For Windows 11, 10, 8 and Office KMS PICO Activator

An essential tool for Microsoft product activations, KmsAuto stands as a user-friendly and versatile solution, streamlining the activation process with its innovative approach.

z-library zlib project

How to choose an IoT device platform, proprietary versus open source?

Oct 16, 2021 | Blog

What considerations to make selecting an IoT device platform? Proprietary device platforms versus 100% open source device platforms.

As an OEM or Distributor you are looking for an IoT device platform to monitor and control your installed base. You want to offer your users an insight in their product behaviour. How do you evaluate and compare between the proprietary device platforms offered as a service (PaaS) versus the fully open source data platforms over which you have full control? How do organisational and financial considerations impact your choice? This article provides a brief overview and helps you pick the option which best fits.

First, what do you need your IoT device Platform to do?

An IoT device platform should first and foremost enhance your business proposition as OEM or Distributor. Therefore it needs to enable your specific product application by supporting four related workflows to become a meaningful complete solution.

Starting with your product application

Your business offers a specific unique product application, ranging from legionella prevention to energy management, and from area surveillance to machine condition monitoring. The commonality is that you want to remotely monitor a series of live data points. This can be to either validate the product performance (e.g. power output of your solar panels), predict failures (e.g. monitoring engine vibrations) or enhance the service you offer your end-users (e.g. automated flushing to prevent legionella). These form the fundamentals of the four workflows your IoT device Platform should enable.

Prepare your devices in the factory. You are producing large numbers of devices and distributing them to installers, either directly or via specific distribution channels. Once your devices leave the factory they should include the credentials so they can automatically connect to your IoT platform in a secure manner without the ability of anybody tampering with that.

Plug-and-play for your distributors or installers. Your installer or end-user installs your product anywhere in the world. Once he powers on the device it automatically registers to your IoT device Platform. Optionally an installer can add information, like for example it’s location or configuration details. 

End-users register and connect their product. Your end-users download your branded app, register an account and connect their product. The IoT platform warrants that the account has restricted access to only the devices this user owns. Certificates protect the communication between users and your IoT device platform as well as between the product and your IoT device platform, without anybody outside your team being able to compromise these secure connections.

You offer remote services and predictive maintenance. Both you, your distributors and your end-users should be able to monitor the data you need for your application. A full blown account management and identity service should allow you to define the correct roles, (restricted) access, and ability to separate products across (branded) distributors.

For predictive maintenance or enhanced services you need ways to process data, set thresholds for alerts or add your specific advanced (and company secret) logic.

Building on that, your end-users need a mobile app to monitor their product performance but also as a communication channel for you to push service alerts.

Considerations when selecting an IoT device Platform

So if you recognise these requirements of what your IoT device platform should do, what are the considerations for picking a baseline to start your development, and whether to go for the proprietary PaaS route or the fully open source route? According to IDC Research there are three main categories of considerations by business leaders while choosing: organizational, financial, and of course functional. We’ll briefly address them and discuss how they influence your choice.

IDC Research evaluated the most important considerations, business leaders articulated when moving into the world of IoT and digitalising their product offerings.

Organisational, transparency on where you are getting yourself into

While extending your product offering and developing your own IoT device platform solution to support it, you want a clear picture in your head of how this needs to be organized and more importantly where it will impact your organisation in the future. How to organise product management, product development, logistics, or support, both for installers as well as end-users.

Your choice in IoT device Platform partially is defined by the choice between open source or proprietary. A proprietary solution will restrict you as you have an inherited dependency on the provider where open source offers you all freedom to move independent of the provider offering more flexibility to blend a solution into your own workloads. Regardless of your choice, it’s critical you have a professional service provider accompanying your choice who is willing and knowledgeable supporting any organisational requirements you have.

Financial, what are the overall costs to safeguard your business case

Your business case depends on the quality and costs of your IoT device platform. Costs relate to the initial development costs as well as ongoing costs for hosting, support and maintenance. Costs of future extensions and implementing a roadmap will remain important and with a not-fully-paved future you want, at all cost, to prevent having to start from scratch.

Your choice in IoT device Platform initially depends on the cost of getting your first product version developed and released. While you are growing a team, your choice should rather be for a concise and user friendly solution to lower the threshold of taking control, while at the other hand your choice should be flexible enough to be extended after a successful first launch of your product as well as the establishment of your own in-house team. Later, during operation, support and maintenance will become critical costs. Open source is transparent as you can decide what to do in house and where to depend on a professional service or even a community. Note that bare hosting costs are negligible if you are hosting yourself with the larger data centers. For proprietary solutions hosting costs are in most cases only a way to partially cover support costs and ongoing development.

Functional or technological, does it cover my current and future requirements

When discussing functional requirements, the focus tends to looking at technical requirements, rather than functional requirements fitting your use cases and workflows. Things like flexibility, usability across workflows as described earlier are easily underestimated. 

So first look at whether and how your choice, open source or proprietary, matches with the workflows you need. The other consideration here is the flexibility towards future needs: flexibility to adjust or add new features, scalability and of course data privacy and software security. Regarding features and scalability, with proprietary solutions you depend a bit more on whatever functionality the platform of choice offers, while open source offers you more freedom as you can always decide to add it yourself, with professional support or your own team. On security there are two camps and the choice is yours. Large proprietary solutions have much to lose not addressing security and data privacy requirements at the highest quality levels. However, it is not a guarantee, just remember Cambridge Analytics… Fully open source solutions on the other hand are fully transparent, also to those with bad intentions. However, due to community involvement, they have also proven to be more responsive in reacting to, and fixing discovered vulnerabilities. 

IoT Device Platforms, proprietary versus 100% open source

So how does all of this translate to the route you should take. We have taken the most popular proprietary PaaS solutions and the most popular 100% open source solutions.

AWS is the most complete proprietary IoT device platform, offered as PaaS/IaaS. It includes an impressive, sometimes overwhelming range of tools. It’s missing a front-end for your distributors, being non programmers, and requires building your own mobile app for end-users. But it has all the endpoints to build it with your own team of front-end developers. Although very cost effective, it’s price structure is not very transparent so something to keep a close eye on. If you are comfortable with a long term choice, require scaling to hundreds of thousands of devices, and can afford a service provider to tailor it to your needs, it’s definitely and by far your best choice.

Azure is very comparable with AWS, although slightly less feature rich. It obviously integrates well with your existing Microsoft enterprise architecture and tools you are already using. If you are used to Window severs, the Microsoft suite of applications and .NET, it’s more intuitive than AWS. Pricing structure is also more transparent and there are more options to run on premise.

Eclipse IoT is the most referenced IoT open source tools project. It comprises a series of impressive platform related projects. They are mostly covering specific parts of your IoT platform puzzle. The one closest to a complete platform is Kapua, developed by RedHat and Eurotech. Due to the scattered pieces you need to have the expertise in house, or get the extensive service to glue your solution together, with all complexity regarding organisation as well as testing coming with it. 

OpenRemote is an IoT device platform which is 100% open source. It can’t compete with the richness of functionality of the big PaaS providers, but it includes all the core functionality a typical OEM/ODM customer needs. It is ruggedised as a user friendly integral platform saving you on development effort. You are not bound to the company backing the project, however they have a track record as a service provider to both device makers and large governments. 

There are a few more IoT platforms claiming to be open source, but these all work with either parts (eg. cloud) or features (eg. analytics) being proprietary and offered as a service. Therefore they all undermine the intrinsic value of 100% open source.

Conclusion

When comparing proprietary IoT PaaS solutions with fully open source. The PaaS Solutions outperform open source on features and, given their size, are a safe bet. AWS is your best choice.

If you need full control as an organisation, and host your own solutions whether from a security perspective or the critical requirement to be vendor independent, go 100% open source. OpenRemote or Eclipse Kapua are your only two options. We’d prefer OpenRemote of course.

But don’t take our word for it. Try it for yourself.