RFC - project OpenVBus - A different approach to vehicle control.
I have had a dream to build something really cool for the past 10 years and I think with recent research this dream is starting to become a possible reality. I may have talked about this in the past but didn't really know what direction to head in but now I think I have a better grasp on what I can do. It will be a major undertaking but I think it is innovative enough that if I am successful it can be used as a basis for a bunch of projects.
I want to build a new system for interfacing into vehicles. if we look at how a printer is connected to our computer we don't need to know specifics on how the printer works. We just need to know what it supports and using a generic driver do what we need to do. If the same printer also has a fax and scanner you can also take advantage of those with the same driver. If you get a new printer you just load the proper driver and use your original software and away you go.
I want to make dealing with cars this easy. In short I want to build a Vehicle Bus Device system. Initially it would be windows based but could be adapted to others I am sure. I may use C# with .Net due to its rapid code building capability or use C++. I can always port it to C++ at a later time or just use Mono to move it to Linux. The intention would be to make a high level system that would allow a software package to work with any car and be able to control any system in that car. The software package accessing this device doesn't need to worry if the car is a ford, chevy, bmw or whatever.
As I see it this device will be sort of like a tree type device with 2 levels to it. There will be an interface level and a vehicle level.
The interface level would be the actual interface between the vehicle and the computer. This would default to a single ODBII connection but could actually be multiple ODBII devices to take advantage of multiple data buses in the vehicle or could even be a custom interface built with an Arduino type device to add an interface to the computer. I will be able to test this with my Truck which is almost fully controlled via CANBUS and with my older ODBI based caprice. In the older ODBI vehicle I will have very limited options available since it only deals with the engine and transmission but I would be able to add functions by building a new interface into my vehicle. This interface could be to control my windows, pop the trunk or whatever I can think up. The intent is that this VBUS device won't care how it works.. Just that it is available.
While doing research I have seen some test rigs that have as many as 4 or more CANBUS hookups and other types of in vehicle data networks such as LIN or non ODBII compliant networks. This would allow full connections to a vehicle for testing or whatever. The intent of this device system is it won't care how may interfaces you have. Your end software package will still work the same way. There will need to be a way to prioritize which interface to use when more than one interface accesses the same module. This would be useful for when one bus allows full access to a module and another bus only allows limited access.
The other level would be the vehicle level. This would be vehicle dependent and be where you have an interface that works with many vehicles. I am not sure yet how to progress with this but I am thinking that the default ODBII driver should contain anything that can be accessed through the normal ODBII device. This universal driver could then be over ridden or expanded upon by other interfaces.
The end product of this experience?
In my control panel I will have a "Vehicle Bus" option and in device manager there will be a "Vehicle bus" item listed when connected to a vehicle.
In this you would be able to configure some of the options that may be available. It will operate much like how a printer works.
(Linux would obviously have a different interface)
The software package would be able to communicate with the VBUS device and request a generic piece of information such as RPM and the device would return it in a simple format regardless of the original source. If a vender wants to make their proprietary device work with the software they could easily do so by extending the drivers already included.