Page 1
OPERATIONS AND ADMINISTRATION SYSTEM for HRM 911 Dispatch Center
1.0 Introduction.
The HRM 911 Dispatch Center provides operator and dispatch services for the Region’s police, fire and
emergency health services (EHS) agencies. It also acts as a single point of contact for the Region’s citizens
to call for help. The software controlling this dispatch center is of vital importance with safety critical and
time critical constraints. At this time the Region would like to upgrade the computer systems, which
support this dispatch center.
2.0 General Overview.
The Region is divided into 42 zones with operators being assigned to one primary zone and four secondary
zones. This configuration allows operators to become familiar with the particular areas of the region they
deal with. Operators only deal with 911 events from their secondary zones if they are unoccupied and all
operators in the secondary zone are occupied. A 911 event is an incoming call from a citizen or a
communication from a managed asset (police, fire, EHS). There is no limit on the number of operators
which can be assigned to a particular zone. Finally, specially identified supervisory operators may handle
911 events from any zone and may monitor the managed assets from any zone.
3.0 Managed Assets.
A managed asset is a particular instance of fire, police or EHS entities. The dispatch system actually
manages each individual asset (e.g. fire engine, police cruiser and ambulance) by communicating with
computer systems residing within these assets (these system are not part of the dispatch system). For
more information see Section 8 of this document for more details; assets are always in one of three states
idle, on call or unavailable. An operator may dispatch only idle assets.
4.0 911 Events.
There are three kinds of 911 events:
1. Incoming telephone calls from citizens asking for help (HELP)
2. Outgoing communications to managed assets (police, fire, EHS) originated by the operator
(OUTCOMM).
3. Incoming communications from managed assets (police, fire, EHS) originated by the
managed asset (IN-COMM).
When a HELP call arrives, the system must report to the operator the vital information about where the call
is originating. When incoming calls have appropriate calling name and calling number information, this
can be used to lookup civic address information in the regions database system (see Section 8 below). The
system must display this information to the operator. When this calling information does not arrive with
the call (over the public telephone network) the operator must be able to provide the system with the civic
address (street name and number as provided by the caller) and the system must then retrieve the remainder
of the civic address information from the regions database. The user interface must graphically indicate the
location of the caller within the operator’s zone.
Operators must be able to select from any of the current 911 Events through the user interface. Each
operator can only have one HELP call at a time (i.e. the system must only direct HELP calls to an
unoccupied operator). Operators may however manage multiple 911 events at the same time. For example
one HELP call and multiple IN_COMM and OUT_COMM events.
The operator must be able to use the system to dispatch (with OUT_COMM events) any of its managed
assets to the location of a particular HELP call. For example if there is a fire reported, the operator must be
able to use the systems interface to dispatch fire services to the location. The dispatch message must be
sent automatically to the managed asset by the system. The user interface must update to indicate which
assets have been dispatched to the HELP location.
Page 2
Managed assets continually and automatically send their location back to the system so that it can display
locations to the operators. When an incoming COMM message arrives from one of these managed assets
the operator’s display must somehow identify the asset. Managed assets can make requests for the
dispatching of additional managed assets. In this case the dispatch system must behave in much the same
manner as a HELP call and allow the operator to dispatch additional assets (e.g. back up police or fire
units). The user interface must update to indicate which assets have been dispatched.
5.0 User Interface.
The dispatch system must provide a modern point-and-click user interface for the operators to use. In
particular it must have the ability to display maps of the region and allow the operator to navigate around
the maps (including zooming in and out). The user interface must allow the operator to be able to click on
map locations to get information from the civic database (e.g. address of the location clicked on). The user
interface must allow the operator to make annotations on the maps and to manipulate managed assets
through a drag and drop mechanism. For example dragging managed assets to a HELP call location must
be possible and result in the asset being dispatched (the system must only allow “idle” assets to be
dispatched in this manner). The user interface must show the location and status (graphically) of all HELP
calls and managed assets in the operator’s regions (including calls for other operators in the region).
Finally supervisory operators must be able to visualize and manipulate the map for the entire region.
The user interface must also support a simple query interface that operators can use to lookup information
from the Region’s civic address database.
6.0 Information System.
Operators need to be able to call up information about residences and commercial properties within the
region based on telephone number or partial addresses. The system must interface with the Region’s Civic
Database System in order to get this information in a timely fashion. See Section 8.0 for more information.
The 911 program is extremely expensive and the region is constantly being asked to justify expenditures.
In order to help in this area the 911 dispatch system must gather and report on statistics, which can be used
to justify the system. For example, average wait time, number of calls per hour, number of calls per day,
busy hour and other values, which may be helpful.
7.0 Safety Critical and Time Critical Constraints.
Clearly the 911-dispatch system is a safety critical system. As such, it must be available 99.9995 % of the
time. The system is responsible for reporting on its own status at regular intervals and for sounding
appropriate alarms to indicate potentially fatal failure conditions. That is before the system is completely
unavailable it must report degraded status by sending a message over a reliable network to some external
source. You must suggest some reasonable means of doing this.
The system must route calls to an available operator within 3 seconds of a call when an available operator
exists (See Section 8.4).
When there is no operator available the system must keep track of wait time and raise alarms so that the
region can determine if more operators must be added.
8.0 Interfaces.
This section describes the various interfaces that the completed dispatch system must interoperate with or
provide.
8.1 User Interface.
You need not provide the complete working user interface (see Section 9.0). Instead provide
mock-ups of what the user interface would look like and make use of a simple text-based system
for the proof-of-concept prototype.
Page 3
8.2 Managed Assets Communication Interface.
When managed assets communicate with the dispatch center they use the following simple
communication protocol. All messages have transaction ids and are sent over a reliable
guaranteed mechanism. You need not be concerned with the actual underlying transport.
Message
HELLO
LOC_UPDATE
DISPATCH_CNF
HELP_REQ
FAIL
Meaning
Initiation of
communication
Location update
Confirmation of
dispatch order
Request for additional
assets to be
dispatched.
Last message failed.
Content
LOCATION (map x,
y coordinates)
LOCATION (map x,
y coordinates) and
status indication.
NONE
Message text.
NONE
When the dispatch system communicates with managed assets it uses the following simple
protocol:
Message
Meaning
Content
DISPATCH
Dispatch order.
LOCATION and text
info about the HELP
call.
CHNG_STATUS
Dispatch can tell the
New status.
asset to change its
status from idle to
unavailable or viceversa.
HELP_CNF
Confirmation of help
NONE.
being dispatched in
response to a
HELP_REQ
FAIL
Last message failed.
NONE
8.3 Civic Address Database.
The Region’s IT department will work with you to accommodate a simple communications
protocol to retrieve this information. You are expected to design this protocol and submit it to
the Region’s IT department for approval.
8.4 Failure Reporting Interface.
The system is responsible for logging any conditions, which might lead to a failure. In the event
of possibly fatal errors the system must notify the Region’s by placing a call to a predefined
paging gateway.
8.5 Public Switching Telephone Network (PSTN) Interface.
Your system must interface with the PSTN in order to receive incoming calls from citizens calling
for help.
Your system will be notified of incoming calls through the protocol described below:
Page 4
Message
INCOMING
Meaning
A call arrived at the
interface to your
system
Content
Call Identifier,
Calling Name and
Calling Number.
Callers to 911 can not ever disconnect the call from their end so there is no disconnect message.
Your system can itself interact with the PSTN through the following outgoing protocol:
Message
ORIGINATE
DISCONNECT
Meaning
The system can
originate an outgoing
call.
Disconnect an existing
call.
Content
Call Identifier,
Number to be called.
Call Identifier.
Page 5
9.0 Deliverables, Due Dates and Penalties.
The following deliverables are expected. Descriptions will be expanded in class as the project progresses.
You will note that some of these deliverables have no value towards the final project grade but will result
in deductions from the final project grade if they are delivered late.
9.1 Group Proposals.
There is a lot to get done for this project, for this reason it is important that all groups get started as soon as
possible. To do this we first must choose groups. Group proposals are due by email
(keast@cs.stmarys.ca) to the instructor by Tuesday Sept. 14 th at 12:00 noon. 10 marks will be
deducted from the final project grade if this is not provided on time.
They must include:
 Group identification – team name.
 A primary and secondary team leader for the group and for each of the deliverables. This is not
binding but is intended to help you to begin the process of dividing up the work that is going to
need to get done. Every team member is expected to participate to some degree in every part of the
project, but each person may spend more effort in one area than the other areas.
 Over-view of Team Members including a brief summary of academic and professional
background.
 Email addresses, names and student numbers of all members
These groups will be accepted at the sole discretion of the instructor and changes may be made. Final
teams will be announced in class Tuesday September 14th.
9.2 Project Plan.
This document must be formally provided and include the following:
 Over-view of Team Members including a brief summary of academic and professional
background.
 Detailed project plan including:
o List of milestones (they must match this schedule but must have a finer granularity (i.e
you must specify more milestones).
o Activity network
o Activity bar chart
o Task allocations to team members.
o Brief risk identification as well as a plan to manage the risk
In particular this document must show the ordering of the tasks and how they can be divided up among the
members. Some tasks can be done in parallel – this must be indicated in your plan.
NOTE: The task distribution in this plan is non-binding – that is as the term goes on group members
may well work on aspects of the project which do not follow the plan. You would be best served however
to create a realistic a fair plan since this will ultimately help you reach the prescribed deadlines.
Consult Chapter 5 of your text for assistance with Project Planning,
DEADLINE FOR PROJECT PLAN:
This deliverable is due in the class on September 23nd. It will not be accepted late. This is worth
10% of the final project grade.
Page 6
9.3 Software Requirements Specification.
This document must be formally provided.
 It must follow the IEEE model described in class and chapter 6 of your text.
 It must be complete and precise.
 No formal modeling techniques are required but students may use them if they find them
helpful and understand them.
 In addition to the standard IEEE sections, GUI mock-ups must be provided in the appendix.
The user document provided is not complete and will not be enough to generate a complete SRS. You must
follow the requirements elicitation and analysis techniques discussed in class and chapter 7 of your
text.
The instructor will provide answers to elicitation questions by email. Each group will be allowed only 6
questions for this stage of the process. Choose them wisely.
DEADLINE FOR SOFTWARE REQUIREMENTS SPECIFICATION:
 A draft of this deliverable is due in class Tuesday October 5th. The draft will not be
graded but feedback will be provided. If the draft is not submitted then 5 marks will
be deducted from the final grade for SRS.
 The final delivery of the SRS is due in class Thursday October 21st. A late penalty of
15% per day will apply. This is worth 30% of the final project grade.
9.4 Software Design and System Architecture.
This document must be formally provided.
It must provide the following (two major parts):
 PART ONE: A high level design describing your systems architecture (see Chapters 11 and 12 of
your text). This portion must describe all aspects of your system at a high level including
appropriate architecture and context diagrams and accompanying text describing each major
component in your system.
 PART TWO: It must provide a detailed design each component or subsystem in your
architecture. This detailed design must be sufficient for a skilled programmer to correctly
implement the portions described. This section may be done following any reasonable
combination of the methods described in Chapters 11-16 as appropriate for your design.
DEADLINE FOR SOFTWARE DESIGN AND ARCHITECTURE:
 No draft of this document is required, but feedback will be provided on one draft per
group if the group submits in a timely fashion.
 This deliverable is due in class Thursday November 18. A late penalty of 15 % per
day will apply. This is worth 30% of the project grade.
9.5 Software Test Plan.
This document must be formally provided. It must provide:
 A test case for each requirement in the SRS.
 For each case an indication of the expected result and behaviour.
 Traceability information, which shows that each requirement has been covered and clearly
indicates which requirements are covered by each text.
 An explanation for why any requirement is not covered.
The input to this deliverable is the SRS, which means you may begin this as soon as the SRS is
finalized.
Page 7
The document must be written as an acceptance document to be used by the Region to formally accept the
system. As such tests must be provided in a table with appropriate spaces for the results, date etc. to be
filled in. Portions of this document will be used to validate the prototype system provided.
DEADLINE FOR SOFTWARE TEST PLAN:
 No draft of this document is required, but feedback will be provided on one draft per
group if the group submits in a timely fashion.
 This deliverable is due in class Tuesday November 30th. A late penalty of 15 % per
day will apply. This is worth 15% of the final project grade.
9.6 Prototype and System Demo.
A working prototype which illustrates how your system would work when fully implemented.
Details on this prototype will follow. However students should note that a fully working system is not
expected.
Demonstration of prototype during meeting with instructor after the term ends during which a subset of
your test plan tests will be executed. All members of the group must be present for the demo, questions
will be asked and members may receive a different grade for this portion of the project.
This is worth 15% of the final project grade.