HI! I do not completely understand the impact of Y2K. I do understand that banks can be disrupted, and credit bureaus, and the IRS. However, I do not understand how electricity and oil can be affected. Just because oil pumps have embedded chips does not mean the pumps will not work. They can set the clocks back to 1990's until the situation is fixed. The same for electricity. I am sure that the chips in the pumps get there date info from the central computer, just set the clocks back.

Electric companys have this central processing plant to divert electricity to houses, and these automated systems handle all grid diversions etc.. Once again setting the clock back will at least stop the so called economic collapse. It can work.

I believe that all of this is a hoax. However, a terror perceived or real is just as effective to the stock market.

All of this is mentioned in "The Protocols Of the Learned Elders Of Zion". I am not an Anti-Semite. I am a born again Christian who happens to be a man of color. However, the Protocols call for a planned economic collapse to usher in a new economic system world wide,and then a world government. Nafta is done and Gatt, and probably MAI; and mark my words that this will shift the way the world does business. Additionally, watch out all of you with stock; according to the Protocols they plan on doing away with the Money Market.

Whoever wrote the protocols sure know our economic system today, and where we are headed whether Jew or Gentile. The Protocols have not been proven false by a court of law, or hard evidnce, just people who do not like what it says, and because many white supremacist groups use it for their hate agenda.

I suggest that if you haven't read it do so, just to be informed.

As for my Jewish friends do not get mad at me, for I support Israel. This is just for information sake. Think of it as a reporter looking at information. Do not take it personal.

-- King Wells Jr (kwellsjr@worldnet.att.net), June 08, 1998

Answers

Mr. Wells:

Your post illustrates perfectly the immense need for the general public to be made aware and educated about this problem. If our political leaders are unwilling to provide this information, then people must do their own homework. Your statements about embedded systems reveal a lack of basic research.

 They can set the clocks back to 1990s until the problem is fixed.

Who exactly are They and do they realize that the clocks are in the chips themselves?

Do They realize that most of the embedded chips that are suspected of being date-sensitive wont be field-programmable, meaning that they have to be physically replaced?

And, do They think that these ICs might be date-sensitive for a reason (i.e., designed as such)  and that simply setting back the clocks would defeat the whole purpose of these chips being date-sensitive in the first place?

If setting back the clocks were a viable solution do you think that these chips could all be reprogrammed (replaced) and tested by 01/01/2000?

If setting back the clocks were a viable solution how long would we have to live in the past until the systems were remediated  especially when such an approach would provide exactly what some IT managers and executives desperately want, an infinitely receding deadline. All the time in the world to fix the problem, so whats the rush?

The same for electricity. I am sure that the chips in the pumps get their date info from the central computer, just set the clocks back. Electric companies have this central processing plant to divert electricity to houses, and these automated systems handle all grid diversions etc..

Im sure the reference to pumps and electricity was an oversight (unless you are referring to nuclear plants). However, I dont see how you are sure that the remainder of your statement makes any sense. I am sure... Does that mean your own speculation? Divine inspiration? Factual knowledge from people who possess it?

 the chipsget their date info from the central computer , just set the clocks back.

The whole idea of embedded systems is to reduce or eliminate the need for the supervision of a central computer.

Assuming that embedded systems did get their date info from a particular mainframe, the questions previously asked above still apply.

I wont comment on the second half of your post, failing, at the very least, to see the relevance of the subjects addressed.

Mr. Wells, I realize that my reply may come across as rather gruff and critical. Please understand that it stems from my own frustration. This frustration comes from knowing millions of other people are at the same level of understanding that you are when it comes to grasping the details of this problem.

Best Regards, PMB

-- Paul M. Bednarek (paul_bednarek@quantumdata.com), June 08, 1998.

The response from King Wells Jr concerns me.

Most of my background is mini/server/PC based systems, though I have a little digital-design and mainframe experience. I am not, however, familiar with standard protocols related to embedded controllers. Of course the controllers have their own clocks. But are you SURE the time on the clocks can't be changed? I never heard of a clock (even a little one) where you couldn't set the time. Please provide references, if possible (please!), since if you are correct, we are in DEEP SH*T!!!

-- Phil (pperucci@mindspring.com), June 09, 1998.

...oops... I meant the response from Paul.

-- Phil (pperucci@mindspring.com), June 09, 1998.

Some microchips have clock functions that are not accessible. There have been articles on Gary North about this as well as Rick Cowles forum on electric utilites.

-- Rebecca Kutcher (kutcher@pionet.net), June 09, 1998.

Phil:

I started to post a reply after reading your message. Then I looked over my previous post and decided that I had better provide a short description of my background (before I am besieged with questions that I may or may not be qualified to answer authoritatively!).

I am currently employed as an electrical engineer, with responsibilities that include primarily design verification with some actual analog and digital design duties (namely, redesigning the circuitry that I find to be deficient). Although I do write ATE applications to serve my own testing purposes, I am not a programmer. I do interact with programmers on a daily basis and am painfully aware that even though our people are extremely talented and well-intentioned, in seven years with my current employer I have yet to see a major software project completed on time.

The embedded systems issue is quite a bit more complex than you would deduce from my post or that of Mr. Wells. Embedded system is a somewhat generic, catch-all phrase that describes a collection of circuitry that is optimized to perform certain tasks. If youve been following the threads on some of the other Y2K websites, you have probably heard that the embedded systems aspect of Y2K is the killer, a nightmare, and so on. The reason for this is that embedded systems can be vastly different in terms of functionality and flexibility.

For example, some systems may contain actual processors (i.e., having dedicated I/O lines, arithmetic functions, a small amount of non-volatile memory, etc.). These systems will probably have an internal counter referenced to a register which contains some sort of date data. I say probably because our concern here is with embedded system effects on utility industries. These industries have employed embedded systems that were designed before I entered the field. The reference data used by the counter most likely can be set back in this case, providing you have access to the required I/O and address lines. This may be remote access, it might not. Of course, this means that all other embedded systems and any external controls and applications that interact with the fixed system must also be set back  every device and software utility must be on the same page. As you might imagine, were talking about a considerable amount of effort  maybe as much effort as you would expend fixing the problem the right way (making the systems Y2K compliant).

On the other hand, some embedded systems, may be relatively dumb, containing primarily PLDs (Programmable Logic Devices), FPGAs (Field Programmable Gate Arrays), and other devices.

Put simply, PLDs are chips that can be programmed to perform certain functions given certain conditions. That is, they generate logic output according to algorithms that manipulate logic input into the device. PLDs are almost always programmed before being installed on a circuit board, mainly because the external circuitry required to program them in-circuit is not cost-effective considering the relatively limited potential of these devices. Many older PLD's are also "one-shot" devices - programmable only once. So, if some sort of date reference data is burned into these chips, the only way to change that data is to physically remove the IC and replace it with one that is programmed with the data required.

FPGAs, while similar to PLDs, offer much greater potential in terms of function and algorithm complexity. Although the acronym indicates that these devices are field programmable, this programmability is entirely dependent on the design of the circuits they are used in. For example, the company that I am associated with has designed products utilizing FPGAs where the products functionality was never intended to be altered or expanded. Therefore the necessary PCB layout requirements and external circuitry was not implemented. It isnt difficult to imagine that designers creating embedded systems for utility applications never envisioned a reason for those systems to function any differently than as described in the original design specification. Again, physical replacement is the only option in such cases.

Whew, I have rambled Phil, I know that you requested references if I could provide them. Its difficult to provide more than a suggestion to search data sheets and application notes for the specific devices in question. Even with all the information available for a particular device, the question of weather the system is repairable in one way or another is almost entirely dependent on how the system is designed. I am not employed in the utilities industry, and do not have specific information regarding what hardware may be involved. In fact, looking back over my post, it has just come to mind that FPGAs are a relatively recent addition to embedded systems  at least when you consider the antiquity of some of the systems that utilities must be using.

There is a site you might be interested in at http://www.cera2.com/embe/index.htm. The site also contains links to various manufacturers of commonly used embedded system devices.

I hope this information has been useful. I also hope that my reply hasnt become irritatingly verbose!

Best Regards, PMB

-- Paul M. Bednarek (paul_bednarek@quantumdata.com), June 09, 1998.

: They can set the clocks back to 1990s until the problem is :fixed.

: Who exactly are They and do they realize that the clocks are :in the chips themselves?

"They", for all fans, of David Letterman, refers to the Van Pattoen Family from 8 is Enough.

As far as the TPOTLEOZ, it's been proven time and again that the writings are fake.

-- havocuz (havocuz@mindspring.com), June 09, 1998.

Paul,

Please bear with me, but I imagine (incorrectly) electric utility companies where all the embedded controllers are wired together, much like PCs are networked these days. If this is not the case, please understand I am an applications programmer...

Since a TEOLOEAWKI scenario would typically start with failure of the utility companies, I am mostly concerned here with utilities, and the rail-system which brings the fuels.

Are you saying that 1) the controllers at a utility are not all wired to central locations and 2) "set time" is not a common command for embedded controllers!?

-- Phil (pperucci@mindspring.com), June 09, 1998.

Phil:

As I said before, I dont work in the utility industry, and I cant speculate on the exact architecture of the particular embedded systems used. I have had some experience in the process control field, and I think that some of the systems I have seen you could expect to find in similar form with utilities.

For example, embedded systems measuring a particular variable in a process, making a decision based on that value, and initiating some action. The action would indeed be reported to a central computer or controller, but this type of communication requires a minimum of connectivity  it may be a single bit on the central computer/controller data bus. This certainly is a simplified case, but it illustrates that although the systems are connected, you dont necessarily have full remote access to the brains of a particular embedded system or controller.

As for the existence of a set time command for embedded controllers, all I can offer is that it makes perfect sense (to me, as a non-programmer) to have such a command. However, not knowing exactly what types of systems are common in the utility industry, I couldnt guarantee it. If the embedded systems are running code that was custom written by in-house personnel, anything is possible.

Best Regards, PMB

-- Paul M. Bednarek (paul_bednarek@quantumdata.com), June 10, 1998.

Paul, Who said common sense had anything to do with it??? In programming many times the common sense just isn't there. You have the whiz kids that are "creative" geniuses and being logical and having common sense just isn't "creative". After more years than I care to think about in the programming field, I can say this. I have gone in after these whiz kids and repaired more systems that were badly written. I have also done some firmware programming and the clock function may be in the chip, but addressable only if the chip is reprogrammed (good luck finding the orginal programming).

-- Rebecca Kutcher (kutcher@pionet.net), June 10, 1998.

Rebecca:

Of course, you're absolutely right! I guess if common sense were a prerequisite for being a competent programmer, we wouldn't be in the mess were in right now!

Best Regards, PMB

-- Paul M. Bednarek (paul_bednarek@quantumdata.com), June 11, 1998.