FENNECA Safety Requirement Has to Say More Than Stop
A requirement such as the system shall stop when the gate opens leaves the safe state, timing, modes, and fault behavior unanswered. Here is what the SRS must settle.
)
The system shall stop when the safety gate is opened.
Open the gate, watch the machine stop, and the test passes. The requirement still leaves most of the safety function undefined.
It still leaves most of the engineering undecided. How fast must the machine stop? What is the safe state for a suspended load? Does the rule apply in setup and recovery modes? What happens if the gate switch fails shorted, or if power disappears halfway through the stop?
An assessor raising those questions is not inventing new work. The original sentence never constrained the design enough to show the intended risk reduction.
The vertical-axis counterexample
A safety requirement exists because a hazard analysis found a risk that needed another control. Its link to that risk is part of the engineering, not an index added for the assessor.
Take a vertical axis behind the gate. “Remove power” may sound safer than “stop,” but an uncontrolled drop can create the hazard. The safe state might require a controlled stop followed by holding torque or a mechanical restraint. Without the hazard and operating condition, a generic stop requirement can point the design in the wrong direction.
Feature lists do not become safety requirements merely by moving into a document called SRS. Ask which risk reduction is credited to the behavior. No answer means the integrity target and verification basis are floating.
The argument to have before design freeze
The SRS needs functional behavior and an integrity requirement. The first says what the safety function must do. The second says how much confidence the risk assessment requires from it.
For the gate example, the team should be able to find the initiating condition, the safe state, and the maximum response time in the controlled requirement. Applicable modes belong there too. Startup, automatic operation, teach, maintenance, and recovery can put the same machine in very different states.
Fault behavior cannot be implied. Loss of power, a detected internal fault, or a failed input may need a defined response that is different from the normal protective stop.
These details make arguments appear earlier, which is useful. A controls engineer and a mechanical engineer may disagree about the achievable stop time, the effect of a suspended load, or the state of the brake after power loss. Better to discover that while the safety distance and mechanical design can still change than during validation.
A test cannot infer missing words
Repeat the original test. The gate opens and the machine stops. If the requirement includes a 250 millisecond response time, the test now needs an instrumented measurement. If the safe state includes holding a vertical load, the test needs to observe that condition. If maintenance mode is in scope, somebody has to run the case there.
At Fennec, we would send the one-line gate requirement back before approving a test plan. Specific wording shows the verification work the team actually owes.
The same rule applies to reliability analysis. A SIL or Performance Level calculation belongs to a defined safety function with a known architecture and demand behavior. It cannot rescue a requirement that never states what success means.
Put the SRS between the HARA and the architecture
Write the SRS after the hazard analysis identifies the safety functions and before the implementation hardens. Earlier than that, it becomes a wish list. After design freeze, it tends to describe choices already made.
Changes should travel through the same chain. If a hazard changes, the team can see which requirement needs review. If the requirement changes, its design and verification evidence become candidates for impact analysis.
In ASAP, the SRS is a controlled view of requirements derived from the hazard analysis and tied to verification. The project does not need a second requirements document rebuilt for the assessor.
The methodology was developed over five years inside Amazon Robotics and supports a large autonomous mobile robot fleet in continuous operation.
If “shall stop” is doing most of the work in your SRS, Fennec can help test what the requirements actually commit the design to do.
Frequently asked questions
What is a safety requirements specification?
It states what each safety function must do and the integrity it must achieve. It connects the hazard analysis to design and verification.
What belongs in a safety functional requirement?
Identify the hazard, initiating condition, safe state, response time, applicable operating modes, and behavior during loss of power or detected fault. The exact content depends on the function.
How is a safety requirement different from a product requirement?
A safety requirement exists to reduce a specific risk and traces to that hazard analysis. A product behavior with no safety rationale is not made into a safety requirement by placing it in the SRS.
Why do assessors focus on the SRS?
Design and verification evidence are judged against it. If the requirement is vague or disconnected from the hazard, downstream evidence cannot establish the intended risk reduction.
What is a safe state?
The condition reached when a safety function acts, stated precisely enough to verify. Removing power is not universally safe; the correct state depends on the hazard and machine.
)