This week I had an article published relating to how my washing machine could
fail 31 Dec 1999. I have researched this for some time and would like to
thank those readers of this newsgroup who were able to help.
The article was published in New Zealand Computerworld and the on-line edition
can be accessed at URL:
http://www.idg.co.nz/wwwfeat/Y2000/ja250199.htm
It would be appreciated if those who have expert knowledge in the area of
embedded systems could offer intelligent debate on the issues I have raised.
Abuse enlightens no-one!
Jocelyn Amon
Financial Solutions Limited
http://www.ts.co.nz/~finsol/
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
That goes for my car too, since the only time it has the time on the
radio, and it doesn't care about the date. I doubt that the engine computer
uses GPS, since if it did you can bet the marketing people would have
hyped it.
Previously, Dague wrote in comp.arch.embedded:
> First off, the Y2K bug will probably surface to some extent in all industries,
> especially in the banking industry. But for people to go around promoting
> chaos is a bit overkill, and they're probably doing it to make money from those
> who don't quite understand.
>
> As far as the embedded industry, like a microwave or your washer, of course the
> corporate suits don't know if Y2K will affect their product. The software was
> probably done by not more than a few people, and those people have already
> moved on to bigger embedded projects.
>
> When you say that "embedded systems are often programmed by third-party
> companies" I would have to disagree. I will however say that embedded systems
> use third party real time operating systems that do not provide source code to
> the kernel.
>
> As for a washer's embedded system, it probably could be done by a few embedded
> software engineers, with a few electrical and several mechanical engineers.
> The software is what the Y2K bug is focusing on. For a washer, or any other
> consumer product, adding RAM and ROM can be expensive if you multiply that by
> each system. Therefore, the code is tight, and I don't think date code can
> hide in routines that monitor motor control and user button presses.
>
> Well, I won't go on, but I feel that you did stretch to get some of your
> conclusions.
>
> This should be an interesting thread.
>
> Jeff
>
It's kind of hard to believe that a home washing machine would have
any sort of RTC that keeps track of the current date. If it did,
how is the time and date set? I think your washer should work just great on 1/1/2000.
VCR's of course are one sort of appliance that does keep track of
dates. However none of mine have the correct date programmed
into them anway and they still seem to play movies just fine.
The only other device that I can think of around my house that
keeps track of dates is my FAX machine. However, like my VCR's, it doesn't
have the right date either. The programming procedures are
just too hard to remember.
I think I'm safe here because none of my household appliances seem to get past
1990 which is the default date set after I plug them in.
Speaking of computer time/date problems, you might find this new bug interesting. 40
to 50 *million* Windows PCs in North America are going to start telling the wrong time
on April 1, 2001 due to a software bug:
http://security.pharlap.com/y2k/apri1.htm
A PC World article on the problem can be found at:
http://www.pcworld.com/pcwtoday/article/0,1510,9327,00.html
Richard
>I figure since I don't need to reset the time and date in my washer,
>dryer, dishwasher, water softener, refrigerator, hot water heater,
>toaster, blender, food processor, mixer, electric knife, etc. after
>power outages that they are probably Y2K safe.
>
>Previously, Dague wrote in comp.arch.embedded:
>
>> This should be an interesting thread.
>>
Actually, this is mostly just a joke. I hope there aren't any
people out there who are stupid enough to fall for this.
Tom
> snip...
>
> This week I had an article published relating to how my washing machine could
> fail 31 Dec 1999. I have researched this for some time and would like to
> thank those readers of this newsgroup who were able to help.
>
> snip...
Could somebody please explain to me why a washing machine would give a tinkers
damn about what date it is?? What does the date have to do with washing
clothes, for god's sake!?
Am I missing something here, but surely Y2K is not an issue if the device in question holds, or makes use of, dates. e.g. my oven has a clock, but no day/date, my VCR has a 7 day timer but no date (as long as you tell it today is Wednesday, no problem) ... and so on.
Rgds Andrew
--
-----------------------------------------------------------------------------
God put me on earth to accomplish a certain number of things
Right now I am so far behind I will never die
-----------------------------------------------------------------------------
Andrew Holt email: andre...@uk.sun.com
Technical Consultant
-----------------------------------------------------------------------------
> Could somebody please explain to me why a washing machine would give a tinkers
> damn about what date it is?? What does the date have to do with washing
> clothes, for god's sake!?
Explaining why a washing machine could be affected by Y2K is exactly what I
have done in my article, see URL:
http://www.idg.co.nz/wwwfeat/Y2000/ja250199.htm
This reference was given at the start of this thread so I would have assumed
you would have read it before commenting!
What is it you are disputing? The only objection to my article so far, from
this newsgroup or elsewhere, has been that third-parties do not program the
logic for embedded systems on behalf of the manufacturer - can anyone confirm
that this assertion is correct? If it is true that third-party programmers
are not involved with embedded systems production, it does not eliminate the
chance of my washing machine failure - just lessens the odds a bit.
If you are going to dispute that a washing machine could fail Y2K compliance,
then stick to the arguments as I have presented them - don't just state what
you think should be so. I want to know what the experts know to be so. Each
of the facts I have presented is based on a lot of research which I can call
upon if disputed - what is your opinion based on? Wishful thinking?
>
Jocelyn Amon
Financial Solutions Limited
http://www.ts.co.nz/~finsol/
-----------== Posted via Deja News, The Discussion Network ==----------
> I find it hard to understand why a washing machine would need a calandar.
So that they can expire two weeks after the guarantee. =;-) Ditto tape decks,
toasters, etc etc.
And can't you now get washing machines with built-in tcp/ip, so that you can
know when the spin cycle is done without leaving the comfort of your PC?
*Mel!*
Project engineer and bum.
Why?
Scenario 1. Chaos breaks out. Banks fail, lights go out, cats sleep with
dogs etc.
They can claim they were correct and look like prophets.
Scenario 2. Nothing big happens, a bug here or there, but most can deal
with it.
Then can claim they that only there warnings drove companies to fix the
problems, and again, look like prophets.
Quite the racket!
Dague <da...@aol.com> wrote in message
news:19990126194832...@ng35.aol.com...
>This should be an interesting thread.
>
>Jeff
fin...@ts.co.nz wrote:
> I have noticed a recent interest on Y2K failure of embedded systems in this
> newsgroup.
>
> This week I had an article published relating to how my washing machine could
> fail 31 Dec 1999. I have researched this for some time and would like to
> thank those readers of this newsgroup who were able to help.
>
> The article was published in New Zealand Computerworld and the on-line edition
> can be accessed at URL:
>
> http://www.idg.co.nz/wwwfeat/Y2000/ja250199.htm
>
> It would be appreciated if those who have expert knowledge in the area of
> embedded systems could offer intelligent debate on the issues I have raised.
> Abuse enlightens no-one!
>
> Jocelyn Amon
> Financial Solutions Limited
> http://www.ts.co.nz/~finsol/
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Hey Jocelyn,
are you Peter DeJager's wife? I read the article and I sure
hope you did not receive payment for it. And it's kind of early for an April
Fool's joke.
You have a great imagination, why not write a sci-fi novel?
I will elaborate further on your article later as I am at work right now.
Mark D'Sylva
>Could somebody please explain to me why a washing machine would give a tinkers
>damn about what date it is?? What does the date have to do with washing
>clothes, for god's sake!?
To do a deep wash after the New Year's Day party? :-)
________________________________________________
Evandro Menezes Austin, TX ICQ:7957253
eva...@geocities.com come.to/evandro
> Speaking of computer time/date problems, you might find this new bug interesting. 40
> to 50 *million* Windows PCs in North America are going to start telling the wrong time
> on April 1, 2001 due to a software bug:
Since it only affects daylight savings time you may want to move to
Arizona.
KLK
>This week I had an article published relating to how my washing machine could
>fail 31 Dec 1999. I have researched this for some time and would like to
>thank those readers of this newsgroup who were able to help.
Most of the other threads have been gentle or humourous, but I feel obliged to
treat this neither with respect nor levity.
Simply put, it's one of the most shoddy pieces of work I've ever seen by someone
claiming to be a computer consultant. If they were a member of a professional
body, I would expect them to be reprimanded, and if a client paid fees they
should be refunded.
However, it's little different to any of the other pieces of supposedly informed
journalism floating about in the media, and there are probably quite a lot of
people making a quick buck. It's mainly scare-mongering speculation based on 5%
knowledge, and 95% ignorance. It is quite obvious you have no direct knowledge
of embedded systems.
Your thin conclusion "there is a very slight possibilty of failure or incorrect
operation" compared to the more dramatic headline, is not warranted by any
evidence, only your assumption that the washing machine "would definitely
require more functionality than a single microcontroller could provide".
Have you actually examined the machine internally to discover if they are even
any electronics in it, and not just an electro-mechanical device? You have not
established that there is even any software in it, which you later use to
justify possible problems with calendar handling.
I could go into detail of how time related issues were handled in embedded
systems I have worked on but I'm so disgusted I couldn't be bothered. I guess
we're going to get this sort of nonsense for the next 11 months.
--
Bob Cousins, Software Engineer.
http://www.lintilla.demon.co.uk/
"We demand that we may, or may not, be philosophers!"
Bob Cousins wrote:
> In comp.arch.embedded, fin...@ts.co.nz wrote:
>
> >This week I had an article published relating to how my washing machine could
> >fail 31 Dec 1999. I have researched this for some time and would like to
> >thank those readers of this newsgroup who were able to help.
I have never seen any posts by her previously, I wonder how she got any help.
>
> Most of the other threads have been gentle or humourous, but I feel obliged to
> treat this neither with respect nor levity.
>
> Simply put, it's one of the most shoddy pieces of work I've ever seen by someone
> claiming to be a computer consultant. If they were a member of a professional
> body, I would expect them to be reprimanded, and if a client paid fees they
> should be refunded.
>
Agreed
>
> However, it's little different to any of the other pieces of supposedly informed
> journalism floating about in the media, and there are probably quite a lot of
> people making a quick buck. It's mainly scare-mongering speculation based on 5%
> knowledge, and 95% ignorance. It is quite obvious you have no direct knowledge
> of embedded systems.
>
> Your thin conclusion "there is a very slight possibilty of failure or incorrect
> operation" compared to the more dramatic headline, is not warranted by any
> evidence, only your assumption that the washing machine "would definitely
> require more functionality than a single microcontroller could provide".
>
This one was interesting... if you do a simple internet search on her, you will
get quite a few hits, including the home page of her company (to which she
provided a URL) She indicates that she has vast software experience, but the
statement you refer to above was amazing. She has no idea what can be done with a
single 8 bit microcontroller.
>
> Have you actually examined the machine internally to discover if they are even
> any electronics in it, and not just an electro-mechanical device? You have not
> established that there is even any software in it, which you later use to
> justify possible problems with calendar handling.
>
> I could go into detail of how time related issues were handled in embedded
> systems I have worked on but I'm so disgusted I couldn't be bothered. I guess
> we're going to get this sort of nonsense for the next 11 months.
>
I was also going to write a detailed reply, but realised it would be a waste of
time.
My colleagues who read the article were laughing. Maybe the embedded firmware is
written by emus and kiwis where she comes from.
That article was another example of how gravy-sucking "consultants" charge lots of
money to write articles in fields that they have no knowledge.
Mark D'Sylva
>That article was another example of how gravy-sucking "consultants" charge lots of
>money to write articles in fields that they have no knowledge.
>
This sounds like another good storyline for the "Dilbert"
cartoon. Dogbert, the self proclaimed expert consultant,
goes around scaring people and then charges them to
step in and be reassuring to relieve their anxiety.
Mmmm.... pardon me, I have a web page to go build =-}
Tom
My experience is based on the fact that never in my life have I had to
set the date on a washing machine. I consider that very practical
experience.
How do you come to this conclusion. Where is your evidence that third-party
programmers are MORE likely to introduce Y2K problems into products than
programmers who work directly for a manufacturer? I have worked contracts
for a number of companies. My experience leads me to believe that the odds
of Y2K would not change based on whether or not the product developer was
directly employed or a third-party. Idiots are freely available and widely
distributed throughout the industry (as are prodigies).
>If you are going to dispute that a washing machine could fail Y2K
compliance,
>then stick to the arguments as I have presented them - don't just state
what
>you think should be so. I want to know what the experts know to be so.
Each
>of the facts I have presented is based on a lot of research which I can
call
>upon if disputed - what is your opinion based on? Wishful thinking?
In an effort to see what would happen in MY house, I tested EVERY APPLIANCE
I could think of in my home for Y2K compliance. This includes the waching
machine (kenmore), dryer (GE), microwave (panasonic), dish washer (kenmore
again), fridge (kenmore, too), TV (magnavox), VCR (JVC), DSS (Sony), DVD
(Sony), Stereo (JVC), Can Opener (???), Coffee Maker (Mr. Coffee), Radio
(WalkMan), Vacuum Cleaner (Hoover), Car (Nissan), Truck (Ford), Water Faucet
(Delta), Sprinkler System (???), and Windows 98 PC (Micron) (this was the
one I was most concerned with!!!).
My test included setting the date to the following:
December 31, 1999 11:59 PM
January 1, 2000 (any time)
February 27, 2000 11:59 PM
February 28, 2000 11:59 PM
February 29, 2000 11:59 PM
March 1, 2000 (any time)
October 31, 2000 11:59 PM (I'm superstitious)
December 24, 2000 11:59 PM (and optimistic)
December 31, 2000 11:59 PM
I changed every clock. I changed my watches. WOW, they were ALL adjustable
and they worked with NO Y2K problems. How COOL!!!. I had to buy a couple
of year 2000 calendars and X-out the days (just to be sure). I had to find
the VCR manual to set the clock on that (and found all kinds of cool stuff
in that little endeavor). It was very hard at first to figure out how to
"trick" my appliances into believing that it was really a new year. Then, I
figured it out. To start things off, I found a recording of Auld Lang Sygn
(I can't remember how to spell it) and played that. (My stereo kept going
and that's a good sign, right?) And, then I changed the date. And for the
next 5 hours or so it was 2000 in my house! I even had a friend call me up
to wish me "Happy New Year 2000". I figured that would test the phone (900
MHz Sony).
Anazingly enough...
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
EVERYTHING kept working. I was surprised. I did laundry during the test
just to make sure that crossing date boundaries worked. It did. Washed
that stack of dishes in the sink, too. Cool clean clothes, clean dishes,
and a Y2K test. (OK, so I have no life!)
The only problem in my test was that a super old shareware application for
my PC displayed the year as 00, but it still worked. It only prints the
date so MAYBE it's OK.
There may have been problems with my procedures. I may have missed a
clock/calendar in my appliances that was hidden (this is true). But, if you
can't correctly adjust the date (which is really an abstract concept
anyway), what does it matter? If the date is not important enough to be
correct, then who cares?
Cool.
Now, on to something more serious. There are real Y2K issues and limited
amount of resources that we have to get these problems corrected. People
are working overtime to be prepared for the 4-digit date and other problems.
However, there is so much crap and fear going around that people are
creating a hysteria about something which is a minor nuissance. I guess if
people decide there should be a problem, then the same people will figure
out a way to have a problem. Pity.
Jon Ward
Keil Software
P.S. And now for a shameless plug for Keil Software... When your 8051,
251, or 166 products start to fail or you think you may have a Y2K problem,
please contact us about purchasing our development tools. We can recommend
consultants and engineers in your area who are experts with our tools and
can assist you in updating your application software.
> Since it only affects daylight savings time you may want to move to
> Arizona.
>
Or Indiana..........
Richard
>Explaining why a washing machine could be affected by Y2K is exactly what I
>have done in my article, see URL:
>http://www.idg.co.nz/wwwfeat/Y2000/ja250199.htm
>
>This reference was given at the start of this thread so I would have assumed
>you would have read it before commenting!
OK, I just ran over and read it. It's a bunch of bunk. I don't know
if I hould laugh or cry over this one.
>
>What is it you are disputing?
Your knowledge of what is going on. Do you do any embedded
systems? Have you a clue how they work?
Tom
Chuck McCown wrote:
> I find it hard to understand why a washing machine would need a calandar.
So it could figure out when to go on vacation.....
> The premises and conclusions are (IMHO) contrived, but
> logically consistent. Just like the premise that you can move air by
> flapping your arms and the conclusion that if you could only flap hard
> enough you *will* be able to fly.
Exactly.
>
> Jim
>
>
>[...]
>> you think should be so. I want to know what the experts know to be so. Each
>> of the facts I have presented is based on a lot of research which I can call
>> upon if disputed - what is your opinion based on? Wishful thinking?
>
>My experience is based on the fact that never in my life have I had to
>set the date on a washing machine. I consider that very practical
>experience.
But the referenced article supposes that the calendar function
*is* included and that it may use a default starting date every time
the device is powered up. That way it isn't required that anyone
actually sets the date from some user interface, other than the on-off
switch, that is.
The premises and conclusions are (IMHO) contrived, but
logically consistent. Just like the premise that you can move air by
flapping your arms and the conclusion that if you could only flap hard
enough you *will* be able to fly.
Jim
> Have you actually examined the machine internally to discover if they are even
> any electronics in it, and not just an electro-mechanical device? You have not
> established that there is even any software in it, which you later use to
> justify possible problems with calendar handling.
Yes I have a washing machine similar to my own in pieces. I didn't know how
to identify a battery so I couldn't tell if there was one there or not - the
control panel contained a lot of componentry! It contains three chips - two
appear to control the power supply (I got this info from searching the
internet) & the other controls the functioning of the washing machine. The
manufacturer could give me NO information on this chip. The details for this
are: The chip has 40 pins, 20 on each side is marked: Intel Appian
J363040047 58009-004A 9137
The markings on the circuit board correspond with the pins as follows:
Pin Right Left
1 - C -
2 - A -
3 BO B-
4 - TO
5 - INT
6 -
7 - OSC
8 - -
9 - -
10 - C IN
11 - A IN
12 - B IN
13 - -
14 - 1 TRIP
15 - 1 LIM
16 TX OV
17 PUMP B+
18 BRK A+
19 HIST -
20 +5V C+
What can YOU tell from this information?
And why is no one disputing the 'facts' as I perceive them to be? Where's the
logical and reasoned argument? It appears that embedded systems engineers are
just as hysterical about the perceived hype of the Y2K issues as many of the
general population. Instead of getting emotional about this, their energy
would best be used in giving me and others the real facts - is that so hard?
If anyone can debunk my conclusions with a sensible argument, believe me, I
am only too willing to listen and will admit it where I am wrong. After all,
I wrote the article so that I and others could learn something about this
problem.
BTW, coincidentally this story from Fisher & Paykel came out the day after my
article was published, URL:
http://www.infotech.co.nz/current/nxfnp.html
Now, would this mean that the washing machine WOULD have a battery & perhaps
even a calendar???
> I was also going to write a detailed reply, but realised it would be a waste
of
> time.
Why? Is it so difficult to refute what I have written? I think your reasons
for not doing so are that you do not possess the knowledge to comment
sensibly so you are hiding behond the excuse of it being a waste of time. It
is not a waste of time my reading any information on this subject. If you
are concerned about it being a waste of your time then you obviously have
plenty to squander on the following abuse.
> Maybe the embedded
firmware is
> written by emus and kiwis where she comes from.
This sort of comment is usually descended to by those who have no reasonable
argument to offer.
> That article was another example of how gravy-sucking "consultants" charge
lots of
> money to write articles in fields that they have no knowledge.
> Mark D'Sylva
>
What a joke! Journalism pays very little. I'm doing Y2K awareness work
because I see a need to inform others of the Y2K problem and the nature of
that problem.
As you and others in computing know very well, computing pays a lot more than
most jobs and certainly more than journalism. Who's going to get rich
writing articles at .30c per word with a maximum of $250 for any single
article (and that's NZ dollars - half the US dollar). It has taken many
hours of research to write that one article and I attempted to keep it
concise. I also put a lot of effort into making it as readable as possible to
those who are not familiar with the subject matter - all this takes time for
which I do not get much in monetary compensation.
Replying to those such as yourself also takes time. I am hoping my reward will
be a useful response.
Well, go on, make my day and prove to others that you do know what you are
talking about. Try putting YOURSELF on the line and risking the criticsm of
your peers - or do you lack the courage? Its easy scoff - much harder to
take a stand and do something.
For anyone interested in the article I wrote that started this abuse, it is
available at URL:
http://www.idg.co.nz/wwwfeat/Y2000/ja250199.htm
OK, here are a couple of comments:-
In the article you say
"My washing machine would definitely require more functionality than
a single microcontroller could provide but it would not need to be as
complex as, for instance, a VCR."
On what are you basing the assertion that your washing machine requires
more than a single chip micro-controller? I can tell you confidently
that a single chipper would easily cope with the functions required to
run a washing machine.
Again, you say
"To save costs, the third-party programmer may use a "one size fits
all" base program to which the manufacturer’s requirements are added.
This base code may also be proprietary and commercially sensitive and
it may have a calendar function built in "just in case" it is
required."
Again, I would dispute this assumption. In a small, cost-sensitive
product for volume manufacture, one would certainly not use a
proprietary OS, unless there was a specific need for it, such as real-
time multi-tasking being necessary. A washing machine definitely does
not come within that definition, it is a simple timer/sequencer
function, which has for years been carried out by nothing more complex
than an electric motor driving a drum with cams and switch contacts.
The main thrust for going from mechanical programmer switches to
electronic controllers is be mechanisms full of gears and complex parts
are expensive to manufacture. From the washing machine manufacturer's
point of view, there is also the attraction that they can make their
product more marketable by having a "computer type" interface, instead
of a knob which the user winds round to the required start point.
None of this requires "hard real-time" control - the washing machine
will work just fine if the washer motor starts a few mS either way of
the set time.
Your assumption is that the developer will have swept up a whole load of
unnecessary functions into the code, just to save development time - I
think that you will find that this is not the case.
<Yawn>
"If a calendar function were present in the base code, a programmer
might decide to use it to time my washing machine’s wash and spin
cycles. If this were the case then it would increase the chances of a
Y2K bug causing a failure."
How would any programmer use a calendar for timing the spin cycle? Does
you machine need to spin for months? I think not. If the system *did*
have a calendar based RTC, then the timing function is going to be based
on an incremental count of seconds - i.e. I need to stop spinning at a
time (say) 120 seconds from NOW. It will then wait for that number of
seconds to elapse. This is not a calendar based calculation, and, if it
will work past midnight on any day, then it will happily work past
midnight on 31/12/99...
Another quote
"The majority of embedded systems hold the year as two digits only.
This is not a problem if the programmer has given consideration to the
year 2000 occurring and handled the year value correctly."
This is exactly the point isn't it - in fact the point that
'ma_cr...@juno.com' was making. You see, a register somewhere can
hold the year - as 1 digit, two digits or 26 digits - but until the
program actually does something _with_that_number_ it has absolutely no
effect on the system whatsoever. It is only then that *what* he does
with the number has significance.
Now - ask yourself - what use does your washing machine make of year
information? Since, by your admission in the article, there is no way
for the user to set a date, the year cannot be guaranteed to have any
particular value. The chances are that, in the very unlikely event that
your washing machine *has* a calendar function, it currently has the
wrong year. It works perfectly, does it not - or at least as well as it
is designed to! So why would any particular value of year digits have
any more disruptive effect than another?
As ma_crowder says, "why (would) a washing machine would give a tinkers
damn about what date it is??"
I think you can say that *any* system which does not have a way for the
date to be set will, by definition be Y2K compliant. This is simply
because if the date matters to the functioning of the system, then there
*must* be some way to set it correctly. Otherwise the date-dependent
functions cannot work properly.
Much of the remainder of the article, which deals with the mechanisms
for Y2K bugs manifesting themselves, I have no quarrels with, nor your
comments about systems which *do* have calendars being prone to failure.
--
Chris Wright
Colt International Licensing Ltd
Here's some dispute, based on the facts you presented....
>> I have established that there is a very slight possibility of my washing
machine failing or
>> functioning incorrectly on January 1, 2000.
which can reasonably be paraphrased as saying "To all intents and practical
purposes, my washing machine is year-2000 compliant". Based on the facts you
presented, here's a stab at estimating the size of your "very slight
possibility", using generously large probabilities.
Probability that embedded system contains a calendar function: 80% (for the
sake of argument)
Probability embedded system has battery backed up power source: 60%
Probability battery survives 10 -20 years supporting RTC: 50%
Probability internal date rollover causes noticeable fault: 50%
(Definition: it's not "noticeable" if the register rolls over to 00, or the
next byte the carry gets added into isn't used, or the fault does not
persist once power is interrupted and restored, such as an elapsed time
calculation).
All these things have to happen, so the overall probability is:
0.8 * 0.6 * 0.5 * 0.5 = 0.12 (12%)
but my estimates were grossly overestimated in their likelihood, so this is
saying the chance of Y2K failure is less than 12 %, not that it is 12% or
even that it's close. Reduce the probabilities slightly, and you get a new
estimate:
0.5 * 0.3 * 0.2 * 0.25 = 0.0075 (0.75%) which is probably more like it.
Maybe even less - there could be other events that are also required that
I've omitted to include.
And that leads me on to a point which I can't see on your page:
It's only a Y2K fault if it happens in relation to the date and can be
identified as a Y2K fault. If 1% of washing machines fail in this way, how
would you know that it was a Y2K fault? You'd probably first try switching
it off and back on (might work after that), and then you would probably
simply view it as failed or faulty, as happens anyway to a proportion of
washing machines. Which would give you a choice, buy a new washing machine
(after all, we've already established this one is likely to be several years
old), or have it repaired. Repair probably means replacing some of the
embedded components until it starts working again - it's unlikely to be as
sophisticated as investigating logic paths in the embedded software, and
bits of embedded systems fail due to power surges, E-M interference, even
physical stress, all the time.
So together with the above probabilities, multiply in a factor of 1 in 100
or 1 in 10,000 or less that you recognise it's a Y2K problem, and you should
realise that although from a purist, pedantic, hairsplitting perspective, it
could be said that a system with no apparent date functionality might
technically be capable of Y2K failure, to all practical pragmatic purposes
it can't.
Easy, it needs to be hung up in front of it, like an eye test. How else will
my W. Machine with all
mechanical timers know that its must fail on 01/01/00.
Brad
Yep, that's how things are designed, we have to work extra
hard to get those calender bugs in there =-}.
Have you ever had people accuse you of designing things
to fail? I get that every now and then at parties. When I
say that I'm a designer some people will say "You purposely
design things to fail once the are out of warretny, don't you?
Why do companies do that?". Then I have to explain that
it is not a plot to design things to fail, it just comes naturally.
=-} Some people get really suspicous.
Tom
>Explaining why a washing machine could be affected by Y2K is exactly what I
>have done in my article, see URL:
>http://www.idg.co.nz/wwwfeat/Y2000/ja250199.htm
I've just read the article. Although there are some insightful
observations about the Y2K issue, the washer example was extremely
unfortunate. Besides, the topics raised around embedded systems in
general are quite flawed, in general. For instance, concluding that
because something has timing functions it means it keeps the date is
ludicrous. Another, most embedded systems do not keep the date with
an RTC chip. Most just keep a count of seconds.
I may be wrong, but you look to me like someone who doesn't know what
you're talking about. Not about the Y2K, not about embedded systems.
You sound more like another chaos prophets just trying to make money.
Sorry for the flame, but you asked for it.
>Another quote
> "The majority of embedded systems hold the year as two digits only.
> This is not a problem if the programmer has given consideration to the
> year 2000 occurring and handled the year value correctly."
>
>This is exactly the point isn't it - in fact the point that
>'ma_cr...@juno.com' was making. You see, a register somewhere can
>hold the year - as 1 digit, two digits or 26 digits - but until the
>program actually does something _with_that_number_ it has absolutely no
>effect on the system whatsoever. It is only then that *what* he does
>with the number has significance.
Besides, who among the embedded system developers uses "digits" for
dates? 99.95% of the times, a binary number makes much more sense,
even when there is a "user interface"! Binary numbers take longer to
overflow... :-)
> On what are you basing the assertion that your washing machine requires
> more than a single chip micro-controller? I can tell you confidently
> that a single chipper would easily cope with the functions required to
> run a washing machine.
In fact my washer manages to get along just fine with no chips at all.
KLK
>
> Have you ever had people accuse you of designing things
> to fail? I get that every now and then at parties. When I
> say that I'm a designer some people will say "You purposely
> design things to fail once the are out of warretny, don't you?
> Why do companies do that?". Then I have to explain that
> it is not a plot to design things to fail, it just comes naturally.
> =-} Some people get really suspicous.
>
> Tom
I find it interesting that you comment on this.
I have been thinking about how embedded technology could be used by
people to easily and deterministically design in product failure in
order to provide a *gauranteed* stream of service work.
!!! DISCLAIMER !!!
!!! I DO NOT SUPPORT, ADVOCATE, OR PARTICIPATE IN THIS ACTIVITY AND
CONSIDER IT AN UNETHICAL PRACTICE !!!
Now then, let us continue.... :)
This could conceivably provide incentive for dealers to push a
particular brand of car so that they can reap the service fees.
Consider the case of an automobile engine controller. An engineer could
write the control code so that it degrades engine performace as a
function of time & mileage. When the customer brings his/her car to the
shop, the mechanic checks the on-board computer with his analyser and it
instructs him that it is time to change the plugs, oil, filter,
whatever. Upon completion of the 'tune-up', the mechanic resets the
analyser and gets a clean bill of health for the car.
What's important to emphasize here is that neither the customer nor the
*mechanic* is aware that the tune-up was unnecessary.
With todays low-cost, powerful, and secure microcontrollers (PIC, for
example), it would be virtually impossible to prove that this was being
done. With code-protection enabled, an outsider could not dissasemble
the control code for evidence and there is no other, easily acquired,
evidence that is as strong.
What is really significant here is the ease, certainty and impunity with
which this behaviour can be achieved.
I would be very much interested in your (and others) opinion(s) on the
matter.
Regards,
Daniel J. Quinz, P. Eng.
Micronetics CES
e-mail: da...@micronetics-ces.com
Now it works, and it cost me less than a buck in parts to fix.
Previously, Daniel Quinz wrote in comp.arch.embedded:
Jon Ward
Keil Software
Tom Maier wrote in message <36afb546...@news.mindspring.com>...
>"Brad" <ti...@iafrica.com> wrote:
>
>>
>>Chuck McCown wrote in message <36af3...@news.accessus.net>...
>>>
>>>I find it hard to understand why a washing machine would need a calandar.
>>>
>>
>>
>>Easy, it needs to be hung up in front of it, like an eye test. How else
will
>>my W. Machine with all
>>mechanical timers know that its must fail on 01/01/00.
>>
>
>Yep, that's how things are designed, we have to work extra
>hard to get those calender bugs in there =-}.
>
>>Explaining why a washing machine could be affected by Y2K is exactly what I
>>have done in my article, see URL:
>>http://www.idg.co.nz/wwwfeat/Y2000/ja250199.htm
>I've just read the article. Although there are some insightful
>observations about the Y2K issue, the washer example was extremely
>unfortunate.
Agreed.
VCRs, though, especially the fancier ones with VCR Plus, may
have problems. Also, some VCRs get time and date info from broadcast
signals, although I think this is based on data usually sent only
in Europe.
I'd expect the most trouble from copy-protection devices.
For example, is the time-limited variant of DVD disks Y2K compliant?
John Nagle
John Nagle
Er, um (fidget)...
This is a tough call. I would argue that it wasn't *designed*
to fail but, rather, was "poorly designed". There's a difference
between the two, I think.
I don't imagine many folks would argue about the fact that
some products/manufacturers are designed better than others.
The buyer *expects* fewer problems, etc. Whether that is
a result of better design margins (ample derating, etc.),
better quality control, etc.
If you buy a garbage can made out of flimsy plastic, it's
unrealistic to expect it to be serviceable 10 years down the
road. OTOH, buying an all metal can stands a good chance of
surviving that long (assuming you take care of each of them).
I suspect most folks are more concerned with purchase price:
"You, too, can have this fancy dancy gizmoccordian for
only $19 per month!"
than "cost to own".
My TV is 16 years old. I've spent $11 on it in all those years.
My oldest cassette deck is now close to 20 years -- and still
sounds better than my hearing!
The few times I've purchased "down" I've been disappointed
(a Sony cassette deck and a tuner neither of which survived
a month before internal plastic gears, etc. started breaking).
I think lifetime of most consumer electronic products now is measured
in the 12 - 18 mo range. And, anything less than $100 is simply
discarded instead of repaired. So...
> Now it works, and it cost me less than a buck in parts to fix.
Unfortunately, too few folks have the skills to do these
things nor the inclination/motivation...
:-(
--don
[snips throughout]
> I have been thinking about how embedded technology could be used by
> people to easily and deterministically design in product failure in
> order to provide a *gauranteed* stream of service work.
> This could conceivably provide incentive for dealers to push a
> particular brand of car so that they can reap the service fees.
> Consider the case of an automobile engine controller. An engineer could
> write the control code so that it degrades engine performace as a
> function of time & mileage. When the customer brings his/her car to the
> shop, the mechanic checks the on-board computer with his analyser and it
> instructs him that it is time to change the plugs, oil, filter,
> whatever. Upon completion of the 'tune-up', the mechanic resets the
> analyser and gets a clean bill of health for the car.
> What's important to emphasize here is that neither the customer nor the
> *mechanic* is aware that the tune-up was unnecessary.
> With todays low-cost, powerful, and secure microcontrollers (PIC, for
> example), it would be virtually impossible to prove that this was being
> done. With code-protection enabled, an outsider could not dissasemble
> the control code for evidence and there is no other, easily acquired,
> evidence that is as strong.
> What is really significant here is the ease, certainty and impunity with
> which this behaviour can be achieved.
I think there are lots of big assumptions you make here.
First, I dispute the "ease, certainty and impunity" claim you make.
We're always hearing about whistle-blowers in various industries.
How do you *guarantee* that the folks who *know* about this
never "squeal" to the press, governmental agencies, etc.?
Or, that they don't eventually end up working for some *other*
car manufacturer, mention this at some point in their employment
and find the other car manufacturer deciding that this would be
a great way to damage their competitor in the eyes of the
**BUYING** public? After all, the offending car manufacturer
would be hard pressed to gather up all evidence of his
misdeeds -- since millions of them would be scattered around
the planet!
You also assume that these "secure" processors *ARE* secure.
For enough money, any of them can be probed. Usually, this
amount is high enough (and the controllers small enough) that
it's economically more realistic to just duplicate the
functionality of the "black box" from empirical observation
rather than trying to "copy" it. In a case like this, the
stakes might be high enough that folks opt to invest $$$
to gain some competitive advantage.
This wouldn't be atypical of the aftermarket auto industry.
Also, statistics would side against the manufacturer -- since
folks could start comparing notes about performance, cost-to-own,
etc. I'm sure (?) Ford didn't intentionally *design* Pinto's
to drop their gas tanks when rear-ended. But, *someone*
started noticing this "tendency" (can you spell "statistics"?)
and, hence, it *became* an issue in the public eye...
Someone could always take the ECU out of the vehicle and
provide *ideal* inputs to it and notice that it doesn't
agree with the expected behaviour of a "brand new" unit
(i.e. isolate all other variables from the analysis).
So, the ECU is at fault! "Gee, we've been seeing a lot
of 'defective' ECU's. I wonder if there isn't something
inherently defective in the *design* of that device?"
(just like falling gas tanks!)
I vaguely recall some ECU (CAdillac?) that *logged*
every time the operator drove it over 88MPH (?). I
don't recall this fact being "warmly received" by those owners!
I suspect that the inevitable news/suspicion that an
ECU was *designed* to fail in the manner suggested would
be the "kiss of death" for that manufacturer.
--don
Or replacment orders...
: !!! DISCLAIMER !!!
: !!! I DO NOT SUPPORT, ADVOCATE, OR PARTICIPATE IN THIS ACTIVITY AND
: CONSIDER IT AN UNETHICAL PRACTICE !!!
Agreed.
: Consider the case of an automobile engine controller. An engineer could
: write the control code so that it degrades engine performace as a
: function of time & mileage. When the customer brings his/her car to the
: shop, the mechanic checks the on-board computer with his analyser and it
: instructs him that it is time to change the plugs, oil, filter,
: whatever. Upon completion of the 'tune-up', the mechanic resets the
: analyser and gets a clean bill of health for the car.
: What's important to emphasize here is that neither the customer nor the
: *mechanic* is aware that the tune-up was unnecessary.
It would be difficult to fool a competent mechanic. For starters,
unless you design in "smart" oil-filters (probable) and spark-plugs
(less likely), the ECU would have to be _told_ that the work had been
done. It would not take a rocket-scientist to wonder why that particular
button had to be pushed to have the physical replacment "recognized". Now,
not _every_ mechanic is a rocket-scientist, but it only takes
one suspicious sort and the lure of big-bucks from some tabloid
to blow the lid off this sort of thing. OTOH:
: With todays low-cost, powerful, and secure microcontrollers (PIC, for
: example), it would be virtually impossible to prove that this was being
: done. With code-protection enabled, an outsider could not dissasemble
: the control code for evidence and there is no other, easily acquired,
: evidence that is as strong.
: What is really significant here is the ease, certainty and impunity with
: which this behaviour can be achieved.
There is abundant evidence of "ethically challenged" firms.
We need only await the technology. Note the recent news about jiggered
gas-pumps, which dispensed the amounts used by "weights and measures"
inspectors correctly, but gouged typical customers. For those who
didn't see this, the scam was to run the "billing indicator" faster
than the real flow, until approaching either the five or ten gallon
quantity that the inspectors always used. An average customer who
bought anything _but_ exactly five or ten gallons was overcharged.
Of course, both Netscape and M$ do something similar, where
their browswers and web-authoring software collude to both "break"
the competitor's product and force customers to "upgrade" endlessly.
: I would be very much interested in your (and others) opinion(s) on the
: matter.
It sucks, and it's an inevitable by-product of the current
(over the last 200 years at least) elevation of commerce and profit
as _the_ only worthy goals. It's not going away soon. One can only
hope to appropriately "tune" one's level of paranoia.
BTW: I bet the manufacturer could even get an "expert
witness" to testify plausibly enough for a jury that the
jiggered ECU was performing a valuable service by enforcing
the recommended service interval.
Mike
| alb...@agames.com, speaking only for myself
The resistor was part of the display circuit, which is what failed. The
manufacturer of the display calls for a 1/2 watt resistor (I used a
one-watt part) in app-notes for similar displays. So, the selection
of a 1/4 watt resistor was either a freak accident or intentional.
Because of other poor service from products I've bought from Sears, and
because of the exhorbitant cost of their replacement parts, I choose to
believe that Sears views failures as a desirable and service as a large
profit center. It is for this reason that I believe the defect was
intentional. YMMV.
>First, I dispute the "ease, certainty and impunity" claim you make.
>We're always hearing about whistle-blowers in various industries.
>How do you *guarantee* that the folks who *know* about this
>never "squeal" to the press, governmental agencies, etc.?
That's my opinion too. I've never had an employer or
customer even hint at such a thing as a purposefully
induced failure and I think if somebody did do that the word
would get out and cause long term damage to the company's
image and sales.
There's really good incentive to keep those products
error free and durable. The company name is at stake.
An old product that "takes a lickin' and keeps on tickin'"
is good advertising for future sales.
Sometimes I've had employers or customers who told
me that deadline was more important than reliablity
and testing, so that is strictly their call on the business
side of this. They are willing to take the rap for
product failures to be the first on the market with some
product. It's a marketing decision, not a devious plot.
As a side note, my wife has a Susuki and exactly at 50K
miles a red lite on the dashboard came on and
warned something about the car needing service.
She took it in to a non-authorized repair place and they told
her that it was a reminder to have the car checked
and that the light could only be turned off by an
Suszuki authorized repair center. The light is still
on.
Tom
>Chris Wright wrote:
>
>> On what are you basing the assertion that your washing machine requires
>> more than a single chip micro-controller? I can tell you confidently
>> that a single chipper would easily cope with the functions required to
>> run a washing machine.
>
>In fact my washer manages to get along just fine with no chips at all.
>
>KLK
My washer has had chips in it from time to time. Sometimes
I come home from work with an eprom or a micro in my shirt
pocket and it shows up either in the washer or dryer.
On one of my first jobs out of college I had to fly up to
PA to install some software I wrote into a machine up
there. I stopped by to see my mother and she insisted
on washing my clothes (mothers, you know...). I had
the eproms in my shirt pocket (in a platic case). They
went through the washer and ended up in the dryer.
She held out tow mangled eproms and said "what's this?".
The pins where all higgledy-piggledy. I was afraid to
fly back to Altanta and admit this error to my boss, so I
straightedn out the pins and went to PA and installed
them.
They worked just fine.
Now wasn't that a more interesting story than this Y2K
in the washer stuff?
Tom
> The resistor was part of the display circuit, which is what failed. The
> manufacturer of the display calls for a 1/2 watt resistor (I used a
> one-watt part) in app-notes for similar displays. So, the selection
> of a 1/4 watt resistor was either a freak accident or intentional.
Don't believe app notes, either! :> Many are written
by folks who haven't ever *designed* real systems, etc.
> Because of other poor service from products I've bought from Sears, and
> because of the exhorbitant cost of their replacement parts, I choose to
> believe that Sears views failures as a desirable and service as a large
> profit center. It is for this reason that I believe the defect was
> intentional. YMMV.
I never buy Sears products -- does that give you some idea
of my attitude towards them? :>
--don
Looks like its either an Intel 8032 or a 8047, OTP.
>
>And why is no one disputing the 'facts' as I perceive them to be?
Most of it is too silly to deal with. If you worked in the field
you would realize this.
> Where's the
>logical and reasoned argument?
You've already recieved "seasoned" arguments. I have almost
20 years in designing this stuff and I already told you that it is
seldom that any embedded processor system even needs a
calender. Other people have told you this also. You are very
stubborn in sticking with your uneducated specualtion of this
y2k problem. If the people who do this for a living aren't
worried, then why are you pressing panic buttons?
>It appears that embedded systems engineers are
>just as hysterical about the perceived hype of the Y2K issues as many of the
>general population. Instead of getting emotional about this, their energy
>would best be used in giving me and others the real facts - is that so hard?
No, the facts are easy. Getting you to read them is hard.
>
>If anyone can debunk my conclusions with a sensible argument, believe me, I
>am only too willing to listen and will admit it where I am wrong. After all,
>I wrote the article so that I and others could learn something about this
>problem.
This is a different attitude than you express in your article. In the
article you "explain" things that are total fabrications, like having
the calender code embedded into applications that aren't even
using them.
I said it once and I'll say it again, it is bunk.
>
>BTW, coincidentally this story from Fisher & Paykel came out the day after my
>article was published, URL:
>http://www.infotech.co.nz/current/nxfnp.html
>
I'm still in stitches from the last article. Why don't you
quote parts of it for us?
>Now, would this mean that the washing machine WOULD have a battery & perhaps
>even a calendar???
What for?
>> I was also going to write a detailed reply, but realised it would be a waste
> of
>> time.
> Why? Is it so difficult to refute what I have written? I think your reasons
> for not doing so are that you do not possess the knowledge to comment
> sensibly so you are hiding behond the excuse of it being a waste of time. It
Wow. What an obvious troll! :>
> is not a waste of time my reading any information on this subject. If you
> are concerned about it being a waste of your time then you obviously have
> plenty to squander on the following abuse.
While this may seem new and fascinating to you, it's old news to the
rest of us. We've had this discussion a few *dozen* times in the past.
We also are *directly* involved in the design, manufacture, repair and
support of these products. I doubt you'll find folks elsewhere
who can actually say that *they* designed product XYZ.
[snip]
> What a joke! Journalism pays very little. I'm doing Y2K awareness work
> because I see a need to inform others of the Y2K problem and the nature of
> that problem.
As I have said, we've all "been there, done that, got the T-shirt
to prove it...". We're just tired of all the doom and gloom
forecasts that are (to those of us looking at the problem from the
*inside* out) just lots of "hype".
It's reminiscent of Reader's Digest shorts on things like
"Marijuana: The Killer Weed", etc. Except in places like
Scientific American, etc. folks are looking for sensationalism.
A studied article that concludes "there will be no problem"
would go over like a lead balloon (note that I am not
making any statements here as to the scope of the "problem";
that's been beaten to death numerous times before). By
contrast, an article (or a news documentary like one that
aired here last week) admonishing folks to stockpile food,
ammunition, whole blood and Cracker Jacks will get a more
receptive review...
(note that I am not claiming you to be in this same category.
I've not read your article nor do I care to. I am not
attempting to address the substance of your claims nor of any
other rebuttals of them -- rather, I'm trying to explain why you
will see this sort of reaction here...)
> Well, go on, make my day and prove to others that you do know what you are
> talking about. Try putting YOURSELF on the line and risking the criticsm of
> your peers - or do you lack the courage? Its easy scoff - much harder to
> take a stand and do something.
That's on a par with some of the comments (elided in this reply)
that *you* took offense with in their criticism of your article.
If you read the technical newsgroups every day (for many *years*!)
you'll see that people "risk the criticism of their peers" on
an almost daily basis. Further, that criticsim is very *public*
in these forums. Typically, a print article is a one-way
discourse. Here, every comment invites criticism, clarification,
etc.
I doubt the folks here could be accused of lacking "courage" -- though
many of us might be accused of lacking common sense! :>
--don
fin...@ts.co.nz wrote:
> In article <36AF9975...@scican.com>,
> Mark D'Sylva <mds...@scican.com> wrote:
>
> > I was also going to write a detailed reply, but realised it would be a waste
> of
> > time.
>
> Why? Is it so difficult to refute what I have written? I think your reasons
> for not doing so are that you do not possess the knowledge to comment
> sensibly so you are hiding behond the excuse of it being a waste of time. It
> is not a waste of time my reading any information on this subject. If you
> are concerned about it being a waste of your time then you obviously have
> plenty to squander on the following abuse.
>
> > Maybe the embedded
> firmware is
> > written by emus and kiwis where she comes from.
>
Well sorry about that one, I just can't imagine how many competent embedded
developers would create the type of code you have written about.
>
> This sort of comment is usually descended to by those who have no reasonable
> argument to offer.
I do have reasonable arguments which I could offer, but a proper reply would take
more time than I have during the day. As I am presently quite busy after work,
I am not able to work on a reply for a few days. I will try to replay on the
weekend, but I have seen some of the points I would highlight already mentioned
in other replies.
>
> > That article was another example of how gravy-sucking "consultants" charge
> lots of
> > money to write articles in fields that they have no knowledge.
> > Mark D'Sylva
> >
>
> What a joke! Journalism pays very little. I'm doing Y2K awareness work
> because I see a need to inform others of the Y2K problem and the nature of
> that problem.
>
Well than I am sorry, it really seems (after looking at your web site) that you
are performing consulting work in the area of Y2K. I should not have concluded
that.
>
> As you and others in computing know very well, computing pays a lot more than
> most jobs and certainly more than journalism. Who's going to get rich
> writing articles at .30c per word with a maximum of $250 for any single
> article (and that's NZ dollars - half the US dollar). It has taken many
> hours of research to write that one article and I attempted to keep it
> concise. I also put a lot of effort into making it as readable as possible to
> those who are not familiar with the subject matter - all this takes time for
> which I do not get much in monetary compensation.
>
> Replying to those such as yourself also takes time. I am hoping my reward will
> be a useful response.
>
> Well, go on, make my day and prove to others that you do know what you are
> talking about. Try putting YOURSELF on the line and risking the criticsm of
> your peers - or do you lack the courage? Its easy scoff - much harder to
> take a stand and do something.
>
I hope to respond on the weekend. As I said, others have mentioned some of the
points I disaggree with already.
>
> For anyone interested in the article I wrote that started this abuse, it is
> available at URL:
> http://www.idg.co.nz/wwwfeat/Y2000/ja250199.htm
>
In the US, public television stations broadcast time information; my VCR
sets the time from this automatically.
[snip]
> There's really good incentive to keep those products
> error free and durable. The company name is at stake.
> An old product that "takes a lickin' and keeps on tickin'"
> is good advertising for future sales.
Unfortunately, I think this is becoming less true.
It seems like folks tend to buy based solely on price, nowadays.
This is unfortunate:
for them, because they'll probably pay more in the long run
once "cost to own" is factored in
for me, because it encourages the few *good* manufacturers
to abandon their practices in favor of the quick buck...
> As a side note, my wife has a Susuki and exactly at 50K
> miles a red lite on the dashboard came on and
> warned something about the car needing service.
> She took it in to a non-authorized repair place and they told
> her that it was a reminder to have the car checked
> and that the light could only be turned off by an
> Suszuki authorized repair center. The light is still
> on.
I believe this is a common "feature" of most ECU's. If you
have the shop manual, you can probably find the wire that
needs to be grounded (momentarily) to clear the "code"...
This, IMHO, borders on the boundary of ethical/unethical.
Yes, arguably it is there as a reminder of the *scheduled*
need for service. Thanks for reminding me, etc. But, I
think it is done knowing/expecting some large percentage
of owners to bring their cars in for service out of fear, etc.
Of course, it's unrealistic to legend the lamp:
"Hi! It's time for your scheduled XX,000 mile service
checkup. This pleasant reminder is here to remind you
that your dealer desperately needs your continued
business to meet his payroll. Chances are, he'll
find nothing wrong but will just take the opportunity
to sell you an overpriced oil change, chassis lube,
some new windshield wiper blades and, if he feels
like he can get away with it, a new set of hoses,
belts and filters! Of course, these things *probably*
should be replaced anyway. After all, your family's
life depends on the reliability of this vehicle!!
And, we all know that *you* surely won't take the
time and effort to perform all those preventative
maintenance activities *yourself*! C'mon... be
realistic! There's a football game on this weekend.
You *know* you'd rather spend the weekend exercising
your ass on the seat of that overstuffed chair!
For your convenience, the name and address of your
dealer are displayed on the cover of the owner's
manual in the glove box -- yes, that small dusty
book that you've never opened. Go on, give him
a call and set up an appointment *today*! You
can even use your car phone so you won't forget to
call *later* -- hit "**#*25" and I'll magically dial
his number for you! By the way, should you decide
to ignore this gentle prompt, simply turn the ignition key
off for 15 seconds and the indicator will be cleared..."
Or, is that too much to hope for? :>
--don
>We also are *directly* involved in the design, manufacture, repair and
>support of these products. I doubt you'll find folks elsewhere
>who can actually say that *they* designed product XYZ.
She isn't influenced by knowledge and experience.
>contrast, an article (or a news documentary like one that
>aired here last week) admonishing folks to stockpile food,
>ammunition, whole blood and Cracker Jacks will get a more
>receptive review...
This reminds me of a little poem. I'll call it the "Y2K Chant" :
"When in danger
or in doubt,
run in circles
scream and shout."
That pretty well sums it up, doesn't it? I don't recall
if that is from the book "Catch-22" or from "Muntiny on
the Bounty". Anybody remember?
Tom
[..EPROMS went through the washer and dryer...]
>
>They worked just fine.
Wow. I'm not too surprised they survived the washer, but I would
expect some ESD damage from the dryer...
>
>Now wasn't that a more interesting story than this Y2K
>in the washer stuff?
>
Indeed.
Regards,
-=Dave
Just my (10-010) cents
I can barely speak for myself, so I certainly can't speak for B-Tree.
Change is inevitable. Progress is not.
>In article <36AF9975...@scican.com>,
> Mark D'Sylva <mds...@scican.com> wrote:
>
>> I was also going to write a detailed reply, but realised it would be a waste
>of
>> time.
>
>Why? Is it so difficult to refute what I have written?
Two reasons:
1) Not knowing the facts has not stopped you writing a whole load of nonsense,
so what's the point of telling you after the event?
2) It would entail me passing on a significant proportion of 10 years knowledge
of working on embedded, real-time and application programs. Given the large gap
in your knowledge, it would take more time than I have to fill it in.
I estimate the chances of a washing machine failing due to a Y2K problem, or
indeed any time or date related problem, as a lot less than it being hit by a
plane. Why don't we see any articles about the risk of plane crashes on washing
machines?
The important thing about Y2K is perspective, both of the impact of the problem
and the likelihood of it occurring, and your article illustrates neither.
Simply put, washing machines don't have dates, and will not have a calendar
problem. They don't need them and the manufacturer is not going to waste money
on them.
Every product I have worked on, the first thing you consider when using a timer
is what is the range of the timer, and what will happen when it overflows.
Designers of embedded or real-time code are acutely aware of timing issues, and
are unlikely to get it wrong.
I've encountered hundreds, if not thousands of bugs, and I can only think of one
that was date related.
>I think your reasons
>for not doing so are that you do not possess the knowledge to comment
>sensibly so you are hiding behond the excuse of it being a waste of time.
Ok, so what's your excuse for writing a load of rubbish? If you want to check my
resume, it's on my website. I guess you've got your 12 minutes of fame though.
>is not a waste of time my reading any information on this subject. If you
>are concerned about it being a waste of your time then you obviously have
>plenty to squander on the following abuse.
Why should I spend my time doing *your* research? Don't worry, writing abuse is
much quicker than countering mistaken nonsense ;-)
Please tell me a non-abusive way to say "you do not know what you are talking
about". It might have been an idea to consult some experts *before* publishing
your article.
--
Bob Cousins, Software Engineer.
http://www.lintilla.demon.co.uk/
"We demand that we may, or may not, be philosophers!"
>Because of other poor service from products I've bought from Sears, and
>because of the exhorbitant cost of their replacement parts, I choose to
>believe that Sears views failures as a desirable and service as a large
>profit center. It is for this reason that I believe the defect was
>intentional. YMMV.
I think you're being to skeptical here. I can't really say
yeah or nay about sears quality, but most of the "bugs"
of the type that you describe come from several other,
more reasonable, explainations.
Here are some reasons for high failure rates:
1. The company that designed the whatever had
little experience in that technology.
2. the company is pushing the engineers to design new
things and not paying attention to old bugs. (too busy
stroking forward to look back).
3. The company has no feedback from field service
back to engineering to alert the engineers to change the
design flaws. The same Product continues to be manufacutered for
many years with the same flaws.
4. You got an early model that wasn't totally debugged.
5. The company is new to the technology and they
hired wrong. They ended up with a design team with
bad credentials because the company didn't know how to
pick good from bad, rookie from experienced.
6. Your home AC supply is running too high and the
products you are buying are feeling the pain. I usually
design so that worst case AC overvoltage (sustained)
is at +20%. Some people design closer to nominal.
7. the product is in an environment in your home that
is not "nominal". A resistor that is in an ambient heat
of 120F doesn't have the same wattage handling capability
as a resistor in a "room temperature" environment (70F).
It's stuff like the above that are the cause of most
failures in the field that I have seen. Notice that
these errors are just to to sloppiness, not malice.
Notice that companies that are run by engineers don't
have these problems as much; like Hewlett-Packard.
Tom
>Don't believe app notes, either! :> Many are written
>by folks who haven't ever *designed* real systems, etc.
>
That's not always true! Bob Pease of National Semi.
loves to write ap. notes and he's one of the best
designers. He loves to tinker.
Tom
> Why don't we see any articles about the risk of plane crashes on washing
>machines?
I'm working on just that subject. To make the article longer and
even more interesting, I plan to also include statistical studies
showing the probability of water heaters being struck by
space debris. I've contacted an editor at New Yorker mag. and,
after looking over the rough draft, they are eager to publish it.
> I guess you've got your 12 minutes of fame though.
It was Andy Warhole who said 15 minutes of fame, right? That
means she gets another 3 minutes due her.
> It might have been an idea to consult some experts *before* publishing
>your article.
That would delay the "product".
Tom
>Yes I have a washing machine similar to my own in pieces. I didn't know how
>to identify a battery so I couldn't tell if there was one there or not - the
You don't know how to identify a battery. *sigh* What exactly are your
qualifications ?
>are: The chip has 40 pins, 20 on each side is marked: Intel Appian
>J363040047 58009-004A 9137
It's likely to be a custom ASIC or FPGA.
>What can YOU tell from this information?
I can tell there is no evidence of battery backed memory, a microcontroller, any
software, a calendar or a Y2K problem.
>And why is no one disputing the 'facts' as I perceive them to be?
Every one is disputing the facts as you perceive them.
>Where's the
>logical and reasoned argument?
Logic and reason can't add any more information than is there already: If you
have no evidence of something then no amount of reasoned argument will get you
anywhere.
> It appears that embedded systems engineers are
>just as hysterical about the perceived hype of the Y2K issues as many of the
>general population. Instead of getting emotional about this, their energy
>would best be used in giving me and others the real facts - is that so hard?
If there is one thing guaranteed to get the goat of any professional, it's
someone else purporting to be one when they clearly aren't.
The real fact is that there is no problem.
>If anyone can debunk my conclusions with a sensible argument, believe me, I
>am only too willing to listen and will admit it where I am wrong. After all,
>I wrote the article so that I and others could learn something about this
>problem.
It is not possible for anyone to prove that something doesn't exist. It is up to
you to prove that there is a problem. If you can verify that chip XYZ is a
microcontroller, and also examine the software it contains and find that it
maintains a calendar, *then* I will accept that there *may* be a problem.
Otherwise all you are saying is that a piece of equipment might conceivably have
a fault. That is not news.
>BTW, coincidentally this story from Fisher & Paykel came out the day after my
>article was published, URL:
>http://www.infotech.co.nz/current/nxfnp.html
Hmm, interested choice of word "story". It's a "story" by a journalist, though
probably rewritten from a press release, which is what journalists mostly do.
However rather than go by second-hand information, perhaps you could consult
what Fisher and Paykel had to say first-hand
http://www.fp.co.nz/nz/Whiteware/millenium.html.
Of course, they could be mistaken, or lying, but I would need to see some good
evidence of that. They are hardly likely to make a marketing feature of Smart
devices and then do something stupid with Y2K. I expect their engineers and
management have been over everything with a fine tooth comb, if they needed to.
I hope for your sake no lawyers at F&P take an objection to your article. You
didn't even quote what they say or make a link to their site. Normal
journalistic practice is to give a chance for the manufacturer you are accusing
of having a problem some airtime to state their case.
>Now, would this mean that the washing machine WOULD have a battery & perhaps
>even a calendar???
The article talks about plans, which are by implication future developments, and
mentions things "such as". Even if the washing machine stores data (probably in
EEPROM anyway), there is still absolutely no indication of a date being
involved, or that if it was it would affect the operation.
You are really clutching at straws with this one. I have to ask myself, if you
can get this one so wrong, why should I take seriously anything else you have to
say about Y2K?
>Tom Maier <sminst...@mindspring.com> uttered in <36b0b39d...@news.mindspring.com>:
>
>[snip]
>
>> There's really good incentive to keep those products
>> error free and durable. The company name is at stake.
>> An old product that "takes a lickin' and keeps on tickin'"
>> is good advertising for future sales.
>
>Unfortunately, I think this is becoming less true.
>It seems like folks tend to buy based solely on price, nowadays.
I'm of the opinion that competition for increased reliability
is increasing. (warning, old fart story coming!) When I was
a kid in the early sixties companies weren't required by
law to take returns and many companies operated in a
rather fly-by-night fashion of producing junk and then
changing their names to make more. Today there are
consumer protection laws and a major issue in the
comapnies is "if we produce an utter failure, will it
drive us inot bankrupcy to take all the product back
off the market?". This makes an immediate financial
incentive to make a product that at least mets the
legal warrenty period.
In reality, it is hard to say which of our opinions is
true because where would the records be to prove it?
This is just my opinion, for what it is worth.
> to abandon their practices in favor of the quick buck...
That attitude has always been around. There used to
be no laws whatsoever to halt it, though.
>
>> As a side note, my wife has a Susuki and exactly at 50K
>> miles a red lite on the dashboard came on and
>> warned something about the car needing service.
>This, IMHO, borders on the boundary of ethical/unethical.
I'll tell you that it is extremely annoying to have that light
on when driving at night. The light is big and bright and
shining in the drivers face. We've proped up a card in front
of it to tone it down a bit, but you can almost read by
it, it is so bright.
>Yes, arguably it is there as a reminder of the *scheduled*
>need for service. Thanks for reminding me, etc. But, I
>think it is done knowing/expecting some large percentage
>of owners to bring their cars in for service out of fear, etc.
>
>Of course, it's unrealistic to legend the lamp:
> "Hi! It's time for your scheduled XX,000 mile service
> checkup.
You are coming close to a "secret" idea that I had
many years ago. I call it the "Mother Chip". It's a
processor that you install under the dashboard with a
voice synth. that nags at you "Why aren't you wearing
your seatbelts? When was the last time you washed that
shirt? Your driving like a maniac, slow down! etc., etc.,"
Now that I've given this idea out, my patent application
will be no good! Rats!
Tom
As a computer professional with 30 years of experience, of which the
last 12 were directly involved with embedded controllers, I have to
agree with Bob and Mark. Your article was opportunistic silliness.
As to why they don't take the time to give you a detailed reply, good
embedded designers are paid well, unlike journalism, and their time is
valuable. I'm sure that someone here would be glad to consult for you
on Y2K issues, for about $100 an hour.
Now if you want to write an article on a clearly wrong and bad case of
embedded programming, follow the threads here on the Therac-25.....
Jim
However, since the Sears service guy said that all the timer boards
fail like this after 3-5 years I would say that Sears has, for
whatever reason, not taken proactive steps to fix the problem.
Failing to fix a known problem, especially one that is easy to fix,
is the same as designing in failure in my opinion.
[...]
Meindert
If you cannot identify a battery your actual knowledge of the subject
is woefully inadequate.
<SNIP of incomplete and ambiguous information>
>
> What can YOU tell from this information?
As the information is incomplete and ambiguous any information
posted, unless from the machine manufacturer, would be speculation.
Which is exactly what you original article is. A mind game.
>
> And why is no one disputing the 'facts' as I perceive them to be?
Please reread your sentence. It answers your question. You present no
facts. You present things as they may be, or as they might be, or
as they could possibly be. That is not fact. It is pure speculation.
> Where's the
> logical and reasoned argument?
My question exactly. Where is yours? You stated a hypothetical
planet fluffy bunny view of embedded systems and expect to
recieve calm reasoned discourse? You have no facts. Only mind games.
> It appears that embedded systems engineers are
> just as hysterical about the perceived hype of the Y2K issues as many of the
> general population. Instead of getting emotional about this, their energy
> would best be used in giving me and others the real facts - is that so hard?
They did. You do not accept them. That is not their problem.
>
> If anyone can debunk my conclusions with a sensible argument, believe me, I
> am only too willing to listen and will admit it where I am wrong.
Wrong. You have already demonstrated that you will shrilly defend to
the death your mind game as some sort of ultimate truth. Do you
watch a lot of X-Files reruns?
> After all,
> I wrote the article so that I and others could learn something about this
> problem.
>
> BTW, coincidentally this story from Fisher & Paykel came out the day after my
> article was published, URL:
> http://www.infotech.co.nz/current/nxfnp.html
So? It says nothing about what appliances it would interact with.
Instead, like your own piece, it alluded to possible interactions with
'whiteware' to be named later. No facts there about Y2K.
>
> Now, would this mean that the washing machine WOULD have a battery & perhaps
> even a calendar???
In what way would that article even begin to give you any
such idea?
You have done both the writing and computer professions a disservice.
Bill
--
************************************************
* *
* All opinions herein expressed are mine and *
* mine alone. You may choose to ignore them *
* but I own them. Heck, my kids don't listen *
* to me, why should you? *
* *
* Email: wmilam'at'ford'dot'com *
************************************************
And many companies reward their employees with stock and retirement
benfits that give them an incentive to insure that the products do
indeed work properly.
<SNIP>
>
> As a side note, my wife has a Susuki and exactly at 50K
> miles a red lite on the dashboard came on and
> warned something about the car needing service.
> She took it in to a non-authorized repair place and they told
> her that it was a reminder to have the car checked
> and that the light could only be turned off by an
> Suszuki authorized repair center. The light is still
> on.
Many such indicators are mandated by the appropriate regulatory
agency. This could be either a CARB or EPA requirement.
This could well be a significant item such as emission control
devices. In light of the current regulations in renewing licenses and
having cars pass emission tests it would seem prudent to
follow up on this.
> Some of your points definitely don't apply in this
>case, but I will concede that it could have been accidental.
Notice that some of my points show that companies do
create bugs and they just don't care and they have the
service people run around cleaning it up all the time.
I worked for one company that did this all the time
and when I pointed it out to some upper level execs
they told me that this is how they had been doing business
since before WWII and they would continue to do so.
Then one of them called me a whipper-snapper or something
like that (I was younger then).
That company is in dire straits now. their market
share has fallen from about 80% to about 15% in the
past 20 years. A couple of competitors cropped up
in the 1970's and they have a policy of "it works right
out of the box, always".
It's the big, old companies that seem to do this old
method of "sell it first, fix it later". Maybe Sears is
that way (I don't know), but after talking to the old
execs of a company that was doing this I can say that
they have no malice, this is just the way that they
learned to do business in the early days.
>
>However, since the Sears service guy said that all the timer boards
>fail like this after 3-5 years I would say that Sears has, for
>whatever reason, not taken proactive steps to fix the problem.
That sounds exactly like what I was talking about. In some
companies feedback doesn't exist and the field people know what's
going on, but the execs and engioneers are in the dark
(sometimes purposefully). As long as their sales keep going
or until the upper ranks die off, they will continue to do
business that way. It worked for their pappy.
>
>Failing to fix a known problem, especially one that is easy to fix,
>is the same as designing in failure in my opinion.
>
Well, OK, it is something that is built in to some methods
of doing business, so it could be called purposeful.
Mostly it's just ignorance in the upper ranks of some companies.
Tom
>Many such indicators are mandated by the appropriate regulatory
>agency. This could be either a CARB or EPA requirement.
>This could well be a significant item such as emission control
>devices. In light of the current regulations in renewing licenses and
>having cars pass emission tests it would seem prudent to
>follow up on this.
>
We did immediately. We took it straight in. The independant
said that there was no work that was required on the maintenance
list that couldn't be done by him (except that he couldn't
turn the light off).
Tom
fin...@ts.co.nz wrote:
<snip>
>
> Yes I have a washing machine similar to my own in pieces. I didn't know how
> to identify a battery so I couldn't tell if there was one there or not - the
> control panel contained a lot of componentry! It contains three chips - two
> appear to control the power supply (I got this info from searching the
> internet) & the other controls the functioning of the washing machine. The
> manufacturer could give me NO information on this chip. The details for this
> are: The chip has 40 pins, 20 on each side is marked: Intel Appian
> J363040047 58009-004A 9137
>
- It's an Intel microcontroller (or could it just be a chunk of plastic? Your
article says the washer definitely requires more functionality than a single
microcontroller)
Maybe "Appian" is "Appliance"
- is J363040047 the model of your washer?
- 58009-004A most likely identifies that particular s/w "mask", it is often a
number that the chip manufacturer gives you at the time the firmware is submitted as
a file for masking, to identify your software.
- 9137 is the date code: year 91, week 37
>
> The markings on the circuit board correspond with the pins as follows:
>
> Pin Right Left
> 1 - C -
> 2 - A -
> 3 BO B-
> 4 - TO
> 5 - INT
> 6 -
> 7 - OSC
> 8 - -
> 9 - -
> 10 - C IN
> 11 - A IN
> 12 - B IN
> 13 - -
> 14 - 1 TRIP
> 15 - 1 LIM
> 16 TX OV
> 17 PUMP B+
> 18 BRK A+
> 19 HIST -
> 20 +5V C+
>
> What can YOU tell from this information?
>
Well, I can tell you that your pin 20 is most likely pin 40 because almost all
micros have the +5 volts fed in to pin 40.
I can also see that the PUMP is controlled by pin "17" and the BREAK by "18"
There appear to be some error inputs on pins "TRIP" and "LIM"
>
> And why is no one disputing the 'facts' as I perceive them to be? Where's the
> logical and reasoned argument? It appears that embedded systems engineers are
> just as hysterical about the perceived hype of the Y2K issues as many of the
> general population. Instead of getting emotional about this, their energy
> would best be used in giving me and others the real facts - is that so hard?
A proper reply actually would take quite awhile. Some of the things that got me
going were:
- you are billed as a Computer Consultant. Your article was similar to what an
uninformed journalist would say. I would expect more from you, given your
background as shown on you web site.
>
> If anyone can debunk my conclusions with a sensible argument, believe me, I
> am only too willing to listen and will admit it where I am wrong. After all,
> I wrote the article so that I and others could learn something about this
> problem.
>
I have a problem with this. You should not be writing this type of article an then
saying "its so you can learn something...." . The readers of the article will have
expectations of your credibility based on your title as Computer Consultant. Now
you are telling us you want to learn about the problem. You should have asked us
to comment on the article BEFORE you had it published.
>
> BTW, coincidentally this story from Fisher & Paykel came out the day after my
> article was published, URL:
> http://www.infotech.co.nz/current/nxfnp.html
>
> Now, would this mean that the washing machine WOULD have a battery & perhaps
> even a calendar???
NO!
Unless someone has changed the text at that URL, they are talking about a
diagnostic tool which counts cycles, faults, etc. and will be used by the service
people to aid in the diagnosis of the appliance.
It seems to me a simple form of feedback would be to check on
which Sears replacement parts are being shipped to Sears service
centers to replace Sears parts in broken Sears products. All they
have to do is look, but they apparently aren't. Maybe this is how
they always have done it, like you say. Anyway, not a good way to
keep customers.
>It seems to me a simple form of feedback would be to check on
>which Sears replacement parts are being shipped to Sears service
>centers to replace Sears parts in broken Sears products. All they
>have to do is look, but they apparently aren't. Maybe this is how
>they always have done it, like you say. Anyway, not a good way to
>keep customers.
>
I worked for a company that actually discouraged "feedback".
Their term for it was "interference". Engineering didn't want
to be critiqeud by manufacturing, sales, or service departments,
so the chief chased them off.
When I was new at that company I went out and looked around
the factory floor. There was a suggestion box, so I opened it up
and looked in. It was crammed with scraps of paper. People
in manufacturing were giving me funny looks. I asked who the
suggestions were for and one of the guys told me they were
for engineering and so I took them back to my desk. Half of
them contained swear words about engineering department.
My boss told me to throw them out.
I kept them in a drawer and worked on one or two per week
(except for the ones that had reference to sex and animals
and engineers). I found that many manufacturing problems
on some products were very well know in on the floor, but
unheard of in engineering. I wrote up some ECNs (engineering
change notices) and then it because my legitimate
responsibility to do them. This way I bypassed the roadblock
that people in manufacturing could not do ECNs.
Then I solved many problems and people in engineering
thought that I had found and corrected these problems all
by myself, but all I did was implement the changes that I found
in the box. People were amased, but the whole thing was
pretty stupid from the word go.
A year later I went and talked to people in the service
department and repeated this same "miracle".
Some companies are that way.
Tom
>
>
> > Have you actually examined the machine internally to discover if they are even
> > any electronics in it, and not just an electro-mechanical device? You have not
> > established that there is even any software in it, which you later use to
> > justify possible problems with calendar handling.
>
> Yes I have a washing machine similar to my own in pieces. I didn't know how
> to identify a battery so I couldn't tell if there was one there or not - the
> control panel contained a lot of componentry! It contains three chips - two
> appear to control the power supply (I got this info from searching the
> internet) & the other controls the functioning of the washing machine. The
> manufacturer could give me NO information on this chip. The details for this
> are: The chip has 40 pins, 20 on each side is marked: Intel Appian
> J363040047 58009-004A 9137
[snip]
> What can YOU tell from this information?
>
> And why is no one disputing the 'facts' as I perceive them to be? Where's the
> logical and reasoned argument? It appears that embedded systems engineers are
> just as hysterical about the perceived hype of the Y2K issues as many of the
> general population. Instead of getting emotional about this, their energy
> would best be used in giving me and others the real facts - is that so hard?
>
> If anyone can debunk my conclusions with a sensible argument, believe me, I
> am only too willing to listen and will admit it where I am wrong. After all,
> I wrote the article so that I and others could learn something about this
> problem.
I'd say the most compelling reason why your machine has no extra/hidden
functions is simply: cost.
Why pay *anyone* extra development time, or, conversely, add extra components
(such as a real time clock chip) when it would significantly add to the cost
of the end product and thus degrade profits.
In high volume manufacturing such as home appliances and the car industry, a
potential saving of even some *cents* in final production cost is considered
worthwhile.
The upshot of all this is that making the assumption that this machine (and
others in its class) have RTCs (and thus potentially flawed calendar
functions) when the funtionality cleary doesn't demand it, is simply not
warranted.
Chris.
You have not acknowledged it at all, but prefer to post counter-abuse to
those people who haven't the time or inclination to attend to your
education in a field in which you claim to be an expert.
--
Chris Wright
Colt International Licensing Ltd
>I'd say the most compelling reason why your machine has no extra/hidden
>functions is simply: cost.
>
>Why pay *anyone* extra development time, or, conversely, add extra components
>(such as a real time clock chip) when it would significantly add to the cost
>of the end product and thus degrade profits.
>
>In high volume manufacturing such as home appliances and the car industry, a
>potential saving of even some *cents* in final production cost is considered
>worthwhile.
>
>The upshot of all this is that making the assumption that this machine (and
>others in its class) have RTCs (and thus potentially flawed calendar
>functions) when the funtionality cleary doesn't demand it, is simply not
>warranted.
This is very true. The design criteria for products that are
mass produced are different from ones that have low volume and
the major difference is that high volume embedded designs
are normally done from the chip level up to minimize product
cost.
Talking about *cents* in the paragraph above, I once worked
for a week solid on trying to reduce some cost out of an analog
circuit. It used all precision 1% and by doing some worst case
analysis of using some 5% resistors I was able to pull almost half
of the more expensive 1% ones out of the circuit without degrading
the minimum performance specs. It took me all week to do it, but
I saved 13 *cents* on the product. Volumes where to be 150K of the
product, so in that one week I saved the company 150K*0.13 =
$19,500. It seems silly, but when you do the math it really
does come out.
If the volume would have been 100 pieces then I would have
spent all that time saving only $13. In the case of low volumes
it is best not to look at the pennies (or even dollars sometimes)
and it's more important to just plow ahead to meet
performance criteria and deadline, and that can often mean
using way too much hardware for the job.
Tom
Tom Maier wrote:
I worked on very high volume products, and many of the microcontrollers were
masked. It was a pay-per view satellite receiver with a modem to report what PPV
buys were made. To reduce the cost of the modem, I implemented the data link
layer and the modem modulator/demodulator in a micro, to save the costs of a
modem chip.
Working on products which are to be produced in large quantities was a real
challenge, to look at every possibility for shaving off a few cents.
Mark D'Sylva
>I worked on very high volume products, and many of the microcontrollers were
>masked. It was a pay-per view satellite receiver with a modem to report what PPV
>buys were made. To reduce the cost of the modem, I implemented the data link
>layer and the modem modulator/demodulator in a micro, to save the costs of a
>modem chip.
>Working on products which are to be produced in large quantities was a real
>challenge, to look at every possibility for shaving off a few cents.
>
Off loading as much of the job into the micro often saves on
hardware, as you mention, as long as it doesn't grossly increase
the micro cost. What is annoying is when there
is a hardware engineer who goes forward and designs the
hardware based on the assumption that it has to be there.
There was one guy in particular that I often had a tug-of-war
with. He was an old TTL logic guy who was new to micro design
and he kept putting in hardware and I kept telling him "take
that out, I'm going to do that in software". Sometimes he wouldn't
take it out and so we had some products that ended up with
unused hardware in it. These were low volume stuff, so
rather than fight with him over it I just left it in.
Signal processing is an area I'm a bit weak on. I probably
would have paniced and thrown the modem hardware in.
Tom
Tom Maier (sminst...@mindspring.com) wrote:
: Mark D'Sylva <mds...@scican.com> wrote:
: >Working on products which are to be produced in large quantities was a real
: >challenge, to look at every possibility for shaving off a few cents.
: >
: Off loading as much of the job into the micro often saves on
: hardware, as you mention, as long as it doesn't grossly increase
: the micro cost. [...] so we had some products that ended up with
: unused hardware in it. These were low volume stuff, so
: rather than fight with him over it I just left it in.
There are a couple threads coming together here. Back when
I started in this industry, I was designing P.C.B.s for Telcom
equipment. Odd as it may seem today, telephones in those days
were expected to last 20 years, and were "replaced free" by
the Telcos in the very rare cases of failure. C.O. equipment
had even longer expected service lifes. And of course, all these
things were produced in massive volume. As a result, we spent
quite a bit of time designing the products, before building
them. From management's point of view, I would guess that
"shaving another nickel" was the highest priority, but just
the process of thinking about "how does this alter reliability"
would also sometimes lead to "free" improvements in reliability.
No guarantees, but if you are at least _looking_ at a design,
you have a better chance of improving it than if you are just
"buying a black box"
Even when I moved to coin-operated video-games, there
were "market forces" that made it worthwhile to both minimize
hardware for cost-reduction, and care about reliability.
But the near-collapse (some would challenge "near" :-)
of the coin-op business, and the ascendancy of the PC, there
are _powerful_ incentives of design-time and cost to "just
use PC components". While I agree that a washing-machine
designed _today_ is probably immune to Y2K problems, the
day may not be so far off.
More and more, the "only rational decision" (management
term) is to include "packaged" hardware and software, often
designed for very different applications, in "custom" products.
It will only get worse. The furby folks won't have to address this
soon, but it is "creeping down" the embedded-system market "as we speak".
Today, your fax-machine, tomorrow, your microwave oven. By 2020,
no piece of electrical equipment will be safe from mass-produced
idiocy. Or, perhaps the marketing department of Sirius Cybernetics
_will_ be the first against the wall when the revolution comes... :-)
BTW: the latest Microprocessor Report has a nice article on
Intel's new process (P858). They will be shaving oxide thicknesses
to near theoretical limits (reliability wise), but, not to worry
because "Intel reliability estimates" figure it will still last
ten years. Does that give any _other_ embedded-system guys the
same "kicked in the gut" feeling it did me?
Mike
| alb...@agames.com, speaking only for myself
> As you and others in computing know very well, computing pays a lot more than
> most jobs and certainly more than journalism. Who's going to get rich
> writing articles at .30c per word with a maximum of $250 for any single
> article (and that's NZ dollars - half the US dollar). It has taken many
No one doubts that you would be better off with a real job. The point is
that it is currently a lot easier to sell .30c words about Y2K than
about global warming or any other topic.
KLK
: >Tom Maier <sminst...@mindspring.com> uttered in <36b0b39d...@news.mindspring.com>:
: >
: >[snip]
: >
: >> There's really good incentive to keep those products
: >> error free and durable. The company name is at stake.
: >> An old product that "takes a lickin' and keeps on tickin'"
: >> is good advertising for future sales.
Timex is "still alive", but I'd bet Swatch and a few
zillion FlyByNight LCD-watch companies have more sales _and_
better margins.
: >Unfortunately, I think this is becoming less true.
: >It seems like folks tend to buy based solely on price, nowadays.
: I'm of the opinion that competition for increased reliability
: is increasing.
Not noticeably, IMHO. YMMV.
: in the early sixties companies weren't required by
: law to take returns and many companies operated in a
: rather fly-by-night fashion of producing junk and then
: changing their names to make more. Today there are
: consumer protection laws and a major issue in the
: comapnies is "if we produce an utter failure, will it
: drive us into bankrupcy to take all the product back
: off the market?". This makes an immediate financial
: incentive to make a product that at least mets the
: legal warrenty period.
Not hardly. Typically, these consumer regulations
are dealt with by arranging for the "blame" to fall on
a shell-corporation, which is drained of assets before
too many claims can come in. Speaking of Sears, this
is _exactly_ how they run their "Add a Room" remodelling
service. They have been investigated and warned by
various state A.G.s every few years for the last twenty
or thirty years, yet nothing is ever actually done,
and they are still very much "alive". When Sears,
Microsoft, and some of the more blatant electrical-equipment
manufacturers actually go out of business, _without_
substantial "Golden Parachutes" for the board, _then_
I'll believe there are economic incentives for reliability.
More likely reliability is "snuck into" products by
engineers and production-line workers who just can't
stomach "following orders" all the way. IMHO
: In reality, it is hard to say which of our opinions is
: true because where would the records be to prove it?
In the "Add a Room" case, they are probably available
as court records. In just about every case, the Sears response
was "We contracted that out to some real flakes who seem to
have disappeared. Sorry about that, but the contract you
signed specifically says that your gripe is with the people
you can't find, not with us, even though you wrote the check
to us".
: That attitude has always been around. There used to
: be no laws whatsoever to halt it, though.
There have been fraud laws, and building "codes"
since the days of Hamurabi. There is _always_ a way around
them, and the crooks are better at passing that knowledge
down than the average consumer is :-)
Thank you Mr. Cousins for cutting to the heart of the matter here. The
article (for those who have not read it) clearly states that there is no
real time dependency (Y2K or otherwise) in any of the company's products.
There is too much hype, opinion and lack of reasoned response surrounding
the Y2K issue on all sides. Some products will have Y2K problems, including
embedded products. Many will not. The important thing is to check if there
is a problem with a particular product before speculating that it has a
problem or could not possibly have a problem.
This entire thread is a perfect example. It never would have started if the
original author had taken the time to investigate the problem with the
manufacturer. It never would have continued so far if any of the respondents
(Mr.. Cousins excepted) had taken the time to look for the answer. In
fairness to the latter though, the original author did ask for comments on
his article, so perhaps the responses are warranted.
Wayne Johnston
Disclaimer: these are my own opinions.
When my dad went to business school shortly after the Second World War,
he went to a lecture where the guest speaker was the manager of a
successful, real-world business unit (the electric clock division of a
big appliance manufacturer).
After the speaker told all about the economics of making and selling
electric clocks, he opened the floor for questions, and one student
said, "based on everything you've told us, it would seem that you'd be
fiscally irresponsible if you did NOT put sand in the bearings so that
the clocks will wear out after a few years."
The lecturer hemmed and hawed for a moment, and then finally he said,
"Actually, we etch them with acid."
Tom Maier wrote:
> <snip>
>
> Off loading as much of the job into the micro often saves on
> hardware, as you mention, as long as it doesn't grossly increase
> the micro cost.
It didn't. That micro cost about $2.00 US in the masked version, (8k bytes ROM)
and it had other functionality as well.
> What is annoying is when there
> is a hardware engineer who goes forward and designs the
> hardware based on the assumption that it has to be there.
> There was one guy in particular that I often had a tug-of-war
> with. He was an old TTL logic guy who was new to micro design
> and he kept putting in hardware and I kept telling him "take
> that out, I'm going to do that in software". Sometimes he wouldn't
> take it out and so we had some products that ended up with
> unused hardware in it. These were low volume stuff, so
> rather than fight with him over it I just left it in.
>
I've had similar experiences. I remember on case (back in '82) when the h/w
designer (who was in his 50's back then or at least seemed to be since I was young
then) added inverters between the source of an interrupt and the actual INT pin.
He got really mad when I told him the int. edge sensitivity was s/w configurable.
(that's not the only one, just one that came to ming quickly)
>
> Signal processing is an area I'm a bit weak on
So are other people, including myself.
> I probably would have paniced and thrown the modem hardware in.
>
Well, I would have still needed that micro - it was not there just for the modem.
You may be surprised how simple that code was. There was no signal processing of the
"DSP" in s/w type. The analog signal from the phone line was amplified, bandpass
filtered, and converted to a digital stream. (level detector/schmitt trigger).
The micro then measured the period of the pulses to determine if a 0 or 1 arrived.
That's the main idea, but I left out many details. It was tested on a BER tester in
the presence of noise of the type that you get on phone lines, and worked very well in
the lab and also in the field. This method could be used because of the low data
rate required. (only about 400 bytes to upload)
Mark
Nah, it's done because the EPA requirement for emission controls is that
they function correctly for 50,000 miles. I think the argument is that the
owner would bring the car in for service at that interval, and therefore the
emission control equipment would be working correctly at that time.
I had a truck that had that "feature". It was past 50K when I bought it, but
the service manual gave the procedure for deactivating the light.
You did it by cutting the wire.
>There is too much hype, opinion and lack of reasoned response surrounding
>the Y2K issue on all sides.
So what is your experience in this field? Do you design
commercial products with embedded control?
Tom
>
>
>Tom Maier wrote:
>> He was an old TTL logic guy who was new to micro design
>> and he kept putting in hardware and I kept telling him "take
>> that out, I'm going to do that in software". Sometimes he wouldn't
>> take it out and so we had some products that ended up with
>> unused hardware in it. These were low volume stuff, so
>> rather than fight with him over it I just left it in.
>>
>
>I've had similar experiences. I remember on case (back in '82) when the h/w
>designer (who was in his 50's back then or at least seemed to be since I was young
>then) added inverters between the source of an interrupt and the actual INT pin.
>He got really mad when I told him the int. edge sensitivity was s/w configurable.
>(that's not the only one, just one that came to ming quickly)
>
I can top that story.
This same guy designed a large step sequencer board out of
counters and RAMs for the control of a stepper motor. I had
already told him that I was doing that in software, but he went
ahead and designed it anyway. While it was out at the board
house being fabricated he happened to stop by at the prototype
machine and saw the steppers running. He looked in the
control box and there was only one card, the cpu board in
there.
After the boards came back from the board house he came out
and stuck this sequencer into the rack and walked away,
knowing fully well that it didn't need one.
Stubborn, huh?
Tom
[snip]
> I had a truck that had that "feature". It was past 50K when I bought it, but
> the service manual gave the procedure for deactivating the light.
> You did it by cutting the wire.
Hmmm... the shop manual for my vehicle just says to disconnect
power for 10 seconds (less draconian than snipping a wire! :>)
(unless the lamp is currently indicating an engine fault which
persists after power is restored)
--don
fin...@ts.co.nz wrote:
In article <36AF9975...@scican.com>,
Mark D'Sylva <mds...@scican.com> wrote:
> I was also going to write a detailed reply, but realised it would be a waste
of
> time.
Why? Is it so difficult to refute what I have written? I think your reasons
for not doing so are that you do not possess the knowledge to comment
sensibly so you are hiding behond the excuse of it being a waste of time. It
is not a waste of time my reading any information on this subject. If you
are concerned about it being a waste of your time then you obviously have
plenty to squander on the following abuse.
I don't think that was abuse.
Replying to those such as yourself also takes time. I am hoping my reward will
be a useful response.
Well, go on, make my day and prove to others that you do know what you are
talking about. Try putting YOURSELF on the line and risking the criticsm of
your peers - or do you lack the courage? Its easy scoff - much harder to
take a stand and do something.
For anyone interested in the article I wrote that started this abuse, it is
available at URL:
http://www.idg.co.nz/wwwfeat/Y2000/ja250199.htm
Jocelyn Amon
Financial Solutions Limited
http://www.ts.co.nz/~finsol/-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Hello Jocelyn,
here is my response. I hope that whoever holds the copyright
(if it is Computerworld and not you) does not mind me using it.
I have just highlighted the main sections I don't agree with, as
can spend the entire evening on this.
Monday, January 25, 1999
Will my Gentle Annie survive the Y2K bug?
By Jocelyn Amon
During my research into embedded systems and Y2K compliance, I received
a lot of
criticism in choosing as my example my Fisher & Paykel Gentle Annie
washing machine.
Many have the opinion that there are more serious issues relating to embedded
systems to
write about. Unfortunately Y2K and, in particular, embedded systems are
very dull to most
people. Attention spans would soon shorten if I described the functionality
of a mass
spectrometer or a voltage regulation device.
Why talk about those two devices? There is almost no
chance that they would be affected by Y2K.
If there was a date function in a spectrometer it would be for display
only, and I don't remember the last voltage regulator I saw with
a date function in it, only a date code on it.
A washing machine and the function it performs are things that are familiar
to most of us.
Also, I’ve frequently read that "if it doesn’t need to know the date then
it can’t have a Y2K
problem". As we all know, a washing machine has no need of a date and,
therefore, the
notion that it could possibly be affected by Y2K sounds ludicrous. However,
Y2K immunity
is not always guaranteed in such cases. By detailing the factors that might
affect the Y2K
compliance of this everyday household appliance I hope that I will be able
to enlighten some
readers as to the complexity of the Y2K issues relating to devices containing
embedded
systems.
Embedded systems are the "brain" of any device. They can be as simple as
a single chip
which controls a very straightforward function or they can be as complex
as a control panel
consisting of microcontrollers, microprocessors, a real time clock (RTC),
a long life battery
and other componentry. My washing machine would definitely require more
functionality than
a single microcontroller could provide but it would not need to be as complex
as, for
instance, a VCR.
Error! how did you come to this conclusion?
Both a washing machine and VCR could be controlled by the same 8 bit microcontroller,
with different code of course. A quick guess is that either
would use less than 4 K bytes of code space, and less than 128 bytes of
RAM. A relatively simple state machine can be written
to control either of these two products.
I began my research by asking Fisher & Paykel a number of straight
forward questions in
relation to the componentry that exists within the embedded system. Apart
from assuring me
that my washing machine was year 2000-compliant, a question I never put
to them, they
were unable to offer any further details. They stated that it would involve
disclosing
proprietary information and also that the details I required were commercially
sensitive.
Perhaps manufacturers are sensitive in giving out this information but
it is possible they may
not know the answers.
Or the end users will not know how to interpret them.
Embedded systems are often programmed by third-party companies and the
source code
may not necessarily be given to the device manufacturer commissioning the
work.
That is possible, but most almost all companies who use third
parties to develop software stipulate in the contract that they will require
the source code.
It is not likely that an appliance manufacturer would use a third
party to develop this code. They would have a small software group
for this.
To
save costs, the third-party programmer may use a "one size fits all" base
program to which the
manufacturer’s requirements are added. This base code may also be proprietary
and
commercially sensitive and it may have a calendar function built in "just
in case" it is required.
This is also not very likely. Embedded systems rarely have
lots of junk thrown in for good luck.
And what type of calendar function are you refering to here?
A separate h/w RTC, or a software implementation?
I think you are refering to a h/w RTC. There is almost
ZERO chance of finding one in a washer. ( I really beleive it is
ZERO)
As with "normal" software, often all that is required is for the code to work to specification.
Most embedded software and products are tested to see what happens if abnormal situations occur, not just the norm.
In most cases, how it actually achieves the end result is of no interest
to anyone but the
programmer.
Until it is time for a code inspection before committing it to a
mask or OTP micro.....
I doubt that the washing machine code was just written and dropped
in without an inspection.
Those
adding their layer to an embedded system might not understand how it
will finally be deployed and devices may be adapted for a purpose which
was originally never
intended.
Embedded systems such as those found in a washing mashine are relatively simple. They would rarely consist of "layers" as you describe. Often, there is no kernel or OS in them.
At
each step the original source code used and the record of various adjustments
may be lost. All this makes it very difficult for anyone to know for sure
what is actually
occurring within many embedded systems.
This is possible in any software, but remember this washer
runs on about 4Kor less of code. It's rather hard to get lost with
such a small system unless it was very poorly written, or the programmer
just inherited a real mess from someone else who had left.
Also, there are source control tools which can be used to track changes
to code.
I think any competent s/w engineer could look at that code and have
a very good idea how it operates within 1 weeks, maybe less. These
systems may be mysterious to YOU, but not to us.
Therefore my washing machine could contain a calendar function and, because
of this, it
could be susceptible to the Y2K bug. If a calendar function were present
in the base code, a
programmer might decide to use it to time my washing machine’s wash and
spin cycles. If this
were the case then it would increase the chances of a Y2K bug causing a
failure.
Even if the RTC and calendar function was in the code, very
few (no?) programmers would use it to time a cycle.
Using that method would take more code that doing it the proper
way!!
They would most likely set up some down-counters which get deceremented
to zero by the interrupt routine.
At the beginning of the cycle, you load the required time
into the counter. Then you just check for zero,
and your done.
For a Y2K bug to be activated, my washing machine must be continuously
powered long
enough for the year value to move from the start-up date to the year 2000.
For most
computer systems, the start up year value is 1970 or 1980. For some embedded
systems the
start-up year can be as late as 1992. Therefore my washing machine must
stay switched on
for a minimum of eight years for a Y2K failure to occur. This would be
very unlikely to occur
as I frequently switch it off, causing the year value to revert to the
start-up value.
However, it is not uncommon for embedded systems to have their own alternative
power
supply, usually a lithium battery. PCs use lithium batteries so that date
and configuration
information is retained whenever the main power source is switched off
or disconnected.
There is a possibility that my washing machine could also have a battery
to retain
configuration information. Some lithium batteries can function for up to
10 years and some
are able to be recharged whenever the main power source is switched on.
There is no configuration info I can think of for a washer. Manufacturers don't add parts unless there is a good reason as it increases costs and may reduce reliability.
Any failure occurring in a device that has no requirement for a date is
unlikely to happen on
January 1, 2000, as it is very unlikely that it would have ever been set
to the correct date.
Any Y2K failure in such systems is likely to occur sometime after that
date. For testing
purposes, however, embedded systems may be set to the current date at the
time of
manufacture, so failure occurring on the actual day cannot be completely
ruled out.
They are going to set the current date into the washing machine in
the factory? Why? So it can take a day off on its birthday?
It is highly unlikely.
Each system can have its own unique way of failing Y2K compliance. The
majority of
embedded systems hold the year as two digits only. This is not a problem
if the programmer
has given consideration to the year 2000 occurring and handled the year
value correctly.
Ideally any logic would have been tested for year 2000 compliance but,
until recently, this
would have been most unlikely.
Many embedded product *have* been tested for compliance during development, even in the 1980's. I did this on date sensitive products I worked on. I think embedded developers were more aware of this than mainframe developers, but I could be wrong.
A Y2K problem may be introduced when the logic does any of the following:
Converts the value to a four-digit year by prefixing "19".
Adds one to the year and makes no allowance for storing the extra digit
when 99
becomes 100.
Reads in the year in "years since 1900" format and makes no allowance for
an
incoming year value of three digits,
Sorts or calculates with a year value of 00.
Where an extra digit is encountered that was not allowed for, either of
the following scenarios
is a possibility:
The extra digit could overwrite another value and corrupt it, either by
changing the
original value or making the value unreadable. This could affect a temperature
reading,
an item count, an elapsed time value or some other value that may or may
not be
important. Any "fail safe" mechanism built into the program logic could
be invalidated
as the corrupted value may fall outside the conditions allowed for.
Why do you assume that the extra digit would cause this?
In an embedded software product, you would not represent years
in ASCII, it may be BCD or even an 8 bit count from the base year,
and even that would be good for 255 years.
The extra digit could overwrite part of the program. This may cause the
program to
halt or could cause something "odd" to happen, either immediately or at
a later point in
the operation.
How is it going to corrupt the program code? The washer is running from EPROM or ROM, not RAM.
An example applicable to my washing machine would be failure to allow for
a year of 00.
This may cause an elapsed time calculation to give an incorrect value when
99 was
subtracted from 00. This particular example of failure would only be a
concern if my washing
machine was operating at the time of the 1999-2000 rollover.
Like I said earlier, this is not how you time events in an
embedded system.
Plus who would turn it on just before new year? Most
people would not be anywhere near the washer. Make sure you aren't!!
I have established that there is a very slight possibility of my washing
machine failing or
functioning incorrectly on January 1, 2000.
After making a whole slew of assumptions of which the individual
possibilities are next to zero.
Now, just work out overall probability
However,
I consider the main threat to my
washing machine’s viability to be a failure of the power transmission systems.
The power
industry is reliant on thousands of embedded systems, many of which do
have a calendar
function and which keep track of the current date. A certain percentage
of these will have
Y2K compliance problems.
In my next article I will ask some the questions relating to embedded systems
that I have
been unable to find answers to. In particular, I am interested in the likelihood
of the various
scenarios, described above, occurring. Perhaps Computerworld readers with
expertise in
this area will be able to provide the answers for the benefit those who
need to decide what
devices to include in Y2K assessments. You can post your queries directly
to
Computerworld’s Y2K Hotline.
I hope that my reply satisfies you. I am sure that anyone in
my field will agree with most of what I have said. I really
did not have the time for this reply, but I know you are expecting
it.
Maybe you would like to see something relating to my work
so you know that I have a little background in embedded systems, since
you said earlier that I don't have the knowledge to comment on embedded
systems.
Just look here: http://www.patents.ibm.com/details?pn=US05699385__&language=en
(I developed the s/w algorithm and code)
Mark D'Sylva
"Maybe the embedded firmware is written by emus and kiwis where she comes
from."
The assumption that we New Zealanders would allow Australian emus anywhere
near our embedded systems is a slur on our good judgement.
As for the rest of the message, thanks for taking time to reply so
comprehensively. I am still working through the info you have given and will
reply soon.
Thanks again
Jocelyn Amon
I had a 1980something Volkswagen where the light was controlled by a
secret, "black" odometer. A mechanic told me to find it by tracing the
speedometer cable. Push the white button on the side of it, and the
light went out for another 30,000 miles.
AFAIK, the engine did have an ECU, but the odometer that turned on the
idiot light was purely mechanical.
> In article <36B3BFBC...@interlog.com>,
> Mark D'Sylva <mds...@interlog.com> wrote:
> >
> > --------------FE47F93CDFEE4550BD268836
> > Content-Type: text/plain; charset=iso-8859-1
> > Content-Transfer-Encoding: 8bit
> >
> > fin...@ts.co.nz wrote:
> >
> > > In article <36AF9975...@scican.com>,
> > > Mark D'Sylva <mds...@scican.com> wrote:
> > >
> <snip>
> >
> > I don't think that was abuse.
> > <snip>
> >
> The comment I termed as abuse was the following:
>
> "Maybe the embedded firmware is written by emus and kiwis where she comes
> from."
>
> The assumption that we New Zealanders would allow Australian emus anywhere
> near our embedded systems is a slur on our good judgement.
Now who is abusing whom???
> As for the rest of the message, thanks for taking time to reply so
> comprehensively. I am still working through the info you have given and will
> reply soon.
Chris - An emu style programmer if ever there was one!
Tom Maier wrote:
>
> chris.h...@bigfoot.com (Chris Hoffmann) wrote:
>
> >I'd say the most compelling reason why your machine has no extra/hidden
> >functions is simply: cost.
> >
> >Why pay *anyone* extra development time, or, conversely, add extra components
> >(such as a real time clock chip) when it would significantly add to the cost
> >of the end product and thus degrade profits.
> >
> >In high volume manufacturing such as home appliances and the car industry, a
> >potential saving of even some *cents* in final production cost is considered
> >worthwhile.
> >
[snip]
> Talking about *cents* in the paragraph above, I once worked
> for a week solid on trying to reduce some cost out of an analog
> circuit. It used all precision 1% and by doing some worst case
> analysis of using some 5% resistors I was able to pull almost half
> of the more expensive 1% ones out of the circuit without degrading
> the minimum performance specs. It took me all week to do it, but
> I saved 13 *cents* on the product. Volumes where to be 150K of the
> product, so in that one week I saved the company 150K*0.13 =
> $19,500. It seems silly, but when you do the math it really
> does come out.
>
[snip]
True, as long as you aren't drawing a salary of $1,014,000 / year
($19500 x 52). However if you draw @100,000 per year, and do this
10 times over the course of a project (or 10 engineers do it once),
then you have absorbed your savings in salary, as well as incurring
a delay to market...gotta do that break-even analysis.
--Mark
>True, as long as you aren't drawing a salary of $1,014,000 / year
>($19500 x 52). However if you draw @100,000 per year, and do this
>10 times over the course of a project (or 10 engineers do it once),
>then you have absorbed your savings in salary, as well as incurring
>a delay to market...gotta do that break-even analysis.
>
They did the break even analysis. I was "idle" at the moment,
between projects, and the device they assigned me to minimize
was "idle", waiting for the assembly line to become available.
It was either work on that or read "MAD Magazine", so
there wasn't too much to be decided.
At that company they would overstaff engineering and then
when a person became idle they would assign us to outside
contract design jobs to keep us busy. The in-house stuff
always took priority, though. This way they always had a
large supply of engineers on hand.
Tom
sorry for the flame :-(
KJ
___________
Chuck McCown <m...@bcl.net> wrote in message
news:36af3...@news.accessus.net...
>
>I find it hard to understand why a washing machine would need a calandar.
>
>
regards,
KJ
_____________
Eric Gunnerson <eri...@micronospamsoft.com> wrote in message
news:78qfa7$7...@news.dns.microsoft.com...
>John Nagle wrote in message ...
>> VCRs, though, especially the fancier ones with VCR Plus, may
>>have problems. Also, some VCRs get time and date info from broadcast
>>signals, although I think this is based on data usually sent only
>>in Europe.
>
>
>In the US, public television stations broadcast time information; my VCR
>sets the time from this automatically.
>
>
HOWEVER, I think that you might be overlooking one subtle, but rather large
point; Unless you are talking about very small companies doing this, there
would be way too many people who would have to know about this! Can you
imagine if, say, General motors were practicing this in their vehicles
(who's nervous!)? There is no way that everyone involved, or who knew about
it could keep the general public from finding out. The media would get a
hold of it and watch out!There would be such a huge public out-roar that
nobody would ever buy a GM product again! If the president can't even keep
anything secret, why should we believe anyone else can?
But, then again, I could be wrong.
I guess that would mean that everyone at GM would be having quite the little
chuckle right now!!!
regards,
KJ
_____________________
Daniel Quinz <da...@micronetics-ces.com> wrote in message
news:36B0A1...@micronetics-ces.com...
>Tom Maier wrote:
>>
>> "Brad" <ti...@iafrica.com> wrote:
>>
><snip>
>
>>
>> Have you ever had people accuse you of designing things
>> to fail? I get that every now and then at parties. When I
>> say that I'm a designer some people will say "You purposely
>> design things to fail once the are out of warretny, don't you?
>> Why do companies do that?". Then I have to explain that
>> it is not a plot to design things to fail, it just comes naturally.
>> =-} Some people get really suspicous.
>>
>> Tom
>
>I find it interesting that you comment on this.
>
>I have been thinking about how embedded technology could be used by
>people to easily and deterministically design in product failure in
>order to provide a *gauranteed* stream of service work.
>
>!!! DISCLAIMER !!!
>
>!!! I DO NOT SUPPORT, ADVOCATE, OR PARTICIPATE IN THIS ACTIVITY AND
>CONSIDER IT AN UNETHICAL PRACTICE !!!
>
>Now then, let us continue.... :)
>
>This could conceivably provide incentive for dealers to push a
>particular brand of car so that they can reap the service fees.
>
>Consider the case of an automobile engine controller. An engineer could
>write the control code so that it degrades engine performace as a
>function of time & mileage. When the customer brings his/her car to the
>shop, the mechanic checks the on-board computer with his analyser and it
>instructs him that it is time to change the plugs, oil, filter,
>whatever. Upon completion of the 'tune-up', the mechanic resets the
>analyser and gets a clean bill of health for the car.
>
>What's important to emphasize here is that neither the customer nor the
>*mechanic* is aware that the tune-up was unnecessary.
>
>With todays low-cost, powerful, and secure microcontrollers (PIC, for
>example), it would be virtually impossible to prove that this was being
>done. With code-protection enabled, an outsider could not dissasemble
>the control code for evidence and there is no other, easily acquired,
>evidence that is as strong.
>
>What is really significant here is the ease, certainty and impunity with
>which this behaviour can be achieved.
>
>I would be very much interested in your (and others) opinion(s) on the
>matter.
>
>Regards,
>
>Daniel J. Quinz, P. Eng.
>Micronetics CES
>e-mail: da...@micronetics-ces.com
> > What is really significant here is the ease, certainty and impunity with
> > which this behaviour can be achieved.
>
> I think there are lots of big assumptions you make here.
>
> First, I dispute the "ease, certainty and impunity" claim you make.
> We're always hearing about whistle-blowers in various industries.
> How do you *guarantee* that the folks who *know* about this
> never "squeal" to the press, governmental agencies, etc.?
> Or, that they don't eventually end up working for some *other*
> car manufacturer, mention this at some point in their employment
> and find the other car manufacturer deciding that this would be
> a great way to damage their competitor in the eyes of the
> **BUYING** public? After all, the offending car manufacturer
> would be hard pressed to gather up all evidence of his
> misdeeds -- since millions of them would be scattered around
> the planet!
Now your raising the question of whether or not designing in limited
operational life is ethical. That rather depends on a number of factors.
Systems I design have their features considered with respect to:-
* Safety
* Environment
* Economy
.....in that order.
I have designed some systems to perform their designed functions until a
certain specific date and then to cease to operate. Such non-operation
continues until the system safety features have been validated and the
validation timer reset. The client has full knowledge of this aspect of
the system so the systems are not being mis-represented to him.
The reasons for doing this are to ensure that the system safety certification,
required by some systems, can be revalidated at regular intervals.
--
Paul E. Bennett ................... <p...@tcontec.demon.co.uk>
Transport Control Technology Ltd. <http://www.tcontec.demon.co.uk/>
<enq...@tcontec.demon.co.uk>
Going Forth Safely
> BTW: the latest Microprocessor Report has a nice article on
> Intel's new process (P858). They will be shaving oxide thicknesses
> to near theoretical limits (reliability wise), but, not to worry
> because "Intel reliability estimates" figure it will still last
> ten years. Does that give any _other_ embedded-system guys the
> same "kicked in the gut" feeling it did me?
Now you know why I never use Intel products in any system I design. :->
My clients spec a minimum life expectancy of 30 years and so far the
component we have most trouble sourcing for that lifetime is the
electrolytic capacitors. The ones that stand the best chance of lasting
that long are usually more expensive (CECC or Mil-Spec). Adding certain
microcessors to the list now seems to be a necessity.
(I wonder if Italian cars are Y2K compliant? Uh oh, bad joke coming...)
-Bill Giovino
Microcontroller.com
Jon Ward wrote:
>
> Well, I guess we're gonna have to fault GOD. He designed American Men to
> fail at 70 years, but he designed French Men to fail at 74 years. And, the
> French drink more wine, smoke more, and have affairs with young under-age
> women. I wish God had designed ME to be a French Man.
>
> Jon Ward
> Keil Software
>
> Tom Maier wrote in message <36afb546...@news.mindspring.com>...
> >"Brad" <ti...@iafrica.com> wrote:
> >
> >>
> >>Chuck McCown wrote in message <36af3...@news.accessus.net>...
> >>>
> >>>I find it hard to understand why a washing machine would need a calandar.
> >>>
> >>
> >>
> >>Easy, it needs to be hung up in front of it, like an eye test. How else
> will
> >>my W. Machine with all
> >>mechanical timers know that its must fail on 01/01/00.
> >>
> >
> >Yep, that's how things are designed, we have to work extra
> >hard to get those calender bugs in there =-}.
1. Desktop computer
2. Laptop computer
3. Cigar humidor
Both the desktop & the laptop passed, mostly as a result of my diligence
in preparing them for Y2K. Most recently, I upgraded the Microsoft java
VM on both computers - it is not well publicized that Microsoft's JVM
was not Y2K compliant until the final updates were posted to Microsoft's
website last month (Win98's JVM is not Y2K compliant!).
There was one glitch - some of the Dilberts I had saved on my desktop
did not print. These were all the ones with the Pointy-Haired Boss,
however.
My humidor passed, however, one of my lighters stopped working. I
concluded that the fluid was not Y2K compliant.
And now, for a dose of reality...
I spent 30 minutes on the phone today with Airtouch Cellular before I
could find someone who would admit that their cellular phone network
*might* *not* be ready in time for 1/1/2000; they would not assure me
that my phone would work.
-Bill Giovino
Microcontroller.com
> I can understand why you think that maybe things are designed to fail, (my
> Quantum HD recently failed three weeks after the warranty expired...).
> :-(
>
> HOWEVER, I think that you might be overlooking one subtle, but rather large
> point; Unless you are talking about very small companies doing this, there
> would be way too many people who would have to know about this! Can you
> imagine if, say, General motors were practicing this in their vehicles
> (who's nervous!)? There is no way that everyone involved, or who knew about
> it could keep the general public from finding out. The media would get a
> hold of it and watch out!There would be such a huge public out-roar that
> nobody would ever buy a GM product again! If the president can't even keep
> anything secret, why should we believe anyone else can?
>
Oh, I don't know about that, the US government managed to cover up Rosewell.
I'm sure that companies large and small can cover their tracks also. Anyone
know a 'true' story of this type ?
> But, then again, I could be wrong.
>
> I guess that would mean that everyone at GM would be having quite the little
> chuckle right now!!!
>
> regards,
> KJ
> _____________________
> Daniel Quinz <da...@micronetics-ces.com> wrote in message
> news:36B0A1...@micronetics-ces.com... s.com
Hello KJ,
Sorry about your hard drive. Five out of five seagate
Barracuda's bit the dust here this year, all in the same
RAID chassis. Glad they failed one at a time however.
That aside, your comments about GM are amusing. GM, Ford,
and Chrysler publically admit their vehicles are designed to
last a specific amount of time, and I'm going to guess here,
and say its 6-8 years. If you bought a vehicle that lasted
20 years, you'd be cutting into the market segment that the
Big Three thrive on - repeat business.
Anyway, just 2 cents, highly off topic. :)
--
Frederic Breitwieser
Bridgeport, CT 06606
http://www.xephic.dynip.com
1993 Superchaged Lincoln Continental
1989 500cid Turbocharged HWMMV
1975 Dodge D200 Club Cab (soon to be twin turbo 440)
2000 Buick GTP (twin turbo V6)
It can't be too hard. In a company of thousands, a job can be subcontracted
by an employee, who has signed an NDA, to a third party who also has signed
an NDA. The NDA cannot *force* someone to keep their mouths shut, but it
can be a strong incentive to do so. The key is not to involve a bunch of
in-house employees in the process.
[...]