Maybe helpful for people wanting to interface to ODB CANBUS

Mike_cj0

Member
I have an ELM327 based ODB to USB device that i use for diagnostic tests etc on my car.

I have been reading the datasheet for the ELM 327 main chip and it has plenty of useful information that could be useful to people who have project ideas involving vehicle systems.

The ELM 327 uses only a few aditional components to allow intefacing to any ODB2 compliant vehicle. Fo rinstance to connect to the canbus you just need the elm327, a microchip MCP2551 and a few descreet components.

The ELM327 uses a ttl level serial interface so could be directly connected to a picaxe's serial pins. It also only requires basic ascii commands to to function and the elm327 does the hard work.

I maybe using this to build an adapter for my cars steering wheel controls for the cd/radio as no adapter is available on the market.

Anyway, enough of my waffle, here is the datasheets -

ELM 327 - http://www.elmelectronics.com/DSheets/ELM327DS.pdf
MCP2551 - http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf

Hopefully they will help some one.
 

MartinM57

Moderator
Cue the PICAXE hobby community designing inappropriate hardware, connecting birds nest wiring into the ODB2 connectors on our cars, writing apps that inject badly formatted signals on the CAN-bus and then coming on here asking why something went Badly Wrong(tm) when they drove down to Mrs Miggins Pie Shop last night...

Unless you know exactly what you are doing with automotive and CAN projects (in which case, you wouldn't be here) I would advise staying well away. All IMHO of course...
 

srnet

Senior Member
Out of interest, I know nothing about CANBUS, if you were to write a program for a PICAXE controller, what harm could you do to a vehicle with a simple syntax error in a program ?
 

MartinM57

Moderator
Not a syntax error, per se (you wouldn't be able to program the PICAXE with one, of course), but an error in priority, message ID or data content that maybe affected the ABS, Engine Control, Lighting, Dashboard info, Air Bag etc data that is flying round the bus constantly and in pretty much real time.
 

Mike_cj0

Member
srnet, i believe the potential do cause dame is limited as the cars ECU as i believe you can unly request information from the system or send very simple commands such as resetting indicated fault values. I may be wrong but i dont think you can override the data being transmitted by a digital throttle pedal for instance. Pretty much all you can do is send a given ecu module a request for its current state or listen to the traffic thats on the bus and then use that data to control an external device such as an LCD displaying engine temperatures or the like. i believe due to the operating environment that it has to work in the system is very robust.

The SRS safety systems are on a completely different network and cant be communicated to through the odb port so they cant be interfeared with.

The ELM 327 and MCP2551 provide protection from sending malformed packets on to the canbus as the the elm encodes the instructions that it is sent into a standards compliant format and the mpc2551 provides the actual link to the bus and has a whole load of features to protect the bus. The datasheets goes into a fair bit of detail.

The worst that could happen if your picaxe program sent a request that made no sence to the ELM chip would be that it would responed with either a ? or NO DATA.

I wouldnt suggest having an adapter connected to the odb port all the time as it is usually in the drivers footwell and could well get in the way or be dangerous. However in my car i have a spare canbus connector as part of the wiring loom behind the headunit which is what the factory headunit connects to to read the canbus data for using the steering wheel buttons.

If i am wrong on any point i would be keen to know.

As an added note i plan on setting the MCP2551 to work in recieve only mode.
 
Last edited:

srnet

Senior Member
OK, thanks.

So, I can't use CANBUS to turn someone elses car (it would be silly to use your own) into a giant remote controlled toy ?

Shame, that would be fun.
 

lewisg

Senior Member
If i am wrong on any point i would be keen to know.
In my experience you are absolutely correct in your evaluation of this part of automotive digital communications. This seems like a good starting project since you will only be reading packets that are already present but due to radio replacement don't do anything useful.

Please keep us posted on your progress! I'm sure your circuit(s) and code will help someone else later on. We are all standing on the shoulders of giants...
 

Jeremy Harris

Senior Member
You can't do harm by reading CANBUS signals, the OBD interface was designed to be pretty foolproof (remember it's used by garage technicians mainly). Some here seem overly keen to condemn something interesting based on a lack of understanding, IMHO. The worst you can do in terms of changing things in the car would be to alter some of the user or service centre settable options, things like reversing beeps, seat belt warning audible alarms etc, none of which affect basic vehicle operation or systems safety. In fact you can change all these settings just as accidentally by using one of the many ELM327 based diagnostic/settings units like the Scangauge, but no harm will result.

Hopefully the OP won't be discouraged by the negativity and will carry on with the experiment, as it sounds like an interesting project (and I comment as a Scangauge owner who has played around a fair bit with OBD CANBUS settings)
 

srnet

Senior Member
The worst you can do in terms of changing things in the car would be to alter some of the user or service centre settable options, things like reversing beeps, seat belt warning audible alarms etc, none of which affect basic vehicle operation or systems safety
Could you turn off things like oil pressurea/level warning indicators, brake fluid warnining levels, disk pad warning levels and the like ?

What sercurity or system allows you to turn off for example a reversing beep, but not for instance a warning that a brake pad is knackered ?
 

Jeremy Harris

Senior Member
Could you turn off things like oil pressurea/level warning indicators, brake fluid warnining levels, disk pad warning levels and the like ?

What sercurity or system allows you to turn off for example a reversing beep, but not for instance a warning that a brake pad is knackered ?
NO! As I have already said, you cannot interfere with safety-critical systems.

The OBD II interface is specifically designed to be primarily read-only, as it's intended to be used by technicians in the garage when they service the car. The vehicle manufacturer can allow some write operations, but these are limited to non-safety critical user-preference settings. For example, the only things I can set on my car are internal audible warnings, like the one that operates when there is a weight on a front seat detected but no seat belt latched signal detected. The warning light that this sensor combination operates can't be turned off from the OBD II port, only the beeper. The same goes for a few other settings, the reverse beeper can be turned off but the illuminated reverse indicator cannot.

None of the oil pressure, temperature or level settings can be written to, they are read only. The same goes for things like the steering angle sensor, the brake pedal position sensor, brake pad warning signals, tyre pressure indications, throttle position sensor, engine rpm signals and all the myriad other sensors on a modern car.

Quite apart from anything else, vehicle systems are also fail-safe, or fail-benign, and have to be to get through approval. This means that, for example, if a critical sensor fails, or an abnormal CANBUS signal appears, the system will either shut the car down or put it into a fail-benign mode, with reduced functionality and perhaps performance (a little like the limp-home mode that older ECUs used when they detected a sensor failure). For example, if a critical braking system CANBUS error (or a dodgy sensor reading) is detected then the system will open all the control valves in the braking system (they are also fail-safe and open when powered off normally), disable ABS and traction control, disable vehicle stability control and revert to non-power assisted braking, along with some prominent warning displays to tell the driver things have gone seriously wrong. The brakes will still work OK to stop the car, albeit with none of the enhancements we have come to expect.
 

hippy

Technical Support
Staff member
As I have already said, you cannot interfere with safety-critical systems.

For example, if a critical braking system CANBUS error (or a dodgy sensor reading) is detected then the system will open all the control valves in the braking system (they are also fail-safe and open when powered off normally), disable ABS and traction control, disable vehicle stability control and revert to non-power assisted braking, along with some prominent warning displays to tell the driver things have gone seriously wrong. The brakes will still work OK to stop the car, albeit with none of the enhancements we have come to expect.
I think what people are worrying about is a PICAXE OBD system could bring such things about. If a PICAXE knocks ABS or power assisted steering out that is something you don't want to happen just as you are relying upon it. Losing ABS or power steering would by most people's definitions be classed as the PICAXE having interfered with the safety critical system.

What would be the situation if the PICAXE and/or ELM327 inadvertently floods the CANBUS with data which it cannot handle ( perhaps using the wrong baud rate or timeouts ) or sends so much data that other devices cannot get their messages onto the bus in a timely fashion ?

I don't know if that could happen but with regards safety critical systems the onus is on proving it cannot.
 

Jeremy Harris

Senior Member
My guess is that there is a bit of a general misunderstanding here of what you can and cannot access (or indeed connect to) via an OBD II port, which is creating unfounded concerns and tales of doom. The OBD II port only allows limited access to the car systems (I think this is the third time I've said this, but I guess that message isn't hitting home).

You can't think of OBD II port as being a hard connection to the master bus, as it isn't. It allows read access to pretty much all the sensors, plus some processed data, on the CANBUS (or manufacturer specific variant). It may also allow limited (and buffered) write access to some of the vehicle processors to change some settings, but this write access is effectively firewalled behind the OBD II interface.

The concept of flooding the CANBUS with data is a bit off the mark, quite apart from the effective firewall that the OBD II port provides. CANBUS isn't like a serial port, it is a complex bidirectional bus with a very high degree of built-in robustness against interference and node failure. As such it's remarkably tolerant to failure and interference, which isn't really surprising given it's core application in cars.

Finally, the OBD II port has already been certified as fail-safe, nothing connected to it can cause the car to crash, the brakes to fail or whatever, the worst that can happen is that the car fails-safe or fails-benign and stops working as designed.
 

hippy

Technical Support
Staff member
The OBD II port only allows limited access to the car systems (I think this is the third time I've said this, but I guess that message isn't hitting home).
It's easy to say it or believe it but for a safety critical system such belief has to be proven to be accepted as fact.

You can't think of OBD II port as being a hard connection to the master bus, as it isn't.
I was under the impression that it was, with the data signalling lines exposed via the OBD II connector. That reflects my understanding from others who have interfaced to their ODB II sockets which required a physical CANBUS interface chip ( MCP2551 or similar ) and a controller ( ELM327, microcontroller or PC ).

I was under the impression that using the OBD II interface was much like connecting to a LAN via a passive hub rather than connecting to a firewall in front of that hub. It could be either and I wouldn't like to say. In the absence of proof there is a firewall for a safety critical system one would have to assume that there isn't such a firewall.

Of course, the ELM327 ( or whatever controller is used ) acts as a firewall, but on the inside or outside of the ODB II connector one does not necessarily know the reliability or robustness of such a firewall under all situations, cannot simply assume it won't let adverse things through onto the bus for a safety critical system.

It is of course possible to design a passive system that only sees messages on the CANBUS, only watches the bus and cannot put anything on to the bus, but once you have something which can illicit responses by controlling the bus the potential for adverse bus interference is there.

the worst that can happen is that the car ... stops working as designed.
That's the impact on safety criticality that one would seek to avoid.

With safety critical systems the onus is on proving that things are not unsafe. Until that's done it has to be assumed they could be.

One also has to be careful with terms such as "fail-safe" as some mechanisms are often only fall-back positions rather than absolute guarantees of a safe outcome - After power assisted steering fails during cornering, having non-assisted steering is better than nothing; it helps towards avoiding ending up on the wrong side of the road and driving head on into incoming vehicles but doesn't guarantee that you won't.
 

Jeremy Harris

Senior Member
The point that seems to be being missed is that the vehicle provides the isolation to make the OBDII port fail safe. It's part of Type Approval. All the ELM 327 does is provide the right bus protocols to interface with a handful of different manufacturer interpretations of CANBUS and allow connectivity to pretty much any system that wants to read or limited write to the bus.

Earlier I tried to explain this, but I may be doing a poor job of it. Here's a slightly long-winded but perhaps more thorough description of the way things work in order to help get the message across.

As I guess most know, proving that software/firmware is safe gets harder the more complex the code gets. By the time you get to a few thousand lines of code it becomes near-impossible to verify that the code will work as expected under every combination of inputs and outputs. There are several ways of dealing with this problem. On aircraft and spacecraft safety critical systems a multiple central processor approach is often used, with different types of processor on each redundant multiple and different, isolated, software teams writing the same functional code but using different languages and compilers for each processor. Polling systems are used to compare the outputs of each processor, with any oddball outputs from one causing a processor to be taken off line. The process uses "majority voting" to decrease the risk of a software/firmware error causing a reliability problem that might jeopardise safety.

Where the mass of additional processors can't be tolerated (originally for safety critical military applications) then a system of using a robust language that's designed to be safe (at the moment this is principally ADA, but some flavours of C are accredited now I believe) together with certified compilers that have been proven (by static code walkthrough) to generate consistently safe code. Even then it is still common to perform hand static code walkthroughs of the compiled code against all possible I/O combinations to ensure safety. This is a long winded and time consuming approach, but is one used for things like aircraft engine FADEC systems.

Car manufacturers faced a big safety challenge as more automation started to make its way into vehicle systems. It isn't cost effective to use aircraft/spacecraft/military software/firmware methods for safety critical systems, yet as soon as vehicle steering, throttle and braking systems needed "computer" control this is pretty much what was demanded for safety approval. Car manufacturers came up with a way around this problem, by dividing the vehicle up into several different sub systems, each of which only has a few hundred lines of code at most and each of which can be safety certified by testing as a consequence. Not only does this get around the complex safety critical certification problem, but it also allows systems to be updated and changed by just re-qualifying a single module, rather than the whole car.

To make such a system work safely, each module, or sub-processor, needs to be fail safe or fail benign. This means that in the event of a sub-processor being interfered with, by, for example, an oddball CANBUS signal, it will invoke its own graceful and safe failure protocol. The downside to such a distributed processing approach to safety critical systems is the need to move lots of data around the car all the time, both to do health checks on the sub-processors (a little like a sophisticated watch dog) and to transmit commands and sensor/display signals from module to module. For example, when you press the brake pedal a command will be sent to the brake processor telling it to activate the brakes at a specific rate and with a specific pressure that is dependent on the pedal force and the rate of pedal movement. This is a direct (not CANBUS) signal from the pedal to the brake processor. The brake processor will activate the brakes, vehicle stability system, ABS etc and will send CANBUS signals back to the vehicle display indicator sub-processor telling it that it's braking normally, activating anti-skid or that it has a problem (brake pad wear, ABS failure or whatever). Even if the CANBUS gets blocked by some fault that will not (and cannot) affect the way the braking system operates, because if the brake processor (which is only a fairly dumb beast at the end of the day) detects a problem it will fail safe, by de-powering all the ABS brake fluid valves and modulator and allowing brake pedal pressure to directly and fully operate the brakes.

A similar process takes place for other sub-systems, like the engine ECU, body ECU (which normally controls lights and wipers), steering ECU, airbag and restraint system ECUs or even the more trivial and less safety critical sub-systems, like the radio and navigation system. Although CANBUS connects all these systems and allows them to communicate, CANBUS itself isn't fully a part of the safety critical certification. It doesn't need to be because the sub-processors themselves are the key to providing this functionality - they will fail safe or fail benign even if CANBUS totally fails, or they get unexpected CANBUS commands. It has to be like this to allow for things like bus failures, connectors getting unplugged or the garage technician fiddling about via the OBDII port.

It's a clever bit of design, one that has allowed a great deal of automation to be incorporated in cars without there being a massive overhead in safety critical systems verification (and anyone who has been involved in such work will know just how costly and time consuming it is). The core message is "if you keep a system relatively simple you can more easily certify it as being safe", something that has a direct bearing on people designing and building Picaxe projects. At least one Picaxe project I know of has used a similar distributed processing approach, the one Peter Perkins undertook with his battery monitoring system. Each of his cell modules had code that was simple enough to be 100% tested against any failure mode, with the bus allowing communication to a master unit that mainly did overall management and display. The slave units worked stand-alone from a safety critical systems standpoint, monitoring cell voltage and operating shunts directly as I recall, so even if the bus failed the cells were still kept safe.
 

hippy

Technical Support
Staff member
Each of his cell modules had code that was simple enough to be 100% tested against any failure mode
I doubt it, not against any failure mode. For example, here's a simple system design which continuously measures light levels, lights a LED when dark, turns it off when light -

Code:
Do
  ReadAdc LIGHT_LEVEL_PIN, b0
  If b0 < 120 Then 
    High LED ' Dark so LED on
  Else
    Low LED ' Bright so LED off
  End If
Loop
Most people would classify that as perfect code which does the job infallibly. When it's working it does indeed do its job as expected but if it fails it will not.

If it does fail then we generally don't care, no harm done.

But what if the LED scares off night monsters and if you don't have it turned on at night you'll die, but if you do have it on during the day you'll attract day monsters and be killed by them. Should people put trust in that code if their lives do depend on it always working correctly ?

I can count at least three obvious failures which would prevent such a system from working as desired, putting the LED on during the day or leaving it off at night, with all the potential consequences.

In fact it's perhaps a good exercise in understanding safety critical issues to take that simple program and make it as infallible as possible. At the very least always allowing something else to determine there is a failure even if this code itself can't do anything about that failure.
 

srnet

Senior Member
Each of his cell modules had code that was simple enough to be 100% tested against any failure mode, with the bus allowing communication to a master unit that mainly did overall management and display
As I hope you realise, that is just not possible, or rather it might be but we have know way of proving it.

Its missleading to suggest that any code can be 100% tested against 'any' failure mode, serious professionals know this of course, but the average hobbyist reader of these forums would not.
 

Buzby

Senior Member
Most people would classify that as perfect code which does the job infallibly. ...

... I can count at least three obvious failures which would prevent such a system from working as desired,
Hippy, I beg to differ.

I would say the code is 100% testable and 100% infallible.

The code for your Monster Scarer is simple enough to be exhaustively tested with every possible input , i.e. the full range of analogue values 0 to 255, so it's logical behaviour can be predicted for every possible combination of inputs, and those combinations can be presented in any order.

In your example there will probably be an annoying flickering of the LED around dusk and dawn.
The sofware engineeer may decide to add timers or hysterisis to remove the flicker.
The behavour of the code will not now be the same for two occurences of the same input presented at different times, so proving it will take more complex testing, but it is still a 100% predictable system.

Any program built from predictable logical elements will have a predictable behaviour, although it may be very diffcult to do that predition on a very complex ( but still perfectly logical ) program.

However, I wouldn't trust my life to a system in which this code was used, until I knew a lot more about the whole setup.

Determining if a system is fit for purpose is a different kettle of fish.

Now questions about hardware and environment are important.

What proof exists that the PICAXE firmware always interprets tokens the exactly the same way ?
( For example, there could be a an internal counter which overflows after some time and corrupts the interpreter. )

What is the inherant reliability of the PIC chip ?, of the light sensor ?, of the LED ?
How reliable is the power supply ?, how immune to interference ?.
What if a leaf falls off a tree and blocks light to the sensor ?
IWhat happens if it gets rained on ?

Until all these questions, and more, can be answered, I won't be buying Hippy's Patent Monster Scarer.

Cheers,

Buzby
 

Jeremy Harris

Senior Member
The last point is key and is one reason why military level safety critical systems have to use qualified compilers. These have been exhaustively tested so that they are known to always compile "safe" and consistent code.

The challenge with designing and building safety critical systems, be they mechanical, electrical, hydraulic, electronic hardware, or software is that testing them becomes massively more difficult as the level of complexity increases. The specific issue with software/firmware is that it is relatively easy to increase the complexity of the code whilst keeping a fairly simple hardware arrangement.

When designing safety critical, distributed architecture, systems, like those used in modern cars, the safety enhancement is provided by breaking things down to smaller, more readily tested, units. The design approach is also key to the success of this approach, too. The first thing the designers do is list all of the input and output parameters for the sub-processing "block". The safety critical design process hinges on getting the interface spec spot on, every bit as much as the safety of a mechanical braking system hinges on getting the design and tolerances right.

Once the I/O specs are defined, testing the completed module (hardware and firmware) is a similar process to testing a mechanical sub-assembly. Every single combination of I/O is tested, including all foreseeable fault or failure conditions, which provides an adequate level of qualification. It isn't 100% safe, because that isn't possible even for a mechanical or hydraulic system, but the required safety standard is that the electronic system shall not be worse than an alternative. In fact, electronic systems have been proven to be better than mechanical systems in safety critical automotive applications, most probably because their development forced designers to use more formal safety assessment methods.
 

bpowell

Senior Member
Jeremy: Very interesting data; thank you! Monitoring / displaying ODBII data is on my list of "when I get to it" projects! I'll be bookmarking this thread...and probably copying it to a file just in case it gets deleted. :)

Mike_cj0: Thanks for the data sheets...great find!

Please keep us updated on progress / code samples!
 

srnet

Senior Member
I dont know enough aboutn CANBUS to dispute what is being said about the system being failsafe.

However if a 'hobbyist' had be tinkering with a cars CANBUS, for whatever reason, I think I would not want to be a passenger in thier car, who would ?
 

RexLan

Senior Member
I dont know enough aboutn CANBUS to dispute what is being said about the system being failsafe.

However if a 'hobbyist' had be tinkering with a cars CANBUS, for whatever reason, I think I would not want to be a passenger in thier car, who would ?
REALLY? Surely you're not serious. Want a ride ... LOL.
 

Jeremy Harris

Senior Member
I dont know enough aboutn CANBUS to dispute what is being said about the system being failsafe.

However if a 'hobbyist' had be tinkering with a cars CANBUS, for whatever reason, I think I would not want to be a passenger in thier car, who would ?
That's your prerogative, but it really just shows that I've not explained things adequately well.

FWIW I have a Scangauge hooked into the OBDII port on my car and I'd happily let anyone sit in the passenger seat and bang in random CANBUS commands while the cars working. It might do some odd things, and beep some warnings, but I am certain that all the safety critical stuff, like brakes and steering, will carry on working just fine, and more importantly the worst that might happen is a shut down, which can be cleared on reboot (i.e. restarting the car).

99% of the time all you can do with an ELM327 hooked up to the port is read data from the car anyway, the write operations are restricted and limited to a few minor functions. Because CAN is a message based, rather than address based, protocol, unless a message has a specific meaning to a sub-processor on the bus it will simply be ignored.

If you send gibberish over the bus it will simply be ignored. It's not like either I2C or serial protocols, because it has been specifically designed to operate in a harsh environment and with things hooked up to it that can tinker about with data on the bus. Have you seen how many after market CBDII units are around and used by garages all over the world? Do you think that all garage technicians are so good at this stuff that they couldn't accidentally stuff loads of erroneous commands into the bus when they service your car? The reason you don't hear of accidents caused by all this tinkering that goes on every time a car is serviced is because the bus is designed so as to make it safe.
 

bpowell

Senior Member
I dont know enough aboutn CANBUS to dispute what is being said about the system being failsafe.

However if a 'hobbyist' had be tinkering with a cars CANBUS, for whatever reason, I think I would not want to be a passenger in thier car, who would ?
Said the man on the ground as the Wright Brothers flew...
 

buntay

Senior Member
This is a very interesting thread. But I think there are alot of people missing the obvious and don't really know how a car works and these are the people who rely on the mechanics. with that being said lets look at a few facts. Car company have put alot of money into making the engine more efficient with the use of a "computer". now most companies have proprietary software and settings for thier products. and because there is a safety standard that must be met I find it highly unlikely that critical elements can be easily modified. Granted there are programmers out there that do grant access to changing parameters but I highly doubt that someone could stumble on to the low level programming dealing with making the car safe. If one wants to poll the ODB for info that can be done easy as pie but to make changes to safety critical elements? I don't think so.


when all else fails contact one of the manufacturers and do research. :D
 

Jeremy Harris

Senior Member
I think it's also a human failing to assume that mechanical systems can be 100% tested and therefore be 100% safe. They are every bit as prone to failing in a non-graceful way as electronic systems, in fact more so, because even now mechanical parts on cars are often not designed to be fail safe.

To quote one example I have personal experience of with my wife's car, a Citroen C3, it seems that the cars that use this front suspension design (it's shared between some Citroen, Renault and Peugeot model) are prone to front coil spring failure. This seems a common failure mode on several of these models and when the spring breaks there's about a 50% chance that it will break the flexible brake hose and the jagged end then rip the side wall of the tyre, depending on whether the break in the coil is facing outward or inward. The consequences of this mechanical failure can be severe, total loss of control and partial loss of braking, together with a high probability of the car swerving off the road or into oncoming traffic. My local garage confirmed he'd seen several examples of the same spring failure as we suffered and an internet search shows that it is/was a fairly common occurrence on these cars. Clearly far less effort had been put into assuring that the suspension was designed to be fail safe than had been put into the electronic systems of the car, something that doesn't particularly surprise me.
 

Paix

Senior Member
I have a Citroen Picasso and that was the subject of a vehicle recall in around 2003. I believe that some sort of retainer was fitted to limit the damage. . . . probably why the risk is now only about 50:50 :)
 

retepsnikrep

Senior Member
I'm doing quite a bit with older obdii protocols at the moment, sending commands on the bus and changing some vehicle parameters, it's not vodoo or magic beans, just common sense and pretty logical. It won't all blow up when you get something wrong and is no more dangerous than modifying your cars brakes or suspension IMHO. I'm looking forward to moving into and interacting with canbus shortly. In my project I will be analysing the data passing over a dedicated non obdii can interface between two specific vehicle computers and injecting packets/modifying what going back and forth.

I don't claim by BMS software is failsafe though!!!!

As an aside I used the elm chip for about one week on the obdii protocol but then went straight to direct interface with the pic itself which is very easy and avoids the expense of the elm chip. Canbus might be a bit trickier though ;)

My Interface circuit uses a 16F886 pic and talks too the standard KLine OBDII bus and a Honda specific bus on another OBDII pin at a different speed.

http://www.solarvan.co.uk/obdii/ODBIIGauge16F886.jpg
 
Last edited:

hippy

Technical Support
Staff member
The opposite side of the "it can't go wrong" coin are those who have demonstrated being able to take over system control via CANBUS in ways that could be catastrophic if done in a moving vehicle.

