Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : TAVA Technologies (TAVA-NASDAQ) -- Ignore unavailable to you. Want to Upgrade?

To: Richard S. Schoenstadt who wrote (12122)	3/3/1998 9:41:00 AM
From: Gerald Underwood	Respond to of 31646

Richard, it is clear that you have given this a great deal of thought and your effort is much appreciated. You have approached the idea of EPRI as possible competition in a logical and rational manner. However, and this is a big however, I believe you are arguing a mote point. Even if EPRI and TAVA would both put their abilities into a collaborative effort, it is most likely that they could still not come close to fulfilling the needs of embedded systems y2k remediation. This segment of y2k is reportedly about a year behind the IS effort and some believe it is much larger and will require more specialized expertise. We are down to the wire. The only thing that will get the job done at this late date is some kind of united effort. Let's hope it materializes and TAVA is a leader. Regards, Gerry

To: Richard S. Schoenstadt who wrote (12122)	3/3/1998 11:32:00 AM
From: John Mansfield	Respond to of 31646

Hi Richard, I do appreciate that you have made serious thoughts about EPRI/TAVA! So here I will try to answer your thoughts. I like the fact that we can discuss this in a serious way; without all the mud-slinging that happens occasionally on SI! I have put my reactions to the points you have made in italics << John, With respect to catching up. I used to agree with your position. However I don't anymore for the following reasons. First take Tava's database. They have 10,000 items. So an initial assumption would be that a competitor would have to assess 10,000 items for compliance to catch up. But now I think no. That each industry will have items specific to that industry. Of course there will probably be some overlap but just as an example maybe out of 10,000 items, the utility industry might have only 2000. (example only.) If you look at the ERPI faq sheet this notion is confirmed - i.e. the data developed is not readily transferable to other industries. And the Jan. 29 press release says R.W. Beck will among other things "extend Tava's compliance database to include process automation components commonly applied in power generation, transmission and distribution." >> Ok, but it also might be 4000 or 6000 items; I expect a lot of different objects to be around in those 9000 electric utilities. << Second this press release raises another point. Tava hasn't been working on a database specific to the utility for that long a period of time. Of if so one must assume they decided they needed to help. We don't know exactly when they started working together. But the press release is only about a month old. Give them 3 months that still is not that big a head start on the database portion. >> I do not think that there will be that many objects specific only to this particular industry. But ok, we cannot be sure about that. << Third. If you assume as I do now that each industry has it's own set of components and equipment, then Tava has spread it's effort presumably over multiple industries. Since only 20 people have been devoted to the whole project, since June anyway, it is reasonable to assume that only a small portion of the effort has been devoted to utilities. So that's not much of a head start. And we don't know how much experience those individuals had with the utility industry. Clearly Tava determined they needed help. (This possibility that every industry has it's own unique set of equipment etc. makes it clear to me that Tava with 20 or whatever number of people cannot even remotely compete with concentrated cooperative industry efforts - if they were launched.) >> - Again I do not think that the industry specifics will be such a large portion. - Do not underestimate the lead-time it takes to get all the information together. Again, see Brook's law. 100 engineers working on a project doesn't get the job done 5 times as quickly. << Compare that to EPRI's program or at least it's potential. There are 50 utilities signed up now. Suppose each one only operates one plant and only one person at each plant will be involved with the embedded program. That's still 50 people with direct experience in the utility industry. They could catch up very rapidly to Tava on a utility compliance database. (And suppose instead of one plant the avg. was 2,3 etc. Also note they hope to have 100 participants. Or suppose more than one person was devoted to the problem per plant. You would now be talking about an enormous manpower advantage.) >> No see above; I simply do not agree with you on this. Part of the information is built by asking the manufactuers of the objects; this simply takes time no matter how many persons are put on the job. Also, you want the information to be reasonably consistent. Y2K compliance is not simply a yes/no question; objects can have no problem with 1/1/2000 but with the leap-year; or not a problem with the leap-year but some limitation in the windowing solution etc etc. This makes it much more effective to have a single team doing the complete job (as at TAVA); compared to different people working on different objects at distinct utilities. << Fourth. R.W. Beck will help equalize this manpower and experience But we don't know how many people of theirs have been assigned to year 2k. And further R.W. Beck's people have no self-evident experience with respect to year 2k over anybody else with utility experience. They will need to be trained in the year 2k aspects just like anybody else. >> OK they might or might not have the experience; but from the experience they have they look quite competent. So this is not a clear plus or minus to me. << Fifth Tava doesn't have that big a head start with respect to hands on year 2k experience at utilities. (i.e. developing solutions.) Of the 30 clients they have so far with their 100 or 250 sites, we don't know how many if any are utilities - with the exception of the very recent contracts with Pacific Corp and CMS. >> All the information I gathered so far (Rick Cowles; messages on discussion boards etc) indicate that the experience is rather limited; and also utilities have only recently started in a broader way (read the recent Cowles status report from c.s.y2k; that I have posted; it is quite alarming). << Sixth as I think about it, I don't think inventorying your system is that big a deal as far as the method is concerned - which may be one reason Tava is giving away the methodology for free. If you read the article written by Tava's engineer, Jacobsen, it seems to me it is mostly just the drudge work of going through floor plans and process flow diagrams. To me it seems an engineer familiar with his plant would be far better suited to this task than Tava. >> Well you can not see inventorying totally separate from the actual integration testing; the latter being quite complicated (see the GM test manual or the IEE test advices). So I tend to think that it has to be well thought out before you actually start the proces. When this proces has been setup in an ineffective way; part of the work might have to be re-done. also keep in mind that there is only very little time left; time better spent starting doing the inventory and solving the problems; than thinking out a method for yourself. Just IMHO of course. << Also note that you can use any common database program to compile your inventory. Also you were talking in the clubhouse about a British company which offered embedded system services. The database you were talking about was imo just a model structure - you know these are the fields that should be included. Meaning such information is pretty basic and easily transferable over the web by an organization like ERPI. >> << Seventh. It seems to me that after plant personnel the first place I would turn to would be to system integrators familiar with my plant - this both for the inventory and the solution phase. Second to people like R.W. Beck who were familiar with the utitlity industry. And only lastly to someone like Tpro with limited experience in the utility industry. >> Yes, but those guys would be much less informed about y2k issues ; and about how to set up the whole process. << Eighth Although Tava may have a large database we don't know how much of that is relatively simple to put together. Some of the larger component companies have evaluated their own products. So let's assume that 50% of the components in the utilities are by main stream manufacturers. That would make compiling that part of the database relatively easy. >> Yes, but there will be errors in those evaluations. Also, as mentioned above, some level of consistency must be there in the information in the database. The information that the component companies deliver will be in wildly different formats and level of detail. So I expect compiling to be more complicated than that. << Ninth ERPI would be putting few or no engineers on the project the way I envision it. They would basically act as a clearing house and organizer of data. They would take the data submitted by the engineers working at Factory A and enter it into the database. This would be very simple if a common database structure and language were used. >> Well see argument I stated above. It can not function that way. << Tenth. People have said that every component has to be tested. Well this is an area I am weak on. But that strikes me as very implausible. You probably have to look at every component. But it seems to me that some components are clearly not going to be date dependent. In fact it seems that everyone concedes that the overwhelming majority are not. One figure is only 5%. The other given by Tava is 30%. Also it seems to vary from industry to industry. The food and drug industry having a far higher % of date sensitive components. >> Well there are strong indications that in principle every component that has some electrical power source is suspect; see messages from e.g. David Hall from the SIM board. The most difficult part is the integration and end-to-end testing; the GM guide is very clear about this. I don't know if one can make generic statements that one industry is more date-sensitive than another. Just read all the messages on BIOS/RTC problems; even when a system does not use any dates at the application-level; there can be problems (e.g time dilation problem). << John, most of the above is with respect to the notion that an industry working together to solve this problem could catch up to Tava very quickly and not need their services. >> No I do not agree. Of course it is useful when they help each other. But to get a complete and usefule method/database together; keep it current etc can only be done effectively and fast by a commercial enterprise. Obviously the effort has to be a serious one. I cannot judge whether EPRI embedded program is serious or not. (Although it seems so to me.) If not then they provide no competition to Tava. If it is they do - competition in the sense that they enable utilities to do work which absent ERPI they would have to turn Tava. << People seem to think it is absurd that the industry could work together in a non-competitive manner to solve this problem. I find it even more absurd to believe that they wouldn't in the face of what some claim could be a catastophe. >> See above. Helping each other will help; but it is not enough. Key to the whole issue is getting a complete solution to all customers fast enough. << RS >> Regards, John

To: Richard S. Schoenstadt who wrote (12122)	3/3/1998 2:09:00 PM
From: Steve Sanchez	Respond to of 31646

you said: ... People seem to think it is absurd that the industry could work together in a non-competitive manner to solve this problem. I find it even more absurd to believe that they wouldn't in the face of what some claim could be a catastophe. not according to Roleigh Martin: : ... Through my past experiences with the Y2K Problem, I have received some insider information. One embedded systems Year 2000 expert involved in the utility industry problem provided abundant insight. To protect his identity, let's call him "George." I know he is an expert from independent and public sources and I have verified it was he who sent me the material by phone calls I made to him. As for its authenticity, I can at least state the following: Either some in the industry are doing or saying the things said below, or else someone wants me to believe this information. Either way, it is worth pondering. George wrote about a November 1997 state utilities meeting with a senior executive of a leading engineering firm involved in the utility industry and a senior researcher on the embedded systems problem who is affiliated with an industry group. His observations follow--they have been "sanitized" by George to hide individual/group/corporate/geographical identities. He also included observations made subsequent to that meeting. "Those who have not yet recognized the embedded systems problems are already too late. It was said to take about 21 months to make one power generation plant Year 2000 compliant. 'The only thing we can be certain about the Year 2000 is that we won't be able to catch everything.' (Speaker with the State Public Power District who opened the meeting) The opinion was expressed that complete Year 2000 remediation for a number of utilities is an insurmountable task; therefore, they should just attempt to make the steps necessary to prove due diligence in the court of law." "It was apparent from the meeting that the majority of the electric utilities had little to no idea about the extent of their embedded systems problem. The $30-40 million figure to upgrade one typical power plant was given by the expert engineer who attended and spoke at the meeting. I have spoken with him about embedded systems on a few different occasions. The twenty-one month timeframe was first given by the engineering firm executive, and was concurred by the expert engineer." "The idea that complete remediation would not be possible was a strong theme in the expert engineer's presentation. In fact proving 'due diligence' was named as a major driver for participating in the proposed solution program. Due diligence was also named as a major driver in the engineering firm's executive presentation as to why the utilities should utilize the services of a professional engineering firm with expertise in doing embedded systems troubleshooting for Year 2000 upgrading of core infrastructures." "New HVAC machines (as well as others) do not always contain manual override for 'on' position. Work-arounds are impossible without costly replacement. Lead-time on replacement of such machines is already over one year and increasing." [An HVAC is a heating/ventilation/air-conditioning system. Without HVACs working, rooms containing electronic sensors and heat-sensitive data processing equipment can overheat and start malfunctioning.] "In a private phone conversation with the expert engineer, he expressed the opinion that a 30% outage is not out of the realm of reality. If thirty percent of the nation's grid goes, the rest may go as well. That is a reason that the few and far between plants who are ready (or at least closer to being ready) for the Year 2000 are considering isolation. That is not exactly an easy task. Also to consider: a customer who is serviced by a power transmission center rather than a power generation station could just be out of luck, even if his (far away) generation station is still pumping out power. This brings us to another point. Under current federal law, any power generator capable of producing excess power must be connected (whether on or off-line) to the power grid. This includes windmills (!) and private companies' power generation stations." "Every firm, of which I am aware, offering Year 2000 embedded systems remediation does not perform testing to a high enough degree... [One firm] tests only at the component level in embedded systems, and then only at the hardware/functioning software level. This leaves huge holes in their testing. They do not test for component interaction problems. There have been documented cases of interaction failures, often causing more severe problems than RTC or BIOS anomalies...yet [they do] not test for them. [They do] not review the ladder logic, which often contains date references, in PLCs (programmable logic controllers). They are also unaware of many problems in embedded systems which have been recently discovered. For instance, they were unaware of the cyclic rollover problem with certain PLCs... [One] must make sure the experts really are experts." "I do not plan to be anywhere near a big (or medium) city when the Year 2000 hits. There is just too much that could go wrong." Roleigh Martin y2ktimebomb.com