"Ultimately, implementations with MQTT are initially much cheaper and sometimes faster." One likes to argue in one way or another. But isn't it more expensive in the end if every adjustment means additional work and everyone involved has to be called to the meeting again to coordinate the data model and interfaces? Let's look at this point from our personal perspective in a direct comparison between MQTT and OPC UA and what both together can make for a good team for a step-by-step transformation.

 

OPC UA makes IIoT better

As Isao Hirooka describes it in the current edition of InTech 2022-02 (ISA), OPC UA enables a number of ready-made interfaces between industrial partners. The information models specified by OPC UA form the added value for these interfaces. Every participant in the network can obtain information and if everyone adheres to the applicable specifications, then the programs, devices and developers can already achieve and implement a lot without changing another document.

 

The "digital twin" is part of the IIoT

Commissioning is possible digitally and the first test of the system between PLC and PC only needs a few small adjustments for the mechanical gaps in the new process control, which could not be physically implemented in the previously used simulation. "Digital twin" as a new part in IIoT enables the entire life cycle from idea to commissioning and back to development with the gaps in the real world in "luggage" to close them forever. This results in a very stable integration, so that our customers can test how the system would run even without a PLC or a piece of sheet metal.

 

The information model

Yes, this word sounds very abstract to many and not everyone can find an exact idea of ​​it before they have even seen it and explained it using an example. You can explain the information model very precisely with your file explorer or file manager in the operating system. There are groups of data - the folders - in the folders there are other folders or files or packed data as ZIP files etc. and it is best to have a descriptive name for all entries in the file structure so that we know exactly what it is even after a long time we put here.

Files have different types - EXE, JPG, ZIP, ISO - each type has a specific way of using this data and how to handle reading and writing. Exactly what your file system offers, also offers an information model in OPC UA, including a ready-made interface to be able to transport and exchange this data from the information model via web technologies.

Whether video streams or images, firmware or updates, whether temperature or historical average per day for a month - OPC UA offers a lot of data structures and data types that you or the integrator of your choice can use "out of the box".

MQTT Sparkplug doesn't go quite as far as OPC UA, but Sparkplug is a very important extension that you should demand for your MQTT solutions. As with OPC UA, an explorable data structure is also created here as a hierarchy, which from our point of view is very useful and important for AI applications and cloud services. Configuring instead of programming is the motto and that saves a lot of time and money in the long run.

 

IIoT and specifications

The specifications of OPC UA and MQTT Sparkplug are certainly "a blessing and a curse at the same time", but we are very sure that everyone from the respective subject will ultimately find that their data, using the specifications of their subject, is good or even are better organized. After all, a few smart people in the field have already found it right and important. That is - from my own experience - a lot of time from professionals that you basically get "as a gift". If the gap is too big for your application, everyone can contribute and expand the specifications with the respective working groups.

 

MQTT makes everything easier

Well, that all sounds nice. But why not just MQTT and data structures in JSON. First of all, it should be briefly mentioned that MQTT and OPC UA complement each other well and are not mutually exclusive. Together they form a "dream team" for us personally. Because even if we prefer to use OPC UA, we are always in contact with MQTT brokers. Because OPC UA is not just a protocol like MQTT is. OPC UA is a web technology that connects protocols such as HTTP and MQTT. Should the new QIC or TSN become important for the industry tomorrow, I am very sure that you will get this connection with OPC UA and, in the best case, again "out of the box" simply with the next version and a little configuration effort.

 

Drawback for IIoT

We see the biggest disadvantage for you if you only want to use MQTT purely and then later it becomes more complex or the demands increase. There is then a lot of discussion and testing, which has long been done in the working groups and you bear the costs for the technicians and programmers racking their brains over the next "good" solution. This can set you back a lot in terms of time and reduce your competitiveness. This can then be the case every year with every adjustment and it becomes expensive and maybe even more expensive than if you had relied on OPC UA and MQTT together.

 

IIoT needs LTS

Especially in industry, you should insist on Sparkplug for MQTT. The OPC UA model specifications can also be used in JSON format via MQTT from the first implementation. This does not necessarily require OPC UA. This facilitates the later, step-by-step integration or connection of OPC UA and MQTT solutions. In addition, you can use the specifications to be compatible with new solutions later, because for OPC UA there is always a look at the "Long-Term Support" (LTS). After all, you want to be able to use your solutions a little longer and the industry needs LTS solutions for the return-of-invest (ROI)

 

Use MQTT Sparkplug and OPC UA

From our personal experience with OPC UA and MQTT - the better both are in terms of integration, the more costs you save. The initial savings in MQTT and JSON integrations can quickly drive you to develop from scratch or require constant integration work and support, which can end up causing a lot of costs. There are specific run-time security, software and hardware requirements in the industry. Because a standstill often costs more than good integration with appropriate fault-tolerance handling.

 

Costs and licenses

We can offer and build OPC UA solutions to our customers without them having to become a member of the OPC Foundation or paying annual fees. With us, you go a little easier, because we have more than a decade of experience with programming for industry using OPC, OPC UA and MQTT.

 

Releases, updates and containers

We use C# .NET 6.x or 3.1 Core dotnet for software development. You will receive platform-independent software from us and if possible directly in the container. You also have a choice, because we also offer NodeJS and Rust for programming your solutions. If you wish, we are very flexible on this point.

Containers save installation effort and make it possible to reduce the risk of commissioning and adjustments. If the new part of the system still has mechanical errors, we simply switch the container of the last running version back on and we continue. If the status is improved, then the newest container can be activated again and you can start a new mechanical test.