System Modeling and Hardware–Software Co-Design

Introduction

Embedded mechatronic products combine mechanical structures, sensors, actuators, electronics, communication networks, and software. Their behaviour is therefore not determined by hardware or software alone. A controller may be mathematically correct but unusable if its processor is too slow; a powerful processor may be unnecessary if a small microcontroller can satisfy timing, energy, and safety requirements. System modeling and hardware–software co-design provide disciplined methods for making these decisions before expensive implementation.

System modeling represents structure, behaviour, information flow, timing, and constraints using precise abstractions. Hardware–software co-design uses these models to decide which functions should execute in mechanical, analog, digital hardware, firmware, or higher-level software. The central engineering objective is not merely to minimize cost. It is to achieve an acceptable balance among performance, energy consumption, reliability, maintainability, integration risk, safety, and lifecycle cost.

Consider an automated positioning stage. Its design includes a motor, power driver, encoder, mechanical transmission, real-time controller, diagnostic software, and user interface. Position regulation may be implemented in a microcontroller, while current limiting may be performed by dedicated driver hardware. Logging and configuration may execute on a supervisory computer. A model makes these boundaries explicit and permits alternatives to be evaluated systematically.

Learning Objectives

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

1. Model embedded-system structure and behaviour using finite-state machines, UML, SysML, and data-flow representations.
2. Identify timing, memory, computation, communication, energy, safety, and interface constraints.
3. Partition system functions between mechanical elements, electronics, hardware accelerators, firmware, and application software.
4. Estimate processor utilization, memory requirements, communication load, latency, and energy.
5. Apply model-based design and simulation to reduce integration risk.
6. Compare design alternatives using technical, economic, safety, and maintainability criteria.

1. System Abstraction and the Modeling Process

A model is a deliberately simplified representation of a system. It is useful when it preserves information relevant to a decision while omitting irrelevant detail. A good embedded-system model normally describes four views:

• Structure: components, ports, interfaces, and physical organization.
• Behaviour: states, events, actions, control laws, and sequencing.
• Information flow: signals, data transformations, sampling, and communication.
• Constraints: timing, memory, energy, cost, safety, reliability, and environmental limits.

A practical modeling process begins with stakeholder needs and measurable requirements. Requirements are transformed into functions, functions into interacting blocks, and blocks into candidate implementations. The design is then simulated, allocated to hardware or software, verified, and refined.

A requirement should be testable. “The actuator shall respond quickly” is weak because “quickly” is undefined. “The controller shall produce a command within 2 ms of a valid sensor sample under nominal load” is measurable. Requirements should also identify operating conditions, tolerances, failure responses, and verification methods.

A useful traceability chain is:

Requirement → function → model element → implementation item → verification test.

Traceability is particularly important in safety-related systems because it shows why a design decision was made and whether every requirement has evidence of satisfaction.

2. Finite-State Machines for Embedded Behaviour

A finite-state machine (FSM) represents a system with a finite set of states, events, transitions, guards, and actions. A state describes a mode in which the system exhibits defined behaviour. An event causes evaluation of possible transitions. A guard is a Boolean condition that must be true for a transition to occur. An action is performed during a transition or while a state is active.

For example, a motorized door controller may contain the states Closed, Opening, Open, Closing, and Fault. A transition from Closing to Open may occur when the open-limit sensor becomes active. A transition to Fault may occur if excessive current is detected.

An FSM can be described formally as:

where S is the finite set of states, E is the set of events, T is the transition relation, s₀ is the initial state, and A is the set of actions. The notation is a modeling abstraction rather than a single implementation algorithm. It assumes that relevant behaviour can be represented by a finite number of identifiable modes.

A transition may be written as:

For example:

FSM design must address:

• Completeness: every relevant event has a defined response.
• Determinism: conflicting transitions do not produce unpredictable results.
• Safety: hazardous states and transitions are explicitly represented.
• Recovery: communication loss, sensor failure, and watchdog reset have defined behaviour.
• Time: deadlines, timeouts, and minimum dwell times are modeled.

