Modul SYS_ICTDATA třída ICT_ReadDataModule.cs

Základní popis funkce pracoviště

Pracoviště SYS_ICTDATA je spuštěno jako služba na aplikačním serveru (v TSE je to adresa 172.16.2.208). Funguje jako zprostředkovatel dat mezi pracovišti typu ICT a databází výsledků testů Kompass. Na pracovišti ICT se načte panel do xTrace a proběhnou standartní kontroly (PartExistCheck, RoutingCheck, GS, atd) následně se panel zasune do stroje a spustí se testování. Na počítači běží vedle našeho pracoviště také software pro zpracování dat ze stroje a následného zapsání výsledků do databáze. Pracoviště čeká na dokončení testu (message - Čekám na výsledek testu č.X). Pozn. na pracovišti ICT je možné opakované testování. V tomto stavu se služba opětovně dotazuje databáze na výsledky testů a po načtení výsledků dojde k zpracování do formátu Json a následnému odeslání pracovišti ICT, které daná data zapíše již do naší databáze (konkrétně tabulka Part_Data sloupec ProcessData), která jsou vidět v rodném listu jak panelu, tak jednotlivých dílů na panelu.

Stav před updatem (srpen/září 2019)

Pokud došlo k přerušení připojení mezi službou a databází, tak se pracoviště o tomto stavu nijak nedozvědělo a operátor mohl dále pracovat. Bohužel samozřejmě pracoviště ICT zůstalo "viset" ve stavu Čekám na výsledek testu č.X a po následném timeoutu došlo k chybě. Služba SYS_ICTDATA neuměla přiřazovat chyby k jednotlivým dílům podle dat v detailech testů a většina chyb tak zůstala u prvního dílu tj. všechny chyby se uložily do procesních dat k prvnímu dílu na panelu.

Stav po updateu

Pokud dojde k odpojení služby od databáze, tak dojde k odeslání zprávy na pracoviště ICT, kde je ve skriptu modul DeviceErrorChecker, který, jak již název napovídá, kontroluje stav zařízení a umí reagovat i na chyby odeslané ze služby a v případě výpadku připojení zablokuje práci na pracovišti. Dále se upravilo přepočítávání dílů na panelu podle katalogového parametru PCBDirection a zpracování dat z databáze (konkrétně metody getTestResult a ReorderTestResults). Pozn. všechny metody a katalogové parametry jsou podrobně vysvětleny v dalších kategoriích.

PCBDirection

PCBDirection je katalogý parametr nadefinovaný u produktu a určuje seřazení PCB ve skutečnosti vs seřazení dílů v xTrace. Může nabývat hodnot číslo, číslo, číslo, ... kde musí odpovídat počet indexů celkovému počtu PCB na panelu nebo stačí Default, kde následně nedochází k žádnému vnitřnímu přepočítávání pozic a reálné idnexy odpovídají indexům v xTrace. Ukázka nadefinované hodnoty: 4,8,12,16,20,24,28,3,7,11,15,19,23,27,2,6,10,14,18,22,26,1,5,9,13,17,21,25 Když si představíte tuto hodnotu jako pole, kde jednotlivé buňky jsou oddělené čárkou, odpovídají xTraceovému indexu PCB v panelu a hodnota v dané buňce odpovídá reálné pozici PCB na panelu. Například první buňka má hodnotu 4 to znamená, že seriové číslo 1924906586015113AUSEKF00-V010400.01 je ve skutečnosti na 4 pozici. Tato relace je dobře viditelná na rodném listu výrobku v kategorii Procesní data, kde jsou vidět například výsledky testů z pracoviště ICT.

Důležité tabulky v databázi Kompass

Pro nás jsou důležité pouze tabulky HISTORY a EVENTS. V tabulce HISTORY jsou zaznamenány obecná data testů jednotlivých PCB na panelu (našemu OID zde odpovídá KEYHIST) a v tabulce EVENTS jsou již detaily testu daného PCB tj. diagnostické zprávy, naměřené hodnoty, atd. (opět řízeno sloupcem KEYHIST)

Důležité metody

V této kategorii jsou zmíněny všechny důležité metody ze třídy ICT_ReadDataModule.cs

GetLastKey

Tato metoda je první z "opravdové" komunikace mezi pracovištěm ICT a službou SYS_ICTDATA. Pracoviště si od služby vyžádá ID testu a služba provede dotaz na databázi Kompas konkrétně na tabulku HISTORY a vráti hodnotu KEYHIST jako uint.

GetNewDataByBarcode

Metoda GetDataByBarcode je standartně volána pracovištěm ICT po načtení seriového čísla dílu. Provede se kontrola, jestli vůbec daný díl existuje. Následně se načte produkt tohoto dílu a také se načte hodnota katalogového parametru produktu PCBDirection. MySQL dotazem se z tabulky HISTORY (databáze Kompass) se natáhnou výsledky testů pro všechny PCB na panelu a uloží se do datového objektu DataTable metodou mySQL.FillTable. Důležité sloupce pro dotažení dat jsou SERIAL_NUM (=seriové číslo ve formátu SN panelu.pořádové číslo dílu, např 1924906586015113AUSEKF00-V010400.01) a KEYHIST (označuje ID testu). Unvitř metody jsou volány getTestResult a ReorderTestResults (tyto metody jsou vysvětleny níže). Jelikož je metoda volána ihned po načtení panelu na pracovišti ICT, tak může dojít ke stavu, že služba nemůže ještě vyčítat výsledky z databáze. Toto je ošetřeno opětovným voláním metody, dokud nevrátí data ve formátu XML zpět pracovišti.

GetDatabyBarcode

Jediný rozdíl mezi touto metodou a GetNewDataByBarcode je, že GetDataByBarcode umí najít starý výsledek testů. Pozn. nikdy se mi GetDataByBarcode nepodařilo zavolat a ani nevím, jak se volá.

Pozn. obě následující metody jsou volány uvnitř getTestResult a mají spíše pomocný charakter, jelikož provádějí konverzi dat.

DataRowToICTTestResult

Provede jednoduchou konverzi mezi DataTable dtHistory a třídou ICTTestResult. Postupně na všechny řádky se zavolá Convert.To hodnoty z dataTable do property třídy ICTTestResult.

DataRowToICTTestDetail

Jedná se o obdobný případ jako DataRowToICTTestResult. Provede se konverze mezi dtEvents a ICTTestResultDetail, kde dtEvents je naplněn dotazem do tabulky EVENTS.

Tabulka EVENTS obsahuje detaily testů jednotlivých PCB na panelu, a proto je dotaz řízen pouze parametrem KEYHIST. Podle záznamů v této tabulce rozlišujeme různé typy testů a podle nich se chováme k datům odlišným způsobem. Více je vysvětleno v getTestResults. Důležité sloupce jsou KEYHIST, DIAGMESS a VALUE. KEYHIST můžeme chápat jako ID testu daného PCB. Při analýze dat je vhodné si nejprve načíst data z tabulky HISTORY a dále se řídit podle KEYHIST, protože v tabulce HISTORY vidíme vztah mezi KEYHIST a SERIAL_NUM => vidíme KEYHIST daného dílu. Ve sloupci DIAGMESS jsou možné různé typy dat podle typu testu (důležité! typ testu nemusí být stejný pro celý panel a ani pro jedno PCB. To znamená, že u jednoho PCB můžou být výsledky ze všech typů testů a my se musíme rozhodovat až podle dat) např. SW1 a SW2 - PCB_5, Zener not tested, Not tested, PNEU sepnuti PCB1 atd.

getTestResult

Spolu s metodou ReorderTestResults se jedná o jedny z nejdůležitějších metod celého modulu, a proto se budu snažit vysvětlit co nejpodrobněji funkčnost metody. Na začátku metody se nadefinuje regulární výraz, který kontroluje hodnotu DIAGMESS. Nadefinuje se List resultList. Tento seznam výsledků je na konci metody předán jako parametr do metody ReorderTestResult a dále je zformátován do JSONu a přeposlán pracovišti ICT. V cyklu naplníme seznam výsledky z HISTORY (DataTable dtHistory - vstupní parametr metody). Uložíme si výsledek testu prvního PCB do boolovské proměnné isFirstTestResultPass (výsledek testu P potom true) a přepíše se výsledek testu na P. Podle každého záznamu v resultList se provede dotaz na tabulku EVENTS a naplní se DataTable dtEvents. Opět se provede konverze dat tentokrát metodou DataRowToICTTestResultDetail. Zkontroluji jestli sloupec VALUE není roven nule a není null. Je-li podmínka splněna, tak otestuji hodnotu dříve nadefinovaným RegExem. Když hodnota odpovídá RegExu, tak si z ní vytáhnu číslo PCB a výsledek testu daného PCB přepíši na F a detail testu připíšu k tomuto záznamu v resultList. Když DIAGMESS nebude odpovídat regulárnímu výrazu, tak přepíšu výsledek testu prvního PCB na F, pouze když byl výsledek testu prvního dílu F a právě se dívám na detaily testu prvního dílu (podmínka if (!isFirstTestResultPass && pcb == resultList[0]) ). Proč? U jednoho typu testu se všechny chyby připisují k prvnímu dílu na panelu => v cyklu procházím všechny detaily testu a kontroluju, jestli se jedná o chybu automaticky přiřazenou k prvnímu dílu nebo se jedná o chybu prvního dílu. Chyby typu SW1 a SW2 - PCB_5 jsou zřejmé, že patří k jinému dílu. V Tomto případě konkrétně k pátému dílu na panelu (v regexu je groupa, do ktere se ulozi hodnota a tu pak snížím o jedna a tim dostavam index). Vezme se tedy pátý (respektive čtvrtý, jelikož se list indexuje od 0), přepíše se výsledek testu na F a daný detail se připíše k testu PCB (ve tříde ICTTestResult je properta ICTTestResultDetail).

ReorderTestResults

Zde se provádí přeskládání výsledků z listu resultList (vstupní parametr metody je návratová hodnota getTestResult). V první řadě se zaloguje hodnota již dříve načteného katalogového parametru PCBDirection. V případě, že je hodnota parametru Default, tak se s výsledky nic neděje a jen se zeserializují na JSON a odešlou pracovišti ICT. Je-li hodnota jiná než Default, tak se zkontroluje zda odpovídá počet testů a počet indexů v katalogovém parametru PCBDirection. Tato kontrola probíhá metodou SetError. Podmínka je sice nastavená na directionSplit.Length == resultList.Count ovšem před celým SetError je !. Pozn. bylo by možná vhodné tuto podmínku a volání metody přepsat, aby byla lépe čitelná. V případě, že se nerovná directionSplit.Length == resultList.Count, tak se zaloguje message a vyvolá exception. Cyklem se prochází hodnoty na jednotlivých pozicích v PCBDirection a každá tato hodnota se kontroluje dalším voláním metody SetError. Konkrétně se provede int.TryParse (hodnota PCBDirection na dané pozici se konvertuje na 32-bit signed int), zkontroluje se, zda není hodnota vyšší než počet výsledků (hodnota by mohla "ukazovat" na index mimo panel) a jestli není záporná hodnota. V případě, že jakákoli podmínka z výše uvedených není pravdivá, tak se opět zaloguje message a vyvolá exception. Když všem podmínkám vyhovuje, tak se do indexu určeného hodnotou PCBDirection vloží první (respektive nultý) záznam - řádek reorderedList[pcbPosition - 1] = resultList[position++]. Po dokončení tohoto cyklu se se returne přeskládaný list a ten se následně zeserializuje a odešle.

Podmínky pro zapsání dat z SYS_ICTDATA do procesních dat dílu

Výsledek testu dílu musí být F a VALUE v detailu testu nesmí být NULL. Ve třídě ICTResultChecker.cs je metoda savePCBResult, ve které se vyhnodnocuje, jestli se jedná o OK/NOK díl. V případě, že je díl OK, tak se uloží procesní data bez komponent (tj. detail testu z tabulky EVENTS). Když je díl NOK, tak se při zapisování komponent (=detail testu) kontroluje hodnota VALUE != null.

Výsledky testů v HISTORY mohou mít dvě formy. Za prvé můžou být všechny detaily chyb připsané k prvnímu dílu respektive k prvnímu testu (záleží na PCBDirection) nebo jsou připsané k jednotlivým dílům.

Ukázka výsledků testů (tabulka HISTORY)

TODO! - najit v HISTORY, kdy je F enom u prvniho dilu

Obr.č.2 - druhý typ výsledků v tabulce HISTORY Zde lze vidět výsledky v databázi v tabulce HISTORY, kde mohou být výsledky testů F u jiných dílů než jen u prvního.

Ukázka detailů chyb připsaných k prvnímu dílu (tabulka EVENTS)

Obr.č.3 - detail výsledku testu prvního dílu s chybami pro jednotlivé díly a s chybou prvního dílu (KEYEVENT = 37398516) Zde vidíme, že se při testování zjistili 2 typy chyb. Za prvé Test SW2 a SW3 a za druhé Test SW2 a SW3 - PCB index. Ve výsledných procesních datech tedy máme chybné díly specifikované v DIAGMESS a první díl, jelikož chyba Test SW2 a SW3 neodpovídá regexu, ale má VALUE != null.

Obr.č.4 - detail výsledku testu prvního dílu s chybami pro jednotlivé díly Zde vidíme ideální výsledky stejného typu testů jako v obr.č. 1. Detail obsahuje pouze chyby typu TLACITKO - PCBčíslo - SW. Tento DIAGMESS tedy odpovídá regulérnímu výrazu definovaném v metodě getTestResult a také VALUE není null. Tím pádem se všechny tyto chyby přiřadí k dílům nadefinovaným v DIAGMESS a výsledek testu těchto PCB se přepíše na F.

!TODO! - popsat podminky pro zapsani procesnich dat na pracovisti ICT - popsat duvody podminek