[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov. 2011

Modèle Qualité pour lautomatisme Conception sûre des applications de contrôle-commande Mardi 22 novembre 2011Thierry COQ Denis CHALONthierry.coq@dnv.com denis.chalon@automationsquare.com 1System and Software Reliability Directeur techniquePrincipal consultant

Contenu Le logiciel – appréhension ou appréhension La qualité logicielle en informatique Application à lautomatisme Cas réel – Audit DNV Etude de ladéquation des seuils du modèle Qualité à lautomatisme Conclusions 2 Tous droits réservés

Le logiciel est partout Applications toujours plus complexes  Plus de variables, plus dE/S, plus de traitements  Applications réparties sur plusieurs automates Remplacement de fonctions matérielles par des fonctions logicielles (plus flexibles, moins chères) Total Integration: Drilling Le développement est principalement sous-traité BACK-UP PLANT SYSTEM NETWORK SAFETY SYSTEM WIND SENSORS Réutilisation de bibliothèques EMERGENCY SHUTDOWN PROCESS CONTROL STATION FIRE & GAS déjà développées VRU GYRO INFORMATION MANAGEMENT REMOTE DIAGNOSTIC INTEGRATED THRUSTER CONTROL SYSTEM - DYNAMIC POSITIONING - POSMOOR - AUTOSAIL CONTROL - OPERATOR CONTROL NETWORK SYSTEM INTEGRATED MONITORING & CONTROL SYSTEM - EXTENSION ALARM - PROCESS CONTROL PROPULSION AZIPOD DRILLING DRIVE FIELDBUS SYSTEM NETWORK ENERGY MANAGEMENT SYSTEM POWER GENERATION & DISTRIBUTION 3 Tous droits réservés

Lappréhension du logiciel Où sont les logiciels, comment est gérée leur intégrité sur leur durée de vie ? Quelle est la qualité délivrée par nos fournisseurs développeurs ? Comment peut-on sassurer que les fournisseurs sont qualifiés ? Quelles sont les causes des erreurs logicielles? Comment peut-on avoir confiance dans les corrections logicielles dans la suite du projet ? Durant lexploitation ? Comment prévenir les décalages de délais dans les phases de réception et le développement des projets? 4 Tous droits réservés

Les intervenants autour du logiciel Client Méthodes Chef de projet Automaticien Métiers différents Environnement et outils spécifiques très différents Peu de connaissances partagées Le logiciel est plus difficile à appréhender que la mécanique, lélectricité,... Niveau de détail requis par rapport au logiciel14mm 120mm 400mm 5 Tous droits réservés

Échanges, outils et perception liés au logiciel Client PLC 1 PLC 2 PLC 3 Méthodes PLC 4 PLC 5 PLC 6 ? PLCToujours en panne, 9 7 PLC 8 PLC maintenance se plaint performances moyennes Illisible, pas de tests, en retard ? ? Pas fini, compliqué, important... Vite, vite. Déjà fait avant copier/coller... 400mm fixeChef de projet Automaticien 6 Tous droits réservés

Besoin de rendre visible le logiciel Toujours en panne, Client maintenance se plaint performances moyennes Vite, vite. copier/coller... Méthodes Le logiciel doit devenir mesurable : Illisible, pas de tests, en retardChef de projet - objectivement - de façon répétable Et la mesure doit être partagée par tous les intervenants Automaticien Pas fini, compliqué, important... 7 Tous droits réservés

Qualité logicielle en informatique Que font les informaticiens pour « donner de la visibilité au logiciel » ? Comment définit-on la qualité dun logiciel ? Comment peut-on la mesurer ? Est-ce que la mesure a réellement un sens ? Les codes dont la qualité mesurée est bonne sont-ils réellement de bonne qualité ? 8 Tous droits réservés

Bref historique de la qualité logicielle 1970s – Théorie formalisé par Mac Cabe 1980s - Outils disponibles utilisés (ex : logiscope) 1990s - Gros efforts dutilisation pour la maîtrise du risque (logiciel critique) 2000s - Démocratisation des méthodes de suivi de la qualité et de leur coût:  Automatisation de la génération des données depuis le code source  Simplification de lutilisation des outils de qualimétrie (plus besoin de spécialiste)  IHM graphiques ergonomiques et adaptées aux différents intervenants  Standardisation des concepts (ISO9126) Une science est aussi mature que ses outils de mesure (Louis Pasteur) 9 Tous droits réservés

Principe de fonctionnement dun modèle qualité en informatique ergonomie Fiabilité opérationnelle Coût de maintenance fonctionnalités Taux de détection de bug performance EXTERNAL CMMI Gestion des exceptions ISO9126 couplage réutilisabilité architecture INTERNAL fiabilité testabilité évolutivité Tolérance aux fautes efficacité maintenabilité lisibilité compréhensibilité Complexité du code 10 Tous droits réservés

Flot dun suivi Qualité Tableaux de bord Client Méthodes Décide Suit 4 3 Opération automatique Modèle danalyse Sonde logicielle Opération automatique Contrôle 2 Code Résultats de la sonde sourceChef de projet 2 Corrige Développeur 1 11 Atelier de Développe développement

Modèle Qualité Client Méthodes Ratio de commentaire Pas de GOTO RéutilisabilitéChef de projet Compréhensibilité … Maintenabilité Lisibilité Efficacité Evolutivité Automaticien Fiabilité Testabilité Sous-carac- Points de mesure Attributs des programmes téristique et de vérification 12 Tous droits réservés

Modèle danalyseLa fonction fctn_vannesa 67 lignes de code Mesure 1 Mesure 2 Modèle Attribut 1 Le programme a une bonne testabilité Mesure 3 danalyse Attribut 2 ... Attribut 3 Mesure NLa variable cbfe_34 Attribut 4na pas de commentaire Vérification 1 Attribut 5 Vérification 2 ... ... Attribut N Vérification N 13 Tous droits réservés

Caractéristiques de la méthode SQALE La méthode SQALE prend en compte tout le cycle de vie du logiciel y compris la maintenance, la rénovation et la réutilisation. Les caractéristiques du programme sont hiérarchisées : − Qui voudra réutiliser un programme non fiable? − Qui peut démontrer la fiabilité dun programme non testable? Le résultat est un indice de remédiation pragmatique : − Combien ça coûte pour avoir un programme de qualité à partir de la situation actuelle − Les problèmes à résoudre ne sont comptés quune seule fois sur lattribut le plus prioritaire − Il ny a pas de compromis à subir entre caractéristiques − Par quoi commencer en premier. SQALE est indépendante dun langage, et dune technologie particulières. − Les résultats sont directement comparables dun programme à lautre SQALE est applicable directement contrairement à lISO9126 qui demande dêtre interprétée et dont les ambiguïtés doivent être résolues. SQALE est automatisable et automatisée, économique à mettre en œuvre. Elle est standardisée. 14 http://www.sqale.org/ Tous droits réservés

Application à lautomatisme Quelle sonde logicielle utiliser ? - multi-automate - 5 langages de lIEC-61131 Quel modèle qualité prendre ? - transposition des modèles qualité de linformatique traditionnelle - spécificités du domaine Quels outils pour les intervenants ? - comment intégrer avec les outils des différents métiers - comment gérer lexternalisation des développements 15 Tous droits réservés

Lautomaticien et le logiciel Client Problèmes solutionnés :  Rendre objectif lévaluation non fonctionnelle du programme Méthodes  Rétro-action positive sur les habitudes de programmation  Obtenir une vision plus large du logicielChef de projet que la simple application sur laquelle le développeur travaille. Automaticien 17 Tous droits réservés

Le chef de projet et le logiciel Client Problèmes solutionnés :  Suivre la qualité  Suivre lavancement du projet Le tableau de bord permet Méthodes  Benchmarking une navigation depuis la vision globale jusquau détailChef de projet 80-400mm Il permet également un Automaticien suivi temporel de lavancement du projet 18 Tous droits réservés

Les méthodes et le logiciel Client Problèmes solutionnés :  Prise en compte de lexistant  Vérification adéquation entre Méthodes spécifications et code  Formalisation et partage des méthodes de développement 24-120mm  Indicateurs logiciels transversesChef de projet Automaticien 19 Tous droits réservés

Le client final et le logiciel Client Problèmes solutionnés :  Simplification de la prise de décision sur les moyens à affecter en fonction Méthodes dune vue objective.  Corrélation possible avec dautres sources dinformations disponibles dans lusineChef de projet PLC 1 PLC 2 PLC 3 PLC 4 PLC 5 PLC 6 Automaticien 10-24mm PLC 7 PLC 8 PLC 9 20 Tous droits réservés

Audit code automate Besoin : maîtrise des risques Client : DNV Malmö Suède Fonction : Automate en charge de la commande de la tour de pose sur un bateau Automate : RSLogix 5000 Sonde : PLC Checker Méthode : SQALE Image non représentative du bateau en question 22 Tous droits réservés

Audit de code : le besoin Objectifs:  Identification des risques principaux liés au logiciel Périmètre:  Logiciel du contrôle commande de la tour de pose  Fiabilité, maintenabilité et sureté de fonctionnement de la tour Actions: revue de code manuelle et automatisée  Analyse du fonctionnel de lapplicatif logiciel  Analyse des processus de développement − Spécifications, conception, codage, tests unitaires, dintégration et de recette  Analyse de la qualité interne de lapplication logiciel : SQALE 23 Tous droits réservés

Audit de code: analyse SQALE Code LADDER, environ 7000 code locations Chiffres dindex normalisés Problèmes les plus fréquents:  Testabilité: variables écrites à plusieurs endroits, code mort, complexité importante, code dans des commentaires  Fiabilité: variables lues avant dêtre écrites  Maintenabilité: code non commenté 24 Tous droits réservés

Audit de code: résultats Cohérents avec autres résultats SQALE pour dautres langages Satisfaisants meilleurs que la moyenne des résultats observés Cohérents avec analyse de code manuelle et vérification des « top ten » Encore des difficultés avec les outils à résoudre  Interactions du calculateur avec linterface homme-machine  Copier/coller de code pas encore détecté Appréciation finale de la Suède: « The SQALE analysis provided a very valuable complement to the manual part of the software review »... « While the manual review focused on thoroughly checking selects parts of the code, the SQALE analysis measured defined quality characteristics of the complete code » 25 Tous droits réservés

Comment valider que les seuils du modèle Qualité sont adaptés à lautomatisme? Pourquoi un modèle qualité informatique conviendrait aux langages de lIEC ? Comment assurer la corrélation entre les résultats et la réalité ressentie ? 26 Tous droits réservés

Étude de lexistant Formalisation des mesures à effectuer sur les programmes Constitution dune base de programme client  Pas de programmes de test  Multi-automates (PL7 Pro, Unity Pro, Step7, RS5000) Exécution de la sonde (PLC Checker) sur chaque programme avec les mesures formalisées Analyse des résultats  Résultat par automate  Résultats tout automates confondus  Définition de classes dacceptation 27 Tous droits réservés

Quelques chiffres ~25 mesures ~300 codes PLC S7, Unity Pro, PL7 et RSLogix5000, ~180 000 POUs, ~2 500 000 instructions ~2 000 000 variables 55h de calcul Les résultats : 112MB de données brutes à exploiter 28 Tous droits réservés

Définition des seuilsLe modèle Qualité nest pas élitiste, il doit correspondre à lusage réel. 50% : A 75% : A ou B 90% : A, B ou C Critère dacceptation 95% : A, B, C ou D 97,5% : A, B, C, D ou E 99% : A, B, C, D, E ou F 29 Tous droits réservés

Nombre de lignes de codeAPPLICATION UNITE DE PROGRAMMATION Pas de critères de qualité sur cette dimension, juste une information  Sassurer que chaque unité de Applications jusquà 60 000 lignes de code programme a une taille raisonnable 50% < 10 000 lignes  90% des POU ont une taille inférieure à 100 lignes de code  Le seuil est comparable à ce qui est préconisé en informatique 30 Tous droits réservés

Complexité des codes  Les programmes sont-ils faciles à comprendre ?  Deux complexités différentes : complexité cyclomatique, complexité essentielle  Dans les deux cas, les seuils sont en ligne avec les seuils vus enCritère dacceptation informatique :  eV(G) < 5  V(G) < 15 => Les automaticiens programment déjà correctement pour la plupart. Attention la complexité cyclomatique nest pas dispo en tant que telle sur Critère dacceptation tous les langages (limitations sur langages graphiques : SFC, FBD et LD). 31 Tous droits réservés

Niveau de commentaire des codes  Les applications sont-elles bien commentées ?  Nom des éléments du programme : − 50% ont 85% de commentaires − 75% ont 70% de commentaires − 90% ont 60% de commentaires  Vérification sur les tailles de commentaires  Densité de commentaire dans le code : − 50% ont 67% de commentaires − 75% ont 57% de commentaires Critère dacceptation − 90% ont 52% de commentaires 32 Tous droits réservés

Résultats Peu de dispersion en fonction des automates sur les mesures très générales, => donc les programmes automates sont comparables entre eux indépendamment de leur fonctionnalité Les seuils de complexité pratiqués en informatique sont applicables en automatisme avec les restrictions suivantes :  Adaptations nécessaires pour les langages graphiques (SFC, Contact et FBD)  Seuils de détection pour le Copier/Coller  Prise en compte de mauvaises pratiques pour étoffer les mesures 33 Tous droits réservés

A retenir Les découvertes tardives de bugs et de non-qualité sont coûteuses. Le suivi de la qualité au cours du cycle de vie y remédie :  La démocratisation du suivi qualité − Tableaux de bord qui permettent navigation entre synthèse et détail − La génération des données peut se faire semi-automatiquement voire automatiquement − Implémentation de lISO 9126  Les méthodes et outils existent, sont applicables et sont adaptés à lautomatisme − Support multi-automate A lattention des industriels − Support les langages de lIEC-61131 et intégrateurs − Outils et méthodes disponibles Invitation pour participer au perfectionnement dun modèle qualité adapté à lautomatisme. Recherche industriels et intégrateurs motivés Merci de contacter souhaitant participer au perfectionnement dun modèle DNV ou IAS qualité adapté à lautomatisme. 35 Tous droits réservés

En savoir plus... Qualité logicielle sur Wikipédia - http://fr.wikipedia.org/wiki/Qualité_logicielle Site de SQALE - http://www.sqale.org/ Der Norske Veritas - http://www.dnv.com/ Itris Automation Square – http://www.automationsquare.com/fr/plc-checker.html SQUORING - http://www.squoring.com/ Inspearit - http://www.inspearit.com/en/Denis CHALON Thierry COQ36denis.chalon@automationsquare.com thierry.coq@dnv.com Tous droits réservésDirecteur technique Principal consultant

http://leblogdesqsf-s.blogspot.com	86
http://leblogdesqsf-s.blogspot.fr	36
http://a0.twimg.com	2
http://leblogdesqsf-o.blogspot.com	2

[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov. 2011

by Itris Automation Square on Nov 23, 2011

Accessibility

Tags

Upload Details

Usage Rights

4 Embeds 126

Statistics

[FR] Presentation Club Automation "Modele Qualite pour l’automatisme" 22 nov. 2011 — Presentation Transcript