Remerciement

Je tiens tout d’abord à remercier M. Romdhane Ridha, mon maître de

stage, qui occupe la fonction de chef département mesures et
instrumentation au sein de la société EPPM, et qui m’a accueilli comme
stagiaire dans son service. Il m’a beaucoup appris sur des enjeux et sur ses
missions au quotidien. Durant mon stage, j’ai eu la chance de pouvoir
bénéficier des conseils de M. CHrifa Mohamed qui est ingénieur à Smart
Energy et je voudrais le remercier pour le temps qu’il m’a accordé et son
aide précieuse.

Je souhaite également adresser mes remerciements les plus sincères aux

équipes pédagogiques et administratives d’ESPRIT qui ont facilité mes
démarches et ont assuré un suivi tout au long de mon stage.

Enfin, un grand merci à ma famille qui m’a toujours encouragé dans mes
choix d’orientation professionnelle et à M. Zouari Talel qui m’a conseillé
pour la rédaction de ce rapport de stage et a eu la gentillesse de bien
vouloir le relire.

1
Table des matières
Introduction Générale.............................................................................................................................8

Introduction...........................................................................................................................................10

I. Présentation de l’entreprise d’accueil : EPPM....................................................................10

II. Présentation de l’entreprise cliente.....................................................................................12

III. Contexte générale du projet................................................................................................13

1 Le QQOQCP.......................................................................................................................13

IV. Présentation du système SCADA et son emplacement dans la pyramide d’automatisation

industrielle............................................................................................................................................16

V. Méthodologie et Objectif....................................................................................................17

1 Concept de parc photovoltaïque..........................................................................................18

2 La supervision des installations photovoltaïques................................................................20

3 Les avantages de la solution...............................................................................................20

CHAPITRE II.......................................................................................................................................22

LES PROTOCOLES DE COMMUNICATION D’UN SYSTÈME SCADA.....................................22

I. Modbus...............................................................................................................................23

1 Modbus RTU......................................................................................................................23

2 Modbus TCP/IP..................................................................................................................25

II. IEC 60870-5........................................................................................................................26

1 Aperçue de l’IEC60870-5...................................................................................................26

2 Transmission.......................................................................................................................28

3 Communication...................................................................................................................29

2
 4 Objets de données d'application..........................................................................................29

5 Adressage............................................................................................................................30

III. Le protocole IEC 104..........................................................................................................30

1 Format de l’APCI................................................................................................................31

2 Format de l’ASDU..............................................................................................................33

IV. IEC 60870-5-104................................................................................................................40

V. DNP 3.0...............................................................................................................................41

VI. Comparaison entre IEC 60870-5-101/104 et DNP 3.0.......................................................41

Chapitre III............................................................................................................................................45

SPECIFICATION.................................................................................................................................45

FONCTIONNELLE.............................................................................................................................45

Introduction...........................................................................................................................................46

I. Méthodologie de conception...............................................................................................46

II. Spécification des besoins....................................................................................................46

1 Besoins fonctionnels...........................................................................................................46

2 Besoins non fonctionnels....................................................................................................47

III. Analyse fonctionnelle.........................................................................................................47

1 UML....................................................................................................................................47

2 Les avantages de l’UML.....................................................................................................47

3 Diagramme de cas d’utilisation globale du système...........................................................48

4 Diagramme cas d’utilisation S’authentifier........................................................................49

5 Diagramme cas d’utilisation Gestion de traçabilité............................................................50

6 Diagramme cas d’utilisation Gestion des données.............................................................51

7 Diagramme cas d’utilisation Visualiser les données..........................................................53

IV. Diagramme de classe..........................................................................................................54

V. Diagramme de séquence.....................................................................................................56

3
Chapitre IV...........................................................................................................................................59

Conception et réalisation......................................................................................................................59

I. Environnement de travail....................................................................................................60

1 Environnement matériel......................................................................................................60

2 Environnement logiciel.......................................................................................................61

II. Architecture de l’échange des données...............................................................................63

1 Structure du message..........................................................................................................64

2 Exemple d’une trame..........................................................................................................65

III. Réalisation et résultat de simulation...................................................................................69

4
Liste des abréviations :

GTC : Gestion Technique Centralisée

RTU : Remote Terminal Unit

APCI : Application Protocol Control Information

ASDU : Application Service Data Unit

IOA : Information Object Address

COT : Cause of Transmission

ORG: Originator Address

QQOQCP : Qui ? Quoi ? Où ? Quand ? Comment ? et Pourquoi

SQ : Structure Qualifier

HTML: Hypertext Markup Language

PHP: Hyper Text Preprocessor

VSC: Visual Studio Code

CSS: Cascading Style Sheets

API: Application Programming Interface

EPA: Enhanced Performance Architecture

UML: Unified Modeling Language

HTTP : HyperText Transfer Protocol

SCADA : Supervisory Control And Data Acquisition » (système de contrôle et d’acquisition de

données),

5
 Liste des figures
Figure 1:logo de l'entreprise d'accueil--------------------------------------------------------------------------11

Figure 2: Logo de l'entreprise cliente--------------------------------------------------------------------------12

Figure 3: Pyramide d'automatisation industrielle-------------------------------------------------------------16

Figure 4:Concept d'un parc photovoltaïque-------------------------------------------------------------------19

Figure 5:Exemple de système de télésurveillance------------------------------------------------------------20

Figure 6:Représentation d'un Modbus de base----------------------------------------------------------------23

Figure 7:câble RS-485 Figure 8:cable série RS-232-----24

Figure 9:les couches d'un modèle OSI vs TCP/IP------------------------------------------------------------26

Figure 10: le modèle OSI vs modèle EPA---------------------------------------------------------------------27

Figure 11:Topologie du réseau----------------------------------------------------------------------------------28

Figure 12:Format de la trame I----------------------------------------------------------------------------------31

Figure 13:Format de la trame APCI----------------------------------------------------------------------------32

Figure 14:Types de trames APCI-------------------------------------------------------------------------------32

Figure 15: Le format de l'ASDU--------------------------------------------------------------------------------34

Figure 16:La structure de l'ASDU avec SQ=0 et SQ=1-----------------------------------------------------37

Figure 17:Exemple d'objet d'information Valeur mesurée normalisée avec l'horodatage (type=10)- -40

Figure 18:Cas d'utilisation général-----------------------------------------------------------------------------49

Figure 19:Cas d'utilisation s'authentifier-----------------------------------------------------------------------49

Figure 20:Cas d'utilisation gestion de traçabilité-------------------------------------------------------------50

Figure 21:Cas d'utilisation gestion des données énergétiques----------------------------------------------52

Figure 22:Cas d'utilisation visualiser les données énergétiques--------------------------------------------53

Figure 23:Diagramme de classe général-----------------------------------------------------------------------55

Figure 24:Diagramme de séquence général-------------------------------------------------------------------57

Figure 25:Carte Raspberry PI 3B+-----------------------------------------------------------------------------61

6
Figure 26:les interconnexions d'une API----------------------------------------------------------------------62

Figure 27:Architecrure d'échange des données par la base de données-----------------------------------64

Figure 28:Organigramme de la procédure Send_ASDU----------------------------------------------------66

Figure 29:Organigramme de la procédure Receive_ASDU (a)---------------------------------------------67

Figure 30:Organigramme de la procédure Receive_ASDU (b)---------------------------------------------68

Figure 31:Exemple d'envoie M_ME_NB_1 ASDU----------------------------------------------------------69

Figure 32:Interface utilisateur du programme de simulation------------------------------------------------70

Figure 33:Interface de configuration IEC----------------------------------------------------------------------71

Figure 34:Configuration I/O-------------------------------------------------------------------------------------72

Figure 35:Page historique d'envoie des données--------------------------------------------------------------73

Figure 36:Historique de configuration IEC-------------------------------------------------------------------74

Liste des tableaux

7
Tableau 1:Méthode QQOQCP-------------------------------------------------------------------------16

Tableau 2: Communication maitre/esclave avec Modbus RTU-----------------------------------28

Tableau 3:Groupes de codes de type définis---------------------------------------------------------39

Tableau 4:DNP3.0 vs IEC60870-5--------------------------------------------------------------------45

Tableau 5:Description de cas d'utilisation S'authentifier-------------------------------------------52

Tableau 6:Description de cas d'utilisation de gestion de traçabilité-------------------------------53

Tableau 7:description de cas d'utilisation de gestion des données énergétiques-----------------54

Tableau 8:description de cas d'utilisation visualiser les données énergétiques------------------55

8
 Introduction Générale

IEC60870-5 est un standard basé sur le modèle de référence réduit appelé architecture de
performance améliorée (EPA). La commission électrotechnique internationale (IEC) a développé le
premier protocole complet connu sous le nom 60870-5-101 pour la communication SCADA. En
effet, c’est un protocole standard de communication internationale pour le télé-contrôle des systèmes
de transmission de puissance électrique. Le protocole est largement adopté dans de nombreux pays à
travers le monde, qui communique par le réseau étendu « WAN ». Habituellement, les normes
60870-5-101 à 60870-5-103 sont utilisées dans des opérations industrielles électriques. La norme
60870-5- 104, quant à elle, fournit des services de communication SCADA par l’utilisation de
protocole de contrôle du transport (TCP) et le protocole internet (IP). Ce dernier fonctionne avec cinq
couches : trois couches de la famille EPA et deux couches supplémentaires du modèle OSI.

Le module à développer est spécialement conçus pour les applications de l'industrie de l'énergie, avec
des capacités de traitement supérieures ainsi que de nombreuses options d'interfaçage et il fournit non
seulement une conversion de protocole one-to-one, mais également une conversion de protocole
many-to-many et prend en charge de nombreuses fonctions selon les normes énergétiques.

Il sera testé pour résister à des variations de température et d'environnement strictes et s'est avéré
efficace dans une variété de segments de l'industrie et des services publics.

Nous exposons dans le présent rapport quatre grands chapitres décrivant les volets principaux de
notre projet de fin d’études :

Le premier chapitre englobera la présentation de l’entreprise d’accueil où nous avons effectué

l’étude, et la présentation de l’entreprise cliente bénéficiaire et le cadre général du projet.

Dans le deuxième chapitre, est consacré sur la compréhension du système SCADA, ces
principaux protocoles.

Le troisième chapitre c’est « spécification fonctionnelle » qui présente nos besoins

fonctionnelles et non fonctionnelles. Il met l’accent sur les divers composants implémentés dans
l’architecture de notre système.

Le dernier chapitre de ce rapport (chapitre IV) traitera la partie « conception et réalisation »

qui présente les différents outils de développement utilisés, notre étude conceptuelle et la validation
de notre système.

9
Chapitre I

Cadre du projet et
méthodologie

10
 Introduction

Ce stage de fin d’étude, a comme objet la conception et la réalisation d’un système électronique de
traitement des données énergétiques. Le module a développé fournit une conversion de protocole
industriel (IEC60870) et prend en charge de nombreuses fonctions selon les normes énergétiques
avec l’aide, la collaboration et l’encadrement des membres de l’entreprise.

J’ai eu l’opportunité de travailler sur ce sujet qui est spécialement conçus pour mettre en œuvre avec
succès les tâches de contrôle et de supervision des données, en mettant l’accent sur la simplicité de
l’utilisation.

I. Présentation de l’entreprise d’accueil : EPPM

EPPM (Engineering Procurement & Project Management) fondée en 1993 est reconnu comme l'un
des principaux contacteurs EPC actifs au Moyen-Orient et en Afrique, opérant dans les secteurs du
pétrole et du gaz (midstream), du traitement des eaux, des énergies renouvelables et des installations
industrielles.

EPPM offre à ses clients une large gamme de services comprenant l'ingénierie, la gestion de projet,
l'approvisionnement, la construction et la supervision, la mise en service et le démarrage ainsi que les
services d'exploitation et de maintenance.

Le siège social d'EPPM est basé en Tunisie avec des filiales dans le monde entier en Algérie, Libye,
Angola, République Démocratique du Congo, KSA, UAE (Dubaï et Abu Dhabi), Irak et Oman.

Au cours des 25 dernières années, EPPM a réalisé avec succès des projets dans les domaines de
l'ingénierie, de l'EPC (projets clés en main), de l'EPS, du PMC, de l'O&M, ainsi que des projets de
financement tels que des projets BOT(Build-Operate-Transfer) et BOO (Build-Operate-Own) à long
terme et des projets de leasing.

EPPM s'engage à respecter les normes internationalement reconnues (telles que ISO : QHSE, ISO
9001 V2000, ISO 14001, OHSAS 18001), dans l'exécution de tous ses projets et a adopté des
services de gestion de projet en conformité avec les normes convenues du Project Management
Institute (PMI).

11
Figure 1:logo de l'entreprise d'accueil

12
II. Présentation de l’entreprise cliente

La société « Smart Energie Saving » est une société qui agit dans le domaine de l’économie de
l’énergie.

Son objectif est de maîtriser l’augmentation de la consommation d’énergie auprès des clients en
optimisant ses coûts d’approvisionnement énergétiques, contribuer à créer des conditions de
prospérité en offrant aux clients des outils économiques pour alimenter leurs besoins énergétiques
avec de moindres coûts. En effet, l’amélioration de l’efficacité énergétique est aujourd’hui un facteur
de compétitivité, ils permettent aux clients de s’inscrire dans une démarche propre apte à concilier
entre leurs activités commerciales, disponibilités énergétiques et les exigences du développement
durable.

Parmi ses activités :

 Correction du facteur de puissance : conception, construction et installation des systèmes de

correction de facteur de puissance spécifique aux sites adaptés à vos besoins d'affaires
 Installation maintenance : maximiser le retour sur les investissements dans les PFC et Filtre
d'harmonique actif avec maintenance régulière du système
 Surveillance du système en ligne : prendre des décisions quant à la capacité et rapidement
vous informer sur les anomalies de puissance et des vêtements de puissance indésirables
 Vérification de la qualité d’énergie : identifier les problèmes et concevoir des solutions
appropriées.

Figure 2: Logo de l'entreprise cliente

13
14
III. Contexte générale du projet

Actuellement, l’énergie solaire photovoltaïque est l’une des sources renouvelables les plus
économiques. La hausse constante des prix de l’énergie électrique unie à l’optimisation dans les prix
des éléments qui intègrent un parc photovoltaïque génère une augmentation directe de
l’investissement dans ces systèmes. Pour cette raison, la puissance moyenne dans les installations de
nouvelle génération augmente de jour en jour, avec le besoin de systèmes capables de superviser et
de gérer les installations sous une forme permanente et d’interagir avec tous les éléments, en assurant
ainsi un rendement optimal, du point de vue technique comme économique.

Notre installation d’une centrale photovoltaïque 10MW à « Meknassy » équivaut à une grande
étendue d’hectares à gérer. Par conséquent, la gestion de l’information et de la maintenance est une
tâche complexe qui rend indispensable de disposer d’un outil de supervision qui permette une
réponse agile et efficace face à toute incidence qui pourrait se produire.

La solution dont je suis amenée à développer doit garantir la supervision et la gestion de parcs
photovoltaïques afin d’obtenir une information détaillée de l’installation, outre les alarmes en temps
réel, qu’elles soient critiques ou non, et l’interaction avec le système en assurant et en améliorant le
rendement d’une ou plusieurs installations dans un même système d’acquisition de données.

1 Le QQOQCP

Le QQOQCP est aussi appelé la méthode de questionnement. C’est un outil qui sert à identifier le
problème dans son ensemble à partir de 6 questions, Qui ? Quoi ? Où ? Quand ? Comment ? et
Pourquoi ? [3]

Cette méthode apporte des informations qui permettent de mieux connaitre, définir et clarifier

Notre problématique car elle explore toutes les dimensions sous différents angles.

Elle représente un bon point de départ pour poser un diagnostic sur le projet. (Tableau 1)

15
 Tableau 1:Méthode QQOQCP

Questions Réponses

Qui est concerné par le projet ? EPPM

Qui est le responsable ? Ridha Romdhane

QUI ?

Qui est le client ? STEG

Qui est intéressé par le résultat ? STEG et EPPM

*L’absence de la commande à
distance.
Quel est le problème ?
*Manque de sécurité
QUOI ?
*Surveillance a distance

Quels sont les produits, quels sont les Des automates, RTU, PC

Constituants ?

Quelles sont les conséquences et Automatisation et sécurité de

impacts de la situation ? distribution

OÙ ? Où se passe la situation ? Mesure et instrumentation

Dans quel service ?

QUAND ? Quand le problème a-t-il été découvert ? Juillet 2018

16
COMMENT ? Comment a été détecté le problème ? Par la société cliente

POURQUOI ? Pourquoi respecter cette procédure ? Pour respecter les engagements

avec les clients

17
IV. Présentation du système SCADA et son emplacement dans la pyramide
d’automatisation industrielle

Les systèmes d’automatisation industriels sont très complexes, car ils se composent de différents
périphériques. Ils se caractérisent par une confluence de fonctionnement de plusieurs équipements
dans une même période. La pyramide d’automatisation industrielle est organisée de manière
hiérarchique comme présentée dans la Figure (3).

Figure 3: Pyramide d'automatisation industrielle

Ce dernier est constitué de quatre couches : la première s’appelle couche d’instrumentation où l’on
trouve les capteurs, les pré-actionneurs et les actionneurs. La deuxième couche est la partie de
contrôle : où l’on peut trouver les automates programmables (API), les régulateurs

(Proportionnel, intégrateur, dérivateur) PID, les ordinateurs PC. Le troisième niveau est la Plateforme
logicielle modulaire (SCADA/MES « ManufacturingExecution System »). Au sommet de la
pyramide, on trouve l’ERP « Entreprise Ressource Planning » c’est un logiciel qui gère la
planification des ressources de l’entreprise.

18
SCADA est l’acronyme de « Supervisory Control And Data Acquisition » (système de contrôle et
d’acquisition de données), un terme qui décrit les fonctions de base d’un système SCADA. Les
entreprises utilisent des systèmes SCADA pour contrôler les équipements sur tous leurs sites, mais
aussi pour collecter et enregistrer des données au sujet de leurs opérations.

Un SCADA est généralement fourni sous forme de logiciel combiné à des éléments matériels, tels
que des automates programmables industriels (API) et des unités terminales distantes (RTU).

La complexité de mettre en place un système SCADA se présente en grande partie dans le choix des
protocoles de communication entre les différents dispositifs de l’installation qui dépend de leur
sécurité.

La solution SCADA de supervision montrera l’état de tous les éléments installés, de la génération
d’énergie sur les plaques photovoltaïques tel que :

 Surveillance en temps réel

Le système surveille en temps réel les variables, électriques ou de toute nature, de tous les dispositifs
installés dans l’installation photovoltaïque pour sa supervision continue

 Alarmes en temps réel

Le système SCADA sera actif en permanence, en générant des alarmes en temps réel pour que les
responsables de la maintenance puissent être informés en temps réel de toute irrégularité qui pourrait
se produire dans l’installation photovoltaïque

 Facilité d’utilisation

Conception personnalisée adaptée aux besoins du client, pour que l’interface soit totalement
conviviale et intuitive.

V. Méthodologie et Objectif

La supervision des centrales photovoltaïques (PV) est un processus important pour assurer le bon
fonctionnement et la performance de ces installations. Elle consiste à collecter des données sur les
différents équipements de la centrale photovoltaïque, tels que les panneaux solaires, les onduleurs, les
batteries, les capteurs de température et les compteurs d'énergie, afin de surveiller leur état de
fonctionnement et de performance.

C’est dans cette optique que s’inscrit la solution réalisée qui consiste en la mise en place d’un des
protocoles utilisés dans un système SCADA qui interagit, en temps réel, avec les systèmes et les
équipements installés sans oublier l’optimisation de la ressource solaire, l’amélioration de

19
l’efficience du centre et la simplification de la gestion pour obtenir le meilleur rendement dans la
production d’énergie solaire.

