|
So, you thought that fixing a trillion lines of code is a big problem. It's child's play compared to the embedded chip problem. This, according to a long article in EE TIMES (Jan. 14), an electrical engineering trade journal.
Note the old urban myth, airplanes dropping from the sky. Some catch phrases are as irresitible to y2k reporters as assurances of compliance in December, 1998, are to corporate press release writers.
* * * * * * *
There's been a lot of hoopla about the possibility that a banking program or payroll application will freeze up at the turn of the century, but observers are now growing far more concerned that deeply embedded systems represent a far bigger problem. It's fairly simple to determine whether a PC's software package will work correctly, but it's much more daunting to tell whether a nuclear plant, factory system, elevator or other system with embedded firmware might be brought to its knees by the "00" in a dated time stamp.
Though often hidden, the embedded problem may have far more impact than the one in front-office computers. It's unlikely that airplanes will fall from the sky when the 1990s end, but observers say portions of factories may fold, oil drilling and piping systems may freeze up and other embedded hardware may grind to a halt. . . .
Sensory overload "This will be a far bigger issue on the plant floor than in a mainframe," said Bill Heermann, sales director at Tava Technologies, here. "In a mainframe, you've got software that's only looking at about five streams of data. On the plant floor, you've often got 10,000 electronic sensors, and in one fashion or another, each sensor is a data stream that has to be examined. One of those 10,000 sensors may begin feeding bad data to networked devices above them and bring down the whole network, shutting down the plant." . . .
Some of the difficulty may lie within real-time operating systems. "There's an issue here," said Arthur Orduna, director of marketing at RTOS vendor Microware Systems Inc. (Des Moines, Iowa). "For example, you'll see it a lot in the single-board-computer industry."
There, Orduna said, companies have a wealth of VME-based SBCs running RTOSes in fac-tory-floor applications. The boards perform data-collection functions which feed into large databases. "Anything that's database-oriented--which is where year 2000 really comes into play--and is tied into data-collection and industrial-automation scenarios is going to be at risk," Orduna said.
At the same time, he claimed, there's little risk for embedded software in consumer applications. . . .
Elsewhere in the embedded-systems industry, however, parts may be used for many years. And several factors make it far more difficult to check for year-2000 problems, not the least of which is that embedded processors are by design scattered about remotely, not sheltered inside climate-controlled offices.
Worse, many companies have not yet realized that embedded systems face the same potential problems as their office counterparts. Consulting firms are just now beginning to shift some of their focus from the office to production environments, but the number of people studying embedded systems is far smaller than in information technology.
Those responsible for checking embedded systems will usually have to go over each unit individually, often because embedded computers have firmware that's been revised at a given site. For instance, a production machine in a Chrysler factory might operate differently than a similar model used by Ford.
Checking out those systems often requires probing the chips or motherboard, since many embedded systems don't have disk drives, instead housing programs in non-volatile memory. Compounding the problem, embedded systems made by the same company may well use different chips and different versions of the firmware, so there's no certainty that two seemingly identical systems will perform the same way when the 1900s end. . . .
Even the time-consuming task of shutting down a system for testing often isn't the hard part. The ubiquity of microprocessors and their wide distribution means a nightmare just getting to each of the independent CPUs. In many cases, these remote devices don't have I/O systems, so checking out the chips can be difficult.
|