WCGW Safety Suite — Seven Safety Engineering Methods

Safety investigation: Network-controlled robot arm

Investigation status: Provisional model, pending engineering evidence.

System boundary: Network client → command receiver → motion controller → motor drives → robot joints → physical workspace.

1. Walk the Chain — Physical hazard reasoning

A network disconnection is not itself a physical hazard. The relevant question is whether motion continues after the controlling client can no longer influence it.

Constructed trace

PROCESS: Command reception
→ STRUCTURE: Motion controller
→ PROPERTY: Command timeout behavior
→ PERFORMANCE: Motion persistence
→ CONSTRAINT: Motion must terminate under defined loss-of-control conditions
→ HAZARD: Unintended continued movement
→ HARM: Collision or crushing injury

The PSPP classification distinguishes the system's structures, processes, properties, and performance. OPB grounding is used where applicable to identify physical quantities and phenomena, such as angular velocity, kinetic energy, and stopping distance.

Finding: Communication loss must be evaluated in terms of the physical motion it permits, not merely whether the network connection closes.

2. STPA — Unsafe control actions

The control structure contains a remote operator, network channel, motion controller, motor drives, and robot arm.

Potential unsafe control actions include

• A motion command remains effective after its controlling session expires.
• A stop command is not provided when continued motion becomes unsafe.
• A stop command is provided but arrives too late.
• Motion resumes after reconnection without renewed authorization.

Finding: A successful network reconnection could itself create an unsafe transition if stale commands are replayed.

3. Shared Substrate — Common-cause investigation

The proposed safeguards include a communication watchdog, motion controller, and stopping mechanism.

Investigating their dependencies reveals a candidate common cause: the watchdog and command execution logic may share the same processor or scheduling resources.

If that processor stalls, both motion supervision and communication-loss detection could be impaired.

Finding: Two logically distinct safeguards are not necessarily independent.

Evidence needed: Controller architecture, watchdog implementation, power distribution, and fault-response behavior.

4. Change Walk — Modification impact analysis

Consider a proposed software change that increases the communication timeout to tolerate network jitter.

The affected trace extends beyond the timeout configuration:

Timeout parameter
→ Detection latency
→ Additional travel distance
→ Hazard exposure
→ Safety constraint
→ Verification tests
→ Assurance claim

A longer timeout may improve operational availability while increasing the distance traveled before stopping.

Finding: A networking configuration change may require renewed physical safety verification.

Re-verification candidates: Disconnection detection, worst-case stopping distance, recovery behavior, and related safety claims.

5. Circular Argument — Assurance integrity

Proposed assurance claim

"The robot stops safely when remote control is lost."

Supporting evidence currently consists of a software requirement specifying that the robot shall stop after communication loss.

That requirement is not evidence that the behavior has been implemented or verified.

Finding: The assurance argument is incomplete. A requirement cannot establish its own satisfaction.

Evidence needed: Implementation traceability, fault-injection results, measured stopping performance, and test-environment applicability.

6. Standard Shift — Standards applicability

The investigation is compared against the applicable functional-safety framework and intended operating context.

Potential considerations include ISO 10218 for industrial robots, ISO/TS 15066 for collaborative robot applications, and ISO 13849 or IEC 62061 for relevant safety-related control functions.

Finding: The applicable requirements depend on the machine configuration, intended use, and risk assessment. A generic communication timeout cannot be assumed to satisfy a safety-function requirement.

Open question: Is communication-loss handling part of a safety-rated function, or merely ordinary operational control?

7. Assessor Dry Run — Evidence challenge

An independent assessor reviews the resulting model.

Challenge A: What establishes the maximum stopping distance?

Status: Open. No measured deceleration or stopping-time evidence.

Challenge B: Can the watchdog fail together with the motion controller?

Status: Open. Independence has not been demonstrated.

Challenge C: What happens when communication returns?

Status: Open. Stale-command rejection has not been verified.

Challenge D: Which safety claims are supported by actual tests?

Status: Open. Requirements exist, but test evidence has not been supplied.

Consolidated investigation trail

Next engineering actions

1. Obtain the motion-controller and watchdog architecture.
2. Establish the relevant safe-state and stopping-performance constraints.
3. Measure disconnection response and stopping distance under representative conditions.
4. Test controller stalls and reconnection with pending commands.
5. Attach test results to the corresponding requirements and assurance claims.
6. Repeat the assessment against the updated evidence baseline.

Conclusion

The central investigation finding is not simply that network disconnection can be dangerous.

It is that a communication timeout, shared controller dependency, physical stopping behavior, and assurance claim may form one connected safety problem.

The investigation provides a structured trail from the initiating condition through physical consequences, control decisions, dependencies, proposed constraints, verification obligations, and assessment questions.

No physical tests were performed in this illustrative example. The resulting hypotheses and proposed evidence obligations require human review. When executed through WCGW's MCP tools, the corresponding concepts and relationships can be maintained and queried in the engineering graph.