Simulation Tools, MBSE and Co-Simulation

Introduction

Modern mechatronic products are developed through the interaction of mechanical, electrical, electronic, control, software, and communication subsystems. A robotic actuator, autonomous vehicle, medical instrument, or industrial machine cannot be represented adequately by a single engineering discipline. Simulation tools therefore serve two related purposes: they predict the behaviour of a design before physical construction, and they provide a common technical language through which specialists can collaborate.

This chapter examines practical environments and methods for implementing mechatronic models. It focuses on MATLAB/Simulink, Simscape, Modelica, model-based systems engineering (MBSE), SysML, the Functional Mock-up Interface (FMI), application programming interfaces (APIs), version control, and reproducible workflows. The central concern is not merely how to draw a block diagram, but how to create models that are traceable, exchangeable, testable, maintainable, and sufficiently credible for engineering decisions.

A useful distinction is between a model and a simulation. A model is a representation of a system, its structure, and its governing relationships. A simulation is the execution of that model under specified inputs, parameters, initial conditions, and numerical settings. Changing a solver, time step, parameter set, or interface can change simulation results even when the underlying physical model is unchanged.

Learning objectives

After studying this chapter, students should be able to:

1. Select appropriate simulation environments for physical, control, and system-level models.
2. Implement continuous-time, discrete-time, and physical-network models in MATLAB/Simulink, Simscape, or Modelica.
3. Explain how MBSE and SysML connect requirements, architecture, behaviour, and verification.
4. Describe FMI-based model exchange and co-simulation, including synchronization and interface limitations.
5. Design practical data exchanges using APIs and structured files.
6. Apply version control, configuration management, testing, and reproducibility principles to simulation projects.
7. Evaluate model credibility, numerical limitations, cybersecurity concerns, and ethical risks.

1. Simulation environments for mechatronic engineering

1.1 Signal-flow and physical-network modelling

In a signal-flow model, blocks transform explicit input signals into output signals. This approach is natural for controllers, filters, logic, and software algorithms. MATLAB/Simulink is widely used for this purpose. A plant may be represented by transfer functions, state-space equations, lookup tables, or custom code.

A continuous-time state-space model is commonly written as:

Here, x(t) is the state vector, u(t) is the input vector, y(t) is the output vector, and A, B, C, and D are system matrices of compatible dimensions. The model assumes that the selected states contain sufficient information to determine future behaviour and that the relationships are linear and time-invariant over the operating range. For nonlinear systems, the general form is:

Physical-network modelling represents components through physical variables and conservation laws. Simscape and Modelica follow this philosophy. A hydraulic component, for example, is connected through pressure and flow variables; an electrical component through voltage and current; and a mechanical translational component through force and velocity. The modeller specifies component relationships and connections, while the tool assembles the governing equations.

This distinction is important. Signal-flow models make causality explicit: one block computes an output from an input. Physical models can support acausal modelling, in which equations describe relationships without requiring the modeller to decide in advance which variable is computed. The solver and equation-processing system determine a computational solution after all connections are known.

1.2 MATLAB and Simulink

MATLAB provides numerical computation, data analysis, parameter studies, optimization, plotting, and scripting. Simulink provides a graphical environment for interconnected dynamic systems. Together they are especially useful when a project requires:

• controller development and tuning;
• state-space, transfer-function, or nonlinear plant models;
• signal processing and embedded-code generation;
• automated simulation campaigns;
• test harnesses and requirement-linked verification.

A disciplined Simulink model separates parameters, signals, buses, physical units, and verification logic. Parameters should be stored in a controlled script, data dictionary, or structured configuration object rather than hidden inside many blocks. Subsystems should have documented interfaces, meaningful names, and defined sample times.

For a discrete-time state model with sampling period T_s, a simple forward-Euler approximation is:

The approximation is appropriate when the sampling period is sufficiently small relative to the system dynamics and when numerical stability is acceptable. It is not automatically suitable for stiff systems or fast oscillatory modes. The choice of solver and sample time must be justified by physical time scales, accuracy requirements, and real-time constraints.

1.3 Simscape and Modelica

Simscape libraries provide component-based physical modelling within the MATLAB ecosystem. Modelica is an equation-based, object-oriented language designed for multi-domain physical systems. Both are valuable for systems containing interacting mechanical, electrical, thermal, hydraulic, and control domains.

A rotational inertia illustrates the physical approach. If torque τ acts on an inertia J, the angular acceleration is:

where ω is angular velocity. With viscous damping coefficient b and external load torque τ_L, the balance becomes:

The units are consistent: J has units kg·m², dω/dt has units rad/s² (radians are dimensionless), and their product has units N·m. The equation assumes a rigid inertia, a linear viscous damping law, and a defined sign convention.

Physical-network tools reduce repeated manual derivation, but they do not eliminate modelling responsibility. A connection must be physically meaningful, parameter values must be realistic, and algebraic loops or idealized elements may create numerical difficulties.

2. Choosing an appropriate model representation

Model selection should follow the engineering question rather than tool preference. A controller engineer may require a fast linearized model; a mechanical designer may need contact, compliance, and friction; and a systems engineer may need requirements, interfaces, and operating modes.

A model has a scope. A motor model used for speed control may omit bearing geometry but must represent torque, inertia, friction, electrical dynamics, and actuator limits sufficiently well for the intended tests. Adding detail is not always an improvement: excessive detail can slow simulation, obscure assumptions, and increase calibration effort.

3. MBSE and SysML

3.1 From documents to connected models

Model-based systems engineering treats a system model as a primary engineering artefact. Traditional development often distributes requirements, interface definitions, design drawings, analysis reports, and test procedures across separate documents. MBSE connects these artefacts through explicit relationships.

A typical systems-engineering chain is:

Requirement → functional behaviour → logical architecture → physical architecture → implementation → verification evidence.

The chain is useful only when relationships are maintained. A requirement should be linked to the element responsible for satisfying it and to a verification method that demonstrates compliance. A simulation result is not automatically proof of compliance; its assumptions, test conditions, and model credibility must be recorded.

3.2 SysML viewpoints

SysML provides diagrams and language concepts for describing systems. Common viewpoints include:

• requirement diagrams for needs, constraints, and derivation relationships;
• block definition diagrams for system elements and their relationships;
• internal block diagrams for connections and item flows;
• activity diagrams for functional workflows;
• state-machine diagrams for modes and transitions;
• parametric diagrams for constraints and analysis relationships.

SysML blocks are architectural elements, not necessarily software functions or physical parts alone. A block may represent a controller, sensor, actuator, subsystem, or external entity. Ports define interaction points, while item flows describe what crosses interfaces.

For a motorized positioning axis, a useful decomposition may include a motion controller, power converter, motor, transmission, position sensor, load, and safety supervisor. The model can link a requirement such as “position error shall remain below a specified limit under a specified load” to a simulation test and a later physical test.

MBSE is complementary to simulation, not a replacement for it. SysML may describe that a controller commands a motor, but a dynamic simulation is needed to evaluate overshoot, current, thermal stress, or instability.

3.3 Traceability and configuration

Traceability answers questions such as:

• Which requirement motivated this parameter?
• Which model element implements this function?
• Which version of the model produced this result?
• Which test demonstrates compliance?
• Which assumptions invalidate the result?

A practical traceability record contains requirement identification, model or code revision, parameter-set identifier, solver settings, input dataset, output files, and reviewer approval. This is particularly important in safety-related or regulated applications.

4. FMI and co-simulation

4.1 Functional Mock-up Interface

FMI is an open standard for exchanging and connecting dynamic models. A model may be packaged as a Functional Mock-up Unit (FMU). Two principal uses are:

1. Model Exchange: the importing environment supplies the numerical solver, while the FMU supplies equations and state-related functions.
2. Co-simulation: the FMU contains its own solver and advances in communication steps, exchanging inputs and outputs with a master algorithm or another FMU.

Model exchange can provide tighter solver coordination but requires compatible interfaces and solver support. Co-simulation allows each subsystem to retain its specialized solver, but communication-step errors and synchronization issues can reduce accuracy.

4.2 Co-simulation architecture

In co-simulation, subsystem A and subsystem B each advance from time t_k to t_k+1. At a communication point they exchange variables. If the communication step is H, then:

The step H is not simply a software setting. It must resolve the fastest relevant interaction, delay, switching event, and control requirement. If one subsystem changes rapidly between communication points, the other subsystem may use stale information.

A simple explicit exchange can be represented as:

This is a zero-order-hold assumption: subsystem B holds A’s last output during the interval. It introduces an approximation and may destabilize tightly coupled systems. Smaller steps, interpolation, iterative exchange, or a different partition may be required.

Co-simulation errors arise from numerical integration within an FMU, interpolation or extrapolation at interfaces, solver tolerances, algebraic loops, event timing, and inconsistent units. A successful simulation run is not evidence that these errors are negligible.

4.3 Interface contracts

Every exchanged variable should have a defined name, meaning, unit, direction, valid range, sampling or communication rule, and ownership. For example, “motor torque” must specify whether it is commanded torque, electromagnetic torque, or shaft torque; whether sign conventions are positive clockwise or counter-clockwise; and whether saturation is applied before or after exchange.

A compact interface contract may include:

5. APIs and data exchange

Simulation tools often need to communicate with CAD systems, databases, test benches, optimization software, or supervisory applications. APIs provide programmatic access through defined operations and data formats. Common approaches include Python or MATLAB interfaces, REST services, sockets, shared files, and message brokers.

A robust exchange separates data from presentation. Structured formats such as JSON, XML, CSV, or HDF5 can store parameters and results, but the format alone does not define semantics. A JSON field named “mass” is incomplete without a unit, coordinate frame, revision, and uncertainty or source.

A useful parameter record contains:

parameter: rotor_inertia
value: 0.0025
unit: kg*m^2
source: supplier_test_report_17
valid_range: [0.0020, 0.0030]
revision: 4

APIs should validate schemas, reject unknown or out-of-range values where appropriate, report errors clearly, and authenticate sensitive operations. Idempotent operations are preferable for automated workflows: repeating a request should not unintentionally duplicate a design or corrupt a result.

CAD/CAE integration requires particular care. Geometry identifiers can change after feature edits, meshes can be regenerated with different element numbering, and coordinate systems may differ between tools. A simulation workflow should therefore exchange stable metadata, units, coordinate transformations, material definitions, and provenance rather than relying only on file names.

6. Version control and reproducible workflows

A simulation result is reproducible only when another engineer can reconstruct the computational conditions that generated it. A recommended project structure separates source models, scripts, configuration, input data, generated results, documentation, and tests. Large binary files may require an appropriate artifact repository rather than ordinary source storage.

Version control systems such as Git support commits, branches, tags, reviews, and change history. Good commit messages explain the engineering change, not merely “updated model.” Tags can identify released model baselines. Branches should be short-lived where practical, and merges should include verification evidence.

A reproducible workflow records at least:

• model and source-code revision;
• tool and library versions;
• operating system or container image;
• parameter and input-data revisions;
• solver, tolerances, step sizes, and random seeds;
• unit conventions and coordinate frames;
• generated artefact checksums;
• pass/fail results of automated tests.

Reproducibility has three related levels. Repeatability means the same team obtains consistent results in the same environment. Reproducibility means an independent team can obtain the result using the documented artefacts. Replicability concerns obtaining consistent conclusions using a different implementation or experimental arrangement.

Automated tests should include unit tests for functions, model tests for subsystem behaviour, regression tests for selected outputs, and integration tests for interfaces. Numerical regression tests require tolerances because floating-point calculations, solver versions, and hardware may produce small differences. A test criterion can be written as:

where y_sim is the simulated value, y_ref is the reference value, ε_abs is an absolute tolerance, and ε_rel is a relative tolerance. The criterion is meaningful only when the output units and reference conditions are identical.

7. Worked implementation example: electromechanical positioning axis

Consider a simplified motor driving a load through a rigid transmission. The electrical armature equation is:

The mechanical equation is:

The position relationship is:

Here, v is applied voltage (V), i is current (A), L is inductance (H), R is resistance (Ω), k_e is back-emf constant, k_t is torque constant, J is equivalent inertia, b is viscous damping, τ_L is load torque, ω is angular speed, and θ is angular position. In SI units, consistent motor conventions commonly give k_e in V·s/rad and k_t in N·m/A, with numerical equality only under appropriate SI definitions.

Assume L = 0.5 mH, R = 2 Ω, k_e = 0.1 V·s/rad, k_t = 0.1 N·m/A, J = 0.01 kg·m², b = 0.001 N·m·s/rad, and zero load torque. The electrical time constant is:

The mechanical time constant associated with viscous damping is:

These values indicate widely separated time scales. A controller simulation that uses a very large step may miss electrical transients, while a real-time implementation may intentionally use a reduced electrical model if the control objective does not require those dynamics.

In Simulink, the three differential equations can be implemented with integrator blocks and algebraic feedback. In Simscape, a voltage source, resistor, inductor, controlled torque source, inertia, and damper can be connected physically. In Modelica, the same system can be expressed as connected electrical and mechanical components. An FMI workflow could export the motor plant as an FMU and connect it to a controller developed in another environment.

Verification should proceed incrementally: first test the resistor-inductor circuit, then the motor torque relation, then the mechanical load, and finally the closed-loop controller. Expected limiting behaviour should be checked. For example, at steady state with zero acceleration and zero load torque, the equations imply k_t i = bω and v = Ri + k_eω. These relationships provide simple checks on simulation outputs.

8. Illustrative case: digital engineering workflow for a pick-and-place actuator

Background. An engineering team is developing a servo actuator for a pick-and-place machine. The actuator includes a motor, belt transmission, position sensor, drive electronics, embedded controller, and safety interlock. Mechanical, controls, and software engineers initially use separate models.

Problem. The first integrated simulation shows inconsistent position responses. Investigation reveals that the mechanical model uses millimetres, the controller uses metres, and the co-simulation interface interprets speed in revolutions per minute rather than radians per second. In addition, the controller model and plant model use different saturation limits.

Analysis. The team creates a SysML architecture with explicit ports and links the performance requirement to a simulation test. An interface contract defines position in metres, speed in radians per second, positive direction, update period, saturation behaviour, and sensor-fault status. The plant is implemented in Simscape, the controller in Simulink, and an FMU is exported for an independent software-in-the-loop test.

Approach. All parameters are placed in a version-controlled configuration file with units and source references. A continuous high-fidelity model is used for design analysis, while a discrete model uses the intended controller sample period. Automated tests check unit conversion, steady-state speed, position tracking, actuator saturation, and fault response. A continuous-integration job runs a reduced regression suite whenever model or script files change.

Outcome. The team identifies the unit mismatch before hardware testing. The final evidence package contains the requirement links, model revision, FMU checksum, solver settings, parameter set, test inputs, plots, and review record. The approach does not guarantee that the physical actuator will behave identically, but it makes assumptions visible and reduces avoidable integration errors.

Learning points. Interface semantics are as important as numerical values. MBSE provides the structure for traceability; simulation tools provide dynamic analysis; FMI enables exchange; and version control makes the evidence auditable. None of these removes the need for physical validation.

9. Limitations, governance, and professional practice

9.1 Model credibility

A model may be mathematically correct but inappropriate for its purpose. Credibility requires documented assumptions, parameter provenance, verification of implementation, comparison with analytical limits, and validation against experimental or trusted reference data. Calibration should not be confused with validation: fitting parameters to one dataset does not prove accuracy under different operating conditions.

Discretization, solver tolerances, stiff dynamics, discontinuities, contact, hysteresis, and algebraic loops can all affect results. Engineers should perform sensitivity studies and, where relevant, compare solver settings or model fidelities. Outputs should be reported with limitations rather than excessive precision.

9.2 Safety and cybersecurity

Simulation models used in safety decisions require controlled changes, review, independent checking, and clear separation between verified evidence and exploratory analysis. Proprietary CAD, supplier models, and test data require access control and licensing compliance. FMUs and APIs can contain executable code; they should be treated as software supply-chain artefacts and scanned, authenticated, and executed in controlled environments.

Cybersecurity also applies to connected digital twins. Unauthenticated parameter updates, manipulated sensor data, or compromised model services can produce unsafe recommendations. Least privilege, signed artefacts, network segmentation, logging, and secure credential management are appropriate controls.

9.3 AI-assisted modelling

AI tools can help generate scripts, identify anomalous results, search documentation, or propose reduced-order models. They can also introduce fabricated APIs, incorrect equations, hidden assumptions, or untraceable changes. AI-generated code must undergo human review, testing, licensing checks, and validation against trusted references. In safety-critical engineering, responsibility remains with qualified engineers and the organization’s approval process.

9.4 Best-practice checklist

Before releasing a simulation result, ask:

1. Is the modelling purpose and scope stated?
2. Are units, signs, coordinate frames, and interface meanings explicit?
3. Are equations, parameters, initial conditions, and solver settings documented?
4. Has the implementation been tested against analytical or limiting cases?
5. Are model, data, tool, and environment revisions recorded?
6. Has the co-simulation communication step been justified?
7. Are results traceable to requirements and verification procedures?
8. Are uncertainty, calibration limits, and validation evidence reported?
9. Are executable artefacts, APIs, and proprietary data governed securely?

Chapter Summary

Simulation environments provide complementary capabilities. MATLAB/Simulink is effective for signal-flow, control, algorithms, and automated testing, while Simscape and Modelica support multi-domain physical-network modelling. The representation must match the engineering question and should include only the fidelity needed for credible decisions.

MBSE connects requirements, functions, architecture, implementation, and verification. SysML helps express structure, behaviour, interfaces, and traceability, but dynamic performance still requires executable models. FMI supports model exchange and co-simulation; its success depends on well-defined variables, units, communication steps, and numerical assumptions. APIs extend simulation into CAD/CAE, databases, optimization, and test systems, but data semantics and security must be controlled.

Version control and reproducibility transform simulation from an individual activity into an auditable engineering process. A credible result identifies its model scope, parameters, solver settings, software environment, tests, and limitations. Physical validation remains essential, and AI assistance must be governed by technical review and professional responsibility.

Key Terms

Model exchange: Use of an executable model with a solver supplied by the importing environment.

Co-simulation: Joint simulation in which connected subsystems exchange data at communication points.

FMU: Functional Mock-up Unit packaged according to the FMI standard.

FMI: Functional Mock-up Interface for model exchange and co-simulation.

MBSE: Model-based systems engineering using an integrated system model as a primary engineering artefact.

SysML: Systems Modeling Language for specifying system requirements, structure, behaviour, and constraints.

Acausal modelling: Equation-based modelling in which computational causality is determined after connections are defined.

Signal-flow model: Model in which blocks compute outputs from explicitly directed inputs.

Physical-network model: Model based on component relationships and conservation laws across physical domains.

Interface contract: Formal definition of exchanged variables, units, directions, ranges, and update rules.

Traceability: Ability to link requirements, design elements, analyses, tests, and evidence.

Solver: Numerical algorithm that advances a dynamic model in time.

Communication step: Time interval between exchanges in a co-simulation.

Regression test: Test that detects unintended changes in established model behaviour.

Reproducibility: Ability of another team to obtain a result using documented artefacts and conditions.

Calibration: Adjustment of model parameters to fit observed data.

Validation: Evaluation of whether a model adequately represents a real system for its intended purpose.

Digital twin: Connected digital representation maintained for a physical asset or process.

Reduced-order model: Simplified model designed to preserve selected behaviours at lower computational cost.

Configuration management: Controlled identification, modification, review, and release of engineering artefacts.

Review Questions

Short Answer Questions

1. Distinguish a signal-flow model from a physical-network model.
2. What are the two principal uses of FMI?
3. Why must a co-simulation communication step be justified physically?
4. State three items that should be recorded for a reproducible simulation.
5. What role does SysML play in an MBSE process?

Long Answer Questions

1. Explain how MATLAB/Simulink, Simscape, and Modelica can be used together in a mechatronic development process.
2. Describe how requirements, architecture, simulation, and verification are connected in MBSE.
3. Explain the principal numerical and semantic sources of error in FMI co-simulation.
4. Develop a version-controlled workflow for a controller and plant model intended for software-in-the-loop testing.
5. Discuss why model credibility requires both verification and validation.

Analytical / Application Questions

1. A plant FMU exchanges position and speed with a controller every 10 ms, but the plant contains a mode transition occurring within 1 ms. Analyse the likely consequences and propose a revised co-simulation strategy.
2. A simulation result changes after a software update although the source model is unchanged. Design an investigation using version records, solver settings, parameter files, and regression tests.
3. Design an MBSE and simulation integration plan for a two-axis robotic actuator, including requirements, SysML elements, interface contracts, FMI boundaries, automated tests, and physical validation.

Multiple Choice Questions with Answers

Question 1

Which modelling approach allows the tool to determine computational causality from connected physical equations?

A. Acausal physical-network modelling

B. Pure document modelling

C. Manual waveform plotting

D. Unstructured scripting

Correct Answer: A. Acausal physical-network modelling

Question 2

In FMI co-simulation, what does the communication step represent?

A. The time interval between data exchanges

B. The model’s total operating lifetime

C. The number of states in an FMU

D. The physical size of the system

Correct Answer: A. The time interval between data exchanges

Question 3

Which SysML element is most directly used to represent system needs and constraints?

A. Requirement diagram

B. Activity token

C. Source-code branch

D. Solver tolerance

Correct Answer: A. Requirement diagram

Question 4

For the motor example, what is the electrical time constant when L = 0.0005 H and R = 2 Ω?

A. 0.00025 s

B. 0.0025 s

C. 0.25 s

D. 4,000 s

Correct Answer: A. 0.00025 s

Question 5

Which item is essential in an interface contract?

A. Variable meaning and unit

B. The colour of a block icon

C. The author’s preferred font

D. The number of pages in a report

Correct Answer: A. Variable meaning and unit

Question 6

What is the primary purpose of a regression test in a simulation project?

A. To detect unintended changes in established behaviour

B. To increase model complexity automatically

C. To replace all physical testing

D. To remove the need for parameter documentation

Correct Answer: A. To detect unintended changes in established behaviour

Question 7

Which statement best describes model exchange in FMI?

A. The importing environment supplies the numerical solver

B. Each FMU must always use the same solver

C. It refers only to CAD geometry transfer

D. It eliminates the need for interface definitions

Correct Answer: A. The importing environment supplies the numerical solver

Question 8

Why can a larger co-simulation communication step be problematic?

A. It can cause rapidly changing information to be represented by stale data

B. It always reduces computational cost to zero

C. It changes all units into SI units automatically

D. It guarantees instability in every model

Correct Answer: A. It can cause rapidly changing information to be represented by stale data

Question 9

Which practice most directly supports reproducibility?

A. Recording model, data, tool, and solver revisions

B. Saving only the final plot

C. Changing parameters manually without a log

D. Using undocumented default settings

Correct Answer: A. Recording model, data, tool, and solver revisions

Question 10

Why should AI-generated simulation code be reviewed by an engineer?

A. It may contain incorrect equations, APIs, or hidden assumptions

B. AI code is always computationally slower

C. Review is unnecessary for non-safety systems

D. AI cannot produce executable code

Correct Answer: A. It may contain incorrect equations, APIs, or hidden assumptions