incident management systems context and capability for ... · introduction: incident management...

Defence R&D Canada – Atlantic

Incident Management Systems Context and

Capability for Maritime Force Protection

Volume 1

Eric Widdis, Arthur Cole and Allen StotzMacDonald Dettwiler and Associates Ltd.

MacDonald Dettwiler and Associates Ltd.Suite 60, 1000 Windmill RoadDartmouth, NS B3B 1L7

Project Number: DN0917 Issue 3.0

Contract Project Manager: Chris McLaughlin, 902-481-3514

Contract Number: W7707-063601-001-HAL/11GQ

Contract Scientific Authority: Mark G. Hazen, GL/MC2CD, 902-426-3100 x 176

The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and thecontents do not necessarily have the approval or endorsement of Defence R&D Canada.

Contract Report

DRDC Atlantic CR 2008-179

October 2009

Copy No. _____

Defence Research andDevelopment Canada

Recherche et développementpour la défense Canada

This page intentionally left blank.

Incident Management Systems Context and Capability for Maritime Force Protection Volume I

Eric Widdis Arthur Cole Allen Stotz MacDONALD DETTWILER AND ASSOCIATES LTD. (MDA) Prepared By: MacDONALD DETTWILER AND ASSOCIATES LTD. (MDA) Suite 60, 1000 Windmill Road Dartmouth, Nova Scotia B3B 1L7 Project Number: DN0917 Issue 3.0 Contract Project Manager: Chris McLaughlin, 902-481-3514 Contract Number: W7707-063601-001-HAL/11GQ CSA: Mark G. Hazen, GL/MC2CD, 902-426-3100 x176 The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of Defence R&D Canada.

Defence R&D Canada – Atlantic

Contract Report


October 2009

Principal Author

Original signed by Eric Widdis

Eric Widdis

Approved by

Original signed by David Hazen

David Hazen

Head, Technology Demonstration Section

Approved for release by

Original signed by Ron Kuwahara for

Calvin Hyatt

Chair DRP

© Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2009

© Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2009

Abstract ……..

In the context of command and control (C2) for base and fleet force protection, incident

management systems (IMS) may prove to be an important tool. This study was initiated under

the Maritime Force Protection Technology Demonstration Project (MFP TDP) in order to further

investigate and define IMS specific to MFP concerns. In order to better understand this type of

product for use with base and fleet systems, the study also highlights FP related IMS features and

includes a summary of typical and non typical IMS capabilities. To address the problem of

useful Incident Management within the Maritime Force Protection environment, the study

reviews several existing IMS solutions and their compatibility with Incident Management

requirements within Canadian Forces Base Halifax.

Résumé.....

Les systèmes de gestion des incidents (SGI) ont le potentiel de devenir des outil importants dans

le contexte du commandement et contrôle (C2) pour la protection des bases et de la force navale.

La présente étude, chapeautée par le Projet de démonstration de technologies de protection de la

Force navale (PDT PFN), a visé à étudier puis préciser les caractéristiques d’un SGI adapté à la

PFN. Afin de mieux comprendre comment utiliser ce type de produit avec les systèmes existants

des bases et de la flotte, l’étude a aussi insisté sur les fonctions des SGI pertinentes à la protection

de la flotte, et elle comporte un résumé des fonctions typiques et particulières des divers SGI.

Dans le but de rendre la gestion des incidents utile dans le contexte de la protection de la Force

navale, l’étude a comparé plusieurs systèmes de SGI existants et évalué à quel degré ils répondent

aux besoins en matière de gestion des incidents de la Base des Forces canadiennes Halifax.

DRDC Atlantic CR 2008 179 i


ii DRDC Atlantic CR 2008 179

Executive summary

Incident Management Systems Context and Capability for Maritime Force Protection: Volume I

E. Widdis; A. Cole; A. Stotz, DRDC Atlantic CR 2008-179; Defence R&D Canada – Atlantic; October 2009.

Introduction: Incident Management Systems (IMS) have been developed in the civilian

emergency management community to address command and control issues dealing with short

time frames, multiple agencies and volunteer personnel. Domestic home port maritime force

protection (MFP) has many similar characteristics; operations centres staffed as secondary duty,

liaison with other government departments, etc. As a result of previous research and the

investigation of traditional military C2 systems it appears that commercial IMS may have

application to MFP in domestic port situations. The MFP Technology Demonstration Project

(TDP) intends to conduct experimentation/demonstration of C2 systems for force protection in

fiscal year 2010 and requires guidance on the characteristics of IMS and their applicability to the

maritime FP problem. In the context of command and control (C2) for base and fleet force

protection, incident management systems (IMS) may prove to be an important tool. This study

was initiated under the Maritime Force Protection Technology Demonstration Project (MFP TDP)

in order to further investigate and define IMS specific to MFP concerns. In order to better

understand this type of product for use with base and fleet systems, the study also highlights FP

related IMS features and includes a summary of typical and non typical IMS capabilities.

Results: A broad survey of commercial IMS products was conducted, lists of typical and non

typical capabilities were compiled, and a concise definition of IMS developed. The initial

information gathered from a general look at IMS technology was correlated with the results from

previous tasks to achieve a better understanding of the essential and desirable criteria in existing

IMS. A review several existing IMS solutions and their compatibility with Incident Management

requirements within Canadian Forces Base Halifax was completed. It was found that many of the

characteristics of commercial IMS are directly applicable to the domestic port force protection

requirements. However, no one system provided all of the capability required, with the

integration to tactical level sensor systems and blue force tracking being the greatest concern.

Notably, many of the vendors are currently addressing this concern, although, IMS systems are

more typically used at a more operational or strategic level.

Significance: The information gathered about the three systems identified as sample IMS

solutions provides a solid basis for further investigation, and significantly narrows the field for

considering suitable systems for use in base and fleet FP. The recommendations and conclusions

of this study will also allow for a more informed decision in choosing a system for potential

simulated environment testing.

Future plans: The results of this study will be used to further investigate specific IMS, and

potentially for future testing. As well, the information gathered and correlated on Incident

Management may be helpful in assisting with a future statement of deficiency, aiding in possible

procurement of technologies.

DRDC Atlantic CR 2008 179 iii

Sommaire .....

Capacités des systèmes de gestion des incidents dans le contexte de la protection de la Force maritime : volume I

E. Widdis; A. Cole; A. Stotz, DRDC Atlantic CR 2008-179; R & D pour la défense Canada – Atlantique; Octobre 2009.

Introduction : Dans le milieu de la gestion des situations d’urgence, on a créé les systèmes de

gestion des incidents (SGI) dans le but de mieux gérer les questions de commandement et de

contrôle dans un contexte de délais serrés, d’agences multiples et de personnel bénévole. Or, la

protection de la force navale (PFN) dans le port d’attache canadien est assurée dans un contexte

semblable : les centres d’opérations sont jugés des tâches secondaires, et on travaille liaison avec

d'autres ministères, entre autres caractéristiques. Des recherches précédentes doublées d’une

étude des systèmes militaires de C2 habituels laissent penser que les systèmes de SGI

commerciaux peuvent être utiles à la PFN dans les ports canadiens. Le Projet de démonstration de

technologies de protection de la force navale (PDT PFN) vise à faire au cours de l’exercice

financier 2010 l’essai ou la démonstration des systèmes de commandement et contrôle (C2) pour

la protection de la force; pour cela, il existe un besoin d’en savoir plus sur les caractéristiques des

SGI et leur pertinence au problème de la protection de la force en milieu naval. Les systèmes de

gestion des incidents (SGI) ont le potentiel de devenir des outil importants dans le contexte du C2

pour la protection des bases et de la force navale. La présente étude, chapeautée par le Projet de

démonstration de technologies de protection de la Force navale (PDT PFN), a visé à étudier puis

préciser les caractéristiques d’un SGI adapté à la PFN. Afin de mieux comprendre comment

utiliser ce type de produit avec les systèmes existants des bases et de la flotte, l’étude a aussi

insisté sur les fonctions des SGI pertinentes à la protection de la flotte, et elle comporte un résumé

des fonctions typiques et particulières des divers SGI.

Résultats : Nous avons effectué une vaste étude de SGI commerciaux, dressé la liste des

caractéristiques typiques et particulières de ces systèmes, et élaboré une définition succincte des

SGI. Les données compilées initialement par une étude générale de la technologie des SGI ont été

comparées aux résultats des tâches précédentes afin de pouvoir établir plus exactement les

caractéristiques essentielles et désirables des SGI existants. Nous avons étudié plusieurs solutions

de SGI et leur compatibilité avec les besoins en matière de gestion des incidents de la Base des

Forces canadiennes Halifax. Cette étude a révélé que nombre des fonctions des SGI commerciaux

répondent directement aux besoins en protection de la force dans les ports canadiens. Toutefois,

aucun système n’offre toutes les fonctions nécessaires; entre autres, l’intégration avec les

systèmes de capteurs tactiques et la surveillance de la force bleue ont été particulièrement

problématiques. Il faut cependant signaler que plusieurs fournisseurs s’efforcent de combler ces

lacunes, même si les SGI sont pour la plupart destinés à des utilisations d’ordre plus opérationnel

ou tactique.

Portée : Les renseignements recueillis sur les trois systèmes retenus à titre d’échantillons de

solutions en SGI sont un excellent point de départ pour des études plus poussées, et ils réduisent

beaucoup le nombre de systèmes convenables à évaluer pour la PF des bases et de la force navale.

Les recommandations et les conclusions de la présente étude permettront également de faire un

choix plus éclairé lorsqu’on envisagera faire l’essai d’un système en environnement simulé.

iv DRDC Atlantic CR 2008 179

Recherches futures : La présente étude servira à orienter les études suivantes des SGI, et le cas

échéant aux essais éventuels de ces systèmes. Les renseignements recueillis, mis en corrélation

avec la gestion des incidents, pourront aussi être utiles à élaborer un énoncé des carences qui

aidera à l’approvisionnement technologique.

DRDC Atlantic CR 2008 179 v


vi DRDC Atlantic CR 2008 179

Table of contents

................................................................................................................................. i Abstract ……..

................................................................................................................................... i Résumé ….....

........................................................................................................................ iii Executive summary

.................................................................................................................................. iv Sommaire .....

........................................................................................................................... vii Table of contents

............................................................................................................................... viii List of figures

................................................................................................................................... ix List of tables

............................................................................................................................... 1 1 Introduction

1.1 ...................................................................................................... 2 Document Overview

1.2 .......................................................................... 2 Applicable and Reference Documents

......................................................................................................................... 3 2 Review Criteria

2.1 ....................................................................................... 3 Prior Interviews and Research

2.2 .............................................................................................................. 4 Review Criteria

..................................................................................... 5 3 Incident Management Systems Survey

3.1 ................................................................................................................... 5 Introduction

3.2 .......................................................................................................... 5 Definition of IMS

3.3 ......................................................................... 8 Typical IMS Features and Capabilities

3.4 ............................................................... 10 Non Typical IMS Features and Capabilities

3.5 ............................................ 11 Mapping of IMS Capabilities to the Context of MFP C2

3.6 ............................................................................................... 15 Existing IMS Solutions

3.6.1 ............................................................................................ 15 Command View

3.6.2 .......................................................................... 16 Asset Control and Tracking

3.7 ................................................................................................ 18 Sample IMS Solutions

3.7.1 .......................................................................................................... 19 E Team

3.7.2 ................................................................................................... 23 Black Coral

3.7.3 ..................................................................................................... 27 ESS Crisis

...................................... 32 4 Incident Systems Assessment, Conclusions and Recommendations

4.1 ..................................................................................................................... 32 Summary

4.2 ............................................................................ 32 Conclusions and Recommendations

..................................................................... 35 List of symbols/abbreviations/acronyms/initialisms

.............................................................................................................................. 37 Distribution list

DRDC Atlantic CR 2008 179 vii

List of figures

Figure 1: Command View is a strategic level situational awareness tool that was initially

developed as a prototype to demonstrate the value of web portal technology to the

CF................................................................................................................................ 16

Figure 2: While ACT has not been developed to function as an Incident Management System,

it may be useful for providing FP boat information to users of an IMS. .................... 17

....... 20 Figure 3: E Team has been in use at the Nova Scotia Provincial EMO since October 2007.

Figure 4: E Team provides a full managed response capability, including remote access by

responders. .................................................................................................................. 22

Figure 5: E Team’s GIS display allows users to display the locations of incidents, responders,

and assets through the use of graphical icons, which are displayed in layers. ............ 23

Figure 6: Black Coral’s SoftRisk product is a fully functional IMS that provides a GIS COP

based on Microsoft Virtual Earth. ............................................................................... 25

Figure 7: SoftRisk displays geo referenced information, including sites, on layers within its

GIS COP...................................................................................................................... 26

............................................. 27 Figure 8: Black Coral’s LIVE software is its flagship GIS product.

Figure 9: ESS Crisis was used by the New Brunswick Emergency Measures Organization to

manage the response to the 2008 flooding along the Saint John River....................... 28

Figure 10: ESS Crisis allows users to create new instances of incidents directly from the GIS

display. ........................................................................................................................ 30

Figure 11: ESS Crisis’ messaging capability organizes messages based upon the incidents to

which they are related. ................................................................................................ 30

Figure 12: ESS Crisis provides information about each incident within icon balloons on the

GIS display. Users can click on a link to be directed to tabular based incident

information within the system..................................................................................... 31

viii DRDC Atlantic CR 2008 179

List of tables

.................................................... 18 Table 1: Initial list of surveyed Incident Management Systems

................................................................................ 20 Table 2: Capabilities and features of E Team

......................................................................... 24 Table 3: Capabilities and features of Black Coral

........................................................................... 28 Table 4: Capabilities and features of ESS Crisis

DRDC Atlantic CR 2008 179 ix

x DRDC Atlantic CR 2008 179


DRDC Atlantic CR 2008 179 1

1 Introduction

This study was initiated under the MFP Technology Demonstration Contract, W7707

063601/001/HAL consisting of two main requirements each contained in a separate volume:

Volume 1: To perform a study to explore the scope and capabilities of Incident Management

Systems (IMS) in the context of Command and Control (C2) and Maritime Force Protection

(MFP). The study has investigated and summarized the following topics:

a. A concise definition of Incident Management Systems (IMS);

b. A summary of typical IMS features and capabilities, and a discussion of the range of

non typical capabilities;

c. A mapping of IMS capabilities to the context of MFP C2;

d. A summary of the existing IMS solutions being used on the East and West Coasts, as

well as in local Emergency Measures Organizations (EMO); and

e. A review of one or two sample IMS solutions to support the MFP C2 context.

Volume 2: To develop and document a high level Unified Modeling Language (UML) model of

MFP related Incident Response Management at CFB Halifax:

a. Incident Management as implemented in Halifax;

b. Capturing key entities (people, information, systems) and interfaces between these

entities; and

c. A generic model to show where Incident Management could be improved.

This study was performed with consideration of the objectives stated in the SOW, as follows:

The purpose of this TA is further the team’s understanding of incident management systems

(IMS), and investigate if/how advanced IMS technologies could apply within the context of the

MFP TDP. The results will include a review of IMS capabilities and a high level model of

Incident Management in CFB Halifax. The outcome of this study is to support DRDC and the

client in determining the context of IMS technologies for MFP, and how IMS would fit within

existing processes and doctrine.

2 DRDC Atlantic CR 2008 179

1.1 Document Overview

The results of the study are reported in two volumes as follows:

Volume 1 – Unlimited distribution

Section 1: Introduction and Overview of Approach

Section 2: Review Criteria

This section presents the criteria used to review and compare the various C2 systems.

Section 3: Incident Management Systems Survey

This section presents the analysis of the IMS solutions identified as relevant to the MFP

task and SOW.

Section 4: IMS Systems Assessment, Conclusions and Recommendations

This section provides a summary of the system survey, and presents conclusions and

recommendations.

Volume 2 – Limited Distribution (DND and Defence Contractors)

Section 1: Introduction

Section 2: Incident Management UML Model

This section presents the analysis of the IMS SOP identified as relevant to the MFP

task and SOW.

Annex A: Incident Response Management UML Model

This annex provides the model of an Incident Response Management process that is

employed at CFB Halifax.

1.2 Applicable and Reference Documents

1. Task Authorization 9 (TA #9): W7707 06 3061 – Incident Management in a C2 Context

2. Task Authorization Response: Maritime Force Protection TDP Task Authorization 9: Incident

Management in a C2 Context, MDA document 01 5035

3. Task Authorization 3 (TA #3) Contract Report: C2 COTS System Survey for the Maritime

Force Protection TDP

4. Task Authorization 6 (TA #6) Contract Report: Survey of Force Protection Information

Requirements for Fleet, Base and Port Security Personnel


2 Review Criteria

2.1 Prior Interviews and Research

Task 3 of the MFP TDP identified a requirement to investigate Incident Management Systems

(IMS) as an integral component of MFP C2 Systems. Additionally, MFP Task 6 indicated the

need for improved IM systems for CF Emergency Operations Centres (EOC). Task 6 provided an

initial summary of desirable features that the interviewees indicated they would want in an IMS.

These features included:

• IMS technology that could be integrated with, or replace, other systems currently in use,

• An IMS designed with the users’ needs and tasks taken into account so as to not add to the

already high workload,

• An IMS tailorable for the different roles and positions as well, so that users get only the

information they need and not necessarily the full picture.

• An IMS that can display real time information (e.g., “Red – Enemy Assets, Blue – Friendly

Assets, White – Neutral Assets and Green – Environmental information”) in the form of a

Common Operating Picture (COP) on a geospatial display. The COP should include the

following features:

A map that is easy to zoom in/out on and pan (would include street names and

building markers on land)

Dragging and dropping of land assets (e.g. police car, MP barrier)

Real time locations of all boats in the area of interest (and any associated AIS

information)

Real time locations of all land assets in the area of interest

A radar overlay similar to the one in the ECPINS system

Electronic Chart overlay

Course, speed and fuel levels of the RHIBs

Historical data display (e.g. electronic logging) of certain threats/events so that one

can learn from previous situations that were similar.

Alerts to indicate threat level changes.

• An IMS that provides more direct and secure voice communications as well as the ability to

communicate with others through file sharing, whiteboard and chat.

• Ideally, an IMS that provides camera feeds (or “eyes on”) from additional areas around the

different ports/bases.


2.2 Review Criteria

In addition to collecting requirements defined in previous MFP taskings, a number of potential

COTS IMS solutions were identified and compared. A number of standard COTS IMS features

were identified, as well as some non standard features that were not inherent to every identified

system. As a sanity check, the MFP Command and Control structure of CFB Halifax was

modeled in the Unified Modeling Language (UML) and reviewed with previous and current

members of the Canadian Navy as well as DRDC personnel. This model was used to define

additional requirements that would be placed upon an IMS for potential use in managing force

protection related activities at CFBs Halifax and Esquimalt. These requirements have been

consolidated with the previously derived set and are presented in the following sections.


3 Incident Management Systems Survey

3.1 Introduction

The Incident Management System (IMS) survey was conducted during August to October 2008

by the members of the MDA team. The initial steps of this survey entailed an on line search for

OTS IM systems in order to determine what types of systems were available and what their

general characteristics were. IM system searches were made by searching on a number of terms,

including Crisis Management Systems, Incident Command Systems, Incident Response Systems,

Incident Command Systems, and Emergency Response Systems in addition to IMS. Several

potential candidates for a COTS IMS were identified and a preliminary list of general features

and capabilities was identified.

3.2 Definition of IMS

Before attempting to define what exactly an Incident Management System is, we should first

examine the nature of an incident itself. In the context of this study, an incident is a current or

impending hazard that must be managed in some respect in order to reduce its probability of

occurrence, impact, and/or scope. In more practical terms, this means that there is a current,

potential, or impending danger to personnel or infrastructure that must be mitigated and brought

to a timely and efficient conclusion. Examples of incidents include fires, natural disasters,

medical emergencies, and situations requiring policing. Within the context of force protection,

incidents may include terrorist attacks on infrastructure such as naval vessels or bases, or attacks

against military personnel or civilian personnel working at military sites. Note that in addition to

the management of the original incident, there is an equally important (and often longer lasting)

consequence management component, where the effects of the incident need to be managed over

the longer term.

The stakes can be very high when managing an incident, as an inefficient or ineffective response

can be very costly in terms of consequences to both human life and monetary impact. Proper

incident management, however, is a complex capability to implement. A number of problems can

arise when managing these situations and are generally common across all types of incidents:

• The actions of multiple agencies or groups need to be coordinated. Larger incidents may

involve a number of diverse groups, such as local, national, and military police forces,

service branches, health responders, and fire departments. Each of these groups may have

their own Concept of Operations and have very little organized communication with each

other. The solution to this problem is to give a single body (generally called an Emergency

Operation Centre, or EOC) overall control and communications authority for incident

management.

• Time can be lost and response efficiency can be reduced through the lack of efficient

operational plans for all preconceived incidents. On the fly incident management is a worst

case scenario and exposes response organizations as being ill prepared and unable to

perform their expected duty. When presented with new incidents, emergency response

managers should already have pre established plans of action which have been improved

through cycles of realistic testing or operational use.


• EOC response managers may not have access to a properly managed operational picture.

What this means is that for any particular incident the EOC may not fully understand the

locations and status of responders or related physical assets, or have a managed, persistent

log of what has already happened during a response and what still needs to be done. There

are three main reasons for maintaining such a operational log:

Steps in the response do not get skipped or forgotten. For example, a step that says

“Contact local Red Cross” may result in a phone call that gets made, but not

answered. Unless the incident manager is periodically reminded to complete this

step, it may be forgotten and not carried to completion.

Personnel changes should not result in a loss of situational awareness. There needs

to be a persistent mechanism for maintaining the situational awareness despite shift

changes, especially for longer duration responses. Operational information should

not be lost when a new person starts their shift.

The log can be used to generate daily or weekly situational awareness reports that

can be fed back up the command chain.

• Responders often do not have efficient access to all of the operational information they need

when responding to incidents, if they have access at all. For example, police directed by

EOC personnel to an incident can benefit by knowing the locations and status of all other

responders to an incident, as they may have to redirect traffic, handle protesters, or establish

safety perimeters. Ideally, responders could report their own status either manually or

automatically to the COP, and then be able to view the COP themselves, with the caveat that

the information may be filtered so that only the right information (and possibly not the

whole operational picture) is presented to individual responders. In addition to human

resource information, there is also a physical resource information requirement. Responders

and managers need to know where physical resources exist and what their availability status

is. For example, after a natural disaster such as a flood, there is a huge number of physical

resources that are required, including food, clothing, temporary shelters with beds,

construction equipment, and generators, just to name a few.

In light of these common, incident management related problems, it can be seen that technology

can play a major role in maximizing the efficiency of incident response and reducing the impact

of critical incidents upon infrastructure and personnel. While it is paramount to have an

organized, well staffed, and well prepared response organization as well as the supporting

communications infrastructure, it is only natural to develop and implement technology to further

assist incident managers and responders by mitigating the problems discussed above.

Emergency response planners and managers have already recognized the potential for technology

to assist them in carrying out their jobs, resulting in computer based Incident Management

Systems (IMS) to address many of the outstanding problems related to incident management. The

concept of an IMS is not new; they have been in existence for decades and are being used at

thousands of locations throughout the world. Many of these systems were originally developed

for specific types of incidents, such as toxic spills or site security monitoring, but have expanded

in capability over the years to become highly featured, enterprise class management systems. It

should be noted that the events of September 11, 2001 were a catalyst for IMS development,

improvement, implementation, and standardization, as the U.S. Department of Homeland Security

(DHS) identified the need for a country wide standard for emergency response management and

consequently developed the National Information Management Systems (NIMS).


Despite the name, NIMS is actually a procedural framework as opposed to a physical system, and

defines the approach that is to be used by all three levels of government when managing

responses to natural disasters or terrorist attacks. The introduction of an IM national standard has

encouraged IMS developers to modify their products to be compatible (i.e. NIMS compliant)

with the DHS’s specification.

With this said, we can now better define what exactly an IMS is and what it does. Put simply,

IMSs help response managers to mitigate the core problems mentioned above, namely:

• Coordination of activities among a group of diverse and physically separated organizations

or groups during the response to an incident.

• Storage and refinement of predefined, standard operational procedures (SOPs). Most IMSs

perform logging of actions and events, so that over time, these SOPs can be examined

forensically post event and improved.

• Operator assistance in managing instances of events. IMSs provide operators with the ability

to instantiate a single instance of a SOP for a particular type of event and then track the

instance to ensure that each discrete task within the SOP is completed. This “checklist” can

be shared among a number of users, meaning that no one user is the only one to fully

understand the current situation.

• Generation and sharing of a real time Common Operational Picture (COP). The COP can

take on two basic forms. The first is a textual style list, showing all involved units, their

locations, and their status, while the second is a true GIS style display, which provides a

mapping capability and the ability to display icons for responder units along with related

status information. In general, the incident manager updates the responder locations

manually based on unit feedback, but in more advanced systems (in terms of GIS

capability), responders have remote access to the COP and can update their own location

and status information, either manually or automatically.

It should be noted, however, that the term “Incident Management System” is not a standardized

term among incident response organizations or IMS vendors. As mentioned earlier, the OTS

system survey was carried out using a number of similar, but different terms which are used

interchangeably, sometimes to represent the same thing, but sometimes not. In general, however,

IMSs fall into two main categories: strategic systems and tactical systems. Strategic IMSs are

generally used by high level incident management organizations such as federal, state, or

provincial EOCs. These systems allow EOC personnel to list and track incidents at a high level,

pass overall response authority horizontally to parallel organizations (i.e. designate a “lead

agency”) and provide status information to higher levels of government. An example of a

strategic IMS is ESi’s WebEOC software. Tactical IMSs are different from strategic systems in

that the primary user (in this context, the BOC) is also assumed to be the lead agency. Tactical

IMSs are generally smaller in scale, but provide a downward Command and Control path to

responders (or response organizations) as well as a return path for status information. Information

may be shared with parallel and higher level organizations, but these data paths are not meant to

be the primary focus of the system. Due to the Command and Control nature of tactical IMSs,

they are often referred to Incident Command Systems (ICS) in either their entirety or in part. Due

to the particular requirements posed by the FP problem (i.e. the primary user in the BOC is the

Incident Controller), it was decided to focus on tactical, ICS type features as opposed to strategic

level IMS features. The following sections of the document reflect this decision. Although the

discussions continue to use the generic title “IMS”, the underlying intent is to describe IMS

features and capabilities as they apply to Incident Command.


As Incident Management can be a large, complex undertaking, OTS IMSs provide a large number

of specific features. There is a large set of overlapping capabilities among most IMSs, and a

number of non typical features that are vendor specific. These features are described in the

following sections.

3.3 Typical IMS Features and Capabilities

To assemble the following list of typical IMS features, a web survey was conducted to determine

which systems were a) leaders in the market, or b) had specific capabilities of interest for FP

activities conducted by the CF. The features presented by these systems were compared to

determine what capabilities overlapped and which were unique to particular systems. This

section describes the features that were common to all IMS solutions investigated as part of the

survey.

In general, IMS provide the following features and capabilities.

Management of Incident Response as sets of defined and allocated tasks. IMSs provide users

with the tools to manage multiple incidents simultaneously, by allowing incident response

activities to be managed as a series of individual tasks that can be assigned to personnel or

groups. These series of tasks are predefined as Standard Operating Procedures (SOP), which are

based upon the nature of the incident for which they have been developed. Once a particular

incident has occurred, the operator can instantiate a single instance of an SOP as a managed

checklist and assign the individual tasks within it to responder units and personnel. The IMS will

maintain a record of the status of the tasks to ensure that the Incident Commander knows what

has not been assigned, what is still in progress, and what is incomplete. Some systems

automatically track task progress and can notify the operator if tasks are not completed by a

particular time. Task status updates can be entered by the Incident Commander or directly by

responding groups, agencies, or individuals that have remote access to the system. Once all tasks

have been completed, the system will mark the incident response as complete.

This automated or semi automated capability provides a number of benefits:

• Incident Response is consistently managed, as it is based upon predefined SOPs. This helps

responders to become more efficient over time as they are consistently assigned the same set

of tasks, and makes it easier to spot SOP inefficiencies and fold the improvements back into

the system.

• Tasks within the response to a particular incident don’t get lost or forgotten, ensuring that

incidents are properly tracked and managed through to completion.

• The operational state board (i.e. listing of active incidents with associated task checklists)

are available to everyone with access to the system, assuming they have been assigned the

appropriate permissions. This ensures that no single individual is the only person to

understand or have access to the operational picture. This is particularly important in light of

the fact that personnel shift changes may (and usually do) occur during incident response.

The shared operational picture also makes it easier to move the primary user site to another

location in case of power failure, fire, etc.


• Decreased workload for the Incident Commander. Because the system maintains the state

board for all active incidents, the Incident Commander can concentrate on the job ahead as

opposed to maintaining the current operational picture. In addition, remote units, groups,

and agencies can update their own status, removing this burden from the Incident

Commander.

The display of incidents and events in a geospatial display. All IMSs surveyed provided this

type of capability, although the level of GIS functionality varied considerably, as did the

comprehensiveness of the linkages between the GIS display and the text/tabular portion of the

system. For example, some systems allow users to create new incident instances directly from the

GIS display, while others only display icons for incidents already created through the text/tabular

portion of the system. Other GIS displays are little more than drawing tools, letting users place

icons, polygons, etc. at will on a map and sharing this picture with other users. In some cases, the

GIS component seemed like more of an afterthought, although the corresponding vendors seemed

to have recognized this and were improving the GIS capability. Features that were common

included:

• Geospatial displays are provided via interfaces to commercial GIS mapping software. The

most common mapping APIs used in these systems were ESRI ArcGIS and Microsoft

Virtual Earth. None of the systems surveyed had proprietary mapping. The use of

commercial mapping packages provides a number of advantages, including operator

familiarity, feature richness, open standards (in the case of ESRI) and relatively low cost.

Note, however, that a standalone server implementation of Virtual Earth on a private

network could involve significant licensing fees.

• Icons to represent incidents, personnel, resources, and facilities. In all implementations,

these icons were presented in layers, meaning that particular types of icons could be enabled

and disabled. Some systems allow users to directly access incident information by clicking

on the icon to bring up an information “bubble” displaying information from the system

database regarding the that particular incident.

• Sharing of the GIS operational picture as part of the COP. All information entered through

the geospatial display is shared with all other users who have access to the geospatial

component and have the appropriate access privileges.

The capability to create Situational Reports (SITREPS) on the current state of the incident response. This capability can serve a number of purposes. First, it can be used as a tool to create

briefing materials for decision makers who may not have direct access to the system or who may

only need to know the overall operational picture at a very high level. A second purpose is to

create briefing materials for local media, who ultimately keep the general public informed.

During crisis events it is imperative to keep the affected public informed as to what is currently

happening, when assistance will be provided, what action they should take themselves, and when

the situation will be resolved.

The capability to log all user activities during an incident response. All IMSs surveyed have

the capability to record and retrieve time stamped logs of all significant events during incident

response. There are two main reasons to have a post event log of user activities: The first is to be

able to go back through the activity log to identify errors, omissions, or inefficiencies that can be

mitigated in the future by modifying the associated SOPs. The second is to provide a post event

action log for personnel training. By reviewing and comparing the action logs after training

sessions, it is possible to identify specific areas where individual users are lacking adequate skills.


Messaging. The ability to exchange information using a messaging capability is extremely useful

when managing teams, agencies, or individuals using an IMS. Not only is it fast and reliable, it is

readily available to all of the IMS users, as it is provided as one of the IMSs capabilities.

Messages can generally be directed at individual users or groups of users, much the same as

email.

Access based on organizational structure. As with most organizations, IM and incident

response agencies have hierarchies that require different levels of data access for the varying roles

of the personnel and groups within. Consequently, IMSs provide the ability to configure user and

group accounts to limit read and write access to different types of data. For example, the Incident

Commander at the EOC would likely require read and write access to all portions of the system,

whereas a higher level observer such as a media relations officer would only need read access to

high level information across all of the current incidents. On site responders would have their

accounts configured to display only the information they need to get their jobs done quickly and

efficiently, such as the geographical COP and tasks directed specifically to them.

Training. All of the systems examined provide some sort of training and simulation capability,

mainly through the existing functionality. Simulated or training scenario incidents can be entered

into the IM systems (either on the active system or on a training instance) and managed as if they

were real incidents, with trainees managing the response. Trainer personnel can add to the

scenario by adding and allocating tasks to users and adding new incidents in real time. After the

event is over, the operator logs can be reviewed to assess operator performance and to identify

areas of improvement.

3.4 Non-Typical IMS Features and Capabilities

Across the various IMSs that were examined, a number of features and capabilities were

identified that were specific to only a single IMS or to a subset:

Automated, real-time interfaces to external sensors and reporting systems. These types of

interfaces include AIS, GPS, radar, and surveillance cameras. In general, IMSs do not provide

these types of sensor information, as they are intended to primarily function as a process

management tool to allow humans to effectively and efficiently manage the activities of other

humans. In addition, the GIS component of most of the systems is not intended to be a real time

display of vehicle or other responder locations; rather it is meant to be a high level physical

overview of an incident so that commanders and responders know the general locations of

responders and related assets, with the understanding that tasked units either a) manage their own

activities onsite, or b) are directly managed by their respective organizations, and not by the

Incident Commander.

Chat capability. Messaging is ubiquitous among the various IM systems, with distribution being

based on transmission among individual personnel or entire groups. Chat however, is not offered

by all vendors. Where it is offered, it generally follows the Internet model, where chat groups (i.e.

“chat rooms”) can be set up and users can subscribe to these groups.


Web browser-based user interfaces. Although this feature is presented in the non typical

features section, the vast majority of IMSs on the market are based on web technologies. The use

of web technology to implement IM capability provides a number of benefits, including:

• Users are already familiar with the interface.

• The system can be deployed on existing servers and user computers, regardless of the

platform or OS (with some exceptions). On the server side, technologies such as the

application server and the database are generally hardware and OS agnostic, and on the

client side, users only need web browsers, which are available for all of the most common

platforms.

• Complicated client side software updates are not necessary, because all of the data and

business logic are hosted on a central server. Users only have thin client access. Software

update rollouts only need to be done on a single server or cluster of servers, usually at a

single location.

• Ability to continue service even after a major infrastructure loss. An example of this is the

rebuilding of the New York City EOC in the days immediately after the attacks on the

World Trade Center on September 11, 2001. The NYC EOC, which was to go online with

its new web based IMS system on September 17, was completely destroyed due to its

location at WTC #7. The IMS vendor re hosted the EOC application on its own ASP servers

and made it immediately available to emergency agencies within the city. By September 14,

once the requisite network infrastructure was implemented, the EOC was fully up and

running again in a converted warehouse.

PDA capability. Because most of the IMSs surveyed are based on web browser technology, they

are, by default, accessible to anyone with a network connection (fixed or wireless) and a PC

based computer (including tablet PCs). PDAs are a similar technology to which IMS vendors are

interested in extending their products. These devices are generally designed to be highly mobile,

well featured, and networked over existing wireless network infrastructure. Unlike laptops and

tablet PCs, however, PDAs are much smaller, meaning that screen space is at a premium, and

because PDAs would probably be used at the lowest levels of the response hierarchy, the

information presented to users needs to be reduced so as not to overburden these users with too

much information beyond what they need to know. Of the systems surveyed, one currently has a

PDA version, while another has a PDA release planned for the near future.

3.5 Mapping of IMS Capabilities to the Context of MFP C2

Commercial IM systems, while very functional and feature rich, need to be put into the context of

maritime force protection activities before one can assess their value to the CF in protecting

personnel and infrastructure from attack and the subsequent effects. These systems have generally

been designed for civilian agencies, although it should be noted that a large number of military

facilities throughout Canada, the U.S., and the rest of the world use these systems to safeguard

their assets and to manage their response to many types of incidents, including terrorist attack. In

fact, since 9/11, the value of IM systems in managing and mitigating terrorism based incidents

has been a key focus of the U.S. Department of Homeland Security, resulting in NIMS (the

National Incident Management System). Most major IMS vendors now claim that their products

are NIMS compliant.


With this said, however, it still remains to examine the particular requirements posed by the FP

problem on both coasts and to determine to what extent commercial IMSs address these needs.

From the personnel surveys conducted as part of MFP task authorization #6, discussions with

MFP SMEs, and auditing of training scenarios at the BOC, a number of high level requirements

have emerged. These requirements, along with a discussion of the extent to which commercial

IMS solutions address them, are presented below:

• Managed SOPs. Force protection against terrorist attack and mitigation of the subsequent

effects requires a fast, efficient response. This means that SOPs must be planned far in

advance of any predicted attack scenarios, improved through multiple cycles of simulated

trials, and executed in an efficient manner. Based on the work described above, it is

apparent that neither Halifax nor Esquimalt has fully reached this level of maturity in

managing FP events. The number and completeness of current FP SOPs is not adequate, and

the response based upon the SOPs that currently exist is very human centric and inefficient.

Auditing of a simulated incident at the BOC in Halifax revealed several problems:

SOPs are stored within CommandView as static web pages. These pages provide no

task management capability, only a list of actions to take. This resulted in a lot of

questions back and forth across the room among the various personnel as to who had

already been contacted, and what the current situation was. Personnel assigned to the

different means of communication (i.e. radio, telephone, chat) could not directly

enter the status of their own activities, requiring the BOC OOW having to

periodically ask these personnel what they had accomplished. The MP in the BOC

had the best understanding of the situational picture, but he was very busy on both

radio and phone and found it difficult to keep up with communications and keep the

OOW informed at the same time. While the SOP was projected onto the wall for all

to see, it was a static view of what needed to be done, and not what had been

completed.

Tasks are assigned to personnel through inefficient means. Most of the commands

going out from the BOC were sent over radio and telephone. Communications were

generally bottlenecked, as one person was in charge of all command and control

related communications. In addition, remote units were reporting back through these

same channels, adding to the traffic.

Actions were not being automatically time stamped and recorded in a persistent

electronic log, making it difficult to do post event forensics to determine where the

problems were so that improvements could be made to the SOP. In the current BOC,

a person is required to maintain manual logs. The inability to automatically log

events severely curtails the usefulness of training events, as process improvement

should be one of its primary goals.

The OOW spends a considerable amount of time briefing his superiors on what was

happening instead of managing the tactical situation.

• COTS IMSs help to solve all of these problems. First of all, they present instantiations of

SOPs as automatically tracked checklists of tasks which can be assigned to other personnel

directly through the system. These “checklists” can be projected onto the wall in an

Operations Centre, letting all personnel within understand what needs to be done, what has

been done, and what is in progress, simply by glancing at the display. In addition, remote

users (or other groups managing individual responders) can manually enter their own status

and have these updates appear at the BOC for all to see without BOC personnel

involvement. This system inherent command and control capability takes a significant bite

out of the communications requirements between incident commanders and responders.


In addition, COTS IMSs generally provide built in messaging capability, and some provide

chat. Because the operational picture is available for all to see, this also eliminates the

problem of a single individual within the BOC having the best understanding of the overall

picture, which is a significant problem during shift changes. COTS IMSs also provide

automated operator event logging so that post event forensics can be performed to spot

deficiencies and to fold solutions back into the SOPs. Lastly, higher level users such as a

Base Commander or a Public Affairs officer can log into the system themselves to directly

view the event checklist or to generate incident reports tailored for their position.

• A GIS based Common Operating Picture. Personnel on both coasts indicated the need for a

GIS based common operating picture, with standard mapping functions like pan, zoom, etc.

The COP would display land maps or nautical charts and display drag and drop icons to

indicate incident locations, responder locations, and other assets. Other desirable features

included overlays of data such as radar video, vessel locations from ARPA radar and AIS,

and the ability to display the real time locations of FP craft. This requirement was reflected

in the fact that the BOC has a direct screen feed from QHM’s harbour display, as well as the

interest on both coasts in the ACT system for the FP boats. COTS IMSs provide a large

portion of this GIS functionality as a standard feature. Most have a GIS component that is

shared among all users, and any user with the appropriate access can place various types of

icons on the map to represent incidents, responder units, and assets such as police barriers.

Mapping engines are all COTS based and will display most standard map formats for

terrestrial and nautical charts, as well as specialized file formats such as AutoCAD. Overlay

of sensor data, especially real time data, is generally not an IMS function, however. IMSs

are primarily intended to allow users to coordinate and manage the activities of other people

in response to an incident as opposed to providing a surveillance capability in the same vein

as a C4I system. Icons on the GIS display are primarily used as a means to indicate that

responder organizations are onsite and carrying out their assigned tasks, as opposed to

providing the Incident Commander with enough granularity in situational awareness to

directly command individual responder personnel. It is generally understood that the

Incident Commander should be tasking responder organizations with higher level tasks, and

then letting these organizations conduct their own activities at a lower level. With this said,

however, a COTS solution was identified that has been designed to provide interfaces to,

and overlays of, sensor feeds (albeit with some NRE). If a system such as ACT could be

configured to provide FP boat information in a commonly used format (such as radar ARPA

or NMEA AIS) then this data could be imported by this mapping application and displayed

to users.

• Improved communications channels. It is generally agreed upon across the entire FP

organizations on both coasts that communications are currently a problem. Communication

channels currently include telephone, handheld radio, MCOIN chat, as well as MCOIN

messaging. Each of these presents its own particular problems, including;

Unanswered phone calls

Reliance on public telecom systems

Lack of encryption

Lack of user accounts or other inability to access computer based communications

systems

Lack of radio operating procedures.


While IMSs do provide some communications paths, such as messaging and chat, it should

be noted that most COTS IMSs do not address the issues listed above, nor are they intended

to. IMS vendors leave the communications paths up to the various agencies that use the

system and provide a means for users to control and monitor the actions that take place over

these paths. As described earlier, however, the messaging, tasking, and reporting

capabilities built into these systems may make some legacy comms channels obsolete, as

long as remote users have system access.

• Event Management. In addition to responding to incidents, FP personnel on our coasts

must also be able to control and monitor activities during pre planned events, such as the

entry of a foreign warship into a Canadian port. This type of incident is different from

normal FP activities, as each incident may require a specialized, one time only operating

procedure. Most IMSs also provide this capability, whereby individual OPs can be

generated, instantiated, and tracked. A good example of this IMS capability is their common

use in planning and monitoring visits by political dignitaries.

• Ease of use. A number of CF personnel expressed the requirement to be given a system that

was easy to learn how to use. This is especially important for two reasons: 1) The military

has a high staff turnover rate, meaning that training must be performed on an almost

continuous basis, and 2) A system that is difficult to operate will not be well accepted and

may go unused. IMS vendors have recognized this, and have designed systems that are very

intuitive. COTS IM systems are used in hundreds (perhaps thousands) of locations by

thousands of users at all levels of technical ability, including military installations. For IMS

vendors, a decrease in usability means a decrease in market share. More recently, vendors

have made their product NIMS compliant, which has standardized the methodology by

which responders and incident commanders in the U.S. conduct their activities. This has

resulted in a whole suite of IM systems that have a high degree of commonality in how they

are to be used, and in terminology.

• Site redundancy. There are two main reasons why site redundancy is important for

protecting our bases. The first reason is more generic: Redundancy in site location means

that destruction of or inability to staff a primary site means that the IM capability can still

continue to run at a second location. An example of this might be damage to the BOC in

case of an explosive attack on the CFB Halifax Dockyard. The primary site could be moved

to the MP dispatch in Willow Park, for example. A second reason for site redundancy would

be for temporary IM staffing until the BOC is stood up. For the time being, the BOC is not

operational 24/7, but is only staffed in times of heightened alert or after a significant event.

Redundancy would allow a continuously staffed entity such as the MP dispatch or the RJOC

to act as the Incident Commander until responsibility could be handed over to the BOC.

Fortunately, most COTS IMSs are web based, meaning that the system server is location

agnostic, and can be placed in a safe location far away from potential FP danger locations

and accessed remotely from anywhere with a network connection. Any group or

organization can become a primary user by being given the appropriate level of system

access through their user account.

• An IMS tailorable for different roles and positions. CF personnel at all levels of the FP

command chain have expressed the desire to be given a system that is tailorable for their

particular roles. For the Incident Commander, this means that virtually all information

within the system is available. For the various responders, it will be necessary to constrict

their understanding of the COP and the tasking checklists only to the information that

pertains directly to them and to the duties they have been assigned. Users at the periphery of

FP activities may only wish to see their own assigned tasks and nothing else, including the

COP. In most cases, efficiency can be improved by restricting information flow on a “need


to know” basis. This is another issue that IMS vendors have recognized and addressed. Most

COTS IMSs allow organizations to model their organizational structure as a set of user

accounts with varying degrees of system access. Users or groups who get assigned with

tasks by the Incident Commander are generally restricted to viewing only their own tasks (in

fact some vendors provide a “My Tasks” page to make things as simple as possible for

users).

3.6 Existing IMS Solutions

The following IMS and IMS related systems are currently in use by the Canadian Forces in

Halifax and Esquimalt.

3.6.1 Command View

Command View (CV) is a global, high level, strategic incident and event information sharing tool

available through the DND SECRET Network. CV is provided through a web portal, and

provides a geospatial mapping application utilizing colour coded flags (Maple Leaf Icons) to

display the location of incidents and events. The application has the capability to store and

display documentation including SOPs, has the inherent security features of the SECRET

Network, and provides the Readiness status and Rules of Engagement (ROE) currently in effect.

Recently, it has been modified to provide an Incident Management capability, but it should be

noted that this capability is aimed at global, strategic level operations and not at local tactical IM

operations. In support of IM, Command View allows operators can place incident markers upon

the map, enter some textual information describing the incidents, and view SOPs.

While CV functions very well for its originally intended purpose, it is somewhat lacking in

capability in managing highly localized, fast paced FP incidents. Major deficiencies on CV in

terms of FP IM include: inability to create checklists from SOPs, no task allocation capability, no

responder SITREP capability, no operator logging, no messaging, and difficulties in extending

capability to remote units over wireless links because of security concerns.

Figure 1: Command View is a strategic-level situational awareness tool that was initially

developed as a prototype to demonstrate the value of web portal technology to the CF.

3.6.2 Asset Control and Tracking

Asset Control and tracking (ACT), from OSI Geospatial Inc., provides control and tracking of

smaller maritime assets such as harbour patrol vessels and deployed RHIBs. It is currently in use

at CFB Esquimalt, and has undergone an evaluation trial at CFB Halifax. Through the use of

ACT, a larger vessel or a shore facility (known as the Parent Unit) can exchange information with

small vessels to improve the overall situational awareness of all personnel involved.

ACT consists of two main components, both of which are based on ECPINS technology. The first

component resides at the parent unit, and provides full WECDIS and AIS capabilities. The second

component, ACT SC, resides on each of the assets, and consists of a radio transponder, computer,

and operator display. ACT SC provides the asset with an electronic chart capability, AIS, and the

ability to exchange information with the parent unit. The parent unit communicates wirelessly to

one or more assets over user selectable VHF channels, which may or may not be encrypted.

Assets can also be configured to communicate with each other.

While ACT is not an IMS, it may be able to interface with one so that IMS users can view the

locations and status of FP boats in Halifax and Esquimalt in real time.


Figure 2: While ACT has not been developed to function as an Incident Management System, it

may be useful for providing FP boat information to users of an IMS.



3.7 Sample IMS Solutions

As part of this study, a survey of COTS IMS solutions was conducted, which had three main

purposes:

• To determine commonalities and differences in the capabilities provided by COTS IM

systems, so as to more precisely define the characteristics of Incident Management Systems

as they apply to the MFP context. These results were presented earlier in this document.

• To identify systems that met the IM requirements presented by the FP problem at CFBs

Halifax and Esquimalt. Some of these requirements came directly from CF personnel as part

of previous taskings, while others were developed through discussions with SMEs and on

site auditing of BOC IM activities.

• To identify potential candidates for integration into DRDC’s virtual harbour experiment.

Fourteen IM systems were initially selected (see Table 1) using the following criteria:

• The system must be an OTS system.

• The system must be proven in the real world, i.e. have a proven user base.

Table 1: Initial list of surveyed Incident Management Systems

Vendor Product Hyperlink

NC4 E Team http://www.eteam.com/index.html

Ultra Atlas Ops http://www.atlasops.com/

OSI

Asset Control and

Tracking http://www.osigeospatial.com/offshoresystems/index.htm

JIIFC

Detachment Command View N/A

ESS Crisis http://www.ess-crisis.com/

Mission Mode

Solutions Mission Mode http://missionmode.com/

Intergraph I Asset/I Consequence http://www.intergraph.com/

AOT Public

Safety

Corporation Max Responder http://www.publicsafetycorp.com/

Black Coral SoftRisk/LIVE http://www.blackcoral.net

http://www.eteam.com/index.html

http://www.atlasops.com/

http://www.osigeospatial.com/offshoresystems/index.htm

http://www.ess-crisis.com/

http://missionmode.com/

http://www.intergraph.com/

http://www.publicsafetycorp.com/

http://www.blackcoral.net/


Vendor Product Hyperlink

esi911 WebEOC http://www.esi911.com/home/

Locus

Technologies eTask http://www.locustec.com/

Clark Reynolds

& Co. EOC System http://www.emergency-planning.com

Alert

Technologies

Corporation OpsCenter http://www.alerttech.com/

Previstar

CEM Planner /

Continual Preparedness

System http://www.previstar.com

Once these systems were compared with each other in terms of capability, it became much more

apparent which ones were most relevant to the MFP problem. The initial set of IMSs was then

shortlisted to four systems, and the corresponding vendors were contacted. All of the contacted

vendors conducted web demonstrations, as all of these systems were based on web technology

and were accessible via browser. After each demonstration, follow up questions were sent to the

vendors to solicit additional detail. Of the four systems, three were identified as tactical (versus

strategic) IMSs. These three systems, along with a discussion of their features and capabilities,

are presented below.

3.7.1 E Team

E Team, made by NC4, is one of the most commonly used IMSs on the market. It is a web based

product, and can be either self hosted or hosted on NC4’s ASP servers. It provides a full IMS

implementation, including a GIS COP display based on ESRI technology. Its features include the

following:

• User access based upon organizational structure

• Predetermined SOPs based upon incident type

• Delegation of tasks to individuals or groups

• Automated checklists

• Remote access by responders to view assigned tasks or to modify task status.

http://www.esi911.com/home/

http://www.locustec.com/

http://www.emergency-planning.com/

http://www.alerttech.com/

http://www.previstar.com/

Apart from any sensor integration work that may be required, E Team does not need to be

modified after installation. Administrators can configure the system for their own particular

operational environment (i.e., configure user accounts, SOPs, and reports) and then users can

begin using the system. The lack of up front NRE is very beneficial to many organizations which

a) need to be up and running quickly, and b) don’t have adequate funds to develop their own

customized solution.

Figure 3: E Team has been in use at the Nova Scotia Provincial EMO since October 2007.

Table 2: Capabilities and features of E Team

Capability/Feature Description

Managed Response Provides full management of incident response. Stores

previously developed SOPs, allows users to create multiple

instances of SOPs as checklists. Users can assign individual

tasks within checklists to responders. Responders can remotely

access the system to view their own assigned tasks and to

update the status of their own tasks. Alerts can be sent to other

users to indicate high importance events to other users that

require immediate intervention.

GIS Based COP Based on ESRI technology. Can display land based maps and

nautical charts, but is mainly aimed at the terrestrial market.

Users with appropriate access can view and modify the COP.

Data is displayed in layers, and icons are used to indicate the

location of geo referenced incidents. Not intended to display

real time locations of vehicles and vessels; vendor states that

this could be done, but that updates might be on the order of

minutes apart.

Messaging/Chat E Team provides real time messaging, chat, and alert

capabilities.

Organizational Access User structure can be built to match the structure of an

organization. Four levels of user access are provided, supports

accounts based on groups of single individuals. System can

store and display org charts.

Training Capability Provides both Operations and training Modes




Real time Sensor Integration

and Display

Possible, with significant NRE. E team is not designed to

provide this capability.

Reporting Capability E Team provides a large number of reports, including incident

reports, situation reports, infrastructure reports, and duty logs,

as well as a Crystal Reports interface that can be used to create

customized reports.

Logging E Team provides a full logging capability. All operator actions

are logged and time stamped, and can be audited post event.

Historical logs can be queried using the system.

PDA Capability PDA version under development

Third Party Development Yes. Interfaces can be built using the E Team Web services

interface, new components can be developed using the Web

Services architecture. Java and web based services

architecture.

Other Stores and provides online reference documents

Can connect to other instances of E Team for information

sharing and delegation of responsibility

NIMS and ICS compliant

Use in Canada The Nova Scotia Provincial EMO uses E Team as its Incident

Management System. E Team underwent its first provincial

exercise in October 2007.

Figure 4: E Team provides a full managed response capability, including remote access by

responders.


Figure 5: E Team’s GIS display allows users to display the locations of incidents, responders,

and assets through the use of graphical icons, which are displayed in layers.

3.7.2 Black Coral

Black Coral is an Ottawa based company that provides a number of software products which

address many of the requirements described earlier in this report. They provide four main

products:

• SoftRisk. SoftRisk is their main Incident Management product. It provides a number of IM

related features, including: user tasking and automated logging, live chat, discussion forums,

user, resource, and site management, GIS mapping (using Microsoft Virtual Earth), and

local or remote server hosting.

• LIVE. LIVE is a geographical application used by response teams to collaborate their

activities properly and to share information via a map based display. Information is

displayed using the ESRI ArcGIS engine, and users can annotate displayed objects. Unlike

SoftRisk, LIVE is a thick client application, and can continue to function without the

network being operational. Objects displayed by LIVE can be linked to Incidents within

SoftRisk. LIVE supports real time sensor data feeds such as GPS, AIS, and ARPA.

• HANDHELD. HANDHELD is a subset of LIVE that runs on Windows based PDAs it

provides much of the functionality of LIVE, but is designed to run on a much smaller

display with no keyboard capability.



• AXIS. AXIS is a software product that allows users to filter information within the COP

into multiple data feeds for distribution to an external user community. External users can

also post information back into the COP for others to use.

Table 3: Capabilities and features of Black Coral


Managed Response Provides management of incident response. Stores previously

developed SOPs, allows users to create instances of incidents,

define related tasks, and allocate tasks to responders.

Currently does not support checklist generation from stored

SOPs, but this is intended to be rolled out in late October or

early November 2008. Responders can remotely access the

system to view their own assigned tasks and to update the

status of their own tasks. Systems tracks alerts to completion,

provides notification when tasks have not been completed by a

certain time.

GIS Based COP SoftRisk has its own integrated GIS COP based on Microsoft

Virtual Earth. LIVE is specifically built to provide multi

agency collaboration through a GIS style COP. LIVE is based

on ESRI ArcGIS, and provides many features, including

automated synchronization of data between users, real time

communications, and editable data layers. Linked with

SoftRisk.

Messaging/Chat SoftRisk provides live chat and messaging.

LIVE provides chat, messaging, and collaboration through

Microsoft Groove.

Organizational Access Provides granular security, access based upon user role.

Training Capability Black Coral is currently working on this capability


and Display

LIVE is designed to provide this capability. Accommodates

real time data from sensors such as ARPA radar, GPS, AIS.

Rich API is provided to allow system developers to integrate

resource positions.

Reporting Capability Reporting is supported.

Logging SoftRisk automatically logs and time stamps all activities for

post event analysis

PDA Capability Yes. Provided by HANDHELD, runs on Windows Mobile


platforms. Highly featured.

Third Party Development Yes. Architecture uses open standards, third parties are

currently developing their own interfaces.

Other AXIS product allows users to publish and subscribe to geo

referenced alerts and data feeds.

Can be hosted locally or by an ASP.

NIMS and ICS compliant.

Use in Canada Black Coral products are used by Public Safety Canada and the

National Defence Command Centre (NDCC)

Figure 6: Black Coral’s SoftRisk product is a fully-functional IMS that provides a GIS COP

based on Microsoft Virtual Earth.


Figure 7: SoftRisk displays geo-referenced information, including sites, on layers within its GIS

COP.


Figure 8: Black Coral’s LIVE software is its flagship GIS product.

3.7.3 ESS Crisis

ESS Crisis is another fully featured IMS product, very similar in capability to E Team. It is used

by many large organizations across a number of domains, including militaries, oil and gas,

governmental emergency management, manufacturing, and postal services. It is also a web based

product, and can be hosted by an ASP or established as a local instance. It features an integrated

GIS COP based on Microsoft Virtual Earth. Its features include the following:

• Automated incident management, including automated SOP checklists and delegation of

tasks.

• An integrated GIS based COP based on Microsoft Virtual Earth. This COP provides all of

the benefits of Virtual earth, including maps, aerial views, and bird’s eye (oblique) views.

• Remote access by responders to view assigned tasks and to update status.

• Tracking of personnel and resources.

• State boards and situation reporting.


Figure 9: ESS Crisis was used by the New Brunswick Emergency Measures Organization to

manage the response to the 2008 flooding along the Saint John River.

Table 4: Capabilities and features of ESS Crisis


Managed Response Provides full management of incident response. Stores

previously developed SOPs, allows users to create multiple

instances of SOPs as checklists. Users can assign individual

tasks within checklists to responders. Responders can remotely

access the system to view their own assigned tasks and to

update the status of their own tasks. Alerts can be sent to other

users to indicate high importance events to other users that

require immediate intervention.

GIS Based COP Based on Microsoft Virtual Earth. Uses the VE API to display

icons to represent locations of responders, incidents, and sites.

Users can enter amplifying information by clicking on icons

and typing directly into the pop up balloons. Provides satellite,

map, and oblique aerial views. Users with appropriate access

can view and modify the COP. Data is displayed in layers. Not

intended to display real time locations of vehicles and vessels;

vendor states that this could be done, but that the system is not

built to provide this functionality and would require NRE.

Messaging/Chat Crisis provides a messaging capability.




Organizational Access Users can log in by name, organization, or position. Various

levels of user access.

Training Capability Provides a training capability


and Display

Possible, with significant NRE. Crisis is not designed to

provide this capability.

Reporting Capability Provides a SITREP capability, ICS standard reports,

assessment and recovery reports, and operational log reports.

Logging Crisis provides a full logging capability. All operator actions

are logged and can be audited post event.

PDA Capability Any device running windows will run the software, although

PDAs provide limited capability due to size.

Third Party Development Modifications are done by services contract.

Other Storage of staff qualifications

Automated notification/recall of personnel via email, phone,

fax, pager

NIMS and ICS compliant

Use in Canada The New Brunswick Emergency Measures Organization uses

ESS Crisis as its primary incident management tool. It selected

ESS Crisis in October 2007.

Figure 10: ESS Crisis allows users to create new instances of incidents directly from the GIS

display.

Figure 11: ESS Crisis’ messaging capability organizes messages based upon the incidents to

which they are related.


Figure 12: ESS Crisis provides information about each incident within icon balloons on the GIS

display. Users can click on a link to be directed to tabular-based incident information within the

system.



4 Incident Systems Assessment, Conclusions and Recommendations

4.1 Summary

The information provided in the previous sections of this document reflects the original goals of

the study portion of the SOW, namely:

• To make a concise definition of Incident Management Systems,

• To summarize typical and non typical features and capabilities of Incident Management

Systems,

• To map IMS capabilities to the context of MFP C2,

• To summarize existing IMS solutions being used of the East and West Coasts, and

• To review a number of IMS solutions to support the MFP C2 context.

In addition to this information, however, it was deemed necessary to review the information as a

whole to draw conclusions and to make recommendations for the way forward. These are

presented below.

4.2 Conclusions and Recommendations

After analyzing the IM requirements posed by the FP problem on both coasts, reviewing the

current organizational hierarchy, and comparing a large number of IMS solutions, it became

apparent that DND could benefit greatly from the implementation and use of a COTS incident

management system. The current processes and procedures for carrying out these activities on

both coasts are less than optimal for a number of reasons, including:

• Lack of situational awareness. There is currently no state board or common operational

picture that is shared among managers and responders. The current operational picture is

only known to a few individuals, and even they may not have the full understanding of what

is going on, what has been done, and what is left to do.

• The command hierarchy and the associated responsibilities for managing FP activities are

not fully understood by all of the organizations involved. Personnel give conflicting

information on which organizations are responsible for certain activities, while some

organizations are unsure as to what activities they themselves are responsible for.

• The distributed structure of Command and Control makes timely response difficult. Force

protection incidents are generally high impact and very fast paced, requiring dispersed

organizations and personnel to efficiently coordinate their activities. Managers need to be

able to task off site responders and organizations in an effective, fast manner and to receive

timely, accurate feedback.

• Poor communications. There are currently a number of different communications links

being used to connect managers and responders, including telephone, voice radio, chat, and

messaging. While these links can be very effective, they must be incorporated into an

overall communications plan so that there is no ambiguity in how they are to be used. In

addition, the number of different communications links should be reduced as much as

possible to reduce the complexity of the communications network, and where possible, a


single, streamlined communications path should be used to reduce the need for dedicated

communications personnel.

• Lack of forensic data for process improvement. Currently, the decisions made and the

responders actions carried out during incident response are not recorded for post event

forensics. These data can be reviewed post event to identify areas where SOPs need to be

improved and can be compared between multiple training scenarios to determine whether or

not personnel are becoming more efficient over time.

These issues are precisely the types of problems that COTS IMSs are designed to address. It

should be noted that the issues described above are very common among IM organizations

operating without an IMS. In addition, many of the IMS requirements posed by DND are similar

in nature to those of many other organizations responsible for incident management activities.

Commonalities include:

• The need to manage multiple events, including the requirement to manage events as sets of

allocated and auditable taskings to individuals or groups,

• The need to mitigate potential events and to maximize efficiency in responding to past

events,

• The need to manage personnel across organizational boundaries,

• The need to generate and share a GIS based Common Operating Picture,

• Support for training and simulation activities,

• The need to track vehicles and other mobile assets in real time through a variety of sensor

data feeds, and

• The need to have an easy to use system that requires minimal operator training.

The level of non recurring engineering (NRE) needed to implement an IMS for FP activities can

vary widely, depending upon the flexibility of the end user and the particular COTS system

chosen for implementation. For example, one of the IMSs examined requires a great deal of NRE

up front, as it is designed to be a framework upon which users can develop applications. Most of

the COTS system surveyed, however, are meant to be installed as is and merely configured post

installation to support customer specific requirements such as users accounts, organizational

access roles, and SOPs. While it might still be necessary to perform a trade off between site

specificity and NRE cost, it is recommended that going forward, a more generic product should

be considered. Going this route provides a number of benefits:

• Because the same product is being used at a variety of locations, customer feedback

(especially on workflow and new features) gets rolled back into the product as a series of

improvements, which eventually make the system better to use and more efficient. If each

location had its own tailored IMS this would not be possible, as the workflow models would

all be different.

• Software updates and patches can be more easily installed. In addition, customized systems

may not operate properly after software updates, and the manufacturer will not accept

responsibility for problems due to customizations they did not make themselves.

• Up front development costs are lower, as the system is merely installed and configured for

use, as opposed to buying a product that provides an architectural backbone and requires

substantial application development.


It should be noted, however, that using a more generic solution for FP activities will require DND

to modify the processes through which it carries out those activities. While COTS IMS software

can be configured and modified in part to suit a particular organization’s processes, they still

require a certain amount of willingness from the various user organizations to modify the way

they conduct business. This imposition, which at first appears to be a detriment, eventually results

in a more streamlined and coordinated IM approach that has been proven time and time again all

over the world. IMSs force organizations to improve their practices, organizational hierarchy, and

SOPs, but this benefit is hard won, as there is a requirement for significant up front work in

developing or modifying the overall Concept of Operations for the entire IM structure as well as a

large number of SOPs. As an added benefit, most COTS IMS solutions are also NIMS compliant,

meaning that they incorporate U.S. national standards for incident management and control that

have been developed through years of IM experience and user feedback across a huge number of

emergency operations groups, both military and civilian.

A COTS IMS could also assist DND in managing many incident management operations beyond

force protection operations. IMSs are designed for many other types of incidents and operations

that DND also needs to manage, including:

• Planning for and managing future events, such as the visit of foreign ships or dignitaries

• Handling of common emergencies, such as fire, police, and health emergencies

• Response to HAZMAT emergencies

• Assistance in natural disaster response, such as the DND involvement in the response to

Hurricane Juan

• Routine base operations activities, such as maintenance, logistics, and security.

Because of the versatility of IMSs, it would be entirely feasible to implement and manage many

SOPs within the IMS that are beyond the scope of force protection and expand the user

community outside the Base Operations Centre.

In order to further investigate the usefulness of a COTS IMS to the Naval community, DRDC is

interested in integrating an IMS into their Virtual Harbour (vHarbour) simulation testbed so that

DND users can use the IMS during a simulated FP incident. It is expected that putting an IMS

into the hands of DND personnel will provide much insight into the benefits and challenges

associated with implementing an IMS on both coasts and solicit useful feedback. Based upon the

capabilities of COTS IMSs and the vHarbour testbed, it is recommended that an IMS should be

implemented within a vHarbour scenario, but to keep the interfaces between the simulation and

the IMS as few and as simple as possible. Generally, COTS IMSs do not require or support

external sensor feeds, but one GIS based situational awareness tool has been identified that a) is

designed to interface with sensor feeds from common devices such as GPS and AIS receivers,

and b) is meant to be used in conjunction with an IMS. Because DRDC and DND have both

identified the need to track certain mobile assets in real time (such as FP boats) it is necessary to

implement this capability for the upcoming vHarbour trial. The sensor feed between the

simulation and the GIS tool should be based upon an open standard (in all likelihood NMEA AIS

messaging) and be used to transmit the positions of simulated harbour craft into the IMS COP.


List of symbols/abbreviations/acronyms/initialisms

AIS Automatic Information System

AOR Area of Responsibility

CBTO Combat Officer

C2 Command and Control

CCFL Commander Canadian Fleet Atlantic

CJTFA Commander Joint Task Force Atlantic

COP Common Operating Picture

COPO Common Operating Picture Officer

COTS Commercial Off The Shelf

DND Department of National Defence

DRDC Defence Research & Development Canada

DRDKIM Director Research and Development Knowledge and Information

Management

ECPINS Electronic Chart Precise Integrated Navigation System

EMO Emergency Measures Organizations

EOC Emergency Operations Centre

FASF Formation Auxiliary Security Force

FP Force Protection

FPO Force Protection Officer

GIS Geographical Information System

GPS Global Positioning System

IMS Incident Management System

J3 Chief of Staff Joint Operations

MDA MacDonald Dettwiler and Associates

MFP Maritime Force Protection

MFP TD Maritime Force Protection Technology Demonstration

MP Military Police

N3 Chief of Staff Naval Operations

NPM Naval Provost Marshall

Ops O Operations Officer

R&D Research & Development

RCMP Royal Canadian Mounted Police


RHIB Rigid Hull Inflatable Boat

RJOC Regional Joint Operations Centre

SA Situational Awareness

SITREP Situational Report

SCOPA Senior Canadian Officer Presently Afloat

SOP Standard Operating Procedure

SOW Statement Of Work

UML Unified Modeling Language

XO Executive Officer


Distribution list

Document No.: DRDC Atlantic CR 2008 179

LIST PART 1: Internal Distribution by Centre 1 H/TD

1 H/MICS

1 Mark G. Hazen

1 Tania Randall

1 Adrian Hewitt

3 DRDC Atlantic Library

8 TOTAL LIST PART 1

LIST PART 2: External Distribution by DRDKIM 1 Library and Archives Canada

1 DRDKIM

2 TOTAL LIST PART 2

10 TOTAL COPIES REQUIRED

DOCUMENT CONTROL DATA (Security classification of title, body of abstract and indexing annotation must be entered when the overall document is classified)

1. ORIGINATOR (The name and address of the organization preparing the document.

Organizations for whom the document was prepared, e.g. Centre sponsoring a

contractor's report, or tasking agency, are entered in section 8.)

MacDONALD DETTWILER AND ASSOCIATES LTD. (MDA) Suite 60, 1000 Windmill Road Dartmouth, Nova Scotia B3B 1L7

2. SECURITY CLASSIFICATION (Overall security classification of the document

including special warning terms if applicable.)

UNCLASSIFIED

3. TITLE (The complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S, C or U)

in parentheses after the title.)

Incident Management Systems Context and Capability for Maritime Force Protection: Volume I

4. AUTHORS (last name, followed by initials – ranks, titles, etc. not to be used)

Eric Widdis; Arthur Cole; Allen Stotz

5. DATE OF PUBLICATION (Month and year of publication of document.)

October 2009

6a. NO. OF PAGES

(Total containing information,

including Annexes, Appendices,

etc.)

52

6b. NO. OF REFS

(Total cited in document.)

0

7. DESCRIPTIVE NOTES (The category of the document, e.g. technical report, technical note or memorandum. If appropriate, enter the type of report,

e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered.)

Contract Report

8. SPONSORING ACTIVITY (The name of the department project office or laboratory sponsoring the research and development – include address.)

Defence R&D Canada – Atlantic 9 Grove Street P.O. Box 1012 Dartmouth, Nova Scotia B2Y 3Z7

9a. PROJECT OR GRANT NO. (If appropriate, the applicable research

and development project or grant number under which the document

was written. Please specify whether project or grant.)

11GQ

9b. CONTRACT NO. (If appropriate, the applicable number under

which the document was written.)

W7707-063601/001/HAL

10a. ORIGINATOR'S DOCUMENT NUMBER (The official document

number by which the document is identified by the originating

activity. This number must be unique to this document.)

DN0917 Issue 3.0

10b. OTHER DOCUMENT NO(s). (Any other numbers which may be

assigned this document either by the originator or by the sponsor.)


11. DOCUMENT AVAILABILITY (Any limitations on further dissemination of the document, other than those imposed by security classification.)

Unlimited

12. DOCUMENT ANNOUNCEMENT (Any limitation to the bibliographic announcement of this document. This will normally correspond to the

Document Availability (11). However, where further distribution (beyond the audience specified in (11) is possible, a wider announcement

audience may be selected.))

Unlimited

13. ABSTRACT T (A brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highly desirable

that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification

of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), (R), or (U). It is not necessary to include

here abstracts in both official languages unless the text is bilingual.)

In the context of command and control (C2) for base and fleet force protection, incident

management systems (IMS) may prove to be an important tool. This study was initiated under

the Maritime Force Protection Technology Demonstration Project (MFP TDP) in order to

further investigate and define IMS specific to MFP concerns. In order to better understand this

type of product for use with base and fleet systems, the study also highlights FP related IMS

features and includes a summary of typical and non typical IMS capabilities. To address the

problem of useful Incident Management within the Maritime Force Protection environment, the

study reviews several existing IMS solutions and their compatibility with Incident Management

requirements within Canadian Forces Base Halifax.

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Technically meaningful terms or short phrases that characterize a document and could be

helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers, such as equipment model

designation, trade name, military project code name, geographic location may also be included. If possible keywords should be selected from a

published thesaurus, e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus identified. If it is not possible to select

indexing terms which are Unclassified, the classification of each should be indicated as with the title.)

Incident Management Systems; IMS; characteristics; maritime force protection