Testy zgodnoci w diagnozowaniu systemów alarmowych

Transkrypt

1 Testy zgodnoci w diagnozowaniu systemów alarmowych Ryszard SOBCZAK Politechnika Gdaska,Wydział Elektroniki, Telekomunikacji i Informatyki ul.g.narutowicza 11/12, Gdask, rsob@pg.gda.pl. Streszczenie: W pracy przedstawiono przydatno technik formalnej specyfikacji w zastosowaniu do testowania systemów alarmowych. Na podstawie specyfikacji wykonanej w jzyku SDL oraz programowego narzdzia moliwe jest automatyczne generowanie sekwencji testujcych sprawdzajcych zgodno działania systemu alarmowego ze stawianymi mu wymaganiami. 1. WSTP Cech charakterystyczn współczesnych systemów alarmowych jest ich rosnca złoono technologiczna i funkcjonalna. S to systemy rozproszone współpracujce z coraz bardziej złoonymi elementami detekcyjnymi oraz z wieloma rodzajami urzdze ochronnych. Cykl pracy systemów tego typu składa si z dwóch faz: fazy dozoru i fazy reakcji na rozpoznany alarm. Faza reakcji na rozpoznany alarm jest faz przerywajc faz dozoru i pojawia si rzadko. Jest ona jednak kluczow jeli chodzi o zastosowanie systemu. Diagnostyka fazy dozoru moe wydawa si zadaniem prostym. Jednake w trakcie tej fazy czsto wykonywany jest tylko proces dozoru. Pozostałe procesy wykonywane s stosunkowo rzadko i przez to rozpoznanie błdów w ich funkcjonowaniu jest równie trudne. Bez specjalnego uzasadnienia mona powiedzie, e diagnostyka systemu w trakcie obsługi alarmu jest wrcz niemoliwa. Std szczególne znaczenie bada i testów diagnostycznych przed dopuszczeniem systemu do eksploatacji. W działaniu systemów alarmowych szczególne znaczenie ma problem współpracy pracowników obsługi z systemem. ródłem trudnoci jest wspomniana niewielka czsto wystpowania fazy alarmowej. W przeciwiestwie do systemów telekomunikacyjnych w systemach alarmowych protokoły współdziałania obsługi z urzdzeniem sygnalizujcym alarm s realizowane wyjtkowo rzadko, a skutki niewłaciwej obsługi niebezpieczne. Alarm oznacza zagroenie chronionego obiektu i działanie obsługi w warunkach stresu. Powoduje to, e mamy tu do czynienia z dwoma wanymi wymaganiami: wymaganiem łatwoci obsługi systemu i wymaganiem poprawnoci działania systemu w sytuacji alarmowej. Przedmiotem pracy s metody zapewnienia poprawnoci działania systemu w sytuacji alarmowej. Systemy alarmowe dopuszczone do esploatacji s przedmiotem testów i bada homologacyjnych opartych o dowiadczenie osób diagnozujcych i badajcych systemy, wsparte odpowiednimi normami. Praca przedstawia moliwoci zastosowania jzyków formalnej specyfikacji do opracowywania wymaga na działanie oraz obsług systemów tego rodzaju,a take do generowania testów zgodnoci z tymi wymaganiami. Testy te powinny by podstaw bada diagnostycznych i homologacyjnych systemów alarmowych. Jako przykładowy system alarmowy posłuył system poarowy i projekt normy opisujcej wymagania na systemy tego typu. W pracy zastosowano do opisu wymaga jzyk SDL (Specification and Description Language) [1] oraz opracowane dla tego typu jzyków techniki generowania testów badania zgodnoci sposobu pracy systemu ze stawianymi mu wymaganiami. Praca zawiera równie ocen przydatnoci zaproponowanej metody diagnozowania. 2. FORMALNA SPECYFIKACJA WYMAGA NA SPOSÓB DZIAŁANIA SYSTEMU ALARMOWEGO Sporód kilku technik formalnej specyfikacji systemów rozproszonych trzy s przedmiotem unormowa o charakterze midzynarodowym.

2 S to jzyki formalnej specyfikacji: SDL, Estelle i LOTOS. Dwa pierwsze jzyki oparte s na modelu rozszerzonego automatu skoczonego, a trzeci na algebrze procesów. Najstarszym jzykiem jest jzyk SDL. Jest to jednoczenie najczciej w praktyce stosowana forma specyfikacji ze wzgldu na jej pierwotne przeznaczenie jakim było specyfikowanie wymaga na sygnalizacje i protokoły telekomunikacyjne. Dziki długiej historii oraz stosunkowo czstemu stosowaniu tego jzyka opracowano wiele narzdzi wspomagajcych jego stosowanie. Modelem lecym u podstaw tego jzyka jest rozszerzony automat skoczony. Automat o skoczonej liczbie stanów, pobudze i reakcji. Podstaw jzyka s konstrukcje pozwalajce na opisanie działania procesu składajcego si z cigu reakcji na moliwe pobudzenia. W kadym stanie procesu (STATE nazwa_stanu) proces oczekuje na pobudzenia (INPUT nazwa_pobudzenia), a w przypadku odebrania konkretnego pobudzenia generuje reakcj na to pobudzenie (OUTPUT nazwa_reakcji) oraz zmienia stan (NEXTSTATE nazwa_kolejnego_stanu) automatu. Przykładowo: NEXTSTATE Alarm; INPUT Uszkodzenie OUTPUT (Wlacz_sygnalizacje_swietlna) NEXTSTATE Alarm END Jak ilustruje to powyszy przykład jzyk ten równie precyzyjnie jak protokoły telekomunikacyjne moe opisywa działanie innych systemów informacyjnych. Oprócz zalenoci typu pobudzenie-reakcja jzyk dostarcza równie rodków do wyraania relacji czasowych. Przykładowo: SET(Timer_1,30); NEXTSTATE Alarm; END STATE Alarm INPUT Timer_1 OUTPUT (Wlacz_alarm_II_stopnia); OUTPUT (Wlacz_gasnice); NEXTSTATE Alarm_II_stopnia; INPUT Kasuj_alarm RESET (Timer_1); OUTPUT (Wylacz_syrene); OUTPUT (Sprawdz_uprawnienia); NEXTSTATE (Po_kasowaniu) ENDSTATE Alarm Polecenie SET pozwala uruchomi lokalny dla procesu zegar o nazwie Timer_1 i potraktowa upłynicie zadanego przedziału czasu jako pobudzenie. Polecenie RESET zeruje zegar przed upływem odmierzanego czasu. Przedstawiona w ostatnim przykładzie konstrukcja jest typowym opisem time out-u. Z kadym sygnałem nadawanym mona zwiza odbiorc sygnału: OUTPUT (Modul_gaszenia, Wlacz_gasnice) Odbieranie pobudze zakłada identyfikacj typu pobudzenia niezalenie od jego ródła. Nadawane reakcje i odbierane pobudzenia s nie tylko sygnałami synchronizujcymi działanie systemu, lecz mog równie zawiera dane: (nr_linii,nr_punktu) OUTPUT (Modul_gaszenia, Wlacz_gasnice(nr- _strefy) Wicej szczegółów na temat SDL mona znale w [1]. Poniej przedstawiono specyfikacj wymaga funkcjonowania urzdzenia alarmowego w stanie alarmu wykonan na podstawie projektu normy Systemy sygnalizacji poarowej. Centrale sygnalizacji poarowej [2] z odwołaniami do odpowiednich punktów normy. PROCESS(P_ALARM) INPUT AlarmPozar OUTPUT (wysw_tekst(a_alarm)); Licznik:=Licznik+1, (* Punkt 7.13 *) STATE Pozar INPUT AlarmPozar OUTPUT (wysw_tekst(a_alarm)); Licznik:=Licznik+1, (* Punkt 7.13 *) INPUT Klw_kursor pozar_pierwszy(); INPUT Klw_stop (* Punkt *)

3 OUTPUT (Wyl_syrene); INPUT Klw_alarm (* Punkt 7.11.d *) led_wl(ao); OUTPUT(P_KONTR,USTAW);(* Punkt 7.8 *) OUTPUT(P_TRANS,ALARM); (* Pkt 7.7 *) INPUT Klw_kasow (* Punkt 7.6 *) OUTPUT (P_KODY, Sprawdz_upr); NEXTSTATE Reset_po_alarmie; INPUT Timer (* Punkt d *) wysw_tekst(a_alarm); ENDSTATE; STATE Reset_po_alarmie INPUT Zgodny OUTPUT (Aktywuj); OUTPUT (Reset); NEXT INPUT Niezgodny NEXTSTATE Pozar ENDSTATE; ENDPROCESS; Przedstawiony fragment formalnej specyfikacji wymaga jednoznacznie definiuje rodzaje pobudze, które mog pojawi si w trakcie obsługi sytuacji poarowej oraz rodzaje reakcji na te pobudzenia. Specyfikacja jest niepełna, gdy nie uwzgldnia przykładowo zgłoszenia uszkodzenia w trakcie obsługi poaru. Jaki jest poytek ze stosowania tego formalizmu? Istniej trzy powody, dla których formalizm ten jest niezbdny, a mianowicie: 1. potrzeba sprawdzenia wewntrznej zgodnoci wymaga zawartych w normie tak, by sformułowania normy nie stawarzała moliwoci wykonania systemu zgodnego z norm, lecz działajcego niepoprawnie, 2. wymaganie wyraone w normie by dokumentacja była na tyle dokładna, aby umoliwi kontrol zgodnoci z wymaganiami niniejszej normy, 3. przeprowadzenie testów dopuszczajcych urzdzenie do eksploatacji. Zagadnienie wewntrznej zgodnoci wymaga sformułowanych w ramach normy jest istotne, ale wykracza poza ramy diagnostyki systemów. Praktyka wskazuje, e realizacja drugiego postulatu jest nierealna ze wzgldu na rónorodno technologii i jako oprogramowania funkcjonujcego w systemach alarmowych. Naley wic przynajmniej badania dopuszczajce system do eksploatacji przeprowadzi w sposób, który gwarantuje spełnienie zapisanych w normie wymaga. 3. TESTY ZGODNOCI Testy zgodnoci pozwalaj sprawdzi na ile testowany system działa zgodnie ze stawianymi mu wymaganiami. Testy zgodnoci Specyfikacja wymaga Wdroenie Produkt Rys. 1 Przeznaczenie testów zgodnoci Efektywne stosowanie testów zgodnoci wymaga narzdzi ich automatycznego generowania. Podstaw algorytmów automatycznego generowania testów zgodnoci jest istnienie sformalizowanej specyfikacji sposobu działania systemu. Dla systemów, dla których podstaw jest model automatowy technik generowania testów zgodnoci przedstawiono przykładowo w [3]. Załoenia, które musi spełnia specyfikacja by mona było dla niej wygenerowa w sposób automatyczny sekwencj testujc s nastpujce: 1. model opisujcy testowany system musi mie posta deterministycznej maszyny stanów o skoczonej liczbie stanów oraz znany i skoczony zbiór pobudze i reakcji, 2. model powinien zapewnia generowanie reakcji na pobudzenia w skoczonym czasie, 3. stany i przejcia modelu tworz silnie połczony graf. 4. w kadym stanie testowany system akceptuje i generuje poprawne reakcje na cały zestaw pobudze. Spełnienie tych wymaga przez specyfikacje wykonane w jzyku SDL jest oczywiste. Naley przy tym jednak przyj, e odmierzanie czasu (polecenia INPUT, SET oraz RESET) jest równowane odbieraniu pobudzenia od procesu zegara i wysyłaniu reakcji do procesu zegara. Rys. 2 ilustruje maszyn stanów dla przedstawionej specyfikacji.

4 Generowanie sekwencji testujcej polega na wygenerowaniu sekwencji przej obejmujcej wszystkie przejcia w grafie (złoenie algorytmu poszukiwania cyklu Eulera z algorytmem AlarmPozar Klw_kursor Klw_stop Klw_alarm Timer Pozar Dozor AlarmPozar Niezgodny Zgodny PoAlarmie Klw_kasow Rys. 2. Maszyna stanów procesu obsługi zgłoszenia poarowego Dijkstry znajdowania najkrótszej cieki w grafie). Długo tak skonstruowanej sekwencji jest nie wiksza ni: S P gdzie S to liczba stanów w grafie, a P liczba pobudze. W rzeczywistych systemach alarmowych rzdy wielkoci S i P s wielokrotnie mniejsze ni w systemach telekomunikacyjnych. Liczba S nie powinna by wiksza ni 50, a liczba P nie wiksza ni 100. Daje to sekwencj testujc o długoci najwyej 5000 pobudze. W analizowanym przykładzie S=3, a P= 8 co daje długo najdłuszej sekwencji równ 24. Na podstawie przedstawionych w [3] algorytmów wykonano oprogramowanie generujce sekwencje testujce [4]. Narzdzie było przeznaczone do generowania testów zgodnoci protokołów i usług telekomunikacyjnych. Zastosowane dla przedstawionej powyej specyfikacji wygenerowało sekwencj testujc nastpujcej postaci: AlarmPozar -> AlarmPozar -> Klw_kursor -> Klw_stop -> Klw_alarm -> Timer -> Klw_kasow -> Niezgodny -> Klw_kasow -> Zgodny Otrzymana sekwencja ma długo 10 pobudze i jest prawie dwa razy krótsza ni dokonane wczeniej oszacowanie z góry. ródłem tak du- ej rónicy jest zwizanie z kadym stanem tylko wybranych pobudze, a nie wszystkich moliwych. Oznacza to te, e sekwencja testujca dla rzeczywistych systemów bdzie znacznie krótsza ni wynika to z maksymalnego oszacowania. Wystpienie w sekwencji pary AlarmPozar wynika z moliwoci wystpienie tego pobudzenia w dwóch stanach: w stanie Dozoru i stanie Pozaru. Kolejno pobudze w cigu AlarmPozar -> Klw_kursor -> Klw_stop -> Klw_alarm -> Timer jest dowolna o ile załoymy, e wykonana specyfikacja jest wewntrznie poprawna. Wówczas kolejno pojawiania si wymienionych pobudze w stanie obsługi poaru nie jest istotna. Pobudzenie Klw_kasow moe spowodowa zmian stanu lub pozostanie w dotychczasowym stanie, w zalenoci od wartoci nastpnego pobudzenia i dlatego pojawia si w sekwencji testujcej dwukrotnie w parze z pobudzeniami Zgodny i Niezgodny. 4. PODSUMOWANIE Zastosowanie formalnej specyfikacji do wyra- enia wymaga stawianych systemom alarmowym stwarza moliwo automatycznego generowania sekwencji testujcych sprawdzajcych zgodno produktu z wymaganiami normy, która je definiuje. Tak przeprowadzone testy powinny przyczyni si do usprawnienia procesu homologowania systemów alarmowych oraz podnie ich jako. Istnienie formalnej specyfikacji wymaga usprawni równie proces wytwarzania systemów alarmowych. LITERATURA [1] CCITT Specification and Description Language (SDL). ITU Recomm. Z.100, 1995 [2] Systemy sygnalizacji poarowej. Centrale sygnalizacji poarowej. Projekt Polskiej Normy, PKN, [3] Holzmann G.J.: Design and validation of computer protocols. Prentice-Hall Int., London, 1991 [4] Putyrski S.: Testy zgodnoci dla protokołów komunikacyjnych, Praca dyplomowa, Politechnika Gdaska WETI, Gdask, 1997 Using conformance tests in diagnostic of warning systems The usefulness of formal specification techniques in testing and certifying warning systems is shown. On the basis of specification in SDL language and ap-

5 propriate software tool it is possible to generate testing sequences, which check conformance of device operation and system requirements.