A PERSPECTIVE ON ETHERNET-TCP/IP AS A FIELDB

l. INTRODUCTION

Recently, Ethernet has attracted of lot of attention in the industrial communication field. A number of vendors are offering industrial communication product based on Ethernet and TCP/IP as a mean to interconnect field devices to the first level of automation. Others restrict their offer to communication between automation devices such as PLCs and provide integration means to existing fieldbusses. In their solutions, fieldbusses are used to communication with field devices.

The paper intents to offer a critical view at the use of Ethernet and the related technology as a mean to link field devices to the first level of automation (fieldbus). This idea is not new and solutions using Ethernet were proposed more than 20 years ago. In a first part, we describe some of these solutions. We will then explain what has changed since and why there is such a rebirth in the interest for Ethernet today. The third part will recall the main requirements that a fieldbus should cover. This will allow discussing the suitability of Ethernet The fifth part will then look at the missing parts and the issues that need to be explored in more detail, We will end the paper with some discussion on standardization issues and the different organization that take care of it.

We will purposely restrict our discussion to the lower layers of the communication stacks. In particular, the issues related to the application layer and data representation will not be addressed here.

2. EARLY ATTEMPTS

The first products using Ethernet or some derivatives in the industrial context were released in the early 80s. Examples are FACTOR by APTOR (Boudenant, et al 1986), Sinec Hl by Siemens, LAC by COMPEX or ARLIC (Natkin and Woog., 1983) by SEMA group. In 1983,27 industrial busses were out in the market among which a number were based on the principles of Ethernet. Later, the MAP (Manufacturing Automation Protocol) which has begun with the IEEE 802.4 token bus protocol adopted Ethernet as an option for the MAC sublayer (ESPRIT 1995),

At the same time, it was recognised in the scientific community that CSMA/CD was superior to other protocols in terms of flexibility, robustness and simplicity. Furthermore, it was the only standard protocol that did not use fixed priorities thus opening the possibility to work with deadlines
(Le Lann 1983). For these reasons, a number of Ethernet derivatives were invented to improve the real-time behaviour or the network. Some of them were even available in silicon (i.e INTEL 82596 chip).

However, the "random" aspect of Ethernet and the availability of other MAC protocols made the interest shift to other solutions.

3. WHY IS ETHERNET BACKAGAIN?

If Ethernet gamed little acceptance in the industrial market (only few product survived the early phase), in die office environment, Ethernet has captured most of the market at the desktop level. More recently, thanks to the switch technology, it has spread as a backbone at the company level. The attachment costs have dropped accordingly from more than 1000$ in the 80s to 10$ today. At the same time, the signalling speed has been increased from 10Mbit/s to l00Mbit/s and 1Gbit/s. Higher speeds are planned.

With the advent of 10baseT and l00baseT (IEEE 802.3u), the topology of an Ethernet network has changed from a bus to a tree where all nodes of the tree are special devices called hubs that acts as repeaters in the networking terminology. Along with this change, cheap connectors (RJ45) and cables (unshielded twisted pairs) were used instead of coaxial cables and BNCs.

Starting from this tree topology and with a huge reduction in switch costs, it was easy to introduce the so-called "full duplex Ethernet". In this technology, there are no longer collisions. Rather, in case of simultaneous emissions, the switch on which two nodes are connected will serialise the packets if their destination is on the same port of the switch. The link between the switch and the node may thus be exploited at the same time in both directions, thus the name of full duplex Ethernet, As, in the mind of many users, collisions were the source of the non determinism, the presence of switches made Ethernet deterministic. They had what they dreamed a cheap and deterministic network with a clear path to more performance if needed in the future.

More recently, priority handling mechanisms were introduced in Ethernet (IEEE802.1D (IEEE
Std 802.1D-1990)). They can potentially be used to implement traffic prioritising.

The second part of the picture is TCP/IP. These protocols form the basic of the Internet (as described by IETF RFCs) and have become the "lingua franca" of communications, They are available as source code in public domain, as IP (intellectual property parts) to include in silicon or even as within single chip solutions that also include a micro-controller and an Ethernet interface.

The picture is very clear, a supposedly deterministic (because of the switches) network made of widely accepted standards (IEEE 802.3, TCP and IP) and available as inexpensive parts (silicon, cables and connectors). It is an ideal case.

4. SEVEN REASONS TO ADOPT ETHERNET

With what was mentioned in the previous paragraph, it seems that there are very good reasons to use Ethernet as a fieldbus:

- there is a lot of cheap silicon available. Single chip solutions exist that integrate Ethernet and a TCP/IP stack;

- integration with the Internet is straightforward as the solutions are identical;

- 'with the presence of TCP ,it is possible to use all the conventional protocols such as FTP, HTTP and also describe the capability of a device and the format of data using well known techniques such as XML (Wollschlaeger2000);

- Ethernet already offers a clear path to future increase in bandwidth. The solution has thus a clear potential to handle future needs;

- as everybody will be using the same protocols, the solution is universal and thus compatibility issues are solved. Vendors will only have to support a single solutions instead of multiple fieldbusses. Users will have a single inventory to manage;

- the capacity of existing fieldbusses is reaching its limits. Even with new versions with higher bit rates, it is unlikely that they will be able to cover future needs;

- the market is asking for Ethernet. As many vendors are providing such solutions, it is urgent to offer it to stay in the market.

Unfortunately, we will see later that this picture is not as ideal as it may seem. Before that, let us recall the main requirements that a fieldbus has to fulfil.

5. FIELDBUS REQUIREMENTS

Fieldbus requirements were studied in depth by a number of projects and widely published (see for instance (ISO 1989)). We do not intend to detail these requirements but just to remind the most important ones which have an impact on the lower OSI layers. A fieldbus should be able to:

- to transport small packets of information with bounded latency. Failure to transfer the information should be indicated;

- handle periodic traffic with different period durations. In many fieldbus solutions, this requirement is translated into some cyclic traffic. The real need it to be able to transport the information well before the end of the period at which the data bas been sampled;

- handle sporadic traffic with bounded latency;

- allow for quasi simultaneous sampling of a number of inputs;

- provide indication for temporal consistency. The fact is that control or acquisition systems expect that different sensed values correspond to the sampling instants that should be within a few percents of the sampling period. The network should hence provide ways to know if a set of values exhibit this property, name temporal consistency. Sometimes the age absolute temporal consistency (Kopetz 1988), is also important to its users;

- for sporadic traffic, provide ways to know the order in which events have occurred. An application will take different decisions depending on the order in which events have occurred. As the events are potentially detected on different nodes of the network, there should be a way to find out the order,

- transfer data from one node to another or one node to a number of others;

- rugged solutions in terms in resistance to interference, vibrations, etc;

- low cost solution. The cost picture includes the devices (nodes, connectors, cables, hubs, switches)

- as well the planning, installation, commissioning and maintenance expenses.

Although these are not the only requirements, they are the main ones that make fieldbusses different from other networks. Let us see how Ethernet and TCP/IP can fulfil them.

6. CAN ETHERNET AND TCP/IP FULFIL THE REQUIREMENTS?

In this paragraph, we will look at the requirements mentioned above and see how the combination of Ethernet and TCP/IP may fulfil them.

6.1. Small packets with bounded latency

With a minimum frame size of 64 bytes, Ethernet is clearly not very efficient. However, this not really an issue as the bit rate is high enough to cover existing needs. Latency is in theory not bounded in Ethernet when taking collisions into account. Practically, most networks are operated well below their capacity (a few percents). Collisions are rare and latency is low.

When switches are used instead of hubs, the picture changes somehow. The impact depends on the type of switch used. Switches come in at least three flavors:

- "store and forward" switches receive a packet from a port. When the packet is entirely received, they check its integrity and, if it is correct, they insert the packet in the output queue linked to the selected (according to the address in the packet) output port;

- "cut through" switches start receiving the packet As soon as there enough bits to check that no collision had occurred (64 bytes), they start inserting the packet in the queue associated to the selected output port;

- "fast forward" switches differ from the previous ones in that they start sending the packet to the output queue as soon as there enough information to identify the output port (address fields).

The order in which packets are inserted in the queue associated to an output port depends on the instant at which the decision to transfer the packet is taken. The behaviour is clearly "First In - First Out". Advanced switches additionally implement priorities according to IEEE. 802. 1D. In such a case, each output port is assigned, at least logically, as many output queues as the number of priorities (5 to 8). Output queues are then serviced according the priorities, the highest priority queue being serviced first until it is empty. Within a given queue, packets are serviced in a FIFO order.

If an end node connected to a switch do not handle the priority bits, it is still possible to configure a switch so that all packets coming from this port are assigned a given priority. The priority bits are then overwritten by the switch. Similarly, it is possible to configure the switch so that it reduces the priority of all traffic coming from a given port.

The objective of this paper is not to given a detailed analysis of the traffic on an Ethernet network. However, some conclusions can be drawn easily:

- compared to a hub, in absence of collisions, a switch will introduce an additional latency which can be as long as the packet emission time. If we assume a network; of a number of sensors and actuators connected to a single PLC. All traffic from the sensors goes to the PLC. All traffic to the actuators originates from the PLC. With switches, the latter will always suffer from an additional latency because in a hub based solution no collisions take place;

- using priorities, it is possible to limit the impact of non real time traffic coming from outside the control system and the set of sensors and actuators. This "foreign traffic" can be "downgraded" by the switch on which this traffic enters. However, unless end nodes implement priority management, the responses to this external traffic will be treated as high priority traffic;

- if the network is not overloaded, it is possible to evaluate the worst case latency using FIFO non preemptive scheduling analysis techniques. Let us use again the example described above (single PLC). We assume that traffic is cyclic with a single cycle. The maximum latency of a packet coming from a sensor will be the sum of emission tunes of all packets transmitted by the sensors plus the inter-packet gap and the sum of latency of all switches in the path;

- the number of available priority levels is too small to efficiently implement a priority based scheduling, a situation similar to the 802.5 token ring case (Strosnider andMarchok., 1989);

- the switch by itself does not make Ethernet deterministic except under controlled loads. Load control should be added somewhere on top of the transport protocol;

- switches may be used to offer path redundancy.

The use of TCP as a transport protocol raises another concern. In case of transmission error, most fieldbusses either implement an immediate retransmission of the missing packet or rely on some temporal mechanism to inform the consumers that the expected information could not be transmitted. With TCP, packet transmission errors are not immediately detected and retransmission may take place well after the sample of a sensor value bas been transmitted.

6.2 Periodic traffic with different periods

It is clearly impossible to handle periodic traffic with low jitter in an Ethernet network. However, this is not really an issue. The real requirement is to be able to sample the sensor inputs periodically, Transfers may not be strictly periodic. They just need to occur before the end of the period. This translates into bounded transfer times, an issue already discussed.

Periodic sampling can be implemented by using synchronised clocks for which a number of algorithms exist [Fonseca and Mammeri, 1996]. The question is "at which level should these algorithms be implemented ?". With Ethernet and TCP/IP, this should be done on top of TCP or UDP or above. This is the only manner to keep the compatibility. This also implies that application services that provide the sampling services should be created. These services should operate on a group of sensors and thus cannot rely on TCP.

Provided there exists a clock synchronisation mechanism, multiple periods can be implemented easily.

6.3. Sporadic traffic with bounded latency

This issue was discussed in a previous paragraph
(§ 6.1).

6.4. Simultaneous sampling of a number of inputs

Simultaneous sampling of a number of inputs can be be implemented using UDP and broadcast. However, it is not possible to guarantee that sampling will be periodic (see previous paragraph). A better solution is to rely on synchronised clocks as described above.

6.5. Temporal consistency indication

There are at least two possibilities to implement this feature. The first one is to use transmit a time stamp with each piece of data. The time stamp carries the time at which the data bas been acquired. It is obtained by some synchronised clock algorithm. The consumer of the data can compare the time stamps of the different data and decide on their temporal consistency status.

A second technique is to use the algorithms developed for the FIP fieldbus (CENELEC EN 50170 1996), which are based on local timers on both the producer and the consumer (Decotignie and Prasad., 1994). This solution must be implemented on top of TCP and UDP.

6.6. Give the relative ordering of events

Here again, Ethernet and TCP/IP do not provide any solution. A possible solution is to add a clock synchronisation algorithm on top of the transport layer and tag the events with the time at which it occurred.

6.7. Transfer data from one node to number of others

TCP can be used in point to point communication relationships. However, in a number of cases, the producer consumer model (Thomesse 1993) or the publish/subscribe model are preferred. An example is when the information produced by a sensor is used by more than a device. Broadcast source addressing is often used to implement this. In this scheme, the packet does not carry the address of the source node but the identification of the data. Consumers filter the incoming; packets according to this identifier. Such a mechanism; requires some form of broadcast. TCP cannot be used in such a case. However, the IP protocol defines ranges of addresses that can be used as multicast addresses as well as one broadcast address. Assuming Ethernet based solutions will use the IP protocol, UDP and multicast transport protocols (Obraczka 1993) can be used. It is; however necessary to add some protocol to inform the consumers of failure to transmit in case of error.

There is another reason to implement models such as producer consumer or publish subscribe. In a conventional client server approach, the time necessary to satisfy a request depends on the message queuing and transfer times as well as on the time spend in the server application to generate the answer which is very difficult to calculate. With these models, this time can be bounded.

6.8. Rugged solutions

In comparison with existing fieldbusses, Ethernet based solutions introduce concerns about the connectors and the cables. RJ45 is the traditional connector used in Ethernet. It is inexpensive and very resistant to vibrations. A new solution has to be found for industrial use in particular to ensure the required degree of protection (IP67).

Resistance to interference of existing Ethernet cables (category 5) also need to be assessed in the industrial context

6.9. Low cost solution

Compared to existing fieldbusses, Ethernet based network add new devices (hubs and/or switches) and introduce complexity in the cabling layout process. The tree topology is clearly more complex to plan and to install. However, cable fault diagnosis and replacement are likely to be eased.

Even if low cost and integrated silicon solutions are available to implement the network interfaces, the complexity of the TCP/IP stack requires additional computing power and will thus lead to more expensive network interfaces. This is particularly true when the solution is compared to inexpensive sensor and actuator busses.

Finally, Ethernet cabling does not support remote powering of devices. Additional cables will have to be installed to provide the necessary power to end devices and to the hubs and switches.

In summary, Ethernet based fieldbusses are likely to be less cost effective than existing ones.

7. THE MISSING PARTS

As discussed in the previous paragraph, Ethernet and TCP/IP are not enough the cover the needs that a fieldbus has to fulfil. In particular, they fail to:

- provide mechanisms for absolute and relative temporal consistency,

- provide ways to order the events;

- offer quick retransmissions in case of errors;

- control the load on the network (Kweon and Shin., 2000);

- offer remote powering of the devices;

- offer guaranteed throughput to devices
(Le Lann 1983);

8. STANDARDIZATION EFFORT

A number of industry organisations actively promote the use of Ethernet in the industrial context. To which extend, they plan to support field devices is not clear and seems to be a matter of appreciation by the implementers. The organisations are:

- the Fieldbus Foundtation with HSE (High Speed Ethernet);

- PROFIBUS Nutzerorganisation with ProfiNet

- ControlNet International

(CI), the Industrial Ethernet Association

(IEA) and the Open DeviceNet Vendor Association (ODVA) support the EtherNetlIP standard

- Industrial Automation Open Networking Alliance (IAONA) supports a number of industrial standards on different topics among which industrial networking, It seems to back EtherNet/IP,

- The MODBUS users promote MODBUS TCP

- Interface for Distributed Automation

(IDA) group

We will not detail the different proposals. The interested reader is referred to the web sites of the different organisations. Suffice to say that the solutions are not compatible.

The number of groups that study solutions based on Ethernet shows the strong interest in searching solutions.

The approaches are diverse and are not compatible except in the use of Ethernet and TCP/IP. The physical layer is identical but at least two different connectors are defined. The higher layer protocols are different. Some use only TCP, some use a combination of UDP (for real-time traffic) and TCP.

The good news is that one can built a network interface that has the same hardware (except the connector) for all proposed solutions. The difference will be in the software. The bad news is that the solutions will continue to be non interoperable. The dream to have a single solution again vanishes.

9. CONCLUSION AND FUTURE WORK

For the time being, solutions based on Ethernet and TCP/IP do not offer die level of functionality that existing fieldbusses provide. Even if, under normal circumstances, latencies are low, the picture is not yet satisfactory in case of transmission errors.

Concerning the temporal aspects (consistency, event ordering, etc.), the existing protocols are not sufficient and new protocols should be added.

In the beginning of the paper, seven reasons to adopt Ethernet were listed. As a contradiction, here are seven reasons to stay away from Ethernet:

- cabling is more complicated (tree topology instead of bus) and more expensive;

- security is not guaranteed especially with regards to externally generated traffic;

- the existing protocols do not make the required job;

- there exist better and cheaper performing solutions;

- a universal solution is likely to be just a dream;

- remote powering of devices is absent;

- Ethernet even with the addition of switches does not guarantee the temporal constraints.

This paper does not give any definitive answer to the question (does one exist ?) but rather a list of issues that should carefully be studied before making the transition.

In conclusion, Ethernet - TCP/IP can be used as a fieldbus provided these protocols are complemented with the missing parts and special care is taken to protect the real-time part from externally generated traffic.

10. ACKNOWLEDGMENTS

This paper was largely inspired by discussions with Dr. H. Kirrmann from ABB Research, industrial partners of CSEM, a number of speakers and attendees to the Euroforum conference on Ethernet TCP/IP in Paris last June as well as my colleagues in the CSEM networking group.

11. REFERENCES

Boudenant J, et al. Lynx: an advanced deterministic CSMA-CD local area network prototype, Proc. Advanced Seminar on Real-Time Local Area Networks, Bandol, France, April 16-18, 1986, pp. 177-192.

CENELEC EN 50170, General Purpose Field Communication System, vol.3/3 (WorldFIP), 1996.

Decotignie J.-D., Prasad P., Spatio-Temporal Constraints in Fieldbus: Requirements and Current Solutions, Proceedings of the l9th IFAC/IFIP Workshop on Real-Time Programming, Isle of Reichnau, June 22-24, pp.9-14,1994.

ESPRIT Consortium CCE-CNMA, CCE: an Integration Platform for Distributed Manufacturing Applications, Research Reports ESPRIT, Springer, Berlin, 1995.

Fonseca P., Mammeri Z., "A Framework for the Analysis of Non-Deterministic Clock Synchronisation Algorithms", Proceedings of the 10th international Workshop on Distributed Algorithms, WDAG 96, Bologna, Italy, October 9-11, 1996, pp.l59-174

IEEE. Std 802. ID-1990, IEEE standards for local and metropolitan area networks: media access control (MAC) bridges, IEEE standard, 1990.

ISO/ TC184/ SC5/ WG2 TCCA group, Time Critical Local Area Networks Analysis of Needs and Characteristics, ISO/ TC184/ SC5/ WG2 N 190, Oct. 30,1989.

Kopetz H., Consistency Constraints in Distributed Real Time Systems, Proc. Of the 8th lFAC workshop on Distributed Computer Control Systems, Vitznau, Sept 13-15,1988, pp.29-34.

Kweon S., Shin K, Achieving real-time communication over Ethernet with adaptive traffic smoothing, Proc. of the Real-Time Technology and Application Symposium, 2000, pp.90 -100.

Le Lann G-, A deterministic multiple CSMA-CD protocol, INRIA-Project Score Internal Report PRO-1-002, january 1983.

Nation S., Woog A., ARLIC: une architecture de réseau local industriel, Proc. Nouvelles Architectures de Communication, ENST, Paris, 1983.

Obraczka K., Multicast Transport Protocols: A Survey and Taxonomy, IEEE Communications magazine 36(1) 1998.

Perlman R„ Interconnections - bridges and routers, 2^nd edition, Addison Wesley, Reading, 2000.

Pleinevaux P. and Decotignie J.-D., Time Critical Communication Networks: Field Busses, IEEE Network Magazine, vol. 2, pp. 55-63, 1988.

Strosnider l., Marchok T., Responsive, Deterministic IEEE 802.5 Token Ring Scheduling, Journal of Real-Time Systems l, pp. 133-158, 1989.

Thomesse J.-P-, Time and Industrial Local Area Networks, Proc. COMPEURO'93, Paris, May 24-27,1993, pp.365-374.

Wollschlaeger M., A framework for fieldbus Management using XML Descriptions, Proc. WFCS2000, Porto, Sept. 6-8, 2000, pp. 3-10.

A PERSPECTIVE ON ETHERNET-TCP/IP AS A FIELDBUS

Jean-Dominique Decotignie