This was posted on AOL by Zebra
It seems there may still be some confusion as to the difference between TPRO and KEA or VIAS. I sent this E-Mail to a friend and she asked that I post it here. Now HERE I AM WAY OUT OF MY LEAGUE in terms of technical knowlege, so I actively invite corrections to any errors.
The Y2K problems that TPRO is gearing up for are in EMBEDDED SYSTEMS. This means EPROM and PROM type chips with real-time clocks or date functions that are not Y2K compliant. In most cases the chips must simply be replaced but the trick is finding them all. TPRO's CD-ROM is a key to a compilation of all the data they have gathered over many years of working with Embedded Systems. It is the "treasure map" to finding the chips in your factory,
replacing the ones that need it, and issuing Vendor Compliance reports so that your person in charge of Y2K can finally say, "everything is fixed that needs fixing."
This article below can shed some light on the topic. All of the "Other" Y2K companies are involved in fixing software, often old COBOL programs. The difference is that there it is a Software problem. With Embedded Systems, it is a Hardware problem. Like replacing the BIOS or mother board of an old 286 machine (PLC's or Process Logic Controllers are just rugged versions of desktop computers with a single function in a factory) which will not
handle the date change. But Embedded Sytems is much more than PLC's, PLC's are easy.
So you see there probably will be a software solution to the business or "IT (Information Technology)" Y2K problem, perhaps it will be CA's. This is why I've never bought any of the other Y2K stocks, I think there will be a real silver bullet on that side, and the price will tumble.. But none of that will affect TPRO, except perhaps if the investing perception turns into the idea ALL Y2K problems have been fixed.
memagazine.org
Only now are companies becoming aware of y2k as it concerns manufacturing operations. "Most manufacturing firms have a y2k corporate project in place already," Owen said, "but very few have kicked it in at the operations side of the issue. The problem's been a combination of people in plants thinking it's strictly a downstream corporate/IT problem and the
corporate/IT people not being aware of how the systems are running in plants." This is Ken Owen who came to work for TPRO from Fluor-Daniel
Embedded Bugs
"Embedded systems are everywhere," Owen said, "in chips, circuit boards, proprietary units, and so on." Unlike corporate programs that use languages like COBOL and can be rewritten, "these systems have hard-coded logic that we can't get the source code for, so they require a whole different approach for testing and resolution. Unless fixed, they can be the source of bad data, especially with date/time stamping. . . . High-level systems, such as those
for analysis and scheduling, may have more problems because they'll be working from 'injected' bad data." Inventories, which often rely on such date/time stamping, may not be restocked properly because of misread years.
Any manufacturing-related process that is measured over time can be affected. For example, a number of smart sensors have the ability to track when they were last calibrated, and they issue a signal if they operate past their scheduled recalibration date. Many of these instruments currently use the two-digit year, so after Dec. 31, 1999, they will quite likely go out of calibration.
"Plants won't come crashing to a halt," said Miklovic, who specializes in plant-floor systems analysis, "but they may degrade in performance." Because dates in embedded systems would be misread, manufacturing plants will enter a fail-safe operating mode-similar to when a car fails in its internal diagnostics and enters a "limp-home mode." "Performance economies will suffer, profits will be affected, and it could take people a while to figure out
what's going on," he added.
Another reason why estimates of the y2k problem are conservative at best is that systems running in the plant usually are not managed the same way as corporate IT systems. "It's not a rigorously managed environment," Owen said, "like those dealing with legacy projects [that involve COBOL and old programs]-no control libraries, no database managers, no version management, minimal change control, and the like." Furthermore, plants often have
proprietary software to run various mechanical systems such as process controllers that have no readily identifiable version to manage and update, nor most likely compliance with the year 2000. The same is probably true with "hidden applications" written on the factory floor-scheduling and product configuration performed on spreadsheets, for example-without the help of IT personnel.
All of this makes it difficult to gauge how much work is necessary to get the plant floor ready. Many operations still use older computer systems and have no regular, planned means of upgrades. "Some would argue that any PC put in a plant is taken out within five years," Miklovic said, "but are they really? When you get to the factory floor, there are still a lot of plain old 286-type machines out there that are in dedicated-operator type of
situations, and they have been there for many years already."
Time Is Not on Their Side
Of course, the y2k problem has to be fixed to keep plants running properly. Some companies have the capabilities to focus on fixing the bug in both corporate systems and factory operations. Ford Motor Co. in Dearborn, Mich., for example, has established a central program office that has been assisting both plant and IT operations to assess the entire business: reviewing each operation; evaluating which programs have to be rewritten, altered, or
upgraded; and determining what needs to be adjusted on the factory floor and elsewhere. In addition, Ford has created an accelerated conversion center as one of several approaches to address all of its "mission-critical" systems-what's involved in running the business day to day.
The biggest job in eliminating the millennium bug is just finding all the components that use dates. The company expects its mission-critical systems to be y2k-compliant by the end of 1998, giving Ford a full year to test all the systems and guarantee their operation.
Staff in many other corporate IT departments, however, often stick with the familiar: software upgrades, program recoding, and computer models. According to Miklovic, even in manufacturing firms, IT personnel have focused on the classic business-system issues, such as buying new enterprise-resource-planning systems that can handle the year 2000, and most companies haven't begun to look at the plant floor.
The biggest part of the job, he added, is not fixing the problems but finding them-which components use dates. A number of tool sets exist for non-y2k-compliant corporate computer programs, such as those in accounting or scheduling departments, that can scan software, recognize date fields, and flag their occurrences to be reprogrammed. Such scanning tools, however, are not effective for manufacturing
operations and their proprietary, embedded, non-COBOL-based date logic.
Instead, managers have to go back to their device and component vendors to find out about compliance. Sometimes that means getting a patch to cover a problem; more frequently, an out-of-date machine needs to be replaced. "Almost every vendor states a compliant position from some product release forward," Owen said, "one that's just out or one that will soon be out. Very few are doing "backwards assistance'" for earlier versions.
The best vendors are in the process of determining their own product compliance, Owen added, and they're making the data available. "Allen Bradley in Milwaukee is a good example. For several months, the company has had compliance data on the Web-and discusses what testing has been done-for programmable logic controllers and relays."
The vast majority of vendors, however, are aware of the y2k problem but are still forming committees, according to Miklovic. At that point, "you have to decide whether your vendors understand the problem," he said. "If they don't understand it, there's no guarantee that a replacement will work. If they understand but don't have a solution at hand, you have to assess their ability to develop a solution in a timely fashion. If they do have it, then go
ahead and do it through a patch or replacement."
Time, however, has become the biggest enemy for all conversion efforts. Most experts agree that all y2k projects need a full year to test all possible fixes, leaving little more than a year from now to find and fix all millennium bugs. And the deadline-Dec. 31, 1999-is immovable.
"You are never going to get it all fixed," said Owen, whose firm began offering y2k services specifically for manufacturing operations in the last few months. He recommended prioritizing: identifying and addressing y2k dilemmas first in the mission-critical parts of the organization (what is needed just to survive, or "if we fail here, we're down in a big way"); then areas that are very important but not mission-critical; and finally the
"nice-to-haves" that can be either worked around if they fail after the deadline or dealt with much later.
Owen also suggested that a large operation with many facilities should not try to fix them all in one shot as its first step. Instead, pilot sites-two or three typical facilities-should be selected. "If you do a good selection," he said, "you can quickly develop good representative feedback for company executives, who can then look at the size of the problem and likely exposure. They can then determine the approach for the entire company."
"There is no average manufacturer when it comes to this problem," Miklovic added. "Some firms can spend just $10,000 doing an audit, finding a couple of minor problems, and fixing them; others will have to spend millions of dollars finding and fixing. There is no one solution."
Hope this helps explain the HUGE difference between TPRO and all other "Y2K Companies."
Zebra |
