First Principles Review (FPR) Where to Now for SE?

Transcription

1

2 First Principles Review (FPR) Where to Now for SE? An ASEW 2017 workshop 30 October 2017

3 Hindsight vs Insight vs Foresight 3

4 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 Engineer luke.brown2@defence.gov.au Presenter 2 Bill Parkins, Rockwell Collins, Chief Engineer bill.parkins@rockwellcollins.com Presenter 3 - Shaun Wilson, Shoal Engineering, CEO shaun.wilson@shoalgroup.com 4

5 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) Reference First Principles Review Creating One Defence 5

6 First Principles Review

7 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

8 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

9 For consideration What does One Defence Business Model mean to me? Enabling systems Framework tailoring Usefulness of MBSE Interface definitions In-service support End-to-end capability Adaption of Systems Thinking Adoption of new tools & methods Legacy systems Digital transformation solution and organisations Governance at which level Common Concept of Operations New RACI? 9

10 Where Do We All Fit Together? Luke Brown, CAS Group, Chief Systems Engineer

11 So what actually is our job? Luke Brown Chief Engineer

12 What is our Role? 12

13 What is our Role? ADF CASG Industry 13

14 Change the way we do things The well-reviewed bolt 14

15 What is our role? 15

16 Where value is added Usage and Intent 16

17 17

18 What are the Challenges in Implementing Joint Force Integration / Interoperability? Bill Parkins, Chief Engineer, Rockwell Collins Australia

19 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

20 Key focus areas What does One Defence Business Model mean to me? Enabling systems Framework tailoring Usefulness of MBSE Interface definitions In-service support End-to-end capability Adaption of Systems Thinking Adoption of new tools & methods Legacy systems Digital transformation solution and organisations Governance at which level Common Concept of Operations New RACI? 20

21 Common ConOps challenges Navy interoperability (US/Other Coalition Joint Operations) C2, Command Support/ISREW, TF/TG Communications Air & Undersea Warfare Maritime Support-Amphibious and Underway support Air Force interoperability (US/Other Coalition Joint Operations) Airspace Control Air Combat, ISREW Transportation and Support 21

22 Common ConOps challenges Army interoperability (Tactical to Strategic and Joint Forces) Land Manoeuvre Multi-role; Aviation, Combat Support, CSS, Engr, Comms Shaping Operations Amphibious and Special Forces Persistent nodes to supplement shorter range bearers and provide re-transmission or data storage for push and pull access by land assets Australian Joint Operations Sovereign Operations Training for Joint Operations Disaster Recovery Peacekeeping/Regional Aid 22

23 Legacy systems Platform decisions create legacy challenges Cost of developing new solutions compared with buying existing Whole of life cost for acquisition and sustainment is uncertain Navy examples: Collins Class Submarine, FFG, ANZAC Ship, AWD Air 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 environment This additional scope could be progressed by system-of systems integrators working together with platform SPOs and PSIs Needs to be recognised as a component of Engineering Support for the capability and funded accordingly 23

24 Interface definitions Standards? Subject to change (uncertain) Cost to implement changes to extant systems and equipment May be prohibitive if systems are in use globally Examples are waveform changes in radios Flexibility limited and interoperability threatened Architectures? Need to be well understood early in capability definition phase Need flexibility to adapt to meet changing ADF force level capability priorities 24

25 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 models Include system managers as stakeholders in JF SOS model Provide simulation based evidence for verifying Joint Force Interoperability requirements Dynamic verification modelling needed for this Architecture and Data Definitions to be commonly understood and used at all levels 25

26 26

27 Digital Transformation the Move to Model-based Design Approaches Shaun Wilson, Shoal Engineering, CEO

28 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 Operational Analysis Black Box context analysis Solution Concept Solution Design 28

29 From strategy to implementation Strategic Operational System 29

30 Stakeholder needs System functions Design cycle Technology review, Market surveys, Trade-off studies Cost, benefit & risk analysis Strategy Requirements iteration Alternatives analysis & architecture definition Solution iteration Solution concept Solution build Operational experience Verification & Validation 30

31 Needed Capabilities Process Architecture Concepts and Specifications Standards Verification Trade Studies MOEs COIs Adapted from Vitech Corp. source Performance Constraints Traceability Reviews Architecture Validation Risks Decisions Interfaces Change Management Complexity in relationships are often hidden Inconsistencies result in problems

32 Systems Engineering in transition Traditional Specifications Future ATC Pilot Airplane Interface requirements Authorize Request to proceed System design Initiate power-up Report Status Power-up Direct taxiway Analysis & Trade-off Test plans Initiate Taxi Executed cmds Moving from document-centric to model-centric Reprinted from INCOSE Model-Based Systems Engineering Workshop, February

33 A model Performers (organisations, users, stakeholders) Systems External External systems systems Government Policy Concept of Operations Needs Strategy Functions Interfaces Constraints (e.g. regulatory, budget) Requirements 33

34 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

35 Studies & evaluations Commonwealth document repository (Objective) Supply chain capabilities High-performance computing Optimisation Search Interfaces Capability parametric models Range Endurance Persistence Validation data etc. Interfaces Operational / capability model System solution options model Interfaces Cost analysis models Acquisition Sustainment Capability Design Specialist reports (e.g. TRA spt) Technical parametric models Mass Drag Detectability Power consumption Validation data etc. Interfaces Integrated Product Design Environment Expert evaluation 35

36 S.2.ON.1 ADS - Scenar io 2 (G) nil S.2.ON.2 Air component- Scenar io 2 (G) nil Air Def ence C 2 - Scena.. Air space m anagement C2 - Scenar i.. S.2.ON.4 GBAMD - Scenar io 2 (G) nil S.2.ON.5 JFECC - Scenario 2 Air space and Fi res SA - Scena.. (G) nil Sensor data and ef ect - Scenar.. Land C2 - Scenario 2.. S.2.ON.6 Mar iti me C2 - Scenar.. Land component - Scenar io 2 (G) nil S.2.ON.7 Mar iti me component - Scenar io 2 (G) nil S.2.ON.3 S.4 GBAMD Scenari o 4 - Popul ati on s.. GBAMD Capabil it.. Air obj ect node - Scenar io 2 (G) nil AND 1 Perf orm higher C2 - Scenario 2.. HI WNGO (G) 2 Shape - Scenar io 2 (G) HI OPORD (G) 3 GBAMD OPORD (G) Deploy - Scenar io 2 (G) 4 Establi sh GBAMD in the AO - Sce.. LP 5 Conduct GBAMD operati on - Sce Operat ion dur ation Conti nues 0.0 Finished 1.0 basi sof Assess ef fect i veness (G) Functio n LE r esult s in r esult s in r esult s in r esult s in Battle damage assessme nt (G) Requ irement OR basi sof Supp ort Bat tl e Damage Asses.. Functio n speci fi ed b y Syst em Requ irement17.. Requ irement LP Wi thdr aw - Scenar io 2 (G) basi sof basi sof basi sof Assess ef fect i veness (G) Functio n AND Information from t ask success as.. Requ irement Supp ort GBAM D pl annin g (G) Functio n S.1 GBAMD Scenari o 1 - Defence of.. GBAMD Capabil it.. speci fi ed b y Syst em Requ irement 19.. Requ irement Assess task success - Scena.. Op erat i onala cti v.. Supp ort comma nd an d c.. Functio n speci fi ed b y Syst em Requ irement 20.. Requ irement 1.1 basi sof basi sof basi sof M aintain SA (G) Functio n Interface to Land For ce (G) Requ irement Sense objects (G) Functio n Contribu te to Land Force SA (G) Functio n speci fi ed b y Syst em Requ irement33.. Requ irement St at us (G) Requ irement basi sof Assess cu rent condi ti on (G) Functio n speci fi ed b y Syst em Requ irement 18.. Requ irement Through the Capability Life Cycle Capability Design Knowledge Model Test Concept Document Functional & Performance Specification Operational Concept Document Capability Needs Statement Technical parametric studies Capability options analysis Technical Risk Assessment Cost-benefit-risk analysis Diagram courtesy DSTO 36

37 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 38

39 39

40 Applied to Surface Combatants 40

41 Thank You