Click on the PDF button to download a PDF version of this White Paper.

Click on the "Get Acrobat" button to download a FREE copy of Acrobat Reader.

Architectural Issues Related to Ethernet TCP/IP Connectivity to LonWorks

Coactive Division
Broadband Energy Networks Inc.
7000 Terminal Square
Upper Darby PA 19082
Tel: 610.734.1245
Fax: 610.734.1263
Lawrence Silverman, President, Broadband Energy Networks
Email: lsilverman@broadbandenergynetworks.com
Submitted to: Fieldcomms International 1997

Abstract

Linking of the enterprise information network with fieldbus-based control and data networks can provide many valuable benefits such as access to data from anywhere in the enterprise and remote supervisory control. Ethernet and Internet Protocols (TCP/IP) have emerged as the standards for enterprise networks for both the public Internet as well as private intranets. LonWorks has emerged as the leading fieldbus network for many industries including building automation, industrial automation, machine control, and environmental monitoring. This paper discusses the technical issues involved in linking a fieldbus such as LonWorks to Ethernet TCP/IP networks. Architectures and components for various types of applications are presented and contrasted. Technical options for implementing these architectures are also discussed.

1.0 The Problem

In building and factory automation fieldbus solutions linking control devices and sensors are fast becoming a reality. These systems provide tremendous benefit in terms of saved wiring, decreased integration costs, and increased system flexibility. Many automation systems however have additional requirements that go beyond the scope of the fieldbus solution. These requirements include:

• remote access to the network for monitoring, diagnostics, network management
• linking of disparate fieldbus subnets
• access to the fieldbus control network from the enterprise LAN

1.1 Remote Access

Remote access to fieldbus networks can be used to reduce travel time of technicians and provide better levels of service to the customer. It can also be used to streamline efforts to collect data from remote sites. Current solutions for remote access utilize dialup approaches that do not scale to larger systems and often involve custom protocols and drivers.

1.2 Subnet Integration

Building automation applications typically utilize a fieldbus subnet per floor of a building. Linking of floors, as well as buildings across a campus is desired and often required. Linking of floors provides the possibility for security subsystems to be tied to HVAC and lighting subsystems for intelligent building management. Linking of buildings across the campus allows for optimization of energy resources, for example heating systems, which may be serving more than one building.

In factory systems different bays of a process system or multiple assembly lines in a discrete system need to be linked to provide coordinate and global data gathering.

1.3 LAN Access

Ultimately the data and supervisory control facilities that a fieldbus system can provide must be accessed by a human. Often this includes management personnel who are not located near the control system or plant floor. With increasing use of business Local Area Networks (LANs) in the enterprise, it is natural to use this is a convenient means to access the fieldbus data for analysis and storage and to provide monitoring and supervisory control functions.

2.0 Ethernet as the Physical Media

Ethernet has emerged, particularly in the past 2-3 years, as the dominant standard for computer LANs. It is supported in both multidrop (10base2) and "star" (10baseT) configurations and is very well supported with availability of hubs and routers for creating large, distributed LAN/WAN systems. New higher speed versions of Ethernet (e.g., 100Mbit) are emerging that promise to prolong the life-span of this technology for the foreseeable future.

Many of the same technical characteristics of Ethernet that make it a good choice for business networks also makes it a good choice for integrating fieldbus systems. Our choice of Ethernet is influenced heavily by its ubiquity. Its widespread use for business networks not only makes it available, but also drives down costs and provides a wide range of tools and engineer familiarity.

Some have argued that the "non-deterministic" nature of Ethernet make it unsuitable for automation systems. We believe this to be unfounded, and a result of a misguided system-level view. Process loops which require completely deterministic, high-speed performance (e.g., a position sensor feeding back to a high-speed motor control system) obviously should not be closed over slow or non-deterministic communications channels. However, many aspects of automation do not require these characteristics. The key is intelligent system design that integrates the appropriate technologies for the various subsystems.

3.0 Internet Protocol (IP) as Transport

While Ethernet provides the physical layer, the family of Internet Protocols (IP) such as TCP/IP are a sound choice for the transport protocol. This family of protocols provides various types of transport and access services to support a wide range of applications. IP has emerged as the foundation for enterprise Intranets as well as the Internet. As with Ethernet, the wide range of tools and products, as well as the knowledge base of engineering staff, makes IP a compelling choice for the protocol for integrating fieldbus networks.

From a technical standpoint, IP is well suited to the fieldbus connectivity function due to its support of both wide-area and local area links, as well as due to its support for both point-to-point (e.g., PPP over dialup) and broadcast modes.

3.1 Why Not IP for the Complete Fieldbus Solution?

IP is ill-suited for fieldbus connectivity from at least one technical aspect: data packet size. IP was designed as a mechanism for transfer of files or other large blocks of information. As such it is optimized for this problem. Control networks on the other hand are oriented toward repeated streams of small packets of control information. The main affect of this characteristic of IP is decreased bandwidth utilization. Sending small packets over IP will work, but will decrease the efficiency of the IP network in terms of actual application data throughput as a proportion of overall network bandwidth.

For these reasons connectivity solutions should address the issue of providing data "bunching", or offer a gateway approach so that the best use of the IP channel is made for the particular application.

4.0 Protocol Versus Interface

There is often confusion about the difference between protocols and interfaces. This issue is particularly relevant for the questions of fieldbus connectivity. While IP may be the protocol used to connect fieldbus networks across the enterprise, the interface provided to applications to access that information is a completely separate question.

Often it is possible to provide interfaces for LAN-based applications that look like a direct fieldbus connection. This provides transparent operation of the application whether it is operating "local" to the fieldbus network, or "remotely" from somewhere on the LAN/WAN.

In addition to widely used defacto standards such as Modbus, there are also several emerging standards for interfaces to automation equipment including fieldbus systems. Emerging efforts include the Java Automation API and OLE for Process Control.

4.1 Java Automation API

The Java Automation API is a multi-vendor effort to create a standard Java-based interface to control equipment, including networked I/O. Once established it promises to provide a common, platform-independent interface for applications which is independent of the means used to connect the control equipment. This effort is in the early stages. A draft specification is due for comment Spring 1997.

4.2 OLE for Process Control (OPC)

This is a multi-vendor effort to create a standard OLE-based interface to control equipment. It also promises to provide a common interface for Windows-based applications which is independent of the physical interface to the control equipment. Version 1.0 of the standard was released in late 1996 and some reference implementations exist.

5.0 Performance Considerations

An enterprise solution connecting fieldbus subnets needs to be designed from a systems level and must address the same issues as any networked system. The same sorts of calculations and considerations done for the fieldbus itself, must also be made for the Ethernet segments of the system as well. The application requirements must be carefully assessed to determine the various performance requirements such as latency, throughput, and overall network bandwidth.

5.1 Latency

Since the Ethernet backbone being used is often a part of the enterprise network and is being used for business functions, latency of messages can vary depending on system loading. For data collection and monitoring functions this is generally not an issue. For subnet-to-subnet connectivity this may be an issue depending on the capabilities and flexibility of the fieldbus protocol being used. LonTalk does particularly well in this area due to its support of multiple physical media. LonTalk provides several parameters to tune various timing and time-out features of the communications. These can be adjusted to fit the characteristics of the Ethernet channel being used.

5.2 Throughput

As has been noted, IP is oriented toward large blocks (files) of data. There is considerable fixed overhead per packet. This will tend to lower the usable-data throughput of the network when used for control information. In most typical building automation systems we have seen however, this is not an issue due to the relatively high bandwidth of Ethernet coupled with the low data requirements for data flowing up to the enterprise.

6.0 Connectivity Requirements

There are at least four basic types of connectivity encompassed by system requirements for linking fieldbus to the enterprise:

• LAN-based Network Interface
• Fieldbus/Ethernet Router
• Fieldbus Gateway
• Remote access

6.1 LAN-based Network Interface

The commonly used method for linking an MMI or control application with the control network is to use a network interface card inside the PLC or PC that is running the application. This requires that the PC or PLC be located physically near the control network wiring.

In many enterprises a plant or building-wide LAN exists. It is often convenient to provide access to the control network via this LAN. This can be done with a LAN-based Network Interface device. These types of devices have physical connections to both the LAN and the control network and provide a driver which presents a standard interface to the application. This allows applications to operate as if they are directly connected to the control network.

6.2 Fieldbus/Ethernet Router

Linking fieldbus subnets over the LAN/WAN is achieved by using Fieldbus/Ethernet Router devices. These devices are intended to use the Ethernet LAN or WAN connection to link disparate subnets into a single large "virtual" network. The are generally transparent to the actual protocol being routed, but may be configurable in terms of basic routing functions (e.g., bridge, repeater, learning router). As with any router, these devices do introduce some latency into the communications between subnets which must be taken into account in network design.

In addition to providing the basic connectivity function, fieldbus/Ethernet routers provide the features of routers in general. This includes traffic management and logical segmentation of the network.

6.3 Fieldbus Gateway

Routers provide connectivity at the protocol packet level. Gateways can be used to provide data access services to a fieldbus, in formats other than the fieldbus protocol. A gateway may also act to translate from one protocol to another.

Gateways have the advantage of being able to provide connectivity to the control network in a form which is more convenient for the application. On the other hand there is generally more configuration and setup associated with them, since a "mapping" must be defined between the fieldbus protocol and the format or protocol being used on the other side.

One example of a gateway approach is a LonWorks to Modbus device. These types of devices have physical connections for both LonWorks and modbus. In this sort of device, the data elements (Network Variables, in LonWorks parlance) are "mapped" to Modbus address locations. Data can then be sent and received from LonWorks by using Modbus commands to read and set register values. Block transfer of data can also be supported. The advantage of such a gateway is that once the gateway is configured, any application which knows how to speak to a Modbus device can now send and receive data to a LonWorks network.

6.4 - Remote Access via the Internet - Leveraging LAN to LAN Solutions

Connectivity requirements for many applications include remote access. Simple instances of this requirement include being able to monitor or control data on a remote fieldbus from a single host workstation, one site at a time. More advanced requirements include having the ability to access multiple remote fieldbus networks simultaneously.

Another benefit of using IP as the foundation of a connectivity solution is the recently availability of solutions for enterprise remote LAN connectivity. These technologies and products can be leveraged to link the control network to the enterprise in a flexible and cost efficient manner.

The figure below shows a system architecture which includes multiple sites being connected to an enterprise via the Internet. This solutions leverages "Remote Access Server (RAS)" products developed for remote office connectivity. RAS solutions allow two office LANs to be connected over a remote link such as the Internet. With the addition of a LonTalk to Ethernet link, we get a completely connected control system that can be accessed from anywhere in the enterprise. Remote offices of the enterprise can also be linked using RAS solutions.

[Figure 1. Multiple fieldbus subnets connected across the Internet/Intranet using standard a Remote LAN architecture]

[INSERT FIGURE 1 HERE]

7.0 Security

Considering the use of public networks such as the Internet for control system connectivity naturally raises security concerns. The use of IP and standard LAN connectivity components however, actually simplifies the security question. All the available remote LAN solutions which exist for office connectivity support a variety of security features to control both unauthorized access to the remote site as well as interception or insertion of information. The key to leveraging the security features of Internet solutions is to make sure that the gateway or router being used for your control system connectivity uses standard IP protocols to communicate.

8.0 Network Management

Any type of connectivity solution must address the issue of device and network management. Both the enterprise side and the fieldbus side of the device must be managed. In the architectures proposed above, the connectivity device is typically an IP device on the enterprise network. As such, support for a standard network management protocol such as SNMP would be a convenient feature. On the fieldbus side, the connectivity device may appear as either a node, a router, or some other type of network device. LonWorks has a well developed set of features for network management including management of routers. These facilities should be supported by the connectivity device to allow for simple integration and maintenance.

9.0 Conclusion

The real promised value of fieldbus systems is that key data of and about the process and the process equipment is available in digital form. This information ultimately helps drive business decisions and streamlines plant operation via functions such as enhanced preventative maintenance. To realize this promise the information must be provided to the enterprise in a flexible and cost effective manner. In this paper we have outlined the key requirements for enterprise connectivity and discussed some of the technical issues involved.

Solutions for enterprise connectivity exist today. Gateway and router products to connect popular fieldbusses such as LonWorks to the enterprise and the Internet are available from multiple vendors. The rapidly evolving standards for applications interfaces, such as OPC, will serve to speed the adoption of these types of enterprise connectivity solutions.

References

1. "A Technology Roadmap for Enterprise Connectivity to Control Networks"; D. Byron, D. Gaw, et. al., Coactive Networks, Inc. in Papers and Tutorials of the LonUsers International Conference, Spring 1996, Santa Clara, CA.
   
   
2. "Accessing LonWorks Networks from the World Wide Web"; D. Gaw, Coactive Networks, Inc., in Papers and Tutorials of the LonUsers International Conference, Fall 1996, Nice France.
   
   
3. http:\\www.echelon.com - A good starting point for further information on LonWorks.