SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Year 2000 (Y2K) Embedded Systems & Infrastructure Problem

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: John Mansfield who wrote (523)7/19/1998 10:23:00 AM
From: John Mansfield  Read Replies (2) of 618
 
Valuable article: 'Critique of Mark Frautschi's Report

asked in the TimeBomb 2000 (Y2000) Q&A Forum

This critique done by Harlan Smith. Credentials at bottom.
This is also good solid information for those who are
unsure of what an embedded system really is.

*********************************************

* I am critiquing Mark Frautschi's report right now at his
specific request and I am very displeased with it. He has
gathered every urban legend in sight, scrambled them
some more and given us an omelet of urban legends that is
very counterproductive.

* The "embedded systems" problem is very serious but
bears no resemblance to what Mark Frautschi portrays in
his report. His references are in many cases poor and in
many cases do not support what he says.

* He clearly does not understand "embedded systems"
even though he apparently has a Ph.D. in Physics.

* Please take everything you read in there as possibly
completely incorrect.

* I don't know how many times I have to say this but
THERE IS NO EMBEDDED CHIP PROBLEM. There
is an "embedded system" problem. "Embedded chip
problem" is the jargon of the technically illiterate. I will
clarify:

a. All Y2K problems are software problems. There are
no Y2K hardware problems, none, zero.

b. Even PC Clock problems, where the century is not
properly accounted for, are software problems as the
BIOS software has not properly accounted for the fact
that the RTC (Real Time Clock) does not incorporate a
century counter. Almost no RTCs do, with the exception
of one little used device from Dallas Semiconductor.

c. The non-compliant software that will cause Y2K grief is
not designed by the semiconductor manufacturer but the
"embedded systems" designer. This is true regardless of
whether that software is supplied to the semiconductor
manufacturer to deliver mask programmed ROMs or the
"embedded systems" house programs a blank EPROM,
EEPROM or other blank field programmable ROM.

d. When one looks for "embedded systems" problems,
one is _not looking for "non-compliant chips". THERE IS
NO SUCH THING AS A "NON-COMPLIANT
CHIP". Instead one is looking for a cluster of chips that
forms an "embedded system". A small computer, if you
will. If that "embedded system" is found to be
non-compliant, the cause will be that there is
non-compliant software resident on a ROM (Read only
memory). If the system can be repaired, the fix will be to
find the source code, re-compile, re-program a ROM (by
whatever means is consistent with the ROM technology)
and repair the circuit board by replacing the ROM. This
may not be possible for numerous reasons, in which case
the "embedded system" may have to be replaced. (Don't
get confused, the ROM could be incorporated into the
micrcontroller chip.)

e. Can an "embedded system" be a single chip? Yes. In
simple systems, a microprocessor based system is not
used. Instead a "microcontroller" is used that can have
on-chip ROM and RAM to form a complete system.
However, those remediating systems important to the
infrastructure, or safety critical, generally find that they are
almost always dealing with more complex,
microprocessor based, multi-chip systems, on the order of
complexity of a PLC (Programmable Logic Controller) or
greater. I will explain shortly how this cuts down the
number of systems we have to be concerned about
immensely.

f. Can a microprocessor-based system be placed on a
single chip? Again yes. There is a technology called ASIC
(Application Specific Integrated Circuit) that permits this.
However, it is expensive to have such designed and we
will likely find very few of these to concern ourselves with.
When we are doing our detective work, we will be in
general looking for multi-chip devices, as ASIC
technology is relatively new and expensive and most
PLCs etc. deployed to the field are multi-chip devices.
However, this only impacts the numbers of "embedded
systems" we must deal with as there are myriad
exceptions to worry about. An expedition to find
non-compliant "embedded systems" must try to
comprehend the occasional oddities or they will miss a
few important problems. This is one reason why the
problem is so damn mind bending.

g. How many "embedded systems" do we have to worry
about? I have done some homework here. Others,
including, for sure, Mark Frautschi have not. Look at this:

World Semiconductor Trade Statistics (WSTS) from
Integrated Circuit Engineering Corp. (ICE) Status 1998

Units (millions) 1991 1992 1993 1994 1995 1996
1997(est) Total Microcontroller 1722 1902 2221 2659
3067 3450 4167 19188 Microprocessor 136 143 167
170 212 249 286 1363 20551

Asked by Tom Scully (2scully@concentric.net) on July 17, 1998.

Answers

Here's the rest of it:

***************************** Every "embedded
system" must incorporate either a rmicrocontroller or a
microprocessor. But I've already said that threats to the
infrastructure are likely microprocessors, not
microcontrollers. That's important, when one looks at the
numbers.

>From this, we can perhaps estimate that 30 or 40 billion
microprocessors and microcontrollers have been
deployed to the field but less than 3 billion
microprocessors. So we've already reduced the potential
threats to the infrastructure by a factor of **10**.

Now further, we know that microprocessors are used in
computers and there are huge numbers of PCs and other
computers built that will chew into that 3 billion.

We again reduce the number, by those not incorporated
into date sensitive systems.

And again by those that are compliant.

Rick Cowles uses a figure of 25 million of concern. I'll go
with that. If we assume that is worldwide, that is
25*10^6/40*10^9 = .000625 or .0625% of the problem
that would be represented by 40 billion. Worldwide, we
can probably handle 25 million.

25 million is doable and fixable. 40 billion is not.

g. So now that we've got "techie", non-compliant chips,
and the numbers under a little control let's go on and
respond specifically to Mark Frautschi.

>-----Original Message----- >From: Tom Scully
[SMTP:2scully@concentric.net] Sent: Thursday, July 16,
1998 11:34 AM To: year2000@efn.org Subject:
Embedded Systems Question

>Harlan and other techies- >Could you check out the
following url and let us know if this is accurate or not.
Namely this:

"Thus, even when only relative time is required by the
OEMs, this may often be derived from chips that keep
absolute time internally. Those chips that represent
absolute time using two digit dates are subject to
Year-2000 failures just as with computers and software
as has been>more widely reported."

This could happen. Think about your PC. If you replace
the battery for the RTC and don't reset the date, it would
start ticking away from the default date. So could an
"embedded system". So, it would have 20 years before it
thought it reached 2000 and that would be 2018. We
have 20 years to worry about that prolem. I don't care if
the problem occurs in 2001. Our present concern is about
what occurs in years 1999 and 2000.

>The logic "It does not NEED to keep dates, therefore it
does not keep >dates." is not based on what is actually
happening within the chip.

Not the chip, the "embedded system" let's just forget this
ignorant "chip" jargon.

"This has resulted in a number of systems being declared
Year-2000-compliant when in fact their chips have not
been tested. Examples of systems containing unassessed
chips include remote control load management switches
installed at consumer sites by electric utilities, automobile
power train transmission control modules and major
household appliances."

Pretty much a garbage statement. "include remote control
load management switches installed at consumer sites by
electric utilities"? What does that mean? If he could talk in
English, there may be date-sensitive "embedded systems"
in electric utility substations or yard switching and we
should worry about such. The electric utilities have been
close mouthed about that, saying that problems are largely
restricted to generating stations of all types.

Non-compliant "automobile power train transmission
control modules and major household appliances", is an
unsupported "urban legend". If I find any support for that,
you will be among the first to know.

"Please see reference [4]. In the case where no date is set
by an external agent, the chip defaults to its "epoch" date.
This could be the design date, the date of manufacture, or
some other, arbitrary, date. Non->compliant systems are
subject to failure when the internal date reaches
>1/1/2000, which in general will not be in step with actual
time (since there >is no means, or need, to input actual
time at the turn-on point). In >general, such a chip will
reach 1/1/2000 internally AFTER 1/1/2000 >actually
occurs."

Technically, this is possible, IF the "embedded system"
has a built in lithium battery or equivalent. But why would
a designer go to such lengths to design a system that way.
This is really an unsupported claim.

"This is due to natural delays introduced by the production
life cycle, shelf >life and possibly the duty cycle (the
fraction of the time the chip is >"powered up"). For
non-Year-2000-compliant architectures, these delays
increase the likelihood that most of their failures will occur
AFTER 1 January 2000. One manufacturer has released
documentation to its customers that some of their systems
will not fail until 2006. [5]"

So, possibly, there are a very few weirdly designed
devices out there that will fail in out years. This is ;not a
major concern. We really don't care. They will probably
be lost in the noise level of random failure that we expect
anyway.

tmn.com editorializing on
a long list of references (some good) is mostly a bunch of
inarticulate baloney. I have been trying to read it and
comment on it and am getting very frustrated about the
gap with reality. Gary North of course loves it, as it
supports his thesis of world calamity. Finally.

DON'T SAY "TECHIE"

DON'T SAY "EMBEDDED CHIP PROBLEM"

DON'T SAY "NON-COMPLIANT CHIPS"

DON'T SAY "A 40 BILLION CHIP PROBLEM"

DON'T SAY "WE MUST TEST 40 BILLION, OR
ANY NUMBER OF CHIPS,IN THE FIELD"

-----

DO SAY "Embedded systems" are a big problem.

DO SAY "We may have to test, or otherwise investigate,
as many as 25 million 'embedded systems'"

DO SAY "Investigating these is a very tedious and difficult
task"

DO SAY "When a non-compliant 'embedded system' is
found, it may be very difficult to repair or replace"

DO SAY "Most people completely misunderstand the
'embedded system' problem"

DO SAY "The 'embedded system' problem can only be
solved by a lot of management understanding and hard
work."

DO SAY "Let's clear away the fear mongering baloney
and put our shoulders to the task of getting this done."

DO SAY "Mark Frautschi, you have made a very definite
negative contribution to the effort. Spreading urban
legends and stating that things are hopeless and we must
go back to pencil and paper is asinine in the extreme."

DO SAY "This is a damn big problem and, if we don't
approach it diligently and intelligently, disaster is likely to
occur."

How do I follow up, "strong letter follows"? Harlan

Synergistic Mitigation & Contingency Preparation --
"Austere Infrastructure"
2000.jbaworld.com
scotsystems.com (for printout)
Quick Small Business Guide to Y2K
angelfire.com
Embedded Systems Remediation
2000.jbaworld.com
y2knews.com YOU CAN
HELP angelfire.com

Answered by Tom Scully (2scully@concentric.net) on July 17, 1998.

greenspun.com
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext