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) - patrick.monassier@free.fr

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