Home / Courses / AI-Enabled Digital Engineering and Virtual Product Development / Module 4

Course 25 | Module 4 of 12

Model-Based Systems Engineering and Practical SysML Awareness

Use model-based representations to connect requirements, structure, behavior, analysis, and verification without turning the course into syntax training.

Start lesson 4.1 Open lab

MAP

Module map

Learning outcomes

Explain why MBSE is a way of working, not a collection of diagrams.
Read practical SysML representations of requirements, structure, behavior, and interfaces.
Connect parametric, analysis, and verification cases to engineering evidence.
Plan integrations between system models, CAD, CAE, optimization, and test artifacts.

Evidence standard

Complete all four lessons, reproduce the worked checks, run the lab, and correct the weekly quiz. Treat AI output as candidate evidence until independently verified.

Lesson 4.1MBSE as a governed modeling practice Lesson 4.2Practical SysML concepts: requirements, structure, behavior, and interfaces Lesson 4.3Parametric models, analysis cases, and verification cases Lesson 4.4Connecting MBSE with CAD, CAE, optimization, and evidence

4.1

MBSE as a governed modeling practice

Why this lesson matters

A diagram can be visually persuasive while its elements have no shared semantics, ownership, configuration, or connection to evidence.

Learning objectives

Define and distinguish MBSE and Model element.
Apply the lesson method to the worked mbse as a governed modeling practice case.
Evaluate evidence, uncertainty, and AI-assisted output before making a claim.

Readiness check

Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.

Check your response

A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.

Core idea

Model-based systems engineering applies systems engineering using a coherent model as a primary means of representing, analyzing, communicating, and controlling system information. Diagrams are views of model elements and relationships, not the model itself.

Key concepts

MBSE	Systems engineering performed through governed models and their relationships across lifecycle work.
Model element	A uniquely identified semantic object such as a requirement, part, action, port, analysis, or verification case.
View	A presentation of selected model information for a stakeholder concern.
Viewpoint	The conventions, purpose, and concerns that govern a view.

Step-by-step explanation

Define stakeholder questions before selecting a view.
Create reusable semantic elements with stable identity.
Connect elements through typed relationships and ownership.
Generate views for different concerns from the same model basis.
Validate the model against source information and keep it under configuration control.

Worked example

A team has separate requirement, block, and activity diagrams for the cooling rig. The pump is named P-1, PumpAssembly, and CoolantMover in the three diagrams, with no shared identity.

1
Create one pump element with a stable identifier.
2
Assign its structural role, allocated function, ports, requirements, and verification cases as relationships.
3
Render separate views for requirements, structure, and behavior from that element.
4
Add ownership, status, and configuration so a view cannot silently mix baselines.

Result. The diagrams become consistent views of a governed model instead of three drawings that happen to look related.

Independent check. Selecting the pump in any view reaches the same element, properties, relationships, and baseline.

Common misconceptions

Misconception	Correction
MBSE means drawing SysML diagrams	MBSE includes methods, semantics, analysis, governance, traceability, configuration, and evidence use.
A tool output closes the question	A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked.

Diagnostic questions

Can a spreadsheet participate in MBSE?

Yes, if its role, data semantics, configuration, and relationships are controlled; tool type alone does not decide.

What would make this work reproducible?

Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.

Practice ladder

Basic

Explain the difference between a model and a diagram using a pump example.

Intermediate

List model elements needed to answer who verifies a cooling requirement and with what evidence.

Advanced

Design three stakeholder views that reuse one model without exposing irrelevant detail.

AI-assisted engineering task

Ask AI to identify inconsistent names and candidate duplicate elements across three model exports. Require evidence for each match.

How to prove the AI output yourself

Compare identifiers, not labels alone.
Check ports, properties, owner, and configuration.
Let the model authority merge or reject candidates.

Retrieval and spaced review

Answer closed-notes today, then again after 1, 3, 7, and 30 days.

Define MBSE.

Systems engineering performed through governed models and their relationships across lifecycle work.

