Profinet je víc než jen spojení Profibusu a Ethernetu

Profinet je víc než jen spojení Profibusu a Ethernetu

Cílem tohoto článku je podat základní informace o Profinetu, o jeho objektovém modelu a o principu tvorby automatizačních systémů s využitím tohoto modelu. Větší důraz je přitom kladen na inženýrský model Profinetu.

Slovo Profinet vzniklo spojením slov Profibus a Ethernet, proto lze jeho význam chápat jako implementaci komunikačního protokolu Profibus na přenosovou vrstvu Ethernetu. Tento pohled však není úplně přesný, protože Profinet především popisuje nový přístup k vytváření distribuovaných automatizačních systémů za použití předem vytvořených automatizačních komponent. Komponenty (objekty) s určitou funkcí jsou vkládány do návrhového inženýrského systému a logicky spojovány tak, jak to odpovídá požadavkům řízené technologie. Funkce jednotlivých komponent je definována jejich výrobcem a předpokládá se, že půjde o zařízení obsahující již jakousi „vlastní inteligenci“. Jinými slovy, stále více se uplatňuje myšlenka rozmísťování výpočetní síly nutné pro řízení celého systému mezi různá zařízení, která se fyzicky nacházejí blíže řízené technologii. Uvolněné prostředky hlavního řídicího prvku (PLC, PC apod.) tak mohou být využity úlohami vyšší úrovně, např. pro zpracování technologických předpisů, bezpečnostní služby nebo kontakt s manažerskou úrovní řídicího systému. Navíc se stále levnější a výkonnější Ethernet dostává blíže k řízené technologii a tím snižuje celkové nároky na pořízení technického vybavení.

Specifikace Profinet ve verzi z března 2001 a v poslední úpravě ze srpna 2001 se zabývá především těmito tématy:

• využití stávajících široce používaných technologií, otevřenost díky definovaným povinným přístupovým rozhraním, možnost rozšíření o rozhraní odpovídající funkci daného zařízení,
• zapojení stávajících instalací sítě Profibus do celého systému bez nutnosti jakýchkoliv změn,
• využití stávajících nástrojů pro programování a konfiguraci PLC,
• využití podobných mechanismů pro komunikaci mezi zařízeními v horizontálním i vertikálním směru,
• jednotný inženýrský model usnadňující návrh celého systému,
• objektově orientovaný návrh – aplikace jsou vytvářeny spojováním objektů (komponent).

1. Koncepce Profinetu

1.1 Objekty při návrhu a běhu aplikace
Koncepce Profinetu popisuje způsob návrhu aplikace, tzn. jaké komponenty jsou definovány v této fázi tvorby systému, jak se tyto komponenty spojují apod., i způsob komunikace a vzájemné interakce příslušných objektů při běhu výsledné aplikace. Slovem objekt se rozumí automatizační objekt, neboli objekt, který představuje určité zařízení vykonávající danou funkci v celém řídicím systému. Jsou definovány dva typy zařízení: zařízení, která není možné programovat (lze pouze nastavovat jejich parametry), a která tedy mají pevnou funkci danou výrobcem, a zařízení programovatelná, jako např. PLC nebo softwarové PLC apod., jejichž funkce je dána právě jejich programem podle požadavku aplikace. Automatizační objekt je označován AUTO, automatizační objekt v době návrhu ES-AUTO, v době běhu systému RT-AUTO.

Na obr. 1 je vidět rozdělení celého automatizačního systému do několika částí. První je část představovaná objekty RT-AUTO, které odpovídají skutečným zařízením přítomným v technologii a jejichž chování bylo definováno buď výrobcem, nebo uživatelem při programování, jak ostatně vyplývá z předchozího textu. Vzájemné vztahy mezi objekty RT-AUTO musí být stanoveny v konfiguračním nástroji. Z toho důvodu má každý objekt RT-AUTO v konfiguračním nástroji příslušný objekt ES-AUTO, který obsahuje všechny potřebné informace o daném zařízení. Když se aplikace přeloží a kopíruje do fyzických zařízení, z každého objektu ES-AUTO se vytváří odpovídající objekt RT-AUTO. Poslední část tvoří již zmiňovaný konfigurační (inženýrský) nástroj, popř. nástroje potřebné pro diagnostiku, simulaci apod.

1.2 Komunikace
Jak již bylo řečeno v úvodu, Profinet využívá stávající metody pro vytvoření komunikačního modelu s důrazem na Ethernet jako na přenosovou sběrnici. Jde především o komunikační protokol TCP/IP, jehož služby využívá protokol RPC, a dále o protokol DCOM. Specifikace a implementace RPC stejně jako TCP/IP jsou široce rozšířeny na různých platformách, protokol DCOM pochází ze světa operačních systémů firmy Microsoft. Neznamená to však, že je tím implementace zařízení Profinet omezena na platformu těchto operačních systémů, neboť Profinet využívá vlastní implementaci DCOM. V konečném výsledku se bude rozlišovat, zda systém Profinet běží na platformě, která DCOM již poskytuje, nebo zda je třeba dodat externí software k jeho zavedení.

Na obr. 2 je znázorněn systém založený na komunikaci Profinet. Jsou zde rozlišena zařízení na straně inženýrského systému a na straně technologie. Všechna zařízení využívají zmíněné protokoly TCP/IP, RPC a DCOM pro zajištění komunikačních služeb, přičemž zařízení (aplikace) na straně inženýrského systému využívají model COM k interakci s komunikačními službami, které jsou přirozenou vrstvou nad službami DCOM. Zařízení na straně technologie místo toho využívají objekt ACCO, který zajišťuje, že spojení navržená v inženýrském systému budou skutečně zajišťována a udržována i v době běhu systému. Každý objekt ACCO se chová jako producent dat svých objektů RT-AUTO pro jiné objekty RT-AUTO v ostatních zařízeních a současně jako konzument dat objektů RT-AUTO v ostatních zařízeních pro své objekty RT-AUTO. Protokol objektů ACCO v sobě zahrnuje přenos časových známek a údajů o správnosti přenášené hodnoty, monitorování komunikujícího partnera, znovuobnovení spojení a diagnostické možnosti.

1.3 Integrace existujících zařízení
Na obr. 2 je rovněž vidět, že existující zařízení mohou být integrována do systému Profinet prostřednictvím zařízení zvaných proxy; v našem případě jde např. o proxy směrem k existující instalaci sítě Profibus DP nebo o proxy směrem k existující instalaci AS-I apod. To umožňuje jednoduše instalovat systém Profinet do již existujících aplikací, aniž by bylo nutné stávající zařízení vyměnit za nová. Jediným požadavkem je, aby nadřízené zařízení (master) dané sběrnice bylo schopné komunikovat po Profinetu. Tento předpoklad je možné splnit buď zavedením kódu Profinet přímo do firmwaru CPU, tzn. dodáním nové verze zařízení master bez nutnosti změn uživatelského programu, nebo přidáním ethernetového modulu, který bude Profinet přímo podporovat, a mírnou změnou řídicího uživatelského programu.

Proxy je tedy objekt, který se chová jako zástupce nějakého dalšího objektu nebo objektů a vytváří rozhraní pro jejich kontakt s „vnějším světem“. Používá se v těch případech, kdy není možný přímý přístup přes Profinet k zařízením na nejnižší úrovni – na úrovni technologie. Z hlediska návrhu systému jsou však takováto zařízení naopak chápána jako objekty Profinet, právě díky jejich reprezentaci pomocí proxy, a jako taková jsou zobrazována i v inženýrském systému.

2. Inženýrský model

Model inženýrského systému, který Profinet definuje, je hledisko, které má největší význam pro uživatele dané technologie, ať už jde o projektanty systému nebo jeho operátory. Toto hledisko rovněž obsahuje největší potenciál pro úsporu při uvádění automatizačního systému do provozu i při jeho další údržbě. Z hlediska uživatele je návrh systému založeného na Profinetu jednoduchý a intuitivní od samého začátku a představuje použití jednotného inženýrského nástroje pro výrobky od různých výrobců, umožňuje snadné a univerzální propojování, parametrizaci, diagnostiku apod., podporuje integraci již existujících programovacích nástrojů (např. programování jednotlivých PLC), definuje jednoduché rozhraní pro přenos dat do nadřazených aplikací, jako jsou např. aplikace řízení podniku atd.

2.1 COM – základ objektového modelu
Technologie COM firmy Microsoft tvoří základ objektového modelu Profinet. V něm jsou vytvářeny jednotlivé komponenty, jejichž funkce je zvenčí přístupná přes jednoznačná rozhraní. Pod pojmem rozhraní je možné chápat skupinu funkcí, pomocí níž je poskytována určitá služba komponentou typu server klientskému zařízení nebo aplikaci (opět prostřednictvím komponenty). V takovém případě se říká, že komponenta implementuje dané rozhraní; detaily této implementace však nejsou pro uživatele podstatné, a zůstávají tudíž skryty. Styk s těmito objekty bude možné uskutečnit pomocí automatizovaných rozhraní OLE, která jsou rovněž standardizována v COM. Pro popis rozhraní COM se používá jazyk IDL, jehož syntaxe je podobná syntaxi C++.

