The 1990s saw the widespread adoption of network technology on two fronts: Office automation and factory automation. But while office automation soon standardized on Ethernet (for volume reasons) and TCP/IP (due to the Internet explosion), factory automation fragmented into a number of incompatible fieldbusses (a fieldbus is the common designation for an automation network). One decade later, the consequences materialize – networks based on Ethernet and TCP/IP are steadily getting faster and less expensive, while the fieldbus market is more or less stuck at the low speed/high price level.

Due to this development, several fieldbus vendors have ported their system software to run on top of Ethernet and TCP/IP in order to be part of the continuing trend towards higher performance, lower prices and standardized protocols. What they have failed to see, however, is that TCP/IP is not one protocol, but a large set of protocols aimed at everything from installation and configuration to network management. The purpose of this article is to shed some light on these additional protocols and show how they could be used to pave the way for “plug and play” automation networks.

TCP/IP Basics – IETF and RFC

The generic term “TCP/IP” usually means anything and everything related to the specific protocols of TCP and IP. It can include other protocols, applications, and even the network medium. A sample of these protocols are: UDP, ARP, and ICMP. A sample of applications are TELNET, FTP, and rcp. TCP/IP runs equally well on top of Ethernet, ATM and Wireless LAN, making higher-level protocols very portable.

The TCP/IP protocols are described in documents called RFCs (RFC stands for Request For Comment). The ultimate adoption of these as standards is governed by a body called the IETF (Internet Engineering Task Force).

Some of the Protocols in the Family

IP – Internet Protocol – RFC 791 [1] (version 4) and RFC 2460 [2] (version 6). Uses an “IP address” as a logical identifier. It is designed for routing across subnets. A very simple mechanism (using the “IP mask”) identifies the subnet. IP is not attached to any specific hardware. Version 4 is almost exclusively used today; version 6 is slowly gaining ground.

ARP – Address Resolution Protocol – RFC 826 [3]. Used to translate IP addresses to Ethernet addresses. The translation is performed with a table look-up, the ARP table is filled “as needed” by the ARP protocol.

UDP – User Datagram Protocol – RFC 768 [4]. UDP is a connectionless datagram delivery service that does not guarantee delivery. It does not maintain an end-to-end connection with the remote UDP module; it merely pushes the datagram out on the net and accepts incoming datagrams off the net.

TCP – Transmission Control Protocol – RFC 793 [5]. TCP offers a connection-oriented byte stream. It is a sliding window protocol with time-out and retransmits. In contrast to UDP, TCP guarantees delivery. In automation context, it must be stressed that TCP packetizes the byte stream at will; it does not retain the boundaries between writes.

DHCP – Dynamic Host Configuration Protocol – RFC 2131 [6]. DHCP’s purpose is to enable individual computers on an IP network to extract their configurations from a server (the “DHCP server”). DHCP consists of two components: a protocol for delivering node-specific configuration parameters from a DHCP server to a node and a mechanism for allocation of network addresses (IP addresses) to nodes. The overall purpose of DHCP is to reduce the work necessary to administer a large IP network.

TELNET – RFC 854 [7]. TELNET provides a remote login capability on TCP. The operation and appearance is similar to an ASCII terminal connected directly to a computer with a command-line interface. If the user types “telnet delta” on the command line, he receives a login prompt from the computer called “delta”.

FTP – File Transfer Protocol – RFC 959 [8]. File Transfer Protocol (FTP), as old as TELNET, also uses TCP and has widespread interoperability. The operation and appearance is as if you TELNETed to the remote computer. But instead of typing your usual commands, you have to make do with a short list of commands for directory listings and the like. FTP commands allow you to copy files between computers.

TFTP – Trivial File Transfer Protocol – RFC 1350 [9]. TFTP is a very simple protocol to transfer files, hence its name. It is implemented on top of UDP so it may be used to move files between machines on different networks implementing UDP. It is designed to be small and easy to implement, therefore it lacks most of the features of FTP. The only thing it can do is read and write files from/to a remote server.

SNMP – Simple Network Management Protocol – RFC 1157 [10]. Simple Network Management Protocol (SNMP) uses UDP and is designed for use by central network management stations. The central station uses SNMP to collect this data from other computers on the network. SNMP defines the format for the data; it is left to the central station or network manager to interpret the data.

