Ipari hálózati topológiai hibák: vonalas, csillag-, gyűrű- és fa topológiájú hálózati hibák Schneider Modicon- és Phoenix Contact-rendszereken

Miért kritikus az ipari üzemidő szempontjából a hálózati topológia ismerete?

Minden ipari hálózatnak van egy topológiája, és minden topológiának megvan a saját hibajelensége. A legtöbb mérnök azonban csak egy leállás során ismeri meg ezeket. Én egy palackozósoron tanultam meg őket a nehezebb úton. Egy Schneider Modicon M580 PLC három Altivar frekvenciaváltót fűzött fel láncba Modbus RTU-n keresztül. A VFD-2 egyik laza kapcsa megszakította a kommunikációt a VFD-3 felé, miközben a VFD-1 továbbra is megfelelően lekérdezett. A sor négy órára leállt, mert senki sem bízott a topológiai térképben. Ezért tanulmányozza, hogyan hibásodnak meg a vonalas, csillag-, gyűrű- és fa topológiák, mielőtt a hiba Önre talál.

Melyek a vonalas topológia gyakori lezárási és hosszproblémái?

A vonalas topológia az eszközöket az első csomóponttól az N csomópontig láncba rendezi. Minimális kábelezést igényel, ezért kisebb, kevésbé kritikus alkalmazásokhoz illik. Ugyanakkor rejtett buktatókat tartogat. Először is, a lezáró ellenállást. Egy RS-485 Modbus RTU-szegmens mindkét fizikai végén 120 ohmos lezárást igényel. Egy Profibus DP-szegmenshez saját lezáróhálózat szükséges: a megfelelő buszcsatlakozók használatával 220 ohm a vezetékpárra kapcsolva, 390 ohmos előfeszítő ellenállásokkal, amelyeket csak az első és az utolsó eszközön szabad bekapcsolni. Egyszer három bekapcsolt lezárást találtam ugyanazon a fővonalon. A visszaverődések véletlenszerűen tönkretették a kereteket, és CRC-hibák árasztották el az M580 kivételnaplóját. Másodszor, a távolságot. Egy Modbus RTU-fővonal 9600 baud sebességnél körülbelül 1200 méterig működik megbízhatóan. Ha a sebességet 115 200 baudra emeli, a biztonságos hossz drasztikusan csökken. Végül ne feledkezzen meg a hibák aszimmetriájáról. A kikapcsolt eszköz általában átengedi a láncot. Egy zárlatos kapocs viszont az egész vonalat megszakítja.

• 1. lépés: Járja végig fizikailag a fővonalat, és papíron rögzítse minden eszköz helyét.
• 2. lépés: Ellenőrizze, hogy a lezárás pontosan a két fizikai végponton aktív, máshol pedig sehol.
• 3. lépés: Mérje meg a buszt vonalvizsgálóval, és ellenőrizze az előfeszítő feszültséget, valamint a jelminőséget.
• 4. lépés: Vesse össze a baudsebességet a teljes kábelhosszal, és határérték közeli állapot esetén csökkentse a sebességet.

Miért függ a csillag topológia teljes mértékben a központi switch állapotától?

A csillag topológia minden eszközt egyetlen központi switchhez csatlakoztat. A hibakeresés egyszerű, a bővítés pedig könnyű. A központi eszköz azonban egyetlen hibapontot jelent. Ha a switch meghibásodik, vele együtt az egész cella leáll. Egy olyan üzemben dolgozom, ahol egy Phoenix Contact FL SWITCH menedzselt switch szolgál egy Modbus TCP kommunikációs modulon keresztül csatlakozó Modbus TCP-cella központjaként. A switch működőképes maradt, de egy hibásan konfigurált port egyszer elárasztotta a hálózatot egyetlen IO-Scanner multicastforgalmával. Néhány másodpercen belül minden Modbus TCP-kliens időtúllépést jelzett. Ráadásul egy nem menedzselt switch még ezt a hibát sem képes jelenteni. Ezért minden termelési szempontból fontos helyen használjon menedzselt switcheket. A multicastforgalom korlátozásához engedélyezze az IGMP-sznoopingot. Végül állítsa be a portstatisztikákat, és jelezze a növekvő hibaszámlálókat még azelőtt, hogy a felhasználók észrevennék a problémát.

• 1. lépés: Cserélje le a termelési cellákban a nem menedzselt switcheket menedzselt egységekre.
• 2. lépés: Engedélyezze az IGMP-sznoopingot, és hetente kérdezze le a portstatisztikákat.
• 3. lépés: Zárolja a nem használt portokat, és állítsa be kézzel a sebességet és a duplex módot.
• 4. lépés: Minden kritikus cellához tartson a polcon egy beprogramozott, hideg tartalék switchet.

Hogyan konfigurálható megfelelően a redundancia gyűrű topológiában?

A gyűrű topológia minden eszköz számára két kommunikációs útvonalat biztosít. Normál működés közben az egyik út logikailag blokkolva marad, így a gyűrű vonalként viselkedik. Kábelszakadáskor a gyűrű az alternatív útvonalon keresztül helyreáll. A helyreállás azonban teljes mértékben a helyes konfigurációtól függ. A Phoenix Contact menedzselt switchek támogatják az MRP-t, vagyis az IEC 62439-2 szabványban rögzített Media Redundancy Protocolt. Az MRP-ben pontosan egy switchet kell gyűrűmenedzserként, MRM-ként konfigurálni, míg az összes többi kliensként működik. Helyes konfiguráció esetén a helyreállás 200 ezredmásodpercen belül megtörténik. A Schneider Modicon M580 saját redundáns gyűrűt kínál a távoli IO-leágazásokhoz. Ezért minden üzembe helyezéskor ellenőrizze a menedzseri szerepkört. Egyszer olyan gyűrűt vizsgáltam, amelyen két különböző kivitelező két menedzsert konfigurált. A hálózat hónapokig hibátlanul működött. Ezután egy kihúzásos esemény duplikált csomagokat és elárasztást váltott ki, és az egész szegmens instabillá vált. Ne feledje a gyűrűk második törvényét sem: az első szakadás után redundancia nélküli vonallá válik. A hibát azonnal javítsa ki.

• 1. lépés: Erősítse meg, hogy minden gyűrűszegmensben pontosan egy MRP-menedzser található.
• 2. lépés: Az üzembe helyezés során tesztelje a gyűrűt úgy, hogy szándékosan kihúz egy kábelt.
• 3. lépés: Mérje meg a helyreállási időt, és vesse össze a folyamat tűréshatárával.
• 4. lépés: Állítson be riasztást a gyűrű újrakonfigurálási eseményeire, hogy a hibás kábeleket még aznap kijavíthassák.

Hogyan előzhetők meg a broadcastviharok hierarchikus fa topológiában?

A fa topológia kiválóan skálázható nagy üzemekben. A cellaswitchek területi switchekhez csatlakoznak, a területi switchek pedig az üzemi gerinchálózatot táplálják. A hierarchia azonban függőségeket hoz létre. Ha egy magasabb szintű switch meghibásodik, minden alatta lévő eszköz elérhetetlenné válik. Ráadásul egy ártatlannak tűnő bekötési hiba az egész fát leállíthatja. Két switch közé helyezett plusz patchkábel Ethernet-hurkot hoz létre. A broadcastkeretek vég nélkül keringenek, és a broadcastvihar néhány másodperc alatt túlterheli az összes switchet. Láttam, amikor ez egy teljes csomagolócsarnokot állított le. A PLC-k és a HMI-k véletlenszerűen elvesztették a kommunikációt, miközben minden hardver egészségesnek tűnt. Ha a Spanning Tree Protocol túl lassan reagál, vagy egyáltalán nincs konfigurálva, a vihar győz. Ezért engedélyezze a gyors spanning tree funkciót a hierarchiában, és fizikailag címkézzen fel minden uplinket.

• 1. lépés: Engedélyezze az RSTP-t minden hierarchikus Phoenix Contact switchen, megfelelő prioritásokkal.
• 2. lépés: Címkézze fel és színkódolja az összes uplinkkábelt a véletlen keresztbekötések megelőzésére.
• 3. lépés: Figyelje a portonkénti broadcastcsomagokat, és riasztson a hirtelen kiugrásokra.
• 4. lépés: Zárja a switchhelyiséget, és minden patchmunkához kérjen változtatási jóváhagyást.

Összegzés és gyakorlati tanácsok

A topológiai hibák tervezési hibák, amelyek a lehető legrosszabb pillanatban válnak láthatóvá. Először ellenőrizze minden RS-485-fővonal lezárását és hossz-tartalékát. Másodszor, egységesen használjon menedzselt switcheket, és olvassa le a statisztikáikat még azelőtt, hogy az üzemeltetők elolvasnák a riasztásokat. Emellett minden redundáns gyűrűt teszteljen úgy, hogy az üzembe helyezés során fizikailag kihúz egy kábelt. Soha ne feltételezze azonban, hogy egy üzembe helyezéskor hibátlanul működő gyűrű továbbra is egészséges: minden switchcsere után ellenőrizze a menedzseri szerepkört. Ezért tartsa naprakészen a topológiai rajzokat, és kezelje őket szabályozott dokumentumként. Végül gyakorolja csapatával az útmutatóban szereplő hibaszimulációkat. A gyűrű viselkedését tervezett teszt során érdemes megtanulni, nem pedig hajnali 3 órakor, egy leállás közben.

Szerző: Xu Jiawei ipari automatizálási mérnök, több mint 10 év tapasztalattal PLC-, DCS- és irányítástechnikai rendszerek terén.