Are we safe enough? Plant managers can effectively mitigate risk through safety & security systems integration
Ask a plant manager why safety is important, and the answer is that protection of personnel, equipment, and the environment will prevent serious incidents. Ask an IT director, and it's data integrity and network availability that are crucial to safeguarding the entire plant and its productivity. No matter what perspective taken, all plant managers are asking themselves, “Are we safe enoug...
Ask a plant manager why safety is important, and the answer is that protection of personnel, equipment, and the environment will prevent serious incidents. Ask an IT director, and it's data integrity and network availability that are crucial to safeguarding the entire plant and its productivity.
No matter what perspective taken, all plant managers are asking themselves, “Are we safe enough?” An integrated approach to plant safety and security improves business performance and peace of mind via interrelated layers of protection to deter, detect, and mitigate potential threats.
A process plant typically operates in what is called the “normal operation” zone. In this zone, the control system is tasked with keeping the process in this region of operations—and in most cases, it does. However, outside forces or disturbances can cause a process to deviate or drift from normal operation into the “upset condition” zone. In this zone, operator action is required. If left alone, the abnormal situation moves into the “critical situation” zone and emergency or mechanical shutdown action is taken to safeguard the plant.
One of the defining elements of an abnormal situation is the urgency surrounding a response. With a clear understanding of how abnormal situations develop, and with many tools available to mitigate these situations, one can prepare for the unexpected.
Layers of protection
The control system is composed of instrumentation and a distributed control system to maintain the process in the normal operating region. Inefficiencies can occur in a process, equipment can fail, and operations can drift beyond a safe zone. The intent of the asset-monitoring layer, which sits on top of the control system, is to give an early warning of pending failures before they become operational concerns.
The operator's first warning that the control system cannot cope with a pending condition is the alarm system. When properly engineered, the alarm system warns the operator that an action is required. From here, the operator needs to interact with the system to bring the process back to normal.
But system interlocks triggered by field switches, stored boundaries, or constraints may intervene. Typically these interlocks are built into the control logic to prevent equipment damage.
Within this category of interlocks is a work process to establish limits. In operations management, the critical, standard, and target boundaries of system variables or processes must be clearly understood and defined. This requires supporting information including the purpose of the measurement, a piping instrumentation diagram reference, equipment constraints, corrosion control limit, safety limit, and environmental limit—all stored or referenced so that the database is a complete repository of the information associated with both the variable and the boundary.
The other two layers play an integral part in the protection of life and plant assets, although everyone hopes that the situation never requires them. The safety system provides a redundant and final layer of protection that brings the plant to a safe condition. Failing all else, a layer that demands consideration contains applications that track personnel and muster those who are evacuated in an emergency.
But mitigating risk involves more than just proper application of hardware and software. A plant must consider an integrated approach to managing the total enterprise when designing for risk management that maintains a safe operating environment. The challenge is in knowing when to integrate and when to keep separate for security and safety reasons.
Operational integration gives plant personnel a seamless interface to the process that is under control, while maintaining safe separation. From an operational perspective, it makes no difference where the application is running: All required information is available to the operator, allowing applications running in equipment to be monitored from any operator console—e.g., from rotating equipment and compressor protective systems to emergency shutdown systems and plantwide fire and gas applications.
To ensure appropriate segregation, separate databases should store the safety and control strategies, and separate software modules should be made available through specialized tools. This prevents unauthorized changes or corruptions, and common-cause failures. A protected module is safe from viruses and harmful hacking via a built-in protection mechanism that checks the integrity of the software before installation, after installation, and during run time.
A managed and protected database environment is another key to the success of separate databases. The login scheme should include a dedicated protection mechanism with several access levels for the engineering application, loading of the application in the controller, and forcing points in the Safety Instrumented Systems (SIS) controller. A user-expiration mechanism downgrades the access level after a user-defined period of time elapses to protect the application from accidental or unauthorized changes when the equipment is unmanned over a period of time.
When considering software and hardware, using dedicated and specifically developed hardware and software reduces the risk of a common-cause failure. Using dedicated solutions for both safety and control protects the safety system from any defects in the control-related operations. In addition, the safety and control strategies are developed by different groups using dedicated methods. Using the same hardware or software for both safety and control increases the possibility of systematic controller failure. A clear separation reduces the effort for testing and designing safety systems.
It's also necessary to protect equipment from outside threats by installing an embedded hardware firewall that isolates the safety application from external devices during run time. Those devices can never jeopardize the safety or availability of the application. With this embedded firewall and the use of a Safety Integrated Level (SIL)-4 certified proprietary protocol, the data integrity between control and safety is protected.
Fire and gas, power, modifications, and simulation elements were once thought of as extras in the safety & security realm. Today it's essential to plan and design for these elements before implementing any safety and security solutions. This ensures the ability of all systems to work together.
One of the main tasks of a fire and gas system is to alert personnel of safety hazards and initiate evacuation of buildings and areas through annunciation devices. While most safety system outputs are normally energized outputs, these annunciation devices are of the “energize-for-action” type.
What this means is the safety system must have purpose-built field-monitoring output modules to properly integrate with a fire and gas system. Those field-monitoring output modules will actively check the wiring from the SIS output channel to the fire and gas field equipment such that malfunction of the connected device, lead breakage, or short-circuit in the wiring can be detected.
Additionally, a safety system that powers field devices makes project implementation easier. Sometimes appropriate power supplies are difficult to find and add unnecessary cost. The need to source external power supplies can add $10 per device to implementation. For an average refinery, this could add up to $140,000.
After implementation, it's not unusual for hundreds of modifications to be made to the safety system, yet some of these systems do not allow integrated modifications. Instead the system must be taken offline, modifications installed, and then full-functional testing needs to occur before the system—and process—can be started.
Some claim that changes can be made, but they hold huge disadvantages and even safety risks. From the moment a change is initiated until the functional test is completed, process operators are fully responsible for the safety of the unit.
One reason safety systems are implemented is to remove the “human factor” from the safety layer of dangerous processes. If an operator does not judge correctly once a safety-critical situation occurs, the safety of a plant is at stake. A safety system that delivers a fully tested and approved infrastructure for implementing online modifications to the safety controller configuration will eliminate this risk.
By using a fully integrated simulated system—process, control, and safety—plant managers can verify and optimize hazard identification, educate and train operators, and verify if responses are correct. Such integration supports logic debugging with visualization displays.
The safety system can be integrated with a simulation process model or forced from open-ended connections. With some solutions, the control system database is automatically imported within the simulation technology with a look and feel identical to the configuration tool.
Abnormal situations surely can cost many millions of dollars. Technology can relieve safety pressures, but only when a site fully considers independent yet interrelated layers of protection to eliminate threats will it truly reduce the risk.
Plant-floor advisory: Industrial Ethernet networks need more security
Use of Ethernet-based networks to connect machines, production systems, and enterprise solutions promises a high degree of flexibility and cost savings. It also leaves enterprise networking and common network interfaces more vulnerable to security compromises.
There are all kinds of excuses why security is given little consideration when it comes to Ethernet-based networks on the plant floor, but growing connectivity between production and office networks necessitates that potential interactions, security consequences, and maintenance costs be considered, says Torsten Rössel, director of business development for Innominate Security Technologies AG , a supplier of embedded security devices for industrial applications.
“Corporate firewalls establish access security against Internet attacks from most external intruders, but harmful programs often are introduced internally,” says Rössel. “Consider, for instance, that external service technicians have access to production networks, and it's possible for employees and visiting consultants with laptops to inadvertently—or deliberately—introduce malicious software behind the external firewall.”
The consequences of a production interruption can be more serious than failures in the office network. Accounts vary because industries differ, but it's easy to see that lost production can cost a manufacturer thousands of dollars, and damage customer relationships.
What's needed, says Rössel, are architectures with small, distributed security systems. While some believe this approach is cost prohibitive, it isn't necessarily so, he says.
“Innominate's mGuard security devices are used in a decentralized, distributed architecture to protect individual production cells. These security appliances are designed for use in industrial environments. They combine the characteristics of a 'stateful inspection firewall'—incoming and outgoing data packets are monitored and eventually blocked based on predefined rules—with options for encrypted, authenticated communication via virtual private network connections,” explains Rössel. “Their suitability for industrial applications stems from use of relevant industrial standards and the ability to integrate with industrial controls such as controllers, panel PCs, machinery, and plant networks.”
The mGuard firewall acts as a self-contained system in the network, and can protect a production cell or a single automated device. Updates to the security device can be made without interfering with the protected system itself, so existing systems can easily be retrofitted, Rössel says.
Additionally, Innominate Device Manager (IDM) software has templates, offers automated inheritance of configuration properties, and uses an integrated Certificate Authority to produce VPN certificates. Via a push-pull mechanism, a central management console supplies needed information to the decentralized components, Rössel says.
“It's an economical solution that delivers decentralized security with effective protection devices arranged in a distributed architecture,” Rössel says. “The security infrastructure can be administered and maintained from a central console so it doesn't add any administrative burden.”
—Jim Fulcher (
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.