Chuck Sippial is assistant vice president for physical plant at Texas A&M University, College Station, Texas. He led a roundtable discussion on the Y2K issue at the San Jose annual meeting in August. He can be reached at firstname.lastname@example.org.
Imagine it is ten minutes after midnight on January 1, 2000, and your campus has no power except the emergency generators serving your most critical systems. You are told to report to the command center to meet with your university president and senior campus officials. Your president turns to you and asks you to present your plan for having the campus back in operation by 8:00 a.m. on Monday, January 3, 2000. Besides the loss of electrical power, natural gas has been curtailed and meteorologists are predicting a freeze. The power and gas company report that they have full crews working on the problem but cannot tell you when the systems will be operational. They are blaming the problems on Y2K, the Year 2000 bug. I don t know about you, but this would be my worst nightmare.
Some experts are predicting that the above situations may indeed happen if we ignore the Millennium Bug/Y2K/Year 2000 problem. I am acknowledging that I am an old timer in the facilities business and rely heavily on the bright folks who have grown up with computers. I turn to them when something does not come on or when the screen freezes up. I am a big "dummy" when it comes to understanding this one-eyed monster that controls four to five hours of my daily life. Now that I have established my expertise on this issue, let me tell you of my fear of the unknown that is less than 15 months away.
A year ago I started reading articles and having discussions with my associate directors about the impact on our institution s facilities of the Year 2000 (Y2K) change. Our concern was with the change on computer calendars and clocks from 99 to 00 and how the systems might read that two-digit year as 1900, not 2000. At first, we felt somewhat smug in thinking that the Y2K change would have almost no impact on the systems we own, operate, and maintain. In thinking back now, I still cannot remember why we felt this Y2K thing was not something to worry about. I guess I felt that it was a system/telecommunication problem and that the computer people would come up with a solution well before 1/1/00. We all felt that many systems were simply time clocks and, if need be, we could just turn them back to a prior year. No problem. Everything would be under control.
In April 1998, the University of Texas at Austin (UT) sponsored the Big 12 Physical Plant Conference. Our assistant vice president for administration went to the conference along with several physical plant managers. They brought back a paper that was quite impressive in describing UT s efforts to limit the impact that Y2K would have on their operation. I still believed, however, that we had everything under control at A&M.
Last May I received a magazine article that discussed the Y2K impact on embedded systems. I soon discovered that we were not as prepared as I thought. That little queasy feeling in my stomach was moving up to my brain; you know the kind that tells you to look further and deeper. I want to point out that I was a little disappointed in the previous responses I had received, but I now realize that my people were giving me what they thought was the correct response. The problem was mine. I was ignorant of the facts and was not asking the right questions. I sum that up as a leadership problem. I again reviewed the handout from UT and started searching the Internet for more information. I discovered that there was too much information for me to read, understand, and quickly get an overall view of the problem.
I knew I had to get the ball rolling, so I asked the associate directors to tell me who their smartest technical staff members were. I formed a task force to advise me of the full scope of our problem and work directly with me to develop solutions. I am convinced today that being ready for the Y2K change is the highest priority I have. I am delegating some of my duties to allow time for me to stay on top of this problem. The good news is that we can be ready, but the bad news is that it will take many staff hours and even more money ($500,000 to $1 million) to get us there.
There is no need to reinvent the wheel in approaching this task. The first action is to find out the different types of systems you have on your campus, then determine if they are Y2K-compliant. Second, prioritize the systems in order of importance 1) life safety, 2) mission critical, and 3) other. For example, your power plant operation will be much more critical to your education and research mission than a time clock that controls an air handling unit in the administration facility. You should run these priorities by your vice president.
Third, get an inventory of all components for the different systems. You should pay special attention to the embedded chips. Some embedded chips were developed in the 1970s and will read 00 as 1900. I am told that the chips report this information as 1900 and then your system logic (whatever that means!) will get confused and shut down. The basic guideline is to test each and every embedded chip, if you have time. If you have less time, you may elect to check one of a group of similar chips, or you can take the manufacturers word that it is okay. Both are risks but are your decisions to make. I strongly advise you to test everything you can as soon as you can. The period between this Christmas and New Year (when most of our institutions are closed) is a good time to test. Plus, this will give you one year to develop the solution to any problems you identify.
I am told that there are some shortcuts if time and money are critical issues on systems that are not date dependent. For example, if a clock controls elevators on a seven-day schedule and is not date dependent, you may ignore it for the time being. Even if it is date dependent, you can probably set it back 11 years to buy time and money (the calendar repeats itself every 11 years).
Another more risky technique is to disconnect the noncompliant components from the central system, which allows them to function as standalone without putting your entire monitoring system out of business. As stated, this is somewhat risky, but if the central monitoring system shuts down or receives bad data, you may be worse off. Note: I am not recommending this processing. I only mention it as a consideration for those folks whose backs are up against the wall and will be trying to prevent total system failure. Of course, we could always return to the old days by hiring temporary security or conduct fire watches to safeguard life and property.
There you have it. That is all I can suggest for facilities professionals behind the power curve. Please do not rely only on what I say. There is more information on the Internet than you can handle, as well as books to read. Also UT has a checklist that is on the Web at www.utsystem.edu/oir-year2000/overview.
Don't get caught short! Ask the questions. Go look for yourself and test as soon and often as you can. Don't let the "millennium bug" become your worst nightmare!