Programming for Cloud-to-Device Communications in Industrial IoT
![](https://www.freewave.com/wp-content/uploads/2017/03/oil2-1-1024x202.png)
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
Hackathons Giving Birth to Innovative IoT Solutions
One of the fastest growing spaces in tech is the world of connected devices — often called the Internet of Things. In the embedded engineering and software development worlds, this technological shift is so pervasive some have taken to called it “The Internet of Everything.” While organizations and enterprises are increasingly putting the IoT at the root of many of their forward-thinking business strategies, one of the strongest engines of innovation stems from hackathons. Hackathons are essentially software or hardware challenges, where teams of developers or engineers are giving a task (i.e. build a smart city solution), with specified hardware or software (maybe a certain development board or programming environment), in a specific time period (anywhere from a few hours to a few days). In today’s top IoT news, we’ll take a look at a few stories in the industry about hackathons and how they are helping shape the IoT. Functional Fabric Hackathon Leads to eTextiles Innovation One of the fastest growing areas of the IoT revolves around smart clothing — sometimes called eTextiles. Smart clothing can range from simple solutions like integrating sewable LEDs into clothing to craft safer bicycling attire, to embedded sensors that are used to monitor environmental conditions for oil and gas workers. Recently, as noted in this article from “The University Network,” the Massachusetts Institute of Technology hosts a hackathon focusing on “Functional Fabric.” MIT has long been a hub for IoT innovation and is one of the epicenters of eTextiles. In the Functional Fabric Hackathon, teams of students faced the challenge of design clothing solutions that would aid soldiers, first responders and victims of disasters. The teams had three days to come up with their solutions and were competing for two grand prizes of up to $15,000. 22 teams competed and the winning solution came from an MIT student group called “Remote Triage.” Their solution was a sensor system that could be embedded in a soldier’s uniform, that would monitor not only vital signs, but could then report any injuries to field medics, provide location of the injured soldier, and even triage the severity of the injury with a color coding system. Hackathon Challenges Young Women to Build Smart City Solutions “She Builds Tech — Smart City Hackathon” recently challenged young women in India to build the smart city solutions of the future. As noted in this article from The Hindu, there were ultimately five winners — a solar energy harnessing paint, a water grid solution system, geo-fencing, a smart ambulance service, and a routing and scheduling system for tourists. The event lasted for two days and attracted over 300 girls from various engineering colleges. TechCrunch Disrupt Hackathon Coming in Mid-September TechCrunch Disrupt, the event that has becoming one of the world’s biggest stages for innovative new technologies, is rapidly approaching, with the San Francisco version of the event scheduled to kick off on September 12th. The hackathon will pit teams against each other in a two-day sprint to design the most impressive tech. At the end of the hackathon, teams will have just 60 seconds to impress judges for their shot at a $5000 grand prize, a slew of gifts and gadgets provided by sponsors, and all the glamour that goes along with winning one of the countries most elite hackathon competitions. To learn more about the hackathon, or to grab tickets to watch the action, check out this article from TechCrunch. — Hackathons continue to prove that innovations in the worlds of IoT, embedded engineering, and software solutions do not have to come just from the prototyping labs of Fortune 500 companies, but can emerge from groups of students and tech enthusiasts faced with big challenges and short timeframes.
Node-RED: The IoT Programming Language No One is Talking About
Sussing out the key pieces of the Internet of Things is usually accompanied by caveats ranging from the established uncertainty of the future, the security problems of the present, and the legacy system integrations of the past. Industry gurus and thought leaders predict growth in the billions – dollars, devices, deployments, Cloud applications, etc. Networking experts waffle on standardization. Hardware providers sprint to keep up. But one of the critical pieces of the Industrial IoT is something you won’t find jumping off front-page headlines – yet: Node-RED, the programming tool for wiring together hardware devices developed by IBM, is the power behind the IoT throne, and no one is really talking about it. Lost amid the noise about ‘smartifying’ the world is the practical reality that unless you can figure out a way to seamlessly connect the hardware devices that comprise a smart network, you are essentially relying on the Cloud to run an overwhelming number of disparate applications – and that is assuming your network is near invincible. Since the Industrial IoT relies, in theory, equally upon Cloud and Edge device processing, developing software applications that can effectively run in both settings is crucial. This is where Node-RED comes in. According to Nodered.org, the open-source Node-RED ” … provides a browser-based editor that makes it easy to wire together flows using the wide range of nodes in the palette that can be deployed to its runtime in a single-click … [making it] easy to wire together flows using the wide range of nodes in the palette.” The essence of this tool is that engineers and operating technicians can create and configure applications easily, in real time, on Edge devices. Ideally, the pieces of code being used to create programs are reusable, meaning that the process can be learned by field operators without the need for a degree in computer science. The code is built on Node.js, the JavaScript runtime that frequently pops up on Raspberry Pi platforms due to its ease of use. So, if it is so easy, and so important, why is no one talking about it? The ongoing problem for the IIoT is the Wild West mentality: the no-holds-barred land grab has resulted in disparate hardware and software products that often require a combination of proprietary and open-sourced solutions. As a result, the actual mechanisms that drive the building of an IIoT network are often less talked about than the tangible pieces that come together to build that network. There are several considerations to keep in mind. First, the idea of IT/OT convergence has only just started to gain traction, so legacy solutions (especially in certain industries) haven’t quite crossed the threshold of multi-function. Second, the changing demographic of the workforces in the industrial sector means that the traditional gatekeepers, often not versed in software or computer programming, have been loathe to adopt solutions that require a whole new skill set. The result is that the idea of programming between devices and Cloud applications is in a relative infancy. Third – and still related to the workforce demographic – creating an entire workforce of people versed in both hardware engineering and computer programming is impractical. Those factors, along with several others related to the need for network functionality and data analytics, means that a solution like Node-RED is still not completely understood, and perhaps even more pertinent, still not widely adopted by industry leaders on both the hardware and software side. But it also means that it is more necessary than ever.