OK, this brings up a topic I'd like to understand better... Certainly a
goal of most or all businesses is to create a 'revenue stream'. It's
turned out that the easy way to do this is to churn products - new model
each year, "new and improved" something (everyone wants to have the
latest), planned obsolescence, etc. In a lot of cases, chasing some
small improvement results in more complexity, "more ways for it to
break", and higher repair costs. In fact, the engineering process is
full of phrases that address this, like "if it ain't broke, don't fix
it", and there are always arguments between older engineers vs newer
ones, or techs vs engineers, about how some or another 'upgrade' isn't
needed or is downright foolish. The evolution of Microsoft Windows is
probably the premier case in point.

So, as engineers, where is the line drawn on when to integrate some new
technology? Internet toasters... hmmm... the old ones work well, they
last for years, and you have to be there with it since you're gonna eat
the toast, so any 'remote control' or internet connection is just silly.
However, I could see (if not done already in some models) where a PIC
might be added with sensors to determine toast 'doneness'. While the old
style is reliable and at most you might lose a few slices at first try
in finding your preferred setting, a semiconductor toaster brings with
it a whole 'nuther set of issues, like susceptibility to power surges or
line transients, limited life of the controller due to heat, more
components - higher failure rate, etc. If internet connected, then there
could be a whole list of future problems such as security (a flaw or
worm that makes it turn on and stay on without the owner knowing), or
just obsolescence because it couldn't handle IPv6 or it was 10Mb and
your net is only 100Mb+.

There's also the perspective in the decision. Imagine a condition where
a device (even a car) can enter a 'broken' state. You could design in a
soft-fail mode where it continues in limited mode until fixed, or it
could just stop until it is repaired. Let's say the soft fail product
would, based on failure analysis, cause 3 times as many units to go into
degraded mode and report an error, vs the hard fail ones. One case has a
higher statistical failure rate, but the other one has a greater impact
on the customer. From a 'numbers' point of view, hard fail is better
perhaps. From a customer view, soft fail is better. After all, the
customer only cares about his/her unit, not your statistics...

I know I've become less of an advocate for doing it a new way all the
time. Any ideas on how to decide? If going to a semiconductor based
design chops $0.05 off the cost, but makes the unit more complex, more
prone to failure from reliability or design problems (you sure you
tested it under all-day operating conditions now?), and more difficult
to repair, do you do it willingly? It's almost an engineering ethics
problem. The CEO says shave the cost - knowing replacement sales will go
up, he can shut down the repair channel perhaps (cheaper to buy a new
one for the customer since repair shops won't want to debug), and with
new designs every year, he can stop selling repair boards in a few years
and force customers to upgrade. This, vs the old design that lasted for
years with parts that are available by the 'billions' out there (small
appliance type scenario). Do you argue, or just do it? Do you have any
obligation to the customer? All this manufacturing and marketing stuff
is just the 'stuff' needed to get YOUR design into the customer's hands...

Then there's the ego part. MY design or routine is so good it'll never
be hacked into. No buffer overflows here... You might not say it out
load, but it happens every day. Your toaster code may be great, but
there's a place where execution can start and leave it vulnerable on the
net if it starts randomly... You test the hardware under all conditions
and it always comes up fine and starts at the beginning. Ship it! Then,
6 months later, purchasing sources a resistor from China and it can go
so far off when warm (it's a toaster) that it causes a brownout
condition and maybe random code execution or IP vulnerability... Testing
and experience showed it worked fine without planning for that
contingency, but now it shows up in a million units. It would've cost
another $0.06 to put in protection, but that would've blown the CEO's
numbers, and your experience said it wasn't likely (but you never used
Chinese resistors before...). Look at all the recalls today vs 20-30 yrs
ago... CEOs don't know zeners. How far do you push? And in this case,
you can even spin it to put blame on hackers for anyone so hacked, so a
recall isn't in the plan. Is it the hacker's fault or Microsoft's fault
when a buffer overflow in a driver causes the system to allow remote
execution of code? Who is to blame when someone connects to your drive
and sees your files when Wndows ships with the smb port open and ready
for connections? If you say the bad guy is always to blame, remember
that most insurance cos. will not pay up if they can show you left your
car door unlocked... The bad guy did bad, but you were held responsible
for letting it happen. I digress though.

Chances are, the original freezer problem came about this way. Is it
corporate misconduct? I doubt it. You don't invest millions into a
product in order for it to be a dud. Marketing said "we need a new fancy
model". Product planning said "put in an ice maker". The engineer
said... ? While the engineer on it might have been following 'orders',
what is his responsibility for the undefined parts and to create
something usable to the many customers? Each of the bum products talked
about, from the fancy freezer to the new Honda, were engineering
'improvements' over the previous models that had worked fine. Was it
really necessary? It's the effect even a single engineer can have. The
company may facilitate the transaction, but you bought this engineer's
piece of work. Do you do the same? (rhetorical question) So what do you
do to prevent this (assuming your ego doesn't say it's perfect 'cause
you designed it ;) , AND since someone will always be inconvenienced
over some design flaw or feature, how do you minimize the impact to all?

New isn't always improved. And BTW, "you" means just the reader and
isn't a particular person or posting... ;)

-Skip

Robert Ammerman wrote:
> Maybe we really do need Internet connected toasters: for firmware updates!
>
> Bob Ammerman
> RAm Systems
>
>   

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist