SCADA - Supervisory Control And Data Acquisition - is essentially a graphics front end for displaying data.

The data can be obtained over a communications network from simple I/O (Input/Output) blocks or from a DCS or from a PLC or from a network of PLCs. Most SCADA systems can provide archiving and trend plots of selected data. SCADA systems were originally "leg savers". That is, they didn't make any control decisions, they just collected the data and displayed it in a central location so you didn't have to walk around and collect the info. This is no longer true for most SCADA software, which has added alarming, PID, and control logic. DCS - Distributed Control System - were originally developed in the process industries, such as petrochemical refining. They were initially a way of linking many independent single loop PID controllers together to permit displaying process and tuning data at a central computer. The communications protocols were proprietary, and the systems were expensive. They were good with analog data, but not with discrete data, sequencing, timing, etc. PLC - Programmable Logic Controller - systems were originally developed for the manufacturing industry, particularly the automotive industry. They were developed to replace hard wired relay logic panels, and were strong on sequencing, timing, and if/then type discrete I/O based logic. Communications protocols, math functions, and analog I/O capabilities were added later as the market expanded. PLC communications protocols are generally open, or at least accessible by equipment and software from multiple suppliers. The distinction between PLC and DCS has blurred, and newer designs look similar in terms of hardware and software capabilities. DCS are generally still more expensive on small systems, but on large ones may be more economical. Use of one over the other is often dictated by the installed base and engineering familiarity in a given industry.

Dalam dunia control industri kebanyakan menggunakan sistem control seperti PLC, DCS maupun SCADA. Apa sih perbedaan PLC, DCS dan SCADA itu.?? PLC : Progammable Logic Control Biasanya digunakan untuk menangani industri dengan pengaturan input/output digital (on-off), dan yang membutuhkan adanya logic operation. Terutama digunakan untuk mengatur suatu relay, karena bekerja secara digital (on-off). Dituntut memiliki scanning time yang cepat dengan orde 1 milisecond.

DCS : Distributed Control System Biasanya digunakan untuk menangani process industry dengan parameter-parameter analog sebagai input/output. Memiliki scanning time yang lebih lambat (ada yang mencapai orde second) disbanding PLC. DCS dituntut untuk memiliki kehandalan yang lebih tinggi karena fungsinya yang digunakan sebagai controller dalam process industry yang penting. Biasanya untuk menangani proses yang kompleks, ditangani dengan mengkombinasikan kedua system dimana biasanya PLC dikontrol oleh DCS. PLC menangani proses yang butuh action cepat dan biasanya digital process, sedangkan DCS mengatur keseluruhan system terasuk PLC tadi. SCADA : Supervisory Control and Data Acquisition SCADA digunakan untuk dapat mengintegrasikan dan mengkomunikasikan antar sistem kendali. Bukan sebagai kendali proses secara langsung. SCADA lebih berfungsi sebagai sistem monitor dan akuisisi data secara terpusat, biasanya berada di level manajemen untuk mengamati hasil proses industri.
The goals of DCS and SCADA are quite different. It is possible for a single system to be capable of performing both DCS and SCADA functions, but few have been designed with this in mind, and therefore they usually fall short somewhere. It has become common for DCS vendors to think they can do SCADA because the system specifications seem so similar, but a few requirements paragraphs about data availability and update processing separates a viable SCADA system from one that would work OK if it weren't for the real world getting in the way. DCS is process oriented: it looks at the controlled process (the chemical plant or whatever) as the centre of the universe, and it presents data to operators as part of its job. SCADA is data-gathering oriented: the control centre and operators are the centre of its universe. The remote equipment is merely there to collect the data--though it may also do some very complex process control! A DCS operator station is normally intimately connected with its I/O (through local wiring, FieldBus, networks, etc.). When the DCS operator wants to see information he usually makes a request directly to the field I/O and gets a response. Field events can directly interrupt the system and advise the operator. SCADA must operate reasonably when field communications have failed. The 'quality' of the data shown to the operator is an important facet of SCADA system operation. SCADA systems often provide special 'event' processing mechanisms to handle conditions that occur between data acquisition periods.

There are many other differences, but they tend to involve a lot of detail. The underlying points are: SCADA needs to get secure data and control over a potentially slow, unreliable communications medium, and needs to maintain a database of 'last known good values' for prompt operator display. It frequently needs to do event processing and data quality validation. Redundancy is usually handled in a distributed manner. DCS is always connected to its data source, so it does not need to maintain a database of 'current values'. Redundancy is usually handled by parallel equipment, not by diffusion of information around a distributed database. These underlying differences prompt a series of design decisions that require a great deal more complexity in a SCADA system database and data-gathering system than is usually found in DCS. DCS systems typically have correspondingly more complexity in their process-control functionality. The company I work for has both DCS and SCADA products. The operator stations for each product line can use the same UNIX workstations. The systems share data (and thus form a composite SCADA/DCS system), but the SCADA database architecture is significantly different from the DCS data architecture, to the extent that the SCADA master station database looks to the DCS operators very much like some directly-connected DCS I/O. The DCS people are (of course) keen to simplify this to cut costs. However, they do not yet have a viable alternative for the mechanisms required in SCADA systems to have communications redundancy and data redundancy to provide the sort of SCADA system reliability that our customers expect. If you look at most customer's system requirements specifications, a careful analysis of the data collection and data quality requirements will indicate if SCADA-style or DCS-style systems are appropriate. In general: the more features a system provides the more it will cost, so if you do not need SCADA-type data gathering facilities it will usually be more economical to use a DCS-type system. If you do need these facilities, you will pay for them. The short answer: DCS and SCADA are still different things, it depends what the customer specifies as to which is appropriate for a particular installation. I hope this has clarified more than it has confused. Also, it is my opinion based on my own experiences with DCS and SCADA. Others may have experience with systems that are designed to provide full SCADA and full DCS functionality in the one system. However, he has only briefly touched on an area which I consider to be one of the major differences between SCADA and DCS systems, especially so for the smaller SCADA systems and single-site SCADA HMIs in comparison to DCS systems. This relates to the alarming and eventing philosophies of the two differing applications. To put in very simplistic terms, a SCADA system is event driven, while a DCS is process state driven. A DCS is primarily interested in process trends, a SCADA system in process events.

A SCADA master station or HMI system generally considers changes of state (both status points and analogue changes leading to alarms) as the main criteria driving the data gathering and presentation system. Any undetected changes of state simply cannot be missed. This is reflected firstly in the field devices which are biased to the rapid scanning of digital inputs, and secondly at the protocol level where transmittal of changes of state (COSs) and sequence of events (SOEs) are generally given higher priority than analogue scans. SCADA software is event driven. A change of state will cause the system to generate all alarms, events, database updates and any special processing required relating to that change directly from the recognition of that change (including any analogue alarms). Event lists and alarm lists are of major importance to the operator, sometimes more so than data screens. Filtering of these lists is often quite complex, allowing displays sorted by plant/system area and alarm/event category/importance. Configuring alarms and events for points is relatively easy, as such attributes are usually added by default when a point is added to a SCADA system database. On the down side, the display of process data can be neglected by system manufacturers. It can be difficult to draw and configure system displays, and graphics can be dismal, although modern operating systems with off the shelf display packages are overcoming this. Conversely, DCS systems and process control system based SCADA HMIs are state based and consider the process variable's present and past states to be the main criteria driving the DCS. (PLC) protocols are generally register scanning based, with no specific change of state processing provided. Should a point toggle between scans, it will not be seen by the DCS. If any change of states are critical (as some would be for a DCS used for SCADA applications), a point must be latched on until it is confirmed it has been scanned, which can be difficult and non-deterministic. Field devices do not scan points as rapidly, but may be able to present them to the DCS in an overall faster time. DCS software tasks are generally run sequentially, rather than event driven. Therefore alarms or events are not generated when a point changes state, but when that particular process is run. Events and alarm lists are secondary in importance to the process displays, and filtering may not be as complex and flexible. Configuring points is a separate task, with points requiring alarms and events needing to be configured in a separate action. On the up side, the generation and display of data, especially analogue trends and standard process blocks, is far more user friendly and easier for both operator and engineer. Of course there are many exceptions to these generalities, and many DCS manufacturers have produced systems to deal with COSs (both by producing event driven base systems and "special" COS description alarming), and similarly there are SCADA systems with greater data acquisition and process control capability. It really does come down to the user being able to define system requirements accurately, as Andrew has written in his last few paragraphs.

Vendors can usually provide a system fully meeting any customer's requirements, however the requirements may lead to a DCS or SCADA with high customisation, this may add significant cost and complexity, for features which are not necessarily required. The value of relevant system requirements and specifications that both reflect all of a customer's internal requirements, and can be met with systems commercially available cannot be overstated. That's where companies like SKM can provide services to clients, offering independent knowledge using SCADA/Automation staff with many years expedience, from both user and vendor backgrounds. It our responsibility to carefully consider the cost consequences to the client of overspecifiying features that are functionally inappropriate. A few well meaning but ill chosen functions can lead to dramatic capital cost increases with little operational benefit.