What are other jurisdictions (national and international) doing with respect to representative testing of embedded products? It would important to determine whether anybody has adopted this as an accepted best practice.

There are some representative tests being carried out by various groups in the UK - usually under the banner of a trade association or interest group to avoid direct liability claims. For example, the major UK food retailers have formed a group called 'self-check' which pools their data. We have established that so long as the make, model, AND software release issue are known then a test on one system is illustrative of what another system can be expected to do. Simply knowing the make and model, or the serial number, is not good enough as a representation of what other similar systems may do.

	How does testing of embedded products compare with test bed application testing? What is important to determine here is whether witness testing on test beds can be considered reliable.
	In general, test bed testing can be considered reliable, provided that it does exercise the type of operational functionality that the live system performs. The test bed (once again... this IS important) must be running the same release of firmware in any embedded system components as the live system, otherwise the test results cannot be regarded as valid.

What is the failure rate with testing of embedded products within a single design? The assertion is that components may change on a product in mid-production and that some products of the same design will be compliant and some will not.

You have highlighted a common misconception, which is that buying different batches of chips can affect the compliance status outcome. The reality of this is that the failure rate is zero. It is simply not true. We have all heard the stories about systems where some pass and some fail, but it has nothing to do with where the chips came from... the issue is to do with the version of vendor's firmware code the supposedly identical systems are running. Systems fail in the millennium because they are comparing dates, and doing so incorrectly, which is a function of the vendor's code. Clock chips do not compare dates, nor do they fail at the year 00. Microprocessors cannot maintain date and time all by themselves, so are not to blame either. It is the vendor software which holds the key, and, yes, vendors frequently update their firmware code to include new features and fixes to old ones. One such fix is how the system compares year dates, so you may get two identical systems (or so you think) which are running different releases of the vendor's firmware. One may fail, the other may not. The firmware release number is usually visible on a label stuck to the ROM chips which hold the firmware code. The Delta-T Probe was designed as a test tool for the identification of clock usage and the extraction of pertinent code. Using the Delta-T Probe It is possible to compare one version of code with another, and also see how the firmware code compares dates.

What is the % of embedded devices that testing will not be capable of confirming compliance? This is assuming that testing can never be 100% efficient and that things will be missed.

You are right. Testing is all about establishing a level of confidence, ranging from [no confidence at all]... to ...[100% confident]. Even validating all the code in a system, which takes weeks, will not guarantee compliance as something may be missed. Date roll-over testing and Delta-T Probe testing do both give you a high degree of certainty that the system will not fail, but it is not absolute. The extent of certainty is dependent upon the system complexity and the amount of time spent in investigation and testing.

	Is the likely failure rate of embedded systems using micro controllers less than 1 in 100,000. i.e. most embedded systems manage processes based on time rather than date?
	The quoted statistic is on the low side. We have experienced a (serious fault) failure rate of about 1 in 1,000 on most projects. This figure is pretty small as almost 80% of embedded systems do not use time or date at all. The Delta-T Probe can be used to confirm absence of date and time in microprocessor based systems, where the presence of time and date is in doubt.

	Is it true that of those microprocessors which have real time clocks less than 0.25% will fail, but at least 7% will have date processing problems of some sort?
	The question is slightly misleading… microprocessors do not fail as a result of Y2K problems, as there are no commercially available microprocessors which have on-board real time clocks. Of embedded systems that use real time clocks we have seen a failure rate in the order of 5%, with critical failures at roughly 3%.

	Large scale embedded systems applications typically use PC based control with disc storage of historical information. The control application typically co-ordinates the activity of many low-level devices. e.g. BMS controllers. Is it true that at least 35% of these types of control systems will suffer from date problems?
	Yes. Much historical data logging and processing is performed on a two-digit year-date basis. This means that although the controllers continue to function normally it is quite likely that the PC application may not process or graph the data correctly. This figure is increased if the PC hardware is not checked for non-compliance to over 60%.

	Is it true that embedded systems are only at risk from Y2K problems if they have a constantly available source of time with a battery power source?
	Yes, that is a good description of the primary risk category, but anything with a data connection through which time and date information can be received is also at risk. If you are uncertain whether a system contains time and date then the Delta-T Probe provides the only reliable method of detecting it.

The only way to establish if the date part of the data is used is to examine the program code used by the device. Is this true?

There are a number of ways of finding out if a system uses the date part of its clock data. If it is possible to change the date and test the system operationally then that is probably the easiest method of testing it, albeit with a certain amount of risk that the system will fail. The other method is to look at the code, which is difficult to get at and may take weeks to do. The Delta-T probe simplifies the operation of getting at code non-invasively and extracting only the code relevant to time and date operation.

	Some real time clock chips have an embedded battery. Would a simple examination reveal this?
	Yes. These chips tend to sit on 'stacked' chip sockets (which have a battery inside them), or be conspicuous by their size and vertical dimensions.

Does some equipment derive its real time from satellites? If so, what are the equipment types?

GPS positioning devices receive their time from satellite information. A number of other (usually industrial or high security) systems take their time from the Rugby MSF radio time signal, or a similar signal sent from Frankfurt in Germany. The latter are extremely difficult to test, as it is not possible to change the time and date locally on the equipment. The Delta-T Probe is appropriate for testing many of these systems.

	If a device only logs data by recording data values and time intervals and it is inactive over the century date then it will be OK post year 2000. What if it is active over the century date?
	The interval recorded between data values read either side of the year 2000 boundary may be calculated wrongly, resulting in 100 years or some other nonsensical number. This is a one-off problem, and can be corrected for by uploading the data and manually changing the value in a logged data file.

	If we have devices that were wrong in the last leap year then they will have millennium problems, but other functionality will not be lost, is this correct?
	There is no way of knowing for sure without looking at the code, but if a system skipped 29/2 at the last leap year it is sure to do it in the Year 2000. Whether it can handle 00 as 2000 is a completely separate matter that must be established through testing.

	Do you agree that domestic appliances with the exception of PCs, video players and complicated security systems are not going to suffer Y2K problems?
	Yes. Even if they display the time (like an microwave oven) there is no reason for them to be comparing dates, or even know what the date is.

	I have been told that CMOS may have dormant embedded software that has nothing to do with the functionality of the equipment, which may cause a system to close down at the millennium. Is this true?
	We have never seen such a case. Millennium bug problems are directly attributable to systems comparing dates incorrectly. It is possible that a maintenance function or analysis function may suffer from such a problem, so it may only be discovered post-millennium, but these types of functions do not usually affect the ability of an embedded system to operate as programmed.

	Equipment listed in IEE category 1 and 2 must be complaint because they have no real time clock chip, crystal or battery. Is this true?
	This question refers to microchip controlled 'smart sensors', such as modern fire detectors. Some smart sensors do actually know the time and date for recording information, but do not make decisions based upon it, so in the general case the above statement is true.

I'm confused about embedded chips! If I have an item of equipment (such as a network hub) that I have been told by the manufacturer does not have any date processing functionality, could the chips within the hub still fail on 1 Jan 2000?

A very easy to answer question... the answer is no, absolutely not. There is a misconception that there are going to be failures caused by 'bad batches' of chips as a result of cheap imports etc. This is simply not the case. A system will fail if it is (a) doing date-related processing AND (b) fails to calculate date comparisons correctly. In other words, it is a problem caused by the system vendor's code, and not the chips they have chosen to use. If the vendor says they are doing nothing date related (and can justify it) then there is nothing to worry about.

I have received a request from a major client that you may be able to help me with. They have been told that 9/9/99 will not affect any building services systems and would like an opinion/any documentary evidence.

In all the testing, and of all the manufacturer statements we have received (now in excess of 65,000 systems) there is not one that suffers from that problem. The perceived problem is that '9999' may be used as an end-of-records marker or an end-of-file marker in a database application, and that it might be entered by an operator into a date field to signify the last record. This is plausible for a custom-written accounting or stock control package, but highly unlikely to be the case. Embedded systems do not use file systems or database records - they use real time control variables, so the likelihood of this failure is pretty much nil.

I have been given the following solution as a 'fix' to all my PC and embedded systems Y2K problems. Is this for real? "If you enter in any random order items : 98, 99, 00, 01, 02, O1, O2, O0. Your computer can sort these items like this : 00, 01, 02, 98, 99, O0, O1, O2. This may be all that is important to you. You can also make your real time clock understand that after year 99, comes the year O0 not 00. Not "zero zero" but "O zero" where the 0 is the letter 'O'. This involves your BIOS setup and you may need some help and help is available. You will then be able to run your computer for the next ten years. If you like to start after the year 99 with a letter "A" instead of "O" you will be able to run your computer the next two and a half centuries and then buy yourself a new computer."

Variations of this so-called solution have been suggested many times, and you are right in questioning whether it is a workable. For a totally non-computer person it sounds plausible, but in reality it is impossible. The simple truth is that you cannot simply tell a system to use (letter) O instead of 0 (zero) without some serious reprogramming, which is difficult and extremely expensive. The same goes for using 'A' after '9'. The type of companies that could do a code 'patch' to implement such a scheme charge thousands of pounds per day, and a fix like this would take anything up to a couple of weeks per system. The words 'this involves your BIOS setup' are the clue to where this fails. There is no PC BIOS in the world that allows you to enter invalid times and dates containing letters through the BIOS setup screen. Even if such a thing were possible, it would cause havoc in almost all applications that use the date as they would not know what to do with letters in the year field. In short, (regretfully) it is simply not possible.