Alternative to OPC-UA [closed]

Question

Is there any decent alternative to OPC-UA as a solution for accessing process data of a system composed of various PLCs? Something that is platform independent and can "speak" with products of different brands ?

I've heard of MQTT but it seems to be much more like a transport protocol, and only that. It does not have all the higher level stuff like the information modeling, etc.

Stonedeaf

if you are not concerned about exposing Information mode and you just need to have a communication with the machine at only a few data point I would never suggest using OPC UA rather I would go for AMQP MQTT or any other messaging protocol because the sole purpose of OPC UA standard doesn't fit in this situation. – Ruffle

Answer 1

OPC is the only standard way for communicating with PLCs. OPC DA is the old alternative. OPC UA is the new one and recommended, nowadays. Before OPC there was just proprietary protocols and shared protocols like Modbus, but they are just lower level transport protocols as you've mentioned.

OPC UA is pretty unique with the Information Modeling, especially. With that feature it is enabling new communication possibilities for higher level systems and applications as well, in addition to plain PLC communication.

Note that some PLCs can also talk OPC UA natively, which makes it a standard in that way.

And OPC UA is really standardised as IEC 62541, ensuring that it's independent.

Update 17/07/19: OPC UA is now defined also as the Industry 4.0 Communication as I wrote in my recent article.

Update 20/05/05: OPC UA version 1.04 defines Pub/Sub alternatives, using UDP for secure data multicast in local networks and AMQP/MQTT for secure broker based data & event delivery to cloud systems. Version 1.04 also defines a WebSocket/JSON protocol alternative, which enable easier usage in web applications. None of these are broadly available, yet, but hopefully will become popular in 2020-21 time frame.

Territus

Answer 2

In a practical industrial application, MQTT is not an alternative to OPC-UA. The original goal of OPC, back in the '90s, was to provide a standard communication mechanism and data model that would provide interoperability among clients and servers that implemented the specification. OPC-UA expands and generalizes the data model and the communication without giving up on that core goal. In order to do this, the standard must specify things like the format of a time stamp, the encoding of data types, historical values, alarms, etc.

MQTT is a message transport layer that does not provide interoperability by design. It does not stipulate the format of the payload, does not specify how one transmits a particular data type, timestamp, value, hierarchy, or anything else that would allow an application to understand the data being transmitted. You can create a valid MQTT server that emits XML, JSON, or custom formatted data that is plain-text, encrypted, base-64 encoded, or anything else you like. The only way a client application can interact with your server is by knowing in advance what data format the server will produce and accept.

OPC-UA has recently introduced a publish/subscribe mechanism to improve bandwidth utilization, reducing a communication bandwidth advantage that MQTT currently offers. At the same time, the MQTT specification will need to grow to specify data formats in order to promote interoperability. Expect to see a convergence of functionality between MQTT and OPC-UA, mostly MQTT growing to meet OPC-UA.

MQTT is a much simpler implementation at the moment, which holds advantages for embedded and resource-constrained systems. The addition of a data modeling specification would act to reduce this advantage.

The bottom line is that OPC-UA is for interoperability and MQTT is for simple custom communication. MQTT needs to grow before it can be an alternative to OPC-UA.

Becki

Answer 3

OPC-UA has some very interesting parts, especially concerning information modelling, interoperability and the publish/subscribe pattern.

However, even though it's a standard in the strictest of senses, I've found that to use it in a webapp you need to code a gateway server. Because it uses raw sockets and a binary (although fast) serialization protocol.

This is why we created an alternative protocol called Woopsa at my university. We decided to base it on HTTP + JSON. We tried to make a protocol that's similar to OPC-UA: it has Information Modelling, publish/subscribe, and even multi-requests. It's all completely open-source.

We've just released version 1.0 here: http://www.woopsa.org/

You can get the source code directly on our GitHub: https://github.com/woopsa-protocol/Woopsa

Basically, our protocol is just a standardized RESTful API using HTTP+JSON. For example, you can read a value by making a GET /woopsa/read/Temperature and it will reply you in JSON:

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

You can also get the object tree by using the meta word, for example: GET /woopsa/meta/ which will give you something like that:

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

Impolitic

"[OPC UA] uses raw sockets and a binary (although fast) serialization protocol." But since version 1.02, it also offers an XML + Soap + HTTPS protocol binding, and, as @Jouni mentioned, also a WebSocket/JSON protocol alternative as of 1.04. Does this make it overlap with Woopsa more than when Woopsa was first begun? – Myrtie

I guess it does. However, the spec for OPC-UA remains in the thousands of pages, while Woopsa fits in a single short HTML page. I would say Woopsa remains a light-weight, universal and viable alternative to OPC-UA. – Impolitic

It seems there is no mention about security/encryption in the specs: woopsa.org/specifications – Cecilececiley

Woopsa uses HTTP. As such it can be transported over HTTPS, and any authentication scheme that is supported by it can be used! – Impolitic

Answer 4

MQTT is growing in popularity as the protocol of choice for I.o.T. It does have its short comings - however its simplicity is often seen as a strength whereas OPCUA carries the overhead of design by committee.

If you need to combine the two, you may like to consider trying our simple gateway mqtt2opcua

Paris

@NZFarmer MQTT seems indeed very promising to me as an alternative to OPC/OPC-UA. However, do MQTT handle the information modeling? If yes, how? – Stonedeaf

@Stonedeaf MQTT at its core is a very pub/sub framework. Suggest you review the spec. – Paris

@NZFarmer Yes, it works in a pub/sub architecture that's fine. This answer the question How. How about the question What? I mean one of the biggest strength of OPC/OPC-UA is that it defines a presentation/modeling for the data. i.e. this kind of data will have a field value, a field timestamp, a field unit, etc. How about MQTT? Does it defines this? – Stonedeaf

@cid. "A messaging transport that is agnostic to the content of the payload" See: ibm.com/developerworks/library/ws-mqtt – Paris

Answer 5

Unserver is a product designed to solve the exact problem described in this question.

It is capable of talking to different field devices and provide a unified HTTP API on top of them. It integrates with devices via Modbus RTU, but other common protocols will be added in the future.

In short, first you configure a data 'tag' like this:

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

Then you can work with the tag using an API endpoint created automatically:

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

{
  data:{
    level: 1
  }
}

Check out the documentation for more info. The product is free for evaluation and non-commercial use.

Disclaimer: I'm part of the team. Hope this is useful.

Dickey

Answer 6

I just released another approach to this challenge. The project is called ELTRA IoT.

It's cloud service as mediator and end-user components that act as device representation or operator interface (https://www.eltra.ch/)

Primarily, it was created to simplify integration of CANopen devices with smartphone applications, but I quickly realized, that it can be used for any IoT project.

This project is inspired mainly by CANopen and FDT architecture.

The first idea was to deliver the solution, that allows bringing your device into internet using web standards like REST/JSON (avoid binary protocols, gateways, firewall, proxies issues and all this staff, that makes this whole process more complicated) within short time.

Web standard like HTTP/REST/JSON/WebSocket plays well with all operating systems and architectures and allows also easy end-user app integration in any modern language.

Main features:

• Same API both sides (device and operator)
• CANopen CiA-311 data model representation
• Nodes, object dictionary, index, subindex, strong data typing, ranges etc. You know CANopen = you are at home
• History data
• RPC support - custom commands execution
• Simple cloud service API https://eltra.ch/docs
• Standard authentication scheme
• SSL encryption
• Cross-platform solution for Windows, Linux, Android, IPhone, Raspberry PI

SDK is available as open source on Github:

https://github.com/eltra-ch/eltra-sdk

At the moment, the library is implemented in .NET Standard and tested with Windows, Linux (x64 and ARM32), Android, IPhone.

Nuget package is available under:

https://www.nuget.org/packages/Eltra.Connector/

If the complexity of OPC UA is an overkill and Woopsa doesn't fit your design, then ELTRA could be an alternative.

disclaimer: This project is part of my masterthesis and eltra.ch service is my privately held website

Anastatius