Un article rapide pour présenter une vidéo qui donne vie aux différents sujets que j'ai pu aborder dans mes précédents articles. Enjoy!
Affichage des articles dont le libellé est iiot. Afficher tous les articles
Affichage des articles dont le libellé est iiot. Afficher tous les articles
Connecter un automate à un serveur OPC/UA sous Linux
J'ai déjà présenté dans de précédents articles le couteau suisse de la connectivité OT/IT : KEPServerEX. Indispensable pour exposer les données d'une grande variété de machines via un serveur OPC/UA. Il est prévu pour fonctionner sous un environnement Windows.
Nous allons voir ici comment utiliser son pendant pour serveurs Linux : ThingWorx Kepware Edge.
Pour les besoins de cet article, nous utiliserons de nouveau notre PLC Siemens Logo! 8.
Contrairement à la version pour Windows, celle-ci ne dispose pas d'interface graphique. En revanche, elle expose une interface REST très complète et très bien documentée dans le ThingWorx Kepware Edge User Manual disponible en téléchargement. Elle est même autodocumentée, via des APIs spécifiques. Par exemple :
Définition des drivers/channels spécifiques
La requête suivante renvoie les éléments nécessaires à la création de channels dédiés au type de machine/équipement à connecter :
GET https://localhost:57513/config/v1/doc/drivers/Siemens%20TCP%2FIP%20Ethernet/channels
Réponse :
{
"type_definition": {
"name": "Channel",
"collection": "channels",
"namespace": "servermain",
"can_create": true,
"can_delete": true,
"can_modify": true,
"auto_generated": false,
"requires_driver": true,
"access_controlled": true,
"child_collections": [
"devices",
"phonebooks"
]
},
"property_definitions": [
{
"symbolic_name": "common.ALLTYPES_NAME",
"display_name": "Name",
"display_description": "Specify the identity of this object.",
"read_only": false,
"type": "String",
"default_value": null,
"minimum_length": 1,
"maximum_length": 256
},
{
"symbolic_name": "common.ALLTYPES_DESCRIPTION",
"display_name": "Description",
"display_description": "Provide a brief summary of this object or its use.",
"read_only": false,
"type": "String",
"default_value": null,
"minimum_length": 0,
"maximum_length": 255
},
{
"symbolic_name": "servermain.MULTIPLE_TYPES_DEVICE_DRIVER",
"display_name": "Driver",
"display_description": "",
"read_only": true,
"type": "String",
"default_value": "Siemens TCP/IP Ethernet",
"minimum_length": 0,
"maximum_length": -1
},
{
"symbolic_name": "servermain.CHANNEL_DIAGNOSTICS_CAPTURE",
"display_name": "Diagnostics Capture",
"display_description": "Select whether or not to make the channel's diagnostic information available to an OPC application.",
"read_only": false,
"type": "EnableDisable",
"default_value": false
},
{
"symbolic_name": "servermain.CHANNEL_UNIQUE_ID",
"display_name": "Unique Id",
"display_description": "Unique identifier associated with this object.",
"read_only": false,
"type": "Integer",
"default_value": 422613010,
"minimum_value": null,
"maximum_value": null
},
{
"symbolic_name": "servermain.CHANNEL_ETHERNET_COMMUNICATIONS_NETWORK_ADAPTER_STRING",
"display_name": "Network Adapter",
"display_description": "Specify the name of a network adapter to bind or allow the OS to select the default.",
"read_only": false,
"type": "StringWithBrowser",
"default_value": null,
"minimum_length": 0,
"maximum_length": -1,
"hints": [
"",
"wlp3s0",
"eno1"
]
},
...
]
}
Définition des devices
La requête suivante renvoie les éléments nécessaires à la création de devices dédiés au type de machine/équipement à connecter :
GET https://localhost:57513/config/v1/doc/drivers/Siemens%20TCP%2FIP%20Ethernet/devicesRéponse :
{
"type_definition": {
"name": "Device",
"collection": "devices",
"namespace": "servermain",
"can_create": true,
"can_delete": true,
"can_modify": true,
"auto_generated": false,
"requires_driver": true,
"access_controlled": true,
"child_collections": [
"services",
"tag_groups",
"tags"
]
},
"property_definitions": [
{
"symbolic_name": "common.ALLTYPES_NAME",
"display_name": "Name",
"display_description": "Specify the identity of this object.",
"read_only": false,
"type": "String",
"default_value": null,
"minimum_length": 1,
"maximum_length": 256
},
{
"symbolic_name": "common.ALLTYPES_DESCRIPTION",
"display_name": "Description",
"display_description": "Provide a brief summary of this object or its use.",
"read_only": false,
"type": "String",
"default_value": null,
"minimum_length": 0,
"maximum_length": 255
},
{
"symbolic_name": "servermain.MULTIPLE_TYPES_DEVICE_DRIVER",
"display_name": "Driver",
"display_description": "",
"read_only": true,
"type": "String",
"default_value": "Siemens TCP/IP Ethernet",
"minimum_length": 0,
"maximum_length": -1
},
{
"symbolic_name": "servermain.DEVICE_MODEL",
"display_name": "Model",
"display_description": "Select the specific type of device associated with this ID. Options depend on the type of communications in use.",
"read_only": false,
"type": "Enumeration",
"default_value": null,
"enumeration": {
"S7-200": 0,
"S7-300": 1,
"S7-400": 2,
"S7-1200": 3,
"S7-1500": 4,
"NetLink: S7-300": 5,
"NetLink: S7-400": 6
}
},
{
"symbolic_name": "servermain.DEVICE_UNIQUE_ID",
"display_name": "Unique Id",
"display_description": "Unique identifier associated with this object.",
"read_only": false,
"type": "Integer",
"default_value": 4145021575,
"minimum_value": null,
"maximum_value": null
},
{
"symbolic_name": "servermain.DEVICE_ID_FORMAT",
"display_name": "ID Format",
"display_description": "Indicate the format of the device ID (set by the driver by default).",
"read_only": false,
"type": "Enumeration",
"default_value": 0,
"enumeration": {
"Octal": 0,
"Decimal": 1,
"Hex": 2
}
},
...
]
}
Munissez-vous donc d'un client d'API comme Postman, d'un client OPC/UA comme UAExpert, et c'est parti!
Les endpoints
La documentation ThingWorx Kepware Edge Quick Start décrit les étapes nécessaires pour connecter un premier client UAExpert au serveur OPC/UA, via le endpoint créé par défaut par l'installation standard. Ce dernier est sécurisé et requiert une validation manuelle pour accepter la connexion du client au serveur.
Mais il est fréquent que le client qui sera utilisé dans une application (que vous découvrirez dans un prochain article ;) ne supporte pas ce mécanisme d'authentification. Il devient donc nécessaire de créer en premier lieu un nouveau endpoint "non sécurisé".
Ceci peut donc être fait via l'API REST de Kepware Edge :
POST https://localhost:57513/config/v1/admin/ua_endpointsBody :
{
"common.ALLTYPES_NAME": "UnsecureEndpoint",
"common.ALLTYPES_DESCRIPTION": "Available adapters: Default; wlp3s0:192.168.1.94; vboxnet0:192.168.56.1; eno1:; localhost",
"libadminsettings.UACONFIGMANAGER_ENDPOINT_ENABLE": true,
"libadminsettings.UACONFIGMANAGER_ENDPOINT_ADAPTER": "Default",
"libadminsettings.UACONFIGMANAGER_ENDPOINT_PORT": 49331,
"libadminsettings.UACONFIGMANAGER_ENDPOINT_URL": "opc.tcp://localhost:49331",
"libadminsettings.UACONFIGMANAGER_ENDPOINT_SECURITY_NONE": true,
"libadminsettings.UACONFIGMANAGER_ENDPOINT_SECURITY_BASIC128_RSA15": 0,
"libadminsettings.UACONFIGMANAGER_ENDPOINT_SECURITY_BASIC256": 0,
"libadminsettings.UACONFIGMANAGER_ENDPOINT_SECURITY_BASIC256_SHA256": 0
}
Il sera nécessaire de redémarrer le serveur pour prendre en compte cette modification. Ce nouveau endpoint apparaitra donc dans le client OPC/UA :
Le Channel
En s'appuyant sur la documentation récupérée plus haut, nous pouvons créer le channel spécifique à notre PLC Siemens :
POST https://localhost:57513/config/v1/project/channelsBody :
{
"common.ALLTYPES_NAME": "SiemensChannel",
"servermain.MULTIPLE_TYPES_DEVICE_DRIVER": "Siemens TCP/IP Ethernet",
"servermain.CHANNEL_DIAGNOSTICS_CAPTURE": false,
"servermain.CHANNEL_WRITE_OPTIMIZATIONS_METHOD": 2,
"servermain.CHANNEL_WRITE_OPTIMIZATIONS_DUTY_CYCLE": 10,
"servermain.CHANNEL_NON_NORMALIZED_FLOATING_POINT_HANDLING": 0,
"servermain.CHANNEL_ETHERNET_COMMUNICATIONS_NETWORK_ADAPTER_STRING":"wlp3s0"
}
Le Device
Nous pouvons maintenant associer à notre Channel un Device représentant notre Logo! 8 :
POST https://localhost:57513/config/v1/project/channels/SiemensChannel/devicesBody :
{
"common.ALLTYPES_NAME": "Logo8",
"servermain.DEVICE_ID_STRING": "192.168.1.13",
"servermain.MULTIPLE_TYPES_DEVICE_DRIVER": "Siemens TCP/IP Ethernet",
"servermain.DEVICE_MODEL": 0,
"servermain.DEVICE_ID_FORMAT": 0,
"servermain.DEVICE_ID_HEXADECIMAL": 0,
"servermain.DEVICE_ID_DECIMAL": 0,
"servermain.DEVICE_ID_OCTAL": 0,
"servermain.DEVICE_DATA_COLLECTION": true,
"servermain.DEVICE_SIMULATED": false,
"servermain.DEVICE_SCAN_MODE": 0,
"servermain.DEVICE_SCAN_MODE_RATE_MS": 1000,
"servermain.DEVICE_SCAN_MODE_PROVIDE_INITIAL_UPDATES_FROM_CACHE": false,
"servermain.DEVICE_CONNECTION_TIMEOUT_SECONDS": 3,
"servermain.DEVICE_REQUEST_TIMEOUT_MILLISECONDS": 2000,
"servermain.DEVICE_RETRY_ATTEMPTS": 2,
"servermain.DEVICE_INTER_REQUEST_DELAY_MILLISECONDS": 0,
"servermain.DEVICE_AUTO_DEMOTION_ENABLE_ON_COMMUNICATIONS_FAILURES": false,
"servermain.DEVICE_AUTO_DEMOTION_DEMOTE_AFTER_SUCCESSIVE_TIMEOUTS": 3,
"servermain.DEVICE_AUTO_DEMOTION_PERIOD_MS": 10000,
"servermain.DEVICE_AUTO_DEMOTION_DISCARD_WRITES": false,
"servermain.DEVICE_TAG_GENERATION_ON_STARTUP": 1,
"servermain.DEVICE_TAG_GENERATION_DUPLICATE_HANDLING": 0,
"servermain.DEVICE_TAG_GENERATION_GROUP": "",
"servermain.DEVICE_TAG_GENERATION_ALLOW_SUB_GROUPS": true,
"siemens_tcpip_ethernet.DEVICE_COMMUNICATIONS_PORT_NUMBER": 102,
"siemens_tcpip_ethernet.DEVICE_COMMUNICATIONS_MPI_ID": 0,
"siemens_tcpip_ethernet.DEVICE_S7_COMMUNICATIONS_MAX_PDU": 960,
"siemens_tcpip_ethernet.DEVICE_S7_COMMUNICATIONS_200_LOCAL_TSAP": 200,
"siemens_tcpip_ethernet.DEVICE_S7_COMMUNICATIONS_200_REMOTE_TSAP": 200,
"siemens_tcpip_ethernet.DEVICE_S7_COMMUNICATIONS_300_400_1200_1500_LINK_TYPE": 3,
"siemens_tcpip_ethernet.DEVICE_S7_COMMUNICATIONS_CPU_RACK": 0,
"siemens_tcpip_ethernet.DEVICE_S7_COMMUNICATIONS_CPU_SLOT": 2,
"siemens_tcpip_ethernet.DEVICE_ADDRESSING_BYTE_ORDER": 0,
"siemens_tcpip_ethernet.DEVICE_TAG_IMPORT_TYPE": 0,
"siemens_tcpip_ethernet.DEVICE_TAG_IMPORT_CODE_PAGE": 4294967295,
"siemens_tcpip_ethernet.DEVICE_TAG_IMPORT_STEP_7_PROJECT_FILE": "",
"siemens_tcpip_ethernet.DEVICE_TAG_IMPORT_PROGRAM_PATH": "",
"siemens_tcpip_ethernet.DEVICE_TAG_IMPORT_TIA_EXPORT_FILE": ""
}
Toutes ces informations correspondent à ce qui est demandé par l'assistant de configuration dans la version Windows.
Les Tags
Terminons par le plus important, exposer les informations de l'automate via les tags OPC/UA :
POST https://localhost:57513/config/v1/project/channels/SiemensChannel/devices/Logo8/tagsBody :
[
{
"common.ALLTYPES_NAME": "Entree1",
"servermain.TAG_ADDRESS": "I0.0",
"servermain.TAG_DATA_TYPE": 1,
"servermain.TAG_READ_WRITE_ACCESS": 1,
"servermain.TAG_SCAN_RATE_MILLISECONDS": 100,
"servermain.TAG_SCALING_TYPE": 0
},
{
"common.ALLTYPES_NAME": "EntreeReseau1",
"servermain.TAG_ADDRESS": "V0.0",
"servermain.TAG_DATA_TYPE": 1,
"servermain.TAG_READ_WRITE_ACCESS": 1,
"servermain.TAG_SCAN_RATE_MILLISECONDS": 100,
"servermain.TAG_SCALING_TYPE": 0
},
{
"common.ALLTYPES_NAME": "Output1",
"servermain.TAG_ADDRESS": "Q0.0",
"servermain.TAG_DATA_TYPE": 1,
"servermain.TAG_READ_WRITE_ACCESS": 1,
"servermain.TAG_SCAN_RATE_MILLISECONDS": 100,
"servermain.TAG_SCALING_TYPE": 0
}
]
Et voilà! Notre serveur est prêt à être utilisé :
Pour aller plus loin
Si vous avez besoin de configuration spécifique, avec des attributs particuliers, pour ne pas avoir à fouiller dans toute la documentation, il est possible d'exporter un projet déjà existant sous Kepware version Windows au format JSON : vous retrouverez ainsi tout le contenu nécessaire pour appeler les APIs REST!
Récupération des logs
Les logs du serveur, habituellement visibles sous Windows dans la console, peuvent être récupérés via cette interface :
GET https://localhost:57513/config/v1/event_logFichier(s) joint(s) :
Pilotez votre usine pour une production plus agile grâce au Edge computing
Pour faire suite à mon précédent article, où nous avions vu comment lier les réseaux IT et OT pour faire de la supervision (par exemple d'une chaine de production), il reste maintenant à voir comment agir sur les équipements connectés dans l'usine : envoyer des commandes, définir des programmes, déclencher des arrêts...
Pour simplifier la réalisation et ne pas interférer avec les réseaux de terrains spécifiques (Profinet, Profibus, AS-i...), nous allons interfacer le noeud "de plus haut niveau" en termes de réseaux OT : l'automate!
Voici en résumé ce qui peut être mis en place :
En quelques mots :
- La plateforme IoT Cumulocity Edge permet de planifier n'importe quel type d'opération à destination d'un équipement spécifique (marche/arrêt, changement de programme...)
- Une instance de Kepware Kepserver permet d'exposer les données et les actions possible sur un équipement (quel qu'il soit, même ancien et/ou propriétaire) via une interface OPC/UA
- Un "agent" permet de récupérer les opérations en attente sur la plateforme pour les interpréter en appels de méthodes OPC/UA, que Kepware traduira ensuite en langage automate
Le pilotage du parc machines grâce aux fonctions de device management
Pour commencer, les commandes à envoyer aux équipements sont décrites dans des "opérations" sur la plateforme IoT :
 |  |
Le principe est le suivant : l'opération est créée pour un équipement spécifique, au statut "En attente". L'équipement (ou un agent) va alors consulter régulièrement la plateforme pour savoir si une opération lui a été demandée. Le cas échéant, il la prendra en considération en la passant au statut "En cours d'exécution" et réalisera la tâche demandée. Une fois terminée, il passera l'opération au statut "Succès" ou "Echec" selon le résultat.
Un Agent pour orchestrer les opérations
Dans certains cas, l'intégration d'un agent spécifique pourra être nécessaire pour scruter le contenu de la plateforme IoT et piloter en conséquence les interfaces OPC/UA existantes.
Un des moyens les plus versatiles pour ce genre de besoin peut être un script en langage Python : il peut facilement s'intégrer avec les interfaces de la plateforme IoT et l'OPC/UA et peut être déployé sur n'importe quelle passerelle ou autre équipement réseau de ce type.
Vous voilà équipés pour interagir au mieux avec vos lignes de production!
Fichier(s) joint(s) :
Convergence des réseaux OT et IT en pratique : de l'automate à la plateforme IoT (sans Cloud!)
Après avoir traité le sujet du Edge computing dans mon précédent article, il est temps d'aborder un autre frein souvent recontré lors de la transformation numérique d'une unité de production : l'unification des réseaux industriels (OT) et applicatifs (IT).
L'automate comme noeud central
Les APIs (Automate programmable industriel) ou PLC en anglais (Programmable Logic Controller) sont depuis longtemps les "cerveaux" des usines, orchestrant les différents processus techniques. Depuis quelques années, les fabricants misent de plus en plus sur leur rôle central en les rendant de plus en plus intelligents et interconnectés.
 |
 |
