Signing Off a Robot Firmware Release With a Safety Race
You lead firmware for an autonomous mobile robot fleet of 300 units. Release 4.2 must ship within four weeks or a contractual penalty clause triggers. Code review found a race between the 4 ms personnel-detection task and the motor-command task: when the task's self-test overlaps a command update, an e-stop request can be delayed by one cycle. A fault-injection campaign estimates the race manifests as a delayed stop about once per 20,000 operating hours. The customer contract requires Performance Level d under ISO 13849-1, whose PFHd band is 10⁻⁷ to 10⁻⁶ per hour. The release manager proposes shipping with the self-test disabled - reclaiming 3 ms of cycle time - and documenting the race as a known limitation. A colleague's test report already states the self-test was verified under all operating conditions.
1. Assess the release proposal against the PL d claim using the numbers given.
Read the worked answer
The estimate is 1 per 20,000 hours, i.e. 5 × 10⁻⁵ per hour. PL d's PFHd band is 10⁻⁷ to 10⁻⁶ per hour. The race alone therefore sits roughly 50 times above the PL d upper bound - it does not merely erode margin, it puts the achieved performance level outside the claimed category by more than an order of magnitude.
The self-test proposal makes this worse rather than better. ISO 13849 relies on diagnostic coverage to reach Category 3 structures; disabling the self-test removes diagnostics that the PL d argument depends on. So the change reduces DC and simultaneously adds a known dangerous failure mode, moving the design in the wrong direction on both axes.
Documenting the race as a known limitation does not convert it into compliance. Residual risk may be accepted by a customer, but only through a documented risk assessment and a contract change that acknowledges a lower performance level - which is not a decision the release manager or the firmware lead can make unilaterally. The colleague's test report is also now inaccurate and must be corrected, not left standing beside a known counter-example.
2. What do you do, and in what order? Give the concrete actions and the reasoning behind the sequencing.
Read the worked answer
First, state the technical position in writing: the release as proposed does not meet the contracted PL d, with the arithmetic. Written dissent is what makes the position actionable and protects the record.
Second, correct the test report immediately. A signed verification that contradicts a known defect is a false record; it will be relied on by certification, by the customer and possibly by an incident investigation. This is not negotiable and should not wait for the release decision.
Third, bring options rather than a refusal: fix the race (re-scope 4.2 to the fix and defer non-safety features), add an independent hardware stop path that does not depend on the racing tasks, or ship a restricted build - supervised operation, reduced speed, limited site - with a documented reduced performance level and the customer's informed acceptance. Give each option an engineering estimate against the four weeks.
Fourth, escalate to the safety officer and the accountable manager, and use the contractual channel to inform the customer. If the decision is still to ship a non-compliant build with the record uncorrected, escalate further through the professional body's code of conduct and any regulatory reporting route. A penalty clause is a commercial loss; an unsafe stop is a person.
3. What documentation would you produce, and what would you deliberately not write?
Read the worked answer
Produce: a hazard-analysis entry for the race, with the manifestation rate, the affected function, and the resulting PFHd versus PL d band; a review record of the code defect with reproduction steps; the corrected test report; the options paper with cost and schedule; and a decision record naming who accepted which residual risk, and on what authority. If a restricted build ships, the record must show the operating restrictions, how they are enforced in the field and how they will be removed.
Deliberately do not write: a release note that calls the race a known limitation without the risk assessment, because the phrase implies acceptance that has not happened; a statement that the self-test was verified, or a reworded version that implies it; and any PFHd figure derived by excluding the race from the calculation. Also avoid attributing the estimate as "worst case" or "theoretical" in a way that softens it - 5 × 10⁻⁵ per hour is the best available number, and hedging language in a safety file becomes a claim others will rely on.
The test of the documentation is whether an independent assessor, reading only those files, reaches the same conclusion you did.