• Nie Znaleziono Wyników

Dla potrzeb wykorzystania zbiorów wymagań do opisu oczekiwanych funkcjonalności systemu diagnostycznego, konieczne jest wprowadzenie pewnych dodatkowych założeń, które nie są spo-tykane w obszarze inżynierii oprogramowania. Założenia te (Amarowicz, 2014b, 2015), związane są z koniecznością przyjęcia pewnego specyficznego sposobu zapisu definiowanych wymagań, tak aby możliwe było uwzględnienie wszystkich niezbędnych informacji, potrzebnych do opracowania zbioru potencjalnych projektów systemu diagnostycznego.

Biorąc pod uwagę wymienione wcześniej uwagi i spostrzeżenia, każde wymaganie funkcjonal-ne reqi może być zapisane jako:

reqi =< eot, cr, attrr, pfr, drule>, (6.2) gdzie:

ˆ eot – element obiektu technicznego,

ˆ cr – treść wymagania,

ˆ attrr – atrybuty wymagania,

ˆ pfr – stopień preferencji wymagania,

ˆ drule – zbiór reguł diagnostycznych.

Treść wymagania jest słownym opisem funkcjonalności systemu diagnostycznego, związanej z po-trzebą rozpoznawania określonego stanu technicznego obiektu1, np. konieczność wykrywania zła-mania zęba koła zębatego. Do każdego wymagania, możliwe jest przypisanie pewnego zbioru atrybutów:

attrr= {attrr1, attrr2, ...}, (6.3) które będą stosowane do dokładnego opisu danego wymagania oraz będą przydatne dla potrzeb procesu oceny zgromadzonych wymagań. Każdy atrybut attri może być zapisany jako:

attri =< ci, vi, impi>, (6.4) gdzie:

ˆ ci – treść/nazwa atrybutu,

ˆ vi – wartość atrybutu,

ˆ impi – stopień ważności atrybutu.

1Zgodnie z zależnością 2.4, stan techniczny obiektu jest funkcją uszkodzeń. Można zatem rozpatrywać treść wymagania, jako konieczność wykrywania określonych uszkodzeń lub zużyć obiektu.

Metoda projektowania systemów diagnostycznych z zastosowaniem zbiorów wymagań 51 Przykładami atrybutów mogą być np. poziom redukcji/ograniczenia prawdopodobieństwa pienia uszkodzenia opisanego przez wymaganie, poziom redukcji kosztów związanych z wystą-pieniem danego zdarzenia itp. Każdemu wymaganiu funkcjonalnemu, można przyporządkować pewną wartość z przedziału< 0; 1 >, nazywaną stopniem preferencji pf. Wyraża on konieczność uwzględnienia funkcjonalności opisanej przez dane wymaganie, w końcowym projekcie systemu diagnostycznego. Stopień preferencji może być traktowany jako subiektywna ocena przydatno-ści funkcjonalnoprzydatno-ści opisanej przez dane wymaganie, do osiągnięcia przez system diagnostyczny założonej funkcji celu, czyli minimalizacji ryzyka technicznego. Każde wymaganie funkcjonalne jest przypisywane do wybranego podzespołu/elementu obiektu technicznego eot, celem uporząd-kowania definiowanych wymagań i utworzenia hierarchicznego zbioru wymagań.

Do każdego wymagania funkcjonalnego, można przypisać pewien zbiór potencjalnych reguł diagnostycznych:

drule= {drule1, drule2, ...}, (6.5) które mogą być zastosowane, do rozpoznawania stanu technicznego opisanego przez dane wy-maganie. Każda reguła diagnostyczna zapisywana jest jako:

drulei=< cdr, attrdr, pfdr, subs, ko>, (6.6) gdzie:

ˆ cdr – treść reguły,

ˆ attrdr – atrybuty reguły,

ˆ pfdr – stopień preferencji reguły diagnostycznej,

ˆ subs – zbiór podsystemów diagnostycznych,

ˆ ko – kryteria ograniczające dla podsystemów.

Analogicznie jak w przypadku opisu wymagania, cdr jest opisem słownym reguły, np. przekro-czona wartość skuteczna drgań, attrdr to zbiór możliwych atrybutów, za pomocą których można dokładnie opisać każdą z reguł np. poziom fałszywych alarmów, natomiast pfdr to stopień pre-ferencji przypisany do reguły. W przypadku reguł diagnostycznych, stopnień prepre-ferencji niesie informację o tym czy reguła diagnostyczna jest przydatna do wykrywania danego uszkodzenia, natomiast każdy z atrybutów zapisywany jest identycznie jak w przypadku atrybutów wymaga-nia funkcjonalnego.

Każda z reguł diagnostycznych może być zrealizowana, poprzez zastosowanie tzw. podsys-temu diagnostycznego, w skład którego wchodzą określone układy pomiarowe oraz algorytmy analizy i wnioskowania. Każdy podsystem subs może być zapisany jako:

subsi=< etype, vf k >, (6.7) gdzie:

ˆ etype – zbiór typów elementów podsystemu,

ˆ vf k – wartość funkcji kryterialnej.

Jako typy elementów podsystemu rozumiane są możliwe do zastosowania kategorie czujników, kart pomiarowych, operacje analizy sygnałów itd. Przyjęcie takiej formy zapisu podsystemu dia-gnostycznego, pozwala na etapie formalizowania potrzeby projektowej, na opracowanie zbioru potencjalnych podsystemów diagnostycznych bez wnikania w dokładne ich szczegóły, tj. w

kon-Metoda projektowania systemów diagnostycznych z zastosowaniem zbiorów wymagań 52 kretne egzemplarze poszczególnych elementów. Dla potrzeb dalszych rozważań, każdy typ ele-mentu podsystemu może być zapisany jako:

etypei=< elem, attre>, (6.8) gdzie elem to zbiór możliwych egzemplarzy elementów danego typu, czyli np. konkretne czujniki z katalogów a attre to zbiór atrybutów opisujących dany typ elementu, np. zakres pomiarowy, czułość, cena itd. Atrybuty te stosowane są w procesie optymalizacji projektu systemu dia-gnostycznego. Dla potrzeb ograniczania możliwości zastosowania wybranych elementów wcho-dzących w skład podsystemów, możliwe jest zdefiniowanie zbioru kryteriów ograniczających ko, przypisanych do poszczególnych reguł diagnostycznych drulei. Poszczególnym podsystemom w procesie optymalizacji, przypisywana jest pewna wartość vf k, będąca wynikiem zastosowania funkcji kryterialnej. Przykładowo poszukując rozwiązania cechującego się minimalną ceną, bę-dzie to po prostu koszt danego podsystemu itd. W wielu przypadkach możliwe lub konieczne jest zastosowanie optymalizacji wielokryteriowej.

Opisany w sposób formalny, schemat zależności pomiędzy wymaganiami funkcjonalnymi, regułami diagnostycznymi oraz podsystemami, wraz z przykładowymi ich egzemplarzami, zi-lustrowany został w sposób graficzny na rys. 6.3. Dla potrzeb rozważań w ramach inżynierii wymagań, reguły diagnostyczne oraz przypisane do nich podsystemy mogą być traktowane jako wymagania pozafunkcjonalne przypisane do wybranych wymagań funkcjonalnych, opisujących oczekiwane funkcjonalności projektowanego systemu diagnostycznego. Opisują one potencjalne możliwe ścieżki, w ramach których mogą być zrealizowane poszczególne z wymagań funkcjonal-nych.

Obiekt techniczny Węzeł łożyskowy z łożyskiem kulkowym zwykłym.

Rys. 6.3: Schemat zależności pomiędzy elementami proponowanego formatu zapisu wymagań

Metoda projektowania systemów diagnostycznych z zastosowaniem zbiorów wymagań 53