Vous êtes sur la page 1sur 11



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.

Compare PLC and DCS: What is the difference?

You must automate a process, but you can't decide between a DCS and a PLC. Are these systems really all that different? The answers depend on a slew of other questions. Turn the clock back 10-15 years: The programmable logic controller (PLC) is king of machine control while the distributed control system (DCS) dominates process control. If you manufacture plastic widgets, you speak PLC. If you produce chemicals, you speak DCS. Today, the two technologies share kingdoms as the functional lines between them continue to blur. We now use each where the other used to rule. However, PLCs still dominate high-speed machine control, and DCSs prevail in complex continuous processes. The early DCS looked dramatically different from the early PLC. Initially, the DCS performed the control functions of the analog panel instruments it replaced, and its interface mimicked their panel displays. DCSs then gained sequence logic capabilities to control batch processes as well as continuous ones. DCSs performed hundreds of analog measurements and controlled dozens of analog outputs, using multi-variable Proportional Integral Derivative (PID) control. With the same 8-bit microprocessor technology that gave rise to the DCS, PLCs began replacing conventional relay/solid-state logic in machine control. PLCs dealt with contact input/output (I/O) and started/stopped motors by performing Boolean logic calculations. The big change in DCS over the past 20 years is its move from proprietary hardware to the personal computer (PC) and standard LAN technologies. With each advance in PC power, DCSs have moved up in power. PCs gave us speedy, responsive, multi-media, windowed, operator-process interfaces (OPI). Relational databases and spreadsheet software enhance the ability of DCSs to store and manipulate data. Artificial intelligence (AI) technology gives us "smart" alarming. Today's DCS architecturally looks much like the DCS of 20 years ago, but tomorrow's DCS may control through networked "smart" devices-with no I/O hardware of its own. Most DCSs offer redundant controllers, networks, and I/Os. Most give you "built-in" redundancy and diagnostic features, with no need for userwritten logic.

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.

What is Ladder Logic?

Ladder logic is a method of drawing electrical logic schematics. It is now a graphical language very popular for programming Programmable Logic Controllers (PLCs). It was originally invented to describe logic made from relays. The name is based on the observation that programs in this language resemble ladders, with two vertical "rails" and a series of "rungs" between them. In Germany and elsewhere in Europe, the style is to draw the rails horizontal along the top and bottom of the page while the rungs are drawn sequentially from left to right. A program in ladder logic, also called a ladder diagram, is similar to a schematic for a set of relay circuits. Ladder logic is useful because a wide variety of engineers and technicians can understand and use it without much additional training because of the resemblance. Ladder logic is widely used to program PLCs, where sequential control of a process or manufacturing operation is required. Ladder logic is useful for simple but critical control systems, or for reworking old hardwired relay circuits. As programmable logic controllers became more sophisticated it has also been used in very complex automation systems. Most manufacturers of programmable logic controllers also provide associated ladder logic programming systems. Typically, the ladder logic languages from two manufacturers will not be completely compatible; ladder logic is better thought of as a set of closely related programming languages rather than one language. Even different models of programmable controller within the same family may have different ladder notation such that programs cannot be seamlessly interchanged between models.

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.

Safety Instrumented Systems

What is a Safety Instrumented System?
A Safety Instrumented System SIS is a new term used in standards like IEC 61511 or IEC 61508 for what used to be called Emergency Shutdown System ESD, Safety Shutdown System, Interlock System, Permissive Systems, etc. ... A Safety Instrumented System SIS consists of one or more Safety Instrumented Functions SIF. What is a Safety Instrumented Function SIF?

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"

What is a Safety Integrity Level SIL?

Safety Integrity Level SIL is a measure of risk reduction provided by a SIF based on four levels. Each level represents an order of magnitude of risk reduction. Every SIF has a SIL assigned to it, the SIS and equipment does not have a SIL assigned to it.

What is a Safety Integrity Level SIL?

Safety Integrity Level SIL is a measure of risk reduction provided by a SIF based on four levels. Each level represents an order of magnitude of risk reduction. Every SIF has a SIL assigned to it, the SIS and equipment does not have a SIL assigned to it.

SIL Safety Integrity Level SIL 4 SIL 3 SIL 2 SIL 1

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):

SIL determines the design cycle where all risks are identified, requirements are quantified and final design is validated. Safety instrument systems (SIS) has been a major design factor in all process plants for as long as the author can remember. This standard for application of SIS for process industries is based on international standards from the International Electro-technical Commission (IEC), namely IEC 61511 and IEC 61508. These identify an overall approach to the task of determining and applying safety within a process plant.

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.


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.