1. Disambiguate Data with Documentation Context is the Key to Scaling Integration Complexity Gordon A Hunt, Principal – TRG Systems, FACE Advisory Board, UCS WG, CAPT USN-R Chris Allport, President – New Spin Robotics, UCS FACE Alignment FACE™ TIM Meeting, Huntsville AL 02 February 2016

2. 2 COPYRIGHT © 2016. Overview Where we are… What’s the challenge… About data architecture… Tools to simplify… Where we are going…

3. 3 COPYRIGHT © 2016. Modular Open Systems Approach (MOSA) with Standard Key Interfaces Common Domain Capabilities via Product-Lines Common Domain Capabilities Common Data Capabilities Common Infrastructure Layered Architectures Modular Architectures Ad Hoc Architectures Where we are… Evolution of Complex Systems Logical progress of architectural separation of concerns http://blog.sei.cmu.edu/post.cfm/architectural-evolution-dod-combat-systems-359

4. 4 COPYRIGHT © 2016. What’s the Challenge… System(s) Integration spans a much larger set of problem and challenges… Different timelines for integration and technology refresh cycles Leveraging different implementation frameworks and interfaces Not managed/funded by the same program management Not in the same domain

5. 5 COPYRIGHT © 2016. What’s the Challenge… What makes this hard? There isn’t a common interface specification… Different temporal constraints and requirements… We can’t standardize on one protocol… Configuration & implementations vary… It that is? Something else, at the root? It’s the data’s content, context & behavior It’s an integration scalability problem

6. 6 COPYRIGHT © 2016. Current progress… Modularity Reusability Extensibility Portability Integratability Interoperability – Technical – Syntactic – Semantic – … What system architectural property drives/enables understandability?

7. 7 COPYRIGHT © 2016. Current progress… Modularity Reusability Extensibility Portability Integratability Interoperability – Technical – Syntactic – Semantic – …

8. 8 COPYRIGHT © 2016. Current progress… Modularity Reusability Extensibility Portability Integratability Interoperability – Technical – Syntactic – Semantic – …

9. 9 COPYRIGHT © 2016. Current progress… Modularity Reusability Extensibility Portability Integratability Interoperability – Technical – Syntactic – Semantic – …

10. 10 COPYRIGHT © 2016. Current progress… Modularity Reusability Extensibility Portability Integratability Interoperability – Technical – Syntactic – Semantic – …

11. 11 COPYRIGHT © 2016. Current progress… Modularity Reusability Extensibility Portability Integratability Interoperability – Technical – Syntactic – Semantic – …

12. 12 COPYRIGHT © 2016. Current progress… Modularity Reusability Extensibility Portability Integrateability Interoperability – Technical – Syntactic – Semantic – … Levels of Interoperability: http://www.iiisci.org/journal/CV$/sci/pdfs/P468106.pdf Ability to move stuff around. Plugs and sockets, bit and bytes

13. 13 COPYRIGHT © 2016. Current progress… Modularity Reusability Extensibility Portability Integrateability Interoperability – Technical – Syntactic – Semantic – … Levels of Interoperability: http://www.iiisci.org/journal/CV$/sci/pdfs/P468106.pdf Many efforts defining domain specific data Addressing the definition of message (ICD) syntax How to inform the machine about content of data

14. 14 COPYRIGHT © 2016. Current progress… Modularity Reusability Extensibility Portability Integrateability Interoperability – Technical – Syntactic – Semantic – … Levels of Interoperability: http://www.iiisci.org/journal/CV$/sci/pdfs/P468106.pdf Defining what is being said, context and semantics The meaning of the data, to include representation NOT – more content to added to the messages

15. 15 COPYRIGHT © 2016. Current progress… FACE™ Architecture – Data Syntax – Data Semantics – “Rules” of structure UCS Working Group – Data Architecture – Interface Content (ICDs) – Context (Structure) – Behavior (Domain) Others as well… model.

16. 16 COPYRIGHT © 2016. Semantics and Data Architecture The procedure is actually quite simple. First you arrange things into different groups. Of course, one pile may be sufficient depending on how much there is to do. If you have to go somewhere else due to lack of facilities that is the next step, otherwise you are pretty well set. It is important not to overdo things. That is, it is better to do too few things at once than too many. In the short run this may not seem important but complications can easily arise. A mistake can be expensive as well. At first the whole procedure will seem complicated. Soon, however, it will become just another facet of life. It is difficult to foresee any end to the necessity for this task in the immediate future, but then one never can tell, After the procedure is completed one arranges the materials into different groups again. Then they can be put into their appropriate places. Eventually they will be used once more and the whole cycle will then have to be repeated. However, that is part of life. - Bransford & Johnson (1972) document.

17. 17 COPYRIGHT © 2016. Semantics and Data Architecture What Interface is This? – Controller reporting its currently control asset? – Asset reporting the controller that is currently tasking it? – Controller requesting control of a certain asset? – An agent authorizing a controller control of a certain asset? – A conditional message that specifies when a controller must release an asset? Why do this? – Provides a machine-scalable way of linking interfaces. struct Message { long controllerID; string assetID; Pos location; } struct Pos { double x; double y; double z; } document.

18. 18 COPYRIGHT © 2016. Semantic Data Models… They are different and separately document – the CONTENT, and the CONTEXT You Still Need – System appropriate and optimized ICDs Just adding machine usable formalism model. document.

19. 19 COPYRIGHT © 2016. Services Sequence Diagrams Functional Decomposition Functional Decomposition Use Case Analysis Interface Definitions Projections Refinements “Message” Model “Message” Model Reference System Measures Observables Units Precision Logical Model Logical Model Entities Missions Objectives Actions Conceptual Data Model Conceptual Data Model Building an Understanding of UCS Dependencies “Messages” Service Definitions Service Definitions Service Model model.

20. 20 COPYRIGHT © 2016. UCS NATO 4586 Others Looking at UCS Entities Missions Objectives Actions Measures Units Precision Coordinate Systems Coordinate Systems Conceptual Data Model Conceptual Data Model Logical Data Model Logical Data Model Platform Model Platform Model model.

21. 21 COPYRIGHT © 2016. UCS NATO 4586 Others Leveraging UCS for Context Documentation Leveraging Domain Content – 1,600 Entities & Associations – 13k Characteristic Attributes Aligning LDM SDM Content – Measurements and Coordinate Systems Decoupling Models – Improves reuse – Enhances Integration Entities Missions Objectives Actions Conceptual Data Model Conceptual Data Model Logical Data Model Logical Data Model Platform Model Platform Model model.

22. 22 COPYRIGHT © 2016. A Bottom Up Approach Platform Data Model Platform Data Model NATO 4586 Logical Data Model Logical Data Model Conceptual Data Model Conceptual Data Model Inertial States position Standard X Vehicle Status position WGS-84 Latitude Degrees Longitude Degrees Altitude Meters WGS-84 Latitude Degrees Longitude Degrees Altitude Meters Air Vehicle acceleration altimeterPressure atcCallSign attackAngle bingoFuel centerOfGravity course flapAngle flightMode Heading location Mass maximumAirSpeed speed ECEF X Meters Y Meters Z Meters ECEF X Meters Y Meters Z Meters 4586 Standard X document.

23. 23 COPYRIGHT © 2016. Documented Content Enables “Automatable” Mapping & Integration Human Readable. Machine Parsable. Machine Generated. connect.

24. 24 COPYRIGHT © 2016. Why Use a Tool Many ways to generate the documentation document.

25. 25 COPYRIGHT © 2016. Modeling Wizard Delivered to Navy Oct 2015 Government Purpose Rights Make it easy for anyone to accurately & quickly document existing IDL interfaces without the overhead imposed by existing workflows. document.

26. 26 COPYRIGHT © 2016. Interface & Data Documentation Workflow UCS USM FACE SDM Rules of Construction MOF OCL XMI Rules of Construction MOF OCL XMI Governs Informed from Interface Documentation Uses USM Model Generates SME Knowledge Capture -Units -Frames of Reference -Data type representation  Context & Semantics Input Informs Generates Code Interfaces document.

27. 27 COPYRIGHT © 2016. Where we are going… Integration-Based Interoperability Concerns… The ‘data of behavior’ which informs the transformation – Have – Service descriptions and human understandable forms – Needed – the machine understandable equivalents. Its hard, is takes time and there is no magic transform – Take a page from history, it’s doable – Have to be rigorous in the rules model. document. connect. secure.

28. 28 COPYRIGHT © 2016. Questions? Come by the UCS / FACE Collaboration Booth Check out the Paper on ‘Context’ Register for a chance to win your own BB8 – More chances awarded for ‘getting’ context – Text ‘Context’ to 33444 to enter