PPRuNe Forums - View Single Post - And then there was only one
View Single Post
Old 8th Aug 2018, 05:43
  #43 (permalink)  
megan
 
Join Date: Mar 2005
Location: N/A
Posts: 5,951
Received 395 Likes on 210 Posts
Going to be a very long, long time before pax hop on a pilotless aircraft IMHO, or even cargo ops.

https://www.atsb.gov.au/media/3532398/ao2008070.pdf

5.6 Final comments and lessons for new systems
The investigation into the in-flight upset occurrence involving QPA on 7 October 2008 was difficult and took an extensive amount of time. It covered a range of complicated issues, including some that had rarely been considered in depth by previous aircraft accident investigations (such as system safety assessments and single event effects).
Ultimately, the occurrence involved a design limitation in the flight control system that had not been previously identified by the aircraft manufacturer, and a failure mode with the ADIRU that had not been previously identified by the ADIRU manufacturer. Given the increasing complexity of such systems, this investigation has offered an insight into the types of issues that will become relevant for future investigations. It also identified a number of specific lessons or reminders for the manufacturers of new complex, safety-critical systems to consider. These include:
• System safety assessments (SSAs) and other design evaluation activities should recognise that ADIRUs and similar types of equipment can generate a wide range of patterns of incorrect data, including patterns not previously experienced.
• Failure mode effects analyses (FMEAs) have a limited ability to identify all equipment failure modes, particularly for complex, highly-integrated systems.
• Where practicable for safety-critical functions, SSA and other design evaluation activities should consider the effects of different values of system inputs in each mode of operation, particularly during transitions between modes.
• The BITE for ADIRUs and similar types of equipment should check the results of each key stage in the processing of output data.
• SEEs are a potential hazard to aircraft systems that contain high-density integrated circuits. Designers should consider the risk of SEE and include specific features in the system design to mitigate the effects of such events, especially in systems with a potentially significant influence on flight safety.
• The in-service performance records for safety-critical line-replaceable units should include all reported performance problems, not just those that result in the removal of the unit from the aircraft.
• The records for the key components within safety-critical systems should include details such as production or batch codes as well as the part number where practicable.
A broader lesson concerns the safety assessment activities needed for complex systems. In recent years there have been developments in the guidance material for system development processes and research into new approaches for SSA. However, design engineers and safety analysts also perform a safety-critical function, yet the investigation found little published research that has examined the human factors issues affecting such personnel. In other words, there has been limited research that has systematically evaluated how these personnel conduct their evaluations of systems, and how the design of their tasks, tools, training and guidance material can be improved so that the likelihood of design errors is minimised. The need for further research and development in this area will become more important as system complexity increases over time.
What is worse is para 6.3 (bolding mine),
• It is very likely that the air data inertial reference unit (ADIRU) data-spike failure mode involved a problem with the data packaging and queuing within the ADIRU’s central processing unit module. This fault resulted in numerous data anomalies, including air data reference parameters being intermittently transmitted with the data or label of another parameter. Despite extensive testing and analysis, the exact origins of the failure mode could not be determined.
• Tests and analyses showed that the air data inertial reference unit data-spike failure mode was probably not triggered by a software bug, software corruption, hardware fault, physical environment factors (such as temperature of vibration), or from electromagnetic interference.
• The three known occurrences of the air data inertial reference unit data-spike failure mode occurred on two A330 aircraft operated by the same operator; however, no factors related to the operator’s aircraft configuration, operating practices, or maintenance practices were identified that were associated with the failure mode.
• The flight crew’s responses to the warnings and cautions, the pitch-down events, and the consequences of the pitch-down events, demonstrated sound judgement and a professional approach.
Also,
https://www.atsb.gov.au/media/24550/...503722_001.pdf
When the upset event occurred and the primary flight display indicated an underspeed, then an overspeed condition, as well as the slip/skid indicator showing full right deflection, the crew experienced a situation that had previously been considered not possible.
Things went downhill for the PIC, Captain Sullivan, post event, PTSD.

QF 72

https://www.atsb.gov.au/media/24550/...503722_001.pdf
Erroneous acceleration values sourced from the Air Data Inertial Reference Unit (ADIRU) and flagged as valid to the aircraft precipitated an in-flight upset as the aircraft climbed through FL365.......The software anomaly was not detected in the original testing and certification of the ADIRU.
Then there was,

https://aviation-safety.net/database...?id=20010207-0
Following a nighttime flight from Barcelona to Bilbao, the crew positioned the plane for a runway 30 approach and landing. During their final ILS approach, the aircraft encountered heavy turbulence at about 200 feet agl. with gusts up to 65 mph. The aircraft encountered windshear with 1.25G updraft, downdraft and a tailwind gust at just 70 feet agl. When the Ground Proximity Warning System (GPWS) sounded, the captain called for a go-around while pulling on the sidestick, reportedly without pressing his priority control button. The combination of dynamic winds and the crew actions created a situation that triggered the airplane's alpha protection system. As the crew applied TOGA power for a go-around, with both pilots pulling back on their sidesticks, the alpha protection law reduced the elevator nose-up command. Instead of a go- around, the aircraft struck the runway with a vertical speed of approx. 1,200 fpm. The nosegear collapsed and the aircraft skidded 3,280 feet (about 1000 m) down the runway before coming to a stop.

Probable Cause:
"The cause of the accident was the activation of the angle of attack protection system which, under a particular combination of vertical gusts and windshear and the simultaneous actions of both crew members on the sidesticks, not considered in the design, prevented the aeroplane from pitching up and flaring during the landing."
The difficulty in testing software, I understand, is determining ALL the possible failure modes. Pilots are here to stay.
megan is offline