I have seen various posts stating (in so many words) that the most serious Y2K problems we face are in:

Position 1: Software used for the business infrastructure Position 2: Embedded systems Position 3: A combination of the two

There are other positions of course, but the above seem to be the most predominant. I have done Y2K project work in both embedded systems and software, and continue to research actual findings of Y2K problems in embedded systems (I always go for the verifiable stuff only, manufacturers and model numbers required, and I have loads of data).

I would like to get feedback from those working in Y2K as well as those in the forum who have studied the issue. In your opinion, what ARE the areas of most concern? I have made it clear in previous posts that I am confident that we will have less than a bump in the road at the actual rollover (yes, a self-admitted "poly"), but that doesn't keep me from listening to what others have to say. This is a sometimes fiesty, sometimes friendly forum, I especially start to respect those here when I see posts like Forum Friends. I hate it when that happens, I don't WANT to respect you, lol! The more I come around, the more I like you "TTGIBDs" (Think They Get It But Don't) types.

Based on the response, I am open for a technical, fact based discussion concerning Y2K in embedded systems if anyone is interested (my short position based on the current facts in front of me - vast majority of Y2K bugs in embedded systems are minor, with serious problems being rare.) Let me emphasise that I am talking about a discussion, not a war, not to "win", but a respectful discussion, where we all learn something....:)

Regards,

-- FactFinder (FactFinder@bzn.com), August 29, 1999

Answers

Howdy FactFinder,

Before we get into this, if you are the same FactFinder that hangs out at euy2k, please allow me to thank you once again for your help in answering one of my questions there a few months ago. You may not remember, but I do...

Now, what is an "embedded system" ??? Isn't it just another computer? A CPU, a program, aka software (usually stored in ROM), working storage (RAM), and some sort of input/output?

Y2K is a software problem, no matter how you look at it. On the mainframe (my world) Y2K is a matter of how the OS deals with a hardware timer. The timer itself says "I know nothing" about a date, it's just a relative time, and it's up to the OS to break it down to seconds, minutes, hours, days, months and years.

Same on a PC. The RTC can be "faulty" in only having a 2 digit year, but a "smart" OS (aka BIOS) can figure out when it rolls.

An embedded system is just another program. What it does with dates, if anything, is up to the guy that wrote the program.

Tick... Tock... <:00=

-- Sysman (y2kboard@yahoo.com), August 29, 1999.

FactFinder

While I have no tech background, looking for good info is a pastime. Here is a link posted to assist in your investigation from the GartnerGroup. It was posted on August 16 and is the last public document they are publishing on the web regarding Y2K.

In it is an excellent update on the embedded systems problem and is highly recommended. In an unusual move I have provided the section dealing with embedded systems on another thread so the flow of discussion is not interupted on this thread. Hopefully it will provide insight of this part of the Y2K problem. Possibly others would like to contribute information on that thread and have the conversation on this thread.

companion document for "The "Real" Y2K Problem - Is it Embedded Systems or is it Software?"

-- Brian (imager@home.com), August 29, 1999.

A Qoute from the above link

"The decomposition of the embedded-systems problem into the three families  microcontrollers, microprocessors and LSESs  shows the futility of attempting to provide a percentage failure rate for embedded systems as a whole. There are tens of billions of microcontrollers, but only tens of millions of microprocessors and only millions of LSESs."

-- Brian (imager@home.co), August 29, 1999.

First of all, thanks Brian for posting the link to the Gartner document. It's a refreshing change to have something presented in a balanced manner as opposed to some of the hype from the likes of North & Hyatt.

With respect to the thread topic, "The "Real Y2K Problem - Is it Embedded Systems or is it Software?" which I will interpret for my answer as "will the impact be worse from embedded systems or will it be worse from mainframes/desktop computers?" I think that the answer is embedded systems. For example, an some types of embedded computer bugs could cause the failure to deliver power, water, or communications which under certain circumstances and if it lasts long enough and over a wide enough area would cause people to die. Going back to the Gartner Report example of the train, if such a failure caused two trains to be routed to the same piece of track at the same time people again would die. I believe that embedded failures are more serious even though the Garner Report shows an expectation of fewer embedded failures.

On the other hand, a mainframe computer failure at the utility company might cause billing problems. A problem of this sort could conceivably cause financial failure of the utility, but I thing the reality is that this is a class of problem that could be worked around.

An embedded system process occurs in real time and therefore more difficult for a human to correct and override (depending on what process is being controlled and the training of the human involved) and the consequences are more likely to be deadly. A mainframe process is typically occurs more slowly.

