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.

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.

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.

• List of automation protocols
• Vehicle bus
• List of network protocols
• Universal gateway
• Cloud storage gateway

• Protocol Converter for Real Time management system
• White-Paper: Impact of using protocol converters for substation modernization projects using iec 61850