Dear All
The embedded chip problem is one that I think most people are only beginning
to become aware of.
As I think I mentioned in a post or two ago, I attended a meeting on
environmental issues and Y2K. At the meeting the President of the NSW
Computer Society said his society was asked to advise the Australian
Government of the various implication of Y2K on Australia. He suggested
that one of the objectives that the government should take on board was that
no person would die because of the Y2K problems.
This was some what startling to the people in the audience to suggest that
the Y2K problem could lead to deaths. He said that non-compliant embedded
chips would cause accidents and endanger the health and safety of workers.
This could be from oil rigs or chemical plants exploding to water supplies
being contaminated. The fact that many embedded chips are inaccessible and
the shear number of them means that they are impossible to fix or replace.
The recent gas explosion in Melbourne where the city was cut off from gas
supplies for 4 weeks and the Auckland power failure are examples of what
could happen. The Melbourne gas explosion was the result of human error in
the face of system malfunction. Two people died. Melbourne was entirely
dependent on one gas plant to provide heating/cooking for 90% of homes and
all restaurants/factories/hospitals.
Unlike some people who predict that people will revert to hording and become
selfish in adversity, the people of Melbourne rediscovered their neighbours.
People invited others over for BBQs and those with electric showers shared
with neighbours whose hot water was heated by gas. People who had hardly
spoken suddenly were talking about the common plight.
<<...>>
-----Original Message-----
From: Victor Milne [SMTP:[EMAIL PROTECTED]]
Sent: Friday, 19 February 1999 13:38
To: futurework; Thomas Lunde
Subject: Re: [GKD] Training Y2K Specialists
Thomas,
>From the reading I've been doing I think that Y2K is a much more
serious
problem with respect to embedded systems than with respect to
computers. Not
to say it isn't a very big problem with computers.
There is a very good article, long but not too technical, at
http://www.tmn.com/~frautsch/y2k2.html
>From it I gleaned the following interesting points about embedded
chips.
Estimates of the number of embedded chips in service range from 25 -
50
BILLION.
Only a small number, perhaps 1 per cent, will be affected by the y2k
date
rollover, those that have a timing function.
Many people do not realize that almost all chips used to control
timing have
a built-in date function. Even though the chip may be controlling
only a
simple process such as: Event A ... 15 milliseconds ... Event B, it
is
counting off the days on its internal calendar.
A chip's internal calendar may or may not be in sync with our
calendar. The
chips were usually given arbitary start up dates, something like the
date
manufacture of that model commenced, which could be something like
Se;tember
9, 1984. When the chip is first powered up, it sets itself to that
date.
This means that there are three possibilities.
The chip does have a date-monitoring function and was reset to
synchronize
with the calendar. These chips may fail at the rollover to the
millennium.
The usual example is the elevator which must be inspected every six
months.
On January 1, 2000 it will subtract a date such as 23/09/99 from
01/01/00
and get an error and shut itself down.
The chip was kept continuously powered up but only its timing
function was
utilized. Take our example of a start date of 09/09/84. Just to make
it
complicated suppose it was a replacement part that was not taken off
the
shelf and powered up until November 5, 1987. Starting at that date,
the chip
will take 15 years and 101 days to reach 01/01/00, which will happen
on
February 14, 2002. The author of the article cited above says that
he
expects "y2k" events to go on happening until about 2006.
The third possibility is that the chip is powered down from time to
time,
maybe frequently. That's why you don't have to worry about the chips
in your
car. You would have to run the car engine continously for years to
cause a
timing control chip to reach 01/01/00 on its internal calendar.
Anyway, as a repairman, you would appreciate that checking out
embedded
systems would mean first learning from the schematics of a machine
or an
industrial process where chips with timing functions are located,
having a
skilled technician remove the part with the chip on it and test it
for y2k
compliance and replace it ... if there is a replacement. There is
obviously
no quick way to swell the ranks of y2k trouble shooters as far as
embedded
systems are concerned. In some cases, it is virtually impossible to
access
the chip. An example that I've seen more than once: apparently an
offshore
oil rig has ten of thousands of embedded chips, many of them located
below
the waterline and encased in concrete. Incredible as it seems, it
will
probably be cheaper just to let this multimillion dollar
installation fail
and build a new one rather than to fix the old one.
By the way, just as a matter of curiosity, do new washing machines
use chips
to time the cycles or is it still just a mechanical timer?
Live long and prosper
Victor Milne
FIGHT THE BASTARDS! An anti-neoconservative website
at http://www3.sympatico.ca/pat-vic/pat-vic/
LONESOME ACRES RIDING STABLE
at http://www3.sympatico.ca/pat-vic/
-----Original Message-----
From: Thomas Lunde <[EMAIL PROTECTED]>
To: Global List <[EMAIL PROTECTED]>; Future Work
<[EMAIL PROTECTED]>
Date: February 18, 1999 8:03 AM
Subject: Re: [GKD] Training Y2K Specialists
>
>-----Original Message-----
>From: Thomas Lunde <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: February 21, 1999 4:19 PM
>Subject: Re: [GKD] Training Y2K Specialists
>
>
>>
>>Dear Henry:
>>
>>Thanks for your in-depth response. I guess what I hear you saying
is that
>>Y2K personnel are highly specialized and that there is no army of
>unemployed
>>that could be mobilized to provide manpower.
>>
>>Chris Reuss responded in another post:
>>
>>India has them, for instance. India is one of the main profiteers
of the
>>y2k
>>business. According to the Indian association of software
producers
>>(Nasscom),
>>India has y2k orders in the volume of more than 2 billion dollars,
and
>>demand
>>is still bigger than supply.
>>
>>Thomas:
>>
>>Now these two answers neatly bracket my dilema. Henry is saying,
as have
>>others, it is tough to solve and requires a broad range of
expertise and
>the
>>side effects of mistakes may be just as bad as the original
problem. On
>the
>>other hand, I get, it's already taken care of, it's no big deal
and by the
>>way, we can send the problem offshore to India as they understand
>>(apparently) all our languages and our networks and our business
models
>>better or at least as well as anyone in North America.
>>
>>Henry wrote:
>>
>>>- the changes to datebases I referred to earlier do not happen in
>>>isolation. Databases can be used by tens, hundreds or even
thousands
>>>of other programs and changes must be carefully planned and
coordinated.
>>
>>Thomas:
>>
>>Now I don't have to be an expert to understand this paragragph.
And it's
>>not hard to see how complex accessing data bases must be and how
difficult
>>it would be to fix if all that data got scrambled in some way.
So, it
>seems
>>to me that turning that over to programmers a half a world away
and
>trusting
>>them to solve it is the highest form of irresponsibility. After
they
>finish
>>the job, will there be anyone left on our side who can understand
all the
>>changes they have made or in the worst case, if they fuck it up,
do we
>still
>>have the talent to change it back or forward to a system that
works.
>>
>>Now, I'm sort of a simple guy who fixes washing machines for a
living.
>It's
>>not rocket science but it is amazingly more complex than most
would think.
>>It requires all the skills - diagnosis - which can often be wrong
-
>>replacement of parts - which may stress other parts of the system
-
>external
>>factors such as water pressure or wiring problems, etc and etc.
Though
one
>>can go through a 6 month or year course, I can assure you that the
variety
>>and complexity of the problems you can run into boggle the mind.
And this
>>is in a very simple system of electro-mechanical design. Because
I fix
>>broken things, I have a healthy respect for the difficulties of
even
simple
>>problems and I am far from re-assured about the confident tone we
are
taken
>>to this world wide problem.
>>
>>So, with great persistence, I'm still stuck at my original
question. Do
we
>>have the manpower with the expertise to do the job and if so, what
would
>>constitute proof? The fact that there does not seem to be much
demand for
>>Y2K specialists is very suspect given the amounts of money,
complexity and
>>variety of systems affected and the potential downside if we do
not get it
>>all fixed. It's easy to have opinions but I'm looking for a few
facts. I
>>have yet to read a little story of a complete Y2K fix. From
analysis,
>>diagnosis, repair, testing and final result in terms of manpower
and
money,
>>for even a small company or government dept.
>>
>>Respectfully,
>>
>>Thomas Lunde
>>
>>
>>
>>Subject: Re: [GKD] Training Y2K Specialists
>>
>>
>>>Good morning all
>>>
>>>I have been following the debate on training people to fix y2k
>>>problems and the apparent lack of success in doing this with some
>>>interest.
>>>
>>>It seems that once again we have people debating an issue about
>>>which they have only limited or theoretical knowledge.
>>>
>>>The reasons that it has not been possible to train droves of
staff
>>>are many and varied and in my view include at least the
following:
>>>
>>>- fixing the problem in most cases does not involve just changing
a
>>>few lines of code. In many cases database files must be changed
and
>>>output layouts modified.
>>>
>>>Since these outputs are in many cases very specific in nature,
fields
>>>on forms, data in EDI files, etc, care must be taken with every
change.
>>>
>>>- not all systems that will be effected are what might be thought
of
>>>as traditional business systems. Many are complex interrelated
>>>systems which cannot be changed in isolation. An understanding of
the
>>>whole process is very often required. With early programming
>>>techniques it was much easier to make changes to individual
>>>programmes, but that is not true any more.
>>>
>>>- the changes to datebases I referred to earlier do not happen in
>>>isolation. Databases can be used by tens, hundreds or even
thousands
>>>of other programs and changes must be carefully planned and
coordinated.
>>>
>>>- in the non business systems arena the problems are often much
more
>>>complex since the date field may play no critical role in the
actual
>>>function performed by the program but its correct handling is
key. I
>>>am thinking of equipment used to monitor and drive other
activeties
>>>such as Numerically Controlled Equipment, data logging systems
and of
>>>course the whole embedded system cess pool.
>>>
>>>- there is a huge number of programming languages out there. A
>>>single shop, my University for example, may use many different
>>>languages for example. For us Natural, Java, Basic, SAS, CSP and
a
>>>whole host of other less used such as Cobol, Delphi, Fortran, etc
are
>>>all required just to run the show. This excludes the databases
Adabas
>>>C & D, Sybase, SGLServer, ESSBASE etc.
>>>
>>>And then of course come the academic users with their
miscellaneous
>>>collection of tools.
>>>
>>>All of these run in a mixture of operating systems and hardware
such
>>>as our VM/esa and Solaris plus a host of MicroSnear operating
>>>systems.
>>>
>>>While I know that there is more Cobol code created every day than
any
>>>other language, the bulk of this is generated code. It cannot be
>>>fixed by working at code level, hence the lower than expected
demand
>>>for Cobol programmers, but must be fixed by people who understand
the
>>>business as descibed in the generation tool used.
>>>
>>>
>>>For anybody, and we looked at it, to train unsophisticated people
to
>>>do y2k fixing is just not on. The basic mechanical skills yes,
but the
>>>conceptual ones are much more difficult.
>>>
>>>Another, and I except rather paternlistic view, is that to train
>>>people as y2k fixers who will not later be able to develop into
full
>>>time programmers because of their lack of aptitude, is not
helpful.
>>>In fact under SA labour law it is likely to get an employer into
very
>>>serious labour problems.
>>>
>>>Anyway those are my pragmatic thoughts on why there has been
less
>>>success than anticipated in mass training, for what its worth.
>>>
>>>PS I don't know what happened to the Blair Initiative into mass
>>>training in the UK but I suspect it died quietly. Anyone know?
>>>
>>>Cheers
>>>
>>>Henry
>>>"The old Chinese curse appears to be upon us,
>>> we live in interesting times!"
>>>=====================================================================
>>>Subscribe to the IT Digest, an information resource from Wits
Univ.
>>>Send e-Mail to [EMAIL PROTECTED] with SUBSCRIBE
ITDIGEST
>>>and {your_user_id} in the body followed by END on the next line.
>>>----------------------------------------------------------------------
>>>Henry C Watermeyer 'Phone
+27-11-716-3260/8000
>>>Director - Computer & Network services Fax +27-11-339-1225
>>>University of the Witwatersrand, Johannesburg
>>>P/Bag 3, Wits 2050, South Africa mobile
+27-(0)82-800-8862
>>> //SunSITE.Wits.ac.za //WWW.Wits.ac.za
>>>======================================================================
>>>
>>>
>>>
>>
>
>