Mais avant d'envisager le remplacer de tout le parc installé dans un site, il existe différents moyens permettant de faire remonter les informations d'un automate standard (même ancien) vers des applications du SI.
Cas d'usage
Le PoC réalisé ici repose sur un des automates les plus répandus dans l'industrie, à savoir un Siemens S7-200, décliné dans le modèle d'entrée de gamme le LOGO! 8. Plusieurs briques logicielles vont lui être adossées afin de récupérer les états de ses différentes entrées/sorties et les remonter vers la plateforme IoT Cumulocity Edge installée localement.
 |
 |
Kepware Kepserver comme porte d'entrée
Ce logiciel distribué par PTC est le véritable couteau suisse de l'industrie 4.0, car il permet de se connecter directement et nativement à un grand nombre d'automates puisqu'il contient tous les pilotes nécessaires :
Après configuration pour utiliser le pilote Siemens et reconnaissance des entrées/sorties, il expose automatiquement les données issues de l'automate via un serveur OPC/UA :
Cumulocity Edge et client OPC/UA
La version Edge de Cumulocity IoT embarque nativement un connecteur vers un serveur OPC/UA. Il suffit donc de le faire pointer vers le serveur exposé par Kepware pour récupérer les informations de l'automate :
Vous voici entrés dans la 4ème révolution industrielle!
Fichier(s) joint(s) :
IoT Edge computing pour la maintenance conditionnelle
La transformation vers l'"Industrie 4.0" implique de profonds changements pour les usines (organisationnels, technologiques...). Parmi eux, le concept de "Edge computing" fait partie des plus attendus et des plus complexes. Il découle du besoin grandissant d'analyser de plus en plus d'informations issues des machines, dans le contexte notamment de la maintenance conditionnelle, qui permet de connaitre en temps réel leur état pendant les phases de production.
Vers l’usine intelligente...
Le "Edge computing" a pour vocation d'apporter des capacités de calcul et de prise de décision au sein même de l'usine, au plus près des machines.
L'intérêt premier est de répondre aux problématiques de sécurité, vis-à-vis de la connectivité avec un Cloud : disposer d'une plateforme IoT fonctionnant entièrement en mode déconnecté permet de s'affranchir de toutes les difficultés d'ouvrir un réseau OT vers l'extérieur et ainsi limiter les risques de failles de sécurité.
Le second intérêt est de permettre l'analyse en temps réel de signaux complexes et volumineux, tels que des vibrations ou des rotations et ainsi accélérer la prise de décision. Plus besoin d'agréger ou préformatter les données avant de les envoyer vers un Cloud, ce qui réduit les efforts nécessaires et améliore la qualité des informations utilisées dans les analyses.
... utilisant l'expérience de l'Homme
Mais cette usine "agile" et "intelligente" ne serait rien sans le savoir et le savoir-faire des personnels de maintenance. Leur connaissance du parc de machines et leur expérience en détection de pannes sont les éléments clés qui doivent être utilisés et préservés tout au long du processus de transformation numérique.
Il est donc important que les nouveaux outils introduits au sein de l'usine soient au service de ces Hommes et leur permettent de garder la main sur leur métier, tout en valorisant leurs connaissances et en facilitant leur quotidien.
Par des industriels, pour des industriels
Brilliant things repose sur la plateforme Cumulocity IoT, de l'éditeur allemand SoftwareAG, plusieurs fois reconnue comme leader sur le marché par des organismes observateurs indépendants. Celle-ci apporte toutes les fonctionnalités d'une plateforme (dashboard, device management, droits d'accès, stockage, sécurité...) ainsi qu'une large palette de connecteurs vers des protocoles de communication industriels (OPC/UA, Modbus...) et des pilotes pour des machines de grands fabricants (DMG-MORI, Dürr, Engel...) développés par le consensus d’industriels ADAMOS.
De plus, sa version Edge décline toutes les fonctionnalités de la version SaaS dans un environnement pouvant être déployé localement, sur un serveur situé dans l'usine, sans nécessiter de connexion vers l'internet. Elle offre en supplément la présence du moteur de streaming analytics Apama, capable de recevoir et traiter d'importants flux d'évènements.
Plus de pouvoir pour la maintenance
Brilliant things est une solution destinée au personnel de maintenance : elle met à disposition une interface simple d'utilisation pour créer des corrélations d'évènements, afin de générer une information à haute valeur pour la maintenance, à partir d'évènements disparates reçus des différents équipements de l'usine.
Par exemple, en s'appuyant sur son expérience et sa connaissance du parc, l'utilisateur (typiquement un responsable de maintenance) pourra créer une corrélation d'évènements avancée du type : "Si, sur ma fraiseuse verticale, la vitesse de rotation de la broche dépasse 60.000 tours/min et que la température de l'outil atteint 85°C dans un intervalle de 30 secondes, pendant le programme TUENC5, alors déclencher une alarme !". En complément, d'autres règles de gestion dans la plateforme peuvent implémenter un scénario d'escalade (envoi de mail par ex) ou un workflow de traitement (déclencher une opération : arrêt machine...).
Une vision globale du parc
La première étape consiste à sélectionner l'ensemble des évènements qui seront utilisés pour créer la corrélation :
- Pour les machines en fonctionnement, peuvent être utilisés :
- Les évènements remontés en temps réel liés par exemple à une supervision conditionnelle : vitesses de rotation, température de fonctionnement, vibrations, qualité de l’huile...
- Les évènements liés à leurs opérations : temps de fonctionnement, programme courant, paramétrage...
- Les informations contextuelles liées à la maintenance : date de dernière révision, indicateurs (MTBF, MTTR...)
- Les évènements issus d'autres appareils connectés à la plateforme (autres que les machines) : détecteurs de fumée, capteurs d'hygrométrie ambiante, de luminosité...
- Des évènements spécifiques issus d'autres systèmes applicatifs du Système d’Information, par exemple venant d'un broker MQTT ou service web REST
L'expertise en jeu
Vient maintenant le temps de l'élaboration de la corrélation de tous ces évènements : fort de son expertise et de sa maitrise du parc de machines, l'utilisateur va pouvoir reconstituer les conditions précises liées au dysfonctionnement à observer. Quelle que soit la complexité des évènements ou leur source, cette interface claire permet de configurer la succession de contrôles à effectuer pour créer une information à forte valeur ajoutée pour la production.
Ainsi, tout le savoir du personnel de maintenance est mis en jeu pour devenir la pierre angulaire de ce système d'analyse, pour conduire à un ensemble performant et pertinent.
Maintenance conditionnelle intelligente
Dans certains contextes, la maintenance conditionnelle devient une source de bruit important, par le grand nombre de signaux et d'alarmes qui peuvent être émis (capteurs, actionneurs, voyants...) : il peut alors être difficile de donner un sens juste à tous ces signaux même avec une parfaite connaissance du parc et des processus. Ce qui peut parfois mener à des situations à risque lorsque la multitude d'informations est finalement ignorée car trop complexe à analyser dans les délais impartis.
C'est la raison pour laquelle il est important de pouvoir regrouper tous ces signaux et les analyser simultanément afin de lever des alertes plus pertinentes et plus efficaces, et ainsi réduire les risques de faux positifs ou d'éléments perturbateurs.
En résumé, Brilliant Things apporte une solution à la complexité montante de la maintenance conditionnelle, en la rendant accessible aux personnes qui en sont les premiers acteurs.
Fichier(s) joint(s) :
Connecter une machine industrielle à Cumulocity
Il est clair aujourd'hui que c'est l'Industrie qui va drainer le plus de marché (et d'innovation) dans le domaine de l'internet des objets. Pour s'inscrire dans cette mouvance, nous allons voir comment il est possible de connecter une machine industrielle à la plateforme IoT Cumulocity.
Le protocole OPC/UA
Il s'agit d'une extension du protocole OPC, standard de l'industrie permettant la communication entre machines, qui vise à simplifier leur intégration et leur utilisation en apportant notamment de la flexibilité, de la sécurité et de l'indépendance vis-à-vis des fabricants.
Rapide point d'architecture : avec OPC/UA, chaque machine est reliée à un serveur (souvent 1 machine = 1 serveur, installé en local). Ensuite, une passerelle permet d'interroger les données des serveurs ou envoyer des opérations :
Serveurs de démo
Pour tester les fonctionnalités d'OPC/UA, il est possible d'utiliser un serveur public, comme par ex ceux d'OPCLabs, ou d'installer son propre serveur local, comme ceux fournis par Unified Automation.
Client
Le client le plus pratique à utiliser pour des premiers tests est UaExpert d'OPCLabs téléchargeable ici. C'est lui que nous utiliserons pour notre démonstration.
Premier cas d'usage
Description
Pour les besoins de cet article, nous allons nous appuyer sur les données de démo contenues dans le serveur présenté plus haut, représentant une chaudière (boiler), simulée donc par le serveur. L'idée principale est qu'une nouvelle donnée et un nouvel évènement soient générés côté Cumulocity chaque fois que la température de notre chaudière change. Voici l'architecture mise en place pour créer le lien jusqu'à Cumulocity :
Le lien vers la plateforme est réalisé par un Agent (fourni par Cumulocity) déployé sur la passerelle. Pour le récupérer et le configurer, il suffit de suivre la documentation ici.
Configuration des Devices
Voici à quoi ressemble la configuration dans Cumulocity du Device correspondant à notre passerelle :
Comme vous pouvez le voir, il est lié à un autre Device, représentant le capteur de température. Voici sa configuration :
Comme vous le constatez, nous avons configuré ce Device pour émettre un Measurement et un Event à chaque changement de valeur. Nous aurions pu également lui dire de lever une Alarme. On retrouve également à chaque fois le "Browse Path" qui permet de naviguer (à la mode OPC/UA) jusqu'à la valeur à surveiller. Cette information peut se trouver grâce au client UaExpert, dans la vue Attributes, sous le nom de BrowseName :
Testons!
Maintenant que tout est configuré, il ne nous reste plus qu'à tester! Pour cela, il faut tout d'abord démarrer l'Agent Cumulocity (voir doc). Si tout a bien été préparé, il n'y aura pas d'erreur dans la console ni d'Alarme levée sur la plateforme.
Nous pouvons maintenant, à l'aide d'UaExpert, simuler un changement de température dans notre chaudière via l'appel à la méthode dédiée "Heat" :
Une fois la méthode invoquée, nous verrons apparaitre dans Cumulocity nos valeurs de température ainsi que nos évènements :
Hope this helps!
Fichier(s) joint(s) :
Inscription à :
Articles (Atom)
