Indholdsfortegnelse

Boeing 737 MAX-skandalen – samlet resumé

Boeing 737 MAX-skandalen – samlet resumé

Baggrund

I 2010 lancerede Airbus A320neo med markant bedre brændstofeffektivitet.
Boeing oplevede pres for hurtigt at kunne konkurrere uden at udvikle et helt nyt fly.
I stedet for et „clean sheet“-design valgte Boeing at opgradere den eksisterende 737-platform → 737 MAX.

Designudfordringen

737-designet er oprindeligt fra 1960’erne og sidder lavt over jorden.
De nye, større og mere brændstofeffektive motorer måtte placeres anderledes.
Det ændrede flyets aerodynamik og kunne få næsen til at pege for meget op i visse situationer.

MCAS-softwaren

Boeing implementerede MCAS (Maneuvering Characteristics Augmentation System).
Systemet skulle automatisk presse næsen ned ved risiko for stall.
MCAS baserede sig oprindeligt på data fra kun én angle-of-attack (AOA)-sensor.
Systemet var ikke tydeligt beskrevet i pilotmanualer.
Mange piloter var ikke klar over systemets fulde funktion og autoritet.

Ulykkerne

Oktober 2018: Lion Air Flight 610 styrtede i Indonesien.
Marts 2019: Ethiopian Airlines Flight 302 styrtede kort efter takeoff.
I alt 346 mennesker omkom.
Begge ulykker blev forbundet med fejlagtig MCAS-aktivering pga. forkert sensordata.

Kritik og undersøgelse

Kritik af utilstrækkelig test og risikovurdering.
Kritik af manglende gennemsigtighed over for piloter og myndigheder.
Undersøgelser pegede på kulturproblemer og internt pres for at overholde tidsplaner.
FAA blev kritiseret for at have delegeret for meget certificeringsansvar til Boeing.

Konsekvenser

737 MAX blev globalt grounded i næsten to år.
Boeing foretog softwareopdateringer (MCAS bruger nu to sensorer).
Pilottræning blev ændret og udvidet.
Store økonomiske tab og betydelig omdømmeskade for Boeing.

737 MAX-skandalen & software testing?

1. Single Point of Failure

MCAS brugte oprindeligt kun én AOA-sensor.
God safety-kritisk praksis kræver redundans og validering af input.
Manglende krydstjek mellem sensorer øgede risikoen markant.

2. Utilstrækkelig systemtest (Integration & System Testing)

MCAS’ samlede autoritet (gentagne nose-down kommandoer) var større end først dokumenteret.
Edge cases – fx fejlende sensor + pilotmodreaktion – var ikke tilstrækkeligt testet i realistiske scenarier.
Kompleks interaktion mellem software og menneske blev undervurderet.

3. Kravspecifikation og ændringshåndtering

MCAS’ funktion blev udvidet undervejs (mere autoritet end oprindeligt planlagt).
Ændringer i safety-kritisk software kræver streng impact-analyse og regressionstest.
Sporbarhed mellem krav → design → test ser ud til at have været utilstrækkelig.

4. Manglende Failure Mode & Hazard Testing

Safety-kritiske systemer testes normalt med FMEA/FTA-analyser.
Spørgsmålet: “Hvad hvis sensoren giver forkerte data?” burde have været centralt.
Worst-case kombinationer blev ikke behandlet konservativt nok.

5. Human Factors Testing

Piloter var ikke fuldt informeret om MCAS.
Cockpit-advarsler var ikke altid til stede eller fungerende.
Test burde have inkluderet realistiske simulator-scenarier med uvidende piloter.

6. Certificering og uafhængig verifikation

Safety-kritisk software kræver uafhængig verifikation (IV&V).
Delegering af certificeringsopgaver reducerede muligvis graden af ekstern kontrol.
Compliance ≠ faktisk sikkerhed.

7. Læringspunkter for software testing

Redundans er afgørende i safety-kritiske systemer.
Test skal inkludere fejlscenarier og misvisende input.
Ændringer i krav skal udløse fuld risikovurdering.
Systemer, der interagerer med mennesker, kræver omfattende usability- og stress-test.
Kultur og organisatorisk pres kan påvirke testens grundighed.

Kultur og organisatorisk pres

Tids- og konkurrencepres kan føre til reduceret testdybde og risikovurdering.
Fokus på deadlines og compliance kan overskygge reelt sikkerhedsfokus.
Manglende psykologisk sikkerhed kan forhindre eskalering af kendte problemer. (frygt for fyring)
Organisationskultur påvirker dermed direkte testens grundighed og effektivitet.