Can we implement crc-32 for MODBUS?

J

Thread Starter

jignesh v mehta

sir/madam,
We are a group design engineers working on a Safety critical project. We were intersted in useing MODBUS protocol for some of the non vital communication links involved in our project.
As per the requirements, we have to achieve a hamming distance of minimum 5.

The use CRC-16 does not permit this as the hamming distance of CRC-16 is 4.CRC-32 seems to satisfy our requirement as it has a hamming distance of 5.

We are facing a problem with the number of bits assigned for error checking. The MODBUS protocol limits it to 16 bits. But we intend to use CRC-32 which requires 32 bits. It aslo allots 253 bytes for data. Our data will be around 128 bytes. so we plan to keep 32 bits for CRC. Having done that, can we still claim to have implemented modbus protocol.

we need this clarification, to be written in our documents. it would be kind of you, if you could answer this question of ours.

Thanking you.

your's sincerely
Jignesh v Mehta
DESIGN ENGINEER
REPD (R&D)
 
L

Lewis Bodden

NO! If you don't follow the Protocol completely don't say that it is MODBUS compatible. It will not work with others that follow the protocol spec. There are to many companies out there that claim to be MODBUS compatible and are not. Yes it uses the MODBUS structure but data bytes are swapped or there may be differences in addressing.

It is arguable that a 32 bit CRC would give you measurably more security than a 16 bit CRC.

Using the MODBUS Protocol with 16 bit CRC and other error detection like Parity checks for byte errors, Framing checks, and testing for valid message structure is highly reliable.

If you desire more security and want to keep in compliance with the MODBUS "Standard", I would suggest that you implement the "Standard" MODBUS protocol and embed additional checks within the data. If you are sending 128 bytes send an additional 4 bytes as a check of the data field only.

You should investigate other protocols that have more security.

Some additional features are:

Serialize the communications packets. If the number of the current packet is not one more than the last (allowing for roll over) then a communication has been missed. Also if the response does not have the correct sequence number the requested data does not match.

Use specific characters to mark the beginning and end of the message.

Always use a byte count to indicate the length of the message.

[email protected]
 
sir,
iam a design engineer working on the same project on which the earlier mail was based. the problem we are facing is that we have to achieve a minimum hamming distance of 5 in our codewords.
but crc-16 cannot give it. crc-32 seem to have a minimum hamming distance of 5.

according to the suggestions given by you, we could add a few bits as check bits with the data.
but adding 2 more bits to the error checking field of the frame seems to solve our problem.it will reduce the computations required to fill the other check bits if added in the data field.

regards
k.sai naidu
design engineer
REPD(R&D)
Hbl nife power systems
india
 
D
If you are looking for a simple protocol that can implement a 32bit CRC have a look at the SNAP protocol.
 
A

Alex Pavloff

You could, but it would require additional client side processing.

For example: Put your data in the first 64 holding or input registers.
40000-40064. In the 65th and 66th holding registers, put your 32-bit CRC.
Use a standard holding or input register read of the first 66 registers, hack the last 2 words off the end, and use it as your 32 bit CRC to check
the first 64 bits. (Or put it at the front -- you get the idea).

Now, the real question is -- does making the data available through Modbus when requiring more steps actually help your customers? If not, then don't bother with Modbus.

Alex Pavloff - [email protected]
Eason Technology -- www.eason.com
 
J

jignesh v mehta

You had suggested SNAP because we need of CRC-32 for error detecting MODBUS protocol. MODBUS is best fit for our system but we have to use crc-32 to get hamming distance-5. Due to lack of time and information we are unable to select SNAP. So, is SNAP is similer to MODBUS or not?

-Jignesh Mehta
(Sr. Design Engineer)
HBLNIFE Power System Ltd.
HYDERABAD
INDIA
 
J

jignesh v mehta

Is MODBUS is only application layer protocol or application layer plus data link layer protocol?

In MODBUS specifies it is application layer protocol but for error detecting it is using ARQ(Automatic Repeat Request) as a Backword Error Conrol (BEC) from Data link layer. And it also detecting error through 2 byte error checking. Then, why MODBUS is only a application layer protocol?

-Jignesh Mehta
(Sr. Design Engineer)
HBLNIFE Power System Ltd.
Hyderabad,
INDIA.
 
R

Rob Hulsebos

Hi,
Of course you can use a CRC32 if you wish. Only, it can't be called Modbus anymore. If you want to remain Modbus-compatible and still have Hd 5, perhaps other tricks should be used. For example, put your CRC32 in the datafield of a Modbus message (using two registerlocations). Or else, use a trick like some safety fieldbus systems do:

- take your data and copy it in buffer1
- invert all data from buffer1 and put it in buffer2
- send a single Modbus message containing the contents of buffer1 and 2
- at the receiver, check the CRC, and if Ok, also check that buffer1 and 2 are each others inverse, if OK use it, else discard

This might increase the Hd to more than 4, but I am not sure that it reaches Hd 5, perhaps someone with more mathematical background knows it.

A disadvantage is that you always have double-length messages.

Rob Hulsebos
 
L

Lynn August Linse

You are shooting yourself in the foot to use a CRC32 and calling it Modbus. I'm sure a very small minority of your users care about your "hamming distance 5", so creating a product NO ONE can talk to seems a foolish investment no matter how genuine your intention.

Instead, if you are just polling (reading) data, then I'm sure you could obtain the same effective "hamming distance" by implementing client-side filtering - use repeated polls with CRC16 to filter-out the extremely rare even of an undetected bit error.

Or as someone else suggested, but an added CRC32 as the last 2 registers of your data. So to read 10 registers at 400001, poll for 12 and ignore the
last 2 unless you can handle CRC32. Then normal clients only see the real CRC16 yet function, while your safety critical clients would ALSO double check the CRC32.

I think the 2nd option (CRC32 as last 2 registers) would be your safest bet.

The only value Modbus offers is there are thousands of products out there which speak it - with the CRC16 that is. The instant you require a CRC32 you (and your customer) lose this value. A customer could possibly sue you for fraud if you claimed Modbus and then they found out NO existing Modbus products in the world can work with you for anything. You might be safer to write your own protocol and call it "RepdBus" or "MehtaBus".

Best Regards

Lynn August Linse, alist (at) linse (dot) org
IA Firmware Specialist, Digi Int'l (www.digi.com)
26741 Portola Pkwy, Suite 1E #242
Foothill Ranch CA 92610-1743 USA
Ph/Fx: 949-916-1524 (voice message usually)
 
M

Mark Hensley

Hello Lewis,

Thanks for taking a turn at keeping Modbus Protocol pure to what Modicon intended it to be. As we continue to see attempts at strange
interpretations of the specification I have to wonder if we need to rewrite the protocol document using PICTURES. Obviously the words Modicon has used seem to keep people thinking that random changes to the protocol are
exceptable. I say that with obvious sarcasm as I don't know that I have read a single protocol document that is as clear as the Modbus Protocol
guide. Ok, Omron Host is pretty clear as well. I can't believe we still have questions and proposals like this one.

To the progenitor of this thread, if it isn't in the Modbus Protocol Guide you can't call it Modbus or even "Modbus Like".
 
J

Jignesh Mehta

We are in fail safe projects. So, we are in need of health check & diagnostic function codes in MODBUS.
It looks like the Diagnostic function code of MODBUS have been designed for modicon controllers only. And we are using Intel-486 processor. can we use this diagnostic function code(0x08) for our system? and if we can, we actually plan to use only some of the subfunction codes. is it fine or do we have to take all the subfunctions into consideration.
Please suggest us.

-Jignesh Mehta
[email protected]
HBLNIFE Power System Ltd.
Hyderabad
INDIA.
 
Jignesh Mehta
Hamming distance 6 is offered by CAN protocol. Do look this up as a viable alternative to Modbus with cRC32.

Should you need more info on CAN contact me at [email protected]. we have several critical systems, including on-board vehicle control systems functioning with CAN.

Suresh
Director , ICON microcircuits & software technologies pvt ltd, Chennai,
India
 
You might want to revisit your Hamming distance spec. Specifying a Hamming distance of 5 versus 4 might not actually provide any real benefit in a
typical industrial environment.

Using the Hamming distance as a design metric assumes completely random distribution of bit errors found on low S/N links. In industrial
environments with properly installed communication links, S/N is high.

Errors are caused by infrequent bursts of noise from arcing contactors, VFD's, ground hum, static discharges and the like. These burst and sporadic
data stream errors represent an extremely small percentage of the complete number of random error combinations possible in a data stream. CRCs are designed specifically to handle these burst and sporadic errors.

16 bit CRCs can detect all one and two bit errors, all errors with odd numbers of bits, all burst errors with length <= 16, 99.997% of 17 bit burst errors, and 99.998% of 18+ bit burst errors. A high quality link in an industrial environment may only suffer only a handful of CRC errors in a day, perhaps very few of them would be 18+ bit burst type. Furthermore, your device commands can be designed in such a way that minimize the impact of a bad packet if swallowed. You might then conclude the 16 bit CRC is good enough.

The 32 bit CRC provides a much higher degree of assurance that you won't swallow a bad packet. Each additional bit of a CRC roughly halves the probability of passing an undetected burst error.

For Modbus/TCP, the 16 bit CRC is stripped out because it doesn't add any value on top of the 32 bit Ethernet CRC and the 16 bit TCP checksum. Commonly used TCP data-link layer frames (frame relay, PPP, etc) other than Ethernet also have error detection.

If you are stuck with a serial connection to your device you could swap the 16 bit CRC for a 32 bit CRC, but then it isn't Modbus anymore.

There's nothing in the Modbus spec that says you can't calculate any CRC you want and write it into an unused register adjacent to whatever block you are reading. Then you check the normal CRC at the data-link layer, and check the 'register' CRC at the application layer. Same goes for write access, but in reverse.

However, the end result is the same either way - nobody else's Modbus master will work with your slave, and your master won't work with anyone else's slave. So you can call it whatever you want, as long as it isn't Modbus.

Best regards,
Joe Manns
Arden Environmental Engineering Inc.
3550 Lexington Ave. N
Shoreview, MN 55126
Ph 651-484-5415
Fax 651-484-5568
 
J
This input may come a bit late...

The hamming distance required for safety depends on the message length. E.g. ProfiSafe uses hamming distance of 4 (CRC16) for messages up to 12 bytes, and hamming distance of 5 (CRC32) for messages up to 122 bytes. Thus, I believe if you only read a couple of registers at the time the CRC 16 should be OK.

Now, for safety approval just CRC does not cut it. Over and above a normal protocol you need to add "codeword", sequence counter, and some other stuff. These additions would make the protocol something that can no longer be called Modbus. See e.g. http://www.itk.ntnu.no/fag/fordypning/SIE3092/SIE30AB/PDF/ProfiSafe-Profil-1 00e.pdf

Lastly, if you change to CRC32 it is no longer Modbus.

Jonas Berge
==================
[email protected]
www.smar.com
 
Top