Consider both expected and unexpected events when doing your risk assessment.
7. Failing to account for end effectors
The safety limits of collaborative robots only apply to the manipulator itself. However, the end effector you choose can hugely impact the safety of the robot. If you don’t account for it, there could be serious safety implications.
An extreme example would be a welding end effector. Obviously, you would not want anyone to be near the robot when the welder was active.
8. Failing to account for objects
It’s easy to forget that any objects held by the robot will also affect the safety. Jeff Burnstein of A3 talked about this in his keynote at our Robotiq User Conference this year. He used the example of a collaborative robot holding a knife. Even though the robot itself is safe, the knife certainly is not.
Safety issues can also arise when the robot holds long objects — which reach outside its workspace — and heavy objects — which could fall and cause damage.
9. Not involving the team
Safety is only possible when everyone who will be using the robot is involved. If a risk assessment is created by one person in a far-away office, it won’t be much use to anyone. The members of your team have a unique perspective on the task and should be included at all stages.
10. Using a risk assessment to justify a decision
A risk assessment should be an objective look at the activity from the perspective of safety. Unfortunately, sometimes people use them to justify decisions which have already been made.
For example, a person might have decided they don’t want to pay for expensive safety sensors so they use the risk assessment to show that one is not needed. The problem with using risk assessments in this way is that it stops you from thinking clearly and makes it likely that you will miss some unsafe behavior.
11. Not considering ALARA
Sometimes, people find one or two potential risks, implement some risk controls, and then just leave it at that. Because they have found a few risks, they don’t look for more.
ALARA stands for “As Low As Reasonably Achievable.” It’s a core concept of safety which means that you should reduce the risk of an activity as much as you can. This means that you should consider all of the risks of a robot application, not just one or two.
12. Using “reverse ALARA” arguments
This is related to the previous two mistakes. A “reverse ALARA” argument is one which uses risk assessment (or some other analysis, e.g. cost-benefit analysis) to show that safety measures should be reduced. Usually the justification is that the system still conforms to legal safety values.
The problem with this is that it directly goes against the principle of ALARA, hence the name.
13. Not linking hazards with controls
A good risk assessment identifies which parts of the robot task are most likely to cause hazards. However, this is not the end of the risk assessment. You also need to say how you will mitigate these hazards with controls.
Then — and this is a part people sometimes forget — you need to link each hazard to a control. If you don’t do this, it’s very difficult to tell if all your hazards have been addressed.
14. Not keeping risk assessment up to date
Risk assessments are only useful if they apply to the real robotic system as it is now. If your risk assessment was written 2 years ago, it’s likely that the robot has changed in that time and it is no longer up to date.
Collaborative robots change all the time. It’s easy to reprogram them, add extra end effectors, and move them to a completely new task. As a result, your risk assessment should be regularly updated.
15. Telling nobody about the proposed measures
Safety measures are useless if you don’t tell anyone about them. Too often, risk assessments are compiled, printed out, put into a drawer, and forgotten.
Make sure that your risk assessment is available to everyone and that everyone is aware of the safety measures. Read our eBook How to Perform a Risk Assessment for Collaborative Robots for more information.
For more investment strategies, visit ETF Trends.