Mapping industrial robot safety requirements to SWT3 witness procedures. Collaborative operation modes, safety-rated control systems, cybersecurity, stopping functions, and conformity evidence for AI-enabled robots under the EU Machinery Regulation.
Who this is for: Robot OEMs, system integrators, cobot manufacturers, safety engineers, Notified Body auditors (TUV, DEKRA, Bureau Veritas), and AI platform providers deploying models on physical robotic hardware.
ISO 10218:2025 replaces the 2011 edition. The revised standard adds cybersecurity requirements, expands collaborative operation safety, and aligns with the EU Machinery Regulation (2023/1230) which takes effect January 20, 2027. As a harmonized standard, compliance with ISO 10218 creates a legal presumption of conformity with the Regulation's essential health and safety requirements. Robots with AI-based safety functions require third-party Notified Body assessment under Annex I Part A.
A cobot's vision model receives an over-the-air update that changes its human-detection algorithm. The separation distance calculation shifts by 3 centimeters. Under ISO 10218, that is a safety function change. Under the EU Machinery Regulation, the entity that pushed the update just became the legal manufacturer of a machine it did not build -- with full conformity assessment obligations, including a new Notified Body EU Type-Examination.
The technical file proves the robot was safe on the day the Notified Body tested it. But robots run for years after certification. The question every assessor, insurer, and market surveillance authority asks is: is it still safe now? A static document cannot answer that. A continuous witness record can. That is the gap ISO 10218:2025 creates and that SWT3 fills -- not replacing the mechanical safety case, but providing the ongoing runtime evidence that the robot continues to operate within its certified safety envelope.
ISO 10218 is the foundational safety standard for industrial robots. Part 1 covers the robot itself (manipulator, controller, teach pendant). Part 2 covers the robot system -- the robot integrated into a production cell with tooling, workpieces, conveyors, and safeguarding devices. Together, they define the safety requirements that every industrial robot manufacturer and system integrator must meet.
The 2025 revision matters for AI teams because three things changed simultaneously:
For manufacturers designing AI-enabled robots for the EU market, ISO 10218:2025 is not optional. It is the primary harmonized standard that Notified Bodies will use to assess conformity with the Machinery Regulation's essential health and safety requirements for robot products. Beyond Europe, the standard has global reach: Japan's JIS B 8433 is a direct adoption of ISO 10218, and China's GB 11291 and GB/T 36530 series for industrial and collaborative robots converge toward the same requirements.
| Area | ISO 10218:2011 | ISO 10218:2025 |
|---|---|---|
| Cybersecurity | Not addressed | Explicit cybersecurity requirements for robot controllers and safety-related control systems |
| Collaborative operation | Basic framework, 4 modes defined | Expanded validation requirements, refined force/pressure limits, detailed monitoring obligations |
| Software safety | Referenced IEC 62443 generally | Specific SCS requirements for software implementing safety functions, integrity verification |
| Risk assessment | Referenced ISO 12100 | Robot-specific risk assessment guidance, task-based hazard identification for collaborative applications |
| Stopping functions | Category 0/1/2 stops defined | Refined stop categories with explicit monitoring and verification requirements |
| Machinery Regulation | Harmonized under Directive 2006/42/EC | Harmonized under Regulation (EU) 2023/1230 (directly binding, no national transposition) |
| Autonomous mobile robots | Not covered (separate ISO 3691-4) | Coordination with ISO 3691-4 for AGVs/AMRs referenced, system integration clauses applicable |
| Clause | Requirement | AI Impact |
|---|---|---|
| Part 1, Cl. 5.3 | Risk assessment specific to robot applications | AI-controlled robots require risk assessment covering learned behaviors, model updates, and edge cases not present in deterministic controllers |
| Part 1, Cl. 5.4 | Safety-related control system (SCS) design and validation | AI models implementing safety functions must meet Performance Level (PL) requirements per ISO 13849 or SIL per IEC 61508. Software integrity verification required |
| Part 1, Cl. 5.5 | Robot stopping functions (Category 0, 1, 2) | AI systems must not prevent or delay protective stops. Category 0 (immediate power removal) must override any AI control loop |
| Part 1, Cl. 5.6 | Speed and axis limiting | AI-driven speed optimization must respect safety-rated speed limits. Dynamic speed adjustment requires monitoring and verified enforcement |
| Part 1, Cl. 5.10 | Collaborative operation requirements (4 modes) | AI cobots must implement at least one collaborative mode with validated safety parameters. Adaptive behavior adds complexity to all four modes |
| Part 1, Cl. 5.12 | Cybersecurity for robot safety systems (NEW) | Robot controllers and safety PLCs must resist cyberattack. References IEC 62443 for industrial automation security zones and conduits. AI model integrity, communication channel security, and update authentication required |
| Part 2, Cl. 5 | Robot system design and integration safety | System integrator must validate the complete cell including AI components. Integration testing must cover AI failure modes |
| Part 2, Cl. 6 | Safeguarding: protective devices and perimeters | AI-controlled safety zones, virtual fencing, and adaptive workspace boundaries must meet the same requirements as physical safeguards |
| Part 2, Cl. 7 | Collaborative robot system design requirements | Complete cobot cell design including workspace layout, task-specific risk assessment, and operator training documentation |
Performance Level matters. ISO 13849-1 defines five Performance Levels (PL a through PL e) for safety-related control systems. Robot safety functions typically require PL d or PL e. An AI model that implements a safety function -- collision avoidance, speed limiting, workspace restriction -- must be validated to the required Performance Level. This is a quantitative requirement: mean time to dangerous failure (MTTFd), diagnostic coverage (DC), and common cause failure (CCF) must all be demonstrated.
What SWT3 contributes and what it does not replace: SWT3 provides the monitoring and diagnostic evidence layer -- continuous proof that safety functions are executing, that transitions occur as designed, and that drift is detected. This evidence contributes to demonstrating diagnostic coverage (DC) within the PL calculation. SWT3 does not replace the FMEA, reliability block diagrams, hardware fault tolerance analysis, or the safety validation testing that PL assessment requires. Those remain the responsibility of the safety engineer using the methods defined in ISO 13849-2.
Twenty SWT3 procedures produce evidence relevant to ISO 10218:2025 compliance. Together, they cover safety control systems, stopping functions, collaborative operation, cybersecurity, hardware attestation, and post-deployment monitoring.
| SWT3 Procedure | Evidence Produced | ISO 10218 Clause |
|---|---|---|
AI-EMRG.1 |
Emergency override lifecycle: trigger, authorization, fallback state, recovery | Part 1, Cl. 5.5 (Category 0/1 stop) |
AI-SAFE.1 |
Safe state transition: mode changes, speed reduction, workspace restriction | Part 1, Cl. 5.4 (SCS), Cl. 5.5 (Cat 2 stop), Cl. 5.6 (speed limits) |
AI-TOOL.1 |
Tool call witnessing: every command to physical actuators | Part 1, Cl. 5.4 (SCS integrity), Part 2, Cl. 5 (integration) |
AI-TOOL.2 |
Tool access control: authorization for safety zone entry, actuator access | Part 2, Cl. 6 (safeguarding), Cl. 5.10 (collaborative access) |
AI-HITL.1 |
Human-in-the-loop approval for high-risk operations | Part 1, Cl. 5.10 (hand guiding, teach pendant), Part 2, Cl. 7 (cobot design) |
AI-HW.1 |
Hardware runtime attestation: sensor validation, actuator health | Part 1, Cl. 5.4 (SCS hardware), Part 2, Cl. 6 (protective devices) |
AI-MDL.1 |
Model registration: safety controller firmware inventory | Part 1, Cl. 5.4 (SCS documentation) |
AI-MDL.2 |
Model version governance: firmware update tracking, lineage | Part 1, Cl. 5.12 (update security), EU Mach Reg Art. 18 (substantial modification) |
AI-DRIFT.1 |
Statistical drift monitoring: performance degradation detection | Part 1, Cl. 5.4 (SCS monitoring), Cl. 5.10 (collaborative parameter drift) |
AI-BASE.1 |
Baseline integrity: cryptographic fingerprint of certified configuration | Part 1, Cl. 5.4 (validated state), Cl. 5.12 (integrity verification) |
AI-CHAIN.1 |
Multi-device orchestration: coordinated multi-robot operations | Part 2, Cl. 5 (multi-robot cell integration) |
AI-INCIDENT.1 |
Incident classification and response attestation | Part 1, Cl. 5.3 (risk assessment feedback), post-market obligations |
AI-CYBER.1 |
Cybersecurity posture attestation | Part 1, Cl. 5.12 (cybersecurity, NEW in 2025) |
AI-ROBUST.1 |
Robustness testing: protective stop validation, fault injection | Part 1, Cl. 5.4 (SCS validation), Cl. 5.5 (stop function testing) |
AI-PERF.1 |
Performance metrics: speed, force, position accuracy measurement | Part 1, Cl. 5.6 (speed limits), Cl. 5.10 (force/pressure limits) |
AI-ENV.1 |
Environment attestation: workspace zone configuration, boundaries | Part 2, Cl. 6 (safeguarding zones), Cl. 7 (collaborative workspace layout) |
AI-TRANS.1 |
Transparency: operator information, safety instructions | Part 1, Cl. 7 (information for use), Part 2, Cl. 8 (user information) |
AI-ENG.3 |
Safety-critical review gate: risk assessment sign-off, NB approval | Part 1, Cl. 5.3 (risk assessment), EU Mach Reg Art. 5 (conformity) |
HBOM-INV.1 |
Hardware component inventory: robot cell bill of materials | Part 2, Cl. 5 (system documentation), technical file |
HBOM-LIFE.1 |
Component lifecycle: maintenance records, degradation tracking | Part 1, Cl. 5.4 (SCS maintenance), post-deployment monitoring |
In the ISO 10218 context, AI-SAFE.1 captures every transition between robot operating modes: automatic operation to reduced-speed mode, collaborative mode activation, workspace boundary enforcement, and Category 2 monitored stops where the robot holds position under power. Each transition anchor records the trigger condition, the target state, actions suspended, and whether recovery is available.
Standard mapping: Clause 5.4 requires the safety-related control system to maintain the robot in a safe state under all foreseeable conditions. Clause 5.6 requires speed and axis limits to be enforced by the SCS. AI-SAFE.1 proves these transitions occur in real time, not just in test documentation.
For Performance Level validation, verify that AI-SAFE.1 anchors cover every operating mode transition documented in the risk assessment. A robot with four defined operating modes should show transition evidence for all permitted mode pairs. Missing transitions indicate untested safety paths.
ISO 10218 Part 1, Clause 5.5 defines three stop categories. Category 0 removes power immediately. Category 1 decelerates to stop, then removes power. Category 2 maintains power for position holding. AI-EMRG.1 records the full emergency override lifecycle: what triggered the stop (operator, sensor, AI decision), which category was executed, what fallback state the robot entered, and whether recovery was initiated.
Standard mapping: Clause 5.5 requires that stop functions override all other robot functions and that their activation cannot create additional hazards. AI-EMRG.1 proves the stop function executed as designed and that no AI control loop interfered with the protective stop sequence.
Verify that AI-EMRG.1 anchors exist for Category 0 stops from every emergency stop device (buttons, safety mats, light curtains). Check timestamps to confirm stop execution time meets the requirements for the specific hazard. An AI system that delays a Category 0 stop -- even by milliseconds -- is a conformity failure.
Collaborative robots must operate within defined speed and force limits. ISO 10218 Part 1, Clause 5.10 specifies maximum permissible forces and pressures for human-robot contact. AI-PERF.1 witnesses measured performance values -- TCP speed, joint torques, contact forces, position repeatability -- and compares them against the safety-rated limits configured in the SCS.
Standard mapping: Clause 5.6 requires speed limits to be enforced by the safety-rated control system. Clause 5.10 requires force and pressure limits for collaborative operation. AI-PERF.1 provides continuous measurement evidence that the robot operates within its certified safety envelope, not just that the limits are configured.
For power and force limiting cobots, compare AI-PERF.1 measured forces against the biomechanical limits in ISO/TS 15066 Table A.2. The standard defines maximum permissible force and pressure by body region. AI-PERF.1 anchors should demonstrate that measured contact forces remain below these thresholds across all tested scenarios.
The 2025 edition of ISO 10218 adds cybersecurity requirements that did not exist in the 2011 version. A compromised robot controller can disable safety functions, alter speed limits, or override emergency stops. AI-CYBER.1 attests that cybersecurity measures are active: firmware integrity, communication channel authentication, access control to safety parameters, and intrusion detection status.
Standard mapping: Clause 5.12 requires robot safety systems to resist cybersecurity threats and explicitly references IEC 62443 for industrial automation security. IEC 62443 organizes the industrial network into security zones and conduits -- the robot controller, safety PLC, HMI, and field sensors each belong to a zone with defined security level requirements. AI-CYBER.1 records the cybersecurity assessment against IEC 62443 (or another applicable framework), providing the evidence that Clause 5.12's requirements are being met at the zone level.
Clause 5.12 is new in 2025 -- many existing robot installations were certified under the 2011 edition without cybersecurity evidence. For new certifications, verify AI-CYBER.1 coverage of each IEC 62443 zone in the robot cell: the controller zone, the safety network zone, and any external communication conduits. For re-certification of existing installations, this is the most likely gap.
Robot system integration under Part 2 requires defining the collaborative workspace, restricted zones, and safeguarded spaces. AI-ENV.1 attests the configured workspace boundaries, safety zone dimensions, and environmental parameters (lighting, floor conditions, access paths) that affect the safety case. For adaptive robots that modify their workspace boundaries based on sensor input, AI-ENV.1 captures each boundary change.
Standard mapping: Part 2, Clause 6 requires safeguarding of the robot system including perimeter devices, interlocked gates, and presence-sensing systems. Clause 7 requires collaborative workspace design documentation. AI-ENV.1 provides verifiable evidence of the as-configured workspace -- not just the as-designed layout.
Compare AI-ENV.1 workspace zone records against the layout drawings in the technical file. Any discrepancy between the documented workspace and the configured workspace is a conformity gap. For robots with adaptive safety zones, verify that every zone change is witnessed and that the minimum safe distance is never violated.
Part 2 system integration requires documenting every component in the robot cell: manipulator, controller, end effector, sensors, safety devices, conveyors, and fixtures. HBOM-INV.1 records the complete hardware bill of materials with a manifest hash, enabling automated detection of any hardware change from the certified configuration.
Standard mapping: Part 2, Clause 5 requires system integrators to document the complete robot system configuration. The technical file under the Machinery Regulation must include component specifications. HBOM-INV.1 provides a verifiable hardware inventory that can be checked at any point in the system's lifecycle against the certified baseline.
For multi-robot cells, each robot should have its own HBOM-INV.1 attestation, and the cell-level inventory should reference all individual robot inventories. A component swap (sensor replacement, end effector change) that creates a delta from the certified baseline may require re-assessment if the changed component performs a safety function.
Collaborative operation is the most complex area of ISO 10218 compliance for AI-enabled robots. The standard defines four collaborative operation modes, each with distinct safety requirements and evidence obligations.
The robot stops before a human enters the collaborative workspace and does not resume until the human exits. AI systems must not override or delay the monitored stop. SWT3 evidence: AI-EMRG.1 (stop execution), AI-HW.1 (presence sensor validation), AI-ENV.1 (workspace zone boundaries).
A human physically guides the robot by hand using an enabling device. The robot must operate at reduced speed and the human must maintain control at all times. AI systems that assist hand guiding (force amplification, path optimization) must ensure the human can always override. SWT3 evidence: AI-HITL.1 (human control attestation), AI-PERF.1 (speed verification), AI-SAFE.1 (reduced-speed mode).
The robot maintains a minimum protective separation distance from the human. If the distance decreases below the threshold, the robot reduces speed or stops. This is the most AI-intensive mode -- AI vision systems often calculate the separation distance in real time. SWT3 evidence: AI-PERF.1 (measured separation distance), AI-SAFE.1 (speed reduction transitions), AI-HW.1 (sensor validation for distance measurement), AI-DRIFT.1 (sensor accuracy drift).
The robot is designed so that contact forces and pressures remain below biomechanical thresholds defined in ISO/TS 15066. The robot may contact the human during normal operation. AI systems that dynamically adjust force limits based on task context must ensure limits are never exceeded. SWT3 evidence: AI-PERF.1 (measured contact forces vs. ISO/TS 15066 limits), AI-ROBUST.1 (force limiter validation testing), AI-TRANS.1 (operator information on contact risks).
Adaptive cobots face compound requirements. An AI cobot that switches between collaborative modes during operation (e.g., speed and separation monitoring while approaching, power and force limiting during contact) must meet the safety requirements of each mode at the moment of transition. AI-SAFE.1 anchors at each mode transition create the evidence chain showing the robot met the requirements of the target mode before entering it.
Part 2 of ISO 10218 addresses the system integrator -- the entity that combines the robot with tooling, workpieces, and safeguarding into a complete production cell. For AI-enabled systems, the system integrator bears additional responsibilities:
AI-ENG.3 witnesses the risk assessment sign-off and links it to the specific cell configuration documented in HBOM-INV.1.AI-HW.1 attests to sensor and protective device health. AI-ENV.1 records the safeguarding zone configuration.AI-CHAIN.1 witnesses cross-device operations with shared cycle IDs, providing forensic reconstruction capability for multi-robot incidents.AI-TRANS.1 attests that operator information is current and accessible.The system integrator is typically a different entity from the robot manufacturer. Under the EU Machinery Regulation, the system integrator is the legal manufacturer of the complete machinery (the cell), while the robot manufacturer is the manufacturer of a partly completed machine. Both must provide declarations of conformity, and the system integrator's conformity assessment must address the integrated AI behavior -- not just the mechanical installation.
ISO 10218 is a harmonized standard under the EU Machinery Regulation. This creates a specific legal mechanism:
SWT3 witness anchors serve as the runtime evidence layer within this framework. The static technical file (design documentation, risk assessment, test protocols) proves the robot was designed and validated to ISO 10218. The witness anchors prove the robot continues to operate within its certified safety envelope after deployment. Together, they create a complete conformity evidence package for initial assessment and ongoing market surveillance.
For the parent regulation crosswalk including substantial modification detection and conformity assessment pathways, see the EU Machinery Regulation (2023/1230) Crosswalk.
SWT3 procedures mapped against seven key areas of ISO 10218:2025.
| Procedure | Cl. 5.3 (Risk Assess.) |
Cl. 5.4 (SCS) |
Cl. 5.5 (Stopping) |
Cl. 5.10 (Collab.) |
Cl. 5.12 (Cyber) |
Part 2 Cl. 5-6 (Integration) |
Part 2 Cl. 7 (Cobot Design) |
|---|---|---|---|---|---|---|---|
AI-EMRG.1 |
✓ | ✓ | ✓ | ✓ | ✓ | ||
AI-SAFE.1 |
✓ | ✓ | ✓ | ✓ | ✓ | ||
AI-TOOL.1 |
✓ | ✓ | |||||
AI-TOOL.2 |
✓ | ✓ | ✓ | ||||
AI-HITL.1 |
✓ | ✓ | |||||
AI-HW.1 |
✓ | ✓ | ✓ | ||||
AI-MDL.1 |
✓ | ||||||
AI-MDL.2 |
✓ | ✓ | |||||
AI-DRIFT.1 |
✓ | ✓ | |||||
AI-BASE.1 |
✓ | ✓ | |||||
AI-CHAIN.1 |
✓ | ||||||
AI-INCIDENT.1 |
✓ | ||||||
AI-CYBER.1 |
✓ | ✓ | |||||
AI-ROBUST.1 |
✓ | ✓ | |||||
AI-PERF.1 |
✓ | ✓ | |||||
AI-ENV.1 |
✓ | ✓ | |||||
AI-TRANS.1 |
✓ | ||||||
AI-ENG.3 |
✓ | ✓ | |||||
HBOM-INV.1 |
✓ | ||||||
HBOM-LIFE.1 |
✓ |
Coverage summary: 20 SWT3 procedures across 7 standard areas. Clause 5.4 (safety-related control systems) has the deepest coverage with 9 procedures, reflecting the SCS's central role in AI-enabled robot safety. Collaborative operation (Clause 5.10) is covered by 7 procedures across all four collaborative modes.
from swt3_ai import Witness
witness = Witness(
endpoint="https://your-instance.example.com/api/v1/witness",
api_key="axm_your_key",
agent_id="cobot-cell-07",
jurisdiction="DE",
legal_basis="EU-2023-1230"
)
# Witness safe state attestation (AI-SAFE.1)
# Records whether a stop/interrupt mechanism exists and was confirmed
witness.witness_safe_state(
mechanism_exists=True,
safe_state_confirmed=True,
mechanism_type="collaborative_stop"
)
# Witness cybersecurity assessment (AI-CYBER.1)
# Records controls assessed vs. compliant against IEC 62443
witness.witness_cybersecurity(
controls_assessed=24,
controls_compliant=22,
framework="IEC-62443",
framework_version="4.2",
findings_count=2,
critical_findings=0
)
# Witness performance metrics (AI-PERF.1)
# Records safety validation test results
witness.witness_performance(
metrics_evaluated=12,
metrics_passing=12,
benchmark_type="safety",
model_under_test="cobot-vision-v3.1"
)
# Witness hardware inventory (AI-HW.1)
# Auto-detects accelerator hardware at startup
witness.witness_hardware()
witness.flush()import { Witness } from '@tenova/swt3-ai';
const witness = new Witness({
endpoint: 'https://your-instance.example.com/api/v1/witness',
apiKey: 'axm_your_key',
agentId: 'welding-cell-03',
jurisdiction: 'DE',
legalBasis: 'EU-2023-1230'
});
// Witness safe state attestation (AI-SAFE.1)
witness.witnessSafeState({
mechanismExists: true,
safeStateConfirmed: true,
mechanismType: 'emergency_stop'
});
// Witness cybersecurity assessment (AI-CYBER.1)
witness.witnessCybersecurity({
controlsAssessed: 24,
controlsCompliant: 22,
framework: 'IEC-62443',
frameworkVersion: '4.2',
criticalFindings: 0
});
// Witness performance metrics (AI-PERF.1)
witness.witnessPerformance({
metricsEvaluated: 12,
metricsPassing: 12,
benchmarkType: 'safety',
modelUnderTest: 'cobot-vision-v3.1'
});
await witness.flush();