Unlocking Potential

Capability-Based Technical Reference Frameworks for Open System Architecture

Implementations(Leathart, Porter, Schmidt, O’Hare, Crisp, Laird)

Presented by John R. LeathartChief Engineer

PEO SUB-SSystems Integration Manager - Submarine

Warfare SystemsNAVSEA05UW

April 3, 2014

Unlocking Potential

Naval Enterprise OSA Strategy*

• Business changes

• Technical Reference Frameworks

• Implementation Tools

• OSA Training

*ASN RDA “Naval Open Systems Architecture Strategy” 26 November 2012

OSA Vision: Affordable, Open Platforms that Easily Accommodate Open Modules

Unlocking Potential

Technical Reference Framework

Page 3

• Provides a reusable architecture for a family of related applications• An integrated set of components

Standardized specifications

Architectures

Data Models

Protocols

Tools

Unlocking Potential 4

Open Interfaces - SPIES

Technical Frameworks Enable Buying Choice

SWFTS CANES

Unlocking Potential

Do You Have a Closed System?

• Is your system delivered through a single contract

– If so, has it been that way for a while?

• Is that prime contractor the only one who knows how your system is architected?

If you answered yes to these two questions, then you are at high risk of a having closed system

Unlocking Potential

What to do if You Have a Closed System• 1st step is to analyze your architecture

• Acquire system architecture documents and compare them to the following ten attributes

• Federated Acquisition/Integrated Operation• Data Driven• Expandable (Adaptable, Scalable, Extensible)

• Authoritative Governance• Published and Discoverable• Reduced Complexity (Modular Design, Minimized Coupling, Clear/Concise/Consistent)

• Be Open (Use of Open Standards, Support Re-Use, Utilize Central Services)

• Be Secure (Compliant, Certifiable, Reliable)

• Reusability (Portable Components)

• Defined Intellectual Property and Data Rights

Unlocking Potential

• You are an Open System– Should be easy to compete in smaller components,

lending towards right-sized competition

• You are not Open and need an plan of action – Describe at a high level the capability you are delivering – Using the description, define the pieces of that capability that when

combined make up that whole capability– Repeat the step on the pieces until it makes sense to stop

• Each piece should be clearly defined, easy to understand, and the individual capabilities are of manageable size

Capability Decomposition & the Method to the Madness

Do you meet all 10 characteristics?

YES

NO

Unlocking Potential

• You are not Open and need an plan of action (Continued)– Map the existing system in to these pieces

• If the mapping is difficult it is likely your systems architecture is lacking and that piece may need to be re-architected

• Change should be accomplished in an evolutionary, not revolutionary, manner• Map out the evolutionary plan of change of the architecture

• Requires defining interfaces between components• Use open principles for interfaces (published, using industry standards)

• Provides a manageable risk profile

Capability Decomposition & the Method to the Madness (cont.)

KEY TO SUCCESSFirst step should be modest and not aggressive

– Pick a piece outside of the programs critical path– Goal should be to prove the viability

Unlocking Potential

• BSY-2 Combat System for Seawolf Class submarines• Last submarine combat systems designed under GOTS procurement

• Very Capable• Very Costly & Delivered late

• After initial three Seawolf Class submarines were built the program was cancelled due to cost, with the combat systems significantly contributing to that cost

• Virginia Class submarines and COTS based combat systems• Design of the Submarine Warfare Federated Tactical Systems (SWFTS)

• Hardware capability defined by the 2yr Technical Insertion (TI) process• Software was based on a data driven design

• Data model defined with 14 data groups utilizing an open standard middleware• Programatically broken up into separate PMOs each delivering a piece of the

overall combat system (Sonar, Tactical Control, Weapons Control, Imaging, etc)

PEO Submarines Combat Systems Success Story

Unlocking Potential

• Virginia Class submarines and COTS based combat systems (cont.)– Some significant keys to success of the APB process were

• The process brings in all sized businesses proposing solutions to requested topics Significant small business participation

– Software lifecycle created to support a drumbeat of improved capability

PEO Submarines Combat Systems Success Story (cont.)

• Two year cycle known as the Advanced Processor Build (APB)

– TI hardware design done on even years– APB software baselines are designed on

odd years

• Utilizes Open System Principles– Published and open interfaces – Use of open standards middleware– Baseline management (governance) on

System of System Interfaces

Unlocking Potential

• The solution was originally for Virginia Class submarines but were then extended to the other classes of fast attack submarines

• Has been in place for longer than a decade• Significant cost reductions of the cost of acquisition and maintenance of the

combat systems on the fast attack submarine fleet• Has dramatically reduced cost and has provided rapid new capability insertion to

the substantial benefit of the fleet.

• This is an example of how open systems principles work• Took a large monolithic combat system (BSY-2) and re-factored the capabilities

using open system principles• Has been working for more than a decade and still works• The TI and APB processes have been lauded as a model for acquisition in warfare

systems

PEO Submarines Combat Systems Success Story (cont.)

• Description of Analysis Phase to determine if an architecture lends itself to being constituted by modular components

Endsystem EndsystemWireless/wired Networks

Sensor Systems

Weapons Systems

C2 System Weapons Control

Technology base:Proprietary MWVxWorksFDDI/LANS

EngagementSystem

Technology base:Proprietary MWPOSIXVME/1553

KillEval SchedEO

Network

AAWEG

AAW

AAWTBMEG

AAWAAW

AAWMG

TMBMG

Technology base:Proprietary MWMercuryLink16/11/4

Technology base:DII-COEPOSIXATM/Ethernet

Technology base:Proprietary MWPOSIXNTDS

Applications Applications

Operating System

OperatingSystem

Illum

Applications

Endsystem

Applications

EndsystemWireless/wired Networks

Common ServicesDistribution Middleware

Infrastructure Middleware

Domain-Specific Services

Middleware

Wireless/wired Networks

Sensor Systems

Weapons Systems

EngagementSystem

Common ServicesDistribution Middleware

Infrastructure Middleware

Domain-Specific Services

Operating System

OperatingSystem

C2 System Weapons Control

Stove-piped versus layered & modular

Published Open Interfaces & Standards: Methodology

• Determine the granularity & capability scope of the open interfaces & standards• Granularity is a measure of the “surface area” of the interface• Capability scope identifies the layer(s) of abstraction that are

addressed

Published Open Interfaces & Standards: Methodology

Com

ms

Rada

rs

Laun

cher

s

Othe

r

Early OSAwith COTS

Com

ms

Rada

rs

L aun

cher

s

Oth e

r

OSA with Domain Reuse

Com

ms

Rada

rs

Laun

cher

s

Othe

r

OSA withSOA

Com

ms

Rada

rs

Laun

cher

s

Oth e

r

OSA withProduct Lines

Com

ms

Rada

rs

Laun

cher

s

Othe

r

Ad HocArchitecture

• Determine which of the identified components can be published as either • Open standards, which either exist already or which could be

defined/ratified via a recognized standards organization, or• Published domain-specific interfaces (local standards), which are

defined by agreements amongst government & contractors in one or more domains

Open standard

s

Open domain-specific

interfaces

Published Open Interfaces & Standards: MethodologyCo

mm

s

R ad a

r s

L aun

cher

s

Oth e

r

Early OSAwith COTS

Com

ms

Rada

rs

Laun

cher

s

Othe

r

OSA with Domain Reuse

Com

ms

R ad a

r s

L aun

cher

s

Oth e

r

OSA withSOA

Com

ms

R ad a

r s

L aun

cher

s

Oth e

r

OSA withProduct Lines

• Determine the appropriate governance models best suited for defining, adopting, & publishing the open interfaces & standards

• Relevant examples include• International standards

bodies• Vendor-centric “de facto

standards” • Managed

Government/Industry consortium

Published Open Interfaces & Standards: Methodology

• Common data models & protocols help achieve interoperability between hardware and/or software applications & services

• These common data models & protocols simplify data interchange & exchange between components from different suppliers or components implemented using different technologies.

Common Data Models & Protocols for OSA Initiatives

Unlocking Potential

What is a Common Data Model and Why is it Important?

• Common data models define the terminology that a program uses for all of its data sources and the relationships that exist between different data items

• A common data model enables data interoperability between applications

• A Government owned data model can provide protection from a vendor lock on their interfaces

• Ensure interoperability between applications • A Common Data Model

– Allow applications to loosely coupled– Applications can upgrade at their own pace, because the data model

provides for a common exchange

Unlocking Potential

Commercial Industry Using Data Models

Amazon and Facebook -Utilize a common data model to share key characteristics of their customers

Apple and Samsung -Use Data Models to Support the Quick Launch of New Smart Phone Products

Unlocking Potential

Navy Implementation of a Data Model

19

The Anti Submarine Warfare (ASW) Community of Interest Data Model (ACDM)is:

• An information exchange model– A standard to support moving information between systems– Designed to provide unambiguous interpretation

• Intended as a living model– Continually evolve to the changing needs of the ASW community– Grow in capability as the sophistication of ASW systems increases

• Developed to be Flexible– Support interoperability between software platforms– Extensible/scalable for individual system / program needs

• Broad in scope– Tracks and situational awareness– Sensor metrics and sensor data– Mission planning– Simulation and training– Reconstruction and analysis

Unlocking Potential

TRF Governance Plan• Guides the TRF description in acquisition program

documents such as – • Acquisition Plan• RFP• System Engineering Plan• Interoperability DODAF Views• Information Support Plan• System Specifications• Software Development Plan• Configuration Management Plan

• Creates a coherent picture concerning adherence to OSD and Navy OSA policy.

21

Better Buying Power 2.0Promoting Effective Competition for the Life Cycle

https://acc.dau.mil/bbp

Enforce open system architectures and effectively manage technical data rights:

This item is continued from BBP 1.0 and will focus on improving the Department’s early planning for open architectures and the successful execution of the plan to provide for open architectures and modular systems. This will include the development of a business model and associated intellectual property strategy (data rights planning) that can be implemented over the lifecycle of the product, starting while competition still exists.

Unlocking Potential

Questions?