STATERA Library · Series 08 · Volume 03 · Chapter 12 · EN
Source: https://github.com/Statera-Library/08_Vol_03_Real_Time_Operating_Systems/blob/main/Chapter_12_RTOS_Case_Studies/Chapter_12_RTOS_Case_Studies_EN.md

Volume 03 Real Time Operating Systems

12. RTOS Case Studies

12.01 Indoor AMR Drive System: FreeRTOS Case

An indoor Autonomous Mobile Robot (AMR) drive system is a representative application for demonstrating how FreeRTOS can provide deterministic control at the actuator and drive layer. The software architecture should separate high-frequency motor control from higher-level functions such as perception, localization, planning, and mission management. FreeRTOS is particularly suitable for the MCU-based controller because the drive subsystem has fixed hardware interfaces, constrained memory, and strict timing requirements. The case therefore focuses on deterministic execution, communication, feedback processing, fault handling, and safe motor operation.

The AMR drive controller receives motion commands from a higher-level computer and converts them into controlled wheel motion. Depending on the mechanical configuration, the controller may operate differential-drive, four-wheel, or other drive mechanisms, while the fundamental real-time structure remains similar. The controller interfaces with motor drivers, encoders, current sensors, temperature sensors, brakes, communication transceivers, and safety inputs. Its responsibility is not to perform global navigation or AI inference, but to execute the physical motion command reliably and report accurate state information to the supervisory computer.

The real-time control path begins with sensor acquisition and continues through validation, state estimation, control computation, limiting, and actuator command generation. Encoder feedback provides wheel position and velocity, while current and temperature measurements provide information about actuator loading and thermal conditions. Hardware interrupts should perform only the minimum work required to capture or acknowledge time-critical events and transfer data to appropriate FreeRTOS tasks. This structure prevents excessive interrupt execution from disturbing the periodic control loop and establishes a predictable execution model.

A dedicated servo control task should operate with the highest application priority because missed control deadlines can directly affect vehicle motion. The task executes periodically using a deterministic timing mechanism such as vTaskDelayUntil()\, reads the latest validated sensor state, calculates the required control response, applies velocity and current limits, and updates the motor command. The exact control frequency depends on the motor and drive hardware, but the important design principle is that the period and execution budget are explicitly defined. Control computation must consistently finish before its deadline rather than merely achieving a high average frequency.

Other FreeRTOS tasks can handle communication, diagnostics, configuration, and background processing at lower priorities. A communication task exchanges commands and feedback with the supervisory controller through an appropriate robot communication interface such as CAN or CANopen, depending on the selected drive architecture. It validates received commands, checks freshness and timeout conditions, and publishes wheel state, motor status, and diagnostic information. Diagnostic and configuration tasks should not interfere with the critical control path. This priority hierarchy reflects the different deadlines and criticality of each function.

Inter-task communication should use FreeRTOS synchronization and IPC mechanisms according to the data characteristics. Queues are appropriate when discrete commands or events must be transferred between tasks, while mutexes and semaphores are useful for controlled access to shared resources and synchronization between activities. Time-critical sensor data should avoid unnecessary copying or blocking operations. Shared state must be protected carefully so that a low-priority task cannot create excessive blocking for the high-priority control task. Priority inversion should therefore be considered during resource design.

The drive controller should also implement a clear lifecycle and fault-management strategy. Typical operating states include initialization, disabled, ready, enabled, controlling, stopping, faulted, and recovery. Fault conditions can include encoder failure, excessive motor current, excessive temperature, invalid commands, communication timeout, control-loop overrun, drive faults, and watchdog expiration. Depending on the safety architecture, the response may involve holding the current command, ramping down velocity, disabling torque, activating a brake, or entering a defined safe state. FreeRTOS provides scheduling mechanisms, but the application defines the actual safety behavior.

A watchdog supervisor provides an additional layer of protection against software malfunction. Critical tasks can periodically provide heartbeat information to a supervisor task, which determines whether required activities remain healthy. The watchdog should be refreshed only when the required heartbeats and health conditions have been satisfied. This prevents a single functioning task from masking a failure elsewhere in the control architecture. Control-loop execution time, communication activity, sensor freshness, and critical state-machine conditions can therefore become part of an integrated health-monitoring strategy.

Communication between the AMR\'s higher-level computer and the drive controller should preserve a clear separation of responsibilities. The supervisory computer may generate velocity or trajectory commands using localization, navigation, perception, optimization, or AI functions, while the FreeRTOS controller executes the physical drive response. The communication interface transfers motion intent and returns measured state rather than attempting to move high-level autonomy into the MCU. This separation allows the computationally intensive software platform to evolve independently while preserving a stable deterministic control layer.

Memory management is another important consideration for an embedded AMR drive controller. Because the target environment normally has limited Flash and RAM compared with an edge computer, static allocation or controlled memory strategies are preferable for critical tasks. Dynamic allocation during normal real-time operation can introduce unpredictable execution time and fragmentation risks. Task stacks, queues, buffers, and control-state structures should therefore be dimensioned during system design and validated under representative worst-case workloads. The memory architecture should support deterministic execution rather than optimizing only for average resource utilization.

The final system should be validated as an integrated real-time control platform rather than by checking whether individual FreeRTOS tasks appear to function correctly. Measurements should examine task execution time, control-loop period, scheduling latency, communication delay, interrupt activity, CPU utilization, stack usage, and watchdog behavior under realistic drive loads. Stress testing should include rapid command changes, high motor load, communication loss, sensor faults, thermal conditions, and repeated start-stop operation. The resulting case demonstrates the central role of FreeRTOS in an indoor AMR: it forms the deterministic execution layer that connects supervisory motion intent to reliable, bounded, and fault-aware physical actuation.

12.02 Outdoor AMR PREEMPT RT Drive Control Case

An outdoor Autonomous Mobile Robot (AMR) drive-control system places stronger real-time demands on the computing platform than a typical indoor drive system because it must operate under variable terrain, vibration, temperature, communication conditions, and actuator loads. This case uses Linux with PREEMPT_RT as the real-time control platform for the drive-control layer. The architecture separates high-level autonomy from deterministic motion execution, allowing perception, localization, navigation, and AI workloads to coexist with time-sensitive control functions while preserving predictable control behavior.

The outdoor AMR receives motion commands from a higher-level computer responsible for perception, localization, navigation, planning, and mission execution. These commands may contain target velocity, steering, torque, enable state, or other motion parameters. The PREEMPT_RT control computer converts this motion intent into timely commands for the motor controllers and continuously receives feedback such as actual velocity, steering position, motor current, temperature, bus voltage, and drive status. This separation prevents high-level computation from directly determining actuator timing.

The real-time control architecture should use multiple control rates according to the physical dynamics of the system. Fast current or torque regulation is normally handled inside the motor drive or MCU, while the PREEMPT_RT computer performs a slower but still deterministic vehicle-level control loop. A control loop around 1 kHz can be used when the hardware and communication architecture require it, while velocity, steering, coordination, and supervisory functions can execute at lower rates. This multi-rate design prevents computationally expensive functions from unnecessarily entering the fastest control path.

PREEMPT_RT provides the kernel foundation required for deterministic execution on a general-purpose Linux platform. Real-time threads can use scheduling policies such as SCHED_FIFO, while high-resolution timers and threaded interrupt handling reduce uncontrolled scheduling latency. CPU affinity and IRQ affinity can isolate the most important control thread from unrelated processing. Memory locking and controlled allocation further reduce the possibility that paging, memory faults, or resource contention will introduce unexpected delays. The kernel provides the real-time mechanisms, but application architecture must establish the actual timing guarantees.

The main control thread should acquire the latest vehicle state, process communication input, execute the control algorithm, apply physical and safety limits, and transmit updated commands within a bounded execution window. For a 1 ms cycle, every operation required by that cycle must complete before the deadline, leaving sufficient margin for variation. The design should therefore avoid unnecessary blocking, uncontrolled dynamic allocation, long critical sections, and computationally unpredictable operations. Worst-case execution time is more important than average execution time when determining whether the architecture is genuinely real-time.

Outdoor operation makes sensor and actuator feedback particularly important. Wheel encoders, steering encoders, motor-current measurements, bus-voltage measurements, motor and inverter temperatures, limit switches, and safety inputs provide the information required to maintain controlled motion. Terrain variation can increase wheel slip and motor load, while slopes and payload changes can alter the required torque. The control layer must therefore validate incoming measurements, detect abnormal conditions, and prevent invalid sensor values from propagating into actuator commands.

Communication must also be treated as part of the real-time control chain. CAN, CAN-FD, EtherCAT, or industrial Ethernet may be used according to the drive architecture, with the selected interface carrying motion commands and returning status and telemetry. Message validation should include identifiers, range checks, sequence information, CRC where applicable, and timeout supervision. A communication failure must not leave the robot indefinitely executing an obsolete command. The control system should detect stale commands and transition toward a predefined safe response.

The drive-control software should contain an explicit state machine covering initialization, self-test, disabled, ready, enabled, running, stopping, fault, and recovery conditions. Transitions should be controlled by validated commands, safety inputs, feedback conditions, and fault logic rather than by individual application threads. Faults may include encoder failure, overcurrent, excessive temperature, invalid commands, communication timeout, drive faults, or control-loop overruns. Depending on the safety concept, the system can hold a command, ramp down velocity, disable torque, activate braking, or enter a defined safe state.

Watchdog supervision provides an additional protection mechanism for the real-time platform. Critical control activities should expose health information such as heartbeat status, loop completion, communication freshness, and fault state. A supervisor can determine whether the control system remains healthy and initiate recovery when required. The watchdog should not simply confirm that the operating system is alive; it should provide evidence that the critical control functions are actually progressing within their expected timing and operational conditions.

The outdoor AMR architecture must also account for the coexistence of real-time control with non-real-time workloads. Perception, AI inference, logging, visualization, fleet communication, diagnostics, and data recording may generate significant CPU, memory, storage, and network activity. PREEMPT_RT does not automatically make all such workloads deterministic. The architecture should therefore isolate critical threads, assign appropriate priorities, reserve computational resources, control interrupt placement, lock critical memory, and prevent background workloads from consuming the resources required by the control loop.

Validation must measure the complete timing chain rather than relying on nominal CPU utilization or average loop frequency. Important measurements include control-loop period, scheduling latency, execution-time variation, communication delay, interrupt activity, CPU utilization, memory behavior, and recovery response. Tools such as cyclictest, ftrace, perf, and LTTng can be used to investigate Linux real-time behavior and identify sources of jitter. Stress testing should include high computational load, communication traffic, sensor faults, actuator faults, terrain changes, thermal conditions, and repeated acceleration and braking.

The resulting architecture establishes PREEMPT_RT as a bridge between flexible Linux-based robotic computing and deterministic physical motion control. High-level autonomy can evolve independently through perception, localization, planning, AI, and fleet functions, while the real-time layer maintains bounded execution for vehicle control. The case demonstrates that deterministic behavior is not achieved simply by installing PREEMPT_RT; it emerges from the combined design of scheduling, CPU and IRQ affinity, memory management, communication, control timing, fault handling, and systematic validation. This makes PREEMPT_RT particularly suitable for an outdoor AMR platform requiring both computational flexibility and reliable real-time drive control.

12.03 Mobile Manipulator EtherCAT Master RTOS Case

A mobile manipulator combines a mobile base with an articulated manipulator, creating a control problem in which locomotion and manipulation must operate as one coordinated physical system. An EtherCAT Master running on a real-time controller provides a suitable communication and synchronization layer for this architecture. The master can coordinate wheel drives, steering actuators, manipulator joint drives, gripper controllers, and safety I/O through deterministic cyclic process-data exchange. The case therefore focuses on real-time communication, multi-axis synchronization, control-cycle coordination, and fault-aware operation.

The main controller typically runs a real-time operating environment such as Linux with PREEMPT_RT and hosts the EtherCAT Master application. Higher-level functions such as motion planning, trajectory generation, AI, navigation, diagnostics, and operator interfaces remain above the real-time control layer. The EtherCAT Master receives motion objectives and converts them into coordinated setpoints for the distributed devices. Feedback from the drives and I/O devices is returned to the controller, allowing the application to maintain a consistent representation of wheel, steering, joint, gripper, and safety states.

The EtherCAT network connects multiple slave devices through a deterministic real-time fieldbus. Typical slaves in a mobile manipulator include wheel-drive servo amplifiers, steering actuators, manipulator joint drives, gripper controllers, safety I/O modules, and additional sensors. EtherCAT frames pass through the slaves while each device reads or modifies the process data intended for it. This on-the-fly processing reduces unnecessary communication overhead and allows many axes and I/O devices to participate in a common control cycle without requiring an independent communication transaction for every device.

The EtherCAT Master software is organized around several closely related functions. The master core manages network access and cyclic communication, while network management discovers and configures slaves and verifies the expected topology. PDO mapping defines which process variables are exchanged cyclically, while SDO or mailbox services support configuration, parameter access, and diagnostics. Distributed Clock management provides precise time synchronization, and diagnostic services monitor network conditions, counters, slave states, latency, and jitter. These functions together form the software foundation for deterministic multi-axis control.

Process Data Objects (PDOs) form the primary real-time data path between the master and the slaves. Output PDOs can contain control words, operating modes, target positions, target velocities, target torques, and other commands. Input PDOs can contain status words, actual positions, actual velocities, torque feedback, and error information. PDO mapping places these variables into the controller\'s process image so that the real-time task can read feedback and write commands efficiently. Careful mapping reduces frame size and network load while supporting predictable cycle execution.

The central execution mechanism is a cyclic real-time task that repeatedly performs the communication-control sequence. The controller first reads the latest input image, processes feedback, and executes the required control algorithms. It then updates the output image with new commands and initiates the EtherCAT communication cycle. The EtherCAT frame passes through the distributed slaves, collecting and updating process data before returning to the master. The next cycle reads the returned feedback and computes the following commands. This continuous loop establishes the timing relationship between computation, communication, and actuation.

Distributed Clocks (DC) are particularly important when the mobile base and manipulator must move together. Communication timing alone does not guarantee that individual devices apply their commands at exactly the same physical instant because propagation delays and local clock differences remain. EtherCAT DC synchronizes the clocks of the distributed devices to a common high-precision time base. Synchronization events such as SYNC0 can then define when outputs are applied, allowing multiple wheel and manipulator axes to execute coordinated commands at a common execution point.

The control hierarchy should remain multi-rate rather than forcing every function to operate at the EtherCAT cycle frequency. High-level trajectory and motion planning can operate at relatively low rates, while the EtherCAT Master executes cyclic command and feedback exchange at an intermediate real-time rate. Individual servo drives can perform their local current, velocity, and position loops at much higher rates. This hierarchy allows the master to distribute coordinated setpoints while leaving the fastest physical control loops close to the motors. Such separation reduces computational burden and preserves deterministic timing.

Real-time scheduling on the master controller must be coordinated with the EtherCAT cycle. The communication and control task should receive appropriate real-time priority and should avoid unnecessary blocking, uncontrolled dynamic memory allocation, and unpredictable operations. CPU affinity and memory locking can isolate critical processing, while appropriate interrupt handling reduces interference from unrelated workloads. The objective is bounded jitter, low communication latency, and stable cycle execution rather than simply achieving a high average CPU performance. The real-time operating system and EtherCAT architecture must therefore be designed as one timing system.

Fault handling must be integrated directly into the EtherCAT Master rather than treated as an external diagnostic function. Communication loss, slave-device faults, invalid process data, Distributed Clock synchronization errors, drive faults, and missed cycles can all affect coordinated motion. The master should detect these conditions within a bounded time and apply an appropriate protective response, such as controlled deceleration, torque disable, transition to a safe state, or alarm notification. Slave-state transitions should also be monitored so that the master does not assume that a device is operational simply because network communication remains available.

Performance verification must evaluate the complete timing chain from sensing and feedback availability through control computation, command transmission, and physical actuation. Important measurements include EtherCAT cycle time, scheduling latency, communication latency, control-loop jitter, Distributed Clock deviation, SYNC0 timing accuracy, Working Counter behavior, CPU load, and missed cycles. Hardware timestamping, network diagnostics, drive feedback, and tracing can provide evidence of actual system behavior. Validation should include high communication loads, multiple simultaneous axis movements, synchronization disturbances, drive faults, and repeated coordinated motion to verify deterministic performance under realistic conditions.

The resulting mobile-manipulator architecture establishes the EtherCAT Master as the deterministic coordination layer between high-level robot intelligence and distributed physical actuators. The mobile base and manipulator can retain their own local servo loops while receiving synchronized setpoints from a common real-time process-data cycle. Distributed Clocks provide a shared execution reference, PDOs provide efficient cyclic data exchange, and the real-time scheduler maintains bounded execution of the master task. Together, these mechanisms enable coordinated locomotion and manipulation with low latency, precise synchronization, predictable timing, and fault-aware operation.

12.04 Quadruped Joint MCU RTOS Design Case

A quadruped robot requires each leg joint to generate precise and rapidly changing torque while maintaining stable coordination across all four legs. A dedicated joint MCU running an RTOS provides the deterministic execution layer between the central controller and the physical actuator. The MCU receives position, velocity, torque, stiffness, damping, mode, and enable commands, while returning joint states, status, and alarms. The architecture therefore focuses on deterministic timing, hierarchical servo control, hardware abstraction, protection, diagnostics, synchronization, and safe fault response.

The central controller performs higher-level functions such as state estimation, motion planning, gait generation, and whole-body control. These functions produce motion objectives for individual joints rather than directly controlling the power stage at the fastest physical rate. A deterministic communication interface such as CAN-FD or EtherCAT transfers commands from the central controller to each joint MCU and returns feedback and telemetry. This separation allows computationally complex locomotion algorithms to evolve independently while the MCU maintains bounded and predictable actuator control.

The joint hardware typically combines a BLDC or PMSM motor, encoder, mechanical reducer, current sensors, temperature sensors, and an inverter power stage. The MCU interfaces with these components through synchronized ADC acquisition, high-resolution timers, PWM generation, DMA, GPIO, and communication peripherals. The hardware abstraction layer isolates the application and control algorithms from processor-specific peripheral details. This structure makes it possible to maintain consistent control software while adapting the implementation to different ARM Cortex-M devices, timer architectures, ADCs, communication interfaces, or power-stage designs.

The firmware is organized into several functional modules around the real-time control layers. The application and state machine manage operating modes and transitions, while the safety supervisor evaluates limits and fault conditions. The communication stack handles command and feedback exchange, diagnostics and logging record runtime behavior, and parameter and calibration functions maintain configuration data. These modules should not interfere with the highest-frequency control operations. Critical control paths must remain short, predictable, and independent from non-critical configuration, logging, or maintenance activities.

The servo architecture follows a hierarchical control structure in which position, velocity, and current or torque loops operate at different rates. The position loop may operate around 200--1000 Hz and produces velocity references, while the velocity loop may operate around 1--2 kHz and produces torque or Iq references. The current or torque loop operates at the highest rate, typically around 10--50 kHz, using current acquisition, Clarke and Park transformations, PI control, inverse Park transformation, and SVPWM generation. This hierarchy keeps the fastest control close to the motor and distributes computational work according to physical dynamics.

The RTOS scheduling model must preserve these timing relationships. The fastest activities can be driven by hardware timers, PWM events, ADC completion, encoder capture, and fast interrupt service routines. The primary servo task executes at a lower but still deterministic rate, while communication, diagnostics, configuration, and background activities operate more slowly. Fixed execution periods, bounded execution time, minimized jitter, and continuous measurement are essential design principles. The objective is not simply high CPU utilization or high control frequency, but reliable completion of every critical control operation before its deadline.

Inter-process and inter-task communication must match the semantics of the information being transferred. Task notifications are useful for rapidly waking a specific servo task from an interrupt, while queues can transfer sensor samples or discrete messages. Semaphores can represent events or synchronize resources, and mutexes can protect configuration structures or shared data. Clear ownership of shared information is important because unnecessary locking can delay critical control tasks. The design should minimize blocking and prevent priority inversion so that lower-priority activities cannot introduce unbounded delays into the joint-control path.

Memory management must also support deterministic behavior. Critical RTOS objects such as task stacks, queues, control structures, and communication buffers should preferably use static allocation. If dynamic allocation is required, it should normally be completed during a controlled initialization phase rather than during normal real-time operation. Runtime creation and deletion of objects can introduce unpredictable execution time and fragmentation. Stack high-water marks, available heap, minimum free memory, allocation failures, and stress-test margins should therefore be monitored to confirm that the MCU maintains sufficient memory resources under worst-case operating conditions.

Protection and fault handling are integrated directly into the joint controller. The system must detect conditions such as overcurrent, overvoltage or undervoltage, overtemperature, position or soft-limit violations, excessive velocity or acceleration, excessive torque, following error, sensor failure, stall conditions, and power-stage faults. A detected fault can be classified and logged before torque is limited or derated, the joint is brought to a controlled stop, and torque is inhibited through a safe mechanism such as STO. Fast hardware fault inputs should provide an additional shutdown path when software response alone is not sufficiently fast.

Diagnostics provide the information required to understand both normal operation and abnormal behavior. The controller can record reset causes, fault codes, cycle time and jitter, currents, voltages, temperatures, encoder status, communication timeouts, event history, and runtime statistics. These measurements make it possible to distinguish a control-algorithm problem from a sensor, communication, timing, or power-stage problem. Pre-fault and post-fault event information is particularly useful for reconstructing transient failures that may disappear before a conventional diagnostic interface can inspect the system.

Synchronization becomes essential when multiple joints contribute simultaneously to a gait. Distributed clocks, synchronized control cycles, timestamps, or equivalent timing mechanisms can provide a common temporal reference for coordinated multi-joint action. The joint MCU should therefore treat synchronization information as part of the control architecture rather than as an optional communication feature. When the central controller commands several joints to change posture, generate a step, absorb an impact, or recover balance, predictable timing between the individual joint controllers helps preserve the intended whole-body behavior.

The hardware platform should provide sufficient timing and peripheral capability for the selected control rates. An ARM Cortex-M MCU with Flash and RAM, high-resolution timers, synchronized ADCs, DMA, CAN or EtherCAT, PWM outputs, gate drivers, motor sensors, and an isolated power supply forms a representative implementation. The firmware lifecycle should additionally include secure boot and verification, calibration and parameter management, safe update and rollback, version compatibility, monitoring, and maintenance. Verification should measure loop period, execution time, latency, jitter, CPU load, stack usage, and communication behavior under maximum sensor rates, communication bursts, rapid commands, limit conditions, fault injection, bus loss, and simultaneous diagnostics. The resulting design provides a deterministic and fault-aware joint-control foundation for stable quadruped locomotion and coordinated whole-body motion.

12.05 Humanoid Integrated Controller Mixed Criticality Case

A humanoid robot requires an integrated controller capable of coordinating many joints while simultaneously maintaining balance, posture, locomotion, manipulation, and safety functions. The controller must therefore combine deterministic real-time computation with high-performance workloads such as perception, state estimation, planning, and AI inference. A mixed-criticality architecture provides a structured way to allow these functions to coexist while preventing lower-criticality workloads from interfering with safety-critical control. The fundamental principle is that safety authority remains deterministic and independently enforceable.

The integrated controller can be divided into a high-criticality safety domain and a lower-criticality QM or AI domain. The safety domain contains functions such as emergency stop, torque limitation, joint protection, balance constraints, watchdog supervision, deadline monitoring, and safe-state management. The QM or AI domain contains perception, world modeling, localization, motion planning, optimization, learning, visualization, and other computationally intensive functions. Both domains may use the same physical computing platform, but their timing, memory, device access, and failure behavior must be controlled according to their different criticality levels.

The safety controller should remain the final authority over physical actions even when commands originate from AI or high-level planning functions. An AI planner may propose a joint trajectory, locomotion command, posture adjustment, or manipulation action, but the safety domain must independently verify whether the requested action satisfies predefined limits. These limits can include joint position, velocity, acceleration, torque, temperature, power, balance, workspace, and operational-envelope constraints. If an AI component produces an invalid or unsafe command, the safety controller must be capable of rejecting, limiting, or replacing it without depending on the correctness of the AI software.

Isolation is the central mechanism for achieving freedom from interference between the criticality domains. Spatial isolation can use MPU, MMU, or IOMMU mechanisms to protect memory and control device access, while temporal isolation can use scheduling priorities, CPU affinity, execution budgets, or time partitioning. Resource management must also consider shared CPU cores, memory, cache, interconnects, DMA, accelerators, and network bandwidth. Depending on the platform, RTOS domains, hypervisors, or operating-system partitions can establish stronger boundaries between safety control and high-performance workloads.

Time partitioning provides a useful mechanism when safety and AI workloads must share processor resources. Processor time can be divided into repeating execution windows in which specific domains receive controlled access to CPU resources. Safety control may receive protected windows with strict deadlines, while state estimation, real-time communication, Linux services, perception, AI inference, and logging receive separate execution opportunities. A lower-criticality domain must not overrun its assigned budget and consume time reserved for safety functions. This approach provides temporal predictability even when computational demand changes dynamically.

The real-time control path should use a hierarchical structure that reflects the physical dynamics of the humanoid robot. Fast joint and actuator control remains close to the motor controllers, while higher-level whole-body control, balance control, gait generation, and coordinated motion operate at appropriate real-time rates. The integrated controller receives joint feedback and sensor information, performs state estimation and safety checks, calculates coordinated commands, and distributes them to the joint-level controllers. This multi-rate architecture prevents AI inference or complex planning operations from entering the fastest actuator-control path.

Communication across the criticality boundary must be explicitly controlled rather than being treated as ordinary data exchange. Information transferred from the QM or AI domain should pass through defined interfaces with range and plausibility checks, integrity protection, timestamp or sequence validation, freshness and timeout monitoring, and clearly defined safety assumptions. Communication success alone must not be considered evidence that the received information is safe. If data are delayed, corrupted, duplicated, reordered, or outside an acceptable range, the safety domain must be able to reject the information and continue using an independent safe response.

Monitoring and supervision provide continuous evidence that the mixed-criticality system remains within its intended operating conditions. The safety domain should monitor task deadlines, execution time, watchdog status, resource usage, communication freshness, health information, and critical state transitions. The QM or AI domain can be monitored for excessive CPU or memory consumption, unexpected behavior, inference overload, or communication problems. Fault containment ensures that a failure in an AI model, Linux service, communication stack, or non-safety process does not automatically propagate into the safety control domain.

A humanoid controller must define explicit responses for faults and degraded operating modes. Potential failures include missed deadlines, CPU overload, memory violations, invalid commands, sensor failures, communication loss, actuator faults, watchdog expiration, and synchronization errors. Depending on the fault and available redundancy, the controller may limit torque, reduce motion speed, stop selected joints, transition to a controlled posture, activate an emergency stop, or enter a predefined safe state. Recovery should be controlled by the safety architecture rather than allowing a failed lower-criticality component to determine its own recovery behavior.

Verification of the integrated controller must demonstrate both deterministic safety behavior and successful coexistence with computationally demanding workloads. Tests should examine spatial isolation, temporal isolation, communication integrity, deadline compliance, resource contention, interrupt behavior, memory protection, watchdog response, and fault containment. Stress conditions should include high AI inference load, CPU saturation, memory pressure, communication bursts, network disruption, domain restart, corrupted data, delayed messages, and long-duration operation. The important question is not whether the AI workload operates correctly in isolation, but whether safety functions remain deterministic and protected while that workload operates at maximum demand.

The resulting architecture establishes mixed criticality as an integration principle for humanoid control rather than simply a scheduling technique. Deterministic safety control, real-time whole-body coordination, and high-performance AI can share a common computing platform when their execution, memory, communication, and resources are explicitly separated and continuously supervised. The safety domain retains independent authority over physical limits and safe-state transitions, while the QM or AI domain provides perception, prediction, planning, optimization, and learning capabilities. This enables a humanoid controller to combine reliable real-time physical control with flexible intelligent computation without allowing higher computational complexity to compromise fundamental safety behavior.

12.06 Cargo UAV FCC RTOS Architecture Case

A cargo Unmanned Aerial Vehicle (UAV) Flight Control Computer (FCC) is a safety-critical embedded platform responsible for maintaining stable flight while coordinating propulsion, navigation, guidance, actuator control, and fault management. Unlike ground robots, a major control failure can immediately threaten continued flight. The FCC RTOS architecture must therefore prioritize deterministic execution, bounded latency, fault containment, redundancy, health monitoring, and controlled transition to degraded or safe operating modes.

The FCC receives information from inertial measurement units, GNSS receivers, air-data sensors, radar or laser altimeters, actuator feedback, propulsion systems, power monitors, and other avionics interfaces. These measurements are transformed into reliable vehicle-state information for flight control. The controller then generates commands for control surfaces, propulsion units, thrust-vectoring devices, or other actuators according to the aircraft configuration. Every critical sensing-to-actuation path must operate within explicitly defined timing and integrity requirements.

