first principles review (fpr)€¦ · airspace control air combat, isrew transportation and support...

First Principles Review (FPR)

Where to Now for SE?

An ASEW 2017 workshop – 30 October 2017

Hindsight vs Insight vs Foresight

3

Workshop participants

• Moderator – Kerry Lunney, Thales Australia, Country Engineering Director /

Candidate for INCOSE President kerry.lunney@thalesgroup.com.au

• Presenter 1 – Luke Brown, CAS Group, Chief Systems Engineerluke.brown2@defence.gov.au

• Presenter 2 – Bill Parkins, Rockwell Collins, Chief Engineer

bill.parkins@rockwellcollins.com

• Presenter 3 - Shaun Wilson, Shoal Engineering, CEOshaun.wilson@shoalgroup.com

4

Workshop cadence

1. Welcome and Introduction (10 mins)2. Luke Brown – Post FPR – Where do we all fit together! (7 mins)

Open floor to workshop (25 mins)3. Bill Parkins – What are the challenges to implement Joint Force Integration /

Interoperability? (7 mins)Open floor to workshop (25 mins)

4. Shaun Wilson – Digital transformation – The move to model-based design approaches (7 mins)Open floor to workshop (25 mins)

5. Additional questions/discussion – time to reflect (10 mins)6. Way Forward and Thank You (4 mins)

ReferenceFirst Principles Review – Creating One Defence

5

First Principles Review

What did it say?

• “Defence to focus on planning and governance, and

industry to focus on execution.”

• “The added value in utilising …Defence...personnel in

the acquisition and sustainment life cycle is their

expertise in the creation and management of

requirements.”

• The importance of “joint force integration,

interoperability and designing the future force.”

7

What does that mean for us?

• We need to examine and streamline the roles of Defence and industry in the

“value chain” of engineering, reducing overlap.

• We need to leverage advances in our profession to support efficiencies and

more complicated force integration.

8

For consideration …

What does “One Defence Business Model” mean to me?

End-to-end capability

Legacy systemsInterface definitions

Common Concept of Operations

Enabling systems

New RACI?

Adaption of Systems ThinkingDigital transformation –

solution and organisations

In-service support

Usefulness of MBSE

Governance – at which level

Adoption of new tools & methods

Framework tailoring

9

Where Do We All Fit Together?

Luke Brown, CAS Group, Chief Systems Engineer

So what actually is our job?

Luke BrownChief Engineer

What is our Role?

12

What is our Role?

Industry

CASG

ADF

13

Change the way we do things

The well-reviewed bolt

14

What is our role?

15

Where value is added

Usage and Intent

16

17

What are the Challenges in Implementing Joint Force

Integration / Interoperability?

Bill Parkins, Chief Engineer, Rockwell Collins Australia

Engineering challenges

• The Vice Chief of Defence Force will have the right to stop projects proceeding

through the approval process until joint force integration is proven. How can we

better support this? What outputs/evidence will be required?

• Defence is to establish enterprise-wide frameworks for architecture standards

and master data management. What is the expected flow down for acquisition

projects and in-service contracts? What framework will be used? If unique, will

it be shared?

19

Key focus areas

What does “One Defence Business Model” mean to me?

End-to-end capability

Legacy systemsInterface definitions

Common Concept of Operations

Enabling systems

New RACI?

Adaption of Systems ThinkingDigital transformation –

solution and organisations

In-service support

Usefulness of MBSE

Governance – at which level

Adoption of new tools & methods

Framework tailoring

20

Common ConOps challenges

• Navy interoperability (US/Other Coalition Joint Operations)C2, Command Support/ISREW, TF/TG CommunicationsAir & Undersea WarfareMaritime Support-Amphibious and Underway support

• Air Force interoperability (US/Other Coalition Joint Operations)Airspace ControlAir Combat, ISREWTransportation and Support

21

Common ConOps challenges

• Army interoperability (Tactical to Strategic and Joint Forces)Land Manoeuvre

Multi-role; Aviation, Combat Support, CSS, Engr, CommsShaping Operations

