“Achievement through Collaboration”

PMA209 Industry Day: Future Airborne Capability Environment (FACE) “Achievement through Collaboration” Bob Matthews PMA209 Avionics Architecture IPT L robert.matthews@navy.mil 301-757-6462 NAVAIR Public Release SPR#: 2014-531 Distribution Statement A: "Approved for Public Release Distribution is Unlimited” PMA209 develops, integrates, and delivers avionics solutions that meet customer requirements, enable interoperability, and maximize affordability.

Agenda • Why Open Architecture (OA) is Needed • Open Architecture Transition • Types of Open Architecture • FACE Reference Architecture • FACE PILE Overview • Phase I Overview • Phase I Demonstration • FACE PILE Demonstration Architecture • Documentation • Path Forward • Summary

Why OA is Needed

Open Architecture Transition Closed/Proprietary Open http://www.forbes.com/sites/darcytravlos/2012/08/22/five-reasons-why-google-android-versus-apple-ios-market-share-numbers-dont-matter/

Types of Open Architectures • Hardware OA Types • Managed by data rights only • Open Architecture based on implementation • Open Architecture based on interface and architectural pattern standardization • Interoperability OA Types • Interface control and management • Defined message definition • Semantic data model for message derivation • Software Based OA Types • Managed by data rights only • Functional Open Architecture • Open Architecture based on implementation • Open Architecture based on interface and architectural pattern standardization • Blended Approach (Two or more of the above)

Data Rights Driven Open Architecture • Relies on government purpose or unlimited data rights to enforce the openness of the architecture • Built upon non standard architectures resulting in effort to move to another architecture • Components may be monolithic, extremely complex and require major rework to reuse • Platform specifics may be included in components adding complexity and rework to reuse • Functionality of components defined by vendor • This strategy has been used for several years to enforce open architecture through use of contract language and not achieved expected results

Functional Open Architecture • Relies on defining the functionality, interoperability and behaviors of components to enforce openness • Built upon non standard architectures • Provides a functional breakdown of components within a system • Determines interactions between components • Determines messaging interface • Determines component and interface behavior • Needs focus from technical competencies to accomplish • OSD UAS Control Segment (UCS) is one example

Implementation Driven Open Architecture • Relies on a chosen set of infrastructure components to enforce the openness of architecture • Usually relies on COTS infrastructure products • May require particular commercial technologies be mandated • Couples components to the COTS infrastructure requiring modifications when COTS components replaced or moved to dissimilar architecture • Establishes unique software product line architecture for single domain that may not be flexible or scalable to other technical domains

Open Architecture based on Interface and Architecture Pattern Standardization • Relies on a set of standards to enforce the openness of an architecture • Use standard interfaces and architectural patterns to abstract components from the infrastructure implementation decoupling components from infrastructure • Establishes a product line architecture enabling flexibility in infrastructure • Provides Syntax and Semantic definition of the standardized interfaces • Can use architectural patterns to abstract platform unique requirements from capability based components enabling reuse in multiple technical domains • FACE Technical Standard defines this type of architecture, led by PMA209 and AIR-4.5

Blended Approach • Can be used to enforce the openness of an architecture • Appropriate data rights should be enforced to provide appropriate data for reusable components • The functional architecture should provide a functional breakdown of components within a system • The infrastructure implementation should be used to verify that all possible COTS technologies are utilized in a system • Interface and Architectural Pattern Standards should be used to establish the product line architectural approach

FACE Reference Architecture • FACE Portable Components Segment • Portable Applications • Portable Common Services • Transport Services Segment • Platform Specific Services Segment • Platform Device Services • Platform Common Services • Graphics Services • I/O Services Segment • Drivers • Operating System Segment

FACE PILE Overview • Build a FACE lab to develop the Technical Standard • Fused A/A and A/S tracks in a FACE architecture • Model open architecture to influence Next Gen Vertical Lift and FA-XX • Prove concept of standard by plugging existing radar, Electro-Infrared (EO/IR), and Embedded GPS/INS Inertial (EGI) into the lab • Ensure NAWCAD, NAWCWD and Industry participation • Identify organizational, training and financial changes needed to make the Business Model work • Make this action part of the Integration and Interoperability (I&I) Commander’s Guidance

