October 23, 1997

A tale of three buses:
DeviceNet, Profibus-DP, Foundation Fieldbus

Mike Santori, National Instruments

The best of buses for one industrial-automation application can be the worst of buses for another. Wide-ranging requirements have spurred the creation of specialized networks. Understanding the forces driving each of these networks can help you make a far, far better choice for your next system.

A much-discussed topic in industrial automation is the move to open digital networks. This move marks a significant change in the architecture of process-control and manufacturing systems. As with any major technological change, much contention surrounds the choice of technologies, methods, and architectures. In an ideal world, one approach might encompass all automation applications--from simple data logging to discrete machine control to distributed process control. In reality, though, industrial-automation systems address such varied requirements that no one network can conceivably suit all of them. The IEEE-488 standard has been the dominant communications interface for benchtop and rack-and-stack instrumentation for more than 20 years. Over the years, IEEE-488 has evolved to include more software standardization and increased transfer rates. It continues to satisfy many test-and-measurement applications. In industrial automation, however, widely varied requirements reduce the likelihood that one network will suffice.

Several major technological shifts have occurred in control systems over the last 50 years. Process control has shifted from manual systems to pneumatics, followed by electronic control systems based on the 4- to 20-mA instrumentation standard. Today's distributed-control systems still largely use 4- to 20-mA instrumentation wired to I/O subsystems, which in turn connect to larger systems by proprietary digital networks. Manufacturing has also seen major trends over the past few decades, the most significant being the move in the early 1970s from hard-wired relay panels to programmable-logic controllers (PLCs). As do distributed-control systems, PLC-based systems typically directly wire analog and digital signals to I/O subsystems, which connect to the PLC using vendor-specific digital networks.

Devices that include both digital-communication and sensing capabilities characterize today's digital networks. A common network that directly connects the control system's measurement and control devices replaces point-to-point wiring to centralized I/O subsystems. Digital networks provide numerous benefits, the most fundamental of which is the increased information available from a device that communicates digitally.

In today's business climate, companies must think of their manufacturing capabilities as integral to their strategic business plans. Increasing business pressures, such as time to market, flexibility, and the need for higher quality, force manufacturers to take a hard look at their automation systems. Manufacturers expect more than measurement data from their control systems. Control systems must provide information to support business decisions that influence a company's responsiveness to ever-changing customer and market needs.

Stringent regulatory and quality requirements add to the need for information. Many industries must comply with new environmental and safety requirements, and many manufacturers have to conform to ISO 9000 quality requirements. In such a business environment, less of the required data is control-specific. Managers need more information of other types so that they can manage, maintain, diagnose, and modify the control system.

Standard digital networks for industrial applications have additional benefits. Reduced wiring lowers installation and maintenance costs. Open systems let users select the right instrument for the job, regardless of the control-system manufacturer. The networks also have intelligent instrumentation, in which better performing devices provide functions such as multivalue measurements and advanced diagnostics. The networks offer distributed control with intelligent devices that provide the flexibility to apply control centrally or at local process points for improved performance and reliability. These and many other reasons create great interest in standardizing digital-communication networks for industrial-automation systems.

Three networks

Many digital networks are in use and under development for industrial-automation applications. These networks range from low-level systems that gather data from simple discrete sensors to sophisticated networks in which intelligent field devices implement distributed control. You can evaluate these networks by examining published material, which includes numerous tables and benchmark summaries. The benchmarks consider cable length, number of nodes, maximum transfer rate, and maximum data bytes per packet. These benchmarks have their uses, but they don't really explain how networks operate or how they integrate with control-system designs. An in-depth treatment of every network would require much information and technical detail.

Three digital networks that target industrial-automation applications--DeviceNet, Profibus-DP, and Foundation Fieldbus--illustrate how different target applications result in different network architectures. Users often speak about these networks in the same breath, even though the networks focus on different applications and use disparate technologies.

The choice of these three networks is no indication that they are superior to others for their target applications. Numerous other networks, including LonWorks, Interbus-S, Seriplex, and CANopen, have strong followings and many successful applications. In general, these networks' architectures also target specific requirements. The profiled networks, however, represent contrasting technologies and are arguably the subject of the most intense current discussions.

DeviceNet--A CAN-based manufacturing bus

Developed by Allen-Bradley (Milwaukee), DeviceNet is now the responsibility of an independent supplier organization, the Open DeviceNet Vendors Association (ODVA, www.industry.net/c/orgindex/odva). ODVA controls the DeviceNet specification. DeviceNet is a low-level network that connects industrial devices, such as sensors and actuators, to higher level devices, such as controllers. DeviceNet focuses especially on the interchangeability of low-cost, simple devices often used in manufacturing applications. Examples are limit switches, photoelectric sensors, motor starters, bar-code readers, variable-frequency drives, and operator interfaces. Part of the goal of DeviceNet is to achieve the same level of interchangeability for 120/220V-ac and 24V-dc discrete devices using digital communications, as is possible with hard-wired I/O devices.

The basis for DeviceNet is the controller area network (CAN). Robert Bosch GmbH (Stuttgart, Germany) developed CAN to replace expensive wiring harnesses with a digital network, primarily in European-manufactured automobiles. CAN's primary goal is to interconnect in-vehicle controllers, such as antilock-brake systems and engine-control units. CAN offers fast response and good reliability under adverse environmental and electrical conditions. These attributes make CAN suitable for industrial applications. Cost was also a major consideration in choosing CAN as the basis for DeviceNet. Consumer and commercial demand for CAN is key to decreasing prices and improving performance of CAN chips. Thus, DeviceNet benefits from much higher volumes of communication chips than those of purely industrial-automation chips (more than 10 million vs hundreds of thousands in 1996).

DeviceNet uses a trunk-line/drop-line topology. The network provides separate twisted-pair buses for signal and power distribution. Trunk and drop lines can use thick or thin cable, with network distances depending on data rate and cable size (Table 1). Power distribution is a key characteristic of DeviceNet. Devices can use the same set of wires for power and communication. Thus, simple sensors usually need no external power supplies. Also, you can remove devices from the network or insert them into the network without removing network power. You can add power taps at any point in the network and thus connect redundant power supplies. An optoisolated-design option allows externally powered devices to share the same bus cable as bus-powered devices.

In DeviceNet's communications stack, the CAN protocol defines portions of the physical and data-link layers (Figure 1). DeviceNet adds the remainder of those layers, along with the media and application layers. As a rule, CAN defines the form of data movement, whereas the DeviceNet application layer defines the data's meaning.

A DeviceNet network can have as many as 64 node addresses. Because it uses the CAN data-link layer, DeviceNet is inherently a peer-to-peer network, though many applications use a master/slave architecture. DeviceNet uses a producer-consumer model, which requires packets on the network to include data-identifier fields. This approach contrasts with older technologies in which messages include a specific source and destination. The producer-consumer model's identifier provides for multiple priority levels and data consumers. On DeviceNet, data-producing devices add appropriate identifiers to the data they place on the network. From the identifiers, the devices can tell whether they should consume the data. Because messages are not specific to sources or destinations, data transfer is efficient.

In DeviceNet, two entities on the network must establish a connection before communication can occur. Explicit-message and I/O are the basic types of connections. The network assigns transmissions associated with a connection, an identification value, or a connection ID. An explicit-message connection provides a generic, multipurpose communication path between two devices and provides the means for performing typical request/response functions, such as device configuration. The explicit-messaging protocol indicates how a device should interpret a message.

An I/O connection is a dedicated, special-purpose communication path between a producing device and one or more consuming devices. The connection ID implies the content of the associated I/O message. No defined protocol exists for I/O-message data. The devices at either end of the connection must know the general form of I/O messages. I/O connections carry time-critical, control-oriented data.

The predefined master/slave connection set addresses common situations--applications in which devices lack the resources or the need for DeviceNet's full dynamic-configuration capabilities. Many sensors and actuators perform a predetermined function (for example, starting a motor). The type and amount of data the device produces or consumes are unalterable parts of the device design. The predefined master/slave connection set meets the needs of such devices by almost totally configuring the device connections when the device identifies itself at power-up. Starting the application requires only that the master device claim ownership of this predefined set of connections.

The predefined master/slave connection set defines several I/O connections. These connections include bit-strobed command/response (polled), cyclic, and change-of-state (exception based). You can choose the I/O mechanism that yields the most efficient data transfer. The predefined master/slave connection set defines the communication mechanism for a basic network comprising a master (for example, a PLC) and a set of simple devices (for example, on/off switches or motor starters).

DeviceNet objects and device profiles

The object model provides a template for organizing and implementing the attributes (data), services (methods or procedures), and behaviors of a DeviceNet product's components (Figure 2). For each attribute, the model provides an addressing scheme that comprises the node address or medium-access-control identifier (MAC ID), the object-class identifier, the instance number, and the attribute number. You use this four-level address with an explicit-messaging connection to move data on a DeviceNet network.

An identity object's attributes include vendor ID, device type, product code, revision status, serial number, product name, and state. Message-router objects pass explicit messages to the other objects and generally have no external visibility. A DeviceNet object's attributes include node address, baud rate, bus-off action, bus-off counter, allocation choice, and the master's MAC ID. Optional assembly objects group attributes from application objects into one attribute that can move with a single message. A connection object represents one end of a virtual connection (explicit or I/O) between two nodes on a DeviceNet network. An optional parameter object operates in devices with configurable parameters, providing a standard way for a configuration tool to access all parameters. Configuration options that are attributes of the parameter object include values, ranges, text strings, and limits. Also, a device usually includes at least one application object other than those from the assembly or parameter class.

To facilitate compatibility and interoperability, DeviceNet defines standard device profiles. From a logical standpoint, you can interchange multiple vendors' simple devices, such as pushbuttons, motor starters, photocells, and pneumatic-valve actuators, that conform to the same device-type profile.

A device profile contains the definition of the device's object model, including a drawing similar to Figure 2; the definition of the device's I/O-data format, usually including the definition of assembly objects for simple and efficient data transfer; and the definition of the device's configurable parameters and the public interfaces to those parameters, which the manufacturer sometimes documents in an electronic data sheet that comes with the device. The device profile and electronic data sheet describe the objects in a device and thus the device's function as a user sees it. Standard configuration tools can use the information in an electronic-data-sheet file to enable configuration of all DeviceNet devices.

Profibus-DP--a high-speed I/O network

Profibus comprises compatible protocol-stack variations--Profibus-FMS, Profibus-DP, and Profibus-PA. Profibus-FMS handles high-level, non-real-time communications among devices. Profibus-DP targets time-critical communication between controllers and distributed peripherals. German national standard DIN 19 245 and European Fieldbus Standard EN50170 both specify Profibus-FMS and DP. Profibus-PA targets process-control applications, especially those requiring intrinsically safe operation.

Profibus-DP is by far the most common Profibus protocol. The Profibus User Organization (www.profibus.com) and its affiliated organizations represent all parties involved in Profibus, including users and manufacturers.

Profibus-DP provides high-speed data transfer at the sensor and actuator levels. Controllers, such as PLCs, exchange data with their distributed peripherals using a fast serial link. Profibus defines master and slave devices. Master devices, or active stations, can control the bus and transfer messages without a remote request. Slave devices are simple peripherals, such as sensors and actuators. Slaves, or passive stations, cannot access the bus except at the request of a master. In a Profibus-DP system, data exchange is mainly cyclic, with a master reading input information from slaves and sending output information back to the slaves.

You can relate the Profibus-DP protocol architecture to the Open Systems Interconnection (OSI) reference model (Figure 3). To achieve desired performance, Profibus-DP does not use OSI layers three to seven. The direct-data-link mapper maps the data-link-layer functions for the user interface. The user interface specifies the system and device behavior of Profibus-DP devices.

The Profibus standard defines two physical layers with appropriate medium-access protocols for different transmission techniques. The base version of the physical layer uses copper wire in accordance with US standard EIA RS-485. This physical medium uses a two-conductor twisted-pair cable. A second physical medium is fiber-optic, which greatly extends the bus length at high transmission speeds. Fiber-optic versions of Profibus operate at transmission speeds as high as 12 Mbps. Table 2 shows the basic characteristics of RS-485 transmission.

The Profibus data-link layer is designated as the fieldbus data link. The MAC defines when a station can transmit data and ensures that only one station has the right to transmit data at any time. The Profibus protocol specifies the following two requirements for the MAC:

c In communication between complex automation components with equal bus-access rights (masters), the MAC must ensure that each of these stations has sufficient opportunity to execute its communication tasks within the precisely defined time interval.

c In communication between a complex automation device and a simple peripheral (slave), a cyclic real-time data exchange transfers data as simply and quickly as possible.

The Profibus medium-access protocol includes the token-passing method for communication between complex stations (masters) and the master-slave method for communication between complex stations and simple peripherals (slaves). This combined method is called hybrid medium access. Profibus-DP uses an individual subset of the Profibus layer-two services.

Targeting high performance

Profibus-DP is a low-level network that targets high-performance I/O scanning. Profibus-DP needs approximately 6 msec at 1.5 Mbps and less than 2 msec at 12 Mbps to transmit 512-bit input and output data distributed over 32 stations. Additional performance improvement results from an increased transmission speed of 12 Mbps and from fixed performance requirements for different implementations.

A Profibus-DP network can include the DP-Master Class 1 (DPM1), which is the central controller. A DPM1 exchanges information with the decentralized stations (DP-slaves) in a defined message cycle. Typical devices are PLCs, computer numerical controllers, and robot controllers. The network can also include DP-Master Class 2 (DPM2) devices, which are used for programming, configuration, or diagnostics, and DP-slaves, which are I/O devices that provide input information and issue output information to the system. Typical DP-slaves are discrete inputs or outputs for 24V dc or 230V ac, analog inputs, and analog outputs. The amount of input and output data is device-dependent and has a maximum of 246 bytes.

A Profibus-DP system can be either monomaster or multimaster. A multimaster system operates either as independent subsystems, each comprising one master and assigned slaves, or as one system in which additional masters operate as configuration or diagnosis devices. Every master can read the input or output images, but only one master (assigned at configuration time) can write to the outputs of a DP-slave.

A DPM1 follows a defined recurrent order as it automatically executes data transfer to and from its assigned DP-slaves. A typical Profibus-DP system configuration comprises one or more DP-slaves assigned to a DPM1. Interaction between the DPM1 and a DP-slave has parameterization, configuration, and data-transfer phases. In the parameterization and configuration phases, the DPM1 sends configuration data to the DP-slave, which compares the new configuration data with its real configuration. The device type, format, and the length of information, as well as the number of inputs and outputs, must be identical, protecting the user from configuration faults.

The Profibus specification requires the vendors of every DP-slave and DPM1 to document the device's characteristics in a device data sheet and database file that follow a standard structure, content, and coding format. The standardized approach permits common configuration tools to configure any Profibus-DP device. Every DP-slave type must have an identification, or "ident" number. The ident number allows a DPM1 to identify the types of connected DP-slaves.

Foundation Fieldbus--for process control

The Fieldbus Foundation (Austin, TX, www.fieldbus.org/information) has developed Foundation Fieldbus, a network based on the work and principles of ISA (Instrument Society of America) and IEC (International Electrotechnical Commission) standards committees. The goal of these committees is to develop a digital fieldbus that meets the control requirements of process applications. Although the committees have been at work since the mid-1980s, a variety of technical and political challenges has prevented much standardization. However, the Fieldbus Foundation bases its network on ISA and IEC standards, as well as standards that cover Profibus, the French FIP, (factory-instrumentation protocol), and HART (highway addressable remote transducer), a common open protocol in industrial instrumentation.

Foundation Fieldbus targets distributed control in process automation. Foundation Fieldbus technology comprises the physical layer, the communication stack, and the user application. These components fit the OSI communication model (Figure 4).

Foundation Fieldbus does not implement layers three through six of the OSI model, because process control does not require the services of these layers. An important part of Foundation Fieldbus is the defined user application, layer eight.

Foundation Fieldbus uses the ISA S50.02-1992 and IEC 1158-2 physical-layer (electrical, wiring, and so on) standards (Table 3). These standards specify data-communication rates of 31.25 kbps, 1 Mbps, and 2.5 Mbps. Devices operating at 31.25 kbps can draw their power directly from the network. Part of the target application of this physical layer is also to let low-speed devices run on twisted-pair wiring used by 4- to 20-mA instrumentation. The same twisted-pair cable carries both power and signals. The physical layer also specifies the capability for intrinsically safe operation, a requirement for hazardous environments.

The communication stack provides the services to interface the user application to the physical layer. The data-link layer (DLL) manages access to the fieldbus through a deterministic centralized bus scheduler, the link active scheduler (LAS). Foundation Fieldbus supports deterministically scheduled cyclic communications to execute control loops, for example, and unscheduled, acyclic communications, which handle events, such as alarm conditions. For cyclic communications, the LAS maintains a list of transmission times and compels a device to transmit data at the appropriate time. For acyclic communications, the LAS grants permission to a device to use the fieldbus by passing a token to the device. Thus, the LAS is in charge of access to the bus.

A link master is a device that can be an LAS. A basic device cannot be an LAS. A simple fieldbus segment can simultaneously have multiple link masters but only one LAS (Figure 5). Foundation Fieldbus specifies that the LAS capability must be transferable to secondary link masters, providing redundancy for enhanced system robustness.

The stack's Fieldbus-access sublayer (FAS) provides an interface between the data-link layer and layer seven. The FAS provides communication services, such as client/server, publisher/subscriber, and event distribution.

The stack's Fieldbus-messaging-specification (FMS) layer defines a model for applications to interact over the fieldbus. The object dictionary and the virtual field device are important features of this model. The object dictionary is a fieldbus-device structure that describes data that can appear on the fieldbus. You can think of the object dictionary as a look-up table that supplies information, such as the data type of values that you read from or write to a device. The virtual field device is a model for remotely viewing data described in the object dictionary. FMS services enable you to read and write information about the object dictionary; read and write the data variables described in the object dictionary; and perform other activities, such as uploading and downloading data and invoking programs inside a device.

Foundation Fieldbus user layer

Foundation Fieldbus defines an eighth layer--the user layer. The user layer defines blocks that represent the functions and data in a device. Rather than interfacing to a device through a set of commands, a Foundation Fieldbus user interacts with devices through a set of blocks that define device capabilities in a standardized way. Resource blocks, function blocks, and transducer blocks are the general types of blocks. Resource blocks describe the characteristics of a device, such as name, manufacturer, and serial number. Function blocks provide the control and I/O behavior of a device. Transducer blocks decouple function blocks from the functions that read and write local inputs and outputs.

Function blocks are the core components with which a user specifies a control system's behavior. Foundation Fieldbus defines standard sets of function blocks. A set of 10 function blocks defines the most basic control and I/O functions (Table 4).

Connecting the inputs and outputs of individual function blocks specifies communication of data on the bus. Even more important, you can precisely schedule a function block's execution, allowing direct execution of control loops over the network. The function blocks reside in individual devices, but the network schedules the functions' overall execution. An example of a simple control loop has analog-input (AI), proportional/integral/derivative (PID), and analog-output (AO) function blocks (Figure 6).

You can implement function blocks on the fieldbus in several ways. The AI, PID, and AO functions could each reside in separate devices, such as a transmitter, a loop controller, and a valve. Alternatively, the PID function itself could reside in the control valve. In the second case, no explicit controller device exists. In either system, the user sees a series of connected function blocks and an execution schedule. The second system shows the use of Foundation Fieldbus for distributed control, in which the control function exists in the field rather than in larger centralized controllers.

A second important feature of the Foundation Fieldbus user layer is device descriptions, standardized descriptions of devices' functions. Using a device description, a control-system host--a Windows NT-based human-machine interface, for example--can obtain the information to create an interface for configuring device parameters, calibrating, and performing diagnostics and other functions. Device descriptions are written in a textual device-description language. After converting the device description to binary form, the manufacturer ships it with the device.

A bus for every application

Vastly different network architectures result from different application targets. DeviceNet chose a low-cost CAN as the basis for a peer-to-peer network of fairly low-level devices, mainly for manufacturing. Profibus-DP optimizes for maximum I/O-scanning performance by presenting a low-level view of connected devices. Foundation Fieldbus focuses on an architecture of distributed process control using function blocks in complex, intelligent field devices. The appropriate network for an application depends on the system function, as well as the availability of the system's required devices. When you evaluate a network, the bottom line is to understand not only the bits and baud rates, but also the network's overall function. This approach helps determine how well a network meets the needs of your application.

| EDN Access | Feedback | Table of Contents |