New digital technology now makes it feasible to integrate process control and safety instrumented functions within a common automation infrastructure. While this can provide productivity and asset management benefits, if not done correctly, it can also compromise the safety and security of an industrial operation. Cyber security and sabotage vulnerability further accentuate the need for securing the Safety Instrumented System (SIS).
Certainly, a “common platform” approach, using similar hardware and software dedicated for control and safety functions, respectively, can provide the potential for cost savings. However, it is widely acknowledged that utilizing separate, independent, and diverse hardware/software for safety and control is the optimal way to protect against potentially catastrophic common cause and systematic design and application errors.
Different vendors offer varied degrees of integration and solutions. The question is how to provide an integrated control and safety solution with advanced functionality and productivity, without compromising safety and security. So where do users draw the line?
A TÜV certification of the hardware/software systems to IEC 61508 specifications carries significant advantages, but should this be the only criterion? How does a TÜV certificate extend to the plants overall assignment of risk reduction credits for all independent layers of protection (IPL)? Control system embedded safety logic solvers may actually increase the SIL requirements of the SIF if no credit is allowed for the DCS as an IPL.
This paper discusses engineering best practices in integrating control and safety in a secure manner, while maintaining independent layers of protection. Potential benefits and side effects of the different approaches are highlighted within the paper.
Author: Asif A. khokher (Innovasys Engineering & Systems)
DCS stands for "Distributed Control System". DCS's were designed to control processes, not discrete operations. As such, a large number of the inputs and outputs are analog like a 4-20mA signal or 0-10V signal. In Literary meaning, a Distributed Control System (DCS) refers to a control system usually of a process or manufacturing system, in which the controller elements are not central in location (like the brain) but are distributed throughout the system with each component sub-system controlled by one or more controllers. Process plants used to have long series of panel mounted Single Loop Controllers (Analog/PID controllers).
PLC stands for "Programmable Logic Controller". Historically a PLC was in discrete control of manufacturing processes. Whole discrete logic used to be implemented with relay circuitry. Most of the inputs and outputs for discrete control are binary, meaning they have only two states: On and Off.
What are attributes and characteristics which differentiate the PLC system from the DCS. There have been claims and counter claims from different manufacturers that their system is DCS or PLC. The topic has remained under debate for long, and especially today when we have already entered into new era of Hybrid Distributed Control Systems, it has become increasingly difficult to select and differentiate the advantages and drawbacks one can get from different systems.
There are few similarities and dissimilarities which I would like to mention here:
1) DCS are designed or made available to the user in a way that only configuration in form of a Functional Block has to be carried out unlike PLC, where complete programming has to be implemented using any one of the different languages available in the system.
Now, Functional Blocks are also available in the PLC systems, which really makes it comparable to DCS.
2) When DCS started emerging in the market, idea was to supply DCS with whole bunch of hardware and software packages including for Human Interface, necessary for the complete automation of the plant, thus facilitating Single Point Configuration in terms of database and communication possible in general. Additionally, Human Interface does not need separate communication package i.e DDE server, to communicate with the controller. DCS includes higher levels of application software for regulatory and batch control.
In case of PLC systems, PLCs were not supposed to be in packages but competition with DCS vendors forced the PLC manufacturers to offer necessary all other softwares and packages.
3) Many DCS are designed such that it is possible to configure cycle time for each Functional Block. Thus DCS system takes care of cycle time scheduling of the Functional Blocks which are the basic execution units. This is one of the reason that overall scan time of the DCS is comparatively higher than the PLC system.
This functionality has been introduced in PLC systems(s) in some form as well.
4) A DCS has inherently multiple processor capability thus making the functionality distributed across a network. In a typical multi-processors (multi-node) DCS architecture, Engineer has to put in less efforts for inter-communication of the processors or one controller can easily access the Tag(s) from the database of the other .i.e the input of FB in one controller can be output of FB of the other controller.
This is possible now in PLC but more efforts have to be put in.
5) DCS programming is centered around configuration of Functional Blocks and discrete logic is implemented in DCS using FBs, thus making the DCS inherently an analog control system (although ladder programming is also possible in some of the DCS also). PLCs were programmed using Ladder/Relay language , before arrival of IEC 1131-3 standard and Analog control was incorporated inside Ladder inside Ladder Logic using special FBs. This is probably the reason we look at some of the process plants that process (Analog) control is done by the DCS, while emergency control (Discrete Control) is implemented by PLC based systems.
6) PLCs are still being used at RTU stations because of their simple, small and cheaper architecture as well as engineering (typically the RTU application) instead of big DCS. DCS have been used as the central system in a SCADA network. In a typical SCADA scenario, one DCS is connected to many PLCs systems.
7) Being Discrete in nature, PLC was natural choice of manufacturer and end-user to apply it for safety system. This led to production of specialized safety system conforming to SIL3 certification in accordance with ANSI / ISA 84.00.01-2004.
Today, a lot has changed, it is difficult to distinguish between two systems in terms of its main features. Differences between the two has virtually vanished due to Programming / Configuration language standard IEC-61131.The functionality of the PLC has evolved over the years to include sequential relay control, motion control, process control, distributed control systems and networking. However, in major industrial areas and structure markets, it is practice to deploy DCS for process control and PLC based system for safety control. Perhaps, for a large install base like more than 1000 I/Os system, cost of installation, addition and maintenance per I/O is less in case of DCS system.
Now, more important is cost, application, system integrity, reliability, maintainability, historical logging / intelligent statistics and learning / training. How much support is available from the vendor for the operation matters most to the operator now. This has resulted into ‘Solutions Packages’ by vendors to their customers instead of simply offering individual products. It is DCS or PLC, must come in a solution package. More and improved System functionalities have made these system more complex which require strong integration between the operator /user and the manufacturer.
Few vendors also introduced Hybrid DCS / PLC system or transformed their PLC based system into DCS by incorporating similar features. DCS vendors have now introduced packages for Asset Optimization and management which seamlessly integrate with their systems. It is difficult to say which system to select ? It varies from user to user as discussed above. It is End-User who has to have all knowledge and courage to take responsibility of his system in totality.
Author: Asif A. khokher (Innovasys Engineering & Systems)
Whether to migrate to new process control system and de-commission the existing one; is a question asked by many plant owners. It is not only a matter of cost but lot of human resources and time is required to accomplish this successfully. Migrating to a new platform whether it is same OEM/vendor or new, is a question to be answered by the persons working for the plant.
If this question is asked to vendors/sellers, then no one answer would be obtained. New seller would provide arguments in the favor of new platform. He will first focus on the disadvantages of the existing system and may argue following in favor of the migration
- Parts will eventually become obsolete and not supported by the OEM.
- Degrading parts of the system will tend to increase the failures and add-in hazards to your facility.
- Increasing failures will divert your resources to resolve these issues instead of focusing on improvement.
- New Platform will be free from above issues and your people may rather focus on leveraging new features of the new platform to optimize the performance of the plant.
- New platform will bring more processing speed, open architecture and integration would be easier. It would be easier to learn the new platform and modifications /additions could be done without the immediate support of the vendor. This will also be crucial factor during emergency phase if encountered.
- New features of the new platform will bring more power in the controlling and optimizing the process. Yes, it is expensive, but power/cost remains the same.
On the other hand, OEM of the existing system would argue:
- Few of the critical older parts may be changed with the new versions which are more reliable. In general, Integrity of these parts is proven in the industry so trustable.
- Improved version of the software(s) would bring additional features which would help engineers control their process better and get more optimization.
- No new training is required. Hence, resources may focus on optimizing the existing technologies and facilities rather learning new technologies in case of new platform costing lot of additional money for the plant owner. Operators too will be happy with the continuity of the existing platform.
So, what is the decision, to migrate or not to ? Following would aid additionally in deciding this:
- How new platform would help in optimizing the process and increase the production in quantity and quality ?
- Does the new platform help control system operator manage it more efficiently in the control room ?
- Does the new platform would help increase system reliability and reduce risk of hazard? Does process safety management would be more efficient ?
- Does the new vendor provide better mechanism of after –sales support ?
- Does inventory management would be more efficient in the new platform ?
- Does the online diagnostics and performance data of the system including field instruments would be available in the new platform ?
- What level of effort would be required from different departments i.e operations, maintenance, engineering, management, safety etc in migrating to new platform ?
- Does the new platform provide better life cycle cost as compared to the legacy system ? Installation & commissioning cost normally is high of the new system, however, operating and maintenance cost may reduce the expenses.
It is decision of the plant user whether to migrate or not to migrate. In both cases, efforts are required. Cost of installation and commissioning may not be high as compared to production revenues, however, systematic decision and implementation of the decision is necessary to reduce the risks.