Post on 25-May-2020
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?