Inginiérie


Les systèmes embarqués représentent plus de 95 % du marché des microprocesseurs.

Bien sûr il faut y enlever les gadgets hi tech fabriqués en grande série, sur le continent asiatique.

Mais depuis longtemps, le militaire, le spatial , l’aéronautique, qui intégraient de l’électronique sont passés aux systèmes informatiques embarqués.

Puis d’autres domaines ont suivi : la commande numérique de machines outil, la robotique, l’automobile et d’autres domaines, jusqu ‘à la gestion technique des batiments.

  • La conception des circuits imprimés et la connectique plus le cablage..ces derniers étant une norme du format STEP. La CAO y a pris une place de plus importante.

    Pour l’anecdote, le retard d’ Airbus est du à des câbles trop courts, sur les éléments livrés par les allemands, parce qu’ils n’ont pas voulu changer leur logiciel de conception de cablage, largement dépassé, bien qu ‘ils aient été avertis au départ, mais ça pressait… Reformer leurs techniciens à un nouveau logiciel, qui plus est, français Catia. Une erreur que ne commettrait pas un BTS en CAO débutant…

  • L’inginiérie des systèmes embarqués

    C’est un secteur en pleine évolution, qui recrute au niveau ingénieur.

    Aujourd’hui il y a des écoles spécialisées pour former les ingénieurs pour les systèmes embarqués et temps réel.

    C’est un beau métier parce qu ‘il ne se limite pas à la programmation, il y a souvent la conception du hardware ( lorsqu ‘on ne peut pas choisir dans la gamme de cartes disponibles dans le commerce, qui parfois servent à faire le proptotype ).

    Une partie non négligeable de l’étude est le domaine des capteurs et actionneurs, de plus en plus évolués.

    Pour l’étude d’un système embarqué il faut pouvoir appréhender le processus industriel, que l’on va piloter. ( aviation , chimie, télécom, etc… )

    Le temps réel est aussi très spécifique, l’application étant découpée en tâches, gérées par le scheduleur. L’étude de ce découpage en taches, est primordiale pour le fonctionnement de l’ensemble ( système et processus )

    Il faut également avoir une bonne « culture risques », ces systèmes pilotant des processus industriels généralement à risques : chimie, nucléaire, etc…qui doivent être pris en compte dans le projet.

    Dans de nombreux domaines, il y a des normes à respecter. 

    Mais il y a également tous les risques liés au système informatique : panne de capteurs, de composants, et bugs logiciels : là aussi il y a des normes;, et parfois une certification. Un bug pouvant avoir des conséquences catastrophiques, les programmes sont testés de façon beaucoup plus complète.

    Les systèmes informatiques disposent d’une gestion de la qualité particulière.

    La qualité des systèmes informatiques intègre au projet de développement une approche permettant de contrôler autant que possible le produit final.

    Elle concerne :

    * la qualité des processus de réalisation ;

    * la qualité des processus d’ingénierie des systèmes, notamment mis en œuvre par le génie logiciel, que l’on nomme également sûreté de fonctionnement des systèmes informatiques (une application particulière de la sûreté de fonctionnement).

    Les normes , ne sont pas là pour contraindre, mais pour aider.. Bien sur il y a des abus administratifs ( exemple la norme de récupération des eaux pluviales, qui se sont renforcées avec la grippe aviaire ), mais généralement elles découlent de travaux d’experts des domaines concernés après des analyses d’incidents…

    Il faut les voir plus comme un support que comme un contrainte. Essayez de définir la démarche qualité pour la réalisation d’un système sans y faire référence.

    Elles ont l’avantage qu ‘on parle tous le même langage, depuis le fabricant de capteurs et de matériels, jusqu ‘à la maintenace..

    Quand j’ai commencé dans les années 70, il n’ y avait pas de normes !

    Enfin si une seule : si on vait cassé pour 100 MF de matériel et causé autant en pertes de production, on pouvait tous rentrer chez nous..

    Et ce n’était pas la peine d’aller démarcher d’autres clients. Les premières expériences se seraient arrétées.

    C’était des installations prototypes, mais les équipes projets étaient plus étoffées, elles regroupaient des gens d’expériences diverses. Même les anciens sytèmes d’automatismes, prenaient en compte les risques. Les cahiers des charges étaient bien faits et il y avait toujours une recette contractuelle ( avec des pénalités )

    Le volet maintenance ( un état de vie du projet ) doit également être pris en compte, il peut apporter son lot de risques, avec l’absence de procédures.

    A chaque étape du projet il faut une validation par un tiers qui a gardé ses capacités de critique et son indépendance.

    La norme aviation prévoit avec la certification , un nombre de lignes, par homme et par moins , bien inférieure aux SI. Mais c’est la moyenne globale sur la période qui va depuis le début de l’étude, jusqu à la livraison :

    The DO-178B certification process is so time- and labor-intensive that vendors may experience an output of just 125 lines of code per man-month.

    d’où l’intéret d’utiliser un OS certifié, même si ça ne rentre pas dans les exigences d’un autre domaine.

    On ne demande pas de taper du code plus vite que son ombre, on demande que le résultat soit parfait.. Le codage c’est peu par rapport à l’ensemble de l’étude..

    Source : http://www.lynuxworks.com/rtos/rtos-178.php

    Un exemple d ‘une société d’inginiérie et de ses méthodes de travail..

    SERMA Inginiérie.

    http://www.serma-ingenierie.com/index.php?option=com_content&view=article&id=2&Itemid=28

    Serma Technologies

    http://www.serma-technologies.com/fr/

    IDMOS ( une branche de SERMA ) développe des circuits intégrés spécifiques. lorsqu ‘il est nécessaire de miniaturiser et que ces circuits n’existent pas dans le commerce. C’est aussi un aspect du développement de l’informatique.

    On appelle ça des « fabless » : elles confient la fabrication de leurs chips à des fondeurs.

    http://www.id-mos.com/Pages/fr_tool_n_method.htm

    Sûreté de fonctionnement des logiciels..

    Source : le site de SERMA.

    LOGICIELS

    Expertise Software

    La Sûreté de Fonctionnement des logiciels intégrés dans un système complexe dépend quasi exclusivement de la complétude de la définition des besoins, de la conception, des Tests Unitaires, d’Intégration et de la validation dans le système.

    Nous proposons un ensemble de méthodes pour :

    * Spécifier les exigences de Sûreté de Fonctionnement du logiciel,
    * Mettre en œuvre les tests du logiciel,
    * Auditer le processus de développement du logiciel,
    * Détecter l’impact des dysfonctionnements du logiciel sur le système

    Une erreur bénigne dans un module enfoui dans le logiciel, une mauvaise interprétation des besoins fonctionnels du système, une interface erronée du logiciel avec son environnement, peuvent entraîner des risques nuisant gravement à la Sécurité Fonctionnelle du système. C’est pourquoi notre métier est de mettre en œuvre les Techniques d’Évaluation de Vérification et de Validation de la Sûreté de Fonctionnement du logiciel pour :

  • Contrôler la complétude du code d’un logiciel (LCC),
  • Vérifier la couverture des tests du logiciel,
  • Analyser l’impact des modifications du logiciel,
  • Analyser les Modes de Défaillance du logiciel et leurs Effets sur le système (AMDE, AEEL),
  • Prouver formellement un logiciel,
  • .

    SPECIFIER

    Aider le Maître d’Ouvrage d’un système logiciel qui doit satisfaire à des critères de sûreté de fonctionnement (Fiabilité, Maintenabilité, Disponibilité, Sécurité), à :
    Sélectionner les exigences les plus pertinentes compte tenu du type de système, de la criticité des fonctions de ce système, du référentiel normatif applicable,
    Exprimer les exigences de sûreté du logiciel (produit, processus) devant figurer dans le Cahier des Charges ou la Spécification technique,
    Préparer l’analyse des réponses des constructeurs à ces exigences.

    ANALYSER

    « Analyser les modes de défaillance et leurs effets »

    Lors de la mise en œuvre de systèmes dont certaines fonctions critiques (en terme de FMDS) sont portées par du logiciel, cette méthode permet au Maître d’Ouvrage et au Maître d’Oeuvre d’identifier les défaillances du logiciel pouvant aboutir aux « Événements Redoutés » du système, mais aussi d’évaluer l’architecture du logiciel vis-à-vis de la Sûreté de Fonctionnement et de la tolérance aux fautes.
    Elle permet également à l’Évaluateur/Certificateur d’identifier, de façon indépendante, les risques résiduels des fonctions logicielles susceptibles d’aboutir à l’occurrence d’Événements Redoutés sur le système.

    Les AMDE du logiciel s’appuient sur une analyse fonctionnelle formalisée établie à partir d’éléments tels que :

  • la Spécification Technique des Besoins du Logiciel (STBL),
  • le Document d’Architecture Logiciel (DAL) ou Document de Conception Préliminaire (DCP),
  • le Document de Conception Détaillée (DCD),
  • le Code du logiciel
  • Le comportement fonctionnel est déterminé à partir du code source à l’aide de nos outils APRLS® et AGFL® qui fournissent l’architecture du logiciel jusqu’aux chemins fonctionnels des composants logiciels.

    AUDITER

    L’objectif de l’audit des processus de développement du logiciel est de fournir au Maître d’Ouvrage une confirmation objective de la conformité des processus de développement de l’entité auditée (Maître d’Œuvre, Fournisseurs, Sous-Traitants,…) vis-à-vis des exigences définies par l’état de l’art et les règlements normatifs (CEI61508-3, CENELEC 50128, CEI 880, DO 178B,…)

    La conformité des processus aux normes de la Sûreté de Fonctionnement est évaluée au travers :

    * du Cycle de vie du logiciel,
    * de la Spécifications des prescriptions du logiciel,
    * de la Conception et du développement du logiciel
    * du V&V (Vérification et Validation) du logiciel,
    * de la planification et de la documentation du logiciel,
    * de l’organisation des équipes (Responsabilités, indépendance des équipes, circuits d’informations,…),
    * de la gestion de projet (planning, revues, gestion de configuration, gestion des modifications, mesures de la qualité,…).

    Nous utilisons son outil Audit_SdF® de checklists des exigences de la norme à évaluer. Une métrique est évaluée pour chacun de ces thèmes en fonction de critères d’importance adaptés au contexte des processus audités.

    TESTER

    Fournir au Maître d’Œuvre les moyens, méthodes, outils pour faire réaliser, par une équipe indépendante, les Tests Unitaires, d’Intégration (logiciel/logiciel, logiciel/matériel), de Validation des logiciels intégrés dans le système dont il a la charge. Réaliser les plans et dossiers de Tests Unitaires, d’Intégration et de Validation. Établir le dossier justificatif de vérification des tests effectués vis-à-vis des exigences de couverture du référentiel normatif applicable au projet.

    VERIFIER

    Aider le maître d’ouvrage, l’exploitant ou l’évaluateur d’un système comportant du logiciel, à vérifier la couverture fonctionnelle des Tests Unitaires, d’Intégration et de Validation et leur complétude vis-à-vis des exigences de sûreté.

    Identifier, par utilisation de l’outil AGFL® (Analyse par Graphe Fonctionnel du Logiciel), les scénarios de tests fonctionnels, de robustesse, de tolérance aux fautes et de tests par injection de fautes, qui doivent compléter les dossiers de tests pour aboutir à une couverture de type « classe d’équivalence ».

    « Classe d’équivalence » : La partition du domaine d’entrée d’un programme, de telle sorte qu’un test utilisant une valeur représentative d’une classe est équivalent à un test utilisant une autre valeur de cette classe. (Source : norme DO 178 B).

    CRITIQUER

    La Lecture Critique de Code permet au Maître d’Oeuvre d’un système logiciel devant satisfaire à des exigences de qualité et de Sûreté de Fonctionnement de contrôler l’application des règles de l’état de l’art en matière de qualité et de sûreté du code des logiciels (C, ADA, Modula2, Assembleurs) comme par exemple :

    * les constructions peu sûres (switch case sans clause default, code mort, …),

    * les anomalies du flot de contrôle (récursivité, sorties multiples de composant, …),

    * les anomalies du flot de données (mémoires/sorties non rafraîchies sur un chemin d’exécution,

    * relation d’ordre sur les entrées erronée sur un chemin d’exécution, variable globale entre traitements parallèles, entrées non initialisées, variables non utilisées, …),

    * les anomalies du flot de dépendance des données (effets de bord des composants appelés, …),

    * la conformité des chemins fonctionnels du code aux spécifications du logiciel (STBL, DAL),

    * la traçabilité du code à ses exigences de conception (DCP, DCD).

    L’ensemble de ces contrôles est réalisé à l’aide de nos outils AGFL® et APRLS® appliqués sur le code.

    VALIDER

    La méthode de Validation Formelle de la spécification permet au Maître d’Ouvrage ou au Maître d’Œuvre d’avoir au plus tôt l’assurance de la complétude et de la cohérence des fonctionnalités portées par le logiciel décrites dans les spécifications du logiciel. Cette assurance est apportée par l’établissement du modèle formel de ces fonctionnalités et la démonstration sous forme de preuves mathématiques du respect des propriétés de sûreté des fonctions du logiciel dans le système. (Cette démarche est « Hautement Recommandée » (HR) pour les logiciels de niveau SIL 4 dans la norme CEI 61508).

    Normes, Methodes et Outils :

    DO178-B : pour le logiciel

    http://fr.wikipedia.org/wiki/DO-178B

    DO 254 pour le matériel électronique

    http://fr.wikipedia.org/wiki/DO-254

    CEI 61508

    iec 61508

    http://www.iec.ch/functionalsafety/explained/

    http://www.surete-fonctionnement.clearsy.com/2008/12/la-norme-cei-61508-et-ses-derives/

    La norme CEI 61508 et ses dérivés

    * La norme CEI 61511, créée en 2003, est la norme adaptée de la norme CEI 61508 pour les procédés industriels.

    * La norme CEI 61513, créée en 2001, est la norme adaptée de la norme CEI 61508 pour le secteur du nucléaire.

    iec nuke

    http://www.pdftop.com/ebook/iec+61513/

    IEC 6513 Réseaux de Communications ( exemples et classifications )

    http://www.pdftop.com/view/aHR0cDovL3d3dy5ucmMuZ292L3JlYWRpbmctcm0vZG9jLWNvbGxlY3Rpb25zL251cmVncy9jb250cmFjdC9jcjY5OTEvY3I2OTkxLnBkZg==

    http://docs.google.com/viewer?url=http://www.sea.siemens.com/us/SiteCollectionDocuments/WSSResources/Internet/Products/ProcessSafetyARC_09.pdf&chrome=true

    * La norme CEI 62061, créée en 2005, est la norme adaptée de la norme CEI 61508 pour la sécurité des machines.

    * Les normes EN 50126/EN 50128/EN 50129, créées respectivement pour les dernières versions, en 1999/2001/2003, sont des normes adaptées de la norme CEI 61508 pour le secteur du ferroviaire.

    * La norme ISO 26262 est en cours de réalisation et sa sortie est prévue pour 2009. Celle-ci est l’adaptation de la norme CEI 61508 pour le secteur de l’automobile.

    http://www.worldlingo.com/ma/enwiki/fr/Safety_Integrity_Level

    APR : Analyse Préliminaire des Risques

    http://fr.wikipedia.org/wiki/Analyse_pr%C3%A9liminaire_des_risques

    AMDEC : Analyse des Modes de Défaillance et de leur Criticité

    http://fr.wikipedia.org/wiki/AMDEC

    HAZOP : HAZard and OPerability study

    http://en.wikipedia.org/wiki/Hazop

    AEEL : Analyse des Effets et des Erreurs des Logiciels

    http://igm.univ-mlv.fr/~dr/XPOSE2002/AMDEC/M%E9thode_AEEL.htm

    STBL : Specification Technique des Besoins Logiciels


    http://www.infeig.unige.ch/support/se/lect/spec/rqmt/web.html


    ALARP

    ALARP stands pour « aussi bas que raisonnablement faisable« , et est une limite employée souvent dans le milieu de sûreté-critique et systèmes à haut niveau d’intégration. Principe d’ALARP est ce le risque résiduel sera aussi bas que raisonnablement faisable.

    http://www.worldlingo.com/ma/enwiki/fr/ALARP

    Autre exemple société Altec :

    Management des risques – Optimisation des processus

  • APR
  • AMDEC
  • AEEL
  • HAZOP
  • Arbres de Défaillances
  • Diagrammes de Fiabilité
  • Diagrammes d’États / Réseaux de Pétri
  • Calculs prévisionnels FMDS
  • Robustesse et tolérance aux fautes
  • Management des risques – Optimisation des processus

  • Risques industriels
  • Risques environnementaux
  • Risques technologiques
  • Risques programmes
  • Une autre société d’inginiérie spécialisée : Fiatec ( Valence – Drôme )

    L’étude de risques concerne d’autres métiers que l’electronique et l’informatique embarquée, et automatismes industriels.

    Des boites comme Fiatec sont capables de regrouper toutes les compétences pour étudier un projet informatique industriel, connaissant bien chaque domaine d’application, mais aussi les risque de l’automatisation, et peut proposer ses services à des PME, qui n’ont pas les moyens de payer des spécialistes de chaque domaine..

    http://www.fiateq.com/index.php?id_rub=2

    C’est devenu incontournable aujourd’hui et il y a de nombreuses offres d’emplois qualifiés.

    http://www.fiateq.com/index.php?id_rub=7

    C’est aussi un domaine, où malgré l’évolution rapide des technologies on capitalise davantage son expérience et on est pas balayés en même temps que les technologies deviennent obsolètes.

    C’est aussi un des domaines de l’informatique les mieux payés, et qui offre pas mal d’évolution. Qui offre des CDI et très rarement des CDD. Domaine un peu délaissé par les informaticiens purs et durs qui n’ont pas les bases de connaissances complémentaires requises..

    Une petite entreprise qui ne connait pas la crise.

    ca exemple

    http://www.iso-ingenierie.eu/

    Il manque encore deux choses pour compléter ce paragraphe de l’inginiérie :

    l’évaluation : qui permet d’évaluer les performances du processeur à utiliser pour faire fonctionner l’application ( ça concerne plus les domaines comme l’automobile où le coût du processeur est important lorsque le système est diffusé en grande série )

    L’INRIA , mais aussi le CNRS font des études dans le domaine du temps réel, pour s’assurer du bon fonctionnement de l’application, et vérifier que la durée d’éxécution des taches ne conduira pas à un blocage, dans certaines situations de surcharge, parfois difficiles à estimer ou à simuler..

    et il manque aussi les outils de simulation.

    Logiciels :

    http://www.knowllence.com/fr/produits/tdc_need.php

    http://www.lihoutech.com/hazop.htm

    Publicités
    Cet article a été publié dans Histoire de l'informatique. Ajoutez ce permalien à vos favoris.

    Laisser un commentaire

    Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

    Logo WordPress.com

    Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

    Image Twitter

    Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

    Photo Facebook

    Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

    Photo Google+

    Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

    Connexion à %s