Rozhraní automatizačních objektů jsou rozdělena do čtyř skupin:

• povinná rozhraní představují standard, který musí splňovat všechna zařízení na Profinetu,
• volitelná rozhraní nutně nemusí být obsažena ve všech zařízeních; jestliže však jsou, musí být realizována podle platné specifikace,
• rozhraní specifická pro dané zařízení odpovídají určitým vlastnostem zařízení a nemohou být standardizována; obyčejně jsou implementována ve firmwaru (stále však musí být dodrženy zásady specifikace COM),
• rozhraní závislá na aplikaci jsou vytvářena programováním daného zařízení, např. PLC, a odpovídají konkrétním požadavkům aplikace.

V popisu rozhraní jsou navíc definovány tzv. vlastnosti (properties), které zpřístupňují atributy objektu okolnímu světu prostřednictvím pomocných metod. Vlastnost komponenty může být typu get, což znamená, že příslušná pomocná metoda odpovídající atribut čte, nebo typu put, což znamená, že příslušná pomocná metoda odpovídající atribut naopak mění (zapisuje).

Metody rozhraní jsou implementovány v komponentě server a jejich voláním klient žádá server o vykonání nějaké činnosti, např. o nastavení ventilu do určité polohy. Jde o jiný typ metody, než tomu je v případě metod souvisejících s vlastnostmi komponenty, které pouze zpřístupňují atributy komponenty okolnímu prostředí. Server není ovlivňován skutečností, je-li volání metody synchronní nebo asynchronní; ve druhém případě může informovat klient o dokončení služby prostřednictvím události. Událost může vzniknout, jestliže např. ventil dosáhl koncové polohy. Server pak volá metodu klientu, pro který je volání takové metody událostí. Jde tedy vlastně o obrácený postup oproti volání metody serveru klientem. Výhodou tohoto způsobu je, že klient se nemusí serveru dotazovat na výsledek požadované operace, což snižuje komunikační nároky. Server navíc může události distribuovat více klientům.

Model COM definuje tři typy komunikačních cest mezi komponentami: v rámci procesu, mezi procesy v rámci jedné jednotky a mezi procesy běžícími v různých jednotkách (vzdálené volání). V rámci jednoho procesu se používá lokální volání funkcí s virtuální tabulkou ukazatelů na jednotlivé členské funkce rozhraní. V případě volání funkcí mezi procesy se definují části kódu klientu a serveru zvané proxy a stub (nelze je zaměňovat s pojmem proxy definovaným v Profinetu), které zajišťují pomocí mechanismu RPC vzájemnou komunikaci mezi vzdálenými procesy, popř. pomocí LRPC komunikaci mezi procesy v rámci jedné jednotky.

2.2 Automatizační objekty
Jak již bylo uvedeno v předchozí části, automatizační objekty se dělí na objekty v inženýrském systému (platné v době návrhu) – ES-Object a na objekty platné při běhu – RT-Object. ES-objekt reprezentuje RT-objekt při návrhu systému, vzájemné propojování a parametrizace ES-objektů vytváří model automatizačního řešení celého systému. Základní myšlenkou je, že každému ES-objektu přísluší právě jeden RT-objekt, takže vztahy mezi jednotlivými ES-objekty mohou být jednoduše mapovány na vztahy mezi RT-objekty, které jim odpovídají.

Při návrhu systému je možné rozlišovat dvě fáze – vytvoření šablony ES-objektu neboli generování komponenty a použití ES-objektu v inženýrském nástroji při tvorbě automatizační aplikace. Tento postup je vidět na obr. 3. Nejdříve se vytváří šablona objektu. Tato činnost zahrnuje popis rozhraní a programování odpovídajících metod. Výsledná šablona je uložena v knihovně objektů v podobě popisu komponenty (soubor typu XML). V prostřední úrovni je popsán konkrétní systém s použitím ES-objektů. Jde o objekty ES-Device a ES-AUTO.

ES-Device představuje jednotku v návrhovém systému, jednotku s pevnou nebo programovatelnou funkcí. Automatizační objekt ES-AUTO se používá pro propojování a přiřazování parametrů podle požadavků aplikace. Jestliže jde o zařízení programovatelné, odpovídající RT-AUTO vznikne až po překladu a nahrání příslušného kódu do reálného zařízení. Jestliže se jedná o zařízení s pevnou funkcí, jde zpravidla o pouhé nahrání parametrů, protože daný objekt již v reálném zařízení existuje, je pouze třeba jej zaktivovat. RT-AUTO je objekt, který představuje proveditelný kód v daném reálném zařízení.

