A robot completing a demonstration is encouraging. It does not establish how the robot behaves under all the conditions relevant to its application. Safety engineering needs a more specific question: what requirement is being demonstrated, and what evidence shows that it has been met?
Verification asks whether the design meets its specified requirements. Validation asks whether the resulting function is suitable for its intended use. Both require clearly defined conditions and acceptance criteria. A test without a criterion can record behaviour, but it cannot establish whether that behaviour is acceptable.
Start with a concrete requirement
Suppose a protective measure is intended to detect entry into a robot cell and initiate a defined response. The requirement should identify the condition to detect, the required response, relevant timing limits, and the conditions for restarting.
Writing only that the robot must stop is incomplete. Engineers need to define which motion must stop, how stopping is achieved, what happens to held loads or gravity-driven axes, and which faults must be addressed. The details depend on the risk assessment and the actual machinery.
Record the starting conditions
A stopping test at low speed with no load may not represent the demanding conditions for the application. Useful records include the robot configuration, tool, payload, speed, direction, operating mode, and relevant environmental conditions.
Measurements need known methods and uncertainty. The time recorded by one device may not line up with the time recorded by another. Without checking that relationship, the apparent delay can be misleading.
Introduce faults with a defined purpose
Fault injection means deliberately introducing a controlled fault to examine a specified response. Examples might include interrupting a communication link, freezing a sensor value in a simulation, or simulating a brake fault.
The selected method must be suitable for the question and controlled by the test procedure. A simulated sensor failure can test software logic, but it may not reproduce every electrical or physical consequence of an actual sensor failure. The result must be described within that limitation.
Each test should identify the fault, when it was introduced, what was detected, which response occurred, and what final state was reached. A final position alone can miss hazardous movement that occurred earlier.
Measure the complete response
Detection is only the beginning. A sensor collects information, processing identifies the condition, a decision is made, communication carries that decision, and the machinery responds physically. Delays at every stage can affect the result.
For illustration, a robot moving at 1 metre per second travels 100 millimetres in 100 milliseconds if speed remains constant. That calculation describes travel during the stated interval. It is not a complete stopping distance and does not include later braking, falling, or sliding.
Filtering and persistence also consume time. Waiting for several consecutive measurements may reduce unnecessary trips, but it delays the response to a genuine condition. That delay belongs in the analysis.
Use simulation for the questions it can answer
A simulation can explore many combinations of speed, posture, payload, and failure timing. It can make a complex interaction easier to inspect and help identify conditions that need physical testing.
Its usefulness depends on the model. If the model assumes that a brake always holds, it cannot establish the consequences of a failed brake without changing that assumption. If the model does not include payload release, it cannot bound the travel of a released payload.
Model validation requires comparison with relevant physical behaviour. Agreement in one operating condition does not automatically establish agreement everywhere.
Compare against existing methods
A new monitoring concept should be tested against the methods already in use. Under the same conditions, does it detect an important change sooner? Does it detect something that existing monitoring misses? Does it generate more unnecessary responses?
Good research includes the possibility that the new concept adds little or no benefit. A useful conclusion can be that an existing function already addresses the proposed problem. Tests should help make that decision rather than assume the answer.
Leave a record another engineer can follow
A defensible report connects each hazard to a requirement, a design measure, an acceptance criterion, and a test result. It records deficiencies, corrective actions, remaining assumptions, and the limits of the conclusions.
For a client, the key question is whether the evidence supports the claimed behaviour in the intended application. A video is helpful. A repeatable test with traceable conditions and reviewed results is much more useful for an engineering decision.
Continue reading: How Compel can support your project