En outre, le système permet la réalisation de rapports automatiques pour pouvoir réviser les taux de
production souhaités et l’envoi d’alarmes pour l’intervention dans le cas où un problème dans le
centre se produirait.

Les objectifs de ce projet sont :

 La réalisation d’une carte (émettrice/réceptrice) avec le module de communication TCP/IP

 L’acquisition des données du GTC (avec la méthode API et/ou MODBUS)
 L’établissement d’une communication IEC entre la plateforme et le central de dispatching en
utilisant le protocole 608570-5-104
 La Communication des grandeurs physiques avec le distributeur local

1 Concept de parc photovoltaïque

Étant donné qu’une installation photovoltaïque comprend des composants de différents fabricants,
l’intégration et la communication entre eux peut s’avérer un peu complexe.

Pour faciliter la tâche d’intégration et de supervision, SMART ENERGY SAVING a développé une
solution complète et intuitive pour les gestionnaires d’installations photovoltaïques.

Ce schéma montre les différentes possibilités et équipements utilisés dans une installation
photovoltaïque type.

20
Figure 4:Concept d'un parc photovoltaïque

21
 2 La supervision des installations photovoltaïques

Quels que soient la taille et l’usage d’une installation PV, le système de monitoring a pour objectif
principal de suivre l’énergie PV produite, d’évaluer la performance du système PV, de détecter les
dérives ou les dysfonctionnements et d’avertir immédiatement en cas de défaut.

Les systèmes pour installations à grande échelle, de 500 kWc et plus, sont capables de monitorer la
totalité de l’installation, de l’entrée de chaîne au point de connexion au réseau.
Ces systèmes sont basés sur un système SCADA (Supervision Control And Data Acquisition),
permettant le monitoring multisite, les mesures CC et CA, le contrôle à distance des équipements
motorisés, les alarmes intelligentes, la génération de rapports, l’indication de performance et d’autres
fonctions comme l’analyse en profondeur.
Ces systèmes incluent également d’autres équipements pour exploiter le site plus efficacement,
comme une station météo (thermomètres, pluviomètres et anémomètres), des capteurs d’irradiance,
un contrôleur de site qui communique avec l’opérateur du réseau pour adapter la production du site
aux variations du réseau (tension, facteur de puissance) et des compteurs spécifiques tels que des
compteurs de consommation (RGM) proches du point de connexion.
Ces systèmes SCADA peuvent être locaux et/ou distants, avec des capacités de redondance et un
traitement de données très performant.

Figure 5:Exemple de système de télésurveillance

3 Les avantages de la solution

On travaille sur quatre axes principaux :

 Rentabilité

22
Haute rentabilité de l’investissement, la supervision maximise la productivité de l’installation
photovoltaïque.

 Qualité

Longévité de l’installation, la surveillance continue permet d’allonger la vie des équipements de

l’installation.

 Accessibilité

Connexion simple, accès distant au SCADA de l’installation depuis tout point du monde.

 Sécurité

Gestion continue, alarmes et rapports automatiques de rendement de production.

Conclusion

Dans ce chapitre, on a présenté la société d’accueil avec ses différents départements et la société
cliente ainsi leur activité et leur domaine. Par la suite, on a défini le cadre du projet, son objectif et les
étapes suivies pour sa réalisation. L’objectif du chapitre suivant est de décrire les différents
protocoles d’un système SCADA et en s’intéressera plus précisément à l’IEC60870 ; le protocole qui
a été mis en place dans ce présent travail.

23
 CHAPITRE II

LES PROTOCOLES DE COMMUNICATION

D’UN SYSTÈME SCADA

24
 INTRODUCTION

SCADA signifie "Contrôle de supervision et acquisition de données ». En effet, SCADA est un

système de surveillance et de contrôle qui peut être géré, en temps réel, une grande quantité de
données de mesure à tout moment. De plus, le système enregistre quelques données programmées
dans une base de données.

Une grande partie de la complexité de la configuration d'un système SCADA provient du choix
du protocole de communication entre les différents appareils de votre installation.

La section suivante présente les protocoles de communication les plus connus et on va s’intéressé
plus précisément à celui qu’on a travaillé avec « l’IEC60870-5 ».

I. Modbus

Modbus est un protocole de communication série développé par « Modicon ». C'est une

Méthode de transmission en série d'informations entre les appareils électroniques.

Un appareil demandant des informations est appelé un "maître". Les appareils qui fournissent des
informations, en revanche, sont des "esclaves". En réseau, la norme Modbus, le maître a jusqu'à 247
esclaves, chaque esclave a une adresse unique de 1 à 247. Les maîtres peuvent également écrire des
informations aux esclaves.

Ce protocole est ouvert, il est devenu un standard de communication dans l’industrie.

On utilise Modbus pour transmettre des signaux à partir des appareils d’instrumentations.

Le protocole Modbus de base entre un maître et l'esclave est présenté dans la Figure7.

Figure 6:Représentation d'un Modbus de base

1 Modbus RTU

Modbus RTU est un protocole ouvert qui transmet des données en série sur un câble (RS-232 ou
RS-485) dérivé d'une architecture maître/esclave. C'est un protocole largement accepté en raison de
sa facilité d'utilisation, il est très utilisé dans les systèmes automatiques industriels.

25
Figure 7:câble RS-485 Figure 8:cable série RS-232

Les messages Modbus RTU sont structurés dans une architecture 16bits. La simplicité de cette
architecture est d'assurer la fiabilité de la transmission des messages. Ce protocole prend en charge
les tableaux, des textes ASCII, Files d'attente et autres données indépendantes.

Ce tableau présente la méthode de communication entre le maitre et l’esclave à travers le Modbus

RTU

Tableau 2: Communication maitre/esclave avec Modbus RTU

Maitre Esclave

Requête initiale
Effectuer l’action

Code de fonction Information de requête Initiale de réponse

Réception de réponse Code de fonction Information de requête

26
 2 Modbus TCP/IP

Le protocole TCP/IP (Transmission Control Protocol/Internet Protocol) réunit les deux protocoles
TCP et IP qui sont utilisés conjointement pour transmettre des données avec des garanties de fiabilité
en utilisant la couche transport du modèle OSI (voir figure 10).

Lorsque des informations sur Modbus sont envoyées en utilisant ces protocoles, les données sont
transmises à TCP puis envoyées dans une adresse IP.

Ensuite, IP place les données dans un paquet et le transmet dans un dispositif de réception.

Ce protocole fonctionne avec le mode Client / Serveur. Les clients sont tous actifs, le serveur est
complètement passif. Chaque client a le droit de lire et écrire dans le serveur.

La performance d'un réseau Modbus TCP dépend fortement du type et de la conception du réseau
Ethernet. Ce dernier utilise les performances des processeurs dans les interfaces de communication
pour les dispositifs respectifs.

Modbus TCP est une approche pragmatique qui utilise Ethernet comme un moyen de transmission de
données pour les applications d'automatisation. Il divise les différentes tâches de communication
en couche. Chaque couche remplit une fonction différente. Les données passent par quatre couches
individuelles avant d'être reçues à l'autre extrémité

27
 Figure 9:les couches d'un modèle OSI vs TCP/IP

II. IEC 60870-5

1 Aperçue de l’IEC60870-5

La norme IEC 60870-5 fait partie de l'ensemble des normes IEC 60870 qui définissent les
systèmes utilisés pour la télé-conduite (contrôle de surveillance et acquisition de données) dans les
applications d'ingénierie électrique et d'automatisation des réseaux électriques.

La partie 5 fournit un profil de communication pour l'envoi de messages de télécontrôle de

base entre deux systèmes, qui utilise des circuits de données permanents directement connectés entre
les systèmes. Le comité d'études 57 de la CEI a élaboré une norme de protocole pour la télé-conduite,
la télé-protection et les télécommunications associées pour les systèmes d'alimentation électrique. Le
résultat de ce travail est la norme IEC 60870-5. Le comité d'études 57 de la CEI a également élaboré
des normes complémentaires :

 IEC 60870-5-101 Protocoles de transmission - Normes complémentaires, notamment pour les

tâches de télécontrôle de base
 IEC 60870-5-102 Protocoles de transmission - Norme complémentaire pour la transmission
des totaux intégrés dans les systèmes d'énergie électrique
 IEC 60870-5-103 Protocoles de transmission - Norme complémentaire pour l'interface
informative des équipements de protection

28
  IEC 60870-5-104 Protocoles de transmission - Accès au réseau pour la CEI 60870-5-101 en
utilisant des profils de transport standards

Dans notre projet, on va travailler avec deux normes IEC 60870-5-101 et IEC 60870-5-104 qui est
une analogie du premier avec les changements dans les services de transport, de réseau, de liaison et
de couche physique pour s'adapter au réseau complet.

La pile de protocoles IEC 60870-5 est basée sur le modèle de référence réduit appelé Enhanced
Performance Architecture (EPA) qui comprend trois couches du modèle OSI : couche application
(7), couche de liaison (2), et couche physique (1) (voir figure 11).[1]

Figure 10: le modèle OSI vs modèle EPA

La couche physique définit les spécifications dépendantes du matériel de l'interface de

communication de la IEC 60870-5-101.

La couche liaison de données définit les formats de trame et les procédures de transmission de la
communication CEI

La couche application définit les éléments d'information permettant de structurer les données de
l'application et les fonctions des services de communication. [3]

29
 2 Transmission

La norme CEI 60870-5-101 fournit un profil de communication pour l'envoi de messages de

télécontrôle de base entre une station centrale de télécontrôle (maître) et des stations de télécontrôle
externes (esclaves), qui utilise des circuits de données permanents directement connectés entre la
station centrale et les stations individuelles, voir la figure (12).

Figure 11:Topologie du réseau

La spécification CEI 104 combine la couche application de la norme CEI 60870-5-101 et les
fonctions de transport fournies par un protocole TCP/IP (Transmission Control Protocol/Internet
Protocol).

La norme CEI 101 autorise deux procédures de transmission alternatives :

 Transmission déséquilibrée : la station de contrôle commande le trafic de données en

interrogeant les postes contrôlés de manière séquentielle. Elle initie tous les transferts de
messages, tandis que les stations extérieures contrôlées ne font que répondre à ces messages.
Les services suivants sont supportés :
- ENVOI/NON RÉPONSE pour les messages globaux et pour les commandes de points de
consigne cycliques
- ENVOI/CONFIRMATION pour les commandes de contrôle et les commandes de point
de consigne.
- DEMANDER/RÉPONDRE pour l'interrogation des données des stations extérieures
contrôlées.
 Transmission équilibrée : dans ce mode, chaque station peut initier le transfert de messages.
Les stations peuvent agir simultanément en tant que stations de contrôle et stations contrôlées
(elles sont appelées stations combinées). La transmission équilibrée est limitée aux
configurations point à point et point à point multiples. Les services soutenus sont :

30
 - ENVOI/CONFIRMATION
- ENVOI/NON RÉPONSE : ceci ne peut être initié que par une station de contrôle avec une
adresse de diffusion dans une configuration multiple point à point. [3]

3 Communication

La différence entre les directions de contrôle et de surveillance est un concept important pour
comprendre l'adressage selon la norme CEI 60870-5. Il est supposé que le système global a une
structure hiérarchique impliquant un contrôle centralisé, selon le protocole, chaque station est soit
une station de contrôle, soit une station contrôlée.

La communication IEC 101/104 est échangée entre la station contrôlée et la station de contrôle.

 La station contrôlée est surveillée ou commandée par une station maîtresse (RTU).
 La station de contrôle est une station où le contrôle des stations est effectué (SCADA).

Aussi la norme CEI 101/104 définit plusieurs modes de direction, La direction du moniteur est une
direction de transmission de la station contrôlée (RTU) à la station de contrôle (PC), la direction de
contrôle est une direction de transmission de la station de contrôle, typiquement un système SCADA,
à la station contrôlée, typiquement un RTU et la direction inversée qui est une direction dans laquelle
la station surveillée envoie des commandes et la station de contrôle envoie des données dans la
direction de surveillance.

4 Objets de données d'application

La norme CEI 60870-5 contient des informations sur un ensemble d'objets d'information qui
conviennent à la fois aux applications SCADA générales et aux applications de systèmes électriques
en particulier. Chaque type de données possède un numéro d'identification de type unique (Type ID).

Un seul type de données est inclus dans une unité de données de service d’application (ASDU). Le
type est le premier champ de l'ASDU.

Les types d'objets d'information sont groupés par direction (direction de surveillance ou de contrôle)
et par le type d'information (information sur le processus, information sur le système, les paramètre
de transfert de fichiers).

Ainsi, les données de l'application sont transportées dans l'ASDU dans un ou plusieurs objets
d'information en fonction de l'indicateur de structure variable (SQ), il peut y avoir plusieurs objets
d'information, chacun contenant un ensemble défini d'un ou plusieurs éléments d'information.

Un seul objet d'information contenant un certain nombre d'éléments d'information identiques. Dans
les deux cas, l'élément d'information est le composant fondamental utilisé pour transmettre des
informations dans le cadre du protocole. [3]

31
 5 Adressage

La norme CEI 101 définit l'adressage tant au niveau de la liaison qu'au niveau de l'application.
L'adresse de liaison (ou adresse du dispositif) et l'adresse ASDU (ou adresse commune) sont fournies
pour l'identification de la station finale :

L'adresse du dispositif est le numéro d'identification du dispositif, e champ de l'adresse de liaison

peut être de 1 ou 2 octets pour une communication non équilibrée, et de 0, 1 ou 2 octets pour une
communication équilibrée. Comme les communications équilibrées sont de type point à point,
l'adresse de liaison est redondante, mais peut être incluse par sécurité.

La plage de valeurs dépend de la longueur de l'adresse de liaison qui peut être d'un octet, c'est-à-dire
de 1 à 255, ou de deux octets, c'est-à-dire de 1 à 65 535. Les valeurs typiques sont 1 pour IEC 101 et
2 pour IEC 104.

Chaque dispositif du réseau de communication possède une adresse commune de l'ASDU (adresse
COA ou ASDU), l'adresse commune de l'ASDU, combinée à l'adresse de l'objet d'information
contenu dans les données elles-mêmes, constitue l'adresse unique de chaque élément de données.

COA est généralement l'adresse d'application du client (station logique) qui doit correspondre à
l'adresse définie dans la configuration du client. Cette adresse est définie comme l'adresse de la
station de contrôle dans le sens du contrôle, dans le sens de la surveillance, en revanche, le champ
d'adresse commun contient l'adresse de la station qui renvoie les données (station contrôlée). Cette
information est nécessaire pour que les données puissent être identifiées de manière unique et mises
en correspondance avec les bons points dans les images de données du système. [3]

III. Le protocole IEC 104

Le protocole IEC-104 est largement utilisé dans les systèmes SCADA modernes.

La trame de base du protocole IEC-104 est appelée Unité de données du protocole d'application
(APDU) et une trame APDU peut être au format U, S ou I-format.

La trame de contrôle non numérotée (U) est utilisée pour tester, démarrer ou arrêter les flux de
communication. Le format de supervision (S) est utilisé pour exécuter des fonctions de supervision
numérotées. Le format d'instruction d'information (I) est utilisé pour envoyer des commandes et des
informations numérotées.

L'APCI contient des informations de base telles que la longueur du paquet et le numéro de séquence
et l'ASDU contient les attributs détaillés.

Il existe les trois attributs utilisés pour l'identification et l'extraction des événements dans cette étude.

1) L'identification du type contient le code d'instruction.

32
 2) La cause de transmission est toujours spontanée.
3) Les adresses des objets d'information (IOA) sont les adresses des données surveillées à
l'intérieur du RTU.
 Les événements spontanés ne peuvent être envoyés qu'au format I.

Figure 12:Format de la trame I

1 Format de l’APCI

Chaque APCI (Application Protocol Control Information) commence par un octet de départ de valeur
0x68 suivi de la longueur de 8 bits de l'APDU (Application Protocol Data Unit) et de quatre champs
de contrôle de 8 bits. L'APDU contient un APCI, voir la figure (14) En général, la longueur de
l'APCI est de 6 octets.

33
 Figure 13:Format de la trame APCI

Le format de la trame est déterminé par les deux derniers bits du premier champ de contrôle. La
norme définit trois formats de trame, voir la figure (15). [3]

Figure 14:Types de trames APCI

I-Format (format de transfert d'informations), le dernier bit de CF1 est 0. Il est utilisé pour effectuer
le transfert d'informations numérotées entre le poste de commande et la station contrôlée. Il a une
longueur variable.

Les APDUs de I-format contiennent toujours un ASDU. Le champ de contrôle de I-format indique la
direction du message. Il contient deux numéros de séquence de 15 bits qui sont séquentiellement
augmentés d'une unité pour chaque APDU et chaque direction.

S-Format (fonctions de surveillance numérotées), les derniers bits de CF1 sont 01.

34
Il est utilisé pour effectuer des fonctions de supervision numérotées. Il a une longueur fixe, les APDU
au format S sont toujours composés d'un seul APCI.

Dans tous les cas où le transfert de données s'effectue dans un seul sens, les APDU de S-format
doivent être envoyés dans l'autre sens avant le dépassement du délai d'attente, le dépassement de la
mémoire tampon ou lorsqu'ils ont dépassé le nombre maximal d'APDU de format I autorisés sans
accusé de réception.

U-Format (fonctions de contrôle non numérotées), les derniers bits de CF2 sont 11.

Il est utilisé pour exécuter des fonctions de contrôle non numérotées. Il a une longueur fixe.

Les APDU au format U sont toujours composés d'un seul APCI. Une seule des fonctions TESTFR
(Test Frame), STOPDT (Stop Data Transfer) ou STARTDT (Start Data Transfer) peut être activée en
même temps. [3]

2 Format de l’ASDU

L'ASDU contient deux sections principales : l'identifiant de l'unité de données (d'une longueur fixe
de six octets), et les données elles-mêmes, composées d'un ou plusieurs objets d'information.

L'identificateur d'unité de données définit le type spécifique de données, fournit un adressage

permettant d'identifier l'identité spécifique des données, et inclut des informations supplémentaires
comme cause de la transmission. Chaque ASDU peut transmettre au maximum 127 objets.

Le format de l'ASDU est présenté à la figure (16). [3]

35
 Figure 15: Le format de l'ASDU

L’ASDU contient les champs suivants :

 Identification du type (Type ID, 1 octet) :

0 n'est pas utilisé, 1-127 est utilisé pour les définitions standard de la CEI 101, 128-135 est réservé
pour le routage des messages et 136-255 pour une utilisation spéciale.

36
Dans la gamme des définitions standard IEC 101, il existe actuellement 58 types spécifiques définis.
Ces types forment les groupes suivants, voir le tableau (3).

TypeID Groupe

1-40 Traiter l'information dans le sens du moniteur

45-51 Traiter les informations dans le sens du

contrôle

70 Informations sur le système dans le sens du

moniteur

100-106 Informations sur le système dans le sens du

contrôle

110-113 Paramètre dans la direction du contrôle

120-126 Transfert de fichiers

Tableau 3:Groupes de codes de type définis

Il est important de noter que l'identification du type s'applique à l'ensemble de l'ASDU ; par
conséquent, si l'ASDU contient plusieurs objets d'information, ils sont tous du même type.

 Le bit SQ (Structure Qualifier) spécifie comment les objets ou éléments d'information sont
adressés.

SQ=0 (séquence d'objets d'information) : adressage d'éléments d'information individuels ou d'une

combinaison d'éléments d'information dans un certain nombre d'objets d'information (OI) du même
type.

37
Chaque élément individuel ou combinaison d'éléments est adressé par l'adresse de l'objet
d'information. L'ASDU peut se composer d'un ou de plusieurs objets d'information égaux.

Le nombre d'objets est codé en binaire (nombre d'objets) et définit le nombre d'objets d'information.

