Itris Automation a signé son premier partenariat académique avec l’université de Reims Champagne-Ardenne (URCA). Itris Automation met à disposition des étudiants de l’URCA des droits d’utilisation de PLC Checker. L’initiative a été développée dans le but d’initier les étudiants de l’URCA à la vérification des programmes automates réalisés au cours de leurs travaux pratiques et de leurs projets.
Retrouvez-nous sur http://www.itris-automation.com/fr/
Contactez-nous sur commercial@itris-automation.com pour plus d'informations.
[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov....
[FR] Poster Cetsis 2014 - PLC Checker
1. INITIATION A LA QUALIMETRIE DE CODE D’AUTOMATE PROGRAMMABLE INDUSTRIEL
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 requiert
de 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 la
société Itris Automation Square pour la vérification automatique de la qualité du code API au moyen de l’outil logiciel PLC Checker.
Vérification Automatique de code API – PLC Checker
Par la Recherche
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.
Liens utiles
PLC Checker trial website:
www.plcchecker.com
Simulation d’une écluse Pragma-Soft :
http://ressources2.techno.free.fr/mecanique/ecluse/Index.htm
Plateau de formation URCA
www.univ-reims.fr/meserp
Règles de Nommage
Les 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 Commentaire
La 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 code
Le 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 Structuration
La 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 utiles
Ce 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 le
CReSTIC. «Méthodologie pour les études
d’automatisation et la génération automatique
de programmes Automates Programmables
Industriels sûrs de fonctionnement »,
Phase d’analyse fine des méthodologies et
outils de conception des programmes API
existants au sein de la SNCF.
Evaluation de la qualité du code API
aujourd’hui développé par la SNCF.
Vérification de la qualité du code API par
l’outil PLC Checker de la société Itris
Automation 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 ?).