Alternative à OPC-UA

OPC-UA comporte des parties très intéressantes, notamment en ce qui concerne la modélisation de l'information, l'interopérabilité et le modèle de publication/Abonnement.

cependant, même s'il s'agit d'une norme au sens strict, j'ai découvert que pour l'utiliser dans une webapp, il faut coder un serveur de passerelle. Parce qu'il utilise des sockets raw et un protocole de sérialisation binaire (bien que rapide).

C'est pourquoi nous avons créé un protocole alternatif appelé Woopsa dans mon université. Nous avons décidé de baser il est sur HTTP + JSON. Nous avons essayé de faire un protocole similaire à OPC-UA: il comporte la modélisation de L'Information, la publication/souscription, et même des multi-requêtes. C'est complètement open-source.

Nous venons de publier la version 1.0 ici: http://www.woopsa.org/

Vous pouvez obtenir le code source directement sur notre GitHub: https://github.com/woopsa-protocol/Woopsa

fondamentalement, notre protocole est juste une API RESTful standardisée utilisant HTTP + JSON. Par exemple, vous pouvez lire une valeur en faisant un GET /woopsa/read/Temperature et il va vous répondre en JSON:

{"Value":24.2,"Type":"Real"}

vous pouvez aussi obtenir l'arbre des objets en utilisant le meta word, par exemple: GET /woopsa/meta/ qui va vous donner quelque chose comme ça:

{
  "Name":"WeatherStation", 
  "Properties": [
    {"Name":"Temperature","Type":"Real"},
    ...
  ],
  "Methods": { ... }
  "Items": [ 
    "Thermostat",
    ...
  ]
}

dans une application industrielle pratique, le MQTT n'est pas une alternative à L'OPC-UA. L'objectif initial du CPVP, dans les années 90, était de fournir un mécanisme de communication et un modèle de données normalisés qui assureraient l'interopérabilité entre les clients et les serveurs qui mettaient en œuvre la spécification. OPC-UA étend et généralise le modèle de données et la communication sans renoncer à cet objectif fondamental. Pour ce faire, la norme doit spécifier des choses comme le format d'un timbre de temps, la encodage des types de données, des valeurs historiques, des alarmes, etc.

MQTT est une couche de transport de messages qui n'assure pas l'interopérabilité de par sa conception. Il ne stipule pas le format de la charge utile, ne spécifie pas comment on transmet un type de données particulier, horodatage, valeur, hiérarchie, ou quoi que ce soit d'autre qui permettrait à une application de comprendre les données transmises. Vous pouvez créer un serveur MQTT valide qui émet XML, JSON, ou des données formatées personnalisées qui sont en clair-texte, crypté, base-64 encodé, ou tout ce que vous voulez. La seule façon dont une application client peut interagir avec votre serveur est de savoir à l'avance quel format de données le serveur va produire et accepter.

OPC-UA a récemment introduit un mécanisme de publication/abonnement pour améliorer l'utilisation de la bande passante, réduisant ainsi l'avantage de la bande passante de communication que MQTT offre actuellement. En même temps, la spécification MQTT devra se développer pour spécifier les formats de données afin de promouvoir interopérabilité. On peut s'attendre à une convergence de fonctionnalité entre MQTT et OPC-UA, la plupart du temps MQTT se développant pour répondre à OPC-UA.

MQTT est une implémentation beaucoup plus simple pour le moment, qui présente des avantages pour les systèmes embarqués et à ressources limitées. L'ajout d'une spécification de modélisation des données réduirait cet avantage.

le résultat est que OPC-UA est pour l'interopérabilité et MQTT est pour la communication personnalisée simple. MQTT doit pousser avant de pouvoir être une alternative à L'OPC-UA.

le MQTT est de plus en plus populaire comme protocole de choix pour I. O. T. Elle a ses limites, mais sa simplicité est souvent perçue comme une force, tandis QU'OPCUA prend en charge la conception par Comité.

Si vous avez besoin de combiner les deux, vous pouvez envisager d'essayer notre simple passerelle mqtt2opcua

Unserver est un produit conçu pour résoudre le problème décrit dans cette question.

il est capable de communiquer avec différents périphériques de terrain et de fournir une API HTTP unifiée sur dessus d'eux. Il s'intègre avec des périphériques via Modbus RTU, mais d'autres protocoles communs seront ajoutés à l'avenir.

en bref, vous configurez d'abord un 'tag' de données comme ceci:

{
  "name": "tank1", 
  "device": "plc1", 
  "properties": [
    { 
      "name": "level", 
      "address": "HR0", 
      "type": "numeric", 
      "raw": "int16"
    }
  ]
}

alors vous pouvez travailler avec la balise en utilisant un endpoint API créé automatiquement:

GET http://localhost:9000/tags/tank1

{
  data:{
    level: 1
  }
}

découvrez le documentation pour plus d'info. Le produit est disponible gratuitement pour évaluation et utilisation non commerciale.

Disclaimer: je fais partie de l'équipe. Espérons que cela est utile.