Des exemples de briques technologiques dans le cadre d'une application pour l'industrie du futur

HAL Id: hal-01768653

https://hal.archives-ouvertes.fr/hal-01768653

Submitted on 19 Apr 2018

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Des exemples de briques technologiques dans le cadre d’une application pour l’industrie du futur

Pascal Vrignat, Manuel Avila, Jean-François Millet, Bernard Roblès, Florent Duculty, Stéphane Begot, Jean-Christophe Bardet, David Delouche, Toufik

Aggab, Julien Thuillier, et al.

To cite this version:

Pascal Vrignat, Manuel Avila, Jean-François Millet, Bernard Roblès, Florent Duculty, et al.. Des

exemples de briques technologiques dans le cadre d’une application pour l’industrie du futur. La

Revue 3 E. I, Société de l’électricité, de l’électronique et des technologies de l’information et de la

communication, 2018. �hal-01768653�

1

DES EXEMPLES DE BRIQUES TECHNOLOGIQUES DANS LE CADRE D'UNE APPLICATION POUR L'INDUSTRIE DU FUTUR

Pascal Vrignat

, Manuel Avila

, Bernard Roblès

, Jean-François Millet

, Florent Duculty

, Stéphane Begot

, Christophe Bardet

, David Delouche

, Toufik Aggab

, Julien Thuillier

,

Frédéric Kratz

.

1

Université d’Orléans, IUT de l’Indre, Laboratoire PRISME, Châteauroux, France

2

HEI Campus Centre, Laboratoire PRISME, Châteauroux, France

3

INSA Centre-Val de Loire, Laboratoire PRISME, Bourges, France

[email protected]

RESUME : La quatrième révolution industrielle est à l’évidence bien en marche. Tous les jours nous en avons la démonstration au travers de nouveaux modes d’organisation autant marchands qu’industriels de la société. Nous sommes confrontés à des ruptures majeures aussi bien liées à l’évolution des technologies qu’à la mondialisation de l’économie avec l’émergence et la maturité de nouveaux acteurs : le défi de la transition énergétique, la révolution du numérique, la protection de notre planète, les convergences entre les sciences du vivant et des sciences dures… Cet article présente des applications implémentées dans le cadre de la mise en place de technologie “Internet of Things” par l'utilisation d'un réseau Profinet. Ces applications peuvent être utilisées sur l’ensemble des processus de l’entreprise dans le cadre de l'Industrie du Futur. Le standard OPC est apparu au milieu des années 90 pour faciliter les échanges entre le monde des automatismes et celui de la supervision basée sur PC. Les dernières spécifications d’OPC UA (Unified Architecture) sont aujourd'hui validées. Avec cette nouvelle version, la fondation OPC révolutionne son standard de communication entre équipements industriels. OPC UA rompt les liens qui le rendaient indissociable de Windows, pour se déployer sur tous types de plateformes.

Mots clés : Industrie du Futur, SCADA, Siemens, Profinet, Reporting, Serveur OPC UA, Interface Homme-Machine

1. INTRODUCTION

Le projet “Industrie du Futur”, lancé le 14 avril 2015, doit jouer un rôle central dans la démarche de la seconde phase de la Nouvelle France Industrielle

avec pour objectif, d’amener chaque entreprise à franchir un pas sur la voie de la modernisation de son outil industriel et de la transformation de son modèle

1

Le 12 septembre 2013, le Président de la République associé au Ministre de l’économie, de

économique par le numérique. De nombreux indicateurs montrent que nous sommes à l’aube d’une révolution majeure, porteuse de nombreuses innovations et créatrice d’une nouvelle dynamique de marché. Plusieurs termes peuvent nommer cette révolution [18], [19] : “Industrie du Futur”, “Cyber-Usine”, “Usine digitale”,

“Integrated Industry”, “Innovative Factory”

l’industrie et du numérique lançaient conjointement

à l’Élysée 34 plans de reconquête industrielle (les 34

plans de la Nouvelle France Industrielle).

2 ou “Industrie 4.0”. Le moyen pour y parvenir impliquera obligatoirement les technologies de l’Internet dans un processus de fabrication [11] (Fig. 1). Des objets communicants et autonomes viendront se greffer à la “toile” pour créer un écosystème informationnel connecté utilisant le concept de l’“Internet des objets” ou “Internet of Things

”.

Fig. 1 : Un exemple de décryptage des briques technologiques de l’Industrie du Futur : 4 axes principaux et un axe transverse, présent sur

l’ensemble de ces axes

Les résultats présentés dans [16] précisent quelques chiffres à retenir. Ils sont issus d’une enquête menée par PAC

en février 2016 auprès de 150 entreprises industrielles

de plus de 500 personnes ayant déjà eu des réflexions sur le sujet de l’IoT (Fig. 2).

Fig. 2 : Enquête du PAC / 2016

L'intégration des briques technologiques au sein des processus d’une entreprise de production peut être définie suivant le modèle présenté dans la Fig. 3 [21]. Cette représentation s'insère sur différents verrous technologiques : échelle de maturité des technologies disponibles et/ou savoir-faire, roadmap d’appropriation.

L'Internet of Things est donc devenu indispensable pour accéder à différents services et répondre aux exigences de l'Usine digitale.

Fig. 3 : Des applications IoT possibles sur l’ensemble des processus de l’entreprise

2

IoT

https://www.pac-online.com/liot-dans-lindustrie-

en-france

3 Nous proposons des éléments de réponse à cette révolution numérique avec un certain nombre de briques et de fonctionnalités très intéressantes qui peuvent être implémentées dans le cadre d'un contrôle-commande de processus. De nombreuses solutions technologiques et verrous sont présentés à partir d'un processus simple à mettre en œuvre. Cet article se décompose en deux sections. Dans la première section, nous présentons l'architecture TIC

qui a servi de support de tests. Dans la seconde section, nous présentons les différents travaux qui ont été menés afin de valider le concept de l'Industrie du Futur. Ces travaux peuvent être menés à bien dans le cadre de formations supérieures (étudiants d’IUT

ou d’écoles d’ingénieurs à vocation technologique). Nous terminons nos propos par une conclusion et des perspectives.

2. L'ARCHITECTURE UTILISEE DES RESEAUX

L'architecture réseaux utilisée est un environnement mis en place depuis 1994 au sein de l'IUT de l'Indre sur le site de Châteauroux. Cette architecture a évolué à de nombreuses reprises et peut ressembler aujourd'hui, à un réseau d'entreprise classique. La Fig. 4 présente deux bâtiments (Plateau Technique et IUT) interconnectés à partir d'une solution fibre optique (FO). Des réseaux sur support en cuivre servent de canaux de transmission dans les différents services et différentes salles (sous-réseau VLAN

). Des services Wifi sont également disponibles (U32). Une fibre optique est également présente pour interconnecter l'IUT et le CES

à un réseau numérique très haut débit inter-universités : RENATER

.

Fig. 4 : Architecture réseaux de l'IUT de l'Indre – Site de Châteauroux

4

TIC pour un usage de base de l'Internet, l'interconnexion de systèmes et réseaux, les systèmes d'information.

5

IUT : Institut Universitaire de Technologie

6

Virtual Local Area Network

7

Centre d'Etudes Supérieures

8

Réseau National de télécommunications pour la

Technologie, l'Enseignement et la Recherche

4 Le processus piloté dans notre étude est raccordé au VLAN3 GEII. Ce VLAN interconnecte trois étages du département avec différentes salles et différents matériels et processus (ordinateurs, imprimantes, systèmes ou maquettes pédagogiques…). La Fig. 5 décrit la zone qui a fait l'objet des différents tests. La salle concernée intègre différents matériels de différents constructeurs interconnectés en réseaux. De nombreux postes informatiques de travail sont également interconnectés dans la baie de brassage de la salle (Fig. 5 (a)). L'objet détaillé de l'étude concerne le réseau PROFINET et PROFINET IO

qui vient d'être installé dans cette salle (Fig. 5 (b)). PROFINET IO est un standard Ethernet industriel ouvert et destiné au monde de l'automatisation. Contrairement au PROFINET CBA

qui est destiné aux systèmes distribués. PROFINET IO se concentre sur l'échange de données entre Automates Programmables Industriels

ou Interface Homme-Machine. PROFINET IO est très similaire à PROFIBUS. Alors que PROFIBUS utilise les communications cycliques pour échanger des données avec des API à une vitesse maximale de transmission 12 Mbits/s, PROFINET IO utilise le transfert de données cyclique pour échanger des données avec des API sur

Ethernet. Comme avec PROFIBUS, un contrôleur programmable associé à un autre dispositif doivent tous deux avoir une compréhension préalable de la structure de données et connaitre le sens du transfert.

PROFINET couvre l’ensemble de la gamme des applications d’automatisation et se distingue à cet effet par trois caractéristiques de communication :

• le non-temps réel (temps non maitrisé), par exemple : communication TCP/IP et UDP/IP,

• le temps réel (RT

),

• le temps réel isochrone (IRT

).

Sont interconnectés sur ce réseau, un API (CPU-Siemens : 1512C) et sept pupitres opérateurs (KTP700). Ces pupitres opérateurs sont des clients de l'application hébergée dans l'automate associés à des variables partagées (Fig. 7). Ils peuvent contrôler individuellement le processus (entrées / sorties). Le déploiement de cette architecture peut s’appliquer à une ligne de production de grande longueur nécessitant un volume de pupitres opérateurs suffisant afin que ces derniers puissent contrôler la ligne en tous points.

Fig. 5 : Architecture réseaux du processus (support des tests)

9

ROFINET IO est l’évolution du réseau PROFIBUS DP vers une base Ethernet

10

Component Based Automation

11

API

12

Real Time

13

Isochronous Real-Time. Ce terme est un canal de

communication optionnel, situé à côté du canal

Ethernet standard. Le terme isochrone signifie que

chaque trame est envoyée avec un intervalle de

temps très précis.

5 Ce processus est constitué d'une partie commande interconnectée à des entrées- sorties de type Tout Ou Rien (TOR) et analogiques (Fig. 6 (a) et (b)). Elle gère des recettes de fabrication (3 recettes) associées à des consignes de vitesses apportées à un moteur électrique asynchrone via un variateur de vitesse de type U/F.

Fig. 6 : Organisation de la partie commande associée à son actionneur

Fig. 7 : Résumé du tableau des variables partagées par l’automate

3. STRUCTURE PYRAMIDALE D’UNE ENTREPRISE EN LIAISON AVEC DES BESOINS EN

INFORMATIQUE INDUSTRIELLE Dans le monde exigeant du contrôle- commande de processus, l'accès à des données de processus et/ou d'usine en ligne et en temps “souhaité” est crucial. La croissance d’une entreprise se traduit par une croissance parallèle du volume des données issues du processus et de la demande de traduction en informations pertinentes pour les équipes d'exploitation et de direction [13]. Souvent, les personnes qui ont en charge un système d’information doivent s’attacher à connecter et récupérer

les informations pertinentes de leur usine

via leur système informatique [10]. Lorsque

cela fonctionne, les personnes concernées

ne peuvent souvent pas utiliser

efficacement et rapidement les données

brutes issues de la production, pourtant

essentielles pour le contrôle des coûts

d'exploitation. Le travail présenté consiste à

mettre en place une structure opérationnelle

montrant les fondements d’une architecture

industrielle communicante (Fig. 8). Il

apporte un grand nombre de compléments

d’information par rapport aux articles [3],

[15], [22], [23]. A partir des informations

émanant du processus, nous souhaitons

6 développer et utiliser plusieurs clients dans une démarche SCADA

.

Fig. 8 : Architecture pyramidale dans le Concept CIM

Nous montrons dans cet article plusieurs solutions à implémenter pour effectuer un large panel de tests. Pour cela, les données sont centralisées dans un serveur OPC

et mises à disposition vers différents clients OPC, l’ensemble permettant de suivre “en ligne”, un certain nombre de contenus de variables (Items

). Les choix proposés feront également l’objet d’une réflexion à mener avec les étudiants sur les points suivants : stabilité de Windows, du pack Office, robustesse de la solution, sécurité…

Une consultation des variables avec des objets portables (tablette et Smartphone) est également possible et présentée.

3.1 Détail de l’application globale dans une démarche SCADA

L'environnement architectural de travail lié à l'application d'automatisation du processus est présenté Fig. 9. Le processus est piloté par une partie commande sur laquelle est implantée une application répondant par exemple, à une recette de

14

SCADA: Supervisory Control and Data Acquisition. L’objectif d’un environnement SCADA est de mener une conduite réactive d’un processus.

Un environnement SCADA comprend 3 sous- ensembles : la fonction commande, la fonction surveillance et la fonction supervision.

15

CIM: Computer Integrated Manufacturing

16

OPC : [14] OPCFOUNDATION.,

https://opcfoundation.org/. : OPC est similaire à DDE (Dynamic Data Exchange) dans l'objectif de faire communiquer de façon transparente différents systèmes ou applications. Dans ses performances,

fabrication. Un certain nombre de logiciels doivent être installés sur l’ordinateur qui sera relié au réseau LAN

du département de formation (Fig. 9). Le client n°1 (ou les clients n°1) sont des pupitres opérateurs interconnectés, capables de contrôler et de visualiser les différents états liés au processus. C'est un client qui existe dans de nombreuses applications industrielles. Le client n°2 offre la possibilité d’interagir sur le système avec un pupitre opérateur préalablement choisi à partir d'un navigateur Internet. Les précautions en matière de sécurité des échanges devront être respectées… Le client n°3 est un environnement logiciel fourni par le constructeur Siemens (OPC Scout) capable d'offrir différents services OPC. Le client n°4 est une solution tierce offrant de nombreux services pour d'autres clients (solutions logicielles). Comme le montre la Fig. 9, le client n°5 (Excel) permettra de développer au fil de l'eau, des tableaux de bord, des histogrammes, des calculs statistiques… sur des données terrain que nous souhaitons surveiller. Le client n°6 offrira des services automatiques de messagerie au fil de l'eau sur des données terrain que nous souhaitons également surveiller. Enfin, le client n°7 (MATLAB) est un environnement bien connu en R&D.

MATLAB est un environnement puissant destiné aux calculs scientifiques et aux simulations. Il apporte aux ingénieurs, chercheurs et à tout scientifique une solution intégrant calcul numérique et

OPC surclasse de loin DDE (contrôle de la qualité des échanges, gestion des erreurs de communication…) qui n'a jamais connu de véritable essor dans le monde industriel. De plus, OPC permet de gérer de façon simple des architectures réseau

"Client-Serveur" grâce à des mécanismes natifs dans Windows 95/98/NT : OLE (Object Linking and Embedding), COM (Component Objet Model), DCOM (Distributed Component Objet Model).

17

Item : désignation d’un objet associé à une variable à déclarer permettant d’être traitée par le serveur OPC et les clients potentiels.

18

LAN : Local Area Network

7 visualisation. Il peut également s'interfacer avec des solutions Hardware (microcontrôleur…). Il dispose de plusieurs centaines (voire milliers), selon les versions et les modules optionnels autour du noyau

Matlab de fonctions mathématiques, scientifiques et techniques appelées

“Toolbox”. Dans notre cas, il sera utilisé pour visualiser des données du processus à l’aide de la Toolbox OPC.

Fig. 9 : Mise en place de différents clients

3.1.1 Verrous logiciels

La société Siemens a lancé une nouvelle plateforme de programmation avec ses nouvelles gammes de produits. La plateforme Totally Integrated Automation Portal (TIA Portal) est le nouvel environnement de travail qui permet de mettre en œuvre des solutions d’automatisation avec un système d’ingénierie intégré. Cet environnement qui répond à la norme IEC 61131-3 intègre notamment, la configuration et la gestion des réseaux de communication, la configuration et la gestion des fonctions Safety

, la configuration et la gestion d'axes numériques (motion control), la configuration et la programmation des API,

19

Fonction de sécurité active sur un processus

la configuration et la programmation des pupitres opérateurs, les services Internet…

L'ensemble des tests effectués ont été menés

avec la version V14-SP2 (soit sous

Windows 7-Pro (64 bits) soit sous Windows

10). La Fig. 9 montre que nous avons

souhaité valider différents services que

propose le nouveau standard OPC : OPC

UA. Les dernières spécifications d’OPC

UA (Unified Architecture) viennent d'être

validées. Avec cette nouvelle version, OPC

UA devrait réussir à unifier les échanges au

niveau des systèmes industriels là où la

version Industrielle d’Ethernet n’a pas

réussi (Fig. 11). Ce standard (OPC) des

réseaux informatiques locaux aurait pu

servir de base à une déclinaison Industrielle,

8 temps réel, fiable et sécurisée, mais malheureusement les différents fournisseurs de solutions industrielles n’auront pas réussi à s’entendre sur un standard commun. La Fig. 10 illustre les parts de marché de chaque déclinaison de ces Ethernets Industriels.

Fig. 10 : Part de marché des réseaux industriels en 2016 [6].

La plupart de ces déclinaisons d’Ethernet Industriel ont été développées sur la base d’un réseau de terrain existant chez le constructeur Profinet depuis Profibus (Siemens), Modbus TCP depuis Modbus (Schneider- Electric), Ethernet/IP depuis DeviceNet ou ControlNet (Rockwell Automation), ou développées comme Ethercat qui tire le meilleur parti du support Ethernet (exploitation maximale de la bande passante).

Cette unification des échanges n’ayant pu se faire au niveau matériel, OPC UA offre l’opportunité de le faire au niveau logiciel.

Le standard OPC, apparu dans les années 90, permettait les échanges entre les systèmes automatisés et les outils de supervision basés sur des ordinateurs personnels (PC). La contrainte forte était de s’appuyer sur le protocole propriétaire de Microsoft DCOM

. OPC UA est ouvert, indépendant de la plateforme, pour toutes

20

Distributed Component Object Model. DCOM est une technique propriétaire de Microsoft qui permet

les applications et pour toutes les connexions. Il va ainsi permettre les communications entre tous les éléments des différentes couches de la pyramide CIM, depuis un composant (par exemple : un actionneur) jusqu’au niveau d’un ERP

(Fig. 8, Fig. 11). Il peut être intégré aussi bien dans un puissant serveur d’entreprise que dans un petit objet connecté (IoT). La structure d’OPC UA a été spécifiée en plusieurs parties. Par exemple :

• Partie 1 - OPC UA Concepts : applicables au serveur et client OPC UA,

• Partie 2 - OPC UA Security Model : modèle pour sécuriser les échanges,

• Partie 3 - OPC UA Address Space Model : définition de l’organisation des objets. Le modèle orienté objet a été utilisé.

• …

Différents serveurs OPC peuvent être déployés et utilisés afin de répondre aux exigences du sujet présenté dans cet article (CODRA Composer, OPC Server, Matrikon OPC, Resolvica OPC, SV OPC...). Pour cela, le lecteur pourra se référer à l'article [22]. Nous avons fait le choix d'utiliser deux solutions. Une première solution (OPC Scout) mise à disposition par le constructeur Siemens et une deuxième solution (solution tierce : Cogent Data V8-2017) qui offre une plateforme de services très variés, associés à différents standards (Modbus, DDE, TCP, ODBC, HTTP, XML…). L'ensemble des navigateurs Internet actuels sont utilisables (client n°2). Pour Excel, nous avons utilisé le pack Office 365 (client n°5). La version 45.8.0 de Thunderbird a été utilisée pour l'application de messagerie (client n°6). Le client n°7 utilise la version de Matlab R2016a avec la toolbox OPC.

la communication entre des composants logiciels distribués au sein d'un réseau informatique.

21

Enterprise Resource Planning

9

Fig. 11 : OPC UA convient à toutes les plateformes [20].

3.1.2 Création de l’application hébergée dans l’API (cerveau du processus)

L’application gérant le processus est développée avec l’environnement de programmation TIA Portal V14-SP2. Cette application n’a pas vocation à gérer un processus complexe et un grand volume de variables. Sa vocation est de présenter la faisabilité du dispositif. Néanmoins, elle doit permettre d'intégrer des concepts communément utilisés dans une application industrielle : gestion d'entrées-sorties Tout ou Rien (TOR) et analogiques, gestion des modes de marche et d'arrêt, gestion de recettes, signalisation, affichage… (Fig.

12).

Fig. 12 : Fonctionnalité du programme hébergé dans l'API

L'API utilisé (CPU 1512C-1 PN : Fig.

13) s'insère dans de très nombreuses applications : machines spéciales, machines

textiles, machines d'emballage, fabrication de machines-outils, industrie électronique et artisanat électronique, automobile, environnement, agro-alimentaire …

Fig. 13 : Fonctionnalités principales de l'API utilisé

4. RESULTATS 4.1 Client n°1

Le client n°1 est un client classique que l’on retrouve sur de très nombreuses applications industrielles. Ce pupitre (KTP700) fonctionne avec un écran tactile et bonne définition graphique. Il est géré par un système d’exploitation dit

“propriétaire”. Le développement de l’application hébergée en son sein s’effectue avec l’environnement logiciel TIA PORTAL (Fig. 9). L’application fait appel aux différentes variables partagées (Fig. 7) que nous pouvons associer à des objets graphiques, des champs numériques, des graphes…

4.2 Client n°2

L’accès à un poste de conduite sur site peut être réalisé de deux manières différentes. Le contrôle-commande de grandes machines et d’installations disséminées se simplifie alors grâce à la possibilité de configurer avec le service SmartClient des postes de conduite répartis autorisant un contrôle-commande à partir de divers points. Dans ces conditions, l’opérateur obtient la même vue sur chaque poste, dont un seul peut être utilisé en conduite du système à un moment donné.

On parle alors de contrôle-commande

coordonné car la communication est de type

10 full duplex entre un pupitre opérateur et le client n°2 ou n°2 BIS (Fig. 14).

Fig. 14 : Mise en œuvre d’un contrôle-commande délocalisé

Le service SmartClient doit être déclaré dans le projet sous TIA PORTAL comme étant actif pour les pupitres concernés. Ce service implique la gestion des accès sécurisés à partir d’un navigateur Internet.

Pour intercepter un pupitre opérateur à partir du client n°2 BIS, il faut gérer l’administration du franchissement du firewall avec une redirection vers l’adresse IP du pupitre concerné. Avec cette stratégie, il est possible de commander le pupitre opérateur comme si l’utilisateur était sur place, à la seule différence que les touches ne sont pas actionnables directement sur le matériel, mais avec la souris. Pour s’affranchir également des différents soucis de mises à jour que l’on peut rencontrer dans un navigateur Internet utilisant des ressources java, le constructeur Siemens propose un logiciel qui apporte les mêmes services qu’un navigateur Internet (Fig. 15).

La Fig. 15 (a) présente les paramètres qui doivent être renseignés afin de pouvoir accéder au pupitre concerné. Dans notre cas, c’est l’adresse 10.0.2.67 (Fig. 14).

L’accès à l’application est alors possible

après validation d’un mot de passe Fig. 15 (b).

Fig. 15 : Le service SmartClient à partir d’un client n°2 ou n°2 BIS

Le mot de passe renseigné Fig. 15 (b)

doit être inséré au préalable, dans le système

d’exploitation du pupitre. Ce point

11 particulier renvoie le lecteur vers de la littérature qui présente les notions de mot de passe dits “faibles”, “moyens”, “forts” [4], [17].

La Fig. 16 (a) et (b) présente des écrans consultables et contrôlables par l’opératrice distante. Deux recettes de fabrication ont été validées avec la visualisation au fil de l’eau de la vitesse de rotation du moteur électrique concerné (recette de fabrication /

Fig. 12). Fig. 16 : Interception de l’application du pupitre à partir d’un client n°2 ou n°2 BIS

4.3 Client n°3

Afin de pouvoir vérifier que les données (nommées “Items” dans le monde OPC) sont disponibles pour les différents clients, il est nécessaire d’utiliser dans un premier temps, un outil capable de visualiser à la fois, le point de connexion au serveur OPC UA et l’ensemble des données qu’il récupère. OPC Scout est capable de vérifier l’ensemble des fonctionnalités du système de communication à partir de l’adresse : opc.tcp://10.0.2.60 :4840 (Fig. 9, Fig. 17).

Fig. 17 : Connexion au serveur OPC UA de l’API (opc.tcp://10.0.2.60 :4840)

OPC UA est capable de gérer l’authentification et l’autorisation de son

utilisation par différents utilisateurs. Pour

établir une connexion, l’utilisateur peut

12 s’identifier par : un certificat X.509

(Fig.

18), un nom d’utilisateur / mot de passe ou Kerberos

[7], [12].

Fig. 18 : Gestion d’un certificat suivi X.509 [2]

Cette gestion peut être configurée dans les paramètres de l’API (Fig. 19). Dans nos tests, nous n’avons pas adopté de gestion de certificat.

Fig. 19 : Gestion d’un certificat

La connexion au serveur

(opc.tcp://10.0.2.60 :4840) permet d’intercepter l’API (PLC_1) et de pouvoir choisir les données que l’on souhaite contrôler en ligne (Fig. 20, Fig. 21, Fig. 22).

Fig. 20 : Connexion au serveur OPC UA de l’API (PLC_1)

22

X.509 est une norme spécifiant les formats pour les certificats à clé publique, les listes de révocation de certificat, les attributs de certificat, et un algorithme de validation du chemin de certification, définie par l'Union internationale des télécommunications.

23

Kerberos est un protocole d'authentification réseau

qui repose sur un mécanisme de clés secrètes

(chiffrement symétrique) et l'utilisation de tickets, et

non de mots de passe en clair, évitant ainsi le risque

d'interception frauduleuse des mots de passe des

utilisateurs.

13

Fig. 21 : Connexion au serveur OPC UA de l’API (PLC_1)

La Fig. 22 présente les résultats d’un monitoring de données (entrées / sorties Tout Ou Rien sur le système : Bouton_Poussoir_xx, Commutateur_xx, Voyant_Vert, Entrée_Analogique_xx, Sortie_Analogique_xx,

gestion des recettes sur le système). Ces premiers résultats montrent qu’il est possible de connecter par la suite, d’autres clients (Fig. 9).

Fig. 22 : Monitoring des data du serveur OPC UA

4.4 Client n°4

Historiquement, OPC est le service de choix dans un environnement de contrôle- commande de processus et de reporting.

Comme nous l’avons déjà présenté, il existe un grand nombre de serveurs OPC permettant de disposer d’une connectivité avec différents API, PC industriels… Très souvent, les fabricants de matériel d’automation proposent une suite logicielle

OPC compatible avec leur gamme de

produits. Cela permet ensuite aux éditeurs

de logiciels de supervision de créer des

applications “client OPC” pour accéder

facilement à des données en temps réel

provenant d’un processus de fabrication,

d’un système, d’une machine… Avec OPC

UA il n’y a plus de rattachement obligatoire

avec une suite logicielle rattachée au

fabricant de matériel. Dans cette nouvelle

orientation logicielle, l’éditeur Cogent

14 Real-Times Systems [9] propose une suite logicielle permettant de disposer de très nombreux services (Fig. 23).

Fig. 23 : Cogent DataHub avec OPC UA

L’ensemble de ces services ne sera pas développé dans cet article. Nous développerons notre travail sur deux points préalablement exprimés : Client n°5 et Client n°6 (Fig. 9). Comme nous l’avons montré préalablement avec le client n°3, l’ensemble des data est disponible. Afin de pouvoir travailler avec les clients n°5 et n°6, il faut préalablement effectuer un certain nombre de paramétrages dans Cogent DataHub.

Fig. 24 : Cogent DataHub paramétrages

Cet environnement logiciel permet de se connecter à différents standards OPC : OPC UA, OPC DA, OPC A&E. Dans le cadre de notre application la connexion au serveur doit se faire au point : opc.tcp://10.0.2.60 :4840 (Fig. 24 (A)). Comme le montre la Fig. 24 (B), différents paramètres sont nécessaires au bon fonctionnement de la session. Le lecteur pourra pour plus de détails se référer à [5]. Une vérification des différents paramètres doit être menée afin de valider la session engagée Fig. 24 (C). La partie Connection Test montre que la

connexion est correctement paramétrée Fig.

24 (C). La Fig. 24 (D) permet d’appeler une

fenêtre afin de choisir les data que l’on

souhaite suivre (Fig. 25). Dans ces

conditions, les résultats présentés dans la

Fig. 25 montrent que l’API est bien visible

(A) avec l’ensemble de ces variables qui

pourront être manipulées (B).

15

Fig. 25 : Cogent DataHub paramétrages

4.5 Client n°5

Le client n°5 permet de pouvoir développer des interfaces Homme-Machine avec un suivi en ligne de la production.

Cette démarche peut s’inscrire dans un plan d’action de mise en place de briques logicielles dans un dispositif de type ERP

. Dans notre cas, nous avons choisi Excel dans la pack Office 365. L’environnement Open Office est également compatible. Le principe de base est dans un premier temps très simple, puisqu’il suffit de glisser et déposer les différentes variables dans les cellules concernées d’un tableau (Fig. 26).

Il faudra par la suite écrire quelques scripts (Macro) pour permettre des mises en forme de graphes par exemple, en respectant des critères d’échantillonnage des mesures. Ces critères dépendront du contexte de la production associés aux différentes constantes de temps du processus que l’on souhaite surveiller.

24

Enterprise Ressource Planning

Fig. 26 : Associer une variable Cogent DataHub avec une cellule du client n°5

Une mise en forme possible avec des résultats récupérés lors d’un test est proposée dans la Fig. 27 ((A) et (B)). Le responsable de la ligne de production peut alors, élaborer un contrôle-commande optimal du fonctionnement, traiter des statistiques, optimiser le TRS

…

Fig. 27 : Résultats disponibles dans le client n°5 sur la campagne de mesures

25

Taux de Rendement Synthétique

16 4.6 Client n°6

Cogent DataHub permet également d'envoyer des courriels et des messages textes, déclenchés par un événement tel qu'un changement de valeur sur une mesure ou par un déclenchement temporel (Fig.

28). Les courriels et les messages associés peuvent être édités en texte brut. Ils peuvent contenir des valeurs courantes issues du processus de fabrication de ligne de production.

Fig. 28 : Service de messagerie implémenté dans l'environnement Cogent DataHub

Avant de pouvoir envoyer un courriel, il est nécessaire de respecter certains paramètres. Ce travail doit être mené en collaboration avec la personne en charge de l’administration du réseau digital de l’entreprise. En effet, il faut respecter les différentes préconisations en matière de routage d’adresse IP, de sécurité et d’autorisation de franchissement du firewall. Dans notre cas il faut intervenir sur l’administration du firewall (PIX 515 de la Fig. 4). Dans notre cas, les règles établies sont les suivantes (se référer à la Fig. 9 pour identifier l’adresse IP : 10.0.2.90) :

# Declaration des objets locaux

Poste_115_AUTOMATE_PV_GEII =

"10.0.2.90"

nat18 = "194.167.26.18" # Nat pour adresse plublic envoi de mail via smtp.univ- orleans.fr

# NAT

match out log on $if_out from

$Poste_115_AUTOMATE_PV_GEII to any nat-to $nat18 label "nat-automate-115- PV-GEII" #115 AUTOMATE PV GEII

# LAN>EXT

pass log quick proto {tcp,udp} from

$Poste_115_AUTOMATE_PV_GEII to any port [1]

# EXT->LAN

pass log quick proto {tcp,udp} from any to

$Poste_115_AUTOMATE_PV_GEII # pour prise en main à distance

# Vérifier les règles : pfctl -nf /etc/pf.conf.local

# Charge les règles : pfctl -f /etc/pf.conf.local

Afin de pouvoir configurer l’envoi de

messages par l’intermédiaire du client n°4,

il est au préalable, nécessaire de de valider

cette fonction par l’intermédiaire d’un

script sous l’environnement Windows

PowerShell (Fig. 29 (A)). La Fig. 29 (B)

montre que l’envoi du message est bien

effectué après l’exécution du script (pas de

message d’erreur). Le message arrive par la

suite dans la boite mail concernée Fig. 29

(C).

17

Fig. 29 : Script de validation d’envoi d’un mail et réception d’un mail

La Fig. 30 décrit les différents réglages qu’il faut adopter afin de pouvoir émettre des messages relevant du fonctionnement du système (gestion des recettes, alarmes…). La Fig. 30 (A) précise le serveur SMTP, le Port et l’expéditeur du mail. La Fig. 30 (B) présente la variable que l’on souhaite suivre avec un message associé (Subject). La Fig. 30 (C) montre les différentes conditions pouvant être paramétrées afin de valider l’envoi du message associé à une variable.

Fig. 30 : Configuration du client n°4 pour l’envoi de mail

La Fig. 31 présente les résultats obtenus

pour deux messages différents associés à

deux recettes de fabrication. Le nom de la

recette est désigné dans le “Sujet”, sa

validité est précisée par la valeur 1 (corps

du message).

18

Fig. 31 : Réception de mail pour 2 recettes

4.7 Client n°7

La Toolbox OPC de Matlab (R2016a) permet de fournir une connexion aux serveurs OPC DA

, OPC HDA

et OPC UA. Cette connexion permet de lire, écrire et enregistrer des valeurs de data à partir de différents périphériques tels que, les systèmes de contrôle-commande distribués, les systèmes de surveillance et d'acquisition de données… Le client n°6 peut donc récupérer des informations issues de notre application. Il pourra également par la suite et si besoin, effectuer de nombreux traitements algorithmiques spécifiques déjà implémentés. La Fig. 33 présente les différentes lignes de commande que l’on doit adopter afin de vérifier et valider la configuration à adopter. On peut noter que le service passe bien par le client n°4 (Cogent DataHub). Il faudra respecter les quatre étapes préciser dans la Fig. 32 pour obtenir des premiers résultats probants.

Fig. 32 : Comment accéder à des data sous Matlab

26

DA : Data Access

Fig. 33 : Vérification des services sous Matlab

Il est possible de vérifier l’ensemble des paramètres lorsque la connexion est activée avec le serveur (Fig. 34).

Fig. 34 : Vérification des différents paramètres

Comme le montre la Fig. 32, il faut ensuite parcourir l’espace des noms des data du serveur OPC UA et les choisir (Fig. 35 (A)). Une ligne de commande ((Fig. 35 (B)) les fera apparaitre dans la fenêtre de travail.

Nous avons choisi pour ce test, trois entrées (Bouton_Poussoir_x) de type Tout Ou Rien et une sortie analogique (image de la consigne de vitesse pour les différentes recettes de fabrication). La Fig. 36 présente deux résultats pour deux essais différents.

La Fig. 36 (A) montre que les trois premières valeurs sont nulles [ 0] sauf la quatrième [ 1]. Cette valeur concerne l’état du Bouton_Poussoir_Rouge. Cette entrée stoppe le fonctionnement de la ligne de production et donc l’injection de toutes consignes de vitesses. La Fig. 36 (B) montre que l’image de la consigne de vitesse est

27

HDA : Historical Data Access

19 fixée à (16500) et confirme bien que le système n’est pas en arrêt.

Fig. 35 : Espace des noms des datas dans le serveur

Fig. 36 : Résultats sur la campagne de test

Ces derniers essais nous permettent une ouverture de travail vers d’autres horizons en matière de travaux scientifiques appliqués au diagnostic et au pronostic pour les processus ou les systèmes. En effet, la mesure et l’enregistrement de données sont les points de départ incontournables avant toutes modélisations.

5. CONCLUSION

Nous avons détaillé dans cet article de nombreux outils capables de répondre à des besoins très différents et complémentaires dans la mise en œuvre de solutions numériques pour les processus industriels ou tertiaires. Nous avons montré qu’il était nécessaire de débloquer plusieurs verrous matériels et logiciels pour la bonne tenue des résultats attendus. Cet article pourra inspirer de nombreux spécialistes du domaine en matière de mise en œuvre de solutions de reporting.

De ces différents essais et présentations nous pouvons également relever quatre points majeurs :

 L’Industrie du Futur, c’est déjà aujourd’hui ! Le numérique est présent dans tous les secteurs de l’industrie, des services, du médical, de la chimie, de la biologie. Depuis mai 2015, 1500 PME et ETI sont engagées dans cette dynamique de l’Industrie du Futur. Les technologies numériques font maintenant partie du quotidien de tous et sont accessibles plus ou moins aisément. Les Smartphones et les ordinateurs portables illustrent quotidiennement cette évidence. Ces technologies du numérique modifient profondément les usages qui semblent sans limites hormis, celles de l’imagination et du pouvoir d’inventivité des nouveaux acteurs ! De grandes fédérations et groupes professionnels [8]

ont déjà mis en place des programmes en

vue d’informer, de promouvoir,

d’accompagner et d’aider leurs adhérents

à prendre le virage du numérique ;

notamment au travers de salons, de

conférences, de diverses manifestations et

projets sur ces sujets. Les évolutions sont

de plus en plus rapides et profondes, elles

sont incontournables. Les entreprises qui

ont réussie face à ces enjeux ont su créer

les conditions d’agilité, de réactivité et de

renouvellement de leurs modes

opératoires afin de se centrer sur leurs

véritables enjeux industriels et

économiques. Elles ont su développer des

environnements favorables à leur

20 croissance. La réussite de ce mouvement engendré par l’Industrie du Futur est directement liée à la qualité des compétences humaines qu’elles soient celles des directions d’entreprises, du personnel en général sans oublier, les responsables économiques et politiques nationaux et régionaux (Fig. 37).

Fig. 37 : Evolution des révolutions industrielles à horizon 2020

 Notre pays a des atouts qui tiennent pour beaucoup à la qualité reconnue de nos personnels, à sa culture et son histoire industrielle riche ; cependant malgré notre retard dans certains domaines nous sommes à même de définir notre propre modèle original de développement (voir le succès et la créativité de nos “petites pousses - startup” dans les objets connectés notamment).

 Certes ne sous-estimons pas cependant les craintes et résistances légitimes qu’expriment certains dirigeants comme d’autres acteurs sociaux qui ne savent pas encore comment se projeter dans ce nouveau paradigme.

 Par contre, cette réalité digitale n’est pas suffisamment connue du grand public et l’image de l’industrie pâtie toujours des clichés relevant de la révolution industrielle du XIX siècle. Combien de parents ont déjà vu des Fab Lab ? Combien de citoyens connaissent des applications numériques dans le domaine de l’écologie, de l’optimisation des ressources naturelles, de l’optimisation des processus de fabrication ? La nouvelle génération d’individus a une vision beaucoup plus positive de l’avenir industriel, faisant en sorte qu’elle l’envisage dans notre pays

tout en se familiarisant avec les autres cultures.

Remerciements

Cet article et ces travaux ont pu être menés à bien grâce à un financement de matériels et de logiciels par le CFA des Universités Centre-Val de Loire.

6. REFERENCES

[1] N. E. 1325-1, Vocabulaire du management de la valeur, de l'analyse de la valeur et de l'analyse fonctionnelle - Partie 1 : analyse de la valeur et analyse fonctionnelle, 1996.

[2] R. ARMSTRONG and PAUL HUNKAR, The OPC UA Security Model For Administrators, (7 July, 2010), pp.

1-32.

[3] J.-P. CHEMLA and B. RIERA, Programmation objet pour une domotique réalisée avec un API, Actes du 10ème Colloque sur l’Enseignement des Technologies et des Sciences de l’Information et des Systèmes (CESTIS- EEA’13), Caen, 2013, pp. 78-80.

[4] CNIL, Les conseils de la CNIL pour un bon mot de passe 27 janvier 2017.

[5] COGENT REAL-TIME SYSTEMS, Cogent DataHub Documentation, Version 8.0, 2016.

[6] P. COUTANCE, réseaux industriels : forte poussée d'ethernet et du sans fil, Mesures (20 mars 2017).

[7] R. HENSSEN and M. SCHLEIPEN, Interoperability between OPC UA and AutomationML, Procedia CIRP, 25 (2014), pp. 297-304.

[8] http://allianceindustrie.wixsite.com/

[9] https://cogentdatahub.com/

[10] J. DEPREZ, J.L. BIANCHI, J.

MAILLEFERT and A. JUTON., Bus de

terrain et supervision, Société de

l'électricité, de l'électronique et des

technologies de l'information et de la

communication, 3EI 2010-60, n°60,

2010.

21 [11] M. BLANCHET and R. BERGERRIED.,

Industrie 4.0 - Les leviers de la transformation, Gimélec (2014), pp. 8- 11.

[12] W. MAHNKE, S.-H. LEITNER and M.

DAMM, OPC unified architecture, Springer Science & Business Media, 2009.

[13] MESURES., Communications radio : les industriels misent sur le sans fil, mesures, 805 (2008), pp. 27-40.

[14] https://opcfoundation.org/.

[15] P. VRIGNAT, M. AVILA, F.

DUCULTY, S. BEGOT and J.F.

MILLET., Utilisation d’une architecture logicielle dans le cadre d’une mise en place d’une solution multi-clients via un serveur OPC, Gesi n°77, Revue des Départements : Génie Electrique et Informatique Industrielle en IUT, 2012.

[16] PAC, L'IOT dans l'Industrie en France, in Whitepaper, ed., CXP Group is the #1 independent European research and advisory firm, 2016.

[17] PEQUIN L., Politique de gestion des mots de passe, Centre de Ressources Informatique, Université de la Réunion, 2010.

[18] D. F. PORTAIL DE L'ÉCONOMIE, DE L'ACTION ET DES COMPTES PUBLICS,, La nouvelle france industrielle - Présentation des feuilles de route des 34 plans de la nouvelle France industrielle, Ministère de l'Économie, des

Finances,de l'Action et des Comptes publics, 2016.

[19] L. SIEGFRIED, Industrie 4.0–L’usine connectée-Executive summary, Gimélec, 2013.

[20] SOGETI, Unifier sa communication industrielle avec OPC UA, Une solution

« Plug & Play » pour optimiser l’interopérabilité de vos systèmes industriels, 2016.

[21] TEAM HENRI-FABRE, Industrie du futur : Ses briques technologiques, Déploiement dans les processus, Cas particulier de l’IoT, Projets développés par TEAM, Technologies & Expertise in Advanced Manufacturing, 2016.

[22] P. VRIGNAT, F. DUCULTY, M.

AVILA, S. BEGOT, T. AGGAB, J.-F.

MILLET, D. DELOUCHE and F.

KRATZ, Développement et utilisation d’applications complémentaires dans une approche SCADA avec une solution communicante Bluetooth, J3eA, 15 (2016), pp. 0005.

[23] P. VRIGNAT, J.-F. MILLET, F.

DUCULTY, S. BEGOT and M. AVILA, Développement et utilisation d'applications complémentaires dans une approche SCADA: retour sur expérience avec des étudiants Bac+ 2 et Bac+ 5, CETSIS, Colloque sur l’Enseignement des Technologies et des Sciences de l’Information et des Systèmes, 11ème Edition, Besançon, France, (2014), pp.

76-81.