3.6 Industrial Grade Networking
As with other computerized applications, industrial control and automation rely increasingly on computerized networks. General-purpose networking or connectivity solutions such as plain Ethernet or Token Ring are, however, ill-adapted to the harsh and demanding environment of industrial applications. Common Ethernet, for instance, is too vulnerable to EMI (Electromagnetic Interference) and RFI (Radio Frequency Interference) to be used in most industrial environments.
Therefore, quite a few specialized, industrial-grade networking solutions have been developed over time. In addition to being more adapted to industrial environments, these industrial networks, commonly known as fieldbuses, contribute to reducing wiring, increasing modularity, providing diagnostics capabilities, enabling self-configuration, and facilitating the setup of enterprise-wide information systems.
In the following sections, I will cover the industrial networks supported by Linux and briefly discuss the other industrial networks that have little or no Linux support. If you are new to fieldbuses, you may want to take a look at Rob Hulsebos' Fieldbus Pages located at http://ourworld-top.cs.com/rahulsebos/. The web site includes a large collection of links and references to all sorts of fieldbus systems.
The Controller Area Network (CAN) is not only the most common fieldbus, but probably one of the most pervasive forms of networking ever used. CAN was introduced in 1986 by Robert Bosch Gmbh. as a serial bus system for the automotive industry and has since been put to use in many other industries. CAN's development received early contributions from engineers at Mercedes-Benz and Intel, which provided the first CAN chip, the 82526. Today, more than 100 million new CAN devices are sold every year. Application fields range from upper-class cars, such as Mercedes, to factory automation networks.
CAN specifies a hardware interface and a communication mechanism. It is a multi-master serial networking protocol with error detection capabilities, where message identification is done through content rather than through the receiver node or the transmitter node. CAN is managed and promoted by the CAN in Automation (CiA) group and is subject to ISO standard 11898 published in 1993.
Since CAN is a low-level protocol, akin to Ethernet, many higher-level protocols have been put forward to complete it. Four such protocols are J1939, DeviceNet, Smart Distributed System (SDS), and CANopen. J1939 was introduced and continues to be maintained by the Society of Automotive Engineers (SAE), and is very popular in the automotive industry. DeviceNet is another popular CAN-based higher-level protocol and is managed by the Open DeviceNet Vendor Association (ODVA). SDS was put forth by Honeywell and continues to be promoted and managed by the same company. CANopen was introduced and is managed by the same group that maintains CAN, the CiA. SDS has not been as popular as DeviceNet and J1939, because it was never standardized, while J1939, DeviceNet, and CANopen were.
For more information on CAN, CAN-related hardware, and CANopen, consult the CiA's web site at http://www.can-cia.org/. The CiA provides its specifications online. SAE provides subscription-based access to the J1939 standard through its web site at http://www.sae.org/products/j1939.htm. Information on DeviceNet can be found on the ODVA's web site at http://www.odva.org/. The DeviceNet specification is available in printed form from the ODVA for a fee that covers reproduction costs and provides a life time unlimited royalty-free license to develop DeviceNet products. If you are interested in SDS, you can find more information about it, including specifications, on Honeywell's web site at http://content.honeywell.com/sensing/prodinfo/sds/.
The Attached Resource Computer NETwork (ARCnet) was introduced by Datapoint Corporation in 1977 as a general purpose network, much like Ethernet. Today, ARCnet is seldom used in office LANs anymore, but it is still popular as an industrial fieldbus. ARCnet is now an ANSI standard and is managed and promoted by the ARCnet Trade Association (ATA).
ARCnet is a token-based network that can use either a star topology or a bus topology. An ARCnet NIC (Network Interface Card) can be compatible with one of the two topologies, but not both. Apart from its low cost, ARCnet has many advantages compared to standard office networks, including deterministic performance, automatic reconfiguration, multi-master capability, and immunity to noise. Also, ARCnet guarantees the safe arrival of packets and guarantees notification in case of transmission failure.
Support for ARCnet has been part of the Linux kernel for quite some time now. Since ARCnet NICs have almost identical programming interfaces, there is no need for a broad range of device drivers. Instead, the kernel includes drivers for the two standard ARCnet chipsets, COM90xx and COM20020. In addition to the drivers, the kernel includes three different protocols to be used with ARCnet hardware. The first and most common protocol conforms to RFC1201 and enables the transmission of IP traffic over ARCnet networks. When a system is configured with the RFC1201 protocol, for instance, the kernel's own TCP/IP stack can be used to provide TCP/IP networking on ARCnet hardware. The second protocol conforms to RFC1051, which was replaced by RFC1201 already mentioned. This protocol is provided to enable interaction with old networks. Finally, the kernel provides an Ethernet-encapsulation protocol, which enables ARCnet networks to transport Ethernet packets.
Information regarding the Linux ARCnet drivers is available from the ARCnet for Linux project web site at http://www.worldvisions.ca/~apenwarr/arcnet/. The site includes the Linux-ARCnet HOWTO, which provides extensive discussion on the use of ARCnet with Linux. The HOWTO includes jumper settings information and card diagrams for many ARCnet NICs. It also includes cabling instructions for ARCnet networks. A text copy of this HOWTO is included in the kernel's sources in the Documentation directory.
The ATA's web site, found at http://www.arcnet.com/ contains more information about ARCnet, including forms for ordering the ANSI standard and other manuals.
The Modbus Protocol was introduced by Modicon in 1978 as a simple way to transfer control data between controllers and sensors using RS232 in a master-slave fashion. Modicon was later acquired by Schneider Electric, which owns the Modbus trademark and continues to steer the development of the protocol and its descendants.
Since Modbus specifies a messaging structure, it is independent of the underlying physical layer. There are two formats used to transmit information with Modbus, ASCII, and RTU. The first sends each byte as two ASCII characters, while the second sends each byte as two 4-bit hexadecimal characters. Modbus is usually implemented on top of a serial interface such as RS232, RS422, or RS485. In addition to Modbus, Schneider specifies the Modbus TCP/IP protocol, which uses TCP/IP and Ethernet to transmit Modbus messages.
Two open source projects provide Modbus capabilities to Linux:
For more information about Modbus, read the Modbus specifications, available at http://www.modbus.org/.
3.6.4 A Word on the Other Industrial Networks
There are, of course, many other industrial networks, most of which are not supported by Linux. There is, for instance, currently no support for ControlNet, Seriplex, AS-Interface, or Sercos in Linux. Still other fieldbuses have some form of support in Linux, but will require a certain amount of further work before we can classify them as having Linux support. The following is a list of such fieldbuses:
In addition, there is a driver for Applicom cards in the Linux kernel. Though the driver was mainly used for Profibus by its author, Applicom cards can handle many protocols. When used, the card is seen as a character device in /dev.
Also, Hilscher Gmbh. provides a device driver for its CIF boards and a user-level framework that enables the development of fieldbus-independent applications. The framework and device driver is distributed under the terms of the GPL with extensive documentation and is available from Hilscher's web site at http://www.hilscher.com/device_drivers_linux.htm. The device driver included in the package can be accessed from user space using the unified framework API. This, in turn, enables control applications to be developed independently from the underlying fieldbus technology. Although only Hilscher's hardware driver is currently part of the package, the approach used by Hilscher and the framework it provides may be useful in helping Linux provide wide and uniform support to industrial network technologies in the future.