SQ=0 implique une séquence d'objets d'information où chaque objet a sa propre adresse d'objet
d'information. Le nombre d'objets d'information est donné par la valeur de sept bits dans
l'identificateur d'unité de données (champ nombre d'objets)

Il peut donc y avoir jusqu'à 127 objets d'information dans cet ASDU.

SQ=1 (un seul objet d'information) : adressage d'une séquence d'éléments d'information uniques ou
de combinaisons égales d'éléments d'information d'un objet unique par objet d'éléments d'information
ou de combinaisons égales d'éléments d'information d'un seul objet par ASDU.

Lorsque SQ=1, la structure contient une séquence d'éléments d'information dans un objet
d'information.

Tous les objets d'information ont le même format. Il n'y a qu'une seule adresse d'objet d'information,
qui est l'adresse du premier. [3]

38
 Figure 16:La structure de l'ASDU avec SQ=0 et SQ=1

 Nombre d'objets/éléments :
o Utilise la plage 0 - 127
o 0 signifie que l'ASDU ne contient aucun objet d'information (IO)
o 1-127 définit le nombre d'objets d'information ou d'éléments.

 Le bit T (test) définit les ASDUs qui ont été générés dans des conditions de test et qui ne sont
pas destinés à contrôler le processus ou à modifier l'état du système.

T=0 (pas de test), T=1 (test)

 Le bit P/N (positif/négatif) indique la confirmation positive ou négative d'une activation

demandée par une fonction d'application primaire.

P/N = 0 (confirmation positive), P/N = 1 (confirmation négative).

39
 P/N est significatif lorsqu'il est utilisé avec des commandes de contrôle. Le bit est utilisé lorsque
la commande de contrôle est reflétée dans la direction du moniteur, et il fournit une indication sur
l'exécution ou non de la commande.

Lorsque le bit PN n'est pas pertinent, il est mis à zéro.

 Cause de la transmission (COT)

Le champ COT est utilisé pour contrôler l'acheminement des messages à la fois sur le réseau de
communication et à l'intérieur d'une station, en dirigeant l'ASDU vers le programme ou la tâche
appropriée pour le traitement. Les ASDUs dans le sens du contrôle sont des services d'application
confirmés et peuvent être reproduites dans le sens du contrôle avec des causes de transmission
différentes.

Le COT est un code à six bits qui est utilisé pour interpréter l'information à la station de destination.
Chaque type d'ASDU défini possède un sous-ensemble défini de codes qui lui sont significatifs. [3]

 Adresse de l'expéditeur (ORG)

L'adresse de l'expéditeur est facultative sur la base du système. Elle permet à une station de contrôle
de s'identifier explicitement. Cela n'est pas nécessaire lorsqu'il n'y a qu'une seule station de contrôle
dans un système. Lorsqu’il y a plus d'une station de contrôle, ou lorsque certaines stations sont des
stations bi-modes, dans ce cas, l'adresse de l'expéditeur peut être utilisée pour diriger les
confirmations de commande vers l'ensemble du système.

L'adresse de l'expéditeur dirige les ASDU en miroir et les ASDU interrogées dans la direction du
moniteur vers la source qui a activé l'ASDU.

Si l'adresse de l'expéditeur n'est pas utilisée (les bits sont mis à zéro) et s'il y a plus d'une source
unique dans un système défini, les ASDUs dans la direction du moniteur doivent être dirigés vers
toutes les sources pertinentes du système, dans ce cas, la source spécifique affectée doit sélectionner
ses ASDUs spécifiques. [3]

 Champ d'adresse ASDU

L'adresse est appelée adresse commune car elle est associée à tous les objets contenus dans l'ASDU.
Elle est normalement interprétée comme une adresse de station, Toutefois, elle peut être structurée de
manière à former une adresse de station/secteur où les stations individuelles sont divisées en
plusieurs unités logiques. [3]

L'adresse globale est une adresse de diffusion dirigée vers toutes les stations d'un système spécifique
(adresse de diffusion).

Les ASDUs avec une adresse de diffusion dans le sens du contrôle doivent être répondues dans le
sens du contrôle par l'adresse commune spécifique définie (adresse de station).

40
Selon la norme, ce paramètre se compose de 2 octets

La valeur 0 n'est pas utilisée, la plage 1 - 65 534 signifie une adresse de station, la valeur 65535
(0xFFFF) signifie une adresse globale qui est utilisée lorsque la même fonction d'application doit être
initiée simultanément. Elle est limitée aux ASDUs suivants :

o Type=100 (commande d'interrogation) : réponse avec des données système particulières

instantané à un moment donné
o Type=101 (commande d'interrogation de compteur) : geler les totaux au temps commun
o Type=103 (commande de synchronisation de l'horloge) : synchronise les horloges à l'heure
commune
o Type=105 (commande de processus de réinitialisation) : réinitialisation simultanée [3]

Information Objets

L'ASDU transmet des objets d'information dans sa structure. Chaque objet d'information est adressé
par une adresse d'objet d'information (IOA) qui identifie les données particulières dans une station
définie.

Sa longueur est de 3 octets pour la norme CEI 104. L'adresse est utilisée comme adresse de
destination dans le sens du contrôle et comme adresse de source dans le sens de la surveillance.

Le troisième octet de l'IOA est uniquement utilisé en cas de structuration de l'adresse de l'objet
d'information afin de définir des adresses non ambiguës dans un système spécifique. Dans tous les
cas, le nombre maximal d'adresses différentes est limité à 65 535 (comme pour deux octets).

Si l'adresse de l'objet d'information n'est pas pertinente (non utilisée) dans certains ASDU, elle est
mise à zéro.

Tous les objets d'information transmis par un ASDU doivent avoir le même type d'ASDU, s'il y a
plus d'objets de types différents à transmettre, ils sont insérés dans plusieurs ASDU.

Certains objets d'information contiennent plusieurs éléments d'information. Par exemple, la figure 11
montre un objet d'information de type 10 (valeur mesurée, normalisée avec repère temporel). Cet
objet est défini uniquement pour SQ=0 et contient trois éléments d'information valeur normalisée
NVA (2 octets), descripteur de qualité (1 octet) et horodatage binaire (1 octet), pour ce type d'objet,
les causes valides de transmission sont spontanées (code 3) ou demandées (code 5). [3]

41
 Figure 17:Exemple d'objet d'information Valeur mesurée normalisée avec l'horodatage (type=10)

Le nombre d'objets d'information et d'éléments d'information dans l'ASDU est le nombre d'objets
indiqué dans le deuxième octet de l'en-tête de l'ASDU.

 La plupart des ASDU sont identiques entre -101 et -104. Principalement des différences avec
les balises temporelles.

IV. IEC 60870-5-104

Il s'agit d'une extension du protocole CEI 60870-5-101 avec des modifications apportées aux services
de transport, de réseau, de liaison et de couche physique pour satisfaire la gamme complète d'accès
au réseau. La norme utilise l'interface réseau TCP/IP (Transmission Control Protocol/Internet
Protocol) pour fournir une connectivité LAN (Local Area Network).

Deux couches de liaison distinctes sont définies dans la norme, qui convient au transfert de données
sur Ethernet et sur ligne série (PPP - Point-to-Point Protocol). Les données du champ de contrôle de
la norme CEI104 contiennent divers types de mécanismes pour une gestion efficace de la
synchronisation des données du réseau.

La couche application de la CEI 104 reste la même que celle de la CEI 101, certains types de données
et services n'étant pas utilisés.

Le protocole CEI 104 est utilisé pour les systèmes d'alimentation et le protocole CEI 101 est utilisé
pour le centre de télécontrôle. [3]

42
V. DNP 3.0

DNP 3.0 (Distributed Network Protocol version 3) est un protocole de communication utilisé dans les
systèmes de contrôle de processus industriels. Il a été développé pour répondre aux exigences de
communication des réseaux de distribution d'énergie électrique, mais il est également utilisé dans
d'autres industries telles que l'eau, le gaz et le pétrole.

DNP 3.0 a été conçu pour offrir une communication fiable, efficace et sécurisée entre les
équipements de contrôle de processus à distance et les centres de contrôle. Il utilise une architecture
client-serveur pour permettre la communication bidirectionnelle entre les équipements de terrain et
les centres de contrôle. Le protocole permet également la communication entre les équipements de
terrain, ce qui peut être utile pour la surveillance et le contrôle des processus.

Les principales caractéristiques de DNP 3.0 sont les suivantes :

Redondance : DNP 3.0 offre une redondance intégrée pour assurer une communication fiable en cas
de panne de l'un des canaux de communication.

Sécurité : DNP 3.0 utilise des mécanismes de sécurité tels que l'authentification, le cryptage et la
vérification de l'intégrité des données pour garantir la sécurité de la communication.

Évolutivité : DNP 3.0 peut être étendu pour prendre en charge de nouveaux types de données et de
nouveaux équipements.

Gestion des données : DNP 3.0 fournit des fonctions pour la gestion des données, telles que
l'enregistrement des données et la gestion des événements.

Diagnostic et surveillance : DNP 3.0 permet la surveillance et le diagnostic à distance des

équipements de terrain, ce qui peut aider à identifier les problèmes avant qu'ils ne deviennent
critiques.

En résumé, DNP 3.0 est un protocole de communication fiable, sécurisé et évolutif pour les systèmes
de contrôle de processus industriels. Il offre des fonctionnalités avancées pour la gestion des données,
la surveillance et le diagnostic, ainsi que la redondance intégrée pour garantir une communication
fiable.

VI. Comparaison entre IEC 60870-5-101/104 et DNP 3.0

IEC 60870-5/104/101 et DNP3.0 sont deux protocoles de communication utilisés dans les systèmes
de contrôle et d'acquisition de données (SCADA) pour les réseaux électriques et les systèmes de
distribution d'eau. Les deux protocoles ont des caractéristiques similaires, mais il y a des différences
dans quelque point.

La section suivante compare les deux protocoles sous différents angles.

43
44
 Tableau 4:DNP3.0 vs IEC60870-5

Protocole IEC 60870-5-104/101 DNP 3.0

Date de réalisation 1993 1993

Développé par IEC standards TC 57 WG 03 Harris

Support standard IEC 60870 IEEE 1815-2012

Interface physique RS 485 et fibre optique RS 232 ,485 et Ethernet

Type de Maitre/esclave Maitre/esclave,

communication client/serveur

Support modèle OSI Couche application et 3 2eme,4ème et 7éme couche

couches d’EPA soutenant TCP/IP

Vitesse de transmission 19200 BPS 38400 BPS

Marché dominant Europe L’Amérique du nord

Il convient de noter que ces caractéristiques ne sont pas exhaustives et que le choix entre les deux
protocoles dépendra des besoins spécifiques de chaque système de contrôle et d'acquisition de
données.

Conclusion

Lors de ce chapitre, une présentation des principaux éléments d’un système SCADA a été proposée.
L’évolution dans le temps du système SCADA a démontré qu’il est aujourd’hui de plus en plus
ouvert et utilisé dans divers domaines d’application (industriel, éducation, énergétique, etc.). Après
l’étude des différents protocoles de communication nous avons choisi de travailler avec l’IEC60870-
5-104, l’étape suivante sera consacré à l’étude des besoins aussi bien que la mise en cadre des
spécifications.

45
46
Chapitre III

SPECIFICATION

FONCTIONNELLE

47
 Introduction

Dans ce chapitre nous allons étudier la spécification des besoins afin de déterminer et préciser les
fonctionnalités attendues de notre projet, ensuite nous allons suivre une méthodologie de
modélisation UML afin d’évoquer les différents diagrammes (diagramme de séquence, de classe et
de cas d’utilisation).

I. Méthodologie de conception

La conception d’un système d’information est une étape cruciale et essentielle pour le lancement
d’un projet informatique, elle s’effectue préalablement à la réalisation et nécessite une méthodologie
de travail adéquate répondant aux spécifications du système et aux exigences des utilisateurs dans
l’objectif d’aboutir à la solution adéquate. La phase de conception permet de décrire le
fonctionnement du système à venir et de formaliser les étapes préparatoires de son développement, en
vue d’en faciliter la réalisation et d’assurer la conformité aux besoins de l’utilisateur. La phase de
modélisation nécessite des méthodes d’analyse et de conception permettant de mettre en place une
représentation virtuelle d’une réalité.

II. Spécification des besoins

La spécification des besoins exprime les comportements ou les actions que le système doit respecter.
Ces spécifications se présentent en deux catégories : les spécifications fonctionnelles et non
fonctionnelles. Ces dernières seront décrites ci-dessous.

1 Besoins fonctionnels

Ces besoins représentent les principales fonctionnalités du système. Ils proviennent généralement des
utilisateurs de ce système.

L’interface à développer doit permettre :

 Gestion de traçabilité : cette variante des taches permet la consultation d’historique de

configuration et des grandeurs envoyés.
 Gestion de configuration : ce service inclus dans les taches effectué par l’utilisateur à travers
lequel il peut ajouter ou supprimer les grandeurs à envoyer.
 Supervision du système : cette tache assure la supervision en temp réel des changement des
valeurs.

48
 2 Besoins non fonctionnels

Ces spécifications n’expriment pas une fonction du système mais agissent de façon indirecte sur le
résultat et sur la performance du système. Ce qui fait que nous ne devons pas les contraintes ci-
dessous :

 La sécurité : sécuriser l’envoie des données.

 La performance : les interfaces web doivent être performantes et facile à manipuler, et le plus
important qu’elles doivent être compréhensibles, et bien organisées.
 La disponibilité en permanence du système : à tout moment notre système doit être capable de
vérifier les valeurs en temps réel et de stocker les changements de configuration.

III. Analyse fonctionnelle

Pour mieux comprendre les fonctionnalités de notre système, nous avons recourt à une approche
incontournable dans le cadre du développement des interfaces web, c’est la méthode orientée
objet, une méthode normalisée pour visualiser la conception du système.

Nous avons choisi le langage de modélisation le plus adopté UML.

1 UML

UML n’est pas une méthode (C’est une description normative des étapes de la modélisation) : ses
auteurs ont en effet estimé qu’il n’était pas opportun de définir une méthode en raison de la diversité
des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet de représenter
et de communiquer les divers aspects d’un système d’information aux graphiques qui sont bien sûr
associés à des textes qui expliquent leur contenu. UML est donc un métalangage car il fournit les
éléments permettant de construire le modèle qui, lui, sera le langage du projet.
2 Les avantages de l’UML

UML est un langage formel et normalisé. Il permet ainsi : Un gain de précision, un gage de stabilité
et l'utilisation d'outils.

UML est un support de communication performant : Il cadre l'analyse et facilite la compréhension de

représentations abstraites complexes. Son caractère polyvalent et sa souplesse lui font un langage
universel.

 Objectif :

- Construire des modèles de systèmes

- Organiser le travail

49
 - Gérer le risque

En conclusion, nous avons choisi de travailler avec UML parce qu’il exprime mieux la vue statique et
dynamique du système d'information et pour notre interface web, il est nécessaire de faire une
analyse très approfondie pour pouvoir dégager les nécessités de développement ainsi que quelques
scénarios d'exécution. [8]

Dans la conduite de ce sujet, nous avons choisi de travailler autour de trois diagramme UML :

 Diagramme de classe : permet de décrire la structure statique d’un système

 Diagramme de séquence : c’est une représentation des interfaces entre les éléments du
système et/ou de ses acteurs

 Diagramme de cas d’utilisation : permet de décrire les fonctionnalités du système du point de

vue de l’utilisateur.

Pour représenter ces diagrammes, nous avons choisi StarUML comme logiciel de modélisation cédé
comme open source par son éditeur. [9]

3 Diagramme de cas d’utilisation globale du système

Dans cette section nous allons modéliser les fonctionnalités principales de notre système.

L’acteur principale est l’utilisateur qui manipule le système, après être identifié il peut gérer les
données. Cette action n’est possible que lorsque le serveur nous permet l’accès à la base des données.
Par la suite, on peut les visualiser en temps réel et gérer la traçabilité.

La figure (19) et le 1er tableau présentent le diagramme de cas d’utilisation général.

50
 Figure 18:Cas d'utilisation général

4 Diagramme cas d’utilisation S’authentifier

Ce diagramme décrit les cas d’utilisation « s’authentifier » avec les scénarios nominaux et alternatif
figure (20).

Figure 19:Cas d'utilisation s'authentifier

51
 Tableau 5:Description de cas d'utilisation S'authentifier

Cas d’utilisation S’authentifier

Acteur Utilisateur (Superviseur)

Précondition Saisir les données d’accès (Port et Adresse IP).

Postconditions L’accès à l’interface suivante, ou message

d’erreur.

Scénario nominal Utilisateur saisit le Port et l’adresse IP

Exception Affichage d’un message d’erreur.

5 Diagramme cas d’utilisation Gestion de traçabilité

Le diagramme de cas d’utilisation de la figure (21) ainsi le tableau (5) montrent les spécifications
de cette tâche.

52
 Figure 20:Cas d'utilisation gestion de traçabilité

Tableau 6:Description de cas d'utilisation de gestion de traçabilité

Cas d’utilisation Gestion de traçabilité

Résumé Cette partie sert à contrôler l’utilisation de l’interface.

L’utilisateur peut vérifier les variables envoyés,
l’horaire de l’envoie, l’historique de chaque
configuration.

Scenario normal L’utilisateur accède à l’interface.

Pour consulter l’historique l’utilisateur doit appuyer
sur le bouton historique, une interface s’ouvrira
contenant les informations nécessaires.

Scénario d’erreur L’utilisateur n’appuie pas sur le bouton historique

Précondition L’administrateur doit s’authentifier

53
 Postcondition Interface d’affichage par date et heure

6 Diagramme cas d’utilisation Gestion des données

Vue que la modification de données ne sera pas gérée que lorsqu’on ajoute des variables et les
enregistrer, nous préférons d’étudier ces cas ensemble.

En effet, le diagramme de cas d’utilisation sur la figure (22) et le tableau (6) illustrent les
spécifications de cette tâche.

Figure 21:Cas d'utilisation gestion des données énergétiques

Tableau 7:description de cas d'utilisation de gestion des données énergétiques

Cas d’utilisation Gestion des données

Résumé Cette partie sert à interagir avec le système pour gérer les
données énergétiques.

L’utilisateur peut modifier les données énergétiques

existantes, d'en ajouter de nouvelles.

54
 Scénario normal L’utilisateur accède à l’interface SETUP IEC, il doit
sélectionner les variables à afficher.

Le système va remplir les champs automatiquement suite à la

configuration d’I/O Adress.

Si les champs sont remplis, l’utilisateur doit enregistrer ses

configurations.

Scénario d’erreur L’utilisateur n’enregistre pas les changement

Précondition L’utilisateur doit s’authentifier

Postcondition Commande du système

7 Diagramme cas d’utilisation Visualiser les données

Le diagramme de cas d’utilisation de la figure (23) et le tableau (7) montrent les spécifications
fonctionnelles de cette tâche.

55
Figure 22:Cas d'utilisation visualiser les données énergétiques

56
 Tableau 8:description de cas d'utilisation visualiser les données énergétiques

Cas d’utilisation Visualiser les données

Résumé Lors de l’utilisation de l’interface RunTimeClient

l’utilisateur peut visualiser les données énergétiques en
temps réel.

Scénario normal L’utilisateur doit cliquer sur le bouton RunTime dans le

menu.

Le système envoie une requête à l’API pour avoir les

variables ainsi leurs valeurs en temps réel.

Scénario d’erreur L’utilisateur n’a pas enregistrer son configuration

Précondition L’utilisateur doit s’authentifier

Postcondition Interface d’affichage en temps réel par date et heure

IV. Diagramme de classe

Le diagramme de classe est considéré comme le point central dans la modélisation orientée objet, il
est utile pour plusieurs raisons. Tout d'abord, il permet de visualiser clairement la structure du
système, ce qui peut aider les développeurs à mieux comprendre l'architecture globale du système.
Ensuite, il permet de détecter rapidement les erreurs de conception ou les incohérences dans le
système, en montrant les dépendances entre les classes. De plus, il peut être utilisé pour générer du
code automatiquement à partir du modèle, ce qui peut accélérer le processus de développement. [13]

57
Afin de représenter une vue globale sur les différentes fonctions de notre système, les entités et les
opérations réalisées, nous avons modélisé sur la figure (24) les classes du système.

Figure 23:Diagramme de classe général

Dans ce diagramme de classe, la classe IEC104Client représente le simulateur de client IEC 104.
Cette classe contient les attributs ip_address, port, connexion, ainsi que les méthodes connect,
disconnect, start, stop, send et IEC104 event.

La deuxième classe IEC104Event représente un événement IEC 104. Elle contient les attributs
event_type et data, qui représentent le type d'événement et les données de l'événement,
respectivement.

La 3éme classe EventType est une énumération utilisée pour représenter les différents types
d'événements IEC 104 possibles MEASURED_VALUE, SCALED_VALUE ...

Ces types d'événements sont utilisés pour déterminer le format des données dans l'événement.

La quatrième classe IEC104 APDU représente une trame IEC104 qui contient plusieurs variables qui
composent la trame.

Et finalement La classe IEC104 Server représente un serveur IEC104 qui écoute les connexions
entrantes et peut envoyer/recevoir des trames IEC104.

58
Ces classes permettent de modéliser le comportement d'un simulateur de client IEC 104 en
fournissant les outils nécessaires pour établir une connexion avec un serveur distant, envoyer des
événements et recevoir des événements en retour.

V. Diagramme de séquence

Les diagrammes de séquence sont utilisés pour représenter les interactions entre les différents objets
d'un système, ou les différentes parties d'un système, en montrant comment les messages sont
échangés entre eux au fil du temps. Ils permettent de modéliser les scénarios d'utilisation et de
comprendre les interactions complexes entre les différents composants d'un système.

Ce diagramme de séquence présenté dans la figure (25) représente l’enchainement des actions et des
interactions entre les différents éléments de notre projet. [13]

59
 Figure 24:Diagramme de séquence général

Ce diagramme de séquence montre les étapes suivantes :

1. L'utilisateur affiche l'interface utilisateur.

2. L'interface utilisateur lance la connexion avec le serveur IEC104.

3. Le client IEC104 envoie une demande de connexion au serveur IEC104.

4. Le serveur IEC104 accepte la demande de connexion du client IEC104.

60
 5. Le client IEC104 envoie une demande de lecture des données énergétiques au serveur
IEC104.

6. Le serveur IEC104 envoie les données énergétiques initiales au client IEC104.

7. Le client IEC104 affiche les données énergétiques initiales sur l'interface utilisateur.

8. Le serveur IEC104 envoie une notification de changement de données énergétiques chaque

fois qu'il y a une mise à jour des données.

9. Le client IEC104 met à jour les données énergétiques affichées sur l'interface utilisateur en
fonction des notifications reçues du serveur IEC104.

10. Le processus de mise à jour des données énergétiques affichées se répète en boucle jusqu'à ce
que l'utilisateur termine la session. [13]

Conclusion

Durant ce chapitre, nous avons commencé par présenter les différents besoins attendus de notre
projet, ensuite, nous avons identifié les acteurs et présenté la description du diagramme de cas
d’utilisation global et celle textuelle de chaque cas.

La partie de conception et le choix de l’environnement de travail sera l’objectif du chapitre qui suit.

61
Chapitre IV

Conception et réalisation

62
Introduction
Après l’analyse approfondie dans le chapitre précédant des fonctionnalités, dans ce chapitre nous
présentons la conception de l'interface graphique de supervision de notre centrale photovoltaïque.
Nous décrivons les fonctionnalités de l'interface utilisateur, les exigences de conception, les outils et
les technologies utilisés pour la conception de l'interface utilisateur.

I. Environnement de travail

L'environnement de travail pour le développement d'un système de contrôle de centrale

photovoltaïque basé sur le protocole IEC 104 peut être configuré comme suit :

1 Environnement matériel

Raspberry Pi : est une carte électronique peu coûteuse, équipée d'un processeur ARM, de ports GPIO
et de connectivité Ethernet, Wi-Fi et Bluetooth, elle est utilisée comme plateforme de développement
pour le système de contrôle en raison de sa flexibilité et de sa capacité à exécuter différents types de
logiciels. Le Raspberry Pi sera utilisé pour exécuter le contrôleur de centrale électrique (Power
PlantController), ainsi que pour héberger une base de données MySQL pour stocker les données de la
centrale électrique. [4]

Caractéristiques :
- Alimentation à prévoir : 5 Vcc/maxi 2,5 A* via prise micro-USB (* intensité maxi si toutes
les fonctions sont utilisées)
- CPU : ARM Cortex-A53 quatre cœurs 1,4 GHz
- Wi-Fi: Dual-band 2,4 et 5 GHz, 802.11b/g/n/ac (Broadcom BCM43438)
- Bluetooth 4.2 (Broadcom BCM43438)
- Memoir: 1 GB LPDDR2
- Ethernet 10/100/1000 : jusqu'à 300 Mbps
- 4 ports USB 2.0
- Port Ethernet 10/100 base T : RJ45
- Bus : SPI, I2C, série
- Support pour cartes micro-SD
- Sorties audios : HDMI avec gestion du 5.1/Jack 3,5 mm en stéréo
- Sorties vidéo : HDMI
- Dimensions : 86 x 54 x 17 mm

63
 Figure 25:Carte Raspberry PI 3B+

Power Plant Controller : un contrôleur industriel programmable (PLC) utilisé pour interconnecter les
différents équipements de la centrale photovoltaïque et collecter les données.

Maquette : C’est un prototype elle se compose des capteurs utilisés pour collecter les données
environnementales telles que la température, l'humidité, la luminosité, des Onduleurs et analyseurs
qui sont des équipements de la centrale photovoltaïque, utilisés pour générer de l'énergie solaire.

Un PC : ordinateur portable MSI

2 Environnement logiciel

 Système d'exploitation : le Raspberry Pi peut être équipé d'un système d'exploitation tel que
Raspbian, basé sur Debian, qui offre une compatibilité élevée avec les logiciels open-source.
 Langages de programmation : Python le langage de programmation que nous avons utilisé
pour développer le système de contrôle et les applications de l'API REST.
 MySQL : un système de gestion de bases de données relationnelles utilisé pour stocker les
données collectées par le système de contrôle.
MySQL utilise phpMyAdmin comme interface pour gérer les bases de données sur un serveur
PHP, c’est le moyen le plus adopté qui permet d’exécuter facilement et sans ambiguïté, les
requêtes de création de table, insertions, mise à jour, suppression et modifications de structure
de la base de données. [2]
 PHP : est un langage de programmation côté serveur, souvent utilisé pour créer des
applications web dynamiques. Il est open-source, ce qui signifie que le code source est
disponible pour tout le monde et peut être modifié selon les besoins. [11]

64
 PHP peut être utilisé pour générer du contenu HTML, manipuler des fichiers, interagir avec
des bases de données, et bien plus encore. Il est souvent combiné avec des bases de données
comme MySQL pour stocker et récupérer des informations.

L'une des principales caractéristiques de PHP est qu'il peut être intégré directement dans des
fichiers HTML, ce qui facilite l'écriture de pages web dynamiques. Il est également facile à
apprendre et à utiliser, ce qui en fait un choix populaire pour les développeurs débutants.

 API REST : un ensemble de protocoles et de normes permettant la communication entre

différentes applications, utilisé pour interconnecter le système de contrôle avec d'autres
systèmes et applications.

Figure 26:les interconnexions d'une API

Nous avons également choisi d'utiliser une API REST pour permettre aux utilisateurs d'interagir avec
la centrale électrique à distance. L'API REST sera développée en Python, le choix d’une API Restful
répond à des commandes et à des langages spécifiques. Elle est donc plus simple, plus flexible et plus
rapide que les autres types d’APIs. Par conséquent, elle est adaptée à un usage industriel en entreprise. [12]

Les requêtes se font toujours au format HTTP. Les réponses parviennent au client sous un format
standardisé : JSON.

 CSS (Cascading Style Sheets) : c’est un langage de feuilles de style utilisé pour décrire la présentation
d'un document HTML ou XML. CSS est utilisé pour définir les styles visuels tels que la couleur, la
taille de police, la mise en page, les marges, le positionnement et d'autres aspects de l'apparence d'un
document.
Le CSS permet de séparer la présentation de la structure du document, ce qui permet de modifier
facilement l'apparence d'un site Web en modifiant simplement le fichier CSS sans avoir à modifier le
code HTML. [6]

65
  Visual Studio Code (VSC) : est un éditeur de code source gratuit et open source développée par
Microsoft. Il est disponible pour Windows, Mac OS et Linux. Visual Studio Code est conçu pour
les développeurs qui travaillent avec plusieurs langages de programmation et pour les
développeurs de logiciels web qui créent des sites web dynamiques. [10]
Nous avons choisi cet éditeur pour ses fonctionnalités d’édition avancées.

 En utilisant ces technologies, il est possible de développer un système de contrôle de centrale

photovoltaïque fiable et efficace, permettant une collecte et une analyse des données en temps
réel, ainsi qu'une communication transparente avec d'autres systèmes et applications.

II. Architecture de l’échange des données

L'échange de données entre une base de données MySQL, une API REST, une carte Raspberry Pi et
un client IEC 104 peut être expliqué comme suit :

1) La base de données MySQL stocke les données à être utilisées par l'interface. Ces données
peuvent inclure des informations telles que des mesures de courant, Tension, puissance, etc.
[2]
2) L'API REST fournit une interface pour accéder aux données de la base de données. La
communication entre la base de données et l'API REST est généralement effectuée en utilisant
le langage SQL (Structured Query Language).
3) La carte Raspberry Pi est un dispositif qui peut être utilisé pour accéder à l'API REST. Elle
peut envoyer des requêtes HTTP ou HTTPS pour récupérer des données à partir de l'API
REST ou pour envoyer des données à l'API REST pour les enregistrer dans la base de
données.
4) Le client IEC 104 est un protocole de communication utilisé pour échanger des données en
temps réel entre des équipements de contrôle de processus. Il peut être utilisé pour envoyer
des commandes aux équipements ou pour recevoir des données de mesure et d'état. Le client
IEC 104 se connecte à la carte Raspberry Pi via une connexion réseau pour échanger des
données.
5) La carte Raspberry Pi peut utiliser l'API REST pour récupérer les données stockées dans la
base de données MySQL et les transmettre au client IEC 104. De même, le client IEC 104
peut envoyer des données à la carte Raspberry Pi via la connexion réseau, et la carte
Raspberry Pi peut utiliser l'API REST pour enregistrer ces données dans la base de données
MySQL.

 En résumé, l'API REST fournit une interface pour accéder aux données stockées dans la base
de données MySQL, et la carte Raspberry Pi peut être utilisée pour accéder à l'API REST et
échanger des données avec un client IEC 104. Cette architecture permet d'interconnecter
différents équipements de contrôle de processus et de partager des données en temps réel pour
permettre une meilleure gestion et une optimisation des processus.

66
 Figure 27:Architecrure d'échange des données par la base de données

1 Structure du message

Les messages envoyés ont une structure imbriquée, qui dérive de la structure en couches du
protocole. L'ASDU (service applicatif Unité de données) est un bloc de données envoyé par les
processus d'application dans une autre station. L'ASDU est spécifié sous forme de trames de longueur
variable.

Une trame à longueur variable utilisée dans CEI 870-5-104 commencer par :

 Caractère de début d'un octet.

 Deux octets Longueur de trame
 Caractère de début d'un octet.
 Champ de contrôle d'un octet.
 Adresse de liaison d'un octet.

Et arrête avec :

* Somme de contrôle d'un octet.

* Caractère d'arrêt d'un octet.

L'ASDU est composé d'un identificateur d'unité de données et d'un ou plusieurs Objets informatifs.
L'identifiant de l'unité de données a toujours la même structure pour tous les ASDU. Les objets

67
d'information d'un ASDU sont toujours de même structure et de même type, qui sont définis dans le
type champ d'identification.

La structure de l'identifiant de l'unité de données est :

 Identification du type sur un octet.

 Qualificatif de structure variable d'un octet.
 Un/deux octets Cause de la transmission.
 Adresse commune à un/deux octets de l'ASDU.

La structure de l'objet d'information est :

 Identifiant de l'objet d'information.

 Ensemble d'éléments d'information.
 Horodatage de l'objet d'information (optionnel).
2 Exemple d’une trame

Dans la procédure d'envoi et de réception d'unités de données de service d'application (ASDU), le

serveur (station secondaire) génère une trame de longueur fixe. Cette trame a été construite à partir
des trames de départ et d'arrêt, en plus de l'unité de données de service d'application (ASDU).

 L'organigramme de la procédure d’envoie ci-dessus est présenté par la figure (29).

68
 Figure 28:Organigramme de la procédure Send_ASDU

 Procédure de réception : Dans cette procédure, le client (station primaire) vérifie tous les
octets - un par un - du message reçu. S'il n'y a pas d'erreurs par rapport aux spécifications
utilisées, la station primaire détermine et affiche les valeurs mesurées. L’Organigramme est
présenté dans la figure (30et31).

69
Figure 29:Organigramme de la procédure Receive_ASDU (a)

70
 Figure 30:Organigramme de la procédure Receive_ASDU (b)

Et comme résultat de simulation la figure (32) nous montre un exemple d’envoi d’une trame :

 Le bit de start « Start byte » c’est fixé à 0x68 ce qui donne en décimal "104"
 Le caractère de longueur de la trame « Length of the APDU » était fixé à "54", ce qui
spécifiait
 Send sequence number N(S) LSB = 90 => I-Format
 Send sequence number N(S) MSB=20
 Receive sequence number N(R) LSB=124
 Receive sequence number N(R) MSB=0
 Originator address = 0
 Common ASDU address (2 octets) = 1 dec
 La trame d’ASDU commence par Type_ID qui a été réglé sur "11" pour se référer à
Measured value, Scaled value « M_ME_NB_1 »
 La cause du caractère de transmission « COT » était fixée à "3", ce qui se référait à un
balayage en arrière-plan, utilisé dans la direction du moniteur pour synchroniser les données
 « Number of object » Selon l’exemple décrit dans la figure 27 nous avons choisi d’envoyer 7
variables (V1, I1, P1, Q1, Qt, Ewh, Evah) chacun d’eux s’écrit sur 6 bits :
1) Object_address_octets_1

71
 2) Object_address_octets_2
3) Object_address_octets_3
4) Scaled_value_octets_1
5) Scaled_value_octets_2
6) Scaled_value_octets_3

Figure 31:Exemple d'envoie M_ME_NB_1 ASDU

III. Réalisation et résultat de simulation

Lorsque le programme a été exécuté, une interface est apparue, qui contient certains valeurs envoyés
(Tension, courant, puissance…) comme le montre la figure (33). Toutes les grandeurs étaient
sélectionnées au hasard en raison du large choix. Cela permet également de les visualiser en temps
réel et ça change proportionnellement avec les données envoyées de l’API à chaque instant.

72
 Figure 32:Interface utilisateur du programme de simulation

Lorsque l’utilisateur passe à la deuxième page de configuration des différents types d’ASDUs

La page apparait comme l’indique la figure (34).

73
 Figure 33:Interface de configuration IEC

Ici l’utilisateur peut choisir les types d’ASDUs, les différentes grandeurs physiques à afficher à partir
de l’API en sélectionnant les variables dans la colonne « SCADA_TAG » et tous les autres champs
vont se remplir automatiquement grâce à la page suivante ‘SETUP IO’ comme le montre la figure
(35). Et pour finir la configuration on clique sur le bouton « SAVE » pour enregistrer notre choix.

74
 Figure 34:Configuration I/O

Dans cette page, on a fait la configuration de chaque variable :

 Le nom
 L’adresse IO
 Le type
 L’unité
 Le coefficient

Et pour finir on a ajouté une page d’historique « HISTORY » ou on trouve les différentes valeurs de
mesure envoyée pendant des différents date et heure (Courant, Tension, puissances actifs et réactives,
Energie, facteur de puissance…) qui représentent les éléments d'information du message.

75
 Figure 35:Page historique d'envoie des données

En termes de sécurité et confidentialité on a fait aussi une partie d’historique de configuration IEC
pour que chaque utilisateur peut garder son travail enregistrer et garder des notes de traçabilité.

76
 Figure 36:Historique de configuration IEC

Conclusion

Ce chapitre nous a permis de concevoir une interface graphique spécifique qui permettra à
l’opérateur de configurer plusieurs paramètres de l’installation.

Nous avons réalisé à l’aide de cette interface l’envoie et la réception des données entre la centrale de
dispatching aux clients à travers l’API et le power plant Controller. Ces tests ont permis de valider la
fiabilité du protocole conçue en matière pour la télé-conduite, la télé-protection et d'autres fonctions
de télécommunication pour les systèmes d'alimentation électrique.

77
 Conclusion générale

L'objectif principal de cette recherche est d'étudier ce protocole en détails pour obtenir des
connaissances sur le fonctionnement, la configuration et la mise en œuvre du cadre protocolaire. Le
deuxième objectif est de simuler une partie des fonctions du protocole, telles que transfert des valeurs
de mesure avec un nombre à virgule flottante.

Cette recherche a couvert tous les aspects théoriques de la Protocole CEI60870/104. Le programme
de simulation est implémenté et couvre une partie des fonctions du protocole, telles que la procédure
de transfert des valeurs de mesure avec nombres à virgule flottante.

Le programme a besoin de quelques ajouts des types d’ASDUs pour appliquer le contrôle/monitoring
des stations secondaires par la station primaire.

Pour les futurs travaux, le programme de simulation a besoin d’un développement pour inclure toutes
les fonctions de protocole restantes qui couvrent tous les types de massages.

Dans ce projet, nous avons présenté la conception et la mise en œuvre d'une interface graphique de
supervision centrale photovoltaïque conforme à la norme IEC60870. Notre solution permet de
superviser et de contrôler plusieurs sites de production photovoltaïque à partir d'une interface
utilisateur unique. Notre solution a été validée par des tests rigoureux et a démontré sa fiabilité et son
efficacité. Nous espérons que ce travail sera utile pour les professionnels travaillant dans le domaine
de la surveillance et du contrôle des systèmes photovoltaïques.

78
 Bibliographie

[1] la norme IEC-60870-5, https://en.wikipedia.org/wiki/IEC_60870-5 , (8 March 2023).

[2] MySQL, récupéré sur Wikipédia : https://fr.wikipedia.org/wiki/MySQL, (2019, avril 21).

[3] Description and analysis of IEC 104 Protocol, Rapport technique no. FIT-TR-2017-12,
(décembre, 2017) :

https://www.fit.vut.cz/research/publication-file/11570/TR-IEC104.pdf.

[4] https://www.raspberrypi.com/products/raspberry-pi-3-model-b-plus

[5] logiciel IDE Raspberry, https://www.raspberrypi.com/software/

[6] CSS, https://www.futura-sciences.com/tech/definition/internet-css-4050, (2023)

[8] UML en français, Récupéré sur http://UML.free.fr/, (2017, Janvier)

[9] StarUML, MKLabs Co.,Ltd. https://staruml.io/, (2014-2023)

[10] Visual studio code, https://code.visualstudio.com/, (février 2023)

[11] Manuel PHP, Peter Cowburn, https://www.php.net/, (22 mars 2023)

[12] API rest, Red Hat® Integration, https://www.redhat.com/fr/topics/api/what-is-a-rest-api, (8 mai

2020)

[13] chat GPT, Open AI, https://chat.openai.com/chat, (30 novombre 2022)

79
Annexe A: IEC 104 ASDU types and their description

Annexe B : Cause of Transmission (COT) values

80
81