Linkedin  Facebook  Twitter  Instagram  YouTube

Standardised Common Service Layer in IoT Applications

When we talk about ITS along with ITS associated verticals like Traffic Management, Vehicle Tracking, Automated Toll Collection etc., we generally think about them in isolation. Even in smart cities, verticals like smart street lights, smart homes, smart parking, smart garbage collections and solid waste management are seen in silos. But in smart cities once we try to make the cities smarter, we have to think of them not as siloed individual entities but a collection of all together. And the collection would not be possible until and unless they talk in the same language. Aurindam Bhattacharya, Senior Programme Manager, Centre for Development of Telematics (C-DOT) elaborates on the need for a standardised common service in IoT like ITS.

The debate regarding IoT and ITS have been going on for ages. IoT and ITS  have largely evolved as two separate streams within both standards and industry initiatives. Today, as most of the cars have sensors, microcomputers and communication devices fitted into them, IoT has become deeply rooted in ITS – in particular cooperative and connected automated mobility – to give vehicles a complete perception of their environment.

Generally speaking, as IoT is basically a collection of many sensors and actuators with some logic associated with that, it is trying to bring in intelligence into this whole ecosystem. There are two aspects to IoT: one is a proximal and other is a distal IoT.

Proximal IoT supports communication among devices in close proximity with functionality targeting fields such as smart homes and buildings and vehicleto- vehicle communications. Here devices often discover each other using multicast or broadcast capabilities and then exchange data directly.

Distal functionality targets larger-scale IoT deployments, basically connecting proximal IoT islands to the Internet.

When a person trying to cross the street and the car automatically applies brakes, that is proximal IoT. A car senses something within it and taking an action inside, that is what we call proximal decision-making.

But when a car senses something and another car wants to benefit from that information that is a distal IoT because that will have to be sent across to a central intelligence decision-making entity to be able to communicate further to either a single car or a set of cars. Now while it applies to cars, it is also applied to other verticals like Adaptive Signal Control. For instances, when a car breaks down, there is a huge traffic at a signal. In such case, this information must be notified to several agencies like a hospital or to a patient who needs to be carried to a hospital. Such information is going to be very useful in deciding as to whether to take the route or take an alternate one. The information will also be passed on to the traffic police department whether to divert the traffic from that area to some other area.

When we talk about standardisation of IoT, we talk about standardising the communication aspects of it and when we talk about the communication, we mostly talk about the distal IoT part of it.

Reusability of resources is emerging as the cornerstone of modern IoT systems. The data generated by the sensors of one entity is going to be used and it must be re-used to really make sense in this ecosystem. This has to be done with proper security framework implemented into this.

ITS is instantiation of IoT, all applications are generated out of information which is given by the sensors and sensors means IoT. While IoT generates data, some data consumption and taking decision making based on that data is an instantiation of the IoT. For example, a vehicle tries to sense a pothole; now while it senses a pothole, it takes a decision to apply brakes, that is proximal IoT. But when it communicates to a service provider and thereby the other vehicles get to know that there is a pothole and that is likely to cause some accidents on this particular road then that becomes a distal IoT. And that is where we would like to standardise this communication link.

Now when we say standardisation, there have been ample number of standards in the connected vehicles paradigm. For example, the 5.9Ghz 172 Channel crash imminent safety standards have been there since ages. Now this is between vehicle-to-vehicle, and many such similar standards exist in every vertical domain in every area e.g. Health Domain, Industrial Domain, Home Appliances Domain and Power Sector etc. Similarly, in ITS when you look at IEEE and ISO standards, you will get hundreds of standards but those are mostly application specific. We are not going to touch upon those standards here because the objective is to homogenise all the verticals together, and not about any specific application use case. These application use cases should mostly be reusable in the same fashion using a standardised communication mechanism.

Most of the current implementations of IoT/M2M applications (including Vehicle-to-Infrastructure kind of  ITS applications) are very siloed where the data is predominantly generated by using some sensors which connect to some controller(usually referred to as gateways) using some PAN(personal area network) protocol like ZigBee, Z-Wave, LoRa, Bluetooth, BLE, Wi-Fi (or even wired connection) etc. and then communicate to the server having the business application. The network used between such gateway(s) and the server(s) is a WAN connectivity medium, which is used merely as a means of transport… The business application in the server not only has to know about the data model of the sensors, but also has to understand the PAN protocols as well.

When ITS had just started taking shape, the premier car manufacturers like the BMW, Mercedes etc. used a lot of sensors in their vehicles. The data generated by these sensors were transported to their respective factories in a very proprietary manner. The communication was generally done using GSM network in international roaming. There was no provision to share this data and therefore other applications could not get the benefit of this huge data generated. Data sharing is important and the users get enormously benefitted.

Share with: