A címben szereplő betűszóra a mai napig nincs, a tartalmát teljes egészében visszaadó, a köztudatban is egységesen, széles körben elterjedt, magyar nyelvű kifejezés. A “kezelőfelület” az eredeti szó jelentésénél jóval kevesebb, az “ember-gép kapcsolat” pedig sokakban egész más asszociációkat vonz. A lakossági célú felhasználás esetén - talán épp ezért - szinte teljesen ismeretlen, az iparban pedig máig az angol szóhármas kezdőbetűinek együttese a használatos. Ugyanez a helyzet a ‘High Performance’ előtag esetén, aki mégis hallott már róla, az általában valamilyen futurisztikus, főként a tudományos-fantasztikus filmekben látott, HUD eszközökre gondol. A valóság azonban ettől meglehetősen távol áll.
Néhány éve egy fejlesztő kollégánk iránymutatásával léptünk rá arra az útra, amely a felhasználói felületek tervezése során egyre inkább tudatosan és célzottan alkalmazza a High Performance HMI paradigmát. A kezdeti botladozásokból, kísérleti megoldásokból mára lassan kialakul egy továbbra is folyamatosan fejlődő, de már viszonylag stabil alapokat magáénak tudó rutin, amelynek mentén az új generációs HMI rendszereinket fejlesztjük.
Habár a számos ipari automatázálási termék hirdeti a dobozán nagy betűkkel kiemelten az “out of the box” megoldásokat, mégis könnyen belátható, hogy egy implementációs gyakorlatot nagyon nehéz (ha nem lehetetlen) “becsomagolni”. Elsajátítható, mérnöki szolgáltatásként megvásárolható, de kész, kódolt termékek között maximum a megvalósítást megkönnyítő segédeszközök kaphatóak. Ugyanakkor tény, hogy nagyon sok gyártó kínál mára olyan komplex könyvtárakat termékei mellé, melyek használatával kevesebb gyakorlati tapasztalat mellett is jó eredmények érhetőek el.
A következőkben néhány gondolatban, a teljesség igénye nélkül röviden összegeznénk azokat a tapasztalatokat, jellemző kihívásokat vagy hibákat, amelyekkel az elmúlt pár év során találkoztunk és amelyek leginkább megnehezítették egy-egy projekt során a HMI fejlesztést.
Általános, mondhatni a témától független probléma, hogy ha a beruházói oldalról él is a megvalósítani kívánt rendszer esetében az életciklus alapú megközelítés, ennek a tervezés vagy nem képezi részét, vagy nem tulajdonítanak neki kellő jelentőséget, holott a végeredmény szempontjából talán ez a legkritikusabb lépés (erről bővebben korábbi "Tervezni? Kell!" c. cikkünkben olvashat). Nincs ez másként a HMI esetében sem. A tervezést és kivitelezést egységes keretek között tartó, dokumentált rendszer szükséges, mely részletezi az alapvető direktívákat, a struktúrát, a hierarchiát, ismerteti az alkalmazandó / alkalmazható technikákat, színeket, stb. Enélkül még akkor is kétséges a siker, ha egy projekten nem több (különálló) kivitelező dolgozik, nagyobb volumenű, szerteágazó munkák esetében pedig hiánya egyenes út a nem megfelelő minőségű végtermékhez, azaz végső soron a kudarchoz. Fontos megérteni és belátni, hogy az ennek megalkotásához szükséges idő és költségráfordítás tudatosítása és érvényesítése valamennyi fél elemi érdeke. A számos területen egyre elfogadottabbá váló agilis fejlesztési módszertan alkalmazása csak abban az esetben ajánlott, ha annak helyes használatában a résztvevőknek gyakorlata van és az ezzel ideális esetben együtt járó projekt-kultúrát magukénak vallják.
A GE web HMI megoldása is High Performance HMI alapelveit követi
A HPHMI módszertana az egyes elemek/képernyők implementációján felül nagy hangsúlyt fektet az azok hatékony használatára közvetlenül vagy közvetve hatással lévő tényezőkre. A lehető legteljesebb ergonómia kulcsfontosságú a végeredmény tekintetében. Ha például a beviteli felület esetén a felhasználási terület sajátosságai miatt kizárólag a touch screen használata a megengedett, akkor annak
megválasztása mindenképp úgy kell történjen, hogy valamennyi, kizárólag ezen a felületen végrehajtható (vagy rutinszerűen ott végrehajtott) feladathoz kapcsolódó funkció kényelmes és átlátható kezelését lehetővé tegye.
Ezt nehezíti, hogy a tervezés során sokszor nem áll rendelkezésre minden olyan információ, amely ezen kérdések eldöntéséhez szükséges, illetve - mivel a legtöbb esetben a nagyobb “mozgástér” (nagyobb képernyő, stb.) kisebb-nagyobb költségtöbbletet jelent - a beruházói oldal húzódozik ezek alkalmazásától, sokszor nem gondolva ennek hosszútávú hatásaira.
Szinte minden esetben, amikor meglévő rendszerek leváltását vagy felújítását tűzte ki célul a beruházó, előbb utóbb felmerül a kérdés, mi az a “helyes gyakorlat” melyet változtatás nélkül érdemes átmenteni, megvalósítani az új HMI esetén, és mely területeken szükséges részleges vagy teljes módosítás. A kérdés nehéz, hiszen számos aspektusból vizsgálható, és ennek eredménye a legritkább esetben ad egyértelmű választ. A vizualizálni kívánt folyamatra nézve általában a legnagyobb rutinnal rendelkező végfelhasználók (operátorok) számára sokszor kényelmetlenség és potenciális hibaforrás a megszokottaktól való bármilyen eltérés, nem beszélve az áttervezéshez szükséges időráfordításról, így nagyon gyakran elvárás, hogy az az új HMI kinézete “as-is” egyezzen meg a korábbival. A kétségtelen tények mellett ugyanakkor egy áttervezés magában hordozza egy (kezelési) folyamat revízionálásának lehetőségét, melynek során az évekig kényszerűségből eltűrt hibák kivezethetők, továbbá az iparban használatos eszközök és (az ezekre alapozó) mérnöki gyakorlatok jelentős változáson mentek keresztül, melyek kiaknázása jelentősen üzleti előnyt jelenthet a hatékonyság vagy a megbízhatóság így elért növelésével.
A tervezési/kivitelezési folyamat legnehezebb és talán legtöbb kihívást jelentő fázisa, amikor a végfelhasználói és az alkalmazás-fejlesztői oldal próbálja (sokszor a projekt vélt érdekében) saját álláspontját a másik kárára érvényesíteni, holott éppen ezek szinergiája a kívánatos. A probléma gyökere általában az, hogy nem beszélik egymás nyelvét. A végfelhasználó (operátor, stb.) érti a folyamatot, érti annak technológiáját és függőségeit ellenben nincs tisztában a folyamat-felügyeleti (SCADA, DCS) rendszer elsősorban technikai korlátaival, összefüggéseivel. Az alkalmazásfejelsztő érti ezeket, de a folyamatra vonatkozó kellő szakismeret és/vagy helyi sajátosságok ismerete nélkül nem képes adaptáni, illeszteni azt. Az egyetlen helyes út a konszenzus: Párbeszéd, melynek során a felhasználó a folyamatról alkotott mentális modellje szerint írja le azt a működést, melyet a fejlesztőnek a frontend oldalon szimulálnia szükséges, elfedve mindazt ami a tényleges megvalósításhoz technikailag szükséges. Elengedhetetlen, hogy mindkét oldalról olyan személyek vegyenek részt ebben, akik az adott feladatra nézve kellő kompetenciával rendelkeznek.
Egy általunk, már a High Performance HMI elvek szerint elkészített felület
A tervezés során számtalanszor szembesülünk azzal, hogy - legtöbbször erőforrás vagy idő hiányában - a végfelhalsználó nem tudja, vagy nem akarja pontosan végiggondolni, a folyamat során, melyhez az adott rendszert tervezzük, mely adatok milyen módon, esetben és prioritásban fontosak a számára. A ma kapható szoftvereszközök szinte mindegyike tartalmaz olyan “varázslókat”, melyekkel “fogd és dobd” elven, másodpercek alatt megjeleníthető egy adatforrás aktuális (vagy akár historikus) értéke, ráadásul szokás - főleg marketing oldalról - ezeket a lehetőségeket tévesen a termelékenység kulcsaként, arra vonatkozó példaként kiemelni, holott ez maximum annyiban igaz, hogy egy gyakorlott fejlesztő munkáját egyszerűsítheti, ellenben gyakorlatlan felhasználó esetén magában hordozza annak a vélt rutin tévhitére alapozott magabiztosságnak a kockázatát, amely aztán technikai vagy egyéb téren nem megfelelően kivitelezett rendszert eredményez, illetve a valós fejlesztői munkát alul értékelté teszi.
Minden képernyőn pontosan annyi és olyan adat megjelenítése szükséges, amely mellett az a felhasználó szempontjából nézve még átlátható, egyértelműen “egy szempillantás alatt” értelmezhető a folyamatra nézve számára releváns információt tartalmaz.
A jól megtervezett struktúra és hierarchia, valamint az adatforrások (elsősorban technológiai szempontból való) pontos ismerete ennek szükséges, de nem elégséges feltétele.
A projekt határidők mindenütt szűkre szabottak, ritka, hogy az átfogó, részletes tesztelésre a kellő idő rendelkezésünkre álljon, már ezért is érdemes a projekt kivitelezése során végig úgy fejleszteni, hogy a teszt fogalmát és lépéseit (különböző formákban) abba beépítjük. HMI tervezés esetében a leggyakrabban az “End to End” módszertan szerint dolgozunk, mindamellett, hogy az esetlegesen a felületek mögött futó kódok esetén más, “unit test” eljárások is szóba kerülhetnek. Sokszor a fejlesztő és a teszteket végrehajtó személye ugyanaz, mely még akkor sem szerencsés, ha a tesztelés célja kizárólag a kódolási/működési hibák kiszűrése, ha pedig a “Usability” szempontokat is figyelembe kívánjuk venni, akkor kifejezetten kerülendő. Már a fejlesztés kezdeti szakaszaiban (a fejlesztő-eszközök segítségével, vagy akár egy normál méretű papírlap és ceruza használatával) percek alatt, tényleges kódhátteret nem tartalmazó, de a majdani vizuális megjelenésbeli elképzeléseinket körvonalazó képernyőminták bemutatásával is jelentős eredmények érhetőek el. A felhasználót arra készteti, hogy végiggondolja a folyamatot, jelezze, ha valamit nem ért, nem tart jónak, a fejlesztő pedig láthatja hogyan közelíti a felhasználó az általa készített felületet: milyen bejárási sorrendet tart, hogy kísérel meg használni elemeket, hol akad el, mely elemek értelmezése során bizonytalanodik el, milyen hibákat vét, milyen (téves) következtetéseket von le, stb.
A fenti néhány pont messze áll akárcsak a témához kapcsolható címszavak listájának felsorolásától, mégis a tervezés/kivitelezés során való szem előtt tartásukkal komoly előrelépés érhető el. Mint megoldásszállító nem szabad megfeledkeznünk arról a tényről, hogy a tényleges végfelhasználó egyetlen kapcsolata a majdani rendszerrel a HMI. A mögöttes rendszer hibamentes és stabil működése olyan elvárás, amelynek való megfelelés alapvetőnek tekinthető. Amíg öt-tíz évvel ezelőtt a felhasználói élmény - mint szempont - az ipari alkalmazások területén még elhanyagolható, másodrendű tényező volt, mára ez a helyzet megváltozott.
Ha a felhasználó számára az általunk tervezett kezelőfelület használata kényelmetlen, frusztráló, az azzal történő munkája során bizonytalan, nem hatékony, akkor minden valószínűség szerint a komplett rendszert fogja negatívan megítélni,
ami mind az alkalmazott környezetnek, a terméknek, mind pedig a rendszerintegrátornak komoly kockázatot jelent a jelenleg ebből a szempontból egyre inkább erősödő, számos alternatív megoldást kínáló piaci versenyben.