Systemy safety-critical - wszystkie wpisy

W większości projektów, gdy mamy możliwość wykorzystania jakiegoś istniejącego rozwiązania, w ogóle się nie zastanawiamy. Dużo publicznego kodu znajdziemy na GitHubie, a w JavaScripcie wychodzi tyle nowych bibliotek, że są one nawet częścią pijackiej gry. Jak już pewnie się domyślacie – w systemach safety-critical sytuacja jest zgoła odmienna. Użycie zewnętrznego kodu podlega specjalnym procedurom i w normach nazywane jest właśnie tytułowym akronimem SOUP, czyli Software of Unknown Provenance, lub Software of Uncertain Pedigree. Nazwy te od razu zwracają uwagę na podstawowy problem tego softu – jego nieznane pochodzenie, historię i proces wytwarzania.

Co zalicza się do SOUP?

Każda norma oczywiście zawiera definicję co rozumie przez SOUP. Czasem używane są również inne nazwy, jak na przykład COTS (Commercial off the Shelf). W skrócie każdy kod, który nie był od początku wytworzony w ramach aktualnego projektu i z zachowaniem obowiązującego procesu wytwarzania oprogramowania jest uznawany za SOUP. Może to być więc:

  • Projekt open-source z internetu.
  • Oprogramowanie płatne.
  • Kod wzięty z innego projektu.
  • A nawet kod stworzony przez zewnętrzną firmę na nasze zamówienie.

Szczególnie ciekawy jest ostatni punkt. NASA ma swoje checklisty z wymaganiami stawianymi zewnętrznym kontraktorom. Źle widziana jest na przykład praca w dużych nadgodzinach. Czyli SpaceX na przykład by ich nie spełnił 😀 Jest to uzasadnione wcześniejszymi doświadczeniami NASA, po których doszli do wniosku, że koszt błędów popełnianych przez zmęczonych developerów – skutkujący na przykład niepowodzeniem misji kosztującej miliardy dolarów – jest większy niż korzyści z większej ilości mandaysów.

Nieraz jesteśmy tak przyzwyczajeni do używanych bibliotek, że w ogóle nie traktujemy ich jako zewnętrzny soft. Dobrym przykładem są tu biblioteki standardowe języka jak choćby C stdlib. To samo tyczy systemów operacyjnych, systemów plików, stosów TCP/IP, bibliotek kryptograficznych i wszelkiego innego kodu.

Typowe problemy

W przypadku takiego softu wziętego z zewnątrz zwykle musimy się mierzyć z:

  • Dokumentacją nie spełniającą wymagań norm.
  • Brakiem dostępu do kodu źródłowego (w przypadku płatnego softu w formie binarnej).
  • Niewystarczającym supportem.
  • Brakiem informacji o procesie wytwarzania np. jak tworzono architekturę, czy robiono testy, czy była statyczna analiza.
  • Integracją z resztą projektu.

Oczywiście skoro decydujemy się na użycie zewnętrznego softu, musimy zapewnić zgodność z wymaganiami stawianymi przez normę. Oznacza to, że musimy sami wykonać odpowiednie testy i stworzyć wymagane dokumenty. Support producentów softu może okazać się tutaj bardzo pomocny.  Często okazuje się wręcz, że wybranie wersji komercyjnej jest tańsze niż użycie darmowego softu i wzięcie całego ciężaru biurokratycznego na siebie.

Co brać pod uwagę przy wyborze SOUP?

Wiemy już, że decyzja o wykorzystaniu zewnętrznego kodu wcale nie musi być taka prosta. Niesie ona za sobą pewne konsekwencje i nakłada na nas nowe obowiązki. Dlatego wybór takiego softu musi być dokonany mądrze. Pomagają w tym różne dostępne w internecie guideline’y takie jak na przykład Software Safety Guidebook od NASA. Na co więc powinniśmy patrzeć?

Stabilność

Po pierwsze musimy ocenić, czy soft, którego chcemy użyć, jest stabilny. W tym celu musimy odpowiedzieć na pytania:

  • Jak często wychodzą nowe wersje?
  • Czy API jest stabilne?
  • Jak długo już projekt jest rozwijany?
  • Ile osób z niego korzysta?
  • Ile osób go rozwija?

Jeżeli biblioteka jest aktywnie, długo rozwijana i używana przez wiele osób, jej wiarygodność wzrasta.

Wymagania z norm

Kolejny zestaw pytań dotyczy wymagań stawianych przez normy. Tutaj musimy wziąć pod uwagę:

  • Jakość ogólnodostępnej dokumentacji.
  • Poziom wsparcia technicznego – szczególnie czy jest w stanie pomóc przy spełnianiu norm.
  • Czy mamy dostęp do kodu źródłowego.
  • Sposób testowania projektu.
  • Proces fixowania błędów.
  • Jak długo wspierane są starsze wersje?

Ostatni z tych punktów jest ważniejszy niż mogłoby się wydawać. W safety-critical zarządzanie wersjami również jest mocno sformalizowane i nie dodajemy od razu każdej aktualizacji. Wymagana jest głębsza analiza zmian i często decydujemy się pozostać przy jednej konkretnej wersji. Wtedy przyda się wsparcie do starszej wersji, tym bardziej, że projekt safety-critical może powstawać nawet kilka lat, a działać nawet i 20 lat.

Integracja

Następny zestaw pytań dotyczy łatwości integracji z naszym projektem.  Tutaj musimy się zastanowić nad kwestiami takimi jak:

  • Możliwość rozszerzania i modyfikacji softu.
  • Czy znalezione bugi dodajemy do kodu, czy zgłaszamy i czekamy na nową wersję z fixem?
  • Czy da się wyłączyć nieużywane funkcje?
  • Jak bardzo uzależniamy się od zewnętrznego softu? Czy jest to biblioteka dołączana do naszego kodu, czy framework odpalający nasz kod. Preferowana jest oczywiście opcja numer jeden.
  • Czy musimy dopisać jakieś brakujące funkcje?

Najlepiej, jeżeli nie musimy grzebać w wewnętrznej implementacji dodanego softu, tylko rozszerzać go o potrzebne dodatki. Powinniśmy odciąć go od reszty systemu za pomocą odpowiedniej warstwy abstrakcji zmniejszając do minimum bezpośrednie zależności.

Podsumowanie

Ograniczenia dotyczące wykorzystania istniejącego softu w safety-critical są dość restrykcyjne. Jednak na pewno nie można odmówić im sensu. Przynajmniej część z nich może być również wykorzystana w zwykłych projektach jako odpowiedź na hype driven development. Oczywiście bez tych wszystkich punktów wymuszanych przez normy.

 

Systemy safety-critical - Nawigacja