Ipari Ethernet hibadiagnosztika: Wireshark mélyelemzés Modbus TCP és OPC UA protokollokhoz DCS hálózatokban

K: Miért fontos a csomagszintű elemzés a DCS hálózatokban?

Az ipari Ethernet hordozza a folyamatirányítás életvonalát. A Modbus TCP és az OPC UA a leggyakoribb protokollok közé tartoznak – ha a kommunikáció megszakad, a termelés leáll. A Yokogawa CENTUM VP DCS rendszerek a belső üzenetküldéshez a Vnet/IP-t használják, de sok terepi eszköz még mindig a 502-es porton kommunikál Modbus TCP-vel. A Yokogawa VI701 Vnet/IP interfészkártya biztosítja a nagysebességű Vnet/IP gerinchálózati kapcsolatot a CENTUM VP FCS csomópontok számára, míg a Schneider TCSESM083F23F0 ipari menedzselt switch biztosítja a SPAN port tükrözési képességet, amely szükséges a Wireshark csomagfogásához a DCS hálózatokon. A Prosoft PLX32-EIP-MBTCP EtherNet/IP és Modbus TCP protokollhíd gyakori megoldás az EtherNet/IP DCS rendszerek és a Modbus TCP terepi eszközök között – ez a gyakori forrása a késleltetési hibáknak, amelyeket ez az útmutató tárgyal.

K: Mi a Modbus TCP keretstruktúrája, amit ismernem kell?

A Modbus TCP adatokat egy 7 bájtos MBAP fejléc és egy PDU csomagolásában továbbít. A fejléc tartalmaz egy tranzakcióazonosítót, protokollazonosítót (mindig 0x0000), hosszmezőt és egységazonosítót. Egy normál FC 03 olvasási kérés hexadecimálisan: 00 01 00 00 00 06 01 03 00 00 00 0A. Gyakori funkciókódok: 0x03 tartományregiszterek olvasása, 0x06 egyetlen regiszter írása, 0x10 több regiszter írása.

Ha a slave kivételválaszt küld, a funkciókód 7. bitje be van állítva (pl. 0x83 = hiba az FC 03-on). Kivételkódok: 01 = érvénytelen funkció, 02 = érvénytelen adatcím, 03 = érvénytelen adatérték. Ezek a kódok az első diagnosztikai nyomok Wiresharkban.

K: Hogyan működik az OPC UA bináris protokoll Wireshark elemzéshez?

Az OPC UA alapértelmezett portja a 4840. Egy kliens Hello üzenetet küld, a szerver válaszként Acknowledge-et ad, majd a kliens megnyit egy biztonságos csatornát, létrehoz egy munkamenetet és aktiválja azt. Yokogawa környezetekben az OPC UA szerverek gyakran tűzfal mögött futnak – ellenőrizze, hogy a 4840-es port nyitott és elérhető. Titkosított munkamenetek esetén töltse be a szerver privát kulcsát PEM formátumban az Edit → Preferences → Protocols → OPC UA menüpont alatt, hogy valós idejű dekódolás legyen lehetséges az autentikációs hibák és munkamenet-időtúllépések esetén.

K: Hogyan állítsam be a porttükrözést és a Wireshark fogást?

• 1. lépés: Jelentkezzen be az ipari switch CLI vagy webes felületére (Hirschmann, Moxa vagy Cisco IE sorozat). Azonosítsa a PLC-hez vagy DCS vezérlőhöz csatlakozó forrásportot.
• 2. lépés: Állítsa be a SPAN tükrözést: állítsa be a forrásportot a PLC Ethernet portjára, a célportot pedig a diagnosztikai laptopra. Engedélyezze a kétirányú forgalomtükrözést.
• 3. lépés: Nyissa meg a Wiresharkot, válassza ki a tükrözött interfészt, és állítson be egy fogási szűrőt: tcp port 502 or tcp port 4840. Indítsa el a fogást.
• 4. lépés: Hozza létre a hibajelenséget. Hagyja folyni a forgalmat legalább 30 másodpercig.
• 5. lépés: Állítsa le a fogást, mentse .pcapng formátumban. Alkalmazzon megjelenítési szűrőket: kezdje modbus vagy opcua szűrőkkel, majd használja a tcp.analysis.retransmission szűrőt az anomáliák elkülönítéséhez.

K: Esettanulmány — Yokogawa CENTUM VP Modbus TCP időtúllépés?

Egy petrolkémiai üzem időszakos adatvesztést jelentett a Modbus TCP kapcsolatokon. A CENTUM VP DCS 24 terepi adóegységet kérdezett le 500 ms-onként, időnként három-négy adó kiesett a lekérdezési listából. Miután beállították a porttükrözést egy Hirschmann switchnél és két órányi forgalmat rögzítettek, a tcp.analysis.retransmission és Modbus kivételválaszok szűrése több TCP újraküldést mutatott ki bizonyos slave címekre.

Az ok: egy RS-485–Ethernet átjáró firmware hibája miatt csomagokat dobott el nagy terhelés alatt, amikor egyszerre több mint 16 slave válaszolt. Megoldás: frissítsék az átjáró firmware-ét és csökkentsék a lekérdezési csoport méretét 12 eszközre átjárónként.

K: Esettanulmány — Schneider Modicon M580 OPC UA hitelesítési hiba?

Egy vízkezelő üzem SCADA kliens nem tudott OPC UA munkameneteket létrehozni egy tanúsítvány megújítás után. A Wireshark OpenSecureChannel válaszokat mutatott BadCertificateInvalid státuszkóddal. A köztes CA tanúsítvány hiányzott a kliens megbízhatósági tárolójából. A köztes CA hozzáadása és az OPC UA kliens újraindítása után a munkamenetek sikeresen aktiválódtak.

Egy második probléma jelentkezett: az OPC UA Publish kérésekre akár 10 másodpercig nem érkezett válasz. A opcua.service == Publish szűrés TCP zéró ablak értesítéseket mutatott – a Modicon vezérlő CPU kihasználtsága 95% volt. A logika áthelyezése egy másodlagos vezérlőre 200 ms alá csökkentette az előfizetési késleltetést.

Mik a legfontosabb szakértői tippek?

• Soha ne tükrözzön forgalmat olyan portra, amely termelési forgalmat hordoz – ez broadcast hurkot okoz.
• Mindig állítson be fogási szűrőt a fogás megkezdése előtt. Szűretlen fogás egy forgalmas DCS hálózaton kevesebb mint 60 másodperc alatt megtölti az 1 GB-os pufferet.
• Használja a Follow TCP Stream funkciót a teljes kliens-szerver kommunikáció rekonstruálásához.
• Exportálja az anomáliás kereteket hex dumpként a gyártói műszaki támogatás számára. Tartalmazza az időbélyegeket és az interfész információkat.
• Archiválja a .pcapng fájlokat leíró nevekkel (dátum, vezérlőmodell, hiba leírása) a trendanalízishez.

Szerző: Zhang Minghui, ipari automatizálási mérnök, több mint 10 év tapasztalattal PLC, DCS és vezérlőrendszerek területén.