Nem a Mbps számít: mit nézz egy ipari hálózaton, ha a vezérlés akadozik

Miért nem segít, ha gigabitesre cseréled a switchet?

Ha egy gyártósoron akadozik a vezérlés, az első reflex a "kevés a sávszélesség". Irodai hálózaton ez gyakran igaz. Ipari hálózaton ritkán. A PLC és a HMI vagy a többi vezérlő között apró csomagok mennek: szenzorértékek, állapotok, parancsok, egyenként pár bájt. Az ilyen forgalom a legtöbb helyen összesen is kevés Mbps, így a gigabites uplink önmagában nem old meg semmit.

Az ipari hálózaton három dolog dönt: hány csomagot tud a hálózat kezelni másodpercenként, mennyi idő alatt ér oda egy csomag, és mennyire állandó ez az idő.

Csomag/másodperc: ami a switch valódi korlátja

Egy vezérlő ciklusidejétől függően eszközönként több száz, akár több ezer csomag megy másodpercenként. Ha sok eszköz van egy hálózaton, a forgalom Mbps-ben alacsony marad, csomagszámban viszont jelentős. A switchnek és a routernek minden csomagot fel kell dolgoznia és tovább kell küldenie.

Egy eszköz hirdethet nagy sávszélességet, de ha a csomagfeldolgozó képessége (pps) kicsi, vagy a CPU-ja szoftveresen kezeli a forgalom egy részét, akkor terhelés alatt eldob csomagokat. Egy eldobott vezérlőcsomag egy gyártósoron nem lassulás, hanem hiba.

Mit nézz meg: a switch portjainak eldobási számlálóit (output és queue drop), és azt, hogy a csúcsterhelés idején mennyi a csomag/s érték. Az adatlapon a kapcsolási teljesítmény pps-ben szerepel, nem csak Mbps-ben.

Késleltetés és jitter

Késleltetés: az idő, amíg egy csomag a forrástól a célig ér.
Jitter: ennek a késleltetésnek az ingadozása.

Ciklikus vezérlésnél a jitter gyakran nagyobb gond, mint az átlagos késleltetés. Ha minden csomag mindig ugyanannyi idő alatt ér oda, azt be lehet tervezni. Ha egyszer 1, egyszer 5 ezredmásodperc, a vezérlő időzítése felborul, és a kapcsolat figyelőórája (watchdog) megszakíthatja a kommunikációt, anélkül hogy bármelyik kábel vagy eszköz hibás lenne.

Hol romlik el?

Sok ugrás. Minden routolt lépés újabb feldolgozás. A HMI és a PLC közötti útvonal legyen rövid.
Szoftveres továbbítás. Ahol a forgalmat a CPU kezeli, ott terhelés alatt nő a késleltetés és a szórás. A hardveres továbbítás (L3 switch) kiszámíthatóbb.
Sorban állás. Ha a háttérforgalom (mentés, naplózás, nagy fájlok) ugyanabban a sorban megy, mint a vezérlés, a vezérlés várakozik.
Inline biztonsági eszközök. Minden tűzfal és IPS késleltetést visz be. A mértéke termék- és beállításfüggő, ezért nem érdemes általános számokban gondolkodni: mérni kell.

QoS: forgalom rangsorolása

A QoS (szolgáltatásminőség) azt szabályozza, mi mehet előre, ha torlódás van. A forgalmat jelölni kell, és a hálózati eszközök a jelölés alapján állítják sorba:

CoS (802.1p) a második rétegen, az Ethernet-keret VLAN-címkéjében.
DSCP a harmadik rétegen, az IP-fejlécben (a régi ToS utódja).

Egy ipari hálózatban a szokásos sorrend csökkenő prioritással: kritikus vezérlés, folyamatadat és HMI-frissítés, mérnöki munka és munkaállomás-hozzáférés, rutinfelügyelet és adatgyűjtés, végül a háttérfeladatok, például mentés és naplózás.

Két fontos korlát:

A QoS nem varázsszer. Rosszul tervezett vagy tartósan túlterhelt hálózaton nem old meg semmit. Egy sávot nem lehet szélesebbé tenni jelzésekkel.
Meg kell őrizni a prioritást. Ha egy switch átírja vagy törli a VLAN-prioritást, a vezérlési forgalom elveszíti az előnyét. Profinet esetén a gyártói dokumentáció szerinti prioritásnak kell megmaradnia az egész útvonalon.

A biztonság és a teljesítmény egyensúlya

Itt van egy tipikus feszültség. A szegmentálás routolást igényel, a tűzfal csomagvizsgálatot, az IPS még mélyebb elemzést. Mindegyik késleltetést visz be, miközben a hálózat éppen a késleltetésre érzékeny. Ebből nem az következik, hogy ne védd a hálózatot, hanem hogy tervezd bele az elejétől:

A tűzfalat és a szegmentálást a zónák határára tedd, ne a gyártócellán belülre.
Az időkritikus forgalom maradjon a cellán belül, ahol nem kell routernek vagy tűzfalnak átmennie.
Inline IPS ipari hálózaton csak alapos tesztelés után. Először csak figyelő (IDS) módban.
Élesítés előtt mérd meg a jelenlegi késleltetést és jittert, utána újra. Így tudod, mit okozott a változtatás.

Hogyan mérheted meg úgy, hogy nem zavarod a gyártást?

Aktív szkennelésre és terhelésgenerálásra nincs szükség, sőt, ipari szegmensen nem is szabad. A passzív mérés elég:

Rögzítsd a forgalmat SPAN porttal vagy TAP-pel, a rögzítő interfésznek nem lehet IP-címe (a részletek ebben a cikkben).
Nézd meg a terhelést csomag/másodpercben. Wiresharkban a Statistics > I/O Graphs, a függőleges tengely csomag/s.
Mérd a ciklikus forgalom érkezési időközeit. Szűrj egy eszköz forgalmára, majd nézd a frame.time_delta_displayed értéket. A szórás a jitter.
Olvasd ki a switch eldobási számlálóit. Csak lekérdezés, semmi átkonfigurálás.
Írd fel a normál értékeket. Hibakereséskor csak ahhoz képest lehet bármit rendellenesnek mondani.

Az IT és OT hálózat különbségéről szóló cikkben leírtam, miért más az ipari hálózat prioritása. Ez a cikk azt mutatja meg, hogyan látszik ez a számokban.

Összefoglalás

Az ipari hálózat teljesítményét nem a Mbps adja, hanem a csomagszám, a késleltetés és főleg annak állandósága. A QoS segít a rangsorolásban, de a kapacitást nem pótolja. A legfontosabb szabály ugyanaz, mint a hibaelhárításnál: előbb mérj passzívan, aztán nyúlj bármihez.

Ha a gyártósorotokon időnként akadozik a kommunikáció, és nem derül ki, hol, az ipari hálózat felmérése és hibaelhárítása passzívan, a termelés zavarása nélkül megrendelhető.