Communication in Industrial Networks

The topic of networking in industrial applications has a long, and rather tangled, history. Each individual industry approached the task of deploying electronic controls on individual pieces of equipment, linking these controls into islands of automation, and finally pulling these islands into a factory-wide network. These are now linked into the enterprise networks and are associated with sales forecasting, stock control, and management information systems, amongst others. However, this is beyond the scope of this piece. The problem with this approach is that the different industries developed different approaches to implementing the networks. In the 1980s, there was a movement to create a common way of describing networks with the OSI (Open Systems Interconnect) model from the ISO, and to find the ways that different networking technologies interacted using the model. This looked at communications as a seven-layer model. Level 1 is the physical layer, defining the wires, connectors, and the way in which signals travel across the wires (or optical fibers.) The layers become increasingly abstract, until layer 7, the application layer, which is the interface between the network and the communication software.

At the time there was a huge investment in OSI activities, with an important legacy consisting of the ability to describe current networking technologies in terms of the relevant OSI layers, even if they were not designed with that approach.

Today there are several networking technologies being deployed. Industrial Ethernet is making steady progress, particularly as it is seen as compatible with standard Ethernet. While it has significant plus points, it does have some disadvantages, particularly for hard real-time applications. Despite this, many earlier networking technologies, such as Modbus and Profibus, have been adapted as overlays on Ethernet.

Increasingly popular, and perhaps currently the dominant networking technology (although different market figures give different numbers), is CAN bus. This started life as a way of linking the increasing number of intelligent nodes in cars and was developed in Germany by Robert Bosch. It was taken up widely within the general automotive industry, accepted by the SAE (Society of Automotive Engineers in the US) and is now covered by International Standards Organization standard ISO 11898, in several parts. In current implementations, CAN bus is low cost, robust, and tolerant of the extreme environment of a car, characteristics that make it attractive for industrial control applications. It has become so widespread that many microcontrollers include a CAN interface on chip, removing the need for a dedicated controller chip for each node. Some estimates suggest that there are more than twenty companies supplying microcontrollers with CAN capability, normally either 16-bit or 32-bit.

CAN bus

CAN bus was designed for physical simplicity. There is no single master, as each node on the network is a master and the nodes are joined by a single, terminated, twisted pair cable. Each node can talk to any other node(s). Maximum bit rate is 1 Mbit/sec, which can be sustained over a normal cable length of around 40 m. With longer cable lengths, bit rates fall, and for a theoretical 10 km cable the bit rate would drop to around 5 Kbit/sec. There are also CAN bus networks using optical connectivity and even wireless. Their data rates will be different.

The nodes are not given specific addresses, and while theoretically this allows an indefinite number of nodes, a normal maximum will be around sixty-four on a network. Instead of a node address, messages have identifiers that determine a message’s priority. CAN bus deploys CSMA/CD (Carrier Sense Multiple Access with Collision Detection), which means that any node can transmit a message. If two (or more) nodes try to transmit at the same time, those with lower priorities will yield to the highest priority and will retry later. Listening nodes will recognize messages that are relevant to them and download them.

Messages are transmitted as frames of four types. The data frame is the basic frame for messaging. Additionally there is the remote frame, requesting the transmission of a specific message; the error frame, sent when a node detects an error; and the overload frame, used to add a delay between data frames.

The data frame itself can carry up to 8 bytes of data, and has seven fields: a single bit Start of Frame (SOF); the Arbitration Field; a Control Field (which specifies the number of bytes of the message); the data Field, of between 0 and 8 bytes; a Cyclic Redundancy Check (CRC) field of a 15 bit CRC sequence and 1 bit delimiter; an Acknowledgement (ACK) field of 2 bits (one for acknowledging receipt of a message, the other the field delimiter); and seven bits for End of Frame (EOF).

The Arbitration Field defines the two different data frame types: Standard Frame and Extended Frame. Standard Frame uses an 11-bit identifier, while Extended Frame adds a further 18 bits to the identifier, to cope with some of the protocol requirements of CAN bus overlays.

Every node on the network reads every message, deciding whether the content is relevant to them. If they decide that the message is relevant, the node resets the ACK field bit and retransmits the message. This allows the transmitting node to know that at least one node has received the message. All the message management is carried out by the CAN bus controller, originally a standalone device and normally for industrial automation, and now an integrated part of the host controller.

Returning briefly to the OSI 7-layer model, CAN bus has only two layers. One, the wires, corresponds to the lowest, or physical, level of the model. The other, the message format and the CSMA/CD process, roughly map onto the data link layer. This means that the CAN bus only defines the road and the overall shape of the vehicles traveling on the road. What the vehicles carry, what the content of the data field actually means, is left to the implementation. This means that the equivalents of the higher levels of OSI model are left undefined. One definition, covering layers from the network layer up to the applications layer, is the CAN Open standard developed by CiA (CAN in Automation), a consortium of 560 companies. The choice of this, and of other protocols that can use the CAN bus, is dependent very much on the context of the application. CAN is now standardized in ISO 11898, ISO 16845, and SAE J1939 for automotive, industrial, and general embedded communications.

FlexCAN

An extension to CAN, FlexCAN, with an associated protocol, SafeCAN, has been developed in the US and is achieving some success in safety-critical applications, since it brings determinism and real-time aspects. Generally, where FlexCAN is implemented on a microcontroller, it is backwards compatible with CAN.

LIN

LIN, Local Interconnect Network, also comes from the automotive industry. It was developed to provide an alternative and extension to CAN bus, in applications where the costs associated with the high bandwidth and error handling that CAN bus provides are too high. In automotive use, these are the simple things like window control, rain sensors and door locks, while in industrial use, temperature and pressure sensors, non-critical on-off switches and simple actuators are natural candidates for a LIN network. LIN is often used to create sub-networks to CAN.

Where CAN bus controllers tend to be part of the options offered in upper 16-bit and 32-bit microcontrollers, LIN can use the standard serial universal asynchronous receiver/transmitter (UART) found on even the lowest cost 8-bit microcontrollers or a dedicated LIN interface.

Instead of equal status nodes, the LIN bus is master-slave. Any LIN bus will have one master and one or more slaves (up to 16). The master also includes a slave. The master polls the slaves, in a pre-defined sequence and frequency. The message may be an instruction or request for information. Slaves respond by subscribing (carrying out the instruction) or publishing (providing the information).

A LIN message frame has a Message Header and a Message Response, with the header sent by the master and the response by one of the slaves. The Header has three elements: Break, Sync, and Identifier, while the Response has two, Data and Checksum. Break serves to alert all slaves that a message is coming, while Sync allows the slave to sync to the transmission speed. Identifier both provides identification for the message, and alerts slaves that a particular message is relevant. The relevant slave then uses the Response, providing up to 8 bytes of payload in the Data field and calculates a Checksum value. The mapping of the Identifier and the content of Data formats are implementation dependent.

The current standard is LIN 2.1, and this provides a sleep mode for the nodes. The period of inactivity to trigger sleep mode is defined by the developer and is ended by any node, either the master working to a pre-defined schedule, or a slave being triggered by a pre-defined state of the application software.

Implementing CAN

Most microcontroller developers offer CAN interfacing. Normally, a CAN interface on the microcontroller will connect to a CAN transceiver, and these are available from a wide range of suppliers.

Freescale has a large range of microcontroller options based on the PowerPC architecture. The MPC8306/9 families are PowerQUICC II Pro products, with an e300 PowerPC core and the QUICC, RISC-based communication engine. Designed as communications processors, they offer a wide choice of different interfaces, allowing them to be used to bridge CAN to other networking technologies. In industrial applications this is often Ethernet, used to link the CAN network to the broader enterprise. Within the MPC8306/9 families there is a wide range of speed/power trade-offs available, and Freescale is one of the few manufacturers implementing FlexCAN. Freescale has a development kit spanning the MPC830X families. At the low power end of the offerings are the Silicon Labs C8051F5XX microcontrollers. These are 8-bit 8051 based, come in small form factor packages, and provide user control over all peripherals, allowing them to be powered down to save power. Among the tools available is a development kit that can hold two processors, allowing a LIN 2.1 Master slave network to be exercised.

Texas Instruments’ Stellaris family offers a significant range of power/speed options based on the ARM Cortex cores. The Stellaris 2000, 5000, 8000, and 9000 families all have members with CAN capability. TI offers a range of boards and kits for developing CAN networks using Stellaris, employing different development environments such as IAR, Keil and CodeSourcery. TI also offers other microcontroller architectures with CAN capability, including members of the Piccolo range; the Sitara ARM Microprocessors, based on ARM9 or Cortex-A8 cores; and the Hercules safety microcontroller platform, which is designed specifically for IEC 61508 and ISO 26262 safety critical applications using ARM Cortex-M3 and Cortex-R4F cores.

Atmel also has several families supporting CAN, including members of the 32-bit AVR AT32UC3C, and the ARM9 based SAM9. Additionally, Microchip provides CAN across most of its PIC variants, including the 8-bit PIC 10/12/16 and 18, the 16-bit PIC24, and the 32-bit PIC32. As with most manufacturers, these are supported by a wide range of development kits.

Parameters

This is just a short summary of some of the microcontroller options available. The problem in choosing a microcontroller is not going to be whether it has CAN. Instead, the selection criteria are going to be those normally used, using parameters such as power/performance, other peripherals, and available software. Often the crucial factor is going to be whether the in-house investment in a particular architecture, including tools and man-years of experience, provides the comfort that this project will be completed to high quality, within time, and on budget.