Real Time Operating Systems — Ch.05: Task Scheduling [EN]

STATERA Library · Series 08 · Volume 03 · Chapter 05 · EN
Source: https://github.com/Statera-Library/08_Vol_03_Real_Time_Operating_Systems/blob/main/Chapter_05_Task_Scheduling/Chapter_05_Task_Scheduling_EN.md

Volume 03 Real Time Operating Systems

05. Task Scheduling

05.01 Task Scheduling Theory: Utilization Bound / Response Time

Task scheduling theory provides the mathematical foundation for determining whether a set of real-time tasks can execute on a processor while satisfying timing constraints. In a real-time operating system, correctness depends not only on producing the correct computational result but also on producing it before the required deadline. The attached structure places this topic at the beginning of the dedicated Task Scheduling chapter, before Rate Monotonic, EDF, mixed-criticality, multicore, and AI-inference scheduling topics.

A periodic real-time task is commonly modeled as τᵢ = (Cᵢ, Tᵢ, Dᵢ), where Cᵢ represents the worst-case execution time, Tᵢ is the period or minimum inter-arrival time, and Dᵢ is the relative deadline. Each activation of the task creates a job that requires at most Cᵢ units of processor time and should finish within Dᵢ after its release. This compact model allows engineers to reason about timing independently from much of the application implementation.

Processor utilization expresses how much computing capacity is requested by the task set. For a periodic task τᵢ, utilization is Uᵢ = Cᵢ/Tᵢ, while total utilization is U = Σ(Cᵢ/Tᵢ). A task requiring 1 ms every 10 ms therefore consumes 10 percent of one processor. Utilization is an important first indicator of feasibility, but a value below 100 percent does not automatically guarantee schedulability under every scheduling algorithm or priority assignment.

For fixed-priority Rate Monotonic scheduling with independent periodic tasks and deadlines equal to periods, the classical Liu-Layland sufficient utilization bound for n tasks is U ≤ n(2^(1/n) − 1). The bound approaches ln(2), approximately 0.693, as the number of tasks becomes large. A task set below this bound is guaranteed schedulable under the assumptions of the theorem, while exceeding the bound does not necessarily mean that deadlines will be missed.

The distinction between sufficient and necessary conditions is essential in scheduling analysis. Utilization-bound tests are attractive because they are computationally inexpensive and can quickly establish that a system is safe. However, they can be pessimistic because they summarize complex task interactions using a single utilization value. A system that fails a sufficient utilization test therefore requires more precise analysis rather than immediate rejection, particularly when processor resources are tightly constrained.

Exact or tighter schedulability analysis can be performed using response-time analysis. For a fixed-priority task τᵢ, its worst-case response time is obtained by considering its own execution time together with interference caused by all higher-priority tasks. A common recurrence is Rᵢ = Cᵢ + Σ⌈Rᵢ/Tⱼ⌉Cⱼ for every higher-priority task τⱼ. The ceiling term determines how many times each higher-priority task may execute during the response interval.

Response-time analysis is normally evaluated iteratively. The calculation begins with an initial estimate such as Rᵢ⁽⁰⁾ = Cᵢ, after which interference from higher-priority tasks is added to produce the next estimate. Iteration continues until two consecutive values are equal, indicating convergence, or until the calculated response time exceeds the deadline. If the converged value satisfies Rᵢ ≤ Dᵢ for every task, the analyzed fixed-priority task set is schedulable under the assumed model.

Real systems introduce additional execution costs that must be incorporated into this theoretical framework. Interrupt handling, context switching, scheduler execution, cache effects, memory contention, device-driver activity, and communication processing consume processor time even though they may not appear in the nominal application WCET. Blocking caused by mutexes or other shared resources can also delay a high-priority task. Practical response-time equations therefore often include blocking and implementation overhead rather than relying solely on idealized execution times.

Worst-case execution time is consequently one of the most important inputs to scheduling analysis. Average execution time is unsuitable for hard real-time guarantees because a task may occasionally follow a longer control path, encounter unfavorable cache behavior, or process unusually complex input. WCET should represent a defensible upper bound under the intended hardware and software configuration. Measurement-based estimates can be useful, but safety-critical designs may require more systematic timing analysis and margin.

Deadline, period, and response time describe different timing properties. The period determines how frequently a periodic task is released, the deadline specifies when a released job must finish, and response time measures the interval from release until completion. A task may have Dᵢ = Tᵢ, but this equality is an assumption rather than a universal rule. Control, communication, and sensor-processing workloads may use constrained or application-specific deadlines that are shorter than their periods.

Scheduling analysis must also distinguish execution demand from release behavior. Periodic tasks arrive at regular intervals, while sporadic tasks have irregular releases separated by a defined minimum inter-arrival time. Aperiodic tasks may have less predictable arrival patterns. Real robot software typically combines all three behaviors: servo loops are periodic, fault events are sporadic, and diagnostic or maintenance operations may be aperiodic. Their interaction must be controlled so that noncritical work cannot compromise critical deadlines.

The scheduling model is especially relevant to robotics because different software functions operate at dramatically different rates. Motor-current regulation may execute much faster than position control, while localization, perception, communication, diagnostics, and mission management operate at progressively different timescales. Treating all workloads as equivalent CPU consumers hides these temporal requirements. Scheduling theory instead provides a method for translating control periods and execution demands into explicit processor guarantees.

A robot controller can therefore be designed by first identifying each timing-critical task, estimating or measuring its WCET, assigning its period and deadline, and calculating utilization. A simple utilization-bound test can eliminate obviously safe configurations quickly. Task sets close to the processor limit should then undergo response-time analysis, including interference, blocking, operating-system overhead, and appropriate engineering margins. This creates a traceable connection between software architecture and timing feasibility.

Multicore processors complicate the interpretation of utilization because aggregate CPU capacity alone does not determine schedulability. A task may be pinned to one core, migrate between cores, share caches and memory buses, or compete with interrupts and kernel threads. Consequently, a system showing modest total CPU utilization can still experience deadline violations on an overloaded or interference-sensitive core. Per-core task allocation and interference analysis become necessary extensions of single-processor scheduling theory.

Scheduling theory also establishes the conceptual basis for the later topics in the attached RTOS structure, including Rate Monotonic scheduling, Earliest Deadline First, mixed-criticality scheduling, multicore scheduling, hypervisor isolation, and real-time scheduling of AI inference workloads. These mechanisms differ in priority assignment and resource management, but they ultimately address the same engineering question: whether computational demand can be completed within explicitly defined temporal constraints.

For robotic real-time systems, utilization and response-time analysis should therefore be viewed as complementary tools rather than competing methods. Utilization provides a compact measure of processor demand and enables rapid schedulability screening, whereas response-time analysis examines the timing behavior of individual tasks under worst-case interference. Together they transform scheduling from an empirical tuning exercise into an analyzable engineering discipline capable of supporting predictable control, perception, communication, and safety behavior.

05.02 Rate Monotonic Scheduling: Analysis and Practice

Rate Monotonic Scheduling (RMS) is a fixed-priority scheduling method designed primarily for periodic real-time tasks. It assigns priorities according to task periods: the task with the shortest period receives the highest priority, while tasks with longer periods receive progressively lower priorities. Because priorities are determined statically from timing requirements, RMS provides a predictable scheduling model that is particularly suitable for deterministic control workloads in real-time operating systems.

The theoretical importance of RMS comes from its optimality among fixed-priority scheduling algorithms under a classical set of assumptions. Tasks are independent and periodic, their deadlines equal their periods, execution times are known and bounded, and scheduling is fully preemptive on a single processor. Under these assumptions, if a task set can be scheduled by any fixed-priority assignment, the Rate Monotonic priority assignment can also schedule it. These assumptions must therefore be understood before applying the theory to practical systems.

Consider periodic tasks represented as τᵢ = (Cᵢ, Tᵢ, Dᵢ), where Cᵢ is the worst-case execution time, Tᵢ is the period, and Dᵢ is the relative deadline. RMS compares the values of Tᵢ and assigns higher priorities to smaller periods. For example, tasks with periods of 5 ms, 10 ms, 20 ms, and 100 ms receive priorities from highest to lowest in that order. This naturally favors high-frequency functions such as servo and motor-control loops.

A fundamental RMS schedulability test is based on processor utilization. For n periodic tasks, total utilization is U = Σ(Cᵢ/Tᵢ). Under the classical Liu-Layland model, the sufficient schedulability condition is U ≤ n(2^(1/n) − 1). The bound decreases as the number of tasks increases and approaches ln(2), approximately 0.693. If utilization remains below this bound, the task set is guaranteed to meet its deadlines under the assumptions of the RMS scheduling model.

The utilization bound is sufficient but not necessary. A task set exceeding the Liu-Layland bound may still be completely schedulable because the bound intentionally provides a conservative guarantee. Harmonic task sets demonstrate this clearly. When task periods are integer multiples of shorter periods, task releases align efficiently and RMS can potentially schedule processor utilization approaching 100 percent. Therefore, failing the simple utilization test should lead to more detailed analysis rather than immediate rejection of the design.

Response-Time Analysis (RTA) provides a more precise method for evaluating RMS task sets. For each task τᵢ, the worst-case response time includes its own execution time plus interference from all higher-priority tasks. An iterative relation can be written as Rᵢ^(k+1) = Cᵢ + Σ⌈Rᵢ^k/Tⱼ⌉Cⱼ, where the summation includes tasks with higher RMS priority. Iteration continues until the response time converges or exceeds the task deadline.

The critical instant concept explains why RMS response-time analysis can focus on a particular worst-case release pattern. For independent fixed-priority periodic tasks, a task generally experiences its maximum interference when it is released simultaneously with all higher-priority tasks. The resulting synchronous release creates the greatest initial competition for processor execution. Analyzing this condition allows engineers to evaluate worst-case timing behavior without exhaustively simulating every possible relative phase among periodic tasks.

Preemption is central to RMS operation. When a higher-priority periodic task becomes ready, it can interrupt a currently executing lower-priority task and immediately obtain the processor. The lower-priority task resumes later when no higher-priority work remains. This behavior protects fast control loops from slower background activities, but every preemption may introduce context-switching, cache, pipeline, and scheduler overhead that must be considered when translating theoretical RMS analysis into an implementation.

Shared resources introduce another complication because a high-priority task may become blocked by a lower-priority task holding a mutex or another exclusive resource. This can produce priority inversion, violating the simple assumption that higher-priority tasks are delayed only by other higher-priority tasks. Practical response-time analysis therefore incorporates a blocking term, commonly represented as Bᵢ, producing an expression such as Rᵢ = Cᵢ + Bᵢ + Σ⌈Rᵢ/Tⱼ⌉Cⱼ.

Priority inheritance and priority ceiling mechanisms can bound resource-related blocking and make RMS behavior more predictable. Priority Inheritance Protocol temporarily raises the priority of a lower-priority task that blocks a higher-priority task, while Priority Ceiling Protocol imposes stronger rules governing access to shared resources. These mechanisms do not eliminate resource contention, but they transform potentially uncontrolled priority inversion into blocking behavior that can be bounded and incorporated into schedulability analysis.

RMS implementation in an RTOS normally maps theoretical priorities onto the kernel\'s discrete priority levels. Designers first identify periodic tasks, determine their periods, and rank them from shortest to longest period. Kernel priorities are then assigned while reserving appropriate levels for interrupts, safety functions, and operating-system services. Care is required when several tasks have equal periods, when the number of software tasks exceeds available priority levels, or when application-specific criticality conflicts with pure period-based ordering.

A practical robot controller illustrates why RMS is useful. A fast joint or drive-control loop may execute every 1 ms, an odometry task every 5 or 10 ms, a state-estimation function every 10 or 20 ms, communication processing every 20 ms, and diagnostic tasks every 100 ms or longer. RMS naturally gives the fastest deterministic control loop the highest task priority. Slower monitoring and communication functions execute in the processor capacity left available by higher-frequency real-time activities.

However, priority should not be selected from frequency alone without examining system architecture. An emergency-stop path, watchdog, fault monitor, or hardware protection function may require greater practical criticality than its nominal execution period suggests. Such functionality is often implemented through interrupts, dedicated safety processors, separate priority domains, or explicitly reserved high-priority tasks. RMS should therefore be applied within a clearly defined scheduling domain rather than interpreted as a universal rule for every software function.

Timing measurements are essential when moving from RMS theory to practice. Worst-case execution time should include realistic input conditions, memory behavior, interrupt interference, communication activity, and operating-system overhead. Engineers should observe execution time, release jitter, response time, deadline misses, context switches, and CPU utilization under representative worst-case workloads. Trace tools and hardware timestamps can then verify whether measured behavior remains consistent with the assumptions used during schedulability analysis.

Multicore platforms require additional consideration because classical RMS theory primarily describes a uniprocessor scheduling model. Tasks may be partitioned among cores, or global scheduling may permit migration between processors. In robotic systems, partitioned approaches are often attractive because high-frequency control tasks can be pinned to dedicated cores while perception, communication, and noncritical processing execute elsewhere. Nevertheless, shared caches, memory bandwidth, interrupts, and inter-core communication can still introduce timing interference.

RMS is particularly effective when workloads are periodic, execution times are bounded, timing requirements are stable, and deterministic behavior is more important than maximizing average processor throughput. These characteristics frequently appear in motor control, actuator coordination, sensor acquisition, state estimation, and embedded robot control. Workloads dominated by irregular events, dynamically changing computation, or large AI inference jobs may require complementary scheduling mechanisms instead of relying exclusively on classical RMS.

A disciplined RMS design process therefore connects timing requirements directly to implementation. Engineers define Cᵢ, Tᵢ, and Dᵢ for each periodic task, assign priorities according to period, calculate processor utilization, perform the utilization-bound test, and apply response-time analysis when necessary. Blocking and implementation overhead are then incorporated, followed by measurement under realistic workloads. The final objective is not merely high CPU utilization, but demonstrable evidence that every timing-critical task completes before its required deadline.

05.03 Earliest Deadline First: Implementation and Limits

Earliest Deadline First (EDF) is a dynamic-priority scheduling algorithm in which the ready task or job with the earliest absolute deadline receives the highest execution priority. Unlike Rate Monotonic Scheduling, where priorities are derived statically from task periods, EDF priorities can change whenever jobs are released or completed. This makes EDF directly responsive to current deadline urgency and provides a powerful scheduling model for periodic and deadline-driven real-time workloads.

A periodic task can be represented as τᵢ = (Cᵢ, Tᵢ, Dᵢ), where Cᵢ is its worst-case execution time, Tᵢ is its period, and Dᵢ is its relative deadline. When a job is released at time rᵢ, its absolute deadline becomes dᵢ = rᵢ + Dᵢ. EDF compares these absolute deadlines among all ready jobs and selects the one with the smallest dᵢ. Consequently, priority belongs to individual job instances rather than being permanently attached to a task.

The central theoretical advantage of EDF is its optimality for preemptive scheduling on a single processor under classical assumptions. For independent periodic tasks with deadlines equal to their periods, a task set is schedulable by EDF when its total processor utilization satisfies U = Σ(Cᵢ/Tᵢ) ≤ 1. This means EDF can theoretically utilize up to 100 percent of processor capacity, whereas the simple sufficient utilization bound for Rate Monotonic Scheduling approaches approximately 69.3 percent as the number of tasks increases.

EDF scheduling can be understood through a simple timeline. Suppose three jobs are ready with absolute deadlines at 20 ms, 35 ms, and 50 ms. The job with the 20 ms deadline executes first. If another job is released during its execution with a deadline of 15 ms, the newly released job becomes the most urgent and can preempt the current job. After it completes, the scheduler again selects the ready job having the earliest remaining absolute deadline.

Implementation therefore requires a ready structure ordered by absolute deadline. A simple RTOS implementation may maintain ready jobs in an ordered list, priority queue, or binary heap. Whenever a task releases a new job, blocks, completes, or changes state, the scheduler updates this structure and identifies the minimum deadline. Efficient data structures are important because EDF performs dynamic priority decisions at runtime rather than relying on a fixed task-priority table established during system configuration.

The EDF dispatch procedure is conceptually straightforward. When a job becomes ready, its absolute deadline is calculated and inserted into the deadline-ordered ready queue. The scheduler compares it with the currently executing job. If the new deadline is earlier, preemption occurs; otherwise the current job continues. When a job finishes or blocks, the scheduler removes it and dispatches the ready job with the earliest deadline. This process continuously tracks temporal urgency as system conditions change.

For the implicit-deadline periodic model where Dᵢ = Tᵢ, processor utilization provides a particularly elegant schedulability test. If U ≤ 1, EDF can schedule the task set under the classical assumptions; if U > 1, the processor fundamentally lacks enough execution capacity. This utilization result makes EDF attractive for systems requiring high processor efficiency because the theoretical schedulability region is larger than that provided by the simple RMS utilization-bound test.

However, utilization alone is not sufficient for every EDF task model. When relative deadlines differ from periods, especially when Dᵢ < Tᵢ, processor demand must be examined over relevant time intervals. Demand-based schedulability analysis considers how much execution may be required before deadlines within a particular interval. This distinction is important because average processor utilization may remain below 100 percent while short intervals still contain more deadline-constrained computation than the processor can execute.

EDF also differs from RMS in overload behavior. Under normal schedulable conditions, dynamic deadline priorities allow EDF to use processor capacity efficiently. When execution demand unexpectedly exceeds available capacity, however, multiple deadlines may begin to fail in a less predictable pattern. A temporary execution-time overrun can delay the earliest-deadline job, which then delays subsequent jobs. For safety-critical systems, this overload propagation must be addressed explicitly rather than assuming nominal schedulability guarantees remain valid.

Runtime overhead is another practical limitation. EDF requires deadline tracking, ordered ready-queue management, and potentially more frequent scheduling decisions as job deadlines change relative order. Each preemption can introduce context-switching, cache, pipeline, and scheduler costs. On modern processors these costs may be manageable, but high-frequency embedded control systems must include them in worst-case timing analysis. The theoretical U ≤ 1 limit should therefore not be interpreted as a practical recommendation to operate continuously at exactly 100 percent CPU utilization.

Release jitter and interrupt interference further reduce the simplicity of the ideal EDF model. Sensor interrupts, communication events, DMA completion, kernel services, and hardware-dependent delays can shift the effective release time of software tasks. If jobs arrive later or in bursts, their remaining time before deadline decreases. Practical EDF analysis must therefore consider not only nominal Cᵢ, Tᵢ, and Dᵢ values but also release jitter, scheduler latency, interrupt execution, and other sources of temporal interference.

Shared resources create additional scheduling challenges. An early-deadline job may become blocked because another task holds a mutex, communication buffer, device interface, or other exclusive resource. Dynamic priority alone cannot eliminate this blocking and may interact with priority inversion. Resource-access protocols designed for dynamic-priority scheduling, such as the Stack Resource Policy, can provide bounded blocking behavior and help preserve analyzability when EDF tasks share mutually exclusive resources.

EDF implementation also depends strongly on RTOS capabilities. Many embedded kernels are fundamentally designed around fixed numeric priority levels, making RMS-like scheduling straightforward while EDF requires additional scheduling logic or kernel modification. Systems supporting deadline-oriented policies can provide more direct mechanisms. Linux, for example, provides deadline scheduling concepts based on runtime, deadline, and period parameters, illustrating how EDF-related principles can be integrated with execution-time reservation mechanisms.

In robotics, EDF can be useful when tasks have heterogeneous or dynamically meaningful deadlines. Sensor processing may need completion before the next fusion cycle, trajectory updates before a control horizon expires, communication packets before network freshness limits, and planning jobs before motion decisions become obsolete. EDF allows these jobs to compete according to actual deadline urgency instead of assigning priority solely from nominal execution frequency, which can improve processor use in workloads with diverse timing requirements.

Nevertheless, very fast deterministic control loops are often easier to reason about using fixed priorities, dedicated cores, interrupts, or hardware-level execution. A 1 kHz servo task with strict jitter requirements may benefit more from stable processor placement and predictable interference than from dynamically changing priorities. For this reason, practical robotic architectures may combine fixed-priority control scheduling with EDF-like scheduling for higher-level computation rather than forcing every workload into a single scheduling policy.

Multicore processors further complicate EDF. Global EDF allows jobs to migrate among processors and selects globally urgent deadlines, potentially improving load balancing but introducing migration and shared-resource overhead. Partitioned EDF assigns tasks to specific cores and applies EDF independently within each partition, reducing migration but creating a task-allocation problem. Cache contention, memory bandwidth, interrupt affinity, and inter-core communication remain important even when theoretical processor utilization appears sufficient.

EDF becomes particularly challenging for AI inference workloads because their execution times may vary substantially with model architecture, input characteristics, GPU contention, batching, and accelerator scheduling. A deadline can express when perception or inference results become stale, but EDF cannot guarantee completion unless execution demand is bounded and the underlying compute resource is schedulable. Deadline assignment therefore does not replace WCET estimation, execution reservation, admission control, or overload management.

A practical EDF design process begins by defining execution times, release patterns, periods, and relative deadlines, then converting each released job into an absolute deadline. Processor demand is analyzed using the schedulability test appropriate to the deadline model, while blocking, jitter, interrupts, and scheduling overhead are incorporated into the timing budget. Implementation is then validated through tracing and worst-case workload testing to confirm that actual deadline behavior remains consistent with theoretical assumptions.

EDF should therefore be understood as both a powerful scheduling theory and an engineering tradeoff. Its dynamic priorities can provide excellent processor utilization and direct deadline-oriented execution, but they introduce runtime complexity, overload sensitivity, resource-sharing issues, and implementation overhead. In real-time robotics, the objective is not simply to select EDF because it has a higher theoretical utilization limit, but to determine whether its deadline-driven flexibility improves predictability and resource efficiency for the actual workload.

05.04 Mixed Criticality Scheduling

Mixed-Criticality Scheduling (MCS) addresses systems in which software functions with different assurance, safety, and timing requirements share the same computing platform. Instead of treating every task as equally important, the scheduler distinguishes criticality levels and protects the execution of safety-critical functions when processor demand becomes greater than expected. This concept is increasingly important in robots where control, safety, perception, communication, and AI workloads coexist.

A mixed-criticality task can be represented by conventional timing parameters such as period Tᵢ and deadline Dᵢ, together with a criticality level Lᵢ and multiple worst-case execution-time estimates. A simplified dual-criticality model may define Cᵢ(LO) for normal operation and Cᵢ(HI) for a more conservative high-assurance condition. High-criticality tasks generally satisfy Cᵢ(HI) ≥ Cᵢ(LO), reflecting the larger execution budget required to provide stronger timing assurance.

Criticality should not be confused with ordinary scheduling priority. Priority determines which ready task executes first at a particular instant, while criticality expresses the level of assurance or protection required when system resources become insufficient. A high-frequency communication task can have a relatively high runtime priority while still being less safety-critical than a lower-frequency emergency function. Mixed-criticality scheduling therefore introduces another design dimension beyond conventional priority ordering.

The fundamental MCS mechanism is operating-mode management. During normal operation, commonly called low-criticality mode or LO mode, both high-criticality and low-criticality tasks can execute using their normal execution budgets. If a high-criticality task exceeds its assumed LO-mode execution budget, the system can switch into high-criticality mode, or HI mode. The scheduler then reallocates processor capacity so that critical functions retain sufficient resources to meet their deadlines.

Mode switching is therefore a controlled response to execution-time uncertainty rather than simply an indication that the processor has failed. When a high-criticality task executes beyond Cᵢ(LO), the scheduler assumes that optimistic timing assumptions may no longer be valid. It activates the more conservative Cᵢ(HI) budget and reduces competing workload. This mechanism provides temporal protection for essential functions even when actual execution demand differs from the assumptions used during normal operation.

Low-criticality tasks can be handled in several ways after a transition to HI mode. The classical theoretical model may suspend or discard them completely, freeing processor capacity for high-criticality tasks. Practical systems often use less severe degradation strategies. Logging frequency may be reduced, visualization can be disabled, communication updates can be slowed, and nonessential perception or planning functions can operate at reduced quality while safety and control functions remain protected.

Schedulability analysis must consider each operating mode rather than evaluating only total average CPU utilization. In LO mode, the system must verify that the complete workload can satisfy its timing requirements under normal execution budgets. In HI mode, analysis must verify that high-criticality tasks remain schedulable using their larger conservative budgets after the defined degradation policy is applied. A system is acceptable only when the required timing guarantees hold across all specified operating conditions.

Execution-time estimation is particularly important because MCS explicitly acknowledges that different assurance levels may require different WCET assumptions. Cᵢ(LO) may represent a realistic execution budget obtained from measurement or normal operating conditions, while Cᵢ(HI) can include stronger margins and more pessimistic timing behavior. The distinction allows normal operation to use computing resources efficiently without forcing every workload to operate continuously according to the most conservative assumptions.

Mode transition itself introduces timing complexity. When an overrun is detected, high-criticality tasks may already be executing while lower-criticality jobs occupy processor time or hold shared resources. The scheduler must define precisely when the transition occurs, which tasks are suspended or degraded, how existing jobs are handled, and how execution budgets are updated. Transition latency must be bounded because an excessively slow mode change can consume the timing margin intended to protect critical tasks.

Returning from HI mode to normal operation is also an important engineering problem. Immediate recovery after one task completes can cause repeated oscillation between modes if execution demand remains unstable. Practical systems may wait for a synchronization point, a predefined number of successful cycles, or an explicit health-management decision before restoring degraded workloads. Recovery policy therefore becomes part of system-level scheduling design rather than merely an implementation detail.

Shared resources require special attention in mixed-criticality systems. A high-criticality task can still be delayed if a low-criticality task holds a mutex, communication buffer, device driver, or shared hardware resource when a mode switch occurs. Suspending the lower-criticality task without releasing or safely transferring the resource can create severe blocking. Resource-access protocols and bounded critical sections must therefore be designed together with the mixed-criticality scheduling policy.

Spatial isolation can complement temporal scheduling. Safety-critical control software may execute on a dedicated MCU or CPU core, while perception and AI workloads operate on separate processors or accelerators. Memory protection, process isolation, hypervisors, and time partitioning can further prevent lower-assurance software from interfering with critical functions. Mixed-criticality scheduling is therefore often one component of a broader architecture combining temporal, spatial, and fault-containment mechanisms.

Robotic systems provide a natural example of mixed criticality. Emergency stopping, actuator protection, stability control, and watchdog functions can require the strongest guarantees. Motion control and localization may occupy another criticality level, while perception, mapping, communication, diagnostics, logging, and user-interface functions can tolerate varying degrees of degradation. The exact classification depends on the robot\'s hazards, operational design domain, and safety architecture rather than on computational complexity alone.

AI inference makes mixed-criticality design particularly relevant because AI execution time can be more variable than conventional periodic control software. Camera resolution, scene complexity, neural-network architecture, batching, GPU contention, and memory transfers can affect inference latency. An AI workload should not be allowed to consume unbounded compute time if doing so can interfere with braking, actuator control, watchdog processing, or another safety-related function. Compute budgets and isolation mechanisms therefore become essential.

Multicore systems create both opportunities and challenges for MCS. Critical workloads can be pinned to reserved cores while less critical functions use remaining processors, reducing direct scheduling interference. However, cores may still share last-level caches, DRAM bandwidth, interrupt controllers, interconnects, thermal limits, and I/O devices. Consequently, CPU affinity alone does not guarantee isolation, and interference through shared hardware must be considered when establishing worst-case timing guarantees.

Hypervisor-based architectures can extend mixed-criticality scheduling by separating software into virtual machines or partitions with different assurance requirements. A safety partition may receive guaranteed processor windows while Linux, ROS 2, perception, or AI applications execute in less critical partitions. Time partitioning can restrict when each domain runs, while memory and device isolation limit unintended interference. This approach is especially useful when heterogeneous software stacks must coexist on one computing platform.

Mixed-criticality scheduling should also coordinate with fault detection and system health management. An execution-budget overrun may result from abnormal input, software degradation, resource contention, hardware throttling, or an emerging fault. The scheduler can provide immediate temporal protection, but another subsystem may need to diagnose the cause and determine whether degraded operation remains acceptable. Scheduling mode therefore becomes part of the robot\'s overall operational state and safety response.

Verification requires testing more than nominal execution. Engineers should deliberately create execution overruns, CPU contention, interrupt bursts, communication congestion, memory pressure, and delayed task releases while observing mode transitions and deadline behavior. Tracing should confirm when overruns are detected, which workloads are degraded, how quickly processor capacity is reclaimed, and whether high-criticality tasks continue meeting their deadlines throughout the transition and degraded operating state.

A practical MCS design begins by identifying timing-critical functions, assigning justified criticality levels, defining periods and deadlines, and establishing execution budgets for each relevant assurance mode. The architecture then specifies mode-switch triggers, degradation actions, resource-access rules, processor allocation, and recovery conditions. Schedulability analysis and worst-case testing must cover both steady-state modes and transitions rather than validating only normal CPU utilization.

Mixed-Criticality Scheduling ultimately provides a structured method for answering what a real-time robotic system should preserve when all requested computation can no longer be executed simultaneously. Instead of allowing uncontrolled overload to determine which deadlines fail, the architecture intentionally sacrifices or degrades less critical work to protect essential functions. Its purpose is therefore not simply efficient CPU scheduling, but predictable preservation of safety and control under changing computational demand.

05.05 Robot Task Priority Design: Control, Perception, Comm [w/Code]

Robot task priority design determines how limited computing resources are distributed among control, perception, communication, safety, and supporting functions while preserving required timing behavior. Unlike purely theoretical scheduling problems, robot software combines periodic control loops, event-driven processing, variable perception workloads, and network traffic. Priority design must therefore reflect deadlines, execution rates, criticality, dependencies, and consequences of delayed execution.

Control tasks normally require highly deterministic execution because their outputs directly affect actuators and physical motion. Motor-current control, joint servo loops, steering control, velocity regulation, and stabilization may operate from hundreds of hertz to several kilohertz. Excessive latency or jitter can degrade control quality or destabilize the system. These functions therefore commonly occupy high-priority real-time scheduling domains with bounded execution times and carefully controlled interference.

Safety functions require separate consideration because scheduling priority and safety criticality are not identical concepts. Emergency-stop processing, watchdog supervision, actuator protection, collision-response logic, and fault handling may execute less frequently than servo control but require extremely short and dependable reaction times when triggered. Such functions can use high-priority tasks, interrupts, dedicated safety processors, or isolated execution domains depending on the required safety architecture.

Perception workloads have fundamentally different timing characteristics from low-level control. Camera processing, LiDAR processing, object detection, semantic segmentation, terrain analysis, and sensor fusion often require substantially more computation and may exhibit input-dependent execution times. Their useful update rates may range from several hertz to tens of hertz. They need timely execution, but allowing perception computation to delay a deterministic actuator-control loop can create unacceptable physical-system behavior.

The relationship between perception and control should therefore be based on data freshness rather than forcing both functions to execute at identical rates. A camera may produce images at 30 or 60 frames per second while a motion controller executes at hundreds or thousands of hertz. The controller can continue operating using the latest validated state estimate between perception updates. Timestamping, buffering, interpolation, prediction, and state estimation connect these different temporal domains without requiring direct one-to-one execution.

Communication tasks introduce another timing domain. CAN, CANopen, EtherCAT, Ethernet, DDS, ROS 2 messaging, and other communication mechanisms transfer commands, measurements, state information, and diagnostics between computing nodes. Their scheduling requirements depend on message purpose. A motor command or synchronized feedback message can require strict timing, while telemetry, logging, map transfer, and user-interface data can tolerate substantially greater latency and jitter.

Communication priority should consequently be designed according to the semantics of the transmitted information rather than the communication protocol alone. Control feedback carried over CAN may deserve higher scheduling priority than diagnostic traffic on the same bus. Likewise, an Ethernet packet containing a time-sensitive actuator command differs fundamentally from a large perception-data transfer. CPU scheduling, network queue priority, protocol QoS, and application-level deadlines should therefore be coordinated instead of designed independently.

A practical priority hierarchy often places hard real-time control and immediate safety processing at the highest protected levels, followed by time-sensitive state estimation and control-related communication. Perception and planning occupy intermediate levels according to their deadlines and degradation tolerance, while telemetry, visualization, logging, database updates, and maintenance functions normally execute at lower priorities. This hierarchy is a design starting point rather than a universal ordering for every robot.

Task dependencies can alter apparently simple priority assignments. A high-priority control task may depend on state information produced by a lower-priority estimation task, or a perception pipeline may wait for sensor data delivered by a communication thread. If producer tasks cannot execute soon enough, increasing the consumer\'s priority does not improve system latency. Priority design must therefore analyze end-to-end execution chains rather than optimizing isolated threads without considering data dependencies.

Rate Monotonic Scheduling provides a useful baseline when robot workloads consist of stable periodic tasks. Short-period servo and acquisition tasks naturally receive higher priorities than slower monitoring functions. However, period alone does not represent safety importance, end-to-end deadlines, resource dependencies, or variable computational demand. Practical robot scheduling may therefore begin with rate-based priority assignment and then refine the hierarchy using response-time, criticality, and dependency analysis.

Deadline-oriented scheduling can be useful for perception, planning, and communication workloads whose urgency depends more directly on data validity than on fixed execution frequency. A trajectory update must complete before the current trajectory becomes unsuitable, while perception information loses value as it ages. Such tasks can be interpreted through relative or absolute deadlines, allowing the architecture to distinguish computational frequency from the time at which a result must become available.

Shared resources are a major source of priority interference. Control, perception, and communication threads may compete for mutexes, memory buffers, device drivers, DMA channels, shared memory, or hardware interfaces. A low-priority logging or communication task holding a required resource can block a high-priority control function and create priority inversion. Critical sections should therefore be bounded, and mechanisms such as priority inheritance or priority ceiling should be used where appropriate.

Multicore processors allow scheduling domains to be separated physically as well as logically. A dedicated core can execute high-frequency control loops while other cores process perception, planning, communication, and system services. CPU affinity and interrupt affinity reduce unwanted migration and scheduling interference. However, shared caches, DRAM bandwidth, I/O buses, and memory controllers can still create cross-core interference, so core separation alone does not provide complete temporal isolation.

Heterogeneous robot computers add another layer because CPUs, GPUs, NPUs, and microcontrollers execute different portions of the workload. A GPU may perform perception inference while a real-time CPU executes state estimation and an MCU closes motor-control loops. Priority design must therefore extend beyond one operating-system scheduler. Compute reservations, queue management, synchronization, communication latency, and backpressure across processors determine the actual end-to-end timing behavior.

Overload behavior should be defined before deployment rather than discovered during operation. When CPU or accelerator demand exceeds available capacity, the system should preserve safety and control while intentionally degrading less critical functions. Perception frame rates can be reduced, visualization disabled, map updates postponed, and diagnostic traffic throttled. Mixed-criticality principles provide a structured way to determine which robot functions remain protected when all requested computation cannot execute simultaneously.

Release jitter must also be considered because robot tasks are frequently activated by timers, interrupts, network packets, DMA completion, or upstream software events. Even if execution time is bounded, irregular activation can change interference patterns and increase end-to-end latency. Timestamped sensor acquisition and synchronized clocks help separate measurement time from processing time, while scheduling analysis determines whether delayed releases can still satisfy downstream control and perception deadlines.

A useful robot scheduling architecture therefore operates across multiple rates. Fast actuator loops can execute at deterministic high frequencies, state estimation at intermediate rates, perception and planning at slower rates, and fleet or diagnostic communication at still different intervals. These layers exchange timestamped state rather than assuming synchronous execution. Such a multi-rate architecture reflects the physical reality that sensing, reasoning, networking, and actuator control have fundamentally different temporal requirements.

Priority design must ultimately be validated through measurement. Engineers should observe worst-case execution time, response time, release jitter, preemption, blocking duration, CPU utilization, communication latency, and deadline misses while generating realistic processor, network, and sensor loads. Trace data should reveal whether high-priority control remains deterministic when perception inference, communication bursts, logging, and other background workloads execute simultaneously.

A disciplined design process begins by classifying every task according to function, period, deadline, WCET, criticality, dependencies, resource usage, and degradation tolerance. Tasks are then assigned to scheduling domains and processors, priorities are established, shared-resource behavior is analyzed, and overload policies are defined. Response-time analysis and stress testing verify the resulting architecture before deployment. The objective is not to maximize the priority of every important task, but to construct a coherent temporal hierarchy.

Effective robot task priority design therefore connects physical dynamics with software scheduling. Control requires deterministic execution, perception requires sufficiently fresh environmental information, communication must deliver time-sensitive data within its validity window, and noncritical services must not interfere with these functions. When priorities, processor allocation, communication QoS, and overload management are designed together, the robot can maintain predictable behavior even while executing heterogeneous workloads.

05.06 Multi-Core Scheduling: AMP vs SMP Design

Asymmetric Multiprocessing (AMP) and Symmetric Multiprocessing (SMP) provide two fundamentally different approaches to organizing real-time workloads across multiple processor cores. AMP assigns cores to predefined software domains or tasks, while SMP allows a common operating system scheduler to distribute runnable tasks across available cores. The design choice directly affects determinism, load balancing, fault isolation, resource sharing, and the complexity of real-time scheduling analysis.

In an AMP architecture, each processor core or group of cores is assigned a specific execution responsibility. One core may execute actuator control, another may handle state estimation, and other cores may run perception or communication workloads. Tasks generally remain within their assigned processing domain rather than migrating dynamically. This static allocation simplifies reasoning about interference because the set of tasks competing for each core can be explicitly defined during system design.

AMP is particularly attractive for hard real-time control because processor affinity can create predictable execution environments. A dedicated core can run high-frequency servo loops without competing directly with perception, logging, or user-interface threads. Interrupts can also be routed toward specific cores, further reducing scheduling disturbance. The resulting architecture resembles several independent uniprocessor systems connected through shared memory or interprocessor communication mechanisms.

The primary limitation of AMP is reduced flexibility in processor utilization. A dedicated control core may be lightly loaded while another core becomes overloaded with perception or planning tasks. Because workloads are statically partitioned, unused processing capacity cannot automatically be transferred to overloaded cores. Task allocation therefore becomes an important design problem, and engineers must estimate execution demand carefully enough to avoid both excessive reservation and localized overload.

SMP takes the opposite approach by presenting multiple processor cores as a shared execution resource managed by one operating system scheduler. Runnable tasks can be dispatched to different cores according to priority, affinity, processor availability, and scheduling policy. This improves load balancing because idle cores can execute available work. General-purpose operating systems and many modern RTOS implementations use SMP because it provides flexible utilization of multicore processors.

Task migration is one of the defining characteristics of SMP. A task executing on Core 1 may later resume on Core 2 if the scheduler determines that another placement is preferable. Migration can improve processor utilization and responsiveness, but it also creates timing costs. Cache contents associated with the task may no longer be local, translation structures may require reloading, and shared-memory traffic can increase. These effects complicate worst-case execution-time and response-time analysis.

The AMP-versus-SMP decision should therefore not be reduced to static versus dynamic scheduling alone. AMP favors isolation and analyzability, whereas SMP favors flexibility and aggregate resource efficiency. A robot with strict actuator timing may benefit from AMP-style core partitioning, while computationally variable perception and planning workloads can benefit from SMP scheduling. Many practical architectures consequently combine characteristics of both models instead of adopting either approach exclusively.

CPU affinity provides an important bridge between AMP and SMP. Even under an SMP operating system, selected real-time tasks can be pinned to specific cores, preventing unwanted migration. Other tasks remain free to migrate across the remaining processors. This creates a partitioned SMP architecture in which deterministic control workloads receive dedicated execution resources while general-purpose workloads retain dynamic load balancing. Such hybrid designs are common in high-performance robotic computers.

Interrupt affinity is equally important because isolating a task on a CPU core does not guarantee deterministic behavior if unrelated device interrupts continue executing on that core. Network interfaces, storage devices, cameras, communication controllers, and other peripherals may generate significant interrupt activity. Routing noncritical interrupts away from real-time cores can reduce execution jitter. Timer interrupts and required hardware events must then be analyzed as part of the remaining interference.

Multicore scheduling introduces shared-hardware interference even when software tasks are perfectly partitioned. Processor cores may share last-level cache, DRAM channels, memory controllers, system interconnects, and I/O resources. A perception workload performing large memory transfers can therefore increase memory-access latency for a control task running on another core. Temporal isolation requires consideration of these shared resources rather than relying exclusively on CPU-core assignment.

Cache behavior is especially important when comparing AMP and SMP. AMP can improve cache locality because tasks repeatedly execute on the same cores, allowing instruction and data working sets to remain relatively stable. SMP migration can reduce locality and create cache-related preemption and migration delays. However, even pinned tasks may interfere through shared cache levels, so cache partitioning, memory placement, or workload separation may be necessary for demanding real-time systems.

Synchronization becomes more complex when tasks execute concurrently on different cores. Mutexes, spinlocks, semaphores, atomic operations, and lock-free data structures may protect shared state, but each mechanism introduces timing implications. A high-priority task on one core can wait for a lower-priority task on another core holding a shared lock. Multicore priority inversion and lock contention therefore require bounded critical sections and carefully selected synchronization protocols.

Interprocessor communication is central to AMP because separately assigned processing domains must exchange commands and state information. Shared-memory queues, ring buffers, mailboxes, message passing, and interprocessor interrupts can connect these domains. The communication interface should minimize blocking and preserve data consistency while maintaining bounded latency. Timestamped messages are particularly useful in robots because different cores may execute control, estimation, perception, and communication at different rates.

SMP systems require attention to global and partitioned scheduling strategies. Global scheduling allows tasks to execute on any eligible processor and potentially migrate between cores, providing flexible load distribution. Partitioned scheduling assigns tasks to processors first and then schedules each processor independently. Partitioned approaches improve analyzability but create a bin-packing-like allocation problem, while global approaches reduce static allocation constraints at the cost of migration and more complex interference analysis.

Robot computing architectures naturally support functional partitioning. A real-time core can execute motion control, another core can process localization and state estimation, and a group of cores can support ROS 2 communication, planning, and system services. GPU or NPU accelerators may separately execute neural-network inference. This heterogeneous arrangement extends multicore scheduling beyond CPU cores and requires explicit management of queues, synchronization, accelerator access, and end-to-end deadlines.

Perception workloads often favor flexible multicore allocation because their computational demand varies with sensor input, algorithms, and processing pipelines. Camera decoding, point-cloud processing, object detection preparation, mapping, and planning can exploit parallel execution across multiple cores. In contrast, high-frequency control tasks frequently benefit from stable core placement. Combining fixed placement for deterministic functions with shared cores for computational workloads provides a practical balance between predictability and efficiency.

Communication processing also influences core design. CAN or EtherCAT handling associated with actuator control may be placed near the real-time control domain, while Ethernet, DDS, ROS 2, telemetry, and fleet communication can execute on general-purpose cores. Network interrupts and protocol processing must be assigned carefully because high packet rates can consume substantial CPU time. Communication architecture and CPU scheduling should therefore be designed as one timing system.

Overload containment differs between AMP and SMP. In AMP, excessive computation within one partition can be prevented from directly consuming another partition\'s dedicated CPU time, providing natural temporal containment. In SMP, an overloaded workload can potentially occupy multiple processors unless affinity, bandwidth control, reservations, or scheduling policies restrict it. For robots, uncontrolled perception or AI workload expansion should never be allowed to consume the processing capacity reserved for safety and actuator control.

Fault containment can also favor partitioned architectures. If a software component on one core becomes unresponsive, independently scheduled control functions on another core may continue operating. However, shared memory corruption, kernel failures, thermal throttling, or common hardware resources can still propagate failures. Strong isolation may therefore require memory protection, separate operating-system instances, hypervisors, or even physically separate processors in addition to multicore task allocation.

Validation of multicore scheduling requires measurements beyond average CPU utilization. Engineers should monitor per-core utilization, task migration, response time, execution jitter, interrupt distribution, lock contention, cache behavior, memory bandwidth, and deadline misses. Stress tests should run perception, networking, storage, logging, and AI inference simultaneously while verifying deterministic control execution. A system showing low total CPU utilization can still fail if one critical core or shared resource becomes overloaded.

A practical AMP/SMP design process begins by classifying tasks according to timing criticality, execution variability, communication dependency, and resource demand. Highly deterministic tasks can be assigned protected cores, while flexible workloads can share an SMP pool. CPU and interrupt affinity, synchronization, memory behavior, communication paths, and overload policies are then defined. Response-time analysis and multicore stress testing verify whether the resulting architecture satisfies required deadlines.

The most effective robotic multicore architecture is therefore often hybrid rather than purely AMP or purely SMP. AMP-like partitioning provides deterministic execution for safety and control, while SMP provides efficient load balancing for perception, planning, communication, and supporting software. By combining core isolation, controlled affinity, bounded synchronization, shared-resource management, and heterogeneous acceleration, a robot can exploit multicore performance without sacrificing the temporal predictability required for physical control.

05.07 Hypervisor-Based Scheduling Isolation: Xen, KVM, RT

Hypervisor-based scheduling extends real-time scheduling beyond a single operating system by introducing a virtualization layer that controls how processor time, memory, devices, and interrupts are distributed among isolated software domains. Instead of allowing every application to compete within one scheduler, a hypervisor creates multiple execution environments with independently managed workloads. This approach is increasingly valuable in robotic systems where safety-critical control, Linux applications, ROS 2, perception, and AI workloads must coexist without compromising deterministic behavior.

A hypervisor operates beneath guest operating systems and becomes the first software layer responsible for allocating hardware resources. Guest systems such as Linux, RTOS instances, or specialized control software execute inside isolated virtual machines or partitions rather than directly controlling the hardware. The hypervisor therefore determines which processor cores execute each guest, when execution occurs, how interrupts are delivered, and which devices each software domain can access.

Virtualization should not be viewed solely as a cloud-computing technology. In embedded and robotic platforms, its primary purpose is often deterministic isolation rather than server consolidation. Safety-critical control software may execute independently from perception and user-interface applications even while sharing the same physical processor. This architectural separation reduces unintended interference and supports stronger timing guarantees for functions that cannot tolerate unpredictable execution delays.

Hypervisors are commonly classified as Type 1 or Type 2. A Type 1 hypervisor executes directly on hardware and generally provides stronger control over processor scheduling, interrupts, and memory isolation. A Type 2 hypervisor executes on top of another operating system, making it convenient for development but less suitable for demanding real-time deployment because the host operating system remains part of the scheduling path.

Xen represents a mature Type 1 hypervisor architecture frequently discussed in embedded virtualization. Xen separates system responsibilities into privileged and guest domains, allowing independent operating systems to execute simultaneously while maintaining controlled communication between domains. Different processor cores can be assigned to different guests, making Xen attractive for systems combining Linux applications with isolated real-time workloads.

Xen scheduling can be configured using different scheduling policies depending on workload characteristics. General-purpose workloads may prioritize fairness, while real-time configurations emphasize predictable execution windows and bounded interference. CPU pinning allows guest domains to execute on dedicated cores, reducing migration-related timing variation. This capability aligns well with robotic architectures that reserve processor resources for deterministic control functions.

KVM (Kernel-based Virtual Machine) takes a different architectural approach by integrating virtualization directly into the Linux kernel. Instead of introducing a completely separate hypervisor layer, KVM transforms Linux into a hypervisor while relying on Linux scheduling and virtualization infrastructure. This design provides excellent compatibility with Linux software ecosystems and makes virtualization accessible through standard Linux management tools.

Real-time KVM configurations often combine KVM with PREEMPT_RT Linux to improve deterministic behavior. PREEMPT_RT reduces kernel latency, while CPU isolation, interrupt affinity, and dedicated processor assignment help protect virtual-machine execution. Although KVM benefits from mature Linux infrastructure, achieving predictable timing generally requires careful system configuration rather than relying on default scheduling behavior.

CPU isolation is one of the most important hypervisor scheduling techniques. Safety-critical virtual machines can receive exclusive processor cores, preventing ordinary Linux applications from competing for those execution resources. Processor affinity and scheduler configuration then ensure that control-related execution remains confined to reserved hardware. This resembles AMP-style partitioning while preserving virtualization-based management and isolation capabilities.

Time partitioning extends isolation by allocating execution windows instead of relying only on processor ownership. Each virtual machine receives predefined processor time according to a scheduling plan, preventing one domain from consuming unlimited computation. Even when one guest experiences heavy workload or software malfunction, another guest\'s reserved execution windows remain protected. Time partitioning therefore provides temporal isolation in addition to spatial separation.

Interrupt virtualization introduces another important scheduling consideration. Physical interrupts generated by sensors, communication devices, storage systems, or timers must be routed through the hypervisor before reaching guest operating systems. Poor interrupt placement can introduce additional latency or jitter. Real-time configurations therefore frequently dedicate interrupts to specific cores and minimize unnecessary interrupt sharing between critical and noncritical domains.

Memory isolation provides another foundation for predictable behavior. Each guest receives protected memory regions, preventing accidental modification by other software domains. However, memory bandwidth, shared caches, DRAM controllers, and system interconnects may still create performance interference. Hypervisor scheduling must therefore consider shared hardware behavior rather than assuming that memory protection alone guarantees temporal independence.

Device assignment significantly influences scheduling predictability. Hypervisors may virtualize devices through shared interfaces or assign physical devices directly to specific guests using hardware-assisted mechanisms. Direct assignment reduces virtualization overhead and timing uncertainty for critical peripherals such as industrial communication controllers, while shared virtual devices improve flexibility for less critical workloads. The assignment strategy therefore depends on both timing requirements and resource-sharing goals.

Inter-domain communication becomes essential because isolated virtual machines rarely operate independently. Control software, perception software, planning modules, and monitoring services must exchange commands and state information while preserving isolation guarantees. Shared-memory channels, virtual communication devices, message passing, and carefully controlled interfaces allow cooperation without removing architectural boundaries. Timestamped communication helps maintain consistency across independently scheduled domains.

Scheduling interference still exists even inside virtualized systems. Shared processor caches, memory buses, DMA activity, GPU access, and simultaneous peripheral traffic can affect execution time across otherwise isolated guests. Consequently, hypervisor scheduling cannot rely exclusively on virtual-machine boundaries. Engineers must analyze hardware contention together with virtual scheduling policies when establishing worst-case timing guarantees.

Robotic architectures naturally benefit from hypervisor partitioning. A real-time guest can execute actuator control, safety monitoring, and state estimation, while Linux guests handle ROS 2 communication, perception pipelines, planning, user interfaces, and fleet-management software. GPU resources may support AI inference independently, while communication between domains remains explicitly managed. This organization separates deterministic control from computationally variable software without requiring physically separate computers.

Mixed-criticality systems frequently combine hypervisors with criticality-aware scheduling. High-criticality guests receive protected processor resources, while lower-criticality guests can experience controlled degradation under heavy computational demand. Instead of allowing uncontrolled overload to affect every application equally, virtualization preserves execution guarantees for essential functions. Hypervisor scheduling therefore complements mixed-criticality design rather than replacing it.

Multicore processors further strengthen hypervisor scheduling capabilities. Dedicated cores can execute real-time guests, while shared cores host Linux and application workloads. CPU affinity, interrupt affinity, and controlled migration reduce timing variability, although shared caches and memory resources still require analysis. The objective is not merely separating software logically, but constructing hardware-aware execution domains with predictable temporal behavior.

Real-time scheduling analysis changes when virtualization is introduced. Engineers must account for guest execution time, hypervisor scheduling latency, virtual interrupt delivery, device virtualization overhead, shared-resource interference, and communication delays between guests. Measuring only application execution time is insufficient because virtualization introduces additional scheduling layers that contribute to worst-case response time.

Validation therefore requires workload combinations that stress both virtualization and real-time behavior simultaneously. Control loops, perception inference, network traffic, storage activity, ROS 2 communication, and AI workloads should execute concurrently while engineers measure interrupt latency, response time, execution jitter, virtual-machine scheduling behavior, and deadline compliance. Trace tools should confirm that critical guests continue meeting timing requirements even when noncritical guests generate heavy computational pressure.

A practical hypervisor-based scheduling design begins by classifying workloads according to timing criticality, communication requirements, and resource usage. Critical functions receive dedicated processor resources, carefully assigned interrupts, protected memory, and bounded communication paths, while flexible workloads occupy shared domains with appropriate scheduling policies. CPU isolation, time partitioning, device assignment, and multicore interference analysis are then integrated into one architecture before real-time validation under representative operating conditions.

Hypervisor-based scheduling ultimately provides a structured method for combining deterministic control and complex software ecosystems on a single computing platform. Xen emphasizes strong partitioning through a dedicated hypervisor architecture, while KVM leverages the Linux ecosystem with appropriate real-time configuration. When processor isolation, interrupt management, memory protection, device assignment, and temporal scheduling are designed together, virtualization becomes a practical tool for building predictable, mixed-workload robotic systems rather than merely a method for running multiple operating systems.

05.08 Real-Time Scheduling Challenges for AI Inference Tasks

Real-time scheduling for AI inference differs fundamentally from scheduling conventional periodic control tasks because inference execution time is often highly variable and depends on model architecture, input size, accelerator state, memory traffic, and runtime optimization. A motor-control task may have a measurable worst-case execution time, while a neural-network pipeline can exhibit substantially larger timing variation. This makes deterministic deadline guarantees more difficult.

AI inference in robotics is commonly used for object detection, semantic segmentation, depth estimation, terrain classification, localization support, language processing, and learned planning. These workloads usually execute at lower rates than actuator control but consume much greater computational resources. Their scheduling problem is therefore not simply achieving maximum throughput, but producing sufficiently fresh results without interfering with safety-critical and control workloads.

Average inference latency is insufficient for real-time design. A model that normally completes in 20 ms but occasionally requires 60 ms cannot safely be treated as a 20 ms task when its deadline is 33 ms. Engineers must consider latency distributions, tail latency, worst observed execution time, and ideally a defensible worst-case execution time(WCET). Rare inference delays can become important when perception outputs directly influence physical motion.

Execution-time variability originates from several layers. Neural networks contain different operators, tensor dimensions, conditional paths, preprocessing stages, memory transfers, and postprocessing operations. Runtime libraries may select different kernels, while caches and memory allocation can change execution behavior. GPU frequency scaling, thermal throttling, concurrent kernels, and background workloads introduce additional variation that does not appear in simplified model-level timing estimates.

Accelerator scheduling creates challenges beyond CPU scheduling. A CPU real-time scheduler can prioritize threads, but a high-priority CPU thread launching GPU work does not automatically receive equivalent priority inside the GPU. Multiple inference processes may compete for streaming multiprocessors, memory bandwidth, execution queues, and accelerator memory. End-to-end scheduling must therefore include both CPU execution and accelerator service rather than treating the GPU as an instantaneous coprocessor.

Data transfer is another important source of latency. Camera images, LiDAR tensors, feature maps, and neural-network parameters may move between sensors, system memory, CPU caches, and accelerator memory. DMA can reduce CPU involvement but still consumes memory and interconnect bandwidth. Consequently, inference response time includes acquisition, preprocessing, transfer, accelerator execution, synchronization, postprocessing, and result delivery rather than neural-network execution alone.

Batching illustrates the conflict between throughput and real-time latency. Processing several inputs together can increase accelerator utilization and overall throughput, which is desirable for cloud workloads. A robot, however, may need the newest sensor result immediately. Waiting to construct a larger batch increases queueing delay and data age. Real-time inference therefore often favors small or fixed batches even when this reduces maximum accelerator efficiency.

Queue management is equally important because overloaded inference pipelines can accumulate stale sensor data. Processing every queued camera frame may cause the system to operate on increasingly old observations even though inference itself remains functional. For many robotic applications, dropping obsolete frames and processing the newest available observation is safer than preserving every input. Queue depth should therefore be explicitly bounded according to freshness requirements.

Deadline and frame rate should not be treated as identical concepts. A perception model running at 20 Hz has a nominal 50 ms period, but its useful deadline may be shorter or longer depending on robot dynamics and downstream consumers. A controller may require updated obstacle information before a predicted collision boundary is reached. Scheduling requirements should therefore be derived from information validity and physical-system response rather than frame rate alone.

Multi-rate architecture helps separate AI inference from deterministic control. A perception model may operate at 10--30 Hz while state estimation executes at 100--200 Hz and motor control operates at 1 kHz. The faster layers continue using the latest validated state while waiting for new inference results. Timestamping, prediction, interpolation, and uncertainty estimation allow asynchronous AI outputs to participate in control without forcing control loops to wait for every neural-network execution.

Priority assignment alone cannot guarantee AI timing because resource contention may occur outside the CPU scheduler. A high-priority inference process can still experience delays caused by GPU kernels launched by another application, shared DRAM bandwidth, PCIe traffic, memory allocation, or thermal management. Resource reservations, accelerator partitioning, bandwidth management, dedicated execution contexts, and workload admission control may therefore be required for stronger timing isolation.

CPU affinity and accelerator isolation can reduce interference. Critical preprocessing and result-handling threads may be pinned to selected CPU cores while background services execute elsewhere. Where hardware permits, accelerator resources can also be partitioned or assigned to specific workloads. Isolation is particularly useful when one computer simultaneously executes perception, mapping, visualization, logging, simulation, communication, and multiple neural-network models.

Model architecture strongly affects schedulability. Larger networks may improve perception accuracy but increase execution time, memory consumption, and timing variance. Real-time deployment therefore requires balancing accuracy with latency and predictability. Quantization, pruning, operator fusion, reduced input resolution, optimized inference engines, and smaller model variants can reduce computational demand, but optimization should be evaluated using end-to-end timing rather than theoretical operation counts alone.

Dynamic model adaptation provides another strategy for maintaining deadlines. A robot can normally execute a high-accuracy model but switch to a smaller model, lower image resolution, reduced frame rate, or simplified perception pipeline when computational pressure increases. Such graceful degradation is preferable to uncontrolled deadline misses. The degradation policy should be predetermined so that safety and control functions remain protected during overload.

Admission control prevents excessive AI workloads from entering the system. Before launching another model or inference stream, the runtime can determine whether sufficient CPU, GPU, memory, and bandwidth capacity remains available. This concept resembles processor utilization analysis in classical real-time scheduling, although AI resources are multidimensional and execution times are less predictable. The objective is to reject or defer work before resource saturation produces cascading delays.

Mixed-criticality scheduling is especially relevant when AI inference shares hardware with physical control. Safety monitoring, actuator control, and essential state estimation should retain protected execution capacity even when perception or generative AI workloads become computationally expensive. Lower-criticality inference tasks may reduce frequency, skip frames, change models, or temporarily stop. AI scheduling must therefore include explicit overload behavior rather than assuming sufficient resources are always available.

Multicore CPU and heterogeneous processor architectures can provide structural isolation. Dedicated CPU cores may execute real-time control while an SMP pool handles preprocessing, ROS 2 communication, and planning, with GPUs or NPUs assigned to neural inference. This arrangement reduces direct competition but does not eliminate shared-cache, DRAM, I/O, and thermal interference. Hardware topology must therefore be incorporated into scheduling analysis.

Hypervisor-based isolation can strengthen separation when AI and control software execute on the same high-performance computer. A real-time guest may receive dedicated CPU cores and communication devices, while a Linux guest manages AI inference and general applications. Even then, shared accelerators and memory bandwidth remain possible interference paths. Virtualization should therefore be combined with resource partitioning rather than treated as a complete timing guarantee.

Thermal and power behavior introduces a distinctive challenge for sustained AI inference. A GPU may initially satisfy deadlines but later reduce its clock frequency after prolonged high utilization or temperature increase. Power-management policies can similarly alter processor frequency. Real-time validation must therefore include long-duration workloads and worst operating conditions instead of measuring only short inference benchmarks on an idle, cool system.

Observability is essential for diagnosing inference scheduling. Useful measurements include sensor timestamp, queueing delay, preprocessing time, accelerator submission time, kernel execution, synchronization delay, postprocessing, output timestamp, CPU utilization, accelerator utilization, memory bandwidth, and deadline misses. Measuring only frames per second can conceal severe tail latency or stale-data problems that directly affect robotic behavior.

Stress testing should reproduce realistic concurrent workloads. Perception inference should execute together with mapping, ROS 2 traffic, storage activity, network bursts, visualization, logging, and other AI models while critical control timing is monitored. Tests should also include thermal saturation, memory pressure, sensor bursts, and intentionally overloaded inference queues. The goal is to determine whether the complete platform remains predictable rather than proving that an isolated model runs quickly.

A practical real-time AI scheduling process begins by defining the required data freshness and end-to-end deadline for each inference function. Engineers then measure execution-time distributions, identify CPU, accelerator, memory, and communication dependencies, establish bounded queues, allocate resources, and define overload policies. Timing analysis is followed by stress testing under representative workloads, with sufficient margin reserved for execution variability and platform interference.

Real-time AI inference scheduling ultimately requires a shift from maximizing computational throughput to guaranteeing useful information at the correct time. Deterministic control should never depend blindly on variable AI execution, and AI pipelines should be designed around bounded latency, freshness, isolation, and graceful degradation. By coordinating CPU scheduling, accelerator allocation, queue management, model optimization, and mixed-criticality protection, robots can exploit powerful AI models while preserving predictable physical behavior.

05.09 Scheduling Analysis Tools: Cheddar / RTA-OS

Scheduling analysis tools transform real-time scheduling theory into an engineering process that can be applied before deployment. Instead of relying only on processor utilization or average execution time, engineers model tasks using parameters such as period, deadline, worst-case execution time, priority, release jitter, and blocking time. Analysis tools then determine whether every task can satisfy its timing constraints under specified scheduling assumptions.

A basic scheduling model represents each task τᵢ using execution time Cᵢ, period or minimum inter-arrival time Tᵢ, and relative deadline Dᵢ. Practical models may additionally include priority Pᵢ, release offset, jitter Jᵢ, blocking Bᵢ, precedence relationships, shared resources, and processor assignment. The accuracy of scheduling analysis depends strongly on whether these parameters represent realistic worst-case operating conditions rather than nominal measurements.

Processor utilization provides the simplest initial test. For periodic tasks, total utilization can be expressed as U=Σ(Cᵢ/Tᵢ). Utilization analysis quickly identifies obviously overloaded configurations and can test sufficient bounds for scheduling algorithms such as Rate Monotonic Scheduling. However, utilization alone does not describe interference, blocking, release patterns, or individual deadlines, so more detailed analysis is required for realistic robot systems.

Response-Time Analysis(RTA) provides a stronger method for fixed-priority systems. For task τᵢ, its worst-case response time can be computed iteratively from its own execution time plus interference from higher-priority tasks. A common formulation is Rᵢ=Cᵢ+Bᵢ+Σ⌈Rᵢ/Tⱼ⌉Cⱼ, with extensions for jitter and other effects. The task is considered schedulable when the converged response time remains no greater than its deadline.

RTA is particularly useful because it evaluates each task individually rather than treating processor utilization as one aggregate quantity. A processor may have moderate overall utilization while one low-priority task still misses its deadline because of repeated preemption. Conversely, a system exceeding a conservative utilization bound may remain schedulable. Response-time results therefore provide more actionable information for priority and timing design.

Cheddar is an analysis and simulation environment designed for real-time scheduling studies. It allows engineers to describe software architectures containing processors, tasks, scheduling policies, shared resources, and timing parameters. The modeled architecture can then be evaluated using schedulability analysis and scheduling simulation. This makes Cheddar useful for connecting theoretical scheduling concepts with concrete system configurations before implementation.

A Cheddar model can represent periodic and other task activation patterns together with execution times, deadlines, priorities, and processor assignments. Scheduling policies can be associated with processors so that different architectural alternatives can be studied. Engineers can modify task periods, priorities, execution budgets, or processor mappings and observe how those changes affect schedulability, making the tool useful during early design exploration.

Scheduling simulation complements analytical tests by providing a temporal view of task execution. A timeline can show task releases, execution intervals, preemptions, completions, idle processor time, and deadline violations. This visualization helps engineers understand why a particular configuration fails. Instead of receiving only a schedulable or unschedulable result, designers can inspect the interference pattern that produces excessive response time.

Simulation and analytical proof should not be confused. A simulation demonstrates behavior over the simulated interval and selected release scenario, whereas schedulability analysis attempts to establish guarantees according to a mathematical task model. A timeline without a deadline miss does not prove that all future schedules are safe. For hard real-time systems, simulation is therefore most valuable when combined with analytical methods such as utilization tests and RTA.

Shared-resource analysis is another important capability in realistic scheduling studies. Tasks may compete for mutexes, communication buffers, device drivers, or hardware interfaces, introducing blocking that is absent from simple independent-task models. Priority inheritance or priority ceiling protocols can bound some of this interference. The resulting blocking term must be incorporated into response-time calculations rather than ignored during schedulability assessment.

Release jitter and offsets can significantly change analysis results. Sensor interrupts, network arrivals, DMA completion, and upstream processing may cause tasks to become ready later or less regularly than ideal periodic models assume. Offsets can sometimes reduce interference by separating task releases, while jitter can increase worst-case response time. Analysis tools allow these temporal relationships to be represented more explicitly than simple utilization calculations.

Multicore scheduling requires additional information because tasks must also be assigned to processors. Under partitioned scheduling, analysis can be performed for each core after task allocation, but finding an effective allocation resembles a bin-packing problem. Under global scheduling, migration and cross-core interference complicate analysis. Shared cache, memory bandwidth, locks, and interrupts may introduce effects that theoretical processor-only models do not fully capture.

RTA-based analysis tools are therefore best understood as part of a larger timing-verification workflow rather than complete representations of hardware behavior. Mathematical analysis determines whether a defined model is schedulable, while measurement determines whether execution-time and interference assumptions are valid on the actual platform. Both are required because an incorrect WCET or blocking estimate can make a mathematically correct analysis irrelevant to the deployed system.

Operating-system measurements provide the empirical side of scheduling analysis. On real-time Linux systems, engineers can measure scheduling latency, wake-up latency, task execution, preemption, interrupt activity, and context switches using tracing and latency-analysis facilities. PREEMPT_RT configurations should be evaluated under realistic CPU, network, storage, and memory loads because an idle-system measurement does not represent worst operating conditions.

Tracing tools help connect observed timing failures with their causes. When a control task experiences unexpected latency, traces can reveal whether it was delayed by a higher-priority task, interrupt processing, kernel activity, lock contention, or another execution path. This evidence can then be compared with the assumptions used in RTA. Scheduling analysis becomes much stronger when theoretical interference terms correspond to events observed on the actual target platform.

The scheduling model should therefore evolve as implementation measurements become available. Early development may begin with estimated WCET values and assumed task periods. Prototype measurements then refine execution times, jitter, blocking, and interrupt costs. The updated parameters are returned to the analytical model and schedulability is evaluated again. This iterative model-measure-analyze process gradually closes the gap between theoretical architecture and real execution.

Robot scheduling analysis benefits especially from representing multi-rate execution. A 1 kHz actuator-control loop, 100--200 Hz state estimator, 10--30 Hz perception task, communication threads, planning functions, and low-rate diagnostics create different interference patterns. Tools can determine whether slower workloads disturb fast control and whether priority assignments remain valid when several periodic and event-driven activities coincide.

AI inference requires additional caution because its execution-time distribution may be much less deterministic than conventional control software. An average GPU inference time should not simply be inserted into a real-time task model as Cᵢ. Tail latency, preprocessing, memory transfers, synchronization, queueing, and accelerator contention must be measured. Conservative execution budgets or workload reservations may then be incorporated into scheduling analysis.

Scheduling tools are also valuable for design-space exploration. Engineers can compare RMS and deadline-oriented policies, change task priorities, move workloads between cores, reserve one processor for control, or reduce the rate of noncritical functions. Each alternative can be evaluated before modifying the deployed system. Analysis therefore becomes not only a verification mechanism but also a systematic method for selecting an architecture.

A useful workflow begins by constructing a task table containing function, period, deadline, WCET, priority, jitter, blocking, criticality, and processor assignment. Utilization tests provide an initial screening, followed by RTA or another schedulability method. Cheddar or similar scheduling environments can visualize execution and compare alternatives. The resulting architecture is then implemented and measured using operating-system tracing and latency tools.

Stress testing closes the verification loop. CPU-intensive background workloads, network bursts, storage activity, interrupts, memory pressure, perception processing, and AI inference should execute while critical tasks are monitored. Measured worst-case timing is compared with analytical assumptions and required deadlines. Any mismatch requires either updating the model, changing priorities, reducing interference, reallocating processors, or increasing timing margins.

The central purpose of scheduling analysis tools is therefore not to produce a single schedulability result, but to establish traceable evidence connecting requirements, mathematical models, implementation, and measured timing behavior. Cheddar supports architecture-level modeling and simulation, RTA evaluates worst-case task response, and operating-system measurements validate assumptions on real hardware. Used together, these techniques provide a disciplined path from scheduling theory to predictable real-time robot execution.

05.10 Platform Scheduling Strategy: AMR, Manipulator, UAV

A platform scheduling strategy must reflect the physical dynamics, sensing architecture, computational workload, and failure consequences of the robot being controlled. Autonomous Mobile Robots (AMRs), manipulators, and Unmanned Aerial Vehicles (UAVs) all require real-time execution, but their dominant timing constraints differ. A useful architecture therefore begins with common scheduling principles and then adapts priorities, rates, isolation, and overload behavior to each platform.

All three platforms benefit from a hierarchical multi-rate architecture. Fast low-level control operates close to actuators, intermediate-rate estimation converts sensor measurements into usable state, and slower perception and planning layers interpret the environment and generate future actions. Communication, diagnostics, logging, and user interfaces occupy additional timing domains. These layers should exchange timestamped state rather than requiring synchronous execution at one common frequency.

An AMR typically places wheel or drive control at the most deterministic level. Motor-current, velocity, steering, braking, and actuator-protection loops may execute from hundreds of hertz to approximately 1 kHz depending on the drivetrain. These functions should normally execute on an MCU, RTOS, or protected real-time CPU domain where scheduling jitter is tightly bounded and computationally variable perception cannot directly interrupt physical control.

AMR state estimation generally operates more slowly than actuator control but faster than high-level perception and planning. Wheel odometry, IMU processing, localization, and sensor fusion may execute from tens to hundreds of hertz. LiDAR processing, obstacle detection, terrain understanding, mapping, and path planning can operate at lower and more variable rates. The scheduler should preserve control and localization even when perception computation temporarily becomes expensive.

AMR communication spans several timing classes. CAN, CANopen, EtherCAT, or similar networks may carry actuator commands and feedback with relatively strict timing, while Ethernet, DDS, and ROS 2 transport perception, navigation, diagnostics, and application data. Fleet communication over Wi-Fi or cellular networks has much weaker timing guarantees. Local motion safety must therefore continue independently when external communication becomes delayed or unavailable.

Manipulator scheduling is dominated by precise coordinated motion. Joint current, torque, velocity, and position loops require low jitter because timing variation can directly affect trajectory accuracy and mechanical stability. Multiple joints must also remain temporally coordinated. A manipulator therefore benefits from tightly synchronized servo tasks, deterministic fieldbus communication, and carefully bounded execution paths between trajectory generation, interpolation, and actuator commands.

Trajectory interpolation forms an important intermediate scheduling layer for manipulators. A high-level planner may generate motion segments relatively slowly, while the servo system requires new joint references at a much higher deterministic rate. Interpolation converts these asynchronous planning outputs into continuous reference trajectories. This separation prevents variable planning or AI execution time from directly entering the joint-control loop and provides a buffer between reasoning and physical motion.

Manipulator perception requirements depend strongly on the application. Vision-guided grasping, pose estimation, force sensing, collision detection, and visual servoing introduce additional feedback loops with different rates. Force or tactile feedback may require relatively fast processing, whereas object detection can tolerate slower updates. Priority assignment should therefore follow the physical feedback path and required reaction time rather than simply classifying all perception as one scheduling category.

UAV scheduling places exceptionally strong emphasis on flight stability because missed deadlines can rapidly produce unsafe vehicle dynamics. Motor control, attitude stabilization, and inertial processing require highly deterministic execution, often on dedicated flight-control hardware. These functions must remain operational even when navigation, perception, communication, or AI workloads fail. The scheduling architecture should therefore create a strong boundary around the minimum functions required to maintain controlled flight.

UAV estimation commonly combines IMU, GNSS, barometer, magnetometer, visual odometry, and other sensors. IMU-related processing may execute at hundreds of hertz or higher, while global navigation and vision updates occur more slowly. The estimator must combine asynchronous measurements without forcing the fastest loop to wait for slower sensors. Timestamping and time synchronization are therefore fundamental components of UAV scheduling as well as sensor fusion.

Perception and AI inference on UAVs create additional constraints because onboard computing resources are limited by mass, power, and thermal capacity. Object detection, terrain analysis, visual navigation, and learned planning can consume substantial GPU or NPU resources. Scheduling must account not only for execution latency but also for sustained power and thermal behavior. AI workloads should degrade gracefully before they threaten flight-control computation or available energy.

Despite their differences, AMRs, manipulators, and UAVs share a common criticality hierarchy. Immediate safety and actuator protection require the strongest guarantees, followed by stabilization or motion control and essential state estimation. Perception and planning usually occupy lower deterministic levels, while fleet services, visualization, logging, and maintenance can be degraded or suspended. Actual priorities must still be derived from deadlines, dependencies, and response-time analysis rather than labels alone.

Multicore scheduling can reinforce this hierarchy. Dedicated cores may execute real-time control and estimation, while an SMP pool handles perception, planning, ROS 2, communication, and system services. CPU affinity and interrupt affinity reduce unwanted interference. GPU and NPU accelerators can process neural inference independently, although shared memory bandwidth, cache, I/O, and thermal resources remain potential sources of cross-domain interference.

AMP-style partitioning is particularly useful when deterministic control must be protected from complex software. An AMR can isolate drive control, a manipulator can reserve processors for servo execution, and a UAV can protect flight-control functions. SMP remains valuable for workloads whose computational demand changes dynamically. A hybrid architecture combining protected cores with a shared processing pool therefore provides a practical scheduling strategy across all three platforms.

Hypervisor-based isolation can extend this strategy on high-performance computers. A real-time guest can execute control or safety-related software while Linux guests run ROS 2, perception, planning, AI inference, and user applications. Dedicated cores, memory protection, interrupt assignment, and controlled communication paths improve isolation. However, shared GPU and memory resources must still be analyzed because virtualization alone does not guarantee temporal independence.

Communication scheduling must be integrated with processor scheduling. A control task completing on time is insufficient if its command waits unpredictably in a network queue. AMRs may depend on drive-network deadlines, manipulators on synchronized industrial Ethernet, and UAVs on tightly timed sensor and actuator interfaces. CPU priorities, network QoS, message queues, timestamps, and protocol timing should therefore be analyzed as one end-to-end execution chain.

Overload management should be explicitly platform dependent. An AMR can reduce perception rate or speed while preserving obstacle avoidance and braking. A manipulator can pause or reduce motion while retaining servo and safety functions. A UAV may reduce mission-level computation while preserving stabilization, navigation, and safe-flight functions. Graceful degradation must reflect what physical behavior remains safe when full computational capability is unavailable.

Watchdogs and health monitoring provide a scheduling-level defense against software failure. Critical tasks can report periodic execution health, while supervisors detect deadline misses, stalled communication, excessive inference latency, or unavailable sensors. Recovery actions may include restarting a process, switching algorithms, reducing workload, entering a safe state, stopping an AMR or manipulator, or initiating an appropriate UAV contingency mode.

Timing analysis should evaluate complete functional chains rather than isolated tasks. For an AMR, the relevant chain may extend from LiDAR acquisition through obstacle detection and trajectory modification to braking. For a manipulator, it may extend from force sensing through control computation to joint torque output. For a UAV, IMU acquisition, state estimation, stabilization, and motor command generation form a critical chain. End-to-end latency determines the actual physical response.

Scheduling parameters should be validated using both analytical methods and measurements. Utilization analysis and Response-Time Analysis (RTA) can verify modeled periodic workloads, while execution traces reveal real preemption, blocking, interrupt activity, and jitter. Stress testing should simultaneously activate perception, communication, storage, logging, and AI workloads while verifying that critical control chains continue satisfying their deadlines.

Platform validation must also reproduce representative physical operating conditions. AMRs should be tested during dense sensing, navigation changes, and communication bursts. Manipulators should be evaluated during coordinated multi-joint motion, perception updates, and force interaction. UAV testing should consider high-rate sensor activity, navigation processing, communication, sustained inference, and thermal loading. Scheduling margins should reflect these realistic worst-case combinations.

A practical platform strategy begins by classifying tasks according to physical function, period, deadline, WCET, criticality, dependencies, communication path, and degradation tolerance. Tasks are then mapped to MCUs, CPU cores, GPUs, NPUs, and communication interfaces. Priorities, affinities, resource reservations, and overload policies are defined before analytical verification and stress testing confirm the architecture.

The central principle is that scheduling architecture should follow physical responsibility. AMRs prioritize reliable mobility and obstacle response, manipulators prioritize synchronized precision and controlled interaction, and UAVs prioritize continuous flight stability and navigation. By combining multi-rate control, criticality-aware priorities, processor isolation, communication timing, and graceful degradation, each platform can exploit advanced perception and AI while preserving predictable physical behavior.

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go