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 [email protected]
• Presenter 1 – Luke Brown, CAS Group, Chief Systems [email protected]
• Presenter 2 – Bill Parkins, Rockwell Collins, Chief Engineer
• Presenter 3 - Shaun Wilson, Shoal Engineering, [email protected]
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