Interfaçage de capteurs industriels Modbus avec une passerelle IIoT open source

Les applications de l'Internet des objets industriel (IIoT) nécessitent généralement un passerelle de périphérie pour intégrer des périphériques Modbus et d'autres appareils, mais la mise en œuvre d'une passerelle peut être coûteuse et longue. Cet article propose une étude de cas sur l'interfaçage d'un capteur industriel avec un cadre informatique de pointe open source qui peut considérablement simplifier le déploiement.

La technologie de l'Internet des objets industriels (IIoT) se développe rapidement. Les applications IIoT dans le domaine de la surveillance à distance et de l'analyse avancée révolutionnent les entreprises et leur offrent des avantages exemplaires. L'edge computing se produit généralement directement sur les appareils auxquels les capteurs sont attachés ou sur un appareil passerelle physiquement proche des capteurs.

Dans les cas d'utilisation industrielle, où un certain nombre de capteurs doivent être interfacés avec des passerelles de périphérie, les architectes de solutions et les développeurs doivent décider de la conception et du développement du logiciel d'une passerelle de périphérie et de la manière de traiter les données de divers capteurs et d'effectuer des analyses de données pendant la conception et le développement. phase. Dans une telle situation, s'il n'y a pas de framework open source, le développement de nouveaux logiciels, les corrections de bogues peuvent nécessiter beaucoup d'efforts et de coûts.

Le premier article de cette série en deux parties décrit des capteurs industriels avec des cas d'utilisation et fournit un aperçu des exigences d'une passerelle Edge ainsi qu'une discussion sur la façon dont les exigences de passerelle Edge peuvent être satisfaites avec EdgeX Foundry, un cadre informatique Edge open source qui sert de Edge middleware entre la détection physique et l'actionnement des « choses » et un système de technologie de l'information (TI) (Figure 1).

Figure 1. Fonderie EdgeX (Source :www.edgexfoundry.org)

Cet article propose une étude de cas sur l'interfaçage d'un capteur industriel avec EdgeX pour obtenir une fonctionnalité d'informatique de pointe.

L'objectif de cette étude de cas est d'évaluer l'un des frameworks de edge computing appelé EdgeX Foundry fonctionnant sur une passerelle Raspberry Pi en interfaçant un capteur industriel de température et d'humidité. Voici le bloc de haut niveau et le diagramme de flux de données avec lequel l'étude de cas est expliquée :

cliquez pour l'image en taille réelle

Figure 2. Schéma fonctionnel de haut niveau (Source :www.edgexfoundry.org)

Modbus

Modbus est un protocole ouvert et les transports sont standard. Il ne nécessite pas de couche physique spécifique, contrairement à de nombreux protocoles propriétaires, les réseaux Modbus sont donc construits sur une infrastructure commune et bon marché telle que des liaisons RS-485.

Modbus implémente une représentation des données très simple et facile à comprendre. Son objectif principal est simplement de déplacer des données entre les appareils maîtres et esclaves Modbus. Il n'y a que deux types de données à déplacer, les registres et les bobines. Les registres sont des entiers non signés de 16 bits utilisés pour stocker les valeurs analogiques telles que les valeurs de température, d'humidité et de pression. Les bobines sont des bits uniques utilisés pour stocker les valeurs numériques dans la carte mémoire Modbus, généralement des valeurs d'état telles que l'état du commutateur (ON ou OFF), l'état de fonctionnement du moteur (UP ou DOWN) et l'état de la vanne (OUVERT ou FERMÉ).

Cela nécessitait peu d'espace de code, souvent aussi peu que 1K. La RAM variait avec la taille de votre espace de données. Des dispositifs d'automatisation simples avec peu de données pourraient être mis en œuvre avec pratiquement aucun espace RAM.

Modbus pourrait être si facilement compris par les non-programmeurs. Les ingénieurs qui ont construit des machines à colle, des compteurs, des appareils de mesure, etc. pouvaient facilement comprendre le concept de bobines/registres et les commandes simples pour les lire et les écrire.

Souvent, plusieurs instruments sont connectés au même réseau Modbus. Aucun instrument ne prend en charge tous les protocoles de réseau d'instrumentation, mais presque tous prennent en charge Modbus. En choisissant Modbus, vous avez de bonnes chances d'éviter les problèmes de compatibilité et les futurs problèmes de mise à niveau.