What role does Model element play here?

A uniquely identified semantic object such as a requirement, part, action, port, analysis, or verification case.

What must a reviewer be able to reconstruct?

Selecting the pump in any view reaches the same element, properties, relationships, and baseline.

End-of-lesson summary

Student notes

When you draw a view, note the stakeholder question, source model, baseline, and elements intentionally excluded.

Practical SysML concepts: requirements, structure, behavior, and interfaces

Why this lesson matters

Mechanical engineers do not need to memorize every notation, but they must read and question the model elements that connect their analyses to system intent.

Learning objectives

Define and distinguish Requirement definition and Part and port.
Apply the lesson method to the worked practical sysml concepts: requirements, structure, behavior, and interfaces case.
Evaluate evidence, uncertainty, and AI-assisted output before making a claim.

Readiness check

Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.

Check your response

A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.

Core idea

SysML 2.0 supports representations of requirements, structure, behavior, analysis cases, and verification cases. Use only enough notation to make semantics and relationships clear, then return to the engineering question.

Key concepts

Requirement definition	A reusable definition of required constraint or behavior with attributes and relationships.
Part and port	A structural element and its interaction point used to describe composition and interfaces.
Action	A unit of behavior that transforms inputs into outputs.
State	A condition of a system with permitted behavior and transitions.

Step-by-step explanation

Represent the requirement and its measurable attributes.
Build structural decomposition using parts and typed ports.
Describe key behavior as actions, flows, states, and interactions.
Connect requirements to responsible parts and behaviors.
Use views to inspect interface completeness and allocation coverage.

Worked example

Represent a thermostatically controlled cooling loop with sensor, controller, pump, cold plate, and radiator.

1
Create a requirement for fixture temperature <= 45 °C in the test transient.
2
Represent parts and ports for coolant, electrical power, temperature signal, and speed command.
3
Describe behavior: sense temperature, compare threshold, command pump, transport heat, and enter fault state on sensor loss.
4
Link the temperature requirement to the control and thermal behaviors and the verification case.

Result. The model shows not just component presence but how structure and behavior jointly satisfy a requirement under nominal and fault states.

Independent check. Every flow has compatible source and sink, every required behavior is allocated, and fault behavior has a verification path.

Common misconceptions

Misconception	Correction
A block diagram proves the system works	It represents selected structure or behavior; analysis and evidence are still required.
A tool output closes the question	A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked.

Diagnostic questions

Why use ports?

They make interaction points and exchanged items explicit, which supports interface consistency checks.

What would make this work reproducible?

Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.

Practice ladder

Basic

Choose whether ten statements describe requirement, structure, behavior, interface, or state.

Intermediate

Sketch a textual SysML-like model for the loop without relying on vendor syntax.

Advanced

Add a redundant sensor and explain how structure, behavior, states, and verification change.

AI-assisted engineering task

Ask AI to turn a short controlled specification into candidate model elements and relationships, preserving source identifiers.

How to prove the AI output yourself

Compare every candidate element to the specification.
Check direction, multiplicity, units, and allocation.
Reject invented behavior or components.

Retrieval and spaced review

Answer closed-notes today, then again after 1, 3, 7, and 30 days.

Define Requirement definition.

A reusable definition of required constraint or behavior with attributes and relationships.

What role does Part and port play here?

A structural element and its interaction point used to describe composition and interfaces.

What must a reviewer be able to reconstruct?

Every flow has compatible source and sink, every required behavior is allocated, and fault behavior has a verification path.

End-of-lesson summary

Student notes

For each model element, keep source, purpose, owner, and verification relation visible.

Parametric models, analysis cases, and verification cases

Why this lesson matters

Equations become reusable system evidence only when variables, units, assumptions, execution, and requirement comparisons are controlled.

Learning objectives

Define and distinguish Constraint relation and Analysis case.
Apply the lesson method to the worked parametric models, analysis cases, and verification cases case.
Evaluate evidence, uncertainty, and AI-assisted output before making a claim.

