RE: Millenium Compliance

["Buchholz, Steven" <Steven.Buchholz@kla-tencor.com>]

Didn't everyone check the URL posted from the A4 page?  AoA stated in their
response that there is no part in the car that keeps track of the year
number in any form, be that 2 digit or four, until the TT, which by
definition is Y2K compliant ... :-).  They did respond to the only plausible
source of Y2K problems that comes to my mind, that being within diagnostic
equipment that they use to work on cars.  

Think about it, it doesn't make any sense to try to keep track of the year
in an automotive application; at least not in any way that could cause the
car to malfunction due to an improper year being computed based on a faulty
internal representation of the full 4 digit year.  Given sufficient passage
of time, even the small error in a crystal oscillator that creates the basis
of time in a car will add up to create an error of seconds, minutes ... even
hours or days if you wait long enough.  This means that if you want to keep
track of the calendar year, you need to provide some way to set it.  I have
not seen any setting mode that allows the year to be set.  Designing a
system that knows the year, but is not able to keep track of the passage of
time when the battery is removed would be inane.  

Today, it is possible to keep accurate time based on reference signals
broadcast by the NIST here in the USA ... and I'm sure that there are others
in other parts of the world.  I have not had a need to investigate if there
is any worldwide encoding standard in the broadcast so that the little Radio
Shack auto-setting clock I have (probably actually made by Oregon
Scientific) would be able to work if I took it to Madagascar for instance.  

Let's assume that the OBD-II standard ECUs had a faulty internal
representation of the year.  I believe that OBD-II was the first time that
cars were required to hold fault codes and such even after the engine is
shut off.  If indeed such cars did keep track of the year, this information
would likely be used to timestamp when a particular event occurred.  The
tool that reads out the timestamp can very easily understand the issue and
deal with it properly.  Let's say that it was as simple as just a 2 digit
representation of the year ... the tool would see a year reported and know
that the likelihood that the event occurred 100 years ago is pretty remote,
so that it probably 20xx rather than 19xx.  Even assuming that the car was
on the road 100 years after it was built the reader could presume that the
fault had not been stored in the ECU memory for 100 years and do the right
thing.  What would you expect to happen, that the ECU would determine that
the year is now 1900, and that 92 octane gasoline was not available and thus
to go into limp home mode?  Or perhaps the tranny computer would think that
somehow it had gone back in time to a date before it was created ... 

Some people think that there's some sort of X-files hidden function built
into every chip that will cause them all to self destruct (a la ... what was
that movie with Tom Selleck and errant automatons? ... Runaway?).  Let me
tell you as someone involved with the semiconductor business ... people have
a hard enough time getting the chips to do what they promised their
customers it would do to think about such subterfuge ...

Steve Buchholz
San Jose, CA (USA)

> ----------
> If the battery was not disconnected the date could accumulate.  (maybe
> only
> when It wa on, mayb all the time depending on the circuit)  If it only
> happened when it was on it could fail years from now.  at least that is
> how
> I understand it.
>