Surface Navy Combat Systems Engineering Strategy

Surface Navy Combat Systems Engineering Strategy

Kathy Emery, Chief ArchitectPEO Integrated Warfare Systems

4 March 2010

2

Open Architecture (OA) is a key enabler for meeting the CNO’s objectives

Naval OA is amulti-faceted business and

technical strategy for acquiring and maintaining National Security Systems

(NSS) as interoperable systems that adopt and

exploit open-system design principles and architectures

Modular design and design disclosure

Reusable application software

Interoperable joint warfighting applications and secure information exchange

Life cycle affordability

Increased competition and collaboration

NAVAL OA CORE PRINCIPLES

3

Implementation of OA across the enterprise will yield many benefits

Reduction in Time to Field

Increased Performance

Improved Interoperability

Reduction in Risk

Cost Avoidance

Decreased development and acquisition cycle times to field new warfighting capabilities

Faster integration of open standards based systems

Improved operator performance thru delivery of cutting edge technologies and increased bandwidth capabilities from spiral developments and technology insertions

Use of common services (e.g. common time reference) Use of common warfighting applications (e.g. track mgr) Use of published interfaces to standardize collaboration

Leverage proven reusable components Test early and often in the developmental cycle to

minimize risk of delivering non-interoperable products

Cost avoidance from software re-use and use commodity COTS products at optimum prices

Reduced training and streamlined lifecycle support

4

System Integrationand Test

FleetFleet

PEO SHIPS/CARRIERS/

Int’l CustomersJFCOMNNWC

OPNAV

DASN

ONR

International

Platform Specific

Top Level Acquisition Process ViewProduct

Development

Directorate Level

ComponentRequirements

Definition

Product Line Engineering

PEO IWS Level

Combat / Warfare System

Integration

SystemTest &

Evaluation

Certification

Installation

ILS &Training

ComponentDevelopment

ComponentTest

CapabilityIntegration

CapabilityTest

Readiness Assessment

Requirements Analysis

Product LineArchitecture/

Interface Mgmt

Modeling and Simulation

Science and Technology

FMS Management

Integrated Warfare Systems

& Capabilities

Capabilities

Requirements|Interfaces

Technology

CVN

AegisDDG

AegisCG

DDG1000

LCS

AMPHIB

FMS

RequirementsMission Archs

FundingRegulations

PoliciesComponent

RequirementsDefinition


ComponentTest


CapabilityTest

ComponentRequirements

Definition


ComponentTest


CapabilityTest

5

PEO IWS Organization

6

Implementing Open Architecture:Strategy, Interfaces and Open Standards

Treat computing environment as a commodity – Select commercial mainstream COTS products

that conform to well-established open system interface standards

– Bundle specific COTS products for a given timeframe and revisit selections on a regular basis

Isolate applications from high rate-of-change COTS through selection of standard APIs– Upgrade H/W and S/W Independently and

on different refresh intervals

Transform application development from single-platform development to multi-platform portfolio– Objective architecture defines key interfaces that

support extensibility and reuse goals based on common data model

– Eliminate redundant software development efforts

Commercial Products

“Build Once”

Hardware

Operating System

Middleware

Hardware

Operating System

Middleware

Applications

Display

Track Mgmt Command

&Control

SensorMgmt

WeaponMgmt

VehicleControl

7

Information Architecture

Transport Services

Data-Oriented API (Publish/Subscribe Model)

Component

Attributes

Services

Component

Attributes

Services

Component

Attributes

Services

Component

Attributes

Services

• Define a common data model and information standard• Component-to-network interfaces, not component-to-component• Component interfaces are coordinated* and authenticated**• Expose information and post for any authorized subscriber to access• Producers of information don’t have to be aware of consumers

Information-Oriented Architecture Is Key toDefining Reusable, Extensible Components

*Coordinated = fully-specified IDD, Gov’t CM via ICWG**Authenticated = interface compliance test before acceptance

Presenter

Presentation Notes

The key architectural precept is the concept of an information-oriented architecture. Components will use publish/subscribe messaging services to produce and consume data that is defined in a common data model. This allows components to be easily added or removed from a configuration. PEO IWS will control changes to the data model and the allocation of responsibility for publishing data to specific components. When common components are delivered, we will authenticate their implementations of those interfaces and provide a pedigree to subsequent reusers.

8

ECDIS-N

Common Core Software• Sensor Management (local)• Track Management (Common Tactical Picture)• Combat & Control (incl. Tactical Mission planning)• Weapon Management• Vehicle Control (air, surface, underwater)• Display / User Interface

Radar

IFF

ES

EO/IR

NCTR

Acoustic

Decoys

Torpedoes

Guns

EA

TDL

CDL-N

ADNS

METOC

NavSensors

ControlledVehicles

Computing Equipment(processors, displays, networks, storage, physical interfaces)

Infrastructure Services

Computing Environment*

DDS

SensorsWeapons

External Comms

Nav DataFusion System

Navigation

Air TrafficControl

JTT

Launchers

* Computing environment could becombat system specific or total ship

C2/ISR

Planning

JPALS

TTWCS

(Air, surface,

underwater)

AIS

Missiles

LogisticsSystems

Total ShipTraining System

Support

CombatSystem Trainer

NavTrainer

Aviation Trainers

C2Trainers

CombatSystem

Readiness

IWSAIRC4I

Color Coding

GPSTime Wind

Surface Combat System Network-Based Architecture

Presenter

Presentation Notes

Figure 3 – Combat System Key Interfaces and Organizational Responsibilities

9

Transitioning to Objective Architecture Based Combat System

Required warfighting capabilities determine components modified

10

B/L 1/2/3/4/5DDG 51-78 CG 47-73

B/L 6 Ph I/IIIDDG 79-90CG 66 & 69

B/L 7 Ph IDDG 91-112

1980 1994 2002Year

ACB 08/TI 08Advanced Capability

Build (ACB) Technology Insertion (TI)

2009

Mixed COTS and MILSpec Design

Mission Critical Enclosure (MCE)

All COTS computers

UYK-43UYK-44

UYK-43/44+Adjunct COTS

COTSSMP’s

Processors COTSBlades

MIL Spec Design(MCE)

A Scaleable Pool of Interchangeable

Processors

Displays UYH-4 UYQ-21 (TGC) UYQ-21/UYQ-70 Thin Client

Displays

Aegis Weapon System Hardware Architecture Roadmap

Weapon System

UYK-7UYK-20

2012 2016

COTSBlades

Common ProcessingSystem (CPS) & MCEA Scaleable Pool of

Interchangeable Processors

COTSTBD

ACB 16/TI 16

Connectivity All NTDSAll Network

Pub Sub

Pre-Aegis

1960

MIL Spec Design

UYH-4

UYK-7

Thin Client Displays

NormalizedEquivalentCapability

2 UYK-43 120 UYK-43

ACB 12/TI 12

Point-to-Point Point-to-PointAll Network

Pub Sub

TBD

Point-to-Point

Common Display Systems (CDS)

CPSCPS

Common ProcessingSystem (CPS) & MCEA Scaleable Pool of

Interchangeable Processors

4 UYK-43 270 UYK-43 875 UYK-43 ~2500 UYK-43

Increased computing power and network-based performance will enable significant combat system warfighting improvements

11

Evolution of Open Architecture

I II III IVCharacteristics:

Key EngineeringActivities:

Benefits/Evidence:

COTS Infrastructure Component-BasedSoftware

Open BusinessModel

Common CoreArchitecture

• Separation of Application/ Infrastructure

• Commercial Standards• Commodity Products

• COTS Performance Characterization

• Prototypes / EDMs• Planned Refresh

Cycles

Increased Performance / Bandwidth

Reduced Cost

• Component-Based Designs

• NetworkedApplications• Configurable Test

Environments

• Multi-Level Test and Evaluation

• KPP Validation• Increased Reuse

Decreased Dev Time Improved Testability Reduced Cost (Reuse) Scalability, Extensibility,

Testability, …

• Open Business Practices• Rapid Transition of New

Capabilities to Systems• Open Disclosure / Data

Rights

• 3rd Party Developers• Peer Reviews and

