Jak dobrze musi być wykonany program, aby mógł być uznany za bezpieczny? Przez wiele lat inżynierowie z komitetów technicznych próbowali odpowiedzieć na to pytanie i powstało już kilka standardów, które ustanowiły warunki funkcjonowania oprogramowania w aplikacjach bezpieczeństwa.

Oprogramowanie jest na ogół skomplikowane, z tego też powodu liczba awarii spowodowanych błędami oprogramowania jest bardziej nieprzewidywalna i prawdopodobna, niż to ma miejsce w sytuacji sprzętowej. Było to główną przyczyną tak późnego wprowadzenia zasad stosowania programowalnych rozwiązań bezpieczeństwa w przemyśle maszynowym. Okazuje się bowiem, że ustanowienie zasad funkcjonowania oprogramowania w aplikacjach bezpieczeństwa nie jest takie proste i musiało minąć wiele lat badań, aby wyciągnąć wnioski i wyselekcjonować warunki użyteczności tych aplikacji.

Tzw. „niebieski ekran śmierci” jest znany chyba każdemu użytkownikowi komputerów. Przyczyną jego pojawiania się jest błąd oprogramowania, które nie jest kompatybilne z innym oprogramowaniem lub sprzętem. Badania wykazały, że proste oprogramowanie, do prostych funkcji zawiera około 25 błędów na 1000 linii kodu. Dobrze napisane oprogramowanie ma około 3 błędów na 1000 linii kodu, a oprogramowanie wykorzystywane w badaniach kosmicznych ma (według NASA) mniej niż jeden błąd na 10 000 linii kodu.

W praktyce oznacza to, że telefon komórkowy mający do 200 000 linii kodu, ma ok. 600 błędów oprogramowania (badania przeprowadzono dla starszych modeli telefonów komórkowych, a nie smartfonów). System operacyjny na PC ma ok. 27 milionów linii kodu, a więc do 50 000 błędów, a kosmiczny wahadłowiec może mieć do 300 błędów. Te błędy pozostają uśpione w produktach do momentu, gdy uaktywnienie się ich spowoduje powstanie szkody (zgodnie z prawem Murphy’ego). Dlatego programiści wykorzystujący program w aplikacjach bezpieczeństwa ponoszą wielką odpowiedzialność za prawidłowe funkcjonowanie aplikacji.

O ile tego typu błędy pojawiające się podczas użytkowania komputerów domowych są źródłem jedynie frustracji, to błędy pojawiające się w aplikacji bezpieczeństwa mogą stać się źródłem katastrofy. Jakie warunki funkcjonowania oprogramowania w aplikacjach bezpieczeństwa muszą być zatem spełnione, aby umożliwić programistom o różnym stopniu wtajemniczenia jego użytkowanie?

Jedną z istotnych zmian, jakie umożliwiły rozwój oprogramowania w aplikacjach bezpieczeństwa było wprowadzenie normy PN-EN ISO 13849-1, która w p. 4.6 podała warunki funkcjonowania oprogramowania dla wszystkich elementów systemu sterowania związanych z bezpieczeństwem w sektorze maszynowym. P. 4.6 dotyczy głównie do zastosowania przez programistów, którzy opracowują funkcje bezpieczeństwa dla maszyny w języku zorientowanym na aplikację w programowalnym sterowniku logicznym (PLC). Wymagania te nie są szczególnie nowe dla programistów oprogramowania wbudowanego, związanego z bezpieczeństwem. Oprogramowanie sprzętowe lub programowe do urządzeń elektronicznych elementów bezpieczeństwa, które jest na ogół certyfikowane, często podlega bardzo skomplikowanym wymaganiom podstawowej normy bezpieczeństwa EN / IEC 61508-3 (i pozostałych siedmiu części). Zbiór norm ISO 61508 dotyczy podstawowych wymagań regulujących zasady bezpieczeństwa funkcjonalnego (dla tzw. „procesówki”).

Norma PN-EN 61508 podaje ogólne wymagania bezpieczeństwa oprogramowania, które dotyczą również oprogramowania aplikacyjnego wg PN-EN ISO 13849-1.

Pierwszym wymaganiem jest wyszczególnienie warunków bezpieczeństwa oprogramowania, a w szczególności programowych funkcji bezpieczeństwa i nienaruszalności bezpieczeństwa oprogramowania.

Drugim wymaganiem jest wyszczególnienie warunków bezpieczeństwa dla każdego elektronicznego programowalnego systemu związanego z bezpieczeństwem, koniecznych do zaimplementowania wymaganych funkcji bezpieczeństwa.

Trzecim wymaganiem jest określenie warunków dotyczących nienaruszalności bezpieczeństwa dla każdego systemu związanego z bezpieczeństwem, koniecznych dla osiągnięcia poziomu nienaruszalności bezpieczeństwa dla każdej funkcji bezpieczeństwa.

Wg tych wymagań, wytwórca oprogramowania wbudowanego musi wykonać szereg badań, które pozwolą rozwiązać wszelkie niezgodności dotyczące przyporządkowania poziomu nienaruszalności bezpieczeństwa oprogramowania. Spełnienie tych wymagań będzie zaś możliwe, gdy zostaną rozpatrzone wszelkie powiązania między sprzętem i oprogramowaniem. Zapewnić to może „opis architektury” sprzętu, a w wymaganiach dotyczących bezpieczeństwa oprogramowania dla takiego sprzętu muszą być rozpatrzone następujące zagadnienia:

1. samomonitorowanie oprogramowania,
2. monitorowanie sprzętu elektroniki programowalnej, czujników i elementów wykonawczych,
3. testowanie okresowe funkcji bezpieczeństwa podczas działania systemu,
4. możliwość testowania funkcji bezpieczeństwa w czasie działania wyposażenia ochronnego.

Tego typu postanowienia mają na celu wspólne opracowanie koncepcji programu bezpieczeństwa, które ma współpracować z fizycznymi urządzeniami pochodzących od różnych producentów. Opracowując program bezpieczeństwa dla danej architektury połączeń, dla programu bezpieczeństwa nie jest istotne, jakie elementy zostaną podłączone w granicach stosowania tej architektury (to osobna kwestia, wykraczająca poza obszar dotyczący programu bezpieczeństwa). Ale jest istotne, aby zachowanie się tych elementów było zgodne z założeniami podanymi przez EN 61508-3. Wówczas możliwe staje się ustanowienie wspólnej płaszczyzny funkcjonowania rozwiązań programowalnych współpracujących z innymi elementami wchodzącymi w skład systemu sterowania odpowiedzialnego za bezpieczeństwo.

Warunki funkcjonowania oprogramowania w aplikacjach bezpieczeństwa były długo analizowane, zanim pojawiła się możliwość wprowadzenia ich w życie. Dzięki podstawowym wymaganiom możliwe stało się dopuszczenie do obrotu programowalnych sterowników bezpieczeństwa, które w połączeniu ze znanymi już komponentami wejściowymi (typu czujniki, blokady, kurtyny lub przyciski zatrzymania awaryjnego) i wyjściowymi (typu styczniki, przekaźniki, zawory, napędy) zapewniają działanie funkcji bezpieczeństwa. „Jakość” takiej funkcji zależy wówczas nie tylko od oprogramowania, lecz od innych cech, charakteryzujących użyte urządzenia bezpieczeństwa w celu zaprojektowania funkcji bezpieczeństwa. Taka „całość” ma wpływ na ogólny poziom zapewnienia bezpieczeństwa PLr, który można wyliczyć w dedykowanym do tego celu oprogramowaniu, np. SISTEMA. Ale oprogramowanie związane z bezpieczeństwem musi być na tyle sprawdzone, aby projektant funkcji bezpieczeństwa w przemyśle maszynowym mógł użyć programowalnego urządzenia bezpieczeństwa zgodnie z jego przeznaczeniem. Sposób użycia musi być zatem intuicyjny i tak opracowany, aby programista mógł w łatwy sposób zaprogramować funkcję bezpieczeństwa. Ewentualne błędy w architekturze połączeń lub w programie bezpieczeństwa powinny być natychmiast wykrywalne. Architektura połączeń wraz z logiką urządzenia programowalnego nie może przy tym pozostawiać jakichkolwiek wątpliwości w zastosowaniu w aplikacjach bezpieczeństwa i musi umożliwiać jednocześnie wykrywanie błędów funkcjonalnych (związanych z nieprawidłowym podłączeniem urządzeń odpowiedzialnych za bezpieczeństwo).

Właśnie wkraczamy w wyjaśnienie kwestii, dlaczego program bezpieczeństwa na poziomie aplikacji musi być jednocześnie funkcjonalny i prosty w użyciu.

Przeanalizujmy sobie taki oto kod w języku wysokiego poziomu C:

 

Drobny błąd literowy  (użycie zmiennej a zamiast b) powoduje, że przy spełnieniu warunku a<c<b zwracany rezultat będzie niepoprawny. W pozostałych sytuacjach błąd się nie uwidoczni, wskutek czego oprogramowanie pozornie będzie działać prawidłowo [1]. Cechą charakterystyczną oprogramowania jest to, że w odróżnieniu od elementów sprzętowych nie podlega ono awariom wynikającym z procesów starzenia lub zużycia [1]. Może natomiast zawierać błędy systematyczne, którego przykład podano powyżej. Błędy te mogą być ukryte przez znaczną część cyklu życia oprogramowania i ujawnić się w określonych sytuacjach, doprowadzając do awarii systemu. Czasami pojawienie się takiego błędu może nastąpić po wielu latach funkcjonowania oprogramowania.

Jest to głównym powodem stosowania uproszczonych języków programowania w aplikacjach bezpieczeństwa, gdzie błędy systematyczne zostały ograniczone. Można spotkać graficzne języki programowania, w których zasady programowania zostały szczegółowo opracowane przez producenta oprogramowania (Samos PLAN firmy Wieland, Flexi Soft Designer firmy SICK, PNOZmulti Configurator firmy PILZ). Języki typu LAD lub FBD mają postać uproszczonych instrukcji, a certyfikowane bloki funkcjonalne do obsługi takich funkcji bezpieczeństwa jak muting, sterowanie oburęczne czy zatrzymanie awaryjne są dostępne w postaci biblioteki gotowej do użycia.

Użycie programowalnych urządzeń bezpieczeństwa, których oprogramowanie jest zgodne z założeniami IEC 61508-3 nie zwalnia programisty od odpowiedzialności za popełnianie błędów aplikacyjnych. Stosowanie oprogramowania w aplikacjach bezpieczeństwa wymaga wiedzy na temat bezpieczeństwa w systemach sterowania. Nie wystarczy być wybitnym programistą PLC, aby móc przystąpić do pisania programów odpowiedzialnych za bezpieczeństwo. Trochę wiedzy na temat zasad bezpieczeństwa należy posiadać, aby integrację systemu automatyki z wykorzystaniem programowalnych układów bezpieczeństwa wykonać zgodnie z aktualnie obowiązującym stanem wiedzy techniki. Pamiętajmy o tym, że oprogramowanie bezpieczeństwa jest narzędziem w rękach programisty.

[1] „Podstawy Bezpieczeństwa Funkcjonalnego” pod red. T Kosmowskiego