( zither | 2021. 02. 04., cs – 21:01 )

Ez az egész, amit írtál egy tök egyszerű feladat, csak le kell vetkőzni a web programozói vénát, mivel webes eszközökkel nem lehet ezt a feladatot jól megoldani. A webes eszközök nem valós idejű és időkritikus alkalmazásokra készültek, a kommunikációjuk ehhez lassú. Jellemzően a szkript és GS-s nyelvek is lassúak és kiszámíthatatlanok valós idejű és idő kritikus rendszerek készítéséhez (szóval php-t és társait is buktad).

Amit szerintem tenned kell:

  1.  megnézed, hogy a jelenleg gyártósorban lévő plc-kből lekérdezhető-e a kívánt adat. Ha nem akkor csinálsz rá valami érzékelőt, de valószínűleg a jelenlegi rendszer is képes lehet rá.
  2. Az adatokat begyűjtöd (akár a gyártósori PLC-ről, akár érzékelőről) és valamilyen kompakt programmal beszórod egy dinamikus memória tömbbe bináris formában. Ugyan itt értékeled ki (közel valós időben) a bejövő adatokat, illetve valósítod meg ez alapján a szükséges riasztási eseményeket. Továbbá a memóriában gyűlő adatokat (amiket már kiértékeltél és csak historikusak) bulkban letoldod valami tárolóra. Akár bármilyen SQL szerverre is hatékonyan leküldhető. Ez lesz az első réteged. Ha old-school vagy ezt megírod C-ben, ha nagyon modern akarsz lenni, akkor mondjuk rustban, ha villamos mérnök vagy, akkor meg ladderben (létra) PLC-re. 
  3. Most előveszed az általad állandóan emlegetett web szervert, php-t, és a többi lassú kacatot, amikben csinálsz még egy front-endet, ami a vezetés által igényelt színes-szagos grafikonokat és riportokat legenerálja az elmetett adatok alapján.

Az architektúra lényege: a számlálást és a beavatkozást (mivel ezek idő kritikus dolgok) megcsinálod egy gyors kompakt rendszerben. A begyűjtött adatokat pedig elmented későbbi felhasználásra. Az elmetett adatok alapján pedig a webes szerveren megvalósíthatod a színes szagos de lassú dolgokat. Így szétválaszthatod a számlálás és a hiba esetén történő gyors beavatkozást (jelzést, a kezelő fele) a számlálás eredményeként keletkező statisztikáktól és nyomon követési adatoktól. Az előbbi idő kritikus (ha lemaradsz a darabról, már nem tudod megszámolni), az utóbbi meg ráér, csak túl sok adatot mozgat (a managernek tök mindegy, hogy egy cache rebild miatt két másodperccel később jön meg a riport). Ez egyben azt is jelenti, hogy az alsó rétegnek a lehető legegyszerűbbnek és butábbnak kell lennie. Neki nem kell tudnia, hogy milyen darabot gyártotok, elég azt hogy jön a darab és mennyi, illetve nem jön, pedig kéne (hibajelzés). Az összes többi adatot (pl.: melyik gyártósor mikor mit gyárt) a felsőbb rétegben rakod mellé.