V tomto díle se opět zaměříme na protokoly uživatelské vrstvy, konkrétně na OPC a přístup k informacím a dále architekturu Microsoft .NET a Java.
OPC a přístup k informacím
Řada aplikací v oblasti průmyslové automatizace je vysoce generického druhu a je určena k obsluze nejrůznějších automatických systémů. Původně se od autorů tohoto aplikačního softwaru požadovalo vytvoření driverů pro každý automatizační systém, k němuž měly být připojeny. OPC tuto situaci řeší zavedením společného rozhraní (OPC klient) pro všechny aplikace spolupracující s automatickými systémy využívajícími OPC server. Komunikace pak probíhá mezi OPC klientem dodaným dodavatelem aplikace a serverem dodaným dodavatelem automatizace, takže dodavatel softwaru se nemusí zabývat zvláštnostmi automatického systému.
Systém OPC byl původně určen k provozování nad operačním systémem Microsoft Windows®. Je založen na objektovém modelu Microsoft Component Object Model (COM) a je distribuován po síti (Distributed Component Object Model neboli DCOM). Při použití COM si mohou dvě aplikace běžící nad OS Windows na stejném počítači mezi sebou předávat data jako zprávy mezi objekty. Tyto aplikace si mohou také předávat zprávy, pokud jsou instalovány na různých počítačích propojených sítí DCOM. COM se zakládá na prvku společného operačního systému, kterému se říká RPC (vzdálené procesní volání neboli remote procedure calls) a který je implementován v Microsoft Windows jako rozhraní pro předávání zpráv mezi objekty nazvané „spojování a vkládání objektů“ (object linking and embedding, OLE). Pokud dva objekty fungují na různých počítačích, používá operační systém Windows pro komunikaci uživatelsky definovaný síťový protokol. Microsoft podporuje TCP/IP jako standardní síťový protokol, ale lze použít jakýkoliv protokol definovaný v síťových propojeních Windows Network Connections. Pokud síťové zařízení nepoužívá systém Windows, musí podporovat COM/DCOM nebo SOAP. (SOAP je původní akronym pro protokol přístupu k jednoduchým objektům, Simple Object Access Protocol, který dnes neznamená nic. Nyní se jedná o otevřený standard založený na XML podporovaný konsorciem World Wide Web Consortium neboli W3C, což je normalizační orgán odpovědný za internetové standardy.) Microsoft a řada dalších společností podporují SOAP na mnoha jiných operačních systémech, včetně těch, které se používají pro vnořené systémy a jsou vhodné pro zařízení průmyslové automatizace. Upozorňujeme, že použití TCP/IP vytváří nedeterministická propojení, pokud se používá internet, protože způsob definování TCP podřizuje časování zpráv náhodným prodlevám internetového routingu. Protokol TCP/IP používaný pouze na místní síti není náhodným prodlevám vystaven, takže je plně deterministický. Avšak použití TCP může vést k neefektivnímu využívání síťových zdrojů ve srovnání s jinými protokoly přenosové vrstvy, které jsou založeny na uživatelském internetovém protokolu User Datagram Protocol/Internet Protocol (UDP/IP).
Původní protokol OPC se nazýval DA (přístup k datům, Data Access) a používal velmi jednoduché datové struktury. Podle DA jsou data jednoduchá 16bitová řada. Význam bitů definuje koncový uživatel během použití. Ačkoliv DA postačoval pro běžné aplikace typu PLC, funkce řízení procesu vyžadovaly další datovou strukturu pro atributy nebo parametry řídící smyčky a instrumentace. OPC nejprve vytvořila jazyk XML (eXtensible Markup Language) pro definování těchto datových struktur jako vrstvy, která má být implementována nad OPC/DA. Než se jazyk OPC/XML rozšířil, uvědomili si jeho tvůrci, že je potřeba lepší metoda definování objektových atributů. Tato metoda byla představena jako OPC/DX (výměna dat neboli Data eXchange), opět jako další vrstva nad OPC/XML. Účelem OPC/DX je umožnit definování dat nezávisle jak na řídícím systému představovaném serverem, tak na systému správy nebo prezentace dat představovaném OPC/DX klientem.
OPC se dále vyvinul v dnešní OPC/UA neboli jednotnou architekturu (Unified Architecture). Úplný popis OPC/UA najde čtenář na webu, když si vyhledá OPC/UA. Tyto změny OPC si vyžádala skutečnost, že byla potřebná podpora i jiných platforem než jen Windows, a že původní COM, DCOM a OLE se pro systémy založené na Windows staly zastaralými. OPC/UA je založena na sérii otevřených, IEC a internetových standardů, které podporují distribuovaný objektově orientovaný přenos dat, jako je SOAP, a jazyk popisu elektronických zařízení EDDL (Electronic Device Description Language). I když mechanismy OPC/UA se od předchozích verzí liší, cíle jsou stejné: poskytnout společné rozhraní mezi zdroji dat a jejich uživateli.
Architektura Microsoft .NET a Java
Microsoft nahradil celý svůj systém objektového modelování a mnoho dalších aspektů své architektury rámcem .NET (vyslov tečka-net). Záměrem .NET je zavést jednotný rámec realizace programů nezávisle na programovacím jazyku. Microsoft to nazývá společné jazykové prostředí běhu programu (CLR), které je virtuální. Microsoft normalizoval specifikace rámce .NET prostřednictvím Evropské asociace výrobců počítačů (ECMA), orgán pro otevřené standardy pro počítačové programovací jazyky. Tato koncepce je téměř totožná s koncepcí společnosti Oracle (původně vytvořené společností Sun Microsystems) Java Virtual Machine (JVM), ale vznikla o 5 let později a má řadu výhod systému Windows. JVM od společnosti Oracle interpretuje věty v originálním jazyce programu jako bytové kódy, které představují instrukce pro JVM. Platforma .NET je trochu jiná— věty v originálním jazyce musí být přepsány do knihovních standardů .NET a pak teprve kompilovány do cílového strojového kódu, kdy většinu práce udělá knihovna.
Microsoft tvrdí, že .NET bude fungovat rychleji na všech cílových počítačích, ale Oracle kontruje, že Java běží na každém počítači, který podporuje JVM. Microsoft má podporu JVM zabudovanou ve Windows. Mezi .NET a Java vlastně není žádný viditelný rozdíl. Největším rozdílem je, že .NET podporuje hladkou migrační cestu z COM/DCOM do objektové komunikace .NET. To znamená, že .NET podporuje OPC. Verze Javy od Microsoftu také podporuje OPC/UA.
Metoda přístupu k objektům .NET se nazývá SOAP a nahrazuje COM. Dopad na OPC spočívá v tom, že ho osvobozuje od omezení operačního systému Microsoft. Specifikace OPC/UA byla založena na použití .NET/SOAP.
Nástroje pro práci v poli (FDT)
Většina sběrnic fieldbus definuje atributy zařízení používaných pro snímání a řízení. Tyto definice atributů jsou obsaženy ve specifikacích uživatelské vrstvy. Tabulka 1 obsahuje názvy specifikací sběrnic fieldbus a některé jejich vlastnosti.
Nástroj FDT byl vytvořen pro eliminaci potřeby uživatele udržovat různé definice atributů pro HART, PROFIBUS-PA a FOUNDATION Fieldbus. FDT umožňuje dodavateli polní instrumentace nabídnout jednotný manažer typu zařízení (DTM) nezávislý na sběrnici, která se bude pro projekt používat, zatímco hostitelský počítač využívá rámcový FDT server.
Většina dodavatelů řízení procesů, zdá se, FDT podporuje, zejména to platí pro ty, kdo podporují také PROFIBUS-PA. FDT však nemá stejnou úroveň podpory ve světě tovární automatizace, protože jen málo dodavatelů PLC vyrobilo rámcové FDT servery nebo DTM pro binární polní zařízení. Zdá se, že FDT a OPC/DX jsou dvě velmi podobné metody řešení téhož problému.
OPC se staví jako protokol na vysoké úrovni sloužící pro normalizaci komunikace mezi hostitelem a ovladačem. FDT se naopak tváří jako protokol na vysoké úrovni pro normalizaci komunikace mezi terénním zařízením a ovladačem. Oba protokoly vycházejí z Microsoft COM/DCOM a využívají datové rámce kódované v XML (v OPC/DX, XML a UA). OPC má být určen pro automatizační sítě na bázi ethernetu, zatímco FDT je určen pro sběrnicové sítě typu fieldbus. Jasné je, že jakmile ovládací sítě založené na ethernetu přejdou do domény fieldbus, nastane mezi OPC a FDT/DTM konflikt.
Dalším možným konfliktem pro FDT je normalizace EDDL souborem norem IEC 61804. Vývojáři FDT tvrdí, že tento nástroj byl speciálně vyvinut jako řešení technického problému definování atributů inteligentních zařízení. To je i jeden z cílů EDDL spolu s poskytováním rychlého přístupu k datům zařízení v reálném čase, což cílem FDT nebylo.
Hlavní výhodou FDT před EDDL a OPC je, že umožňuje dodavateli terénního zařízení sestavit všestranné vizualizační nástroje pro podrobnou analýzu dat obsažených v terénním zařízení, a zejména pro použití pro diagnostiku a kalibraci. Tyto nástroje využívající FDT jsou nezávislé na dodavateli řídícího systému.
V roce 2007 se skupina FDT spojila s kooperačním týmem EDDL (ECT) s cílem odstranit rozdíly a zmatení uživatele z těchto dvou přístupů. Tento cíl byl splněn a výsledkem je FDI (integrace polních zařízení). EDDL je nyní ANSI/ISA-61804 a FDT specifikace jsou uvedeny v ANSI/ISA-62453. Do EDDL byla přidána řada grafických prvků, které zavedl FDT pro zobrazení dat lokální instrumentace. Specifikace FDI má na starosti skupina FieldComm Group, ale tato norma dosud nebyla schválena.
V příštím, závěrečném díle se seznámíme s bezdrátovými sítěmi.
