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 11, 2016 | Automation, Internet of Things, Technology
Following up on its release of REST enabled programmable automation controllers (PACs) for the industrial internet of things, Opto 22 has released Node-RED nodes. The purpose for enabling Node-RED addresses significantly decreasing IIoT application development time and complexity. These Node-RED nodes for PACs make it easier to prototype and develop applications for connecting physical assets to cloud applications. Node-RED nodes and a RESTful API for Opto 22 SNAP PAC R-series and S-series controllers are available free for download.
Rapid IIoT Application Prototyping
Linking technology assets and services together to build IIoT applications often requires layers of complex software development and long development cycles that quickly erode IIoT application ROI. Opto 22’s Node-RED nodes for SNAP PAC programmable automation controllers enable nearly anyone to rapidly prototype and develop IIoT applications with Node-RED, opening a path to quickly connect legacy physical assets to the digital world of cloud services.
Node-RED for IIoT
Node-RED is an innovative visual wiring tool to connect edge computing systems such as industrial automation controllers to cloud services such as Amazon Web Services (AWS) IoT, IBM Watson IoT, and Microsoft Azure in new and interesting ways.
Created by Nick O’Leary (@knolleary) and Dave Conway-Jones (@ceejay) of IBM Emerging Technologies (@ibmets), Node-RED is an open-source, cross-platform technology available on GitHub.com and npmjs.org, and is currently available for a variety of platforms, including OS X, Microsoft Windows, Linux, and Raspberry Pi, and cloud offerings like IBM Bluemix and AT&T Flow. Built on the popular Node.js JavaScript runtime, Node-RED benefits from a large Node-RED library—containing over 500 prebuilt and ready-to-deploy nodes—allowing IIoT application developers to leverage existing software code and deploy it directly into their applications.
“I’ve been very impressed with the whole Node-RED project,” said Jim Turner, Senior Software Developer at Opto 22. “It’s well run, polished, and of high quality, but still very practical and useful. It’s been a pleasure to develop for their platform.” At the time of this release, Node-RED has been downloaded from npmjs.org over 25,000 times in the last month.
Lowering the Technical Bar
The Node-RED development environment offers a gradual and easily approachable learning curve for users of all levels and requires little to no programming skills. Instead, Node-RED takes advantage of pre-programmed, reusable code blocks called nodes. These nodes make IIoT application development simpler, easier to repeat, and faster to scale. Through a visual browser-based, drag-and-drop interface, Node-RED allows IIoT application developers to focus on identifying an opportunity and developing a solution, rather than building the components of an application from scratch.
Advanced JavaScript functions can also be created within the editor using a Function node. A built-in library lets developers save useful functions, templates, or node flows for re-use. The flows created in Node-RED are stored using the widely known JSON format, which can be easily imported and exported for sharing with other developers and applications, promoting the idea of social application development.
Download the Node-RED nodes for Opto 22 SNAP PAC R-series and S-series controllers directly.
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 | 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 | Aug 16, 2013 | Automation, Technology
Source: Wikipedia
It is interesting, or maybe coincidental, that I had just left the National Instruments user conference about Graphical Programming (among other things) when I downloaded a Robert Scoble podcast interview with the principles of a new company who just launched a flow chart programming tool for high-tech programmers. (I couldn’t find a link for Scoble, but search Scobleizer on iTunes.)
The company has released No Flow JS and many companies had picked it up. A sample of the Flow Diagram Programming accompanies this post.
This brought back all the memories of flow-chart programming from the 90s. The only company still successfully pushing that paradigm to my knowledge is Opto 22. Phoenix Contact picked up the remnants of Think ‘n Do and Steeplechase many years ago. I can remember when the latter two companies thought that everyone would flock to their controllers because it was so much easier and more understandable to program in with flow charts than ladder diagram.
Unfortunately for them, engineers were afraid of the control platform–a PC. I told the CEOs for years that they should stop arguing in their ads about whose real-time operating system was better and concentrate on why engineers should switch from PLCs to the new platform. Meanwhile, Opto 22 found its niche and happily keeps customers happy with its controller and flow-chart programming.
NI uses a paradigm much like function block programming. I have programmed in LabView and recommend it over Ladder. On the other hand, I realize that there remain many thousands of technicians who are quite comfortable in Ladder. But even for those who love Structured Text, perhaps they should take a look at flow chart programming. If it’s coming to mainstream programming, could industrial be far behind?
