Kliknutím na „Prijať/Prijať všetky“ súhlasíte s ukladaním súborov cookies na vašom zariadení na zlepšenie navigácie na stránke, analýzu používania stránky a pomoc pri našom marketingovom úsilí. Viac informácií nájdete v našich Zásadách ochrany osobných údajov.
MožnostiOdmietnuťPrijať
22.11.2024

Komunikácia - Ethernet/IP

Peter Humaj

IT Specialist

Časť jesene v uplynulom roku 2018 som strávil implementáciou Ethernet/IP protokolu do D2000 KOM procesu. Tento blog popisuje kľúčové vlastnosti protokolu a pridáva niekoľko subjektívnych názorov.

 

Úvod

 

V protokole Ethernet/IP znamená IP industrial protocol. Podľa Wikipédie je Ethernet/IP jeden z najrozšírenejších komunikačných protokolov v USA. V začiatkoch bol vyvíjaný firmou Rockwell, v súčasnosti existuje združenie ODVA (Open DeviceNet Vendor Association), ktoré vyvíja protokol CIP (Common Industrial Protocol) a jeho konkrétne adaptácie na zbernice Ethernet (Ethernet/IP), CAN (Device Net) , fieldbus (ControlNet) a štvorvodičovú priemyselnú zbernicu odvodenú od RS485 (CompoNet).

 

V súčasnosti existujú aj aplikačné rozšírenia CIP protokolu – CIP Safety (komunikácia odolná voči výpadkom), CIP Motion (riadenie pohybu) a CIP Sync (veľmi presná časová synchronizácia na úrovni menej ako 100 ns).

Združenie ODVA má viac ako 300 členov, sú medzi nimi firmy ako Rockwell, Honeywell alebo Schneider Electric.

 

Normy

 

Štandard CIP má takmer 1300 strán. Definuje nielen protokol, ale popisuje aj objektový model, knižnice objektov, atribútov a profily zariadení.

 

Štandard Ethernet/IP má ďalších cca 160 strán a obsahuje konkretizácie CIP protokolu a objektov pre zbernicu Ethernet.

Norma CIP obsahuje definície niekoľkých desiatok tried objektov (Class). V rámci jednej triedy (napr. Analog Input) môže byť definovaných niekoľko inštancií (Instance), ktoré sú určené svojim číslom. A každá konkrétna inštancia má definované atribúty (Attribute), opäť adresované číselne. O každom z nich norma hovorí, či je povinný alebo voliteľný, či je určený na čítanie alebo na zápis, a definuje aj jeho dátový typ. Atribúty môžu byť jednoduché typy (celočíselné, reťazce, reálne čísla a iné), polia hodnôt, štruktúry aj polia štruktúr.

 

Takže štandardná adresácia obsahuje trojicu Class/Instance/Attribute.

 

Navyše, každá trieda má ešte tzv. atribúty triedy (Classwide Attributes). Tieto sú spoločné pre všetky objekty v rámci triedy. Tieto atribúty sa adresujú zadaním nulového čísla inštancie.

 

Norma myslí jednak na rozšíriteľnosť, jednak na potreby jednotlivých výrobcov, takže definuje číselné intervaly tried aj atribútov, ktoré sú určené pre ďalšie rozšírenie protokolu ako aj pre triedy a atribúty špecifické pre jednotlivých výrobcov (vendor-specific).

 

.. a komplikácie

 

Aké problémy a komplikácie bolo nutné riešiť pri implementácii protokolu?

  1. Nezávislé atribúty v každej triede

Každá trieda má nezávisle definovaný zoznam atribútov . Pokiaľ teda chceme implementovať konfiguračný nástroj, je nutné pre každú triedu udržovať zoznam možných atribútov (v skutočnosti zoznamy dva – atribúty inštancií a atribúty triedy). Ak to porovnám s protokolom BACnet – tam bol zoznam atribútov jeden (s takmer 200 položkami) a pri definícii typov objektov (ekvivalent tried v protokole Ethernet/IP) sa iba vymenovalo, ktoré atribúty sú povinné a ktoré voliteľné.

  1. Nespojité číslovanie atribútov

CIP norma definuje pre viaceré triedy objektov atribúty takým spôsobom, že vynecháva niektoré čísla atribútov (niekedy z historických dôvodov, niekedy ako rezervu pre ďalšie rozšírenie). Niekedy je ale vynechaných atribútov pomerne veľa. Napr. pre triedu Motion Axis Object je definovaných niekoľko desiatok atribútov, ktorých čísla sú z medzi 1 a 1585. Na porovnanie, BACnet protokol má atribúty číselne pekne zoradené za sebou.

  1. Revízie objektov .. a iné

