In the previous article, we saw at length about the design level complications facing a telematics device maker, and how they are further compounded by India specific constraints. Before moving on to discuss about network related issues, there is still a key element between the device and the network that we have to take a closer look at — the Telematics Device Protocol.
If one were to be very reductive, the Protocol will be the language with which Telematics devices will communicate to entities outside the vehicle — be it a web server, a connected infrastructure or even another connected car. The Protocol is the ‘visible’ output of the Processing Node that we spoke about in our previous article. The Protocol itself has two components: the constructed String has the data/content/message that is to be sent to the external world; the Transmission Type defines the ‘how’ of the protocol, including string structure, semantics, identifiers and so on. When a designer defines a protocol, she ends up defining these critical items: what goes into my string, how do I construct my string, and what method do I use in my transmission channel.
String construction, as we said earlier, is the key output of the Processing Node. What goes into the message string depends primarily on the vehicle architecture. For CAN based vehicles, string contents and structure depends on the number of ECUs being part of the CAN. Such vehicles will involve both parameters from the respective ECUs (engine, body controller etc.) as well as specific DTCs (required for diagnostic, prognostic messages). For non-CAN based vehicles, these inputs are provided by individual sensors through analog or digital I/Os. Note that each sub-system (whether an ECU or a sensor) can have it’s own data generation frequency. String construction for the Protocol message will factor in individual sampling frequencies for each parameter from the vehicle network. The final Constructed String will be an overlay of location and timing data on top of the vehicle parameters desired to be sent at that point in time (whether it is regular vehicle data or specific alerts). There are multiple ways to eventually for the string message: Binary, Hexadecimal, JSON, XML etc. Some OEMs even use their own bespoke message string structure.
Aside from constructing the message string, the other part of the Protocol is the transmission Type — protocol types like UDP, TCP/IP, HTTP, HTTPs, MQTT etc. are quite well known. There isn’t one standard transmission type for Connected Vehicles, let alone IoT, as each protocol has it’s own set of advantages and disadvantages which are well documented. In different operating conditions, each protocol would fare better over the others. What we would like to stress here is that for a Telematics system design that should work in India, one key and often overlooked consideration is data consumption — the protocol type would end up determining how much data is consumed for message transmission; how transmission sessions are handled when switching between GSM network sites or between types of data; and crucially the impact on data loss due to disconnections.
So why is an entire article focusing on the Telematics Protocol? For an engineer, the Protocol has the ability to act as a bridge between multiple system level constraints that will crop up:
Availability of processing power ( this is primarily dictated by total BOM cost of the telematics device and the eventual form factor, and pretty much will be what is offered by the module company). The impact of this will be on the string construction for the Protocol — whether the device simply pushes out vehicle data, or does some processing on top of the sampled data
Power management — in edge conditions between vehicle ignition cycles, and when the device runs on internal batteries or during crash/emergency conditions, how the Protocol handles critical vehicle data will determine efficient usage of available power for the device
Transmission Node constraints — crucially in India, when currently almost all Telematics devices use GPRS, the Protocol will have to be designed efficiently enough to work around low network speeds and availability
Functional Requirements — eventual frequency with which the Protocol pushes data out of the device is dictated by what the system must cater to the end user. Connected applications which focus more on real time data would require faster transmission rates.
Across all these apparent sub-systems, it is the job of the Protocol to paper over contrasting needs and constraints and ensure seamless end user experience from the Connected Vehicles service. A correctly designed Telematics Protocol can bridge over all the subsystem needs and problems.
The Telematics Protocol can also support overcoming uniquely Indian operating issues. To handle network availability, GSM latency and other related issues, the Telematics Protocol can do multiple workarounds: check GSM signal strength before attempting transmission, use the protocol type’s handshaking/acknowledgment message to determine whether a message is to be re-sent or not, use previous packet transmission statuses to switch to another GSM band (from 4G to 3G to GPRS to USSD for example) and so on. A designer can define protocols to limit the content of the message string — for example transmit only lat-long and time for live vehicle tracking, but include detailed CAN messages for diagnostics. The Protocol is also quite handy to work around edge conditions (for example when a vehicle is idling, or coming to a stop, or when ignition is switched off), to ensure that the data presented to the end user makes logical sense in all conditions.
In non-CAN network vehicles (which will be most vehicles in India) the Protocol has a very useful role. In vehicles using rudimentary sensors (fuel level, engine RPM being the most likely candidates), a simple pass-through of the measured values to an end user application (web page or mobile app) will end up showing tremendous value fluctuations). When these values are translated into BI reports they have an even greater impact. For such scenarios, at the device end, a faster sampling rate combined with some algorithmic smoothing can ensure that the users see no mismatch between what they see in the instrument cluster and what shows up in a telematics web app.
Telematics devices to be used for the Indian market must be built with some rudimentary device side intelligence, to ensure that the Protocol will be capable for handling unique scenarios and build the right transmission data. But the data must skip through one final hurdle to reach a place where it can add meaningful value — in our next article we will focus on the challenges posed by our choked up GSM network.
This article was originally published in my previous blog.