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 4, 2016 | Automation, Industrial Computers, Technology
John Bernadin (retired Rockwell Automation executive) posted a comment on my LinkedIn post of my blog post on Protocol Wars–Vendors versus Standards.
“From the PLC side, the Auto industry began major efforts to drive standards in the 1990’s like GM’s MAP mfg automation protocol. However, after a decade they realized that even with their leadership and size, the Big Three and their top tier suppliers couldn’t get PLC vendors to agree on a standard. So in 2000, they decided it would literally take an “Act of Congress” to get vendors to agree. Two years later, a bipartisan Congress passed the Manufacturing Enterprise Integration Act of 2002 giving NIST over $150 million to develop and drive Interoperability protocols and standards. What happened next? President Bush never approved the budget for NIST to do it because he philosophically didn’t believe that the federal government should be creating standards. Thus, 25 years later we still have nothing — because this problem is like solving world hunger or world peace. It’s too big. “
Good recap, John.
Then there were PC standards
In those days, there was a PC standard. Actually, there were a few. There was an “XT” bus that standardized PCs on what became known as the PC platform. In the late 80s, IBM thought it would get fancy and recapture some proprietary technology it lost with the XT platform. Anyone remember Microchannel?But then PCI came along driven more by chip makers, I believe, to take the backplane to another level without being vendor specific.
I actually took classes and may still have a certificate around the house having passed tests on IBM’s proprietary, or sort-of proprietary, technologies. Remember also Token Ring? Yep, that was another. The third test had something to do with finance applications on the PC.
In those days you could build cards to plug into the bus. Only Apples were locked down.
There was an “embedded” PC world dominated by VMEbus and in the mid-late 90s PCI and then CompactPCI. PLCs were generally built on a modified VME but nothing was standard.
None of these things I’m talking about were driven by government. IBM allowed its first PC bus to become an industry standard that other companies could build to–and the PC industry took off.
Allen-Bradley CompactLogix I/O
In the 90s the big automakers grew frustrated with what was essentially a single PLC source and tried a bunch of things. Maybe the government. Maybe they were big enough to drive a CompactPCI standard. All PLC manufacturers would build on a single CompactPCI standard. Anyone’s cards would fit in the backplane–just like the PC industry. You could load anyone’s operating system and programming software on the platform.
By driving hardware and then software to commodity, then the automakers could drive the cost dramatically down.
Innovation
Since the 80s and 90s saw tremendous innovation around the standards driven PC platform, it was logical (to users) that similar innovation advances would be seen in the industrial “PC” market.
Many things were tried. Many things failed.
Trouble is–the industrial market is much smaller than the PC market. A commodity industrial market would drive incumbents to seek other markets. Innovation would dry up. Suppliers drove to protect their turf.
And innovation exploded.
We saw many things added to the PLC platform driven by competition (although reducing interoperability):
- PC technologies–memory, processing
- Networking
- Integrated motion control
- Reduced footprint
- Innovative development studios
But, alas, if you bought Rockwell, you were stuck with Rockwell. Same with Siemens, and everyone else.
Users did reap some price concessions. Better, they reaped technology advances because the suppliers could afford to invest in new technology.
New technology cycle
Theses curves always run their cycle.
Where are we now? Is there any reason to need a standard platform PLC? Or has that technology curve been passed?
Do we need a single protocol for moving data in this brave new IoT world? Or, will suppliers build gateways that foster inter-communication–or a bus such as the ws-ISBM? And render the argument moot?
by Gary Mintchell | Mar 24, 2016 | Automation, Internet of Things, Interoperability, Operations Management
Owner/Operators do see great benefits to standards for system-of-systems interoperability. Getting there is the problem.
Aaron Crews talked about what Emerson is doing along the lines I’ve been discussing. Tim Sowell of Schneider Electric Software hasn’t commented (that’s OK), but I’ve been looking at his blog posts and commenting for a while. He has been addressing some of these issues from another point of view. I’m interested in what the rest of the technology development community is working on.
Let’s take the idea of what various suppliers are working on and raise our point of view to that of an enterprise solutions architect. These professionals are concerned about what individual suppliers are doing, of course, but they also must make all of this work together for the common good.
Up until now, they must depend upon expensive integrators to piece all the parts together. So maybe they find custom ways to tie together Intergraph, SAP, Maximo, Emerson (just to pull a few suppliers out of the air) so that appropriate solutions can be devised for specific problems. And maybe they are still paying high rates for the integration while the integrator hires low cost engineering from India or other countries.
When the owner/operators see their benefits and decide to act, then useful interoperability standards can be written, approved, and implemented in such a way to benefit all parties.
Standards Driving Products
I think back to the early OMAC work of the late 90s. Here a few large end users wanted to drive down the cost of machine controllers that they felt were higher than the value they were getting. They wanted to develop a specification for a generic, commodity PLC. No supplier was interested. (Are we surprised?) In the end the customers didn’t drive enough value proposition to drive a new controller. (I was told behind the scenes that they did succeed in getting the major supplier to drop prices and everything else was forgotten.)
Another OMAC drive for an industry standard was PackML—a markup language for packaging machines. This one was closer to working. It did not try to dictate the inside of the control, but it merely provided an industry standard way of interfacing with the machine. That part was successful. However, two problems ensued. A major consumer products company put it in the spec, but that did not guarantee that purchasing would open up bidding to other suppliers. Smaller control companies hoped that following the spec would level the playing field and allow them to compete against the majors. In the end, nothing much changed—except machine interface did become more standardized from machine to machine greatly aiding training and workforce deployment problems for CPG manufacturers.
These experiences make me pay close attention to the ExxonMobil / Lockheed Martin quest for a “commodity” DCS system. Will this idea work this time? Will there be a standard specification for a commodity DCS?
Owner/Operator Driven Interoperability
I say all that to address the real problem—buy in by owner/operators and end users. if they drive compliance to the standard, then change will happen.
Satish commented again yesterday, “I could see active participation of consultants and vendors than that of the real end users. Being a voluntary activity, my personal reading is standards are more influenced by organizations who expect to reap benefit out of it by investing on them. Adoption of standard could fine tune it better and match it to the real use but it takes much longer! The challenge is : How to ensure end user problems are in the top of the list for developing / updating a standard?”
He is exactly right. The OpenO&M and MIMOSA work that I have been referencing is build upon several ISO standard, but, importantly, has been pushed by several large owner/operators who project immense savings (millions of dollars) by implementing the ecosystem. I have published an executive summary white paper of the project that you can download. A more detailed view is in process.
I like Jake Brodsky’s comment, “I often refer to IoT as ‘SCADA in drag.’ ” Check out his entire comment on yesterday’s post. I’d be most interested in following up on his comment about mistakes SCADA people made and learned from that the IoT people could learn. That would be interesting.
