-
An Application Layer for using Firewire in industrial
applications
Philippe Dallemagne Centre Suisse dElectronique et
de Microtechnique Jaquet-Droz 1
2007 Neuchiitel, Switzerland [email protected]
Abstract
Firewire can ofer real-time communication services for
industrial applications. However, Firewire lacks an
industry-oriented Application Layer. This paper presents the
services which may be used over Firewire, in order to make it
compliant with the industrial applications needs. The mapping of
these services on Firewire services is also described. This
Application Layer gives the ability to easib and rapidly set up
real-time communications in an industrial context.
1 Introduction
1.1 Firewire as a fieldbus Fieldbuses (Interbus-S[ 171,
Profibus[ 181, CAN[ 191,
FIP[12], etc.) greatly helped in reducing the costs of
industrial control systems. However, most of them have now reached
some limits (response time, bandwidth, etc.). Previous experiments
191, [ 101, [ 1 11, [ 131 have shown that Firewire (IEEE
1394-1995)[1] can be used in an industrial environment, for example
motion control or tool-machines control. Firewire brings better
performances (100 to 400 Mbit/s) than current fieldbuses at
comparable costs. Since the Firewire standard includes a backplane
version, it is also applicable to the backplane buses, which
suffers from the same limitations.
In the cable environment, Firewire can help in improving the
performance of the communication while reducing the cost of
distributing the application, since several Firewire interfaces are
already available for consumer appliances. The use of Firewire as
the communication system and the definition of an adapted
Application Layer (AL) will hopefully lead to the definition of a
powerful control platform, that respects the specific industrial
application requirements [6], [7].
Moreover, the use of Firewire in backplane environments allows
the definition of intermediate systems, from the most centralized
to the fully distributed, in a almost transparent way.
Luis Ruiz Centre Suisse dElectronique et
Jaquet-Droz 1 2007 Neuchstel, Switzerland
[email protected]
de Microtechnique
1.2 The need for an Application Layer for Firewire
Firewire defines a serial bus that can connect at high speeds
several kinds of devices, called bodes. This standard is based on
the Control and Status Register (CSR) Standard IS0 13213[2]. It has
been designed for connecting multimedia devices. It offers services
especially well suited for video streams, for example Digital Video
[4]. These Isochronous services can be used for transferring
real-time data in industrial applications [9], [lo], [ l l] ,
[13].
Asynchronous transactions are not time-bound, but the delivery
is guaranteed. They can therefore be used for configuration,
download, etc.
A fieldbus (or Local Industrial Network) is characterized by the
presence of only the two lower layers of the OS1 model. It usually
provides also a dedicated Application Layer [ 141, [ 161. Firewire
basically defines the Physical and the Data Link Layer. Therefore,
specific services need to be defined in an upper layer so that
applications fully and consistently benefits from the Firewire
performances.
The application may also directly use the standard services of
Firewire with some restrictions in order to keep the other services
out of trouble (for example to avoid skew on the cycle start).
1.3 Concepts The Application Layer services aim at handling
and
transferring variables, events, interrupts, and programs. This
AL is kept as simple as possible and offers real- time capabilities
as well as non real-time.
The available services are basically derived from MPS
(Manufacturing PeriodicaVaperiodic Services) [12], E161 and MMS
(Manufacturing Message Service) [22], [16], but they do not handle
lists of variables. Variables are uniquely identified and
characterized over the whole network. The AL offers two families of
services : MPS-like services and SubMMS [12]-like services. The AL
handles real-time variables (periodic, sporadic) like in M P S and
asynchronous services (i.e. non real-time) like in MMS. The former
basically consists of Read (local and far), Write (local and far)
and Update primitives for variables. The latter basically
WFCS-2OO0, September 6-8, Porto, Portugal
0-7803-6500-3/00/$10.00 @2000 JEEE 109
-
consists of download, program invocation services, aperiodic
variables management, etc.
Variables database. A variables distributed database is used to
globally and uniquely identify and describe every piece of data
(variable) that is transferred with the help of the AL. On any
participating node, the AL is informed of the characteristics of
the exchanged variables and it maintains the variables database
(identifiers, temporal or structural characteristics, properties,
etc.), which is built during the network initialization (variables
declarations). The AL transfers variables of different types and
sizes. These variables can be time-constrained (periodic or
sporadic) or not (aperiodic) [21]. Events and interrupts can be
efficiently instantiated through several periodic variables.
However, non real-time events and interrupts should be implemented
through aperiodic variables to lower the stress on the periodic
traffic.
A global synchronization is maintained throughout the network,
based on the built-in Firewire cycle (125 ps.). Every event related
to any variable (production, transfer, etc.) is time-stamped with
the cycle count.
The application is notified when the local copy of a variable
has been refreshed, modified or in error condition (not produced,
not periodically refreshed, etc.). The application may also modify
the variable value, start or stop its (periodical) production or
trigger its aperiodic production.
Variables type. The definition of data types for variables
pertains to some kind of Presentation layer, which is not covered
in this paper, even though this aspect is usually part of the
fieldbuses AL. The variables that are transferred in an industrial
environment are usually of basic types, like byte, 16-bit word
winlet), 32-bit word (quadlet), 64-bit word (octlet), floating
point value (range, precision and coding to be determined), byte
stream (length is variable).
Phases. The AL operates in two phases: configuration (nodes
identification, master election, variables declaration, calculation
of the macro-cycle, subscription, etc.) and operation (variables
exchanges, etc.), where the producing nodes produces variables
periodically or on request.
1.4 Benefits and expected results The usage of the Firewire
isochronous bandwidth is
optimized and periodic variables can be transferred in
real-time. The AL will make Firewire suitable for high- performance
real-time applications.
2 Application Layer presentation
2.1 Communication models Real-time variables (periodic and
sporadic) are
broadcast by their producers and consumed by the nodes that need
them. The communication model used here is the producer-consumer.
Any other information will be
considered as non-critical and it will be handled on a
best-effort scheme. However, the timing aspects (production or
delivery dates for example) of the aperiodic variables will be
available to the application. An aperiodic variable is available to
any application that requests it (the client node). This request
will be completed by a response from the node that produces the
variable (the Servefnode). This family of services uses a
client-server model to exchange data through Firewire asynchronous
transactions. The asynchronous services include download and
program invocation capabilities.
Consumers of periodic or sporadic variables are rather passive
for the real-time traffrc since they do not request the variables.
The consumers of aperiodic variables are hctive, since they
explicitly request the variable value, although the transfer of the
value of such a variable is broadcast to save bandwidth.
2.2 Architecture The AL defines a Master node and
participating
nodes. Any of them can be a producer and/or a consumer. After
the regular Firewire initialization, a Master node is elected. Then
it starts the AL configuration process, during which it gets all
the productions declarations, from which it computes a macro-cycle,
which determines the real-time traffic. The macro-cycle is
broadcast to every participating node and the Master starts the
operational phase, in which the producers strictly follows the
macro-cycle so that real- time variable can be produced
periodically and on time.
2.3 Variables in industrial applications Aperiodic (non
time-critical) variables. An
aperiodic variable must be able to provide its age (date of
production) to the application. It is made of a name, a type, a
time-stamp, a value, a toggle and an optional validity duration (in
number of Firewire cycles).
Real-time variables. A periodic variable is made of a name, a
period (in number of Firewire cycles), a validity duration (in
number of Firewire cycles), defined by the application, a type, a
value (in relation with the variable type), a time-stamp and a
toggle. The AL itself may also evaluate the variable promptness and
freshness.
A periodic variable is periodically transmitted on the network.
The producer indicates that the value of the variable has changed
by toggling an indicator bit that is sent as a field of the
variable delivery frame (i.e. not inside the variable value, which
may be difficult to decode and interpreted by the lower layers).
Thus the AL can warn the application that the variable value has
changed (Update).
The value of a periodic variable is valid for the associated
period (or for a given validity interval). Therefore, the value is
said to be invalid when its age is greater than its period. Like in
FIP, we could use timers to indicate this event to the application.
The timers are reset when the variable is received.
110
-
Sporadic variables. A sporadic variable is made of a name, a
deadline (in number of Firewire cycles), a minimum inter-arrival
delay (in number of Firewire cycles), a type, a time-stamp, a value
and a toggle. They can not be piggy backed on the periodic traMic
since the period of this periodic traffic may not comply with the
sporadic variable requirements.
They are considered as regular periodic variables. The only
difference is that they wont be updated periodically and the
quality evaluation is different.
Interrupts and events. An interrupt can be considered as a
sporadic variable that needs an acknowledgement (clear). When the
application signals an interrupt, the AL signals it to the Data
Link Layer (DLL), immediately confirms the service and clears the
interrupt when the variable has been sent. #en the consumer
receives a interrupt value with a modified toggle, the DLL signals
the interrupt to the AL which in turn signals it to the application
and clears the interrupt.
Similarly, the events are sporadic variables (without any
acknowledgement) that can be simulated by dedicated periodic
variables, which samples the possible event indicator at the
producer end. The modification of the variable (its toggle has
changed) at the consumer end means that the event occurred at the
producer end.
With the toggle generalization, we can ensure that any value
modification will be indicated to the application. With two
periodic variables, the application can implement the behavior of
an interrupt. This allows the transfer of event and interrupts
through periodic variables.
Therefore, a so-called Interrupt is entirely handled by the
application. For example, the application can create two periodic
variables: one for the indication, and another for the
acknowledgement of the interrupdevent, if necessary. From the
application point of view, the interrupt will be immediately
cleared by the source when sent and by the target as soon as it is
handled after reception.
We dont consider complex event management, like in XED for
example. Though they offer a greater flexibility, such features
seem far too complex and heavy for communication controllers. It
will be up to the application to determine the value of boolean
events. The evaluation formula will be defined and transmitted by
other means.
Variable management. All variables are time- stamped for their
production and emission. The AL maintains freshness and validity
indicator, based on the reception date and the lifetime.
A variable value that is sent over the network by the protocol
also includes a modification toggle, which will indicate whether
the value has changed since the last update of the variable. The
producer of the variable calculates the value of the toggle. This
is applied for periodic variables as well as for aperiodic
variables, which are broadcast (ie. without any acknowledgement) :
this gives the ability to send the same value several times
(re-send for forward error correction) without troubling nodes
that already received the value correctly.
The production node may stop the actual production of a periodic
variable during the network operations. However, the periodic
variable value is still sent, with a bit that indicates that the
variable production is started or stopped.
Quality of the variable database. The quality of service can be
monitored by the application. It depends on the quality of the
information delivered to the different applications that make use
of the information. This quality relies on the variable quality and
the global consistency of the handled variables. The variable value
quality shall be appreciated on freshness, promptness (age),
validity term, deadline (earliest term, latest term) respected or
not, confidence (optional), etc.
The producer and the consumers of a variable must also take care
of un-initialized variables. The AL must keep this information in
its database.
2.4 Productions scheduling and macro cycle The macro cycle is
calculated in order to enable all
periodic productions to occur in accordance with the production
periods (including interrupts and events). The macro-cycle
specifies the Firewire cycle and the isochronous channel in which
any variable shall be produced. It is valid until a bus-reset
occurs. The macro- cycle allows every producer to produce its
variable on time. The macro-cycle is therefore the Least Common
Multiple (LCM) of all producers cycles.
The periodic traffic is based on three periodical production
cycles: - Local micro-cycle, which is the biggest interval in
which a given production is done only once, ie. the period (it
is at least one bus cycle),
Figure 1. Example of local microcycle.
- Local macro-cycle, which is the smallest interval in which the
highest rate periodic variable (on the node) occurs LCM(al1 periods
on the node) times. Therefore, it is the interval in which the
complete production combination occurs only once,
Local macro-cvcle
i Local micro-cycle for A
The variable A IS produced every 375 us The vanable B IS
produced every 250 us
- Bus cycle,
125 us. 0
Figure 2. Example of local macro-cycle.
111
-
- Global macro-cycle, which is the combination of local
macro-cycles from all producers, i.e. the smallest interval in
which the highest-rate periodic variable (of all nodes) will be
produced LCM(all periods on all nodes) times.
A structure, called macro-cycle, is broadcast by the Master node
to every node in the network. This macro- cycle specifies which and
when any variable shall be produced during the Global macro-cycle
duration.
3 Mapping of the AL services on Firewire
3.1 Firewire basic services and CSR architecture
IEEE- 1394- 1995 asynchronous transactions can constitute a
Basic Asynchronous Transactions service. The application can use
them to perform specific, Firewire compliant, asynchronous
transmissions. Isochronous channels may be genuinely used by
applications.
Specific hnchor points are defined for the AL services in the
1212 CSR architecture (memory- mapped). For example, a variable may
be considered as an address in the CSR architecture. This address
should be accessed from any layer, but will likely be known by the
application. The objects manipulated by the protocol are mapped
onto the CSR architecture. This means that some addresses will be
reserved for our own needs.
3.2 Synchronization with the Firewire cycle One of the purposes
of the AL services is to transfer
real-time variables on-time. The AL uses the convenient Firewire
built-in clock synchronization mechanism (cycle start) that is
issued by the root node. This $lobal clock has a rate of 8kHz. It
will be used for time- stamping every exchanged variable. All
timings and duration are expressed in Firewire cycles.
The CSR Architecture defines a Clock Synchronization mechanism
using optional, dedicated registers [2],[1]. The Firewire start
cycle maintains a coherent time reference between all nodes. The
Firewire cycle count (CYCLE-TIME register, updated at each cycle
start) is used for time-stamping and macro- cycle/synchronization,
which gives the age (absolute consistency) and time consistency
(local relative consistency). The CYCLE-TIME register is a 32-bit
register. It is structured in 3 fields: secound-count (7 bits, in
seconds -> 128 seconds range), cycle-count (13 bits, in 1/8000th
of a second) and cycleoffset (in 1/3072th of a cycle). The
cycle-offset is used for the positive( ie. late) skew. A
cycle-offset different from 0 indicates that the past cycle was
late of this value. The Firewire root automatically corrects this
skew.
The time-stamping and synchronization of the periodic traffic
(variables, events and interrupts) and the nodes that handle them
is implicitly done with the help of the Firewire cycle. More
sophisticated
synchronization schemes can be implemented by the application by
reserving some periodic variables to simulate synchronization
variables.
3.3 Point-to-point, multicast or broadcast communication
Point-to-point transfers are implemented with asynchronous
transactions, since the target and initiator nodes are identified
in the asynchronous packets. However, the asynchronous transactions
are not time- bounded.
Multicast transfers are implemented with Firewire, since the bus
is a broadcast tree. Multicast is therefore done using broadcast
transactions, explicitly filtered by the application on all nodes,
or implicitly filtered by the DLL. This can be done with
asynchronous transactions (node 63 for broadcast) or with
isochronous actions (all channels are broadcast). The use of
isochronous channels should be reserved for time-critical data.
Broadcasts are easily implemented with both the isochronous (all
channels and 63 specifically) and asynchronous (to node 63)
transactions.
4 Application Layer services
4.1 Presentation The AL offers services for the initialization
and
operations phases. Initialization. The network initialization is
made of
the Master node election, the producers and consumers
identification, variable localization and addressing scheme,
macro-cycle calculation and diffusion. It handles also errors
(variables inconsistencies - two or no producers, no consumer, type
conflicts, etc.).
Each producer will declare (broadcast) the list of its produced
variables, associated to its allocated channel number. The
declaration interval begins when the first variable declaration is
performed. It is terminated when there is no more arbitration for
asynchronous transactions or no more variable declaration inside a
fairness interval. The Master node allocates the necessary
bandwidth after having received all the variables declarations.
The Master node also establishes control points from which the
process can not go hrther if the control conditions are not
fulfilled. For example, the Master counts the number of responses
it gets (from both the producers and consumers) and it can use
these numbers in later steps, in order to check the consistency of
the produced and the consumed variables, for example.
Operations. Services are performed by using the available
Firewire services. The real-time traffic (periodichporadic
variables, events and interrupts) occurs in isochronous channels
(previously allocated), because the Firewire asynchronous services
do not guaranty the delay of delivery (an asynchronous
112
-
transaction can take up to 22 ms. to complete, which is too long
for the target applications).
Other services are operated through asynchronous transactions,
ie. read, write and lock (and asynchronous streams from 1394a),
which specify the address and memory usage in conformance to the
CSR architecture [2]. This is not desirable to use isochronous
actions to perform these services, since they may interfere with
the real-time isochronous traffic (i.e. periodic and sporadic
productions, events and interrupts).
The services described here are based on the IEEE 1394-1995
standard. Extensions like the IEEE 1394a standard (frozen but not
official) may be used. If 1394a is used, asynchronous broadcast on
node 63 may be replaced by an asynchronous stream, though it does
not offer any obvious benefit.
The AL does not support hot plugging. No nodes can be inserted
in the network during operation, because it would induce a
bus-reset, thus making the macro-cycle obsolete.
4.2 The Master node declares itself as Master candidate
and, if elected, it receives the variables declaration, it
calculates the macro-cycle and informs every participating node of
the macro-cycle. This node may or may not be the root. It could be
any node that declares itself as Master-capable.
The first participating node that says I am Master candidate is
elected, ie. recognizes itself and is recognized by the other
participating nodes as the Master. All other pending candidates
shall retire when they have recognized that another node has
declared before. The Master is elected first so that the Master
could be identified by all participating nodes, thus allowing them
to send it some configuration-oriented asynchronous
transactions.
When a node receives the first candidature, it registers the
candidate Physical-ID as the Master and sends a you are the Master
message to the candidate. This latter message is accompanied by an
boolean indicating whether the node is a variable producer or
not.
The Master is confirmed as being the Master when it receives at
least one you are the Master asynchronous indication from any node
(except itself).
All producer node shall send the you are the Master message. The
parameter producer shall be set to 1 (Yes). The Master shall count
the number of producers that send such a message. This will give
the number of producing node in the network, once the timer
expires.
Then the Master broadcasts a bend me variables lists to all
participating nodes. All pending you are the Master messages shall
be ignored. The Master may also be a producer or a consumer and it
will also act as such.
In the case of the candidate node being alone on the bus (no
nodes replies to its candidature will occur) a timer shall be set
in order to time-out the Master election. If the Master election
fails, the MPS-like
Election of the Master node
services are not started and any further MPS-like PDU shall be
ignored.
There is also a timer to decide when the election replies
process expires. This timer is set to 2 fairness intervals, i.e. 44
ms (to ensure that every node will have an opportunity to send an
asynchronous transaction).
4.3 Periodic variables declaration Each declared producer
allocates a channel number,
which will identify the producer. Then, each producer declares
its produced variables and its channel number by an asynchronous
transaction to the Master. The consumers can associate the channel,
the producer and the variables list.
Each producer must send a variables declaration (even if it does
not intend to produce anything : the variable list will be empty).
It is important since the Master counts the number of variables
declaration and compares it to the number of producers. When the
number of list declarations equals the number of producers, the
variables declaration service ends. Further declaration are
ignored. The Master checks the variables identifiers to ensure that
no double declaration exists. This event shall be reported to the
application.
4.4 Aperiodic variables declaration To ensure the aperiodic
traffic, the Master node
reserves one asynchronous stream channel. No bandwidth
allocation is necessary since asynchronous streams pertain to the
asynchronous traffic, which complies with the fairness
algorithm.
The Master allocates a asynchronous stream channel before. This
channel is called Aperiodic Traffic Channel (ATC). This ATC number
will be immediately broadcast to all nodes by a broadcast
asynchronous transaction. All capable nodes will therefore know
that this channel will be reserved and used for the aperiodic
traffic, and all their Application layer shall record the ATC
number for future use. As long as this channel is unknown, no
aperiodic traffic shall occur.
Once the ATC is defined, any pending aperiodic variable request
can start.
The Master node can free the ATC. It shall first broadcast the
free transaction. All aperiodic traffic shall cease within the next
two faimess intervals. After two faimess intervals (running
requests and subsequent response will complete), the ATC will be
supposed to be free.
The aperiodic variables names are known by the requesting nodes,
since the aperiodic traffic producers publish the lists of
available variables so that consumers can request them to the right
node.
4.5 Macro-cycle and channel allocation The macro-cycle indicates
which variable shall be
produced in which cycle. It means that some variables will not
be produced in every cycle. In order to avoid the
113
-
overhead of allocateddeallocating the channels and bandwidth,
the isochronous bandwidth must be bver- allocated. The sum of all
producer needs would exceed the maximum allowed isochronous traffic
per Firewire cycle (lows.), without however exceeding, at any one
Firewire cycle, a given percentage of the overall bandwidth (for
example, 70%).
Some producers may have several periodical productions to make,
at different rates. For a given producer, the isochronous allocated
bandwidth corresponds to the highest sum of the micro-cycles
bandwidth requirement on any bus-cycle, during the local
macro-cycle. The channel bandwidth allocation (made by the Master)
is equivalent to the greatest load of production in all bus cycles
included in the local macro- cycle. Therefore, a part of the
bandwidth will likely be lost in each channel. The bandwidth usage
must therefore be optimized: the Master will try to fit all
production according their timing requirement into the available
bandwidth, thus trying to allocate the lowest possible bandwidth.
In case of insufficient available bandwidth (impossible scheduling
with the available bandwidth), the Master reports an error to all
participating nodes
The producers are not able to allocate their own required
bandwidth, because the resulting needed Firewire bandwidth would
exceed 100 %, which is not allowed.
Less than the whole bandwidth is used for the AL services at any
Firewire cycle, so that some free isochronous bandwidth may be
available for other isochronous devices (DV cameras, etc.).
Example of allocation. For example : a node that only needs to
produce a variable (say a quadlet) each Firewire cycle will have a
local micro-cycle of one Firewire cycle for the variable and a
local macro-cycle of one Firewire cycle. A node that needs to
produce two variables - one quadlet each cycle, one quadlet each
two cycles - will have two micro-cycles - one of one cycle, the
other of two cycles - which gives a macro-cycle of two cycles.
4.6 The start of the macro-cycle is indicated to the
application. On each Firewire cycle start, the AL tests if it is
the start of the macro-cycle. Each producer shall use this
indication as the beginning of the macro-cycle. This is also a
useh1 indication for re-synchronization.
As the node needs to send isochronous data on specific Firewire
cycles on a periodic basis, it needs to know precisely when the
data shall be made available to the PHY and whenhow it will be
actually sent on the wire. When the period of a given variable
completes (matching of the Firewire cycle number with the cycle of
production of the variable), the application programs the Firewire
adapter so that it sends the variable value (outgoing transmission
pipe). In the first next cycle, the value will be sent inside the
channel. By the
Time reference and data transfers
consumer, the value will be available in the Incoming
transmission pipe. The modification of a is indicated to the
application. The expected behavior is therefore : when something is
sampled at the start of cycle N and put in the transmission pipeat
cycle N, it shall be sent at cycle N+1.
4.7 Network start The Master starts the network by a
broadcast
asynchronous transaction, when all producers know when and what
to send.. The macro cycle starts on the next Firewire Cycle start
(i.e. immediately following the Start). The producers will
arbitrate the bus to start the productions, accordingly to the
macro-cycle.
If a station misses the cycle start, the Master station will
detect that the corresponding scheduled productions did not occur
during the first macro-cycle. It will stop the network. All
productions will be stopped.
4.8 Transfer mechanisms Periodic variables production. Two
techniques,
based on the capabilities of Firewire, have been considered for
periodic variable production: - using time stamping, which relies
on the Firewire
clock synchronization mechanism (based on the cycle start packet
and the dedicated registers). using isochronous channels (one for
each producing node) in which a sufficient slice of the bandwidth
is periodically reserved for a given variable.
Both solutions have been used in order to time-stamp
-
variable and to guarantee on-time delivery.
Master Producers
.........I Master allocate a channel for a compu bandwidth
(overall needed for the dec
accordingly to the macro cycle
Figure 3. Periodic traffic (summary)
114
-
The periodic variables production of a given node takes place in
an isochronous channel that is associated to the node during the
network initialization. The variable value is time-stamped by the
producer with the cycle in which the variable has been sampled. The
production is triggered when the current cycle corresponds to the
cycle in which the variable must be produced. (This information is
actually taken from the macro-cycle initially sent by the
Master).
Periodic consumption. The isochronous channel traffic is
broadcast on the bus, therefore all nodes can read it. The Master
makes this information available in the macro-cycle. Since the
Master sends the macro-cycle to every participating node, every
consumer will therefore know the characteristics of any variable
and its production channel. The AL of the consumers shall keep a
list, which links any locally consumed variable to its respective
production channel, to which the AL must be sensitive. The consumer
application must therefore tell its AL what are the expected
variables (subscription).
Then, applications that want to consume variables will listen to
the corresponding channels. However, as a node may produce several
variables, a consumer node will receive several variables inside
one packet, some of them being useless to it. It is then up to the
Application layer to extract the needed variables.
The consumer AL stores a copy of the received values. It tests
the toggle of each transmitted variable to determine if the value
has changed, which may be indicated to the application. The
variables value are always available to the application, which
requests them to the AL database (local Read).
. .. ... . .. va.~.ab!er. .ue~.~~.at!h~~.~i .nt . . -
Variables list broadcast
...... .... . . .. .. .. Variables ... . .... . . . list ....
and . ..... location . ..... .. ..... . known.. ..... .~ - c - - v
m -se : variable value
Server Client
...-I ..... .. . ..
>
.....
._.
- on ATCvariablevalue I I I I
-:\{# list broadcast Figure 4. Aperiodic traffic (summary)
Aperiodic variable transfers mechanism. The transfer of an
aperiodic can occur at any time (on request) once the Master starts
the network. The aperiodic variables are also declared by the
variables owner, but this can happen at any time during the network
operation (asynchronous broadcast). A variable can also be deleted.
A dedicated asynchronous channel is allocated, without any
bandwidth (the channel number is associated to the variables
declaration). The channel is an asynchronous stream that is
broadcast inside the asynchronous traffic. This service is based on
a client-server production model : a node (the client) requests the
value of a given variable to another node (the server) which
completes the service by returning the variable value to the
client. The request is broadcast on node 63. The variable is
returned in the dedicated asynchronous stream channel. Thus the
aperiodic variable is made available to every consumers, which will
record the variable value. This avoids several requestlresponse
sequences.
5 Conclusion and future work
5.1 Conclusion The Application Layer enables the Firewire
technology to achieve the main expected result, which was to
have guaranteed real-time exchanges. It also makes the application
scalable and independent from the variable location, since the
Master automatically computes a valid macro-cycle before starting
the network operations. It offers other useful features for
real-time application development, such as a better comprehension
of the whole application and the possibility to check and validate
an architecture or a distribution of the data.
Therefore, the implementation of this Application Layer gives to
Firewire new perspectives outside of the multimedia field. It gives
Firewire the ability to be used in the industrial activities by
easily and rapidly developing or porting test applications.
Finally, associated to such an Application Layer, Firewire
represents a strong contender for the current fieldbuses, at least
in some areas, like tool-machine or short-range industrial network.
For example, about 30 axis of a multi-axis tool-machine can be
managed in lms. control loop.
5.2 Future work New functionalities and services may be added in
the
future, for example the definition of an bccurate mode in which
the possible start cycle skew would not be allowed anymore. This
could be useful for system for which skew must not occur (eg. motor
position). The use of asynchronous transactions shall therefore be
controlled, thus preventing from any asynchronous transaction that
would last longer than the remaining bandwidth. Such a goal could
also be achieved by using
115
-
judicious local timers on producing nodes. Some guidelines or
profiles may be published so as to define application-specific
types of variables and their behavior. The spatial consistency of
the distributed database should be more formally covered: a
variable can be used by several applications, each of them having a
local copy of the variable. All local copies of a given variable
should be consistent network-wide. This property is not evaluated
in the current implementation of the AL.
An Application Programming Interface (AFT) should eventually be
provided, in order to give access to the AL services through
high-level languages. This would give a good understanding of the
available services, enables faster development cycles and improves
the maintainability of the application.
Finally, the performance of Firewire combined with its
Application Layer must be measured on the field in many real-world
applications.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
IO.
1 I .
12.
IEEE Standard for a High Performance Serial Bus, IEEE, 30 august
1996 ISOhEC 13 123: 1994, Control and Status RePister (CSR)
Architecture for Microcomputer Buses, IEEE, 1994 G. Ulloa, L. Ruiz,
P. Raja, F. Guidec, and J. Hernandez,
Characterizing Temporal Consistencv in a Fieldbus Environment,
presented at Singapore International Conference on Intelligent
Control and Instrumentation SICICIP2, Singapore, 1992. IEC 61883,
proposed standard for Digital Interface for Consumer Electronic
AudioNideo Equipment L. Ruiz and J.-D. Decotignie, Fieldbus: a
Network for Process Level Communication, IEEE Industrial
Electronics Society Newsletter, vol. 41, pp. 4-6, 1994. Z. Mammeri,
Classification des contraintes temuorelles, Contribution
GDR-PRC-PRS, Groupe temps-rCel, 1996, Centre de Recherche en
Informatique de Nancy. DesprCs F.M., Automatisation des svstkmes de
productions, du besoin a I'utilisation, Collection "industries",
Cditions Kirk, Maisons-Alfort, 1993. S. Koppenhoefer, J.-D.
Decotignie, D. Auslander, Fieldbus Based Integrated Communication
and Control Svstems, Proceedings of Computational Engineering in
Systems Applications , CESA'96 IMACS-IEEE/SMC Multiconference,
Lille, France, 9-12 juillet 1996, pp.
L. Ruiz, P. Dallemagne, J.-D. Decotignie, Using Firewire as
Industrial Network, 19" Conference of the Chilean Computer Society,
Taka, Chile, Nov. 8-13, 1999. J.-D. Decotignie, L. Ruiz and P.
Dallemagne, Un &eau
de terrain a hautes performances sur la base de Firewire,
presented at INNOCAP99, Grenoble, France, 1999. Philippe
Dallemagne, Luis Ruiz, Laurent Mealares, _A low-cost real-time
system for control and monitoring of high performance
tool-machines, presented at Real-Time Systems 2000, Paris, March
2000. NF C 46-601 Bus FKP : architecture et prksentation gCnCrale.
AFNOR 90
13 16-1 321.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
N. Stampfl, IEEE 1394 in comparison with Other Bus Svstems,
Proceedings of the fieldbus Conference FeT99, pp. 3 13-3 18,
Magdeburg, Germany, September 23-24, 1999. P. Pleinevaux and J.-D.
Decotignie, Time Critical Communication Networks: Field Busses,
IEEE Network Magazine, vol. 2, pp. 55-63, 1988. Schickhuber G.,
McCarthy, O., Distributed Fieldbiis and Control Network Svsterns,
IEE Computing and Control Engineering Journal, February, 1997.
RCseaux locaux industriels, Z. Mammeri, J.P. Thomesse. Eyrolles,
Paris octobre 93 INTERBUS-S, Reference Manual for INTERBUS
Peripherals Communication Protocol, Phoenix Contact, 1991.
PROFIBUS-Process Field BUS DIN Deutsches Institut fiir Normung
E.V., Berlin (D) 1988 DIN V19245-1988 (Teil
ISO/DIS 11898: 1998, Road Vehicles, Interchange of Digital
Information - Controller Area Network (CAN) for High-speed
Communication, ISO, 1998. Jean-Dominique Decotignie, Patrick
Pleinevaux, _A Survev on Industrial Communication Networks, Annales
de TClCcommunications / Annals of Telecommunications,
Jean-Pierre Thomesse, Miguel Leon Chavez, Main Paradigms as a
Basis for Current Fieldbus Concepts, Proceedings of the fieldbus
Conference FeT99, pp. 3 13- 3 18, Magdeburg, Germany, September
23-24, 1999. International standard IS0 9596- 1. Manufacturing
Message Specification (MMS), Part 1 : Service definition.
Intemational Organization for Standardization, 1994.
1+2).
V01.48, No.9-10, pp.435-448, 1993.
116
