MultiTrode has recently released the firmware version 2.2.1 for the MultiSmart Pump Station Manager. This update includes enhancements for achieving higher efficiencies and support for extra security.

Major highlights of this release are,

1) Easy interfacing of selected ABB drives, in just a few button presses
2) Support for Dallas iButton security key
3) Improvised well mixer functionality
4) New Pump Alternation Modes
5) Simplicity in interfacing Rain-gauges
6) Extended pump efficiency calculations and alarming
7) DNP Object 0 support (helps in remote identification of device details and DNP profiles)
8) Improvised VFD configuration menu
9) Enhancements for flow calculations and flow statistics

These new features and enhancements further extend the capabilities of the MultiSmart to continue providing a unique and one stop solution for Pump Station Management. Registered members can download the firmware from the MultiTrode website www.multitrode.com. If you do not have a login, please navigate to http://www.multitrode.com/member-registration.php for applying a free registration. Read more…

General News, Industry, SCADA & Telemetry

If you are relatively new to DNP3 you might under-estimate the value of certification.

Compared with a protocol like Modbus, DNP3 has way more features. That’s another way of saying that it is a lot more complex.

Modbus compliance is very easy to test. Suppose you have an RTU with Modbus Slave – a unit which will be polled by a master PLC or RTU. To test it, you can download any one of a number of free or demo Modbus tools and check that you can read a set of registers and write to a set of registers. That’s not the complete functionality of Modbus but it does confirm that the basic functionality works – and because the protocol is so simple, the product vendor is unlikely to have got it wrong. One tool readily available is the Kepware OPC server and you can download a demo version from their website.

As the end-user or system integrator implementing DNP3, if you have to put together a master from one supplier and a slave from another, when it doesn’t work who do you call? Or if you are taking advantage of the fact that DNP3 is an open protocol supported by many vendors you might be choosing a number of different field products – each one suited best for the application at hand.

DNP3 has the flexibility you need for reliable, secure telemetry but there’s a lot of features to test.

The smartest approach is to get the vendor to do it for you before you start using the product or software. If you ask for an independent certification you know that the protocol has been tested by someone who’s reputation is on the line if they miss something.

To get an idea of what gets tested in DNP3 certification you can see a copy of a full test report on the MultiSmart RTU on our main site, under the product manuals section of MultiSmart – www.multitrode.com/pump-station-manager/product-manuals.html Read more…

SCADA & Telemetry DNP3, RTU, SCADA, telemetry

Our White Paper on SCADA reporting also appeared in Pumps & Systems – for those who don’t know it, an excellent US industry magazine. You can find the online version of the magazine at www.pump-zone.com.

What’s the White Paper about? Essentially it looks at where SCADA and telemetry reporting currently stands for a typical lift station network – compared with where it could be – and where the utility asset managers and operations managers would like it to be.

Operational Cost Breakdown

Anyone who has implemented a SCADA system, or even played with a SCADA package can tell you how easy it is to create an animation on the HMI that depends on a data point. For example, displaying a well emptying and filling as the level “tag” falls and rises in value. Or a motor changing from blue to red as the temperature tag increases in value.

It’s probably the first thing that you get taught on the SCADA course, or get shown by the salesperson when he/she demonstrates ease of use of that SCADA platform.

Reporting is a whole different question. There is the challenge of finding where the real data exists in the system, understanding data integrity and getting to grips with the reporting interface. But the bigger challenge for many end users and SI’s is that creating a good report means getting to grips with relational database concepts, and that’s a lot harder than linking a process value to a graphical animation.

As Paul Francis, MultiTrode CTO, said:

Reporting has always been a challenging aspect of any SCADA platform. Visualization and trending tools were some of the earliest adopted elements of SCADA systems and hence matured long before reporting interfaces did. Developing useful reports can also be more of a technical challenge than making a nice graphical interface for your plant or collection system; in part due to the nature and structure of the underlying data.”

Away from the mechanics of reporting, there are other challenges. For example, data acquisition in the field. Typical PLC and RTU systems aren’t bringing 100’s of tags back to the SCADA system. That requires a level of design that is rarely catered for. With minimal data, it’s hard to generate much in the way of reports – and this may well have contributed to the low expectations of asset managers.

Reports - Pump Efficiency Changes

And in the US, the de facto standard for water and wastewater telemetry protocols is Modbus. This works against any attempt to get asset rich data. (See, for example, DNP3: Part One or DNP3: Part Two).

None of this means that it’s too difficult to get reports that will cut operational costs or provide asset reports to allow better capital allocation. It’s just important to understand the different roadblocks that lie in the way.

If you want to read the SCADA Reporting White Paper you will have to fill in a short registration form (unless you already have a MultiTrode website login). Read more…

