The beginning of the end for ECU tuning?

[Jeff V.]

They were trying to make it so you'd be guilty of a DMCA violation if you used a tool other than their officially blessed (and expensive) one.

Cars have low detail, government mandated OBD2 for emissions diagnostics. But if I want to log into the high detail, proprietary diagnostics, then that usually involves a security routine. If I write my own software to access that secured mode, bam, DMCA violation.

[alienviking]

[quote=""Duck Vader""]Issue I see from reading up on this before is what happens if the tractor goes down in the middle of the field? Now the farmer can't work on his own tractor to get it back running to finish the work or in some cases even get him back home if far from home and bad weather is coming in.[/quote]

From having been in that exact situation with both tractors and combines - you call a local expert who brings a fully loaded repair van out on site. If you think a farmer will have either the knowledge or tools to repair a tractor out in the field you are fooling yourself. Not only will he have neither, but modern tractors are friggin space ships with more technology than the space shuttle had.

A typical farmer fixes things with duct tape, steel wire, a big hammer and maybe a welding tool. Not a highly advanced ECU tuning tool, radar tuning tool etc.

[Chris95RT]

[quote=""Jeff V.""]My sister in law had a 98 Mercedes wagon. It was worth, at best, $2000. She had to replace the key for it. This was a $300 part, only available from Mercedes. Not only was that a significant portion of the car's value, but what happens when Mercedes eventually discontinues support for that model of car and/or key?

Right now you can't get new ABS controllers and steering position sensors for the C5 Corvette. The hardware is out of production, old units can't be rebuilt because the electronic specs aren't available. Even if you could get a part, you'd need to take them to a dealer to be programmed, or invest in hundreds of dollars of equipment and software subscriptions to program it yourself.[/quote]

1) That does suck and honestly there's so much wrapped into that I could rationalize it multiple ways. My dad has had keys reprogrammed off ebay for less than 50 bucks for my old Jeep, often they do it for free. Would it be better to allow access to the key system to anyone for them to figure it out? I would disagree.

And Who is responsible for that 300 dollar charge? The dealer? The OEM, I dunno.

2) You're better at nitpicking that stuff that I am, and quick google does semi confirm that but there's others saying that AC Delco makes parts for it. But again, is it dealers charging ridiculous fees to a class of people who own those cars (vetts and mercedes = money = can sped a lot for the replacement) or is it OEMs trying to control what you can fuck with so they can ensure the cars safety.

I guess what do you do when you can't get parts for a 91 3S anymore? You deal? You get a new car? Should OEMs be expected to support their cars indefinitely?

I know which lines of the argument we fall on, just speaking my mind.

[Duck Vader]

[quote=""alienviking""]From having been in that exact situation with both tractors and combines - you call a local expert who brings a fully loaded repair van out on site. If you think a farmer will have either the knowledge or tools to repair a tractor out in the field you are fooling yourself. Not only will he have neither, but modern tractors are friggin space ships with more technology than the space shuttle had.

A typical farmer fixes things with duct tape, steel wire, a big hammer and maybe a welding tool. Not a highly advanced ECU tuning tool, radar tuning tool etc.[/quote]

Just saying that is what I read. I have personally only worked on and used older tractors. None of these new high tech ones.

[Jeff V.]

I don't need expensive, proprietary vendor specific software to diagnose anything we have on our network. 99% of my diagnostic work is done in a generic terminal window or web browser. All of the vendors we use publish their software bug lists, change logs, and troubleshooting routines freely.

I can't find the specific standard at the moment, but EPA made it a requirement as of 2008 to provide emissions diagnostics via CANbus.

[Jeff V.]

I guess what do you do when you can't get parts for a 91 3S anymore? You deal? You get a new car? Should OEMs be expected to support their cars indefinitely?

If some Chinese manufacturer wants to manufacture new ABS modules, they can legally reverse engineer the hardware. But the OEMs have made it needlessly complex and illegal to reverse engineer the software. Without the software, the hardware is useless. If everything wasn't so fucking proprietary, then one vendor could manufacture a generic ABS module that would work in multiple OEMs vehicles.

If I don't like what Juniper is doing, I can drop a Cisco or Adtran or any of a dozen other vendors hardware right in its place. We did exactly that with our Google Fiber business customers. Google's hardware is crap. It's barely good for residential use. It's borderline useless for a business. So we replaced it with inexpensive Ubiquiti hardware that is lightyears more capable. This was all possible because the underlying protocols and hardware interfaces were standardized.

But since the OEMs refuse to cooperate on common equipment, then after some period like 20 years or something, they should be required to publish sufficient specs to enable 3rd parties to build and repair parts.

[vr4]

[quote=""Jeff V.""]My sister in law had a 98 Mercedes wagon. It was worth, at best, $2000. She had to replace the key for it. This was a $300 part, only available from Mercedes. Not only was that a significant portion of the car's value, but what happens when Mercedes eventually discontinues support for that model of car and/or key?

Right now you can't get new ABS controllers and steering position sensors for the C5 Corvette. The hardware is out of production, old units can't be rebuilt because the electronic specs aren't available. Even if you could get a part, you'd need to take them to a dealer to be programmed, or invest in hundreds of dollars of equipment and software subscriptions to program it yourself.[/quote]


My bosses dad just had his c5 abs module rebuilt.

[Chris95RT]

[quote=""Jeff V.""]I don't need expensive, proprietary vendor specific software to diagnose anything we have on our network. 99% of my diagnostic work is done in a generic terminal window or web browser. All of the vendors we use publish their software bug lists, change logs, and troubleshooting routines freely.

[/quote]

Maybe it's my ignorance, but you can get VID/PID and DTC information from reading P/B codes with standard things.

If you want to get deeper and start programming things like the infotainment system, which is rapidly becoming a safety critical system due to backup camera requirements, yes you need proprietary things to do that.

On the other hand if I want a different BIOS on my Lenovo laptop because I don't trust Chinese stuff- can't do that, so I either don't buy that laptop or deal with the situation.

I can't find the specific standard at the moment, but EPA made it a requirement as of 2008 to provide emissions diagnostics via CANbus.

Would be suprised that they would specify the phy to be honest, but I dunno.

If some Chinese manufacturer wants to manufacture new ABS modules, they can legally reverse engineer the hardware. But the OEMs have made it needlessly complex and illegal to reverse engineer the software. Without the software, the hardware is useless. If everything wasn't so fucking proprietary, then one vendor could manufacture a generic ABS module that would work in multiple OEMs vehicles.

I know you keep saying this, but a) I don't want that situation where some people from China can reverse engineer a part that helps me slow down and b) Each OEM has their own standard to test and design against that in the end ties down to their own brand and use case. I know we go back and forth on this a lot, but you cannot force Chrysler to conform to a Mercedes standard on everything.

They do it where they can, you just don't see it. Diesel and body controls are a big thing where the module form factor may be different but the electronics are the same.

CAN the physical layer is the same.
CAN at the networking layer isn't, why? Because each OEM has their own requirements for bandwidth, signaling, and network topology. And it's easily configurable from the supplier side.

If I don't like what Juniper is doing, I can drop a Cisco or Adtran or any of a dozen other vendors hardware right in its place. We did exactly that with our Google Fiber business customers. Google's hardware is crap. It's barely good for residential use. It's borderline useless for a business. So we replaced it with inexpensive Ubiquiti hardware that is lightyears more capable. This was all possible because the underlying protocols and hardware interfaces were standardized.

You have at least 5 OEMs to choose from if you don't like one car. The situation you're describing is more akin to saying, I don't like the parts that make up the system not the system itself.

I can't take the google hardware, and flash Cisco routing software on it- or maybe I can? I dunno.

But since the OEMs refuse to cooperate on common equipment, then after some period like 20 years or something, they should be required to publish sufficient specs to enable 3rd parties to build and repair parts.

I think we just agree and disagree on this, they commonize where they can maybe it's not as visible outside the electrical architecture of the car. No you can't take a BCM from one car and put it on another for so many reasons, but you can take the electronics from one module and reuse it in another which is what they do; for example the stuff I'm working on now takes ICs from phones/servers and puts them in automotive modules for ADAS.

The internet experience or use case is to interpret a protocol that runs the internet, the internet is largely the same and car's just are not.

But I digress.

[Chris95RT]

But since the OEMs refuse to cooperate on common equipment, then after some period like 20 years or something, they should be required to publish sufficient specs to enable 3rd parties to build and repair parts.

Suppliers do that already for them? Until it's not profitable, and then they don't.

It's why old mustang and Camaro parts are easier to find and fuck with than 3s parts.

[Jeff V.]

Maybe it's my ignorance, but you can get VID/PID and DTC information from reading P/B codes with standard things.

Simple, real world scenario I was running into earlier this year. GM released a performance upgrade for the magnetic suspension on the C7. People were asking how to tell if the car was properly upgraded. Some people were getting their cars back and it didn't feel any different.

GMs proprietary tool can show the calibration part numbers. Those can be compared to a list to tell whether the car was upgraded properly.

There is no other way to get this information. This is not top secret, competitive info. Getting the current software versions of a module is common sense shit that should be available via any basic diagnostic tool. But GM doesn't publish the commands for it. There's no way to get DTCs or run diagnostics on the suspension module either.

It's not even secured. I ran a bus sniffer and pulled the commands out. It's fucking simple. But now I'm afraid to post it anywhere because in doing so, I not only violated my terms of service with my GM software subscription, but I may be subject to DMCA violations.

GM and Ford and BMW and Porsche don't need their own special little snowflake ways to run some "report programmed status" commands. I can pull a thousand performance parameters out of a basic network switch using a simple protocol like SNMP and a manufacturer provided MIB file. There is absolutely no technical reason an automotive OEM could not provide the same info in a similar format. I honestly don't see any reason they couldn't just use SNMP to begin with.

The only reason they don't do it is because there are far too many people with a vested interest in keeping it expensive and complicated in order to preserve their own profits and jobs.

On the other hand if I want a different BIOS on my Lenovo laptop because I don't trust Chinese stuff- can't do that, so I either don't buy that laptop or deal with the situation.

Don't be ridiculous. First up, a laptop isn't a $10,000+ purchase that you're locked into for years at a time. Second, you can replace it with another manufacturer's hardware and still run Windows or Linux and all your apps. Third, if you want to replace the motherboard, or keyboard, or display, you can buy a new one and snap it in. There's no expensive tools or software required. Fourth, yes, you can change out the BIOS in some instances.

https://en.wikipedia.org/wiki/OpenBIOS

[Chris95RT]

I guess to finish my little manifesto, a lot of this comes from a lot of different angles but one common use case.

They want to prevent counterfeits being made, so take the IoT world where people could grab your device, reverse engineer the code, inject something harmful into it, and then resell it as the original device. I'm sure from one point of view it looks sinister, and from the negative press about JD it certainly seems like ripe for abuse; but on the other, there's so much code, unused variables, and registers that if given the chance I'm sure an enterprising person could really do some weird shit.

I'm guessing the people in the automotive world are just as concerned with that scenario, which is why you're seeing similar implementations of that technology.

[Jeff V.]

This isn't about reverse engineering. Going back to the ZR1 example, the controller firmware isn't encrypted. It's just digitally signed. There's nothing stopping anyone from reverse engineering the control strategies for the LT5 engine. They just can't write changes to the car. I honestly don't even object to that. I totally get why they're doing it.

It's the fact that they require expensive tools and software to diagnose the module and write that signed firmware to it to begin with. It's the fact that at a whim, they can just decide to drop support for cars past a certain age. At that point, no amount of resourcefulness will get that car back on the road when it needs repair.

With everything going to cloud based, you can't even count on some hobbyist archiver to keep the necessary software alive somewhere. Once they decide it's done, you're shit out of luck.

[Chris95RT]

[quote=""Jeff V.""]
GM and Ford and BMW and Porsche don't need their own special little snowflake ways to run some "report programmed status" commands. I can pull a thousand performance parameters out of a basic network switch using a simple protocol like SNMP and a manufacturer provided MIB file. There is absolutely no technical reason an automotive OEM could not provide the same info in a similar format. I honestly don't see any reason they couldn't just use SNMP to begin with.
[/quote]

Because the information you're getting is standard since the inception of the internet, SNMP, HTTP, all those protocols are the same.

- GM might do their battery management with a temperature signal in C.
- Ford might do it with with a temperature signal in F.
- Chrysler might infer it based off of some formula because they're too cheap to get a BMS.

You can't force them all to do things the exact same way.

The phy is similar, but the protocols might have evolved differently based on their individual needs and ability to pay for it. Cars are just inherently not the same, but that's not to say they're not evolving to be similar with the advent of an ethernet bus- so maybe we'll see more standardized protocols, along with more memory on the modules/expertise to understand the software stacks behind interpreting it.

I just don't see how they're doing it out of laziness or a fuck you attitude.

The only reason they don't do it is because there are far too many people with a vested interest in keeping it expensive and complicated in order to preserve their own profits and jobs.

Really- the only reason is that they're out there to fuck people? Honestly sounds like a miss, or sounds like they need a better way of telling people it's updated.

I know from personal experience if I released something poor, and it affected service it would come back to me to be fixed in the next revision.

Don't be ridiculous. First up, a laptop isn't a $10,000+ purchase that you're locked into for years at a time. Second, you can replace it with another manufacturer's hardware and still run Windows or Linux and all your apps. Third, if you want to replace the motherboard, or keyboard, or display, you can buy a new one and snap it in. There's no expensive tools or software required. Fourth, yes, you can change out the BIOS in some instances.

I'm not being ridiculous.

Well aware of what you need to do to change it in some instances using a custom JTAG, Beaglebone black/RBPI, others you're just fucked and have to deal with it. So you're right, no expensive tools, but a lot of expertise which comes off at no cost because someone offered it up, and didn't develop it as part of their deliverable.

And no, you can't take a keyboard from an asus and put it in a lenovo laptop. Just like I can't take the BIOS from one and flash it into the other, but fitment and interfacing for memory is the same across the board because the interface to them isn't protocoled and just a memory bus.

To add...

I honestly don't know the limitations between the ethernet and CAN OSI models, so I'm not aware if you can support natively application layer protocols like SNMP and the like on CAN- I feel like it's a limitation of the protocol stack, and not people's inability to do it.

I know the phy's are different though and thus the bandwidth situation is different.

[Chris95RT]

[quote=""Jeff V.""]This isn't about reverse engineering. Going back to the ZR1 example, the controller firmware isn't encrypted. It's just digitally signed. There's nothing stopping anyone from reverse engineering the control strategies for the LT5 engine. They just can't write changes to the car. I honestly don't even object to that. I totally get why they're doing it.

It's the fact that they require expensive tools and software to diagnose the module and write that signed firmware to it to begin with. It's the fact that at a whim, they can just decide to drop support for cars past a certain age. At that point, no amount of resourcefulness will get that car back on the road when it needs repair.

With everything going to cloud based, you can't even count on some hobbyist archiver to keep the necessary software alive somewhere. Once they decide it's done, you're shit out of luck.[/quote]

Honestly man you have a lot more familiarity in that area than I do, so maybe GM is trying to grab money by controlling things tightly. Or maybe they didn't want to deal with having parts of things public and parts of things private, and their ability to diagnose things cheaply is hindered because of it.

Or maybe that the cost to make things as modular as possible is outweighed by the need to get things working for the masses.

I know ford wouldn't give just anyone access to the ST1,2 and 3 calibration to just anyone nor would they allow you to reflash ECUs over CAN without a proprietary device for obvious reasons. Even if it was just ROM you were modifying.

[Chris95RT]

With everything going to cloud based, you can't even count on some hobbyist archiver to keep the necessary software alive somewhere. Once they decide it's done, you're shit out of luck.

It's funny-

Someone at Ford came up with an idea to run their control strategy over the cloud, and use neural networks to determine optimal tuning and whatnot real time. But the control loop time that you need to react to was waaaaaay too short to deal with sensor delay + network delay + external processing delay, especially with cost as a factor.

Or maybe you're stating that people don't keep the software on websites anymore? I dunno.

[Jeff V.]

Because the information you're getting is standard since the inception of the internet, SNMP, HTTP, all those protocols are the same.

- GM might do their battery management with a temperature signal in C.
- Ford might do it with with a temperature signal in F.
- Chrysler might infer it based off of some formula because they're too cheap to get a BMS.

Come on. You know as well as I do that at the end of the day, the module reports temperature as "0xAF" or some such low level shit. It's up to a higher level protocol to translate that data into something human readable like Celsius or Fahrenheit or Kelvin.

That's the whole point of the MIB in the SNMP example. If I send some long ass OID string to a switch, and it replies with "212" I don't know if that's a temperature or the number of current cache hits or some kind of timer in minutes or seconds or hours or years. That's why I need a translation table in the form of a MIB.

All this shit exists. They just refuse to publish it, let alone in some kind of common format like SNMP.

And no, you can't take a keyboard from an asus and put it in a lenovo laptop. Just like I can't take the BIOS from one and flash it into the other, but fitment and interfacing for memory is the same across the board because the interface to them isn't protocoled and just a memory bus.

I don't expect to change cosmetic shit like keyboards (fenders, taillights, etc). But you're kind of making my point for me. I can get generic hard drives, or memory, or USB peripherals, or wifi access points, or power supplies. There's no reason you can't have generic body or powertrain control modules with application specific software.

I honestly don't know the limitations between the ethernet and CAN OSI models, so I'm not aware if you can support natively application layer protocols like SNMP and the like on CAN- I feel like it's a limitation of the protocol stack, and not people's inability to do it.

SNMP wouldn't work for module to module signaling, but it'd be fine for external diagnostics. It's extremely compact and resource efficient.

Also, I found the EPA CANbus thing.

https://www.gpo.gov/fdsys/pkg/CFR-2013- ... 806-05.xml

(iv) ISO 15765-4:2005(E), January 15, 2005. Beginning with the 2008 model year and beyond, this industry standard shall be the only acceptable protocol used for standardized on-board to off-board communications for vehicles below 8500 pounds. For vehicles 8500 to 14000 pounds, either this ISO industry standard or the SAE standards listed in paragraph (h)(1)(vii) of this section shall be the only acceptable protocols used for standardized on-board to off-board communications.

Or maybe you're stating that people don't keep the software on websites anymore? I dunno.

Basically. Have you ever seen the roof diagnostic program for the 3000GT Spyder? It's this ancient old DOS thing. It's a miracle someone managed to pry it out of ASC in the first place. But at least it exists and can be kept alive in online archives and virtual machines running DOS on emulated hardware. If that had been on some cloud server somewhere, there'd be nearly no chance of properly diagnosing and repairing a Spyder roof.

[Chris95RT]

I don't expect to change cosmetic shit like keyboards (fenders, taillights, etc). But you're kind of making my point for me. I can get generic hard drives, or memory, or USB peripherals, or wifi access points, or power supplies. There's no reason you can't have generic body or powertrain control modules with application specific software.

Because you're all over the place on different levels of abstraction with your examples as they stretch from protocol specific implementation, to physical level signaling which I'm trying to make my point on, so maybe we just agree about different things- I dunno.

Bosch reuses the drivers, MCU/MPU, input protection circuit, etc for their modules as much as they can because they're at the physical layer because it makes things cost less and you get higher quality out of the end result- they don't reuse things at the system level. Once you get to the system level, it becomes implementation specific because of the requirements to that system. There would be no reason to include the overhead of a driver for heated seats when you don't have heated seats at all- for example, the circuitry may be there to control it, but the interface to the system is not.

I know we reuse our power electronics between different industries but we have to reengineer it to be used in a car because it has to be safer, but the same concept is there. Hardrives, Memory, all use physical level signaling which aren't protocol specific- the same things exists for MCUs to flash them in the form of JTAG. And voltage is voltage as well as current, although your power requirements may be different from implementation to implementation.

Come on. You know as well as I do that at the end of the day, the module reports temperature as "0xAF" or some such low level shit. It's up to a higher level protocol to translate that data into something human readable like Celsius or Fahrenheit or Kelvin.

That's the whole point of the MIB in the SNMP example. If I send some long ass OID string to a switch, and it replies with "212" I don't know if that's a temperature or the number of current cache hits or some kind of timer in minutes or seconds or hours or years. That's why I need a translation table in the form of a MIB.

All this shit exists. They just refuse to publish it, let alone in some kind of common format like SNMP.

Again, there's a major difference between what CAN can support and what Ethernet can support and you're kinda out of my wheelhouse with respect to that. I know SNMP runs on TCP/IP, which neither runs on CAN but might run on automotive ethernet; so maybe it's a limitation of the protocol stack and not people being greedy. In the end I can certainly see why OEMs don't want people gaining access to every physical signal in the car.

I guess you're just not making your argument strong enough that you need access to the CAN bus in its entirety, and what the OBD interface doesn't provide you. The calibration ID certainly is a good example, but again the mechanism there seems to be the one that deserves the scrutiny not your inability to grab any information from the CAN bus (such as anti theft codes, for example).

Also, I found the EPA CANbus thing.

To me that reads the protocol, not the physical layer. Meaning I could implement OBD over Ethernet and be compliant, but that's really neither here nor there since they'll just rewrite it when new stuff becomes available.

[Jeff V.]

OBD only gets me emissions stuff. I want OEM level diagnostics for all modules, using standard hardware and software. They already do this to a point with UDS (unified diagnostic services). They just don't publish the commands and responses. J2534 was supposed to allow generic hardware, but then the OEMs got picky about which specific devices they would talk to.

Google GMW3110-2010. It's a leaked copy of part of GMs diagnostic strategy. If I can find it on Google, so can a competitor.

ISO 15765 is a standard for sending data packets specifically over CANbus. So no, you could not run OBD over Ethernet and still be compliant.

[Chris95RT]

I guess while we will always agree to disagree with respect to how modules should be able to be hot swappable between OEMs, I can give you an example of a situation here where we dealt with different form factors due to people not wanting to put the money for a 5c regulator.

One of our Capacitive touch for our ARM core based MCUs included a 5c regulator so you could hook it to a 12v signal or a 5v signal.

The RX version of it, which looked the same, had to have a 5v pre reg on it because they didn't want to include the 5c in the BOM.

Should you have forced them to do it? Absolutely, but that's a pretty simple scenario so where do you stop? It gets worse the more complicated the system gets. Maybe Audi is okay with buying higher voltage components at a premium for a more efficient power system, whereas Ford just went with the standard 12v because they have less heavy power requirements due to less electronics.

Do you force Ford to pay for the extra components? Or do you force Audi to make it modular? Or do you force the module vendor to absorb the cost; because 24v systems don't work with 12v natively. Or dang, maybe Ford wants to do their cycle plans for their vehicle lines at different points because of manufacturing constraints.

That's how I see it, whether it's right or wrong.

[Chris95RT]

ISO 15765-4:2016 places restrictions on those International Standards for the fulfilment of the regulations. It does not specify in-vehicle CAN bus architecture, but seeks to ensure that the vehicle's regulated CAN communications comply with external test equipment requirements.

ISO 15765-4:2016 defines the requirements to successfully establish, maintain and terminate communication with a vehicle that implements the requirements of the OBD/WWH-OBD regulations. Plug‑and-play communication capabilities among vehicles and test equipment are defined to assure the interoperation of external test equipment and vehicles. This part of ISO 15765 details all of the OSI layer requirements to achieve this goal.

--https://www.iso.org/standard/67245.html

That's the successor to the one you stated, seems like it protects what you want it to? And it seems to me to add language to future proof things by saying it doesn't specify the architecture but just the protocol and interface, but again I'm not in that area. I really don't know man, just know what I've seen from reuse on both the IC side of things and the vehicle systems side of things.