While this was done in terms of how someone could maliciously affect a system to which not having access would be a primary safeguard, once you facilitate access you open the door to malicious action both deliberately caused and unintentionally. Many things said to not be possible proved indeed to be possible.

The issue of 'fuzzing' is particularly relevant to damage a PICAXE or similar system could inflict; simply throwing inorrect packets on the bus causes some ptentially dangerous events to occur.

Full paper at http://www.autosec.org/pubs/cars-oakland2010.pdf, snippets below -

Reflashing ECUs While Driving. The standard also states that ECUs should reject reflashing events if they deem them unsafe. In fact, it states: &#8220;The engine control module should reject a request to initiate a programming event if the engine were running.&#8221; However, we experimentally verified that we could place the Engine Control Module (ECM) and Transmission Control Module (TCM) into reflashing mode when our car was at speed on jack stands. When the ECM enters this mode, the engine stops running. We also verified that we could place the ECM into reflashing mode while driving on the closed course.

Fuzzing. Much to our surprise, significant attacks do not require a complete understanding or reverse-engineering of even a single component of the car. In fact, because the range of valid CAN packets is rather small, significant damage can be done by simple fuzzing of packets (i.e., iterative testing of random or partially random packets). Indeed, for attackers seeking indiscriminate disruption, fuzzing is an effective attack by itself.

