1 informatique industrielle formation cesi ingénieur génie Électrique patrick monassier année...
TRANSCRIPT
1
Informatique Industrielle
Formation CESIIngénieur Génie Électrique
Patrick MONASSIER Année 2009
2
OBJECTIFS :
• Savoir appréhender la problématique spécifique des systèmes dits « réactifs » par rapport aux systèmes classiques « interactifs, transactionnels »• Connaître tous les services nécessaires à un système informatique connecté à un processus industriel
CONTENU :
• Rappel sur les architectures matérielles simples : répartition des actions logicielles à effectuer sur le ou les processeurs• Les architectures tolérant les fautes : redondance des actions logicielles ou du matériel• Le principe de la programmation synchrone et asynchrone• L’ordonnancement et les concepts de priorités des actions logicielles• Les interruptions matérielles , les évènements et le temps
DUREE : 7 heures
FORME : Cours magistral illustré par des exemples de problématiques industrielles
Module Informatique Industrielle
3
La façon dont va se dérouler le cours
C’est un cours magistral illustré par des exemples de problématiques industrielles exprimées à l’aide de plusieurs mises en applications vécues. Ces exemples permettent d’introduire des parties de cours théoriques sur la programmation des systèmes informatique industriels et de présenter des applications ayant trouvé des prolongements pratiques dans des domaines variés.
1. Introduction sur l’informatique industrielle
2. Application de sécurité d’anticollision sur grues
3. Supervisions et IHM en lien avec des robots industriels
4. Systèmes embarqués pour le transport routier (GPS, WIFI, GPRS)
Ces exemples sont issus de cas réels développés et mis en œuvre par l’intervenant
4
Présentation de l’intervenant
Activités professionnelles :
Directeur Recherche Développement 2007 - actuel • Systèmes embarqués pour véhicules, poids lourds et bus
Direction Informatique Industrielle 2001-2007 • Ingénierie robotique, Informatique de production, vision
Ingénieur d’affaires 1998-2001 • Applications informatiques pour les hôpitaux et l’industrie pharmaceutique
Directeur technique 1992-1998 • Systèmes de sécurité informatiques embarqués : grues, grues mobiles
Support commercial Avant-vente 1989-1992 • Systèmes et réseaux sur sites industriels et en embarqué
Ingénieur projets industriels 1986-1989 • Création de systèmes temps réel et réseaux
Ingénieur d’études1981-1986 • Développement de robots pour la maintenance nucléaire, en milieux irradiés
Patrick Monassier (CPE Lyon) - [email protected]
Télécharger les cours sur: http://patrick.monassier.free.fr
Associations :
• Vice-président de l’Association des Ingénieurs CPE Lyon• Administrateur à l’URIS Rhône-Alpes (Union Régionale des Ingénieurs et Scientifiques – CNISF Conseil National des Ingénieurs et Scientifiques de France)• Gérant de la Maison des Ingénieurs de Lyon
Cours :
Université Lyon 1CPE LyonCNAMINSAT de TUNISCESI
5
Introduction aux systèmes
Informatiques Industriels
Partie 1 - Introduction
6
Les applications
Il y a une explosion du nombre des applications : Il y en a partout ! On met de plus en plus de microprocesseurs et de microcontrôleurs dans toutes sortes de machines et d’appareils, pour l’industrie, pour des besoins en communication, des applications grand public...etc.
Cette explosion est principalement due à l’augmentation de la puissance des microprocesseurs et de leurs circuits périphériques, la diminution du coût des composants, l’internationalisation des besoins. Les applications sont de plus en plus variées……
Des applications de plus en plus «étranges» et de plus en plus cachées
• Transport : avions, bateaux, trains, transport routier, automobiles, motos, fauteuils pour handicapés, ascenseurs…• Médical : Imagerie médicale, robots d’analyse, opérations assistées, scanners…• Nucléaire : contrôle des centrales, sécurité• Multimédia : musique, films, connaissance, documentations• Portage : grues, grues mobiles, transpalettes• Usines : production automatisée, production robotisée• Traçabilité : géolocalisation, suivi de production… etc.
Des applications de plus en plus puissantes et de plus en plus communicantes
7
L’évolution du matériel (hard)
Quelques dates, quelques références…
- 1970 Les ordinateurs tiennent dans de grandes salles climatisées 1 à 6 M€- 1980 L’apparition des mini-ordinateurs 15 k€- 1983 L’apparition des premiers microprocesseurs industriels - 1985 L’apparition du PC, 15 k€, 100.000 Transistors, 10MHz- 2000 PC multimédia 10.000.000 transistors 1GHz 1,5 k€- 2010 PC mobiles 250 €
On avait des puces, il faut maintenant s’attendre à l’arrivée des pucerons
Des millions de petites puces partout qui changeront le monde
Rappel de la loi de Moore - Un des fondateurs d’Intel
La puissance des microprocesseur double tous les 18 mois
Cela reste vrai, on a pas encore trouvé les limites…
Mais qu’en est-il du logiciel qui va animer ce matériel ?
8
Ma définition du logicielC’est un très très très long texte écrit dans un langage
plutôt ennuyeux dans lequel chaque détail compte
« Quand nous avons commencé à programmer nos ordinateurs, nous avons trouvé à notre grande surprise qu’il était beaucoup plus difficile d’avoir des programmes qui marchent que ce que nous avions pensé . Il fallait que nous inventions le debugging. Je peux me souvenir du moment exact où je me suis aperçu qu’une grande partie de ma vie allait être consacrée à trouver des erreurs dans mes propres programmes »
Vous feriez vous opérer en toute confiance par un robot chirurgien ?
Le hard exécute stupidement, parfaitement et très rapidement toute une succession d’opérations primaires dictées par le logiciel.
Imaginez vous faire marcher une entreprise de 10 000 employés parfaitement stupides, et parfaitement obéissant. Sans une seule délégation de pouvoir et sans un brin de réflexion aux différents niveaux d’exécution…. ? Est-ce qui arrive avec le logiciel ?
Sur le logiciel : Quelques thèmes de réflexion …
9
Un logiciel a besoins de logiciels pour être créé, émulé et pour fonctionner
Le logiciel : un objet intellectuel très lourd
Le code source
DriversBibliothèques
LangageCompilateur
Outil de développement
Cible
firmwareSystème d’exploitation
Des milliers de lignes de code
Code source
Gestion des versions
L’exécutable
1 mètre d’épaisseur
de listing
1 mètre d’épaisseur
de listing
10.000 € 15.000 € Entre 1 mètre de listing à 10.000€ et 1 mètre de listing à 15.000 €….lequel choisissez vous ?
Une question… au hasard…
10
Vision industrielle :• Une conduite de projet rigoureuse• Outillages techniques impeccables (simulation, visualisation…)• Juste évaluation des coûts• Programmation défensive
Approche Scientifique :• Mieux comprendre l’objet logiciel• Faire des outils à valeur ajoutée• S’appuyer sur des modèles mathématiques appropriés
Dans l’idéal : Expliquer formellement pourquoi le logiciel marche !
Prendre le logiciel au sérieux
• Difficile à réaliser dans des contextes industriels concurrentiels• Primordial dans des applications critiques
L’Airbus A380 a entièrement conçu, réalisé, simulé à l’aide d’ordinateurs et de logiciels spécifiques
Il ne serait venu à l’idée de personne qu’à son premier vol, il ne décolle pas !
Réaction d’un des ingénieurs après le premier vol : « L’avion s’est comporté presque aussi bien que ce que nous avions prévu »
11
On peut considérer globalement que la fiabilité des microprocesseur et des circuits électroniques en temps que tels est devenue excellente.
Il n’empêche ! Nous devons prendre des précautions !!!
• Dans les phases de conception et de choix technologiques• Dans le choix des approvisionnements et des solutions• Dans la prise en compte des environnements de fonctionnement• Dans l’évaluation de la fatigue et du vieillissement des composantes du système• Dans tous les échanges entre les capteurs, les actionneurs et le système…….etc…etc…etc…
Certains domaines d’applications exigent le respects de normes et de règles : ferroviaire, avionique, nucléaire, automobile …
Ce n’est pas le cas de toutes les applications industrielles …
Agressions sur le hard : Températures haute et basses, vibrations, chocs, salinité, perturbations électromagnétiques, connectique, humaines, composants
Et le hard dans tout ça ?
Logiciel Matérielhard
CapteursActionneurs
Communication
Système Environnement d’application
12
Communiquer en IHM ou en M2M n’est pas une aussi simple qu’on le pense en première approche :
Il faut adapter la communication à l’application.Il n’y a pas de solution standardIl faut aussi adapter en fonction de l’environnement Il faut faire les bons choix face aux contraintes temporellesSi tout marche bien en labo, il est à parier que des problèmes arriveront dans l’environnement industriel si certaines précautions n’ont pas été prises.
Problèmes de communication : IHM : Mauvaise acceptation du système, interface non adaptée, erreurs d’interprétation, interfaces non protégées….M2M : agressions extérieures (Perturbations électromagnétiques, connectique), communication adaptée, perturbations du réseau, ruptures de communication…
IHM : Interface Homme MachineM2M : Machine To Machine – Communication entre systèmes
Et la communication ?
Logiciel Matérielhard
CapteursActionneurs
Communication
Système Environnement d’application
13
Pour une majorité d’applications industrielles, les systèmes sont maintenant de plus en plus enfouis. Il y a de moins en moins d’interface humaine : quelque fois réduite à son minimum, voir complètement absente. Le système agit caché : on ne voit physiquement que le résultat de sa décision…
Ceci amène à prendre en compte d’une façon importante l’évaluation des risques et la gestion de la sécurité. Ceci dépend évidemment de l’environnement de fonctionnement du système : toutes les applications ne sont pas soumises aux mêmes contraintes.
Il y a une grande différence entre le problème de l’impression d’un document informatique et un système ABS qui « oublie » de freiner, ou un régulateur de vitesse qui se bloque !
Le BUG !
On ne doit pas avoir une vision limitative du bug (ou bogue) et considérer que cela vient uniquement du logiciel. Dans une vision industrielle, on doit prendre en compte toutes les composantes de l’application finale comme nous l’avons vu précédemment : logiciel, hard, système, capteurs/actionneurs, communication, environnement, erreurs d’évaluations… etc.
On doit considérer le risque en termes de Sûreté, de Sécurité et Disponibilité…• Sûreté : rien de mal ne peut arriver• Sécurité : il n’y aura pas d’accident grave• Disponibilité : le système sera toujours disponible
Le risque industriel
14
Windows…. LOL
Ariane V : évolution de Ariane IV vers ArianeV (plus puissante). On récupère une partie des calculateurs électroniques. Sur un des calculateurs de trajectoire, alors que la fusée approche de la fin de son lancement, vers la puissance maxi, il y a dépassement de capacité d’un registre de calcul. La fusée quitte la trajectoire et doit être détruite. Le calculateur était parfaitement adapté aux paramètres d’Ariane IV. On n’a pas suffisamment vérifié son adaptation à un environnement moteur plus puissant…
Mars Polar Lander : La sone tombe en panne sur Mars. Il y a inversion de priorités des tâches dans le noyau temps réel : les tâches les plus prioritaire sont masquées par les tâches les moins prioritaires. Grâce à la fonction Debug restée intégrée anormalement au programme, on a pu à distance reprogrammer le gestionnaire de taches.
USS Yorktown : Un des fleuron de la marine américaine, un bateau dernière génération reste bloqué pendant six heures en pleine mer parce qu’un opérateur a entré une valeur 0.0 au lieu de 1.0 en paramètre, entraînant une erreur de division par 0 et des réactions en chaînes de mises en sécurité.
Microprocesseur Pentium : Un erreur dans une opération de division cachée à l’intérieur du microprocesseur entraîne une reprise des composants.Le coût a été estimé à 475 M$ soit plus que le coût du développement de ce microprocesseur.
Therac 25 : Un appui sur la touche TAB du clavier, accompagné d’une séquence particulière, envoie une dose d’irradiations maximum au patient cancéreux, pendant un court instant.
Le Bug soft est reproductible à l’infini dans les mêmes conditions de séquences. Il ne s’agit pas uniquement d’un enchaînement de circonstances non reproductible. L’accident de l’avion Concorde en est un exemple : l’accident arrive suite à choc avec une pièce tombée d’un autre avion sur la piste. Le risque de reproduire un accident identique à partir des mêmes causes est pratiquement nul.
Quelques exemples de bugs
15
Il est difficile de découvrir certains bugs bien cachés au fond des programmes.
Il y a beaucoup d’interactions et on a beaucoup de mal à conceptualiser ce qui se passe
Il y a le problème des Bug mais aussi des divergences d’applications
Difficultés à trouver les bugs
Raison 1 : • SSII : Le client ne sait pas ce qu’il veut mais on va lui faire quand même. • Je corrigerai bien l’erreur mais je n’ai plus les sources
Raison 2 (plus sérieuses) : Difficulté à trouver des bugs :
• Invisible : pas d’inspection visuelle • Programmes très gros : Compréhension globale difficile• Programmes discontinu : pas de marge de sécurité • Plein d’interactions : Comportements combinatoires• Pas d’auto-correction : tous les détails comptent• Interface Homme-Machine : 2 logiques différentes• ……
Il faut un homme pour faire une erreurIl faut un ordinateur pour faire un désastre
Éviter les bugs… c’est DUR, très DUR !
16
Rappel - CONTENU :
• Les architectures tolérant les fautes : redondance des actions logicielles ou du matériel
Fin de partie 1 - Think-Tank
Carte électroniqueLogiciel embarqué
Système embarqué
Communication
Capteurs et actionneurs
Think Tank :
En groupe, une réflexion sur tout ce qui peut amener des dysfonctionnements graves dans un système de sécurité informatique industriel. On part sur la base d’un système embarqué relié à des capteurs et à des actionneurs, communiquant par réseau avec d’autres systèmes équivalents.Le système possède une interface humaine simplifiée.
Oula ! Grave là ! … Ca ressemble à un bug ça !!!!
IHM simple
17
Application de sécurité d’anticollision sur grues
Partie 2 – Application de sécurité
18
D'OU CA VIENT ?Il convient de rappeler l'existence d'un décret daté du 23 août 1947 qui définit les précautions à observer par les utilisateurs de grues de chantiers.
Dans les années 1970/1980 certains chantiers comme les chantiers de construction de centrales nucléaires sur lesquels on dénombre souvent 30 grues et plus enregistrent des accidents graves voire mortels.
Historique
Au début des années 80 apparaissent les premiers dispositifs d'aide à la conduite, essentiellement basés sur de l'électronique analogique.
Le 07/07/1987, en France une circulaire du ministère des affaires sociales et de l’emploi pose les conditions générales d'utilisation des grues à tour dont les zones d'actions se recoupent.
C'est à la fin des années 80, suite aux progrès importants réalisés en électronique numérique qu'apparaissent les premiers systèmes à microprocesseurs qui permettront l'essor des systèmes ANTI-COLLISION.
Les progrès techniques accomplis et l'expérience acquise depuis la circulaire de 07/87 entraînent le législateur à publier la note technique du 06061991qui apporte les précisions nécessaires ou indispensables pour tous.
19
Les risques d'accidents - collisions - survols de zones
On cherche à éviter les collisions entre le câble qui porte la charge et la structure d’une grue adverse Le risque est de déséquilibrer la charge et de provoquer un accident au solIl n’y a aucun risque de chute d’une grue lors de ce type de collisionOn cherche aussi à éviter le survol de zone sensibles (cour d’école, voie ferrée, route) par une charge
XCharge
20
TRANSLATION
DISTRIBUTION
ORIENTATION
GRUES - Les Mouvements
Grue haute
Grue basse
Grue haute
Charge
21
GRUES - Interférences et survol de zone
X
X
XSurvol de zone InterférenceORIENTATION
TRANSLATION
DISTRIBUTIONInterférence
Chantier : Vue de dessus
On veut gérer jusqu’à 16 grues sur une distance de 2000 mètres
22
GRUES - Interférences et survol de zone
ORIENTATION
Le système doit être dynamique et aider le conducteur de la grue àmieux piloter : si le système est uniquement sécuritaire, il ne sera pasaccepté par l’opérateur. Une interface humaine est nécessaire.
Référentiel chantier X
Y
0
Calculs par vectorisation dynamique tenant compte des inerties et des vitessesAnticipation des collisions (IHM : flèches vertes, orange, rouge)Connaissance des positions entre grues rafraîchies toutes les 300ms
23
Chantier : Vue en coupe
Sol chantier =0
Translation
Longueur flèche Longueur
contre-flèche
hauteur
Point 0 de recalage
Inertie Rotation : à pleine charge
24
Rappel - CONTENU :
• Rappel sur les architectures matérielles simples : répartition des actions logicielles à effectuer sur le ou les processeurs
Application grues : Think-Tank N°1
Carte électroniqueLogiciel embarqué
Système embarqué
Communication
Capteurs et actionneurs
Think Tank :
Imaginer une architecture matérielle et surtout logicielle apte à répondre à l’application Anticollision de grues. Prendre le problème dans son ensembleNe pas chercher à rentrer dans le détail pour l’instant.
IHM simple
25
18
4
3
liaison Radio
Bus de terrainJusqu’à 16 gruesDistance totale 2000 mètres maxi
Architecture générale de l’installation1Quelle architecture générale ?Où mettre le ou les systèmes ?Comment assurer l’échange des données ?
26
TRANSLATION
DISTRIBUTION
ORIENTATION
Réseau interne
Réseau inter-grues
Système
Capteurs
Actionneurs
Légende
Implanter le système et relier les capteurs2
Où mettre le système ?Comment relier les capteurs et actionneurs ?Comment échanger les données ?
27
Architecture du système3
Comment architecturer le système ?Quelles cartes mettre ?Présentation physique du système ?
Carte CPU
Carte E/S
Carte Communication
Interface humaine
Autres systèmes
Traitements
Capteurs/actionneurs grue
Grutier
28
Organisation logicielle4
Comment organiser le logiciel ?Comment assurer le Déterminisme de la communication ?Comment déléguer les tâches ?Temps de cycle ?
Microprocesseur
Carte E/S
Microcontrôleur réseau
Afficheur, manettes grue
Bus de Terrain
Traitements anti-collision
Prise d’informations, décision physique
Information, action
Après calcul et essais, il a été décidé de prendre un temps de cycle de 300 ms, répétable à l’infini
29
Synchronisation
Traitements de survol de zone et d’interférence
Pilotage desactionneursde la grueLocale et affichage au grutier
Temps d’attente
Temps de cycle : 300 ms
Position desautres grues
(Réseau Inter-grues)
Organisation du temps5
Comment organiser le cycle de 300 ms ?Comment être sûr de pouvoir faire le traitement dans les 300 ms ?
Lecture des capteurs dela gruelocale
Acquisition Traitement Résultat
1 2 3 4
30
Synchronisation
Organisation du temps6
Comment organiser le cycle de 300 ms ?Comment être sûr de pouvoir faire le traitement dans les 300 ms ?
Acquisition Traitement Résultat
1 2 3 4
Réseau
CPU
E/S
31
Carte Entrées/Sorties – Afficheur, manettes grutier
Synchronisation
Communication : échange des données entre les 16 grues – 300ms
Tâches imparties à chaque carte7
Comment répartir les tâches ?Comment optimiser le temps ?
Acquisition Traitement Résultat
1 2 3 4
Réseau
CPU
E/S
Réseau
CPU
E/S
(1)
(1) Récupérer les position es autres grues mais envoyer aussi vers le autres grues ses propres positions
32Temps de cycle : 300 ms
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Temps de cycle divisé par 16 : 300ms / 16 = 18,75 ms
- Orientation:......12 bits- Distribution:..... 12 bits- Translation:..... 12 bits
1 2 3 4 5 octetsInformations à transmettre:
- N° de la grue:.. 4 bits
attente
Communication réseau7Comment échanger les données entre grues ?Quelles données échanger ?Comment respecter le temps (déterminisme) ?
33
Début de trame
Identifieur Commande C.R.C. Fin de trame Données
Espace intertrame
1 12 6 40 15 10 3 bits de données
47 bits
18,75 ms maximum imposé
18.75ms / 87 bits = 0.21ms par bit => 1 / 0.21ms = 4,64Kb/s
à 20 Kbits / s => facteur 4
Trame Bus de Terrain8Comment transporter les données par un bus de terrain ?Comment tenir compte des contraintes temporelles et des distances ?
Exemple : Réseau CAN (Controlled Area Network)
Voir le Diaporama « CAN » de l’intervenantPrincipes et fonctionnement du réseau CAN
34
- Orientation:......12 bits- Distribution:..... 12 bits- Translation:..... 12 bits
1 2 3 4 5 Informations à transmettre:
- N° de la grue:.. 4 bits
Début de trame
Identifieur Commande C.R.C. Fin de trame Données
Espace intertrame
18,75 ms maximum
Trame Bus de Terrain
3510 100 1000 10 000 mètres
1600
1000
100
10
5
Débit Kbits / s
Longueur du réseau (mètres)
Valeur maximale du protocole CAN
20 Kbit / s
4000 m
GRUES - Distances en fonction de la vitesse de transmission (réseau CAN)
Bus de Terrain9Quelle vitesse choisir pour les échanges des données ?S’assurer de la compatibilité du réseau, un exemple avec la distanceTenir compte aussi de la topologie…
36
Protocole constructeur: Support filaire RS485 à 9,6 Kb/s - Protocole et trames constructeur
Protocole FIP: Support filaire à 1Mb/s - Protocole FIP simplifié - Trames FIP
Protocole CAN: Support filaire à 20 Kb/s - Protocole et trames CAN
N° Grue 4 bits Données 40 bits C.R.C. 8 bits
52 bits
5,4 ms
100 bits
100 uS
87 bits
4,35 ms
Autres réseaux10 Peut-on prendre un autre réseau que CAN ?
37
DriverRS 485
Driver FIPTransformateur
Driver CAN
80C250
Contrôleur FIP
FIPART
Contrôleur CAN
82527 Intel Philips
Microprocesseur
Microprocesseur
Microprocesseur
Constructeur
FIP
Fil
Fil
Fil
Modèle ISO ..... Couche 7 Application..........Couche 2 liaison..... Couche 1 Physique
CAN
Autres réseaux Peut-on prendre un autre réseau que CAN ?
Et le modèle ISO en 7 couches ?
38
+5V= +5V= Isolé
2 OptoHCPL7101
Driver CAN
82C250
Contrôleur CAN
Intel 82527
uP
Couche 1 PhysiqueCouche 2 liaisonCouche 7 Application
Filtres
Carte réseau11Protéger la carte réseauIsolation galvanique
Que peut-il arriver sur le réseau ?
39
Application grues : Think-Tank N°2
Think Tank :
Au vu de l’architecture que nous avons choisi,Imaginer tout ce que nous pouvons mettre en place pour assurer la sécurité de l’application.
Tenir compte de sécurités matérielles et logicielles, de l’architecture et du choix des composants des différentes cartes électroniques.
Attention : nous sommes dans un cas où en cas de collision, de survol de zone interdite, il peut y avoir des conséquences graves : décès de personnel par chute d’échafaudage par exemple si la charge est déséquilibrée soudainement , collision de la charge avec un train si on survole une voie ferré, chute de charge pendant le survol d’une cour d’école….
40
La Sécurité : Une vue de points à prendre en compte12
Capteurs : Glissement des capteurs, rupture mécanique, rupture de câbles, information altérée…Solutions : Doubler les capteurs, comparer les valeurs entre eux, vérifier en dynamique les écarts de valeurs soudaines, détecter les ruptures de câbles, vérifier la cohérence des données…
Actionneurs : l’info n’est pas relayée, la carte Sortie n’est plus disponible, rupture de la communication avec la carte Entrées/Sorties, Mise en sécurité de la grue en cas d’incident.Solutions : Relire l’information de sortie et la comparer (relais de sécurité), détecter la non communication de la carte E/S, Mettre les sorties en sécurité en cas d’incident : piloter les relais en coupure en cas de problème
Réseau : détecter une rupture de réseau, vérifier la cohérence des valeurs, se mettre en sécurité en cas de problème, réagir face à un réseau fonctionnant de façon aléatoire, vérifier que les données sont bien rafraîchies quand il le faut (cycle de 300 ms). Gérer les cas normaux d’allumage et d’extinction d’une système adverseSolutions : Vérifier la bonne prise en compte des données d’un nouveau système qui vient d’être monté. Vérifier que les données sont bien rafraîchies, vérifier les valeurs limites des données, vérifier leur évolution temporelle. Mettre la grue en sécurité en cas de coupure réseau. Mettre en sécurité la grue face à un système adverse qui vient d’être coupé, rallumé ou nouvellement inséré.
41
La Sécurité : Une vue de points à prendre en compte13
Carte CPU hard : défaut d’un composant périphérique (RAM, EPROM, FLASH, RTC…)Solutions : Vérifier la disponibilité des composants, Vérifier la cohérence et la disponibilité des données, doubler les données écrites en RAM et vérifier en lecture, mettre en place des CRC sur les programme et la Flash, vérifier périodiquement les mécanismes de sécurité
Carte CPU Soft : défaut de déroulement du programme, perturbations du microprocesseur…Solutions : Mettre en place des signatures de traçabilité – passage par des chemins de traitements logiciels cohérents et complets. Vérifier la périodicité des traitements (timers, Watch-dog). Vérifier la cohérence des ordres de sorties.
En final : peut-on assurer la sécurité avec un seul système ? Dans certains domaines (avionique par exemple) on triple les systèmes : Ce principe de doublement ou triplement des systèmes consiste à effectuer un traitement similaire à partir de mêmes valeurs d’entrées et de comparer à chaque fois les résultats obtenus entre systèmes. Si les résultats sont différents, on put supposer un problème : dans ce cas, il faut arbitrer sur la décision à prendre
ATTENTION : Dans une architecture à double ou triple système, les hard et les logiciels doivent être différents !! En effet, si un bug soft arrive par exemple, il se produira au même endroit et au même moment sur chaque système s’ils sont similaires : ça ne sert donc à rien ! En mettant en parallèle des hard et des softs différents, effectuant les même taches, on a la garantie qu’un bug soft ou hard ne se répétera pas au même moment sur les deux ou sur les trois systèmes …
42
FIN de Présentation
Patrick MONASSIERCESI 2009