Whispers & Screams
And Other Things

Enhancing Oil,Gas and Power Operations - SCADA via Rustyice Satellite Solutions

Oil and gas operations are located in unforgiving environments, from the blistering cold of the arctic to the scorching heat of the deserts and the storming conditions out on the open sea. To sustain secure operating conditions in these remote areas, reliable communication is as vital to the end-user as the umbilical cord is to an unborn child.


Supervisory Control And Data Acquisition

Supervisory control and data acquisition (SCADA) is a unique aspect of oil, gas and power distribution operations in that it does not entail communication between people, but between machines, also known as machine–machine (M2M).

SCADA describes a computer based system that manages mission critical process applications on the ‘factory floor’. These applications are frequently critical for health, safety and the environment.

The term telemetry is often used in combination with SCADA. Telemetry describes the process of collating data and performing remotely controlled actions via a suitable transmission media. In the context of this article, the telemetry media is a satellite communications solution.

SCADA in Oil, Gas and Power Distribution Operations

SCADA is not limited to a particular aspect of these types of operations. In the Oil and Gas industry, SCADA applications can be found in upstream areas such as well monitoring, downstream in areas such as pipeline operations, in trade by managing the fiscal metering/custody transfer operations and logistics in applications such as inventory management of tank storage facilities. SCADA systems in the Power Distribution industry use RTUs and PLCs to perform the majority of on-site control. The RTU or PLC acquires the site data, which includes meter readings, pressure, voltage, or other equipment status, then performs local control and transfers the data to the central SCADA system. However, when comparing and specifying a solution for challenging SCADA environments, RTU and PLC-based systems are not equal.

PLC Systems are Sub-Optimal for Complex SCADA Systems

Originally designed to replace relay logic, PLCs acquire analog and/or digital data through input modules, and execute a program loop while scanning the inputs and taking actions based on these inputs. PLCs perform well in sequential logic control applications with high discrete I/O data counts, but suffer from overly specialized design, which results in limited CPU performance, inadequate communication flexibility, and lack of easy scalability when it comes to adding future requirements other than I/O.
With the rapid expansion of remote site monitoring and control, three critical industry business trends have recently come into focus:

• System performance and intelligence – Process automation improves efficiency, plant safety, and reduces labor costs. However, complex processes like AGA gas flow calculations and high-resolution event capture in electric utility applications require very high performance and system-level intelligence. The reality is that even high-performance PLCs cannot meet all these expectations.

• Communication flexibility – Redundant communication links between remote systems and the central SCADA application form the basis of a reliable, secure, and safe enterprise. Power routing automation in electric applications, water distribution, warning systems, and oil and gas processes all require unique communication mediums including slow dial-up phone lines, medium speed RF, and broadband wired/wireless IP.

• Configurability and reduced costs – Although process monitoring and control are well defined and understood within many industries, the quest for flexibility and reduced Total Cost of Ownership (TCO) remains challenging. In the past, proprietary PLC units customized with third party components filled the niche, but suffered from lack of configurability and higher maintenance costs than fully integrated units. Today, businesses look for complete modular off-the shelf systems that yield high configurability with a significant improvement in TCO.

At the technical level, several requirements currently influence the SCADA specification process:
• Local intelligence and processing – High processing throughput, 64 bit CPUs with expanded memory for user applications and logging with support for highly complex control routines.

• High-speed communication ports – Monitoring large numbers of events requires systems that support multiple RS232/485 connections running at 230/460 kb/s and multiple Ethernet ports with 10/100 Mb/s capability.

• High-density, fast, and highly accurate I/O modules Hardware that implements 12.5 kHz input counters with 16-bit analog inputs and 14-bit analog outputs for improved accuracy.

• Broadband wireless and wired IP communications. Recent innovations in IP devices demands reliable connectivity to local IEDs (Intelligent Electronic Devices) as well as emerging communication network standards.

• Strict adherence to open standard industry protocols including Modbus, DNP3, and DF-1 on serial and TCP/IP ports

• Robust protocols for support of mixed communication environments.

• Protection of critical infrastructure – Enhanced security such as password-protected programming, over the air encryption, authentication, and IP firewall capability.

Selecting a Satellite Communication Solution – Factors to Consider


When selecting a satellite communications solution, there are numerous factors that must be considered. Enterprise applications like e-mail, Internet access, telephony, videoconferencing, etc. frequently tie into public communications infrastructure. Due to security and reliability considerations it is considered best practice to isolate mission critical SCADA communications infrastructure from public networks.

The Rustyice solution is a dedicated satellite communications network solution tailored for the SCADA applications environment. By virtue of system design, our solution offers greater security against hacker attacks and virus infestation which mainly target computers that are connected to the Internet and are running office applications.


Due to the critical nature of most SCADA operations, a reliable communication solution is of utmost importance. The satellite communications industry is mature with a proven track record. Satellite transponder availability is typically in the 99.99 percentile range, a number far superior to that of terrestrial networks. To build on this strength, our solution utilises a miniature satellite hub that is deployed at the end-users SCADA control centre. Data to/from the remote terminal units (RTUs) are piped directly into the SCADA system. There is no vulnerable terrestrial back-haul from a communication service providers facility, which can cause the entire network to crash if cut during public works, i.e. digging.

To increase the reliability of the hub, it is frequently deployed in a redundant/load sharing configuration. This ensures that the hub is available more than 100% of the time, making it far from the weakest link in the communication chain.

Types of Connectivity

Contrary to enterprise-related communications which take place randomly, SCADA communication is quite predictable. It is a continuous process, where the SCADA application polls the RTUs at regular intervals. The outgoing poll request is a short datagram (packet) containing as few as 10 bytes. The returned data from the RTUs are also in a datagram format with the message size being from 10 bytes to 250 bytes. One could easily assume that a satellite solution based upon dial-up connectivity such as Inmarsat, Iridium or Globalstar would be ideal for this application environment. Since SCADA is not just data collection, but also entails control (which at times can be of an emergency nature), you simply cannot wait for the system to encounter a busy connection. What is needed is a system that provides an ‘always on’ type of connection, commonly referred to as leased line connectivity.

A Rustyice solution supports both circuit switched (leased line and multi drop) and packet switched (TCP/IP and X.25) applications concurrently.

Continue reading
26 Hits

The Chirpsounder / Ionosonde

Anybody who has ever set up a working international HF link will know it can be a tricky business. You see there's a pesky movable thing called the ionosphere which is pretty fundamental to the whole business.
Communicating with a point halfway round the planet using HF is like trying to play that old 70's children's game called Rebound. Since radio links are usually close to or distinctly line of sight links, communicating with a point on the other side of a sphere would seem like a fairly insurmountable problem. I'd think the first time this problem was solved using the ionosphere it was probably an accident caused by some early radio pioneers receiving signals for their fellow pioneers some way round the planet and beginning to wonder why and how it was happening.

The reason it was and does happen is because of a thin layer of the Earths atmosphere called the ionosphere. The ionosphere is a region of the upper atmosphere, from about 85 km (53 mi) to 600 km (370 mi) altitude, and includes the thermosphere and parts of the mesosphere and exosphere. It is distinguished because it is ionized by solar radiation. It plays an important part in atmospheric electricity and forms the inner edge of the magnetosphere. It has practical importance because, among other functions, it influences radio propagation to distant places on the Earth. This is the reason we as Telecommunications Engineers are interested in it.

The ionosphere is a layer of electrons and electrically charged atoms and molecules in the upper Earths atmosphere, ranging from a height of about 50 km (31 mi) to more than 1,000 km (620 mi). It exists because of the Sun's ultraviolet radiation which causes these gases to ionise and develop a charge. Because of the boundary between this layer and the relatively uncharged layer below, wave diffraction occurs. This phenomenon takes place at different incidences with different frequencies and, with clever utilisation of this property, the ionosphere can be utilized to "bounce" a transmitted signal down to the ground. Transcontinental HF-connections can rely on up to 5 of these bounces, or hops.

It is the process of determining the appropriate frequencies and their respective bounce points around the planet that is the focus of this post. The applied physics involved in this refraction are beyond the scope of this post but, in a nutshell, what they do produce is a spread of frequencies which bounce at different incident angles to the boundary layer such that different distant points on the surface of the planet can be reached when the bounced radio wave returns to the ground. This is shown more clearly in the diagram on the left.

Unfortunately, it is not quite as straightforward as the diagram above suggests as the strength and location of the ionosphere is always changing as day becomes night and also as cosmic radiation from the Sun changes over time. This presents those wishing to use this phenomenon with the constant problem of determining which frequencies are workable and usable between any two given points on the Earth.

The problem of determining these usable frequencies was the driving force behind the invention of the Chirpsounder (also known as an Ionosonde). The Chirpsounder, or rather a pair of Chirpsounders operate in tandem using a Chirp transmitter in one location and a Chirp receiver in another. The job of the transmitter is to transmit a sweep of radio output from one predetermined frequency to another over a given amount of time. A Chirp receiver situated close to the transmitter would if synchronised to match the sweep timings, receive all of the sweeps from the beginning to the end but the same Chirp receiver placed two thousand miles away over the Earths horizon may not fare so well. This is where the technology really comes into its own.

When a Tx/Rx pair of Chirpsounders are running a synchronised sweep between two distant locations, the receiver will receive from the transmitter only during those parts of the sweep that are conducive to a working link between the two. This information is gathered by the Chirp receiver and is used to provide the user with a graph showing frequency on the x-axis and receive delay on the y-axis. There will also often be a display of receive signal strength incorporated in the output. A sample Chirpsounder output is shown on the right.

As can be seen, there are a number of elements shown on the trace and each of these represents a successful reception of the signal from the transmitter. The more solid the line, the more reliable the link and this information, when used in parallel with the received power information can enable telecommunications professionals to choose the most appropriate frequency. Once the decision had been made the operational transmitters and receiver could be set appropriately and the operational radio channel could begin to pass its traffic using the ionospheric bounce. Quite amazing really.

Continue reading
833 Hits