Alternative to OPC-UA

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.

Thanks for your help!

Answer 1

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.

Answer 2

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.

Also, the upcoming version 1.04 (in RC at the moment) of OPC UA will define Pub/Sub alternatives (using UDP & AMQP first MQTT later) and will also define a WebSocket/JSON protocol alternative, which will enable easier usage in web applications.

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",
    ...
  ]
}

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

Answer 5

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.