Real-time scheduling, firmware lifecycle and dependable state
A deadline is part of correctness
A real-time requirement specifies when an observable result must occur, not simply that the processor is fast on average. Define period, release, deadline, execution time and allowed jitter for the actual task. A hard missed deadline can violate an essential requirement, while a soft deadline has a graded service impact; these labels need the real application’s consequences. Worst-case execution, blocking, interrupt work and interference from higher-priority activity can affect response time. An average benchmark alone is not a deadline guarantee.
Share state deliberately
An RTOS schedules tasks according to its policy and configuration. Priority can express urgency, but assigning one task the highest number is not a complete schedulability analysis. Mutual exclusion may introduce blocking and priority inversion; an appropriate inheritance or ceiling protocol can bound certain effects under its assumptions. A semaphore can signal available items or resources, while a mutex has ownership rules under the chosen API. Avoid blocking operations inside an interrupt handler unless the platform explicitly supports the operation and its timing consequences.
For a supplied conservative response bound, add 6 milliseconds of task execution,8 milliseconds of blocking and 9 milliseconds of higher-priority interference. The bound is 23 milliseconds, exceeding a 20 millisecond deadline. This arithmetic diagnoses a conflict in the supplied model; it does not prove which implementation change will eliminate it. Shortening a critical section, revising priorities or changing the design must be evaluated against all affected deadlines and safety requirements.
Build, deploy and recover with evidence
Firmware development still needs requirements, interface contracts, versioned code, repeatable builds, review and tests. Cross-compilation targets a different execution environment; a successful host build does not establish the target’s memory use, timing or peripheral behavior. Linker scripts, startup code and bootloader arrangements determine how the image is placed and started. Unit tests can exercise logic, while target integration and hardware-in-the-loop tests investigate device interactions under authorized conditions.
A watchdog can detect the absence of a required health action, but blindly restarting may repeat a dangerous failure or hide evidence. Define what health means, how failures are recorded and what safe or degraded behavior is appropriate. For updates, validate image origin and integrity, compatibility and authorized version transitions, and plan for interruption or insufficient power. An A/B-image arrangement can preserve an earlier bootable image when correctly implemented, but a successful signature does not prove that the new firmware is functionally safe. Keep recovery authority, key custody and state migration in the design. These are written engineering foundations, not a universal safety certification or a live plant-update procedure.