Industrial Control Summary: A safety PLC (Safety Programmable Logic Controller) is a programmable system that can still respond correctly and cut off the output in a timely manner when it or its peripheral components or actuators malfunction.
Unlike ordinary PLCs, safety PLCs not only provide the functions of ordinary PLCs, but also implement safety control functions, complying with the requirements of safety-related component standards for control systems such as EN ISO 13849-1 and IEC 61508. All components in a safety PLC employ a redundant and diverse structure. Two processors perform cross-checking during processing, and the processing results of each processor are stored in their respective memory. Output is only made when the processing results are completely consistent; if any inconsistency occurs during processing, the system immediately shuts down.
In addition, in terms of software, the safety function blocks provided by the safety PLC, such as emergency stop, safety door, and safety light curtain, are all certified and encrypted. Users only need to call the function blocks to configure the relevant functions, ensuring that the safety functions will not be lost due to program vulnerabilities in the safety functions during the design process.
Designing a safety PLC requires considering many factors and incorporating numerous specialized design features. For example, a safety PLC emphasizes internal diagnostics, combining hardware and software to allow the device to constantly monitor its operational status. The software within a safety PLC utilizes a range of specialized technologies to ensure reliability. A safety PLC possesses redundancy, enabling system operation to continue even if a portion of the system fails. Furthermore, a safety PLC includes external safety mechanisms to prevent unauthorized reading or writing of internal data via digital communication interfaces.
The difference between safety PLCs and conventional PLCs lies in the fact that safety PLCs require safety certification from third-party professional organizations, meeting stringent international standards for safety and reliability. A thorough, systematic approach must be adopted in the design and testing of safety PLCs. Experts from TUV in Germany and FM in the United States provide independent third-party verification and validation of the safety PLC design and testing process.
Specialized electronic circuitry, meticulous diagnostic software analysis, and a comprehensive design that tests for all possible failures ensure that the safety PLC has the ability to detect potentially hazardous failures in over 99% of its internal components. A Failure Mode, Effects, and Diagnostic Analysis (FMEDA) methodology guides the design process, identifying how each component contributes to system failure and outlining how the system should detect that failure. TUV engineers personally perform failure testing as part of their certification process.
Strict international standards are applied to safety PLCs. These standards require specialized techniques to avoid complexity. Further analysis and testing are needed, meticulously examining the operating system's task interactions. This testing includes real-time interactions, such as multitasking (when in use) and interrupts. A special diagnostic process called "program flow control" and "data verification" is also required. Program flow checks ensure basic functions execute in the correct order, while data verification ensures all critical data is redundantly stored in memory and validated before use. During software development, a safety PLC requires additional software testing techniques. To verify data integrity, a series of "software failure injection" tests must be performed—intentionally disrupting the program to check if the PLC's response operates in the expected safety manner. Software design and testing are meticulously documented so that third-party inspectors understand the PLC's operating principles. The fact that most software development doesn't utilize this standardized process explains why so many bugs in low-quality software go undetected.
