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.
#with cifX / netX driver and real-time ethernet programming examples
FROM hilschernetpi/netpi-netx-programming-examples
#enable building ARM container on x86 machinery on the web (comment out next line if built on Raspberry)
#RUN [ "cross-build-start" ]
#labeling
LABEL maintainer="slos@hilscher.com" \
version="V0.0.1" \
description="Debian(stretch) / Hilscher netX / Ada for Automation Development"
#version
ENV ADA_FOR_AUTOMATION_HILX_BASIS_DEV_VERSION 0.0.1
#install git, gnat and gprbuild
RUN apt-get update \
&& apt-get install git gnat gprbuild
#install libmodbus
RUN apt-get update \
&& apt-get install libmodbus5 libmodbus-dev
#install Ada for Automation
RUN mkdir --parents /home/pi/Ada \
&& cd /home/pi/Ada \
&& git clone https://gitlab.com/ada-for-automation/ada-for-automation.git A4A \
&& mkdir A4A/Hilscher
#copy some Hilscher files relating to netX Diag and remote access
COPY ./Hilscher/ /home/pi/Ada/A4A/Hilscher/
#and build some demo applications
RUN cd "/home/pi/Ada/A4A/demo/000 a4a-k0-cli" && make
#SSH port
EXPOSE 22
#the entrypoint shall start ssh
ENTRYPOINT ["/usr/sbin/sshd", "-D"]
#set STOPSGINAL
STOPSIGNAL SIGTERM
#stop processing ARM emulation (comment out next line if built on Raspberry)
#RUN [ "cross-build-end" ]
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.
FROM soloist/netpi-a4a-basis-dev:latest
#enable building ARM container on x86 machinery on the web (comment out next line if built on Raspberry)
#RUN [ "cross-build-start" ]
#labeling
LABEL maintainer="slos@hilscher.com" \
version="V0.0.1" \
description="Debian(stretch) / Hilscher netX / Ada for Automation Web Development"
#version
ENV ADA_FOR_AUTOMATION_HILX_WEB_DEV_VERSION 0.0.1
#install Gnoga and dependencies (Simple Components, ZanyBlue)
RUN mkdir --parents /home/pi/Ada/Gnoga \
&& cd /home/pi/Ada/Gnoga \
&& git clone https://git.code.sf.net/p/gnoga/code gnoga \
&& cd /home/pi/Ada/Gnoga/gnoga \
&& make release \
&& make install
#build some Ada for Automation Web demo applications
RUN cd "/home/pi/Ada/A4A/demo/052 a4a_hilscherx_piano" && make
#install the PROFINET IO Device firmware for example
RUN cd "/home/pi/firmwares" \
&& dpkg -i netx-docker-pi-pns-3.12.0.2.deb
#SSH port
EXPOSE 22
#the entrypoint shall start ssh
ENTRYPOINT ["/usr/sbin/sshd", "-D"]
#set STOPSGINAL
STOPSIGNAL SIGTERM
#stop processing ARM emulation (comment out next line if built on Raspberry)
#RUN [ "cross-build-end" ]
Je recommence la séquence en plus condensé…
docker container create --publish 22:22 -p 8090:8090 --privileged=true --device=/dev/spidev0.0:/dev/spidev0.0 netpi-a4a-web-dev:latest
docker tag netpi-a4a-web-dev soloist/netpi-a4a-web-dev:latest
docker push soloist/netpi-a4a-web-dev
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