Préambule

Un programme automate est réalisé suivant un cahier des charges.
Généralement ce cahier des charges pour l'automatisme est appelé analyse fonctionnelle (souvent abrégée en AF)

Une analyse fonctionnelle doit reprendre les points suivants :

• Description des équipements de l'installation.
• Descriptions des capteurs et des actionneurs.
  • Liste des entrées et des sorties pour l'automate.
  • Liste des informations annexes.
• Description du fonctionnement de l'installation.
  • Descriptif général.
  • Descriptif détaillé de chaque équipement.
• Schéma de l'installation.
  • Repérage des différents équipements.
  • Repérage des différents capteurs.
  • Repérage des différents actionneurs.

 On peut y trouver aussi en annexe :

• Les graphs de fonctionnement.
• Des schémas type pour les échanges entre les différents éléments de contrôle-commande.

La réalisation d'une analyse fonctionnelle prend du temps. Ce temps peut sembler inutile et de nombreuses personnes voudront l'économiser.

C'est une erreur à ne pas faire !

Ce temps passé à rédiger l'analyse fonctionnelle permettra de :

• Poser les bases du programme automate.
• Définir et valider l'orientation de la programmation.
• Éviter des oublis de fonctionnalités.

Cette analyse fonctionnelle servira pour un autre document qui est l'analyse organique.

Parfois ces deux documents peuvent être synthétisés en un seul.

On parle alors d'analyse fonctionnelle détaillée.

Pour ma part, je préfère avoir un seul document que plusieurs. Ce n'est qu'une question de simplification lors de modification... Car vous aurez toujours des modifications.

Programmation

Une fois notre analyse fonctionnelle détaillée en main, il vient le temps de la programmation.

A partir de ce moment, sauf grosse erreur de conception dans votre analyse fonctionnelle, vous devez la suivre.

D'où l'importance de bien la détailler.

Un programme automate ne devrait être que la transcription de l'analyse fonctionnelle en code interprétable par l'automate.

Il y a de trop nombreux programmes qui sont réalisés sans analyse fonctionnelle, et par là même, de trop nombreux automaticiens qui se plaignent de refaire le travail ou de ne pas savoir ce qu'ils ont à faire…  Je pourrais leur dire que c'est ce qu'ils méritent car ils ont commencé à coder sans analyse fonctionnelle.

Il est vrai que les besoins peuvent évoluer durant la réalisation du projet. L'analyse fonctionnelle doit alors être revue et adaptée en fonction de ces nouveaux besoins.

Réalisation des modules permettant de rendre générique le programme

Tous les paramètres de l'installation doivent être paramétrables et sauvegarder dans un fichier, une base de données, tout autre moyen qui permette de s'affranchir de stocker et d'écrire en "dur" toutes ces valeurs dans le programme.

Dans tous les cas, ces paramètres doivent être chargés avant le démarrage du programme principal. 

En général, les automates ne redémarrent pas souvent, ce ou ces modules n'ont pas besoin d'être optimisés pour une vitesse de lecture, mais plutôt pour une simplicité d'évolution.

La lecture se fera au démarrage, par contre, l’écriture pourra être traitée de deux manières :

• Mémorisation et test des valeurs des paramètres. Et si modification, enregistrement automatique.
• Action de l’opérateur pour enregistrement des nouveaux paramètres.

La deuxième solution est à privilégier car elle permet :

• De ne pas surcharger l’automate en cas de nombreux paramètres
• Permettre à l’opérateur d’avoir une porte de secours s’il s’est trompé.

Un exemple de programme sous Codesys V3.5 pourra être téléchargé ici ultérieurement.

Organisation d’un programme Codesys V3.5 

Afin d’assurer une lecture plus simple du programme, l’organisation suivante peut être adoptée.

Ce n’est certainement pas la plus optimisée, mais elle reste compréhensive par n’importe quel automaticien.

Dans un premier temps, créer :

• Un dossier « Prog_data »
• Un dossier « Visu »

Dans le dossier Visu, seront placées toutes les visualisations crées, et dans le dossier Prog_data, tout le reste. Ceci évite d’avoir dans un premier temps une arborescence énorme et de perdre du temps en navigation entre les différents éléments.

Ensuite :

• Découper son programme en grandes fonctionnalités
• Créer un dossier pour chaque fonctionnalité créée.
• Crée une liste de variables globales qui contiendra toutes les variables qui devront être écrites depuis d’autres modules.
• Crée un PROG ou plusieurs PROG dans ce dossier pour y traiter les informations voulues.

Un exemple de structure de programme pourra être téléchargé ultérieurement ici.

Lors de la création des programmes, il peut être intéressant de créer des actions pour différencier toutes les fonctionnalités. Par exemple :
- ACT_INIT
- ACT_MASTER
- ACT_TRAITEMENT
- ACT_FONCTIONS

Cette arborescence pourra permettre de ne pas avoir à déclarer des variables pour toutes les fonctionnalités puisqu’elles seront déclarées dans le PRG (FB) qui contiennent les actions, ce qui simplifiera l’organisation des variables.

L’utilisation des Méthodes pourrait être décrit dans cette partie, mais ce ne sera pas le cas. La raison essentielle est que la notion de « Méthode » correspond plus à une approche informatique qu’à une approche automatisme. Ce point fera l’objet d’un autre article.

Tout en restant modulaire et évolutif, il faut que notre programme reste accessible à tout automaticien.