Introduction to Model Based System Engineering
Definitions
What it is
Formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle stages.
MBSE is a specialization of Model Based Engineering which is
What it is not
Inevitably it is compared to the other Approach to Systems Engineering, Document Based System Engineering.
Rationale
Precondition
MBSE is suited to tasks that are
Some tools are not suited to application of MBSE, e.g.
Postcondition
Problem
Be aware of cyber-physical gap (the gap between what actually happens and the mental model of the reality)
Integrating legacy products and models into the MBSE model encompasses huge challenges
Quantity of data to be handled by the model may 'break' the model, particularly its reliance on diagrams for communication
Upfront investment to design, develop, and implement an MBSE approach
Building a cadre of employees with modeling and software skills
Process definition and adoption by the different multidisciplinary teams
Team training on MBSE processes and tools
Methodology
For a review of MBSE Methodologies see this page.
Method
Heuristics
People who have responsibility for change of parameter in model should be the same subject matter expert who made the change before the use of models
A model is regarded as complete if the stakeholder receiving the document does not ask too many questions and gives then enough space to produce a design
A System Engineer can provide first 3~5 levels of detail and provide the platform for disciplines to interact
20% of modeling effort is in modeling sunny day (nominal) scenarios, rest is on rainy day (non-nominal) scenarios
By having redundancies in feedback modeler can minimize making decisions based on false feedback (see cyber-physical gap)
Use Standard and Patterns. Define a set of rules and best practices to structure the design environment
If number of users are small then can have an in-formal approach to what part shall be modeled by whom
If number of users are large then need formal configuration management process
Process
MBSE activity
Ask questions
Evaluate what functions (and at what level of fidelity) MBSE activity should be applied to
Evaluate what components (and at what level of fidelity) MBSE activity should be applied to
Decide who/which teams should participate in MBSE activity
What difference do we expect MBSE to make to the bottom line
Learn how to be a SE
Learn how to use a language (
SysML)
Learn how to use a tool
Modeling
Start with Use Cases. Sum of required functions = complete system behavior
Flesh Use Cases with stakeholder-SoS behavior (black box)
Create Requirement Tree, refined by use cases
Provide Context
Structure and Inter-relationships
Behavior w/ states
Test/Simulate to Verify/Validate
Parts
Architecture
Monolothic Model Architecture (clean sheet, single model)
Federated Model Architecture (different models interconnected to each other, recommended if different models have high fidelity)
Tools
Language
Abstraction
Emphasis on relevant information only which helps communication, decision making and analysis
Building a model is an application of abstraction
E.g. Requirement Document is an abstraction of emergent behavior
Task list is an abstraction of process
ICD is an abstraction of interface
Automation
Employs computers to perform simulations providing additional information
Automation can lead to better comprehension by helping to predict outcomes under different scenarios
Automate verification activity
Use Cases
Fowler identifies 3 different use cases of UML models:
UML As Sketch
UML As Blueprint
UML As Programming Language
Scenarios
Maintain configuration control
View data from different viewpoints
Determine who/what will be impacted by changes
Trace requirements, design, verification, validation and integration
Check consistency