Brakes. Our fuzzing of the Electronic Brake Control Module allowed us to discover how to lock individual brakes and sets of brakes, notably without needing to unlock the EBCM with its DeviceControl key. In one case, we sent a random packet which not only engaged the front left brake, but locked it resistant to manual override even through a power cycle and battery removal. To remedy this, we had to resort to continued fuzzing to find a packet that would reverse this effect. Surprisingly, also without needing to unlock the EBCM, we were also able to release the brakes and prevent them from being enabled, even with car&#8217;s wheels spinning at 40 MPH while on jack stands.

Lights Out. Our analysis uncovered packets that can disable certain interior and exterior lights on the car. We combined these packets to disable all of the car&#8217;s lights when the car is traveling at speeds of 40 MPH or more, which is particularly dangerous when driving in the dark. This includes the headlights, the brake lights, the auxiliary lights, the interior dome light, and the illumination of the instrument panel cluster and other display lights inside the car.

Critical components, like the EBCM brake controller, are connected to the separate highspeed bus, with the Body Control Module (BCM) regulating access between the two buses. One might therefore assume that the devices attached to the low-speed bus, including aftermarket devices, will not be able to adversely impact critical components on the high-speed bus. Our experiments and analyses found this assumption to be false.
 

buntay

Senior Member
@ Hippy


