Monitoring je mechanizmus, sluziaci na detekciu stavov zariadeni vo vozidle, vyhodnotenie ziskanych stavov, zaznamenanie detekovanych chyb, zobrazenie vodicovi a odoslanie na dispecing (prip. do ineho systemu).
Cely system je postaveny na tom, ze kazdy aplikacny ovladac zariadenia vytvara subor s informaciou o aktualnom stave zariadenia (nemusi ist priamo o ovladac zariadenia). Tento subor je monitorovany procesom monitor, ktory spaja podla suboru monitor.xml zariadenia do jednej “databazy”. Tam sa spajaju udaje aj z inych zariadeni (napr. stavy zariadeni z citacky). Nad tymto databazovym suborom bezi proces analyzer, ktory podla suboru msv.xml urcuje co je a co nie je chapane ako chyba (kazdy zakaznik to moze chciet inak). Ak analyzer vyhodnoti stav ako chybu, podla nastavenia sa tato sprava poskytne pripojenym klientom (napriklad plugin dispecerskeho, alebo aplikacia).
Stavovy subor zariadenia je ulozeny v ramdisku (zvycajne /tmp/ alebo /tmp/slaveXY/). To kam sa tento subor bude ukladat a ako sa bude volat je nastavene v HwConfig-u (atribut StatFile). V sucasnosti ma 30B a obsahuje zakladne informacie o SNR zariadenia, stave (32bit), pozicii a case zosnimania. Pre podrobny popis je potrebne si pozriet dokumentaciu tlaciarne a dokument:
DokumentaciaTD/VyvojovyUsek/VyvojSW/TransFare/OnboardComputer_Slave_Common/Monitoring_#lastVersion.doc
Program monitor zbiera udaje podla suboru monitor.xml, ktory sa skusa vycitat z ”/opt/emtest/var/spool/incoming/monitoring/monitor.xml” ak sa nepodari ho najst tak z ”/opt/emtest/etc/monitor/monitor.xml”. Tento subor sa sklada z dvoch zakladnych casti. Prva je StatusFiles, ktora hovori o jednotlivych syboroch, ktore sa maju brat do uvahy, druha CommonSettings obsahuje vseobecne nastavenia (napr. cas obnovovania). Zaznamy zariadeni su clenene a mozu obsahovat aj podriadene zariadenia (napr. oznacovac na citacke). Na to je potrebne mysliet, inak sa stav zariadeni, ktore su na citackach nebude brat do uvahy. Monitor nepotrebuje ku svojej praci nastavenia podla HwConfig-u a teda ho ani necita.
Subor monitor.xml moze byt spolocny pre vsetkych zakaznikov, lebo este neurcuje co je a co nie je chyba. Nevyhodou je len to, ze sa spomaluje praca s databazovym suborom ak je v systeme vela zariadeni a dochadza k nadbytocnym zapisom na SDcku.
Monitor uklada udaje o stave (aj historiu) do adresara ”/opt/emtest/var/lib/states/”.
Štruktúra súboru:
<?xml version="1.0" encoding="iso-8859-1"?>
<monitor>
<StatusFiles>
<File DeviceType="20" CheckTime="10000" Path="/tmp/StatusGps.dat" Bitmap="0xFFFFFF"/>
<File DeviceType="7" CheckTime="10000" Path="/tmp/StatusPrinter.dat" Bitmap="0xFFFFFF"/>
<File DeviceType="12" CheckTime="10000" Path="/tmp/StatusSlave01.dat" Bitmap="0xFFFFFF"/>
<File DeviceType="12" CheckTime="10000" Path="/tmp/StatusSlave02.dat" Bitmap="0xFFFFFF"/>
<File DeviceType="75" CheckTime="10000" Path="/tmp/StatusWifiOnBoard.dat" Bitmap="0xFFFFFF" MonitoringDelay="60"/>
<!--
DeviceType viz. monitoring.doc,
CheckTime je v ms. Ak =0 zariadenie sa nekontroluje
Path je cesta k typu zariadeni -> obsahuje wildkey znaky!
Bitmap hovori o bitoch co sa beru do uvahy pri zmene stavu.
-->
</StatusFiles>
<CommonSettings refreshTime="10000"/>
</monitor>
kde:
Program analyzer obsahuje pomerne sofistikovany mechanizmus, ktory na zaklade stavov jednotlivych zariadeni zozbieranych monitorom, na zaklade konfiguracie toho co dane vozidlo obsahuje a na zaklade konfiguracie toho co zakaznik pozaduje za chybu vyhodnoti ci je system v poriadku alebo v chybe. Informaciu o stave kontrolovanych zariadeni je mozne ziskat pripojenim sa na port 4950 zariadenia, kde bezi analyzer. Takto sa tam momentalne pripaja hlavna aplikacia (trieda EMonitoring, obhospodarujuca stav zaraideni v menu a zobrazovanie hlasok vodicovi) a plugin dispecerskeho (odosielanie na portal).
Subory ktore bere analyzer do uvahy pri rozhodovani su:
Analyzer vyuziva HwConfig.xml na dve veci. Najprv pomocou neho vie ake ma mat vozidlo zariadenia, potom ho pouziva na mapovanie nazvu zariadenia a cisla zariadenia (ktore je v msv.xml). Zariadenie je povazovane za pouzivane vo vozidle, ked ma Status=“1” (analyzer_7 vie vyhodnotit aj novy atribut Enable).
HwConfig.xml sa vytvara pri starte programom configvehicle, ktory sa spusta este pred hlavnou aplikaciou a je vytvarany z maximalistickeho suboru HwConfigDefault.xml vynechanim niektorych jeho nepouzivanych riadkov. To co je alebo nie je v danom vozidle je urcene v subore HwConfEEPROM.xml.
Subor msv.xml je vyuzivany analyzerom na definovanie chyboveho stavu zariadenia, na urcenie kontrolovanych typov zariadeni a na urcenie dolezitosti stavu zariadenia (kedy sa ma posielat). Zariadenie moze byt vo viacerych (aj chybovych) stavoch. Cislo stavu daneho zariadenia je tiez definovany v tomto subore.
Subor sa sklada z troch hlavnych sekcii.
Prva settings urcuje pre ake zobrazovacie zariadenie (DisplayTargetType) je pre dane cislo zariadenia (DeviceNumber - cislovanie je v ramci suboru) a dany stav (StateOrder - cislo stavu zariadenia) dolezite o tomto stave zariadenia notifikovat (StateImportanceType). Napriklad ked chceme aby sa na tlaciarni (zariadenie 7) chyba rezacky (stav 4) poslal do portalu dispecingu (DisplayTargetType 2) bude v sekcii nasledovny riadok:
<monitor DeviceNumber="7" StateOrder="4" DisplayTargetType="2" StateImportanceType="4" />
Druha sekcia devices urcuje mapovanie medzi cislom zariadenia (DeviceNumber - z prvej sekcie), cislom zariadenia pod akym identifikuje zariadenie aplikacny ovladac (DeviceType), nazvom zariadenia v HwConfig-u (HwName) a textom pre zobrazenie (DeviceName). Casto byva polozka DeviceNumber zhodna s polozkou DeviceType, nie vzdy je to vsak mozne. Nazov zariadenia zobrazujuci sa vodicovi (DeviceName) musi byt prelozeny v danom jazyku. Nazov spajajuci HwConfig.xml a msv.xml musi dbat na velke a male pismena.
Tretia sekcia states obsahuje zoznam stavov pre dane typy zariadenia (DeviceNumber). Stav s cislom (StateOrder) je definovany kombinaciou chybovej a logickej masky (ErrorMask a LogicalStateMask). ErrorMask urcuje ktory bit / kombinacia bitov stavu sa ma uvazovat, LogicalStateMask urcuje ci sa ma brat pre zapnuty bit chybovej masky ako platna hodnota 0, alebo 1. V pripade ze je stav aktivny zobrazi sa prisluchajuci text (polozka StateDescription), ktory musi byt uz prelozeny v spravnom jazyku.
Odporucam pozriet si kontrolu nastavenia monitoringu.
MHD konfiguracia v sebe zahrna specifika v podobe spracovavania statusovych suborov z priecnikov /tmp/slaveXY nasledovne: