Comparison and temporal validation of automotive real-time architectures Karen Godary, Pierre Parrend, Isabelle Aug´e-Blum INSA Lyon / Lab CITI - 21 av. J. Capelle 69621 Villeurbanne, France
[email protected]
Abstract In the automotive domain, the X-by-wire systems are dedicated to critical and real-time applications. These systems have specific needs that must be fulfilled, in particular in the reliability domain. Fault-tolerant architectures have been designed to fit with these requirements : TTA, FlexRay or TTCAN. This paper presents a methodology of temporal validation, and illustrates it for the validation of TTA and TTCAN services. This validation provides some temporal bounds, that can be used for the comparison of these architectures.
keywords : automotive and real-time networks, temporal validation, reliability.
Introduction In the automotive domain, the current trend is to replace mechanical and hydraulic systems with electronic ones. These new systems are called X-by-wire systems where X is the implemented functionality. They are related to critical applications, such as steering or braking, i.e. applications for which a dysfunction can has catastrophic consequences. Reliability is
then an essential element for the implementation of such systems in the vehicles. The functionalities of these systems are distributed on different controllers communicating through a network. For the braking application for instance, the controllers are closed of each wheel, and communicate through a network to exchange their local braking informations. Therefore, these type of systems have specific properties resulting from their distributed and realtime nature. Moreover, their reliability requirement imply fault-tolerance, i.e. a correct behavior even in presence of faults. In this context, traditional automotive networks are not reliable enough to provide such a strong reliability. Indeed, detection of faults is necessary but not sufficient, and specific fault-tolerant mechanisms are needed. For instance, CAN (Controller Area Network) [ISO93] which is largely used in the automotive domain, do not provide enough faulttolerance. Therefore some new architectures have been designed, such as TTA (TimeTriggered Architecture) [Kop98], FlexRay [Fle04] and TTCAN (Time-Triggered CAN) [TF00]. These new architectures must guarantee the correct behavior of the system, even in presence of faults. This guarantee is verified using different validation techniques such as test, simulation and fault-injection. But the critical property of the X-by-wire systems requires also formal validation, to formally and exhaustively verify their reliability. This article concerns the temporal part of this validation, more precisely the validation of the temporal bounds (the maximum execution time) of the architecture services. For the moment, no one of these architectures is preferred in the automotive context. Many criteria have to be considered, and the proposed architectures have different characteristics. Therefore, a definitive choice of one of them can rely on a comparison between these architectures. In the context of critical and real-time systems, this comparison must take into account the temporal validation characteristics of the architectures.
2
This works presents in a first section a study of the temporal validation of two architectures : TTA and TTCAN. One common methodology has been applied to validate temporal bounds of the architectures services. These temporal bounds are in a second section analyzed to compare both architectures in the reliability domain.
1 Temporal validation of fault-tolerant architectures 1.1 Validation methodology The temporal validation of the architecture services has been done using a methodology initially developed for TTA, and described in [GAM04b]. This methodology is composed of two main steps : the conception of the model, and the validation itself. Property model
Abstract and verified architecture model
Fault model
Architecture model
Model checking
Simulation + Verification Caption :
verified architecture model
Models Actions
num
Numeric bounds : B S (depending on parameters)
Results
Abstractions + Verification Analysis
Verified and abstract architecture
Human analysis
Parameterized bound B S = ∆+π
Figure 1: The two steps of the validation methodology
Conception of the model The first step of the methodology (left of figure 1) consists in designing a model of the system. Therefore, it was first necessary to choose a validation technique and a modeling formalism. These choices have been done depending on the TTA characteristics [GAM04a, God04] : the tool is UPPAAL and the formalism are the TSA 3
(Timed Safety Automata) [BY04], an extension of the timed automata. Therefore a first model of the system can be designed, and has to be validated verifying behavioral properties extracted from the specifications, to check its correctness. This model must also be efficient, that is to say free of exponential explosion problem which originates of exhaustive analysis. The obtained model is then an abstract model, efficient for the validation process.
Validation The second step, on the right of the figure 1, is the validation itself. The validation is done verifying properties on the model of the system. In UPPAAL, the validation is done using a model checker which allows to exhaustively and formally validate a system. Then the UPPAAL tool allows, using a test automaton, to verify that a deadline value is never reached, which is a bound of the maximum execution time of a specific service. This bound is validated under fault hypotheses. The obtained bound is a numeric value, which depends of the system parameters, as for example the slot duration, so it is very specific to a particular architecture. Therefore, a new analysis process is applied to extract a parameterized bound of the service, studying the trace of the worst execution scenario of the service generated by UPPAAL. Analyzing this trace allows to extract a parameterized bound, only dependent on the architecture topology (as the number of nodes).
This methodology of validation was initially employed and devoted to the temporal validation of TTA. Its use is illustrated for an example in the following section 1.2, with the validation of the reintegration service. Then the application of the same methodology for the validation of another network was studied : the methodology has been applied to CAN 1 , and then to the TTCAN architecture [Par04] . The section 1.3 gives an example of the validation of one TTCAN service : the reinitialization of a node. 1
works done with Tahiry Razafindralambo
4
1.2 Validation of TTA 1.2.1
TTA : Time-Triggered Architecture
TTA ([Kop98]) is composed of a cluster, i.e. a set of nodes connected through a communication network based on TTP/C (Time Triggered Protocol class C) ([TTT03]). There is two possible topologies : bus and star. This study is based on the bus topology of TTA.
The TTP/C protocol The Time-Triggered Protocol is based on a static and predefined scheduling of the messages. It implements a broadcast communication using the TDMA (Time Division Multiple Access) strategy. Informations about transmitted data and emission dates are stored in a static table in each node. Each node is assigned a fixed duration for the transmission of its messages : a slot. The slots are grouped together in a TDMA round. The usual system phase is a cyclic execution of all TDMA rounds : the cluster cycle. A slot is composed of several phases, one phase (TP, Transmission Phase) for the effective transmission of the messages on the bus, and others for the execution of the protocol algorithms. The TDMA access implies a global view of the system. In one hand, there is a global view of the time of the system, and a synchronization of the local clocks of the nodes in this global time. This function is provided in TTP/C by a specific synchronization service [KHK 97], based on the comparison between the time of the real arrival of each message and the expected time given by the static scheduling. In the other hand, there must be a global view of the member of the cluster with their state, i.e. if they are active or not. This is assured with different services, mainly the membership service [BP00].
Fault tolerance TTA is designed to be fault-tolerant [KBP01], and then includes many dedicated mechanisms. First fault-tolerance is assured with hardware components, such as 5
a duplicated bus or bus guardians [Tem98], which are autonomous subsystems preventing the node to emit at the wrong time. The architecture also provides the management of software redundancy : a critical application task can be duplicated. Then critical messages can be duplicated in the space domain and in the temporal domain. Finally, several services of TTP/C are also dedicated to fault-tolerance, as fault detection services or services which allowed nodes to reintegrate the cluster (reintegration or reinitialization).
1.2.2
Example of the reintegration service
In the context of the validation of TTA, all the fault-tolerant services have to be validated. The methodology presented in section 1.1 is dedicated to this validation, verifying their temporal bounds. This section gives an illustration of the validation of the reintegration.
Reintegration The reintegration of a node can occur when one of the TTA basic algorithms detects a fault. The faulty node transits in passive state, and waits for reintegration, whereas non-faulty nodes continue a normal execution. Therefore, in the slot before its own sending slot, the faulty node checks whether it can transit to active state, i.e if it has received at least MIC (Minimum Integration Count, a parameter of the protocol) correct frames since it has failed. When this is fulfilled, the node can send its frame. The exact bound is validated between the beginning of the reintegration (i.e. the detection of the fault which causes the transition of the faulty node to passive state), and the end of the reintegration (i.e. its transition to active state).
Hypotheses Basic services : Some TTA mechanisms are supposed to be correct, as there have already been formally validated in the literature ([Pfe03], [Rus02], [BM02]) : member-
6
ship, clique avoidance, clock synchronization and bus guardian window algorithms. Architecture : The model includes a cluster of 4 nodes with bus guardians in a one bus topology. No redundancy is considered. The TDMA schedule is then composed of 4 slots in a round, and a cluster cycle is composed of two rounds. Fault hypotheses : The faults modeled here are the ones of TTA [TTT03], which specify a frequency of one fault at a time and one fault for two rounds. Therefore the only fault modeled here is the one which initiates the reintegration process.
Temporal bound validation The detailed models, nor the numeric values of the validation process, are not given here. This parts just gives an illustration of the analysis of the worst case scenario (given figure 2 for the faulty node 2) : A fault is detected after the TP phase of the slot 4; the faulty node transits then in passive state, and tries to reintegrate; it then initializes its reintegration counter; When the faulty node receives a correct frame, it increments its reintegration counter; Just before its sending slot (at the end of the slot 1), the faulty node verifies its reintegration condition, i.e. if it has received more than MIC correct frames. In this worst case scenario, this condition is not yet verified, the faulty node therefore remains in passive state and the slot 2 will be empty. Then the faulty node has to wait one round more to check again its reintegration property. Before its next sending slot, it can reintegrates the cluster and sends. The analysis of this scenario allows to extract a parameterized bound of the reintegration :
"!$# &% '( *) ,+ .7
reintegration bound : D Reint
π
MIC* ∆ slot
2
∆TP slot2 slot3 TP
fault arrival (node 2)
slot1
slot4
slot2 slot3 slot4
TP
fault detection => Passive
n=0
2 slot1
slot2
TP
reception ok
reintegration counter
π
∆ round
empty
receptions ok n>MIC => Active
n stays in Passive n=1 n=2 n=3
n=1
n=4
Figure 2: Worst reintegration scenario for node 2 This bound is independent of the parameters such as the scheduling values (as the duration of the round), but remains dependent of the architecture structure because the analysis has been done for 4 nodes. The same temporal validation methodology allowed to validate different bounds of the TTP/C services. These bounds have been validated with different fault hypotheses. For more details, please refer to [God04, GAM04c].
1.3 Validation of TTCAN 1.3.1
TTCAN : the Time-Triggered Controller Area Network
TTCAN (Time-Triggered Controller Area Network) [TF00] is based on the CAN protocol [ISO]. It proposes a natural time-triggered extension of CAN : it proposes an additional scheduling layer implemented on a CAN controller.
Principles of the protocol The TTCAN messages transmission is based on a TDMA fixed scheduling defined in an emission matrix made of several basic cycles, as shown in figure 3. A basic cycle can contain two types of windows : the reserved windows, for the transmission of specific messages from specific nodes, and the arbitrating windows, for event-triggered 8
messages such as alarms, or retransmission of faulty messages. Each window in the basic cycle may be either reserved or arbitrating, depending on the scheduling. Each basic cycle begins with the emission of a reference message. The node which emits the reference message is known as the time master, and there are several nodes which may be potential time masters. Two levels of synchronization are available, according to the precision which is necessary in the system. Level 1 merely consists for each node in employing the local time of the controller. Level 2 enables synchronization with the time master through transmission of its local time in the reference message, and compensation of clock drift. Reference Message basic cycle :
Data Message
∆ round
reserved window :
∆ slot
basic cycle : optional undetermined gap time
∆ round arbitrating window
Figure 3: Example of a TTCAN scheduling
In TTCAN, the fault-tolerance is implemented using the CAN error detection mechanisms and new specifics services, as for example the time master management. If no fault occurs, the time-triggered extension of CAN ensures determinism and hard real-time capabilities, that is to say guaranty of delivery before a given deadline. This is true apart from gap case : a gap is a suspension of emission before the beginning of a basic cycle. The introduction of a gap brings flexibility in the system, but do not ensures bounded arrival time, as its end is often indicated by an external signal.
1.3.2
Example of the reinitialization service
The reinitialization in TTCAN corresponds to the reintegration situation in TTA.
9
Reinitialization service Reinitialization takes place in case of serious errors, called S3 errors, as for instance if the application alive signal is not updated. This S3 signal is emitted in the faulty node, and forces it to transit to the configuration mode. After a configuration duration, the node resynchronizes with the other nodes : it listens to the bus until it receives two valid reference messages. As soon as this synchronization is performed, the node is able to send data messages, and reinitialization is over.
Hypotheses The hypotheses considered here are the same as the ones of TTA (section 1.2.2) for the architecture and the fault hypotheses. We consider an equivalent scheduling as the one used in TTA validation, and no gap is considered, to cope with the behavior of TTA. Between two data messages, enough time is left to send a CAN error frame if necessary. Such a strategy, proposed in [GL01], allows the detection of faults without collision and loss of the scheduling. Moreover, as the considered fault hypotheses are one fault every two basic cycles, we use an arbitrating window with the same period replacing the last reserved window of the basic cycle to retransmit the faulty message when necessary and to achieve guarantee of delivery.
Temporal bound validation The bound of reinitialization is taken between the reinitialization signal and the time point where the faulty node is synchronized again, and thus capable of sending messages, that is to say at the end of second received Reference Message. The worst scenario of the reinitialization behavior is given figure 4 : A reinitialization signal is emitted in one node, which corresponds to the S3 error detection in the TTCAN norm. It represents the beginning of the reinitialization. The faulty node enters in the configuration mode, and stays in this mode during an interval
. 10
A reference message begins to be emitted just before the node finish configurating. This message is then not taken into account by the faulty node. The next reference message is emitted at the beginning of the next basic cycle. The faulty node receives it and waits for a second one. A second reference message is emitted one basic cycle later, but is erroneous, and is to be reemitted immediately afterwards. This third reference message allows the faulty node to finish its synchronization. The reinitialization is over at the end of this message.
reinitialization bound
∆ conf
begin of reinitialization
∆ RefMsg + ∆ Err
ε
∆ round
∆ round
∆ RefMsg end of reinitialization
second received reference message first received reference message not received by reference message the faulty node erroneous reference message and error frame
Figure 4: Worst reinitialization scenario (with one error)
The analysis of this worst case scenario allows to extract the following temporal bound of the reinitialization service :
# # % )
This bound is independent of some protocol parameters, as the duration of the reference message emission. But it is dependent of some specific options in the scheduling of TTCAN, as for example the duration of the arbitrating window in the basic cycles.
11
As for TTA, our validation methodology has been used to validate the TTCAN services with different fault hypotheses : see [Par04] for more details.
2 Comparison between the two architectures 2.1 Comparison : state of the art TTCAN is a recent architecture. Some comparisons exist between CAN and TTCAN [TB04, AG03], but not to our knowledge with others architectures dedicated to the X-bywire systems. A criteria easy to compare is the raw value of performances [AG] : TTP/C can support more than 25Mbit/s (depending on the used physical layer) with maximum frame length up to 240 Bytes. Moreover, TTP/C protocol does not add a big overhead, providing a high data efficiency transmission; whereas TTCAN is based on CAN, i.e. in a CSMA/CA access technology, which limit its transmission speed to 1Mbit/s and its frame length to 8 Bytes. Another point of view is the cost of the system : TTP/C is known to be very expensive, in particular for the bus topology version. Indeed, TTA has many integrated additional mechanisms and components dedicated to the fault tolerance. The development of the star topology reduce this disadvantage, but TTA remains more expensive than TTCAN. Moreover, TTCAN is based on CAN controllers, which are already used for a long time in automotive industry and therefore already have optimized and cheap implemented chips. Another frequent argued subject is the flexibility potential of the architecture. The strict time-triggered scheduling in TTA can be considered as a drawback for some applications which not fit well with a deterministic behavior. Whereas TTCAN provides the possibility to add some specific windows, managed with the CAN protocol and dedicated to the eventtriggered traffic. But the addition of such a window is often synonym to less reliability 12
(no fault tolerance of this traffic for example). This problem is a current discussion in the automotive industry, where the rigidity of the time-triggered technology is viewed as a drawback, but where the reliability is essential in the X-by-wire context. This provides another essential criterion to compare the architectures : the reliability domain. In one hand the architectures have to be fault tolerant, with specific mechanisms dedicated for that. In this domain, TTA is more complete, providing several possibilities that are not possible in TTCAN. One important difference for instance is the bus guardian. This component is dedicated to protect the bus from frame emission at the wrong time. This prevent in particular from the babbling idiot failure, i.e. a node which emits randomly, which is an important problem of the CAN networks (and then TTCAN). Moreover, TTA allows management of application redundancy, which is a powerful tool for fault tolerance. TTCAN provides configurable mechanisms to allow only basic fault-tolerance. In other hand, fault-tolerant mechanisms have to be validated to ensure the reliability of the architecture. In the context of critical real-time systems, the comparison of two architectures must rely on the results of their validation, particularly their temporal validation. The next section presents a comparison between TTA and TTCAN based on the temporal validation of both architectures. Temporal bounds of equivalent services on both architectures, as the ones presented in section 1.2.2 and 1.3.2, are compared and analyzed.
2.2 Comparison of the architecture behaviors 2.2.1
Treatment of a host error
A first comparison between TTA and TTCAN can be done comparing two closed services : reintegration in TTA, and reinitialization in TTCAN. These services both allow a node to reintegrate a cluster after the detection of a fault, for instance a host error (the host level
13
has a problem, for instance is not alive or is not synchronized any more). The temporal bounds of these two services have been validated in the previous sections 1.2.2 and 1.3.2. If one considers the absolute value of these bounds, the architecture TTA is faster than TTCAN for a node reintegration in the worst case. But a bound has no signification without interpreting it. The interesting behavior of an architecture is expressed in terms of lost or delayed messages. Therefore, these bounds have to be analyzed more precisely.
In TTA,
a faulty node transiting in passive state remains synchronized with the rest of the
cluster. It still receives transmitted messages. Referring to figure 2, the worst behavior of reintegration corresponds to one lost message : in the round following the fault detection, the faulty node can not reintegrate and remains in passive state, leaving its slot empty.
In TTCAN,
the worst behavior of reinitialization (figure 4) has different consequences.
First a faulty node is not considered synchronized any more. Even it is not specified in the specification, it is possible that all the messages received during the reinitialization are not taken in consideration, and then are lost for the faulty node. Second, the reinitialization in TTCAN lasts about two rounds, which involves two messages which are not emitted. Therefore, the comparison of the temporal bounds of the services allows the comparison of the architectures behaviors. For instance the previous analysis shows that the TTA architecture implies less losses than TTCAN after the occurrence of a host error.
2.2.2
Treatment of an emission fault
Then the two services (reintegration in TTA and reinitialization in TTCAN) have been compared with their temporal bounds. However, these services are not always used exactly in the same situation. Reintegration in TTA is more often initiated than reinitialization in
14
TTCAN. For instance, an emission fault causes in TTA the reintegration of the faulty node after this node has detected a membership error. In TTCAN, this fault do not lead to the reinitialization of the faulty node, and the lost message can be reemitted. The behavior of the two architectures after the occurrence of an emission fault is studying in the following.
In TTA,
an emission fault causes a membership loss error, which corresponds to a node
which is not acknowledged. The detection of this fault initiates the reintegration of the faulty node. The composed bound of these two services, the membership loss detection and the reintegration, is the following (see [God04]) :
%% ' "!
# % ' ,.-
This bound shows that the worst behavior of TTA in the case of an emission fault corresponds to two losses of messages, the erroneous one and another one. TTA
detection + reintegration bound : D EmissionFault
π 2
2* ∆ slot slot2
emission fault
slot3
∆ round
MIC* ∆ slot slot4
slot1
fault detection => Passive
π
slot2
slot3
=> stays in Passive
slot4
2
slot1
slot2
reintegration => Active
Figure 5: Worst scenario for the treatment of an emission fault in TTA
In TTCAN,
an emission fault is detected in the same principles as the CAN protocol, i.e.
immediately : a node which received an erroneous frame sends a specific error frame to prevent all the nodes there is a problem. The sending node then waits a specific phase, the arbitrating window, in which it can re-send its message. Depending on the frequency of this arbitrating window and the fault hypotheses, an emission error can then just lead to a delay
15
in the emission, without losing a message. This second analysis allows to compare the behavior of the two architectures after the occurrence of an emission fault. It shows that in this situation, TTA in the worst case leads to two losses of messages, whereas TTCAN just introduces a delay without loss if it is well configured. Indeed, some parameters of this architecture must be established depending on the fault hypotheses. In the case of an emission fault for instance, the erroneous message could be reemitted if the arbitrating window is long enough for all the messages which have to be reemitted. In the context of our fault hypotheses, i.e. only one fault for two rounds, only one message can be erroneous. It is therefore sufficient to have an arbitrating window with a duration equal to the transmission of only one message.
2.2.3
Comparison : Conclusion
The two previous analysis shows that the results of the comparison are dependent of the structure of the architectures. In one hand for example, the reliability of TTCAN depends on the duration and the frequency of the arbitrating windows. In other hand, TTA has powerful optional fault-tolerant services, as the application redundancy for instance. Therefore the comparison can not be done in a generic way, but concerned two specific implementation of the protocols. The temporal bounds of the architecture services can then be used to compare the behavior of these two implementations. The bounds can be translated in message losses or transmission delays, which are informations that can be used for the evaluation of the quality of service (QoS) of a fault-tolerant architecture. For example, different implementations can be compares to see if they are reliable enough depending on specific application requirements, or specific fault-hypotheses.
16
Conclusion This paper presents in a first part a temporal validation methodology for critical real-time systems. This methodology was illustrated for the validation of the services of two automotive networks : TTA and TTCAN. The two studied services are the reintegration in TTA and the reinitialization in TTCAN. The methodology allows to validate and extract parameterized bounds of the maximum execution time of these services. It is composed of two parts : first the conception of a model of the system, using the TSA as a modeling formalism, and second the validation itself, using the UPPAAL tool model checker to verify some properties on the model. This step allows to validate numeric bounds, from which parameterized bounds can be extracted analyzing the worst case scenario. The second part of this paper deals with the architectures comparison. The comparison can not be done in a generic way : the behaviors of both architectures are compared for the same situation, for example the management of the same error. The services temporal bounds are used to interpret the architecture behaviors in terms of messages losses and transmission delay. Such a comparison can give elements on the fault tolerance capability of the studied systems. These results depend on the chosen implementation of the architectures, as for instance the redundancy degree in TTA or the duration of the event-triggered windows in TTCAN. The comparison method presented in this paper can be a solution to help for the choice of one architecture for the X-by-wire systems. The results can be useful in a more global method of reliability and QoS evaluation. Moreover, works must be extended to other faulttolerant architectures, especially to FlexRay which is the principal opponent to TTA in the automotive domain. This method can give elements to resolve the well-known problem “reliability vs flexibility”, allowing to analyze both the architectures behaviors. 17
References [AG]
TTTech Computertechnick AG. Comparison of protocols. www.tttech.com.
[AG03]
A. Alberts and W. Gerth. Evaluation and comparison of the real-time performance of can and ttcan. In 9th international CAN Conference, iCC 2003, M¨unchen, 14.-16.10.2003, S. 05/1-05/8, 2003.
[BM02]
A. Bouajjani and A. Merceron. Parametric verification of a group membership algorithm. In 7th Int. Symp. on Formal Techniques in Real-Time and Fault Tolerant Systems, volume LNCS 2469, pages 311–330, Oldenburg (Germany), September 2002.
[BP00]
G¨unther Bauer and Michael Paulitsch. An investigation of membership and clique avoidance in TTP/C. In 19th IEEE Symposium on Reliable Distributed Systems, N¨urnberg, Germany, October 2000.
[BY04]
Johan Bengtsson and Wang Yi. Timed automata: Semantics, algorithms and tools. In W. Reisig and G. Rozenberg, editors, Lecture Notes on Concurrency and Petri Nets, LNCS vol 3098. Springer–Verlag, 2004.
[Fle04]
FlexRay consortium. FlexRay Communications System - Protocol Specification - Version 2.0, June 2004. http://www.flexray-group.com.
[GAM04a] K. Godary, I. Aug´e Blum, and A. Mignotte. SDL and timed petri nets versus UPPAAL for the validation of embedded architecture in automotive. In Forum on specification & Design Language (FDL’04), Lille, France, September 2004.
18
[GAM04b] K. Godary, I. Aug´e Blum, and A. Mignotte. Temporal bounds for TTA : Validation. In IFIP Working Conference on Distributed and Parallel Embedded Systems, Toulouse, France, August 2004. [GAM04c] K. Godary, I. Aug´e Blum, and A. Mignotte. Validation temporelle des services TTA. Technical Report RR2004-4, Lab. CITI, INSA Lyon, 2004. Confidentiel. [GL01]
D. Heffernan G. Leen. TTCAN : a new time-triggered controller area network. Elsevier Science B.V., December 2001.
[God04]
Karen Godary. Validation Temporelle d’une Architecture Embarqu´ee pour l’Automobile. PhD thesis, INSA Lyon, Novembre 2004.
[ISO]
Iso 11898-1: CAN transfer layer, iso 11898-2: Can high speed physical layer, iso/prf 11898-3: Can fault tolerant physical layer. ISO Norm.
[ISO93]
International Standards Organisation. ISO 11898. Road Vehicles—Interchange of digital information—Controller area network (CAN) for high speed communication, 1993.
[KBP01]
Hermann Kopetz, G¨unther Bauer, and Stefan Poledna. Tolerating arbitrary node failures in the time-triggered architecture. In Society of Automotive Engineers World Congress, Detroit, MI, USA, March 2001.
[KHK 97] Hermann Kopetz, Ren´e Hexel, Andreas Kr¨uger, Dietmar Millinger, and Anton Schedl. A synchronization strategy for a TTP/C controller. In SAE Congress and Exhibition, Detroit, MI, USA, February 1997. SAE Paper No. 960120.
19
[Kop98]
Hermann Kopetz. The time-triggered architecture. Proc. of the First International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC ’98), April 1998. Kyoto, Japan.
[Par04]
P. Parrend.
Validation temporelle d’architectures embarqu´ees pour
l’automobile. Technical Report RR2004-, Lab CITI, INSA Lyon, juillet 2004. [Pfe03]
Holger Pfeifer. Formal Analysis of Fault-Tolerant Algorithms in the TimeTriggered Architecture. PhD thesis, Universit¨at Ulm, Germany, 2003.
[Rus02]
J. Rushby. An overview of formal verification for the time-triggered architecture. In Werner Damm and Ernst-R¨udiger Olderog, editors, Formal Techniques in Real-Time and Fault-Tolerant Systems, volume 2469 of LNCS, pages 83– 105, Oldenburg, Germany, 2002. Springer-Verlag.
[TB04]
JC Tournier and JP Babau. Communication protocol evaluation for embedded systems. In IEEE International Conference on Industrial Technology, ICIT’04, December 2004.
[Tem98]
Christopher Temple. Avoiding the babbling-idiot failure in a time-triggered communication system. In 28th International Symposium on FTCS, Mu¨ nchen, Germany, June 1998.
[TF00]
W. Dieterle F. Hartwich R. Hugel M. Walther T. Fu¨ hrer, B. M¨uller. Time triggered communication on CAN. In 7th International CAN Conference, 2000.
[TTT03]
TTTech Computertechnik AG, Time-Triggered Technology, Vienna, Austria. Time-Triggered Protocol TTP/C, High-Level Specification Document - edition 1.4.3, November 2003. http://www.ttech.com.
20
