Układy programowalne bezpieczeństwa charakteryzują się wieloma zaletami. Mniejsza ilość okablowania oraz elastyczność zastosowania wpływa na czas uruchomienia, ale jednocześnie kod programu bezpieczeństwa musi być prosty, aby ograniczyć powstawanie błędów systematycznych. Artykuł opisuje najważniejsze zasady programowania w aplikacjach bezpieczeństwa.

Układy programowalne bezpieczeństwa pojawiają się coraz częściej w układach sterowania maszyn. Część zalet ich zastosowania opisałem już w takich artykułach jak “Warunki funkcjonowania oprogramowania w aplikacjach bezpieczeństwa”, czy “System krytyczny pod względem bezpieczeństwa”. Oprogramowanie takie najczęściej funkcjonuje w sterownikach bezpieczeństwa, o których pisałem w artykule “Sterownik bezpieczeństwa- czym różni się od standardowego sterownika PLC”. Aby uzupełnić temat, należałoby co nieco wyjaśnić, czym charakteryzuje się program bezpieczeństwa, który może być przygotowany przez automatyka. W artykule postaram się pokrótce wyjaśnić, jakimi cechami charakteryzuje się aplikacja użytkownika przeznaczona do przygotowania programu bezpieczeństwa na układy programowalne bezpieczeństwa.

Wymagania dotyczące oprogramowania w sektorze maszynowym są opisane w normach PN-EN ISO 13849-1 i PN-EN 62061. Kilka cennych informacji na temat funkcji bezpieczeństwa realizowanych przez programowalne elektroniczne systemy sterowania można znaleźć również w ogólnej normie PN-EN 12100. W p. 6.2.11.7.3 znajduje się wymaganie, aby oprogramowanie, łącznie z wewnętrznym oprogramowaniem operacyjnym i oprogramowaniem użytkowym było tak zaprojektowane, aby były spełnione wymagania eksploatacyjne dotyczące funkcji bezpieczeństwa (opisane w IEC 61508-3).

Należy jednak pamiętać, że o ile norma IEC 61508-3 wprowadziła fundamentalną wiedzę dla warunków stosowania elektronicznych systemów programowalnych w aplikacjach bezpieczeństwa i dla sektora maszynowego jest ona ważną normą, to dotyczy ona głównie producentów programowalnych urządzeń bezpieczeństwa, takich jak sterowniki bezpieczeństwa. Od programisty sterowników PLC nie wymaga się wiedzy na temat wbudowanych systemów operacyjnych ani znajomości wewnętrznej architektury sprzętu, na którym pracuje. Dlatego języki o pełnej zmienności FVL nie są szczegółowo omawiane w normach PN-EN ISO 13849-1 i PN-EN 62061. W tych normach są opisywane warunki stosowania języków o ograniczonej zmienności LVL.

Wymagania normy IEC 61508-3 stosuje się do języków o pełnej zmienności (FVL). Natomiast oprogramowanie użytkowe oparte na językach o ograniczonej zmienności LVL (czyli oprogramowanie do zaprogramowania funkcji bezpieczeństwa z poziomu oprogramowania dostarczanego przez producenta programowalnego wyposażenia ochronnego) są ujęte w normach sektora maszynowego – PN-EN ISO 13849-1 i PN-EN 62061. Poniżej przedstawiono zależności pomiędzy ogólną normą bezpieczeństwa funkcjonalnego a wybranymi normami sektorowymi. Normy z poniższego diagramu dotyczą programowalnych systemów sterowania.

Jedną z najważniejszych norm z sektora maszynowego jest norma PN-EN ISO 12100, dotycząca ogólnych zasad projektowania. W normie tej można znaleźć również kilka informacji dotyczących programowalnych elementów systemu sterowania, związanych z bezpieczeństwem. Układy programowalne bezpieczeństwa muszą być obarczone pewnymi ograniczeniami, aby popełnianie błędów systematycznych (o których pisałem w artykule “Warunki funkcjonowania oprogramowania w aplikacjach bezpieczeństwa”) było tak dalece ograniczone, jak to tylko możliwe.

Norma PN-EN ISO 12100 zaleca, aby użytkownik nie miał możliwości wprowadzania zmian w zastosowanym oprogramowaniu poprzez zastosowanie oprogramowania wbudowanego w niereprogramowalną pamięć (np. mikrosterownik, zastosowanie określonego układu scalonego). Jeżeli wymagane jest programowanie przez użytkownika, dostęp do oprogramowania związanego z funkcją bezpieczeństwa powinien być ograniczony (np. za pomocą zabezpieczeń lub haseł dla osób upoważnionych).

Konstrukcja programowalnego elektronicznego systemu sterowania powinna być taka, aby było dostatecznie zapewnione małe prawdopodobieństwo powstania przypadkowych uszkodzeń sprzętowych, jak i powstania uszkodzeń systematycznych, które mogłyby ujemnie wpływać na spełnianie funkcji sterowania związanej z bezpieczeństwem.

Przyjęte standardy kodowania powinny uwzględniać dobrą praktykę programowania, zakazywać używania niebezpiecznych cech języka oraz określać procedury dokumentowania kodu źródłowego.  Zaleca się, aby język programowania był silnie stypizowany, umożliwiał tworzenie struktury blokowej oraz gwarantował kontrole typów zmiennych i zakresu tablic. Powinien uniemożliwiać stosowanie takich technik jak skoki bezwarunkowe, rekursja, wskaźniki, pamięć alokowana dynamicznie. Ponadto zalecane jest, aby kompilator oraz biblioteki programistyczne były certyfikowane lub posiadały status zwiększonego zaufania wskutek stosowania.[1]

Jedną z podstawowych dróg uzyskania niezawodnego oprogramowania jest dążenie do jego maksymalnego uproszczenia przy zachowaniu wymaganej funkcjonalności. Program powinien być przejrzysty i realizować tylko te funkcje, które są niezbędne do realizacji danego zadania [1].

Wyżej wymienione normy dotyczące bezpieczeństwa dzielą oprogramowanie na 2 rodzaje:

FVL – rodzaj języka, który daje możliwość implementowania dużej różnorodności funkcji i zastosowań. Przykładem oprogramowania FVL to język C, C++, Asembler. Typowym przykładem układów, w których stosuje się FVL, są układy wbudowane. W sektorze maszynowym FVL spotyka się w oprogramowaniu wbudowanym, wyjątkowo w oprogra­mowaniu aplikacyjnym.

LVL – rodzaj języka, który daje możliwość łączenia wcześniej zdefiniowanych funkcji bibliotecznych, ukierunkowanych na zastosowanie tak, aby implementowały specyfikacje wymagań bezpieczeństwa. Typowe przykłady LVL to schematy drabinkowe, schematy bloków funkcyjnych. Typowym przykładem systemu stosującego LVL jest sterownik PLC.

Projektanci funkcji bezpieczeństwa mają do dyspozycji oprogramowanie aplikacyjne, umożliwiające programowanie w językach LVL, które wg PN-EN ISO 13849-1 powinny mieć możliwość przetestowania poprzez symulację. Kod programu powinien być czytelny, zrozumiały i możliwy do testowania i dlatego powinno się używać zmiennych symbolicznych (zamiast bezpośrednich adresów sprzętowych). Wymagania dotyczące bezpieczeństwa oprogramowania dotyczą takich obszarów jak:

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

Program (napisany w języku LVL) dotyczący części sterowania odpowiedzialnej za bezpieczeństwo musi mieć możliwość potwierdzenia autentyczności programu przez autora, daty wgrania, wersji oraz ostatniego rodzaju dostępu. Ponadto istnieje szereg zasad dotyczących struktury takiego programu opisanych w załączniku J normy PN-EN ISO 13849-1.

Oprogramowanie powinno być uformowane w spójną i zrozumiałą strukturę ogólną, umożliwiającą łatwą lokalizację różnych typów przetwarzania. Wymaga to m.in. na:

• stosowaniu podziału programu na segmenty w celu zidentyfikowania głównych części odpowiadających „wejściom”, „przetwarzaniu” oraz „wyjściom”;
• stosowaniu w programie źródłowym komentarzy dotyczących każdego segmentu,
• stosowaniu opisów bloków funkcjonalnych;

Ponadto, aktywacja lub dezaktywacja zmiennych wyjściowych użytych w programie może odbywać się tylko raz, a każda zmienna globalna, wejściowa lub wyjściowa powinna posiadać jednoznaczną, mnemoniczną nazwę opisaną komentarzem w programie źródłowym.

Regułą i dobrą praktyką programowania jest stosowanie bloków funkcyjnych, które zostały zwalidowane przez dostawcę programowalnego elementu bezpieczeństwa. Programista musi wpierw upewnić się, że warunki funkcjonalne tych bloków odpowiadają warunkom funkcjonowania programu odpowiedzialnego za część sterowania związaną z bezpieczeństwem. Bloki te nie mogą modyfikować zmiennych globalnych. Blok funkcyjny musi wykryć niezgodności zmiennych, które ma przetwarzać i powinien udostępniać kod defektu (w postaci wyjściowej), aby można było zidentyfikować źródło defektu.

Kod bloku funkcyjnego powinien być ograniczony do minimum tak, aby parametryzacja bloku nie zawierała więcej niż 8 wejść cyfrowych i 2 całkowitoliczbowe oraz jedno wyjście. Wewnątrz bloku kod programu może zawierać maksymalnie 10 zmiennych lokalnych i maksymalnie 20 równań boolowskich.

Wszystkie wymagania dotyczące stosowania uproszczonej techniki programowania w aplikacjach bezpieczeństwa mają na celu zwiększenie niezawodności programu odpowiedzialnego za część sterowania związaną z bezpieczeństwem. Uproszczenia skutecznie zmniejszają występowanie błędów systematycznych, a stosowanie certyfikowanych funkcji bezpieczeństwa – oprócz wiarygodności – zwiększa czytelność programu. Stosowanie tych zasad pozwala na zwiększanie niezawodności systemów sterowania związanych z bezpieczeństwem już na etapie przygotowywania projektu, bowiem wszelkie błędy, które w początkowym etapie mogłyby powstać, mogłyby mieć wpływ na niezawodność oprogramowania, a tym samym na całościowe bezpieczeństwo.

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