Read this information, I think the "secondary clock issue" will prove to be the biggest problem of all...stick with it and read the entire page...fascinating...If this has been posted before, sorry I just want to make sure that everyone gets a chance to read it.

http://www.webpal.org/Beach2.htm

-- BiGG (supersite@acronet.net), June 26, 1999

Answers

The "secondary clock" problem (a misnomer, by the way) was thrashed out on this forum weeks ago, but the best explanation of why it is not a problem is that offered by Peter de Jager in his latest article, "A Crock of Clocks," at www.year2000.com

-- Don Florence (dflorence@zianet.com), June 26, 1999.

Bigg:

Yes. Beach has been posted, but has drifted into obscurity unfortunatly. Sysman was to do some recearch into his thesis, but has been absent of late. I beleive that Beach is on to something, but has difficulty articulating the substance of this subject to lay people and professionals alike. It seems DeJager and others strike at the periferal points, and not at the substance as GN points out so eloquently. I have not worked at the chip logic level, but it seems that some thoughtful opinions have cropped up on this forum from time to time that warrants further study. It is really to important to dismiss out of hand.

I for one would like to hear more from Beach himself. Hope that he has not been too discouraged from the flak that he undoubtedly received.

Thanks for the post.

Bob P

-- Bob P (rpilc99206@aol.com), June 26, 1999.

Several people have "gone after him" in the past, Peter de Jager included...still think Bruce is right, and in all fairness he sure has a lot of people that agree with him...

-- BiGG (supersite@acronet.net), June 26, 1999.

P.S. This is not to say that there aren't some serious problems with embedded systems out there, of course--just not in the form (and probably not to the degree) that Mr. Beach suggests. I saw some data last fall from TAVA (which is doing remediation of embedded systems for various large corporations, including GM) indicating that they were encountering quite a few problems. QSS in the UK seems to be finding similar results, and there's general agreement that in the really large, complex embedded systems (process and safety control systems in the petrochemical industry, etc.) you can find failure rates up to 35% (no typo) or more. The good news, I suppose, is that remediators know that these are precisely the types of systems they had better focus on. The British pioneered much of this research; there was a study done for the British Office of Health & Safety (or some such name/agency) a couple of years ago that originally highlighted the dangers in the types of complex systems noted above.

Incidentally, the Institution of Electrical Engineers (IEE) in the UK is compiling a "casebook" of discovered problems with embedded systems. It's by no means exhaustive, of course, but it is intended to serve as a significant sampling of problems; the IEE notes the impact of each problem on the system itself and on the business as a whole (impacts range from "cosmetic" to "catastrophic"). I don't have the link handy, but as I recall, the IEE homepage is at www.iee.org.uk (or maybe www.iee.org/uk) There should be a link to the casebook from there. The most serious problems I noted while browsing involved some DCS and SCADA systems for certain types of petrochemical and mfg. plants, plus some railway transport and communications systems problems.

Harlan Smith, I think, has said that overall the embedded systems problem hasn't been as bad as originally feared but that it is still worse than we would like. That seems a fair enough assessment.

-- Don Florence (dflorence@zianet.com), June 26, 1999.

All in all, the stock market will crash due to irrational human fears. Once the selling starts, all Haydes will break loose.

No one knows when this will happen, but when it does, the SHTF!

-- Randolph (dinosaur@williams-net.com), June 27, 1999.

When all it will take in some cases, is just one or more well placed embedded systems...any happy face stuff is just panic control. Who gives a -bleep- what the % is, if it will only take a few embedded systems to 'run the boat ashore'. I've come to the conclusion that 'nobody really knows', and since 'nobody can see the future', this tends to make me feel the need to cover my backside. Which 'few' embedded systems will do the most harm? Let's start a pool, pick your industry or name that possible environmental accident...the closest call gets a years supply of ThyroBlock or 250 gallons of gasoline or a complete solar system or a lifetime supply of carpet fresh. Sound like fun?

-- Will continue (farming@home.com), June 27, 1999.

BiGG,

The fundamental problem with Beach's "Secondary clock" is that it is not a clock at all.

Excerpts from Beach2.htm (My italics)

4. An Improved Definition of The Beach Bug

Still, what needed to be more clearly stated is that the reason that the Secondary Clock is not visible is because it does not request or display a time. And I needed to go on and state more definitively, although I did show by examples, that there does not need to even be a RTC associated with the embedded processor, in order for the Beach Bug to be present. This has led to what is now perhaps a still better definition of the Beach Bug and the Secondary Clock. (And I look forward, with the help of friends and critics, to defining it still better).

The Beach Bug (Secondary Clock Century Problem) is a two digit Century Code problem, that is present in some embedded microprocessor Firmware Code and may be related to RTC usage, but can also be present without a RTC.

(snip)

How the Beach Bug is created

There are various mechanisms by which the Beach Bug may have been initially introduced into a system.

1. The main mechanism discussed in the original presentation was that the clock access can be programmed into a program stored in a ROM or EPROM. The documentation of this fact may be lost in a hierarchy of "black boxes" that are assembled into larger and larger integrated systems. Thus it is that some device may give no indication that it is using a RTC but it may nevertheless be.

2. Similarly, there are programs developed for ASICS, (Application Specific Integrated Circuits) that have their own RTC built in.

3. There are microprocessors that have their own RTC built right into them. For a sample list see:

Motorola Chips that are not Y2K compliant

4. There may be programs in any of 1 or 2 above that access RTC,s in external systems of which they are a part.

5. The embedded processor may just be repeatedly capturing date information from a data stream with which it associated and may be processing that data without ever accessing a RTC.

End of excerpts.

The bottom line is that he confuses clocks with program code that processes date and/or time information. Such program code does not constitute a clock of any kind, secondary or otherwise. Such program code can indeed have Y2K problems, but when it does, it is simply another instance of the Y2K bug, not some newly discovered kind of clock.

The ambiguity of his terminology in his April 9 paper led some readers to guess at what he meant, and some may have expressed support of what they guessed that he meant. Beach2.htm quotes "supporting" comments, but it is clear that those comments to not resolve his confusion between clocks and program code that processes date and/or time information.

Jerry

-- Jerry B (skeptic76@erols.com), June 27, 1999.

I found a website for that TAVA information on embedded systems mentioned above: www.prepare4y2k.com/embed1.htm There's also a link to it from the International Energy Agency's website, which is at www. iea.org The IEA (a UN agency, I think) has quite a bit of good stuff on Y2K and global energy concerns; there have been snippets of IEA material posted on this forum in recent days.

The TAVA report (from August 1998) goes into fairly good statistical detail about the kinds and numbers of serious embedded systems problems being found in TAVA's remedial work for four very large U.S. corporations: an oil company, a pharmaceutical, a beverage company, and an auto mfgr. For reasons of confidentality, none of the companies is named, though I happen to know from other reports that the auto mfgr. is GM.

-- Don Florence (dflorence@zianet.com), June 28, 1999.

Quote:...the closest call gets a years supply of ThyroBlock or 250 gallons of gasoline or a complete solar system or a lifetime supply of carpet fresh. Sound like fun? ...Endquote.

Will continue, If I win can I have the Eridani system? It would be great fun to own the Vulcan solar system, though I imagine they would not recognize my 'deed.'

:-)

-- J (jart5@bellsouth.net), June 28, 1999.