I stand corrected :eek:

I guess it would come down to if you want to monitor ok, but one should not try to do anything else
 

MartinM57

Moderator
Far too many long posts here :D

If you know absolutely what you're doing then I guess that a guaranteed read only device using low level components like the ELM is fair game. If you don't know what you are doing, but you consider yourself 'experienced' then maybe something a bit more high level like a Arduino can bus shield, proper connectors etc. would be appropriate. If you're not really sure of what you're doing and/or have limited experience then I (IMHO) would suggest finding a different project.
 

Buzby

Senior Member
What proof exists that the PICAXE firmware always interprets tokens the exactly the same way ?
( For example, there could be a an internal counter which overflows after some time and corrupts the interpreter. )
A little OT, and a couple of weeks late, but highly relevant to the discussion about software reliability.

A worldwide supplier of SCADA software had a major support issue on 1st Jan 2012.
A deeply hidden bug in some core software, originally written when the 8086 was fresh, sprung into life.
Many thousands of factories and services around the world are affected.

The bug is related to a date-range function, but nobody all those years ago thought to test if the function worked beyond 2011.
It didn't, and now the supplier has had to supply a software patch to update the systems.

But the problem is compounded by the fact that the bug did not crash every system on 1st Jan 2012.
The bug only kicks in when a change is made to the system, such as would be needed if a new vessel was added to a chemical plant, or an old conveyor removed from a warehouse.

So the effects of this bug will be occurring sporadically for years to come.

There are lots of lessons to be learned from this, not least is the fact that just because some software has been running OK for twenty years, it doesn't mean it will run OK tomorrow.
 

MartinM57

Moderator
Interesting and I've no reason to doubt you, but in the words of Wikipedia "This article needs additional citations for verification" :D
 

7cory7

Member
Jeremy:
I'm very interested in your project. I am a hobbyist Honda Tuner with a turbocharged 1993 Accord. My car is OBD1 which allows me full control of the ECU, (Yes full control, I blew the engine with a stupid mistake) and I get better gas mileage while highway cruising but also have double the horsepower when I want it too.
Most of us who also have an OBDII car simply build/buy a harness for the car and run an OBDI ECU in it.
I also have experience with the MegaSquirt custom ECU on a turbocharged Rotary RX7, and the Bosch Motronic ECU in a Turbocharged VW GTI.
There are many commercial products that will read CANBUS info, and I would love to be able to have what you intend to build because with your setup I could data-log and see where changes need to happen.
I have almost 0 experience with OBDII BUT with anything automobile related I do understand that i am operating a 3800 pound projectile that I am ultimately responsible for!!!!!
Hippy is right though in that many dont understand the effects of their actions. This however doesnt mean for you to stop the project, just be careful to let others know of possible dangers (Mostly not knowing what they are doing:))
I was considering buying just such a product for my 1999 Ford expedition. Building one would be a lot funner though.
Keep working on this and I'll help out if I can.
Cory.
 

dmaxben

Member
As been said, modern car electrical systems (and databusses) are INCREDIBLY robust. You really cant "crash" them, no matter what you do. Not to mention, modern automotive electrical systems are incredibly clean as well. Im not sure why everyone thinks that modern car electrical systems are still the "dirty nightmare" that they might have been back in the 1970's when you had points opening and closing etc... People need to remember that pretty much everything on cars today is driven by microcontrollers and computers. The automotive engineers know this and have made HUGE strides in making modern car electrical systems perfectly safe for electronics of all types. Alternators are all solid-state regulated and smoothed, etc.

For example, all of the GM trucks and SUV's have had something called "regulated voltage control" since 2005. Basically there is a module dedicated JUST to control efficiency of the electrical system, the alternator, and how the battery is charged. There is a module that has an inductive (?) clamp/ring around both the battery cables and the cable coming out of the alternator. That module continuously monitors how much current the truck electrical devices are drawing at that second, it records battery temperature, battery health, battery sulfation info, what voltage the battery dropped to at last startup and how long the vehicle was sitting, and if it senses that any of the battery cells are getting weak/wearing out, it changes the whole charging rates and manages the electrical system loads differently, and exercises the battery carefully to preserve the life left in it. Alternator charging is all solid state controlled by the ECM (the main engine control module) with a PWM signal, and a databus signal.

I dont know much about other vehicles, but GM has used several different databusses over the years. In pre-2005ish vehicles, Class 2 for low-speed body communications (instrument cluster, radio, HVAC, amplifier, windows, doors, lights etc), which is a single-wire databus, common chassis ground. I think it floats around 3 volts and is pulled up to 7volts for a "1" and pulled to chassis-ground for a "0". 10.4kbps, pretty slow. Tons of error checking, priority headers, etc. You can even do cool things like send ASCII text to the message-center display in the instrument cluster. For ECM-TCM (trans control module) communications, because those were higher priority real-time messages they used an isolated J1939 CAN bus, twisted pair, 250k. In later vehicles, they went to their proprietory GMLAN databus in two forms. Low speed GMLAN, 33.3kbps, technically a "single-wire CAN", which otherwise works the same as the old Class 2 bus, common chassis ground and then 1 "databus" wire. Then high speed GMLAN for powertrain comms, 2 wire CAN, twisted pair, 500kbps, 120ohm terminating resistors at either end. If you were to send an unrecognized/misformatted/totally whacked-out command, the modules would simply flag the message as "jibberish", ignore it, and go about their business. They will only follow a command unless it was directly addressed to them. And even then, anything "safety critical" physically CANT be commanded by a databus command...the modules just wont do it because they only understand and will only process specific messages that have been programmed into their software from the factory, no matter what you tell them. You cant just "hack the bus" and send a data message to the airbag control module and make it deploy the airbags....it just doesnt work that way.

Yes, everything is databus controlled, from the radio to the amplifier to the ABS module etc. But you have to remember, all of those modules are still "standalone" in their own form. Automotive databusses are not designed with a central node and while all modules share info over the databus, they are NOT dependent on eachother to function.

Example A. If you cut the databus wire going to the airbag control module and you are in an accident, your airbags will still deploy just fine, because all of the sensors are hardwired directly to the airbag control module. Now what WONT happen (because you cut the databus wire, or shorted it) is that after you crash and the airbags deploy, the airbag module wont be able to command the doors to power-unlock (obviously you can just flip the manual door lock lever, just like you did in the days before power locks), it wont be able to command the interior lights to turn on, the 4-way lights to flash, and it wont be able to send a data message to the OnStar module to automatically summon help "SOS"....but so what...

Same thing with ABS. Again, its a standalone controller. Yes, it communicates with the ECM (to request torque reduction during a stability-control event), instrument cluster (to turn on the ABS warning lights if theres a problem), etc. But if you were to severe its ties with the rest of the computers in the truck....you'll still have power brakes (again, its a mechanical system/brake-booster), you'll even still have ABS....only thing you will lose is traction control and stability control. But again...so what...most cars older than 10 years or so dont even have stability/traction control to begin with. Even if you cut ALL ELECTRICAL POWER going to the ABS module, you'll still have power-assisted brakes. You just wont have ABS....

