Protocol converter: Difference between revisions
| Line 16: | Line 16: | ||
**Building Automation |
**Building Automation |
||
**Process Automation |
**Process Automation |
||
== Latency & Engineering Issues in using Protocol Converters == |
|||
Protocol Converters are generally used for transforming data and commands from device or application to another. This necessarily involves transformation of data, commands, their representation, encoding and framing to achieve the conversion. |
|||
There are simple and complex type of conversions depending on the application and domain in which this is being used. The most simplest and commonly used conversion is protocol conversion between Modbus RTU and Modbus TCP. In this conversion, there is no change in the overall framing. Hence it is easy to take the Serial Modbus RTU frame and encapsulate it in a TCP/UDP Socket and send it over Ethernet. Since both the protocol framings are the same, except for the actual physical layer transmission, both the application layers will interpret data similarly as long as the communication interfaces are made transparent. |
|||
However, there do exist very complex conversions, where the data format, the data types supported, the object models etc., are so different that the conversion engine needs to make modification not only in framing, but need mapping information for each type of data and command and in some cases the object models. Also, there might be user configuration required in defining the mapping, and mapping non supported data types to supported data types. |
|||
These transformations though brings about conversion advantages, also brings about communication delay, processing latency and hence an overall end to end processing time which is finite and need to be considered in all solution design. |
|||
The latency of end to end communication depends on the processing delay of the hardware and/or software being used, the protocol & conversion complexity and the solution architecture. These latencies can vary for typical industrial and energy automation applications from 10-20 milli-seconds to as high as 1 second. Solution architectures using protocol converters need to consider this latency and how it will impact the project for which converters are being considered. |
|||
Also most such architectures would involve configuration and mapping which would involve considerable engineering effort and engineering time. These also need to be considered while defining project schedules. |
|||
==External links== |
==External links== |
||
Revision as of 11:38, 2 December 2007
A Protocol Converter is a device used to convert standard or proprietary protocol of one device to the protocol suitable for the other device or master station to achieve the interoperability between the two. There are varieties of protocols used in different fields like Power Generation, Transmission & Distribution, Oil & Gas, Automaton, Utilities, AMR, Remote Monitoring applications etc. The major protocol translation messages involve conversion of data messages, events, commands, time synchronization etc.
General Architecture
The general architecture of a protocol converter include an internal master protocol communicating to the external slave devices and the data collected is used to update the internal database of the converter. When the external master requests for data the internal slave collects the same from the database and send it to the external master. There will be different schemes for handling the spontaneous reporting of events and commands. There can be different physical medium for communication on protocol-X & Y which include RS232, RS485, Ethernet, etc.
Applications of Protocol Converters
Protocol Converter applications vary from Industry to Industry. The protocol converter can be a software converter, hardware converter or an integrated one depending on the protocols.
- Some of the key applications are:
- Substation Automation
- Building Automation
- Process Automation
Latency & Engineering Issues in using Protocol Converters
Protocol Converters are generally used for transforming data and commands from device or application to another. This necessarily involves transformation of data, commands, their representation, encoding and framing to achieve the conversion.
There are simple and complex type of conversions depending on the application and domain in which this is being used. The most simplest and commonly used conversion is protocol conversion between Modbus RTU and Modbus TCP. In this conversion, there is no change in the overall framing. Hence it is easy to take the Serial Modbus RTU frame and encapsulate it in a TCP/UDP Socket and send it over Ethernet. Since both the protocol framings are the same, except for the actual physical layer transmission, both the application layers will interpret data similarly as long as the communication interfaces are made transparent.
However, there do exist very complex conversions, where the data format, the data types supported, the object models etc., are so different that the conversion engine needs to make modification not only in framing, but need mapping information for each type of data and command and in some cases the object models. Also, there might be user configuration required in defining the mapping, and mapping non supported data types to supported data types.
These transformations though brings about conversion advantages, also brings about communication delay, processing latency and hence an overall end to end processing time which is finite and need to be considered in all solution design.
The latency of end to end communication depends on the processing delay of the hardware and/or software being used, the protocol & conversion complexity and the solution architecture. These latencies can vary for typical industrial and energy automation applications from 10-20 milli-seconds to as high as 1 second. Solution architectures using protocol converters need to consider this latency and how it will impact the project for which converters are being considered.
Also most such architectures would involve configuration and mapping which would involve considerable engineering effort and engineering time. These also need to be considered while defining project schedules.