Popisné soubory typu XML mohou být buď dodávány přímo se zařízením, jehož funkce je pevně dána již výrobcem, nebo mohou být automaticky generovány pro zařízení naprogramované uživatelem. Tento úkol vykonává tzv. generátor komponent, který může být např. přímo součástí programovacího nástroje. Uživatelský program se poté do skutečného zařízení nahrává na základě podnětu od inženýrského nástroje nahrávací aplikace (facet), která je dodána výrobcem a která odpovídá danému konkrétnímu zařízení (např. PLC). Hlavní výhodou pro návrháře celého automatizačního systému je, že se nemusí zabývat detaily samotné komunikace, protože jeho práce spočívá především v definování logických komunikačních spojení mezi jednotlivými objekty. Takové spojení může mít dvě různé podoby: buď zdrojová data jednoho objektu mohou být propojena s cílovými daty jiného objektu, nebo události, které vznikají v jednom objektu, spouštějí procedury v dalším objektu. Jak již bylo popsáno, rozhraní objektů popisují jejich vlastnosti, metody i události, na které reagují, a tyto údaje jsou prostřednictvím popisného souboru k dispozici inženýrskému systému. Díky tomu je vytváření spojení velmi jednoduché a Profinet se postará o to, aby mezi sebou komunikovala správná zařízení a objekty a aby komunikace byla bezchybná.

2.3 Podpůrné objekty (facets)
Komponenta pro ES-Device má pouze obecnou funkci. Profinet umožňuje tuto obecnou funkci rozšířit dodáním vlastních podpůrných objektů (facets). Díky tomu je možné se rozhodnout, zda bude použit obecný podpůrný objekt popsaný v Profinetu, nebo zda bude nutné implementovat speciální podpůrný objekt přímo odpovídající danému zařízení. Kdyby byly všechny funkce ES-Device implementovány přímo v této komponentě, při sebemenší změně jedné z funkcí by bylo třeba upravit implementaci celé komponenty.

V Profinetu jsou specifikovány následující obecné podpůrné objekty:

Podpůrné objekty pro spojování objektů RT-AUTO. Tento podpůrný objekt standardizuje vnější rozhraní, jejichž prostřednictvím mohou být určena vzájemná propojení jednotlivých objektů RT-AUTO. V době běhu jsou tato spojení uskutečňována objektem ACCO. Každý podpůrný objekt přitom odpovídá právě jednomu rozhraní objektu RT-AUTO, které se zúčastní propojení (takových rozhraní může být několik), a představuje všechny jeho vlastnosti, metody i události.

Podpůrné objekty pro přiřazování parametrů objektům RT-AUTO a logickým zařízením. Parametrizační podpůrný objekt umožňuje přiřadit parametry prostřednictvím objektů ES-AUTO a ES-Device. Činí tak s využitím funkce pro zjištění počtu parametrů, jejich jmen, datových typů a implicitních hodnot. Ze strany uživatele poskytuje přístup pro objekt ActiveX (na platformě Windows), který implementuje potřebné uživatelské rozhraní pro nastavování daných parametrů.

Podpůrné objekty pro přiřazování objektů ES-AUTO objektům ES-Device. Zařízení, na nichž budou jednotlivé objekty ES-AUTO vykonávat svou funkci, musí být definována již při inženýrském návrhu. Toto přiřazení se musí uskutečnit jak pro zařízení s pevnou funkcí, tak pro zařízení programovatelná. V obou případech musí být definována instance objektu RT-AUTO, ke kterému se bude vztahovat instance objektu ES-AUTO. Objekty RT-AUTO s pevnou funkcí v příslušném zařízení existují stále, v případě objektů programovatelných se musí o jejich vytvoření postarat příslušný objekt ES-Device během nahrávání dat do skutečného zařízení.

Podpůrné objekty pro propojení inženýrských dat se skutečným systémem. Proces nahrávání dat do skutečných zařízení zajistí, že konfigurace vytvořená v inženýrském systému bude existovat také v zúčastněných zařízeních Profinet. Ne všechny objekty ES-AUTO musí být nahrány do skutečných zařízení. Objekty, jichž se tento proces týká, jsou identifikovány přiřazovacím podpůrným objektem.

Při nahrávání dat systém nejdříve testuje jejich konzistenci a potom pro každý objekt ES-Device generuje reference na skutečné zařízení. Následuje nahrávání dat do objektů RT-AUTO (tento proces je závislý na každém zařízení) a jsou identifikovány nebo vytvářeny odpovídající instance objektů RT-AUTO pro příslušné objekty ES-AUTO určené pro nahrávání. Jakmile jsou všechny objekty RT-AUTO připraveny, proces končí nahráním jejich vzájemných propojení.

2.4 Zařízení DP slave
Profibus DP je komunikační protokol zaměřený především na rychlou výměnu dosti malého množství dat mezi zařízením master a několika zařízeními typu slave. Při požadavku, aby zařízení typu Profibus DP slave byla schopna komunikovat na Profinetu, by výrazně stouply hardwarové nároky na jejich realizaci. Navíc by se výrazně změnil poměr cyklické a acyklické komunikace – zatímco Profibus DP využívá acyklickou komunikaci pouze ve výjimečných případech, pro Profibus DP na Profinetu by se acyklická komunikace stala významnou částí komunikace, což by s sebou neslo i prodloužení reakční doby celého systému Profibus DP. Z tohoto důvodu se nabízí možnost modelovat zařízení Profibus DP slave jako proces z pohledu COM; z pohledu Profinetu pojmu proces odpovídá logické zařízení.

V Profinetu může být každé zařízení Profibus DP slave přístupné pouze pod adresou jeho masteru, jinými slovy zařízení DP slave není přiřazena žádná IP adresa. DP slave je chápán jako logické zařízení a objekt RT-AUTO představuje DP slave jako aplikaci. Z pohledu Profinetu je reprezentantem zařízení DP slave objekt zvaný proxy. S použitím proxy přestávají být v Profinetu zařízení DP slave závislá na svém masteru a stávají se samostatnými objekty. Proxy vlastně „sídlí“ v příslušném masteru a transformuje volání COM na data (telegramy) Profibusu DP. Na aplikační úrovni tak zařízení master funguje jako brána do světa Profinetu.

Na zařízení DP slave a aplikaci v něm běžící se lze dívat ze tří pohledů:

• Pohled Profinet představuje aplikaci běžící v zařízení slave jako objekt RT-AUTO.

• Pohled DP představuje zařízení DP slave ve smyslu Profibusu DP. Data mohou být s masterem vyměňována cyklicky, tzn., že master má ve své paměti obraz dat zařízení slave a výměna těchto dat ze strany Profinetu a ze strany DP je nezávislá. Ve druhém případě mohou být data vyměňována na straně DP acyklicky, což předpokládá zvláštní komunikaci na obou stranách pro každý požadavek.

• Programátorský pohled na zařízení slave jako na zařízení s pevnou nebo programovatelnou funkcí. Tento pohled zahrnuje mapování DP objektů na aplikační objekty.

V současné době zahrnuje Profinet podporu komunikace DPV0, neboli základních cyklických funkcí Profibusu DP. V příštích verzích bude zahrnuta i podpora DPV1, což znamená podporu acyklické komunikace a zpracování výstražných hlášení – alarmů.

3. Závěr
Hlavní výhody Profinetu vyplývají z inženýrského modelu. Díky němu se může návrhář systému soustředit především na logické propojení jednotlivých objektů, díky konceptu objektů proxy může snadno integrovat již existující instalace průmyslových sběrnic, především Profibusu DP, jehož podpora je ve specifikaci Profinet přímo zahrnuta.

Již existující řešení je možné shromažďovat v různých knihovnách a tak je lze použít v dalších aplikacích bez nutnosti velkých změn. Využití podpůrných objektů nechává dostatečný prostor pro implementaci vlastností unikátních pro každý jednotlivý druh zařízení, přičemž současně je dobře definováno rozhraní těchto podpůrných objektů na straně uživatele (návrháře systému) i na straně modelu Profinet.

V dalších verzích specifikace se počítá s vytvořením modelu reálné komunikace s využitím internetového protokolu UDP/IP a s nastavením priority paketů podle IEEE 802.1, čímž dojde k oddělení dat přenosu multimédií a hlasu od dat důležitých pro řízení technologie. Proto se počítá s dosažením garantované doby přenosu dat od producentu ke konzumentu do 5 ms.

V neposlední řadě bude pro členy sdružení Profibus CZ v České republice k dispozici volně přístupný zdrojový kód pro implementaci vlastních zařízení.

Poděkování
Tento článek vznikl za podpory Ministerstva školství, mládeže a tělovýchovy České republiky v rámci projektu LN00B096.