Application au cas OSEK-VDX

Transcription

1 Systèmes d exploitation temps réel - Application au cas OSEK-VDX Yvon Trinquet IRCCyN - UMR CNRS 6597 École Centrale de Nantes, École des Mines de Nantes Université de Nantes Équipe «Systèmes Temps Réel» Yvon.Trinquet@irccyn.ec-nantes.fr 1

2 Plan Généralités Le noyau temps réel OSEK/VDX OS La communication OSEK/VDX COM Évolutions, modèles d application 2

3 Exemple d architecture fonctionnelle (ou logicielle) d une application Nmax_A Nmin_A CTRL_Bac_A Valim_A Nmax_B Nmin_B CTRL_Bac_B Valim_B Ordre_Fab Req_Fab Utilisateur Superviseur Etat_Fab CR_Fab Req_Pains Niveau_C Mot_H D_Pain CTRL_TR Fin_Pains CTRL_Bac_C Vvid_B Vvid_A Mot_TR Nmax_C Vvid_C Légende : Evénement : Variable partagée : Boîte aux lettres : une action 3

4 Quelle implémentation? choix de la configuration matérielle contraintes topologiques contraintes de sûreté de fonctionnement contraintes temporelles lien «Tâche Événement activeur» approche «synchrone» approche «asynchrone» 4

5 la démarche synchrone : Hypothèse «temps nul» pour les calculs et les réactions Simultanéité possible des événements Cadre formel vérification formelle mais le «monde» est asynchrone la démarche asynchrone : Les calculs prennent du temps Les événements ne sont jamais simultanés Il faut accepter la préemption et ordonnancer, protéger les ressources partagées Modèles beaucoup plus complexes, plus durs à vérifier Un support d exécution : l exécutif temps réel 5

6 Types d exécutifs les exécutifs «généralistes» beaucoup de produits commerciaux (VxWorks ) un standard OSEK-VDX pour de petits systèmes embarqués les exécutifs Unix TR approche Posix (standards IEEE) : extensions temps réel pour Unix (ordonnancement, sémaphores, multi-threads ) approche Linux temps réel : RT-Linux, RTAI les exécutifs «recherche» : Mars (Kopetz), Spring kernel (Stankovic), ARTS (Lehoczky) 6

7 L exécutif et l application Application mesures Tâche Tâche Tâche Tâche commandes Interface machine Appels de services virtuelle d'exécution horloge événements issus du procédé Agence de gestion du temps Agence de gestion des événements Agence de gestion des tâches (Interruptions) Ordonnanceur Exécutif 7

8 contexte d OSEK/VDX (1) celui de «l électronique» embarquée dans les véhicules contraintes temps réel (dures et souples) : (powertrain, chassis, body, telematics) sûreté de fonctionnement élevée mais mission en principe interruptible avènement du X by Wire 8

9 contexte d OSEK/VDX (2) support matériel minimal (peu de RAM, ECU 8 et 16 bits) architecture distribuée autour de réseaux : CAN, LIN puis TTP/C, FlexRay fonctions transversales : inter-opérabilité des sous-systèmes pour réaliser la fonction flexibilité de l architecture : ajout de fonctions, portabilité et réutilisabilité des fonctions logicielles) Et tout cela au moindre coût! 9

10 OSEK/VDX : historique Proposition du groupe OSEK, constitué : de constructeurs (BMW, DaimlerChrysler, Renault, PSA, etc.) d équipementiers (Bosch, Siemens, etc.) d universitaires (Univ. Karlsruhe) Fusion des projets OSEK (Allemand) et VDX (GIE PSA-Renault) Travaux commencés en 1995 pour OSEK, vers 1992 pour VDX 10

11 OSEK/VDX : OSEK/VDX OS version 2.2, septembre 2001 noyau du système d exploitation OSEK/VDX COM version 3.0.1, janvier 2003 services pour la communication OSEK/VDX NM version Mai 2000 gestion et surveillance du réseau OSEK/VDX OIL version janvier 2003 langage de description des applications Le site Web de référence : www. osek-vdx. org 11

12 Le noyau temps réel OSEK-VDX OS 12

13 Principaux services d OSEK/VDX OS Services pour les tâches Services de synchronisation (événements) Services d exclusion mutuelle Services pour les phénomènes récurrents (compteurs et alarmes) Service pour la communication (dans OSEK/VDX COM) Services pour la gestion des interruptions Services systèmes et gestion des erreurs Tous les objets sont statiques : - pas de création dynamique d objets - pas de suppression dynamique d objets 13

14 Les tâches (1) Tâche = objet actif de l application La tâche «Basique» : module sans point bloquant doit se terminer 3 états : suspended / ready / running activations multiples : mise en file des requêtes d activation si la tâche est active (pas d instanciation) Running La tâche a le processeur terminate Diagramme des états preempt start Suspended La tâche est inactive Ready activate La tâche est inactive 14

15 Les tâches (2) Task T1 { Activate (T2) TerminateTask () } ActivateTask TerminateTask ChainTask Schedule Task T3 { TerminateTask () } Task T2 { ChainTask (T3) } + d autres services 15

16 Les tâches (3) La tâche «Étendue» : un ou plusieurs modules peut attendre une occurrence d événement 4 états : waiting en plus Diagramme des états wait Running La tâche a le processeur terminate La tâche est en attente Waiting preempt start Suspended La tâche est inactive release Ready activate La tâche est inactive 16

17 ordonnancement (1) Les tâches (4) priorité fixe non modifiable (la valeur 0 est la plus faible priorité) 3 modes d ordonnancement : préemptif : toutes les tâches en mode préemptif Une tâche peut être interrompue au profit d une autre plus prioritaire non préemptif : toutes les tâches en mode non-préemptif Une tâche perd le processeur lorsqu elle le demande explicitement mixte (attributs des tâches : préemptif ou non préemptif) Intérêts du non-préemptif dans un contexte préemptif : si temps d exécution faible, peu différent du temps de commutation de contexte engendre moindre consommation de RAM Non préemption pour protection d une ressource 17

18 Les tâches (5) ordonnancement (2) gestion des ressources partagées avec «Priority Ceiling Protocol» qui influe sur l ordonnancement. notion de groupe de tâches : Un groupe = un ensemble de tâches liées par une ressource interne Les tâches internes au groupe, partageant une ressource ne peuvent se préempter : C est intéressant pour des tâches coopérantes (à l aide d une même ressource) C est plus simple que la gestion classique de ressource car complètement transparent à l application Pour les tâches externes qui ont une priorité à la plus haute priorité du groupe, les tâches du groupe sont non-préemptives Pour les tâches externes qui ont une priorité > à la plus haute priorité du groupe, les tâches du groupe sont préemptives 18

19 Les tâches (6) classes de conformité (1) créées pour adapter le noyau : aux besoins de l application aux ressources matérielles disponibles tâches basiques seulement tâches basiques et étendues pas de mémorisation des activations + 1 tâche / niveau de priorité mémorisation des activations (tâches basiques) + plusieurs tâches / niveau BCC1 BCC2 ECC1 ECC2 19

20 Événements (1) synchronisation par événements événements privés : 1 événement est la propriété d une tâche étendue (c est l implémentation qui fixe le nombre d événement d une tâche) seul le propriétaire peut invoquer le service d attente modèle n producteurs / 1 consommateur n tâches peuvent invoquer le service de signalisation 1 tâche invoque le service d attente attente explicite des consommateurs (synchrone) par opposition à la signalisation asynchrone d Unix 20

21 Événements (2) synchronisation par événements occurrences mémorisées, effacement explicite l effacement de l occurrence est à la charge du propriétaire attente possible sur une liste d événements en OU - la première occurrence réveille la tâche - si elle est survenue lors de l appel la tâche n est pas bloquée pas de chien de garde dans les services (attente non gardée) utilisation des alarmes pour cela 21

22 Événements (3) SetEvent ClearEvent WaitEvent GetEvent Task T3 { SetEvent (T2, EV2) TerminateTask () } Tâche basique Tâche basique Task T1 { SetEvent (T2, EV1) TerminateTask () } Task T2 { Loop WaitEvent (EV1, EV2) ClearEvent(EV1,EV2) EndLoop } Tâche étendue 22

23 Ressources (1) Les ressources et l exclusion mutuelle Ressources à usage unique : code, périphérique Besoin d un accès coordonné aux ressources à usage exclusif : section critique exclusion mutuelle d accès La gestion des ressources doit assurer que : 2 tâches n occupent pas la ressource en même temps il n y a pas d inversion de priorité il n y a pas d interblocage entre tâches 23

24 Ressources (2) L inversion de priorité activation de T4 : Ready puis Running Priorité T4 > Priorité T3 > Task T4 T4 demande la ressource S Run W Run t T1 et T4 utilisent la même ressource Task T3 Task T2 S S Re Run S t Temps de suspension anormale de T4 Re Run S t Task T1 Run Re Run Re t T1 occupe la ressource Libération de la ressource Légende S Run Re W Suspended Running Ready Waiting 24

25 Le protocole «Priority Ceiling Protocol» Ressources (3) Task T5 Ceiling Priority S R Run S R Run S Libération de la ressource t t Priorité T5 > Priorité T4 > Priorité T3 > T1 occupe la ressource Task T4 S Re Run Run S t T1 et T4 utilisent la même ressource Task T3 Task T2 S Re Run S t S Re Run S t Task T1 Run Re R t T1 occupe la ressource Légende S Run Re W Suspended Running Ready Waiting 25

26 Ressources (4) Les ressources et l exclusion mutuelle services pour prendre et relâcher explicitement une ressource utilisation du protocole PCP pour éviter : les inversions de priorités les blocages inter-tâches GetResource ReleaseResource une ressource standard : Res_scheduler (passage en mode non-préemptif) restriction d appels de services à l intérieur d une section critique TerminateTask, ChainTask, Schedule, WaitEvent : ne doivent pas être appelés dans une section critique 26

27 GetResource ReleaseResource Ressources (5) Task T1 { GetRessource(R1) ReleaseRessource(R1) TerminateTask () } Ressource R1 Task T2 { GetRessource(R1) ReleaseRessource(R1) TerminateTask () } Task T3 { GetRessource(Res-Scheduler) ReleaseRessource(Res_Scheduler) TerminateTask () } 27

28 alarmes et compteurs Alarmes (1) compteur manipulable au travers de OIL (Osek Implementation Language) enregistrement de «ticks» externes, éventuelle pré-division compteur fini avec RAZ automatique MaxAllowedValue TicksPerBase MinCycle Source de ticks (interruption) Compteur_C1 Temps physique, couronne moteur 28

29 alarmes et compteurs Alarmes (2) alarme attachée à 1 compteur et 1 tâche unique ou cyclique, déclenchement absolu ou relatif l alarme est déclenchée lorsque le compteur atteint une valeur de référence sur expiration : - activation de la tâche, ou - signalisation d un événement, ou - exécution d une routine «Callback». Alarme_A1 Task T1, Activate Source de ticks (interruption) Compteur_C1 Counter Action (ActivateTask, SetEvent, AlarmCallback AlarmTime, CycleTime Temps physique, couronne moteur Alarme_A2 Task T2, Event EV1 29

30 exemples Alarmes (3) Période du Timer ( T ) Timer ou autre Temps 8 Compteur ( modulo 8 ) 0 Temps Alarme cyclique (temps de cycle = 6 * T) Alarme simple (Temps = 2 * T) lancement de l alarme périodique Signalisation périodique de l événement associé à l alarme lancement de l alarme Temps Signalisation de l événement associé à l alarme Temps 30

31 Applications Alarmes (4) activation de tâches périodiques ou non signalisation d occurrences d événement périodiques ou non périodiques garde temporelle SetRelAlarm SetAbsAlarm GetAlarm CancelAlarm 31

32 Alarmes (5) Compteur ticks 1ms, max : 50 Alarme_A1 Expire à 20, Périodique, cycle=20, Task T1, activate Alarme_A2 Expire à 50, Périodique, cycle=50, Task T2, event EV2 Task T1 { TerminateTask () } Task T2 { Loop WaitEvent(EV2) EndLoop } Alarme_A3 Expire à 48, unique, AlarmCallBack AlarmCallBack(name) { } 32

33 La communication OSEK-VDX COM 33

34 OSEK COM (1) La communication Portabilité, réutilisation et inter-opérabilité des logiciels d application Même interface pour les communications internes et externes Indépendance vis-à-vis du protocole de communication sous-jacent Adaptation au contexte (scalability) Configuration statique de la communication ECU_1 ECU_2 Actioneur_1 Médium de communication 34

35 OSEK COM (2) ISO/OSI Model Application Application OSEK OS (OSEK Operating System) Presentation Session Transport Network OSEK COM Interaction Layer Network Layer OSEK NM (OSEK Network Management) Data Link Layer (DLL) Data Link Layer Physical Bus Communication Hardware OSEK-VDX / COM v3.0 (courtoisie Christophe Marchand (PSA)) 35

36 OSEK COM (3) services basés autour des objets messages 1 message = 1 nom + 1 type de données + des attributs modèle de communication m : n : Écriture dans le message : plusieurs écrivains possibles (même site) Lecture du message : plusieurs lecteurs possibles (un site, sites ) des classes de conformité pour s adapter au contexte CCCA et CCCB : communication interne à un site seulement CCC0 et CCC1 : communication intra et inter-sites 36

37 OSEK COM (4) Modèle de communication asynchrone structure «tableau noir» (Unqueued message), variable rafraîchie structure à file FIFO (Queued message), boîte aux lettres classique pas de suspension de la tâche émettrice pendant la transmission pas de blocage si message non disponible pour la tâche réceptrice resynchronisation par polling (sur une variable d état) activation tâche sur fin d envoi ou réception signalisation d occurrence sur fin d envoi ou réception exécution routine Callback alarme sur garde temporelle (émission / réception) 37

38 OSEK COM (10) Application Application Message SendMessage ReceiveMessage ActivateTask, SetEvent, SetFlag or Callback ReceiveMessage Message Object Class 1 Notification Class 1 Interaction Layer Notification Detection Reception Filtering Class 4 Class 2 Class 3 Notification Detection Reception Filtering internal & external CPU-order Message Callouts Networkorder Message I-PDU Callouts IPDU Callouts Send Filtering Byte ordering Message Object Transfer Properties (Triggered or Pending) I-PDU Transmission Mode (Direct, Periodic or Mixed) I-PDU Tx Minimum Delay Time Monitoring external Transmissio n Deadline Monitoring Reception Deadline Monitoring CPU-order Message Callouts Network-order Message Callouts Byte ordering IPDU Callouts Transmission Request Transmission Confirmation Transmission Error Indication Transmission Confirmation Reception Error Indication Reception Indication Reception Indication -PDU Underlying Layer Zero-length Application Message Zero-length Message Object I-PDU Non-zero-length Application Message Non-zero-length Message Object Non-zero-length Message Storage (courtoisie Christophe Marchand (PSA)) 38

39 Source doc OSEK-VDX COM Filtrage sur les messages OSEK COM (9) Algorithm Reference Algorithm Description F_Always True No filtering is performed so that the message always passes F_Never False The filter removes all messages F_MaskedNewEqualsX (new_value&mask) == x Pass messages whose masked value is equal to a specific value F_MaskedNewDiffersX (new_value&mask)!= x Pass messages whose masked value is not equal to a specific value F_NewIsEqual new_value == old_value Pass messages which have not changed F_NewIsDifferent new_value!= old_value Pass messages which have changed F_MaskedNewEqualsMaskedOld (new_value&mask) == (old_value&mask) F_ MaskedNewDiffersMaskedOld (new_value&mask)!= (old_value&mask) Pass messages where the masked value has not changed Pass messages where the masked value has changed F_NewIsWithin min <= new_value <= max Pass a message if its value is within a predefined boundary F_NewIsOutside (min > new_value) OR (new_value > max) Pass a message if its value is outside a predefined boundary F_NewIsGreater new_value > old_value Pass a message if its value has increased F_NewIsLessOrEqual new_value <= old_value Pass a message if its value has not increased F_NewIsLess new_value < old_value Pass a message if its value has decreased F_NewIsGreaterOrEqual new_value >= old_value Pass a message if its value has not decreased 39

40 Exemples de services OSEK COM (11) SendMessage SendDynamicMessage ReceiveMessage ReceiveDynamicMessage SendZeroMessage GetMessageStatus 40

41 Evolutions : OSEKtime, OSEK FT Com Modèles d application 41

42 Évolutions Évolution conjointe avec une approche TT (Time-Triggered) OSEKtime OS 1.0 juillet 2001 OSEK FT com 1.0 juillet 2001 (Fault-Tolerant Communication) 42

43 Aperçu d OSEKtime OS Contexte : TTCAN - TTP/C - FlexRay 2 types de tâches : Les tâches TT Les tâches OSEK-VDX OS (classiques, services précédents) Tâche TT = un module (point d activation, point de sortie) (suspended, running, preempted) Plan statique d ordonnancement calculé hors-ligne Surveillance des échéances (marques dans le plan d ordonnancement) Utilisation des temps libres pour l exécution des tâches OSEK-VDX classiques 43

44 Modèles d application (1) Classes de conformité : souci d implémentation, pas de vérification Modèles d application du plus simple (analysable formellement) au plus complexe (validation par simulation) Exemples de modèles Tâches basiques, périodiques, indépendantes (la coopération par message «unqueued» n est pas une dépendance) Tâches basiques, périodiques, indépendantes avec offset initial (l offset peut être géré par une alarme non périodique) 44

45 Modèles d application (2) Exemples de modèles (suite) Tâches basiques, périodiques, avec partage de ressource Tâches basiques, périodiques + apériodiques (gestion par un serveur de tâches), indépendantes Tâches basiques, périodiques, dépendantes par messages («queued») internes à un site ou inter-sites Tâches basiques périodiques, tâches étendues périodiques (infos sur les causes et temps de blocage) -- Tâches étendues cycliques, coopérant via le réseau, partageant des ressources, préemptives et non-préemptives 45

46 Conclusion OSEK/VDX OS, COM, NM, OIL une proposition mature et complète OSEKtime OS et FTCom une architecture TT + communication FT (à promouvoir) Des produits industriels (Motorola, WindRiver ) et des produits propriétaires (équipementiers) Un pas important vers la portabilité des applications, la réutilisation de composants dans les ECU 46