Systemy safety-critical - wszystkie wpisy

Zwykle przyjmujemy, że koszt wytworzenia systemu safety-critical spełniającego wymagane normy jest dziesięciokrotnie wyższy, niż zwykły projekt posiadający te same wymagania funkcjonalne. Po przeczytaniu poprzednich części serii powinniście mieć całkiem dobre wyobrażenie skąd biorą się dodatkowe koszty. W tym artykule omówię koszty developmentu, zewnętrznego kodu i narzędzi.

Wykorzystane dane

Do analizy wykorzystam dokument “Cerification Cost Estimates for Future Communication Radio Platforms” wydany przez organizację EUROCONTROL analizujący koszty systemów dla lotnictwa spełniających normy DO-178B dla software’u i DO-254 dla hardware’u. Poziomy bezpieczeństwa DAL (Development Assurance Level) są następujące:

Poziom bezpieczeństwaOpis
Level AUtrata życia pasażerów, zniszczenie samolotu
Level BDuży negatywny wpływ na bezpieczeństwo i osiągi samolotu, możliwe poważne obrażenia pasażerów
Level CZnaczne zmniejszenie marginesu bezpieczeństwa pilotów, możliwe lekkie obrażenia pasażerów
Level DNiewielkie zmniejszenie marginesu bezpieczeństwa pilotów, możliwe niedogodności pasażerów i wydłużenie lotu.
Level EBrak negatywnych skutków

O poziomach bezpieczeństwa więcej można przeczytać w jednej z wcześniejszych części cyklu:

SLOC/h – Ilość linii kodu na godzinę

Ilość kodu produkcyjnego w przeliczeniu na godzinę pracy developera dla poszczególnych poziomów DAL przedstawia wykres:


W pierwszym odruchu możecie sobie pomyśleć, że to jakieś brednie. Jaki doświadczony developer pisałby 12 linii kodu na godzinę? Musicie jednak pamiętać, że wartość SLOC/h (software lines of code per hour) jest obliczana jako ilość ostatecznego kodu produkcyjnego (bez pustych linii i komentarzy) podzielona przez ilość osobogodzin wszystkich osób pracujących nad projektem. Uwzględnia więc ona nie tylko samo pisanie kodu, ale również projektowanie, dokumentację, prototypy, testy, refactoring, meetingi, zarządzanie, certyfikację i wszystkie inne aktywności wykonywane w czasie projektu.

W temacie SLOC trafiłem również w sieci na ciekawe porównanie, które działa na wyobraźnię. Koszt wytworzenia pojedynczej linii kodu produkcyjnego zawiera się w przedziale 10$-45$. Oznacza to, że już 1000 linii kodu może być wartych tyle samo co kilogram złota.

Skąd biorą się różnice między poziomami bezpieczeństwa?

W dokumencie znajdziemy również odpowiedź skąd biorą się różnice między poszczególnymi poziomami DAL. Zostały one przedstawione na kolejnym wykresie:

Dołączono również tabelę opisującą dodatkowe kroki wymagane na poszczególnych poziomach:

Jak widać najwięcej dodatkowej pracy związanej z zapewnieniem wymaganego poziomu DAL dotyczy weryfikacji. Nie oznacza to oczywiście jedynie testowania gotowego rozwiązania. O niektórych zadaniach weryfikacyjnych trzeba pomyśleć już na samym początku projektu. Dobrym przykładem jest tutaj Traceability, czyli możliwość prześledzenia rozwoju funkcjonalności od wymagań przez rozwiązania architektoniczne po implementację i testy.

Gdzie ponosimy koszty?

Koszt możemy ponosić na dwa sposoby:

  • Czas potrzebny na stworzenie własnego rozwiązania.
  • Kupienie gotowego softu i narzędzi.

Wbrew pozorom druga opcja jest często tańsza mimo, że ceny wydają się kosmiczne. Potwierdzenie możemy znaleźć również w dokumencie. Jest tam tabela z wyliczeniem ilości osobodni potrzebnych do realizacji przykładowego projektu spełniając poszczególne poziomy DAL (Table 9, strona 59-60). Aby spełnić najwyższy poziom DAL A potrzeba około 46000 mandayów. Z tego 42000 zajmują 2 komponenty – Stos IPv6 i ORB (Object Request Broker). Korzystając z gotowych rozwiązań jesteśmy więc w stanie zaoszczędzić teoretycznie 90% czasu projektu!

Poza softem możemy również kupić narzędzia automatyzujące pracę. Ułatwiają one zachowanie procesu wytwarzania oprogramowania wymaganego przez normę. Toole tego typu to najczęściej prawdziwe kombajny zawierające ogromną ilość opcji i mające równie ogromną cenę.

Podejmując decyzję o wyborze takiego narzędzia staramy się porównać jego cenę z kosztem robienia wszystkiego ręcznie. Najczęściej takie kalkulacje mocno mijają się z rzeczywistością. Mamy tendencję do robienia zbyt optymistycznych założeń i szacujemy zbyt mały koszt pracy. Najczęstszą przyczyną nietrafionych estymat jest zakładanie, że raz wykonanych czynności nie będziemy musieli powtarzać. Niestety zmiany w projekcie, czy wydawanie nowych wersji wymusza na nas kolejne przejścia cyklu. Napisanie własnych narzędzi albo robienie wszystkiego za każdym razem ręcznie na dłuższą metę bardzo często się nie opłaca. Poza tym dostajemy support, a zaoszczędzony czas możemy przeznaczyć na inne aktywności.




Podobał się artykuł? Zapisz się na newsletter

Zapisz się, aby otrzymywać informacje o nowościach na blogu,
ciekawe materiały oraz informacje marketingowe. W prezencie otrzymasz również
dokument “Jak zwiększyć jakość kodu w projektach embedded? – darmowe narzędzia”.


Systemy safety-critical - Nawigacja << SOUP – Wykorzystanie zewnętrznego softu w safety-critical