REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Ecole Nationale Polytechnique

Département d’Electronique

DOOFAS R&D

Mémoire de projet de fin d’études

pour l’obtention du diplôme d’ingénieur d’état en électronique

Étude et implémentation du protocole

industriel PROFINET pour les I/O
devices

YAHIA AISSA Ilyas

Présenté et soutenu publiquement le (12/07/2021)

Composition du jury :

Président M. TAGHI Mohamed Oussaid MAA ENP

Promoteur M. LARFI Abdelmoumen Ingénieur. DOOFAS
Promoteur M. LARBES Cherif Prof. ENP
Examinatrice M. BENALIA Nour El-Houda Dr. ENP

ENP 2021
 REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Ecole Nationale Polytechnique

Département d’Electronique

DOOFAS R&D

Mémoire de projet de fin d’études

pour l’obtention du diplôme d’ingénieur d’état en électronique

Étude et implémentation du protocole

industriel PROFINET pour les I/O
devices

YAHIA AISSA Ilyas

Présenté et soutenu publiquement le (12/07/2021)

Composition du jury :

Président M. TAGHI Mohamed Oussaid MAA ENP

Promoteur M. LARFI Abdelmoumen Ingénieur. DOOFAS
Promoteur M. LARBES Cherif Prof. ENP
Examinatrice Mme. BENALIA Nour El-Houda Dr. ENP

ENP 2021
 Dédicace

Je dédie ce travail à ma merveilleuse mère, mon père et mon frère,

À la mémoire de mes deux grands-pères,
À ma famille,
À mes amis
Et à tous ceux qui m’ont soutenu dans mon parcours.
 Remerciements

Je voudrais dans un premier temps remercier, mon encadreur [Link] Cherif,

pour sa confiance, il m’a toujours soutenu dans mes projets et a toujours été à l’écoute.
Je remercie également M. LARFI Abdelmoumen et M. REBIKA Samir ainsi que
toute l’équipe de DOOFAS pour leur disponibilité, leurs précieux conseils et pour
m’avoir introduit au monde professionnel.
Je tiens à témoigner toute ma reconnaissance envers mes parents pour m’avoir
offert l’environnement adéquat afin de me focaliser sur mon travail, ainsi que mon
frère qui m’a apporté son soutien moral et intellectuel tout au long de mon projet.
Je remercie sincèrement les membres du jury, Mme. BENALIA Nour El-Houda et
[Link] Mohamed Oussaid, qui ont généreusement offert leur temps, leur soutien,
leurs conseils et leur bonne volonté durant ces trois dernières années.
Enfin, je remercie mes amis Adel, Zaki, Walid, Nadir, Djamel, Larbi, Nassim et
Abderrahmane ainsi que mes cousins Arysse, Adlane, Anis, Nassim, Sofiane et Malik
qui ont toujours été là pour moi. Leur soutien inconditionnel et leurs encouragements
ont été d’une grande aide.
 Abstract
Nowadays, there are many standard industrial protocols in automated systems.
They can be divided into two categories : Ethernet-based and non-Ethernet-based pro-
tocols. Each protocol corresponds to a need according to the expected performances
and the targeted market, with a central notion : real time.
This document presents a study as well as the implementation of an IO device
communicating with the protocol PROFINET on embedded linux, then the adaptation
of the operating system so that it meets the real time constraints. Finally, it presents
the tests carried out on the IO device which confirms the proper functioning of our
system as well as the respect of the constraints of determinism.
Key words : PROFINET, Industrial Ethernet, Embedded linux, Real time

Résumé
Les protocoles industriels standards dans les systèmes automatisés sont de nos
jours nombreux. On peut les classer en deux catégories : les protocoles basés sur Ether-
net et les autres. Chaque protocole correspond à un besoin selon les performances at-
tendues et le marché visé, avec une notion centrale : le temps réel.
Ce document présente une étude ainsi que l’implémentation d’un IO device commu-
niquant à l’aide du protocole PROFINET sur linux pour embarqué, Puis l’adaptation
du système d’exploitation afin qu’il réponde aux contraintes de temps réel. Enfin, il
présente les tests effectués sur l’IO device qui confirme le bon fonctionnement de notre
système ainsi que le respect des contraintes de déterminisme.
Mots clés : PROFINET, Ethernet industriel, Linux embarqué, Temps réel
Table des matières

Liste des tableaux

Table des figures

Liste des abréviations

Introduction 14

1 Aperçu global sur PROFINET 16

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.1 Système numérique de contrôle-commande : . . . . . . . . . . . 18
1.2.2 Programmable logic controller (PLC) . . . . . . . . . . . . . . . . 18
1.2.3 IO device (Appareil de terrain) . . . . . . . . . . . . . . . . . . . 19
1.3 Bus de terrain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.1 Ethernet industriel . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.2 Exemples de bus de terrain . . . . . . . . . . . . . . . . . . . . . . 24
1.3.3 Profinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3.4 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Protocoles de communication PROFINET 27

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 Équipements et intégration : . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 Constituants d’un réseau PROFINET . . . . . . . . . . . . . . . . 28
2.2.2 Intégration des équipements PROFINET . . . . . . . . . . . . . . 29
2.2.3 Modules et submodules . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.4 GSD file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
 2.2.5 Conformance classes . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Communication PROFINET : . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1 Modèle OSI et profinet . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.2 Temps réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.3 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.4 Éléments du protocole Profinet . . . . . . . . . . . . . . . . . . . . 36
2.3.5 TCP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4 Principaux canaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.1 Application relation (AR) . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.2 Communication relation (CR) . . . . . . . . . . . . . . . . . . . . . 39
2.4.3 Communication cyclique . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.4 Communication acyclique . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.5 Alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.5 Démarrage (startup) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.5.1 Context management (CM) . . . . . . . . . . . . . . . . . . . . . . 44
2.5.2 Le lancement en différentes étapes . . . . . . . . . . . . . . . . . . 44
2.5.3 Protocoles utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3 Implémentation du protocole PROFINET 49

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Hardware utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.1 Choix du microcontrôleur . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3 Linux sur embarqué . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.2 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
[Link] Multitâche . . . . . . . . . . . . . . . . . . . . . . . . . . 53
[Link] Multi-utilisateur . . . . . . . . . . . . . . . . . . . . . . . 53
[Link] Multithreading . . . . . . . . . . . . . . . . . . . . . . . 53
[Link] Système de fichiers hiérarchique . . . . . . . . . . . . . 53
[Link] Device drivers . . . . . . . . . . . . . . . . . . . . . . . . 54
[Link] La contrainte de temps . . . . . . . . . . . . . . . . . . . 54
[Link] La capacité du réseau . . . . . . . . . . . . . . . . . . . . 54
 3.3.3 Propriétés temps réel de Linux : . . . . . . . . . . . . . . . . . . . 54
[Link] Option "SCHED_FIFO" . . . . . . . . . . . . . . . . . . . 54
[Link] Application sur un cœur de processeur séparé . . . . . . 55
[Link] Patches en temps réel . . . . . . . . . . . . . . . . . . . . 55
[Link] Augmenter le temps de cycle de l’application . . . . . . 56
[Link] Matériel de l’interface réseau . . . . . . . . . . . . . . . . 57
3.4 Bibliothèque p-net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.1 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4.3 Dépendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5 Implémentation p-net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.1 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6 Application spécifique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6.2 GSD file pour l’IO device . . . . . . . . . . . . . . . . . . . . . . . 62
3.6.3 Structure du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
[Link] Organisation des fichiers . . . . . . . . . . . . . . . . . . 63
[Link] Machine d’état . . . . . . . . . . . . . . . . . . . . . . . . 64
3.6.4 API PROFINET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.6.5 Implémentation de la communication cyclique . . . . . . . . . . . 69
[Link] Lecture capteur . . . . . . . . . . . . . . . . . . . . . . . 69
3.6.6 Implémentation de la communication acyclique . . . . . . . . . . 72
3.6.7 Implémentation des alarmes . . . . . . . . . . . . . . . . . . . . . 73
3.6.8 Application prototype . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4 Test et résultats 76
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2.1 Codesys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2.2 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3 Test de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.1 Test du lancement de l’application . . . . . . . . . . . . . . . . . . 81
 4.3.2 Test communication des données cycliques . . . . . . . . . . . . . 85
4.3.3 Test communication des données acycliques . . . . . . . . . . . . 87
4.3.4 Test des alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.4 Performance temps réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4.1 Performance avec un noyau standard . . . . . . . . . . . . . . . . 90
4.4.2 Performance avec noyau temps réel . . . . . . . . . . . . . . . . . 92
4.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Conclusion générale 94

Bibliographie 95

Annexes 97
.1 Annexe A : Code application en C . . . . . . . . . . . . . . . . . . . . . . 98
.2 Annexe B : Script python pour capteur . . . . . . . . . . . . . . . . . . . . 105
.3 Annexe C : GSD file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
.4 Annexe D : Script linux pour test de performance . . . . . . . . . . . . . 108
.5 Annexe E : IEEE754 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Liste des tableaux

1.1 Exemples bus de terrain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.1 Éléments du protocole profinet . . . . . . . . . . . . . . . . . . . . . . . . 37

2.2 Étapes d’envoi d’une alarme . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3 Trames envoyées pendant le démarrage . . . . . . . . . . . . . . . . . . . 46
2.4 Type de service DCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.5 Service ID DCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table des figures

1.1 Exemple d’un système numérique de contrôle-commande . . . . . . . . 17

1.2 Représentation d’un système de contrôle-commande . . . . . . . . . . . 18
1.3 Automate programmable compact PLC SIEMENS S7-1200 . . . . . . . . 19
1.4 Débitmètre massique avec ethernet industriel (PROFINET) . . . . . . . . 20
1.5 Système de contrôle direct vers Systèmes de contrôle distribué . . . . . 21
1.6 Boucle de courant 4-20 mA . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.7 Fabrication intégrée par ordinateur CIM . . . . . . . . . . . . . . . . . . . 23
1.8 Le marché mondial par protocole Ethernet 2018 . . . . . . . . . . . . . . 25
1.9 Les CRs sur PROFINET selon le principe producteur/consommateur . 26

2.1 Les composants d’un réseau PROFINET . . . . . . . . . . . . . . . . . . . 29

2.2 Intégration d’un IO Device PROFINET . . . . . . . . . . . . . . . . . . . . 29
2.3 Modèle IO device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 Structure de Conformance Classes . . . . . . . . . . . . . . . . . . . . . . 32
2.5 Modèle OSI dans PROFINET . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6 Composition du cycle d’envoi . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.7 Origine de l’overhead lors de l’encapsulation des données . . . . . . . . 34
2.8 Trame Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.9 Construction d’une trame PROFINET temps réel . . . . . . . . . . . . . . 36
2.10 Priorisation de la trame avec le tag VLAN . . . . . . . . . . . . . . . . . . 38
2.11 TCP vs UDP communication . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.12 Application relations (AR) et connexion entre IO controller et IO device 39
2.13 Échange de donnée dans un CR . . . . . . . . . . . . . . . . . . . . . . . . 40
2.14 Transmission de données cycliques avec le protocole RT pour Profinet . 40
2.15 Transmission de données cycliques avec le protocole RT pour Profinet . 41
2.16 Services acyclique read/write services Profinet IO . . . . . . . . . . . . . 42
2.17 Liste des I&Ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.18 Alarmes avec différentes priorités . . . . . . . . . . . . . . . . . . . . . . . 43
2.19 Attribution adresse IP à l’aide du protocole DCP . . . . . . . . . . . . . . 45
2.20 Etablissement de la connexion CM (Context management) . . . . . . . . 45

3.1 Canaux PROFINET et utilisation dans l’application . . . . . . . . . . . . 50

3.2 Raspberry pi 3 model B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3 Comparaison de latence entre un noyau standard et un noyau temps réel 56
3.4 CMake logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.5 GCC GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.6 Norme IEEE 754 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.7 Couche du programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.8 Machine d’état alarme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.9 DHT11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.10 Valeur du capteur sous format IEEE754 dans le fichier . . . . . . . . . . . 71

