wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

13-6 Industrial Communication Systems
themselves and process the encapsulated traffic as a node, not as a router. This effectively enables purely
IP-based fieldbus nodes, which can communicate directly to legacy (non IP-based) nodes in the system.
The tunneling approach has been chosen for LonWorks or KNX/IP.
Other fieldbus systems implement a dedicated IP data link layer for the fieldbus protocol natively.
Nodes in these systems can be connected directly onto the Ethernet network without the use of a tunneling
technique. Examples are BACnet/IP or Modbus over TCP. To access other, non IP-based CN nodes,
routers are used.
Notwithstanding the ease of IP everywhere, a separation of field-level and office-level networks is still
recommended for performance and security reasons, even if—as in the case of industrial Ethernet—a
direct integration of both networks is possible. Another issue in using IP-based transport systems for
fieldbus protocols is that the original, native communication media had partly different properties.
For example, delay times, delay variance, and packet ordering may impair the fieldbus protocol state
machine itself. These effects are typically combated by using extra sequence numbers and synchronized
time-stamping on the tunnel. Once the protocol state machines are maintained, the application on
top is still influenced in its design. Application timers or feedback control loops must be aware of the
changed timing relations.
Once the problem of merging isolated network islands into a flat network hierarchy is solved, logical
boundaries within the same networking technology still exist. These are typically imposed by different
application domains to keep the traffic, addressing, and installation tasks separated. While communication
would be enabled over the flat network, the domain boundary bars traffic. The use of proxy devices
solves this problem. Proxies are basically devices that pass the process data and expose it from one
domain into another. An implementation of a proxy is placed as one instance in each domain. Strictly
speaking, a proxy can be seen as a gateway between the same technologies. An example for using proxies
is LonWorks in automation systems. In this system, address spaces are separated by address domains.
The address domains are set up according to different application domains, such as HVAC or emergency
lighting. A LonWorks proxy can expose data points of one domain to another domain. Other examples
of proxies are HTTP proxies. These are frequently used to isolate local from public IP traffic for security
reasons. For instance, the office-level network needs access to Web services in the field-level network.
While it is common practice to keep those two IP networks separate, an HTTP proxy can establish the
Web service link.
Another area of focus is protocol convergence. Today’s automation systems represent highly heterogeneous
systems. Different application service domains may use different CN technologies. The goal
for vertical access or distribution of communication services is clearly a seamless communication also
between the application domains and across all layers of the automation system. The classical approach
to let system A communicate with system B is the use of gateways. This concept is being adopted widely.
Gateways abstract the network service at the application level (e.g., data point values, trend data, schedules,
and alarms) and represent it in different networking technologies. Commonly used gateway concepts
today are based on monolithic gateways. These are devices that have the global view of one system
and expose it to another system. This concept, however, presents an inherent problem: The complexity
to integrate an arbitrary number of systems is of quadratic order. Another problem is that the gateway
is a single point of failure (SPOF) in the system.
In the move to a more service-oriented model, the communication services such as data points,
scheduling, trending, or alarming can be abstracted and presented in a single interface, which is technology
independent [DPAL]. Applications developed on such devices use the abstracted interface and
are essentially made independent from the underlying networking system. It is important to note that
this approach is only feasible for actual data communication, not the configuration of such devices,
which still remains technology specific.
As computing power is readily available, devices can add another network protocol stack to provide
native access to certain services to the system of another technology. Figure 13.4 presents an example
for this scenario. A controller implements not only the LonWorks technology but also the BACnet
© 2011 by Taylor and Francis Group, LLC