Independent Assess• Mentoring• Fleet Involvement

o Increased Number of Vendors/Opportunities

o Improved Transition of S&T to Fleet

• Common Objective Architecture / Interfaces

• Common Components, Frameworks, Services

• Common Precepts/ Patterns/Standards

• Align Existing Arch / Roadmaps

• Establish/Publish “Objective Arch”

• Establish/Publish Common Data Model

o Improved Interoperability

o Cost Avoidanceo Reduced

Training/Support

We are now focused here

Presenter

Presentation Notes

Open architecture started out focused on modernization and new construction combat systems – technical issues: COTS-based processors, network interfaces, modularized, documented interfaces We achieved the benefits shown in terms of extensibility and performance by getting out of militarized environment But now we are focused on changing the business model to allow more participation / innovation / cost containment pressure We are also focused on commonality – hence “objective architecture” in order to get additional benefits shown Objective architecture assumes we have open architecture baselines and now we are moving to common implementations of core capabilities Components designed for reuse (not opportunistic) We aren’t going to spend money to develop a common combat system or a common CMS core We are going to use opportunities where we are making significant warfighting improvements to design and build them in a common way – build once, integrate many times Gradually, our combat systems will evolve to a common core – we won’t end up with completely common C.S., as each ship class has unique missions that drive differences in configurations, but the core software should become a single software product line over time – we can select components and tailor them to specific ship class needs

12

PEO IWS Responsible for AchievingOA Objectives for Combat Systems

Coordinate architecture and overarching interface principles for developing combat systems

Oversee design, construction and maintenance of all ship combat systems

Coordinate combat system acquisition programs across PEOs

Leverage combat system software components across programs

“We must change from an approach that is optimized by program and platform to one that can solve the challenges of integrated systems that cross many platforms and functions…”

– ASN(RDA) MSG DTG 112123ZOCT02

We are transforming to a product line acquisition approach

13

Surface Combat System Top Level Objective Architecture

Platform Adaptation

Common Core

External CommunicationsDomain

Sensor Mgmt Domain

DisplayDomain

Vehicle ControlDomain

Weapon MgmtDomain

Support Domain

Track Mgmt Domain Combat ControlDomain

CommsDomainManager

TrainingDev EnvTraining

Dev EnvCommonGUIs

WeaponDomainManager

Link 16S TDL J

JRELink 11Link 22

WeaponsMK 41 VLSMK 57 VLS

MK 29 GMLSRAM GMLS

SeaRAMMK 160 AGS

MK 160 GFCSCIGSCIWS

TTWCSHarpoon

MK 36 DLSNulka

SLQ-32 EAOTSTATT

NIXIENLOS

VehiclesFixed Wing

MH-60RSmall Boats

UAVUUVUSV

ShipResourceManager

System TrackManager

Track Server

TacticalMissionPlanning

Combat ID

Multi-Source

Integrator

GeodeticRegistration

TacticalDecide &Assess

SensorControlSensor

ControlMissileController

Link DataManager

(one per missile)

CC SupportServices

TacticalDecisionSupport

InfrastructureDomain

EngagementScheduler

IAMDCoordinator

USWCoordinator

StrikeCoordinator

SUWCoordinator

SensorControlSensor

ControlWeaponController

(one per weapon)

DDS

SIPRNETNIPRNET

MissilesSM-2SM-3SM-6ESSMRAM

ASROC

VehicleDomainManager

AssetControllerVehicle

Controller

JTT / IBS

ConsolesComputing Equipment Domain Displays Cabinets Processors

TDL InterfaceController

DDS InterfaceController

SATCOMRouter

IBS InterfaceController

VehicleCoordinator

CDL InterfaceControllerCDL-N

Storage Networks

TrainingDev Env

ScenarioController

PlanningCore

After ActionReviewer

PerformanceAnalyzer

ComputerBased

Training

ReadinessAssessment

DataReduction

CombatSystemTrainer

ASWTrainer

KnowledgeManager

ShipControlTrainer

EWTrainer

DataCollector

AssetController

Launch/RecoveryModuleVehicle

SensorCoordinator

VehicleWeapon

