Building a perfect industrial telemetry system

This article explores the challenges of developing telemetric SCADA systems and covers the seven most important features to look for in selecting a GPRS solution.

SCADA systems promise tremendous efficiency and reliability advantages for remote industrial operations, but their implementation can seem a daunting challenge. Telemetry and wireless technologies have made monitoring systems possible in applications that were previously too remote or distributed for conventional cabling. However, in building or expanding a wireless system, system integrators must confront new and possibly unfamiliar technologies and challenges.

An archetypical SCADA application

This article will use a hypothetical pipeline system to illustrate the various problems and decisions involved in creating a remote SCADA system. The same telemetric technologies and solutions used in this pipeline system are equally relevant to distributed industrial applications or any other system that requires the remote monitoring and control of many devices.

A pipeline system is used to transmit liquids such as water, oil, natural gas and pulp over long distances. There are usually many pipeline control and monitoring points distributed throughout the length of the system. The remote monitoring system collects data from these points regarding pipeline pressure, flow rate and other real-time information and transmits it to the control centre.

Challenges in deploying a remote SCADA system

By definition, a pipeline system will span substantial physical distances in order to fulfil its function, and the various data acquisition and control points are distributed throughout the length of the pipe in the field. This presents obvious difficulties for a wired communications solution - paving, wiring and leasing lines from telecom carriers can quickly escalate costs to prohibitive sums. The dial-up process will be slow and operating costs of maintaining the lines will be high. Finally, geographical limitations may make it outright impossible to deliver wires to certain locations. Wired communications is simply unsuitable for a distributed remote SCADA system such as a pipeline.

In contrast, a GPRS communications system is very flexible. It requires less investment in capital or deployment time and is easier to maintain for greater overall cost-effectiveness. However, even with the convenience of GPRS-powered communications, every SCADA system is complex. Multiple field devices, such as a pipeline system’s flowmeters, pressure gauges, thermometers and water quality analysers, must be integrated and reliably monitored. In order to build or maintain a resilient, stable and long-lasting system, developers need to possess a broad set of skills, including an understanding of wireless communications, control procedures, communications protocol conversions and how to write control system software.

A typical GPRS system

A typical GPRS system can be divided into three major components: the site equipment and devices located in the field, the monitoring host computer located at the control centre and finally, an additional SMS connection for mobile alerts.

Figure 1: A typical GPRS SCADA system.

The first section, often referred to as the ‘remote terminal’ or ‘front end’, includes the devices in the field, such as instruments and data acquisition devices. These devices are then connected to I/O modules and processed by a programmable logic controller (PLC) located on the field, which is a bridge between the field devices and the control centre. The PLC control and monitoring terminal collects status data and is responsible for communications and automation, as well as sending out alarm messages when preset parameters are met. As the remote field sites are generally unmanned, terminal performance and resilience are important factors in the overall reliability of the system. Finally, a GPRS modem connects these field devices wirelessly with the rest of the system.

The second part of the system, often referred to as the ‘SCADA software’ or ‘back end’, is the control centre where the host computer monitors and evaluates the data constantly arriving wirelessly from the field.

The final part of the system is the real-time alarm component, which gives the system an additional means with which to keep system operators constantly aware of the pipeline’s status wherever they are. Deploying an SMS alarm system ensures that system operators will be notified of urgent information via SMS messages even if they are not in the control centre.

Common GPRS hurdles

Once deployed, a SCADA system using GPRS is an invaluable tool to improve the reliability, efficiency and safety of a pipeline network. However, there are substantial hurdles to overcome before a GPRS SCADA network is up and running smoothly. For example, GPRS communications present unique connectivity issues, as often only dynamic IP addresses are available for GPRS devices. The bandwidth consumption of the GPRS network must also be controlled to minimise access charges.

Additionally, the plethora of different devices at a field site can quickly create overwhelming development costs - the many system components at the field site must all be configured and tested so that they communicate seamlessly. For example, just the connection between the PLC and the GPRS modem requires the appropriate settings, driver and interface before it is functional. Specific development is also required for the PLC’s connection with each of the various I/O devices used: alarms, control equipment, data acquisition and data storage. Even after all this development is complete, it is still necessary to conduct thorough integration testing to ensure that the system runs smoothly as a whole.

Towards integrated solutions: seven key things to look for

Increasingly, system builders are responding to the hurdles outlined above by turning to integrated all-in-one GPRS solutions - remote terminal units (RTUs). By combining multiple front-end functions, including the GPRS modem, alarm, PLC, data logger and device I/O on one device, an integrated solution can reduce the complexity of a GPRS system and consequently offer substantial efficiency and reliability advantages. However, not all RTUs are created equal. Before selecting an all-in-one GPRS device, make sure that the product can deliver the following seven key features.

Figure 2: Integrated GPRS SCADA solution.

Flexible and efficient client-host communications

An RTU that allows fine-tuning of its communications behaviour will allow users to consume precisely the amount of bandwidth needed - no more and no less. This conserves network usage and reduces GPRS service charges.

Broadly speaking, client-host communications can be divided into two categories. In a polling architecture, the host computer will send queries to each remote terminal in turn and receive data in response. In an active or push architecture, clients will initiate contact with the host. This can be set to trigger on the occurrence of specific events.

A polling architecture results in consistent and predictable host-client communications and has been very common in industrial automation in the past. There are a number of different protocols for its implementation, such as Modbus/TCP and Profibus. However, in a GPRS environment there are additional considerations that alter the assessment of network architectures. Compared to a wired network, the data transfer rate of a GPRS network is relatively low, with a theoretical peak of 172.2 kbps and about 20 to 40 kbps available in general use. Additionally, in GPRS networks the IP address of terminal equipment is often not fixed.

Figure 3: Passive polling architecture versus active push architecture.

In this environment the polling architecture’s shortcomings become apparent. In order for the host to access the client terminal, it must have a fixed IP address. Workarounds for this issue, such as a VPN, dynamic domain name resolution and public fixed addresses, are problematic, an additional cost and limited by carrier availability. Also, if the interval between polling queries to each client is set too long, then the cycle may miss important events until it is too late. However, if the interval is set too short, then responses could be lost with constant reconnections.

An active or push architecture is well suited for GPRS networks, and a flexible active architecture is a key component of an effective RTU. The client takes the initiative to connect to the host computer, so only the host computer needs a fixed IP address; the client can have a dynamic or private IP without any issues. Additionally, instead of responding to host queries on a fixed schedule, a remote smart terminal can decide when information should be reported to the control centre.

Broad connectivity options

The integrated solution should be able to manage varied and numerous field devices. The serial interface is the most common interface for industrial devices, so the integrated RTU will need serial ports available to connect those devices to the SCADA network. However, merely having an available port is not enough; industrial devices communicate using many different communications protocols. Seek a GPRS solution that is versatile enough to handle a diverse range of devices without imposing onerous development demands on system builders. Specifically, the ability to create transparent serial channels to the control centre and advanced protocol conversion functions will reduce the complexity of connecting field devices to the SCADA system.

Reliable alarm system

The most critical requirement of any alarm system is timeliness. It does no good for system operators to receive detailed and accurate system alarms if those alerts have come too late for an effective response. An RTU that includes a front-end alarm system that is real time and versatile will ensure that technicians and staff receive system alerts promptly and reliably.

A front-end unit that can initiate alarms possesses obvious advantages over ones that rely on the host PC in the control room to process data and then generate alarms. The transmission between client and host could be delayed, interrupted or lost entirely, which is unacceptable for a potentially mission-critical alarm. There are additional advantages if the RTU has a built-in clock and can timestamp alarms and alerts on the front end, rather than relying on the host PC to record the times. Timestamps recorded in the RTU can be periodically uploaded to the host for more accurate real-time analysis and processing.

Also ensure that the RTU possesses versatile alarm messaging. Selecting a unit that can deliver messages via SMS, email, TCP/UDP, SNMP or updates to the SCADA system allows system operators to receive critical information in any circumstance, in the most appropriate format and medium.

Intelligent autonomous control of field devices

Verify that your RTU can be easily configured to respond to certain events in the field with or without operator intervention from the control room. Allowing the system operator to adjust field devices from the host PC substantially speeds response time compared to sending out a maintenance team. However, even this expedited response could be insufficient in some urgent situations, such as an imminent critical pipeline leak. In these sorts of pressing circumstances, the RTU should be able to automatically adjust devices to close valves and address the situation, and then issue alerts to inform system operators.

Front-end data logging and storage

A SCADA system relies on consistent and trustworthy historical data in order to build analysis and prediction models. There are two common approaches to storing log data in a SCADA system: back end and front end. In back-end storage, the remote terminal sends data to the central host PC continuously, where it is then stored. In front-end storage, the RTU has storage capacity built in, so the data can be recorded as files in local memory, which is then regularly copied to the host computer.

Figure 4: Front-end versus back-end data logging.

In order to conserve bandwidth in a GPRS environment, average rather than real-time values should be transmitted, even when using back-end storage - for example, rather than continuously transmitting flow data, the RTU can intermittently transmit the 5-minute pipeline flow rate average. Furthermore, back-end storage is vulnerable to network interruptions, in which case the data being transmitted from the remote terminal could be lost without ever being stored. A front-end storage solution ensures that all data is logged to a local file regardless of network conditions.

Low power consumption

The basic challenge of supplying power becomes nontrivial at remote field sites and substations. Indeed, it might be physically impossible to supply power via cables to some field sites. Instead, a combination of solar and battery power is an excellent choice for distributed remote networks. This combination allows the battery to help compensate for variations in available solar energy due to time of day or year. Unfortunately, battery costs can rise quickly if the system requires higher capacity batteries. Selecting equipment that is designed for low power consumption will minimise the headaches and costs involved in supplying power to remote sites.

Easy-to-use software tools and integration

An RTU that integrates many hardware components into one device may seem like an excellent solution, but without corresponding software support this complex device is a recipe for disaster. An RTU with easy-to-use software tools will minimise the need for lengthy and resource-intensive software development and maintenance. Ensure that the RTU provider understands a basic but often overlooked principle: to deliver customer value, hardware and software should go hand in hand.

Moxa Inc
www.moxa.com
CrispTech Pty Ltd
www.crisptech.com.au