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: Bonzo who wrote (8161)	12/31/1997 3:21:00 PM
From: Mike Winn	Read Replies (1) \| Respond to of 31646

Joe, I will make the answer quick as I need to get prepared for the New Year Eve. May be I will get back to you next year. Most embedded systems have either cyclic or event driven tasks. An initialization task is launched at power up to do the system and board tests, afterwards cyclic tasks are launched. They get dispatched at pre-determined frequencies. If you are dealing with control law with feedback loop or with filters, this is where your input and output got to be scheduled because otherwise you are going to introduce phase shift into the system. Event-driven tasks, as the name implies, get dispatched upon detection of an event, like someone pushing a button, or an alarm is detected, or some other input is detected. So everything basically evolves around frames, or clock ticks, not clock time. Some systems use the date and time to log errors, or the occurence of an event for diagnostics purposes, but that's not crucial to the operation of the system. When clock time or date are involved, normally it is centralized and performed by a single system. For instance on an airplane, the date and time are acquired by the Maintenance Computer or Flight Management Computer and dispatched to all the other boxes. In a factory, the time and date are maintained by the main Control Panel computer. This is where the orders are entered by the operator, and all the billings, inventory and reports are done. The embedded systems that are spread all over the factory floor do not need to know about date and time, and even if they do, the info will be sent by a main computer via the network. That's how the design ought to be done, otherwise you will have the burden of maintaining the clock time in all those systems spread around the factory floor. So if there is any Y2K problem to be fixed, it's centralized inside a single computer, normally a mainframe or minicomputer. I agree with you wholeheartly that there are always systems out there where a separate clock is maintained by all the distributed systems for redundancy. But those are a very small percentage of the total number of embedded systems. With respect to fixing the code in embedded systems, I maintained that it's not easy, because 1) most of the time, there is no more room inside the ROM or EPROM to add code, 2) the fix needs to be done properly or the timing may be totally screwed up, 3) the assembler/compiler of old processors may no longer be available, 4) you can't replace one embedded system without knowing how it interfaces with the other systems. I maintain that the embedded code remediation, if there is any, have to be done in house, or by the designers of those systems, and cannot be contracted out. With regards to the stock and the company, I think TPRO is OK as far as the factory automation business is concerned, but the Y2K stuff is purely fiction. Most of the Y2K stocks go to moon shot because they are associated with Y2K code remediation on mainframe and there is plenty of work to do. Not a single company has so far claimed that it has landed a contract doing Y2K code remediation in embedded systems. If TPRO gets one, it will be the first. Happy New Year to you. Mike.

To: Bonzo who wrote (8161)	1/1/1998 10:58:00 AM
From: John Miz	Read Replies (1) \| Respond to of 31646

Joe, Mike Winn wrote in his post; quote, "So where is the date used? "Only in the control panel computer where the accounting, inventory, and report date are generated. Do the embedded systems need to know about the date? No, obviously. Everything inside those embedded systems are running on clock ticks, not on clock time or date." Unquote. Now, I was told these are very DANGEROUS assumptions. That embedded systems use dates for: Alarm message log files Operator command log files Calibration/maintenance history Network protocol software File system software Time validation of commands (to reject stale commands) Time dependant authenticaion codes Performance measurement Computation/prediction of time dependant external conditions Distributed network protocols used for failure tolerant systems Stored commands to be executed at a future date/time Compensation for component aging/wear Time dependant mode selection (traffic lights, elevators) Preventative maintenance scheduling That's just a partial list. If you care to comment, please do so. John