Infusion pump firmware: utilization bound versus response-time analysis

The 71% number is the rate-monotonic utilization bound check: for n tasks the sufficient bound is n(2^(1/n) − 1), which for n = 5 is 5 × (2^0.2 − 1) ≈ 0.743. Being under that bound proves schedulability only if the underlying assumptions hold: independent tasks, no blocking, no release jitter, deadlines equal to periods, and execution times that are true worst cases across the operating envelope.

Here at least two assumptions fail. Blocking is explicitly nonzero (interrupt masking plus whatever the flash driver holds), and the 40 µs and 1,800 µs figures were measured on a bench, not at 60 °C with flash writes and clock tolerance in play. The correct check is per-task response-time analysis:

R_i = C_i + B_i + Σ over higher-priority tasks j of ceil(R_i / T_j) × C_j

iterated to a fixed point and compared with D_i. For the 1 ms motor task, a single preemption by the logging task is larger than the motor task's entire period, so a shared mutex or a long non-preemptible flash section can blow the deadline outright. Utilization is a screening test; it is not a schedulability argument when blocking exists.

The misses correlate exactly with completion of a flash write in the lowest-priority task, and the victim is the highest-priority task. That is the signature of unbounded priority inversion: either the flash driver masks interrupts for the duration of a page erase/write, or the logging path holds a mutex or bus lock (SPI/flash) that the motor path also needs. A 1 ms task cannot tolerate a blocking section of the order of a flash page operation.

Fixes, roughly in order of preference:

1. Remove the shared resource from the critical path. Give the logger its own flash partition and a double-buffered queue so the interrupt handler only enqueues a record and returns.
2. If sharing is unavoidable, use a priority-inheritance or priority-ceiling mutex and measure the longest critical section with a logic analyser on target hardware at temperature extremes.
3. Move erase and program operations into a DMA-driven state machine with a bounded, documented worst case, and account for that bound as B_i in the response-time analysis.
4. Confirm the priority assignment is actually rate-monotonic; that assignment is optimal only when relative deadlines equal periods.

A watchdog converts a missed deadline into a reset. It does not restore dose accuracy, and a reset mid-infusion is itself a hazardous event that belongs in the hazard analysis.

The nine days and the trial date are schedule inputs, not engineering evidence. The defensible position is a written gate with named criteria, not a yes or no in a meeting.

What the gate should require: the inversion mechanism identified from a trace rather than inferred; a measured worst-case blocking time on production-intent hardware at the temperature extremes; a re-run of the response-time analysis with that blocking term; and a stress run long enough to give confidence about a failure rate that currently looks like three events in 40 hours, which is far too frequent for a device infusing continuously.

Because the device is Class II and the hazard is a timing hazard, the finding belongs in the risk file, not only in a bug tracker. Notify the quality and regulatory functions in writing with the analysis attached. If management elects to proceed, the release should be limited to bench or laboratory use with the miss instrumented and logged, and the decision should be recorded with the residual risk stated. Do not sign a verification report asserting the timing requirement is met. If you are overruled, escalate in writing and keep the record; that record is what shows the organisation knew.