Continueing this from http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001A1t

**********

OK Cherri,

I guess we agree on what an "embedded system is? I'm no ES expert, but I have been playing with all kinds of DIGITAL computers for the past 3 decades or so, esp.with ASSEMBLY language. So, I guess I've got a few more "minor" points:

"The main reason for this is that it takes up a lot of memory to write the booleen algebraic equations for seconds up to years, leaving little room left to program the chip for the desired function you attempting to accomplish."

Come on now Cherri, what does it take to "count and compare?" Let's make it easy, and assume that we have a "clock" that generates an interrupt every second. Do you think the following (x86) code would work, to update seconds, then minutes?:

WAIT: NOP ; wait for interrupt

INC SECONDS

CMP SECONDS,59

JL WAIT

MOV SECONDS,0

INC MINUTES

CMP MINUTES,59

JL WAIT

; DO THE SAME FOR HOURS, DAYS, MONTH AND YEARS!!!!!

This only generates a few bytes of program code, next to nothing, hardly a dent in the space available on the ROM. Next point:

"To provide accurate date-time you need a source that would keep "time" in a reliable way otherwise the function would be moot. That means the "black box would also have to contain a RTC, BIOS and a Battery, as well as an external source of power."

First, we don't need a RTC since the above code EMULATES a RTC.

Second, the BIOS is OUR PROGRAM that is contained in the ROM. We are the BIOS.

Now, lets talk about the battery, and the external power. I'm in a bit of a rush, and don't have time to locate the link in the archive. We had a post about a SOLAR POWERED WATCH, that was placed in a dark drawer for 30 days, and it kept perfect time. It had NO BATTERY. but a CAPACITOR was charged by the TINY solor array, that kept the watch powered in the dark. Yes, a capacitor is just like a battery, it stores juice. A capacitor is a very common component, maybe more common than a "chip."

So what do we have in the "guts" of the watch? A very tiny DIGITAL circuit, that takes a TINY amount of power to keep it running, and it is VERY accurate. Do any "embedded systems" use such a clock? I don't know, I'm not the expert. I sure can't think of a reason why not. Next point:

"The black box if totally independant of an external computer would have to had the time and date set upon initialization. In my research with semiconductor manufacturers, I have found that they do not do this at the factory for many logical reasons."

Another, less common component is NON-VOLATILE RAM. This is a special kind of RAM that remembers it's contents when power is lost (maybe we can't keep the watch in the drawer for 60 days...). When power is restored, it picks up where it left off. This is important when "sequencing of transactions" is important. Do any "embedded systems" use NV-RAM? Somebody sure does, but I'm no expert..

This is what our old friend, BRUCE BEACH is about. Is he an "expert?"

Any comments, Cherri? <)=

-- Sysman (y2kboard@yahoo.com), July 30, 1999.

The above should have read:

Do any "embedded systems" use NV-RAM for timer or "clock" storage.

Are you out there, Cherri? <:)=

-- Sysman (y2kboard@yahoo.com), July 31, 1999.

Sysman, yep but I'm getting ready to take a nap.

-- Cherri (sams@brigadoon.com), July 31, 1999.

Can't blame ya for the nap Cherri, going to do the same, this heat and no rain sucks...

Maybe one of our other "pollys" would like to discuss this. Flint, you're a "chip" guy? Hoff maybe, or are you stuck on "aviation?" Doomers@suck.com?

Come on folks, this is the start of my reply to BRUCE BEACH. Am I nuts? Is Mr. Beach nuts? Is Cherri nuts?

Or is it all hype??? <:)=

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

Sysman:

OK, I'll do my best. I've written a lot of this before, you know.

(1) Your example is correct, it's quite possible to keep track of time without some RTC function. Indeed, most low-level embedded programs do just that for a variety of purposes. Far fewer of them keep track of real, calendar time (synchronized to the outside world) since there is rarely any need to do this. Those that do generally require some method of resynching, since those crystals aren't all *that* accurate. An RTC itself passes muster if it gains or loses less than about 2 minutes a day. But that's a day off every 2 years, so some outside update function is required if the time needs to be synched with real time. And if such a sync function isn't required, then it isn't real time after all, it's just a timer.

(2) Your example is fine, I've done this myself. But you will notice that there is no y2k error in it! Typically, to introduce such an error your code must store time values as binary coded decimal (why?), then allocate a single byte for each field (normal enough), then initialize all these values to real time (implying some method of setting the time, required as discussed above), then ignore overflow of the year byte, then create code that assumes that such overflow can't happen! Finally, when overflow does happen and is mishandled, the device needs to misbehave in some way that seriously compromises the application it's used in.

Now a couple of observations here. To find embedded systems where all of these things are true, you must eliminate all but a very small handful of systems. Very small. The vast majority of embedded systems don't keep track of real, calendar time at all, since there's no reason to. They use simple timers.

Of those systems that *do* something with the date, as opposed to just keeping track of it, this functionality is rarely burned into the microcontroller or other ROM space. That would be the wrong logical level in almost all remaining cases (which was a small total number to begin with). This is NOT to say that improper function due to date mishandling isn't part of the "system", it just happens at a higher level.

(3) Most of the misunderstanding about the dangers posed by embedded systems are based on one or two sources of confusion. First, people tend to equate what is *possible* (as in your example) with what is actually *done*. This is a simple error to make. As I said, it's a rare system that keeps track of calendar time at all.

Second, there is a real problem defining an "embedded system" at all. These tend to be layered as used in sensitive applications (I'm not talking about your VCR here). As an example, think of an ABS braking "system". Each wheel has a wheel control "system" (consisting of sensors, servo mechanisms, a microcontroller, etc.) That's an embedded "system". Now, each wheel system reports to a vehicle-level braking system that 'knows' about each wheel. At this level, we find logic to prevent swerving due to differential friction coefficients at different wheels. This system in turn reports to a subsystem that, for example, handles wheel control generally -- braking, differential, alignment, whatever. Finally, this subsystem reports to a master system that handles all aspects of the vehicle. And perhaps you could throw in the diagnostic system used by the mechanic to query and update each vehicle's system.

The purpose of this example is to emphasize that in most important cases, there really isn't any good place to draw a line and say, *this* embedded system is everything within *this* circle. As the circle becomes larger, of course the number of actual chips within it grows. At the chip level, y2k bugs are vanishingly rare. At the highest levels (the "assembly line system", for example), you are talking not only about millions of chips, but about networks of servers running custom applications handling thousands of tasks being performed by tens of thousands of pieces of machinery.

At this "highest" level, it's not at all surprising to find 30-40% of "systems" have y2k issues. But people confuse the incidence of issues at this level with the incidence at lower levels, so I've seen people claiming that 30-40% of "embedded chips" have y2k errors, and there are 50 billion chips! This is a logical and semantic problem, NOT an accurate assessment of what we're facing.

As a footnote, there was a thread not long ago asking me to respond to Cory's challenge. In that thread, I spent some time explaining why embedded errors are less "contagious" than IT errors. I won't repeat that here, but it's another aspect of this same issue.

-- Flint (flintc@mindspring.com), August 01, 1999.

Flint, Thanks for explaining it as you did (I am NOT good at explanations>. As for the crystal ascillator, there is usually a capacitive/reactive , well a cap and a coil that is used to refine the frequency to a tighter standard. But as you say, it is difficult to make the crystal exactly as you need it. In larger systems (Yes mainframes - my first experience with a RTC) there is more physical space to put the hardware that can keep the ctystal more accurate. Thank you for helping to explain that there are not chips out there with "hidden" (unknown) clocks (as in hour/day/year) that will fail because they were put in systems that did not "use" the clock but it would keep time anyway and fail on the roll-over, or sometime after because it was started (again unknowingly) when put into some system. Such as a washing machine.

The distinction between an "embedded chip" and an "embedded system" is something I have been trying to show people for over a year now.

A lot of the examples that people are giving of "embedded system" problems comes down to the software running through the system, in the form of a program as apposed to what is "burned into" a programmable device. Yes these problems exist and yes they must be be found and fixed. But it is important for people to understand that every electro-mechanical or even every digital device does not have to be physically tested.

I know without even looking at my table lamp that it does not and will not have a Y2K failure. If there is a power failure at my local utility and the lamp does not work, it is still not the fault of the lamp- it is the fault (lack of power) from the utility. Just as it is not the fault of a chip if the software going through it functions in a way to cause a Y2K error or failure, the fault origionates at the source of the software-the program.

Bruce Beach does NOT know what he is talking about.

One thing that scares people who do not know about "chips" is if they see a diagram or pinout and see the CLK pin. They assume it has to do with time and date. They do not understand that it is what "steps" the bits (voltage) through the chip.

-- Cherri (sams@brigadoon.com), August 05, 1999.

Wow, what an educational thread. Brain-ache central calling :)

It occurs to me, as we get further and further into this issue, that a minor contribution from my un-technical self may assist in illuminating a little "big-picture" perspective to this debate, particularly as it applies to the layman.

On late-night TV the other night, (which over here consists of educational programming, mostly output from the Open University), a documentary was running for a post-graduate technology course. The programme was dealing with certain issues involved in the integration of technology into real life scenarios. It was particularly interesting when viewed by someone with a degree of Y2K interest, although the topic was not touched on directly. A few of the statements by some of the egg-head experts did give me pause for Y2K related thought though.

Principally, the part which caught my eye was a technical discussion of the safety, accuracy and fallability of computer programmes when applied to life-critical applications in the real world. Principally, the discussion dealt with the issue of software, but the general message seems to be appliccable to hardware concepts also.

An example was given of a piece of medical equipment, namely a 3 part multi-purpose scanning device, incorporating a low-intensity electron- beam scanner, coupled with an X-Ray device, and a light-sensitive scanner. The software was written so that a patient could be located on the scanning table and positioned accurately using the light- scanner (which uses no accelerator beam and is therefore 100% safe)> The software was then designed to rotate the patient on a turntable, to place them accurately in front of the low-intensity electron scanner, where they received a scan. Finally, the turntable was moved again and the patient would be X-Rayed. Take into account that the X- Ray device is the most dangerous, as it uses high-intensity accelerated beams, and if used wrongly can harm the patient.

Despite extensive logical testing in the lab, the software proved glitchy. In some cases it wrongly positioned the patient in front of the wrong device, and then sent the intensity setting to that device based on where it *thought* the patient was, and not where they *really* were. This led to some patients receiving an electron scan at X-Ray intensity. This is a BAD idea. The system was decommissioned and the software re-written. There were other examples.

Commenting on this, an eminent professor from the OU stated that . .

{quoting loosely) "Computer systems are rarely, if ever allowed to operate without a practical level of human participation and intervention. Where such systems ARE permitted, their function tends to be deemed non-critical to life-supporting processes. In most cases of computer related failure leading to injury or loss of life, the fault can be traced to a degree of human error in the supervision or intervention in the process" {this kind-of echoes what Cherri was saying about people not bothering to check mechanical valves etc)

Basically, the concept being that people should not "trust" computer systems to perform perfectly every time. Thats not the way they are designed, and few designers or engineers would attempt to claim a 0% failure rate for ANY system. The prof actually went on to state that . .

"In any computer software program or application developed nowadays using modern, complex programming languages, it is generally accepted as an engineering principle that some kind of informational error will occur within the data at least once in every 200 instructions."

The point being that this kind of error rate is absolutely acceptable, because systems are designed to incorporate a degree of tolerance of inevitable minor errors. Furthermore, it underlines the fact that all modern systems are designed with just this kind of tolerance in mind. This explains the need for human participation in computerised processes. Even the engineers and designers know that nothing is ever 100% perfect.

This all sounds like support for the position that Y2K errors have the power to destroy the systems we use and benefit from today, but in fact it's just the reverse.

Bearing in mind that most, if not all computerised processes operate with a "1 in 200 instruction" error rate tolerance (or worse), how can we argue logically that one more source of data error could cause irrevocable failure ? If computerised systems are designed to be checked, monitored, and maintained by human beings NOW, that suggests to me that most if not all Y2K-based errors should fall within the remit of this safety sequence, and it is only in circumstances where the human factor has been irresponsibly removed from the process that we face a real risk to the continuity of service. This kind of in- built lack of the security of human intervention it seems would, in the industry's own rule book, represent the unneccesary imposition of an irresponsible risk.

Bizarre isnt it, that information pertaining to the inevitable and inherent imperfections, fallabilities and unpredictabilities of complex computer systems can actually make you feel SAFER.

I hope all this was in some way relevant.

Kindest Regards

W

-- W0lv3r1n3 (W0lv3r1n3@yahoo.com), August 05, 1999.

Wolfe, You nailed it exactly!

" Bizarre isnt it, that information pertaining to the inevitable and inherent imperfections, fallabilities and unpredictabilities of complex computer systems can actually make you feel SAFER." I hope all this was in some way relevant. 20 years ago while working at the Lazy B, they were developing the 757 and 767. They were adding a lot of digital equipment. I literally had a vocal tissy fit asking how they could allow such unreliable devices (those containing chips) to have control over something as important as flight. Knowing first hand and with decades of hands on experience that some "IC's (not even embedded ones) can fail from a stray bit of static electricity. It was explained to me and shown to me, physically, that the only digitally computerized systems were there as a convienence, to help piloting the aircraft easier, and would in no way replace the physical harware and instrumenttion that ran and flew the aircraft. Just over a year ago I joined Peter DeJagars mail-list and there was a lot of speculation about aircraft falling out of the sky. IKnowing exactly how they fly and what equipment does what, I jumped in and stated that they would not, could not and will not fail due to Y2K. There was a lot of discussion from a lot of different people giving opinions and what if scenerio's, all of which I answered with facts. I contacted a few "old friends" (I no longer work there) and got the word to them about the speculatation. I was not allowed to say anything about what tests were done or where they were in double-checking for Y2K butapon verifying what I knew, posted this: I am stating that no Boeing Aircraft will have problems due to Y2K. A few months later Boeing and the FAA made public Statements Stating the same thing. The point I am trying to make is the one you wrote so well :o) That although the digital age is great for information technology, it does not replace physical harware that we have depended on for centuries. Water works depend on valves, pressure and physical hardware. Electricity depends on the physical generation of power, voltage regulation, high voltage transformation to lower voltages until it gets to the transformer that feeds your house at the correct voltage and frequency. Power plants use harware to generate electricity, but from basic common sense they will not depend on digital computing for more than superficial uses much the same as an aircraft. Timestamping, measurement tracking, usage tracking etc can all be done by dgital computers, but are not necessary to produce the electricity itself. Or for more than a user friendly way to monitor safety and running the plant. The workers can sit and look at computer screen and monitor the equipment. That is convenienct. But the same equipment that they are monitoring is still monitored by the physical-hardware guages that have always been used. So if the computer monitoring is unavailable, the workers just do what they have always done (before the computer) and walk over and look at the guages etc. NOTHING safety wise is left strictly to computers. That is why nuclear power plants systems fail in the safety positions. The equipment runs with the safety "interlocks" held in the energised position (it takes power to keep them in that position) so if there is a power failure the voltage loss causes the interlocks to de-energise and close (in the safty position). You are correct in realising that because of the nature of digital computing (and embedded systems) of its tendency for failure, that critical functions are never left strictly to their use.

Unfortunatly, as has been seen in the fuel pipeline failures reciently, people are becoming complacent and less responcible when it comes to the physical hardware. What goal does someone in highschool have for their future these days? Computing. How many highschool students are encouraged to go into the fields of physical mechanics and hardware? not many. How many people want to take the time and use the mental work it takes to learn these (once common) things? Not many, it is easier to take some cources in "information technology" and make big bucks playing with pre-written programs. They don't know "how" the software works, nor do they care. If the teacher in this field and schools teaching it were so "brilliant" then why did NONE of them realise the potential for the Y2K problem? Because it does not take much thinking to be an IT. They are not brilliant. Hell even Bill Gates is rather dumb. Lucky, but dumb. He had motion etectors put in his "computerized mansion" to turn the lights off and on, so what happened? Heh Heh. Every time he turned over in bed the lights came on. DUH~~ The glut in IT and the falacy of the talent it takes to be one is now being exposed. Who was origionally called in for Y2K remediation? IT's. Guess what? After they went through their little routine (learned in college) on how to "milk" a job for all the money and time they could get away with, they had to turn to the people who did the real work in Information technology, the programmers. Big business learns real fast, especially where the bottom line is concerned. They also communicate with each other. They learned that their people in-house, who knew their systems, were the ones they needed to use to fix their Y2K problems. And what were many of those Y2K problems they needed to fix? Except for legacy systems, the problems that had to be fixed were those systems put in place by the "so called brilliant" IT's they had hired in the last 10 or so years to work for them. There was absolutly no reason for any of those Y2K problems to exist in the equipment and systems put into place in the last 10 years. Micro-doft and Silicon Vally are responsible for producing COTS that were non Y2K compliant simply because, although they could write all kinds of nifty doftware, they lacked the basic understanding of "how" it actually worked physically on the machines. They did not have the knowledge to "see" the problems they were creating. The days of "recient college graduates" walking out and making a fortune is over. They have been exposed for what they really are. They have cost the businesses and governments of the world so much money and problems beause of Y2K that they will never again be accepted without proving themselfs. Who will be the big money makers - job wise in the next century? Those who have the talant and training and brains it takes to run those things that no one wants to learn today. The people who understand and know what to look for in water work valves and flow systems, Those who know how to operate, troubles shoot and repair harware systems in the physical infrastructure. Compare today with 20 years ago. How many people in their teens and twenty's know how to fix a simple thing in their cars engine? How many even have the basic understanding of the way a car works? How many people in that age group know what a circular saw is, much less could use one? Do they know how to prevent the kickback ? How many would loose their hands or legs if they had to use one today? How many teens or those in their twenties know where the starter is located in their car, much less how easy (and cheap) it is to replace one? A lot of peope see the split between those in the "high technology (and pay) fields and those who do not understand or use computing? The posibilities in computing are infinate, in information technology are finite. It will be those who know the physical sciences as well as computing that have the future open to them. Gee, I went on a tangent on this post didn't I *grin*.

-- Cherri (sams@brigadoon.com), August 06, 1999.

-- Cherri (sams@brigadoon.com), August 06, 1999

Answers

Very good information folks. Thanks!

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

I agree with what you basically said.

Would it not be fair to say though, that the more complex and/or dangerous/inaccessible a system is the more likely it is to have embedded processors that do care about the date?

The more regulated an industry for saftey, enviroment government system or other reason the more likely it is that the date will have some critical importance. At least this is true in my experience.

I feel very confident that any micro processor having to do with appliances in my home will not be affected by a date problem. And if it did then it would only be a minor probem and only for me.

In large complex system however, the is a exponentially greater chance of a system failure (based on the large number of chips and depending on how critical they are to the system). In my experience failures often occur of the silliest reasons and usally now what you think of first.

So it would seem to me that the most critical systems are the ones that are most prone to failure.

-- John Beck (eurisko111@aol.com), August 06, 1999.

Good information----NOT!!!

What a bunch of techno babble, congratulatory, myopic, condescending,words. Read it all--unfortunately---what a pat on the back--atta boy!! we got it all figured out. Why don't you form a little club of great brains!

Quotes: They learned that their people in-house, who knew their systems, were the ones they needed to use to fix their Y2K problems. And what were many of those Y2K problems they needed to fix? Except for legacy systems, the problems that had to be fixed were those systems put in place by the "so called brilliant" IT's they had hired in the last 10 or so years to work for them. There was absolutly no reason for any of those Y2K problems to exist in the equipment and systems/"

You almost had me convinced there was or is no y2k problem! Cherri, who do you think will read this novel

-- David Butts (dciinc@aol.com), August 06, 1999.

From the Embedded Syatems Faults Casebook at the Action 2000 site. (Action 2000 is the official British government site which has been accused by its former director and others of not being "doomer" enough.) There is lots more information (on embedded systems and other Y2K matters), at the site.

http://business.bug2000.co.uk/steps/systems/

Equipment Type: Access Control Application

Type: Card access control system for site and internal departments

Sector: ALL

Description: System fails at rollover. Access barred.

Solution: Replace

Consequences: Security system inoperable. Additional manning required.

Equipment Type: OTHER

Application Type: Car Park Management System

Sector: ALL

Description: Dates after 31/12/99 not handled correctly

Solution: Replacement of hardware and software

Consequences: Loss of revenue, lack of car-parking causing traffic congestion, safety - if car park egress not possible or restricted.

Equipment Type: Access Control

Application Type: Site-wide building access control and security system Six connected controllers, at various site locations, controlling a network of card readers and keypads (supported by modems etc), printers and visual display terminals.

Sector: ALL

Description: The control panel will rollover correctly from 28/02/00 to 29/02/00. However, if 29/02/00 is entered manually, it will default to 01/02/00.

Solution: The access control software will be upgraded and the control panels replaced.

Consequences: Nuisance, but may cause regulatory problems. Access to restricted areas may be controlled using a manual, paper-based system. However this is expensive and time consuming.

Equipment Type: Fire Control

Application Type: Fire Alarm Panel - sounds alarm when triggered.

Sector: ALL

Description: Date advances from 31/12/99 to 01/01/100. Critical date 01/01/2000.

Solution: Client informed. Does not affect operation of system, only reporting.

Consequences: Equipment Type: HVAC

Application Type: Air Conditioning/Heating Controls

Sector: ALL

Description: Loss of control of HVAC system. Critical date 01/01/2000.

Solution: Upgrade software. Manufacturer supplying free upgrade.

Consequences: Potentially catastrophic.

Equipment Type: HVAC

Application Type: Controller with logging capabilities.(Outstation)

Sector: ALL

Description: Potential loss of historic data. Critical date 01/01/2000. No affect on control operation.

Solution: Download the data prior to roll over.

Consequences: Equipment Type: HVAC

Application Type: Controlling & Monitoring. (Outstation)

Sector: ALL

Description: Loss of control of Air conditioning. Critical date 01/01/2000.

Solution: Replace microprocessor/ Replace equipment.

Consequences: Potentially catastrophic if A/C does not function in communications areas.

Equipment Type: Stand Alone Instrument

Application Type: UPS- Uninterruptible Power Supply.

Sector: ALL

Description: Loss of remote data/ alarm logging. Critical date 01/01/2000.

Solution: Upgrade microprocessor

Consequences: If external monitoring is utilised, may be catastrophic.

Equipment Type: Fire Control

Application Type: Fire alarm control panel - sounds alarm.

Sector: ALL

Description: Fire alarm malfunction on rollover- alarm raised. Critical 01/01/2000.

Solution: Software upgrade.

Consequences: Would lead to building being evacuated.

Equipment Type: Logging / Monitoring

Application Type: Water leak detection.

Sector: ALL

Description: Non reporting of leaks / fire alarms. Potential false alarms. Critical date 01/01/2000.

Solution: Upgrade microprocessor.

Consequences: Non reporting of leaks could cause major damage with long down times. False alarms would cause systems (e.g.. air conditioning) to be closed down- potentially catastrophic if supporting Comms room.

Equipment Type: Building Mgmt Sys

Application Type: BMS

Sector: ALL

Description: The system will operate correctly through the millennium rollover if the system remains powered. If the system is powered down, however, the date will revert to XX/XX/1900

Solution: Upgrade/ replace equipment.

Consequences: Potential failure of air conditioning/ heating system, security systems etc.

Equipment Type: Fire Control

Application Type: Fire Alarm Panel.

Sector: ALL

Description: Does not recognise year 2000 as a leap year. Critical date 29/02/2000.

Solution: Manually change date on 1st March 2000.

Consequences:

Equipment Type: Access Control

Application Type: Intruder Panel

Sector: ALL

Description: Does not recognise leap year, hence date becomes erroneous. Critical date is 29th February. This problem is experienced every leap year.

Solution: Correct date on 1st March. (As will have been done in previous years)

Consequences: Incorrect date logging.

Equipment Type: Logging / Monitoring

Application Type: Data Tape Recorder.

Sector: ALL

Description: Critical date 01/01/2000. Solution: Software upgrade.

Consequences: Equipment Type: Building Mgmt Sys

Application Type: Swipe card system- Access control.

Sector: ALL

Description: Will not allow access from 01/01/2000. Critical date 01/01/2000.

Solution: Both software and hardware upgrades maybe necessary.

Consequences: Will cause significant inconvenience to business.

Equipment Type: Building Mgmt Sys

Application Type: Fire Alarm Panel.

Sector: ALL

Description: System crashes on rollover, can be reset in year 2000, but doesn't recognise leap years. Critical date 01/01/2000.

Solution: Replace equipment.

Consequences: Building is left unprotected if system is not reset immediately after roll-over.

Equipment Type: Fire Control

Application Type: Central fire alarm monitoring

Sector: ALL

Description: Clock will revert to1900 with power switched on. Will not recognise leap year. Current day /time incorrectly displayed. Elapsed time fault monitoring functions may not recognise genuine fault during transition 1999 to 2000

Solution: No fix available. New unit purchased.

Consequences: Inability to remotely monitor in-plant/office fire alarm systems. Could be even more critical if process systems fail etc during rollover and manning will also be minimum during this period.

Equipment Type: HVAC

Application Type: Package Boiler Control System local and remote

Sector: ALL

Description: Hardware and software

Solution: Solution not yet known as manufacturer not now in business

Consequences: Failure would result in no bulk oil supplies to a major works as steam is used to preheat heavy oil for distribution (5 x 10,000 tonne tanks pumped at 50t /hour)

Equipment Type: Building Mgmt Sys

Application Type: Building Management system and Lighting Management system

Sector: ALL

Description: No problem experienced - non-compliance issue picked-up before problem arose. Interface between BMS and other building systems it monitored/controlled.

Solution: Upgrade of software and PCs, patch for operating system Contingency includes introduction of manual over-rides for plant

Consequences: Not catastrophic but seriously inconvenient in term of efficient monitoring and control of the building systems

Equipment Type: Fire Control

Application Type: Fire control

Sector: ALL

Description: No problem experienced - non-compliance issue picked-up before problem arose. Graphic History software and PC non-compliant. Operating system non-compliant

Solution: Upgrade of software , operating system and PCs

Consequences: Not catastrophic but lack of enhanced graphical presentation of location of fire and fire alarm history would have an effect on the management of this safety element

Equipment Type: Building Mgmt Sys

Application Type: This is a building (energy) management system (BEMS) and comprises a master (communications unit) and a number of slaves (control units). The master is connected to each slave by means of an RS485 link and each slave controls various analogue and digital devices such as boilers, air-conditioning units, chillers etc. by means of an interface board. Depending upon the nature of the item controlled the board may be either analogue or digital. Programming the (master) communications unit is accomplished by means of, say, a hand-held unit or PC connected to the unit via. an RS232 link. The control units contain a keypad that allow them to be programmed with times and dates, type of functions to execute etc.

Sector: ALL

Description: As dates in the next century cannot be set, date-based functional tests cannot be carried out. Therefore, any problems that may be caused by this situation will not be known until the next century.

Solution: The inability to program post-year 2000 dates into the control units creates a dilemma: 1) Just because the firmware prevents post-year 2000 dates from being programmed into the control units does not mean that the units are not compliant. Therefore, the question arises "is it worth changing firmware versions just to allow post-year 2000 dates to be entered (for testing purposes)?" 2) If the units are non-compliant how will problems manifest themselves? The solutions are: 1) Do nothing but develop contingency plans. 2) Replace the entire system. This is unlikely given the cost of the system and the extent to which the system has been integrated into the company's infrastructure.

Consequences: The BEMS controls many items that improve the working environment, for example, air-conditioning and heating units. Should these fail, working conditions may become unbearable during the summer and winter months respectively and perhaps breach HSE regulations.

Equipment Type: Fire Control

Application Type: The system is a fire detection system not connected to the local fire brigade. It comprises a number of outstations, fire panels with battery backup connected to two 80486-based computers by means of an RS485 link. Both the computers and fire panels contain history logs.

Sector: ALL

Description: Centralised PC failed to auto-roll into millennium. Also, 1 model of fire panel refused to allow leap-days to be set. The problem with leap-days was already known to the manufacturer as being caused by the version of the firmware - there is no current solution available. The critical dates are 01.01.2000 and all leap-days.

Solution: There are two solutions: 1) The computers. These must be replaced with compliant alternatives. 2) The fire panels. The solution for these is "do nothing". However, care must be taken to ensure that there is no need to manually set the date to the 29th February .

Consequences: Possible legal implications if fire were to occur after date corruption had entered the system, for example, no history log.

-- Old Git (anon@spamproblems.com), August 06, 1999.

When you add to the above list of faults the following article, you can say, "London, we have a problem." http://www.telegraph.co.uk:80/et?ac=000154642417163&rtmo=pQsbINle&atmo =99999999&pg=/et/99/8/4/nbug04.html

ISSUE 1531 Wednesday 4 August 1999

Ignoring Millennium bug 'puts jobs at risk', By Robert Uhlig, Technology Correspondent JOBS are at risk because a "hard core" of Britain's small companies are failing to take action against the Millennium bug, a Government adviser has warned.

Gwynneth Flower, managing director of Action 2000, said: "This could be the downfall of British business, this lack of perception of the risk shows a worrying short-sightedness." The hotels and restaurants industry was particularly at risk, and Ms Flower said that almost half the firms in that sector were unlikely to be ready in time.

Companies which do not eradicate the bug from their computer systems could find themselves unable to undertake simple operations such as checking customer records, taking orders or sending out goods. They may not even be able to open their premises or operate lighting or heating systems.

Action 2000's latest State of the Nation survey found that about 80,000 medium-sized businesses have not done enough to tackle the computer problem, saying that the stubborn few were foolishly putting their employees' and share- holders' interests at risk.

Ms Flower said: "I have led the business horse to water, I have even kicked it up the backside, but I cannot make it drink." She said people were mistaken if they thought that most Millennium bug problems would strike on the New Year weekend.

"There will be a series of degradations. Problems might not be picked up until the end of the month, the end of the quarter or when end-of-year results are being compiled."

13 July 1999: Millennium bug may hit financial institutions 9 July 1999: Millennium bug threat to councils 7 July 1999: BA 'bug-free 1 July 1999: Passport crisis blamed on Millennium bug 24 May 1999: Millennium bug leaflet intended to quell panic 18 May 1999: Scotland Yard in Millennium bug computer row 17 May 1999: Millennium bug 'will hit 999 services'

-- Old Git (anon@spamproblems.com), August 04, 1999

-- Old Git (anon@spamproblems.com), August 06, 1999.

-- Old Git,

You are backing up what I said wheather you realise it or not.

It is the software, rather than the chip or device itself that has the problem. read THE PROBLEM. No one says that there was not a Y2K problem. People are saying that those problems are getting fixed, at least at the infrastructure leval. What I am attempting to make understandable is that all of the hullabaloo about embedded chips is not true, the chance of a Y2K failure because of an embedded chip is almost non existant, and the problems being found in "embedded systems" are being shown to be software (programming) problems, not problems with the hardware (or system) itself. Your long example above shows just that. Software update needed, manual resets etc. Just because someone labeled these devices as "embedded" it does not mean that the hardware system has a Y2K problem, it is usually the doftware that runs through the system that is at fault and causes the problem.

-- Cherri (sams@brigadoon.com), August 06, 1999.

This thread is about the same as any other "embedded" thread that has ever appeared on this forum. Is it really the chip's firmware, or is it software? Does complexity increase or reduce the probability that there will be a problem? Is there really such a thing as an embedded chip? -- embedded system is the preferred term. Etc., etc., etc., etc.

That it is August 1999 and this debate continues as far as what the problem is, says quite a bit in itself. The only known solution -- checking each and every embedded device for Y2K problems -- always seems to get omitted. Which, considering that there is not enough time left to apply this solution, is probably just as well.

-- Jack (jsprat@eld.net), August 06, 1999.

Cherri:

Old Git is helping much more than just illustrating that the locus of the embedded problem doesn't often lie in the silicon itself. She is also pointing out that (1) The total number of problems that have been found is fairly small; (2) The scope of those problems is quite limited; (3) The impact of failure is often little more than increased liability in case of unlikely accident; (4) that the failing systems are well publicized and the solutions are readily available, a huge time saver for those who need to know this stuff.

Considering that what she's posted is good, sound, hard documentation for every argument against big embedded problems, this represents a remarkable change of heart on her part. Do you suppose she is seeing the light here? I admit I had thought her closed-minded, but apparently I was wrong and she's willing to argue in favor of minor problems when the facts warrent it.

-- Flint (flintc@mindspring.com), August 06, 1999.

Oh, right, things like building fire suppression systems are certainly limited. Why, I would seriously doubt that you would ever find more than one per building. And so, should one not be able to suppress a fire, so what -- you figure the vast majority of buildings won't have fires anyway.

Yeah, embedded problems are noise level, not even worth worrying about....

-- King of Spain (madrid@aol.com), August 06, 1999.

KoS:

Good Example! Turns out (read the fine print) that IF you set this system to Feb 29, 2000, THEN there *might* be legal implications IF there is a fire, since you won't have a log properly kept!

Yep, that's a killer OK. And of course this isn't *all* fire suppression systems with this obscure potential logging problem, only the noncompliant ones. Hope you don't lose *too* much sleep over this, eh?

-- Flint (flintc@mindspring.com), August 06, 1999.

My Dear Pollies.

Thank you for a very enlightening run-around. You have proved the old addage..."If you can't bedazzle them with Brillence...Beffudle them with B/S". You spin a good tale...And for the most part of it is true, as far as it goes. But when you get to the large indstrial complexes, your reasoning stops at the front gate..

But still, in all, I do thank you for a college student's (A student , of course) understanding of ROM and PROM chips on a text book level about embeded systems.And just how few or rare they might with a date sensitive feild..In any given system.

But as the practical vendor who has received an order for a P.. pot load of PLC's knows; for costs and practicality,use what is on hand or what is the cheapest being offered on the market (chips) that can be made to do the job..(even those which have date fuctions; but can be used in a differecnt configuration.)

This old electrican will stay out of the loop untill about April of 2000. You see, there is the sequence in which the embeded systems where tested as they where finished for me to consider. And the Chevron double tap in old Califonia doesn't inspire any confidence in you collective theroy...I'll rely on my practical experience for a few months longer...While hoping all the while you turn out right. Sigh...But you aren't, though I wish it where different.

~~~~~~~~~~~~~~~~~~Shakey~~~~~~~~~~~~~~~~~~

-- Shakey (in_a_bunker@forty.feet), August 06, 1999.

John, Good questions.

I agree with what you basically said. Would it not be fair to say though, that the more complex and/or dangerous/inaccessible a system is the more likely it is to have embedded processors that do care about the date?

No. The opposite is true. If a device is dangerous/inaccessable then you would not rely on embedded processor that could fail. The date/time part of the system would be superficial to the operability of the device so the device would not fail simply due to a date stamp or error monitering system. You put as few obsticles in your way as possible in a situation like you describe. Where critical reliability is concerned (outside of information technology) the least likely that a system relies primarily on embedded processors (digital equipment). Understand it may use "embedded devices" but these would be hardware, electo-mechanical devices. Due to the fact that a system that contains computer chips- integrated circuits is known to be prone to a high failure rate when it is used in a physical hardware system (mechanical/ hydraulic/ pneumatic/ fuel/ water-liquid/ manufacturing etc. the system either has the chip/device redily accessable so it can be repaired or replaced. In areas where these devices would be difficult to access, they are not used. Just good common sense. To have a device unaccessable when you know it is not reliable would cause any business to fail, and fast. The "embedded systems" on offshore platforms are not necessarily digital. Most likely they are electro-mechanical, which is vastly more reliable and have longer work life than a computerized system. The wording "embedded" has been used so much that people really have no idea what one is. Basically, from the information available, it is a self-contained device. Kinda like sysman calls a "black box". People are now assuming because a device is self contained that is has a micro-processor or digital computing ability capability to it. This is not true. Although a PC contains a huge amount of chips in it, they are not as prone to failure as chips in a "hardware" enviroment. Unless you pick up your PC and move it around the room for 8 hours a day, rocking it on it's sides and subject it to constant electrical storms, the PC should not have chip failures. It is in the areas where the chip is involved in movement, constant analog to digital input, connected to equipment where large amounts of voltage is used, hydraulic, mechanical (etc) movement then the failure rate of chips is high. It is not safe to assume that because your PC, (which has few moving parts) does not have problems with digital chips that other devices will have problems with them. So basicly something that could be "broken" by static electricity would not be used in a situation such as you describe.

The more regulated an industry for saftey, enviroment government system or other reason the more likely it is that the date will have some critical importance. At least this is true in my experience.

This could be very true. But the data recording of info and time/date would be superficial to the device. In other words it would not effect the functioning of the device if it (data monitoring) failed to work. If timing were of importance to the device then it would most likely would be achieved by elapsed time internally done mechanically.

In my experience failures often occur of the silliest reasons and usally now what you think of first. So it would seem to me that the most critical systems are the ones that are most prone to failure. No the most critical systems are the ones protected against failure. -- John Beck (eurisko111@aol.com), August 06, 1999.

-- Cherri (sams@brigadoom.com), August 07, 1999.

Yawn.

If the embedded systems problem is a problem (which I happen to believe it is) then that will be obvious very soon. If it is not a problem then - great! One less thing to FOF.

At this point it is ALL MOOT. Anyone who thinks everything will be fine or NTB (Not THAT Bad) can go blithely on with their lives. The rest of us can continue to do the best we can to take the precautions we feel are worth taking.

-- Byte Me (Tired of this cr@p.com), August 07, 1999.

My Dear Shakey:

What you are reading is an attempt (by people who have been doing embedded systems for many years) to explain how they work, and why the problem isn't so serious, in terms that can be understood by people who don't do this for a living.

What you are expressing is a refusal to believe any of it, on the part of someone who doesn't understand and doesn't want to. If you prefer fear to knowledge, that is your privilege. But your attempt to dismiss those who understand what you don't misses the mark.

Yes, some embedded systems will fail in serious and unexpected ways. Even more than happens today. But these isolated failures don't threaten the infrastructure, and don't mean the loss of all oil, or all power, or all telephony, etc. Worries like those are created by people who think in terms of all-or-nothing, and since it won't be nothing, it *must* be all. But it won't be.

-- Flint (flintc@mindspring.com), August 07, 1999.

My Dear Mr. Flint

Sir; if the situation(y2k) where not so serious, I do believe I would take offense at your condensending manner.

Let's see now...My rather partial inexperience at my chosen profession began with the MSR/PAR anti ballistic mssle system in N. Dak. back in 1972. From there it went to the Jim Bridger coal-fired complex at Rock Springs Wy.

The Navaho coal-fired complex at Page Ariz. The Phelps Dodge remodel at Morenci Az..(copper smelter)

Called back again to Jim Bridger in Wy...Trouble in the Ball mills sequence (they crush up the coal into a fine dust).

Wheatland coal-fired complex, eastern Wy.

S.L.C. Ut. The little Bingham copper mine up on the hills to the north of the city...I am sure you have heard of them.

The Salt River Project( rather smallish coal fired at St. Johns, Az. I went between there and the Joseph City Az. power generation units for a couple or three year..Between times I spent a little time in Palo Verde east of Phonix, Az. It seems that they had some trouble making the interlocks between PLCs work in conjunction with each other.

I went on to the San Juan coal-fired at the four corners in N. Mexico. And of course I forgot, But I'll include now...The Huntington power house in Huntington Canyon, UT.

My last effort at power generation was the Intermountain Power project at Delta, Ut.

I next went into the Casinios (as in gambling of course). But I won't continue this summary of my work experience, which is almost begining to feel like I am putting in my papers for a position with some company. But if you are ever in Vegas and take in the two sailing ships fighting it out at the Treasure Island casino...Now there were some interlocking problems which were fun.

Mr. Flint...There is just a bare possibility that I might know a little about the subject of embeds..And of course, you should know that on a billion dollar plus job, the General cont. has it's own on site work shop to remeadate, change, even make up specials for any PLC problem that might come up..

I'll end by suggesting that you count back and see how many power houses have blown a system, explosively in the last 11 mo...How many since the first of the year? How many refineries since the first, world wide..? The double tap at The Chevron refinery.. The various ppe lines...We'll hear more from them before long.Why have most if not all, of the major gas/oil companies have anounced FOF.

~~~~~~~~~~~~~~~~~~~~Shakey~~~~~~~~~~~~~~~~

-- Shakey (in_a_bunker@forty.feet), August 07, 1999.

Embedded chips/systems/devices/whatever have always been considered the "wildcard" of Y2K. Unless they are checked out -- and the time to do that for all of them has effectively run out -- it becomes an open question how they will behave and what they will effect. If we are lucky, it may be no more than automated log files from a fire system having incorrect dates; if we are not so lucky, many lives may be lost due to malfunctioning systems. Unfortunately, trying to "extrapolate" a bad log file bug on one fire suppression system to mean this is the worst Y2K error that could occur on all of them is wishful thinking, to say the least.

-- Jack (jsprat@eld.net), August 07, 1999.

I second Brian in saying this is good information, from "both" sides (to categorize them all loosely). I'd like to thank Cherri, Flint and Shakey for their efforts in explaining things.

I read Cherri and Flint and I think perhaps next year will just be a depression. I read Shakey and I think perhaps next year will just be a really bad depression. Either possibility is reassuring for me.

Any knowledgeable source that expects things to be worse than Shakey's posts indicate? Barring that, I'm taking this whole thread as good news.

Thanks again.

-- Gus (y2kk@usa.net), August 07, 1999.

Gus

My take is that things can run without the date but will it run as efficiantly or as safe? That will depend on the experiance of the staff. I think the question should be where do you draw the line with the risks involved? This would mean a through understanding in my mind of the dynamics of the systems involved

There is a real question in my mind if the capibility is there to have effective contingency plans in place. That is where the human error will come in.

Comments anyone?

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

Like others who post to this forum, when I have come upon information which I would class as "reliably good news," I have posted it. You have just never noticed, Flint. It has nothing to do with "a change of heart."

You say my post points out how few problems have been discovered. That's what bothers me, because the post following that post shows that there is an unacceptably high number of British firms that have not done anything about remediation, embedded whatsits or not. I have no reason to believe that the situation is any better with US firms. If I'm right, you might as well multiply that 80,000 medium-sized firms figure by 4 to get an approximate number of the US firms who aren't bothering to remediate--i.e., 320,000. No doubt some--who knows how many?--of that number have not bothered to check their embedded systems.

You also say that "The impact of failure is often little more than increased liability in case of unlikely accident." Oh really?

Look at this: ". . .lack of car-parking causing traffic congestion, safety - if car park egress not possible or restricted." And if the traffic lights system, fails around the same time? Have you heard of the well-documented phenomenon known as "road rage?" How about people trapped in parking garages in the dead of winter? Heat of summer? How about assaults on sitting ducks?

There are half a dozen or so scenarios describing loss of heat or AC in a building. What if it happens to several (let alone many) high-rise apartment buildings, hotels, nursing homes, apartments for the elderly, etc., all at once? Where will local governments house those people who would otherwise freeze or boil to death?

Where the buildings involved are communications facilties--like emergency services or defense installations, the given scenario describes the situation as "catastrophic.' I think we all know why computer rooms are carefully climate-controlled. Not only will those offices be uninhabitable but there is an excellent chance that all the delicate electronic equipment will be rendered inoperable by extreme temperatures.

For those buildings where the embedded sytems controlling fire alarms and fire control are affected, who knows what could happen? The sprinkler system may be erroneously activated destroying crucial equipment, again a building containing vulnerable people might have to be evacuated in the middle of winter--or summer--and the elevators will stop working when the fire alarm/control systems malfunction. (When I was a great deal younger I had to walk down 43 floors during a high-rise office building fire. No fun. Older people collapsed.)

I love the swipe card control system conclusion: "Will cause significant inconvenience to business." Our entire police headquarters building is controlled by swipe card access and the Communications Center is controlled by a second swipe card access. I also know that riot control gear is kept at police headquarters in another swipe-controlled access room. Who knows what other areas are similarly controlled? National Guard and defense facilities too. There must be thousands, if not tens of thousands, of buildings which use the same systems--many hotels also. Let's hope they all have manual workarounds--like stationing people at the door of sensitive areas to ensure no unauthorized personnel enter. Gonna stretch 'em a bit thin, isn't it? I think emergency services personnel won't need any more drains on their resources next year.

Luckily, I have a developed sense of consequence.

-- Old Git (anon@spamproblems.com), August 07, 1999.

I just LOVE the polly spin on this stuff:

1) Nobody knows what will happen.
2) But, NOTHING REALLY TOO BAD will happen.

Cherri, Flint -- LOL!

-- King of Spain (madrid@aol.com), August 07, 1999.

Old Git:

A developed sense of consequence ought not be the same thing as a hypertrophied sense of consequence. Your sense of the consequences of a noncompliant card swipe system is built on the assuptions that (1) They're used everywhere; (2) Everyone is using the same noncompliant system (I've done at least two such swipe systems, no y2k bugs in mine); (3) Nobody has fixed or replaced any of them. Now, all three of these assumptions is wildly false, but how can you have a decent sense of consequence without a few false assumptions, eh what?

Just like you implication that everyone is on the 43rd floor. No, you didn't say that, you simply ignored anyone who wasn't. And really, what IS a serious consequence? As far as I'm concerned, the aliens could abduct all of Southern California, smog and all, and never return it and we'd probably be better off.

-- Flint (flintc@mindspring.com), August 07, 1999.

Sorry I missed this thread earlier, but it's 2:30 AM, and I gotta crash. I want to spend more time on some of your remarks before I reply. I'll be back! <:)=

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

I'm with KOS, Old Git and Shakey on this one...

"As a net is made up of a series of ties, so everything in this world is connected by a series of ties. If anyone thinks that the mesh of a net is an independent, isolated thing, he is mistaken..."

Buddha

"The conveniences and comforts of humanity in general will be linked up by one mechanism, which will produce comforts and conveniences beyond human imagination. But the smallest mistake will bring the whole mechanism to a certain collapse. In this way the end of the world will be brought about."

Sufi Prophet Pir-o-Murshid Inayat Khan's Prophecy made in 1922

(Complete Works, 1922 I, p. 158-9)

-- Andy (2000EOD@prodigy.net), August 08, 1999.

Flint, I'm not going to get into one of your interminable ersatz arguments, I'm going to let people judge for themselves.

Flint said about my post: "Your sense of the consequences of a noncompliant card swipe system is built on the assuptions that (1) They're used everywhere; (2) Everyone is using the same noncompliant system." What I said was: "There must be thousands, if not tens of thousands, of buildings which use the same systems--many hotels also." {Did anyone else NOT comprehend that "same systems" refers to swipe card systems in general as opposed to the exact swipe card system everywhere?}

Flint says I assume that "Nobody has fixed or replaced any of them." What I said was: "If I'm right, you might as well multiply that 80,000 medium-sized [British] firms figure by 4 to get an approximate number of the US firms who aren't bothering to remediate--i.e., 320,000. No doubt some--who knows how many?--of that number have not bothered to check their embedded systems." {Did anyone comprehend that "some. . . have not bothered to check" means "nobody has fixed or replaced any"?)

Flint says: "Now, all three of these assumptions is wildly false, but how can you have a decent sense of consequence without a few false assumptions, eh what?"

Based on the above evidence, it appears that it is quite possible for readers of my post to not only have an undeveloped sense of consequence, but also an undeveloped sense of comprehension of the English language. Perhaps the former follows from the latter, huh?

Finally, Flint says: "Just like you [sic] implication that everyone is on the 43rd floor. No, you didn't say that, you simply ignored anyone who wasn't." Quite right. I should have mentioned those on the 44th to 51st floors and the penthouse as well. I should also have mentioned the guy in the wheelchair who was carried down only 10 floors. And the woman with the leg braces who only had to negotiate six floors of stairs. There were other disabled people among the 8,000 workers in the building but those are the only ones I knew personally; I have no idea which floors the others came from. Of the large number of people scattered on the sidewalk and street being treated by firefighters and paramedics, I don't know how many came from below the 43rd floor. Smoke appeared in the stairwell at the 30th floor and became gradually denser as one descended, so I'll make a wild assumption that those victims with oxygen masks over their faces were being treated for respiratory problems, like smoke inhalation, asthma difficulties, and so on. A developed sense fo consequence would have indicated to its owner that those who evacuated from below the 43rd floor would have had some difficulties too.

-- Old Git (anon@spamproblems.com), August 08, 1999.

Old Git:

OK, I agree with you. I don't know how you figure that there "must" be thousands or tens of thousands of buildings using these systems, nor how you determined that the noncompliance would have the effects you propose, but let's assume you have this information and you're keeping it secret so as not to bore us, OK?

But I seriously doubt you have information on how many of these buildings will ignite. So what you're saying is IF a noncompliant card swipe system is used, and IF this noncompliance causes major difficulties, and IF such a building catches fire, and IF there are no alternatives (card swipe systems I've designed can *always* be disabled entirely, just in case of fire), THEN some people will be in deep trouble. And IF those people are on upper floors of high-rise buildings, they may die as a result.

Yes, for those people the consequences are fatal. Indeed, this is true today when highrise buildings catch fire, y2k or not. Maybe we're talking about two different aspects of "consequence" -- for you, anyone badly inconvenienced (or killed by accident) counts, whereas for me, the issue we're dealing with is, *what degree* of difficulty will embedded systems pose?

And no, I don't accept that the world will go straight to hell in a handbasket because of isolated embedded failures. If it turns out that 10,000 deaths can be attributed directly to y2k failures, then we got away pretty damn clean, your sense of consequence notwithstanding. Milne et. al. are talking about deaths in the billions, resulting from the breakdown of the infrastructure due to embedded failures. This is NOT going to happen, as your own list demonstrates. If we're talking about 10,000 deaths, that's in the noise of ordinary mortality rates, and isn't significant. Although you're welcome to emphasize and mourn each one, even today.

-- Flint (flintc@mindspring.com), August 08, 1999.

Flint says, "If it turns out that 10,000 deaths can be attributed directly to y2k failures, then we got away pretty damn clean...If we're talking about 10,000 deaths, that's in the noise of ordinary mortality rates, and isn't significant."

If 10,000 deaths directly attributable to Y2K failures is insignificant, just how many deaths would be significant enough to qualify as more than a Bump in the Road?

Flint says, "And really, what IS a serious consequence? As far as I'm concerned, the aliens could abduct all of Southern California, smog and all, and never return it and we'd probably be better off."

So, if the deaths of half of the U.S.'s most populated state would not only be insignificant, but welcome, then there really can be no Y2K scenario that rises above a Bump in the Road.

How much difference is there between an Uber Doomer who ranks himself as a "10" because he expects such significant destruction and an Uber Polly who ranks himself as a "1" because he thinks that such destruction would be insignificant? Could it be that, like the fine line between genius and idiocy, there is a fine line between a "1" and a "10"?

-- Wow (Holy@cow.now), August 08, 1999.

Wow:

OK, I raised the issue, and you quoted me, but didn't otherwise address the issue. Do you have some opinion?

How many people die each year, worldwide? Let's say the world's population is 8 billion, and let's say the mean lifespan is 50 years (includes infant mortality, so this is conservative). That means about 1/50th of everyone dies each year. 1/50th of 6 billion is 120 million people. Thats 120 million deaths from all causes worldwide annually. So 10,000 deaths is one twelve thousandth of *normal* yearly deaths. Thats .008%

Now, look at the pessimists here. Surely they're predicting that mortality resulting from y2k will rise at least ONE percent, right? This translates to over a million deaths. If they're talking about 5%, there goes Southern California. And some are talking about 50%!

So what I see happening here is people already laying the groundwork to be able to claim y2k was a disaster after we all know it was NOT. We do this by exaggerating the importance of what happens that's unusual, while ignoring the typical (which dwarfs it).

(And I should point out that 10,000 deaths is well within normal *variation*. To translate, y2k could cause 10,000 deaths directly, and the global total mortality could *still* decline! Apparently a sense of consequence is the opposite of a sense of perspective).

-- Flint (flintc@mindspring.com), August 08, 1999.

Flint is correct. 10,000 deaths worldwide will barely even register. This would equal a Bophal chemical disaster or a bad monsoon season.

10,000 deaths in USA would be a moderate scenario. 100,000 would be severe. I am guessing we will have 500,000 deaths in USA attributable directly and indirectly to y2k by 2005. Worldwide the figure will be many millions.

-- a (a@a.a), August 08, 1999.

'a':

One of the main things I'm trying to get clarified here is this "indirectly attributable" grab-bag. Does this mean you can, with enough imagination, construct some hazily plausible explanation for *every* death that associates it with y2k? In that case, basically EVERY death for the next 5 years can be "indirectly attributed" to y2k one way or another, just the same as you make equally implausible arguments that morality and society have been going downhill ever since you've been old enough to make a contribution.

What I've been proposing is to measure indirect y2k consequences in terms of variation outside the normal range, for things we can (more or less) measure, like deaths and power outages and bankruptcies and unemployment. I readily agree that these are very indirect, meaning we have no controls in this experiment and we can't possibly say that such effects wouldn't have happened normally even without y2k (for example, the market seems overheated and headed for a big correction y2k or not).

In terms of embedded systems, these should be most directly attributable (but not completely -- things explode pretty regularly as we've noticed). I'm not expecting mortality (even in the US) to be beyond normal patterns. Sure, you'll find deaths caused by y2k failures here and there.

You'll notice that between 3.5 and 4 million people die in the US each year. I don't know what the variation is, but 100,000 either way wouldn't surprise me as being about a standard deviation. So yes, 10,000 is in the noise even in the US. Your 500,000 number over 5 years is about 4 month's worth of deaths at normal rates. So you're predicting that mortality in the US will rise 6% for the next 5 years. That's high, but nothing near what infrastructure collapse would cause. Indeed, it's hard to picture just *what* would cause it. Any suggestions?

-- Flint (flintc@mindspring.com), August 08, 1999.

One more try, then I have to go and do something useful.

Flint says: "I don't know how you figure that there 'must' be thousands or tens of thousands of buildings using these systems." That came about based on my personal knowledge of the number of offices and hotels using swipe-card systems in one large American city multiplied by large and medium-sized cities worldwide. I should have dotted more Is, crossed more Ts by saying "individual offices within buildings as well," shouldn't I?

". . .nor how you determined that the noncompliance would have the effects you propose. . ." I didn't determine those scenarios, the British government did.

". . . but let's assume you have this information and you're keeping it secret so as not to bore us, OK?" No secret, see answer above.

"But I seriously doubt you have information on how many of these buildings will ignite." I didn't say they'd all ignite? The official British government scenarios above state that alarms will malfunction, so you could have a fire alarm without any fire. But the building has to be immedaitely evacuated until the cause of the alarm has been determined.

"So what you're saying is IF a noncompliant card swipe system is used, and IF this noncompliance causes major difficulties," yes, "and IF such a building catches fire," yes--or if the alarm goes off and there is no fire, "and IF there are no alternatives (card swipe systems I've designed can *always* be disabled entirely, just in case of fire)," Oh, Have you designed every card-swipe system in the world then? Or, if not, can you speak for the system in, say, the Bahrein Hilton? "THEN some people will be in deep trouble." Quite possibly, especially if tens of thousands of small to medium-sized business haven't done anything about any kind of remediation. Varying depths of trouble, actually. "And IF those people are on upper floors of high-rise buildings, they may die as a result." Certainly. Especially if they suffer from heart problems or respiratory difficulty, or other disease, illness, disability or condition aggravated by even a few floors of steps or smoke, or even if there actually IS a fire--yes, they COULD die.

"Yes, for those people the consequences are fatal. Indeed, this is true today when highrise buildings catch fire, y2k or not." Yup. "Maybe we're talking about two different aspects of 'consequence' -- for you, anyone badly inconvenienced (or killed by accident) counts," yup, "whereas for me, the issue we're dealing with is, *what degree* of difficulty will embedded systems pose?" I don't think Flint or anyone else knows what degree of difficulty embedded systems will pose. Even if only one embedded system in one building causes a death, I happen to think that's one death too many. If it's YOUR relative who's killed or injured, it's a family tragedy; if it's nobody you know, it's a statistic--that seems to be Flint's attitude!

Many years ago I was walking with my then 6-year old son in the business district of New Orleans. We had heard lots of sirens but didn't have any idea what was happening, until we turned a corner and were confronted with a fire in a high-rise building (the Rault Center). Before I could turn around and take my young son from the scene, the sixth of seven women jumped to her death right in front of us, flames pouring out of the window behind her. Of course that fire had nothing to do with embedded systems. But, according to the British scenarios above, such a fire COULD happen. Shouldn't it be prevented if it CAN be prevented?

"And no, I don't accept that the world will go straight to hell in a handbasket because of isolated embedded failures." Where did I make that claim? I don't believe it either.

"If it turns out that 10,000 deaths can be attributed directly to y2k failures, then we got away pretty damn clean, your sense of consequence notwithstanding." Huh? What are you talking about? Who said 10,00 deaths? What do you mean, "got away pretty damn clean"?

"Milne et. al. are talking about deaths in the billions, resulting from the breakdown of the infrastructure due to embedded failures. This is NOT going to happen, as your own list demonstrates." Flint has put words in my mouth. Nowhere have I mentioned billions or even tens of thousands of deaths. Flint apprently thinks everyone goes along with every single statement made by Paul Milne.

In a subsequent post, Flint says: "So what I see happening here is people already laying the groundwork to be able to claim y2k was a disaster after we all know it was NOT. We do this by exaggerating the importance of what happens that's unusual, while ignoring the typical. . ." Frankly, it hadn't occurred to me to so manipulate statistics. In any event, if someone DOES try this little deceit (and it IS a deceit), a simple comparison with mortality rates for the previous 5-10 years will show the utter fallacy of such a claim--and I would be in the forefront of those saying, "show me evidence of HOW these people expired."

My sense of compassion tells me that the relatrives of those massacred in Kosovo experience more misery than if the victims had died naturally in their sleep. And that same sense of compassion tells me that the relatives of anyone (any ONE) who dies or is seriously injured as a result of a preventable embedded systems failure will feel more anguish than if that person had died a natural death.

Now I know you folks are tired of this nit-picking. Flint will no doubt drag in more issues and other people's views and attribute them to everyone else, but I think the important issues have been settled: there are predictable consequences from the malfunction or failure of embedded systems (which many people lump together with embedded "chips")(number of possible failures uknown); those consequences could produce death and injury (number of deaths and injuries unknown); and any such casualties are probably avoidable.

-- Old Git (anon@spamproblems.com), August 08, 1999.

Flint, let me try again to explain it to you. First off, you say that I have been making

"implausible arguments that morality and society have been going downhill."

Flint, it said in paper today that the tower at Kent State university has been reopened for the first time since the shooting in 1974. Do you remember that Flint? 12 people were shot and killed. It was a tragedy that gripped the nation for decades. In comparison, last week, some disgruntled nut that lost his ass in the stock market shot and killed the same number of people. It is news for about two days. A week later, someone else goes on another office rampage and shoots and kills three. It barely makes headlines. Do you think this is evidence that "society is going downhill"?

Society isn't going downhill Flint. Its GONE downhill. Every night we continue to desensitize ourselves to violence by watching more and more hours of more and more realistic videos of bloodletting and mayhem. We love it so much that we even feed it to our kids. They love it too. And its not just carnage that fascinates us. Television now contains the same type of material that was once confined to publications like Hustler magazine. Do you just take information like this and completely ignore it Flint? Are you waiting for Decker to complete his research on debauchery statistics, is that it? What will it take for you to realize that this society may become completely dysfunctional when it is confronted by the disaster that is soon to unfold?

Now. Remember my first email to you last October? I said

My fear of what we can expect in the next few years is complex, but is
based on (in increasing order)



- global economic depression
- y2k
- war/terrorism threat
- global climate change

My outlook hasn't changed. The coming depression will unleash a level of violence unheard of in the 30's or even the 70's. Thousands will die directly because of this violence. The y2k problem will cause scores of industrial and transportation accidents, directly killing tens of thousands more. War, caused by suffering in general, and the opportunity of y2k and the financial collapse in particular, will kill 100's of thousands more. And this triple whammy on the third world, in combination with deteriorating world climate, will unleash famine and disease that will kill millions on top of that.

Any questions?

-- a (a@a.a), August 08, 1999.

'a' wrote:

Society isn't going downhill Flint. Its GONE downhill. Every night we continue to desensitize ourselves to violence by watching more and more hours of more and more realistic videos of bloodletting and mayhem. We love it so much that we even feed it to our kids. They love it too. And its not just carnage that fascinates us. Television now contains the same type of material that was once confined to publications like Hustler magazine. Do you just take information like this and completely ignore it Flint? Are you waiting for Decker to complete his research on debauchery statistics, is that it? What will it take for you to realize that this society may become completely dysfunctional when it is confronted by the disaster that is soon to unfold?

It is good to here this sort of thing. People too easily forget what this is all about. Flint especially seems to exhibit a willful ignorance of Y2K.

Here in Denmark we are suffering acutely from the kind of moral decline you write of. Not surprising when you think we were the first country to legalise pornography. The crime rate is appalling, Murdering is everywhere. And so is sex and stuff. Even now, as I look out of my window, I can see some murdering going on to my left; and across the street to my right I can see a courting couple lingering in a dimly lit porch. I don't even bother to shut the curtains these days. Do you remember that film with Kurt Russell, in which New York became a prison for the dammed? Well that film was actually based on Copenhagen rather than an imagined future New York.

You really ought to fly over some time. I mean 'fly over' the city. With a helicopter. You can do that if you get permission and pay for it yourself. Well anyway I can tell you as one who is resident in an advanced state of Soddam and Gommora, that it is pretty dammed awful and I wouldn4t wish it on anyone..

May the Lord mercy on you.

-- Smell my elbow (Bergeetah@greatdane.dk), August 08, 1999.

smell and 'a':

I'm really sorry that y2k will not bring an end to the immorality and general decline you see all around you. Smell, I suggest you pray harder - who knows, it might be all we need. 'a', I already explained that millions die every year normally. If your concatenation of disasters (to which y2k contributes) causes only as many people to die as happens currently (or even fewer), where's the problem? It would seem to be as artificial as your declining morality.

And Old Git, your careful misunderstanding of everything I write must be tiring you brain. Let me try a different tack, since all the others got bent away. IF embedded systems failures follow the pattern and scope of the kind of things you posted, *and no more*, then not a single one of us will have any need for any of our preparations. Death rates will be normal. The infrastructure will be intact. y2k will be a non-event.

I'll certainly agree that many, perhaps most, people who die today, do so of preventable causes. I suggest this has ALWAYS been true. It's as irrelevant to embedded systems as 'a' and 'smell's morality bleating, but still true.

-- Flint (flintc@mindspring.com), August 08, 1999.

Flint, don't act so stupid. Do you think that y2k will be significant only if half the population dies?

Not many folks died directly because of the Great Depression Flint. Does that mean it was a non-event?

-- a (a@a.a), August 08, 1999.

'a':

I'm just proposing a yardstick by which the depradations of y2k can be measured. What I'm proposing to use is normal variation along several vectors -- deaths, bankruptcies, explosions, whatever. All I ask is that these differences be measurable and quantifiable, rather than just some hazy feeling that "things" are worse than they once might have been.

The Great Depression is a good example, because we have records of quite a few rates at that time -- bank failures, unemployment, probably even velocity of M3. That is, measurable, definable quantities.

I've already said that one problem with any effort at measuring the effects of y2k is lack of control - we have no otherwise identical world where y2k doesn't happen to compare with. This means if something *doesn't* go wrong, it might have gone wrong if y2k hadn't prevented it! (As well as things that would have gone wrong y2k or not). But this seems as close as we can come to quantifying macroeconomic y2k effects.

Do you have some better ideas?

-- Flint (flintc@mindspring.com), August 08, 1999.