Model-Based Engineering, Digital Twins and Optimization

Introduction and Context

Modern mechatronic products combine mechanical structures, electronics, sensors, actuators, embedded software, communications, and human interaction. Their behaviour is therefore determined not by one discipline but by interactions across disciplines and across the product life cycle. A motor controller may be electrically correct but mechanically unstable; a mechanically efficient mechanism may consume excessive energy because of poor control logic; and a low-cost design may be unreliable because thermal, software, and maintenance effects were not considered together.

Model-based engineering (MBE) addresses this problem by treating models as primary engineering artefacts. Instead of relying mainly on documents and physical prototypes, engineers use interconnected models to specify requirements, represent architecture, predict behaviour, verify designs, and support operation. Digital twins extend this idea by linking a computational model to an identifiable physical asset or process through operational data. Optimization then explores alternatives systematically so that performance, cost, energy consumption, safety, and maintainability can be considered together.

These methods do not eliminate engineering judgement. They make assumptions explicit, expose trade-offs earlier, and provide evidence for design decisions.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Explain the principles and workflow of model-based systems engineering (MBSE).
2. Distinguish system, simulation, surrogate, and digital-twin models.
3. Select appropriate software-in-the-loop, processor-in-the-loop, and hardware-in-the-loop methods.
4. Formulate a design-space exploration or optimization problem with constraints and measurable objectives.
5. Interpret Pareto-optimal solutions and make defensible engineering decisions.
6. Identify model-validity, data-quality, cybersecurity, safety, and governance risks.

1. Model-Based Systems Engineering

1.1 From document-centric to model-centric engineering

In document-centric development, requirements, drawings, test reports, software specifications, and calibration data are often maintained separately. Interfaces may be described inconsistently, and a change in one subsystem may not be propagated to all affected artefacts. MBSE instead constructs a connected system model containing requirements, stakeholders, functions, logical components, physical components, interfaces, states, constraints, and verification cases.

A useful MBSE chain is:

Need → Requirement → Function → Logical architecture → Physical architecture → Implementation → Verification → Validation

A requirement states what the system must achieve. A function describes what must happen without prematurely prescribing a physical solution. The logical architecture allocates functions to interacting logical elements. The physical architecture maps those elements to motors, sensors, processors, mechanisms, networks, and software. Verification asks whether the design was built correctly against its specifications; validation asks whether the correct system was built for its intended use.

MBSE commonly uses systems-modelling languages and tools to represent relationships rather than merely storing isolated text. The exact notation is less important than disciplined semantics: each requirement should be traceable to design elements and verification evidence.

1.2 System boundaries and interfaces

A model must define its boundary. For an autonomous mobile robot, the boundary may include the vehicle, embedded controller, battery, sensors, and software, while excluding the warehouse floor. Alternatively, the floor and wireless infrastructure may be included if their behaviour affects requirements.

Interfaces deserve special attention because many failures occur between domains. An interface specification should identify:

• exchanged energy, material, information, or mechanical loads;
• direction and timing of signals;
• units, ranges, resolution, and sampling rate;
• communication protocol and failure behaviour;
• ownership and verification responsibility.

For example, a temperature signal described as “temperature” is incomplete. The model should specify whether it is in °C or K, whether it is filtered, its valid range, update period, sensor bias, and response to disconnection.

1.3 Traceability and change impact

Traceability links a need to requirements, requirements to architecture, architecture to implementation, and implementation to tests. A traceability matrix can reveal unverified requirements, redundant tests, or components that have no stated purpose. When a requirement changes, the model can identify affected interfaces, simulations, test cases, and safety analyses.

Traceability is not automatically beneficial. Poorly defined links can create a large but meaningless network. Each relationship should answer a useful question such as “Which test verifies this requirement?” or “Which requirement constrains this parameter?”

2. Engineering Models and Their Fidelity

A model is a purposeful representation of a system. It is neither automatically true nor automatically useful. Model fidelity is the degree to which relevant behaviour is represented accurately for a stated purpose. A high-fidelity model is not always preferable: it may be slow, difficult to calibrate, and unnecessary for early design exploration.

Important model categories include:

2.1 A simple dynamic model

Many mechatronic systems can be represented in state-space form:

Here, x(t) is the state vector, u(t) is the control input, p is a vector of parameters, d(t) represents disturbances, y(t) is the measured output, and f and g are state-transition and output functions. The model assumes that the selected states contain sufficient information to predict future behaviour and that the functions are defined over the operating region of interest. Units must be consistent: for example, position may be in m, velocity in m/s, force in N, and time in s.

For a translational mass–damper–spring system, Newton’s law gives:

where m is mass in kg, c is damping coefficient in N·s/m, k is stiffness in N/m, x is displacement in m, and F is applied force in N. The equation assumes a linear spring, viscous damping, and one-dimensional motion. Nonlinear friction, geometric effects, saturation, and backlash require additional terms or a different model.

The natural frequency of the undamped system is:

where ωₙ is in rad/s. This expression is applicable to the ideal undamped linear model. It should not be used without qualification when damping, nonlinear stiffness, or multiple coupled modes dominate.

2.2 Verification, validation, and uncertainty

Verification examines implementation correctness: for example, whether a simulation solves the intended equations. Validation examines adequacy for the real-world question: for example, whether the model predicts a robot arm’s settling time within an acceptable tolerance.

Model validation requires representative data. A model calibrated only with low-speed motion may fail at high speed because friction, structural flexibility, and motor heating change. Uncertainty should be documented as parameter ranges, measurement error, model-form uncertainty, and uncertain operating conditions.

A basic relative error for a measured quantity is:

where yₘ is the measured value and yₚ is the predicted value. The expression is meaningful when yₘ is non-zero and the quantities have the same units. It should not be the only validation measure: absolute error, dynamic waveform comparison, bias, phase error, and requirement-specific acceptance limits may be more appropriate.

3. Simulation-Based Development and HIL

Simulation enables engineers to test conditions that are expensive, dangerous, rare, or difficult to reproduce physically. However, simulation results are conditional on model assumptions, numerical methods, parameters, and initial conditions.

3.1 Software-in-the-loop

In software-in-the-loop (SIL), control software—often compiled for a development computer—interacts with a simulated plant. SIL is useful for control algorithms, state machines, fault handling, and regression testing before hardware is available. It is fast and inexpensive, but it may not reveal processor timing, sensor electrical effects, quantization, communication delays, or hardware-specific faults.

3.2 Processor-in-the-loop

Processor-in-the-loop (PIL) executes the algorithm on the intended processor or a representative processor while the plant remains simulated. PIL exposes numerical precision, execution time, memory limits, and compiler effects. It is more realistic than SIL but still does not reproduce the complete electrical and physical environment.

3.3 Hardware-in-the-loop

In hardware-in-the-loop (HIL), real controller hardware is connected to a real-time plant simulator. The simulator must compute each plant step within the required sample interval. If the sample period is Tₛ, the real-time computation and communication must complete within Tₛ, with sufficient margin. A missed deadline can produce an artificial failure or conceal a real one.

HIL can test sensor failures, actuator saturation, battery faults, network delays, emergency states, and extreme operating conditions without exposing equipment or people to the full hazard. Signal conditioning, scaling, latency, and electrical loading must nevertheless be modelled or reproduced correctly.

3.4 Choosing a simulation level

A robust verification strategy uses all four levels rather than treating HIL as a replacement for physical testing.

4. Digital Twins

A digital twin is a computational representation connected to a particular physical asset, process, or system through data flows over a relevant part of its life cycle. A static CAD model is not necessarily a digital twin. A simulation disconnected from a real asset is usually a digital model or digital shadow, depending on the direction of data exchange.

A practical twin architecture includes:

1. Physical layer: asset, sensors, actuators, operators, and environment.
2. Connectivity layer: wired or wireless communication, gateways, time synchronization, and data management.
3. Digital layer: physics models, data-driven models, state estimation, simulation, and visualization.
4. Decision layer: diagnostics, prognostics, optimization, control recommendations, and work orders.
5. Governance layer: identity, access control, cybersecurity, versioning, provenance, and audit records.

