Realtime Control Design

Realtime Control Design

Produce a task/resource ownership table and an evidence-backed timing budget. The fastest clock or highest CPU utilization is not the objective.

Workflow

1. Read the shared contract. Identify the framework/RTOS, core count, tick/timebase, actuator safe state and actual response requirement. Mark unknown deadlines; do not invent universal values.
2. Give actuator outputs one owner. Define how sensors, network callbacks, services and interrupts pass bounded data or requests to it.
3. For each activity record period/event, deadline, worst observed execution, priority/affinity, stack/storage location, blocking operations and failure response. Define data age separately from task execution duration.
4. Keep I2C waits, logging, sockets, flash/NVS writes and unbounded allocation out of a time-sensitive tick unless their blocking time is measured and budgeted. A queue's size and overflow policy must be deliberate. Latest-value snapshots suit state; events requiring lossless order need a different path.
5. Read timing and overload. Keep CPU headroom for radio, interrupts, idle/watchdogs and contention. Do not put hot control data/stacks in PSRAM simply because it is available.
6. Define stale-sensor, deadline-miss and lost-command behavior before tuning. Use the shared bench lease contract for remote actuation. OTA must coordinate with the actuator owner.
7. Instrument start intervals, durations, queue drops, sensor timestamps and state changes under representative load. A sampled dashboard may miss short transitions; choose a bounded event trace when exact action timing matters.

Ownership and limits

This skill owns the control architecture and budget. freertos-patterns owns task/queue/mutex implementation. non-blocking-patterns owns simple scheduling. wireless-telemetry owns transport/measurement interpretation. ota-deployment-guardian owns update and rollback gates. Do not create another scheduler or promise hard real-time performance from a compile result.

The output must identify design values versus measured values, representative workload, missing measurements and acceptance criteria. Keep the stages in the shared contract visible. See source lessons for the build-to-hardware boundary.