SCADA deployment using OPC

By Randy Kondor, B.Sc. Eng. CompESCADA DEPLOYMENT using OPC SCADA deployment can effectively use OPC provided that the driver’s SCADA engine properly handles the unique SCADA communication requirements. Traditionally, SCADA (Supervisory Control and Data Acquisition) deployment has always used proprietary software applications and drivers to enable control centers to effectively manage the large amount of data collected. With the introduction of OPC, there have been various attempts at applying industrial standards to these SCADA based implementations. To help these attempts succeed and avoid significant cost overruns, integrators must differentiate between “plant-based” OPC mentality and SCADA applications. SCADA is Different from Manufacturing Manufacturing plants are typically confined to a small geographical area, and are usually less than a square mile. This includes businesses such as Pulp & Paper, Petrochemicals, Refineries, Automotive, etc. Their communication methods normally use reliable Ethernet or serial mediums, and frequently use a DCS and/or PLCs to control their process. In sharp contrast, SCADA applications cover very large geographical regions, frequently measured in the hundreds or thousands of square miles. These enterprises include: pipelines, oil gathering fields, electrical transmission utilities, water/wastewater, etc. As a result, they usually prefer satellite, radio, or modem communication, and typically rely on RTUs for their control. From a driver perspective, the biggest difference between Plant and SCADA implementations is the communication. (While hybrid plants exist, we only cover the pure SCADA concepts, which can then be easily transferred to hybrid plants.) Due to their confined geographical nature, Manufacturing Plants typically use a robust and reliable Ethernet backbone, which are usually installed in electrically quiet (i.e. little noise) locations. Bandwidth, from 9600 bps to Gigabit networks, is plentiful. They are also able to use a relatively small number of PLCs and DCSs, as the wires can economically reach all the necessary equipment, sensors, actuators, etc. On the other hand, due to their large coverage area, SCADA enterprises rely on noisy telemetry (wireless) or telephone (leased) line communication. Consequently, they also use lower communication speeds (300 – 9600 bps), and a very large number of RTUs, frequently numbering in the hundreds or even thousands. OPC Servers for SCADA applications must take these factors into account. They must optimize their communication to allow for extra noise, low bandwidth and a large device count. They must also handle their priority of operations differently than in a plant. Finally, the SCADA Master (the OPC Client application) must behave slightly differently to help the OPC server behave properly. Noisy CommunicationNoisy communication is the hallmark of SCADA operations. Invalid packets are very common, and extra bits often slip into the packets due to radio squelch. It is important for SCADA servers to differentiate between an invalid data packet as indicated by a bad CRC, and packets that are invalid due to radio squelch. In the former, the read must be performed again. But, if the SCADA server recognizes the latter (extra bits after a good CRC is detected), it can easily cleanup the data by simply ignoring the extra bits. This data cleansing enables the SCADA server to avoid extra reads where they are not required, and save on precious bandwidth. OPC enables the servers to have a dynamically configurable number of retries. Users can specify the number of retries that are acceptable in their specific situations.Large RTU Count A large number of RTUs is also a signature aspect of SCADA applications. While plant-based drivers rarely connect to more than a few PLCs simultaneously, SCADA servers frequently connect to tens or even hundreds or RTUs. SCADA servers must usually share a single connection amongst many RTUs, resulting in a connect-read-disconnect operation. SCADA server must be very efficient in their connection and disconnection procedures. As well, they must adhere to a dynamic polling sequence that enables them to read data from all the devices in a round-robin polling sequence, and also be able to interrupt the sequence with a higher priority write operation. Once the interruption is complete, the SCADA server must resume its regularly scheduled polling sequence. OPC uses a timestamp to indicate the last time that a given value was read. This enables users to easily tell if they should interrupt the polling sequence to refresh their data, or if their data is at an acceptable age. This reduces the number of interruptions to the SCADA server, and reduces system load. Low Bandwidth Low Bandwidth communication plagues SCADA operations. Unlike in Plants, SCADA bandwidth is at a premium. Due to telephone and telemetry limitations such as distance, weather, radio noise, and other conditions, bandwidth usually remains at a meager 300bps to 9600bps. Communication between the SCADA Master and the associated RTUs must be reduced to minimum levels. It is extremely important that the OPC Server be able to differentiate between the two OPC read types: cache and device read requests. A “cache read” enable the SCADA Master to read the data in the OPC Server’s existing buffer. Cache reads are used in slow processes where the absolute latest values are not required. The advantage is a very fast response from the OPC server, and causes no polling sequence interruption of the RTUs. To get the latest values from the RTU, the SCADA Master must issue a “device read.” A device read causes the OPC Server to stop its regular round-robin polling sequence, and retrieve data from the selected RTU. The advantage of a “device read” is that it provides the most recent values, however, it takes more time to execute, and slows down the entire system’s performance. Thus, the differentiation between cache and device reads will save the SCADA system from resource-hogging reads. This difference also enables the OPC server to implement priority of operations, which are of interest especially when timely data is required, such as in AGA (American Gas Association) reads. OPC Servers are not a Commodity Although OPC makes it possible to handle the specific issues posed by SCADA operations, the actual feature implementation is left up to the software developers, so it naturally follows that OPC SCADA servers are not created equal. Sophisticated buyers will research their requirements, and ask for them explicitly. Unfortunately, OPC servers that work well in a plant environment do not necessarily work well in SCADA applications. For instance, a simple search on the Internet will reveal many OPC servers that support the popular Modbus protocol; but only a small percentage actually supports Modbus for use in SCADA. Some vendors even offer separate OPC servers for plant and SCADA purposes, so check with your OPC vendor to ensure you are getting what you require. Thus, OPC and SCADA can be highly compatible concepts. Integrators must carefully research and plan their projects to be successful. The SCADA applications are more difficult to support than their plant-based cousins, since they require special provisions for low bandwidth and noisy communication with a multitude of devices. But, when these requirements are fulfilled, integrators can effectively deploy OPC servers in a SCADA environment.