Figure: Information flow in a digital-twin architecture.

4.1 State estimation and predictive maintenance

Sensor measurements rarely reveal every internal state. A state estimator combines a model with measurements to estimate quantities such as bearing degradation, battery state of charge, or joint friction. A simple discrete model is:

where A, B, and C are system matrices, wₖ is process uncertainty, and vₖ is measurement noise. Linear estimators such as the Kalman filter require suitable linear or locally linear models and assumptions about noise statistics. Nonlinear systems may require extended or unscented variants, particle filters, or other estimation methods.

Predictive maintenance should not be equated with “replace when a model predicts failure.” A maintenance decision must consider prediction uncertainty, consequence of failure, inspection cost, spares, safety, and regulatory requirements.

5. Design-Space Exploration and Optimization

Design-space exploration (DSE) evaluates alternative architectures, component selections, controller parameters, and operating strategies. Variables may be continuous, discrete, categorical, or mixed. Examples include gear ratio, motor rating, battery capacity, sampling period, material choice, and control gains.

A constrained optimization problem can be written as:

Here z is the design vector, J is a vector of q objectives, gᵢ are inequality constraints, hⱼ are equality constraints, and zᴸ and zᵁ are lower and upper bounds. Units and scaling must be considered when objectives are combined.

Typical objectives include mass, purchase cost, energy use, tracking error, noise, and reliability risk. Constraints may include maximum temperature, settling time, actuator force, battery voltage, safety factor, manufacturability, and communication bandwidth.

5.1 Single-objective and multi-objective optimization

A weighted-sum formulation is:

where Jᵢⁿ are normalized objectives and wᵢ are non-negative weights. The weights must be justified, and normalization is essential when objectives have different units. A weighted sum may fail to identify some Pareto solutions, particularly on non-convex fronts.

A design zᵃ dominates zᵇ if it is no worse in every objective and strictly better in at least one, assuming minimization. A Pareto-optimal design is not dominated by any feasible design. The Pareto front shows the trade-off between competing objectives; it does not automatically identify one final product.

5.2 Optimization workflow

1. Define the decision, objectives, constraints, and operating scenarios.
2. Identify variables, ranges, discrete choices, and unavailable combinations.
3. Select a model appropriate to the required speed and accuracy.
4. Sample the design space using a planned experiment or space-filling design.
5. Evaluate, validate, and record results with configuration and random seeds.
6. Construct surrogate models when direct simulation is expensive.
7. Search for feasible and Pareto-efficient designs.
8. Re-simulate promising candidates using higher-fidelity models.
9. Perform sensitivity, robustness, manufacturability, and lifecycle analysis.
10. Document the decision and assumptions.

Surrogate models can be polynomial, response-surface, Gaussian-process, neural-network, or other regressors. They must be validated on data not used for fitting. Extrapolation beyond the training region is especially dangerous.

5.3 Robustness and sensitivity

An optimum under nominal parameters may perform badly when friction, payload, temperature, or supply voltage varies. Robust design seeks acceptable performance across uncertainty. Sensitivity analysis asks how much outputs change when inputs change. A local normalized sensitivity can be expressed as:

where y is an output and p is a parameter, with non-zero y and p and sufficiently small changes for a local approximation. A large magnitude of S indicates that the output is sensitive to that parameter. Global sensitivity methods are preferable for nonlinear systems with interactions.

6. Worked Example: Selecting a Motor–Gearbox Design

Consider an illustrative conveyor axis requiring a constant linear speed of 0.50 m/s and a drum radius of 0.05 m. Neglecting slip, the drum speed is:

Suppose three feasible designs are evaluated using a validated simulation. Their results are:

Assume allowable temperature is 80 °C and tracking error must not exceed 1.5 mm. Design C is infeasible because 83 °C exceeds the thermal constraint. Design A is feasible but is dominated by B: B costs more, but uses less energy and has lower tracking error; therefore A is not automatically dominated because it is cheaper, yet it represents a cost–performance trade-off. The feasible Pareto set is A and B. If energy is valued at $0.20 per kWh and the axis completes 1000 cycles, the energy difference is 60 kJ per cycle, or 60,000 kJ overall:

The operating-energy saving is approximately $3.33, so energy cost alone does not recover B’s additional $40 purchase cost in this short scenario. However, longer operating life, reduced tracking losses, or lower maintenance risk could change the decision. This illustrates why optimization outputs require lifecycle and stakeholder interpretation rather than selection by one metric alone.

The calculation assumes the listed energy is repeatable, the cycle count is representative, and energy price is constant. It excludes installation, maintenance, downtime, and disposal costs.

7. Illustrative Case Study: Digital Twin for a Robotic Assembly Cell

Background

A manufacturer operates a six-axis robot that inserts components into housings. Unplanned stops arise from gripper wear, variable part tolerances, and occasional controller alarms. Physical experiments interrupt production and provide limited information about rare faults.

Problem

The company needs to reduce downtime while maintaining insertion accuracy and operator safety. It also wants to compare alternative gripper materials and motion profiles before purchasing hardware.

Analysis

The engineering team defines requirements for cycle time, insertion force, positional accuracy, allowable motor temperature, and safe response to a sensor failure. A kinematic and dynamic robot model is connected to production data. Measured joint positions and motor currents are time-synchronized with fault codes. A state estimator tracks friction-related changes, while a reduced-order contact model predicts insertion force.

The model is first verified against known trajectories, then validated using production runs not used for calibration. HIL testing subjects the real controller to simulated encoder dropouts, excessive force, communication delay, and thermal overload. DSE varies gripper stiffness, approach speed, force limit, and controller gains. Objectives are cycle time, energy per cycle, and predicted wear; constraints include force, temperature, accuracy, and safety response time.

Approach and solution

The team retains several Pareto-efficient designs rather than selecting the fastest design. A moderate-speed motion profile reduces energy and predicted wear while meeting cycle-time requirements. A dashboard displays asset-specific condition estimates, model confidence, and recommended inspection intervals. Any automated command requires authorization and an independent safety system remains responsible for protective stops.

Outcome

The approach reduces physical trial iterations and identifies a design that meets accuracy and temperature limits with lower predicted wear. The exact numerical benefit would require measured plant data; the important result is the decision process: traceable requirements, validated models, controlled experiments, and explicit uncertainty.

Learning points

• A digital twin is valuable only when its data, model, identity, and purpose are controlled.
• HIL reveals timing and fault behaviour that ordinary offline simulation may miss.
• A Pareto set supports decision-making; it does not replace it.
• Safety functions must not depend solely on a predictive or cloud-based twin.

8. Professional Practice, Governance, and Limitations

8.1 Data and model governance

Every operational model should have an owner, version, validity range, calibration history, data lineage, and change-approval process. Time stamps, units, sensor quality, missing values, and synchronization errors must be recorded. A model that silently changes after software or parameter updates cannot provide defensible evidence.

8.2 Cybersecurity and privacy

Connected twins enlarge the attack surface. Threats include forged sensor data, unauthorized commands, ransomware, intellectual-property theft, and denial of service. Controls include asset identity, least-privilege access, encryption, network segmentation, secure update mechanisms, logging, vulnerability management, and incident response. Industrial systems should be designed with relevant functional-safety and industrial-cybersecurity standards in mind; the applicable standard depends on sector, jurisdiction, and risk assessment.

8.3 Safety and ethical responsibility

Optimization can produce unsafe solutions if safety is represented as an informal preference rather than a hard constraint. Engineers must distinguish acceptable performance from unacceptable risk. Human operators should understand when a recommendation is automated, uncertain, or based on extrapolation. Data-driven models can encode bias—for example, if data represent only healthy machines or one environmental condition. Accountability remains with the organization and qualified professionals, not with an opaque algorithm.

8.4 Limitations

MBE requires upfront modelling effort, consistent terminology, tool interoperability, and trained personnel. Digital twins can be expensive to instrument and maintain. Real-time models may simplify rare but important phenomena. Optimization can exploit errors in a simulation (“model gaming”), and a mathematically optimal design may be impossible to manufacture or service. These limitations are managed through staged fidelity, independent review, physical validation, uncertainty analysis, and lifecycle thinking.

9. Contemporary Developments and Best Practices

Cloud and edge computing allow twins to combine local real-time control with remote analytics. Machine learning is increasingly used for anomaly detection, surrogate modelling, parameter estimation, and remaining-useful-life prediction. Physics-informed and hybrid models aim to combine conservation laws with measured data. Generative design and automated experiment planning can accelerate exploration, but generated alternatives still require engineering constraints and verification.

Best practice is to:

• begin with a decision and measurable value, not technology for its own sake;
• define the system boundary, assumptions, units, and validity range;
• maintain requirement-to-test traceability;
• use the lowest model fidelity that answers the question, then validate critical decisions at higher fidelity;
• include uncertainty, failure modes, and safety constraints from the beginning;
• separate training, validation, and test data for data-driven models;
• preserve configurations, seeds, parameter sets, and simulation logs;
• combine SIL, PIL, HIL, and physical tests;
• present Pareto alternatives with lifecycle consequences;
• monitor model drift after deployment and retire models that are no longer valid.

Chapter Summary

Model-based engineering provides a connected representation of requirements, functions, architectures, interfaces, implementation, and verification. It improves traceability and supports controlled change across the mechatronic product life cycle. Engineering models must be selected and validated for a stated purpose; greater fidelity is not automatically better.

SIL, PIL, and HIL progressively introduce implementation, processor, timing, and hardware realism before full physical testing. A digital twin links a model to a particular physical asset through governed data and supports monitoring, prediction, maintenance, and decision-making. State estimation is often necessary because important internal conditions cannot be measured directly.

Design-space exploration evaluates alternatives systematically. Multi-objective optimization represents competing goals such as cost, energy, accuracy, temperature, and reliability. Feasibility, dominance, Pareto optimality, robustness, sensitivity, manufacturability, and lifecycle effects must all be considered. Finally, cybersecurity, safety, data provenance, model drift, uncertainty, and professional accountability are essential to responsible deployment.

Key Terms

Model-based engineering: Engineering practice in which interconnected models are primary development artefacts.

Model-based systems engineering: Application of model-based methods to requirements, architecture, behaviour, verification, and life-cycle systems engineering.

Traceability: A documented relationship linking needs, requirements, designs, implementations, and tests.

Verification: Demonstration that an artefact satisfies its specified requirements.

Validation: Demonstration that a system is suitable for its intended real-world purpose.

Model fidelity: Degree to which a model represents relevant system behaviour for a stated use.

State-space model: Representation using state-transition and output equations.

Software-in-the-loop: Testing software with a simulated plant on a development computer.

Processor-in-the-loop: Testing an algorithm on a target or representative processor with a simulated plant.

Hardware-in-the-loop: Testing real controller hardware against a real-time simulated plant.

Digital twin: A model connected through data to a particular physical asset or process.

State estimation: Inferring unmeasured system states from models and measurements.

Design-space exploration: Systematic evaluation of alternative design variables and configurations.

Surrogate model: An efficient approximation of an expensive simulation or experiment.

Objective function: Quantitative measure to minimize or maximize in an optimization problem.

Constraint: Equality, inequality, or bound that limits acceptable designs.

Pareto dominance: Condition in which one feasible solution is no worse in all objectives and better in at least one.

Robust design: Design that maintains acceptable performance under uncertainty and variation.

Model drift: Reduction in model validity as the asset, environment, or data distribution changes.

Data provenance: Record of the origin, transformation, timing, and ownership of data.

Review Questions

Short Answer Questions

1. What is the principal difference between verification and validation?
2. Why are interfaces particularly important in MBSE?
3. State one advantage and one limitation of HIL simulation.
4. What makes a digital twin different from a disconnected simulation model?
5. Define Pareto optimality in a minimization problem.

Long Answer Questions

1. Explain an MBSE workflow from stakeholder need through physical validation, including the role of traceability.
2. Compare SIL, PIL, HIL, and physical testing in terms of realism, cost, and faults revealed.
3. Describe the architecture and governance requirements of a digital twin for predictive maintenance.
4. Formulate a multi-objective optimization problem for a mechatronic product and justify suitable constraints.
5. Discuss why model validation, uncertainty analysis, and cybersecurity are necessary for trustworthy engineering decisions.

Analytical / Application Questions

1. A design has low energy consumption but violates a maximum-temperature requirement. Explain why it cannot be selected as a feasible optimum and propose two ways to redesign or reassess it.
2. A robot twin predicts bearing failure using data collected only at low payload. Analyze the validity risks and design a validation plan for higher payloads.
3. Three Pareto-efficient motor designs differ in cost, energy, accuracy, and maintenance risk. Propose a decision method that includes lifecycle cost, uncertainty, safety, and stakeholder preferences.

Multiple Choice Questions with Answers

Question 1

Which sequence best represents a typical MBSE development chain?

A. Need → requirement → function → architecture → verification

B. Verification → need → procurement → function → validation

C. Architecture → disposal → requirement → need → simulation

D. Cost → software → need → marketing → verification

Correct Answer: A. Need → requirement → function → architecture → verification

Question 2

In the state-space model ẋ(t) = f(x(t), u(t), p, d(t), t), what does u(t) normally represent?

A. The measured output

B. The control input

C. The parameter uncertainty

D. The model error

Correct Answer: B. The control input

Question 3

Which simulation method executes the control algorithm on the intended processor while the plant remains simulated?

A. SIL

B. PIL

C. HIL

D. Physical validation

Correct Answer: B. PIL

Question 4

Which statement about a digital twin is most accurate?

A. It is always identical to a CAD model

B. It must be connected to a specific physical asset or process through relevant data

C. It can operate without asset identity or data provenance

D. It replaces all physical safety systems

Correct Answer: B. It must be connected to a specific physical asset or process through relevant data

Question 5

For the linear mass–spring model mẍ + cẋ + kx = F(t), which unit is appropriate for the stiffness coefficient k?

A. N/m

B. N·s/m

C. kg/m

D. m/N

Correct Answer: A. N/m

Question 6

A solution dominates another in a minimization problem when it is:

A. Worse in every objective

B. No worse in every objective and strictly better in at least one

C. Equal in every objective and infeasible

D. Better in one objective regardless of all constraints

Correct Answer: B. No worse in every objective and strictly better in at least one

Question 7

Why must objective functions with different units generally be normalized before a weighted sum is formed?

A. To remove all engineering meaning

B. To make numerical scales comparable

C. To guarantee a global optimum

D. To eliminate constraints

Correct Answer: B. To make numerical scales comparable

Question 8

A design requires a temperature no greater than 80 °C. A candidate reaches 83 °C. What is the correct classification?

A. Feasible and dominant

B. Infeasible unless the temperature constraint is changed or the design is modified

C. Pareto optimal automatically

D. Validated because the error is only 3 °C

Correct Answer: B. Infeasible unless the temperature constraint is changed or the design is modified

Question 9

What is a major risk of using a surrogate model outside the region represented by its training data?

A. Guaranteed improvement in accuracy

B. Unsafe extrapolation and misleading optimization results

C. Automatic elimination of uncertainty

D. Removal of the need for physical testing

Correct Answer: B. Unsafe extrapolation and misleading optimization results

Question 10

Which practice best supports trustworthy deployment of an engineering digital twin?

A. Changing model parameters without recording them

B. Using only nominal data and ignoring faults

C. Maintaining versioning, data provenance, validity limits, and independent validation

D. Allowing the twin to bypass independent safety functions

Correct Answer: C. Maintaining versioning, data provenance, validity limits, and independent validation