From SoftwarePractice.org

Please click here for the Team Management Page.

Contents 1 System Overview 1.1 System Purpose 1.2 Assumptions 2 Glossary of Terms 2.1 System Requirements 3 Stakeholder Analysis 3.1 Stakeholder Identification 3.2 Stakeholder Ratings 3.3 Stakeholder Benefits 3.4 Quality Attributes Ratings 4 Architectural Analysis 4.1 Contextual Factors 4.1.1 Market/Competitive 4.1.2 Social 4.1.3 Organisational 4.1.4 Technological 4.1.5 Political / Legal 4.2 Usage Narratives 4.2.1 Car-Bike Collision 4.2.2 Monitor Traffic Conditions 4.2.3 Speeding Ticket 4.2.4 Racing at the Intersection 4.2.5 Faulty Video Capturing Device 4.2.6 Emergency Alert 4.2.7 Failure Alert 4.2.8 Road Usage Enquiry 4.3 Quality Narratives 4.3.1 Reliability – Runtime Quality 4.3.2 Performance – Runtime Quality 4.3.3 Scalability – Non-Runtime Quality 4.4 Architecture Constraints 4.5 Architecture Issues 5 Conceptual Architecture 5.1 View 5.1.1 Final Version of Conceptual Architecture (version 7.1) 5.2 Description 5.3 Component Responsibilities 5.4 Use Case Maps 5.4.1 Use Case Map 1 - Car-Bike Collision 5.4.2 Use Case Map 2 - Racing at the Intersection 5.4.3 Use Case Map 3 - Failure Alert 5.4.4 Use Case Map 4 - Road Usage Enquiry 5.5 Impact Maps 5.6 Performance 5.6.1 Scalability 5.7 Data Model 5.7.1 General Description 5.7.2 Video Buffer Persistent Storage 5.7.2.1 View 5.7.2.2 Description 5.7.3 Traffic Density Buffer Persistent Storage 5.7.3.1 View 5.7.3.2 Description 5.7.4 Central Database Persistent Storage 5.7.4.1 View 5.7.4.2 Description 6 Execution Architecture 6.1 Concurrent View 6.1.1 Description 6.1.1.1 Component Level Description 6.1.2 Behavioural Analysis 6.1.2.1 Car-Bike Collision 6.1.2.2 Faulty Video Capturing Device 6.2 Deployment View 6.2.1 Description 7 Implementation Architecture 7.1 View 7.2 Description 8 Architecture Styles 9 Architecture Design Critique 10 References 11 Appendix 11.1 Presentation 11.1.1 Milestone 1 Slides 11.1.2 Milestone 2 Slides 11.2 Minutes Of Meeting

System Overview

System Purpose

The Intersection Monitoring System (IMS) provides for the next generation monitoring of road intersections or on a stretch of road. IMS is a software intensive system that provides continous video recording of the road intersection 24 hours a day every day. It detects and reports red light offences, speeding offences and accidents, and can monitor road usage by vehicle types and time of day.

Assumptions

The system architecture is based on the assumptions stated below:

1. The system monitors and reports on any activity within the physical range of the monitoring system.

2. We can also assume that any underlying hardware devices will be installed by the client.

Glossary of Terms

CMP  : Central Monitoring Point

CMS  : Central Monitoring Station

GUI  : Graphical User Interface

IMB  : Intersection Monitoring Box

IMS  : Intersection Monitoring System

RTA  : Roads and Traffic Authority

SAD  : Software Architecture Document

UI  : User Interface

UCM  : Use Case Map

System Requirements

The system requirements of the clients can be identified as:

1. The IMS will monitor road usage by vehicle type and time of day.

2. The IMS will record and report unusual events - accidents, speeding, red light offences.

3. Sensor Signal Processor will notify the central monitoring point of unusual events.

4. Monitoring Control will notify the central monitoring of potential or actual system failure.

5. The IMS will provide the means to query the system from a central station.

6. The IMS will provide an unobtrusive way to monitor the system.

Stakeholder Analysis

A stakeholder is any person or organisation who can be positively or negatively impacted by the actions of a system. The various stakeholders identified for this system have been listed below.

Stakeholder Identification

• System Users
  • System Developers
  • Operational Staff
  • Monitoring Staff

• Government
  • Roads and Traffic Authority (RTA)
  • Local Council
  • State Government
  • Fire Department
  • Police Department
  • Health Services

• Other Stakeholders
  • Motorists
  • Human Rights Department
  • Maintenance Crew
  • Media
  • Insurance
  • Legal Services

Stakeholder Ratings

The following table will identify the key stakeholders who can impede and/or promote the project

0 - No ability to promote or impede

5 - Significant Ability to promote or Impede

Stakeholder	Promote	Impede	Comment
System Developers	2	3	Can promote the project by performing tasks efficiently. Can impede the system by misusing their privileges
Operational Staff	3	3	Important Stakeholder Can promote the project by efficiently managing the system. Can impede the project by misusing their privileges
Monitoring Staff	2	0	Can Promote the system by working efficiently
Roads and Traffic Authority(RTA)	5	5	Significant Stakeholder Can fund the project and provide the needed resources. Can stop the project at any time if there are any legal obligations or changes in the system requirements.
Local Council	5	5	Significant Stakeholder Can promote the project and help in organising things quickly if needed Can stop the project at any time if there are any legal obligations.
State Government	5	5	Significant Stakeholder Can promote the project and help in organising things quickly if needed Can stop the project at any time if there are any legal obligations.
Emergency Service Department includes Fire Department, Poilce Department and Health Services	2	0	Can promote the system by responding effectively during an emergency.
Motorists	3	3	Important Stakeholder Can promote the system as it is benefetting them, like after an accident the emergency services will reach the site quicker as they will be informed immediately. Can raise privacy concerns and impede the system.
Human Rights Departments	3	5	Significant Stakeholder Can promote the system by appreciating road safety issues tackeld by the system. Can raise privacy concerns and fight with the government to impede the system.
Maintenance Crew	3	0	Important Stakeholder Can promote the system by finding and repairing any defects in the system, efficiently
Media	1	2	Can promote the system if it turns out to be successful Can impede the system based on motorists interview
Insurance Companies	3	2	Can promote the system based on evidence gathered from various sensors Can impede the system regarding privacy issues
Legal Services	3	2	Can promote the system based on evidence gathered from various sensors Can impede the system on privacy counts

Stakeholder Benefits

Stakeholder	System Developers
Identity	Users that have developed the system.
Characteristics	Knowledgeable to design the system. Develop a system that conforms to the stakeholder requirements.
Nature of their interest	Applying skills to developing new systems.
Benefits to the Stakeholders	Successful running of the system will boost their image in the industry. Enhances their development skills.

Stakeholder	Operational Staff
Identity	User responsible for running the system.
Characteristics	Knowledge of the system's functions and procedures.
Nature of their interest	Maintain the system and keep it running.
Benefits to the Stakeholders	Ease of use of system.

Stakeholder	Monitoring Staff
Identity	Users that will be monitoring traffic once the system is running.
Characteristics	Knowledge of monitoring procedures. Able to contact emergency departments when needed.
Nature of their interest	Receiving accurate data on unusual events. notify emergency services of these events.
Benefits to the Stakeholders	Quick response time and accuracy of data given.

Stakeholder	Roads and Traffic Authority
Identity	RTA is the NSW State Government agency responsible for improving the road safety and managing the road network.
Characteristics	Authority funding the project. Able to read statistical data.
Nature of their interest	Improve road safety and reduce occurence of accidents Access to statistical data.
Benefits to the Stakeholders	Ease of obtaining statistical data. Accuracy of data obtained. Safer roads. Catching road offenders

Stakeholder	Local Council
Identity	Promote strategic development of commercial areas in that region and is proactive in planning for the development of the local area.
Characteristics	Knowledge of rules surrounding the building of projects in local areas.
Nature of their interest	Hardware elements of system need to be implemented under the guidelines supplied by the local council.
Benefits to the Stakeholders	System blends into regular streets and does not stand out. Better road usage statistics.

Stakeholder	Insurance Companies
Identity	Responsible for providing insurance to motorists
Characteristics	Manages insurance policies and claims
Nature of their interest	Reducing motor accidents and having less to claims to deal with
Benefits to the Stakeholders	Will gain financial benefit with the reduction of motor accidents

Stakeholder	Fire Department
Identity	Provide emergency services depending on the nature of the emergency event occurring.
Characteristics	Responds to emergency calls. Transport fire brigades at the site.
Nature of their interest	Receiving accurate details on incidents that have occured.
Benefits to the Stakeholders	Faster response to emergency locations. Accurate details of location and severity of accident.

Stakeholder	Police Department
Identity	Responsible for real time road safety
Characteristics	Knowledge of road rules Have the ability to issue on-the-spot fines
Nature of their interest	Road and traffic safety
Benefits to the Stakeholders	Less personnel needed to patrol traffic

Stakeholder	Health Services
Identity	Services that use the road for different reasons. These include the Ambulance Service looking after sick or injured people, the police who uphold the countries laws, and the fire services that help to put out fires of different types in buildings or in the bush
Characteristics	Health services are also road users but assist people who are in need of help in different emergencies. In order to do this they require minimal traffic to reach emergency spots in shorter durations.
Nature of their interest	Able to go through the traffic in a short time
Benefits to the Stakeholders	With traffic running smoother it means the Emergency services have quicker routes to get to the emergency situations that they help keep in check

Stakeholder	Motorists
Identity	Drivers of the automobiles.
Characteristics	Able to drive automobiles. May be road rule offenders.
Nature of their interest	Would like safer roads. Require emergency response when accidents occur.
Benefits to the Stakeholders	Allows the roads to be safer as traffic offenses will occur less often. Faster emergency response

Stakeholder	Human Rights Department
Identity	Concerned for the privacy of citizens.
Characteristics	Knowledge of laws concerning privacy.
Nature of their interest	Does not want the identities of citizens to be shown in monitored video footage.
Benefits to the Stakeholders	Identities of citizens will not be shown.

Stakeholder	Maintenance Crews
Identity	The people responsible for repairing/replacing any piece of equipment which has malfunctioned
Characteristics	Knowledge of all monitoring equipment. Can repair or replace all cables, cameras and sensors.
Nature of their interest	Supplying high quality service to all monitoring equipment.
Benefits to the Stakeholders	If the system were to expand, more monitoring equipment means more maintenance jobs to be given.

Stakeholder	Media
Identity	Provides news directly to the general public
Characteristics	Able to greatly influence the views of people
Nature of their interest	Depending on how successful the system is, the media will be able to provide feedback about it
Benefits to the Stakeholders	Will allow them to criticise or compliment the system

Stakeholder	Legal Services
Identity	Responsible for dealing with lawsuits
Characteristics	Knowledge of the law
Nature of their interest	Will be able to file lawsuits against the system whenever possible
Benefits to the Stakeholders	Will gain profit if a lawsuit is filed and won

Quality Attributes Ratings

Each Stakeholder is provided 10 points to rate the importance of the different quality attributes associated with them. The total for each quality attribute represents the overall score and will help in determining the top 3 quality attributes associated with our system.

Stakeholder	Maintainability	Performance	Security	Testability	Usability	Reliability	Scalability
System Developers	2	1	2	2	1	1	1
System Administrator	2	2	2	0	3	1	0
Monitoring Staff	0	2	1	0	3	3	1
RTA	0	3	1	0	1	3	2
Local Council	0	2	1	0	0	4	3
Motorists	0	2	0	0	0	4	4
Human Rights Department	0	3	4	0	0	3	0
Maintenance Crew	3	2	0	1	2	1	1
Total	7	17	11	3	10	20	12

The three main quality attributes of our system are Reliability, Performance and Scalability.

Architectural Analysis

Contextual Factors

Market/Competitive

Enablers

In an effort to beat road tolls and offences that can lead to injuries, this project has been funded to create a system to keep roads safer. In this market there won’t be any competitors as it is funded directly by the RTA. This system has a great potential to be adopted by other states if it were to be a success in NSW. The statistics provided will help the RTA in their planning of roads as they are able to monitor traffic behaviour more closely and accurately.

Social

Enablers

Accidents will be more easily detected and a faster response by the emergency department can be made. With the vast amount of monitoring and recording happening, traffic offences will reduce and the roads will feel safer.

Constraints

When creating a system which utilizes camera technology, procedures must be taken to protect the privacy of people to prevent lawsuits.

Risks

There is a chance that this system can induce fear into the eyes of drivers.

Organisational

Constraints

Accident response relies heavily on the perception and judgement of monitoring staff as they will be responsible for contacting emergency services. Procedures must be put into place to ensure judgements are made correctly.

Risks

An incorrect response by monitoring staff may either lead to emergency resources being dispatched unnecessarily or emergency resources not being dispatched at all to locations when it is needed.

Technological

Enablers

The technology being used to monitoring and recording is already currently available and can be mass produced. Storage mediums have also become cheaper and require less space as it is increasingly becoming affordable.

Constraints

The system relies heavily on the quality of the technology being used as data being returned needs to be as accurate as possible. Maintenance checks and back ups will be needed in order to keep equipment from malfunctioning. This system relies on the surrounding area’s electricity supply to run which means blackouts will inevitably cause monitoring and recording equipment to go offline for the area affected. Severe traffic accidents and sabotaging may cause damage to monitoring equipment.

Political / Legal

Constraints

This system has a chance of breaching privacy laws as it includes recording of live footage with cars and pedestrians involved. Due to human rights departments, precautions must be taken and preparations must be made in order to wipe out any chance of lawsuits.

Usage Narratives

Car-Bike Collision

On a friday morning, at 10:00 AM, Steve was driving his Sedan along Victoria Road. Tom, a passionate motorcyclist and an engineering Student at UWS, was getting late for his lecture. At the traffic lights, at intersection point V5 on Victoria Road, the signal turned amber which provoked Tom to drive faster and get through. Steve who was driving behind Tom had a similar intention. Tom changed his mind at the very last moment and slowed down and decided to stop. Steve, who by now had over-committed, was late in halting his car, crashed onto Tom's motorbike. The audio sensors detected the accident due to sudden rise in audio frequency caused by screeching tyres when braking and the collision; and triggered the system to preserve the last 10 seconds of the video leading up to the accident. An alert was reported to the central monitoring station warning of a possible accident with the 10 seconds of video footage being sent. John, who was on duty at the central monitoring station viewed the video and contacted the emergency services by phone and gave them details on the location and the type of accident. It took approximately 1 minute in total from the time in which the accident occured and the emergency services were contacted.

Stakeholders Associated

• Motorists
• RTA
• Monitoring Staff
• Emergency Services Department

Quality Attributes Associated

• Reliability
• Performance
• Availability
• Usability

Monitor Traffic Conditions

James, a dedicated RTA staff member decided to monitor the traffic conditions at a particular intersection. The intersection of interest was the Great Western Highway and Cumberland Highway intersection which has had an increase in peak hour traffic. James chose this particular intersection at his computer and queried the system to provide statistical data from the previous month till today for the hours of 4pm to 7pm. The results showed an alarming number of vehicles going through this intersection between those hours and the data presented gave vehicle types as well as time of day.

Stakeholders Associated

• Motorists
• RTA
• Monitoring Staff

Quality Attributes Associated

• Performance
• Usability
• Reliability

Speeding Ticket

Kevin, a newspaper journalist, arrives home one day to discover that he has been given a speeding ticket. The speeding ticket had details on the time and location of the incident but he did not believe that he had been speeding in this area. He quickly and angrily called up the RTA regarding this offense and was given an opportunity to see the picture taken at the time of the incident through the RTA website. Upon seeing the picture, Kevin noticed that his face was blurred for privacy reasons. Upon taking a closer look at the picture he noticed that the pedestrians and other driver’s faces were blurred. Wondering why this had been done he called up the RTA once more and asked why this was done. To his surprise it was to protect the privacy of people and would prevent lawsuits from happening in regards to privacy concerns.

Stakeholder Associated

• Human Rights Department
• RTA
• Motorists

Quality Attributes Associated

• Security
• Availability

Racing at the Intersection

Steven and Beckam, 2 enthusiastic motorcyclists, were racing along the Hume Highway. They even drove past the traffic light, at the corner of Henry Lawson Road, when the signal was red, without ever intending to stop. Unfortunately for them, the sensors in the ground at this particular intersection triggered the cameras and pictures of these offences were recorded. These pictures were sent to the Central Monitoring point along with the date and time of the incidents. John, who was on duty at the monitoring station, viewed the transmitted images. These images showed 2 motorcyclist in the middle of their red light offenses with their faces blurred but all that was required was the license plate. John recorded these offenses which were later sent to the police for processing. One week later, Steven and Beckam each recieved a very large fine due to their neglection of traffic laws.

Stakeholders Associated

• Motorists
• RTA
• Monitoring Staff

Quality Attributes Associated

• Performance
• Usability
• Reliability
• Scalability

Faulty Video Capturing Device

It was 5:30pm on Parramatta rd and there was a steady flow of traffic as the majority of the working population was on its way home from a hard day at work. At this time, 1 of the video cameras, used to monitor traffic, decided to malfunction and data flow, from this camera, went to a halt. The traffic monitoring system did not stop sending data to the central monitoring point though. The system came equipped with 2 cameras at each point of monitoring and was well prepared for this event. Data was now being sent from the single camera. As this camera had malfunctioned, a warning was sent to the central monitoring point. Jeremy, an operator of the central monitoring point, received this warning and then proceeded to book a maintenance crew to prepare to go out and repair the camera. The only time that was available in the maintenance schedule was for that night in between 11pm and 12pm so he entered the details of location and type of fault. Bob, from the maintenance crew, received the call and set his schedule to prepare to get the job done. At 11:00pm that night, Bob and his crew set out to this camera to fix the camera. At approximately 11:20 after replacing the camera, the system was ready to function as normal so Bob called up the central monitoring point to notify them. Sally answered the call and checked that the camera was ready to work. To do this she streamed live footage from that camera to verify that it is indeed working. The checked turned up successful and the camera then continued to monitor like normal and Bob went back home in time to sleep.

Stakeholders Associated

• Monitoring Staff
• Maintenance Personnel
• Camera Manufacturers

Quality Attributes Associated

• Performance
• Usability
• Reliability
• Availability

Emergency Alert

It was 7:30am on Hume hwy and it was the time that the majority of the working population was on its way to work. Jeremy, a bank worker, was in a rush to beat the traffic so he drove as fast as he could without going above the speed limit. He quickly overtook many cars. Darren, another bank worker, was driving at a steady pace noticed Jeremy driving next to him and slowly going passed him. In his rush, Jeremy quickly changed into Darren’s lane prompting him to quickly break to avoid collision. The quick breaking caused to tires to screech and an alert was sent from the monitoring system to the central monitoring point. Brad, the operator at the central monitoring point, received the alert approximately 10 seconds later and watched the 10 seconds leading up to the tires screeching and noticed nothing had happened. The system gave Brad 2 options. These were to disregard the alert or to call the emergency departments. Noticing that nothing had happened Brad disregarded the alert.

Stakeholders Associated

• Motorists
• Monitoring Staff
• RTA

Quality Attributes Associated

• Performance
• Usability
• Reliability

Failure Alert

It was 7:30 PM on a Sunday evening, when John, an operator at the Central Control Unit received an alert on his computer screen from the failure monitoring block unit of the Intersection Monitoring System of disfunctional audio sensors at Hume Highway and Auburn Road intersection. Since audio sensors were used to identify accidents, John was glad that the system came equipped with a failure monitoring block. He quickly looked up the maintenance crew schedule and chose the earliest time availble for them to go fix the audio sensors. The earliest time was between 11pm and 12am that night. At around 11:30 PM, he received a call from the leader of the maintenance crew that they had fixed the hardware for the audio sensors. The maintenance crew had verified that the audio sensor was working as it was able to produce audio data. John was relieved that the system was now fully functional for monitoring the traffic for the busy Monday morning tomorrow.

Stakeholders Associated

• Monitoring Staff
• Maintenance Crew
• Motorists

Quality Attributes Associated

• Performance
• Reliability
• Maintainability

Road Usage Enquiry

It was 8:00AM on Monday morning, when Sandy, an operator at the Central Monitoring Point, was asked by David, an RTA official, to check details of road usage at the George St and Liverpool St intersection for the previous day. She selected the intersection on her interface and inputted the date as well as time and duration. The results showed her the amount of cars that went by as well as showing that a single unusual event occurred. She saved the data, which was stored into a single text file, and sent it to David.

Stakeholders Associated

• RTA
• Monitoring Staff
• Motorists

Quality Attributes Associated

• Performance
• Reliability
• Usability
• Maintainability

Quality Narratives

From the stakeholder analysis, the following 3 quality attributes were exposed as critical to the system:

Reliability – Runtime Quality

Reliability of the system is perhaps the most critical aspect of the IMS. Since some of the data collected can be used to investigated accidents and be used as evidence in court, it is imperative that the system is reliable, and able to report on its condition, failures, calibration. The data can also be used in planning and analysis, so again, reliability of the system is important to ensure the data collected is meaningful and accurate.

Narrative 1:

There is an accident at an intersection monitored by a Intersection Monitoring Block. A car has hit and killed a pedestrian. It is late, and there were no witnesses. The driver of the vehicle has not stopped to report the incident and needs to be traced.

Robert, an accident investigator at the RTA, logs into the IMS to check for incidents. The IMB has reported an accident event, having detected the squeal produced by skidding tires. It has also identified the speed as out of range for the intersection, and that the car had passed through a red light. All the events are time-stamped, and the video clips have corresponding live time-stamps in the lower left corner of the image.

From the video clip data, the number plates of the car were captured. Robert generates a report based on the IMB data collected, and this is used by police and Department of Public Prosecutions.

The data from the IMB enables police to locate, charge and arrest the suspect.

In court, the defence tries to discredit the reliability of the system, and the validity of the data, but because the IMS has continuous self-monitoring capability which is reported on a regular basis, the prosecution is able to uphold that the data captured is valid.

The defendant is later prosecuted with charges including speeding, negligent driving manslaughter, and failing to stop at the scene of an accident.

The reliability of the system was key to the data being accepted as evidence by the court, and log records were provided as proof of the system reliability.

Narrative 2:

The Strategy & Planning department at the RTA are developing the next 5 year capital works program, and are conducting an initial investigation to determine where money needs to be spent. Factors they are looking for are accidents and their frequency, capacity and utilisation of roads and traffic patterns surrounding intersections. The IMS is becoming a critical source of data since it is deployed at many prominent roads and intersections, and has a variety of sensors for gathering this data.

Using the IMS, the Strategy and Planning staff are able to query for accident reports at IMB sites, and determine the frequency at which they occur. Because the IMB was deployed at the Seven Hills/Leabons Lane roundabout, they are able to identify that it has become an accident black spot due to the unusual geography of the roads intersecting. There are significant visibility issues, and recent residential developments have increased the volume of traffic flowing through the roundabout.

There are pedestrian considerations due to a childcare centre located on Leabons Lane. Many parents walk and drive to drop their children off at the childcare centre.

Direct access from Lucretia Road to the intersection was removed a decade ago to prevent accidents at the intersection, but that has resulted in cars being diverted via Ellam Drive, which has poor visibility of traffic flowing out of the roundabout, and has just resulted in the accident black spot moving from the roundabout to the Ellam Drive intersection.

It is decided that funding should be allocated to convert this roundabout to a traffic-light controlled intersection.

Additional usage statistics indicate a large amount of traffic flows from Seven Hills road onto Leabons Lane which connects to another major road, so a right turn lane is catered for in the planning.

The accuracy of the data was important in determining the right-turn lane, and was a result of the reliability of the system.

Performance – Runtime Quality

Performance is another very important aspect of IMS as the system will be sending real-time data continuously. Performance is measured by how long it takes for data to reach its destination, how accurate the data is and how much data was recorded. When an unusual event occurs, it is important that the central monitoring point is notified as quickly as possible so that action can be taken. It is also important for the system to continuously record the data of every vehicle going through that intersection as the data is stored for future reference and needs to be accurate.

Narrative 1:

On May 3rd, 2008, there was an accident in which 2 cars collided at the Henry Lawson Drive and Hume Hwy intersection. As the cars collided, a large screeching sound of the tyres caused the IMS system to react. This sent a warning signal to the central monitoring point. It took the signal about 2 seconds for the signal to reach the central monitoring point.

At the central monitoring point, David was on duty and received the warning in which he then watched the video footage of the crash to assess whether emergency services were required to be contacted. After watching the 10 second footage, David decided that emergency services were needed as people were injured so he went ahead and contacted them via phone.

Amy, at the emergency department, took the call from David and dispatched nearby emergency services as required. It took a total of 1 minute and 20 seconds from when the crash occurred to when Amy was able to send out people and a total of 5 minutes for them to appear on sight.

Narrative 2:

On September 20th, Jeremy, from the RTA, decided that he needed to access the road usage data of King Georges road for reference in future road works. Data had been continuously recorded. Whenever a car goes past this particular intersection, the system records the type of car and the time and stores it into a database.

Jeremy was able to quickly generate the road usage data as he only needed to query the system for the hours of between 4pm and 7pm of the previous day.

Scalability – Non-Runtime Quality

Scalability is perhaps the third most important aspect of IMS. The system must be able to expand from a small suburb to a whole region of suburbs. Each suburb has a large number of intersections and other road areas that will require IMS implemented. Scalability is measured by how much the system is able to expand while working as intended.

Narrative 1:

IMS has recently launched and only a small number of suburbs had been implemented into this system. The next target suburb planned was Campsie with a large number of intersections requiring monitoring.

When each intersection has IMS implemented, an on-site official contacts the central monitoring point stating that that particular intersection is ready. After entering the details for that intersection, the monitoring staff tests to see if data is flowing from that intersection to the central monitoring point. Video footage is sent and the monitoring staff verifies that it can be seen.

After the intersection is verified to be ready it is added to Campsie’s list of intersections in the system.

Narrative 2:

It was the 2nd of August when Darren was driving up Lane Cove road when he noticed there had been a car crash on a particular intersection. Records showed that this particular intersection was notorious for accidents.

Darren also noticed that this intersection was not equiped with IMS when it was clearly needed reduce the number of traffic accidents. He sent in a request, for this intersection to be equiped with IMS, to the RTA. About 2 weeks later the RTA went to work and equiped the intersection with IMS.

Architecture Constraints

The following constraints were applied during the architecture design:

• Describe the significant components

• Internal and external interfaces and relationships

• Define graceful evolution paths and reuse variations required

• Guide – component selection, adaptation and binding

• Allow smooth assembly of components

• Provide compatibility across multiple instances

Architecture Issues

The following architecture related issues were considered for the architecture design:

• Fault tolerance of the software

• Early defect detection

• Risk reduction

• Measurement

• Reuse

• Quality

• Transfer targets – should be easily implemented

Conceptual Architecture

The conceptual architecture provides a domain-level overview of the system. It's main purpose is to increase understanding of the system.

View

Conceptual Architecture - Version 1

Conceptual Architecture - Version 2

Conceptual Architecture - Version 3

Conceptual Architecture - Version 4

Conceptual Architecture - Version 5

Conceptual Architecture - Version 6

Conceptual Architecture - Version 7

Final Version of Conceptual Architecture (version 7.1)

Description

Data enters into the system through the use of various sensors. Sensors are deployed into the system inorder to detect the occurance of ususual events, like crash events, speeding offenses and traffic light offenses, and also to monitor road usage at various intersections. All the sensors are operating in real time.

They can be categorized as:

1. Unusual Event Sensors
2. Data Recording Sensors

Unusual Event sensors can be further categorised into:

1. Audio Sensors - Generates Event when audio frequencies that do not lie in the specified range are detected
2. Red Light Offence Sensors – Generates Event when a red light offence has been committed by a motorist
3. Speeding Sensors – Generates Event when a speeding offence has been committed by a motorist

Data Recording is done by two types of sensors:

1. Video Capturing Device – Records vehicle movements
2. Traffic Density Sensor – Monitors road usage by vehicle type(Light weight or Heavy weight vehicle) and time of day

Intersection Monitoring Box (IMB) is the name given to the collection of components that perform several functionalities which are described below in detail. It comprises of Failure Monitoring Block, Video Data Handlers, Sensor Handlers and Traffic Data Handlers.

Upon occurance of an unusual event, the Sensor Signal Handler receives the event via Unusual Event Sensors. It then identifies the source of the event and reports the event to Sensor Signal Processor. Sensor Signal Processor then contacts the video storage device, which will get the last 10 seconds of the recording, in case of a crash event, as recognized by audio sensors, or get the image of the event in case of a red light offense or a speeding offense as detected by the Red Light Sensor or Speeding Sensor respectively, and passes the data to the Unusual Event Handler. Unusual Event Handler notifies the Unusual Event User Interface of the unusual event that has occurred.

The operator at the Unusual Event User Interface contacts the appropriate emergency services, in case of a crash event, and updates the central database. External interface, which also includes RTA, can retrieve data via the Data Communicator and query the system and perform various operations like getting road usage details, red light offenses, speeding offenses etc.

Data Recording Sensors collect video data and traffic data information and store it locally into Video Storage and Traffic Density Storage respectively. The data from the storage can be retrieved via the interfaces and transmitted to the Sensor Signal Handler or Data Monitoring Unit on request. Data Monitoring Unit requests video data and traffic data and sends this data to System Monitoring User Interface for further processing.

All the data, that is received from various components by the Central Monitoring Point, is stored at this central location in the Central Database, which is controlled by the Database Access Layer.

To monitor the operations of the various kinds of sensors, the system contains a Failure Monitoring Block which polls the sensors and notify Failure Control Unit of any hardware or software failures. This information is then passed onto the System Monitoring User Interface which notifies the maintenance crew in case of any failure event. A record of the failure notification is also stored in the Central database for future reference.

