IoT Platforms – Part One: A Framework for Understanding This Maze

IoT Platforms Everywhere

With the rising popularity and hype over IoT, providers of a very broad range of types of technologies have taken to calling themselves “IoT Platforms” or something similar. In fact, virtually the same terminology is being used to cover so many different of types of technologies that we felt a compelling need to help people understand and sort through the different types of solutions and services comprising IoT Platforms.

Who Uses IoT Platforms?

The main users of IoT Platforms are people developing IoT applications and IoT-enabled products and services. And right now lots of people are very busy developing IoT offerings including:

• Physical product companies — manufacturers of all manner of physical products are implementing IoT-enabled features, as well as building IoT-enabled services around those. This includes makers of vehicles (trucks, aircraft, cars, ships), building components and systems (HVAC, lighting, elevators, security, etc.), city systems (traffic controls, waste collection, street lighting, etc.), mining equipment, agricultural equipment, home appliances, electronics — a virtually endless list. They are all getting into the IoT game.
• Service providers — especially providers of services involving physical ‘things,’ such as field service/maintenance and repair, transportation and logistics services, real estate and facilities management, hospitality, waste collection, and so forth; many of them are actively seeking ways to differentiate their businesses.
• Software companies — many established software firms as well as startups are incorporating IoT functionality into their products.

Build vs. Buy

Companies looking to expand into IoT-enabled features or services face a decision whether to build it themselves or use an existing IoT application or service. For example, a logistics provider could build their own application. Or they could look to an existing provider, such as Savi or TransVoyant or Descartes, who have already invested heavily to solve various logistics problems using IoT technology.² If they cannot find a solution, then they may develop it themselves.

Challenges of Building an IoT Solution

Without an IoT platform, the challenges of building an IoT solution are enormous.These include things like:

• Diversity and number of devices — applications that need to work across a variety of scenarios have to interface to myriad devices — potentially many thousands of variants. Managing all those devices requires administrative infrastructure as well. Why build that from scratch if you can get it from a platform?
• Managing communications complexities — an extension of the challenge of dealing with thousands of devices is managing their communications, including creating a solution that works globally with different carriers, monitoring performance, and optimizing communications costs.
• Developing the application logic UI and database — these can be built from scratch using conventional tools, but integrated development platforms designed specifically for IoT greatly accelerate the process.
• Developing analytics — IoT analytics have specific characteristics not found in traditional analytic platforms, such as dealing with real-time streaming data, geo-spatial data, enormous volumes, etc. Furthermore, domain-specific IoT analytic platform providers can amass libraries of pre-built algorithms, queries, dashboards and tools, saving a tremendous amount of time for their users.
• IoT Infrastructure — a significant amount of back-end infrastructure is needed to pull this off, including servers, data centers, communications services, security policies and systems, administrative staff, and so forth. Many if not most platform providers run the backend for you, accelerating deployment greatly and reducing capital expenses and hiring commitments.

Thus IoT Platforms perform a critical function in helping accelerate and reduce the cost of developing IoT-enabled products, services, and applications.

Evolution of IoT Development Tools

A complex stack of technology is needed in order to create the magic that end-users see (or hope to see) in IoT applications. Two or three decades ago, if someone wanted to develop an IoT-enabled product, application, or service, they had to assemble or create many or most of those pieces themselves from scratch. Today many of these pieces are available within various IoT platforms that can be purchased or subscribed to.

Most IoT-enabled products or services — and the underlying engines, services, and end-to-end components needed to support those products — use functionality from almost every box in our framework. Many of these functions and components can be obtained using some combination of IoT platforms. A few IoT platforms focus on one specific portion of the framework, but far more of the platforms span across multiple boxes, integrating various pieces of the solutions. That complicates the process of selecting the right platform, or more likely set of platforms, for any given application.

Most platforms also tend to have a heritage in one of these boxes; a ‘center of gravity,’ if you will, from which the rest of the platform is built. So, for example, in this series of articles we might characterize a particular platform as being an IoT Communications Platform (because that is its heritage and strength), but that platform may also offer development tools and a storage platform. Some platforms are hardware-centric, others focus on device connectivity, others on communications, or the development platform, or analytics. Here we will start at the bottom of the stack, the hardware.

Hardware — the ‘Body of IoT’

The Internet of Things is about smart physical objects connected to the internet. That requires hardware components, such as sensors, processors, controllers, communication hardware, local communication buses, and so forth. In fact, one indicator of the growth of IoT is the sales of embedded microprocessors, which are core to many IoT-enabled systems. These are expected to surpass all other types of processors in dollar sales this year or next year and already far surpass all the other categories of processors in unit sales.

IoT Platforms from the Chip Makers

Most makers of embedded microprocessors and other key electronic components offer families of IoT products, such as those from TI, Qualcomm,³ and Freescale, as well as IoT component collections from distributors like Avnet Memec and Arrow Electronics. A few semiconductor companies are building comprehensive IoT platforms around their core hardware component offering. One example is ARMs mbed IoT Device Platform. ARM is by far the most popular embedded microprocessor architecture; over 50 billion ARM processors⁴ had been produced as of 2014. Their IoT Platform⁵ consists of the mbed OS for the ARM processor; mbed Device Server providing device protocols, device management, and many other services; mbed Tools, a complete web-based IDE; and a set of references applications. Further, they have assembled an ecosystem of partners including Cloud Partners (Operators, Backend IoT Services, and Cloud Service Providers), OEMs, ODMs, system integrators, and component providers (processors, sensors, actuators, modules, etc.).

Intel announced their IoT Platform in December, 2014. Intel describes their IoT Platform as “an end-to-end reference model and family of products from Intel — that works with third-party solutions … ” Since Intel’s main goal is to sell more chips, it is not surprising that, like ARM, their approach is to provide the core microprocessors and some enabling software, but rely on others to use reference designs and partners to build out the solution. In their product brief, Intel lists six IoT components. Central to these is Intel’s IoT gateway,⁶ which uses an Intel processor to provide device protocol abstraction, local processing and analytics, communications, hardware-based security features, and edge management features. We will talk more about IoT gateways in a future part of this series. Intel also provides Analytics Services for developers to use in the gateway, Enhanced Privacy Identity (EPID) technology to secure the gateway, Wind River Edge Management System⁷ (providing device management, connectivity and middleware, analytics, and additional security features), Mashery⁸ API Management, and McAfee⁹ Secure Fabric Platform. These last three are all acquisitions and show a grasp of pieces that will be critical for IoT success — managing billions of devices, managing a sea of APIs between different systems and layers, and keeping the whole thing secure (successful hacking of a plane or car could be deadly).

For both ARM and Intel, their core product is the microprocessor that will go into the bottom-most layer of our IoT technology stack. However, their IoT platforms touch many of the other layers of the solution stack — actually virtually all layers if you include the parts provided by the ecosystem of partners they’ve assembled. Samsung has also developed their IoT Platform, which seems to be more oriented towards phones and consumer appliances.

IoT Hardware Prototyping Kits

In addition, there are numerous hardware prototyping kits/platforms for IoT applications. These are quite varied in their capabilities and focus. Many are open source platforms, initially created for education purposes, and most are pretty affordable (in the $20-$60 range). Examples include Arduino Uno, Raspberry Pi, BeagleBone Black, mbed LPC1768 (part of ARM’s mbed platform) and dozens more.

Device Management

Dealing with the Universe of Heterogeneous Devices

Depending on how you define and forecast ‘things’ or devices, predictions of the number of IoT devices by the end of this decade are generally in the range of 25-75 billion devices. These types of numbers and large scales create challenges for IoT developers. Besides the sheer volumes, there is the daunting variety of things. This places heavy demands in deploying, commissioning, managing, updating, and maintaining all of these devices. These requirements span across a huge variety of scenarios and use cases with different requirements: from individual home owners trying to manage all the devices in their smart home, to businesses trying to manage their fleets of smart vehicles, smart buildings, and other assets, to manufacturers and service providers who need to manage and optimally maintain smart products out in the field. All of them need unified ways to manage the devices within these ‘things.’ No IoT administrator wants to have to deal with 100 or 1,000 different administrative interfaces — one for each device. Hence the need for an underlying device management platform. It would be crazy for each IoT application developer to create their own device management platform, so they look to third party IoT Device Management platforms.

Device Abstraction, Normalization, and Standardization

Developers of IoT applications face a further problem from the immense diversity of devices. They need to write code that can communicate with an enormous variety of types of devices. This includes many legacy devices that only speak proprietary/legacy protocols (for at least the next decade or more there will still be plenty of those).¹⁰ Developers need software code that can discover, connect to, receive data from, send commands to, and manage these devices all in a secure and normalized way. It would be insane for each new IoT application developer to have to write their own library of code for each new type of device they encounter. That is why IoT developers need some sort of abstraction and normalization of the interfaces, so their code can talk to all devices of a specific class in the same way (for example a class of device might be a thermostat; the developer wants a standard way to find out the current temperature, regardless of the make or model of thermostat). This need for abstraction exists on many different levels in an IoT architecture.

Device Standards

Establishing standard protocols is one way to skin this cat. In fact, a number of IoT device protocol standards already exist and more are being developed. Examples of existing protocols¹¹ that can be useful to IoT applications include:

• DDS (Data Distribution Service): a local machine-to-machine protocol, integrating devices with one another
• MQTT (Message Queue Telemetry Transport): collects device data and communicates to servers, was designed for remote sensor nodes, conserving power and memory use
• CoAP (Constrained Application Protocol): lightweight protocol for simple devices to communicate over the internet
• AMQP (Advanced Message Queuing Protocol): a queuing system for message-oriented middleware, generally used a little higher in the stack, for example to connect IoT gateways to servers

Device Interface Service

Standards alone cannot solve the problem, at least not in the next many years, because there are so many legacy devices. For this reason, many IoT Platforms include some sort of device interface services that provide the needed abstraction and normalization. They provide a framework to build new connectors as needed and collect an ever-growing library of connectors to different types of devices. Examples of IoT Device Management Platforms include those from Zatar, Etherios, DCN, Wind River Edge Management, RacoWireless, Cumulocity, Eurotech, and Xively. Device management and interfacing are by no means all that these platforms do, but the device layer is central to many of these platforms. There are many other IoT platforms with device interfacing layers in them.

IoT Communications Platforms

The communications link, between the ‘things’ and internet, is a key part of IoT. Some IoT platforms assume that communications link between the internet and the ‘thing’ already exists and is being managed, and they focus instead on solving other problems as we have been describing. But some IoT platforms focus specifically on providing the machine-to-machine communications services needed to make it all work. This is a natural area for wireless carriers to jump in, hence we see IoT Communications Platforms such as Vodafone M2M , AT&T M2X, Verizon M2M, T-Mobile M2M, Sprint M2M, Singtel M2M, and many more.

In addition, there are a number of carrier-independent providers of IoT communications services, designed to provide management of multiple cellular carriers. Examples include Arkessa, Jasper, RacoWireless, and Aeris. As with other areas, the boundaries and functionality of these solutions varies. Common functionality for IoT communications platforms include:

• Cellular communications services (e.g. CDMA, GSM, 4G LTE, etc.) — especially the carriers, but also some of the independent providers will provide the actual cellular services for the IoT devices. Some services allow multiple carriers services to be used, providing redundancy so that the strongest signal or most economical channel can be used.
• Cellular device management — communications platforms specifically focused on managing devices that use the cellular services. This can includes full lifecycle management, such as provisioning and decommissioning as well as dashboards, alerts/exceptions, and reports.
• Cost/rate management — analyzing device usage and adapting to the carriers’ various plans to optimize cost
• Global SIM — the ability to operate worldwide on a single SIM
• Cloud services — collection, storage, analysis of IoT data. May include a rules engine for filtering and alerting.
• Diagnostics — troubleshooting and fixing issues on devices

The carriers have varying strategies and some offer quite a bit of functionality beyond the services listed above. For example, Vodafone offers application-specific solutions such as asset tracking, smart grid and smart meters, energy data management, smart cabinets, M2M terminals, and more. AT&T’s M2X is more of a development platform with libraries, device support, security, a developer portal, data storage, and a developer community.

Compared to cellular-based IoT communications platforms, we have not seen as much investment yet in platforms focused on satellite communications, perhaps because of the relative cost of those services. Satellite services can be an important piece of the puzzle for IoT applications in remote locations outside cellular coverage, such as oil platforms, ocean vessels, mining, and logging operations.

Many Pieces to the Puzzle

This first article in our IoT Platform series introduced the overall framework and covered hardware platforms, device management platforms, and communications platforms. We have already seen that, regardless of the core focus of the platform, they very often overlap with other areas in the framework. Platform providers have different visions of what problem they are trying to solve, for whom, and for which range of IoT applications. They often also want to leverage the underlying technologies and assets they have already in their portfolio. And they take into consideration their business model, current customers, and where they want to go next. When evaluating platforms, it pays to take the time to understand all these things. It is a critical decision for an IoT developer. The relationship between the IoT application developer and the IoT platform provider is a long term ‘marriage’ — divorce (i.e. switching platforms) can be messy, expensive, time-consuming and painful.

In Part Two, we look at Local Intelligence Platforms and IoT Gateways.

In future installments of this series, we will explore some of the other types of IoT Platforms, including IoT development platforms, IoT data storage, and IoT analytics platforms.

______________________________________________

¹ IoT-enabled products include things like a driverless truck, smart appliance, and so forth. IoT-enabled services are things like predictive maintenance, building energy reduction services, etc. IoT-enabled software applications include things like real-time logistics, intelligent inventory, smart parking, and the like. — Return to article text above
² Some of these, such as Savi and TransVoyant, serve a duel role as both a purpose-specific application, but also as an extensible platform that allows the user to build their own applications or variants. — Return to article text above
³ Qualcomm was instrumental in forming the AllSeen Alliance, a set of IoT open source technology and standards, primarily based on the AllJoyn platform contributed by Qualcomm, providing interoperability among IoT devices. Intel has formed a competing open-source initiative the Open Interconnect Consortium. We will discuss these initiatives further in a future installment of this series. — Return to article text above
⁴ ARM does not manufacture the processors, but licenses their RISC chip designs to semiconductor manufacturing companies who fabricate the chips. — Return to article text above
⁵ The mbed OS runs in ARM’s Cortex-M-based 32-bit microcontrollers. Mbed Device Server implements various device protocols to talk to IoT devices and various services including directory services, device management, data flow, subscription management, security, and administrative, all accessed through a REST API . Mbed Tools includes a complete web-based IDE and developer website. References applications include Connected Home Reference App, Street Lighting Reference App, and others. — Return to article text above
⁶ It appears that Intel is not actually selling the gateway directly themselves, but rather relying on ODM (Original Design Manufacturer) partners to produce it. In their December 2014 press release they said, “Intel IoT Gateways are currently available from seven ODMs with 13 more releasing systems in early 2015.” — Return to article text above
⁷ Intel acquired Wind River in 2009. — Return to article text above
⁸ Intel acquired Mashery in 2013. — Return to article text above
⁹ Intel acquired McAfee in 2011. — Return to article text above
¹⁰ Keep in mind that some applications of IoT, such as managing an office building, entail devices that are replaced only after decades of use. So even ten years from now, some IoT applications will still have to interface with many devices made in the last century. — Return to article text above
¹¹ These protocols examples do not address the semantics of the data from the device. A higher level of protocol and an agreed ontology is needed for that. — Return to article text above

To view other articles from this issue of the brief, click here.