Coordinator

VehicleComms

Coordinator

SensorControlSensor

ControlSensorController

(one per sensor)

SensorTracker

CompositeTracker

Nav SystemSimulator

SensorSim/StimSensor

Sim/StimSensor

Simulator/Stimulator

WeaponSimulatorWeapon

SimulatorWeaponSimulator

WeaponSimulatorWeapon

SimulatorExt. CommsSimulator

SensorDomainManager

Above WaterSensor

Coordinator

Below WaterSensor

Coordinator

ComputingResource

Mgmt

Nav, Position & Time

DataMediationServices

C.S. LANMgmt

DataExtraction /Recording

DistributedObjects

MessagingServices

DataMgmt

C.S Security/Info Assur.

ExternalComms

Coordinator

Operational Command & ControlGCCS, NECC, NCCT

VehicleScheduler

NavigationDomain

GPSInertial / Gyro

Water Speed LogDepth Sounder

Magnetic CompassMETOC Sensors

AIS

NavigationData Fuser

Bridge System

Ship Movement

Coordinator

Chart Server

ECDIS-N

Bridge Interface

Controller

TrainingDomain

LogisticsSupport

ComputingEnvironment

C.S.NetworkSecurity

C.S.InteriorComms

SOA CoreServices

ComponentFramework

TACSIT Display

Collabora-tion Mgmt

GUI Display

Operator Task Mgmt

Audio/ Video

Support

Remote Display

Controller

Display Renderer

Platform Specific

GUIs

Platform Specific Display Apps

Common Display Apps

SPY-1DBR

AMDRSPQ-9BSPS-49ASPS-48ESPS-67SPS-73SPS-74UPX-29UPX-37CIWSMK 9

SLQ-32EDO ESM

SEWIPEO/IRFLIR

MH-60RTowed Sonar

Hull Sonar

Presenter

Presentation Notes

How will we control our own architecture? We will publish an architecture description document (ADD) that describes the architecture and will maintain a Government-controlled architectural model that defines all components and component interfaces down to the level where component compliance can be authenticated. The Government will compete development of new or upgraded capabilities and require those delivered capabilities to align to the objective architecture. The architecture and interface standards will be open and available to all who desire to compete. Government controls the architecture as well as the common components in the product line portfolio.

14

Navy Technical Reference Model

Application Services

Common Computing Environment

Communications & Networks

Common Services

WANs

SATCOM

LANs

Wireless

Network/ Circuit Mgmt

Security

Computing Hardware

SOA Core Services(Tactical Edge)

Enterprise Services

Support Systems

Aviation Systems

ISR

Command & Control

Combat Systems

Platform Training

Hosting Environment

Basic Services

Ship Control

User GroupsCOICOICOICOI COI

15

Notional Joint UAS Control Segment Software Framework

Geodetic

Blue Force Tracker

Weather

Audio Comm

ExploitProduct

Find, Fix, Target

Link 16

Media Recording

Navigation

EnvironmentFeedback

Collection Planning

Route Planning

Track Storage

Task Planning

Track CorrelationTask

Processing

Tactical Msging

Threat

Chat

Product Output

Collaboration

System Access, Info

Ass

Network Mgt

Display Mgt

Sys Health, Maint.Training

Supporting Services

Vehicle Status

PLD Status

Comm Link Mgt

Integrated App

Integrated App

Integrated App

DisplayLocalHCI

PLD Control

Weapon Control

Vehicle Control

Weapon Status

Handover

Auto T-O/L Mission Control Services Bus

UA Control Services

COM

M L

ink

to U

AV

Supporting Services Bus

Loca

l

Integrated App

Integrated App

Integrated App

Display HCIDistributed

GIG

GIG

GIG

Loca

l G

IG

Local

Local

AIS

Sense & Avoid

Comm Link Mgt

Find, Fix, Target

Navigation ATC

Payload Control Services

Weapons Control Services

Planning Services

Content Management Services

Combat System Focus C4I Focus

Presenter

Presentation Notes

This is an operational example of the capability improvements achieved once CS and C2 applications can freely interoperate. Combat system vehicle control application focus on directing aircraft to fly to a specific location and perform a specific mission (surveillance, engagement). Mission plans and Air Tasking Orders/Air Control Orders (ATOs/ACOs) are generated in C2 applications. These are currently handled in paper form and key information is manually entered by combat system operators into combat system databases. Mission plans/replans can be generated more rapidly on the C2 side when current vehicle status is available to the planners. Targeting decisions on C2 side can be more rapidly implemented on CS side because plans and orders are received, processed and viewed digitally.

16

Today’s Shipboard Environment(Direct interfaces, unique solutions, weak cross-domain integration)

MIDS MOS

URC-141NMT SMQ-11

CDL-SAN/USQ-167

RCSTurnkey

RFRF RFRF HSFBSSR-1

RF HFRGURC-131

RF DMRSRC-61

RF MUOSTerminal

RF

ARC-210RF JTT-M

USQ-151

RF SSES/SCI COMMS

RF GBSUSR-10

RF TV-DTSOE-556U

RF

MCCP

BFTTUSQ-T46

CDLMSUYQ-86

TVSUSQ-155

ARC IIIUSQ-162 27TV

6TV

14TVDBR

EWS

CEC

TISS **

CV-TSCSSQ-34C

RAM MK31

CIWS MK15 MOD21&22

GMLS MK29

RF

RF

RLGNWSN-7

AIAS

FathometerUQN-4A

DSVLWQN-2

IBS (SCC)

SPS-73Lite

RF

RF

IFLOLS

ACLSSPN-46

LSODS

ILSSPN-41

ILARTS

MWS

CATCC/DAIR

TPX-42A

LRLS

MOVLAS

SEA BASED JPALS

AAG EMALS

VTS

TACANURN-25

RF

RFRF

SATCC

AnnouncingMC

PPLAN

JSLSCAD

JBPDS

IPDS MK26MD0

JCAD

PDR-65ARADIAC

CANES(Unclassified)

NTCSSBK2

TMIP-M

BFEM

IA

AIS(URN-31)

MCMS

ADNSUSQ-144

TCSUSQ-171

GCCS-MGenser

NITESUMK-4(V)(Genser)

DCGS-N(Genser)

JMPS

IA

TBMCS

JWARN

NAVSSI Bk 4.X

GCCS-MSCI

Radiant Mercury

SSEE INC (X)

DCRS

UASS UMQ-12

CANESCoalition

MFRRADIAC

SVDSSXQ-10B

CANES(Genser)

TC2S

RF

Gertrude WQC-2A

RF

GPS

DMSProxy

DMSProxy

Non-Warfare SystemsInternal WS Interfaces

External WS Interfaces

RF

DAS IRST **

SSTDSLQ-25A

CANES(SCI)

NITESUMK-4(V)(Unclass)

JSF ALIS

AIMS MK XIIUPX-29

RF

TCSUSQ-171

MLAN

DCGS-NSCI

DMRT **

Space & Weight**

RF

ADMACSBK III

NN

Network Distribution Bus

SSDS MK2

RF

RF

RF

TCSUSQ-171

NAVAIR

PEO IWS

NAVSEA

PEO C4I

17

AISVTS

SPS-73

RLGN

NAVSSI

AIAS

IBSDSVL

Fathometer

NAV

Nav and HM&ESystems

AAG EMALS

DMRT

CATCC

DAIR

IFLOLS

LSODS

ILSILARTS

MWS

TACAN JPALS

ACLS

MOVLASLRLS ADMACSBlk III

Aviation Systems

PLATFORM

Interface Control

Network Management

ShipNetwork

CEC

IRST CV-TSC

TISS

DBR

CIWS

IFF

SSTD

SSDS

Tactical Systems

SGS/AC

EWS

GMLS

RAM

CST

SSES/SCI COMMSMUOSMIDS CDL-S NMTGertrude MCCPJTT-M SMQ-11

RCSTurnkey

CDLMSTV-DTSGBS TVSDMRHFRGARC

IIIHSFBARC

210

ADNS

External Comms Systems

Functional Enclave

Functional Enclave

Functional Enclave

Func

tiona

l Enc

lave

Func

tiona

l Enc

lave

JMPS

CANESCoalition

DMSProxy

GCCS-M

UASS

DCGS-N

NITES

TCS JWARN

TBMCS

DCRS

IA

DMSProxy

MLAN

NITES

TCSTMIP-M

NTCSS

BFEM

IA

CANES(Unclassified)

C4I Systems

GCCS-MSCI

DCGS-NSCI

SSEEINC

TC2S

JSF ALIS

CANES(Genser)

Radiant Mercury

CANES(SCI)

Desired Shipboard Environment(Networked interfaces, common/interoperable solutions,

significant cross-domain integration)

18

• Infrastructure

• Display

• Sensor Management

• Track Management

• Combat Control

• Weapon Management

• Vehicle Control

• External Comms Mgmt

• Navigation

• Training

• Support

Combat System

Domain Boundary

DDS, CDL-N, TDLs, JTT/IBS

C4I Network & Services• Afloat internal ship networks

• Afloat Core Services

C4I External Communications

• WAN gateway

• SATCOM

• LOS communications

C4I Applications• GCCS-M

• DGCS-N

NOC

Ashore

• DISN• NIPRnet

SIPRnet• NMCI• Allied

networks

Direct and LOS• HF Internet Protocol

• Digital Multichannel Radio

• Milstar terminal-to-terminal

Dom

ain

Bou

ndar

y

Dom

ain

Bou

ndar

yUnclass

GENSER

Domain Boundary

Dom

ain

Bou

ndar

y

CANES Services supports CS data exchange with C2 Applications (whether onboard and offboard)

Information Assurance is a Significant Hurtle to Resolve:PEO IWS and C4I will coordinate inputs to consolidated C&A activity

SWTRG-Defined Baselines / Platform IT

CORB-DefinedBaselines / Full IA

Dom

ain

Bou

ndar

y

19

Common Component Requirements Flow from Combat System Requirements – PSEAs Involved

SOFTWARE ELEMENTREQUIREMENTS DEFINITION

(B5 SPEC / IDS)

SUBSYSTEMREQUIREMENTS DEFINITION

(B1 / B2 SPEC)

SYSTEMREQUIREMENTS DEFINITION

(A SPEC / SSS / TPMs)

SYSTEM DEFINITIONAND DESIGN

SYSTEM & SUBSYSTEMDEFINITION AND DESIGN

SOFTWAREIMPLEMENTATION

SUBSYSTEMTESTING SYSTEM INTEGRATION

PRODUCTBASELINE

OPERATIONAL TESTS(DT&E / OT&E)

NAVY COMBAT SYSTEM TEST(SIT / DT)(Level 5)

SYSTEM TEST & EVALUATION,MULTI-ELEMENT INTEGRATION

& TEST (MEIT) (Level 4/5)

ENGINEERING TEST &EVALUATION (ET&E)

(Level 3)

ELEMENTINTEGRATION & TEST

(Level 2)

SOFTWARE COMPONENTUNIT AND COMPONENT TEST

(Level 1)

CODE

SOFTWAREDETAILED DESIGN

(Design Model)

COMPONENT SOFTWAREREQUIREMENTS DEFINITION

(B5 SPEC / SRS / IDS)

OPERATIONAL / CAPABILITYREQUIREMENTS DEFINITION

(TLR / CDD / NCD / KPPs)

ALLOCATEDBASELINE

FUNCTIONALBASELINE

CodeReviews

DesignReviews

SDR

SSR

SYSPDR

SRR

TRR

SoftwareComponentDevelopers

PSEAs

SYSCDR

20

Process Definitions Needed for Each Phase fromStrategic Planning to Delivery / Sustainment


(B5 SPEC / IDS)


(B1 / B2 SPEC)



SYSTEM DEFINITIONAND DESIGN

SYSTEM & SUBSYSTEMDEFINITION AND DESIGN

SOFTWAREIMPLEMENTATION

SUBSYSTEMTESTING SYSTEM INTEGRATION

PRODUCTBASELINE

OPERATIONAL TESTS(DT&E / OT&E)

