I hope pollies are tormenting me, gloating, dancing in the streets. I hope all
my friends are 'ribbing' me about y2k for *years*. I hope all that grain I
have is fed to birds and dear. I hope my grandchildren laugh when I tell them
the funny story about hauling a truckload of canned goods to a farm in Northern
It would mean that the world as we know it still more or less exists.
Cory says the real problem is with legacy systems, not embeddeds. Maybe he
thinks so because those are the problems he knows and sees.
I am Shultz: I know nothing. I see nothing.
But I do read a lot, talk to people, think, and prepare.
Read this (on embedded systems) if you need a reason to turn ultra-doomer:
I can't stand it. Been reading the posts from today and I just cannot believe
the way things are going. Even worse, a lot of it is financial as if we are all
believing that there will necessarily BE an economy next year.
The real problem that I see is the embedded chips. Now, before the flamers out
there get their typing fingers all twisted up in an agony of anticipation, let
me point out that a very small percentage of embedded systems use date
functionality. HOWEVER, and it is a big one, a lot of those systems probably
*have* date capability, and in my 15 years of embedded work I saw any number of
systems which really had no need to be dependent on dates at all, in order to
accomplish their primary function, but which wound up with all sorts of bells
and whistles which did depend on the date functionality, simply because it was
there and could be used.
A Primer on Embedded Systems.
I don't know if anyone has ever set down exactly what embedded systems are or
how they work, in general. I haven't seen such a post. So I am going to leap
into the breech and provide one.
Embedded systems are those which have a controller chip of one sort or another
on a circuit board, inside of device, which control one or more of the
functions of the device. Simple enough. They are the chips which run hardware,
as opposed to *pure* software, of the mainframe, general pc environment, or the
distributed networks, which perform 'calculations', in all of their many and
There are, to my knowledge, 4 types of embedded systems, classifying them by
the nature of the controlling device. Two of these I have experience with.
These 4 types are:
1. Microprocessor controllers. These are full instruction set, standard
microprocessors, of the same genre as the one in the pc that most of you are
using to access this forum.
2. Microcontrollers. These are reduced instruction set, specialized function
devices. They are made *specifically* to control devices, hence the name. They
have instructions which relate to I/O ports, a feature lacking in the
microprocessor, as it has no I/O ports on board. These chips almost always
include on-board memory of both the RAM and ROM variety.
3. Programmable Logic Controllers (PLC's). These are a relatively recent
addition to the spectrum of controlling chips. I do not know a whole lot about
them, as I have never used them. The first mention of them I saw was in about
1993. I am not saying that there weren't any before that, just that they hadn't
blipped on my radar screen before then. My impression of them is that they are
microcontroller chips carried to an extreme.
4. Programmable Logic Arrays (PLA's). NOT to be confused with PLC's. The PLC is
a dedicated control device. The PLA is a Very Large Scale Integration chip.
It's primary use was to replace as many as possible of the digital logic chips
which were used to 'select' things or actions in circuit boards. I, personally,
wouldn't have thought of it, but apparently for EXTREMELY simple applications,
they can be substituted for a controller type chip. (My understanding is that,
if the control problem can be stated as a complex Boolean function, then it is
possible to use these).
I will not address numbers 3 and 4 any further, as they are not something about
which I know a great deal. My experience doing logic design as an EE many years
ago might allow me to stumble through PLA's, but certainly not PLC's.
However, having done a number of projects in a variety of fields, for a wide
array of employers, ranging from the federal government, the DOE, the DOD,
medical equipment, telecom, HVAC, and wireless companies, I feel qualified to
expound a little bit on the first two. (I know, I know, the only thing I bring
to the table is a 'self-reported' knowledge of these things, and 'How come you
won't post your real name, and ..... Did you ever hear of a 'Yellow Dog Clause'
in contracts? Does the term 'Non-disclosure agreement' ring any bells? And I
realize that all I have is 'experience'. Certainly doesn't make me the equal of
some of the self-proclaimed 'debunkers'.)
The primary difference between microprocessors and microcontrollers is that the
latter were *specificallly designed* to control equipment. The former get
'pressed into service' to control equipment. The former require other chips to
actually cause changes of state on hardware, heavy duty relays, I/0 chips, etc.
The latter have them built into the chip itself.
One of the distinguishing features, which is directly related to that primary
difference, is that, since the microcontroller was specifically designed for
the task, all necessary functionality tended to be built into the chip. The
ideal goal here was a single chip circuit board. This was a rare bird in the
real world, but it did occasionally come to pass. But it was the ideal.
What this means is that, while a microprocessor has its program stored in PROM
(Programmable Read Only Memory) or EPROM (Erasable Programmable Read Only
Memory) or EEPROM (Electrically Erasable PROM), the microcontroller chip has
its program in the on-board ROM (Read Only Memory). Now note the main
distinguishing feature here. One of these has multiple types of memory
available, all of which have the word 'Programmable' in their names. The other
does not have the word programmable in it. The implications here are important.
In one case, the chip can be reprogrammed by burning a new PROM and removing
the old one and inserting a new one, or by erasing the old one and
reprogramming it. In the case of the EEPROM, the hardware may have the correct
voltages and amperage to actually do the reprogramming on the board itself and
nothing has to be removed! In the OTHER case, reprogramming of the chip
involves removing the old one, throwing it away, and starting over. Read that
sentence carefully, understanding that the shortest cycle time for this
operation that I have ever seen was 18 (That is EIGHTEEN) WEEKS! And that was
for a very small scale application. A more normal cycle time for this type of
operation is about 12-18 MONTHS, depending on the complexity, size of staff,
operating budget, and test equipment availability.
Now, as I understand it, a truly impressive number of organizations are
planning on doing 'fix-on-failure'. If the above discussion doesn't make you
just a little queasy about this, try thinking what New York City, or
Washington, D.C., or any big city will look like after 18 WEEKS without
electricity or water, let alone 18 MONTHS.
I can already hear Flint saying 'But what makes you think they haven't replaced
those chips?'. Well, I don't know that they haven't. But I do know that there
has been no *spike* in demand for embedded designers. I do know that
distributed networking applications is paying better than embedded. I do know
that 3 former clients have approached me about possibly working on remediation
of code, but only in the last two months. And the pay rate was so low as to be
ridiculous. Keep in mind, they wouldn't be selling anything new, just making
what is already there work after the first of the year. So it is 'maintainance'
work, which is the lowest paying. Of course, in one case, replacing the chips
would be a neat trick, since the manufacturer left the chip business 6 or so
years ago. Which means that the entire system would have to be redesigned,
since the chips used had some truly impressive, and non-standard,
The fore-going discussion, while long, provides much of the background as to
why I am literally *terrified* about the upcoming roll-over. These are the
things that actually make physical equipment work. Some of it is vital (think
power companies, gas companies, water companies, etc), some of it is dangerous
(think helium liquefication plants, chemical companies, high speed, high torque
fans for air volume adjustment in HVAC), and some of it is just plain necessary
(think gas station pumps, medical devices, traffic lights, Command, control,
communication and intelligence for the DOD). And I have no evidence that they
are being corrected. I have no *evidence* to the contrary, in fairness to the
pollies, however, the problem I have is that there are some awfully obvious
cues that I should have seen, which would have strongly indicated that
something was being done, and these are not in evidence. At the same time,
there is some small amount of weaker evidence that nothing is being done.
As the man said, we report, YOU decide. (Fox news).
Me, I gotta go down to Sam's Club, they got a sale on rice and beans.
-- just another (anot...@engineer.com), October 27, 1999
(Much More follows)
"Overall, among the 552 Fortune 1000 companies making complete disclosure on
Y2K budgets and costs in their second quarter 1999 filings with the SEC..."