Väčšina tried (ale nie všetky) v štandarde CIP má aj atribút Revision. V závislosti od tohto atribútu môžu mať objekty rôzne atribúty, prípadne ich atribúty majú odlišné číslovanie. Okrem revízií sa atribúty v niektorých prípadoch líšia pre jednotlivé podtriedy (Subclasses) jednej triedy alebo závisia od iných špecifík konkrétnych tried.

 

  1. Typy atribútov

Pre niektoré atribúty je typ atribútu závislý od niečoho iného. Napr. v triede S-Analog Sensor Object je atribút Value štandardne INT, ale môže byť aj iný, podľa hodnoty atribútu Data Type, ak je tento atribút podporený. Takže v konfiguračnom dialógu je nutné pre každý prípad implementovať možnosť nastavenia typu atribútu.

 

EIP_1

Obr 1: pomerne komplexný konfiguračný dialóg meraného bodu pre Ethernet/IP protokol.
V hornej tretine sa konfiguruje štandardná adresácia pomocou Class/Instance/Attribute.

 

Služby

 

Norma definuje štandardné služby (CIP Common Services ) – najdôležitejšie pre nás boli Get_Attribute_Single (0x0E) a Set_Attribute_Single (0x10), ktoré sú určené na čítanie a zápis atribútov.

 Podobne ako pri triedach objektov a pri atribútoch, aj tu je definovaná rezerva pre rozšírenie štandardu aj pre služby špecifické pre jednotlivých výrobcov.

 

Browsovanie

 

Užitočnou vlastnosťou pri implementácii protokolu je možnosť vyčítať zoznam objektov pri  funčnej komunikácii. Protokoly ako OPC, OPC UA alebo BACnet browsovanie podporujú. Ako je na tom Ethernet/IP?

 

Zoznam tried sa dá jednoducho vyčítať z atribútu Object List triedy Message Router. To je skvelé - ale čo zoznam inštancií v jednotlivých triedach? Väčšina tried obsahuje classwide atribúty Number of Instances a Max Instance, ktoré obsahujú počet inštancií resp. číslo maximálnej inštancie. Komplikácie: štandardne sú tieto atribúty typu UINT (16-bitové číslo bez znamienka), v niektorých triedach sú ale typu UDINT (32-bitové číslo bez znamienka).

 

EIP_2

Obr 2: browsovanie tried a inštancií.
Môžete si všimnúť že trieda File Object má dve inštancie, číslo 200 a 201.

 

Teória verzus prax

 

Keď som podporil štandardné čítanie a zápis a otestoval ho voči softvérovému serveru libiec61850, vyskúšal som zapožičané Micro820 vyrábané firmou Rockwell.

 

Nasledovalo prekvapenie: zoznam podporených tried bol pomerne krátky a nevedel som v ňom nájsť ani hardvérové vstupy/výstupy, ani softvérovo definované premenné. Čo s tým?

 

Po konzultáciách s nadštandardne ochotnými špecialistami z firmy Rockwell som zistil, že Rockwell išiel vlastnou cestou – prakticky nepoužíva štandardnú adresáciu Class/Instance/Attribute, ale vlastnú tzv. Symbolickú adresu (textovú adresáciu objektov). Navyše, namiesto štandardných služieb Get_Attribute_Single a Set_Attribute_Single používa na čítanie a zápis vlastné, proprietárne služby:

  • Read Tag Service [0x4C]
  • Write Tag Service [0x4D]
  • Read Tag Fragmented Service [0x52]
  • Write Tag Fragmented Service [0x53]

Tieto služby na rozdiel od štandardných služieb ponúkajú viacero vylepšení:

  • Umožňujú špecifikovať počet elementov poľa pri čítaní a zápise, takže je možné pracovať aj s časťou poľa
  • Vyžadujú špecifikovať typ hodnôt pri čítaní a zápise, takže nedôjde k chybnej interpretácii dát.
  • Umožňujú prácu aj s veľkými poľami („Fragmented“) verzie príkazov, keď sa polia čítajú resp. zapisujú po častiach (fragmentoch).

Čo osobne pokladám za prekvapujúce a zvláštne – prečo najväčší  implementátor Ethernet/IP protokolu používa proprietárne služby na čítanie a zápis? A prípadne, ako je to u iných výrobcov – budeme musieť pre každého z nich implementovať jeho proprietárne služby?

 

