Tag Archives: SCADA

The Internet of Things outlook for 2014: Everything connected and communicating

The Internet of Things is more than Internet-connected refrigerators and shoes that tweet; it’s a new wave of enabling devices to become more ‘intelligent’ and our chance to become better informed about our businesses and the world around us.

By Ken Hess for Consumerization: BYOD | January 10, 2014 — 13:00 GMT (21:00 GMT+08:00) | Topic: Tapping M2M: The Internet of Things

Kevin Ashton, a British technology pioneer who co-founded the Auto-ID Center at MIT, which created a global standard system for RFID and other sensors, coined the phrase “Internet of Things” back in 1999. His Internet of Things (IoT) is a system where the Internet is connected to the physical world via ubiquitous sensors. And sensors can be any device that gathers data and reports that data to a data collection facility such as a data warehouse, a database, or log server.

IoT isn’t just a fancy buzzword that describes how your refrigerator can let you know when you need to replace your spoiling milk or your rotting vegetables (although it can), it is so much more. How much more is only left to your imagination and to your budget. You can do as little or as much with IoT as you want. For example, if you operate food distribution business, you could install sensors in your trucks that send temperature, humidity, and dock-to-dock travel times back to your home office for analysis. You can also more accurately track the exact expense required to deliver each food product or container to the customer.

The Internet of Things is not just about gathering of data but also about the analysis and use of data.

My best example of gathering and analysis of IoT data is the first instance of such a system: The Coke Machine at Carnegie-Mellon University’s Computer Science department, also known as the Internet Coke Machine.

