Latest in OA
Innovation and C4ISR
Gordon A Hunt, Principal – TRG Systems
FACE Advisory Board, UCS WG, CDR USN-R
OA Summit, Washington DC.
04 November 2014
Where we are…
OSA - Evolution of DoD Combat Systems
Ad Hoc
Architectures
Modular
Architectures
Modular Open
Systems Approach
(MOSA) with
Standard Key
Interfaces
Layered
Architectures
Common
Infrastructure
Common
Data
Capabilities
Common
Domain
Capabilities
Common
Domain
Capabilities via
Product-Lines
Logical progress of architectural separation of concerns
http://blog.sei.cmu.edu/post.cfm/architectural-evolution-dod-combat-systems-359
What’s the Challenge…
C4I spans a much larger set of systems…
• Not in the same domain
• Not managed/funded by the same PM
• Leverage different TRFs
• Different timelines for integration
and technology refresh cycles
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
What’s been done…
• Where else has content, context
and behavior been thoroughly
defined?
• Compilers!
• Syntax – content
• Semantics – context
• Operations – behavior
• Consider what’s been done with
these rigorous definitions…
http://commons.wikimedia.org/wiki/File:Compiler.svg#mediaviewer/File:Compiler.svg
What’s been done…
• What made this transform possible?
• Machine readable, rigorous, and closed
input, output, and rules specifications
• Something like Extended Backus–Naur Form
• Define “Rigorous”?
• Solid mathematical basis & foundations.
• Not just machine readable
• Must be machine understandable
http://commons.wikimedia.org/wiki/File:Compiler.svg#mediaviewer/File:Compiler.svg
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integratability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
…
What system architecture property drives/enables
understandability?
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integratability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
…
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integratability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
…
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integratability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
…
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integratability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
…
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integratability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
…
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integrateability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
…
Ability to move stuff around.
Plugs and sockets, bit and bytes
Levels of Interoperability: http://www.iiisci.org/journal/CV$/sci/pdfs/P468106.pdf
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integrateability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
…
Many efforts defining domain specific data
Addressing the definition of message (ICD) syntax
How to inform the machine about content of data
Levels of Interoperability: http://www.iiisci.org/journal/CV$/sci/pdfs/P468106.pdf
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integrateability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
…
Defining what is being said, context and semantics
• The meaning of the data, to include representation
• NOT – more content to added to the messages
Levels of Interoperability: http://www.iiisci.org/journal/CV$/sci/pdfs/P468106.pdf
Current progress…
• Modularity
• Reusability
• Extensibility
• Portability
• Integrateability
• Interoperability
•
•
•
•
Technical
Syntactic
Semantic
More…
Get to this in a moment….
Levels of Interoperability: http://www.iiisci.org/journal/CV$/sci/pdfs/P468106.pdf
Current
progress…
• FACE™ Architecture
• Data Syntax
• Data Semantics
• “Rules” of structure
• UCS Working Group
•
•
•
•
Data Architecture
Content (ICDs)
Context (Structure)
Behavior (Domain)
• Others as well…
Current
progress…
• FACE™ Architecture
• Data Syntax
• Data Semantics
• “Rules” of structure
Semantics
• UCS Working Group
•
•
•
•
Data Architecture
Content (ICDs)
Context (Structure)
Behavior (Domain)
• Others as well…
Syntax
Current progress… An Example
• Two message definitions – talking about the same thing, or not?
enum AlarmLevel {
GREEN,
RED,
YELLOW,
NO_STATUS,
NORMAL
};
struct alertType : Header {
float x, y, z;
double set_angle;
AlarmLevel status;
};
??
public final class VehicleStatus implements java.io.Serializable
{
public String ID = null;
public Position3D_WGS84 location = null;
public EngineSpeed_RadiansPerSec speed = null;
public VehicleStatus (String _id, ... )
{
....
}
}
Current progress… An Example
• Two message definitions – talking about the same thing, or not?
• Demonstrations have shown this to work!
• Still more to do, but really exciting.
• Interesting with small number of messages, powerful with 1000’s
• ICD Verification & Data Rights
• Own the rights things with the right level of detail
Where are we going…
• Pragmatic and Dynamic 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 can be done
• Have to be rigorous in the rules
• We can’t stop current progress