by Gary Mintchell | Sep 16, 2016 | Automation, Internet of Things, Interoperability, Operations Management, Technology
September 14-15 found me back in Chicago for the International Manufacturing Technology Show (IMTS) and an IIoT conference sponsored by OMG and IIC. I’ll have several reports even though I fly to Sacramento Sunday for the Inductive Automation Ignition Customer Conference. (I’m writing this on Friday, but it may not get posted.)
Tom Burke, OPC Foundation President and Executive Director, stopped me as I walked the aisle. He talked about the cool things happening with OMAC. I do not know the technical details, but OMAC wishes to specify (not sure of exact technical term) OPC UA into its PackML as its communications protocol.
Turns out this is much more significant than I gleaned from the press release. By the time I waded through the marketing general statements, I gave up on reading the rest. For some reason, marketing and/or PR people seem to want to hit every buzz word in the beginning of a release in order to show relevance or something and then bury the good stuff almost off-hand in the bottom of the text.
This is a significant advance for interoperability. There remains a stance in the industry for point solutions that may be based on open standards, but are explicitly not interoperable—everything is held within the kimono, so to speak. Interoperability benefits an entire industry. The more that end users buy according to interop, the faster the pace of adoption will be.
IIoT and Pack Expo
Look for OPC Foundation (booth N-4702), PLC Open (booth N-4703), and OMAC (booth N-4800) at Pack Expo the first week of November. Be sure to vote first! Personally, I am torn between going to a single-supplier event or this one. Both are too expensive for the lone entrepreneur. I’ll wind up with one, though.
The OPC Foundation provided a couple of bullet points about its news:
- the results of joined collaboration between OPCF with OMAC about PackML mapping into OPC UA namespace
- the results of joined collaboration between OPCF and PLCopen about IEC61131-3 PLCopen Client FB to allow initiating an OPC UA connection from inside the controller
OMAC and IIoT
Here is the news from OMAC. “The Organization for Machine Automation and Control (OMAC), OPC Foundation, and PLCopen are working together to help advance communications protocols necessary for the Industrial Internet of Things (IIoT) to succeed.
Interoperability among devices and machines that use different protocols is a significant challenge in realizing the full potential offered by the Industrial Internet of Things. By collaborating on companion specifications to the standards and protocols they’ve already developed OMAC, OPC Foundation, and PLCopen can advance the quality and efficiency of data sharing and communication at the machine and production line and up through the enterprise. Collaborative efforts by standards organizations, such as OMAC, OPC Foundation, and PLCopen, align with the Industrial Internet Consortium’s goal to ultimately identify and define building blocks for interoperability that make smart factories and IIoT possible.
“Standards are needed to support communications from machine-to-machine and from the plant floor to interfaces that will allow large scale data analytics and information transfer,” says John Kowal, a member of OMAC’s Board of Directors, co-chair of the Industrial Internet Consortium’s Smart Factory Task Group, and business development director for B&R Industrial Automation Corp. “It just makes sense for these organizations which have individually done so much to advance automated manufacturing to collaborate and avoid redundant developments.”
Here’s how the three automation standards leaders are bringing their efforts together. One of OMAC’s major initiatives has been promotion of the ISA-TR88.00.02 automation standard commonly known as PackML. The second generation was released last year. Manufacturers and machine builders worldwide have implemented ISA-TR88 on various control platforms to increase speed to production, ease packaging line integration and improve reliability. While PackML defines machine modes, states and tag naming conventions, it does not specify a communications protocol.
The OPC Foundation’s Unified Architecture (OPC UA) is an industrial interoperability framework. It delivers information modeling with integrated security, access rights, and all communication layers to provide plug and play machine-to-machine (M2M) communication inside factories. It is scalable across the plant floor and from sensor to IT enterprise and cloud scenarios. OPC and PLCopen recently worked together to define a set of function blocks to map the IEC 61131-3 global standard for industrial controls programming to the OPC UA information communication model. The latest version was released earlier this year. IEC 61131-3 is the only global standard for industrial control programming and is recommended by OMAC in its Packaging Guidelines document.
To take their efforts to the next level, OMAC and the OPC Foundation have established a taskforce to develop a companion specification for ISA-TR88/PackML and OPC UA by the end of 2016. The task force led by Sari Germanos, open automation manager for B&R Industrial Automation, includes members of OMAC and OPC Foundation from around the world. Participation is open to interested members of either organization.
“A standard communication protocol, used consistently across the industry, is vital for realizing the full benefits of automation standards such as ISA-TR88, which then can be a valuable data source for smart factories and the IIoT,” says Dr. Bryan Griffen, OMAC Chairman and Nestlé Group Engineering Manager. “A companion specification between ISA TR88 and OPC UA fills this need and builds on the work completed with PLCopen earlier this year. The opportunities to transform manufacturing as hardware and software solutions are integrated through consistently applied, standardized protocols are extraordinary. We’re pleased to be a part of those efforts worldwide.”
“Today, there is more reason than ever to believe that communications standards will proliferate, as the IIoT drives the need to flatten network communication architectures,” says OPC Foundation Director Thomas Burke. “Along with organizations like OMAC and PLCopen, we’re actively engaged to do just that.”
“By collaborating and ensuring the standards we’ve developed work together we ensure transparent and fully secured communication right out of the box with standardized access between any OPC client and server via a secure channel, independent from network architecture and protocol or machine type and controls,” says PLCopen Managing Director Eelco van der Wal.
by Gary Mintchell | Aug 15, 2016 | Data Management, Internet of Things, Interoperability, Manufacturing IT, Operations Management
Programming the Industrial Internet of Things is getting interesting. After the Opto 22 news on REST and Node_RED along with the Inductive Automation conversation on using MQTT middleware and Sparkplug for data description, I’ve dived into these technologies.
These things are all standards and widely used. Some have been around for a little while. I’ve got to say that Node_RED is really cool. And as open source, it has a fantastic library of functions.
How used?
So, my next question is, “How are these used?”
And mainly I am comparing to OPC UA.
I have been in conversation with several people from the OPC Foundation. They told me, “OPC UA is about multivendor secure reliable interoperability for data and information integration from the embedded world to the cloud. It’s more than just a communication protocol for moving data between points a and b.”
Granted, OPC UA is based upon XML technology, not JSON. It is XMPP. There were probably many good reasons for using this at the time the specification for OPC UA was being designed. For one thing, it is secure. Build in. And security is a major point of discussion when you talk with OPC people.
But, let’s talk about the multivendor and interoperability issues. When data is described in OPC UA, any other OPC UA device knows what is in the information packet. That is a power that many vendors–but especially end users–were searching for. Interoperability is the method that many industries have used for growth and innovation. Think railroads or cargo containers, for example.
So, even though REST, Node_RED, JSON, MQTT, and Sparkplug are all in themselves open, I throw the ball back into their court.
Is the principal use of these technologies for tying proprietary applications and devices together so as to lock out competition? To what degree is there an industry movement to describe devices and information in an industry-wide manner such that an interoperability of devices may be obtained?
I suppose there is a side note that I hear from some quarters about using open technologies, but using them in such a way that a customer is locked into one system integrator. Although this does not look so complex as to lock a customer in, it’s a question I need to ask.
I guess as the ad says, “Inquiring minds want to know.”
by Gary Mintchell | Aug 8, 2016 | Internet of Things, Interoperability, Operations Management, Software, Standards
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.
The Grandfather of them all
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:
- How do you model/describe your data?
- How do you store your data?
- How do you authenticate?
- How do you encrypt?
- Where do you store your secrets?
- What do you use for transport?
- Who/what can you connect to?
OPC UA can answer all these questions.
Choose wisely
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.
by Gary Mintchell | Aug 5, 2016 | Automation, Internet of Things, Operations Management, Technology
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.
MQTT and Sparkplug
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.
Describing the message
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.
by Gary Mintchell | Jun 28, 2016 | Automation, Networking, Operations Management, Standards, Technology
I’ve decided not to try to publish bunches of news for bunches of posts per day. It’s not quantity I’m looking for–and I get the feeling neither are you. Besides, according to some of my sources of statistics, readership of this blog is about half of the big magazines in the space. Not bad considering that half or more of their views come via search–and they have tons more stuff to search.
Tom Burke, president of the OPC Foundation sent this article describing the latest protocol advancement it is working on. It is a publish/subscribe protocol that lets OPC UA and messaging protocols such as AMQP and MQTT play nicely with OPC. This gives users the benefits of both types of messaging. Certainly a winning proposition. In fact, I had been wondering about the OPC response to MQTT which is popping up more frequently.
OPC UA PubSub: Bringing the Power of the Cloud to Industrial Automation
Many OPC systems today have a small number of HMIs or SCADA applications which manage a larger number of devices. In some cases, MES systems and ERP systems are part of the picture and use OPC interfaces to collect data from the factory and send it on to enterprise applications. This model works well for many applications and will continue to be a mainstay of many industrial automation users which have a lot of equipment installed in a single location that needs to be managed. However, the widespread deployment of cloud based solutions has many factory operators wondering how they can take advantage of it to streamline their operations. The needs of these users have been the driving force behind the new OPC UA PubSub Specification. This specification layers OPC UA on top of message based middleware such as AMQP or MQTT in a way that allows users to take advantage of OPC UA features such the robust information modelling framework while adapting to the message centered communication paradigm of the middleware.
Use OPC UA PubSub to Broadcast Data and Events to the Cloud
OPC UA PubSub defines a loosely coupled message protocol that can be used with multiple encodings (e.g. JSON, UA Binary or XML) and multiple transports (e.g. AMQP, MQTT, XMPP et. al.). Applications which publish information create data or event subscriptions as they would for normal OPC UA communications and forward the notifications produced to the Message Oriented Middleware. Applications which consume information create subscriptions with the Message Oriented Middleware which will forward the messages to them as they arrive. The OPC UA PubSub Specification defines a format for these messages that allow them to be consumed by subscribers who have no knowledge of OPC UA and no ability to connect to the publisher (Figure 1).
The middleware in these cases may support durable queuing, multicast and/or filtering which allows OPC UA data or events to reach a much larger variety of applications including big data applications which depend on a supply of real time data from the factory.
Data is not Enough: OPC UA Extends its Information Model to the Cloud
The raw data in messages produced by publishers can have a structure which can be understood by subscribers which have no access to information other than the message. However, the metadata associated with the message can provide important additional context which allows the subscribers to properly interpret the message. To facilitate this OPC UA PubSub defines a metadata message that can be delivered using the same middleware broker infrastructure. These messages also allow the publishers to instantly report changes to their configuration which affects the content of the messages. Each message published includes an identifier for the metadata version that applies to the message which ensures that subscribers can easily detect and manage changes to the metadata.
End to End Security: Cloud Services run by Third Parties may not be Secure Enough
The Cloud relies on infrastructure provided by vendors that specialize in providing large scalable systems. However, the nature of the Cloud means these third parties will have access to the data even if the communication between the application and the broker is secure. OPC UA PubSub provides for end-to-end security which ensures that only applications authorized by the operators will be able to view or modify the data no matter how many intermediaries are required to deliver the data. OPC UA PubSub includes a key distribution model that allows loosely coupled applications to share keys as needed (Figure 2). Access to the Security Key Servers is controlled using web based standards for federated identity management such as OAuth2. For example, a factory owner can use the OAuth2 support built into Active Directory to provide authorization services for their Security Key Servers. This access will be independent of the middleware used to deliver the messages to their intended recipients and allows for access to be granted or revoked as needs evolve.
Figure 2 – OPC UA PubSub End-to-End Security Model
OPC UA PubSub: A Flexible solution that can Evolve
Different middleware vendors want operators to commit to using their protocol for their operations. OPC UA PubSub provides a framework for simultaneously supporting multiple protocols as the needs of factory owners evolve while providing a standard architecture for describing complex information. Figure 3 illustrates how this works in practice where a Machine Vendor uses MQTT to communicate with its machines deployed in a customer’s factory while the Factory Operator uses AMQP to capture analytics. In both cases, the data being sent to the Cloud is based on OPC UA PubSub and conforms to an OPC UA Information Model. The bottom line for factory operators is OPC UA reduces costs and provides greater flexibility by allowing factory operators to focus on information their enterprise needs instead of the protocol needed to move the information between systems.
Figure 3 – OPC UA PubSub a Flexible Framework that Evolves as Needs Change
