INITIATION A LA QUALIMETRIE DE CODE D’AUTOMATE PROGRAMMABLE INDUSTRIEL

Vérification Automatique de code API – PLC Checker

Transfert Pédagogique par Reverse Engineering

Conclusions

� Un exemple de transfert pédagogique suite à des activités de recherche de l’enseignant-chercheur.

� Sensibilisation de la qualité de code API aux étudiants de master Pro EEAII, spécialité Systèmes Automatisés.

� Utilisation de PLC Checker lors de l’évaluation des projets de développement de programmes API.

PLC Checker trial website:www.plcchecker.comSimulation d’une écluse Pragma-Soft :http://ressources2.techno.free.fr/mecanique/ecluse/Index.htmPlateau de formation URCAwww.univ-reims.fr/meserp

Liens utiles

Aujourd’hui, écrire un programme dans un Automate Programmable Industriel (API) selon un cahier des charges définit ne suffit plus. Assurer la qualité des programmes automates requiertde nouvelles solutions capables d'automatiser la vérification de la conformité avec les règles de codage et de réduire les coûts de maintenance.Dans ce cadre, un programme académique a été mis en place au sein du master Professionnel EEAII (Electronique, Electrotechnique, Automatique, Informatique Industrielle) de l’URCA et lasociété Itris Automation Square pour la vérification automatique de la qualité du code API au moyen de l’outil logiciel PLC Checker.

Par la Recherche

Règles de NommageLes variables, routines (FC), blocs fonctions (FB) portent des mnémoniques qui doivent suivre des règles : � Tous les éléments constituant le programme doivent être nommés,� Les noms des éléments du programme doivent avoir une taille d’au moins 4 caractères et d’au plus 30 caractères,� Les mnémoniques des variables ne doivent pas faire référence à leur emplacement physique,

Règles de CommentaireLa bonne utilisation des commentaires facilite la compréhension du code :� Tous les éléments constituant le programme doivent être commentés (Sections, réseaux, variables …)� Les commentaires doivent comporter un minimum de caractères (7 pour les variables, 15 pour les codes),

Règles d’Ecriture du codeLe code doit respecter des règles d’écriture qui vont permettre d’éviter des problèmes lors de l’exécution du programme. La règle la plus élémentaire concerne le fait que toutes les variables, à l’exception des Entrées et des variables système, doiventêtre écrites avant d’être lues.

Règles de StructurationLa structuration du programme est importante car la maintenabilité du code en dépend :� Les sauts en arrière sont interdits,� Une variable doit être écrite au sein d’une seule routine, ou d’une seule tâche,� Une sortie physique ne doit être écrite qu’une seule fois par cycle API (Erreur classique chez les étudiants).

Informations utilesCe ne sont pas des règles mais des « bonnes pratiques » contribuant à l’amélioration de la qualité des programmes API :� Le taux de commentaires,� La présence de code mort,� La présence de code dans les commentaires,� Les indicateurs de la complexité du code comme le nombre cyclomatique ou la complexité essentielle,� Le nombre d’étapes du SFC,� Le ratio de code dupliqué sur l’application,

…

Pour l’enseignement

� 11/2011 : thèse CIFRE entre la SNCF et leCReSTIC. «Méthodologie pour les étudesd’automatisation et la génération automatiquede programmes Automates ProgrammablesIndustriels sûrs de fonctionnement »,

� Phase d’analyse fine des méthodologies etoutils de conception des programmes APIexistants au sein de la SNCF.

� Evaluation de la qualité du code APIaujourd’hui développé par la SNCF.

� Vérification de la qualité du code API parl’outil PLC Checker de la société ItrisAutomation Square (IAS)http://www.automationsquare.com/fr/

Utilisation de PLC Checker par les étudiants de Master Professionnel EEAII (Electronique, Electrotechnique, Automatique, Informatique Industrielle) de l’URCA.

Deux phases :� un cours magistral de 2 heures sur la qualimétrie de code API� 2 séances de travaux pratiques de 3 heures chacune.

Séance 1 : � Présentation en simulation du fonctionnement d’une écluse,� Identification par auto-apprentissage des contraintes sécuritaires,� Prise en compte d’un programme pré établi (Unity Pro de Schneider Electric) � Proposition d’une analyse fonctionnelle qui aurait pu amener à ce résultat

Séance 2 :� Analyse du résultat de PLC Checker� Correction du programme� Réitération de l’analyse PLC Checker pour évaluation du code à travers des indicateurs graphiques

� Prendre conscience que le code de l’un n’est pas toujours compréhensible par l’autre

� Assurer la lisibilité du code

� Rendre le code maintenable

� Etablir des standards de programmation d’API

� Permettre une pérennité du code

Retour Etudiants

� Des règles évidentes et pourtant oubliées

� Des indicateurs graphiques n'exprimant pas toujours l'analyse attendue.

� Le pourcentage d'erreurs et de commentaires donné n’est relié à aucune donnée exprimée quantitativement (10% d’erreurs sur quelle quantité d’information ?).