Podsystem wnioskujący

Reguły zgromadzone w bazie wiedzy oraz relacje między nimi, opisują sposób postępowania zmierzający do rozwiązania określonego problemu. Możliwości takiego postępowania ograniczone zostało o mechanizmy maszyny wnioskującej posiadającej stałe algorytmy operujące na pewnych danych bazy wiedzy.

Cały mechanizm wnioskujący przeznaczony dla jednego urządzenia, umieszczony został w oddzielnym, niezależnym wątku, w którym zawarto nieskończoną pętle wywołującą cyklicznie kolejne funkcje pobierania nowych obiektów faktów, generującą drzewo reguł oraz funkcje analizującą zapisaną w regułach wiedzę. Każde nowe wnioskowanie inicjowane jest przez obiekt faktu, dla którego tworzona jest struktura obiektów reguł skojarzonych ze sobą według określonych zasad opisanych w rozdziale „Budowa i edycja bazy wiedzy”. Mechanizm polegający na generowaniu maksymalnej liczby możliwych relacji, daje pełny obraz możliwości rozwiązań zapisanych w postaci wiedzy regułowej również wtedy, gdy nie biorą on bezpośredniego udziału w procesie wnioskowania. Do rozwiązania określonego problemu wykorzystywane są jedynie te reguły z pośród utworzonych, które pozwolą na jednoznaczną odpowiedź. Wiedza zapisana w blokach reguł nie biorących udziału w procesie wnioskowania również może być cenna dla operatora systemu. Użytkownik może dokładniej ocenić jakość udzielonej odpowiedzi, widząc reguły bezpośrednio wykorzystane w procesie wnioskowania oraz te, które zostały pominięte i dla których status nie został określony.

Dzięki mechanizmom organizacji pamięci przez interpretera języka Java, usuwanie wszelkich niewykorzystywanych obiektów, również obiektów reguł spoczywa na maszynie wirtualnej Javy.

Obiekt reguły to instancja klasy „ESObjectRule”. Najważniejsze jej pola to:

ESRule eSRule;

int status, statusCond[ ][ ]; ESObjectRule tESObjectRuleNext [ ][ ]; TimerES timer1[ ], timerWait1[ ];

eSRule - jest to odnośnik do już istniejącej reguły utworzonej podczas edycji i zapisanej w wektorze reguł. Dwie kolejne zmienne opisują status reguły oraz statusy warunków, ustalane podczas wnioskowania. Wskazania na reguły spełniające warunki relacji, zapisywane są w macierzy tESObjectRuleNext [ ][ ]. Ostatnie dwa obiekty reprezentują „timery” generowane na podstawie „fasety faktów”, gdzie pierwszy odlicza czas „opóźnienia”, po którym rozpoczyna się przeszukiwanie tablicy obiektów faktów. Drugi „timer” dotyczy czasu oczekiwania na obiekt faktu. Po tym czasie, gdy brak jest szukanego obiektu, status danego warunku może przyjąć jedną z ustalonych w fasecie wartości „1”, „0” lub „-1”.

Domyślne opóźnienie głównej pętli to jedna sekunda, w tym czasie dla nowych obiektów

faktów tworzone są relacje, ale tylko raz podczas pierwszego cyklu. W tym okresie czasu

analizowane są wszystkie dopuszczone do tego procesu reguły. Wyłączone są reguły, których status jest znany oraz te które nie są blokowane przez zmienną join fasety warunku.

Wnioskowanie zaczyna się od pierwszej reguły, której odnośnik zapisany jest w obiekcie

związane żadne fasety, wykonywana jest następna nieokreślona reguła wskazana przez pierwszy odnośnik z macierzy tESObjectRuleNext [ ][ ]. W jednym wierszu tablicy dwuwymiarowej zapisywane są wskaźniki reguł związane z pierwszym warunkiem. Miedzy tymi regułami domyślnie występuje operator OR.

Gdy reguła jest określona zwracany jest wynik do warunku poprzedniej reguły. Zanim ostatecznie wartość statusu warunku zostanie przypisana, porównywane będą wartości wektora wygenerowanego z zapisu skryptowego warunku z wektorem konkluzji wskazanej reguły po przypisaniu konkretnych wartości faktów.

Algorytm obrazujący mechanizm wnioskowania w obrębie jednego wątku przedstawiony został na rysunku 8.5.

Rysunek 8.5. Schemat wnioskowania podczas jednego cyklu głównej pętli dla jednego wątku.

Pobierz regułę

Czy reguła jest określona? T

N

Pobierz warunek T

N Analizuj fasety warunku

T

N

REGUŁA NIE JEST OKREŚLONA Czy znaleziono? Czy jest to ostatni

warunek? REGUŁA JEST OKREŚLONA N N T WEJŚCIE T

Szukaj nowej reguły, której konkluzja da się dopasować

do warunku

Powróć do warunku poprzedniej reguły

Czy ta reguła była pobrana jako pierwsza?

HIPOTEZA NIE POTWIERDZONA Powróć do warunku

poprzedniej reguły Czy ta reguła była pobrana

jako pierwsza? T N N HIPOTEZA POTWIERDZONA WYJŚCIE Czy wszystkie fasety wykonane? T N *

Czy warunek jest ustalony?

Czy warunek jest ustalony?

Po pobraniu reguły sprawdzane jest czy była już wcześniej określona, jeżeli tak, zwracany jest wynik do warunku poprzedniej reguły. Jeśli był to warunek pobrany z pierwszej reguły, wynik zwracany jest do obiektu faktu i kończony jest proces wnioskowania. W przypadku, gdy reguła nie została wcześniej określona, analizowane są kolejne jej warunki. Gdy warunek nie jest ustalony wykonywane są przypisane do niego fasety w celu pozyskania potrzebnych wiadomości.

Gdy warunek jest spełniony, dedukcji poddawany jest kolejny. Jednakże, gdy wynik jest negatywny, status całej reguły jest „0 – fałszywy” i zostaje zwrócony do warunku poprzedniej reguły lub obiektu faktu. Jeśli warunek nie został określony, analizowana jest kolejna reguła z tablicy tESObjectRuleNext[][]. Status równy „0-fałsz” dla całej reguły w przypadku wystąpienia tylko jednego fałszywego warunku, spowodowany jest opisywanym w rozdziale wcześniejszym domyślnym, obowiązującym operatorem AND między warunkami.

Jeżeli program nie może określić danego warunku w jednym cyklu, następna próba odbędzie się w kolejnym cyklu. Oczekiwanie na odpowiedź od użytkownika lub systemu nie zatrzymuje głównej pętli, a jedynie zaznacza niedokończoną fasetę jako tę, która będzie określała zadanie po kolejnej iteracji pętli.

Rysunek 8.6. Schemat analizy Obiektu Faktu

Obiekt fasety głównej, to przede wszystkim składowe przechowujące informacje

o sposobie pozyskiwania i przeszukiwania danych niezbędnych w procesie wnioskowania. Wyróżnić należy dwa obiekty faset; generujące zapytania do operatora systemu i zapytania lub polecenia kierowane pośrednio przez lokalną bazę danych do fizycznych urządzeń.

Ustaw pierwszą fasetę do analizy n=start

WEJŚCIE

Czy istnieje obiekt fasety N

T

Analizuj n -tą fasetę Faseta wykonana?

Ustaw następną fasetę

n=n+1

Czy wybrano wszystkie fasety (n>4)? N N T T NIE WSZYSTKIE FASETY WYKONANE WSZYSKIE FASTEY WYKONANE WEJŚCIE * * *

Wszystkie odpowiedzi, zarówno udzielone przez człowieka, jak również przez urządzenia mikroprocesorowe, zapisane zostają jako rekordy w specjalnej tabeli bazy danych. To właśnie na ich podstawie powstają obiekty faktu zapisane w wektorze faktów. W bieżącym wątku, cała zawartość wektora może być wielokrotnie przeszukiwana w sposób sprecyzowany przez dwa kolejne obiekty fasety faktów. Kolejność ich wywołania może być dowolna i zależeć od danego przypadku. Często, pozytywny rezultat poszukiwania, kończy się w jednym cyklu, przy użyciu jednej fasety. Jeśli operacja nie powiedzie się sukcesem, uruchamiana jest faseta użytkownika lub faseta bazy danych, a następne przeszukiwanie obiektu faktu zaczyna się od początku według nowego kryterium zapisanego w drugiej fasecie faktu.

Po pobraniu fasety faktu sprawdzane jest czy istnieje timer opóźnienia. Timer jest obiektem, w którym kluczowym elementem jest licznik, dekrementowany w czasie wywołania odpowiedniej funkcji w głównej pętli. Gdy wynik osiągnie wartość zero, w zmiennej obiektu reguły eSObjectRule, pole timer1[ ] przybierze wartość null. Następnie przeszukana zostanie tablica w poszukiwaniu obiektu faktu. Jeżeli operacja się powiedzie, porównywane będą składowe warunku cond1 i cond2, opisana w kolejnym podrozdziale.

Rysunek 8.7. Schemat postępowania podczas analizy fasety faktu.

Po ustawieniu statusu dla warunku, inkrementowana jest zmienna start wskazująca numer kolejnej fasety przeznaczonej do analizy w kolejnym cyklu. Przybierane wartości mieszczą się w zakresie od 1 do 4. Gdy poszukiwany obiekt faktu nie zostanie odnaleziony

* * WYJŚCIE start = start + 1 Faseta faktów WYKONANA Timer opóźnienia ustawiony ? N T Szukaj fakt Czy znaleziono? N Timer przeszukiwania ustawiony? N

