Should you leave processing in the cloud or on the edge? Both. Particularly in IIoT, developers need to start thinking about both tracks.
There is a power struggle going on in the Industrial Internet of Things (IIoT). Many think cloud applications are the future of real-time data processing in IIoT settings; others believe data should be processed and decisions executed at the edge of the network.
In truth, the answer lies somewhere in the middle: Data needs to be processed both via the cloud and at the edge, which presents an interesting opportunity for software developers in the IIoT space. Clearly, being able to operate industrially hardened smart devices remotely – and in many cases automatically – from the cloud presents many benefits. But the challenge lies in potential connectivity issues when developing applications. Developers must think along a dual track, which means that they must think about how an app developed for the cloud can be mirrored to run on the edge device itself.
Several factors converge here to create a unique atmosphere for developers: connectivity, security, and today, the programmability of edge devices. Traditionally, the devices themselves simply acted as conduits for data collection and transport, but today, hardware manufacturers are creating devices that can host third-party applications. A point worth noting is the advent of Node-RED, which can streamline some of the programmability challenges.
So, understanding the need for mirrored applications, let’s look at a few use-cases that highlight exactly why this redundancy is necessary.
Cloud-to-Device in the Oilfield
In the case of oil fields, when the edge app sees an oil pump showing a temperature reading above a predetermined safety level, the applications on the device can decide to shut the pump down, or the cloud application can send a command to do so. In cases where there are emergencies, different sites might have a different set of actions that need to be initiated. In fact, most sites have thermal sensors on the oil pads. If the oil pads exceed a certain threshold, then these cloud programs know there is an explosion and a fire happening onsite. To prevent a chain reaction, the cloud will send a command to shut down all the pumps and all the valves in that area so they don’t create a chain reaction and keep spreading.
Extending the oil site example, if there is an intentional attack on the site, the first thing you do is disconnect the communication lines back to the cloud to protect the network. In that scenario, having the same application running on the cloud and the edge devices still allows the same decision to be made in the local network by the device itself. If the device cannot ‘see’ the cloud, it can still respond and execute tasks. If the cloud program is not responding, and the device notices the pad temperature goes beyond the threshold, it can initiate a local shutdown protocol. Once the network is back online, the device can send this information back to the cloud which can, in turn, be given to site operators remotely.
Because of these necessary duplications, programming for these settings can be difficult. For example, in Oracle applications, in SCADA networks, all of the applications run on Java. Oracle pages run on Java. Therefore, most programmable industrial devices must demonstrate that they can run the same Java application locally. Many IIoT platform providers have now expanded the scope of the programming. They’ve built devices that can actually drag and drop the same Java code from the cloud into individual edge units, to run that device. Of course, it has to be developed for a device and for the cloud, so it requires some extra attention, mainly because on the device, the decision-making is slightly different. It does not execute the application unless it cannot speak to the cloud. When it cannot speak to the cloud, then it executes the command just the way the cloud would.
Redundancy Applications in UAS
In other industrial settings – unmanned systems, for instance – the protocols are different. If a drone can’t communicate with the operator, it could have a simple command that says, “Trace back all your GPS location and fly them in a reverse mode and go back to where you came from, until you can establish communication and get new commands.” So, it’s the same concept. Programmable IIoT platforms are now being set up and designed so that they can run applications in multiple different languages. If the application is written in C, Java, Python – basically, anything that can be read on the cloud – it can be dragged and dropped into those edge units, and it could execute the same protocols directly on the edge device. This simple concept is transforming the way the IIoT thinks about data transport and real-time decision-making. If you write your code once you can drop it in both places, and if the device loses communication, it knows what to do.
Of course, there are many other considerations when thinking about programming applications for the edge and the Industrial IoT. Security remains paramount, and we see examples every day pointing to a potential meltdown if security isn’t addressed properly. Still, the potential for the cloud-to-device communication and application execution remains great. For developers, being able to think across platforms, languages and program functions are three key points to consider when creating applications for the Industrial IoT.
This article originally appeared on DZone.com
