Alternative to OPC-UA

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.

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

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.