Hierarchical state machines reduce complexity by grouping related states. A system may have a top-level operational state and nested states for calibration, motion, and diagnostics. Orthogonal regions represent concurrent behaviours, such as motion control operating simultaneously with communication monitoring. FSMs are excellent for sequencing and modes, but they are less suitable for continuous dynamics; those require differential equations, transfer functions, or numerical simulation.

3. UML and SysML in Mechatronic Design

UML is widely used for software and system behaviour. Relevant diagrams include use-case, activity, state-machine, sequence, class, and component diagrams. SysML extends systems modeling toward requirements, physical systems, interfaces, and parametric relationships. In mechatronics, SysML is valuable because it can represent mechanical, electrical, and software elements in one architecture.

A requirements diagram identifies stakeholder needs and relationships such as derive, satisfy, verify, and refine. A block definition diagram describes system blocks and their general relationships. An internal block diagram shows parts, ports, connectors, and item flows. A parametric diagram links model parameters to equations or constraints.

For example, an autonomous conveyor system may contain blocks for the frame, drive motor, motor inverter, optical sensor, embedded controller, safety relay, and operator panel. A connector between the sensor and controller should specify more than “signal.” It may identify voltage range, update rate, connector type, data encoding, and fault behaviour.

The distinction between a physical connection and a logical flow is important. A CAN bus is a physical and data-link communication mechanism; a “speed command” is a logical item flowing across it. Mixing these levels can hide bandwidth, timing, and failure assumptions.

Modeling tools do not automatically produce correct designs. Ambiguous names, undocumented assumptions, excessive detail, and inconsistent units can make a sophisticated model misleading. Models should therefore be reviewed by engineers from mechanical, electrical, software, controls, and safety disciplines.

4. Data-Flow and Computational Models

A data-flow model represents computation as transformations connected by data paths. Typical blocks include sensor acquisition, filtering, coordinate transformation, control-law calculation, saturation, diagnostics, and actuator output.

A sampled control loop can be represented as:

Sensor → conditioning → state estimation → controller → limiting → actuator driver → plant → sensor.

The model should identify sampling rates, data types, buffering, synchronization, and communication delays. A data-flow graph is especially useful for identifying parallelism and deciding which operations could be implemented in dedicated hardware.

If a task produces N bytes per second and each message contains B payload bytes, the approximate message rate is:

where rₘ is in messages per second. If each message also has H overhead bytes, the transmitted byte rate is:

This estimate assumes fixed-size messages and excludes lower-layer bit stuffing, inter-frame gaps, acknowledgements, and retransmissions. For a bus with bit rate C, the ideal utilization is:

where R is in bytes per second and C is in bits per second. Real utilization is higher when protocol overhead and arbitration are included. A design should retain margin for bursts and worst-case traffic, not merely average traffic.

Worked Example: Communication Load

A controller sends 16-byte status messages at 100 messages/s. Each message has 6 bytes of protocol overhead. The payload rate is 1,600 bytes/s. The transmitted rate is:

For a 1 Mbit/s bus, the idealized utilization is:

The result is well below the nominal bus capacity, but priority, worst-case bursts, error retransmissions, and other nodes must still be considered.

5. Model-Based Design and Simulation

Model-based design uses an executable model as a central engineering artifact. The model may include plant dynamics, sensors, actuators, controller logic, timing, and fault conditions. It supports several levels of verification:

• Model-in-the-loop (MIL): control algorithms are tested against a simulated plant.
• Software-in-the-loop (SIL): production-oriented software executes against a simulated plant.
• Processor-in-the-loop (PIL): compiled code runs on the target processor while the plant remains simulated.
• Hardware-in-the-loop (HIL): real controller hardware interacts with a real-time plant simulator.
• Prototype or system testing: the complete physical system is evaluated.

This progression can expose errors early. MIL may reveal an unstable control law; SIL may reveal numerical or data-type problems; PIL may reveal processor limitations; HIL may reveal I/O timing, communication, and fault-response problems.

A model is not a substitute for physical testing. Simulation depends on model fidelity. Friction, backlash, saturation, quantization, sensor noise, electromagnetic interference, thermal effects, and manufacturing variation may be omitted or inaccurately represented. Verification therefore requires both simulation and empirical evidence.

For a sampled controller, the sampling period Tₛ should be selected with respect to system dynamics and computational delay. There is no universal ratio that guarantees performance, but the sample rate must be sufficiently faster than the important closed-loop dynamics and must leave time for computation, communication, and actuation. Excessively slow sampling causes lag and degraded control; excessively fast sampling increases processor load and energy without necessarily improving performance.

6. Hardware–Software Partitioning

Partitioning assigns functions to implementation domains. Typical choices include:

• mechanical mechanisms and passive safety elements;
• analog conditioning and protection circuits;
• programmable logic or dedicated digital hardware;
• microcontroller firmware;
• real-time operating-system tasks;
• application software on an embedded processor;
• supervisory, cloud, or engineering software.

A function is a good candidate for dedicated hardware when it requires very low latency, high deterministic throughput, parallel processing, or direct safety enforcement. Software is attractive when algorithms change frequently, product variants are expected, or complex decision logic is required. Analog implementation may be appropriate for filtering, protection, or very low-latency signal conditioning, but calibration and component variation must be considered.

Partitioning criteria include:

Partitioning is a multi-objective decision. A weighted decision score can support comparison:

where nᵢ is a normalized score for criterion i, wᵢ is its weight, and ∑wᵢ = 1. The meaning of “higher is better” must be established before scoring. Normalization must be documented because a weighted score does not replace engineering judgment or safety analysis.

A practical partitioning workflow is:

1. Identify functions and their interfaces.
2. Assign timing, precision, throughput, safety, and update requirements.
3. Generate at least two plausible allocations.
4. Estimate resources and bottlenecks.
5. Evaluate interfaces, failure modes, verification effort, cost, and lifecycle effects.
6. Prototype the riskiest assumptions.
7. Record the rationale and trace it to requirements.

7. Resource and Performance Estimation

Processor Utilization

For periodic tasks, an approximate processor utilization is:

where Cᵢ is the worst-case execution time of task i and Tᵢ is its period. Both must use the same time unit. This estimate assumes independent periodic tasks and does not by itself prove schedulability. Interrupts, blocking, context switches, cache effects, DMA, and operating-system overhead must be included in a realistic analysis.

Worked Example: CPU Load

Suppose three periodic tasks have the following worst-case execution times and periods:

Thus:

The remaining 65% is not automatically available for all purposes because interrupt bursts, communication, startup activity, and safety tasks require margin. A design review should also examine worst-case response time, not only average utilization.

Memory Estimation

Memory demand can be divided into program memory, constant data, static variables, stacks, dynamic buffers, communication queues, and diagnostic records. A first estimate is:

The terms must use the same unit, such as bytes. Mₒₕ represents overhead and engineering margin. Stack usage should be measured or bounded, especially with recursion, nested interrupts, and multiple threads.

Latency and Jitter

Latency is the time between an event and the corresponding response. Jitter is variation in latency or execution timing. A control loop may fail even when average latency is acceptable if worst-case latency violates the stability or safety requirement. Models should therefore distinguish average, maximum, and deadline-miss behaviour.

Energy

Electrical energy over an interval is:

where P(t) is power in watts and E is energy in joules. For approximately constant power, E ≈ P∆t, with time in seconds. Average power over an interval is:

Energy optimization may involve reducing computation, lowering clock frequency, using sleep modes, shortening active time, reducing communication, or improving the actuator and power stage. These alternatives can conflict with response time and reliability.

8. Interfaces, Integration, and Risk

Many embedded failures occur at interfaces rather than inside individual components. Interface specifications should define units, ranges, rates, timing, ownership, initialization, error codes, electrical levels, endian representation, scaling, and fault behaviour.

A sensor value may be represented as:

where xᵣₐw is the measured digital value, a is the scale factor with physical units per count, and b is the offset in physical units. The equation assumes a linear calibration over the specified operating range. Saturation, nonlinear calibration, and invalid codes must be documented separately.

Integration risk increases when assumptions are untested, interfaces are unstable, tools are immature, or hardware and software teams develop against different interpretations. Risk reduction practices include interface control documents, versioned models, automated tests, hardware abstraction layers, simulation stubs, continuous integration, and incremental integration.

Failure Mode and Effects Analysis (FMEA) examines possible failure modes, their causes, effects, detection methods, and controls. Fault-tree analysis begins with a hazardous top event and reasons backward through logical combinations of causes. These techniques complement behavioral models: an FSM describes intended operation, while safety analysis examines deviations from it.

9. Illustrative Case: Smart Conveyor Sorting Cell

Background

The following is a fictional illustrative case. A conveyor sorts packages according to barcode and weight. The cell contains an encoder, optical sensor, barcode reader, load cell, motor inverter, pneumatic diverter, safety guard, and embedded controller.

Problem

The initial proposal placed all functions in a general-purpose industrial computer. The design met average throughput but exhibited uncertain response when barcode processing and database communication occurred simultaneously. The safety engineer also questioned whether a software command alone could guarantee that the diverter stopped during an emergency.

Analysis

The team modeled the system with:

• a SysML block model for the conveyor, sensors, controller, inverter, diverter, guard, and operator panel;
• a data-flow model for sensing, classification, tracking, and actuation;
• an FSM with Idle, Running, Tracking, Diverting, Jam, Emergency Stop, and Recovery states;
• timing constraints for encoder sampling and diverter actuation;
• a fault model covering sensor disagreement, communication loss, and pneumatic pressure failure.

The model showed that package tracking required deterministic encoder processing, whereas barcode interpretation and production reporting were computationally variable. The emergency-stop path also required an independent, fail-safe interruption of actuator energy.

Approach and Solution

The functions were repartitioned as follows:

1. Encoder capture and timestamping were assigned to timer capture hardware.
2. High-rate package tracking and motion control were assigned to a real-time microcontroller task.
3. Barcode decoding was retained on the industrial computer.
4. A safety relay removed hazardous actuator energy independently of the application processor.
5. Production data were buffered and transmitted asynchronously so reporting could not delay motion control.
6. HIL testing reproduced sensor timing, delayed communication, and jam conditions.

The interface model specified timestamp units, encoder resolution, message priorities, timeout values, and invalid-data handling. The state model prohibited diverting when the safety chain was open or package position was uncertain.

Outcome

The revised design separated deterministic control from variable information processing. It reduced integration risk because each boundary had explicit timing and fault rules. The design also improved maintainability: barcode software could be updated without changing the real-time control firmware. Safety was improved because emergency stopping did not depend solely on a general-purpose software process.

Learning Points

The case demonstrates that partitioning is not simply a matter of placing computation where processor capacity is available. It must consider determinism, safety independence, data ownership, update strategy, and failure containment. Modeling exposed architectural problems before full integration.

10. Maintainability, Safety, and Governance

A maintainable design uses clear module boundaries, stable interfaces, meaningful names, automated tests, configuration control, and documented assumptions. Excessive coupling increases the effect of change. A useful design principle is to isolate volatile functions, such as communication protocols or user interfaces, from stable control and safety functions.

Safety-critical functions should follow applicable standards and organizational processes. Depending on the application, relevant standards may include IEC 61508 for functional safety, ISO 13849 or IEC 62061 for machinery safety, ISO 26262 for road vehicles, and IEC 62304 for medical-device software. The exact standard, safety integrity target, and compliance process depend on the product and jurisdiction. Standards do not guarantee safety; they provide structured expectations for hazard analysis, development, verification, independence, and evidence.

Cybersecurity is increasingly part of co-design. A networked actuator may be physically safe under ordinary faults but unsafe if unauthorized commands are accepted. Threat modeling, authenticated updates, secure boot, least privilege, key management, logging, and vulnerability response should be considered from the architecture stage. Security controls consume memory, computation, energy, and development effort, so they must be modeled rather than added casually at the end.

Artificial intelligence may be integrated into perception or predictive maintenance, but AI components introduce uncertain behavior, data dependence, model drift, and verification challenges. A robust architecture should bound AI authority, monitor confidence, define fallback modes, protect data, and ensure that safety-critical limits remain enforceable independently of a statistical prediction.

11. Contemporary Design Practices and Limitations

Modern embedded development increasingly uses digital twins, executable requirements, automatic code generation, containerized development tools, virtual commissioning, and continuous hardware–software integration. These practices can shorten iteration cycles and improve traceability. However, automatic code generation does not eliminate the need to verify generated code, numerical behavior, timing, compiler assumptions, and target-specific effects.

Common limitations include:

• models that omit physical nonidealities;
• optimistic average-case resource estimates;
• hidden timing introduced by networks or operating systems;
• inconsistent units and coordinate conventions;
• excessive dependence on proprietary tools;
• inadequate version control of models and generated artifacts;
• failure to model degraded and recovery modes;
• confusing functional correctness with safety or cybersecurity.

Best practice is to maintain a small number of authoritative models, define ownership, review interfaces, automate consistency checks, test assumptions early, and preserve traceability from requirement to evidence. The model should be detailed enough to support decisions but simple enough that engineers can understand and challenge it.

Chapter Summary

System modeling provides a common language for the multidisciplinary nature of mechatronics. Structural models describe components and interfaces; finite-state machines describe modes and transitions; data-flow models describe computation and information movement; and SysML/UML organize requirements, behavior, structure, and verification relationships. Model-based design supports progressive verification through MIL, SIL, PIL, HIL, and physical testing.

Hardware–software co-design partitions functions according to timing, determinism, flexibility, energy, cost, safety, and maintainability. Resource estimates for processor utilization, memory, communication, latency, and energy provide early evidence, but worst-case behavior and interface assumptions must also be examined. Safety analysis, cybersecurity, traceability, configuration control, and independent protection mechanisms are essential in dependable systems. The most effective design process combines executable models with engineering judgment, prototypes, measurements, and disciplined integration.

Key Terms

Finite-state machine: A model consisting of states, events, transitions, guards, and actions.

State: A defined mode of operation with characteristic behavior.

Guard: A Boolean condition that permits a transition.

UML: A standardized modeling language widely used for software and system behavior.

SysML: A systems-modeling language extending UML concepts for multidisciplinary engineering.

Block: A structural modeling element representing a system or component.

Data-flow model: A representation of transformations and movement of data through a system.

Model-based design: Development using an executable or analyzable model as a central artifact.

MIL: Model-in-the-loop testing using simulated algorithms and plant models.

SIL: Software-in-the-loop testing of software against a simulated plant.

HIL: Hardware-in-the-loop testing with real controller hardware and a real-time simulated plant.

Partitioning: Allocation of functions among hardware, software, mechanics, and electronics.

Worst-case execution time: The maximum execution time assumed for a task under specified conditions.

Jitter: Variation in timing or latency.

Traceability: The documented relationship between requirements, design elements, implementation, and tests.

FMEA: Failure Mode and Effects Analysis, a structured examination of possible failures.

Fault tree: A deductive model connecting a hazardous event to contributing causes.

Interface control document: A controlled specification of interfaces, data, timing, and responsibilities.

Digital twin: A digital representation linked to a physical system or process.

Review Questions

Short Answer Questions

1. What are the principal elements of a finite-state machine?
2. Distinguish model-in-the-loop from hardware-in-the-loop testing.
3. Why must communication interfaces specify units and timing, not only signal names?
4. State two reasons for assigning a function to dedicated hardware.
5. What is the purpose of traceability in a mechatronic development project?

Long Answer Questions

1. Explain how UML and SysML can be combined to model a multidisciplinary embedded system.
2. Discuss the major criteria used when partitioning a function between hardware and software.
3. Explain why average processor utilization is insufficient to prove real-time schedulability.
4. Describe a model-based verification workflow from algorithm development to physical testing.
5. Discuss how safety, cybersecurity, and maintainability influence system architecture.

Analytical / Application Questions

1. A controller has tasks with execution times of 0.1 ms, 0.4 ms, and 1.2 ms, and periods of 1 ms, 4 ms, and 20 ms respectively. Calculate approximate processor utilization and identify additional information required before claiming schedulability.
2. Design a finite-state machine for an automated gate that includes normal operation, obstruction detection, emergency stop, sensor failure, and recovery. State the guards and safety actions that should be included.
3. For a networked robotic actuator, propose a hardware–software partition that preserves deterministic motion control while allowing secure remote monitoring. Justify the partition using timing, safety, energy, and maintainability criteria.

Multiple Choice Questions with Answers

Question 1

Which element of a finite-state machine determines whether a transition is permitted?

A. Guard

B. Payload

C. Compiler

D. Calibration table

Correct Answer: A. Guard

Question 2

What is the primary purpose of a data-flow model?

A. To show transformations and movement of information

B. To specify only the mechanical dimensions

C. To replace all physical testing

D. To calculate manufacturing wages

Correct Answer: A. To show transformations and movement of information

Question 3

A task executes for 0.2 ms every 1 ms. Its approximate processor utilization is:

A. 5%

B. 20%

C. 50%

D. 80%

Correct Answer: B. 20%

Question 4

Which verification stage uses real controller hardware with a real-time simulated plant?

A. MIL

B. SIL

C. HIL

D. Code review

Correct Answer: C. HIL

Question 5

A function requiring highly deterministic, very low latency is often a candidate for:

A. Dedicated hardware

B. An unbounded background process

C. A user manual

D. A cloud-only service

Correct Answer: A. Dedicated hardware

Question 6

In the communication estimate R = rₘ × (B + H), what does H represent?

A. Sampling frequency

B. Protocol overhead in bytes per message

C. Bus voltage

D. Motor efficiency

Correct Answer: B. Protocol overhead in bytes per message

Question 7

Why is a safety relay useful in the conveyor case?

A. It independently removes hazardous actuator energy

B. It increases barcode resolution

C. It replaces all diagnostic software

D. It guarantees unlimited bus bandwidth

Correct Answer: A. It independently removes hazardous actuator energy

Question 8

Which statement about average processor utilization is correct?

A. It alone proves every deadline will be met

B. It is irrelevant to embedded systems

C. It is an estimate that must be supplemented by timing and schedulability analysis

D. It measures memory capacity

Correct Answer: C. It is an estimate that must be supplemented by timing and schedulability analysis

Question 9

What relationship is central to design traceability?

A. Requirement to design element to implementation to verification

B. Supplier to invoice to tax return

C. Motor speed to paint color to packaging

D. Clock frequency to screen brightness only

Correct Answer: A. Requirement to design element to implementation to verification

Question 10

Which issue is especially associated with AI components in embedded systems?

A. Model drift and difficult verification of statistical behavior

B. The impossibility of using sensors

C. Automatic elimination of cybersecurity threats

D. Guaranteed deterministic output in all conditions

Correct Answer: A. Model drift and difficult verification of statistical behavior