Functional Safety - Protect your environment, people, products and company brand from the start
March 14, 2017
Design for safety. Seems like a no-brainer, doesn't it? If that's the case, why do so many designers push functional safety down from the top of the p...
Design for safety. Seems like a no-brainer, doesn’t it? If that’s the case, why do so many designers push functional safety down from the top of the priority list? This happens in just about all application areas, but it’s a real head scratcher when you’re looking at things like industrial automation, including industrial robotics.
Before we move on, let’s define functional safety. The International Electrotechnical Commission (IEC), the organization responsible for the preparation and publication of International Standards for all electrical, electronic, and related technologies, defines functional safety as “that part of the overall safety of a system or piece of equipment that depends on its operating correctly in response to inputs — safely managing operator errors, hardware failures, and changes in environment.” In a nutshell, it’s about saving human lives.
Got it? So now let’s think about industrial robots, particularly those that are required to work in a setting with people – called collaborative robots, or cobots. In the factory of the future, humans and robots will collaborate to an increasing extent, and putting humans into the environment completely changes the equation as far as safety is concerned. That requires holding safety to a much higher standard, including what’s written in the IEC 61508 industrial functional safety specification (or the flight safety (DO-178C DAL A), transportation (EN 50126), and automotive (ISO 26262) standards, for that matter). IEC 6103 adds specific failure modes and characterizations for what to do if something goes wrong or if the robot detects a person within its parameters.
To properly implement functional safety in an industrial setting, you need to look closely at both the hardware and the safety. In our example, and one that’ll be demonstrated in the Wind River booth at Embedded World in Nuremberg, Germany, March 14-16 (Hall 4, Booth 158), you’ll see
Intel’s Xeon D class processor (the D-1529, to be exact) in action, driving an industrial robot, all managed by the VxWorks operating system (OS). Released last December, the Intel Xeon processor D-1529 was designed for industrial functional safety and has received TÜV IEC 61508 Safety Integrity Level (SIL) 2 certification. The demo at Embedded World shows a robotic arm entering safety mode when a system error is simulated. The Wind River platform running on Intel’s first Functional Safety solution – the Intel Xeon® D-1529 processor – brings up two virtual machines (one guest OS responsible for controlling the task of drawing on a Plexiglass window, and the other running a test application). An error is simulated and the system enters safety mode and halts drawing on the Plexiglass window. This demo is showcasing safety and virtualization in Intel and Wind River technologies.
Both the hardware and the software can be taken through to the same level of functional safety certification. Using this methodology, you can design a system that would contain all the characteristics you need in terms of separation of applications. This includes failure modes that constitute the application’s building blocks. Advanced time partitioning with space partitioning ensure reliable, interference-free consolidation of multiple applications of different criticality levels. With this separation, if the application in one domain fails or starts to write into areas that it shouldn’t, those regions are protected because of the partitioning. In a nutshell, VxWorks protects the rest of the system from errant applications.
VxWorks has some specific aspects that are designed for safety, for example, using real-time processes (RTPs) where sets of RTPs can be partitioned both in time and space from the rest of the applications and system services. RTP-based applications can be restricted to access only the system resources that are allocated to them, and system objects are protected so that they cannot be written over. Application programming interfaces (APIs) can be restricted as well by allowing applications that need to talk to certain protocols – like networking or file systems – to be restricted to only those APIs they have permission to access. Locking RTPs down prevents an errant application from using services it should not access and reduces risk in the overall system.
If you also desire a version of Wind River Linux within your application, you can do that, too. Because Linux can’t achieve the same certification level as VxWorks, to ensure the proper level of safety you’ll want to run Linux as a guest OS on top of Wind’s hypervisor technology. This way it will remain walled off from the rest of the system. Developers can support VxWorks alongside several instances of Linux, and using this configuration prevents unwarranted interactions that can potentially impact a system’s functional safety.
Figure 1 | Consolidation of heterogeneous operating systems and functionality with the Virtualization Profile for VxWorks.]
As you can see, the functional safety mechanisms are there for you to take advantage of both in hardware and in software. Which begs the question: When are you going to put functional safety back to the top of the priority list?
Wind River, an Intel Company
LinkedIn: www.linkedin.com/company/wind-river
