Select Page
The six most common questions about IoT Platforms

The six most common questions about IoT Platforms

If you have any plans getting involved with the Internet of Things (IoT), chances are that you will come across the term “IoT platforms”. This article describes some of the most common questions regarding these platforms, such as what they are used for, how they differ from each other and what you should consider before selecting one.

 

Which role does an IoT platform play in the overall IoT architecture?

IoT spans a lot of areas, but most IoT solutions have four major building blocks in common:

1) Data collection (via sensors, devices, gateways, APIs, humans etc.).

2) Some (wireless) infrastructure or network to transmit the data from the sensor.

3) An IoT platform where data is collected, analyzed and from where devices often can be managed to some extent.

4) An application layer (dashboard, mobile app, API for integration to other systems, services platform, ERP or sales systems etc.).

What else can an IoT platform do?

Apart from the basic stuff described above, many IoT platforms can also do a lot of other tricks. Examples:

– Store, normalize and filter data.

– Represent data sources and objects/humans/places in logical object models.

– Analyze and build logics between the collected data to automate a process, create an alarm etc. based on rules that you can define yourself.

– Present data in dashboards/maps/portals or publish it through (open or industry-specific) Application Programming Interfaces (APIs).

– Perform device management of sensors, devices and gateways.

– Manage and monitor (SIM) connectivity and data plans.

– Perform more advanced cognitive tasks, AI and machine learning based on collected data. This is sometimes offered as modules.

– Offer connectivity plan and subscription management, especially for SIM cards.

– Offer multi-tenancy support so that you can define who should get access to what kind of data.

– Billing management.

Why is the IoT platform landscape complex to understand?

Some platforms can provide a lot of the above described functionality in a very narrow way, some focus on just a few aspects, some are only handling network connectivity while other platforms actually are not platforms but Lego boxes with platform pieces that you can use to build something of. Some platforms support industry standard protocols like FIWARE or FHIR. Most platforms are created for vertical reasons (see below). All platforms are mixed up in comparison matrixes for various reasons. Any platform comparison should always come with a clear definition of what is compared, but that is seldom the case. As the result, you often end up looking at fruit salads rather than apple vs. apple comparisons.

What does “vertical platform” mean?

Unlike the “regular” fixed/mobile Internet, IoT is not standards driven but application driven. Most platforms are therefore originally created for specific purposes, like optimization of an industrial process, a home burglar system, asset tracking in a hospital or disruption of the taxi industry. We refer to these platforms as “vertical” as they target specific use cases or areas. A vertical platform comes with a well-defined ecosystem of supported devices, sensors and gateways from certain vendors. These platforms are seldomly interconnected to other vertical platforms (IoT really means Intranet of Things in most cases). As there are no well-spread open standards for device management, adding more sensors to a vertical platform later on may be costly in time and pesos. Vertical platform integration (for IoT or anything else) often gets exponentially complex with the number of involved systems. The reason is that API integration is a per-platform game due to poor standardization.

While vertical platforms often solve the tasks they are created for, they also come with scalability issues and lock-in effects. When you go for a vertical solution, always take the northbound APIs into consideration. You should be able to not only receive data from a vertical solution, but ideally also have device management control. A simple example is a street light system where you want to be able to not only read out data from the lights but also be able to dim them and turn them on and off. If you are a municipality or a large corporation, specifying the APIs here as part of a procurement process is key to be able to grow with solutions over time. It is actually more important than the platform selection. Also look out for any platform provider who is charging “per device” and/or “per Byte of storage”. Those kinds of models work well in proof of concepts, but you could end up with a non-scalable and costly infrastructure in the end.

I have heard about horizontal platforms. What is that?

The main task for a horizontal platform is to aggregate and cross-connect verticals and by that also allow for data to be shared between systems in a scalable way.

The figure below shows the concepts of a horizontal platform. As each vertical only has one integration with the horizontal layer, this results in linear complexity when verticals are added, and suddenly it is possible to scale. New services can seamlessly be added and immediately reach entire populations.

Horizontal platforms are often used to aggregate vertical platforms within Smart Cities, Smart Buildings, Healthcare etc. The purpose is not only for the application layer to get access to data in an easier and more scalable way, but it also allows logics to be built between verticals without the operator having to do stuff in many systems.

Horizontal platforms are often built with the Lego bricks provided by Microsoft, AWS or Google and can therefore also natively provide dashboards, cognitive functionality, machine learning and much more over time. During 2018 we saw several very capable open source platforms emerging. This will over time remove “per device and per Byte” cost for collecting data from sensors.

A properly built horizontal platform is the foundation for a scalable platform economy that can enable enormous values for a city, a hospital, a population or an entire nation. A good example is the X-Road system which is the (Blockchain based) e-health backbone for both Estonia and Finland.

Now, can you tell me which platform I should choose?

As the bullets above hopefully have described, various platforms solve different tasks and are created for different purposes. There is not one size fits all, and it is not possible to tell which vertical platform that is most suitable for a specific application or task without knowing what that application looks like. A general recommendation is to look at the open source communities early in a process. Several such platforms are very mature and allows you to start off building business from day one rather than spending time on development.

Another important thing to consider is that a lot of people who today are spending time on IoT probably instead should focus on the foundation of data collection and define what APIs should look like. If your patient data ends up in 20 different healthcare systems that you cannot access, you will never be able to use that data in an efficient and innovative way regardless of platform choice.

And that sums up where you should always start with IoT. Before picking a platform, a radio standard or a sensor you need to understand the use cases, business cases, problems to be solved, opportunities, humans, needs, business impact analysis and much more. Too often things are done the other way around.

Ten things you didn’t know about the Internet of Things

Ten things you didn’t know about the Internet of Things

1. “50 billion connected devices” has already happened

Some say there will be 50 billion connected devices in 2025. It has already happened. Everything from cars and Barilla pasta to Nespresso capsules and Gillette razors are already connected and powered by IoT. Uber’s entire business model is built on an IoT platform. Your phone is probably part of tens or hundreds of IoT business models depending on how many apps you have installed.

2. Most devices will never be connected to the Internet

Unlike the previous “versions” of the Internet (content/people/mobile) that have been driven by standardization and certification, IoT is completely application driven. This has resulted in countless jungles of proprietary wireless techniques, protocols, platforms and applications that are tailored for various use cases but cannot talk to each other. Device communication outside your own IoT network is rare which is fine as there is generally no value in connecting your dog to a meeting room at the office or a fan system in a building to a car. IoT generally means Intranets of Things.

3. IoT Business Intelligence never gets better than the data you collect

Ok, you knew this already but it still needs to be highlighted. There are air quality sensors not capable of measuring data at a relevant resolution and energy meters that sit inside metal boxes in people’s basements without ability to get a wireless signal. If you cheat on radio front end, antenna design, network design, security or sensor quality it will bite back. Advice: Do not cheat.

4. You might already have access to the data you need

Example: A municipality could dig down hundreds of thousands of on-street parking sensors all over a city, or they could invest the money in a mobile payment platform like EasyPark that can provide the parking status via an API. No sensors, no hassle, just data, and at the same time they get rid of the parking ticket payment machines. The same applies for buildings, healthcare and a lot of other areas where sensor technology already exist. Before you roll out sensors or build a network, carefully consider if there is a smarter way of collecting the data.

5. IoT might be the next millennium bug

Pretty much every device is advertised with a maximum battery life time of ten years, and a lot of IoT systems are sold without lifecycle management support. Will all sensors we roll out today have been replaced by something else in ten years’ time or are we creating a new massive “millennium” bug when everything stops working in 2027? Many wireless networks will be gone ten years from now and sensor technology evolves all the time. It does not hurt to have a long-term plan.

6. A lot of sensors will soon be replaced by something else

The exponential technical evolution results in new technology reaching a lot of users faster than before, but also that technology gets outdated much quicker. VHS, CD and mp3 are good examples. Cameras and image recognition will replace a lot of sensor technology sooner than we think. As mentioned above, parking sensors can often be replaced by a software API. There are other concepts too, like synthetic sensors that potentially can replace a lot of legacy in-home sensors and at the same time increase security. Augmented Reality will replace many indoor positioning services where the aim is to find something. And on it goes.

7. The location of connected devices and sensors is more important than you expect

At a first glance, knowing the exact position/location of a device or sensor is only important if you are dealing with tracking/positioning of objects. However, if you automatically get the position of something it simplifies inventory, support and troubleshooting, and this can prove to be worth a lot for the TCO. Consider an activity based office where sensors with 5-10 years battery lifetime are spread out under tables, on trash bins and in meeting rooms. Will you refurnish, re-organize or move to another office during the coming five-ten years? Probably, and unless you are planning to arrange a massive “sensor hunt” for your staff, make sure you take measures. You get similar benefits when streetlights, parking sensors, water meters and other things report their position automatically.

8. IoT is about ecosystems. Be an attractive partner.

There are a lot of companies out there trying to figure out how they should be relevant in the IoT space. Many of them create own platforms, boxed solutions or develop own and very proprietary protocols. Most of them reinvent the wheel. A better approach is to stick to what they do best and refine that even further while joining ecosystems where their piece of the puzzle fits. Example: If your core business is to analyze a certain type of medical disease, do not employ backend coders to build a platform for this. Someone else has already spent 30 000 man hours to productify something that works. Instead, employ doctors and spend time with patients to build value in your algorithms.

9. Small scale is not the same as large scale

During 2018, tons of small-scale IoT Proof of Concepts (POCs) have been carried out all over the world. In many cases, some Low Power Wide Area Network (LPWAN) technology such as LoRaWAN has been used as the bearer of sensor data. Many of these POCs will scale up during 2019 and onwards, and that is when new types of issues will arise. The LoRaWAN ecosystem is scattered. Narrowband IoT comes with battery constrains. The 868MHz frequency band is very small without any guaranteed sustainable future, especially in larger cities. Provisioning of devices, distribution of security keys and certificates, platforms and their price plans, quality of sensors, precision in sensor measurements and much more will be very different when scaled up.

10. Your biggest IoT challenge is not technical

The evolution curve of technology has surpassed the pace of human adaptation rate and the result is that legacy processes and procurement processes, laws, politics and poor business impact analysis block innovation. We all see this daily when we buy new technology that comes with a massive engine under the hood while the user experience still is an old bicycle. A tender process (from RFI to purchase order) can take several years, and when it is time to buy in to something it is already outdated technology. To get things going, do not focus on technology but business operations, people, needs and user experience and set measurable goals for your IoT projects.