Amphibious and Special ForcesPersistent nodes to supplement shorter range bearers and provide re-transmission or data storage for push and pull access by land assets

• Australian Joint OperationsSovereign OperationsTraining for Joint OperationsDisaster RecoveryPeacekeeping/Regional Aid

22

Legacy systems

• Platform decisions create legacy challengesCost of developing new solutions compared with buying existingWhole of life cost for acquisition and sustainment is uncertain

Navy examples: Collins Class Submarine, FFG, ANZAC Ship, AWDAir Force examples: P-3C, C-130,Army examples: ARH, BCS-L, Joint examples: Satellite Communications, DHFCS, JORN, Simulators

• As an element of Sustainment of legacy/extant systems, need to define external

interfaces to the joint environmentThis additional scope could be progressed by system-of systems integrators working together with platform SPOs and PSIsNeeds to be recognised as a component of Engineering Support for the capability and funded accordingly

23

Interface definitions

• Standards?Subject to change (uncertain)Cost to implement changes to extant systems and equipment

May be prohibitive if systems are in use globallyExamples are waveform changes in radios

Flexibility limited and interoperability threatened

• Architectures?Need to be well understood early in capability definition phaseNeed flexibility to adapt to meet changing ADF force level capability priorities

24

Process improvement ideas

• Generate requirements for JFI from approved scenarios incorporated into the

architecture models at the Joint Force Level

• Create entities for extant systems as components of modelsInclude system managers as stakeholders in JF SOS model

• Provide simulation based evidence for verifying Joint Force Interoperability

requirementsDynamic verification modelling needed for this

• Architecture and Data Definitions to be commonly understood and used at all

levels

25

26

Digital Transformation –the Move to Model-based

Design Approaches

Shaun Wilson, Shoal Engineering, CEO

Design questions

• Why does it do it?goal and objectives => mission

• Who uses it? Who is impacted by it?organization elements and relationships

• Where is it used?locations, logical and / or physical

• When is it used?time, sequence, major events, cycles

• How is it used?processes and procedures, behavior

• What is in it & what does it do? • How is this achieved?

Problem Definition

OperationalAnalysis

“Black Box” context analysis

Solution Concept

Solution Design

28

From strategy to implementation

Operational SystemStrategic

29

Design cycle

Stak

eho

lder

nee

ds

Syst

em

fu

nct

ion

s

Alternatives analysis

& architecture

definition

Solution

iteration

Requirements

iteration

Verification & Validation

Technology review, Market surveys, Trade-off studies

Operational experience

Strategy

Solutionconcept

Cost, benefit & risk analysis

Solution build

30

Constraints

Verification

Standards

Trade Studies

MOEs COIs

Interfaces

Risks

Traceability

Validation

Architecture

DecisionsPerformance

ReviewsChange

Management

Needed Capabilities

Concepts and Specifications

Process Architecture

Complexity in relationships are often hiddenInconsistencies result in problems

Adapted from Vitech Corp. source

• Specifications

• Interface requirements

• System design

• Analysis & Trade-off

• Test plans

AirplaneATC Pilot

Request to proceed

Authorize

Power-up

Initiate power-up

Direct taxiway

Report Status

Executed cmds

Initiate Taxi

Future

Systems Engineering in transition

Reprinted from INCOSE Model-Based Systems Engineering Workshop, February 2010

Traditional

Moving from document-centric … to model-centric32

Government Policy

Strategy

Performers (organisations,

users, stakeholders)

Needs

Constraints(e.g. regulatory,

budget)

Functions

Concept of Operations

External systems

Interfaces

External systems

Requirements

Systems

A model

33

Model-based concepts

• The model is essential

(‘the single source of truth’)

• Choice of graphical language is less important (MBSE ≠ SysML)

• The model encompasses the system design and specification

• The model is provided to subsequent teams throughout the product lifecycle

• Design documents and specifications are generated from the model, complete

and consistent

34

Cost analysis models• Acquisition• Sustainment

High-performance computing• Optimisation• Search

Supply chaincapabilities

Capability parametric models• Range• Endurance• Persistence• Validation data• etc.

Studies & evaluations

Capability Design

Technical parametric models• Mass• Drag• Detectability• Power consumption• Validation data• etc.

Expert evaluation

Specialist reports(e.g. TRA spt)

Interfaces

Interfaces

Interfaces

Interfaces

Commonwealth document repository

(Objective)

Integrated Product Design Environment

Operational / capability model

System solution options model

35

Technical parametric studies

Operational Concept Document

Functional & Performance Specification

Test Concept Document

Technical Risk Assessment

Capability options analysis

Capability Needs Statement

Cost-benefit-risk analysis

Capability

Design

Knowledge

Model

Air space m anagement C2 - Scenar i.. .

Land C2 - Scenar io 2.. .Air Def ence C2 - Scena.. .

Mar iti me C2 - Scenar.. .

Sensor data and eff ect - Scenar.. .

Air space and Fi res SA - Scena.. .

S.2.ON.1

ADS - Scenar io 2 (G)

nil

S.2.ON.2

Air component -Scenar io 2 (G)

nil

S.2.ON.3

Air obj ect node -Scenar io 2 (G)

nil

S.2.ON.4

GBAMD - Scenar io2 (G)

nil

S.2.ON.5

JFECC - Scenar io 2(G)

nil

S.2.ON.6

Land com ponent -Scenar io 2 (G)

nil

S.2.ON.7

Mar iti me component- Scenar io 2 (G)

nil

Finished1.0

Conti nues0.0

Operat ion duration

S.4

GBAMD Scenari o4 - Popul ati on s.. .

GBAMD Capabil it.. .

AND

1

Perf orm higherC2 - Scenar io 2.. .

2

Shape - Scenar io2 (G)

3

Deploy - Scenar io2 (G)

4

Establi sh GBAMDin the AO - Sce.. . LP

5

Conduct GBAMDoperati on - Sce.. .

LE

OR LP

6

Wi thdraw -Scenar io 2 (G)

AND

S.1

GBAMD Scenari o1 - Defence of .. .

GBAMD Capabil it.. .HI WNGO(G)

HI OPORD(G)

GBAMDOPORD (G)

result s in r esult s in r esult s in r esult s in

basi s of basi s of

speci fi ed b y

basi s of basi s of basi s of

speci fi ed b y speci fi ed b y

basi s of basi s of basi s of

speci fi ed b y

basi s of

speci fi ed b y

5.3.1

Assess tasksuccess - Scena . ..

Op erat i onalA cti v. ..

Bat t le dam ageassessme nt (G)

Requ ir em ent

1.6

Assessef fect i veness (G)

Funct io n

1.6.1

Supp ort Bat tl eDam age Asses. ..

Funct io n

Syst emRequ ir em ent 17. ..

Requ ir em ent

Inf orm at ion f r omt ask success as. ..

Requ ir em ent

1.6

Assessef fect i veness (G)

Funct io n

2.1

Supp ort GBAM Dpl annin g (G)

Funct io n

Syst emRequ ir em ent 19. ..

Requ ir em ent

2.2

Supp ortcom ma nd an d c . ..

Funct io n

Syst emRequ ir em ent 20. ..

Requ ir em ent

Int erf ace to LandFor ce (G)

Requ ir em ent

1.1

M aint ain SA (G)

Funct io n

1.2

Sense obj ects (G)

Funct io n

4.4

Cont r ibu te t oLand For ce SA (G)

Funct io n

Syst emRequ ir em ent 33. ..

Requ ir em ent

St at us (G)

Requ ir em ent

1.6.2

Assess cu rr entcondi ti on (G)

Funct io n

Syst emRequ ir em ent 18. ..

Requ ir em ent

Through the Capability Life Cycle

Diagram courtesy DSTO

36

Program and Force level

• FPR states the importance of …

“joint force integration, interoperability and designing the future force.”

• How does a model-based approach support this?

• Can it be done without the use of models? (I don’t think so)

37

38

39

Applied to Surface Combatants

40

Thank You