Airbus 320 design/HF investigative processes
Per Ardua ad Astraeus
Thread Starter
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
Airbus 320 design/HF investigative processes
Place holder for the discussion on Airbus 320 sensors/design/general accident matters etc (see Post 2280 in http://www.pprune.org/forums/showthr...84415&page=114 in R&N). If anyone posting here wishes a post from the R&N thread copied in to preserve the flow please let us know.
Guest
Posts: n/a
Well I know this may be interpreted as out of subject (the thread was split) but this comes as an answer to some (supposedly) experts here and as an effort to make some people see that Murphy's Law should always be considered everywhere, anytime.
Some excerpts from an study dealing with problems with a machine called "Therac25". Please someone point out whether or not its a trustworthy source:
Despite what can be learned from such investigations, fears of potential liability or loss of business make it difficult to find out the details behind serious engineering mistakes. (Underline is mine)
Most accidents are system accidents; that is, they stem from complex interactions between various components and activities. To attribute a single cause to an accident is usually a serious mistake. In this article, we hope to demonstrate the complex nature of accidents and the need to investigate all aspects of system development and operation to understand what has happened and to prevent future accidents. (underline is mine)
The paper can be obtained @
http://courses.cs.vt.edu/~cs3604/lib.../Therac_1.html
Some excerpts from an study dealing with problems with a machine called "Therac25". Please someone point out whether or not its a trustworthy source:
Despite what can be learned from such investigations, fears of potential liability or loss of business make it difficult to find out the details behind serious engineering mistakes. (Underline is mine)
Most accidents are system accidents; that is, they stem from complex interactions between various components and activities. To attribute a single cause to an accident is usually a serious mistake. In this article, we hope to demonstrate the complex nature of accidents and the need to investigate all aspects of system development and operation to understand what has happened and to prevent future accidents. (underline is mine)
The paper can be obtained @
http://courses.cs.vt.edu/~cs3604/lib.../Therac_1.html
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by flyingnewbie10
study dealing with problems with a machine called "Therac25"
I don't think any of the lessons from this story in computer safety in medicine has much relevance to aviation. The cultures are exceptionally different. Let me briefly indicate although it's halfway off-topic. The Therac story was a lot about incompetent engineering (also incompetent user-interface engineering and complete lack of safety analysis) as well as about the lack of any traceability of incidents histories. Aerospace pays a lot of attention to safety analysis and user-interface engineering, and has an international system (or collection of systems) for logging and learning from incidents (the all-operators Telex/Service Bulletin/AD system).
PBL
Last edited by PBL; 21st Sep 2007 at 12:46. Reason: Spelllling
Guest
Posts: n/a
I don't think any of the lessons from this story in computer safety in medecine has any relevance to aviation. The cultures are exceptionally different.
However all this makes me feel even more that history repeats itself...
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
flyingnewbie10:
For the last time - real-time systems such as those used in the A32/3/4/80 are a completely different paradigm and methodology to the imperatively programmed systems that the average person thinks about when discussing computers.
For the last time - real-time systems such as those used in the A32/3/4/80 are a completely different paradigm and methodology to the imperatively programmed systems that the average person thinks about when discussing computers.
Guest
Posts: n/a
For the last time - real-time systems such as those used in the A32/3/4/80 are a completely different paradigm and methodology to the imperatively programmed systems that the average person thinks about when discussing computers
Higher Level has to go to Low Level and there is where s... might happen (I said might).
For the last time, too: Investigators should be open to all possibilities. We have to know the system, how it synchronizes, how it takes input, how it process input, how it takes priorities and so on. Not just make general and pseudo-authoritative statements about it.
However I have a clear disavantadge to defend my point here, as our dear CENIPA says it found the TL pedestal but does not show any photograph or any impression about it. And then sends the piece to the potential "wolf"...
By the way I will ask again: Where are the docs about that (one) TL above idle warning ?
(P.S. : The information about the TL pedestal is confirmed news - from the last day of air traffic parlamentary commission)
Aerospace pays a lot of attention to safety analysis and user-interface engineering, and has an international system (or collection of systems) for logging and learning from incidents (the all-operators Telex/Service Bulletin/AD system).
Take that (again !!) TL above idle warning and what AI safety director stated about it before Congressmen.
BTW, my guesses:
1 - He was saying the truth (yet to confirm);
2 - The warning could work more frequently than "desirable", showing some problem with TLA sensors (maybe someone understands me here);
3 - The warning related procedure represented a risky overload to the A320 realtime computer system given the available processing capacity.
Last edited by flyingnewbie10; 21st Sep 2007 at 13:50. Reason: replacing declarative with functional
