IoT Reality Check: What Happens When the Software Doesn't Work?

To get the Internet of Things right, you need to get the software right.
By Jyoti Bansal

Look at General Electric, a leader at the forefront of the industrial Internet of Things. The company is putting sensors in everything—turbines and locomotives and all the things it makes—and yet its CEO, Jeffrey Immelt, is quoted in the New York Times as saying GE will be "a top 10 software company" by 2020. That's an amazing statement coming from one of the world's leading manufacturers.

So simply put, to get the IoT right, you need to get the software right. But as any enterprise CIO, developer or IT operations team will tell you, that is no easy challenge, even for software running in a data center, much less in the wilds of the thing-net.

A Hard Look at IoT Software
The issues that can plague IoT software are no different, really, than those that can negatively impact any enterprise software-development project or ongoing deployment. The pace of new feature development needs to remain insanely fast just to keep up with competitive pressures. The code can be less than perfectly written. New releases and updates—which are essential to keep IoT devices functioning and to remotely upgrade existing hardware with new capabilities—can inadvertently break something that worked before. Scan the tech headlines or the Apple message boards. It happens all the time.

Sometimes, a perfect storm hits with just the right combination of factors, whether it's environmental thresholds like temperature, or unusual traffic volume, or some other anomaly that befuddles or breaks the software only in those specific circumstances, and couldn't be (or wasn't) anticipated in development.

Why Is IoT Software Such a Challenge?
Besides all the issues that normally affect software, the Internet of Things introduces a host of additional challenges, including:

• It is inherently distributed and complex, with numerous interrelationships between hardware, software, network devices and the back end that is running things.
• There is typically a high degree of geo-complexity, with devices and their supporting systems separated by great physical and logical distances.
• Further complicating geo-complexity, the devices themselves are often literally on the move in a vehicle or some other form of transport.
• Waning battery power must prioritize functionality over monitoring, thereby slowing or halting the stream of performance data necessary to manage the software.

If a problem is found in the software connected to remote devices, troubleshooting presents its own unique challenges. Among them:

• If the issue is with equipment, it could be far away or difficult to access.
• Actively troubleshooting an issue can consume excessive power at the endpoint device, potentially creating additional problems.
• Agile software cycles can introduce unexpected glitches.
• Non-standard connectivity protocols can make it difficult to remotely remedy software embedded in devices or otherwise remote.

JOIN THE CONVERSATION ON TWITTER
Loading
ASK THE EXPERTS
Simply enter a question for our experts.
Sign up for the RFID Journal Newsletter
We will never sell or share your information
RFID Journal LIVE! RFID in Health Care LIVE! LatAm LIVE! Brasil LIVE! Europe RFID Connect Virtual Events RFID Journal Awards Webinars Presentations