SCADA & Telemetry reporting, RTU, SCADA, telemetry

This post continues the themes from Part One and Part Two.

The subject today is security, and also why proprietary protocols aren’t the answer.

Security in communications is a hot topic, but in practice in the water and wastewater industry, not many people are actively implementing it.

It’s important to differentiate between “hacking the comms” and “hacking the server”. If there is a greater problem for the organization, it’s surely someone hacking your server through a firewall –  or from within your building – because now they can take control as well as present the operations staff with a completely false worldview.

However, if the SCADA server is highly secure and someone was very motivated to take control of your system, then they could potentially do a lot of damage by hijacking the communications. Imagine if they turned off all of the sewer pump stations in a city? You can send your staff out to put every station into manual over-ride – but only once you knew about it, and it would take some time to get to every single station. You would have lots of overflows, and you would have your whole team racing around from station to station. If it happened in a time of high inflows – e.g. a storm – then the problems would be much worse. In a water supply system it might be possible to burst pipes.

There are a lot of articles about communications security that start: “Since 9/11″ – probably because it gets higher exposure. But how much of a risk is it?  And is the risk greater from other sources than terrorism – like disgruntled ex-employees? It’s certainly getting attention from governments, but not much practical attention from the utilities themselves.

This article doesn’t try and address the risk factor. Instead, we’ll just explain a little about how communications to remote sites can be secured.

Security in Communications -  Are proprietary protocols the answer?

One subject that the promoters of proprietary protocols majored on in recent years is security. This is because they didn’t have a lot else to hang their hat on.

What am I talking about? Open protocols have been the perceived way forward for a long time, but especially in this century/millenium. For the last 5-10 years in the water & wastewater industry, almost anyone writing an engineering spec, or an operations manager or utility director who had done a small amount of research, knew that you needed to specify an “open protocol” for a new or upgraded system.

This presented a challenge for a number of companies who had their own protocols in their RTU and used these protocols to lock in customers. What to say to show they were progressive?

“At least no one knows how to hack our protocol, that’s an advantage..”

By the way, I’m not including in this list, companies with their own protocol who made them public. There are many companies, including ourselves, who in the 1990’s had their own telemetry protocol in their RTU because it seemed – rightly or wrongly - to have some advantages at that time. The important point is, once the move towards open protocols became desirable or a requirement, and high quality telemetry protocols became available, what did those suppliers do? The responsible ones published their protocol and made it easy for other parties, including competitors, to copy them.

In fact, most proprietary protocols aren’t that hard to reverse engineer.

In the world of encryption and authentication, the experts will tell you that openness is what allows the audit. Don’t tell the world that your protocol is “secure” because it is proprietary, unless you have invited a few hackers to break it. It probably won’t take them very long.

A good recent example is where one of our partner companies, Trihedral, reverse engineered a proprietary protocol from another supplier to allow them to break into their market – to replace the SCADA server software while still interfacing to the RTU’s in the field.

Only last year (2008) I read an article in a water industry magazine by a supplier saying how their RTU protocol was more secure than DNP3 because it wasn’t published..

Time to move on..

DNP3 Security – How Does it Work?

Security is one of those tricky subjects that most people actually don’t want to understand. As a user you just want to know it works. So I’ll stay away from the more technical aspects.

DNP3 is a published protocol with a very strong and a very technical user group. You can be sure that the people in the user group who published the security specification knew what they were doing.

Very simply, DNP3 security doesn’t encrypt the message, it authenticates the message.

If someone intercepted a command to an RTU: ”turn on Pump 1″ which might look like “digital tag 15 ON”, they could read it!

But if the bad guys then wrote a command to send to the RTU - ”turn off Pump 1″ – “digital tag 15 OFF” – the DNP3 authentication mechanism would reject it. The security mechanisms in DNP3 can determine when the command is a valid one by a trusted party.

This gives an insight into why the oil and gas suppliers might want RTU encryption, not authentication. In a highly competitive commercial environment you don’t want others to know how much volume you pumped  -for example.

In water and wastewater, even in the privatized but regulated market of the UK, it’s hard to see how anyone reading your pump station commands could cause you a problem.

The key point of DNP3 security is that while others can see what you are doing, they can’t pretend to be you and tell your system to do the wrong thing. That’s what authentication means.

If you want to know more, please take a look at our White Papers section. You need to fill in a short registration form to download any of the papers. The title of that paper is “Keeping SCADA systems open and secure from cyber-attack”.

There’s a lot more technical data available – check out the DNP3 Users Group.

And if you’re one of those people who like to understand more about “how everything works” – for the confusing world of encryption and authentication, a personal recommendation is Cryptography Decrypted by H.X. Mel & Doris Baker. It was published in 2001 so it might be a little dated, but I found it made subjects like public key encryption finally understandable. Read more…

SCADA & Telemetry DNP3, RTU, SCADA, security

We posted a news item on our main site about Trihedral and MultiTrode.

Background

This brief blog post gives a bit of background. Canadian-based Trihedral have been making inroads into the water and wastewater industry – our main market – for some time. From our perspective, we have seen them win a lot of customers in the SE of the USA. They might be winning customers in lots of other areas too.. we’ve just noticed the SE region.

The Florida market has had a major supplier who locked up the customer base with a proprietary protocol. What Trihedral did was reverse engineer the protocol. As a result, the Trihedral VTS platform can be implemented by these customers who can continue to use their existing field hardware but are now free of their restraints! They change their SCADA platform, keep their old hardware (so don’t have to change everything overnight), but they can start using new products.

These customers who have switched to VTS can now introduce any product they want in the field – or the plant – so long as it supports open protocols like Modbus or DNP3. 

The Partnership

That’s the background, but the news item is about what Trihedral have done, in partnership with MultiTrode. VTS will shortly have an “add site” function for MultiSmart.

This function essentially removes a lot of the legwork, or integration, out of bringing a MultiSmart site with 100’s of tags (data points) into the VTS system.

The new version of VTS isn’t quite out yet – expected in February. But I saw a demo of it a few months ago and was very impressed. The MultiSmart pump station manager was on an ethernet link (could have been a radio link) to the VTS SCADA server and the whole process was automated.

The remote MultiSmart site created a compressed version of the XML configuration (we use XML as standard for all configuration files), transmitted it using DNP file transfer (industry standard), VTS loaded it, unzipped it, and presented the user with a few checkbox options for configuration – including graphics, alarms and controls.

I know some of the Florida customers are very keen to get their hands on it. And some of our engineers are very interested in what Trihedral have done.

2+2 is more than 4 – if you choose the right combination

That’s the beauty of working with other companies who are great at what they do and have a passion for making things better! New ideas that spur our engineers on to come up with even more innovation.. and make life easier for the customer. Read more…

SCADA & Telemetry Add new tag, DNP3, MultiSmart, SCADA, telemetry

This follows on from the first blog post on DNP3 where we covered Date/Time Stamping – or Less Guessing - and a little bit of a comparison with Modbus.

This post is about some of the mechanisms for communicating between the SCADA, or master station, and the remote site. By the way, in DNP3 speak, you often hear the term “outstation” for the remote site. We’ll tend to stay with RTU (depending on who you talk to it either means “Remote Telemetry Unit” or “Remote Terminal Unit”), which is essentially the device that communicates.

Polling 

Let’s start with a Modbus comparison again, just to give a little context. Modbus is a totally polled environment – that is, the master station (typically a PLC) requests data from a site. The remote site can’t choose to send some data to the master station, it has to wait until the master requests it. So a very typical arrangement for a collection system is where the master PLC polls each lift station in turn and when it is has finished, starts again.

This has a lot of disadvantages as anyone with a growing network of lift stations has found. The time taken to get around the network goes up and up. You might get to a point where it’s 15 minutes between polls and decide to prioritize certain sites to get polled more frequently, or add a radio frequency (and therefore a new base station and repeater radio) to split the network into more manageable pieces.

It’s not an ideal situation, because Modbus isn’t an ideal telemetry protocol. (It’s a great protocol for other applications).

Unsolicited Reporting

If waiting until the master station asks you how you are doing isn’t the best way, what about unsolicited reporting. What’s unsolicited reporting? The remote site, also known as the RTU, sends data to the master station without being asked.

If you are used to Modbus polling systems, this might sound like anarchy. And if you have every site sending a message every time an event takes place, it could well be anarchy. Will the radio network stand up to lots of sites all trying to communicate at once?

The only way you might be able to prevent chaos, is by having a very limited amount of data getting sent, or a high radio bandwidth. One of the guys in MultiTrode told me about a system he was involved in with a previous company where they used unsolicited reporting for every event, and during a major storm the entire network shut down due to “collisions” in the radio network. The solution was for someone to go and visit every site and reset each RTU. Then the network started communicating again. But they lost all the data for their critical event.

That’s not great. What’s the solution?

Communication Choices and Different Classes

The DNP3 protocol has some great features to avoid the problems above.

Firstly, you can group events into different classes. Then secondly, you can choose how those different classes communicate from the RTU to the master station.

An example is the best way to explain it. Suppose you want to know about all high level alarms within 1 minute, and otherwise you are happy for all stations to be communicating at least once every 30 minutes.

You would put the alarm “High level” into class 1, and everything else into class 2. Then you would set class 1 to unsolicited reporting immediately. And class 2 you might set one of two ways – either to report every 30 minutes or sooner if the event buffer was full; or you might have the master station polling every 30 minutes.

Now you can find out immediately about high level alarms without risking the network turning into treacle and you still find out about all the changes in your network.

It’s the flexibility in DNP3 that is one of its great features. As Paul Gibson, one of the key people behind the development of the MultiSmart pump station manager, said:

“If we didn’t have DNP3, we’d be trying to design a protocol just like it to put into the product.”

The Communications Network still needs Design

Just because there’s a flexible protocol doesn’t mean you don’t have to do anything. Every communications network needs design. How much data? What is the bandwidth? What are the delays?

Read more…

SCADA & Telemetry DNP3, Modbus, MultiSmart, RTU, SCADA, telemetry

In the water and wastewater industry in the US, Modbus is the most common telemetry protocol. Its great benefit is its simplicity – and almost everyone in automation and process control is familiar with it.

For a few years now, we’ve been promoting DNP3 for telemetry instead of Modbus. Why? What’s the benefit? For people new to protocols and telemetry it’s hard to know where to start. 

Today, we’ll cover the first benefit:

Date/Time Stamping – or Less Guessing

DNP3 adds a date/time stamp to every event when it occurs. Each event is added to the “event buffer” in the RTU with its own date/time stamp. Then when the RTU communicates with the SCADA, or “master station”, the data can be stored in a Historian (database) or displayed on the HMI with the actual time the event took place – not the time that the master station received the data.

I mention that point because a lot of SCADA systems, most of them, were so orientated around process plants with hard-wired high speed data connections (like ethernet or high speed serial) that the normal mode of operation was to log the data with the date/time that it was received by the SCADA (and ignore any date/time stamp from the field if one existed). It doesn’t matter too much in a process plant – the comms is almost instantaneous – and if any comms outage occur they are quickly fixed.

DNP3 tells you when the event occurred – not when the SCADA system found out about it! 

In wastewater collection and water supply systems almost all of the assets are distributed in the field. And communications are often disrupted. Even when they are not disrupted, you don’t want every event to be communicated when it occurs.

Here’s how a typical Modbus network works – the master station (typically the master PLC) “polls” each site in turn to get all of the current data.

“Get the current data” means read a snapshot of all of the Modbus “registers” or data points. Most of them won’t have changed, so you are using precious bandwidth to capture lots of unchanged data. What about the data that has changed? Unfortunately, you don’t find out when it changed. You can just see that a different value is there now.

Modbus fills up the bandwidth with data that hasn’t changed. DNP3 only captures the data that has changed. So it can communicate a lot more useful data in the same bandwidth.

Let’s use the example of an analog process value. The value that the SCADA last captured from the field was 6.8, this time around – 10 minutes later – it is 6.9. So when the SCADA trending client displays this value – or you produce some kind of report, the process shows 6.8 moving to 6.9. Is that what happened? Or did it go to 7.1 and then back down? You’ll never know. You might know your own process really well, or you might be guessing.

You might know your own process really well, or you might be guessing. Using DNP3 avoids the kind of detective work that often goes on, where the operations and engineering staff try to fill in the gaps!

And then lastly, what if comms to that site – or a number of sites – is down for 24 hours? With DNP3, when comms is restored, all of the events during that period will be communicated to the SCADA (check out the technical note below).
 

Do I need this?

Whe you build a house, if you have the right foundations and structure you can add another floor. If not, you have to knock it down and start again.

To begin with, just getting reliable data out of a SCADA system is a great relief. But once it’s working and providing data you start to ask more questions – because you want to make the system work better.

Did both pumps run together in Pump Station 18?
What’s the hydraulic delay between Station 19 and 18?
I know the radio failed but do we know how high the level got at Station 12? And so on.  

A Quick Technical Note

Designing your comms system always takes some work and this isn’t aimed to be a technical workshop. But one important point with your field device is to ensure that the event buffer has been configured with enough memory to capture all the data that you might need in an outage. And the other important point is to ensure that the DNP3 configuration is for SOE (sequence of events) – as it is possible to configure last event only.

I mention these points because it is often only when you really want the data that you find out it wasn’t configured to capture that data that you wanted. Best to check when starting out.

Learn More

There are two whitepapers about DNP3  on the main site. One covers DNP3 Security – “Keeping SCADA systems open and secure from cyber-attack” and the other is more general – “Benefits of DNP3″.

To access the whitepapers you do need to complete a short registration form.



Read more…

SCADA & Telemetry