Friday, October 12, 2012
Integrated DCS and SIS or Isolated Systems
|| Found it worth Sharing ||
ISA- InTech Article
My Conclusion-
Which systems are better?
The original separate Safety
Instrumented Systems where the logic solver is totally different or the
integrated version, where the same system has two different kinds of
controllers/logic solvers-one type for the BPCS and another type for the SIS?
Note that the integrated SIS DCS does not imply that it is one
common system, it is just integrated for ease of use an convenience.
Thus the configuration software may
have different types of logic blocks, some meant exclusively for use in safety
functions, whereas other can be used in the normal BPCS functions. If the logic
solvers/ controllers need to communicate with other logic solvers, then it has
to be over a "safety bus".
Thus the integrated system is not
really totally integrated, but is much more close knit than the earlier totally
standalone systems.
Only time will tell us which system is
better. There were fears amongst a section of the community that a single
common cause failure could knock out both systems, but these seem to be
unfounded for the moment.
_____________________________________________
Integrated DCS and SIS
The right solution improves plant availability, safety
Fast
Forward
·
Advanced digital technology makes it possible to combine
process control and safety instrumented functions within a common automation
infrastructure while ensuring regulatory compliance.
·
The most reliable approach to control and safety system
integration maintains principles of segregation, with safety and control
strategies developed by different groups using dedicated methods.
·
Operational integration based on the separation principle
offers better support for plant life-cycle management.
|
By Johan School and Erik de Groot
Today’s industrial organizations face a host
of operational challenges. Ensuring the safety of personnel, equipment, and the
environment are priorities for every facility. At the same time, plants must
find ways to increase process efficiency, availability, and throughput—helping
to improve their overall business performance.
Manufacturers employ varied approaches to
interfacing their plant’s Distributed Control System (DCS), Programmable Logic
Controller (PLC), or relay system with the Safety Instrumented System (SIS).
The primary function of a DCS or PLC is to hold specific process variables to
predetermined levels in a dynamic environment, while a SIS is a static system
that takes action when a process is out of control and the control system is
unable to operate within safe limits.
Due to the costs associated with maintaining
separate engineering, operation, and maintenance infrastructure for control and
safety systems, many companies are now considering a more integrated
architecture.
Background
In 1998, the International Electrotechnical
Commission (IEC) published IEC 61508, “Functional safety of
electrical/electronic/programmable electronic safety-related systems.” This
document set the standards for safety-related system design of hardware and
software. IEC 61508 is a generic functional safety standard, providing the
framework and core requirements for sector-specific standards. These include
IEC 61511: 2003, “Functional safety: Safety instrumented systems for the
process industry sector,” a three-part series of standards that provides
good engineering practices for the application of SIS technology in the process
sector.
ANSI/ISA-84.00.01 was issued as the U.S. version of
IEC 61511 in September 2004. It primarily mirrors IEC 61511 in content, with
the exception of a grandfathering clause:
For existing safety instrumented systems (SIS)
designed and constructed in accordance with codes, standards, or practices
prior to the issuance of this standard (e.g., ANSI/ISA-84.01-1996), the
owner/operator shall determine and document that the equipment is designed,
maintained, inspected, tested, and operated in a safe manner.
The European standards body, CENELEC, has adopted
the standard as EN 61511. This means in each of the member states of the
European Union, the standard is published as a national standard.
More recently, in 2007, a number of major
control system end users and manufacturers, along with ISA, formed the ISA
Security Compliance Institute (ISCI) to establish standards, tests, and
conformance processes supporting the integration of control system products.
The organization’s work addresses key issues, such as cybersecurity related to
process control and safety systems.
Why separate systems?
In an industrial plant, the DCS and SIS are
typically interfaced through a gateway, with each system having its own
operator interfaces, engineering workstations, configuration tools, data and
event historians, asset management, and network communications.
In addition to segregation of control and
safety equipment, there is separation of responsibilities between the personnel
who manage these assets. The safety engineer is focused on safe operation,
whereas the process engineer wants to maximize plant availability and
operational profit.
According to IEC 61511, safety systems should
be dedicated to safety-critical assets only. Most DCS systems are not
sufficiently robust and fail-safe to operate safety-critical instruments at all
times. The standard also urges caution if non-safety and safety functions are
implemented in the same safety-related system since this may lead to greater
complexity and increase the difficulty of carrying out life-cycle activities,
such as design, validation, functional safety assessment, and maintenance.
Today, however, advanced digital technology
has made it feasible to combine process control and safety instrumented
functions within a common automation infrastructure—all while ensuring regulatory
compliance. With this approach, plant personnel can view the status of the
safety system and its applications, and combine this information with process
control functions. The evolution of the Human-Machine Interface (HMI) allows
critical information to be shared between the safety system and controllers and
between the safety system and third-party subsystems via a digital bus
interface.
Achieving operational integration
Different suppliers offer different strategies
for operational integration of plant systems. For industrial organizations, the
dilemma is how to achieve an integrated control and safety solution with
advanced functionality and productivity, without compromising safety and
security.
In a typical industrial operation, four levels
of integration are essential from a usability point of view:
·
First, the operational integration must allow plant personnel to
have a seamless, transparent interface to the process under control. Whether
the actual strategy is running in the process controller, the safety system, or
on a higher level makes no difference. All required information would be
available on the operational level.
·
Second, peer-to-peer communication between safety controllers
and process controllers is the key to integration. Information from one
controller needs to be communicated to peers quickly in order to anticipate
process startup or abnormal situations in a controlled manner.
·
Third, all data available in the lowest level of process and
safety I/O can be transferred to the higher level of operations and turned into
information that is usable for various higher level applications.
·
Finally, configuration tool integration only has added value if
the point information is interchangeable. This means the user has a single
point of data entry, and all information entered into the database can be
replicated to other databases. The information is available for use at all
levels of the safety and control topology.
It should be noted integration of the DCS and
SIS does not imply a single common system. Rather, the two systems are
integrated for ease of use and convenience. The configuration software may have
different types of logic blocks, with some meant exclusively for use in safety
functions and others used in normal control system functions. If the logic
solvers/controllers need to communicate with other logic solvers, then it has
to be over a communication bus that is robust enough to carry safety-critical
data reliably. Thus, the integrated system is not really totally integrated but
is much more closely aligned than earlier totally stand-alone systems.
Choosing right approach
There are undoubtedly many good reasons for
tight integration of control and safety from an operations and productivity
point of view. Solutions for operational integration encompass key areas across
the plant, including operator interfaces, data processing, peer control,
diagnostics, post-mortem analysis, fire and gas systems, alarm management,
power supplies, and simulation/optimization.
However, industrial plants cannot achieve
their operational objectives and still minimize safety risks without choosing a
solution driven by the separation principle. Some technology providers seek to
integrate control and safety by using the same hardware and software platform,
network environment, operating system, and engineering tools for both
environments. However, this strategy increases the possibility of systematic
controller failures, including those resulting from design errors.
Experience has shown the most robust and
reliable approach to DCS-SIS integration maintains the well-established
principles of system segregation, with safety and control strategies developed
by different groups using dedicated methods.
The specific criterion for effective
operational integration includes:
·
Separate databases: Plants should employ separate databases to store safety
and control strategies and also use dedicated control and safety configuration
tools. Maintaining separate tools with separate databases prevents unauthorized
changes or corruptions, decreases safety risks, and prevents common cause
failures.
·
Database integrity, security: It is important to protect safety software from viruses
and harmful hacking. This includes checking the integrity of the software
before installation, after installation, and during run time. The integrity of
all data accessed through the safety configuration tool, as well as the
integrity of an application loaded into the safety system, must be safeguarded
from unwanted changes to protect the entire safety application during the
entire life cycle.
·
Managed and protected application environment: Protection of the safety system from off- and on-process
changes is another important requirement. In particular, users need a login
protection mechanism to protect the safety application from accidental or
unauthorized changes when it is unmanned over a specified period.
·
Dedicated software and hardware: Using dedicated and specifically developed hardware and
software, according to the IEC 61508 safety standard, reduces the risk of a
common cause failure. Dedicated hardware and software for safety and control
also protects the safety system from any defects in control-related operations.
·
Secure network environment: A good practice is to protect the safety system from
outside threats through the use of an embedded hardware firewall, which
isolates the safety application during runtime execution from external devices.
With this embedded firewall and the use of a SIL-certified safety protocol, the
data integrity between control and safety is protected and guaranteed.
·
Safety device certification: Additional cybersecurity assurance can be gained by
utilizing safety solutions that have received the ISCI’s ISASecure Embedded
Device Security Assurance certification. This certification recognizes the
integrity of the embedded safety device and its development life cycle and
involves rigorous testing of communication robustness, functional security, and
software development security.
Benefits to end users
As described in this article, industrial
facilities can realize significant advantages from seamless, yet secure,
integration of plant control and safety systems. Some of the potential benefits
include: accurate time synchronization, elimination of data mapping
duplication, common HMI, and reduced operator and maintenance training
requirements.
With secure integration at the control data
and operator levels, plants can implement a single, common operational
interface for control and safety. Operators can view the status of the safety
system, as well as monitor alarms and events related to the process. Any alarms
or events from the safety system are automatically integrated into the control
system HMI. It also makes no difference where an application is running; all
required information is available to the operator. This allows for a wide range
of applications to be monitored plant-wide from any operator console, from
rotating equipment and compressor protective systems through emergency shutdown
systems to large plant-wide fire and gas applications. And with integrated
simulation tools, plant managers are able to verify and optimize hazard
identification, train operators, and verify the responses.
Last, operational integration based on the
separation principle offers better support for plant life-cycle management.
Users can choose to migrate their control and safety systems to newer releases
independent of one another. Migrations can even be performed on-process without
effecting normal operations. This contrasts with common platform solutions,
which frequently require migration of the control and safety infrastructure as
a whole.
Prudent industrial organizations will continue
to adhere to the separation principle for control and safety systems while at
the same time achieving operational integration, which combines hardware and
software diversification with integrated solutions for the operator interface,
data processing, data analysis, and alarm management.
Labels: control, control engineering, DCS, ESD, Rahul Kapoor
Subscribe to Posts [Atom]
Post a Comment
Note: Only a member of this blog may post a comment.