netIC IOT

Module IC de communication DIL-32 pour Ethernet temps réel, E/S numériques et communication IoT

 
  • Un seul matériel compact pour tous les esclaves Ethernet temps-réel
 
  • Interface objet indépendante du protocole avec l'application
 
  • Définition d'objet et d'appareil avec netX Studio
 
 
  • Serveur OPC UA & client MQTT intégrés
 
  • Webserver intégré
 
  • Connexion directe d'E/S numériques via registres à décalage
 

 

netIC IOT : orienté objet et IoT-Ready

Les appareils de terrain compacts gagnent progressivement en intelligence et en fonctionnalités. Il est donc nécessaire, surtout pour I4.0 et IIoT, d'établir un modèle de données continu et orienté objet, de l’appareil de terrain au niveau de l’encadrement. Outre la transmission par Ethernet temps réel, les objets doivent être transférés directement dans le nuage ou à une passerelle edge par communication IoT. Pour atteindre ces objectifs, Hilscher a enrichi son module IC de communication netIC DIL-32 compact d’une fonctionnalité IoT essentielle.

  


Cas d'utilisation : Avec un OPC UA / MQTT intégré, les appareils de terrain fournissent des "données à valeur ajoutée" à un appareil edge ou directement à un cloud en utilisant le même câble physique.

 

Le nouveau netIC IoT-ready est basé sur la puce multiprotocole netX 52 et offre aux fabricants d'appareils une flexibilité maximale et une manipulation simple. Avec netIC IOT, l'utilisateur peut transmettre des données via OPC UA ou MQTT sur le même câble parallèlement à la communication Ethernet temps réel, sans perturbations et en contournant l’automate. Toutes les données process et de service de l'appareil de terrain seront organisées dans un modèle objet générique, indépendant du protocole.

Le fabricant d'équipement d'origine (OEM) sera assisté par l'outil de développement intelligent netXStudio qui le guidera tout au long du « processus de construction » de l’appareil et, à l'avenir, il pourra même adapter le brochage de netIC IOT à ses besoins. De plus, il peut utiliser la fonctionnalité standard netIC comme interface SSIO pour les entrées/sorties directes ou une interface SPI pour le CPU hôte.

Pour satisfaire aux différents besoins, il existe deux versions de netIC pour Ethernet temps réel :

netIC

 

netIC IOT

 
  • Pour les appareils de terrain simples avec un faible débit de données
  • Fonctionne comme une passerelle embarquée
  • Interface hôte utilisant le protocole Modbus RTU via UART
  • Connexion d'E/S numériques via registres à décalage à l'aide d'une interface SSIO
  • Configuration via un outil graphique facile à utiliser
  • Serveur web intégré
  • Flash 4Mo & SDRAM 4Mo
 
 
  • Pour les appareils de terrain intelligents dans le domaine de l'industrie 4.0
  • Interface de communication avec mémoire à double accès
  • Interface hôte via un modèle objet indépendant du protocole utilisant un SPI 50 MHz (SPM)
  • Connexion d'E/S numériques via registres à décalage à l'aide d'une interface SSIO
  • Développement d'appareil via netXStudio
    • Définition d'objet et d'appareil
    • Création de sites web
    • Gestion des utilisateurs
    • ...et plus encore
  • Serveur web intégré
  • Serveur OPC UA & client MQTT intégrés
  • Flash 4Mo & SDRAM 8Mo
 

 

 

Structure logicielle pour l'application

En tant qu'interface commune pour l'échange de données vers le processeur hôte, les produits basés sur netX utilisent une mémoire à double accès interne. Sa structure clairement définie consiste en un canal système, un canal handshake et jusqu'à 4 canaux de communication qui peuvent être utilisés pour des fonctions/protocoles indépendants.

Le nombre de canaux de communication accordés à l'application varie en fonction de la gamme de fonctions du firmware netX utilisé.

Le firmware du netIC IOT fournit un canal (canal 0) accessible par le processeur hôte à l'aide d'une interface SPI 50 MHz (SPM) par défaut. Ce canal 0 fournit des données Ethernet temps réel ainsi que des données IoT à l'application. Le netIC IOT se démarque par le fait que les données ne seront pas transférées comme une simple carte mémoire, mais dans le modèle d'objet indépendant du protocole : netPROXY.

De plus, les entrées/sorties numériques peuvent être connectées directement via des registres à décalage conventionnels à l'aide d'une interface série synchrone supplémentaire (SSIO). Les données seront ensuite utilisées par l'application, l'Ethernet temps réel ou la communication IoT.

 

Canal 0 :

Données Ethernet temps réel cycliques / acycliques & données IoT
via OPC UA / MQTT

SSIO :

E/S numériques via registres à décalage

 

 

 

Interface objet indépendante du protocole netPROXY

Protocole Chaque système réseau fournit des services spécifiques qui doivent être mis en œuvre dans l'application par l'utilisateur. Cette étape requiert une grande connaissance du fonctionnement de chaque système et suppose qu'un effort supplémentaire soit investi dans le logiciel de l'application pour chaque réseau. C'est à ce moment-là qu'intervient la technologie netPROXY. En résumé, netPROXY établit une interface d'objet et de service orientée appareil entre l'application et la communication. Cette couche d'abstraction dissimule la complexité ainsi que les différentes API de protocole et permet un échange de données cycliques et acycliques avec quelques services simples.

Le fabricant de l'appareil se contente de mettre en œuvre cette interface d'objet générique dans son application et netPROXY transcrit les objets automatiquement en services de réseau correspondants. Ainsi, le fabricant d'équipement d'origine (OEM) peut développer son application indépendamment de toute exigence spécifique au réseau et reçoit en fin de compte un réel appareil multiprotocole.

L'OEM sera assisté par un outil de développement intelligent qui le guidera tout au long du "processus de construction" de son appareil de terrain. Lors de ce processus, l'OEM créera le modèle d'objet pour son appareil et les données seront presque automatiquement mappées au système réseau choisi. Outre les paramètres pour OPC UA, MQTT et la gestion des utilisateurs, à l'avenir, l'OEM pourra même adapter le brochage de DIL-32 IC à ses besoins.

Ensuite, l'OEM reçoit une image téléchargeable pour son appareil, un fichier de description de l'appareil personnalisé (EDS) ainsi que le code source pour l'intégration dans son application (.h).