Running Out of Time: Intelligent Transportation
Systems and the Millennium
U.S. Dept. of Transportation PTI (Public Technology Inc.)
Table of Contents

Acknowledgments

On the much-heralded day of January 1, 2000, many of the computers and chips embedded in the heart of community's infrastructures will be unable to recognize the actual date. Normal data transmissions, transportation and public safety operations, and financial transactions may be performed irrationally, or not at all. This primer describes how state and local officials use their leadership to avert the negative impact on their communities.

This primer was made possible through the contributions of researchers and discussion groups participants. Special thanks go to Clint Page, Kathleen Guzda, and Robert Hicks, who authored different sections of this primer for the U.S. Department of Transportation; and the Urban Consortium's Transportation and Telecommunications and Information Task Forces for their vigilance and work in identifying issues critical to local governments; and to PTI's internal Year 2000 (Y2K) team.

Public Technology, Inc. (PTI), is the non-profit technology research, development, and commercialization organization of the National League of Cities (NLC), the National Association of Counties (NACo), and the International City/County Management Association (ICMA). PTI's mission is to advance the development and use of technology in local and state governments.

PTI's Urban Consortium (UC) is a special network of the nation's largest cities and counties that focuses on new solutions to common concerns. The UC provides a creative forum for elected and appointed officials to identify practical ways to improve the provision of public services while generating new revenue opportunities.

The UC addresses the critical needs of large local governments through five technology task forces: Energy, Environment, Telecommunications and Information, Transportation, and Public Safety. The task forces are staffed by representatives of the UC member cities and counties who are experts in these areas and have extensive experience managing practical challenges in their jurisdictions.

UC members act as urban laboratories to develop and test solutions as well as to share new technologies and management approaches with other local governments, both large and small, across the United States.


Preface

The Year 2000 (Y2K) challenge is real: Unless we take action now, our communities may be severely weakened on that fateful Saturday morning in January 2000. Regional economies may falter, public safety and health may be compromised, and our citizens may become frustrated and begin to look for places to lay the blame. Even though the issue reflects programming choices made decades ago by people in both industry and public service, it will test our state and local government leadership mettle like no other challenge in recent years.

Yet, the Y2K challenge also presents a golden opportunity to show local and state agencies and the private sector how truly essential transportation institutions really are. We hold in our hands a winning strategy to keep our national economy going through what may be rough times. We can adopt the following four-part approach:

  • Prepare the community through awareness programs that mobilize multiple resources;
  • Establish solution transfer mechanisms through alliances;
  • Steer all sectors of the state, regional, and local economies toward true
    collaboration and interface management; and
  • Develop contingency plans to combat breakdowns if they occur.

It will take leadership for government to be ready!

This primer on intelligent transportation systems and Y2K is one element of a comprehensive campaign launched by Public Technology, Inc., and its three sponsoring organizations, the National League of Cities, National Association of Counties, and International City/County Management Association. It marks the start of our commitment to overcome this challenge, and indeed, to make it an opportunity for forging stronger public/private alliances at all levels of government.
Federal and state government organizations have already announced their commitment to this national campaign. We intend to include state, regional, and local government organizations so officials in all communities, no matter what their size, are aware of the Year 2000 Problem and have the tools and resources to develop effective solutions.

Costis Toregas
President, Public Technology, Inc.
 

The Year 2000 Problem

Call it the Year 2000 Problem or the Y2K Problem, and it sounds like a technical glitch. Call it the Millennium Bug, and it sounds like an end-of-the-world science fiction thriller. Whatever we call it, the problem is real.

Nobody is sure what computers--or for that matter, any of the countless devices and systems controlled by microchips--are going to do at the stroke of midnight when December 31, 1999, rolls over to January 1, 2000. Some computers and systems will make the change smoothly. Some will stop working. Others will behave erratically.

Why? During the early days of computing, when processing power and storage capacity were puny compared with those of today, programmers and engineers reduced the space needed to store dates by recording only the last two digits of the year; Valentine's Day 1980, for example, was stored as 021480. (They saw no reason to store the slashes between the month, day, and year, either.) When this century ends and the new one begins, that practice will present a problem. Computers won't know the difference between Valentine's Day, 1901, and Valentine's Day, 2001. They will both be stored as 021401 and collide in the confusion.

