Certyfikacja oprogramowania systemów przemysłowych

1. Certyfikacja oprogramowania systemów przemysłowych Andrzej KWIECIEŃ

2. Certyfikacja • Badanie zgodności z podanym wzorcem • Uzgodnienia normatywne prowadzą do wzorca jakim jest norma • Po co w ogóle normalizować? • Kto jest odpowiedzialny za powstawanie norm?

3. Normalizować? • Po co w ogóle normalizować oprogramowanie? • Normalizować sposoby tworzenia algorytmów? • Normalizować stosowalność narzędzi? • Stosować znormalizowane narzędzia? • Czy na fakt normalizacji ma wpłynąć rodzaj i przeznaczenie oprogramowania?

4. Czy testowanie nie wystarczy? • Czy sposoby testowania też powinny być znormalizowane? • Istnieją instrukcje testowania oprogramowania? • Są to najczęściej zalecenia i opracowania konkretnych producentów oprogramowania! • Ale są też dokumenty normatywne testowania oprogramowania! • To oznacza, że są dokumenty zwane normami!

5. Daj przykład • „Urządzenie pomiarowe-walka o dokładność” • „Identyczny algorytm, dwa kompilatory, dwa różne wyniki”- czy programiście potrzebny jest kalkulator?

6. Wniosek • Musimy coraz szybciej produkować oprogramowanie-musimy korzystać z coraz to wydajniejszych narzędzi-ale jaką mamy gwarancję, że są to dobre narzędzia? • To może jednak korzystać z narzędzi znormalizowanych? • Co to znaczy?

7. Inny przykład • Oprogramowanie analizatora gazów toksycznych i wybuchowych do celów badawczych w laboratorium studenckim • Oprogramowanie analizatora gazów toksycznych i wybuchowych do celów ostrzegania i sterowania systemami zasilania energetycznego

8. Jeszcze jeden przykład • System intensywnego nadzoru medycznego • Analiza gazowa chorego, • Gwarantowany czas powiadamiania i alarmowania Czy Tobie chodzi o bezpieczeństwo? TAK!

9. Chyba jednak należy software normalizować? Czy tak?A precyzyjniej?SPRAWSDZIĆ CZY OPROGRAMOWANIE ZOSTAŁO WYKONANE ZGODNIE Z ZALECENIAMI (Normą). Innymi słowy należy porównać etapy jego tworzenia z zalecanym wzorcem tworzenia.

10. Co to jest CENELEC • Europejski Komitet Normalizacyjny Elektrotechniki Bruksela • European Committee for Electrotechnical Standarization Brussels • ComiteEuropeendeNormalisation ELECtrotechnique Brussels

11. Opisuje wszystkie fazy cykli życia bezpieczeństwa Umożliwia innym sektorom (np.pneumatyka) tworzenie podobnych norm Udostępnia metodę opracowania specyfikacji wymagań bezpieczeństwa Stosuje i wyznacza poziomy nienaruszalności bezpieczeństwa Wprowadza podejście opierające się na analizie ryzyka Ustala docelowe miary liczbowe uszkodzeń systemów związanych z bezpieczeństwem Ustala dolną granicę docelowej miary uszkodzeń w przypadku uszkodzeń niebezpiecznych np. średnie prawdopodobieństwo niewykonania zaprojektowanej funkcji systemu równe 10-5/h, TEMAT:Bezpieczeństwo funkcjonalne systemów E/E/PE -nas interesuje tak naprawdę tylko PE

12. Cykl życia bezpieczeństwa oprogramowania Specyfikacja wymagań bezpieczeństwa oprogr Specyfikacja wymagań funkcji bezpieczeństwa Specyfikacja wymagań nienaruszalności bezp. Planowanie walidacji bezpieczeństwa oprogramowania Projekt i opracowanie oprogramowania Procedury pracy i modyfikacji oprogramowania Integracja PE Walidacja bezpieczeństwa oprogramowania Do normy IEC 61508-1 Do normy IEC 61508-1

13. Nienaruszalność bezpieczeństwa oprogramowania i cykl życia wytwarzania Oprogramowanie po walidacji Walidacja Specyfikacja wymagań bezp. oprogramowania Specyfikacja wymagań bezp. E/E/PES Testowanie walidacyjne Testowanie integracyjne E/P Architektura E/E/EPS Architektura oprogramowania Projekt systemu oprogramowania Testowanie integracyjne Testowanie modułu Projekt modułu Wyjście Kodowanie Walidacja

14. Przykład normy„Urządzenia elektryczne do wykrywania i pomiaru gazów palnych, gazów toksycznych oraz tlenu-Wymagania i badania dotyczące urządzeń wykorzystujących oprogramowanie i/lub techniki cyfrowe”. PN-EN 50271 Treść normy opracowano przez zespół normalizacyjny S.C. 31-9 Komitetu Technicznego CENELEC TC 31 i została zatwierdzona przez CENELEC jako EN 50271 w dniu 01.05.2001r 01.04.2004-ostateczny termin wycofania sprzecznych norm krajowych

15. Zakres normy • Prezentacja wymagań i zakresu badań dotyczących urządzeń do wykrywania i pomiarów gazów palnych, toksycznych i tlenu • W zastosowaniach przemysłowych zakres dotyczy również urządzeń stosowanych w przestrzeniach zagrożonych wybuchem • Stanowi uzupełnienie szeregu innych norm dotyczacych wykrywania i pomiarów gazów palnych i par, gazów toksycznych lub tlenu.

16. Definicje • Jednostka cyfrowa-część urządzenia do cyfrowego przetwarzania danych- moduły A/D i D/A są elementami JC • Stan specjalny- inne stany urządzenia niż kontrola koncentracji gazu, tryb kalibracji lub stan awaryjny • Oprogramowanie- „twór umysłowy obejmujący programy, procedury, reguły i dokumentację towarzyszącą odnoszącą się do pracy jednostki cyfrowej” • Oprogramowanie związane z bezpieczeństwem-oprogramowanie używane do wprowadzania funkcji bezpieczeństwa • Parametry-ustawienia producenta lub użytkownika, które mają wpływ na działanie oprogramowania

17. Zasady projektowania • Interfejs analogowo-cyfrowy • Pełne pokrycie zakresu wejść • Przekroczenie zakresu przetwarzania jednoznacznie sygnalizowane • Próbkowanie A/D i D/A odpowiadające żądanej dokładności odwzorowania danych • Błędy numeryczne • Błędy cyfrowego przetwarzania mniejsze niż najmniejsza odchyłka wskazania wymagana przez właściwą normę europejską • JC musi automatycznie kontrolować dozwolony zakres we., wy., i wewnętrzny danych oraz obsługiwać przekroczenia zakresu • Obowiazuje zasada „najgorszego przypadku”

18. Zasady projektowania • Proces pomiarowy • Podczas procesu pomiarowego maksymalny, całkowity czas 4 następujących po sobie aktualizacji wartości wyjściowej nie powinien przekroczyć czasu odpowiedzi lub czasu do alarmu (urządzenia tylko alarmujące) • Sygnalizacja stanu specjalnego • Konieczność sygnalizacji lokalnej jak i na wyjściach przeznaczonych do zdalnej transmisji • Sygnalizacja cyfrowa • Identyfikacja sygnałów • Priorytety sygnalizacji-wyświetlany stan o najw. priorytecie • Przegląd sygnałów, które aktualnie nie są pokazane lub aktywowane

19. Zasady projektowania • Odczyt cyfrowy • Jednoznaczność wyświetlanych jednostek miary wskazanych wartości zmierzonych • Wyraźna sygnalizacja wszystkich pomiarów powyżej i poniżej zakresu pomiarowego

20. Zasady projektowania • Oprogramowanie • Możliwe rozpoznanie wersji oprogramowania (wyświetlacz)podczas załączania urządzenia lub po jego restarcie lub na życzenie użytkownika • Brak możliwości zmiany zaprojektowanych funkcji oprogramowania • Kontrola prawidłowości ustawień parametrów • Bariera dostępu do zmian parametrów przez osoby niepowołane (blokada mechaniczna lub programowe kody dostępu) • Ustawienia powinny być zabezpieczone nawet w przypadku wyłączenia urządzenia i podczas trwania stanu specjalnego • Lista parametrów podlegających zmianom przez użytkownika oraz ich zakresy muszą być wymienione w instrukcji obsługi • Strukturalna i modułowa konstrukcja-łatwiejsze jego sprawdzenie i konserwację • Jasno zdefiniowany interfejs we wszystkich modułach do innych modułów

21. Zasady projektowania • Oprogramowanie • Dokumentacja (w pliku technicznym) winna zawierać: • Nazwę urządzenia, do którego należy oprogramowanie • Jednoznaczna identyfikację wersji programu • Typ i wersję oprogramowania użytych narzędzi • Kod źródłowy modułów zabezpieczających oprogramowania • Opis funkcji • Strukturę oprogramowania (schemat działania programu, wykres Nassi-Schneidermana) • Protokoły atestacyjne oprogramowania • Każdą zmianę oprogramowania wraz z datą zmiany i nowymi danymi identyfikacyjnymi. Uwaga! Dokumentacja jest przeznaczona jedynie do użytku laboratorium badawczego. Wszystkie informacje są poufne i należą do producenta.

22. Zasady projektowania • Sprzęt • Podzespoły powinny być sprawdzane przez oddzielne badania • Uniemożliwienie wprowadzania zmian do kodu oprogramowania w każdych warunkach pracy. Modernizacje kodu powinny odbywać się pod kontrolą wytwórcy • Konieczność stosowania jednostek pamięci, w których zawartość danych pozostaje stała kiedy zaniknie zasilanie. Jeżeli użyto baterii należy w instrukcji podać czas jej życia. • Transmisja danych • Niezawodność • Opóźnienia (wynik błędów transmisji) muszą być mniejsze od czasu odpowiedzi lub1/3 czasu włączenia alarmu. Jeżeli nie, to urządzenie powinno przejść w określony stan specjalny (udokumentowany w instrukcji obsługi)

23. Zasady projektowania • Badania wyrobu • Zasilanie JC co okres równy 10xczas odpowiedzi • Automatyczne (po załączeniu lub na życzenie użytkownika) testowanie wszystkich dostępnych widocznych i słyszalnych funkcji wyjściowych • Sprzęt kontrolujący wraz z jego bazą czasową (np. programem alarmowym) powinien pracować niezależnie i odrębnie od jednostki cyfrowej • Program i pamięć parametryczna powinny być kontrolowane przez producentów, którzy dopuszczają wykrywanie pojedynczych bitów błędów • Pamięć nietrwała powinna być kontrolowana przez producentów poprzez badanie zdolności odczytywania i zapisywania komórek pamięci Po wykryciu awarii urządzenie powinno przejść w określony stan specjalny

24. Dziękuję