On 27 Mar 2005, the UK put its clocks forward one hour. This apparently caused problems for Barclays Bank - one of the UK's leading banks - with ATMs and other online services unavailable to customers in the South of the country. The text of the Daily Telegraph's report on the failure is reproduced below. http://www.telegraph.co.uk/news/main.jhtml;sessionid=3D4HHCXBASXCNU5QFIQMGCM5WAVCBQUJVC?xml=3D/news/2005/03/28/nbarc28.xml&sSheet=3D/portal/2005/03/28/ixportal.html I would be surprised if the bank relied upon the actions of a human to change the time on its servers. For example, if the servers are not time synchronised through an atomic clock receiver or from an NTP Time Server, it begs serious questions regarding the time-standing of transactions. Bi-annual time changes have been a part of computing at least since the first commercial systems began processing. Surely 54 years is not too short a time to have worked out the risks and put in place procedures to deal with them. If it was indeed a human error, perhaps the heading on the relevant page should read: "Spring forward, fall back". Another puzzling factor is that it apparently took 11 hours (4 am to 5 pm) to determine and correct the problem. In my experience, the first thing to be blamed is the last thing that was changed. Michael 'Streaky' Bacon Summer Time slip-up forces Barclays' cashpoints to close *The Daily Telegraph*, 28 March 2005 Millions of Barclays customers were unable to withdraw money yesterday after the bank's cashpoint network crashed amid claims that a duty manager had accidentally put the clocks back instead of forward. More than 1,400 auto-tellers in the south of England and some on-line services were out of order. Barclays customers were unable to withdraw money from any bank, while cardholders with other banks were unable to use Barclays cash machines. The error came to light at 4am on 27 Mar 2005 when technicians noticed that customers' personal details were not being forwarded to the computers that control much of the bank's infrastructure. The problem was eventually resolved at 5pm. Executives trying to determine the cause of the problem admitted that a mistake during the switch to British Summer Time could have been to blame. Customer services staff were less ambiguous. One admitted: "A manager put the clocks back instead of forward and that has caused enormous problems." The bank's British network uses two servers based in Gloucestershire: one for operations north of the Wash and the other to control operations in the South. The Gloucester South server is understood to have been set one hour back instead of forward. The bank conceded that an error over the time change was to blame but denied that an individual manager made the mistake. Alistair Smith, a spokesman for the bank, said: "It seems that this problem may somehow be related to the time change, although I am told it was not to do with someone making a mistake while manually changing the time."
A laptop computer containing names, SSNs, and some addresses and birthdates for 98,369 alumni, grad students and applicants was stolen from an office at UC Berkeley. In compliance with California's new data-theft reporting law, the breach was reported and has now been widely publicized — although ironically, as a writeup on slashdot points out, this publicity may have alerted the thief, who was probably only interested in the hardware, to the true value of his find. Links: http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2005/03/28/financial/f151143S80.DTL http://yro.slashdot.org/article.pl?sid=05/03/29/036237
Case in point, the agreement (Enrollment E-Consent) you are asked to accept when you sign up for Hertz #1 Gold membership - at https://www.hertz.com/servlet/JoinProfileServlet?club=G Right at the bottom, where your consent is sought, there's a footnote that says: * "Any Hertz rental website" or "the Hertz rental website" means any Hertz website relating to vehicle rentals including, without limitation, all websites with addresses which begin "www.hertz". The relevant text, much further up the document, is: Disclosures to You by Hertz 1. Summary of Your Consent. At the bottom of this page, after you have reviewed these disclosures, you will be asked to give your consent (your "Consent") to Hertz's use of an electronic record rather than paper format to provide or make available to you the following information (the "Information") via any Hertz rental website* or by e-mail (collectively "Electronic Record(s)"), subject to the conditions and other requirements discussed below: I first noticed this several years ago - and reported it to the web master. I don't recall getting any response, and the web site today shows that I didn't get the message through to anyone. Clearly, if I own a domain bogus.tld, I can create a www.hertz.bogus.tld site and there's nothing to stop Hertz using any information submitted there - I'm not sure how they'd get hold of information submitted to my hypothetical web site. It'd be cute mistake for a Mom'n'Pop outfit to make; it is more serious when it's a major international corporation that is suffering from technical myopia. Jonathan Leffler Guardian of DBD::Informix v2005.01 — http://dbi.perl.org/ firstname.lastname@example.org, email@example.com
> I wonder if somebody on this board has some insight on how the electronic > controls of modern cars are designed AFAIK technically it is a distributed control system with quite many relatively independent units communicating through a bus (typically CANbus). > and especially if a single component's failure (such as a common > microprocessor) could affect multiple functions (e.g., acceleration and > brakes). The various ESPs (electronic stability programs) are able to reduce engine power and apply selective braking on some wheels in order to stabilize the vehicle. So there already is something that can give commands to both the brakes and the engine. I have no idea how (im-)probable is that kind of failure mode, though.
In RISKS-23.81, Robert Scheidt expresses doubt that a hung cruise control system would stop braking, in "Cruise-control failures" I can't assess that, but I do know that the handbrake/parking brake on a 2004 Renault Scenic is CPU controlled, by the system that manages the ignition. When you pull out the 'ignition card", the parking brake engages automatically. There is also a handle you can pull below/left of the steering wheel, which sends a request to turn parking on. There was a bit of a lag engaging, as I recall from my weeks rental, say 0.5s or so. How does it disengage? Well, there is the fun part. The parking brake disengages when you drive off. This seems like a convenient feature, but was certainly a disadvantage when I rented the car in the Alps for a week -even without any of these 'cruise control failure' disasters. The problem was simple: how do you turn round on a sloping mountain road near grenoble, when the snow has got too deep for you to continue. In a conventional car, the solution is the three-point turn, executed with maximum care. You back up and turn, then go forwards, completing the turn. This is actually a manouevre which is part of the UK driving test, albeit on a flat road. To do it safely on a mountain road you need to 1. Make sure you are in a gear that is going in the correct direction, so as not to drive off the edge of the (steep, unprotected) drop. 2. With a manual transmission, bring up the clutch slowly until the transmission is engaged. This stops you slipping (the hill start), and provides an extra cue that you have (#1) right. 3. Move off very gently as you release the handbrake. This is your final sanity check. The key point here is the failure mode "driving off the edge of the road" is not something you want to encounter, nor is "sliding down the hill as you set off". Unfortunately, the Renault Scenic, with its automatic handbrake, doesn't let you do any of these. You cant bring up the clutch under gentle acceleration (check 2), as the handbrake comes off too early. The only way to do a hill start is put your foot down enough to be sure that when the handbrake comes off, you aren't go slide backwards. This eliminates any chance of making sure that you are in the right gear through tentative car motions. Let's just say I wasn't happy with the whole process. We did turn round safely; I am writing this email. But I had to check and doublecheck the gear lever settings before each step in the process, and it was no fun at all. An interesting footnote is what would have happened if I'd got it wrong? I'd have driven off a cliff and not been found until later in the spring. At that time, I am sure the cause of the crash would have been attributed to "driver error", and not system failure. This is so reminiscent of assigning "pilot error" to any crash of an airplane with no obvious mechanical cause. This is something that should be so familiar to RISKS readers, be it related to A320 flight control systems. Chinook fog navigation, etc, etc. Are we going to replicate these incidents with drive-by-wire car control systems?
In any car that I have ever seen, cruise control has been an option installed late in the assembly process. In some cases, the marketing department has decreed that you can't buy the car without cruise control, but it's not something that is generally built in "deep down" in the system. Cruise control is typically a fairly dumb system - "all" you have to do is to detect the current road speed and apply more or less pull on the throttle cable to compensate. In all the cars which I have driven with cruise control, you can feel the accelerator pedal drop slightly when you hit an uphill climb. And cruise control after-market modules are widely available. The basic brake system of "most" (all?) modern cars - certainly including the Renault "Vel Satis" and "Laguna" models allegedly involved in the widely-publicised cruise control issues - is essentially a very simple hydraulic circuit. ABS, EBD, etc modules may be able to cut in and remove pressure from the circuit momentarily, but you'll generally know about that (at least in the case of ABS) from the noise. Aside from that, there's a direct mechanical/hydraulic, cause-and-effect relationship between the brake pedal and the wheels. Additionally, braking systems are designed so that the force which can be applied exceeds the force which the engine can provide by a substantial factor. So in the Renault cases, while it's entirely possible that a number of independently-designed and unconnected mechanical systems (brakes, throttle, gear lever, ignition key or card) failed simultaneously, it's also possible that the driver made a mistake (honest or otherwise). It has been reported that the driver in the first incident (October 2004) had just had his driver's license restored after a four-year ban for various speeding and alcohol-related offences; perhaps he thought he'd been "flashed" by a speed trap and needed an excuse ? And after that, anyone who wants to get on TV can just call and say their Renault's cruise control blocked; it's "another claimed incident", and why should anyone check if it really happened, if it makes a good story ? When the first incident occurred, it became an excuse for every columnist who has ever had an expensive electronic module replaced in their car, to get on their high horse about "how there's too much electronics and software in cars these days". This ignores the generally superior reliability of electronics - although it's maybe not much comfort if you have a $600 part to replace, that 10 other people have been saved $80 each - and also the fact that without electronics, car manufacturers would be unable to meet emissions standards, thereby incurring the wrath of much the same group of journalists. A few years ago in the UK, there was a related incident when a trucker claimed that a stuck throttle cause him to be unable to stop his truck on a busy highway. It was later revealed (but not on the front page) that he was undergoing psychiatric treatment for an attention-seeking disorder...
Nick, Thanks for your reply. Please note that I am not taking sides on this, just being curious, and I am not an owner of one of those renault cars. I also had no accident recently where I need this as an excuse and don't plan any. Regarding your first remark I would like to mention that cruise control is in my opinion now part of the system in newer cars. The gas pedal does not move as part of speeding up or going up a hill. In fact the gas pedal just gives an electric signal to the electronic injection system and there is no mechanical connection. This is true for my current car (Honda accord 2004) and was true in my previous car (bmw 530d 2000) and to the best of my knowledge it is implemented in such a way also in the Renault cars involved. Regarding the brakes I hope of course that there is no relation with the cruise control. However many cars (including some of the renault models) have now more dynamic controls, like for anti-skidding where brakes on one of the rear wheels is activated when some detection that the car skids in one or the other directions is detected. And this happens without having to press the brake pedal. Mercedes started this a few years ago and it is now widely used (including in my Honda) The other possibility I could think about, it that if the cruise control goes indeed get stuck or blocked (for whatever reason) and does not deactivate when pressing the brake pedal, the driver may have the impression that the brakes are ineffective since the cruise control will counteract with the brakes by speeding up the car whilst the brake pedal is being pressed. See that you are living in Strasbourg. I was born in a village not far away (Mundolsheim) and lived there until I started traveling as a computer specialist in the 1970's. Now living in Brussels.
This would not take a common microprocessor. It would not even take a microprocessor although there might be one for the anti-lock brakes which are common on today's cars. Brakes when they operate turn forward motion and turn it into heat. In doing so the brakes themselves heat up --- a lot. Now in normal use they can quickly cool down because you reach a speed of zero, and either wait for a bit, or stop braking and start going again. Either way they can cool down. However, if they are used enough they don't get a chance to cool. This is a problem in race cars and they use special brake bads because of this. It is not normally a problem in street cars. However, if you are trying to override the accelerator with the brakes the brakes will in fact overheat. This can cause the brakes to work less well. Eventually if you get them hot enough the fluid can boil, and cause the feedback issue that has been mentioned. The real question is why do they make cars where the computer also controls turning the engine off and on?
Perhaps the loss of braking is really a loss of power braking due to the ignition switch being off? Then the brake pedal still works, but requires more pressure, so it seems to be resisting. Mark Brader, Toronto, firstname.lastname@example.org
In his otherwise well reasoned mini-essay, I take issue with Don Norman's statement (RISKS-23.81) regarding what is interpreted as "good". My own recent blood work report gives the measured concentrations, counts, etc., along with "reference ranges" of acceptable values: 34 instances of the form m < acceptable < n i.e., higher or lower are bad 6 instances of the form acceptable < n i.e., low is good 1 instance of the form m < acceptable i.e. high is good This suggests that doctors, in particular, are in general not likely to assume that "high numbers are good."
(I am tempted to say: case closed. Quick: is high MIC good or bad? Rule of thumb: Any definition that has to contain the phrase "in other words" is a definition in trouble. In this case, after reading the "in other words" phrase, I still don't know. I think this means that a High MIC number is good for the organism, but bad for the physician trying to kill it. I still have no idea of how this translates into the MIC rating for an antibiotic.) The definition is quite clear, in fact I (not a medical doctor) understood why a low MIC indicates acceptable antibiotic performance of a drug upon reading the original article (Morrell, RISKS-23.79). The definition makes clear that the MIC refers to the minimum dose that provides suitable antibiotic performance. The text, "The MIC of a drug is defined in broth as the lowest concentration that prevents visible turbidity of the broth following the overnight incubation of 105-6 colony forming units (CFU)/ml (obtained during the log phase of growth)," cannot get more clear on this. All that is required for a complete understanding is knowledge of the word "turbidity" and why measured turbidity in a previously clear solution indicates pathogenic growth. In this respect I must disagree with Mr. Norman, and submit that a surgeon who can't be bothered to remember (or figure out as quickly as I did) the more desirable relative magnitude of a MIC, should be giving his work considerably more thought. David W. Brunberg, Engineering Supervisor, The F.B. Leopold Company, Inc.
The responses to my note concerning the original *JAMA* article on computer assisted mistakes miss my point entirely. Richard Cook discusses at length the problems of complex mistakes and cites Three Mile Island and other complex systems. Don Norman googles himself into trouble by trying to figure out what an MIC is. Like many a googler, he got the definition right, but lost on context. Meanwhile, off thread I discussed the nature of mistakes in the medical environment. Several people sought information on detected medical mistakes. I cautioned against looking for the complex, obscure mistake and instead suggested they target "simple" problems in an overworked, high volume system. "Aim low" I suggested, having observed that most mistakes that I found were simple mistakes dealing with basic medical ideas that preceded computers, computerized systems and were taught to first year medical school students, but forgotten, ignored or overlooked by overworked staff. The fact that computerized systems did nothing to help alleviate these errors is lamentable, but has nothing to do with the mistake, and in fact the error, conceptually preceded computers. Amputating the wrong limb is not a computerized mistake, an adult dose to a pediatric patient is not convergence of multiple errors. Picking the wrong antibiotic based on a confused memory of which is best (high or low) is more understandable to layman, but to the physician proud of how many undergrad and others he had to be better than to become a doctor, it is insulting. When an in-house reviewer reviewed an appendix of mistakes on our first publication, he scribbled in the margins: "this is going to make some of our doctors look like blockheads". This doctor did not consider these mistakes the product of a complex interaction of events, but something that could have been avoided with simple thought and professionalism. I have no real disagreement with either responder on the problems with the complexity of current medical systems, and the need for expensive and comprehensive reform. What I disagree with, as someone who watched real mistakes being made is the idea that that the bulk of mistakes being made in a hospital environment resemble the complex chain of events that occur in airline crashes or nuclear reactor accidents. I am sorry, I have worked my entire professional life in a hospital, and it is far less regulated and far more human, and has far fewer layers of protection between the patient and a serious mistake. Are complex systems introducing new mistakes? No doubt. But the mistakes my system found routinely were simple, and embarrassing to those that made them. My point was that before we chase the complex mistakes, we need to first deal with the simple ones.
Bob, Thanks for your note. It was charitable of you to send it. I am afraid that we are in rather serious disagreement here. There is is no misunderstanding on my part or on Don Norman's. We understood you perfectly. What you wrote was simply wrong. The 'aim low' argument is nonsense as is the contention that these are 'simple' mistakes. Don and I have written enough to make all this clear. [This has been a very interesting discussion. However, I think the basic points have now been adequately made. As I noted in RISKS-23.81, the bottom line is that blame can often be distributed variously and generously! Thanks to the contributors (who have serious credentials) and to the RISKS readers for staying with us! PGN]
In RISKS-23.80, Roland Giersig makes two assertions that I do not believe to be correct. While discussing railroad safety and communication, he states that, for example, if "track-side communication to the on-board units fails, then the system falls back to a state where the train pilot has to navigate by sight instead of relying on the electronic systems. And this is perfectly safe, unlike in air-traffic-control." Every system will have its limitations. Even navigation by sight is not perfectly safe. I refer you to the Canadian Transportation Safety Board Investigation Report on the derailment and collision at Thamesville, Ontario, 1999 April 23, at http://www.tsb.gc.ca/en/reports/rail/1999/r99h0007/r99h0007.asp The train involved was navigating by sight, in midday, under reasonable conditions. After noting a switch target indicating an incorrectly positioned crossover, the crew did not have sufficient time to prevent the subsequent derailment and collision with parked and loaded cars on a siding. Many times, your most reliable safety measure is an alert and informed human somewhere in the system. In the 10 seconds between observing the switch target and the derailment, the crew fully applied emergency braking, shut down the main diesel engine, and transmitted and then repeated an emergency stop message to a train approaching within two minutes in the opposite direction, successfully preventing a far greater tragedy than did occur. Both of the train crew in the engine were killed - the only deaths in the accident. For their actions, both were posthumously awarded the Meritorious Service Medal by the Governor General of Canada. Second, he highlights the statement that "The danger lies in the unknown accuracy of the GPS signal!!" I do not believe the accuracy of the GPS signal is unknown. Many GPS units report EPE - Estimated Position Error, which is an estimate of the accuracy of the GPS signal. It is the estimated error for a 1-sigma level of confidence. A 3-sigma, 95% confidence level, error measure can be calculated by multiplying the given EPE by 3. (Some low-end handheld units are reported to stray from this definition.) With many GPS units delivering 3 metre accuracy, a 95% confidence level with an accuracy of 9 metres would be possible under many conditions. With a GP40 engine measuring 18 metres overall, accuracy comparable to the size of the engine should be possible, and verifiable, in many cases. Of course, it is still necessary to actually design the control system to take advantage of this information. Ultimately, it appears that developers of such systems can fail twice - once by not leveraging all the information provided by the positioning system, and again by not providing useful human interfaces (both informational and control) in the event of either positioning failures or degraded accuracy.
Clock Skew I have an NTP (Network Time Protocol) client installed on my PC. Every hour (and additionally when I manually request), it resynchronizes my clock to NTP servers around the world. Querying five servers (from a list of 164 servers), it uses results from the "best" based on a scoring algorithm. Since different scores might result at different querying events, I keep resynchronizing to different NTP servers with differing skews. If any of the five servers gets a really poor score, it drops out of the chosen five; and another server from the list of 164 joins the five. To defeat fingerprinting based on clock skew, all I have to do is change the option for the resynchronization period to a shorter interval. David E. Ross <URL:http://www.rossde.com/> I use Mozilla as my Web browser because I want a browser that complies with Web standards. See <URL:http://www.mozilla.org/>.
Please report problems with the web pages to the maintainer