What is Telemetry?
If you’ve come to this page through an internet search, and you don’t know what telemetry is, then welcome to a new and mystifying land; a land where you’ll spend a great deal of time banging your head against a wall, both literally and figuratively. In this series of articles, I hope to provide an insight into what telemetry is, how it works, how it is utilised, and what we at ID Systems do on a day to day basis.
The main question we get from job hunting undergraduates with degrees in electronic engineering is, ‘what is telemetry’, so that is where we will start off.
At it’s most basic level, telemetry is the remote monitoring of an object, and derives from the Greek tele (remote) and metron (monitor). One supposes the Greeks probably had a need to count how many goats were on a given hilltop, and thus the concept was born. A more recognisable form of telemetry to those of an engineering bent is that of the telemetry used in F1. A modern racing car is stuffed to the gunnels with analytical equipment monitoring the constantly changing variables of speed, fuel consumption, breaking times, acceleration etc…all this information is relayed in real time to technicians in the pit, and is constantly monitored throughout the race. In this way, technicians can analyse the cars performance and use this information to determine how the performance could be improved.
Sadly, IDS do not work in this glamorous world, and our clients requirements are of a more prosaic nature, but telemetry is an essential reporting device in the modern workplace.
ID Systems are telemetry providers to the utilities sector, or more specifically, to the water and gas industries. This means that we provide telemetry systems which monitor both the plant and process. Take the water industry as an example.
Scottish Water has in excess of 15,000 sites. Now imagine the cost to man every one of these sites for at least 8 hours a day. You would be talking in the region of roughly 225 million pounds a year, on-going. Telemetry drastically reduces this cost. ID Systems install a Remote Telemetry Unit (RTU), which reports back to a centralised database, and gives Scottish Water the information they require without having to man the sites.
Broadly speaking, Scottish Water require two types of information from the RTU:
1) Fault finding information, describing the nature of a fault and how critical it is
2) Logging of numerical values. SEPA and the DWQR place obligations on Scottish Water to log the values of all analogue signals on sites. Analogue signals are those which present a numerical value, e.g. flow rate, level rate, pH values, chlorine values etc… These must be logged every fifteen minutes and presented to SEPA in a reporting format. This information also allows managers to assess what processes on a site need to be improved and what don’t.
ID Systems provide the hardware and software to allow this to happen
Digital signals and database mirroring
The underpinning of telemetry is electricity and electrical circuits. For those unfamiliar with circuitry, think about a burglar alarm. A basic alarm will consist of a circuit, around which electricity flows (at a very low voltage) and a sensor which detects if this circuit is broken. If you look at your front door, you will see a magnet on the door and a switch on the door frame, and when the door is closed, the magnet and switch are adjacent. This proximity completes the circuit, and as long as electricity flows through it (when the alarm is set), the sensor ‘recognises’ that the door has not been opened. If the circuit is broken, the sensor then ‘recognises’ this and sets off the alarm, hence the need to enter your key-code as soon as you get into the house.
This is essentially what happens on a Scottish Water site with telemetry installed, albeit on a much more complex scale. IDS install a sensor box, called a Remote Telemetry Unit (RTU) which can monitor a number of circuits. An example of such a circuit would be an instrument failed signal. A cable is taken from a relay on the instrument. On the event of instrument failure, the relay changes state from closed to open, and the electrical circuit is broken. The RTU ‘notices’ this, and takes the appropriate action, which, in this case, is to alert the central server back at HQ that the instrument has failed.
This RTU has a unique address, and all the signals it monitors are ‘mirrored’ on a server at the Scottish Water headquarters. When the RTU dials out, or when it is polled by the server, the signals on the server are updated to match what is happening on site, thus if a pump has failed and is unavailable, this is mirrored on both a graphical representation, called a mimic, and on the IO list (or Input/Output list, to give it it’s technical name). This is an example of what people mean when they say that software is just ones and zero’s. As far as the RTU is concerned, zero (or closed) equals healthy, and one (or opened) equals failed.
When the RTU connects to the server, it also updates the log files. The RTU logs instantaneous values for all analogue signals (more on these later) every fifteen minutes, and on change of state (from opened to closed and vice versa), for all digital signals. This allows for historical trending, to meet drivers from environmental bodies, and to be able to assess how the plant is performing over a given period. The RTU stores these values until it communicates with the server, and then it ‘purges’ itself and starts from scratch.
So there we are for this blog, a brief overview of how digital signals work and how the RTU is mirrored at a typical ‘Top End’. In the next article, we’ll take a look at analogue signals, and how scaling works. We will also look at how the signals are physically relayed to the server.
Last time, we discussed how telemetry utilises the concept of open and closed circuits to provide information for ‘digital’ signals. This time, we look at the notion of analogue signals and the concept of scaling. Analogue signals are those which represent a numeric value, such as chlorine or flow. To keep things simple, we shall focus on the example of level. Say there is a storage tank on a site, and the highest level the water can reach is four meters, after which, it starts to spill. How do we represent the value of the level in a way the telemetry system understands?
Typically, a tank will have a level meter, which emits an ultrasonic beam to the surface of the water. The meter then works out the level of the surface based on an algorithm. Let’s say, for the sake of discussion, that the level of the water is 4 meters, or the maximum height of the tank. The meter sends what we call an analogue signal to the telemetry unit, and this signal represents a numeric value. The signal is in fact a current loop, and is a milliamp value. This milliamp value is anywhere between 4 to 20, where 4 represents zero, and 20 represents 4 metres. The level meter takes the actual value of the level (4 metres) then works out what milliamp value to send to the telemetry unit. In this example of 4 metres, the value to be sent will be 20 milliamps, or full scale. The telemetry unit reads the milliamp value and because it has been scaled as 0-4=4-20, works out that the value of the level is three meters. To flesh this out a bit, take the example where the level of the tank is 1.5 metres. The level meter would calculate this and send over a value mid-way between four and twenty, which in this case is twelve; if the level was 1 meter, the value would be 8 milliamps, and if 3 meters, 16 milliamps.
In tabular form, using whole numbers, we would get something like this:
0 meters = 4 millamps
1 meter = 8 milliamps
2 meters = 12 milliamps
3 meters = 16 milliamps
4 meters = 20 milliamps
There are algorithms to calculate the almost infinite number on values, and the algorithms are embedded in the code of the RTU. The level meter uses the same algorithms to calculate what the output loop signal should be, so there is a correspondence between RTU and level meter. If the level meter sends a milliamp signal based on the tank level being 2.63 metres, the telemetry unit will read the milliamp source and translate it as being 2.63 metres.
This has been a brief overview of how a telemetry unit receives and interprets analogue, signals. For further reading on the algorithms involved, this is a useful website: