The FTT Paradigm

System Architecture

• Master Node
  • System Requirements Data Base (SRDB) contains the communication requirements
  • Communication requirements API
    • Allows to add, remove or change the properties of message streams
    • Changes to the SRDB do not require distributed consensus
  • Online Scheduler
    • Scheduling is a local Master decision
    • Scheduler operates online on the SRDB
      • Changes to the SRDB aooear seamlessly on the bus
  • Online admission control and QoS manager
    • Non-feasible change requests are rejected
    • The highest possible amount of resources is given to each stream (if the application handles dynamic QoS)
• Master/Multi-Slave scheme
  • Reduces overhead
  • A single Trigger-Message (TM) triggers several slave messages
• Trigger-Messages may trigger message transmissions as well as tasks
  • Holistic scheduling supported
• Scheduling policy independent of the underlying bus protocol
  • Arbitrary scheduling policies can be implemented
• Support for different traffic types
  • Synchronous (Time-Triggered)
    • Controlled autonomously by the network
  • Asynchronous (Event-Triggered)
    • Triggered explicitely by the application
  • Real-Time
    • Subject to admission control
    • Reserved resources
  • Non Real-Time
    • Transmitted in background
    • Best effort

Control Channel

• Traffic is allocated in fixed duration Elementary Cyles (EC)
• Trigger-Message contains the EC schedule
• The Master broadcasts the TM at the beginning of every EC
• Slaves transmit accordingly to the received TM schedule

FTT-CAN

Implementation of the FTT paradigm on the Controller Area Network (CAN) protocol

• Targets simple 8 and 16 bit microcontrollers
  • Implementations available for Philips 80C592 and Microchip PIC18 & DsPIC families
• Supports both synchronous and asynchronous traffic
• Asynchronous traffic is autonomously transmitted by the slaves
  • An abort mechanim prevents window overruns

FTT-Ethernet

Implemantation of the FTT paradigm on the Ethernet

• Shared Ethernet presents a single broadcast domain and non-deterministic collision resolution mechanism
• FTT Trigger-Messages include timing information to prevent collisions
  • Slave nodes transmit messages at precise time instants
• Asynchronous traffic is periodically pooled by the Master node
• Single scheduler and ready queue
• Implementation on the SHaRK RTOS

FTT-SE

Implementation of the FTT paradigm on Switched Ethernet

• Controls the traffic submitted to the switch
  • No switch queue/memory overflows
  • Bounded and deterministic latency for Real-Time traffic
• Support to unicast, multicast and broadcast traffic

Asynchronous traffic

• Event-Triggered traffic
• Signaling mechanism posts the Master about slave's requests
• Asynchronous real-time and non real-time traffic are also scheduled by the master
  • Real-Time guarantees obtained with the use of servers
  • Non real-time supported in the background, without timeliness guarantees

FTT-Enabled Switch

Integration of the FTT Master functionality in a custom Ethernet switch

FTT-Enabled switch properties

• Seamless integration of standard (non-FTT) nodes without jeopardizing the real-time services
• Asynchronous traffic autonomously triggered by the end nodes
• Traffic Policing
  • Unauthorized transmissions blocked at the switch input ports
• Reduction of the switching latency (low periodic traffic jitter)

FTT-Enabled switch internal architecture

• Fully implemented in hardware ( based on the NetFPGA platform )
• Packets are classified at the ingress ports
  • Packets that do not conform with the declared requirements are discarded
• Packets are stored in reserved memory areas according with its type
  • No memory contention among different traffic types
  • Worst-case analysis and resource reservation mechanisms allow guaranteeing that memory is always available for real-time traffic
• Output queues controlled by the master (implemented in hardware)
  • Extremely low jitter
  • Traffic confinement strictly enforced