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.