3G wireless connection is used to connect between the IMB device and CMP. 1 CMP interacts with a number of IMB devices via 3G wireless connection. This type of network connection will enble faster data transmission capabilities and deliver speeds of up to 14.4Mbit/s on the downlink and 5.8Mbit/s on the uplink. 3G network also offers a greater degree of security by allowing the User Equipment(UE) to authenticate the network it is attaching to. The user can be sure the network is the intended one and not an impersonator.

Component Responsibilities

The table below summarises the responsibilities for each of the components of the conceptual architecture.

Component	Responsibility
Video Storage	Stores Video and Images Transmits Videos and Images
Sensor Signal Handler	Senses the type of event generated
Traffic Density Data Storage	Stores Road Usage Data Transmits road usage data on request
Sensor Signal Processor	Performs various control actions as per the unusual event
Failure Monitoring Block	Polls sensors Generate notifications on detection of failure
Unusual Event Handler	Recieves data related to unusual event Transmits event related data
Data Monitoring Unit	Retreives road usage data and Video Data Transmits data to UI Helps CMS to query the system
Failure Control Unit	Recieves Failure Events Notifies CMS
Unusual Event Monitoring User Interface	Recieves Unusual Event Notification. Contact Emergency services Stores Data
System Monitoring User Interface	Query the system Recieve Road Usage Data and Other Video data Stores Data in the Central Database Receives Failure Notifications Contact Maintenance Crew
Central Database	Stores data Transmits data
Data Communicator	Recieves data transmission requests Query the Central database transmits data

The Following are not the actual components in the system but external hardware interfaces which play a mjor role in our system. These are mainly the sensors being used

Interfaces	Responsibility
Video Capturing Device	Captures video data Transmits video data
Audio Sensor	Captures audio sounds Transmits audio sounds on detecting sounds of unusual frequency
Red Light Offence Sensor	Detects red light offences and generate events on its detection
Speeding Sensor	Detects speeding offences and generate events on its detection
Traffic Density Sensor	Captures Traffic Events Transmit Traffic Density Data

Use Case Maps

Use Case Map 1 - Car-Bike Collision

Explanation: The diagram shows triggering of the audio sensor when an unusual audio frequency was detected, when a crash occurred and the action of events that were followed leading upto informing the Emergency Services Department.

• A sudden change in Audio Frequency Level is detected by the audio sensor and an event is triggerred and a signal is sent to the Sensor Signal Handler
• Sensor Signal Handler recognizes the event and transmits a signal to Sensor Signal Processor for futher Processing
• Sensor Signal Processor requests Video Storage to transmit the last 10 seconds of the recorder video.
• Video Storage queries its database to extract the requested video and forwards it to the Sensor Signal Processor upon retrieval.
• Sensor Signal Processor transmits the video clip to Unusual Event Handler which recognises the unusual event and transmits the video to the Unusual Event Monitoring User Interface.
• The staff member at the Central Monitoring Point recieves the video clip and informs the corresponding Emergency Services Department
• The staff member also updates the database for the occurance of the particular event i.e. crash event in this case

Use Case Map 2 - Racing at the Intersection

Explanation:

The diagram above illustrates the scenario when multiple events take place at the same time and how the system handles the occurance of these multiple events and takes appropriate actions

• Red Light Offense Sensor detects a red light offense and sends a signal to Sensor Signal Handler
• Concurrently the Speeding Sensor detects overspeeding occuring and sends a signal to Sensor Signal Handler
• Sensor Signal Processor sends a request to the Video Controller to transmit the recorded image for the corresponding Red Light Offense and another request to send the image for the speeding offense.
• Video Storage recieves the requests and transmits the requested images seperately for the corresponding events.
• Sensor Signal Processor then transmits the images to the unusual event handler which recognizes both the events and transmits the images to the Unusual Event Monitoring Interface
• The images then get stored in the Central Database.
• RTA which regularly checks for road offences comes across these images and imposes appropriate penalties on the offenders.

Use Case Map 3 - Failure Alert

Explanation: The above diagram demonstrates the scenario of a occurance of a failure event of the audio sensor and how the system handles the failure event and informs the Maintenance crew to check and fix the fault

• Failure Monitoring Block regularly monitors the sensors to check their functionality.
• Failure Monitoring Block recognises a failure event, and sends a message to Failure Control Unit which then transmits it to System Monitoring User Interface.
• Staff Member at the System Monitrong User Interface acknowledges the recieved message and informs Maintenance Crew to fix the fault.
• Upon fixing the fault the Maintenace Crew inform the Monitoring Staff

Use Case Map 4 - Road Usage Enquiry

Explanation: The diagram explains the scenario when an RTA staff, at the Central Monitoring Point wishes to query the system and monitor road usage at a particular intersection by analysing the recorded video clips and traffic density data.

• The user at System Monitoring User Interface sends a message to Data Monitoring Unit to send the recorded video clips and Traffic Density Data to analyse the road usage at a particular intersection, for a fixed time interval
• Data Monitoring Unit transmits a signal to Video Storage and to Traffic Density Video Storage to transmit the requested video clips and Traffic Density Data Respectively
• Video Storage recieves the signal and transmits the requested video clips from the video buffer.
• Traffic Density Data Storage recieves the signal and transmits the requested data from the Traffic Density Buffer.
• The Video Clips are then passed on to the Data Monitoring Unit and then to the System Monitoring User Interface where the staff recieves and views them and discards them when no unusual event was recognized
• The Traffic Density Data is also passed on to the System Monitoring User Interface via the Data Monitoring Unit, where the operator recieves the data and analyses it and stores the statistics to the central database

Impact Maps

Performance

The impact above is focussing on the performance of the system. It shows in the event of a screeching sounds detected, the Sensor Signal Processor requests for the video for that location and the Unusual Event Handler transmit this data to the Unusual Event Monitoring UI where monitoring staff informs the Emergency Services Department upon knowing of the severity of the event.

Scalability

The impact map above describes the incorporation of an extra IMB into the system. The extra component for Intersection Monitoring Block represents the entire IMB block illustrated to its left, hence the multiplicity symbol has been left out. The behaviour analysed is the monitor road usage and unusual event handling by the system upon addition of a new IMB. The system is designed to function correctly with the addition of extra sub-systems.

Data Model

General Description

• All the data stored in the system shall be time stamped based on the actual time and not when the observation was entered into the system. Even though the information entered is real-time this is done to ensure the exact details for the observation are retrieved and any delay in inputting of data will still be for the time the observation was actually made.

• All the data stored into the system shall be standardised to follow a consistent pattern that will make it easier to compare different data. An example of this is:
  • Time entered into the system shall be of the format HH24: MI: SS (hour: minute: second).
  • Date entered into the system shall be of the format DD: MM: YYYY (day: month: year).

• Source entity identifies the source from which the data has originated. This could be either of the various kinds of sensors.

• Street entity contains details of the particular street for which the data is being provided.

Video Buffer Persistent Storage

View

Description

• Video of road usage, at a particular location, that is being continuously recorded is being stored. This is continuously being recorded and required when an unusual event occurs. The data gets overwritten at the end of the day, if it has not been requested.

• Time and location details of the video are also stored. This is the time when the video was recorded and not when it was entered into the system as described above.

Traffic Density Buffer Persistent Storage

View

Description

• Information on road usage is stored at a particular location, this is being done continuously.

• Time and location details of the road usage are also stored. This is done in order to identify road usage patterns.

Central Database Persistent Storage

View

Description

• Details of system failure are stored here
• Information of unusual events also gets stored here
• Traffic density buffer data gets stored here centrally
• Only relevant video data gets stored

Execution Architecture

Execution Architecture translates the domain level responsibilities and the flow of information from the Conceptual Architecture to unit of concurrent activities and invocation relationships.

Execution Architecture for IMS is represented in two views:

1. Concurrent View

2. Deployment View

Concurrent View

Execution Architecture - Version 1

Execution Architecture - Version 2

Execution Architecture - Version 3

Description

Component Level Description

Failure Monitoring Block

Failure Monitoring Block polls all the sensors and devices (Audio sensors, Red Light Offence Sensors, Speeding Sensors, Video Capturing Device, Traffic Density Sensor) for its operational status. It is connected to Failure Control Unit via a TCP/IP link that is invoked if poll result from at least one or more sensors shows current or potential sensor failure.

Sensor Signal Handler

Sensor Signal Handler is another concurrent sub-system that can be mapped to conceptual architecture (Sensor Signal Handler and Sensor Signal Processor). This component receives events from the unusual event sensors (Audio Sensors, Red Light Offence Sensors and Speeding Sensors). It identifies the source of the unusual event and requests images/video (video- if the source of event is an accident, images - if the source of the event is a red light offence or a speeding offence)from the Video Storage component via a synchronous API call. It forwards the unusual event to the Central Monitoring Station via a TCP/IP link.

Video Storage

This component provides a continuous recording buffer for the video input received from Video Capturing Device. It accepts requests from the Sensor Signal Handler and formats the video for output. It also processes the video to generate static images if the requests were for static images, in cases of red light offences or speeding offences. It implements a software interface to facilitate data update in the Data storage Component via the Data Monitoring Unit; via a TCP/IP link.

Traffic Density Data Storage

This component executes as a concurrent component. It receives traffic density data from the traffic density sensors and formats the data to represent vehicle types (Light, Medium, Heavy) and frequency of vehicles for particular times during the day. It is connected to the Data Monitoring Unit via a TCP/IP link and implements a software interface for data transmission which finally gets stored in the Data Storage.

Failure Control Unit

This component executes as a concurrent component on the server side. The Failure Control Unit polls the Failure Monitoring Block for potential or current system failure. In case of a failure of a particular type of sensor or device, it reports to the Central Monitoring Point where the operator performs necessary action.

Unusual Event Handler

This component executes as a concurrent sub-system on the server side. It polls the Sensor Signal Handler for Unusual Event and notifies the Central Monitoring point if an unusual event occurs.

Data Monitoring Unit

This component executes as a concurrent sub-system on the server side. It implements the software interface that is used for communication with the Video Storage and the the Traffic Density Data Storage components executing on the client-side. Its primary objective is to facilitate data communication with the client-side and to support multiple communication channels.

Central Monitoring Point

This GUI component is executed as a concurrent sub-system in the server-side. Its primary objective is to regulate the system and to provide visibility of the working of the system. When, it receives an unusual event, the operator working at the Central Monitoring Station creates a report and files it to the appropriate facility external to the system. It also implements video surveilance, where live videos of cretain intersections can be played and performs traffic analysis reports based on inputs from the Traffic Density Data Storage running on the client-side for a particular intersection. It also has the added responsibility of mobilizing a maintenance crew once a failure notice has been reported.

Data Storage

This component is implemented as a remote storage unit where all data is stored.

Behavioural Analysis

Car-Bike Collision

The above Use Case Map covers the usage narrative of a car-bike crash event at a intersection and how our system handles the event

Faulty Video Capturing Device

The above Use Case map covers the scenario when a faulty Device is detected by the system and monitoring staff is notified who in turn notifies the Maintenance Crew

Deployment View

Description

Client Application

Client Application is deployed in a separate hardware and provides support for remote TCP/IP connection with the Servr-side application. TCP/IP is chosen over UDP/IP as it is a reliable channel, however, there is performance trade-off for acheiving reliability of the system. The Client Application is implemented as a thick client that does most of the data gathering and processing. Further, client application is replicated to represent independent clients that should be supported by the server-side application.

Server-side Application

Server-side Application includes the Processing Unit and the Server-side GUI. Both the software components are included inside a single hardware device, as the Central Monitoring Staion, theoritically, monitors many Client Applications. As there is a considerable amount of processing done in the Processing Unit, including the Server GUI in the same hardware machine eliminates the need for making remote calls to the Processing Unit from the Server GUI and vice versa. This results in increased performance of the system as the system speed within a specific hardware device is not bottlenecked by the connection speed if it were implemented in a different hardware device, and the processing speed would be directly influenced by the network bandwidth speed. However, in this case the acheived performance is much greater than the reliability compromized by implementing both the processing Unit and the server-side GUI in the same hardware device.

Central Database

Centeral Database is stored in a separate hardware to the Server-side application. This has been done to acheive a greater system reliability with compromize in the system performance. Deploying the Central Database in a separate hardware module, further, provides the ease of deployment of redundant data storages as the process of replacing a data storage would be accomplished by disconnecting the HTTP interface and reconnecting it to the substitute data storage. The cost of implementation of a redundant data storage is justified by the reliability gained by the system, as reliability is a major quality attribute of the system when compared with the cost of implementation and as justified by the quality attribute analysis.

Implementation Architecture

View

Implementation View - Version 1

Implementation View - Version 2

Description

Java is the chosen language for implementation of the IMS. Java provides platform independent code execution via the use of extensive system libraries and the use of Java Virtual Machine (JVM), which provides support for just in Time Compilation (JIT). Further, JDBC driver is also provided by Java for enhanced data base access. Sql Server is used to implement and data storage.

Client Application

The client application will be implemented using JRE1.5. This run-time environment provides support for RMI (Remote Method Invocation) which the client application will be using for communicating with the server-side application. The client application accesses the server by making remote server calls.

Server-side Application

The server-side application will be implemented using the JRE1.5 and JWT (Swing classes). The Central Monitoring Point will be implemented in JWT, as it provides support for good GUI look and feel when used across different platforms the system may be deployed in. The server-side application implements the remote methods that the clients can access using the RMI procedure calls.

Data Storage

Data storage will implement JRE1.5 for providing support for RMI calls the server-side application will make to the Data Storage. The Data Storage will be implemented using the Sql Server, as it has a considerable amount of market share and market confidence.

Architecture Styles

Reliability is the most important aspect of IMS. Our distributed object architecture addresses this quality by allowing for failure monitoring. The system needs to be continuously running with no down time or as little down time as possible. This is made possible through a failure monitoring block on the client side which communicates with the failure control unit on the server side. The layered architecture also allows for data integrity as data is flowing in a single direction from the lower layer to the higher layer.

Scalability is addressed in the DOA as it allows for a large number of clients to a single server. The IMBs act as the client while the central monitoring point acts as the server side. This allows for a large amount of intersections to be monitored by a single central monitoring point.

Performance is indeed a very important aspect of IMS but will be affected by the DOA. No matter what architecture is used there will be latency involved. This means that it will take time to send data from, for example, sensor signal handler to the central monitoring point when an unusual event is detected. Latency, however, is minimal and will barely be noticeable.

Traffic monitoring and video also have their own storage on the client’s side to reduce the impact on performance. This data is only sent to the central monitoring point when it is required reducing the amount of data being sent to the data monitoring unit. Traffic monitoring data is also stored in the central database after it has been obtained.

Architecture Design Critique

The development of the initial executable prototype

The development of the initial executable prototype gave us insight into the feasibility of the architecture design. On developing the initial executable prototype, it was realized that the initial version of the Conceptual and Execution Architecture had fundamental defects in them. We discovered that our approach of making the Intersection Monitoring Devices the server and the Central Monitoring Point the client would result in bottleneck of performance as the client would have to be able to access multiple servers simultaneously to achieve system functionalities. Thus, the conceptual architecture was modified to make the server the Central Monitoring Point and the client being the Intersection Monitoring Devices.

Conceptual Architecture

Conceptual Architecture was designed to increase the group’s understanding of the problem for which the solution was being implemented. The usage narratives revealed the core system functionalities against which the quality attributes of the system was assessed. The final version of the conceptual architecture represents a rigorous brainstorming followed by a critical assessment of all criterion and user requirements understanding.

Execution Architecture

The execution architecture was derived from the conceptual architecture and required analysis of the conceptual architecture to identify concurrent sub-systems. From the concurrent sub-systems the deployment view was developed.

Implementation Architecture

The deployment view of the execution architecture suggested that the distributed nature of the architecture would warrant either the 3 Tier Architecture or the distributed object architecture (DOA). The group chose the DOA as major system qualities; performance, reliability and scalability were best supported by this architecture; detailed discussion is included in the Implementation Architecture section.

Chosen Implementation Language

Java was the chosen implementation language as it is platform independent, provides support for remote method invocation and its SWT classes provide cross – platform GUI’s. This further supported the primary quality attributes.

Architecture strengths

The architecture for the IMS is highly reliable, scalable and provides a much enhanced performance based on the architecture design and implementation. All quality related issues and their proper justifications have been provided in the relevant sections.

Architecture Weaknesses

The architecture developed has been constrained by the currently available hardware technologies. The IMS relies heavily on data from the hardware components to an extent that it is almost integral to the functionality of the system. However, due to advances in hardware technologies it may difficult to adapt to newer technologies available.

Future development

The IMS is still open for future development. With hardware advances, the use of multiple sensors to detect unusual events can be replaced with a single device. Further, each device can be given the logic to identify the source of unusual event easing off the processing in the client device without further changes to the other components within the client. This is essential as it directly affects the performance of the system. Increase in communication bandwidth will positively impact the system.

References

Blacktown City Council 2008, About Us, http://www.blacktown.nsw.gov.au/footer/about-us.cfm (1 September 2008)

Emergency NSW 2008, Office For Emergency Services, http://www.emergency.nsw.gov.au/oes (1 September 2008)

Google Maps 2008, Google Map Data - MapData Sciences Pty Ltd , [1] (9 September 2008)

McAdam, R. & Reekie, J. (2006) A Software Architecture Primer, Angophora Press, Sydney

Ministry of Public Security 2008 Automatic Electronic Enforcement Project, http://www.mops.gov.il/BPEng/OnTheAgenda/AutomaticElectronicEnforcementProject/ (1 September 2008)

Roads And Traffic Authority, NSW 2008, RTA Home Page, http://www.rta.nsw.gov.au/ (1 September 2008) McAdam, R. & Reekie, J. (2006) A Software Architecture Primer, Angophora Press, Sydney

Appendix

Presentation

As Wiki does not upload .ppt files, we uploaded the slides in the SVN Repository as adviced by the tutor.

Milestone 1 Slides

Presentation Slides

Milestone 2 Slides

Presentation Slides

Minutes Of Meeting

All the team meetings will be recorded in Meeting Minutes Page, which includes the discussions during the tutorials