Programmation d'automates : 10 bonnes pratiques

La programmation d'automates et plus globalement de systèmes automatisés est à la fois un art et une science.L'utilisation de plusieurs outils, langages de programmation et fonctions permet aux ingénieurs de concevoir des solutions créatives répondant à des besoins bien spécifiques.En effet,le fait de concevoir une machine à part de zéro nécessite certes des compétences très techniques mais aussi suscite l'imagination.

Bonnes pratiques

En raison des multiples méthodes et outils disponibles, la route menant vers la résolution d'un problème déterminé peut varier considérablement selon le chemin choisi au début.Le but de cet article est de décrire les meilleures pratiques de programmation que vous pourrez utiliser lors de la conception de vos projets.L'intention ici n'est pas de définir comment programmer des fonctions spécifiques, mais de développer certaines bonnes pratiques qui permettent de fournir un livrable exceptionnel, une approche cohérente et bien planifiée.

Les standards de programmation sont des méthodes de codage qui sont créés pour accroitre la performance du programmeur.Les «meilleures pratiques», étroitement liées aux standards de programmation, décrivent les méthodes et les stratégies à suivre lors de la conception et du déploiement des standards de programmation. Les meilleures pratiques peuvent également impliquer l'ajout de segments de code supplémentaires et / ou la suppression de codes redondants ou morts qui ne sont pas utilisés. Les meilleures pratiques sont des méthodes recommandées pour écrire un segment de code, tandis que les standards de programmation sont un ensemble spécifique de règles à appliquer au style et aux techniques de codage.


Règle #1 : Définissez votre structure

Lorsque vous développez un programme à partir de zéro ou que vous complétez un programme existant, vous devez prendre du recul par rapport aux détails et définir une bonne structure. Cela fournit un plan clair de la façon dont vous allez diviser les fonctions, les variables et fournir un arrangement logique. La segmentation des fonctions permet une conception qui peut facilement être étendue et suivie par d'autres programmeurs.

Commencez par développer un diagramme visuel de la structure de votre code. Dans certains cas, vous pouvez clairement décrire cette structure dans le code réel. Ceci est comparable à la construction d'une table de légende au sein d'un dessin et devrait fournir une carte de la structure de votre programme et / ou des notes de développement et de segmentation afin que le prochain programmeur puisse suivre les mêmes méthodes. Cette structure doit inclure à la fois le code de votre automate mais aussi de votre HMI si vous en disposez.


Règle #2 : Veillez toujours à bien documenter votre programme et dossiers de conception

Une documentation pour appuyer les exigences fonctionnelles et / ou spécifications est essentielle pour permettre le développement d'un programme.En effet,les documents qui sont utilisés pour répondre aux exigences fonctionnelles de la machine à concevoir sont tout aussi importants que le programme à concevoir.Une documentation n'exige pas de concevoir  un long document officiel, mais elle doit clairement décrire la structure et les standards de programmation qui seront suivies. Une simple feuille de calcul Excel peut être utilisée pour relayer cette information. Cependant, l'emplacement idéal pour cette information est dans le programme lui-même pour s'assurer de ne pas l'égarer.

 

Règle #3 : Toujours planifier les modifications ultérieures

Lors du développement d'un système, il est important de planifier les extensions, les modifications et les réductions futures. Par conséquent, lorsque vous définissez votre structure, vous devez toujours être conscient des changements potentiels.Ne concevez pas de structures limitées qui pourraient rendre difficile la modification de votre structure initiale.Par exemple, si vous segmentez vos emplacements de mémoire pour chaque type de données, veillez à avoir suffisamment de place pour les modifications et / ou les extensions du système dans les années à venir.

De plus, c'est toujours bon de décrire votre structure de programme sur papier pour identifier visuellement comment le code sera segmenté et introduire quelques changements potentiels pour tester la structure organisationnelle de votre conception.La planification des potentielles modifications est difficile parce que vous ne savez pas ce qui va se passer dans le futur. Il est toujours recommandé de revoir votre concept avec d'autres ingénieurs plus expérimentés pour s'assurer que vous ne négligez pas l'évidence. Cependant, il y a un équilibre entre la planification des extensions futures de l'extension et le respect des exigences. Prévoyez une expansion future de votre système,mais ne consacrez tout votre temps à faire du sur-optimisation inutile,votre temps est précieux !


Règles # 4 : Effectuer des choix technologiques judicieux

A quoi bon d'acheter un char blindé pour tuer une moustique ! Il faut toujours veiller à vérifier que les solutions que vous allez retenir répondent bien aux besoins du problème à résoudre.Il faut donc bien étudier votre système avant d'effectuer le choix technologique.Ne pas le faire est irresponsable. Vous ajouteriez aveuglément des frais supplémentaires à votre projet.La phase du choix technologique peut être certes chronophage mais tout de même crucial pour garantir le succès.

 

Règle # 5 : Réutilisez votre code à volonté !

Dans un projet,il peut arriver d'utiliser les mêmes fonctions à plusieurs endroits du programme.La mauvaise manière de faire serait de coder en dur les mêmes fonctions plusieurs fois, ce qui entraînerait des coûts supplémentaires tels que l'augmentation de la mémoire et la réduction de la vitesse de traitement du programme.

En codant plusieurs fois la même fonction, vous introduisez également une possibilité d'erreur car les modifications apportées à une instance doivent être copiées avec précision dans toutes les autres instances à la main.La bonne pratique est donc de créer une source unique de fonctions et de les appeler en cas de besoin. Cela vous demandera de coder les fonctions sur un niveau général et, dans certains cas, vous allez peut-être inclure des paramètres ou des variables supplémentaires pour aider la fonction à tenir compte des attributs différents ou supplémentaires.

 

Règle # 6 : Soyez cohérent jusqu'au bout

La cohérence est un élément crucial quand on conçoit quelque chose.Lors de la conception d'une analyse fonctionnelle ou d'un programme,il faut tâcher toujours d'être le plus cohérent possible.En effet,l'incohérence montre l'immaturité dans une conception et peut causer plusieurs problèmes au cours du cycle de vie d'un système.

En effet,dans certains cas, des méthodes alternatives peuvent être découvertes après le développement initial et la décision de changer d'angle devrait dépendre uniquement de la performance du système et des fonctionnalités supplémentaires.Si vous avez identifié une méthode plus astucieuse qui peut avoir un facteur «cool», mais qui n'améliore pas les performances ou n'offre pas suffisamment de temps de développement pour couvrir tout le temps passé dans l'application, alors vous devez vous en tenir à la solution initiale.


Règle # 7 : Soyez astucieux et malin

Un bon programmeur doit être quelqu'un de très astucieux,quelqu'un qui peut faire beaucoup de choses avec peu de moyens,quelqu'un d'efficient et pas seulement efficace.Pour cela,essayez de vous tenir au courant de ce qui ce fait actuellement et des nouveaux outils et technologies qui viennent de sortir.Si vous ne faites pas cela,vous risquez d'être largué en un rien de temps et perdre de l'efficacité au travail.Aussi,prenez le temps de tester les outils de programmation et d'autres fonctionnalités pour vous assurer que la programmation et le déploiement utilisent les méthodes les plus efficaces disponibles.

À titre d'exemple, au lieu d'intégrer plusieurs instructions «IF THEN», vous devez utiliser des instructions «CASE» pour fournir plus d'efficacité et fournir une structure plus lisible. Communiquez avec d'autres ingénieurs plus expérimentés et discutez d'autres outils avec lesquels vous n'êtes peut-être pas familiers et mettez en place un test rapide pour acquérir l'expérience nécessaire.

Cependant,vous ne devez pas passer tout votre temps à chercher des astuces pour modifier par la suite un plan déjà établi car cela pourrait nuire et interférer avec le concept cité précédemment,celui de la cohérence.Il est tout de même bon de connaître vos outils avant de concevoir votre application pour vous assurer que vous pouvez fournir une solution adéquate compte tenu de la période de livraison définie.

 

Règle # 8 : Veillez à concevoir un code propre et structuré

Un bon entretien dans votre programme est toujours une bonne pratique. Dans certains cas, vous devez créer des fonctions ou des éléments pour vous aider à gérer les données et à garder votre programme propre.Les bonnes pratiques d'entretien font partie de l'organisation, ce qui favorise l'efficacité et le professionnalisme.Par exemple pour une machine donnée,au lieu de mettre un pan de code à un seul endroit,essayez de segmenter votre code par fonction.Par exemple dans l'atelier d'ingénierie comme TIA Portal de Siemens,on a la possibilité de créer plusieurs blocs de fonctions.


Règle # 9 : Veillez à toujours commenter votre code

Rien n'est plus frustrant que de lire un code mal commenté ou pire encore commenté de façon incohérente. La signification, la terminologie, le nom d'une variable et la description de celle-ci  doivent être tout aussi cohérents que le code lui-même.Le code lui-même explique comment quelque chose se passe et le commentaire devrait refléter pourquoi cela se produit.

Les commentaires doivent être effectués à chaque niveau. En d'autres termes, chaque fonction devrait avoir un bref commentaire.Aussi, le programme dans son ensemble doit être commentée pour aider la personne qui lira le programme de le comprendre aisément.Les commentaires doivent être concis, cohérents, précis et écrits pendant la programmation et non après.

Un type de commentaire particulièrement précieux est la description des raisons pour lesquelles vous n'avez pas codé quelque chose d'une manière particulière. S'il y a une façon standard de coder quelque chose, et que vous avez choisi de le faire différemment (que vous l'ayez essayé de façon standard ou non), vous devriez expliquer pourquoi vous avez choisi de le faire différemment dans un commentaire. C'est autant important pour vous que pour les autres - quand vous reviendrez et regarderez votre code un an plus tard et demanderez "pourquoi ai-je fait ceci?" La réponse sera là.

 

Règle # 10 : Enregistrez vos modifications

Il faut toujours garder une trace des changements dans un programme,cela permet de se repérer tout au long du développement.Des journaux de modifications doivent être incorporés dans votre projet et de préférence dans la section d'en-tête pour les changements globaux. Cependant, si des modifications sont nécessaires au niveau de la couche de fonction, elles doivent être répercutées dans l'en-tête global ainsi que dans la couche de commentaires de la fonction elle-même.

Un bon journal des modifications inclut une entrée de journal ou un numéro de révision. Ainsi que la date et la personne effectuant les changements. La description doit décrire la nécessité du changement et définir explicitement tous les aspects du programme qui sont concernés.


Résumé

Les méthodes et les stratégies de programmation sont subjectives dans une certaine mesure, et la flexibilité de l'utilisation de plusieurs techniques permet aux ingénieurs de solliciter leur esprit créatif pour produire des solutions. Être créatif est une forme d'expression de soi qui doit être équilibrée par de bonnes pratiques pour s'assurer que la solution correspond aux objectifs globaux de l'utilisateur final.

L'utilisateur final a évidemment des objectifs communs partagés avec le développeur, mais a également des objectifs supplémentaires tels que la facilité d'utilisation, la capacité d'expansion, et la capacité de dépanner et d'interposer des fonctions pour soutenir la production au besoin. Le respect des meilleures pratiques devrait être l'une des principales considérations lors de la fourniture d'une solution finale à l'utilisateur final afin de garantir que le produit de la programmation respecte les pratiques acceptables de l'industrie.

Ces méthodes énumérées ci-dessus fournissent la convivialité, la flexibilité et la maintenabilité globales pour garantir que le développeur et l'utilisateur final disposent d'une solution efficace et de qualité capable de supporter le cycle de vie du produit. Les ingénieurs devraient s'efforcer d'offrir un niveau de programmation plus élevé pour permettre aux clients de réussir dans la fabrication. Chaque projet devrait consister en des solutions solides qui permettent aux entreprises d'accroitre leur performance.

formation automatisme automate programmable

Commentaires

  • automationsense
    Bonjour,
    1) Il y' a plusieurs différences le profinet c'est un réseau ethernet industriel,le modbus il y'a plusieurs variantes,les modes de fonctionnement diffèrent,merci de regarder sur google c'est plus simple
    2) IHM c'est en français et HMI en anglais
    3) Non nous n'avons de formations qui englobe tous les rseaux
    Cdlt
  • Bea
    • 2. Bea Le 06/05/2020
    Bonsoir!
    J'aimerais avoir la réponse aux questions suivantes s'il vous plaît :
    1- la différence entre profibus (DP, PA, FMS) , profinet, modbus( les types de modbus), ASI et ethernet ;
    2- la différence entre HMI et IMH
    3- Avez-vous un module de formation qui englobe tous les réseaux ou protocoles de communication?
    Merci d'avance !

Ajouter un commentaire

 

7 choses à savoir si Tu débutes en automatisme...

7 choses que tu dois savoir si tu debutes en automatismeCliquez ici pour télécharger le guide PDF

Superv 3