Przykład budowy bazy wiedzy

Praktyczne wykorzystanie diagnostycznego systemu ekspertowego (DSE), jako mechanizmu wspomagającego pracę systemu sterowania, musi opierać się na dobrze zaplanowanej i zbudowanej bazie wiedzy. Przed przystąpieniem do szczegółowego opisu elementów systemu ekspertowego, przedstawiony zostanie przykład dający wstępne wyobrażenie o możliwościach oraz sposobie jego działania.

Przykład opisuje zdarzenie powstałe w chwili odczytania rekordu z lokalnej bazy danych, dotyczące zmiany wartości nastawnika. Stan nastawnika może być ustawiany przez:

- program ConfigNetRS485 przeznaczony do konfiguracji sieci RS485,

- diagnostyczny system ekspertowy,

- inne czynniki zewnętrze powodujące np.: zrestartowanie węzła lub uszkodzenie urządzenia.

Zmiana stanu nastawnika inicjuje komunikację z węzłem LON. Przesłany pakiet z sieci RS485 jest dalej przekazywany przez dynamiczną zmienną sieciową warstwy LON do komputera z lokalną bazą danych. Pojawienie się nowego rekordu w tabeli nvChange może rozpoczynać proces sprawdzania poprawności przekazanego parametru w diagnostycznym systemie ekspertowym.

W chwili odczytania w lokalnym serwerze komunikacyjnym, pakietu z informacją o zmianie stanu nastawnika, możemy założyć, iż:

jest ono prawidłowo zainstalowane w systemie,

oraz komunikuje się poprzez sieć LON z lokalną bazą danych.

W takiej sytuacji należy sprawdzić czy stan nastawnika jest uzależniony od parametrów innych urządzeń, to znaczy czy nastawnik pracuje w podsystemie z innymi urządzeniami jak np. miernik temperatury. Jeżeli tak jest, znaczy to, iż analizie powinny podlegać wszystkie związane zależnościami parametry współpracujących urządzeń. Jedna z hipotez postawiona w tym miejscu brzmi: „Nieprawidłowa praca podsystemu centralnego ogrzewania”. Podczas wnioskowania będzie można ją potwierdzić lub zaprzeczyć.

W rozpatrywanym przypadku system ekspertowy powinien wykonać następujące czynności:

Sprawdzić czy nastawnik pracuje w podsystemie CO oraz pobrać listę urządzeń podrzędnych, w tym podsystemie są to mierniki temperatury.

Jeśli pobrana zostanie pusta lista, już w tym miejscu możemy wysnuć stwierdzenie mówiące, że nastawnik jest samodzielnie pracującym urządzeniem, zaprzeczającą tym samym, iż podsystem centralnego ogrzewania działa nieprawidłowo.

Jeżeli na liście będą identyfikatory urządzeń podrzędnych, system powinien wygenerować i wysłać pakiet do pierwszego odczytanego miernika z zapytaniem o wartość temperatury aktualnej oraz zadanej.

Jeżeli miernik temperatury nie odpowie na zapytanie w określonym czasie, hipoteza główna potwierdzi się, a przyczyną będzie nieprawidłowo działający miernik temperatury, który dalej w innym wątku, szczegółowo może być badany przez system ekspertowy.

Prawidłowo odczytane parametry miernika temperatury pozwalają przejść do kolejnych czynności polegających na sprawdzeniu stosunku temperatury aktualnej do zadanej, jednocześnie sprawdzając stan nastawnika. Hipoteza główna znajdzie swoje potwierdzenie, gdy zostaną spełnione następujące warunki:

o temperatura aktualna jest wyższa od zadanej oraz stan nastawnika jest równy 1,

o temperatura aktualna jest niższa od zadanej oraz stan nastawnika jest równy 0.

W pozostałych przypadkach podsystem CO sterujący zaworami kaloryfera traktujemy jako prawidłowo działający.

Powyższe warunki znajdują swoje odwzorowanie w systemie ekspertowym w formie graficznych bloków przedstawiających wiedzę, jako reguły połączone zależnościami wynikającymi z dopasowania warunków jednej reguły i konkluzji drugiej (Rysunek 5.2). Pierwszy wiersz w każdym prostokątnym bloku opisuje w umowny i skrócony sposób identyfikator konkluzji np.: CO064_52, pozostałe to identyfikatory warunków np.:

