Átlagosan negyedévente készítünk új VISION verziót, de a kibocsátás időpontját befolyásolhatják a hozzánk beérkező felhasználói kérések is (néha pár hét telik el csupán). Ezentúl van jó pár komponens a VISION-ben, amiket a legjelentősebb komponens fejlesztőktől (pl. DevArt) szerzünk be szerződéses alapon. Ezek a külső fejlesztők is hasonló ütemben készítenek új változatokat a komponensekből, amiket mi tesztelés után építünk be a rendszerbe, a róla szóló dokuementumot pedig a szokásos helyén, a VISION fejesztések leírásai között tesszük közzé.

A VISION programon - kibocsátás előtt - egy ún. gyári hozzáférésű (factory acceptance) tesztet futtatunk le. A teszt jellemzően 72 órán át ketyeg pár összetett tesztalkalmazást felhasználva (demo, receptkezelő, energiamenedzsment, RG stb.). Az eljárás lényege, hogy a tesztalkalmazásokban - a VISION saját demo funkcióját használva - egy tesztsorozatot rögzítünk (képváltások, parancsok, adatbázis műveletek stb.) és ezt körbefuttatva azt vizsgáljuk, hogy a rendszer mindig a kívánt állapotba kerül-e, ill. ismétli-e az állapotát a tesztsorozat végén. A teszteket ciklikusan futtatjuk. Közben vizsgáljuk még a hálózati funkciókat, a web-et, a processzor hasznátot és azt, hogy van-e memória szivárgás.

Még annyit, hogy ilyen teszteket bárki készíthet a saját alkalmazásával is. Mi gyakran próbáljuk rávenni erre a rendszerintegrátorainkat. Ha valaki esetleg nem tudná, először a programot demo üzemmódba kell kapcsolni (Beállítások - demo üzemmód), majd a Ctrl R, P, Q stb. parancsokkal felvételt indítani, ill. visszajátszani - akár ciklikusan is.

Rendszeresen készítünk ilyen vizsgálatokat, összehasonlításokat. Párról részletes dokumentáció is készült. Így pl.az Ignition és a VISION összehasonlításáról, vagy a DMS és a Microsoft Power BI összevetéséről.

Emellett készült táblázatos összehasonlítás is a funkciók összevetésére.

Több, mint 300 rendszerintegrátor van Magyarországon, külföldön kb. egy tucat.

Ezt nagyon nehéz megmondani, de több ezer. Az új licence megrendelések száma kb. 200 évente. De ezekben sok az ún. hálózati licence, ami egyszerre több (max. 15) klienst is tartalmazhat.

A következő kép a kinyomtatott licence szerződéseink lefűzött dokumentuma, kb. 1500 oldal, 8 év megrendelései (2012-2020):

A VISION programot Delphi-ben fejlesztjük (Embarcadero). Létezett C-ben írt változata is UNIX-ra, de ez a verzió a múlté. Csak azért említem, mert a UNIX-os változat elkészítése miatt készült anno egy Pascal - C keresztfordító, amit még ma is használunk, sőt be van építve a VISION-be. Amikor ui. váltunk a C és a Pascal nyelvek között, akkor pont ez a keresztfordító lép működésbe.

Miért Delphi? Egyszerű a válasz: ez jelenleg a leghatékonyabb, a legnagyobb teljesítményű natív kódú fejlesztő rendszer a világon. Mivel pedig a teljesítmény meghatározó fontosságú egy SCADA rendszer esetében, nagyon más választásunk nincs - ha nem akarunk a teljesítmény vonatkozásában kompromisszumot kötni.

Természetesen. Ebben az összefoglalóban is megtalálható az előadások egy része, de az egyes fejezetek elején található link is rámutat. Ott megtalálható az összes, amihez az előadók is hozzájárultak.

A legelső előadásom pont erről szól. A VISION X10 egy modern SCADA rendszer, ilyen rendszerből pedig jelenleg nagyon kevés van. Pont az ellenkező tendencia figyelhető meg: a rendszerek hihetetlen sebességgel avulnak el, mert nem bírnak lépést tartani az IT térhódításával. És legtöbbször pont a nagynevű ipari cégek szenvednek tőle. Neveket nem írhatok, de nem nehéz kitalálni. Vannak e jelenségnek, vagyis a SCADA rendszerek leszakadásának más objektív okai is, amiket mi, a fejlesztők jól ismerünk, de pont ezért, s mert üzleti érdeket is sértenek, nem kotyoghatók ki. A lényeg, hogy az előadásomban vázolt leszakadási folyamatnak nagyon is objektív okai vannak (a letöltött anyagban megtalálhatók az internetes hivatkozások). Azt mindenesetre leszögezhetjük, hogy a VISION X10 nem ebbe a körbe tartozik, sőt nála dinamikusabban fejlődő rendszer se nagyon van.

Hogy mit hoz a jövő, nehéz megmondani. Az érdeklődés azonban és emiatt a fejlesztés is töretlen. Hogy mennyire, érdemes talán a következő kérdést is elolvasni!

A második előadásomban részletesen bemutattam a VISION program fejlesztési stratégiáját, aminek alsó szintjén a VISION script alapú rendszermodulok (rendszer funkciót ellátó modulok) állnak. Ezek fejlesztésében nagyon sokan vesznek részt, sok aktív rendszerintegrátorunk. Nem véletlenül szentelünk különös figyelmet a VISION alapú VISION fejlesztésnek, vagyis a VISION önfejlesztő képességének. Ma már a szerkesztő funkciók is VISION-ben készülnek, ergo bárki átalakíthatja, továbbfejlesztheti a VISION-t ízlése szerint. A rendszer e téren nyitott forráskódú. A másik ilyen vonal a driver fejlesztés, amiben megint több fejlesztő vesz részt.

Nem akarom persze megkerülni a kérdést, ami az alapszoftvert illeti, s ami a Provicon szűk fejlesztőcsapatának a kezében van jelenleg. Az elmúlt 5 évben azonban jelentős átalakításokat végeztünk annak érdekében, hogy a kód egyrészt egyszerűsödjön, másrészt a fejlesztésbe lehetőleg minél több kollégát és partnercégeket is bevonjunk. Jelenleg a core, ami a VISION-ön belül mindent meghatároz, csupán 20 forrásfájlból áll és összesen 130 ezer sor (nem volt mindig így, a VISION X9-ben ez még több millió sor volt!). Egy-egy nagyobb komponens, amit "as is" alapon az internetről letöltünk, nagyobb ennél. A VISION motor tehát könnyen elsajátítható lett, miközben ez a 20 fájl tartalmazza a fordítót, az összes taszkot, a kommunikációt, az adatgyűjtést, a trendkezelést, a grafikát, de még az energiamenedzsment és DMS feladatokat is. Az átalakítás pont azt célozta meg, hogy a rendszer továbbfejlesztése 20 év múlva is biztosított legyen.

Rengeteg anyag készült ezekről, valamint az együttműködés lehetőségeiről, és már egy tucat tárgyaláson vagyunk túl a fejlesztői kooperáció és a nemzetközi terjesztői hálózat kiépítése terén - nem egy esetben a világ legnagyobb cégeivel. A program és a bemutatott anyagok fogadtatása minden esetben kiváló volt! Néha már zavarbaejtően pozitív volt a fogadtatás! Mi nagyon optimistán tekintünk ezért a jövőbe. Mi több, a rendszer oktatása az egyetemeken és főiskolákon is folyamatos.

De egy képet is megosztanék, ami fellibbenti a fátylat a VISION szintjeiről és belső struktúrájáról, valamint a szándékainkról:

Jelenleg nem működtetünk ilyen szolgáltatást, de többször felmerült már az igénye. Elvileg minden eszközünk megvan hozzá. Kérjük keressen meg bennünket, ha ilyen szolgáltatás kiépítésében szívesen résztvenne!

Jelenlegi tervezetlen módon történő óriási mennyiségben, villámgyors növekedéssel több negatív hatása van az energia hálózatra, kiszámíthatatlan óriási energiatermelés és termelés megszűnése miatt rövid idő alatt.

Igen, a villamosenergia törvényben megjelent, mint fogalom, de a pontos jogai, feladatai, engedélyei még tisztázatlanok, mind vezérlés szabályozás, mind elszámolási szempontból.

Az energiaközösségek témában kb. 18 pilot pályázati projekt fut, aminek eredményeként a jogi és szabályozási környezettel való ütközései fogják megmutatni az un konformitását a jelenlegi rendszerrel és ezután fognak a törvények és a szabályozások módosulni.

Őszintén szólva nem számoltuk össze, de úgy száz körül. A DMS mindenféle dologra használjuk, nem csak SCADA rendszerek riportálására. Készült már okos parkoló rendszer, tehenészet számára cirkuláris gazdaság, menetrendező rendszer, energiamenedzsment rendszer és mérésadatgyűjtő rendszer is - jó sok. De a legérdekesebb felhasználási kör talán mégis a számlafeldolgozás.

2021-től él a törvény, de a 2022. januári szigorítás a covid miatt 2023. januárig lett kitolva, így 2023-tól várható a 2021. év adatainak ellenőrzése.

Természetesen. Az előadásomban bemutattam, hogy a rendszer képes automatikus karbantartási ciklusokat készíteni és működtetni. Az adatok forrása legtöbbször egy SCADA program, ami üzemórát és/vagy mennyiség mérési adatokat produkál. A karbantartás ezután indítható konkrét időhöz vagy ciklushoz igazítva, adott üzemóra után, vagy egy mennyiségi határt elérve. És persze mindezek kombinációja is lehetséges.

Itt a lényeg, hogy egy-egy konkrét feladatkörre készül rendszer szintű(!) megoldás. Ez azt jelenti, hogy magát az alkalmazást már nem kell módosítani, csak konfigurálni. Például a mérőkiolvasó miniSCADA esetén tetszés szerint vehetünk fel az alkalmazás segítségével merőket, ráadásul mindjárt vagy 100 műszerből válogatva és az így elkészített adatbázis tábla alapján a program maga legyártja az összes unitot, a kommunikációt és a unitok belső beállításait - vagyis a végső VISION alkalmazást.

Hasonlóan univerzális a fájlfeldolgozó rendszerünk. Ez a program sem igényel semmilyen módosítást, egyszerűen bekonfigurálható, hogy milyen könyvtárakban keressen és milyen fájlokat. Amihez azután konvertert rendelhetünk, elvégezve az adott fájltípus feldolgozását és az adatok eltárolását akár 6 különböző adatbázisban - automatikusan. A leggyakrabban PDF számlafeldolgozásra használjuk a programot (ld. Piya Csaba előadása), de nagyon hatékony pl. MAVIR XML fájlok feldolgozására is. Hogy mennyire, had világítsam meg egy konkrét példával:

A MÁV-nál mintegy 3300 POD-ból kapunk adatokat (minden nap egy hetet vissza) és vagy 150 mozdony fedélzeti számítógépéből. Ezek átkonvertálására korábban egyik kollégánk .NET célalkalmazást fejlesztett, ami a napi adatmennyiséget 23(!) óra alatt dolgozta fel - hogy érzékelhető legyen, mekkora probléma ez és milyen adatmennyiség. Mármost a VISION miniSCADA rendszerével ez jelenleg 10, azaz tíz másodperc. És már működik 5-ik éve, ami brutális mennyiségű adat. A feldolgozása mégis real-time.

Tehát ahelyett, hogy folyton valami célalkalmazást fejlesztenénk, egy termékkört specifikáltunk a gyakori feladatok univerzális megvalósítására. Ez a miniSCADA.

Adott vállalkozás mennyi embere, mennyi időt tölt a számlák könyvelésével, a számlaadatok kontrolling szempontú (pl. kwh, m3 gáz,..) feldolgozásával, a számlák iktatásával, költséghelyre történő szétosztásával stb. Pl. Megyei jogú város városüzemeltetési cégei fent leírt feladatainak automatizálásával 15-18 ember munkaévet spórol meg. Érdemes megnézni ebből a szempontból Piya Csaba előadását is.

Nagyon sokfélét - attól függően, hogy a számlakonfigurációs programmal milyen adatokat konfiguráltunk be a számláról. Van olyan alkalmazásunk, amelyben a számlán található összes adatot feldolgozzuk. Ez villamosenergia esetén kb. 120, földgáz esetén 80 adat (egységár, korrekciós tényező, tételes díjak, adók, brutto, netto, áfa stb. stb.). Ehhez a full felhasználáshoz készült egy Excel alapú export struktúra, ami leírja a controlling végpontokat, az allokációs mechanizmust és oszlopképletek formájában a számlaadatok feldolgozását. Ezen az alapon aztán a felhasználó olyan bizonylatokat, jelentéseket állíthat elő magának Excel-ben, amilyet csak akar. Program módosítás nem kell hozzá.

Egy másik érdekes alkalmazásunk önkormányzatok számára készül. Speciális prototípus Excel fájlok alapján ún. betöltőket készít a könyvelés és az SAP rendszer számára. Érdekessége az alkalmazásnak, hogy még papír alapú számlákat is képes feldolgozni, bizonyos korlátozásokkal (OCR).

A számlaadatok ezentúl idősoros adatok mellé is betehetők akár a költségeket, akár a mennyiségi adatokat tekintve. Ha ráadásul még mérőkiolvasóval is kombináljuk a rendszert, máris megvan az alap a számla audit elvégzéséhez.