The FTTEthernet protocol: Merging flexibility, timeliness and efficiency

1
The FTT-Ethernet protocol Merging flexibility,
timeliness and efficiency
Paulo Pedreiras1, Luís Almeida1, Paolo Gai2
1 DET-IEETA University of Aveiro P-3810-193
Aveiro, Portugal
2 Retis-Lab Scuola Superiore Sant'Anna Pisa,
Italy
2
Presentation outline

• Real-time communication system requirements
• Why (not) Ethernet?
• Methods to achieve Real-time behavior on Ethernet
• The FTT-Ethernet protocol
• FTT-Ethernet implementation based on S.Ha.R.K.
• Experimental results
• Conclusions and future work

3
Real-time communication system requirements

• Distributed systems are widely disseminated in
  automation and control applications
• Most of these systems rely on fieldbuses to
  interconnect the set of nodes
• In this context, fieldbuses can be required to

• Support different types of traffic
• Time-triggered , Event-triggered
• Hard real-time , Soft real-time , Non real-time

4
Real-time communication system requirements

• Predictable message transmission
• Bounded delivery time for all real-time messages
  under all foreseen traffic conditions
• Fair message transfer of non real-time messages
• Operational flexibility
• Temporal consistency information
• Efficient bandwidth utilization

5
Real-time communication system requirements

• Over the last years it was observed
• An increase in the quantity and functionality of
  the nodes
• New classes of more demanding applications
  (e.g. machine vision)
• Dynamic environments (e.g. mobile robotics)
• Resulting in a steady increase in the amount of
  data exchanged over the network and requiring
  an increased operational flexibility
• These demands are pushing the traditional
  fieldbuses (e.g. CAN , WorldFIP , ProfiBus ) to
  their limits.

6
Why (not) Ethernet?

• There is a trend towards the use of Ethernet at
  field level. Common arguments favoring its use
• Higher transmission speeds, still increasing...
• Compatibility with networks used at higher
  layers in the factory structure
• TCP/IP stacks over Ethernet are widely
  available, allowing the use of application layer
  protocols such as FTP, HTTP, etc.
• Cheap, due to mass production

7
Why (not) Ethernet?

• Common arguments against the use of Ethernet at
  field-level
• Non-deterministic arbitration scheme
• Message delivery is not guaranteed

8
Achieving real-time behavior on Ethernet

• Many techniques and protocols have been used to
  support real-time behavior on Ethernet.
• CSMA/DCR, Master-Slave, TDMA, Token-passing,
  Virtual time, Traffic smoothing, Switched
  Ethernet
• These protocols vary in their goals, favoring
  different aspects.
• Either hard or soft timeliness guarantees
• Either event or time-triggered traffic
• Allowing or not, dynamic communication
  requirements

9
Achieving real-time behavior on Ethernet

• None of these methods fullfils all the
  requirements previously stated, because they
  either
• Lack support for some types of traffic
• Are inflexible concerning message set and/or
  scheduling policy
• Do not provide timeliness guarantees
• Do not enforce temporal isolation between
  distinct traffic types
• Are bandwidth or response-time inefficient
• Require specialized hardware

10
The FTT-Ethernet protocol

• The FTT-Ethernet protocol is our attempt to
  fulfill all the referred requirements
• It is based on the
• Flexible Time-Triggered (FTT) paradigm
• that has been recently developed at the
  University of Aveiro, following a successful
  implementation on Controller Area Network
  (FTT-CAN)

11
The FTT-Ethernet protocol

• FTT-Ethernet protocol main features
• Time-triggered communication with operational
  flexibility
• On-the-fly changes on message set and scheduling
  policy
• Online admission control (real-time traffic)
• Temporal accuracy information
• Support for different types of traffic
• event/ time-triggered, hard / soft /
  non-real-time
• Temporal isolation between the distinct traffic
  types
• Efficient use of network bandwidth

12
The FTT-Ethernet protocol

• The FTT paradigm relies on two main features
• Centralized scheduling
• Master/multi-slave transmission control

13
The FTT-Ethernet protocol

• Centralized scheduling
• communication requirements and message
  scheduling policy localized in one single node
  (Master)
• Facilitates on-line changes to either message set
  as well as scheduling policy
• Facilitates the implementation of on-line
  admission control

14
The FTT-Ethernet protocol

• Master/multi-slave
• the same Master message is used to trigger
  several messages in several slave nodes.
• Enforce the traffic timeliness in the bus
• (typical of Master-Slave transmission control)
• High bandwidth utilization efficiency
• (compared to typical Master-Slave transmission
  control)

