Lessons Learned im Requirements Management: Ariane 5 Flug 501

Die Katastrophe von Ariane 5 Flug 501 zeigt, warum wir immer zweimal nachdenken sollten, bevor wir Anforderungen, Engineering-Designs und Tests aus früheren Projekten unverändert wiederverwenden. 

In der Hardware-Produktentwicklung ist es üblich, Anforderungen, Software-Routinen, Testfälle oder Designentscheidungen aus früheren Projekten wiederzuverwenden. Das kann Zeit sparen, aber nur dann, wenn die Bedingungen, unter denen diese Entscheidungen sinnvoll waren, weiterhin gelten.

Ariane 5 Flug 501 war der erste Flug der europäischen Ariane-5-Rakete am 4. Juni 1996. Die Rakete übernahm einen Teil der Inertialreferenz-Software von Ariane 4, einer früheren europäischen Rakete, bei der die Software erfolgreich funktioniert hatte. Doch Ariane 5 folgte einem anderen Flugprofil, ein Wert überschritt den vom Programm erwarteten Bereich, und die Rakete wurde weniger als eine Minute nach dem Start zerstört.

Die Lehre daraus ist einfach, wird aber leicht vergessen: Bevor Sie Arbeit aus früheren Projekten wiederverwenden, prüfen Sie, ob dieselben Annahmen und Betriebsbedingungen auch im neuen Projekt noch gelten.

Wichtige Erkenntnisse

• Die Wiederverwendung bewährter Anforderungen, Software, Tests oder Designentscheidungen spart Zeit, aber der ursprüngliche Kontext muss überprüft werden.
• Überprüfen Sie wiederverwendete Testfälle, bevor Sie sie einsetzen, um dieselbe Anforderung in einem anderen Produkt nachzuweisen.
• Reduzieren Sie Risiken, indem Sie Anforderungen, Testverfahren, Nachweise und Status miteinander verknüpft halten.

Was beim Start von Ariane 5 geschah

Am 4. Juni 1996 absolvierte Ariane 5 ihren ersten Flug von Kourou in Französisch-Guayana aus und transportierte vier Cluster-Forschungssatelliten für die Europäische Weltraumorganisation. Die Mission dauerte weniger als eine Minute. Etwa siebenunddreißig Sekunden nach dem Start wich die Rakete von ihrer geplanten Flugbahn ab und wurde zerstört.

Die Ursache lag im Inertialreferenzsystem, das Lage- und Geschwindigkeitsdaten an den Bordcomputer der Rakete übermittelte. Ariane 5 übernahm Software von Ariane 4, einschließlich einer Ausrichtungsroutine, die nach dem Start noch etwa 40 Sekunden aktiv blieb. Diese Routine hatte in Ariane 4 funktioniert, doch Ariane 5 folgte einem anderen Flugprofil.

Aufgrund dieses anderen Profils geschahen mehrere Dinge in schneller Folge:

• Ein horizontaler Geschwindigkeitswert wurde größer, als die Software erwartet hatte.
• Die Software versuchte, den Wert von einer 64-Bit-Gleitkommazahl in eine 16-Bit-Ganzzahl mit Vorzeichen umzuwandeln, doch der Wert passte nicht mehr hinein.
• Die Umwandlung lief über, und das Inertialreferenzsystem behandelte dies als Fehler und schaltete sich ab.
• Das Backup-System lief mit derselben Software und schaltete sich aus demselben Grund ebenfalls ab.
• Ohne gültige Flugdaten verwendete der Bordcomputer stattdessen Diagnosedaten, gab falsche Flugbefehle aus, und die Rakete wurde zerstört.

Gerade das macht diesen Fall für das Anforderungsmanagement so nützlich. Die wiederverwendete Software hatte zuvor funktioniert, trug aber eine Annahme aus der früheren Rakete in sich: dass dieser Wert innerhalb eines sicheren Bereichs bleiben würde. Ariane 5 veränderte den Kontext dieser Annahme, daher musste sie im neuen System sichtbar gemacht und erneut geprüft werden.

Die Darstellung erinnert daran, dass auch wiederverwendete Engineering-Arbeit noch eine einfache Prüfung braucht: Sind die Annahmen dahinter im neuen System noch wahr?

Was Hardware-Teams aus dem Fall Ariane 5 lernen können

Die meisten Hardware-Teams bauen keine Raketen, aber sie verwenden bewährte Arbeit ständig wieder. Ein PCB-Block aus einem früheren Produkt kann in ein neues Design kopiert werden. Eine Firmware-Routine kann in eine neue Hardware-Revision übernommen werden. Ein Testverfahren kann bestehen bleiben, obwohl sich die Stromversorgungsarchitektur geändert hat. 

Das ist normale Engineering-Arbeit. Wiederverwendung hilft Teams, schneller voranzukommen. Der wichtige Schritt besteht darin sicherzustellen, dass Anforderung, Annahme und Verifizierungsprüfung weiterhin zum neuen System passen.

Wiederverwendete Anforderungen überprüfen

Eine Anforderung, die in einem Produkt funktioniert hat, sollte nicht automatisch als auch im nächsten gültig betrachtet werden. Dieselben Worte mögen noch richtig aussehen, aber die Betriebsbedingungen darum herum können sich geändert haben. Zum Beispiel kann eine Strombegrenzung, ein Temperaturbereich oder eine Schnittstellenbeschränkung in einem Design sicher sein und in einem anderen überprüft werden müssen. Bevor eine Anforderung wiederverwendet wird, sollte das Team prüfen, ob das neue Produkt noch innerhalb derselben Annahmen arbeitet.

Annahmen mit Verifizierungsverfahren verknüpfen

Einige der wichtigsten Engineering-Annahmen werden nie als formale Anforderungen aufgeschrieben. Sie leben in Designnotizen, alten Testplänen oder im Gedächtnis einzelner Personen. Das kann riskant werden, wenn Arbeit wiederverwendet wird. Wenn eine Annahme eine Designentscheidung beeinflusst, braucht das Team eine Möglichkeit, sie mit einer Verifizierungsprüfung zu verknüpfen. Andernfalls ist es leicht, die Entscheidung wiederzuverwenden, ohne den Grund zu sehen, der sie ursprünglich sicher gemacht hat.

Tests überprüfen, wenn sich Anforderungen ändern

Ein Testfall, der im vorherigen Projekt bestanden wurde, beweist im nächsten nicht immer dasselbe. Wenn sich die Anforderung ändert oder wenn sich das System rund um die Anforderung verändert, muss sich möglicherweise auch das zugehörige Testverfahren ändern. Das ist besonders wichtig, wenn Teams Testfälle, Abnahmekriterien oder Compliance-Nachweise wiederverwenden.

Wie ein vernetzter Anforderungs-Workflow hilft

Ein besserer Anforderungs-Workflow behandelt eine Anforderung nicht als isolierte Textzeile. Er hält die Anforderung mit dem zugrunde liegenden Grund, der davon betroffenen Designarbeit und der Verifizierungsarbeit verbunden, die zeigt, ob sie noch gültig ist. 

Genau das ist am wichtigsten, wenn sich etwas ändert. Eine wiederverwendete Anforderung mag noch korrekt aussehen, aber die Annahme dahinter passt möglicherweise nicht mehr zum neuen Produkt. Ein Test mag noch existieren, aber er prüft möglicherweise nicht mehr die richtige Bedingung.

In einem vernetzten Workflow können Teams die wichtigen Elemente eng zusammenhalten: die Anforderung, den Kontext dahinter, die Verifizierungsmethode, das Verfahren, das Ergebnis, den Nachweis und den aktuellen Status. Anstatt alte Dokumente oder Testberichte zu durchsuchen, können Ingenieure sehen, was miteinander verbunden ist und was möglicherweise erneut überprüft werden muss.

Altium Requirements Portal unterstützt diese Art von Workflow, indem Anforderungen, Rückverfolgbarkeit, Zuständigkeiten und Verifizierungsarbeit in einer gemeinsamen Umgebung zusammengeführt werden. Das hilft Teams, bewährte Arbeit mit mehr Vertrauen wiederzuverwenden, weil die Anforderung und die dazugehörigen Prüfungen miteinander verbunden bleiben.

Sind die alten Annahmen in Ihrem Projekt noch wahr?

Jedes Hardware-Team verwendet bewährte Arbeit wieder. Das ist keine Abkürzung, die man vermeiden sollte, sondern ein praktischer Weg, schneller zu entwickeln und gute Engineering-Entscheidungen weiterzutragen. 

Die nützliche Frage lautet, was sich rund um diese wiederverwendete Arbeit verändert hat:

• Hat sich der Betriebsbereich geändert? 
• Muss der Test überarbeitet werden? 
• Gelten die Annahmen hinter der ursprünglichen Entscheidung noch?

Wenn Teams diese Fragen beantworten können, wird Wiederverwendung vertrauenswürdiger. Die Anforderung steht nicht für sich allein. Der Grund dahinter, die Verifizierungsprüfung und die Nachweise bleiben nah genug beieinander, damit das Team sie überprüfen kann, wenn sich der Produktkontext ändert. 

Das ist die Lehre, die Ariane 5 Hardware-Teams bis heute mitgibt: Wiederverwendung funktioniert am besten, wenn der Kontext dahinter verbunden bleibt.

Machen Sie Entscheidungen zur Wiederverwendung mit einem Anforderungsmanagement-Tool, auf das Ihr gesamtes Team zugreifen kann, leichter überprüfbar und vertrauenswürdiger.

Starten Sie mit Requirements Portal →

Häufig gestellte Fragen

Kann die Wiederverwendung von Engineering-Arbeit riskant werden?

Die Wiederverwendung von Engineering-Arbeit kann riskant werden, wenn sich der Produktkontext ändert, die ursprünglichen Annahmen, Betriebsgrenzen oder Verifizierungsprüfungen jedoch nicht erneut überprüft werden. Die Arbeit mag noch korrekt aussehen, aber die Bedingungen, die sie im vorherigen Projekt gültig gemacht haben, gelten möglicherweise nicht mehr.

Was sollten Ingenieure prüfen, bevor sie eine Anforderung, einen Test oder eine Designentscheidung wiederverwenden?

Teams sollten prüfen, ob das neue Produkt dieselben Betriebsbedingungen, Schnittstellen, Grenzen und Abnahmekriterien wie das ursprüngliche Projekt verwendet. Sie sollten außerdem bestätigen, dass die zugehörige Verifizierungsmethode im neuen System noch immer das Richtige nachweist.

Wie hilft Rückverfolgbarkeit, wenn Anforderungen wiederverwendet werden?

Rückverfolgbarkeit hilft Teams zu erkennen, wie eine Anforderung mit Designentscheidungen, Annahmen, Testverfahren, Nachweisen und Status verbunden ist. Wenn wiederverwendete Arbeit in ein neues Projekt übernommen wird, machen diese Verknüpfungen leichter sichtbar, was noch gültig ist und was überprüft werden sollte.