certyfikacja oprogramowania system w przemys owych n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Certyfikacja oprogramowania systemów przemysłowych PowerPoint Presentation
Download Presentation
Certyfikacja oprogramowania systemów przemysłowych

Loading in 2 Seconds...

play fullscreen
1 / 38

Certyfikacja oprogramowania systemów przemysłowych - PowerPoint PPT Presentation


  • 122 Views
  • Uploaded on

Certyfikacja oprogramowania systemów przemysłowych. Andrzej KWIECIEŃ. 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?. Normalizować?.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Certyfikacja oprogramowania systemów przemysłowych' - myrrh


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
certyfikacja
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?
normalizowa
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?
czy testowanie nie wystarczy
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!
daj przyk ad
Daj przykład
  • „Urządzenie pomiarowe-walka o dokładność”
  • „Identyczny algorytm, dwa kompilatory, dwa różne wyniki”- czy programiście potrzebny jest kalkulator?
wniosek
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?
inny przyk ad
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
jeszcze jeden przyk ad
Jeszcze jeden przykład
  • System intensywnego nadzoru medycznego
    • Analiza gazowa chorego,
    • Gwarantowany czas powiadamiania i alarmowania

Czy Tobie chodzi o bezpieczeństwo?

TAK!

slide9

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.

co to jest cenelec
Co to jest CENELEC
  • Europejski Komitet Normalizacyjny Elektrotechniki Bruksela
  • European Committee for Electrotechnical Standarization Brussels
  • ComiteEuropeendeNormalisation ELECtrotechnique Brussels
temat bezpiecze stwo funkcjonalne system w e e pe nas interesuje tak naprawd tylko pe
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
cykl ycia bezpiecze stwa oprogramowania
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

nienaruszalno bezpiecze stwa oprogramowania i cykl ycia wytwarzania
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

wymagania dotycz ce cyklu ycia oprogramowania
WYMAGANIA DOTYCZĄCE CYKLU ŻYCIA OPROGRAMOWANIA

Cyklem życia oprogramowania nazywamy przedział czasuod momentu rozpoczęcia fazy opracowania jego koncepcji, aż do chwili zakończenia jego używania. Cykl życia oprogramowania zwykle obejmuje:

·       fazę sformułowania wymagań,

·       fazę opracowania,

·       fazę sprawdzania,

·       fazę integracji,

·       fazę zainstalowania,

·       fazę modyfikacji.

specyfikacja wymaga bezpiecze stwa oprogramowania
SPECYFIKACJA WYMAGAŃ BEZPIECZEŃSTWA OPROGRAMOWANIA

Specyfikacja wymagań bezpieczeństwa powinna zawierać wszystkie wymagania dotyczące funkcji bezpieczeństwa, które powinny wypełniać systemy związane z bezpieczeństwem. Zwykle tę specyfikację dzieli się na:

  • specyfikację wymagań dotyczących funkcjibezpieczeństwa,
  • specyfikację wymagań dotyczących nienaruszalności bezpieczeństwa, która zawiera te wymagania nienaruszalności bezpieczeństwa funkcji bezpieczeństwa, które powinny wypełnić systemy z bezpieczeństwem związane
specyfikacja wymaga bezpiecze stwa oprogramowania1
SPECYFIKACJA WYMAGAŃ BEZPIECZEŃSTWA OPROGRAMOWANIA

Cele specyfikacji wymagań bezpieczeństwa oprogramowania:

  • wyszczególnienie wymagań dotyczących oprogramowaniabezpiecznego, w kategoriach wymagań dotyczących programowych funkcji bezpieczeństwa nienaruszalności bezpieczeństwa oprogramowania,
  • wyszczególnienie wymagań dotyczących programowych funkcji bezpieczeństwa dla każdego systemu PES związanego z bezpieczeństwem, koniecznych do zaimplementowania wymaganych funkcji bezpieczeństwa,
  • wyszczególnienie wymagań dotyczących nienaruszalności bezpieczeństwa oprogramowania dla każdego systemu EPS związanego z bezpieczeństwem, niezbędnych do osiągnięcia poziomu nienaruszalności bezpieczeństwa
specyfikacja wymaga bezpiecze stwa oprogramowania2
SPECYFIKACJA WYMAGAŃ BEZPIECZEŃSTWA OPROGRAMOWANIA

Specyfikacja wymagań bezpieczeństwa oprogramowania dotyczy wyrobu a nie projektu. Należy zatem zadbać, aby w zbiorze funkcji bezpieczeństwa znalazły się takie jak:

  • funkcje umożliwiające osiągnięcie stanu bezpiecznego obiektu lub jego utrzymanie,
  • funkcje związane z wykrywaniem, informowaniem i zarządzaniem defektami w programowalnej elektronicesprzętu,
  • funkcje związane z wykrywaniem, informowaniem i zarządzaniem defektami w czujnikach i elementachwykonawczych,
specyfikacja wymaga bezpiecze stwa oprogramowania3
SPECYFIKACJA WYMAGAŃ BEZPIECZEŃSTWA OPROGRAMOWANIA
  • funkcje związane z wykrywaniem, informowaniem i zarządzaniem defektami w czujnikach i elementachwykonawczych,
  • funkcje związane z wykrywaniem, informowaniem i zarządzaniem defektami w samym oprogramowaniu (tak zwane funkcje „samo monitorowania” oprogramowania,
  • funkcje związane z okresowym testowaniem funkcji bezpieczeństwa w trybie „on-line”,
  • funkcje związane z okresowym testowaniem funkcji bezpieczeństwa w trybie „off-line”,
  • funkcje pozwalające na bezpieczne modyfikowanie PES.
wymagania dotycz ce narz dzi wspomagaj cych i j zyk w programowania
WYMAGANIA DOTYCZĄCE NARZĘDZI WSPOMAGAJĄCYCH I JĘZYKÓW PROGRAMOWANIA

Wybór narzędzi wspomagających zależy zazwyczaj od natury czynności produkcji oprogramowania i od jego architektury.

  • Język o ograniczonej zmienności, przy niskim poziomie nienaruszalności bezpieczeństwa.

Wymagane narzędzia i języki programowania, ograniczone do języków standardowych edytorów i programów ładujących PLC (ang. Programmable Logic Controller – sterownik przemysłowy swobodnie programowalny). Odpowiedzialność za zgodność z wymaganiami będzie głównie spoczywać na dostawcy oprogramowania.

wymagania dotycz ce narz dzi wspomagaj cych i j zyk w programowania1
WYMAGANIA DOTYCZĄCE NARZĘDZI WSPOMAGAJĄCYCH I JĘZYKÓW PROGRAMOWANIA
  • Wyższe poziomy nienaruszalności bezpieczeństwa.

Może być konieczny ograniczony podzbiór języka PLC oraz potrzebne narzędzia do weryfikacji i walidacji, takie jak analizatory kodu i symulatory. W tych okolicznościach odpowiedzialność będzie spoczywać tak na dostawcy, jak i na użytkowniku.

wymagania dotycz ce narz dzi wspomagaj cych i j zyk w programowania2
WYMAGANIA DOTYCZĄCE NARZĘDZI WSPOMAGAJĄCYCH I JĘZYKÓW PROGRAMOWANIA
  • Narzędzia do zastosowań wbudowanych (ang. Embedded Systems), stosujące języki o pełnej zmienności.

Narzędzia te z konieczności są bardziej wszechstronne, nawet przy niskich poziomach nienaruszalności bezpieczeństwa. Odpowiedzialność za zgodność z wymaganiami, będzie spoczywać głównie na wytwórcy oprogramowania. Obejmuje to także dostawcę PLC, który będzie używać języka o pełnej zmienności przy dostarczeniu języka o ograniczonej zmienności do programowania aplikacji użytkownika.

wyb r j zyka programowania
WYBÓR JĘZYKA PROGRAMOWANIA
  • Wybór języka a wymagany poziom nienaruszalności bezpieczeństwa,
  • Powinien być kompletny i jednoznacznie zdefiniowany,
  • Może być ograniczony do cech, które są jednoznacznie zdefiniowane,
  • Dopasowany do charakterystyk zastosowania,
  • Musi mieć właściwości wykrywania błędów.
  • Kompilator języka powinien mieć:
    • Certyfikat zgodności z uznaną normą albo udokumentowaną analizę przydatności
  • Jeżeli wymagania, o których wspomniano nie mogą być spełnione, to podczas opisywania projektu architektury oprogramowania należy udokumentować uzasadnienie użycia języka alternatywnego. W owym uzasadnieniu należy przedstawić szczegółowo dopasowanie tego alternatywnego języka, do wypełnienia przewidzianego celu orazwszelkie dodatkowe sposoby rozwiązywania jakichkolwiek zidentyfikowanych słabych stron tego języka.
wyb r j zyka programowania1
WYBÓR JĘZYKA PROGRAMOWANIA

Jeżeli wymagania, o których wspomniano nie mogą być spełnione, to podczas opisywania projektu architektury oprogramowania należy udokumentować uzasadnienie użycia języka alternatywnego. W owym uzasadnieniu należy przedstawić szczegółowo dopasowanie tego alternatywnego języka, do wypełnienia przewidzianego celu oraz wszelkie dodatkowe sposoby rozwiązywania jakichkolwiek zidentyfikowanych słabych stron tego języka.

slide26

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

zakres normy
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.
definicje
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
zasady projektowania
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”
zasady projektowania1
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
zasady projektowania2
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
zasady projektowania3
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 konserwacja
    • Jasno zdefiniowany interfejs we wszystkich modułach do innych modułów
zasady projektowania4
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.

zasady projektowania5
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)
zasady projektowania6
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