Introduction to Model-Based Systems Engineering

David Orr Systems Engineering Specialist

Agenda 1. What is MBSE? 2. Different Model Viewpoints 3. Why do MBSE? 4. Why not do MBSE? 5. Do’s & Don'ts 6. Language & Architecture 7. Techniques & Approaches 8. Concepts & Enabler

Reference: http://www.incoseonline.org.uk/Documents/zGuides/Z9_model_based_WEB.pdf

1. What is MBSE?• A formalised application of modelling to support:

– System requirements (capture & definition) – System analysis (functional and performance) – System design (solution optioneering) – Verification & Validation

• MBSE spans the SE lifecycle • MBSE is an alternative to document-based SE

– Model with viewpoints replaces traditional documents (specs, interface requirements, analysis reports, plans)

• The model forms the “single source of truth

What is MBSE?• Document-centric (traditional) approach:

– Write specifications (publish BRS/SRS/OCD) – Analyse options (publish design reports) – Do trade-off analysis (publish option reports) – Analyse interfaces (publish interface specs) – Plan testing (publish inspection/test plans & specs)

What is MBSE?• Model-centric (novel to TfNSW) approach with

viewpoints: – Enterprise/Planner – Implementer (design/build/test) – Operator – Maintainer

2. Different Model Viewpoints

Planner

Implementer

(Design & Construct)

Operator

Maintainer

3. Why do MBSE?• Improve communications

– With stakeholders (planner, implementer, operator, maintainer) – In engineering team (implementer) – Across language/discipline barriers

Planner

– Visual rather than written viewpoint – “A picture paints a thousand words” – Suitable for complex problems & solutions Operator

ImplementerMaintainer

Why do MBSE?• Improve quality

– Early identification of requirements issues (gap/clash) – Focus on defining problem rather than documentation – Diagrams less ambiguous than textual descriptions – Improved system specification – Reduce rework (redesign, rebuild) – Reduced errors during system integration/test – Improved requirements traceability – Consistent, automated documentation generation

Why do MBSE?

• Increase productivity – Improved impact analysis of requirement changes – Greater consistency across related “documents” – Less duplication & inconsistency – Improved multi-discipline team interaction – Re-use of existing models – Auto-generation of documentation (specs, reports)

Why do MBSE?

• Reduce risk – Improved cost estimates – Early requirement definition & validation

• Enterprise goals/Business requirements • Operational/Maintenance Concepts • System requirements

4. Why not do MBSE?

• You cannot model everything! • Hard to model non-functional requirements (to be):

– Supportability – Compatibility – Interoperability – Disposability – Sustainability

Why not do MBSE?

• Not if maintaining “business as usual” (BAU) • Not if problem & solution definition is “simple” • Not if scope & complexity cannot justify cost & effort • Not without prior training & awareness • Not if the will & culture are lacking • Not in isolation from other teams & methods • Not if no enterprise vision, leadership & support

5. MBSE Do’s

• involve design SMEs early on • select an applicable approach • plan/manage modelling process • clearly define system of interest • keep models simple as possible • understand model assumptions • verify models as you develop • Verify that the tool gives what you need • question simulation results

MBSE Don’ts

• model just for the sake of it • exclude stakeholders • model in isolation from design • exclude engineering know-how • assume MBSE has all answers • believe what a tool-vendor says • model without understanding the model inputs &

outputs • use same data to develop and to test model

6. Language & Architecture

• What is a modelling language? – A structured, common, syntax & rules-based means of

communicating modelling concepts between multiple stakeholders with different viewpoints

• What is an architecture? – A structured framework upon which to develop design

• What is an architectural framework? – A generic structure and syntax “metamodel” used as a basis for

developing a specific architectural model

• What is an architectural model? – An abstract representation of a real system

7. Techniques/Approaches• Select a suitable modelling language/notation

– Unified Modelling Language (UML) – System Modelling Language (SysML)

• Select a relevant architectural framework – DODAF, MODAF, TRAK

• System modelling methodologies: – Object Oriented Systems Engineering (OOSE) – Rational Unified Process (RUP) – Harmony SE – Vitech’s MBSE Methodology

• Select pre-defined methodology, then tailor it • Manage the model! (control and review)

Techniques/Approaches• Record model objectives/assumptions • Some possible modelling techniques:

– Structured analysis/design (functional models) – Behavioural Modelling (pedestrians, rail traffic) – Entity Relationship Modelling (interfaces, human) – Finite Element Modelling (structures, mechanical systems) – Environment Virtualisation (flooding, lighting, noise) – Process Modelling (business flows) – Building Information Modelling (BIM) (buildings, places)

Techniques/ApproachesBIM 3D/4D/5D/6D

6D

3DSpatial information

ID Task Name FinishFeb 2015

18 19 20

1 18/02/201518/02/2015 Task 1

2 18/02/201518/02/2015 Task 2

Start

4D

Schedule information

Cost information5D

Lifecycle management information

8. Concepts/Enablers• Models are abstractions/representations of reality • Models facilitate understanding of complexity • Models are not reality – remember that! • Use multi-user repository-based modelling tools • Models can be applied:

– Horizontally to support SE lifecycle process – Vertically to support top-down integration into:

• Operational models (Operational Concept) • System models (Functional Model) • Component models (Asset Classification Scheme)

Concepts/Enablers

• Move to MBSE requires culture/mindset change • Model/solution will evolve with increasing detail • Documents automatically generated to baselines

Stakeholders, Model, LifecycleCED/FRD/TSD CED/FRD/TSD

TransportAsset Management

& Service Agency

TPD (AEOEP)

Design/Build/Integrate/Test Supply Chain (AEOs)

PPD

Demand AnalysisStrategic Goals

Operational ConceptMaintenance Concept

Business Case

Business Requirements Specification (BRS)

System Requirements Specification (SRS)

Enterprise Goals

Concept Activity

Concept Activity

Concept Activity

Concept Activity

COTS Procurement, Fabrication, Manufacture

Site Installation & Assembly

Sub-systems Integration and Testing

Network Integration Test & Commission

System Validation, Acceptance & Handbackvalidation

verification

validation

Operate & Maintain

Measure Performance

Stakeholder engagement area

Lifecycle stage transition

System life cycle stage

allocate

allocate

allocateallocate all

ocate

verification

Capability View Capability ViewMetric Metric

Metric Metric

Metric

Systems Integration and Testing

Disposal

Sys

tem

/Fun

ctio

nal V

iew

(Fun

ctio

nal B

reak

dow

n)P

hysi

cal/S

olut

ion

Vie

w (A

sset

Bre

akdo

wn)

System Implementation/RealisationSystem Definition & Design

CED: Customer Experience DivFRD: Freight & Regional DevelopTSD: Transport Services DivTPD: Transport Projects DivAEO: Authorised Eng Organisation

allo

cate

allocateallo

cate

Systems Architecture (Preliminary Design)

Sub-systems Design (Detailed Design)

Assembly Level Design (Detailed Design)

verification

verification

Component Level Design (Final Design - AFC)

AFCverification

verification

verification

MetricMetric

Assem

bly 1

Assem

bly 8

Assem

bly 7

Assem

bly 6

Assem

bly 5

Assem

bly 4

Assem

bly 3

Assem

bly 2

Subsystem

1

Subsystem

4

Subsystem

3

Subsystem

2

Function 1

Function 8

Function 7

Function 6

Function 5

Function 4

Function 3

Function 2

verification

Questions?