The definition of SCADA is ‘Supervisory Control and Data Acquisition’.
SCADA refers to a system that collects data from various sensors at a factory, plant or in other remote locations and then sends this data to a central computer which then manages and controls the data. SCADA systems are used not only in industrial processes: e.g. steel making, power generation (conventional and nuclear) and distribution, chemistry, but also in some experimental facilities such as nuclear fusion. It’s providing overall control remotely from a SCADA Host software platform.
SCADA Host platforms also provide functions for graphical displays, alarming, trending and historical storage of data. The size of such plants ranges from a few 1000 to several 10000 Input Channels and Output Channels.
Overall Four type of SCADA Levels, these being:
- Field instrumentation
- PLCs and/or RTUs
- Communications Networks
- SCADA Host software
1. Field Instrumentation:
Field instrumentation is a key component of a safe and optimized control system. Traditionally, pumps and their corresponding operational values would have been manually controlled i.e. an operator would start/stop pumps locally and valves would have been opened/closed by hand. Slowly over time, these instruments would have been fitted with feedback sensors, such as limit switches, providing connectivity for these wired devices into a local PLC or RTU, to relay data to the SCADA host software.
Although today’s instrumentation technician requires more technical knowledge and the ability to design, install and maintain equipment, than in the past, this is the reduced cost in automating processes and higher technical skills held by personnel. Today, most field devices such as valves have been fitted with actuators, enabling a PLC or RTU to control the device rather than relying on manual manipulation. This capability means the control system can react more quickly to optimized production or shut down under abnormal events. The requirement is that the instrument must be designed for the location or area in which it has been placed.
Many types of instrumentation are designed for extremes of hot and cold. If the instrumentation is not designed for these temperatures, an artificial environment within a cabinet or some sort of building is required. This comes at an extra cost not just in initial design but also for ongoing maintenance. Instrumentation must also common with any EMC expands are electromagnetic compatibility standards which may be in place, to ensure that an electrical device does not have any undesirable effects upon its environment or other electrical devices.
2. PLCs & or RTU’s:
Programmable Logic Controllers (PLCs) and Remote Telemetry Units (RTUs) Used to be different devices but over time they are now almost the same. If we go back 30 years, an RTU was a ‘dumb’ telemetry box for connecting field instruments. The RTU would ‘relay’ the data from the instruments to the SCADA host without any processing or control but had well-developed communication interfaces or telemetry. In the 1990s control programming was added to the RTU so it operated more like a PLC.
A further development of devices in the field is to offer a specific application that could incorporate a number of instruments and devices with an RTU/PLC, incorporating technology sets to provide an ‘off the shelf approach to common process requirements, E.g. gas well production that includes elements of monitoring, flow measurement and control that would extend as an asset into the SCADA Host.
In terms of environmental and regulatory compliance, PLCs and RTUs have the same type of requirements as instrumentation in that they operate in the same environment. However, PLCs have traditionally not been as environmentally compliant as RTUs. This is mainly due to the fact that PLCs were designed to operate in areas, such as factory floors, where the environment was already conditioned to some degree.
3. Communication Networks:
The communication network is necessary to relay data from remote RTU/PLCs, which are out in the field the pipeline, to the SCADA host Located at the field office or central control centre. How well a SCADA system can manage communication to remote assets is fundamental to how successful the SCADA system is. Twenty years ago the communication network would have been leased lines or dial-up modems which were very expensive to install and maintain, but in the last 10-15 years, many users have switched to radio or satellite communications to reduce costs and eliminate the problematic cabling issues. More recently, other communication types have been made available that include cellular communications and improved radio devices that can support greater communication rates and better diagnostics.
However, the fact that these types of communication media are still prone to failure is a major issue for modern, distributed SCADA systems. At the same time as the communication medium changed so too did the protocols. Protocols are electronic languages that PLCs and RTUs use to exchange data, either with other PLCs and RTUs or SCADA Host platforms. Protocols have been proprietary and the product of a single manufacturer. As a further development, many manufacturers gravitated to a single protocol, MODBUS, but added on proprietary elements to meet specific functionality requirements.
For the Oil & Gas industry, there are a number of variants of MODBUS, including but not limited to, MODBUS ASCII, MODBUS RTU, Enron MODBUS, and MODBUS/TCP. This provided a communication standard for the retrieval of flow or process data from a particular RTU or PLC. This incremental development in using MODBUS protocol variants was seen as an improvement. A good example is how historical flow data is retrieved from an RTU/PLC by a SCADA Host. However, the advancement of SCADA Host software, and in some cases the sharing of protocol languages.
In recent years, protocols have appeared that are truly non-proprietary, such as DNP (Distributed Network Protocol). These protocols have been created independently of any single manufacturer and are more of an industry standard; Many individuals and manufacturers have subscribed to these protocols and Contributed to their development. Consequently, the oil and gas market is still heavily invested in MODBUS variants. As the benefits of these protocols become more apparent to users, it is expected that they will be more accepted and become a component of standard solutions provided specifically for oil and gas markets.
4. SCADA Host Software:
Traditionally, SCADA Host software has been the mechanism to view graphical displays, alarms, and trends. Control from the SCADA Host itself only became available when control elements for remote instruments were developed. These systems were isolated from the outside world and were the domain of operators, technicians, and engineers. Their responsibility was to monitor, maintain and engineer processes and SCADA elements. With advancements in Information Technology (IT) this is no longer the case. Many different stakeholders now require real-time access to the data that the SCADA Host software generates.
Accounting, maintenance management, and material purchasing requirements are performed or partly performed from data derived from the SCADA system. Consequently, there is a drive for the SCADA Host to be an Enterprise entity providing data to a number of different users and processes. This has encouraged SCADA Host software development to adopt standards and mechanisms to support interfacing to these systems. It also means that IT, traditionally separated from SCADA systems, is now involved in helping to maintain networks, database interfacing and user access to data.
Many of the initial SCADA Host products were developed specifically for the Manufacturing environment where a SCADA system resided within a single building or complex and did not possess many of the telemetry communication Features required by SCADA systems for geographically distributed assets.
These types of 1st-generation SCADA Hosts often required a hybrid PLC or RTU, called a Front End Driver (FED) or Front End Processor (FEP), to be used for handling communications with remote devices. This resulted in a number of disadvantages as it required specialized programming, external to the SCADA Host platform, and created a communications bottleneck.
Although multiple FED or FEP devices resolved some of this, there were extra costs and difficulties in creating and maintaining them due to their specialized nature. Modern SCADA software that encapsulates telemetry functionality no longer requires these types of hybrid PLCs for communications.
They now use software programs called ‘drivers’ that are integrated into the SCADA Host itself. Software drivers contain different types of protocols to communicate with remote devices such as RTUs and PLCs. As technology developed, SCADA Host software platforms were able to take advantage of many new features. These included the development of integral databases specifically designed for SCADA Host software requirements, being able to handle thousands of changes a second, for really large systems, yet still, conform to standard database interfacing such as Open Database Connectivity (ODBC) and Object Linking and Embedding for Databases (OLE DB). These standards are required so that third-party databases can access data from the
SCADA Host software. Remote client access to the SCADA Host is another technology that has enabled users to operate and monitor SCADA systems while on the move between or at other locations. There is a drive towards operational safety for SCADA Host systems within the oil and gas industry. 49 CFR 195.446 Control Room Management regulations look at SCADA Host software and how it functions in terms of operations, maintenance, and management. It also covers the degree of integration of the SCADA system itself and its use of open architecture and standards.
Security:
Security for SCADA systems has in recent years become an important and hotly debated topic. Traditionally SCADA systems were isolated entities that were the realm of operators, engineers, and technicians. This has meant that SCADA Host platforms were not necessarily developed to have protected connections to public networks. This left many SCADA host platforms open to attack as they did not have the tools necessary to protect themselves.
In terms of remote assets communicating back to a SCADA Host, security has been an issue for many years with numerous documented attacks on SCADA systems. However, it’s only been in recent years that an open standard has been produced to provide secure encrypted and authenticated data exchanges between remote assets and a SCADA Host platform. Solutions for remote asset and SCADA host communication security have very different requirements. Security has to also be viewed overall, and not just in terms of the SCADA system itself.
For example, if somebody wanted to disrupt production, they would not necessarily need to access the SCADA system to do this. If a gas wellhead site or a monitoring point on a gas pipeline is remotely situated, it could be easily compromised by a trespasser. If the asset is critically important, other solutions that may or may not form part of the SCADA system itself would have to be considered. e.g. camera surveillance security.
A large number of unauthorized accesses to a SCADA system come not from or at the remote assets themselves but through the SCADA Host or computers used to access the SCADA system for diagnostic or maintenance purposes. For example, the recent attack using the Stuxnet virus was introduced via a thumb drive on a computer used to access a SCADA system.
There are a number of standards available that describe how to secure a SCADA system, not just in terms of the technology employed, but in terms of practices and procedures. This is very important since the security solution to SCADA is not a technological silver bullet, but a series of practices and procedures in conjunction with technological solutions. These practices and procedures would include items of training, SCADA Host access, and procedures to follow when SCADA security has been compromised.
In modern SCADA systems, IT departments are integral to implementing and maintaining SCADA security for an organization and should be included in setting up practices, procedures and implementing technologies.
