aviation management interoperability for emergency ... · aviation management interoperability for...
TRANSCRIPT
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
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