Standardised Common Service Layer in IoT Applications

Nowadays majority of the cars are fitted with many types of sensors. These cars generally send information to their respective manufacturers, who in turn derive a lot of intelligence by analysing this data to figure out how the parts of a car are functioning while being driven in a particular geography so that they can make modifications in the manufacturing process. The manufacturers can then build their cars suitable a specific region or country.

A subset of this data thus generated by the same set of sensors can be very useful for the service provider who provides periodic service for the car (and this definitely is not the manufacturer) because he needs this information to cater to the client. So, the servicing partner is going to know as to what in your car is likely to fail, how your car is being driven, and which inventory is depleting so that he can provide logistics information regarding those. The service provider can also give feedback as to, which are the cars needing attention.

Another consumer of the data thus generated by the sensors can be the insurance company, as the company insures user/driver by virtue of the driving pattern/skills. The insurance premium thus charged can then be based on the driving skills and a safe driver can earn significant discount on the premium amount. This would also significantly reduce false claims.

A beneficiary of the car’s sensor data can be the on-road assistance company. Many of the car owners in the big cities subscribe to on-road assistance. The on-road assistance provider is only interested about knowing where a car has broken down and what part of the car has broken down, so that he can send a vehicle to the user’s comfort. Even the traffic police will be immensely benefited by having access to this data because if a car has broken down during office hours in a busy city road, the traffic personnel will then have to send a towing vehicle straightaway or divert the traffic. Even the commuters need not depend on Google to know which route is congested.

Similarly, there can be many such application use cases where the data generated by the sensors if shared, can bring immense value. These applications become unviable if each of these applications is required to install its own exclusive set of sensors.

So, it becomes amply clear that the real benefit of the sensor data is obtained when divergent applications share it. This sharing has to be done in a secure manner with proper authentication, authorisation and accounting. Advocates of the proprietary siloed application providers may argue that the data can be shared from the business applications also. But that would require another management layer being created (as shown in the figure) which would extract data from all these applications. Not only it would be expensive, but also impracticable as this management layer would have to interface with such divergent proprietary implementations using non-standard APIs. This is far from being practicable. We must break these silos, if we really want to benefit out of IoT implementation.

The only way this can be achieved in a truly transparent, interoperable and yet secure manner is by following a horizontal framework instead of a vertical framework. In the horizontal framework, there is a common service layer in between the business application and the sensors. So instead of all these sensors and the associated hardware & applications on the car sending information to the proprietary back-end business application, the data is pushed to a common service layer in a standardized fashion wherein any business application can get that data.

For example, a car owner decides that his car’s information should go to only a particular service provider and insurance provider. Here, the car owner will be the one who is permitting this data access. And having this common service layer and the security framework built into it, the data pertaining to the car is shared amongst the stake holders only after obtaining permissions from the car owner. So, unlike in the vertical centric implementation, the owner is at the total control of this data in a horizontal framework. In a siloed implementation, the data goes to the manufacturer whether one likes it or not.

The common service layer thus provides a standardised interface through which multiple divergent applications can extract data after proper authentication and authorisation. The owner of the data remains in complete control of the data and decides whom to share the data with.

Additionally, the data provides future proof interoperability as it completely hides all the complexities of the car-end technologies including the networking protocol being used. For examole, for communication inside the car, Bluetooth & wired communication is used and beyond that embedded SIMs & 3G, 4G and even Wi-Fi. Soon, there will be a lot of innovations with the adoption of technologies like 5G, LoRa and Sigfox. The business applications would not have to bother about such advances in technologies as they have to just know how to extract data from the common service layer and not any further.