panel 3: open architecture going dod-wide - defense daily · professor of computer science, ... air...
TRANSCRIPT
Panel 3: Open Architecture Going DoD-Wide
#OA2012
Moderator: Nickolas Guertin, Director for Transformation, Deputy Assistant Secretary of the Navy for Research, Development, Test and Evaluation Speakers: Mr. Rich M. Ernst, Interoperability Lead, Office of the Secretary of Defense for Acquisition, Technology, and Logistics, Unmanned Warfare
Dan Gahafer, Forge.mil Program Manager, Defense Information Systems Agency (DISA)
Dr. Douglas C. Schmidt, Professor of Computer Science, Vanderbilt University
Robert Sweeney, Future Airborne Capability Environment Lead Engineer, Air Combat Electronics, PMA-209
2
Unmanned Aircraft Ground Control Stations (UCS)
Open Architecture Summit - 2012 Rich Ernst
OUSD S&TS/ Interoperability Lead
UNCLASSIFIED
UNCLASSIFIED - Pubic Release 12-S-1669
OSD ADM ‘Common DoD Architecture’
3
OUSD ST&S UAS Common Architecture DoD Open App Store Marketplace
30+ PoR ready Apps & Demos PoR: TCS, Block 50, and Global Hawk
Potential PoR: OSRVT
DoD Contract Guidebook & IP Rights Open Business Model for UAS GCSs RFP Language for UAS GCSs
Open GCS Architecture for UAS Joint HMI Style Guide for GCSs
2.1 Architecture Model HMI Guide
Existing UCS ADMs: OSD, Army, Navy, Air Force UCS ADMs: GSRA
UNCLASSIFIED - Pubic Release 12-S-2677
OSD UCS Working Group Our Product is Stakeholder Consensus
• Technical Society
• Chartered by Joint UAS Task Force Interoperability IPT
• Program of Work and Operating Rules defined in DoDAF AV-1
• Operating Rules per Public Law 104-113 (NTTAA) and OMB Circular A-119
• Private collaboration site for Working Group members
• Visit public site at http://www.ucsarchitecture.org (video demos included)
• OUSD UCS architecture documents consist of:
UCS-WG As of Jan 2012 200+ Organizations
640+ Members 25+ Funded Companies
Architecture Description Program of Work Governance Style Guide Conformance Specification System Safety and Airworthiness Management Plan Information Assurance Management Plan Core Application Program Interface Standards Platform Independent Model (PIM): Application Platform Independent Model (PIM): Infrastructure Platform Independent Model (PIM): IA and Security Mgmt Platform Independent Model (PIM): Deployment Architecture System Implementations: Deployment Architecture System Implementations: Mobile Deployment Architecture System Implementations: Fixed Facility
Deployment Architecture Platform Guidance for Safety and Information Assurance System Safety and Airworthiness Case Information Assurance Case Architecture Description Model Driven Architecture (MDA) Transform Reference Interface Control Document (ICD) Platform Independent Model (PIM): Application Platform Independent Model (PIM): Refined PIM Interface Control Document: Data Distribution Service (DDS) Interface Control Document: Java Messaging Service (JMS) List of UCS Architecture Validation Experiments 1.0 ToolTrade Development Tool Trade Study
June, 2011
Open Business Model for Unmanned Aircraft Systems Ground Control Stations
An open business model will promote competition and innovation while reducing costs
OBM is designed to: 1. Target affordability 2. Incentivize productivity and innovation 3. Promote real competition
The Ground Control Station Open Business Model is an
approach for doing business in a transparent
way that leverages the collaborative innovation of
numerous participants across the enterprise
permitting shared risk, maximized asset reuse, and
reduced total ownership costs.
UNCLASSIFIED - Pubic Release 11-S-3277
OBM v2 Release w/RFP Language
Feb 2009, OUSD (AT&L) Mandates Common GCS Architecture
July 2011, Navy Mandates UCS Architecture
July 2011, Army Mandates UCS Architecture
2012, Joint UAS Open Business Model
May 2009, USAF signs out UCS in AF Flight Plan 2009-2047
1
2
3
4
6
Sept 2011, UCS Architecture Ver. 2.0 5
7
OUSD - Improving Interoperability and Affordability Across UAS Domain
May 2012, GSRA (GSTR) UCS ADM
9 Jun 2012, HMI Common Guide
8
May 2012, UCS Architecture Ver. 2.1 7
UAS App Store 10
Contract Ready
OSD has developed a common architecture and designed an open business model to meet its objectives
UCS Arch V2.2 to be Released 8
UCS-WG Demo Activities
OUSD/AT&L ADM Published
UCS Arch V0.5 Released
UCS Arch V1.0 Released
UCS Arch V2.0 Released
UCS Industry
Days
UCS Arch V2.1 Released
IWP Demo
UCS Arch V2.0
Kickoff
Feb 2009 May 2009 Dec 2009 Jun 2010 Aug 2010 Nov 2010 Jan 2011 May 2011 Sept 2011
pkg Blue Force SA Serv ice
«servicePoint» Blue Force SA«requestPoint» Responses«service»
Blue Force SA Sv c
«servicePoint» Blue Force SA«requestPoint» Responses
BlueForceSARequests
BlueForceSAResponses BlueForceSARequests
BlueForceSAResponsespkg Blue Force
«servicePoint»Blue Force SA «requestPoint» Translate
«Domain»Blue Force
«servicePoint»Blue Force SA «requestPoint» Translate
BlueForceSARequestsBlueForceSAResponses
BlueForceSARequests
BlueForceSAResponses
Additional OSD Funding for next phase
HMI Study Plan kickoff
Implementation Structuring
UCS Industry Brief to OUSD
Structuring Industry
2009 Concept
Exploration
Dec 2009 Version 0.5 Incl. AV-1
May 2012 Version 2.1
Nov 2012 Version 2.2
Architecture Modeling (Funded)
June 2010 Version 1.0
Nov 2010 IWP Demo Mar 2011 JSIL Demo
Architecture Definition & Demonstration
Oct 2011 Nov 2011 May 2012 May 2012 June 2012 July 2012 Aug 2012 Nov 2012 Feb 2013
Enduring Organization
BDRVT Flight Test
June 2011 Version 2.0
Version 3.0
HMI Common Style Guide Final Spec.
Global Hawk ADM
UCS Compliant BDRVT test
Next phase TBD
Reusable Code Cost Savings
9 Pubic Release 12-S-2840
Behavio
r Code
Autogenerat
ed IF Code
Custom IF
Code
Projected Cost
Savin
gs
(Minim
al)
Complete UCS S
ervice
Projected Cost
Savin
gs
(Industr
y Ave
rage)
Autogen IF
Code
Total C
ost Sa
vings
(Industr
y Ave
rage)
UCS Servi
ce
SLOC SavingsUCS-AllocateUAVResourceService 488 34,331 1,631 972,000$ 6,316,904$ 6,706,800$ UCS-HandoverUAVResourceService 6,086 40,709 3,794 1,349,040$ 7,490,456$ 9,308,376$ UCS-VehicleFlightControlService 539 31,496 1,528 895,013$ 5,795,264$ 6,175,589$ UCS-SensorPedestalService 299 28,699 292 781,067$ 5,280,616$ 5,389,362$ UCS-EOIRSensorService 320 29,709 395 811,307$ 5,466,456$ 5,598,018$ UCS-EOIRSensorAutomationService 74,394 43,212 4,717 3,261,947$ 7,951,008$ 22,507,434$ UCS-VehicleInterfaceService 30,562 50,664 7,399 2,363,333$ 9,322,176$ 16,306,997$ Shared DDS code 699 18,640$ -$ 128,616$
Total: 112,688 258,820 20,455 10,452,347$ 47,622,880$ 72,121,192$
Cost Savings Assumptions (Minimal): Based on all code, 30 LOC produced per day, $100/hr billing rate
Cost Savings Assumptions (Industry Average): Based on autogenerated code, 10 LOC produced per day, $230/hr billing rate
391,963 (Industry Avg.) (Minimal)
(Industry Avg.)
UCS Services
BDRVT – UCS Services
Additional – UCS Services
TCS Products
UCS 2.1+ App Store Products
Primary Mission Control System Support
EMC
Dynamic Airspace Dynamic Airspace cont’d
System Support
Primary Mission Control Sensor Mgmt Vehicle Flight Status
Vehicle Interface
Vehicle Flight Ctrl
Vehicle Subsystem Ctrl/Status
Manage UAV Health
Vehicle Messenger
Manage WCAs Vehicle Config. Data
Vehicle Flight Status
Chat
White Boarding
World Wind
Google Earth
Annotation (White Boarding)
SA (Combined Forces)
Vehicle Handover
Mission Mgmt Planning
Generate Route Planning
EO/IR Sensor Search
Sensor Pedestal
Sensor Plan Manager
EO/IR Sensor Planning
Airspace Restrictions
Flight Ctrl
Planning
UNCLASSIFIED - Pubic Release 12-S-2677
UCS-WG As of Jan 2012 200+ Organizations
640+ Documented Members 25+ Funded Companies
Summary • V2.1 completed in May 2012 (first baseline finished specification)
• Included final open architecture specification for the following PoRs: Global Hawk, BAMS, Gray Eagle, Predator/Reaper, and Fire Scout
• V2.2 will be completed end of November 2012 (completing the core architecture services) • Supported by Government and Industry stakeholders • Technical Society is the right business model for Gov to benefit from • Responsive to acquisition priorities • Effective Competition
• Reusability
• Interoperability
• Rapid Capability to Warfighter
• Continued Innovation
• Acquisition Efficiency
• Demonstrations
• Reach Out
• Publications • UAS Digest (June 2011), Unmanned Vehicles (UK) (February 2012)
• Conferences • AUVSI North America (August 2011 and Aug 2012) Presentations
• PEO U&W PMA 281, DPM PM UAS, • Lead Engineer, Global Hawk Capabilities Branch • UCS-WG Industry Members
• Rover • MAESTRO • App Store Environment
• CDL - Integration of six (6) previously stand-alone services • Bidirectional Remote Video Terminal (BDRVT) – PoR • Successfully completed demonstrations across: Army, Navy, & USAF
Pubic Release 12 S 1669
H A S
12
Questions?
Panel 3: Open Architecture Going DoD-Wide
#OA2012
Moderator: Nickolas Guertin, Director for Transformation, Deputy Assistant Secretary of the Navy for Research, Development, Test and Evaluation Speakers: Mr. Rich M. Ernst, Interoperability Lead, Office of the Secretary of Defense for Acquisition, Technology, and Logistics, Unmanned Warfare
Dan Gahafer, Forge.mil Program Manager, Defense Information Systems Agency (DISA)
Dr. Douglas C. Schmidt, Professor of Computer Science, Vanderbilt University
Robert Sweeney, Future Airborne Capability Environment Lead Engineer, Air Combat Electronics, PMA-209
OA Summit, October 18th, 2012
Open System Architecture (OSA):
Challenges & Success Drivers
Professor of Computer Science
Institute for Software Integrated
Systems
Vanderbilt University
Douglas C. Schmidt [email protected]
Visiting Scientist
Evolution of DoD Combat Systems C o
m m
s
R a d a
r s
L a u n
c h e r
s
O t h
e r
Traditional Stovepipe
C o m
m s
R a d a
r s
L a u n
c h e r
s
O t h
e r
Early OSA with COTS
C o m
m s
R a d a
r s
L a u n
c h e r
s
O t h
e r
OSA with Domain Reuse
C o m
m s
R a d a
r s
L a u n
c h e r
s
O t h
e r
OSA with SOA
Key Questions • When has OSA been successful thus far? • Why hasn’t OSA succeeded further? • How can OSA be more successful in the future?
C o m
m s
R a d a
r s
L a u n
c h e r
s
O t h
e r
OSA with Product Lines
When Has OSA Been Successful Thus Far? Alignment between business incentives, technical maturity, & managers perceptions of risk prudence
Provide mechanisms to manage endsystem resources, e.g., CPU scheduling, memory management, file systems & IPC
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
Operating Systems & Protocols
Domain-independent commonality
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
Operating Systems & Protocols
Encapsulates & enhances native OS mechanisms to create reusable network programming components
Alignment between business incentives, technical maturity, & managers perceptions of risk prudence
Domain-independent commonality
When Has OSA Been Successful Thus Far?
Defines distributed programming components & APIs that automate & extend OS mechanisms
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
Operating Systems & Protocols
Alignment between business incentives, technical maturity, & managers perceptions of risk prudence
Domain-independent commonality
When Has OSA Been Successful Thus Far?
Domain-independent commonality
Defines reusable domain-independent services that simplify distributed computing
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
Operating Systems & Protocols
Alignment between business incentives, technical maturity, & managers perceptions of risk prudence
When Has OSA Been Successful Thus Far?
Domain-Specific Services
Domain-specific commonality
Tailored to requirements of specific warfighter domains, e.g., C4ISR, avionics, air defense, etc.
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
Operating Systems & Protocols
Alignment between business incentives, technical maturity, & managers perceptions of risk prudence
When Has OSA Been Successful Thus Far?
Why Hasn’t OSA Succeeded Further?
Serialized phasing of OSA infrastructure & application development postpones identifying design flaws that degrade system QoS until late in the lifecycle, i.e., during system integration
Despite substantial technical advances during the past decade, affordable & dependable OSA-based solutions remain elusive
Glacially slow contracting processes don’t support timely delivery of OSA capabilities to meet mission needs
Despite substantial technical advances during the past decade, affordable & dependable OSA-based solutions remain elusive
Why Hasn’t OSA Succeeded Further?
Contracting models that assume OSA requirements can be fully defined up front are expensive when inevitable changes occur
Despite substantial technical advances during the past decade, affordable & dependable OSA-based solutions remain elusive
Why Hasn’t OSA Succeeded Further?
Quality-of-service (QoS) suffers when OSA initiatives use COTS products that are not suited for mission-critical DoD combat systems
Despite substantial technical advances during the past decade, affordable & dependable OSA-based solutions remain elusive
Why Hasn’t OSA Succeeded Further?
Rigid adherence to ossified standards & reference architectures impedes OSA technology refresh & limits application capabilities
Despite substantial technical advances during the past decade, affordable & dependable OSA-based solutions remain elusive
Why Hasn’t OSA Succeeded Further?
At the heart of these problems is the lack of an holistic approach that aligns & balances key business, management,
& technical drivers at scale
Despite substantial technical advances during the past decade, affordable & dependable OSA-based solutions remain elusive
Why Hasn’t OSA Succeeded Further?
Joint Tactical Radio System (JTRS) is a poster child for lack of alignment between business, management, & technical drivers
Why Hasn’t OSA Succeeded Further?
Some key problems
• Business model disincentivized completion of design phase
• The Software Communication Architecture was a poorly specified standard, which impeded portability & interoperability
• “Tragedy of the Commons” complicated effective program management & acquisition strategy encouraged “requirements creep”
Technical Drivers
Foundations of OSA
development
Management Drivers
Ensuring effective leadership & guidance
of OSA initiatives
Business Drivers Achieving effective
governance & broad acceptance of OSA economic aspects
Strong S&T Connections to Reduce
Risk Mastery of
Agile Lifecycle Methods
Understand the Strategic
Role of Software
Managed Industry/
Government Consortia
Agile Contracting
Model Data Rights & Effective Licensing
Model
Systematic Reuse
Expertise
Agile Architecture
Expertise
Automated Conformance & Regression
Test suites
...
OSA
How Can OSA Be More Successful in the Future? Successful OSA initiatives need
aligned multi-dimensional approaches
How Can OSA Be More Successful in the Future? Effective open competition requires economic & value-based OSAs
Key attributes • Crisply defined software &
system technical architecture • Enable focused competition
at component, subsystem, & system levels
• Modular innovation potential • New economically-guided
criterion for decomposing OSAs into modules
• Competitive evolutionary procurement processes
• Generate a sequence of evolutionary improvements over DoD program lifecycles, instead of just point solutions
Concluding Remarks
• OSA initiatives for defense systems need a holistic strategy
• OSAs are achievable & valuable, though not easy to develop & sustain
• Alignment in business, management, & technical dimensions is essential
Strong S&T Connections to Reduce
Risk Mastery of
Agile Lifecycle Methods
Understand the Strategic
Role of Software
Managed Industry/
Government Consortia
Data Rights & Effective Licensing
Model Agile Contracting
Models
Systematic Reuse
Expertise
Agile Architecture
Expertise
Automated Conformance & Regression Test Suites
...
OSA
“Big breakthroughs often happen when what is suddenly possible meets what is desperately necessary” – Thomas Friedman
Panel 3: Open Architecture Going DoD-Wide
#OA2012
Moderator: Nickolas Guertin, Director for Transformation, Deputy Assistant Secretary of the Navy for Research, Development, Test and Evaluation Speakers: Mr. Rich M. Ernst, Interoperability Lead, Office of the Secretary of Defense for Acquisition, Technology, and Logistics, Unmanned Warfare
Dan Gahafer, Forge.mil Program Manager, Defense Information Systems Agency (DISA)
Dr. Douglas C. Schmidt, Professor of Computer Science, Vanderbilt University
Robert Sweeney, Future Airborne Capability Environment Lead Engineer, Air Combat Electronics, PMA-209
FACE™ is a Trademark of The Open Group
Robert Sweeney Naval Air Systems Command
FACE TWG Chair
Transforming
Defense Through the Use of Open
Architecture
NAVAIR Public Release 12-1141 (prior versions
11-1134, 11-1510, and 12-524) Distribution Statement A
"Approved for public release distribution is unlimited”
18 October 2012
33 http://www.opengroup.org/face
Agenda
• The Problem • The Solution: FACE • Why FACE? • Summary
34 http://www.opengroup.org/face
The Problem: Barriers to Portability
• Truly portable applications require common open standards at multiple layers in the architectures to prevent lock-in and improve competition throughout supply chain
• Uniform application of common open standards across DoD aviation needed to break “Cylinders of Excellence”
TraditionalApplication
PresentationConcerns
(Display H/W & S/W, headless transports, cursor
devices, etc.)
Business Logic Concerns(Many MIL-STDs, FMF, RNP/RNAV, Situational
Awareness, etc.)
I/O Concerns(Interface Cards, Radio ICDs, Networks, OFPs,
etc.)
Other cooperating and/or supporting applications
SPECIFICDisplay Hardware &
Software
SPECIFICRadios, Networks &
software subsystems
Tight Coupling here is a barrier
to portability
Tight Coupling here is a barrier to portability
Tight Coupling here is a barrier
to portability
SPECIFICOperating System & Drivers
Tight Coupling here is a barrier to portability
Portable FACEApplication
PresentationConcerns
(Display H/W & S/W, headless transports, cursor devices, etc.)
Business Logic Concerns
(Many MIL-STDs, FMF, RNP/RNAV, Situational
Awareness, etc.)
I/O Concerns(Interface Cards, Radio ICDs, Networks, OFPs,
etc.)
Other cooperating and/or supporting applications
SPECIFICDisplay Hardware &
Software
SPECIFICRadios, Networks &
software subsystems
Tight Coupling here no longer impacts application portability
AdaptationLayer
AdaptationLayer
AdaptationLayer
SPECIFICOperating System & Drivers
No longer a barrier to portability due to selection of operating system standards being present at all computing environments
Immutable abstraction interfaces enable portability as tight coupling is moved out of the “application”
35 http://www.opengroup.org/face
Important Differences Between COE Domains • Competition must exist throughout layers and segments
of embedded systems • Defense embedded systems have stringent requirements
for Robustness, Security, and Determinism • Defense hardware must withstand extreme
environmental conditions – Results in a “disadvantaged” operating environment for software
• System life spans are many years – Architecture must support technology refresh
36 http://www.opengroup.org/face
• FACE is Future Airborne Capability Environment • FACE is an open COE enabling:
– Defense product line architectures
– A flexible and modular software architecture
• FACE includes: – Technical Standard and support documentation
• Reference Implementation Guide
• Verification Matrix
• Data Model
– Business Guide and support documentation • Contracting Guide
• Conformance Program
• Library Registry and Repositories for FACE-conformant products
The Solution: FACE
37 http://www.opengroup.org/face
Why FACE? Technical Benefits
• Reduces the time to field new capabilities • Provides for portability of software components across
embedded defense systems • Enables interoperable software components across multiple
operating environments • Reduces integration effort • Provides a software standard and reference architecture to
enable truly open software components in existing and future embedded systems
38 http://www.opengroup.org/face
FACE Architectural Segments
• 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
39 http://www.opengroup.org/face
FACE Consortium Publications
• FACE Business Guide – Version 1.1 published September 2011 and available at the
following link on The Open Group's Bookstore:
– http://www.opengroup.org/bookstore/catalog/g115.htm
• FACE Technical Standard – Edition 1.0 published January 2012 and available at the following
link on The Open Group's Bookstore:
– http://www.opengroup.org/bookstore/catalog/c122.htm
40 http://www.opengroup.org/face
• FACE enables getting capabilities to the Warfighter faster and at an affordable cost
• FACE is addressing the business concerns that have hampered other OA initiatives
• FACE has established a Common Operating Environment • FACE is being designed through industry and government
collaboration • FACE and its model for public-private partnership are
relevant to many domains – UCS, Army COE, others…
• FACE Standard is creating a new Defense marketplace for embedded software
Summary
41 http://www.opengroup.org/face
Questions?
Panel 3: Open Architecture Going DoD-Wide
#OA2012
Moderator: Nickolas Guertin, Director for Transformation, Deputy Assistant Secretary of the Navy for Research, Development, Test and Evaluation Speakers: Mr. Rich M. Ernst, Interoperability Lead, Office of the Secretary of Defense for Acquisition, Technology, and Logistics, Unmanned Warfare
Dan Gahafer, Forge.mil Program Manager, Defense Information Systems Agency (DISA)
Dr. Douglas C. Schmidt, Professor of Computer Science, Vanderbilt University
Robert Sweeney, Future Airborne Capability Environment Lead Engineer, Air Combat Electronics, PMA-209
Questions?
#OA2012
Panel 4: Perspectives from Industry
#OA2012
Moderator: Judy Cerenzia, Director, Collaboration Services, The Open Group Speakers: Patrick M. Antkowiak, Vice President and General Manager, Advanced Concepts & Technologies Division, Electronic Systems Sector, Northrop Grumman Corporation
Jamie G. Durbin, Technical Director, Product Line Architecture, Lockheed Martin
Gordon Hunt, Chief Applications Engineer, RTI
Thomas J. Laliberty, Director, Integrated Combat Systems, Raytheon Integrated Defense Systems
Affordability, Agility and Open Innovation
for AESA Systems
October 18, 2012
Pat Antkowiak Vice President and General Manager
Advanced Concepts and Technologies Division
So What’s the Big Deal with AESAs?
56 Proven and affordable AESA solutions
• Efficient effective radiated power generation
• Fast, inertialess, high-gain beam agility
• High reliability with graceful degradation
• Wider operating and instantaneous bandwidths
• Modular scalable architectures
• Reducing risks and costs
AESA Technology Trends
Scalable, Lower SWAP: Thin, Lightweight, Fewer parts, LRUs, LRMs, better power added efficiency
Multi-Function & Sensor Exploitation: Radar, Comms, Electronic Warfare, ISR, Passive Sensing, ATR, Data Fusion
More Bandwidth: wider operating and instantaneous bandwidth
Digital Beamforming: backend receiver and processor architecture evolution
More Open: Modular Open System Architectures allow for “best-of-breed” technologies
Rapidly Growing Capability
Lower Cost of Ownership
57
• Modular Open Systems Architectures (MOSA) penetrating DoD
• Software and hardware being driven to open standards and sourcing
• Major change in defense electronics business model
• Open innovation and an open business model are a “must”
Proprietary Front End Electronics
Proprietary Back End Processing
Users
Proprietary Interfaces
Proprietary SW OEM controlled
sourcing
Closed Networks
Proprietary Front End Electronics
Proprietary Back End Processing
Proprietary SW OEM controlled
sourcing
Proprietary Communication
Networks
Open Front End Electronics
Open Network
Open Scalable Back End Processing
Open Standard Interfaces
Open Source SW
Open Source HW
Modular / Open Systems – Transformation
Open Systems Architecture and Open Innovation … AESA Affordability for New Systems AND Legacy Platforms 58
A Shift Towards Capabilities Based Systems Development & OA/Open Innovation …
• Existing Capabilities and “Re-usable” Components … Producible, Open Innovation
• Modeling/Simulation Explore Mission Performance … Collaborative Development
• Cost and Risk Constrained … Requirements Iterated Around Constraints
59
•Capabilities
•Reusable Components
•Open Standards
•Component Test Plans
A Capabilities Based Approach
“Open” as A Foundation for Affordability
Open Architecture … Revolutionizing New and Legacy Platforms
“Open” as a Foundation
Open Architecture
Scalability Tech Insertion
for Affordability
Largest S-band Radar
G/ATOR
AMDR NEW
F-16 A-D/SABR
APG-81 Array, SABR REP integrated Flown on BAC1-11
+
F-35/APG-81
F-15 F-18
60
Leveraging Capability Investment
LEGA
CY
Open Architecture Applies to Both
Modular AESA Architectures – Open, Affordable and Revolutionizing
Bottom Line
• Proven and affordable AESA solutions
• Technology engine continuing to rapidly
evolve AESA radar capability
• Bringing open systems architecture back
to legacy platforms
61
Panel 4: Perspectives from Industry
#OA2012
Moderator: Judy Cerenzia, Director, Collaboration Services, The Open Group Speakers: Patrick M. Antkowiak, Vice President and General Manager, Advanced Concepts & Technologies Division, Electronic Systems Sector, Northrop Grumman Corporation
Jamie G. Durbin, Technical Director, Product Line Architecture, Lockheed Martin
Mr. Gordon Hunt, Chief Applications Engineer, RTI
Thomas J. Laliberty, Director, Integrated Combat Systems, Raytheon Integrated Defense Systems
The Benefits of Open Architecture: A
Practitioner’s View
Open Architecture Summit 18 October 2012
Jamie G. Durbin Technical Director, Navy OA Lockheed Martin MS2
- 65 - JGD Open Architecture Summit
AEGIS Open Architecture Evolution Phase 1: Commercial Technology…
• Commercial / Open Standards
• Commodity Products
• Separation of Application/ Infrastructure
• Planned Refresh Cycles
Focus: Leverage the Commercial Marketplace – Exploit Continuous Increases in Performance
• COTS Display and Network Distribution (B/L 6)
• Complete COTS Weapon System Infrastruct. (B/L 7)
• Through B/L 9: - 6th Generation Networks - 4th Generation Display/
Processors - 1st Generation Signal
Processing
Mid 1990s
- 66 - JGD Open Architecture Summit
AEGIS Open Architecture Evolution Phase 2: Componentized Software…
• Component-Based Designs
• Distributed Processing
• Message-Passing Architectures
• Modern Development Technologies
Focus: Decrease Development Time – Reduce Cost
Mid 2000s
• C2 Component Architecture (B/L 7)
• AEGIS Open Architecture Model-Based Design (B/L 8)
• Through B/L 9: • Merge of AAW and BMD
Baselines into Single Component Architecture
• Model-Based Architecture Document Describes Key Interfaces
- 67 - JGD Open Architecture Summit
AEGIS Open Architecture Evolution Phase 3: Open Business Model…
• Open Disclosure / Collaboration
• Peer Reviews and Independent Assessments
• Contract Guidebook
• SHARE / CAL Repositories
• Open System Management Plans
Focus: Increase Number of Players/Opportunities – Improve Transition of S&T Into Fleet
Today
• Established Technology Collaboration Centers
• Migrated Core Track Management using 3rd Party STM/TS (B/L 9)
• Through B/L 9: • Numerous 3rd Party
Developers (Commercial and Non-Commercial)
• Plethora of Licensed Products
- 68 - JGD Open Architecture Summit
Key Benefit of OA Approach REUSE within contractor configurations…
Common Development and Variation Techniques Enable Life Cycle / Total Ownership Cost Savings
Common Source Library
USS Bunker Hill CG-52
TI08/ ACB08 Code Base
Key Elements of Common Development:
• Single Set of Specifications • Common Program Plans • Single Set of Processes &
Metrics • Integrated Team Structure • Enterprise Products
LCS
CG
DDG
NSC
Aegis Ashore
Build Process
“Fix it Once”
• Open Standards-based Designs • Componentized Architecture • Well-Defined Interfaces • Clear Separation of Application
and Infrastructure
- 69 - JGD Open Architecture Summit
Key Benefit of OA Approach REUSE across multiple stakeholders, contracts, configurations…
Objective Architecture Provides “Architectural Context” for Product/Capability Development
• Consistent Domains / Boundaries
• Common Precepts and Methods
• Common Functional Allocation
• Common Data Model
• Core Common Components
- 70 - JGD Open Architecture Summit
Government / Industry Collaboration SBIR Example…
Combat System
Requirements
System Development
System Integration and
Test
System Certification and
Deployment
Need to Increase Integration of Collaboration/ Planning Between Development Communities
SBIR Phase I / Phase II
Existing Topics Existing
Topics Existing Topics
Existing Topics Existing
Topics New Topics
SBIR Pipeline
Technology/ Capability Roadmaps Architecture Models
Component-based Architectures Standards-based Designs Well-Defined Interfaces
Review / Prioritization of Topics Robust Competition for S&T
Contracts
Small Business Mentorship Technical Guidance During
Development
Combat System Development
S&T Development
Minimal Transition into FleetToday
- 71 - JGD Open Architecture Summit
Government / Industry Collaboration SBIR Example…
System Development
System Integration and
Test
System Certification and
Deployment
Combat System
Requirements
Collaborate Early and Often … from Gap Analysis Through Transition
SBIR Phase I / Phase II
Existing Topics Existing
Topics Existing Topics
Existing Topics Existing
Topics New Topics
SBIR Pipeline
Combat System Development
S&T Development
SBIR Tech Roadmap
Transition Plans
• Conduct Gap Analysis • Align Topics to Gaps • Propose New Topics • Assess Viability / Potential
• Establish Transition Tasks, Funding and Milestones
• Conduct Periodic Assessments of Maturity – Field When Ready
Joint Industry/ Gov’t Team
Panel 4: Perspectives from Industry
#OA2012
Moderator: Judy Cerenzia, Director, Collaboration Services, The Open Group Speakers: Patrick M. Antkowiak, Vice President and General Manager, Advanced Concepts & Technologies Division, Electronic Systems Sector, Northrop Grumman Corporation
Jamie G. Durbin, Technical Director, Product Line Architecture, Lockheed Martin
Mr. Gordon Hunt, Chief Applications Engineer, RTI
Thomas J. Laliberty, Director, Integrated Combat Systems, Raytheon Integrated Defense Systems
Copyright © 2012 Raytheon Company. All rights reserved Customer Success Is Our Mission is
a registered trademark of Raytheon Company. Statement A: Approved for Public Release; Distribution is unlimited.
Open Architecture Summit
Tom Laliberty Director, Integrated Combat Systems
18 October 2012
75
Engagement in OA Continuum
Standards – Open Architecture Computing Environment (OACE) – Joint Technical Architecture (JTA) – DoD Information Technology Standards and Profile Registry (DISR)
Assessments and Policy – Open Architecture Assessment Tool (OAAT) – Modular Open System Assessment (MOSA) – DoD Open Systems Architecture Contract Guidebook for Program Managers
Reuse and Architecture – Software Hardware Asset Reuse Enterprise (SHARE) Repository, Common Asset Library (CAL), Forge.mil – Tri-Program Initiative Surface Navy Standard Command & Control (SNSC2) – PEO IWS Product Line Architecture (PLA) – PLA Components: Common Display System, Common Processing System, System Track Manager/Track Server
76
Software Modularity through Variability Dimensions
PEO IWS Product Line Architecture supports Managed Variability
Variability Dimension
Description From the IWS Product Line Architecture ADD:
Mission Area Components include or exclude support for specific mission areas
Mission Capability Components include or exclude support for various capabilities within a mission area
Sensors and Weapons
Components include or exclude support for specific types of sensors/weapons
Foreign Military Sales (FMS)
Components replace sensitive algorithms with approved replacements for FMS
Restrictive Data Rights
Components enable late binding of code protected by restricted data rights
PEO IWS Product Line Architecture Managed Variability
77
Implementing Variability Dimensions & Maintaining Single/Common Source Library
SSDS implementation of Managed Variability and SSL/CSL
Six ship classes and 44 platforms
78
Perspective on Intellectual Property Need to balance the overall interests and preserve
incentives for non-Government investments and commercial market participation How to ensure the Government can establish competition for
interchangeable components and their support – Form, fit, function and interface data – Should not require detailed design or manufacturing process
Small business impact of use of any Government
development funding?
10/25/2012
Panel 4: Perspectives from Industry
#OA2012
Moderator: Judy Cerenzia, Director, Collaboration Services, The Open Group Speakers: Patrick M. Antkowiak, Vice President and General Manager, Advanced Concepts & Technologies Division, Electronic Systems Sector, Northrop Grumman Corporation
Jamie G. Durbin, Technical Director, Product Line Architecture, Lockheed Martin
Mr. Gordon Hunt, Chief Applications Engineer, RTI
Thomas J. Laliberty, Director, Integrated Combat Systems, Raytheon Integrated Defense Systems
Questions?
#OA2012
Thank you to our Sponsors!
#OA2012
See You Next Year!
#OA2012
Save the Date October 10, 2013
Grand Hyatt Washington Washington, DC