4.1 Prototype du setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.2 Configuration de la raspberry qui simule le PLC . . . . . . . . . . . . . . 78
4.3 Interface du logiciel après ajout des composants . . . . . . . . . . . . . . 79
4.4 Paramètrage de l’interface ethernet de la raspberry simulé en PLC . . . . 79
4.5 Paramètre de la plage d’adresse des IO devices . . . . . . . . . . . . . . . 80
4.6 Paramétrage de l’IO device à travers le logiciel . . . . . . . . . . . . . . . 80
4.7 Première trame DCP broadcast . . . . . . . . . . . . . . . . . . . . . . . . 81
4.8 Première trame DCP broadcast en octets . . . . . . . . . . . . . . . . . . . 81
4.9 Deuxième trame DCP confirmant le nom de l’IO device . . . . . . . . . . 82
4.10 Deuxième trame DCP en octets . . . . . . . . . . . . . . . . . . . . . . . . 82
4.11 Troisième trame DCP qui montre l’envoi de l’adresse IP . . . . . . . . . . 83
4.12 Troisième trame DCP en octets . . . . . . . . . . . . . . . . . . . . . . . . 83
4.13 Dernière trame DCP confirmant la réception des paramètres par l’IO
device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.14 Dernière trame DCP en octets . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.15 Trame LLDP de l’IO device . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.16 Trame donnée cyclique de l’IO controller à l’IO device . . . . . . . . . . . 85
4.17 Trame donnée cyclique de l’IO controller à l’IO device en hexa . . . . . . 86
4.18 Trame donnée cyclique de l’IO device à l’IO controller . . . . . . . . . . . 86
4.19 Trame donnée cyclique de l’IO device à l’IO controller en hexa . . . . . . 86
4.20 Write response (écriture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.21 Read response (lecture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.22 Trame alarme notification . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.23 Trame alarme acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 89
4.24 Trame alarme réponse du PLC . . . . . . . . . . . . . . . . . . . . . . . . 89
4.25 Trame alarme acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 89
4.26 Latence avec noyau standard et sans taskset . . . . . . . . . . . . . . . . . 90
4.27 Latence avec noyau standard et taskset . . . . . . . . . . . . . . . . . . . 91
4.28 Latence avec noyau temps réel et sans taskset . . . . . . . . . . . . . . . . 92
4.29 Latence avec noyau temps réel et taskset . . . . . . . . . . . . . . . . . . . 93
30 Représentation en mémoire d’un nombre au format IEEE 754 . . . . . . . 110
Liste des abréviations

IO Input/Output

SNCC Système numérique de contrôle-commande

PLC Programmable Logic Controller

GSD General Station Description

I&M Identification Maintenance

CIM Computer-Integrated Manufacturing

CC Conformance Classes

OSI Open Systems Interconnection

UDP User Datagram Protocol

IP Internet Protocol

RTC Real Time Class

VLAN Virtual Local Area Network

MAC Media Access Control

AR Application Relation

CR Communication Relation

IOCS Input/Output Consumer Status

IOPS Input/Output Provider Status

CM Context Management

LLDP Link Layer Discovery Protocol

DCP Discovery and Configuration Protocol

TCP Transmission Control Protocol

XML Extensible Markup Language

Introduction

Au cours des dernières années, la transition vers le numérique a été la priorité des
services publics, entreprises et industries, les efforts sont justifiables au vu des avan-
tages qu’offre la digitalisation de nos informations. Il a été donc nécessaire d’adapter
les équipements et machines afin d’assurer la possibilité de traitement de données nu-
mériques et de communication à l’aide de divers protocoles qui nous permettent le
transfert et l’acquisition d’informations.
Cette philosophie du passage vers le numérique a rapidement été adoptée par
les industriels, d’où le partitionnement des différentes périodes de l’industrie, nous
sommes actuellement dans l’ère de l’industrie 4.0 qui est caractérisée par l’utilisation
d’outils numériques qui permettent l’optimisation et le contrôle des processus indus-
triels.
Parmi les entreprises qui ont mené ces changements, Siemens, ABB, allen and
bradley ont joué un rôle important dans la conception et la commercialisation d’équi-
pements d’automation industrielle. La diversité des automates disponibles a permis
la création de différents protocoles de communication, chacun propre à une certaine
gamme de produits ou marques. Ces protocoles de communication permettent aux
dispositifs électroniques, représentés sous forme de système embarqué, dans un envi-
ronnement industriel où ils contrôlent des machines et capteurs, d’être interconnectés
dans un réseau permettant la communication entre les différents périphériques.
L’un des fournisseurs d’automates les plus influents SIEMENS a profité du dé-
veloppement de l’un des protocoles les plus utilisées, ethernet en l’occurence , pour
concevoir le protocole PROFINET qui est basé sur cette technologie. Ce genre de pro-
tocole sera nommé ethernet industriel au vu de son utilisation dans un environnement
industriel avec des contraintes de temps réel et de déterminisme.
Le but de ce travail est la conception d’un IO device sur système embarqué com-
muniquant à l’aide du protocole de communication PROFINET.

14
Introduction

Ce document est organisé comme suit :

• Chapitre 1 (Aperçu global sur PROFINET)

Dans ce chapitre, on introduit les concepts de base du protocole PROFINET en présen-
tant les notions fondamentales y afférant ainsi qu’une description de l’environnement
où il est utilisé.

• Chapitre 2 (Protocole de communication PROFINET)

Dans ce chapitre, le protocole de communication PROFINET est abordé avec plus de
détails relatifs à ses caractéristiques et ses fonctionnalités.

• Chapitre 3 (Implémentation du protocole PROFINET)

Dans ce chapitre, on aborde les choix matériels considérés ainsi que les étapes
nécessaires à l’implémentation de la librairie p-net pour le développement d’une
application pour un cas pratique en respectant les contraintes de temps réel du
protocole PROFINET .

• Chapitre 4 (Tests et résultats)

Dans ce chapitre, nous présentons les tests effectués sur notre système après implé-
mentation puis nous procédons à l’analyse des résultats obtenus.

• Conclusion générale
Dans la conclusion générale, on énumère les principaux résultats de notre travail et on
présente des perspectives.

15
Chapitre 1

Aperçu global sur PROFINET

Chapitre1

1.1 Introduction

Dans l’optique de transition vers le numérique, les systèmes de contrôles et de

commandes n’ont cessé d’évoluer, entrainant avec eux le développement de concepts
et d’outils qui ont contribué à la numérisation de l’environnement industriel.
Cet environnement a engendré l’émergence de nouvelles technologies, parmi
elles le développement de protocoles de communication afin d’assurer la communi-
cation entre les différents équipements industriels. L’un des protocoles qui a été dé-
veloppé par SIEMENS et qui s’est caractérisé par son utilité dans des applications à
contraintes de temps réel et ses riches fonctionnalités, est le protocole PROFINET.
Ce chapitre a pour but d’introduire les notions de base concernant le protocole
PROFINET ainsi que les concepts associés.

1.2 Définition

L’automatisation des procédés industriels a été une priorité pour les entreprises,
elle a permis l’accroissement de la productivité, en plus de l’amélioration de la flexibi-
lité et la qualité des produits.
Une installation industrielle typique dispose de capteurs et actionneurs qui se-
ront contrôlés à l’aide de PLC et d’interface Humain-Machine, on peut alors parler de
système numérique de contrôle-commande (SNCC), les équipements de commande
d’un SNCC sont distribués ou géo-répartis, et disposent de protocoles de communica-
tion qui assure l’intéraction entre les différents équipements du système.

F IGURE 1.1 – Exemple d’un système numérique de contrôle-commande

17
Chapitre1

1.2.1 Système numérique de contrôle-commande :

Un système de contrôle-commande permet le pilotage d’un procédé industriel

physique au travers des fonctions de commande, de surveillance et de supervision
(figure 1.2). La commande a un rôle opérationnel qui consiste à faire exécuter un en-
semble d’opérations pour agir sur le procédé physique [1].
La surveillance a un rôle informationnel qui porte sur le recueil des signaux pro-
venant du procédé, de la commande et le traitement des défaillances. La supervision
a un rôle décisionnel qui permet d’optimiser, en présence ou non de défaillances, le
fonctionnement du système. L’interaction du système de contrôle-commande avec le
procédé physique est réalisée, d’une part, par des observations à travers des capteurs,
et d’autre part, par des actions réalisées par l’intermédiaire d’actionneurs (figure 1.2).
Les capteurs permettent de transformer les grandeurs physiques du procédé maté-
riel en signaux électriques interprétables par le système de contrôle-commande. Les
actionneurs (moteurs, transformateurs...) permettent de transformer les commandes
électriques du système de contrôle-commande, en ordres qui permettent d’agir sur le
procédé physique en changeant son état[2].

F IGURE 1.2 – Représentation d’un système de contrôle-commande

1.2.2 Programmable logic controller (PLC)

Un automate programmable (PLC) est un type particulier d’ordinateur. Même

dans les environnements industriels difficiles, les automates sont incroyablement
fiables. Un automate programmable est un contrôleur polyvalent qui utilise des don-
nées provenant d’un ensemble d’entrées, les traite par le biais d’une série de logiques
préprogrammées et envoie une sortie physique en fonction des résultats de cette lo-
gique. Par conséquent, ces contrôleurs peuvent automatiser le fonctionnement d’une
machine, d’un processus ou d’une chaîne de fabrication entière.

18
Chapitre1

Il fonctionne comme le "cerveau" d’un système de contrôle, et peut donc interpréter

les données lues en input et décider de ce qui doit se passer une fois qu’il a été correc-
tement programmé. En fonction de cette décision, il manipule ensuite les signaux de
sortie. Les équipements situés sur le terrain sont connectés à ces signaux de sortie. Il
peut s’agir par exemple d’un interrupteur de démarrage/arrêt ou d’un IO device.

F IGURE 1.3 – Automate programmable compact PLC SIEMENS S7-1200

1.2.3 IO device (Appareil de terrain)

Ces dispositifs intègrent l’intelligence requise pour les techniques de détection et

de contrôle simples . Ils remplacent donc le besoin d’un contrôleur pour effectuer les
tâches basiques habituellement réalisées par un PLC.
Ils peuvent être directement connectés à un bus de terrain, ce qui permet de trans-
mettre de multiples mesures à la station de contrôle de niveau supérieur suivante via
une ligne de transmission numérique, en éliminant le matériel superflu tel que les mo-
dules locaux connectés au PLC.
Ces IO devices décentralisés relient des capteurs et des actionneurs binaires et
analogiques au contrôleur mobile. Ils permettent l’évaluation décentralisée des si-
gnaux des capteurs et la commande d’actionneurs ou de vannes proportionnelles. La
sortie des données et le réglage des fonctions de l’appareil se font via un bus d’inter-
face.

19
Chapitre1

F IGURE 1.4 – Débitmètre massique avec ethernet industriel (PROFINET)

1.3 Bus de terrain

Le bus de terrain est un système de réseau industriel pour le contrôle distribué

en temps réel. C’est un réseau de communication numérique reliant différents types
d’équipements d’automatisme intelligents ou à intelligence limitée pour permettre
leur coopération tel que : les capteurs, les actionneurs, les automates programmables,
les machines à commande numérique, les robots ...etc. Dans les réseaux de terrain,
la taille des messages échangés est assez faible comparativement aux autres types de
réseaux, locaux ou à grandes distances. Les flux d’information sont plutôt périodiques
et l’aspect contrainte de temps (temps réel) est prioritaire.

• Avantages des réseaux de terrain

Le but initial des bus de terrain était de remplacer les anciens systèmes centra-
lisés en distribuant le contrôle, le traitement des alarmes, le diagnostic aux différents
équipements qui sont devenus de plus en plus intelligents.

Les anciens systèmes de communication industriels utilisaient la boucle de cou-

rant 4-20 mA, qui est un moyen de transmission analogique permettant d’envoyer un
signal analogique sur une grande distance sans perte ou modification, pour relier les
équipements aux machines de contrôle.[3]

20
Chapitre1

F IGURE 1.5 – Système de contrôle direct vers Systèmes de contrôle distribué

F IGURE 1.6 – Boucle de courant 4-20 mA

Après l’apparition de la communication numérique, cette technique a été rapide-

ment remplacée par les bus de terrain. Leurs utilisation offre plusieurs avantages :

•Réduction des coûts initiaux :

- Réduction massive du câblage : un seul câble en général pour tous les équipements
au lieu d’un cable par équipement.
- Possibilité de réutiliser le câblage analogique existant dans certains cas.
- Réduction du temps d’installation.
- Réduction du matériel nécessaire à l’installation.

•Réduire le coût d’exploitation en :

- Augmentant les performances de l’automatisme.
- Réduisant les coûts des extensions futures.

•Réduction du coût de maintenance :

- Complexité moindre donc moins de maintenance (fiabilité accrue).
- Maintenance plus facile : temps de dépannage réduit, localisation des pannes pos-
sibles grâce à des diagnostics en ligne donc à distance.
- Outils de tests dédiés.

21
Chapitre1

- Flexibilité pour l’extension du bus de terrain et pour les nouveaux raccordements.

• Performances :
- Précision : la donnée numérique transférée est immunisée contre le bruit et la
distorsion contrairement à un signal analogique.
- Les données et mesures sont généralement disponibles à tous les équipements de
terrain.
- La Communication est possible entre deux équipements sans passer par le système
de supervision.
- La structure distribuée permet de faire résider des algorithmes de contrôle au niveau
de chaque équipement de terrain.[4]

1.3.1 Ethernet industriel

• Protocole ethernet
Ethernet est un protocole de réseau local à commutation de paquets. C’est une
norme internationale : ISO/IEC 802-3.
Après avoir été utilisé pour les applications purement bureautiques, Ethernet est
entré dans le monde industriel par le haut de la pyramide CIM. Dans un premier
temps, il a servi à connecter les superviseurs aux automates ce qui a amélioré les per-
formances tout en supprimant des cartes de communications spécifiques. Il a ensuite
remplacé les anciennes connexions inter-automates.
Aujourd’hui il est descendu au niveau hiérarchique des bus de terrain et l’essen-
tiel de la périphérie automate : IO devices, variateurs, codeurs, IHM . . . est disponible
sous Ethernet. Pour résumer on peut affirmer que désormais la majorité des équipe-
ments compatibles avec les bus de terrain traditionnels tels que PROFIBUS, Modbus,
DeviceNet, CANopen . . . existent également dans une version Ethernet industriel.

22
Chapitre1

F IGURE 1.7 – Fabrication intégrée par ordinateur CIM

• Comparaison entre Ethernet industriel et Bus de terrain classique

l’Ethernet industriel dispose de sérieux atouts qu’il convient d’évaluer.
1- Vitesse : Le bus de terrain classique le plus rapide PROFIBUS fonctionne à la
vitesse maximale de 12 Mb/s,alors que la plupart des protocoles basés sur l’Ethernet
industriel dispose d’une vitesse de 100Mb/s. Un atout pour les applications exigeantes
en temps de réponse.
2- Séparation galvanique : Sur un bus de terrain, tous les équipements d’un même
segment utilisent le même média. Une anomalie sur un équipement, un connecteur ou
le câble peut affecter la communication de l’ensemble des stations. Avec Ethernet, le
média n’est pas partagé, une anomalie n’affectera que la station concernée par le lien.
3- Résistance aux perturbations électromagnétiques : Ethernet s’avère plus ro-
buste qu’un bus de terrain par rapport aux perturbations électromagnétiques, ce qui
ne veut pas dire qu’il est totalement insensible.
4- Cohabitation de protocoles : Il n’est pas possible de faire cohabiter sur un même
câble des équipements PROFIBUS et Modbus même si les 2 fonctionnent sur RS485.
Grâce à Ethernet, il est possible sur un même réseau de connecter par exemple des
stations PROFINET et MODBUS-TCP tout en utilisant ce même réseau pour consulter
une page web et envoyer un mail.
5- L’accès aux technologies IT : La plupart des équipements Ethernet industriel
disposent d’un serveur Web. Un simple navigateur suffit pour configurer ou diagnos-
tiquer l’appareil. Certains appareils peuvent envoyer automatiquement un mail pour
signaler un défaut ou une opération de maintenance.

23
Chapitre1

6- Accessibilité : La technologie Ethernet permet d’accéder beaucoup plus

facilement à l’appareil y compris à distance, que s’il se trouvait sur un bus serial.[4]

1.3.2 Exemples de bus de terrain

Les différents bus de terrain offrent une multitude de caractéristiques et des per-
formances variées. Il est difficile de faire une comparaison générale des performances
des bus de terrain en raison des différences fondamentales dans la méthodologie de
transfert des données. Dans le tableau comparatif ci-dessous, les différents bus de ter-
rains avec leurs caractéristiques.

Bus de terrain Bus power Redondance Max device Synchronisation

EtherNet/IP Non Optionnelle Illimité Oui

Modbus Non Non 246 Non
PROFIBUS DP Non Optionnelle 126 Oui
PROFINET IO Non Optionnelle Illimité Non
EtherCAT Oui Oui 65,536 Oui
ControlNet Oui Oui 99 Non
AFDX Oui Oui Illimité Non
CANopen Non Non 127 Oui

TABLE 1.1 – Exemples bus de terrain

1.3.3 Profinet

PROFINET est l’évolution du réseau PROFIBUS DP vers une base Ethernet. On

y retrouve certains des concepts de base qui ont permis à PROFIBUS de devenir le
leader du marché (Simplicité de mise en œuvre, principe de diagnostic, fichiers des-
criptifs. . . ) tout en améliorant les performances et en intégrant les services propres aux
technologies IT.
• Normes et standards
Les spécifications PROFINET figurent dans les documents IEC 61158 type 10 et
IEC 61784.

24
Chapitre1

Par ailleurs PROFINET exploite des fonctions et services IT ayant déjà fait l’objet
de standardisation pour des applications informatiques classiques (Web, FTP, RSTP,
SNMP, 802.1Q . . . ).
• Marché
PROFINET est aujourd’hui une réelle alternative à PROFIBUS DP mais aussi aux
autres bus de terrain traditionnels.
Du point de vue de la performance, la supériorité d’un réseau Ethernet tel que
PROFINET est évidente. Cependant beaucoup d’installations n’ont pas un besoin im-
médiat d’amélioration en termes de vitesse, taille de données ou nombre de stations.
Si PROFINET séduit de plus en plus d’utilisateurs c’est que l’offre en matériel est
de plus en plus large et que le prix d’une architecture Ethernet est désormais tout à fait
compétitif.
Porté par ses atouts technologiques mais également par le support de grands
acteurs de l’automatisme, PROFINET occupe la place de leader au sein des réseaux
Ethernet industriels avec 29% de part de marché [5].

F IGURE 1.8 – Le marché mondial par protocole Ethernet 2018

Source :IHSMarkit|Technology

25
Chapitre1

1.3.4 Communication

PROFINET échelonne la communication sur trois niveaux de performances :

• L’échange cyclique de données avec des contraintes de temps réel.
• L’échange de données acycliques pour la lecture et l’écriture de données selon
les besoins (paramètres et données diagnostic).
• Un modèle d’alarme flexible pour la signalisation de défaillances avec trois ni-
veaux d’alarme (besoin de maintenance, besoin de maintenance urgente et diagnostic).

F IGURE 1.9 – Les CRs sur PROFINET selon le principe producteur/consommateur

1.4 Conclusion

Nous avons vu dans ce chapitre la constitution d’un système de contrôle-

commande et abordé chaque composant faisant partie d’un SNCC ainsi que les bus de
terrain. Étant donné la popularité et les performances du protocole PROFINET, notre
choix s’est porté sur la conception d’un IO device qui sera apte à communiquer avec
un PLC à l’aide de ce protocole.

26
Chapitre 2

Protocoles de communication
PROFINET
Chapitre2

2.1 Introduction

Profinet permet l’interfaçage direct d’appareils de terrain distribués sur l’Ether-

net. Tous les appareils utilisés sont connectés sur le même réseau, et offrent donc une
communication uniforme sur l’ensemble de l’usine de production. Profinet spécifie
l’échange complet de données entre les IO controllers et les IO devices, ainsi que leurs
paramétrages et leurs diagnostics. Il est conçu pour un échange de données rapide
avec des cycles de quelques millisecondes, et est basé sur un modèle fournisseur/con-
sommateur.

2.2 Équipements et intégration :

2.2.1 Constituants d’un réseau PROFINET

PROFINET suit le modèle fournisseur/consommateur pour l’échange de don-

nées. Cela signifie que l’IO controller et L’IO device envoient des données cycliques
indépendamment.
Les classes d’appareils se présentent comme suit :
• IO controller
Il s’agit généralement d’un automate programmable (PLC) dans lequel s’exécute
le programme d’automatisation. Le IO controller fournit des données de sortie aux IO
devices configurés, en tant que fournisseur et est le consommateur d’entrées venant de
celui-ci
• IO device
Un IO Device est un appareil de terrain distribué qui échange des données avec
un ou plusieurs IO Controllers en utilisant les mécanismes de Profinet. Une configura-
tion Profinet contient au moins un IO Device.
• IO supervisor
Une station d’ingénierie permettant la configuration et le diagnostic d’un réseau
PROFINET, typiquement un logiciel sur PC [6]

28
Chapitre2

F IGURE 2.1 – Les composants d’un réseau PROFINET

2.2.2 Intégration des équipements PROFINET

À chaque équipement PROFINET (IO Device) est obligatoirement associé, un fi-

chier descriptif de type GSD qui comporte les informations nécessaires pour que l’IO
Supervisor puisse les intégrer dans I’IO Controller. Les différentes étapes de l’ingénie-
rie se présentent comme suit :

F IGURE 2.2 – Intégration d’un IO Device PROFINET

1- Les fichiers descriptifs (GSD) des différents équipements sont chargés dans la
bibliothèque de l’IO Supervisor.
2- La configuration du réseau PROFINET et paramétrage des IO Devices.
3- Le transfert du projet dans l’IO Controller.
4- L’IO Controller vérifie la présence et l’identité des IO Devices et leur envoie
leurs paramètres. Les stations passent ensuite en échange de données. [5]

29
Chapitre2

2.2.3 Modules et submodules

Les modules sont positionnés dans des slots, les submodules dans des subslots.
Le remplacement, sans reconfiguration au préalable, des modules et des sous-modules
est donc possible. La différence entre un dispositif "modulaire" et un dispositif "com-
pact" est simplement que les fentes avec leurs modules/sous-modules sont fixes dans
un dispositif compact. Les adresses de device/slot/subslot peuvent être appliqués à
n’importe quelle architecture de dispositifs [7] .

F IGURE 2.3 – Modèle IO device

2.2.4 GSD file

Chaque fournisseur d’un end device doit fournir un fichier GSD associé. Ce fi-
chier décrit les propriétés de l’appareil concerné. cependant, le fichier est présent dans
un fichier XML. Dans Profinet, le terme Generic Station Description Markup Language
(GSDML) est également utilisé.
La structure et les règles d’un fichier GSD sont définies par le schéma GSDML
qui est administré par Profibus International et qui contient les règles de validité qui
permettent, par exemple, de vérifier la syntaxe d’un fichier GSD.

30
 Chapitre2

1 +−− P r o f i l e H e a d e r
2 +−− P r o f i l e B o d y
3 |
4 +−− D e v i c e I d e n t i t y
5 | |
6 | +−− I n f o T e x t
7 | +−−VendorName
8 |
9 +−−DeviceFunction
10 | |
11 | +−−Family
12 |
13 +−− A p p l i c a t i o n P r o c e s s
14 |
15 +−− D e v i c e A c c e s s P o i n t L i s t
16 +−−ModuleList
17 +−−SubmoduleList
18 +−− V a l u e L i s t
19 +−−LogBookEntryList
20 +−− C a t e g o r y L i s t
21 +−−ChannelDiagList
22 +−−ChannelProcessAlarmList
23 +−−UnitDiagTypeList
24 +−− E x t e r n a l T e x t L i s t

2.2.5 Conformance classes

PROFINET offre un grand nombre de fonctions. Ces fonctions sont divisées en

classes de conformité de manière claire. Elles fournissent un résumé pratique des dif-
férentes fonctionnalités de l’IO device.
Il existe trois Conformance Classes (CC) :
•La Conformance Class A (CC-A) fournit des fonctions de base pour PROFINET avec
une communication en temps réel (RT). Tous les services informatiques peuvent être
utilisés sans restriction. Les applications typiques se trouvent, par exemple, dans l’au-
tomatisation des entreprises. La communication sans fil est spécifiée pour cette classe.
• La classe de conformité B (CC-B) étend PROFINET pour inclure des diagnostics de
réseau utilisant des mécanismes IT et des informations de topologie du réseau.
• Conformance Class C (CC-C) décrit les fonctions de base pour les appareils avec

31
Chapitre2

réservation de bande passante et synchronisation supportées par le matériel. La com-

munication Isochronous Real-Time (IRT) est disponible.

F IGURE 2.4 – Structure de Conformance Classes

2.3 Communication PROFINET :

Les échanges entre IO device et IO controller utilisent différents canaux selon le

type de données :
• Canal temps réel pour les E/S cycliques et les alarmes .
• Canal standard UDP/IP pour le paramétrage, la configuration .

2.3.1 Modèle OSI et profinet

Le protocole PROFINET respecte l’organisation en 7 couches du modèle OSI.

• Pour la communication en temps réel (cyclique et alarmes), on utilise directe-
ment la couche ethernet sans utiliser les autres couches , et cela afin de minimiser le
temps d’encapsulation du paquet et de respecter les contraintes de temps réel.
• Le canal standard utilisé ,par exemple pour configurer une station ou faire
un diagnostic (acyclique), est basé sur la couche Réseau IP et la couche Transport
TCP/UDP en plus d’ethernet, la contrainte de temps réel est négligeable.
• L’équipement peut aussi avoir un trafic IT classique sans rapport avec PROFI-
NET, par ex. accéder à la page web de l’équipement.

32
Chapitre2

F IGURE 2.5 – Modèle OSI dans PROFINET

2.3.2 Temps réel

Le temps réel signifie qu’un système traite les événements externes dans un
temps défini. Si la réaction d’un système est prévisible, on parle d’un système détermi-
niste. Les exigences générales pour la communication en temps réel (RT) sont donc :
- Une réponse déterministe.
- Des temps de réponse définis, généralement jusqu’à 5ms pour les applications
standard.
Étant donné que la tâche principale du processeur est l’exécution du programme
utilisateur et non l’échange de données, la communication en temps réel sur Ethernet
ne doit entraîner qu’une charge insignifiante pour le processeur. Dans le même temps,
le cycle d’envoi, c’est-à-dire la durée d’une transmission de données de l’application
d’un dispositif A à l’application d’un appareil B, doit être aussi faible que possible. La
figure 2.6 montre les facteurs responsables du cycle d’envoi.

33
Chapitre2

F IGURE 2.6 – Composition du cycle d’envoi

L’une des possibilités de mise en œuvre de la communication en temps réel est

l’utilisation de protocoles de communication standard tels que TCP/IP. Cependant,
leur application est également associée à des inconvénients : l’encapsulation des trames
augmente leurs longueurs, et entraîne donc une augmentation du temps de transmis-
sion sur la ligne (Fig. 2.7).

F IGURE 2.7 – Origine de l’overhead lors de l’encapsulation des données

34
Chapitre2

Le protocole temps réel permet la transmission performante de données cycliques

et de messages contrôlés par des événements (alarmes). Il est divisé en trois classes
(RTC : real-time classes) :
- Classe temps réel 1 (RTC 1) : convient à la transmission de données cycliques et
acycliques. Aucune exigence particulière n’est imposée aux switchs utilisés.
- Classe temps réel 2 (RTC 2) : convient pour la transmission d’interruptions et de
données cycliques. Des switchs spéciaux doivent être utilisés dans ce cas.
- Classe temps réel 3 (RTC 3) : convient à la transmission de données cycliques
avec des applications de contrôle du mouvement. Des switchs spéciaux doivent égale-
ment être utilisés avec RTC 3, et une planification explicite de la communication doit
être effectuée à l’avance.

2.3.3 Ethernet

Le standard Ethernet est le protocole de la 2eme couche (liaison de donnée) le

plus répandu dans les réseaux locaux (LAN).
• Trame Ethernet de la 2eme couche :
La trame Ethernet est une unité de données du protocole de la couche liaison de
données et utilise les mécanismes de transport de la couche physique Ethernet sous-
jacente. , sa trame se présente sous cette forme :

F IGURE 2.8 – Trame Ethernet

- Chaque interface Ethernet possède une adresse fixe et unique intégrée par le
fournisseur. Cette adresse, appelée adresse matérielle ou MAC (Media Access Control),
est enregistrée sur la carte réseau et sert à l’identifier dans le réseau local.
- La case Ethertype nous permet de connaitre le type de trame envoyée ou reçue, voici
quelques exemples :
< 0x0600 : IEEE802.3 length block
0x0600 : Ethernet II type block

35
Chapitre2

0x0800 : IP
0x0806 : ARP
0x8100 : Tag Control Information ; data packets with VLAN-TPID
0x8892 : Profinet
0x88E3 : MRP
0x88CC : LLDP
- La partie Data contient les données envoyées.
- CRC (Contrôle de redondance cyclique) permet de détecter des erreurs de transmis-
sion.

2.3.4 Éléments du protocole Profinet

La communication en temps réel est basée sur le protocole ethernet de la

deuxième couche, la structure de la trame se présente sous cette forme :

F IGURE 2.9 – Construction d’une trame PROFINET temps réel

Afin de maintenir un faible retard de la trame pendant la communication, la

transmission de tous les services cycliques et acycliques se voient attribuer des priori-
tés par l’application du format de trame VLAN (balisage VLAN). À l’aide de l’élément
de protocole "priorité de l’utilisateur". La "priorité de l’utilisateur" peut avoir des va-
leurs comprises entre 0 (priorité la plus basse) et 7 (priorité la plus élevée). Les trames
Profinet en temps réel sont envoyées avec la priorité 6 ou 7.

36
Chapitre2

élément du protocole Exemples et explications

Ethernet II header Adresse MAC de la destination et de la source

VLAN-TAG VLAN Tag Protocol Identifier :
User Priority :
0x00 : IP, DCP
0x01 - 0x04 : Reservé
0x05 : RTA low-priority or UDP RTA low-priority
0x06 : RTC 1/2, UDP RTC (RT over UDP),
0x07 : PTCP, MRP, MRRT
CFI (Canonical Format Indicator) :
0 : Ethernet
1 : Token Ring
VLAN ID :
0x00 : Transmission de donnée avec priorité
0x001 : Standard setting
0x002-0xFFE : For free use
0xFFF : Reservé
Ethertype 0x8892 : Profinet
0x8100 : Tag Control Information VLAN-TPID
frameID RTC1, UDP RTC :
0xC000 – 0xF7FF : Unicast frames
0xF800 – 0xFBFF : Multicast frames
DCP :
0xFEFD : GetReq, SetReq, GetResp, SetResp
0xFEFE : IdentifyReq
0xFEFF : IdentifyResp
payload User data : dépend de l’IO device
APDU Status (Application Protocol Data Unit Status) :
Cycle counter :Le compteur est incrémenté par le provider à
chaque envoi.
Data status
Transfer status

TABLE 2.1 – Éléments du protocole profinet

37
Chapitre2

F IGURE 2.10 – Priorisation de la trame avec le tag VLAN

2.3.5 TCP/UDP

TCP et UDP s’exécutent au-dessus de l’IP et se fondent sur les services fournis
par ce dernier.
•TCP (Transport Control Protocol) assure un service de transmission de données
fiable avec une détection et une correction d’erreurs de bout en bout.
•UDP (User Datagram Protocol) offre un service de transmission de data-
grammes sans connexion.
Avec TCP ou UDP, il est possible de remettre des données à des processus d’applica-
tion s’exécutant sur une machine distante. Ces processus d’application sont identifiés
par numéros de port.

F IGURE 2.11 – TCP vs UDP communication

le protocole PROFINET communique dans les échanges de données acycliques à

l’aide d’un canal UDP.

38
Chapitre2

2.4 Principaux canaux

2.4.1 Application relation (AR)

Une "Application Relation" (AR) est un élément logique et virtuel qui permet
l’échange de données entre deux dispositifs sur des canaux de communication. La
transmission effective des données a lieu à l’intérieur de ces canaux au moyen d’une
ou de plusieurs "communications relations" (CR).
Plusieurs relations d’application peuvent être établies vers un IO Device à partir
de différents IO controllers.

F IGURE 2.12 – Application relations (AR) et connexion entre IO controller et IO device

2.4.2 Communication relation (CR)

Plusieurs relations de communication (CR) peuvent être établies au sein d’un AR.
Les types de CR suivants existent :
- Le CR de données d’E/S pour la transmission cyclique de données .
- Le CR Record data pour la transmission acyclique de record pour la mise en
service, le paramétrage, les diagnostics, etc.
- L’alarme CR pour la transmission acyclique d’événements.

39
Chapitre2

F IGURE 2.13 – Échange de donnée dans un CR

2.4.3 Communication cyclique

Les données IO cycliques sont transmises via le "IO data CR" en tant que données
en temps réel entre le fournisseur et le consommateur dans un laps de temps para-
métrable. Les temps de rafraichissement peuvent être spécifiés individuellement pour
les connexions aux différents appareils et sont ainsi adaptés aux exigences de l’appli-
cation. De même, différents temps de rafraichissement peuvent être sélectionnés pour
les données d’entrée et de sortie dans une plage de 250 µs à 512 ms.
Après le démarrage du système, les données d’E/S sont échangées cycliquement
entre le IO controller et l’IO device.
Chaque élément de données d’E/S contient deux attributs, les IOPS (IO Provider
Status) et IOCS (IO Consumer Status), qui permettent aux IO controller et IO device
d’évaluer la fiabilité des données.
L’IOPS est transmis par le fournisseur en même temps que les données et est donc
dépendant de son état.
En revanche, l’IOCS peut seulement être renvoyé par le consommateur au four-
nisseur qu’après la réception des données.

F IGURE 2.14 – Transmission de données cycliques avec le protocole RT pour Profinet

40
Chapitre2

IOCS et IOPS peuvent avoir les valeurs GOOD et BAD représentés dans la trame
en hexadécimal par 0x80 ou 0x00.
Comme norme, les sorties de l’IO controller sont toujours nommées output, et ceux de
l’IO device input, vice versa.

F IGURE 2.15 – Transmission de données cycliques avec le protocole RT pour Profinet

2.4.4 Communication acyclique

La transmission de données acycliques sert à échanger des données qui ne sont

pas critiques en termes de temps. Les services de lecture et d’écriture (Read/Write re-
cord) sont utilisés. L’échange de données acycliques a lieu dans le canal de communica-
tion NRT (NRT : non-real-time) en utilisant le protocole remote procedure calls (RPC),
basé sur UDP. Les services de lecture/écriture se composent toujours d’une demande
et d’une réponse ultérieure.
L’échange acyclique de données à l’aide de la fonction "record data CR" peut être
utilisé pour :
•La configuration des paramètres et d’autres configurations des IO devices.
•La lecture des informations d’état (Statut) et des données d’identification et de main-
tenance (I&M) permettant une identification unique des appareils, modules et sous-
modules et de leurs versions.

41
Chapitre2

F IGURE 2.16 – Services acyclique read/write services Profinet IO

F IGURE 2.17 – Liste des I&Ms

2.4.5 Alarmes

Les alarmes sont des données acycliques en temps réel qui doivent être envoyées
dans un délai défini.
Ce concept d’alarme couvre à la fois les événements définis par le système (tels
que le retrait et l’insertion de modules) et la signalisation de défauts détectés par l’IO
controller (par exemple, une tension, charge défectueuse ou une rupture de fil).
L’utilisateur peut définir des alarmes de processus correspondantes pour les mes-
sages du processus, par exemple un seuil de pression dépassé. Dans ce cas, le IO device
peut encore être opérationnel. Ces alarmes de processus peuvent avoir une priorité dif-
férente de celle des alarmes de diagnostic.

42
Chapitre2

F IGURE 2.18 – Alarmes avec différentes priorités

Exemple de type d’alarmes :

•Process alarm : L’alarme signale l’apparition d’un événement provenant d’un
processus, par exemple le dépassement d’un seuil de pression.
•Pull : l’alarme signale le retrait d’un module/sous-module.
•Plug : l’alarme signale l’insertion d’un module/sous-module.

Émetteur Protocole Contenu

IO-device PN-AL Alarm notification high, 1 byte user data

IO-controller PN-AL ACK-RTA-PDU
IO-controller PN-AL Alarm ack high, alarm type Process, slot, subslot, Status OK
IO-device PN-AL ACK-RTA-PDU

TABLE 2.2 – Étapes d’envoi d’une alarme

43
Chapitre2

2.5 Démarrage (startup)

2.5.1 Context management (CM)

Le rôle du context management (CM) est de gérer les AR et CR. Il s’occupe de :

- L’initialisation des applications relations (AR).
- L’initialisation des communications relations (CR).
- La définition de paramètres de communication adéquats pour les relations de
communication, par exemple les délais et les modes de fonctionnement.
- Paramétrage de l’Ethernet device driver (EDD).
- Distribution des paramètres décrits dans le fichier GSD.

2.5.2 Le lancement en différentes étapes

Dans un réseau PROFINET, chaque appareil reçoit un nom symbolique qui

identifie de manière unique l’appareil. L’appareil est identifié et configuré avec ce nom
au cours du processus d’ingénieurie. Les adresses MAC et IP exactes sont configurées
à l’aide de ce nom lorsque l’application PROFINET est lancée.
•Attribution d’un nom à un IO device :
L’IO device se voient attribuer un nom avant l’établissement effectif d’une connexion.
Le nom est attribué par un IO supervisor et enregistré en mode permanent dans l’IO
device. Le nom est utilisé pour l’identification univoque d’un IO device pendant le
runtime.

•Au démarrage d’un appareil Profinet IO (avant que l’adresse IP ne soit définie),
le protocole DCP est utilisé.
1- L’automate envoie un message de diffusion (broadcast) DCP.
2- Tous les IO devices du sous-réseau répondent en indiquant leur adresse MAC.
3- L’automate envoie un message DCP à l’IO device avec une adresse MAC spécifique,
contenant l’adresse IP et le nom de la station que l’IO device doit utiliser.
4- L’IO device définit son adresse IP et son nom de station en conséquence et confirme
en envoyant une requête DCP à l’IO controller.

44
Chapitre2

F IGURE 2.19 – Attribution adresse IP à l’aide du protocole DCP

•Établissement de la connexion
Un CR de données IO est établi par une séquence de connexion entre l’IO controller
et l’IO device. La demande d’écriture suivante lance son paramétrage, qui se termine
par la demande DControl suivante. Suite à la réponse positive à la demande CControl
envoyée par l’IO device, la connexion est établie.

F IGURE 2.20 – Etablissement de la connexion CM (Context management)

•Trames Ethernet envoyées pendant le démarrage :

Dans cet exemple, l’IO controller est démarré en premier, puis l’IO device.

45
Chapitre2

Sender Protocol Content

IO-controller LLDP Nom, MAC, IP addr, port (envoyé chaque 5 secondes)

IO-controller PN-DCP “Ident req”. cherche “rt-labs-dev” (envoyé chaque 2.5 seconds)
IO-controller ARP Qui utilise mon IP ?
IO-device LLDP Nom, MAC, IP addr, port (envoyé chaque 5 secondes)
IO-device PN-DCP Station name,IP addr, gateway,vendeur r(chaque 3 seconds)
IO-device PN-DCP “Ident OK” Identify response.
IO-controller PN-DCP “Set Req” Set IP request. Utilise IP addr et gateway.
IO-device PN-DCP “Set OK” Status.
IO-controller ARP Qui a <IO-device IP address> ?
IO-device ARP IP <IO-device IP address> est à <IO-device MAC address>
IO-controller PNIO-CM “Connect request” Controller MAC
IO-device PNIO-CM “Connect response” MAC address, UDP port
IO-device PNIO-PS FrameID 0x8001. Cycle counter, provider stopped. 40 bytes data.
IO-controller PNIO-PS FrameID 0x8000. Cycle counter, provider running. 40 bytes data.
IO-controller PNIO-CM “Write request” API, slot, subslot, data.
IO-device PNIO-CM “Write response” API, slot, subslot, status.
IO-controller PNIO-CM “Control request” (DControl). Command : ParameterEnd.
IO-device PNIO-CM “Control response” Command : Done
IO-device PNIO-PS FrameID 0x8001. Cycle counter, provider running. 40 bytes data.
IO-device PNIO-CM “Control request” (CControl). Command : ApplicationReady
IO-controller PNIO-CM “Control response” Command : ApplicationReadyDone

TABLE 2.3 – Trames envoyées pendant le démarrage

2.5.3 Protocoles utilisés

•LLDP (Link Layer Discovery Protocol) :

Pendant le démarrage, les appareils commencent à échanger des informations LLDP
et les informations de topologie peuvent être lues. Cette topologie sera enregistré dans
l’appareil de terrain. Si des changements dans la topologie sont détectés, le contrôleur
recevra une alarme de la station affectée.
•DCP (Discovery and basic Configuration Protocol) :

46
Chapitre2

Il est utilisé par l’IO controller pour découvrir et identifier les informations sur les IO
devices et configurer les paramètres tels que le nom du périphérique PROFINET et
l’adresse IP sur un réseau PROFINET. PROFINET DCP est un protocole de couche de
liaison Ethernet et offre de multiples services tels que ‘Identify All’, ‘Identify’, ‘Set’, Set
– ‘Flash’, Set – ‘Reset to Factory’, ‘Get’ et ‘Hello’.
-DCP Identify All : Il nous permet d’identifier/naviguer dans le réseau PROFINET et
de trouver tous les appareils PROFINET attachés.
-DCP Identify : Il est utilisé lorsqu’un appareil doit être trouvé à l’aide d’un nom d’ap-
pareil particulier ou connu.
-DCP Set : Il est utilisé pour définir le nom ou l’adresse IP de l’appareil.
-DCP ‘Set / Reset to Factory’ : Le service ’Set / Reset to Factory’ est une commande
spéciale qui place l’appareil dans un état d’usine PROFINET (par défaut) qui est un
nom vide ("") et des paramètres IP de [Link].
-DCP Get : Le service "Get" est utilisé pour obtenir des informations d’un appareil.
Ce tableau nous permettra de distinguer le type de service de la trame DCP :

Type de service Description

0 Request
1 Response Success

TABLE 2.4 – Type de service DCP

Service ID Description
3 Request
4 Response Success
5 Response Success

TABLE 2.5 – Service ID DCP

•ARP (Address Resolution Protocol) :

ARP est un protocole Internet qui relie une adresse IP à une adresse physique (adresse
MAC Ethernet). Chaque station disposant d’une adresses IP dans le réseau gère une
table de résolution d’adresse à cette fin. Les paires déjà attribuées d’adresses IP et MAC
sont implicitement stockées dans cette table, appelée cache ARP.

47
Chapitre2

2.6 Conclusion

Dans ce chapitre, nous avons présenté le fonctionnement du protocole PROFI-

NET que ce soit en communication, les étapes du démarrage, ainsi que différentes no-
tions qui constitueront une base pour la suite du projet. Pour la conception de notre IO
device, nous nous limiterons à un device de classe B communiquant en RT1 (real time
class 1).

48
Chapitre 3

Implémentation du protocole
PROFINET
Chapitre3

3.1 Introduction

Pour exploiter les fonctionnalitées du protocoles PROFINET de façon optimale,

Nous allons implémenter sur un système embarqué un IO device exécutant des tâches
sur les canaux cycliques , acycliques et des alarmes, cette application aura la spécifi-
cité de transmettre les données lues d’un capteur en temps réel sur le canal cyclique,
paramétrer le temps entre chaque lecture du capteur et un seuil sur le canal acyclique,
qui en cas de dépassement , engendrera une alarme qui sera lancée en temps réel sur
le canal adéquat.

F IGURE 3.1 – Canaux PROFINET et utilisation dans l’application

L’implémentation se fera sur embedded linux en utilisant la librairie p-net, il est

cependant possible de l’utiliser sur un microprocesseur bare-metal ou à l’aide d’un
RTOS mais cela nécessite l’utilisation d’un RTOS fourni par rt-labs, ou l’adaptation
des API de celui-ci avec un RTOS standard (FreeRTOS par exemple).

L’une des problématiques rencontrées est l’adaptation du système d’exploitation

linux pour qu’il respecte les contraintes de temps réel.

3.2 Hardware utilisé

L’implémentation d’un IO device nécessite un hardware qui dispose des capaci-

tés minimales suivantes :
• Il doit être possible d’envoyer et de recevoir des trames Ethernet brutes.
• Il doit être possible de stocker des données entre deux exécutions, dans un système
de fichiers ou une mémoire non volatile.
• Pour la CC (Class conformance) B, il doit y avoir une implémentation SNMP que le
stack p-net peut utiliser.

50
Chapitre3

Par rapport au port ethernet, voici la configuration matérielle requise :

•Au moins 100 Mbit/s full duplex
•Les câbles standards et croisés doivent être supportés.
•Auto-polarité.
•Auto-négociation. [8]
Le matériel doit être capable d’ordonnancer les multitâches en temps réel, (dans notre
cas , une distribution linux) afin d’obtenir des performances optimales.

3.2.1 Choix du microcontrôleur

Après une étude de faisabilité, notre choix s’est porté sur une Raspberry pi 3
model B, de par son accessibilité et ses caractéristiques, c’est la carte idéale pour pro-
totyper une application.
L’intégration d’un système d’exploitation nous facilite le développement et le dé-
ploiement de notre application.

F IGURE 3.2 – Raspberry pi 3 model B

51
Chapitre3

3.2.2 Caractéristiques

La puissance de calcul ainsi que les caractéristiques de notre hardware ont une
importance par rapport à la mise en place d’un système respectant les contraintes de
temps réel.
-Processeur
• Broadcom BCM2387 chipset.
• 1.2GHz Quad-Core ARM Cortex-A53 (64Bit)

-Mémoire
• 1GB LPDDR2
Système d’exploitation
• Boots à partir d’une Micro SD card, distribution linux raspbian avec un noyau temps
réel.

-Alimentation
• Micro USB socket 5V1, 2.5A
-Ethernet
• Pour la partie ethernet, la raspberry utilise la microchip LAN9514, qui contient un
hub USB 2.0 haut débit avec quatre PHY USB 2.0 en aval entièrement intégrés, un PHY
USB 2.0 intégré en amont , un contrôleur MAC/PHY 10/100 Ethernet et un contrôleur
EEPROM, ce qui est suffisant pour notre application.
[9]

3.3 Linux sur embarqué

3.3.1 Introduction

La stabilité et la fiabilité de Linux sur embarqué a été démontrée au fil des années,
plusieurs produits ont été développés en utilisant ce système d’exploitation, ses nom-
breux avantages ont pallié auw contraintes de mémoire. Open source et documenté, il
peut être modifiable à notre guise pour notre application, dans notre cas, nous allons
l’adapter pour qu’il réponde à nos contraintes de temps réel.

52
Chapitre3

3.3.2 Caractéristiques

Voici quelques-unes des caractéristiques importantes de Linux, et des systèmes

d’exploitation de style Unix en général.

[Link] Multitâche

- L’ordonnanceur Linux implémente un véritable multitâche préemptif, dans le

sens où un processus de priorité plus élevée, rendu prêt par l’occurrence d’un événe-
ment asynchrone va préempter le processus en cours d’exécution. Cependant, le noyau
Linux lui-même n’est pas préemptible. Ainsi, un processus ne peut pas être préempté
pendant qu’il exécute un service du noyau.

[Link] Multi-utilisateur

-Il existe un certain nombre de fonctionnalités qui prennent en charge la confi-

dentialité des données. Linux préserve cette caractéristique et la met à profit dans les
environnements de serveurs et des systèmes embarqués.

[Link] Multithreading

- Linux offre un support étendu pour le véritable multitraitement symétrique

(SMP). Un thread ressemble fortement à un processus fils classique à la différence qu’il
partage beaucoup plus de données avec le processus qui l’a créé :
-Les variables globales.
-Les variables statiques locales.
-Les descripteurs de fichiers (file descriptors).
Le multi-threading est donc une technique de programmation permettant de profiter
des avantages (et aussi de certaines contraintes) de l’utilisation des threads.

[Link] Système de fichiers hiérarchique

- Tous les systèmes d’exploitation modernes ont des systèmes de fichiers hiérar-
chiques. Mais le modèle Linux/Unix ajoute des fonctionnalités en plus de ce à quoi
nous sommes habitués avec les systèmes d’exploitation traditionnels.

53
Chapitre3

[Link] Device drivers

- Un pilote est une portion de code exécutée dans l’espace du noyau. Il est chargé
de faire l’interface entre un programme utilisateur et un composant matériel.

[Link] La contrainte de temps

Il y a deux types de contraintes de temps pour les systèmes embarqués : douce

ou dure.
- Une contrainte douce (système temps réel doux) est moins contraignante car en cas
d’erreur raisonnable, le système reste fonctionnel. processus aurait dû s’exécuter.
- Par opposition, la contrainte dure ne permet aucune erreur liée au moment d’exécu-
tion, cela empêchera le bon fonctionnement du système. [10]

[Link] La capacité du réseau

Il définit si un système peut être relié à un réseau. Linux offre la possibilité de

se connecter à un réseau à l’aide des nombreux drivers disponibles tel que "net" qui
contient le code source des différents protocoles réseau supportés par le noyau Linux.
Nous pouvons citer ipv4, ipv6 ou x25 [11] .

3.3.3 Propriétés temps réel de Linux :

Linux n’est pas un système d’exploitation en temps réel. le protocole profinet

a des contraintes de temps assez strictes. Par exemple, un automate Simatic (avec
les paramètres par défaut) enverra une alarme si aucune trame Profinet n’est reçue
pendant 7-8 ms. Il est donc important que Linux soit suffisamment réactif.

Il y a quelques méthodes qui peuvent être utilisées pour améliorer la réactivité

de Linux. Nous citerons toutes les méthodes utilisées afin de pallier à la contrainte de
temps réel.

[Link] Option "SCHED_FIFO"

Le noyau linux offre deux méthodes d’ordonnancement en temps réel, l’ordon-

nancement FIFO (First in First out) SCHED_FIFO et le Round Robin SCHED_RR . La

54
 Chapitre3

méthode que nous avons utilisé est la méthode SCHED_FIFO qui implémente l’algo-
rithme first in first out, quand une tâche SCHED_FIFO s’exécute, elle continue son
exécution jusqu’à ce qu’elle se termine, se fasse bloquer par le processeur, l’appel sys-
tème yield ou sa préemption par une tache en temps réel d’une priorité supérieur.
Contrairement au round robin, il n’y a pas d’intervalle de temps pour chaque tâche
(timeslice).
Pour notre application : Nous avons selectionné l’option d’ordonnancement
FIFO du noyau Linux. Ceci est fait en passant l’argument de ligne de commande
-DUSE_SCHED_FIFO=ON à cmake. [8]

[Link] Application sur un cœur de processeur séparé

Il est possible d’indiquer au noyau Linux de ne pas placer de processus sur un

cœur de processeur spécifique. On doit avoir plus d’un cœur dans notre CPU.
Dans le fichier :

1 sudo nano /boot/cmdline . t x t

On ajoute :
1 i s o l c p u s =2

Puis on reboot le système

En définissant la commande de démarrage Linux isolcpus=2, le noyau ne placera
pas de processus automatiquement sur le noyau numéro 2 du processeur. Cette option
est généralement définie à partir du bootloader. La meilleure façon de vérifier quels
sont les cœurs de CPU qui sont actuellement isolés :
1 c a t /sys/ d e v i c e s /system/cpu/ i s o l a t e d

•On place l’application Profinet sur le noyau CPU isolé. Cela se fait en utilisant :

1 sudo t a s k s e t −c 2 . / pn_dev

où -c 2 indique le noyau CPU à utiliser.

[Link] Patches en temps réel

En appliquant le patch en temps réel (PREEMPT_RT), les propriétés en temps

réel peuvent être améliorées. Pour que les patchs en temps réel aient un effet sur p-net,

55
 Chapitre3

l’option de cmake USE_SCHED_FIFO doit être active.

Afin d’accomplir cela, nous avons compilé le noyau linux avec l’extension PREEMPT-
RT. Ensuite, nous avons installé l’image du noyau ainsi que les modules nécessaires.

1 ~$ cd /tmp
2 /tmp$ t a r x z f r t − k e r n e l . t g z
3 /tmp$ cd boot
4 /tmp/boot$ sudo cp −rd * /boot/
5 /tmp/boot$ cd . . / l i b
6 /tmp/ l i b $ sudo cp −dr * / l i b /
7 /tmp/ l i b $ cd . . / o v e r l a y s
8 /tmp/ o v e r l a y s $ sudo cp −d * /boot/ o v e r l a y s
9 /tmp/ o v e r l a y s $ cd . .
10 /tmp$ sudo cp −d bcm * /boot/

On ajoute ceci au fichier /boot/[Link] :

1 k e r n e l =vmlinuz4 . 1 4 . 7 4 − r t 4 4 −v7+

Après le redémarrage du système, on peut confirmer la bonne installation du kernel :

1 uname − r
2 4 . 1 4 . 7 4 − r t 4 4 −v7+

la figure 3.3 représente la latence résultante du linux kernel Standard et Preempt-

RT Kernels (3b) [12] .

F IGURE 3.3 – Comparaison de latence entre un noyau standard et un noyau temps réel

[Link] Augmenter le temps de cycle de l’application

Pour les tests, on peut augmenter le temps de cycle de l’automate afin de réduire
les problèmes de time-out. Le nombre autorisé de trames manquées peut également

56
Chapitre3

être augmenté dans les paramètres du PLC.

[Link] Matériel de l’interface réseau

Si notre interface réseau Ethernet est connectée via USB, il peut y avoir une
latence supplémentaire. Cela peut affecter l’intervalle des trames Profinet transmises,
dans notre cas le matériel qui concerne l’interface réseau ne cause pas de problème.

3.4 Bibliothèque p-net

La bibliothèque Profinet p-net de RT-Labs est utilisée pour l’implémentation d’IO

device Profinet. elle est facile à utiliser et occupe un faible espace de mémoire. Elle est
particulièrement bien adaptée aux systèmes embarqués où les ressources sont limitées
et où l’efficacité est cruciale. La bibliothèque est fournie avec les fichiers sources com-
plets, y compris les couches de portage.

3.4.1 Fonctionnalités

Écrit en C, le stack p-net offre aux utilisateurs toutes les tâches basiques du pro-
tocole PROFINET telles que l’implémentation du temps réel, les alarmes , l’échange
de données cycliques et acycliques, le lancement de l’application avec les protocoles
LLDP et ARP, ainsi que l’envoi de packet TCP/IP.
p-net nous offre beaucoup de possibilités d’un point de vue fonctionnel, parmi eux :
- La mise en oeuvre d’un device de CC (Conformance Class) A ou B
- L’envoi des trames de RTC 1 (Real Time Class 1)
- La disponibilité sur Linux, RTOS ou bare metal.
- L’utilisation de plusieurs ports ethernet (sur linux)
- L’activation du protocole SNMP
- Un nombre configurable de modules et submodules virtuels
- La disponibilité des données I&M (I&M0 - I&M4).

57
Chapitre3

3.4.2 Limitations

Malgré toutes les fonctionnalités listées précedemment, le stack p-net est dédié
aux IO devices, il ne peut donc pas être utilisé pour les IO controllers.
Son utilisation nécessite la connaissance des différentes limites du stack qui sont :
- L’absence de redondance de média (ne supporte pas le protocol MRP ).
- Le stack ne supporte pas la RT_CLASS_UDP, la DHCP, l’utilisation de plusieurs IO
controller en même temps.
- L’option fast startup qui nous permet le lancement rapide de l’application n’est pas
disponible.
- L’option IRT (Isochronous real time) n’est pas implémentée donc il n’y a pas de
synchronisation du temps.
- Les alarmes n’utilisent pas de paquets UDP (Il n’y a que le mécanisme de base
implémenté c’est à dire l’envoi d’alarme en temps réel).

3.4.3 Dépendances

• cmake 3.14
CMake fournit un ensemble d’outils permettant de compiler un projet pour différentes
plateformes, de faire des tests et de créer des packages pour différents systèmes.

Le principe d’une compilation à l’aide de CMake est d’écrire des fichiers CMa-
[Link] dans tous les répertoires qui contiennent du code ou documentation à
compiler/installer. La coutume est alors de créer un sous-répertoire build, dans lequel
on va compiler notre package puis d’y appeler cmake. On dit alors qu’on construit
le projet "out-of-source", tout les fichiers temporaires seront dans le sous-répertoire
ROOT/build qu’on pourra supprimer si besoin sans affecter notre projet. cmake va
alors créer des fichiers de compilation dépendants de l’architecture/OS.
- On compile généralement en dehors du répertoire source et on le laisse donc intact.
- On utilise une seule syntaxe relativement simple.
- L’outil est cross-plateform, il tourne aussi bien sous Linux que sous MacOS et
Windows.

Pour utiliser CMake, on doit :

58
Chapitre3

- Définir des fichiers [Link] à placer dans le répertoire source.

- Faire appel à cmake pour qu’il génère les makefiles.
- Faire appel à make pour compiler le projet.
[13]

F IGURE 3.4 – CMake logo

• gcc 4.6
GNU Compiler Collection, abrégé en GCC, est un ensemble de compilateurs créés par
le projet GNU. GCC est un logiciel libre capable de compiler divers langages de pro-
grammation, dont C, C++, Objective-C, Java, Ada, Fortran et Go.

F IGURE 3.5 – GCC GNU

• net-snmp
Pour la CC B (conformance class B) le protocole SNMP est nécessaire. Linux utilise
net-snmp (BSD License)

59
 Chapitre3

3.5 Implémentation p-net

Nous allons implémenter le stack profinet ainsi que notre application sur linux
embarqué, et pour cela, nous allons suivre les procédures citées ci-dessous

3.5.1 Compilation

En premier lieu, nous devons installer les dépendances nécessaire à l’importation

et la compilation de notre projet.
• Afin de compiler le stack nous devons installer la dernière version de cmake :

1 sudo apt update

2 sudo apt i n s t a l l snapd
3 sudo r e b o o t
4 sudo snap i n s t a l l cmake −− c l a s s i c

• On vérifie si c’est bien la dernière version qui est installée :

1 cmake −− v e r s i o n

Il est important que la version soit supérieure à 3.14

Pour pouvoir importer la librairie et faire la gestion de version pour le travail en colla-
boration avec l’entreprise, nous devons installer git :
1 sudo apt i n s t a l l g i t

Afin d’importer la librairie à partir de git, nous devons la télecharger ou l’importer

directement de git :
1 g i t c l o n e −− r e c u r s e −submodules h t t p s :// github . com/ r t l a b s −com/p− n e t . g i t

Puis on crée et configure le build à l’aide des options cmake :

1 cmake −B b u i l d −S p− n e t −DUSE_SCHED_FIFO=ON

Après la création du fichier "build", on lance le build du code à l’aide de cette com-
mande :
1 cmake −− b u i l d b u i l d −− t a r g e t i n s t a l l

On accède au fichier build :

1 cd b u i l d

On ne doit pas oublier l’activation de l’interface ethernet et son initialisation :

60
 Chapitre3

1 sudo i f c o n f i g e t h 0 1 9 2 . 1 6 8 . 0 . 5 0 netmask 2 5 5 . 2 5 5 . 2 5 5 . 0 up

On lance l’application comme suit :

1 sudo t a s k s e t −c 2 . / pn_dev −v

3.5.2 Configuration

Le fichier [Link] contient un ensemble de directives et d’instructions dé-

crivant les fichiers sources et les cibles du projet (exécutable, bibliothèque, ou les deux).
Pour configurer les différentes options de l’application
1 s e t (PNET\_MAX\_AR 2
2 CACHE STRING "Number o f c o n n e c t i o n s . Must be > 0 . ’ Automated RT T e s t e r ’
uses 2 " )
3

Le code sera automatiquement complété dans option.h comme suit :

1 # i f ! d e f i n e d (PNET\_MAX\_AR) \newline
2 / * * Number o f c o n n e c t i o n s . Must be > 0 . " Automated RT T e s t e r " uses 2 * /
3 # d e f i n e PNET\_MAX\_AR @PNET\_MAX\_AR@
4 # endif

3.6 Application spécifique

3.6.1 Introduction

L’application consistera en l’implémentation d’un IO device qui capte les valeurs

du capteur associé (un capteur de température dans notre cas), et envoie sur le canal
cyclique les valeurs de la température lues.
Sur le canal acyclique, il y’aura envoi d’un paramètre considéré par l’application
comme un seuil, qui en cas de dépassement, enverra une alarme au PLC.
Nous allons en premier lieu écrire le GSD file associé à notre IO device puis expliquer
les différentes parties du code, ce qui nous permettra de modifier les parties nécessaires
pour notre application en utilisant les fonctions de l’API PROFINET.

61
 Chapitre3

3.6.2 GSD file pour l’IO device

Le GSD file décrit l’IO device et permet à l’ingénieur qui met en place le SCNN
de connaitre les données envoyées ainsi que les paramètres à partir de l’IO supervisor,
Il n’aura qu’à ajouter le GSD file à son environnement de développement.
Afin d’adapter le GSD file de l’IO device à notre application, nous devons ajouter
ceci :
1 <DataItem DataType =" F l o a t 3 2 " T e x t I d =" p_value " UseAsBits =" f a l s e " />

2 <Ref DataType =" F l o a t 3 2 " B y t e O f f s e t = " 0 " D e f a u l t V a l u e = " 1 " AllowedValues

= " 0 . . 9 9 " Changeable =" t r u e "
3 <Ref DataType =" F l o a t 3 2 " B y t e O f f s e t = " 0 " D e f a u l t V a l u e = " 2 " AllowedValues
= " 0 . . 9 9 9 " Changeable =" t r u e "

La partie IOData décrit les données envoyées dans le canal cyclique en temps réel, le
format "Float32" correspond à la norme IEEE 754 sur l’arithmétique à virgule flottante.
Elle est la norme la plus employée actuellement pour le calcul des nombres à virgule
flottante avec les CPU et les FPU.

F IGURE 3.6 – Norme IEEE 754

Les paramètres sont représentés dans la <RecordDataList>, Nous avons 2 paramètres,

l’un représentant le temps entre la lecture du capteur, et l’autre le seuil à ne pas dépas-
ser avant l’envoi d’une alarme, ils sont de type Float32.

62
 Chapitre3

3.6.3 Structure du code

[Link] Organisation des fichiers

Le code se présente sous cette forme :

/p-net
[Link]
include
sample_app
src
common
device
ports
Comprendre la structure du code nous permettra de l’adapter dans le futur et de
comprendre ce que nous devons changer pour l’implémentation de notre application.
Le code est divisé en 3 parties :
-Port :
Cette partie s’occupe de l’interfaçage entre le hardware et la partie application,
elle contient une base pour le networking, c’est à dire la création de socket, l’envoi
de trame sur la couche liaison de données et de paquets UDP. Elle s’occupe aussi de
tout ce qui est manipulation de fichier (sauvegarde, chargement, comparaison ...) ,
ainsi que la base du système d’exploitation. Les fichiers et les fonctions de cette partie
auront un préfixe pnal_ et feront partie de la couche d’abstraction la plus basse.

Exemple d’envoi de trame ethernet sur la deuxième couche :

1 handle −> s o c k e t = s o c k e t ( PF_PACKET , SOCK_RAW, htons ( l i n u x _ r e c e i v e _ t y p e ) ) ;
2 bind ( handle −> s o c k e t , ( s t r u c t sockaddr * )&s l l , s i z e o f ( s l l ) ) ;
3 i n t r e t = send ( handle −> s o c k e t , buf −>payload , buf −>len , 0

[14]
-Device :
Cette partie implémente les fondements de la bibliothèque, les fichiers et fonc-
tions de cette partie ont le préfixe pf_ , elle est implémentée sous forme de machine
d’état où est intégré le CM (context management) , ainsi que des fonctions qui per-
mettent d’ajouter à un buffer les headers et données nécessaires , qui seront utilisées
plus tard dans la constitution de la trame cyclique et de l’alarme, en plus des paquets
acycliques.
-API :
Cette partie utilise les fonctions du device pour réaliser les fonctionnalités finales

63
Chapitre3

de notre application, elle nous propose des fonctions qu’on utilisera pour réaliser les
tâches nécessaires au bon fonctionnement de notre IO device.

F IGURE 3.7 – Couche du programme

[Link] Machine d’état

Il existe plusieurs façons de programmer une application, on peut directement

utiliser nos fonctions dans une boucle et tout s’exécutera séquentiellement, c’est ce
qu’on appelle une superloop, les inconvénients de cette manière de programmmer
sont évidents : le manque de contrôle sur les timings et l’absence d’ordonnancement.
On a donc inventé les machines d’états, qui nous permettent de gérer les conditions de
transition vers un autre état et ainsi avoir plus de maitrise sur les échéances de notre
système, il y’a aussi l’utilisation d’un OS (système d’exploitation) qui nous donne l’op-
tion de préemption et d’ordonnancement, ce qui nous permet le multithreading, c’est
à dire l’execution de plusieurs threads simultanément. Dans un système complexe,
toutes les architectures possibles peuvent coexister tant que le bon fonctionnement de
l’application est assuré.

Dans le cadre de notre application, la librairie utilise plusieurs machines d’états

qui s’occupent du lancement de l’application, de la mise en place des différentes
configurations et du context management, et de la communication cyclique, acyclique

64
Chapitre3

et des alarmes.L’application est donc lancée sous forme de thread avec un timer ce qui
nous permet de profiter des avantages d’un système d’exploitation.

Les machines d’états sont présentées comme suit :

•Alarmes :
- ALPMI Alarm Protocol Machine Initiator. initialise l’alarme pour être envoyée au IO
controller
- ALPMR Alarm Protocol Machine Responder. Réponse de l’IO controller à l’alarme
(from IO-controller)
- APMR Acyclic Protocol Machine Receiver. Reçoit les trames Ethernet d’alarme de
haute et de basse priorité en provenance de l’IO device
- APMS Acyclic Protocol Machine Sender. Envoie des trames Ethernet d’alarme au IO
controller

F IGURE 3.8 – Machine d’état alarme

•CMDEV Context Management protocol machine Device, gère l’établissement

de la connexion pour les IO devices :
Il existe 11 états dans ce CM :
- POWER_ON, Initialisation des données.
- W_CIND, Attend l’indication de connexion (in the connect UDP message)
- W_CRES, Attend la réponse de connexion de l’application et le démarrage du CMSU.
- W_SUCNF, Attend la confirmation CMSU .
- W_PEIND, Attend l’indication PrmEnd (dans le message UDP DControl).

65
Chapitre3

- W_PERES, Attend la réponse PrmEnd de l’application.

- W_ARDY, Attend que l’application soit prête à partir de l’application.
- W_ARDYCNF, Attend la confirmation du contrôleur que l’application est prête.
- WDATA, Attend qu’un échange de données cycliques soit établi.
- DATA, Échange de données et monitoring des connexions.
- ABORT, Interrompt la relation d’application.
•CMDMC Multicast s’occupe de la communication entre IO devices à l’aide de mes-
sages DCP.
•CMINA Context Management Ip and Name Assignment protocol machine :
Cette machine d’état est responsable de l’attribution du nom de la station et de
l’adresse IP. Elle effectue une réinitialisation d’usine lorsque le IO controller le de-
mande.
Il existe 4 états dans ce CM :
- SETUP
- SET_NAME
- SET_IP
- W_CONNECT
Elle aide au traitement des demandes DCP Set et DCP Get.
•CMIO Context Management Input Output protocol machine.
•CMPBE Context Management Parameter Begin End protocol machine.
•CMRDR Context Management Read Record Responder protocol machine, répond
aux paramètres lus par l’IO controller.
•CMRPC Context Management RPC Protocol Machine, gère la communication RPC
via [Link] s’occupe des services suivants :
- Connect
- Release
- DControl (“Parameter end” est envoyé au IO-Device)
- CControl (“Application ready” est envoyé au IO-Controller)
- Paramètre read (Utilise CMRDR)
- Paramètre write
•CMSM Context Management Surveillance protocol Machine, surveille l’établisse-
ment d’une connexion.
Le composant CMSM surveille l’établissement d’une connexion. Une fois que le dispo-
sitif entre dans l’état DATA, la mission de ce composant est terminée.

66
Chapitre3

Il s’agit essentiellement d’une minuterie, qui a deux états : IDLE et RUN. Si elle n’est
pas arrêtée avant son expiration, le stack entre dans l’état PNET_EVENT_ABORT. Le
minuteur revient à l’état IDLE au bout du compte. En général, le délai d’attente est
d’environ 20 secondes (il peut être ajusté par le IO controller).
Le minuteur est démarré à PNET_EVENT_STARTUP (au message de demande de
connexion), et arrêté à PNET_EVENT_DATA.
Il surveille également les messages de réponse et d’indication :
-Read
-Write
-DControl
Il démarre le timer à l’envoi du message "response" et l’arrête à la réception du mes-
sage "indication".
•CMSU Context Management Start Up machine. Démarre d’autres machines d’état,
par exemple PPM et CPM.
•CMWRR Context Management Write Record Responder protocol machine
•CPM Consumer Protocol Machine, pour la réception des données cycliques :
Reçoit les données cycliques. Vérifie que les données entrantes respectent le proto-
cole et que la synchronisation des trames entrantes est correcte. Stocke les données
entrantes dans un buffer.
Plusieurs instances de CPM peuvent être utilisées en parallèle.
Il existe 3 états dans ce CM :
-W_START Attente d’initialisation
-FRUN
-RUN
S’il y a un délai d’attente dans l’état RUN, il repasse à l’état W_START.
•FSPM Fieldbus Application Layer Service Protocol Machine. Interaction avec l’appli-
cation de l’utilisateur ; implémente des callbacks.
•PPM Provider Protocol Machine, pour l’envoi de donnée cyclique.
Il existe 2 états dans ce CM :
-W_START
-RUN
[8]

67
 Chapitre3

3.6.4 API PROFINET

Voici un bref aperçu de certaines des fonctions les plus importantes de l’API du
stack Profinet de p-net :
Cette fonction s’occupe de l’initialisation :
1 p n e t _ t * p n e t _ i n i t ( c o n s t p n e t _ c f g _ t * p_cfg )

Cette fonction sert à initialiser les ARs

1 i n t p n e t _ a p p l i c a t i o n _ r e a d y ( p n e t _ t * net , u i n t 3 2 _ t arep )

L’application signale qu’elle est prête à échanger des données avec l’envoi d’une de-
mande de CControl au IO controller.
Cette fonction initialise la communication cyclique :
1 void p n e t _ h a n d l e _ p e r i o d i c ( p n e t _ t * n e t )

Cette fonction permet à l’application de demander l’interruption de la connexion.

1 i n t p n e t _ a r _ a b o r t ( p n e t _ t * net , u i n t 3 2 _ t arep )

Cette fonction permet l’envoi des données cycliques et les IOPS au IO controller :
1 i n t p n e t _ i n p u t _ s e t _ d a t a _ a n d _ i o p s ( p n e t _ t * net , u i n t 3 2 _ t api , u i n t 1 6 _ t s l o t ,
u i n t 1 6 _ t s u b s l o t , c o n s t u i n t 8 _ t * p_data , u i n t 1 6 _ t d a t a _ l e n , u i n t 8 _ t
iops )

Cette fonction est utilisée pour récupérer l’état du consommateur IOCS d’un sub-slot.
1 i n t p n e t _ i n p u t _ g e t _ i o c s ( p n e t _ t * net , u i n t 3 2 _ t api , u i n t 1 6 _ t s l o t , u i n t 1 6 _ t
subslot , uint8_t * p_iocs )

Cette fonction sert à lire les données cycliques envoyées par l’IO controller vers l’IO
device ainsi que l’état du fournisseur IOPS.
1 i n t p n e t _ o u t p u t _ g e t _ d a t a _ a n d _ i o p s ( p n e t _ t * net , u i n t 3 2 _ t api , u i n t 1 6 _ t s l o t
, u i n t 1 6 _ t s u b s l o t , bool * p_new_flag , u i n t 8 _ t * p_data , u i n t 1 6 _ t *
p_data_len , u i n t 8 _ t * p_iops )

Cette fonction définit l’état de l’IO device quand il est consommateur :

1 i n t p n e t _ o u t p u t _ s e t _ i o c s ( p n e t _ t * net , u i n t 3 2 _ t api , u i n t 1 6 _ t s l o t ,
uint16_t subslot , uint8_t iocs )

Alarmes :
Cette fonction permet d’émettre une alarme à partir de l’IO device vers l’IO controller
1 i n t pnet_alarm_send_process_alarm ( p n e t _ t * net , u i n t 3 2 _ t arep , u i n t 3 2 _ t api
, u i n t 1 6 _ t s l o t , u i n t 1 6 _ t s u b s l o t , u i n t 1 6 _ t payload_usi , u i n t 1 6 _ t
payload_len , c o n s t u i n t 8 _ t * p_payload )

68
 Chapitre3

Cette fonction envoie un ACK (acknowledge) au contrôleur. Elle doit être appelée par
l’application après avoir reçu une alarme dans le rappel pnet_alarm_ind().
1 i n t pnet_alarm_send_process_alarm ( p n e t _ t * net , u i n t 3 2 _ t arep , u i n t 3 2 _ t api
, u i n t 1 6 _ t s l o t , u i n t 1 6 _ t s u b s l o t , u i n t 1 6 _ t payload_usi , u i n t 1 6 _ t
payload_len , c o n s t u i n t 8 _ t * p_payload )

3.6.5 Implémentation de la communication cyclique

[Link] Lecture capteur

Afin de lire les données du capteur, nous allons écrire dans un fichier qui sera
lu par l’application avant chaque envoi cyclique [15] . Voici la fonction qui nous per-
mettra de lire les valeurs du fichier à partir de l’application, elle est implémentée dans
sample_app.c :
1 u i n t 8 _ t * r e a d _ v a l u e _ s e n s o r ( c o n s t char * f i l e _ n a m e ) {
2

3 FILE * fp = fopen ( file_name , " r " ) ;

4

5 i f ( fp == NULL)
6 {
7 f p r i n t f ( s t d e r r , " Couldn ’ t open f i l e f o r reading\n " ) ;
8 exit (1) ;
9 }
10 u i n t 8 _ t * a r r a y = ( u i n t 8 _ t * ) malloc ( 4 * s i z e o f ( u i n t 8 _ t ) ) ;
11 int i ;
12 f o r ( i = 0 ; i < 4 ; i ++) {
13 f s c a n f ( fp , "%x " , &a r r a y [ i ] ) ;
14 }
15 f c l o s e ( fp ) ;
16 return array ;
17 }

•Capteur utilisé :
Le capteur DHT11 est capable de mesurer des températures de 0 à +50°C avec une
précision de +/- 2°C et des taux d’humidité relative de 20 à 80% avec une précision de
+/- 5%. Le capteur a la particularité de communiquer avec le microcontrôleur via une
unique broche d’entrée / sortie qui sera le pin 23.
Nous utiliserons ce code pour récupérer les données de la température et les écrire sur

69
 Chapitre3

le fichier qui sera lu par le code cité ci-dessus.

Nous avons relié la broche VCC du capteur à la broche 3,3V, la broche OUTPUT du
capteur à la broche 23, le GND du capteur à une broche GPIO GND

F IGURE 3.9 – DHT11

Nous avons utilisé la librairie Adafruit_DHT afin de lire à partir du capteur,

puis transformer la valeur float lue en format IEE754 à l’aide des fonctions décrites
ci-dessous. On écrit à chaque itération les nouvelles valeurs sur le fichier qui sera lu
par l’application.
Nous avons donc importé les librairies nécessaires
1 import Adafruit_DHT
2 import time

Cette fonction nous permettra de transformer n’importe quelle type en format

IEEE754.
1 def IEEE754 ( n ) :

On récupère la température et l’humidité en utilisant la fonction disponible dans

la libraire.

1 humidity , temperature = Adafruit_DHT . r e a d _ r e t r y ( sensor , DHT11_pin )

Puis nous écrivons la température à chaque itération

1 m y f i l e . w r i t e ( s t r ( IEEE754 ( temperature ) [ x ] ) + ’ \n ’ )

L’éxecution du code python doit se faire de façon à minimiser les efforts du CPU :
1 sudo n i c e −n 19 python main . py

"nice" est une commande disponible sur le système d’exploitation Linux. Cette com-
mande pointe directement vers un point d’entrée du kernel portant le même nom, elle
permet de changer le niveau de priorité d’un processus déterminé. La priorité la plus
élevée correspond à un niveau de -20, tandis que la plus basse correspond à +19.

70
 Chapitre3

Dans notre cas nous donnons la priorité la plus basse pour permettre à notre applica-
tion de respecter les contraintes de temps réel.
Les données dans le fichier seront sous cette forme :

F IGURE 3.10 – Valeur du capteur sous format IEEE754 dans le fichier

La communication cyclique se fait comme suit :

Voici le prototype de la fonction qui nous permettra de gérer la communication cy-
clique :
1 s t a t i c void a p p _ h a n d l e _ c y c l i c _ d a t a (
2 p n e t _ t * net ,
3 c o n s t app_data_t * p_appdata ,
4 uint8_t data_ctr ,
5 u i n t 8 _ t * p_inputdata ,
6 uint16_t inputdata_size )

Nous devons en premier lieu récupérer la valeur du capteur et l’assigner au paramètre

p_inputdata à l’aide de la fonction décrite plus haut, elle nous permettra de récupérer
les données sous forme de vecteur et il nous sera plus facile de le transformer en float
plus tard.

1 p_inputdata = r e a d _ v a l u e _ s e n s o r ( " s e n s o r . t x t " ) ;

2

Cette fonction a déjà été cité dans l’API, elle nous permet d’envoyer les datas de l’IO
device à l’IO controller ainsi que le IOPS (Provider status)

1 ( void ) p n e t _ i n p u t _ s e t _ d a t a _ a n d _ i o p s (
2 net ,
3 APP_API ,
4 slot ,
5 p _ s u b s l o t −> s u b s l o t _ n b r ,
6 p_inputdata ,
7 inputdata_size ,

71
 Chapitre3

8 iops ) ;
9

1 ( void ) p n e t _ i n p u t _ g e t _ i o c s (
2 net ,
3 APP_API ,
4 slot ,
5 p _ s u b s l o t −> s u b s l o t _ n b r ,
6 &i n p u t d a t a _ i o c s ) ;
7

1 pnet_output_get_data_and_iops (
2 net ,
3 APP_API ,
4 slot ,
5 p _ s u b s l o t −> s u b s l o t _ n b r ,
6 &outputdata_is_updated ,
7 outputdata ,
8 &o u t p u t d a t a _ l e n g t h ,
9 &o u t p u t d a t a _ i o p s ) ;

Toutes les nomitations output/input seront désignées par rapport à l’IO control-
ler, c’est pour cela que les données envoyées de l’IO device à l’IO controller sont appe-
lées input.

3.6.6 Implémentation de la communication acyclique

L’implémentation se fait grâce à une fonction de rappel (callbacks) qui est une
fonction passée dans une autre fonction en tant qu’argument,et qui est ensuite invo-
quée à l’intérieur de la fonction externe pour accomplir une sorte de routine ou d’ac-
tion.
1 s t a t i c i n t app_write_ind
2

1 s t a t i c i n t app_read_ind

Comme nous pouvons le constater, ces fonctions sont rappelées autre part dans
le code sous forme de callbacks.
1 int app_pnet_cfg_init_default ( pnet_cfg_t * stack_config )
2 {
3 ...

72
 Chapitre3

4 s t a c k _ c o n f i g −>read_cb = app_read_ind ;
5 s t a c k _ c o n f i g −> w r i t e _ c b = app_write_ind ;
6 ...
7 }

3.6.7 Implémentation des alarmes

Voici le prototype de la fonction qui s’occupera des alarmes.

1 s t a t i c void app_handle_send_alarm (
2 p n e t _ t * net ,
3 u i n t 3 2 _ t arep ,
4 bool * p_alarm_allowed ,
5 c o n s t app_data_t * p_appdata ,
6 u i n t 8 _ t * alarm_payload )

Elle utilise cette fonction qui a été décrite dans la partie API :
1 pnet_alarm_send_process_alarm (
2 net ,
3 arep ,
4 APP_API ,
5 slot ,
6 p _ s u b s l o t −> s u b s l o t _ n b r ,
7 APP_ALARM_USI,
8 APP_ALARM_PAYLOAD_SIZE,
9 alarm_payload ) ;

3.6.8 Application prototype

Notre application a la spécificité de transmettre les données lues d’un capteur en

temps réel sur le canal cyclique, paramétrer le temps entre chaque lecture du capteur
et un seuil sur le canal acyclique, qui en cas de dépassement, engendrera une alarme
qui sera lancée en temps réel sur le canal adéquat.
Pour pouvoir mettre en place la condition pour le lancement de l’alarme avec le seuil
reçu sous forme de paramètre acyclique :
Nous avons dû effectuer des opérations de manipulation de données pour convertir
entre les différents types de données.
Pour convertir les données lues du fichier en float lisible par notre système, nous
avons utilisé une union qui, à l’image d’une structure, est un regroupement d’objets de

73
 Chapitre3

type différents, occupant le même espace de mémoire.

1 union u {
2 uint8_t x [ 4 ] ;
3 f l o a t val ;
4 };
5

Après avoir fait l’instanciation de notre union, on lit notre fichier puis on inverse
l’ordre des octets, on passe d’une disposition BE (Big endian) à une disposition LE
(Little endian).
1 union u u n t e s t ;
2

3 uint8_t * buffer = read_value_sensor ( " sensor . t x t " ) ;

4 untest . x [3 ] = buffer [ 0 ] ;
5 untest . x [2 ] = buffer [ 1 ] ;
6 untest . x [1 ] = buffer [ 2 ] ;
7 untest . x [0 ] = buffer [ 3 ] ;
8

On effectue aussi la conversion de Big endian à Little endian avec le paramètre

acyclique qui représente le seuil mais cette fois-ci à l’aide d’une fonction qui nous per-
met de réarranger l’ordre de nos données sachant que le paramètre est de type float.
1 t h r e s h o l d = R e v e r s e F l o a t ( p_appdata −>app_param_1 ) ;

Voici la fonction utilisée pour inverser une donnée float de type IEEE754 d’une
disposition Big endian à une disposition Litte endian ou vice versa.
1

2 f l o a t ReverseFloat ( const f l o a t inFloat )

3 {
4 f l o a t retVal ;
5 char * f l o a t T o C o n v e r t = ( char * ) & i n F l o a t ;
6 char * r e t u r n F l o a t = ( char * ) & r e t V a l ;
7 returnFloat [ 0 ] = floatToConvert [ 3 ] ;
8 returnFloat [ 1 ] = floatToConvert [ 2 ] ;
9 returnFloat [ 2 ] = floatToConvert [ 1 ] ;
10 returnFloat [ 3 ] = floatToConvert [ 0 ] ;
11 return retVal ;
12 }

Puis on utilise le paramètre reçu comme condition pour lancer l’alarme en cas de dé-
passement du seuil, on utilise aussi une variable pour contrôler la machine d’état et

74
 Chapitre3

limiter le lancement de l’alarme à 4 fois, assez pour exécuter les 4 états cités plus tôt
d’une alarme.
1 i f ( u n t e s t . val > t h r e s h o l d && k== f a l s e )
2 {
3 f o r ( i n t i = 0 ; i < 4 ; i ++) {
4 app_handle_send_alarm (
5 net ,
6 p_appdata −>main_api . arep ,
7 &p_appdata −>alarm_allowed ,
8 p_appdata ,
9 alarm_payload ) ;
10 }
11 k= t r u e ;
12 }
13

Nous avons utilisé toutes ces fonctions dans une boucle qui les exécutera selon le flag
indiquant l’état actuel, qui varie selon les événements manipulés par l’OS à l’aide des
fonctions dédiées à cela.
Exemple :
Pour sortir de l’état de l’alarme :

1 o s _ e v e n t _ c l r ( p_appdata −>main_events , APP_EVENT_ALARM)

2

3.6.9 Conclusion

Dans ce chapitre, nous avons fait l’implémentation de notre IO device en effec-

tuant une analyse par rapport au hardware et système d’exploitation à choisir tout en
prenant en compte les besoins de l’application.
Nous avons ensuite fait en sorte que notre système respecte les contraintes en
temps réel de notre application en utilisant plusieurs méthodes afin d’accomplir ceci.
Après une étude approfondie de la bibliothèque p-net et de son implémentation,
nous avons programmé une application en utilisant son API pour concevoir un IO
device fonctionnel qui sera testé dans le prochain chapitre.

75
Chapitre 4

Test et résultats
Chapitre4

4.1 Introduction

Pour tester l’IO device, nous avons simulé un PLC à l’aide d’une autre raspberry
pi, nous avons utilisé codesys pour pouvoir faire cela, après avoir reproduit ce qu’au-
rait fait un automaticien, c’est à dire, ajouter le GSD file du device dans codesys (ou le
logiciel consacré au PLC) puis ajouter notre device dans notre topologie et régler tout
les paramètres nécessaires (IP ...) puis connecter l’IO device et l’IO controller dans le
même réseau,nous allons ensuite recueillir les trames et packets à l’aide de wireshark
et contrôler l’efficacité de nos méthodes pour le respect des contraintes en temps réel
sur notre système.

F IGURE 4.1 – Prototype du setup

4.2 Outils utilisés

4.2.1 Codesys

CODESYS est un environnement de développement pour des automates pro-

grammables industriels (API) selon le standard CEI 61131-3 pour le développement
d’applications dans l’automation industrielle.
Il nous permettra de simuler le comportement d’un PLC sur une raspberry pi, afin
de lire les données transmises en temps réel sur le canal cyclique, lire et modifier les
paramètres acycliques, et nous informer dans le cas du déclenchement d’une alarme.

77
Chapitre4

Après l’installation du logiciel et le téléchargement de tout les plugins nécessaires

au déploiement sur raspberry pi, nous allons ensuite insérer les paramètres spécifiques
à notre système, c’est à dire, le username et mot de passe du root, l’adresse IP, puis
installer le package et lancer le runtime.

F IGURE 4.2 – Configuration de la raspberry qui simule le PLC

Ensuite, nous avons ajouté le GSD file de notre IO device au projet, pour cela
nous nous sommes rendus sur l’onglet outils puis Référentiel d’appareils, "installer",
et on choisit le GSDML file confectionné par nos soin.
La prochaine étape sera d’ajouter notre IO device dans l’onglet appareil, dans
Device (CODESYS Control for Raspberry pi SL) , on appuie sur Ajouter un appareil,
Adapteur ethernet, Ethernet.
Après un clic droit sur ethernet, on choisit l’option Ajouter un appareil, Profinet IO
master, puis PN-Controller.
On reproduit la même chose sur PN-Controller, on ajoute "P-Net Sample App", puis
DIO 8xLogicLevel.

78
Chapitre4

F IGURE 4.3 – Interface du logiciel après ajout des composants

Sur l’onglet Ethernet, on ajuste l’adresse IP, le masque de sous-réseau et la passe-

relle par défaut de notre interface réseau "eth0" qui définit les paramètres de notre IO
device.

F IGURE 4.4 – Paramètrage de l’interface ethernet de la raspberry simulé en PLC

79
Chapitre4

Sur l’onglet PN-controller, on ajuste la plage d’adresses IP de sorte à couvrir tous

les futurs IO devices.

F IGURE 4.5 – Paramètre de la plage d’adresse des IO devices

Sur l’onglet PN_Net_Sample_App, on paramètre l’adresse IP, le masque de sous-

réseau et la passerelle par défaut de l’IO device.

F IGURE 4.6 – Paramétrage de l’IO device à travers le logiciel

Il ne reste plus qu’à se connecter et appuyer sur Démarrer et le processus sera

lancé.

4.2.2 Wireshark

Wireshark est un logiciel d’analyse réseau (sniffer) qui permet de visualiser l’en-
semble des données transitant sur la machine qui l’exécute, et d’obtenir des informa-
tions sur les protocoles applicatifs utilisés.[16]
Le filtre qui nous permet de ne visualiser que les paquets de type profinet se présente
sous cette forme : pn_io

80
Chapitre4

4.3 Test de l’application

4.3.1 Test du lancement de l’application

1-Le PLC envoie un message de diffusion DCP (broadcast) et tous les IO devices
du sous-réseau répondent en indiquant leur adresse MAC.

F IGURE 4.7 – Première trame DCP broadcast

F IGURE 4.8 – Première trame DCP broadcast en octets

Service : Requête d’identification qui est décrite par un Service ID égal à 5 et un

type de service égal à 0.
Le bloc gris désigne le nom du device recherché et nous permet de trouver notre
IO device qui est identifié par son nom seulement.
Nous remarquons aussi que les trames DCP ne contiennent pas de tag VLAN et ne sont
donc pas concernées par les priorités, elles possédent directement un ethertype 0x8892
correspondant au protocole PROFINET, ce sera le cas pour toutes les trames DCP.

81
Chapitre4

2-l’IO device confirme son nom :

F IGURE 4.9 – Deuxième trame DCP confirmant le nom de l’IO device

F IGURE 4.10 – Deuxième trame DCP en octets

Service : Réponse d’identification qui est décrite par un Service ID égal à 5 et un

type de service égal à 1.
Le bloc gris désigne la configuration actuelle de l’IO device ainsi que toutes les
informations additionnelles de celui-ci .

82
Chapitre4

3-L’Automate envoie un message DCP à l’IO device en utilisant son adresse

MAC, contenant l’adresse IP qu’il doit utiliser.

F IGURE 4.11 – Troisième trame DCP qui montre l’envoi de l’adresse IP

F IGURE 4.12 – Troisième trame DCP en octets

Service : Requête de réglage qui est décrite par un Service ID égal à 4 et un type
de service égal à 0.
Le bloc gris désigne l’IP, le masque de sous-réseau ainsi que la passerelle par
défaut qui sont envoyées par le PLC à l’IO device.

83
Chapitre4

4-l’IO device confirme que l’adresse a été reçue et configurée :

F IGURE 4.13 – Dernière trame DCP confirmant la réception des paramètres par l’IO
device

F IGURE 4.14 – Dernière trame DCP en octets

Service : Réponse de réglage qui est décrite par un Service ID égal à 4 et un type
de service égal à 1.

84
Chapitre4

• LLDP :
Les trames LLDP sont utiles pour détecter à quel voisin, le dispositif est connecté dans
le réseau.
Elles sont envoyées par un dispositif Profinet toutes les 5 secondes, pour indiquer
l’adresse IP, etc.

F IGURE 4.15 – Trame LLDP de l’IO device

4.3.2 Test communication des données cycliques

F IGURE 4.16 – Trame donnée cyclique de l’IO controller à l’IO device

85
Chapitre4

F IGURE 4.17 – Trame donnée cyclique de l’IO controller à l’IO device en hexa

Détails des 40 octets de data envoyés de l’IO controller à l’IO device :

byte 1 : IOPS du slot 0, subslot 1.
byte 2 : IOPS du slot 0, subslot 0x8000.
byte 3 : IOPS du slot 0, subslot 0x8001.
byte 4 : IO data du slot 1, subslot 1.
byte 5 : IOPS du slot 1, subslot 1.
byte 6 : IOCS du slot 1, subslot 1.
(puis 31 bytes de padding à 0)

F IGURE 4.18 – Trame donnée cyclique de l’IO device à l’IO controller

F IGURE 4.19 – Trame donnée cyclique de l’IO device à l’IO controller en hexa

86
Chapitre4

Détails des 40 octets de data envoyés de l’IO device à l’IO controller :

byte 1 :IOPS (Provider Status) du slot 0, subslot 1.
byte 2 :IOPS (Provider Status) du slot 0, subslot 0x8000.
byte 3 :IOPS (Provider Status) du slot 0, subslot 0x8001.
byte 4-8 : IO data du slot 1, subslot 1 (4 bytes data).
byte 9 :IOPS (Provider Status) du slot 1, subslot 1.
byte 10 :IOCS (Consumer Status) du slot 1, subslot 1.
(puis 31 bytes de padding à 0)

Dans les trames cycliques, nous avons le tag ethertype VLAN 0x8100 qui est suivi
par le Tag Control Information qui contient la priorité de la trame (6), le format, et l’ID
qui sont à 0 suivi par l’ethertype 0x8892 représentant PROFINET.

4.3.3 Test communication des données acycliques

F IGURE 4.20 – Write response (écriture)

87
Chapitre4

F IGURE 4.21 – Read response (lecture)

4.3.4 Test des alarmes

F IGURE 4.22 – Trame alarme notification

88
Chapitre4

F IGURE 4.23 – Trame alarme acknowledgement

F IGURE 4.24 – Trame alarme réponse du PLC

F IGURE 4.25 – Trame alarme acknowledgement

89
Chapitre4

4.4 Performance temps réel

Notre application nous impose des contraintes de temps réel qui doivent être
respectées. Pour pouvoir accomplir cela, nous avons utilisé plusieurs méthodes qui
nous ont permis de réduire le temps de réponse de notre application. La variation de
la latence dans le temps est appelée jitter. Un jitter élevé signifie que les délais sont
fortement variables, ce qui perturbe les protocoles en temps réel. Nous avons donc
effectué des tests sur notre système linux pour comparer l’impact de nos méthodes sur
la latence et le jitter de notre application.
Cyclictest est le plus souvent utilisé pour le benchmarking des systèmes RT. C’est
l’un des outils les plus fréquemment utilisés pour évaluer les performances relatives
des systèmes temps réel.
Il mesure de manière précise et répétée la différence entre la transition des états
des threads afin de fournir des informations sur la variation de latences du système. Il
peut mesurer les jitters causées par le matériel, le firmware et le système d’exploitation.

4.4.1 Performance avec un noyau standard

•La figure 4.26 représente la latence des différents coeurs du processeur sur un
échantillon de thread qui nous permet de juger les performances de notre système
avec un noyaux linux standard, et sans l’isolation de l’application sur un coeur du
processeur.

F IGURE 4.26 – Latence avec noyau standard et sans taskset

90
 Chapitre4

1 sudo sh m k l a t e n c y p l o t

Il y’a une forte variation de latences, avec une latence maximale de 451 us, qui peut
causer l’arrêt de notre application.

•La figure 4.27 représente la latence des différents coeurs du processeur sur un
échantillon de thread qui nous permet de juger les performances de notre système
avec un noyaux linux standard, et avec l’isolation de l’application sur le coeur 2 du
processeur à l’aide de la manipulation citée dans le chapitre 3.

1 sudo t a s k s e t −c 2 sh m k l a t e n c y p l o t

F IGURE 4.27 – Latence avec noyau standard et taskset

Nous observons la diminution de la latence comparée à la figure 4.26 avec une

latence maximale de 204us.

91
 Chapitre4

4.4.2 Performance avec noyau temps réel

•La figure 4.28 représente la latence des différents coeurs du processeur sur un
échantillon de thread qui nous permet de juger les performances de notre système avec
un noyau linux temps réel RT_PREEMPT, implémenté à l’aide de la manipulation citée
dans le chapitre 3 et sans l’isolation de l’application sur le coeur 2.

1 sudo sh m k l a t e n c y p l o t

F IGURE 4.28 – Latence avec noyau temps réel et sans taskset

On remarque beaucoup moins de variations par rapport aux tests effectués avec
un noyau standard. La latence maximale est de 111 us.

•La figure 4.29 représente la latence des différents coeurs du processeur sur un
échantillon de thread qui nous permet de juger les performances de notre système
avec un noyau linux temps réel RT_PREEMPT, et avec l’isolation de l’application sur
le coeur 2 du processeur à l’aide des manipulations citée dans le chapitre 3.
1 sudo t a s k s e t −c 2 sh m k l a t e n c y p l o t

92
Chapitre4

F IGURE 4.29 – Latence avec noyau temps réel et taskset

Il s’agit de la combinaison de méthodes qui nous a fourni la variation de latences

la plus basse ainsi qu’une latence maximale de 106us.

4.4.3 Conclusion

Comme nous pouvons l’observer sur les graphes résultants de nos tests, la com-
binaison des méthodes choisies, c’est à dire, l’utilisation d’un noyau temps réel ainsi
que l’isolation de l’application sur un coeur séparé minimise la variation de latences et
nous permet donc de respecter les contraintes de temps réel imposées par le protocole.

93
Conclusion générale

Ce travail contribue à l’intégration du protocole de communication PROFINET

sur système embarqué. Nous avons eu l’occasion de voir l’importance des bus de com-
munication dans un environnement industriel et des systèmes en temps réel.
La compréhension de l’architecture industrielle et de son organisation nous a permis
d’adhérer à l’idée de la transition de l’analogique au numérique et de l’intérêt des bus
de communication basés sur ethernet.
Ensuite, nous avons découvert et assimilé le protocole PROFINET en montrant toutes
ses fonctionnalités et en faisant une analyse approfondie de chaque partie caractéri-
sant ce protocole.
Nous avons, à l’aide de solutions open source, implémenté et conçu une application
spécifique exploitant toutes les fonctionnalités de PROFINET. Nous avons aussi réa-
lisé une maquette fonctionnelle pour les tests.
Notre application exige un respect des contraintes de temps réel strict, nous avons
donc adapté notre système d’exploitation linux afin qu’il réponde aux contraintes de
l’application en utilisant plusieurs méthodes citées dans le chapitre 3.
Enfin nous avons assuré le bon fonctionnement de notre application implémentée en
captant toutes les données transférées et contrôler l’efficacité de nos méthodes pour le
respect des contraintes en temps réel sur notre système.
Il convient de souligner les limites causées par la librairie et le hardware pour
réaliser un IO device de classe supérieure. Néanmoins, notre travail est largement
suffisant pour l’application demandée.
Par rapport aux perspectives de recherches futures, le projet pourrait se porter
sur la conception d’un IO device sur STM32 en utilisant un RTOS ce qui permettra un
meilleur contrôle sur tous les aspects de l’application ainsi qu’un hardware développé
sur mesure pour la réalisation d’un produit fini. On peut aussi partir sur une solution
plus générale, qui consitera en la réalisation d’une image linux adaptée à notre appli-
cation à l’aide de yocto et d’y intégrer différents bus de communication.

94
Bibliographie

[1] C. NIEL Éric, Maîtrise des risques et sûreté de fonctionnement des systèmes de produc-
tion. Éditeur : Hermes Science Publications (25 février 2002).

[2] “What is a distributed control system (dcs),” [consulté le 3 mai 2021].

Disponible sur : <[Link]
[Link]>.

[3] N. Ayllon, “Fieldbus vs 4-20 ma,” [consulté le 15 mai 2021]. Disponible sur :
<[Link]

[4] D. Abdelhamid, “Cours réseaux locaux industriels,” 2010 Disponible sur

<[Link]
rli_10.pdf>.

[5] AGILICOM, [consulté le 2 avril 2021]. Disponible sur : <[Link]

[Link]/[Link]>.

[6] “Profinet théorie et pratique [consulté le 20 avril 2021]. disponible sur :

<[Link]
35519&token=225153add677d46a889856bb7e16f7e580ced7d4>.”

[7] R. Pigan and M. Metter, Automating with PROFINET, Industrial Communication ba-
sed on Industrial Ethernet. Publisher : Publicis (December 3, 2008).

[8] “p-net profinet device stack docs [consulté le 6 avril 2021]. disponible sur :
<[Link]

[9] “Technical specification : Raspberry pi 3 model b,” [consulté le 2 juin 2021]. Dispo-
nible sur : <[Link]
%252Fds%252Fpdf%252FT%[Link]>.

[10] P. V. Hung, “Linux embarqué et système embarqué,” Hanoï, 15 Juillet 2005.

[consulté le 24 Juin 2021]. Disponible sur : <[Link]
[Link]/embedded/tipe-pham_viet_hung.pdf>.

95
Bibliographie

[11] D. Abbott, Linux for Embedded and Real-time Applications, Fourth Edition. Publisher :
Newnes, 2017.

[12] M. Riva, Real Time System - Preempt-RT Patching Tutorial [consulté le 13

Juin 2021]. Disponible sur <[Link]
raspberry-pi-preempt-rt-patching-tutorial-for-kernel-4-14-y>.

[13] J. Fix, “Tutoriel cmake , [consulté le 28 mai 2021]. disponible sur

<[Link]
[Link]#principe>.”

[14] geeksforgeeks, “Socket programming in c/c++,” [consulté le 2 mai

2021]. Disponible sur : <[Link]
socket-programming-cc/>.

[15] “Capteur de température et humidité dht11 avec raspberry pi, [consulté le

2 juin 2021]. disponible sur <[Link]
capteur-de-temperature-et-humidite-dht11-avec-raspberry-pi/>.”

[16] Hilscher, “Capturing profinet with wireshark,” [consulté le 12 mai 2021]. Dispo-
nible sur <[Link] DOC190402AN01EN.

[17] Open Source Automation Development Lab (OSADL), Cyclictest script [consulté
le 2 Juin 2021]. Disponible sur <[Link]
[Link]>.

[18] IEEE-754 : Aide Mémoire [consulté le 25 mai 2021]. Disponible sur <https://
[Link]/lectures/archi-ord/[Link]>.

96
Annexes
 Annexes

.1 Annexe A : Code application en C

• Code de la communication cyclique :

1 s t a t i c void a p p _ h a n d l e _ c y c l i c _ d a t a (
2 p n e t _ t * net ,
3 c o n s t app_data_t * p_appdata ,
4 uint8_t data_ctr ,
5 u i n t 8 _ t * p_inputdata ,
6 uint16_t inputdata_size )
7 {
8 uint16_t slot = 0;
9 uint16_t subslot = 0;
10 u i n t 8 _ t i n p u t d a t a _ i o c s = PNET_IOXS_BAD ; / * Consumer s t a t u s from PLC * /
11 u i n t 8 _ t o u t p u t d a t a _ i o p s = PNET_IOXS_BAD ; / * Producer s t a t u s from PLC * /
12 u i n t 8 _ t outputdata [APP_DATASIZE_OUTPUT ] ;
13 uint16_t outputdata_length = 0 ;
14 u i n t 8 _ t i o p s = PNET_IOXS_BAD ;
15 c o n s t a p p _ s u b s l o t _ t * p _ s u b s l o t = NULL;
16 bool o u t p u t d a t a _ i s _ u p d a t e d = f a l s e ; / * Not used i n t h i s a p p l i c a t i o n * /
17 bool l e d _ s t a t e = f a l s e ; / * LED f o r c y c l i c data * /
18 bool h a s _ s e t _ l e d _ s t a t e = f a l s e ;
19 u i n t 8 _ t output_parameter ;
20 / * Prepare i np ut data ( f o r sending t o IO− c o n t r o l l e r ) * /
21

22 p_inputdata = r e a d _ v a l u e _ s e n s o r ( " s e n s o r . t x t " ) ;

23

24 f o r ( s l o t = 0 ; s l o t < PNET_MAX_SLOTS ; s l o t ++)

25 {
26 f o r ( s u b s l o t = 0 ; s u b s l o t < PNET_MAX_SUBSLOTS ; s u b s l o t ++)
27 {
28 i o p s = PNET_IOXS_BAD ;
29 p _ s u b s l o t = &p_appdata −>main_api . s l o t s [ s l o t ] . s u b s l o t s [ s u b s l o t ] ;
30

31 / * S e t i n p u t d a t a f o r a l l custom i np ut modules , i f any * /

32 i f ( p _ s u b s l o t −>plugged && a p p _ s u b s l o t _ i s _ i n p u t ( p _ s u b s l o t ) )
33 {
34 i f ( p _ s u b s l o t −>p_in_data ! = NULL)
35 {
36 i o p s = PNET_IOXS_GOOD ;
37 }

98
 Annexes

38

39 ( void ) p n e t _ i n p u t _ s e t _ d a t a _ a n d _ i o p s (
40 net ,
41 APP_API ,
42 slot ,
43 p _ s u b s l o t −> s u b s l o t _ n b r ,
44 p_inputdata ,
45 inputdata_size ,
46 iops ) ;
47

48 ( void ) p n e t _ i n p u t _ g e t _ i o c s (
49 net ,
50 APP_API ,
51 slot ,
52 p _ s u b s l o t −> s u b s l o t _ n b r ,
53 &i n p u t d a t a _ i o c s ) ;
54

55 i f ( p_appdata −>arguments . v e r b o s i t y > 1 )

56 {
57 i f ( i n p u t d a t a _ i o c s == PNET_IOXS_BAD )
58 {
59 printf (
60 " The c o n t r o l l e r r e p o r t s IOCS_BAD f o r i np ut s l o t %u\n " ,
61 slot ) ;
62 }
63 e l s e i f ( i n p u t d a t a _ i o c s ! = PNET_IOXS_GOOD)
64 {
65 p r i n t f ( app_handle_cyclic_data ,
66 " The c o n t r o l l e r r e p o r t s IOCS %u f o r i np ut s l o t %u . I s
it "
67 " i n STOP mode?\n " ,
68 inputdata_iocs ,
69 slot ) ;
70 }
71 }
72 }
73

74 / * S e t outputdata f o r custom output modules , i f any * /

75 i f ( p _ s u b s l o t −>plugged && a p p _ s u b s l o t _ i s _ o u t p u t ( p _ s u b s l o t ) )
76 {

99
 Annexes

77 o u t p u t d a t a _ l e n g t h = s i z e o f ( outputdata ) ;
78 pnet_output_get_data_and_iops (
79 net ,
80 APP_API ,
81 slot ,
82 p _ s u b s l o t −> s u b s l o t _ n b r ,
83 &outputdata_is_updated ,
84 outputdata ,
85 &o u t p u t d a t a _ l e n g t h ,
86 &o u t p u t d a t a _ i o p s ) ;
87 }
88 }
89 }
90 }

• Code de la communication acyclique :

1 s t a t i c i n t app_write_ind (
2 p n e t _ t * net ,
3 void * arg ,
4 u i n t 3 2 _ t arep ,
5 u i n t 3 2 _ t api ,
6 uint16_t slot ,
7 uint16_t subslot ,
8 u i n t 1 6 _ t idx ,
9 u i n t 1 6 _ t sequence_number ,
10 uint16_t write_length ,
11 c o n s t u i n t 8 _ t * p_write_data ,
12 pnet_result_t * p_result )
13

1 s t a t i c i n t app_read_ind (
2 p n e t _ t * net ,
3 void * arg ,
4 u i n t 3 2 _ t arep ,
5 u i n t 3 2 _ t api ,
6 uint16_t slot ,
7 uint16_t subslot ,
8 u i n t 1 6 _ t idx ,
9 u i n t 1 6 _ t sequence_number ,
10 u i n t 8 _ t * * pp_read_data ,
11 u i n t 1 6 _ t * p_read_length ,

100
 Annexes

12 pnet_result_t * p_result )

• Code pour l’implémentation des alarmes :

1 s t a t i c void app_handle_send_alarm (
2 p n e t _ t * net ,
3 u i n t 3 2 _ t arep ,
4 bool * p_alarm_allowed ,
5 c o n s t app_data_t * p_appdata ,
6 u i n t 8 _ t * alarm_payload )
7 {
8 s t a t i c app_demo_state_t s t a t e = APP_DEMO_STATE_ALARM_SEND ;
9 uint16_t slot = 0;
10 bool f o u n d _ i n p u t s l o t = f a l s e ;
11 uint16_t subslot_ix = 0;
12 c o n s t a p p _ s u b s l o t _ t * p _ s u b s l o t = NULL;
13 pnet_pnio_status_t pnio_status = { 0 } ;
14 pnet_diag_source_t diag_source = {
15 . a p i = APP_API ,
16 . slot = 0 ,
17 . subslot = 0 ,
18 . ch = APP_DIAG_CHANNEL_NUMBER,
19 . ch_grouping = PNET_DIAG_CH_INDIVIDUAL_CHANNEL,
20 . c h _ d i r e c t i o n = APP_DIAG_CHANNEL_DIRECTION } ;
21

22 / * Loop though s l o t s and s u b s l o t s t o f i n d f i r s t in pu t s u b s l o t * /

23 while ( ! f o u n d _ i n p u t s l o t && ( s l o t < PNET_MAX_SLOTS) )
24 {
25 f o r ( s u b s l o t _ i x = 0 ; ! f o u n d _ i n p u t s l o t && ( s u b s l o t _ i x <
PNET_MAX_SUBSLOTS) ;
26 s u b s l o t _ i x ++)
27 {
28 p _ s u b s l o t = &p_appdata −>main_api . s l o t s [ s l o t ] . s u b s l o t s [ s u b s l o t _ i x ] ;
29 i f ( app_subslot_is_input ( p_subslot ) )
30 {
31 found_inputslot = true ;
32 break ;
33 }
34 }
35 i f ( ! found_inputslot )
36 {
37 s l o t ++;

101
 Annexes

38 }
39 }
40 i f ( ! found_inputslot )
41 {
42 p r i n t f ( " Did not f i n d any in pu t module i n t h e s l o t s . Skipping . \ n " ) ;
43 return ;
44 }
45

46 diag_source . s l o t = s l o t ;
47 d i a g _ s o u r c e . s u b s l o t = p _ s u b s l o t −> s u b s l o t _ n b r ;
48

49 s w i tc h ( s t a t e )
50 {
51 c a s e APP_DEMO_STATE_ALARM_SEND :
52 i f ( * p_alarm_allowed == t r u e && arep ! = UINT32_MAX)
53 {
54 alarm_payload [ 0 ] + + ;
55 printf (
56 " Sending p r o c e s s alarm from s l o t %u s u b s l o t %u USI %u t o "
57 " IO− c o n t r o l l e r . Payload : 0x%x\n " ,
58 slot ,
59 p _ s u b s l o t −> s u b s l o t _ n b r ,
60 APP_ALARM_USI,
61 alarm_payload [ 0 ] ) ;
62 pnet_alarm_send_process_alarm (
63 net ,
64 arep ,
65 APP_API ,
66 slot ,
67 p _ s u b s l o t −> s u b s l o t _ n b r ,
68 APP_ALARM_USI,
69 APP_ALARM_PAYLOAD_SIZE,
70 alarm_payload ) ;
71 * p_alarm_allowed = f a l s e ; / * Not allowed u n t i l ACK r e c e i v e d * /
72 }
73 else
74 {
75 p r i n t f ( " Could not send p r o c e s s alarm , as alarm_allowed == f a l s e or
"
76 " no c o n n e c t i o n a v a i l a b l e \n " ) ;

102
 Annexes

77 }
78 break ;
79

Boucle main :
la boucle se présentera comme telle :
1

2 i f ( f l a g s & APP_EVENT_READY_FOR_DATA)
3 {
4 o s _ e v e n t _ c l r ( p_appdata −>main_events , APP_EVENT_READY_FOR_DATA) ;
5

6 app_handle_send_application_ready (
7 net ,
8 p_appdata −>a r e p _ f o r _ a p p l _ r e a d y ,
9 p_appdata −>arguments . v e r b o s i t y ) ;

2 e l s e i f ( f l a g s & APP_EVENT_ALARM)
3 {
4 o s _ e v e n t _ c l r ( p_appdata −>main_events , APP_EVENT_ALARM) ; / * Re−arm

*/
5

6 app_handle_send_alarm_ack (
7 net ,
8 p_appdata −>main_api . arep ,
9 p_appdata −>arguments . v e r b o s i t y ,
10 &p_appdata −>alarm_arg ) ;
11 }

2 e l s e i f ( f l a g s & APP_EVENT_TIMER)
3 {
4 o s _ e v e n t _ c l r ( p_appdata −>main_events , APP_EVENT_TIMER ) ; / * Re−arm

*/
5 if (
6 ( p_appdata −>main_api . arep ! = UINT32_MAX) &&
7 ( t i c k _ c t r _ u p d a t e _ d a t a > APP_TICKS_UPDATE_DATA) )
8 {
9 tick_ctr_update_data = 0;
10

11 app_handle_cyclic_data (
12 net ,

103
 Annexes

13 p_appdata ,
14 button1_pressed ,
15 d a t a _ c t r ++ ,
16 p_appdata −>inputdata ,
17 s i z e o f ( p_appdata −> i n p u t d a t a ) ) ;
18

19

20 }
21 }

1 e l s e i f ( f l a g s & APP_EVENT_TIMER)
2 {
3 o s _ e v e n t _ c l r ( p_appdata −>main_events , APP_EVENT_TIMER ) ; / * Re−arm

*/
4 if (
5 ( p_appdata −>main_api . arep ! = UINT32_MAX) &&
6 ( t i c k _ c t r _ u p d a t e _ d a t a > APP_TICKS_UPDATE_DATA) )
7 {
8 tick_ctr_update_data = 0;
9

10 app_handle_cyclic_data (
11 net ,
12 p_appdata ,
13 button1_pressed ,
14 d a t a _ c t r ++ ,
15 p_appdata −>inputdata ,
16 s i z e o f ( p_appdata −> i n p u t d a t a ) ) ;
17

18 ...
19 }

104
 Annexes

.2 Annexe B : Script python pour capteur

Code pour la lecture du capteur DHT11 :

1 import Adafruit_DHT
2 import time
3 s e n s o r = Adafruit_DHT . DHT11
4 DHT11_pin = 23
5

6 # Function f o r c o n v e r t i n g decimal t o b i n a r y
7 def f l o a t _ b i n ( my_number , p l a c e s = 3 ) :
8 my_whole , my_dec = s t r ( my_number ) . s p l i t ( " . " )
9 my_whole = i n t ( my_whole )
10 r e s = ( s t r ( bin ( my_whole ) ) + " . " ) . r e p l a c e ( ’ 0b ’ , ’ ’ )
11

12 f o r x i n range ( p l a c e s ) :
13 my_dec = s t r ( ’ 0 . ’ ) + s t r ( my_dec )
14 temp = ’ %1.20 f ’ %( f l o a t ( my_dec ) * 2 )
15 my_whole , my_dec = temp . s p l i t ( " . " )
16 r e s += my_whole
17 return res
18

19 def IEEE754 ( n ) :
20 # i d e n t i f y i n g whether t h e number
21 # i s p o s i t i v e or n e g a t i v e
22 sign = 0
23 if n < 0 :
24 sign = 1
25 n = n * ( −1)
26 p = 30
27 # convert f l o a t to binary
28 dec = f l o a t _ b i n ( n , p l a c e s = p )
29

30 d o t P l a c e = dec . f i n d ( ’ . ’ )
31 onePlace = dec . f i n d ( ’ 1 ’ )
32 # f i n d i n g t h e mantissa
33 i f onePlace > d o t P l a c e :
34 dec = dec . r e p l a c e ( " . " , " " )
35 onePlace −= 1
36 d o t P l a c e −= 1
37 e l i f onePlace < d o t P l a c e :

105
 Annexes

38 dec = dec . r e p l a c e ( " . " , " " )

39 d o t P l a c e −= 1
40 mantissa = dec [ onePlace + 1 : ]
41

42 # c a l c u l a t i n g t h e exponent ( E )
43 exponent = d o t P l a c e − onePlace
44 e x p o n e n t _ b i t s = exponent + 127
45

46 # c o n v e r t i n g t h e exponent from
47 # decimal t o b i n a r y
48 e x p o n e n t _ b i t s = bin ( e x p o n e n t _ b i t s ) . r e p l a c e ( " 0b " , ’ ’ )
49

50 mantissa = mantissa [ 0 : 2 3 ]
51

52 # t h e IEEE754 n o t a t i o n i n b i n a r y
53 f i n a l = s t r ( s i g n ) + e x p o n e n t _ b i t s . z f i l l ( 8 ) + mantissa
54

55 # c o n v e r t t h e b i n a r y t o hexadecimal
56 h s t r = ’ %0*X ’ %(( l e n ( f i n a l ) + 3 ) // 4 , i n t ( f i n a l , 2 ) )
57 a = ’ 0x ’ + h s t r [ 0 : 2 ]
58 b = ’ 0x ’ + h s t r [ 2 : 4 ]
59 c = ’ 0x ’ + h s t r [ 4 : 6 ]
60 d = ’ 0x ’ + h s t r [ 6 : 8 ]
61

62 return ( a , b , c , d)
63

64 while True :
65

66 humidity , temperature = Adafruit_DHT . r e a d _ r e t r y ( sensor , DHT11_pin )

67 i f humidity i s not None and temperature i s not None :
68 p r i n t ( ’ Temperature = { 0 : 0 . 1 f } * C Humidity = { 1 : 0 . 1 f }% ’ . format (
temperature , humidity ) )
69 with open ( ’ s e n s o r . t x t ’ , "w" ) as m y f i l e :
70 f o r x i n range ( 4 ) :
71 m y f i l e . w r i t e ( s t r ( IEEE754 ( temperature ) [ x ] ) + ’ \n ’ )
72

73 else :
74 ( ’ F a i l e d t o g e t reading from t h e s e n s o r . Try again ! ’ )
75 time . s l e e p ( 1 )

106
 Annexes

.3 Annexe C : GSD file

• GSD file de notre IO device :

1 <VirtualSubmoduleList >
2 <VirtualSubmoduleItem ID = " 1 3 " SubmoduleIdentNumber ="0 x0001 "
MayIssueProcessAlarm =" t r u e " >
3

4 <IOData>
5 <Input C o n s i s t e n c y =" A l l it em s c o n s i s t e n c y " >
6 <DataItem DataType =" F l o a t 3 2 " T e x t I d =" p_value " UseAsBits =" f a l s e "
/>
7 </Input >
8 </IOData>
9

10 <RecordDataList >
11 <ParameterRecordDataItem Index = " 1 2 3 " Length ="4" >
12 <Name T e x t I d =" TOK_sample_parameter_1 "/>
13 <Ref DataType =" F l o a t 3 2 " B y t e O f f s e t = " 0 " D e f a u l t V a l ue = " 1 "
AllowedValues = " 0 . . 9 9 " Changeable =" t r u e " V i s i b l e =" t r u e " T e x t I d ="Demo_1"/>
14 </ParameterRecordDataItem >
15 <ParameterRecordDataItem Index = " 1 2 4 " Length ="4" >
16 <Name T e x t I d =" TOK_sample_parameter_2 "/>
17 <Ref DataType =" F l o a t 3 2 " B y t e O f f s e t = " 0 " D e f a u l t V a l ue = " 2 "
AllowedValues = " 0 . . 9 9 9 " Changeable =" t r u e " V i s i b l e =" t r u e " T e x t I d ="Demo_2
"/>
18 </ParameterRecordDataItem >
19 </RecordDataList >
20 <ModuleInfo >
21 <Name T e x t I d ="TOK_Name_Module_I8O8"/>
22 < I n f o T e x t T e x t I d =" TOK_InfoText_Module_I8O8 "/>
23 </ModuleInfo >
24 </VirtualSubmoduleItem >
25 </VirtualSubmoduleList >

107
 Annexes

.4 Annexe D : Script linux pour test de performance

voici comment installer les dépendances nécessaires pour effectuer les tests :
1 sudo apt − g e t i n s t a l l −y build − e s s e n t i a l
2 g i t c l o n e g i t :// g i t . k e r n e l . org/pub/scm/ u t i l s / r t − t e s t s / r t − t e s t s . g i t
3 cd r t − t e s t s
4 g i t checkout s t a b l e /v1 . 0
5 make a l l − j 4
6 sudo make i n s t a l l

puis on utilise le script mklatencyplot

1 # ! / bin/bash
2

3 # 1 . Run c y c l i c t e s t
4 c y c l i c t e s t − l 1 0 0 0 0 0 0 −m −Sp90 − i 2 0 0 −h400 −q >output
5

6 # 2 . Get maximum l a t e n c y
7 max= ‘ grep "Max L a t e n c i e s " output | t r " " " \n " | s o r t −n | t a i l −1 | sed s
/^0 * // ‘
8

9 # 3 . Grep data l i n e s , remove empty l i n e s and c r e a t e a common f i e l d

separator
10 grep −v −e " ^# " −e " ^$ " output | t r " " " \ t " >histogram
11

12 # 4 . S e t t h e number o f c o r e s , f o r example
13 c o r e s =4
14

15 # 5 . C r e a t e two−column data s e t s with l a t e n c y c l a s s e s and frequency v a l u e s

f o r each core , f o r example
16 f o r i i n ‘ seq 1 $ c o r e s ‘
17 do
18 column = ‘ expr $ i + 1 ‘
19 c u t −f1 , $column histogram > h i s t o g r a m $ i
20 done
21

22 # 6 . C r e a t e p l o t command header
23 echo −n −e " s e t t i t l e \ " Latency p l o t \ " \n\
24 s e t t e r m i n a l svg\n\
25 s e t x l a b e l \ " Latency ( us ) , max $max us\ " \n\
26 s e t l o g s c a l e y\n\
27 s e t xrange [ 0 : 4 0 0 ] \ n\

108
 Annexes

28 s e t yrange [ 0 . 8 : * ] \ n\
29 s e t y l a b e l \ "Number o f l a t e n c y samples\ " \n\
30 s e t output \ " p l o t . svg\ " \n\
31 p l o t " >plotcmd
32

33 # 7 . Append p l o t command data r e f e r e n c e s

34 f o r i i n ‘ seq 1 $ c o r e s ‘
35 do
36 i f t e s t $i != 1
37 then
38 echo −n " , " >>plotcmd
39 fi
40 cpuno = ‘ expr $ i − 1 ‘
41 i f t e s t $cpuno − l t 10
42 then
43 t i t l e = " CPU$cpuno "
44 else
45 t i t l e = " CPU$cpuno "
46 fi
47 echo −n " \ " h i s t o g r a m $ i \ " using 1 : 2 t i t l e \ " $ t i t l e \ " with h i s t e p s " >>
plotcmd
48 done
49

50 # 8 . Execute p l o t command
51 gnuplot − p e r s i s t <plotcmd >

[17]

109
Annexes

.5 Annexe E : IEEE754

Afin de préserver le maximum de bits de précision pour une taille de stockage

donnée k, un nombre à virgule flottante v(ou à point flottant dans la version anglo-
saxonne) est habituellement représenté sous la forme normalisée :

v = (+|−)1.x(k−1) x(k−2) ...x0 ∗ 2E

avec les x des chiffres binaires.

Le chiffre avant la virgule n’est jamais stocké et ne compte donc pas dans le calcul
de la taille du format de représentation. La mise en forme normalisée peut nécessiter
de déplacer le point flottant vers la gauche (lorsque est plus grand que 1 en valeur
absolue) ou vers la droite (lorsque st plus petit que 1 en valeur absolue). [18]

F IGURE 30 – Représentation en mémoire d’un nombre au format IEEE 754

110