Rapport de PFE Validation temporelle d architectures embarquées pour l automobile

Rapport de PFE Validation temporelle d architectures embarquées pour l automobile Pierre Parrend INSA Lyon Encadrant : Isabelle Augé-Blum CITI Juin 2004

Résumé Cette étude se situe dans un contexte de fort développement des applications automobiles basées sur l électronique, en vue de remplacer certaines pièces mécaniques, tels les systèmes de freinage, de direction. Le protocole le plus utilisé actuellement est CAN, mais il ne suffit pas aux applications nécessitant un haut degré de sécurité. D autres protocoles ont donc été développés, selon le paradigme Time- Triggered (selon un ordonnancement pré-défini), comme TTA, Flexray. En effet, ce type de protocoles est plus facile à valider. De la rencontre de CAN et des protocoles Time-Triggered est issu TTCAN. C est ce protocole auquel nous allons nous intéresser. Il est indispensable pour un protocole destiné à des applications à haut niveau de sécurité de disposer d un validation formelle. Nous allons étudier son comportement temporel à l aide de l outil UPPAAL, qui permet l analyse, à l aide d une méthode développée au CITI. Nous présentons la modélisation réalisée à fin d analyse, ainsi que les résultats obtenus. Ces données nous permettent une comparaison systématique avec le protocole TTA, ce qui offre une mise en perspective critique des deux protocoles.

i Table des matières 1 Introduction 1 2 Contexte de l étude 2 2.1 Monde CAN............................. 2 2.1.1 CAN............................ 2 2.1.2 Autres Protocoles...................... 2 2.2 Protocole TTCAN.......................... 3 2.2.1 Matrice d émission..................... 3 2.2.2 Synchronisation d horloge................. 5 2.3 Validation temporelle........................ 7 2.3.1 Validation existante..................... 7 2.3.2 UPPAAL.......................... 7 2.3.3 Méthode employée..................... 7 3 Modélisation 9 3.1 Eléments de TTCAN........................ 9 3.2 Hypothèses............................. 10 3.3 Schéma d émission......................... 10 3.4 Modèle de TTCAN......................... 11 3.4.1 TSO (Time Schedule Organiser).............. 11 3.4.2 MSA (Master State Administrator)............. 13 3.4.3 CTC (Cycle Time Controller)............... 16 3.5 Observateurs............................ 18 3.6 Scénarios.............................. 18 4 Obtention des bornes 19 4.1 Exemple d une borne sans erreur.................. 20 4.2 Exemple d une borne avec erreur.................. 21 4.3 Autres bornes............................ 22 5 Comparaison avec TTA 23 5.1 Particularités de TTCAN...................... 23 5.2 Services communs......................... 23 5.2.1 Synchronisation...................... 23 5.2.2 Initialisation........................ 24 5.2.3 Réinitialisation....................... 25 5.2.4 Réintégration........................ 26 5.2.5 Accusé de réception.................... 27 5.2.6 Communication Blackout Check.............. 27 5.3 Bornes spécifiques......................... 28 5.3.1 TTCAN........................... 28 5.3.2 TTA............................. 28

ii 5.4 Récapitulatif............................. 29 6 Conclusion 30 Bibiographie 31 Annexes 32 A Les automates du modèle 32 A.1 Cycle Time Controller (CTC).................... 32 A.2 Time Schedule Organiser (TSO).................. 33 A.3 Master State Administrator (MSA)................. 37 B Les bornes de TTCAN 40 B.1 Synchronisation........................... 40 B.2 Initialisation............................. 40 B.3 Réinitialisation........................... 41 B.4 Initialisation/Réinitialisation d un Time Master.......... 41 B.5 Emission.............................. 42 B.6 Variation de la durée d un cycle.................. 42 B.7 Reprise d erreur S2......................... 43

1 1 Introduction Les équipementiers automobiles tendent à remplacer un grand nombre de pièces mécaniques par des circuits électroniques, qui doivent être plus fiables, plus souples, et surtout moins onéreux. Actuellement, les applications concernées sont des applications de confort, mais un grand nombre de recherches sont effectuées dans le but de remplacer les systèmes de transmission, de direction, de freinage, par l électronique : ce sont les applications embarquées dites X-by-Wire, basées sur des réseaux. Elles nécessitent une garantie forte en terme de sécurité. Le schéma 1 montre le schéma de principe d une application distribuée, avec transmission des données sur bus. FIG. 1 Schéma de principe d une application distribuée Le standard actuel mis en œuvre dans les systèmes embarqués pour l automobile est CAN (Controller Area Network). Plusieurs couches applicatives ont été développées, pour des environnements spécifiques (industrie, véhicules, etc...). L une des dernières évolutions de CAN est l introduction d une couche Session qui permet la communication time-triggered, et doit résoudre les problèmes de validation de CAN : TTCAN (Time-Triggered Controller Area Network). TTCAN permet d assurer un fonctionnement en temps réel dur, c est à dire avec garantie d arrivée des messages avant leur expiration. Il est indispensable de valider le comportement temporel de TTCAN, pour vérifier l effectivité de cette garantie d arrivée des messages. Ceci est réalisé à l aide de UPPAAL, selon une méthode déjà employée pour d autres travaux. Après l étude du comportement de TTCAN, la comparaison avec un autre protocole de réseau de terrain, en l occurence TTA, permet d évaluer les avantages et les inconvénients de chacun, et de mettre en perspective d éventuelles lacunes.

2 2 Contexte de l étude Cette étude vise à améliorer la connaissance d une des dernières évolutions de CAN, TTCAN, en s interrogeant sur la pertinence de son utilisation dans des applications nécessitant une grande sécurité. L interêt de TTCAN repose sur l importance de l utilisation de CAN et des nombreuses couches applicatives qui y sont associées, que nous détaillerons. Nous présenterons ensuite TTCAN, dont la transmission Time-Triggered est basée sur une matrice d émission définie lors de la conception du système. La synchronisation des différents noeuds est réalisée par rapport à un temps global. Afin de pouvoir utiliser TTCAN dans l industrie et dans l automobile, il est indispensable de valider ses propriétés temporelles. Ceci est réalisé avec le logiciel UPPAAL, selon la méthode présentée dans [GAM04]. 2.1 Monde CAN 2.1.1 CAN CAN [ISO93] est un protocole de communication pour bus de terrain, très utilisé dans l automobile et l industrie. Le protocole connait une forte utilisation depuis 10 ans. Ses implémentations sont donc peu chères. Son inconvénient est la complexité de la validation, due au mécanisme CSMA. C est un protocole event-triggered (guidé par les événements), c est à dire que les moments d émission des messages ne sont pas prédéfinis. Lors de l émission, les messages envoyés sont départagés par le mécanisme CSMA/CA (Carrier Sense multiple access / Collision avoidance) : lorsqu une station a un message à émettre, et que le bus est libre, elle émet. En cas de collision, le message le plus prioritaire passe sur le bus, les autres sont rejetés, et réémis ultérieurement. En effet, CSMA/CA permet des collisions non destructrices : le message le plus prioritaire est transmis. Tous les émetteurs comparent le message transmis au message qu ils ont émis. Si ces deux messages sont différents, c est que la transmission a échouée, le message devra être retransmis. 2.1.2 Autres Protocoles Les autres protocoles basés sur CAN sont TTCAN et FTTCAN. TTCAN est un protocole Time-Triggered, qui supporte l émission de messages event-triggered. FTTCAN permet en plus un ordonnancement dynamique, en offrant la possibilité de modifier les noeuds émetteurs à chaque cycle de base. Pour utiliser au mieux les possibilités de CAN, un certain nombre de couches applicatives ont été développées. Au delà des couches génériques (CAL - CAN Application Layer, puis CANOpen, qui permettent l accès aux ressources du réseaux sous formes d objets logiciels, ainsi que l émission de grands paquets de données), plusieurs couches sont dédiées à des environnements spécifiques :

3 SDS (Smart Distributed System), réseaux industriels, permet d accéder aux fonctions des éléments du système par une couche de contrôle, DeviceNet, réseaux industriels, qui permet d accéder aux données et services du système, notamment les capteurs et actionneurs ; SDS supporte la présence de sous-réseaux par une couche de routage, J1939, ISO 11992, véhicules routiers, supporte les sous-réseaux, dispose d une couche de transport pour permettre l émission de paquets de grande taille sur CAN (segmentation), ISOBUS, engins agricoles, composé d un bus tracteur et d un bus sur lequel se trouvent les instruments, avec une couche de transport pour segmenter les paquets et une couche applicative avec interface utilisateur, NMEA2000, engins sous-marins, contient une couche de transport et une couche applicative. CANKingdom est un outil de configuration des modules du système, qui permet la gestion de bus CAN, TTCAN, etc. 2.2 Protocole TTCAN TTCAN est conçu pour être exploité dans les réseaux de terrain, notamment dans les applications X-by-Wire, pour lesquelles il se trouve en concurence avec TTA et Flexray. TTCAN est une extension du protocole CAN, qui permet la transmission de messages selon un ordre prédéfini (communication Time-Triggered). Ceci permet d assurer un fonctionnement en temps réel dur, c est à dire avec garantie d arrivée des messages avant expiration, hors utilisation de Gap (concept qui permet la suspension de la communication Time-Triggered). Le Gap apporte de la flexibilité dans la transmission de données. Par contre, il ne permet pas d assurer l arrivée des messages de données en un temps déterminé, dans la mesure où leur fin est souvent marquée par un signal applicatif extérieur à TTCAN. La norme [DRAFT03] définit la couche Session d ordonnancement (scheduling), implémentée par le FSE (Frame Synchronisation Entity), qui gère la synchronisation au niveau du contrôleur TTCAN. La figure 2 nous montre la pile protocolaire de TTCAN. Le protocole FTTCAN définit une extension de TTCAN, en y introduisant la possibilité de modifier à chaque cycle de base les noeuds émetteurs. Une plus grande flexibilité est également prévue pour la transmission des messages asynchrones. 2.2.1 Matrice d émission L ordonnancement est stocké dans une matrice qui définit les instants d émission des messages. Une matrice contient plusieurs cycles de base (voir figure 3).

4 FIG. 2 Pile protocolaire de TTCAN Chaque cycle contient : des fenêtres réservées, pour un type de message donné émis par un noeud donné, des fenêtres à arbitrage, où tous les noeuds peuvent tenter d émettre. La résolution de colision se fait selon les mécanismes de CAN (CSME/CA). Ceci permet la transmission de messages exceptionnels (alarmes, etc.), ou la réémission de messages erronés. La présence de multiples cycles de base dans cette matrice permet de fonctionner avec plusieurs séquences différentes de messages. Ces séquences doivent être définies avant le lancement de l application. Le mécanisme Time-Triggered permet de confiner chaque message dans sa fenêtre d émission. Par conséquent, une erreur dans une fenêtre n a pas d influence sur les autres fenêtres. Le débit du bus n est donc pas affecté par les erreurs, on peut utiliser plus pleinement sa bande passante. Le début de chaque cycle de base est marqué par l émission du bit Start Of Frame du Message de Référence, puis de ce message de référence, par le noeud maitre (Time Master). Un noeud, appelé maître, gère le séquencement des cycles de base. Chaque cycle de base commence par l émission d un Message de Référence. Le Time Master est choisi parmis les huit (au plus) Time Master potentiels qui peuvent exister sur le bus. A chacun est associé une priorité, et celui dont la priorité est la plus forte émet le Message de Référence. Il est possible de suspendre l émission de messages entre deux cycles de base, par la présence d un Gap. Ceci permet une plus grande souplesse qu avec d autres protocoles à émission Time-Triggered, comme TTP [KG94]. Un autre facteur de souplesse est la présence de fenêtres à arbitrage, qui peuvent être jointes si elles sont consecutives.

5 FIG. 3 Matrice d émission de TTCAN L implémentation de TTCAN est réalisée par l ajout d un module de synchronisation de trames au contrôleur CAN tel qu il est défini dans la norme 11898-1. 2.2.2 Synchronisation d horloge La synchronisation des horloges des noeuds est indispensable afin de garantir une vision cohérente de l écoulement du temps dans les différents noeuds, et donc une grande précision quant au début des colonnes d émission. Il existe deux modes de synchronisation d horloge : le niveau 1 et le niveau 2. La différence entre les deux est une différence de précision. Le niveau 1 fait une synchronisation en fonction du moment d arrivée des messages de référence, alors que le niveau 2 permet une synchronisation de tous les noeuds avec le temps du Time Master, et donc une plus grande précision et une meilleure utilisation du bus. Des noeuds fonctionnant sur le niveau 1 peuvent co-exiter avec des noeuds de niveaux 2, car il y a compatibilité mais, dans ce cas, on, on perd le bénéfice de la précision du niveau 2. Le niveau 1 Chaque station repère l instant d arrivée du message de référence, et utilise cet instant comme début du cycle. La variable Cycle_T ime indique la valeur du temps pendant un cycle de base. Cycle_T ime est calculé comme suit :

6 Cycle_T ime = localtime Ref_Mark (1) avec : Cycle_T ime : temps écoulé depuis le début du cycle localtime : temps local Ref_Mark : après réception complète du Message de Référence, Ref_Mark prend la valeur de Sync_Mark. Sync_Mark : La valeur de Sync_Mark prend la valeur de localtime à chaque Synchronisation Pulse, c est à dire au premier bit de chaque trame de données transmise sur le bus. S il s agit d un Message de Référence correctement émis, Sync_Mark est validé est devient la valeur de Ref_Mark. En synchronisation de niveau 1, les fenêtres sont plus grandes au fur et a mesure que l indice de la colonne croît dans le Cycle de Base, afin de compenser les effets du glissement d horloge. Elles doivent bien entendu être définies statiquement pour prendre ce phénomène en compte. Le niveau 2 Le niveau 2 utilise le temps du Time Master, ou temps global (Global_T ime), en prenant en compte l offset (différence entre le temps global et le temps local au moment de l arrivée du Message de Référence), et le glissement de l horloge locale par rapport à l horloge globale (T UR, Time Unit Ratio). [DRAFT03]. Les noeuds ont un compteur interne, qui leur permet de compter les NTU (Network Time Unit), qui fournissent le localtime. Le Global_T ime est le localtime du Time Master, transmis aux noeuds dans le Message de Référence. Les variables sont calculées comme suit : avec : Global_time : temps global pour le bus Global_T ime = localtime + offset (2) offset = Ref_Mark Master_Ref_Mark (3) pour chaque cycle, avec : Master_Ref_Mark : valeur de local time dans le Time Master à l émission du bit SOF du Message de Référence ( frame Synchronisation ). T UR = p_sys q_gt q_gt = Master_Ref_Mark(n) Master_Ref_Mark(n 1) (5) p_sys = Ref_Mark(n) Ref_Mark(n 1) (6) n et n-1 désignent le cycle en cours et le cycle précédent. (4)

7 2.3 Validation temporelle 2.3.1 Validation existante Peu de travaux ont été réalisés sur la validation de TTCAN. On a notamment la comparaison avec CAN [TB03], en ce que concerne le débit, le délai de transmission des informations, et le délai de détection d erreur. Un important travail de validation a été également effectué par [LH02]. Il s agit de la validation du comportement de TTCAN. Il est ainsi possible d affirmer que TTCAN est un protocole valide, et ne contient pas d erreurs. 2.3.2 UPPAAL Principes UPPAAL [PL00] est un outil de modélisation, simulation et vérification de systèmes temps réels. Il est basé sur la théorie des automates temporisés étendus par des variables et communication par canaux, et est composé de trois parties : un langage de modélisation, un simulateur, et un vérificateur de modèle. Langage de modélisation C est un langage non déterministe à gardes. Déterministe parce qu il permet de modéliser un choix aléatoire entre plusieurs transitions ; à garde parce que les transitions sont régulées par la valeur relative des horloges par rapport à des valeurs caractéristiques de chaque état, appelées gardes. Simulateur Le simulateur permet de visualiser le comportement du système. Vérification UPPAAL est conçu pour vérifier les propriétés d invariance et d atteignabilité des états, en explorant systématiquement l espace d états des automates du modèle. Une trace de diagnotic est générée, qui indique la cause du succès ou de l échec de la vérification effectuée. 2.3.3 Méthode employée La méthode employée pour l extraction des bornes de TTCAN est celle présentée par [GAM04]. Elle comporte deux étapes principales, représentées sur la figure 4 : l obtention du modèle du protocole à étudier, l extraction des bornes. Obtention du modèle Il s agit de réaliser un modèle, qui simule le comportement de TTCAN. Ensuite, on réalise la vérification du modèle, par la simulation d une part, par la validation formelle de ses propriétés d autre part. On vérifie l absence de blocage, la compatibilité des valeurs des variables utilisées, l atteignabilité ou non des états

8 FIG. 4 Méthodologie d extraction des bornes des automates, la compatibilité des états des différents automates, à l aide de UP- PAAL. Il est possible ensuite, si les performances du modèle ne sont pas satisfaisantes, d optimiser celui-ci par l abstraction. On peut s inspirer pour celà de [GAM], qui propose la réduction du nombre de noeuds, d arcs, d horloges, d automates, de chemins multiples. Nous disposons alors d un modèle vérifié et abstrait. Extraction des bornes Une fois le modèle disponible, il est nécessaire de créer les scénarios de fautes, qui correspondent au pire cas pour la borne considérée. Chaque scénario permet d obtenir une borne. Un observateur permet de valider la borne en effectuant une transition interdite si la borne n est pas vérifiée. C est un automate particulier qui prend une transition interdite si la propriété que l on souhaite validée n est pas vérifiée. Chaque scénario est réalisé avec plusieurs jeux de paramètres, ce qui permet d obtenir par analyse une formule paramétrée, qui est l expression de la borne temporelle.

9 3 Modélisation TTCAN est un protocole destiné à supporter des applications distribuées industrielle et automobiles. Chaque noeud est composé d un contrôleur TTCAN, c està-dire un contrôleur CAN auquel on a ajouté un module de synchronisation (FSE, Frame Synchronisation Entity). La figure 2, dans la partie 2.2, montre le schéma d un noeud TTCAN. Le schéma d émission permet la transmission de l ensemble des messages de données, même en cas d erreur, grâce à la présence de fenêtres à arbitrage dans lesquelles sont réémis les messages qui n ont pas pu être émis dans leur fenêtre exclusive. 3.1 Eléments de TTCAN Le module FSE de TTCAN se compose principalement de trois éléments [HMFH00] : TSO (Time Schedule Organiser), gère les fenêtres d émission et de réception, MSA (Master State Administrator), gère l émission des Messages de Référence, CTC (Cycle Time Controller), fournit le temps global du système pour chaque noeud. Par simplification, on utilise un seul automate qui délivre un temps global à l ensemble des noeuds. Ce sont les élements qui seront implantés. La synthèse du principe d application distribuée, de la pile protocolaire de TT- CAN et des éléments de FSE conduit au schéma de conception suivant : FIG. 5 Architecture du bus Le bus et la partie 11898-1 du controleur (norme CAN) sont celles implémentées par T. Razafindralambo, avec quelques adaptations. Il s agit d implémenter la partie 11898-4 du controleur (TTCAN), c est à dire le FSE (Frame Synchronisation Element), ainsi que l introduction d erreurs.

