Model-Based Systems Engineering & the System Life Cycle

Model-based systems engineering (MBSE) is systems engineering in which formalized models are primary technical artifacts throughout the lifecycle. Documents may still be generated for communication or approval, but they are views of maintained model content rather than independent sources that drift apart.

ISO/IEC/IEEE 15288:2023 provides a common framework of lifecycle processes from conception through development, production, utilization, support and retirement. It explicitly allows processes to be iterative, concurrent and recursively applied to system elements; it does not prescribe one lifecycle model or modeling technique. SysML 2.0 supplies a current language for expressing system requirements, structure, behavior, quantities and analysis relations with complementary graphical and textual notation.

Model-based is not diagram-based #

A drawing becomes a model when its elements have defined identity and semantics, relations can be queried, and consistency constraints can be evaluated. Copying the same component name into five diagrams creates five strings. Referencing one component definition from five views creates one modeled entity with several projections.

flowchart TD
  N["Stakeholder needs"] --> R["Requirements"]
  R --> A["Architecture and behavior"]
  A --> X["Analysis models"]
  A --> V["Verification cases"]
  X --> E["Evidence and margins"]
  V --> E
  E -->|"reveals mismatch"| R

The arrows are trace relations with meaning: derive, satisfy, allocate, verify, refine or contradict. A generic hyperlink is not enough when change impact depends on relation type.

A minimal model spine #

An effective repository connects:

• stakeholder needs and operational scenarios;
• measurable requirements and constraints;
• system context and interfaces;
• functional and behavioral models;
• logical and physical structure;
• quantities, units, budgets and margins;
• analysis models and assumptions;
• verification methods, cases, results and anomalies;
• configuration baselines and change decisions.

Specialist models remain necessary: simulation, CAD, source code, safety analysis and test data cannot be replaced by one general-purpose language. MBSE succeeds when the authoritative identities, parameters and assumptions connecting those models are managed and transformations are checked.

Lifecycle reasoning #

The same SoI is viewed differently through life:

Verification and validation are not synonyms. A perfectly implemented requirement can still be the wrong requirement.

Change propagation is the payoff #

Suppose a sensor sample period changes. A connected model should reveal affected filters, estimator assumptions, controller discretization, bus load, timing budgets, power use, verification cases and safety evidence. The model need not automatically decide the change is acceptable. It must make the affected claims discoverable and keep quantities consistent.

That requires configuration discipline. Every result must identify model version, tool/transformation version, parameter set and evidence. A “digital thread” without provenance can propagate the wrong value more efficiently.

Failure modes #

• diagrams are produced for reviews but not used for decisions;
• model elements duplicate rather than reference authoritative definitions;
• requirements are syntactically traced but not measurable;
• analysis results omit assumptions, units or validity ranges;
• generated documents are edited independently;
• tool interoperability loses semantics while preserving shapes;
• the model stops at delivery and excludes operation, support and retirement;
• consistency checks verify schema validity but not physical plausibility.

Start with one decision chain whose drift is costly, model its authoritative entities and relations, automate a few decisive checks, and make evidence flow back into the same configuration. MBSE is justified when it improves change reasoning and technical truth, not when it maximizes model size.