Ambulance Dispatch System (CAD System)

Ambulance Dispatch System (CAD System)

System Design Document

Faisal Azizullah
Brandon Bass
Ali Hashi
Sonali Jejurkar (Team Lead for del-3)
Sirisha Koneru
Ananthapriya Mummineni (Team Lead for del-2)
Shveta Mupparapu (Team Lead for del-1)
Vidya Perumal
Group URL:

Revision History:

Version / Revision Date / Description / Author
1.0 / 06/23/2007 / Initial Draft with template & section 1 / Sonali Jejurkar
1.1 / 06/29/2007 / Section 1 refinement / Sonali Jejurkar
1.2 / 06/30/2007 / Initial draft with all the sections and necessary UML diagrams / Sonali Jejurkar
1.3 / 07/01/2001 / Typo in section 3.5 is fixed / Vidya Perumal
1.4 / 07/01/2007 / Paragraph 2 in section 1.5 should be describing the dispatcher interface / Brandon Bass

1.Introduction

1.1Purpose of the system

The emergency ambulance dispatch system or Computer Aided Dispatch System (CAD) is a web based application that efficiently receives a phone call from 911 services, records the details of an emergency incident including location, finds the next available ambulance and dispatches the ambulance within 3 minutes.

As referenced in the Requirements Analysis Document (RAD) that we submitted as a deliverable 1 and 2, the system throws an exception if the ambulance is not dispatched within 11 minutes range after receiving the phone call from the 911 operator.

1.2Design goals

Identifying design goals is the key step of Design phase in SDLC. In the light of non-functional requirements addressed in the earlier phases we agreed to develop CAD considering following design objectives.

1. Reliability: For 99.9% times LTS will provide accurate map for the incident location and should give correct directions to CAD. Once Dispatcher receives correct information from LTS, it can guide the driver of the ambulance accordingly.
2. Usability: The Dispatcher interface will be very user friendly and system designers will create all the necessary user manuals for easy use of the system.
3. Performance: CAD will be designed to achieve one minute of response time to locate nearest ambulance from the nearest location after submitting location details.
4. Supportability: The system can be extended to identify the nearest hospital from the incident location in the 2nd stage of system development. Also after the go-live of the 1st stage of CAD there will be a team of 5 members to provide the required technical support.
5. Implementation: Since the CAD system will be developed using JAVA and Rational Rose the system designers will have the constraint of having technical experts in this area.
6. Interface: The CAD system interacts with LTS for getting driving directions to the location. Therefore CAD will be compatible with LTS
7. Packaging: CAD is packaged into WAR file.
8. Legal: CAD will be compliant as far as the licenses for the soft wares it uses are concerned.

1.3Definitions, acronyms, and abbreviations

1. CAD (Computer Aided Dispatcher): This is the name given to the software system under consideration.

2. Caller: Is the person who calls the 911 service and asks for an ambulance

3. Operator: Is the person who attends the phone call at 911 services

4. Dispatcher: Is the person who receives the phone call from operator, enters incident information into CAD system, and processes the necessary details for dispatching the ambulance

5. LTS (Location Tracking System): Is the independent software component that accepts caller phone number from CAD and provides location details to CAD. This is a mapping system.

6. System Administrator: Is the person who manages all types of user accounts using CAD and maintains their access privileges.

7. Driver: Is the person who is driving the ambulance.

8. SDLC: Software Development Life Cycle

1.4References

Problem Statement:

Architecture Specification:

Object-Oriented Software Engineering- Using UML, Patterns, and Java 2nd Edition

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2nd ed., C. Larman

1.5System Overview

CAD system’s goal is to provide fastest ambulance service to the victims of any emergency incidents. To achieve this goal the system is decomposed into Operator Interface, Dispatcher Interface (CAD) and LTS Interface. For implementation purpose Operator Interface and LTS interface are beyond the scope of this project. The CAD system assumes the input from Operator Interface, processes it, sends the caller’s phone number to LTS Interface, and receives the location details from LTS.

The Dispatcher Interface is used by a 911 ambulance dispatcher that stores all the information provided by the caller. This information includes address of the incident, number of people injured, number of ambulances required and type of emergency. After processing this information an appropriate incident report is created by this system and sent to the Dispatcher system as an input. The CAD system under consideration is built assuming validated report of an incident exists and is provided to CAD as an input.

The CAD system is designed to locate the available ambulances near the incident location and dispatch them as per the requirement with the help of LTS. We assume that LTS provides incident location and this will be used by CAD, in conjunction with CAD’s internal maps, to derive driving directions. LTS is a highly sophisticated navigation system that provides location details by accepting caller’s phone number as an input. If the caller is located outside the reach of LTS signals then some additional details about incident are expected.

All three interfaces are closely interlinked and with validated inputs to the system interfaces an attempt is made to dispatch the ambulance within 3 minutes range.

2.Current software architecture

Since this project is based on Greenfield engineering we will discuss current architecture of the similar system called MyTrip discussed in course text book. Using this application a driver can plan a trip from a home computer by contacting a trip-planning service on the Web. The trip is saved for later retrieval on the server. The trip-planning supports more than one driver like our CAD system supports more than one caller.

The system is decomposed into 2 subsystems namely RoutingSubsystem and PlanningSubsystem. The PlanningSubsystem is responsible for constructing a Trip connecting a sequence of Destinations. The PlanningSubsystem is also responsible for responding to replan requests RoutingSubsystem.

The RoutingSubsystem is responsible downloading a Trip from the PlanningService and executing it by giving Directions to the driver based on its location. This initial subsystem decomposition and interaction between subsystems resembles to CAD’s subsystem and their interfaces.

3.Proposed software architecture

3.1Overview

This section will mainly address various software components of CAD system. An Operator Interface and LTS Interface are beyond the scope of this course project. The CAD system under consideration is initially decomposed into 2 subsystems called Dispatcher Interface and Ambulance Interface that heavily interact with an external database called Incident Management System.

Incident Management System is a central database storing all the details about an incident entered via Dispatcher Interface and all the vehicle details entered via Ambulance Interface. Both these interfaces independently access the central repository and keep track of all the incidents that might be used for generating reports.

3.2Subsystem decomposition

As mentioned above, the two main parts of the CAD subsystem: the Dispatch information organization part of the system which is responsible to record the details of the incident and via Dispatcher Interface and the Ambulance organization part, in which vehicle details are managed.

For the Dispatch information part, a three-tier architectural style in which a Dispatcher client subsystem provides a front end for users to initiate all Dispatch related use cases (e.g., Enter Caller Information, Track Caller Location, Dispatch Ambulance, Monitor Ambulance) The CADServer subsystem is responsible for access control and concurrency control, and delegates to nested subsystems for the application logic. The bottom tier is realized by the Incident Management system responsible for storing any persistent objects.

For the Ambulance Organization part, client server architecture may not be sufficient for synchronous ambulances in which the action of one ambulance can trigger events for other ambulances within a relatively short time. For simulating synchronous behavior and achieving the goal of responsiveness, we select a peer-to-peer architecture in which Ambulance Interface subsystem provides the interface and AmbulancePeer maintains the state of the ambulances currently on the road and serving the victims.

Following package diagrams make this subsystem decomposition more clear.

3.3Hardware/software mapping

CAD is inherently a distributed system, as users sit in front of different machines, possibly from several different locations. However, we distinguish only between two types of nodes: the UserMachine to provide a Dispatcher user interface and the ServerMachines to run the application logic and storage and, more generally, to provide the CAD services. CADClient and the AmbulanceFrontEndPeer run on the UserMachine. In an installation of CAD with few Dispatchers, all other subsystems can be collocated onto a single ServerMachine. However, to ensure scalability we identify an additional subsystem dedicated to send Ambulance status to the browser and assign the StatusServer, the AmbulancePeer, the IncidenceManagement and the CADServer subsystems to different processes that can run on different ServerMachines.

For the realization of the dispatcher organization part of CAD, we select J2EE framework. J2EE is a collection of interfaces and standards developed by Sun Microsystems and community efforts for developing portable web-based information systems in Java. The advantage of this standard is that it is implemented by several open-source and commercial products, thus enabling a Dispatcher to trade off scale. (e.g., number of ambulances, number of ambulance drivers) for set-up costs (e.g., licensing and run-time costs). Also, in their simplest form, open source components of this framework are easy to install and require little prior administration knowledge.

Consequently, the CADClient is a Web browser and the CADServer and the other dispatcher organization subsystems are accessed through a Web server. To realize the CADServer and related subsystems, we select JAVA Servlets and JAVA Server Pages (JSP), components of J2EE, as the main technology for implementing the boundary objects. Servlets are classes that are located on the ServerMachine, process and respond to requests from a Web browser by generating an HTML page. We use JSPs to realize the boundary and control objects of CAD. JSPs in turn invoke methods on entity objects and storage objects, which are also, realized using JAVA foundation classes. In the following diagram the components on the left side reside on client machine and the components on the right side reside on the server machine.

3.4Persistent data management

CAD deals with 2 sets of objects that must be stored. The first set includes the objects that are created and accessed by the dispatcher organization subsystems and that need to be persistent to track the progress of dispatcher processes. The second set includes the objects that are created and accessed by the AmbulancePeer and the AmbulanceFrontEndPeer during dispatch process and are used to track the status of ambulances while on the road.

The first set of objects is well defined and will probably not change much during the lifetime of CAD. The second set of objects are specific to each Ambulance are defined by the Ambulance developers. All these objects are managed by Incident Management System.

The initial prototype of CAD will use flat files to store persistent objects and will minimize operating costs in the early phases of development.

3.5Access control and security

The CAD is a multi-user system, different actors are allowed to view different sets of objects and invoke different types of operations on them. The System Administrator can create users and maintain their accounts. The Ambulance Station can create instances of new vehicles and manages them. Also it can view ambulance status.Note that most of the access control information is already stated in the use case model

3.6Global software control

We have already stated above in hardware/software mapping section that the WebServer waits for requests from WebBrowser. Upon the receipt of a request, the WebServer processes it and dispatches it to the appropriate servlet or JSP, thus resulting in an event-based control flow. The Web Server allocates a new thread for each request, allowing the parallel handling of requests. This results in a more responsive system by enabling the WebServer to respond to individual WebBrowser requests before other requests have been completely processed, and can increase throughput by enabling the processing of one request while another is waiting for the database to respond.

3.7Boundary conditions

In this section we review design decisions and identify additional boundary use cases. CAD is created with the installation of the system. Vehicle instances to be tracked are created and destroyed as the ambulances are being dispatched. So following are the additional uses cases while reviewing persistent objects.

InstallCAD: The Administrator installs CAD, gives an instance name and selects a persistent storage subsystem and configures resource parameters (e.g., maximum number of concurrent ambulances to be dispatched and tracked, file path for storage)

ManageAmbulances: The actor Ambulance Station adds or removes an ambulance, including custom code for AmbulancePeer and AmbulanceFrontEndPeer. The list of ambulances is updated for the next time an actor enters new vehicle.

ConvertPersistentStorage: When the CADServer is down, the Administrator can convert the persistent storage from a flat file storage to a database storage or vice a versa.

StartCADServer: The Administrator starts the CADServer. If the server was not cleanly shut down, this use case invokes the Check Data Integrity usecase that handles this exceptional behavior.

CheckDataIntegrity: CAD checks the integrity of the persistent data. For file-based storage, this may include checking if the last logged transactions were saved on the disk. For database storage, this may include invoking tools providing by the database system to re-index the tables.