Vehicle Diagnostic Logging Device

Transcription

1 UCCS SENIOR DESIGN Vehicle Diagnostic Logging Device Design Requirements Specification Prepared by Mackenzie Lowrance, Nick Hermanson, and Whitney Watson Sponsor: Tyson Hartshorn with New Planet Technologies 5/8/2009 Most modern commercial vehicles provide a standard OBD 2 diagnostic port. Many companies that use commercial vehicles would like the capability to capture and transmit this information in order to process and evaluate it. An ELM327 chip paired with a microcontroller, Bluetooth module, and a smartphone will be used to record and communicate vehicle diagnostic data from a car to an understandable interface for average consumers.

2 Table of Contents 1 Overview 3 2 Statement of the Problem 3 3 Operation Description 4 4 Requirements Specification Design Deliverables 5 6 Preliminary System Test Plan Implementation Considerations 6 8 Appendix A: System Diagram 7 9 Appendix B: System Concept 8 10 Appendix C: Definitions 9 2

3 1 Overview Microcontrollers have transformed the amount of data that exists on a modern automobile s performance. Information such as engine idle time, engine settings, error codes, and the data necessary to calculate fuel efficiency are all available data outputs can all be measured in ECU[1] based vehicles. This project will give consumers the ability to capture and transmit this information via Bluetooth [2] to a smartphone [3] and eventually to a central server in order to process and evaluate it. 2 Statement of the Problem Many companies with commercial vehicles, such as those made by Peterbilt and Kenworth, would like to be aware of the information provided by the OBD 2 [4] diagnostic ports on their vehicles. These companies would be able to receive information about their vehicles, such as maximum and average speed, any braking violations that occur, the average fuel efficiency, engine temperatures, total idle time of the engine, and the total distance traveled. This data along with additional information can be pulled from the OBD 2 diagnostic port. The Vehicle Diagnostic Logging Device will be designed to diagnose engine performance of commercial vehicles. Information will be pulled off the OBD 2 diagnostic port, at regular intervals, that is provided in most modern commercial vehicles. The information will then be processes by the ELM327 [5] chip (as requested by New Planet Technologies), transmitted via Bluetooth to a smartphone, and finally displayed on the smartphone as well as on a server, both operating with a custom user interface. There are several objectives for the design of this project. The product will be designed to have all the power supplied to the device through the OBD 2 diagnostic port. The ELM327 chip needs to read data every one to three seconds (to be determined after testing) from the OBD 2 port and send the data to the microcontroller for processing. The ELM327 chip should use the standard codes [6] of the OBD 2 diagnostic port to analyze faults seen in the vehicle. The microcontroller will need the ability to calculate maximum speed, average speed, braking violations, average fuel efficiency, total engine idle time, engine temperatures, and total distance traveled. The Bluetooth module will have a profile that is recognized as a simple serial device. The Bluetooth module should be detected when the smartphone is within range. The Bluetooth module will also transmit data to the smartphone. There will also be some flash memory that will store data pulled from the OBD 2 diagnostic port until the smartphone is connected to the module. The amount of flash memory will be determined based on the sampling rate from the OBD 2 port and the method with which we store information. The flash memory should then delete the old data once it has been transmitted to the smartphone. The smartphone should then use Java 2 Platform Micro Edition (J2ME) in order to create a user interface to understand the information sent via the Bluetooth. This information will then be sent to a central server where a functional web application will display the data as well. The server space will be provided by UCCS for the proof of concept. For actual implementation, the customer must provide their own server space, such as renting server space from a third party or purchasing a server. 3

4 3 Operation Description The Vehicle Diagnostic Logging Device is designed to be hands off. Once connected to the OBD 2 port, the actual device will not be handled. However, the user will be able to access the data via the smartphone and interact with the server. The smartphone application can be accessed by anyone (i.e. the driver, the driver s supervisor, etc.) in order to the view the most recent data in a read only format. This will allow a user to always be up to date on the performance of the engine. Authorized personnel (i.e. managers) will be able to access the information on the server from any link to the World Wide Web. The user interface will consist of a display of the gathered data, as well as a that can be used to manipulate the data. This toolbox will allow the user to specify a timeframe to look at, ranging from the entire collection of data for a specific vehicle down to a single upload, and also empowering the user to have the system show only specific events, ignore data of a certain type, or mix them to show cases when something changed at a certain rate or when multiple events occurred at once. 4 Requirements Specification The requirements are as follows: 1. All power must be supplied by the OBD 2 port. 2. The ELM327 chip must read data every 1 3 seconds. 3. The ELM327 chip must send the data to the microcontroller for processing. 4. The microcontroller will be 8 bit and low powered. 5. The microcontroller must calculate the maximum speed, average speed, breaking violations, average fuel efficiency, total engine idle time, engine temperature, and the total distance traveled. 6. The microcontroller must be able to distinguish the standard codes used in the OBD 2 port. 7. The Bluetooth device must use a simple serial profile. 8. The Bluetooth device must be able to detect when a smartphone is within transmission range. 9. The Bluetooth device must be able to transmit all of the calculated data to the smartphone. 10. The 2MB flash must be able to store all of the calculated data until a smartphone is within transmission range, and have a method for handling an excess of data with minimal losses in case a smartphone is not within range. 11. The 2MB flash must be able to delete old data once it s been transmitted through the Bluetooth device. 12. The Smartphone application will be implemented using J2ME wireless toolkit in combination with CDLC. 13. The server must have a functional web application with a user interface. 4

5 14. The device must use an SPI interface to interface across a bus to the flash memory from the microcontroller. 15. The packaging of the final product must be small enough to fit within the dash board of the vehicle. Maximum dimensions will be determined after researching the vehicles that will implement this system. 16. The total budget for building and testing the device must not exceed $ Design Deliverables There are four deliverables to obtain. They are listed below. 1. A working prototype corresponding to the block diagram shown in Figure 1 of the Appendix. 2. A read only Smartphone application, implemented using J2ME wireless toolkit in combination with CDLC. 3. A functional web application for data uploaded to the server. 4. Documented test results of the prototype including the success/failure of the prototype to perform, the accuracy of calculations (average fuel efficiency, average speed, etc.), the ability to recognize violations and mark them appropriately, the accessibility of the smartphone application, and the functionality of the web application. 6 Preliminary System Test Plan The performance testing will be completed in two stages. 1. Data that can be given from the OBD 2 port will be simulated within the laboratory. We will verify successful transmission of the simulated data from the serial port to the ELM327, the proper decision making of the microcontroller, the storage of the flash memory, and the successful transmission of the Bluetooth module to the smart phone. We will then verify the functionality of the web application and server. 2. After the laboratory research is conducted, the performance will then be measured by pulling data from an OBD 2 port on a vehicle. We will verify successful transmission of the data from the OBD 2 port to the ELM327, the proper decision making of the microcontroller, the storage of the flash memory, and the successful transmission of the Bluetooth module to the smart phone. The cost to perform these tests will be based on the cost of the parts to implement the design. Acceptance Test for Simulation: 1. The device will be laid out on a prototype board. PCB will be considered if adequate time remains and minimal errors occur with the prototype board. PCB is not a requirement. 2. Standard codes will be used to push data to the ELM327 chip from a PC. 3. Verification that data was transmitted to the ELM327 will be conducted. 4. Confirmation that data from the ELM327 is sent to the microcontroller. 5

6 5. Check that the microcontroller can calculate maximum speed, braking violations, etc. correctly. 6. Confirmation that data can be transmitted to the flash memory from the microcontroller. 7. Verification that data can be sent to the Bluetooth module from the microcontroller. 8. Verification that data can be sent to the Smartphone and that the Bluetooth has a simple serial profile. 9. Confirmation that data can be sent to the server and the web application can display the information. Acceptance Test for a Vehicle: 1. The device will be laid out on a prototype board. PCB will be considered if adequate time remains and minimal errors occur with the prototype board. PCB is not a requirement. 2. Data can be pulled from the OBD 2 port correctly using the ELM Verification that data was transmitted to the ELM327 will be conducted. 4. Verification that the standard OBD 2 codes are interpreted. 5. Confirmation that data from the ELM327 is sent to the microcontroller. 6. Check that the microcontroller can calculate average fuel efficiency, total distanced traveled, etc. correctly by checking the gauges on the dashboard display during the test run and making simple hand calculations. Fuel efficiency can be calculated by measuring the amount of gas used compared to the distance traveled. 7. Confirmation that data can be transmitted to the flash memory from the microcontroller. 8. Verification that data can be sent to the Bluetooth module from the microcontroller. 9. Verification that data can be sent to the Smartphone and that the Bluetooth has a simple serial profile. 10. Confirmation that data can be sent to the server and the web application can display the information. 7 Implications Considerations The device shouldn t require any maintenance once it is installed, and the user interface on the server should require very little training to operate. Since the device is completely run off of the OBD 2 port, it should be able to be installed by any trained mechanic without special instruction. Security of the device could be an issue. It is outside the scope of our project, but customers should be aware that tampering may occur and should take measures to protect the device. 6

7 8 Appendix A: System Diagram Figure 1: Block Diagram 7

8 Appendix B: System Concept Figure 2: System Diagram 8

9 Appendix C: Definitions [1] Engine Control Unit [2] An open wireless protocol for exchanging data over short distances from fixed and mobile devices, creating personal area networks [3] A phone with advanced operating capabilities, including access to the internet and PC like operating systems [4] Diagnostic port found under the dashboard of most vehicles [5] A chip designed to interpret the OBD 2 port [6] The standard codes used by the OBD 2 port, some companies make non standard codes that must be purchased in order to decode 9