Aviation management interoperability for emergency response and recovery System Architecture

Steve Newton Selkirk Systems Inc. Prepared By: Selkirk Systems Inc. Suite 4-415 Dunedin St. Victoria, BC V8T 5G8

Contractor's Document Number: CSSP-2014-CP-2005 PWGSC Contract Number: W7714-156-075/001/SV Contract Technical Authority: Daniel Charlebois, Defence Scientist. Disclaimer: The scientif ic 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 the Department of National Defence of Canada.

Contract Report DRDC-RDDC-2016-C100 April 2015

IMPORTANT INFORMATIVE STATEMENTS: Aviation Management Interoperability for Emergency Response and Recovery Project, # CSSP-2014-CP-2005, was supported by the Canadian Safety and Security Program which is led by Defence Research and Development Canada’s Centre for Security Science (DRDC-CSS), in partnership with Emergency Management British Columbia (EMBC). The project was led by DRDC-CSS. Canadian Safety and Security Program is a federally-funded program to strengthen Canada’s ability to anticipate, prevent/mitigate, prepare for, respond to, and recover from natural disasters, serious accidents, crime and terrorism through the convergence of science and technology with policy, operations and intelligence.

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

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

EMERGENCY AIR OPERATIONS PROJECT (AVIATION MANAGEMENT INTEROPERABILITY FOR

EMERGENCY RESPONSE AND RECOVERY)

CSSP-2014-CP-2005

System Architecture

Selkirk Systems Inc.

Version: Emergency Air Operations - System Architecture.V2-2

Selkirk Systems Inc. – Suite 4, 415 Dunedin Street, Victoria, BC V8T 5G8 Canada 2 | P a g e

Contents

Introduction and Background ....................................................................................................................... 3

Milestone #2 - System Architecture ............................................................................................................. 4

Architecture .............................................................................................................................................. 4

Workflow................................................................................................................................................... 5

Conclusions and Future Considerations ................................................................................................... 5

Potential Next Steps ...................................................................................................................................... 6

Step 3 - Introduction of EDXL-RM ............................................................................................................. 6

Step 4: Central EDXL- DE Message Broker ............................................................................................... 6

Step 4: Options – Alternative to EDXL-DE for Delivery ............................................................................. 7

Appendix A – ETeam to Strike-Slip API Mapping .......................................................................................... 8

Strike-Slip API to ETeam ............................................................................................................................ 8

ETeam to Strike-Slip API ............................................................................................................................ 9

Selkirk Systems Inc. – Suite 4, 415 Dunedin Street, Victoria, BC V8T 5G8 Canada 3 | P a g e

Introduction and Background

This document is the Strike-Slip system architecture developed for the Air Operations Project. It outlines the architecture as built for Milestone #2, as well as identifies additional architectural considerations for the following iterations.

Strike-Slip provides:

- an interoperability exchange for information flow between collaborating systems involved with aviation resource requesting and prioritization

- a set of web UI’s for request processing, approval, and prioritization (system #1) - integration with E-Team, the incident and resource management system in use with EMBC and

other major involved agencies in BC (system #2)

In the previous milestone’s system architecture document, we explored four potential major iterations for a deployed interoperable system. In order to achieve the second milestone, we implemented the first two concepts, shown in Figures 1 and 2 below.

Figure 1 - Step 1 - Single Shared Web Application

Figure 2 - Step 2 - Sharing through web-client API

Selkirk Systems Inc. – Suite 4, 415 Dunedin Street, Victoria, BC V8T 5G8 Canada 4 | P a g e

Milestone #2 - System Architecture

Architecture

The current architecture for Strike-Slip is detailed in Figure 3.

Figure 3 - Strike-Slip Architecture as of Milestone #2

Selkirk Systems Inc. – Suite 4, 415 Dunedin Street, Victoria, BC V8T 5G8 Canada 5 | P a g e

The architecture for Strike-Slip was chosen to be highly available and highly scalable, and fast to refactor to maximize reuse beyond the exercise. As the following diagram denotes the architecture is almost fully redundant with the database replication being the only technical hurdle remaining before we can claim both complete redundancy and scalability.

The integration point for all Strike-Slip UIs and existing applications is the Public API which is currently REST Level 2 with some Level 3 HATEOAS implemented with a goal of full HATEOAS support by the end of the project.

The benefit of HATEOAS in the API is that the major workflows can shift dramatically potentially without breaking the integration or UIs dependent upon the API.

Workflow

Over the course of the project the greatest amount of change has been in the workflow being who can perform which action upon a request in a specific state. It would be desirable to add flexibility to this process. The workflow implemented for the second milestone exercise is denoted in Figure 4.

Figure 4 - Milestone 2 Workflow

This workflow defines three roles:

Requester: Requesting on behalf of an Emergency Operations Centre (EOC)

Approver/Prioritizer: working at the Regional Emergency Operations Centre (REOC)

Implementer: The entity responsible for mission planning and dispatching

Roles are responsible for actioning requests at various stages of the workflow. The stages are determined by statuses, which in turn, are defined by the last action taken.

The actions available to a role at any given stage amount to the ability to move the request forward or back, or abort it. Roles have unique actions available at each stage that result in unique statuses. The initial goal of the uniqueness was to allow a user to recognize the last action taken, and by whom without having to drill into the details.

Conclusions and Future Considerations

The architecture provided in Milestone #2 has met the scalability, redundancy, and openness requirements for the project. Based on the architecture, the following future architectural changes / additions are being considered:

Selkirk Systems Inc. – Suite 4, 415 Dunedin Street, Victoria, BC V8T 5G8 Canada 6 | P a g e

Add monitoring and metrics support to the microservices

Improved behaviour when services are unavailable (circuit breakers)

Configuration and authorization tooling for admins

Add OpenID security

Apply Security to workflow Roles in order to inform HATEOAS supplied actions in the API

Have the systems integrating to the workflow conform to the HATEOAS actions

Potential Next Steps

Step 3 - Introduction of EDXL-RM

As the diagram in Figure 5 denotes, the 3rd major iteration could build upon Step 2 and introduces a 3rd API:

By this stage in the process, we will have identified what parts of EDXL-RM we are using, and any required definitions or changes to the spec required in order to facilitate the business case of aircraft requesting in an emergency in BC. (EDXL-RM-BCEMERG-AIR)

Potentially at this point E*Team would be configured to ingest and expel EDXL-RM-BCEMERG-AIR likely a simplified RESTFul XML over HTTP delivery mechanism, but may still require a bridge / poller.

Step 3 is optional at this point as it may be simpler to skip to Step 4

Figure 5 - Step 3 Introduction of EDXL-RM

Step 4: Central EDXL- DE Message Broker

Builds upon Step 2 and/or Step 3 and introduces a central EDXL-DE Message Broker

Selkirk Systems Inc. – Suite 4, 415 Dunedin Street, Victoria, BC V8T 5G8 Canada 7 | P a g e

If we choose not to implement Step 3, we would need to define and implement the EDXL-RM-BCEMERG-AIR standard.

Would require a centralized EDXL-DM server to use as a delivery mechanism for the EDXL-RM-BCEMERG-AIR payload

Would likely require some rework of the security models and mechanisms from Step 2 unless the broker supported and trusted the OAuth2 provider.

Figure 6 - Option 4 Full EDXL-DE Delivery

Step 4: Options – Alternative to EDXL-DE for Delivery

Alternative delivery mechanisms can be considered to replace EDXL-DE for delivery, such as those that MASAS uses for CAP-CP (HTTP POST + RSS), or other standard, non-OASIS, web delivery mechanisms.

Selkirk Systems Inc. – Suite 4, 415 Dunedin Street, Victoria, BC V8T 5G8 Canada 8 | P a g e

Appendix A – ETeam to Strike-Slip API Mapping

Strike-Slip API to ETeam

Strike Slip Field Name Eteam Field Name Comments

Blue Code

Mission Type Mission this is ok if it appears in the Mission Desc for SS (duplicate)

BCERMS Goal

Urgency

Last Progress Update

Current Status Status

Requesting EOC Requester's Contact info Requesting EOC:

Date of Request Date Sumitted (to Eteam) note that this may be different then the SS Submitted timestamp

Requesting Agency/ Org Requesting Org

Resource Type Resource Type

Mission Description Mission Different mapping for Eteam -> SS

Resource is Required When Needed

Specialized Equipment Must Come With (Other field)

Primary EOC Contact Requestor's Contact Info

Name Requestor's Contact Info

Position Requestor's Contact Info

Phone Requestor's Contact Info

Email Requestor's Contact Info

Primary Field Contact

Name

Radio Frequency

Cell

Email

Pickup Description Additional Location Information Only one way from SS to Eteam. Put labels in front

Latitude Latitude

Longitude Longitude

Destination Description Additional Location Information Put 'Destination Description" in front of text

Latitude Put 'Destination Description" in front of Lat Long

Longitude Put 'Destination Description" in front of Lat Long

Number of Passengers

Payload

Selkirk Systems Inc. – Suite 4, 415 Dunedin Street, Victoria, BC V8T 5G8 Canada 9 | P a g e

ETeam to Strike-Slip API

Eteam Field Name Strike Slip Field Name Comments

Basic Info tab:

Priority Priority

Status Current Status

Tracking Number - Local A Tracking Number field is required for this.

Tracking Number - State

Tracking Number - FEMA

Tracking Number - EMAC

Requesting Organization Requesting Agency/Org *

Requestor's Contact Info Primary EOC Contact Name All text into the name field

Related Event/ Incident/ Activity

Resource Category

Quantity n/a hidden 1

Resource Type/Kind Resource Type *Only aicraft requests should be pushed to Strike Slip

Quantity Unit of Measure

When Needed Resource is Required

Mission Mission Description Different mapping SS -> Eteam

Resource Must Come With Specialized Equipment

Special Instructions Mission Description Mission Text – TBD.

Forward Request To

Individual

Organization/ Location

Position

Agency

Vendor

Summary of Actions Taken

Estimated Resource Cost

Notification tab: Future state – may be conversation fields

Message

Select Recipients

Notification List

Other Email Address

Access Control & Sharing tab:

Group

Individual

Selkirk Systems Inc. – Suite 4, 415 Dunedin Street, Victoria, BC V8T 5G8 Canada 10 | P a g e

Share Document

Select Recipients

Comment

Geolocation tab:

Site Name

Site Type

Street Address

Ap or Lot No

City

State

Zip

Intersection - Street 1

Intersection - Street 2

County

Geographic Area

Country

Additional Location Information

Latitude Pick-up Latitude

Longitude Pick-up Longitude

Attachments & Overlays tab:

Web Pages

Footer:

Request History

Last update user Future

Last updated field future

Created By future

Created timestamp Created timestamp When it appears from Eteam

Last Modified by future

Last Modified timestamp Last Modified timestamp When it appears from Eteam