Chris Gammell

Developer Relations Lead at Golioth

Chris Gammell

@chris_gammell on twitter

• Developer Relations Lead at Golioth
• 20 years hardware development
• Worked at places like ABB, Samsung, Supplyframe, Keithley, Hologram
• Most recently was a hardware and firmware consultant.

https://golioth.io

IoT Services Are Not
Straightforward

Ask for help with "IoT" and you'll get 150 different service suggestions

(and none of those might be right)

Understanding Services
Can Prevent Future Pitfalls

A common tradeoff

• How much of a solution you can "Buy"

• How much you'll need to "DIY"

A good outcome for this session:

You know enough to be able to map a new service offering and know to ask about the missing pieces

Assumptions for today's examples

The device is always on

We're looking at cellular platforms

The platform we're going to choose needs some web interface

We're not going to be designing the web interface

Example product: Cellular
door lock / access control

This is a minimum set of requirements to narrow the field

If you don't have these requirements, it's a really good idea spending time going out and discovering them

"You have to 'buy in' at each decision point, but then you're stuck with it"

~ A friend with 15+ years of IoT experience

The 12 Layers Chart

Noticeably Absent

Layer 1: Hardware

Layer 1: Hardware

Overview

• The physical interface to the world
• Determines your ultimate device specifications

Layer 1: Hardware

Examples

• Custom
• Off the shelf
• Migration based (dev board -> module)
• Bought through cloud provider (verically integrated)

Layer 1: Hardware

Risks

• Custom hardware is expensive to develop and manufacturing can be fraught with issues.
• 2021/2022 has had many sourcing issues.

DIY

BUY

• The switching costs are extremely high.
• Choosing a piece of hardware from a cloud provider can influence the rest of the "layers" you use.
• Sourcing issues exist for purchased hardware too.

Layer 2: Device Firmware

Layer 2: Device Firmware

Overview

• The low level code running on your device.
• We define it as the summation of Real Time Operating System (RTOS), drivers, low level interfaces to hardware (HAL), and vendor contributed code.
• Could be locked into your vendor offering, if you are using a vertically integrated solution. 

Layer 2: Device Firmware

Examples

• FreeRTOS
• Zephyr RTOS
• ThreadX
• Particle OS
• DIY

Layer 2: Device Firmware

Risks

• Building from the ground up is a lengthy process.
• Every additional feature requires you write it from scratch, including peripheral and network support.

DIY

BUY

• Choosing an Operating System means you are at the mercy of the development path.
• Some RTOSes are owned by cloud companies, which means the most supported path will likely be their path.

Layer 3: Device Application

Layer 3: Device Application

Overview

• The higher level function and business intelligence running on your device.
• May be portable between different pieces of hardware (depends on the lower level device firmware/RTOS). In general, this layer of SW/FW contains higher levels of abstraction.
• May be possible to update application code without updating all code.
• For DIY solutions, depends on how you structure your code/project setup.

Layer 3: Device Application

Examples

• Particle Web IDE running Arduino software on top of Particle OS

• Toit device management running application software on top of a VM.

Layer 3: Device Application

Risks

• High levels of abstractions can make it harder to troubleshoot stuff "under the hood"
• Additional layers of SW/FW can consume more resources and drain batteries quicker.
• If defining your own application level code, it's important to draw boundaries in the correct places.

Layer 4: Connectivity / Security

Layer 4: Connectivity

Overview

• For certain devices, the connectivity is included and invisible to the user, such as WiFi device. Configuration is still required, but there is no external operator.
• For cellular and certain LPWAN platforms, the connectivity layer is something that needs to be considered.
• Some platforms bundle this with their services.

Layer 4: Connectivity

Examples

• Hologram management console of SIM cards

Layer 4: Connectivity

Risks

• Additional layer of management required, including if you need to build tooling into your management back-end.
• Less synchronization between data and device activation.

DIY (separate provider)

BUY (bundled)

• Limited to what the provider is offering, especially if there is no option to buy external data. 
• May not be able to cost optimize for large deployments. 

Layer 5: Configuration / State

Layer 5: Configuration / State

Overview

• This is what you need to be able to push and pull current state information from a device. 
• Both the device and the cloud have access to the same variables.
• Sometimes referred to as "Digital Twin".
• Want to be able to set the state and understand the current state at the same time. 
• Want some kind of message queuing to ensure delivery from cloud to device.

Layer 5: Configuration / State

Examples

• Golioth console showing LightDB state management options for a device

• AWS IOT Core Device Shadow (source)

Layer 5: Configuration / State

Risks

• Choosing a platform without a "command and control" option means you will need to build your own.
• Building from basic hosted elements (AWS, Azure, etc) will be a higher maintenance overhead and codebase.

DIY

BUY

• Vendor lock-in for all developed intelligence.
• More rigid method of implementing C&C on a device.
• If provider has some, but not all, required features, may still require custom development.

Layer 6: Time-Series Data

Layer 6: Time-Series Data

Overview

• Sending back streaming data and tagging each datapoint with the time it was received.
• Whenever you see a line graph visualizing something like temperature, it was likely built on a service such as this.
• This is one of the most common aspect of IoT platform services because of the expectation of being able to chart sensor data.

Layer 6: Time-series Data

Examples

• Adafruit.io back end processing of time-series data (source)

• Azure IoT Time Series Insights (source)

Layer 6: Time-series Data

Risks

• Choosing to go true DIY (running your own database) can be a DevOps challenge as you scale. 
• Buying a cloud service (AWS, Azure, etc) for this service can quickly spiral costs if rate limiting ins't in place.

DIY

BUY

• Rate limits may end up impacting your ability to capture all data you want.
• Needing higher rates may bump you into a higher cost "tier" as you scale.
• Watch your ingress  and egress costs on certain platforms.

Layer 7: Device Management

Layer 7: Device Management

Overview

• As your fleet of device grows, you want some way to view all of the devices that are part of a project or deployment. 
• Tools to specifically target a single device or subset of devices and take some action on that subset.
• Reporting "health" status of devices, often outside of the configuration / state data interfaces.

Layer 7: Device Management

Examples

• Blues Wireless Notehub interface (source)

• Blynk management of outside devices (source)

Layer 7: Device Management

Risks

• Some small projects don't think they need device mgmt at first, instead relying on scripting to ping devices; not a good idea.
• Differentiation likely isn't worth the time investment.

DIY

BUY

• Vendor lock-in
• If a particular platform is not built for the intended scale of the deployment.

Layer 8: Device Firmware Update

Layer 8: Device Firmware Update

Overview

• Being able to remotely update the firmware/software of a device is a critical function for any IoT deployment.
• Different platforms will update the device firmware (layer 2) and/or the device application (layer 3). 
• Versioning is an important aspect of an update system, so the correct firmware is downloaded to eligible devices.
• DFU is intertwined with Device Management.

Layer 8: Device Firmware Update

Examples

• Particle.io OTA firmware updates (source)

• AWS IoT Lens  (source)

Layer 8: Device Firmware Update

Risks

• Some small projects don't think they need device mgmt at first, instead relying on scripting to ping devices; not a good idea.
• DIY solutions have a higher risk of "bricking" a device because of less tested device and cloud code.

DIY

BUY

• Quotas around how much data and how often you can update a device might not fit your needs.
• May require deeper integration with a Device Firmware (layer 2) solution than you prefer.

Layer 9: Cloud Interoperability

Layer 9: Cloud Interoperability

Overview

• A benefit of most IoT device management systems is they move the burden of processing and routing information from the device to the cloud.
• Platforms ingest data from constrained devices and then have more power to re-transmit that data to other parts of the internet.
• Cloud providers "speak the same language" (HTTP) so it can be easier to pass messages between providers.

Layer 9: Cloud Interoperability

Examples

• Golioth.io Output Streams

• Blues Wireless Notehub Routes

Layer 9: Cloud Interoperability

Risks

• Trying to do this from the device would require changing out the endpoints your device hits.
•  

DIY

BUY

• This is another layer of software and management. 
• Systems that are closer to using raw web processing require much more cloud side code.

Layer 10: Deployment Flexibility

Layer 10: Deployment Flexibility

Overview

•  Probably the least thought of, but most important as your device / service / business starts to scale:
  • Can you expand as you want? 
  • What are the limits of your current service offering?
• Some IoT companies run into a roadblock at this stage and then start from scratch on a large scale solution--an all DIY solution with separate services for each of the 12 layers.
• Can you buy the service instead?

Layer 10: Deployment Flexibility

Examples

• Clearblade Enterprise Offering

• Golioth.io Extended/Enterprise edition (modern on-prem)

Layer 10: Deployment Flexibility

Risks

DIY

BUY

• Not many service providers offer this as an option...what then?
• Taking on more of the DevOps tasks.

Layer 11: API Access

Layer 11: API Access

Overview

• How do you access all of the data and command and control functions you have on your devices from an external source like an app? You need an API!
• This is the "cloud side" control of your fleet of devices.
• There are different methods of pushing or pulling data from a cloud platform, such as a REST API, WebStreams, WebHooks.

Layer 11: API Access

Examples

• Blues Wireless REST API

• Golioth.io REST API

Layer 11: API Access

Risks

DIY

BUY

• API Rate Limiting
• Usually you will not have input into the structure of the data.

Layer 12: Visualization

Layer 12: Visualization

Overview

• This is the method of charting and interacting with data, often for your end users.
• There are multiple offerings in the IoT space that start with this as the main feature and have gradually offered more features "down the stack". 
• Sometimes the visualization tools are more at a "platform" level and also offer secondary device management, for "your customer's customer".
• How end customers often think of "IoT"

Layer 12: Visualization

Examples

• Ubidots visualization and user management platform

• Datacake visualization platform

Layer 12: Visualization

Risks

DIY

BUY

• Often this is a secondary service you will need to purchase and export data to (higher system cost).
• Targeting a viz tool first might not have the other features explained in layers 1 through 11.

Resources

Golioth Blog

Chart

Case Study:
Particle Boron Device /
Particle Cloud

Layer 1: Hardware

Layer 2: Device Firmware

Layer 3: Device Application

Layer 4: Connectivity / Security

Layer 5: Configuration / State

Layer 6: Time Series

N/A

Layer 7: Device Management

Layer 8: Device Firmware Update

Layer 9: Cloud Interoperability

Layer 10: Deployment Flexibility

N/A

N/A

Layer 11: API Access

Layer 12: Visualization

N/A

Summary

• Pretty all inclusive offering due to the vertical nature of their platform.

• The risks are the same for any vertical platform: lock-in.

Case Study:
WiFi device talking to MQTT broker

Layer 1: Hardware

Layer 2: Device Firmware

Layer 3: Device Application

Layer 4: Connectivity / Security

Layer 5: Configuration / State

Layer 6: Time Series

Layer 7: Device Management

Layer 8: Device Firmware Update

N/A

Layer 9: Cloud Interoperability

N/A

Layer 10: Deployment Flexibility

N/A

N/A

Layer 11: API Access

N/A

Layer 12: Visualization

N/A

Summary

• Possible to script and tie together some of the features mentioned here

• All of the above "layers" were mostly focused on local control, taking this to the cloud would be an additional layer of difficulty.

• Since "scripting" is a common theme, this would be very difficult to maintain.

Case Study:

Golioth cellular device

Layer 1: Hardware

Layer 2: Device Firmware

Layer 3: Device Application

Layer 4: Connectivity / Security

Layer 5: Configuration / State

Layer 6: Time Series

Layer 7: Device Management

Layer 8: Device Firmware Update

Layer 9: Cloud Interoperability

Layer 10: Deployment Flexibility

Layer 11: API Access

Layer 12: Visualization

N/A

Summary

• Similar features to other device platforms, with more flexibility on the device and cloud side of things.