Identifying the Units – Basic Addressing

Ethernet and Wireless LAN nodes running TCP/IP all share the same addressing mechanisms:

They have a unique hardware address assigned at the time of production (MAC address). They get a unique logical address (IP address) assigned as part of the system set-up or at boot time.

The IP protocol is only concerned with the logical address of the nodes, using a specialized protocol (ARP – the Address Resolution Protocol) to map logical addresses to physical addresses when necessary. (IP version 6 does not need ARP as it contains an auto-configuration mechanism to provide an implicit generation of the device part of the logical address directly from the physical address.)

In an automation or measurement system, there will probably exist many identical nodes with similar or identical tasks to handle, but located at different places in a task hierarchy. In this case it will be impossible for the configuration software to tell these devices apart (it cannot see which of identical unit sits at the start or end of a conveyor belt for example). Figure 1 shows a part of such an automation network with three identical nodes. It also shows three distinct identities for one of the nodes. Those are:

The MAC address. This identity is uniquely associated with the network interface. If the module is exchanged for another, the MAC address will change.

The IP address. This identity is associated with the network configuration. If the module is exchanged for another, the IP address may or may not change.

The automation identity. This identity is associated with the function of the device. If the module is exchanged for another, the automation identity must remain constant.

In the classical fieldbus scenario, no MAC address existed; the network address was set by hand and also used for the automation identity. In such a scenario, the systems engineer had to keep track of everything manually. Usually, he started by creating a “map” of the overall system, assigned identities to the various nodes on the map and, carrying the map along, saw to it that the real nodes were assigned network addresses equal to the identities indicated by the map. When the hardware addresses are fixed and logical addresses are automatically assigned, we cannot use this approach.

A better approach would be to attach an automation identity to each device. This could be done by entering this description into non-volatile storage, or by physically attaching an automation identity source to each device site (remember that the automation identity is not associated with the device, but with the purpose of the device). This identity could be used for automatic configuration purposes. We shall return to this subject a little later.

Use Names Instead of Addresses!

The problem with fieldbus addresses and automation identities is that they carry no meaning. The automation systems engineer might remember that device 27 on one fieldbus is a combined flow meter and temperature sensor, but mostly it has to be looked up in the system documentation (assuming that it has been written and can be found). A descriptive name, however, like “main_flowmeter” would help make the control structure more understandable.

Of course, such names can be used today. Textually substituting “27” for “main_flowmeter” is something most system compilers can easily handle. The disadvantage with this method is that the name does not appear anywhere in the controller and cannot be used for anything. What we propose instead is to introduce a table of device references and a small middleware layer into the automation protocol stack. Every entry in this table should contain three entries: The device name, the automation device identity and the IP address. Thus, whenever the controller wants to talk to automation device 27, the middleware looks in the table and retrieves the IP address of the device. If the IP address is not in the table, the middleware uses a name server in order to fetch the IP address, using the device name.

The DNS System and Protocol

The Domain Name System (DNS, [11]) uses hierarchical names and name servers. Each name server knows its domain name and the names of the devices inside it. Any request for a local name is resolved locally; other requests are passed along to the next level. The levels are separated by dots, just as in Internet site names. Thus, if your company is referred to as bigcomp and the flow meter is in hall 4 of the New Jersey factory, every controller in your company should be able to access the flow meter using the name “main_flowmeter.hall4.nj.bigcomp”. Inside the hall4 subdomain, it is enough to refer to main_flowmeter. Remember, however, that these names are your internal names, you are not allowed to show them on the Internet (no automation device should ever be visible on the Internet, due to the risk of sabotage by hackers and virus authors).

If every device is given a name corresponding to its automation identity, it should routinely register with the local DNS server when the startup and configuration phase was finished. That way, every controller would be able to access the device without any knowledge of networking details. The only snag is: how does the device get hold of an IP address for itself and how does it get hold of the DNS server IP address?

Automate Network Administration with DHCP

When the TCP/IP protocol suite is used to handle end-to-end message transfers, every node must be configured with a set of parameters:

The IP address of the node

The IP subnet mask

The IP address of the master controller

A simple solution is to program these parameters into each node using some sort of configuration tool. This will usually work satisfactorily on smaller systems, but the procedure has several drawbacks:

It involves copying a lot of meaningless information and is therefore error-prone

Whenever a defective module is exchanged, the configuration procedure must be repeated for the new module

In office automation networks, such manual procedures have long been discarded and automatic procedures have been introduced. There is absolutely no reason why automation systems should not use the same procedures.

The DHCP Protocol Supplies Useful Information

A DHCP session is run very infrequently, and the interval can be configured. It is always run when a device powers up. The information supplied in a standard DHCP session is the IP address the node may use and some other IP parameters. The protocol may also furnish some additional information, which may prove very useful for automation purposes:

A boot server host name

A boot file name (which is supposed to be located on the boot server)

The IP address of the local Domain Name Server

A Possible Startup Sequence

Using the protocols described above, we are in the position to create a startup sequence for a “plug and play” automation system:

After power-on and self-test, run DHCP. The DHCP session should provide the server host name, the boot file name and the Domain Name Server address. Register with the Domain Name Server. Use the Domain Name Server to get hold of the IP address of the boot server. Download the boot file using TFTP. Check the revision number of the latest firmware against the current revision number. If the current revision is older, then download the latest firmware and store it in program memory.

From this point on, the procedure depends on the high-level protocol used. Some protocols expect the devices to keep still and wait until they are polled, others may want the device to contact the controller.

Other Useful Protocols and Services

SNMP Helps Network Administrators

The Simple Network Management Protocol is an application-layer protocol designed to facilitate the exchange of management information between network devices. By using SNMP-transported data (such as packets per second and network error rates), network administrators can more easily manage network performance, find and solve network problems, and plan for network growth.

Today, SNMP is the most popular protocol for managing networks. SNMP-related standardization activity continues even as vendors develop and release state-of-the-art, SNMP-based management applications. SNMP is a relatively simple protocol, yet its feature set is sufficiently powerful to handle the problems presented in trying to manage today’s networks.

IGMP Manages Network Groups

The publish/subscribe model allows independently developed distributed applications to be able to exchange information in an event driven manner without needing to know the source of the data or the network topology. Information producers publish information anonymously. Subscribers anonymously receive messages without requesting them.

Like other broadcast-based models, publish/subscribe is network-efficient on hub-based systems. For example if the cost of energy changes in a distribution system, only a single transmission is required to update all of the devices dependent on the energy price (This is of course in the best or most optimistic case).

IGMP [12] is a protocol for devices to use when they want to join or leave multicast groups. By sending a Membership Report to its immediately neighboring router, a device informs the router that it wishes to become part of a multicast group. Routers periodically transmit Membership Query messages to determine which host groups have members on their directly attached networks.

Conclusion: The Tools Are Available – Use Them!

The protocols and services we have been discussing are neither resource-hungry nor in any way real-time. They typically run when a device is powered up for the first time, and not very often after that. In addition, they do not interfere with existing automation protocols, and should therefore be ideal candidates for the first step towards a true “plug and play” automation system.

References

[1] RFC 791, “Internet Protocol”. Online at http://www.ietf.org/rfc.html.

[2] RFC 2460, “Internet Protocol, Version 6 (IPv6) Specification”. Online at http://www.ietf.org/rfc.html.

[3] RFC 826, “Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware”. Online at http://www.ietf.org/rfc.html.

[4] RFC 768, “User Datagram Protocol”. Online at http://www.ietf.org/rfc.html.

[5] RFC 793, “Transmission Control Protocol”. Online at http://www.ietf.org/rfc.html.

[6] RFC 2131, “Dynamic Host Configuration Protocol”. Online at http://www.ietf.org/rfc.html.

[7] RFC 854, “Telnet Protocol Specification”. Online at http://www.ietf.org/rfc.html.

[8] RFC 959, “File Transfer Protocol”. Online at http://www.ietf.org/rfc.html.

[9] RFC 1350, “The TFTP Protocol (Revision 2)”. Online at http://www.ietf.org/rfc.html.

[10] RFC 1157, “Simple Network Management Protocol (SNMP)”. Online at http://www.ietf.org/rfc.html.

[11] RFC 1035, “Domain names – implementation and specification”. Online at http://www.ietf.org/rfc.html.

[12] RFC 1112, “Host extensions for IP multicasting”. Online at http://www.ietf.org/rfc.html.