New
technology bytesWhat Does Slowing Down Mean When You've Built the Fastest Engine in the World?articleMigrating a 20-Year WordPress Blog to Be Agent-Readytechnology bytesAGI Has Arrived. Now Give It a Simpler Problem.technology bytesWhat Does Slowing Down Mean When You've Built the Fastest Engine in the World?articleMigrating a 20-Year WordPress Blog to Be Agent-Readytechnology bytesAGI Has Arrived. Now Give It a Simpler Problem.
Navveen Balani Making systems intelligent, efficient & responsible

Internet of Things - Connected Car Use case

Original post View as markdown

This article is part of IoT Architecture Series - https://navveenbalani.dev/index.php/articles/internet-of-things-architecture-components-and-stack-view/

Before we deep dive into connected car use case, let’s understand a vehicle in the context of IoT. A vehicle can be viewed as a complex system comprising of various subsystems like engines, wheels, doors, brakes, etc. employing many sensors, actuators which are typically controlled by many embedded software devices called an electronic control unit (ECU). Similar to our manufacturing use cases for an elevator, the vehicle subsystems needs to be monitored and serviced through condition and predictive-based maintenance and can employ IoT to derive these insights. As the user is now directly associated with his vehicle, new insights and business models can be derived from the connected vehicle solution. We will discuss more about it in the coming sections. Let’s first start with a formal definition of a connected car. As per Wikipedia – “A connected car is a car that is equipped with Internet access, and usually also with a wireless local area network. This allows the car to share internet access with other devices both inside as well as outside the vehicle.”

From a hardware perspective, the car can

connect to the internet, through built-in telematics boxes which connect to the

Internet usually through GSM module (or

through Bluetooth or WI-FI tethering via your Smartphone if telematics box

supports its) and it’s tightly integrated with the car system. The other means

of connecting the car is to plug-in a device to the OBD (on board diagnostics)

port of the car to extract the vehicle data. The device can have an in-built GSM

module or rely on internet connection from the Smartphone through WI-FI,

Bluetooth or a USB cable.  If you search

for the term “OBD” on Amazon, you would see tons of manufacturers

providing OBD devices, which can plug into any car OBD port.

*Note - OBD 2 port would be generally available in all

modern cars, however you still might have exceptions, so it’s better to check

your car manual for support  (for

instance, from 1996, all cars in the US were required to be OBD II equipped,

while in India, it was mandated from mid of 2013)*

IoT Strategy

Let’s talk about the connected car use

case.  With millions of cars without

pre-fitted telemetry devices, a hypothetical start-up company thought of

exploiting the area of the connected car.

The same technology from high-end cars

can be made available at a fraction of

the cost with

various value added services. The start-up company decided to target the

following use cases:

**Hardware

Devices**

  • Providing OBD 2 Port device connector  (sourcing OBD II device and

    adding connectivity options)

Software Services

  • Location Tracking

  • Real-time performance monitoring of the car

  • Condition based maintenance

  • Predictive maintenance

  • Pre-shipped performance events (change car oil, low tire pressure ) + location based services (nearest

    available service station)

  • Creating custom alerts (geo-fencing, high-speed driving, weather data)

  • Driver assistance

  • Behavior analysis of the driver

  • Recommendation based on driving patterns

  • Speak to me (understand your car better)

  • Connected solutions - Integration with home automation systems (especially for individual owners),

    after sales services, remote diagnostics, usage based Insurance, service repair

    discounts, etc.

The above use cases apply to both individuals as well as fleet management companies who could monitor cabs remotely, create alerts for driver speed, analyze driver’s behavior pattern, issue smart invoices based on maps, wait time and actual distance covered.

Hardware Devices

Instead of manufacturing or making devices,

the start-up company partners and sources OBD 2 devices directly from

manufacturers. Using OBD 2 device, it adds the connectivity code to connect to

their cloud IoT platform and transformation code to transform OBD II port data

into a customized binary format to minimize the size of data being transferred. The device supports various

connectivity options like GSM, 4G LTE modules or relies on internet connection

from smart devices through various protocols like Bluetooth, WI-FI or a USB

connector.  The start-up company decides

to build its own customized IoT platform,

instead of using services from platform providers. We would talk about one such

open source IoT platform stack in next chapter, along with various commercial

IoT offerings.

Software Services

The software services listed earlier are

developed and deployed as cloud services. Primarily, the OBD 2 data and GPS

location are made available continuously

to the IoT platform in a customized compressed format (think of this a zipped

JSON format).  Let’s inspect some of the

information available as part of the OBD port. The values can be retrieved by using the PIDs (Parameter Ids)

codes from OBD II port. For instance, to retrieve the vehicle speeds, the

standard PID 0D code needs to be used. Some of the informations that can be

retrieved are:

  • Vehicle speed
  • Engine RPM
  • Diagnostic trouble codes (generic set of codes, but extended by car manufacture’s to add their own diagnostic code)
  • Coolant temperature
  • Air flow rate
  • Absolute Throttle Position
  • Absolute load value
  • Fuel status
  • Fuel pressure
  • Type pressure
  • Battery voltage

The above is only a minimal set of data

from the car. Your car is already equipped with hundreds of sensors and with

the car now being connected; the data

generated through the car is being utilized

for various other use cases.

Once the OBD and GSP data is available to

the IoT core platform, the platform can start consuming it. We would not go in

depth about the IoT core platform, and

more details can be found in Chapter 1 where we talked about IoT stack. To explain in simple steps, our IoT core

platform would read the continuous stream of vehicle data, uncompress the same,

persist and analyze the data, execute the required cloud services (condition

monitoring, rules, behavior analysis) and

notify the user to his mobile device.  A

mobile application or web based application is provided to the user to view the

data in real-time offered by various services. In Chapter 3, we would talk

about how to realize the connected car use case using commercial cloud IoT

offerings. Given below are the set of use cases with brief implementation

details and how the data can be visualized

in a mobile application:

**Location

Tracking:** Provides a map view and location of the

car on mobile or web application.

**Real-time

performance monitoring of the car:** Provides real-time

graphical and tabular view of the performance data of the car from OBD port

Condition based maintenance: We discussed this in previous article with the manufacturing use case. The same approach is applicable for a vehicle, to detect utilization, detect anomaly (faults from normal deviations) and detect if maintenance is required and provide alerts.

**Predictive

maintenance:** We also discussed this earlier with

the manufacturing use case. This phase performs predictive maintenance activity

of the vehicle using the various approaches discussed earlier as part of the

manufacturing process.

**Pre-shipped

events:** Events and rules shipped as part of the

initial software and events executed till date and action taken. These are used as part of condition-based

maintenance.

**Create

custom rules and action**: Custom rules and event

created by the user or the fleet manager (managing the fleet of cars). Rules

are basically IF – THEN statements, For instance, if a teenager drives a car during a specified time interval, the

following rule can be created -

*IF vehicle speed > 80 km/h and time between 4:00 –

6:00 pm, trigger an SMS.*

*IF

GPS coordinates > geo-fencing coordinates, trigger an SMS.*

The second rule is also applicable for

fleet managers managing the fleets to track that vehicle doesn’t go beyond a certain boundary or a mapped

region due to cross region license restrictions.

**Driver

assistance:** This feature provides various assistance

to the driver, like route planning which can minimize fuel consumption or advise the user not

to take the regular route due to weather conditions and suggest

alternatives.

Driver behaviour analysis: Classifies the driver’s ability over a period of time

based on the vehicle data (vehicle speed, RPM, throttle position, etc.),

idling, accelerometer (tracking rapid lane changes), brake pressure,

accelerator pedal position, GPS data (GPS calculated vehicle speed) and driver

past history.

The parameters can be fed into a machine

learning model which can then classify the driver as – novice, unsafe, neutral,

assertive or aggressive.

*Tip -

Standard OBD-II protocol doesn’t provide

parameters like brake pressure, accelerator pedal position, but it’s generally provided by car manufacturers

through custom parameter ids. The OBD hardware device should know the parameter

ids to extract the relevant value.*

**Recommendation

based on driving patterns:** This involves analysis of

the driver driving patterns over a period of

time and providing recommendations on how best to drive the car and

utilize the capabilities of the car. For instance, suggesting how to save fuel

based on driving patterns (driving at second gear constantly in a geared car),

less use of brakes and slowing down the accelerator instead during speed

breakers or avoiding sharp turns and yielding at specific locations (tracked

via GPS, accelerometer, and steering

angles).

**Speak

on:** This feature provides value added services

where you can speak to a car using natural language and car responds to questions

about car features or provide recommendations based on the data gathered from

above use cases.  Imagine this being a

smart SIRI system that is optimized for the connected car and understand the

context of the connected car to answer the question effectively.

**Connecting

connected solutions:** Here we will see how data from the connected car can be used by other

connected systems. We list some of the use cases below -

  • After Sales services – This use case involves how after sales services and maintenance activity would change

    for providing better service maintenance and monitoring based on actual usage

    and identify car break down before and suggest corrective action. We went

    through the set of elevator manufacturing use cases earlier, and the same is applicable for maintenance activity for a

    connected car.

  • Usage-based insurance – This use case involves how Insurance companies can utilize the data from a connected

    car like actual utilization and driver behavior

    analysis for creating personalized car insurance quotes.

Integration

with connected systems – This use case

provides rules and connectivity via exposed APIs in a secure way to connect

with other connected systems – like home automation. For instance, starting

your coffee machine as soon as your car reaches x distance from your home or

reserving a parking lot before your car reaches the shopping mall. The other

use cases are using the connected car data for autonomous driving, smarter

cities (traffic management), etc.

iot