Rapport de PFE Validation temporelle d’architectures ...

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

Transcript of Rapport de PFE Validation temporelle d’architectures ...

Page 1: Rapport de PFE Validation temporelle d’architectures ...

Rapport de PFEValidation temporelle d’architectures embarquées

pour l’automobile

Pierre ParrendINSA Lyon

Encadrant : Isabelle Augé-BlumCITI

Juin 2004

Page 2: Rapport de PFE Validation temporelle d’architectures ...

Résumé

Cette étude se situe dans un contexte de fort développement des applications au-tomobiles basées sur l’électronique, en vue de remplacer certaines pièces méca-niques, tels les systèmes de freinage, de direction. Le protocole le plus utilisé ac-tuellement 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, cetype 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 pourun protocole destiné à des applications à haut niveau de sécurité de disposer d’unvalidation formelle. Nous allons étudier son comportement temporel à l’aide del’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ésultatsobtenus.

Ces données nous permettent une comparaison systématique avec le protocoleTTA, ce qui offre une mise en perspective critique des deux protocoles.

Page 3: Rapport de PFE Validation temporelle d’architectures ...

i

Table des matières

1 Introduction 1

2 Contexte de l’étude 22.1 Monde CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.1 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.2 Autres Protocoles . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Protocole TTCAN . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.1 Matrice d’émission . . . . . . . . . . . . . . . . . . . . . 32.2.2 Synchronisation d’horloge . . . . . . . . . . . . . . . . . 5

2.3 Validation temporelle . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1 Validation existante . . . . . . . . . . . . . . . . . . . . . 72.3.2 UPPAAL . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.3 Méthode employée . . . . . . . . . . . . . . . . . . . . . 7

3 Modélisation 93.1 Eléments de TTCAN . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Hypothèses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Schéma d’émission . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Modèle de TTCAN . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4.1 TSO (Time Schedule Organiser) . . . . . . . . . . . . . . 113.4.2 MSA (Master State Administrator) . . . . . . . . . . . . . 133.4.3 CTC (Cycle Time Controller) . . . . . . . . . . . . . . . 16

3.5 Observateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.6 Scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Obtention des bornes 194.1 Exemple d’une borne sans erreur . . . . . . . . . . . . . . . . . . 204.2 Exemple d’une borne avec erreur . . . . . . . . . . . . . . . . . . 214.3 Autres bornes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Comparaison avec TTA 235.1 Particularités de TTCAN . . . . . . . . . . . . . . . . . . . . . . 235.2 Services communs . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2.1 Synchronisation . . . . . . . . . . . . . . . . . . . . . . 235.2.2 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . 245.2.3 Réinitialisation . . . . . . . . . . . . . . . . . . . . . . . 255.2.4 Réintégration . . . . . . . . . . . . . . . . . . . . . . . . 265.2.5 Accusé de réception . . . . . . . . . . . . . . . . . . . . 275.2.6 Communication Blackout Check . . . . . . . . . . . . . . 27

5.3 Bornes spécifiques . . . . . . . . . . . . . . . . . . . . . . . . . 285.3.1 TTCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3.2 TTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Page 4: Rapport de PFE Validation temporelle d’architectures ...

ii

5.4 Récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 Conclusion 30

Bibiographie 31

Annexes 32

A Les automates du modèle 32A.1 Cycle Time Controller (CTC) . . . . . . . . . . . . . . . . . . . . 32A.2 Time Schedule Organiser (TSO) . . . . . . . . . . . . . . . . . . 33A.3 Master State Administrator (MSA) . . . . . . . . . . . . . . . . . 37

B Les bornes de TTCAN 40B.1 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 40B.2 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40B.3 Réinitialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B.4 Initialisation/Réinitialisation d’un Time Master . . . . . . . . . . 41B.5 Emission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42B.6 Variation de la durée d’un cycle . . . . . . . . . . . . . . . . . . 42B.7 Reprise d’erreur S2 . . . . . . . . . . . . . . . . . . . . . . . . . 43

Page 5: Rapport de PFE Validation temporelle d’architectures ...

1

1 Introduction

Les équipementiers automobiles tendent à remplacer un grand nombre de piècesmécaniques par des circuits électroniques, qui doivent être plus fiables, plus souples,et surtout moins onéreux. Actuellement, les applications concernées sont des ap-plications de confort, mais un grand nombre de recherches sont effectuées dans lebut de remplacer les systèmes de transmission, de direction, de freinage, par l’élec-tronique : ce sont les applications embarquées dites ‘X-by-Wire’, basées sur desré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, avectransmission 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’automo-bile est CAN (Controller Area Network). Plusieurs couches applicatives ont été dé-veloppées, pour des environnements spécifiques (industrie, véhicules, etc...). L’unedes dernières évolutions de CAN est l’introduction d’une couche Session qui per-met la communication time-triggered, et doit résoudre les problèmes de validationde CAN : TTCAN (Time-Triggered Controller Area Network). TTCAN permetd’assurer un fonctionnement en temps réel dur, c’est à dire avec garantie d’arrivéedes messages avant leur expiration. Il est indispensable de valider le comportementtemporel de TTCAN, pour vérifier l’effectivité de cette garantie d’arrivée des mes-sages. Ceci est réalisé à l’aide de UPPAAL, selon une méthode déjà employée pourd’autres travaux.

Après l’étude du comportement de TTCAN, la comparaison avec un autre pro-tocole de réseau de terrain, en l’occurence TTA, permet d’évaluer les avantages etles inconvénients de chacun, et de mettre en perspective d’éventuelles lacunes.

Page 6: Rapport de PFE Validation temporelle d’architectures ...

2

2 Contexte de l’étude

Cette étude vise à améliorer la connaissance d’une des dernières évolutions deCAN, TTCAN, en s’interrogeant sur la pertinence de son utilisation dans des ap-plications nécessitant une grande sécurité.L’interêt de TTCAN repose sur l’importance de l’utilisation de CAN et des nom-breuses couches applicatives qui y sont associées, que nous détaillerons.Nous présenterons ensuite TTCAN, dont la transmission Time-Triggered est baséesur une matrice d’émission définie lors de la conception du système. La synchro-nisation 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 in-dispensable de valider ses propriétés temporelles. Ceci est réalisé avec le logicielUPPAAL, 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 uti-lisé dans l’automobile et l’industrie. Le protocole connait une forte utilisation de-puis 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 queles 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 Sensemultiple 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 priori-taire 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 prioritaireest transmis. Tous les émetteurs comparent le message transmis au message qu’ilsont é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 estun 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 couchesapplicatives ont été développées. Au delà des couches génériques (CAL - CAN Ap-plication Layer, puis CANOpen, qui permettent l’accès aux ressources du réseauxsous formes d’objets logiciels, ainsi que l’émission de grands paquets de données),plusieurs couches sont dédiées à des environnements spécifiques :

Page 7: Rapport de PFE Validation temporelle d’architectures ...

3

SDS (Smart Distributed System), réseaux industriels, permet d’accéder aux fonc-tions 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 dusystème, notamment les capteurs et actionneurs ; SDS supporte la présencede sous-réseaux par une couche de routage,

J1939, ISO 11992, véhicules routiers, supporte les sous-réseaux, dispose d’unecouche de transport pour permettre l’émission de paquets de grande taillesur CAN (segmentation),

ISOBUS, engins agricoles, composé d’un bus tracteur et d’un bus sur lequel setrouvent les instruments, avec une couche de transport pour segmenter lespaquets et une couche applicative avec interface utilisateur,

NMEA2000, engins sous-marins, contient une couche de transport et une coucheapplicative.

CANKingdom est un outil de configuration des modules du système, qui per-met la gestion de bus CAN, TTCAN, etc.

2.2 Protocole TTCAN

TTCAN est conçu pour être exploité dans les réseaux de terrain, notammentdans les applications X-by-Wire, pour lesquelles il se trouve en concurence avecTTA et Flexray.TTCAN est une extension du protocole CAN, qui permet la transmission de mes-sages selon un ordre prédéfini (communication Time-Triggered). Ceci permet d’as-surer un fonctionnement en temps réel dur, c’est à dire avec garantie d’arrivée desmessages avant expiration, hors utilisation de Gap (concept qui permet la suspen-sion de la communication Time-Triggered).Le Gap apporte de la flexibilité dans la transmission de données. Par contre, il nepermet 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 synchronisa-tion au niveau du contrôleur TTCAN. La figure 2 nous montre la pile protocolairede TTCAN.

Le protocole FTTCAN définit une extension de TTCAN, en y introduisant lapossibilité de modifier à chaque cycle de base les noeuds émetteurs. Une plusgrande flexibilité est également prévue pour la transmission des messages asyn-chrones.

2.2.1 Matrice d’émission

L’ordonnancement est stocké dans une matrice qui définit les instants d’émis-sion des messages. Une matrice contient plusieurs cycles de base (voir figure 3).

Page 8: Rapport de PFE Validation temporelle d’architectures ...

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 laréémission de messages erronés.

La présence de multiples cycles de base dans cette matrice permet de fonction-ner avec plusieurs séquences différentes de messages. Ces séquences doivent êtredéfinies avant le lancement de l’application.Le mécanisme Time-Triggered permet de confiner chaque message dans sa fenêtred’émission. Par conséquent, une erreur dans une fenêtre n’a pas d’influence surles autres fenêtres. Le débit du bus n’est donc pas affecté par les erreurs, on peututiliser plus pleinement sa bande passante.Le début de chaque cycle de base est marqué par l’émission du bit Start Of Framedu 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 cyclede 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 quipeuvent exister sur le bus. A chacun est associé une priorité, et celui dont la prio-rité 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, parla présence d’un Gap. Ceci permet une plus grande souplesse qu’avec d’autres pro-tocoles à é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.

Page 9: Rapport de PFE Validation temporelle d’architectures ...

5

FIG. 3 – Matrice d’émission de TTCAN

L’implémentation de TTCAN est réalisée par l’ajout d’un module de synchro-nisation 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 garantirune vision cohérente de l’écoulement du temps dans les différents noeuds, et doncune grande précision quant au début des colonnes d’émission. Il existe deux modesde synchronisation d’horloge : le niveau 1 et le niveau 2. La différence entre lesdeux est une différence de précision.Le niveau 1 fait une synchronisation en fonction du moment d’arrivée des messagesde référence, alors que le niveau 2 permet une synchronisation de tous les noeudsavec le temps du Time Master, et donc une plus grande précision et une meilleureutilisation du bus. Des noeuds fonctionnant sur le niveau 1 peuvent co-exiter avecdes noeuds de niveaux 2, car il y a compatibilité mais, dans ce cas, on, on perd lebé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 variableCycle_Time indique lavaleur du temps pendant un cycle de base.Cycle_Time est calculé comme suit :

Page 10: Rapport de PFE Validation temporelle d’architectures ...

6

Cycle_Time = localtime−Ref_Mark (1)

avec :Cycle_Time : temps écoulé depuis le début du cyclelocaltime : temps localRef_Mark : après réception complète du Message de Référence,Ref_Markprend la valeur deSync_Mark.Sync_Mark : La valeur deSync_Mark prend la valeur delocaltime à chaque’Synchronisation Pulse’, c’est à dire au premier bit de chaque trame de donnéestransmise sur le bus. S’il s’agit d’un Message de Référence correctement émis,Sync_Mark est validé est devient la valeur deRef_Mark.En synchronisation de niveau 1, les fenêtres sont plus grandes au fur et a mesureque l’indice de la colonne croît dans le Cycle de Base, afin de compenser les effetsdu glissement d’horloge. Elles doivent bien entendu être définies statiquement pourprendre ce phénomène en compte.

Le niveau 2 Le niveau 2 utilise le temps du Time Master, ou temps global(Global_Time), en prenant en compte l’offset (différence entre le temps globalet le temps local au moment de l’arrivée du Message de Référence), et le glisse-ment de l’horloge locale par rapport à l’horloge globale (TUR, Time Unit Ratio).[DRAFT03].

Les noeuds ont un compteur interne, qui leur permet de compter les NTU (Net-work Time Unit), qui fournissent lelocaltime. Le Global_Time est lelocaltimedu Time Master, transmis aux noeuds dans le Message de Référence.Les variables sont calculées comme suit :

Global_Time = localtime + offset (2)

avec :Global_time : temps global pour le bus

offset = Ref_Mark −Master_Ref_Mark (3)

pour chaque cycle, avec :Master_Ref_Mark : valeur de local time dans le Time Master à l’émission dubit SOF du Message de Référence (‘frame Synchronisation’).

TUR =p_sys

q_gt(4)

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.

Page 11: Rapport de PFE Validation temporelle d’architectures ...

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’agitde la validation du comportement de TTCAN. Il est ainsi possible d’affirmer queTTCAN 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érifica-tion 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 troisparties : 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 tran-sitions ; à garde parce que les transitions sont régulées par la valeur relative deshorloges 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 etd’atteignabilité des états, en explorant systématiquement l’espace d’états des auto-mates du modèle.Une trace de diagnotic est générée, qui indique la cause du succès ou de l’échec dela 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ésen-tée par [GAM04]. Elle comporte deux étapes principales, représentées sur la figure4 :

– 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 comporte-ment de TTCAN.Ensuite, on réalise la vérification du modèle, par la simulation d’une part, par lavalidation 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

Page 12: Rapport de PFE Validation temporelle d’architectures ...

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], quipropose la réduction du nombre de noeuds, d’arcs, d’horloges, d’automates, dechemins 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éerles 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 sila borne n’est pas vérifiée. C’est un automate particulier qui prend une transitioninterdite 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’ob-tenir par analyse une formule paramétrée, qui est l’expression de la borne tempo-relle.

Page 13: Rapport de PFE Validation temporelle d’architectures ...

9

3 Modélisation

TTCAN est un protocole destiné à supporter des applications distribuées indus-trielle 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émad’un noeud TTCAN.Le schéma d’émission permet la transmission de l’ensemble des messages de don-nées, même en cas d’erreur, grâce à la présence de fenêtres à arbitrage dans les-quelles sont réémis les messages qui n’ont pas pu être émis dans leur fenêtre ex-clusive.

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 chaquenoeud. Par simplification, on utilise un seul automate qui délivre un tempsglobal à 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émen-tées par T. Razafindralambo, avec quelques adaptations. Il s’agit d’implémenter lapartie 11898-4 du controleur (TTCAN), c’est à dire le FSE (Frame Synchronisa-tion Element), ainsi que l’introduction d’erreurs.

Page 14: Rapport de PFE Validation temporelle d’architectures ...

10

3.2 Hypothèses

Afin de permettre la comparaison avec les travaux de [GAM04], les hypothèsesd’erreurs et la configuration des bus sont les mêmes :

– le bus considéré est un bus TTCAN avec quatre noeuds, dont deux TimeMaster 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 deuxCycles de base, sur la dernière fenêtre du cycle, afin de permettre la réémission desmessages erronés. Etant donné qu’une erreur peut se produire au plus une fois tousles 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éeldur (un message arrivé en retard n’a plus de valeur), est respecté. Si l’on a besoind’un délai moindre, il suffit de multiplier le nombre de fenêtres à arbitrage parcycle.La matrice utilisée est celle présentée dans le tableau suivant :

MR EW EW EWMR EW EW AWMR EW EW EWMR EW EW AW

MR, Message de Référence,

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 :Tx_Enable = msg_error_size + Interframe_space

le temps entre deux messages de données, suffisant pour qu’une erreur sur un mes-sage ne perturbe pas l’émission du suivant.

FIG. 6 – Déroulement d’un cycle de base

Page 15: Rapport de PFE Validation temporelle d’architectures ...

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’initialisa-tion, 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.

Inter_Slot in_SlotSynchronising

Sync_Off

idle Msg_Ref_endMsg_Ref_being_sent2

error1

end_slot

Inter_Slot1

Msg_Ref_being_sent1

Initialisation

Erreur S3

Erreur dans un slot

0 1

4 5

6

7 8

9

10

11

2 3

Entre les Cycles de Base

Slot

FIG. 7 – Automate TSO

Ecoulement du temps Le temps local est mis à zéro lors du début du l’initia-lisation (ou de la réinitialisation), et au début de la réception d’un Message deRéférence.Dans une fenêtre d’émission, le moment de fin de fenêtre d’émission de messagede données, ainsi que de fin de fenêtre d’émission de trame d’erreur, est synchro-nisé par le temps global au niveau du CTC, en prenant en compte une gigue de 4temps bits (valeur arbitraire).A la fin de la fenêtre d’émission d’une trame d’erreur, chaque noeud reste une du-réeInterframe_space dans l’état Inter_Slot avant de passer au Slot suivant.

Page 16: Rapport de PFE Validation temporelle d’architectures ...

12

Si le noeud est à la fin du Cycle de Base, il attend Watch_Trigger dans l’état In-ter_Slot.

On considère que, dans notre système, il n’y a pas de fenêtre d’arbitrage desti-née à la transmission d’alarmes : toutes les fenêtres à arbitrage sont destinées à laretransmission des messages erronés.

Initialisation Le lancement de la simulation dans l’automate TSO est marquéepar le signaldepart. Ceci permet le départ simultané de la simulation pour l’en-semble des noeuds.Le TSO entre ensuite dans une phase de configuration (noeud ‘Sync_Off’). Le si-gnalconfig_doneest émis afin de signifier au MSA que la configuration du noeudest achevée et que celui-ci peut commencer à écouter le bus en vue d’émettre desMessages de Référence. Puis le TSO écoute sur le bus l’arrivée de Messages deRé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é dansle 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 sontinitialisés (numéro de colonne, temps de cycle à la fin de la réception du Mes-sage de Référence, numéro de cycle courant), et la transmission de données peutcommencer.

Erreur S3 Quel que soit l’état de l’automate, en cas d’erreur de type S3 (signalS3_node, noeud12), la configuration du noeud recommence, en retournant à l’étatSync_Off (noeud1).

Entre les Cycle de Base L’état par défaut entre deux Cycles de base, de mêmequ’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 deWatch_Trigger (transition vers le noeud4).Watch_Trigger peut prendre deux valeurs, Gap (notéWatch_Trigger_Gap) ounon Gap (notéWatch_Trigger).Le noeud étant en état ‘In_Schedule’ (node_state[X] == 4), la transition dunoeud4 vers le noeud5, à 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 (noeud6) àl’état Msg_Ref_end (noeud5), à la reception d’un Message de Référence, avant demettre à jour la valeur decycle_count et de passer dans l’état Inter_Slot (noeud6).

Page 17: Rapport de PFE Validation temporelle d’architectures ...

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êtred’émission, et la fin de l’émission d’une éventuelle trame d’erreur. Ceci corres-pond à 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 vec-teurcolumns. Chaque noeud met à jour le numéro de la colonne dans laquelle ilse trouve (column).Les moments de fin de fenêtre d’émission de message de données et de fin de fe-nêtre d’émission de trame d’erreur sont indiqués par des synchronisations initiéespar le CTC (signauxcol, 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 ducycle 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ésententre les différentes colonnes pour qu’une erreur sur un message n’affecte pas lemessage 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 à ar-bitrage.Les conditions d’erreur données comme hypothèse ont comme conséquence qu’ilne peut y avoir de conflit lors de la réémission, dans la mesure où il y a au plusune erreur tous les deux cycles de base, c’est à dire avec la même période que lesfenê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) (noeud10), et annule la réémission du Message norma-lement prévu dans CAN (Cancel_msg). En fait, selon la norme, il n’y a pas an-nulation du message, mais annulation du processus de réémission de CAN pourTTCAN, sauf dans quelques cas précis (Message de Référence, fenêtre à arbitragesuffisamment longue).

Par ailleurs, le noeud error1 (noeud 11) est atteint si un TSO reçoit un Messagede 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 TimeMaster potentiels : initialisation, attente d’émission et émission de Messages deRéférences (MR), erreur d’émission, gestion de Tx_Ref_Offset, numéro du cyclede base courant et configuration.

Page 18: Rapport de PFE Validation temporelle d’architectures ...

14

La figure 8 présente un aperçu de cet automate.

idle

before_msg_complete

Msg_Ref_sent

bigger_priority

lesser_priority

own_priority

In_Schedule

waiting4cancelingRM

0

2

3

4

7

9

10

12

13

6

8

5

1

11

Numero de cycleInitialisation

Configuration

Gestion de Tx_Ref_Offset

Erreur d’emission Attente d’emission Emission d’un MR

FIG. 8 – Automate MSA

Initialisation L’état initial est le noeud 0. L’initialisation consiste à attendre quele TSO associé ait terminé son initialisation (signalconfig_done). La transitionvers 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 buspendant une duréeWatch_Trigger_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 condi-tions est remplie :

– expiration deWatch_Trigger_Gap ; on tente d’émettre (transition versl’é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),

Page 19: Rapport de PFE Validation temporelle d’architectures ...

15

En cas de réception d’un Message de Référence, on passe dans l’état 11, qui cor-respond à l’écoute d’un Message de Référence émis par un autre Time Masterpotentiel.Pendant un Gap, le comportement est identique.

Entre deux Cycles de Base, le temps d’attente dans l’état ‘In_Schedule’ (noeud1) est la valeur deWatch_Trigger (variable qui représente la valeur de Watch_Trig-ger hors Gap). Les transitions pour sortir de cet état sont les mêmes que pour la find’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 si-gnal 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 dewait_timeavant de tenter d’émettre à nouveau un Message de Référence (et donc d’effectuerla transition vers le noeud 2).Ainsi, si un Message est correctement émis, le Time Master potentiel reçoit le si-gnalmsg_sent, aveccurrent_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 potentieltente d’émettre un Message (transition vers le noeud 2) dès qu’il voit la fin de latrame d’erreur sur le bus (réception deend_error aprèsRef_frame_sync).

Erreur d’émission En cas d’erreur lors de l’émission du Message de Référence(ici, c’est l’erreur debit_stuffing qui est utilisée en exemple), le Time Master an-nule l’émission du Message (Cancel_msg). Ceci permet de neutraliser la réémis-sion automatique existante dans le protocole CAN. Le noeud 12 est ‘C’ (commi-ted), car une seule transition ne peut contenir plusieurs synchronisations.A la fin de l’émission de la trame d’erreur (signalend_error), le Time Master po-tentiel retourne dans l’état ‘In_Schedule’, et attendTx_Trigger 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 selonla norme, et selon les mécanismes explicités dans le document ‘Etat de l’art : leprotocole TTCAN’, Mécanismes > Sélection du maître.

Pour la gestion de Tx_Ref_Offset, on a :Ref_Trigger_Offset = Delta_round− Tx_Ref_Offset.

Le noeud 7 (bigger_priority) et les transitions du noeud 7 vers le noeud 9 gèrentle cas des Time Master potentiels, qui n’ont pas émis le Message de Référence duCycle de Base courant, mais dont la priorité est supérieure à celle du Message deRéférence émis.Si Ref_Trigger_Offset > 0, alors on modifie :Ref_Trigger_Offset = 0.Si Ref_Trigger_Offset ≤ 0, alors on modifie :Ref_Trigger_Offset =

Page 20: Rapport de PFE Validation temporelle d’architectures ...

16

Ref_Trigger_Offset − 2 (décrémentation d’un temps bit, donc de deux uni-tés de temps UPPAAL).

Le noeud 8 (lesser_priority) et les transitions du noeud 8 vers le noeud 9 gèrentle cas des Time Master potentiels qui n’ont pas émis le Message de Référence duCycle de Base courant, et dont la priorité est inférieure à celle du Message de Ré-férence émis.Si Ref_Trigger_Offset ≤ 0, alors on modifie :Ref_Trigger_Offset =Initial_Ref_Trigger.

Le noeud 6 (own_priority) concerne le noeud qui a émis le Message de Réfé-rence du Cycle de Base courant.Si Ref_Trigger_Offset 6= 0, alors on modifieRef_Trigger_Offset = 0(Transition du noeud 5 vers le noeud 6). Les transitions de 6 vers 9 gèrent le nu-méro de Cycle (voir paragraphe correspondant).

Numéro de Cycle Le Time Master courant met à jour le numéro de Cycle deBase (Master_Cycle_Count) dans la matrice (transition entre le noeud 6 et lenoeud 9) : incrémentation de 1, sauf dans le cas oùCycle_Count_Max est atteint.Dans ce cas, le compteurMaster_Cycle_Count est remis à zéro.

Configuration Avant de recommencer à écouter sur le bus, les Time Master po-tentiels mettent à jour les paramètres d’attente,wait_time (en fonction deNext_is_Gap) et de Discontinuité (Disc_bit en fonction de set_disc_bit) (transi-tions 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 dechaque 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 dudéroulement du temps.

La transition vers le noeud 1 se fait donc à la réception du signalmsg_sent,aveccurrent_msg_is_ref == 1. La valeur decycletime est alors mise à jour(cycletime := msg_ref_size).

Page 21: Rapport de PFE Validation temporelle d’architectures ...

17

Inter_SlotErreur_frame

Waiting4Msg

0

1

4

32

Fin de Fenetre d’emission

Fin de la fenetre de trame d’erreur

FIG. 9 – Automate CTC

Fin de la fenêtre d’émission A la fin de la colonne courante (temps donné parcycletime == columns[column + 1]), le signalcol de fin de colonne est émispour 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 in-troduite pour chaque noeud. Un compteur (i) contient l’indice du noeud courant.Quandi == 3, le dernier signalcol 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 sansattendre à l’état Waiting4Msg (noeud 0).

Si l’on se trouve à l’intérieur du Cycle de Base (column < 2) ou à la fin duCycle de Base si le message émis est erroné (column == 2 and error_here ==1), on émet un signalend_Slotpour chaque noeud, avec la même gigue que lorsde l’émission du signalcol.

Il faut noter qu’il y a une gigue, mais pas de glissement de l’horloge : l’émissiondu deuxième signal n’est pas modifiée par la présence de gigue au premier signal.

Après la signalend_Slotde fin de trame d’erreur, on passe au Slot suivant sion 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 onattend un Message de Référence.

Page 22: Rapport de PFE Validation temporelle d’architectures ...

18

3.5 Observateurs

L’observateur doit être adapté au scénario considéré : un canal de synchronisa-tion commande la mise en route de l’horloge, un autre la fin de la phase étudiée. Sicette deuxième synchronisation a lieu trop tard, l’horloge a atteint la deadline et ily a deadlock.

3.6 Scénarios

Un automate implémente les différents scénarios de test et d’extraction debornes dans TTCAN. Les variables correspondantes doivent être modifiées dansles 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 etde fin de la phase à borner, ainsi que de modifier la valeur de la borne (une bornetrop petite étant cause de deadlock).

Les scénarios sont basés sur les évènements pouvant arriver : Gap, présenced’une discontinuite au deuxième Message de Référence, réémission du Messagede Référence du à une erreur, émission erronée d’un message quelconque de la ma-trice, 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 nonTime Master sur bus actif sans erreur, avec Gap. Ce scénario est composé de deuxphases, le lancement de la réinitialisation, et la resynchronisation du noeud avec lebus 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 signalS3_node, qui provoque la réinitialisation d’un noeud TTCAN (ici le noeud 1). Cesignal de réinitialisation est émisDelta_round−config_time+3 unités de tempsUPPAAL après le deuxième Message de Référence, de telle sorte que le noeud soiten phase de configuration lors de l’émission du Message de Référence suivant, etqu’il ne puisse pas le prendre en compte. Le noeud qui se réinitialise doit doncattendre 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 Mes-sage de Référence reçu par le noeud en cours de réinitialisation. Le mécanisme desynchronisation ne peut donc pas avoir lieu, car il nécessite la réception de deuxMessages de Référence consécutifs entre lesquels le temps se déroule de manièrecontinue. Le noeud doit donc attendre le Message de Référence suivant afin deréaliser sa synchronisation, et de pouvoir émettre des messages de données.

La figure 10 montre ce scénario.

Page 23: Rapport de PFE Validation temporelle d’architectures ...

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. Laborne 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 partie2.2, paragraphe Matrice d’émission, et le mécanisme de la discontinuité temporelledans 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 duMessage de Référence avant l’émission des messages de données. La réception dece message marque la synchronisation réussie du noeud avec le Time Master encours.

Le cas des Gap (intervalle long entre la fin d’un Cycle de Base et le début ducycle de base suivant) est également étudié, mais n’est pas présenté ici : il introduitun espace de temps indéfini entre deux Cycles de base, et les bornes temporellesdépendent alors du moment d’arrivée du signal de fin de Gap, par définition aléa-toire.

La réinitialisation met le noeud considéré dans l’état de configuration, et elleest suivie de la synchronisation du noeud concerné avec le Time Master déjà actifsur le bus. C’est donc le même scénario que l’initialisation sur bus actif.

Page 24: Rapport de PFE Validation temporelle d’architectures ...

20

Les tests effectués sur le modèle pour vérifier sa validité sont les suivants :

Test Résultat

E<>(TTCAN_Session_3.Msg_Ref_being_sent2 and Case.waiting4msg3)nonA[] not deadlock 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 quatrenoeuds, dont deux Time Master potentiels, sur le bus. Au moins deux Mes-sages 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 deRéférence suit dans un délaiconfig_time le signal de réinitialisation. Lesignal doit être émis plus de :

∆round − config_time + max(Ref_Trigger_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èsle début de l’émission du Message de Référence, et ne connait donc pas lavaleur deSync_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 leBit 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é tem-porelle. A la fin de ce Message de Référence, le noeud a fini sa réinitialisa-tion.

Les paramètres sont les suivants :

config_time, le temps nécessaire à la configuration du noeud avant qu’il puissecommencer 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 dediscontinuité, sont :

config_time Ref_msg_size ∆round δ borne10 206 1112 1 35512 206 1112 1 35432 158 1064 1 335110 158 1064 1 3359

Page 25: Rapport de PFE Validation temporelle d’architectures ...

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 deconfig_time avantle 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 cettevaleur 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 dutroisième Message de Référence de la phase de réinitialisation, et réémissions im-mé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 quatrenoeuds, dont deux Time Master potentiels, sur le bus. Au moins deux Mes-sages 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 deRéférence suit dans un délaiconfig_time le signal de réinitialisation. Lenoeud sort alors du mode de configuration immédiatement après le début del’émission du Message de Référence, et ne connait donc pas la valeur deSync_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 deDiscontinuité à 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 quel’erreur utilisée dans le modèle (bit stuffing) engendre un message d’erreur de 44unités (22 temps bits).

Page 26: Rapport de PFE Validation temporelle d’architectures ...

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 dediscontinuité, sont :

config_time Ref_msg_size ∆round error_frame_size δ borne10 158 1064 44 1 37632 158 1064 44 1 37552 206 1112 44 1 404310 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.

Page 27: Rapport de PFE Validation temporelle d’architectures ...

23

5 Comparaison avec TTA

5.1 Particularités de TTCAN

TTCAN présente, par rapport à TTA, deux particularités, qui lui offrent de laflexibilité, 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 deuxCycles 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 :Tx_Trigger_Gap

La présence d’un Gap lors d’un scénario modifie donc la borneb de la manièresuivante :

b = b + Tx_Trigger_Gap−∆round.

Discontinuité La conséquence d’une discontinuité est l’imposibilité d’utili-ser le temps global au moment de la discontinuité pour calculer le glissement relatifde 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 desmessages, il est donc nécessaire d’attendre le Message de Référence suivant pourfinir cette initialisation.La présence d’une discontinuité lors d’un scénario modifie donc la borneb de lamaniè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 doncde comparer la valeur des bornes de TTA à celles de TTCAN sans Gap, et sansdiscontinuité 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_sizeavec erreur :∆round + 2 ∗Ref_Msg_size + Error_frame_size

Page 28: Rapport de PFE Validation temporelle d’architectures ...

24

Analyse La synchronisation d’horloge dans TTA dépend de la durée de la ma-trice d’émission. Dans TTCAN, elle dépend principalement de la durée du cycle debase. A priori, la synchronisation sera donc plus rapide en TTCAN, en particulierpour 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 2ou plusieurs noeuds en TTA, un seul ou plus en TTCAN, et le passsage à l’étatdit actif, c’est-à-dire quand le noeud est susceptible de commencer à émettre desmessages.On considère que l’ordonnancement en TTA et en TTCAN est le même : mêmenombre 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êtresd’émission.On cherche donc la valeur deτwcsup, le temps d’initialisation en pire cas (wake upstart 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, etdu passage à l’état actif. On considère uniquement le temps avec erreur [?].τwcsup = τ listen

max−1 + 2 ∗ τ coldstartmax−1 + ∆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).

Tx_Trigger_Gap , ∆round + n ∗m ∗ Ref_msg_size ≤ Tx_Trigger_Gap ≤2 ∗ 1016 − 1 (ou temps maximal de Gap prévu lors de la conception, cequi permet d’avoir une initialisation beaucoup plus rapide). Dans le cas duminimum, il s’agit du temps d’un round TDMA allongé du temps pendant

Page 29: Rapport de PFE Validation temporelle d’architectures ...

25

lequel les noeuds tenterons de réémettre le Message de Référence avant lelancement d’une procédure de traitement d’erreur. Le maximal est le tempsmaximal 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 unTime Master potentiel avec le lancement d’un procédure d’erreur.

Initial_Ref_Offset, l’offset par défaut de chaque Time Master potentiel, c’està dire le temps d’écoute qui s’ajoute àTx_Trigger_Gap. Il est différentpour chaque noeud, et fonction de la priorité du noeud.

Ref_Trigger_Offset, la valeur effective de l’offset pour le noeud considéré.−127 ≤ Ref_Trigger_Offset ≤ 127.

La borne est composée du temps d’écoute du bus, et du mécanisme de synchro-nisation.Sans erreur :τwcsup = τ listen + τ synchro

= config_time + Tx_Trigger_Gap + min(Initial_Ref_Offset)+∆round + Ref_msg_size

Avec erreur :τwcsup = τ listen + τ synchro

= config_time + Tx_Trigger_Gap + min(Initial_Ref_Offset)+∆round + 2 ∗Ref_msg_size + error_frame_size

Analyse On néglige le temps de configuration, faible comparé au temps d’écoutesur 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’unou l’autre protocole pour l’initialisation.Si TTCAN est configuré de manière à pouvoir supporter de grands Gaps, le tempsd’écoute sur le bus est très grand et l’initialisation est beaucoup plus longue quesur TTA.Par contre, si on considère un système sans Gap, TTCAN est plus performant queTTA à condition que le nombre de fenêtres d’émission par round TDMA soit su-pé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 lefonctionnement du véhicule, la durée de l’initialisation peut éventuellement deve-nir 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-

Page 30: Rapport de PFE Validation temporelle d’architectures ...

26

lisation.

TTCAN Réinitialisation d’un noeud après erreur, ou l’initialisation d’un nou-veau 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 ex-plicite pendant l’écoute du bus. La réintégration correspond aux cas ‘MembershipLoss’, ou ‘Host error’ ou ‘host life-sign not update’.

∆round + 2 ∗∆Slot −∆TP + π

TTCAN La borne de réintégration correspond à une erreur d’émission S2, quiprovoque la suspension de l’émission de l’ensemble des messages.

2 ∗Nm ∗∆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 ef-fet, la réintégration en TTA est causée par une erreur symétrique ou de faute by-zantine, 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 etune suspension totale de la transmission des messages.Il faut noter également que la borne de TTCAN n’est valable que si la faute n’estpas périodique de périodeNm ∗∆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 esten état d’erreur S2, l’ensemble des noeuds se taisent, et le temps de réintégrationest plus long.

Pour le cas où la réintégration est causée en TTA par une erreur de l’hôte (dutype ‘host life-sign not update’), la borne correspondante en TTCAN est celle dela réinitialisation.Le terme majeur de la borne en TTA est∆round, alors que pour TTCAN c’est2 ∗ ∆round. La réintiailisation est donc environ plus longue d’un round TDMA

Page 31: Rapport de PFE Validation temporelle d’architectures ...

27

pour TTCAN que pour TTA, les autres termes étant en première approximationnégligeables.

Pour affiner la conpréhension de ces mécanismes, il sera indispensable d’étu-dier la possibilité de fautes byzantines en TTCAN.

5.2.5 Accusé de réception

TTA l’accusé de réception est implicite. En cas d’erreur, une trame non acquitéese manifeste par l’apparition d’un clique. La borne est donc celle de la détectiond’un clique :

∆round + 2 ∗∆Slot + π

TTCAN l’accusé de réception est explicite, c’est l’accusé de réception de CAN.

Analyse L’acquitement en TTCAN est explicite, et a donc lieu immédiatementaprès l’émission de la trame de données. Au contraire, l’acquitement de TTA estimplicite, il nécessite donc d’observer le comportement du système lors des tramessuivantes, et et donc plus long. En particulier lors d’erreur, où la borne correspondà la détection d’un clique, le temps nécessaire est supérieur à un round TDMA.

5.2.6 Communication Blackout Check

TTA La borne avec faute permanente de détection du ‘Communication blackout’est :

∆round + 2 ∗∆Slot + π

TTCAN Il n’y a pas de service correspondant au ‘Communication blackout’ enTTCAN. Il faut donc attendre la suspension de l’émission des messages de donnéespar erreur S2, ou l’état CAN_bus_Off (erreur S3), pour identifier un Communica-tion Blackout check.L’erreur S2 est déclenchée pour MSC = 7. MSC est un compteur incrémenté àchaque trame erronée reçue. En cas de faute permanente, il faut donc :

7 ∗Nm ∗∆round

avant qu’une erreur S2 soit lancée.Quant à l’erreur CAN_bus_Off, il s’agit de 256 trames d’erreurs consécutives auminimum. Le temps exprimé en fonction de∆round dépend donc du nombre deslots par round TDMA.

Analyse La détection d’un ‘Communication blackout’ existe en TTA comme enTTCAN, mais se base en TTCAN sur des compteurs destinés à une evaluation plusglobale de la qualité de la transmission. Ce service est donc bien plus performanten TTA.

Page 32: Rapport de PFE Validation temporelle d’architectures ...

28

5.3 Bornes spécifiques

5.3.1 TTCAN

TTCAN n’offre pas, contrairement à TTA, de services spécifiques. Mais plu-sieurs comportements, qui influent sur les performances du systèmes, ne se re-trouvent pas en TTA.Les valeurs des bornes sont présentées dans la partie B.

Initialisation / réinitialisation d’un Time Master La présence d’un Time Mas-ter est indispensable en TTCAN, mais pas en TTA, où les différents mécanismessont réalisés par les services, et sont implicites.

Variation de la durée d’un cycle L’absence de Message de Référence en TTApermet d’obtenir des cycles de durée fixe, ce qui n’est pas le cas en TTCA.On considère le cas sans Gap. En cas de Gap, il faut ajouter à la borne :

Tx_Trigger_Gap−∆round

si le Gap se situe à la fin du Cycle de base courant, et :∆round − Tx_Trigger_Gap

si le Gap se situe à la fin du Cycle de base précédent.

Borne sans erreur :max(Initial_Ref_Offset) + 127

Borne avec erreur :max(Initial_Ref_Offset) + 127 + Ref_Message_size + Error_Frame_size

5.3.2 TTA

TTA offre un certain nombre de services qui lui sont spécifiques.

Clique avoidance La borne correspond à la détection d’un clique, après une fautebyzantine, sans faute lors de la détection du clique.

∆_round + 2 ∗∆Slot + π

Membership loss La borne correspond à la détection d’une perte de member-ship, générée par une faute symétrique, sans faute lors de la détection de la pertede membership.

2 ∗∆Slot + ∆TP + ∆PRP + π

Mode change Le temps nécessaire pour effectuer un ‘Mode Change’ est :∆cycle + ∆round + ∆PSP + π

Page 33: Rapport de PFE Validation temporelle d’architectures ...

29

5.4 Récapitulatif

Le tableau suivant donne pour chaque borne le protocole qui est a priori leplus rapide. Les résultats sont à considérer avec précaution, en fonction de chaquesituation particulière.

TTA TTCANclock synchronisation X

initialisationréintégration X

accusé de réception X

Communication Blackout X

Page 34: Rapport de PFE Validation temporelle d’architectures ...

30

6 Conclusion

TTCAN est un protocole récent : en effet, il a été présenté en 2002. Du faitde sa simplicité, le protocole lui-même a été validé, il est donc possible d’affirmerqu’il est fiable.

Cependant, la comparaison avec TTA montre que l’absence de services avancésdestinés à gérer les différents cas d’erreur est préjudiciable. Il sera donc utile deles implémenter dans une couche applicative. Il faut noter la bonne performancede TTCAN grâce aux mécanismes explicites de CAN, par exemple le mécanismed’accusé de réception. En TTA, ces mécanismes sont gérés de manière implicite,et donc plus long en cas d’erreur.

TTCAN est donc un protocole fiable, mais relativement peu développé enterme de services. Il est nécessaire de lui adjoindre des mécanismes supplémen-taires. Voire même de la modifier, pour palier à l’inconvénient majeur des proto-coles Time-Triggered : le manque de flexibilité.

FTTCAN réalise cette modification. Reste à valider le comportement d’un pro-tocole qui introduit, par la flexibilité, une explosion combinatoire d’états possibledans le système, et pose donc de réels problèmes d’analyse.

Page 35: Rapport de PFE Validation temporelle d’architectures ...

31

Références

[DRAFT03] Road vehicles _ Controller area network (CAN) _ Part 4 : Time trig-gered communication ; Working Draft ISO 11898, 08-2003.

[ISO93] International Standard Organisation, ISO 11898. Road Vehicles-Interchange of digital information-Controller Area Network (CAN) for hignspeed communication, 1993.

[KG94] H. Kopetz, G. Grünsteidl. Ttp, a protocol for fault tolerant real-time sys-tems. IEEE Computer, 27(1), 14-23, January 1994.

[HMFH00] CAN Network with Time Triggered Communication, F. Hartwitch, B.Mueller, T. Fuehrer, R. Hugel, Robert Bosch GmbH ; Proceedings 7th Inter-national CAN Conference ; 2000.

[GAM04] Temporal bounds for TTA : Validation ; K. Godary, I. Augé-Blum, A.Mignotte, DIPES, 08-2004.

[GAM] Model Abstraction for the Temporal Validation of TTA with UPPAAL, K.Godary, I. Augé-Blum, A. Mignotte,

[LH01] TTCAN : a new time-triggered controller area network, G. Leen, D. Hef-fernan, 12.2001, Elsevier Science B.V,

[PL00] Uppaal2k, Paul Pettersson and Kim G. Larsen, Bulletin of the EuropeanAssociation for Theoretical Computer Science, volume 70, pages 40-44,2000.

[LH02] Leen, G. and Heffernan, D., Formally Verifying Aspects of Time-Triggered Controller Area Network. (Phases 1 and 2a), Technical report,Main Library, University of Limerick.

[TB03] ] J-C. Tournier and J-P Babau, Communication Protocol Evaluation forEmbedded Systems, ICIT’03 International Conference on Industrial Techno-logy, oct. 2003.

Page 36: Rapport de PFE Validation temporelle d’architectures ...

32

A Les automates du modèle

A.1 Cycle Time Controller (CTC)

La figure 12 présent l’automate du CTC, avec ses principales composantes.Les figures 13 et 14 présentent ces composantes : fin de la fenêtre d’émission dedonnées et fin de la fenêtre d’émission de la trame d’erreur.

Inter_SlotErreur_frame

Waiting4Msg

0

1

4

32

Fin de Fenetre d’emission

Fin de la fenetre de trame d’erreur

FIG. 12 – Automate CTC

i:=00

1 2 3

Waiting4Msg

gigue==2,i<3col[i]!gigue:=0,i++

cycletime==columns[column+1]col[i]!i++ col[i]!

i==3cycletime:=msg_ref_sizemsg_sent?

gigue<=2cycletime<=columns[column+1]

Erreur_framecurrent_msg_is_ref==1

Inter_Slot

gigue:=0,

FIG. 13 – Automate CTC : fin de la fenêtre d’émission de données

Page 37: Rapport de PFE Validation temporelle d’architectures ...

33

1 2

3

4

0

cycletime>=columns[column+1]column:=0

error_here==0,column==2,

i==3,column==2,error_here==1end_Slot[i]!i:=0,column:=0

i:=0column++,end_Slot[i]!

i==3,column<2

column<2||(column==2&&error_here==1),cycletime==columns[column+1]+error_frame_sizeend_Slot[i]!gigue:=0,i++

gigue==2,i<3end_Slot[i]!gigue:=0,i++

Erreur_frame

cycletime<=columns[column+1]+error_frame_size

Inter_Slot

Waiting4Msg

gigue<=2

FIG. 14 – Automate CTC : fin de la fenêtre d’émission de trame d’erreur

A.2 Time Schedule Organiser (TSO)

La figure 16 présente l’automate modélisant le TSO et ses différentes compo-santes.Les figure 17 à 20 détaillent chacune des composantes : initialisation, temps entreles cycles de base, déroulement d’un slot, erreur dans un slot, erreur de type S3.

Page 38: Rapport de PFE Validation temporelle d’architectures ...

34

Inter_Slot in_SlotSynchronising

Sync_Off

idle Msg_Ref_endMsg_Ref_being_sent2

error1

end_slot

Inter_Slot1

Msg_Ref_being_sent1

Initialisation

Erreur S3

Erreur dans un slot

0 1

4 5

6

7 8

9

10

11

2 3

Entre les Cycles de Base

Slot

FIG. 15 – Automate TSO

Inter_SlotSynchronising

localtime<=Init_Watch_Trigger

Sync_Offlocaltime<=config_time

idle Msg_Ref_endMsg_Ref_being_sent2localtime<=wait_time

Msg_Ref_being_sent1

msg_sent?n_column[X]:=column,node_state[X]:=4,localtime:=msg_ref_size

current_msg_is_ref ==1,Disc_Bit==0,node_state[X]==2

node_state[X]:=1,localtime:=0

depart?

node_state[X]:=2

localtime==config_timeconfig_done[X]!

msg_sent?current_msg_is_ref ==1

localtime:=msg_ref_size,wait_time:=Watch_Trigger

cycle_count:=Master_Cycle_Count,Tx_Enable:=interframe_space

bornes[X]!

Ref_frame_sync?current_msg_is_ref==1

0

1

23

4 5 6

FIG. 16 – Automate TSO : initialisation

Page 39: Rapport de PFE Validation temporelle d’architectures ...

35

Inter_Slot

localtime<=columns[column]+Tx_Enable

Msg_Ref_endMsg_Ref_being_sent2localtime<=wait_time

msg_sent?current_msg_is_ref ==1

column:=0,n_column[X]:=column,localtime:=msg_ref_size

cycle_count:=Master_Cycle_Count,Tx_Enable:=interframe_space

bornes[X]!

column==3,Next_is_Gap==1column:=0,wait_time:=Watch_Trigger_Gap−3*Delta_round

current_msg_is_ref ==1,node_state[X]==4msg_sent?

n_column[X]:=column,localtime:=msg_ref_size

64 5

FIG. 17 – Automate TSO : entre les Cycles de base

Inter_Slot

localtime<=columns[column]+Tx_Enable

in_Slotend_slot

Inter_Slot1

send_msg[X]!

Trigger[cycle_count][column]==100,localtime==columns[column]+Tx_Enable,bus_state==−1

column++,n_column[X]:=column,Tx_Enable := error_frame_size+interframe_space,error_here:=0

column<2

Trigger[cycle_count][column]==200||Trigger[cycle_count][column]==300,localtime==columns[column]+Tx_Enable,bus_state==−1

column==2Tx_Enable:=Watch_Trigger−Delta_round,column++,n_column[X]:=column,error_here:=0

localtime==columns[column]+Tx_Enable,Trigger[cycle_count][column]==400,msg_2_resend==0

localtime==columns[column]+Tx_Enable,Trigger[cycle_count][column]==400,msg_2_resend==1,bus_state==−1

send_msg[X]!msg_2_resend:=0

column!=2||error_here==1col[X]?

end_Slot[X]?

error_here==0,column==2

col[X]?

8

9

67

FIG. 18 – Automate TSO : déroulement d’un slot

Page 40: Rapport de PFE Validation temporelle d’architectures ...

36

in_Slot

error1

end_slot

send_msg[X]!

Trigger[cycle_count][column]==100,localtime==columns[column]+Tx_Enable,bus_state==−1

current_msg_is_ref ==1msg_sent? bit_stuff_error?

Trigger[cycle_count][column]==100

msg_2_resend:=1,error_here:=1

Cancel_msg[X]!

7 8

10

11

FIG. 19 – Automate TSO : erreur dans un slot

Inter_Slot in_SlotSynchronising

Sync_Off

Msg_Ref_endMsg_Ref_being_sent2

error1

end_slot

Inter_Slot1

Msg_Ref_being_sent1

node_state[X]:=2

localtime==config_timeconfig_done[X]!

S3_node[X]?

S3_node[X]?S3_node[X]?

S3_node[X]?

localtime:=0,msg_2_resend:=0,column:=0

S3_node[X]?

1 2 3 4 5 6 7

8

9

10

11

FIG. 20 – Automate TSO : erreur de type S3

Page 41: Rapport de PFE Validation temporelle d’architectures ...

37

A.3 Master State Administrator (MSA)

La figure 21 présente l’automate modélisant le MSA et ses différentes compo-santes.Les figure 22 à 25 détaillent chacune des composantes : initialisation, attente d’émis-sion, émission, erreur d’émission, configuration, gestion du numéro de cycle, ges-tion de l’offset.

idle

before_msg_complete

Msg_Ref_sent

bigger_priority

lesser_priority

own_priority

In_Schedule

waiting4cancelingRM

0

2

3

4

7

9

10

12

13

6

8

5

1

11

Numero de cycleInitialisation

Configuration

Gestion de Tx_Ref_Offset

Erreur d’emission Attente d’emission Emission d’un MR

FIG. 21 – Automate MSA

Page 42: Rapport de PFE Validation temporelle d’architectures ...

38

0

2

4

1

3

config_done[X]?c:=0,

S3_node[X]?S3_node[X]?

In_Schedule

before_msg_complete

idle

wait_time:=Tx_Trigger_Gap+Initial_Ref_Offset[X]

2

3

4

5

1

11

c<=wait_time frame_sync:=1Ref_frame_sync?

c:=msg_ref_sizemsg_sent?current_msg_is_ref ==1

before_msg_complete

In_Schedule

c==wait_time,frame_sync==0

c==wait_time,frame_sync==1frame_sync:=0,wait_time:=msg_ref_size,c:=0

end_error?current_msg_is_ref ==1

Msg_Ref_sent

FIG. 22 – Automate MSA : initialisation, attente d’émission

2

3

412

13

5

1

11msg_sent?c:=msg_ref_size

put_next_is_gap==0send_msg[X]!current_msg_is_ref :=1,n_column[X]:=3,Next_is_Gap:=0

c==wait_time,frame_sync==0

Next_is_Gap:=1n_column[X]:=3,current_msg_is_ref :=1,send_msg[X]!put_next_is_gap==1

c:=msg_ref_size

In_Schedule

waiting4cancelingRM before_msg_complete

current_msg_is_ref ==1end_error?

bit_stuff_error?Ref_frame_sync!

msg_sent?current_msg_is_ref ==1

Msg_Ref_sent

c<=wait_time

2

3

412

13

1

bit_stuff_error?Cancel_msg[X]!

end_error?

wait_time:=0c:=0,

c<=wait_time

In_Schedule

before_msg_completewaiting4cancelingRM

FIG. 23 – Automate MSA : émission, erreur d’émission

10

1

set_disc_bit==1Disc_Bit:=1

Next_is_Gap==1

wait_time:=Tx_Trigger_Gap+Tx_Ref_Trigger[X]−Delta_roundwait_time:=Tx_Ref_Trigger[X]

Next_is_Gap==0

Disc_Bit:=0set_disc_bit==0

c<=wait_time

In_Schedule

9

9

6

Master_Cycle_Count:=0Master_Cycle_Count==Cycle_Count_Max

Master_Cycle_Count<Cycle_Count_MaxMaster_Cycle_Count++

own_priority

FIG. 24 – Automate MSA : configuration et gestion du numéro de cycle

Page 43: Rapport de PFE Validation temporelle d’architectures ...

39

7

9

6

8

5

11

Tx_Ref_Trigger[X]:=Delta_round + Initial_Ref_Offset[X]Tx_Ref_Trigger[X]<=Delta_round

Tx_Ref_Trigger[X]>Delta_round

Tx_Ref_Trigger[X]:=Delta_roundTx_Ref_Trigger[X]>Delta_round

Tx_Ref_Trigger[X]:=Tx_Ref_Trigger[X]−2Delta_round−Tx_Ref_Trigger[X]<127Tx_Ref_Trigger[X]<=Delta_round,

Delta_round−Tx_Ref_Trigger[X]>=127

Cancel_msg[X]!msg_on_bus_priority>msg_priority[X]

msg_on_bus_priority<msg_priority[X]Cancel_msg[X]!

current_msg_is_ref :=0wait_time:=Delta_round,Tx_Ref_Trigger[X]:=Delta_round,msg_on_bus_priority==msg_priority[X]

Next_is_Gap==1wait_time:=Tx_Trigger_Gap+Initial_Ref_Offset[X]Next_is_Gap==0

wait_time:=Tx_Ref_Trigger[X]

own_priority

lesser_priority

bigger_priority

Msg_Ref_sent

FIG. 25 – Automate MSA : gestion de l’offset

Page 44: Rapport de PFE Validation temporelle d’architectures ...

40

B Les bornes de TTCAN

Les résultats obtenus pour les mécanismes de TTCAN sont les suivants :

B.1 Synchronisation

La synchronisation permet aux différents noeuds du bus d’émettre les mes-sages de données en fonction du déroulement d’un temps global. Elle nécessite laréception par le noeud qui veut se synchroniser de deux Messages de Référenceconsécutifs sans discontinuité temporelle.

Synchronisationsans erreur, sans bit de discontinuité∆round + Ref_Message_size

sans erreur, avec bit de discontinuité2 ∗∆round + Ref_Message_size

avec erreur, sans bit de discontinuité∆round + 2 ∗Ref_Message_size + Error_frame_size

avec erreur, avec bit de discontinuité2 ∗∆round + 2 ∗Ref_Message_size + Error_frame_size

B.2 Initialisation

La borne d’initialisation sur bus vide est le temps nécessaire à un noeud, TimeMaster potentiel, pour émettre des messages de données, sachant qu’il est éteint,et donc désynchronisé, au début du processus. Le noeud doit écouter le bus pours’assurer qu’aucune communication n’est en cours, puis se synchroniser.

Initialisationsans erreur, avec bit de discontinuitéconfig_time + Tx_Trigger_Gap + min(Initial_Ref_Offset) + 2 ∗∆round + Ref_msg_size

sans erreur, sans bit de discontinuitéconfig_time + Tx_Trigger_Gap + min(Initial_Ref_Offset) + ∆round + Ref_msg_size

avec erreurs, avec bit de discontinuitéconfig_time + Tx_Trigger_Gap + min(Initial_Ref_Offset) + 2 ∗∆round

+3 ∗Ref_msg_size + 2 ∗ error_frame_size

avec erreurs, sans bit de discontinuitéconfig_time + Tx_Trigger_Gap + min(Initial_Ref_Offset) + ∆round

+2 ∗Ref_msg_size + error_frame_size

Page 45: Rapport de PFE Validation temporelle d’architectures ...

41

B.3 Réinitialisation

La réinitialisation concerne un noeud qui connait une erreur grave, par exemplela mort de l’application. Ce noeud doit donc refaire l’ensemble du processus d’ini-tialisation, sachant qu’il peut se synchroniser grâce aux communications déjà pré-sentes sur le bus.

Reinitialisationsans Gap, sans erreur, avec bit de discontinuitéconfig_time + 3 ∗∆round + Msg_ref_size− δ

sans Gap, sans erreur, sans bit de discontinuitéconfig_time + 2 ∗∆round + Msg_ref_size− δ

sans Gap, avec erreurs, avec bit de discontinuitéconfig_time + 3 ∗∆round + 3 ∗Msg_ref_size + 2 ∗ error_frame_size− δ

sans Gap, avec erreurs, sans bit de discontinuitéconfig_time + 2 ∗∆round + 2 ∗Msg_ref_size + error_frame_size− δ

avec Gap, sans erreur, avec bit de discontinuitéconfig_time + Tx_Trigger_Gap + 2 ∗Deltaround + Ref_msg_size− δ

avec Gap, sans erreur, sans bit de discontinuitéconfig_time + Tx_Trigger_Gap + Deltaround + Ref_msg_size− δ

avec Gap, avec erreurs, avec bit de discontinuitéconfig_time + Tx_Trigger_Gap + 2 ∗Delta_round + 3 ∗Ref_msg_size+2 ∗msg_error_size− δ

avec Gap, avec erreurs, sans bit de discontinuitéconfig_time + Tx_Trigger_Gap + Delta_round + 2 ∗Ref_msg_size+msg_error_size− δ

B.4 Initialisation/Réinitialisation d’un Time Master

On s’intéresse au temps nécessaire à un noeud Time Master entre le momentoù il commence son initialisation (ou sa réinitialisation), et celui où il peut émettredes Messages de Référence.

Initialisation / Réinitialisation d’un Time MasterInitialisation sans erreurconfig_time + Tx_Trigger_Gap + min(Initial_Ref_Offset)Initialisation avec erreurconfig_time + Tx_Trigger_Gap + min(Initial_Ref_Offset)+Ref_msg_size + error_frame_size

Réinitialisation sans erreurconfig_time + 2 ∗∆round

Réinitialisation avec erreurconfig_time + 2 ∗∆round + Ref_msg_size + error_frame_size

Page 46: Rapport de PFE Validation temporelle d’architectures ...

42

B.5 Emission

L’un des paramètres les plus importants des protocoles de communication estle temps entre la production d’un message de données, et son émission, notammenten cas d’erreur.

Emissionsans erreurTC − TP + Tx_Enable + Message_size

avec :0 ≤ TC − TP ≤ Nm ∗∆round

avec erreurTC − TP + ∆e→a + Tx_Enable + Message_size

avec :∆Slot ≤ ∆e→a ≤ Na ∗∆round −Ref_msg_size−∆Slot

B.6 Variation de la durée d’un cycle

L’un des problèmes de TTCAN est la non régularité de la durée d’un roundTDMA. On s’intéresse à ses variations.

Page 47: Rapport de PFE Validation temporelle d’architectures ...

43

Variation de la durée d’un cyclesans Gap Gap à la fin du BC précédentGap à la fin du BC courant

pas d’erreur,Time Mastercourant

0 ∆round−Tx_Trigger_Gap Tx_Trigger_Gap−∆round

Changementde TimeMaster (1)

−127 ≤ b ≤max(Initial_Ref_Offset)

∆round −Tx_Trigger_Gap − 127 ≤b ≤ ∆round −Tx_Trigger_Gap +max(Initial_Ref_Offset)

Tx_Trigger_Gap −∆round − 127 ≤ b ≤Tx_Trigger_Gap −∆round +max(Initial_Ref_Offset)

Changementde TimeMaster (2)

−max(Initial_Ref_Offset) ≤b ≤ 127

∆round −Tx_Trigger_Gap −max(Initial_Ref_Offset ≤b ≤ ∆round −Tx_Trigger_Gap + 127

Tx_Trigger_Gap −∆round −max(Initial_Ref_Offset) ≤b ≤ Tx_Trigger_Gap −∆round + 127

Changementde TimeMaster, pirecas

max(Initial_Ref_Offset)+127

∆round −Tx_Trigger_Gap +max(Initial_Ref_Offset)+127

Tx_Trigger_Gap −∆round +max(Initial_Ref_Offset)+127

Récupérationd’erreur S2

−127 ∆round −Tx_Trigger_Gap− 127

Tx_Trigger_Gap −∆round − 127

avec erreur −Ref_Message_size −Error_Frame_size

∆round −Tx_Trigger_Gap −Ref_Message_size −Error_Frame_size

Tx_Trigger_Gap −∆round −Ref_Message_size −Error_Frame_size

B.7 Reprise d’erreur S2

En cas d’erreur S2, et de suspension de l’émission des messages de données,le temps nécessaire pour reprendre la transmission est :

Reprise d’erreur S2b ≥ 2 ∗Nm ∗∆round