2.2 Security Systems (Part 1)

What is a "Security System"?

Safety systems are designed to protect people, equipment, and the environment from potentially hazardous conditions. In such cases, they must act immediately, moving the plant or equipment to a safe position.

Security system designers often make the mistake of not considering the system holistically. They focus too much on one aspect, such as the type of hardware to use, and neglect other parts, creating unfortunate bottlenecks and weaknesses.

Figure 2-3. Security System Objectives

The IEC Technical Committee examined 34 accidents that were the direct result of failures in control and safety systems in different industries.

The result is very illustrative and is reflected in Figure 2-4.

Figure 2-4. Causes of failures

In other words, almost half of the errors were due to incorrect specifications.

As a result of this study, the Committee established general requirements and strategies to achieve the functional safety of the Safety Systems.

Figure 2-5. Strategies for functional safety

People's capabilities: adequate training, good knowledge and experience.

Security Management: The security policy must be set out in a security plan that must be carried out for each project.

Technical requirements: risk assessment, required security level (SIL), hardware and software requirements, documentation.

These requirements must be taken into account in each of the 16 phases of the so-called "Global Security Life Cycle".

Figure 2-6. Global Security Life Cycle (Click to enlarge)

The cycle begins with the concept definition (the scenario), continues with risk analysis, implementation, start-up, maintenance, and ends with final decommissioning.

Each period of the life cycle includes:

■ Objectives

■ Requirements

■ Scope of application

■ Specification

■ Results

Functional safety assessment must be carried out at all stages, especially in cases of higher safety levels, by independent experts (employees, departments, organizations) with access to all personnel, all associated documentation and all equipment.

Within phase 9 of the Cycle there are two clearly differentiated concepts: hardware (part 2 of IEC-61508) and software (part 3).2.2.2 Design of Security Systems. General Considerations When faced with a Security System, we must establish some basic design criteria that will be vital in later phases:

• What technology to use?: Relays, Solid State, Microprocessor
• What levels of redundancy? Does it depend on the technology or the level of risk?
• Field devices: Digital or analog? Redundant? How often should they be tested? Does it depend on the application, technology, or risk level?
• Periodic testing: How often? Does it depend on the technology, the level of redundancy, or the level of risk?
• Types of Security System Failures?
• Regulations: Which ones to apply?

In any process there are many risks that can cause an accident.

Figure 2-7 shows all the possible causes of a failure.

Figure 2-7. Main risks

2.2.3 Control System versus Security System

It is recognized by all safety experts and recommended by all standards that both systems should be independent. Despite this, we still find technicians or plant managers who do not see, or do not want to see, the difference between the two systems and prioritize economic or other interests over plant safety.

It is obvious that using the same system for both functions (control and security) has advantages (e.g., cost and maintenance), but it is also clear that it has many risks, which we hope to clarify in this chapter.

Let's assume that the same Control System also performs protection and safety functions, and that a safety demand arises from the process or boiler, for example, a sudden pressure surge within the combustion chamber. The Control System must act immediately by shutting down the boiler, which entails, for example, closing all fuel shut-off valves (SOVs).

What happens if a failure occurs in the Control System? Such a failure should never prevent the boiler from reaching a safe state.

Figure 2-8. Security Demand

Figure 2-8 shows a clear and simple example of a dangerous failure.

If a short circuit had occurred in a digital output during the operation of the boiler, neither the system nor the operator would have been aware of it.

Even if the CPU commands the valve to close (de-energize), this will not occur if the output transistor is short-circuited.

Figure 2-9. Active and Passive Failure

Now let's assume there is a separate and independent Security System.

The Safety System could also fail and therefore must comply with certain design criteria that greatly differentiate it from the Control System.

Figure 2-10. Security Demand The failure to reach a safe position is essential. Unnecessary or nuisance shots must be minimized.

Figure 2-11. Types of failures The types of failures of the Safety Instrumented System (SIS, according to IEC-61508) are:

• Undetected dangerous fault: this is the worst, it can be avoided with regular testing or by improving self-diagnostics
• Dangerous fault detected: action must be taken quickly
• Degraded mode due to partial failure of the redundant system: this is the best; redundancy increases the investment cost but reduces the total life cycle cost
• False trigger: the system's MTBF needs improvement, it can lead to bypass abuse
• IEC-61508 makes many considerations regarding SIS failures.

For example, it classifies the components of the E/E/PES into two groups: ■ Type A Components: The failure modes of all components are well-defined, the components can be fully tested, and there is a good failure data history (100,000 operating hours over two years in 10 systems across different applications). Example: resistors, relays. ■ Type B Components: The failure modes are not well-defined, or not all components can be fully tested, or there is no good failure data history. Example: microprocessors. Based on this classification and considering the percentage of diagnostics performed on the equipment, the achievable SIL levels are established. Fortunately, most users have had few experiences with PLC failures. The typical CPU watchdog timer failures or a digital output that fails to power on are familiar to everyone, but very few are fully aware of the number of possible failures a PLC can have, many of them semi-hidden and sometimes difficult to recognize as clear failures. As an example, according to IEC-61508, no microprocessor-based system can have a level higher than SIL3, even if the self-diagnostic percentage is 99%. The main differences between the Control System and the Safety System are shown in the following summary:  

  Control systems are active and dynamic, which is why most faults are self-detecting. Safety systems are passive and static, so many faults remain hidden. They need to be manually tested or incorporate self-diagnostics, something that general-purpose PLCs rarely include. Combining both functions, control and safety, in a single system has advantages: a single power supply, simplified maintenance and spare parts storage, easier training of technical personnel, and reduced costs. However, almost all standards, regulations, and expert recommendations strongly advise against this combination. If someone were to go against these recommendations, they would need to have compelling and well-documented reasons for doing so. How could such a decision be justified before a jury in the event of an accident? Both systems, including instruments and actuators, must be physically and functionally separate.  

Figure 2-12. Control Levels Failures due to common causes should be avoided (hardware, software, vibrations, heat, design errors, maintenance errors, etc.).