10 3.2 Hypothèses Afin de permettre la comparaison avec les travaux de [GAM04], les hypothèses d erreurs et la configuration des bus sont les mêmes : le bus considéré est un bus TTCAN avec quatre noeuds, dont deux Time Master potentiels, matrice de scheduling (exemple), un message d erreur au plus tous les deux cycles de base. 3.3 Schéma d émission La matrice d ordonnancement comporte une fenêtre à arbitrage tous les deux Cycles de base, sur la dernière fenêtre du cycle, afin de permettre la réémission des messages erronés. Etant donné qu une erreur peut se produire au plus une fois tous les deux cycles de base, tous les messages seront transmis sur le bus. On considère que le délai d arrivée du message, selon les conditions de temps réel dur (un message arrivé en retard n a plus de valeur), est respecté. Si l on a besoin d un délai moindre, il suffit de multiplier le nombre de fenêtres à arbitrage par cycle. La matrice utilisée est celle présentée dans le tableau suivant : MR, Message de Référence, MR EW EW EW MR EW EW AW MR EW EW EW MR EW EW AW EW, fenêtre exclusive (exclusive window), AW, fenêtre à arbitrage (arbitrating window). La figure 6 montre le déroulement d un Cycle de Base (Basic Cycle, BC), avec : T x_enable = msg_error_size + Interf rame_space le temps entre deux messages de données, suffisant pour qu une erreur sur un message ne perturbe pas l émission du suivant. FIG. 6 Déroulement d un cycle de base

Inter_Slot1 11 3.4 Modèle de TTCAN Les schémas détaillés du modèle sont visibles dans l annexe A. 3.4.1 TSO (Time Schedule Organiser) Plusieurs aspects sont traités par le TSO : l écoulement du temps, l initialisation, l erreur S3, les cycles de base à l intérieur de la matrice d émission et les slots à l intérieur d un cycle de base, ainsi que les erreurs d émission dans les slots. La figure 7 présente un aperçu de cet automate. Erreur dans un slot error1 11 Initialisation Entre les Cycles de Base 10 idle 0 Sync_Off 1 Synchronising Msg_Ref_being_sent2 Msg_Ref_being_sent1 2 3 4 5 Msg_Ref_end Inter_Slot 6 7 in_slot 8 end_slot Erreur S3 Slot 9 FIG. 7 Automate TSO Ecoulement du temps Le temps local est mis à zéro lors du début du l initialisation (ou de la réinitialisation), et au début de la réception d un Message de Référence. Dans une fenêtre d émission, le moment de fin de fenêtre d émission de message de données, ainsi que de fin de fenêtre d émission de trame d erreur, est synchronisé par le temps global au niveau du CTC, en prenant en compte une gigue de 4 temps bits (valeur arbitraire). A la fin de la fenêtre d émission d une trame d erreur, chaque noeud reste une durée Interframe_space dans l état Inter_Slot avant de passer au Slot suivant.

12 Si le noeud est à la fin du Cycle de Base, il attend Watch_Trigger dans l état Inter_Slot. On considère que, dans notre système, il n y a pas de fenêtre d arbitrage destinée à la transmission d alarmes : toutes les fenêtres à arbitrage sont destinées à la retransmission des messages erronés. Initialisation Le lancement de la simulation dans l automate TSO est marquée par le signal depart. Ceci permet le départ simultané de la simulation pour l ensemble des noeuds. Le TSO entre ensuite dans une phase de configuration (noeud Sync_Off ). Le signal config_done est émis afin de signifier au MSA que la configuration du noeud est achevée et que celui-ci peut commencer à écouter le bus en vue d émettre des Messages de Référence. Puis le TSO écoute sur le bus l arrivée de Messages de Référence pour la synchronisation (noeud synchronising ). La synchronisation a lieu par la réception de deux Messages de Référence consécutifs, sans discontinuité temporelle entre les deux. Il y a une discontinuité dans le temps global quand le temps du système est synchronisé avec une horloge extérieure (type GPS). A la réception du deuxième Message de Référence, les paramètres du noeud sont initialisés (numéro de colonne, temps de cycle à la fin de la réception du Message de Référence, numéro de cycle courant), et la transmission de données peut commencer. Erreur S3 Quel que soit l état de l automate, en cas d erreur de type S3 (signal S3_node, noeud 12), la configuration du noeud recommence, en retournant à l état Sync_Off (noeud 1). Entre les Cycle de Base L état par défaut entre deux Cycles de base, de même qu entre deux Slots, est Inter_Slot (noeud 6). En cas de Gap (Next_is_Gap == 1), on attend un nouveau Message de Référence, qui doit arriver avant la valeur de W atch_t rigger (transition vers le noeud 4). W atch_t rigger peut prendre deux valeurs, Gap (noté W atch_t rigger_gap) ou non Gap (noté W atch_t rigger). Le noeud étant en état In_Schedule (node_state[x] == 4), la transition du noeud 4 vers le noeud 5, à la réception d un Message de Référence, se fait indépendament de la présence de discontinuité (Disc_bit == 0 ou Disc_bit == 1). S il n y a pas de Gap, l automate passe directement de Inter_Slot (noeud 6) à l état Msg_Ref_end (noeud 5), à la reception d un Message de Référence, avant de mettre à jour la valeur de cycle_count et de passer dans l état Inter_Slot (noeud 6).

13 Slots Dans un Cycle de Base de notre exemple, il y a trois fenêtres d émission, ou Slots. Leur déroulement est marqué par : le début de la colonne, la fin de fenêtre d émission, et la fin de l émission d une éventuelle trame d erreur. Ceci correspond à trois parcours successifs des états du Slot : Inter_Slot, in_slot, end_slot, Inter_Slot1. Les valeurs temporelles des débuts de chaque colonne sont contenues dans le vecteur columns. Chaque noeud met à jour le numéro de la colonne dans laquelle il se trouve (column). Les moments de fin de fenêtre d émission de message de données et de fin de fenêtre d émission de trame d erreur sont indiqués par des synchronisations initiées par le CTC (signaux col, end_slot). Chaque noeud peut être, pour une colonne donnée d un cycle de base donné, en émission (Tx_Trigger=100), en réception (Tx_Trigger=200), silencieux (Tx_Trigger=300), ou en fenêtre d arbitrage (Tx_Trigger=400). Si la dernière fenêtre d un cycle de base ne connaît pas d erreur, on peut sortir du cycle de base sans attendre le temps nécessaire à l émission d une trame d erreur (passage de In_Slot à Inter_Slot1 sans passer par end_slot). Ce temps est présent entre les différentes colonnes pour qu une erreur sur un message n affecte pas le message suivant. Erreur d émission En cas d erreur lors de l émission d un message de données, l émission de celui-ci est suspendue jusqu à la prochaine fenêtre d émission à arbitrage. Les conditions d erreur données comme hypothèse ont comme conséquence qu il ne peut y avoir de conflit lors de la réémission, dans la mesure où il y a au plus une erreur tous les deux cycles de base, c est à dire avec la même période que les fenêtres à arbitrage. Si un noeud en émission observe une erreur sur le message qu il a envoyé (bit_stuff_error ici), il l enregistre afin de procéder à sa réémission (msg_2_resend := 1) (noeud 10), et annule la réémission du Message normalement prévu dans CAN (Cancel_msg). En fait, selon la norme, il n y a pas annulation du message, mais annulation du processus de réémission de CAN pour TTCAN, sauf dans quelques cas précis (Message de Référence, fenêtre à arbitrage suffisamment longue). Par ailleurs, le noeud error1 (noeud 11) est atteint si un TSO reçoit un Message de Référence alors qu il se trouve dans une fenêtre d émission. 3.4.2 MSA (Master State Administrator) Le MSA, Master State Administrator, implémente les fonctionnalités des Time Master potentiels : initialisation, attente d émission et émission de Messages de Références (MR), erreur d émission, gestion de Tx_Ref_Offset, numéro du cycle de base courant et configuration.

14 La figure 8 présente un aperçu de cet automate. Erreur d emission Attente d emission Emission d un MR waiting4cancelingrm 12 13 before_msg_complete 3 4 11 5 Msg_Ref_sent 2 1 In_Schedule 7 bigger_priority 10 Configuration 9 lesser_priority 8 idle 0 Initialisation 6 own_priority Numero de cycle Gestion de Tx_Ref_Offset FIG. 8 Automate MSA Initialisation L état initial est le noeud 0. L initialisation consiste à attendre que le TSO associé ait terminé son initialisation (signal config_done). La transition vers le noeud 1 (attente d émission) a alors lieu. En cas d erreur de type S3, l automate recommence la configuration du noeud, en retournant à l état Idle (noeud 0). Attente et émission Après l initialisation, le Time Master potentiel écoute le bus pendant une durée W atch_t rigger_gap avant d émettre un Message de Référence (noeud 1). Il peut émettre un Message de Référence si l une des deux conditions est remplie : expiration de W atch_t rigger_gap ; on tente d émettre (transition vers l état 2), la garde de la transition étant atteint, réception d une trame d erreur (end_error) après avoir reçu le bit Start_of_Frame (Ref_frame_sync) d un Message de Référence ; on tente alors d émettre (transition vers le noeud 2),

15 En cas de réception d un Message de Référence, on passe dans l état 11, qui correspond à l écoute d un Message de Référence émis par un autre Time Master potentiel. Pendant un Gap, le comportement est identique. Entre deux Cycles de Base, le temps d attente dans l état In_Schedule (noeud 1) est la valeur de W atch_t rigger (variable qui représente la valeur de Watch_Trigger hors Gap). Les transitions pour sortir de cet état sont les mêmes que pour la fin d attente d émission (expiration ou réception d un Message de Référence). Si un autre Message de Référence commence à être émis (réception du signal Ref_frame_sync), le noeud attend la réception complète de ce message ( wait_time = Msg_Ref_size et clock c := 0) après l expiration de wait_time avant de tenter d émettre à nouveau un Message de Référence (et donc d effectuer la transition vers le noeud 2). Ainsi, si un Message est correctement émis, le Time Master potentiel reçoit le signal msg_sent, avec current_msg_is_ref == 1, et passe directement de l état In_Schedule (noeud 1) à l état Msg_Ref_sent (noeuds 11 puis 5). Dans le cas où le Message de Référence émis est erroné, le Time Master potentiel tente d émettre un Message (transition vers le noeud 2) dès qu il voit la fin de la trame d erreur sur le bus (réception de end_error après Ref_frame_sync). Erreur d émission En cas d erreur lors de l émission du Message de Référence (ici, c est l erreur de bit_stuffing qui est utilisée en exemple), le Time Master annule l émission du Message (Cancel_msg). Ceci permet de neutraliser la réémission automatique existante dans le protocole CAN. Le noeud 12 est C (commited), car une seule transition ne peut contenir plusieurs synchronisations. A la fin de l émission de la trame d erreur (signal end_error), le Time Master potentiel retourne dans l état In_Schedule, et attend T x_t rigger avant de pouvoir émettre un nouveau Message de Référence. Gestion de Tx_Ref_Offset La partie Gestion de Tx_Ref_Offset se fait selon la norme, et selon les mécanismes explicités dans le document Etat de l art : le protocole TTCAN, Mécanismes > Sélection du maître. Pour la gestion de Tx_Ref_Offset, on a : Ref_T rigger_offset = Delta_round T x_ref_offset. Le noeud 7 (bigger_priority) et les transitions du noeud 7 vers le noeud 9 gèrent le cas des Time Master potentiels, qui n ont pas émis le Message de Référence du Cycle de Base courant, mais dont la priorité est supérieure à celle du Message de Référence émis. Si Ref_T rigger_offset > 0, alors on modifie : Ref_T rigger_offset = 0. Si Ref_T rigger_offset 0, alors on modifie : Ref_T rigger_offset =

16 Ref_T rigger_offset 2 (décrémentation d un temps bit, donc de deux unités de temps UPPAAL). Le noeud 8 (lesser_priority) et les transitions du noeud 8 vers le noeud 9 gèrent le cas des Time Master potentiels qui n ont pas émis le Message de Référence du Cycle de Base courant, et dont la priorité est inférieure à celle du Message de Référence émis. Si Ref_T rigger_offset 0, alors on modifie : Ref_T rigger_offset = Initial_Ref_T rigger. Le noeud 6 (own_priority) concerne le noeud qui a émis le Message de Référence du Cycle de Base courant. Si Ref_T rigger_offset 0, alors on modifie Ref_T rigger_offset = 0 (Transition du noeud 5 vers le noeud 6). Les transitions de 6 vers 9 gèrent le numéro de Cycle (voir paragraphe correspondant). Numéro de Cycle Le Time Master courant met à jour le numéro de Cycle de Base (M aster_cycle_count) dans la matrice (transition entre le noeud 6 et le noeud 9) : incrémentation de 1, sauf dans le cas où Cycle_Count_Max est atteint. Dans ce cas, le compteur Master_Cycle_Count est remis à zéro. Configuration Avant de recommencer à écouter sur le bus, les Time Master potentiels mettent à jour les paramètres d attente, wait_time (en fonction de N ext_is_gap) et de Discontinuité (Disc_bit en fonction de set_disc_bit) (transitions noeud 9 vers noeud 10, et noeud 10 vers noeud 1). 3.4.3 CTC (Cycle Time Controller) Le CTC (Cycle Time Controller) fournit le temps de cycle global au TSO de chaque noeud. Le CTC prend en compte un décalage temporel entre les noeuds : les noeuds voient les échéances temporelles avec 0..4 temps bits de retard. Le CTC gère la fin de la fenêtre d émission et la fin de la fenêtre de trame d erreur. La figure 9 présente un aperçu de cet automate. Lancement L état initial est Waiting4Msg (noeud 0). Le CTC donne le temps de cycle global : le parcours des états successifs a lieu à partir de la réception du Message de Référence. Il dépend ensuite uniquement du déroulement du temps. La transition vers le noeud 1 se fait donc à la réception du signal msg_sent, avec current_msg_is_ref == 1. La valeur de cycletime est alors mise à jour (cycletime := msg_ref_size).

17 Fin de la fenetre de trame d erreur 4 0 Waiting4Msg Inter_Slot Erreur_frame 1 2 3 Fin de Fenetre d emission FIG. 9 Automate CTC Fin de la fenêtre d émission A la fin de la colonne courante (temps donné par cycletime == columns[column + 1]), le signal col de fin de colonne est émis pour le premier noeud (transition du noeud 1 vers le noeud 2). Une gigue de 1 temps bit (2 unités de temps UPPAAL) supplémentaire est introduite pour chaque noeud. Un compteur (i) contient l indice du noeud courant. Quand i == 3, le dernier signal col est émis, et on passe dans l état Error_frame (noeud 3). Fin de la fenêtre de trame d erreur Si on se trouve à la fin du Cycle de Base, et qu il n y a pas d erreur (column == 2, error_here == 0), on revient sans attendre à l état Waiting4Msg (noeud 0). Si l on se trouve à l intérieur du Cycle de Base (column < 2) ou à la fin du Cycle de Base si le message émis est erroné (column == 2 and error_here == 1), on émet un signal end_slot pour chaque noeud, avec la même gigue que lors de l émission du signal col. Il faut noter qu il y a une gigue, mais pas de glissement de l horloge : l émission du deuxième signal n est pas modifiée par la présence de gigue au premier signal. Après la signal end_slot de fin de trame d erreur, on passe au Slot suivant si on se trouve dans le Cycle de Base (transition vers le noeud 1). Sinon, à la fin du Cycle de Base, on passe à l état Waiting4Msg (noeud 0), et on attend un Message de Référence.

18 3.5 Observateurs L observateur doit être adapté au scénario considéré : un canal de synchronisation commande la mise en route de l horloge, un autre la fin de la phase étudiée. Si cette deuxième synchronisation a lieu trop tard, l horloge a atteint la deadline et il y a deadlock. 3.6 Scénarios Un automate implémente les différents scénarios de test et d extraction de bornes dans TTCAN. Les variables correspondantes doivent être modifiées dans les Déclaration globales, en fonction du scénario que l on souhaite valider. Il est également indispensable d adapter l observateur aux conditions de début et de fin de la phase à borner, ainsi que de modifier la valeur de la borne (une borne trop petite étant cause de deadlock). Les scénarios sont basés sur les évènements pouvant arriver : Gap, présence d une discontinuite au deuxième Message de Référence, réémission du Message de Référence du à une erreur, émission erronée d un message quelconque de la matrice, cas d erreur S3, qui a pour conséquence la réinitialisation du noeud concerné. En exemple, nous présentons le scénario de réinitialisation d un noeud non Time Master sur bus actif sans erreur, avec Gap. Ce scénario est composé de deux phases, le lancement de la réinitialisation, et la resynchronisation du noeud avec le bus en présence de discontinuité temporelle. La séquence des noeuds parcourus est la suivante : 0, 15, 16, 17, 18, 19, 20, 22, dans l automate de gestion des scénarios. Phase 1 : Réinitialisation On réinitialise le noeud une fois qu il est synchronisé, c est à dire après la réception de deux Messages de Référence. On émet un signal S3_node, qui provoque la réinitialisation d un noeud TTCAN (ici le noeud 1). Ce signal de réinitialisation est émis Delta_round conf ig_time+3 unités de temps UPPAAL après le deuxième Message de Référence, de telle sorte que le noeud soit en phase de configuration lors de l émission du Message de Référence suivant, et qu il ne puisse pas le prendre en compte. Le noeud qui se réinitialise doit donc attendre le Message de Référence suivant pour de commencer la synchronisation. Ceci correspond à une stratégie de recherche du pire cas. Phase 2 : Discontinuité On introduit une discontinuité lors du deuxième Message de Référence reçu par le noeud en cours de réinitialisation. Le mécanisme de synchronisation ne peut donc pas avoir lieu, car il nécessite la réception de deux Messages de Référence consécutifs entre lesquels le temps se déroule de manière continue. Le noeud doit donc attendre le Message de Référence suivant afin de réaliser sa synchronisation, et de pouvoir émettre des messages de données. La figure 10 montre ce scénario.

19 FIG. 10 Scénario de réinitialisation sans erreur, Disc_bit==1 4 Obtention des bornes La méthodologie d obtention des bornes a été présentée dans la partie 2.3. La borne du mécanisme de réintégration sans Gap et avec discontinuité temporelle, sans et avec erreur, est détaillée ici. Le principe du Gap est présenté dans la partie 2.2, paragraphe Matrice d émission, et le mécanisme de la discontinuité temporelle dans la partie 3.6. Les autres bornes que nous avons trouvées seront ensuite présentées. Le principe de la réintégration a été présentée dans la partie 3.6. La borne est le temps maximal entre le signal de réinitialisation, et le moment où le noeud est capable d émettre des messages, c est à dire la fin de l émission du Message de Référence avant l émission des messages de données. La réception de ce message marque la synchronisation réussie du noeud avec le Time Master en cours. Le cas des Gap (intervalle long entre la fin d un Cycle de Base et le début du cycle de base suivant) est également étudié, mais n est pas présenté ici : il introduit un espace de temps indéfini entre deux Cycles de base, et les bornes temporelles dépendent alors du moment d arrivée du signal de fin de Gap, par définition aléatoire. La réinitialisation met le noeud considéré dans l état de configuration, et elle est suivie de la synchronisation du noeud concerné avec le Time Master déjà actif sur le bus. C est donc le même scénario que l initialisation sur bus actif.

20 Les tests effectués sur le modèle pour vérifier sa validité sont les suivants : Test E<>(TTCAN_Session_3.Msg_Ref_being_sent2 and Case.waiting4msg3) A[] not deadlock Résultat non oui 4.1 Exemple d une borne sans erreur Le scénario précis est le suivant : 1. Le système s initialise et se synchronise une première fois. On a donc quatre noeuds, dont deux Time Master potentiels, sur le bus. Au moins deux Messages de Référence ont été émis. 2. Un signal de réinitialisation est émis (classiquement Application_Watchdog, c est à dire mort de l application). Le pire cas est celui où le Message de Référence suit dans un délai conf ig_time le signal de réinitialisation. Le signal doit être émis plus de : round config_time + max(ref_t rigger_offset) après le Message de Référence précédent. Dans ce cas, le noeud sort du mode de configuration immédiatement après le début de l émission du Message de Référence, et ne connait donc pas la valeur de Sync_Mark. Il ne peut donc recevoir ce Message de Réference. 3. Le noeud reçoit un message de Référence, puis un deuxième, qui contient le Bit de Discontinuité à un. Il ne peut donc pas se synchroniser. 4. Le noeud reçoit un troisième Message de Référence, sans discontinuité temporelle. A la fin de ce Message de Référence, le noeud a fini sa réinitialisation. Les paramètres sont les suivants : config_time, le temps nécessaire à la configuration du noeud avant qu il puisse commencer la phase de synchronisation, Ref_msg_size, la taille du Message de Référence, round, la durée d un round TDMA. Les valeurs obtenues pour la borne en fonction des paramètres, avec le bit de discontinuité, sont : config_time Ref_msg_size round δ borne 10 206 1112 1 3551 2 206 1112 1 3543 2 158 1064 1 3351 10 158 1064 1 3359

21 La borne (avec bit de discontinuité) est : config_time + 3 round + Msg_ref_size δ δ exprime le fait que le signal d erreur est lancé moins de config_time avant le début d un nouveau cycle. La valeur de la borne : config_time + 3 round + Msg_ref_size est exclue des possibilités, le temps en pire cas tend vers cette valeur mais ne l atteint jamais. 4.2 Exemple d une borne avec erreur On considère le scénario ci-dessus, avec introduction d erreurs. Le pire cas est celui dans lequel il y a des erreurs lors de du premier et du troisième Message de Référence de la phase de réinitialisation, et réémissions immédiates. La réémission est réussie à chaque fois. Le scénario est donc le suivant : 1. Le système s initialise et se synchronise une première fois. On a donc quatre noeuds, dont deux Time Master potentiels, sur le bus. Au moins deux Messages de Référence ont été émis. 2. Un signal de réinitialisation est émis (classiquement Application_Watchdog, c est à dire mort de l application). Le pire cas est celui où le Message de Référence suit dans un délai conf ig_time le signal de réinitialisation. Le noeud sort alors du mode de configuration immédiatement après le début de l émission du Message de Référence, et ne connait donc pas la valeur de Sync_Mark. Il ne peut donc recevoir ce Message de Réference. 3. Le noeud reçoit un message de Référence erroné, qui doit être réémis, 4. le noeud reçoit un deuxième Message de Référence, qui contient le Bit de Discontinuité à un. 5. Le noeud reçoit un troisième Message de Référence, erroné, qui doit être réémis. A la fin de ce Message de Référence, le noeud a fini sa réinitialisation. Les paramètres sont : config_time, Ref_Msg_size, round, error_frame_size, la taille d une trame d erreur. Remarque : au pire cas, on a max(error_frame_size) = 23 temps bits, alors que l erreur utilisée dans le modèle (bit stuffing) engendre un message d erreur de 44 unités (22 temps bits).

22 FIG. 11 Scénario de réinitialisation avec erreur, Disc_bit==1 Les valeurs obtenues pour la borne en fonction des paramètres, avec le bit de discontinuité, sont : config_time Ref_msg_size round error_frame_size δ borne 10 158 1064 44 1 3763 2 158 1064 44 1 3755 2 206 1112 44 1 4043 10 206 1112 44 1 4051 La borne avec le bit de discontinuité, est : config_time + 3 round + 3 Msg_ref_size + 2 error_frame_size δ 4.3 Autres bornes Les résultats sont présentés dans l annexe B.

23 5 Comparaison avec TTA 5.1 Particularités de TTCAN TTCAN présente, par rapport à TTA, deux particularités, qui lui offrent de la flexibilité, mais influent sur le comportement temporel : la présence de Gap, c est à dire la suspension de l émission des messages pour un temps indéfini, entre deux Cycles de Base, et la discontinuité du temps global du système. Gap La durée entre deux Messages de Références lors d un Gap est notée : T x_t rigger_gap La présence d un Gap lors d un scénario modifie donc la borne b de la manière suivante : b = b + T x_t rigger_gap round. Discontinuité La conséquence d une discontinuité est l imposibilité d utiliser le temps global au moment de la discontinuité pour calculer le glissement relatif de l horloge locale par rapport à l horloge du Time Master. En cas d initialisation, où la synchronisation doit être faite avant de pouvoir commencer à émettre des messages, il est donc nécessaire d attendre le Message de Référence suivant pour finir cette initialisation. La présence d une discontinuité lors d un scénario modifie donc la borne b de la manière suivante : b = b + round. Il est nécessaire, afin de pouvoir faire la comparaison entre TTA et TTCAN, de prendre en compte des comportements pour des situations identiques, et donc de comparer la valeur des bornes de TTA à celles de TTCAN sans Gap, et sans discontinuité temporelle. 5.2 Services communs Nous présentons les valeurs des bornes pour TTA et TTCAN. 5.2.1 Synchronisation TTA avec erreur : cycle TTCAN sans erreur : round + Ref_Msg_size avec erreur : round + 2 Ref_Msg_size + Error_frame_size

