The 10 Key Steps for Functional Safety
Follow these steps for validation of subsystems and components to reduce implementation-level complexity in your control systems.
As we consider machine safety risk reduction and validation, here are the 10 key steps to follow in a functional safety process:
1. Identify hazard
2. Assess risk
3. Reduce risk
4. Establish safety requirements
5. Implement functional safety (FS)
6. Verify functional safety
7. Validate functional safety
8. Document functional safety
9. Prove compliance
10. Get certification
Hazard identification and risk assessment as defined in ISO 12100 consists of four principal steps: determine the limits of the machinery, identify the hazard, estimate the risk, and evaluate the risk. The ultimate question to be answered: Has the risk been adequately reduced?
The three methods for risk reduction, from most to least preferred: inherently safe design measures, safeguarding (i.e., implementation of complementary protective measures), and information for use. ISO 13849-1 and IEC 62061 reference the first two of these methods.
The risk assessment is a living document that must be revisited and modified as system specifications and usage change. This strategy will ensure that the safety plan is kept over the life of the machine.
The Risk Reduction Process
Inherently safe design measures are the first and most important step in the risk reduction process. This is because protective measures inherent to the characteristics of the machine are likely to remain effective, whereas experience has shown that well-designed safeguarding may fail or be violated, and information for use may not be followed.
Inherently safe design measures are achieved by avoiding hazards or reducing risks through the choice of design features for the machine itself and/or interaction between the exposed persons and the machine. Safety of the machinery is not only dependent on the reliability of the control system, but also on the reliability of all parts of the machine. The continued operation of the safety function is essential for the safe use of the machine. This can be achieved by some of the following measures:
- Use of reliable components
- Redundancy of components or systems
- Limiting exposure to the hazard through mechanization or automation of loading, feeding, unloading, and removal operations
- Limiting exposure to the hazard through the location of setting and maintenance points outside of dangerous zones
Design guards and protective devices to be suitable for the intended use, taking into account mechanical and other hazards involved. Make them compatible with the working environment of the machine and designed so that they cannot be easily defeated. They should provide the minimum possible interference with activities through operation and other phases of the machine life.
Validation and Verification
Validation is a root requirement of ISO 12100. Section 184.108.40.206 (Safety functions implemented by programmable electronic control system) states, “The programmable electronic control system should be installed and validated to ensure that the specified performance for each safety function has been achieved.” Validation comprises testing and analysis to show that all parts interact correctly to perform the safety function and that unintended functions do not occur.
Clause 8 of ISO 13849-1 also addresses validation: “The design of the safety related parts of a control system shall be validated. The validation shall demonstrate that the combination of safety related parts of a control system providing each safety function meets all relevant requirements of this part of ISO 13849.”
ISO 13849-2 is dedicated to validation. The scope of ISO 13849-2 states the procedures and conditions to be followed for validation by analysis and testing of the safety functions provided, the category achieved, and the PL achieved, of the safety related parts of the control system in compliance with ISO 13849-1 using the design rationale provided by the designer.
So what is validation vis-à-vis verification? Validation ultimately asks that the following questions be answered:
- Are we building the right system?
- Does the safety system actually reduce the risks identified in the risk assessment?
- When reviewing the risk assessment can we validate that the safety system actually causes risk reduction?
- Is it at the specified target determined in the risk assessment?
- Does the system meet all targets?
Verification is the evaluation of whether or not a system complies with a regulation, requirement, specification, or imposed condition. Verification asks that these questions be answered:
- Are we building the system right?
- Is the system well built?
From an ISO 13849 perspective, overall validation includes:
- Validation of safety requirements specification for safety functions
- Validation of safety functions
- Validation of performance levels and categories
- Validation of category, MTTFd, DCavg, CCF, systematic capability, and finally PL
- Validation of safety related software
- Validation of environmental requirements
- Validation of maintenance requirements
- Validation of information for use
Validation principles, according to ISO 13849-2, include the following:
- Design team and validation team need to be independent.
- Design team cannot objectively validate their own design and validation team cannot objectively validate if involved in the design.
- Level of separation is proportional to the safety performance.
- Validation should start as early as possible in the design process.
Use of the V-model development process is integral in functional safety projects. The V-model represents a software development process, also applicable to hardware development, which may be considered an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards to form the typical V shape. The V-model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness and level of abstraction, respectively.
The left-hand side of the V is product definition, design and development, requirements, architecture, hardware design, and software design. The right-hand side is project test and integration, verification and validation (i.e., test and functional safety assessment), system and acceptance, integration, software integration, and software module. Throughout each phase of the project, the system goes through verification and validation. Everything in the V model rests on the base of functional safety management to ensure that the safety plan is kept.
Reducing Complexity with Validated Products
The major challenge of achieving and validating machinery safety control systems is complexity. The multiplicity of sensor, logic, and actuator subsystems that typically make up a functional safety system can make the overall development process daunting. For example, consider a functional safety project for interlocking the retractable cover of a CNC lathe. There are three solutions a manufacturer might take:
- Solution One: Development on element and subsystem level (i.e., do it yourself). By using the DIY method, the manufacturer will have to go through the entire V-model process, which can be challenging for anyone without experience in using the approach.
- Solution Two: Implementation by integration of functional safety certified subsystems, parameterization. This approach makes it simpler for a manufacturer to comply with requirements. By using pre-certified FS subsystems and components, the manufacturer’s efforts are greatly reduced in complying with the V-model. They still have to go through machine hazard ID and risk assessment, SRCS requirements specification, and user documentation; however, hardware and software requirements specification (and testing) is not required care of use of pre-certified subsystems and components. Functional safety management is still required of the manufacturer to support the entire process.
- Solution Three: Implementation by integration of functional safety subsystems, LVL programming (e.g., function blocks, ladder logic). Sometimes the extra complexity of programming is needed, which makes the V-model slightly more complex by bringing back the need for an application software architecture description and software state machine diagram; but, it still is far simpler than the DIY approach.
The fact is that safety systems are becoming increasingly complex. Systems are being created with reduced material cost (i.e., software instead of hardware); they are smarter, safer, and connected. Additionally, interacting systems are driving cybersecurity as a safety issue. So complexity looms as a major issue in achieving and validating safety systems. There are three principal ways to deal with this challenge:
- With thorough and systematic methods and tools in hazard identification and risk assessment
- With structured processes and documentation for system development (i.e., use of the V-Model)
- With use of validated (FS certified, approved, listed) subsystems and components to reduce implementation-level complexity.
For similar information on machine safety from safety experts, order your “Machine Safety Made Easy DVD” by clicking here.
Have an Inquiry for Siemens about this article? Click Here >>