Writeup about TPRO and Y2K problems in embedded systems
First let's define what's an embedded system. An embedded system is a small computer-based system that controls the operation of a device (electrical or mechanical), or a motor, or a bunch of input sensors. A walkman or a TV can be considered as embedded systems also but let's concentrate here about industrial embedded systems only.
A typical embedded system receives inputs from sensors and its output is triggered by an event. Lets take the example of a sawmill.
Somewhere, there is a control panel where the operator can entered the number and size of lumbers to be cut. The command to cut (event) is sent to a controller (embedded system) where a number of lumbers will be loaded on a conveyor belt and a sensor will make the count (input). After the requested number of lumber gets loaded, the motor on the conveyor belt will get started (output), and the load of lumber then goes to a saw. Another controller (embedded system) will control the saw (output) to cut the lumber based on the lengths (input) entered by the operator. The number of cut lumbers are sent back to the control panel computer (typically a PC or minicomputer or mainframe) where it will recalculate the inventory, generate a billing to the accounting software, and produce a report. So where is the date used? Only in the control panel computer where the accounting, inventory, and report are generated. Do the embedded systems need to know about date? No, obvioulsly. Everything inside those embedded systems are running on clock ticks, not on clock time or date. For instance, every 10 msec, a sensor will detect the position of the lumber and the saw, then the embedded system will reposition the saw blade to make the proper cut. All the input and output are based from the time an event was triggered (command from control panel to cut a piece of lumber at certain length), and not based on the clock time. Yes, there is Y2K problems in factories, but the problems are on the mainframe side, not on the embedded systems side.
Then there are may be a few other classes of embedded systems where the operation is based on the clock time, and the time and date are maintained locally for redundancy. For instance, the article posted by John Mizgalski described embedded systems for load dispatch or remote switchyard inside an electric utility that perform certain function at a predetermined time schedule. Those kind of systems are rare and account for may be less than 5% of all embedded systems.
That's why we don't hear much about Y2K problems in embedded systems. All of the Y2K contracts announced so far are on the mainframe side and in the business software. IMRS has won several contracts with utility companies and they are all for mainframe code remediation.
So where does TPRO stand in this Y2K remediation for embedded systems?
I went to TPRO web site and saw that this is mainly a low tech integration house. The company does not build embedded system, nor any hardware, nor do they seem to have any expertise in assembly language programming, a desirable skill in embedded system design (check the employment, only looking for software engineers with high level language programming skills). TPRO buys Programmable Logic Controllers (PLC) and other hardwares from Allen-Bradley, a good supplier of hardware components for factory automation. So basically, TPRO buys modules from other companies, does a little bit of programming, and integrates them in factories.
How does TPRO go about Y2K code remediation? Their web site describes a bunch of planning steps mainly to impress management such as plant inventory, block diagrams generation and then search of Y2K problems. This is how the Y2K search process is described by TPRO:
Search Y2kOne is diagnostic software designed to uncover date usages through a textual search. Once the software applications have been inventoried under the Plant Y2kOne code collection procedures, Search Y2kOne allows the user to select the types of search required for the specific software that was used to produce the suspected runtime applications. In addition to search designated program source code, it also examines the script languages in custom code and packaged software for parallel application spawning to make sure that all possible system applications are examined.
Search Y2kOne delivers much more functional power than the average business system's text search utility. Unlike conventional techniques, it doesn't rely on creating search patterns based on outdated or lost documentation, or personal interviews. With its diagnostic capabilities, all potential Y2K issues are marked, counted and assigned complexity factors that allows for the automatic evaluation of the repair effort.
So for God sake, TPRO will do a textual search of the code. Typically in the old day, the code in embedded systems was written in assembly language. I hope first that the source code can be located. Then I hope that the code is documented well enough that the search can find keywords such as date, year, etc. So let say TPRO finds the bad code, then what's next? First, the code is burned in ROM or EPROM. TPRO needs to find some free space inside the ROM or EPROM to insert the new code. In assembly language, sometime programmers use absolute addressing, so TPRO better be careful in moving the code around. Oh, I forgot that TPRO has no experience in assembly language programming. I think TPRO's solution will be to propose the hardware be replaced with the PLCs from Allen-Bradley. Honestly, I think that's probably the best solution.
I also think that TPRO has expertise only in manufacturing factories. TPRO does not have the capability to fix embedded systems for electric utilities, telephone companies, nuclear plants, etc. That kind of code is too complex and can only be fixed in house or by companies such as GE, Westinghouse, Honeywell, Fluor, etc. who specialize not only in embedded systems but also in building whole elecric plants, manufacturing plants, or chemical plants. Surprisingly, none of those companies has announced any business in Y2K code remediation, while we see IBM, Oracle, EDS, CA, etc. announcing their entry in mainframe code remediation. Why? Because there isn't much.
What does the BMY contract mean?
As I stated before, I doubt that there is much Y2K problems in factories. I suspect that the assessment contract with BMY has to do with upgrading some of their embedded systems but has nothing to do with Y2K. But TPRO may be clever to propose to BMY to do the Y2K assessment for free and BMY's management says sure. So now TPRO can put out a news saying they do Y2K assessment for BMY. As a matter of fact, going to TAVA's web site, I see the Y2Kone logo pasting all over the place. That can imply factory upgrade for the future (year 2000), or that can imply code remediation for year 2000. Yes, they are trying to create a nuance so people will think they are doing Y2k work when in fact they are not. I think TPRO management is managing the stock price, not the company. Why in the hell do they have to announce a pilot project? Every single contract announced by IMRS, CBSL, SYNT, KEA is always a real contract with real dollars. While the stocks of those companies were tanking last month, management made no effort to put out phony news just to maintain the stock price. TPRO is clearly trying to hype using hot words such as Y2K, embedded systems to maintain the stock price. This is the only company that proclaims to be in the Y2K code remediation for embedded systems.
Oh btw, these are the links to other SI threads where you can ask questions about Y2K problems in embedded systems and get second, third opinions:
- Wind River (WIND): this is a company specializing in real time OS for embedded systems
exchange2000.com
- RadiSys (RSYS): this is a company specializing in real time OS and hardware for embedded systems
exchange2000.com
- Integrated Systems (INTS): also a company making real time OS
exchange2000.com
==============================
OK, I am done with this writeup and sorry if it is unorganized. Writing was never my strong field. |
