From SoftwarePractice.org

• Ibrahim Abdalla 10461123 • Andrew Chan 02059537 • Orrin Hastings 10407789 • Kenneth Ho 10459319 • Phi Nguyen 10431599 •

Contents 1 System Preface 2 System Scope 3 System Analysis 3.1 Stakeholders 3.2 Stakeholders Narratives 3.3 Usage Narratives 3.4 Quality Narratives 3.5 Contextual Factors 4 Conceptual Architecture 4.1 Initial Overview 4.1.1 Revisions 4.1.2 Current Revision 4.2 Elaborated Overview 4.2.1 Revisions 4.2.2 Current Stereotype View 4.2.3 Responsibilities 4.2.4 Use Case Maps 4.2.4.1 Add/Update emergency vehicle 4.2.4.2 Open new service request & locate vehicle 4.2.4.3 Dispatch vehicle to an emergency location 4.2.4.4 Generate a report on vehicle movements 4.2.4.5 Generate a report on activities in a region 4.2.5 Data Models 4.3 Architectural Justifications 4.4 Architectural Issues 5 Execution Architecture 5.1 Elaborated Concurrent Subsystems View 5.2 Elaborated Deployment View 5.3 Use Case Maps 5.3.1 Add/Update emergency vehicle 5.3.1.1 Add Vehicle 5.3.1.2 Update Vehicle 5.3.2 Open new service request & locate vehicle 5.3.3 Dispatch vehicle to an emergency location 5.3.4 Generate a report 5.4 Architectural Justifications 5.5 Architectural Issues 6 Implementation Architecture 6.1 Elaborated Implementation View 6.2 Decisions for Component Implementation 6.2.1 Off the Shelf Components 6.3 Revised Elaborated Implementation Architecture 6.4 Constraints 6.5 Architectural Justifications 6.6 Architectural Issues 7 Critique 8 Project Tasks Management 9 Instructor comments

System Preface

As we live in a society with no superheroes, one thing we can always rely on is the help of emergency services to assist us when we're in crisis. The New South Wales (N.S.W) State Government has come to the assistance of the Emergency Services in responding to the aid of others in a timely manner by contracting Team T5 to create the Emergency Response Management System (ERMS).

System Scope

Intended to be used by N.S.W emergency service providers to help them decide which unit to dispatch and which route to take to attend to the emergency most efficiently.

It will be assumed that the system will have a "miracle" system that will be responsible in deducing and providing a route between two end points (i.e. the vehicle and the emergency scene). The system itself will be used to maintain a geographic database and can dispatch and track emergency vehicles.

The following are further specifications of the system:

• The emergency vehicles may consist of N.S.W ambulance, fire, police, police rescue, coastal and harbour patrol, traffic control, accident response units, State Emergency Services, and Bushfire services.

• The system must operate 24*7

• The system must know where all vehicles are at any time

• A vehicle can be added to or removed from the system

• A vehicle can be suspended for maintenance or other reasons

• The system should be able to report on vehicle movements over a given period - day, week, month

• The system should be able to report movements of a specific vehicle over a period or on a specific occasion

• The system should be able to report activity from a nominated dispatch centre

• The system should be able to report activity to a nominated region

System Analysis

Stakeholders

Below is a list of the major stakeholders associated with the ERMS.

-   N.S.W Citizens/Callers

-   N.S.W Emergency Phone Operators/Dispatchers

-   N.S.W Emergency Vehicles/Services
         Accident Response Team
         Ambulance
         Bushfire services
         Fire Brigade
         Police
         State Emergency Services

-   Head of N.S.W Dispatch Stations

-   N.S.W State Government
         Emergency Management Committee
         Public Servant

-   Roads and Traffics Authority (RTA)

-   Software Architects/Developers
         Administrator
         Database Management
         IT Support
         Network Developers
         Project Managers
         System Designers
         Software Developers

Stakeholders Narratives

Narratives highlighting the stakeholders, their persona, and their involvement/impact with the ERMS.

Accident Response Team

Ham Samson has 10 years of experience working in the Accident Response Team for N.S.W, based mainly around the localities of Cronulla. With his vast experience, he has acquired a photographic memory of the geographic layout of Cronulla and surrounding regions. He shows passion and dedication to his work.

With the introduction of an improved emergency response system, ERMS, Ham is now able to navigate to regions unknown to him before. For this, he relies heavily on the availability of the system to point him in the correct direction to the emergency scene.

Administrator

Kenneth Polaski is a 25 year old highly experienced man who just discovered a new job vacancy has just come through from his recruitment agency in his field of interest in system and network administration. He would be going for an interview with the N.S.W State Government. After the interview process he was notified by phone that he is suitable in maintaining the ERMS and their users.

Kenneth's role will be to ensure the integrity of all data coming into or out of the ERMS. Additionally, he is primarily concerned with the amount and level of access to the system, he has raised this issue to the T5 development team on a number of occasions.

Head of NSW Dispatch Stations

Thomas Thornebroke-Hemmingway is 56 years old and has been working as the Head of Dispatch Stations for the last 7 years. He was promoted from Head of Ambulance Dispatch because of his effective management and cost cutting skills. He is now hoping to further cut costs and help consolidate the operations of the emergency services by implementing a new, cutting-edge automated system. Moreover, the system shall aid Thomas in analysing the effectiveness of the system itself, being able to provide historic statistical data and reporting at the instant push of a button.

Thomas realises the need for the new advanced system to be always operational, easy to manage and definitely be scalable. If any of the aforementioned fails, Thomas could be at the forefront of politics and an easy target for a scapegoat.

IT Support

Gazumpta Inglebourne is a recently graduated IT student. She has been in the work force for only 8 months and is still adjusting to her new lifestyle. She is enthusiastic, hard-working and motivated. She currently works providing technical support for projects developed by T5. She spends most of her time on the phone to previous customers debugging minor technical issues, such as rebooting servers and fixing network connectivity issues. She will also be providing technical support for the ERMS once it is functional.

In order for Gazumpta to provide the necessary support for ERMS, she has posed several issues of importance to T5's development team: "ERMS should be easy to use, easy to navigate, be up at all times and not able to be accessed in a way which can cause risks to the system."

Network Developers

Bruce Nassir is part of a team of developers responsible for maintaining communications between dispatch stations, as well as dispatch stations and emergency service units.

Bruce already finds his current tasks of maintaining such a primitive emergency dispatch system extremely difficult. He hopes that the ERMS will provide an easy and more flexible means of maintenance while still holding itself together without any security flaws.

NSW Ambulance

Timmy Walker has been working as the chief and head of Sydney CBD's Ambulance Station, located approximately 2km from Royal Prince Alfranklin Hospital, for almost 14 years. His daily activities include the overall co-ordination and management of the station's resources and overseeing all ambulance dispatch events. The thing about Timmy is that he is a control freak and a perfectionist, he likes to be informed about anything or everything at all times.

Timmy's central concern is the impact in which the ERMS will have on his daily normal activities. He sees the ERMS as a bit of a threat and seeks to have some sort of access and say in the running of the ERMS.

NSW Bushfire Services

Red McCoy was responsible for committing arson in rural bushland in early '97. After his arrest, the Court sentenced him to join the NSW Rural Fire Service.. apparently they thought it would be a comical punishment.

Having served out his sentence in the NSW Rural Fire Service, Red decided to continue on to build his career in this field. Since he is only needed during the majority of the bush fire season (Summer), Red is not overly concerned about the status of the ERMS during the off seasons. Due to his past history, Red still takes pleasure in causing problems for others, however he keeps this under wraps.

NSW Citizens/Callers

Greg Treebourne is a mild mannered, quiet under-achiever. His wife of 8 years left him 7 months ago after an extended relationship break down causing them both much distress and resulting in him turning to alcohol for support. Greg has worked in the escalation department for Chubb Security for the last 12 years and his recent personal life troubles have resulted in him giving sub-par performances at work.

It is Gregs resposibility to contact the relevant emergency department in case of an emergency with a Chubb Security staff member. In order to get effective help for his colleagues, he endeavors for the ERMS to provide quick and timely response times.

NSW Emergency Phone Operators/Dispatchers

Andrew Lopan is in his fifth year of his internship program as an Emergency Phone Operator, at the local Emergency Call Centre. His tasks involve recieving emergency calls regurlary, which he then transfers onto the required department. Soon he will be finishing his internship, where he would become a full time employee.

Over the years that Andrew has been an Emergency Phone Operator, he has had to manually consult a list of authorities in an excel spreadsheet to locate the most appropriate department to dispatch for emergencies. The dawn of the ERMS has meant that the scope of Andrew's work previously has been cut down dramatically. He no longer needs to rely on a static list, however he is concerned with any technical training that might be attached to the ERMS. Having the majority of tasks automated, Andrew questions the longevity and reliability that comes with such a system.

NSW Fire Brigade

Ron Smith is in his late 60s and has been put in charge of 5 fire stations in his district. One of his main roles is to ensure there are sufficient resources to meet the district's needs 24/7. Because of lack of funding, he is finding that it is increasingly difficult to meet the state's demand. Ron has been promised that the ERMS would cut down on the number of administrative staff required to across all his 5 fire stations, as well as co-ordinate his district more effectively.

Ron has never trusted computers, and hopes that this system does not create more problems for him and his under-funded stations.

NSW Police

Jenny Jack is a recent recruit to the Holroyd City Council Police Department. She has just been transferred from Western Australia. Her main duties includes reporting to emergencies and following up on reporting. However, as she has just been transferred, she has little knowledge of streets and finds it difficult to attend to emergency scenes - even though she has been shown around by her new partner Jonathan Sand.

Due to Jenny's unfamiliarity with her surroundings, she is placing all her trust in the ERMS to provide her with the most efficient and closest route to emergency scenes.

NSW State Emergency Management Committee

Hugo First is a government minister on the emergency management committee. His team is funding and monitoring the development of the ERMS system. Hugo's main concern is the lack of visibility on emergency vehicles and its activities on an everyday level. Hugo wants to know the utilisation of various police, ambulance and fire services. He also wants to know whether various districts are overworked or underworked. He hopes the ERMS would give him the data so he could understand the the state's emergency service requirements and make informed policy recommendations to his team.

NSW State Emergency Services

Seven Elfen is an 18 year old single woman who recently volunteered for the S.E.S after just finishing her Higher School Certificate.

As a S.E.S personnel, she is one of many in her elite group responsible for responding to unprecedented events and providing additional aid to already dispatched emergency respondents. For Seven and her colleagues to respond effectively to any emergencies, the ERMS should never be offline unless for critical updates and the relevant users are notified within an appropriate time frame. Furthermore, should the system be offline, it should not be down for more than 30 minutes.

Project Managers

Joe Pow, going on to 44 this year, has been working for Robot Future Pty Ltd for the past 15 years. Joe Pow is one of two distinguised project managers at the company. He has been involved in directing and managing numerous projects, with a track record of 31 successful jobs from having taken on 35 jobs. Having exhausted all opportunities at Robot Future, he is looking to expand his expertise and knowledge, and hopes to further his successful track record. Intrigued by T5's proposal of a new technological breakthrough in managing emergency services, Joe takes the helm of the project hoping to ride out the huge potential publicity the new system has to offer.

Like all project managers (those which are competent), Joe has extremely stressed the point that the system be reliable and in order to establish this, the system must be tested at all angles.

Public Servant - NSW State Government

Robin Banks is a public servant working for the state government. She has recently been transferred to assist the State Emergency Management team. Due to her statistics background and analysis skills, she has been placed in charge of collecting state-wide statistics regarding resourcing, utilisation, and performance of all emergency services.

Robin and her team currently has to manually consolidate data from all emergency services which takes months. She hopes the ERMS will give her the data she needs so her team can spend more time data mining rather than collecting data.

Roads and Traffic Authority

Edwind Mosfern is an average worker who watches over the intersections of the roads in N.S.W using the Sydney Coordinated Adaptive Traffic System (SCATS). He has been known to notice the slightest changes in traffic and is considered for a leading position. His current protocol is to contact the local district emergency dispatch centre if he notices any critical situations whilst performing his regular monitoring activities.

The deployment of the ERMS does not have a significant impact on Edwind's current protocol, however he still reminds the T5 team that from the point of raising the emergency to dispatch and to arrival should be as fast, if not quicker, than what the current system is capable of.

Software Developers

Abby Dollar has spent 5 years in the IT industry, designing and implementing solutions which incorporate databases and websites for DWDesign. She has been heavily involved in politics since 1998 and is a 2003 software engineering graduate with first class honours from UTS. Having heard about the new improvements to redevelop NSW's emergency response system, she has acquired a position in T5's development team.

Abby hopes to bring her relatively up-to-date expertise and knowledge to the T5 team. She stresses that: "... in order for any system or solution to survive in today's modern world which is highly susceptible to changes, it must carry its weight on three things. That is, first and foremost scalable, secondly reliable, and in order to realise this it must be rigorously tested. Too much testing is never a bad thing."

System Designers

Jeremy McPastry is a senior software designer. He has been involved in the design and development of numerous software projects over the course of his career. His visionary design skills have aided him in a well known name in the industry and have secured him many high paying contracts. Jeremy will be involved in the earlier design phases of this project and will help to break down the project from a problem statement into a tangible model which can be further decomposed into smaller tasks to be completed by the junior staff.

Jeremy takes his solution designs very seriously, he is occasionally awaken in the middle of the night upon discovering an amazing breakthrough in his dream. Jeremy centers his designs around a solution which is maintainable, testable and finally usable. After all, what is the point of a system which cannot be used properly.

Usage Narratives

Narratives describing the system's functionality.

Database Management

Narrative 1

After constantly lodging appeals to the NSW State Government and the backing of the NSW State Emergency Management Committee, Ron has been able to secure some extra funding and resources for his district. This has enabled the purchase and operation of a new Fire emergency vehicle. In order for this vehicle to be part of the ERMS, Ron logs into the ERMS system with the appropriate credentials. After this, he is able to view a list of all emergency vehicles and create an add request with the details of the vehicle and service type.

Narrative 2

Timmy has been recently notified by one of his employees that their Ambulance emergency vehicle requires some maintenance after acquiring a mileage of 100,000km. With this information, Timmy accesses the ERMS and creates an update request (i.e. append Suspended status) for the required vehicle.

Emergency Phone Operators/Dispatchers

Andrew arrives to work, logs onto the system and awaits for an emergency call. Soon enough a call comes in from Greg, where Andrew requests the type of emergency service; Fire, Ambulance, or Police, the location and the active emergency. He then enters a service request into the system and identifies the nearest idle Police emergency vehicle in the area for him to dispatch to the emergency scene.

Emergency Vehicles

Jenny and Jonathan are highway officers who are constantly on the move on the streets of NSW. Through the in-car computer, they soon receive contact from Andrew advising them of an active situation and corresponding location. The best route for the officers to attend to the emergency scene is determined. Using this information they can quickly assess the situation and arrive in a timely manner.

Head of Dispatch Stations

Mr Thornebroke-Hemmingway is receiving pressure from his superiors to cut running costs at the new emergency call centres. He is able to use the ERMS to pull up logs of how much work the employees are doing at their workstations. Using the data produced by the system he works out that 4 members of the team aren't pulling their weight and he is now able to talk to them and tell them to lift their game or move on.