NAVY COMBAT SYSTEM TEST(SIT / DT)(Level 5)

SYSTEM TEST & EVALUATION,MULTI-ELEMENT INTEGRATION

& TEST (MEIT) (Level 4/5)

ENGINEERING TEST &EVALUATION (ET&E)

(Level 3)

ELEMENTINTEGRATION & TEST

(Level 2)


(Level 1)

CODE


(Design Model)


(B5 SPEC / SRS / IDS)

OPERATIONAL / CAPABILITYREQUIREMENTS DEFINITION

(TLR / CDD / NCD / KPPs)

ALLOCATEDBASELINE

FUNCTIONALBASELINE

CodeReviews

DesignReviews

SDR

SSR

SYSPDR

SRR

TRR

SYSCDR


(B5 SPEC / IDS)


(B1 / B2 SPEC)




(B5 SPEC / IDS)


(B1 / B2 SPEC)




(Level 1)

CODE


(Design Model)


(B5 SPEC / SRS / IDS)SSR

SWPDR

SWIBR


(B5 SPEC / IDS)


(B1 / B2 SPEC)




(B5 SPEC / IDS)


(B1 / B2 SPEC)




(Level 1)

CODE


(Design Model)


(B5 SPEC / SRS / IDS)SSR

SWPDR

SWIBRFeeder Program /

Common AssetDevelopment

CombatSystem

T&E / Cert

Integ. FieldingSchedules

ShipIntegration

Readiness/Perf. Asmnt

FleetOutreach

Int. ProductRoadmaps

EnterpriseCCP

S&TManagement

ACBDefinitions

Strategic PlanningMissionAnalysis

IntegratedPOM Planning

Delivery & Sustainment

ACBExecution /

CombatSystem

Integration

SE CONOPS

Presenter

Presentation Notes

PSEAs are involved in defining requirements for common components – multiple PSEAs to a common developer – requirements have to be reconciled PSEAs still responsible for end-to-end requirements and integration/performance. They may also be developers, but intent is to introduce more 3rd party developers and not as subcontractors.

21

Combat System Objective Architecture Component and Interface Definition

AMOD

DDG 1000 DDG 1000

Aegis

SSDS SSDS

A component is a bounded module with:• Associated requirements (in DOORS)• Design description• Defined Interface (modeled in UML)

Common Assets Library (CAL)

• Defined superset component requirements• Establish interfaces IAW objective architecture• Develop/deliver authenticated components

Available forfielding in CG(X) and backfit in 2014 & beyond

Legacy Components

Objective ArchitectureComponent Development

3rd Party Development S&T Rapid Development

RCIP

Presenter

Presentation Notes

Dynamic Object Oriented Requirements System (DOORS) Unified Modeling Language (UML) Componetized software will be available for forward fit into new construction and back-fit into in-service ships where appropriate Common architecture promotes software reuse, reduced testing, fewer baselines, and affordability CG(X) will be created from a mix of existing and newly developed components taken from a Common Asset Library (CAL) The CAL is a library of objective architecture compliant common software components that can be integrated with other components to create Advanced Capability Builds (ACBs). Common assets maintained for each component will include development artifacts such as requirements and design documentation, models, test procedures, and test results.

22

Carriers

AmphibDDG-1000

Destroyers

Cruisers

PEO IWS Product Line Approachfor Surface Combat Systems

Common Asset Library (CAL)

Aegis Development DDG-1000Development

CVN / AmphibDevelopment

3rd PartyDevelopment



Based on a common architecture, with- Common data standards and APIs- Common services APIs- Reusable software components (core assets)

Artifacts include:- Requirements (functional, performance, interface, design)- Design models, engineering studies and papers- Source code, compile and build scripts, configuration files- Test plans, procedures, harnesses, execution results, metrics

Presenter

Presentation Notes

PEO IWS will maintain a CAL – note it isn’t just source code – it is all artifacts needed to develop, test, reuse requirements, design, code. PSEAs will draw from the CAL those GFE components that are applicable.

23

Common allocations and interfaces allow components to be reused across Combat Systems– Reuse reduces integration and test costs for new development– Improves interoperability and eases operator cross-decking

Componentization localizes changes– Reduces Test / Cert costs for subsequent upgrades for component level

changes S&T and new developers know how and where their products can fit in

– Improved transition of new technology into Programs-of-Record Extensible to accommodate upcoming new warfighting capabilities:

Benefits of Componentized Objective Architecture

- Threat-D- MH-60R Integration- Netted Surface Tracking- Ship Protection Systems- Improved Surface and

Underwater Pictures

- Net-centric Services- Joint IFC / DWC- Hardkill / Softkill

Coordination- Common Air Control- Fleet Synthetic Training

- Distance Support- Maintenance Free

Operating Periods- Optimized Manning

Initiatives

Presenter

Presentation Notes

Commonality costs more up front, but expect savings from reduced integration and test, and subsequent upgrades. Items in blue are new capabilities we want to implement in multiple combat systems. As we get greater commonality, our ability to build once, integrate multiple times goes up. Having a stable architecture also allows S&T community to preposition their technology to land in the C.S.

24

Programmatic

Acquisition

• Funding• Schedule/Milestones• People• Requirements• Platform Obligations• Warfighting Commitments

• Number/Types of Participants• Contracting Approaches• Peer Review Processes• Roles and Responsibilities• Incentivizing “Enterprise”

Behavior

Acquisition Precepts• Open Business Model• Data Rights and OA incentives• 3rd party development of

components and capabilities• Platform System Engineering

Agents (PSEAs) for end-to-end C.S. engineering

• Competition at all levels

Technical Precepts•Architecture

• Component Based• Common Data Model• Network-based interfaces• Common framework for reqmts allocation

•Design for reuse / extensibility•Extensive use of M&S and automated code, documentation and test tools & techniques

Programmatic Precepts•Spiral evolution process

• Bi-annual Advanced Capability Builds (ACBs)

•Decouple new capability development from ACB dates

•Rapid transformation to common core software

•Rapid Capability InsertionProcess (RCIP) development

•Integrated POM Inputs andprogram roadmaps

•Product Line Tasking & Funding to field activities

Technical• Architecture Precepts• Objective Architecture• Component Boundaries• Key Interfaces• Open Standards

• IWS Systems Engineering Board• Cross-Program Coordination• Approval and Decision Process

• Architecture and Interface Control• Enterprise Configuration Management• Open Peer Review Process• Common Asset Mgmt & Reuse Library• Facilitate Information Transfer• S&T Roadmaps and Transition Plans• Org. Roles and Responsibilities

Governance (Formalized)

Product Line Approach Way Ahead Perspectives

Arch. Description Doc. (ADD) V1.0

July 2009 Acq Mgmt Plan (AMP) V1.0Dec 2009

Sys Engr Mgmt Concept of Ops

April 2010

Presenter

Presentation Notes

We are paving new ground on multiple fronts: Technical – defining architecture, data models, using model-based development Programmatic – defining ACB and TI processes, RCIP, product line roadmaps (putting the “I” in IWS) Acquisition – competition plans, data rights, separation of component/capability developers from PSEAs Governance ties it all together – requirements/budgeting, configuration management, CAL and SHARE We have or are documenting processes and architecture in the above documents.

25

Business Characteristics of OA

OPEN BUSINESS MODEL CHARACTERISTICS OPEN SYSTEM MODEL CHARACTERISTICS

OA language in contracts

Appropriate Data Rights

Design artifacts disclosed

Design artifacts published in repositories

Collaboration / Peer Reviews

Continuous competition

Rapid capability insertion process (RCIP)

Fleet involvement

Modular architecture

Widely accepted/supported standards

Use of commodity COTS

Published Interfaces

Isolated proprietary components

26

PEO IWS System Engineering Guidance

April 2010

Executive plan to build and maintain Open Architecture Combat SystemsProvides objectives for stake holder alignment

Describes software architecture for combat system product line withfocus on Combat Management software

Product line systems engineering processes

Process for planning and specifying combat system upgrades for bi-annual Advanced Capability Builds

Integrated configuration management of overall portfolio of C S d t

Documents

Surface Navy Combat Systems Engineering Strategy