1394AP: A Protocol for Deterministic Industrial Communication via IEEE 1394

Klaus Frommhagen, Petra Nauber, Uwe Schelinski, Michael Scholles Fraunhofer Institute for Photonic Microsystems (Fraunhofer IPMS)

Maria-Reiche-Strasse 2 01109 Dresden / Germany

{frommhag, nauber, schelins, scholles}@ipms.fraunhofer.de

Abstract

In this contribution we present an application layer called 1394AP (1394 Automation Protocol) for the industrial use of the IEEE 1394 "FireWire" standard which is favorable for factory automation because of its inherently deterministic network behavior. Starting from an analysis of industrial communication requirements and an overview of the principles of IEEE 1394, it will be shown that also other advantages make IEEE 1394 a promising network for industrial use. The following sections describe the 1394AP protocol in detail and explain how to implement the necessary hardware and software based on general purpose architecture of an IEEE 1394 embedded node. The paper will conclude with an outlook on the next steps in the ongoing specification process of 1394AP.

1. Introduction

In industrial automation a trend towards decentralized systems can be observed in recent years. In combination with the increasing performance of computing and control hardware the majority of system functionality has been moved from a central processing unit to distributed computing nodes. A typical example is motion control: The system consists of several I/O-modules and decentralized control for each of the axes. Global functionalities like parameter setup for each of the nodes, monitoring as well as network management are carried out by a standard industrial PC running one of the standard operating systems, but this task may also be assigned to anyone of the control units.

The system requirements heavily depend on the application. Handling systems for semiconductor processing for instance must provide velocities of up to 10 m/s and accelerations of up to 100 m/s2 per axis while motions must be reproducible with a resolution in the submicron range. Beyond that, a motion control system must include more and more additional features: today's users expect graphical user interfaces for system control and monitoring, service personal must have online access for maintenance procedures, a growing amount of

status data is acquired during operation of the system for failure analysis or, even more important, failure prediction. Last but not least, image acquisition and processing, e.g. for surveillance of pick-and-place cycles becomes more and more essential.

Numerous bus and network technologies have been introduced for industrial automation in the past in order to fulfill these requirements. The list includes Ethernet (IEEE 802.3) and its industrial derivates, Profibus [1], CANBus [2], and SerCos [3] to name only a few of them. All of them must be judged by the criterion if they can guarantee a deterministic behavior of the network. Whereas this goal is only achievable with substantial technical effort for the mentioned technologies, another standard offers this behavior inherently: IEEE 1394 [4] also known as FireWire™. Originally developed for audio/video transmission and computer networking and peripheral attachment, IEEE 1394 offers exactly that feature necessary for deterministic network behavior: data transmission at fixed intervals regardless of bus load. This is called isochronous transactions in IEEE 1394 terms, sending data packets with a fixed clock of 8 KHz. Data receive their destination at predefined time stamps, no matter if it is audio/video information or parameter data for a drive.

IEEE 1394 has a lot of other advantages for industrial automation:

• A maximum data rate of 800 Mbit/s offers the chance to transmit image acquisition data via the same infrastructure as motion control information.

• IEEE 1394 synchronizes the clocks in each node at an interval of 125 µs which is a prerequisite for high precisely control applications. Jitter is below 100 ppm.

• For critical or security relevant data IEEE 1394 offers so called asynchronous transactions that guarantee successful data transmission or provide sender and receiver with well defined error codes which allow an analysis of the failure on both sides.

• Network topology has no limitations, both tree-like and loop architectures are supported. All nodes share the same rights, so that peer-to-peer communication is possible. Therefore, the central control hardware needs not to fulfill any special requirements. A standard desktop PC is fully sufficient.

0-7803-9402-X/05/$20.00 © 2005 IEEE

• IEEE 1394 is the only network technology that can combine motion, I/O, and digital image acquisition. Theoretically, this is also true for technologies like Profinet-RT, but they lack of end-user equipment like cameras supplied with this interface. Given this, motions of a machine can be directly controlled via visual information acquired from an IEEE 1394 digital camera, which is included in the control loop.

• The enormous number of IEEE 1394 devices in a large number of application fields (including automotive in the future) leads to multiple sources for components and independence from specific technology providers as well as low-cost implementations.

Because of all these reasons, a number of implementations already use IEEE 1394 for industrial automation. Although IEEE 1394 also provides a method to carry IP (Internet Protocol) data using the IPover1394 protocol, a typical industrial environment will look like depicted in Figure 1: parts of the system that require synchronized, deterministic communication with hard real-time requirements will use IEEE 1394, other functions like configuration and maintenance, visualization, and overall surveillance will be based on standard Ethernet with the possibility of proprietary solutions for integration of application specific modules.

Figure 1: Typical industrial environment using IEEE 1394 for real-time applications

2. IEEE 1394 Basics

IEEE 1394 is a serial bus connecting nodes with data rates up to 800 Mbit/s currently. As briefly introduced in the previous section, the standard supports two completely different types of data transfer:

1. Asynchronous transfers are controlled by a request and response scheme that guarantees a 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.

2. Isochronous channels are used for data that require a fixed, guaranteed bandwidth and submission at a fixed time-stamp. The 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.

These two transfer types use a common Physical and Link Layer of the IEEE 1394 protocol stack as depicted in Figure 2. The Link Layer provides addressing, data checking, and data framing for packet transmission and reception, whereas the Physical Layer transforms the logical symbols used by the Link Layer into electrical signals, which includes bus arbitration in case several nodes want to send data at the same time. The isochronous data are directly fed into the Link Layer, for asynchronous data an additional Transaction Layer implements the secure protocol using requests and responses for asynchronous transactions. All three layers exchange data with the so-called Serial Bus Management that incorporates some special functions for managing the isochronous bandwidth and optimizing the efficiency of the bus..

Link LayerPacket ReceiverCycle Control

Transaction Layer

Physical Layer

SerialBusManagement

PacketTransm itter

Read, W rite, Lock

Packets

Sym bols

Elektrical Signals &M echanical Interface

IsochronousChannels

Configuration &Error Control

Hardware

Firm ware

M edia InterfaceEncode / Decode Arbitration

Figure 2: Protocol architecture of IEEE1394

In the original version IEEE1394-1995 [5] of the standard and in the IEEE 1394a-2000 amendment [6] the physical media for IEEE 1394 were restricted to special 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 which is a drawback for industrial applications. A modified version of the STP cables still exists in the latest amendment IEEE 1394b [7], but a true differential signaling is now used and, more important, a number of other media have been added. A matrix with all supported speeds and reach for different kind of media is shown in Figure 3.

IEEE 1394b offers two options for IEEE 1394 in industrial applications. On one hand, existing CAT5 cabling can be used if a data rate of 100 Mbit/s is sufficient, e.g. if only short status and control messages have to be exchanged. On the other hand, optical media combine the advantages of high data rates with long distance and solve almost all EMI problems. Repeaters with multiple optical ports for set up of an all-optical

backbone and one copper port for attachment of end devices are already available (see Figure 4).

Figure 3: Supported media by IEEE 1394

Figure 4: Optical Repeater for IEEE 1394b

If the special IEEE 1394 STP cables – both for IEEE 1394a and IEEE 1394b – are used, not only data but also power can be provided. A maximum current of 1.5 A at a typical voltage of 12 V is sufficient for a lot of applications, so that a separate power supply can be omitted for most nodes. IEEE 1394b only affects the Physical Layer: existing applications that use the original IEEE 1394-1995 standard and the first amendment IEEE 1394a-2000 can migrate to IEEE 1394b by replacing the Physical Layer, no change of software is required.

Every data are transmitted as packets consisting of a header that describes the type and destination address of the packets and the payload. The IEEE 1394 standard only specifies how packets are transmitted from one node to another, i.e. it covers only the lower layers of the ISO/OSI architecture. The definition of common interpretation of the payload is left to application specific transport protocols. Related to industrial applications are the IIDC (Industrial and Instrumentation Digital Camera) 1394 based Digital Camera Specification [9] (short

DCAM) for industrial cameras delivering uncompressed video and the Instrument & Industrial Control Protocol IICP Specification [10] that defines how to implement the IEEE 488 protocol on IEEE 1394.

����� � � �� � � � � � � � � � � � � �

����� � � �� � � � � � � � � � � � � � � � � �

� � ���� � �� � � � � � � � � � � � � � �

�� � � �� � � � ! � � " � � # � � $

���� � � �� � � � � � � � � � � � � � � � � �

� � % � �� � & � �� ' � �� � � �� % � �� � � �( � � � ") � * �

����� � � �� � � � � � � � � � � � � �

����� � � �� � � � � � � � � � � � � � � � � �

� � ���� � �� � � � � � � � � � � � � � �

�� � � �� � � � ! � � " � � # � � $

���� � � �� � � � � � � � � � � � � � � � � �

� � % � �� � & � �� ' � �� � � �� % � �� � � �( � � � ") � * � In applications where IEEE 1394 is used for high performance industrial control systems, factory automation, or motion control, typically proprietary protocols have been used, since no international standard existed. In the meantime, leading European companies selling products for factory automation and motion control as well as research institutes working on IEEE 1394, factory automation and production technologies have formed the “1394 Automation” Association. Their main task – under technical leadership by some of the authors of this contribution – was to develop a standard called “1394AP (1394 Automation Protocol)” [11] that allows subsystems for factory automation and motion control from different vendors to communicate with each other via IEEE 1394.

3. The protocol 1394AP

A communication system in accordance to the IEEE 1394 Application Layer for Industrial Automation (1394AP) consists of one Application Master and up to 62 application slaves. The Application Master is the central control instance in the distributed control system. In most cases, this will be the programmable logic controller (PLC) or a personal computer (PC) that is part of the network, but any other node with sufficient computing power may take this functionality as well. During boot up of the system, each node signals its capability to become Application Master, in case of more than one contender, one node will be automatically chosen. The application slaves (called devices for the rest of the contribution) are controlled by the Application Master. Examples for devices are sensor devices, remote I/O devices, drives, cameras etc.

Device 1(Application Slave 1)

Application Master(e.g. PLC, PC)

Device 2(Application Slave 2)

Device 62(Application Slave 62)...

Figure 5: 1394AP System Architecture

Based on the IEEE 1394 network structure, the architecture of a 1394AP system can be seen as a logical bus system (see Fig. 5). The 1394AP communication layer model is based on the IEEE 1394 communication layer model. It uses the services provided by the IEEE 1394 Transaction Layer (see Fig. 6). A device is structured as follows:

1. Communication: This function unit provides the appropriate functionality to transport data items via the underlying communication.

Figure 6: 1394AP Communication Layer Model

2. Control Status Register: The CSR is a collection of all the data items which have an influence on the behavior of the application objects, the communication and the state machine used on this device. It is based on the principles concerning CSRs defined in IEEE 1394 and serves as an interface between the communication and the application.

3. Application: The application comprises the functionality of the device with respect to the interaction with the process environment.

1394AP offers three different services to the application:

a) Transmission and reception of Process Data (PD) include time critical control, sensor and actuator data. This is the main purpose of 1394AP.

b) The Service Data (SD) service describes the means, provided by the application layer, to transmit non-time critical parameter (and even complete software modules) for automation devices.

c) The Network Management (NMT) service describes the means, provided by the application layer, for station and network management.

These services will be described in more detail below. Because of the special requirements of industrial communication, some aspects differ from other, non-industrial IEEE 1394 protocols.

Concerning Process Data, the main task of the Application Master is the cyclic transfer of input data to the devices. This information is summarized in the

Master Data Telegram (MDT), which is the payload of an IEEE 1394 packet. The update rate of the control variables can be adjusted via the 1394AP specific Application Cycle. Its length is based on the requirements of the application. For high-speed applications, the Application Cycle is identical with 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 requirements, the Application Cycle is spread over several isochronous cycles. Then, for the MDT both isochronous and asynchronous packets can be used. In the first case, each packet only carries part of the complete MDT, in the second case asynchronous broadcast write requests are used. The MDT of 1394AP only defines a data structure for transmission of application specific variables, but does not specify the meaning of the variables itself. This is left to the application, which gives flexibility for the use of 1394AP. While the devices receive the MDT and extract the data for proper operation, they output their data via the Device Data Telegrams, short DDT. The DDTs transfer data both to the Application Master and to the other devices, so that a real peer-to-peer data transfer is ensured. The remarks on Application Cycle for the MDTs are also valid for DDTs.

IEEE1394 Application Layer for Industrial Automation (1394AP)

Asynchronous Transfer Interface

Bus Management

Interface

Isochronous Transfer Interface

Transaction Layer

Link Layer

Physical Layer

Bus Manager

Isochronous Resource Manager

Cycle Master

Node Controller

Management Layer Services

Transaction Layer Services Link Layer Services

Communication, Device and Application Profiles

Management Services

CSR Services SD Services PD Services

The mechanism described above for exchange of Process Data by 1394AP is called Clock Synchronised Process Data Communication and based on the Application Cycle, which is a multiple of the bus cycle e.g. for applications that do not require a cycle period of 125µs. The application cycle is indicated by the master data telegram, which follows the cycle start telegram and contains the application cycle count. The application master occupies channel 0 for the master data telegram. To indicate the relation of a certain device data telegram to the application cycle, the application cycle count is contained in each device data telegram. If the operational mode is activated the Process Data transmission is initiated by the synchronisation event. The synchronisation event is generated if the cycle start event occurs and the current application cycle is completed. An application master prepares the output data and transmits it using channel 0.

A device prepares the data acquisition if input data is supported. The input data is transmitted in the next possible isochronous channel slot associated with the device and its application cycle. If output data is supported, this data, received with an MDT (channel 0), is written out if the global output trigger time is expired. The same procedure is valid if the output data is received with a DDT within the same application cycle count.

Process Data may also be transmitted using asynchronous write packets which is called Event Synchronized Process Data Communication. The synchronisation behaviour is in principle the same for isochronous and asynchronous transactions. Only the

delay time and the jitter will probably be greater for asynchronous Process Data transactions.

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. The clocks running in each individual node are synchronized every 125 µs by the Cycle Start Packets. Data to be sent either as MDT or DDT are held in local buffers and marked with a time stamp. The time information contained in the Cycle Start Packets is used as trigger that releases the data for transmission. One problem has to overcome if isochronous and asynchronous data transfers are mixed. After a cycle start, first all isochronous packets are sent, the remaining part of the cycle is used for asynchronous data. However, IEEE 1394 does not check if the transfer of one asynchronous packet can be terminated within 125 µs since the last cycle start. If not, the next Cycle Start Packet will be delayed. For 1394AP, this results in non-deterministic timing, which cannot be accepted. Therefore, some pre-calculation of the overall bandwidth has to be carried out, which prevents the delay by managing the limited asynchronous resources between all nodes of the network. Isochronous transport is preferred in any case.

The MDTs and DDTs define the major software interface of 1394AP to the application. In order to ease the migration from other bus solutions to 1394AP without the necessity to re-write major parts of the application software, well known communication profiles will be adapted to 1394AP. As a first implementation, the CANopen Communication Profile [12] has been adopted to 1394AP. Process Data structures defined by CANopen have been mapped onto the MDTs and DDTs of 1394AP.

Service Data are always sent via asynchronous transactions; more than one logical connection may exist at the same time for a given device. Both upload (a device uploads service data from the Application Master) and download service (vice versa) are defined. The services are confirmed. A remote result parameter indicates the success or failure of the request. In the case of a failure, optionally the reason is confirmed. In the case of success, the data and its size are confirmed. Of course, it is also possible to abort an ongoing Service Data exchange. Concerning implementation, the transfer of large chunk of Service Data follows the procedures already defined in the SBP-2 standard.

The Network Management (NMT) state machine determines the behavior of the communication function unit. The state diagram of a device is shown in Figure 7. It follows basically the same mechanism as defined in CANOpen standards.

The INITIALISATION state is divided into three sub-states in order to enable a complete or partial reset of a device:

1. INITIALISING, after power-on or hardware reset. After finishing the basic node initialization the

device enters autonomously into the state RESET-APPLICATION.

2. RESET-APPLICATION: In this state the parameters of the manufacturer specific profile area and of the standardised device profile area are set to their power-on values. After setting the power-on values the state RESET-COMMUNICATION is entered autonomously.

3. RESET-COMMUNICATION: This sub-state covers the IEEE 1394 bus configuration procedure including channel and bus bandwidth allocation. The application master is then determined. After this the state INITIALISATION is finished and the device enters the state PRE-OPERATIONAL.

Initialisation

Pre-Operational

Operational

Stopped

Power on or Hardware Reset

Initialisation

Pre-Operational

Operational

Stopped

Power on or Hardware Reset

Figure 7: State Diagram of a Device

Devices enter the PRE-OPERATIONAL state directly after finishing the device initialization. During this state, device parameterization via Service Data services (e.g. using a configuration tool) is possible. The configuration of the 1394AP specific CSRs is performed by a configuration application running on the Application Master. The device may be switched into the OPERATIONAL state by sending a special "Start Remote Node" request.

In the state OPERATIONAL all communication services are active. The Process Data transfer starts with the first Master Data Telegram. By switching a device into the state STOPPED it is forced to stop the 1394AP functionality. In addition to the NMT mechanisms described so far, an optional "Node Guarding" protocol has been implemented which can be used for detection of failure in one of the nodes or the communication infrastructure.

4. Implementation of embedded IEEE 1394

Beyond the formal definition of the 1394AP protocol first efforts to implement it into real communication modules have been undertaken. Before any special aspects concerning 1394AP can be pointed out in Section 5, the generic architecture of an embedded IEEE 1394 device has to be described [13].

Only the lower layers of the IEEE 1394 protocol are realized by dedicated hardware, the upper layers are firmware. Therefore, every IEEE 1394 node must contain some kind of processor that executes the higher layers. Usually, the data handling is split: the processor executes the IEEE 1394 stack, cares about the asynchronous data, and controls additional low bandwidth hardware via programmed bit I/O, whereas the isochronous, time critical data are processed by some application specific hardware. In this case processors like the SAB-C161PI by Infineon or an ARM7 type give sufficient computing power. The use of an FPGA for the hardware processing of time critical data provides flexibility, so that the same design can be used for a broad range of applications.

A variety of Link Layer Controllers (LLC) from different manufacturers exists. For industrial applications the TSB12LV32 “GP2Lynx” by Texas Instruments is well suited. It provides a memory mapped interface to a microcontroller for asynchronous data and setup of the IEEE 1394 data transmission as well as a 16 Bit high speed data port that can send or receive data at full speed of 400 Mbit/s. For the Physical Layer any standard PHY chip can be used. A three-port PHY gives most flexibility for the network topology.

Figure 8: Embedded IEEE 1394 protocol stack

The architecture of the software implementation of the protocol stack (see Figure 8) represents the layer structure as defined in the standard. However, two additional layers are inserted which both provide a universal programming interface. The embedded application closely interacts with the Serial Bus Management, the Transaction Layer, and the Link Layer. In order to ease the coding of the application for the user, a common Application Programming Interface (API) must be provided. API calls include routines for initialization of the bus, the basic asynchronous transactions (Read, Write, and Lock), set up of isochronous transfers, and inquiry of information on the status of the bus and the local node as well as callback functions that are automatically executed in case of external bus events. The latter generate responses to

incoming requests without explicit programming in the application. However, the API, the Transaction Layer, and the Serial Bus Management shall be independent from the Link Layer Controller in order to be usable for different embedded systems. Therefore an additional Hardware Abstraction Layer (HAL) is used that transforms services requested to the Link Layer into corresponding hardware accesses. No embedded real time operating system is required; time critical tasks are scheduled via timers of the microcontroller.

An important issue especially for industrial applications not using the IEEE 1394b standard is the electrical interface between PHY and LLC. Since in IEEE 1394a DC voltage levels communicate some information between the PHYs, all PHYs are directly connected with each other. If the nodes are powered from an external supply, they might operate at different ground levels, which may produce a current flow on the IEEE 1394 cables. In order to prevent a faulty operation of the bus or even a damage of the nodes, a galvanic isolation between the LLC and the PHY is strongly recommended. Normally, if the chips include some busholder circuitry, a capacitor inserted in the data and control lines is sufficient. Of course, the problem of additional galvanic isolation vanishes if IEEE 1394b and optical media are used.

For proper operation of IEEE 1394 in industrial environments, a number of additional requirements must be fulfilled. First of all, it is important to follow the rules of the PHY manufacturers for PCB design which include short distance between PHY and LLC, etch traces that match the line impedance of the cable, and avoidance of vias between the PHY and the IEEE 1394 connectors. Secondly, galvanic isolation is self-evident for IEEE 1394a, as described above. Thirdly, EMI protection of the power supply must be applied. Fourthly, shielding and grounding have to be accurate. If these rules are considered, a stable operation of IEEE 1394 nodes can be guaranteed even under harsh industrial conditions.

Application

Application Programming Interface

Transaction Layer

asynch data

Hardware Abstraction Layer

isoc

h. d

ata

Link Layer

Physical Layer

Ser

ial B

us

Mg

mt.

Har

dw

are

Fir

mw

are

5. 1394AP Implementation

The previous sections have shown that the combination of IEEE 1394 and 1394AP provide an ideal means for industrial communication, especially in high performance motion control applications where a number of axes have to be synchronously controlled. In the past, some arguments were risen against the use of a technology originating from consumer electronics in an industrial environment. These were mainly the limited reach of 4.5 m between two IEEE 1394 nodes and the DC coupling via copper cables. However, these drawbacks are solved with the IEEE 1394b amendment, especially using optical transmission. All necessary components like chip sets, cables, connectors are rather cheap because of the parallel use in other application fields. Necessary software stacks can be licensed from

various suppliers, which will reduce development time and reduce associated costs.

For first experiments with 1394AP, a communication node that supports features of a preliminary version of the 1394AP protocol by hardware has been designed [14]. It can only be used as device, not as Application Master. Principally, it uses the system design described in Section 4, but comprises a different Link Layer Controller because of the special communication pattern defined in 1394AP. The “GP2Lynx” is only capable of either sending or receiving isochronous data, but not both simultaneously as required for MDTs and DDTs. Therefore, the Texas Instruments TSB42AB4 “CeLynx” device is used in this design. Originally targeted to consumer electronics, it is also well suited for industrial applications and supports full duplex isochronous streaming.

Figure 9: Architecture of node communication via 1394AP

The resulting schematic of the node is shown in Figure 9. Since worst case an MDT has to be processed every 125 µs (Application Cycle equal to one) the filtering of the incoming MDTs and DDTs is carried out by an FPGA implementation. Therefore, the microcontroller of type Infineon C167CS only has to handle relevant data. Outgoing DDTs are sent as asynchronous packets and directly written into the Link Layer Controller by the microcontroller. Figure 10 shows the industrial communication node. First experiments with this embedded system have shown that 1394AP is suited for industrial real-time communications, especially for motion-control systems. Despite the limited computing capabilities of the C161 microcontroller and missing DMA channels between the FPGA and the µC, cycles less than 250 µs between transmissions of two MDTs have been achieved. Of course, this limits the Application Cycle to two, but a full featured 1394AP node (i.e. Application Cycle equal to one) can easily be build by choosing more powerful processor with DMA capability like an ARM type.

Figure 10: Node for synchronous industrial communication via IEEE 1394

In addition to these developments directly targeted to 1394AP, there are already IEEE 1394 equipped products for factory automation and motion control available. Most common are industrial cameras that use the IIDC standard. For specification of 1394AP it was an important criterion that other protocols can also be used at the same time. The IIDC standard was most crucial, since it was the goal to have one infrastructure for motion, vision, and I/O. This has been achieved, in case the bus provides enough bandwidth. Cameras compliant to IIDC are available both with CCD and CMOS imagers, with geometrical resolutions ranging from VGA (640 x 480 pixels) up to several megapixels.

Other factory automation products with IEEE 1394 interface include a motion control system (see Figure 11) that can be connected to servo and step motors and a bus coupler (see Figure 12) which acquires analog and digital data from arbitrary sensors or provides data to any kind of actuators. For the latter data interfacing with a PC is very easy, only a low-cost IEEE 1394 interface card is needed.

� � + , # -

� � � �

� � � � � � � � � � �

� � �

� � � � �

� �

� � � �

� � � � � � � �

� � � � � � �� � � �

� � � � �

� �

! � � � � " � � �

� � � �

# � # $ % �

" � % � � �

# � # $ % �

" � % � � �

# � # $ % �

� � �

� � & � � '�./

� � & � � �

� � �

� ( � ) * � � � � � � � � �

� � � + , -

� � � * � � � � � � � � � � � �

� � �

� � . � / / � � . � � � � � � �

+ , - � � � � ' � � � � � � �

# � � � � � � � & � � � � *

0 � � � � &

) � � � # � � # � � � � # � � � 0 � � �

) � # � � � # 1

� 2 3 4 4 �

� � + , # -

� � � �

� � � � � � � � � � �

� � �

� � � � �

� �

� � � �

� � � � � � � �

� � � � � � �� � � �

� � � � �

� �

! � � � � " � � �

� � � �

# � # $ % �

" � % � � �

# � # $ % �

" � % � � �

# � # $ % �

� � �

� � & � � '�./

� � & � � �

� � �

� ( � ) * � � � � � � � � �

� � � + , -

� � � * � � � � � � � � � � � �

� � �

� � . � / / � � . � � � � � � �

+ , - � � � � ' � � � � � � �

# � � � � � � � & � � � � *

0 � � � � &

) � � � # � � # � � � � # � � � 0 � � �

) � # � � � # 1

� � + , # -

� � � �

� � � � � � � � � � �

� � �

� � � � �

� �

� � � �

� � � � � � � �

� � � � � � �� � � �

� � � � �

� �

! � � � � " � � �

� � � �

# � # $ % �

" � % � � �

# � # $ % �

" � % � � �

# � # $ % �

� � �

� � & � � '�./

� � & � � �

� � �

� ( � ) * � � � � � � � � �

� � � + , -

� � � * � � � � � � � � � � � �

� � �

� � . � / / � � . � � � � � � �

+ , - � � � � ' � � � � � � �

# � � � � � � � & � � � � *

0 � � � � &

) � � � # � � # � � � � # � � � 0 � � �

) � # � � � # 1

� � + , # -

� � � �

� � � � � � � � � � �

� � �

� � � � �

� �

� � � �

� � � � � � � �

� � � � � � �� � � �

� � � � �

� �

! � � � � " � � �

� � + , # -

� � � �

� � � � � � � � � � �

� � �

� � � � �

� �

� � � �

� � � � � � � �

� � � � � � �� � � �

� � � � �

� �

! � � � � " � � �

� � � �

# � # $ % �

" � % � � �

# � # $ % �

" � % � � �

# � # $ % �

� � �

� � & � � '

� � � �

# � # $ % �

" � % � � �

# � # $ % �

" � % � � �

# � # $ % �

� � �

� � & � � '�./

�./

� � & � � �

� � �

� ( � ) * � � � � � � � � �

� � � + , -

� � � * � � � � � � � � � � � �

� � �

� � . � / / � � . � � � � � � �

+ , - � � � � ' � � � � � � �

# � � � � � � � & � � � � *

0 � � � � &

) � � � # � � # � � � � # � � � 0 � � �

) � # � � � # 1

� � & � � �

� � �

� ( � ) * � � � � � � � � �

� � � + , -

� � � * � � � � � � � � � � � �

� � �

� � . � / / � � . � � � � � � �

+ , - � � � � ' � � � � � � �

# � � � � � � � & � � � � *

0 � � � � &

� � �

� ( � ) * � � � � � � � � �

� � � + , -

� � � * � � � � � � � � � � � �

� � �

� � . � / / � � . � � � � � � �

+ , - � � � � ' � � � � � � �

# � � � � � � � & � � � � *

0 � � � � &

) � � � # � � # � � � � # � � � 0 � � �

) � # � � � # 1

� 2 3 4 4 �

6. Summary

Given the new 1394AP standard, it has become possible to build communication systems for factory automation and motion control that benefit from all technical advantages of IEEE 1394. Main reason to use this technology in industrial application is the deterministic behavior of the communication with guaranteed delivery times of critical information. As explained in detail, IEEE 1394 offers that feature inherently. But also other advantages like high data rate, flexible network topology, possibility of peer-to-peer communication and low implementation cost make it an almost ideal choice for industrial communication, as long as some basic implementation principles are followed.

Figure 11: Industrial motion control system using IEEE 1394 (© Nyquist Control)

Figure 12: Industrial I/O module with IEEE 1394 (© WAGO Kontakttechnik)

Interoperability between manufacturers is ensured because of the standardization by 1394AP. However, given the European base of the 1394automation group responsible for 1394AP, propagation of this protocol would be limited. Therefore, 1394automation has joined the 1394 Trade Association (1394TA) with more than 150 member companies worldwide. Its goal is to promote the use of IEEE 1394 in markets like consumer electronics, computers, automotive and industrial & instrumentation. 1394AP will become an official standard of the 1394TA very soon.

Technically, the next step concerning the use of IEEE 1394 and especially 1394AP for factory automation and motion control is the development of standards and test

tools for compliance and interoperability tests. Although desirable for any kind of IEEE 1394 device, these tests are of special importance for industrial systems given the possible damage a device may cause in case of faulty operation. Fraunhofer IPMS, among others, is a Certified Test Lab by the 1394TA for IEEE 1394 conformance tests and involved in that process.

In summary, IEEE 1394 is already more than an emergent technology for factory automation and motion control nowadays, since it will be widely used in industrial applications very soon.

References

[1] IEC 61158/61784: Digital Data Communications for Measurement and Control: Fieldbus for use in industrial control systems, 2003.

[2] ISO Standard 11898: Controller area network (CAN), International Standards Organization, 2003.

[3] IEC 61491: Electrical equipment of industrial machines – Serial data link for real-time communication between controls and drives, 2002

[4] D. Anderson: Firewire System architecture (2nd edition). Addison-Wesley, 1999.

[5] IEEE Standard for a High-Performance Serial Bus 1394-1995, IEEE Press, Piscataway, 1996.

[6] IEEE Standard for a High-Performance Serial Bus Amendment 1 1394a-2000, IEEE Press, Piscataway, 2000.

[7] IEEE Standard for a High-Performance Serial Bus Amendment 2 1394b-2002, IEEE Press, Piscataway, 2002.

[8] Serial Bus Protocol 2 (SBP-2). ANSI Standard NCITS 325-1998.

[9] IIDC 1394-based Digital Camera Specification, Version 1.31. 1394 Trade Association, 2004

[10] 1394TA IICP Specification for the Instrument & Industrial Control Protocol, Version 1.00. 1394 Trade Association, 2000.

[11] IEEE 1394 Application Layer for Industrial Automation, 1394automation e.V., Minden (Germany), 2004

[12] CiA DS 301 V4.0.2: CANopen application layer and communication profile. CAN in Automation e.V., Erlangen (Germany), 2005

[13] M. Scholles, U. Schelinski, P. Nauber: IEEE 1394 for Factory Automation. In: R. Zurawski (Ed.): The industrial information technology handbook. CRC Press, Boca Raton, Fl., 2004, p. 45/1 - 45/12.

[14] M. Scholles, U. Schelinski, P. Nauber, K. Frommhagen: Data Transmission in Industrial Environments Using IEEE1394 “FireWire". In: R. Zurawski (Ed.): The Industrial Communication Technology Handbook. CRC Press, Boca Raton, Fl., 2005, p. 17/1 - 17/12.