ipConv Architecture

In general, two solutions come to mind for the implementation of gateways:

• direct conversion from one protocol to the other
• conversion of protocol to and from a standardized format which does not depend on a protocol

The first approach is well suited for simple one-to-one conversions between related protocols. Both protocols are very close, i.e. there is a great resemblance between both protocols in the way information is represented. This approach offers only a very limited degree of flexibility with respect to expanding and decoupling both protocols. This need not necessarily be a disadvantage, if flexibility is not the top priority, as is the case in conversions from Profibus-DP to Modbus.

The second approach relies on the conversion of data from a protocol to a standardized protocol independent universal format. This universal representation must be powerful enough to cover all protocols. This method is best suited for universal conversions where the target protocol is not specified. It offers the highest degree of flexibility and modular expansion allowing decoupling of different protocols.

ipConv relies on the second approach, data is converted from a protocol-specific to a standardized protocol independent representation and back again.

ipConv is a modular system comprising several protocol stacks assuming the protocol-specific communication tasks.  Outwardly, the protocol stacks are connected to external communication partners. Internally, they are able to exchange data via a standardized interface with the node module (node). Generally, the protocol stacks are not directly connected to each other.

The normalized interface allows information to be represented in a way which is protocol independent, so that data can be exchanged between different protocol stacks.
Protocol stacks translate information from the protocol-specific representation to the normalized form and back. During this process, telegrams are broken down into their atomic units such as individual single indications.

Protocol stacks consist of one or several modules which are self-contained functional units. Simple protocol stacks usually comprise one single module. More complex protocols based on the OSI Layer Model will consist of several modules. In this case the module assumes the functionality of an OSI layer (e.g. link layer or application layer). Each module (as well as the link layer module) has its own interface to the node module, which enables the transfer of administrative data such as the connection status to a specific RTU.

Additional tasks of administrative modules are for instance failover control, time synching etc.

The node takes care of reception, processing and dispatching of normalized information. During the start-up phase it establishes a connection to each module which is then used for internal data transmission.

All information dispatched to and from the node is transmitted in normalized form. Generally normalized information has these attributes:

• information address
• information type
• status, quality
• value
• time stamp (optional)
• further type-dependent attributes

The information type determines how the attributes are to be interpreted. Information is addressed via a normalized address (NA) which unambiguously identifies an information unit inside a module in a specified transmission direction. The normalized addresses are structured in a way that allows tracing of the protocol specific address and vice versa. The actual structure of the normalized address is determined by a protocol stack.

Each piece of information in the node passes through the following stages:

• Reception from the source module
  At this point there is a check whether the received information has been configured or not. If this is not the case, the information is rejected and the appropriate message is written to the logfile.
• Processing
  Configured information can be processed as determined by the configuration parameters, it can be scaled, inverted, converted etc.
• Dispatching
  The configuration also specifies where the information is to be transmitted, i.e. to which module and with what target NA (normalized address). At this point the information type is also converted, if the source type is not identical to the target type.
• Transmission to the target module
  Before the information is sent to the target module, the node checks whether the target NA has been configured. If this is not the case, the information is rejected and the appropriate message is written to the logfile. Similar to the reception, additional information processing might take place at this point.

It is the node configuration which determines how the information is processed. It defines exactly what information (address, type) comes from a module and proceeds to a module.

Only if there is status or value change data (single indications, measured values etc.) is transmitted in monitoring direction. In control direction all data (commands, set points etc.) is transmitted directly. Generally the behavior depends on the normalized information type.

A protocol stack is an organizational unit of one or more protocol modules that helps to simplify configuration. At runtime only the individual protocol modules become active.

A protocol module is connected to a remote communication partner as well as to the node. Its task is to maintain the data flow with the remote station and to translate the data from the protocol specific into normalized form and vice versa.
A protocol module consists of a clearly defined "vocabulary" of normalized information which it can exchange with the node. There are two basic categories:

• process information
• internal information

Process information is data that is directly transmitted to/from the communication partner. Inside the protocol module, only the conversion of addresses and values between the protocol specific and normalized form takes place. The function range of a protocol defines what normalized information types can be processed by a protocol module.

Internal information on the other hand is only indirectly related to the remote station. It is generated and processed directly inside the protocol module and has an organizational function. If, for instance the remote station does not respond, this fact is often signaled to the node with an internal message.

Protocol modules are self-contained units which are able to set up and maintain data traffic with the remote station without any instructions from outside. For instance a slave module has an image of all the information to be transmitted to the corresponding master and can respond to all requests independently, without referring back to the node. The transmission mode to be used (spontaneous, polling etc.) depends on the protocol. The node provides all the information to the module in case of value / status changes.  In contrast the master module makes sure that a general poll is executed, if a new RTU is recognized, thus ensuring that all information with respect to this RTU is fully up-to-date.

For tracing the data traffic at the communication interface, each protocol module offers the possibility to log the data at different levels of abstraction.

In addition to protocol modules, there are further modules that do not have any direct communication tasks. For example the NTP module takes care of system clock synchronization via the NTP protocol. Administrative modules, too, use the normalized interface to communicate with the system.