Odpoveď na prvú otázku treba hľadat v histórii (a v diskusných fórach). Adresácia pomocou textových mien je síce užívateľsky príjemná, ale má menší výkon a je vyžaduje prenos väčšieho množstva bajtov pri adresácii. Preto sa v minulosti používala menej a existovali aj iné, nezdokumentované služby, ktoré Rockwell používal na komunikáciu medzi svojimi zariadeniami, prípadne medzi zariadeniami a svojím OPC serverom RS Linx. Aká je výhoda proprietárnej a nezdokumentovanej služby? Umožňuje jednak vývoj vlastného OPC servera, ktorý bude pochopiteľne rýchlejší a výkonnejší ako niečo, co môže ponúknuť konkurencia, a jednak úpravy a optimalizácie týchto nezverejnených služieb bez toho, aby bolo nutné tieto zmeny vopred oznamovať (a navyše sa tak pokazí kompatibilita s konkurenčnými riešeniami).

 

Podľa viacerých diskusných vláken nájdených na internete došlo asi pred piatimi rokmi k opusteniu proprietárnej služby umožňujúcej čítanie dát z konkrétneho pamäťového offsetu a k zavedeniu nových CIP služieb umožňujúcich prevod symbolického mena na tzv. Symbol Instance ID. Zmena sa týka firmware CompactLogix verzie 21 a novších.

 

Na porovnanie – aj BACnet používa štandardne podobnú číselnú adresáciu (Object Type+Instance) a Siemens (na rozdiel od iných výrobcov) používa textovú adresáciu objektov. Ale na prevod mena objektu na kombináciu Object Type+Instance používa štandardom definovanú službu protokolu BACnet Who-Has.A na čítanie a zápis sú už použité štandardné služby, ktoré objekt adresujú štandardne, pomocou Object Type+Instance. Takže v tomto prípade bolo nutné iba podporiť prevod mena objektu – a navyše aj tento prevod bol súčasťou štandardu BACnet.

 

Rockwell a browsovanie

 

Keďže už vieme, že Rockwell používa proprietárne služby na čítanie a zápis objektov so symbolickou adresáciou, ponúka sa ďalšia otázka – je podporované browsovanie týchto objektov?

 

Našťastie odpoveď znie áno. V dostupnej dokumentácii je popísaný spôsob zistenia objektov so symbolickými menami. Ide opäť o proprietárnu službu, ktorá vracia textové názvy objektov, ich typy a aj 32-bitové ID každého objektu. Jedná sa o už spomenuté Symbol Instance ID, ktoré je možné používať pri adresácii a tak komunikáciu optimalizovať – prenos ID a zrejme aj vyhľadávanie podľa neho je rýchlejšie ako práca s textovými identifikátormi. Bohužiaľ, na PLC typu Micro820, ktoré sme mali k dispozícii, tento optimalizovaný mód nebol podporený a dalo sa pracovať iba s textovými adresami. Až ďalšie testované zariadenie, CompactLogix 5370 Controller, umožnilo otestovať túto optimalizáciu.

 

V D2000 verzii 12 je teda podporená práca so symbolickou adresáciou, optimalizovaná práca s použitím Symbol Instance ID ako aj browsovanie objektov s textovou adresou.

 

EIP_3

Obr. 3: browsovanie premenných v režime symbolickej adresácie firmy Rockwell

 

Záver

 

Protokol Ethernet/IP je široká téma, ktorej sa tento blog iba zľahka dotkol vo vybraných bodoch. Vďaka podpore výrobcov je a zrejme aj ostane široko používaným protokolom.  Počas implementácie ovládača tohto protokolu do systému D2000 som sa nemohol ubrániť jeho porovnaniu  s inými štandardami ako BACnet alebo OPC. Mám dojem, že na rozdiel od týchto štandardov sa v Ethernet/IP výraznejšie presadzujú proprietárne prístupy, ktoré nakoniec spôsobia, že je nutné si zakúpiť od konkrétneho výrobcu aj OPC server a komunikovať cezeň. Zároveň sa tým znižuje interoperabilita zariadení a sťažuje možnosť ich náhrady za zariadenie od konkurencie. Skrátka použitím (a preferovaním) proprietárnych služieb a objektov, ktoré štandard umožňuje, dochádza k závislosti od konkrétneho výrobcu napriek otvorenosti samotného protokolu. Toto sa javí ako konkurenčná nevýhoda voči iným protokolom, najmä čo sa týka vertikálnej komunikácie na vyššie úrovne (SCADA).

 

Na druhej strane, štandardy CIP a Ethernet/IP definujú aj rýchlu komunikáciu medzi  zariadeniami (rozšírenia CIP Motion, CIP Sync), čo sú oblasti, v ktorých protokoly ako OPC UA konkurovať nemôžu.

 

V každom prípade, D2000 verzia 12 už protokol Ethernet/IP podporuje a pridáva ho tak k rastúcemu zoznamu podporovaných a implementovaných protokolov.

 

7.1.2019, Ing. Peter Humaj, www.ipesoft.com

Iné blogy

Všetky

Right time/Right place solutions

Menu
Dôležité odkazy
Kontaktné údaje
© Copyright IPESOFT 2023