24 Analyse La synchronisation d horloge dans TTA dépend de la durée de la matrice d émission. Dans TTCAN, elle dépend principalement de la durée du cycle de base. A priori, la synchronisation sera donc plus rapide en TTCAN, en particulier pour des systèmes complexes qui nécessitent un grand nombre de cycles de base. 5.2.2 Initialisation L initialisation est le temps entre le passage à l état ON du contrôleur de 2 ou plusieurs noeuds en TTA, un seul ou plus en TTCAN, et le passsage à l état dit actif, c est-à-dire quand le noeud est susceptible de commencer à émettre des messages. On considère que l ordonnancement en TTA et en TTCAN est le même : même nombre de cycle de base (aussi appelé round TDMA) par matrice d émission, même nombre de fenêtres d émission par cycle de base, même taille des fenêtres d émission. On cherche donc la valeur de τ wcsup, le temps d initialisation en pire cas (wake up start up time). TTA Les paramètres qui entrent en jeux dans l initialisation de TTA sont : τ listen, temps d écoute sur le bus. τ coldstart, durée du mécanisme de cold start. round, la durée par défaut d un cycle de base. slot, la durée maximale d un slot. La borne est constituée du temps d écoute du bus, du mécanisme coldstart, et du passage à l état actif. On considère uniquement le temps avec erreur [?]. τ wcsup = τmax 1 listen + 2 τ max 1 coldstart + slot = 3 round 2 slot +2 (2 round 2 slot ) + slot = 7 round 5 slot TTCAN Les paramètres qui entrent en jeux dans l initialisation de TTCAN sont : τ listen, temps d écoute sur le bus. τ synchro, temps du mécanisme de synchronisation. round, la durée par défaut d un cycle de base. slot, la durée maximale d un slot (peut contenir jusqu à huit octets de données). T x_t rigger_gap, round + n m Ref_msg_size T x_t rigger_gap 2 10 16 1 (ou temps maximal de Gap prévu lors de la conception, ce qui permet d avoir une initialisation beaucoup plus rapide). Dans le cas du minimum, il s agit du temps d un round TDMA allongé du temps pendant

25 lequel les noeuds tenterons de réémettre le Message de Référence avant le lancement d une procédure de traitement d erreur. Le maximal est le temps maximal que peut supporter un contrôlleur TTCAN. Ref_msg_size _slot, tous les slots n ont pas la même taille. n 8 nombre de Time Master potentiels sur le bus. m, arbitraire, nombre de tentative d émission du message de Référence par un Time Master potentiel avec le lancement d un procédure d erreur. Initial_Ref_Of f set, l offset par défaut de chaque Time Master potentiel, c est à dire le temps d écoute qui s ajoute à T x_t rigger_gap. Il est différent pour chaque noeud, et fonction de la priorité du noeud. Ref_T rigger_of f set, la valeur effective de l offset pour le noeud considéré. 127 Ref_T rigger_offset 127. La borne est composée du temps d écoute du bus, et du mécanisme de synchronisation. Sans erreur : τ wcsup = τ listen + τ synchro = conf ig_time + T x_t rigger_gap + min(initial_ref_of f set) + round + Ref_msg_size Avec erreur : τ wcsup = τ listen + τ synchro = conf ig_time + T x_t rigger_gap + min(initial_ref_of f set) + round + 2 Ref_msg_size + error_frame_size Analyse On néglige le temps de configuration, faible comparé au temps d écoute sur le bus, et non pris en compte dans la borne de TTA. Il n est pas possible de tirer des conclusions absolues sur la supériorité de l un ou l autre protocole pour l initialisation. Si TTCAN est configuré de manière à pouvoir supporter de grands Gaps, le temps d écoute sur le bus est très grand et l initialisation est beaucoup plus longue que sur TTA. Par contre, si on considère un système sans Gap, TTCAN est plus performant que TTA à condition que le nombre de fenêtres d émission par round TDMA soit supérieur à (n m + 7)/5. Dans tous les cas, la durée de l initialisation n a que peu d importance au démarrage du véhicule, dans la mesure où celui-ci nécessite plusieurs secondes, à cause du démarrage du moteur. Par contre, si un noeud doit être lancé pendant le fonctionnement du véhicule, la durée de l initialisation peut éventuellement devenir critique. 5.2.3 Réinitialisation Les valeurs de la borne de réinitialisation pour TTA ne sont pas disponibles. On ne peut donc pas effectuer la comparaison des deux protocoles pour la réinitia-

26 lisation. TTCAN Réinitialisation d un noeud après erreur, ou l initialisation d un nouveau noeud, sur bus contenant au moins un noeud actif. sans erreur : config_time + 2 round + Msg_ref_size δ avec erreur : config_time + 2 round + 2 Msg_ref_size + error_frame_size δ. 5.2.4 Réintégration TTA Réintégration si un noeud devient ON et reçoit une trame avec C_State explicite pendant l écoute du bus. La réintégration correspond aux cas Membership Loss, ou Host error ou host life-sign not update. round + 2 Slot T P + π TTCAN La borne de réintégration correspond à une erreur d émission S2, qui provoque la suspension de l émission de l ensemble des messages. 2 N m round Dans certains cas, il faut également considérer la borne de réinitialisation : sans erreur : config_time + 2 round + Msg_ref_size δ avec erreur : config_time + 2 round + 2 Msg_ref_size + error_frame_size δ. Analyse Les deux bornes de réintégration sont dificilement comparables : en effet, la réintégration en TTA est causée par une erreur symétrique ou de faute byzantine, dans le cas de Membership loss, et ne concerne que les noeuds fautifs, alors que l erreur en TTCAN (S2) correspond à un trafic très perturbé sur le bus et une suspension totale de la transmission des messages. Il faut noter également que la borne de TTCAN n est valable que si la faute n est pas périodique de période N m round. Celà étant, on observe que la réintégration des noeuds se fait plus rapidement, et de manière sélective pour TTA. Alors que dans TTCAN, quand le système est en état d erreur S2, l ensemble des noeuds se taisent, et le temps de réintégration est plus long. Pour le cas où la réintégration est causée en TTA par une erreur de l hôte (du type host life-sign not update ), la borne correspondante en TTCAN est celle de la réinitialisation. Le terme majeur de la borne en TTA est round, alors que pour TTCAN c est 2 round. La réintiailisation est donc environ plus longue d un round TDMA