Digital Engineering Foundations · Module 4 of 8
Models and Model-Based Engineering
A model is not the truth; it is a purposeful representation with limits. Treat every engineering model as a controlled artifact with a purpose, scope, assumptions, inputs, outputs and owner, then connect it to the requirements and architecture it informs.
Readiness check
Building on Modules 1–3. Tick only what you can do closed-notes.
- Name a model you have used and explain what it leaves out.
- Identify one input and one output of that model.
- Identify the idealizations in a hand calculation.
- Read a simple block diagram.
- Distinguish a requirement from a component.
The core idea
An engineering model is a purposeful representation of something real, proposed or abstract, useful as digital evidence only when its purpose, scope, assumptions, inputs, outputs, configuration and owner are visible.
A model may be geometric, mathematical, behavioral, physical, statistical or procedural. Most model misuse begins when a result built for one question is reused for a different question without review. Model-based engineering connects those governed models, requirements, structure, behavior, analysis and verification views, so a CAD model, stress model, thermal model and test model can describe the same subsystem from different viewpoints, none of them the whole truth.
The skills, taught in order
Four steps: treat models as artifacts, state purpose and assumptions, connect models to requirements and architecture, and read model-based systems engineering at a literacy level.
4.1 Models as engineering artifacts
State the model purpose before using it, record what the model represents and what it omits, connect inputs and outputs to controlled artifacts, and assign ownership and review status. A CAD model represents geometry and interfaces, not automatically material strength or manufacturing quality. A beam model may capture first-order stiffness but not local bolt contact or 3D stress concentration. Adequacy depends on purpose, not size.
4.2 Model purpose, scope and assumptions
A purpose statement names the question, decision and acceptable use ("estimate whether bracket thickness options are worth detailed analysis, not a release-level proof"). Scope defines where the model applies; assumptions state simplifications, fixed values and idealizations. Visible assumptions make a model reviewable rather than weak. Set input and output boundaries, list the assumptions that control the result, and create review triggers so previous model evidence is re-inspected after a geometry or load change.
4.3 Connecting requirements, architecture and analysis
Models support digital engineering when they connect to the requirements, functions, components and interfaces they inform. Link each model to the requirement it informs and to the architecture element it analyses, record model outputs as evidence candidates, and use a model register to prevent orphan analyses. "The beam stress model analyses component BRK-ARM and supports requirement REQ-LOAD" is a linked, useful analysis; an unlinked analysis may be interesting but weak as project evidence.
4.4 MBSE and SysML awareness for mechanical engineers
Model-based systems engineering uses governed models to represent system information and relationships across the lifecycle. SysML is a general-purpose modeling language covering requirements, structure, behavior, analysis cases and verification cases. The goal here is literacy: read model elements as engineering information and know what such models connect, not detailed SysML syntax or a commercial tool. The value is in governed model information and controlled relationships, not box art, and basic literacy helps your CAD, CAE and test evidence connect to system requirements.
Lab & connections. Lab 4 builds a model register. Model credibility, validation and uncertainty are developed in Module 5 and, in depth, in the dedicated VVUQ course. For SysML detail, see the OMG SysML specification.
Worked example 1: is this model fit for the decision?
A student uses a simple beam bending model to argue the bracket "passes." Decide whether the model is fit for that decision.
- ProblemJudge whether a first-order beam model can support a release-level pass/fail claim for the bracket.
- Given / findModel: cantilever beam, uniform section, linear-elastic, point load at the payload. Decision sought: "the bracket passes the 600 N static requirement for release." Find the fit-for-purpose gap.
- ModelFit-for-purpose = the model's scope and assumptions cover the physics that controls the decision, at the required credibility.
- SolveThe beam model captures gross bending stiffness and nominal stress. It omits the bolt-hole stress concentration, contact at the mounting face, and any 3D load path, exactly where a bracket usually fails. So it is a valid screening model ("is this thickness worth detailed analysis?") but not a release-level proof.
- CheckRecord the purpose as "screening," list the omitted effects as assumptions, and set a review trigger: a release claim needs a model whose scope includes the stress concentration (FEA) plus the analysis-baseline provenance from Module 2.
- ConclusionThe model is not wrong; the claim is out of scope. Naming the purpose prevents a screening result from being quoted as a release proof.
Worked example 2: catching an orphan model
A model register lists four analyses. Find the orphan model and connect the rest to requirements and architecture.
- ProblemUse the model register to ensure every analysis answers a real obligation.
- Given / findModels: MOD-STRESS (beam), MOD-CLEAR (CAD envelope), MOD-THERMAL (lumped), MOD-MODAL (first mode). Requirements: REQ-LOAD, REQ-CLEAR (payload clearance), interface REQ-FIT. Find links and any orphan.
- ModelEach model should link to the requirement it informs and the architecture element it analyses; an orphan is a model tied to no requirement or decision.
- SolveMOD-STRESS analyses BRK-ARM, supports REQ-LOAD. MOD-CLEAR verifies interface clearance, supports REQ-CLEAR (but does not verify yield stress). MOD-MODAL informs a dynamics concern only if a vibration requirement exists. MOD-THERMAL supports no listed requirement → orphan: either add the missing thermal requirement it was meant to inform, or remove it from the evidence set.
- Check"One model can answer everything" is false, clearance ≠ strength. Each link states what the model does and does not prove.
- ConclusionA model register with required links turns a pile of analyses into an inspectable evidence set and exposes work that answers no question.
Misconceptions and diagnostics
| Mistake | Diagnostic question | Correction |
|---|---|---|
| The most detailed model is best | "What decision is being supported?" | Adequacy depends on purpose, not size. |
| A model is the truth | "What assumptions and data support it?" | A model is a representation with limits. |
| Assumptions are weaknesses | "Could the model be understood without them?" | Visible assumptions make a model reviewable. |
| One model can answer everything | "Does it include geometry, physics, controls, manufacturing and use?" | Different questions need different model viewpoints. |
| MBSE is drawing boxes | "Are relationships, semantics and configuration controlled?" | The value is governed model information, not box art. |
Practice ladder
List four model types in the bracket project, state purpose and owner for each, and record one assumption per model. Mark which model output supports which requirement.
Show answer
CAD (geometry, Design owner), stress (screening, CAE owner), clearance (interface check), modal (first mode), each with a purpose, an owner and one controlling assumption, and each output tied to a requirement or marked "screening only."
Write a purpose statement for a stress model, then its scope and three assumptions, name one use outside scope, and define a review trigger after a geometry change.
Show answer
Purpose is a decision-support sentence; scope names the domain; assumptions are the simplifications that control the result; the out-of-scope use is quoting a screening result as a release proof; the trigger fires model review when geometry or load changes.
Link three models to requirements and two to architecture elements, find one orphan model in the lab data, and write one model-output evidence statement.
Show answer
Good work uses the model register, states each link's meaning, names the orphan (no requirement/decision), and writes an evidence statement that includes the model's configuration and what it does not prove.
Build a small model register for one real subsystem, with purpose, scope, assumptions and requirement links for every model, and a lightweight architecture-and-verification relationship sketch.
What good work looks like
No orphan models, each with a purpose and controlling assumptions, linked to requirements and architecture, the model layer of the Module 8 digital thread.
Working with AI, and proving it yourself
Use AI as an examiner, not a solver
Portfolio task
Ask AI to draft a model description and challenge its assumptions, then verify every technical assumption yourself and record the model's purpose, scope, inputs, outputs and owner in the register.
Retrieval and spaced review
Closed notes. Answer out loud, then reveal.
1. What is a model?
A purposeful representation used to answer a question or support a decision.
2. Why record model scope?
Scope tells reviewers where the model is meaningful and where it is not.
3. What does a model purpose statement name?
The question, the decision and the intended use.
4. What is an orphan model?
A model not clearly tied to a requirement, artifact or decision.
5. What is the course goal for MBSE and SysML?
Awareness and literacy, reading governed model information and relationships, not full notation training.