Modbus RTU Address Limit

[smackay]

I am having an issue address hardware, using Modbus RTU, with Memory Map items above 70001.  When using the built in functions the address are entered zero based instead of 40001 based.  The following address (70002-40001) yielded a problem.  For whatever reason address (70001-40001) is the max address value that will work with the built in Modbus functions.  (70002-40001) wraps back around to (40001-40001).  Lots of other PC type software programs allow relative addressing up to ~ 100,000 as a 16 bit integer will allow for 2^-1 = 65535 or a relative address of 65535 + 40001 = 105,536.  I don't understand the artificial boundary that has been implemented.  It is not based on power of 2 boundaries such as 2^15 =  32768 + 40001 = 72769.

I am using DAQFactory Ver. 5.91 Build 2203.

Is there a work around.  I am in a pickle.

Thank you,

Shawn

[AzeoTech]

It is important to understand that there really is just one range of Modbus addresses and that's 0 - 65535.  Those are the values that are sent to the device.  Everything else is just arbitrary mapping to those values.  There are generally three standards for this mapping, but even that gets messed up by manufacturers.  Here are the three:

1) straight mapping, or what I often called zero indexed.  In this case, the docs will indicate Modbus address 53 and mean that the 53 should be sent down the wire to the device.  In my opinion all new devices should use this mapping because its simple and hard to mess up

2) what I call 40001 mapping.  This is the original mapping scheme of Modbus created way back when.  In this case, the digit in the 10,000's place indicates what type of register you want.  no digit (0) = coil, 1 = input status, 3 = input register, and 4 = holding register.  The funny part is that those numbers don't line up with the corresponding function code.  For example, to read an input register you usually use function code 4, and to read a holding register you use 3.  Go figure!   Other than indicating the function to use, the 10,000's place has no meaning to the actual address so gets stripped off.  

Now to add to that, the folks that originally created this scheme apparently thought that the electricians who were the ones originally installing PLC's back in the day couldn't count from 0, so while internally the address starts at 0, this arbitrary mapping starts at 1.  So, 40,001 is the first holding register and corresponds to 0 down the wire.  40,002 corresponds to 1, etc.  30,001 corresponds to the first input register, again 0 down the wire.  

So to convert from this scheme to the actual down the wire address you strip off the 10,000's place and subtract 1.  DAQFactory will do this automatically for you the first time you read a value between 30,001 and 49,999.

The problem with this scheme, besides it inherent confusion, especially with the +1 factor and the fact that it overlaps the straight mapping scheme, is that its limited to 9999 addresses per function.  So, somewhere along the line they came up with the third scheme:

3) let's call it 400001 mapping (usually called extended).  This is identical to the 40001 mapping except the function code indicator is in the 100,000's place instead of the 10,000's place.  This makes it so the full 65536 addresses can be used.  To convert to straight mapping, strip off the 100,000's place and subtract 1.  This mapping at least does not overlap with straight mapping except for coils, so is a little less confusing than 40001 mapping, but still, in my opinion, unnecessary.

DAQFactory does not directly recognize 400001 mapping and so if your documentation specifies registers in 400001 notation you will have to do the strip and subtract routine in your head.  

Now, as I mentioned, 40001 notation has an extra confusion factor because it overlaps with the straight mapping, and well, they all use 0-65535 when they go down the wire.  Because of this, its possible for a device to have registers in the 30001 - 49999 range, but actually be using straight mapping.  In these cases, you can tell DAQFactory to only use straight mapping by simply attempting to read a register in the 50001+ range once at startup.  It will probably timeout, but it doesn't matter.  DAQFactory will lock into straight mapping and when you tell it to read register 41832 it will actually send 41832 down the wire and not 1831.

That all said, 70001 is not a valid address in any of the Modbus register mappings I've ever heard of.  Straight mapping is going to range from 0 to 65535.  40001 mapping will range from 1 to 19999 and 30001 to 49999.  400001 mapping will range from 1-65536, 100001-165536, 300001 - 365536 and 400001 - 465536.

And if that's not enough: it still amazes me that hardware manufacturers mess all this up.  For example, the SunSpec standard for solar inverters has a particular modbus map for reading common items from inverters.  They use the 400,001 mapping.  The manufactures then use this standard, but in several cases I've seen them mess it up.  I won't name names, but what they did was specify that a register is at, for example 40,001, which you would expect to either be holding register 0 down the wire if using 40001 mapping, or register 40001 if using straight mapping.  But no, the actual down the wire register is 40000.  So they subtracted 1, but didn't strip the four.  I talked with the folks at Sunspec and they explained that the register is supposed to be 440001, which would of course map to 40000 down the wire but the manufacturer must have messed it up their understanding and their documentation and instead documented the register as 40001.  Now why Sunspec chose to use such a confusing spot in the register map I'm not sure despite their explanation, but in the end it was really the manufacturers misunderstanding of Modbus.

And this is just one example.  So the lesson here is that although most devices follow one of the above, there are still devices out there that do weird things like just subtract one, so sometimes you have to experiment and try and figure out what on earth the manufacturer was thinking.

 

[jesawyers]

Hi All,

I just wanted to put my two cents in on this subject because I have fought this subject my entire career in the power industry.

As we all know, there are latterly thousands of devices that support MODBUS.  But you have to ask the question...Is it MODBUS compliant with the actual MODBUS protocol as defined by specification at www.modbus.org?

Many products only implement part of the full MODBUS protocol and others, like in the case above, implement extensions specific to their products.  This is fine but can lead to confusion because the actual MODBUS specification is not being implemented.

As our awesome Azeo Tech Guru has pointed out, the biggest issue is if the MODBUS device uses zero based addressing or 1 based addressing.  We all have seen both and I have seen devices use 1 based addressing but the actual packet uses zero based addressing.

If you look in the actual MODBUS specification, it specifically states register addresses are from 0x0000 to 0xFFFF.  Notice that they don't start at 40000.  

MODBUS is a very simple protocol if implemented per the specification but it's beginning to run in to age issues.  MODBUS is still a popular protocol because it's been around for a long time.

However, one item we are running into is the lack of security features within the protocol.  MODBUS can be spoofed quite easily when using MODBUS/TCP.  Cyber Security is the new hot topic in the automation industry and the MODBUS protocol needs to be updated to improve Data Integrity, Authentication, Non-Repuditation, and Replay Protection.  These security holes have been identified by many companies and are pushing the MODBUS organization to update the protocol.  In particular, we are being pushed by the US Navy to find methods to better secure MODBUS communication links.

For our Azeo Tech Guru, I have attached an PDF showing a possible solution that the authors proposed for doing this that I found on the Internet.  We are looking at rolling our own MODBUS protocol based on this proposed solution but it would be better if the MODBUS.org folks jump on this to keep the MODBUS protocol relevant in today's cyber security threats.

Later...John

A_Secure_MODBUS_Protocol.pdf

Modbus_Application_Protocol_V1_1b3.pdf

[AzeoTech]

That's an interesting way to secure Modbus.  I'm glad to see that its really just a wrapper for the standard Modbus, however, I think it misses a key point:

It never addresses DoS attacks, which are pretty easy to affect on low power PLC's that can't handle the number of connections a real PC based server can.  I actually saw this sort of thing recently with some remote PLC's insecurely attached to cell modems and thus public IPs.  Even though the "hacker" couldn't control anything, their connection would tie up the single socket available and prevented the actual user from reading their data.  DoS attacks are pretty much impossible to prevent on PLC level if you are publically facing.  

It is for this reason that I think securing Modbus is kind of a waste of time.  The Modbus traffic really should just be on a secured network in the first place and not in a place where it can be accessed by the Internet, or even other non-SCADA parts of the corporate LAN.  For remote access, one should use a push mechanism out of the PLC instead a query mechanism which allows you to keep the PLC securely behind a firewall.  This eliminates DoS because the firewall can handle it and is designed for it.  The rest can be handled with SSL and some of the other tricks they mentioned when communicating with the push gateway.  DAQConnect uses exactly this architecture, where a gateway box behind the firewall communicates over Modbus locally and then pushes the results to the DAQConnect server.  

I'm not trying to really toot DAQConnect's horn on this, but do think that a push mechanism offers better protection than any secure protocol at the PLC level.  It really comes down to the fact that PLC's are inherently simple and low CPU powered devices.  The fact that they are simple is why they are more reliable than PC based controllers.  The more you add to them to make them more complicated, the more they become like PCs and less reliable.  So, I believe you are better off sticking with simple, i.e. old fashion Modbus, at the PLC level and if you need the extra security layers, use a variety of methods such as the push mechanism I mentioned using additional hardware to put the complexity outside the PLC.

An example of this is another project I'm helping with.  In this case, the customer is using DAQFactory to handle a large subsystem of a plant.  They've used DAQFactory for years and have a well tested application.  Their customer wants to integrate the data into a larger plant wide SCADA system from another manufacturer.  My concern with this was the affects of the rest of the SCADA system and network traffic on the DAQFactory subsystem and its PLCs.  For this reason, and because they really wanted to use Ethernet/IP, it was decided to use a protocol translator between Ethernet/IP and Modbus.  DAQFactory acts as the Modbus slave and makes the data points available to the translator.  The key thing here though and why I mention it is that I insisted that the translator - DAQFactory link be over serial and not simply on the overall SCADA network.  That way, the DAQFactory powered subsystem is pretty much completely isolated from the rest of the system except for the data needed by the main system which is passed over serial.  In this way the DAQFactory subsystem is protected from everything, even DoS since a serial connection is limited to 115k baud at most, which really limits the traffic.  By sticking with Modbus for this link too, it means DAQFactory has to spend a whole lot less CPU power generating the rather simple Modbus responses.

 

[jesawyers]

Hi Guru...Yep completely agree about the DoS attacks and the use of a firewall.  I'm sure I'm stating the obvious, but network security should be approached with multi-layered solutions in mind.

On our turbine control systems we are delivering to the US Navy, we are implementing firewalls with deep packet inspection as our current security solution since they still want to still use MODBUS. 

One item as part of the multi-layered security solution is also physical security which most folks ignore.  The last statistic I saw, about 60% of all security breaches come from inside the network/firewall.  That number used to be as high as 75%.  The control systems we supply are on ships with no access to the Internet.  So physical locking or disabling Ethernet ports is part of our security plan.  

Something you and others might be interested in is an organization called the Defense Information Systems Agency (DISA.mil).  DISA provides Security Technical Implementation Guides (STIGs) which identify security holes in software and hardware and solutions.  The big one we use for software are the STIGs for the various Windows releases which we use for HMI applications.

I also recommend folks visit http://energy.gov/oe/services/cybersecurity

Right before starting my current job, we received a RFQ for a turbine control system that included a bunch of Department of Energy Cyber Security requirements.  I believe this will now be standard policy for control system and implementation of Cyber Security requirements will increase control system costs.

Well nice chatting with you and hopefully our exchange will help increase control system security awareness within the Azeotech users.

Later...John