Modeling Methodology and Requirements

Introduction

A mechatronic system combines mechanical structure, sensors, actuators, electronics, embedded computation, control algorithms, communication, and often human interaction. Modeling provides a disciplined way to represent these interacting elements so that engineers can predict behavior, test alternatives, identify risks, and verify whether a design satisfies its intended purpose.

A model is not the system itself. It is a purposeful representation created for a particular question. A model suitable for selecting a motor may be unsuitable for designing a current controller. A model used to estimate energy consumption may not represent the detailed switching behavior of a power converter. Consequently, effective modeling begins not with equations or software, but with requirements and decisions.

This chapter presents a methodology for translating stakeholder needs into modeling objectives, selecting an appropriate abstraction level, stating assumptions, decomposing a system, defining performance measures, developing models iteratively, and maintaining traceability between requirements, model elements, simulations, and conclusions.

Learning Objectives

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

1. Distinguish stakeholder needs, system requirements, modeling objectives, and verification criteria.
2. Select an appropriate system boundary, abstraction level, and model type.
3. Formulate assumptions and assess their consequences.
4. Decompose a mechatronic system into interacting subsystems.
5. Define measurable performance indicators and acceptance criteria.
6. Develop and refine models through iterative verification and validation.
7. Maintain traceability from requirements to model components and simulation evidence.
8. Recognize limitations, uncertainty, ethical issues, and governance requirements in simulation-based engineering.

1. From Stakeholder Need to Modeling Objective

1.1 Stakeholder needs and system requirements

Stakeholders include customers, operators, maintenance personnel, manufacturers, regulators, safety engineers, and business decision-makers. Their statements are often expressed in broad terms:

• “The robot must be fast.”
• “The positioning system must be accurate.”
• “The machine must be safe and reliable.”
• “The product should consume little energy.”

These statements are important but insufficient for modeling. Engineers translate them into verifiable system requirements. A good requirement identifies a function or constraint, a measurable quantity, operating conditions, and an acceptance threshold.

For example, “the positioning system must be accurate” may become:

Under a payload of 2 kg, ambient temperatures from 10 °C to 35 °C, and commanded displacements up to 0.5 m, the final absolute position error shall not exceed 0.5 mm.

The requirement now identifies a quantity, a limit, and relevant conditions. It can be connected to a model and tested through simulation or experiment.

A requirement typically contains:

• Object: the system or subsystem affected;
• Action or capability: what it must do;
• Measure: how performance is quantified;
• Condition: when or under what environment it applies;
• Criterion: the permitted value or pass/fail rule.

Requirements should be unambiguous, feasible, consistent, traceable, and verifiable. “High reliability” is weak because it lacks a measure. “The actuator shall complete 10,000 operating cycles without functional failure under the specified duty cycle” is more useful, although the definition of functional failure must still be supplied.

1.2 Modeling objectives

A modeling objective states what the model must answer and how its output will support an engineering decision. Examples include:

• Estimate the settling time of a servo axis.
• Determine whether a motor can accelerate a specified load.
• Predict temperature rise during continuous operation.
• Compare two gear ratios.
• Evaluate stability margins of a feedback controller.
• Estimate battery energy required for a mission profile.

The objective should be narrower than the complete product requirement. A practical formulation is:

For [operating conditions], use [model type] to estimate [output] within [acceptable uncertainty] in order to support [decision].

For example:

For a 2 kg payload and a 0.5 m move, use a nonlinear rigid-body and motor model to estimate peak motor torque and settling time in order to select the actuator and controller gains.

This statement clarifies the required fidelity. If the decision concerns peak torque, detailed electromagnetic switching may be unnecessary. If electromagnetic torque ripple is under investigation, it may be essential.

1.3 Requirement hierarchy and traceability

Requirements are normally organized hierarchically:

1. Stakeholder needs
2. System requirements
3. Subsystem requirements
4. Component requirements
5. Verification criteria
6. Model variables and simulation tests

Traceability links each item to the next. A traceability matrix can contain the following fields:

Traceability prevents a common failure: producing impressive plots that answer no engineering question. It also supports change management. If the payload changes, the engineer can identify affected assumptions, test cases, and model elements.

2. System Boundaries, Interfaces, and Decomposition

2.1 Choosing the system boundary

A system boundary defines what is inside the model and what is represented as an external input, disturbance, or fixed parameter. Boundary selection depends on the question being asked.

For a position-control study, the boundary may include the controller, amplifier, motor, transmission, load, and position sensor. The user command is an input, while ambient temperature may be treated as a parameter. For a thermal study, the boundary may expand to include motor losses, housing, airflow, and the environment.

An excessively narrow boundary can omit important interactions. An excessively broad boundary increases parameters, computation time, and uncertainty. A useful boundary includes all elements that materially influence the modeled output over the modeled time scale.

2.2 Functional and physical decomposition

Two complementary decompositions are useful:

• Functional decomposition: what the system does, such as sense position, compute error, generate torque, transmit motion, and dissipate heat.
• Physical decomposition: which physical elements perform those functions, such as encoder, microcontroller, inverter, motor, gearbox, shaft, and frame.

A functional block diagram emphasizes information and energy flow. A physical architecture emphasizes components and interfaces. Both should identify signals, units, direction of influence, and constraints.

Figure: Functional decomposition of a closed-loop mechatronic position-control system.

2.3 Interface definition

Interfaces are frequent sources of modeling error. An interface specification should identify:

• signal name and direction;
• physical meaning and unit;
• range and resolution;
• sampling rate or timing;
• latency and bandwidth;
• energy or mechanical connection;
• initial conditions and constraints;
• failure or saturation behavior.

For example, an encoder interface is not merely “position.” It may include quantization, sampling delay, maximum count rate, wraparound, noise, and loss-of-signal behavior. Ignoring these features can produce a controller that performs well in simulation but fails in hardware.

3. Abstraction Levels and Model Types

3.1 Abstraction as purposeful simplification

Abstraction removes details that are not important to the current objective while retaining influential relationships. Common levels include:

• Conceptual model: components, relationships, and causal structure;
• Steady-state model: equilibrium relationships, ignoring transients;
• Lumped-parameter dynamic model: masses, inertias, resistances, capacitances, and delays represented by a small number of variables;
• Distributed-parameter model: spatial variation represented by fields or partial differential equations;
• Component-detail model: switching, geometric, material, or electromagnetic details;
• Data-driven model: behavior inferred from measured input-output data.

A model should be no more detailed than necessary to make the decision with acceptable confidence. This principle is sometimes called fit-for-purpose modeling.

3.2 Physical, mathematical, computational, and surrogate models

A physical model represents physical mechanisms, such as Newtonian motion or electrical resistance. A mathematical model expresses those mechanisms as equations. A computational model specifies how equations are solved numerically. A surrogate model approximates a more expensive model or measured behavior for rapid evaluation.

For a rotational actuator, a simplified mechanical balance may be written as:

Here J is rotational inertia in kg·m², θ is angular position in rad, b is viscous damping in N·m·s/rad, τ_L is load torque in N·m, and τ_m is motor torque in N·m. The equation assumes a rigid lumped inertia, linear viscous damping, and torque quantities referred to the same shaft. It neglects backlash, elastic deformation, Coulomb friction, and time-varying inertia.

If a compliant transmission is important, two inertias and a torsional spring-damper may be required. If only average speed is relevant, the inertial term may be omitted under steady-state conditions, giving:

where ω = dθ/dt is angular velocity. This reduced equation is not generally valid during acceleration.

3.3 Linear and nonlinear models

A linear model satisfies superposition: the response to the sum of inputs equals the sum of responses to each input, and scaling an input scales the response. Linearization is often performed around an operating point. For a nonlinear function y = f(x), a first-order approximation near x₀ is:

The approximation is useful when deviations from x₀ are sufficiently small and the function is differentiable there. It may be misleading near saturation, friction transitions, impacts, geometric singularities, or unstable operating regions.

3.4 Continuous-time, discrete-time, and hybrid models

Physical dynamics are commonly represented in continuous time, while embedded controllers execute at discrete sampling instants. A simple discrete state model is:

Here x_k is the state at sample k, u_k is the input, y_k is the output, and p is a parameter vector. The subscript d indicates a discrete-time representation. Hybrid models combine continuous dynamics with discrete events such as switching, contact, mode changes, and fault responses.

Sampling time must be related to the fastest relevant dynamics. Choosing it too large can hide instability or alias important behavior; choosing it unnecessarily small increases computational effort. The appropriate value depends on bandwidth, numerical method, computation limits, and the purpose of the simulation.

4. Assumptions and Their Consequences

Assumptions make modeling possible, but every assumption removes a phenomenon. Good engineering practice records assumptions explicitly and classifies them as:

• Structural: rigid links, fixed topology, one-dimensional motion;
• Physical: negligible heat loss, linear friction, constant material properties;
• Operational: specified payload, speed range, duty cycle, and environment;
• Numerical: solver tolerance, step size, interpolation, and convergence rules;
• Data-related: parameter values, measurement accuracy, and calibration quality.

Each assumption should have a rationale and a validity range. For example, “neglect motor inductance” may be acceptable for a slow mechanical response study but unacceptable for current-loop design. “Assume no backlash” may be acceptable before mechanism selection but unacceptable for precision positioning.

A useful assumption register contains:

Assumptions should be revisited when requirements, operating conditions, or design architecture change.

5. Performance Measures and Acceptance Criteria

A model becomes useful when its outputs are linked to measurable criteria. Common measures for mechatronic systems include:

• rise time;
• peak time;
• overshoot;
• settling time;
• steady-state error;
• tracking error;
• bandwidth;
• energy consumption;
• peak force or torque;
• temperature;
• vibration amplitude;
• reliability or fault probability;
• computational latency.

For a reference signal r(t) and output y(t), the tracking error is:

A maximum absolute error over an interval [0,T] is:

The units of e_max are the units of the output. An integral absolute error can be defined as:

Its units are output-units × time. It penalizes accumulated error but does not by itself distinguish a brief large error from a longer small error as a safety limit would. Performance measures must therefore be chosen to reflect the requirement rather than convenience.

For a step response, percent overshoot is commonly defined when the final value is nonzero as:

where y_max is the maximum response and y_∞ is the final value. The definition is unsuitable when the final value is zero or when the response does not converge.

Acceptance criteria should distinguish:

• nominal performance;
• worst-case performance over tolerances;
• robustness to disturbances;
• safety limits;
• model uncertainty.

A simulation pass is not proof that the physical system will pass. It is evidence conditional on the model, assumptions, parameters, and test scenario.

6. Iterative Model Development

Model development is a cycle rather than a one-time sequence:

1. Define the decision and requirements.
2. Establish the boundary and interfaces.
3. Select states, inputs, outputs, and parameters.
4. State assumptions.
5. Build the simplest adequate model.
6. Verify equations, units, implementation, and numerical solution.
7. Validate against analytical results, experiments, or trusted references.
8. Perform sensitivity and uncertainty analysis.
9. Refine the model if discrepancies affect the decision.
10. Document results and update traceability.

Verification and validation

Verification asks: “Was the model implemented correctly?” Examples include checking conservation laws, dimensions, code logic, solver convergence, and limiting cases.

Validation asks: “Does the model represent the real system adequately for its intended use?” Validation requires comparison with observations, experiments, or credible benchmark data. A model can be verified yet invalid if its assumptions do not represent the physical system.

Sensitivity and uncertainty

Sensitivity analysis investigates how outputs change when inputs or parameters change. A local normalized sensitivity of output y to parameter p can be expressed as:

This dimensionless quantity is meaningful when y and p are nonzero and differentiable near the operating point. Large magnitude indicates that uncertainty in p may strongly influence y. For nonlinear or discontinuous systems, global parameter sweeps or sampling methods are more appropriate.

Uncertainty may arise from parameter tolerances, unmodeled physics, measurement noise, environmental variation, and numerical approximation. It is better to report a credible range or confidence statement than a falsely precise single value.

7. Worked Example: Modeling a Servo Positioning Axis

Consider an illustrative single-axis positioning mechanism driven by a motor. The requirement is to move a carriage 0.5 m with a 2 kg payload and achieve a final position error no greater than 0.5 mm. The settling time target is 0.8 s.

Step 1: Define the question

The first design question is whether a proposed actuator and controller can satisfy position accuracy and settling time. This does not initially require detailed winding geometry or transistor switching. A lumped mechanical model, actuator torque limit, sensor quantization, controller, and delay are sufficient for the first iteration.

Step 2: Select variables and assumptions

Assume:

• one-dimensional translation;
• rigid carriage and transmission;
• constant equivalent mass;
• linear viscous damping for the first iteration;
• no backlash initially;
• actuator force limited to 120 N;
• position measurement available at 1 kHz;
• disturbances represented by an external force.

The translational balance is:

where m is equivalent mass in kg, x is position in m, c is viscous damping in N·s/m, F_L is load or disturbance force in N, and F_a is actuator force in N. The model assumes linear viscous damping and rigid transmission.

Step 3: Estimate a basic acceleration limit

Ignoring damping and disturbance for a short acceleration interval, Newton’s law gives:

If the equivalent moving mass is 5 kg and the actuator force is 120 N, then:

This is an ideal acceleration limit, not a guaranteed trajectory performance. Force may be reduced by friction, voltage limits, thermal limits, or controller saturation.

Step 4: Define outputs

The simulation should report maximum position error, settling time, peak force, peak velocity, and sensitivity to mass, damping, delay, and sensor resolution. A nominal pass requires both position error ≤ 0.5 mm and settling time ≤ 0.8 s.

Step 5: Refine if necessary

If the first model passes comfortably, a second iteration may include Coulomb friction, backlash, actuator saturation, sampling, sensor quantization, and flexible transmission modes. If it fails, the engineer should determine whether the failure is caused by insufficient force, poor control tuning, delay, structural flexibility, or an unrealistic requirement.

The important conclusion is methodological: model complexity is justified by a decision-relevant discrepancy, not by a desire to represent every physical detail.

8. Applied Case: Illustrative Automated Pick-and-Place Cell

Background

An illustrative manufacturing cell uses a two-axis gantry to pick components from a conveyor and place them into trays. The cell contains linear motors, position sensors, a vision system, a programmable controller, safety interlocks, and a compressed-air gripper.

Problem

The initial design meets average cycle time in a simple simulation but occasionally misses the placement tolerance when conveyor speed changes. Stakeholders require a 1.2 s maximum cycle time, placement error no greater than 1 mm, and safe stopping when a guard is opened.

Analysis

A first model included commanded motion, ideal axis dynamics, and a fixed pick location. It omitted conveyor timing uncertainty, camera latency, sensor quantization, controller execution delay, and emergency-stop behavior. Verification showed that the equations and software were implemented correctly, but validation against measured trials revealed a systematic placement error during high conveyor speeds.

The team decomposed the problem into:

1. conveyor position estimation;
2. vision measurement and latency;
3. coordinate transformation;
4. trajectory generation;
5. axis dynamics and tracking;
6. gripper timing;
7. safety state transitions.

The modeling objective was revised from “simulate axis motion” to “predict placement error and cycle time under measured conveyor speed, sensing latency, and actuator limits.”

Approach and solution

The revised model represented camera latency as a time delay, included bounded conveyor-speed variation, and modeled the axes as discrete-time closed-loop systems. The team created test cases for nominal, minimum, and maximum conveyor speeds. A separate hybrid safety model represented normal operation, guarded stop, reset, and fault states.

Traceability linked the 1 mm placement requirement to the coordinate-transformation model, sensor uncertainty, axis tracking error, and validation measurements. The model was calibrated using recorded encoder and camera data, then tested on data not used for calibration.

Outcome

The refined model identified that camera latency, rather than motor force, dominated placement error at high conveyor speed. A timestamp synchronization correction and a predictive conveyor-position estimate reduced the predicted error below the requirement. The safety model also showed that a software stop command alone did not satisfy the required safe-stop behavior; a monitored hardware safety circuit was necessary.

Learning points

• A model must represent the dominant error mechanisms for its intended decision.
• Latency and interfaces can be as important as component dynamics.
• Safety behavior requires explicit modes, faults, and transitions.
• Validation should use independent operating data.
• Traceability exposes which requirement is supported by which evidence.

9. Professional Practice, Ethics, and Governance

Simulation results can influence safety, investment, product release, and public welfare. Engineers must not present a model as more certain than its evidence permits. Important governance practices include:

• documenting assumptions, parameter sources, and software versions;
• preserving model and data provenance;
• recording failed as well as successful tests;
• separating calibrated data from validation data;
• identifying the responsible engineer and approval status;
• protecting confidential and personal data;
• applying cybersecurity controls to connected simulation and digital-twin systems;
• using independent review for safety-critical decisions.

AI-assisted modeling can generate code, identify patterns, or construct surrogate models. However, generated equations and code require engineering verification. An AI system may reproduce hidden bias in data, omit physical constraints, or produce plausible but dimensionally incorrect relationships. Human accountability, independent checks, and transparent documentation remain essential.

10. Challenges and Limitations

Model-form error

A model may omit a mechanism such as backlash, hysteresis, thermal drift, or structural resonance. More data cannot fully correct a model-form error if the mechanism is absent.

Parameter uncertainty

Mass, friction, stiffness, sensor delay, and motor constants may vary with temperature, wear, manufacturing tolerance, and operating point. Nominal parameters should not be treated as universal constants without evidence.

Identifiability

Different parameter combinations can produce similar outputs. A model may fit available data while its individual parameters remain uncertain. Experiments should be designed to excite the dynamics needed for identification.

Numerical limitations

Poor scaling, inappropriate step size, discontinuities, and solver tolerances can create artificial behavior. Results should be checked for convergence and physical plausibility.

Overfitting and excessive complexity

A highly detailed model can match a particular data set but generalize poorly. It may also be too slow for optimization or real-time use. Complexity should be controlled by the modeling objective.

Best-Practice Checklist

Before accepting a mechatronic model, ask:

1. What decision will the model support?
2. Which requirement and acceptance criterion does each output address?
3. Is the system boundary explicit?
4. Are inputs, outputs, states, units, and interfaces defined?
5. Are assumptions documented with validity limits?
6. Has the model been verified independently of validation?
7. Has it been compared with measurements or a trusted benchmark?
8. Have sensitivity, uncertainty, and worst-case conditions been considered?
9. Are delays, saturation, quantization, faults, and safety modes relevant?
10. Can another engineer reproduce and audit the result?

Chapter Summary

Modeling begins with a decision, not with software. Stakeholder needs must be translated into measurable system requirements, modeling objectives, and acceptance criteria. A suitable model has a defined boundary, explicit interfaces, purposeful abstraction, documented assumptions, and outputs connected to requirements.

Functional and physical decomposition help manage mechatronic complexity. Physical, mathematical, computational, and surrogate models serve different purposes. Continuous, discrete, and hybrid representations should be selected according to system dynamics and implementation realities. Verification checks whether a model is implemented correctly; validation checks whether it represents the real system adequately for its intended use.

Iterative development is essential. Engineers should begin with the simplest adequate model, compare predictions with analytical results or experiments, perform sensitivity and uncertainty analysis, and add detail only when it affects the decision. Traceability connects requirements, model elements, test cases, outputs, and evidence. In professional practice, transparent assumptions, reproducibility, safety analysis, and responsible use of AI are as important as mathematical sophistication.

Key Terms

Model: A purposeful representation of a system or phenomenon.

Modeling objective: A statement of the question a model must answer and the decision it supports.

Requirement: A documented, verifiable need or constraint imposed on a system.

Traceability: The ability to link requirements, model elements, tests, and evidence.

System boundary: The defined separation between modeled elements and external influences.

Abstraction: Purposeful omission of details that are not relevant to the modeling objective.

Assumption: A condition accepted as true for constructing or using a model.

Functional decomposition: Division of a system according to the functions it performs.

Physical decomposition: Division of a system according to its physical components.

Interface: A defined connection through which information, energy, or material is exchanged.

State: A variable or set of variables that describes the dynamic condition of a system.

Parameter: A quantity characterizing a model whose value is normally fixed for a simulation case.

Verification: Checking whether a model or implementation was constructed correctly.

Validation: Checking whether a model adequately represents the real system for its intended use.

Sensitivity analysis: Study of how output changes in response to input or parameter changes.

Uncertainty: Lack of complete knowledge about parameters, inputs, model form, or measurements.

Hybrid model: A model combining continuous dynamics with discrete events or modes.

Acceptance criterion: A measurable rule used to decide whether a requirement is satisfied.

Surrogate model: A computationally efficient approximation of a detailed model or observed behavior.

Model-form error: Error caused by an inadequate representation of the underlying physical mechanisms.

Review Questions

Short Answer Questions

1. Why must stakeholder needs be translated into measurable system requirements before modeling?
2. Distinguish model verification from model validation.
3. What is the purpose of defining a system boundary?
4. Give two examples of information that should be specified at a subsystem interface.
5. Why should assumptions be recorded with validity limits?

Long Answer Questions

1. Explain how a requirement can be traced from a stakeholder need to a simulation output and verification report.
2. Compare conceptual, lumped-parameter, distributed-parameter, and data-driven models, including an appropriate use for each.
3. Explain how functional decomposition and physical decomposition complement one another in mechatronic modeling.
4. Discuss the advantages and limitations of beginning with a simplified model and refining it iteratively.
5. Describe how uncertainty, sensitivity, and model-form error affect confidence in simulation results.

Analytical / Application Questions

1. A servo axis meets its position requirement in simulation but fails when the payload changes and the sensor introduces a delay. Identify the likely omitted model elements and propose an iterative refinement and validation plan.
2. Design a traceability matrix for an automated pick-and-place system with requirements for cycle time, placement accuracy, energy use, and safe stopping. Specify suitable model outputs and evidence for each requirement.
3. A model predicts a peak actuator force of 95 N using a nominal mass, while the actuator limit is 100 N. Explain why this small margin may be inadequate and propose sensitivity, uncertainty, and worst-case analyses.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a modeling objective?

A. A broad statement that the product should be excellent

B. A question the model must answer to support a specific engineering decision

C. A list of every component in the final product

D. A record of software commands used to run a simulation

Correct Answer: B. A question the model must answer to support a specific engineering decision

Question 2

What is the primary purpose of a system boundary?

A. To define which elements are modeled and which are external inputs or disturbances

B. To guarantee that the model contains every physical phenomenon

C. To determine the commercial price of the system

D. To replace the need for interface specifications

Correct Answer: A. To define which elements are modeled and which are external inputs or disturbances

Question 3

Which activity is an example of verification?

A. Comparing predicted temperature with measurements from a prototype

B. Checking that units are consistent in the implemented equations

C. Asking an operator whether the product feels reliable

D. Changing parameters until a requirement is met

Correct Answer: B. Checking that units are consistent in the implemented equations

Question 4

In the equation e(t) = r(t) - y(t), what does e(t) represent?

A. Actuator saturation

B. System inertia

C. Tracking error

D. Sensor bandwidth

Correct Answer: C. Tracking error

Question 5

Which model is most appropriate when discrete mode changes and continuous physical dynamics both affect behavior?

A. A static model

B. A hybrid model

C. A purely conceptual model

D. A lookup table with no state variables

Correct Answer: B. A hybrid model

Question 6

Why might a detailed electromagnetic switching model be unnecessary during an initial actuator sizing study?

A. Switching behavior can never affect a mechatronic system

B. The model should be no more detailed than required by the decision

C. Detailed models cannot be verified

D. Actuator sizing does not require any physical assumptions

Correct Answer: B. The model should be no more detailed than required by the decision

Question 7

If m = 5 kg and F_a = 120 N, what ideal acceleration follows from a = F_a/m when damping and disturbance are neglected?

A. 6 m/s²

B. 24 m/s²

C. 115 m/s²

D. 600 m/s²

Correct Answer: B. 24 m/s²

Question 8

Which issue was identified as a dominant cause of high-speed placement error in the illustrative pick-and-place case?

A. Excessive motor winding resistance only

B. Camera latency and conveyor-position estimation

C. The color of the machine enclosure

D. The absence of a rigid system boundary

Correct Answer: B. Camera latency and conveyor-position estimation

Question 9

What does sensitivity analysis investigate?

A. How model outputs change when parameters or inputs change

B. Whether a requirement has been written in a legal format

C. Whether a computer has sufficient storage capacity

D. How many components are present in a system

Correct Answer: A. How model outputs change when parameters or inputs change

Question 10

Which practice is most appropriate when using AI-generated modeling code?

A. Accepting the code if its plots appear plausible

B. Removing all documentation to protect the method

C. Verifying equations, units, constraints, and results independently

D. Using generated output as experimental validation

Correct Answer: C. Verifying equations, units, constraints, and results independently