New FireWire standard targets industrial applications
By Michael Scholles
Thanks to the increasing performance of CPUs and programmable logic controllers (PLCs), today’s automation systems can be realized using a number of decentralized modules. While global functions such as module parameter setup and network management are performed by industrial PCs, such tasks may also be assigned to control modules such as PLCs. In addition, these automation systems also include graphical user interfaces for system control and monitoring, as well as image-acquisition and processing capability.
To fulfill these requirements, a number of different bus and network topologies including Ethernet (IEEE 802.3) and its industrial derivates, Profibus, CANBus, and SerCos, are available. While deterministic network behavior for these standards is only achievable with substantial technical effort, it is inherent in the IEEE 1394, or FireWire, standard. Originally developed for audio/video transmission, computer networking, and peripheral attachment, IEEE 1394 provides data transmission at fixed intervals regardless of bus load. Such isochronous transactions send data packets with a fixed clock rate of 8 kHz no matter whether the data are audio/video information or parameter data for a drive.
IEEE 1394 has many advantages for use in industrial automation networks (see “Defining the FireWire standard,” p. D6). The standard’s maximum 800-Mbit/s data rate allows image data to be transmitted using the same infrastructure as motion-control information. Because clocks in each node are synchronized at 125-µs intervals, the standard is ideal for control applications. For critical data, FireWire’s asynchronous transactions guarantee successful data transmission or provide sender and receiver with well-defined error codes. Because all the nodes on the network share the same rights, peer-to-peer communication is possible, and central control hardware can be as simple as a PC. Using FireWire-based peripherals, machine motion can be controlled via visual information acquired from a camera included in the control loop.
For applications in which IEEE 1394 is used for industrial control systems, factory automation, or motion control, a number of European companies have formed the 1394 Automation Association. Their main task was to develop the 1394AP (1394 Automation Protocol) standard that allows subsystems for factory automation and motion control from different vendors to communicate with each other via IEEE 1394.
Systems built using the 1394AP standard consist of one application master and up to 62 application slaves. In most cases, the application master will be a PLC or PC that is part of the network, but any other node with sufficient computing power can be used. During system bootup, each node signals its capability to become the application master. In case of more than one contender, one node is automatically designated. The application slaves (or devices such as sensors, cameras, and I/O) are controlled by the application master.
Figure 1. Based on the IEEE 1394 communication layer model, IEEE 1394AP Application Layer controls isochronous, asynchronous data transfer and bus-management functions. 1394AP offers three different services to the application including transmission and reception of isochronous process data (PD), transmission of noncritical asynchronous service data (SD), and management of network functions (NMT).
Based on the IEEE 1394 communication-layer model, the architecture of a 1394AP device is a logical bus system (see Fig. 1). The IEEE 1394AP application layer controls isochronous, asynchronous data transfer and bus-management functions. The Control status register serves as an interface between the user’s application and method of communication. 1394AP offers three different services to these applications including transmission and reception of isochronous process data (PD), such as time critical control, sensor, and actuator data. While service data (SD) are used to transmit noncritical parameter data, network management (NMT) is applied to network-management functions.
The main task of the system’s application master is the cyclic transfer of isochronous process data to the devices. This information is summarized in a master data telegram (MDT), which is the payload of an IEEE 1394 packet. The update rate of these data can be adjusted using the 1394AP-specific application cycle. For high-speed applications, the application cycle is identical to the standard IEEE 1394 isochronous cycle of 125 µs. In this case, the MDT is the payload of isochronous packets, which are sent immediately after the cycle start packet. In case of reduced performance, the application cycle can be spread over several isochronous cycles. Then, to transfer data using the MDT, both isochronous and asynchronous packets can be used.
While the MDT of 1394AP only defines a data structure for transmission of application-specific variables, the meaning of these variables is left to the application. While the devices receive the MDT and extract the data for proper operation, they output data using device data telegrams (DDTs). These transfer data both to the application master and to the other devices, ensuring peer-to-peer data transfer. Similarly to the MDTs, the application cycle for the MDTs is also variable.
One of the main reasons why IEEE 1394 has been chosen as control bus for real-time systems is its deterministic timing via isochronous data transfer. Clocks running in each individual node are synchronized every 125 µs by the cycle start packets. Data sent either as MDT or DDT are held in local buffers and marked with a time stamp. However, since IEEE 1394 does not check if the transfer of one asynchronous packet can be terminated within 125 µs, the next cycle start packet will be delayed. For 1394AP, this results in nondeterministic timing, which is unacceptable. Therefore, some precalculation of the overall bandwidth must be made to prevent the delay by managing the limited asynchronous resources between all nodes of the network. This is generally why isochronous data transfer is preferred.
MDTs and DDTs define the major software interface of 1394AP to the user’s application. To ease the migration from other bus solutions to 1394AP without rewriting application software, well-known communication profiles such as the CANopen Communication Profile have been implemented in 1394AP.
Hardware design
To realize the 1394AP standard, the Fraunhofer Institute for Photonic Microsystems has developed a communication node that can be used as device, but not as application master (see Fig. 2). This node comprises a TSB42AB4 “CeLynx” link layer Controller from Texas Instruments that can send or receive isochronous data simultaneously as required by the MDTs and DDTs. Since, in the worst case, an MDT has to be processed every 125 µs, the filtering of the incoming MDTs and DDTs is performed by an FPGA and a C167CS from Infineon used to handle relevant data. Outgoing DDTs are sent as asynchronous packets and are directly written into the Link Layer Controller by the microcontroller.
Figure 2. The Fraunhofer Institute for Photonic Microsystems has developed a communication node that can be used as device, but not as application master. The node comprises a TSB42AB4 “CeLynx” link layer controller from Texas Instruments capable of sending or receiving isochronous data simultaneously as required by 1394AP.
In addition, many IEEE 1394-equipped products are available for factory automation and motion control. The most common are industrial cameras that use the IIDC standard that can also be used in 1394AP networks. Cameras compliant to IIDC are available with both CCD and CMOS imagers, with geometrical resolutions ranging from VGA to several megapixels.
Other products include motion-control systems that can be connected to servo- and stepper motors and bus couplers that acquire analog and digital data from arbitrary sensors.
Michael Scholles is business-unit manager at Fraunhofer Institute for Photonic Microsystems, Dresden, Germany; www.ipms.fraunhofer.de.
Defining the FireWire standard
IEEE 1394 is a serial bus connecting nodes with data rates up to 800 Mbits/s that can be mixed with older devices running at 100, 200, and 400 Mbit/s. The standard supports both asynchronous and isochronous data transfer: asynchronous transfers are short messages used for control and setup. Data exchanges are controlled by a request and response scheme that guarantees data delivery for read or write operations or generates well-defined error codes. This type of communication is used if reliability is more important than timing, as it cannot be exactly determined at which time an asynchronous request of the application is sent to the connected node.
Isochronous channels are used for data that require a fixed, guaranteed bandwidth and submission at a fixed time-stamp. Streaming data are divided into packets that are sent every 125 µs. This 8-kHz clock is distributed across the network by a special packet called cycle start packet. One example of isochronous transfer outside factory automation is real-time video. Since the reception of data is not secured, the sender does not know if any other node is listening.
These two transfer types use a common physical and link layer of the IEEE 1394 protocol stack (see figure). Isochronous data are fed into the link layer. An additional transaction layer implements the standard’s secure protocol using requests and responses for asynchronous transactions.
All three layers exchange data with serial-bus-management firmware that incorporates functions for managing the isochronous bandwidth and optimizing the efficiency of the bus. While the physical and link layers are implemented in hardware, the transaction layer and serial bus management are implemented in firmware. Serial bus management is optional and can be omitted for design of embedded nodes if a host computer with a common operating system is part of the network. However, one node with serial-bus-management capabilities must be present.
In the original IEEE 1394-1995 standard and the IEEE 1394a-2000 amendment, the physical media for IEEE 1394 were restricted to shielded-twisted-pair (STP) copper cables and IEEE 1394-specific sockets and connectors. For signaling and data exchange between two nodes, a pair of differential signals is used with additional information coded in the dc voltage level. While a modified version of the STP cables still exists in IEEE 1394b, true differential signaling is now used, and additional types of media-including optical-have been added. - M. S.
Organization Info
Basler Vision Technologies
Ahrensburg, Germany
www.baslerweb.com
Fraunhofer IPMS
Dresden, Germany
www.ipms.fraunhofer.de
Fraunhofer IPT
Aachen, Germany
www.ipt.fraunhofer.de
IfAK Magdeburg
Barleben, Germany
www.ifak-md.de
IMMS Ilmenau
Germany
www.imms.de
Infineon
Munich, Germany
www.infineon.com
Maxon Motor Sachseln
Switzerland
www.maxonmotor.com
Nyquist Industrial Control
Eindoven, The Netherlands
www.nyquist.com
Phoenix Contact
Blomberg, Germany
www.phoenixcontact.com
Stöber Eggenstein
Germany
www.stober.de
SSD Drives
Heppenheim, Germany
www.ssddrives.com
Texas Instruments
Dallas, TX, USA
www.ti.com
TNO Industrial Technology
Eindhoven, The Netherlands
www.ind.tno.nl
WAGO Kontakttechnik
Minden, Germany
www.wago.com