7 gaśnice przenośne 1 podział



Pobieranie 1.36 Mb.
Strona14/26
Data10.05.2016
Rozmiar1.36 Mb.
1   ...   10   11   12   13   14   15   16   17   ...   26

Dokumentacja oprogramowania

  1. Dokumentacja powinna umożliwiać zapoznanie się z budową oprogramowania. Dokumentacja ta powinna być wystarczająco szczegółowa w celu sprawdzenia zgodności konstrukcji z niniejszymi wymaganiami.


Powinna zawierać, co najmniej:

a) opis funkcjonalny przebiegu głównego programu, zawierający:



  • zwięzły opis każdego modułu i wykonywanego przez niego zadania;

  • opis współpracy modułów;

  • opis sposobu wywoływania modułów, włącznie ze sposobem obsługi przerwań;

  • ogólną hierarchię programu.

W opisie powinny być użyte formy graficzne do prezentowania budowy programu i przepływu danych, lub równoważna jednoznaczna metoda dokumentowania oprogramowania.

b) opis, które obszary pamięci i do jakich celów są używane (np. program, dane dotyczące konkretnego obiektu i zmienne chwilowe);



c) opis współpracy oprogramowania ze sprzętem w CDSO.
          1. Szczegółowa dokumentacja oprogramowania powinna zawierać co najmniej:


a) opis każdego modułu programu, zawierający:

  • nazwę modułu,

  • identyfikację wytwórcy,

  • datę i/lub nr wersji,

  • opis wykonywanych zadań,

  • opis interfejsów, zawierający rodzaj przekazywanych danych, zakres ważności danych i sprawdzanie ważności danych,

b) wykaz kodów źródłowych, zawierający wszystkie ogólne i lokalne zmienne, stosowane stałe i etykiety oraz wystarczający komentarz, umożliwiający poznanie przebiegu programu;

  1. szczegóły wszelkich narzędzi programowych wykorzystanych do przygotowania programu (np. narzędzia projektowe wysokiego poziomu, kompilatory, assemblery).



        1. Budowa oprogramowania


W celu zapewnienia niezawodności CDSO powinny być spełnione następujące wymagania, dotyczące budowy oprogramowania:

  1. oprogramowanie powinno mieć strukturę modułową;

  2. budowa interfejsu dla danych generowanych ręcznie i automatycznie nie powinna

pozwalać na pojawianie się błędów w realizacji programu;

  1. program powinien zapobiegać blokowaniu się systemu.



        1. Kontrola realizacji programu

          1. Realizacja programu przez mikroprocesor powinna być nadzorowana przy pomocy wewnętrznych procedur samotestowania oraz przez układ monitorujący na przykład „watch dog” uwzględniając, co następuje:

  1. układ monitorujący powinien umożliwić określenie i sygnalizację błędu przy uszkodzeniu mikroprocesora lub związanych z nim układów zegara,


  2. układ monitorujący powinien umożliwić określenie i sygnalizację błędu, jeśli algorytmy związane z głównymi funkcjami programu nie zostaną zrealizowane,

  3. w przypadku, gdy mikroprocesor nie realizuje prawidłowo programu, obwód monitorujący powinien:

  1. w ciągu 10 s od momentu wykrycia uszkodzenia ponownie zainicjować działanie procesora oraz próbować powtórnie uruchomić program od odpowiedniego punktu. Procedura powinna sprawdzać, czy zawartość pamięci - zarówno programu jak i danych – nie została zniszczona; albo

  2. zarejestrować, wystąpienie uszkodzenia (z użyciem systemu umożliwiającego zarejestrowanie, co najmniej 99 uszkodzeń, resetowanego przez autoryzowany serwis); albo

  3. automatycznie wyzerować system oraz sygnalizować optycznie i akustycznie o tym fakcie.
          1. Funkcjonowanie układu monitorującego oraz sygnalizowanie uszkodzenia nie powinny być zakłócone przez defekt w realizacji programu nadzorowanego systemu.

          2. Układ monitorujący powinien skorzystać z najwyższego priorytetu w celu wprowadzenia CDSO w stan bezpieczeństwa (np. niemaskowalne przerwanie najwyższego priorytetu).




        1. Przechowywanie programów i danych.

          1. Kod programu i dane niezbędne do spełnienia przez CDSO niniejszych wymagań powinny być zachowane w pamięci, która powinna być zdolna do ciągłej, nie odświeżanej i niezawodnej pracy przez co najmniej 10 lat.

          2. Program powinien być zachowywany w nieulotnej pamięci, do której zapis możliwy jest tylko na poziomie dostępu 4. Każda pamięć powinna być identyfikowalna tak, aby mogła być w sposób jednoznaczny przyporządkowana do dokumentacji oprogramowania.

          3. W stosunku do danych konkretnego obiektu powinny być spełnione następujące wymagania:


  1. zmiany nie powinny być możliwe do wprowadzenia na poziomach dostępu 1 lub 2;

  2. zmiana danych obiektowych nie powinna mieć wpływu na strukturę programu;

  3. jeżeli dane obiektowe są przechowywane w pamięci ulotnej, wówczas powinny być zabezpieczone przed utratą podczas zaniku napięcia zasilania przez zastosowanie rezerwowego źródła energii, które może być odłączone od pamięci na poziomie dostępu 4 i które jest zdolne do utrzymania zawartości pamięci co najmniej przez dwa tygodnie;

  4. jeżeli dane są przechowywane w pamięci o dostępie swobodnym (RAM), wówczas powinien istnieć mechanizm, który będzie zapobiegał wpisywaniu do pamięci danych, tak aby zawartość pamięci mogła być chroniona w razie wystąpienia uszkodzenia w realizacji programu.



        1. Nadzorowanie zawartości pamięci


Zawartość pamięci z programem oraz dane obiektowe powinny być automatycznie sprawdzane w odstępach nie przekraczających 1 s. Urządzenie sprawdzające powinno sygnalizować uszkodzenie systemowe w razie wykrycia zafałszowania pamięci.

1   ...   10   11   12   13   14   15   16   17   ...   26


©absta.pl 2016
wyślij wiadomość

    Strona główna