IT Support

Gazumpta has received a call from one of the emergency call centres to tell her that some of their emergency phone operators are experiencing slow response times at their operating stations. Gazumpta follows the documented troubleshooting procedures which involve checking the status of the system to ensure all interfaces and devices and working properly and examining log files produced by the system for any unusual entries. Following the procedures Gazumpta is able to narrow down the problem to one of the servers having networking problems.

Management Reporting

Narrative 1

Ron suspects that a number of his employees are inappropriately utilising the Fire Brigade's resources by joyriding and making unnecessary visits. To either confirm or dismiss this suspicion, he logs into the ERMS database via the ERMS user interface, and generates queries to see historical logs of all movements made by Fire emergency vehicles within the last month.

Narrative 2

Ron has been very conscious of his departments budget. He has noticed that one of the fire trucks in one department is using 20% more fuel than any others, which is completely unacceptable as far as he is concerned. Even though he is not overly comfortable using a computer he is able to log into the new ERMS system and navigate to the reporting section. He is able to narrow down the display to only show only the paths which the suspect fire engine has taken and he is able to show different time periods such as hours, days and weeks. By examining the displays he is able to determine that the fire truck is making daily trips to the McDonalds in the next suburb.

Narrative 3

Crime rates are skyrocketing all over N.S.W and the public is calling for justice and action from the Police force. This has been directly attributed to the previous primitive emergency response system. In response to the public scrutiny, Robin is now able to log into the ERMS and execute queries on specific regions of N.S.W to examine "hotspots" (via coordinates) - that is, those areas where Police emergency vehicles are dispatched to often. With this information, she will be able to provide the necessary statistics for further analysis and eventual recommendations.

Quality Narratives

Narratives describing the system's main attributes.

Reliability
Description: The system is dealing with emergencies, it must be highly robust due to the criticality of many emergency calls.

Kenneth, whilst undergoing his hourly task of checking the overall status of the ERMS, realises that a certain emergency vehicle had been dispatched twice to two different locations at times which are humanely impossible. He contacts the emergency vehicle in question to examine the details of events. Kenneth comes to the conclusion that one of the entries is an error, during which he attempts to erase the record the system crashes and is offline for approximately an hour.

During this hour, an unprecedented electrical storm brews over central Strathfield, knocking down a number of trees and consequently power lines leaving hundreds of homes without electricity. A number of citizens in distress call the local Emergency Centre whereupon Andrew is forced into manually consulting his primitive excel spreadsheet for the appropriate State Emergency Services. For Andrew to get help effectively for the citizens, the ERMS should always be available, that is have constant uptime, and in an event of an unprecedented offline the system should be able to recover its data and ensure its integrity.

Real-time Responsiveness
Description: The system must have accurate information on all emergency vehicles and resources at all times. Emergency operators need to have up to date information on state emergency resources in order to make appropriate dispatch decisions.

Whilst going about his daily duties of monitoring the status of several Chubb Security vans, Greg notices a silent alarm had been triggered for a van located on the boundary between Concord and Strathfield. Highly experienced that he is, he is aware that there is an attempted robbery in progress. With no time to waste, Greg quickly notifies the nearest Emergency Centre for immediate assistance.

Andrew is the operator responding to the call and is quickly brought into action. He knows that every second counts and must consult the ERMS to dispatch an appropriate emergency service and/or vehicle to the scene (when we say appropriate, we mean the correct emergency service type and those which are closest to the scene). In order to do this in the most effective and least amount of time, the ERMS must be relatively "live" - that is to consistently contain data that is most recent.

Factors Influencing Required Quality Attributes - Many factors contribute to the quality needs of the ERMS. Through the quality narratives we came up with the following factors

- Lifetime of the system - This system will represent a significant investment from the state government. The state government intends to use this system for the next 15 years at minimum in order to justify its cost. All estimates and load calculations need to also consider the increased load of the ERMS due to population growth.

- Criticality The system needs to support callers in emergencies. This greatly increases the criticality of the application hence affecting the required architecture. All estimates and forecasted usage patterns should be met with a safety factor to ensure smooth operation at all times. A safety factor of 5 will be applied to all forecasted usage patterns and loads.

- Processing Demand The processing demand on the ERMS will be very high due from ongoing emergency requests of the entire state of NSW. The emergency requests would also arrive at the system aperiodically and in bursts. This is particularly true in state-wide emergencies such as during bushfires, hurricanes or possible terrorist attacks. Due to the critical nature of possible calls to the ERMS, the system must be able to handle all requests without failure. Emergency phone call-handling is out of the scope of this system so will not be discussed.

Another factor to consider is the number of emergency vehicles which require their location to be reported. The number of emergency vehicles and the required frequency of its location update will play a large role in determining the eventual architecture of the system. It is estimated that there will be up to 20,000 emergency vehicles in operation when the system needs to role out. The system will also need to account for growth in demand.

Performance Demands - Reasonable response time - - The system needs to respond to requests within 3 seconds. any more than this will be considered unresponsive - Emergency Request Throughput - The population of NSW is currently around 7 million. While it is possible for the entire state to call at the same time, this is a highly unlikely scenario. If the entire state is in emergency, requests will be spread out. A system able to handle 100,000 emergency requests a second will be sufficient to serve the state of NSW. After applying the safety factor, the system will need to support 500,000 emergency requests.

- Vehicle location update frequency - The location of the vehicle will help the operator make a decision on which vehicle to dispatch. For this purpose the system does not require the exact location of the vehicle, rather it requires a rough indication of its location in a 1km radius. For this reason the system will require location updates twice every minute or every 30 seconds. A configurable update frequency may be possible as an extension of this project but is out of the scope of this project.

- Capacity - The system will be recording all vehicle movements from up to 20,000 vehicles every 30 seconds.this equates to 57.6 million vehicle location records a day. Because every record is required for reporting, discarding records is not an option and must be stored either in summary form or archived. An ongoing archiving, summarisation and flushing of old data is required to keep the system responsive.

Dependability Demands The ERMS needs to serve the state's residents at times of emergency 24/7. For this reason it must have extremely high reliability. Mean time to failure must be over 15 years, the projected lifetime of this system. Due to the critical nature of information being stored, the system must also have high data integrity. Information stored in the system will be used to service emergencies. Any data corruption or improper alterations of data cannot occur. This means data integrity checks will be required.

IN the event of a shut down or halting failure, the mean time to repair must be short.

Factors - availability - The system needs to be available 99.99966% of the time (6 sigma) - relability. The mean time to failure (MTTR) of the entire system must be over 15 years due to the critical nature of the system - maintainability - The mean time to repair must be under 1 hour. After applying a safety factor, this should be under 12 mins. - data integrity - value failures while important are not critical to the system operation. An md5 check on incoming request will eliminate any chances of data corruption during transfer and storage

Security concerns - due to the fact that the project is a government funded, care must be taken to provide proper security to the system. In the case of the ERMS, the most critical security concern is the unauthorized use of resources and its subsequent affect on availability. unauthorized requests to the system can open up the possibility for denial of service attacks, with the potential of crippling the entire ERMS system with unauthorized requests.

Factors - authentication is required for system usage. - the ERMS system should be protected from denial of service attacks.

Contextual Factors

Contextual factors define what is physically, legally, economically and socially feasible in terms of the supply of products and services from a resource.

Economical

Constraint: Due to the increasing prices of goods and services, the NSW Government are strictly budgeted for the project to be developed. It is important that the project does not exceed this budget.

Enabler: With the budget at hand, the system can be promptly produced and provided to the public. The expenses and costs of co-ordinating and operating the current emergency system in place will be significantly reduced.

Risk: A change in the NSW Government's structure will affect the amount of funds and support being provided to the development of the ERMS.

Marketable

Constraint: Competitors may arise to match the functionality of the system and implement it into other states. This would cause Team T5 to lose it's share in the Australian Market.

Enabler: After implementation of the ERMS into the state of NSW, it is more likely for other Australian States to adopt and implement the solution into their environment.

Risk: Upon completion of the NSW-based system, competitors with similar systems but advanced/different features are bound to arise. This could create a major loss financially. Furthermore, the NSW Government would likely switch to the competitor's system.

Organisational

Constraint: The size and complexity of the existing structure must be understood in order for the ERMS to meet the needs of the stakeholders.

Enabler: The backing of the Government in the development of the project is evident.

Risk: Implementing the new system can cause existing personnel headaches when adapting to the new structure and processes.

Political

Constraints: Acquiring rights from the NSW Government to allow tracking of emergency service personnel may impede the project.

Enabler: The NSW Government is under pressure to deliver the ERMS successfully and on budget due to recent debacles with the state rail system and power selloff.

Risk: Possibility of breaching privacy laws due to the monitoring of emergency vehicle movements.

Schedule

Constraints: Due to the varying working hours of contractors within Team T5, time has become a factor that separates each contractor. This would result in different meeting and development times which could slow down the progress of the project.

The limited time resource from contractors in T5 is also a major constraint. Proper planning is crucial to ensure time is not wasted.

Enablers: Pressure from the tight schedule may motivate contractors to work more productively.

Risks: Failing to meet deadlines may cause the NSW Government to scrap the ERMS. This will also affect the reputation of T5.

Social

Constraint: This project has a strong social impact on the public and their emergency needs. People rely on emergency services and require them to be very reliable. If this new system does not meet or exceed the current systems reliability and efficiency from a civilians perspective then the project has been in vain.

Enabler: The capability of increasing the number of emergenices undertaken and overcomed efficiently and effectively in a timely manner could eventually create more profits.

Risk: With every system, there is a risk in the implementation process as well as providing the system to the general public, in a case of whether the public will deem the system as a privacy invader and/or unrealistic.

Technical/Technological

Constraint: The system is relying on the GPS to be highly attentive with fast reaction times on actions/turns as well as being upto date with the state maps. Furthermore, the system's run time durability and the ability to calculate thousands of route is highly noted.

Enabler: Advances in GPS and wireless communication would provide a gateway to the connection and development of the ERMS.

Risk: Relying heavily on transmitting electronically the details of the emergency to vehicles/stations could be fatal as the link between the transmitter and reciever could drop out, causing emergencies to be missed.

Conceptual Architecture

Initial Overview

Revisions

Conceptual Architecture - Revision 1

Conceptual Architecture - Revision 2

Current Revision

We have realised that this ERMS system will need to be decomposed into three smaller separate programs. Each of these programs will have a particular responsibility and will use communication protocols (which are yet to be decided) to maintain communication with the other components. The three components are the "Dispatch Client", the "ERMS Core Server" and the "In Vehicle Client".

The ERMS core server will be a Java application which will act as the core server for this system. Only one instance of this application will be running to service all of the NSW region. It will have to be installed on a powerful server running from a central location with a fast network connection. This application will act as a central point of communication for all the dispatch and in vehicle clients. It will act as an abstraction layer for retrieving data from the datastore which is carrying all the relevant data for the functionality of this system.

The dispatch client will be a Java client which will run on the work station of each emergency phone operator. This client will act as an interface for the emergency phone operator into the ERMS system. It will communicate with the ERMS core server over the network to gather the necessary data from the datastore. The client will be used to open new service requests and search for vehicles close to the desired location. It will use its connection with the ERMS core server to send dispatch messages to the in vehicle clients. It will also be used for managers to view reports generated by the core server.

The in vehicle client will be an embedded system installed in each of the emergency vehicles. We imagine that the physical design of the embedded system will be similar to current GPS systems. It will also have similar functionality, it will be able to determine its own current geographical location and to map routes between two locations so that the drivers can navigate efficiently to their destination. However it will also be able to perform two way communication with the ERMS core server to provide updates of its current location as well as receive dispatch information. This application will also be written in Java as Java is highly portable and especially useful for use in embedded systems.

Elaborated Overview

Revisions

Conceptual Architecture (Stereotype) - Revision 1

Current Stereotype View

Refer to Section 4.2.2 for discussion of components and responsibilities

Responsibilities

Dispatch Client

The Login Screen will be what emergency phone operators, managers and administrators first encounter when they open up the application. It will simply prompt them for their userid and password and then send this data to the server for verification. If the verification fails they will remain at the login screen, otherwise they will be taken to the next screen appropriate to their user type.

The Operator User Interface is what the emergency phone operators will spend most of their time interacting with. It will act as a root screen for a logged in operator and provide them with links to other relevant sections such as locating and dispatching an emergency vehicle.

The operator will use the Open New Service Request UI whenever they take a new call. Using this interface they can enter in all the relevant data, this data is sent across to the server and stored in the database.

The Vehicle Locate/Dispatch UI will be used to find the nearest emergency vehicle to the required location. The operator will enter in the geographical location needed and a request will be sent to the server. The server will return a list of the nearest relevant emergency vehicles which will be displayed to the operator. The operator will then be able to select which vehicle they want and a dispatch request will be sent to the vehicle via the server.

The Management UI will be available only to the manager and administrator user types. This interface will contain links to either the report viewer section or add/update/delete section; this will be dependent on the user type.

The Report Viewer UI section will be able to be navigated by both manager and administrator user types. It will be responsible for showing reports, generated by the server, based on user input. Management and administration will be able to choose from a list of reports with each report showing different data.

The Add/Update/Delete Vehicle UI section will again be allowed to be navigated by administrator and manager user types only. This section will allow for the adding or removing of emergency vehicles into the server, updating static vehicle details, and marking vehicles as being in for maintenance.

ERMS Core Server

The ERMS Core Server will contain datastores which the system needs. This includes the Credential Datastore which will be used for authenticating users when they initially log on to the system. Moreover, the credential datastore will be used to distinguish the level of access to the different interfaces/sections of the dispatch client.

The Case Datastore will store all the details about all cases which have been opened, this includes closed and resolved cases which are kept for reporting purposes. It will contain details such as the time the case was opened, who opened it, the time it was closed and more.

The Vehicle Datastore stores information about all the emergency vehicles in the system. It will be used in report generation as well as used in assisting when searching for vehicles to dispatch.

The Location Polling is used to communicate with the emergency vehicles. It will be using a communication protocol to contact the vehicles and request their current location. The server will ask each of the cars for their location and then store it in the vehicle location datastore. It will most likely poll all the vehicles in a round robin fashion so as not to overload its receivers by receiving too many locations at once. The frequency of the polling action must be relatively high to ensure a real-time response, however too high a frequency will cause performance issues.

The Vehicle Location Datastore is where the current location of the emergency vehicles will be stored. It will be used to find the locations of the closest vehicles. It will have to store all historical locations (for all vehicles) as well for reporting processes.

The Dispatch Datastore is used to store details on all vehicles which have been dispatched. It will store data on all dispatches which have been made, effectively creating a historic repository, again mainly for reporting purposes.

The Report Generator is responsible for receiving report requests from the dispatch client and then executing the necessary commands to the datastore(s) specified in the request. Essentially, the report generator will manage, produce, and format the necessary data whenever report requests are made by the system.

The Database UI is responsible for the overall maintenance of all datastores contained in the ERMS Core Server. This UI will only be accessible by the administrator user type. Here, the administrator will be able to perform tasks which are specific to him/her as required for the smooth running of the ERMS.

And finally the Contact Vehicle module will make contact with vehicles when a dispatch is made. It will send them all the relevant data that they need, including their destination location (point of emergency).

In Vehicle System

The GPS Module will interface with the GPS Interface which will be able to communicate with the satellites to determine its current geographical location. The GPS module will use this location to tell the core server where it is.

The Request Handler module will take in communications from the core server and parse it. It will primarily take in the emergency location from the request and feed it into the Miracle Routing System interface which may be a version of software such as "Google Maps" or "WhereIs".

The Vehicle UI will be the in car display which the emergency vehicle operators will use to navigate to the required location. It will show a map as well as possibly some other information such as summaries of the case which they are attending.

Use Case Maps

Add/Update emergency vehicle

Usage Narrative:

• Database Management Narrative 1 (DMN1)
• Database Management Narrative 2 (DMN2)

Preconditions:

1. The user has already gained access to the ERMS via the dispatch client by inputting their userid and password on the LoginScreen.
2. The user has been authenticated as being either a manager or administrator user type. This is done through communication between the LoginScreen and the Credential Datastore.

DMN1 Details:

1. Upon successful authentication, the user is taken to the Management UI. Here they will be given two options; "go to ReportViewer UI" and "go to Add/Update/Delete Vehicle UI".
2. The user clicks on "go to Add/Update/Delete Vehicle UI".
3. The user is taken to a screen with a list of all emergency vehicles present in the ERMS, this list is produced by the interaction with the Vehicle Datastore on the ERMS Core Server. Additionally, the screen will contain links to "add", "view/edit" or "delete" the vehicles. The "view/edit" and "delete" options will be located to each vehicle.
4. The user clicks on "add".
5. The user is taken to a screen with a list of empty fields that correspond to all necessary attributes of an emergency vehicle.
6. The user enters in all the mandatory fields and clicks on submit. The details will be relayed and stored into the Vehicle Datastore.
7. The user is taken to the root "go to Add/Update/Delete Vehicle UI" screen where they can then view the vehicle they have just added, alongside all other vehicles.

DMN2 Details:

1. Upon successful authentication, the user is taken to the Management UI. Here they will be given two options; "go to ReportViewer UI" and "go to Add/Update/Delete Vehicle UI".
2. The user clicks on "go to Add/Update/Delete Vehicle UI".
3. The user is taken to a screen with a list of all emergency vehicles present in the ERMS, this list is produced by the interaction with the Vehicle Datastore on the ERMS Core Server. Additionally, the screen will contain links to either "add", "view/edit" or "delete" the vehicles. The "view/edit" and "delete" options will be located to each vehicle.
4. The user clicks on "view/edit" for the specific vehicle.
5. The user is taken to a screen with a list of fields that correspond to all necessary attributes of an emergency vehicle. The fields are populated from the selected vehicle, this pre-population is again produced by the interaction with the Vehicle Datastore.
6. The user can then overwrite any of the fields, except the vehicle's mandatory unique identifier. The user changes the vehicle status field from active to inactive and clicks on submit. The details will be relayed and stored into the Vehicle Datastore.
7. The user is taken to the root "go to Add/Update/Delete Vehicle UI" screen where they can then view the vehicle they have just edited, alongside all other vehicles.

Possible issues:

• While updating a vehicle, there could be synchronisation problems between the time of pre-population and actually executing the submit request. E.g. What could happen if the vehicle was deleted within that time period
• While adding a vehicle, there could already be an identical or redundant entry of that particular vehicle. There must be some sort of checking in place to prevent this type of event from occurring.

Open new service request & locate vehicle

Usage Narrative:

• Emergency Phone Operators/Dispatchers (EPO)

Preconditions:

1. The user has already gained access to the ERMS via the dispatch client by inputting their userid and password on the LoginScreen.
2. The user has been authenticated as being an operator user type. This is done through communication between the LoginScreen and the Credential Datastore.

EPO Details:

1. Upon successful authentication, the user is taken to the Operator UI. Here they will be given one option; "go to Open New Service Request UI".
2. The user clicks on "go to Open New Service Request UI".
3. The user is taken to a screen with a list of empty fields that correspond to all necessary case details (i.e. Description, Date, Time).
4. The user enters in all the mandatory fields and clicks on submit. The details will be relayed and stored into the Case Datastore.
5. The user is then taken to the Vehicle Locate/Dispatch UI.
6. The required case details will be relayed to the Vehicle Location Datastore.
7. The user is then displayed with a list of vehicles to select and dispatch.
8. The user selects the closest emergency vehicle.
9. Meanwhile, regardless of any event triggers, the Location Polling module is constantly cycling through each vehicle from the Vehicle Datastore and retrieving the vehicle id.
10. Using the id, it then communicates with the GPS Module attached to the vehicle.
11. The GPS Module will send back the coordinates of the specific vehicle to the Location Polling.
12. The Location Polling will relay and store the data to the Vehicle Location Datastore.

Possible issues:

• There could be synchronisation issues with the actual location of the vehicle since the location polling does not poll all the vehicles at every moment.
• The process from creating a new request to locating and dispatching an emergency vehicle is sequential. Perhaps introduce a navigation so the user can execute locate requests at anytime for monitoring purposes.

Dispatch vehicle to an emergency location

Usage Narrative:

• Emergency Vehicles (EV)

Preconditions:

1. The user has already gained access to the ERMS via the dispatch client by inputting their userid and password on the LoginScreen.
2. The user has been authenticated as being an operator user type. This is done through communication between the LoginScreen and the Credential Datastore.
3. The user has already lodged a new service request into the Case Datastore via the Open New Service Request UI.
4. The user has located the appropriate vehicle.

EV Details:

1. After selecting the vehicle, an option to dispatch will be displayed to the user.
2. The user clicks on dispatch which will invoke the Contact Vehicle module.
3. The Contact Vehicle will take the relevant details sent over from the dispatch client and store it in the Dispatch Datastore.
4. Simultaneously, the Contact Vehicle will relay the details of the case (the coordinates of the emergency and other information) to the RequestHandler of the InVehicle System.
5. The RequestHandler will poll the GPS Module for the vehicle's current position (coordinates).
6. With the information gathered from the GPS Module and the case details sent from the server, the most effective route is determined (externally by the miracle routing system) and displayed to the Vehicle UI.

Possible issues:

• The fact that the dispatch client has to send over all the details to the Contact Vehicle for each dispatch request is unnecessary overhead. Perhaps the dispatch client could just send the case id, then the Contact Vehicle can use this to communicate with the Case Datastore to obtain all relevant information.
• At the moment, there is no clear indication of how feedback from the vehicle will be handled or given back to the operator.

Generate a report on vehicle movements

Usage Narrative:

• Management Reporting Narrative 1 (MRN1)
• Management Reporting Narrative 2 (MRN2)

Preconditions:

1. The user has already gained access to the ERMS via the dispatch client by inputting their userid and password on the LoginScreen.
2. The user has been authenticated as being either a manager or administrator user type. This is done through communication between the LoginScreen and the Credential Datastore.

MRN1 Details:

1. Upon successful authentication, the user is taken to the Management UI. Here they will be given two options; "go to ReportViewer UI" and "go to Add/Update/Delete Vehicle UI".
2. The user clicks on "go to ReportViewer UI".
3. The user is taken to a screen with a list of all datastores that are able to be queried.
4. The user selects the Vehicle Location Datastore and specifies fire as the emergency service type and the previous month as the range.
5. The user clicks submit and the input is relayed to the Report Generator.
6. The Report Generator creates and executes the specific query against the Vehicle Location Datastore, based on parameters sent over from the ReportViewer UI.
7. The Report Generator formats the results returned.
8. The Report Generator will then send back the processed information in report form to the ReportViewer UI; for the user.

MRN2 Details:

1. Upon successful authentication, the user is taken to the Management UI. Here they will be given two options; "go to ReportViewer UI" and "go to Add/Update/Delete Vehicle UI".
2. The user clicks on "go to ReportViewer UI".
3. The user is taken to a screen with a list of all datastores that are able to be queried.
4. The user selects the Vehicle Location Datastore and specifies the vehicle id, fire as the emergency service type and the previous month as the range.
5. The user clicks submit and the input is relayed to the Report Generator.
6. The Report Generator creates and executes the specific query against the Vehicle Location Datastore, based on parameters sent over from the ReportViewer UI.
7. The Report Generator formats the results returned.
8. The Report Generator will then send back the processed information in report form to the ReportViewer UI; for the user.

Possible issues

• Nil.

Generate a report on activities in a region

Usage Narrative:

• Management Reporting Narrative 3 (MRN3)

Preconditions:

1. The user has already gained access to the ERMS via the dispatch client by inputting their userid and password on the LoginScreen.
2. The user has been authenticated as being either a manager or administrator user type. This is done through communication between the LoginScreen and the Credential Datastore.

MRN3 Details:

1. Upon successful authentication, the user is taken to the Management UI. Here they will be given two options; "go to ReportViewer UI" and "go to Add/Update/Delete Vehicle UI".
2. The user clicks on "go to ReportViewer UI".
3. The user is taken to a screen with a list of all datastores that are able to be queried.
4. The user selects the Dispatch Datastore and specifies a range of coordinates and police as the emergency service type.
5. The user clicks submit and the input is relayed to the Report Generator.
6. The Report Generator creates and executes the specific query against the Dispatch Datastore, based on parameters sent over from the ReportViewer UI.
7. The Report Generator formats the results returned.
8. The Report Generator will then send back the processed information in report form to the ReportViewer UI; for the user.

Possible issues

• Nil.

Data Models

The above Data Model describes the data stored in the ERMS, as well as the relationship between the datastores. The relationships are detailed by the linking of the individual datastores through foreign keys.

Stored Data

Data related to the Emergency vehicles include the type of vehicle (e.g. Fire, Police, Ambulance) as well as the name of the vehicle. Additionally, the status of the vehicle is known, this is needed to identify which vehicles are currently suspended and undergoing maintenance.

Data related to the Operators and Management of the system are stored in the User datastore, this includes their username, password, and role.

Vehicle locations are stored persistently and links a vehicle to its location at a specific time.

The Case datastore is updated when a new service request is open. It holds the ID of the operator who opened the request and timestamp, a description of the emergency and it's type (e.g. Fire), and the location of the incident.

Dispatch information comprises of the vehicle ID that is dispatched and timestamp, the emergency service request it is for, and the operator who issued the dispatch.

Relationships

The Data Model shows the following relationships:

1. A service request (or case) is opened by an individual operator. A operator however may file many service requests.
2. An open service request may have many (or zero) vehicle dispatches corresponding to the emergency.
3. A user can dispatch many vehicles for various emergencies.
4. Each dispatch is of a single vehicle. A single vehicle however can be dispatched many times.
5. A vehicle will have many locations over time.
   

Architectural Justifications

By breaking down the ERMS into 3 logical parts; Dispatch Client, Core Server, and In-vehicle System, we can successfully provide balanced performance and security to the meet the quality needs of our stakeholders.

The separation of the Dispatch Client and Core Server allows the server to be run remote from the client. This means that the server must be accessed remotely and is only possible if the Dispatch Client has validly authenticated the operator. Direct remote access to the Core Server and its datastores is strictly limited to Administrators.

To ensure maximum system availability, Administrators have the ability to enter and update information into the datastores without setting the ERMS Core Server offline.

There are also performance gains by implementing the architecture this way:

• Data validity is checked at the client end. This ensures that the data is in the correct format and all necessary data is given before it is sent to the server. This implementation of 'Design by Contract' reduces the processing overhead of the ERMS Core Server.
• The Report Generator is implemented into the ERMS Core Server to gain direct access to the datastores. This allows the required data to be acquired quickly, processed, and then returned to the Dispatch Client. The Report Generator will only return the required information, i.e. if a report on vehicle movements is requested, the Report Generator will only access data from the Vehicle Location Datastore and the client will not have access to data in the other datastores. This implementation adds a further check to ensure the data is only read and not modified via the Report Viewer.
• The In-Vehicle System will handle the processing of the 'quickest route' via the Miracle Routing System. This reduces the processing overhead of the ERMS Core Server. This will also improve the responsiveness of the In-Vehicle System as it has real-time access to its 'current location' for processing the 'quickest route'.
  

Architectural Issues

Team T5 has identified weaknesses and possible improvements to our ERMS.

• As maintenance of the ERMS Core Server is highly important, Administrators should be given a higher-priority remote connection to perform his/her tasks.
• If the ERMS Core Server goes offline, this will impede all operations of the ERMS. This issue will be dealt in hardware where the server will automatically reboot if a fatal error occurs to ensure minimal downtime.
  

Execution Architecture

Elaborated Concurrent Subsystems View

Dispatch Client
The dispatch client is a user initiated component which makes asynchronous calls to the ERMS service proxy with a callback. This is to relieve the UI thread on the client from locking up everytime a request is made.

ERMS Service Proxy
This component is responsible for making calls to the ERMS service. It executes in a background thread to allow the UI component to continue working. This component is created and destroyed as required by the Dispatch Client and is not always active.

Service Request Handler
The server will be serving many requests concurrently. To allow for this, a thread a needs to be created per request as in a service. Calling the database and in-vehicle services synchronously is acceptable from this component because the call is in its own thread context.

ERMS Database
The database will be serving information concurrently due to all the querying required. Because of this the database has service characteristics.

Location Polling
This component is an on-going process which can be independant from the server process. It periodically gets a list of all vehicles from the ERMS Database, and makes asynchronous calls to the vehicle services to retreive its address. The calls to the InVehicle Service needs to happen asynchronously due to its real-time constraints and the possibility of partial failure. This cannot happen synchronously due to the high probability of time-outs and failures when communicating with the in vehicle system. The successful results of the asynchronous call will be collected entered into the Vehicle Location datastore asynchronously to reduce blocking.

InVehicle Request Handler
This component needs to have service characteristics due to the constant polling from the Location Polling component as well as the possibility of concurrency problems if multiple calls are made at the same time. Due to its service characteristics, the component can safely query synchronously the miracle routing system as well as the GPS system. Updates to the InVehicle client will be made asynchronously. The updates will be picked up by the Invehicle client UI in its own thread.

InVehicle Client
This component is a user driven component which displays information pushed out from the ERMS Server as well as display mapping and routing instructions from the miracle routing system.

Elaborated Deployment View

The ERMS system runs different applications concurrently on many machines.



Dispatch Operator Kiosks
The dispatch operators will share a set of workstations which will typically run a single instance of the Dispatch Client application.

Application Server
The application server will be a powerful server machine which will handle many requests through the ERMS core server application. The core server application will also be sending data to the in-car client to be displayed in car.

A location polling component which will give the system updates on vehicle locations. This will run as a totally separate process independent from the core server application.

Database Server
The database will be frequently hit by requests from the application server concurrently. To assist in scalability, the database will run on a dedicated machine with massive HD read rates.

In-car computer
The in-car computer will typically contain the in-car client of the system. A screen will be built into the vehicle and the computer will be hidden away.

Use Case Maps

Add/Update emergency vehicle

Add Vehicle

Description:

• This use case map describes the process of a manager or administrator adding a new vehicle to the ERMS.

1. The initial callback (green) to the Service Request Handler creates a new thread. This thread accesses the ERMS database synchronously and returns the list of vehicles managed by the ERMS.
2. The second event (purple) illustrates the adding of a new vehicle into the ERMS database with similar characteristics, and renews the Dispatch Client UI with updated list of vehicles for confirmation.

Possible Issues:

• The initial call to the Service Request Handler gathers the list of current vehicles from the ERMS database, however this is additional overhead and affects the performance of the system. It is possible for the manager or administrator to add a vehicle without knowledge of current vehicles. This is a drawback in the conventional UI design to enhance usability; this UI is shared by both Add and Update use cases.
• The Service Request Handler and ERMS Database are vital for this use case. If either fail to function properly, the operation will be unsuccessful.

Recommendations:

1. Make multiple clones of the Service Request Handler and ERMS Database which will run in parallel. If one fails, then we will attempt to make communication with the replications. This allows for multiple points of failure and a more reliable system.

Update Vehicle

Description:

• This use case map describes the process of a manager or administrator updating an existing vehicle's details in the ERMS.

1. Similar to the Add Vehicle use case, the initial callback (green) returns a list of vehicles managed by the ERMS.
2. The second event (blue) is executed when a user selects a vehicle to update. This returns the details specific to that vehicle and shares similar characteristics to the previous event.
3. The final event (purple) corresponds to the second event (purple) of the Add Vehicle use case. This updates the details of the selected vehicle into the ERMS database via the Service Request Handler and updates the Dispatch Client UI for confirmation. This event shares similar characteristics to the previous events.

Possible Issues:

• The second event (blue) returns the details of the specific vehicle. This data is already acquired through the first event and may appear to be additional overhead, however this is necessary to allow managers and administrators to edit the most up-to-date information. Therefore the manager and administrators have more reliable data to work with.
• The Service Request Handler and ERMS Database are vital for this use case. If either fail to function properly, the operation will be unsuccessful.

Recommendations:

1. Make multiple clones of the Service Request Handler and ERMS Database which will run in parallel. If one fails, then we will attempt to make communication with the replications. This allows for multiple points of failure and a more reliable system.

Open new service request & locate vehicle

Description

This execution use case map describes two key events derived from the Emergency Phone Operators usage narrative. These two events are:

The process of creating a new service request entered through the dispatch client by the Emergency Phone Operator. This is then stored in the ERMS Database.(Black)

The process of locating a vehicle, gathered from the database based on longitudinal and latitudinal co-ordinates; +/-100. (Red)

The use case map details the possible issues should a major component fail and recommendations for future references.

Possible Issues

• Dispatch Client failure:
  • The Emergency Operator will not be able to access the ErmsInterface to create a new service request.
  • Located vehicles will not be able to follow back to the Dispatch Client.
• Service Request Handler failure:
  • The ErmsInterface will not able to connect to the Request Handler.
  • Data will not be able to be called from the ERMS Database by the Request Handler.
  • Data will not be able to be passed on from the ERMS Database to the Dispatch Client through the ErmsInterface.
  • Locations of vehicles stored in the ERMS Database will not be able to be gathered by the Service Request Handler to be passed on to the Dispatch Client.
• ERMS Database failure:
  • New Service Requests will not be saved and logged in the ERMS Database due to connection failure between the Request Handler and the ERMS Database.
  • Locations of vehicles will not be retrieved by the Service Request Handler to be forwarded to the Dispatch Client.
  • The New Service Request will be unable to locate a vehicle within a set region.

Recommendations

• It is highly recommendable to backup the ERMS Database into another remote Database to still be able to accept new Emergency Requests.
  
• It is recomended that the Administrator be given access to manually restart the Core Server, consisting of the Request Handler/Database/Location Polling, through the Database interface as well as the Administrator Interface.
  
• It is recomended that the old system is running parallel to the ERMS to allow Emergency Operators to revert to their old responsive skills to emergency requests.
  
• It is recomended that the Database be accessed by the Administrator without having to use the ERMS to manually enter critical data.
  

Dispatch vehicle to an emergency location

Description

This execution use case map describes the key event of dispatching a vehicle or vehicle/s. Notions of reliability and real-time responsiveness quality attributes are discussed in this following section.

In the Dispatch Client, the operator has selected the vehicle/s and executes the dispatch command. This will spawn the ERMS Service Proxy thread which will handle the communications between the Dispatch Client and Service Request Handler. This proxy creation allows asynchronous calls to the Service Request Handler, meaning the Dispatch Client is not blocked. The Service Request Handler will execute a synchronous call, a query to insert data (sent over by the proxy) into the ERMS Database. After this is successful, the Service Request Handler makes communication with the appropriate InVehicle Interface of the selected vehicle/s via the In Vehicle Request Handler component.

This Vehicle Request Handler will then supply the Invehicle Client the details of the emergency asynchronously via the creation of a new thread, this permits the In Vehicle Request Handler to receive any further emergency requests. However, before the Vehicle Request Handler can do this, it must make two synchronous calls to the GPS Interface and Miracle Routing System to retrieve the most effective route.

Possible Issues

- The entire process is dependent on the correct and successful operation of the Service Request Handler. This will create the high risk of the ERMS not functioning properly - that is storing the request details and passing notification to the vehicle - if this component were to go down.

- If the ERMS Database were to go down then the entire process will be blocked as the Service Request Handler creates a synchronous call to the Database. This means that the entire process may only proceed once the details are placed in the Dispatch datastore of the ERMS DB.

- Even though these interfaces are not explicitly apart of the ERMS, if the calls to the GPS Interface and Miracle Routing System fail, this will have a detrimental effect on the notification sent to the InVehicle Client as the calls are synchronous. In other words, there could be no notification given.

Recommendations

1. Make multiple clones of the Service Request Handler and ERMS Database which will run in parallel. If one fails, then we will attempt to make communication with the replications.

2. Make the call to the ERMS Database from the Service Request Handler not blocking, that is make the call asynchronous so the process can proceed without actually storing the details in the ERMS DB.

3. Have a retry functionality when calls are made to the external interfaces (GPS and Miracle). So, if a certain threshold is reached (no. of retries, say 20) then notification will be given to the InVehicle Client without the most effective route. The emergency case details will still be provided.

Generate a report

Description

This use case shows the execution of the system for the purposes of the reporting event. The reporting module is initiated from the dispatch client, makes an asynchronous call to the service request handler (via the ERMS proxy), which then makes a synchronous call to the database. The service request handler will pass back the retrieved data to the dispatch client via the ERMS proxy (this proxy was created on request previously when the client triggers the reporting event).

Possible Issues

- The database may be executing some massive queries, which will add stress on the database, as well as block a thread on the OS while the database system is executing consume.

- Reporting may be unresponsive if a complex query with joins are executed. Depending on the complexity of the query, this may make some reports unusable.

Recommendations

1. Queries executed through the dispatch client should not be too complex, and will also have a timeout of 2 minutes. This will reduce load on the database and keep the reporting module responsive.

2. Complex queries will be required for the system, in order to accommodate for this, a business intelligence layer will need to be built to denormalise and summarise data into a more queryable form.

Architectural Justifications

• The ERMS Database is a central repository for the various datastores mentioned in the conceptual architecture. This organisation allows the ERMS Database to be detached and placed on its own Database Server.
• A connection to the ERMS via the Database UI allows Administrators to remove erroneous data to maintain data integrity.
• Connections made to the Service Request Handler will create a new thread to process its request. This implementation allows the service to manage a large number of concurrent connections efficiently and meet performance demands. These connections are also implemented as asynchronous callbacks to avoid locking of the Dispatch Client UI.
• As described in the conceptual architecture, the Location Polling process will be implemented by a background thread. This will allow it to continue operation without interruptions from the server process and adhere to Real-time Responsiveness contraints. The asynchronous calls to the ERMS database are also implemented to reduce blocking.
• The GPS Interface and Miracle Routing System are external interfaces outside the scope of our project.

Architectural Issues

• To meet with Reliability demands, the ERMS Database will need to be cloned to avoid a single point of failure. This allows connections to be made to other Databases if one fails. The workload could also be balanced across the Database cluster to improve performance. However, this means the deployment of additional Database Servers, and their locations and status will be need to be known by the Application Server.

Implementation Architecture

Elaborated Implementation View

This diagram shows the three seperate applications which will make up the system.

All three of these applications will need to be able to communicate. It is very important that this communication is reliable and secure. The Java secure socket extension (JSSE) is a set of packages that we will be utilizing for communication. The JSSE will enable us to use the TCP/IP protocol with added security features to ensure the integrity of all communication.

Currently the medium used for communication between the ERMS core server and the emergency vehicles is undecided. It is very important to examine all the possibilities closely and weigh up their benefits and constraints before coming to a decision. Some possibilities include using the mobile GSM network or even wireless networks while in CBD locations.

The ERMS core server will be running a MySQL database which will be used to store all the relevant data for our system, including vehicle locations, open cases and authorised users. The Java database connectivity module (JDBC) will be used to connect to the database interface.

Our application components will interact with the JSSE module and the JDBC module to carry out the neccesarry actions for the system to function.

We will be using the Java Swing module to design our interfaces. The swing module will allow us to quickly create highly practical and interactive interfaces for our system while conforming to interface standards which will help minimise staff training time.

The in vehicle client will utilize Java's code portability with the Java runtime environment (JRE) to run on a cut down embedded system. This system could potentially be no bigger than standard GPS modules which are on the market today depending on how many resources are allocated to its development. The in vehicle client application components will also have to interface with the GPS system and the miracle route finder.

Decisions for Component Implementation

Off the Shelf Components

Selecting appropriate off the shelf components can improve the reliability, maintainability, development and deployment of the system. We have decided on using a number of off the self products for our final system.

The off the shelf components which this system requires are listed below:

• PostgreSQL
  • PostgreSQL is an open source relation database software package.
  • It is a highly scalable database system which will be appropriate for accommodating growth in the ERMS system.
  • Completely free and open source
  • Has a number of good administration interfaces.
  • It is extensible.
  • It is optimised for storing and processing large quantities of data, such as the data our system will be storing
  • Ultimately we chose PostgreSQL over MySQL because of its superiour administration interfaces.

• MemCached
  • MemCached is used to reduce database queries by storing common results in physical memory.
  • It is open source.
  • This greatly decreases query overhead times and can improve system performance.
  • Response time is important in our system making this a vital off the shelf product.

• GPS Hardware + Software layer
  • A GPS unit will need to be purchased for each of the vehicles.
  • Developing it in house will be an arduous task and there are many ready made options available.
  • We are yet to settle on a specific GPS unit but we will need to take into a number of factors, including:
    • Cost
    • Ease of integration into the system
    • Reliability

• “Miracle Route Finder” software
  • The route finder will be operating on each of the in vehicle clients.
  • There are many different ready made route finder solutions from a broad variety of companies
  • The software will need to be able to run on an embedded system with limited resources.
  • The software needs to be able to interface with the rest of the in vehicle client.

Revised Elaborated Implementation Architecture

This revised implementation architecture reflects our decision to use PostgreSQL as our database backend and also show our implementation of MemCached. There is a Java module available for MemCached making it very easy to implement into our design. Also, using memCached will only require making minor modifications to our database abstraction layer.

Constraints

There are a number of constraints to be considered in the implementation of this system. It is important that the system is designed to minimise the impact of these constraints to prevent future problems and improve the maintainability and extensibility of the system.

One constraint is reliability vs hardware cost. Hardware can be very expensive depending on the levels of redundancy and reliability required. It is import to assess the expected loads on the servers, the desired uptime and response times to ensure an appropriate server is purchased. For this system the load is not expected to be incredibly high, but reliability and response time is of vital importance. We recommend using a number of lower end servers running in parallel as the server for this system. Having a number of server means that is a couple become unavailable there are still some taking the load. Multiple parallel servers can also increase response time, with appropriate load ballancing the each server will only have to deal with a portion of the requests.

If we use parallel servers we will be able to use lower end servers as each one only needs to handle a portion of the total load, potentially reducing the costs associated with buying a small number of very high end servers.

It is also important that the load balancing between the servers is performed completely transparently from the clients. There are a number of load balancing hardware solutions availble on the market which would be suitable for this project.

Scalability vs cost is another constraint. It is important that this project's implementation architecture allows for future growth. A load balancing server cluster is a highly scalable implementation. It allows for new servers to be added to the cluster with relative ease and minimal cost, improving its load handling capacity.

Architectural Justifications

• The Dispatch Client implemented with Java Swing components will restrict and validate the user's input data before it is passed on to the ERMS Core Server. This ensures data integrity and enhances security against malicious code.
• The SSL connection between the Dispatch Client and ERMS Core Server will ensure a reliable and secure medium for transmission.
• The use of existing Java packages gives support to Software Developers familiar with Java to maintain our code.
• Our elaborated Implementation Architecture illustrates our decision to implement the ERMS with PostgreSQL and MemCached.

1. PostgreSQL will offer performance benefits as the database grows larger in size. This is a consideration over the lifetime of the ERMS as new service requests are made and more vehicles are managed, as well as logging functions.
2. MemCached also offers performance benefits in decreasing query overhead times.

Architectural Issues

• For additional data security, critical data in the database will be encrypted. This has yet to be implemented in our prototype.
  
  

Critique

The executable prototype that was implemented was a clear reflection of T5’s architecture design. This meant that the design was well thought out and feasible. All components specified in the elaborated conceptual view were implemented successfully. However, the prototype did have some minor differences in terms of data flow, actual implementation packages and execution at run time. These differences include:

1. The operation of the ERMS service proxy (called communicator in the prototype) contained within the Dispatch Client component was quite different. The design specifies that this proxy should be created as a new thread on request so to allow the Dispatch Client to continue to be used without blocking (asynchronous). The prototype did not create a new thread but just instantiated a new class each time a new request was made. This meant that the Dispatch Client does not give a response, thus impacting on the real-time responsiveness attribute, and is blocked until the request is served by the Service Request Handler (synchronous).

2. The data flow was different in the prototype from the design, when the Dispatch Client triggers the dispatch vehicle event. Instead of all the currently active case details stored permanently (only until another case is opened) in the Dispatch Client, only the case id is stored. This meant that only the case id was sent over to the Contact Vehicle component whereupon it would retrieve the case details. The design specified that all case details are sent to the Contact Vehicle during the dispatch event.

3. The design outlines the implementation of a transport security layer. The prototype did not use SSL capabilities included in the Java package JSSE.

Overall, the design was sufficient as it was able to be implemented into a working executable solution without any major difficulties. Of the three differences outlined, only the first (1) has a negative impact on the performance of the ERMS. The second (2) difference is beneficial as less data is passed from component to component lowering the risk of data integrity issues. The third (3) difference is not critical to the running of the system, security was not one of the two prioritised attributes of the system.

There are a number of anticipated issues to consider for future milestones. These include:

• The implementation of the SSL capability provided in the Java package JSSE will be a significant step in terms of securing the system. This will impact on any network connections between the three modules.

• The implementation of MemCached will require the database abstraction layer to be modified. This will boost the overall performance of the system in terms of streamlining database queries.

• The actual integration of the GPS component and Miracle Routing System with the InVehicle Client will prove to be a significant step. This will need to be outsourced effectively and interfaced smoothly with the existing components.

Project Tasks Management

All management and schedules will be contained at: Team T5 Management

Instructor comments

Make sure you go through the stakeholder analysis to determine your key quality attributes. 28th Aug Lian