Modularity and Troubleshooting
A residual current device trips leaving the house in the dark. How do I fix the problem?
Modularity is my friend.
First I bring down all the circuit breakers
at the distribution panel.
Then I bring up the residual current circuit breaker
(known as ground fault circuit interrupter in the US),
and then I bring up the breakers one by one.
When I bring up the tenth one the residual current circuit breaker
trips again, which allows me to pinpoints the problem at the
sockets supplying the washing machine and the tumble dryer.
Turning off the tumble dryer allows me to bring up the corresponding
circuit breaker, which means that the fault is probably in the
tumble dryer.
My next step is to isolate the fault inside the tumble dryer.
Opening the top and right panel of the dryer
(a Siemens/Bosch WTL 5200 unit) exposes a number of cables plugging the
various components together.
I remove the dryer's plug from the socket and use a multimeter to measure
the resistance between the earth and live.
At 20KΩ it is no wonder the RCCB tripped.
I then remove each one of the plugs distributing the main power
to each part, starting with easiest and most suspect:
- Motor
- Electronics
- Heating unit
Can we debug programs in the same way? Yes and no. For some types of programs, such those created out of shell pipelines, we can be readily disassemble them into parts and see what goes in and out of each part. Monolithic systems, written in C, C++, Java, or C#, are difficult or impossible to disentangle. In these cases the current state of the art is to build hundreds of test cases that know how to invoke and test each method or function. Although this helps troubleshooting, it strikes me as a waste of effort. It should be possible to attach general purpose testing tools to our programs, in the same way as one uses a multimeter, oscilloscope or digital analyzer in electronic troubleshooting. This would delegate test cases to the place where they are really needed: regression testing.
Read and post comments
