Tell me more Internet of Things — Part 1 — IoT platform cost and value comparison

Comparison of selected IoT (Internet of Things) AEP (Application Enablement Platform) by implementing step by step a specific use-case and adding a possible DLT (Distributed Ledger Technology) implementation to that comparison.

Part 1 | Part 2 | Part 3 | Part 4| Part 5 |Part 6 | … | Part n

This article (Part 1) explains the project goals. I am introducing the use/business case and how I intend to compare the cloud implementations. At the end we will set up the hardware of the use-case and deploy a simple program which prints the sensors data to the command line.

This is my personal project (multiple parts) which could stretch along month.

Motivation and targets

According to Gartner Hype Cycle the Term IoT Platform is just about on its decline from its hypest and highest rise.

Adapted Gartner Hype cycle with IoT Platform and Blockchain as of July 2018. Yin Yang symbol (describes how seemingly opposite or contrary forces may actually be complementary)

Even though Gartner is not necessarily right about every detail in technology it is certainly true that there is loads of positive business outlook from the very same research team states several trillion industry in just a few years (yes trillion 1,000,000,000,000 🐵)

True is as well that many companies have already opened their devices/businesses to the internet. And some made the collected data analyzation and data visualization centrally to their value proposition.

Whereas companies like Siemens focus in some parts more on the industrial business with their own platform MindSphere, which states to be the Operating System (OS) for the Industrial Internet of Things (IIoT). Others like Google (Google Cloud) or Amazon (AWS) added specially IoT to their vast cloud functionalities in order to advertise this market better.

All of these platforms have in common that they are offered as services. Whereas Siemens MindSphere is a Platform as a Service (PaaS) — Google and Amazon bring the Infrastructure as a Service (IaaS) included in their offerings. Meaning Siemens won’t have their own Servers (Data Centers ~ Clouds) but need to partner up with Microsoft, Amazon or Google.

The maverick approach for IoT combines two of the most hyped topics — IoT and Blockchain (better DLT Distributed Ledger Technology) and with that it would be on the highest hype on that very same curve. IOTA stands for (“A permissionless distributed ledger for a new economy”) — it’s not really the abbreviation I was expecting but it makes sense 😎. We have to be fair here, IOTA is not a platform but rather a protocol.

So adding IOTAs distributed and decentralized approach to the comparison is risky but I think worth it and opens up to a lot of questions and discussion while comparing to centrally managed platforms.

Currently IOTA transactions (messages) are secured by distributed Node software running on personal servers or cloud instances (VPS). So it is neither a IaaS nor a PaaS — it enables with providing node software, the protocol as well as a wide community to promote their vision of IoT.

All IoT solutions have in common beside other things like security, data handling and automation to solve scaling.

But why do we need all that scaling?

The control theory and system identification Professor emphasized us to always apply the most simple and easiest approach before going nuts (meaning just try linearly identify a system before training nonlinear neural networks). Translated to our use-case here that would be starting not necessarily with the BigData approach 😅. The use case (product) we will develop is at the time of writing just one device and we could implement it very easy non scale-able way. Knowing that without the other ~9.999 devices we won’t have any way of doing big data diagnostics which is the real value contribution for the business case.

In order to understand the IoT platforms benefits but as well its drawbacks we define a business case for our product (use-case) to understand how the value proposition develops with those increased functionalities.

Use-case : The product we connect to the IoT “platform”.

: The product we connect to the IoT “platform”. Business case : How to make money with this product/service connected to the cloud?

: How to make money with this product/service connected to the cloud? Value proposition: What is in for the customer?

The reference architecture

To structure our approaches and use the same wording we follow the reference architecture for IoT systems introduced by the Institute of Architecture of Application Systems.

IoT reference architecture

Every platform has its own terms which can be mapped on this simple overview.

The use-case

Everyone needs a portable environmental sensing device which tells you at home, work or while commuting which air you are breathing and other influencing health condition you are exposed to.

The prototype

Sensors (Particulate Matter — SDS011 PM2.5 and PM10, Humidity and Temperature)

(Particulate Matter — SDS011 PM2.5 and PM10, Humidity and Temperature) Device : Raspberry Pi 3b+

: Raspberry Pi 3b+ Drivers : USB connected (digital), GPIO connected (analog)

: USB connected (digital), GPIO connected (analog) Gateway : Raspberry Pi 3b+ — WiFi module

: Raspberry Pi 3b+ — WiFi module IoT Integration Middleware : IoT Platform (Google IoT, AWS IoT MindSphere, “IOTA” not a Middleware but a protocol and distributed network)

: IoT Platform (Google IoT, AWS IoT MindSphere, “IOTA” not a Middleware but a protocol and distributed network) Application: Visualization: metrics, time-series.. , notification: notify when conditions are not healthy, automation: support APIs for controlling {e.g. heating, air …}, manual event input: user can or should log when sick or other metrics, analytics: diagnostics based on big data nonlinear system identification 👍

Use case assumptions

Message-size: 20 words (columns where every word is about 5 chars)

20 words * 5 chars/words = 100 chars ~ 100 Bytes ~ 0,0001 MB

Table representation of the telemetry message (device — message)

Message-frequency: 20 messages/hour

That would lead to data ingest of roughly 18 MB / year per device

20*24*100*365 = 17,52 MB / year per device

As our product get super popular we would account

1.000 Devices ~17,52 GB / year 10.000 Devices ~175,2 GB / year.

If we don’t throw away that data (certainly not) let’s say we gain roughly 300 GB of data in 3 years (10.000 Device ramp up)

Business case assumptions

Only for the sake of staying easy (we want to compare the platforms but not the business case) we only provide the visualization and analyzation.

The device itself can be assembled by open sourced instruction or could be bought by a third parties.

Free to use application (only visualization and alarms) [0 EUR]

Licensed version which gives you health recommendation based on the data analytics (of all users devices and their personal inputs). [20 EUR / year]

Draft of profit accumulation for our business plan (needs updating for the IoT AEP costs)

Value proposition assumptions

We really don’t know what we are breathing during a course of the day. Certainly we don’t know individually how it affects our own health.

The value

of having an continuous environmental measurement and the possibility of logging personal health events.

getting recommendation (based on the provided big data analytics) from basic avoiding certain levels to supplement or counter measures.

personal recommendation — e.g. analyzing your next flat or house to be sure it does not affect your health.

That is a long introduction for a comparison of IoT platforms. But I guess in order to compare the solutions we need an end to end use — case. Just comparing the prices of data storage won’t do it.

The Milestones and KPIs

In order to be able to compare the platforms we introduce sections (milestones) and some indicators for comparisons.

KPIs (Key Performance Indicators)

K1: Cost of solution running continuous (€/year, €/user)

K2: Maintenance costs (€/year, €/user)

K3: Complexity of implementation (difficult=1, ok = 2, easy & short=3)

K4: Documentation quality (none=1, some=2, more=3)

K5: Out of the box functionality (few=1, some hacking=2, all is there=3)

Milestones

This is a prototype and we use javaccript where possible (Node.js) even if that is less suitable.

Milestones

M0: Hardware setup (for all the same).

M1: Hardware connection (Raspberry Pi and its Sensors).

Easiest implementation with available libraries. No HW serial coding or embedded C programming (in case of MindSphere that might be necessary for the prototype 😅 node.js lib is not yet publicly available)

M2: Onboarding sensors (data).

Easiest onboarding of device. Outlook of onboarding further devices (automatic onboarding when user registers)

M3: Visualization of data.

Visualization (out of the box if available)

M4: User visualization and event handling (thresholds).

Users own device visualization and event handling (out of the box if available).

M5: User input in case of events or manual.

User input to enrich event data from the device. Easiest implementation. Outlook for mobile input.

M6: Integration of external data sources.

Adding external API available sensing data e.g. API call for the dedicated GPS coordinates and add them for data quality enriching.

M7: Analyzation of data (for correlation of air quality other factors on own health).

We won’t have big data but we provide data and check how difficult is penetration of this data (automated or manual). Machine learning for identifying correlation between sickness and various inputs.

M8: Automation (Sending commands to actuators)