Learn me: OBD-II emulation

OK, so this thread got me thinking about OBD-II, specifically how to speak it.

Which lead me to this chip...

Now, I haven't yet decided if this thing can actually generate the OBD-II messages necessary to talk to a code scanner, but my hunch is that it could.

So now the question: this chip is $10. If it can actually respond to OBD-II queries with the proper answer, why don't aftermarket ECUs incorporate it? I'm not sure if an aftermarket ecu has enough spare cycles to both give commands to this and run your fuel/spark, but I imagine a combining this with a cheap, dedicated PIC could do the trick.

So why don't aftermarket ECUs incorporate this for emissions "compliance"? Things like the XYZ ECU flasher already "hide" certain codes, so it's not like this is a line manufacturers don't want to cross.

What am I missing here?

My initial guess is that it would be illegal.

In reply to peter:

The reality is that the market is obscenely small vs the investment needed to both make it work, and certify the product with various regulatory agencies. OBDII is a lot lot more than fuel and spark, there are a ton of subroutines that check and monitor a myriad of systems. Additionally each manufacturer utilizes different sensors on each of these varied systems so a single chip/software solution would never work. remember each manufacturers ECU knows how to interpret each of the different sensors and actuate the various other components that go into the OBDII required functions.

IIRC, there was a substantial thread on the MS forums (a long, long, time ago when I was active there) where it was preemptively filed under "for the love of all that's good in the world don't even think of discussing this on our forums for the legal ramifications of OBD circumvention."

It's been a while, but I think that was the gist of it. I'm not sure what the legaleze is, but I can see a pretty clear distinction between hiding certain codes (depending on what they are) and reporting back to a scanner that "yes sir, everything's legit here!" when it's not related to the actual state of engine management....

I have personally seen it done on a couple different cars (Turbo Elise & Supercharged F-Body), but that was years ago. Now I know in GA they check for specific monitors and datalog. Still technically possible to spoof, but it's not as easy at it used to be.

Just to clarify, it's illegal under Federal law and a Bad Idea. Some states have alternative emissions waivers that you can apply for. If you have a reasonable tune and cats, you should be able to pass a sniffer test.

eebasist wrote: In reply to peter: The reality is that the market is obscenely small vs the investment needed to both make it work, and certify the product with various regulatory agencies. OBDII is a lot lot more than fuel and spark, there are a ton of subroutines that check and monitor a myriad of systems. Additionally each manufacturer utilizes different sensors on each of these varied systems so a single chip/software solution would never work. remember each manufacturers ECU knows how to interpret each of the different sensors and actuate the various other components that go into the OBDII required functions.

I was more thinking along the lines of sticking to the (small subset of) basic OBD-II codes and allowing the aftermarket ECU to set them. I've assumed that the scanner essentially asks the ECU for a list of trouble codes and gets one in reply. Should be dead simple, but this is what I get for assuming.

ransom wrote: [snip]... I'm not sure what the legaleze is, but I can see a pretty clear distinction between hiding certain codes (depending on what they are) and reporting back to a scanner that "yes sir, everything's legit here!" when it's not related to the actual state of engine management....

That's an interesting hair to split. I fail to see the distinction between not reporting a trouble code by intentionally failing to report it (flasher), and not reporting a trouble code by not collecting it (stand-alone OBD-II emulator).

Warren v wrote: Just to clarify, it's illegal under Federal law and a Bad Idea. Some states have alternative emissions waivers that you can apply for. If you have a reasonable tune and cats, you should be able to pass a sniffer test.

I agree to all your points, most emphatically that the actual pollution can be held within the target limits, if a sniffer was used instead of a ECU query.

What I'm interested in is why "flashes" and "unlocks" are kosher enough that tuning companies feel comfortable providing the end-run, but a cheap standalone circuit is verboten.

In reply to peter:

No idea on the legal dance of hiding codes, but emissions-faking devices are spelled out in at least GA state law as a big deal.

Faking the CAN data would be possible on a car-by-car basis. I don't think it would be wise to even think about attempting it. It would be easier to retain both ECUs with quick disconnects and slap in the stock injectors and whatnot for the annual test. You could then quickly revert back to the standalone ECU for your offroad usage.

It's so stupid. Actual emissions compliance is not difficult, but the ridiculous rules and regulations make it so. Don't even get me started on CARB. I don't even live in CA and I frikkin hate everything about it. SB100 all the things.

On another note, I really do wonder if this chip could be used to tickle one of these insurance black boxes. Because that "our device shows that you drove at 300mph for 72 hours straight" phone call would just be so amusing...

peter wrote: On another note, I really do wonder if this chip could be used to tickle one of these insurance black boxes.

Man, you are really into this whole "barking up the wrong tree" thing!

It can't be that hard from a programming point of view. It's a published protocol. The responses are standardized, that's kinda the whole point. There's no reverse engineering to do, you simply set your doodad up to give the correct responses. Yes, various manufacturers can and do add extra sensors, but they're not part of the OBD-II protocol, merely piggybacking on it.

Seems like this would be the starting point.
http://standards.sae.org/j1979_201202/

Here's an older online version if you want a taste. Page 41 gives you an idea of what the codes actually look like, and later they're all defined. I'd never known what the P stood for before http://read.pudn.com/downloads122/doc/comm/520493/标准/saeJ1979_2006-08-25Ballot.pdf

I'm not touching the legality, merely commenting on the feasibility of implementation. I'm not working on an OBD-II emulator or planning to do so.

Keith Tanner wrote: I'm not touching the legality, merely commenting on the feasibility of implementation. I'm not working on an OBD-II emulator or planning to do so.

Shortly:

peter wrote:

ransom wrote: [snip]... I'm not sure what the legaleze is, but I can see a pretty clear distinction between hiding certain codes (depending on what they are) and reporting back to a scanner that "yes sir, everything's legit here!" when it's not related to the actual state of engine management....

That's an interesting hair to split. I fail to see the distinction between not reporting a trouble code by intentionally failing to report it (Cobb), and not reporting a trouble code by not collecting it (stand-alone OBD-II emulator).

The "depending on what they are" is important. Speaking of grey areas (and OBD I, so I am really wandering around here), when I put a '95 325is engine and computer in my '87 325is, part of the Turner chip's job was to shut the stock computer up in its complaining about the absence of a road speed sensor (which its new home didn't have to begin with). It's kind of a contrived example, but the upshot is that OBD II looks at a lot of stuff, and it's not too hard to imagine something which is not strictly necessary (even legally), but which if changed would cause the stock algorithms to complain. Hiding a complaint which no longer applies to the new configuration, if that configuration is, for example, CARB-approved, would be one way.

That's a lot of mumbling; I don't have a perfect real-life example, but that's why I mentioned it: It's not too hard for me to imagine a scenario where that's a legitimate thing to do. Whether that scenario is what Cobb's doing, I don't know.

I guess the flip-side is that if an aftermarket ECU could be certified to keep track of the correct stuff and report it correctly, that wouldn't just be OBD II emulation, that would be OBD II implementation, but the certification would be, I'm sure, a major hurdle.

peter wrote:

Warren v wrote: Just to clarify, it's illegal under Federal law and a Bad Idea. Some states have alternative emissions waivers that you can apply for. If you have a reasonable tune and cats, you should be able to pass a sniffer test.

I agree to all your points, most emphatically that the actual pollution can be held within the target limits, if a sniffer was used instead of a ECU query. What I'm interested in is why "flashes" and "unlocks" are kosher enough that tuning companies feel comfortable providing the end-run, but a cheap standalone circuit is verboten.

I'll be one to point out that it's not a great idea that one talks alot about something that is clearly a defeat device. Very ilegal to sell. And noting that there's no real point in putting the tag "not for road use" is lying, since the point is to get around on road testing.

Now, about the idea that the sniffer test is some kind of valid test that OBDII covers- it's not. Not even close. Most sniffer tests are not all that useful, anyway, since the targets are so incredibly high for the conditions that even if you pass, it's still going to badly fail a real test.

But OBDII main requirement is that the light illuminates once the car exceeds 1.5x it's certified emissions level. There are so few tests out there that run a real FTP75 as sniffers that you would miss that.

CAN you make emissions without OBDII? Sure. Will people do that- highly unlikely.

BTW, flashes are unlocks are tampering as well, and are very ilegal. So you know.

Warren v wrote:

Keith Tanner wrote: I'm not touching the legality, merely commenting on the feasibility of implementation. I'm not working on an OBD-II emulator or planning to do so.

Shortly:

FWIW, many EPA folk are very aware of this site. They have car enthusiests, too. There was a Challenge car that AMOST had an EPA "sponsorship" sticker on it back in the day. And more than one challenge car was worked out, but never built.

z31maniac wrote: My initial guess is that it would be illegal.

From what I've heard it's this. To falsely report that an engine is running properly when it's not, is illegal enough that NO company wants to get into the business of fooling the EPA. That's just a liability that no smart company is going to take.

peter wrote:

Warren v wrote: Just to clarify, it's illegal under Federal law and a Bad Idea. Some states have alternative emissions waivers that you can apply for. If you have a reasonable tune and cats, you should be able to pass a sniffer test.

I agree to all your points, most emphatically that the actual pollution can be held within the target limits, if a sniffer was used instead of a ECU query. What I'm interested in is why "flashes" and "unlocks" are kosher enough that tuning companies feel comfortable providing the end-run, but a cheap standalone circuit is verboten.

Because of the "not for road use" " for off-road use only" tag.

Kind of like how the skater head shops can sell fake pot as "herbal potpourri" or fake coke as "bath salts" as "not intended for human consumption"

Wow, lots of stuff here.

I'm not a corporate entity, I'm not producing anything, and my only vehicle is non-OBD-II. This is all a mental exercise. But as I'm not conspiring to do anything illegal, I'm not concerned about a visit from the EPA. As was pointed out, it's an open protocol and the chips are commercially available. I'm seriously wondering why implementing the OBD-II protocol as an aftermarket supplier is so difficult.

Here's the thing: if, as I understand it, reporting an OBD-II system OK message was as simple as polling a list of N sensors, one could very easily create a PCB with N digital inputs, and reporting via OBD-II whether they were all in the OK or NOT OK state. Amongst all the chicken-littling here, it sounds like the "system OK" check is not that simple. I'd be interested to know whether older implementations were this simple.

Is it because the stock ECU is tuned to pass emissions, then "frozen" in place, and any sensor deviation from normal is then considered a fault? So it's more of a certification that the engine is running according to the stock tune, rather than a certification that all the emissions equipment is present and functioning (ie, altered tune but OK sensors)?

Sigh. Let's all talk about puppies, no one has a problem with puppies, right?

To the OP's curiosity, this chip won't inherently generate or spoof responses. It basically allows a PC to talk to a car's network, a translator if you will. Think 3CPO from Star Wars.

In theory you're totally right, there's nothing technically that hard about it and you've pretty much got it figured out.

But all the talk of legality is the answer to why no aftermarket manufacturer has done it. They don't want to touch the possibility of selling a device that can be used as an OBD spoofer with a 30-foot pole.

alfadriver wrote: I'll be one to point out that it's not a great idea that one talks alot about something that is clearly a defeat device. Very illegal to sell. And noting that there's no real point in putting the tag "not for road use" is lying, since the point is to get around on road testing.

Exactly - Casper Electronics nearly got put out of business for selling an "O2 sensor simulator" that concealed a deleted cat from the ECU. Anything that's blatantly intended to fake a smog test and serves no clear other purpose is asking for trouble.

It could be some companies have different levels of risk tolerance.

In reply to peter:

OBDII isn't just about the sensors. It also does specific running tests to see if the system is operating as it should be. And there are a lot of system tests, all of which need to be completed in a single FTP 75 to clear the base code.

the calibration is, indeed, frozen. But in it, there is quite a range of capability of sensor drift, detection of that, and reaction to it if it would result in a emissions deviation of a certain amount.

One reason why it's so hard to aftermarket is that it's so hard to implement for OEM's. And while some of the test are the same, each OEM may run the tests differently. While the requirements are open, the actual tests are proprietary, and even though the EPA and CARB approve each OEM's test- they are not open to the public.

OBD I was more a sensor check. Which is why a PNP system was able to be developed that was ok in SCCA's eyes to keep a car street legal. SCCA ok'ing does not make it legal, just ok to run at SCCA events.

alfadriver wrote:

Warren v wrote:

Keith Tanner wrote: I'm not touching the legality, merely commenting on the feasibility of implementation. I'm not working on an OBD-II emulator or planning to do so.

Shortly:

FWIW, many EPA folk are very aware of this site. They have car enthusiests, too. There was a Challenge car that *AMOST* had an EPA "sponsorship" sticker on it back in the day. And more than one challenge car was worked out, but never built.

Doesn't bother me if anyone from the EPA reads that post. The communications protocol is publicly available, I spent a few minutes with Google to pull that up and it's available for anyone via the SAE website. It's not a big secret. I just put that bit in there to prevent the predictable phone calls - ie, don't bother calling. I've learned the long way that some enthusiasts will leap on the weakest hint of hope. You should have seen the response on StreetKiaZ.com (not making that up) when we used a Kia block in one of our builds because it was cheap. They thought it was the beginning of a massive push for Kia performance at long last. Anyhow...

I've probably spent more time reading up on what triggers particular codes than most here - alfadriver being the obvious exception. It's not rocket science, and I have to say that reading the actual spec is kind of interesting if you have that sort of mind.

There's a difference between actually implementing OBD-II (monitoring all the sensors for proper function and behavior) and spoofing it, of course. The latter's going to be a lot easier but you're not going to find a US company doing it for fear of legal repercussions.

alfadriver wrote: In reply to peter: OBDII isn't just about the sensors. It also does specific running tests to see if the system is operating as it should be. And there are a lot of system tests, all of which need to be completed in a single FTP 75 to clear the base code.

Thank you for this whole explanation, very awesome and enlightening.

A minimal OBD-II implementation would be very doable - as Keith notes, everything you need is out there. But if there are system tests, etc, definitely not workable.

I've been hacking on medical devices for a year (yeah, I bark up a lot of trees people generally try to avoid), and I wouldn't have expected the EPA to make things quite as difficult for manufacturers as the FDA does. Very interesting and frustrating I'm sure.

Screwing with a voluntary measure with your personal insurance company would just be an amusing prank that would require an agent with the right sense of humor, etc etc.

You guys are looking at this all wrong!

This is the way for us to be able to put newer engines in our race cars!!!!!!!!!! I LOVE IT!!!

RACE CAR ENGINES

(To complete the circle)