Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Vs
DCS
What is a Programmable Logic Controller PLC?
A Programmable Logic Controller PLC is a small computer used for automation of real-world processes, such as control of machinery on factory assembly lines. The PLC usually uses a microprocessor. The program can often control complex sequencing and is often written by engineers. The program is stored in battery-backed memory and/or EEPROMs. Unlike general-purpose computers, the PLC is packaged and designed for extended temperature ranges, dirty or dusty conditions, immunity to electrical noise, and is mechanically more rugged and resistant to vibration and impact. The main difference from other computers are the special input/output arrangements. These connect the PLC to sensors and actuators. PLC's read limit switches, temperature indicators and the positions of complex positioning systems. Some even use machine vision. On the actuator side, PLCs drive any kind of electric motor, pneumatic or hydraulic cylinders or diaphragms, magnetic relays or solenoids. The input/output arrangements may be built into a simple PLC, or the PLC may have external I/O modules attached to a proprietary computer network that plugs into the PLC. PLC's were invented as less expensive replacements for older automated systems that would use hundreds or thousands of relays and timers. Often, a single PLC can be programmed to replace thousands of relays. Programmable controllers were initially adopted by the automotive manufacturing industry, where software revision replaced the re-wiring of hard-wired control panels. The earliest PLCs expressed all decision making logic in simple ladder logic inspired from the electrical connection diagrams. The electricians were quite able to trace out circuit problems with schematic diagrams using ladder logic. This was chosen mainly to reduce the apprehension of the existing technicians. The functionality of the PLC has evolved over the years to include typical relay control, sophisticated motion control, process control, distributed control systems and complex networking. Today, the line between a general purpose programmable computer and a PLC is thinning. The data handling, storage, processing power and communication capabilities of some modern PLCs are approximately equivalent to desk-top computers. PLC-like functionality, combined with remote I/O hardware, allow a general-purpose desktop computer to overlap some PLCs in certain applications. With the IEC 61131-3 standard, it is now possible to program PLCs using structured programming languages, and logic elementary operations. A graphical programming notation called Sequential Function Charts is available on certain programmable controllers.
DCSs allow centralized configuration from the operator or engineering console in the control room. You can change programming offline, and download without restarting the system for the change to be effective. DCSs allow inter-controller communications. You can do data exchange in most DCS systems ad hoc (no need for predefined data point lists). You access data by tag name, regardless of hardware or location. DCSs use multi-tasking operating systems, so you can download and run applications aside from the real-time control functions and still do fractional-second control. DCSs now come in "micro" systems, to price-compete with PLCs-but with full DCS features and capabilities. The typical DCS has integrated diagnostics and standard display templates that automatically extend/update when your database changes. This database is central to the system-you don't have different databases sitting in the controllers. DCSs have user-friendly configuration tools, including structured English, control block libraries, SFC (sequential function chart), and even RLL (relay ladder logic). Most DCSs allow graphical configuration, provide online diagnostics, and are self-documenting. Most provide for user-defined control blocks or customized strategies. The controllers execute control strategies as independent tasks; thus, making changes to part of the control logic has no impact on the rest. An important difference between DCSs and PLCs is how vendors market them. DCS vendors typically sell a complete, working, integrated, and tested system; offering full application implementation. They offer many services: training, installation, field service, and integration with your Information Technology (IT) systems. A DCS vendor provides a server with a relational database, a LAN with PCs for office automation, networking support and integration of third-party applications and systems. The DCS vendor tries to be your "one-stop shop." The PLC is more of a "do-ityourself" device, which is sometimes simpler to execute. Programmable Logic Controllers. When PLCs were solely replacements for hard-wired relays, they had only digital I/O, with no operator interface or communications. Simple operator interfaces appeared, then evolved into increasingly complex interfaces as PLCs worked with increasingly complex automation problems. We went from a panel of buttons and I/O-driven lamps to PLC full-color customized graphic displays that run on SCADA software over a network. PLCs now have many DCS-like control functions (e.g., PID algorithms) and analog I/O. They've moved past their birthplace: the digital world (switch and binary sensor inputs and output contacts to run motors and trigger solenoids). PLCs are fast: They run an input-compute-output cycle in milliseconds. On the other hand, DCSs offer fractional second (1/2 to 1/10) control cycles. However, some DCSs provide interrupt/event-triggered logic for high-speed applications.
PLCs are simple, rugged computers with minimal peripherals and simple OSs. While increasing reliability, PLC simplicity is not conducive to redundancy. Thus, fully redundant ("hot," automatic, bumpless) variations of PLCs, with their added hardware and software, sometimes suffer from a reduction in their reliability-a characteristic PLCs are famous for. Data exchange typically requires you to preassign data registers and hard code their addresses into the logic. If you add registers or need to reassign data, you typically have to deal manually with the Domino Effect. Typical PLC Relay Ladder Logic (RLL) languages include function blocks that can perform complex control and math functions (e.g., PID algorithms). Complex multi-loop control functions (e.g., cascade management and loop initialization) are not typical. For functions too messy to implement in RLL, most PLCs provide a function block that calls a user-written program (usually in BASIC or C). PLCs typically operate as "state" machines: They read all inputs, execute through the logic, and then drive the outputs. The user-written logic is typically one big RLL program, which means you may have to take the whole PLC off-line to make a change of any size. You also run into database synchronization problems because of the separation of PLCs and the Man Machine Interface (MMI) software packages, as opposed to the central databases of DCSs. A PLC will run in a stand-alone configuration. A DCS controller normally expects an operator interface and communications, so it can send alarms, messages, trend updates, and display updates. Many PLC installations use interface software from third-party vendors for improved graphics and various levels of alarming, trending, and reporting. The PLC and MMI software normally interact by sitting on the network and using the register exchange mechanism to get data from and to the various PLCs. This type of communication presumes you have preassigned data registers and can fetch data on an absolute address basis. This can lead to data processing errors (e.g., from the wrong input) you won't encounter with the central database of a DCS. Some PLCs use proprietary networks, and others can use LANs. Either way, the communication functions are the same-fetch and put registers. This can result in bottlenecking and timing problems if too many PCs try communicating with too many PLCs over a network. A PLC may have a third-party package for operator interfaces, LAN interface to PCs and peripherals, PLC data highway or bus, redundant controllers with local and distributed I/O, local MMI and local programming capability. The PLC would have redundant media support, but not the redundant communication hardware or I/O bus hardware you'd find in a DCS. A PLC would have preprogrammed I/O cards for specific signal types and ranges.
Today, the decision between PLC and DCS often depends on business issues rather than technical features. Questions to consider are those involving: The internal expertise to execute the project, Level of support available from a vendor/integrator, Long-term maintainability, and Life-cycle costs. PLCs and DCSs overlap in their features, but also have distinct strengths and weaknesses. When deciding between the two, know who will deliver and support your system, and how they will do it.
Ladder logic can be thought of as a rule-based language, rather than a procedural language. A "rung" in the ladder represents a rule. When implemented with relays and other electromechanical devices, the various rules "execute" simultaneously and immediately. When implemented in a programmable logic controller, the rules are typically executed sequentially by software, in a loop. By executing the loop fast enough, typically many times per second, the effect of simultaneous and immediate execution is obtained. In this way it is similar to other rule-based languages, like spreadsheets or SQL. However, proper use of programmable controllers requires understanding the limitations of the execution order of rungs.
A Safety Instrumented Function SIF is defined as a Function to be implemented by a SIS, which is intended to achieve or maintain a safety state for the process with respect to a specific hazardous event"
RRF Risk Reduction Factor 100,000 to 10,000 10,000 to 1,000 1,000 to 100 100 to 10
PFD Probability of Failure on Demand pro year = 1/RRF >= 10-5 to < 10-4 >= 10-4 to < 10-3 >= 10-3 to < 10-2 >= 10-2 to < 10-1
--------------------------------------------------------------------------------
Safety integrity level (SIL) is a popular phrase used in the designing and outlaying of instruments; and this requires explanation. SIL is a statistical representation of the reliability of safety instrument systems. There are four categories, namely SILs 1, 2, 3 and 4. It is defined as the probability of the safety instrument system (SIS) to fail on demand (PFD). A process demand occurs whenever the process reaches the trip condition and causes the SIS to take action. Consider a tank filling with a process fluid. If the tank is full, the SIS comes into play as the trip conditions are reached. The SIS prevents the tank from overflowing. The number of times this occurs is known as the incident frequency. Consider an SIL 1 installation, which has a maximum probability level of 1 in 10. This means for every 10 times the SIS is activated as a result of a high tank level trip, the safety function (ie, the dump valve opens lowering the level) could be expected to work nine times. The other one time the safety function would not work and the tank would overflow. In SIL 2 this overflow probability would be one in a hundred as a worst-case scenario. The required SIL level in a particular process design and what actions should be taken to reduce the number of process demands is based on the perceived risk and tolerable incident frequency. This decision is taken when considering injuries, fatalities, environmental releases, property damage, plant equipment damage, permit violations and the plant's licence to operate. It is easy to understand the damage caused by the failure of a safety system to work properly, but it is more difficult to realise the true benefit when the safety system does what it is supposed to do. The SIL must be chosen to reduce the incident frequency (ie, tank overflow in the example above) to a tolerable level only. The standard IEC 61508 deals specifically with the functional safety of electrical, electronic and programmable electronic safety related systems. It is therefore a requirement for instrument manufacturers to supply relevant information to enable the use of their equipment by others in a SIS. This is done during the development of these devices and they must be validated following the demands of IEC 61508. A typical safety loop requires a SIL level, which is associated with a safety function - for example, preventing a tank from overflowing - and therefore is not associated with a standalone instrument or piece of equipment only. Thus, for a particular safety system, a SIL level is only obtained after analysing the whole safety loop.
10
In the figure, the dump valve must operate to prevent tank overflow. Safety isolators are used for explosion protection. The loop is broken down into individual blocks, in order to perform the safety function. All of the blocks have to be evaluated in order to obtain the required SIL level. It can be seen that IEC 61508 considers the total instrument loop. Much like 'a chain is only as strong as its weakest link', so too, all the elements in the instrument loop of the safety system play their part. SIL is mostly referred to as a performance criterion, which is the capability to perform at the time needed. The choice of SIL level is often decided by the cost of non-performance. This is difficult to accept ... especially at project budget meetings. No matter how SIL is referred to, or viewed, it can be seen as a good industry involvement toward safety system design. SIL level must therefore be decided upon to reduce incident frequency to a tolerable level only. SIL is the design basis for all engineering decisions related to the safety function. When the design is complete it must be validated against the SIL. Therefore SIL determines the design cycle where all risks are identified, requirements are quantified and final design is validated.
Saurabh
11