Traditional mainframe computers, dominated by older programming languages such as COBOL, FORTRAN, and others, are where the problem has its roots. But virtually anything, and everything, that relies on embedded process controllers (microchips) will be affected. The multitude of personal computers are threatened. Many older IBM-compatible PCs will not be 'Y2K-compliant,' (see definition, left) but machines sold after 1997 generally will be.

Macintosh computers will not have a Year 2000 problem, because they store the date as a number based on the number of seconds since January 1, 1904. This system will handle the year 2000 just fine, but apparently has its own problem: At 6:28:16 a.m. on February 6, 2040, the total number of seconds since Jan. 1, 1904, will be too long a number for the allotted storage space to handle.

Microchips also control security elevators and doors, telephone switches, traffic signal controllers, and electric utility substations, as well as small household and office appliances. Industry experts predict that of the 25 billion chips in electronic components, only about 2 percent will fail, but which 2 percent? In many, perhaps most, cases these devices will just stop working. Elevators will descend to the basement or go into security mode; VCRs will work but will not be able to be programmed.

The problem is not just hardware and chips. Any software that stores and uses dates--spreadsheets, databases, financial management software of all kinds, human resources software, and a host of other programs--is vulnerable to the Year 2000 Problem. By extension, all the data files used by those programs are also vulnerable.

In ways that may not be obvious, transportation systems too are susceptible to the problem. The complex links between public and private systems that move people and goods usually involve computers or automated systems somewhere along the way. With the growth of intelligent transportation systems, the use of computers has multiplied in transport and emergency management systems. Many of those systems include dates in their calculations. The consequences of such systems failing range from annoying inconveniences to life-threatening disasters.

Although plenty of attention has been focused on the dangers of a confused air traffic control system on January 1, 2000, other transportation snafus that may demand a remedy are timed traffic signals that no longer time, intelligent transportation systems that are suddenly dumb, and electronic parking or toll passes that do not permit passage. Buses could be thrown off their timetables, and parking ticket records might no longer be recorded.

Unlike new personal computers, new sophisticated transportation systems are not safe. The burgeoning number of transportation systems that rely on satellite global positioning systems will face an additional punch, a sort of 'mini-Y2K,' on August 2, 1999. Then, the atomic clocks that keep track of time by counting the sequence of weeks since Jan. 5, 1980, will run out of bit space and 'roll over' to Week 0, with the possible result of inaccurate position calculations. In short, anything electronic that depends on dates or on calculations involving dates is vulnerable.

 You're susceptible if:

  • You have any central or mainframe computer that stores data vital or important to your state and local government transportation systems.

  • You have a local area network (LAN) over which data and files are shared, thus allowing dates to be entered in a variety of ways.

  • You use personal computers. The device inside the PC that retains the date and time when the system is turned off often cannot store a four-digit year. It will give your operating system an invalid date after January 31, 1999 (perhaps something like 1/1/80).

  • You electronically store any data with a two-digit year.

  • Your telephone system has programmable switches. Phone systems are almost all controlled exclusively by software, and if the date clocks are not Y2K-compliant, the whole system is not Y2K-compliant.

  • You have automated security systems with computers that automatically lock and unlock doors and elevators at night, open them in the morning, and keep them locked on holidays and weekends.

  • You use global positioning systems (GPS) to locate emergency vehicles. GPS devices determine  distance by measuring how long it takes to get a signal from several satellites in stationary orbit. On August 22, 1999, many will fail to calculate time correctly. The uses of intelligent transportation system (ITS ) range from tracking emergency vehicles or buses, to mapping road accidents or potholes.

  • You use automatic data collection systems, for example, on city-owned parking meters or electronic toll booths.

  • You have computerized traffic signal systems, gates, toll booths, subway elevators, or other public transport mechanisms that rely on computers to open or close them, or automated systems that operate them according to programmed times.

A Mandate for Leadership

By now there have been enough Chicken Little warnings that everyone should be looking at the sky. The consequences of ignoring the problem until New Year's Day 2000 could be great: messy complications that won't be easily sorted out; snarled transportation; angry taxpayers; irate businessmen; lawyers bearing lawsuits. Elected officials could become 'unelected' over their failure on this issue; civil servants could find their constituents most uncivil.

The bad news is, if your state and local governments have not yet begun to address the Year 2000 Problem, it already is late. The good news is, most responsible cities, counties, and states have begun to take remedial steps, typically starting with obvious areas such as public safety systems or the computers that handle accounting and payroll.
The purpose of this primer is to encourage administrators and officials to look at the less-obvious--but potentially troublesome--problems that may occur in the vital transportation area.

Systems at Risk

The challenge of spotting potential Year 2000 problems in intelligent transportation systems (ITS), and fixing them before they occur, is complicated by the hybrid nature of the nation's transportation system. Most ITS are a mix of private and public enterprise. Often, the public portion of the responsibility is shared among local, regional, and state governments, transit authorities, and other entities.

This entwined nature of transportation makes it all the more important for elected officials and administrators to look closely at the computers behind their roadways, traffic signal systems, trucking regulations, airports, shipping ports, rail hubs-in short, behind anything that moves. Chances are, a computer is involved somewhere, and if that computer uses dates, it could be the weak link that breaks the chain.

The private users or other governmental agencies involved in the transit system cannot be counted on to tackle the problem, nor can the manufacturers or vendors of computers and other electronic equipment. Many companies are not sure what will happen with their systems. Others are unable, or unwilling, to provide a cure. Even recently purchased hardware and software cannot be assumed to be Y2K-compliant; check it.

Finally, even if your hardware and software are able to handle the turn of the millennium, if the data has been entered with only two digits to represent the year there may be trouble lurking. The systems may work, but the data may not.

Here are some transportation areas that may be troublesome on January 1, 2000:

  • Intelligent Transportation Systems: Increased use of ITS may pose a major problem. Among uses that are vulnerable: timed or coordinated traffic signals; 'smart tags' or 'smart cards' that use dates, such as an expiration date; information kiosks and automated vehicle message signs; and some public safety systems as vital as 9-1-1 or as routine as an accident-mapping project. So concerned is the federal government about ITS, it scheduled a national summit meeting for the summer of 1998 to discuss the problem.

  • Integrated Transportation Systems: The entire intelligent transportation infrastructure is at risk as integrated systems made up of both new compliant and old non-compliant component systems must interact and communicate.

  • Advanced Traveler Information Systems: Any scheduled services--subways, buses, trains, or planes--could be felled by a Year 2000 malfunction of date-sensitive computer systems. Schedules may be confused, route maps may disappear, and staffing plans could be snarled. Dispatchers may be scrambling to make error-free manual schedules.

  • Traffic Management Systems: These systems measure and report traffic levels throughout metropolitan areas. The Millennium Bug problem has a potential impact on data derived from these systems and used for traffic reporting and control and emergency management purposes.

  • Traffic Signal Control Systems: According to John McCracken of the Federal Highway Administration, "Many of these systems which are centralized, closed loop, and distributed either run on a time-of-day mode or use a time-of-day mode as a back-up to a real-time or traffic-responsive mode of operation."

  • Freeway Management Systems: Driving could become a minefield of interruptions and accidents. Bridges, tunnels, toll booths, ramp metering, electronic lane markers, and rush-hour traffic signals rely on computers for timing. Video images derived from these systems could produce incorrect dates on shots of freeways and arterials.

  • Automatic Vehicle Location Systems: A preview of the problems will come August 22, 1999, when the worldwide global positioning system (GPS), a set of satellites installed by the U.S. Navy to provide pinpoint-precise navigation and time of day, will experience its own anomaly. According to the Navy, "Some receivers (of GPS services) may display inaccurate date information; some may also calculate incorrect navigational solutions." It is a somber possibility, since thousands of ships, planes, missiles, weekend explorers, and recently, new cars rely entirely or in part on the GPS.

  • Smart Goods-Movement Systems: Movement of goods and freight involves a vast system for keeping track of inventory and moving goods on time. Date-sensitive computer systems are everywhere, from the private warehouse, to the city's industrial terminal, to the state's seaport.

  • Emergency Management and Dispatch Systems: Failure to fix the Y2K problem in this area may result in loss of connectivity with outside law enforcement and civil defense agencies, loss of life, danger and damage to personal and business property if emergency notification systems fail, and liability caused by all of the above.

  • Air Safety: The air traffic control system presents the most frightening doomsday scenario. Both the air traffic control system and the airplanes themselves are highly computerized and may rely on embedded date-sensitive systems. The FAA is addressing the problem aggressively, but the task is huge. The airlines themselves face Y2K hazards. Without the appropriate fixes, their records for aircraft maintenance and repair, for crew scheduling, for plane reservations, and for such mundane operational chores as payroll and accounting could become tangled. Some airlines are considering grounding their planes at midnight on December 31, 1999.

  • Water, Rail, and Trucking: Similar problems face maritime shipping, rail yards, and the trucking industry. Such small systems as those operating railroad crossing gates could fail-with disastrous results. Schedules and inventory records could become snarled.

  • In-Vehicle Systems: Some automobiles have systems that keep track of the last time the car was serviced and provide route guidance. They may set off premature warnings on New Year's Day, 2000. Newer engines rely on computer controls with 'embedded chips,' and no one is certain how they will react.

  • Records: If a state licensing department does not respond to the Y2K challenge, driver's license records and vehicle registrations that expire in the year 2000 might be rejected by computers. Rental company computers may reject driver's licenses or credit cards with the offending year.

  • Your Desk: What happens if the personal computer on your desk and all those others around it do not work correctly after midnight of the millennium? Consider all the information stored in those computers essential to your transportation department, and take steps to ensure that these systems are all part of your jurisdiction's Y2K efforts.

Legal Liabilities

The potential effects of the Year 2000 problem seem likely to create an environment in which legal action will thrive. So far, with no lawsuits filed, there are no court decisions and no case law. But there will be.

Warren Reid of Encino, Calif., a legal consultant specializing in Y2K issues, told clients in a recent white paper: "Failing to fix your upcoming Year 2000 problems can not only cause disruption and loss of market share, productivity, and profitability in your company, but will expose the company and you to class-action lawsuits, possible loss of coverage from insurance companies, malpractice for professionals, and director and officer liability-a grand slam!"

Several states have passed laws to protect private business and state agencies from just that kind of legal action related to the Y2K problem. Despite those efforts, and despite the fact that the Year 2000 problem is a technical problem with a technical solution, your city or county attorney should be aware of legal risks.

On The Technical Side

Solving the Year 2000 problem is not technically difficult, even for cases involving embedded microchips.
There are five recognized solutions:

  • Conversion: The only fix that is complete and permanent is also the most obvious: Convert every date to a four-digit year, following International Standard Organization ISO 8601, adopted by the American National Standards Institute (ANSI), which calls for all dates to be entered as "yyyy-mm-dd." Hence, March 31, 1998 would be entered and stored as 1998-03-31.

This approach offers a complete, permanent fix that will change all data records and every application using them. It also is the most intuitive fix. But it requires extensive program and file conversions. Every program in an application must be checked for significant data use and converted; then the entire application has to be converted from its previous form to its new form all at once. Existing data must also be converted all at once, including all active, archived, and security files. This approach also demands a significant amount of new storage space, roughly a 7 percent increase. It takes the most time (of which many are already in danger of running out) and is the most costly.

  • Fixed Windowing: Creating a 100-year window, such as 1936 to 2036, can give computers and software a way to decide which century is appropriate for a date. If the two-digit year is greater than 36, say 47 or 99, then the program assumes the century digits to be 19; if the two-digit year is less than or equal to 36, the century digits are assumed to be 20. This approach requires no change in data, but it provides only a temporary fix. At best, it buys some time. It works only until its appointed time runs out, and at that point it will require reprogramming.

  • Sliding Windowing: This is like fixed windowing, with one significant difference. The 100-year window is calculated from the current date. Each year the software using sliding windows will adjust (slide) the 100-year window one year forward. This approach requires no changes in data, only in date processing routines, and the same code can be used for many years. Production programs, for most applications, can be gradually converted, and they can adapt year after year without reprogramming. If the 100-year window is well selected, it may be permanent and cheaper than ISO 8601. Thus, sliding windowing offers many local governments the fastest, most reliable, and least costly way of dealing with the Y2K problem.

  • Encryption: It is possible to use binary arithmetic to compress dates expressed with four-digit years to occupy the same storage space as those with two-digit years. This approach gives the permanence of full date conversion without the need for more storage capacity. But it requires extensive reprogramming and is not intuitive.

  • Encapsulation: The Gregorian calendar has an interesting quirk: it repeats every 28 years. Because the Y2K problem is related to six-digit dates at the turn of the century, encapsulation simply resets the calendar to 28 years earlier. The computer and its programs do calculations based on a 20th century date and then add the 28 years back in for display purposes. This approach gives a quick fix for situations where the source code is lost or time has run out, but it does not account for religious holidays that do not follow the Gregorian calendar. In the end, encapsulation may be useful only in embedded process controllers in which the actual year is not important, but the day of the week is very important.

A strategy for putting the appropriate technical fixes in place might look like this:


  • Inventory all automated systems and equipment;

  • Test to determine which will be compliant and which will not;

  • Prioritize the results;

  • Find out what remedies to apply;

  • Determine which applications can be fixed on time; and

  • Develop contingency plans for those that can't be fixed on time.

Carrying out this strategy is complicated by two factors. The first is that there are many related areas to find and fix. In numerous cases, application software was developed on a custom basis, or at least heavily customized, to handle local government business practices. These custom applications can be difficult to maintain, and some are too old to change. Even a medium-sized local government or business could have millions of lines of program code, any of which might use dates. Invalid date comparisons could crop up in programs, training, embedded processors, or data. Beyond the computer hardware and software, there are also all those other systems and devices that are controlled by microchips.

The other complicating factor is time. It takes time to make all the necessary changes. The inventory alone for a medium-sized organization could take six to nine months, up to twice as long for a large one, according to some experts. And that is only the computers and software. It may take another three months to inventory all equipment that uses embedded chips. Once the code that needs fixing is identified, maybe 70 to 80 percent can be updated automatically. The rest will have to be read, a line of code at a time, by programmers, and manually changed. At an average rate of 3,000 lines of code a day, that is not a quick job either. With the Year 2000 right around the corner, time is running out, and the deadline cannot be extended.

The Cost of Coping

The time and money it takes to solve Y2K problems in your local government or in your community will very likely be available only at the expense of other improvements and other projects. Solving the transportation-related Y2K problems will add costs to your local government's overall burden in addressing Y2K. How much resistance the cost meets depends, in part, on how much advance consideration there was of the transportation issues, and how thoroughly the problems were identified and inventoried as the local government assessed its Y2K tasks. Obviously, the fewer surprises the better.

There are options, such as the variety of reprogramming solutions discussed previously, each of which carries a different price. The option of replacing older systems before the turn of the century also might become more attractive after a sober look at the cost of fixing the existing system. Whatever the decision, this much is certain: It is not something that can be delayed or postponed. Time grants no reprieves.

Solving the problem requires reprogramming, replacing, or retiring older 'legacy' computing systems-the mainframes and minicomputers that were the mainstays of computing before the advent of the personal computer. It also requires that newer computer systems be checked as well as other systems that use microchips, such as elevator controls and security systems.

The exact cost of doing that will depend on the size of the city and the extent of its use of information technology. Seattle estimates it will spend more than $50 million to reprogram major applications affected by the problem and replace the city's accounting system. Some cities are fortunate to have recently launched major information technology plans that will replace old systems with new ones in time to avoid the Year 2000 problem. In these cases, many of the Y2K compliance costs are covered by funds budgeted for system improvements in the overall city budget.

In Conclusion

The Year 2000 problem presents potentially serious repercussions for the public and private transportation systems on which all of us depend. The burden of fixing the problem falls to government and cannot be shirked. Fixing the problem is not difficult technically; computer experts know the solutions and how to perform them. But those solutions take time and money.

The first step, identifying the problem, takes both technical expertise and a thorough and thoughtful look at the entire range of transportation systems and the supporting casts of computer hardware, software, data, and automated systems. The checklist that follows is a general outline for action for local officials and transportation experts.

Coping With the Year 2000 Problem: A Checklist

Technical Responses

  • Inventory systems.
  • Test for compliance.
    • Hardware
    • Operating systems
    • Custom code
    • Applications
    • Data interfaces

  • Analyze results.
  • Prioritize.
    • Critical systems unrelated to traditional data processing: traffic control,
      water systems controls, etc.
    • Critical data processing systems: accounting, human resources, etc.
    • Systems whose loss would disrupt operations.
    • Systems whose loss would create minor inconvenience.
    • Systems that are extraneous and/or candidates for replacement.

  • Fix or replace hardware.
    • Fix: requires appropriate technical skill.
    • Replace with compliant hardware: Replacement is an expensive option, but it may be the only realistic one for many systems. It also become riskier as we get closer to 1/1/2000.

  • Fix or replace software.
    • Fix the code: requires access to code and appropriate technical skills.
    • Replace with compliant custom or off-the-shelf software.
    • Outsource (at least temporarily) the process to a service bureau whose system is compliant.
    • Live with cosmetic problems or minor inconveniences until they can be finally fixed.

  • Fix or replace embedded systems and interfaces.
    • or replace systems as appropriate are directed to automated systems in elevators, water systems, and building security systems.

  • Don't overlook interfaces with outside business partners.

    • Management Responses

    For Further Information

    Web sites