FACE PILE Phase I Overview • Completed Phase I demonstration of multi-sensor data track correlation in an open architecture environment • Integrated COTS hardware and software into MZ-3A airship • Integrated Vista Maritime Radar (PGSS) • Integrated ADS-B • Integrated AIS • Integrated MX-15 (EO/IR) (PGSS) • Integrated EGI • Integrated Vortex radio (SAIL) • Baseline reference architecture provides a System of Systems integration laboratory baseline • Can be used to mature future technologies for platforms such as FA-XX and FVL • Architecture implemented multiple standards which will benefit multiple platforms • Navy Interoperability Profile (NIOP) Advanced C2 • Communication between AVS and GS • Cursor on Target (CoT) • Communication between GS and Moving Map • UCS Services Service Descriptions • UCS implementation of the FACE Data Model • Army Goal to demonstrate UCS and FACE Conformance • FACE Standard Edition 2.0 • Architectural Segments, Interfaces and Data Model

Phase I FACE Demonstration • Utilize surrogate UAV (MZ-3A Airship) • Sensor suite will include Radar/ADS-B/ AIS and EO/IR • Capable of migrating to additional platforms Distribution Statement A SPR # 2014-531 • Purpose-Demonstrate FACE Architecture • Implements FACE and UCS Conformant UAV and Ground Control Station • Communication achieved through Navy Interoperability Profile (NIOP) • Provide host for track fusion capability • Minotaur provided by JHU/APL • Fielded on EP-3

FACE PILE Demo Architecture

Documentation • Draft Distro A Documentation • Software Design Document (SDD) • Define low level use cases for the software systems • Define the approach for implementing system components on each computing platform in the software system • Define behavior of each software component, including its interactions with other components including portable components, platform specific services, I/O services, and any other software components • System Architecture Design (SAD) • Define the system use cases and map them to low level use cases • Define high level software structure for FACE components and other software components • Map software components to hardware computing platforms • Final Distro D Documentation • Distributed in accordance with DoDI 5230.24 • Additional HW/SW available • Distro D version of SDD and SAD scheduled to be available mid-July

Path Forward • Phase II underway • Integrate Government capabilities into FACE PILE • Small Business Innovative Research (SBIR) projects • SimVentions DEXTER Tool • OCI Open DDS • China Lake Efforts • FACE Mobile Application • System of Systems Engineering for FACE I&I Architectures • Architecture Management Integration Environment (AMIE) • Terrain Awareness Warning System (TAWS) • Sensor/Platform Interface and Engineering Standards (SPIES) • FACE Verification Authority Proposal (AIR 5.4)

Path Forward Continued • Phase III • Strong support from VADM Dunaway • “I want us to work together and expand Phase III of the FACE PILE project to take it to another level. We should approach this as if we are going to define and mature the backbone of a future architecture focused lab now. This will enable us to build confidence in our approach through experimentation and position ourselves strategically to manage an open architecture (hardware and software) product lines. This lab will enable us to experiment with both industry and government capabilities to determine best of breed capabilities and open architecture practices.” • Goals • Demonstrate software capabilities aligned with FACE Technical Standard, Edition 2.0 • Other Ecosystem support • Benefits • Promotes FACE adoption • Allows industry to gain experience integration into government reference architecture • Enhances FACE Data Architecture • Demonstrates the FACE Technical Standard in a representative environment • Responses • 18 companies proposed 22 projects • Review period – April – May 2014 • Sources Sought Review Summit – mid-June 2014 • Integration/Demonstrations ~ June 2014 – ongoing

Summary • FACE is a business strategy that can change the landscape of software acquisition • Phase I demonstrated correlation of multi-sensor data in an open architecture environment • The architecture, including the ground station and services, implemented multiple standards and technologies that provide testable OA requirements that meet MOSA and will benefit multiple program offices • Phase II and III efforts are underway and will allow additional government and industry validation efforts to occur • FACE Technical Standard should be considered for any software procurement where reuse is a goal

Questions? Bob Matthews PMA209 Avionics Architecture IPT Lead robert.matthews@navy.mil 301-757-6462 “Achievement through Collaboration”

Back-Up Slides “Achievement through Collaboration”

Importance of Semantic Interoperability • Navy needs a system-of-systems interoperability • An infrastructure based upon technical, syntactic and semantic standards is required • There are choices for technical and syntax • No sufficient standards for semantics (lacking flexibility, extensibility) • We need more than standards, we need an Open “Interoperable” Infrastructure • Based on open standards • An extensible data model vice a message model • Data model captures semantics and is open and published

Data Model vs Message Model • Message Models provide syntactic interoperability • Used to document the data exchanged between components of a system • Content of each message may be optimized to match the data needs of the sending and receiving applications • Structure may be optimized for transport efficiency • Is intended to be encoded for transport • Data Models provide semantic interoperability • Representation of the elements within the scope of the system • Require sufficient detail to unambiguously capture the relevant state information of each element • Documents the associations and relationships (context) that are relevant to the system • Documents the semantics of the elements • Captures the semantics subjectively by descriptions • Captures the semantics objectively be relations that link elements of similar meaning to “generalizations” or abstractions of the concepts • Extent of abstraction required depends upon the level of interoperability required to meet NF- requirements • Relationship of Message Model to Data Model • Message Model is a “View,” or rearrangement of the Data Model for the purpose of data exchange • Different Message Models, optimized for different transport purposes, derived from the same Data Model, share the same semantic definitions and are Interoperable

Relevance to I&I • Uses the FACE Standard to Create a Common Software Architecture for Future Platforms • Common payloads require common platform interfaces • Modularity allows competitive award of new capabilities with rapid and affordable integration across platforms • Enables Government Led Capability Integration Through Standardization of Key Software Interfaces • Provides shared data model to allow interoperability between disparate systems • Uses the Common Standards and Interoperability (CSI) NIOP • Can easily integrate Sensor/Platform Interface and Engineering Standardization (SPIES) enabled sensor

FACE Timeline Distribution Statement A SPR#: 2014-531 • FACE Technical Standard • Ed. 2.1 Begin UCS Alignment Expansion of Adoption DoN, Army…DoD • FACE Technical Standard Ed. 3.0 • FACE Procurement Guide • Unmanned Carrier Launched Airborne Surveillance and Strike (UCLASS) PDR Contract Award Aug 2013 Navy Awards C-130T AOU Full FACE conformant Contract Sep 2012 • Autonomous Aerial Cargo Utility System (AACUS) ONR BAA released DEC 2011. Army JMR Phase 2 MS ETA BAA released FEB 2012 • Next Gen Jammer (NGJ) TD Contract Award Jan 2014 PMA209 FACE Technical Standard: Ed. 1.0 = Framework Ed. 2.0 = Common Data Model, Health Monitoring, Implementation Guide Ed. 2.1 = Enhanced Data Model, Transport Services Implementation Ed. 3.0 = Security System MAY 2014 OCT 2015 AUG 2011 AUG 2008 JUN 2010 JAN 2012 MAR 2013 AMRDEC released RFI for FACE Reference COE FEB 22, 2012

FACE Consortium Members • Lockheed Martin • Naval Air Systems Command (NAVAIR) • US Army PEO Aviation • Rockwell Collins • Sponsor Level Member Organizations • ATK • BAE Systems • Bell Helicopter • Boeing • Elbit Systems of America • GE Aviation Systems • General Dynamics • Green Hills Software • Harris Corporation • Honeywell Aerospace • IBM • Northrop Grumman • Raytheon • Sierra Nevada Corp. • Sikorsky Aircraft • Textron Systems • US Army AMRDEC • UTC Aerospace Systems • Wind River • Principal Level Member Organizations • AdaCore • Astronautics Corporation of America • Avalex Technologies • Avionics Interface Technologies • Barco Federal Systems • Brockwell Technologies • CALCULEX • Carnegie Mellon Univ. – Software Engineering Institute • CERTON Software, Inc. • Chesapeake Technology Int’l. • CMC Electronics • Cobham Aerospace Communications • Core Avionics & Industrial Inc. • CTSi • Curtiss-Wright Defense Solutions • DDC-I • DornerWorks • Draper Laboratory • Enea Software & Services • ENSCO Avionics • Esterel Technologies • Exelis Inc. • Fairchild Controls • GE Intelligent Platforms • General Atomics Aeronautical Systems, Inc. • Howell Instruments, Inc. • Johns Hopkins Univ. - APL • Kaman Precision Products • KIHOMAC • Kutta Technologies • L-3 Communications • LDRA Technology • LynuxWorks • Mercury Systems • Mobile Reasoning, Inc • Physical Optics Corp. • Presagis USA, Inc. • Pyrrhus Software • QinetiQ North America • Real-Time Innovations • Richland Technologies • Selex Galileo Inc. • Stauder Technologies • Support Systems Associates • Symetrics Industries • Technology Service Corporation • Thomas Production Company • Tresys Technology • TTTech North America, Inc. • Tucson Embedded Systems • US Army Electronic Proving Ground • Verocel • Zodiac Data Systems • Associate Level Member Organizations • The FACE Consortium was formed in 2010 by The Open Group Distribution Statement A SPR#: 2014-531 * The most current list of members can be found at http://theopengroup.org/face/member-list PMA209“Achievement Through Collaboration”

