You’re sitting in your cubicle working on a zigbee driver for some connected “thing” when you decide to see if Google can provide any shortcuts. After some searching you don’t find exactly what you’re looking for, but you do come across a webpage from 2014 entitled, “zigbee Certified Products Surpass 1,000.” For a moment you wonder how many products zigbee has certified since then, until it hits you: “How many times has a zigbee driver like the one I need been written?!”

When we talk about interoperability and the Internet of Things (IoT), we’re usually talking about networking: Technical interoperability of the underlying network infrastructure to enable information exchange; syntactic interoperability that leverages common data structures so that information traversing a network can be recognized by different systems; and semantic interoperability, which allows meaning to be extracted from transmitted information.

Less frequently addressed, however, is interoperability between the components used in developing a system, particularly those that exist within embedded devices at the IoT network edge. Here, countless adaptations of silicon, software, and connectivity have been cobbled together by engineers with slightly different drivers and application programming interfaces (APIs) that, more often than not, perform fundamentally the same functions. It’s not uncommon to find interoperability issues further up the IoT stack rooted in this process.

That’s not interoperability. That’s just engineering… right?

While low-level software development is innate to embedded systems engineering, the market will always favor solutions over enablement. The perception is that time spent on component integration is time lost developing value-added software and services, and that customers pay for connected lighting applications, not zigbee drivers. Add to the equation that many utilities resemble ad hoc versions of industry standards, and what you have is reinvention, not innovation.

In an effort to turn this paradigm on its head for the IoT, The Linux Foundation, with support from 50 companies, launched EdgeX Foundry, an open source initiative focused on improving interoperability through a hardware- and operating system-agnostic edge software platform. The foundation of the EdgeX Foundry software platform is based on Dell FUSE middleware, a code base made available under the Apache 2.0 license that enables a set of loosely coupled, plug-and-play EdgeX Foundry microservices that are compatible with programs developed in any language or application environment through a set of common APIs.

As seen in Figure 1, the core services of EdgeX Foundry, including the pictured microservices as well as APIs for data flow and system management, security, and developer value add, actually exist at the IoT gateway layer given the resources they require. But, for more constrained devices at the edge, the EdgeX Foundry platform also incorporates a device services software development kit (SDK) that not only provides a standard methodology for creating compatible device drivers, protocol support, and the like, but also allows for the development of optimized services capable of running independently on sensor nodes that communicate directly with northbound core services. In each of these instances interoperability will be maintained through an EdgeX Foundry certification program.

[Figure 1 | The EdgeX Foundry platform architecture provides a foundation for IoT interoperability based on a set of loosely coupled microservices and APIs.]

Does EdgeX have the X factor?

When peeling back the onion, the EdgeX Foundry value proposition is another attempt to apply IT principles to the embedded IoT. Like Cloud Foundry, EdgeX seeks to decouple IoT hardware and software, maximize interoperability and reuse around standard components, and accelerate innovation on top of that generic framework.

Of course, this type of strategy has been proposed to the embedded space before with marginal success, largely due to the incredibly diverse requirements and use cases of embedded systems. For example, there may be very good reasons for a custom driver or modified application call within an embedded system design, which is a foreign concept to IT professionals. Other questions revolve around the rigidity of the device SDK and capabilities of the applications developed therein; how the stack can handle gateway-less architectures; and how much system integrators stand to loose. As two very different ends of the technology spectrum continue to collide, only time will be able to provide answers.

Watch Rich Nass of Embedded Computing Design and Jason Shepherd, Director of IoT Strategies for Dell, take EdgeX Foundry for a test drive.

[youtube=https://www.youtube.com/watch?v=7GM8ZS1pVYc]