Mise en œuvre de l’OPC UA

Magazine
Marque
Hackable
Numéro
45
Mois de parution
novembre 2022
Spécialité(s)


Résumé

L’OPC UA (Open Platform Communications Unified Architecture) est une technologie en pleine expansion, notamment dans le milieu industriel. Après une courte introduction sur le sujet, cet article détaillera comment en déployer une implémentation open source dans un environnement embarqué à travers quelques exemples.


Body

L’OPC UA est un ensemble de spécifications dont l’objectif est de standardiser les échanges entre équipements. Historiquement très répandu dans le milieu industriel, en particulier dans les automates et la supervision, il fait ces dernières années une percée dans d’autres domaines comme le ferroviaire, le nucléaire ou le spatial.

L’OPC UA se positionne comme le successeur d’OPC DA (OPC Data Access) qui avait l’inconvénient d’être basé sur une technologie propriétaire Microsoft (COM/DCOM), qui est de surcroît devenue obsolète.

La fondation OPC [1] est chargée des évolutions de la technologie via des groupes de travaux ainsi que de sa promotion.

Parmi ses propriétés les plus remarquables, nous pouvons lister :

  • son indépendance vis-à-vis des plateformes, ce qui permet de le déployer d’un petit capteur actionneur jusqu’à un serveur en passant par le cloud ;
  • des capacités de modélisation de données avancées qui permettent de modéliser finement la sémantique métier des données ;
  • des fonctionnalités de cybersécurité avancées (signature, chiffrement, autorisations…). Ces fonctionnalités sont régulièrement évaluées par le BSI (équivalent allemand de l’ANSSI). Celui-ci a jugé que le protocole offrait un haut niveau de sécurité à ses utilisateurs [2] ;
  • et surtout, son haut niveau d’interopérabilité garanti par la fondation, qui évalue à l’aide d’un laboratoire indépendant tous les produits souhaitant être certifiés OPC UA.

La spécification OPC UA, normalisée IEC62541, est conséquente [3] (1500 pages de normes en 14 volumes pour la version 1.04). Elle s’enrichit régulièrement, notamment avec ses dernières évolutions comme le Pub/Sub qui permet d’étendre ses cas d’usage à la connectivité cloud et aux bus de terrain.

Par conséquent, les différentes implémentations disponibles ne couvrent généralement pas l’intégralité du standard, mais se concentrent sur un sous-ensemble de fonctionnalités adapté à leurs cas d’usage principaux.

Dans cet article, les exemples sont basés sur S2OPC [4], implémentation open source Apache 2.0. Écrite en C99, elle est bien adaptée au développement embarqué et aux contraintes en termes de cybersécurité et/ou de sûreté de fonctionnement.

Enfin, vous aurez sûrement remarqué que depuis le début de cet article, nous évitons soigneusement d’utiliser le qualificatif « protocole » pour l’OPC UA. En effet, ses spécifications contiennent des parties fonctionnelles et sémantiques qui vont bien au-delà de la définition usuelle du terme protocole. C’est pourquoi beaucoup d’experts OPC UA considèrent qu’au lieu de ce terme réducteur, il vaut mieux parler de technologie ou de « framework ». Comme nous n’avons envie de nous fâcher avec personne, c’est la dernière fois que vous voyez le mot protocole écrit dans cet article ;-).

1. Présentation technique

L’OPC UA se décline en deux variantes :

  • le client/serveur, mode connecté point à point. La plus classique et bien adaptée à la supervision ;
  • le Pub/Sub, mode déconnecté basé sur le mécanisme du Publish/Subscribe. Permettant d’adresser à la fois les bus de terrain et la connectivité cloud.

Dans cet article, nous allons nous concentrer sur la partie client-serveur. La mise en œuvre du Pub/Sub pourra faire l’objet d’un second article. Le couplage de celui-ci avec la technologie TSN permet notamment d’atteindre un très haut niveau de déterminisme sur les communications.

En mode client-serveur, un serveur stocke et organise les données dans une structure que l’on appelle l’« address space ». Celle-ci est constituée de nœuds reliés entre eux par des références. Les nœuds possèdent un certain nombre d’attributs suivant leur type. Par exemple, les nœuds de type « variable » possèdent un attribut contenant leur valeur.

Le client a quant à lui la possibilité d’ouvrir des connexions sur les différents points d’accès du serveur (ou endpoints). De manière simplifiée, nous pouvons considérer que ces connexions se font en trois étapes :

  • l’ouverture d’un « secure channel » qui permet de signer et chiffrer les messages ;
  • la création d’une session qui permet une authentification mutuelle des applications client et serveur ;
  • l’activation de cette session qui permet une authentification au niveau utilisateur.

Une fois la connexion établie, le client pourra ensuite envoyer au serveur des requêtes afin que celui-ci exécute les services et lui renvoie la réponse. Les services les plus courants sont les suivants :

  • « GetEndpoints » : ce service permet à un client de connaître quel sont les endpoints d’un serveur et quelles sont les contraintes pour pouvoir ouvrir une session avec chacun d’entre eux (politique de sécurité, authentification utilisateur…) ;
  • « Browse » : ce service permet de parcourir les références entre les différents nœuds de l’« address space » afin d’en découvrir la structure ;
  • « Read » : ce service permet d’aller lire de manière synchrone un ou plusieurs attributs d’un ou plusieurs nœuds de l’« address space » ;
  • « Write » : ce service permet d’aller écrire de manière synchrone un ou plusieurs attributs d’un ou plusieurs nœuds de l’« address space » ;
  • « Method call » : ce service permet d’appeler des méthodes de manière synchrone appartenant à des objets de l’« address space » ;
  • « Subscription » : cet ensemble de services permet à un client de s’abonner à une donnée afin d’être notifié de manière asynchrone d’une modification de celle-ci.

client serveur-s

Figure 1

Au niveau de la sécurité des échanges, trois modes sont possibles :

  • None : aucune protection ;
  • Sign : l’intégrité des données est garantie par une signature ;
  • SignAndEncrypt : les données sont signées et chiffrées.

Parallèlement à cela, la configuration d’un point d’accès comprend également la politique de sécurité qui définit l’ensemble des algorithmes et des tailles des clés et certificats qui vont être utilisés pour l’établissement d’une session client-serveur.

La PKI associée est constituée d’une paire clé privée / clé publique pour le serveur et le client. Les clés publiques sont signées par une autorité de certification que tous deux reconnaissent. Lors des premiers échanges, le client va vérifier la signature du certificat du serveur et le serveur fera la même chose avec le certificat du client.

Il existe également des mécanismes d’authentification et de droits utilisateurs, mais ceux-ci ne seront pas abordés dans cet article pour des raisons de concision.

De nombreuses configurations sont possibles. Dans un objectif pédagogique, cet article se concentre sur le déploiement d’une communication client-serveur entre :

  • une carte microprocesseur Raspberry Pi 3 B+ 32 bits sous GNU/Linux embarqué ;
  • une carte microcontrôleur STM32 Nucleo H745ZI-Q de chez STMicroelectronics sous Zephyr disposant entre autres d’une interface Ethernet lui permettant de s’interfacer avec le Raspberry Pi.

Dans cet article, nous nous reposons en partie sur l’outil Docker qui est supposé être installé sur votre environnement de développement (Docker Desktop pour les personnes utilisant GNU/Linux sous WSL2).

Pour information ou rappel, les commandes suivantes permettent d’autoriser Docker à exécuter des commandes sans sudo explicite :

$ sudo groupadd docker # si le groupe n’existe pas déjà !
$ sudo gpasswd -a $USER docker
$ newgrp docker # ou logout/login

2. Mise en œuvre sur Raspberry Pi / Linux

Commençons par cloner le dépôt des sources.

$ git clone https://gitlab.com/systerel/S2OPC.git
Clonage dans 'S2OPC'...
remote: Enumerating objects: 71231, done.
remote: Counting objects: 100% (4515/4515), done.
remote: Compressing objects: 100% (393/393), done.
remote: Total 71231 (delta 4359), reused 4172 (delta 4122), pack-reused 66716
Réception d'objets: 100% (71231/71231), 183.98 Mio | 3.55 Mio/s, fait.
Résolution des deltas: 100% (58214/58214), fait.

Plusieurs solutions sont possibles pour la compilation. L’une d’entre elles consiste à compiler directement sur le Raspberry Pi en suivant les instructions du wiki [5]. La seconde que nous allons suivre dans cet article est d’utiliser une image Docker contenant les outils et les dépendances permettant de faire une compilation croisée de x64 vers ARM 32 bits. Récupérons l’image Docker.

$ docker pull registry.gitlab.com/systerel/s2opc/rpi-build:latest
latest: Pulling from systerel/s2opc/rpi-build
Digest: sha256:977b5d7083659af98a6279ee12d7d3ca1c94195b8b954c72c605a22386446a7c
Status: Downloaded newer image for registry.gitlab.com/systerel/s2opc/rpi-build:latest
registry.gitlab.com/systerel/s2opc/rpi-build:latest

Puis lançons la compilation croisée en activant l’ensemble des fonctionnalités du serveur :

$ cd S2OPC
$ ./.rpibuild-in-docker.sh WITH_NANO_EXTENDED=1 ./build.sh
Build the library and tests with CMake
- Generate ./build_toolchain directory
- Run CMake
-- WITH_NANO_EXTENDED S2OPC option set
-- PyS2OPC not compiled
-- MQTT PUBSUB: Paho library found, it will be used by MQTT Pubsub Protocol extension
- Run make
Built library and tests with success
Completed with SUCCESS

Les résultats ont été générés dans le sous-répertoire build_toolchain/bin. Vous pouvez les transférer sur votre Raspberry Pi dans un dossier dédié :

$ scp -r build_toolchain/bin/ pi@rapsberry:~/S2OPC

Le serveur de démonstration est configurable via trois fichiers XML vers lesquels doivent pointer trois variables d’environnement :

  • TEST_SERVER_XML_ADDRESS_SPACE qui définit le contenu de l’« address space ». Le format est normalisé par la fondation OPC ;
  • TEST_SERVER_XML_CONFIG qui contient la définition des différents points de connexion du serveur (les endpoints) ;
  • TEST_USERS_XML_CONFIG qui contient la définition de l’authentification au niveau utilisateur.

Pour utiliser la configuration d’exemple, positionnez les variables d’environnement, puis lancez les serveurs :

$ cd S2OPC/bin
$ export TEST_SERVER_XML_CONFIG=./S2OPC_Server_Demo_Config.xml
$ export TEST_SERVER_XML_ADDRESS_SPACE=./s2opc.xml
$ export TEST_USERS_XML_CONFIG=./S2OPC_Users_Demo_Config.xml
$ ./toolkit_demo_server
$ ./toolkit_test_server
S2OPC_Common       - Version: 1.1.0*, SrcCommit: 6a16594c7c5aee180acd9d4ebf2083236428f02c, DockerId: sha256:01589086151582e8d410aa71cc775890a7521804207af16825c506f406472d02, BuildDate: 2022-02-11
S2OPC_ClientServer - Version: 1.1.0*, SrcCommit: 6a16594c7c5aee180acd9d4ebf2083236428f02c, DockerId: sha256:01589086151582e8d410aa71cc775890a7521804207af16825c506f406472d02, BuildDate: 2022-02-11
<Test_Server_Toolkit: initialized
> MatchCRLList warning: Certificate with SHA-1 fingerprint 69:52:2D:55:DE:B6:45:34:52:A1:B7:39:48:B4:52:EF:03:DE:80:25 has no CRL or multiple CRLs, and is removed from the CAs list.
> MatchCRLList warning: Certificate with SHA-1 fingerprint B7:D5:15:48:6A:C1:74:01:54:2A:CB:7A:FC:1D:11:BD:66:83:85:60 has no CRL or multiple CRLs, and is removed from the CAs list.
> PKI creation warning: Not all certificate authorities in given trusted roots have a single certificate revocation list! Certificates issued by these CAs will be refused.
> PKI creation warning: Not all certificate authorities in given untrusted roots have a single certificate revocation list! Certificates issued by these CAs will be refused.
<Test_Server_Toolkit: Certificates and key loaded
<Test_Server_Toolkit: @ space configured
<Demo_Server: Server started

Félicitations, votre premier serveur OPC UA a démarré.

En ce qui concerne la partie client, le même répertoire contient un certain nombre de binaires de démonstration faisant chacun appel à un service OPC UA en tant que client. Par exemple, s2opc_discovery envoie une requête « GetEndpoints » alors que s2opc_read envoie comme son nom l’indique une requête de « Read ».

3. Mise en œuvre sur Zephyr / STM32 Nucleo

Passons maintenant à la partie microcontrôleur sur carte STM32 Nucleo H745ZI-Q avec l’OS Zephyr.

De même que pour la partie Raspberry Pi, il est possible d’installer les outils Zephyr à partir de ce lien [6].

Dans cet article, nous utilisons une image Docker contenant l’ensemble de ces outils ainsi que leurs dépendances installées :

$ docker pull registry.gitlab.com/systerel/s2opc/zephyr_build:latest

On lance un conteneur auquel on lie le répertoire où l’on va ranger les binaires générés :

$ docker run --rm -ti -v /tmp/zephyrproject:/host_zephyr registry.gitlab.com/systerel/s2opc/zephyr_build:latest

Dans ce docker, nous retrouvons les sources de Zephyr et de S2OPC.

Il est nécessaire d’obtenir la branche Zephyr de S2OPC. Cette étape se fait grâce à west.

$ west update s2opc

Via des variables d’environnement, on choisit l’application ainsi que la carte sur laquelle on veut exécuter l’application.

$ export BOARD=nucleo_h745zi_q_m7$ export APP=zephyr_server

Puis on lance la compilation croisée du projet Zephyr et de l’application pour la carte. Une fois la compilation terminée, on copie le fichier dans le répertoire partagé.

Note : l’instruction sudo est nécessaire ici, car l’utilisateur dans le container Docker n’a pas les droits d’écriture sur votre système de fichier.

$ cd /workdir/modules/lib/s2opc/zephyr/samples/${APP}
$ west build -b ${BOARD} .
$ sudo cp build/zephyr/zephyr.bin /host_zephyr/${APP}_${BOARD}.bin

On branche maintenant un câble USB entre le connecteur CN11 de notre carte STM32 NUCLEO et notre PC.

Puis on flashe la mémoire de la carte en la branchant à l’ordinateur via le câble USB et en copiant le fichier binaire dans le média.

$ cp zephyr_server_nucleo_h745zi_q_m7.bin /media/vincent/NOD_H745ZIQ/

Ces instructions permettent de construire une image contenant un serveur OPC UA. Pour construire un client, il suffit de changer la variable d’environnement, puis de lancer la construction de l’application.

$ export APP=zephyr_client

Vérifions maintenant si le serveur démarre et connectons-nous au terminal série de la carte :

$ sudo minicom -d /dev/ttyACM0

Si l’on appuie sur le bouton reset de la carte, nous voyons les traces suivantes qui nous confirment que le serveur OPC UA a bien démarré :

*** Booting Zephyr OS build zephyr-v2.7.1-3-gcd42010fa1bf ***
...
# Info: Server initialized.
# Initializing server at EP: opc.tcp://192.168.42.21:4841
# Address space loaded
# Info: Endpoint and Toolkit configured.
# Info: Server started.
# Server started on <opc.tcp://192.168.42.21:4841>

4. Intégration du client et du serveur

Nous allons maintenant utiliser un client OPC UA sur la carte Raspberry Pi pour faire appel à quelques services sur le serveur de la carte STM32 Nucleo.

Nous savons grâce aux traces ci-dessus que le serveur a démarré sur la carte STM32 Nucleo à l’URL opc.tcp://192.168.42.21:4841. Cette adresse est modifiable si besoin dans la configuration du projet.

Nous laissons à l’utilisateur le soin de placer le Raspberry Pi et la STM32 Nucleo sur le même sous-réseau local.

Utilisons maintenant le service GetEndpoints pour savoir quels sont les points de connexion disponibles sur le serveur :

$ ./s2opc_discovery --none -e opc.tcp://192.168.42.21:4841
S2OPC discovery demo.
4 endpoints:
- Endpoint opc.tcp://192.168.42.21:4841
  Security policy and mode: http://opcfoundation.org/UA/SecurityPolicy#None OpcUa_MessageSecurityMode_None
  ApplicationDescription:
    ApplicationUri: urn:S2OPC:localhost
    ProductUri: urn:S2OPC:localhost
  CertificateThumbprint: <null>
  UserIdentityTokens:
  - PolicyId anonymous
    OpcUa_UserTokenType_Anonymous
    SecurityPolicyUri <empty, endpoint policy is http://opcfoundation.org/UA/SecurityPolicy#None>
      WARNING: secrets in user identity token will not be encrypted
...
  Security policy and mode: http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256 OpcUa_MessageSecurityMode_SignAndEncrypt
  ApplicationDescription:
    ApplicationUri: urn:S2OPC:localhost
    ProductUri: urn:S2OPC:localhost
  CertificateThumbprint: f4:69:4c:21:c0:0f:cb:31:55:36:9d:1d:fc:69:ba:eb:ee:20:9a:04
  UserIdentityTokens:
  - PolicyId anonymous
    OpcUa_UserTokenType_Anonymous
    SecurityPolicyUri <empty, endpoint policy is http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256>
  - PolicyId username_Basic256Sha256
    OpcUa_UserTokenType_UserName
    SecurityPolicyUri http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256

Quatre points de connexion sont listés, mais nous allons nous intéresser à deux d’entre eux à des fins de démonstration :

  • le premier qui n’a ni chiffrement ni signature ;
  • le dernier qui est chiffré et signé avec la politique de sécurité Basic256Sha256.

Commençons par parcourir les références associées au nœud objet dont l’identifiant est normalisé par i=85 :

$ ./s2opc_browse --none -e opc.tcp://192.168.42.21:4841 -n i=85
S2OPC browse demo.
# Info: Session activated.
# Info: Sending BrowseRequest.
# Info: Response received.
Browsed nodes:
- i=85 -> ns=1;s=PubVars "PublisherVars"
- i=85 -> ns=1;s=SubVars "SubscriberVars"
- i=85 -> i=2253 "Server"
- i=85 -> ns=1;s=PubSubStatus "PubSub Status"
- i=85 -> ns=1;s=PubSubConfiguration "PubSub Configuration"
- i=85 -> ns=1;s=PubSubStartStop "PubSub Start/Stop Command"
- i=85 <- i=84 "Root"
- i=85 -> i=61 "FolderType"
# Info: Continuation point null, no more References.

Nous voyons un nœud dont l’identifiant est ns=1;s=PubVars dont le nom laisse supposer qu’il peut contenir des variables. Parcourons donc le niveau inférieur :

$ ./s2opc_browse --none -e opc.tcp://192.168.42.21:4841 -n 'ns=1;s=PubVars'
S2OPC browse demo.
# Info: Session activated.
# Info: Sending BrowseRequest.
# Info: Response received.
Browsed nodes:
- ns=1;s=PubVars <- i=85 "Objects"
- ns=1;s=PubVars -> i=61 "FolderType"
- ns=1;s=PubVars -> ns=1;s=PubBool "varBool"
- ns=1;s=PubVars -> ns=1;s=PubString "varString"
- ns=1;s=PubVars -> ns=1;s=PubInt "varInt"
- ns=1;s=PubVars -> ns=1;s=PubUInt "varUInt"
- ns=1;s=PubVars -> ns=1;s=PubUInt16 "varUInt16"
- ns=1;s=PubVars -> ns=1;s=PubUInt32 "varUInt32"
# Info: Continuation point null, no more References.

En effet, le dossier contient un certain nombre de variables de différents types qui vont nous permettre d’effectuer quelques tests de lecture et écriture. Prenons par exemple le nom dont l’identifiant est ns=1;s=PubString et de type chaîne de caractères.

Nous envoyons une requête de lecture en mode « None » sur ce nœud et nous demandons l’attribut numéro 13 (celui de la valeur) :

./s2opc_read --none -e opc.tcp://192.168.42.21:4841 -n 'ns=1;s=PubString' -a 13
S2OPC read demo.
# Info: Session activated.
# Info: Sending ReadRequest.
# Info: Response received.
Read node "ns=1;s=PubString", attribute 13:
StatusCode: 0x00000000
Variant @0xb4300b58:
  TypeId 12 [dim=0]: String
  Value: "This is a text !"

Essayons maintenant de modifier l’attribut valeur de ce nœud via une requête d’écriture :

./s2opc_write --none -e opc.tcp://192.168.42.21:4841 -n 'ns=1;s=PubString' -t 12 "Hello World"
S2OPC write demo
# Info: Session activated.
# Info: Sending WriteRequest.
# Info: Response received.
Write node "ns=1;s=PubString", attribute 13:
  StatusCode: 0x00000000

La réponse à la requête contient un StatusCode de valeur 0, ce qui confirme que l’opération est un succès.

Une nouvelle demande de lecture nous permet de vérifier que le changement de valeur a bien été pris en compte :

./s2opc_read --none -e opc.tcp://192.168.42.21:4841 -n 'ns=1;s=PubString' -a 13
S2OPC read demo.
# Info: Session activated.
# Info: Sending ReadRequest.
# Info: Response received.
Read node "ns=1;s=PubString", attribute 13:
StatusCode: 0x00000000
Variant @0xb4300b58:
  TypeId 12 [dim=0]: String
  Value: "Hello World"

Les opérations précédentes ont été réalisées sans signature ni chiffrement des échanges. Comme nous l’avons vu plus haut, le serveur expose d’autres « endpoints » incluant de la sécurité. En passant par ceux-ci, il est possible de réaliser les mêmes opérations que précédemment.

Par exemple, la même requête de lecture en signé et chiffré peut être envoyée comme suit :

./s2opc_read -e opc.tcp://192.168.42.21:4841 -n 'ns=1;s=PubString' -a 13 --encrypt --client_cert=./client_public/client_2k_cert.der --client_key=./client_private/client_2k_key.pem --server_cert=./server_public/server_2k_cert.der
S2OPC read demo.
# Info: Session activated.
# Info: Sending ReadRequest.
# Info: Response received.
Read node "ns=1;s=PubString", attribute 13:
StatusCode: 0x00000000
Variant @0xb4400b58:
  TypeId 12 [dim=0]: String
  Value: "Hello World"

Ces binaires OPC UA client de démonstration utilisent tous la politique de sécurité Basic256Sha256, ce qui correspond à un « endpoint » du serveur que nous avons découvert.

Les sources de S2OPC contiennent deux jeux de clés/certificats pour le client et le serveur qui diffèrent sur la longueur de la clé privée : 2048 bits pour le premier et 4096 pour le second. Les clients de démonstration utilisent par défaut la version 4K (ou 4096) alors que le serveur est programmé avec le 2K (ou 2048). C’est pourquoi nous précisions dans la ligne de commande que le client doit utiliser la version 2K.

Un point intéressant à noter est le fait que Wireshark possède nativement un dissecteur OPC UA qui est bien utile pour diagnostiquer les échanges entre un client et un serveur. Voyez par exemple ce qui se passe lors de la précédente lecture de nœud en clair.

Cela nous permet de visualiser les différentes étapes :

  • ouverture d’une « secure channel » ;
  • ouverture d’une session ;
  • appel au service de lecture ;
  • fermeture de la session ;
  • fermeture du secure channel.

wireshark none-s

Figure 2

Si vous réalisez l’opération identique en mode signé et chiffré, vous obtenez les traces suivantes.

wireshark encrypt-s

Figure 3

Vous remarquez que tous les échanges à partir de l’ouverture du « secure channel » sont identifiés comme « UA Secure Conversation Message ». Ceci est logique, car tous ces échanges sont chiffrés à notre demande et Wireshark ne possède pas les informations nécessaires pour décoder ces messages.

Conclusion

Vous avez pu découvrir dans cet article une introduction rapide au framework OPC UA ainsi que quelques exemples de mise en œuvre. Le sujet de l’OPC UA est si vaste que nous n’avons pu voir qu’une petite partie des concepts. J’invite les personnes intéressées par un approfondissement à consulter les ressources mises en ligne par la fondation OPC [1].

Les ressources mises en œuvre dans cet article sont disponibles sur le GitLab du projet [2]. Nous vous encourageons à vous approprier les différentes applications de démonstration mises à disposition. Et pour les plus courageux d’entre vous, nous accueillons toujours avec plaisir de nouveaux contributeurs.

À toutes fins utiles, j’aimerais enfin signaler que les applications utilisées dans cet article ont été développées avec un unique objectif de démonstration. Dans le cadre d’un déploiement industriel, d’autres aspects sont à prendre en compte, notamment vis-à-vis des contraintes de cybersécurité (création, déploiement, stockage et renouvellement des certificats, gestion des utilisateurs…).

Références

[1] Fondation OPC : https://opcfoundation.org

[2] Analyse du BSI : https://opcfoundation.org/security/

[3] Spécifications du protocole OPC UA : https://opcfoundation.org/developer-tools/documents/

[4] Base GitLab du projet S2OPC : https://gitlab.com/systerel/S2OPC

[5] Wiki du projet S2OPC : https://gitlab.com/systerel/S2OPC/-/wikis/compilation#compilation-on-linux

[6] Projet Zephyr : https://docs.zephyrproject.org/latest/getting_started/index.html



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Le combo gagnant de la virtualisation : QEMU et KVM

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

Les listes de lecture

7 article(s) - ajoutée le 01/07/2020
La SDR permet désormais de toucher du doigt un domaine qui était jusqu'alors inaccessible : la réception et l'interprétation de signaux venus de l'espace. Découvrez ici différentes techniques utilisables, de la plus simple à la plus avancée...
8 article(s) - ajoutée le 01/07/2020
Au-delà de l'aspect nostalgique, le rétrocomputing est l'opportunité unique de renouer avec les concepts de base dans leur plus simple expression. Vous trouverez ici quelques-unes des technologies qui ont fait de l'informatique ce qu'elle est aujourd'hui.
9 article(s) - ajoutée le 01/07/2020
S'initier à la SDR est une activité financièrement très accessible, mais devant l'offre matérielle il est parfois difficile de faire ses premiers pas. Découvrez ici les options à votre disposition et les bases pour aborder cette thématique sereinement.
Voir les 33 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous