E03.65.036.G - FR - REGLES DE CONCEPTION ET DE REALISATION DES LOGICIELS

PSA PEUGEOT - CITROËN
E03.65.036.G
Normes Biens d'Equipement
ICS : 25.040.01, 35.080, 35.240.50

MACHINES ET INSTALLATIONS INDUSTRIELLES
AUTOMATISME
REGLES DE CONCEPTION ET DE REALISATION DES LOGICIELS
Page 1/40
Sans restriction d'utilisation
AVANT-PROPOS
A la date de publication du présent document, il n’existe pas de norme internationale, européenne ou française
traitant de ce sujet.
Rédacteur Vérificateur Approbateur
Jean Luc MARCHETTI Voir la liste des intervenants Fréderic TOURNUT

DTI/DITV/ISP/IMAI/AUT/ATA/MAU DTI/DITV/ISP/IMAI/AUT/ATA/MAU
Date Signature Date Signature Date Signature

09/01/2008 09/01/2008
OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

REGLES DE CONCEPTION ET DE REALISATION DES LOGICIELS E03.65.036.G 2/40
HISTORIQUE
Indice Date Nature des modifications
OR 01/01/1999 Version de la norme lors de la reprise sous GEODE
A 02/09/2003 Mise à jour du document
B 14/03/2007 Refonte complète du document
C 09/01/2008 Ajout du chapitre "impact du programme sur la qualité produit"
INTERVENANTS
Les personnes suivantes ont participé à la rédaction et/ou à la vérification de cette norme :
DTI/DITV/ISP/IMAI/AUT/BOME Philippe FORET
DTI/DITV/ISP/IMAI/AUT/BOMG Bernard CHATEAU JAUNE
DTI/DITV/ISP/IMAI/AUT/EMFE Fabien ATTAFI
DTI/DITV/ISP/IMAI/AUT/FERV Alain ETCHEVERRY
DTI/DITV/ISP/IMAI/AUT/PEMO Eric BOEUF, François WIATROWSKI
DTI/DITV/ISP/IMAI/AUT/ATA/VSA Gérard GREMAUD
DTI/DITV/RHN/NCF Sylvain BIGOT
SOMMAIRE
1. OBJET ET DOMAINE D’APPLICATION 4
2. DOCUMENTS DE REFERENCE 5
2.1. NORMES 5
2.1.1. Normes PSA 5
2.1.2. Normes Externes 5
2.2. REGLEMENTATIONS 5
2.3. AUTRES DOCUMENTS 5
2.4. EXPRESSION SUR DOCUMENTS 5
3. TERMINOLOGIE ET DEFINITION 5
3.1. DEFINITIONS 5
3.2. SIGLES 5

4. REGLES SYSTEME 6
4.1. DEBORDEMENT DES CAPACITES DE CALCUL 6
4.2. REPRISE APRES COUPURE ALIMENTATION 6
5. REGLES FONCTIONNELLES 7
5.1. DECOUPAGE FONCTIONNEL 7
5.1.1. Traitement de la sécurité 7
5.1.2. Traitement de la mise en énergie 9
5.2. MARCHES D'EXPLOITATION 10
5.2.1. Aide a la remise en production 10
5.2.2. Les commandes manuelles 10
5.3. INFORMATIONS D'EXPLOITATION 11
5.4. TRAITEMENT DU DIAGNOSTIC 11
5.4.1. surveillance des événements 11
5.4.2. Classification des événements 12
5.4.3. Mémorisation des événements 12
5.4.4. Filtrage des événements 13
5.4.5. Réaction de l'automate sur le process 13
5.4.6. Signalisation des événements 14
5.5. SURVEILLANCE DES CAPTEURS ET ACTIONNEURS 14
5.6. IMPACT DU PROGRAMME SUR LA QUALITE PRODUIT 14
6. REGLES DE CONCEPTION 16
6.1. LA NOTION DE TACHES 16
6.1.1. Temps de réaction d'un système automatisé 17
6.2. ORGANISATION DE LA TACHE PRINCIPALE 18
6.3. LA CONCEPTION MODULAIRE 20
6.4. LA MAINTENABILITE 21
6.5. CHOIX DES LANGAGES 23
7. REGLES DE REALISATION 24
7.1. LE GRAFCET (SFC) 24
7.1.1. Structure générale 24
7.1.2. Transitions 24
7.1.3. Etape initiale 24
7.1.4. Etape de fin 24
7.1.5. Utilisation des bits d'étape 25
7.1.6. Parallélisme structural 25
7.1.7. Parallélisme interprété 27
7.1.8. Saut de séquence 27
7.1.9. Fonctions de contrôle 28
7.1.10. Synchronisation des graphes 29
7.2. LANGAGE A CONTACTS (LD) 29
7.2.1. Structure générale 29
7.2.2. Formes types des équations de surveillance des événements 32
7.2.3. Programmation d’un processus cyclé en langage à contacts 34
7.2.4. Equations types de commande des sorties actionneurs 36
7.2.5. Autres équations type 38
7.3. LE LANGAGE TEXTUEL (ST) 38
7.4. LE REPERAGE DES OBJETS PROGRAMMES 40

1.OBJET ET DOMAINE D’APPLICATION

Ce document énonce les règles de conception et de réalisation applicables aux logiciels des automatismes
programmés, quel que soit le matériel utilisé dans les usines du Groupe PSA Peugeot Citroën. Il sert de référence
pour l’élaboration de documents complémentaires et pour l’élaboration de Procédures d’Exécution des Essais
spécifiques à un type de matériel.
Ce document définit un certain nombre de règles favorisant l’obtention des objectifs de qualité, coût et délai lors de
la conception et la réalisation d’un logiciel d’automatisme.
Ces règles et principes sont motivés par la volonté :
• d’harmoniser les solutions de programmation et d’organisation programme,
• de garantir le comportement dynamique des programmes (performance, fiabilité, déterminisme, …),
• d’atteindre un niveau de lisibilité et de maintenabilité maximal,
• de favoriser la portabilité et la standardisation de tout ou partie des applications.
Pour une meilleure lisibilité, ce document est organisé selon les trois phases de déroulement d’un projet
d’automatisme :
• L’analyse fonctionnelle détaillée constitue le véritable cahier des charges spécifiques des phases de
conception et de réalisation des logiciels d’automatismes. Le chapitre «Règles fonctionnelles» y ajoute un
certain nombre de règles de l’art générales qu’il convient de respecter dans toute application.
• La phase conception (ou analyse organique) consiste à répartir judicieusement les différentes fonctions
d’automatisme à l’intérieur des structures de programme et de données. Le chapitre «Règles de conception»
en énonce les principales règles «grammaticales».
• La phase réalisation (ou codage) doit également se dérouler en respectant les règles «d’orthographe» du
chapitre «Règles de réalisation».
La conformité de ce que fait le programme par rapport à ce qui a été défini durant les analyses
fonctionnelles (satisfaction du critère de capacité fonctionnelle) ne sera cependant pas garantie par la
seule application des règles ci-après. Les essais en simulation de partie opérative et/ou sur site restent
donc de vigueur afin de garantir l’obtention des fonctionnements spécifiés.
Les textes bleus en italique constituent des informations destinées à accompagner les règles.
1. Les textes noirs précédés d'un numéro constituent les règles. Chacune d'elle doit être appliquée et
autocontrôlée par le fournisseur intégrateur.
Un support de formation est associé à ce document.
2. Le contrôle de la bonne application de ce document est à réaliser en utilisant le Guide GE03 047G et l'outil de
contrôle Qualimètre (outil logiciel de contrôle automatique des programmes automates tous constructeurs).
Les termes utilisés dans ce document sont définis dans le référentiel technique transversal : E03.65.015.G.
3. Certaines règles, dépendantes du type de matériel ou des différents ateliers logiciels constructeurs utilisés, sont
énoncées dans des référentiels (appelés annexes constructeurs dans le reste du document) et doivent être
respectées :
AUT-STD-524 : automates SCHNEIDER,
AUT-STD-525 : automates SIEMENS.

2.DOCUMENTS DE REFERENCE
2.1.NORMES
2.1.1.NORMES PSA
E03.65.015.G Machines et installations industrielles – Automatisme – Référentiel technique transversal.
E03.65.038.G Machines et installations industrielles – Automatisme – Règles de rédaction de l'analyse
fonctionnelle, de l'analyse organique et du manuel opérateur.
GE03-047G Guide de suivi et de réception des logiciels d'automates programmables.
2.1.2.NORMES EXTERNES
CEI 61131-1 Automates programmables - Partie 1 : informations générales.
CEI 61131-2 Automates programmables - Partie 2 : spécifications et essais des équipements.
CEI 61131-3 Automates programmables - Partie 3 : langages de programmation.
2.2.REGLEMENTATIONS
Sans objet
2.3.AUTRES DOCUMENTS
AUT-STD-524 Annexe à la norme E03.65.036.G pour automates SCHNEIDER.
AUT-STD-525 Annexe à la norme E03.65.036.G pour automates SIEMENS.
2.4.EXPRESSION SUR DOCUMENTS

Sans objet
3.TERMINOLOGIE ET DEFINITION
Un dictionnaire (glossaire) des principaux termes et leurs définitions utilisés au sein de la Direction Technique et
Industrielle, dans le domaine des automatismes, est fournie dans la norme E03.65.015.G.
3.1.DEFINITIONS
Sans objet
3.2.SIGLES
Sans objet

4.REGLES SYSTEME
4.1.DEBORDEMENT DES CAPACITES DE CALCUL
4. La modification de la valeur d'une donnée utilisée dans le programme automate, à partir des entrées (réseaux,
automate) ou du terminal opérateur, ne doit provoquer aucune anomalie ou incident tel que débordement
arithmétique, dépassement chaînes de caractères, dépassement chien de garde, …
• Cette valeur doit impérativement être filtrée par rapport aux bornes admises avant utilisation,
• Le paramétrage des valeurs de bornes doit être réalisé en priorité dans l'application du terminal, si celui-ci
le permet,
• L'opérateur doit être averti que sa saisie n'a pas été prise en compte lorsque celle-ci est hors bornes.
Exemple : affichages séparés de la consigne et de la valeur prise en compte.
5. Les traitements de type calculs doivent tenir compte des capacités de l'automate afin de maîtriser les
débordements (bornes de calcul, division par 0, …).
6. Toute anomalie ou incident provoqué par un débordement de capacité doit être signalé par un message
(système ou applicatif) acquittable par l'opérateur.
Voir aussi l'annexe par constructeur.
4.2.REPRISE APRES COUPURE ALIMENTATION

7. La perte de l’alimentation de l’automate doit être maîtrisée afin de permettre un redémarrage de l’installation
dans les meilleures conditions possibles. La sauvegarde du contexte avant coupure secteur s’avère
nécessaire dans la majorité des cas.
8. Deux solutions sont autorisées :
• utiliser des données sauvegardées sur coupure secteur,
• en fin de tâche, transférer les données liées au contexte, non sauvegardées sur coupure secteur, dans
une zone sauvegardée, puis les restituer en début de tâche.
9. Lorsque c'est possible, il faut programmer une reconfiguration automatique du système, selon le matériel
utilisé (reconfiguration de cartes intelligentes, …).
Le rechargement du programme signifie souvent la remise dans un état par défaut de toutes les données
(compteurs, mémoires, temporisation, grafcet, …) :
10. Une solution doit être mise en œuvre pour faciliter ces opérations :
• restitution d'un fichier de données,

• accès au recalage depuis le terminal opérateur,
• procédure d'initialisation dans le manuel opérateur,
• ...
Les annexes constructeurs précisent les actions programmées à prévoir pour faciliter les reprises après coupure
secteur.

5.REGLES FONCTIONNELLES
Ces règles de l'art s'appliquent en complément des prescriptions du cahier des charges et de l'analyse
fonctionnelle détaillée.
5.1.DECOUPAGE FONCTIONNEL
5.1.1.TRAITEMENT DE LA SECURITE
5.1.1.1.Autocontrôle à la mise en service
11. Le bon fonctionnement de tous les relais et contacteurs utilisés dans les parties du système de commande
relatives à la sécurité doit être testé à la mise en service de la machine.
Cet autocontrôle peut être fait par programme au moyen d'une sortie automate pilotant un relais de test des
sécurités. Ce relais permet de couper l'alimentation des relais à contrôler. La retombée du relais de test doit
être contrôlée après le démarrage.
12. La temporisation de test des sécurités au démarrage ne dépasse en aucun cas une seconde.
13. Le périmètre du relais de test des sécurités doit correspondre à celui de l'organe de mise en service.
Exemple : pour un automate gérant deux îlots dont la mise en service est indépendante, un relais de test par
îlot est utilisé.
14. Même si l'autocontrôle est commun à plusieurs composants, le diagnostic de chaque composant doit être
réalisé individuellement, conformément au chapitre diagnostic.
Exemple d'équation de test à la mise en service : l'appui sur le bouton de mise en service active une sortie
automate qui coupe l'alimentation de tous les relais à tester.
Front montant
Fin du test organe de mise
démarrage en service Tempo test
P sécurités au
démarrage
Relais test
sécurités au
démarrage
Front montant Fin tempo Relais test

organe de mise test sécurités sécurités au
Fin du test
en service au démarrage démarrage
démarrage
P
Relais test
sécurités au
démarrage
Retour relais Relais

test sécurités Relais Relais Organe de mise Fin du test
validation Relais
au démarrage sécu 1 sécu 2 hors service démarrage
GS GS
Fin du test
démarrage
Relais test
sécurités au Fin du test Test démarrage
démarrage démarrage OK

Dans cet exemple, dès que tous les relais sont vus au repos, le test est considéré comme bon.
Si, au bout d'un temps enveloppe, un ou plusieurs relais restent actifs :
- le test est arrêté,
- un défaut est signalé,
- la mise en service est impossible,
- il faut un nouvel appui sur le bouton de mise en service pour réaliser un nouveau test.
5.1.1.2.Autocontrôle à chaque sollicitation
15. Le bon fonctionnement de chaque relais et contacteur utilisé dans les parties du système de commande
relatives à la sécurité doit être testé à chaque sollicitation.
Cet autocontrôle peut être fait par programme.
16. Le défaut détecté ne peut être acquitté que si le relais est vu au repos.
17. La temporisation contrôlant le fonctionnement du relais ne dépasse en aucun cas une seconde.
Exemple d'équation de contrôle d'un relais d'arrêt d'urgence :
Défaut
Bouton arrêt Relais arrêt relais arrêt
d'urgence d'urgence d'urgence
Tempo
contrôle
relais
Relais test
sécurités au Bouton arrêt Relais arrêt
démarrage d'urgence d'urgence
Fin tempo test Relais arrêt

au démarrage d'urgence
Défaut relais Bouton

arrêt d'urgence acquittement
Relais arrêt
d'urgence
Dans cet exemple, si au bout du temps enveloppe :

- le bouton d'arrêt d'urgence est appuyé et le relais n'est pas retombé,
- le bouton d'arrêt d'urgence n'est pas appuyé et le relais est retombé,
- la fin de test du relais est arrivée et le relais n'est pas retombé,
un défaut relais arrêt d'urgence est signalé et auto maintenu jusqu'à l'acquittement. L'acquittement n'est possible
que si le relais est retombé et que la cause de défaut a disparu.
5.1.1.3.Autocontrôle des groupes de sécurité

18. Pour chaque relais de groupe de sécurité, et si une fonction d'autocontrôle est prévue dans l'analyse
fonctionnelle, une équation du programme automate réalise l'autocontrôle des sécurités du groupe. Une sortie
automate pilote un relais de validation du groupe (KAVS..).

Exemple de gestion d'une sortie relais validation :

Test Bouton Relais arrêt Défaut Défaut
démarrage Validation arrêt relais arrêt relais
d'urgence
OK GS père d'urgence d'urgence GS Validation GS
19. Pour chaque groupe de sécurité défini dans l'analyse fonctionnelle, un bit "Groupe de sécurité OK" valide les
traitements dépendant de ce groupe de sécurité.
Exemples de gestion du bit "groupe de sécurité OK" :
Groupes de Retour relais Retour Groupe de
sécurités pères OK Validation GS validation GS relais GS sécurité OK
5.1.2.TRAITEMENT DE LA MISE EN ENERGIE

20. Les conditions initiales et permanentes de chaque groupe d'énergie interviennent dans l'équation programmée
de la sortie automate de validation du groupe d'énergie (KAVL, KAVP...).
Ces conditions sont listées dans le tableau description des groupes d'énergie du document E03.65.038.G
21. Les contrôles de présence tension d'alimentation des EPO sont intégrés dans cette équation.
Exemple : présence 24V d'alimentation des électrovannes.
22. Les traitements câblés sont reproduits dans l'équation programmée de la sortie automate de validation du
groupe d'énergie (KAVL, KAVP...)
23. Le contrôle du bon fonctionnement à chaque sollicitation des relais de commande et de validation du groupe
d'énergie intervient dans l'équation programmée de la sortie automate de validation du groupe d'énergie
(KAVL, KAVP...).
24. Le contrôle du bon fonctionnement à chaque sollicitation des composants d'interface homme machine de mise
en/hors énergie du groupe d'énergie intervient dans l'équation programmée de la sortie automate de validation
du groupe d'énergie (KAVL, KAVP...).
25. Le contrôle du bon fonctionnement à chaque sollicitation des capteurs et pré actionneurs du groupe d'énergie
intervient dans l'équation programmée de la sortie automate de validation du groupe d'énergie (KAVL,
KAVP...).
Exemple de solution :
Eléments de
Conditions Conditions Présence Relais GE conduite GE Capteurs GE
initiales permanentes tension EPO OK OK OK Validation GE
Groupe d'énergie OK
26. Pour chaque groupe d'énergie défini dans l'analyse fonctionnelle, un bit "Groupe d'énergie OK" valide les
traitements dépendants de ce groupe d'énergie. Il tient compte de l'état du relais de validation du groupe
(KAVL, KAVP...).
Exemple de solution :
Groupes d'énergies Retour relais Retour Groupe d'énergie

pères OK Validation GE validation GE relais GE OK

5.2.MARCHES D'EXPLOITATION
27. Un bit programmé signale chaque état des marches d'exploitation prévues dans l'analyse fonctionnelle.
Exemples : AIAUTO2X : arrêt immédiat de la marche auto du GMM2
MDAUTO1X : mode auto GMM1 sélectionné
MRNORM23 : marche normale entité 23
MRRODA34 : marche rodage entité 34
MRAUTO2X : marche automatique GMM 2
5.2.1.AIDE A LA REMISE EN PRODUCTION

28. Le programme doit traiter toutes les informations (position incohérente du mouvement par rapport à l'état
attendu par le processus, conditions manquantes, …) prévues dans l'analyse fonctionnelle détaillée pour aider
les opérateurs à effectuer les opérations de remise en production (initialisation, recalage logique ou physique,
évacuation pièce mauvaise, …).
Ces informations permettent de générer :
• Les messages d'aide à la conduite,
• Les messages de diagnostic,
• Les données d'animation des pages du terminal opérateur prévues dans les chapitres "description
terminal opérateur" et "graphe d'aide à la conduite" de l'analyse fonctionnelle détaillée.
• Les signalisations lumineuses pour les installations sans terminal opérateur. Dans ce cas la
signalisation doit respecter la séquence de remise en production prévue dans l'analyse fonctionnelle.
5.2.2.LES COMMANDES MANUELLES

29. Le programme doit permettre aux commandes manuelles des mouvements d'être réactives et sécurisées.
Pour cela, il doit traiter les critères suivants :
• deux touches ou boutons poussoir (repos/travail) d'un même mouvement, actifs simultanément, ne doivent
pas provoquer de commande et doivent annuler celle en cours,
• plusieurs appuis successifs sur une même touche ou un même bouton poussoir ne doivent pas être
mémorisés (pas de commande sans appui sur une touche ou un bouton),
• une touche ou bouton poussoir ne peut être actif que si la page de sélection du mouvement sur le terminal
opérateur est affichée et rafraîchie,
• si une touche ou un bouton poussoir est bloqué ou maintenu, un changement de page mouvements ou de
sélection de mouvement sur le terminal opérateur ne doit pas provoquer de commande.
30. Le programme ne doit pas dégrader :
• le temps de réaction système d'une touche du terminal opérateur. Dans tous les cas, le temps de réaction
(temps qui s'écoule entre l'appui sur une touche et la réaction attendue) d'une touche ou d'un bouton
poussoir doit être inférieur à la seconde,
• le temps d'affichage des pages du terminal opérateur.
31. Le programme doit fournir les informations suivantes aux composants (terminal opérateur, bouton poussoir
lumineux, …) permettant la commande manuelle :
• nom du mouvement,
• autorisation mouvement sens repos (sécurités mécaniques et opérateur présentes et pas de défaut
sécurités),

• autorisation mouvement sens travail (sécurités mécaniques et opérateur présentes et pas de défaut
sécurités),
• mouvement attendu sens repos pour reprise auto (aide à la remise en cycle),
• mouvement attendu sens travail pour reprise auto (aide à la remise en cycle),
• événement sur l'actionneur (défaut, alarme, alerte, arrêt, …).
• position atteinte sans événement sens repos (état repos),
• position atteinte sans événement sens travail (état travail),
• commande en cours sens repos (commande repos présente et position non atteinte),
• commande en cours sens travail (commande travail présente et position non atteinte),
• présence d'une demande venant du processus sens repos (manuel guidé),
• présence d'une demande venant du processus sens travail (manuel guidé),
5.3.INFORMATIONS D'EXPLOITATION
32. Afin de garantir la bonne transmission des données échangées avec un équipement tiers (pouvant être
furtives), celles-ci doivent être en priorité de type "demande / compte rendu" (échanges "carrés"). A défaut,
elles doivent être considérées comme des entrées / sorties pour lesquelles les règles du paragraphe "la notion
de tâche" (ci-après) sont appliquées : leur durée doit être supérieure à 2 temps de réaction automate.
Par exemple, l'API envoie une demande de remise à zéro à l'équipement tiers, il reçoit un compte rendu signalant
la remise à zéro effective.
5.4.TRAITEMENT DU DIAGNOSTIC
33. L'ensemble des événements à signaler, issus du diagnostic de la partie opérative (capteurs, actionneurs,
produits, pièces, …) et du diagnostic du système (batteries, piles, réseau d'entrées sorties déportées, cartes
spécialisées, temps de cycle automate, communication, …), doit être traité selon le phasage suivant :
• surveillance de l'événement,
• classification de l'événement,
• mémorisation (si besoin) de l'événement,
• filtrage de l'événement,
• réaction de l'automate programmable pour les événements de type DI, DD (coupure des sorties, inter
verrouillage, …),
• signalisation de l'événement (message de diagnostic, verrine, …).
• aide à l'opérateur pour la remise en production de l'installation (message d'aide à la conduite,…).
34. Si l'affichage des événements système n'est pas traité par le système, il doit être traité selon le phasage ci-
dessus.
35. Si les événements système sont traités par le système et si le paramétrage de la réaction de l’automate est
accessible au programmeur, ces événements et les réactions associées doivent être pris en compte et prévus
dès le début de la conception du programme.
5.4.1. SURVEILLANCE DES EVENEMENTS

36. Chaque événement doit être surveillé et diagnostiqué par l'automate programmable.
37. Les surveillances suivantes sont systématiques (règles de l'art) :

• le bon fonctionnement à chaque sollicitation prévue de chaque composant électromécanique (capteur,

contacteurs, relais, variateurs, organes de commande opérateurs…), y compris les capteurs de présence
pièces,
Chaque entrée automate est contrôlée dans les deux états logiques.
• la cohérence des capteurs d'un même actionneur :
• capteurs repos et travail non actifs simultanément,
• pas de changement d'état du capteur en l'absence d'une commande sur l'actionneur,
• le déroulement des mouvements et des actions dans un temps imparti (temps enveloppe),
• les états des équipements tiers en interface,
• le bon déroulement des échanges avec les équipements tiers,
• les informations système.
5.4.2.CLASSIFICATION DES EVENEMENTS

38. Chaque événement doit être affecté dans une des classes (AE, AL, AF, AR, AT, AO, AM, AV, DI, DD) prévues
par la norme E03.65.038.G, en respectant les règles de classement définies dans cette norme.
39. La classe de chaque événement doit être conforme à l'analyse fonctionnelle.
5.4.3.MEMORISATION DES EVENEMENTS

40. Un événement doit être mémorisé si sa classe (AL, DI, DD) nécessite un acquittement, selon la norme
E03.65.038.G.
41. Un événement trop bref pour être détecté par la partie commande doit être mémorisé même si sa classe ne le
nécessite pas.
Exemples : alerte niveau bas mémorisé jusqu'à niveau moyen, capteur tardif mémorisé jusqu'à demande inverse, …
42. La mémorisation de l'événement doit être traitée par l'équation de surveillance de l'événement et pas par le
terminal opérateur.
43. L'acquittement de l'événement doit être traité dans l'équation de surveillance de l'événement.
44. L'acquittement ne doit être possible que si la cause de l'événement a disparu.
Exemples d'équations de surveillance d'événements :
Evénement mémorisé car il doit être acquitté alarme

Cause de l'alarme
Bouton
Alarme d'acquittement
Evénement mémorisé car il peut être furtif

Commande Fin de Capteur
mouvement mouvement tardif
Temps
enveloppe
Capteur Commande
tardif inverse

5.4.4.FILTRAGE DES EVENEMENTS

45. Durant le démarrage de l'automate les événements doivent être filtrés jusqu'à la fin d'une temporisation
paramétrable.
46. Un événement fils et un événement père ne doivent pas être affichés simultanément. Les événements 'fils'
doivent être filtrés.
Exemple : un défaut «manque tension d'alimentation des entrées» ne doit pas provoquer de «disparition
capteur» pour chaque capteur
47. Le filtrage d'un événement doit être fait dans l'équation de surveillance de l'événement, en insérant les
conditions nécessaires.
Exemple : présence tension carte d'entrée et pas capteur attendu = défaut capteur.
48. Les conditions de filtrage d'un événement ne sont prises en compte qu'à l'apparition de l'événement.
Autrement dit, lorsque l'événement est déjà présent lors de l'apparition des conditions de filtrage, celles-ci sont
inopérantes.
49. Les événements liés à une entrée automate doivent être filtrés par le bon fonctionnement du module d'entrée
correspondant.
Exemple de filtres : disjoncteur de protection du module, entrée présence tension, donnée système signalant
l'alimentation OK et/ou le défaut du module…
50. Les événements liés aux EPO doivent être filtrés par l'état OK des groupes de sécurité et d'énergie dont ils
dépendent.
51. Les événements liés à une marche doivent être filtrés par la marche de l'élément correspondant.
Exemple : la non retombée d'un capteur de présence pièce est filtrée par la marche de l'entité à laquelle il
appartient.
5.4.5.REACTION DE L'AUTOMATE SUR LE PROCESS

52. Les réactions du programme automate aux événements DI, DD doivent être conformes à celles prévues dans
l'analyse fonctionnelle.
53. L'un des deux types de réactions ci-dessous doit être programmé pour chaque événement :
• l'arrêt immédiat qui peut être obtenu par :

o coupure d'un groupe de sécurité => désactivation de la sortie KAVS..,
Exemple : appui sur arrêt d'urgence.
o coupure d'un groupe d'énergie => désactivation de la sortie KAVL.., KAVH..,
Exemple : perte du manostat de contrôle pression pneumatique.
o coupure d'une marche,
Exemple : perte de la position auto du commutateur manu / auto.
o coupure d'une information en interface,
Exemple : la disparition d'un capteur provoque la coupure d'une autorisation de travail robot.
o coupure de la commande d'un EPO,
Exemple : perte de la sécurité mécanique.
• l'arrêt différé qui peut être obtenu par la coupure d'une marche en arrêt cycle, arrêt fin de cycle, arrêt pièce,
...
La notion d'arrêt différé décrite ci-dessus n'a pas de rapport avec l'arrêt de catégorie 1 au sens de la norme
EN 60-204. Fonctionnellement, l'arrêt de catégorie 1 est considéré comme un arrêt immédiat.

5.4.6.SIGNALISATION DES EVENEMENTS

54. Chaque événement surveillé doit être signalé à l'opérateur par un moyen adapté, conformément à ce qui a été
défini dans l'analyse fonctionnelle :
• verrine,
• message de diagnostic sur terminal opérateur,
• message d'aide à la conduite sur terminal opérateur,
• synoptique,
• graphisme animé,
• …
55. Le message de diagnostic doit être conforme à ce qui a été défini dans l'analyse fonctionnelle.
56. Le champ "description" (voir chapitre construction des messages de diagnostic de la norme E03.65.015.G) du
message de diagnostic doit être rédigé dans la langue du pays destinataire du programme.
57. Pour chaque élément du découpage fonctionnel et chaque classe d'événement, le programme produit une
information signalant la présence d'au moins un événement de la classe dans l'élément du découpage
fonctionnel.
Exemples : BR1AE32 : bit de regroupement des alertes de l'entité 32,
BR1DI01 : bit de regroupement des défauts immédiats de l'entité 01.
Cette information est utilisée pour animer les pages des terminaux opérateurs, gérer les verrines ou/et être
envoyée aux systèmes informatiques de surveillance des installations.
5.5.SURVEILLANCE DES CAPTEURS ET ACTIONNEURS

58. Le bon fonctionnement de tous les capteurs et actionneurs doit être contrôlé à chaque sollicitation.
59. La surveillance des capteurs doit être traitée dans la tâche adéquate conformément au chapitre "Règles de
conception".
60. Le rebond d'un capteur doit être détecté et rester sans effet sur la partie opérative (aucune réaction ou
évolution).
61. Lorsque l'état d'un capteur contrôlant le passage d'un mobile doit être mémorisé, la mémoire doit être affichée
sur le terminal opérateur et une fonction de mise à jour de cette mémoire depuis le terminal opérateur doit être
prévue.
5.6.IMPACT DU PROGRAMME SUR LA QUALITE PRODUIT

La réalisation du programme peut, si elle ne répond pas à des règles strictes, produire des aléas susceptibles
de générer un risque grave pour la qualité du produit.
Par exemple, pour une machine de vissage, laisser partir dans le flux aval une pièce qui n'a pas été vissée.
La qualité du produit dépend essentiellement de la bonne synchronisation entre les différents intervenants sur
une installation : automate, machine, équipements tiers, systèmes informatiques, opérateurs,…
Chaque action sur le produit (travail robot, travail opérateur, opération machine) peut être mémorisée par
l'automate, c'est une mémoire d'état.
Une attention toute particulière doit être portée sur l'application des règles ci-dessous qui devront, de plus,
faire l'objet d'un contrôle systématique.
62. L'utilisation de mémoires d'état liées au produit doit être limitée au strict nécessaire.
63. Lorsque la pièce est évacuée, toutes les mémoires d'état liées à cette pièce sont remises à zéro, y compris
celles mémorisées par les équipements tiers en interface (robots, baies de vissage, de soudage…). Voir §
7.1.3 et § 7.1.4.

64. Lorsque des plots mémoires embarqués ou des liaisons informatiques sont mis en œuvre, les buffers de
réception, d'émission et de travail font partie des mémoires d'état liées à la pièce et doivent être remises à zéro
lorsque la pièce est évacuée.
65. les conditions d'effacement de ces données doivent être définies pour toutes les marches de l'installation
(normale, dégradées, manuelle…) et pour toutes les procédures particulières et procédures de reprise, y
compris les cas de reprise après coupure secteur, reprise à froid, microcoupure.
66. Une nouvelle pièce ne peut être introduite que si toutes les données de la pièce précédente sont remises à
zéro.
67. Il faut prévoir la possibilité de modifier les mémoires d'état sur le terminal opérateur, pour recaler la logique
programmée par rapport à l'état physique de l'installation et du produit (attention à la resynchronisation des
échanges avec les équipements tiers) Pour des cas particuliers (opération faite obligatoirement en
automatique, process classé sécurité…), cette opération peut être protégée par mot de passe.

6.REGLES DE CONCEPTION
6.1.LA NOTION DE TACHES
Les règles énoncées dans ce chapitre ont un impact direct sur le dimensionnement des automatismes et
notamment des unités centrales des automates.
Il existe trois types de tâches :
- les tâches rapides, qui sont déclenchées de façon périodique ou sur événement,
- la tâche principale, qui est soit périodique (période d'appel fixe pour une bonne répétitivité des arrêts, par
exemple), soit cyclique (relancée dès qu'elle est terminée),
- les tâches lentes, qui sont toujours périodiques.
68. La phase de conception doit permettre d'affecter les différents traitements à programmer au sein des tâches
les plus appropriées en fonction de leurs besoins en temps de détection ou en temps de réaction (voir le calcul
du temps de réaction au sous chapitre ci-après), en respectant les règles suivantes :
• la période de la tâche où est programmée l'acquisition d'un événement doit être au minimum deux fois plus
faible que la durée de l'événement considéré (théorème de Shannon),
Il convient donc de s'assurer de la durée précise des événements de courte durée (détecteur à la volée sur
came courte, …) pour le choix du type de tâche d'acquisition de cet événement.
• le temps de réaction du système automatisé doit permettre d'obtenir la précision nécessaire dans les
arrêts, les positionnements, les lectures étiquettes, …,
• la dispersion due aux variations du temps de réaction (différence entre le temps le plus court et le temps le
plus long) doit être compatible avec la répétitivité nécessaire au processus (voir l'exemple de calcul de
dispersion ci-après),
• le dimensionnement de l'automatisme doit permettre son évolution en terme de temps de réaction (voir
chapitre maintenabilité),
• la tâche rapide ne doit être utilisée que pour l'acquisition d'événements trop rapides pour la tâche
principale ou pour programmer une réaction «réflexe» (arrêt positionné, etc.). On veille à réduire au
maximum le nombre de traitements réalisés en tâche rapide, ceci afin de ne pas augmenter exagérément
les temps de scrutation des tâches moins prioritaires,
• la tâche principale est utilisée de façon privilégiée (modes de marche, sécurités, commande de process,
etc.),
• la tâche lente peut être utilisée pour réaliser des traitements sans aucune priorité et lorsqu’il est nécessaire
d’alléger la tâche principale,
• la période d’appel de la tâche lente est toujours supérieure à deux fois la période de la tâche principale,
69. Lorsqu'un bus de terrain est utilisé, la durée de la tâche principale doit permettre de garantir le
rafraîchissement de toutes les entrées/sorties du bus en un seul tour de cycle automate.

6.1.1.TEMPS DE REACTION D'UN SYSTEME AUTOMATISE

Le temps de réaction d'un système automatisé est le temps qui s'écoule entre l'apparition d'un événement venant
de la partie opérative et la réaction de la partie commande à cet événement. Ne pas confondre temps de cycle
automate et temps de réaction du système :
Temps de cycle automate
Temps de cycle bus de terrain
Capteur Actionneur
Temps de réaction du système automatisé
Le temps de réaction évolue entre les deux bornes suivantes :

- le temps le plus favorable, égal à :
1 temps de filtrage carte entrée déportée + 1 temps de cycle automate + 1 temps de filtrage carte sortie
déportée,
- le temps le plus défavorable, égal à :
1 temps de filtrage carte entrée déportée + 1 temps de cycle réseau + 2 temps de cycle automate + 1
temps de cycle réseau + 1 temps de filtrage carte sortie déportée.
Dans la définition ci-dessus, les temps de transfert électrique sur le réseau, de transfert entre MIE réseau
(mémoire image des entrées) et MIE automate, de transfert entre MIS automate (mémoire image des sorties) et
MIS réseau, sont négligés.
Exemple de calcul de temps de réaction et de dispersion d'arrêt d'un mobile induite par les variations du
temps de réaction (pour simplifier le calcul, les temps de filtrage des cartes, de l'ordre de la milliseconde, sont
négligés) :
Vitesse du mobile : V = 60 m/mn = 1 mm/ms
Temps de cycle automate : Tca = 20 ms
Temps de cycle réseau : Tcr = 20 ms
Temps de réaction mini : Trm ≈ Tca = 20ms

Temps de réaction maxi : TrM ≈ 2 temps de cycle automate + 2 temps de cycle réseau = 2x20 + 2x20 = 80ms
Temps de réaction moyen : (Trm + TrM) / 2 = (20 + 80) / 2 = 50ms
Distance mini parcourue par le mobile avant la commande d'arrêt : D1 = Trm x V = 20 x 1 = 20 mm

Distance maxi parcourue par le mobile avant la commande d'arrêt : D2 = TrM x V = 80 x 1 = 80 mm
Distance moyenne parcourue par le mobile avant la commande d'arrêt : (D1 + D2) / 2 = (20 + 80) / 2 = 50 mm
La dispersion d'arrêt peut donc atteindre 60 mm (indépendamment de la dispersion due à la mécanique).
Un temps de réaction moyen voisin de 50 ms est signe d'un automatisme bien dimensionné.
70. En aucun cas le temps de réaction moyen ne devra dépasser 70 ms sans accord ou spécifications
particulières du pilote AUT.
71. Afin d'être le plus réactif et dans tous les cas où c'est possible, les données sont écrites avant d'être lues.

6.2.ORGANISATION DE LA TACHE PRINCIPALE

72. L’organisation des traitements de la tâche principale, schématisée ci-dessous, est imposée.
73. Les critères de réalisation des automatismes, doivent être respectés, avec par ordre d'importance :
• la fiabilité qui se caractérise par :

o le déterminisme : à une même situation d'entrée, ne correspond qu'une seule situation de sortie,
o la réactivité : l'automate calcule la nouvelle situation de sortie en une seule scrutation de la tâche
principale,
o l'autonomie : le logiciel est conçu pour réagir de façon prévue à toutes les situations,
• la lisibilité et la maintenabilité des logiciels,
• la modularité, l'évolutivité et la portabilité de tout ou partie des applications.
74. La réactivité est recherchée en s’assurant que l’automatisme réagit en un tour de cycle, ceci sans dégrader la
lisibilité du programme. Le principe qui consiste à utiliser des astuces de programmation pour gagner du temps
de cycle automate au détriment de la lisibilité est à bannir (sauts, …).
75. Les traitements d’entrée, de gestion du processus et de sortie sont impérativement matérialisés par des zones
de programme distinctes, identifiées par un nom conforme aux prescriptions de la norme E03.65.015.G,
chapitre repérage des objets programmés.
76. Pour une meilleure lisibilité, la structure de chaque zone de programme est calquée sur le découpage
fonctionnel du processus piloté.
Les annexes constructeurs détaillent la structure programme pour chaque type d'automate.

Représentation schématique du principe de scrutation de la tâche principale :
Mémoire Image des Entrées

API 1
Ilot 1
GMM1
Entité 1
EPO 1
EPO n
Traitements Entité 2
d'entrée Entité n
GMM 2
GMM n
Ilot 2
Ilot n
API 1
Ilot 1
GMM1
Entité 1
EPO 1
EPO n
Gestion Entité 2
du processus
Entité n
GMM 2
GMM n
Ilot 2
Ilot n
API
Ilot 1
GMM 1 Entité 1
EPO 1
EPO n
Entité 2
Traitements
de sortie Entité n
GMM 2
GMM n
Ilot 2
Ilot n
Mémoire Image des Sorties

6.3.LA CONCEPTION MODULAIRE

Elle a pour Objectifs de :
- découper une fonction complexe en fonctions élémentaires,
- identifier, localiser, regrouper les données utilisées pour ces fonctions,
- réutiliser les modules.
77. La conception modulaire doit respecter les critères suivants :
• la limitation du couplage : afin de faciliter l’intégration et la suppression d’un module de programme, il est
nécessaire de le concevoir de manière à limiter ses échanges avec le reste du programme.
Le regroupement de l’ensemble des données utilisées pour réaliser la fonctionnalité à l’intérieur du
module, permet de limiter le couplage,
• la cohérence : les traitements effectués dans un module doivent tous contribuer à la réalisation d’une
même fonctionnalité.
• la limite de décomposition : il faut poursuivre la décomposition des fonctions en sous fonctions, jusqu’à
obtenir des modules réutilisables dans le plus grand nombre d’applications.
Une trop grande décomposition, augmente les temps d’intégration, une faible décomposition diminue les
possibilités de réutilisation.
Mise en œuvre :
La réutilisation d’un module peut être réalisée de deux façons :
- par duplication du code, les données sont réaffectées à chaque duplication.
Cette solution consomme beaucoup de place mémoire et peu de temps de cycle.
- par utilisation d’un module instanciable permettant l’instanciation multiple. Le code programme du module
instanciable est contenu une seule fois dans l'automate et les données sont dupliquées autant de fois que
d'instances déclarées.
Cette solution consomme plus de temps de cycle que par duplication de code (passage des paramètres
d'entrée et restitution des données de sortie), mais moins de place mémoire.
Un module instanciable possède des données locales, propres à chaque instance (chaque appel).
Il utilise les données d’entrées et les données locales pour calculer ses données de sorties.
Le module instanciable contribue à améliorer la maintenabilité et la fiabilité du programme :
- en localisant les données manipulées par une fonction,
- en obligeant le concepteur à un effort de standardisation,
- en facilitant les modifications, car le programme «source» n’est écrit qu’une fois,
- en présentant uniquement les paramètres d’entrées et de sorties de la boîte à chaque appel (permet un
diagnostic rapide),
- en étant programmé de façon lisible et documentée, en cohérence avec le reste du programme (pas de
module verrouillé en lecture),
- en capitalisant les retours d'expérience et les mises au point sur plusieurs applications.
78. Les données locales d'un module instanciable ne doivent être ni lues ni écrites en dehors de ce module.
Seules les données de sorties, d'entrées/sorties les données publiques peuvent l'être.
79. Dans le cas d’une conception modulaire par duplication de code (sans utilisation du module instanciable), la
zone de données utilisées est partitionnée :
• à chaque copie de programme correspond une partition.
• chaque zone de programme peut lire toutes les partitions et écrire seulement dans celle qui lui est
affectée.

80. Un module instanciable ne doit pas contenir à la fois les traitements d'entrée, la gestion du processus et les
traitements de sortie. Ces trois parties doivent faire l'objet d'une programmation distincte.
Lorsqu'un module instanciable prend en compte les entrées automate, calcule les états (stable, OK, défaut, …)
et commande un actionneur, les problèmes suivants peuvent se poser :
• les informations d'entrée module peuvent être prises en compte avec un tour de cycle de retard si elles
sont calculées en aval dans le programme,
• la commande de marche peut être passée avec un temps de cycle de retard si l'état généré par l'instance
du bloc fonctionnel est traité par la gestion du processus écrite en aval dans le programme,
• la commande de marche peut être passée dans un tour de cycle automate puis infirmée au tour de cycle
automate suivant pour cause de défaut ou de perte de condition de sécurité venant d'un élément de partie
opérative traité en aval dans le programme.
81. La conception modulaire ne doit dans aucun cas être réalisée au détriment du comportement dynamique et
donc de la fiabilité de l’automate (réactivité et déterminisme).
82. Les modules instanciables intégrant du diagnostic doivent posséder une entrée de filtrage des événements.
Exemple : Mddfhs (mode défauts inhibés), Prten (Présence tension d'entrées)
83. Les modules programme (portillons, mouvement, communication, …) cités au cahier des charges doivent être
utilisés.
84. Les "boites noires" (modules instanciables verrouillés en lecture) fournies par l'intégrateur sont interdites sauf
dérogation prévue au cahier des charges.
85. La description fonctionnelle des modules instanciables est renseignée sous forme de commentaire en tête du
module ou dans une fiche descriptive si elle existe.
86. Au moins une instance de chaque module instanciable est appelée.
87. Les niveaux d'imbrication des modules instanciables ne doivent pas dépasser 3.
6.4.LA MAINTENABILITE
Un logiciel maintenable est un logiciel dont la lisibilité et la documentation intrinsèque permettent à tout
automaticien d’en comprendre la structure et le fonctionnement à un degré tel qu’il soit capable de lui apporter
toutes modifications liées à la vie de l’installation.
88. L'application des règles de maintenabilité ne doit pas dégrader la fiabilité.
89. Tout programme est structuré et commenté :
• Chaque équation porte un commentaire d’entête indiquant la nature de l’équation,

• Les commentaires sont les plus précis possible, exprimés en termes liés à l’application,
• Ils sont rédigés dans la langue du pays destinataire du programme,
• Respecter les termes employés dans l'analyse fonctionnelle.
90. L'appel conditionnel d'un bloc, module, sous programme, section, ... est interdit.
91. Le commentaire d'un réseau est identique au commentaire de la donnée affectée dans ce réseau (minimum 10
caractères, maximum 150 caractères).
92. Préférer l’utilisation de labels numériques (si besoin) aux labels alphabétiques, leur progression correspond à
l’ordre de scrutation du programme.
93. Les formes complexes sont décomposées en équations simples (niveaux de parenthèses réduits à 3 en
langage textuel).
94. Les groupes de termes utilisés plusieurs fois dans le programme sont regroupés dans une équation
intermédiaire dite de regroupement, mais seulement si la donnée créée a une signification. Dans le cas
contraire, il faut recopier tous les termes à chaque utilisation plutôt que de perdre en lisibilité.

95. Toutes les données d'entrée, d'entrée/sortie et internes sont lues au moins une fois, hormis les données
écrites pour un équipement tiers ou pour un terminal opérateur.
96. Toutes les données de sortie, d'entrée/sortie et internes doivent être écrites au moins une fois.
97. L'écriture d'une donnée binaire est le résultat d’une équation unique ou de deux équations si set/reset.
98. L'écriture d'une même valeur dans une donnée numérique est le résultat d’une équation unique.
99. Lorsque des écritures multiples d’une même donnée numérique sont indispensables, elles sont regroupées
dans une même zone de programme ou à défaut dans une même tâche.
100. Les entrées physiques ne sont pas écrites par programme.
101. L’état logique 1 des événements signale toujours leur présence. La mise à 1 de ces bits est prioritaire sur leur
mise à 0 (acquittement possible uniquement si la cause a disparu).
102. Le symbole et le commentaire d'une donnée décrivent son état logique 1. Dans le cas ou le commentaire de
l'état logique 1 est incompréhensible (logique inverse), c'est l'état logique 0 qui est décrit avec la mention "0 ="
incluse.
Exemple :
SQ3SE_23 0 = surcourse section élévatrice 23 atteind
103. Les équations des voyants contiennent un essai lampes.
104. Une zone minimum de 10 données de type bit, mot, temporisateur, est réservée pour utilisation provisoire en
mise au point.
105. Les données provisoires utilisées pendant la période de mise en service de l'installation sont supprimées à la
fin de la phase de mise au point ("shunts", inhibitions, …).
106. Le code provisoirement mis en commentaire est supprimé à la fin de la phase de mise au point.
107. Seuls les équations, blocs, sections, modules, sous programmes… utilisés par l'application doivent demeurer
dans le programme. Toute partie de programme non scrutée doit être supprimée.
108. Les données lues et non écrites ou écrites et non lues sont supprimées hormis les données d'échange avec un
équipement tiers ou un terminal opérateur.
109. Une application doit pouvoir évoluer après son développement et sa mise au point tout en garantissant le
temps de réaction du système automatisé. Pour cela, une réserve de 15 % de chacune des capacités
suivantes doit rester disponible :
• les données internes de chaque type,
• les mémoires image des entrées sorties en rack ou déportées,
• chaque espace mémoire de données et de programmes (y compris la mémoire de chargement des
programmes),
• les bus de terrains (temps de cycle, nombre d'esclaves,…),
• le temps de réaction.
110. Les données de réserve ne sont ni lues ni écrites.
111. Les données de format différent affectées au même plan mémoire (par exemple un plan mémoire commun aux
trois types de données Mots/Octets/Bits de mots) ne se chevauchent pas.
112. Une donnée binaire n'est jamais affectée sans condition sauf le bit toujours à 1 et bit toujours à 0.
113. La recopie des entrées automate dans des bits internes et des bits internes dans les sorties automate est
interdite.
Cette recopie est inutile car le programme travaille sur l'image des entrées automate pendant tout son tour
cycle. Un changement d'état d'une entrée en cours de cycle ne sera prise en compte qu'au tour ce cycle
suivant. Pour des questions de regroupement, la recopie de bits d'entrée dans des mots internes est autorisée.

6.5.CHOIX DES LANGAGES

114. Les logiciels des automates programmables sont réalisés en utilisant exclusivement les langages suivants :
- le grafcet ou SFC = Sequencial Function Charts.
- le langage à contacts ou LD = Ladder Diagram.
- le langage textuel ou ST = Structured Text.
115. Compte tenu de sa faible lisibilité, le langage List est proscrit.
116. Le langage de programmation est choisi en fonction du type de traitement à réaliser :
• pour les traitements séquentiels :

o le grafcet (SFC) qui permet de modéliser un comportement séquentiel par mémorisation de l’état en
cours et surveillance des conditions de passage à la situation suivante,
o le langage à contacts (LD) qui permet de calculer à chaque scrutation le nouvel état machine à
obtenir, ceci en ne mémorisant qu’un minimum du contexte.
• pour les traitements combinatoires booléens :
o le langage à contacts (LD) qui permet de modéliser des réseaux d’éléments ‘électromécaniques’
fonctionnant simultanément. C’est le langage privilégié des traitements d’entrée et de sortie.
• pour les calculs numériques :
o le langage textuel (ST) qui permet de programmer des traitements tels que des algorithmes utilisant
des structures, des asservissements, de faire du calcul sur mots ou de réaliser le traitement de
processus complexes (machine à peindre par exemple, …).
117. Lorsque le grafcet est utilisé pour modéliser un comportement séquentiel, la mise en œuvre de fonctions d'aide
à la remise en production est indispensable.

7.REGLES DE REALISATION
7.1.LE GRAFCET (SFC)
7.1.1.STRUCTURE GENERALE
118. Le découpage du grafcet doit correspondre au découpage fonctionnel de l'installation.
119. Si un élément du découpage fonctionnel engendre un graphe dont la taille est supérieure à quatre branches et
vingt étapes, le graphe doit être découpé plus finement.
120. Toute fonction séquentielle indépendante doit être rendue autonome par un grafcet qui lui est propre. Elle n'est
pas représentée par une branche parallèle dans un autre grafcet.
121. les macros étapes doivent être utilisées en priorité par rapport aux graphes, notamment pour la gestion du
processus des entités (une macroétape par entité).
122. Les imbrications de macro étapes sont limitées à deux niveaux.
123. Les graphes comportant moins de trois étapes sont interdits.
124. Les étapes, macro étapes et transitions doivent être commentées (minimum 10 et maximum 150 caractères).
125. Aucune équation ne doit être écrite dans une étape ou une macro étape de grafcet.
7.1.2.TRANSITIONS
126. Les équations respectent les règles du chapitre "langage à contacts".
127. Si une équation dépasse la taille maximale autorisée, elle est décomposée et écrite dans le traitement
combinatoire d'entrée, en utilisant des bits de regroupement.
128. Lorsque les étapes demandent des mouvements, les transitions correspondent aux états contrôlés et sans
défaut de ces mouvements.
7.1.3.ETAPE INITIALE
129. Les étapes initiales des grafcet doivent correspondre à des états physiques stables (pas d’origine en position
intermédiaire par exemple).
130. Chaque graphe possède une et une seule étape initiale correspondant à l’état d’origine mécanique.
131. L’état origine doit toujours correspondre à la première étape du graphe (état stable machine au repos).
132. La première transition correspond toujours aux conditions de départ depuis cet état stable d’origine, et au
contrôle de retombée des mémoires d'état.
Etape initiale 1 Machine en origine
Conditions
de départ et mémoires
d'état retombées
7.1.4.ETAPE DE FIN
133. Chaque graphe se termine par une étape de fin ou étape d’attente. Cette étape correspond à la même
situation mécanique que l’étape origine, avec la plus-value «opération effectuée».
134. La transition qui fait passer de cette étape à l’étape origine tient compte des conditions d’origine et d’évolution
vers un nouveau cycle (retombée des mémoires d'état).

Etape de fin n Machine en origine

ayant travaillé
Conditions
vers l’étape origine
de redémarrage et retombée
des mémoires d'état
7.1.5.UTILISATION DES BITS D'ETAPE

135. Les bits d'étape sont utilisés directement dans les équations d'activation des sorties.
136. L'écriture des bits d'étape est interdite sauf en cas de pré positionnement pour reprise de cycle.
Une attention particulière doit être portée à la façon dont l'interpréteur gère l'évolution du graphe afin de
programmer le grafcet en toute connaissance de cause. Plusieurs transitions vraies dans le même tour de cycle
sont-elles franchies simultanément (recherche de stabilité) ? Si oui, les actions dans les étapes furtives sont elles
exécutées par le système ?
7.1.6.PARALLELISME STRUCTURAL
137. La représentation suivante d’un parallélisme dissimulé est interdite, elle occulte la notion de synthèse globale
d’un grafcet.
1 1
2 Validation action A SET action D 2 Validation action A et D
3 Validation action B 3 Validation action B et D
4 Validation action C RESET action D 4 Validation action C
5 5
138. Toute action maintenue sur plusieurs étapes se fait en parallélisme structural (ou en graphes séparés selon le
nombre d’actions).

139. Deux actions indépendantes validées simultanément doivent être contrôlées et activées séparément.
t1 t2
2 Validation 5 Validation
action 1 action 2
1 Validation action 1 Validation action 2
t1 t2
t1 et t2
3 7
=1
8
140. Les étapes d’attentes doivent être utilisées systématiquement lors de parallélisme structural.
2 Validation 5 Validation 2 Validation 5 Validation

action 1 action 2 action 1 action 2
t1 t2
t 3 7
=1
La représentation de gauche ne permet pas d’identifier l’action bloquante et les validations d'actions sont
maintenues tant que la transition commune n'est pas vraie.
La représentation de droite doit être adoptée. L’état de blocage est matérialisé par la (les) branches(s) n’étant pas
en attente. Chaque validation d'action retombe dès que sa condition de transition est vraie.

7.1.7.PARALLELISME INTERPRETE
141. Il est interdit d’utiliser les possibilités du parallélisme interprété offertes par le grafcet.
Dans l’exemple ci-dessous l’évolution à partir de l’étape 5 peut se faire dans chacune des trois branches vers les
étapes 6, 7 et 8 si les données a, b, c sont dans l'état logique 1 simultanément.
Les conditions des transitions doivent être exclusives : ne seule branche valide à la fois.
a.b.c b.a.c c.a.b
6 A 7 B 8 C
7.1.8.SAUT DE SEQUENCE
142. Il est interdit de sortir d’une structure de branches parallèles si les étapes de fin de chaque branche ne sont
pas toutes atteintes.

143. Les branches parallèles doivent être refermées avant une nouvelle divergence.
Une divergence à l'intérieur d'une branche parallèle telle que la montre la vue suivante est interdite car elle
peut générer deux pointeurs dans la même branche.
7.1.9.FONCTIONS DE CONTROLE
144. Les fonctions de contrôle du grafcet sont réalisées dans le traitement combinatoire d'entrée de chacune des
entités (voir paragraphe ‘traitement d'entrée’).
145. Les fonctions autorisées sont :
• Figeage : cette fonction réalise le maintien du grafcet dans une situation stable,
• Forçage : cette fonction réalise le positionnement du grafcet dans une situation donnée,
• Désactivation : c’est une mise à zéro de toutes les étapes actives. Cet ordre est suivi d’un ordre de
forçage,
• Initialisation : cette fonction consiste à mettre à zéro toutes les étapes actives et à activer la ou les étapes
initiales.
146. Elles sont utilisées exclusivement :
• en cas de reprise à froid,

• après défaillance de l’automate,
• pour recaler l’état logique du grafcet s'il n’est plus cohérent avec l’état physique de l’installation.
147. Le grafcet ne doit pas être désactivé en mode de marche manuelle.
En effet, pendant la marche manuelle, si le cycle est respecté, la reprise de cycle automatique est immédiate.

7.1.10.SYNCHRONISATION DES GRAPHES

148. La synchronisation des graphes s'effectue par l'intermédiaire des étapes de graphe.
Dans l'exemple ci-dessous, le passage dans l'étape 12 (étape de synchronisation) valide la condition de
transition de l'étape 2 (étape d'attente) vers l'étape 3. Le passage dans l'étape 3 permet alors au graphe n°2
de poursuivre son évolution.
Graphe n°1 Graphe n°2
7.2.LANGAGE A CONTACTS (LD)

7.2.1.STRUCTURE GENERALE
149. En règle générale un réseau en langage à contact ne contient qu'une équation d'affectation de bits.
Cette limitation permet d’avoir un commentaire approprié par équation.
150. Plusieurs affectations dans un même réseau sont autorisées uniquement dans les cas suivants :
• dans le bloc d'initialisation du programme au démarrage de l'automate,

• la construction des données de front lorsque l'éditeur ne bénéficie pas d'instructions de front,

• le regroupement des équations de passage des paramètres à un module instanciable ou un sous-

programme, positionnées juste avant son appel,
• le regroupement des données d'échanges de même nature avec plusieurs destinataires, dans une même
équation,
Exemple : envoi d'une donnée vers deux terminaux opérateur
BIT mode auto Mode auto vers TO1
Mode auto vers TO2
• le regroupement des affectations de données de nature différente ayant la même signification (conditions
identiques),
Exemple : traitement d'une donnée locale et d'une donnée de sortie d'un module instanciable.
Condition 1 Condition 2 Condition 3 Condition 4 Donnée de sortie
Donnée terminal opérateur
• L'écriture de plusieurs données si elles constituent une même information,

Exemple : plusieurs mots constituant le numéro d'ordre du véhicule.
• L'écriture de plusieurs valeurs dans une même donnée,
Exemple : écriture de la donnée "type" : si pièce gauche, type = 1 : si pièce droite, type = 2.

151. La représentation d’une équation doit tenir dans un écran console en mode "affichage par défaut". Il convient
donc de limiter le nombre de branches parallèles ainsi que le nombre de contacts en série.
Cette contrainte permet d’avoir une vue dynamique globale de l’équation sans aucune manipulation clavier.
152. Les instructions d'indexation, sont interdites en langage à contact.

153. Les instructions de saut à une étiquette, sont interdites en langage à contact.
Il convient de conditionner l'ensemble des équations concernées par la condition qui aurait validé le saut.
A Saut à suite
JUMP
B C Bit1
Suite
D Bit2
A B C Bit1
D Bit2
154. Les équations en logique inverse sont interdites :

155. L'affectation multiple d'un même bit réalisée pour des raisons de nombre d'instructions est interdite. Utiliser
des bits de regroupement
7.2.2.FORMES TYPES DES EQUATIONS DE SURVEILLANCE DES EVENEMENTS

156. Règles communes à l'ensemble des surveillances :
• l'acquittement n'est actif que si la cause de l'événement a disparu,

• les équations en reset/ set doivent être consécutives dans le même réseau avec priorité à l'équation de set
(équation aval).
157. Les formes des équations de surveillance des événements acquittables autorisées sont les suivantes :
• équation avec auto maintien :

Conditions d'apparition
Filtrage Evénement
Demande
Evénement
acquittement
Conditions
d'acquittement

• équation en reset/set si les conditions d'apparition et d'acquittement sont différentes :

Complément conditions d'apparition
Demande Conditions
Evénement
d'acquittement d'acquittement
R
conditions d'apparition
Filtrage Evénement
Préférer l'équation avec auto maintien au reset/set.
• équation de surveillance d'un relais :

o chaque relais est contrôlé dans les deux états logiques,
o la branche de contrôle de l'état logique 1 est la recopie de l'équation du schéma de câblage,
o la branche de contrôle de l'état logique 0 est le complément de l'équation du schéma de câblage,
o la temporisation correspond au temps de commutation du relais.
Câblage Conditions Programmation

Filtrage
défaut Relais 7 Relais 1 Relais 2 Relais 3 Relais 5 Tempo Défaut relais 7
Relais 1 filtrage temps
commutation
Relais 4 relais
Relais 6
Relais 2 Relais 6
Relais 7 Relais 1
Relais 4
Relais 3
Relais 2 Relais 6
Relais 5 Relais 3 Relais 4
Relais 5
Relais 7
Demande
Défaut relais 7 acquittement

7.2.3.PROGRAMMATION D’UN PROCESSUS CYCLE EN LANGAGE A CONTACTS

158. Le langage à contacts peut être utilisé pour programmer un comportement cyclé.
Avantages de ce mode de programmation :
Il facilite le traitement des remises en cycle après intervention ou sur reprise après incident, du fait qu’un
minimum de mémoires est utilisé. Les équations sont calculées en temps réel, en fonction des états physiques
et sans désynchronisme.
Il permet de s’affranchir des spécificités du grafcet propres à chaque constructeur (comportement de
l’interpréteur, structure programme, capacité mémoire, temps de scrutation, …) et des difficultés de remise en
cycle.
Inconvénients de ce mode de programmation :
Il nécessite des règles d’écriture et une documentation très rigoureuse pour compenser le manque de vision
globale du cycle machine à la relecture des programmes. La visualisation dynamique du programme ne
permet pas d'avoir facilement la vision de l'état du cycle.
Il nécessite une aide au diagnostic supplémentaire. En effet, l’état de la machine n’étant pas mémorisé,
aucune information relative à l’avancement du cycle n’est naturellement disponible pour guider le dépanneur.
159. Tout comme les étapes d'un grafcet, les équations permettent de générer les demandes d’actions dans
l’ordre du cycle en fonction des états stables des actionneurs.
160. Les états stables sont calculés dans les traitements d’entrée.
161. Les demandes d’actions sont utilisées dans les traitements de sortie, selon la structure de la tâche principale
spécifiée ci-avant.
162. Les demandes d'action sont maintenues jusqu'à la fin des actions.
163. L'utilisation des instructions de set/reset pour positionner les bits de demande d'action est interdite.
Le set/reset des actions revient à créer un pseudo grafcet comportant à la fois les désavantages du langage
contact et ceux du langage grafcet : manque de lisibilité du cycle et d'évolutivité pour l'un et difficulté de remise
en cycle pour l'autre.
164. Les cas d’équations identiques, correspondant à une situation physique présente plusieurs fois dans un même
cycle machine, sont résolus en positionnant des mémoires d’exclusivité (nommées mémoires d'état).
Ces mémoires correspondent à un changement d’état du processus (travail effectué, pièce déposée, porteur
chargé, …).
165. Les équations de ces mémoires sont programmées en début de traitement "Gestion du processus".
Exemple :
Dans l'exemple ci-dessous les conditions de début de cycle, de fin de cycle et de travail effectué sont calculées
dans le traitement combinatoire d'entrée.
La donnée de condition de début de cycle est équivalente à la transition qui suit l'étape initiale d'un grafcet. Elle
peut être la combinaison de données propres à l'entité et de données externes (par exemple : fin de travail dépose
pièce robot 1 et présence capteur contrôle présence pièce).
La donnée de condition de fin de cycle est équivalente à la transition qui suit la dernière étape d'un grafcet. Elle
peut être la combinaison de données propres à l'entité et de données externes (par exemple : fin de travail
évacuation pièce robot 2 et absence capteur contrôle présence pièce).
La mémoire de travail effectué est activée par la combinaison de données propres à l'entité et de données
externes (par exemple : fin de cycle de mesure fourni par une baie externe). Elle est désactivée par la condition de
fin de cycle.

Chronogramme fonctionnel :
Condition
Conditiondede Mouvement
Mouvement travail
travail
début
débutdedecycle
cycle Mouvement
Mouvement repos
repos
Actionneur A
Actionneur B
Actionneur C
Travail effectué
Condition
Conditiondede
travail Condition de fin
effectué de cycle
travail effectué
Traitement combinatoire process :

Travail Condition Etat Demande
effectué début de cycle travail A travail A
Travail Etat Etat Demande

effectué travail A travail B travail B
Travail Etat Etat Etat Demande

effectué travail A travail B travail C travail C
Travail Etat Demande

effectué repos C repos C
Travail Etat Etat Demande

effectué repos C repos B repos B
Travail Etat Etat Etat Demande

effectué repos C repos B repos A repos A

7.2.4.EQUATIONS TYPES DE COMMANDE DES SORTIES ACTIONNEURS

166. Les sorties de commandes des actionneurs sont programmées dans une équation unique, scrutée à chaque
tour de cycle et écrite en langage Ladder.
167. Les équations de sortie ont la forme suivante :
Traitement combinatoire de sortie :
Autorisation mouvement
Sécurités Défauts sécurités

mouvement mouvement
Mode de Conditions Défaut Défaut Défauts

Demande marche auto Sécurités Sécurités Sécurités sécurités sécurités sécurités Commande
Commande
processus auto éventuelles * mécaniques électriques opérateurs mécaniques électriques opérateurs inverse
Mode de Conditions
Demande marche manu
opérateur manu éventuelles
Autant de branches
parallèles que de
marches
Autre
Autre mode de Conditions
demande marche éventuelles
* Cycle autorisé pour une installation cyclée, par exemple "présence étiquette et présence pièce,
Fonctionnement autorisé pour une installation non cyclée, par exemple "température four atteinte".
168. En cas de besoin de l'information "Présence demande mouvement" ou action, notamment pour le diagnostic,
l'équation de sortie ci-dessus peut être remplacée par les deux équations suivantes :
Mode de Conditions
Demande marche auto Présence demande
processus auto éventuelles
Mode de Conditions
Demande marche manu
opérateur manu éventuelles
Autant de branches
parallèles que de
marches
Autre
Autre mode de Conditions
demande marche éventuelles
Présence Autorisation mouvement Commande

Commande
demande inverse

169. En fonction du comportement souhaité de l'actionneur, les formes standard des équations de sortie sont les
suivantes :
• commande si demande :
Autorisation Commande
Présence demande Commande
mouvement inverse
• commande si demande et jusqu'à la position :
Autorisation Commande Capteur position Commande

Présence demande mouvement inverse atteinte
• commande maintenue jusqu'à la demande inverse :
Autorisation Demande Commande

Présence demande mouvement inverse
Autorisation
Commande
mouvement inverse
• commande maintenue par la position jusqu'à la demande inverse :

Etat demandé Autorisation

Commande atteint mouvement inverse
• commande maintenue jusqu'à la position ou la demande inverse :

Etat demandé Autorisation

Commande atteint mouvement inverse
170. Les équations d'interverrouillage programmé des contacteurs inverseurs doivent intégrer l'information "retour
contacteur".
Il est possible, par programme, de passer une commande et sa commande inverse sur deux tours de cycle
automate consécutifs, c'est-à-dire en quelques dizaines de millisecondes, donc, pendant le temps de
basculement du contacteur qui peut être supérieur. L'utilisation de l'information retour contacteur permet de ne
passer une commande inverse que lorsque le contacteur est dans un état stable.

Entrées automate Programme automate Sorties automate
Retour Commande Commande

Contacteur Contacteur contacteur AR AR AV
AR
Commande
Commande
AV
AV
AR
Retour Commande Commande
contacteur AV
contacteur AR
contacteur AV AV AR
Retour
Retour
Contacteur Contacteur
AV AR
7.2.5.AUTRES EQUATIONS TYPE

171. La forme type des équations de "Flip Flop" ou "télérupteur" est la suivante :
Front montant Conditions Image front

Commande flip flop éventuelles montant
P
Image front Bit de Bit de

montant flip flop flip flop
Image front Bit de

montant flip flop
7.3.LE LANGAGE TEXTUEL (ST)

172. Les instructions de sauts (JUMP, GO TO, …) et les instructions de type " WITH" sont interdites.
Elles rendent la lecture et la compréhension d'un programme en langage textuel particulièrement difficile.
173. Les boucles itératives sont réalisées avec les instructions dédiées (REPEAT…).
174. Deux boucles imbriquées sont autorisées.

175. Il est interdit de forcer les données définissant une boucle, à l'intérieur celle-ci.
Cette règle améliore la lisibilité et la compréhension et donc l'évolutivité du programme.
176. Les tests de fin de boucle ne doivent pas être de type strictement =. Ils doivent être de type >, >=, <, <=.
Ceci permet d’intégrer des cas de débordement ou d’initialisation erronée, et procure ainsi une meilleure tolérance
aux fautes.
177. Les équations en texte structuré ne doivent pas dépasser les possibilités d'affichage d'un écran en mode
standard.
178. Les valeurs calculées ne dépendant pas d’un indice de boucle ne se font pas à l’intérieur de la boucle.
Ceci a des incidences évidentes sur le temps de cycle de l'automate

179. Utiliser les indentations (tabulations) afin de souligner et rendre plus lisible les différents paragraphes ou
niveaux de structure du programme.
Exemple :
7.4.LE REPERAGE DES OBJETS PROGRAMMES

180. Tous les objets programmés autres que données système (module instanciable, section, bloc programme,
sous-programme, donnée de tout type y compris les objets d'un tableau et les bits significatifs d'un mot,
temporisation, compteur, …) sont affectés d’un mnémonique conforme à la norme E03.65.015.G et d’un
commentaire.
181. Le commentaire des objets programmés est rédigé dans la langue du pays destinataire du programme.
182. Le commentaire des objets programmés comporte au minimum 10 et au maximum 150 caractères.
183. Le commentaire est le plus précis possible, exprimé en termes liés à l'application.
184. Le commentaire d'une donnée ne se limite pas à son mnémonique ou à son adresse mémoire.
185. Deux données distinctes ne doivent pas avoir le même commentaire.
186. Les mnémoniques et commentaires des entrées/sorties tout ou rien sont ceux du schéma électrique.
187. Pour permettre les contrôles automatiques, les commentaires des données internes doivent être marqués (à la
fin du commentaire) dans les cas suivants :
Type de commentaire Marqueur commentaire
Commentaire associé à une donnée écrite par un tiers et lue par l'API !L
Commentaire associé à une donnée écrite par l'API pour un tiers !E
Commentaire séparateur dans la base !C
Un commentaire séparateur est associé à une donnée inutilisée par le programme et ne sert que de repère visuel
permettant de délimiter des zones distinctes pour une meilleure lisibilité et une structuration de la base de
données.
Exemples :
Données écrite par un plot de lecture et lue par l'API : CREPR501 Compte-rendu Plot N°5 Entité 01 !L
Donnée écrite par l'API lue par un terminal opérateur : TAAFF1_1T Table d'affichage 1 IHM1 !E
Commentaire séparateur : MW1000 *************************ZONE TERMINAL OPERATEUR 1******************** !C
188. Une donnée commentée avec le marqueur !L ne doit pas être écrite.
189. Une donnée commentée avec le marqueur !C ne doit être ni lue ni écrite, ni symbolisée. Elle sert de ligne de
séparation pour structurer la base de données.
190. Le nom de l'application est renseigné.
191. La version de l'application est renseignée.

E03.65.036.G - FR - REGLES DE CONCEPTION ET DE REALISATION DES LOGICIELS

Transféré par

Droits d'auteur :

Formats disponibles

E03.65.036.G - FR - REGLES DE CONCEPTION ET DE REALISATION DES LOGICIELS

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

E03.65.036.G - FR - REGLES DE CONCEPTION ET DE REALISATION DES LOGICIELS

Transféré par

Droits d'auteur :

Formats disponibles

PSA PEUGEOT - CITROËN

ICS : 25.040.01, 35.080, 35.240.50

Rédacteur Vérificateur Approbateur

Jean Luc MARCHETTI Voir la liste des intervenants Fréderic TOURNUT

Date Signature Date Signature Date Signature

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

Indice Date Nature des modifications

OR 01/01/1999 Version de la norme lors de la reprise sous GEODE

A 02/09/2003 Mise à jour du document

B 14/03/2007 Refonte complète du document

C 09/01/2008 Ajout du chapitre "impact du programme sur la qualité produit"

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

1.OBJET ET DOMAINE D’APPLICATION

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

2.4.EXPRESSION SUR DOCUMENTS

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

4.2.REPRISE APRES COUPURE ALIMENTATION

• restitution d'un fichier de données,

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

Front montant Fin tempo Relais test

Retour relais Relais

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

Exemple d'équation de contrôle d'un relais d'arrêt d'urgence :

Fin tempo test Relais arrêt

Défaut relais Bouton

Dans cet exemple, si au bout du temps enveloppe :

5.1.1.3.Autocontrôle des groupes de sécurité

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

Exemple de gestion d'une sortie relais validation :

5.1.2.TRAITEMENT DE LA MISE EN ENERGIE

Groupes d'énergies Retour relais Retour Groupe d'énergie

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

5.2.1.AIDE A LA REMISE EN PRODUCTION

5.2.2.LES COMMANDES MANUELLES

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

5.4.1. SURVEILLANCE DES EVENEMENTS

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

• le bon fonctionnement à chaque sollicitation prévue de chaque composant électromécanique (capteur,

5.4.2.CLASSIFICATION DES EVENEMENTS

5.4.3.MEMORISATION DES EVENEMENTS

Evénement mémorisé car il doit être acquitté alarme

Evénement mémorisé car il peut être furtif

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

5.4.4.FILTRAGE DES EVENEMENTS

5.4.5.REACTION DE L'AUTOMATE SUR LE PROCESS

• l'arrêt immédiat qui peut être obtenu par :

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

5.4.6.SIGNALISATION DES EVENEMENTS

5.5.SURVEILLANCE DES CAPTEURS ET ACTIONNEURS

5.6.IMPACT DU PROGRAMME SUR LA QUALITE PRODUIT

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

OR : 01/01/1999 C : 09/01/2008 Réseau de compétence : 04A USAGE INTERNE

6.1.1.TEMPS DE REACTION D'UN SYSTEME AUTOMATISE

Temps de cycle bus de terrain

Le temps de réaction évolue entre les deux bornes suivantes :

Temps de réaction mini : Trm ≈ Tca = 20ms

Distance mini parcourue par le mobile avant la commande d'arrêt : D1 = Trm x V = 20 x 1 = 20 mm