Smart Vehicle Maintenance System
Introduction
Vehicles play vital role in humans life, it helps humans to travel long distance with ease and
comfort. Maintenance of the vehicle is inevitable from the start of transportation history, it
evolves with the technology periods from the iron age to information age. Now, we are heading
towards automation age, which the vehicle maintenance needs technology upgradation.
Imagine that if you can predict faults and failure of parts in your vehicle before it even happens,
sending real-time data of your vehicle’s health to your service centre, having information of your
vehicle on your palm. Current technology has it’s own limitations with OBD(On-Board
Diagnostics), the OBD provides informations about fuel, temperature, auxiliary and RPM, but it’s
missing whole lot of feature, and as well lacking internet of things. My proposal idea is to fix this
gap by giving a real-world solution system.
Explaining Proposal Idea
Internet of Things(IoT) is the solution to make connected smart vehicles, My proposal idea is to
having sensors in vehicles on various parts to get necessary data for projected analysis. Which
is then to send data to cloud for later retrieval. The cloud will provide data to cross platform
devices like Android, iOS/OS X and windows. As the acquired data stored in cloud we can
retrieve the data anywhere in the world, even in real-time. The service centre can acquire data
of your vehicle like oil level, coolant level, break fuel condition, power steering’s reservoir fluid
flowing condition, steering wheel condition, front and rear lamps condition, real-time wheel
alignment data to analyse perfect angles on road drive and much more…The service centre can
get all these data to analyse over-all vehicle health and create projected maintenance service
date, or send immediate notification to the client if there is projected failure found by the
analysis of data. The notifications will be either SMS, E-mail, direct phone call or social media
alerts. By this system we can project failures before-hand and avoid unnecessary hassles, or
even dangerous accidents.
Flow of prototype production
1. Sensors
2. Bluetooth Low Energy module as Peripheral(Server)
3. Bluetooth Low Energy module as Central(Client)
4. WiFi Module as Wifi Gateway
5. MQTT as Cloud Broker
6. MQTT as Client
[Link]
We need sensors to read data from vehicle’s parts, like, liquid level sensor for fuel, oil, coolant
level, temperature sensor, 3-axis gyroscope sensor on wheels to get camber, caster and toe
angles etc. The sensors are connected to Bluetooth Low Energy SOC, either via ADC channels,
SPI, I2C or Peripheral UART communications. Sensor data can read via either of the
communication channels accordingly.
[Link] Low Energy module as Peripheral(Server)
The connected sensors are handled by Bluetooth Low Energy SOC as sensor nodes. The BLE
SOC will be set to act as peripheral(Server) mode. Vendor Specific service will be created as
main service than using any of the SIG(Special Interest Group) services, as the customised
Vendor Specific service gives the flexibility to create more characteristics for each sensors that
is going to be used in vehicle. Each sensor data can accessed through any of the
communication channels accordingly. On receiving sensor data on one second time interval it
will be processed to send as notification for each sensor BLE handle, the number of sending
bytes are set by sensor data length. As the system sends notification for each sensor there will
be more space (20 bytes is maximum to send per notification), The BLE advertising will be set
as high undirect advertising interval = 32, low undirect advertising interval = 1024, high undirect
advertising duration = 30, low undirect advertising duration = 300.
[Link] Low Energy module as Central(Client)
Another Bluetooth Low Energy SOC is set as central(client) to find and receive notifications from
peripheral BLE device. It will scan for peripheral devices and store the device information for
known device process for later scan. Once it’s found the peripheral device it starts to receive the
notifications immediately, and stores the received data in variables as sensor names. The
stored sensor data will either send to smart phone directly for user to check on request or
process to send to WiFi module for further processing. The sensor data to be processed to send
via any of the communication channel which is act as a master.
[Link] Module as Wifi Gateway
The actual Internet of Thing start to happen from this stage of the system. The communication
channel will be configured as per the selection of the channel of UART, SPI or I2C. The WiFi
module will be configured with SSID and WPA2 password of the WiFi router that is going
connect to access internet. The MQTT broker IP, user and password will configured to send
data over internet to MQTT cloud. The sensor data will be received through selected
communication channel from BLE Central device as slave. Later the data will be ready to send
as topics to publish to MQTT cloud.
[Link] as Cloud Broker
[Link] will be used as MQTT broker which runs Mosquito. The published data will be
stored in the topic called “sensor/+/+/value” with 2 one level wildcard for sensor name and
number of data from one sensor. The data published from WiFi module stored in the given topic
in real-time.
[Link] as Client
We can subscribe the topic “sensor/+/+/value” from [Link] with any device and
operating system. An Android Mqtt client app, an iOS app, OS X app or Windows app. Even
linux based devices can subscribe topics in MQTT. We should subscribe the topic with actual
name rather than wildcard, for example
“sensor/3xgyro/xaxis/value”,”sensor/3xgyro/yaxis/value”,”sensor/3xgyro/zaxis/value” and so
on…
Submitted Prototype Features
To demonstrate the idea I have created a prototype with mentioned features. I have used
Broadcom’s BCM920737 LE KIT as BLE peripheral with water level sensors to demonstrate
fuel, oil and coolant level sensing. Macbook Air as BLE client to scan and receive sensor
notifications. I have developed an application (BLE client app) in objective-c with Xcode IDE, the
demonstrated Youtube video URL and images have provided along with this documentation.
The Murata TypeYD WiFi module as WiFi gateway demonstration, I have used 3-axis
gyroscope sensor to demonstrate real-time wheel alignment data. MPU6050 3-axis gyro señor
module using the I2C communication, and the Murata TypeYD module haven’t provided I2C, So
I have used Arduino as I2C slave and MPU6050 as master to send sensor data to Arduino.
Arduino will send the sensor data through UART communication to Murata TypeYD module.
The received data from UART will send over to MQTT broker. Images and videos attached.
Features Not Included in Submitted Prototype
BLE SOC as client feature is not included in my prototype, MQTT client feature is also not
included.
Potential as Product
The BLE concept is best suited with IoT which is act as sensor nodes. The BLE nodes can be
mesh networked to prevent lose of connection to a single node. Bluetooth 5.0 will provide more
stronger signal and bigger bandwidth. The cost of the BLE SOC is gradually reducing over time
and can implement in-vehicles sensors packed, almost leaving any parts of the vehicle without
sensors. WiFi module costs are already inexpensive, we need a single WiFi module as a
gateway to connect to internet. Finally, overall cost to develop this system will be under 80
grand for full working prototype. The final product price will be affordable.
Conclusion
Time to say thanks to EFY Enterprises, Broadcom, Murata and Mouser Electronics for this
awesome IoT design Contest. Thanks for the opportunity to learn and invent new things in
Internet of Things. I have learned and enjoyed my time with this contest. Special thanks for the
Quiz gift that is sent to me as a surprise. Very much happy to submit this project without
expecting anything in return, the ride was joyful, thanks to all.