15
The FTT-Ethernet protocol

• How it works?
• Traffic is allocated in fixed duration time slots
  ( Elementary Cycle - EC )
• Bus time is organized in an infinite succession
  of ECs
• ECs start with a trigger message (TM) sent by the
  Master

16
The FTT-Ethernet protocol

• ECs have two phases (windows)
• The synchronous window
• Conveys the time-triggered traffic
• The trigger message contains the EC-Schedule,
  i.e. IDs and transmission instants of messages
  that are scheduled to be produced within the
  synchronous window
• The asynchronous window
• Event triggered traffic, arbitration based on
  waiting times
• Non real-time traffic, polled by the Master node

17
The FTT-Ethernet protocol
Elementary Cycle structure
18
The FTT-Ethernet protocol

• The Master node
• Maintains a database holding
• System configuration (e.g. EC duration, tx rate)
• Communication requirements
• Builds EC-schedules according to a scheduling
  policy Any scheduling policy can be used (e.g.
  RM, EDF)
• Periodically broadcasts the EC trigger message
  (conveying the respective EC-schedule )

19
The FTT-Ethernet protocol
Master node architecture
20
The FTT-Ethernet protocol

• The Slave nodes
• Execute the application software required by the
  user
• Use communication services (Real-Time API) to
• define the messages locally produced / consumed
• update / read the value of corresponding
  real-time entities
• set-up call-backs associated to communication
  events.
• Two communication stacks
• one for non-real-time (standard IP protocol
  suite)
• other for real-time communication (collapsed 3
  layers model)

21
The FTT-Ethernet protocol

• The Slave nodes
• Access to the Ethernet bus is made via the
• FTT-Ethernet Interface Layer which
• Decodes the TM
• Transmits the messages at appropriate
  instants (according to the EC-schedule)
• Routes the received messages to the appropriate
  communication stack.

22
The FTT-Ethernet protocol
Slave node architecture
23
The FTT-Ethernet protocol

• What are the tradeoffs?
• The downsides of FTT-Ethernet are
• Relatively inefficient handling of ET traffic in
  shared Ethernet, due waiting time based
  arbitration
• Time-related periodic message properties
  constrained to be integer multiples of the EC

24
FTT-Ethernet implementation on S.Ha.R.K.

• FTT-Ethernet requires an ensemble of tasks
• Some of them present tight temporal constraints
• Application tasks should not interfere with the
  protocol timeliness

Use a real-time kernel Soft and Hard Real-Time
Kernel (S.Ha.R.K)
25
FTT-Ethernet implementation on S.Ha.R.K.

• The Soft and Hard Real-Time Kernel (S.Ha.R.K)
• was developed at the ReTiS Lab, Pisa, Italy
• fully modular, highly customizable
• task and device scheduling
• temporal isolation and task execution time
  control
• blocking and non-blocking communications
  mechanisms
• interrupt and hardware port handling
• compliant with almost all POSIX 1003.13 PSE52
  spec.

26
FTT-Ethernet implementation on S.Ha.R.K.

• S.Ha.R.K module configuration
• Several scheduling modules can be configured
• Tasks registered on high priority modules are
  scheduled in foreground with respect to tasks
  registered on lower priority modules

Master Dispatcher, Scheduler Slaves Network
driver, FTT-Interface layer
highest
Real-time application tasks
Module Priority
intermediate
Non-real-time protocol tasks Non-real-time
application tasks
lower
27
Experimental Results

• To assess the protocol feasibility and
  performance, some experiments have been realized
• Synchronous message scheduling with
• Rate Monotonic, Earliest Deadline First
• Elastic Task Model for dynamic QoS handling
• EC duration of 10ms, Synchronous Window using
  50 of EC
• 29 synchronous messages with periods between 1
  and 5 ECs
• The results obtained have shown that
• High utilization of the synchronous window,
  80-95
• Timeliness guaranteed with on-line changes in
  message set

28
Conclusions and future work

• This paper presented
• A set of requirements for real-time communication
  systems in automation / control applications
• Pros and cons of using Ethernet at field level
• An overview of tecniques and protocols for
  real-time over Ethernet

29
Conclusions and future work
30
Conclusions and future work

• Future work
• Master replication and synchronization
• Joint scheduling of periodic and aperiodic
  traffic (using a sporadic server)
• Implementation over Switched Ethernet
• Lower protocol complexity (on the nodes)
• More efficient handling of both event and
  time-triggered traffic