MESURES 826 - JUIN 2010 - www.mesures.com 57

Solutions Vu chez PSA Peugeot Citroën

Reportage

AUTOMATISMES

La qualité des programmes vérifiée par leurs concepteursDans un souci d’uniformisation et d’optimisation de ses chaînes de production, PSA Peugeot Citroën a lancé un projet ambitieux : intégrer à ses processus de dé-veloppement une méthode d’analyse des programmes automates. Cette techni-que innovante a été mise au point par la société grenobloise Itris Automation Square, qui l’a insérée à son logiciel PLC Checker. Aujourd’hui, l’utilisation de PLC Checker est imposée à tous les sous-traitants du constructeur. Les principaux bé-néficiaires sont les agents de maintenance, qui disposent de programmes plus homogènes, plus lisibles et débarrassés de la majeure partie de leurs bugs.

Près de cent cinquante automates neufs sont installés chaque année dans les usines de production de PSA Peugeot Citroën. Dans le même

temps, ce sont un peu moins d’une centaine d’automates qui sont modifiés ou remis à niveau. Ce qui représente, on l’imagine, une grande quantité de programmes dont la plu-part sont conçus par des sous-traitants inté-grateurs. Bien entendu, les responsables automatismes de PSA vérifient à la réception d’un programme que ce dernier répond bien à leurs attentes. Mais en dehors des as-pects fonctionnels, la facilité de maintenance

d’un programme est primordiale pour le constructeur. En effet, les automates ont une durée de vie qui peut dépasser une dizai-ne d’années. L’intervention d’un technicien de maintenance sera donc indispensable du-rant cette période. Pour débugger un pro-gramme, le technicien doit évidemment le comprendre. Ce qui dépendra fortement de la manière dont le programme a été réalisé. « Les agents de maintenance sont soumis à une pres-sion énorme, commente Laurent Mauguy, res-ponsable des activités transverses automatis-mes chez PSA Peugeot Citroën. Sur une chaîne de production qui sort une voiture par minute, les

temps d’arrêts coûtent très cher. Et ce n’est pas une fois la panne survenue que l’on peut commencer à étudier un programme que l’on ne connaît pas. D’où l’importance d’avoir des programmes bien cons-truits, bien écrits, et qui soient uniformes d’une chaîne de fabrication à une autre ».Afin de faciliter ses opérations de mainte-nance, PSA Peugeot Citroën devait donc trouver un moyen pour que les programmes sous-traités s’inspirent tous du même modèle et qu’ils utilisent tous les mêmes règles de co-dage. La solution, les responsables du groupe l’ont identifiée auprès d’Itris Automation Square. Cette société grenobloise a mis au point un logiciel d’“analyse statique de code automate”. De quoi s’agit-il ? Eric Pierrel, directeur marketing de l’entreprise, en ex-plique le principe : « L’analyse statique consiste à vérifier qu’un pro-gramme répond à un cer-tain nombre de règles, et ceci sans l’exécuter, c’est-à-dire uniquement en étu-diant la façon dont il a été écrit. L’analyse statique est déjà couramment utilisée dans le domaine de l’infor-matique embarquée, mais notre logiciel PLC Checker est le premier à mettre cette technique au service des automaticiens. » A l’origine du logiciel PLC Checker, on trouve le langage GLIPS. Ce langage “pivot”, mis au point par les fonda-teurs d’Itris Automation Square, traduit les pro-grammes Siemens

Itris Automation Square a mis au point une technologie innovante pour l’analyse de code automate.

PSA souhaitait avoir un référentiel commun pour tous ses programmes d’automatismes afin d’en faciliter la maintenance.

Désormais, tous les intégra-teurs qui développent des programmes pour PSA doivent effectuer une vérification de leur code avec l’outil PLC Checker.

PLC Checker met en évidence les défauts dans le code et vérifie la conformité vis-à-vis des règles de codage de PSA.

L’essentiel

Face à une production de plus en plus

externalisée, les dirigeants de PSA

Peugeot Citroën devaient trouver

une solution pour uniformiser la qualité

des programmes d’automatismes.

➜

MESURES 826 - JUIN 2010 - www.mesures.com58

SolutionsVu chez PSA

Peugeot Citroën

Reportage

MESURES 826 - JUIN 2010 - www.mesures.com 59

SolutionsVu chez PSA

Peugeot Citroën

Reportage

(Step 7), Schneider Electric (Unity-Pro et PL7 Pro) et Rockwell Automation (RSLogix5000), et c’est sur ce code GLIPS que PLC Checker réalise l’analyse statique proprement dite.Une fois l’analyse effectuée, le logiciel in-dique un taux de conformité vis-à-vis de l’automate cible (chaque constructeur ayant ses spécificités), une indication im-portante lorsque l’on cherche à réduire les temps de déploiement d’un programme.

Surtout, PLC Checker vérifie la compatibi-lité du programme au regard d’un certain nombre de règles de codage. Il y a des rè-gles génériques (éviter les divisions par zéro ou encore d’avoir trop de boucles im-briquées les unes dans les autres) mais aussi des règles spécifiques. Dans le cas de PSA Peugeot Citroën, ces dernières sont issues des bonnes pratiques identifiées par les res-ponsables automatismes du groupe. Le

constructeur a mis au point ses propres règles en ce qui concerne les noms et les types de variables, ainsi que le niveau de commentaires à insérer dans les program-mes.L’outil effectue aussi des tests de fiabilité, notamment afin d’éliminer tout le “code mort”. Il peut s’agir, par exemple, de fonc-tions qui ne sont jamais appelées, ou de boucles dans lesquelles il est impossible

d’entrer. Pour chaque partie du pro-gramme, PLC Checker vérifie que toutes les entrées sont lues (et sont utiles à la fonction en question), et que toutes les sorties sont bien écrites. Enfin, il peut dé-tecter du code qui a été mis en commen-taire par erreur. Tous les développeurs pla-cent en effet à un moment ou à un autre des lignes de code en commentaires pour les tests, et lors de la compilation il peut arriver que ces lignes soient laissées en commentaires par mégarde.

La vérification imposée à tous les sous-traitantsPar défaut, PLC Checker contient une ving-taine de règles de codage. Mais pour ce pro-jet, les ingénieurs de PSA ont collaboré avec les ingénieurs d’Itris Automation Square afin de définir des règles de codage spécifiques. Ils ont créé un ensemble de 70 règles. Celles-ci se déclinent en différents fichiers, car des règles peuvent être ajoutées ou supprimées en fonction des projets. Mais ce n’est qu’un début : si les ingénieurs ont commencé par les règles les plus importantes (ainsi que celles qui étaient simples à programmer en GLIPS), il est prévu de poursuivre les tra-vaux pour porter leur nombre à 100. A titre de comparaison, le standard MISRA pour

le code C embarqué dans l’automobile compte 170 règles de codage. L’objectif à terme est donc d’arriver au même niveau de vérification pour les automates qui pi-lotent les lignes de production que pour les programmes embarqués dans les calcu-lateurs des véhicules.Encore faut-il veiller à ce que ces règles soient respectées. Il suffit qu’un des sous-traitants n’utilise pas PLC Checker pour que tous les efforts déployés se révèlent inutiles. « En effet, ajoute Laurent Mauguy (PSA Peugeot Citroën), même si cette technologie innovante amé-liore la qualité du code automate, l’analyse a un coût (quelques centaines d’euros) que les sous-traitants ne sont pas forcément prêts à payer. C’est la raison pour laquelle nous avons décidé d’en imposer l’uti-lisation, pour tous nos programmes et pour toutes nos usines ».

Une plate-forme collaborativeUn projet d’envergure, donc, qui est aussi une aubaine pour Itris Automation Square dont la solution était jusqu’à présent essentielle-ment employée en France. Elle est désormais adoptée par des intégrateurs de toute l’Eu-rope. Effectivement, selon la procédure mise en place, les sous-traitants ont affaire direc-tement à Itris Automation Square afin de four-nir à PSA des programmes respectant les

règles établies et exploitables rapidement. Le logiciel PLC Checker s’exécute entière-ment à distance. Les développeurs envoient leur programme via Internet sur les serveurs informatiques d’Itris Automation Square. L’analyse est lancée, et les résultats sont im-médiatement publiés. « Chaque automate de PSA est identifié grâce à une fiche signalétique. Afin d’être sûr de vérifier chaque programme avec les bonnes règles de codage, les développeurs travaillent sur un espace du site réservé à un automate en par-ticulier, commente Eric Pierrel (Itris Automation Square). Une fois l’analyse effectuée, le responsable du projet de PSA récupère les rapports de contrôle afin de valider un programme ou d’accorder des dérogations si nécessaires (lorsqu’une règle n’a pas été suivie mais que cela était justifié par le contexte du projet). Clients finaux et développeurs accèdent aux données de manière sécurisée. Toutes les infor-mations sont centralisées et conservées sur nos ser-veurs pour en assurer la traçabilité. PLC Checker constitue ainsi une véritable plate-forme collabora-tive. »Outre les problématiques liées à la mainte-nance, l’utilisation de cette plate-forme ré-pond à plusieurs besoins de PSA Peugeot Citroën. Tout d’abord, celui d’accélérer le dé-marrage des nouvelles chaînes de produc-tion. Une grande partie du travail de mise au point, qui est effectuée à réception du

Un fichier de règles est édité pour chaque projet. Il indique tous

les aspects du code qui seront vérifiés

par PLC Checker.

Un exemple de tableau de bord d’analyse fourni par PLC Checker. Il indique une répartition des erreurs par types de règle de codage.

Afin d’éviter tout malentendu, les analyses sont toutes faites à distance sur les serveurs d’Itris Automation Square. Les dirigeants de PSA s’y rendent pour vérifier l’état d’avancement d’un projet.

Grâce à la démarche ACTIF, les règles de codage de PSA vont au-delà des programmes automates. Ils s’appliquent également aux schémas électriques ainsi qu’aux pupitres et terminaux opérateurs.

Chaque automate est identifié grâce à une fiche signalétique qui est transmise à Itris Automation Square et accessible par les sous-traitants.

L’utilisation systématique de PLC Checker sur tous les nouveaux programmes automates a bénéficié aux ingénieurs de PSA, comme à ses sous-traitants. Voici ce que chacune des équipes a pu retirer de l’analyse statique des programmes :

Pour les ingénieurs “qualité et méthodes” :- Les règles de codage sont plus clairement définies et formalisées ;- Les cahiers des charges sont plus simples à réaliser, car les règles de codage sont livrées séparément des aspects fonctionnels.

Pour les concepteurs de programmes d’automatismes :- La vérification de la conformité aux règles de codage est devenue automatique ;- Les phases de test sont sensiblement réduites, ce qui permet aux développeurs de se concentrer sur le fonctionnel ;

- Le donneur d’ordres peut vérifier la conformité d’un programme dès réception et se l’approprier plus rapidement ;- L’analyse étant effectuée à distance via Internet, il n’y a pas de logiciel à installer ni à maintenir.

Pour les ingénieurs chargés des audits des programmes :- Les tests d’acceptation peuvent désormais être faits sur la base de critères objectifs ;- La vérification de la qualité du code devient simple, rapide et efficace.

Pour les agents de maintenance :- Plus lisibles, les programmes sont aussi plus faciles à dépanner et à faire évoluer ;- En cas de bug, les interruptions durent moins longtemps qu’avant.

Vérification de code automate : des bénéfices partagés par tous

➜

➜

MESURES 826 - JUIN 2010 - www.mesures.com60

SolutionsVu chez PSA

Peugeot Citroën

Reportage

MESURES 826 - JUIN 2010 - www.mesures.com 61

SolutionsVu chez PSA

Peugeot Citroën

Reportage

programme, est ici réduite grâce à un code débarrassé des bugs les plus courants. Par ailleurs, PLC Checker résout le problème du partage des responsabilités en cas de dys-fonctionnement. En effet, d’ordinaire les programmes passaient sous la responsabilité de PSA dès lors qu’il les acceptait. « Jusqu’à présent, les services de PSA effectuaient une vérifi-cation visuelle avant d’accepter les programmes. Des tests étaient réalisés par sondage, mais certains bugs pouvaient passer au travers de ce premier contrôle, commente Marcel Tedesco, directeur techni-que d’INEO agence de Terville. De plus, il peut arriver qu’un programme soit fonctionnel lors des premiers tests mais qu’il se révèle défectueux une fois que la production monte en cadence. Pour tous

ces bugs qui étaient détectés trop tard, c’était à l’in-tégrateur d’intervenir pour faire les modifications nécessaires. Aujourd’hui, avec cet outil, PSA ne peut plus nous dire : “votre programme n’est pas con-forme”. PLC Checker est en quelque sorte notre juge de paix. Grâce à lui les relations clients-fournisseurs sont moins ambiguës. » Tous les programmes pour automates neufs livrés par les sous-trai-tants sont désormais accompagnés d’un “cer-tificat” attestant la qualité de leur programme au regard des règles PSA. Le sous-traitant est dans l’obligation pour être payé de fournir le rapport d’analyse de PLC Checker. Et une fois qu’un programme est déclaré conforme, il passe sous la responsabilité de PSA.

Du changement pour les sous-traitantsLes premières utilisations de PLC Checker n’ont pas manqué de susciter des réactions de la part des sous-traitants. Les responsables des équipes de développement, notamment, s’inquiétaient du fait que le logiciel donnait des résultats différents selon la personne en charge de la programmation. « Mais ceci est tout à fait normal, assure Eric Pierrel, car il n’y a pas deux ingénieurs qui codent exactement de la même manière. Auparavant c’était invisible, car on mesurait parfois les performances d’une équipe de programmeurs, mais jamais on ne les comparait entre eux. » Cette remise en cause des proces-sus de développement a donc un impact fort chez les sous-traitants et les intégrateurs. « Aujourd’hui, PLC Checker a été intégré au réfé-rentiel de notre entreprise, déclare Marcel Tedesco (INEO agence de Terville). Pour chaque projet PSA, nous conservons une trace de tous les résultats d’analyses. Certes, le fait de mesurer la qualité d’un programme en fonction du program-meur était nouveau pour nous, et il a fallu s’y ha-bituer au début. Mais aujourd’hui tous les déve-loppeurs se sentent davantage impliqués, et la qualité de leur travail s’en trouve améliorée. »Rappelons également que le rôle de PLC Checker se limite à mettre en évidence tou-tes les “zones à risque” dans les program-mes. Il est certain qu’un développeur qui lance l’analyse pour la première fois pourra être surpris par la quantité d’alertes géné-rées par le logiciel (parfois plus d’un mil-lier). Il faut dire que les règles définies par PSA sont volontairement strictes, car on pré-fère que PLC Checker produise trop d’aler-tes plutôt que pas assez. « Nous ne réception-nons aucun programme avec zéro alerte, indique Laurent Mauguy (PSA Peugeot Citroën). Avec le référentiel que nous avons mis en place, on consi-dère qu’en dessous d’une vingtaine d’alertes il s’agit d’un bon programme. Et même si le fait d’étudier chaque alerte peut prendre du temps, les délais de

vérification se sont considérablement raccourcis : nos ingénieurs n’effectuent plus d’allers-retours avec le sous-traitant jusqu’à ce que les programmes soient conformes. »Pour assurer la conformité des programmes, les développeurs doivent bien sûr se fami-liariser avec les règles PSA. Mais surtout, ils doivent effectuer des analyses au fur et à me-sure de l’avancement d’un programme. Au moment où l’utilisation de PLC Checker a été imposée, les sous-traitants avaient le choix entre une vérification unique (avant livraison) ou un forfait avec analyses illimi-tées. Mais les responsables d’Itris Automation Square et de PSA ont estimé d’un commun accord que la première formule ne donnait pas d’assez bons résultats. Ils favorisent dé-sormais la seconde, la seule qui permette aux sous-traitants de véritablement comprendre les règles de codage et de s’impliquer dans la qualité de leurs programmes.

PLC Checker est intégré à une démarche qualité globalePLC Checker est utilisé chez PSA Peugeot Citroën depuis un an et demi. Les responsa-bles du groupe estiment qu’ils pourront établir des statistiques des prestations de leurs fournisseurs dès la fin 2010. Comme souvent avec ce type de logiciels visant à améliorer la qualité, le gain financier est relativement difficile à évaluer. Toujours est-il que, pour le constructeur comme pour ses sous-traitants, le bilan est positif à tous points de vue. D’une part, parce que le fait d’effectuer ces contrôles exhaustifs et automatiques ne peut que réduire le ris-que de panne en cours de production (et même en cas de panne, les agents de main-tenance peuvent intervenir plus vite puis-que tous les programmes ont une structure commune). D’autre part, car les déve-loppeurs sont davantage impliqués dans la qualité du code qu’ils produisent. Leur res-ponsabilité est accrue, car la livraison d’un programme s’accompagne d’une obliga-tion de résultat.Aujourd’hui chez PSA, l’utilisation systéma-tique de PLC Checker fait partie d’une dé-marche plus globale visant à améliorer la qualité et la maintenabilité des systèmes automatisés. Ce vaste projet appelé ACTIF regroupe un certain nombre de normes communes à tout le groupe et qui concer-nent la sécurité, la réalisation des interfaces homme-machine, les câblages électriques, les méthodes d’analyse fonctionnelle des programmes ainsi que d’autres aspects trans-verses. C’est dans cette dernière partie qu’a été intégré PLC Checker.

Plus d’une trentaine de sous-traitants ont utilisé PLC Checker depuis le début du pro-jet. Les statistiques conservées par Itris Automation Square indiquent qu’en moyenne douze analyses sont nécessaires pour satis-faire aux critères qualité de PSA Peugeot Citroën. Il reste donc du chemin à parcourir avant de développer des programmes con-formes du premier coup, mais cela va aller en s’améliorant au fur et à mesure que les sous-traitants intégreront les principes de

codage au plus tôt dans leurs processus de développement.

PSA impliqué dans l’adoption de nouvelles technologiesCe que l’on retiendra de ce projet, c’est avant tout le rôle moteur du constructeur français dans l’utilisation de cette nouvelle technolo-gie qu’est l’analyse statique de code auto-mate. « Nous appliquons la même stratégie que nous avions mis en place dans les années 1996 à

1998 pour favoriser l’utilisation de la simulation pour la conception des systèmes de contrôle com-mande. Elle n’avait jamais été réellement exploitée jusqu’à ce que nous l’imposions à tous nos sous-traitants, rappelle Laurent Mauguy (PSA Peugeot Citroën). Aujourd’hui, l’emploi de la simulation est systématique, et pas uniquement pour l’automobile. Nous aimerions connaître le même succès avec PLC Checker, pour encore améliorer la qualité dans les pro-grammes d’automatismes, tous secteurs confondus ».

Frédéric Parisot

L’intégrateur devenu éditeurItris a démarré en 1995 une activité d’intégrateur : la société grenobloise s’est fait connaître en développant des programmes d’automatismes pour différents industriels. Les membres fondateurs de la société se sont vite rendu compte du temps perdu lors de la vérification des pro-grammes. De même, ils regrettaient qu’il soit si difficile de déployer un même programme sur des automates de constructeurs différents. C’est la raison pour laquelle ils mirent au point le langage GLIPS, un langage suffisamment abstrait pour s’affranchir du type de l’automate cible, et suffisamment complet pour pouvoir étudier séparément les parties synchrones et asynchrones d’un programme et y appliquer des méthodes de tests issues du monde de l’informatique (analyse statique, méthodes formelles, etc.).Dans un premier temps, le langage fut réservé à un usage interne à l’entreprise. Mais Itris a ensuite décidé d’exploiter commercialement ce savoir-faire. En 2008, la société change de nom pour Itris Automation Square et change d’activité : de prestataire de services, elle devient éditeur de logiciels.Le caractère innovant de cette technologie a permis à la société de se développer rapidement et de compter parmi ses clients de grands groupes industriels dans l’automobile, comme PSA Peugeot Citroën, mais aussi dans les domaines de l’énergie (avec Schneider Electric ou GDF Suez) et de la Défense (avec Snecma ou encore la DCNS).Outre PLC Checker, son catalogue de produits comprend PLC Metrics (édition de statistiques pour les programmes automates), PLC Converter (traduction d’un programme d’un automate à un autre), PLC DocGen (traduction d’un program-me sous forme de logigrammes, pour faciliter la maintenance) ainsi que PLC Virtualizer (émulation de programmes automates sur PC).

Déployée il y a deux ans (c’est-à-dire quelques mois avant l’utilisation de PLC Checker), la méthode ACTIF est une norme mise au point par le groupe PSA. Elle définit une structure globale pour tous les aspects liés aux automatismes, au sein du groupe comme chez ses sous-traitants. Elle comprend sept normes fondamentales relatives à la sécurité, aux métiers transversaux, à l’analyse fonctionnelle des programmes, aux dossiers électriques, à la programmation, aux terminaux opérateurs et aux réalisations électriques. L’utilisation systématique de PLC Checker fait désormais l’objet d’un des paragraphes de la norme relative aux métiers transversaux.

Dans un contexte où de plus en plus de fonctions sont réalisées par des tiers, l’objectif de la démarche ACTIF est d’apporter plus de cohérence entre les différents livrables. Il s’agit d’offrir un cadre de travail commun à tous les sous-traitants afin de faciliter le démarrage des nouvelles installations et de réduire le nombre d’arrêts de production. La mise en place d’ACTIF a donc un impact sur les métiers de la maintenance, mais aussi sur les opérateurs qui peuvent passer d’une chaîne de production à une autre sans être dépaysés, et dans certains cas réaliser eux-mêmes le redémarrage d’une chaîne sans faire appel à l’agent de maintenance.

Une démarche pour plus de cohérence

➜