From a business perspective, much of Internet of Things (IoT) development isn’t new. Wireless and even mobile Internet connections are mature technologies, and embedded processors go back further still. For industrial markets, the “Industrial IoT” has replaced “SCADA” (supervisory control and data acquisition) as the control system architecture using computers, networked data communications, and process supervisory management to control peripheral devices (the ‘things’ of IoT) in large plants. So what’s new?

What’s new is the combination, and the novel challenges that come with it. Namely, supporting all the services and business models on which companies have come to rely when running on stiflingly designed to cost and/or low-power connected systems.

It’s challenging, time-consuming, and costly enough to make these connected devices in the first place. But that’s only half the story. Like all software products, smart devices need post-launch support and features if they are to stay competitive. Furthermore, any business model that goes beyond the initial product sale — selling apps, streaming content, pay per use, etc. — will require regular updates. And what if that business model changes?

In opposition to the rest of the digital world (PCs, smartphones, servers, etc.), most low-power embedded systems usually don’t run an application platform. This means the product’s software isn’t nicely architected with clear boundaries and interfaces (APIs or ABIs) to separate concerns. Adding/fixing a feature means updating the whole product, with all the extra (exponential) debugging and validation that entails.

It’s not only irritating to the marketing team that never gets their wishes on-time or on-budget, but it is also annoying to the end user who needs to download a large firmware updates and restart their device for it to take effect (often resetting their configurations in the process). To top it all off, embedded programmers aren’t cheap, owing to the difficulty and wide range of expertise needed for the job.

But a slight change in scenery can fix all these problems at once. Specifically, the binary building blocks of IoT should be developed and deployed in individual sandbox environments, all on top of a virtualization layer running semantically managed code. With minimal overhead, embedded binary building blocks (often called apps) sandboxed this way can be placed together to build the device much like one would build a Lego set — a comparison that remains apt post-launch as well, as the device can be later modified as quickly and freely as a mobile app, giving the business that made it more flexibility and fewer expenses.

It’s simple to deploy to a sandbox

This technique is a far cry from how it’s used in DevOps, where sandboxing is the most common. Same goes for its use cases and rationales. But the purpose is much the same. As mentioned, it’s the lack of isolation (cpu, memories, peripherals) in embedded systems that make it so complicated to update. By removing dependencies on both the whole program and its specific toolchain, this combo of virtualization and sandboxing lets developers break a program into smaller binary building blocks and only work on the binary building blocks relevant to the new feature or update.

Consider the ease of updating an app for mobile platforms, where this isolation is already built into the environment. If, say, the creator of Angry Birds wants to add a new bird to the game, she only has to touch the code related to the app itself – no need to access the Android kernel (or even understand it for that matter). To deploy it, she only has to pass a quick round of validation and push the app to the shelf of the targeted ecosystem (here, an application store on the cloud). From there, devices can be updated seamlessly, probably as a background process.

Nothing about updating/upgrading/fixing embedded firmware is that easy, but it’s the experience developers can have when each binary building block is sandboxed. Like their namesake, everything becomes simple and incremental: updates, tuning, debugging, add-ons, etc.

Simplicity for the developers and end users isn’t the only benefit to sandboxing in this way. As you’re able to do partial software updates on embedded systems, it also saves on bandwidth at deployment time. In addition, sandboxing lets you set strong permissions for a given binary building block, saying when binary building blocks can and cannot access other binary building blocks, as well as their access to resources like CPU, RAM, or hardware peripherals.

How to build sandboxes for software building blocks

The virtualization layer beneath the sandboxes is key. It not only enables the sandboxing on small processors that don’t provide memory management units (MMUs), but it is already a step toward the goal of reducing post-launch expenses. A virtualized Java environment, for example, can take advantage of more modern code practices for simplicity, reusability, and abstraction, and allows a development team to be comprised of programmers that are in far greater supply. It also adds to the security of the device for many of the same reasons as sandboxing does.

A natural push back might be that a virtualized environment and a sandbox layer would add costly overhead, especially for very small systems like wearables or battery-operated sensors. However, software on the market today can handle these environments with mere kilobytes of flash footprint and very little extra RAM. A typical sandboxing layer, built on top of a virtualization layer, together weigh less than 45 Kb.

So where do the dollars come in?

Three places. First, as soon you deal with sandboxing and virtualization, you enter into an economical industrial process where you reuse the binary building blocks created that have now been made available on your company’s “shelf.” This is in fact one of the biggest assets a company can have. And because virtualization always comes with simulation – the binary building blocks can run on a virtual device as if they were running on a real device – it greatly lowers a project’s financial risk as it’s easier to validate a specification upfront. The gains are well known: more market share, more margin, and more speed.

Second, the combination of virtualization and sandboxing cuts down on money spent keeping the connected device up-to-date and competitive. As stated earlier, when updating/fixing your device is as simple as updating an app, you bypass the time-intensive process of modifying, testing, and validating the entire firmware. The gains apply on R&D and maintenance costs.

Third, it opens entirely new revenue streams post-launch. Being updatable, a device can integrate an ecosystem where “pay per use” of new services is the rule. Your marketing teams can easily test new ideas by adjusting the product to customers’ usages while charging a fee each month; you could sell subscription services, giving access to web-based services like monitoring, alarms, or streamed/downloadable content; or you could tie it into a larger business model – one of our own partners, a subsidiary of a utilities company, used this approach for a device that helps owners manage their gas bill. The gains are new revenues streams.

Best yet, you can change your mind. When designing/updating a smart device is as big of a commitment as it is now, a new competitor or sudden change in consumer demand means cutting deep into your margins to keep up. Post-launch flexibility via sandboxing and virtualization allow you to be as agile as you can be with software products running on much larger devices.

Profitability is the only barrier left on IoT’s path to ubiquity. If I had to guess, I’d say that 80 percent of smart device companies around right now will fail. Not from poor technical knowledge, but by bleeding to death on tiny margins. The current market will only pay so much for a smart device, which is only barely above the (current) average cost of development.

Forcing the market to bear higher prices would take either a monopoly or a miracle. But as we saw, every other path to profitability just takes software. The sandbox/virtualization combo is all about being fast; low cost (by reusing binary building blocks); low risk; agile to the market’s evolution; and optionally allowing new, recurring revenues. It’s a simple software solution for a complex economic problem with no real downsides. The sandbox/virtualization combo is the final “block” needed to turn IoT devices into profitable businesses.

Fred Rivard is CEO of MicroEJ.

MicroEJ

www.microej.com

@microej

LinkedIn: www.linkedin.com/company/microej

Google+: plus.google.com/+Is2t_News

YouTube: www.youtube.com/user/IS2Tsa