Model-based systems engineering

What is MBSE?

Model-based systems engineering (MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents.) is a way of doing systems engineering in which a connected model of the system, rather than a set of separate documents, holds the engineering information. Requirements, functions, components, interfaces, tests and risks are recorded once, linked to each other, and shown to each audience in the form it needs.

From documents to a model

In document-based systems engineering, the system lives in a stack of files: a requirements specification, an architecture description, interface control documents, a test plan, a risk register, and spreadsheets that try to connect them. Each file is written and reviewed on its own. When a requirement changes, someone has to find every place that depends on it and update each one by hand. On a small project that works. On a large one, the documents drift apart, and reviews spend their time finding inconsistencies instead of judging the design.

MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. moves the information into a model. A requirement is not a paragraph in a file but an item with its own identity, attributes and links. The function that satisfies it, the component that performs that function and the test that verifies it are items too, and the links between them are part of the model. Documents still exist, because people still read and sign them, but they are produced from the model instead of maintained beside it.

The International Council on Systems Engineering (INCOSEInternational Council on Systems Engineering The professional society for systems engineering. It publishes the Systems Engineering Handbook.) describes MBSE as the formalized application of modeling to support requirements, design, analysis, verification and validation, from the concept phase through development and later lifecycle phases. In practice, that means the model is the main working product of the engineering team.

The core ideas

One source of truth

Each fact about the system is recorded once. The mass of a battery, the text of a requirement or the owner of an interface has one home in the model. Every diagram, table and document that shows it reads that one value, so a change made in one place appears everywhere it is used. In Holarch, every page is a view of one model: see the model behind Holarch.

Traceability

Because the links are part of the model, the chain from a stakeholder need to a requirement, to the functions and components that answer it, and to the tests that verify it can be followed in both directions. That answers two everyday questions: why does this part of the design exist, and what is affected if this requirement changes? A traceability matrix shows the gaps, and a change to a source item can flag its downstream links for a second look. See needs and requirements.

Views of one model

Different people need different pictures of the same system. A functional flow block diagram (FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths.) shows the order of functions, a block diagram shows structure, an N-squared chart shows interfaces, and a specification shows requirements as numbered text. In MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. these are views of the same items, not separate drawings. Rename a function on a diagram and the new name shows in the specification too. See behavior and architecture.

Interfaces as first-class items

Many system problems appear where subsystems meet. A model records each interface as an item with its endpoints, the data or material it carries, and its capacity, so interface control documents can be generated from the register rather than written separately. See interfaces.

Verification built in

Each requirement can carry a verification method and links to the test cases that verify it. Test results recorded against those test cases roll up per requirement, so a requirements verification traceability matrix (RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result.) shows what is verified, what failed and what has no test yet. See verification.

Analysis on the same data

A model can be checked and analyzed in ways a document cannot. Rule-based checks find functions with no performer or requirements with no test. Simulations of a functional flow estimate duration and cost. Budgets track mass, power and cost against their limits. Risks and trade studies link to the items they concern. See risk and decisions.

Modeling languages

A model needs a language: a defined set of element types, relationships and diagrams. Two languages are widely used for MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents..

• SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. (Systems Modeling Language) is a general-purpose modeling language for systems engineering, with diagram types for requirements, structure, behavior and parametrics.
• LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. (Lifecycle Modeling Language) is an open language built around a small set of entity classes and relationships, with simple diagrams, and covers program concerns such as cost, schedule, risk and decisions alongside the technical design.

Holarch's model is built on LML and draws SysML diagrams as views of it. Read more about LML and about SysML diagrams in Holarch.

What an MBSE workbench should give a team

• A shared model. Engineers, reviewers and customers look at the same current model, not at exported copies. See collaboration.
• Familiar outputs. Specifications, ICDsInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram., test reports and review packages in Word and Excel, produced from the model. See plan and deliver.
• A way in for existing work. Import of Word specifications, spreadsheets, ReqIFRequirements Interchange Format An OMG XML standard for exchanging requirements, with their attributes and links, between tools. and models from other tools, so a project does not start from zero. See the import and export reference.
• Control over change. Approvals, baselines, change requests and version history, so the team knows what was agreed and what moved since.
• Room to grow. A schema the team can extend, and architecture framework products such as DoDAFDepartment of Defense Architecture Framework The US DoD framework for describing architectures as a set of viewpoints and products, such as OV-1 and SV-1. and UAFUnified Architecture Framework An OMG architecture framework that organizes views in a grid of viewpoints and aspects. It covers DoDAF and NATO needs. when a program asks for them. See frameworks.

How to start with MBSE

Teams that adopt MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. well usually start small and let the model earn its place.

1. Pick one real system. A subsystem or a small project with a review coming up is better than a company-wide rollout.
2. Start with what you have. Import the existing requirements, then link them to the functions and components that answer them.
3. Add the trace as you go. Link requirements to test cases, and use the gaps a traceability matrix shows as the to-do list.
4. Produce one document from the model. When the next specification or ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram. comes from the model, the team sees the benefit at the next change.
5. Extend only when needed. Add classes, attributes and diagrams when a real question needs them, not up front.

Holarch runs in the browser, and students and instructors use it free. Read what Holarch covers as an MBSE tool, follow the getting started guide, or see Holarch for classes.