First choose your map - then find your place on it

To explain your place in the world, first choose a “map” that everyone agrees on, then you can point at your place on that map.  And see how far away you are from other points on the map. For technology blocks, a map can take many forms, e.g. a Venn diagram, a hierarchy, or a dataflow diagram. Probably the most generally-useful technical map is the architecture diagram, which reveals the functional blocks and how they interact. It may also incorporate an axis which represents each block’s position in the technology “stack”: from low-level technology like embedded software (usually shown at the bottom or left), to high-level technology such as applications (usually shown at the top or right of the diagram).

Unfortunately there is not yet one single, generic IoT architecture diagram that everyone agrees with. We drew one in our post The Architecture of a Modern IoT System, and MachNation have also produced a useful block-based diagram. However when considering where a specific IoT block from a particular vendor would go, you find that often it doesn’t map perfectly onto these generic diagrams: either the block doesn’t seem to have a place at all, or it spreads across multiple blocks on the diagram.

We believe that eventually there will be a generic architecture diagram for IoT (perhaps more than one - but not hundreds of them) and it’s a worthwhile goal to work towards. Its existence will make it far easier for vendors, customers and partners to identify each other, and thus accelerate the IoT ecosystem. This will be achieved partly by improving the maps, but also partly by vendors adjusting the shape of their block to fit the map (often by doing less, better) ... and thus an ecosystem of interlocking standard parts emerges.  

In the meantime, let’s take two specific IoT blocks and see how they work together: are there gaps between them, do they overlap?

Here we’ll compare ARM’s Pelion IoT platform with DevicePilot’s Service Monitoring product - and find that they are very complementary.

ARM Pelion

ARM has a strong history as the main provider of processor cores to the IoT world, so naturally they started at the device “end” with their mBed project which provides a standardised IoT device architecture. Just as the Windows/Mac operating system lets you plug in a mouse and have the right software drivers make use of it, mBed is a software framework for building IoT devices in an open, modular way which makes it possible to change or add individual hardware or software elements, yet still have the whole thing “build” and be deployed in a uniform way. The world of mBed is therefore a very low-level world, which deals with software drivers for specific hardware peripherals and comms protocols such as LoRAWAN or ZigBee etc.

Pelion extends mbed. The Pelion website homepage shows the architecture diagram below, which explains how Pelion extends mBed (left) with a complementary set of cloud services (right).

Pelion's cloud services offer three kinds of management:

• Data Management - analytics and machine learning (via their acquisition of Treasure Data)
• Device Management - e.g. uploading new firmware into devices
• Connectivity Management - e.g. provisioning the SIM card on your device (via their acquisition of Stream Technologies)

ASIDE
It makes a lot of sense that ARM has extended their IoT offering into the Cloud, because it allows them to offer a more “complete” platform. In particular, a vitally-important topic in IoT is security, which is always an end-to-end problem, so by offering both the ends, ARM helps its customers to get this right. However, this move also takes ARM firmly into the realm of the Cloud, where they have no history, and into direct competition with AWS IoT and Azure IoT. To companies deploying IoT devices, ARM seems to be saying “let us do everything for you”, and likewise AWS and Azure have been moving into device territory by releasing open-source device solutions such as Free RTOS and Azure IoT Edge. Most people building a cloud solution would choose AWS/Azure. Most people building an IoT device would choose ARM. So it looks like a Battle Royale is shaping-up.

How will it all pan out? Which horse to back? My view is that AWS and Azure will not cede the cloud side to ARM, and ARM will not cede the device side to them. Both sides have incredible strength to defend their own territory, and are quite weak in the other. There is definitely a place for ARM’s cloud-side offerings, but they probably need to run within AWS/Azure (and map nicely onto their paradigms), and likewise AWS/Azure need to get better at working with ARM’s blocks and hardware out-of-the-box. In the IoT ecosystem, as in so many others, "playing well with others" is probably the way to win.

DevicePilot

In contrast, DevicePilot Service Monitoring is a product - and one which can be used with any platform, to add value to it. 

Let’s imagine you’ve used Pelion to build your IoT device, and you’ve gone through trials and are now “scaling-up”. During the trials phase you’ll have used lots of manual processes (checking if devices are working, understanding how users are interacting with them, deploying new firmware to fix bugs etc.). But as you start to scale-up into production, manual approaches fall-apart, badly. As soon as you have more than say 1,000 devices then no amount of spreadsheets, email or daily meetings will compensate for the absence of a decent tool to manage your overall device estate and customer experience.

That missing tool is Service Monitoring. It’s used by the people who have responsibility for customer experience (customer support, operations, product management). They define important customer-happiness metrics (e.g. uptime, availability, charge delivered, whatever) and then maintain live operational dashboards of those so that everyone can see at a glance if everything is on track, and if not why not.

Service Monitoring also enables business process automation, which enables your business processes (including business tools such as CRM tools), to automatically be triggered or updated in response to changes in individual devices, or whole sets of devices.

Service Monitoring results in increased revenue, lower costs and faster growth, by letting the customer experience drive the company to ever-high levels of service quality and efficiency.

So although a good Service Monitoring package does allow exploration of individual devices for customer support or technical diagnosis purposes, more generally it’s operating at the bigger-picture level, showing the situation of the whole device estate, or parts of it. It lets you see the wood for the trees. If you have 10,000+ devices, then individual devices will constantly be having issues, and a stream of notifications about these is too much for a human to cope with. But you can automate with these, and then instead the human can operate at a higher level, and only intervene when novel issues occur for which there are no automated processes defined.

How do DevicePilot and Pelion connect?

In terms of dataflow, DevicePilot ingests data from a broker within the Pelion architecture, in just the same way as the end-user application does. Devices post to the broker, and anyone who cares can then subscribe to that. Typically the broker in IoT architectures uses MQTT (see diagram), though ARM prefers CoAP. DevicePilot is agnostic so it can ingest from anything. 

So here's a basic diagram of the relationship between Pelion and DevicePilot:

Both ARM and DevicePilot both use the term "management" - but there are many different sorts of management.  Service Monitoring is a much higher-level of management than the Device Management and Connectivity Management found in Pelion. Indeed, DevicePilot can ingest data from these lower management layers, and control them (for example, to manage software updates or to use connectivity metadata to improve your device estate management).

Pelion's Treasure Data component is an analytics platform, so perhaps conceptually the part of Pelion closest to DevicePilot. ARM's sales documentation information pitches Treasure Data as a general analytics/ML platform, but in truth it seems focused ainly on customer analysis/engagement rather than service monitoring/device estate management. It’s a truism that while general-purpose analytics tools may be powerful, they are very hard for normal business people to use. What business people need is dedicated tools which perform particular everyday business tasks really well, and these two tasks are really quite different. A Treasure Data user is in most cases a product analyst or marketeer, whereas a DevicePilot user is generally in operations, customers support or Product Management.

How DevicePilot and Pelion are complementary

There is perhaps a tiny amount of overlap between Pelion and DevicePilot - but overlap is much better than a gap. In simple terms:

• Pelion provides much of what you need to build an IoT system.
• DevicePilot provides a big part of how to run an IoT system.

Although Pelion and DevicePilot are complementary, they are by no means everything you’ll need to build and run a successful IoT business. You’ll probably need several other business tools as well, for which DevicePilot can provide integration. 

If all goes well, then in the ideal case both Pelion and DevicePilot will remain entirely invisible to the end customer, manifest only in a user experience which is “boringly reliable”. And as someone charged with delivering an excellent customer experience, you’ll get your weekends back.

Please reach out to discuss further how Pelion and DevicePilot work together.