If you cut the databus wire going to the engine computer once the engine is running, it will keep running just fine....again....all critical sensors (such as the drive-by-wire throttle pedal) ARE HARDWIRED DIRECTLY TO THE ECM. The things that will happen is you'll lose your instruments (tach, speedo, coolant temp, fuel level, oil pressure), and if you shut the engine off, it wont restart until the databus wire is back online because it uses the databus to exchange anti-theft passwords with the transponder in the key.

As said above...I cant reiterate enough how incredibly robust/failsafe automotive computer systems are. Modern car electronics are designed to operate in harsh environments, and they are designed to cope with and isolate direct short-circuits, loose connections, etc...

And second of all, saying you could lose things like power steering and brakes by having a PICAXE do something funky on the databus is flat out ridiculous, no offense. Power steering is a mechanical system driven by a hydraulic belt-driven pump on the engine, and power-assisted brakes are either hydraulically boosted by the mechanical-belt-driven power steering pump, or manifold vacuum off the engine. So unless a PICAXE command messing with the databus can make your power steering hoses spring a leak, you dont have anything to worry about as far as a total databus meltdown causing a "dangerous loss of control" under ANY circumstances.

Ill gladly take a video of me directly shorting any Class 2 or CANbus wire to ground OR to battery positive voltage, just to prove that nothing happens, and the databus is plenty capable of isolating and ignoring any severe problems...ill do this with the vehicle safely parked in the driveway of course though. :)

I was helping a friend of mine fix the harness going to his instrument cluster...on the 24 pin connector, the battery +12v wire is directly above the Class 2 databus wire. We accidentally put the pins back in the wrong place when we were repairing the connector. Started the truck and the instrument cluster wouldnt turn on/boot up (because it wasnt getting a data message to "wake up!"). Basically it was backfeeding 12volts directly onto the Class 2 bus. I plugged in my scan tool to figure out why the cluster wasnt "waking up" and found that a bunch of modules were setting "loss of communications with instrument cluster" trouble codes, and had then isolated themselves from the bus. I rechecked the wiring, found our mistake, swapped the pins, cycled the ignition once, and the cluster booted right up....I cleared all of the "loss of class 2 comms" codes, and havent had any problems with anything else since...that was 30,000 miles ago. No magic smoke, no fires, no expensive burned-up computers.... This is the 21st century. Cars have gotten a lot smarter than what they used to be....... ;)

for what its worth....

Ben
 

dmaxben

Member
In fact, electronic systems have been proven to be better than mechanical systems in safety critical automotive applications, most probably because their development forced designers to use more formal safety assessment methods.
Exactly. You're probably about 1000x more likely to have a brake failure due to a brake line rusting out (for example) than something "causing a raucous on the databus"...

Something neat along these lines is the story of ancient airbag systems still working fine decades later. Believe it or not, car airbags as we know them today originated back in the early 1970's. They were pioneered by GM and were available in some of the higher-end ~1971-1976(?) Buick's and Cadillacs. It was only a $300 option or something like that. What you got was dual frontal airbags, both controlled by an actual digital (not analog) computer that had basic self-diagnostic, trouble-code-storing, and event-data-recording (IE, if you were in a crash, it would record things like G-forces etc, basically a black-box). Pretty amazing cutting-edge stuff for the early 70's. The public didnt understand them though, and after several small children were killed (due to sitting in the front seat and not wearing their seatbelt), they disappeared until the late 1980's when Mercedes brought them back.

But on with the "electrical robustness" part of the story. A couple years ago, from what I remember reading in the story (I cant for the life of me find it online, I read it in a magazine), someone found an old Buick Electra (with the super-rare optional airbags) in a barn somewhere...rotted away, seats chewed up by mice, engine siezed solid, all brakes seized up...basically the car was barely even worth scrap. They threw a fresh battery in it, turned the key on, and the airbag light came on and then went out, indicating that self-diagnostics had passed. For grins, they towed it to a crash facility, and crashed it. 35+ years later, after sitting for who knows how long abandoned in a barn, Both airbags deployed properly and right on cue
 
Last edited:

hippy

Technical Support
Staff member
And second of all, saying you could lose things like power steering and brakes by having a PICAXE do something funky on the databus is flat out ridiculous, no offense.
I can only point to the link in an earlier post and what the researchers demonstrated there ...

http://www.autosec.org/pubs/cars-oakland2010.pdf

Our fuzzing of the Electronic Brake Control Module allowed us to discover how to lock individual brakes and sets of brakes ... In one case, we sent a random packet which not only engaged the front left brake, but locked it resistant to manual override even through a power cycle and battery removal ... we were also able to release the brakes and prevent them from being enabled, even with car&#8217;s wheels spinning at 40 MPH while on jack stands.
It's not so much that a vehicle bus system isn't sound or resilient in itself, it's more what can happen when a controller, PICAXE or other, is introduced into that system.

The researchers were deliberately injecting 'dodgy packets' into the system to achieve their results but it's no different to a PICAXE unintentionally injecting the same with the same results. If their controller can instruct one wheel to lock at speed or completely disable braking then there's a definite risk that a PICAXE or any other micro could do the same.

I'm sure no one deliberately designs any system to put themselves in danger but the issue is what happens when someone does by accident or error or even through issues they have no direct control of ?
 
Top