Jump to content

Protocol converter

From Wikipedia, the free encyclopedia
(Redirected from Protocol Bridge)

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 tools to achieve the desired interoperability. Protocols are software installed on the routers, which convert the data formats, data rate and protocols of one network into the protocols of the network in which data is navigating. There are varieties of protocols used in different fields like power generation, transmission and distribution, oil and gas, automation, utilities, and remote monitoring applications. The major protocol translation messages involve conversion of data messages, events, commands, and time synchronization.

General architecture

[edit]
Protocol converters, illustrated

The general architecture of a protocol converter includes 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 data from the database and sends 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 RS-232, RS-485, Ethernet, etc.

Applications of protocol converters

[edit]

Protocol Converter applications vary from industry to industry. The protocol converter can be a software converter, hardware converter, or an integrated converter depending on the protocols.

  • Some of the key applications are:
    • Substation automation
    • Building automation
    • Process automation

The major protocols used in each area of application are listed under List of automation protocols.

Latency and engineering issues in using protocol converters

[edit]

Protocol Converters are generally used for transforming data and commands from one 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 types of conversions depending on the application and domain in which this is being used. The simplest and most 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, for example: where the data is formatted, the data types supported, the object models, etc. They are so different that the conversion engine needs to make modifications not only in framing, but in mapping information for each type of data, command, and in some cases, the object models. Also, there might be user configurations required in defining the mapping of supported and non-supported data types

These transformations, however, bring about conversion advantages, communication delay, processing latency, and an overall end to end processing time which is finite and needs to be considered in all solution designs.

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 to 20 milliseconds 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, the majority of such architectures would involve configuration and mapping which both require considerable engineering effort and engineering time. These need to be considered while defining project schedules.

See also

[edit]
[edit]