CO064_100 i CO064_101. W takim zapisie wyodrębniamy wartości pozwalające wstępnie

zrozumieć przynależność takiego obiektu do diagnozowanego urządzenia oraz niektórych jego parametrów. Dodatkowo z każdym elementem, nazywanym obiektem zmiennej związany jest opis w formie ciągu znaków, który nie jest dostępny w trybie graficznym, a może być odczytany w czasie edycji reguły np. w dolnym panelu aplikacji. Jest to tekst opisujący w zrozumiały dla użytkownika sposób znaczenie danej konkluzji lub warunku np.: CO064_52 – Nieprawidłowe praca podsystemu CO.

Rysunek 5.3. Lista obiektów zmiennych

Pierwsze dwa znaki, np. „CO” oznaczają przynależność do grupy obiektów, powiązanych tematycznie. Mogą to być znaki identyfikujące dany podsystem np. „CO” jako podsystem centralnego ogrzewania, może dotyczyć np. mechanizmów dostępu do bazy danych lub innych narzędzi sprzętowych i programowych dostępne z poziomu DSE. Dzięki temu w łatwy sposób możemy filtrować obiekty dotyczące jednego wybranego zagadnienia. Wartości tu występujące nie są narzucane przez system i mogą być proponowane przez eksperta i ustalane przez inżyniera wiedzy.

Trzy kolejne cyfry np. 064 jednoznacznie określają typ urządzenia, którego dotyczy dany

obiekt zmiennej, np. może to być typ urządzenia diagnozowanego lub odpytywanego.

Ostatni element występujący w zapisie obiektu zmiennej traktowany jest jako jego identyfikator. Niektóre wartość powinny być zarezerwowane dla poleceń i zapytań, które są wysyłane w pakietach do/z fizycznych urządzeń. Dokładny opis pakietów został przedstawiony w rozdziale „Komunikacja w sieci LON”. Np. wartość „_51” to zapytanie o parametry danego urządzenia. Jeśli cały zapis ma postać CO016_51 odczytujemy z niego, iż miernik temperatury „typ 16” z grupy CO pytany jest o wartość temperatury - „zapytanie nr 51”. Większość wartości identyfikatorów obiektów zmiennych ma znaczenie umowne i służy wyłącznie zapewnieniu jego integralności. W jednej bazie wiedzy nie może istnieć dwa obiekty o takiej samej konfiguracji wartości tworzących identyfikator. Warunkiem powstania relacji między regułami, a dokładniej między warunkiem jednej reguły i konkluzją drugiej jest zgodność wszystkich trzech pól obiektu zmiennej.

Opis wszystkich składowych reguł, pojawiający się w omawianym przykładzie, przedstawiony został bardzo szczegółowo w rozdziale „Budowa i edycja bazy wiedzy”.

Obiekt zmiennej to tylko jeden z wielu składowych obiektu warunku. W każdym obiekcie warunku, można porównywać wartości argumentów zapisane w zmiennych tekstowych,

pochodzące z różnych źródeł, np. bazy danych, od użytkownika lub mogą być tworzone w trakcie wnioskowania. Do zapisu warunku wykorzystywany jest język skryptowy,

pomagający generować, pobierać i zestawiać porównywane wartości. Jeśli w obiekcie

warunku nie występują wartości porównywane, oznacza to iż stan warunku uzależniony

jest od stanu konkluzji innej reguły połączonej relacją.

Pierwsza reguła o identyfikatorze R2 przedstawia konkluzję (CO064_52) traktowaną jako hipotezę prawdziwą gdy dwa poniższe dwa warunki (CO064_100 i CO064_101) zostaną spełnione.

(R2) CO064_52 – Nieprawidłowa praca podsystemu CO = GDY:

CO064_100 – Nastawnik działa w podsystemie CO z miernikiem temperatury AND CO064_101 – Nieprawidłowe parametry podsystemu CO.

W tych dwóch warunkach brak jest porównywanych argumentów, co oznacza uzależnienie wyniku od konkluzji następnych reguł o tym samym identyfikatorze: CO064_100

i CO064_101 (reguły: R3 i R5). W pierwszej kolejności sprawdzany będzie warunek

reguły R3:

(R3) CO064_100 – Nastawnik działa w podsystemie CO z miernikiem temperatury = GDY

CO064_15 – Pobrano pakiet z listą urządzeń podrzędnych F

Wartość identyfikatora obiektu zmienne (równa 15) warunku CO064_15 jest jednocześnie poleceniem wysyłanym do węzła LON z zapytaniem o listę urządzeń podrzędnych, współpracujących z nastawnikiem, dla którego aktualnie będzie przebiegał proces wnioskowania. Dokładny sposób organizacji danych sprecyzowany został z poziomu okna edycji konkretnego warunku i zapisany w tzw. Obiekcie fasety. Ustalone w niej wartości opisują w jaki sposób i do kogo będzie kierowane zapytanie np. o wartości parametrów urządzenia. Adresatem może być fizyczny moduł mikroprocesorowy dostępne pośrednio przez lokalną bazę danych lub użytkownik systemu. Wszystkie odpowiedzi przez nich generowane zapisywane są w tablicy obiektów faktów i mogą być wielokrotnie używane w programie podczas wnioskowania. Taka odpowiedź to jedyna forma interpretowana przez program DSE.

O tym, że dla danego warunku istnieje obiekt fasety informuje znak dużej litery F.

Bezpośrednio z obiektem fasety związane jest okno dialogowe „Edit Fasets” dające możliwość ustawienia kolejności wykonywanych faset.

W tym konkretnym przypadku, w pierwszej kolejności ustawiono polecenie wysłania zapytania do węzła LON („faseta 1 – DataBase”), a następnie pobrania odpowiedzi w formie obiektu faktu (faseta 2 – Facts 1). Dodatkowe trzy parametry dla fasety opisującej sposób poszukiwania obiektu faktu w tablicy, sprecyzowano w oknie „Edit Faset Fact”. Brak zaznaczonej opcji „Opóźnienie” powoduje natychmiastowe wszczęcie przeszukiwanie tablicy obiektów faktów.

„Ważność faktu” pozwala ustalić okres czasu, w którym istniejąca już odpowiedz jest ważna i może być użyta w procesie wnioskowania. Gdy ta wartość zostanie przekroczona, program pomija taką odpowiedz i dalej szuka, oczekując na pojawienie się nowego obiektu

faktu. Nie może on przekroczyć wartości określonej w kolejnych polach opcji „Czas

oczekiwania”. Przekroczenie tego parametru może być sygnałem dla systemu ekspertowego, mówiącym np. o problemie komunikacji z węzłem LON.

W prezentowanym przykładzie, czas w którym odpowiedz przesłana od urządzenia może być wykorzystana w danym wątku, wynosi 10 sekund. Po wysłaniu zapytania o identyfikator urządzenia podrzędnego, program czeka 3 sekundy na odpowiedz. Po tym czasie przypisana zostaje domyślna wartość zwracana przez warunek równa 0 – „false”. Gdy poszukiwanie zakończy się sukcesem, status warunku, a tym samym całej reguły R3 będzie równy 1 – „true”.

Kolejna reguła R5 zestawia aktualny stan nastawnika z wynikiem porównania temperatury zadanej i aktualnej:

(R5) CO064_101 – Nieprawidłowe parametry podsystemu CO = GDY

CO016_100 Temperatura aktualna *1 = jest_wyższa_niż_zadana ORAZ

CO064_112 Stan nastawnika ^1 = 1

W pierwszym warunku program sprawdza czy zwrócony ciąg znaków z następnej reguły R7, na pozycji pierwszej (*1) jest równy „jest_wyższa_niż_zadana”. W kolejnym warunku sprawdzana jest wartość będąca częścią pakiety z informacją o zmianie stanu nastawnika, inicjującego proces wnioskowania (CO064_52). Wskazanie pozycji pobieranej wartości w pakiecie poprzedza znak „^”. Pakiet odczytany z tabeli NvChange, który był sygnałem do wszczęcia wnioskowania, na pozycji pierwszej „^1” zawiera aktualny stan nastawnika. Reguła R7 zwraca wynik konkluzji CO016_100 w postaci ciągu znaków „jest_wyższa_niż_zadana” gdy warunek CO016_101 jest prawdziwy.

