| University of Bielefeld - Faculty of technology | |
|---|---|
|
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D. |
|
| Back to Abstracts of References and Incidents | Back to Root |
| This page was copied from: http://catless.ncl.ac.uk/Risks/17.51.html | |
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Costs of 1999->2000 date fix
CD-ROM that hoses your hard drive
Re: Sex, Lies and Backup Disks
How's your spell?
Re: Spelling Correctors
New software that is just too clever
Ambiguous abbreviation: what does "NCSA" mean?
Industrial espionage 0.5%
Re: risks in medical equipment
ABRIDGED info on RISKS (comp.risks)
The Sunday, 3 December 1995 issue of the Detroit News included an article discussing the projected costs of fixing current programs to correctly handle dates in the year 2000.
This discussion has appeared many times in RISKS, but the article provides some interesting numbers (both actual and projected).
Consumers Power Co. (a Michigan-based electrical utility) began the conversion process two years ago and estimates it will take $20-45M (US) to convert their 350 computer systems. A spokesman for Consumers Power says that the problem for them is quite serious; if not fixed, it could lead to denial of service for its customers. Blue Cross (a health-care provider), which processes 100 million medical claims per year, has budgeted $3M for this year alone to begin converting its systems.
The article gives a few other estimates, claiming that the average Fortune
500 company will spend $100M to convert their own systems. Worldwide, the
cost is estimated at $300-600M.
Bill Schoen, a computer programmer from Ford who (the article states) was the first to write about the 2000 problem in 1983, says he contacted every Fortune 500 company about the problem at that time, but few were interested. "The people that were in positions of power then were going to be retired long before this problem kicked in. They didn't care about a mess they weren't going to be around to clean up."
--Jim Huggins, University of Michigan (huggins@umich.edu)[This problem gives new meaning to "going out on a date" (which many systems will do on 1/1/00). PGN]
[From Cable Regulation Digest]
More powerful than a defective Pentium chip, it's the Intel CD-ROM! Intel developed a press kit that really has impact on reporters -- it cripples their computers. In touting their cable modems at the Western Show, Intel execs distributed a press kit with a CD-ROM demo of some of their modem products. Unfortunately, cranking it up will change those pesky configuration specs on your hard drive, leaving you unable to run other programs. Staffers hurriedly posted signs in the press room warning that the CD "will seriously damage your computer system. Please discard immediately."
Stanton McCandlish, Electronic Frontier Foundation
While it's well known that deleting a file from a disk doesn't really remove the contents, I'm not sure if even a disk erasure program will get rid of the file.
I remember a few years after the Nixon tapes and infamous erasure of some chunk of the tape (20 minutes?). I was talking to somebody working at a research lab who said that according to their magnetic recording expert the contents could have been recovered even if they were simply erased -- enough signal would remain if you really wanted to get the information back.
The best advice if you're giving a computer disk to somebody else is to use a new disk and don't use any sort of copy software which might get the unused portion of the last sector of a file.
> spellchecker -> spell checker
Although I knew there was a lot of fairy dust in Silicon Valley, I didn't imagine it had been automated yet. A spell checker checks spells. I don't think that's what was meant. Something that checks spellings is either a `spelling checker' or, in the common Valley contraction, a `spellchecker'.
[And RISKS has been checking for many a spell. PGN]
Spelling deviations have always been funny. The little column-end snippets in The New Yorker are often based on spelling deviations, and have been since long before computers were involved. An old favorite of mine substituted Datsun for dachshund.
The exact nature of the errors has changed, since computers check spelling differently from the human mind. The old deviations, like the example above, were often based on phonetic similarity whereas the new deviations are related to digital manipulation of the letters. But aren't we just continuing our fascination with spelling rather than discussing any risk of computer use?
Our society is obsessed with "correct" spelling. This obsession didn't exist 400 years ago. If an writer changed a spelling, well, that was a new usage. I've heard it claimed that Shakespeare spelled his own name more different ways than anyone else in history.
I pick up spelling easily. This is a blessing and a curse.
In the current environment, where "correct" spelling is considered important, I can produce a document with no spelling deviations beyond an occasional typo. But when I read a document that is well written but marred by significant deviations from standard spelling, my mind is drawn to the spelling to the detriment of my ability to absorb the content. At such times, I often wish that I and others had a more accepting attitude toward spelling deviations.
Perhaps the risk is that computers have given us another basketful of examples to feed an unhealthy fascination with spelling.
Edward Reid[Similar items have appeared in RISKS in the past. However, this isn clearly a serious risk, and deserves repeating for new readers. PGN]
Jeffrey Sherman (RISKS-17.49) mentioned quirks of WordPerfect 6.1 being too clever. Here's something we found a few weeks ago:
A colleague was trying to prepare a table for publication, listing locations of particular parts of a gene in a long sequence. He would type something like '179-285' into the table boxes, only to find when he tabbed along to the next box, that WP would replace it with -106. He couldn't find any way to persuade WordPerfect to stop treating the table box as a spreadsheet entry, and being in a hurry to get the paper completed, wound up typing these entries in the form '179 to 285', which finally persuaded WP to leave them alone.
The posting on "NCSA FireWallCon '96" in RISKS v17 n42 unintentionally illustrates another (in)famous risk: ambiguous abbreviations.
When reading this item, I, and I suspect many others, assumed that "NCSA" referred to the US National Center for Supercomputing Applications, well-known for (among many other things) such widely-used software as NCSA Telnet for PCs and more recently NCSA Mosaic. Since NCSA have been a major internet site for some years, their sponsoring a firewalls convention seemed quite plausible. I thought the various *.ncsa.com internet addresses given were a bit odd, since NCSA always used to have *.ncsa.uiuc.edu addresses, but I didn't pay too much attention to this.
It was only when reading the _last_line_ (the poster's signature, which in fact our moderator usually trims) of the RISKS item that I discovered that "NCSA" actually referred to the (presumably US) National Computer Security Association!
The lessons to be learned? Well, there are about 450K possible 4-letter sequences, but a simple "birthday paradox" calculation shows there's a 50% chance of duplication if we randomly choose 800 (!) of them. (The nonrandom letter-frequency distribution of real-world abbreviations just makes things worse.) So this sort of "name abbreviation ambiguity" is going to happen more and more often. About all we can do is to spell out key abbreviations in the lead paragraphs of our postings.
- Jonathan Thornburg
A snippet from the magazine "Information Management and Computer Security" provides the following survey (orig. source: Survive):
Survey of Disaster Causes: Europe and USA 1980 - 1991
1. Software problems 14.8%
2. Fraud 11.1%
3. Malicious Damage 10.2%
...
20. Electromagnetic interference 1.3%
23. Earthquake 0.8%
26. Industrial espionage 0.5%
Does anyone know of any *published* industrial espionage (information warfare) cases?
Another article by John Bates (Australia, KPMG 1995 Fraud Survey) states that 7th on the scale of most prevalent fraud by management was that 6% of information theft was perpetrated by management.
David@lifton.demon.co.uk Lifton Research[There are quite a few *unpublished* ones. PGN]
> ... because some technologies are socially defined as 'male' ...
Fortunately for the RISKS community, my partner has discovered the real reason for people being intimidated by technology. She has observed that, despite the fact that I am a computer professional, I seem to be totally intimidated by digital technology in certain contexts. Specifically, I am totally unable to recall which programs to use for different types of clothes when putting a load of washing into the automatic washing machine.
She has thought long and hard about this and has concluded that the difference is that most kitchen equipment comes in nice attractive light colours whereas technologies that are socially defined as 'male' often come in dark coloured or black boxes.
She has concluded that the simplest solution to enable me to do a load of washing on my own is to paint the washing machine black.
Unfortunately, the correlation is not perfect. For example, I can never remember how to programme the (black) video recorder to record a TV show at a particular time when we are out, either.
A more in-depth study is needed. If the European Union could provide me with funds for the purchase of a lot of advanced domestic gadgets in a variety of attractive colours, I will undertake the necessary controlled experiments.
Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB, UK +44 (171) 477-8422 p.mellor@csr.city.ac.uk
I read with interest the accounts of alarm silencing within the medical environment. In my position as a clinical engineer, I have spent many hours evaluating medical equipment for purchase and have seen the same issues wrt *all* medical equipment.
Specifically with infusion pumps - most do have some type of indication that they are being operated on battery - sometimes it's a positive indication (a battery icon lit up on the front panel) and sometimes it's a negative indication (an AC plug lit up on the front panel). Most pumps do have an alarm to indicate that the battery is being depleted - usually a two stage alarm - one which alarms half an hour before the battery depletes and then one which alarms right before the battery depletes and the equipment powers off (if it is not plugged in immediately). There are also some battery management menu items in later model pumps. Lastly, most personnel are trained in the use of the equipment - in fact because of some voluntary regulatory requirements (Joint Commission on Accreditation of Hospitals - JCAHO for short), hospitals are required to document that training has occurred *and* prove proficiency in the use of the equipment they need to use in the discharging of their duties.
Even with the above, occurrences like those described in the posts happen. There are several things going on - first, in an ICU, a nurse is *bombarded* with many different pieces of equipment, which for the most part have slightly different operating/user interfaces and different purposes. Mistakes are bound to happen. Second, if a hospital has not standardized on one manufacturer for a certain type of device, the user has yet another interface/another combination to worry about - it's kind of like going between MS-DOS, UNIX, Windows, Macintosh, etc - little things can make a big difference (this is a big issue for me as I investigated medical device incidents in the hospital - not to mention materials management wanting to save money by standardizing on one manufacturer).
I know that in my current position, I'm trying to reduce the number of interfaces that clinicians are dealing with - we routinely tell medical manufacturers that we want fewer/smaller devices that have a single interface - as well as integration between devices for better information display - i.e. in one place. I know that the future of medical devices will eventually be some sort of transduction mechanism hooked to a PC or some computer which does data gathering, processing and dissemination. Until then, we will have to deal with the onesies and twosies and incongruent mix of technologies and concentrate on training, training and training along with striving for standardization and reduction of different interfaces for clinicians.
Lastly, what I find interesting is that we used to tell the clinicians that
the technology was not there to replace them - i.e., *look* at your patient
- the technology was merely there to assist them by giving them more
information. Sometimes if the clinicians are pressed for time, they lose
that perspective - and yes, sometimes they are intimidated by the
technology. I'd venture to say that producing medical devices is probably
one of the more demanding pursuits because of the regulatory jungle, the
nature of the business (saving lives) and the broad range of technical
skills of clinicians.
It is interesting to read the recent stories about the risks in silencing alarms. The problem is well known in the process industry, but on a much larger scale. Instead of having a single or a few alarms, there are hundreds or thousands. A nuclear power plant can easily have several thousand alarms, and one of the Norwegian off-shore installations is known to have about 15.000 alarms that go into the control room.
The reason for this proliferation is the use of information technology. In the "old" days, alarms had to be announced via an annunciator tile, and there was a limit to how many annunciator tiles one could put in a panel or on a wall. Not so with computers. Alarms can be produced simply by writing them to a screen, and the capacity of the screen is unlimited. That is, assuming that the operators are able to scroll through all the alarms and find the important ones.
This has led to the art of alarm filtering, which uses often complicated logic to supress alarms that are not relevant at the moment. Note the use of the term RELEVANT. This is where the problem lies, because it requires that all conceivable situations - or at least all the important ones - can be analysed in advance. Quite apart from the problem of software reliability (of the filtering algorithms) this touches upon the problems of risk analysis and interface design.
To return to alarm silencing, this is clearly a problem in control rooms as well as in hospitals. It is a problem for the doctors as well as the patients. When alarms occur frequently, as during an accident, various types of visual and auditory signals are used to attract the attention of operators. But in the medium and long term these signals are seen as distracting (which they are) and useless (which they should not be) and are hence ignored. This is a simple fact of human nature that designers should acknowledge. The risks in designing alarm systems without considering the users' ability to respond appropriately are clearly substantial. it is a problem that is taken very seriously in the industries. But specific spectacular examples of ignoring alarms are welcome.
One that comes to mind is the pilot's comment in the Lauda Air crash in 1991. According to the transcript from the CVR, the pilot said: "But, ah, you know it's a - it doesn't really, it's just an advisory thing, I don't ah -". This was in response to the cockpit warning light. Six minutes later the plane had crashed.
Fax: +47.6918.7109Cliff Sojourner's article (RISKS-17.50, in response to John Strohm's article) struck a nerve with me too. All the medical monitors are great technology but apparently the tolerances are set for far too many false alarms to be safe in the real world. I suppose that each manufacturer wants to be sure it isn't their equipment that fails to give a warning early enough - that way a failure can be blamed on the person watching the monitor, but the end result is that real problems go unnoticed for long periods.
Last spring my two-month-old nephew was on a morphine IV pump after surgery, along with all the various monitors and alarms Cliff mentioned. The heart rate monitor repeatedly alarmed and the nurses would come in and silence it, telling us it was normal. Unfortunately, the monitor didn't have another alarm that said there was a real problem. It turns out my nephew was getting a morphine overdose and his heart rate really was getting dangerously low. This was only discovered after persistent nagging on the part of the mother and grandmother who were there the whole night and watched the monitor themselves. Finally they got someone to pay enough attention and he was transferred to ICU and antidote was administered. It was touch and go the next twelve hours or so, but he's fine now. But I wonder what we would have been told the cause of death was had there been no family member there and awake.
As Cliff wrote:
> The risk here is that a real life-threatening situation would
> not be discovered in time to help the patient. ...
In this case the situation was discovered in time, but without much margin.
Jay Harrell, Atlanta, Georgia
On 30 Nov 1995 SOJOURNER_CLIFF@tandem.com wrote about visual and audible alarms used in an Newborn Intensive Care Unit, and how false alarms are common, and how they are regularly silenced via a cut-off switch:
The initial problem of ignored alarms is of course quite troublesome, but I
wonder about a simpler but more insidious risk: are alarming noises
_harming_ the patients, simply by their existence? Certainly, they aren't
going to be bone-shaking klaxons, but if someone desperately needs rest, or
if their sensory nerves aren't yet fully formed, can we truly say that this
is a good environment for them to be in?
I feel safe in saying the current risk is minimal, and perhaps nonexistent, but that isn't a reason to ignore the issue. The science of user-interfaces is still in development, and we mustn't forget that a user is anybody in the room, be they human or animal, asleep or awake, participants or not. Learning when to avoid using a particular type of user-interface element (like an audible alarm) is just as important as learning which elements should be used in the first place.
Here, some obvious solutions present themselves: visible alarms (like rotating police-car style lights) that are highly visible, but shaded so they are only visible to people standing up. Such a light would be obvious the instant you enter the room, but not disturb the patients. (A minor risk here is that of creating problems for short, or wheelchair using, staff members.)
In a different (and unfortunately much more RISKy vain) one could use an entirely different precept of how alarms should be handled, and give staff electronic devices (pagers, etc.) that will be activated by a central computer on any alarm condition in their vicinity or area of interest.
Both lose the value (immediacy, direction, and information content) of an audible alarm, but avoid the problem of alarming the folks who don't need to be alarmed in the first place.
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Unreliable warning systems have been problematic for centuries (hence the tale of the boy who cried wolf). We quickly learn to ignore them so we can continue with real work. However, the danger is that we get used to expecting them to be unreliable.
While in high school I once borrowed a neighbor's family car. They told me, "Oh, by the way, you can ignore that oil light, it's been on for ages." You can guess what comes next. In the middle of the night as I am returning home, the thing throws a rod, leaving a trail of engine parts on the road. An indicator of imminent failure alerted them to a well-known maintenance issue, yet they completely ignored it.
The risk is the age old one of complacency. People get used to complex technological devices being flaky. When yet another device seems to be acting up, they don't take it seriously, even when someone's life depends on its proper operation. As an engineer, I find this behavior totally incomprehensible, but it is something I have to expect from users. Unfortunately, I can only go so far in preventing a user from doing something stupid. Worse, I can never fully anticipate the ways in which the system can be abused and misused. This seems to be more a problem of psychology than technology. There is no bug for me to fix if a user chooses to ignore an alarm condition and insists on continuing to run.
This problem is compounded by uncoordinated and unprioritized alarms. The multiple systems monitoring a patient are all clamoring for attention as the one thing that needs attending to. In reality only some of them may really be pertinent, while others can be safely ignored for the moment. Imagine working in an environment where a half dozen little crises seem to be erupting every moment, despite the fact that everything is under control. It makes it hard to tell when things go out of control.
Steve
The issue of alarms and alarm suppression in a hospital environment is a rather complex one. From time to time IEEE EMB (the bio-med engineering magazine) discusses the problems involved. There is a fundamental conflict in many hospital settings:
It appears that the medical equipment industry is traversing the same ground with regards to audible alarms as the military and space industries crossed decades ago.
In both the space and military applications, it has long been known that too high a false alarm rate will cause human operators to either ignore alarms from that system, or shut them off. In neither industry was this considered a "good" thing, so most RFP's would specify the maximum false alarm rate allowable for a system. In some systems, this meant that some valid alarm situations might go unannounced for a time, but the system designs usually required that a real alarm situation would be identified within a specified time. These two (and, of course there were others) requirements led to both hardware and software designs that attempt to filter out transient noise and that also track suspect records over time to identify alarms in both noisy and lossy environments.
In most instances, both hardware and software designs are modified to provide the most capability in handling these problems.
In the case of some satellite communications, data frames could be marked at transmitting end as to whether all the data in the various fields (i.e. from the various instruments) was the latest and most likely reliable, or old (no new info from last frame) and suspect. On the receiving end, the entire frame could be marked as to whether the broadcast was received complete, partially or not at all. This still presented too much alarm data, and so the data is passed to diagnostic software that tracks states from frame to frame, accumulating historical information and watching for thresholds and other types of trend information to generate alarms at consoles for human monitoring. Of course, if done improperly, the system can miss alarms, but the groups writing this software are supposed to thoroughly test it, and run both filtered and non-filtered versions in simulation and early operations to verify the software (along with all the other software verification processes).
If the medical industry looked around at other safety critical industries that had trod this path before, some of these risks from too frequent alarms could be quickly reduced or eliminated.
But, I guess this is the case of the risk of those ignorant of history are doomed to repeat it :-/
--Rocky
| This page was copied from: | http://catless.ncl.ac.uk/Risks/17.51.html |
| COPY! | |
| COPY! | |
|
by Michael Blume |