Standard and fit for purpose
Share Share on FacebookTweet about this on TwitterShare on LinkedIn

Teppo Hemiä, CEO @Wirepas

The lack of standards is often seen as a hinder for growth in the industrial IoT market. Discussion about standards is lively, but in my opinion often misguided. There is a common misconception that standards, de facto or de jure, would guarantee future proof, easy to implement and interoperable solutions for all verticals and applications within the IoT, and hence support fast development.

Instead, I argue that the combination of open and simple Application Programming Interfaces (APIs) combined with continuous development and innovation is the right path forward. This evolving approach would encourage end customers and vendor ecosystems to invest in their IoT products and services, and it would also allow technologies to evolve with the changing and growing business needs.

The dilemma for large-scale IoT is, that the good old standards don’t deliver and the new ones doesn’t exist. In addition, IoT is a combination of so many diverse business needs and application requirements, that traditional full vertical approach would only help a very limited number of use cases. For example, electricity meters need a different physical layer compared to very high density, low power asset tracking application. It becomes obvious that the protocol and the physical layer need to be separated so that innovation on both sides can be unleashed.

By de-coupling the radio hardware and the protocol software, the lifetime of the installed hardware can be extended and the communications protocol can be updated according to the changing and growing requirements. This is already partly true as many semiconductor companies are offering the very same System-on-Chip (SoC) radio for different protocols. I think we could go even further. We could have one simple API with various radios and then run-time per device configure the protocol to fit the purpose. Full interoperability per application and radio media choice can then still be guaranteed.

It is highly important that we are able to offer SW upgrades and improvements as we learn more and business needs evolve. Why don’t we extend that thinking to the connectivity protocol as well? The installed HW can have a longer lifetime as the protocol is updated according to the changing application requirements. A good example of this is electricity metering where the meters have become sensors for the grid. At the same time, the requirements for the connectivity have changed dramatically during the lifetime of the HW.

Furthermore, I argue that large-scale industrial IoT connectivity should be designed for purpose just like the existing connectivity standards once were. Let’s take Bluetooth as an example. The original design purpose was to develop a wireless connectivity for headsets. The target setting was very clear –  and there were no existing standards available. Dr. Nils Rydbeck, CTO at Ericsson Mobile initiated the research and development for a new short-range radio system in 1989 with the goal of replacing clumsy wires. Later on, the technology was standardized and now we all can enjoy a massive ecosystem of Bluetooth products.

Bluetooth Low Energy (BLE) in turn was initiated by Nokia for the purpose of taking the power consumption to a significantly lower level than classic Bluetooth. It was launched as Wibree 2006 and later re-branded as Bluetooth Smart. The two Bluetooth versions are still existing, do not interoperate, and are based on different technologies. Both were developed for a new purpose at the time.


What about the design objectives for large-scale IoT connectivity? It should be a solution that scales to any number of connected devices, enables 24/7 device availability, works on any open market radio hardware, enables over the air updates, is secure, and can be monitored and diagnosed real time. In addition, an open and simple API is needed; one which is the same for all applications and enables a future-proof, coherent basis on which to build new applications, services and business models. Finally, one must be able to adjust bandwidth, latency and power at run time per device in the network.

I am not saying that one day there would not be an IoT connectivity standard, or more likely several standards. All I am saying is that to unleash the full potential of the IoT we need to de-couple hardware and software at the radio level, we must take the application requirements as our design objective, have open APIs and develop our technologies continuously in line with the business needs.

The IoT market can’t wait. We need to be able to support new IoT based business – now.