Autor: Maciej Gajdzica (Senior Software Developer)
Zachowanie najwyższego poziomu bezpieczeństwa systemu wiąże się ze znacznym wzrostem kosztów i wydłużeniem czasu developmentu. Jak balansować nakłady na systemy krytyczne – wyjaśnia Maciej, specjalista od oprogramowania, od którego zależy ludzkie życie.
Zachowanie najwyższego poziomu bezpieczeństwa systemu wiąże się ze znacznym wzrostem kosztów i wydłużeniem czasu developmentu. Z drugiej strony nie każdy system jest tak samo krytyczny, a nawet w ramach jednego systemu można wyróżnić kilka podsystemów o różnym poziomie wymaganego bezpieczeństwa. Na przykład w samochodzie awaria systemu hamulcowego będzie miała dużo poważniejsze konsekwencje niż awaria radia. Rozwijanie wszystkich podzespołów z zachowaniem tak samo rygorystycznych standardów byłoby nieefektywne i niepotrzebne.
Dlatego właśnie w systemach wbudowanych (embedded) typu safety-critical zdefiniowano poziomy bezpieczeństwa. Norma IE61508 opisująca zasady wytwarzania systemów elektronicznych związanych z bezpieczeństwem definiuje cztery poziomy SIL (Safety Integrity Level – po polsku Poziom Nienaruszalności Bezpieczeństwa).
Dla każdego poziomu zdefiniowane zostały dopuszczalne poziomy prawdopodobieństwa wystąpienia niebezpiecznego wypadku:
PFH (Probability of dangerous failure per hour) oznacza prawdopodobieństwo wystąpienia niebezpiecznego błędu na godzinę, a PFD (Probability of dangerous failure on demand) oznacza prawdopodobieństwo niebezpiecznego błędu przy pracy na żądanie.
Liczby te oznaczają, że dla poziomu SIL4 przy pracy ciągłej jeżeli mamy 1000 urządzeń, które działają przez 10 lat bez przerwy, dozwolone jest wystąpienie jednego niebezpiecznego błędu. I oczywiście nie każdy niebezpieczny błąd musi się kończyć wypadkiem.
Wytyczne z normy IEC61508 stały się podstawą dla innych norm regulujących różne gałęzie przemysłu. Mamy więc normę kolejową DO-178 definiującą poziomy DAL (Design Assurance Level):
Systemy bezpieczeństwa w samochodach mają różne poziomy ASIL (Automotive Safety Integrity Level), zdefiniowane w normie ISO 26262, gdzie ASIL A odpowiada SIL 1 z EIC 61508, a ASIL D odpowiada SIL 4. Poziomy bezpieczeństwa dla oprogramowania medycznego określa się nieco inaczej. Zostały one zdefiniowane w normie EN 62304:
Poziom bezpieczeństwa tworzonego przez nas systemu wyznaczamy po przeanalizowaniu wymagań związanych z bezpieczeństwem i dokonaniu analizy ryzyka. Jeżeli w ramach jednego systemu wydzielimy kilka podsystemów o różnych poziomach bezpieczeństwa, musimy udowodnić, że błąd występujący w komponencie o niższym poziomie bezpieczeństwa nie będzie miał negatywnego wpływu na komponent bardziej krytyczny.
Dlatego nie jest możliwe przydzielenie różnych poziomów bezpieczeństwa dwóm fragmentom programu wykonującym się na tym samym procesorze. W celu zapewnienia odpowiedniej separacji musimy stosować techniki wirtualizacji, a najlepiej przenosić mniej krytyczne moduły na inny procesor.
Jeśli szukasz ekspertów w dziedzinie systemów wbudowanych (embedded systems), chcesz rozwijać swoje oprogramowanie wbudowane, lub potrzebujesz wsparcia w przejściu produktu przez proces certyfikacji napisz do nas.
Dla jednego z naszych klientów zrealizowaliśmy oprogramowanie firmware spełniające wymagania poziomu nienaruszalności SIL4 i normy: ISO: ISO50128, ISO50159. -> Czytaj więcej!