The software architecture should separate functions according to their criticality and timing characteristics. High-criticality functions include attitude stabilization, rate control, actuator command generation, flight-envelope protection, emergency logic, and watchdog supervision. Navigation, guidance, trajectory generation, communication, payload management, diagnostics, and mission functions can operate at different priorities and periods. Computationally intensive AI or perception functions should remain outside the fastest safety-critical flight-control path so that their execution variability cannot directly disturb fundamental aircraft stabilization.

Flight control naturally follows a multi-rate architecture. Fast inner loops regulate angular rates and attitude, while slower outer loops manage velocity, position, altitude, heading, and trajectory objectives. Navigation and mission-management functions operate at still lower rates. The exact frequencies depend on aircraft dynamics and hardware, but each loop must have an explicit period, priority, deadline, and execution budget. This hierarchy ensures that rapidly changing vehicle dynamics receive immediate control attention while slower supervisory functions consume resources only when their timing requirements permit.

RTOS scheduling must preserve the precedence of safety-critical flight functions under both normal and overloaded conditions. Fixed-priority preemptive scheduling can assign the highest priorities to critical control tasks, while less critical communication, diagnostics, logging, and payload activities execute below them. Interrupt service routines should perform only time-sensitive hardware operations before deferring longer processing to scheduled tasks. Worst-case execution time, response time, context-switch overhead, and interrupt interference must be analyzed rather than relying on average processor utilization.

Mixed-criticality design becomes particularly important when safety flight software shares computing resources with advanced autonomy or mission applications. Spatial isolation can protect memory through MPU or MMU mechanisms, while temporal isolation can reserve execution budgets or processor windows for critical functions. Device access, DMA, communication channels, memory bandwidth, and shared accelerators must also be controlled. Hypervisor or partition-based architectures can provide stronger separation when multiple operating environments coexist on the FCC computing platform.

Communication between partitions or processors should use explicitly controlled interfaces. Flight commands, navigation states, actuator data, health information, and mission requests require range checking, sequence validation, timestamps, freshness monitoring, integrity checks, and timeout handling. A valid communication frame does not automatically represent a valid flight command. Safety-critical software must independently determine whether received information is physically plausible and operationally permitted before allowing it to influence actuator outputs.

Redundancy increases tolerance to failures that cannot be safely handled by a single computing channel. A cargo UAV may employ redundant sensors, communication paths, power supplies, FCC channels, or actuator interfaces according to its safety objectives. Independent channels can compare state estimates and control outputs, while voting or supervisory logic determines which information remains trustworthy. Redundancy is effective only when common-cause failures are considered, so duplicated hardware should not blindly share every power, clock, communication, and software dependency.

Health monitoring must continuously determine whether the FCC is executing correctly rather than merely checking whether the processor remains active. Watchdog supervision can monitor task heartbeats, control-loop completion, deadline compliance, sensor freshness, communication status, synchronization, memory integrity, and processor health. Fault information should be classified according to severity and persistence. The supervisor can then decide whether continued normal operation is possible or whether the aircraft must enter a degraded control configuration.

Fault responses should be predefined and deterministic. Sensor disagreement, actuator failure, communication loss, excessive execution time, memory violations, power faults, synchronization errors, or processor failures may require different responses. The FCC may reject a sensor, switch to a redundant channel, reduce flight-envelope limits, disable nonessential workloads, reconfigure actuator allocation, command a controlled diversion, or enter an emergency flight mode. Recovery authority must remain within trusted safety logic so that a failed lower-criticality application cannot independently restore unsafe functionality.

Memory management should avoid introducing unpredictable behavior into critical flight tasks. Safety-critical stacks, buffers, queues, control structures, and communication objects should preferably be allocated statically or during controlled initialization. Runtime allocation can introduce fragmentation and variable execution time that complicate timing guarantees. Memory protection should prevent one task or partition from corrupting another, while stack monitoring, bounds checking, error detection, and persistent diagnostic records provide evidence for both runtime supervision and post-flight failure analysis.

Verification must demonstrate deterministic behavior under worst-case operational and computational conditions. Measurements should include control-loop periods, scheduling latency, execution-time jitter, interrupt response, communication delay, synchronization accuracy, CPU and memory utilization, deadline misses, and watchdog response. Tests should inject sensor faults, communication loss, actuator failures, processor overload, corrupted data, memory violations, power disturbances, and timing faults while simultaneously exercising demanding mission workloads. Long-duration stress testing is necessary to expose rare timing and resource-i...