An Investigation of MBSE Practices across the Contractual Boundary. Quoc Do, Stephen Cook and Matthew Lay

Transcription

1 An Investigation of MBSE Practices across the Contractual Boundary Quoc Do, Stephen Cook and Matthew Lay

2 Contents 1. Research context 2. The research problem 3. Approach 4. Progress to date 5. Early findings 6. Highlights 7. Summary 2

3 1. Research Context Customer Activities Consultancy Activities Project Definition Studies Customer Support Activities Supplier Activities MBSE Concept Definition & SoSE Research Areas Slide 3 Tender Response Preparation Development Phase MBSE across the Contractual Boundary Traditional Focus of MBSE

4 4 2. The Research Problems

5 Research Question 1 What MBSE practices are needed to integrate Acquirer system definition models? Supplier system solution models? Sub-questions What are the challenges? What practices are needed for tendering activities? What practices are needed to manage Requirements-driven change? Implementation-driven change? Slide 5

6 Research Question 2 How can we use MBSE tools to support the design process (as opposed to design capture) in the supplier organisation? Interested in: Design synthesis Trade-off analysis Performance estimation Slide 6

7 Research Question 3 How do we represent and manage the information that needs to traverse the contractual boundary? Nature of the schema Partitioning of models Configuration management across the boundary Slide 7

8 Slide 8 3. Approach

9 Overall Approach Combined approach Scholarship Learn-by-doing Identify challenges to be addressed Trial solutions MBSE practices Innovative tool use Bounding the problem Slide 9

10 The Learn-by-Doing Use Scenario Build on the DSTO pioneering Whole System Analytical Framework (WSAF) that utilises CORE to capture complex system problem definition and the OCD and FPS. Load with an existing project definition model Use this as the basis for a request for tender (with additional information as needed) Design a tender response using traditional SE processes: Requirements analysis Functional analysis Synthesis Systems engineering analysis Build technical response on RFT model Perform MB tender evaluation Slide 10

11 Related Research Activities Investigate tool enhancements needed to support the process Surface challenges from the literature and from exercising the use scenario Address some of the challenges through Defining and exercising processes Tool schemas extensions Bounding MBSE application Publish findings Slide 11

12 Slide Progress to Date

13 Installed WSAF Schema and a project model on the DSIC research infrastructure that employs CORE 9 In parallel, performed literature search Examined the schema, project content, and the documents derived from it (FPS, OCD) Examined the adequacy of the schema to support the RFT and tender response production by conducting supplier systems engineering activities: Requirements analysis Functional analysis Synthesis Started implementing an approach to support synthesis within CORE Slide 13 Progress to Date

14 Slide Early Findings

15 Early Findings WSAF model captures the problem definition well and produces a solid OCD and FPS Supplier SE tender response walk through did not reveal any major deficiencies in the schema WSAF model was written for a purpose not entirely compatible with subsystem design and implementation The nature of the reference (knowledge) model starts to get complex when probity issues and contractual change are considered Greater support to design activities would be attractive Slide 15

16 6. Highlights to Date Support to Synthesis Slide 16

17 ADAV STATE TRANSITION DIAGRAM Water Operation Off Land Operation Transport Support Storage 1.0 DEPLOY ADAV FUNCTION [Ref] F1.0 F1.1/F1.2 [Ref] Defuel ADAV (as required) F1.3 Stow Operational Equipment (as required) F1.7 OR Stow Ammunition (as required) F1.6 Fit Tiedown Points (as required) F1.8 Provide Controls (Land) F2.10 [Ref] Control Vehicle F2.8 [Ref] ADAV ready to transport OR ADAV ready to transport Provide Suspension F2.3 [Ref] Manoeuvre ADAV (on C17) F1.1 Manoeuvre ADAV (on Ferry) F1.1 Provide Power (land) F2.14 [Ref] ADAV Loaded ADAV Loaded Secure ADAV F1.9 Secure ADAV F1.9 ADAV Secured ADAV Secured Provide Traction (land) F2.9 [Ref] Transport ADAV (C17) F1.5 Transport ADAV (Type F13 Ferry) F1.5 F1.1/F1.2 [Ref} C17/ LHD Physical / Environment Physical / Environment External Command and Control Physical / Environment Physical / Environment ADAV in Theatre Unsecure ADAV F1.10 Unsecure ADAV F1.10 ADAV in Theatre F1.0 Deploy Orders / Tasking Request Systems / Tactics Training ADAV unsecured ADAV unsecured Maneouvre ADAV (off C17) F1.2 Maneouvre ADAV (off F13 Ferry) F3.0 Manoeuvre Speed Manoeuvre / Reposition Commands Position / Course F1.2 Propulsion Status F5.0 Vehicle Diagnostics ADAV unloaded ADAV unloaded Remove/stow Tiedown Points (as required) F1.11 Un-stow Ammunition (as required) Deployment Status Vehicle Maintenanc e Faults / Status F2.0 Communicat e Position / Course Hostile / Neutral / Friendly Loc Comms Training F1.13 Vehicle Motion / Orientation & Speed Hostile / Neutral / Friendly Loc F8.0 Navigate ADAV operational Un-stow Operational Equipment (as required) F1.12 Refuel ADAV (as required) F1.4 ADAV operational Vehicle Motion / Orientation & Speed Hostile / Neutral / Friendly Loc Position / Course F4.0 Surveillance Systems / Tactics Training Vehicle Motion / Orientation & Speed Fire/Engage Command Position / Course Threat Data / Tracking F7.0 Neutralise Weapons Training [Ref] F1.0 Threat Data / Tracking F6.0 Protect & Survive Systems / Tactics Training Request Supplies / Maintenanc e / Support System Systematic Design - Synthesis Synthesis: produces candidate design solutions from the functional architecture evaluates their structure, performance, behaviour, and value selects the preferred solution Select Preferred Solution and Complete Design Package Evaluate Design Alternatives Against Value Models Identify Physical Interfaces Allocate Requirements to Solution Components Functional Architecture Slide 17 Synthesise into Candidate System Solutions Identify Design Solution Alternatives for Lower Level Functions System Solution

18 MBSE Support to Synthesis The generation of candidate designs from the functional architecture can be done in a number of ways Map the leaves of the functional hierarchy to design solutions Map the lowest level of the functional flow block diagrams to design solutions The structured design approach: use a morphological table to consider how each function could be performed and form candidate solutions from viable groupings of design solutions to the functions Slide 18

19 The Functional Packaging of a System onto Major Elements (B&F p101 or 122) 19

20 Functional Packaging from a FFBD System Requirements System Top-level Functions Function A Function B Function C Function D Function E Function F Second-level Functions Third-level Functions Unit 1 Unit 2 Unit 3 Unit 4 20

21 Candidate Solution 1 Candidate Solution 2 Morphological Table Transfer Signal (Method) Transfer Signal (Media) Uni-directional Kid transmits Radio Bi-directional Microwave Bi-directional to center Infra-red IR Uni-directional Adult transmits Ultra sound Uni-directional Reflecting 5,3 5,3 5,3 5,3 3,3 US Detect Distance 5,5 5,5 3,5 Time forth and back Signal level Geometric Calculation d 5,3 3,5 5,3 3,5 [ Performance, Lack of development risk ] Piezo electric Speaker Buzzer Vibrator Stinger Produce Alarm Find Direction Instrument rotating 5,5 3,5 3,5 3,5 3,3 Geometric Directional Differential Calculation - Antenna Detector Cellular Geometric Calculation - GPS Display Direction & Distance Beep 5,5 5,3 5,3 5,3 5,5 LCD LED Light level 5,3 3,5 3,5 3,3

22 Innovative Application of MBSE Enhance support to design as opposed to recording the design: Create candidate solutions given a set of functions and design components Evaluate stakeholder value of candidate solutions against MoEs/TPMs Trade-off between candidate solutions (that are all held within a tool environment) to determine the preferred solution The following slides illustrate the progress achieved on the first topic Slide 22

23 The Starting Point A set of system functions that needs to be implemented A set of components that could implement the functions Relate the functions to the components that they can be allocated to Slide 23

24 Invoke The Morphological Table Slide 24

25 Select the Functions to Implement Slide 25

26 Morphological Table Table automatically generated with selected functions and components User needs to enter: The relative performance of the design solution for each function The risk assessment of each design solution The potential candidate solutions, if any, that use each design solution Slide 26

27 Read Morphological Table Back into CORE Candidate solutions held in packages for subsequent refinement, analysis and trade-off Slide 27

28 6. Highlights to Date Thoughts on Model Partitioning Slide 28

29 Insights from Modelling the Realization System (The system for creating the system, after Martin, 2004) Alerted us to the fact that only parts of the model at any stage pass between the actors. This will mean that re-integration later could be problematical unless interfaces can be declared and managed Slide 29

30 The Project Environment (Document-Based Paradigm, Do et al, 2011) Defence Primary Industry Supplier Defence Secondary Government Stakeholder Groups Industry PSPs National Environment Laws and Regulations *Legal Liabilities * Social Responsibilities * Technology Base * Labour Pool *Competing Products * Standards & Specifications * Public Culture Australian Defence Enterprise Environment *Policies & Procedures * Standards & Specifications * Guidelines * Domain Technology * Defence Culture Project Environment Above-The-Line Activities * Directives & Procedures * Plans * Tools * Project Reviews * Metrics Project Support Processes Standards Operating Principles Project Acquisition Information Repository CDP Process Artefacts Project Project Briefings Briefings SOWs RFIs Responses to RFIs Deliverables Contractual Interface Slide 30 Project Environment * Directives & Procedures * Plans * Tools * Project Reviews * Metrics Project Support Processes Standards Operating Principles Project Supplier Information Repository Below-The-Line Activities

31 An MBSE Tendering Environment with Two Bidders (Do et al, 2011) Defence Primary Defence Secondary Government Industry Supplier Industry PSP Stakeholder Groups May well need an intermediate model that could perhaps become the alliance model National Environment Laws and Regulations *Legal Liabilities * Social Responsibilities * Technology Base * Labour Pool *Competing Products * Standards & Specifications * Public Culture Australian Defence Enterprise Environment *Policies & Procedures * Standards & Specifications * Guidelines * Domain Technology * Defence Culture Project Environment * Directives & Procedures * Plans * Tools * Project Reviews * Metrics Project Support Project Acquisition Model Processes Standards Operating Principles Knowledge Representation Schema/Metamodel CM Database Project A Model-based Information flow via views into a shared model Shared Model Environment * Directives & Procedures * Plans * Tools * Project Reviews * Metrics Model Support Shared Project Model Shared Model Environment * Directives & Procedures * Tools * Metrics Processes Standards Operating Principles Shared Model with Company A Model Support Processes Standards Operating Principles Shared Project Model Shared model with Company B Project Environment * Directives & Procedures * Plans * Tools * Project Reviews * Metrics Project Support Project Supplier Model Project Environment * Directives & Procedures * Plans * Tools * Project Reviews * Metrics Processes Standards Operating Principles Slide 31 Company A Project Model Project Support Processes Standards Operating Principles Project Supplier Model Company B Project Model

32 Slide Summary

33 Summary (1) The use of MBSE across the acquisition boundary is a contemporary research area This project is exercising a Use Scenario to uncover and investigate the issues Early findings WSAF model captures the problem well and produces a solid OCD and FPS Supplier SE tender response walk through did not reveal any major deficiencies in the schema WSAF model was written for a purpose not entirely compatible with subsystem design and implementation The nature of the knowledge model starts to get complex when probity issues and contract change are considered Greater support to design activities would be attractive 33

34 Summary (2) MBSE-based design support looks encouraging to: Create candidate solutions Evaluate stakeholder value of candidate solutions Select preferred solution Slide 34

35 Modelling the Realization System surfaced insights: Need to identify the nature of the system model held by each party Need to understand how these models evolve over time Need to consider how best to modularise the models to permit managed information transfer Need to consider whether re-integration of models is feasible or whether earlier models have to be abandoned Need to consider whether re-evaluating decisions later in the project will be feasible Need to consider how to deal with contract changes; will this may require model re-integration Need to consider how to deal with equipment-driven systems changes Come to SETE 2014 for the next instalment! Slide 35 Summary (3)