(R7) CO016_100 - Temperatura aktualna *1 = jest_wyższa_niż_zadana. GDY

CO016_101 - Temperatura aktualna double(*1,*2) ; >= double(*3,*4);

Funkcja double zamienia dwie wartości całkowite pobrane z pakietu przesłanego przez urządzenie do wartości rzeczywistej. Wynik pierwszej funkcji double zwraca temperaturę aktualną oraz druga zwraca temperaturę zadaną. W pakiecie danych, wartości całkowite i rzeczywiste przesyłane są jako oddzielne bajty danych.

Konkluzja kolejnej reguły R9 wystawia kolejno cztery wartości temperatury pobrane przez fasetę ustawioną przy warunku CO016_51.

Rysunek 5.5. Edycja konkluzji CO016_101

(R9) CO016_101 Temperatura *1,*2,*3,*4 = *1,*2,*3,*4 (obiektu faktu CO016_51) GDY

CO016_51 - Pobrano wartość temperatury F

Zapis powyższej konkluzji można rozumieć następująco: Gdy warunek CO016_51 jest spełniony, tzn. program otrzyma pakiet z wartością temperatury, kolejne cztery bajty pakietu będą przypisane do konkluzji CO016_101. Wartości z pierwszej, drugiej, trzeciej i czwartej pozycji pakietu nr=51 zapisz jako kolejne elementy konkluzji w tej samej kolejności (*1,*2,*3,*4 = *1,*2,*3,*4). Na podstawie danych warunku CO016_51 program generuje pakiet 51 z zapytaniem o aktualną wartość temperatury do miernika (typ 16) o identyfikatorze pobranym z pakietu CO064_15. Identyfikator urządzenia ustawiany jest w oknie „Edit Fasets” (Rysunek 5.4) i może być pobrany z istniejących obiektów

faktów wygenerowanych przez warunki z określonym statusem.

Reguła R6 podobna jest w składni do reguły R5, opisuje ona drugi przypadek, gdy wartości parametrów podsystemu nie są prawidłowe, tzn. jeśli gdy temperatura aktualna jest niższa niż zadana oraz stan nastawnika równa się zero.

(R6) CO064_101 – Nieprawidłowe parametry podsystemu CO = GDY

CO016_100 Temperatura aktualna *1 = jest_niższa_niż_zadana ORAZ

CO064_112 Stan nastawnika ^1 = 0 Reguła R10:

(R10) CO016_100 - Temperatura aktualna *1 = jest_niższa_niż_zadana. GDY

CO016_101 - Temperatura aktualna double(*1,*2) ; < double(*3,*4);

Ostatni przypadek potwierdzający nieprawidłową pracę podsystemu CO mówiący o braku komunikacji z urządzeniem podrzędnym, przedstawiają reguły R12 i R13.

(R12) CO064_101 – Nieprawidłowe parametry podsystemu CO = GDY

CO064_113- Miernik temperatury *1 = nie_odpowiada

(R13) CO064_113 - Miernik temperatury *1 = nie_odpowiada GDY

CO16_101 (NIE) Temperatura aktualna

Zadaniem ostatniej reguły R13 jest przekazanie do zmiennej „Miernik temperatury” odpowiedzi w formie ciągu znaków „nie odpowiada” gdy fizyczne urządzenie nie odpowie na wcześniej wysłane zapytanie. Zapis warunku CO16_101 (NIE) oznacza, iż zwrócona wartość z reguły R9 będzie zanegowana. Całą regułę czytamy – „Gdy

temperatura aktualnie NIE została pobrana, znaczy to iż miernik temperatury nie odpowiada”.

Wszystkie przedstawione w powyższym przykładzie reguły mogą być częściowo lub w całości łączone relacjami z innymi regułami, jako część nowej wiedzy opisującej nowe zadania.