In general, two solutions come to mind for the implementation of protocol
converters:
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.
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.
Node and Normalized Interface
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.
Protocol Stacks and Modules
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.
Node and Normalized Interface