Wnioski z zarządzania wymaganiami: lot 501 rakiety Ariane 5

Katastrofa lotu 501 rakiety Ariane 5 pokazuje, dlaczego zawsze warto dwa razy zastanowić się przed ponownym wykorzystaniem bez zmian wymagań, projektów inżynierskich i testów z wcześniejszych projektów. 

W rozwoju produktów sprzętowych często ponownie wykorzystuje się wymagania, procedury programowe, przypadki testowe lub decyzje projektowe z wcześniejszych projektów. Może to oszczędzać czas, ale tylko wtedy, gdy nadal obowiązują warunki, które sprawiały, że te wybory były właściwe.

Ariane 5 Flight 501 był pierwszym lotem europejskiej rakiety Ariane 5, który odbył się 4 czerwca 1996 roku. Rakieta ponownie wykorzystała część oprogramowania inercyjnego układu odniesienia z Ariane 4, wcześniejszej europejskiej rakiety, w której oprogramowanie działało poprawnie. Jednak Ariane 5 miała inny profil lotu, jedna z wartości przekroczyła zakres oczekiwany przez oprogramowanie i rakieta została zniszczona niecałą minutę po starcie.

Wniosek jest prosty, ale łatwo o nim zapomnieć: zanim ponownie wykorzystasz elementy z wcześniejszych projektów, sprawdź, czy te same założenia i warunki pracy nadal obowiązują w nowym projekcie.

Najważniejsze wnioski

• Ponowne wykorzystanie sprawdzonych wymagań, oprogramowania, testów lub decyzji projektowych oszczędza czas, ale wcześniejszy kontekst musi zostać przeanalizowany.
• Przejrzyj ponownie wykorzystane przypadki testowe, zanim użyjesz ich do potwierdzenia tego samego wymagania w innym produkcie.
• Ogranicz ryzyko, utrzymując powiązania między wymaganiami, procedurami testowymi, dowodami i statusem.

Co wydarzyło się podczas startu Ariane 5

4 czerwca 1996 roku Ariane 5 odbyła swój pierwszy lot z Kourou w Gujanie Francuskiej, wynosząc cztery satelity badawcze Cluster dla Europejskiej Agencji Kosmicznej. Misja trwała mniej niż minutę. Około trzydziestu siedmiu sekund po starcie rakieta zeszła z zaplanowanej trajektorii i została zniszczona.

Problem pochodził z inercyjnego układu odniesienia, który przekazywał dane o orientacji i prędkości do komputera pokładowego rakiety. W Ariane 5 ponownie wykorzystano oprogramowanie z Ariane 4, w tym procedurę wyrównania, która pozostawała aktywna przez około 40 sekund po starcie. Ta procedura działała w Ariane 4, ale Ariane 5 miała inny profil lotu.

Z powodu tego odmiennego profilu w krótkim czasie wydarzyło się kilka rzeczy:

• Wartość prędkości poziomej stała się większa, niż oczekiwało oprogramowanie.
• Oprogramowanie próbowało przekonwertować tę wartość z 64-bitowej liczby zmiennoprzecinkowej na 16-bitową liczbę całkowitą ze znakiem, ale wartość nie mieściła się już w tym zakresie.
• Wystąpiło przepełnienie podczas konwersji, a inercyjny układ odniesienia potraktował to jako błąd i wyłączył się.
• System zapasowy uruchamiał to samo oprogramowanie i wyłączył się z tego samego powodu.
• Bez prawidłowych danych lotu komputer pokładowy użył zamiast nich danych diagnostycznych, wygenerował błędne komendy sterujące i rakieta została zniszczona.

To właśnie sprawia, że ten przypadek jest użyteczny z punktu widzenia zarządzania wymaganiami. Ponownie wykorzystane oprogramowanie działało wcześniej, ale zawierało założenie z wcześniejszej rakiety: że ta wartość pozostanie w bezpiecznym zakresie. Ariane 5 zmieniła kontekst tego założenia, dlatego należało je uwidocznić i ponownie sprawdzić w nowym systemie.

Ten przykład przypomina, że nawet ponownie wykorzystane prace inżynierskie nadal wymagają jednego prostego sprawdzenia: czy założenia, które za nimi stoją, nadal są prawdziwe w nowym systemie?

Czego zespoły sprzętowe mogą nauczyć się z przypadku Ariane 5

Większość zespołów sprzętowych nie buduje rakiet, ale stale ponownie wykorzystuje sprawdzone rozwiązania. Blok PCB z wcześniejszego produktu może zostać skopiowany do nowego projektu. Procedura firmware może zostać przeniesiona do nowej rewizji sprzętu. Procedura testowa może pozostać bez zmian mimo zmiany architektury zasilania. 

To normalna praca inżynierska. Ponowne wykorzystanie pomaga zespołom działać szybciej. Kluczowe jest upewnienie się, że wymaganie, założenie i weryfikacja nadal odpowiadają nowemu systemowi.

Przeglądaj ponownie wykorzystane wymagania

Wymagania, które sprawdziły się w jednym produkcie, nie należy automatycznie uznawać za prawidłowe w kolejnym. Te same sformułowania mogą nadal wyglądać poprawnie, ale warunki pracy wokół nich mogły się zmienić. Na przykład limit prądu, zakres temperatur lub ograniczenie interfejsu mogą być bezpieczne w jednym projekcie, a w innym wymagać przeglądu. Przed ponownym wykorzystaniem wymagania zespół powinien sprawdzić, czy nowy produkt nadal działa w ramach tych samych założeń.

Powiąż założenia z procedurami weryfikacji

Niektóre z najważniejszych założeń inżynierskich nigdy nie są zapisane jako formalne wymagania. Znajdują się w notatkach projektowych, starych planach testów albo w czyjejś pamięci. Może to stać się ryzykowne, gdy praca jest ponownie wykorzystywana. Jeśli założenie wpływa na decyzję projektową, zespół potrzebuje sposobu, aby powiązać je z kontrolą weryfikacyjną. W przeciwnym razie łatwo ponownie wykorzystać decyzję bez dostrzeżenia przyczyny, która pierwotnie czyniła ją bezpieczną.

Przeglądaj testy, gdy zmieniają się wymagania

Przypadek testowy, który zakończył się powodzeniem w poprzednim projekcie, nie zawsze potwierdza to samo w następnym. Jeśli wymaganie się zmienia albo zmienia się system wokół tego wymagania, powiązana procedura testowa również może wymagać zmiany. Jest to szczególnie ważne wtedy, gdy zespoły ponownie wykorzystują przypadki testowe, kryteria akceptacji lub dowody zgodności.

Jak pomaga powiązany workflow wymagań

Lepszy workflow wymagań nie traktuje wymagania jako samodzielnego wiersza tekstu. Utrzymuje wymaganie w powiązaniu z przyczyną, która za nim stoi, pracami projektowymi, na które wpływa, oraz działaniami weryfikacyjnymi pokazującymi, czy nadal jest ono prawidłowe. 

To ma największe znaczenie wtedy, gdy coś się zmienia. Ponownie wykorzystane wymaganie może nadal wyglądać poprawnie, ale założenie, które za nim stoi, może już nie pasować do nowego produktu. Test może nadal istnieć, ale może już nie sprawdzać właściwego warunku.

W powiązanym workflow zespoły mogą trzymać blisko siebie najważniejsze elementy: wymaganie, kontekst stojący za nim, metodę weryfikacji, procedurę, wynik, dowód i bieżący status. Zamiast przeszukiwać stare dokumenty lub raporty z testów, inżynierowie mogą zobaczyć, co jest ze sobą powiązane i co może wymagać ponownego przeglądu.

Altium Requirements Portal wspiera taki sposób pracy, utrzymując wymagania, identyfikowalność, odpowiedzialność i działania weryfikacyjne w jednym współdzielonym środowisku. Pomaga to zespołom z większą pewnością ponownie wykorzystywać sprawdzone rozwiązania, ponieważ wymaganie i związane z nim kontrole pozostają ze sobą połączone.

Czy stare założenia w Twoim projekcie nadal są prawdziwe?

Każdy zespół sprzętowy ponownie wykorzystuje sprawdzone rozwiązania. Nie jest to skrót, którego należy unikać, lecz praktyczny sposób szybszego tworzenia produktów i przenoszenia dobrych decyzji inżynierskich do kolejnych projektów. 

Użyteczne pytanie brzmi: co zmieniło się wokół tej ponownie wykorzystanej pracy?

• Czy zakres pracy się zmienił? 
• Czy test wymaga aktualizacji? 
• Czy założenia stojące za pierwotną decyzją nadal obowiązują?

Gdy zespoły potrafią odpowiedzieć na te pytania, łatwiej zaufać ponownemu wykorzystaniu. Wymaganie nie istnieje samodzielnie. Przyczyna, która za nim stoi, kontrola weryfikacyjna i dowody pozostają wystarczająco blisko, aby zespół mógł je przeanalizować, gdy zmienia się kontekst produktu. 

To lekcja, jaką Ariane 5 nadal daje dziś zespołom sprzętowym: ponowne wykorzystanie działa najlepiej wtedy, gdy kontekst, który za nim stoi, pozostaje powiązany.

Ułatw sprawdzanie i budowanie zaufania do decyzji o ponownym wykorzystaniu dzięki narzędziu do zarządzania wymaganiami, do którego ma dostęp cały Twój zespół.

Zacznij korzystać z Requirements Portal →

Często zadawane pytania

Czy ponowne wykorzystanie prac inżynierskich może stać się ryzykowne?

Ponowne wykorzystanie prac inżynierskich może stać się ryzykowne, gdy kontekst produktu się zmienia, ale pierwotne założenia, limity pracy lub kontrole weryfikacyjne nie są ponownie analizowane. Sama praca może nadal wyglądać poprawnie, ale warunki, które czyniły ją właściwą w poprzednim projekcie, mogą już nie obowiązywać.

Co inżynierowie powinni sprawdzić przed ponownym wykorzystaniem wymagania, testu lub decyzji projektowej?

Zespoły powinny sprawdzić, czy nowy produkt korzysta z tych samych warunków pracy, interfejsów, limitów i kryteriów akceptacji co pierwotny projekt. Powinny także potwierdzić, że powiązana metoda weryfikacji nadal sprawdza właściwą rzecz w nowym systemie.

Jak identyfikowalność pomaga, gdy wymagania są ponownie wykorzystywane?

Identyfikowalność pomaga zespołom zobaczyć, jak wymaganie łączy się z decyzjami projektowymi, założeniami, procedurami testowymi, dowodami i statusem. Gdy ponownie wykorzystana praca trafia do nowego projektu, te powiązania ułatwiają zrozumienie, co nadal jest prawidłowe, a co może wymagać przeglądu.