Informatique Industrielle Formation CESI Ingénieur Génie Électrique Année 2009 Patrick MONASSIER

Module Informatique Industrielle 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

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. Introduction sur l’informatique industrielle Application de sécurité d’anticollision sur grues Supervisions et IHM en lien avec des robots industriels 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

Présentation de l’intervenant Patrick Monassier (CPE Lyon) - patrick.monassier@free.fr Télécharger les cours sur: http://patrick.monassier.free.fr 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 Cours : Université Lyon 1 CPE Lyon CNAM INSAT de TUNIS CESI 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

Introduction aux systèmes Informatiques Industriels Partie 1 - Introduction Introduction aux systèmes Informatiques Industriels

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

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 ?

Sur le logiciel : Quelques thèmes de réflexion … Ma définition du logiciel C’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 ?

Le logiciel : un objet intellectuel très lourd Un logiciel a besoins de logiciels pour être créé, émulé et pour fonctionner Code source Le code source Outil de développement Des milliers de lignes de code Compilateur Langage Bibliothèques Drivers Gestion des versions firmware Système d’exploitation L’exécutable Cible Une question… au hasard… 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 ?

Prendre le logiciel au sérieux 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 ! 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 »

Et le hard dans tout ça ? 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 Capteurs Actionneurs Communication Matériel hard Environnement d’application Logiciel Système

Et la communication ? 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 standard Il faut aussi adapter en fonction de l’environnement Il faut faire les bons choix face aux contraintes temporelles Si 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 Machine M2M : Machine To Machine – Communication entre systèmes Capteurs Actionneurs Communication Matériel hard Environnement d’application Logiciel Système

Le risque industriel Le BUG ! 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

Quelques exemples de bugs 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.

Éviter les bugs… c’est DUR, très DUR ! 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 erreur Il faut un ordinateur pour faire un désastre

Fin de partie 1 - Think-Tank Rappel - CONTENU : Les architectures tolérant les fautes : redondance des actions logicielles ou du matériel 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 !!!! Capteurs et actionneurs Communication Carte électronique Logiciel embarqué Système embarqué IHM simple

Partie 2 – Application de sécurité Application de sécurité d’anticollision sur grues

Historique 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. 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.

X Les risques d'accidents - collisions - survols de zones Charge X 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 sol Il n’y a aucun risque de chute d’une grue lors de ce type de collision On cherche aussi à éviter le survol de zone sensibles (cour d’école, voie ferrée, route) par une charge

GRUES - Les Mouvements ORIENTATION DISTRIBUTION TRANSLATION Grue haute Grue basse Charge TRANSLATION

X X X Interférence Survol de zone Interférence GRUES - Interférences et survol de zone TRANSLATION Chantier : Vue de dessus ORIENTATION X Interférence Survol de zone X X Interférence DISTRIBUTION On veut gérer jusqu’à 16 grues sur une distance de 2000 mètres

GRUES - Interférences et survol de zone 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 pas accepté par l’opérateur. Une interface humaine est nécessaire. Y ORIENTATION Calculs par vectorisation dynamique tenant compte des inerties et des vitesses Anticipation des collisions (IHM : flèches vertes, orange, rouge) Connaissance des positions entre grues rafraîchies toutes les 300ms Référentiel chantier X

Longueur contre-flèche Chantier : Vue en coupe Inertie Rotation : à pleine charge Longueur contre-flèche Longueur flèche hauteur Sol chantier =0 Translation Point 0 de recalage

Application grues : Think-Tank N°1 Rappel - CONTENU : Rappel sur les architectures matérielles simples : répartition des actions logicielles à effectuer sur le ou les processeurs Think Tank : Imaginer une architecture matérielle et surtout logicielle apte à répondre à l’application Anticollision de grues. Prendre le problème dans son ensemble Ne pas chercher à rentrer dans le détail pour l’instant. Capteurs et actionneurs Communication Carte électronique Logiciel embarqué Système embarqué IHM simple

3 8 1 4 1 Architecture générale de l’installation Quelle architecture générale ? Où mettre le ou les systèmes ? Comment assurer l’échange des données ? liaison Radio 8 1 4 Jusqu’à 16 grues Distance totale 2000 mètres maxi Bus de terrain

2 Implanter le système et relier les capteurs Légende Réseau interne ORIENTATION Où mettre le système ? Comment relier les capteurs et actionneurs ? Comment échanger les données ? DISTRIBUTION Légende Réseau interne Réseau inter-grues Système Capteurs TRANSLATION Actionneurs

Capteurs/actionneurs grue 3 Architecture du système Comment architecturer le système ? Quelles cartes mettre ? Présentation physique du système ? Carte Communication Autres systèmes Carte CPU Traitements Carte E/S Capteurs/actionneurs grue Interface humaine Grutier

4 Organisation logicielle Comment organiser le logiciel ? Comment assurer le Déterminisme de la communication ? Comment déléguer les tâches ? Temps de cycle ? Microcontrôleur réseau Bus de Terrain Microprocesseur Traitements anti-collision Carte E/S Prise d’informations, décision physique Afficheur, manettes grue 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

5 Organisation du temps 1 2 3 4 Acquisition Traitement Résultat Comment organiser le cycle de 300 ms ? Comment être sûr de pouvoir faire le traitement dans les 300 ms ? 1 2 3 4 Acquisition Traitement Résultat Synchronisation Lecture des capteurs de la grue locale Traitements de survol de zone et d’interférence Pilotage des actionneurs de la grue Locale et affichage au grutier Temps d’attente Position des autres grues (Réseau Inter-grues) Temps de cycle : 300 ms

6 Organisation du temps 1 2 3 4 Acquisition Traitement Résultat Comment organiser le cycle de 300 ms ? Comment être sûr de pouvoir faire le traitement dans les 300 ms ? 1 2 3 4 Acquisition Traitement Résultat Synchronisation Réseau CPU E/S

7 Tâches imparties à chaque carte 1 2 3 4 Acquisition Traitement Comment répartir les tâches ? Comment optimiser le temps ? 1 2 3 4 Acquisition Traitement Résultat Synchronisation CPU (1) Communication : échange des données entre les 16 grues – 300ms Réseau Carte Entrées/Sorties – Afficheur, manettes grutier E/S Réseau (1) Récupérer les position es autres grues mais envoyer aussi vers le autres grues ses propres positions CPU E/S

7 Communication réseau 1 2 3 4 5 octets Informations à transmettre: Comment échanger les données entre grues ? Quelles données échanger ? Comment respecter le temps (déterminisme) ? 7 Communication réseau 1 2 3 4 5 octets Informations à transmettre: - N° de la grue:.. 4 bits - Orientation:...... 12 bits - Distribution:..... 12 bits - Translation:..... 12 bits Temps de cycle divisé par 16 : 300ms / 16 = 18,75 ms 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 attente Temps de cycle : 300 ms

8 18,75 ms maximum imposé Données Trame Bus de Terrain Comment transporter les données par un bus de terrain ? Comment tenir compte des contraintes temporelles et des distances ? 8 Trame Bus de Terrain Exemple : Réseau CAN (Controlled Area Network) 18,75 ms maximum imposé Début de trame Espace intertrame Données Identifieur Commande C.R.C. Fin de trame 1 12 6 40 15 10 3 bits de données 47 bits Voir le Diaporama « CAN » de l’intervenant Principes et fonctionnement du réseau CAN 18.75ms / 87 bits = 0.21ms par bit => 1 / 0.21ms = 4,64Kb/s à 20 Kbits / s => facteur 4

Données Trame Bus de Terrain 18,75 ms maximum 1 2 3 4 5 Début de trame Espace intertrame Données Identifieur Commande C.R.C. Fin de trame 1 2 3 4 5 Informations à transmettre: - N° de la grue:.. 4 bits - Orientation:...... 12 bits - Distribution:..... 12 bits - Translation:..... 12 bits

9 Bus de Terrain Débit Kbits / s Quelle vitesse choisir pour les échanges des données ? S’assurer de la compatibilité du réseau, un exemple avec la distance Tenir compte aussi de la topologie… 9 Bus de Terrain Débit Kbits / s GRUES - Distances en fonction de la vitesse de transmission (réseau CAN) 1600 1000 100 10 5 Valeur maximale du protocole CAN 20 Kbit / s 4000 m 10 100 1000 10 000 mètres Longueur du réseau (mètres)

10 Autres réseaux Peut-on prendre un autre réseau que CAN ? Protocole constructeur: Support filaire RS485 à 9,6 Kb/s - Protocole et trames constructeur N° Grue 4 bits Données 40 bits C.R.C. 8 bits 52 bits 5,4 ms Protocole FIP: Support filaire à 1Mb/s - Protocole FIP simplifié - Trames FIP 100 bits 100 uS Protocole CAN: Support filaire à 20 Kb/s - Protocole et trames CAN 87 bits 4,35 ms

Autres réseaux Peut-on prendre un autre réseau que CAN ? Et le modèle ISO en 7 couches ? Microprocesseur Driver RS 485 Fil Constructeur Microprocesseur Driver FIP Transformateur Contrôleur FIP Fil FIP FIPART Microprocesseur Contrôleur CAN Driver CAN Fil CAN 80C250 82527 Intel Philips Modèle ISO ..... Couche 7 Application..........Couche 2 liaison..... Couche 1 Physique

Que peut-il arriver sur le réseau ? 11 Protéger la carte réseau Isolation galvanique Carte réseau Que peut-il arriver sur le réseau ? +5V= +5V= Isolé Contrôleur CAN Intel 82527 Driver CAN uP 82C250 Filtres 2 Opto HCPL7101 Couche 2 liaison Couche 1 Physique Couche 7 Application

Application grues : Think-Tank N°2 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….

12 La Sécurité : Une vue de points à prendre en compte 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 adverse Solutions : 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é.

13 La Sécurité : Une vue de points à prendre en compte 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 …

FIN de Présentation Patrick MONASSIER CESI 2009