Embedded Computing and Real-Time Control

Introduction and Context

An Internet of Things (IoT) node in a mechatronic system is more than a sensor connected to a network. It is an embedded computer that acquires physical data, makes decisions, drives actuators, communicates with other systems, stores information, and remains safe when components or communication links fail. In a production line, for example, an IoT node may measure motor vibration, regulate position, report energy consumption, and place the machine in a safe state when an encoder becomes unreliable.

Embedded computing is therefore the foundation on which industrial IoT intelligence is built. The central engineering challenge is to combine computational capability with predictable timing, limited resources, electrical safety, maintainability, and reliable interaction with the physical world. This chapter develops those foundations for mechatronics engineers.

Learning Objectives

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

1. Distinguish microcontroller-based systems, embedded Linux systems, and real-time operating systems.
2. Explain the roles of firmware, bootloaders, device drivers, hardware abstraction layers, and application software.
3. Design a basic interrupt-driven and scheduled embedded application.
4. Analyze sampling, control-loop timing, latency, jitter, and actuator update behavior.
5. Select appropriate local storage, diagnostic, watchdog, and fault-handling mechanisms.
6. Integrate sensors, actuators, power electronics, and software safely.
7. Apply these concepts to the design of a robust IoT-enabled mechatronic node.

1. Embedded Computing as a Cyber-Physical Foundation

An embedded system is a computer designed as part of a larger product or machine. Unlike a general-purpose desktop, it is usually optimized for a defined set of functions, constrained by cost and power, and required to respond to physical events within known time limits.

A typical IoT mechatronic node contains:

• Sensors: encoders, thermocouples, accelerometers, pressure sensors, and current sensors.
• Signal conditioning: amplification, filtering, isolation, level shifting, and analogue-to-digital conversion.
• Processing hardware: a microcontroller unit (MCU), microprocessor unit (MPU), or system-on-chip (SoC).
• Actuator interfaces: pulse-width modulation (PWM), digital outputs, analogue outputs, motor-control peripherals, or fieldbus interfaces.
• Communication: Ethernet, Wi-Fi, Bluetooth Low Energy, CAN, RS-485, Modbus, or an industrial Ethernet protocol.
• Software: boot firmware, drivers, middleware, control algorithms, diagnostics, and communication services.
• Power and protection: regulation, fusing, isolation, reverse-polarity protection, surge protection, and emergency-stop interfaces.

The design must preserve a boundary between deterministic local control and less predictable network functions. A network message may be delayed or lost; a motor current-control loop cannot normally wait for a cloud response. Consequently, safety-critical and time-critical functions should execute locally, while cloud systems are used for supervision, optimization, fleet management, and historical analysis.

Figure: Local sensing and control are separated from supervisory network functions.

2. Microcontrollers, Embedded Linux, and System Partitioning

2.1 Microcontrollers

An MCU integrates a processor core, memory, timers, communication peripherals, analogue interfaces, interrupt hardware, and general-purpose input/output on one device. MCUs are well suited to motor control, sensor acquisition, battery-powered nodes, and deterministic control loops. They generally have modest memory and may execute a single firmware image without a full operating system.

Important MCU resources include:

• Flash or non-volatile memory for program code and persistent configuration.
• RAM for variables, stacks, buffers, and task data.
• Timers and capture/compare units for precise periodic events and PWM.
• ADC and DAC peripherals for analogue signals.
• DMA for transferring data without continuous CPU intervention.
• Interrupt controller for responding to hardware events.
• Brown-out and watchdog circuits for recovery from abnormal operation.

2.2 Embedded Linux

Embedded Linux is used when an application needs substantial memory, a file system, graphical interfaces, complex networking, containers, or high-level software libraries. It normally runs on an MPU or powerful SoC with external RAM and storage. Linux provides process isolation, networking stacks, device models, permissions, and mature development tools.

Standard Linux is not automatically hard real-time. Scheduling, virtual memory, drivers, and other processes can introduce variable delays. A real-time Linux configuration, careful driver design, CPU isolation, and measurement can improve predictability, but hard timing guarantees require explicit engineering evidence. A common architecture uses an MCU for fast control and an embedded Linux computer for user interfaces, data aggregation, and connectivity.

2.3 Choosing a Platform

Platform selection should be based on timing, computational workload, safety, power, maintainability, and lifecycle requirements rather than processor speed alone.

3. Firmware Architecture and Hardware Abstraction

Firmware is software stored in non-volatile memory that controls an embedded device. A robust firmware architecture separates responsibilities into layers:

1. Bootloader: initializes essential hardware, validates and selects an application image, and may support field updates.
2. Board-support package: configures clocks, pins, memory, and board-specific peripherals.
3. Device drivers: provide controlled access to ADCs, timers, encoders, buses, displays, and storage.
4. Hardware abstraction layer (HAL): exposes reusable interfaces while hiding register-level details.
5. Middleware: implements protocols, file systems, cryptography, serialization, and RTOS services.
6. Application layer: implements state machines, control laws, diagnostics, and product behavior.

This separation limits the effect of hardware changes. For example, an application should request read_motor_current() through a defined interface rather than directly manipulating ADC registers. Drivers must document units, scaling, valid ranges, timing, error codes, and concurrency assumptions.

Device Drivers

A driver translates software requests into hardware operations. A good driver should:

• initialize the peripheral into a known state;
• validate parameters and handle unavailable hardware;
• expose timeout and error information;
• prevent unsafe output activation during startup;
• protect shared registers and buffers from concurrent access;
• provide diagnostic counters and status information.

A driver is not merely a collection of register writes. It is a safety and abstraction boundary. Poor drivers can create race conditions, stale data, incorrect units, and hidden timing delays.

Boot and Update Integrity

A boot process should establish safe outputs before enabling actuators. It should verify firmware integrity, preserve a recoverable update path, and avoid activating an image that is incomplete or incompatible. Cryptographic authenticity is stronger than a simple checksum: a checksum detects accidental corruption, whereas a digital signature can establish that an image was authorized, assuming keys and verification procedures are properly managed.

4. Real-Time Concepts

A real-time system is one in which correctness depends on both the computed result and the time at which it is produced. A late braking command may be incorrect even if its numerical value is perfect.

• Hard real-time: missing a deadline is unacceptable or potentially dangerous.
• Firm real-time: a late result has no value, but occasional misses may be tolerated.
• Soft real-time: late results reduce quality but do not invalidate the system.

Key timing terms are:

• Period: interval between recurring activations.
• Deadline: latest acceptable completion time.
• Latency: delay between an event and the start or completion of its response.
• Jitter: variation in latency or period.
• Execution time: processor time required by a task.
• Response time: release-to-completion time, including interference and blocking.

For a periodic task with period T, frequency f is:

Here, T is in seconds and f is in hertz. The relation assumes a regular periodic task. A 1 ms sampling period therefore corresponds to 1000 Hz.

A useful utilization measure for a set of tasks is:

where Cᵢ is the worst-case execution time of task i and Tᵢ is its period. U is dimensionless. This is a workload indicator, not by itself a proof of schedulability. Context-switch overhead, interrupt execution, blocking, cache effects, and deadline requirements must also be considered.

5. Interrupts, Polling, and Scheduling

Interrupts

An interrupt allows hardware to request processor attention when an event occurs. Examples include an encoder edge, timer expiry, ADC conversion completion, receive-buffer event, or fault input.

An interrupt service routine (ISR) should be short and deterministic. It should capture essential data, clear the interrupt source, record a timestamp or status, and signal deferred processing. Lengthy parsing, dynamic memory allocation, blocking calls, and complex control algorithms generally belong outside the ISR.

Interrupt priority must reflect consequence and timing. A high-frequency timer interrupt may outrank a low-priority communication interrupt, while an emergency fault input may require a separate hardware path that does not depend on software scheduling.

Polling

Polling repeatedly checks a status flag. It is simple and sometimes appropriate for slow devices or non-critical diagnostics, but it can waste CPU time and introduce response delay. A hybrid design often uses interrupts for urgent events and scheduled polling for health checks.

Cooperative and Preemptive Scheduling

In cooperative scheduling, tasks run until they yield. It is simple and can be predictable if every task has a bounded execution time, but one faulty task can delay all others. In preemptive scheduling, the scheduler can suspend a running task in favor of a higher-priority task. This improves responsiveness but introduces context-switch, synchronization, and priority-inversion concerns.

An RTOS typically provides tasks, priorities, timers, queues, semaphores, mutexes, event flags, and memory-management services. RTOS use is not a substitute for analysis. Developers must define task periods, priorities, worst-case execution times, stack sizes, blocking limits, and failure behavior.

Synchronization and Data Sharing

Shared data between an ISR and a task should be designed deliberately. A single atomic flag may be sufficient for event notification; a ring buffer is useful for streams; a mutex may protect a multi-step transaction. A mutex should not be used inside an ISR. A priority-inversion problem occurs when a high-priority task waits for a resource held by a low-priority task while a medium-priority task continues executing. Priority inheritance or priority ceiling protocols can reduce this risk.

6. Sampling and Digital Control Loops

A feedback loop measures a plant output, compares it with a reference, calculates a control action, and applies that action through an actuator. The loop must execute quickly and consistently enough to represent the plant dynamics.

For a discrete proportional-integral-derivative (PID) controller, define error at sample k as:

where r[k] is the reference and y[k] is the measured output. A commonly implemented positional form is:

Here, u[k] is the control command, Kₚ is proportional gain, Kᵢ is integral gain, Kᵈ is derivative gain, and Tₛ is the sampling period. The equation assumes a fixed sample period and ideal numerical representation. Practical implementations require output limits, anti-windup, derivative filtering, sensor validation, and consideration of actuator saturation.

The derivative term is sensitive to measurement noise. A filtered derivative or a derivative taken on the measured signal may be used, depending on the control objective. Integral windup occurs when the integrator continues accumulating error while the actuator is saturated. Conditional integration, back-calculation, or integrator clamping can reduce this problem.

Sampling Requirements

Sampling too slowly can miss plant behavior and cause phase delay. Sampling too quickly increases computational load and may amplify measurement noise without improving control. The sampling frequency must be selected from plant bandwidth, sensor characteristics, computational capacity, and stability analysis. The Nyquist condition states that a band-limited signal with maximum frequency fₘₐₓ requires a sampling frequency greater than 2fₘₐₓ for ideal reconstruction, but control systems generally use additional margin because filtering, phase delay, and non-ideal behavior matter.

Timing Example

Suppose a position loop runs every 2 ms. Its frequency is:

If the loop computation takes 0.35 ms and related sensor and communication processing takes 0.25 ms in the same period, the basic execution demand is 0.60 ms per 2 ms, or 30% of one processor’s time, before operating-system overhead and other tasks. This does not prove that the design is safe; worst-case execution time and interference must be measured.

A sample that arrives 0.8 ms late may cause a substantially different effective delay than a sample that arrives on time. Therefore, average loop time is insufficient: maximum latency and jitter are important acceptance criteria.

7. Local Storage and Data Integrity

Local storage supports configuration, event logs, calibration values, buffered measurements, and recovery after network loss. Common media include internal flash, external NOR flash, EEPROM, SD cards, and eMMC.

Important design issues include:

• Endurance: flash cells tolerate a finite number of write cycles.
• Wear leveling: writes are distributed to avoid early failure of one location.
• Atomicity: a power loss must not leave a partially updated configuration.
• Data validity: records should include version, length, timestamp, and integrity information.
• Retention: data should remain valid over the required temperature and service life.
• Capacity and rate: storage must accommodate the measurement rate and retention period.

For a log that records N samples per second, with B bytes per sample, for D days, the raw storage requirement is:

where S is in bytes and D is in days. Metadata, file-system overhead, reserved space, and redundancy must be added. For example, 10 samples/s, 24 bytes/sample, and 7 days require 10 × 24 × 7 × 86,400 = 145,152,000 bytes, approximately 145 MB before overhead.

A robust configuration update can use a two-slot scheme: write the new record to an inactive slot, verify it, then mark it valid with a sequence number. At startup, the system selects the newest valid record. This prevents a power interruption from destroying the only valid configuration.

8. Diagnostics, Watchdogs, and Fault Handling

Diagnostics should make failures observable and actionable. Useful diagnostic information includes sensor range violations, communication counters, reset causes, task execution statistics, storage errors, supply-voltage alarms, thermal warnings, and actuator-limit events.

A watchdog timer resets or places the system into a defined state if software fails to refresh it within a required interval. The watchdog should not be refreshed blindly by an always-running idle loop. A stronger design requires critical tasks to report healthy operation to a supervisor, which refreshes the watchdog only when all required conditions are satisfied.

Fault handling should distinguish:

• Detected faults: identified by plausibility checks, timeouts, or hardware flags.
• Latent faults: present but not currently activated.
• Transient faults: temporary disturbances such as electromagnetic interference.
• Permanent faults: hardware or software failures requiring service.

A safe response depends on the hazard. It may involve disabling torque, opening a safety relay, reducing speed, holding the last safe value, switching to a redundant sensor, or entering a controlled shutdown. Safety functions must not rely solely on a general-purpose IoT network or an unverified software message.

9. Safe Hardware–Software Integration

Electrical and software design are inseparable in mechatronics. A software assumption about a logic level, sensor polarity, actuator default state, or grounding arrangement can cause physical damage.

Best practices include:

1. Define the power-up state of every actuator output.
2. Use hardware enable lines and independent emergency-stop circuits where required.
3. Verify voltage levels, current limits, isolation ratings, and connector pinouts.
4. Protect inputs from overvoltage, reverse polarity, electrostatic discharge, and transients.
5. Use galvanic isolation when ground potential differences or hazardous voltages exist.
6. Validate ADC scaling and sensor calibration against traceable references.
7. Separate high-current switching paths from sensitive analogue paths.
8. Use grounding, shielding, filtering, and PCB layout practices appropriate to electromagnetic compatibility.
9. Test abnormal conditions, including unplugged sensors, short circuits, brownouts, communication loss, and corrupted configuration.
10. Document assumptions, limits, and recovery actions.

Functional safety standards such as IEC 61508 and sector-specific standards may apply depending on the machine and hazard. Cybersecurity standards and regulations may also require secure boot, authenticated updates, access control, vulnerability management, and event logging. The exact compliance obligations depend on jurisdiction, industry, and product classification; engineers must consult applicable standards rather than treating a generic IoT security checklist as sufficient.

10. Illustrative Case: Networked Conveyor Positioning Node

Background

Consider an illustrative packaging-line conveyor that indexes trays to a robotic pick point. The node contains a quadrature encoder, a motor drive interface, a photoelectric sensor, a temperature sensor, and Ethernet connectivity to a supervisory system.

Problem

The conveyor occasionally stops at different positions. Network logs show that some commands are delayed during production reporting. Operators also report that a restart can briefly energize the motor before the controller has validated the encoder.

Analysis

The original design uses network commands directly in the motion loop. Encoder processing is performed by a low-priority task, while a communication task occasionally performs lengthy logging operations. Configuration is written to flash on every parameter change, risking wear. The startup sequence enables the motor before sensor plausibility has been established.

The essential distinction is between the local real-time path and the supervisory path. Position acquisition, motion sequencing, limit checking, and motor enable must remain local. Ethernet should carry setpoints, status, and diagnostics but must not determine whether a time-critical position correction occurs.

Approach and Solution

The redesigned node uses:

• a hardware timer and encoder peripheral for position capture;
• a 1 ms local motion task with a measured worst-case execution time below its deadline;
• a separate lower-priority Ethernet task;
• a state machine with INIT, VALIDATE, READY, RUN, FAULT, and SAFE_STOP states;
• plausibility checks comparing encoder movement with commanded direction and expected limits;
• a hardware motor-enable line that remains inactive until validation succeeds;
• a watchdog supervisor requiring both motion and communication-health reports;
• a two-slot configuration record with version and integrity checking;
• event logs containing reset reason, fault code, timestamp, and operating state.

The motion task applies a local trajectory and stops the conveyor if encoder data becomes invalid. If Ethernet communication is lost, the conveyor follows a locally defined timeout policy rather than continuing indefinitely. The supervisory computer can request a stop, but a physical safety circuit independently removes drive enable when necessary.

