How to make modbus protocol driver in the embedded application for fail-safe system? What is the minimum hamming distance can be achieved by the modbus?
The Modbus protocol uses CRC checksum. The CRC consists of two bytes. The Modbus frame may conssists of hundred's of bytes. The minimum frame consists of 5 bytes (+ CRC) so is hard to correct errors using Hamming distance coding. The CRC inform you that the frame is correct or not. If there are errors you must transmit the data again. For details about Modbus Protocol try www.modbus.org or www.modicon.com.
Fail safe system is a very big topic. Details on how best to implement a fail safe system are not specific to the choice of communications protocol but instead, have more to do with redundant hardware mechanisms that will ensure the system will achieve a safe state when a failure occurs. For example, a fail safe fuel control valve will typically have a spring to return the valve to a safe state (typically full closed) if the actuator fails. The control electronics may well have fail safety built in too, in terms of redundant sensors or communications channels. Search the internet for "fail safe" and start reading. Embedded Systems magazine has had many good articles over the years on fault tolerance and safety in embedded systems. See www.embedded.com.
Minimum Hamming distance for Modbus is guaranteed to be at least 2 IF parity is used. This is true for ASCII and RTU modes alike. With that said remember that the LRC and CRC are dsigned to provide error detection The degree to which the LRC and CRC algorithms provide error detection (example: how many single or multi-bit errors can be detected) is beyond the scope of this meager reply. But plenty of articles are available online regarding CRC theory. More reading...
Some of the "safety protocols" I see developing here do things like require all data to be duplicated in every message - and the second copy may be inverted. Others add a stronger "integrity" check - crypto algorithms like MD5 or SHA1 are well studied & documented (both are in IETF/RFC & source code can be found at www.openssl.org). These are things unrealted to Modbus if done 100% in the data portion of a message.
If I were to design such a product, I'd make the data appear in duplicate in 2 areas. 1 area is read-only and 100% Modbus-like and not what you'd consider safe. Common OPC servers and other data users could access this straight off the shelf.
The other area would still use a standard Modbus message form and CRC16, but support a vendor-specific function code & enforce special rules in the coding of the data. Likely only drivers understanding these rules & function code could access this, but you could achieve any level of integrity certainty you desire.
Bottom line is "can you have your cake & eat it too?". Modbus/RTU is Modbus/RTU with a CRC16. If you do anything else, please just don't call it Modbus. No Modbus+CRC32 please.
Regards
Lynn August Linse IA Firmware Specialist, Digi Int'l (www.digi.com)
What is the application for this shutdown system? Process control or discrete factory automation?
It takes much more than CRC32 to make a bus safe.
Several standard safety buses exist and are already in use. Perhaps you can use one of those? ProfiSafe (currently only applicable to PROFIBUS-DP), SafetyBUS p, AS-I safety at work, DeviceNet Safe, and Interbus Safety all meet IEC 61508 SIL3, DIN 19250 AK6, and EN 954-1 Category 4 requirements. These buses are very much factory automation related dealing with discrete signals, robots, and light barriers suitable for machine safety rather than process safety. ProfiSafe could possibly be applied to PROFIBUS-PA (for
process) in the future, but safety for certain DPv1 (acyclic) functions are not supported yet.
The good news for the process industries is that the Fieldbus Foundation has launched a safety initiative . The FFSIS project will develop technical specifications and guidelines for safety instrumented systems. The Fieldbus
Foundation and device manufacturers will develop safety concepts and products which comply with IEC 61508. See: http://www.fieldbus.org/News/default.asp?news_x_language_id=267
Facebook
Google
GitHub
Linkedin
