Embedded Systems Turn on Crowd
October 17th, 1997
Here's the thing about embedded systems.they may not have the
Y2K visibility of big iron applications and they may not be
getting as much attention. In fact they may be the last item on
corporate America's millennium to do list. But expert David
Hall says it's just a matter of scale. Firmware and microcode
get incorporated into microprocessors and programmable logic
controllers (PLCs). And this type of logic is just the downsized
version of its software cousins, programs running on mainframe,
midrange and desktop computers.
The same people who designed mainframes designed microprocessors,"
Hall says. "It's the same logic pattern from mainframes to
midrange systems to PLCs. The logic flow trickles down." There is,
however, at least one important difference. PLCs are virtually
everywhere. In factories, phone switches, medical devices,
transportation, security and intelligent building systems, environmental
control equipment, point of sale devices and much more.
Hall heads up the Society for Information Management's Y2K task
force on embedded software issues. He spoke this week at an
industry conference and clearly drew the lion's share of crowd
interest. Trained as a mechanical engineer, Hall built an Air
Force career managing advanced technology programs in aerospace,
logistics and intelligence.
According to Hall, under the hood, PLCs are built with languages
like assembler, with the same two digit date references and
programming gadgets, like using specific dates to signal
end-of-file processing. While engineering standards may include
an overall safety check, no standards apply to the actual
programming of component.
Hall says the problem persists in some PCs. Here's why.
Real time clock chips provide a current date and time to the
computer's BIOS chip. Real time clock chips are built without
Y2K compliance standards, Hall says, and will roll to 1900 at
the century change. Manufacturers have hundreds of thousands
of these chips in inventory and continue to use their existing
stores. For the PC to achieve Year 2000 compliance, the embedded
code of its BIOS chip must be programmed to handle the century
conversion. If the BIOS is not programmed to correct this error,
it will present 1900 to the operating system.
Even though application software and microcode may share common
ancestry, Hall says that when it comes to organizations seeing
the bigger picture, embedded systems are the great divide.
"The MIS department is taking care of mainframes and midrange
systems and maybe PCs. Embedded systems fixes are the concern
of a back shop engineer or they are outsourced to a third party.
Companies don't try to fix their phone systems or building
management systems. Even though they are similar, there's enough
distance between computers and embedded systems that the twain
never meet."
Here's another important nuance about embedded systems.
According to Hall, no TWO ARE THE SAME. "The problem is that each
is UNIQUE" Hall claims. "There are many options and they are easy
to change." That means that the PLCs in factory A could be different
than those in factory B and no generic testing will be effective.
It's a problem with multiple dimensions. In a manufacturing environment,
for instance, information from systems on the factory floor will feed
business information systems which, in turn, could interconnect with
external suppliers and customers. Conversely, because these systems
are highly integrated, a single PC might be controlling upwards of
200 REALTIME SYSTEMS. "If two or five or ten of these systems have
problems with dates, that could corrupt the PC, which could then
shut down the process," Hall says.
Such a circumstance could mean multi-million dollar productivity
losses, environmental accidents or worse. Hall cautions companies
to follow along a familiar path: inventory, assess risk, fix, test,
perform triage, and build a contingency plan. Fixing the dates in
a highly sophisticated numerical controller or other device is, of
course, a different kettle of fish, work not just any COBOL programmer
can perform.
Hall says organizations have three choices: contact the manufacturer,
use the individual or firm performing normal maintenance to conduct
an engineering evaluation (SEE TAVA), or hire someone else with
sufficient knowledge and experience to perform this work (SEE TAVA).
Unfortunately, although Door Number One seems like the easiest and
most direct approach, it may not deliver the anticipated results.
"If you have systems that have been modified to meet your particular
specifications, you can't call the manufacturer and say, Will it work?'
Unless the manufacturer installed the system, they won't know how it
has been modified." If systems have been changed, and most are,
Hall suggests contacting the manufacturer for information,
specifications and the like. For instance, a device may not use
dates at all. Good information to have when going to fix it.
"Start building a matrix of what you do know," Hall suggests.
And start preparing for what is not known too. "Does an organization
have a fail safe design in its systems," he asks. "What happens
when your systems have bad logic or try to divide by zero? Will it
stop, go into an endless loop or turn on an alarm? Assume that it
is going to happen and plan for it." |