One of the computer science students in 1982, David Nichols, had the original idea to poll the Coke machine so that he didn’t waste a trip to the machine to find it empty. He and a group of fellow students (Mike Kazar (Server Software), David Nichols (Documentation and User Software), John Zsarnay (Hardware), Ivor Durham (Finger interface) together to create this now famous connected vending machine.

From their labs, they could check the status of the sodas in the vending machine. I’m pretty sure they didn’t realize the international effect this would someday have when they devised their plan. Nor did they realize that anyone beyond themselves would care*.

It doesn’t matter that they were trying to save steps or that they were only trying to monitor the status of their favorite bubbly beverages**. But what really matters is that they did it. And they used the data. Their little experiment changed the way we look at “things” and the data that they can produce.

But serious IoT is coming to the world in a big way and has far reaching implications for big data, security, and cloud computing.

Big Data

So called “big” data is a buzzword that seems to eminate from the most unusual places these days. Mostly from the mouths and fingertips of people who haven’t a clue of what it means. What IoT means for big data is that the data from all these “things” has to be stored and analyzed. That is big data. If you look at some of the projections for the next few years, you’ll have an idea of what I mean.

Internet-connected cars, sensors on raw food products, sensors on packages of all kinds, data streaming in from the unlikeliest of places: restrooms, kitchens, televisions, personal mobile devices, cars, gasoline pumps, car washes, refigerators, vending machines, and SCADA systems for example will generate a lot of data (big data).

Security

Lots of devices chattering away to centralized databases also means that someone needs to watch the machine-to-machine (M2M) communications. Security is a major issue with IoT. However, several companies including Wind River have made great advances in IoT and M2M security.

Unfortunately, security for IoT is multilayered and expensive to implement. Strong security must exist in the three vulnerable layers: physical, network, and data. By physical, I mean the device itself must be secured with locks, tamper-proof housings, alarms, or out-of-reach placement. Physical security is a primary problem with IoT. Devices that are easily stolen or broken into pose the biggest threats.

Network communications must be secured by VPN or other form of encryption. Man-in-the-middle attacks are common for such devices and manufacturers need to make it difficult for would be attackers.

Data security poses a problem as well. First, there’s “data at rest” that’s stored locally on the device. Compromise of this information could proved detrimental to the rest of the network because it could reveal other device locations, network topology, server names, and even usernames and passwords. All data at rest should be encrypted to prevent this type of breach.

Second, there’s “data on the move” or “data in motion” which is covered in part by encrypted communications but what happens to the data after it lands on a target device, such as a data center server is also important. And the transfer of that data across a network should also be encrypted.

Encrypted devices, encrypted communications over the entire data path, and hardened physical devices make it very difficult to extract value from any recovered information. In fact, the purpose of this multilayered security is to make it far more expensive to glean usable data than the data itself would yield to the criminal or malicious hacker.

Cloud Computing

You might wonder how cloud computing fits into the IoT world because in the years before cloud computing we did just fine by having our devices report directly to a home server. Nowadays there’s so much more data to deal with from disparate sources that cloud computing can play a significant role in IoT scenarios.

For example, if you have a chain of restaurants spread out over a wide geographic area or worldwide, then your data streams in on a continuous basis. There’s never a good time for taking your services offline for maintenance. This is where cloud computing comes to the rescue.

Your ‘things’ can collect data 100 percent of the time with no breaks in service. If you purchase cloud storage, you can filter the data for extracted offload at your convenience. To me, IoT and cloud computing are the perfect technology marriage.

You won’t have to keep your ear too close to the ground in 2014 to hear about IoT. If you do, you’re just not listening. IoT isn’t a marketing term or tech buzzword, it’s a real thing. You should learn about it and how it can help your company learn more about itself. Seriously.

If you’re losing money on a particular part of your business, then IoT might resolve it for you with better controls, better tracking, and better reporting. Should security, big data, and the cloud computing connection prove to be too overwhelming for you, connect up with a company that knows something about IoT. And if you still don’t know where to start, just ask me by using the Author Contact Form.

What do you think about IoT and what it can do for your company? Talk back and let me know.

*If you care, you can read the recollected story from David Nichols and others.

**Admittedly, it would have been cool to do this with a Coke machine but it would have been far more enticing to me, if they’d also hooked up the snack machine to check the availability of Rice Krispies treats or gum. I love gum. I’m a gum freak. You’ve never seen anyone chew gum like I chew gum. I hope no one ever places gum on the list of endangered things. I might go unhappily extinct.

SCADA

From Wikipedia, the free encyclopedia

Supervisory control and data cquisition (SCADA) is a control system architecture that uses computers, networked data communications and graphical user interfaces for high-level process supervisory management, but uses other peripheral devices such as programmable logic controllers and discrete PID controllers to interface to the process plant or machinery. The operator interfaces which enable monitoring and the issuing of process commands, such as controller set point changes, are handled through the SCADA supervisory computer system. However, the real-time control logic or controller calculations are performed by networked modules which connect to the field sensors and actuators.

The SCADA concept was developed as a universal means of remote access to a variety of local control modules, which could be from different manufacturers allowing access through standard automation protocols. In practice, large SCADA systems have grown to become very similar to distributed control systems in function, but using multiple means of interfacing with the plant. They can control large-scale processes that can include multiple sites, and work over large distances. It is one of the most commonly-used types of industrial control systems, however there are concerns about SCADA systems being vulnerable to cyberwarfare/cyberterrorism attacks.

Contents
1 The SCADA concept in control operations
2 Examples of use
3 SCADA system components
3.1 Supervisory computers
3.2 Remote terminal units
3.3 Programmable logic controllers
3.4 Communication infrastructure
3.5 Human-machine interface
4 Alarm handling
5 PLC/RTU programming
6 PLC commercial integration
7 Communication infrastructure and methods
8 SCADA architecture development
8.1 First generation: “monolithic”
8.2 Second generation: “distributed”
8.3 Third generation: “networked”
8.4 Fourth generation: “Internet of things”
9 Security issues

The SCADA Concept in Control Operations


Functional_levels_of_a_Distributed_Control_System.svg

Functional levels of a manufacturing control operation

The key attribute of a SCADA system is its ability to perform a supervisory operation over a variety of other proprietary devices.

The accompanying diagram is a general model which shows functional manufacturing levels using computerised control.

Referring to the diagram,

  • Level 0 contains the field devices such as flow and temperature sensors, and final control elements, such as control valves.
  • Level 1 contains the industrialised input/output (I/O) modules, and their associated distributed electronic processors.
  • Level 2 contains the supervisory computers, which collate information from processor nodes on the system, and provide the operator control screens.
  • Level 3 is the production control level, which does not directly control the process, but is concerned with monitoring production and targets.
  • Level 4 is the production scheduling level.

Level 1 contains the programmable logic controllers (PLCs) or remote terminal units (RTUs).

Level 2 contains the SCADA software and computing platform. The SCADA software exists only at this supervisory level as control actions are performed automatically by RTUs or PLCs. SCADA control functions are usually restricted to basic overriding or supervisory level intervention. For example, a PLC may control the flow of cooling water through part of an industrial process to a set point level, but the SCADA system software will allow operators to change the set points for the flow. The SCADA also enables alarm conditions, such as loss of flow or high temperature, to be displayed and recorded. A feedback control loop is directly controlled by the RTU or PLC, but the SCADA software monitors the overall performance of the loop.

Levels 3 and 4 are not strictly process control in the traditional sense, but are where production control and scheduling takes place.

Data acquisition begins at the RTU or PLC level and includes instrumentation readings and equipment status reports that are communicated to level 2 SCADA as required. Data is then compiled and formatted in such a way that a control room operator using the HMI (Human Machine Interface) can make supervisory decisions to adjust or override normal RTU (PLC) controls. Data may also be fed to a historian, often built on a commodity database management system, to allow trending and other analytical auditing.

SCADA systems typically use a tag database, which contains data elements called tags or points, which relate to specific instrumentation or actuators within the process system according to such as the Piping and instrumentation diagram. Data is accumulated against these unique process control equipment tag references.

Examples of Use


1280px-Freer_Water_Control_and_Improvement_District_-_Diana_Adame

Example of SCADA used in office environment to remotely monitor a process

Both large and small systems can be built using the SCADA concept. These systems can range from just tens to thousands of control loops, depending on the application. Example processes include industrial, infrastructure, and facility-based processes, as described below:

Industrial processes include manufacturing, Process control, power generation, fabrication, and refining, and may run in continuous, batch, repetitive, or discrete modes.

Infrastructure processes may be public or private, and include water treatment and distribution, wastewater collection and treatment, oil and gas pipelines, electric power transmission and distribution, and wind farms.
Facility processes, including buildings, airports, ships, and space stations. They monitor and control heating, ventilation, and air conditioning systems (HVAC), access, and energy consumption.
However, SCADA systems may have security vulnerabilities, so the systems should be evaluated to identify risks and solutions implemented to mitigate those risks.

SCADA System Components


Scada_std_anim_no_lang

Typical SCADA mimic shown as an animation. For process plant, these are based upon the piping and instrumentation diagram.

791px-SCADA_schematic_overview-s.svg

A SCADA system usually consists of the following main elements:

Supervisory Computers

This is the core of the SCADA system, gathering data on the process and sending control commands to the field connected devices. It refers to the computer and software responsible for communicating with the field connection controllers, which are RTUs and PLCs, and includes the HMI software running on operator workstations. In smaller SCADA systems, the supervisory computer may be composed of a single PC, in which case the HMI is a part of this computer. In larger SCADA systems, the master station may include several HMIs hosted on client computers, multiple servers for data acquisition, distributed software applications, and disaster recovery sites. To increase the integrity of the system the multiple servers will often be configured in a dual-redundant or hot-standby formation providing continuous control and monitoring in the event of a server malfunction or breakdown.

Remote Terminal Units

Remote terminal units, also known as (RTUs), connect to sensors and actuators in the process, and are networked to the supervisory computer system. RTUs are “intelligent I/O” and often have embedded control capabilities such as ladder logic in order to accomplish boolean logic operations.

Programmable Logic Controllers [PLC]

Also known as PLCs, these are connected to sensors and actuators in the process, and are networked to the supervisory system in the same way as RTUs. PLCs have more sophisticated embedded control capabilities than RTUs, and are programmed in one or more IEC 61131-3 programming languages. PLCs are often used in place of RTUs as field devices because they are more economical, versatile, flexible and configurable.

Communication Infrastructure

This connects the supervisory computer system to the remote terminal units (RTUs) and PLCs, and may use industry standard or manufacturer proprietary protocols. Both RTUs and PLCs operate autonomously on the near-real time control of the process, using the last command given from the supervisory system. Failure of the communications network does not necessarily stop the plant process controls, and on resumption of communications, the operator can continue with monitoring and control. Some critical systems will have dual redundant data highways, often cabled via diverse routes.

Human-machine Interface

Scada_Animation.ogv

More complex SCADA animation showing control of four batch cookers

The human-machine interface (HMI) is the operator window of the supervisory system. It presents plant information to the operating personnel graphically in the form of mimic diagrams, which are a schematic representation of the plant being controlled, and alarm and event logging pages. The HMI is linked to the SCADA supervisory computer to provide live data to drive the mimic diagrams, alarm displays and trending graphs. In many installations the HMI is the graphical user interface for the operator, collects all data from external devices, creates reports, performs alarming, sends notifications, etc.

Mimic diagrams consist of line graphics and schematic symbols to represent process elements, or may consist of digital photographs of the process equipment overlain with animated symbols.

Supervisory operation of the plant is by means of the HMI, with operators issuing commands using mouse pointers, keyboards and touch screens. For example, a symbol of a pump can show the operator that the pump is running, and a flow meter symbol can show how much fluid it is pumping through the pipe. The operator can switch the pump off from the mimic by a mouse click or screen touch. The HMI will show the flow rate of the fluid in the pipe decrease in real time.

The HMI package for a SCADA system typically includes a drawing program that the operators or system maintenance personnel use to change the way these points are represented in the interface. These representations can be as simple as an on-screen traffic light, which represents the state of an actual traffic light in the field, or as complex as a multi-projector display representing the position of all of the elevators in a skyscraper or all of the trains on a railway.

A “historian”, is a software service within the HMI which accumulates time-stamped data, events, and alarms in a database which can be queried or used to populate graphic trends in the HMI. The historian is a client that requests data from a data acquisition server.

Alarm Handling


An important part of most SCADA implementations is alarm handling. The system monitors whether certain alarm conditions are satisfied, to determine when an alarm event has occurred. Once an alarm event has been detected, one or more actions are taken (such as the activation of one or more alarm indicators, and perhaps the generation of email or text messages so that management or remote SCADA operators are informed). In many cases, a SCADA operator may have to acknowledge the alarm event; this may deactivate some alarm indicators, whereas other indicators remain active until the alarm conditions are cleared.

Alarm conditions can be explicit—for example, an alarm point is a digital status point that has either the value NORMAL or ALARM that is calculated by a formula based on the values in other analogue and digital points—or implicit: the SCADA system might automatically monitor whether the value in an analogue point lies outside high and low- limit values associated with that point.

Examples of alarm indicators include a siren, a pop-up box on a screen, or a coloured or flashing area on a screen (that might act in a similar way to the “fuel tank empty” light in a car); in each case, the role of the alarm indicator is to draw the operator’s attention to the part of the system ‘in alarm’ so that appropriate action can be taken.

PLC/RTU Programming


“Smart” RTUs, or standard PLCs, are capable of autonomously executing simple logic processes without involving the supervisory computer. They employ standardized control programming languages such as under, IEC 61131-3 (a suite of 5 programming languages including function block, ladder, structured text, sequence function charts and instruction list), is frequently used to create programs which run on these RTUs and PLCs. Unlike a procedural language such as the C programming language or FORTRAN, IEC 61131-3 has minimal training requirements by virtue of resembling historic physical control arrays. This allows SCADA system engineers to perform both the design and implementation of a program to be executed on an RTU or PLC.

A programmable automation controller (PAC) is a compact controller that combines the features and capabilities of a PC-based control system with that of a typical PLC. PACs are deployed in SCADA systems to provide RTU and PLC functions. In many electrical substation SCADA applications, “distributed RTUs” use information processors or station computers to communicate with digital protective relays, PACs, and other devices for I/O, and communicate with the SCADA master in lieu of a traditional RTU.

PLC Commercial Integration


Since about 1998, virtually all major PLC manufacturers have offered integrated HMI/SCADA systems, many of them using open and non-proprietary communications protocols. Numerous specialized third-party HMI/SCADA packages, offering built-in compatibility with most major PLCs, have also entered the market, allowing mechanical engineers, electrical engineers and technicians to configure HMIs themselves, without the need for a custom-made program written by a software programmer. The Remote Terminal Unit (RTU) connects to physical equipment. Typically, an RTU converts the electrical signals from the equipment to digital values such as the open/closed status from a switch or a valve, or measurements such as pressure, flow, voltage or current. By converting and sending these electrical signals out to equipment the RTU can control equipment, such as opening or closing a switch or a valve, or setting the speed of a pump.

Communication Infrastructure and Methods


SCADA systems have traditionally used combinations of radio and direct wired connections, although SONET/SDH is also frequently used for large systems such as railways and power stations. The remote management or monitoring function of a SCADA system is often referred to as telemetry. Some users want SCADA data to travel over their pre-established corporate networks or to share the network with other applications. The legacy of the early low-bandwidth protocols remains, though.

SCADA protocols are designed to be very compact. Many are designed to send information only when the master station polls the RTU. Typical legacy SCADA protocols include Modbus RTU, RP-570, Profibus and Conitel. These communication protocols, with the exception of Modbus (Modbus has been made open by Schneider Electric), are all SCADA-vendor specific but are widely adopted and used. Standard protocols are IEC 60870-5-101 or 104, IEC 61850 and DNP3. These communication protocols are standardized and recognized by all major SCADA vendors. Many of these protocols now contain extensions to operate over TCP/IP. Although the use of conventional networking specifications, such as TCP/IP, blurs the line between traditional and industrial networking, they each fulfill fundamentally differing requirements. Network simulation can be used in conjunction with SCADA simulators to perform various ‘what-if’ analyses.

With increasing security demands (such as North American Electric Reliability Corporation (NERC) and critical infrastructure protection (CIP) in the US), there is increasing use of satellite-based communication. This has the key advantages that the infrastructure can be self-contained (not using circuits from the public telephone system), can have built-in encryption, and can be engineered to the availability and reliability required by the SCADA system operator. Earlier experiences using consumer-grade VSAT were poor. Modern carrier-class systems provide the quality of service required for SCADA.

RTUs and other automatic controller devices were developed before the advent of industry wide standards for interoperability. The result is that developers and their management created a multitude of control protocols. Among the larger vendors, there was also the incentive to create their own protocol to “lock in” their customer base. A list of automation protocols is compiled here.

OLE for process control (OPC) can connect different hardware and software, allowing communication even between devices originally not intended to be part of an industrial network.

SCADA Architecture Development


page1-464px-SCADA_C4ISR_Facilities.pdf

The United States Army’s Training Manual 5-601 covers “SCADA Systems for C4ISR Facilities”

SCADA systems have evolved through four generations as follows:

First generation: “monolithic”

Early SCADA system computing was done by large minicomputers. Common network services did not exist at the time SCADA was developed. Thus SCADA systems were independent systems with no connectivity to other systems. The communication protocols used were strictly proprietary at that time. The first-generation SCADA system redundancy was achieved using a back-up mainframe system connected to all the Remote Terminal Unit sites and was used in the event of failure of the primary mainframe system. Some first generation SCADA systems were developed as “turn key” operations that ran on minicomputers such as the PDP-11 series made by the Digital Equipment Corporation.

Second generation: “distributed”

SCADA information and command processing was distributed across multiple stations which were connected through a LAN. Information was shared in near real time. Each station was responsible for a particular task, which reduced the cost as compared to First Generation SCADA. The network protocols used were still not standardized. Since these protocols were proprietary, very few people beyond the developers knew enough to determine how secure a SCADA installation was. Security of the SCADA installation was usually overlooked.

Third generation: “networked”

Similar to a distributed architecture, any complex SCADA can be reduced to simplest components and connected through communication protocols. In the case of a networked design, the system may be spread across more than one LAN network called a process control network (PCN) and separated geographically. Several distributed architecture SCADAs running in parallel, with a single supervisor and historian, could be considered a network architecture. This allows for a more cost effective solution in very large scale systems.

Fourth generation: “Internet of things”

With the commercial availability of cloud computing, SCADA systems have increasingly adopted Internet of things technology to significantly improve interoperability , reduce infrastructure costs and increase ease of maintenance and integration . As a result, SCADA systems can now report state in near real-time and use the horizontal scale available in cloud environments to implement more complex control algorithms than are practically feasible to implement on traditional programmable logic controllers. Further, the use of open network protocols such as TLS inherent in the Internet of things technology, provides a more readily comprehensible and manageable security boundary than the heterogeneous mix of proprietary network protocols typical of many decentralized SCADA implementations.

This decentralization of data also requires a different approach to SCADA than traditional PLC based programs. When a SCADA system is used locally, the preferred methodology involves binding the graphics on the user interface to the data stored in specific PLC memory addresses. However, when the data comes from a disparate mix of sensors, controllers and databases (which may be local or at varied connected locations), the typical 1 to 1 mapping becomes problematic. A solution to this is data modeling, a concept derived from object oriented programming.

In a data model, a virtual representation of each device is constructed in the SCADA software. These virtual representations (“models”) can contain not just the address mapping of the device represented, but also any other pertinent information (web based info, database entries, media files, etc.) that may be used by other facets of the SCADA/IoT implementation. As the increased complexity of the Internet of things renders traditional SCADA increasingly “house-bound,” and as communication protocols evolve to favor platform-independent, service-oriented architecture (such as OPC UA), it is likely that more SCADA software developers will implement some form of data modeling.

Security Issues


SCADA systems that tie together decentralized facilities such as power, oil, gas pipelines, water distribution and wastewater collection systems were designed to be open, robust, and easily operated and repaired, but not necessarily secure. The move from proprietary technologies to more standardized and open solutions together with the increased number of connections between SCADA systems, office networks and the Internet has made them more vulnerable to types of network attacks that are relatively common in computer security. For example, United States Computer Emergency Readiness Team (US-CERT) released a vulnerability advisory warning that unauthenticated users could download sensitive configuration information including password hashes from an Inductive Automation Ignition system utilizing a standard attack type leveraging access to the Tomcat Embedded Web server. Security researcher Jerry Brown submitted a similar advisory regarding a buffer overflow vulnerability in a Wonderware InBatchClient ActiveX control. Both vendors made updates available prior to public vulnerability release. Mitigation recommendations were standard patching practices and requiring VPN access for secure connectivity. Consequently, the security of some SCADA-based systems has come into question as they are seen as potentially vulnerable to cyber attacks.

In particular, security researchers are concerned about:

  • the lack of concern about security and authentication in the design, deployment and operation of some existing SCADA networks
  • the belief that SCADA systems have the benefit of security through obscurity through the use of specialized protocols and proprietary interfaces
  • the belief that SCADA networks are secure because they are physically secured
  • the belief that SCADA networks are secure because they are disconnected from the Internet

SCADA systems are used to control and monitor physical processes, examples of which are transmission of electricity, transportation of gas and oil in pipelines, water distribution, traffic lights, and other systems used as the basis of modern society. The security of these SCADA systems is important because compromise or destruction of these systems would impact multiple areas of society far removed from the original compromise. For example, a blackout caused by a compromised electrical SCADA system would cause financial losses to all the customers that received electricity from that source. How security will affect legacy SCADA and new deployments remains to be seen.

There are many threat vectors to a modern SCADA system. One is the threat of unauthorized access to the control software, whether it is human access or changes induced intentionally or accidentally by virus infections and other software threats residing on the control host machine. Another is the threat of packet access to the network segments hosting SCADA devices. In many cases, the control protocol lacks any form of cryptographic security, allowing an attacker to control a SCADA device by sending commands over a network. In many cases SCADA users have assumed that having a VPN offered sufficient protection, unaware that security can be trivially bypassed with physical access to SCADA-related network jacks and switches. Industrial control vendors suggest approaching SCADA security like Information Security with a defense in depth strategy that leverages common IT practices.

The reliable function of SCADA systems in our modern infrastructure may be crucial to public health and safety. As such, attacks on these systems may directly or indirectly threaten public health and safety. Such an attack has already occurred, carried out on Maroochy Shire Council’s sewage control system in Queensland, Australia. Shortly after a contractor installed a SCADA system in January 2000, system components began to function erratically. Pumps did not run when needed and alarms were not reported. More critically, sewage flooded a nearby park and contaminated an open surface-water drainage ditch and flowed 500 meters to a tidal canal. The SCADA system was directing sewage valves to open when the design protocol should have kept them closed. Initially this was believed to be a system bug. Monitoring of the system logs revealed the malfunctions were the result of cyber attacks. Investigators reported 46 separate instances of malicious outside interference before the culprit was identified. The attacks were made by a disgruntled ex-employee of the company that had installed the SCADA system. The ex-employee was hoping to be hired by the utility full-time to maintain the system.

In April 2008, the Commission to Assess the Threat to the United States from Electromagnetic Pulse (EMP) Attack issued a Critical Infrastructures Report which discussed the extreme vulnerability of SCADA systems to an electromagnetic pulse (EMP) event. After testing and analysis, the Commission concluded: “SCADA systems are vulnerable to an EMP event. The large numbers and widespread reliance on such systems by all of the Nation’s critical infrastructures represent a systemic threat to their continued operation following an EMP event. Additionally, the necessity to reboot, repair, or replace large numbers of geographically widely dispersed systems will considerably impede the Nation’s recovery from such an assault.”

Many vendors of SCADA and control products have begun to address the risks posed by unauthorized access by developing lines of specialized industrial firewall and VPN solutions for TCP/IP-based SCADA networks as well as external SCADA monitoring and recording equipment. The International Society of Automation (ISA) started formalizing SCADA security requirements in 2007 with a working group, WG4. WG4 “deals specifically with unique technical requirements, measurements, and other features required to evaluate and assure security resilience and performance of industrial automation and control systems devices”.

The increased interest in SCADA vulnerabilities has resulted in vulnerability researchers discovering vulnerabilities in commercial SCADA software and more general offensive SCADA techniques presented to the general security community. In electric and gas utility SCADA systems, the vulnerability of the large installed base of wired and wireless serial communications links is addressed in some cases by applying bump-in-the-wire devices that employ authentication and Advanced Encryption Standard encryption rather than replacing all existing nodes.

In June 2010, anti-virus security company VirusBlokAda reported the first detection of malware that attacks SCADA systems (Siemens’ WinCC/PCS 7 systems) running on Windows operating systems. The malware is called Stuxnet and uses four zero-day attacks to install a rootkit which in turn logs into the SCADA’s database and steals design and control files. The malware is also capable of changing the control system and hiding those changes. The malware was found on 14 systems, the majority of which were located in Iran.

In October 2013 National Geographic released a docudrama titled American Blackout which dealt with an imagined large-scale cyber attack on SCADA and the United States’ electrical grid.

Industrial Control System

From Wikipedia, the free encyclopedia

Industrial control system (ICS) is a general term that encompasses several types of control systems and associated instrumentation used for industrial process control.

Such systems can range from a few modular panel-mounted controllers to large interconnected and interactive distributed control systems with many thousands of field connections. All systems receive data received from remote sensors measuring process variables (PVs), compare these with desired set points (SPs) and derive command functions which are used to control a process though the final control elements (FCEs), such as control valves.

The larger systems are usually implemented by Supervisory Control and Data Acquisition (SCADA) systems, or distributed control systems (DCS), and programmable logic controllers (PLCs), though SCADA and PLC systems are scalable down to small systems with few control loops. Such systems are extensively used in industries such as chemical processing, pulp and paper manufacture, power generation, oil and gas processing and telecommunications.

Contents
1 Discrete controllers
2 Distributed control systems
2.1 DCS structure
3 SCADA systems
4 Programmable logic controllers
5 History

Discrete Controllers


Industrial_PID_controllers_-_front_display

 

Panel mounted controllers with integral hard displays. The process value (PV), and setvalue (SV) or setpoint are on the same scale for easy comparison. The controller output CO is shown as MV (Manipulated variable) range 0-100%Smart_current_loop_positioner

A control loop using a discrete controller. Field signals are process variable (PV) from the sensor, and control output to the valve (the Final Control Equipment – FCE). A valve positioner ensures correct valve operation.

The simplest control systems are based around small discrete controllers with a single control loop each. These are usually panel mounted which allows direct viewing of the front panel and provides means of manual intervention by the operator, either to manually control the process or to change control setpoints. Originally these would be pneumatic controllers, a few of which are still in use, but nearly all are now electronic.

Quite complex systems can be created with networks of these controllers communicating using industry standard protocols, which allow the use of local or remote SCADA operator interfaces, and enable the cascading and interlocking of controllers. However, as the number of control loops increase for a system design there is a point where the use of a PLC or DCS system is more cost-effective.

Distributed Control Systems


A Distributed Control System (DCS) is a digital processor control system for a process or plant, wherein controller functions and field connection modules are distributed throughout the system. They are used when the number of control loops makes DCS more cost effective than discrete controllers, and enable a supervisory view over large industrial processes. In a DCS a hierarchy of controllers is connected by communication networks, allowing centralised control rooms and local on-plant monitoring and control.

The introduction of DCSs enables easy configuration of plant controls such as cascaded loops and interlocks, and easy interfacing with other computer systems such as production control and scheduling. It also enabled more sophisticated alarm handling, introduced automatic event logging, removed the need for physical records such as chart recorders, allowed the control racks to be networked and thereby located locally to plant to reduce cabling.

DCS Structure

Functional_levels_of_a_Distributed_Control_System.svg

Functional manufacturing control levels, DCS and SCADA operate on levels 1 and 2.

A DCS typically uses custom-designed processors as controllers, and uses either proprietary interconnections or standard protocols for communication.Input and output modules form the peripheral components of the system.

The processors receive information from input modules, process the information and decide control actions to be performed by the output modules. The input modules receive information from sensing instruments in the process (or field) and the output modules transmit instructions to the final control elements, such as control valves.

The field inputs and outputs can either be continuously changing analog signals e.g. 4~ 20mA dc current loop or 2 state signals that switch either “on” or “off”, such as relay contacts or a semiconductor switch.

DCS systems can normally also support such as Foundation Fieldbus, profibus, HART, Modbus, PC Link and other digital communication bus that carries not only input and output signals but also advanced messages such as error diagnostics and status signals.

SCADA Systems


Supervisory control and data acquisition (SCADA) is a control system architecture that uses computers, networked data communications and graphical user interfaces for high-level process supervisory management, but uses other peripheral devices such as programmable logic controllers and discrete PID controllers to interface to the process plant or machinery. The operator interfaces which enable monitoring and the issuing of process commands, such as controller set point changes, are handled through the SCADA supervisory computer system. However, the real-time control logic or controller calculations are performed by networked modules which connect to the field sensors and actuators.

The SCADA concept was developed as a universal means of remote access to a variety of local control modules, which could be from different manufacturers allowing access through standard automation protocols. In practice, large SCADA systems have grown to become very similar to distributed control systems in function, but using multiple means of interfacing with the plant. They can control large-scale processes that can include multiple sites, and work over large distances. It is one of the most commonly-used types of industrial control systems, however there are concerns about SCADA systems being vulnerable to cyberwarfare/cyberterrorism attacks.

Referring to the functional hierarchy diagram in this article:

Level 1 contains the PLCs or RTUs

Level 2 contains the SCADA software and computing platform.

The SCADA software exists only at this supervisory level as control actions are performed automatically by RTUs or PLCs. SCADA control functions are usually restricted to basic overriding or supervisory level intervention. For example, a PLC may control the flow of cooling water through part of an industrial process to a set point level, but the SCADA system software will allow operators to change the set points for the flow. The SCADA also enables alarm conditions, such as loss of flow or high temperature, to be displayed and recorded. A feedback control loop is directly controlled by the RTU or PLC, but the SCADA software monitors the overall performance of the loop.

Programmable Logic Lontrollers


663px-Siemens_Simatic_S7-416-3

Siemens Simatic S7-400 system in a rack, left-to-right: power supply unit (PSU), CPU, interface module (IM) and communication processor (CP).

PLCs can range from small “building brick” devices with tens of I/O in a housing integral with the processor, to large rack-mounted modular devices with a count of thousands of I/O, and which are often networked to other PLC and SCADA systems.

They can be designed for multiple arrangements of digital and analog inputs and outputs (I/O), extended temperature ranges, immunity to electrical noise, and resistance to vibration and impact. Programs to control machine operation are typically stored in battery-backed-up or non-volatile memory.

It was in the automotive industry in the USA that the PLC was created. Before the PLC, the control, sequencing, and safety interlock logic for manufacturing automobiles was mainly composed of relays, cam timers, drum sequencers, and dedicated closed-loop controllers. Since these could number in the hundreds or even thousands, the process for updating such facilities for the yearly model change-over was very time consuming and expensive, as electricians needed to individually rewire the relays to change their operational characteristics.

When digital computers became available, being general-purpose programmable devices, they were soon applied to control sequential and combinatorial logic in industrial processes. However these early computers required specialist programmers, and stringent operating environmental control for temperature, cleanliness, and power quality. To meet these challenges this the PLC was developed with several key attributes. It would tolerate the shop-floor environment, it would support discrete input and output, and it was easily maintained and programmed. Another option is the use of several small embedded controls attached to an industrial computer via a network. Examples are the Lantronix Xport and Digi/ME.

History


1280px-Kontrollrom_Tyssedal

A pre-DCS era central control room. Whilst the controls are centralised in one place, they are still discrete and not integrated into one system.

1280px-Leitstand_2

A DCS control room where plant information and controls are displayed on computer graphics screens. The operators are seated as they can view and control any part of the process from their screens, whilst retaining a plant overview.

Process control of large industrial plants has evolved through many stages. Initially, control would be from panels local to the process plant. However this required a large manpower resource to attend to these dispersed panels, and there was no overall view of the process. The next logical development was the transmission of all plant measurements to a permanently-manned central control room. Effectively this was the centralisation of all the localised panels, with the advantages of lower manning levels and easier overview of the process. Often the controllers were behind the control room panels, and all automatic and manual control outputs were individually transmitted back to plant in the form of pneumatic or electrical signals.

However, whilst providing a central control focus, this arrangement was inflexible as each control loop had its own controller hardware so system changes required reconfiguration of signals by re-piping or re-wiring. It also required continual operator movement within a large control room in order to monitor the whole process. With coming of electronic processors, high speed electronic signalling networks and electronic graphic displays it became possible to replace these discrete controllers with computer-based algorithms, hosted on a network of input/output racks with their own control processors. These could be distributed around the plant and would communicate with the graphic displays in the control room. The concept of “distributed control” was realised.

The introduction of distributed control allowed flexible interconnection and re-configuration of plant controls such as cascaded loops and interlocks, and easy interfacing with other production computer systems. It enabled sophisticated alarm handling, introduced automatic event logging, removed the need for physical records such as chart recorders, allowed the control racks to be networked and thereby located locally to plant to reduce cabling runs, and provided high level overviews of plant status and production levels. For large control systems, the general commercial name “Distributed Control System” (DCS) was coined to refer to proprietary modular systems from many manufacturers which had high speed networking and a full suite of displays and control racks which all seamlessly integrated.

Whilst the DCS was tailored to meet the needs of large industrial continuous processes, in industries where combinatoric and sequential logic was the primary requirement, the PLC (programmable logic controller) evolved out of a need to replace racks of relays and timers used for event-driven control. The old controls were difficult to re-configure and fault-find, and PLC control enabled networking of signals to a central control area with electronic displays. PLC were first developed for the automotive industry on vehicle production lines, where sequential logic was becoming very complex. It was soon adopted in a large number of other event-driven applications as varied as printing presses and water treatment plants.

SCADA’s history is rooted in distribution applications, such as power, natural gas, and water pipelines, where there is a need to gather remote data through potentially unreliable or intermittent low-bandwidth and high-latency links. SCADA systems use open-loop control with sites that are widely separated geographically. A SCADA system uses RTUs (remote terminal units, also referred to as remote telemetry units) to send supervisory data back to a control center. Most RTU systems always did have some limited capacity to handle local controls while the master station is not available. However, over the years RTU systems have grown more and more capable of handling local controls.

The boundaries between DCS and SCADA/PLC systems are blurring as time goes on. The technical limits that drove the designs of these various systems are no longer as much of an issue. Many PLC platforms can now perform quite well as a small DCS, using remote I/O and are sufficiently reliable that some SCADA systems actually manage closed loop control over long distances. With the increasing speed of today’s processors, many DCS products have a full line of PLC-like subsystems that weren’t offered when they were initially developed.

This led to the concept and realisation of a PAC – programmable automation controller – which is programmed in a modern programming language such as C or C++, – that is an amalgamation of these three concepts.

Industrial Control System

From Wikipedia, the free encyclopedia

Industrial control system (ICS) is a general term that encompasses several types of control systems and associated instrumentation used for industrial process control.

Such systems can range from a few modular panel-mounted controllers to large interconnected and interactive distributed control systems with many thousands of field connections. All systems receive data received from remote sensors measuring process variables (PVs), compare these with desired set points (SPs) and derive command functions which are used to control a process though the final control elements (FCEs), such as control valves.

The larger systems are usually implemented by Supervisory Control and Data Acquisition (SCADA) systems, or distributed control systems (DCS), and programmable logic controllers (PLCs), though SCADA and PLC systems are scalable down to small systems with few control loops. Such systems are extensively used in industries such as chemical processing, pulp and paper manufacture, power generation, oil and gas processing and telecommunications.

Contents
1 Discrete controllers
2 Distributed control systems
2.1 DCS structure
3 SCADA systems
4 Programmable logic controllers
5 History

Discrete Controllers


Industrial_PID_controllers_-_front_display

Panel mounted controllers with integral hard displays. The process value (PV), and setvalue (SV) or setpoint are on the same scale for easy comparison. The controller output CO is shown as MV (Manipulated variable) range 0-100%Smart_current_loop_positioner

A control loop using a discrete controller. Field signals are process variable (PV) from the sensor, and control output to the valve (the Final Control Equipment – FCE). A valve positioner ensures correct valve operation.

The simplest control systems are based around small discrete controllers with a single control loop each. These are usually panel mounted which allows direct viewing of the front panel and provides means of manual intervention by the operator, either to manually control the process or to change control setpoints. Originally these would be pneumatic controllers, a few of which are still in use, but nearly all are now electronic.

Quite complex systems can be created with networks of these controllers communicating using industry standard protocols, which allow the use of local or remote SCADA operator interfaces, and enable the cascading and interlocking of controllers. However, as the number of control loops increase for a system design there is a point where the use of a PLC or DCS system is more cost-effective.

Distributed Control Systems


A Distributed Control System (DCS) is a digital processor control system for a process or plant, wherein controller functions and field connection modules are distributed throughout the system. They are used when the number of control loops makes DCS more cost effective than discrete controllers, and enable a supervisory view over large industrial processes. In a DCS a hierarchy of controllers is connected by communication networks, allowing centralised control rooms and local on-plant monitoring and control.

The introduction of DCSs enables easy configuration of plant controls such as cascaded loops and interlocks, and easy interfacing with other computer systems such as production control and scheduling. It also enabled more sophisticated alarm handling, introduced automatic event logging, removed the need for physical records such as chart recorders, allowed the control racks to be networked and thereby located locally to plant to reduce cabling.

DCS Structure

Functional_levels_of_a_Distributed_Control_System.svg

Functional manufacturing control levels, DCS and SCADA operate on levels 1 and 2.

A DCS typically uses custom-designed processors as controllers, and uses either proprietary interconnections or standard protocols for communication.Input and output modules form the peripheral components of the system.

The processors receive information from input modules, process the information and decide control actions to be performed by the output modules. The input modules receive information from sensing instruments in the process (or field) and the output modules transmit instructions to the final control elements, such as control valves.

The field inputs and outputs can either be continuously changing analog signals e.g. 4~ 20mA dc current loop or 2 state signals that switch either “on” or “off”, such as relay contacts or a semiconductor switch.

DCS systems can normally also support such as Foundation Fieldbus, profibus, HART, Modbus, PC Link and other digital communication bus that carries not only input and output signals but also advanced messages such as error diagnostics and status signals.

SCADA Systems


Supervisory control and data acquisition (SCADA) is a control system architecture that uses computers, networked data communications and graphical user interfaces for high-level process supervisory management, but uses other peripheral devices such as programmable logic controllers and discrete PID controllers to interface to the process plant or machinery. The operator interfaces which enable monitoring and the issuing of process commands, such as controller set point changes, are handled through the SCADA supervisory computer system. However, the real-time control logic or controller calculations are performed by networked modules which connect to the field sensors and actuators.

The SCADA concept was developed as a universal means of remote access to a variety of local control modules, which could be from different manufacturers allowing access through standard automation protocols. In practice, large SCADA systems have grown to become very similar to distributed control systems in function, but using multiple means of interfacing with the plant. They can control large-scale processes that can include multiple sites, and work over large distances. It is one of the most commonly-used types of industrial control systems, however there are concerns about SCADA systems being vulnerable to cyberwarfare/cyberterrorism attacks.

Referring to the functional hierarchy diagram in this article:

Level 1 contains the PLCs or RTUs

Level 2 contains the SCADA software and computing platform.

The SCADA software exists only at this supervisory level as control actions are performed automatically by RTUs or PLCs. SCADA control functions are usually restricted to basic overriding or supervisory level intervention. For example, a PLC may control the flow of cooling water through part of an industrial process to a set point level, but the SCADA system software will allow operators to change the set points for the flow. The SCADA also enables alarm conditions, such as loss of flow or high temperature, to be displayed and recorded. A feedback control loop is directly controlled by the RTU or PLC, but the SCADA software monitors the overall performance of the loop.

Programmable Logic Lontrollers


663px-Siemens_Simatic_S7-416-3

Siemens Simatic S7-400 system in a rack, left-to-right: power supply unit (PSU), CPU, interface module (IM) and communication processor (CP).

PLCs can range from small “building brick” devices with tens of I/O in a housing integral with the processor, to large rack-mounted modular devices with a count of thousands of I/O, and which are often networked to other PLC and SCADA systems.

They can be designed for multiple arrangements of digital and analog inputs and outputs (I/O), extended temperature ranges, immunity to electrical noise, and resistance to vibration and impact. Programs to control machine operation are typically stored in battery-backed-up or non-volatile memory.

It was in the automotive industry in the USA that the PLC was created. Before the PLC, the control, sequencing, and safety interlock logic for manufacturing automobiles was mainly composed of relays, cam timers, drum sequencers, and dedicated closed-loop controllers. Since these could number in the hundreds or even thousands, the process for updating such facilities for the yearly model change-over was very time consuming and expensive, as electricians needed to individually rewire the relays to change their operational characteristics.

When digital computers became available, being general-purpose programmable devices, they were soon applied to control sequential and combinatorial logic in industrial processes. However these early computers required specialist programmers, and stringent operating environmental control for temperature, cleanliness, and power quality. To meet these challenges this the PLC was developed with several key attributes. It would tolerate the shop-floor environment, it would support discrete input and output, and it was easily maintained and programmed. Another option is the use of several small embedded controls attached to an industrial computer via a network. Examples are the Lantronix Xport and Digi/ME.

History


1280px-Kontrollrom_Tyssedal

A pre-DCS era central control room. Whilst the controls are centralised in one place, they are still discrete and not integrated into one system.

1280px-Leitstand_2

A DCS control room where plant information and controls are displayed on computer graphics screens. The operators are seated as they can view and control any part of the process from their screens, whilst retaining a plant overview.

Process control of large industrial plants has evolved through many stages. Initially, control would be from panels local to the process plant. However this required a large manpower resource to attend to these dispersed panels, and there was no overall view of the process. The next logical development was the transmission of all plant measurements to a permanently-manned central control room. Effectively this was the centralisation of all the localised panels, with the advantages of lower manning levels and easier overview of the process. Often the controllers were behind the control room panels, and all automatic and manual control outputs were individually transmitted back to plant in the form of pneumatic or electrical signals.

However, whilst providing a central control focus, this arrangement was inflexible as each control loop had its own controller hardware so system changes required reconfiguration of signals by re-piping or re-wiring. It also required continual operator movement within a large control room in order to monitor the whole process. With coming of electronic processors, high speed electronic signalling networks and electronic graphic displays it became possible to replace these discrete controllers with computer-based algorithms, hosted on a network of input/output racks with their own control processors. These could be distributed around the plant and would communicate with the graphic displays in the control room. The concept of “distributed control” was realised.

The introduction of distributed control allowed flexible interconnection and re-configuration of plant controls such as cascaded loops and interlocks, and easy interfacing with other production computer systems. It enabled sophisticated alarm handling, introduced automatic event logging, removed the need for physical records such as chart recorders, allowed the control racks to be networked and thereby located locally to plant to reduce cabling runs, and provided high level overviews of plant status and production levels. For large control systems, the general commercial name “Distributed Control System” (DCS) was coined to refer to proprietary modular systems from many manufacturers which had high speed networking and a full suite of displays and control racks which all seamlessly integrated.

Whilst the DCS was tailored to meet the needs of large industrial continuous processes, in industries where combinatoric and sequential logic was the primary requirement, the PLC (programmable logic controller) evolved out of a need to replace racks of relays and timers used for event-driven control. The old controls were difficult to re-configure and fault-find, and PLC control enabled networking of signals to a central control area with electronic displays. PLC were first developed for the automotive industry on vehicle production lines, where sequential logic was becoming very complex. It was soon adopted in a large number of other event-driven applications as varied as printing presses and water treatment plants.

SCADA’s history is rooted in distribution applications, such as power, natural gas, and water pipelines, where there is a need to gather remote data through potentially unreliable or intermittent low-bandwidth and high-latency links. SCADA systems use open-loop control with sites that are widely separated geographically. A SCADA system uses RTUs (remote terminal units, also referred to as remote telemetry units) to send supervisory data back to a control center. Most RTU systems always did have some limited capacity to handle local controls while the master station is not available. However, over the years RTU systems have grown more and more capable of handling local controls.

The boundaries between DCS and SCADA/PLC systems are blurring as time goes on. The technical limits that drove the designs of these various systems are no longer as much of an issue. Many PLC platforms can now perform quite well as a small DCS, using remote I/O and are sufficiently reliable that some SCADA systems actually manage closed loop control over long distances. With the increasing speed of today’s processors, many DCS products have a full line of PLC-like subsystems that weren’t offered when they were initially developed.

This led to the concept and realisation of a PAC – programmable automation controller – which is programmed in a modern programming language such as C or C++, – that is an amalgamation of these three concepts.