Discussion :

[Dave72]

Bonsoir,

mes questions vont sembler stupides et les réponses évidentes mais quand même.

Je suis chargé de projet en automatisme depuis 6 semaines et ma première mise en route ne s'est passée idéalement..
J'ai 15 ans de maintenance en automatisme derrière moi mais beaucoup moins en suivi de projet et conception.

J'aimerais savoir quelles sont vos habitudes et méthodes quand vous développez un programme via une analyse fonctionnelle. Vous optez pour le Grafcet? vous avez une méthode précise (affectation des variables, sécurité, modes de marche)? Avez-vous une bible de l'automatisme qui vous permet de piocher les infos qui vous manquent?

J'ai besoin d'acquérir une méthodologie rigoureuse qui laisse peu de place à l'inconnue, ni à l'approximation.

Par avance, merci.

[Blaze73200]

Bonjour,

Je m'excuse en avance pour les fautes ce n'est pas mon point fort).
Je pense pas qu'il n'y ai pas de bonne ou de mauvaise façon de faire. L'utilisation de GRAFCET dépendra de ton A.F. et du type de tâche que tu devras traiter. Mais aussi suivant les standard de ton entreprise (si elle en a) ou les spécifications du client. Il est toujours plus simple de nommé ces variable cela permet d'avoir un code clair et compréhensible. Il n'y a pas de grande bible a mon gout il faut chercher dans l'aide du constructeur et du logiciel. Mais aussi internet.
La sécurité que tu va programmé va dépendre de l’analyse de risque et du désir du client. Pour cela je te conseille d’utiliser un GEMMA (Guide d'Etude des Modes de Marche et d'Arrêt).

Après pour tout ce qui est mise en service partie automatisme elec. je te conseille de faire une platine ou tu pourra tester dans un premier temps ton programme. Puis une fois l'installation fini réaliser une MES de l'armoire et ensuite faire un test de toute les E/S pour voir si il n'y a pas d'erreur de câblage. Puis tester le fonctionnement des appareil 1 a 1 par la supervision et voir si tu as bien tes retour d'info (ouverture,fermeture de vanne, rotation moteur...) Et ensuite tester ton programme pas a pas en réel.

Après pour moi la meilleur école est l’expérience.

[Dave72]

Bonsoir,

je tenais (tardivement) à te remercier, ne serait-ce que d'avoir répondu. J'ai pu acquérir un standard de l'Automobile. Je poursuis mon bonhomme de chemin.

[domerun]

Bonjour, je voudrais enchérir la réponse que vous avez reçu précédement. Je suis d'accord avec les dires de M. Blaze et je voulais que vous sachiez qu'il existe pour la plus part des familles d'automates des logiciels ou programmes de simulation. Un tel logiciel pourrait vous permettre de simuler toutes les sequences nécessaires. N'oubliez pas les étapes à suivre suggérées auparavant.

Bonsoir et bonne chance !

[Dave72]

Bonsoir,

les simulateurs ont leurs limites (cycles rapides) mais tu as entièrement raison cependant.
Actuellement, je souffre d'un manque de méthode. Comme je suis issu de la maintenance, malgré la rigueur, j'ai été habitué aux programmes "freestyle" ce qui me déssert carrément aujourd'hui.

ça s'est ressenti de manière évidente durant la mise en route.

[_slos_]

Bonjour,

La méthode "freestyle" est la méthode la plus employée de nos jours, aussi appelée "La RACHE", cf. http://www.byatoo.com/la-rache/

Donc, pas de souci à avoir, elle finit par marcher... sur de petits projets...

Avant cette méthode, il y en avait d'autres, pompeusement appelées les méthodes de génie logiciel, que l'on avait adaptées aux spécificités de l'automatisme. Il y avait entre autres le fameux le cycle en V que toutes les boites mentionnaient dans leurs plaquettes.

Analyser c'est diviser un problème en autant de parties qu'il est nécessaire pour que ces sous-problèmes trouvent une solution.

Il faut décrire le système en langage naturel dans un premier temps afin de préciser les ensembles et sous-ensembles fonctionnels, leurs interactions, les modes de marches / arrêt, en intégrant les fonctions de diagnostic, d'IHM, de communication...

On obtient alors les spécifications fonctionnelles que les intervenants sur le projet doivent valider conjointement.
A ce stade on a défini ce qu'on doit obtenir, le "quoi".
Il est possible à partir de ce "quoi", de construire un cahier de tests qui permettra de valider que ce que l'on aura réalisé répond à la fonctionnalité attendue.

Il est possible de raffiner cette spécification, on obtiendra alors des spécifications fonctionnelles détaillées.
Par exemple en indiquant des algorithmes de traitement, en langage algorithmique ou sous la forme d'organigramme, des séquences de traitement, avec des graphes d'état ou du GRAFCET.

Une fois que l'on a analysé il faut concevoir la solution, c'est à dire créer une application mettant en œuvre des matériels, automates, DCS ou PC, et logiciels, IHM, base de données...

On établit durant cette phase les documents de conception qui contiennent la répartition des traitements dans les différentes unités, les interfaces avec la partie opérative, les IHM, la communication avec d'autres systèmes, etc...

Cette phase détermine le "comment". Cela peut prendre un temps certain et ça se fait normalement en amont du codage ou programmation.

Ensuite on code, dans un langage qui convient en fonction de ce que l'on doit coder ou dans celui imposé par le client, les outils ou la hiérarchie, en structurant ce code selon les principes de la programmation structurée et orientée objet.

Puis on teste les objets et fonctions unitairement, puis on procède aux tests d'intégration. Normalement, on n'a pas encore quitté le bureau d'étude... on recourt à la simulation soit avec des outils externes, soit avec un programme intégré spécifique.

On arrive sur site et on réalise les tests de synchronisation durant lesquels on s'assure que les E/S sont câblées là où on les attend, qu'elles fonctionnent comme prévu, sens, valeurs limites, échelle..., puis on vérifie le fonctionnement de chaque organe piloté, chaque sous-fonction, et enfin on démarre la chose. Tout est bien évidemment consigné dans les cahiers de tests créés pour l'occasion.

On sabre le Champagne avec le client ravi que tout ce passe bien dans la joie et la bonne humeur... enfin, on peut rêver...

On prévoira environ :

• 20 % d'analyse fonctionnelle,
• 40 % en conception,
• 20 % en programmation,
• 10 % de tests unitaires,
• 10 % de tests d'intégration.

C'était le principe... avant que commerciaux et financiers prennent le pouvoir dans les boites.

Cordialement,
Stéphane

[EvT Chess38]

A cela il faut prendre en compte que le client va te demander des modifications process une fois en mise en service...
Et malgré le fait d'avoir fait une analyse fonctionnelle avec eux, il ne voudra pas payer un centime pour ces modifications.

[Dave72]

Bonjour,

je suis bien content de recueillir vos avis.
Je rêve d'un programme quasiment parfait, tant sur le fond que sur la forme.

Mon premier problème est un souci de compétences. Comprenez que comme je n'étais pas pleinement automaticien avant, je n'avais pas le temps de m'y consacrer pleinement. J'ai plutôt été gardien de musée par le passé, le langage le plus évolué étant pl7-pro.

Là, j'ai débuté directe avec Unity Pro + Vijeo Designer et je dois manger beaucoup de Siemens dans un futur proche.

Le minimum pour moi, est de structurer convenablement mon programme. J'avoue que le naturel revient vite au galop et j'ai tendance à ajouter les contacts dans tous les sens.

[_slos_]

A cela il faut prendre en compte que le client va te demander des modifications process une fois en mise en service...
Et malgré le fait d'avoir fait une analyse fonctionnelle avec eux, il ne voudra pas payer un centime pour ces modifications.

C'est le jeu actuel.

Le client, ou son acheteur, écrit un cahier des charges le plus vague et léger possible en laissant un maximum de zones d'ombre afin d'obtenir un chiffrage le plus faible.

Le fournisseur, ou son commercial, établit sa proposition tout aussi vague en espérant pouvoir caser le maximum d'avenants.

Le résultat dépend de la méthode employée.

Si ton logiciel est bien conçu, c'est à dire que tu as posé les bonnes questions au bon moment et obtenu les bonnes réponses d'une part, et que d'autre part que l'architecture du système permet une évolution facile, il y aura des heurts mais ça devrait bien finir.

Sinon ben c'est la merde et tu es entre le marteau et l'enclume.

Bonne chance.

Cordialement,
Stéphane

[_slos_]

Bonjour,

je suis bien content de recueillir vos avis.
Je rêve d'un programme quasiment parfait, tant sur le fond que sur la forme.

Mon premier problème est un souci de compétences. Comprenez que comme je n'étais pas pleinement automaticien avant, je n'avais pas le temps de m'y consacrer pleinement. J'ai plutôt été gardien de musée par le passé, le langage le plus évolué étant pl7-pro.

Là, j'ai débuté directe avec Unity Pro + Vijeo Designer et je dois manger beaucoup de Siemens dans un futur proche.

Le minimum pour moi, est de structurer convenablement mon programme. J'avoue que le naturel revient vite au galop et j'ai tendance à ajouter les contacts dans tous les sens.

Bonjour,

Est-ce un gros projet que celui que vous devez gérer ?

Etes vous en SSII ?

Cordialement,
Stéphane

[Dave72]

Finalement, je n'ai pas été embauché. Mes connaissances ont péché. Le projet n'était pas difficile en soi mais le fait d'avoir 2 logiciels à assimiler en même temps m'a demandé du temps, trop de temps.

Je suis déçu car le travail me plaisait énormément. C'est comme ça. Il faut maintenant que j'arrive à faire financer des formations light ou de trouver des cours sur le net.

Merci encore pour votre aide.

[_slos_]

Finalement, je n'ai pas été embauché. Mes connaissances ont péché. Le projet n'était pas difficile en soi mais le fait d'avoir 2 logiciels à assimiler en même temps m'a demandé du temps, trop de temps.

Je suis déçu car le travail me plaisait énormément. C'est comme ça. Il faut maintenant que j'arrive à faire financer des formations light ou de trouver des cours sur le net.

Merci encore pour votre aide.

Bonjour Dave72,

Navré pour toi.

Si ce travail te plaît énormément il faut persévérer.

C'est un travail passionnant mais les conditions d'exercice sont devenues plutôt difficiles.
Cependant c'est un constat assez général...

Cordialement,
Stéphane

[oliviercaen14@free.f]

Bonjour Dave72,

Navré pour toi.

Si ce travail te plaît énormément il faut persévérer.

C'est un travail passionnant mais les conditions d'exercice sont devenues plutôt difficiles.
Cependant c'est un constat assez général...

Cordialement,
Stéphane

Bonjour Dave

Je rejoins l'avis de stéphane
Il faut que tu positives cette expérience et que tu persévères si tu aimes ce travail

Pour revenir à ta question de départ, il est difficile ici de te donner une méthode globale en quelques lignes.

Par rapport à ton analyse personnelle :

"Mon premier problème est un souci de compétences. ........ le langage le plus évolué étant pl7-pro."

Si tu t'accroches et que la lecture assidue de documentation technique ne te rebute pas, tu dois pouvoir
combler ce retard
Bien sur, rien ne remplace l'expérience et la manipulation sur différents équipements

"Le minimum pour moi, est de structurer convenablement mon programme. J'avoue que le naturel revient vite au galop et j'ai tendance à ajouter les contacts dans tous les sens."

Ce point est crucial, il faut apprendre à structurer ta démarche et jeter aux oubliettes (je sais ... c'est dur ..)
les mauvaises habitudes

D'une manière générale, quelque soit la taille de ton projet il faut suivre (scrupuleusement) les étapes suivantes :
- définir clairement le besoin ( ça parait évident , mais c'est trés souvent survolé, et de nombreux problèmes en mise en service proviennent d'une incomprehension entre le client et le prestataire )
- Découper le projet en ensembles et sous-ensembles fonctionnels
- Ecrire, partager et valider l'analyse fonctionnelle
(Plus cette analyse sera détaillée, plus le travail de programmation sera simple et rapide)
- Finaliser et valider les schémas électriques
- réaliser une analyse organique pour les fonctions complexes

C'est seulement une fois ces différentes étapes validées que le travail de programmation commence

- programmer les différents équipements en adoptant le standard du client ou à défaut son standard personnel
(dans tous les cas, adopter une standard simplifie grandement la programmation et les essais)

- ecrire et faire valider les cahiers de tests, on doit retrouver l'ensembles des tests unitaires à réaliser
==> Entrées / sorties (globalement la partie électrique)
==> Paramétrages des différents équipements (Variateurs / codeurs / cartes spécifiques .. )
==> commandes unitaires dans les différents modes de marche
==> Mode automatique général en détaillant les différentes possibilitées
==> défauts et reprise aprés disparition du défaut
==> Apporter une attention toute particulière aux différentes fonctions de sécurité


Une erreur de débutant consiste à penser que le travail est terminé quand le mode automatique répond globalement au besoin du client, mais le test individuel de chaque défaut et vérifier la reprise normale du mode automatique est un travail lourd et fastidieux mais garantie la serennité du client après la période de mise en service

Pour finir, il y a toujours des demandes de dernière minute faites par le client durant les éssais
Il faut quelque soit la complexité de cette demante (même pour les plus simples) éviter de coder directement cette nouvelle fonction sans avoir au préalable couché sur le papier le besoin en l'intégrant dans l'architecture globale

de multiples petites modifications faites sans prendre un minimum de recul amènent souvent à construire une usine à gaz qui à la longue rend le programme de plus en plus complexe à comprendre et à faire évoluer

Si tu as besoin de plus de renseignements, on pourra échanger plus directement par email

Bon courage

Cordialement

Olivier

[Dave72]

Bonjour à tous,

je vous remercie pour vos messages et encouragements.
Il s'est passé pas mal de choses depuis ma dernière mission. Le travail est venu à moi avec 2 à 4 coups de fils/semaines depuis septembre.

J'ai finalement été recruté par un prestataire en ingénierie et assistance techniques aux études et projets industriels. Je suis en poste depuis 3 semaines comme automaticien.
J'ai financé une formation sur siemens Step7 (vu la catastrophe avec Pôle Emploi, la colère m'a pris).
Là, c'est une mission un peu spéciale, je me retrouve à programmer des automates "propriétaires" en langage typé assembleur. C'est une sacrée gymnastique).

Bref, ça roule!

A bientôt!