Laboratoire d`Optimisation Globale SDER/ENAC

Transcription

École Doctorale Informatique et
Télécommunications (EDIT)
Master Recherche – Sûreté du Logiciel et Calcul à haute Performance (SLCP)
Année : 2005
Laboratoire d’Optimisation Globale
SDER/ENAC
Certification du code embarqué
d’un micro-drone
par
Nicolas Albert
[email protected]
Directeur de recherche : Jean-Marc Alliot
Responsable du stage : Pascal Brisset
Nom du projet : Paparazzi
Dirigé par : Pascal Brisset
Février à Juillet 2005
École Nationale de l’Aviation Civile
7, avenue Édouard Belin
31055 Toulouse
Abstract
Unmanned Air Vehicles (UAV) are more and more sollicted for military porpuses and many
applications can now be found in the civil context. To be able to use this kind of aircrafts
in civil conditions, we have to ensure a minimum level of safety, particularly concerning
flying commands. This work aims at improving the safety of critical portions of onboard
source code. The study is made over UAVs from the Paparazzi project, initiated in 2003
by Pascal Brisset and Antoine Drouin.
Résumé
Les drones sont des appareils n’embarquant pas de pilote. Ils peuvent être autonomes et/ou
contrôlés depuis le sol. Leur usage est aujourd’hui de plus en plus en vogue, notamment
dans le milieu militaire où la sécurité des pilotes est parfois difficile à assurer. L’utilisation
de tels aéronefs a été largement médiatisée lors des derniers conflits armés. Les applications
civiles possibles sont tout aussi nombreuses.
Le problème posé est principalement la sécurité de tels appareils, notamment du point de
vue de l’intégration dans le trafic traditionnel. Une telle intégration n’est envisageable que
si l’on est sûr de pouvoir à tout moment contrôler et superviser le drone et le rattraper
en pilotage manuel en cas de problème. La première fonctionnalité à étudier et à sécuriser
est donc la reprise de commande en mode manuel et c’est cette partie de code embarqué
critique que l’on certifiera. Ce document présente les travaux réalisés pour ce travail de
Master, en exposant tout d’abord les limitations introduites par les mini-drones. Nous
détaillons ensuite la réalisation de la certification elle-même, qui passe par la réécriture du
code critique en Lustre. L’étude et les tests opérationnels sont réalisés sur les drones du
projet Paparazzi1 , initié en 2003 par Pascal Brisset et Antoine Drouin.
1
Projet Paparazzi : http://savannah.nongnu.org/projects/paparazzi/
Remerciements
Je remercie tous les personnels du Laboratoire d’Optimisation Globale pour la chaleur
de leur accueil lors de ce stage.
Je remercie Jean-Marc Alliot et Nicolas Durand pour l’attention dont ils ont fait
preuve tout au long de ce stage.
Je remercie Pascal Brisset pour son encadrement attentif et directif dans le déroulement
de ce stage.
Je remercie Antoine Drouin pour ses conseils et ses explications précises sur le fonctionnement de la partie aéromodélisme du projet.
Je remercie Judicaël Bedouet, Thibaut Feydy, Fabien Perrot et Olivier Revelin
également stagiaires de Master Recherche pour l’intérêt permanent qu’ils ont montré.
Je remercie Nicolas Barnier, Charles-Edmond Bichot, Christian Bontemps, David
Gianazza, Kévin Guittet, Jean-Baptiste Gotteland Estelle Malavolti-Grimal et
Thomas Rivière pour l’ambiance chaleureuse qui a régné tout au long de mon stage.
Introduction
Le terme “drone” désigne un engin volant sans pilote, sans considération pour ses caractéristiques (fonction, taille, performances). La particularité des drones consiste donc à
ne pas avoir d’intervention humaine à bord. Ainsi, les aéromodèles sont considérés comme
des drones. Les drones sont conçus pour évoluer dans des environnements où la présence
humaine est impossible ou non envisageable. C’est par exemple le cas d’appareils utilisés
pour diagnostiquer des feux de forêt (impossibilité de respiration) ou concernant les applications militaires (le risque de perte peut être trop important et pousser à ne pas embarquer
un pilote humain).
La dénomination anglaise UAV (Umanned Air Vehicule) suppose de plus que le drone
est autonome. Les aéromodèles ne rentrent plus dans cette définition. L’ambition du projet
Paparazzi est de créer un drone autonome. Des prototypes basés sur des aéromodèles
grand public ont été réalisés et se sont même montrés plus performants que des modèles
développés par des industriels (par exemple EADS Dornier) lors des premières compétitions
de vol autonome à l’automne 2003 et en juillet 2004.
Usages des drones : Comme toute activité nouvelle, les développements dans ce domaine sont très variés. Certaines techniques commencent à être fiables et la question de la
réglementation des vols de drones se pose désormais. Les drones militaires sont déjà utilisés
(lors de la guerre du Golfe et des conflits au Kosovo ou en Afghanistan par exemple) mais
ne requièrent pas de réglementation particulière. En revanche, les vols de drones civils sont
encore marginaux et cantonés aux limitations imposées aux aéromodélistes (vol à vue, en
dessous de 150m et à distance des servitudes aéronautiques).
Problèmes réglementaires : Qu’en est-il de l’intégration des drones civils dans la
circulation aérienne ? En effet, un drone ne peut pas répondre à la règle de base de la
navigation aérienne “voir et éviter”. Les fondements même de la réglementation de la
circulation aérienne sont inapplicables.
Afin de rendre plus facile l’intégration des drones dans l’espace aérien civil actuel, il est
nécessaire de sécuriser et de fiabiliser leur fonctionnement. En effet, il faudrait définir par
exemple si le drone doit déposer une mission (ou plan de vol) et la suivre à la lettre, auquel
cas le contrôle aérien adapterait sa gestion en fonction des drones. Une autre solution moins
contraignante pour le contrôle consisterait à donner des consignes de navigation aux drones
au même titre qu’aux pilotes. Dans ce cas, le respect des consignes de la part du drone est
i
ii
primordial. Les évitements quant à eux peuvent être réalisés par des systèmes embarqués
tels que le TCAS2 , actuellement utilisé pour les avions traditionnels.
Pour permettre l’intégration des drones dans le trafic traditionnel et assurer la cohabitation entre les drones et les avions pilotés, il est indispensable de s’assurer que l’avion
demeure contrôlable quoi qu’il arrive. Dans cette optique, nous nous attachons dans cette
étude à certifier la partie du code source consacrée à la commande et à la gestion des
modes de vol (manuel, automatique, etc.) du drone Paparazzi, le drone devant toujours
être “rattrapable” par un opérateur humain au sol par exemple.
Organisation de ce document : Ce document présente tout d’abord le monde des
drones, leurs spécificités et leurs usages et les contraintes aux quelles ils sont soumis.
La seconde partie sera consacrée au projet Paparazzi, objet de ce stage. Nous y verrons
comment le projet est structuré et quelles sont les fonctionnalités critiques que nous devons
améliorer.
La troisième partie détaille le choix et l’utilisation d’un langage de programmation
synchrone : Lustre. La dernière partie sera consacrée à la vérification des propriétés de
sûreté en exposant le principe et les méthodes utilisées.
2
TCAS : Traffic Collision Avoidance System
Table des matières
Introduction
i
1 Le monde des drones
1.1 Les drones, avant tout militaires . . . . . .
1.2 Applications civiles . . . . . . . . . . . . .
1.2.1 Application selon masse et altitude
1.2.2 Quelques applications concrètes . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
7
8
9
2 Étude technique préliminaire
2.1 Les mini-drones . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Conception d’un mini-drone . . . . . . . . . . . . .
2.1.2 Un mini-drone autonome . . . . . . . . . . . . . . .
2.2 Le projet Paparazzi . . . . . . . . . . . . . . . . . . . . . .
2.2.1 L’aéromodèle utilisé . . . . . . . . . . . . . . . . .
2.2.2 Architecture matérielle de l’électronique embarquée
2.2.3 Spécificités des aéromodèles . . . . . . . . . . . . .
2.3 Principes de la chaı̂ne de commande . . . . . . . . . . . . .
2.3.1 Les servo-moteurs . . . . . . . . . . . . . . . . . . .
2.3.2 Décodage PPM . . . . . . . . . . . . . . . . . . . .
2.3.3 Synthèse des commandes de servo-moteur . . . . .
2.4 Méthode de certification utilisée . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
12
13
14
14
15
16
18
19
21
21
22
3 Utilisation d’un langage synchrone
3.1 Les langages synchrones . . . . . . . . . . . . . . . .
3.1.1 Systèmes temps-réel . . . . . . . . . . . . . .
3.1.2 L’hypothèse du synchronisme . . . . . . . . .
3.1.3 Synchronisme fort . . . . . . . . . . . . . . . .
3.2 Le langage LUSTRE . . . . . . . . . . . . . . . . . .
3.2.1 Exemple booléen : détecteur de front montant
3.2.2 Exemple numérique : compteur . . . . . . . .
3.3 Lustre dans le projet Paparazzi . . . . . . . . . . . .
3.3.1 Entrées / Sorties . . . . . . . . . . . . . . . .
3.3.2 La communication inter-micro-contrôleur . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
25
26
27
27
28
29
29
30
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATIÈRES
3.4
3.5
iv
Détail du traitement de SIG INPUT CAPTURE1 . . . .
3.4.1 Le code C existant . . . . . . . . . . . . . .
3.4.2 Périphériques utilisés sur le micro-contrôleur
3.4.3 Conséquence sur le code Lustre . . . . . . .
3.4.4 Première spécification du décodage PPM . .
3.4.5 Détail de la détection d’erreur dans la trame
3.4.6 Exemples d’erreurs à la réception . . . . . .
Mise en œuvre opérationnelle . . . . . . . . . . . .
4 Vérification des propriétés de sûreté
4.1 Limitations du langage Lustre . . . . . . . . .
4.1.1 Première approche . . . . . . . . . . .
4.1.2 Seconde approche . . . . . . . . . . . .
4.2 Vérification de propriétés . . . . . . . . . . . .
4.2.1 Principe . . . . . . . . . . . . . . . . .
4.2.2 Exemple . . . . . . . . . . . . . . . . .
4.2.3 La vérification dans le projet Paparazzi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . . .
. . . .
PPM .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
31
31
33
34
36
38
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
40
40
40
41
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusion
46
A Interruption SIG INPUT CAPTURE1 en C
49
B Code source Lustre pour la vérification de propriétés
51
Bibliographie
52
Table des figures
1.1
1.5
1.6
1.7
Drones militaires de surveillance : Global Hawk (Northrop Grumman, 1000kg
de charge utile) et Sperwer (Sagem). . . . . . . . . . . . . . . . . . . . . .
Le Predator, drone MAE multi-missions, utilisé par l’US Air Force depuis
1995. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Drones portables : Evolution (BAI Aerosystem) et DO-MAV (EADS-Dornier).
Micro drones : Black Widow (Aerovironment, 42g) et Micromechanical Flying
Insect (UC Berkeley, 25mm) . . . . . . . . . . . . . . . . . . . . . . . . . .
Drone solaire Helios (www.aerovironment.com) . . . . . . . . . . . . . . .
RMAX Yamaha et quadrirotor Braunmod . . . . . . . . . . . . . . . . . .
Analyse du marché du drone civil selon l’USICO . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Twinstar . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Positionnement des composants sur un Microjet . . . . . . .
Architecture matérielle de l’électronique embarquée . . . . .
Compteur décimal et servo-moteur . . . . . . . . . . . . . .
Impulsion de commande d’un servo-moteur . . . . . . . . . .
Trame PPM à 7 canaux et détail de répartition sur les servos
3.1
3.2
Principe d’interaction d’un système temps-réel (ou réactif) . . . . . .
Principe du synchronisme fort : les temps d’exécution sont supposés
face à la dynamique de l’environnement . . . . . . . . . . . . . . . . .
Découpage modulaire du décodage des trames PPM en Lustre . . . .
Machine à état décodant un signal PPM à 6 canaux . . . . . . . . . .
Machine à état générique décodant un signal PPM à N canaux . . . .
1.2
1.3
1.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
9
15
16
17
18
19
19
20
. . .
nuls
. . .
. . .
. . .
. . .
25
27
32
34
35
4.1 Principe du programme de vérification . . . . . . . . . . . . . . . . . . . .
4.2 Automate du nœud SWITCH . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Automate du programme de vérification . . . . . . . . . . . . . . . . . . .
41
42
42
v
.
.
.
.
.
.
.
4
4
.
.
.
.
.
.
.
3.3
3.4
3.5
.
.
.
.
.
.
.
3
Liste des tableaux
2.1
Changements de mode de fonctionnement en cas de défaillance . . . . . . .
22
3.1
3.2
3.3
3.4
Problème de déterminisme lié à la concurrence . . . .
Traitement d’une séquence PPM valide . . . . . . . .
Traitement d’une séquence PPM erronée . . . . . . .
Traitement d’une séquence PPM valide avec mauvaise
.
.
.
.
26
35
37
38
4.1 Code d’exécution pour SIG INPUT CAPTURE 1 . . . . . . . . . . . . . . . . .
4.2 Code de vérification pour SIG INPUT CAPTURE 1 . . . . . . . . . . . . . . .
43
43
vi
. . . . . . . .
. . . . . . . .
. . . . . . . .
configuration
.
.
.
.
.
.
.
.
.
.
.
.
Chapitre 1
Le monde des drones
Les drones sont des aéronefs sans pilote humain à bord. Cette définition simpliste
englobe de nombreux types d’appareils classés dans 3 grandes catégories :
Mini-drones Ce sont des drones plutôt légers et de taille réduite (jusqu’à quelques kilogrammes et d’une envergure jusqu’à 1 à 2 mètre) facilitant la mise en œuvre et
généralement utilisés pour l’observation de zones difficiles d’accès.
MALE (Moyenne Altitude Longue Endurance) Ce sont des drones de taille comparable aux avions traditionnels. Ils sont généralement voués à l’observation, mais
certains peuvent embarquer des armes.
HALE (Haute Altitude Logue Endurance) Il s’agit de drones de grande envergure
volant à très haute altitude. Ils sont majoritairement utilisés pour des communications, comme alternative aux satellites.
Nous présentons ici un court état de l’art concernant les drones[Bri04], puis nous nous
intéressons aux applications civiles réalisables par les drones et en particulier les minidrones.
1.1
Les drones, avant tout militaires
Gros drones Depuis plus d’un demi-siècle, des drones ont été développés dans le domaine
militaire. Après quelques expériences anecdotiques, ils ont été utilisés systématiquement
lors des conflits « modernes », depuis les années 80, principalement par les israéliens,
les américains et par les forces alliées lors des deux guerres du Golfe. Ces engins ont
notamment été utilisés pour des missions de reconnaissance et de surveillance (c.f. figure
1.1). Néanmoins certains (par exemple le Predator, figure 1.2) peuvent être armés, de
missiles ou de mini-drones. Ces avions de plusieurs tonnes possèdent une charge utile
importante (jusqu’à une tonne pour le Global Hawk) et sont équipés de caméras (visible
et infrarouge) et de radars divers. Il sont reliés au sol via des communications haut-débit,
habituellement via des satellites.
Le Global Hawk peut voler au-dessus du trafic civil (FL600) et son intégration à la
circulation aérienne est délicate uniquement pendant les phases de montée et descente.
2
CHAPITRE 1. LE MONDE DES DRONES
3
Fig. 1.1 – Drones militaires de surveillance : Global Hawk (Northrop Grumman, 1000kg
de charge utile) et Sperwer (Sagem).
Avec un rayon d’action pouvant atteindre 12 000 NM (environ 22 000 km), il peut remplir
des missions transcontinentales. À l’automne 2003, un Global Hawk a traversé l’atlantique
pour une mission en Allemagne.
Drones portables La deuxième grande catégorie de drones ne se distingue pas par leur
mission principale, l’observation, mais par leur taille. Ces drones portables (figure 1.3)
de quelques kilogrammes sont conçus pour être transportés dans un sac à dos et mis en
œuvre à l’aide d’une « station-sol » réduite à un ordinateur portable et un émetteurrécepteur permettant la communication avec le drone (les plus gros de ces mini-drones
peuvent nécessiter l’usage d’une rampe de lancement pour le décollage). La charge utile
essentielle d’un tel mini-drone est une caméra vidéo dont l’image est retransmise en continu
à la station-sol. Avec un rayon d’action de quelques kilomètres, l’objectif d’un mini-drone
est d’aller voir « de l’autre côté de la colline » soit en étant piloté comme un modèleréduit standard soit de manière autonome en suivant une mission préprogrammée (une
suite de waypoints), la navigation étant effectuée grâce à un positionnement GPS. Dans
cette catégorie, le DO-MAV d’EADS-Dornier mesure 42cm d’envergure pour un poids de
500g. Il peut être mis en œuvre par un opérateur unique.
Micro-drones Toujours avec des objectifs au départ militaires, la miniaturisation des
UAVs a été poursuivie. Pionnière dans le domaine dès les années 80 avec son Pointer, un
avion de 4kg avec 1kg de charge utile, la société AeroVironment a construit un drone de
42g, le Black Widow (figure 1.4) équipé d’une caméra et capable de naviguer de manière
autonome (GPS) avec une autonomie de 30mn. Mis à part la performance technologique,
on peut douter de l’intérêt d’une telle miniaturisation qui d’une part réduit la charge utile
à quelques grammes et dont les performances de vol sont forcément très dégradées en
présence de vent.
4
Fig. 1.2 – Le Predator, drone MAE multi-missions, utilisé par l’US Air Force depuis 1995.
Fig. 1.3 – Drones portables : Evolution (BAI Aerosystem) et DO-MAV (EADS-Dornier).
La course à la miniaturisation est cependant loin d’être terminée et les études actuelles concernent des engins de quelques grammes (figure 1.4) ; dans ce cadre les recherches s’orientent vers des solutions s’inspirant du monde biologique en particulier pour
l’aérodynamique en privilégiant le vol à ailes battantes. Le vol à ailes battantes ou vibrantes est étudié au sein du projet REMANTA de l’ONERA : les problèmes à résoudre
sont mécaniques et aérodynamiques. Les écoulements induits par les mouvements complexes doivent être analysés finement afin de pouvoir optimiser le rendement du vol. Les
autres problèmes à résoudre à ces échelles concernent la propulsion et l’énergie.
L’intérêt militaire des micro-drones a été identifié depuis plusieurs années et la lecture
du rapport [Hub01] est aussi enrichissante qu’inquiétante.
Drones stratosphériques Il existe également des drones d’une autre envergure, des
grands drones, stratosphériques, prévus pour des vols à très haute altitude pour des durées
a priori illimitées (plusieurs mois). L’objectif dans ce cas est de remplir une mission analogue à celle d’un satellite géostationnaire : observation et communication. Le leader pour
5
Fig. 1.4 – Micro drones : Black Widow (Aerovironment, 42g) et Micromechanical Flying
Insect (UC Berkeley, 25mm)
Fig. 1.5 – Drone solaire Helios (www.aerovironment.com)
cette technologie, en coopération avec la NASA, est encore la société AeroVironment avec
son drone Helios (anciennement Pathfinder). Il s’agit d’un grand avion électrique (figure
1.5) d’une soixantaine de mètres d’envergure, muni de panneaux solaires et d’une pile à
combustible. L’énergie solaire est utilisée pendant la période diurne pour alimenter les moteurs et recharger la pile à combustible. Cette dernière est utilisée la nuit pour éviter à
l’avion de perdre trop d’altitude. En 2001, Helios a atteint une altitude record de 96 863
pieds. Des expérimentations ont été effectuées en 2002 avec ce drone pour la première
application commerciale (de la télévision) utilisant un relais à 60 000 pieds1 .
Drones hélicoptères De même qu’avec les aéronefs pilotés, certaines applications nécessitent la possibilité de pouvoir effectuer du vol stationnaire. Plusieurs solutions sont envisagées, la moins originale est l’hélicoptère classique. Les hélicoptères R-50 et RMAX de
Yamaha sont commercialisés depuis plus d’une douzaine d’années. Il s’agit d’engins d’une
1
Un exemplaire d’Helios s’est écrasé en juin 2003 au large d’Hawaı̈ pendant un vol d’essai.
6
Fig. 1.6 – RMAX Yamaha et quadrirotor Braunmod
cinquantaine de kilos avec une charge utile de 20 et 30kg. Munis d’un système de navigation, ils sont capables d’effectuer des missions en autonomie complète. Aujourd’hui, plus
de 1500 exemplaires sont utilisés au Japon pour des traitements agricoles [Sat]. Le RMAX
a aussi été capable de réaliser des prises de vues aériennes en environnement hostile lors
d’une éruption volcanique. Un exemplaire d’un RMAX capable de voler de façon autonome
jusqu’à 100m au dessus du sol est commercialisé à $200 000. Au Japon, son utilisation agricole doit être certifiée par le Japan Agriculture Aviation Association qui assure également
la formation des opérateurs.
L’autre solution technique classique pour effectuer du vol stationnaire avec un engin
de petite taille est le quadrirotor (figure 1.6) : l’aéronef est sustenté par quatre rotors
indépendants disposés en croix. Le contrôle est assuré simplement par la variation de la
vitesse de rotation de chacun des rotors. Cette solution est mécaniquement plus simple
qu’un hélicoptère classique (rotor à pas variable), naturellement plus stable mais moins
dynamique (réaction lente aux perturbations extérieures). Le quadrirotor est par exemple
étudié par le CEA pour un engin d’exploration intérieure pour les centrales nucléaires. Dans
cette application, le drone doit « apprendre » son itinéraire à l’aide d’« indice vidéo »,
pour savoir ressortir du bâtiment de manière autonome.
Drones européens Bien qu’en retrait dans le domaine militaire (derrière Israël et les
USA), l’Europe est active tant du côté académique qu’industriel sans oublier le domaine
réglementaire. L’université technique de Braunschweig, Allemagne constitue un pôle de recherche important. L’université de Bristol, UK, a organisé en 2004 la 18ème conférence internationale sur les UAV (anciennement Remotely Piloted Vehicles). L’ENSICA et Supaéro
organisent depuis 2001 les Journées Micro-drones, regroupant une conférence et des démonstrations en vol.
Ces journées sont en relation avec le concours de drones miniatures supervisé par la
DGA. Ce concours dont l’épreuve finale aura lieu en 2005 est ouvert aux écoles d’ingénieurs
7
et aux universités. Selon le règlement, « ce concours a pour objet de démontrer la faisabilité
technique et l’intérêt opérationnel des drones miniatures utilisés comme aide au fantassin
dans sa progression en milieu hostile ». L’objectif ultime est la circulation autonome dans
un milieu urbain d’un engin muni d’une caméra, avec pour mission de repérer des snipers.
Les critères d’évaluations comprennent la simplicité de mise en œuvre, l’endurance, la
miniaturisation, la discrétion, ...
Toujours dans le domaine de la défense, c’est EADS, en partenariat avec Dassault,
Thalès et Sagem, qui ont été retenus pour le développement d’un drone MALE pour l’état
français. Cet EuroMALE est en particulier conçu pour coopérer avec le Sperwer (Sagem)
déjà choisi par cinq autres pays européens.
Références La description de l’ensemble des drones existant est disponible sur le web.
On peut citer www.uavforum.com qui répertorie les constructeurs et les aéronefs. La revue
Armada Internationale a publié en juillet 2004 un « guide complet des UAV » disponible à www.aramada.ch. Le site www.livingroom.org.au/uavblog relate régulièrement
les nouvelles du domaine.
Les industriels se sont regroupés au sein d’un consortium UVS International (initialement EURO UVS) afin de promouvoir l’utilisation des drones. Les objectifs du consortium
sont
– d’avoir un impact international ;
– d’être un canal de communication privilégié pour les différents acteurs du secteur :
industries, gouvernements, autorités de l’aviation civile, universitaires, militaires,
opérateurs, ... ;
– de constituer une aide à l’étude du marché du drone ;
– de montrer aux utilisateurs potentiels l’intérêt des drones ;
– de promouvoir la coopération industrielle internationale ;
– d’améliorer la visibilité de la technologie vis à vis du grand public.
Le site du consortium www.uvs-international.org (libre d’accès après inscription), contient une base de donnée importante de documents concernant les constructeurs, les aéronefs
et les événements internationaux dans le domaine. Le consortium organise aussi régulièrement des conférences internationales.
1.2
Applications civiles
Nous présentons ici dans un premier temps les applications par catégories et nous en
détaillons ensuite quelques unes. Certaines d’entre elles ne sont pas compatibles avec la
régulation actuelle de la circulation aérienne ; nous nous intéressons à ce point uniquement
dans la section suivante.
1.2.1
8
Application selon masse et altitude
Tous les avantages reconnus des drones pour les applications militaires sont transposables aux applications civiles : comme mentionné dans l’introduction, les environnements
« Dull, Dirty and Dangerous » peuvent se rencontrer dans le domaine civil. Des missions
civiles très similaires aux missions de défense comme la surveillance des frontières2 et la surveillances des personnes (lors de manifestations publiques par exemple ou lors de simples
missions de police) sont facilement envisageables. D’autres applications, plus originales,
sont étudiées à plus ou moins long terme : observation de la terre, télécommunications,
transport, ...
Le projet européen USICO3 a identifié trois grandes catégories de drones candidats à
des applications civiles [USI04] et analysé le marché comme représenté figure 1.7 :
1. Mini et micro-drones à basse altitude :
– Photos aériennes, inspection
– Publicité
– Épandage agricole, surveillance des cultures, garde de troupeaux
– Expériences scientifiques, mesures atmosphériques
– Déminage
L’évolution de cette branche sera fortement liée à l’évolution de la technologie correspondante. Envisagée uniquement dans le cadre des règles actuelles de l’aéromodélisme, l’utilisation des mini-drones est cependant assez limitée, notamment à
cause de l’obligation de pilotage « à vue ».
2. MALE :
– Activités gouvernementales (police, douanes, environnement, ...)
– Missions scientifiques
– Surveillance d’infrastructures (réseau routier, lignes électriques, pipe-lines, ...)
– Géodésie
– Transport de fret
– Transport de passagers
Les drones de cette catégories sont sur le marché (militaire) mais ne peuvent pas être
intégrés au trafic civil. Notons que l’usage de ce genre de plate-forme est limité par
le traité de non prolifération4
3. HALE géostationnaire :
– Radiodiffusion (télévision, ...)
– Télécommunications mobiles
– Environnement (incendies, pollution maritime, ...)
2
Des drones de l’armée suisse ont par exemple été utilisés pour surveiller les frontières dans le Tessin
pendant l’été 2004. Des drones Hermes surveillent la frontière entre le Mexique et les USA depuis fin juin
2004.
3
Unmanned aerial vehicle Safety Issues for Civil Operations : www.usico.org
4
Régime de Contrôle de la Technologie des Missiles : ce traité régule l’exportation de matériel et logiciel
permettant le développement de missiles d’une charge utile supérieure à 500kg et d’un rayon d’action de
plus de 300km.
9
Mis à part le prototype Helios (figure 1.5), il n’existe actuellement pas de plate-forme
pouvant assurer ces missions (les autres projets envisagent des gros dirigeables). Cependant, ces services correspondent à un marché important, ce qui pourrait entraı̂ner
une évolution rapide du domaine.
Fig. 1.7 – Analyse du marché du drone civil selon l’USICO
1.2.2
Quelques applications concrètes
Publicité et photo aérienne L’une des rares applications actuelles civiles d’un aéronef
non habité concerne l’usage d’un ballon captif simplement comme support publicitaire ou
pour réaliser de la photo aérienne : le ballon est muni d’un appareil photo orientable,
télécommandé depuis le sol ; une caméra vidéo dont l’image est retransmise au sol sert
de viseur. Le ballon peut évoluer jusqu’à 150m, dans le cadre de la réglementation des
aéro-modèles. De nombreuses sociétés, en particulier françaises (Photociel, Phodia, ...),
proposent des services basés sur cette technique. La société Mediazepp commercialise un
ballon équipé pour moins de 5000e, prix à comparer avec une solution classique hélicoptère
et pilote ... Pour cette même application, le drone paramoteur5 Pixy a également été
développé. L’avantage par rapport au ballon captif, tout en restant dans le même cadre
de réglementation, est sa mobilité. De plus, son pilotage, grâce à une vitesse d’évolution
faible, ne nécessite pas les talents d’un pilote chevronné.
Déminage Les mines antipersonnel peuvent être repérées dans certaines conditions depuis le ciel : enfouies à très faible profondeur, à l’aube, elles ne se réchauffent pas de manière
identique au terrain environnant et il est possible de les repérer avec une image infrarouge.
5
Un paramoteur est un aéronef motorisé sustenté par une voilure souple, de type parachute.
10
Une cartographie de terrains minés a déjà été réalisée avec un mini-drone hélicoptère de
quelques dizaines de kilogrammes6 .
La technologie hélicoptère est assez coûteuse mais il est possible d’utiliser un mini-drone
avion pour réaliser cette cartographie. La société Fondmetal Technologie envisage d’utiliser
le système Paparazzi pour équiper un avion de quelques kilogrammes dans ce but. L’objectif est de fabriquer un engin d’environ 15 000e qui serait accessible aux organisations
humanitaires et aux pays en voie de développement. Des expérimentations sont en cours.
Feux de forêt La lutte contre les feux de forêt est d’autant plus aisée que la détection
de départ de feu est précoce. Une surveillance permanente nécessite des moyens humains
importants. La solution drone s’impose naturellement7 . Pour ne pas interférer avec la circulation aérienne, c’est un drone HALE qui est prévu. À 20 000m d’altitude, avec une
autonomie de 24h, le drone sera muni de capteurs optiques et électromagnétiques pour
détecter non seulement les feux mais également les véhicules dans les zones réglementées.
Le programme de recherche piloté par l’ONERA doit donner ses conclusions fin 2004.
Inspection d’infrastructure Les mini-drones sont étudiés sérieusement pour inspecter des infrastructures, en particulier des lignes haute tension et des ouvrages d’art. Le
projet RIPL (Robotic Inspection of Power Lines) développe un mini-hélicoptère de 35kg à
deux rotors coaxiaux contra-rotatifs. L’étude du marché potentiel [AE04] devrait être motivante pour la recherche dans le domaine. Le Laboratoire Central des Ponts et Chaussées
conduit un projet pour l’utilisation de drones dont la mission est la surveillance automatisée d’ouvrages d’art[JLSD02]. Des expérimentations ont été conduites dès 2001 sur un
viaduc, en zone urbaine, avec un hélicoptère de 10kg radio-commandé (non autonome).
Ce même laboratoire étudie également l’utilisation de drones pour la surveillance du trafic routier[JLSL03]. L’objectif vise à mesurer précisément les phénomènes de congestion
chronique (sur les périphériques des grandes agglomérations) ou exceptionnelle (sur les
autoroutes suite à un incident bloquant la circulation par exemple). Dans le second cas
de figure, l’idée est d’avoir un système portable dont la mise en œuvre serait très simple
(quelques minutes) afin d’obtenir rapidement des observations sur site à moindre coût ; c’est
donc encore la catégorie des mini-drones qui est candidate à cet usage. Une expérimentation
a été envisagée au dessus du périphérique de Nantes mais aucune autorisation de vol n’a
pue être obtenue (la réglementation pour l’aéro-modélisme ne s’appliquant pas dans ce
cas).
Mesures atmosphériques Les ballons sondes, utilisés depuis longtemps par la météorologie, ne sont pas à proprement parler des drones puisqu’ils ne sont pas pilotés (ni récupérés
en général). Il est assez tentant de remplacer ces ballons par des aéronefs contrôlés. Il est
cependant délicat d’envisager d’autres engins car les mesures doivent pouvoir être effectuées
6
7
maic.jmu.edu/journal/3.2/focus/schiebel mad/schiebel.htm
www.onera.fr/coupdezoom/07-drone-feux-forets.html
11
dans des conditions délicates (nuage, givrage, très haute altitude, ...) et surtout suivant un
profil vertical. Un drone pourrait être intéressant dans trois contextes :
1. Récupération d’un ballon sonde traditionnel : le ballon est largué à haute altitude et
l’équipement de mesure redescend en planant de manière autonome vers un site de
réception. Le principal problème reste alors l’intégration de la trajectoire descendante
à la circulation aérienne.
2. Campagne de mesures intensives[Pas03] : la campagne Thorpex (The Hemisperifc
Observing System Research and Predictability Experiment) envisage de lancer des
ballons dirigeables à haute altitude (20 000m) emportant une charge utile de dropsondes larguées par télécommande. Prévu pour une durée de vie d’un an, un tel
ballon peut être qualifié de drone ... Est prévu également l’utilisation d’aerosondes8 ,
un drone d’une quinzaine de kilogrammes qui a déjà fait ses preuves, notamment en
traversant l’atlantique.
3. Mesure en basses couches : un mini-drone est particulièrement bien adapté pour
effectuer des mesures à basse altitude. Ainsi, un Carolo T1409 , renommé M2 AV,
Meteorological MAV pour l’occasion, va être utilisé pour effectuer des mesures de
température, humidité et vent[MBV04].
8
www.aerosonde.com
Il s’agit du Twinstar Multiplex de 1.40m, la cellule choisie au sein du projet Paparazzi depuis début
2003.
9
Chapitre 2
Étude technique préliminaire
Nous présentons ici le fonctionnement général des aéromodèles, fournissant un support
à la création de mini-drones. Nous étudierons ensuite la conception structurelle et fonctionnelle du mini-drone Paparazzi. Une fois les fonctionnalités critiques explicitées, nous
nous intéresserons plus particulièrement à l’une d’entre elles : la chaı̂ne de commande de
l’aéronef. Les méthodes de certification envisageables seront ensuite rapidement discutées
afin de choisir la plus adaptée au projet Paparazzi.
2.1
Les mini-drones
Un drone n’embarquant pas de pilote humain, il est tentant de réduire sa taille (c.f. 1.1
et photos 1.3 et 1.4). L’intérêt est double : financier et sécuritaire. En effet, un mini-drone
peut être réalisé avec du matériel “amateur” peu coûteux et largement diffusé. De plus, par
leur légéreté et leur faible vitesse, les mini-drones ont une énergie cinétique bien moindre
que les drones “taille réelle”. L’impact en cas de crash est donc très mesuré, voire minime.
2.1.1
Conception d’un mini-drone
Un drone n’étant pas obligatoirement autonome, les avions modèles réduits (ou aéromodèles) sont des mini-drones. Certains existent en kits prêts à voler, d’autres sont à
monter. Les passionnés les créent de toute pièce. Le point commun est que ce sont tous des
mini-drones, de prêt ou de loin. Nous prendrons ici comme support d’étude les aéromodèles
de type avion, par opposition aux hélicoptères et autres modèles à sustentation.
Un mini-drone est avant tout un avion : En effet, comme les avions traditionnels,
il comporte un fuselage, des ailes, des ailerons (en bout d’ailes), une ou des gouvernes
verticales ou horizontales, un ou des moteurs.
Les ailes permettent à l’avion de se maintenir en l’air, par la portance qu’elles génèrent
en avançant dans l’air. Le mouvement vers l’avant est produit par les moteurs. Les ailerons
12
CHAPITRE 2. ÉTUDE TECHNIQUE PRÉLIMINAIRE
13
permettent d’incliner l’avion pour effectuer des virages tandis que les gouvernes de profondeur permettent de jouer sur le cabrage de l’avion. Tous les ailerons, dérives et gouvernes
participent à la stabilité de l’appareil et sont donc constamment liés.
Le pilotage d’un aéromodèle : Le pilotage d’un aéromodèle s’effectue à partir du sol,
au moyen d’une radio-commande. Le pilote dispose d’un émetteur qui envoie des ordres
au récepteur placé dans l’avion. La radio-commande permet de contrôler la position des
ailerons, des gouvernes de profondeur, le régime des moteurs etc. Chacune de ces informations est indépendante. Comme la radio-commande n’utilise qu’une seule fréquence radio,
les différentes commandes envoyées sont multiplexées pour former un signal unique. Toutes
les commandes sont envoyées en même temps et en continu. Chaque commande constitue
une voie (ou canal ) de la radio-commande. Le nombre de voies possibles sur une radiocommande est une de ses caractéristiques intrinsèques. Le pilote doit coordonner ses ordres
sur chacune des voies pour obtenir un vol fluide.
À bord de l’avion, le récepteur reçoit les ordres par ondes radio. Après démultiplexage,
il est chargé de répartir les ordres reçus pour chaque voie à l’organe correspondant. Par
exemple, pour orienter un aileron, il est nécessaire de le faire pivoter. Pour cela, on utilise un servomoteur qui permet de transformer un ordre transmis électriquement en un
déplacement de quelques millimètres ou centimètres. Ces composants peuvent être très
petits et sont couramment utilisés en modélisme.
Un mini-drone peut donc facilement être réalisé à partir de kits et composants préexistants que l’on commande depuis le sol via une radio-commande. À bord, un récepteur
est chargé de décoder les ondes radio transmises et d’envoyer les ordres correspondants aux
servomoteurs qui agissent sur les éléments aérodynamiques et les moteurs.
2.1.2
Un mini-drone autonome
Le concept de drone présenté précédemment est un simple aéromodèle, piloté par un
humain au sol. Un mini-drone autonome est identique dans sa façon de fonctionner avec
toutefois quelques particularités.
Tout comme l’aéromodèle piloté, le drone autonome peut utiliser les ondes radio pour
recevoir des ordres provenant du sol. Il utilise aussi les servomoteurs pour déplacer les
éléments aérodynamiques et régler le régime moteur.
La différence se situe au niveau de l’interprétation des ordres reçus. Un drone autonome
doit être capable de voler sans intervention humaine du sol. Il a donc un pilote automatique,
pouvant effectuer différents types de missions. Pour cela, il doit tout d’abord être capable
de voler de façon stable, c’est à dire “piloter” l’avion pour le maintenir globalement à plat.
On dit qu’on contrôle l’attitude (ou l’assiette) de l’avion. Ensuite, le pilote automatique
doit naviguer, c’est à dire se déplacer dans son environnement de façon réfléchie. Pour cela,
on doit pouvoir le programmer à l’avance en lui fournissant un plan de vol détaillant tous
14
les objectifs de la mission : point de passage, hauteur par rapport au sol, montée, descente,
trajectoires etc.
Un mini-drone autonome peut donc être un aéromodèle classique auquel on a ajouté
un “cerveau” capable de stabiliser l’avion et d’effectuer de la navigation.
2.2
Le projet Paparazzi
Le projet Paparazzi vise à développer un système de navigation autonome pour avions
modèles réduits. Les domaines d’application de ce type de technologie sont aussi variés
que nombreux, allant du loisir photographique (prises de vue aériennes) à la détection de
mines antipersonnel, afin de faciliter le déminage. Les besoins en terme de sécurité et de
sûreté sont donc différents.
Afin d’assurer un meilleur niveau fiabilité et donc de sécurité, il est nécessaire de certifier
les fonctions critiques face aux risques de défaillances du matériel ou de parasitages (notamment au niveau de la réception radio). Dans le projet Paparazzi, l’architecture matérielle
a été pensée de façon à isoler les tâches critiques.
Le pilote automatique (ou autopilote) du projet Paparazzi a été développé progressivement, en reproduisant au maximum la façon de piloter d’un pilote humain. Ainsi, la
fonction de stabilisation a été créée en premier lieu. Ce mode de fonctionnement du pilote
automatique est un mode de pilotage assisté, permettant de piloter l’attitude de l’avion
sans se soucier de sa stabilisation. Les mouvements autorisés sont limités afin d’éviter que
l’avion ne tombe (décrochage, piqué, retournement...). Ce mode de fonctionnement est très
facile à appréhender et permet de piloter l’avion sans aucun pré-requis.
La fonction de navigation a été développée ensuite, permettant ainsi de donner à l’avion
sa véritable mission. Dans ce mode, l’avion est totalement autonome. La radio-commande
ne sert que pour contrôler le pilote automatique et/ou lui indiquer un événement dans
sa mission. Une mission est un ensemble d’étapes (ou blocs fonctionnels) que l’avion doit
suivre. Un bloc peut consister à faire des cercles autour d’un point donné (jusqu’à réception
d’un événement de la radio-commande par exemple), à rejoindre un autre point, etc. La
mission est enregistrée dans l’avion avant le décollage, contrôlée par la radio-commande
(changements de bloc) et supervisée depuis le sol grâce à un ordinateur affichant en permanence l’état de l’avion. La navigation en mode autonome n’est possible que si on est capable
de se positionner. Pour cela, on utilise un récepteur GPS1 , fournissant une indication de
position mais aussi d’altitude et de vitesse par rapport au sol.
2.2.1
L’aéromodèle utilisé
Pour maintenir le coût de revient des drones créés, il a été choisi d’utiliser des bases
volantes disponibles dans le commerce. Ainsi, les premiers tests ont été réalisés avec un
bimoteur à ailes hautes, le Twinstar (fig 2.1). Ce modèle a l’avantage d’être robuste et
surtout très stable, une qualité appréciable lors des réglages.
1
Global Positionning System
15
Fig. 2.1 – Twinstar
Le second modèle utilisé est un Microjet (fig 2.2). Il s’agit d’une avion à aile delta
plus petit et plus léger que le Twinstar. L’intégration et la mise au point des éléments
développés lors de ce stage seront effectuées sur ce modèle.
Les aéromodèles utilisés comportent tous les équipements classiques d’un avion modèle
réduit (récepteur radio, batterie, moteur(s), hélice(s), servo-moteurs) ainsi que les matériels
spécifiques au pilotage autonome :
– récepteur GPS pour le positionnement et la vitesse sol ;
– capteur à infra-rouge pour l’attitude ;
– carte contrôleur constituant le “cerveau” pour le vol autonome.
Tous ces composants sont représentés sur la figure 2.3.
2.2.2
Architecture matérielle de l’électronique embarquée
L’électronique embarquée comporte deux microcontrôleurs AVR. Ces microcontrôleurs
seront par la suite désignés par leurs noms génériques MCU0 et MCU1 (fig 2.4).
MCU0 est le pilote automatique proprement dit. Il est chargé des tâches suivantes :
– communication avec le récepteur GPS, afin d’obtenir les informations de positionnement et de vitesse sol ;
– interprétation des données des capteurs infra-rouge afin d’en déduire l’attitude de
l’appareil ;
– calcul des commandes de pilotage (fonction de stabilisation) ;
– calcul des commandes de navigation (respect du plan de vol) ;
– communication avec le microcontrôleur MCU1. MCU0 est dit maı̂tre et MCU1 est
esclave. Ainsi, MCU0 donne à MCU1 les ordres de pilotage des servo-moteurs.
16
Fig. 2.2 – Microjet
– génération des messages de télémétrie à destination de la station de supervision au
sol.
MCU1 est chargé des fonctions de réalisation des commandes. Ces tâches sont :
– la réception des événements provenant de la radio-commande ;
– l’envoi des ordres aux servo-moteurs, permettant le pilotage de l’appareil ;
– la réception des commandes de pilotage calculées par le pilote automatique ;
– la gestion des modes de fonctionnement.
Chacune de ces tâches joue un rôle primordial dans le fonctionnement même du drone.
La tâche de commande des servo-moteurs est naturellemnt indispensable. La gestion des
modes de fonctionnement permet de choisir entre les modes automatiques et le mode
manuel. Au moins une des deux tâches de réception des commandes de vol doit fonctionner
pour permettre de contrôler l’avion. Si on perd à la fois la réception radio et le pilotage
automatique alors une ultime mode de fonctionnement dit failsafe prend le relais. Il consiste
à couper les moteurs et placer les gouvernes en position neutre.
Les quatre tâches de MCU1 sont donc critiques et c’est sur ces fonctionnalités que le
stage est focalisé.
2.2.3
Spécificités des aéromodèles
Le système décrit précédemment doit être embarqué à bord d’un aéromodèle. Les
aéromodèles présentent des particularités qui leur sont propres. Si on compare un pilote
automatique embarqué à bord d’un avion de ligne, on constate que les ordres sont donnés
au système par le commandant de bord et son copilote, ceux-ci connaissant parfaitement la
situation de vol. Dans tous les cas, la reprise des commandes en cas de défaillance du pilote
automatique est instinctive pour l’équipage. Dans le cas d’un aéromodèle, la détection des
Fig. 2.3 – Positionnement des composants sur un Microjet
17
18
Fig. 2.4 – Architecture matérielle de l’électronique embarquée
défaillances et le basculement en mode automatique est à la charge du pilote qui se trouve
au sol. Dans le cas du drone Paparazzi le basculement en mode manuel est automatique
si le pilote automatique est défaillant. Si on ne peut pas recevoir la radio-commande, le
mode failsafe est activé.
Non seulement la distance et la taille réduite de l’aéromodèle rendent son contrôle
plus ardu mais aussi un nouvel intermédiaire intervient : les commandes sont transmises à
l’aéromodèle par une liaison radio. Ces commandes sont ensuite interprétées par le microcontrôleur de commande MCU1, qui les communique au pilote automatique MCU0. MCU1
recompose un signal de commande (d’après le pilote automatique ou les commandes manuelles suivant le mode de pilotage sélectionné) qui est envoyé aux servo-moteurs pour
actionner les gouvernes et les moteurs. L’étape de transmission radio rajoute donc de nouvelles sources de défaillance : perte de fréquence (problèmes de portée), brouillage radio
(plusieurs utilisateurs sur la même fréquence).
En cas de perte de données radio, le micro-contrôleur devra s’en remettre aux commandes calculées par le pilote automatique ou, à défaut, tenter de limiter les dégats en
adoptant une attitude la plus neutre possible.
2.3
Principes de la chaı̂ne de commande
Afin de pouvoir interpréter les informations reçues par la radio-commande et ainsi agir
sur les servo-moteurs, il est nécessaire de comprendre le fonctionnement d’un servo-moteur
et de la liaison radio elle-même. Cette section détaille le principe de fonctionnement d’un
servo moteur puis celui de la réception radio qui utilise le codage Pulse Position Modulation
(PPM). Le codage et le décodage de PPM sont duaux et sont utilisés à la fois par les servomoteurs et le récepteur radio.
19
Fig. 2.5 – Compteur décimal et servo-moteur
Fig. 2.6 – Impulsion de commande d’un servo-moteur
2.3.1
Les servo-moteurs
Un servo-moteur est l’association d’un moteur électrique miniature muni d’un petit
circuit électronique assurant sa commande et d’un réducteur, le tout actionnant un axe de
sortie (voir figure 2.5). Le servo-moteur est commandé par des impulsions qui caractérisent
la position de l’axe de sortie. C’est la durée de l’impulsion qui détermine cette position.
La durée du niveau haut logique varie entre 1 et 2 ms. La fréquence de mise à jour de la
position du servo-moteur doit être de 50 Hz, soit une période de 20 ms (voir figure 2.6).
Le micro-contrôleur n’a pas suffisamment de ports de sortie pour être connecté directement aux servo-moteurs. On utilise pour cela un compteur décimal (fig. 2.5) permettant
de compter les impulsions et de le répartir sur chaque servo-moteur. La figure 2.7 illustre
le découpage du signal vers les différents servo-moteurs. Sur cette figure, le signal d’entrée
est représenté sur le permier chronogramme. On constate qu’à chaque impulsion du signal
d’entrée, on démarre une impulsion sur l’une des voies du compteur, les unes après les
autres. Chaque impulsion du signal d’entrée correspond à la fin d’une voie et au début
de la suivante. Le signal d’une voie est donc un créneau de largeur variable exprimant
la valeur de la voie. Ici, nous avons 7 voies. On décode les voies successivement, jusqu’à
arriver à un silence anormalement long. L’impulsion qui y met fin est dite impulsion de
synchronisation. Elle permet de réinitialiser le comptage des voies et indique le début de
la première voie (ici 0).
Fig. 2.7 – Trame PPM à 7 canaux et détail de répartition sur les servos
20
2.3.2
21
Décodage PPM
Dans un modèle radio-commandé classique, les informations renvoyées par le récepteur
radio sont envoyées directement vers le compteur. Ici, nous souhaitons intercepter les commandes reçues par radio afin de pourvoir les traiter et les utiliser pour contrôler le pilotage
automatique. Nous voulons par exemple :
– mixer plusieurs voies (pour faire des virages coordonnés par exemple) ;
– uniformiser les canaux (pour pouvoir utiliser des radio-commandes différentes) ;
– substituer les commandes reçues par les commandes fournies par le pilote automatique.
Le récepteur fournit des trames PPM. C’est donc la position des impulsions qui va
déterminer la valeur de chaque canal. Contrairement au signal de commande des servomoteurs, la longueur du niveau haut importe peu. L’information est contenue dans la
séquence de fronts montants (ou de fronts descendants mais cela revient finalement au
même). L’intervalle entre 2 fronts identiques donne la valeur du canal.
La durée d’une trame est de 20 ms environ (période de 50 Hz). La radio-commande utilisée pour les tests comporte 7 canaux. Chaque canal pouvant prendre une valeur comprise
entre 0.9 et 2.1 ms, la durée de transmission des informations effectives est de 6 à 15 ms
environ. La pause de synchronisation permettant de réinitialiser le numéro du servo reçu
est donc comprise entre 5 et 14 ms (intervalle majorant). Chaque impulsion correspond à
la fin de l’information d’un canal et au début du suivant.
Un exemple de correspondance entre une trame PPM et les commandes des servomoteurs est donné sur la figure 2.7. Le fonctionnement du codage et du décodage étant
complètement réversible, la lecture d’un tel signal revient à effectuer le même travail que
le compteur décimal dont le fonctionnement à été détaillé précédemment (c.f. 2.3.1).
2.3.3
Synthèse des commandes de servo-moteur
Une fois la valeur de chaque canal lue, il s’agit de faire générer des ordres pour les
gouvernes et le(s) moteur(s). Ces commandes peuvent provenir :
– de la radio-commande directement dans le cas d’un pilotage en mode manuel ;
– du pilote automatique dans le cas d’un pilotage assisté ou entièrement autonome
(appelés respectivement auto1 et auto2 par la suite).
Dans tous les cas, les commandes sont normalisées en fonction de la radio-commande
car toutes les radio-commandes n’émettent pas de la même façon (les plages de valeur
peuvent différer par exemple). Les commandes uniformisées sont ensuite envoyées au pilote automatique qui calcule en permanence des lois de pilotage. On utilise ici l’avantage
d’avoir deux micro-contrôleurs pour faire des tâches différentes parallèlement. Le microcontrôleur MCU1 choisit donc sa source de commande. Si le micro-contrôleur de navigation
n’envoie plus de données, on tente de passer en mode manuel. Si la radio-commande est
hors de portée (pas de réception radio) alors on passe en mode dagradé (failsafe). Les
règles de changement de mode de fonctionnement sont détaillées dans le tableau 2.1. ê Les
trames envoyées sur le compteur sont exactement du même type que celles que transmet le
22
récepteur radio. On recompose donc un signal à partir de la source de données sélectionnée.
Perte RC Perte PA
Mode manuel
→ failsafe
–
Mode automatique
–
→ manuel
Mode failsafe
–
–
Tab. 2.1 – Changements de mode de fonctionnement en cas de défaillance (RC : radiocommande, PA : pilote automatique
-
2.4
Méthode de certification utilisée
Nous avons identifié les fonctionnalités critiques et détaillé le fonctionnement de l’une
d’entre elles. Il convient maintenant de choisir une méthode de certification afin d’améliorer
la fiabilité du code source et la sécurité générale de l’appareil.
La certification en soi n’est pas une assurance qualité. On ne certifie pas que le logiciel
ne contient aucun défaut. On s’assure qu’il valide des spécifications concordant avec le
cahier des charges. Ainsi, on accroı̂t la confiance que l’on a dans le logiciel. Cependant, la
qualité des spécifications est à prendre en compte. Pour valider des spécifications, il existe
plusieurs approches :
les tests permettent de vérifier a posteriori des propriétés du programme. La pertinence
de cette méthode dépend du choix du jeu de test. Cependant, cette méthode est
difficile à mettre en œuvre dans le cas d’un micro-contrôleur et quasiment impossible
lorsque le micro-contrôleur est embarqué à bord d’un aéromodèle.
l’interprétation abstraite permet de travailler directement sur le code source du programme, et de réaliser une analyse statique. On peut en tirer les propriétés fondamentales du code. L’étude du code d’un projet réel devient toutefois titanesque, de
part la lourdeur de la méthode.
la vérification en amont consiste à écrire du code dans un langage permettant de faire
des vérifications directement, puis de générer du code opérationnel à partir de ce
code sûr. La fiabilité de la méthode repose sur la correction du générateur de code
et du compilateur utilisés. C’est cette méthode, plus facile à mettre en œuvre, que
nous utilisons ici.
Cependant, il ne faut pas perdre de vue qu’une méthode de certification ou de vérification
n’est jamais une preuve absolue. Chaque méthode a ses défauts et ses qualités [CC01] et
dans tous les cas, la validité d’une certification repose sur la validité de tous les éléments
de l’environnement, aussi bien de développement que d’utilisation réelle. Ainsi, du code
vérifié et testé sur une machine peut ne pas se comporter de la même façon sur le microcontrôleur cible, tout simplement car les compilateurs utilisés n’implémentent pas le code
23
source de la même façon (par exemple lorsque la sémantique du langage n’est pas spécifiée
assez rigoureusement). Une vérification en amont peut donc être correcte mais s’avérer
désatreuse sur le produit fini à cause de tels problèmes de compilateur ou de normalisation
des langages (lors de changements réguliers de version en particulier).
Chapitre 3
Utilisation d’un langage synchrone
Les systèmes embarqués sont réellement particulier du fait de leur immersion totale
dans l’environnement. Contrairement à un programme traditionnel qui lit des informations
pour calculer un ou des résultats, un programme embarqué se doit avant tout d’interagir
avec son environnement, quitte à effectuer des calculs de qualité moindre. Pour répondre à
un tel besoin, on utilise des langages de programmation dits synchrones, présentés ici. Nous
introduirons ensuite le langage sélectionné pour ce projet et enfin l’utilisation qui en a été
faite durant ce stage au travers de l’exemple du décodage des PPM dont le fonctionnement
général a été expliqué au chapitre 2.3.2.
3.1
3.1.1
Les langages synchrones
Systèmes temps-réel
Le groupe CNRS sur la problématique temps-réel a défini en 1988 les systèmes tempsréel comme ceci :
Le comportement d’un système informatique est qualifié de temps réel lorsqu’il
est assujetti à l’évolution d’un procédé qui lui est connecté et qu’il doit piloter
ou suivre en réagissant à tous ses changements d’états.
Les systèmes temps-réel s’opposent donc aux systèmes transformationnels, qui effectuent un calcul à partir de données et d’entrées lues au démarrage, puis fournissent des
sorties et meurent. Les systèmes qui suivent l’évolution de l’environnement sont de deux
types :
système interactif :
– système en interaction quasi permanente avec son environnement, y compris après
initialisation ;
– la réaction du système est déterminée par les événements reçus et par l’état courant
(qui est donc fonction des événements et des réactions passées) ;
– le rythme de l’interaction est déterminé par le système et non par l’environnement.
système réactif ou temps-réel
24
CHAPITRE 3. UTILISATION D’UN LANGAGE SYNCHRONE
25
Fig. 3.1 – Principe d’interaction d’un système temps-réel (ou réactif)
– système en interaction permanente avec son environnement, y compris après initialisation ;
– la réaction du système est déterminée par les événements reçus et par l’état courant
(qui est donc fonction des événements et des réactions passées) ;
– le rythme de l’interaction est déterminé par l’environnement et non par le système.
La figure 3.1 illustre le principe des systèmes temps-réel.
Un système temps réel peut être représenté par une machine à état, un automate dont
l’avancement serait provoqué par les événements de l’environnement. Le calcul de chaque
nouvel état doit être plus rapide que l’intervalle entre deux événements.
3.1.2
L’hypothèse du synchronisme
En règle générale, un programme lit des entrées et calcule une ou plusieurs sorties. La
particularité des systèmes embarqués est que l’interaction avec l’environnement importe
plus que le calcul lui même [Lee01]. En effet, durant le calcul, l’environnement évolue
toujours et les sorties peuvent ne plus être pertinentes. Pour remédier à cela, on fait l’hypothèse que les données ne sont pas modifiées pendant le calcul. En pratique, les données
sont lues avant le calcul et sont considérées fixes pour toute la durée du calcul.
Les valeurs des variables internes ou de sorties sont figées au fur et à mesure de leur
élaboration. Cela revient à n’utiliser que des assignations uniques, gelant ainsi le temps du
point de vue de chaque variable. On assure ainsi un comportement déterministe.
Les premiers problèmes arrivent lorsqu’on veut programmer en utilisant cette hypothèse. En effet, le programmation séquentielle traditionnelle assure le déterminisme
recherché. Cependant, dans le contexte d’un système réactif, on travaille avec des soussystèmes temporellement indépendants et qui s’exécutent parallèlement. Les temps d’exécution interviennent donc dans le résultat calculé. Il n’est donc pas possible de prévoir le
comportement dans un environnement réel, peuplé de retards, délais, etc.
26
C’est donc le caractère asynchrone du monde concret qui pose problème. Pour faire
face à cet asynchronisme, il est nécessaire de synchroniser manuellement les exécutions
des différentes parties d’un système, par le biais de rendez-vous, sémaphores, etc. C’est le
principe de fonctionnement des programmes informatiques en général.
Cependant, la notion de temps d’exécution n’étant pas maı̂trisée, il est difficile de
prévoir les comportements lorsqu’il y a concurrence de deux blocs d’instructions (voir
table 3.1).
var X : integer;
X <- 0
[
X <X <||
Y <]
;
1;
2;
X+1;
Après exécution de ces lignes de
pseudo-code, X vaut 2.
Dans l’hypothèse d’un comportement
asynchrone, plusieurs entrelacements sont
envisageables et Y peut prendre plusieurs
valeurs possibles : 1, 2 ou 3.
Le comportement est donc non
déterministe.
Tab. 3.1 – Problème de déterminisme lié à la concurrence
3.1.3
Synchronisme fort
Pour faire face au problème de l’ordre d’exécution de différentes séquences de code, on
fait l’hypothèse dite du synchronisme fort :
Toutes les opérations sont supposées s’exécuter en un temps nul.
Concrètement, toutes les instructions s’exécutent en même temps, sans ordre particulier. On considère ici que le temps d’exécution est négligeable devant la dynamique de
l’environnement. L’idée consiste donc à ne pas considérer ces temps d’exécution, à les
supposer nuls (voir figure 3.2).
Cette hypothèse a l’avantage de simplifier le comportement interne du système, rendant ainsi déterministe son comportement. Sur l’exemple de la table 3.1, les multiples
affectations de X ne permettent pas d’assurer le déterminisme. Les langages synchrones,
qui mettent en pratique l’hypothèse du synchronisme fort, interdisent les affectations multiples.
Le code écrit sous l’hypothèse du synchronisme fort étant déterministe, il est toujours
possible de le compiler sous forme d’un automate fini minimal. On repasse dans le monde
réel en compilant l’automate sous forme de code séquentiel (en C par exemple). On obtient
ainsi un code utilisable en exploitation. La validité du code généré dépend de l’automate
dont il découle. Il est possible d’effectuer des preuves automatiques de propriétés sur les
automates (Model Checking).
27
Fig. 3.2 – Principe du synchronisme fort : les temps d’exécution sont supposés nuls face à
la dynamique de l’environnement
3.2
Le langage LUSTRE
Le langage LUSTRE [HCRP91] est un langage de programmation synchrone. Son principe repose sur la manipulation de flots (ou flux) de données infinis. Ce langage est destiné
à écrire des systèmes de contrôle de façon la plus « naturelle » possible, afin d’obtenir
une programmation sûre. La programmation consiste donc à décrire le comportement du
système en fonction des flots de données qu’il consomme et produit.
Ainsi, un programme Lustre est constitué de blocs fonctionnels travaillant sur des variables d’entrée-sortie. Ces variables sont des flots de données infinis. Une opération Lustre
est considérée comme agissant sur l’ensemble d’un flot de données et non sur la valeur instantanée de cette variable. Cela permet d’écrire des relations générales qui devront toujours
être vérifiées. Cette particularité se retrouve par exemple en programmation logique.
L’exécution d’un programme Lustre calcule la nouvelle valeur de chaque flot de données
en fonction des valeurs des autres flots et de ses propres valeurs précédentes. Le langage
Lustre est donc adapté aux systèmes échantillonnés. Le rythme d’exécution est déterminé
par l’environnement. Ce n’est pas le flot qui impose son rythme au programme. Une fonction
(ou bloc fonctionnel) Lustre est appelée un nœud. Un programme est un ensemble de nœuds.
3.2.1
Exemple booléen : détecteur de front montant
Le langage Lustre est particulièrement adapté aux problèmes manipulant majoritairement des booléens, comme la gestion des systèmes de commande.
Ce court exemple illustre comment Lustre permet de contrôler des variables d’état
booléennes. Ici, on dispose d’un flux booléen en entrée et on souhaite détecter les fronts
montants [HR02].
node EDGE(X: bool) returns (Y: bool);
28
let
Y = X and not pre(X);
tel
La première ligne spécifie l’interface du nœud. Le nœud EDGE produira donc un flux
booléen Y à partir de X.
La ligne suivante définit l’équation vérifiée par Y :
Y = X and not pre(X);
Il s’agit d’une expression booléenne sur des flux infinis. Les opérateurs “and” et “not”
sont les opérateurs booléens usuels étendus à l’ensemble du flux. C’est à dire que que si
A = (a1 , a2 , ..., an , ...) et B = (b1 , b2 , ..., bn , ...), alors l’expression A and B correspond au
flux booléen (a1 ∧ b1 , a2 ∧ b2 , ..., an ∧ bn , ...).
L’opérateur “pre” désigne l’élément précédent dans un flux. Par exemple si A =
(a1 , a2 , ..., an , ...), alors pre(A) est le flux (nil, a1 , a2 , ..., an−1 , ...). C’est à dire la première
valeur est la valeur indéfinie nil, et pour tout n > 1, la n ème valeur est la n − 1ème valeur
de A.
Pour s’affranchir de la valeur indéfinie nil, il est possible d’initialiser un flux avec
l’opérateur “->” (suivi de). Si A = (a1 , a2 , ..., an , ...) et B = (b1 , b2 , ..., bn , ...), alors “C =
A -> B” est le flux C = (a1 , b2 , ..., bn , ...). Ici, la première valeur de C est a1 et pour tout
n > 1 on a cn = bn .
Ainsi, dans le code de notre exemple, si X = (x1 , x2 , ..., xn , ...), alors l’expression “Y =
X and not pre(X)” donne le flux suivant :
Y = (nil, x2 ∧ ¬ x1 , ..., xn ∧ ¬ xn−1 , ...)
Ici, la première valeur de Y est nil. En effet, Y est calculé en fonction de X et pre(X).
On connaı̂t x1 mais x0 est indéfini. y1 = x1 ∧ ¬ x0 est donc indéfini aussi et vaut nil.
Pour éviter d’obtenir nil, utilisons l’opérateur -> et la constante false1 . L’écriture du
nœud EDGE devient donc :
node EDGE(X: bool) returns (Y: bool);
let
Y = false -> X and not pre(X);
tel
3.2.2
Exemple numérique : compteur
Des types numériques (int et float) sont également définis, permettant par exemple
décrire un compteur numérique. L’expression C = 0 -> pre(C) + 1 ; définit par exemple
la liste des entiers naturels.
1
En Lustre, une constante n est un flux infini ayant toujours la valeur n. Les contantes prédéfinies sont
true, false et les valeurs numériques. Par exemple, 12.34 signifie (12.34, 12.34, 12.34, ...).
29
Ecrivons maintenant un compteur plus évolué permettant de préciser le pas (incr) de
comptage, la valeur initale (init), s’incrémentant à chaque valeur vraie d’un flux X et
pouvant être réinitialisé (reset).
La définition complète de ce type de compteur est la suivante :
node COUNTER(init, incr : int; X, reset : bool) returns (C : int);
var PC : int;
let
PC = init -> pre C;
C = if reset then init
else if X then (PC + incr)
else PC;
tel
La variable intermédiaire PC représente la valeur précédente du compteur.Par ailleurs,
nous voyons ici que l’on peut utiliser la conditionelle if ... then ... else ... pour
écrire une instruction Lustre.
Ce compteur assez générique peut par exemple être utilisé pour énumérer les nombres
pairs avec odds = COUNTER(0, 2, true, true->false) ;
3.3
Lustre dans le projet Paparazzi
Comme nous l’avons vu dans la section 2.2.2 (page 15), notre travail de certification
s’effectuera sur le micro-contrôleur MCU1 qui est chargé des fonctions de :
– réception des événements de la radio-commande,
– génération du signal de commande des servo-moteurs,
– communication avec le micro-contrôleur MCU0 (pilote automatique),
– gestion des modes de fonctionnement.
Chacune de ces fonctions était initialement codée en C sous forme d’une fonction. Nous
souhaitons les ré-écrire en utilisant le langage Lustre. En effet, le langage Lustre peut être
compilé pour générer du code source C que l’on peut intégrer au code source existant.
Ainsi, le programme principal du micro-contrôleur, toujours écrit en C, peut faire appel
aux fonctions crées à partir du code source Lustre.
Nous nous intéresserons par la suite seulement au traitement des commandes reçues
depuis la radio-commande.
3.3.1
Entrées / Sorties
Le micro-contrôleur MCU1 étant chargé de réceptionner les commandes radio et d’actionner les servo-moteurs, il est physiquement relié à ces deux entités. Chacune correspond
à un port (une patte) du micro-contrôleur.
Le signal de la radio-commande arrive sur une entrée logique déclenchant une interruption (appelée INPUT CAPTURE1A) à chaque front montant généré par le récepteur radio. La
30
procédure liée à l’interruption est appelée et est chargée de calculer l’intervalle entre les
impulsions successives, afin de décoder le signal PPM, suivant la méthode expliquée à la
section 2.3.2 (page 21).
Le signal de commande des servo-moteurs doit être généré et envoyé sur une sortie (un
port) du micro-contrôleur. Pour cela, on utilise une minuterie (timer ). Un changement de
niveau logique est effectué sur le port correspondant du micro-contrôleur lorsque le temps
est écoulé. On peut donc réarmer la minuterie pour le prochain changement de niveau
logique. On génère ainsi le signal de commande des servo-moteurs, codé selon la méthode
PPM.
3.3.2
La communication inter-micro-contrôleur
La communication entre les deux micro-contrôleurs utilise le bus SPI2 . Le bus SPI
permet de faire communiquer plusieurs micro-contrôleurs sur un bus. Ils utilisent donc
un canal de communication commun. Comme nous l’avons précisé précédemment (2.2.2),
MCU0 est dit maı̂tre et MCU1 est esclave. Cela signifie que c’est toujours MCU0 qui
initie la communication. MCU1 doit répondre à une sollicitation et ne peut pas initier les
communications. L’arrivée d’une information sur le bus SPI provoque une interruption sur
MCU1. On peut donc traiter l’information envoyée par MCU0 et lui répondre.
Le système Paparazzi utilise le bus SPI pour échanger les valeurs de commande des
servo-moteurs. MCU0 donne à MCU1 les commandes de servo-moteurs calculées par le
pilote automatique et en réponse, MCU1 envoie à MCU0 les derniers événements reçus par
radio. L’intérêt de la communication maı̂tre-esclave réside dans la faible propagation des
défaillances. En effet, si MCU0 fonctionne correctement, MCU1 lui passe les valeurs les plus
récentes fournies par la radio-commande. Par contre si MCU0 ne fournit plus de commandes
de pilotage (pour une raison quelconque), cela ne perturbera pas le fonctionnement de
MCU1, qui n’aura simplement plus à répondre aux sollicitations de MCU0.
3.4
3.4.1
Détail du traitement de SIG INPUT CAPTURE1
Le code C existant
Le code C existant étant écrit manuellement, il est adapté pour un fonctionnement sur
micro-contrôleur, en particulier concernant l’empreinte mémoire et le volume de code.
La procédure de traitement listée dans l’annexe A (page 49) est très simple et utilise
quelques finesses de C. Tout d’abord, les variables utilisées pour stocker les dernières valeurs
sont statiques et donc résidentes en mémoire, afin d’occuper une place fixe et de réduire
le temps d’accès. Ensuite, on se rend compte que la façon de traiter cette interruption est
totalement séquentielle et donc très loin de l’optique propositionnelle envisagée.
En Lustre, l’ordre des instructions n’importe pas, car il s’agit d’assertions à satisfaire.
Ici, le simple calcul de la valeur de l’impulsion nécessite un ordre. Le stockage de la nouvelle
2
SPI : Serial Peripheral Interface
31
valeur doit par exemple se faire après avoir lu l’ancienne, qui peut donc être écrasée. Ces
petites difficultés seront traitées en utilisant la particularité des flots de données, qui ne
« perdent » pas les anciennes valeurs, mais ajoutent la nouvelle au flot. Ainsi, la durée
entre deux impulsions s’écrira simplement width = this - pre(this) en Lustre. En effet
la fonction pre(X) représente la valeur précédente du flot X. Ici, nous n’avons donc pas
besoin d’utiliser deux variables Lustre pour calculer l’intervalle entre les impulsions.
3.4.2
Périphériques utilisés sur le micro-contrôleur
Le signal reçu doit être conforme au standard PPM des radio-commandes. Selon ce
standard, le signal est modulé en intervalle entre les impulsions. Le micro-contrôleur étant
interrompu, la seule information dont on dispose est la date de l’interruption, par lecture
du compteur TCNT1 . Le micro-contrôleur stocke la valeur du compteur dans le registre
ICR1 lors de l’interruption. Ainsi, la lecture de ICR1 nous donne la date de l’interruption,
même si la lecture est effectuée plus tard. Le compteur TCNT1 est un compteur codé sur 16
bits. Il est réglé sur l’horloge du micro-contrôleur, soit 16 MHz. La valeur retournée étant
un entier naturel non signé, la taille du compteur est donc de 216 ([0, 65535]). Ce compteur
1
10−6 s, soit 62.5 ns. Le compteur boucle
permet donc de mesurer des durées minimales de 16
1
−6
16
au bout de 2 × 16 × 10 = 4.096 ms.
La valeur de chaque canal de la radio-commande étant matérialisée par un intervalle
entre deux impulsions successives de 0.9 ms à 2.1 ms environ, ce compteur peut être
utilisé pour mesurer cet intervalle. Cependant, on constate que pour le cas de l’impulsions
de synchronisation, d’une durée variant de 5 à 15 ms environ, ce compteur n’est plus
approprié, car il boucle trop rapidement.
Une second compteur est donc utilisé spécialement pour l’impulsion de synchronisation.
Il s’agit du compteur TCNT2 . Ce compteur est codé sur 8 bits seulement, mais son horloge
est 1024 fois plus lente que celle du micro-contrôleur, permettant ainsi de mesurer des
durées de 64 µs à 16.32 ms.
Cependant, l’interruption levée est liée au compteur TCNT1. Seul ce compteur là est sauvegardé lors de l’interruption. La lecture de TCNT2 se fait donc directement sur le compteur
et non sur un registre de sauvegarde.
3.4.3
Conséquence sur le code Lustre
La fonction C auto-générée par le code Lustre devra pouvoir accéder aux valeurs des
compteurs précités. Lustre n’étant pas prévu pour effectuer des accès matériels, il est donc
nécessaire de laisser ce type de code en C. Il a donc été choisi de lire les valeurs des
compteurs avant l’appel de la fonction Lustre. Ainsi, le code Lustre dispose de ses entrées
en une seule fois. Les sorties sont calculées au fur et à mesure de l’exécution du nœud
Lustre. Le nœud proprement dit devra indiquer :
– si une valeur de canal a été lue,
– la valeur du canal si elle a été lue,
– le numéro du canal dont la valeur a été lue,
32
Fig. 3.3 – Découpage modulaire du décodage des trames PPM en Lustre
– si on vient de terminer une trame PPM valide.
Bien évidemment, si on ne lit pas une valeur de canal, les informations concernant
le canal en cours (valeur et numéro) sont caduques. Le nombre de variables (flots de
données) en sortie devant être fixe, toutes seront fournies par la fonction Lustre, mais
certaines pourront être ignorées par le code C appelant. En effet, lorsque l’on décode une
impulsion ne correspondant pas à la valeur d’une voie (soit car il s’agit de l’impulsion de
synchronisation, soit car le signal radio est erroné par exemple), la « valeur du canal »
renvoyée est obsolète et doit être ignorée. Il en est de même pour le numéro du canal lu,
qui n’a lieu d’être que si un canal a réellement été lu.
La procédure Lustre à écrire devra donc comporter dans tous les cas :
– 2 entrées :
– la valeur du compteur TCNT1 lors de l’interruption,
– la valeur courante du compteur TCNT2 ;
– 4 sorties :
– la valeur du canal lue lors l’interruption,
– le numéro du canal lu,
– un booléen indiquant si on a lu une valeur de canal,
– un booléen indiquant si on a reçu une trame PPM complète.
3.4.4
33
Première spécification du décodage PPM
La seule information à notre disposition étant la “date” de l’interruption, on doit définir
ce qu’est une trame PPM en fonction de cette date. Le décodage d’une trame est séparé
en plusieurs parties et sous-parties (voir figure 3.3), sans notion d’ordre d’exécution.
Détection du type d’impulsion reçue
Cette détection repose sur le calcul de l’intervalle entre les deux dernières impulsions.
Ce calcul est effectué à la fois sur le compteur TCNT1 et le compteur TCNT2, afin de détecter
les impulsions de données (data pulses) et l’impulsion de synchronisation (sync pulse). Le
calcul de l’intervalle pour TCNT1 (resp. TCNT2) est effectué par le nœud width (resp. diff ),
Une fois la durée déterminée, on effectue une test afin de déterminer le type de l’impulsion lue. Les nœuds correct pulse et sync pulse sont chargés de ces tests. Les valeurs
seuil sont fournies par le code C à l’aide de constantes (sous forme de macro C) générées
à partir du fichier XML de configuration de la radio-commande.
Compte-tenu des plages d’utilisation des compteurs utilisés pour mesurer l’intervalle
entre deux impulsions, la notion d’impulsion de synchronisation prévaut sur l’impulsion de
données. En effet, le temps de synchronisation dure plus longtemps que le temps de bouclage
de TCNT1. Ainsi, lors d’un temps de synchronisation, il est possible que TCNT1 boucle et que
l’intervalle mesuré corresponde à une donnée. Afin d’éviter ce cas, dès lors qu’un temps de
synchronisation est détecté, on ignore une possible détection d’une impulsion de donnée.
Détermination de l’état d’avancement de la lecture
L’état d’avancement de la lecture dépend de plusieurs paramètres :
– Est-on en train de lire une trame ? Il s’agit de déterminer si une trame est déjà en
cours de lecture ou si on attend le début d’une nouvelle trame ;
– une erreur a-t-elle eu lieu précédemment pendant la lecture de la trame en cours ? Si
une erreur quelconque a eu lieu, on annule l’intégralité de la trame et on en attend
une nouvelle ;
– lit-on le dernier canal pour la trame en cours ? Si tel est le cas, on se prépare à
attendre une impulsion de synchronisation terminant la trame en cours ;
– attend-on une impulsion de synchronisation ? Ce cas intervient après le dernier canal,
ou lorsqu’on a annulé une trame à cause d’une erreur.
Traitement de la réception des impulsions par une machine à états
La machine à état présentée sur la figure 3.4 détaille le fonctionnement du décodage
d’une séquence PPM codée sur 6 canaux. Les états caractéristiques sont les suivants :
1 : état de fin et de début de trame PPM. Lorsqu’on est dans cet état, on signale la fin
d’une trame PPM valide en positionnant la variable valid à vrai. On en ressort sur
réception d’une impulsion de données. Si on reçoit une impulsion de synchronisation,
alors on passe dans l’état E ;
34
Fig. 3.4 – Machine à état décodant un signal PPM à 6 canaux
2 à 6 : états de réception d’impulsions de données. Comme précédemment, toute réception
d’une impulsion de synchronisation envoie sur l’état E ;
7 : état atteint lors de la réception de la dernière impulsion de données. On attend alors
une impulsion de synchronisation pour repasser en état 1 ;
E : état d’erreur. Lorsqu’on est en état d’erreur, on attend la prochaine impulsion de
synchronisation, qui marque le début d’une nouvelle trame. On passe alors en état 1
bis ;
1 bis : état de début de trame PPM atteint uniquement après une erreur. Contrairement
à l’état 1, cet état ne confirme pas la validité de la trame précédente, car il s’agissait
d’une trame erronée.
Les états 1 à 7 forment la chaı̂ne de fonctionnement normal de la machine à état.
Cette machine à état est spécifique au décodage sur 6 canaux. À partir de celle-ci, il
est facile de construire une machine à états générique pour décoder des trames PPM à N
canaux. La figure 3.5 donne la représentation d’une telle machine à états générique. Les
états i (i ∈ [2, N ]) correspondent aux états 2 à 6 de la machine précédente. L’état N+1 est
atteint lors de la dernière impulsion de données.
3.4.5
Détail de la détection d’erreur dans la trame PPM
La validité d’une trame PPM est spécifiée comme ceci :
– Une trame est considérée comme valide si sa réception s’est effectuée sans aucune
erreur ;
– Font partie de la trame toutes ses impulsions de données, ainsi que les deux durées
de synchronisation l’encadrant. Chaque temps de synchronisation appartient donc à
35
Fig. 3.5 – Machine à état générique décodant un signal PPM à N canaux
deux trames consécutives.
– À chaque instant, on sait si on attend une impulsion de données ou de synchronisation.
Si cette attente n’est pas confirmée par la réception de ladite impulsion, une erreur
est générée. On annule donc l’intégralité de trame, jusqu’à retrouver une impulsion
de synchronisation marquant le début de la trame suivante.
data pulse
sync pulse
current frame
error occured
last channel
expected channel
expecting sync pulse
valid
index
updated
❍
●
●
❍
❍
1
●
●
5
❍
●
❍
●
❍
❍
2
❍
❍
0
●
...
...
...
...
...
...
...
...
...
...
●
❍
●
❍
❍
6
❍
❍
4
●
●
❍
●
❍
●
0
❍
❍
5
●
❍
●
●
❍
❍
1
●
●
5
❍
●
❍
●
❍
❍
2
❍
❍
0
●
...
...
...
...
...
...
...
...
...
...
●
❍
●
❍
❍
6
❍
❍
4
●
●
❍
●
❍
●
0
❍
❍
5
●
❍
●
●
❍
❍
1
●
●
5
❍
Tab. 3.2 – Traitement d’une séquence PPM valide, pour un signal comportant 6 canaux
(● : vrai ; ❍ : faux)
Le tableau 3.2 montre le traitement de deux trames PPM valides comportant 6 canaux
de données. Les variables d’entrées sont data pulse et sync pulse. On utilise les variables
internes suivantes :
36
curren frame variable booléenne utilisée pour différencier le cas de la réception d’une
trame valide du cas où une erreur est survenue lors de la dernière trame (on attend
alors le début de la trame suivante),
error occured variable booléenne passant à vrai lorsqu’une erreur est détectée sur la
réception de l’impulsion (mauvais type d’impulsion reçue par exemple),
last channel variable booléenne indiquant si on est en train de traiter le dernier canal
de données pour la trame en cours (la prochaine impulsion devra alors être une
synchronisation),
expected channel variable entière (de 0 à PPM NB CHANNEL) permettant de savoir le
numéro du canal attendu pour l’impulsion en cours (la valeur 0 indique qu’on attend
l’impulsion de synchronisation),
expecting sync pulse variable booléenne signalant l’attente d’une impulsion de synchronisation (son état doit être cohérent avec celui de sync pulse).
Les variables valid, index, updated sont les variables de sortie :
valid variable booléenne dont l’état indique si on a reçu une trame PPM complète sans aucune erreur. Si elle est vrai alors on pourra exploiter les données reçues précédemment ;
index variable entière fournissant le numéro (de 0 à (PPM NB CHANNEL - 1) ) du canal
reçu. Cette valeur n’est significative que lorsque updated vaut vrai ;
updated variable booléenne passant à vrai si on a reçu une impulsion de données valide.
Le numéro du canal ainsi reçu est fourni par index.
3.4.6
Exemples d’erreurs à la réception
Le tableau 3.2 correspondait au fonctionnement normal du décodage PPM pour une
séquence à 6 voies. Nous présentons ici 2 exemples de comportements anormaux contre
lesquels le micro-contrôleur doit se prémunir. Tout d’abord, une erreur de transmission
peut provoquer l’invalidité d’une impulsion (intervalle trop court ou trop long). L’exemple
suivant traite le cas de la réception d’une séquence PPM codant 5 voies alors que le microcontrôleur est programmé pour décoder 6 voies. Ce cas correspond à une inadéquation
entre la radio-commande et le drone, dûe par exempls à une erreur de programmation ou à
l’utilisation d’une autre radio-commande sur la même fréquence radio. Dans tous ces cas,
le micro-contrôleur doit rejeter les trames PPM erronées.
Invalidité aléatoire d’une impulsion
Le tableau 3.3 montre un exemple de détection d’erreur à la réception. Ici, on s’attend à
une séquence PPM à 6 canaux. Les impulsions reçues correspondent aux attentes, jusqu’à
la sixième. En effet, celle-ci est reçue comme une impulsion de synchronisation au lieu
d’une donnée. Une erreur est donc levée (impulsion non conforme aux attentes). Ceci est
confirmé par le passage à vrai de error occured. Par conséquent, la valeur du canal n’est
pas mise à jour (updated vaut faux) et la variable current frame passe à faux.
37
On passe désormais dans une phase d’attente d’une nouvelle trame valide. Le numéro
du canal attendu devient 0, indiquant qu’on attend une impulsion de synchronisation.
La variable d’attente d’une impulsion de synchronisation sera donc à vrai au prochain
passage. Malheureusement, l’impulsion reçue est une donnée. Il y a donc toujours une
erreur, car on attendait un temps de synchronisation. Sur l’impulsion suivante, on reçoit
effectivement l’impulsion de synchronisation et la variable current frame redevient vrai.
Le déroulement de la séquence peut donc continuer normalement.
Lorsqu’une erreur est détectée, c’est donc toute la trame qui est rejetée, et on passe en
état d’attente d’une nouvelle trame.
data pulse
sync pulse
current frame
error occured
last channel
expected channel
valid
index
updated
❍
●
●
❍
❍
1
●
●
5
❍
●
❍
●
❍
❍
2
❍
❍
0
●
●
❍
●
❍
❍
3
❍
❍
1
●
●
❍
●
❍
❍
4
❍
❍
2
●
●
❍
●
❍
❍
5
❍
❍
3
●
❍
●
❍
●
❍
0
❍
❍
4
❍
●
❍
❍
●
●
0
●
❍
5
❍
❍
●
●
❍
❍
1
●
❍
5
❍
●
❍
●
❍
❍
2
❍
❍
0
●
●
❍
●
❍
❍
3
❍
❍
1
●
●
❍
●
❍
❍
4
❍
❍
2
●
●
❍
●
❍
❍
5
❍
❍
3
●
●
❍
●
❍
❍
6
❍
❍
4
●
●
❍
●
❍
●
0
❍
❍
5
●
❍
●
●
❍
❍
1
●
●
5
❍
Tab. 3.3 – Traitement d’une séquence PPM dont une impulsion est mal reçue, pour un
codage sur 6 canaux (● : vrai ; ❍ : faux)
Mauvaise configuration du nombre de canaux
Une autre erreur possible est la mauvaise configuration du nombre de canaux de la
radio-commande. Cela peut être le cas si on utilise plusieurs types d’émetteurs dont les
caractéristiques diffèrent. Un exemple de réception d’une séquence PPM à 5 canaux alors
que le micro-contrôleur est configuré pour décoder une séquence à 6 canaux est donné par
le tableau 3.4.
Le comportement est ici normal lors des six premières impulsions. La septième impulsion est une impulsion de synchronisation, conformément au codage PPM sur 5 canaux.
Malheureusement, le décodage s’effectuant sur 6 canaux, on attend donc une impulsion de
données. Une erreur est donc levée. La trame est annulée (current frame passe à faux),
et on se met en attente d’une impulsion de synchronisation, marquant le début d’une nouvelle trame potentiellement valide (expecting sync pulse passe à vrai pour l’impulsion
suivante).
Le déroulement de la séquence est tel que les cinq impulsions suivantes sont des impulsions de données, donc on reste dans l’état d’erreur, jusqu’à la prochaine impulsions
de synchronisation. On commence alors la réception d’une nouvelle trame PPM. Les va-
data pulse
sync pulse
current frame
error occured
last channel
expected channel
valid
index
updated
❍
●
●
❍
❍
1
●
●
5
❍
●
❍
●
❍
❍
2
❍
❍
0
●
●
❍
●
❍
❍
3
❍
❍
1
●
●
❍
●
❍
❍
4
❍
❍
2
●
●
❍
●
❍
❍
5
❍
❍
3
●
●
❍
●
❍
❍
6
❍
❍
4
●
❍
●
❍
●
●
0
❍
❍
5
❍
●
❍
❍
●
❍
0
●
❍
5
❍
●
❍
❍
●
❍
0
●
❍
5
❍
●
❍
❍
●
❍
0
●
❍
5
❍
38
●
❍
❍
●
❍
0
●
❍
5
❍
●
❍
❍
●
❍
0
●
❍
5
❍
❍
●
●
❍
❍
1
●
❍
5
❍
●
❍
●
❍
❍
2
❍
❍
0
●
●
❍
●
❍
❍
3
❍
❍
1
●
Tab. 3.4 – Traitement d’une séquence PPM codée sur 5 canaux et interprétée comme étant
codée sur 6 canaux (● : vrai ; ❍ : faux)
riables numériques expected channel et index reprennent leur progression et la variable
current frame repasse à vrai.
3.5
Mise en œuvre opérationnelle
Le traitement des PPM tel que décrit précédemment a été écrit en Lustre. Ce code a
été testé opérationnellement sur une carte de commande réelle. Il a fait ses preuves et s’est
montré aussi fiable que le code existant entièrement écrit en C. De plus, la nécessité d’avoir
des informations en continu sur l’état du système a poussé à utiliser la liason série (RS232)
pour recueillir les informations de mise au point. Cette liaison n’est bien évidemment pas
utilisée en exploitation et les performances du code ne peuvent donc être que meilleures
que sur le banc de test.
Conclusion sur l’usage du langage synchrone Lustre
Le langage Lustre nous a permis d’écrire des blocs fonctionnels simples dont la sémantique est très proche du langage parlé. De cette façon, l’écart entre la spécification et le
code source est réduit au minimum. C’est une façon de s’assurer de la validité du code par
rapport auxdites spécifications.
Les deux exemples fournis à la section 3.4.6 montrent que le code écrit en Lustre
fonctionne mais ne constituent en rien des preuves de non vulnérabilité à des défauts du
signal radio reçu. Il reste désormais à effectuer des vérifications formelles sur le code source
écrit. Cela sera décrit dans le chapitre suivant.
Chapitre 4
Vérification des propriétés de sûreté
La vérification de propriétés de sûreté consiste à vérifier que le programme est en
adéquation avec sa spécification. Dans le cadre de ce stage de Master, nous avons écrit du
code de haut niveau en Lustre afin d’effectuer les vérifications en amont.
L’avantage de cette méthode est que le code source en Lustre est très proche de la
spécification. De ce fait, les erreurs sont plus rares et plus faciles à corriger. Nous verrons
que le code ainsi écrit n’est pas directement vérifiable. Nous présentons ici comment nous
avons procédé pour vérifier de telles propriétés.
4.1
Limitations du langage Lustre
Le langage Lustre impose quelques limitations parmi lesquelles les types de données
fournis par le langage. En effet, Lustre ne propose que les types bool, int et float pour
respectivement les booléens, les entiers et les flottants. Ceci pose problème lorsqu’on veut
intégrer du code Lustre sur un micro-contrôleur dont les types sont beaucoup plus détaillés
et précis. Par exemple, la librairie AVR en C propose les types uint8 t (resp. uint16 t
et uint32 t) pour les entiers non signés de 8 bits (resp. 16 et 32 bits). Cette lacune a
compliqué l’écriture du code Lustre car nous avons dû trouver une façon d’exprimer nos
spécifications malgré des types trop simplistes.
Il en résulte que l’on ne peut plus utiliser le vérificateur Lesar fourni avec le langage
Lustre car le code est partiellement écrit en C.
4.1.1
Première approche
La première idée envisagée pour pouvoir intégrer des types personnalisés dans le code
Lustre a été d’écrire en Lustre les opérations de base sur ces types (somme, multiplication,
égalité, comparaison, etc.). Pour cela, on écrit en Lustre les spécifications de chaque type.
Ainsi, on doit modéliser la modularité des types employés sur le micro-contrôleur.
Cette solution permet de spécifier complètement le comportement des types du microcontrôleur et donc d’obtenir un code source tout-Lustre. Cependant, le code C généré est
39
CHAPITRE 4. VÉRIFICATION DES PROPRIÉTÉS DE SÛRETÉ
40
très lourd et très préjudiciable en terme de performance. De plus, nous avons remarqué que
le code C généré transforme les types int de Lustre en entier int C, qui sont interprétés
par la librairie AVR comme uint16 t. Or uint16 t est un type entier modulaire. Les tests
de comparaison par rapport à zéro sont donc erronés : ils peuvent être toujours vrais ou
toujours faux. Le comportement obtenu diffère donc de celui attendu. Cette solution ne
peut pas être retenue.
4.1.2
Seconde approche
Afin d’utiliser les types natifs du micro-contrôleur (uint8 t, uint16 t et uint32 t),
nous avons décidé de faire appel aux fonctions C sur ces types. En effet, comme il est
possible d’appeler des fonctions C, par exemple pour effectuer des opérations de bas niveau,
il est également possible d’importer de nouveaux types qui sont effectivement définis lors de
l’intégration avec le code C. Comme dans le cas précédent (4.1.1), il est nécessaire d’écrire
chacune des opérations élémentaires sur les nouveaux types définis, mais cette fois-ci, on
les écrit en C et on utilise donc les opérations de la librairie C.
L’amélioration est immédiate : on peut utiliser directement les types natifs pour écrire
du code Lustre. Le code C final sera composé des opérateur écrits en C intégrés dans le
code C généré à partir de Lustre. De plus, on peut s’affranchir des appels fonctionnels
(qui ralentissent l’exécution) en utilisant la primitive inline de C. Le code obtenu est donc
directement utilisable sur le micro-contrôleur (après compilation).
Cependant, cette approche pose problème lorsqu’il s’agı̂t de vérifier des propriétés du
code source de façon automatique. Le laboratoire VERIMAG de Grenoble, qui a défini le
langage Lustre, fournit avec celui-ci un outil de vérification appelé Lesar. Celui-ci permet de
vérifier si une assertion écrite en Lustre est vraie ou fausse. Cette assertion est l’expression
de la ou des propriétés que le code Lustre doit remplir le code Lustre.
4.2
Vérification de propriétés
On utilise donc l’outil Lesar pour vérifier des propriétés du code source Lustre. La
propriété à vérifier est une expression booléenne des variables du code Lustre. Comme les
variables Lustre sont des flux infinis de données, une propriété vérifiée l’est à tout moment
de l’exécution.
4.2.1
Principe
Vérifier une propriété consiste à écrire un nœud Lustre décrivant le fonctionnement
attendu lors de l’exécution du code Lustre. Ce nœud est écrit en Lustre.
En effet, l’intérêt d’écrire la propriété à vérifier dans le même langage que le programme
(ou le sous-programme) lui-même est de pouvoir facilement intégrer le programme à la
propriété. Ainsi, pour prouver qu’une expression B (la propriété) est un invariant sur un
programme P, on fabrique un nouveau programme P’ composé du corps de P et du système
41
Fig. 4.1 – Principe du programme de vérification
d’équations définissant B. La seule sortie de P’ sera B (cf. figure 4.1). Vérifier la propriété
B revient donc à s’assurer que la sortie est constante.
La génération de code repose sur la création d’un graphe d’états du système (cf. 3.4
et 3.5 par exemple). Cette machine à états peut être simplifée avec les règles classiques
[Jen92]. Si la propriété est invariante, alors la machine à états se réduit à un état unique.
4.2.2
Exemple
Soit un nœud modélisant une bascule pouvant être activée (set) ou réinitialisée (reset).
Ce noœud renvoie le niveau de la bascule sous forme de variable booléenne. On dispose
également d’un état initial (initial).
Soit SWITCH1 une première version de la bascule (cf. annexe B). Lorsque set est vrai,
on active la bascule. Sinon, si reset est vrai, alors on désactive la bascule. Ainsi lorsque
set et reset valent vrai en même temps, la bascule est activée. Dans les autres cas, la
bascule reste inchangée.
Soit SWITCH une seconde version de la bascule (cf. annexe B). Ici, on active la bascule si
set vaut vrai et si la bascule n’était pas déjà activée. Si set vaut faux, le comportement
est identique à celui de SWITCH1. La machine à états correspondant à SWITCH est donnée
sur la figure 4.2.
Nous allons vérifier que les nœuds SWITCH et SWITCH1 sont bien identiques tant que set
et reset ne sont pas vrais en même temps. Pour cela, écrivons un nœud de vérification
comparant les sorties de SWITCH et SWITCH1 :
node verif_switch{set, reset, inital: bool) returns (ok: boll);
var level, level1: bool;
let
level = SWITCH(set, reset, initial);
level1 = SWITCH1(set, reset, initial);
ok = (level = level1);
assert not(set and reset);
tel
initial / level
42
0
¬ initial / ¬ level
reset / ¬ level
1
2
¬ reset / level
¬ set / ¬level
set / level
Fig. 4.2 – Automate du nœud SWITCH
¬ initial / ok
initial / ok
set / ok
/ ok
¬ set / ok
¬ reset / ok
reset / ok
(a)
(b)
Fig. 4.3 – Automate du programme de vérification
On calcule ici les résultats donnés par des entrées identiques sur SWITCH et SWITCH1.
L’assertion « assert not(set and reset) » permet de s’assurer que set et reset ne
sont pas simultanéement vrai.
Le compilateur Lustre génère donc un automate décrivant notre programme de vérification. Cet automate est représenté sur la figure 4.3 (a). Il est donc possible en appliquant
les règles de manipulation des graphes d’états de réduire cet automate. On obtient donc
un automate minimal représenté figure 4.3 (b). Cet automate est réduit à un seul état.
Donc ok est un invariant pour le nœud verif switch. On a donc montré que SWITCH et
SWITCH1 ont le même comportement lorsque ¬(set ∧ reset).
43
Prototype du nœud ppm valid :
node ppm_valid(icr1: uint16_t; tcnt2: uint8_t)
returns (valid: bool;
value: uint16_t;
index: uint8_t;
updated: bool);
Tab. 4.1 – Code d’exécution pour SIG INPUT CAPTURE 1
Prototype du nœud ppm valid verif :
node ppm_valid_verif(icr1; tcnt2: int)
returns (valid: bool;
value: int;
index: int;
updated: bool);
Tab. 4.2 – Code de vérification pour SIG INPUT CAPTURE 1
4.2.3
La vérification dans le projet Paparazzi
Les paragraphes 4.1.1 et 4.1.2 ont proposé deux approches pour écrire du code Lustre
adapté au micro-contrôleur utilisé dans le projet Paparazzi. Cependant, aucune de ces
approches n’est utilisable telle quelle. En effet, la première permet de faire des vérifications
mais ne permet pas de générer du code exécutable, alors que la seconde est directement
utilisable mais ne permet aucune vérification.
L’idée retenue est donc de séparer le code d’exécution du code de vérification. De ce
fait, la validité des vérifications repose sur l’adéquation entre le code d’exécution et le code
de vérification.
Vérification d’une propriété sur SIG INPUT CAPTURE 1
Nous allons illustrer la séparation de code en reprenant l’exemple du traitement des
PPM (cf. 3.4). Le nœud SIG INPUT CAPTURE comporte 4 sorties : valid, value, index et
updated. Les spécifications du codage PPM stipulent que l’impulsion de synchronisation
permet de repérer la fin d’une trame et le début de la suivante. On ne peut donc pas lire
une valeur de canal lorsque la fin de trame est détectée (l’impulsion n’est pas une impulsion
de donnée). Nous allons vérifier que nous n’avons jamais valid et updated simultanément
vrais.
Le code d’exécution dont un extrait est présenté dans le tableau 4.1 fait apparaı̂tre les
types natifs du micro-contrôleur. En revanche le code de vérification (tableau 4.2) n’utilise
que les types définis par Lustre.
44
La vérification de l’exclusion mutuelle entre index et updated passe par l’écriture d’un
nœud de vérification :
node test_valid_updated(icr1; tcnt2: int)
returns (ok: bool);
var valid: bool;
value: int;
index: int;
updated: bool;
let
(valid, value, index, updated) = ppm_valid(icr1, tcnt2);
ok = not (valid and updated);
assert (icr1 >= 0 and icr1 < 65535); -- icr1 est un entier de 16 bits
assert (tcnt2 >= 0 and tcnt2 < 255); -- tcnt2 est un entier de 8 bits
let
Dans ce nœud, on utilise les entrées habituelles de ppm valid et on crée des variables
locales pour réceptionner les sorties. L’unique sortie ok est l’expression de la propriété à
démontrer : ¬(valid ∧ updated).
On peut donc utiliser le vérificateur Lesar sur ce nœud pour vérifier que ok est un
invariant.
Problème rencontré
La vérification de cette propriété simple est délicate. En effet, l’outil de vérification
Lesar est avant tout conçu pour travailler sur des variables booléennes. Les vérifications
sur des domaines numériques sont possibles mais uniquement sur des cas très simples. En
effet, une comparaison de 2 valeurs numériques par exemple n’est pas interprétée d’un
point de vue sémantique mais seulement logique. Lesar conservera donc une expression
comme (x ≤ −10) ∧ (x ≥ 10) au lieu d’indiquer qu’elle est toujours fausse. Ceci est dû au
fait que Lesar n’intègre pas d’arithmétique dans ses vérifications. La notion de domaine
d’une variable numérique serait nécessaire pour un tel cas.
Autre approche
Pour faire face au problème des variables numériques dans Lesar, une autre approche
a été envisagée : la modélisation des nombres en binaire. De cette manière, il est facile de
modéliser les types natifs du micro-contrôleur (notamment la modularité des entiers). On
obtient donc un code faisant intervenir exclusivement des variables booléennes.
Cependant, l’explosion combinatoire est telle que cette méthode est inexploitable. En
effet, au lieu de résonner sur les domaines et en particulier les limites de domaine des
variables numériques, cette approche considère toutes les variables comme indépendantes.
La taille de l’espace d’états devient donc 224 , soit environ 16.7 × 106 .
45
Bien que cette approche soit théoriquement réalisable, sa mise en œuvre est quasiimpossible dans le cadre d’un projet réel. En effet, la vérification d’une simple addition sur
8 bits prend un temps de l’ordre de la minute. De plus, on s’éloigne encore un peu plus du
code d’exécution. La validité de la vérification dépendant de la forte corrélation entre lede
définir code d’exécution et le code de vérification, il est difficile de faire confiance à une
méthode visant à ré-écrire tous les types de données sous forme binaire.
Conclusion
Cette étude a permis d’explorer les possibilités d’intégration de code « sûr » dans
un micro-drone. Les spécificités des drones et micro-drones imposent de fortes contraintes
opérationnelles, notamment car la plateforme de développement est différente de la cible
finale.
L’approche envisagée
La génération automatique de code à partir d’un langage de haut niveau tel que Lustre
est possible mais pose des problèmes quant à l’intégration au système global. En effet,
le code ainsi généré est théoriquement « sûr », mais les vérifications ne prennent pas en
compte l’aspect temporel du problème. Ainsi, la code auto-généré est deux fois plus lent
à l’exécution que le code original. Cependant, la charge maximale du micro-contrôleur ne
semble pas être atteinte et nous n’avons pas constaté de défaut de performance.
La vérification en tant que telle pose beaucoup de problèmes, principalement dûs aux
limitations du typage du langage Lustre. L’outil de vérification Lesar fourni avec la version
universitaire du langage Lustre ne permet pas de vérifier efficacement des propriétés sur
les domaines numériques. Les versions commerciales de Lustre telles que Scade intègrent
quant à elles des générateurs de code optimisé ainsi que des vérificateurs efficaces.
Méthode de travail
Même si la vérification de code source reste imparfaite, ce stage a été l’occasion de
ré-écrire une partie du code source critique dans un langage de haut niveau au plus près
des spécifications. Par cet méthode de travail, la sûreté du code source a été améliorée.
De plus, les tests effectués sur un banc de test utilisant une carte de commande réelle ont
permis de valider les modifications apportées avant de tester le nouveau code en vol.
L’accent a été mis sur la disponibilité et la réutilisabilité des travaux réalisés. En effet,
le projet Paparazzi est un projet libre (open source). Il est donc naturel que les travaux
effectués dans ce cadre soient disponibles avec le reste du projet Paparazzi. On peut donc
retrouver le code Lustre écrit durant ce stage sur le serveur CVS du projet1 . De plus, afin
que les utilisateurs potentiels puissent générer automatiquement le code source à partir
du code Lustre, il a été nécessaire d’améliorer le mode de diffusion des outils Lustre. Un
paquetage Debian a ainsi été créé.
1
Projet Paparazzi : http ://savannah.nongnu.org/projects/paparazzi/
46
47
Perspectives
Le travail sur un drone est très enrichissant tout d’abord par l’aspect « tout-embarqué »
du concept mais aussi d’un point de vue sûreté de fonctionnement car la moindre défaillance
technique se paie comptant. L’amélioration de la sûreté d’un micro-drone devra donc
probablement passer par l’utilisation d’outils professionnels de génération de code et de
vérification comme c’est déjà le cas pour les avions traditionnels : Airbus utilise Scade
pour le code critique de ses avions de dernière génération.
Beaucoup de travail est encore à accomplir, notamment la recherche de solutions de
spécification et de normalisation du code source suffisamment simples à mettre en œuvre
et de coût modéré pour pouvoir envisager le développement de micro-drones abordables
techniquement et financièrement pouvant satisfaire à une future réglementation permettant
l’intégration réelle des drones civils dans les espaces contrôlés.
ANNEXES
Annexe A
Interruption SIG INPUT CAPTURE1 en C
SIGNAL( SIG_INPUT_CAPTURE1 )
{
static uint16_t last;
uint16_t this;
uint16_t width;
static uint8_t state;
static uint8_t sync_start;
this = ICR1;
width = this - last;
last = this;
/*
/*
/*
/*
/*
Last value of ICR1 */
to store current value of ICR1 */
to compute the width between last 2 pulses */
state = channel number */
date of last synch pulse */
/* reading date of interrupt */
/* computing pulse width */
/* storing current value as the last one */
if( state == 0 ) {
/*
uint8_t end = TCNT2;
/*
uint8_t diff = (end - sync_start); /*
sync_start = end;
/*
expecting a synch pulse */
reading date of counter TCNT2 */
computing length of synch pulse */
storing current value */
/* The frame period of the mc3030 seems to be 25ms.
* One pulse lasts from 1.05ms to 2.150ms.
* Sync pulse is at least 7ms : (7000*CLOCK)/1024 = 109
*/
if( diff > (uint8_t)(((uint32_t)(7000ul*CLOCK))/1024ul) ) {
state = 1;
/* this really is a synch pulse */
}
}
else {
/* Read a data pulses */
if( width < 700ul*CLOCK || width > 2300ul*CLOCK)
RestartPpmCycle();
/* this is not a data pulse */
ppm_pulses[state - 1] = width;
/* storing this value in an array */
49
ANNEXE A. INTERRUPTION SIG INPUT CAPTURE1 EN C
if (state >= PPM_NB_PULSES) {
ppm_valid = 1;
RestartPpmCycle();
} else
state++;
}
return;
}
50
/* reached last channel ? */
/* expecting synch pulse from now */
/* expect next chanel */
Annexe B
Code source Lustre pour la
vérification de propriétés
Nœud SWITCH1
node SWITCH1 (set, reset, inital:bool) returns (level: bool);
let
level = initial -> if set then true
else if reset then false
else pre(level);
tel
Nœud SWITCH
node SWITCH (set, reset, inital:bool) returns (level: bool);
let
level = initial -> if set and not pre(level) then true
else if reset then false
else pre(level);
tel
51
Bibliographie
[AE04]
R G Austin and G Earp. Power line inspection by UAV : A business case. In
19th international UAV Systems Conference. Bristol, UK, 2004.
[Bri04]
Pascal Brisset.
Drones civils : perspectives et réalités.
nical
report,
École
Nationale
de
l’Aviation
Civile,
www.recherche.enac.fr/~brisset/enac/brisset sapin.pdf.
[CC01]
Patrick Cousot and Radhia Cousot. Verification of embedded software : Problems and perspectives. Lecture Notes in Computer Science, 2211 :97– ? ?, 2001.
Tech2004.
[HCRP91] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The synchronous data-flow
programming language LUSTRE. Proceedings of the IEEE, 79(9) :1305–1320,
September 1991.
[HR02]
Nicolas Halbwachs and Pascal RAYMOND. A tutorial of lustre, 2002.
[Hub01]
Arthur Huber. Death by a thousand cuts : micro-air vehicles in the
service of air force missions. Technical report, Air War College, 2001.
research.maxwell.af.mil/papers/ay2001/awe/huber.pdf.
[Jen92]
Kurt Jensen. Coloured petri nets - basic concepts, analysis methods and practical use, vol. 1 : Basic concepts. EATCS Monographs on Theoretical Computer
Science, pages 1–234, 1992.
[JLSD02] François Derkx Jean-Luc Sorin and Jean Dumoulin. Concept de plate-forme
mobile instrumentée (PMI) pour l’inspection d’ouvrages d’art. In Colloque
Micro-Drones 2002, 2002. www.supaero.fr/microdrone/.
[JLSL03]
Eric Floch Jean-Luc Sorin and Yvon Lesage. Projet de surveillance du trafic
routier par drones. In Journées Micro-Drones 2003, 2003.
[Lee01]
Edward A. Lee. Embedded software from concurrent component models. ACM
SIGPLAN Notices, 36(8) : ? ?– ? ?, 2001.
[MBV04] Jens Bange Marci Buschmann and Peter Vörsmann. MMA - a miniature unmanned aerial vehicle (mini-UAV) for meteorological puposes. In 16th Symposium on Boundary Layers and Turbulence, 2004.
[Pas03]
Claude Pastre. L’observation météorologique, quel avenir ? La Météorologie,
Février 2003.
52
BIBLIOGRAPHIE
53
[Sat]
Akira Sato. Research, development and civil application of an autonomous, unmanned helicopter.
Unmanned Vehicle Systems International.
www.uvs-international.org.
[USI04]
USICO. Workshop on Collision Avoidance and ATC/ATM Integration, Braumschweig, February 2004. www.usico.org.

Laboratoire d`Optimisation Globale SDER/ENAC

Transcription

Documents pareils

Fiche syst`eme d`assainissement 2014 St

Les Plus Beaux Intérieurs Lustre Pampille en cristal de Bohême

TP 1 : Mesure du nombre d`Avogadro

Fiche syst`eme d`assainissement 2014 CETTE EYGUN (EYGUN

en direct de la shf

Tre Bicchieri Gambero Rosso Tre Bicchieri Gambero Rosso DRO IT d

Rider 3 personnes - Baam Productions

NUDITÉ, CORPS ET « FIGURE » L`exemple

Mooc qui peut (Mooc qui veut)