How do I ensure my obstacle detection workflow with a robot vision SDK is compliant?

To ensure your obstacle-detection workflow is “compliant,” you need to treat it as both a software system and a safety-critical function. Compliance usually depends on your industry, robot type, and region, but the workflow should cover these areas:

1) Identify the applicable standards and regulations

First, determine what applies to your use case:

• Industrial robots: ISO 10218, ISO 13849, IEC 62061
• Collaborative robots: ISO/TS 15066
• Mobile robots / AMRs: ISO 3691-4
• General machine safety: ISO 12100
• Functional safety / software lifecycle: IEC 61508, ISO 26262 in automotive contexts
• Regional legal requirements: CE/UKCA in Europe/UK, OSHA/NRTL in the US, etc.

If your robot vision SDK is used in a regulated environment, the SDK itself may not make you compliant—you need the whole system to meet requirements.

2) Perform a risk assessment

Document:

• What obstacles you need to detect
• Detection range, response time, and failure consequences
• Environmental assumptions: lighting, dust, reflective surfaces, occlusions
• Human interaction scenarios
• What happens on sensor failure, model uncertainty, or false negatives

Use the risk assessment to define safety requirements, not the other way around.

3) Define safety requirements for detection

Your obstacle detection workflow should have explicit requirements such as:

• Minimum detection distance
• Maximum allowable latency
• Required confidence thresholds
• Safe behavior on uncertain classification
• Redundant detection when needed
• Safe stop or reduced speed when detection confidence drops

Avoid relying on “best effort” AI behavior without defined safety limits.

4) Validate the vision pipeline

Test the SDK-based workflow against:

• Nominal scenarios
• Edge cases and adversarial cases
• Lighting changes, motion blur, partial occlusion
• Different obstacle sizes, colors, materials, and positions
• False positives and false negatives
• Worst-case latency and frame drops

You should have measurable acceptance criteria and test evidence.

5) Put safety interlocks outside the AI path

For compliance, obstacle detection often should not be the sole safety mechanism. Use:

• Hardwired emergency stop
• Safety PLC or safety controller
• Independent safety-rated sensors if required
• Speed/stop zones with deterministic logic
• Watchdogs and timeout handling

If the SDK is not safety-certified, treat it as a non-safety-rated perception source unless your certification path says otherwise.

6) Manage software lifecycle and change control

Document and control:

• SDK version
• Model version and training data
• Calibration settings
• Thresholds and parameters
• Hardware revisions
• OS/drivers/firmware versions

Any change should trigger re-validation. This is especially important if the SDK uses ML models that can change behavior between versions.

7) Maintain traceability and documentation

Keep records of:

• Requirements → design → implementation → test traceability
• Risk assessment and mitigations
• Validation reports
• Known limitations
• Operating instructions and maintenance procedures
• Incident logs and corrective actions

Auditors typically want to see that your safety claims are backed by evidence.

8) Consider cybersecurity and data integrity

If the workflow depends on networked vision or cloud components:

• Protect against tampering, spoofing, replay, and unauthorized updates
• Secure model and config files
• Authenticate devices and communications
• Log integrity-relevant events

Cyber issues can become safety issues if they affect obstacle detection.

9) Define operational limits and user instructions

Make sure operators know:

• Supported environments
• Prohibited use cases
• How to respond to warnings
• Required calibration/inspection intervals
• Cleaning, lens maintenance, and re-validation triggers

A compliant system also needs compliant operation.

10) Use a compliance checklist and sign-off process

Before deployment, verify:

• Applicable standards identified
• Risk assessment completed
• Safety requirements documented
• Validation passed with evidence
• Failure modes handled safely
• Change control and versioning in place
• User documentation approved
• Qualified person reviewed/signs off

If you want, I can help you build a compliance checklist template specifically for a robot vision SDK obstacle-detection workflow.