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 | Apr 2, 2016 | Automation, News
I have not been away on purpose. This may be about the longest I’ve gone in 12+ years of blogging. Had a crisis of sorts in a business I’ve invested in, two road trips, a bout of allergy infection, and a report for a client due. Plus some construction going on around the house. Quite a week.
Here are some items I’ve been saving up. Meanwhile, I’m still thinking about ramifications of what I started last week with IIoT, Level 3, software, and the like.
Frank Lamb has started a conversation on PLC information and samples. Check out his site and add your comments.
I will be going to Hannover the end of the month. I’ll be busy, but if you will be there ping me. I’ll have a bunch of stuff from Siemens and Dell for sure. There should be much more information from so large a show.
Coming up the first week of May ( 2-5) is QAD Explore, the ERP supplier’s user conference, in Chicago at the Hilton. I’ll be on a panel on Tuesday discussing the relationship past, present, future of MES and ERP with a little IIoT thrown in. If you are a user or are kicking some ERP tires, check it out. Then look me up.
Schneider Electric Connect 2016 will be May 23-26 in New Orleans. I’m not speaking, but I’ll be there. Maybe we can arrange a meet up? This part of Schneider is Modicon/Foxboro/Triconex
Then I saw this blog from Rockwell Automation written by Thomas Donato, President, EMEA, Rockwell Automation, talking about how industrial business leaders are not asking about IIoT (or Industrie 4.0 or whatever). I’ve noticed that suppliers are rushing to claim IIoT as a strategy or that they play in that game. But it’s the same as every new thing that comes down the road—customers just want solutions to their problems. That is how suppliers should be positioning their products and services.
And from my friend Jim Pinto. I asked him annually for 10 years at Automation World to give me his annual Pinto Prognostications. In his blog now, he takes a look at the rest of the 21st Century. Here is his conclusion. Check out the entire post here.
Power will be in the knowledge and the ability to integrate and exploit the new capabilities provided by technology and adapt to new environments and opportunities. The human adventure will continue as the remaining frontiers and limits of human thought are explored. But will people be happy?
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.
by Gary Mintchell | Mar 16, 2016 | Automation, Operations Management
Mike Boudreaux, director of performance and reliability monitoring for Emerson Process Management, has published an important article in Plant Services magazine discussing some limitations of the Purdue Model incorporating the Industrial Internet of Things. There are many more applications (safety, environmental, energy, reliability) that can be solved outside the control system. They just are not described within the current model.
Interestingly, about the same time I saw a blog post at Emerson Process Experts quoting Emerson Process Chief Strategic Officer Peter Zornio discussing the same topic.
I’ve been thinking about this for years. Mike’s article (which I recommend you read–now) brought the thoughts into focus.
Purdue Enterprise Reference Architecture Model
The Purdue Enterprise Reference Architecture Model has guided manufacturing enterprises and their suppliers for 25 years. The model is usually represented by a pyramid shape. I’ve used a diagram from Wikipedia that just uses circles and arrows.
This model describes various “levels” of applications and controls in a manufacturing enterprise. It describes components from the physical levels of the plant (Level 0) through control equipment and strategies (Level 2).
Level 3 describes the manufacturing control level. These are applications that “control” operations. This level once was labelled Manufacturing Execution Systems (MES). The trade association for this level–MESA International–now labels this “Manufacturing Enterprise Solutions” to maintain the MES part but describe an increased role for applications at this level. The ISA95 Standard for Enterprise Control labels this level as Manufacturing Operations Management. It is quite common now to hear the phrase Operations Management referring to the various applications that inhabit this level. This is also the domain of Manufacturing IT professionals.
Level 4 is the domain of Enterprise Business Planning, or Enterprise Resource Planning (ERP) systems. It’s the domain of corporate IT.
Hierarchical Data Flow
The Purdue Model also describes a data flow model. That may or may not have been the idea, but it does. The assumption of the model that sensors and other data-serving field devices are connected to the control system. The control system serves the dual purpose of controlling processes or machines as well as serving massaged data to the operations management level of applications. In turn, level 3 applications feed information to the enterprise business system level.
Alternative Data Flow
What Mike is describing, and I’ve tried sketching at various times, is a parallel diagram that shows data flow outside the control system. He rightly observes that the Industrial Internet of Things greatly expands the Purdue Model.
So I went to the white board. Here’s a sketch of some things I’ve been thinking about. What do you think? Steal it if you want. Or incorporate it into your own ideas. I’m not an analyst that gets six-figure contracts to think up this stuff. If you want to hire me to help you expand your business around the ideas, well that would be good.
I have some basic assumptions at this time:
- Data is not hierarchical
- Data has many sources and many clients
- Eventually we can expect smart systems automatically moving data and initiating applications
Perhaps 25 years ago we could consider a hierarchical data structure. Today we have moved to a federated data structure. There are data repositories all over the enterprise. We just need a standardized method of publish/subscribe so that the app that needs data can find it–and trust it.
Now some have written that technology means the end of Level 3. Of course it doesn’t. Enterprises still need all that work done. What it does mean the end of is silos of data behind unbreachable walls. It also means that there are many opportunities for new apps and connections. Once we blow away the static nature of the model, the way to innovation is cleared.
OpenO&M Model
Perhaps the future will get closer to a model that I’m writing a series of white papers to describe. Growing from the OpenO&M Initiative, the Open Industrial Interoperability Ecosystem model looks interesting. I’ve just about finished an executive summary white paper that I’ll link to my Webpage. The longer description white paper is in process. More on that later. And look for an article in Uptime magazine.
by Gary Mintchell | Mar 14, 2016 | Automation, Operator Interface
“Siri, what’s the weather in Bangor?”
“Alexa, buy some toilet paper.”
“Zelda, check the status of the control loop at P28.”
Operator interface is many years removed from its last significant upgrade. Yes, the Abnormal Situation Management Consortium (led by Honeywell) and Human-Centered Design used by Emerson Process Management and the work of the Center for Operator Performance have all worked on developing more readable and intuitive screens.
But, there is something more revolutionary on the horizon.
A big chunk of time last week on the Gillmor Gang, a technology-oriented video conversation, discussed conversational interfaces. Apple’s Siri has become quite popular. Amazon Echo (Alexa) has gained a large following.
Voice activation for operator interface
Many challenges lie ahead for conversation (or voice) interfaces. Obviously many smart people are working on the technology. This may be a great place for the next industrial automation startup. This or bots. But let’s just concentrate on voice right now.
Especially look at how the technologies of various devices are coming together.
I use the Apple ecosystem, but you could do this in Android.
Right now my MacBook Air, iPad, and iPhone are all interconnected. I shoot a photo on my iPhone and it appears in my Photos app on the other two. If I had an Apple Watch, then I could communicate through my iPhone verbally. It’s all intriguing.
I can hear all the objections, right now. OK, Luddites <grin>, I remember a customer in the early 90s who told me there would never be a wire (other than I/O) connected to a PLC in his plant. So much for predictions. We’re all wired, now.
What have you heard or seen? How close are we? I’ve done a little angel investing, but I don’t have enough money to fund this. But for a great idea…who knows?
Hey Google, take a video.
