Top 10 Questions from the Webinar, ‘Functional Safety of Embedded Systems and Software Used in Machinery’

Functional safety is increasingly being relied upon to make correct and safe decisions in order to maintain safe operating conditions within the machinery space. These systems, along with the safe integration into solutions, require careful consideration by their manufacturers in the way they are developed and the ways they could fail in a dangerous manner.

To help you better understand functional safety and its general concepts, specifically as they apply to embedded systems and software used in machinery, here are the top 10 questions and answers from the webinar, ‘Functional Safety of Embedded Systems and Software Used in Machinery.’

1. In reference to the CE mark, can a functional safety assessment only be conducted on the full or whole product and not a subassembly?
   Functional safety may be assessed at several different levels, but once you go lower than the top product/system level, it may be necessary to make assumptions with respect to what risks and risk levels are appropriate. A safety programmable logic controller (PLC) is a good example.  Safety PLC manufacturers often do not know exactly in which environment or what functions the PLC will be responsible for making, and therefore can’t do a thorough hazard and risk assessment. In these cases, the required safety integrity level (SIL) or performance level (PL) may need to be assumed.
    
2. With regards to functional safety, what should we look for or specify to an original equipment manufacturer (OEM) when purchasing machines?
   System integrators should be conducting hazard and risk assessments to determine where it is necessary to design risk reduction into their system and what safety functions are needed from control systems. This includes the corresponding SIL or PL for those functions. Once those risks have been reduced to acceptable levels, you should know at that point, for example, that you may need a motor drive with an integrated safe torque off (STO) function of SIL 2, an E-Stop with SIL 3 function, etc. If you're working directly with a supplier, this information (the safety functions performed and their corresponding SILs or PLs) should be communicated to them clearly. If you're not working directly with a supplier but are in the market for this equipment, it should be clear when contemplating the purchase of a particular product whether or not it has any functions that have been assessed for functional safety, including the corresponding SIL or PL, either or both on the label of the product (it may have a special mark like UL's Functional Safety Mark) and/or in the product's instruction manual/safety manual.
    
3. As an end-user of a machine, what would be the key questions or tests you would use to evaluate the safety of a machine you just purchased?
   Even before you purchase a machine, the manufacturer of that machine should provide you with a safety manual that describes all the safety considerations, safety functions, PLs, SILs, and perhaps most importantly, the conditions and environment in which that machine can be used. Review this information before you purchase the machine and make sure everything that the machine provides is compatible with your overall integration or at least that it is feasible to take additional steps to accommodate those conditions.  Once you have decided to purchase a machine and integrate it within your end equipment, it is essential that you do something called a factory acceptance test (FAT) to verify the functions performed by the machine before you put it into commission.  Some guidance on how to do FAT in particular for safety applications is provided in the standard IEC 61511.
    
4. How do you perform a functional safety analysis when you build a new plant? Do you review the functional safety of each machine and/or each step of operation? How do you separate two machines that depend on each other?
   A comprehensive hazard and risk assessment can only be done when the entire equipment (including all systems, subsystems, components, etc.), its function and its environment are known. In these cases, functional safety is likely not going to be provided at the top level but by the subsystems, components, etc., that comprise the equipment. Each machine, each step of operation, etc., can then be assessed separately for those functions and the results and conditions of those assessments are documented carefully in a safety manual. It is up to the equipment/system integrator to review all of the subsystem/component safety manuals to help ensure that all potential conditions and concerns have been addressed at the top level.
    
5. Is there an assumption that detection is instantaneous?
   For most safety functions, it is not possible or feasible to assume that detection will be instantaneous. The reaction or response time of a safety function is certainly one critical parameter that is to be declared and communicated in a safety manual.
    
6. What is the source of the reliability data used?
   Various sources of reliability data are possible. Manufacturers of the components themselves will often have this information. There are certain standards that have reliability data published for certain components (ISO 13849-1 has an annex that provides this information). There are also applications and databases that are available that provide this information.
    
7. Are certain software languages either preferred or rejected as being appropriate for writing safety functions?
   Various functional safety standards do offer recommendations on what languages are preferred or not preferred; see IEC 61508, for example. Not only does the language have to be considered, but also if any language subsets are used. Going back to IEC 61508, it, for example, does not recommend just using the C language by itself but does highly recommend using the C language with a subset such as MISRA C.
    
8. I work for a large automobile company. We have been working on these issues for four years. Much of our legacy equipment (older equipment) does not meet these standards. We have struggled to address these issues to meet control reliable requirements which we see at Cat 3 PL d. Have you seen similar issues in the industry?
   Yes, this is not atypical. The European Union has generally been much farther ahead of the curve when it comes to awareness of functional safety compared to North America.  And this awareness trickles down from the top, all the way down to the component suppliers. If the component suppliers aren't told that they need to comply with functional safety requirements, then they don't do it. When they finally are, and in particular when they are now told they have to comply with Cat. 3 PL d (requiring full redundancy), their existing product likely doesn't comply with those requirements, so they must make new products and spend the additional capital to satisfy those requirements.
    
9. How does UL evaluate software for functional safety?
   Software evaluations focus more on the process and techniques used to develop the software rather than on the resulting code itself, which is mainly only walked through to establish traceability with the documentation. The first step in UL's process involves a review of the outputs, i.e., documents, of each of the software development processes, e.g., risk analysis, requirements, architecture, and design specifications, and module, integration, and validation test specifications/results. The second step involves meeting directly with the software developer and conducting an audit of the processes and work products to establish traceability. All in all, software evaluation typically only takes a few days of engineering time.
    
10. Does functional safety documentation have to be sent to UL in a certain format or language?
    Documentation (which are outputs from a manufacturer's development process) should be in the format and language that the manufacturer is most comfortable with. This usually, but not always, means that the documents should be in the primary language used by the manufacturer to avoid having to repeatedly translate, which could cause misunderstandings, and in turn, could lead to systematic faults.