Pobierz wartość ustaloną T Faseta faktów NIE WYKONANA WEJŚCIE T Porównaj składowe

warunku cond1 i cond2

Ustaw status dla warunku

sprawdzane jest czy istnieje timer przeszukiwania. Podobnie jak w przypadku timera opóźnienia, gdy jest ustawiony, pętla fasety zostaje przerwana i program powraca do głównej pętli wnioskowania. Jednakże gdy licznik timera osiągnie zero lub nie będzie utworzony, ustawiona będzie wartość domyśla dla warunku. Tego typu timer daje możliwość np. sprawdzenia czy urządzenie w ustalonym czasie odpowie na zapytanie. Następna faseta traktowana opcjonalna, to faseta użytkownika, umożliwiająca przeprowadzenie dialogu z osobą przed konsolą. Pierwszą operacją po odczytaniu parametrów fasety jest sprawdzenie czy pytanie zostało już wcześniej zadane. Jeżeli tak, uruchomiona zastanie metoda analizy odpowiedzi. Gdy użytkownik odpowie na zadane pytanie, wskaźnik „start” zostanie inkrementowany i program wróci do pętli fasety. Jeżeli jednak pytanie nie zostało jeszcze zadane, program upewni się czy panel do komunikacji z użytkownikiem jest wolny i gdy jest to możliwe zada pytanie, wyświetlając go w panelu.

Rysunek 8.8. Schemat przedstawiający sposób analizy fasety użytkownika.

Kolejny sposób organizacji informacji określa faseta bazy danych. Jest to niezwykle ważny obiekt, dzięki któremu będziemy mogli przeprowadzić dialog z fizycznym urządzeniem za pośrednictwem opisanej na wstępie bazy danych. W rzeczywistości opisywana faseta generuje zbiór informacji, na podstawie której utworzony zostanie rekord i zapisany w lokalnej bazie danych.

* * Jest odpowiedz od użytkownika ? T N start = start + 1 Faseta użytkownika WYKONANA Faseta użytkownika NIE WYKONANA WEJŚCIE

Czy jest wolny panel pytania?

T Zadaj pytanie Czy pytanie tej fasety

było już zadane N T

WYJŚCIE

Pobierz fasetę UŻYTKOWNIKA

Rysunek 8.9. Schemat przedstawiający sposób analizy fasety bazy danych.

Każdy rekord będzie odczytany przez program ConfigNetRs i wysłany za pośrednictwem Servera LNS do sieci LON. Następnie wskazany węzeł LON roześle pakiety do urządzeń kontrolno pomiarowych. W odpowiedzi otrzymamy kolejny rekord na podstawie, którego utworzony będzie obiekt faktu. W zależności od potrzeb można taką odpowiedz wykorzystać w procesie wnioskowania, ustawiając opisaną wcześniej fasetę faktu.

Na każdy wysłany pakiet informacji, system reaguje, zapisując odpowiedź do tabeli

DevResp. W tym momencie specjalnie utworzona kwerenda zbiera komplet informacji

z tabel DevReq (zapytanie) i DevResp (odpowiedź), która traktowana jest podobnie, jak tabela dynamiczna DevChange. Rolą kwerendy jest zestawianie pytania i odpowiedzi w jednej tabeli. Gdy pojawia się rekord kwerendy zostaje odczytany i na jego podstawie utworzony nowy obiekt faktu.

Rysunek 8.10. Pola tabeli DevResp – przechowują odpowiedzi na zapytania z tabeli DevReq.

Wykorzystanie kwerendy pozwala na szybszy dostęp do potrzebnych danych. Dzieje się tak dlatego, że informacje wymagane z poziomu systemu ekspertowego zapisane są częściowo w tabeli z pytaniami oraz w tabeli z odpowiedziami. Wymagało by to podwójnego przeszukania tabel DevReq oraz DevResp. Dodatkowo odpowiedzą w postaci

obiektu faktu zajmuje się inna faseta.

Czy Dane zostały dodane? Dodaj dane do kolejki

T

Faseta bazy danych NIE WYKONANA start = start + 1

Faseta bazy danych WYKONANA

N

WEJŚCIE

WYJŚCIE

Pobierz fasetę BAZY DANYCH

Rysunek 8.11. Kwerenda ReqResp - grupująca informacje z tabel DevReq i DevResp.

W dwuwymiarowej tablicy „int statusCond[ ][ ]” należącej do obiektu reguły, druga kolumna przeznaczona jest do przechowywania aktualnego numeru wykonywanej fasety. Status reguły może być określony po wykonaniu wszystkich czterech faset. Najważniejszym zadaniem podczas wykonywania kolejnych faset jest doprowadzenie do sytuacji, w której warunek będzie mógł być sprawdzony dzięki podstawieniu wartości do zmiennych z zapisu skryptowego. Wartości te mogą pochodzić z obiektu faktu pozyskanego poprzez fasety faktu.