Though the Open Process Automation Forum (OPAF) continues to receive the lions share of coverage as defining “the” open system, it is, in fact, not the only approach or option for the application of open technologies for the control domain.
OPAF is somewhat constrained on how open they can be because they have backwards compatibility as a starting point, which to some extent limits them to using traditional and “less open” (consortia-sponsored) protocols such as OPC, FieldComm, Profibus, etc. to ensure compatibility and vendor support. They’re also working on how to convert all their existing applications and IP to the new virtual environment.
I suspect many readers have at least one or more Arduino, Beagle Bone or Raspberry PI microcontrollers in your hobby shop, partly because of their low price point as compared to their capability—just the right platform for Internet of Things (IOT) devices running on open systems to maintain that same cost-conscious approach. Another new entrant to this market is China-based NodeMcu, which provides an open-source firmware and development kit that helps you to prototype your IOT product with a few Lua script lines in an event-driven Node.js-style network API running on a 5 x 5 mm-sized microcontroller. (Lua was created in 1993 and has been used in many industrial applications with an emphasis on embedded systems, and in one of the most challenging coding environments—games.)
Building on the latent momentum for small, low-cost microcontrollers, Hilscher has introduced its Industrial Raspberry Pi 3 using Node-Red as the development/integration environment and Docker containers to design and connect with the rest of the world.
Node-RED is a Java-script programming tool for connecting hardware devices, APIs and online services by providing a browser-based flow editor that makes it easy to virtually “wire” together flows that can be then deployed to the runtime in a single click.
Containers are standardized units of software for development, shipment and deployment that package up code and all its dependencies (system tools, system libraries and settings), allowing the application to run quickly and reliably from one computing environment to another.
Available for both Linux and Windows-based applications, containerized software will always run the same regardless of the infrastructure. Because container images become containers at runtime, containers isolate software from its environment and ensure that it works uniformly despite differences, for instance, between development and staging.
Much like the support infrastructure for Linux and other open-source projects, containers can be registered/stored with Docker. Other groups, such as OMA Spec Works with their smartobjects, have similar functionality, thus providing continuity of support like has been demonstrated with Linux, Wordpress and other open-source-community tools.
Of course, once we have the tools to capture the data, it needs to be stored and made accessible as and when required within appropriate cybersecurity constraints. One option for providing this capability is Blynk, a hardware-agnostic HTTP RESTful API IoT platform with open-source cloud that can run on public or private servers supporting mobile apps, device management, data analytics and machine learning.
Blynk already supports more than 400 boards (microcontrollers and microcomputers like Arduino, Raspberry Pi, ESP8266, Particle, etc.), including support for Arduino, Particle, ARM mbed, TI Energia, MicroPython, Node.js, OpenWRT and LUA as well as the full range of wired and wireless connections.
Though not based on a microcontroller, Phoenix Contact has released a Linux-based PLC (PLCNext) with free engineering/ programming software supporting familiar IEC 61131-3 languages for traditional protocols including OPC, with the option to post to the cloud. Like Inductive Automation did when they started, this community also has a platform to sell any applications you create.
With all these choices, the challenges to adoption of any new technology, especially in our industry, continue to be:
- Backwards compatibility,
- Protection of intellectual property (IP), especially all those existing applications running the facilities (see 1), and
- Ongoing long-term support.
Containers might be one possible answer, but it certainly appears that, regardless of which solution(s) are in our future, they will include Java.