by Gary Mintchell | Jan 9, 2017 | Internet of Things
Much is written about the Industrial Internet of Things, but is anyone really doing anything with it?
Well, yes, it is real and solving business problems for manufacturers. But too few are taking advantage of leveraging the technology for achieving business benefit. I have been in sessions with managers and engineers seeking a plan of implementation.
So last week I welcomed in the New Year with a conversation with Maciej (Mah-chek) Kranz, author of “Building the Internet of Things: Implement New Business Models, Disrupt Competitors, Transform Your Industry.”
Kranz, Vice President of the Corporate Strategic Innovation Group at Cisco Systems, leads the team focused on incubating new businesses, accelerating internal innovation, and driving co—innovation with customers, partners, and startups. Prior to this he was General Manager of Cisco’s Connected Industries Group, where he drove IoT businesses for key industrial markets.
He told me that he wants people to understand the changes coming due to the IIoT and make the book practical and helpful. He succeeded in that goal. The book contains many examples of Industrial Internet of Things in practice along with practical leadership and implementation advice. While there is some technical discussion, this is not a book for engineering rather it is targeted to line of business leaders, people who solve business problems, and IT leaders as well as engineering leadership.
As I read the book, though, I got the impression that much of what Kranz is calling IIoT was once called “manufacturing IT.” Such is the morphing of terminology.
I have talked with leaders who are trying to build business cases and implement an Industrial Internet of Things strategy. Their experiences merge with Kranz’ observations that the biggest barrier to implementation is cultural. Any of us who are change agents and have tried implementing new technologies and new ways of working can show the scars earned from learning that barrier the hard way.
But the potential benefits are huge. For example, this quote from an executive of Harley Davidson, “What used to take a painfully long time to triage and troubleshoot now can be accomplished in a single morning,” the manager said, “An order of magnitude improvement.”
Kranz is not bashful about proclaiming why you should implement IIoT—“Like it of not, the Internet of Things (IoT) will change your organization unlike anything before. It isn’t just the next big thing. IoT is the future.”
He continues, “The real payoff from IoT comes down to automating existing processes that have a large labor or time component and streamlining the related process in one way or another.”
Here is another quote from the book, “You belong to Generation IoT if you embrace open standards, open collaboration, open communications, and open, flexible business models and you’re willing to assemble a comprehensive partner ecosystem to build and deploy agile, flexible business solutions.”
On the practical side, here are his eight elements of success
- Start with strategy, planning, and preparation.
- Secure C-suite sponsorship
- Build a diverse team
- Communicate and drive IT/OT convergence
- Rethink operations from the ground up
- Design for flexibility
- Educate and train
- Revisit repeatedly-it’s not a one-and-done effort
Kranz concludes with words that echo my belief in Lean—that it isn’t a strategy but more of a way of life. He says, “Most importantly, my hope is that IoT will change the way you think about your business, and how you’ll design, plan, develop, and deliver products and services, go to market, and interact with customers.”
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 26, 2016 | Interoperability, Standards
This snippet from the conversation shows some of the urgency:
The first is that the kinds of technologies that have access controls for copyrighted works have gone from these narrow slices (consoles and DVD players) to everything (the car in your driveway). If it has an operating system or a networking stack, it has a copyrighted work in it. Software is copyrightable, and everything has software. Therefore, manufacturers can invoke the DMCA to defend anything they’ve stuck a thin scrim of DRM around, and that defense includes the ability to prevent people from making parts. All they need to do is add a little integrity check, like the ones that have been in printers for forever, that asks, “Is this part an original manufacturer’s part, or is it a third-party part?” Original manufacturer’s parts get used; third-party parts get refused. Because that check restricts access to a copyrighted work, bypassing it is potentially a felony. Car manufacturers use it to lock you into buying original parts.
This is a live issue in a lot of domains. It’s in insulin pumps, it’s in voting machines, it’s in tractors. John Deere locks up the farm data that you generate when you drive your tractor around. If you want to use that data to find out about your soil density and automate your seed broadcasting, you have to buy that data back from John Deere in a bundle with seed from big agribusiness consortia like Monsanto, who license the data from Deere. This metastatic growth is another big change. It’s become really urgent to act now because, in addition to this consumer rights dimension, your ability to add things to your device, take it for independent service, add features, and reconfigure it are all subject to approval from manufacturers.
We are all familiar with lock in. Heck, I’ve been in some product development meetings where some of these things came up. “How can we keep customers with us and away from the competition?” they ask.
Meanwhile the customer says, “I’m pretty happy with your product now. But what if you start acting like Mylan and its EpiPen? I find myself locked in, and now I am susceptible to frequent price increases. Or what if your quality begins to dip? Not to mention, what is your incentive to innovate any longer?
And so, the inevitable dance continues.
I’m not opposed to big companies with comprehensive product offerings. Sometimes there is a lot of innovation. It takes a lot of money to invest in developing some of these products. Customers appreciate this. They welcome partners. They just want to see competition and alternatives. But sometimes the customer voice gets lost.
Sometimes I look at the situation as an independent analyst/writer not beholden to anyone and decide someone has to speak up for the customer.
by Gary Mintchell | Aug 3, 2016 | Automation, Internet of Things, Technology
“It is the next big thing [in the Industrial Internet of Things].”
I have been waiting for quite some time for the next Opto 22 move. It has always been the early, if not first, mover in adopting technologies that are IT friendly for OT. This next big thing according to Marketing VP Benson Hougland is a controller with a RESTful API.
Let’s look at a couple of big reasons. HMI/SCADA software is rapidly moving to being a cloud-based app with HTML5 clients. Getting to the cloud means getting through firewalls. REST helps. Then consider that recent graduates, and current students, are studying and playing with such technologies as REST and MQTT and others, rather than all the specific industrial technologies and protocols, on their Arduinos and Raspberry Pi’s. They will be right at home programming HMI or database applications with technologies such as REST.
The Announcement
Industrial automation manufacturer Opto 22 has announced immediate availability of version 9.5 of PAC Project, a Microsoft Windows-based integrated software development suite for industrial automation, process control, remote monitoring, and Internet of Things applications.
The most significant addition in this version is new firmware for Opto 22 programmable automation controllers (PACs) that includes an HTTP/S server with a RESTful API, providing developers with secure, programmatic access to control variables and I/O data using any programming language that supports JavaScript Object Notation (JSON).
This new capability closes the IT/OT gap, allows for rapid Industrial Internet of Things (IIoT) application development, provides for secure data exchange using open Internet standards, and reduces time to market in machine and system design.
The addition of a secure RESTful server and an open, documented API to a programmable automation controller (PAC) is a significant, ground-breaking industry innovation, because REST architecture and associated technology are intrinsic to the Internet of Things and paramount to web and mobile-based application development.
Opto 22’s implementation of REST directly into a commercially available, off-the-shelf industrial PAC is unique in the market and places the company as the first and only industrial automation and controls manufacturer to offer this industry-changing technology.
Other features found in this new version include new tools to develop modular control applications with nested subroutines, new debugging tools to reduce development time, support for a worldwide installed base of legacy Optomux I/O systems, and integration of third-party systems and protocols with the IIoT.
To provide enhanced security and auditing for HMI access, PAC Project now offers sophisticated user groups and data rights, as well as the ability to embed video directly into HMI windows.
PAC Project 9.5 provides updated firmware for Opto 22 SNAP PAC S-series and R-series controllers that enable a secure HTTPS server on PAC controllers. Combined with a RESTful open and documented API, this new version allows developers to write applications that access data on the PAC using the developer’s programming language of choice with the well-known and widely supported JSON data format. This new capability allows software and IoT application developers to decrease time to market, reduce the development learning curve, and eliminate layers of middleware for secure Industrial Internet of Things (IIoT) applications.
Firmware version 9.5 for SNAP PAC R-series and S-series PAC-R and PAC-S controllers enables REST endpoints for both analog and digital I/O points as well as control program variables including strings, floats, timers, integers, and tables. REST endpoints are securely accessed using the new fully documented RESTful API for SNAP PACs. Names of RESTful endpoints are derived from a configured PAC Control program strategy file and are therefore unique to each PAC’s program and I/O configuration. Client data requests are returned in JavaScript Object Notation (JSON) format, enabling PAC controllers and I/O to be used with virtually any software development language with JSON support, including C, C++, C#, Java, JavaScript, node.js, Python, PHP, Ruby, and many more.
Database support is also available for database tools that work with JSON, like MongoDB, MySQL, and Microsoft’s SQL Server.
With the release of PAC Project 9.5, developers are no longer tied to a specific manufacturer’s software development environment. They can use the development environment and language of their choosing to write new software, create web services, and build Internet of Things applications.
RESTful data from PACs is secured using TLS encryption over HTTPS connections authenticated using basic access authentication (Basic Auth). RESTful data access can be restricted to read-only use, or allow reading and writing to I/O and strategy variables. The HTTP/S server is disabled by default and must be configured and enabled to operate, preventing unwanted or unauthorized access to the controller over HTTP.
Also included in this release are two Node-RED nodes, used for communicating with SNAP PAC controllers through the RESTful API with Node-RED, a visual tool for wiring up the Internet of Things. Node-RED is an open-source, graphical, flow-based application development tool designed by the IBM Emerging Technology organization that makes wiring up APIs, represented as “nodes,” simple and easy to do. Node-RED is particularly useful for developing IoT applications that interact with cloud-based platforms and APIs, such as IBM Bluemix, IBM Watson, Amazon’s AWS IoT, AT&T MX2, Microsoft Azure, and Google Cloud Platform.
In contrast to OT, IT enterprise networks use the same open standards and protocols found on the Internet. The Internet was founded on open communication standards like TCP/IP. Application-specific protocols are layered on top: HTTP/S, SMTP, SNMP, MQTT, and so on.
The Internet uses programming languages like JavaScript, Java, and Python and presents information using technologies like HTML5 and CSS, all of which are open.
Definitions:
- MQTT—to collect device data and communicate it to servers
- XMPP—to enable the near-real-time exchange of structured yet extensible data between two or more devices on the network
- DDS—a fast bus for integrating intelligent machines
- AMQP—a queuing system designed to connect servers to each other
- API–(Application Programming Interface)—A set of protocols, routines, and tools that web-based applications can use to communicate with other web-based applications.
- JSON–(JavaScript Object Notation)—The primary data format used for asynchronous communication between web browsers and web servers. JSON was primarily developed to replace browser plugins such as Flash and Java applets. JSON is a request/response method web browsers can use to ask for information from web servers.
- REST–(Representational State Transfer)—A set of architectural constraints used to develop web applications. Designed as a common development standard for applications used on the Internet, REST confines developers to a specific set of rules to follow.
- RESTful Architecture—When a web site or API is conforming to the constraints of the REST architecture, it is said to be a RESTful system.
by Gary Mintchell | Mar 9, 2016 | Automation, Internet of Things, Interoperability, Operations Management, Technology
I’ve been thinking deeply about the industrial internet and the greater industrial ecosystem. A friend passed along an article from ZD Net written by Simon Bisson, “There’s A Huge Void At the Heart of the Internet of Things.”
The deck of the article reads, “Closed systems do not an internet make. It’s time to change that before it’s too late.”
He knew I was working on some white papers for MIMOSA and the OpenO&M Initiative on interoperability of standards in the larger industrial ecosystem. In the case of what I’m writing, there exists a gap in areas covered by Enterprise Business Systems, Big Data and Analytics, Automation and Control Systems, and Life-Cycle Engineering Systems. The gap can be filled with Supplier Neutral Open Standards and Specifications.
Bisson writes, “Sensors are everywhere, but they’re solitary devices, unable to be part of a holistic web of devices that exposes the world around us, giving us the measurements we need to understand and control our environments.”
He notes a few feeble movements toward developing “communication and API standards for these devices, through standards like AllJoyn and Open Connectivity Foundation, the backbone is still missing: a service that will allow us to work with all the devices in our homes.”
Industrial Internet broadly speaking
Typical of a consumer-facing publication, he’s thinking home. I’m thinking industrial in a broad scope.
He continues, “Building that code isn’t hard, either. One of the more interesting IoT development platforms is Node-RED. It’s a semi-visual programming environment that allows you to drag and drop code modules, linking them to a range of inputs and outputs, combining multiple APIs into a node.js-based application that can run on a PC, or in the cloud, or even on devices like the Raspberry Pi.”
Bisson concludes, “The road to an interoperable Internet of Things isn’t hard to find. We just need to remember that our things are now software, and apply the lessons we’ve learnt about building secure and interoperable systems to those software things. And once we’ve got that secure, interoperable set of things, we can start to build the promised world of ubiquitous computing and ambient intelligence.”
I’d take his consumer ideas and apply them to industrial systems. The work I’m doing is to explain an industrial interoperable system-of-systems. I’m about ready to publish the first white paper which is an executive summary. I’m about half done with the longer piece that dives into much greater detail. But he is right. Much has already been invented, developed, and implemented at a certain level. We need to fill the gap now.
