5.1.2 Objectifs du processus de certification . . . 139 5.1.3 B´en´efices du processus d’implantation . . . 139 5.1.4 B´en´efices du processus de certification . . . 141 5.2 Chaˆıne de g´en´eration . . . 141 5.2.1 Travaux existants . . . 141 5.2.2 D´etail du processus de g´en´eration . . . 142 5.3 Patrons de g´en´eration de code . . . 143 5.3.1 Composant processor . . . 144 5.3.2 Composants virtual processor et process . . . . 148 5.3.3 Composant device . . . 149 5.3.4 Composant memory . . . 149 5.3.5 Composant thread . . . 149 5.3.6 Composant data . . . 151 5.3.7 Connections entre composants thread . . . 152 5.3.8 Connections entre composants process . . . 153 5.3.9 Int´egration de code applicatif externe . . . 155 5.3.10 Optimisation . . . 156 5.3.11 R´esum´e des patrons de g´en´eration . . . 158 5.4 Plate-forme pour syst`emes sˆurs et s´ecuris´es . . . . 158 5.4.1 Description g´en´erale de POK . . . 158 5.4.2 Architecture et services . . . 158 5.4.2.1 Couche noyau . . . 159 5.4.2.2 Couche partition (libpok) . . . 160 5.4.2.3 Modularit´e et finesse de configuration . . . 162 5.4.3 M´ecanismes de sˆuret´e/s´ecurit´e . . . 162 5.4.3.1 Isolation temporelle . . . 162 5.4.3.2 Isolation spatiale . . . 163 5.4.3.3 Health Monitoring . . . 164 5.4.3.4 Algorithmes de chiffrement . . . 165 5.4.4 Implantation des pilotes de p´eriph´erique . . . 166 5.4.4.1 Mod`eles et choix d’implantation de POK . 166 5.4.4.2 Nouveaux services introduits . . . 167 5.4.4.3 Implantation . . . 167 5.5 Certification des exigences de la sp´ecification . . . 167
5.5.1 Ordonnancement . . . 168 5.5.1.1 Pr´esentation de l’outil . . . 169 5.5.1.2 Mise en pratique . . . 169 5.5.1.3 Retour d’exp´erience . . . 170 5.5.2 Analyse comportementale . . . 171 5.6 Assurance des exigences des standards de certifi-
cation . . . 172 5.6.1 Contexte . . . 173 5.6.2 Int´egration avec le processus de d´eveloppement . . . 173 5.6.3 Int´erˆet de la g´en´eration de code . . . 174 5.6.4 Retours d’exp´eriences . . . 175
Rappels
Le chapitre pr´ec´edent d´ecrit des patrons de mod´elisation et des r`egles de validation d´edi´ees aux syst`emes partitionn´es. Les patrons guident
le concepteur du syst`eme en indiquant la bonne mani`ere pour re-
pr´esenter le syst`eme et ses caract´eristiques. Les r`egles de validation associ´ees assurent que la sp´ecification cr´e´ee respecte bien les exi-
gences d’une architecture partitionn´ee avec ses caract´eristiques de
s´ecurit´e/sˆuret´e. Ces ´etapes garantissent l’absence d’erreur dans les
sp´ecifications du syst`eme, permettant de proc´eder `a son implanta-
tion et sa certification.
Ce chapitre d´etaille le processus de g´en´eration et de certification `a partir des sp´ecifications valid´ees. Il d´ecrit les outils utilis´es, et expli- cite les garanties apport´ees quant aux m´ecanismes de s´ecurit´e/sˆuret´e implant´es.
Objectifs du chapitre
Ce chapitre a un double objectif : (i) la description du processus de g´en´eration automatique de l’architecture de syst`emes critiques et (ii) leur certification.
Dans un premier temps, il d´etaille le processus de g´en´eration de code `
a partir des sp´ecifications, produisant automatiquement une implan-
tation C de mod`eles AADL. Cette premi`ere partie du chapitre pr´e-
sente les patrons de g´en´eration de code qui transposent les construc-
tions AADL vers C et leurs avantages (r´eduction de l’empreinte m´e-
moire, pr´edictabilit´e du code, etc.).
Dans un second temps, ce chapitre pr´esente la plate-forme AADL
pour les applications sˆures et s´ecuris´ees : POK [33, 32]. Celle-ci in- t`egre le code g´en´er´e et assure les propri´et´es de s´ecurit´e et de sˆuret´e
d´ecrites par le concepteur du syst`eme (isolation spatiale/temporelle,
confinement des communications, etc.).
Par ailleurs, nous proposons des outils d’analyse `a l’ex´ecution pour :
1. v´erifier le comportement du syst`eme implant´e par rapport aux
sp´ecifications, garantissant la conformit´e de l’implantation par rapport `a la description de l’utilisateur.
2. assurer la garantie des exigences des standards de certifications (par exemple : couverture de code).
Enfin, ce chapitre met l’accent sur l’utilit´e de l’approche dirig´ee par
les mod`eles : chaque ´etape du processus repose sur l’utilisation des
5.1
Aper¸cu du processus de g´en´eration
Les sections suivantes situent les deux ´etapes abord´ees dans ce chapitre
par rapport `a nos objectifs :
1. implantation automatique `a partir des sp´ecifications (second objectif de
la th`ese, section 1.4)
2. certification du syst`eme `a l’ex´ecution (troisi`eme objectif de la th`ese, sec- tion 1.4).
5.1.1 Objectifs du processus d’implantation
L’objectif de cette ´etape est de produire le syst`eme tout en garan-
tissant le respect de ses sp´ecifications. Pour parvenir `a le satisfaire, il
est n´ecessaire de lier sp´ecifications et implantation.
Modèles AADL
Générateur de code AADL C
Code généré Plate-forme (POK)
Intégration
Application
Etape 1
Etape 2
Figure 5.1 – ´Etapes d’implantation d’un syst`eme partitionn´e `a partir de
mod`eles AADL
Le processus propos´e g´en`ere automatiquement l’implantation `a par-
tir de mod`eles AADL valid´es. Il repose sur deux parties, illustr´ees dans
la figure 5.1 :
1. une g´en´eration de code qui transpose les constructions AADL
en code C (´etape 1 de 5.1). Cette ´etape g´en`ere toutes les construc-
tions n´ecessaires `a l’ex´ecution du syst`eme sp´ecifi´e et assure la liaison entre les composants (g´en´eration de code dit « glue » ). Le code cr´e´e res-
pecte ainsi les caract´eristiques du mod`ele et les exigences du concepteur
(en terme de s´ecurit´e, sˆuret´e, performances, etc.).
2. une int´egration avec une une plate-forme d’ex´ecution (´etape 2
de 5.1. Elle fournit les services n´ecessaires `a l’ex´ecution du syst`eme (iso-
lation temporelle, spatiale, etc.). Elle doit ˆetre hautement configurable
afin d’ˆetre configur´ee et d´eploy´ee en fonction des directives de configu- ration d´eriv´ees des caract´eristiques du mod`ele AADL (configuration des partitions, de la politique de s´ecurit´e, sˆuret´e, etc.). Ainsi, le g´en´erateur de code pourra produire des directives de configuration afin d’adapter au
5.1. Aper¸cu du processus de g´en´eration
Au d´ebut de ces travaux, aucune plate-forme de partitionnement libre
n’existait. Le projet que nous avons initi´e, POK [33, 32] r´epond `a cette de-
mande. Il a pour objectif de faciliter la conception de syst`emes sˆurs et s´ecuris´es en incluant :
1. un syst`eme d’exploitation partitionn´e comprenant les m´ecanismes de s´e-
curit´e et de sˆuret´e requis par les approches ARINC653 et MILS.
2. une suite d’outils facilitant le d´eveloppement de syst`emes sˆurs et s´ecuris´es `
a partir de mod`eles AADL.
5.1.2 Objectifs du processus de certification
La partie certification r´epond au troisi`eme objectif de notre ap-
proche (section 1.4). Elle est mise en œuvre par un processus en deux
´ etapes :
1. CERTIF-SPEC : certification de l’ex´ecution du syst`eme par rapport
aux sp´ecifications.
2. CERTIF-STD : assurance du respect des contraintes des standards de certification (tel DO178B).
Ces contraintes de certification n´ecessitent la cr´eation d’outils qui mettent en relation l’ex´ecution du syst`eme avec ses sp´ecifications pour les comparer et assurer leur conformit´e.
Notre processus de certification est illustr´e en figure 5.2 : CERTIF-
SPEC (partie gauche de la figure) s’appuie sur les mod`eles AADL utilis´es par
les ´etapes pr´ec´edentes du processus de d´eveloppement (validation, implanta-
tion). Ce type de certification compare ex´ecution et sp´ecifications au moyen
de deux outils analysant les aspects suivants :
1. ordonnan¸cabilit´e : v´erification que les ´ev´enements d’ordonnancement
(activation des tˆaches, pr´eemption, etc.) observ´es `a l’ex´ecution respectent les caract´eristiques temporelles de la sp´ecification. Pour cela, un outil en-
registre les ´evˆenements d’ordonnancement (context-switch, changement
de partition) lors de l’ex´ecution du syst`eme et les compare avec les r´e- sultats provenant de la simulation de l’ordonnancement r´ealis´ee `a partir des sp´ecifications.
2. comportementales : analyse de la conformit´e des fonctions ex´ecut´ees
par le syst`eme.
CERTIF-STD (partie droite de la figure 5.2) apporte des garanties sur le syst`eme g´en´er´e ind´ependamment de ses sp´ecifications. Il a pour but de v´erifier
que les syst`emes produits respectent les exigences des standards de certification
(comme la couverture de code requise par DO178B).
5.1.3 B´en´efices du processus d’implantation
Le processus d’implantation traduit automatiquement les sp´ecifications de
l’architecture (mod`eles AADL) en code C int´egr´e `a une plate-forme d’ex´ecu- tion. Il apporte les b´en´efices suivants :
Modèles AADL
Certification des exigences du système
Implantation (code)
Implantation automatique (figure 5.1)
Certifications des exigences des standards
(ex : validation de l'ordonnancement) (ex : couverture de code)
Figure 5.2 – Illustration de l’utilisation des diff´erents outils de certification 1. assurance du respect des sp´ecifications ;
2. d´eterminisme dans la production de code, facilitant ainsi l’analyse de
l’application produite ;
3. absence d’erreur dans le code produit, par la suppression du caract`ere
« manuel » de la production de code.
L’assurance du respect des sp´ecifications garantit que les caract´eris-
tiques du syst`eme sont correctement implant´ees. Dans un processus
de conception traditionnel, rien ne garantit leur respect : les d´eveloppeurs
transposent manuellement la description du concepteur en code et peuvent
donc introduire des erreurs. Le recours `a un processus de transformation au-
tomatique de code assure que les constructions du langage source (mod`eles
AADL) seront correctement transpos´ees dans l’implantation.
Le processus de g´en´eration facilite l’analyse du code par le recours
`
a des patrons de mod´elisation pr´ed´efinis. Ces derniers d´efinissent les
r`egles de transformation de code et ses caract´eristiques (appels de fonctions,
introduction de ressources suppl´ementaires tels que les variables, tˆaches, etc.). Ainsi, le structure du code est pr´ed´etermin´ee, facilitant son analyse et la ga-
rantie du respect d’exigences (par exemple : temps d’ex´ecution n´ecessaire `a
l’envoi des messages, overhead m´emoire introduit par le code g´en´er´e, temps
d’ex´ecution des fonctions, etc.). Ces analyses s’appuient traditionnellement sur
des outils ind´ependants et d´edi´es qui inspectent l’implantation (consommation
m´emoire, temps d’ex´ecution, etc.) et reportent les m´etriques `a l’utilisateur qui
estime si les r´esultats sont conformes aux exigences de production. A l’inverse,
notre processus `a partir de patrons de g´en´eration pr´ed´etermin´es, permet de d´eduire le coˆut (temporel, m´emoire, etc.) du code produit et affranchit l’utili- sateur de proc´eder `a de coˆuteuses analyses de l’implantation.
La g´en´eration supprime le facteur d’erreur humain inh´erent `a la
production de code traditionnelle. La traduction automatique de code
`
a partir des sp´ecifications assure leur bonne implantation et limite les erreurs
traditionnellement introduites par la cr´eation manuelle de code. Cependant,
cela suppose que le g´en´erateur ne comporte lui-mˆeme aucune erreur. L’utili-
5.2. Chaˆıne de g´en´eration