![](https://csdnimg.cn/release/download_crawler_static/16272809/bg14.jpg)
SAE AS6802 Page 20 of 108
NOTE: More priorities can be implemented as necessary. The use of traffic classes with priorities higher than that of the
protocol control frame can have a significant impact on the delay of the protocol control frames in the system. See
Chapter 11 for calculation of the bounds.
The worst-case queueing delay as introduced by dataflow of higher priority than PCFs shall be bounded.
NOTE: These bounds cover the worst-case scenario. Further guidance for calculating these bounds can be found in
Chapter 11 (shuffle delay, maximum shuffle delay).
A Time-Triggered Ethernet device shall implement a non-preemptive dataflow integration algorithm.
NOTE: A Time-Triggered Ethernet device may also implement a preemptive dataflow integration algorithm. A preemptive
dataflow integration algorithm has side effects to be considered. For example, when a frame with high priority is to
be transmitted on a given communication link, a preemptive dataflow algorithm will truncate the ongoing
transmission of a frame with low priority. As a result, the receiver has to anticipate the reception of truncated
frames. It is possible that the truncation of a frame results in a valid Ethernet frame whose CRC matches its
contents.
A Time-Triggered Ethernet device that implements both preemptive and non-preemptive integration algorithms shall
provide a configurable parameter, specifying which algorithm the component will use during operation.
Mechanisms to ensure partitioned access to shared resources (e.g., frame memory) shall be implemented.
NOTE: Guidelines for implementation of these partitioning mechanisms are out of scope of this document and are
defined for example in ARINC 653.
3.5.2 Failure Hypothesis Requirements
In a Time-Triggered Ethernet cluster configured to tolerate a single faulty component, either a synchronization master or a
compression master, documentation shall be provided that argues that the failure behavior of all compression masters
and all switches is fail-silence or fail-inconsistent-omission.
NOTE: One way to achieve an inconsistent-omission failure mode is a high-integrity design, see Appendix B.
NOTE: At the time of the writing of this standard document, ongoing research is concerned with extending the algorithms
defined in this document in a way that the requirement of an inconsistent-omission failure mode for certain Time-
Triggered Ethernet devices can be removed. These extensions are intended to be incorporated in upcoming
releases of this standard.
In a Time-Triggered Ethernet cluster configured to tolerate a single faulty component, either a synchronization master or a
compression master, documentation shall be provided that the failure behavior of all synchronization masters is fail-
silence, fail-inconsistent-omission, or fail-arbitrary.
In a Time-Triggered Ethernet cluster configured to tolerate multiple faulty components, documentation shall be provided
that the failure behavior of any compression masters, synchronization masters, and switches is fail-silence or fail-
inconsistent-omission.
NOTE: One way to satisfy an inconsistent-omission failure mode is to use a high-integrity design, see Appendix B.
NOTE: The inconsistent-omission failure behavior is NOT satisfied by a posteriori notification of a faulty transmission. All
Ethernet frames that are output from a high-integrity Time-Triggered Ethernet device are either correct or
detectably faulty within the receiving Time-Triggered Ethernet device.
A Time-Triggered Ethernet device that is able to relay time-triggered traffic shall be configurable to accept a time-
triggered-transferred frame only when the transfer is received within a defined acceptance window.
NOTE: This mechanism is depicted in Figure 5. The acceptance window is opened and closed at a point in time derived
from the synchronized timebase. The length of this acceptance window is configurable.