We took a brief look at the challenges facing Connected Vehicles Services adoption in India in the first part of this series. Over the next couple of articles, we’ll take a closer view on problems at the individual component level, which in sum make up a connected vehicle services ecosystem.
Do recall that I earlier showed what we called a ‘systems view’ of connected vehicles.
The ‘Systems view’ of vehicle connectivity — or what’s popularly known as Telematics - Collectively , location sensing + vehicle data collection + processing + transmission is usually referred to as Vehicle Telematics. Telematics data is pulled out of a Telematics Device: a typical device consists of a Location Sensing Module, collection of data from Vehicle Data Gateway (either CAN gateway or sensor gateway) and uses on-board Processors to assemble location data and vehicle data, build some layers on them and push them out through a Transmission Module. This sum of parts — the Telematics device — is at the heart of Connected Services. There are fundamental system level constraints, along with regional limitations, which have to be addressed first.
Location Sensing is critical for Telematics, and is often the key difference between Telematics and other IoT devices. Whether it is the globally popular US-based GPS, or the regional variants BeiDou or GloNass, the design level accuracy constraints posed by available industrial / automotive grade GPS chip sets restricts sensitivity to 2.5 meters. Bear in mind that this is a design level, best case scenario accuracy — actual GPS fix might vary even more. Compounding this are edge case scenarios (Cold starts, Satellite constellation availability, Device mounting angles, RF interference, Time to first fix Vs time of first packet transmission etc.) which all translate into poor end user experience when we look at real time track and trace. As far as location sensing is concerned, the trade off always boils down to Cost Vs Sensitivity + Form Factor.
I already touched upon the current market limitations of the Vehicle Gateway — the absence of CAN based in-vehicle networks is a serious limitation. While from a costing consideration, CAN enablement increases vehicle costs by more than a lakh rupees, it lends itself to very poor data extraction abilities. DTCs will not be available when a vehicle sub-system starts to fail or eventually fails — hence prognostics and even basic diagnostics cannot be enabled. Beyond diagnostics, two-way communication is not possible in I/O based vehicle networks: this means remote functions, remote ECU flashing and diagnostics of other ECUs is also ruled out. India being a severely cost sensitive market, many OEMs are yet to bring in CAN even in mid-level passenger vehicle segments. Even those vehicles which have CAN enabled, are yet to have a two-speed CAN network.
The vehicle gateway limitations can be bridged to a certain extent with a strong Processing Node — the second most critical leg of Telematics. We mentioned earlier that processing power available in India is best-in-class — but that too isn’t without a catch:we’ll come to that in a bit. As far as hardware goes, the global growth in semiconductors hasn’t bypassed India yet. Developments in VLSI & FPGA have enabled pioneers like NXP to introduce the ATOP module family, which then opened the floodgates for System-On-Chip (SOC) design. This enabled both the GSM and the GPS stack (plus some additional functions) to be offered on a single module. Such solutions (as opposed to a discrete module based design) offer great optimization in the eventual form factor of Telematics devices.
On the other hand, the SOC design has ended up with module makers posing severe limitations on the end use functions. Module makers like Telit, UBlox, Sierra Wireless etc. force end users to work with custom firmware libraries exposed by them — this constrains the languages that can be used for building the application layer within the Telematics device. The SOC module libraries end up dictating how functional logic is implemented, including the usage of processors, memory management, usage of the GSM gateway, boot sequence of the device, power usage and so on. So even though with a smaller form factor (which provides flexibility in where one mounts the Telematics device in a vehicle), better signal reception, the SOC modules pose limitations in how they are eventually used because of the module library implementation. While the prevalent reference SOC reference designs and library implementations might work successfully in other parts of the world — do keep in mind that no place else in the world pose such extreme divergences in operating conditions & signal availability as India does. In our experience, library implementation in these SOC modules have often led Telematics devices to fall short in actual performance out in the field.
The sum total of these problems eventually hit where it hurts the most — in end user experience. Poor data quality & reliability (even if the frequency of occurrence may be lesser) will often be glaringly visible when the data is presented in real time to the end user — specifically in Track & Trace and other Location services. Indian end users (specifically commercial fleet owners) have very little patience for understanding the limitations of technology, and will ask a very simple question: “Where is my vehicle in the map? Are the location and running parameters shown there accurate?”. Imagine delivering a spiel about cellular tower handshakes and GPS satellite angles against horizon and RF interference to a heavy duty truck fleet owner sitting in Jamnagar!
Through good design practices and some basic guiding principles in firmware architecture, the location sensing & module library limitations can be overcome and a device suitable for the Indian market can be designed (more on this later). But processed location+vehicle data has to still jump through a fiery hoop called the Transmission Node. In our next article, we will take a closer look at the unique network related challenges posed by our country. Feel free to post your thoughts/comments/critique below.
This article was originally published in my earlier blog.