The Internet of Things is all around us. Temperature, barometric pressure and humidity sensors – just to mention the most common ones – are ready to mumble their readings through Wi-Fi or Bluetooth. Sensor readings are gathered and streamed into the Cloud. Models developed by Data Scientists are being executed. The results are used to get to some sort of conclusion.
This summer SAP Labs Hungary held its first IoT Challenge. Employees have been encouraged to come up with IoT related ideas. During ideation in with colleagues it became obvious that the 4 of us (Janos Kannar, Daniel Koncsek, David Egressits and me) shared similar ideas.
The idea was simple. Report the odometer reading (distance travelled with the car to date) of the company cars automatically. Currently this is done manually, through a web application.
The initial requirements were:
- Report the odometer reading regularly
- Make it as seamless for the driver as possible
The solution sounds simple. Using the OBD2 standard diagnostics port of the cars read out the information then submit to the web application. We knew it wouldn’t be so simple.
Unfortunately this information displayed on your cars drivers display is not exactly available through the diagnostics port. The distance travelled since last error code reset is available though, but let’s get back to this later.
The net is that we had a subscription to the challenge. Our prototype was presented in the final and voted to be the best. As a reward we had a chance to present our idea and the corresponding prototype at SAP TECHED 2015 Barcelona.
We planned to use our cars OBD (On-board diagnostics) port. While we knew that there are different versions available by shape we also read that in the EU it is safe to assume that newer cars come with standard connector.
“The EOBD (European On Board Diagnostics) regulations are the European equivalent of OBD-II, and apply to all passenger cars of category M1 (with no more than 8 passenger seats and a Gross Vehicle Weight rating of 2500 kg or less) first registered within EU member states since January 1, 2001 for petrol (gasoline) engined cars and since January 1, 2004 for diesel engined cars.”
(https://en.wikipedia.org/wiki/On-board_diagnostics - cite_note-17)
These ports have been designed for service technicians and specifically for target devices types. But at the same time we also discovered that there are multiple variations of wired and wireless devices available on the Internet. Most of these cheaper devices are based on ELM327 chip. One of us already had one of these. It was using Bluetooth 2.1 standard for communication. Very few are equipped with either Wi-Fi or Bluetooth 4 (BLE Low energy Bluetooth). This makes it impossible, too expensive or very difficult to connect to iOS. I – as an iOS developer and end-user – could not cope with working on a solution that will never be iOS capable.
So we tried to focus on other ideas. We decided to move further out of our comfort zone and build prototype hardware from components already available. Naturally we turned to Arduino.
We have quickly found out that there are Open Source HW shields available for the Arduino Uno. Ended up with Seed Studio CAN-BUS shield.
This shield is widely used among enthusiasts hacking their car display, resetting error codes on older cards that already ran out of warranty.
This card uses CAN-BUS (controller area network) standard, which is the most common one across vendors. It uses OBD to DB9 cable to connect the car to the device:
“A controller area network (CAN bus) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other in applications without a host computer. It is a message-based protocol, designed originally for multiplex electrical wiring within automobiles, but is also used in many other contexts.”
(https://en.wikipedia.org/wiki/CAN_bus)
We had a little (weeks long) struggle of getting some data out of the bus. Various issues were among the causes, but main role was the lack of experience. Right before the deadline we figured out all the problems and started to collect data. During the final we used a RPi (Raspberry Pi) to save the data spitted out by the Arduino on the Serial Console. This is now changed.
Our RPi python application uploaded the data to a simple Java Web Application. It was hosted on SAP HCP (Hana Cloud Platform) and was storing data in a shared HANA schema. The web application exposed an OData service, which was consumed by a Fiori Application as a client.
We also presented list of potential business opportunities:
- Fleet Management
- Analysis of driver characteristics
- Reward based system for “good drivers”
- Automated repair workflows
- Automated service scheduler
- Vendor Feedback – share sensor data directly back to your vendor
- Black Box – to analyze sensor readings in case of accidents
The general feedback from the jury of the completion was good. There was one important recommendation we received. We should keep in mind the Data Privacy and add a way for consumers of the user-story to check the data collected and stored.
This is when we thought of introducing the mobile phone to let the user interrupt the unattended upload of data into cloud.
Since the competition we worked to further advance the tools on all end.
Currently our Arduino hardware hosts
- SD cars shield:
- store data between downloads
- GSP module:
- fetch current position
- get UTC Date-Time
- BLE module:
- allow mobile devices to connect and download data
Our mobile application is written in Cordova. It is capable of connecting to the Arduino device and downloading of collected data. The data can be presented in the application. There is even a map available to visualize the route.
The server side is enhanced to automatically brake down the uploaded readings into separate trips. Readings belonging to the same route should not have more than two ours time difference. The data model is adjusted to allow trips and new sensor readings to be stored. Vehicles are added to the database on the fly (when the first sensor reading is uploaded). The metadata of the vehicles can be manually entered.
Our Fiori application improved a lot. In fact we have now two of these. The first one can be used to search for tips belonging to the same vehicle. The trip routes are visualized on a map. The second one presents overallinformation about the fleet such as distance travelled by each car
.
This was just an overview blog post. I would be happy to share other details. Please leave a comment with your questions or requests witch parts you would like to hear about in more details.
We are very excited about TECHED. We will be presenting the prototype in our own pod from 10:00 to 18:00. We would be happy to welcome you in person.
- SAP Managed Tags:
