This is Part I of a two-part article that defines the differences between conventional programmable logic controllers (PLCs) and safety PLCs. Part II, "Reliable Safety PLC Software," places additional focus on the techniques that ensure the reliability of safety PLC embedded software
There is a strong trend toward the use of programmable electronics in safety instrumented systems. Some users, however, still avoid these software-based systems. They cite the unpredictability of software and case histories of software failure.
They may very well have an argument when thinking of regular programmable logic controllers (PLCs). However, a special class of PLC called a safety PLC does meet the need for safety and high availability in critical automation.
Safety PLCs are special-purpose machines used to provide critical control and safety applications for automation users. These controllers are normally an integral part of safety instrumented systems (SIS), which are used to detect potentially dangerous situations. If such a situation occurs, the SIS is programmed to automatically take action to bring the process or machine to a safe state.
There's a serious question to be answered here, though. What is the real difference between a safety PLC and the well-known conventional PLC that has been successfully used for years? Why shouldn't a conventional PLC without special design features be used in critical control and safety applications?
Rigid Requirements
Most consider a PLC to be a safety PLC when it meets a set of rigorous international standards that cover design, design methods, and testing of software and hardware. Third-party experts enforce the rigor when the products go through the certification process.
Safety PLCs are certified per international standards, primarily IEC 61508¹. A key part of the analysis covers the diagnostic ability of the PLC. A detailed quantitative analysis² ³ of hardware failures is usually performed. That analysis determines the "diagnostic coverage factor," a number between 0-100%. Levels of 90%+ are expected, depending on target safety integrity level and amount of safety redundancy.
Figure 1: V-Model Standards Reassure Reliability
Safety PLCs are also evaluated to ensure electrical safety, user manual integrity, and, in most certifications, even software integrity. The software integrity is another of the key differences between conventional PLC/DCS equipment and safety PLCs.
Remember, a safety PLC is normally designed to accomplish two important objectives: do not fail (redundancy that works well), but if that cannot be avoided, fail only in a predictable, safe way.
Systematic Safety
A number of special design considerations are taken into account. A safety PLC will emphasize internal diagnostics — a combination of hardware and software that allows the machine to detect improper operation within itself.
A true safety PLC will have software that uses a number of special techniques to ensure software reliability. It will have redundancy to maintain operation even when parts fail, and it will have extra security on any reading and writing via a digital communications port.
A safety PLC also differs from a conventional PLC in that the safety PLC is typically certified to meet the functional safety requirements of international standards. Thorough and systematic methods must be applied to the design and testing of safety PLCs. The experts at TV in Germany and Factory Mutual Research Corp. in the U.S. provide third-party independent validation and verification of safety PLC design and testing procedures.
Special electronic circuitry, careful diagnostic software analysis, and full fault injection testing of the complete design assure that SIL 3 safety PLCs are capable of detecting more than 99% of potentially dangerous internal component failures. A Failure Modes, Effects and Diagnostic Analysis (FMEDA) is conducted on the design, indicating how each component in the system fails and how the system detects the failure. Third-party engineers personally perform fault testing as part of their certification process.
Simplify, Corrupt, and Verify
Tough international standards for software apply to safety PLCs. These standards demand special techniques to avoid complexity. Extensive analysis and testing carefully examine operating systems for task interaction.
This testing includes real-time interaction, such as multitasking (when used) and interrupts. Special diagnostics called "program flow control" and "data verification" are required. Program flow checking ensures essential functions execute in the correct sequence. Data verification stores all critical data redundantly in memory and checks validity before use.
During software development, a safety PLC requires additional software testing techniques. To verify data integrity checking, a series of "software-fault injection" tests must be run. Programs are deliberately corrupted to ensure the PLC responds in a predictable, safe manner.
The software design and testing is fully documented so third-party inspectors can understand PLC operation. While most software development does not justify this activity, it is precisely how the most insidious software design faults are uncovered.
High-Integrity Software
While some regulatory bodies in certain geographic areas still do not allow software-based equipment to be used in critical process control or safety protection applications, most have recognized the value of the intensive diagnostics available in safety-certified software-based controllers. Those regulators who do not allow software cite the unpredictability of complex software and the history of software failures [4].
There may be reason to doubt the reliability and safety of some types of consumer-grade software, but the international standards used by designers of safety PLCs have rigorous requirements to increase software integrity. The standards emphasize the process: product development according to a lifecycle model. While several models are available, the "V-model" is the recommended choice because of the link between the design and test specifications during product development (Figure 1).
The standards cover the entire development process from functional requirements of the product to final testing, not just software implementation. International standards require a whole set of development activities designed to ensure the highest software quality for avoidance and control of faults. These activities include program execution diagnostics, data verification testing, data storage integrity, complexity reduction, and a wide set of software development process requirements. Following these guidelines closely with the certification agency's help will result in "high integrity software."
Overall, the safety standards require a quality and robustness not found in many types of products, with or without software. The software development of these products must include many techniques that might be cost prohibitive — in both time and money — to average software suppliers.
Similar, But...
There are certainly many similarities between a safety PLC and a conventional PLC. Both have the ability to perform logic and math calculations. Both typically have input and output (I/O) modules that provide them with the ability to interpret signals from process sensors and actuate control final elements. Both will scan inputs, perform calculations and write outputs. Both typically have digital communications ports. But the PLC was not initially designed to be fault tolerant and fail-safe. That is a fundamental difference.
The realization of many users that conventional controllers cannot be depended upon in critical protection applications defines the need for safety PLCs. The standards are high for safety PLC design, manufacture, and installation. Anything less that these high standards will soon be considered irresponsible, if not negligent, from a business, professional, and social point of view.
Part II, reviews the techniques that safety PLC suppliers use to ensure the reliability of the embedded software.
References:
1. IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems, International Electrotechnical Commission, Geneva, Switzerland, 1998.
2. Goble, W. M., Bukowski, J. V., and Brombacher. A. C., "How Diagnostic Coverage Improves Safety in Programmable Electronic Systems," ISA Transactions, Vol. 36, No. 4, Amsterdam, The Netherlands, Elsevier Science B.V., 1998.
3. Goble, W.M., Control System Safety Evaluation and Reliability, ISA, Raleigh, N.C., 1998.
4. Leveson, N. G., Safeware,System Safety and Computers, Addison-Wesley, Reading, Mass., 1995.
