Introduction to Model Based System Engineering

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

• An approach to engineering that uses models as an integral part of the technical baseline that includes the requirements, analysis and design

Inevitably it is compared to the other Approach to Systems Engineering, Document Based System Engineering.

• Improves Communication
  • Allow different views of the same data - from a single repository MBSE allows user to interrogate the design from different viewpoints. Includes
    • Human Readable Views
    • Machine Readable Views
• Improves Quality
  • Opens the system data/architecture to more subject matter experts giving them the opportunity to make suggestion on how to improve the sytem
• Improves Productivity
  • Eliminates the risk of using redundant data whilst still providing same level of detail
  • Allows automated query for information
• Facilitates management of Complexity
  • Profiles can be extended to different domains
• Facilitates Reuse
• Facilitates Integration.
  • Allows integration of different engineering disciplines
  • Allows integration of information of system over the whole lifecycle

• MBSE does not eliminate documents but unites them in a model

MBSE is suited to tasks that are

• Complete
• Consist
• Potentially logically verifiable

Some tools are not suited to application of MBSE, e.g.

• Early goal setting such as determining how technology-neutral / specific the specification needs to be
• Visioning
• Coordinating Function

• Should produce unified designs
• Produces documents

See this page on model quality.

See this page on how to critique a model.

• 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

For a review of MBSE Methodologies see this page.

• 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

• Ask questions
  • Why model?
  • What problem are we trying to solve with the model?
• 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

1. Start with Use Cases. Sum of required functions = complete system behavior
2. Flesh Use Cases with stakeholder-SoS behavior (black box)
3. Create Requirement Tree, refined by use cases
4. Provide Context
5. Structure and Inter-relationships
6. Behavior w/ states
7. Test/Simulate to Verify/Validate

• 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
    • Provides common vocabularly, structure for communications, e.g. SysML
    • SysML - good general purpose but is limited by the diagram which becomes unyieldly when increasing data
    • Language should be used to enable logicaly reasoning for completeness, consistency or behavior
  • 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

• Model - {definition: intelligent relationships between elements tied together in a logical/mathematical way}systems
  • Components
  • Interfaces (e.g. mechanical, data, power, thermal, optical, pneumatic)
  • Use Cases
    • Nominal Scenarios - covers basic outcomes under nominal conditions and does not consider exceptions
• Critique

Fowler identifies 3 different use cases of UML models:

1. UML As Sketch
2. UML As Blueprint
3. UML As Programming Language

• 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