Jste zde

Protokol SNMP v průmyslových zařízeních

Redakce HW serveru, 3. Květen 2004 - 0:00

Čím více se používá technologie ethernet a protokoly rodiny TCP/IP, tím častěji se můžeme setkat i

s nasazením SNMP, protokolu původně vytvořeného ke kontrole správné funkčnosti aktivních síťových

prvků.

Nevýhodou ethernetu je to, že nemůžeme přesně zaručit dobu, kdy budou data doručena. Lze to obejít buď aplikačním protokolem nebo přechodem na rychlejší ethernet. Nyní se pro zvýšení datové propustnosti stále častěji používají přepínače. Mnohé nabízejí možnost konfigurace a monitorování přenosových parametrů právě pomocí SNMP (např. Hirschmann).

Popis protokolu

Protokol slouží ke komunikaci mezi serverem (SNMP agent) a klientem (SNMP browser či manager). Pokud server nemá k dispozici požadované informace přímo, ale musí je získávat např. další komunikací po sběrnici, hovoříme o tzv. proxy agentovi. Agent je na straně zařízení, klient pak na PC či pracovní stanici.

Protokol standardně používá k přenosu dat UDP datagramů. Novell používá i IPX a existují implementace, které používají TCP. Formát přenášených dat je však vždy shodný. Základem protokolu jsou proměnné, uspořádané do hierarchického stromu (obr. 1).


Obr. 1 - Hierarchický strom proměnných (MIB)

Každá proměnná může být různého datového typu (viz. RFC1155). Nevýhodou číselných typů je omezení na celá čísla. Obchází se to převodem čísel na jejich desetinásobek nebo na textový řetězec. Popis proměnných tvoří MIB (Management Information Base). Ta jednak definuje stromovou strukturu a jednak přiřazuje symbolickým jménům proměnných číselné identifikátory objektu (OID). Základní kořenová MIB je popsána v RFC1213. Pro napojení uživatelských proměnných zde slouží uzel enterprises. Každá firma, která má zájem, může zdarma požádat o přidělení svého identifikátoru, na který pak napojí MIBy svých zařízení. Do jednoho MIBu je možné umístit i popis více zařízení. S výhodou tehdy, když mají společnou část. Příkladem je třeba MIB výrobce UPS - firma APC.

Než spolu začne server a klient komunikovat, musíme oběma dodat shodnou MIB. Oddělením definice od přenášených dat a použitím kódování jazykem ASN.1 (Abstract Syntax Notation) je dosaženo menších datových paketů. Jednotlivé proměnné je možné v paketech agregovat do sekvencí a tím dále snížit provoz na síti. Komunikace probíhá systémem dotaz odpověď. Výjimkou jsou asynchronní trapy odesílané na předem zadanou IP adresu. Pakety jsou různé pro čtení (get), pro zápis(set) a pro trap. Zvláštností je požadavek typu get next, kdy je požadována nejbližší další hierarchická proměnná. Neustálým opakováním takového požadavku je možné projít (walk) celý strom proměnných, které dané zařízení poskytuje. Tak se mohou dotazovat i tabulky, kdy je možné vyslat požadavek na proměnné celého záznamu najednou. Není nutné předem znát kolik záznamů bude tabulka obsahovat, protože get next vrací údaje tak dlouho, dokud jsou další záznamy k dispozici. Význam to má hlavně pro dynamické tabulky. Příkladem je např. počet teploměrů v tabulce na obr. 2.


Obr. 2 - Dynamické tabulky

Doposud jsme hovořili o protokolu verze 1, který se používá již 14 let. Původním cílem bylo získávat pouze okamžité hodnoty proměnných. Stačila jednoduchá ochrana heslem, kterému se zde říká community řetězec. Používají se různé pro čtení, zápis a pro trap. Dalším úsilím vývojářů byla snaha o vetší zabezpečení přenosu a variabilnější definici MIB. Verze 2 používá k ověřování zpráv autentikaci MD5 a seskupování objektů, které lze použít v notifikacích (tak se zde nazývají trapy). U této verze došlo k roztříštění na několik podverzí. Každý výrobce podporoval odlišnou a proto se verze 2 příliš neujala. V prosinci 2002 byl IETF (Internet Engineering Task Force) publikován nový standard – verze 3 (RFC341x). Zde je důležitá možnost použití šifrovacího protokolu AES 128.

Specifika SNMP pro průmyslová zařízení

SNMP poskytuje pouze okamžité hodnoty. Složitější analýzy nabízí protokol RMON (remote monitoring), kterým se zde nebudeme zabývat. Pokud chceme vytvářet grafické vizualizace nebo data archivovat, musíme zařízení periodicky dotazovat. Nevýhodou poskytovaných hodnot je absence informace o kvalitě a čase měření. Příklad jednoduchého výstupu je na obrázku 3.


Obr. 3 - Jednoduchý SNMP klient

Když použijeme protokol UDP, není nutné navazovat síťové spojení a zařízení ani nemusí obsahovat protokol TCP s jeho složitým stavovým mechanismem. To dovoluje použít i méně výkonný mikroprocesor (rodina x51, AVR). Implementaci je možné přizpůsobit potřebám konkrétního produktu. Je možné třeba přidat vzdálené zapínání a vypínání technologie. Další výhodou je schopnost zařízení poslat informaci (trap) o nečekané události (hodnota mimo rozsah, změna vstupu, výpadek napájení u UPS, atp.). Použitím společné konzole pro správu standardních aktivních prvků a průmyslových zdrojů šetříme i lidské zdroje. Většina monitorovacích programů umožňuje vyslat e-mail, SMS, informaci na pager či spustit externí utilitu. Není tedy nutné, aby tyto funkce obsahovalo koncové zařízení.

Jestliže nám to nezakazují přísné bezpečnostní podmínky, můžeme zařízení snadno konfigurovat přes SNMP proměnné. Výhodou je zejména to, že nemusíme implementovat klientskou část. Mnohdy potřebujeme zápisem určité hodnoty spustit nějaký proces (test, start/stop vzdáleného zařízení). Požadovaná bezpečnost se dá většinou zvýšit omezením přístupu pouze z určitých IP adres a změnou default hodnot community řetězců..

Do návrhu uživatelské MIB je zapotřebí zahrnout konfigurovatelné parametry zařízení, poskytované údaje, alarmy a hlášení. Grafické programy usnadňují sestavování MIB souboru. Pro implementaci MIB do zařízení jsou k dispozici generátory kostry kódu, do kterých dopíšeme pouze vazbu na koncovou technologii. Jsou dostupné pro různé jazyky a někdy nabízejí i možnost úpravy MIBu při zachování uživatelského kódu. O správnou funkci procházení hierarchického stromu se stará snmp engine, který je součástí dodávané SNMP knihovny či zdrojových kódů.

Srovnání s ostatními protokoly

Protokol SNMP je širokým standardem při správě informačních sítí. Výhodou při nasazení u průmyslového zařízení je podpora použitého standardu mnoha monitorovacími programy, které často umožňují i parametrickou vizualizaci. Zajišťují i logování kritických stavů a jejich následné zpracování. Pro přehlednost se často používá geografické rozmístění jednotlivých zařízení. Barevně je odlišen stav a tak je na první pohled patrné, která zařízení vyžadují pozornost. Pokud chci vytvořit jednoúčelový klientský program, je situace poněkud horší. Např. pro Javu není mnoho dostupných řešení. Ještě, že máme Internet.

Modbus, konkrétně jeho varianta “over TCP“ používá spojovaný přenos. Pakety jsou ale velmi krátké a mají jednoduchou strukturu. Je snadné implementovat jejich zpracování a pokud použijeme již hotový TCP stack, není zapotřebí tolik kódu jako v případě SNMP. Chybí popis proměnných, jsou pouze definovány jednoduché datové typy a každé zařízení má předem definované adresy, na kterých jsou k dispozici hodnoty proměnných, dohodnutých ve specifikaci. Vychází se z praxe, že primárně existují pouze binární a analogové vstupy a výstupy.

Ethernet/IP (Industrial Protocol) používá TCP pro získávání informačních a konfiguračních dat. Pro komunikaci I/O zařízení se používá multicastingu (UDP) a protokolu CIP. Výhodou je zvýšení propustnosti sítě tím, že poskytovatel (producer) posílá data najednou více odběratelům (consumer). Aby multicasting nezatěžoval sítě s přepínači, je třeba implementovat i složitější protokol IGMP.

OPC (OLE for Process Control) vzniklo právě se zřetelem na potřeby průmyslu. Poskytuje informace jak o čase a kvalitě měření, tak nabízí i možnost archivace dat a asynchronní upozornění na kritické události. Nevýhodou je orientace na Microsoft COM. Pokud budeme chtít použít jinou embedded platformu než Windows, nezbývá než implementovat většinu Windows API (pouze několik řešení). To vylučuje použití v jednoduchých, levnějších zařízeních. Nasazuje se tedy jako proxy server, který k získávání dat používá jiný protokol. Takový server pak slouží více odběratelům a snižuje zátěž primárního zařízení.

Již delší dobu se pro správu a zejména konfiguraci zařízení používá protokol http a technologie HTML. Pro data pak XML. Je možné i zkombinovat http s SNMP, když použijeme Java applet používající k přenosu dat SNMP. Webové stránky, obrázky a jiné soubory můžeme uložit na externí server, ale daleko lepší je umístění přímo do embedded zařízení. Při cenách dnešních flash pamětí tomu již nic nebrání. Největší výhodou je dostupnost klientského prohlížeče. I implementace http serveru je velmi jednoduchá a snadná. Naopak zcela chybí možnost iniciovat spojení ze strany serveru a poslat informaci o kritickém stavu. Můžeme toho docílit pouze periodickým čtením dat.

Závěr

Každý protokol je vhodný pro určitý okruh aplikací a je podporován různými výrobci. Pokud ve svých sítích používáte aktivní prvky a dohlížíte je přes SNMP, pak je dobré vědět, že je možné stejnými prostředky sledovat i kvalitu chodu průmyslových zařízení.
 

Původní článek pro časopis Automatizace 4/2004, Protokol SNMP v průmyslových zařízeních, Ing. Dušan Ferbas

Ing. Dušan Ferbas
dferbas@ dfsoft.cz

DOWNLOAD & Odkazy

  1. Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.
  2. Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP), RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
  3. Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, Performance Systems International, March 1991.
  4. Understanding SNMP MIBs By David Perkins, Evan McGinnis. Published by Prentice Hall PTR, 1996
  5. Automatizace 2/2004, Protokol SNMP pro správu sítí Industrial Ethernet, Ing. Karel Kabeš, podle materiálů ARC Advisory Group
Hodnocení článku: