La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "1 Informatique Industrielle Formation CESI Ingénieur Génie Électrique Patrick MONASSIER Année 2009."— Transcription de la présentation:

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

2 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 Lordonnancement 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 3 La façon dont va se dérouler le cours Cest un cours magistral illustré par des exemples de problématiques industrielles exprimées à laide de plusieurs mises en applications vécues. Ces exemples permettent dintroduire 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 linformatique industrielle 2. Application de sécurité danticollision 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 lintervenant

4 4 Présentation de lintervenant Activités professionnelles : Directeur Recherche Développement actuel Systèmes embarqués pour véhicules, poids lourds et bus Direction Informatique Industrielle Ingénierie robotique, Informatique de production, vision Ingénieur daffaires Applications informatiques pour les hôpitaux et lindustrie pharmaceutique Directeur technique Systèmes de sécurité informatiques embarqués : grues, grues mobiles Support commercial Avant-vente Systèmes et réseaux sur sites industriels et en embarqué Ingénieur projets industriels Création de systèmes temps réel et réseaux Ingénieur détudes Développement de robots pour la maintenance nucléaire, en milieux irradiés Patrick Monassier (CPE Lyon) - Télécharger les cours sur: Associations : Vice-président de lAssociation des Ingénieurs CPE Lyon Administrateur à lURIS 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 1 CPE Lyon CNAM INSAT de TUNIS CESI

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

6 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 dappareils, pour lindustrie, pour des besoins en communication, des applications grand public...etc. Cette explosion est principalement due à laugmentation de la puissance des microprocesseurs et de leurs circuits périphériques, la diminution du coût des composants, linternationalisation 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 danalyse, 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 7 Lévolution du matériel (hard) Quelques dates, quelques références… Les ordinateurs tiennent dans de grandes salles climatisées 1 à 6 M Lapparition des mini-ordinateurs 15 k Lapparition des premiers microprocesseurs industriels Lapparition du PC, 15 k, Transistors, 10MHz PC multimédia transistors 1GHz 1,5 k PC mobiles 250 On avait des puces, il faut maintenant sattendre à larrivée des pucerons Des millions de petites puces partout qui changeront le monde Rappel de la loi de Moore - Un des fondateurs dIntel La puissance des microprocesseur double tous les 18 mois Cela reste vrai, on a pas encore trouvé les limites… Mais quen est-il du logiciel qui va animer ce matériel ?

8 8 Ma définition du logiciel Cest 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 quil était beaucoup plus difficile davoir 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 quune 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 dopérations primaires dictées par le logiciel. Imaginez vous faire marcher une entreprise de 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 dexécution…. ? Est-ce qui arrive avec le logiciel ? Sur le logiciel : Quelques thèmes de réflexion …

9 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 firmware Système dexploitation Des milliers de lignes de code Code source Gestion des versions Lexécutable 1 mètre dépaisseur de listing Entre 1 mètre de listing à et 1 mètre de listing à …. lequel choisissez vous ? Une question… au hasard…

10 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 lobjet logiciel Faire des outils à valeur ajoutée Sappuyer sur des modèles mathématiques appropriés Dans lidé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 LAirbus A380 a entièrement conçu, réalisé, simulé à laide dordinateurs et de logiciels spécifiques Il ne serait venu à lidée de personne quà son premier vol, il ne décolle pas ! Réaction dun des ingénieurs après le premier vol : « Lavion sest comporté presque aussi bien que ce que nous avions prévu »

11 11 On peut considérer globalement que la fiabilité des microprocesseur et des circuits électroniques en temps que tels est devenue excellente. Il nempê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 dapplications exigent le respects de normes et de règles : ferroviaire, avionique, nucléaire, automobile … Ce nest 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ériel hard Capteurs Actionneurs Communication Système Environnement dapplication

12 12 Communiquer en IHM ou en M2M nest pas une aussi simple quon le pense en première approche : Il faut adapter la communication à lapplication. Il ny a pas de solution standard Il faut aussi adapter en fonction de lenvironnement 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 lenvironnement industriel si certaines précautions nont pas été prises. Problèmes de communication : IHM : Mauvaise acceptation du système, interface non adaptée, erreurs dinterpré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 Et la communication ? Logiciel Matériel hard Capteurs Actionneurs Communication Système Environnement dapplication

13 13 Pour une majorité dapplications industrielles, les systèmes sont maintenant de plus en plus enfouis. Il y a de moins en moins dinterface 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 dune façon importante lévaluation des risques et la gestion de la sécurité. Ceci dépend évidemment de lenvironnement 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 limpression dun 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 lapplication finale comme nous lavons 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 ny aura pas daccident grave Disponibilité : le système sera toujours disponible Le risque industriel

14 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é dun registre de calcul. La fusée quitte la trajectoire et doit être détruite. Le calculateur était parfaitement adapté aux paramètres dAriane IV. On na 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 quun 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 à linté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é dune séquence particulière, envoie une dose dirradiations maximum au patient cancéreux, pendant un court instant. Le Bug soft est reproductible à linfini dans les mêmes conditions de séquences. Il ne sagit pas uniquement dun enchaînement de circonstances non reproductible. Laccident de lavion Concorde en est un exemple : laccident arrive suite à choc avec une pièce tombée dun 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 15 Il est difficile de découvrir certains bugs bien cachés au fond des programmes. Il y a beaucoup dinteractions et on a beaucoup de mal à conceptualiser ce qui se passe Il y a le problème des Bug mais aussi des divergences dapplications Difficultés à trouver les bugs Raison 1 : SSII : Le client ne sait pas ce quil veut mais on va lui faire quand même. Je corrigerai bien lerreur mais je nai plus les sources Raison 2 (plus sérieuses) : Difficulté à trouver des bugs : Invisible : pas dinspection visuelle Programmes très gros : Compréhension globale difficile Programmes discontinu : pas de marge de sécurité Plein dinteractions : Comportements combinatoires Pas dauto-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 Éviter les bugs… cest DUR, très DUR !

16 16 Rappel - CONTENU : Les architectures tolérant les fautes : redondance des actions logicielles ou du matériel Fin de partie 1 - Think-Tank Carte électronique Logiciel 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 dun système embarqué relié à des capteurs et à des actionneurs, communiquant par réseau avec dautres systèmes équivalents. Le système possède une interface humaine simplifiée. Oula ! Grave là ! … Ca ressemble à un bug ça !!!! IHM simple

17 17 Application de sécurité danticollision sur grues Partie 2 – Application de sécurité

18 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 lemploi 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 qui apporte les précisions nécessaires ou indispensables pour tous.

19 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 dune grue adverse Le risque est de déséquilibrer la charge et de provoquer un accident au sol Il ny a aucun risque de chute dune 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 X Charge

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

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

22 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 pas accepté par lopérateur. Une interface humaine est nécessaire. Référentiel chantier X Y 0 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

23 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 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 électronique Logiciel embarqué Système embarqué Communication Capteurs et actionneurs Think Tank : Imaginer une architecture matérielle et surtout logicielle apte à répondre à lapplication Anticollision de grues. Prendre le problème dans son ensemble Ne pas chercher à rentrer dans le détail pour linstant. IHM simple

25 liaison Radio Bus de terrainJusquà 16 grues Distance totale 2000 mètres maxi Architecture générale de linstallation 1 Quelle architecture générale ? Où mettre le ou les systèmes ? Comment assurer léchange des données ?

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

27 27 Architecture du système 3 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 28 Organisation logicielle 4 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 dinformations, 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 à linfini

29 29 Synchronisation Traitements de survol de zone et dinterférence Pilotage des actionneurs de la grue Locale et affichage au grutier Temps dattente Temps de cycle : 300 ms Position des autres grues (Réseau Inter-grues) Organisation du temps 5 Comment organiser le cycle de 300 ms ? Comment être sûr de pouvoir faire le traitement dans les 300 ms ? Lecture des capteurs de la grue locale AcquisitionTraitementRésultat

30 30 Synchronisation Organisation du temps 6 Comment organiser le cycle de 300 ms ? Comment être sûr de pouvoir faire le traitement dans les 300 ms ? AcquisitionTraitementRésultat Réseau CPU E/S

31 31 Carte Entrées/Sorties – Afficheur, manettes grutier Synchronisation Communication : échange des données entre les 16 grues – 300ms Tâches imparties à chaque carte 7 Comment répartir les tâches ? Comment optimiser le temps ? AcquisitionTraitementRésultat 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

32 32 Temps de cycle : 300 ms Temps de cycle divisé par 16 : 300ms / 16 = 18,75 ms - Orientation: bits - Distribution: bits - Translation: bits octets Informations à transmettre: - N° de la grue:.. 4 bits attente Communication réseau 7 Comment échanger les données entre grues ? Quelles données échanger ? Comment respecter le temps (déterminisme) ?

33 33 Début de trame Identifieur Commande C.R.C. Fin de trame Données Espace intertrame 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 Terrain 8 Comment 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 lintervenant Principes et fonctionnement du réseau CAN

34 34 - Orientation: bits - Distribution: bits - Translation: bits 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

35 mètres 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 Terrain 9 Quelle vitesse choisir pour les échanges des données ? Sassurer de la compatibilité du réseau, un exemple avec la distance Tenir compte aussi de la topologie…

36 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éseaux 10 Peut-on prendre un autre réseau que CAN ?

37 37 Driver RS 485 Driver FIP Transformateur Driver CAN 80C250 Contrôleur FIP FIPART Contrôleur CAN Intel Philips Microprocesseur Constructeur FIP 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 38 +5V= +5V= Isolé 2 Opto HCPL7101 Driver CAN 82C250 Contrôleur CAN Intel uP Couche 1 Physique Couche 2 liaison Couche 7 Application Filtres Carte réseau 11 Protéger la carte réseau Isolation galvanique Que peut-il arriver sur le réseau ?

39 39 Application grues : Think-Tank N°2 Think Tank : Au vu de larchitecture que nous avons choisi, Imaginer tout ce que nous pouvons mettre en place pour assurer la sécurité de lapplication. Tenir compte de sécurités matérielles et logicielles, de larchitecture 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 dune cour décole….

40 40 La Sécurité : Une vue de points à prendre en compte 12 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 : linfo nest pas relayée, la carte Sortie nest plus disponible, rupture de la communication avec la carte Entrées/Sorties, Mise en sécurité de la grue en cas dincident. Solutions : Relire linformation 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 dincident : 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 dallumage et dextinction dune système adverse Solutions : Vérifier la bonne prise en compte des données dun 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 41 La Sécurité : Une vue de points à prendre en compte 13 Carte CPU hard : défaut dun 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 dentré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 sils 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 quun bug soft ou hard ne se répétera pas au même moment sur les deux ou sur les trois systèmes …

42 42 FIN de Présentation Patrick MONASSIER CESI 2009


Télécharger ppt "1 Informatique Industrielle Formation CESI Ingénieur Génie Électrique Patrick MONASSIER Année 2009."

Présentations similaires


Annonces Google