Master Thesis Guidance With Protocols

S

Thread Starter

Sandra Calvo

Hello,

I am currently writing my Master thesis for my engineering degree. It is about designing an API for a RTU situated in the distribution grid and I am trying to decide which communication method is going to be better to have the device communicate with 3rd parties so new applications can be added.

I have found many protocol alternatives like Modbus, 60870-5-101/104, 61850, DNP3... But I also want to consider RESTful APIs and I don't know how to compare that design alternative with standardized protocols.

Do you have any suggestions? Any approach indications?
I would really appreciated a little guidance.

Thank you.
 
L

Lynn August Linse

Wow, that's a tall order. Which is better? :)

Really it depends on your market. Modbus is great of small general third party devices and LCOAL polling, but it is brute force, so horrible for remote access.

DNP3 is common in power industries, and some of the IEC 61850 stuff is best for workstation-to-workstation transfer.

BACnet is most common in building control, food plants, HVAC.

Personally, I'd probably go with DNP3 or BACnet.

ProfBus, Foundation Fieldbus, and ODVA EthernetIP are more common in manufacturing, but not really very sophisticated as far as true browse & object-oriented behavior goes. Those protocols tend to assume you have some form of local 'description file' which is linked to the remote device type & model.

You really want something object oriented (for a thesis) as those allow auto-config & browse, whereas Modbus is strictly a "get the D*#$ PDF manual and config things manually".
 
I can only speak for the last 35 years (20 with the Fisher ROC series) and it has been Modbus all the way. That is mainly because Modicon published the specs for Modbus and that gave users and suppliers confidence in its future larger scale compatibility. It was free and there were no secrets just as open source like GNU and MinGW ("the GNU General Public License is a free") are today. So is there a future for GNU? I think so, so it must hold true for Modbus as well. IMO.
 
J
Hi.

You must pay attention in the security (cryptography) issues. A large scale data network (utilities) can be severely affected by spoofing software, specially in wireless networks.

JOHN
 
S

Sandra Calvo

Thank you all for your responses.

I am strongly considering Modbus, because DNP3 seems to be able to do everything Modbus does and more, but it is more complex not to say expensive and probably I don't need all its functions...
 
L

Lynn August Linse

You could also look through the California Smart Grid initiatives, as they are trying to define common exchange standards based on REST and modern large-data principles. http://www.cpuc.ca.gov/PUC/energy/smartgrid.htm

Since is a Thesis, you should also discuss this with your committee, as they may penalize you for taking something so old (yet easy to do) like Modbus for a new forward-looking design. Given how expensive (monthly recurring costs) Modbus is for wide-area Smart Grids, I would certainly ding your work down a grade or two if I were your adviser.
 
J
The security/cost of MODBUS is exceptionally inviting for most applications. It is a "kinda" standard in many industries'.
A a ROC guy too, like Harvard, it's simplicity is welcome, after you've read the manual 45 times...

> You really want something object oriented (for a thesis) as those allow
> auto-config & browse, whereas Modbus is strictly a "get the D*#$ PDF manual and
> config things manually".
 
Look, I know the automation fellahs on this forum are really pro-modbus, but it's really not a good idea for distributed grid type applications. For Several Reasons.

1. Modbus has ZERO security. Period. If someone can access the modbus TCP port or the serial->ethernet converter, the system can be controlled. That's it. Game over. If someone tells you 'modbus is secure', they don't know the protocol. The only way to use modbus in a manner that can be remotely secure is to lock off all means of ingress. And that just compensates for a lack of security. To ensure those third parties don't harm the process, a special set of devices or a separate interface would likely be needed (1 for command/control, another for read-only), which increases the cost of the device.

2. Modbus uses a polling architecture, when a distribution application would benefit more by a report by exception+status check. More complicated, and requires more interaction with substation design and maintenance personnel, but it also conserves bandwidth and reduces latency.

3. Modbus doesn't include timestamp data on when the event happened. The timestamp data is computed on the requester when the data comes back from the RTU. THis means you always have to assume a delay on when something happened. Not good for modern distribution automation requirements here you want to use the cheapest form of endpoint communication you can since you're controlling 100s or even 1000s of devices.

For right now, I'd look at DNP3. It's complicated as hell, but my buddy Adam Crain is working on an open source implementation. Also, he received a grant to do Secure Authentication work, which will allow third parties to access certain data, but not all functions, of a device. http://www.automatak.com/opendnp3/

Any company that is concerned about their bottom line and doing distribution automation stuff will NOT be using modbus in the use case you describe. I can't speak for the other protocols you've described.

You may be able to find some discussions in papers on the North American Synchrophaser initiative. It's not distribution, but it is based on the assumption that third parties will be required to connect for data sharing. In other words, it shares some similarities with your use case. Good start here: https://www.cavs.msstate.edu/iPCGRI...13/Panel_Data_Exchange_Dagle_iPCGrid_2013.pdf

Mike
 
C

Curt Wuollet

In nearly any scenario I can think of, if a bad guy has physical access, Game Over.

That applies to outside access to any control network. To depend on software security is insecure.

In most situations, bringing about an inability to control is good enough. Things like power grids and pipleline systems will happily destroy themselves. The biggest laugh i had was someone demonstrating a new high security scheme running on MS Windows.

Regards
cww
 
> In nearly any scenario I can think of, if a bad guy has physical access, Game Over.

Yup. At least with Modbus, the attacker will pretty much have to show up with a screwdriver and wire strippers. :)
 
L

Lynn August Linse

Actually, no. All you need to do with Modbus is start writing zeros at holding register offset 0 and keep going up to 65K, ignoring errors and you will likely crash any PLC program (if a PLC) or totally screw up operations with bad setpoints & flows, all while exposing zero knowledge of the system!

> Yup. At least with Modbus, the attacker will pretty much have to show up with a screwdriver and wire strippers. :)
 
That may be. But how are you going to get on the network to begin with?

> Actually, no. All you need to do with Modbus is start writing zeros at holding register offset 0 and keep going up
> to 65K, ignoring errors and you will likely crash any PLC program (if a PLC) or totally screw up operations with bad
> setpoints & flows, all while exposing zero knowledge of the system!

And from my point of view Modbus TCP/IP is not strictly Modbus, and not really the fault of the Modbus spec if it is not secured (the same applies to radio modems, etc.). In my mind the security requirements of TCP/IP rest squarely on TCP/IP.

And if your attacker breaks into the PLC/SCADA/Whatever at one end and pollutes the Modbus network from there, then maybe it's time to lock down the PLC...

So on a RSxxx network, the way god intended Modbus to be, it's going to take a wiring change.

The point is taken that there are better networks out there, but if you are after interoperability across the greatest number of disparate devices, you can't touch Modbus. That's what makes Modbus so interesting to me.

And even if you don't like Modbus, at some point in your career you are likely going to have to deal with it. So it's insidious as well. :)
 
C

controlobserver

If the attacker can send messages to the control network, he doesn't need physical access to knock it offline. Pretty much any control hardware out there would be completely overwhelmed by a common garden variety DOS (Denial of Service) attack. A DOS attack simply floods the target with messages beyond its capacity to handle. With most control hardware running on an embedded system processor, its ability to handle is pretty low. A single compromised PC on the same network could knock out most of them.

Large commercial web sites are frequently taken down by DOS (or D/DOS - Distributed DOS) attacks, and these are backed with massive server infrastructure, including special DOS protection hardware. Message encryption and authentication are irrelevant in this sort of attack and are no protection.

Buffer overflows are another simple attack that would work against a lot of control hardware. You simply craft the messages to attack software (or firmware) bugs to overflow buffers, overwrite memory, and crash the processor. This is a very common form of attack on the Internet. Again, message encryption and authentication are irrelevant in this sort of attack and offer no protection.

Where encryption and message authentication have a role is where someone wants to infiltrate a network without being detected. That typically happens when they want to steal copies of data without being noticed. That isn't the sort of thing which is the main concern for most control networks.

For a control system which requires the network to be present and working, the only solution is isolation of the network. If you wish to communicate with it remotely in a non-reliable manner (i.e. it can continue operate without you), then you need some sort of gateway and firewall which can isolate the control network from the wider world, and which can restrict the types as well as the volumes of communications which can pass through. You also need to accept that your access may from time to time be cut off by an attacker.

Built-in custom encryption and authentication protocols never stand up to a serious attempt to crack them. The problem is rarely in the math, it's in the implementation. There are only a handful of people in the world who actually know what they are doing in this field, and I've never heard of any of them working for the control industry. If you think you need encryption or authentication, then the only realistic choice would be to pick a very well known and widely used off the shelf software implementation (an actual implementation - not just specification), and tunnel your industrial control protocol over it. Even then, you need to provide a means for security updates because even the very best implementations have bugs which can be exploited.

As for Modbus/TCP versus other industrial protocols, there may be reasons why one may be better than the other in various applications, but security is a complete red herring in any of them.
 
I think we are talking past one another... The OP (original poster) was asking about a specific application, one that required his RTU to talk with 3rd parties. This is a FAR different use case than some of the other posters have assumed, a common case where all communications are held onsite and don't go offsite.

I have few problems using modbus within the confines of single physical location so long as the modbus interfaces are all within the site. But, OP is not asking about a single site, but is asking about an 'API for an RTU' and '3rd parties', which sounds a lot like multiple sites that require outside access. That 3rd party requirement negates any argument about physical access protecting modbus, since 3rd parties are most likely offsite and out of the control of the engineer designing the system.

So using that use case, if you go back to modbus all the glaring security problems start to look really scary when 3rd party access is a requirement. What puts limits on that 3rd party? A contract, or would you rather have some technical enforcement on your side?

Check out https://ics-radar.shodan.io/ sometime. Shodan scans for internet addressable control systems, the current tallies of internet addressable control systems are:

BACnet: 10,530
DNP3: 588
EtherNet/IP: 3,943
Modbus: 13,949
Niagara Fox: 23,294
Niagara Fox with SSL: 159
Siemens S7: 2,701

Mike
 
C

controlobserver

> I think we are talking past one another... The OP (original poster) was asking about a specific application,
> one that required his RTU to talk with 3rd parties. This is a FAR different use case than some of the other posters have
> assumed, a common case where all communications are held onsite and don't go offsite.

Yes, this is why I'm saying that security is a red herring so far as the industrial protocol is concerned. If security is required, then use off the shelf IT security methods and systems and tunnel your data over it. There are even appliance type boxes to do this.

If you are going to integrate it into the RTU, then make sure the hardware is running an off the shelf OS like Linux or FreeBSD, and use VPN software or SSH tunnelling, or something like that.

Either way, make sure there is a way to update the system that is handing the security. If you need security, then you need a software update system.

Leave the communications security to the experts. There is no way that someone working in the automation field is going to get this right when designing and implementing a special protocol where security is built into the data protocol itself.

To go back to what the OP was asking about, I would offer two protocol choices running on different ports. For one I would offer Modbus/TCP. Any other industrial protocol will be unrealistic to implement within the time limits of your project.

For a REST API over HTTP, Modbus/TCP can be considered a sort of REST protocol. You can mirror this quite well in HTTP. A read is a GET, a write is a POST. Read or write from REST endpoints which correspond to Modbus data table addresses. For example doing a GET on "/RTU/coils/50?quantity=10" would be to read 10 coils starting at coil 50. Return the data as a JSON array e.g. "[true, false, false, true, true, true, false, false, false, false]".

Doing a POST on "/RTU/coil/50" with a content payload of"[true,false,true]" would write 3 coils starting at coil 50.

Use the HTTP error codes to indicate success or failure. Don't worry about mirroring the Modbus error codes, since HTTP is going to be a lot easier to troubleshoot, so you don't need detailed error feedback (you could return an HTML web page with the error message if you wish).

Anybody who has done any web programming would understand the above immediately once they know what a coil or register is. The general approach is bog standard stuff for them.

Also, don't worry about the Modbus limits on read and write quantities. There's no reason to impose those limits on your REST protocol.

The above will give you both a standard industrial protocol (Modbus/TCP), plus an HTTP protocol with the least amount of additional effort. If you're going to bother with an HTTP protocol, you may as well also offer a web page at another set of endpoints which read the data and display it in human readable form instead of JSON data to make troubleshooting it easier.

For security, see what I've said above. Just tunnel your data over an off the shelf software.

You may wish to look at doing the whole project with a Rasberry Pi. The Pi will give you the hardware and interfacing options, and the Linux OS will give you a very good toolkit to build the software out of. The price is hard to beat as well.
 
Maybe the master thesis should be on security and the prevalence of lousy MODBUS.

At the AHR show (heating A/C show) in Chicago one vendor stated to have a VAV box controller which supports HTTPS and has an OPC UA server onboard.

You would want to think the industrial world is going to get their "IP act together" someday soon.

And for those that like to be Microsoft critical, OPC UA is not required to be on a Microsoft OS.
 
My sentiments also...
This might be of interest along these lines....

https://github.com/StevePo/ws-squared

regards,
nick

> To go back to what the OP was asking about, I would offer two protocol choices running on different ports. For one I
> would offer Modbus/TCP. Any other industrial protocol will be unrealistic to implement within the time limits of your project.

> For a REST API over HTTP, Modbus/TCP can be considered a sort of REST protocol. You can mirror this quite well in
> HTTP. A read is a GET, a write is a POST. Read or write from REST endpoints ......

> You may wish to look at doing the whole project with a Rasberry Pi. The Pi will give you the hardware and
> interfacing options, and the Linux OS will give you a very good toolkit to build the software out of. The price is hard
> to beat as well.
 
S
> Actually, no. All you need to do with Modbus is start writing zeros at holding register offset
> 0 and keep going up to 65K, ignoring errors and you will likely crash any PLC program (if a
> PLC) or totally screw up operations with bad setpoints & flows, all while exposing zero
> knowledge of the system!

Depends on two factors the implementer has significant control of:

1) That Modbus or other insecure protocol can access any register in the controller. This is less and less often the case. Many PLC's have more than 65K registers and thus by definition only part of the memory will be accessible (assuming a single node address per PLC). Other PLC's require that their registers be explicitly mapped to Modbus ranges by the developer, and in that scenario, he'll probably not map the entire controller. And finally, some PLC makers, realizing the potential security hole in Modbus and other legacy protocols, do support them, but only with a dedicated "sandbox" area of memory and do not allow Modbus access to the general bulk memory area of the controller.

2) That the controller program doesn't qualify command inputs as being within valid ranges, before acting on them.

If those two things are in place, the malicious Modbus client may be able to make the system do some undesired things, but within normal operating limits, and he probably can't crash the PLC.
 
Top