long post; TECHNICAL but VERY INTERESTING : IEE ADDENDA to 'The Millennium Problem in Embedded Systems'
iee.org.uk
This is a very detailed and comprehensive update to the IEE guide on y2k in embedded systems.
IEE is the Institution of Electrical Engineers; based in the UK, Savoy Place, London WC2R 0BL; see also:
iee.org.uk :
'IEE Overview Who we are
Founded in 1871, the Institution of Electrical Engineers is the largest professional engineering society in Europe and has a worldwide membership of over 130,000. These men and women, who have joined together to promote the advancement of electrical, electronic and manufacturing science and engineering, range from students to the most distinguished and highly qualified members of the profession.'
They are very knowledgable about all Y2K aspects in embedded systems.
UK is ahead of the US in awareness on y2k in embedded systems; so this is a very interesting paper.
I have copied some interesting parapraphs below.
John
------------------------------------------------------------------------
iee.org.uk
ADDENDA
JANUARY 1998
1.5.5 Year 2000 Statistics
1.5.5.1 The following statistics may be useful to those wishing to make a case to management for a Year 2000 programme. They appeared in reports of a Cap Gemini and IDC survey based on questions to 313 companies about their year 2000 progress:
(a) 11% of organisations will miss the deadline, putting 29% of UK gross domestic product (GDP) at risk.
(b) If the timetable slips by three months, 25% of organisations will miss the deadline, jeopardising 37% of GDP.
(c) Total cost of year 2000 to UK companies is œ23bn: on average, œ200,000 per small organisation (less than 150 staff); œ400,000 per medium organisation (less than 500); and œ2m per large organisation (more than 500).
(d) Small will take an average of 18 months to become compliant, medium organisations will take 24 months, and large organisations 30 months.
(e) 13% of large organisations have not yet started year 2000 work; 40% started work by June 1997, and 11% more by October.
(f) Testing is ranked the most important element of a year 2000 programme, followed by project management, then strategic analysis and assessment. Code conversion skills and automated tools were ranked least important.
(g) Testing is expected to consume 31% of total year 2000 budgets, code conversion 24%, and analysis and assessment 18%.
<snip>
3.3A CRITERIA FOR CLASSIFYING A SOFTWARE COMPONENT AS DATE INSENSITIVE
3.3A.1 The following set of criteria was supplied by a leading consultant. It should be noted that while the criteria are clear, their application by persons without relevant expertise could result in incorrect conclusions.
3.3A.2 If ALL the following criteria are met, then there is a high probability that the component is not affected by dates:
(a) There is no real-time clock hardware.
(b) Timers do not use a difference in dates to calculate a time.
(c) There is no battery backing for the processor or memory. This point should not be taken as sufficient evidence in itself as some chips maintain information (and potentially therefore date information) even though there is no visible means of power.
(d) There is no access to internal or external non-volatile devices, such as disks and tapes.
(e) The date is not available (known) at the Operating System layer.
(f) The application language contains no constructs or libraries that use or manipulate dates.
(g) There is no external date interface, e.g. from Rugby clocks, or over communications lines. This includes confidence that date cannot be hidden within the data part of a message.
(h) The operator/maintainer never sets a date in the system.
(i) The operator/maintainer never sees any dates (on input or output).
3.3A.3 If only SOME of the criteria are met, then a judgement has to be made on the probability that the component is date independent.
3.5A.4. In the US, the IEEE has issued a Draft Standard for Year 2000 Terminology (IEEE P2000.1) which does not however mention embedded systems specifically and will not be available in approved form until Spring 1998. The draft of the standard is available on the World Wide Web (http://computer.org/standard/pasc/y2term.htm).
K2.3 All equipment and systems which contain embedded systems must therefore be considered at risk from y2k failure until proved otherwise. The task facing business is how to assess the risk to their business from y2k failure and plan preventive action. Difficulties that a business might expect to encounter may include
(a) the size of the project
(b) scarcity of technical specialists
(c) difficulty in getting support from vendors
(d) vendors that have gone out of business
<snip>
K5 ASSESSING BUSINESS IMPACT
K5.1 Objective
K5.1.1 The objective is to put the inventory of embedded systems into priority order of impact on the business in the event of y2k failure. Subsequent y2k compliance assessment work will be carried out in this priority order. This ensures that the systems whose failure would damage the business the most are assessed first.
<snip>
K6.4.3 It is sensible to establish that a vendor has a y2k programme before asking about the compliance of specific products. It may be necessary to make the vendor aware of the y2k problem in embedded systems. If a vendor does not know whether or not his products are compliant one should try to establish by what date he will have this information. In an extreme case where a vendor seems unlikely to produce timely information on inventory items or no longer exists there may be serious difficulties in assessing y2k compliance.
<snip>
K9 MANAGEMENT ISSUES
K9.1 Management Support
K9.1.1 y2k is increasingly being treated as a business issue covering business IT systems, embedded systems and all aspects of the supply chain. The size and importance of a y2k programme covering all these areas is such that it will require support at Board level in the business. It is very likely that an embedded systems y2k project will be part of an overall y2k programme. The embedded systems project will require its own project manager reporting to the y2k programme manager who will no doubt report to a director who acts as sponsor for the y2k programme.
<snip>
APPENDIX M REASONS FOR TAKING ACTION
M1 INTRODUCTION
M1.1 The following is a summary list of various reasons (mainly legal and financial) why companies and their senior management will find it necessary to take action on Year 2000 and other date problems, even if for business reasons they are disinclined to give the matter a high priority. Some of the individual matters are addressed at particular points within the main
<snip> |
