Knowing that a system needs a hazard analysis and an FMEA is only the starting point. The engineering task is to create documents that describe the actual system, expose its assumptions, and connect each safety claim to evidence.
For learned perception, this work must account for the model's limitations alongside sensors, compute, communications, and the machine's response.
This is a worked example of a proposed documentation approach. It does not describe a certified customer system, completed validation campaign, or market deployment. The architecture is illustrative and contains no client-specific design information.
Define the function before evaluating the model
Consider a stationary robotic machine with a learned perception function that detects people near a moving mechanism. The first question is what role that function plays: operational assistance, an input to a protective function, or part of the safety-related decision itself.
For this example, the team is evaluating whether perception could contribute to a protective stop. That is a question to assess, not an established safety capability.
The system definition should identify the sensor coverage, permitted operating conditions, model and compute versions, decision interface, stop-command path, machine response, and restart behavior. It should also state what lies outside the proposed operating envelope.
A confidence score or detection benchmark alone does not describe this complete function.
Build the analysis, rather than only identifying the gap
The initial artifact set would contain an application hazard analysis, a perception-chain FMEA, a safety concept, requirements, and a validation plan. A team's existing templates can provide the structure; AI-specific assumptions and failure mechanisms need explicit treatment within it.
Saphira offers hands-on support to create or adapt these artifacts. Tool adoption is optional, and work within an existing documentation environment can be scoped separately.
The following entries illustrate how an FMEA becomes actionable. Causes and protective measures are candidates for engineering review, not validated properties of this example.
| Candidate failure | Potential system effect | Analysis and documentation task | Evidence needed |
|---|---|---|---|
| Person is not detected | A protective-stop request may not occur when needed | Relate sensor coverage and model limitations to the application hazard; define protective measures | Representative scenario results and justified coverage limits |
| Output is stale or delayed | The machine acts on an outdated scene | Specify freshness monitoring and an end-to-end response-time budget | Timing tests under representative compute and communication loads |
| Sensor view is obscured | Detection capability is degraded | Define detectable degradation, operating limits, and the response to loss of valid input | Obstruction tests and evidence for the monitoring mechanism |
| Conditions exceed the evaluated envelope | Model behavior may be unreliable | Define restrictions, how they are enforced, and conditions for expanding the envelope | Boundary tests, monitoring evidence, and reviewed assumptions |
| Detection succeeds but stopping fails | Hazardous motion may continue | Analyze the downstream control and actuation chain separately | Interface fault tests and machine stopping measurements |
This table is the beginning of a review, not an exhaustive failure analysis.
Turn each hazard into a reviewable requirement
A useful trace chain is:
Hazard → protective measure → safety requirement → verification activity → result → review decision.
An illustrative requirement might state that the system must detect an invalid or stale perception output and initiate its defined protective response within an allocated time. The actual timeout, response, and acceptance limits must come from the application's analysis and architecture; this example supplies no universal values.
The supporting test record should identify the configuration, stimulus, expected response, measured result, and reviewer. An unexecuted test remains planned evidence. A failed or incomplete test remains an open item.
Separate model evaluation from the safety argument
A validation plan should examine relevant scene variations, occlusion, lighting, sensor degradation, latency, and behavior at the operating-envelope boundaries. Simulation can help explore scenarios; the team must justify what transfers to the physical installation and what requires physical testing.
If a probabilistic safety argument is proposed, its assumptions and evidence need separate review. This example does not derive a dangerous-failure rate from model accuracy, claim independence between perception channels, or assign a performance level or safety integrity level.
As background, ISO 13849-1:2023 addresses design and integration of safety-related control systems, while ISO/IEC TR 5469:2024 discusses AI in relation to functional safety. These are scope references, not a determination of which standards apply to this machine or a substitute for their full requirements.
Narrow scope deliberately
A bounded application is easier to describe and evaluate than an unrestricted one. The initial scope might specify a fixed installation, controlled access arrangements, and defined operating conditions. Any expansion should trigger review of the assumptions, hazards, requirements, and evidence affected by that change.
The deployment decision follows that review; it is not implied by completing the documents.
Define the handoff status
A proposed assessment handoff would include a versioned system definition, reviewed analysis drafts, a safety concept, a requirements-to-evidence register, a validation plan, and an open-issues register with owners. Each artifact should state whether it is drafted, reviewed, tested, or accepted by the relevant authority.
Saphira's existing Safe-Stop worked example documents a related workflow for connecting safety requirements to implementation and tests. It supports the traceability approach described here; it does not establish a completed learned-perception certification or a specific customer handoff milestone.
For this worked example, the status is documentation approach illustrated; implementation, validation, and assessment not performed.
To discuss a scoped assessment, contact Saphira with the system concept, existing documentation, and the artifacts your team needs help creating.