[fr] presentation club automation "modele qualite pour l'automatisme" 22 nov. 2011
TRANSCRIPT
1
Modèle Qualité pour l'automatisme
Conception sûre des applications de contrôle-commande
Mardi 22 novembre 2011
Thierry [email protected] and Software Reliability
Principal consultant
Denis [email protected]
Directeur technique
2Tous droits réservés
Contenu
Le logiciel – appréhension ou appréhension
La qualité logicielle en informatique
Application à l'automatisme
Cas réel – Audit DNV
Etude de l'adéquation des seuils du modèle Qualité à l'automatisme
Conclusions
3Tous droits réservés
INTEGRATED THRUSTER CONTROL SYSTEM- DYNAMIC POSITIONING- POSMOOR- AUTOSAIL- OPERATOR CONTROL
SYSTEMINTEGRATED MONITORING & CONTROL SYSTEM- EXTENSION ALARM- PROCESS CONTROL
POWER GENERATION& DISTRIBUTION
PROCESS CONTROL STATION
PROPULSION
WIND SENSORS
VRU
GYRO
BACK-UPSYSTEM
SAFETY SYSTEMEMERGENCY SHUTDOWN
FIRE & GAS
ENERGY MANAGEMENTSYSTEM
AZIPOD
INFORMATION MANAGEMENTREMOTE DIAGNOSTIC
DRILLING DRIVESYSTEM
PLANTNETWORK
CONTROLNETWORK
FIELDBUSNETWORK
Total Integration: Drilling
Le logiciel est partout
Applications toujours plus complexes Plus de variables, plus d'E/S, plus de traitements Applications réparties sur plusieurs automates
Remplacement de fonctions matérielles par des fonctions logicielles (plus flexibles, moins chères)
Le développement est principalement sous-traité
Réutilisation de bibliothèquesdéjà développées
4Tous droits réservés
L'appré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 s'assurer 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 l'exploitation ?
Comment prévenir les décalages de délais dans les phases de réception et le développement des projets?
5Tous droits réservés
Méthodes Chef de projet Automaticien
Les intervenants autour du logiciel
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é,...
Client
Niveau de détail requis par rapport au logiciel
400mm120mm14mm
6Tous droits réservés
Méthodes
Chef de projet Automaticien
Échanges, outils et perception liés au logicielClient
400mm fixe
Vite, vite.Déjà fait avant copier/coller...
Illisible, pas de tests, en retard ?
PLC 1 PLC 2 PLC 3
PLC 4 PLC 5 PLC 6
PLC 7 PLC 8 PLC 9Toujours en panne, maintenance se plaint
performances moyennes?
Pas fini, compliqué, important...
?
7Tous droits réservés
Vite, vite. copier/coller...
Pas fini, compliqué, important...
Illisible, pas de tests, en retard
Toujours en panne, maintenance se plaint
performances moyennes
Besoin de rendre visible le logiciel
Méthodes
Chef de projet
Automaticien
Client
Le logiciel doit devenir mesurable :- objectivement- de façon répétable
Et la mesure doit être partagée par tous les intervenants
8Tous 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é d'un 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é ?
9Tous droits réservés
Bref historique de la qualité logicielle
1970's – Théorie formalisé par Mac Cabe
1980's - Outils disponibles utilisés (ex : logiscope)
1990's - Gros efforts d'utilisation pour la maîtrise du risque (logiciel critique)
2000's - 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 l'utilisation 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)
10Tous droits réservés
Principe de fonctionnement d'un modèle qualité en informatique
CMMI ISO9126
Complexité du code
réutilisabilité
testabilité
fiabilité
évolutivité
efficacité
maintenabilité
couplage
Gestion des exceptions
Tolérance aux fautes
compréhensibilité
lisibilité
ergonomie
performance
Fiabilité opérationnelle
fonctionnalités
Taux de détection de bug
Coût de maintenance
architecture INTERNAL
EXTERNAL
11
Méthodes
Développeur
1
Client
DéveloppeAtelier de
développement
2'
Contrôle
Code source
Sonde logicielle
Opération automatique
Résultats de la sondeChef de projet
Tableaux de bord
Opération automatique Modèle d'analyse
Flot d'un suivi Qualité
4
Décide
3
Suit
2 Corrige
12Tous droits réservés
Lisibilité
Compréhensibilité
Testabilité
Fiabilité
Evolutivité
Efficacité
Maintenabilité
Réutilisabilité Pas de GOTO
Ratio de commentaire
…
Attributs des programmesSous-carac-
téristiquePoints de mesureet de vérification
Méthodes
Chef de projet
Automaticien
Client
Modèle Qualité
13Tous droits réservés
Modèle d'analyse
Attribut 1
Attribut 2
Attribut 3
Attribut 4
Attribut 5
Attribut N
Mesure 1
Mesure 2
Mesure 3
Mesure N
Vérification 1
Vérification N
Vérification 2
Modèled'analyse
...
...
...
La fonction fctn_vannes a 67 lignes de code
Le programme a une bonne testabilité
La variable cbfe_34 n'a pas de commentaire
14Tous 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é d'un 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 qu'une seule fois sur l'attribut le plus prioritaire
− Il n'y a pas de compromis à subir entre caractéristiques
− Par quoi commencer en premier.
SQALE est indépendante d'un langage, et d'une technologie particulières.
− Les résultats sont directement comparables d'un programme à l'autre
SQALE est applicable directement contrairement à l'ISO9126 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.
http://www.sqale.org/
15Tous droits réservés
Application à l'automatisme
Quelle sonde logicielle utiliser ?- multi-automate- 5 langages de l'IEC-61131
Quel modèle qualité prendre ?- transposition des modèles qualité de l'informatique 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 l'externalisation des développements
16Tous droits réservés
Ateliers
Sonde logicielle
Modèle qualité
Tableau de bord
Une solution
la boîte noire s'ouvre pour tous les intervenants...
5 Langages IEC
17Tous droits réservés
Méthodes
Chef de projet
Automaticien
L'automaticien et le logicielClient
Problèmes solutionnés :
Rendre objectif l'évaluation non fonctionnelle du programme
Rétro-action positive sur les habitudes de programmation
Obtenir une vision plus large du logiciel que la simple application sur laquelle le développeur travaille.
18Tous droits réservés
Méthodes
Chef de projet
Automaticien
Le chef de projet et le logicielClient
Problèmes solutionnés :
Suivre la qualité
Suivre l'avancement du projet
Benchmarking
Le tableau de bord permetune navigation depuis la vision globale jusqu'au détail
Il permet également un suivi temporel de l'avan-cement du projet
80-400mm
19Tous droits réservés
Méthodes
Chef de projet
Automaticien
Les méthodes et le logicielClient
Problèmes solutionnés :
Prise en compte de l'existant
Vérification adéquation entre spécifications et code
Formalisation et partage des méthodes de développement
Indicateurs logiciels transverses
24-120mm
20Tous droits réservés
Méthodes
Chef de projet
Automaticien
Le client final et le logicielClient
Problèmes solutionnés :
Simplification de la prise de décision sur les moyens à affecter en fonction d'une vue objective.
Corrélation possible avec d'autres sources d'informations disponibles dans l'usine
PLC 1 PLC 2 PLC 3
PLC 4 PLC 5 PLC 6
PLC 7 PLC 8 PLC 9
10-24mm
21Tous droits réservés
Cas réel – Audit DNV
Est-ce utilisable dans la vraie vie ?
Comment cela se met-il en œuvre ?
Quel temps gagné / perdu ?
22Tous 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
23Tous 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 l'applicatif logiciel
Analyse des processus de développement
− Spécifications, conception, codage, tests unitaires, d'intégration et de recette
Analyse de la qualité interne de l'application logiciel : SQALE
24Tous droits réservés
Audit de code: analyse SQALE
Code LADDER, environ 7000 code locations
Chiffres d'index 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é
25Tous droits réservés
Audit de code: résultats
Cohérents avec autres résultats SQALE pour d'autres 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 l'interface 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 »
26Tous droits réservés
Comment valider que les seuils du modèle Qualité sont adaptés à l'automatisme?
Pourquoi un modèle qualité informatique conviendrait aux langages de l'IEC ?
Comment assurer la corrélation entre les résultats et laréalité ressentie ?
27Tous droits réservés
Étude de l'existant
Formalisation des mesures à effectuer sur les programmes
Constitution d'une 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 d'acceptation
28Tous 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
29Tous droits réservés
Définition des seuils
Le modèle Qualité n'est pas élitiste, il doit correspondre à l'usage réel.
50% : A
75% : A ou B
90% : A, B ou C
95% : A, B, C ou D
97,5% : A, B, C, D ou E
99% : A, B, C, D, E ou F
Critère d'acceptation
30Tous droits réservés
Nombre de lignes de code
APPLICATION
Pas de critères de qualité sur cette dimension, juste une information
Applications jusqu'à 60 000 lignes de code
50% < 10 000 lignes
UNITE DE PROGRAMMATION
S'assurer que chaque unité de programme a une taille raisonnable
90% des POU ont une taille inférieure à 100 lignes de code
Le seuil est comparable à ce qui est préconisé en informatique
31Tous 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 en informatique :
eV(G) < 5
V(G) < 15
=> Les automaticiens programment déjà correctement pour la plupart.
Attention la complexité cyclomatique n'est pas dispo en tant que telle sur tous les langages (limitations sur langages graphiques : SFC, FBD et LD).
Critère d'acceptation
Critère d'acceptation
32Tous droits réservés
Niveau de commentaire des codes
Critère d'acceptation
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
− 90% ont 52% de commentaires
33Tous 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
34Tous droits réservés
Conclusion
Comment participer ?
Comment utiliser ?
J'ai un cas d'utilisation, comment faire ?
Puis-je adapter tout cela à mon besoin ?
En savoir plus ...
35Tous 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 l'ISO 9126
Les méthodes et outils existent, sont applicables et sont adaptés à l'automatisme
− Support multi-automate
− Support les langages de l'IEC-61131
− Outils et méthodes disponibles
Recherche industriels et intégrateurs motivéssouhaitant participer au perfectionnement d'un modèlequalité adapté à l'automatisme.
A l'attention des industriels et intégrateurs
Invitation pour participer auperfectionnement d'un modèle qualité adapté à l'automatisme.
Merci de contacter DNV ou IAS
36Tous 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/
Thierry [email protected]
Principal consultant
Denis [email protected]
Directeur technique