Surveillance de la température

Un système de surveillance de la température IoT permet à une industrie de suivre les paramètres environnementaux sur une plate-forme Web/mobile sécurisée et offre des notifications instantanées en temps réel. Ces données de capteur de température sont accessibles à distance.

Les données recueillies à partir des capteurs de température peuvent être utilisées pour créer des informations statistiques. Cela aidera les industries à améliorer la fiabilité de leur entrepôt et de leur chambre froide.

De nombreux cas d'utilisation industriels utilisent cette application :

• Surveillance numérique de la température dans les laboratoires et les cliniques,
• Conformités en matière de sécurité alimentaire
• Gestion des entrepôts et des stocks,
• Marchandises en transit,
• Surveillance des équipements.

Pour ce type de cas d'utilisation, l'application de surveillance de la température et de l'humidité est très pertinente. Cette application a besoin d'une passerelle pour surveiller la température et l'humidité. La passerelle nécessite une infrastructure informatique de pointe. Ici, le capteur Modbus, la passerelle et le cadre informatique de pointe utilisés sont respectivement le capteur industriel de température et d'humidité SHT20, Raspberry Pi 4 et EdgeX Foundry.

Comment Edgex est-il utilisé ?

Validation du service de périphérique Modbus à l'aide du simulateur d'esclave Modbus (ModbusPal)

ModbusPal est un simulateur d'esclave Modbus, gratuit et open source, publié sous licence GPL. Son objectif est d'offrir une interface facile à utiliser avec les capacités de reproduire des environnements Modbus complexes et réalistes. Il prend en charge TCP/IP nativement et prend en charge la communication série si la bibliothèque RxTx est installée sur l'ordinateur.

ModbusPal peut simuler jusqu'à 247 esclaves Modbus. Chaque esclave peut avoir des registres de maintien et des bobines. Chaque registre ou bobine peut être animé en étant associé à un générateur de valeur dynamique, appelé « automatisme ».

La validation du service de l'appareil Modbus à l'aide du simulateur ModbusPal avec un appareil esclave comme wattmètre se fait en suivant les étapes mentionnées ci-dessous. De la même manière, nous pouvons simuler tout type d'environnement pris en charge par Modbus avec des appareils esclaves tels que des capteurs de température, d'humidité et de pression.

1. Configuration de l'environnement ModbusPal,
2. Ajout d'appareils esclaves et configuration de leurs adressables, valeurs et automatisations,
3. Publication d'un profil d'appareil Modbus dans EdgeX,
4. Envoi d'un appareil Modbus dans EdgeX,
5. Envoi de données ou activation d'un appareil esclave (PUT),
6. Réception de données depuis un appareil esclave (GET).
7. Installez n'importe quel système d'exploitation pouvant installer docker et docker-compose. Dans cet exemple, nous utilisons Ubuntu 20.04.2 LTS pour déployer EdgeX à l'aide de docker.

Figure 3. Configuration d'un environnement pour ModbusPal Simulator

2. Ajoutez des appareils esclaves, configurez des registres de stockage, saisissez des valeurs et des noms et liez-les aux automatismes appropriés.

Figure 4. Ajout et configuration d'appareils esclaves dans le simulateur ModbusPal (Source :www.edgexfoundry.org)

3. Publiez le profil de l'appareil à l'aide de la commande POST.

curl –X POST http://
:48081/api/v1/deviceprofile/uploadfile -F file=@ 
 

Figure 5. Publication d'un profil d'appareil dans EdgeX

4. Poster l'appareil à l'aide de la commande POST. Utilisez la commande ci-dessous pour télécharger en tant que fichier ou utilisez la commande qui est une capture d'écran pour télécharger en tant que contenu.

curl –X POST http://
:48081/api/v1/device/uploadfile -F "file=@" 
 

Figure 6. Publication d'un appareil dans EdgeX

5. Exécutez la commande PUT pour envoyer les données.

curl –X PUT http://
:48082/api/v1/device//command/ -H « Type de contenu : application /json” –d '{“”:“”,“”:“”}'      
 

Figure 7. Exécution de la commande PUT dans EdgeX

6. Exécutez la commande GET pour recevoir les données.

curl –X GET http://
:48082/api/v1/device/name//command/Configuration | json_pp 
 

cliquez pour l'image en taille réelle

Figure 8. Exécution de la commande GET dans EdgeX

Profil de l'appareil

Le profil d'appareil décrit un type d'appareil au sein du système EdgeX. Chaque appareil géré par un service d'appareil est associé à un profil d'appareil, qui définit ce type d'appareil en termes d'opérations qu'il prend en charge. Le profil de l'appareil définit les valeurs et la méthode de fonctionnement de l'appareil, qui peuvent être en lecture ou en écriture. Un profil d'appareil se compose des balises suivantes :

1. Identification : Le profil contient divers champs d'identification. Le champ Nom est obligatoire et doit être unique dans un déploiement EdgeX. Les autres champs sont facultatifs :ils ne sont pas utilisés par les services de l'appareil, mais peuvent être renseignés à des fins d'information,
2. Ressources de l'appareil : Un deviceResource spécifie une valeur de capteur dans un périphérique qui peut être lue ou écrite individuellement ou dans le cadre d'un deviceCommand. Il a un nom d'identification et une description à titre informatif,
3. Commandes de l'appareil : Les DeviceCommands définissent l'accès aux lectures et écritures pour plusieurs ressources de périphérique simultanées. Chaque deviceCommand nommée doit contenir un certain nombre d'opérations get et/ou set resourceOperations, décrivant respectivement la lecture ou l'écriture,
4. Commandes de base : Les CoreCommands spécifient les commandes disponibles via le micro-service core-command, pour la lecture et l'écriture sur l'appareil. Les deviceResources et les deviceCommands peuvent être représentés par coreCommands (le nom de coreCommand fait référence au nom de deviceCommand ou de deviceResource).

Profil d'appareil du capteur de température et d'humidité Modbus (Faites défiler pour voir la liste complète)

nom :"TemperatureHumiditySensor"fabricant :"ROBOKITS"modèle :"RKI-4879"étiquettes :- "SHT20"description :"Transmetteur de température et d'humidité de qualité industrielle Capteur SHT20 Surveillance de haute précision Modbus RS485"deviceResources :- nom :"TemperatureDegC" description :"Température de la pièce en degrés Celsius." attributs : { tableau primaire :"INPUT_REGISTERS", startAddress :"2", rawType :"INT16" } propriétés : valeur : { tapez :"Float32", readWrite:"R", scale:"0.1", floatEncoding:"eNotation" } unités : { tapez :"String", readWrite:"R", defaultValue:"degrees celsius" } - nom :"HumidityPercentRH" description :"Humidité de la pièce en %RH." attributs : { tableau primaire :"INPUT_REGISTERS", startAddress :"3", rawType :"INT16" } propriétés : valeur : { tapez :"Float32", readWrite:"R", scale:"0.1", floatEncoding:"eNotation" } unités : { tapez :"String", readWrite :"R", defaultValue :"%RH" }deviceCommands :- nom :"TemperatureDegC" obtenir : - { index :"1", opération :"get", deviceResource :"TemperatureDegC" } - nom :"HumidityPercentRH" obtenir : - { index :"2", opération :"get", deviceResource :"HumidityPercentRH" }coreCommands :- nom :"TemperatureDegC" obtenir : chemin :"/api/v1/device/{deviceId}/TemperatureDegC" réponses :-code :"200" description :"Obtenir la température en degrés C" Valeurs attendues :["TemperatureDegC"] - code :"503" description :"service indisponible" Valeurs attendues :[] - nom :"HumidityPercentRH" obtenir : chemin :"/api/v1/device/{deviceId}/HumidityPercentRH" réponses :-code :"200" description :"Obtenir l'humidité en %RH" Valeurs attendues :["HumidityPercentRH"] - code :"503" description :"service indisponible" Valeurs attendues :[]

1.1.1.1 Profil de périphérique du périphérique GPIO - 1 (LED rouge) (Faites défiler pour voir la liste complète)

nom :"device-gpio12"fabricant  : « Intelligence du Jiangxing »modèle :"SP-01"libellés :- "gpio12"description :"exporter automatiquement gpio12 par commande"deviceResources :- nom :"valeur" description :"définir ou obtenir la valeur gpio du système" propriétés : valeur : { tapez :"Int8", readWrite :"RW", minimum :"0", maximum :"1", defaultValue :"0" } unités : { tapez :"String", readWrite :"R", defaultValue :"high:1; low:0" }deviceCommands :- nom :"valeur" obtenir : - { opération :"get", deviceResource:"value" } set : - { opération :"set", deviceResource :"value", paramètre :"0" }coreCommands :- nom :"valeur" mettre : chemin :"/api/v1/device/{deviceId}/value" parametersNames :["valeur"] réponses :-code :"200" description :"" -code :"500" description :"service indisponible" Valeurs attendues :[] obtenir : chemin :"/api/v1/device/{deviceId}/value" réponses :-code :"200" description :"" valeurs attendues :["valeur"] - code :"500" description :"service indisponible" Valeurs attendues :[]

Profil de périphérique du périphérique GPIO - 2 (LED bleue) (Faites défiler pour voir la liste complète)

nom :"device-gpio14"fabricant  : « Intelligence du Jiangxing »modèle :"SP-01"libellés :- "gpio14"description :"exporter automatiquement gpio14 par commande"deviceResources :- nom :"valeur" description :"définir ou obtenir la valeur gpio du système" propriétés : valeur : { tapez :"Int8", readWrite :"RW", minimum :"0", maximum :"1", defaultValue :"0" } unités : { tapez :"String", readWrite :"R", defaultValue :"high:1; low:0" }deviceCommands :- nom :"valeur" obtenir : - { opération :"get", deviceResource:"value" } set : - { opération :"set", deviceResource :"value", paramètre :"0" }coreCommands :- nom :"valeur" mettre : chemin :"/api/v1/device/{deviceId}/value" parametersNames :["valeur"] réponses :-code :"200" description :"" -code :"500" description :"service indisponible" Valeurs attendues :[] obtenir : chemin :"/api/v1/device/{deviceId}/value" réponses :-code :"200" description :"" valeurs attendues :["valeur"] - code :"500" description :"service indisponible" Valeurs attendues :[]

Configurations

Le fichier de configuration pour définir les appareils et planifier les tâches. Les microservices (c'est-à-dire, device-modbus) génèrent une instance relative au démarrage. Il contient des détails tels que le type de protocole, le nom de la passerelle, le protocole, l'adresse, le port et le chemin (ID d'unité).

Fichier de configuration du capteur de température et d'humidité (Faites défiler pour voir la liste complète)

[Writable]LogLevel ='DEBUG'[Service]BootTimeout =30000CheckInterval ='10s'Host ='localhost'ServerBindAddr ='' # valeur vide par défaut sur Service .Host valuePort =49991Protocol ='http'StartupMsg ='device modbus start'Timeout =5000ConnectRetries =10Labels =[]EnableAsyncReadings =trueAsyncBufferSize =16[Registry]Host ='localhost'Port =8500Type ='consul'[Logging =]EnableFileRemote ='./GPIO.LOG'[Clients] [Clients.Data] Protocol ='http' Host ='localhost' Port =48080 [Clients.Metadata] Protocol ='http' Host ='localhost' Port =48081 [Clients. Logging] Protocol ='http' Host ='localhost' Port =48061[Device] DataTransform =true InitCmd ='' InitCmdArgs ='' MaxCmdOps =128 MaxCmdValueLen =256 RemoveCmd ='' RemoveCmdArgs ='' ProfilesDir' ='./res UpdateLastConnected =false# Pre-define Devices[[DeviceList]] Name ='TemperatureHumiditySensor' # nom du fichier de profil de l'appareil Profile ='TemperatureH umiditySensor' Description ='Transmetteur de température et d'humidité de qualité industrielle SHT20 Sensor High Precision Monitoring Modbus RS485' labels =[ 'TemperatureHumiditySensor','modbusRTU' ] [DeviceList.Protocols] [DeviceList.Protocols.modbus-rtu] Adresse ='/dev/ ttyUSB0' BaudRate ='9600' DataBits ='8' StopBits ='1' Parity ='N' UnitID ='1' [[DeviceList.AutoEvents]] Frequency ='5s' OnChange =false Resource ='TemperatureDegC' [[DeviceList .AutoEvents]] Frequency ='5s' OnChange =false Resource ='HumidityPercentRH'

Fichier de configuration des périphériques GPIO (LED rouge et LED bleue) (Faites défiler pour voir la liste complète)

[Writable]LogLevel ='DEBUG'[Service]BootTimeout =30000CheckInterval ='10s'Host ='localhost'ServerBindAddr ='' # valeur vide par défaut sur Service .Host valuePort =49950Protocol ='http'StartupMsg ='device gpio started'Timeout =5000ConnectRetries =10Labels =[]EnableAsyncReadings =falseAsyncBufferSize =16[Registry]Host ='localhost'Port =8500Type ='false'[Logging =]EnableFileRemote ='./GPIO.LOG'[Clients] [Clients.Data] Protocol ='http' Host ='localhost' Port =48080 [Clients.Metadata] Protocol ='http' Host ='localhost' Port =48081 [Clients. Logging] Protocol ='http' Host ='localhost' Port =48061[Device] DataTransform =true InitCmd ='' InitCmdArgs ='' MaxCmdOps =128 MaxCmdValueLen =256 RemoveCmd ='' RemoveCmdArgs ='' ProfilesDir' ='./res UpdateLastConnected =false# Périphériques prédéfinis[[DeviceList]] Name ="gpio12" Profile ="device-gpio12" Description ="use gpio12" Labels =['gpio1 2'] [DeviceList.Protocols] [DeviceList.Protocols.other] Address ="device-gpio12"[[DeviceList]] Name ="gpio14" Profile ="device-gpio14" Description ="use gpio14" Libellés =['gpio14 '] [DeviceList.Protocols] [DeviceList.Protocols.other] Adresse ="device-gpio14"

Configuration et exécution avec résultats

1. Connectez le transmetteur de température et d'humidité de qualité industrielle SHT20 au Raspberry Pi (dans lequel la fonderie EdgeX est installée) via l'interface RS485 vers un convertisseur USB et des LED à l'aide de cavaliers et de résistances, comme indiqué sur l'image ci-dessous.

cliquez pour l'image en taille réelle

Figure 9. Détails de la connectivité matérielle

1. 1. Téléchargez le profil de périphérique ci-dessus dans les métadonnées avec un POST sur http://localhost:48081/api/v1/deviceprofile/uploadfile et ajoutez le fichier en tant que clé "fichier" au corps au format form-data, et le fichier créé La pièce d'identité sera retournée. L'exemple de commande suivant utilise curl pour envoyer la requête :

      curl –X POST http://
      :48081/api/v1/deviceprofile/uploadfile -F file=@ 
       

   2. Vérifiez que tous les services obligatoires de l'appareil sont opérationnels.

Figure 10. Vérification des services actifs de l'appareil

c. Ajoutez l'appareil avec un POST à ​​http://localhost:48081/api/v1/device, le corps ressemblera à quelque chose comme :(Faites défiler pour afficher la liste complète)

curl -X POST http://localhost:48081/api/v1/device  -H "Content-Type:application/json" -d '{ "nom"  :"TemperatureHumiditySensor", "description" :"Transmetteur de température et d'humidité de qualité industrielle Capteur SHT20 Surveillance de haute précision Modbus RS485", "adminState" :"UNLOCKED", "operatingState" :"ACTIVÉ", "protocoles" :{ "modbus-rtu" :{ "Adresse"  :"/dev/ttyUSB0", "BaudRate"  :"9600", "DataBits"  :"8", "StopBits"  :"1", "Parité"  :"N", "Unité"  :"1" } }, "libellés" :[ "TemperatureHumiditySensor", "modbusRTU" ], "service" :{"name":"edgex-device-modbus"}, "profil" :{"name":"TemperatureHumiditySensor"}, "autoEvents" :[ { "fréquence" :"5s", "onChange" :false, "ressource" :"TemperatureDegC" }, { "fréquence" :"5s", "onChange" :false, "ressource" :"HumidityPercentRH" } ]}'

Le périphérique peut être ajouté à l'aide de la commande POST ou dans le cadre du fichier configuration.toml.

2. Le service de l'appareil extraira les données de température et d'humidité du capteur toutes les 5 secondes. Les données reçues seront envoyées au service principal et stockées sur le serveur Redis.

2021/03/02 05:03:33 modbus :envoi 01 04 00 01 00 01 60 0a2021/03/02 05:03:33 modbus :reçu 01 04 02 01 4d 78 95

Tableau 1. Décodage de la demande et de la réponse Modbus

Envoyé Décodage Reçu Décodage 01ID d'esclave 01ID d'esclave04Code de fonction 04Code de fonction00 01Adresse de registre 02Compte d'octets00 01Nombre de registres 01 4dDonnées (0x014d =333)60 0aCRC 78 95CRC

3. Le service principal enverra les données au service d'application. La figure ci-dessous montre les données du service principal.

Figure 11. Données de température et d'humidité stockées dans le service principal

4. Le service d'application envoie les données vers le cloud. Ici, nous utilisons le cloud IBM. La figure ci-dessous montre les données dans le cloud IBM.

cliquez pour l'image en taille réelle

Figure 12. Données de température et d'humidité dans IBM Cloud envoyées depuis Application Service

5. Dans l'autre sens, du nord au sud, le service d'application enverra les données au moteur de règles (ici, nous utilisons le moteur de règles Kuiper). Les règles suivantes sont définies.

Tableau 2. Règles

Règles n° Règles LED Statut Règle #1TemperatureDegC> 30°CRed1 (ON)Règle #2TemperatureDegC <30°CRed0 (OFF)Règle #3TemperatureDegC> 28°CBlue0 (OFF)Règle #4TemperatureDegC <28°CBlue1 (ON)

Figure 13. Règle #1

Figure 14. Script pour appliquer les règles

6. Chaque fois que les températures seuils sont atteintes, le moteur de règles envoie une commande à la commande principale.
7. La commande principale active le service du périphérique GPIO pour activer ou désactiver la température de seuil basée sur les LED. Une fois que nous aurons exécuté les règles, les règles seront appliquées. Ici, gpio12 est destiné à la LED rouge et gpio14 est destiné à la LED bleue.

a. Allumez la LED rouge chaque fois que la température dépasse 30 °C.

Journaux du moteur de règles :

level=info msg="résultat du puits pour la règle red_led_on:[{\"TemperatureDegC\":32.3}] fichier ="sinks/log_sink.go:16"rule=red_led_onlevel=info msg="résultat du puits pour la règle blue_led_off:[{\"TemperatureDegC\":32.3}] file="sinks/log_sink.go:16"rule=blue_led_off 
GPIO : 
 
root@ubuntu:~# cat /sys/class/gpio/gpio12/value1root@ubuntu:~# cat / sys/class/gpio/gpio14/value0
 
b. Allumez une LED bleue chaque fois que la température descend en dessous de 28 °C.
 
Moteur de règles : 
 
level=info msg="résultat du puits pour la règle red_led_off :[{\"TemperatureDegC\":27.2}] fichier ="sinks/log_sink.go:16"rule=red_led_offlevel=info msg="résultat du puits pour la règle blue_led_on:[{\"TemperatureDegC\":27.2}] file="sinks/log_sink.go:16"rule=blue_led_on 
GPIO : 
 
root@ubuntu:~# cat /sys/class/gpio/gpio12/value0root@ubuntu:~# cat / sys/class/gpio/gpio14/value1
 
 
Enfin, le service GPIO activera ou désactivera la ou les LED.
 
 
Conclusion
 

 Industries are in the need of interfacing sensors and actuators and monitoring and controlling the environmental parameters for long term. The EdgeX framework enables the temperature and humidity monitoring application versatile, has enabled the controlled environment in industries, datacenters and laboratories. Interfacing any other industrial sensors with EdgeX Foundry will also work similar to industrial grade temperature and humidity sensor. This will save a huge amount of developer effort, development cost and latency as the EdgeX framework handles data storage, analytics, device management and cloud connectivity and gateway is very near to the sensors.
 
Acronyms
 Acronym Expansion AOFAppend Only FileAPIApplication Program Interface AWSAmazon Web ServicesBACnetBuilding Automation and Control NetworkBLEBluetooth Low EnergyCURLClient Uniform Resource LocatorGPIOGeneral Purpose Input OutputHTTPHypertext Transfer ProtocolIBMInternational Business MachinesIIoTIndustrial Internet of ThingsIoTInternet of ThingsITInformation TechnologyLEDLight Emitting DiodeLTSLong Term SupportM2MMan to MachineMQTTMessage Queuing Telemetry TransportRDBRedis DatabaseRedisREmote DIctionary ServerRESTRepresentational State TransferRS-485Recommended Standard – 485SCADASupervisory Control and Data AcquisitionSQLStructured Query LanguageTCP/IPTransmission Control Protocol/Internet Protocol 

            


            

               Comment implémenter l'IA des objets (AIoT) sur les MCU        
                Créer un chemin à travers le labyrinthe de la sécurité IoT