Quote:
Originally Posted by brufleth
A number of reasons. First they don't want to overwhelm a driver with too much info. If they had half a dozen lights come on while you're on the highway it could distract to a dangerous degree. This is something that's actually pretty carefully considered by various agencies and the car makers themselves.
Then they also don't want to give just enough information to be dangerous. An engine code may or may not have an obvious sounding cause but even given an obvious name it might be caused by something else. Would you be more or less pissed if you replaced a sensor yourself that an indication seemed to point to and it didn't fix anything?
Another reason is that manufacturers don't want to give away all the information about what's going on in the ECU. If you start getting into the nuts and bolts of what sets a specific code (which would be the next step) they have to tell you more and more about their software. This gets dicey concerning intellectual property and international exports. This is all commercial (non military) so that's not as bad but still can be a pain.
Source: I design and support ECU software for engines.
|
Thanks for your reply. I'm an engineer as well.
Your mistake in this is to assume the two options for design are "idiot light" and "information overload."
You are likewise mistaken to assume the use case is diagnostic in nature. Although I do feel it would be beneficial to expose this without a scan tool in some way, what I'm supporting here is just greater granularity. For instance, how should I know whether the car can be driven, or whether it should be towed? As it turns out, the CEL will blink if the car should be towed, and if it's solid, it's "okay" to drive. But that's based on a call with Subaru customer service this AM, not good user interface design. Maybe it's buried in the manual; I haven't checked yet.
Your final point is a common misunderstanding that I would say sets up another false dilemma. I understand what you mean -- I'm no stranger to the USPTO -- but when I've worked on large projects where reverse engineering is a concern, the assumption has always been that the competition will do a full teardown such that their documentation is just as good as ours as soon as we go to market. What you describe is really a trade secret, not patentable subject matter. So, if you have anything truly novel and worthy of protection, you file a patent application. But otherwise, you're no more entitled to the use of the idea than anybody else, and when they reverse engineer it, they're free to do the same as you've done as long as they've truly reverse engineered it as opposed to some more nefarious means.
tl;dr idiot lights are an improvement over no idiot lights, but it's time to make an improvement over idiot lights.
I've often wondered why the ECU or some other diagnostic computer doesn't aggregate ALL sensor data and look at the spectral signature as a means of monitoring machine health and suggesting preventative maintenance, but that's another subject...Seems like a great way to pile up reams and reams of data. To a large degree, automakers still don't know what the hell a given design might be doing over the course of its life. I think I once read about Ford going out and buying 10+ year old cars on used lots to do longterm use evaluations. I would guess others do similarly.