home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / aeronaut / airliner / 21 < prev    next >
Encoding:
Text File  |  1992-11-22  |  4.1 KB  |  82 lines
  1. Newsgroups: sci.aeronautics.airliners
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!ohare!news
  3. From: Pete Mellor <pm@cs.city.ac.uk>
  4. Subject: Re: Airline Software-safety database (RISKS-14.08)
  5. Message-ID: <airliners.1992.21@ohare.Chicago.COM>
  6. Approved: kls@ohare.Chicago.COM
  7. X-Original-Message-Id: <4664.9211221721@csrsun8.cs.city.ac.uk>
  8. Sender: kls@ohare.Chicago.COM
  9. Date: Sun, 22 Nov 92 17:21:22 GMT
  10. Lines: 70
  11.  
  12. Dave "Van Damme" Ratner <ratner@ficus.CS.UCLA.EDU> writes in RISKS-14.08: 
  13.  
  14. > I am posting this for Robert Ratner, Ratner Associates Inc, which does
  15. > international consulting in air-traffic control and aviation safety issues.  
  16. > He is looking for a public-accessible data base on software-related incidents 
  17. > in this area.  Email correspondence can be sent to me at ratner@cs.ucla.edu.
  18. > Thanks.            Dave "Van Damme" Ratner    ratner@cs.ucla.edu
  19.  
  20. In my experience, all major manufacturers of software keep databases of 
  21. incidents reported by users of their software and the faults ("bugs") which 
  22. give rise to those incidents. I know for a fact that IBM, ICL, DEC, Unisys 
  23. (or whatever it is now), and Sun all do this. 
  24.  
  25. Such a database is essential to their efforts to improve the quality of their 
  26. software by identifying and fixing bugs, and to reduce their maintenance 
  27. workload by informing customers about known problems so that repeated reports 
  28. are suppressed. 
  29.  
  30. The interesting phrase is "public-accessible". If you are a customer of a large 
  31. manufacturer of system or application software, you will almost certainly have 
  32. access to the *relevant* parts of the database (those which concern the 
  33. products you have bought). This will be provided either on-line, or as printed 
  34. or micro-fiche extracts, updated on a regular basis. 
  35.  
  36. The other interesting phrase is "in this area" (i.e., of air-traffic control 
  37. and aviation safety). 
  38.  
  39. The users of safety critical on-board avionics software are the companies that 
  40. buy the aircraft. They are provided with regular information about all sorts 
  41. of design glitches in the aircraft they have bought, including those in the 
  42. software. Such information is provided in the form of "OEBs" (Operating 
  43. Engineering Bulletins), which are distributed to the flight crews. 
  44.  
  45. Information about software faults in safety-critical avionics systems *must*, 
  46. therefore, be kept on a database somewhere. These databases are public in the 
  47. sense that any pilot on that type of aircraft would have access, but Joe 
  48. Public (as far as I know) does not. 
  49.  
  50. Incidents in flight must (or should) be reported via offical channels by the 
  51. crews. These reports drive the manufacturers' quality improvement programmes. 
  52. After the fault which caused an incident has been diagnosed, it may result in 
  53. an OEB or similar, and in a modification. 
  54.  
  55. Databases of such incident reports are not generally widely accessible. 
  56. Published reports sometimes appear, however. In addition, there are channels 
  57. for anonymous reporting of incidents. In the UK, "CHIRP" is such a forum. In 
  58. the US, I believe the FAA used to run such a scheme, but it was compromised 
  59. when the guarantee of anonymity was removed. 
  60.  
  61. For further information I suggest you contact ALPA. 
  62.  
  63. Given the increasing use of safety-critical software, a central database for 
  64. each major application area would be highly desirable, to say the least. 
  65. Obviously, sensitive issues of commercial confidentiality are involved. In 
  66. particular, it may be difficult to obtain corresponding figures for the 
  67. operating time so as to be able to estimate reliability, and it may be 
  68. difficult to correlate incidents with faults, and so determine which incidents 
  69. are due to software. 
  70.  
  71. I stand to be corrected if anyone *does* know of an official channel for 
  72. public access to flight incident and system fault reports. 
  73.  
  74. Regarding ATC incidents, again I am certain that these are recorded, but access 
  75. is not likely to be easy. 
  76.  
  77. Peter Mellor, Centre for Software Reliability, City University, Northampton 
  78. Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk 
  79. -----------------------------------------------------------------------------
  80.  
  81.  
  82.