Capability-Based Technical Reference Frameworks for
Open System Architecture
Implementations
(Leathart, Porter, Schmidt, O’Hare, Crisp, Laird)
Presented by John R. Leathart
Chief Engineer
PEO SUB-S
Systems Integration Manager - Submarine
Warfare Systems
NAVSEA05UW
April 3, 2014
Unlocking Potential
Naval Enterprise OSA Strategy*
OSA Vision: Affordable, Open Platforms that Easily Accommodate Open Modules
• Business changes
• Implementation Tools
• OSA Training
• Technical Reference
Frameworks
*ASN RDA “Naval Open Systems Architecture Strategy” 26 November 2012
Unlocking Potential
Technical Reference Framework
• Provides a reusable architecture for a family of related applications
• An integrated set of components
Standardized specifications
Architectures
Data Models
Protocols
Tools
Unlocking Potential
Page 3
Technical Frameworks Enable Buying Choice
Open Interfaces - SPIES
SWFTS
Unlocking Potential
CANES
4
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
Capability Decomposition & the Method to the Madness
Do you meet all
10 characteristics?
YES
• You are an Open System
– Should be easy to compete in smaller components,
lending towards right-sized competition
NO
• 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
Unlocking Potential
Capability Decomposition & the Method to the Madness (cont.)
• 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
KEY TO SUCCESS
First 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
PEO Submarines Combat Systems Success Story
• 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)
Unlocking Potential
PEO Submarines Combat Systems Success Story (cont.)
• 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
• Two year cycle known as the Advanced
Processor Build (APB)
• Utilizes Open System Principles
– Published and open interfaces
– TI hardware design done on even years
– Use of open standards middleware
– APB software baselines are designed on
odd years
– Baseline management (governance) on
System of System Interfaces
Unlocking Potential
PEO Submarines Combat Systems Success Story (cont.)
• 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
Unlocking Potential
Published Open Interfaces & Standards: Methodology
•
Description of Analysis Phase to determine if an architecture lends itself to
being constituted by modular components
Applications
Applications
Sensor
Systems
C2 System
Engagement
System
Stove-piped versus
layered & modular
Weapons
Control
EO
AAW
EG
Technology base:
DII-COE
POSIX
ATM/Ethernet
Endsystem
Applications
Applications
Engagement
System
Weapons
Control
Domain-Specific Services
Common Services
Distribution Middleware
Weapons
Systems
Domain-Specific Services
Middleware
Infrastructure Middleware
Common Services
Distribution Middleware
Infrastructure Middleware
Operating
System
Endsystem
TBM
EG AAW
AAW
Technology base:
Proprietary MW
POSIX
NTDS
Operating
System
Wireless/wired Networks
Endsystem
AAW
MG
Illum
TMB
MG
AAW
AAW
Technology base:
Proprietary MW
VxWorks
FDDI/LANS
Operating
System
C2 System
Sched
Network
Technology base:
Proprietary MW
Mercury
Link16/11/4
Sensor
Systems
Kill
Eval
Weapons
Systems
Technology base:
Proprietary MW
POSIX
VME/1553
Operating
System
Wireless/wired Networks
Endsystem
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
Other
Launchers
Radars
OSA with
SOA
Comms
Other
Launchers
Radars
OSA with
Product Lines
Comms
Other
Launchers
Radars
OSA with
Domain Reuse
Comms
Other
Launchers
Radars
Early OSA
with COTS
Comms
Other
Launchers
Radars
Ad Hoc
Architecture
Comms
•
Published Open Interfaces & Standards: Methodology
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
Other
Launchers
Radars
OSA with
SOA
Comms
Other
Launchers
Radars
OSA with
Product Lines
Comms
Other
Launchers
Radars
OSA with
Domain Reuse
Comms
Other
Launchers
Radars
Early OSA
with COTS
Comms
•
Open
domainspecific
interfaces
Open
standards
Published Open Interfaces & Standards: Methodology
•
•
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
Common Data Models & Protocols for OSA Initiatives
• 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.
•
•
•
•
•
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
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
19
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.
Unlocking Potential
Better Buying Power 2.0
Promoting Effective Competition for the Life Cycle
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.
Enforce open system architectures
and effectively manage technical
data rights:
https://acc.dau.mil/bbp
21
Questions?
Unlocking Potential