Nie każdy system jest tak samo krytyczny dla bezpieczeństwa. Nawet jeżeli wiele różnych systemów znajduje się na przykład w samolocie, nie oznacza to, że każdy z nich został wykonany wykorzystując tak samo rygorystyczne techniki. W końcu inaczej podejdziemy do tworzenia systemu sterowania lotem, a inaczej do systemu infotainment wyświetlającego pasażerom filmy podczas lotu. W tym artykule przyjrzymy się jakie poziomy bezpieczeństwa zostały zdefiniowane w różnych normach i czym się kierowano przy ich definiowaniu.
Kategoria: Programowanie
V-model – proces wytwarzania systemów safety-critical
Analiza błędnie działających systemów safety-critical takich jak Therac-25, czy Ariane-5, a także doświadczenie z wielu projektów zakończonych sukcesem doprowadziły do konkluzji, że same umiejętności inżynierów to za mało, aby zapewnić niezawodność systemów. W tym celu niezbędny jest odpowiedni proces wytwarzania oprogramowania. Takie procesy zostały opisane w normach regulujących wytwarzanie oprogramowania dla urządzeń medycznych, samolotów, pociągów, czy elektrowni atomowych. Większość z tych norm opiera się na tym samym procesie zwanym V-modelem. W tym artykule omówię jego założenia.
Ariane 5 – int overflow, który wysadził w powietrze rakietę
Dzisiaj opowieść o kolejnym znanym bugu, który miał ogromne konsekwencje. Podobnie jak w przypadku Therac-25, analiza katastrofy rakiety Ariane 5 przyczyniła się do poprawy procesów wytwarzania systemów safety-critical.
Therac-25, czyli błąd w sofcie medycznym powodujący śmierć pacjentów
W dzisiejszym wpisie omawiam najbardziej znany przypadek błędu systemu safety-critical z branży medycznej prowadzący do ciężkich obrażeń i śmierci pacjentów. Został on wnikliwie przeanalizowany teraz służy jako case study w różnego rodzaju materiałach o systemach safety.
Czy na pewno stać Cię na oszczędności w projekcie?
Ostatnio na portalu embedded.com zaczęła pojawiać się seria artykułów omawiających 10 najczęstszych problemów w projektach embedded napisana przez Jacka Gannsle. Pierwszym omówionym zagadnieniem były złudne oszczędności (link tutaj). Czytając artykuł zgadzałem się praktycznie z każdym słowem, bo sam obserwuję to samo praktycznie od początku kariery zawodowej. Z resztą nie jest to coś specyficznego tylko dla systemów embedded, czy branży IT, Krótkowzroczne podejście do oszczędności jest chyba ogólnoświatowym standardem i objawia się na wielu płaszczyznach. We wpisie postaram się rozwinąć tę myśl, chociaż będę się trzymał przykładów z IT.
Maksymalne wartości zmiennych – biblioteki limits.h i stdint.h
Ostatnio straciłem pół dnia poprawiając wiele pozornie nie powiązanych ze sobą błędy w unit testach. Dokonana przeze mnie zmianie polegała w uproszczeniu na zmianie w kilku miejscach typu zmiennej z uint16_t na int32_t. Jak nietrudno się domyślić, przyczyna wszystkich błędów była wspólna i wiązała się z konwersją signed/unsigned. Linijka, która powodowała błąd wyglądała mniej więcej tak:
uint16_t var = -1;
Code review – prosty sposób na poprawienie jakości kodu
O code review napisano już całkiem sporo. W internecie można znaleźć dokładne opisy jak powinny wyglądać, jakie dają efekty, czy ile kodu sprawdzać na raz. Dlatego nie będę dokładnie analizować tych aspektów. Zamiast tego krótko opiszę najważniejsze korzyści i kilka przydatnych technik na podstawie własnych doświadczeń. Z code review korzystałem już w wielu projektach i zawsze miało to pozytywny wpływ na jakość kodu. Moim zdaniem code review powinno być elementem każdego poważnego projektu.
C++ bez exceptionów
Korzystając z C++ na systemach embedded najczęściej wyłączamy obsługę exceptionów. W tym artykule wyjaśnię dlaczego tak robimy oraz jakie zagrożenia z tym się wiążą.
Przydatne toole do pracy z systemami embedded
Dobry zestaw narzędzi może niesamowicie poprawić naszą produktywność. Należę do osób lubiących automatyzację i wspomaganie się toolami przy developmencie. Szczególnie zrzucanie na toole żmudnych i ciężkich do wyegzekwowania czynności jak na przykład formatowanie kodu, czy wysyłanie komend na terminalu. W tym wpisie przedstawię kilka przydatnych narzędzi, głównie pod kątem embedded, C/C++ i STM32.
Architektura wieloprocesorowa w systemach safety
W systemach safety-critical zadania często rozłożone są na wiele procesorów. Wbrew pozorom przyczyną zwykle nie jest wydajność i potrzeba zapewnienia czasów odpowiedzi spełniających wymagania systemów hard real time. Zabieg ten jest stosowany w celu wydzielenia części krytycznej dla bezpieczeństwa i zabezpieczeniem jej przed niepożądanym wpływem mniej ważnych modułów.