New podcast. Following up on my popular podcast on “Why Big Companies Hate OPC UA Embedded”, I review recent writing on OPC UA, REST, MQTT and Sparkplug relative to needed interoperability. I focus on watching how companies implement REST and MQTT–whether they are using an open transport to move proprietary data types, or whether they are truly embracing what end users want-true interoperability.
I’ve been writing about standards used in applications for Industrial Internet of Things and parts of the IoT ecosystem such as Big Data lately—REST, MQTT, and OPC.
Dennis Nash, president of Control Station noticed the series and called about a big data and IoT application using Control Station software as part of a system for helping engineers optimize control loops in a process plant.
Even if a plant has installed and uses an APC or MPC application, things happen that loops eventually slip out of tune. These loops can cost a plant a lot of money even though the process does not generate alarms or does not appear to be generating problems.
The system builds from historical loop change data recorded in an OSI PI historian. The data flows into a model of a tuned loop. Says Nash, “The basis for our innovation starts with a unique ability to model highly variable process data (i.e. noisy, oscillatory data). We use a proprietary method that no one has successfully emulated.”
He continues, “With the ability to accurately model highly variable data, control loop performance monitoring (CLPM) tools like ours can capitalize on the 100s/1000s of output changes that happen everyday. By aggregating the model date and comparing results with existing tuning parameters, CLPM tools are now getting into the Big Data game.”
Checking loop performance, especially when there are hundreds or thousands, rarely hits an engineer’s to-do list. This system will send a notification of worst actor loops where action can actually improve plant efficiency and profits.
This system works in a one-off application. What if there are more applications in a plant? That is where interoperability and standards come to play. Not so much a standard within Control Station, but where an application such as Control Station can use standards and data interoperability to grab data from a variety of sources. The extensive use of these standards and data interoperability enable the continual push of innovation and process improvement.
This essay is third in a series on moving data on the Industrial Internet of Things. We’ll take a look at OPC UA.
First we looked at Opto 22’s new product that provides for RESTful APIs as a way to open up information to move from platform to platform. This is relatively simple and understood by almost all recent college graduates. This method does not model data, but it can move vast amounts of data.
MQTT is a transport technology providing a low bandwidth middleware. However, developers have recently added a data model, MQTT Sparkplug. MQTT is agnostic as to the message. You can move data from all manner of sources—including OPC—using this transport. People began thinking there should be a way to describe the message within this ecosystem.
I reached out to Tom Burke, president of the OPC Foundation, for more information about how OPC UA fits into this picture.
So what is OPC UA? “OPC UA is about multivendor secure reliable interoperability for data and information integration from the embedded world to the cloud.”
The key to OPC is interoperability. It allows clients from one supplier to import data from another. Many years ago, for example, I was in the Wonderware labs. They had PLCs from almost all known suppliers. In order for its HMI/SCADA software application to work, developers had to write drivers from every one of those PLCs. With OPC, they could communicate with every OPC-enabled PLC. And so could every other supplier. It opened competition, the very thing that customers want.
That was more than 20 years ago. Today there are over 4,200 vendors who have OPC products in the marketplace. Or, as Burke puts it, “The days are over where the end users are willing to pay for multivendor interoperability by developing custom Software Solutions to integrate products from multiple vendors together.”
The OPC UA working group has already developed a simple https interface for UA that will meet and exceed the needs of many applications.
The biggest value is the data modeling/semantics OPC UA provides, followed by the security mechanisms.
I received this from the OPC Foundation:
So for any IoT application, one should ask:
OPC UA can answer all these questions.
So, you can see that there are several options. It really depends upon your data needs. OPC UA guarantees interoperability. REST and MQTT are standards in themselves, but as a user you’d have to ask your supplier if they using them in an open manner. It’s possible that they are using an open standard in a proprietary way that promotes additional system integration business.
It all sounds confusing on the surface. Like any project you’re beginning, be clear about expectations and specifications up front. And, of course, maybe a blend is just right for you.
I ran a brief series on industrial data, interoperability, and the Purdue Model (see this one, for example, and others about that time). It’s about how data is becoming decoupled from the application. It’s not hierarchical, seeking out applications that need it.
This week I took a look at Opto 22’s latest innovation—use of RESTful APIs in an industrial controller. The next step seemed to be looking at MQTT. This is another IT-friendly technology that also serves as an open, standardized method of transporting data—and more.
Then I’ll follow up on a deeper discussion of OPC and where that may be fitting in within the new enterprise data architecture.
I’ll finish the brief series with an application of (perhaps) Big Data and IIoT. It’s not open standard, but shows where enterprises could be going.
Inductive Automation has been around for about 13 years, but it has shown rapid growth over the past 5. It is a cloud-based HMI/SCADA and IIoT platform. I finally made it to the user conference last September and was amazed at the turnout—and at the companies represented. Its product is targeted at the market dominated in the past by Wonderware, Rockwell Automation RS View, and GE Proficy (Intellution iFix in a former life). It’s a private company, but I’ve been trying to assemble some competitive market share guesses. My guess is that Inductive ranks very well with the old guard. Part of the reason is its business model that seems friendly to users.
Just as Opto 22 was an early strong supporter of OPC (and still supports it), so also is Inductive Automation a strong OPC shop. However, just as Opto 22 sees opportunities for better cloud and IT interoperability with REST, Inductive Automation has seen the same with MQTT. In fact, it just pulled off its own Webinar on the subject.
I put in a call and got into a conversation with Don Pearson and Travis Cox. Following is a synopsis of the conversation. It is also a preview of the ICC user conference in Folsom, CA Sept. 19-21. At the conference you can talk to both Arlen Nipper, president and CTO, Cirrus Link and co-developer of MQTT along with Tom Burke, president of the OPC Foundation.
Don and Travis explained that MQTT itself is a middleware “broker” technology. It describes a lightweight, publish/subscribe transport mechanism that is completely agnostic as to the message contained in the communication. So, you could send OPC UA information over MQTT or other types of data. The caveat, as always, is that the application on the receiving end must speak the same “language.”
They see apps talking directly to PLCs/PACs/controllers as going away. We are in the midst of a trend of decoupling data from the application or device.
MQTT is “stateful”, it can report the last state of the device. It rides on TCP/IP, uses TLS security, and it reports by exception.
MQTT is, in itself, agnostic as to the message itself. However, to be truly useful it needs a message specification. Enter Sparkplug. This technology describes the payload. So, it is needed on both sides of the communication. it doesn’t need to know the device itself, as it is all about information. it is a GitHub project and, as is MQTT, part of the eclipse foundation.
I have known Don and Travis for years. I have never heard them as passionate about technology as they were during our conversation.
If you are coming to Folsom, CA for the conference, you’ll hear more. I will be there and would love to have a breakfast or dinner with a group and dive into a deep discussion about all this. Let me know.
I’m sitting in Ohio’s 90-degree heat instead of the 100-degrees of Austin, Texas this week. After attending 18 straight NI Week technology events, I’ve taken a break. I have two things on this post while I think through my next post on Internet of Things and communication technologies.
National Instruments has changed tremendously over the past five years or so. All the marketing and media relations people I’ve known are gone. For the first time last year, I walked into the press room and no one knew me. There were no interviews. No suggestions on finding great information. Even the keynotes no longer brought awe and spontaneous applause at the technology advances. The applause was more perfunctory.
NI is no longer family with a tremendous enthusiasm for technology advancements. It’s a big company.
I’m saving the $1,200 or so it would have cost me to go to Austin in August. I’ll be there in October for Dell World. I’ll visit the other Austin technology companies then. (And run along Town Lake–er, Lady Bird Lake, eat good barbecue, take in some music.)
I’ve been seeing news and receiving press releases from companies promoting MQTT and REST–perhaps instead of OPC UA. (More in my next post.)
So, I have been researching industrial communications–protocols, platforms, architectures, standards. OPC has been a workhorse for moving structured data from control to HMI and beyond. It is developing a publish/subscribe technology to complement its client/server technology to enhance cloud communication.
I’m seeing interest from suppliers from alternatives, or, if not alternatives, other technologies that could complement or supplant much of the work of OPC UA. MQTT, AMQP, REST, DDS. Companies are exploring them.
I wonder why? I’m interviewing many people on the subject. There is much to read.
What do you think? Send email or comment. Is there something about OPC UA that makes you consider other technologies? Why would you pick MQPP? REST is an API specification most used to get large amounts of information into Web pages. Could you use that in place of an MES? Or, to assist your MES?
There are lots of questions. I’m looking for answers. Thoughts?
I am receiving news from NI Week. Here is the first announcement.
NI announced LabVIEW 2016 system design software, empowering engineers to simplify development and effectively integrate software from the ecosystem into their systems. The latest version of LabVIEW introduces new channel wires to simplify complex communication between parallel sections of code. Available on both desktop and real-time versions of LabVIEW, the channel wire method helps improve code readability and reduces development time.
“The new channel wires in LabVIEW 2016 enable us to develop applications even faster by making architectures that are more transferable across domains,” said Christopher Relf, chief engineer at VI Engineering. “With channel wires, we can set up sophisticated software architectural patterns that natively have multiple sources, without having to create and maintain considerable amounts of custom software in the background.”
Much of the success that LabVIEW users have had relies on the openness of both the product itself and the ecosystem that supports it. LabVIEW 2016 continues this trend with enhanced interoperability with Python and third-party devices. This openness, combined with several new enhancements, helps users continue to improve productivity by streamlining code development and deployment. With the latest version of LabVIEW, users can:
