WTCR - Mit csinál az adatmérnök - 2. rész

Mit csinál az adatmérnök - 2. rész

LantiLanti
2012/12/14 12:01

Juhász Szabi írásának folytatása a zengomotorsport.hu oldalról.

Elérkeztünk oda, hogy van egy teljesen felépített adatgyűjtő rendszerünk. Ahhoz, hogy ezek az adatok átláthatóak legyenek, rendszereznem kell őket, azaz a konfiguráció következik. Minden egyes rögzíteni kívánt csatornát célszerű egy beszédes névvel ellátni, amiből azonnal lehet tudni éppen minek az adatait látjuk:

pl.: nTurbo - turbó fordulatszám,

pAirChrg - töltőlevegő nyomás,

tExhaust - kipufogógáz hőmérséklet, stb.

A kisbetűk a csatornák elnevezésében a mindenkori mennyiség egységes jelére utalnak (n-fordulatszám, p-nyomás, t-hőmérséklet), amire a gyorsabb megtalálhatóság miatt van szükség, ugyanis ha nekem egy nyomás adatra van szükségem, akkor elegendő a "p" betűvel kezdődő csatornákat kilistáztatni, így hamarabb rábukkanok a keresett adatra.

Az analóg szenzorok leggyakrabban egy jól behatárolt tartományú feszültségjelet szolgáltatnak, de ha mi a futómű elmozdulására vagyunk kíváncsiak milliméter egységben, ez a "nyers" feszültség jel nem igazán beszédes, tehát át kell formálnunk olyan módon, hogy a rögzített adatok már valós mértékű elmozdulást mutassanak, ezt nevezzük kalibrációnak.

Ezt minden egyes rögzített csatorna esetében el kell végezni, legyen az analóg szenzorjel, vagy CAN üzenet. Ezek után át lehet térni a kijelző konfigurációjára az alapján, ki mit szeretne azon látni. Ez azt jelenti, hogy pl. Norbi számára menet közben lényeges információ a köridő, a legjobb köridőtől való aktuális eltérés, valamint a váltást jelző LED-ek állapota. Ezzel ellentétben Krisztián, a vezető szerelőnk, aki a motor bemelegítését is végzi, azt szeretné látni milyen értéket mutatnak a különféle hőmérsékletek és nyomások, van-e valamilyen rendellenes paraméter, ami hibára utal.

Ugyancsak a kijelzőn jelennek meg különféle hibaüzenetek, figyelmeztetések, valamint riasztások. Az utóbbi két dolog közötti különbség abban rejlik, hogy míg a figyelmeztetés egy adott hibaszint elérését jelzi elő, addig a riasztás már annak elérésről tájékoztat. Például ha a váltóolaj hőmérséklete kezdi elérni az olaj "működésének" határát, megjelenik egy figyelmeztető szöveg a kijelzőn:

- Warning! Gearbox oil temp is high! (Figyelem, a váltóolaj hőmérséklete magas!) -, valamint ezzel egyidejűleg a váltást jelző LED-ek villognak, hogy feltűnőbb legyen a jelzés. Ekkor Norbi rádión jelzi a csapat felé a hibát, és kintről eldöntjük, mit tegyen.

Ahhoz, hogy a rendszer bekapcsolása után ne jelenjenek meg azonnal különféle hibaüzenetek, néhány érték esetében feltételt kell szabni arra vonatkozólag, hogy az mikor van valóban hibás tartományban. Például a motorolaj nyomás esetében a fordulatszámtól kell függővé tenni, hogy az adott érték hibás vagy sem, ugyanis ha csak az olajnyomás érteket adnánk meg figyelmeztető feltételnek, akkor a rendszer bekapcsolása után azonnal jelezne, hogy alacsony az olajnyomás, pedig a motor még nem is jár, ezért meg kell "tanítani" a kijelzőnek, hogy csak akkor jelezzen, ha egy minimum motorfordulat ellenére is egy adott érték alatt van a nyomás.

A rendszer konfigurálásával és az adatok letöltésével még nem ért véget a teendők sora, mivel ezeket az adatokat ki is kell értékelni.

Ahhoz, hogy ez a kiértékelés hatékony legyen, kell egy olyan szoftver, ami személyre szabhatóan képes megjeleníteni a letöltött információkat. Erre azért van szükség, mert ezekből az adatokból dolgozik Bári Gergely a versenymérnök, és én is, de míg Gergő a jármű tényleges viselkedésével kapcsolatos adatokra kíváncsi, én az autó műszaki állapotát ellenőrzöm, azaz minden érték a megfelelő határon belül van, nincs kezdődő vagy tényleges meghibásodás, stb.

Mindketten csak a számunkra releváns adatokat jelenítjük meg, amit úgy érünk el, hogy különféle ún. template-eket (sablonokat) szerkesztünk. Egy-egy ilyen template csoportosítva tartalmaz adatokat aszerint, miként célszerű őket vizsgálni. Például az egyes elektromos szivattyúk áramfelvételéből lehet azok megfelelő működésére következtetni, így egyazon template-en megjelenítve minden ilyen görbét, egyszerre le tudom ellenőrizni az azonos tulajdonságú fogyasztók állapotát. Ha például a váltóolajat áramoltató szivattyú rendben van, de az olaj hőmérséklete mégis magas, az még nem jelent feltétlenül hibás működést, ekkor először a hőmérséklet felfutásának jellegét ellenőrzöm, és ha csak egy rövid időintervallumban volt magas, akkor utána kell járnom szélárnyékban autózott-e Norbi ekkor, és ha igen, valószínűleg ezért emelkedhetett a megszokott érték fölé a hőmérséklet.

Számos ilyen paramétert kell ellenőrizni egy-egy session után, amelyeket sok esetben nem elég csak az eltelt idő függvényében vizsgálni, hanem valamelyik másik jellel egyszerre célszerű megjeleníteni. Ilyen a kijelző esetében is említett motorolaj nyomás alakulása. Ha egy koordináta rendszer X-tengelyén a motor fordulatszámot-, Y-tengelyén a motorolaj nyomását jelenítem meg, akkor a teljes session-ön gyűjtött adatok alapján kirajzolódik az olajszivattyú nyomás-karakterisztikája, amit csak össze kell vetni a szivattyúra vonatkozó katalógusadatokkal és máris kiderül van-e hiba az olajellátással.

Lehetne még folytatni a felsorolást, de úgy érzem, e példák alapján mindenkiben kialakulhat egy kép arról mit is csinál egy Adatmérnök és közelebb kerülhet ahhoz, hogy műkedvelőből műértővé váljon.

FONTOS! Kérlek, állítsd be a Facebook Oldalon az értesítések küldését. Részletek ITT.

Fotó: Zengő Motorsport

Hozzászólások