Open Architecture Requirements • DoD Directive 5000.1 • “E1.1.27. Systems Engineering. Acquisition programs shall be managed through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs. A modular, open-systems approach shall be employed, where feasible.” • N6/N7 Naval Open Architecture (NOA) Requirements Letter 9010, Ser N6N7/5U916276, 23 Dec 05 • This letter establishes the requirement to implement Open Architecture (OA) principles across the Navy Enterprise. Warfare systems include hardware, software and people. • SECNAVINST 5000.2E • “Naval open architecture precepts shall be applied across the Naval Enterprise as an integrated technical and business approach and shall be used for all systems, including support systems, when developing an Acquisition Strategy per ASN(RD&A) memorandum of 5 Aug 04 and CNO (N6/N7) memorandum of 23 Dec 05 with enclosure (1).” • FACE is a rigorous and enforceable definition of OA • FACE is a standard, not a program or product • Single, open interpretation of existing industry standards and software best practices • Established collaboratively between services and industry • Initiated to achieve the goals of OA by explicitly addressing the business and technical issues which plagued other OA attempts Distribution Statement A SPR#: 2014-531 PMA209“Achievement Through Collaboration”

Technologies and Standards • FACE Standard Edition 2.0 • Architectural Segments, Interfaces and Data Model • Minotaur Track Fusion capability • Navy Interoperability Profile (NIOP) Advanced C2 • Communication between AVS and GS • Cursor on Target (CoT) • Communication between GS and Moving Map • UCS Services Service Descriptions • UCS implementation of the FACE Data Model • Army Goal to demonstrate UCS and FACE Conformance Distribution Statement A SPR#: 2014-531 PMA209“Achievement Through Collaboration”

FACE Conformant UCS Services • UCS Primary Mission Control Domain Services • Vehicle Interface Service • Vehicle Flight Status Service • Vehicle Config and Characteristics Service • Vehicle Flight Control Service • Manage Vehicle Plan Service • Vehicle Subsystem Control and Status Service • Allocate UAV Resource Service • Monitor UAV Resource Service • Release UAV Resource Service • Manage UAV System Status Service • Manage UAV Health Service • Allocate Sensor Service • Deallocate Sensor Service • EOIR Sensor Service • SAR Sensor Service • Sensor Pedestal Service • Sensor Plan Manager Service • Manage Mission Plan Catalog Service • Mission Plan Execution Manager Service • Monitor Mission Status Service • Configure Datalink Service • Comms Control Service • Comms Status Service • Vehicle Messenger Service • UCS External Messaging & Control Domain Services • Weather • UCS Mission Planning Domain Services • Integrate Mission Plan Service • Mission Verification and Validation Service • Mission Planning Information Service • Generate Route Plan Service • Route Evaluation Service • Generate Payload Plan Service • EOIR Sensor Planning Service • SAR Sensor Planning Service • Sensor Plan Evaluation Service • Payload Dissemination Planning Service • UCS Dynamic Airspace Domain Services • Information Publisher Service • Provide Blue Force SA Service • UCS Sensor Product PED Domain Services • Sensor Manager Service • Dissemination Service • Stream Catalog Service • EOIR Capture Service • SAR Capture Service • Cache Service * Greenhighlight indicates service is exercised in demo – Redindicates implemented, but not exercised – Yellow highlight indicates FACE conformant, but, not implemented using UCS Distribution Statement A SPR#: 2014-531 PMA209“Achievement Through Collaboration”

“Achievement through Collaboration”