Скачать презентацию US Army Tactical C 2 Interoperability Services Publish Скачать презентацию US Army Tactical C 2 Interoperability Services Publish

8470abe2a8608df4c93663ed6095cdf2.ppt

  • Количество слайдов: 21

US Army Tactical C 2 Interoperability Services: Publish and Subscribe Server (PASS) and Data US Army Tactical C 2 Interoperability Services: Publish and Subscribe Server (PASS) and Data Dissemination Service (DDS) Sam Easterling Army PM Battle Command 2 DEC 09 samuel. [email protected] army. mil

Outline • What are PASS/DDS in a nutshell? • Operational Context • Technical Detail Outline • What are PASS/DDS in a nutshell? • Operational Context • Technical Detail • Summary

Shared SA Net-Ready Interoperability Automatic Database Replication FBCB 2/ JBC-P Air Defense Battle Command Shared SA Net-Ready Interoperability Automatic Database Replication FBCB 2/ JBC-P Air Defense Battle Command Common Services Functional Capabilities MANUEVER • PLI/SA • MEDEVAC • Orders • • • NBC ENGINEER AFATDS FIRE SUPPORT AIR DEFENSE • Synchronized Fires, Effects, ENEMY • Air Defense to Maneuver Units • Positive Aircraft ID • Weapon Coverage • • AIR PICTURE LOGISTICS WEATHER TAIS & Maneuver Execute Responsive Fires JADOCSHand helds Target Locations Radar/Observer Locations BCS 3 • Combat Power • In-transit Visibility • Joint Automated Air Space Control with the JFACC • Air Support Request DCGS-A Maps Display and disseminate COP Disseminate Orders Tactical Collaboration Interoperability between Tactical and Theater levels Chem-Bio Rad-Nuc (CBRN) DTSS • Local Terrain • “Go/No-Go” Areas Weather IMETS • Weather Effects Matrix • Battle Scale Forecast Model Intelligence • • ASAS Secondary Imagery Intelligence Summary Enemy Locations Enemy Geometries Fire Support • • Maneuver GCCS-A/NECC AMDWS Airspace TBC (CPOF, MCS) Logistics Blue Force/SA EAC C 2 Army Battle Command Systems

PASS/DDS (in a nutshell) • Built to support many-to-many data exchange requirements emerging from PASS/DDS (in a nutshell) • Built to support many-to-many data exchange requirements emerging from stovepiped architectures • Publication/ Subscription mechanism – Does not impose a model on the way the application conducts the Business of War. • Not a database, but published data is stored for future subscriptions with a time-to-live – Flexible methodology allowing for insertion of new schemas and message exchange • Web Services/SOAP and XML • Runs over HTTP(s). – Internet protocol – Protocol knows how to deal with latent and ‘dirty’ networks • Data agnostic – But…. ABCS message exchange is based on PASS schemas

Data that Battle Command Exchanges via PASS / DDS • • • Friendly Position Data that Battle Command Exchanges via PASS / DDS • • • Friendly Position Reports (ground air) Enemy Situation Reports Sensor tracks Military C 2 Graphics / Battlespace Geometries Significant Activities (SIGACTS) Targets Airspace Control Orders (ACO) Weather Task Organization Information Addressbook Change Notification Indicators and Warnings

-Each US Army unit in OEF has a PASS node at CJTF, BCT, BN -Each US Army unit in OEF has a PASS node at CJTF, BCT, BN HQ - Also in RC(S) @ 57 th SIG, MEB-A - Co-located with every CPOF Master Repository to enable exchange -Also planned installation in IJC HQ to enable interoperability services with NATO apps

UK/US Information Exchanges UK TRACKS ICS WISEWeb -> Sharepoint Jchat Vo. IP Phone CIDNE UK/US Information Exchanges UK TRACKS ICS WISEWeb -> Sharepoint Jchat Vo. IP Phone CIDNE PASS JOCWATCH JADOCS TIGR MIP TRACKS GCCS-J GCCS-A Document/File Exchange and Collaboration (Read, download, post, contribute) MEDEVAC/CASEVAC, Personnel Recovery, FMV coordination, CAS coordination, TIC SIGACTS PASS / DDS - SIGACTS - BATTLESPACE GEOMETRIES - TARGETS - POSITION REPORTS US -INDICATORS/ WARNINGS -AIR TRACKS -ENEMY SITUATION -ACO Fire Support Coordination Measures Coalition Fires / Effects Patrol Reporting Other Coalition Forces Share. Point Transverse, Jchat, m. IRC Vo. IP Phone CIDNE US BC Systems BCS 3 CPOF DCGS-A TAIS JADOCS GCCS-A AMDWS AFATDS CIDNE FBCB 2 JADOCS TIGR PASS

IJC COP Flow (as of 15 Nov) GCCS-J RM SA Tracks only GCCS-J In IJC COP Flow (as of 15 Nov) GCCS-J RM SA Tracks only GCCS-J In theatre Link-16 feed NIRIS SA Tracks only ? Full COP (CST) GCCS-A SA Tracks only CPOF MR/DB CPOF Client JADOCS GEO, Full COP i. Geo. SIT Server Full COP SIGACTS (-) SIGACTS (+) CIDNE SIGACTS (+) JOCWATCH Graphics, nontrack POS-RPT MIP GW Graphics, nontrack POS-RPT SIGACTS (+) PASS SIGACTS (+) i. Geo. Sit Viewer SA Tracks only MIP GW COP LM (formerly BOM) Graphics, nontrack POS-RPT

Proposed CXI Architecture with C 2 Interoperability Bus CIDNE C 2 PC JADOCS CPOF Proposed CXI Architecture with C 2 Interoperability Bus CIDNE C 2 PC JADOCS CPOF ISRIS FBCB 2 GCCS Intel FS BOM JOCWatch. B JOIIS NIRIS COP ICC US Integration Solutions C 2 Interoperability Bus (CUR 355) Based on PASS / DDS Server JC 3 IEDM / NIIA Canonical Form EVE Others CORSOM NATO UNCLASSIFIED Releasable to ISAF CIED GEO IFTS ü JISR 1 JADOCS 9

IJC MIP Architecture ISAF Secret CENTRIX ISAF Router PASS / DDS MIP COP LM IJC MIP Architecture ISAF Secret CENTRIX ISAF Router PASS / DDS MIP COP LM §Battle field Geometry CPOF 10 IGEOSIT §NATO and ANA Boundaries §FOBS §COPS §UNITS (not tracks) §NGO/IO Locations §Road (Planned, under construction and completed)

DDS Uses a Pub-Sub Approach 1. Providers Advertise (the data they will publish) 3. DDS Uses a Pub-Sub Approach 1. Providers Advertise (the data they will publish) 3. Providers Publish (push data to their server) Clients only communicate with a single server 2. Consumers Subscribe (to their server for data) 4. Servers match advertisement, subscription and publish metadata There are multiple collaborating servers within the DDS network 5. Servers Publish (push data to consumers)

DDS and advertisements • DDS uses advertisements to “tell everyone on the network” that DDS and advertisements • DDS uses advertisements to “tell everyone on the network” that data exists at a certain node – Do. D Discover Metadata Specification (DDMS) version 1. 3 is the standard for the advertisement • What type of data • Data description • Who has access to the data • Clients subscribe to advertisements – Clients provide the “call back protocol” method to deliver data • HTPP(s), UDP(s) (DDS version 2. 0) • Publishers, publish data for an advertisement – Once a publisher, injects data, and a match occurs against the subscription, data is delivered to the client

DDS versus PASS • Data is global – Unlike PASS which was a application DDS versus PASS • Data is global – Unlike PASS which was a application for data dissemination within the TOC, DDS was developed with global data as the main paradigm. • PASS compatibility – Will keep compatibility with current PASS – Usage of a PASS/DDS bridge to mach advertisement to topic – Not tied to any software baseline because of backward compatibility • Better security model than PASS – Complies with NCES security policies – Meets DOD guidelines for security.

PASS to DDS Evolution PASS – Local Service DDS – Federated Service SOA / PASS to DDS Evolution PASS – Local Service DDS – Federated Service SOA / SOAP Interface Payload independent Data Caching Publish and Subscribe Advertise, Publish & Subscribe, Query Limited Metadata filtering (Topic, AOI, Time) Enhanced metadata and Content filtering (Keywords, Content, AOI, Time) Local interchange Net-Centric Interchanges Hand-Jammed static PASS forwarding relationships Dynamic Peer node Discovery

Sample metadata <advertise command. Date. Time= Sample metadata - MCS_DEMO MCS_Desc - MCS - - - 2006 -02 -15 T 11: 03: 55 -05: 00 2006 -02 -15 T 16: 03: 55 -05: 00 - -170. 0 16. 0 -169. 0 17. 0

How DDS Works NCES Services Security Discovery Sub 1 • DDS Nodes Sub 2 How DDS Works NCES Services Security Discovery Sub 1 • DDS Nodes Sub 2 Sub scri be Adv erti se DDS Key Advertisements Subscriptions Published data se h rti ve blis Ad Pu DDS Publisher Overlap in subscriptions from same DDS node are only sent once Sub 1 Sub 2 1. DDS client, discovers DDS node location through the use of discovery services 2. Publisher • Advertise their data, DDS server to server protocol propagates advertisements to other nodes • Publish data to local DDS node merges subscribers of published data from save DDS node and send data to node then DDS nodes stores based on TTL 3. Subscribers • Subscriber, specify advertisement and data filters • DDS node will match subscriptions to advertisements and forward subscription to owning DDS nodes • When DDS node receives published data, it sends to subscribers 4. NCES Security • Authenticates and authorizes DDS nodes, publishers & subscribers

ABCS Data Dissemination Service (DDS) Security Model SAML Security Header Handler User Authentication Handler ABCS Data Dissemination Service (DDS) Security Model SAML Security Header Handler User Authentication Handler Signature Handler Security Header Handler DDS Client (10) Digitally Signed SOAP Response with filtered data Principal Attribute Handler NOTES: • All connections are SSL using HTTPS • All transactions are digitally signed and validated • Client Cert Validation Handler connects to the Cert Validation Service (not shown) Policy Decision Service User Directory (AD / LDAP / etc. ) (roles, clearances, citizenship) (9) User is authorized (7) User Attributes (e. g. Role/Groups) returned Principal Attribute Service (6) Present User DN (5) User DN received Cert Validation Handler Signature Handler Cert Validation Handler User Auth. Service (4) Present UN/PW (1) Digitally Signed SOAP Request with SAML Assertion (3) Cert validated (0) User provides credentials (Username/PW) (2) Client App Digital Sig. Cert Validation Service (TS 3) (8) Present User Role Tactical Services Security System Policy Decision Handler DDS Web Service NCES Component SEC Developed Component

Summary • PASS / DDS are used by US Army Battle Command systems to Summary • PASS / DDS are used by US Army Battle Command systems to share ‘common operational picture’ data at tactical echelons • XML payloads with metadata to enable appropriate AOI/temporal queries and identify releasability • HTTPS-based with soft certificate-based security model • Supporting initial coalition interoperability with UK (JADOCS) and ISAF (CPOF, JOCWATCH, COP LM)

Backup Backup

Security policy DDS has a comprehensive security model • Functional Validation – Users have Security policy DDS has a comprehensive security model • Functional Validation – Users have privileges to functionality based on their group membership • Clearance Classification – Users have privileges to publish or subscribe based on their security classification and releasibility for data. – Users have privileges to publish or subscribe based on the rights associated with the advertisements. – Advertisements carry security classification • Need to know – All functionality for access is based on users being members of groups – Advertisements carry need to know – Advertisement is only available to subscribers who are in the groups which are specified in ‘Releasable To’ field of the Advertisement • Single Sign On under Windows (clients)

MIP Deployment Summary § MIP Ver 09_4_4_22 is installed on the BCS server at MIP Deployment Summary § MIP Ver 09_4_4_22 is installed on the BCS server at IJC HQ. MIP is receiving data from CPO LM (formally BOM) and publishing it to PASS. We have tested it with CPOF and CPOF is subscribing to PASS and displaying the data. There is one issue with Road graphics they are a point to point line, but they are displaying as an icon. Joel Varanda is sending Venis the unclass PDU for the road. § COPLM is sending the following data through MIP: § Battle field Geometry §NATO and ANA Boundaries §FOBS §COPS §UNITS (not tracks) §NGO/IO Locations §Road (Planned, under construction and completed) §COP LM is not sending the following data §SIGACTS (JOC Watch) § Ground Tracks (GCCS-J) §Air Tracks (TBMCS) §Fires (JADOCS) §LOG (NIRIS) 21