What Robot Developers Need To Know About Functional Safety
FORT talks with safety expert Erik Reynolds of Reynolds & Moore to get his take on what developers need to know about functional safety for autonomous systems as a part of our new Q&A series, Safety Check.
Functional safety is crucial to the machine development process. As machine systems in nearly every industry become more autonomous and more complex, safety planning can pose major challenges. With rapidly changing technology and new and emerging safety standards, many developers have questions about how to make their robot systems functionally safe and compliant.
Erik Reynolds discusses key concepts robotics developers need to understand when it comes to functional safety in this fascinating Q&A.
Q: Let’s get started in the obvious place—tell us about Reynolds & Moore and your role there.
Erik Reynolds: Reynolds & Moore is about safety in automation, but it is ultimately about people.
I founded the company in 2016 as a way to stay connected to the new functional safety service offering I helped build at Intertek. I was working full-time for Atmos Energy in pipeline risk and eventually led their regulatory and compliance organization. In 2018, a personal tragedy shook me in a new direction. A close friend of my daughter was killed in a natural gas explosion at their home. I knew the commitment Atmos had to safety, and yet this tragedy still occurred, so at that point, I started to view safety as my calling. By 2020, it became obvious that building R&M into a mature functional safety engineering organization was the best way for me to do that. We are now a team of over 20 and growing every day. We have been fortunate that several Fortune 15 companies share the same vision for safety that we do, so we are in long-term partnerships with a couple of them. I really feel that this small team coupled with strategic partners can pull the levers to really impact people’s lives at work and at home.
My role at R&M is that of Founder and Principal Engineer. That means that I take full accountability for both the business success and the technical authenticity of our work product. I have found the best way to do both is to focus on developing people. One of my favorite questions to ask new folks is “What do you want to do after you leave R&M?” It usually takes them aback for a second, but then we get a chance to talk about what is really important to them. I try to make their experience at the company one of helping them get there.
Q: Why is functional safety important for developers?
ER: Engineering ethics are real and ancient.
Going all the way back to the Code of Hammurabi, every engineer has a duty to take responsibility for the consequences of their work – both good and bad. In the old days of simple systems, this meant adhering to established codes and best practices.
Today’s systems are more complex, and the old ways of prescriptive standards cannot carry the load.
This is where functional safety comes in – it is applied systems engineering to automated safety. It allows the engineer to sleep at night because they have done the work to be aware of the risks as well as reduce them to As Low As Reasonably Practicable. Anything less would be malpractice.
Q: What are some of the safety challenges you see in the world of supply chain robotics?
ER: Self-certification is rarely compliant, even if well-intentioned.
Supply chains are made up of many different and integrated systems. Eventually, the owner-operator takes responsibility for the safety of the workplace. We are seeing a positive trend in increased end-users specifying the need for functional safety assessment and certification down their supply chain. Unfortunately, the other side of this coin is that many components, assembly, and even system manufacturers have an incomplete understanding of exactly what this means. I have personally witnessed self-declarations by component vendors who were completely unfamiliar with basic functional safety standards. Sometimes this is naïve ignorance, thinking that functional safety is covered in their product standard. Other times, it is sadly willful deception.
Compliance is a moving target, for now.
Standards, by definition, lag behind innovation. Automation is developing at such a pace that new approaches often don’t fit neatly into any particular standard. Routes for compliance for advanced sensing technologies and machine learning-based logic are not yet established. This puts the onus back on the manufacturer to define the route themselves – and to convince certification bodies that it is appropriate. This is an exciting opportunity as well because the first few through the door will set the “best practices” for the rest of the market.
Q: Are there things about functional safety that robot developers don’t know, but should know?
ER: Functional Safety is part of the product development process - not an activity at the end.
Traditional compliance is demonstrated after design and development are complete by a construction review and prescribed tests. This ensures that electrical, mechanical, and thermal hazards are handled through standard means. For automated safety systems, the hazards depend on the use case, and therefore the performance of the equipment matters to address the hazards.
Automated safety must be developed in parallel with the rest of the design. It must be documented in a way that is auditable and verifiable at the end. This is what causes schedule slips and cost overruns in the last mile of the development cycle.
Functional Safety all starts with a Hazard and Risk Assessment - before you start designing.
Engineers like to get to the nuts and bolts of designing. That’s why they got into engineering. However, if you design a safety system before knowing the risks in the intended use case, then at best you have only given up some of your design freedom. You have down-selected before you looked at all the options. Then, at worst you have missed important hazards that you will have to go back and re-address – or even worse that will go out into people’s lives without you knowing it.
Functional Safety tests should try to break the safety system – not show it works once.
We build trust through knowing weaknesses, not just strengths. A robust test program is built to find the edges of the trade space where an automated system will not perform as intended. In the case of safety, this means it will let someone experience a hazard in real life. A good safety case accepts that every safety system has performance limits and that the intended use of a particular one is far from the edge of the envelope.
SIL1 + SIL1 +SIL1 ≠ SIL3
Simple systems are additive. Complex systems are emergent. Building automated systems in an additive manner misses out on these emergent properties. At best, it means the system is over-designed. At worst, it means the system is less safe because we think we have addressed the hazards. However, in reality, we haven’t.
Q: What steps would you recommend for an Original Equipment Manufacturer that wants to ensure functional safety for their system?
ER: First, read IEC 61508. This is the foundational standard that most others are built from. It describes the systems engineering approach to automated safety that allows you to employ useful things like software, diagnostics, redundant architectures, and the like that previously were not strictly allowed.
Second, decide what level of competence your team needs in functional safety. One of the bedrock assumptions of the approach is that all personnel are qualified for their roles in the system safety lifecycle. This applies to everyone – management, engineers, developers, testers, technicians, and assessors.
Third, take stock of where you need help. Do your people need training and experience to become competent? Or perhaps they are, but you need them to work on other things? Ask these questions to help work out a functional safety management approach that fits with existing processes.
Q: What are the benefits of working with outside safety experts?
ER: How many safety systems does a typical engineer work on? On a two-year development cycle, in a 10-year career, a senior engineer would have worked on five.
Our team consults on dozens a year – and in diverse industries. When you engage with safety experts you’re getting wisdom gained working within different frameworks that can quickly help you innovate on your safety problem. Safety experts, like R&M, work under strict Non-Disclosure Agreements, so your Intellectual Property is protected. We also have great relationships with Testing and Certification bodies that set the tone for compliance. We know the players, processes, and paperwork needed to get to compliance. A safety expert like myself and my colleagues at R&M help clients know not only what compliance looks like today, but also what it’s likely to look like tomorrow.
Q: Looking ahead, what do you think the future looks like for robots and functional safety? New standards, regulations, predictions?
ER: My hope is that within a decade functional safety will be fully mainstream – just like electrical or mechanical engineering. That will mean we are designing safer systems for everyday people. We have a steep hill to climb to get there though. There is a huge gap between the number of functional safety engineers out there and how many will be needed.
Collaborative robotics, both at work and at home, will be a new area that will need some innovative thinking.
Also, there are a lot of cross-domain applications that we don’t have settled solutions on yet – like robots that work in the warehouse and then drive on streets to get to other work locations or even interact with the public. That is one of the things that is most exciting about functional safety, it is always developing as industries continue to find new ways to help people.
For more information about Erik Reynolds and Reynolds & Moore, click the link to their website here. If you enjoyed this interview, check out more content from the FORT team in the related articles below.