Outcome

The architecture removes network jitter from the position loop, prevents unvalidated startup motion, and makes failures diagnosable. It also permits the communication subsystem to be upgraded without changing the fundamental motion-control timing.

Learning Points

The case demonstrates four principles: real-time control must be local; safety states must be explicit; diagnostics must record causes rather than only symptoms; and storage, communication, and update mechanisms must be designed around failure behavior as well as normal operation.

11. Contemporary Developments and Professional Practice

Modern embedded IoT systems increasingly use hardware security modules, trusted execution environments, secure boot, signed over-the-air updates, time-sensitive networking, containerized services on Linux gateways, and digital twins for commissioning and maintenance. Machine-learning inference may be added for anomaly detection, but it should not silently replace validated safety logic. An AI model can estimate bearing degradation or classify vibration patterns, while a deterministic limit monitor remains responsible for immediate protective action.

Professional development practices include version control, code review, static analysis, unit testing, hardware-in-the-loop testing, continuous integration, traceable requirements, and measurement with oscilloscopes, logic analyzers, profilers, and real-time tracing tools. Timing claims should be supported by worst-case or stress measurements, not by nominal averages. Configuration, calibration, and cybersecurity credentials must be managed as engineering assets throughout the product lifecycle.

Challenges and Limitations

Embedded designs face unavoidable trade-offs. More computation can improve algorithms but increase power, heat, cost, and timing uncertainty. Flash storage is convenient but has endurance and corruption risks. RTOS abstractions improve organization but can conceal blocking and priority problems. Linux accelerates development but may complicate deterministic control. Wireless connectivity reduces cabling but introduces interference, security exposure, and variable latency.

No single architecture is universally best. The correct choice depends on hazard analysis, timing requirements, environmental conditions, lifecycle expectations, maintenance strategy, and available engineering evidence. A design is robust when its assumptions are explicit, its limits are tested, and its failure modes lead to controlled behavior.

Chapter Summary

Embedded computing connects sensors, actuators, control algorithms, storage, diagnostics, and networks into a cyber-physical mechatronic node. MCUs provide efficient deterministic control, while embedded Linux supports complex networking and high-level services. Firmware should be layered into boot, board-support, driver, abstraction, middleware, and application components.

Real-time correctness includes timing as well as numerical output. Interrupts should be short, tasks should have defined timing properties, and shared resources require disciplined synchronization. Sampling period, latency, jitter, execution time, and workload utilization must be analyzed when designing control loops. Discrete PID control is useful but requires practical treatment of saturation, noise, filtering, and integral windup.

Local storage requires attention to capacity, endurance, atomic updates, and integrity. Watchdogs and diagnostics should detect meaningful system health rather than merely prove that some code is executing. Safe hardware–software integration requires controlled startup states, electrical protection, independent safety mechanisms, validated sensor assumptions, and appropriate standards. The central architectural principle is to keep time-critical and safety-relevant behavior local while using networks and cloud services for supervision, coordination, and analysis.

Key Terms

Embedded system: A computer integrated into a larger product to perform defined functions.

Microcontroller unit (MCU): A processor integrating memory and peripherals for embedded control.

Embedded Linux: Linux configured for an embedded computer or gateway.

Firmware: Software stored in non-volatile memory that controls embedded hardware.

Bootloader: Program that initializes hardware and selects or updates application firmware.

Device driver: Software that controls a hardware peripheral through a defined interface.

Hardware abstraction layer: Software layer that hides hardware-specific implementation details.

Real-time system: System whose correctness depends on both result and completion time.

Latency: Time delay between an event and the corresponding response.

Jitter: Variation in timing from one execution or event to another.

Interrupt service routine: Code executed in response to a hardware or software interrupt.

RTOS: Operating system providing real-time-oriented tasks, scheduling, and synchronization services.

Worst-case execution time: Maximum execution duration considered for a task under specified conditions.

Sampling period: Time interval between successive measurements or control updates.

PID controller: Feedback controller using proportional, integral, and derivative error terms.

Watchdog timer: Timer that initiates recovery when software fails to demonstrate health.

Wear leveling: Technique that distributes non-volatile-memory writes to extend storage life.

Safe state: Defined condition that reduces risk when a fault occurs.

Secure boot: Startup process that verifies firmware authenticity or integrity before execution.

Review Questions

Short Answer Questions

1. What distinguishes a microcontroller from an embedded Linux computer?
2. Why should an interrupt service routine normally be short?
3. Define latency and jitter in a real-time system.
4. What is the purpose of a watchdog timer?
5. Why is anti-windup needed in a practical PID controller?

Long Answer Questions

1. Explain a layered firmware architecture and discuss how it supports maintainability.
2. Compare polling, interrupt-driven execution, cooperative scheduling, and preemptive scheduling.
3. Discuss the timing factors that must be considered when implementing a digital control loop.
4. Explain how local storage can be protected against power loss and flash wear.
5. Describe the principles of safe hardware–software integration in an IoT mechatronic node.

Analytical / Application Questions

1. A control task executes every 5 ms. Calculate its nominal frequency and explain why this alone does not establish real-time correctness.
2. Design a fault-response state machine for a motor node that detects encoder loss during operation. Identify transitions, safe outputs, and recovery conditions.
3. A system records 20 samples per second, with 32 bytes per sample, for 14 days. Calculate the raw storage requirement and identify at least three additional storage-design concerns.

Multiple Choice Questions with Answers

Question 1

Which function is most appropriate for a microcontroller in a networked mechatronic system?

A. Executing a deterministic motor-control loop

B. Rendering a complex desktop operating environment

C. Managing a large relational database

D. Replacing all independent safety circuits

Correct Answer: A. Executing a deterministic motor-control loop

Question 2

A task with a period of 2 ms has what nominal frequency?

A. ฮ 2 Hz

B. 50 Hz

C. 500 Hz

D. 2000 Hz

Correct Answer: C. 500 Hz

Question 3

Which operation should generally be avoided inside an interrupt service routine?

A. Capturing a hardware status flag

B. Recording a timestamp

C. Signaling a waiting task

D. Performing a potentially blocking file-system write

Correct Answer: D. Performing a potentially blocking file-system write

Question 4

What is the principal purpose of a hardware abstraction layer?

A. To eliminate the need for testing

B. To hide hardware-specific details behind reusable interfaces

C. To increase network bandwidth

D. To replace the bootloader

Correct Answer: B. To hide hardware-specific details behind reusable interfaces

Question 5

In a real-time system, jitter refers to:

A. Variation in timing from one execution to another

B. The total flash-memory capacity

C. The voltage gain of an amplifier

D. The number of tasks in an RTOS

Correct Answer: A. Variation in timing from one execution to another

Question 6

What problem does integral anti-windup address?

A. Encoder quantization

B. Network authentication failure

C. Integrator accumulation while the actuator is saturated

D. Flash-cell wear

Correct Answer: C. Integrator accumulation while the actuator is saturated

Question 7

For a log recording 10 samples per second, 24 bytes per sample, for 7 days, what is the raw storage requirement?

A. 14,515,200 bytes

B. 145,152,000 bytes

C. 1,451,520,000 bytes

D. 145,152 bytes

Correct Answer: B. 145,152,000 bytes

Question 8

Which architecture best separates deterministic control from unpredictable network delays?

A. A cloud-only control loop

B. A local MCU control loop with network supervision

C. A communication task controlling every PWM edge

D. A file-system task controlling the emergency stop

Correct Answer: B. A local MCU control loop with network supervision

Question 9

Why is a checksum alone weaker than a digital signature for firmware updates?

A. A checksum always requires more memory

B. A checksum cannot detect accidental corruption

C. A checksum detects corruption but does not establish authorization

D. A digital signature cannot detect modification

Correct Answer: C. A checksum detects corruption but does not establish authorization

Question 10

Which watchdog design provides stronger evidence of system health?

A. Refreshing it continuously from an idle loop

B. Disabling it during normal operation

C. Refreshing it only after required critical tasks report healthy operation

D. Refreshing it whenever network traffic is received

Correct Answer: C. Refreshing it only after required critical tasks report healthy operation