CEA LIST

Transcription

CEA LIST

CEA LIST
Compilation et noyau d'exécution dans
l'approche OASIS pour la réalisation des
systèmes temps-réel multitâche et déterministe
Vincent DAVID
[email protected]
Laboratoire d' Intégration des Systèmes et des Technologies
Objectifs, contexte, concepts
– Le déterminisme et la sûreté de fonctionnement
– L’approche OASIS
La mise en œuvre dans une chaîne d’outils
– Compilation et génération de code
– Runtime et noyau d’exécution
Focus sur dimensionnement, testabilité et mise au point
Perspectives avancées
– Aspects distribués
– Systèmes critiques/non critiques
Bref historique
Réacteur 1300 MW : système de CC numérique (1ère génération
avec logiciels classés de sûreté 1E)
– 1985, 8 unités P4, 12 unités P’4 et P’’4
– plus de 350 années de fonctionnement réacteur cumulées (2003)
Réacteur 1450 MW : système de CC numérique (2ème génération)
– 1996, 4 unités N4
– plus de 30 années de fonctionnement réacteur cumulées (2003)
Etapes principales du projet OASIS
–
–
–
–
1993 Æ 1995 : analyse des différentes approches
1996 Æ 2000 : élaboration des concepts OASIS et outils prototypes
2001 Æ 2003 : pré-industrialisation
2003 Æ 2006 : industrialisation dans le cadre du projet QDS/OASIS
Partenaires
– 1993 Æ 2000 : CEA – EDF – FRAMATOME
– 2001 Æ 200x : CEA – FRAMATOME (AREVA-NP)
Objectifs : performances et sûreté
Diminuer les coûts de développement, de qualification et d’architecture
– plus faciles à concevoir, à réaliser, à maintenir (productivité)
– plus faciles à tester, à vérifier et à valider (productivité et qualification)
– plus performants, trouver le bon dimensionnement (meilleure intégration)
Meilleures intégration, modularité et flexibilité
– permettre un fonctionnement « multitâches »
• avec des échelles de temps multiples
– « composants » temps-réel, interface et comportement parfaitement définis et
maîtrisés
• interactions déterministes des « composants »
• (pré-)certification générique de systèmes à logiciel prépondérant
– réduire le nombre de composants matériels (ECU, réseaux…)
Meilleure sûreté de fonctionnement des ECU
– garantir un fonctionnement déterministe, indépendamment des problèmes
d’ordonnancement
– supporter des mécanismes de détection et de confinement d’anomalies de
fonctionnement (ségrégation)
=> Approche multitâche orientée temps-réel et sûreté de fonctionnement
Sûreté de fonctionnement
Confiance fondée sur quelques grands principes
1. robustesse, tolérance aux fautes
(détection et confinement d’anomalies, modes dégradés, etc.)
2. maîtrise des mécanismes mis en œuvre
(ex : problèmes des logiciels à interruptions)
3. déterminisme comportemental
(reproductibilité des tests : les mêmes causes impliquent les mêmes effets)
4. application du principe de diversification
(prévenir les pannes de cause commune, ex : redondance ou div. fonct., etc.)
5. défense en profondeur
OASIS s’attaque aux points 1, 2, 3 et facilite la mise en œuvre du
point 4 (meilleure intégration)
S’inspirer du multitâche, mais viser le
déterminisme système
Ne pas introduire de sources d’asynchronismes dans la conception des
applications (e.g. pas d’entrées/sorties sous interruptions)
– dominer les asynchronismes dus aux temps d’exécution variables
• pour garantir le déterminisme
• pour maîtriser le dimensionnement (performances)
Proposer un modèle multitâche communiquant
– avec un partage sécurisé des ressources
– sur des cibles matérielles standards
Simplifier les problèmes de coordination des activités exprimées en
conception
Définir une approche modulaire/compositionnelle
– interactions entre modules totalement spécifiées et maîtrisées
– réduire les difficultés de mise au point, de tests et de validation (test et déterminisme)
Le fonctionnement TT dans OASIS
Le système est cadencé par le temps réel (Time-Triggered)
– tous les traitements prennent place entre deux instants du système
(mais pas forcément consécutifs) :
• les exécutions asynchrones sont synchronisées (synchronisme) au début et à la fin des traitements :
isochronisme réel indépendant du matériel
– tous les transferts de données entre « tâches » ont lieu à la transition entre deux traitements
Intervalle de temps spécifié
Td
Date de début au plus tôt
Tf
…
Date de fin au plus tard
AE
…
temps physique
Durée d’exécution effective
Cohérence temporelle des échanges (liée aux mécanismes de communication OASIS)
– encapsulation des données et des traitements (donnée protégée et un seul producteur)
– les valeurs des données sur lesquelles travaille une AE ne sont pas sensibles entre Td et Tf
X ∈ p1
déb
H
1
H
2
fin
p
t0
2
–
–
–
principe d’observabilité strict
mise à jour implicite et automatique aux
rythmes définis
dimensionnement automatique et protection
des tampons, optimaux et sûrs
X( t 0 )=X(
)=X(déb )
Cohérence temporelle
Agent consultant décalé (-2)
X0
Agent producteur du flot
X2
X1
X0
X2
X1
X0
Agent consultant en phase (0)
tφ
Ordonnancement et dimensionnement
Les valeurs des données sont indépendantes
– des durées d’exécution réelles, de la politique d’ordonnancement, de la
fragmentation des AE
=> Le comportement temps-réel est indépendant de l’ordonnancement
Une condition nécessaire et suffisante de dimensionnement
– un surgraphe représente tous les comportements temporels possibles d’une
tâche du point de vue des synchronisations temporelles
0
1
(2)
(3)
4
5
…
Hω
– la composition de ces surgraphes permet de connaître tous les intervalles
temporels partagés par les traitements de chaque tâche
• le produit synchronisé est l’opération mathématique de composition des surgraphes
• le « graphe » obtenu contient TOUS les entrelacements possibles des traitements
– engendre un système d’équations et d’inéquations temporelles
=> Démonstration du dimensionnement
[ICECCS 98, ISOLA 07]
Mise en œuvre d'OASIS et choix primordiaux
Pas de rupture culturelle de l'entreprise, mais une rupture technologique pour la sûreté
–
–
–
utilisation d’environnement et de plateforme standard : C, gcc, gld, etc.
portabilité et pérennité des développements
qualité des outils (taille des problèmes traités, performances, traçabilité, etc.)
Description aisée d’une conception OASIS
–
–
Le temps, les agents, les communications, etc.
Fusionner les aspects OASIS et les aspects algorithmes classiques
Limiter les erreurs
–
–
–
ª
Approche déclarative (spécification du besoin) plutôt qu’impérative (appels de fonctions ou de
primitives)
Contrôle de la conception (cohérence du modèle) et moyens d’analyses d’une conception
(à différents niveaux)
Dégager le concepteur des calculs (sur le temps, le dimensionnement, etc.), des problèmes de
codage
Définition du langage ΨC et compilation de la conception OASIS décrite
Extension complète du langage C :
–
–
–
–
–
Multitâche : définition des tâches (agent), de leur code algorithmique dont leur point d’entrée
(body start)
Communications inter-agents : interfaces et manipulations des flots de données temps-réel et
des messages temporels
Comportement temps-réel : au sein des algorithmes de calcul, expression du temps et des
synchronisations temporelles (advance, before, …)
Le code ΨC et l’algorithmique des agents se base sur les instructions du langage C
(fonctions C, intr. préprocesseur, etc.)
Englobe la norme C ISO/CEI 9899:1989 (ANSI-C) et sa bibliothèque standard
Exemple d’écriture du ΨC
Un agent avance dans le temps par sauts successifs le long d’une
échelle de temps (horloge de base de la tâche) définie par le
concepteur pour chaque agent
– Les sauts peuvent être de longueurs différentes (comme ci-dessous 1-3-1)
…
Hω
temps
clock HBASE= gtc1(0, 1); /* 1 ms */
application demo(inittime=99) with HBASE;
agent ag1tst(starttime= 1) with HBASE
{
body start
{
/* proc 1 */ advance(1);
}
}
Initialisation TT :
– Chaque tâche démarre à
partir d’un instant spécifié
de son horloge de base
après le démarrage TT de
l’application
– La valeur initiale du temps
TT de l’application est elle
aussi prédéfinie par le
concepteur
Structuration d’une application ΨC
Outils supports de conception, de génération de code, d’analyse, de
dimensionnement, support d’exécution et de simulation
– compilation : expression des algorithmes avec le cadencement temps-réel
– production automatique du code exécutable et des graphes de contrôle et des
structures de communication
– noyau générique d'exécution temps-réel orienté sûreté
– exécution réelle en temps réel ou simulé (‘simulation exacte’ car un seul
comportement possible) sur une API noyau différente (e.g. POSIX)
– dimensionnement des ressources d’exécution (tampons, etc.)
Comme pour une chaîne de développement standard C
– Unité de compilation séparée des codes sources : fichiers .psy contenant un ou
plusieurs agents
• Puis compilation de toute l’application (ensemble de fichiers Ψ qui la compose)
– Maîtrise du processus de compilation ‘front-end’
• Lors de la 1ère phase de compilation, création d’une arborescence (par fichier Ψ)
– Catalogues conservés pour traçabilité et qualification
– Documentation (e.g. graphes format graphviz) engendré pour traçabilité et qualification
• Dans la 2ème phase de compilation, création d’un répertoire avec le code généré pour
tous les éléments de l’application
– Possibilité d’utiliser du code algorithmique en bibliothèque ou pré-compilé et de ne
l’introduire que lors de la phase d’éditions de liens & construction du binaire
Généricité et réutilisation au de-delà d’une chaîne de développement standard
– Réutilisation d’agents génériques au niveau de leur code binaire (sans les
recompiler, seule l’édition de liens est impactée) au sein d’applications ΨC
Chaîne de génération de code OASIS simplifiée
Codes ΨC
Application
Outil de documentation
Documentation
Elaborée
Outils d’analyse et de vérification
CNS
Dimensionnement
Compilation (1)
Tables
Doc.
...
Compilation (2)
Codes C
Tâches
Application
Codes C
Runtime
Application
Exécution exacte
en temps simulé
Code C
CS/μΝ
Code cible.s
Codes Objets
Tâches
Application
Codes Objets
Runtime
Application
Code objet
CS/μΝ
Segmentation
Images mémoires
Edition de lien finale
Code Exécutable
Le compilateur ΨC, cyc (1/3)
C’est un Lexeur/Parseur/Checkeur :
– Analyse lexicale, syntaxique de tout le Ψ et le C
– Analyse sémantique de tout le Ψ et une grande partie du C
– NB : Les vérifications entre les différentes unités de compilation sont faites
dans la deuxième phase de compilation
C’est un Générateur de code :
– Traduction du code exécutable en C avec insertion de fonctions spéciales
– Traduction de la structure du code (pour la compilation des graphes de
contrôle)
– Extraction d’éléments de déclaration (les types, etc.)
Il a été réalisé :
– Sans récursivité
– Sans gestion dynamique de la mémoire
– Pour que le code soit engendré via une seule fonction pour permettre
traduction en ligne/colonne
Toutes ces opérations sont traçables et lisibles
Le ΨC est plus typé que le C :
– En vue d’une vérification exhaustive de la cohérence de tous les types de
l’application et du runtime typé, le compilateur ΨC tague ou retague :
• Les noms de variables liées aux communications (par des noms et non par des
numéros)
• Les noms de type de struct/union/enum
• Les noms de typedef
Couple ( parseur ΨC ; parseur compilateur C )
– Organisation de la compilation pour démasquer une erreur s’il en existe une
pour permettre une détection
• Soit au niveau de cyc (e.g. interfaces de communication)
• Soit au niveau du compilateur C
– S’appuie sur le retaggage
– Pour permettre une analyse plus approfondie par des outils d’analyse
statique complémentaires
• Exemple : lint / script PsyLint et qac / script PsyQac
– Pour permettre d’autres couplages comme
• Réalisation d’un outil d’extraction & mise en forme automatique des
commentaires pour élaborer la réprésentation graphique des
algorithmes ΨC et C
Sens d’une erreur
– Pas de warning : c’est correct ou c’est incorrect
– Une seule erreur stoppera la suite de la génération de code
– Mais cyc tente de poursuivre l’analyse jusqu’à 50 erreurs
Vérifications effectuées
– Les mots réservés (_psy)
– Les erreurs de syntaxes et sémantique ΨC
• Ex : next indéfini, continue hors boucle, instructions inatteignables, etc.
– Calcule et vérifie les horloges et les contraintes d’inclusion
– Les déclarations Ψ, omises, multiples
– Des règles supplémentaires
• Ex : */const/volatile/void dans une struct d’une temporelle ou mesbox
• Ex : pas de goto arrière, label manquant, pas de goto entrant dans un
scope
Intègre de la programmation défensive (saturation des tables
internes et incohérences)
Compilation de graphes (1/3)
Point de départ : code ΨC de chaque agent
Le compilateur a construit pour chaque fichier .psy, son arbre de
syntaxe abstraite
– il contient toutes les règles de grammaire utilisées
• dont les instructions C conditionnelles et toutes les instructions Ψ (advance, …)
– et leur agencement dans le code (tient compte des boucles, branchements
conditionnels)
Des graphes intermédiaires sont engendrés (Psy1 et Psy1g fic.psy)
pour pouvoir
– se limiter aux seuls nœuds/arcs intéressants du point de vue du flot
d’exécution et des contraintes temporelles
– calculer les contraintes temporelles de chaque portion de code (date de
début au plus tôt, date de fin au plus tard ou échéances)
Après réduction, on obtient un graphe minimal par agent contenant
– Les contraintes temporelles de chaque traitement de l’agent
– Tous leurs enchaînements possibles dans le code l’agent
C’est le graphe de contrôle d’exécution de l’agent
Caractéristiques d’un graphe de contrôle d’exécution :
– Contient des nœuds de 4 types : advance, update, send, when
• Pour chaque nœud, il est possible de les lier au code source de l’agent
via leur numéro
– Contient des arcs orientés qui correspondent à des portions de code
exécutable
• Congruence entre les arcs et des lignes du code source
• Un arc pourrait ne jamais être parcouru lors de l’exécution (car
dépendant de la logique d’instructions conditionnelles précédentes)
• Un arc peut contenir plusieurs branches conditionnelles
Ce graphe détermine tous les appels possibles de l’agent au
micronoyau
Tous les comportements temporels possibles d’un agent sont
inclus dans son graphe de contrôle d’exécution
– Élément de base autonome et indépendant
Les graphes de contrôle d’exécution sont utilisés
– Pour être animé, dans le cadre d’une exécution réelle en temps
simulé (sans la machine cible)
– Pour contrôler l’exécution : ils sont stockés dans le runtime de
l’agent
Pour connaître tous les points de synchronisation temporels d’un
agent, il est nécessaire de parcourir le graphe d’exécution
– Définition des points de synchronisation : séparation temporelle
entre deux traitements (traits verticaux dans les chronogrammes)
– Muni de tables complémentaires (bornes de boucles, période &
phase des horloges)
– Afin de le déployer dans le temps et de déterminer les états
temporels équivalents (congruence temporelle et de valeur d’indices
de boucles)
– Obtention d’un nouveau graphe où seuls les nœuds de
synchronisations temporelles (advance) sont conservés : le
surgraphe d’un agent
Notion de surgraphe d’un agent
…
Hω
temps
clock HBASE= gtc1(0, 1); /* 1 ms */
application demo(inittime=99) with HBASE;
agent ag1tst(starttime= 1) with HBASE
{
body start
{
}
}
compilation
Calcul du surgraphe d’un agent (1/4)
AgDemo
(MS)
Horloge HB=5*MS
Inittime
1000s
Lecture des données d’un coupleur toutes les 5 ms
A.S.A. (1)
Graphe de contrôle (2) (4)
Surgraphe (3)
Traces d’exécution
simulée
La compilation ΨC et la génération de code C
(1/2)
Chaîne de compilation :
– gère différentes unités de compilation, les numéros de lignes pour les codes
d’erreurs (cf. traçabilité), etc.
– calcule les contraintes temporelles
– calcule les dimensions des tampons
Code exécutable engendré directement à partir de la conception en ΨC
– génération des données et codes de runtime pour chaque agent
– génération des données de runtime de l’application pour le Noyau
En ΨC, il n’existe que des primitives de programmation déclaratives :
– pas d’appel noyau direct, tout est compilé à partir de la description haut niveau
Après compilation, une seule primitive d’exécution (!) :
–
–
–
–
demander le changement de nœud dans le graphe de contrôle
la sémantique est compilée dans la runtime avec ses tables
le graphe de contrôle de l’automate de chaque agent est fourni à la runtime
le contrôle de cohérence est assuré par le Noyau
La compilation ΨC et la génération de code C
(2/2)
Traçabilité de la génération de code C à partir du ΨC
– Dans la structuration des fichiers engendrés
• Nommage en fonction des unités de compilation séparés et de leur rôle
• Conservation des tables de calculs intermédiaires
– Au sein des fichiers engendrés eux-mêmes
• Traduction incrémentale en ligne et en colonne pour
– Les codes engendrés et des codes applicatifs algorithmiques conservés
Respect de la mise en forme du fichier source Ψ initial qui permet
– Une mise au point efficace lors de la compilation : le report d’erreur
se fait par rapport au fichier initial
– Un interfaçage correct avec outils de mise au point existant dans la
chaîne de compilation C standard tel que
• Analyse / mise au point du code binaire (e.g. gdb, ddd)
– Points d’arrêt au sein du code Ψ, du code engendré ou du code applicatif
• Couverture de code (e.g. gcov) quand couplé à l’outil d’exécution
exacte POSIX en temps simulé
Anomalies, déterminisme et modularité
Quelques défauts résiduels peuvent toujours être présents
– le nombre de défauts non révélés doit être aussi bas que possible
– certains défauts peuvent être activés sans être détectés par le test
• Exemple de non déterminisme : lecture d’une mauvaise adresse contenant une valeur
dépendante de l’instant physique de l’accès (dans ce cas, le comportement observé
sera dépendant de l’implantation, de la vitesse du processeur, de l’ordonnancement)
Principe de déterminisme fort dans OASIS
– la conséquence d’une anomalie doit être déterministe
• il faut confiner les anomalies et maîtriser leurs conséquences
• forte intégration => nouveaux mécanismes de détection et de confinement
déterministes
– il faut
• détecter à l’exécution toutes les tentatives de violation de la séparation des tâches
• contrôler le dimensionnement des ressources d’exécution (tampons, quotas CPU, etc.)
• contrôler l’enchaînement séquentielle des actions, etc.
– l’impact d’une anomalie de fonctionnement est maîtrisé et déterministe
Définit une architecture logicielle modulaire
– généricité des tâches au niveau du code objet (binaire)
• pas de recompilation
• seulement le runtime à engendrer et l’édition de liens à refaire
– permet une approche multi-fournisseur
Organisation défensive des programmes
exécutables
Mode
d’exécution
utilisateur
Code et données
d’une tâche
…
Code et données
d’une tâche
Codes et données
applicatifs
trap
Prolongement du
contexte d’une
tâche dans la
couche système
Mode
d’exécution
privilégié
Prolongement du
contexte d’une
tâche dans la
couche système
Données relatives
d’une application
(runtime)
Code de la couche système
move sr
Données et code du micro-noyau
horloge
–
–
(gestion de l’allocation du processeur aux tâches et gestion du temps)
contextes d’exécution distincts hors de CS et différents internes à CS, contexte μN indépendant
segmentation particulière des exécutables et des données
•
–
–
–
–
Code générique
(Noyau)
conception orienté sûreté et exploitation spécifique des mécanismes de protection liés au H/W
contrôle de conformité de l’exécution de chaque tâche
contrôle toutes les hypothèses de dimensionnement (quotas, tampons, etc.)
les préemptions de tâches sont toutes contrôlées par le μNoyau atomique
CS 100% préemptible
Noyau générique d’exécution (1/2)
Le Noyau n’est pas un moniteur standard
– c’est un exécuteur orienté sûreté des graphes de contrôle d’exécution de
chaque tâche
Des mécanismes de détection et confinement d’anomalies de
fonctionnement
– les tentatives de violation d’un quota de temps imparti ou la violation d’un
graphe de contrôle ou la violation du dimensionnement d’un tampon
– conception orienté sûreté et exploitation spécifique des mécanismes de
protection liés au H/W (MMU –descripteurs statiques- et mode privilégié)
(brevet d’invention)
– l’impact d’une anomalie de fonctionnement est maîtrisé et déterministe
Le μNoyau est un automate cadencé par le temps (programme
séquentiel non préempté) :
– la seule source d’interruption (l’horloge système) est utilisée pour la
détection et le confinement d’anomalies et les synchronisations temporelles
– les préemptions de tâches sont toutes contrôlées par le μNoyau
– la CS est entiérement lock-free/wait-free (100% préemtible)
• activité incluse dans la gestion des quotas
Noyau d’exécution sur IA32 (2/2)
Portabilité
–
–
Couche système écrite en C
Micronoyau écrit en C pour toutes les parties indépendantes du matériel (assembleur sinon)
Mise en œuvre des E/S matérielles spécifiques sur Intel IA32/PC-AT (IO_S)
–
–
Dont les fonctions spécifiques avec droits superviseur restreints pour effectuer les opérations
d’E/S (in/out)
Pour que chaque agent puisse faire appel aux fonctions d’E/S qui nécessitent ces privilèges avec
contrôle d’accès
Contrôle de l’initialisation et de la configuration des chipsets au démarrage (définition
du mode INIT_S)
–
–
Une fois que le BIOS a donné la main au bootloader OASIS, il n’est plus jamais utilisé
Bootloader OASIS
• Permet de télécharger les images noyau séparément des images applicatives sur mémoire
statique de la carte via les ports réseaux
– Gestion d’un protocole de communication pour le téléchargement par paquets
– Contrôle des réceptions via un protocole spécifique et cryptage des binaires
• Contrôles sur les chipsets
– Non utilisés : mis en mode désactivé
– Utilisés : configuration puis avant la fin de la séquence de démarrage vérification de la conformité de
la configuration mise en œuvre
Performance
–
Temps de passage dans le micronoyau de moins d’une microseconde
Editions de liens, segmentation mémoire (1/2)
Psyld réalise l’édition de liens de tous les _.o d’une application
pour la plateforme cible
– Première édition de liens entre chaque agent avec ses librairies et
sa partie de runtime correspondant
• Segmentation mémoire
– Implantation du pont (interface entre le noyau générique et une application)
– Implantation de chaque agent
– Alignement de tous les segments pour pagination
• genMMU fait les tables MMU correspondantes
– Compilation des tables
– Implantation
– Seconde édition de liens entre toutes les morceaux
• Produit le résultat _.ex
– NB : le Noyau n’est pas recompilé, ni relinké
Ldint réalise l’édition de liens de tous les _.o d’une application
pour la simulation exacte sur POSIX
– Idem avec programme principal (main en bibliothèque : inter.o) et
sans implantation mémoire
Editions de liens, segmentation mémoire (2/2)
Organisation de la mémoire telle que
– Les piles des agents sont séparées
• Placées dans des segments tels que tout débordement est
détecté par la protection mémoire
– Pas de translation d’adresse : mapping direct (bijection)
entre adresses logiques et physiques
• Facilite la détection d’erreur
• Permet une mise au point aisée
– Pas de dépendances cachées que ce soit
• Via les librairies applicatives
• Via le code couche système
– Toutes les tables de symboles sont conservées
• Globales (tables systèmes, tables de protection mémoire, etc.)
• Locales aux agents (données/fonctions locales, en
bibliothèque, etc.)
Mise au point - exécution en temps simulé (1/2)
Objectif : exécuter une application écrite en ΨC dans un environnement
standard comme POSIX (machine de développement)
L’outil repose sur le principe de déterminisme logique et temporel
d’OASIS
– Résultats indépendant de l’ordonnancement des traitements des agents
L’écoulement du temps réel peut être simulé
Réutilisation (après la fin de Psy2) pour compilation
– Du code engendré lors de la compilation et relatif à l’application
– Du runtime de chaque agent
– De la couche système
– Des fichiers C du micronoyau
Seuls les fichiers assembleurs et les fichiers relatifs à la cible ne sont pas
réutilisés
On peut alors parler d’exécution du code réel en temps simulé
– Gestion du temps via la fonction heureCourante
Mise au point - exécution en temps simulé (2/2)
Fonction centrale de l’outil : ordonnancement
–
–
–
–
Faire progresser le temps et gérer l’activation des agents
Synchroniser les données d’entrée vis-à-vis de l’heure globale
Dater les changements de contexte
Servir les appels systèmes (et éventuellement stocker une trace de ces
appels)
1 processus POSIX par agent et 1 processus POSIX pour l’outil
d’exécution exacte en temps simulé
Options pour l’outil
-t nom_fichier_trace –m nombre_de_lignes_engendrés
-s[p] : exécution séquentielle[parallèle] en temps simulé
-r : exécution temps-réel en time-sharing dans le « grain » POSIX
-R : exécution temps-réel POSIX dans le « grain » POSIX avec priorité (par
défaut)
Obtention de traces exactes exploitables pour la V&V d’une application
– Pour l’analyse du comportement temporel d’un agent
– Pour une pré-analyse de charge (vis-à-vis des quotas)
– Pour l’établissement d’une politique de test via des scénarios temporels
Mise au point sur cible
Objectif : être capable de mettre au point sur cible, i.e. d’insérer des
points d’arrêt
– Positionnement points d’arrêt en fonctionnement temps-réel
• En s’appuyant sur l’exécution cadencée par le temps
– Concernant des applications multitâches
• Possibilité de mise au point agent par agent
– Quelque soit le code concerné, applicatif ou système (Ψ et C)
Noyau indépendant des applications
– Remplacement du noyau standard par celui instrumenté pour mise au point
(via lien série)
• « Hook » sur le lien série pour lire l’ordre d’arrêt et échanger des données pour la
mise au point
• Sans changement de l’applicatif
– Point d’arrêt initial au démarrage du système puis dépendant de l’utilisateur
Maîtrise de la construction de l’empreinte mémoire linéaire
– Possibilité d’utiliser outils standards de mise au point (gdb)
• Par instrumentation du compilateur C
– Pour analyser ou injecter des valeurs directement en mémoire
• Pour données internes ou d’I/O
• Assistance au processus de test d’intégration & validation
Synthèse
Conciliation du déterminisme et du multitâche
– objectifs de sûreté et de performances des systèmes critiques embarqués
– maîtrise des applications temps-réel développées
– maîtrise du dimensionnement
Avantages
–
–
–
–
permet autant de rythmes de temps de cycles que nécessaire
permet de tenir plus facilement la charge sur les temps de cycle
permet des démonstrations de sûreté dès l’étape de conception
difficultés de conception (diagrammes temporels) séparées des difficultés de
dimensionnement (ordonnancement)
– portabilité et pérennité grandement facilitées
• coûts de modification et de maintenance mieux maîtrisés
• véritable approche modulaire pour la composition de tâches temps-réel
– exécution réelle en temps-réel ou simulé sans machine cible
– nombreux mécanismes de détection et de confinement d’anomalies de
fonctionnement
• ségrégation, comportements extrêmes mieux maîtrisés
Transfert industriel dans le domaine nucléaire pour AREVA NP (2003-2006)
– respect des normes et recommandations en vigueur
• standard industriels : C, IA32, etc.
• exigences de sûreté : CEI 60880, RFS
– plateforme innovante QDS/OASIS
– qualification : système classé de sûreté, catégorie A
Dimensionnement / tampons de communication
(1/2)
Principe
– Le concepteur exprime les besoins en communication, les outils de
génération de code calcule la taille des tampons pour la mise en
œuvre
– Calculer automatiquement un majorant le plus proche possible du
maximum atteignable par analyse des informations statiques
recueillies lors de la compilation
Pour les variables temporelles
– Calcul réalisé grâce aux tables extraites de la compilation
– La taille d’un tampon local par consultant a une taille égale à celle
spécifiée dans son interface
– La taille du tampon global est calculé en fonction des sauts
maximums dans le temps du producteur et des consultants vis-à-vis
de la période de l’horloge associée à la variable temporelle
(indépendamment de l’ordonnancement)
Dimensionnement / tampons de communication
(2/2)
Pour les messages
– Calcul de la densité d’émission des messages (N, λ) : il y aura
un maximum de N messages envoyés par l’agent toutes les λ
unités de temps
• Utilisation des surgraphes pour lesquels on a conservé le nœud
send (éventuellement « déplié » N fois)
• Recherche de tous les circuits temporels passant par un nœud
send pour trouver le circuit de valeur minimum λ
– Dimension d’un tampon = N*(1+E(Tmax/λ) )
• Calcul de Tmax :
– Pour les zones d’émissions, égal à la somme de l’échéance du
message et du saut maximum dans le temps de l’agent récepteur
(advance)
– Pour la zone de réception, égal à la somme de la durée que le
message est autorisé à rester dans le tampon et du saut maximum
dans le temps de l’agent récepteur
Dimensionnement CPU / principes
Cadencement TT d’une tâche décrit dans la conception
– Encapsulation du comportement temporel dynamique dans le
surgraphe issu de la compilation
• Enchaînement dynamique des AE d’une tâche
• Echanges de données inter-tâches
Ordonnancement dynamique de l’exécution
– Qui respecte le cadencement TT issu de la conception
• Exécution du graphe de chaque tâche séparément contrôlé par le noyau
– Ordonnancement guidé par les échéances
• Optimal pour le modèle OASIS
• Obtention d’une CNS pour savoir si la propriété de ponctualité est
vérifiée
– Démonstration hors-ligne du dimensionnement
• Basée sur la connaissance des quotas des AE (majorants des temps
d’exécution)
• Surveillance en ligne
– Des quotas (dimensionnement AE)
» Instrumentation du noyau possible pour évaluation des temps d’exécution
– Et des échéances (dimensionnement application)
Dimensionnement CPU / mise en oeuvre
Construction mathématique de la CNS
– Composition des tâches : dépliage « temporel » de chaque surgraphe
– La composition des surgraphes des tâches permet de connaître tous les
intervalles temporels partagés par les traitements de chaque tâche
• Le produit synchronisé est l’opération mathématique de composition des
surgraphes
• Le « graphe » obtenu contient TOUS les entrelacement possibles des traitements
A partir de ce graphe, on peut engendrer un système d’équations et
d’inéquations temporelles
– les équations traduisent le fait qu’un traitement peut être réparti sur
plusieurs intervalles TT (quelque soit la politique d’ordonnancement)
– les inéquations dites « de charge » traduisent que sur un intervalle TT, le
temps d’exécution pris par les traitements (ou portions de) est inférieur à la
durée de l’intervalle
ªLa condition formelle à vérifier est le système d’équations et inéquations
linéaires
Dimensionnement CPU / illustration (1/3)
INIT
N7
Q10
Q1
E12
1Ω
Π
2Ω
Q1
Q10
E11
0
N6
INIT
1
E3
N1
E1
E2
E4
N8
E7
3Ω
N3
E9
Q20
Q10
Q10
α.Q20
β.Q20
1
E5
N2
Q20
Etats (N)
N5
E0
INIT
α+β+γ=1
N9
E6
E10
2
E8
N4
Q11
...
ω2
γ.Q20
3
ω1
4
2
5
1
6
7
1
Q10 +α.Q20 ≤ dTT
6
7
...
temps
La propriété de ponctualité à vérifier représente le fait que :
– Sur chaque fenêtre temporelle, la somme des temps d’exécution des
parties d’AE de chaque tâche doit être inférieure à la durée de la
fenêtre temporelle
– Mieux que la condition suffisante classique : la somme des facteurs
de charge normalisés par tâche
• Lorsque les maxima de chaque AE ne sont pas atteints simultanément
Cela engendre les contraintes suivantes
– Pour chaque arc du produit synchronisé
• Une inéquation sur les portions d’AE exécutés dans l’intervalle (identifié
par j)
Σ[i=1..n] αij . Q( AEi ) ≤ k
with αij in [0,1]
– Pour les nœuds de terminaison des AE du produit synchronisé
• Une équation sur les variables libres α par AE (identifié par i)
Σ[j=1..p] αij = 1
α+β+γ=1
Etats (N)
INÉQUATIONS TEMPORELLES
ÉQUATIONS
E0 : Q1_0 alpha1_0 + Q2_0 alpha2_0 <= k ;
E1 : Q1_0 alpha1_1 + Q2_0 alpha2_1 <= k ;
E2 : Q1_0 alpha1_2 + Q2_0 alpha2_2 <= k ;
E3 : Q1_0 alpha1_3 + Q2_0 alpha2_3 <= k ;
E4 : Q1_1 alpha1_4 + Q2_0 alpha2_4 <= k ;
E5 : Q1_1 alpha1_5 + Q2_0 alpha2_5 <= k ;
E6 : Q1_0 alpha1_6 + Q2_0 alpha2_6 <= k ;
E7 : Q1_1 alpha1_7 + Q2_0 alpha2_7 <= k ;
E8 : Q1_1 alpha1_8 + Q2_0 alpha2_8 <= k ;
E9 : Q1_0 alpha1_9 + Q2_0 alpha2_9 <= k ;
E10:Q1_1 alpha1_10 + Q2_0 alpha2_10 <= k ;
E11:Q1_1 alpha1_11 + Q2_0 alpha2_11 <= k ;
E12:Q1_0 alpha1_12 + Q2_0 alpha2_12 <= k ;
alpha1_0 = 1 ;
alpha2_0 + alpha2_1 + alpha2_2 = 1 ;
alpha1_1 = 1 ;
alpha1_2 = 1 ;
alpha1_3 = 1 ;
alpha1_4 + alpha1_5 = 1 ;
alpha1_6 = 1 ;
alpha1_7 + alpha1_8 = 1 ;
alpha1_9 = 1 ;
alpha1_10 + alpha1_11 = 1 ;
alpha1_12 = 1 ;
Q10
Q10
α.Q20
β.Q20
1
2
Q11
...
ω2
γ.Q20
3
ω1
4
2
5
1
6
7
1
Q10 +α.Q20 ≤ dTT
6
7
...
temps
Dimensionnement CPU / résolution
Résolution d’un problème classique de résolution de contraintes
– L’existence d’une solution garantit un dimensionnement correct
En fait, mieux qu’un critère binaire, ce système permet de
caractériser le dimensionnement optimal :
– Remplacer le membre droit de chaque inéquation h0
– Rechercher sa valeur minimum (h0)min telle que le système ait une
solution
• Si (h0)min < 1, garantie de dimensionnement et obtention de la valeur de
réserve CPU
• Sinon, on obtient l’évaluation de la surcharge CPU
• Dans tous les cas, on a aussi un cas d’exécution des AE des tâches
atteignant cette charge
Le produit synchronisé représente la complexité exacte de
l’entrelacement des AE des tâches dans le temps
– Mais toujours quelque soit le découpage dynamique qui sera réalisé
par l’algorithme d’ordonnancement implanté dans le noyau
• Maîtrise fine des asynchronismes liés aux temps d’exécution (quotas) et
au parallélisme d’exécution
Dimensionnement CPU / bilan
Dans une réalisation avec OASIS
– On tire parti des avantages en terme de flexibilité et disponibilité de l’ordonnancement
dynamique
– Tout en apportant une garantie hors-ligne de sa faisabilité
Le dimensionnement est basé sur l’évaluation de majorants sûrs du temps
d’exécution
– C’est un problème différent de la connaissance des WCET
• Car ils n’influent pas sur le comportement du système
• En cas de viol de quota
– Identification de l’AE défaillante avant qu’elle n’influe sur l’ensemble des tâches à exécuter
– Ségrégation de la défaillance au sein de l’AE et de la tâche et maintien de disponibilité du système
»
Impact limité à l’AE de l’agent, possibilité de continuer l’exécution des autres agents
– L’applicatif impacté peut en tenir en compte pour adapter ses traitements
– Définition d’une méthodologie novatrice pour leur évaluation hors-ligne
Illustration sur un exemple simplifié avec deux tâches périodiques :
Tâche A
Tâche B
temps
Réserve CPU dimensionnée sur chaque fenêtre :
- pour une l’occurrence du pire cas A
- pour l’occurrence du pire cas B
Tâche A
Tâche B
temps
Réserve CPU dimensionnée sur la fenêtre :
- pour une l’occurrence du pire cas A
simultanément avec celui de B
- plus rare => gain en terme de marges
Dimensionnement CPU / en-ligne
Garantie dynamique du dimensionnement CPU :
– À chaque fois qu’une synchronisation temporelle est requise
• ajout d’un traitement de temps bornée
• avec comme échéance la prochaine synchronisation temporelle
– Les changements de contexte sont imputés aux quotas de chaque
traitement des agents
Concept d’agent « bouclier » : incorporation d’un agent supplémentaire
– Ayant pour cycle d’exécution celui de la plus petite période d’horloge
manipulée
– Ayant un temps d’exécution fixé (algorithme séquentiel sans instruction
conditionnelle)
– Si l’application s’exécute en présence de cet agent, on a une garantie du
dimensionnement correct en-ligne
Au delà, on peut paramétrer le temps d’exécution du code de l’agent
bouclier
– En faisant varier le paramètre, on peut déterminer une marge sûre du
dimensionnement du CPU en-ligne (pour validation)
Ce qu’apporte OASIS pour le test (1/2)
Mêmes objectifs et potentiel de test que pour les approches
séquentielles
– Le comportement dynamique du système temps-réel est prédictible et
invariant :
• Tous les tests sont reproductibles
– Recherche exhaustive du pire des cas : tous les comportements sont
accessibles et testables
– Chaque agent est testable séparément (facilite la réutilisation)
• Modularité du code source jusqu’au binaire
Capacité d’évaluer et de tester
– Les performances temps-réel (cf. dimensionnement)
– Le comportement fonctionnel d’une application (tout ou en partie)
Le modèle inclue les aspects temps-réel
– Les graphes de contrôle représentent le comportement dynamique des
agents et contiennent les contraintes temporelles
– Le déterminisme permet de faire des campagnes de tests reproductibles
• Maîtrise temporelle de l’injection des données d’entrées
• Invariance du comportement de l’application entière
Ce qu’apporte OASIS pour le test (2/2)
Tests de mise au point
– Démarche de conception incrémentale
• aspects modulaires pris en compte, mise au point sans machine cible
– Utilisation des graphes issus de la compilation (dont les graphes de
contrôle)
• Génération des chronogrammes induits et comparaison avec les
spécifications
Tests de validation
–
–
–
–
Signification d’un résultat associé à un scénario d’entrée spécifié
Analyse de traces d’exécutions
Couverture des graphes de contrôle
Injection de fautes :
• Modification du code binaire
• Simulation de pannes (ex : capteurs)
Contexte multicalculateur avec composants
standards
Problèmes posés par le calcul distribué
– recherche d’un placement optimal (performance) et sûr (SFC, etc.)
– garantie de l’intégrité et l’uniformité des informations
– dérive non uniforme des horloges locales
Composants standards (Components Off-The-Shelf - COTS)
– diffusion à grande échelle, robustesse de certains composants
– pas entièrement conforme avec les exigences (effort d’intégration et d’adaptation)
=> Objectif : garantir le transport de l’information bout à bout (TR+SdF)
Continuité et intégration avec le modèle OASIS
– intègre déjà de manière réaliste les contraintes temporelles
• délais de communication jamais estimés comme nuls
• diffusion avant l’échéance, approvisionnement après l’échéance
– couches systèmes et matérielles transparentes pour le développeur
– application conçue indépendamment de l’architecture
Interface TDMA avec Ethernet standard (physical layer)
– aucune collision par construction (une collision devient une erreur)
– garantir par construction la ponctualité des communications
– dimensionnement et ordonnancement statique du réseau
• pour vérifier et valider le réseau hors-ligne
• pour détecter un comportement fautif
=> Cadencement global des communications connu de tous
Contenu et contenant des paquets
Cycle réseau calculé automatiquement pour chaque application
Contenu (Lettres)
–
structure d’encapsulation des variables temporelles et des messages
Contenant (Paquets & Segments)
–
Lettre créée
Espace lettre réservé
dimensionnement hors-ligne et constant
Segments
Entête
Queue
Champ “données”
ª Durant l’exécution, la longueur du contenant est indépendante de la quantité de son
contenu
ª Communications répétitives et prédictibles
Facilite la vérification du dimensionnement
–
–
théorie (résolution du système d’équations et d’inéquations)
• le pire des cas est calculable
pratique
• le pire des cas est systématique
Concept de communications intégrées
Préserver la couche système et le μNoyau
–
–
maintenir le niveau de sûreté atteint
disposer d’une solution modulaire
–
Concept d’ombre
–
–
clone mémoire du producteur
localisée sur chaque CPU consommateur
Concept de pilote
–
–
Cadencement du réseau
par construction, un seul CPU occupe le média de
communication à un instant donné
Optimisation possible (A-TDMA)
–
–
utilisation du mécanisme de détection de porteuse
« chevauchement » de plages par construction
•
•
tâche TT de la couche système
contrôle les préparations et réceptions
seulement entre deux émetteurs consécutifs
inversion de paquets impossible
ª espace entre deux paquets consécutifs optimal
PRODUCTEUR
OMBRE CONSOMMATEUR
Remplissage du paquet
Extraction des données
par le consommateur
Mise à jour de l’ombre
Transfert du paquet
PILOTE
COUCHE SYSTEME
CPU1
µNOYAU
BUS
PILOTE
COUCHE SYSTEME
CPU2
µNOYAU
Apports de la solution
Extension transparente et intégrée
Gestion des communications performante et sûre
– parallélisme des communications
• pas de problème de sections critiques
• pas d’opérations séquentielles d’élaboration des paquets
ªles tâches communiquent à leur propre rythme en parallèle
ªle pilote se limite à indiquer l’emplacement des paquets en corrélation avec
la plage prévue
– Occupation du réseau optimale
• pas de perte de bande passante inutile
– μNoyau déclenche précisément la transmission
• plages de longueur nécessaire et suffisante
ª Ponctualité toujours garantie pour toutes les données transférées
OASIS pour les architectures SMP
Modèle et implémentation d’OASIS déjà parallèle :
– OASIS sur monoprocesseur est parallèle multi-tâche
– Synchronisation uniquement par le temps
– Couche système lock-free (pas de verrous)
• Complètement préemptive
– Système cadencé par le temps (TT) de sûreté
• Tous les paramètres des tâches sont connus
Pour le portage SMP, seuls quelques éléments doivent être complétés :
– Assurer la consistance mémoire dans la couche système
• Ajout de barrières de mémoire (spécifie l’ordre des opérations mémoires) par des
instructions assembleur spécifiques
– Besoin de synchronisation de l'horloge entre les processeurs
• Utilisation d'une horloge unique
– Algorithmes d'ordonnancement multiprocesseur
• Plusieurs solutions de mise en œuvre (ordonnancement optimal global,
partitionnement des tâches par cœurs, …)
Du point de vue des applications, c’est complètement transparent
– Seuls le noyau et la chaîne de génération de code sont impactés
Systèmes critiques/non critiques (1/2)
Vers une intégration plus poussée
Other
Application(s)
– réduire les marges de dimensionnement CPU
• pire cas souvent peu réaliste avec les caches
Application(s)
non safety-critical
software
Standard OS
…
– cohabitation tâches critiques et non critiques
– déterminisme du système de calcul
Other appli.-level
System Layer
Other-SL
• pour les parties critiques (SdF)
• quid des parties non critiques temps-réel ?
safety-critical
tasks
Task-level
System Layer
« OASIS » - SL
« OASIS » - μK
Une vision statique du partage des ressources n’est plus satisfaisante
Conception et réalisation d’un logiciel système de base permettant
– la coexistence de différentes couches systèmes («OS») dans le même ECU
• une couche système orientée sûreté (e.g. noyau de type OASIS)
• avec une couche système typique du domaine non critique (API quelconque)
– la cohérence et la protection d’échanges de données autorisés entre les
deux couches systèmes
– un partage sûr des ressources qui sont localement nécessitées par chaque
couche système
• apporter des garanties pour tous les niveaux de criticités
• à moduler selon la catégorie, mais le temps-réel est partout…
=> La cohabitation de différents niveaux de criticité est possible
OASIS
Systèmes critiques/non critiques (2/2)
Approches classiques de la coexistence:
– Partitionnement statique des ressources (y compris temporel)
• Mais impose des contraintes sur l’accès dans chaque partition (e.g. ordonnancement non
optimal)
– Priorité du critique sur le non critique
• Mais pas de contrôle sur l’utilisation des ressources du non critique (e.g. on ne sait pas
quand le non critique s’exécute)
Constat
– Pour une garantie de bon fonctionnement, il faut connaitre le besoin en ressource des
tâches (comme fait dans OASIS)
– Le non-critique s'exécute avec peu de contraintes additionnelles, le critique est garanti
Structuration du système pour permettre le partage dynamique et sûr des
ressources:
– Hiérarchie de composants,
• chaque niveau définit le partage des ressources de ses sous-niveaux
– politiques différentes selon le niveau de criticité
• la connaissance des ressources utilisées par un composant est complète
– chaque niveau responsable des ressources de ses sous-niveaux
– même en présence d'interactions/transferts de ressources transverses entre composants
– Interaction dynamiques (transferts de ressources, communications) entre les composants
basées sur un modèle de protection unique (capacités)
• L'impact d'une défaillance d'un composant est limité et connu
– Telle que toute tâche est considérée comme potentiellement malicieuse (y compris tâches critiques)
• Les ressources ne sont jamais perdues (redémarrage d'un sous-système possible)

CEA LIST

Transcription

Documents pareils

annonce emploi - dessinateur projeteur - EFM

Dimensionnement d`une installation électrique basse tension 2017

DOSSIER SATEC INGENIERIE TYPE MAJ 15-10-14

Bilan Thermique Climatisation – TH00

CPR - VB VH chaufferies

OA-KIT-BASIC

Hi-ToolPower FOR HOME LOGICIEL Hi-ToolPower

FARJAN Sara - Ecole Mohammadia d`ingénieurs