I'm sure there are exceptions to this. One such would be banking transfers. If the bug in the banking system causes money to be lost and the functioning of the economy stops, then we will have TEOTWAWKI and even more people will die than would from a train wreck or the failure of a local utility. I'm extrapolating from my experience a bit in this answer. I'd like to hear from an engineer or even a mechanic about the involvment of dates in an actual process. I'd like to know if the date is merely used for timestamping data logs or is actually used in the control of the process, and what the consequences of such a failure would be.

-- Mikey2k (mikey2k@he.wont.eat.it), August 29, 1999.

The real Y2K problem may end up being how the governments of the world decide to take advantage of the problem.

-- Ashton & Leska in Cascadia (allaha@earthlink.net), August 29, 1999.

Sysman, Of course I remember you, I run in to you from time to time in EUY2K. Thanks for your kind comments.

In your post, you make the following statement regarding embedded systems and Y2K: "Y2K is a software problem, no matter how you look at it."

I couldn't agree more. From my experience in assessing and testing both, programmers often use similar date algorithms, whether the programming is in computer software or embedded system "firmware". I have found many of the same types of y2k bugs in both. For example, I have seen the two digit format for the year 2000 displayed/printed as "1/1/100", for both software and firmware.

However I have also seen a number of differences: 1. Leap year handling - A lack of leap year handling of ALL leap years is quite common in embedded system devices, but not common in software/operating systems. Indeed, even today a number of PLCs and other devices are being shipped "Y2K ready" but that still require manually putting in the correct date on Feb 29, 2000 and future leap years. (Examples/links available on request but I will have to dig, some Allen Bradley PLCs, some Westronics digital recorders come to mind).

2. Severity of date problems - My own experience and additional research indicates that severe functional failures due to y2k bugs are very rare in embedded system devices, but common in computer software. A look at how dates are used in each reveals why this is true - embedded systems RARELY use dates in calculations. MOST software applications don't use dates in calculations either, but a lot of them DO - financial based programs, trending programs, etc.

Brian, a good quote you pulled out their. The classifying of embedded systems as microcontrollers, microprocessors and LSESs by the Gartner Group is a big step in an intelligent discussion of embedded systems, and the Gartner Group does a much better job as of late, compared to some of their earlier embedded systems nonsense. It appears that the Gartner Group has finally brought in some engineering/technical expertise rather than letting the IT types handle this issue, and the results are better.

Regards,

Regards,

2.

2.

-- FactFinder (FactFinder@bzn.com), August 29, 1999.

LOL, don't ask me where the "2" and double "regards" came from in the above post, they must have been hiding below the text box ;)

Mikey2k, you brought up some excellent points, I may have addressed some above, but specifically want to respond to this: "I'd like to hear from an engineer or even a mechanic about the involvment of dates in an actual process. I'd like to know if the date is merely used for timestamping data logs or is actually used in the control of the process, and what the consequences of such a failure would be. "

I have worked in nuclear utility's for many years in both electrical and instrumentation systems, for the first few years as a technician, and the last 20 in engineering. In this area, I have NEVER seen dates used to CONTROL a process, or even times from a date/time function used to control a process. Timing functions I am familar with are derived from the microprocessor timing functions (clock cycles) and not from the date/time RTC functions. Most lower level embedded system controllers have no RTCs, but some do. Most higher level SCADA and DCS systems do.

Now of course just as I make such a statement, we both know that programmers are wild men, lol, so you can bet that somewhere out there someone is using dates for control....but I do sincerely believe that this is rare. And I also caution that date function control could be used (and in my best guestimate, probably is to a limeted degree) in areas where I do not have expertise, such as building systems management, manufacturing (perhaps?), etc.

I have done research in the areas of Y2k effects in building equipment and management systems, medical devices, etc., and have found only a few cases of documented severe problems (ie, I have a manufacturer/model number).

One "myth" that I have seen (Frautshi, Gordon, "embedded system white papers")is the "maintenance" date "shutdown" due to the system thinking it has missed a required maintenance date upon reaching the rollover to Jan.1, 2000 ("00" ). This is nonsense, pure speculation that has no factual basis - this is NOT equipment vendors program their systems to do. (again, excluding that one programmer who may have went beserk).

I do want to thank you all for your thoughtful posts, I see some strong and logical thinking here, and hope I can contribute the same.

Regards,

-- FactFinder (FactFinder@bzn.com), August 29, 1999.