User:IveGoneAway/sandbox/Time-Triggered Communication Protocol
- Note: The following is modelling of edits to multiple pages to accomplish clarification of the above issue. Level 1 headings are used here only to indicate the intended page.
A time-triggered communication protocol, commonly, time-triggered protocol, is a method of communication wherein a sequence of scheduled communication actions, distributed among multiple transmitters sharing a common channel, is repeated in a periodic cycle.
- TTP is a registered trademark of TTTech
Time-Triggered Communication Protocol, commomly time-triggered protocol (abbreviated TTP or TT) refers to a class of communication protocols that employ cyclic, isochronous scheduling of bus access by multiple transmitters, generally in the form of time division multiple access (TDMA).[1]
<Rushby> static preallocation of communication bandwidth in the form of a global schedule
Time-triggered communication protocols generally provision for a fixed and repeating schedule of isochronous transmissions where channel access is distributed among multiple transmitters. The schedule (or cycle) may be divided into a fixed schedule of sub-cycles, each having a different but fixed schedule of transmissions. In some systems, portions of such cycles may be overridden by of non-isochronous channel access controls; for example, a cyclic time window or slot may be given over for a fixed period of asynchronous bus access, such as a limited period of CDMA arbitration as in the case of TTCAN.
Time-triggered communication is generally preferred over event-triggered methods for integrated safety-critical systems, because the method provides for verifiable deterministic composition of multiple system functions, e.g, integrated modular avionics.[1][2]
It is a bit arbitrary to state that C and D happen only every other cycle (...|ABC|ABD|ABC|ABD|...) versus A and B happen twice every cycle (...|ABCABD|ABCABD|...)
Certain time-triggered communication protocols are accomplished by defining a time-trigger higher-level protocol over a pre-existing protocol having no inherent isochonous features. For example, CAN bus permits and supports collisions with optional retry after collision, which is considered non-deterministic;[3] so, safety-critical protocols that are built upon CAN bus enforce time-triggered message scheduling (e.g., TTCAN, CANaerospace/ARINC 825).
Characteristics
[edit]TBD
Distinctions from other classes of communication protocols
[edit]| Protocol | Access | Schedule | ||
|---|---|---|---|---|
| time-triggered | multiple transmitters | cyclic | distributed | a priori |
| MIL-STD-1553 | multiple transmitters | cyclic | central | a priori |
| ARINC 429 | single transmitter | cyclic | distributed | a priori |
| USB | multiple transmitters | cyclic | distributed | ad hoc |
distributed vs. central schedule
[edit]Time-triggered protocols rely on a distributed channel access schedule; that is, each transmitter node must have (1) a means of synchronization with the network schedule and (2) knowledge of when it is scheduled to have channel access within that schedule. More simply put, every node must be able to schedule itself such that it transmits it signals only within in its allotted time slots. Thus, these protocols are distinct from Bus Controller/Bus Master systems wherein only a single node is responsible for controlling multiple-transmitter bus access, even if that access may be within a cyclical schedule (an example being MIL-STD-1553).
multiple vs single access
[edit]Periodic multiple-transmitter time-triggered protocols are naturally distinct from periodic single-transmitter messaging protocols, ARINC 429 being an example of the latter. In the ARINC 429 protocol, exactly one transmitter is connected to the bus, thus avoiding requirements for multiple access techniques. Also, even though individual ARINC 429 messages are transmitted on periodic static schedules (within the maximum and minimum transmit intervals for each label), multiple labels on a bus are not necessarily collectively scheduled into a larger logical cyclic frame or major cycle. The specification of a single ARINC 429 label message includes its periodic timing, but not its timing relative to other labels that may be in the same channel[4]
(although such cyclic effects may be a natural consequence of the implementation of the particular labels for a given channel).
While transmission of labels on a ARINC 429 channel is scheduled in cycles, there is only one transmitter on the channel. However, the definition of the schedule is available to all receivers, at least at the specification level, so that receivers may be developed to conform to the predefined label schedule.
Generally, time-triggered protocols are deployed into systems with the time-trigger portion of communications pre-defined (a priori'). While the USB protocol has cyclic messsage sheduling, the schedule is
static vs dynamic schedule
[edit]The safety-critical isochronous time-triggered protocol schedules are static (a priori) schedules as opposed to dynamic or auto-negotiated (ad hoc) schedules. That is, the a priori time-triggered schedule is typically predefined and qualified before operation, whereas ad hoc time-triggered schedules can be made up "on the fly" cases as of USB networks, which include auto-negotiated, plug-and-play, isochronous mode.
Implementations
[edit]Examples of time-triggered communication protocols include:[5]
- ISO 11898-4, CAN Time-Triggered Communication (TTCAN)
- SAE AS6802, Time-Triggered Ethernet (TTEthernet); effectively, time-switched ARINC 429 channels over Ethernet
- SAE AS6803, TTP Communication Protocol (TTP), SAE standardization of TTTech's proprietary time-triggered protocol
- FlexRay
- AUTOSAR Virtual Function Bus employs logical time-triggered Flexray frames, which are virtually or physically transported between applications as Flexray frames or as segments over other low-level protocols; e.g., CAN, LIN
- ARINC 825, General Standardization of CAN Protocol for Airborne Use (CANaerospace)[6]
See also
[edit]References
[edit]- ^ a b Cite error: The named reference
ObermaisserParawas invoked but never defined (see the help page). - ^ Cite error: The named reference
Rushbywas invoked but never defined (see the help page). - ^ Cite error: The named reference
Pikewas invoked but never defined (see the help page). - ^ Cite error: The named reference
ARINC429was invoked but never defined (see the help page). - ^ Cite error: The named reference
ObermaisserCommwas invoked but never defined (see the help page). - ^ Cite error: The named reference
Knueppelwas invoked but never defined (see the help page).
External
[edit]Time-triggered CAN, CAN in Action (CiA)
Bibliography
[edit]
Embedded Systems Handbook, Second Edition: Networked Embedded Systems edited by Richard Zurawski See 14 contribution= {{cite book | last =Obermaisser | first =Roman | contribution= Time-Triggered Communication | publisher =CRC Press is this the same as above?
See 13.2 Event Driven vs TT |title= Trends in Automotive Communication Systems |author= Nicolas Navet |url= https://books.google.com/books?id=9g_IPCI_alUC
|title= Time-Triggered Fieldbus Networks – State of the Art and Future Applications |author= Wilfried Elmenreich, Lakeside Labs, Mobile Systems Group, Institute of Networked and Embedded Systems, University of Klagenfurt |url= http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.184.7405&rep=rep1&type=pdf
- ^ Knueppel,, Ralph (2012), Standardization of CAN networks for airborne use through ARINC 825 (PDF), CAN in Automation, CAN in Automation
{{citation}}: CS1 maint: extra punctuation (link) - ^ Obermaisser, Roman (2005). Event-Triggered and Time-Triggered Control Paradigms. Springer Science+Business Media. pp. 21–23. ISBN 978-0-387-23044-3.
- ^ Obermaisser, Roman (2011). Time-Triggered Communication. CRC Press. ISBN 978-1-4398-4661-2.
- ^ ARINC Specification 429, Part 1-17. Annapolis, Maryland: Aeronautical Radio, Inc. 2004-05-17.
- ^ FlexRay Communications System Protocol Specification
- ^ John Rushby (2001). "A Comparison of Bus Architectures for Safety-Critical Embedded Systems" (PDF). CSL Technical Report. SRI International. Retrieved 2017-01-30.
: A time-triggered system interacts with the world according to an internal schedule, whereas an event-triggered system responds to stimuli that are outside its control.
: In a time-triggered bus, there is a static preallocation of communication bandwidth in the form of a global schedule: each node knows the schedule and knows the time, and therefore knows when it is allowed to send messages, and when it should expect to receive them. Thus, contention is resolved at design time (as the schedule is constructed), when all its consequences can be examined, rather than at runtime.
: Time-triggered operation provides efficiency, determinism, and partitioning, but at the price of flexibility. To reduce this limitation, most time-triggered buses are able to switch among several schedules. - ^ Lee Pike (2007). "Modeling Time-Triggered Protocols and Verifying Their Real-Time Schedules" (PDF). Formal Methods in Computer Aided Design.
The inability to demonstrate correctness through testing motivates us to prove these systems are correct. The specific class of control systems considered in this paper are time-triggered systems. Time-triggered systems are implemented as distributed systems in which each node in the system is independently-clocked, and under normal operating conditions, synchronization mechanisms maintain tight synchronization among the local clocks [5]. When the nodes are tightly synchronized, the temporal behavior of the system can be abstracted as if the nodes execute in lockstep. This sort of abstraction is characterized by the synchronous model or untimed model. At the level of abstraction that the synchronous model provides, formal correctness proofs of the protocols are difficult but feasible [7, 8]