T3: Execution Architecture
From SoftwarePractice.org
Contents |
3.1 Execution Architecture Design
3.1.1 Execution Stereotypes
| Icon | Stereotypes |
 | User Initiated |
 | Service |
 | Active |
3.1.2 Concurrent Subsystems
Fig. 1 Audio monitoring subsytem
Fig. 2 Storage access subsystem
3.1.5 Detailed Concurrency Models
3.2 Behavior
3.2.1 Run Time Quality Attributes
The IMS system has a few run time attribute that are very important. These are security as well as reliability. The system needs to be secure so that the information that is recorded will be able to be used as evidence in a circumstance that may need it, such as a major incident occurring at the intersection. The system also needs to be reliable so that the most information can be obtained to help the traffic congestion.
There are several aspects that can occur that may affect the reliability and security of the IMS system they are:
Reliability:
- Power outages
Not a lot we can do about this except to give the whole system its own backup power source.
- Individual components failing
For these types of errors we have the Error Diagnosing System that keeps an eye on every system in case something goes wrong.
- Run time errors
The Error Diagnosing System will help to diagnose these errors as well.
Security:
- Hackers trying to corrupt or take data
To help prevent this from happening the computers and servers of the system will have firewalls and virus checkers installed to keep them secure. All the data will be encoded and it will be a closed system without need to go on to the Internet.
3.2.2 Dynamic Concurrency
3.3 Deployment
3.3.1 Physical Components Design
- Remote Input/Output (RIO) Unit(s)
RIO's handle inputs and/or outputs and act as an interface to some field devices by taking digital and/or analogue signals.
- Intersection Management Units (IMU) (s)
Scans the RIO units and field devices in real-time with fibre and/or ethernet cables, analyses and processes the information and sends the data via Distributed Network Protocol (DNP) to the Reporting and User Interface systems. These units will implement the "Intersection Module" (See Implementation Architecture).
- Master Station
This is where the end user (the RTA) can access the system using desktop computers. The system scans the IMU's via DNP and displays the information on a User Interface. From here, users can query IMU's and the Database System.
- Database System
When queried, the Database System can update a Master Station's local database. The Database System stores all reports/records and has a backup server that archives the data.
- Field Device (s)
- Camera(s) - The camera(s) will be responsible for capturing all images.
- Microphone(s) - The microphone(s) will be responsible for capturing all sounds.
- Traffic Light(s) - The traffic light(s) will be responsible for sending information of the current traffic light status to the IMS.
- Sensors - Senses vehicle height and whether or not vehicles pass intersections.
- GPS Switch - Acts as a Simple Time Network Protocol (SNTP) Server to provide accurate and synchronised (to 1ms) time source.
3.3.2 Deployment Models
- The Deployment Model has been designed to accomodate for high scalability, security and also real-time performance.
- Scalability
The system is quite modular, divided into Intersection Management Unit, Master Station and Database System. Any of these modules can be added in the future to allow for more intersections, additional offices and database servers.
- Security
The inputs to the Intersection Management Unit is through circuitry and serial links and thus can be physically protected against sabotage by placing the system in a cubicle with security locks. Firewalls would then ensure the systems integrity over the internet.
- Real-time Performance
A GPS acting as a SNTP server with the additional atomic clocks inside the IMS units will ensure that time stamps are accurate and synchronised.
