Manažment počítačovej siete
Základnou činnosťou administrácie počítačových i priemyselných sietí je monitorovanie siete a sieťových zariadení. V sieťach typu TCP/IP je k tomuto účelu určený protokol SNMP. Pre svoju jednoduchosť a ľahkú implementáciu nezávislú na operačnom systému je SNMP ideálny protokol pre manažovanie počítačových i priemyselných sieti. Poskytuje množstvo informácií o stave monitorovaných zariadení, dokáže manažovať zariadenia (meniť konfiguráciu, reštartovať a pod.) a vďaka smerovaniu aj vzdialenú správu cez verejnú sieť.
SNMP protokol
SNMP je jednoduchý protokol typu klient – server, ktorý monitoruje zariadenia pripojené v počítačovej sieti. Je to nástroj na riadenie a správu sieťových zariadení. Jeho hlavnou úlohou je rýchle a správne doručovanie správ medzi sieťovými entitami. Klient generuje požiadavky, na ktoré server odpovedá. Samotný protokol sa skladá z troch častí [4]:
- správca (klient) – generuje príkaz, požiadavky,
- agent (server) – odpovedá na príkazy,
- proxy – riadi prenos SNMP.
Správca SNMP
Je softvérová aplikácia, ktorá riadi a monitoruje agentov SNMP. Pracuje v aplikačnej vrstve modelu TCP/IP. Správca generuje príkazy agentom SNMP, vyhodnocuje tieto informácie a eviduje celkový stav siete. Prostredníctvom SNMP je možné čítať údaje zo vzdialených zariadení, meniť ich konfiguráciu alebo reštartovať zariadenie. Správca tiež prijíma správy od agentov, ktoré si sám nevyžiadal (trap messages). Týmito správami agenti oznamujú určitú zmenu stavu, napr. neautorizovaný správca sa pokúša meniť konfiguráciu a pod.. Správy od agentov prijíma na UDP porte číslo 162. [4], [7]
Agent SNMP
Agent zhromažďuje informácie o svojich sieťových udalostiach a na požiadanie ich zasiela správcovi. Požiadavkám správcu načúva na UDP porte číslo 161. Údaje o zariadeniach sú uložené v MIB databáze (Kap. 3.1.5). [4]
Proxy
SNMP proxy zabezpečuje doručovanie správ medzi správcom a agentom. V prípade rozličných verzií protokolu (Kap. 5.4.1) zastáva úlohu tlmočník v komunikácií. [4]
Verzie protokolu SNMP
V súčasnosti existujú tri verzie protokolu: SNMPv1, SNMPv2 a SNMPv3. Jednotlivé verzie protokolu nie sú navzájom kompatibilné a ich vzájomná komunikácia je sprostredkovávaná cez SNMP Proxy. Každá nová verzia zo sebou prináša určité vylepšenia v manažovaní sieťových zariadení prostredníctvom protokolu SNMP.
SNMP verzia 1
SNMPv1 bol prvá implementácia SNMP protokolu v praxi. Podľa [7] používa iba päť protokolových operácií:
- Get,
- GetNext,
- GetResponse,
- Set,
- Trap.
Pomocou operácie Get správca požaduje hodnoty od agenta. Ak agent nemôže vyhovieť požiadavke Get, nepošle žiadne hodnoty. [7] Operácia GetNext má podobné využitie ako Get s rozdielom, že správca žiada o hodnotu ďalšej položky v zozname agenta. [7] Operáciou GetResponse agent odpovedá na požiadavky zadané správcom operáciami Get a GetNext. [7] Pomocou operácie Set sa zapisujú nové hodnoty položiek. Týmto spôsobom môže správca meniť nastavenia agenta. [7]
Základný formát paketu SNMP správy (Obr. 5) je jednoduchý. V hlavičke správy je označenie verzie SNMP protokolu a názov komunity alebo skupiny, do ktorej patria obe komunikujúce entity. Slúži na overenie totožnosti medzi agentom a správcom. Agent vždy patrí iba do jednej komunity, naopak správca môže byť členom viacerých komunít. Správca môže takto monitorovať viacero zariadení patriacich do rôznych komunít. Veľkosť hlavičky paketu, pola pre verziu a komunitu, má pevnú šírku (Tab. 3). [6]
| Veľkosť (bit) | Význam | |
| Verzia | 32 | Verzia protokolu |
| Komunita | 32 | Názov komunity |
| PDU | Premenlivá | Dátové pole |
V poli PDU (Protocol Data Unit) je uvedená samotná protokolová operácia. Má premenlivú veľkosť (Tab. 3) závislú od množstva prenášaných dát. Podrobný formát PDU poľa je znázornený na Obr. 6. [4]
V poli Typ PDU je uvedená protokolová operácia, Get, GetNext a pod. Všetky operácie používajú rovnaký formát správ, výnimkou sú nevyžiadané Trap správy, ktoré používajú iný formát správy (Obr. 7)
ID požiadavky je číslo na základe, ktorého sa páruje požiadavka správcu s odpoveďou agenta. [6]
- Chybový stav
- hovorí správcovi v akom stave je jeho požiadavka. Má šesť hodnôt (Tab. 4). [6]
- Index chyby
- ukazuje na objekt, ktorý generoval chybu. Ak v poli pre chybový stav je nula, index chyby je nulový. V žiadosti je index chyby vždy nulový. [6]
| Hodnota | Kód | Popis |
| 0 | noError | Nevyskytla sa žiadna chyba |
| 1 | tooBig | Pole PDU je príliš veľké k transportu |
| 2 | noSuchName | Meno požadovaného objektu sa nenašlo |
| 3 | badValue | Hodnota v požiadavke nezodpovedá štruktúre príjemcu |
| 4 | readOnly | Hodnota je iba na čítanie |
| 5 | genErr | Neznáma chyba |
Trap ako jedinú operáciu negeneruje správca, ale agent, ktorý touto správou informuje správcu o výskyte dôležitý udalostí. Jednou zo situácií, kedy môže agent generovať Trap správu je, keď správca sa pokúša komunikovať s agentom patriacim do inej komunity ako správca. Vtedy agent túto situáciu hodnotí ako neautorizovaný prístup a informuje o tom svojho správcu. [6]
| Názov | Veľkosť (bit) |
| PDU Typ | 32 |
| ID požiadavky | 32 |
| Status chyby | 32 |
| Index chyby | 32 |
| Dáta | Premenlivá |
Formát Trap (Obr. 7) je odlišný od formátu ostatných protokolových operácií. V poli Typ PDU je uvedená iba jedna hodnota Trap správa.
- Skupina
- je identifikátorom objektu pre skupiny, ktorý generoval nevyžiadanú (Trap) správu.
- Adresa
- agenta je 32 bitové číslo IP adresy agenta, ktorý generoval nevyžiadanú správu.
- Generický typ správy
- udáva typ preddefinovanej nevyžiadanej správy. Dôvod prečo bola správa generovaná. Podľa [4] má sedem preddefinovaných stavov (Tab. 6).
- Špecifický typ správy
- udáva špecifický typ nevyžiadanej správy. Upresňuje dôvod generovania správy.
- Časová pečiatka
- je čas kedy bola správa generovaná.
| Hodnota | Popis |
| 0 | Studený štart |
| 1 | Teplý štart |
| 2 | Výpadok linky |
| 3 | Nahodenie linky |
| 4 | Neprešlo overenie totožnosti |
| 5 | Strata suseda EGP |
| 6 | Vyhradené |
Prehľad veľkosti v bitoch, ktoré sú vyhradené pre jednotlivé polia nevyžiadanej správy sú uvedené v Tab. 7.
| Názov | Veľkosť (bit) |
| Typ PDU | 32 |
| Skupina | Premenlivá |
| Adresa agenta | 32 |
| Generický typ správy | 32 |
| Špecifický typ správy | 32 |
| Časová známka | 32 |
| Dáta | Premenlivá |
SNMP verzia 2
Druhá verzia prichádza z určitými vylepšeniami oproti prvej verzie protokolu a podľa [6] bol určený na posilnenie SNMPv1 v mnohých oblastiach, vrátane definícií MIB objektov a bezpečnosti. V druhej verzii pribudli dve nové protokolové operácie GetBulk a Inform .
GetBulk slúži na čítanie veľkého počtu dát, napríklad niekoľko riadkov v tabuľke. [6]
Operácia Inform umožňuje výmenu správ medzi viacerými správcami.[6]
Počas vývoja druhej verzie protokolu sa do praxi dostali štyri jeho variácií pod označením: SNMPv2p, SNMPv2c, SNMPv2u s SNMPv2*. Každý variant druhej verzie protokolu používa iný formát hlavičky správy. Formát dátového poľa PDU je pre všetky varianty rovnaký. [6]
Základný formát dátového poľa PDU je rovnaký ako pri predchádzajúcej verzii (Obr. 6). V poli Typ PDU v druhej verzii protokolu sú hodnoty uvedené v Tab. 8:
| Hodnota | Typ PDU správy |
| 0 | Get |
| 1 | GetNext |
| 2 | Response |
| 3 | Set |
| 4 | Trap SNMPv1 |
| 5 | GetBulk |
| 6 | Inform |
| 7 | Trap SNMPv2 |
| 8 | Report |
V poli Chybový stav (Obr. 6) druhej verzii SNMP protokolu je preddefinovaných viac stavov ako v prvej verzii implementácii protokolu. Prvých šesť stavov (Tab. 4) je totožných v oboch verziách SNMP protokolu. Rozšírenie chybových stavov druhej verzie je uvedené v Tab. 10. Protokolová operácia GetBulk používa špeciálny formát dátového poľa (PDU) [6]. Hlavička správy je nasledovná:
| Názov | Veľkosť (bit) | Popis |
| Typ PDU | 32 | Názov operácie - GetBulk |
| ID požiadavky | 32 | Párovanie požiadavky s odpoveďou |
| Bez opakovania | 32 | Počet objektov bez opakovaného čítania v požiadavke |
| Max opakovanie | 32 | Počet iterácií pri čítaní objektov z tabuľky |
| Hodnota | Kód | Popis |
| 6 | noAccess | Odmietnutý prístup k objektu |
| 7 | wrongType | Typ objektu je nesprávny |
| 8 | wrongLength | Špecifikovaná dĺžka pre objekt je nesprávna |
| 9 | wrongEncoding | Nesprávne šifrovanie |
| 10 | wrongValue | Zadaná hodnota je neprípustná |
| 11 | noCreation | Premenná neexistuje, nie je možné ju vytvoriť |
| 12 | inconsistentValue | Špecifikovaná hodnota je blokovaná, alebo nie je možné priradiť hodnotu v danom okamihu |
| 13 | resourceValue | Pokus o nastavenie hodnoty, ktorej zdroje nie sú k dispozícii |
| 14 | commitFaild | Pokus o nastavenie hodnoty zlyhal |
| 15 | undoFaild | Pokus o nastavenie hodnoty zo skupiny premenných zlyhal a pokus vrátiť späť hodnoty ostaných premenných nebol úspešný |
| 16 | authorizationError | Problém s autorizáciou |
| 17 | notWritable | Premennú nie je možné vytvoriť ani zapísať |
| 18 | incosistentName | Premenná neexistuje |
SNMP Verzia 3
Posledná verzia protokolu, ktorá bola aplikovaná do praxe mala za úlohu vyriešiť problémy, ktoré vznikli s nasadením rôznych variácií SNMP protokolu verzie 2 [6]. Tretia verzia používa rovnaké protokolové operácie ako SNMPv2 aj rovnaký formát dátového poľa PDU.
Hlavné vylepšenie SNMPv3 je v bezpečnosti protokolu. Obsahuje niekoľko úrovní zabezpečenia, ktoré umožňujú šifrovanie dát, alebo prístup k dátam na základe užívateľských prístupov. Napríklad konkrétny používateľ má prístup iba k niektorým údajom. Použitie nových bezpečnostných prvkov v SNMPv3 umožňuje bezpečnú správu a manažovanie sieťových zariadení cez verejnú sieť Internet. [6], [9]
| Názov | Veľkosť (bit) | Popis |
| Verzia | 32 | Verzia SNMP protokolu |
| ID správy | 32 | Párovanie požiadavky s odpoveďou |
| Max veľkosť správy | 32 | Maximálna veľkosť správy, ktorú odosielateľ môže prijať |
| Indikátor správy | 8 | Riadi spracovanie správy |
| Bezpečnostný model | 32 | Indikuje použitý bezpečnostný model |
| Bezpečnostné parametre | Premenlivá | Skupina polí, ktoré indikujú použité bezpečnostné parametre |
| Pole PDU | Premenlivá | Dáta spolu s parametrami, ktoré bližšie určujú prenášané údaje |
MIB databáza
Agenti ukladajú dáta vo forme objektov do MIB databázy. Databáza je tvorená stromovou štruktúrou a skladá sa z objektov a ich atribútov, ktoré objekt popisujú [11]. SMI (Structure and Identification of Management Information) definuje pravidlá pre pomenovávanie typov dát [12]. Podľa SMI je každý uzol v databáze popísaný atribútmi uvedenými v Tab. 12.
| Atribút | Popis |
| Object | Meno objektu |
| Syntax | Typ objektu |
| Description | Popis objektu |
| Access | Prístupové práva k objektu |
| Status | Status |
V súčasnosti sa používajú dve verzie databázy MIB-2 a MIB-1 a sú navzájom kompatibilné. Stromová štruktúra MIB databázy je znázornená na Obr. 8.
Podľa [8] sa každá položka v MIB databáze dá jednoznačne popísať pomocou identifikátoru objektu (OID). Identifikátor objektu je celá cesta z koreňa databázy (ROOT) po položku (Obr. 9). OID je tvorený číslom uzla, jednotlivé úrovne sú oddelené bodkou. [12] Položka na Obr. 9 má OID 1.1.3.6.1.
Každý uzol v MIB databáze je označený nielen číslom ale aj slovným popisom [10] [12]. Napríklad číselné OID 1.3.6.1 má slovný popis „iso.org.dod.internet“ (Obr. 8).
SMI definuje dátové typy pre siete typu TCP/IP. S použitím týchto typov bola definovaná prvá verzia MIB databázy. SMI definuje agregátne dátové typy a neagregátne dátové typy. [12]
| Názov | Popis |
| Integer | Celé číslo |
| Octet String | Textový reťazec |
| Object Identifier | Identifikátor objektu |
| NULL | Prázdny objekt |
| Názov | Popis |
| Network Address | Sieťová adresa |
| IpAddress | IP adresa |
| Counter | Nezáporné celé číslo |
| Gauge | Nezáporné celé číslo, ktoré môže stúpať alebo klesať |
| TimeTicks | Nezáporné celé číslo pre počítanie času |
| Opaque | Používa sa pre textové dáta |
Výpis č. 1 Použitie SNMP operácie z príkazového riadka
$ snmpget -v 1 -c public 192.168.5.3 sysUpTime.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (295214760) 34 days, 4:02:27.60
Vo výpise č. 1 je príklad čítania z MIB databázy prostredníctvom SNMP protokolu. Na zistenie hodnoty z MIB databázy, v tomto prípade je to čas prevádzky (sysUpTime), je použitý príkaz snmpget z príkazového riadku operačného systému. Prvá voľba (-v) hovorí o použitej verzii SNMP protokolu (verzia 1). Táto voľba nie je povinná, systém vie automaticky zistiť verziu protokolu agenta. Druhá voľba (-c), za ktorou nasleduje textový reťazec je povinná, slovo public je názov komunity SNMP agenta. Za komunitou nasleduje IP adresa zariadenia, z ktorého chceme čítať údaje. Miesto IP adresy sa môže použiť doménové meno zariadenia, ak existuje. Za identifikáciou zariadenie nasleduje názov položky, ktorej hodnotu chcem zistiť. Namiesto príkazu snmpget môžeme použiť príkaz snmpwalk, ktorý vypíše obsah celej MIB databázy (všetky položky). Nová hodnota sa nastavuje príkazom snmpset.
OPC protokol
OPC protokol sa stal štandardom pre aplikácie používané v oblasti priemyselnej automatizácie. Protokol vytvára jednotné komunikačné rozhranie so zariadeniami od rôznych výrobcov a s rôznym komunikačným rozhraním [13]. Architektúra protokolu je typu klient – server, primárne ide o dva typy: OPC Server a OPC Klient.
Vývoj protokolu je realizovaný pod záštitou združenia OPC Foundation, ktoré podľa [17] má v súčasnosti viac ako 350 členov. Medzi členov združenia patrí napríklad švajčiarsky CERN, nemecký Siemens AG, americký Microsoft Corporation ale i slovenská spoločnosť SAE Automation Nová Dubnica.
Pri monitorovacích systémoch bez použitia OPC protokolu (Obr. 10) musí každá aplikácia vedieť komunikovať so zariadením s jeho komunikačným protokolom. Zariadenia môžu používať rôzne komunikačné protokoly, napr. TSAA, Modbus alebo DDE. Navyše zariadenie môže byť monitorované viacerými aplikáciami. Takéto riešenie je dosť nepraktické, pretože už pri budovaní monitorovacieho systému sme obmedzovaní možnosťami vzájomnej komunikácie medzi softvérom a zariadením, čo sa môže odraziť aj zvýšením finančných prostriedkov pri budovaní monitorovacieho systému. [14]
Problém s rôznymi komunikačnými protokolmi rieši použitie OPC protokolu (Obr. 11). Vďaka OPC protokolu je možné prevádzkovať hardvér a softvér od rôznych výrobcov s rôznym komunikačným rozhraním. Podmienkou je existencia OPC rozhrania na oboch komunikačných entitách, alebo OPC server na strane hardvéru a OPC klient na strane softvéru. Klientska aplikácia nemusí poznať komunikačné rozhranie zariadenia, všetko zabezpečí OPC protokol. [15]
Vývojári softvéru ako sú OPC servery a OPC klienti, nemusia programovať ovládač pre každé zariadenie, ktoré chcú monitorovať, ale stačí implementácia OPC protokolu. Protokol zabezpečí komunikáciu s obrovským počtom priemyselných zariadení a pritom programátor nemusí napísať ani riadok kódu pre ovládač zariadenia. [15] OPC protokol je založený na protokole DCOM (Distributed Component Object Model) čo je programové rozhranie používané v operačných systémoch Microsoft Windows na komunikáciu medzi klientom a serverom [16]. DCOM je rozšírením pôvodného protokolu COM. Pri COM môže komunikácia prebiehať iba v rámci jedného počítača, DCOM umožňuje komunikáciu viacerých počítačov v rámci lokálnej siete alebo aj cez verejnú sieť Internet. Na prenos údajov v sieti využíva protokol TCP/IP. Služba DCOM štandardne načúva na porte 135. [16]
OPC špecifikácia
OPC protokol má niekoľko špecifikácií, ktoré slúžia k rôznemu účelu. OPC Foundation vydal nasledovné špecifikácie [16]:
- OPC DA (Data Access). Táto špecifikácia poskytuje prístup k údajom v reálnom čase to znamená, že aplikácia má k dispozícii posledné hodnoty. Najviac sa používa pri tvorbe serverových a klientskych OPC aplikácií,
- OPC DHA (Historical Data Access). Špecifikácia je určená na prístup k histórii procesných údajov, ktoré je možné potom analyzovať a hodnotiť. Údaje sú zvyčajne uložené v archívoch alebo v databázach,
- OPC AE (Alarms and Events). OPC AE servery sa používajú na výmenu a potvrdzovanie alarmov a udalostí,
- OPC DX (Date eXchange). Definuje spôsob výmeny dát medzi OPC servermi,
- OPC XML (XML Data Access). Táto špecifikácia je založená na štandarde XML. Špecifikácia umožňuje prístup k údajom zo všetkých operačných systémov, nie len Microsoft Windows.
OPC klient
OPC klient je softvérová aplikácia, ktorá prijíma dáta prostredníctvom OPC protokolu od jedného alebo viacerých OPC serverov a získane údaje prezentuje vo forme vizualizácie používateľovi. Používateľ môže dáta nie len prezerať, ale prostredníctvom klientskej aplikácie môže zadávať nové hodnoty. [16]
OPC server
OPC server je softvérová aplikácia, ktorá komunikuje s pripojeným hardvérovým zariadením s jeho komunikačným protokolom. Údaje prevádza do OPC protokolu a poskytuje ich nadradeným aplikáciám, OPC klientom. [16]
SAE SNMP OPC server
Aplikácia SNMP OPC server je softvérová aplikácia od spoločnosti SAE Automation Nová Dubnica. Oproti klasickému OPC serveru v sebe implementuje manažéra SNMP. Toto riešenie sa používa pri monitorovaní sieťových zariadení, ktoré používajú SNMP protokol a je potrebné ich integrovať s rôznymi HMI alebo SCADA systémami. [13]
SNMP OPC server (Obr. 12) komunikuje s pripojeným zariadením (SNMP Agent) pomocou operácií SNMP protokolu. Získane údaje zo zariadení poskytuje nadradeným aplikáciám prostredníctvom protokolu OPC. SNMP OPC server používa tri OPC špecifikácie: OPC XML pre výmenu dát v XML formáte, OPC DA pre klasického OPC klienta a OPC AE pre alarmy a udalosti.
Nastavenie adresného priestoru
Po inštalácii SAEAUT SNMP OPC servera je dôležité nastaviť pracovné prostredie servera, to znamená povedať serveru, ktoré zariadenia bude monitorovať. Nastavenie so robí v okne konfigurátora. V hlavnom menu vyberieme položku „Edit“ -> „New“ ->„Device“, zobrazí sa okno pre pridanie nového zariadenia (Obr. 13).
- Name hovorí o názve zariadenia, pod týmto menom sa zariadenie bude prezentovať v serveri,
- IP Address je sieťová IP adresa monitorovaného zariadenia, SNMP agenta. Táto položka je dôležitá a musí byť správane zadaná v opačnom prípade nebude server s agentom komunikovať,
- Community je názov komunity SNMP agenta. Aj táto položka musí byť správne zadaná, inak agent nebude komunikovať zo serverom, ale bude generovať Trap správy.
Nastavenie pripojenia „Connection settings“ môžeme nechať na štandardných hodnotách. Posledným krokom, ktorý je nutné vykonať pred začatím monitorovania zariadenia je import MIB databázy. Kliknutím pravým tlačidlom myši na zariadenie sa zobrazí menu, v ktorom vyberieme „MIB Browse (On-Line)“, zobrazí sa okno na prezeranie MIB databázy zariadenia (Obr. 14).
Po kliknutím na tlačidlo „Load MIB (On-Line)“, server načíta celú MIB databázu zariadenia do prehliadača (ľavá časť okna – Obr. 14). Kliknutím na tlačidlo „Transfer object(s) to configuration“ importujeme databázu do pracovného prostredia SAEAUT SNMP OPC servera od vybratého uzla. Na Obr. 14 je vybraný uzol MIB-2. Importujú sa všetky podriadené uzly.
OpcDbGateway
OpcDbGateway je softvérová aplikácia z kategórie SCADA systémov. Slúži na zber údajov z externých zariadení, ku ktorým je pripojený OPC server [13]. To znamená, že OpcDbGateway nevytvára priame spojenie s monitorovanými zariadeniami, ale údaje zberá z OPC servera, ktorý má priame pripojenie zo zariadením. Tieto údaje ďalej spracováva a ukladá do procesných databáz a súborov [13]. Spracované údaje poskytuje ďalším aplikáciám, napr. OPC klientom.
OpcDbGateway (Obr. 15) má v sebe implementovaného OPC klienta. Cez toto rozhranie komunikuje s pripojeným OPC server, od ktorého získava údaje o procesoch. Získane údaje ukladá do procesných databáz. Taktiež má v sebe implementovaný OPC server, ktorý mu umožňuje komunikovať s OPC klientom. OpcDbGateway má k dispozícii DLL rozhranie, ktoré slúži na pripojenie externých zariadení. Vlastné nastavenia sú uložené v konfiguračnej databáze.
Použitím aplikácie OpcDbGateway má používateľ k dispozícii nielen aktuálne ale aj staršie dáta, z ktorých môže vytvárať rôzne reporty, alebo sledovať históriu zmien monitorovaných veličín.
Konfigurácia OpcDbGateway
Pre správnu činnosť celého systému je potrebné vykonať základné nastavenia OpcDbGateway. Tvorba konfigurácie a zmena nastavení aplikácie sa robí v okne konfigurátora a pozostáva s týchto krokov [13]:
- Definovanie externých OPC serverov, z ktorých OpcDbGateway bude zberať údaje,
- Definovanie jednotlivých procesných databáz, spôsob prístupu k databázam a ich štruktúra,
- Definovanie operácií, ktoré sa budú vykonávať s údajmi.
Mapovaním adresného priestoru sa definujú externé OPC servery, ku ktorým sú pripojené monitorované zaradenia. V podstate sú to zariadenia, ktoré tvoria adresný priestor SAEAUT SNMP OPC servera (Obr. 13). OPC server sprostredkováva množstvo údajov a premenných, tieto údaje je možné prevziať do konfigurácie OpcDbGateway použitím funkcie „Mapovanie konfigurácie externého OPC servera“. Použitie funkcie je jednoduché a ušetrí množstvo práce a času ako pri manuálnom mapovaní konfigurácie.
