Time-Triggered Protocol (TTP)

TTP has been implemented and used in different domains such as FlexRay in the automotive industry, SAFEbus for serial production and the avionics industry. It is also used for the Airbus A380 and Boeing 787 Kopetz (2003). TTP presents a deterministic, synchronized and congestion-free network based on the IEEE 802.3 Ethernet protocol and is compliant with ARINC 664 part7.

Time-Triggered Transmission

In step (a), task T2 packs m2 into frame f2. Then, in step (b), f2 is placed into buffer B1.T x to prepare it for transmission. There is one buffer for every TT message sent from ES1. There are always static communication schedules that are stored in the form of tables, referred to as routing tables in ESs and NSs. These tables are produced off-line. In this example, the schedule is shown by S. In step (d), f2, which is a TT task, is sent to NS1. The duration of this transformation is determined by the schedule and is stored in the S of ES1 in step (c). Generally, TT tasks are scheduled to be sent before the next scheduled message for transmission. In step (e), f2 is sent to NS1 through a dataflow link. The Filtering Unit (FU) checks the integrity and validity of frame f2 in step (f) and forwards it to the TT receiver task, T TR, in step (h), which then copies it into sending buffer B1,T x for later transmission. In the last step, f2 is sent by the TT sender task in NS1 to NS2. Then, in step (k), f2 arrives at ES2, and the FU stores the frame in buffer B2,Rx. The task T4, then, is activated to read f2 from buffer (m).

Data Flow integration

This section seeks to describe the mechanisms and consequences of the integration of TT and RC dataflow on the single physical platform. There are three different ways to accomplish this integration: Preemption, Timely Block and Shuffling.the purpose of these three integration mechanisms is to clarify when a concurrency exists between two messages with different priorities and what decision should be taken in such a case. If these messages have the same priority, they will be served in FIFO, but in the case of unequal priority, the message with high-priority (H) is served and the message with low-priority (L) will be queued.

Preemption stops the process of relaying message L when message H arrives. The switch takes a minimum of silence time and relays the message H. This mechanism introduces the constant and a priori known latency for message H. But the truncated messages could appear incorrectly to the receiver, which is one of the issues with the preemption mechanism. Two possible solutions to this are first, to include the message length within the message second, to use a signal pattern that violates the line encoding rules when a message is truncated. If a fraction of a truncated message is lost, the whole message will be retransmitted; this causes a loss of bandwidth due to the truncation. Timely Block is a mechanism that ensures switches will not forward messages at those times that TT messages are expected. This mechanism causes more delays while it keeps the scheduled ports free for messages H. The maximum possible number of Ethernet frames for messages L in Timely Block is only 19. To overcome this constraint, the ES and SW need to act more intelligently; thus when the length of message L is known and transported inside of a given message, the switch will determine if enough bandwidth is available to send message L completely before message H has to be relayed.

Shuffling is an optimal solution that delays message H until the message L process is finished. In the worst case, the delay is equal to the maximum length of message L. This delay also impacts the subsequent message H, because the bandwidth required for the message L is compensated by the sum of the inter-frame gaps between the two succeeding messages H. This mechanism does not truncate a message, nor block the outgoing port for message L, which makes it more efficient then the two previous mechanisms. If message H is a TT message, the real-time quality of the time-triggering is degraded. Latency cannot be mitigated; however, in a 100 Mbit/sec or 1 Gbit/sec network, shuffling still has sufficient real-time quality for applications such as avionics Wilfried Steiner and Varadarajan (2009).

Time-Triggered Ethernet (TTEthernet)

TTEthernet is a new SAE Standard Aerospace (2011d) that provides time-triggered services for Ethernet in order to allow synchronous communication with constant latency, tight jitter (μ sec) and determinism properties. TTEthernet integrates three data flows: Time-Triggered (TT) data flow, which is the highest priority flow; Rate Constrained (RC) traffic, which is equivalent to AFDX traffic; and Best Effort (BE) traffic. This makes TTEthernet suitable for mixed-critical applications where highly critical functions work alongside less critical functions.

The origins of TTEthernet can be trace back to an collaborative academic project between Vienna University of Technology and TTTech Computertechnik AG TTT. The main objective of this project was to integrate time-triggered messages with event-triggered messages on a single physical Ethernet network.

Table des matières

INTRODUCTION
0.1 Problem Statement
0.2 Research Objective
0.3 Research Contributions
0.4 Publication
0.5 Thesis Organization
CHAPTER 1 BACKGROUND
1.1 Time-Triggered Architecture (TTA)
1.2 Time-Triggered Protocol (TTP)
1.2.1 Time-Triggered Transmission
1.2.2 Rate-Constrained Transmission
1.2.3 Data Flow integration
1.3 Time-Triggered Ethernet (TTEthernet)
1.4 Integrated Modular Avionic Architecture (IMA)
1.4.1 ARINC 653
1.4.2 ARINC664 part7, AFDX
1.5 Model-Driven Engineering Approach
1.6 The Architecture Analysis Design Language (AADL)
1.6.1 AADL Annexes
1.6.1.1 Behavioral Annex
1.6.1.2 ARINC 653 Annex
1.7 Verification and Simulation Techniques
1.7.1 Discrete Event System Specification (DEVS)
CHAPTER 2 RELATED WORK
2.1 TTEthernet-based platform
2.2 IMA Architecture
2.3 AADL
2.4 DEVS
CHAPTER 3 TIME-TRIGGERED ETHERNET METAMODEL
3.1 TTEthernet Model
3.2 A Metamodel for TTEthernet Domain
3.2.1 Schedulable Resources
3.2.2 Channel
3.2.3 Frames
3.2.4 Scheduler
3.2.5 The Metamodel of IMA
3.3 Conclusion
CHAPTER 4 AN EXTENSION FOR AADL TO MODEL MIXED-CRITICAL
AVIONIC SYSTEMS DEPLOYED ON IMA ARCHITECTURES
WITH TTETHERNET
4.1 Metamodel Extending AADL capability to model TTEthernet
4.2 Textual Syntax for the TTEthernet Extension for AADL
4.2.1 Integration of the AADL-TTEthernet Compiler to OSATE2
4.3 An Example: A Model of a Subsystem of the Flight Management System
4.4 Conclusion
CHAPTER 5 VERIFICATION APPROACH TO THE DESIGN OF DISTRIBUTED
IMA ARCHITECTURES USING TTETHERNET
5.1 Verification Approach
5.2 Simulation of the Navigation & Guidance System
5.2.1 System Description
5.2.2 Model Transformation
5.2.3 Property verification: Contention-Freedom
5.3 Conclusion
CHAPTER 6 CASE STUDY
6.1 System Description
6.2 Property verification: Contention-Freedom
CONCLUSION 

Cours gratuitTélécharger le document complet

 

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *