Voici la présentation de Thierry Coq (Consultant principal pour DNV) et Denis Chalon (Directeur technique d'Itris Automation Square) lors de la journée de débats du Club Automation le 22 novembre 2011 : "Modèle Qualité pour l'automatisme - Conception sûre des applications de contrôle-commande". Retrouvez-nous sur http://www.itris-automation.com/fr/ Contactez-nous sur commercial@itris-automation.com pour plus d'informations.

1. Modèle Qualité pour l'automatisme
Conception sûre des applications de contrôle-commande
Mardi 22 novembre 2011
Thierry COQ Denis CHALON
thierry.coq@dnv.com denis.chalon@automationsquare.com 1
System and Software Reliability
Directeur technique
Principal consultant

2. 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
2
Tous droits réservés

3. 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)
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

4. 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?
4
Tous droits réservés

5. 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 logiciel
14mm 120mm 400mm
5
Tous droits réservés

6. É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 fixe
Chef de projet Automaticien
6
Tous droits réservés

7. 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 retard
Chef 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

8. 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é ?
8
Tous droits réservés

9. 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)
9
Tous droits réservés

10. Principe de fonctionnement d'un 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

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

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

13. Modèle d'analyse
La fonction fctn_vannes
a 67 lignes de code
Mesure 1
Mesure 2 Modèle Attribut 1 Le programme a une
bonne testabilité
Mesure 3 d'analyse
Attribut 2
...
Attribut 3
Mesure N
La variable cbfe_34 Attribut 4
n'a pas de commentaire Vérification 1
Attribut 5
Vérification 2 ...
...
Attribut N
Vérification N
13
Tous droits réservés

14. 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.
14
http://www.sqale.org/ Tous droits réservés

15. 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
15
Tous droits réservés

16. Une solution
Tableau de bord
Modèle qualité
la boîte noire s'ouvre
pour tous les
intervenants...
Sonde logicielle
Ateliers
5 Langages IEC
16
Tous droits réservés

17. L'automaticien 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 logiciel
Chef de projet
que la simple application sur laquelle le
développeur travaille.
Automaticien
17
Tous droits réservés

18. Le chef de projet et le logiciel
Client
Problèmes solutionnés :

Suivre la qualité

Suivre l'avancement du projet Le tableau de bord permet
Méthodes

Benchmarking une navigation depuis la
vision globale jusqu'au
détail
Chef de projet
80-400mm
Il permet également un
Automaticien suivi temporel de l'avan-
cement du
projet
18
Tous droits réservés

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

20. 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 d'une vue objective.

Corrélation possible avec d'autres
sources d'informations disponibles
dans l'usine
Chef 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

21. Cas réel – Audit DNV
Est-ce utilisable dans la vraie vie ?
Comment cela se met-il en œuvre ?
Quel temps gagné / perdu ?
21
Tous droits réservés

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

23. 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
23
Tous droits réservés

24. 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é
24
Tous droits réservés

25. 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 »
25
Tous droits réservés

26. 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 la
réalité ressentie ?
26
Tous droits réservés

27. É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
27
Tous droits réservés

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

29. 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
Critère d'acceptation

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

30. Nombre de lignes de code
APPLICATION UNITE DE PROGRAMMATION
 Pas de critères de qualité sur cette dimension, juste une
information 
S'assurer 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

31. 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
Critère d'acceptation
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
Critère d'acceptation tous les langages (limitations sur
langages graphiques : SFC, FBD et
LD).
31
Tous droits réservés

32. 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 d'acceptation
− 90% ont 52% de commentaires
32
Tous droits réservés

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

34. Conclusion
Comment participer ?
Comment utiliser ?
J'ai un cas d'utilisation, comment faire ?
Puis-je adapter tout cela à mon besoin ?
En savoir plus ...
34
Tous droits réservés

35. 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
A l'attention des industriels
− Support les langages de l'IEC-61131 et intégrateurs
− Outils et méthodes disponibles Invitation pour participer au
perfectionnement d'un
modèle qualité adapté
à l'automatisme.

Recherche industriels et intégrateurs motivés
Merci de contacter
souhaitant participer au perfectionnement d'un modèle DNV ou IAS
qualité adapté à l'automatisme.
35
Tous droits réservés

36. 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 COQ36
denis.chalon@automationsquare.com thierry.coq@dnv.com
Tous droits réservés
Directeur technique Principal consultant