The OBDII breakout module connected to the Vehicle Simulator/Recorder module:
Here is a picture showing the card stack making up the vehicle simulator/recorder module:
A little additional perspective :
When thinking about how the internet-of-things will evolve, it is easy to predict vehicles will be a significant focal point for consumer applications, since vehicles currently represent by far the biggest technology expenditure/investment by the average consumer. Vehicles are very complex machines incorporating multiple micro-controllers communicating via on-board buses. The level of electronic technology in vehicles has exploded and there is a large amount of vehicle data readily available on the diagnostic bus which is used locally, but not yet used for the vast number of potential external applications.
There will be whole sectors of applications such as :
Initial Simulator Concept :
Initially the system will need to be able to provide OBD2 data just as a real vehicle would in response to queries on a CAN bus or K-Line interface. To ensure realistic data, trip data will be collected from real vehicles the project will include a data collection system as well as a playback / simulation system. During a simulated trip, previously recorded data can be interpolated to provide appropriate data to any bus queries.
An attempt will be made to keep the software modular enough that it won't be difficult to replace fault code simulations with better simulations when more is understood about their behavior and also to replace recorded trip scenarios with computed simulations, if and when they get developed.
Objectives :
The primary objective for this project is to provide a vehicle simulator system that provides realistic enough data, primarily in electronic form, to allow developers to test their OBD2 reader prototypes & data applications in a lab instead of needing to test in a vehicle.
A third objective is to make the vehicle simulation system a modular platform that can be extended and upgraded to become a more accurate simulation for more vehicles.
An auxiliary objective is to create a data collection system that will continuously query a vehicle during a trip and record real data with time stamps.
VTR Block Diagram :
System Platform :
In order to make a compact open system that can be easily setup for testing or demonstration at any location the Beagle bone Black (BBB) has been chosen as the platform. Several of them are being supplied by the project sponsors Texas Instruments, Cisco and element. This will allow a data collection system (RTR) to collect trip data from a real vehicle, then a simulator system VTR can simulate this trip for the same data collection unit to see if it collects the same data from the simulation as it did from the real trip. This dual system provides an easy way to validate the system.
System Design :
OBD2 data provides a lot of information about what is occurring inside vehicle systems, but it does not necessarily provide everything desired in a simulation, such as location and orientation of the vehicle, distance traveled, and time stamps on all data.
The Beagle bone Black (BBB) has a CAN bus capability, but a custom cape will be needed to translate this to OBD2 signals and add in a K-Line interface. This cape will also include a GPS module and a 10 channel sensor suite - 3 orthogonal linear accelerometers, 3 orthogonal angular rate sensors, 3 orthogonal magnetometers and an absolute pressure sensor. These sensors are not needed in the simulator system, but will allow more sophisticated sensor data to be collected when the device is used for recording real trips and this data can later be presented by the simulator. The VTR/RTR cape will also include a Bluetooth module - when in VTR mode it will allow generation of fault codes and control of the VTR from a smart phone, when in RTR mode it will allow connection to a Bluetooth OBD2 interface or possibly a smart phone.
RTR Block Diagram :
Project Plan :
The first major task is to set up 2 Beagle bone Blacks to communicate with each other over a CAN bus. This will allow us to gain an understanding of CAN bus messages and protocol. There are a bunch of associated sub tasks such as obtaining appropriate hardware, organizing software development tools, researching what is available on open source, writing some test code, etc.
Both vehicle simulator and vehicle recorder systems have been built and they communicate with each other fine over the CAN bus.
We are still having a devil of a time sorting out OBDII communications with a real vehicle. This is the main reason for such a long delay since our last posting, however I figured we need to post at least an update.
This screen shows location coordinates when the GPS finds enough satellites. Right now it is still showing UTC time.
This is a little warm because I have some bright lights shining directly on the module.
We are still sorting out some of the analog channels...
The LCD updates "instantly" in response to the keypad scroll buttons because it is interfaced via SPI.
Here is a picture showing the card stack making up the vehicle simulator/recorder module:
When thinking about how the internet-of-things will evolve, it is easy to predict vehicles will be a significant focal point for consumer applications, since vehicles currently represent by far the biggest technology expenditure/investment by the average consumer. Vehicles are very complex machines incorporating multiple micro-controllers communicating via on-board buses. The level of electronic technology in vehicles has exploded and there is a large amount of vehicle data readily available on the diagnostic bus which is used locally, but not yet used for the vast number of potential external applications.
- safer driver operation of the vehicle, fewer distractions, more automation
- more effective driving methods
- ways to save fuel
- safer mechanical performance, better & more timely maintenance warnings
- lower cost operation and lower maintenance costs
- better and more timely driver information
- better advanced traffic warnings and route planning
- vehicles better designed to address owner needs and habits
- accident response applications
- vehicle-to-internet applications
- vehicle-to-vehicle communications
- applications that use data from multiple vehicles
Initially the system will need to be able to provide OBD2 data just as a real vehicle would in response to queries on a CAN bus or K-Line interface. To ensure realistic data, trip data will be collected from real vehicles the project will include a data collection system as well as a playback / simulation system. During a simulated trip, previously recorded data can be interpolated to provide appropriate data to any bus queries.
An attempt will be made to keep the software modular enough that it won't be difficult to replace fault code simulations with better simulations when more is understood about their behavior and also to replace recorded trip scenarios with computed simulations, if and when they get developed.
The primary objective for this project is to provide a vehicle simulator system that provides realistic enough data, primarily in electronic form, to allow developers to test their OBD2 reader prototypes & data applications in a lab instead of needing to test in a vehicle.
An secondary objective is to make the vehicle simulator such that it can be used to demonstrate new products and applications indoors at trade shows or sales presentations.
A third objective is to make the vehicle simulation system a modular platform that can be extended and upgraded to become a more accurate simulation for more vehicles.
An auxiliary objective is to create a data collection system that will continuously query a vehicle during a trip and record real data with time stamps.
System Platform :
In order to make a compact open system that can be easily setup for testing or demonstration at any location the Beagle bone Black (BBB) has been chosen as the platform. Several of them are being supplied by the project sponsors Texas Instruments, Cisco and element. This will allow a data collection system (RTR) to collect trip data from a real vehicle, then a simulator system VTR can simulate this trip for the same data collection unit to see if it collects the same data from the simulation as it did from the real trip. This dual system provides an easy way to validate the system.
System Design :
OBD2 data provides a lot of information about what is occurring inside vehicle systems, but it does not necessarily provide everything desired in a simulation, such as location and orientation of the vehicle, distance traveled, and time stamps on all data.
The Beagle bone Black (BBB) has a CAN bus capability, but a custom cape will be needed to translate this to OBD2 signals and add in a K-Line interface. This cape will also include a GPS module and a 10 channel sensor suite - 3 orthogonal linear accelerometers, 3 orthogonal angular rate sensors, 3 orthogonal magnetometers and an absolute pressure sensor. These sensors are not needed in the simulator system, but will allow more sophisticated sensor data to be collected when the device is used for recording real trips and this data can later be presented by the simulator. The VTR/RTR cape will also include a Bluetooth module - when in VTR mode it will allow generation of fault codes and control of the VTR from a smart phone, when in RTR mode it will allow connection to a Bluetooth OBD2 interface or possibly a smart phone.
The first major task is to set up 2 Beagle bone Blacks to communicate with each other over a CAN bus. This will allow us to gain an understanding of CAN bus messages and protocol. There are a bunch of associated sub tasks such as obtaining appropriate hardware, organizing software development tools, researching what is available on open source, writing some test code, etc.
- Design, build and test an OBD2 cape for the BBB.
- Connect a BBB to a vehicle and send and receive OBD2 messages.
- Write the RTR data collection firmware.
- Write VTR simulation firmware.
- Test and validate system.
Both vehicle simulator and vehicle recorder systems have been built and they communicate with each other fine over the CAN bus.
We are still having a devil of a time sorting out OBDII communications with a real vehicle. This is the main reason for such a long delay since our last posting, however I figured we need to post at least an update.
No comments:
Post a Comment