Le netPI RTE 3

Bonjour,

La société Hilscher a conçu une déclinaison industrielle du Raspberry Pi 3, la gamme netPI, aujourd’hui constituée de deux produits, le netPI CORE 3 et le netPI RTE 3.

Ces deux produits partagent donc la même ascendance Raspberry Pi et le netPI RTE 3 apporte en sus une connectivité Ethernet Temps Réel car il dispose d’un système sur puce netX 51.

Le SoC netX 51 est connecté via une liaison SPI haute vitesse à la CPU du Raspberry Pi comme l’est le netX 52 qui équipe le netHAT dont il a déjà été question ici.

Ce même matériel est mis en œuvre dans le netIOT Edge Connect avec une distribution logicielle différente qui se veut plus simple d’utilisation avec Node-RED intégré de base.

Dans l’article précédent je présentais la technologie Docker, intégrée dans tous les produits de la gamme netIOT, avec un exemple « Ada for Automation » et je me propose d’étendre cette démonstration au netPI RTE 3.

Les exemples de code en C

On trouve sur le Hub communautaire une image contenant des exemples d’utilisation du netX 51 pour les protocoles de bus de terrain PROFINET, EtherNet/IP, EtherCAT, POWERLINK et Modbus/TCP.

Il faut noter que le netX 51 est conçu spécifiquement pour gérer des piles de protocoles industriels, cela uniquement en tant qu’esclave. Le cas particulier est celui de Modbus TCP puisqu’il peut être dans ce cas Client et / ou Serveur.

Les sources du Dockerfile sont disponible sur GitHub ici.

Cette image fournit, outre les exemples de code en C, les firmwares qui implémentent les piles de protocoles pour le netX 51 ainsi que le pilote pour Linux qui fournit l’interface applicative cifX. Et bien sûr la documentation qu’il vous faudra étudier avec soin avant de solliciter le support…

L’image de base « Ada for Automation »

Partons de cette image pour créer la notre comme dans ce Dockerfile qui ajoute les outils pour le développement en Ada, la libmodbus, récupère les sources et compile « Ada for Automation » et une application de test basique mettant en œuvre l’API cifX.

Construisons l’image :

On peut tester sur le Raspberry Pi avec le netHAT mais cela demande quelques modifications car, si le pilote Linux fourni dans cette image convient au netHAT, il n’en est pas de même pour les firmwares,les produits étant différents.

Il est donc nécessaire d’adapter en fonction du matériel à sa disposition.

A la création du conteneur, il faut fournir le « device » qui permet la connexion en SPI.

On peut jouer avec le conteneur et, si tout baigne, on tague :

Puis on se connecte et on pousse :

L’image « Ada for Automation » Web

Comme dans l’article précédent, l’image suivante rajoute Gnoga et ses dépendances et compile une application de test disposant d’une interface web.

Je recommence la séquence en plus condensé…

Voilà mes images dans les nuages chez Docker Hub.

Portainer

Avec le Raspberry Pi on a accès au système Linux qui fait tourner Docker et on peut donc interagir avec ce dernier en ligne de commande comme nous l’avons fait jusqu’ici.

Sur les cibles netIOT Edge, le système Linux de base est sécurisé et il n’est pas possible d’y accéder. Aussi ces cibles, disposant toutes de Docker, disposent également d’une interface web qui permet l’interaction avec Docker, j’ai nommé Portainer.

On y accède via le portail :

Portainer permet entre autres de créer et de gérer images et conteneurs.

Mon conteneur créé et démarré, je me connecte en SSH, par exemple avec PuTTY.

Je lance l’application et… ça tombe en marche !

Hilscher fournit le fichier GSDML qui convient pour la configuration du réseau PROFINET avec TIA Portal et on peut visualiser les données échangées dans une table de variables :

Que l’on peut manipuler depuis l’interface web de l’application :

L’état de l’application nous montre un comportement temps réel plutôt satisfaisant, ce qui ce conçoit car le système de base est un Linux avec patches PREEMPT_RT et que Docker ne détruit pas les propriétés temps réel.

On peut aussi s’intéresser à la vue d’état cifX :

Ou se connecter avec SYCON.net, l’outil de configuration standard Hilscher car « Ada for Automation » embarque le protocole de diagnostic et accès distant.

Conclusion

Le netPi est au départ un produit conçu pour connecter les technologies de l’information avec l’opérationnel, soit IT/OT, et gérer localement des données pour les trier, les agréger, les mettre en forme, etc…

Ainsi l’on a l’embarras du choix pour acquérir et traiter ces données.

Au niveau acquisition avec les différents interfaces (LAN, WiFi, RTE, RS 432/422/485…) et protocoles de communication disponibles comme au niveau traitement avec Node-RED, tous les langages disponibles dans Linux (C, Python, Java…), des standards de l’automatisme comme CODESYS ou STRATON, et bien sûr « Ada for Automation », l’éclectisme est de mise à tous les étages et la liberté offerte par cette plateforme la rend propice à toutes les expérimentations et réalisations industrielles.

Cordialement,
Stéphane