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!
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) :
Créer un réseau LoRa et exploiter les données transmises
Nous allons voir ici comment contruire facilement votre propre réseau local LoRaWAN.
Le matériel
Avant de commencer, il est nécessaire de s'équiper d'un ou plusieurs devices constituant les noeuds finaux (transmettant les données de capteurs) ainsi que d'une passerelle (gateway) pour la centralisation des messages. Pour plus de détails sur l'architecture LoRaWAN, vous pouvez voir ici.
Pour cet article, la plateforme qui recevra nos messages LoRa (le Network server) sera The Things Network (TTN) : gratuit, complet et simple d'utilisation.
A ce jour, le matériel le plus abordable (tant en prix qu'en complexité) sur le marché est fourni par Pycom : en premier lieu leur toute nouvelle passerelle Pygate, qui est très simple à prendre en main et peu chère. Elle est programmable en MicroPython et dispose d'une extension Ethernet/PoE. Pour ce qui est des noeuds et capteurs, un LoPy4 posé sur une carte d'extensions PySense répondra à la plupart des besoins.
Je passe sur les détails de l'assemblage des cartes, très bien expliqué sur leur site.
La programmation
Le développement en MicroPython et la programmation des cartes peut se faire assez simplement avec VSCode et l'extension Pymakr.
La passerelle
Avant même de commencer à programmer la Pygate, il est nécessaire de l'enregistrer auprès de la plateforme TTN afin de récupérer des indentifiants. Pour cela, il suffit de suivre les instructions ici.
Ensuite, sur le site de Pycom se trouve un très bon exemple de code permettant de programmer la passerelle pour se connecter à TTN via Wifi. Si vous êtes équipés du module Ethernet/PoE, il suffit de remplacer le code intialisant l'interface Wifi par celui-ci :
from network import ETH
eth = ETH()
while not eth.isconnected():
print("connecting to ethernet")
time.sleep(1)
print("ifconfig", eth.ifconfig())
Ainsi, une fois la gateway connectée à un réseau accédant à Internet, la communication s'établira toute seule et vous verrez remonter régulièrement des signaux de vie sur la page de TTN.
Les noeuds
Pour ce qui est du code nécessaire à l'activation d'un end device, il existe encore une fois un très bon exemple sur le site de Pycom. Comme expliqué, il vous sera nécessaire de créer une application dans TTN pour récupérer tous les identifiants utiles.
Afin de transmettre les données des capteurs d'un Pysense, tout est disponible sur cette page.
Le décodage des données
Sur TTN, le payload des messages est encodé en hexadécimal, sous forme d'octets. Mais la plaforme met à disposition, au sein des Applications, des moyens de décoder et manipuler les contenus afin de faciliter leur utilisation, et ce à partir de fonctions Javascript.
Le Decoder
Ces fonctions permettent de transformer le contenu brut (octets) en données lisibles.
Prenons le scénario suivant : le payload envoyé est constitué de données encodées selon un mécanisme personnalisé : 15 premiers bits pour une température, 7 bits suivants pour une humidité... Cette succession de bits est finalement encodée en hexa afin d'être transmise.
Voici un exemple de décodeur qui transforme le payload des messages LoRa en une chaine binaire :
function Decoder(bytes, port) {
function bytesToBinStr(bytes) {
var binstr = '';
for(var i=0; i<bytes.length; i++) {
var str = bytes[i].toString(2);
while(str.length<8){
str = '0'+str;
}
binstr += str;
}
return binstr;
}
}
Ensuite, selon notre scénario, une fonction permettant de reconstituer la température :
function parseForTemperature(binStr) {
var level = 0.0;
if (binStr.length >= 18) {
var entier = parseInt(binStr.substr(3, 7), 2);
var dec = parseInt(binStr.substr(10, 8), 2);
level = entier + (dec / 100);
if(binStr.substr(2, 1)=="1") {
level = level * -1;
}
}
return level;
}
Enfin, le code complet du Decoder permettant de retourner la température :
function Decoder(bytes, port) {
function bytesToBinStr(bytes) {
...
}
function parseForTemperature(binStr) {
...
}
// Decode an uplink message from a buffer
// (array) of bytes to an object of fields.
var decoded = {};
var binstr = bytesToBinStr(bytes);
decoded.temp = parseForTemperature(binstr);
return decoded;
}
Le Converter
Imaginons maintenant que nous souhaitions transmettre ces données à une plateforme tierce. Il est possible grâce aux convertisseurs de transformer les données décodées afin d'en adapter le format, pour être correctement interprétées par la plateforme cible (ceux qui me suivent reconnaitront Cumulocity ;). En voici un exemple :
function Converter(decoded, port) {
// Merge, split or otherwise
// mutate decoded fields.
var date = new Date().toISOString();
var tempMeasurement = {'c8y_TemperatureMeasurement':{'T':{'unit':'C','value':decoded.temp}}};
tempMeasurement.type = 'c8y_TemperatureMeasurement';
tempMeasurement.time = date;
tempMeasurement.source = {'id':'3466704'};
var converted = {'measurements':[tempMeasurement]};
return converted;
}
Ce qui, ici, produira au final un message de la forme :
{
"app_id": "pygate-test",
"dev_id": "pysense",
"hardware_serial": "...",
"port": 2,
"counter": 27,
"payload_raw": "CBHMmQFHhVM=",
"payload_fields": {
"measurements": [
{
"c8y_TemperatureMeasurement": {
"T": {
"unit": "C",
"value": 32.71
}
},
"source": {
"id": "3466704"
},
"time": "2020-10-27T16:21:50.698Z",
"type": "c8y_TemperatureMeasurement"
}
]
},
"metadata": {
"time": "2020-10-27T16:21:50.491459008Z",
"frequency": 868.1,
"modulation": "LORA",
"data_rate": "SF7BW125",
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-...",
"timestamp": 2919800980,
"time": "",
"channel": 0,
"rssi": -25,
"snr": 10,
"rf_chain": 0
}
]
},
"downlink_url": "https://integrations.thethingsnetwork.org/ttn-eu/api/v2/down/.../integromat?key=..."
}
Vous avez maintenant tout ce qu'il vous faut pour monter votre propre réseau LoRa et faire voyager vos données!
Nous verrons dans un prochain article comment développer un microservice sur Cumulocity pour récupérer ces messages et en extraire les measurements utiles.
Fichier(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) :
Inscription à :
Articles (Atom)
