Introduction au Temps Réel

Transcription

1 Introduction au Temps Réel Emmanuel Grolleau Septembre Plan de la présentation Introduction Contexte applicatif Contraintes temporelles Problématique de la validation temporelle La validation temporelle dans l industrie Analyse de temps de réponse Prise en compte de facteurs pratiques Limiter le surdimensionnement Transactions Modèles Multiframe Positionnement dans le cycle de développement logiciel UML et le temps réel MARTE Enjeux de demain

2 3 Introduction Enjeux industriels Introduction Surdimensionnement Cycle de développement Enjeux industriels de demain 4 Contexte applicatif

3 5 Parallélisme des traitements Période=150ms Envoyer donées Période=20ms Commandes Centrale inertielle Réguler attitude Période=100ms MODEM Lire consignes Période=250ms Récepteur GPS Lire GPS 6 Contraintes structurelles et temporelles Envoyer donées Lire consignes Réguler attitude Envoyer donées Réguler attitude

4 7 Implémentation dirigée par le temps Pire durée d exécution Deux types d implémentation Réguler attitude période temps Dates connues Implémentation dirigée par les événements Dates inconnues temps 8 Types d approche Approche synchrone temps Approche asynchrone Séquence pré-calculée Algorithme d attribution de priorités + ordonnanceur

5 9 Spécificités du temps réel S assurer du respect des contraintes de temps Ordre d exécution = ordonnancement Déterminisme de déclenchement des traitements La dynamique du système doit pouvoir être caractérisée Un pire cas doit pouvoir être extrait Déterminisme des durées de traitement Un Worst Case Execution Time (WCET) caractérise les tâches Déterminisme du service et de l interférence du support d exécution Hardware déterministe Faible latence noyau Traitement généraliste (OS) vs. Traitement temps réel (RTOS) Buts non compatibles avec le temps réel Privilégier la flexibilité par rapport au déterminisme Mémoire virtuelle Garantir l indépendance des processus Systèmes de protection mémoire Augmenter la vitesse moyenne de traitement Pipeline, mémoire cache, prédiction des sauts et prefetch, cache disque Favoriser l équité du partage du processeur entre les processus Algorithmes d ordonnancement à base de tourniquet, comme Multi-Level Feedback Faciliter la maintenance et le diagnostic du système avec de nombreux processus de maintenance, mise à jour, surveillance, etc. Accélérer la vitesse de traitement en utilisant une structure monolithique «Mesures» de la compatibilité au temps réel Déterminisme Robustesse Latence du noyau ( Temps réel = déterministe ) ( mon PC = rapide «la plupart du temps»)

6 Noyau, exécutif, système d exploitation Le noyau : gère les interruptions matérielles, crée les tâches et ou processus, gère la mémoire, se sert d une interruption horloge pour faire l ordonnancement des tâches et des processus L exécutif = noyau + pilotes de périphériques (gestion des entrées/sorties USB, RS-232C, E/S numériques et analogiques, ), protocoles réseaux (pile IP, CAN, bluetooth, etc.) Système d exploitation (SE, Operating System, OS)= exécutif + shell + moyens de maintenance, mise à jour, Systèmes d exploitations généralistes Unix, Linux, Microsoft Windows 7, Windows Vista, Windows XP, Windows 2000, etc. Très consommateurs de ressources (processeur, mémoire, ) Exécutifs temps réel VxWorks, norme OSEK/VDX (automobile), norme ARINC 653 (avionique civile), norme Ada (aérospatiale, avionique militaire), norme POSIX (généraliste), etc. Peu consommateurs de ressources et déterministes (embarquables) La plupart ne proposent (à part ARINC653) que la notion de tâches et pas la notion de processus Qu est-ce qu une tâche/un processus? Le programme principal est une tâche Un sous-programme s exécutant parallèlement au programme principal est une tâche Un processus est un ensemble de tâche partageant des variables globales Deux processus s exécutent en parallèle comme des tâches mais ont leur mémoire propre L entité chargée de partager le ou les processeurs entre les tâches et processus est l ordonnanceur L ordonnanceur est au cœur du noyau

7 13 Qu est-ce qu une tâche temps réel? Une tâche est temps réel si elle doit s exécuter dans une fenêtre temporelle Respect d échéance Validation temporelle S assurer que toutes les tâches temps réel soient exécutées «dans les temps» Pour toute la vie du système = Quels que soient les événements Modèle d application Modèle d environnement Modèle de support d exécution D où viennent les contraintes? Aéronef Miniature Autonome de Détection et d Observation Mini drone Envergure 55 cm Autonomie 20 à 30 minutes en vol de croisière Masse ~930 grammes Récepteur GPS 12 canaux 4Hz 30g Centrale inertielle IMU 38g 3 gyromètres 3 accéléromètres Echantillonnage interne > 1kHz 38+25g MODEM 860 MHz 9600 bps portée max 8km 100 mw Récepteur RC Modes de vol Manuel : pilotage par RC Assisté : roulis/vitesse ascensionnelle Autonome : assisté + navigation mission Retour à la base Montée sur panne GPS/RC/Modem Crash sur place sur panne grave (IMU+RC) MPC g 40 MHz RTOS OSEK/VDX Coprocesseur FP Utilisation 2 UART ( GPS, Modem) 5 entrées PWM RC 4 sorties PWM, Servos CAN ( IMU) Servocommandes

8 D où viennent les contraintes de temps? /2 Gestion parallèle de Réception GPS 1 trame toutes les 250 ms, événement initié par un dispositif externe chaque trame arrive octet par octet (120 octets/trame), chaque octet doit être stocké avant l arrivée du prochain octet (1/5600o/s ~ 175 µs après) Pénalité : perte de la trame, donc prise en compte de la position retardée de 250 ms Réception de données venant du sol 1 trame au plus toutes les 100 ms, événement initié par un dispositif externe Chaque trame est composée de 10 octets, chaque octet doit être lu et stocké en moins de 1/960o/s ~ 1 ms Pénalité : perte d une commande provenant du sol Réception de donnés de la centrale inertielle 1 message toutes les 20 ms, événement initié par un dispositif externe Chaque message CAN est composé de 3 trames de 8 octets de données, séparés de 80 µs, comme dans le cas des liaisons RS-232, chaque trame doit être lue et stockée avant l arrivée de la suivante Pénalité : perte totale ou partielle de contrôle pouvant mener au crash Récepteur de consignes manuelles via le récepteur RC Assure le pilotage en mode répéteur lorsque le système est en mode manuel, initié par un dispositif externe 5 entrées doivent être surveillées (différence temporelle entre front montant et descendant) et mises à jour toutes les 20 ms Pénalité : fonctionnement saccadé pouvant entraîner un crash Génération des commandes vers les servo-moteurs Initié par l horloge interne 5 sorties doivent être programmées avec une valeur de commande toutes les 20 ms Pénalité : fonctionnement saccadé pouvant entraîner un crash Envoi des données vers le sol de navigation/horizon artificiel Initié par l horloge interne (choix de 50 ms) Pénalité : retard d affichage d informations au pilote Navigation Calqué sur l arrivée d informations GPS (~250 ms) Pénalité : mauvaise trajectoire Détection/gestion de pannes Initié par l horloge interne (choix de 200 ms) Pénalité : retard de détection de panne, danger de crash moteur allumé Algorithme de régulation d attitude Initié 1 fois sur 3 par les informations provenant de la centrale Pénalité : perte de contrôle Récapitulatif : D où viennent les contraintes de temps? /3 4 «tâches périodiques» sont initiées par un dispositif externe, leur période est imposée par ceux-ci, il nous faut répondre en temps réel à ceux-ci 3 «tâches périodiques» initiées par l horloge interne 2 tâches initiées par une autre tâche Contraintes de temps inhérentes à la dynamique du système et des dispositifs capteurs/actionneurs Les pénalités de retard peuvent aller d un certain inconfort à la destruction du système, voire à exposer les opérateurs à un risque physique La plupart des événements se produisent de façon périodique (il arrive cependant que des événements soient apériodiques)

9 Types de contraintes de temps Contrainte stricte (hard real-time) Une violation des contraintes temporelles peut être dangereuse pour le système Exemple : tâche d acquisition centrale inertielle du drone Contraintes fermes (firm real-time) Violer une échéance n est pas catastrophique mais la qualité du résultat diminue Exemple : tâche d acquisition GPS, cependant, il faut au moins 1 trame sur 2 pour une navigation presque correcte (1,2)-firm Contraintes molles (soft real-time) Respecter les échéances augmente la qualité du résultat Exemple : aucun sur le drone, applications multimedia 18 Introduction Enjeux industriels Analyse en-ligne Validation temporelle industrielle Cycle de développement Perspectives

10 19 Validation temporelle : place dans le cycle de vie Ordonnancement de tâches temps réel Domaine de recherche né dans les années 1970 S appuie sur des travaux d ordonnancement de production des années 1950 S applique en fin de cycle de développement logiciel Exemple : dans un cycle en W (ou Y) Spécification Simulation Validation temporelle Conception Tests Intégration Spécification &Conception adaptée Intégration avec noyau Tests Codage Codage croisé Tâches réveillées par l horloge interne Date_réveil date_courante Faire toujours Date_réveil Date_réveil + Période_tâche Dormir jusqu à Date_réveil Fait Tâches réveillées par événement extérieur Utilisent une ISR (Interrupt Service Routine) exécutée dès que l interruption a lieu qui déclenche la tâche Faire toujours C C Fait Attendre événement déclencheur Structures typiques des tâches r r=? C r+t C? r+t Tâches logicielles (héritent de la périodicité de la tâche qui les réveille) Faire toujours Attendre événement ou message ou événement ou Fait r+2t

11 21 Validation temporelle RTOS RTOS RTOS Ordonnancement Buts de l ordonnancement généraliste buts ordonnancement temps réel Ordonnancement généraliste» Prendre en compte des notions de priorité tout en évitant qu un processus souffre de famine» Améliorer les performances moyennes» Algorithme le plus fréquent : Multi-Level Feedback (MLF) = tourniquets à priorités avec changement de niveau de priorité en cas de famine prolongée Ordonnancement temps réel» Garantir que même dans le pire cas, une tâche respecte ses échéances» Note : cela signifie qu il faut pouvoir caractériser le pire cas» Algorithme le plus fréquent aujourd hui : algorithme à priorités (simple en apparence ) τ 4 τ 5 τ 4 τ 3 Principe du tourniquet (round robin) Tâche active pendant un quantum de temps τ 9 τ 7 τ 6

12 Algorithme d ordonnancement MLF 5 τ 4 τ 3 Priorité élevée 5 τ 6 2 Priorité moyenne τ 5 τ 68 τ 45 τ τ 68 τ 42 τ τ L ordonnanceur utilise le tourniquet non vide de plus haute priorité Changement de priorité lorsqu une tâche attend «très longtemps» jusqu à ce qu elle obtienne un quantum de temps du processeur. Elle retourne alors à son niveau de priorité initial. Priorité basse τ 47 τ Exemple de systèmes d exploitation utilisant MLF Unix MS Windows Avantages Prise en compte des priorités, Absence de famine, S adapte parfaitement aux systèmes dans lesquels on n a pas d informations sur la charge Inconvénients Coûteux, difficile à caractériser (quel est le pire cas pour une tâche?) T 1 Tâche terminée ou bloquée Processeur τ 3 Algorithme d ordonnancement à priorités Echelle des priorités Niveau de priorité N T 3 Niveau de priorité N-1 Avantages Plus simple à caractériser, implémentation aisée et peu coûteuse Inconvénients Risques de famine Tâche active T 4 τ 4 Niveau de priorité N-2 T 2 Niveau de priorité N-3 τ 7 T 7 Niveau de priorité N-4 Tâches activables

13 Algorithme Rate Monotonic Article de référence : C.L. Liu and J.W. Layland,"Scheduling algorithms for multiprogramming in real-time environment", Journal of the ACM, vol. 20(1), pp , 1973 Contexte Tâches indépendantes, périodiques, à échéance sur requête, simultanées (donc concrètes) : une tâche est définie par un WCET et une période Algorithme Affecter une priorité en fonction de la période : plus la période est petite, plus la priorité est élevée Résultats Rate Monotonic est optimal dans la classe des algorithmes à priorités fixes» Cela signifie que si un algorithme à priorités fixes ordonnance fiablement un système de tâches S, alors RM ordonnance fiablement S» De façon équivalente, tout système ordonnançable par un algorithme à priorités fixes est ordonnançable par RM Théorème de l instant critique: pour des tâches indépendantes, le pire temps de réponse pour une tâche de priorité i advient lorsque toutes les tâches de priorité supérieure à i sont activées simultanément avec la tâche étudiée.» Conséquence : pour des tâches non concrètes, le cas concret simultané est un pire cas. Si un algorithme ordonnance fiablement un système de tâches simultanées, alors il ordonnance fiablement le même système de tâches non simultanées On peut déterminer si un système est ordonnançable dans ce contexte par RM uniquement en testant la charge du système Tests d ordonnançabilité possibles Simulation => nous aurons à déterminer sur quelle durée (durée d étude) (CNS) Calcul du pire temps de réponse (CNS) Calcul du facteur d utilisation processeur (charge processeur) (CS) Instant critique : illustration Soit un système de 2 tâches non concrètes. Une affectation de priorités RM donnerait Prio( )>Prio( ) Temps de réponse,1 = 12 Temps de réponse,2 = 13 temps Remarque : le temps de réponse d une tâche ne dépend que des tâches de priorité supérieure (ou égale) : n est pas influencée par Ou doit-on arrêter la simulation pour conclure que le système est fiablement ordonnancé? Supposons les tâches simultanées Temps de réponse,1 = 14 Temps de réponse,2=13 temps

14 Tests de complexité polynomiale Un système dont la charge U = ΣWCET/période>1 ne peut être fiablement ordonnancé sur un processeur U 1 est donc une condition nécessaire d ordonnançabilité triviale Liu & Layland ont proposé une condition suffisante d ordonnançabilité CS signifie que» si la réponse au test est OUI, le système est fiablement ordonnancé par RM» Si la réponse au test est NON, on ne peut conclure Condition suffisante de Liu & Layland 73 Soit S une configuration de n tâches indépendantes à échéance sur requête. Le système S est ordonnancé fiablement par RM si U n (2 1/n 1) 1/ n limn ( n (2 1) ) = ln(2) Il en résulte que tout système de tâches indépendantes à échéance sur requête de charge inférieure à 69% est ordonnancé fiablement par RM La complexité du test est linéaire incertitude 0% 69% 100% charge n Borne de Sjödin et Hansson 98 : le pire temps de réponse pour les tâches d un système <C i,t i > est majoré par U i =C i /T i Tests polynomiaux plus récents TRi 1 j hp( i) i j hp ( i) Borne hyperbolique (Bini et al. 03) : un système <C i,t i > est ordonnançable (par RM) si ( U i i 1.. n C j U + 1) 2 j Les auteurs ont amélioré la borne de L&L73, ainsi la borne hyperbolique est toujours meilleure (i.e. moins pessimiste, mais bien entendu jamais optimiste) que le test de L&L73 Tests polynomiaux réglables basés sur la RTA δ-het (δ Hyperbolic Exact Test) de Bini et Buttazzo 04 Schémas d approximation de Richard, Baruah, Fisher incertitude CS dit OUI CS NON, CN OUI CN dit non Tâches indépendantes, ER

15 29 Système réel la plupart du temps Surdimensionnement Système réel pire cas Ressources nécessaires Modèle du système réel Condition suffisante 30 Méthodes exactes : complexité et passage à l échelle La problématique principale de l ordonnancement est qu un bon nombre de problèmes (par exemple, lorsque les tâches partagent des ressources critiques) est NP-difficile ou Co-NP-difficile Par conjecture, il n existe donc pas d algorithme donnant en tant raisonnable une réponse exacte Donner une réponse exacte résulte en une explosion combinatoire Problématiques principales de l ordonnancement Evaluer des algorithmes d ordonnancement (les contraintes temporelles sont-elles respectées? Tel critère est-il minimisé?) en utilisant des tests approchés (heuristiques) polynomiaux ou pseudo-polynomiaux permettant d approximer de façon la moins pessimiste possible le comportement d un algorithme» Par exemple, calculer une borne supérieure du temps de réponse des tâches qui soit la moins pessimiste possible, mais qui ne puisse en aucun cas être optimiste Evaluer et comparer des algorithmes» Par exemple trouver un ratio qui caractérise l écart maximal donné par une heuristique par rapport à la réponse que donnerait un algorithme optimal exponentiel Limiter au maximum l explosion combinatoire en réduisant au maximum l espace des états, en trouvant des classes d équivalence entre états lors d une construction/exploration de l espace des solutions.

16 Rate Monotonic Analysis (RMA) temps Remarque 1 : le système se retrouve dans le même état à l instant 28 qu à l instant 0 Par même état nous entendons même motif d arrivées des tâches, et comme à l instant initial, le processeur n a plus rien à traiter Observons cela sur un diagramme de charge (ou de demande processeur) de niveau de priorité 1 Charge à traiter temps Demande processeur Demande processeur Traitement Point creux Période d activité temps

17 33 Formule pseudo-polynomiale de calcul de temps de réponse Une tâche de charge C 2 met, au pire, C 2 unités de temps à s exécuter Demande processeur (RBF) R R R T 10 C 4 (0) (1) 2 2 = C2 + Cj = C2 + 1 = j hp ( i ) T j Traitement (1) R 2 13 (2) Cj = C C (3) R 2 14 Tj R2 = C2 + Cj = C2 + 1 = 14 ( ) 4 C j hp i Tj (2) 2 = C2 + + = j hp ( i) R (0) 2 = C2 = temps Calcul de pire temps de réponse Articles de référence : M. Joseph and P. Pandya,"Finding response times in real-time system", The Computer Journal, vol. 29(5), pp , 1986 Contexte Tâches indépendantes à échéance inférieure ou égale à la période pour [JP 86] Résultats Soit hp(i) l ensemble des indices de tâches de priorité supérieure (ou égale) à la priorité de τ i, en excluant τ i» Par exemple, soient {,, τ 3, τ 4 } de priorité croissante, hp(2)={3,4} Le temps de réponse de τ i est donné par la charge à traiter plus l interférence des tâches de priorité supérieure, en démarrant à l instant critique, car le pire temps de réponse de τ i intervient dans la plus longue période d activité de niveau de priorité prio(τ i ), et celle-ci démarre (y compris pour les tâches à échéances arbitraires) à l instant critique Application au cas D i T i Si τ i respecte ses échéances, son pire temps de réponse est le plus petit point fixe de la suite RTA Response Time Analysis R R (0) i ( n+ 1) i = Ci = Ci + j hp ( i) ( n Ri Tj ) Cj Converge si et seulement si U 1 Complexité pseudo-polynomiale

18 35 Types d approche lors de la validation Modèle du système réel Au choix surdimensionnement vs passage à l échelle Condition suffisante polynomiale Heuristiques hybrides CNS ou CS (suivant les cas) Pseudopolynomiale Méthode exacte exponentielle 36 Simulation : un test exponentiel Montée en charge r+h Taille H = PPCM(périodes) Plus Petit Commun Multiple 1..m borné par 3 m Méthode fortement exponentielle Pros : les périodes sont souvent harmoniques/à PGCD important car les concepteurs sont humains Cons : avec l avènement de l aide à la conception, pros de moins en moins vrai, anomalies d ordonnancement Introduction Prios Fixes Prios Dyn. Offsets Conclusion

19 37 Facteurs pratiques Exclusion mutuelle Communications / contraintes de précédence entre les tâches Suspension Réveils de tâches liés Incertitude sur les dates d activation des tâches Durées non modélisables par WCET Système réel Modèles probabilistes la plupart du temps Etc. Système réel pire cas Modèle du système réel 38 Exemple : exclusion mutuelle Tâche A x++ x 0 Tâche B x++ Election de A Transférer X dans registre R R 0 Préemption par B (sauvegarde du contexte de A dans son BCP) BCP A R=0 CO R 0 Transférer X dans registre R Incrémenter le registre R R 1 Transférer le registre R dans X x 1 Election de A (restauration du contexte de A à partir de son BCP) Incrémenter le registre R Transférer le registre R dans X R R x Mécanisme d exclusion mutuelle (sémaphore, moniteur)

20 Lorsque des ressources critiques sont en jeu, il faut prendre en compte le problème de l exclusion mutuelle Problèmes possibles» Interblocage (dîner des philosophes)» Inversion de priorité (voir plus loin)» Anomalies d ordonnancement Anomalie d ordonnancement Utilisation de la ressource R temps τ 3 C 3 =6 => cela fonctionne sur la simulation La tâche est bloquée lors de l accès à la ressource, c est normal, cela s appelle un blocage (direct) temps τ 3 C 3 =5 => violation d échéance, c est une anomalie d ordonnancement Inversion de priorité Une inversion de priorité a lieu lorsqu une tâche se voit retarder par une tâche de priorité inférieure, alors qu elle ne partage pas de ressource directement avec cette tâche Utilisation de la ressource R temps τ 3 blocage Inversions de priorité : s exécute alors que est bloquée, pourtant ce n est pas qui détient la ressource bloquant héritage τ 3 Libération R => retour au niveau de priorité initiale temps

21 41 Exemple d inversion de priorité Mission Mars Pathfinder (1997) Protocole à Priorité Héritée Article de référence : L. Sha, R. Rajkumar and J.P. Lehoczky,"Priority inheritance protocols : an approach to real-time synchronization", IEEE Transactions on Computers, vol. 39n. 9, 1990, pp Contexte Algorithmes à priorités fixes Nom Protocole à priorité héritée (PPH) ou Priority Inheritance Protocol (PIP) Principe Lorsqu une tâche τ i est bloquée pour accéder à une ressource R, la tâche τ j détenant R hérite de la priorité de τ i pendant la durée de sa section critique sur R Résultats Supprime toute inversion de priorité Effets de bord Même une tâche n utilisant pas de ressource peut subir un blocage indirect de la part d une tâche de priorité inférieure temps τ 3

22 Etude du Protocole à Priorité Héritée Inconvénients Ne supprime pas l interblocage Si une tâche utilise plusieurs ressources, elle peut être bloquée à chaque entrée en section critique Complexe à implémenter Implémentation Lorsqu une tâche est en section critique, son niveau de priorité peut être augmenté lorsqu elle est en attente du processeur ou bloquée par une instruction de type prendre(ressource) sur une ressource qu elle détient. Pendant son exécution, plusieurs tâches peuvent augmenter sa priorité τ i La priorité retombe à prio(τ Héritage de prio(τ j ) à cause de R j ) 1 Héritage de prio(τ k ) à cause de R 2 Héritage de prio(τ m ) à cause de R 2 Utilisation de R 1 Utilisation de R 2 Utilisation de R 1 et R 2 Etude du Protocole à Priorité Héritée temps τ 3 Héritage de priorité Une tâche peut être bloquée par une section critique pour chaque ressource Blocage direct ou indirect La durée de blocage B i d une tâche due aux sections critiques du système est la durée pendant laquelle une tâche peut être bloquée (de façon directe ou indirecte) par une tâche de priorité inférieure Pour PIP B i = ( duréescj( R)) max j lp ( i) ressourcer Utilisation de R 1 Utilisation de R 2 Utilisation de R 1 et R 2 Note: on suppose que fait P(S 2 );P(S 1 ) lp(i) ensemble des indices de plus petite priorité que τ i Durée SC i (R) : durée maximale de section critique de τ i sur R Dans l exemple, B 1 = 5, B 2 =3, B 3 = 0

23 Etude du Protocole à Priorité Héritée S il y avait une tâche de priorité intermédiaire située entre et, même si elle n utilisait pas de ressource, son B i serait de 5 (durée SC 3 (R 1 )+durée SC 2 (R 2 )) car elle peut subir un blocage indirect dû à Si il y avait une tâche de priorité supérieure à celle de, en appliquant la formule proposée, son B i serait de max{durée SC 3 (R 1 ),durée SC 1 (R 1 )}+max{durée SC 2 (R 2 ),durée SC 1 (R 2 )}=5 Cependant, il est évident que la formule donnée est pessimiste dans ce cas, car cette tâche ne pourrait en aucun cas subir un blocage indirect, pourquoi? La formule devrait prendre en compte le fait qu on ne prend en compte que les ressources utilisées par au moins une tâche de priorité supérieure à la tâche dont on calcule le B i Bi = max j lp i) ressourcer utiliséeparunetâchedehp( i) ( ( duréescj( R)) En fait, les formules de calcul du pire temps de réponse sont R R (0) i ( n+ 1) i = Bi + Ci = Bi + Ci + Pour D i T i j hp ( i) ( n Ri Tj ) Cj R R (0) i ( n+ 1) i (*) TRi, k = R ( k) Ti( k 1) i ( k) = Bi + kci ( k) = Bi + kci + j hp ( i) ( n) R i ( k) Cj Tj Pour des échéances arbitraires Etude du Protocole à Priorité Héritée Pourquoi ne considère-t-on qu une seule fois B i? PIP est implémenté dans peu d exécutifs (cela est dû au fait que le protocole à priorité plafond est plus avantageux et facile à implémenter) Ce protocole est cependant implémenté dans VxWorks L absence de protocole de gestion de ressources a failli entraîner l échec de la mission Mars Pathfinder

24 Protocole à Priorité Plafond Article de référence : L. Sha, R. Rajkumar and J.P. Lehoczky,"Priority inheritance protocols : an approach to real-time synchronization", IEEE Transactions on Computers, vol. 39n. 9, 1990, pp Contexte Algorithmes à priorités fixes Nom Protocole à priorité plafond (PPP) ou Priority Ceiling Protocol (PCP) Principe Chaque ressource est munie d une priorité plafond égale à la plus grande priorité des tâches susceptibles de l utiliser Une variable, nommée plafond système, est la priorité plafond maximale des ressources en cours d utilisation Une tâche ne peut entrer en section critique (opération Prendre(R)) que si sa priorité est strictement supérieure au plafond système ou si elle détient elle-même le plafond système Lorsqu une tâche τ i est bloquée pour accéder à une ressource R, la tâche τ j détenant R hérite de la priorité de τ i pendant la durée de sa section critique sur R Résultats Supprime toute inversion de priorité Une tâche ne peut être bloquée au maximum que par une seule section critique de priorité inférieure par période d activité Absence d interblocage (pourquoi?) Effets de bord Même une tâche n utilisant pas de ressource peut subir un blocage indirect de la part d une tâche de priorité inférieure Une tâche, même si elle est la plus prioritaire des tâches active, peut être bloquée en accédant à un sémaphore même libre : c est un blocage d évitement Comparaison PPP - PPH PPH temps τ 3 Héritage de priorité Utilisation de R 1 Blocage d évitement Utilisation de R 2 τ1 PPP = > 1 blocage max Utilisation de R 1 et R 2 temps τ 3

25 Etude du Protocole à Priorité Plafond Bi = max ressourcer utiliséeparunetâchedehp( i), j lp ( i) ( duréescj( R)) Sur l exemple précédent : B 1 =max(2,3) ; B 2 = max(3) ; B 3 = 0 Les formules de calcul du pire temps de réponse sont les mêmes, sauf que B i est plus faible qu avec le PPH R R (0) i ( n + 1) i = Bi + Ci = Bi + Ci + j hp ( i) Pour D i T i ( n R i Tj ) Cj R R (0) i ( n + 1) i ( k) = Bi + kci ( k ) = Bi + kci + j hp ( i) ( n R i Tj ) Cj Pour des échéances arbitraires Problème : implémentation aussi complexe que PPH Protocole à Super Priorité ou Priorité Plafond Immédiat Article de référence : C. Kaiser,"Exclusion mutuelle et ordonnancement par priorité", Technique et Science Informatiques, vol. 1(1), pp , 1982 Contexte Algorithmes à priorités fixes Nom Protocole à priorité plafond immédiat (PPPI) ou Protocole à Super Priorité ou Stak Based Priority Ceiling Protocol Principe Chaque ressource est munie d une priorité plafond égale à la plus grande priorité des tâches susceptibles de l utiliser (comme pour PPP) Une variable, nommée plafond système, est la priorité plafond maximale des ressources en cours d utilisation (comme pour PPP) Une tâche ne peut entrer en section critique (opération Prendre(R)) que si sa priorité est strictement supérieure au plafond système ou si elle détient elle-même le plafond système (comme pour PPP) Lorsqu une tâche τ i entre en section critique, elle hérite pendant toute la section critique de la priorité plafond de la ressource Résultats Mêmes propriétés que le protocole à priorité plafond, en effet même si le comportement peut être différent, le calcul du facteur de blocage est identique Implémentation très simple» Il en résulte que ce protocole est implémenté sur la plupart des exécutifs (norme POSIX, norme OSEK/VDX) et en Ada» Etrangement, il n est pas proposé par VxWorks

26 Protocole à Super Priorité ou Priorité Plafond Immédiat τ τ1 Héritage de priorité PPP = > 1 blocage max Utilisation de R 1 Utilisation de R 2 Utilisation de R 1 et R 2 temps τ 3 52 Ordonnancement et exclusion mutuelle Problème NP-difficile Aucun algorithme non clairvoyant n est optimal Mais on peut appliquer une condition suffisante de la RTA R R (0) i ( n+ 1) i = Ci = Ci + j hp ( i) ( n Ri Tj ) Cj

27 53 Validation temporelle dans l industrie Les RTOS off-the-shelf proposent Ordonnancement à priorités fixes Protocole à priorités plafond immédiat Les méthodes de validation se trouvent en fin de cycle de vie Basées sur la RMA S appuie sur des méthodes des années Enjeux actuels Diminuer les surdimensionnements Mieux utiliser les ressources Aider les concepteurs tout au long du cycle de développement à concevoir un système qui SERA valide temporellement Savoir combiner vue fonctionnelle et opérationnelle S adapter aux nouveaux supports physiques d exécution Etc. Avec des méthodes qui passent à l échelle pour des applications de taille importante

28 55 Introduction Enjeux industriels Diminuer Surdimensionnement le surdimensionnement Cycle de développement Enjeux industriels de demain Tâches sporadiques Fonctionnement non périodique Tâches périodiques Processeur Tâches apériodiques Traitement meilleur effort Rejet Tâches sporadiques Test D acceptation Tâches périodiques Processeur Tâches apériodiques Traitement meilleur effort

29 57 Fonctionnement non périodique «Serveurs» d apériodiques, étudiés dans les années 90 Certains RTOS (norme Ada 1995 et 2005 par exemple, ou POSIX ) proposent de tels serveurs 58 Types de contraintes Contraintes strictes Contraintes fermes Modèles stochastiques QoS

30 59 Dates de réveil liées Différents modèles ont été proposés et étudiés Exemple : transactions Octet 1 Octet 2 Octet µs 173µs 229.2ms Octet 1 Prise en compte sous forme de tâches classiques? Analyse d ordonnançabilité pessimiste Prise en compte sous forme de surcoût processeur dans la durée des tâches? Prise en compte dans toutes les tâches pessimisme Transaction τ i1 τ i2 τ i3 O i2 60 Méthode originelle en priorités fixes Méthode des enveloppes τ Γ i PA PA J τ τ i1 J i 2 i 2 J i 3 i 3 τ J τ i1 i 2 i 2 J i 3 τ i 3 τ i1 Jτ 3 i 2 i 2 τ i 3 i1 τ τ i1 J i i 2 τ i 2 τ i 3 i1 τ i 2 i 2 i 3i1 τ τ i 3 τ i 2 τ τ i1 i 3i 2 i 3 Γ i Γ i W ( t =0 i1 ) t = =00 W i2( t ) W i3( t ) W i (t) τ τ t

31 61 Interférence effective Γ 1 Γ W 11 ( t ) W 12 ( t ) W 13 ( t ) W 21 ( t ) W 22 ( t ) W 21 ( t ) W 22 ( t ) W 11 ( t ) W 12 ( t ) W 13 ( t ) 62 Méthodes des enveloppes Γ 1 Interférence approchée W 1 Charge processeur C ua + W W t = I W2 Interférence approchée Γ 2 Borne sup de temps de réponse de τ ua =10 time τ ua Γ u

32 63 Modèles Multiframe et GMF Tâche multiframe <VecteurWCET,Période>, [Mok&Chen96] P = D = 5 Cycle P = D MF task T P = D J 0 J 1 J J 2 0 J 1 J 2 0 C 1 C 2 C Generalized Multiframe Task <VecteurWCET, VecteurDélai, VecteurPériode> [Baruah99] P 0 = 6 Cycle P 1 = 4 P 2 = 7 D 0 = 5 D 4 D 2 = 6 GMF task T 1 = J 0 J J 1 2 J J 0 1 J 2 0 C 1 C 2 C Comparaison GMF-transactions Comportements possibles différent Comportement pire cas : Transaction généralise GMF P i 0 = 6 Cycle D i0 = 5 4 P i1 = 4 P 2 i = 7 D D 2 i = 6 GMF task 1 i = J 0 J J 1 2 J J 0 1 J 2 T i 0 C i 1 C i 2 C i O = P + P 0 O i 2 = P 0 D = D i1 i T = P + P + P i 0 i 0 1 i3 i i 1 i D = D 1 i2 i 2 i D = D 2 i3 i Transaction Γ i τ i1 τ τ τ i 2 i 3 i1 τ τ i 2 i C i1 = C i C i 2 = C 2 i C = C i 3 i 17 34

33 65 Recurring Real-Time tasks Proposé par [Baruah98] 7, ,5 1, ,2 Période = 50 Période absente dans Le «non-cyclic» RRT Max DBF/RBF parmi les chemins 66 RRT pire interférence 7, , , ,5 1,10 1, ,2

34 67 Digraph [Stigge2011] Pas de distinction nœud source/nœud puits Peut contenir des cycles 12 7, , , ,5 1,10 1, ,2 Rapprochement calcul WCET? 68 Expressivité des modèles digraph ncrrt Transactions RRT GMF multiframe L&L

35 69 Une meilleure utilisation des ressources? Algorithmes en-ligne (ordonnancement dirigé par les priorités) Connaissance des instances actives uniquement Priorités dynamiques EDF,EDL,ML,Pfair Priorités fixes RM,DM,Audsley Algorithmes conservatifs (le processeur ne peut être inactif que si aucune tâche n est active) Algorithmes hors-ligne (ordonnancement dirigé par le temps) Clairvoyance Ordonnancements non conservatifs Optimalité L algorithme le plus utilisé est Earliest Deadline First (EDF) La priorité d une tâche est d autant plus importante que son échéance est proche Raison Règle de Jackson [Jac 55]: exécuter des jobs dans l ordre des échéances non décroissantes est optimal en vue de minimiser le retard maximal Retard i (Lateness): TR i d i ; retard maximal L max = max i {Retard i } J.R. Jackson, «Scheduling a production line to minimize maximum tardiness», Management Science Research Project 43, University of California, Los Angeles, 1955 Preuve : réalisée par échange σ τ b d a τ a d b σ τ a L b L a d a d b τ b L a L b CNS U 1

36 Comparaison DM/EDF Sous la forme <r i,c i,d i,t i >, ::=<0,1,4,4>, ::=<0,4,5,12>, τ 3 ::=<0,2,8,8> U = 1/4+4/12+2/8=20/24=0, DM temps τ 3 EDF temps τ 3 Attention, ici le critère U 1 est une CN et non une CNS pour EDF, car le système n est pas à échéance sur requête 72 Remarques EDF est une politique où les tâches ont une priorité dynamique mais les jobs ont une priorité statique Effet dominos Le calcul de temps de réponse est peu élégant Faire coïncider le réveil de toutes les tâches Faire coïncider l échéance de la tâche étudiée avec chaque échéance rencontrée Prendre le temps de réponse maximal obtenu La vérification du respect d échéances est simple

37 73 Etude de la demande processeur Demand bound function (DBF) Traitement temps Le temps de réponse le plus long arrive dans la première période d activité initiée par un réveil simultané temps 74 Propriétés simplement observables temps Si tâche sporadique? (i.e. période T) Si C i diminue? Si il y a une gigue?

38 75 Le boom de l étude de systèmes répartis Même espace de collision τ 7 Processor C τ 8 FPP: τ 7 >τ 9 >τ 8 τ 9 m 4 m 3 τ 6 τ 4 m 1 m 2 τ 5 τ 3 Processor Processor B A CAN network EDF FPP: > Non-preemptive FPP: m 1 >m 3 >m 2 76 Systèmes répartis Réseau commuté Source node s Switch s 1 0 m 0,j m i,j Link l 0 Link l 1 Link l m Dest. node m n,j FIFO within priorities queue FIFO queue Cell spacer rate 1/t i Muliplexer

39 77 Tous ces modèles/méthodes visent à réduire les écarts Système réel la plupart du temps Système réel pire cas Ressources nécessaires Modèle du système réel Condition suffisante 78 Introduction Enjeux industriels Positionnement Dimensionnement dans le cycle de développement Cycle de développement Enjeux industriels de demain

40 79 Validation temporelle : place dans le cycle de vie Aider le concepteur à concevoir un système valide temporellement Spécification Simulation Validation temporelle Conception Tests Intégration Spécification &Conception adaptée Intégration avec noyau Tests Codage Codage croisé UML 2 et le temps réel Dans les normes UML 2.x Peu ou pas de possibilité d exprimer les spécificités liées au temps réel et à l embarqué Nécessité de pouvoir exprimer le temps, les contraintes de temps, le parallélisme, les différents types de communication, le placement, l ordonnancement, les éléments matériels, etc. Cependant UML + UML profiles + DSL (Domain-Specific Languages) + XMI (pour l échange entre modèles) et les langages de transformation de modèles se développant sont attractifs avec des CASE (Computer-Aided Software Engineering) de plus en plus performants Gains indéniables en productivité, réutilisabilité, fiabilité, sûreté si la méthode est maîtrisée Exemples de CASE : TopCased, IBM Rational Rose, Eclipse,

41 Avant une normalisation d un profil pour le temps réel Différents ateliers proposent différentes approches Artisan Studio : UML+diagrammes spécifiques pour la représentation du multitâche (fortement inspirés de DARTS) Le concepteur est chargé de faire le lien entre tâches et classes/objets/ RT-UML : se base sur les objets actifs UML (attribut isactive=true), ajoute des tubes de communication entre objets qui servent à passer les messages, et définit des stéréotypes spécifiques (<<interrupt>> représente l activation d une tâche objet actif par interruption) UML-RT : Définit la notion de capsules pour les objets actifs, communiquant par des ports. Un canal permet de faire communiquer 2 ports. UML-SDL : Les objects actifs sont exprimés en SDL (Specification and Description Language) langage graphique+textuel non ambigüe (par conséquent pouvant donner des modèles très complexes à manipuler) Concepteur de systèmes embarqués (de très bonne volonté) Par conséquent UML + DARTS UML + SDL UML en capsules Pérennité? Maintenabilité? Evolutivité + suivi des évolutions des normes? Disponibilité d outils? UML + Etre lié à un seul éditeur de logiciel? Un DSL choisi Ex: AADL, sysml UML + stéréotypes

42 Et pourtant, UML apporte de réels avantages Approches dites «structurées»: description de fonctionnalités par rapport aux «bords» de modèle (i.e. par rapport au monde réel capteurs, actionneurs) Simplicité due à l approche totalement descendante Une modification des bords => profondes modifications de la modélisation Absence du concept de composants : réutilisabilité faible d un projet à un autre Approches objet: modélisation du monde réel et du monde métier par des classes/objets regroupés sous forme de composants réutilisables. Prise en main plus complexe, temps de spécification/conception plus long Mais moins influencées par des modifications, plus flexible Time-to-Market voiture, avion, 3 ans Nombreuses modifications du cahier des charges, évolution des normes & exigences, etc. De mieux en mieux comprises et outillées Interfaces de + en + automatisées de transformation de modèles/génération de code (transformations implantées au niveau MOF) Effort de normalisation important en cours Mais toujours une «Jungle» de normes, langages, outils, CASE Parallélisme dans le diagramme des classes Propriété de classe: isactive : boolean Les objets de cette classe sont actifs et s exécutent dans leur propre contexte Concurrence des opérations Propriété concurrency : s adresse plutôt aux classes passives Sequential : opération non réentrante, mais pas de gestion de concurrence, Guarded : opération non réentrante protégée en exclusion mutuelle Concurrent : opération réentrante Propriété des opérations isquery : boolean En lecture seule sur l objet/la classe Envoi de messages : peut être synchrone ou asynchrone Appel d opération ou Signal La norme n implique pas de cohérence (exemple : qu est un appel d opération asynchrone sur une classe passive?)

43 Limitations dans UML Limitations Pas d expression de rythme d exécution (réveil sur interruption, réveil périodique) Pour les messages, notion de file d attente mais pas de notion avec/sans écrasement Pas de réflexion sur la décomposition en tâches D un point de vue multitâche : tend à pousser le concepteur à choisir de «mauvaises» solutions d un point de vue temps réel Non respect du profil Ravenscar Exemple: rendez-vous (i.e. appel synchrone d opération sur un objet actif par un objet actif) Utilisation de solutions dont l exécution est fortement dépendante de l ordonnancement Signaux Expression du temps : pas de temps «vrai» => unités de temps Nécessité de pouvoir étendre UML de façon normalisée Le temps réel n est pas le seul domaine concerné par les lacunes d UML Suivant le contexte dans lequel on se place, ce ne sont pas les mêmes notions qui font défaut Ordonnancement = expression des rythmes, temps absolu, temps considéré comme global, ordonnanceurs, hiérarchie d ordonnanceurs, calculateurs, abstraction du réseau en tant que medium de communication en temps borné, etc. Calcul de durée des traitements = découpage du processeur, mémoires, mémoires caches, instructions, etc. Réparti = découpage du temps, synchronisation d horloges, etc. Etc. Solution propriétaire = être lié à un seul outil/éditeur de logiciel Besoin d une solution normalisée simplement implémentable sur (tous) les ateliers logiciels Utilisation des mécanismes standards d extension d UML

44 Mécanismes standards d extension d UML Stéréotypes Permet de modifier la sémantique d un élément existant Exemple : stereotype <<ppunit>> dans MARTE (Protected Passive Unit) Valeurs marquées (tagged values) permettant d attacher des propriétés n existant pas au niveau du méta-modèle UML à un concept UML. Permettent d associer des valeurs de propriétés aux stéréotypes Valeur des tagged values: exemple de Value Specification Language Permet de définir un langage textuel d expressions Variables, paramètres, littéraux, types composites (collection, interval, tuple, ) Permet de définir des relations et des contraintes arithmétiques, temporelles, logiques Exemple d utilisation de VSL dans MARTE (tiré de la norme MARTE 1.0)

45 Contraintes : OCL OCL (Object Constraint Language) Partie intégrée dans la norme UML depuis UML1.3 Permet de formaliser certains aspects sémantiques sous forme de contraintes logiques Exprime des contraintes sur le modèle ou le méta*-modèle Contraintes sur les relations (xor, frozen, addonly, ordered, subset, ) Invariants sur des classes Pré et Post-conditions des opérations Gardes sur des transitions de diagramme E/T ou des messages de diagramme d interactions Ensemble d objets destinataires d un message Règles de calcul d attributs dérivés Etc. Types de données Scalaires: Boolean, Integer, Real, String Constructeurs : Set, OrderedSet, Bag, Sequence Définition de profils UML Permettent d étendre ou de spécialiser un méta-modèle (exemple: UML) pour un domaine spécifique Exemple : MARTE profile Un profil est défini à partir : D éléments sélectionnés du modèle de référence (MARTE définit les concepts UML qui sont utiles dans le profil) De descriptions sémantiques particulières permettant de préciser la sémantique en cas d ambiguïté dans le méta-modèle de référence (exemple : fonctionnement des machines à état) De stéréotypes, tagged values, et contraintes Et éventuellement De notations supplémentaires De règles de transformation de modèles, validation, présentation

46 Une norme qui semble émerger pour le temps réel : MARTE Modeling and Analysis of Real-Time Embedded Systems Version 1.0, 2009, 738p. Intègre le VSL à la définition de paramètres. Précise les comportements et introduit la notion de mode de fonctionnement Non-functional Properties: Notion d horloges (logique, discrète, Définitions de types de base, Continue, ) et d unités de temps, de débits, Generic Resource Modelling: d énergie ainsi que les relationsdef. de ressources logicielles entre unités (1 s = 1000 ms) (ex: scheduler) et matérielles (ex: processeur) Allocation d entités à des ressources (allocation spatiale mémoire, de calcul, À un ordonnanceur, etc.) Generic Component Model Profil orienté composants (inspiré d AADL) High Level Application Modeling : définit les modèles RtUnit, PpUnit, RtAction, etc. Software/Hardware Resource Modeling: définition utiles pour la modélisation de supports d exécution (RTOS, processeur) Generic Quantitative Analysis Modeling : modèles de base pour l étude de perf. et l ordonnancement RMA Schedulability Analysis Modeling : définit des propriétés d ordonnançabilité (but=>les utiliser dans un outil d ordo.) Performance Analysis Modeling : propriétés pour l étude de perf. orientée réseaux 92 Reste à intégrer UML + temps réel Proposer des méthodologies Limitant le surdimensionnement Tirant parti de méthodes de validation efficace Combinant analyse de sensibilité et méthodes avancées de validation Evolutives Modèles évoluent Méthodes évoluent Questions auxquelles on peut répondre

47 Overview of FA Vehicle Dynamics including all classes belonging to this FA (classes from other FAs are not included at this time) Göran Lundqvist, ( ) BrakeF luids witch (from Basic Layer)... ) R eleaseswit chif (from D river.. I nput.) ) WheelSpeedS ensor (from Basic Layer)...) 4 1 EBASwitch (f rom Driver... Input) ) EBASwitch Lamp (from D river.. I nf.) orm at ion) Electrical Parking Br ake EPBSwitc hif (f rom Driver...) Input) M EPBActuatorIF (from Basic Lay... M Hardw irem M EPBActua tor 1 2 (f rom Basic...) Layer) Co o lan t F an Co n trol Engine Control ECM TempS ensor (from Basic Layer)... ) Engine Vehicle Data Management Additive Dosing Control PiezoSens H ardw ire or (from Basic... Layer) ) D osingpu mp (from Basic... Layer) ) Engine Mode Man agem ent FuelPump (f rom Basic...) Layer) Antilock Braking Emegency Brake Assist C oldz onec oolingc ontroller (from B asic Lay... Glowplug Heating Control H ardwire GlowPlug (from Basic... ) Layer) Engine Cranking StartButtonC M ontrol Gear Shift Up Control 1 Ha rdw i re WaterInFuelSe ns or (from B asic Lay... D ieselfilterwarmerc ontroller (f rom Basic Lay... AmbientTemp Sensor (from Environment)...) F uellid (from Basic...) Layer) EPBVehicleState Estimator (from Vehicle Lay... C oolantfa n (from Basic...) Layer) GaseousFuel Level (from Basic Layer)... ) TextDispla y InfoSymbo l H ardwire (f rom Driver...) Inf ormat ion) H ar dwi re GearShiftU pif Har dw i re (f rom Driver...) I nformation) Hardw ire H ardw ire (f rom Driver.. Information).) BrakeF luidlevelif (f rom D river I nformati... EPBDriverInputEvaluator (from Driver I np... 2 EPBBridge&CurrentMeas (from Basic Lay... H ardw ire WheelSpeedSensorI F (f rom Basic Lay... EBASwitchIF (f rom Driver Inp... PiezoSensorIF (f rom Basic Lay... DosingPumpIF (from B asic Lay... Fuel Pump Control IgnKeyPosWakeup (from Driver I nput ) H ardwire << Out>> WakeU p << PWM 300Hz> > GlowIndicator (f ro m Driver Inf ormat...) ion) M M M OM AC ontrol (from V ehicle Lay... Hardw ire BrakeController (from Basic Lay... M H ardwire Tyre Deflation Detection FuelLidIF (f rom Basic Lay... TyreStatusRe ceiver (from Basic Layer)... ) PW M _Signal TyreD eflationindic ationif (from Driver I nf orm at... ion) ) H ardwire M GaseousFuelLevelIF (fro m B as ic La y... DrivingC ycleofft ime Calculator GlowIndicato rif (f rom Basic Lay... (from Driver I. nf.. ) orm at ion) BCM D riverinf oif (f rom Driver I nformation)...) EPBC ontroller (from B asic Lay... AmbientTempIF (from E nvironme... EngineWarning IndIF (from Driver I nform ati... Ga seousfu el Switch (f rom Basic Layer)...) EngineStateM anager (f rom Basic Lay... FuelPump Controll erc EM (from B as ic La y... Eng inec ranking Controller (f rom Basic Lay... WheelSpeedCalculations (from Basic Lay... Emerg encybrakec ontroller (from B asic Lay... CoolantFanC ontroller (from B asi c Lay... EBADriverIn foif Gl owplug Heating Con troller (from Basic Lay... GearShiftUpC ontroller (from Vehicle Lay... Vehicle Speed (from V ehi cle L ay... (from D rive r. I.. nf ) orm a ti on) EPBD ecis ionm aker (from Vehicle Lay... VehicleInc lina tionif (from V ehicle Layer)... ) EPBDriverIn foif EngineController (f rom Basic Lay... (f rom Driver. Informat.. ) ion) ColdZoneCooling A ctuator (from Basic Lay... EngineVehicleDataM anag er (f rom Basic Lay... CC PT este r (from Basic...) Layer) AdditiveM an ager (from B asi c. Lay.. ) er) FuelPumpC ontrollerecm (from Basic Lay... StartR elay (f rom Basic...) Layer) StartD riverin foi F TyreD eflationd etec tor (f rom Basic Lay... PN IF (from Driver... ) I nput ) (from D rive r I.. nforma.) ti on) AW D AWD TempSen sor (from Basic Lay... AWD Pressure Sen sor (from B as ic La y... TorqueM anager (from Vehicle Lay... Re vers eg ears witchif (fro m Driver I np... AWD FunctionController (f rom Vehicle Lay... AWD Feeder Pump (f rom Basic Layer)...) AWDValve (from Basic... Layer) ) Powertrain Control WheelTractionT orque Distribution (from Vehicle Lay... WheelT orquearbitration (f rom Vehicle Lay... AWDD riverinf oif (f rom Driver I nformation)...) WinterM odem a na ger (from Vehicle Lay... CMbB FCW Adaptive Cruise Control CADS Mode&HMI Man ager F CWSwit cha nalysis CM bbcontroller (from V ehicle Lay... R atiom ana ger (from V ehicle Lay... TipModeM an ag er (from Driver I nput... ) ) C VSensorInt erface (from Environment)...) (f rom D river Inpu... ) t) ForwardC ollisionwarningc ontroller (f rom Vehicle Lay... RatioActuator (from Basic Layer) R atio Actu ato r Sh iftlock (from Driver Inf orm at ion) Long Rang eobjectsensor (f rom Environm e... AdaptiveC ruisec ontroller (from V ehicle Lay... Shiftloc km anag er (from Basic Layer) LockStatusC ontr ol (from D rive r Inp ut ) GearSelector TransmissionD riverinfoi (f rom Driver Input) F ShiftlockActuator (from Driver I nput) C AD SM onitor (f rom Vehicle Lay... BrakePedalPosition Validati on (f rom Driver Inp... C lutchpedalposition Validation (f rom Driver Inp... T OC on troller (f rom Vehicle Layer) C AD SH M IM anager (from D river Inf orm at i... Stability & Traction Control WheelAngularAcc Estimator M SRC ontr oller (f rom Basic Lay... H DC Information LampIF (f rom D river Inf ormat... ) ion) RoadFrictionIndicator (from Basic Lay... (from Vehicle... ) Layer) Cr uise Co n tr ol H ar dwi re TractionControlAWDI ntervention (f rom Vehicle Lay... BrakeLig htswitchvalidation (from Driver I np... C C LampI F (from Driver... I) nformation) SteeringWheelAng le (from Driver I nput ) C CD Controller (f ro m Basic Layer) BodyVertAc csen si F (fro m V eh icle Lay er) AccPedalPosition Validation (f rom D rive r Inp... C ruisecontroller (from V ehicle Lay... C AD S Mod em anager (from Vehicle Layer)... ) Stability&T ractionc ontroller (f rom Vehicle Lay... H illd escentcontroller (from Vehicle Lay... C lutchpedalswitchvalidation (f rom Driver Inp... VehicleSpeedLimit Controller (from V ehicle Lay... AYC Controller (f rom Vehicle Lay... EHPASSte er ingc ontroller (from B asic Layer) Terrain Optimisatio n RotarySwitchIF (f rom D rive r Inp ut ) F CWVisualInte rface (from Driver I nform...) ation) H i ll D esce nt Co n t rol HD C Switc hif Active Yaw Control Bod yse ns orif Road Friction Indication C CButtonsIF2 (from D river I np... MSR C on trol Pedals Vehicle Speed L imitati on EHPAS Steering Control EPSWarningIF (f rom Driver Inf ormat ion) T OD riverinfoif (f rom Driver Inf ormat ion) CADSDriverI nfoif (from D riv er I n... fo ) rm at ion ) BrakeSwitch esif (from Driver...) I nput ) Slip&FrictionEs timator (f rom Basic Lay... HD C M essa g eif RF ID riverinfoif (f rom Driver Inf ormat...) ion) BrakeD iag nostic Switc hif (from Driver Inp... CC Butt ons IF1 Hill Launch Assist (f ro m Driv.. er.) In put) H D CWarni ng IF (fro m D riv er... In) fo rmation ) (f rom Driver. Inf..) ormat ion) (f rom Vehicle...) Layer) BodySe ns oraw D IF (f rom V ehicle L ay... (f rom Driver... I) nput ) ElSer vop um pif (from B asi c Lay er) Continuously Controlled Damping D ampingc ontrolr u Sus pvertpos itions nlevel en sif H LAController (f rom B asic Laye r) (f rom Vehicle Layer) VertM otionestimation (from V ehicle Layer) IndividualD amperc ontrol (f ro m Basic Layer) ClutchPedalSwitc h 25%IF (from D riv er I n p... M PBSwitchIF (f rom Driver Inp... (f rom Vehicle Layer) DamperC urrentc ontrol (f ro m Bas ic La yer) HLADr iver Inf o (f rom Driver Information) ID CM odeinfoif (f rom D rive r Inp ut ) 93 Introduction Enjeux industriels Enjeux Surdimensionnement industriels de demain Cycle de développement Enjeux industriels de demain Introduction Enjeux Dimension Cycle de dévt Demain 94 Augmentation du nombre de fonctionnalités Automobile 90% des innovations sont logicielles 35% du coût total Complexité Logicielle/Matérielle Complexité logicielle Fonctions Calculateurs Complexité matérielle Fonctionnalités Dépendances fonctionnelles New S80 S40 S PV 140