No announcement yet.

RFC - project OpenVBus - A different approach to vehicle control.

  • Filter
  • Time
  • Show
Clear All
new posts

  • 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.

    Last edited by redheadedrod; 01-03-2014, 07:58 PM.

  • #2
    My starting point for this project will be some open source projects already in existence but haven't been developed in years and I believe all of them hold limiting licenses. I will be totally redoing the code base just using the current code base as example code. I am not 100% sure if I want to use C++ as my base language or C#. I will be developing using my windows machines under VS2012 or newer.

    The projects I plan to make use of include odbsim, odblogger, openodb.

    I know BennY has been working on some unified control stuff and also tripzero has a project as well. I hope to talk to both of these members and discuss their projects and see where they are headed as well. Might be able to save us all some work if we work together towards a common goal.

    I should note however that I am currently in college becoming a software engineer so my time will be relatively limited but I want to work towards this goal. My truck project will greatly depend on this so I want to build it and evolve it over time. If others jump on the bandwagon it can be developed into something special.

    Last edited by redheadedrod; 01-03-2014, 07:56 PM.


    • #3
      Ok so now you may be wondering why and how far I want this to go...

      This is something I have been wanting to do once I purchased LT1 edit for my Caprice. At that time I realized there were many different utilities out there for different vehicles but each required a totally new interface and new software. With some non standard vehicles it would be hard to warrant a system being built because so few people would be interested in such a beast for the work required. There are also aftermarket control systems that are not ODBII compliant that would be nice to control as well and use with a generic program. The federal government has been coaxing the automotive industry to standardize much of the diagnostic stuff to allow easier access to diagnostic systems for most any consumer or mechanic. But this has still left lots of proprietary stuff out there that isn't illegal but really is no good reason not to be able to control.

      If you look at commercially available diagnostic equipment it can be very expensive. Inexpensive equipment can't do much more than read trouble codes and reset them. I am hoping that by standardizing a method of communicating that we can get away from device specific software and make interfacing to our vehicles much more mainstream for those of us putting carpc's into our vehicles. Plus it would be nice to bring older vehicles up to speed with the current software and technology.

      Where do I hope this goes...
      I am hoping that eventually this could be developed to make a universal interface for most vehicles so that anyone can write utilities for them. Having tech1 or tech2 level of control over our vehicles or simply allowing someone to build a universal android app to control most functions in a vehicle. Or anything one can dream up. With this accessing standard CANBUS modules we should eventually be able to monitor what a module is doing or what it sees, be able to run diagnostics on any module, and potentially download or upload the binary code for that module. Support for the diagnostics or other stuff would require additional software but being able to access the code directly would allow for some interesting possibilities.
      Last edited by redheadedrod; 01-03-2014, 08:18 PM.


      • #4
        I'd definitely use/buy the software if it supported my canbus'd caddy. I'll likely be trying to do some canbus stuff later on once I get my carpc project going/done.


        • #5
          Still working on the hardware for my truck... Will be jumping on the "Project Unified Car Control" project when I get that far...