by Gary Mintchell | May 4, 2016 | Automation, Technology
Do we need an OPC UA replacement?
I’ve gone from one trip to another and had some allergy attacks in the middle. That’s my excuse. So I’m catching up on Hannover news plus my experience as an ERP analyst (not) at the QAD user conference
I didn’t intend to lead with this one, but for the first time in a while I’ve hit a bit of controversy. My YouTube video essay on the subject garnered my first “like” and first “dislike”. Read and listen and decide who might not like the analysis.
CIP Cloud Interface
In surely the most discussed announcement in automation at Hannover, ODVA announced a “significant” new area of technical work to develop standards for the gateway and interface technology needed to transport data between the cloud and CIP-enabled industrial control systems (ICS) populated with EtherNet/IP and DeviceNet devices. “Ultimately, this work will result in The Common Industrial Cloud Interface Specification, a major new addition to ODVA’s technology portfolio.”
This is from the press release: ODVA’s scope of work for developing the Common Industrial Cloud Interface will encompass two elements in the ecosystem for the industrial cloud: a cloud gateway appliance (Gateway) and an application program interface (API) for the transport of data from the Gateway to the cloud and from the cloud back to the ICS and its devices. Based on open and interoperable standards supported by multiple vendors, ODVA’s new Common Industrial Cloud Interface will accelerate an architectural transformation inclusive of cloud computing to support device management, process analytics, notifications, remote access, virtualization, visualization and, in the future, control.
“The Common Industrial Cloud Interface will enable an enterprise architecture inclusive of cloud computing resources, based on industry standards, and will optimize high performance, secure communications between devices, an ICS and the cloud, as well as simplify common tasks that must be performed by the Gateway. ODVA’s view of its cloud ecosystem is agnostic with respect to the deployment of cloud computing resources in off-premise, on premise, public, private and/or hybrid models. Furthermore, ODVA‘s scope of work for its Common Industrial Cloud Interface excludes services and applications within the cloud itself.“
Replacing OPC UA Embedded?
As the press conference proceeded, attendees became aware that this work is a direct attack on OPC UA. Several major automation technology vendors have voiced disappointment with the embedded version of UA seeing it a a threat to their own messaging protocols.
This is typical of the open standards movement. End users and owner/operators love them. Suppliers try to finesse them away. Only today I heard about a Microsoft response to IFTTT designed to give the same functionality while keeping users within the Microsoft ecosystem. It’s a never-ending battle for users of technology. I think for the 13 years I’ve been writing here that I’ve been consistently on the side of users. Suppliers can develop lots of value add while giving users some freedom for their own innovation.
I asked Rockwell Automation for comment since it is seen as the internal champion for this SIG. It sent this carefully constructed statement:
At Hannover last week, ODVA announced a significant new area of technical work to develop standards for the gateway and interface technology needed to transport data between the cloud and EtherNet/IP and DeviceNet devices. Ultimately, this work will result in The Common Industrial Cloud Interface Specification, a major new addition to ODVA’s technology portfolio.
ODVA’s cloud announcement does not diminish Rockwell Automation’s support for OPC – as demonstrated by Rockwell’s active role within the OPC UA Technical Advisory Committee and the Specifications Working Group. Similarly, it does not diminish Rockwell Automation’s support for other global standards, as it has experts, project leaders, conveners, secretaries and chairpersons on many of the global standards committees, such as the IEC Strategic Group (SG8) focused on Industry 4.0/Smart Manufacturing.
The ODVA announcement simply outlines ODVA’s plans to offer the best solution to connect the world of EtherNet/IP and DeviceNet with the cloud. This will further support EtherNet/IP and DeviceNet customers in configuring devices and streaming data. Because of the benefits this will bring customers, the initiative is supported by the full ODVA board, including Bosch Rexroth, Cisco, Endress+Hauser, OMRON, Rockwell Automation, Schneider Electric, and Weidmuller.
This continued innovation is why recent studies by HMS, IHS, and others show that EtherNet/IP is the leading Ethernet network, followed by Profinet, EtherCAT, Modbus-TCP and Powerlink.
A couple of comments. First, notice that Rockwell’s support for OPC and other open standards is limited to participating at the technical committee level. Therefore, it learns the technology, but notice nowhere in this statement is it suggested that Rockwell will actually implement these open standards.
And, in the end, will it really matter? If you are in the Rockwell Automation ecosystem, then it becomes easy to continue to tie yourself to it. If you are not, you’ll not use it. If you’re on the fence, you’ll have to decide. Probably a little of both.
You can see my comments on YouTube or listen on my podcast. And you can vote on YouTube thumbs up or down. It should be interesting.
by Gary Mintchell | Apr 12, 2016 | Automation, News, Organizations, Technology
Quite a deluge of press releases coming
from the OPC Foundation preparing for the upcoming Hannover Messe. Microsoft was an original OPC supporter, and here a new representative from the company has joined the Board. Key to the announcement is OPC UA communication into the Microsoft Azure cloud.
The OPC Foundation has elected Microsoft to the Board of Directors of the OPC Foundation, which represents many of the world’s most prominent global suppliers. The new board seat, which will be held by Microsoft Director of IoT Business Development Matt Vasey, is an extension of Microsoft’s support for OPC Foundation since the company first became a member in 1995.
Microsoft’s longstanding commitment to interoperability and the OPC Foundation includes the OPC technology portfolio and OPC-UA, active participation in the OPC Foundation technology working groups, and ongoing representation on the OPC Foundation Technical Advisory Council.
“OPC-UA is an essential component of the connected products that manufacturing customers need today, and it is increasingly seen as an important part of enterprise IoT scenarios and business models,” said Matt Vasey, Microsoft Director of IoT Business Development. “I am personally excited to be working with the OPC team to help our customers unlock the value of these high-value IoT scenarios that span from the edge to the cloud. Microsoft is committed to openness and collaboration and fully supports OPC-UA and its evolution.”
“OPC-UA is widely recognized as a key communication technology for the Industry 4.0 initiative,” says Thomas J. Burke, OPC Foundation President & Executive Director. “Microsoft’s support for standards that foster IoT innovation, and specifically for OPC and OPC-UA, result in easy, direct and secure communications from PLC controllers on the shop floor to the top floor world of IT.”
“It’s a great honor to have Microsoft join the OPC Foundation Board of Directors, and we welcome Matt Vasey’s outstanding efforts to facilitate the acceleration of OPC UA as the solution for the Internet of Things,” added Burke.
“As one of the largest IT/Cloud companies, Microsoft joining the OPC Foundation board demonstrates its recognition of the role that OPC UA plays from plant floor to enterprise connectivity and IIoT for industrial automation and beyond”, according to Craig Resnick, Vice President, ARC Advisory Group. “From OPC’s perspective, having Microsoft as part of its board makes sense based on its long history of working with the OPC Foundation as well as its deploying scalable OPC UA connectivity solutions ranging from the sensor to the IT/enterprise and cloud. From Microsoft’s perspective, being part of OPC’s Board shows its commitment to openness for connecting platform independent architectures to its cloud systems, collecting data and providing its Azure cloud services for multiple operating systems beyond just Windows.”
Matt Vasey is currently responsible for IoT business development at Microsoft, working with a cross-functional team to continue to build out the ecosystem of technology partners, standards bodies, and other innovation catalysts that are required for the new generation of IoT applications, services, and systems that serve both individuals and businesses. He also serves as an officer and board member on the OpenFog Consortium, and was instrumental in the formation of this organization working closely with other founders from Intel, ARM, Cisco, Dell and Princeton University.
In addition to Mr. Vasey and Mr. Burke, the OPC Foundation Board includes Russ Agrusa, Founder and Chief Executive Officer of ICONICS; Matthias Damm, President of Ascolab; Stefan Hoppe Senior Engineer of Beckhoff Automation and OPC Vice President, Thomas Hahn, Chief Software Expert at Siemens AG and OPC Vice President, Shinji Oda is General manager, Technology Marketing of Yokogawa Electric Corporation; Veronika Schmid-Lutz, Chief Product Owner for manufacturing products at SAP SE and Ziad Kaakani, Global System Engineering and Architecture, Honeywell Process Solutions.
by Gary Mintchell | Apr 8, 2016 | Automation, Internet of Things, Interoperability, Networking, Operations Management
I have been discussing the importance of industrial protocols to successful use of the Industrial Internet of Things. Among three news releases from the OPC Foundation is news about collaborative work between the Object Management Group (OMG) and OPC Foundation to let DDS and OPC UA play nicely in the same sandbox. This is key because the Industrial Internet Consortium has adopted DDS as a standard, while much of the industrial automation community uses OPC.
Other news includes the announcement of support for publish/subscribe for OPC UA and an OPC UA open source initiative.
Industrial Protocol Collaboration
Specifically, the OPC Foundation and OMG have developed a technical positioning and FAQ document for usage of both the OPC Unified Architecture (OPC UA) and the OMG Data Distribution Service (DDS) standard. The positioning document explains that the OPC UA and DDS standards are largely complementary and compatible. Both are important to the future of the IIoT. The document is a joint recommendation; it helps companies quickly implement an IIoT strategy.
OPC UA and DDS Explained
OPC UA is an industrial communication architecture for platform independent, high performance, secure, reliable, and semantic interoperability between sensors, field devices, controllers, and applications at the shop-floor level in real-time as well as between the shop floor and the enterprise IT cloud. OPC UA allows SoA based easy “plug and produce” scenarios. The information about the system, its configuration, topology, and data context (the meta data) are exposed in the collective “address space” of the individual OPC UA servers.
This data can be accessed by authorized OPC UA clients that can see what is available, and choose what to access. OPC UA truly supports timeless durability as new networking technology is developed it can be plugged into OPC UA seamlessly. Client/Server, Pub/Sub and cloud protocols are integrated into OPC UA.
DDS provides location transparent, interoperable, secure, platform independent, real-time data sharing across any kind of network. DDS lets applications define and share user data with controlled “Quality of Service” (QoS) such as performance, scalability, reliability, durability and security. DDS hides network topology and connectivity details from the application, providing a simple yet powerful data-sharing abstraction that scales from local area networks to fog and cloud computing. It can support even large fan out and sub-millisecond latency. DDS defines a “common data-centric information model” so that applications can run “plug & play” with very little or no deployment configuration. System configuration details are deemphasized to ease redundancy and interoperability.
Today, there is little overlap between OPC UA and DDS in applications. Even when used in the same market (e.g. energy) the use cases are quite different. Today OPC UA provides client-server interaction between components such as devices or applications. DDS is a data-centric “bus” for integration and peer-to-peer data distribution. Because the focal applications and approaches for DDS and OPC UA are different, most applications clearly fit better with one or the other.
The OPC Foundation and OMG are working together on integration and have developed two ways for the technologies to work together. First, an “OPC UA/DDS gateway” will permit independent implementations to work together. Second, “OPC UA DDS Profile” will enable integrated use cases. Initial work to define both approaches is underway at the two standards organizations.
Customers must choose a standard path now to implement a successful IIoT strategy. By working together, the OPC UA and DDS communities will provide a non-proprietary path to interoperability, regardless of the customer’s choice of starting technology.
Open Source OPC UA
The open source repository of OPC UA is now available on the open source GitHub web site. Open source is a very important strategy to eliminate roadblocks to adoption of the technology. By open sourcing the OPC UA technology the OPC Foundation is now enabling easy access to the technology by academia and research organizations, as well as many suppliers and end-users that would like to assess the OPC UA technology as part of early adopter and feasibility analysis.
Open sourcing isn’t just the wave of the future. Open source strategy is now. The OPC Foundation is proud to make the OPC technology available to everyone via the open source repositories.
There are a number of OPC open-source initiatives already available from suppliers, research institutes and academia for OPC UA. The open source repository from the OPC Foundation is intended to supplement these other open-source initiatives, providing additional value. The OPC Foundation has committed resources to moderate/maintain and extend the technology to keep pace with technology changes in the industry as well as the extensions to the OPC UA architecture and corresponding companion specification.
Publish Subscribe
The OPC Foundation addition of publish/subscribe communication functionality to OPC UA provides the necessary infrastructure to achieve seamless interoperability for IIoT, IoT, and industrie 4.0 applications and devices. OPC has been based on a client/server architecture, and is now enhancing the architecture with the inclusion of publish/subscribe to provide a solid infrastructure that allows information integration from embedded devices to the cloud.
The OPC Foundation is working currently with 42 international (and many more to be added) suppliers that are developing products and solutions for the IIoT and needed to provide publish/subscribe to the technology portfolio to facilitate high-performance high reliable device application connectivity for this important market. Support for publish/subscribe as well as the client/server architecture provides a complete solution for any device or application. Existing applications already using OPC UA client/server communications can add the publish/subscribe features with minimal effort.
A demonstration of the OPC UA publish/subscribe functionality will be held at Hanover Fair the week of April 25 in the OPC Foundation Booth hall 9 – A11. This demonstration will consist of multiple vendors showing OPC UA enhanced with publish/subscribe, truly demonstrating how easy it is to have connectivity and information integration in IoT devices and applications. The demonstration will show both semantic and syntactic data interoperability.
by Gary Mintchell | Mar 23, 2016 | Automation, Internet of Things, Interoperability, Operations Management
A couple of people commented on my protocol wars post I published yesterday. I’ll address a couple of comments and then push on toward some further enterprise level conclusions.
Satish wrote: “Nice summary Gary! Standardization is a double edged sword for vendors and always there is a cautious approach. You know what happened with Real time Ethernet, Field bus & ISA 100 standards. It will take its time to mature when customers demand it and vendors are happy with the ROI. I could see how vendors make money in integration through OPC by supporting the standard but adding cost when it comes to usage of it (fine letter prints?). Probably when automation system becomes COTS system it will be a drastic change – XOM’s project with Lockheed Martin is aimed at it, am not sure!”
Satish pointed out a couple of sore spots regarding standards. Actually standards sometimes get a bad rap. Sometime they deserve it. I don’t care to get deeply into any of them, but, for example, the wireless sensor network process was one of the worst examples in the past 20 years. Eventually the industry standard WirelessHART dominated simply due to market forces. From a technology point of view, there just wasn’t that great of a difference. We can think of others. Sometimes it is simply obfuscation on the part of one vendor or another.
However, he is correct talking about the tension of standards and suppliers. Suppliers think that they can provide a better end-to-end solution by keeping everything within their sandpile. Sometimes they can. All of us who have been on the implementing end know that that is not a 100% solution. Sorry.
Cynics think that suppliers simply wish to lock in customers with an extraordinarily high switching cost. All suppliers wish to have a customer for life, but I don’t take that cynicism to the extreme. It implies much better product development and coordination than is often the case.
That said, for suppliers working with standards will almost always be Plan B.
That brings us to the owner/operator or end-user community. They mostly like Plan B. For several reasons. First, this does keep the supplier on its toes knowing that competition is just around the corner. Good service, technology, and prices can keep the customer happy. Slip up, and, well….
Further, owner/operators know that they have many more needs than one supplier can fill. And they have a multitude of legacy systems that need to be integrated into the overall system-of-systems. This also requires Plan B—interoperable systems built upon standards.
This interoperable system-of-systems, however, does not preclude best-of-class technologies and solutions within the COTS product. It only requires exposing data through standards in a standard format. That would include the RDLs and Web Services Information Service Bus Model (ws-ISBM) on the OIIE diagram. The OIIE does not care about what is within the blocks of operations, maintenance, design, and other applications. Just that data can flow smoothly from system to system.
System-of-systems
Aaron Crews of Emerson wrote on LinkedIn a little about Emerson’s work in the area. “Ok now draw a vertical line through your bus and call that a corporate firewall and it gets even more complex. Not pushing the approach as the be-all, end-all, but what Emerson has been doing with the ARES asset management platform is an interesting take on the reliability side of this.”
Let’s take Aaron’s thoughts about what Emerson is doing and consider on the next post what happens if many companies are doing something similar in different applications. Putting these all together looking at things from an enterprise point of view.
by Gary Mintchell | Mar 22, 2016 | Automation, Internet of Things, Operations Management
I’ve spent way too much time on the phone and on GoToMeeting over the past several days. So I let the last post on the hierarchy of the Purdue Model sit and ferment. Thanks for the comments.
Well, I made it sound so simple, didn’t I? I mean, just run a wire around the control system and move data in a non-hierarchical manner to The Cloud. Voila. The Industrial Internet of Things. Devices serving data on the Internet.
Turns out it’s not that simple, is it?
First off, “The Cloud” is actually a data repository (or lots of them) located on a server somewhere and probably within an application of some sort. These applications can be siloed like they mostly are now. Or maybe they share data in a federated manner—the trend of the future.
To accomplish that federation will require standardized ways of describing devices, data, and the metadata. I’ll have more to say about that later relative to some white papers I’m writing for MIMOSA and The OpenO&M Initiative.
Typically data is carried by protocols. OPC (and its latest iteration OPC UA) has been popular in control to HMI applications—and more. Other Internet of Things protocols include XMPP, MQTT, AMQP. Maybe some use JSON. You may have heard of SOAP and RESTful.
Will we live with a multiplicity of protocols? Can we? Will some dominant supplier force a standard?
Check out these recent blogs and articles:
GE Blog – Industrial Internet Protocol Wars
FastCompany, Why the Internet of Things Might Never Speak A Common Language
Inductive Automation Webinar — MQTT the only control protocol you need
OPC – Reshape the Automation Pyramid (is OPC UA all you need?)
Interoperability Among Protocols
What we need is something in the middle that wraps each of the messages in a standard way and delivers to the application or Enterprise Service Bus. Such a technology is described by the OpenO&M Information Service Bus Model that is the core component of the Open Industrial Interoperability Ecosystem (OIIE) that I introduced in the last post. The ISBM is actually not a bus, per se, but a set of APIs based on Web Services. It is also described in ISA 95 Part 6 as Message Service Model (MSM).
The MSM is described in a few points by Dennis Brandl:
- Defines a standard method for interfacing with different Enterprise Service Buses
- Enables sending and receiving messages between applications using a common interface
- Reduces the number of interfaces that must be supported in an integration project
Here is a graphic representation Brandl has developed:
These are simple Web Services designed to remove complexity from the transaction at this stage of communication.
