Monthly Archives: February 2014

What happens when a fault first appears.

Leave a reply

Let’s consider a system – say, my car – that works perfectly when it is new. It has no design flaws. It goes on working for some considerable time, and then some part breaks. The car now has a problem, a fault, that should be repaired by replacing the broken part. But, I don’t yet know there is a fault.

firstError

In the chart, the part breaks at time A. But I don’t recognise there is a problem, because I’ve not yet noticed anything wrong. As far as I am concerned, the car is still working fine. The blue line on the chart represents this period. Eventually, though, the broken part causes an error that I can detect. In my case, the engine stopped when I expected it to be rotating. The red line represents this event, which occurred at time B, some time after time A.

I then realise that the car has a fault. However, I don’t get it fixed straight away, so the car goes on being faulty for some while – the horizontal part of the red line. I can still get the car to start, and drive it around – carefully – but I know it is broken.

In order to know that there is a fault, I need to be able to detect an error, and I won’t be able to do that until the fault is exercised to produce an error I can notice. A fault which isn’t exercised doesn’t produce any errors.

A car headlamp bulb is a good example of a fault that’s not detected until it’s exercised. The bulb can break any time, when the lamp is on or off. When the headlights are switched off, even if there is a broken bulb, there is no error. I’ll not know until I switch on the lights – of course, when it’s dark and I really need it. That’s when I exercise the fault to produce an error, the lamp not producing light when I expect it to.

Using the right words.

Leave a reply

Problem – Error – Report

The field broken things is fully of confusing terminology. When I say something, it means precisely what I mean it to say, so here are some definitions of terms. Keep these straight and you’ll be half-way there.

I use the word problem here to mean, “The cause that made the system produce errors.”

A Problem could be

  • A Fault
    Something that is broken or worn out, that is repaired by replacing the broken part
  • An out-of-calibration event
    Something that is repaired by making an adjustment (like putting more air in a tyre if the pressure is low)
  • A design flaw
    Something that is fixed by changing the design
  • An upset
    Something that goes wrong, but isn’t evidence that the system is breaking down. The cosmic-ray-induced soft errors in computer memory are an example of an upset. Provided they don’t happen too often, we just learn to live with them.
  • and other stuff

so ‘problem’ covers all sorts of causes. We tend to give different names to the causes depending on what action we need to take to make the system work properly. But, all these different sorts of problem share the fact that they cause the system to produce errors rather than working properly.

I use the word error here very carefully, too.

An Error is

  • A signal or datum that is wrong.
    For example, low air pressure in the tyres, high temperature in the engine, zero RPM when the engine is supposed to be running.

An error is internal to the system. It might propagate within the system and cause more errors. For example, low tyre pressure might cause tyre overheating. However, we won’t notice anything is wrong (we’ll be under the misapprehension that the system is working properly) until the error is detected by some error detector and produces a report.

A Report is

  • The output of an error detector that says “There’s an error!”
    For example, the warning light that tells that the engine is overheating
  • The result of a specific test
    For example, when you measure the tyre pressure and find it is low
  • Some human error detector
    For example, you notice the smell of burning rubber.
  • Anything else that causes the procedure of diagnosis and repair to start.

Is It Fixed Yet?

Leave a reply

This is the first in a series of posts about a calculation that worried me for years – about fifteen years. The question occurred to me when my car, a newish company car, broke. It stopped going along. Eventually it started again and I took it to the garage. They changed some parts, presented a big bill, and I drove away. Next week, the car stopped again. After a few minutes, it started. I took it back to the garage, they changed some more parts, and I paid another big bill. Next week… you get the idea. It was driving away from the garage for the third time that I wondered, “How do I work out whether the car is really repaired?” How much testing do I have to do before I trust the car again?

It took me 15 years to work out the answer. I tried collaborating with four different people, and couldn’t solve it. Then, one day, Eureka.

This all happened when I was working for Sun Microsystems, so if there is any intellectual property in the idea, it belongs to them, or now to Oracle. I don’t think a patent was ever applied for – it was in a chaotic time close to when I left Sun, and it’s not in this list. But, it’s old enough now that I don’t think anyone will mind if I publish it. I’ve never seen the result anywhere else, although I’m a bit out of touch with the field now.

The eventual result is applicable to things that break, and also new products with design flaws. It seems quite general.

Future posts here will explain the idea and (if I get my act together) present an online calculator for working out the chance that a problem has been fixed by a repair, given a pattern of test failures and passes both before and after the repair. But I haven’t written that yet.