Readiness check

Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.

Check your response

A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.

Core idea

A parametric relationship constrains properties using equations. An analysis case defines the question, configuration, inputs, method, and outputs. A verification case adds the target requirement and pass-fail logic.

Key concepts

Constraint relation	An equation or rule connecting typed quantities and units.
Analysis case	A controlled definition of an analysis question and execution context.
Verification case	A planned or executed evaluation of requirement compliance.
Value binding	The traceable assignment or connection of an actual value to a model property.

Step-by-step explanation

Define quantities with dimensions, units, uncertainty, and source.
Express equations independently from one execution tool.
Create an analysis case with configuration, assumptions, method, and requested outputs.
Bind controlled values and record execution provenance.
Compare results with requirement criteria in a verification case, including uncertainty and disposition.

Worked example

Use δ = P L³/(48 E I) for a simply supported beam with center load. P = 1200 N, L = 0.8 m, E = 69 GPa, b = 0.04 m, h = 0.03 m, I = b h³/12.

1
Compute I = 0.04(0.03)³/12 = 9.00e-8 m⁴.
2
Compute δ = 1200(0.8)³/[48(69e9)(9e-8)] = 0.002061 m.
3
Convert to 2.06 mm and bind it to the analysis result with the specified configuration.
4
If requirement δ <= 2.50 mm, nominal margin is 0.44 mm; compliance still needs input and model uncertainty treatment.

Result. The nominal analytical case passes by 0.44 mm. The verification case remains conditional until uncertainties and model applicability are assessed.

Independent check. Units close, arithmetic reproduces, boundary condition matches the equation, and the requirement uses the same load and configuration.

Common misconceptions

Misconception	Correction
A parametric relation is a simulation	It defines a constraint; an execution with bound inputs and method produces a result.
A tool output closes the question	A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked.

Diagnostic questions

When is a nominal pass insufficient?

When uncertainty, model discrepancy, configuration mismatch, or consequence makes the decision margin unreliable.

What would make this work reproducible?

Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.

Practice ladder

Basic

Recompute I and deflection with all units shown.

Intermediate

Increase load by 10% and quantify requirement margin.

Advanced

Define a verification case that combines analytical, FEA, and test evidence without treating them as identical.

AI-assisted engineering task

Ask AI to check variable names, units, and equation bindings, not to decide compliance.

How to prove the AI output yourself

Perform dimensional analysis.
Recalculate independently.
Check equation applicability and configuration.
Review uncertainty before final disposition.

Retrieval and spaced review

Answer closed-notes today, then again after 1, 3, 7, and 30 days.

Define Constraint relation.

An equation or rule connecting typed quantities and units.

What role does Analysis case play here?

A controlled definition of an analysis question and execution context.

What must a reviewer be able to reconstruct?

Units close, arithmetic reproduces, boundary condition matches the equation, and the requirement uses the same load and configuration.

End-of-lesson summary

Student notes

Record quantity name, symbol, unit, source, uncertainty, and binding for every value in the analysis case.

Connecting MBSE with CAD, CAE, optimization, and evidence

Why this lesson matters

Replacing every specialist tool with one model is unrealistic. The practical problem is preserving semantics and traceability across tool boundaries.

Learning objectives

Define and distinguish Tool boundary and Semantic mapping.
Apply the lesson method to the worked connecting mbse with cad, cae, optimization, and evidence case.
Evaluate evidence, uncertainty, and AI-assisted output before making a claim.

Readiness check

Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.

Check your response

A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.

Core idea

The system model should identify intent, interfaces, configurations, analyses, and evidence relationships while specialist tools retain authoritative detail. Integrations exchange controlled data through mappings, APIs, files, or links with validation checks.

Key concepts

Tool boundary	The point where information moves between repositories or representations.
Semantic mapping	An explicit correspondence between concepts, units, identifiers, and relationships in two schemas.
Co-simulation	Coordinated execution of models that exchange variables during a simulation.
Round trip	A controlled flow out to a tool and back without losing identity, meaning, or change history.

Step-by-step explanation

Assign authority for each data class and avoid duplicate uncontrolled masters.
Define stable identifiers and semantic mappings before automation.
Validate units, coordinate frames, revisions, and cardinality at exchange.
Record transformations, software versions, and execution results.
Test change propagation and failure behavior, including partial or stale updates.

Worked example

A system model owns a 2.0 kN interface load and CAD owns bracket geometry. An FEA preprocessor imports geometry and a CSV load, then optimization writes a thickness recommendation.

1
Map system load ID and coordinate frame to the FEA load object.
2
Map released CAD revision and material identifier to model inputs.
3
Record mesh and solver configuration as analysis-case evidence.
4
Return stress, displacement, and mass with units, configuration, and run ID.
5
Treat optimization thickness as a candidate design change requiring CAD update, re-analysis, and approval.

Result. The integration preserves authority and evidence without pretending the optimizer can directly release geometry.

Independent check. A changed load or CAD revision makes affected analysis and decision links visibly suspect rather than silently stale.

Common misconceptions

Misconception	Correction
Integration means copying all data into one tool	Useful integration may be federated; authority, mappings, and validated links matter more than physical centralization.
A tool output closes the question	A result remains a candidate until its inputs, method, configuration, uncertainty, and relevance have been checked.

Diagnostic questions

What is the status of an optimizer output?

A candidate recommendation until incorporated into controlled design and verified.

What would make this work reproducible?

Controlled inputs, method or code, versions, assumptions, outputs, and a stated interpretation tied to the decision.

Practice ladder

Basic

Assign authoritative ownership for six fields across requirements, system model, CAD, FEA, and test tools.

Intermediate

Write a mapping table for load magnitude, direction, application region, material, and thickness.

Advanced

Design recovery behavior for a failed partial update that changed CAD but not the FEA mesh.

AI-assisted engineering task

Ask AI to draft a mapping table from two documented schemas, with unknown fields left blank.

How to prove the AI output yourself

Test mappings on known reference cases.
Check units, frames, and identifiers automatically.
Review transformation logs and round-trip differences.

Retrieval and spaced review

Answer closed-notes today, then again after 1, 3, 7, and 30 days.

Define Tool boundary.

The point where information moves between repositories or representations.

What role does Semantic mapping play here?

An explicit correspondence between concepts, units, identifiers, and relationships in two schemas.

What must a reviewer be able to reconstruct?

A changed load or CAD revision makes affected analysis and decision links visibly suspect rather than silently stale.

End-of-lesson summary

Student notes

For each exchange, write source authority, target use, mapping version, validation rule, failure response, and owner.

Lab 4: Represent a minimal digital thread in JSON

Lab objective

Serialize requirements, parts, analyses, tests, decisions, and typed links in a versioned JSON structure.

Engineering context

A model-based workflow needs a tool-neutral interchange artifact before it can connect to specialist repositories.

Input data

Bracket nodes from Lab 3
Typed links
Schema version and configuration identifier

Step-by-step task

Create the JSON structure
Validate IDs and link endpoints
Query all evidence supporting one requirement
Round-trip through a JSON file and compare

Python code

import json

thread = {
    "schema_version": "1.0",
    "configuration": "BRACKET-C",
    "nodes": [
        {"id": "BRK-002", "type": "requirement", "status": "approved"},
        {"id": "CAD-C", "type": "geometry", "status": "released"},
        {"id": "R44", "type": "simulation", "status": "reviewed"},
        {"id": "T18", "type": "test", "status": "planned"},
        {"id": "D3", "type": "decision", "status": "conditional"},
    ],
    "links": [
        {"source": "R44", "type": "supports", "target": "BRK-002"},
        {"source": "T18", "type": "verifies", "target": "BRK-002"},
        {"source": "BRK-002", "type": "informs", "target": "D3"},
    ],
}

ids = {node["id"] for node in thread["nodes"]}
assert len(ids) == len(thread["nodes"])
for link in thread["links"]:
    assert link["source"] in ids and link["target"] in ids
payload = json.dumps(thread, indent=2, sort_keys=True)
restored = json.loads(payload)
assert restored == thread
print(payload)

Explanation of code

Step 1 create the JSON structure Step 2 validate IDs and link endpoints Step 3 query all evidence supporting one requirement Step 4 round-trip through a JSON file and compare

Expected output

A stable, indented JSON document and no assertion failures.

Interpretation

JSON provides structure, not governance. Authority, revision history, permissions, review, and persistence require additional design.

Common errors

Using labels instead of stable IDs
Allowing links to missing endpoints
Omitting schema and configuration versions

Extension tasks

Add JSON Schema validation
Store the graph in SQLite
Record link rationale, status, and reviewer

Reflection questions

What does JSON solve?
What does it not solve?
How would schema migration be controlled?

WEEK 4

Weekly quiz and concept check

Closed notes. Answer each item, then use the key to correct in a different color.

What is MBSE?
What is a diagram in MBSE?
Name SysML concept families used here.
Distinguish a constraint relation from an analysis result.
Who owns detailed geometry?
Why validate tool mappings?

Answer key

1. Systems engineering using governed models as a primary means of representation, analysis, communication, and control.
2. A stakeholder view of selected model elements and relationships.
3. Requirements, structure, behavior, interfaces, analysis cases, and verification cases.
4. The relation defines an equation; a configured execution binds values and produces a result.
5. Usually the controlled CAD or PLM source, with the system model linking to it and its relevant properties.
6. Similar field names can hide different units, frames, identifiers, semantics, or revisions.

SOURCES

Module source map

Source	How it is used
OMG SysML 2.0 Specification	Practical representation of requirements, structure, behavior, analysis cases, and verification cases.
NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev. 2	Lifecycle processes, requirements, interfaces, technical decisions, reviews, verification, and validation.
INCOSE Systems Engineering Handbook, version 5	Systems engineering lifecycle processes and state-of-good-practice context.
DoDI 5000.97, Digital Engineering	Operational definitions of digital engineering, digital models, digital artifacts, authoritative data, test, and sustainment.

Access labels and full-course source notes are on the course home page. Paywalled standards are not paraphrased as if their full text were accessed.

Module map

Learning outcomes

Evidence standard

MBSE as a governed modeling practice

Why this lesson matters

Learning objectives

Readiness check

Key concepts

Step-by-step explanation

Worked example

Common misconceptions

Diagnostic questions

Practice ladder

AI-assisted engineering task

How to prove the AI output yourself

Retrieval and spaced review

End-of-lesson summary

Student notes

Recommended readings

Instructor notes

Practical SysML concepts: requirements, structure, behavior, and interfaces

Why this lesson matters

Learning objectives

Readiness check

Key concepts

Step-by-step explanation

Worked example

Common misconceptions

Diagnostic questions

Practice ladder

AI-assisted engineering task

How to prove the AI output yourself

Retrieval and spaced review

End-of-lesson summary

Student notes

Recommended readings

Instructor notes

Parametric models, analysis cases, and verification cases

Why this lesson matters

Learning objectives

Readiness check

Key concepts

Step-by-step explanation

Worked example

Common misconceptions

Diagnostic questions

Practice ladder

AI-assisted engineering task

How to prove the AI output yourself

Retrieval and spaced review

End-of-lesson summary

Student notes

Recommended readings

Instructor notes

Connecting MBSE with CAD, CAE, optimization, and evidence

Why this lesson matters

Learning objectives

Readiness check

Key concepts

Step-by-step explanation

Worked example

Common misconceptions

Diagnostic questions

Practice ladder

AI-assisted engineering task

How to prove the AI output yourself

Retrieval and spaced review

End-of-lesson summary

Student notes

Recommended readings

Instructor notes

Lab 4: Represent a minimal digital thread in JSON

Lab objective

Engineering context

Input data

Step-by-step task

Python code

Explanation of code

Expected output

Interpretation