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 : Year 2000 (Y2K) Embedded Systems & Infrastructure Problem -- Ignore unavailable to you. Want to Upgrade?

To: John Mansfield who wrote (140)	2/28/1998 5:20:00 AM
From: John Mansfield	Read Replies (1) \| Respond to of 618

TECHNICAL - Embedded code in Process Control Date: Thu, 26 Feb 1998 13:16:01 -0500 From: Chas Mitchell <cmitchel@nmi2000.com> To: Y2K Mail List <year2000-discuss@year2000.com> Subject: Embedded code in Process Control We recently were discussing the value of the McCabe Visual 2000 toolset with an engineer charged with the responsibility for ensuring that the year 2000 rollover would not destroy their business (the industry in question is not important, just the idea of process control computers that monitored and controlled liquid flows, etc). The idea of course was that if you run the code through the McCabe Visual 2000 toolset, you can not only isolate your testing to the date paths, but you can definitely determine whether or not you have actually tested all affected paths. Well, as it turns out, most industries don't purchase source code for any process control device, but instead purchase a module that has the capability of accepting process factors and controlling the process based on those factors (a rather simplified version of the actual process, but good enough for this discussion). Then, he told us that in many if not most situations, the companies that sell the specific devices actually purchase a higher level (or lower level depending on how you look at it) board that already has some embedded code on it. (Virtually all of the code is in EPROMS). So not only does the user not have the source for the device they purchased, but their supplier may or not have that code, but not likely the code that was already on the board that they purchased. So, end user applies factors to code created by next level supplier who created code applied to next level supplier code, etc., for who knows how many levels. So they only thing this engineer can do to verify the process is try over and over again to test the device using as many different factors as he can dream up, until he exhausts himself, or the system shows an error. If it shows an error, he knows he has a problem, and can begin to search for a solution. BUT, if it DOES NOT break, then he never can be sure whether he tested the equipment for all possible conditions which may occur at any of the code levels on the device! And he can not be sure that the device won't shut down his company! Because he did not have source code, we couldn't help him with the McCabe toolset, but he did tell us that someone had developed a piece of hardware that would test and record results on process control equipment, similar to what McCabe does with source code. This was the first time I had ever met anyone who was happy when he managed to find and error!!

To: John Mansfield who wrote (140)	2/28/1998 4:15:00 PM
From: John Mansfield	Read Replies (1) \| Respond to of 618

EC: 'the level of preparation is still relatively limited' 'Communication to the Council, the European Parliament, the Economic and Social Committee and the Committee of Regions: The Year 2000 Computer Problem, COM(1998)102, 25 February 1998, PDF versions in all languages At the turn of the century administrations, enterprises and other users are being affected by the inability of many computer systems and programs to perform correct computations with dates after 31 December 1999, due to the use of only two digits to indicate the year. At the same time, they are being involved in the transition towards a single European currency. Taken together both problems represent a major challenge for the Information technology sector, a critical business issue for enterprises of all sizes in all sectors and a major challenge for public services. Recent surveys show that the level of preparation is still relatively limited and differs across Member States. The European Commission adopted therefore a Communication on the issue. It stresses that the responsibility for fixing the Year 2000 problem clearly lies with suppliers and users of computer-based systems but announces a number of awareness creating and supporting European actions : the Commission will encourage and facilitate the exchange of information and experience, liaise with organisations that are responsible for crucial infrastructural sectors (telecommunications, energy, transport) and insert the Year 2000 problem as a regular agenda item in relevant ministerial and other meetings. ' ispo.cec.be

To: John Mansfield who wrote (140)	3/1/1998 5:51:00 AM
From: John Mansfield	Respond to of 618

JBA Y2K site mentions embedded systems also 'It's not just computers though Your projects have come to an end - all of your key systems recognize the year 2000 date change correctly, there is a 29th February 2000 and there are no magical dates.ÿ Congratulations.ÿ However, the battle isn't over yet. ÿ Many common items today including elevators, heating and air conditioning units, electronically operated doors, phones, bank vault doors, fax machines, cars, traffic lights all contain embedded microchips - some with date logic.ÿ The prospect of just some of these "embedded systems" quitting is quite frightening - especially when you look at life support machines, nuclear plant monitors or airplane instruments. At a company level the risk is much less. ÿ The reason for this is that most embedded systems are not critical to the business. ÿ Could you see a multi-million pound business going broke because of a central heating failure? As a prudent business person (with year 2000 compliant computer systems), the next step is to carry out an audit of your embedded systems, produce a list of the systems most critical to the business (electronically operated doors for instance) and then set about obtaining manufacturer's compliance statements.ÿ In addition you should also produce contingency plans for your most vital embedded systems failing (this is also good practice anyway).ÿ If you fail to get a response and the deadline draws near you could always replace the machine as a last resort.ÿ The Year 2000 and Embedded Systems: For Most Businesses, This Does Not Have to be a Major Problem <Picture: < Year 2000 Link >> provides a clear methodology for dealing with the problem of embedded systems.ÿ A more in-depth discussion of the problem with links to a series of papers can be found at Gary Eubank's Embedded Chips and the Year 2000 <Picture: < Year 2000 Link >> article.' ________ jbaintl.com