Panel 3: Open Architecture Going DoD-Wide - Defense Daily · Professor of Computer Science, ... Air...

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


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

http://www.ucsarchitecture.org/

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.


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 Industry

Days


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

http://en.wikipedia.org/wiki/File:USMC_logo.svg

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


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?


#OA2012





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

mailto:[email protected]

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





Encapsulates & enhances native OS mechanisms to create reusable network programming components

Alignment between business incentives, technical maturity, & managers perceptions of risk prudence


When Has OSA Been Successful Thus Far?

Defines distributed programming components & APIs that automate & extend OS mechanisms









Defines reusable domain-independent services that simplify distributed computing







Domain-Specific Services

Domain-specific commonality

Tailored to requirements of specific warfighter domains, e.g., C4ISR, avionics, air defense, etc.







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



http://www.takeourword.com/images/persistence-of-memory.jpg

Contracting models that assume OSA requirements can be fully defined up front are expensive when inevitable changes occur



Quality-of-service (QoS) suffers when OSA initiatives use COTS products that are not suited for mission-critical DoD combat systems



Rigid adherence to ossified standards & reference architectures impedes OSA technology refresh & limits application capabilities



At the heart of these problems is the lack of an holistic approach that aligns & balances key business, management,

& technical drivers at scale



Joint Tactical Radio System (JTRS) is a poster child for lack of alignment between business, management, & technical drivers


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


#OA2012





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


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”


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


• 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


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


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


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

http://www.opengroup.org/bookstore/catalog/g115.htm

http://www.opengroup.org/bookstore/catalog/c122.htm


• 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


Questions?


#OA2012





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

http://images.google.com/imgres?imgurl=http://www.es.northropgrumman.com/solutions/vader/assets/vader.jpg&imgrefurl=http://www.es.northropgrumman.com/solutions/vader/&usg=__ltCQ6gUID3wqSLS0DAHOMyTSz-w=&h=188&w=250&sz=14&hl=en&start=1&um=1&itbs=1&tbnid=aMRgu8jaos5jaM:&tbnh=83&tbnw=111&prev=/images?q=vader+radar&um=1&hl=en&sa=N&tbs=isch:1



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


#OA2012



Mr. Gordon Hunt, Chief Applications Engineer, RTI


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


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


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


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


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


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


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


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


Topics Existing Topics


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


#OA2012





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


#OA2012





Questions?

#OA2012

Thank you to our Sponsors!

#OA2012

See You Next Year!

#OA2012

Save the Date October 10, 2013

Grand Hyatt Washington Washington, DC

Panel 3: Open Architecture Going DoD-Wide - Defense Daily · Professor of Computer Science, ... Air...

Documents

Transcript of Panel 3: Open Architecture Going DoD-Wide - Defense Daily · Professor of Computer Science, ... Air...