1. A National Effort on Emergency Data Distribution David E. Ellis Information Management Architect (505) 844-6697, dellis@sandia.govdellis@sandia.gov

2. What is NAWS A National Alerting and Warning System (NAWS) is an emerging Family of Service Oriented Architecture (SOA) Capabilities which would accomplish National Alerting and Warning needs by combining the capabilities of various Family/System of Systems. NAWS is based on delivering information (Push) about: –Changes in the real world environment (Alerting). –Response guidance from appropriate decision authority (Warning). The OASIS Emergency Management Technical Committee is developing standards which provide the basis for NAWS delivery (EDXL-DE) and content (CAP, EDXL-RM, etc.) for these SOA based communications.

3. Initial NAWS Evaluation Alerting and warning concepts were evaluated at Coalition Warrior Interoperability Demonstration (CWID) 2005. CAP 1.0 was the basis for all messaging interoperability –Only approved OASIS standard available. –Demonstrated CAP 1.0 was not suitable for delivery of sensor data. –Evaluation used the Nuparadigm Foundation software. Evaluation also exposed semantics engagement issues –Information model for various vendors was tailored to their application/functionality (e.g. parameter element tag usage). Sandia Sensor System used limited distribution filtering based on event location – No real attempt to use SOA capabilities-to-needs matching. CWID 2005 emphasized the need for creation of ad hoc sensor distribution capabilities based on real world incident dynamics. The following two slides represent chlorine incident scenarios –CWID 2005 depicts integration of various civil sector systems. –A Semantic Interoperability Architecture Pilot represents the flow of alerting/warning information.

4. Exchange alerts containing links to situation awareness artifacts using the Common Alerting Protocol (CAP) Standard CWID ’05 “The Real McCoy’s” Collaborating Trials 4.26 DMIS Interoperability Backbone E Team Blue 292 CAPWIN DMIS Tools Civil Sector 3.70 Boeing MI2 Military Unclassified App GCCS Alerts/Tracks SWARM Chat ImageryWeather Air Tracks Surface Tracks Ground Tracks ISR Tracks Network Stats/Alerts FBI Investigator’s Web Services 2.77 InfoBridge 2.58 FRCTS Sandia Sensor System Alerting Framework

5. Semantic Interoperability

6. NAWS Development OASIS CAP 1.1 standard approved and in use. EDXL-DE created to allow a true SOA approach to alerting and warning system integration. Semantic Interoperability Architecture pilot is continuing to work on CAP taxonomy and ontology issues. EDXL-DE is currently in ballot at OASIS and expects standard release in April 2006. Numerous OASIS EDXL/CAP capable systems will be available this calendar year for deployments.

7. National Communications Infrastructure Internet, Satellite, Radio National Communications Infrastructure Internet, Satellite, Radio NAWS Exchange Architecture Sending Application Information Taxonomy (e.g. Alerting, Warning) Receiving Application Information Taxonomy (e.g. DSS, Visualization) Message XML Document (e.g. EDXL SS, CAP) Delivery Metadata EDXL DE- Publish (e.g. direct, registry) Delivery Metadata EDXL DE-Subscribe (e.g. direct, registry) Message XML Document (e.g. EDXL SS, CAP) XML Document Object Routing Nuparadigm Foundation (e.g. content filters, sensitivity enforcement, MOU instantiation by execution Context) Information Exchange Requirement

8. EDXL Distribution Element (DE) EDXLDistribution distributionID senderID dateTimeSent distributionStatus distributionType combinedConfidentiality senderRole * recipientRole * keyword * distributionReference * explicitAddress * targetArea circle * polygon * country * subdivision * locCodeUN * nonXMLContent mimeType size digest uri contentData xmlContent keyXMLContent embeddedXMLContent OR contentObject contentDescription contentKeyword * incidentIdentifier incidentDescription originatorRole * consumerRole * confidentiality 0..1 0..* Specific Message Content - CAP 1.0 - CAP 1.1 - ASOCC - FPCON - Sensor - EDXL Resource Messagin g - IMPP - DSEL - etc. 0..*

9. EDXL Content CAP 1.1 Structure alert Message ID (identifier) Sender ID (sender) Sent Date/Time (sent) Status (status) Scope (scope) Type (msgType) Operator/Device ID (source) Restriction (restriction) Addresses (addresses) Handling Code * (codes) Note (note) Reference ID (references) Incident IDs (incidents) info Event Type (event) Response Type (responseType) Urgency (urgency) Severity (severity) Certainty (certainty) Event Category * (category) Language (language) Audience (audience) Targeting Code * (eventCode) Effective Date/Time (effective) Onset Date/Time (onset) Expiration Date/Time (expires) Sender Name (senderName) Headline (headline) Event Description (description) Instructions (instruction) Information URL (web) Contact Info (contact) Parameter * (parameter) resource Description (resourceDesc) MIME Type (mimeType) Size (size) URI (uri) Dereferenced URI (derefUri) Digest (digest) area Area Description (areaDesc) Area Polygon * (polygon) Area Point-and-Radius * (circle) Geographic Code * (geocode) Altitude (altitude) Ceiling (ceiling) Elements in bold are mandatory; those in italics are optional; asterisk (*) indicates multiple instances permitted

10. Notional EDXL Routing Grid EDXL Router Central Region Southwest Region Southeast Region Northwest Region Northeast Region

11. Warning ValueListUrn DMIS Response/Warning SME Analysis Data Fusion Operator Station Operation Center Alerting NC-JOC DHS-HSOC National Command and Control Plume Analysis Sensor Node + Camera EDXL + CAP EDXL Proxy EDXL + Rad Spectrum NC2 ValueListUrn Alerting ValueListUrn Capability Decomposition

12. WSDL Distribution Path Sensor Node + Camera DMIS Router Operator Station Plume Analysis Operator Station Southwest Region Northeast Region CA MD Default WSDL, Secondary WSDL, WSDLs of Last Resort in routing Configuration File

13. valueListUrn Strategy Prefix for Encoding Schema of valueListUrn –NIEM-L-DoDAF –Others Possible use of Geographical Location Distribution Mask –US:SE:CA: –locCodeUN Topic or Functional Area grouping of Activities (OV1, FEA, others) –Alerting –Warning Potential valueListUrn schema combinations for XPath evaluation –NIEM-L-DoDAF:US:SE:CA:OV1:Alerting –Example – NIEM-L-DoDAF:US:SE:CA:OV1:Alerting – Operator Station – Alerting – SME Analysis – Operation Center

14. Southwest Region Southeast Region EDXL-DE Router EDXL-DE Router Edge Message Replication Surveillance Camera HighLowMedium

15. XML Content Object Non-XML Content Object Security MPEG, JPEG, Etc. CAP, SWE, ANSI N42.42, Etc. WSDL or file Encryption, Decryption, Signing, Verification EDXL Constructor User Interface For Local Configuration EDXL Router Via XSLT Edge EDXL Proxy Service

16. Adversary Weapon Motive Target List Current Location Start Time Finish Time Pre Attack Measurable Characteristic R, E Characteristic Sensor Attack Area of Immediate Effect Area of Progressive Effect Meteorological Environment Post Attack Measurable Characteristic Surveillance Devices Meteorological Sensor Sensor Concentrator Detection Time C, B, R Characteristic Sensor Detection Time Start Time Finish Time Location Has a Detects at a Has a Detects Has a Uses Observe a Has a Measures Reports to Has a Triggers Launches Has a Reports to the Sensor Management System via EDXL Read from tail of arrow to head CBRNE Sensor Detection Ontology Have a

17. CBRN-Sensor-Type Measurable Characteristic Physical Characteristic Chemical Biological Radiological - Alpha - Neutron - Gamma -- Gross -- Spectrum Power Source - External - Internal Form Factor - Self Contained - Integrated - Has Handle Characteristics - Weight - Dimensions Fixed Mobile Hand Held Geospatial Deployment Less Than 5 Pounds Sensor Characteristic Decomposition

18. Publish Subscribe Registration Publish  Type of contentObject being sent o Specific schemas o Specific mime types  Restrict usage of content keyword tables  Register keyword tables for originator roles  Ability to add new schemas, keyword tables, originator roles, and mime types Subscribe  Type of contentObject to recieve o Specific schemas o Specific mime types  Restrict the consumer role tables and the values within the consumer role table  Restrict the keyword tables and the values within the keyword table  Evaluate all explicit addresses from all explicit address schemas o DMIS Cog/#215 o Email/jon@me.org Email/jon@me.org  Type of distribution element o Specific keyword tables and values o Specific consumer role tables and values  Type of distribution element o Specific keyword table and values o Specific sender role tables and values Certificates will be issued to any system which registers with the distribution system. Certificates will be used to create encrypted Tunnels and to Encrypt and Sign contentObjects.

19. Conclusion EDXL-DE delivers arbitrary information: –Other sensor standards can be distributed (based on roles) –System capabilities are tailored to consumer needs by using appropriate standards (Management versus Alerting) –Ability to protect content is included –Provides for Post before processing (Tactical storage) –Architecture allows SOA document distribution –Allows for architectural level replication strategies –Model is shaped by DoD AF methodologies (can use DRM) –Improves on messaging and presence strategies –Allows for multiple sensitivity security message exchanges Now is the time for joint standard interoperability pilots –Obtain representative National use cases for CBRN –Access to sensors and sensor networks for pilots –Forum for joint experimentation needs to be funded