In a time-triggered protocol, the schedules for all messages are predefined and peridocal. So each node in an ensemble knows a priori when to send or when to expect to receive some message. For an overall communication cluster. Time-triggered systems are predictable, it is relatively easy to verify a communication schedule, and the diagnosis of a defect component is facilitated. However, TT systems are inflexible, therefore they are mainly used in dependable systems such as automotive (Flexray protocol) and avionic applications (Safebus, TTP).
With TTP/A, there is, however, also a time-triggered fieldbus protocol. A fieldbus connects devices like sensors, controllers, and actuators, and, therefore must support a higher flexibility than traditional TT applications. On the other hand, the periodic behavior of message schedules is beneficial for sensor/actuator applications and closed control loops, where timeliness is required and arbitrary message delays worsen or even invalidate the result.
TTP/A manages these contradictionary requirements for timeliness, predictability and flexibility by reserving a part of the schedule for monitoring and configuration. Although this means, that the effective communication rate for real-time traffic is reduced, it, unlike in other protocols, guarantees this rate, regardless of other traffic.
The hardware requirements for TTP/A are low – even for embedded systems standards. The protocol runs on any microcontroller providing a UART interface, a few kilobytes of flash memory and around 100 bytes (sic!) of RAM. A generic implementation is available as open source software.
Links on TTP/A:
- W. Elmenreich, Time-triggered smart transducer networks, IEEE Transactions on Industrial Informatics, 2(3):192–199, 2006
- TTP/A Protocol, Specifcation, and Tools
- H. Kopetz, M. Holzmann, and W. Elmenreich. A Universal Smart Transducer Interface: TTP/A, International Journal of Computer System, Science & Engineering, 16(2):71–77, 2001
- The TTP/A Protocol at Wikipedia