Deliverable 3: System Design



Deliverable 3: Architecture Specification

Revision History

|Version |Changed by |Date |Remarks |

|1.0 |Sama |07/02/2007 |First Draft |

|2.0 |Amit and Sama |07/05/2007 |Changes in following sections: |

| | | |3.2, 3.4, and 4 |

|2.1 |Muhammad |07/06/2007 |Updated Section 1.3 – |

| | | |Definitions, acronyms, and |

| | | |abbreviations |

|2.2 |Sama |07/12/2007 |Changes in following section: |

| | | |3.2 (updated system |

| | | |decomposition diagram) |

| | | |3.2.3 (updated database tables) |

| | | |3.4 (updated database tables and|

| | | |fields) |

| | | |4.1 (updated screenshots of UI) |

| | | |4.13 (deleted) |

1. Introduction

This document describes the overview of the software architecture, design goals, current architecture, and design model of the new system. System overview of the software architecture, system decomposition, data management/schemes, and subsystem services are also detailed out in the document.

1. Purpose of the system

The purpose of the Ambulance Dispatch System is to create a system that causes the entire process of dispatching ambulances (to emergency situations) to be more efficient and more effective; the net result of which is to save lives. An ambulance dispatch system generally involves multiple people, extremely large amounts of timely communications, and lightening fast decision-making.

Timely communication is a critical issue. Any information transfer that can be expedited can safe a life. Information must be drawn from the caller and entered into the system by the operator and transferred to the dispatcher. The dispatcher must locate the closest available emergency vehicle, determine availability, and dispatch that vehicle to the proper location. After the ambulance arrives at the proper location, if the subject must be taken to the hospital, an adequate hospital must be located, notified of the arriving new patient, and the shortest, fastest route mapped into the ambulance’s map system. Any breakdown in this fragile process can lead to a lost life by consuming excessive time in clearing up confusions or miscommunications. Misinformation can lead to the wrong decision in the rapidly paced environment.

2. Design goals

The design goals represent the desired qualities of Ambulance Dispatch System and provide a consistent set of criteria that must be considered when making design decisions. The Ambulance Dispatch system must be 99.9% reliable due to critical use of the system. To comply with the portability requirement, server should be installable on a variety of machines and operating systems and functions in a variety of networking environments. The applications and servers should have the transparent load balancing capability to assure 99.9% availability and accessibility. The application performance should be high to reduce and minimize the delay; furthermore, Ambulance Dispatch System shall not take longer than 15 seconds to respond to a page request for members--when using an internet connection that is 56k or higher. The server should have spare capacity to handle larger number of clients.

3. Definitions, acronyms, and abbreviations

1. Definitions:

Dispatcher: Resides in control room and provides services such as answer’s callers, locates closest available emergency vehicle.

Transparent: Unnoticeable to dispatcher or other users.

56K Modem: A device for transmitting usually digital data over telephone wires by modulating the data into an audio signal to send it and demodulating an audio signal into data to receive it.

GPS: A system of satellites, computers, and receivers that is able to determine the latitude and longitude of a receiver on Earth by calculating the time difference for signals from different satellites to reach the receiver.

Dynamic Structure: An interactive system or process

Java Server Pages: An extension to the Java servlet technology from Sun that allows HTML to be combined with Java on the same page. The Java provides the processing, and the HTML provides the page layout that will be rendered in the Web browser.

MYSQL: it is a very popular open source, relational DBMS from MySQL AB, Uppsala, Sweden () that runs under various versions of Unix and Windows and Mac.

WinCE: (Windows Consumer Electronics) Microsoft's version of Windows for handheld devices and embedded systems that use x86, ARM, MIPS and SHx CPUs.

Global System for Mobile Communications: A digital cellular telephone technology that is based on time-division multiple accesses; it operates on the 900-megahertz and 1.8-gigahertz bands in Europe, where it is the predominant cellular system, and on the 1.9-gigahertz band in the United States

Radio-frequency identification: is an automatic identification method, relying on storing and remotely retrieving data using devices called RFID tags or transponders

Unified Modeling Language: An object-oriented analysis and design language from the Object Management Group (OMG)

2. Acronyms and Abbreviations

UI Module: User Interface Module

ADS: Ambulance Dispatch System

DB: Data Base

PDM: Persistent Data Management.

JSP: Java Server Pages

JDBC: Java Data Base Connectivity

WinCE: Windows Consumer Electronics

GSM: Global System for Mobile Communications

RFID: Radio-frequency identification

UML: Unified Modeling Language

KMP: Key Management Principles

LCD: Liquid-crystal display

4. References

1. Team Website utdallas.edu/~mas027000

2. Project Scope

3. Course Home Page

4. Ambulance Dispatch System Case Studies

1.

2.

3.

4.

5. Various Design Studied for the project

1.

2. eecs.harvard.edu/vino/vino/goals.html

3. cs.ucla.edu/classes/fall03/cs211/lectures/lec1103.ppt

4. web/about/ac123/ac147/archived_issues/ipj_1-2/reliable_multicast.html

6. Address Lookup Systems by Phone Number

1.

2.

7. Reference mapping systems

1.

2.

8. Automobile real-time tracking systems

1.

2.

3.

4.

5.

9. Portable GPS vehicle navigation systems and traffic watchers

1.

2.

3.

4.

5.

6.

10. Cell phone tracking and locator services

1.

2.

3.

5. Overview

Schedule and Infrastructure are the constraints impacting the software architecture; furthermore, the team has limited resources (such as equipment and man-power) to complete the project.

The high level functions of the ambulance dispatch system are to employ incident information to locate and allocate the ambulance; furthermore, the system should also formulate incident information for the ambulance personnel. In last but not least, the ambulance dispatch system should also satisfy the timing requirements given as a part of the project scope.

To be able to find the location of incident and to find the route from ambulance location to incident location, an external GPS system would be utilized. The ambulance dispatch system would interact with this GPS system to get the incident location and to find the route to incident location.

2. Current software architecture

Before, the emergency ambulatory service was run manually and consisted of three main components - Call tracking, Resource Identification and Resource mobilization. The architecture of the current system that replaced the manual way has three sections - Components (The static structure), Interaction of Components, and the process structure (Dynamic Structure).

Components: The components of current system architecture are User Interface Module that allows the user to interact with the system, An Ambulance Dispatcher that chooses the best ambulance and hospital for a given incident, Map server which provides the driving distance and approximate time between two given locations, Ambulance Server that provides the status of the ambulance, Hospital Server that provides the location of hospital, their resources, Incident Tracker tracks incidents and their resolution status whether the incident is resolved in a timely manner, An Incident Database which stores incident information, Function Driver that takes the user input and respond like updating servers and database, dispatching ambulance, selecting hospitals etc. The Function driver is subdivided into components, Processor Monitor that monitors the processors in the system, an operating system.

Interaction of Components: The current system architecture is divided into layers or subsystems. The layering model is based on a responsibility layering strategy that associates each layer with a particular responsibility. The layer1 has function driver, UI Module, Incident tracker, processor monitor, Layer2 is Ambulance dispatcher subsystem, Layer 3 has Servers and databases and Layer 4 is the operating system.

Dynamic/ Process Structure: A reliability monitor is implemented as a set of processes. For each incident, a new process is created and destroyed as needed. System is implemented on a three processor system and a processor monitor is implemented to monitor the processors, to make sure each processor is working properly and causes migration off of a mal-functioning processor.

3. Proposed software architecture

1. Overview

[pic]

2. Subsystem decomposition

The system decomposition of Ambulance Dispatch System is as follows:

Each layer is divided into subsystems.

Each subsystem does the coherent work and provides some services.

Details of each subsystem within a layer are as follows:

Each subsystem is described as a package.

Subsystems within a layer can communicate with each other.

[pic]

1. User Interface Layer

This layer is divided in two subsystems.

DispatchUI: This subsystem represents the user interface used by the dispatcher of the Ambulance Dispatch System.

AmbulanceUI: This subsystem represents the user interface used by the ambulance personnel.

2. Dispatch Controller Layer

This layer has five subsystems:

AddrInterface: This subsystem represents the interface to external systems used by the ambulance dispatch system. This subsystem provides the services to Dispatcher subsystem. It gives the address information once the dispatcher inputs a phone number

GPSInterface: This subsystem represents the interface to external system used by the ambulance dispatch system, This subsystem is used by the ambulance user interface to get the details of the route and current positions on the map. It also provides the coordinates of the incident to the Dispatcher subsystem, and the current location of the ambulance to the Tracking subsystem.

User Management: This subsystem implements all the user related functions like login, managing users and creating reports.

Dispatcher: This subsystem performs the core functions of Ambulance dispatch system. Major functions performed by this subsystem are creating incident, finding incident location (address and coordinates), locating and allocating ambulance. This subsystem communicates with subsystem AddrInterface to get information about the address and location details.

Tracking: This subsystem performs the job of ambulance tracking. This subsystem communicates with subsystem dispatcher and GPS Interface, as well as ambulance DB and incident DB.

3. ADS Database Layer

IncidentDB: Represents the database of incidents created.

AmbulanceDB: Represents the database of Ambulance containing ambulance details.

AssignmentInfo DB: Represents the database of Incidents and the Ambulances associated with that incident.

HospitalDB: Represents the database of hospitals in the area dispatch system covers.

UserDB: Represents the database of Users of Ambulance Dispatch System.

Details of each database table are discussed in the Section 3.4 (PDM) Persistent Data Management.

3. Hardware/software mapping

ADS is built as a simple client-server application and only includes four parts:

WebServer

It includes UserInterface subsystem and DispatchController subsystem. UserInterface subsystem is implemented using JSP, Dispatch Controller subsystem is common Java application.

DBServer

It includes ADS Database subsystem. MySQL can be used to implement it. The connection between WebServer and DBServer is JDBC.

WebBrowsers

Common Web Browsers which can support Java are used

WebBrowsersInVehicle

This WebBrowser is used in specific device deployed in Vehicle such as ambulance. This device can run WinCE Operating System. GSM or RFID connections have been used to connect Web server and ambulance client.

The following UML deployment diagram illustrates the hardware/software mapping for ADS.

[pic]

4. Persistent data management

This section describes the persistent data stored by the ambulance dispatch system. This includes information about the users, incidents, ambulances, and hospitals.

Details of each database table are described below,

User Database:

This contains information about User name, Dispatcher ID, password and type of user (Normal user or supervisor).

Incident Database:

This contains information about Caller first name, last name, caller phone number, address of incident, intersection, coordinates (longitude and latitude), number of injured persons, brief description of incident, incident ID, ID of the dispatcher who responds to the incident, the time it took to resolve incident, status of incident (open or close), ID of hospital patients are taken to, date and time incident ticket was created, and any comments if there’s an exception in handling the incident.

Ambulance Database:

The ambulance database is used by the tracking and dispatcher subsystem. This database contains information about the ambulance ID, contact number, location of ambulance (coordinates), starting position (coordinates), and status of each ambulance.

AssignmentInfo Database:

The AssignmentInfo database contains the incident number, and the ambulances associated with that incident.

Hospital Database:

The Hospital database contains the hospital name, address, ID, coordinates, and contact number.

5. Access control and security

As part of the Access Control policy, we've focused on Authentication and Authorization of a user to using Ambulance Dispatch System (ADS), which includes not allowing shared User ID / Password. The password field in the Login Screen uses encryption, and as part of cryptosystem design, Key Management Principles (KMP) are exercised. These are the security measures to uniquely identify our ADS.

6. Global software control

Will be handled in the next deliverable

7. Boundary conditions

The conditions for start-up, shut-down and error behavior of the ADS is as below:

Start-up: A new ticket is created to solve the incident.

Shut-down: Evaluation of the status of each created ticket during start-up.

Error Behavior: Manual Intervention.

4. Subsystem services

1. Dispatcher UI

When the dispatcher, or operator of the system, first starts up the system, the login screen is displayed. The user enters the Dispatcher ID and password into the encrypted text fields, and clicks on “Logon”. The Dispatcher UI communicates with the User Management subsystem to verify whether the Dispatcher ID already exists, and if it does, whether the password is correct or not. If the Dispatcher ID does not exist, then an error message is displayed.

[pic]

Once the user has successfully logged on, a menu page is displayed with the various options, and a list of ambulances and their availability. The user can choose to “Create an Incident”, “Monitor an Incident”, or “Create a Report”.

[pic]

If the user clicks on “Create Incident”, a screen displays with various text fields to fill out, and a default Ticket number assigned to the Incident. The user fills in the caller’s first name, last name, and phone number. User can click on “Get Address” button to query the AddrInterface subsystem for the address or intersection where the caller is calling from. This address is automatically populated by the result from AddrInterface subsystem. User then clicks on “Get Position” button to query the GPSInterface subsystem for the address or intersection where the caller is calling from. This address is automatically populated by the result from AddrInterface subsystem. User asks the caller for a brief description of the incident, and enters into the text field. User also determines how many patients will be requiring an ambulance accordingly, and chooses that number from the drop down menu. If all fields are entered correctly, user clicks on “Create Incident” button. If user wants to start over and clear all fields, user clicks on “Reset”. If user wishes to not create an incident anymore and go back to the menu page, then user clicks on “Cancel”. For both the “Reset” and “Cancel” options, user is prompted with an “Are you sure you want to Reset?” or “Are you sure you want to cancel all changes and go back to menu?” pop up, with an “OK” or “Cancel” option.

[pic]

Once user chooses the “Create Incident” button, the next page that displays is the list of nearest 3 available ambulances, with the ambulance ID, number of miles away from the incident, the contact phone number, the status which should be “available”, and a checkbox to select that particular ambulance. User can click on “Reset” to clear all selections, “Cancel” to clear all selections and go back to the main menu without dispatching any ambulance, or “Dispatch” to dispatch the selected ambulance for the incident. For both the “Reset” and “Cancel” options, user is prompted with an “Are you sure you want to Reset?” or “Are you sure you want to cancel all changes and go back to menu?” pop up, with an “OK” or “Cancel” option. For the “Dispatch” option, an error message pops up if no ambulances are selected before clicking on “Dispatch” button.

[pic]

There is also a time tracker on the screen to display how much time has passed since the incident was created. This page refreshes every two seconds to show the latest availability of the ambulances. If the time exceeds 11 minutes, then an “Exception” message pops up.

[pic]

The user needs to fill out the action taken so far and submit for manual intervention to take place.

[pic]

Once user clicks on “Dispatch”, user is automatically taken to the “Monitor Incident” page. A map of the current location of the ambulance is shown where the information is retrieved via the GPS Interface. The page refreshes every 30 seconds if the distance the ambulance has to travel is less than or equal to 5 miles, every 60 seconds if the distance the ambulance has to travel is greater than 5 miles but less than or equal to 30 miles, and every 3 minutes if the distance to travel is greater than 30 miles, thus displaying the current status of the ambulance. Also, if the ambulance was dispatched, it will display “On the way”. If ambulance personnel has specified that the patient is picked up, it will display “Picked up the patient, en route to hospital”. If ambulance personnel specifies that the patient has been dropped at the hospital, it will display “Dropped patient at the hospital, task complete, ambulance available”. If ambulance personnel specifies that it is lost, then it will display “Lost and need help”, at which point the dispatcher will call the ambulance personnel. The ambulance ID and contact number will display at the bottom of this screen as well, along with a time tracker to note how long it took to resolve the incident, and the ticket number assigned to the ticket.

[pic]

[pic]

If user clicks on “Create report”, user can choose various options to create reports.

2. Ambulance UI

The Ambulance UI is a tabular view of 3 screens available to the ambulance personnel on the LCD screen installed in the ambulance.

The main screen displays the name, address, and contact number for the caller, the number of patients at the incident, name of the nearest hospital, the ticket number for the incident, and the dispatcher’s name and phone number for contact.

[pic]

The second tab is the “Directions” screen, where the step by step directions to the incident, or hospital, as well as the map with the ambulance’s current location, are displayed. The directions are automatically and constantly updated by the GPS infrastructure, which the mobile device in the ambulance communicates through a satellite.

[pic]

The third tab is the “Monitoring” tab, where there are a set of options available for the ambulance personnel to choose from: “Picked up patient”, “Reached hospital”, “Back at station”, or “Lost”. The ambulance personnel chooses the option and clicks on “Submit” to be able to inform the dispatcher who is monitoring the progress of the ambulance.

[pic]

3. User Management

When the user clicks on “Logon” from the Login screen, the User Management system queries the UserDB, and matches the Dispatcher ID to an existing Dispatcher ID in the database, decrypts the password, and verifies against the password in the database. If the Dispatcher ID does not exist, it throws an error back to Dispatcher UI.

User Management subsystem allows creating of new users which would use the ambulance dispatch system. Report generation is also performed by this subsystem.

High level services provided by the User Management subsystem are as follows,

• ValidateUser()

• CreateUser()

• UpdateUserInformation()

• CreateReports()

4. Dispatcher System

When the user clicks on “Get Address”, the Dispatcher System communicates with the AddrInterface by sending the phone number the caller provided, and receiving in turn the address associated with that phone number.

When the user clicks on “Get Coordinates”, the Dispatcher System communicates with the GPSInterface by sending the address or intersection retrieved by the AddrInterface, and receiving in turn the coordinates associated with that address or intersection.

When the user clicks on “Create Incident”, the Dispatcher System uses the address or intersection provided by the AddrInterface and queries the Ambulance DB for the location of available ambulances. It uses an algorithm to find the 3 nearest ambulances and sends those to the Dispatcher UI to display on the screen. It also finds the nearest hospital to the incident by querying the Hospital DB.

When the user clicks on “Dispatch”, the Dispatcher System updates the Ambulance DB with the status “Unavailable” for the chosen ambulance, creates a new record in the AssignmentInfo DB for the ambulance(s) associated with each incident, sends the allocation information to the Ambulance UI, and sends the Ticket number to the Tracking System.

High level services provided by the dispatcher subsystem are as follows,

• GetAddress()

• GetCoordinates()

• GetIncidentDetails()

• CreateNewIncident()

• LocateAmbulance()

• GetNearestHospital()

• Allocateambulance()

5. Tracking System

Once a ticket has been created for an incident, and the Dispatcher system has sent the “allocation information” to the ambulance regarding the address, caller name, nearest hospital, contact information, etc, the Tracking system takes over. For the Operator/Dispatcher to monitor the progress of the ambulance, the Tracking system is used. It requires a ticket number to track the ambulances related to that particular incident.

The Tracking System receives the current coordinates of the ambulance via the GPSInterface, and translates them onto a map, displaying the starting point, ambulance’s current location, incident location, and hospital on the same map.

Before the ambulance sends back any information, the status of the ambulance is “on the way”. When the ambulance personnel chooses a particular option from the display menu, such as “Picked up, on the way to the hospital”, that information is sent to the Tracking System, which updates the status of the ambulance in the Ambulance database, which in turn reflects on the User Interface when the page refreshes.

If the ambulance chooses the option “lost” from the display panel, and the information reaches the Tracking System, and Tracking System updates the ambulance status in Ambulance database, then the Operator/Dispatcher calls the ambulance personnel to give directions. Once the ambulance personnel is finished, he updates the status from the display panel, which in turn updates the ambulance database, and the Tracking System marks the ambulance as “available” for the next emergency.

The Tracking System also keeps track of the time that has passed since the incident was created and the ambulance reached the patient, to the time the ambulance dropped the patient to the hospital and is available. This information is used by the Reporting System.

High level services provided by the tracking subsystem are as follows:

• TrackAmbulance()

• CreateMap()

• Set_AmbulanceStatus()

• Update_AmbulanceStatus()

• Moniter_Time()

6. GPS Interface

The GPS Interface provides the coordinates of the incident location, and the current location of the ambulance, when queried by the Dispatcher subsystem and Tracking subsystem respectively. It also receives the destination address from the Ambulance UI via the device in the ambulance, detects the current location of the ambulance via satellite, and provides step by step directions to the Ambulance UI, updating it every second. Last but not least, it also displays a map for the Ambulance UI to view location and directions. The GPS

High level services provided by the GPS interface are as follows:

• Provide_route_details()

• ProvideCoordinates()

• CreateMap()

• Provide_status()

7. AddrInterface

The AddrInterface, when queried by the Dispatcher UI receives as input a phone number, and provides an address associated with the phone number, or an intersection if the phone number is mobile.

High level services provided by the AddrInterface are as follows:

• Find_Address()

8. IncidentDB

Represents the database of incidents created. This contains information about Caller first name, last name, caller phone number, address of incident, intersection, coordinate of incident, number of injured persons, brief description of incident, incident ID, ID of the dispatcher who responds to the incident, time it took to resolve incident, and current status of the incident.

9. AmbulanceDB

The ambulance database is used by the tracking and dispatcher subsystem. It represents the database of ambulance containing ambulance details such as ambulance ID, contact number, location of ambulance, starting position of ambulance, and status of each ambulance.

10. AssignmentInfoDB

The AssignmentInfoDB contains the incident ID, and the ambulances associated with that incident.

11. HospitalDB

The HospitalDB contains the name of hospital, address, ID, contact number, and coordinates associated with the hospital.

12. UserDB

Represents the database of users of Ambulance Dispatch System; contains information about User name, Dispatcher ID, password and type of user (Normal user or supervisor).

5. Glossary

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download