Impressive new features include:

• Data Logger Enhancements – There are several new Logging Features for Crisis, Interval and Configuration Logging. Interval Logs can optionally trigger DNP events. User interface has been greatly enhanced including saving logs to CF (config logs, IP address, serial number, MAC address, etc) and System Logs (var/log/messages).
• Alternation by Efficiency Enhancements – When the efficiency of pumps is within a configurable deadband, standard alternation is used instead of the N to 1 ratio.
• DuoProbe Upgrades – This marks the formal software release for support of the DuoProbe, including enhancements to DuoProbe operation and calibration.
• Maintenance Mode – A timer is now associated with Maintenance Mode. In addition, flow calculations are disabled during Maintenance Mode operation.
• Print Out Info Pages to Excel – With the push of a button, capture a snapshot of all values displayed on the Info Pages and save it to a .csv file, which can then be imported into Excel.
• Last Known Power Factor – This innovative tag reflects the last known power factor: You no longer need to wait until the pump starts in order to determine the power factor.
• Generations of DNP/MODBUS Log Files – The size of the protocol logs are now programmable with a configurable number of file generations. These logs can help troubleshoot communications issues.
• Pump Starts/Stops Independent of Level – This clever feature allows custom logic to take full control of pumps and is designed especially for PID applications.
• Probe Fail Indicator – The number of the failed sensor is now indicated which helps isolate Probe problems and reduce the amount of time it takes to troubleshoot the problem.
• WITS-DNP – This involves enhancements to DNP3 mandated by the UK water industry. There are some features which have been designed in a generic way so that they can be used outside of WITS. Exposure outside of WITS is scheduled for a future release.

Other notable improvements include:

• Restart MultiSmart Tag
• Disable a Running ISaGRAF Program
• Pump Reversals
• Single Sensor and Three Sensor Probes
• Ability to View Inhibit Status from Front Screen
• Max Starts
• Configurable Limit for IRT
• Pump Starts and Flow Based on Contactor Closure
• Strings Not Included in DNP Class 0
• Pulse Input Flow and Rain Gauge
• Station Low Flow Rate Alarm

Related Blogs:

New MultiSmart Data Logger Enhancements

New Alternation by Efficiency Enhancement

MultiSmart Firmware 2.3 – DuoProbe Features

Upgrading Firmware Versions

Downloading Firmware Upgrades

Sign Up to Receive Firmware Upgrade Notification

A protocol defines the rules by which devices talk to each other. DNP3 is a protocol for transmitting data from Point A to Point B via serial and IP communications. Although DNP is most commonly used by electric, gas, water and wastewater utilities, it can be used anywhere a SCADA system is exists.

Why Do Devices Need to Talk to Each Other?
Utility providers commonly have lots of operations they need to monitor. Typically, there is a central operations center plus remote equipment in the field.  The central operations center houses their main computer.  Installations/substations house remote equipment in the field.  DNP is used to facilitate communication between the main computer and remote equipment, enabling the main computer to remotely open/close circuit breakers, measure line voltages, start/stop motors, open/close valves, check for errors, etc.

View Previous Blog Series on DNP3:

DNP3 Part 1 – Date/Time Stamping

DNP3 Part 2 – Communications Options

DNP3 Part 3 – Security

DNP3 Part 4 – Reliability

DNP3 Part 5 – Compliance

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

Part One: Date/Time Stamping – or Less Guessing
Part Two: Communications Options – Polling and Unsolicited Reporting
Part Three: Security

The DNP3 protocol also supports guaranteed delivery. What does this mean?

Suppose you want to send a command to start a pump. How do you know the RTU at site received the command? With some older and simpler protocols the only way to check is to read the status of the pump at a slightly later time – and hope you catch it in the act.

Or suppose you want to ensure that the message High level alarm or All pumps unavailable sent from the RTU was not missed by the master station or SCADA? With some protocols, like Modbus, there isn’t any mechanism for ensuring this.

DNP3 provides message acknowledgements. With unsolicited reporting, the RTU might send all changed data every half hour, or if the event buffer was full. The “message” that the DNP3 protocol sends includes all the tags that have changed with the date/time of each, and also includes a sequence number. The master station would send an acknowledgement to the RTU – or “outstation” – that that sequence number had been received.

In the event that the RTU / outstation didn’t get that confirmation, it would retry. And after a certain time period the site would go into a Comms Fail mode with probably a longer retry delay. I say “probably” because that depends on how the user sets it up, but that would be the sensible approach.

As you can see if you’ve been following this series on DNP3, the creators of DNP3 designed it for the challenging world of telemetry where communications is always suspect and often problematic.

There’s more to configure in the protocol of course, but each element is there to ensure data integrity:

• you know what happened
• exactly when it happened
• you can guarantee that the SCADA system knows about it
• and you can ensure that data is genuine and not from a hacker

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.

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.

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?