System Modeling and Simulation

Understanding a system begins by deciding which physical effects belong in the model, which can be neglected, and what question the model is expected to answer. Simulation is the execution of that model under defined initial conditions and inputs. Detail alone does not create accuracy; a high-resolution model built around the wrong boundary or parameters can still produce the wrong result.

This course converts the system view introduced in Introduction to Mechatronics Engineering into mathematical and computational models. It uses foundations from Circuit Theory and Signals and Systems and provides the plant-model foundation required by Automatic Control.

Unit 1: Modeling Purpose and System Boundary

A model is a selected representation of a real system for a stated use. The same physical system may require different models for energy consumption, vibration, thermal analysis, or controller design.

Before equations are written, identify the system boundary, inputs, disturbances, measurable outputs, internal states, parameters, initial conditions, and valid operating range. Results should not be generalized beyond that range without validation.

1.1. Model Accuracy Depends on Purpose

A model is not judged only by the amount of detail it contains. A vibration model of a motor shaft and an energy-consumption model of the same motor require different states and parameters. The decision problem, observable outputs, and acceptable error should therefore be defined before the model is built.

Effects excluded from the boundary should be recorded as assumptions. Winding temperature may reasonably be treated as constant in a short electromechanical transient model, while the same assumption can invalidate a duty-cycle analysis because resistance and torque capability change with temperature. The validity domain is part of the model result.

Unit 2: Physical, Conceptual, and Mathematical Models

A physical prototype uses actual components; a conceptual model describes blocks and causal relationships; a mathematical model expresses those relationships with equations. A computational model implements the equations in a numerical solver or discrete-event engine.

A practical progression is:

requirement
 -> system boundary
 -> physical laws
 -> assumptions
 -> equations
 -> parameters
 -> numerical model
 -> verification

Model construction begins by stating the question the model must answer. Specify system boundaries, inputs and outputs, conserved quantities, and neglected effects. Derive equations from explicit assumptions and check parameter units and plausible ranges. Matching one observed behavior is not enough: assess the error with which the model can be used at different operating points. Model complexity is then tied to the accuracy required by the intended decision.

Unit 3: Energy Storage and Dissipation

Dynamic behavior is closely related to storing and dissipating energy. Capacitors and inductors store electrical energy; masses/inertias and springs store mechanical energy. Resistance and viscous friction dissipate energy.

These correspondences allow systems from different physical domains to share similar differential-equation structures. Mathematical similarity does not mean that the underlying physical quantities are identical.

3.1. Building Models from Energy Flow

Many dynamic models become clearer when energy storage and dissipation are identified explicitly. Stored energy includes E_C=0.5 C V^2 in a capacitor, E_L=0.5 L I^2 in an inductor, E_k=0.5 m v^2 in translation, E_k=0.5 J ω^2 in rotation, and E_s=0.5 k x^2 in a spring.

Resistance and viscous friction do not store energy; they dissipate it. This distinction helps identify meaningful state variables. Energy conservation is also a strong verification check: unexplained energy growth in a closed model often reveals sign, unit, or numerical-integration errors.

Unit 4: Electrical-Mechanical Analogies

A mass-spring-damper system and an RLC circuit can both exhibit second-order dynamics.

Mechanical form:

md²x/dt²+bdx/dt+kx=F(t)

Series RLC form:

L(d^2q)/(dt^2)+R(dq)/(dt)+(1)/(C)q=v(t)

This correspondence helps transfer concepts such as energy storage, damping, and natural frequency between domains.

4.1. Limits of Analogies

Electrical-mechanical analogies compare mathematical structure; they do not imply that physical quantities are identical. Force-voltage and force-current analogies use different mappings, and the selected mapping should be explicit when multiple energy domains are coupled.

A DC motor is a direct electromechanical example:

v = R i + L di/dt + K_e ω
J dω/dt = K_t i - T_L - Bω

Current and angular velocity couple the two domains. Even correct submodels produce a wrong system when the coupling terms are incorrect.

Unit 5: Linear and Nonlinear Models

Linear models support superposition and simplify many analysis methods. Real systems may include friction, backlash, saturation, dead zones, magnetic saturation, and nonlinear flow relationships.

A nonlinear model

dx/dt=f(x,u)

may be linearized about an operating point as:

δdx/dt=Aδ x+Bδ u

but the resulting approximation is valid only around the selected region.

For local analysis of a nonlinear system, select an operating point and verify its equilibrium conditions. Evaluate the Jacobians there to obtain a linear model for small deviations. Compare its predictions against the nonlinear model at the selected perturbation magnitude. If the error exceeds the acceptance criterion, restrict the validity region or linearize about another operating point. This prevents a local approximation from being incorrectly applied to the entire operating space.

5.1. Linearization and Operating Point

Linearization does not remove nonlinear behavior; it creates a small-signal approximation around an operating point. For x0,u0, Jacobians such as A=∂f/∂x and B=∂f/∂u may be used. The resulting model is reliable only for sufficiently small deviations around that region.

Saturation, Coulomb friction, backlash, and dead zones may not be represented well by one linear model. Piecewise models, hybrid modes, or direct nonlinear integration may be more appropriate. The engineering objective is a controlled tradeoff between mathematical simplicity and physical adequacy.

Unit 6: State Variables

State is the minimum information carried from the past that is required to predict future behavior under a known input. A continuous-time linear model is commonly written as:

dx/dt=Ax+Bu

y=Cx+Du

Physical energy-storage variables often provide useful states, although state coordinates are not unique.

6.1. State Selection and Physical Meaning

States represent the memory required to predict future behavior. Capacitor voltage and inductor current are natural electrical states; position and velocity are natural states for a mass-spring system. Different coordinate choices can describe the same input-output behavior.

A state does not need to be directly measurable. Unmeasured states may later be estimated by an observer. Units, initial conditions, and admissible ranges must nevertheless be explicit; a numerically executable model can still be physically meaningless when these are inconsistent.

Unit 7: Transfer Functions and State Space

For a linear time-invariant system with zero initial conditions:

G(s)=(Y(s))/(U(s))

represents the input-output relation. State-space representation also exposes internal state and scales naturally to multiple-input, multiple-output systems.

The two forms are complementary representations rather than competing modeling philosophies.

Unit 8: Continuous and Discrete Time

The physical plant may evolve continuously while a digital controller samples it periodically. With sampling period T_s, a discrete state model can be written as:

x_(k+1)=A_d x_k+B_d u_k

Sampling is not merely a data-reduction operation; it changes which dynamics are observable and how numerical behavior must be interpreted.

8.1. Discretization Is More Than Sampling

A continuous dx/dt=Ax+Bu model under a zero-order-hold assumption leads to discrete A_d and B_d matrices. A very small sampling period is not free: computation, communication traffic, and sensitivity to measurement noise may increase. A large period can miss fast dynamics and reduce phase margin.

The discrete model must also represent sample-and-hold behavior, computation delay, and the actual actuator-update instant. Assuming that measurement and actuation belong to the same sample when implementation delays them can create a meaningful phase error.

Unit 9: Numerical Integration

Differential equations without a convenient closed-form solution are executed numerically. Forward Euler:

x_(k+1)=x_k+h f(t_k,x_k)

is simple, but a large step h may introduce large error or instability. Runge-Kutta methods can provide higher accuracy, while implicit methods are advantageous for some stiff systems.

Solver choice must match system time scales and accuracy requirements.

9.1. Local Error, Global Error, and Stability

A small one-step error in Forward Euler can accumulate over thousands of steps. Halving the time step and checking convergence is a simple but powerful test. If the result does not approach a stable solution as the step is refined, the numerical result should not be trusted.

Explicit methods are inexpensive but may require extremely small steps for stiff systems. Implicit Euler, trapezoidal methods, or BDF families can be preferable for some models. Solver selection depends on eigenvalues, stiffness, discontinuities, accuracy needs, and real-time constraints rather than on method order alone.

When step size changes the apparent physics. The model x'(t) = −10x(t) with x(0) = 1 has the continuous-time solution x(t) = e^(−10t), positive and decreasing for all t ≥ 0. Forward Euler produces x_(k+1) = (1 − 10h)x_k. At h = 0.15 s, the multiplier is −0.5, so the numerical result alternates in sign while its magnitude decays. At h = 0.25 s, the multiplier is −1.5, causing a numerical trajectory to diverge although the physical system is stable. Absolute stability of forward Euler for this test equation requires |1 − 10h| < 1, or 0 < h < 0.2 s. A stable step does not, by itself, preserve positivity or ensure adequate accuracy. Step selection must account for stability, physical invariants, and error tolerance together, not just runtime.

9.2. Distinguishing numerical-step Instability from Physical Instability

The continuous-time model dx/dt = -20x converges to zero for every finite initial state. Forward Euler produces x[k+1] = (1 - 20h)x[k]. Its discrete trajectory decays only when |1 - 20h| < 1, or 0 < h < 0.1 s. Choosing h = 0.12 s gives a multiplier of -1.4: the computed state alternates in sign while growing, despite the underlying physical system being stable. Such a trace does not establish physical instability.

A visually smooth plot is not a sufficient step-size criterion. Results should be compared using at least two smaller steps under unchanged physical conditions; relevant energy or dissipation properties and the integrator choice should also be checked. In systems with widely separated time constants, a restrictive time step may arise from the integrator's absolute-stability region rather than accuracy alone. When simulation includes a sampled controller, the numerical stability of the plant solver and the actual closed-loop stability of the sampled controller are separate questions.

Unit 10: Stiff and Multi-Time-Scale Systems

Electrical current may change below the millisecond scale, mechanical motion over tens of milliseconds, and thermal behavior over seconds or minutes. When these scales coexist, a uniformly tiny step may be computationally wasteful while a large step can miss fast dynamics.

Stiffness therefore affects both computational cost and solver selection.

10.1. Electrical, Mechanical, and Thermal Time Scales

A motor-drive model can contain switching in microseconds, current dynamics in sub-milliseconds or milliseconds, mechanical speed in tens of milliseconds, and temperature changes over seconds or minutes. A single fixed time step that resolves all scales may become unnecessarily expensive.

For some studies the switching stage can be replaced by an averaged converter, a fast current loop by an ideal torque source, or a thermal model by a slower update. Model reduction should preserve the time scales relevant to the engineering question rather than blindly removing detail.

Imposing one integration interval on every state in a multiscale model can waste computation. A current may change appreciably over milliseconds while a housing temperature evolves over seconds; the thermal subsystem does not necessarily need the same step size as the electrical subsystem. When subsystems advance on separate grids, however, power exchange must remain consistent on a shared physical timeline. Comparing changes in stored energy with integrated power flow provides a check that numerical acceleration has not violated the underlying conservation balance.

Unit 11: Parameter Identification

Mass, inertia, resistance, and geometry may be measured directly, while friction, time constants, or other coefficients may need to be estimated from experimental data.

Reliable identification requires adequate excitation, characterized measurement noise, a model structure that allows parameters to be distinguished, and separation of fitting data from validation data. Model-structure error should not be disguised as parameter error.

11.1. Identifiability and Experiment Design

Parameter estimation is more than fitting a curve. If two parameters influence the output in nearly the same way, they may not be separately identifiable from one experiment. This creates structural or practical identifiability problems.

The excitation must reveal the desired parameters. A single constant-speed point may not distinguish Coulomb from viscous friction, whereas tests over multiple speeds and accelerations can provide more information. Parameters estimated on one dataset should be checked against separate validation data.

11.2. Separating Nearly Indistinguishable Parameters in an Inverse Problem

Consider two experiments described by y1 = a + b and y2 = a + 1.01b. For y1 = 10 and y2 = 10.03, subtraction gives 0.01b = 0.03, hence b = 3 and a = 7. If the second observation changes by just 0.01 to 10.04, the estimates become b = 4 and a = 6. A small measurement perturbation has produced a substantial parameter change. This is not simply an arithmetic defect of the solver; both experiments excite nearly the same combination of unknown parameters.

Writing the system as y = Aθ + ε reveals the issue. Small singular values of A identify parameter directions that cannot be recovered reliably in the presence of noise. Changing the experimental excitation to make the matrix columns less alike may be more valuable than collecting additional observations under the same conditions. Regularization can reduce estimate variance when experiments cannot be redesigned, but it introduces assumptions and hence possible bias. Data fit, parameter uncertainty, and sensitivity to the regularization choice should be reported separately.

11.3. Tracking Changing Physical Parameters with RLS

For a first-order discrete system y_k = a y_(k-1) + b u_(k-1) + e_k, define parameters θ=(a,b) and regressors φ=(y_(k-1),u_(k-1)). RLS with forgetting factor ρ can emphasize recent measurements, but ρ<1 may also increase variance and noise sensitivity. A constant uninformative input may not identify both parameters; persistent excitation is required.

One-step prediction error does not characterize free-running simulation. Replacing measured lagged outputs with the model's own predictions can compound errors, so autonomous rollout and physical parameter constraints must both be tested.

Unit 12: Sensitivity and Uncertainty

Sensitivity analysis asks how output changes when a parameter changes. A single nominal simulation represents only one operating point.

Manufacturing tolerance, friction, load, supply, and environmental variation may be modeled as ranges or distributions. Monte Carlo studies should record distributions, random seed, model version, and parameter set so that results are reproducible.

12.1. Propagating Parameter Uncertainty

Output sensitivity to a parameter can be interpreted locally through ∂y/∂p. Large sensitivity means that a small parameter error can cause a large output change, which helps decide where calibration effort is valuable.

Monte Carlo analysis samples parameters from distributions instead of using one nominal value, but distributions should be evidence-based. Assigning an arbitrary Gaussian distribution to every unknown does not make uncertainty scientific, and correlated parameters should not be sampled independently.

12.2. Input Uncertainty, Sampling Error, and Numerical Error

Variation in simulated outputs can arise from distinct sources. Unknown physical parameters produce input uncertainty; a finite number of simulation runs produces Monte Carlo error; and integrating differential equations with finite steps produces discretization error. Combining them into one standard deviation obscures which corrective action is effective. A time-step refinement experiment examines numerical convergence while keeping parameters and stochastic inputs fixed; independent replications assess sampling variability.

For Y = g(θ), a first-order approximation to propagation under small uncertainty is

Var(Y) ≈ ∇g(μ)ᵀ Σ_θ ∇g(μ)

where Σ_θ is the parameter covariance matrix. Retaining diagonal entries alone can misstate uncertainty when parameters are dependent. With pronounced nonlinearities or threshold behavior, Monte Carlo sampling that preserves the joint input distribution may be preferable; multimodality and heavy tails must be represented adequately.

Model validation is not the same as resolving parameter uncertainty. Demonstrating convergence of a numerical solver for a given parameter set does not establish that the model describes the physical system correctly. At least three results should be reported separately: numerical convergence, sampling stability of predictive intervals, and validation error against observations of the real system.

Unit 13: Discrete-Event and Hybrid Models

Not every system is described only by differential equations. Relay transitions, limit switches, mode changes, faults, communication packets, and state machines are discrete events.

A hybrid model combines:

continuous physical dynamics
        +
discrete state / event logic

Accurate event timing is essential in collision, saturation, and switching models.

13.1. Combining Continuous Dynamics with Logical Modes

A thermostat, limit switch, or gear change cannot be described by differential equations alone; the system switches between different dynamic regimes. A hybrid model combines continuous states with discrete modes.

A motor axis may use NORMAL, CURRENT_LIMIT, END_STOP, and FAULT modes with different constraints. Without hysteresis or debounce, rapid switching near a boundary can create chattering. Event detection and zero-crossing behavior of the simulation engine can therefore affect the result materially.

13.2. Event Calendars and Stable Ordering in Discrete-Event Simulation

A discrete-event simulation need not advance at wall-clock speed. Simulated time jumps directly to the timestamp of the next event. An event priority queue ordered by (timestamp, sequence_number) yields deterministic behavior for simultaneous arrivals, service completions and resource releases. Because the tie-break order can change instantaneous state, it must be part of the model contract.

Core invariants include nondecreasing simulation time, nonnegative queue length, correct capacity release at task completion and no double completion of a task. Random service times require an explicit distribution, seed and independent replication identifier. Reproducing the same event trace with the same seed demonstrates repeatability, not certainty about the real system's future.

Cancellation, resource failures and recovery can be represented as distinct event types. Their impact is evaluated through queue distributions, bottleneck occupancy, unfinished jobs and processed event counts, not just a mean output.

13.3. Simulation Calibration and Validation Against Measurement

A queue simulator needs distributions of interarrival time, service duration, job class and concurrency limits, not merely a total task count. Parameters estimated from one observation period should be tested on a separate period. Reusing the calibration data as validation data risks optimistic conclusions. Nonstationary traffic may require a time-bucketed or empirical arrival model rather than one Poisson rate for an entire day.

Validation can compare mean queue length, waiting-time percentiles, completion rate and capacity utilization. Deviations may arise from parameter estimation, model structure or missing measurements. Unvalidated simulation results must not be presented as definitive production capacity.

Unit 14: Verification and Validation

Verification asks whether the model and implementation correctly realize the specified equations. Validation asks whether the model represents the real system sufficiently well for its intended use.

Verification can use unit consistency, boundary cases, conservation laws, known analytical solutions, and numerical convergence. Validation compares predictions with independent physical measurements.

14.1. Verification versus Validation

Verification asks whether equations and algorithms were implemented correctly. Unit tests, comparison with analytical solutions, conservation checks, and boundary cases belong here. Validation asks whether the model represents the real system well enough for its intended use and therefore requires comparison with measurements.

A model should not be validated by one metric alone. Mean error may be small while peak value, phase delay, or transient response is wrong. Control design may prioritize phase and dynamic response, while energy studies may prioritize integrated power. Validation metrics must follow the intended use.

Unit 15: Model-Reality Gap

Coulomb friction, backlash, cable compliance, sensor delay, saturation, quantization, and temperature dependence may be absent from a nominal model. The difference between simulation and experiment should not automatically be labeled as noise.

The conditions under which a model becomes inadequate are part of its technical specification.

Unit 16: MIL, SIL, and HIL

Model-in-the-loop evaluates the control concept against a model. Software-in-the-loop executes the actual control software in a software environment. Hardware-in-the-loop closes the loop between the real controller and a real-time plant model.

HIL does not eliminate all physical risk; power-stage behavior, mechanical strength, and electromagnetic effects still require physical validation.

16.1. Following the Same Scenario Across Implementation Levels

MIL can execute the controller and plant as mathematical models. SIL runs production-like software logic on a host to expose numerical, state-machine, and implementation details. HIL connects the real ECU or MCU through physical I/O to a real-time plant simulator.

Test scenarios should remain traceable across these levels. Repeating the same overload or sensor-disconnection scenario in MIL, SIL, and HIL makes it easier to identify whether a behavioral difference comes from the model, software, or hardware.

Unit 17: Reproducible Simulation

An engineering simulation record should preserve at least the model version, parameter set, initial conditions, input data, solver, step size or tolerances, random seed, and software version.

A result that cannot be regenerated weakens traceability of the design decision based on it.

17.1. Reproducing a Result

A saved model file alone is not enough. Model version, parameter set, solver, tolerances, time step, initial conditions, random seed, and external data should be recorded together.

Changes in numerical libraries or platforms can alter floating-point behavior. Critical comparisons should therefore preserve raw results, tolerances, and acceptance criteria instead of only screenshots. Reproducibility turns simulation from a personal experiment into auditable engineering evidence.

Course Boundaries and Continuation

This course focuses on representing physical systems. Fourier analysis, sampling, and LTI theory are developed in Signals and Systems; measurement reliability in Measurement Systems; controller synthesis in Automatic Control; and robot dynamics and planning in Robotics Engineering.

Applied Model Hierarchy: DC Motor and Load

The same DC-motor system can be modeled at different levels for different decisions. An energy estimate may use a constant-efficiency torque converter. Speed control needs electrical and mechanical dynamics. Current ripple or switching loss requires the switching stage. Duty-cycle thermal analysis adds winding temperature and temperature-dependent resistance.

Level 0: P_in -> η -> P_mech
Level 1: T = K_t i, e = K_e ω
Level 2: L di/dt + Ri + K_eω = v
         J dω/dt + Bω + T_L = K_t i
Level 3: inverter / PWM / current ripple
Level 4: thermal state + R(T) + derating

A higher level is not universally “more correct”; it answers a different question. Resolving every transistor edge is unnecessary for early controller design, while an averaged model is inadequate for EMI or switching-loss analysis. Model fidelity should preserve the physics needed for the decision and omit the rest deliberately.

The same hierarchy applies to sensing, hydraulics, and thermal systems. When model and measurement are compared, variable definition, units, and timestamps must match; an apparent model error can otherwise be only a scaling or alignment error.

References

• Banks, J.; Carson, J. S.; Nelson, B. L.; Nicol, D. M. Discrete-Event System Simulation. Pearson, 2010.
• Isermann, R. Mechatronic Systems: Fundamentals. Springer, 2005.
• Law, A. M. Simulation Modeling and Analysis. McGraw-Hill, 2007.

• Walter W. Piegorsch, Richard A. Levine, Hao Helen Zhang, Thomas C. M. Lee (eds.). Computational Statistics in Data Science. Wiley, 2022. ISBN 9781119561071.
• Billingsley, J. Mechatronics Experiments with Machine Vision. Springer Nature Switzerland, 2026. DOI: https://doi.org/10.1007/978-3-032-11218-7.
• Necsulescu, D. Advanced Mechatronics: Monitoring and Control of Spatially Distributed Systems. World Scientific, 2009. ISBN 978-981-277-181-0.
• Chunwei Zhang, Tianpeng Li, Ying Dai, Li Sun, and Ardashir Mohammadzadeh. Practical Neural Networks in Python and MATLAB. Springer Nature, 2026. DOI: https://doi.org/10.1007/978-3-032-14746-2.