Mendelova univerzita v Brně Provozně ekonomická fakulta
Monitoring pneumatické linky FMS 200 za pomocí automatu Simatic a vizualizace v prostředí Control Web Bakalářská práce
Vedoucí práce:
Vypracoval:
Ing. Oldřich Trenz, Ph.D.
Josef Mac
Brno 2012
Tímto bych velmi rád poděkoval vedoucímu bakalářské práce panu Ing. Oldřichu Trenzovi, Ph.D. za jeho vstřícnost, ochotu, čas a cenné rady při tvorbě práce. Dále bych chtěl poděkovat Bc. Marcelovi Vytečkovi za jeho ochotu a technickou podporu.
Prohlašuji, že jsem tuto bakalářskou práci vyřešil samostatně s použitím literatury, kterou uvádím v závěru. V Brně dne 20. května 2012
______________________
Abstract Mac, J., Monitoring of pneumatic lines 200 for FMS using Simatic PLC and visualization in Control Web. Bachelor thesis. Brno: MF, 2012. At the beginnig of the thesis, we'll get to know the Simatic units, with their construction, communication and possibilities. Then a description of the Control Web system follows, of its parts and functions. We will perform analysis of the connection between those two systems and a choice of the best option to connect them. In the following part, the thesis focuses on implementing the application itself as divided into several steps: Producing the simulation entry, which serves as a substitution for a real element. Transferring the data among particular applications, serving for networking possibilities. Replacing the simulation entry with a real element. And at last but not at least, a visualisation of the application.
Keywords Simatic, Control Web, Interconnection, OPC
Abstrakt Mac, J., Monitoring pneumatické linky FMS 200 za pomocí automatu Simatic a vizualizace v prostředí Control Web. Bakalářská práce. Brno, 2012 Na začátku práce se seznámit s jednotkami Simatic, s jejich konstrukcí, komunikací a možnostmi. Dále popis systému Control Web, jeho částí a funkcí. Následně popsat možnosti propojení těchto dvou systémů, provést analýzu a výběr nejvhodnější varianty. V další části následuje implementace samotné aplikace, která je rozdělena do několika částí. Vytvoření simulačního vstupu, který slouží jako náhrada za reálný prvek. Přenos mezi jednotlivými aplikacemi, sloužící pro možnosti posílání dat po síti. Nahrazení simulačního vstupu reálným prvkem. Jako poslední vizualizace aplikace.
Klíčová slova Simatic, Control Web, propojení, OPC.
5
Obsah
Obsah 1
2
Úvod a cíl práce................................................................................................................... 8 1.1
Úvod............................................................................................................................. 8
1.2
Cíl práce ....................................................................................................................... 8
Teoretická východiska práce............................................................................................... 9 2.1
Simatic S7-300 ............................................................................................................. 9
2.1.1
Aplikace ................................................................................................................ 9
2.1.2
Vzhled a konstrukce ............................................................................................. 9
2.1.3
Provedení CPU.................................................................................................... 10
2.1.4
Komunikace ........................................................................................................ 11
2.1.5
Moduly ............................................................................................................... 11
2.2
Control Web............................................................................................................... 12
2.2.1
Podpora .............................................................................................................. 12
2.2.2
Vývojové prostředí ............................................................................................. 13
2.2.3
Datové elementy ................................................................................................ 15
2.2.4
Kanály ................................................................................................................. 17
2.2.5
Ovladače ............................................................................................................. 17
2.2.6
Přístroje .............................................................................................................. 18
2.2.7
Časování a aktivace ............................................................................................ 18
3
Metodický postup ............................................................................................................. 20
4
Vlastní práce...................................................................................................................... 21 4.1
Možnosti propojení pneumatické linky FMS 200 se softwarem Control Web ......... 21
4.1.1
Ovladač pro Simatic 200 s protokolem PPI ........................................................ 21
4.1.2
Ovladač pro komunikaci s PLC Siemens SIMATIC S5/S7 protokolem RK512 ..... 21
4.1.3
Ovladač pro komunikaci MPI/PROFIBUS/IE s PLC Siemens SIMATIC................. 21
4.1.4
Ovladač OPC klient pro Control Web ................................................................. 21
4.2
Srovnání ..................................................................................................................... 22
4.3
Komunikační diagram ................................................................................................ 23
4.4
Tvorba aplikace.......................................................................................................... 23
4.4.1
Simulace vstupu ................................................................................................. 23
4.4.2
Simulační ovladač Dummy ................................................................................. 23
4.4.3
Kanály ................................................................................................................. 25
4.4.4
Zobrazení............................................................................................................ 25
6
Obsah 4.4.5 4.5
Výsledek ............................................................................................................. 26
Komunikace po sítí..................................................................................................... 26
4.5.1
Komunikace ........................................................................................................ 26
4.5.2
Konfigurace serveru ........................................................................................... 28
4.5.3
Konfigurace klienta............................................................................................. 29
4.5.4
Předání dat mezi kanály ..................................................................................... 30
4.5.5
Procedury ........................................................................................................... 30
4.6
Náhrada simulačního vstupu..................................................................................... 31
4.6.1
OPC standard...................................................................................................... 31
4.6.2
Architektura OPC................................................................................................ 32
4.6.3
Specifikace OPC .................................................................................................. 32
4.6.4
Přenos dat .......................................................................................................... 33
4.6.5
OPC klient ........................................................................................................... 33
4.6.6
OPC server .......................................................................................................... 34
4.7
Vizualizace ................................................................................................................. 35
5
Diskuze a závěr.................................................................................................................. 37
6
Literatura........................................................................................................................... 38
Seznam obrázků
7
Seznam obrázků OBR. 1 OBR. 2 OBR. 3 OBR. 4 OBR. 5 OBR. 6 OBR. 7 OBR. 8 OBR. 9 OBR. 10 OBR. 11 OBR. 12 OBR. 13 OBR. 14 OBR. 15 OBR. 16 OBR. 17 OBR. 18 OBR. 19
KONSTRUKCE S7 ............................................................................................................................. 10 PROVEDENÍ CPU.............................................................................................................................. 10 CONTROL WEB - GRAFICKÝ EDITOR ......................................................................................... 14 CONTROL WEB - DATOVÝ EDITOR............................................................................................. 14 KOMUNIKAČNÍ DIAGRAM ............................................................................................................ 23 NASTAVENÍ OVLADAČE DUMMY.DLL ...................................................................................... 24 SIMULACE VSTUPNÍCH HODNOT................................................................................................ 26 KOMUNIKACE KLIENT/SERVER .................................................................................................. 27 KOMUNIKACE KLIENT/SERVER/KLIENT................................................................................... 27 KOMUNIKACE SERVER/KLIENT/SERVER.............................................................................. 27 KOMUNIKACE SERVER-KLIENT/KLIENT-SERVER.............................................................. 27 PRINCIP KOMUNIKACE PŘES HTTP - ČTENÍ......................................................................... 27 PRINCIP KOMUNIKACE PŘES HTTP - ZÁPIS.......................................................................... 28 TEST PŘENOSU HODNOT PŘES HTTP ..................................................................................... 30 VÝSLEDNÝ PŘENOS PŘES HTTP PROTOKOL ....................................................................... 31 ARCHITEKTURA OPC ................................................................................................................. 32 PROPOJENÍ PC STANICE/SIMATIC........................................................................................... 35 KOMUNIKACE MEZI APLIKACI CW A OPC SERVEREM ..................................................... 35 VÝSLEDNÝ VZHLED APLIKACE.............................................................................................. 36
Úvod a cíl práce
8
1 Úvod a cíl práce 1.1
Úvod
Monitoring, jedno slovo, které má v dnešní době mnoho významů a oblastí, kde ho používáme. Setkáme se s ním v reklamě, v médiích, marketingu, v oblasti životního prostředí a ekologie, v oblasti informačních technologií, komunikacích, řídicích systémech. Můžeme tedy obecně říci, že se jedná o sledování stavu či průběhu dané situace. Výstupy z monitoringu mohou sloužit ke statistickým účelům, ke komerčnímu využití, ke sledování vývoje situací ale i k zobrazování a řízení strojů. Automatizační technika by se bez monitorování hodnot či veličin jen těžko obešla, protože na jejich základě mohou probíhat další řízení programů a strojů. Zde je pro nás velkou výhodou vědět aktuální stavy veličin, podle kterých se může např. obsluha rozhodnout jaký další postup práce zvolí, či naměřené hodnoty ukládat, porovnávat a na hodnotě těchto výsledků dále zlepšovat celý automatizační proces.
1.2
Cíl práce
Cílem práce je návrh a otestování vhodného propojení jednotek Simatic S7 a systému Control Web v rámci pneumatické obslužné linky SMC 200 za účelem monitoringu stavu zařízení. Zjistit možnosti jejich propojení, následně výběr nejpříznivější varianty a návrh aplikace, která bude schopná monitorovat data v reálném čase. Aplikaci implementovat a odzkoušet ve formě vhodně navržené simulace prostředí. V závěru zhodnotit výsledek a přínos práce. Důvodů, proč řešit propojení těchto systémů, může být několik. Obecně můžeme říci, že pro obsluhu zařízení jsme vázáni na software od výrobce, jak na propojení tak na další zpracování či řízení. Proto se můžeme chtít zbavit této závislosti. Dalším důvodem mohou být potřeby napojení nového zařízení na podnikovou síť, kdy už máme zavedenou jinou technologii. Rozhodovat může i finanční stránka.
Teoretická východiska práce
9
2 Teoretická východiska práce 2.1
Simatic S7-300
Tato řada je následníkem řady Simatic S5. Nabízí řadu řešení programovatelného automatu pro nejrůznější aplikace. Může se jednat o kontrolní úlohy, integraci technologií nebo archivaci dat. Řeší i otázku automatizace vysoce komplexních systémů v malém rozsahu. Klade důraz na výrobní technologii. Tato platforma je optimálním řešením jak pro centralizovaná tak pro distribuovaná řešení. Nabízí zázemí silné firmy a neustálý vývoj a inovaci. 2.1.1
Aplikace
Simatic S7-300 nabízí řešení pro nejrozmanitější automatizační úlohy v následujících oblastech: • automobilový průmysl • výroba standardních strojů a zařízení • výroba jednoúčelových strojů a zařízení • sériová výroba strojů a zařízení (prakticky všechny druhy výrobních strojů), OEM • zpracování plastů • balicí průmysl • potravinářský a tabákový průmysl • vodárenství, výroba a rozvod el. energie a další 2.1.2
Vzhled a konstrukce
S7-300 umožňuje prostorově úsporné, modulární uspořádání řídicích systémů pro různé typy úloh, přičemž nezáleží na pořadí jednotlivých modulů. Spojovací sběrnice je integrována do jednotlivých modulů. Spojení je provedeno prostřednictvím sběrnicového konektoru, který je součástí dodávky každého modulu. Během provozu není potřeba ventilátor. (Siemens, 2005)
Teoretická východiska práce
Obr. 1
Konstrukce S7 (Siemens, 2005)
2.1.3
Provedení CPU
Obr. 2
Provedení CPU (Siemens, 2005)
10
Teoretická východiska práce
2.1.4
11
Komunikace
Vzhledem k možnostem které nabízí, musí v sobě Simatic obsahovat možnosti propojení s různými komunikačními protokoly, ať už pomocí integrovaného rozhrání přímo v CPU nebo přes jednotlivé moduly. Přehled protokolů: • Průmyslový Ethernet – mezinárodní standard pro propojování rozsáhlých oblastí i jednotlivých řídicích systémů. • PROFIBUS – mezinárodní standard pro komunikaci jednotlivých řídicích systémů a polní instrumentace. • PROFINET – je otevřený komunikační standard mezinárodní organizace PROFIBUS International (PI) založený na Ethernetu. Umožňuje jednotné a ucelené řešení pro veškeré požadavky průmyslové automatizace. • AS-Interface – mezinárodní standard pro komunikaci mezi senzory a akčními členy. • EIB – celosvětově standardizovaný instalační systém pro nasazení při automatizaci budov. • MPI – Multi point interface, pro komunikaci mezi CPUs, PG/PC a TD/OP. • Připojení Point-to-point – pro komunikaci mezi dvěma uzly prostřednictvím speciálních protokolů. Poin-to-point struktura představuje nejjednodušší formu komunikace. Jsou používány různé protokoly (např. RK 512, 3964(R) a ASCII). (Siemens, 2005) 2.1.5
Moduly
Univerzálnost jednotek Simatic spočívá v modulech. V základě je můžeme rozdělit na dva typy. Moduly sloužící pro komunikaci nebo technologické pro řízení procesů. Komunikační moduly: • Digitální a analogové v/v moduly pro téměř všechny typy signálů, včetně zpracování, přerušení a diagnostiky. • Digitální a analogové Ex v/v moduly pro použití v nebezpečných prostředích. • Komunikační moduly pro vazbu point-to-point nebo sběrnicovou komunikaci po ASinterface, PROFIBUS a Industrial Ethernet s IT funkcemi. Příklady využití: • Spojení Point-to-point s rychlostí přenosu dat do 115 Kbit/s a různými protokoly, např. pro připojení tiskáren, scannerů a zařízení od jiných výrobců. • Připojení k polní sběrnici AS-Interface pro komunikaci s binárními senzory a akčními členy. • Připojení na PROFIBUS prostřednictvím buď DP nebo FMS protokolu a nebo pomocí kabelu s optickým vláknem. • Připojení polní instrumentace na PROFIBUS PA prostřednictvím spojky DP/PA. • Připojení k průmyslovému Ethernetu prostřednictvím ISO/TCP nebo TCP/IP protokolu pro datovou komunikaci.
Teoretická východiska práce
12
Technologické moduly: • Jsou funkční moduly pro čítání/měření, všechny druhy polohovacích funkcí, PID a vačkové regulace. Příklady využití: • Čítání v různých pracovních režimech až do 500 kHz, měření až do 100 kHz. • Vačkové ovládání s až 13ti vačkovými stopami na modul. Všechny způsoby polohování: • Regulace polohy v režimu rychloposuvu a pracovním posuvu. • Polohování a pojezdy (Point-to-point) používající krokový motor či servomotory. • Víceosá interpolace (Point-to-point) používající krokové motory či servomotory. • Připojení polohovacích pohonů po PROFIBUS DP. • PID regulátor se schopností zálohování a integrovanou online samočinnou optimalizací pro různé typy regulátorů (spojitý regulátor, krokový regulátor, pulsní regulátor). (Siemens, 2005)
2.2
Control Web
Control Web (dále jen CW) je programovým systémem, který dokáže vystupovat v mnoha rolích. Může pracovat v řídicích jednotkách strojů, spojovat výrobní technologii s informačním systémem podniku, může být datovým serverem s mnoha webovými klienty, dokáže modelovat a simulovat procesy, zvládne řešit strojové vidění a vizuální inspekci, dokáže vytvářet náročné vizualizace, zajišťovat operátorské řízení a mnoho dalšího. (MORAVSKÉ PŘÍSTROJE, 2010)
2.2.1
Podpora
CW poskytuje širokou podporu v různých částech informačních technologií. Hardware: • PLC (Siemens, Mitsubishi, Omron, Teco, Allen-Bradley, ABB, Honeywell, …) • I/O moduly (DataLab IO, ELSACO, ADAM, …) • měřicí karty (Advantech, Axiom, Tedia, …) • „virtuální“ zařízení, např. WWW server apod. • Je potřeba zde uvažovat nutnost ovladačů u některých zařízení Protokoly a datové formáty: • TCP/IP, HTTP, HTML (Ethernet, WiFi, dial-up, …) • ODBC / SQL • COM / ActiveX • OPC (OLE for Process Control)
Teoretická východiska práce
13
• GSM / GPRS • DDE, NetDDE Otevřené protokoly: • OPC Data Access - stále vzrůstající množství OPC serverů • DDE / NetDDE, FastDDE - zachování zpětné kompatibility s DDE servery • GSM modemy, SMS zprávy • HTTP přístup k WWW serverům • Modicon Modbus, Modbus/TCP (MORAVSKÉ PŘÍSTROJE, 2010) Jak už vyplývá z předchozího textu, CW je sám o sobě vysoce komplexní systém pro tvorbu aplikací s různými požadavky. Z tohoto důvody by ani nebylo možné a rozumné snažit se zde popsat všechny jeho funkce a možnosti. Proto se zaměřím na vlastnosti, u kterých lze předpokládat využití v mojí aplikaci. Cílem práce je monitoring a vizualizace. Proto se zaměřím na následující oblasti CW. Aplikace bude komunikovat s jednotkou Simatic, a pro tuto komunikaci bude potřeba předávat data pomocí ovladačů a kanálů. Předávaná data bude potřeba někam uložit, k tomuto účelu slouží datové elementy. S daty ale budeme nejspíše potřebovat pracovat nebo je zobrazovat i jinde než na serveru, který je bude shromažďovat. Pro komunikaci s dalšími periferiemi nám poslouží protokol TCP/IP. Dalším krokem bude jejich vizualizace a zde využijeme možnosti grafického editoru. Důležitým prvkem bude i časování a aktivace jednotlivých prvků. V první řadě ale bude nutné se seznámit se samotným vývojovým prostředím a jeho prvky. 2.2.2
Vývojové prostředí
Vývojové prostředí v systému CW se skládá ze tří částí. Jsou to textový editor, datový inspektor a grafický editor. Jak nebo k čemu jsou představí následující kapitoly. Podstatné ale při práci s tímto systémem je uvědomit si, že každý z těchto editorů má svůj vlastní účel při vývoji aplikace. Používají se všechny a jsou vzájemně propojeny, takže změny v jednom se mohou dotýkat i ostatních. Grafický editor Velmi zjednodušeně můžeme říct, že grafický editor slouží k nastavení vzhledu aplikace a jejího chování, tak jak ji uvidí uživatel. V podstatě je to panel, který se nám zobrazí při spuštění. Jeho hlavním účelem je snadná a rychlá manipulace s přístroji. Podrobněji k přístrojům a jejich typům se dostaneme v jiné kapitole. Grafický editor obsahuje seznam všech viditelných i neviditelných přístrojů. U nich pak dokáže nastavovat jejich vlastnosti, jako jsou jméno, vzor, vzhled, polohu, vstupy/výstupy, podmínky zobrazování a mnohé další. Vlastnosti se mohou lišit podle jednotlivých přístrojů a jejich účelu.
Teoretická východiska práce
Obr. 3
14
Control Web - Grafický editor
Datový inspektor Jak už jeho název napovídá, jedná se o editor určený k práci s proměnnými. V tomto případě nejde jen o klasické proměnné jak můžeme být zvyklí z jiných programů. Krom těch klasických sem můžeme zařadit i seznam ovladačů, kanálů, modulů. Editor je určený k jejich rychlému a pohodlnému vytváření, úpravě nebo i mazání. Samotné proměnné jsou spojeny do sekcí podle typu. Vytváří jejich přehledný seznam i možnosti pohledů na celé skupiny nebo podrobně na jednotlivé proměnné. U nich pak dovoluje nastavovat jejich atributy, jako např. jméno, datový typ, počáteční hodnotu, barvu a další. Opět jsou tyto vlastnosti závislé na typu proměnné.
Obr. 4
Control Web - Datový editor
Teoretická východiska práce
15
Textový editor Jako jediný by textový editor stačil pro vytvoření celé aplikace. Ale toto vytvoření by bylo nejspíše značně náročné na znalost celého kódu systému CW. Navíc je nejmíň uživatelsky přívětivý. Jeho hlavním účelem je dotvoření aplikace, kdy nestačí jednoduší vytvoření přes grafický a datový editor. Jde o situace, kdy je potřeba doplnit kusy kódu, jako mohou být různé algoritmy nebo nastavení chování proměnných na různé podněty. V jistých situacích může i urychlit práci, kdy např. máme skupinu indikátorů a potřebujeme nastavit jednoduchou podmínku každému z nich, a rychlejší než to nastavovat přes grafický editor, může být zkopírování podmínky a její úpravy u každého z nich dle potřeby. 2.2.3
Datové elementy
Zde opět narážíme na komplexnost tohoto systému a proto je jasné, že nebude stačit jednoduché dělení, ale systém CW nabízí hned několik druhů dat. Obecnou strukturní i funkční jednotkou všech těchto druhů dat je datový element. Jednotlivé druhy elementů se od sebe navzájem liší významem i použitím — jejich společnou vlastností zůstává pouze to, že slouží k zaznamenání údajů. Jeden z pohledů jak by jsme je mohli dělit, je podle jejich vlastností: • paměťová náročnost - jsou to data, kdy nás zajímá jejich velikost a to hlavně při komunikaci ať už s ovladači či systémy CW vzájemně mezi sebou. • viditelnost - zde nás zajímá, jestli jde o prvek s globální viditelností, nebo sloužící jen pro chod konkrétní procedury. Jde vlastně o přístupnost daného elementu pro ostatní prvky. • čtení/zápis - ne všechny elementy mohou být schopny jejich čtení nebo zápisu hodnoty • platnost a dosažitelnost - ne všechny elementy mohou být v případě potřeby dostupné, u některých se může při požadavku na jejich hodnotu napřed načíst jejich stav z jiné periférie. A tyto data je potřeba uchovat, dokud nenastane přepis nově načtenou hodnotou. Význam veličiny obyčejně přesně ukazuje na datový typ elementu, neboli na strukturu a podobu dat v něm uchovávaných. CW rozeznává čtyři hlavní skupiny typů dat: • logické hodnoty - které obsahují binární hodnotu, tedy hodnotu vyjadřující stav zapnuto/vypnuto (true/false). • číselné hodnoty- které se (jako jediná skupina typů) dělí podle druhu čísel na samostatné rozlišené datové typy. Čísla v systému Control Web jsou buď desetinná, nebo celá, a to buď se znaménkem, nebo bez znaménka. Pro operace s čísly platí určitá pravidla, která přesně určují jejich chování. Číslům je věnována samostatná sekce této kapitoly — Číselné datové typy. • řetězce znaků - které obsahují skupiny písmen (libovolné kromě znaku s hodnotou 0) bez omezení délky. Řetězce se zapisují do apostrofů (''). • obecná data - jejichž vnitřní struktura je proměnlivá a je definována ovladači, případně virtuálními přístroji. Samotné jádro systému CW ji ale nezná a ani to není zapotřebí. Tento datový typ tedy představuje nějaký blok paměti, o němž je známa pouze jeho délka. Z tohoto důvodu je i množina operací s tímto datovým typem velmi omezena —
Teoretická východiska práce
16
datové elementy obecného datového typu lze vzájemně přiřazovat, předávat je jako parametry do procedur a porovnat na rovnost. • buffer - obsahuje blok paměti, který je nějak vnitřně strukturován. Jádro systému CW definuje pouze základní parametry (například délku bufferu), zbytek, čili vlastní organizace bufferu vyplývá z konkrétního použití. Například, použijete-li knihovnu objektů pro DSP — digitální zpracování signálu, bude CW automaticky pracovat s buffery, které mají organizaci dat odpovídající knihovně DSP. Samozřejmě, data se do systému CW musejí nějak dostat, a ovladač proto musí patřičné struktuře bufferu rozumět, aby ji mohl správně naplnit. Datový typ buffer je velmi flexibilní a je zcela otevřen pro případné speciální použití. Na druhou stranu, ostatní prostředky a datové typy systému CW jsou tak mocné, že potřeba vytvořit nový typ bufferu pro nějaká speciální data nejspíše nikdy nevyvstane. (MORAVSKÉ PŘÍSTROJE, 2012) Druhy datových elementů CW rozeznává osm druhů datových elementů: • Konstanty - datové elementy určené pouze pro čtení. Mohou obsahovat data jakéhokoli typu (s výjimkou datového typu buffer a data), jsou dostupné neustále a mají tudíž vždy platnou hodnotu. Konstanty mohou být globální, lokální v přístroji a lokální v proceduře. • Proměnné - jsou datové elementy obousměrné (pro zápis i čtení), jakéhokoli datového typu, dostupné okamžitě. Stejně jako konstanty mohou být proměnné globální, nebo lokální na různých úrovních. Proměnné slouží primárně k úschově vnitřních stavů aplikace. • Kanály - jsou datové elementy s určeným směrem (mohou být vstupní — input, výstupní — output nebo obousměrné — bidirectional), libovolného datového typu, mohou být pouze globální (nemůže existovat kanál definovaný jen v určité proceduře) a nejsou kdykoli volně dosažitelné. Podrobněji o kanálech dále. • Výrazy - jsou datové elementy jednosměrné (jen pro čtení), jakéhokoli datového typu (podle typu výrazu). Dostupnost výrazů závisí na obsahu výrazu — obsahuje-li definiční výraz elementu komunikované datové elementy (třeba kanály), závisí obsah elementu na stavu těchto elementů. • Vyhodnocované výrazy - jsou identické s datovými elementy výrazy, jejich výpočet se však neděje na požádání, ale periodicky. • Archivované datové elementy - jsou první z trojice druhů elementů, které mohou v aplikaci vystupovat dvojace. Buď jako proměnné, nebo jako výrazy. Jestli se bude element chovat jako proměnná, či jako výraz, záleží jen na definici jeho atributů. Jeho hlavní účel ale je v ukládání dat do archivní databáze. • Sledované výrazy a proměnné - ve stanovených intervalech datový element porovná svou hodnotu (tedy buď přímo svou hodnotu, nebo výsledek výpočtu definičního výrazu) s určenými mezemi a podle výsledku tohoto porovnání uskuteční zadané akce. • Současně archivované a sledované výrazy a proměnné - jde o kombinaci dvou předchozích druhů. (MORAVSKÉ PŘÍSTROJE, 2012)
Teoretická východiska práce
2.2.4
17
Kanály
Kanály jsou druh datových elementů, které komunikují s okolním světem. Mají vztah k reálným snímačům nebo řídícím prvkům. Rozlišujeme dva typy kanálů. Vstupní, které dodávají data do aplikace. Jejich úkolem je např. přenést změřenou veličinu. Naopak u výstupních kanálů vzniká hodnota pro přenos v aplikaci a pomocí kanálu se dostává k řídícím prvkům. Z tohoto popisu vyplývá, že důraz na přenos je různý. U vstupních kanálu je důležité jejich měření, u kterého se musí sledovat jak a jestli se podařil přenos dat. Naopak výstupní kanály mají větší nárok na správný zápis hodnoty ze strany aplikace. Je zde i možnost obousměrných kanálů. Ty pracují na principu, kdy podle toho co po nich chceme, tak se budou i chovat. Při čtení se z nich hodnota přečte, naopak při zápisu se do nich zapíše. Pokud by byly oba dva tyto požadavky zaráz, přednost má čtení, protože se obecně předpokládá, že čtení dat je složitější než zápis. Druhé rozlišení je v řízení těchto kanálů. Kanály, ať vstupní nebo výstupní, můžou být ve dvou režimech. První možnost je, kdy kanál reaguje a zahájí přenos při změně dat. Tohoto se využívá u jednodušších aplikací. Druhá možnost pak je, že kanály jsou řízeny v každém kroku jádra (otázce časování aplikace se budeme ještě věnovat). Tento způsob řízení je složitější a náročnější na obsluhu. 2.2.5
Ovladače
Veškerá komunikace kanálů aplikace probíhá pomocí ovladačů. Kanály jsou datové elementy aplikace, ovladače potom samostatné komponenty (malé samostatné programy), které realizují přenášení kanálů z a do technologie. Logika komunikací, tedy kdy a jaký kanál se má měřit nebo zapisovat, je součástí jádra aplikace, ovladač je jen prostředník, který požadavky aplikace vyřizuje a transformuje je do podoby, které rozumí snímač nebo řídicí prvek. Každý ovladač má definováno k sobě zařízení, s kterým komunikuje. Pojem zařízení zde může být matoucí, protože to nemusí být čistě fyzické zařízení, ale je zde i možnost komunikace mezi aplikacemi, tudíž se pak dá spíše bavit o ovladači k protokolu. Obecně vzato, ovladač vždy komunikuje nějakým protokolem — i třeba zápis a čtení dat z měřicí karty zasunuté přímo v počítači je řízen protokolem — i když velmi jednoduchým. Ovladač tedy rozumí svému protokolu a je pomocí něj schopen předávat vstupně/výstupnímu zařízení požadavky aplikace. Pokud to shrneme, když aplikace chce data dostat nebo poslat, musí tak učinit pomocí ovladačů. Ovladač je obyčejně pomocí souboru s parametry nastaven na určitou množinu dat — vnitřních kanálů — které odpovídají nějakým způsobem datům přímo v technologickém zařízení. Každý vnitřní kanál má své číslo — číslo kanálu v ovladači — které se používá při definici kanálu v aplikaci. Pomocí tohoto čísla tedy dochází k logickému propojení pojmenovaného kanálu — datového elementu s kanálem — částí ovladače. Číslo kanálu v ovladači je základní informace, která se při výměně dat mezi jádrem a ovladačem používá k rozlišení kanálu, a každý požadavek jádra směrovaný k ovladači je proto tímto číslem vybaven. (MORAVSKÉ PŘÍSTROJE, 2012) Systém CW má v sobě několik předdefinovaných ovladačů, které nám můžou velmi pomoc při práci. Můžeme je využít pro simulaci vstupních hodnot, pro komunikaci mezi aplikacemi, pro komunikaci přes různá rozhraní.
Teoretická východiska práce
2.2.6
18
Přístroje
Až do teď jsme se bavili o datových elementech, tedy jakýchsi proměnných a o přenosu těchto hodnot. Tyto informace by ale nebyly moc k užitku, kdybychom je neměli kde zobrazit. Zde dostává hlavní roli grafický editor a jeho paleta přístrojů. Ta obsahuje několik kategorií. K vizualizaci ve 2D slouží ploché přístroje, ve 3D pak prostorové. Výkonné přístroje jsou všechny, které nejsou vidět (neslouží pro vizualizaci), systémové přístroje pak jsou jednak vnitřní přístroje a jednak přístroje určené jen pro volání systémových funkcí. V naší aplikace lze předpokládat, že budeme používat ploché přístroje a proto se na ně podíváme víc. Samotné ploché přístroje se dělí do dalších podskupin: • Zobrazování - zde máme na výběr jaký druh informací chceme zobrazit ( spojité, binární, textové). Tyto přístroje mohou zobrazovat hodnoty vstupních kanálů. • Ovládání a řízení - zde máme stejný výběr zobrazovaných informací. Dá se i odvodit, že přístroje pro ovládání a řízení budou sloužit pro nastavení hodnot či veličin a budou komunikovat s výstupními kanály. • Práce s daty - sekce pro možnost uložení dat, jejich dalšího zpracování a i možnou tvorbu statistik. • Uživatelské rozhraní - slouží pro interakci s uživatelem a dává mu možnost zasáhnout do běhu aplikace. • Datum a čas - v aplikaci můžeme využít i tyto na první pohled možná zbytečné přístroje. • Panely - možnost nastavení panelů. • Popisy a symboly - statické a dynamické popisky v aplikaci. 2.2.7
Časování a aktivace
Aplikace systému CW mohou pracovat ve dvou módech, velmi zásadně se lišících způsobem spouštění jednotlivých akcí, jako například čtení a zápis vstupně/výstupních kanálů nebo aktivace jednotlivých přístrojů. Aplikace reálného času Je výhodná, pokud požadujete deterministické časování aplikace, chcete zaručit spouštění akcí v přesných časových okamžicích nebo potřebujete zaručit posloupnost jednotlivých akcí. Takové požadavky jsou zpravidla spojeny s aplikacemi pro přímé řízení strojů, pro řízení laboratorních experimentů apod. Věci, které by měl člověk brát v úvahu: Systém sám o sobě nic nedělá. Veškerá aktivita pochází od jednotlivých virtuálních přístrojů a datových sekcí. Až když je nějaký virtuální přístroj aktivován, teprve informuje systém, o jaké vstupně/výstupní kanály má zájem. Kanály vyžadované jednotlivými přístroji v daném časovém kroku jsou načteny a virtuální přístroje data zpracují. Systém se vždy bude snažit maximálně dodržet vámi naprogramované časování, a to i pokud je aplikace navržena tak, že na daném hardware a komunikačních rychlostech to není možné. Pro aplikace reálného času mají zcela zásadní význam ovladače vstupně/výstupních zařízení. Bohužel celá řada těchto ovladačů (zejména ovladačů průmyslových automatů) není
Teoretická východiska práce
19
pro práci v reálném čase uzpůsobena. Pro ladění aplikací reálného času nabízí CW možnost zobrazení informací o časování celé aplikace i jednotlivých přístrojů. Aplikace řízené změnou dat Hodí se v situaci, kdy aplikace má za úkol vizualizovat proces a ne jeho řízení. Návrh této aplikace je jednodušší, lehčí na odladění a realizaci aplikace. I zde je potřeba pamatovat na určité věci: Žádná aktivita přístroje nikdy nezpůsobí komunikaci s periferiemi a čtení nebo zápis dat, a to ani když je daný virtuální přístroj periodicky časován. Systém sám periodicky vyčítá data ze vstupně/výstupních zařízení a pokud se jejich hodnota od posledního čtení změnila, aktivuje všechny přístroje tento kanál používající. Virtuální přístroje nejsou aktivovány jen při změně kanálu, ale i po změně jakýchkoliv použitých datových elementů. Např. pokud nějaký přístroj pracuje s nějakou proměnnou a sám tuto proměnnou mění, bude neustále periodicky aktivován, protože jeho aktivace způsobí změnu proměnné, která způsobí další aktivaci. Ačkoliv aktivace přístrojů používajících daný datový element při jeho změně je standardní chování, aktivaci přístrojů datovými elementy lze řídit. Každý datový element nebo datová sekce může definovat atribut passive = true. Změny pasivních datových elementů nezpůsobují aktivace přístrojů. Minimální perioda aktivace, čas aktivace ani pořadí aktivace v tomto módu nelze zaručit. (MORAVSKÉ PŘÍSTROJE, 2012)
Metodický postup
20
3 Metodický postup Po projití a nastudování materiálů systému CW a jednotky Simatic S7, jsem se rozhodl pro rozdělení práce na jednotlivé dílčí úkoly, které budu postupně řešit a testovat dosažené výsledky: 1. Analýza možností propojení systému CW s jednotkami Simatic 1.1. Popis jednotlivých ovladačů, které jsou navrženy pro komunikaci s jednotkami Simatic, vytvoření přehledu na základě daných parametrů, výběr nejvhodnějšího z nich. 2. Komunikační diagram 2.1. Návrh komunikace, jak by měla probíhat v celé aplikaci. Návrh implementovat pomocí UML 2.0. 3. Tvorba samotné aplikace, rozdělená do několika částí: 3.1. Simulace vstupních hodnot 3.1.1. Výběr vhodného ovladače a jeho konfigurace. Simulace a zobrazení vstupních hodnot v jednoduché aplikaci. 3.2. Komunikace po síti 3.2.1. Přenos dat po síti mezi dvěma aplikacemi. Výběr vhodného ovladače a jeho nastavení. Konfigurace serveru a klienta. Vytvoření mapovacích a parametrických souborů. Otestování přenosu na jednoduché proměnné. 3.3. Předávání hodnot v aplikaci 3.3.1. Možnosti, jak zajistit předání hodnot mezi dvěma kanály a jejich aktualizaci. Implementace vybrané varianty. Výsledkem bude aplikace schopná přenášet data ze simulačního vstupu na jinou aplikaci přes komunikační protokol. 3.4. Návrh nahrazení simulačního vstupu 3.4.1. Příprava pro nahrazení simulovaného vstupu pomocí vybrané metody či ovladače. Popis konfigurace jednotlivých prvků. 4. Vizualizace 4.1. Navrhnout a implementovat vhodný vzhled aplikace. Cílem je jednoduchost, přehlednost a názornost. 5. Zhodnocení celého projektu, vytvořené aplikace a přínosu práce pro studium i zkušeností tímto získaných.
Vlastní práce
21
4 Vlastní práce 4.1
Možnosti propojení pneumatické linky FMS 200 se softwarem Control Web
Sama firma Moravské přístroje, která je tvůrcem systému CW, vydala tři ovladače pro komunikaci s jednotkami Simatic. Stručně se na ně podíváme: 4.1.1
Ovladač pro Simatic 200 s protokolem PPI
Komunikace probíhá přes sériové rozhraní. Použitý protokol je zde PPI. Ovladač má dva módy v kterých pracuje, a to master a slave. V módu master vystupuje jako nadřízený systém a řídí veškerou komunikaci s podřízenými stanicemi. V módu slave reaguje pouze na požadavky o čtení a zápis dat. Princip komunikace je takový, že sám uživatel definuje, jakým způsobem budou získaná data prezentována, a to pomocí datových typů, které sám zvolí. 4.1.2
Ovladač pro komunikaci s PLC Siemens SIMATIC S5/S7 protokolem RK512
Ovladač komunikuje přes sériové rozhraní a komunikace probíhá jako point-to-point. Použitý protokol je zde RK512. Ovladač vystupuje vždy jako master. Je schopný komunikovat jen s konkrétními komunikačními procesory jak v řadě S5 tak i S7. Komunikace probíhá na principu interpretace datových elementů PLC jako kanálů ovladače. Konfigurace je v parametrickém souboru, který si uživatel sám nastaví. 4.1.3
Ovladač pro komunikaci MPI/PROFIBUS/IE s PLC Siemens SIMATIC
Tento ovladač je nejvyspělejší ze všech tří. Umožňuje komunikaci přes rozhraní MPI, PROFIBUS nebo Industrial Ethernet. Jako další podporuje komunikaci s širokou řadou PLC a to S7-200 a S7-300/400/M7/C7. Dále je zde možnost připojení více PLC stanic Simatic S7. Jeho velká nevýhoda ale spočívá v nutnosti použití externího softwaru Prodave od firmy Siemens. Tento software v podstatě zaručuje správnou interpretaci dat při správném nastavení typu komunikačního procesoru. Poté probíhá komunikace na principu kanálů. 4.1.4
Ovladač OPC klient pro Control Web
Jedná se o ovladač, který ke své činnosti také vyžaduje ,,prostředníka". Toho nám zde zastupuje OPC server. OPC je standard, který vytváří prostředníka mezi prvky průmyslové automatizace — průmyslovými automaty, čidly a akčními členy na jedné straně a řídicími či operátorskými počítači a průmyslovými informačními systémy na straně druhé. OPC tvoří programovou vrstvu mezi technickým vybavením a programy s tímto hardware komunikujícími. Prvky průmyslové automatizace vybavené OPC serverem jsou nyní podobně snadno a bezproblémově použitelné, jako např. grafické karty vybavené ovladačem pro daný operační systém — nikdo není nucen zabývat se technickými detaily konstrukce čipu dané karty a jejím programovým rozhraním, stačí instalovat ovladač a vše pracuje. Stejně tak stačí na daném počítači instalovat patřičný OPC server pro použitý hardware a programy schopné se na tento server napojit (OPC klient) jsou s tímto hardware schopny komunikovat. Standard je založen na komponentové technologii COM od firmy Microsoft a spravuje ho nezisková organizace OPC Foundation.
22
Vlastní práce
Komunikace mezi OPC serverem a OPC klientem v aplikaci probíhá opět pomocí kanálů. I zde je potřeba nastavit parametrický soubor s jejich množinou.
Tab. 1
Přehled ovladačů na základě daných parametrů
Ovladač pro Simatic 200 Ovladač pro komunikaci s PLC Siemens SIMATIC S5/S7 protokolem RK512 Ovladač pro komunikaci MPI/PROFIBUS/IE s PLC Siemens SIMATIC OPC klient
Rozhraní sériové
Protokol CPU PPI řada 200
sériové, proudová smyčka 20 mA TTY s převodníkem MPI, PROFIBUS, Ethernet
RK512
Komunikace na úrovni aplikační vrsty s OPC serverem
ostatní Mód master/slave
S5: CP524, CP525, CP544, CPU928
Dle S7-200, ovladače S7300/400/M7/C7 Dle OPC serveru
nutnost produktu Prodave OPC server
Zdroj: (MORAVSKÉ PŘÍSTROJE, 2010)
4.2
Srovnání
Při srovnání budu vycházet z cíle této práce, kdy by výsledná aplikace měla být testována v podmínkách laboratoře Inteligentních systémů. V laboratoří jsou tři PLC automaty, s komunikačními čipy řady S7, proto zde můžeme vyřadit první z popisovaných ovladačů pro Simatic 200. Jako další můžeme vyřadit ovladač, který využívá protokol RK512. Tento ovladač je schopný komunikovat pouze se dvěma CPU z řady S7, navíc pouze pomocí protokolu RK512, kdy modul pro tuto komunikaci, není součástí vybavení laboratoře. Třetí z ovladačů by byl vhodný pro obsluhu, i pro pozdější možné použití v praxi, kdy je schopný komunikace se širokou řadou CPU jednotek. Nevýhoda zde je nutnost pořídit další software a to Prodave od firmy Siemens. Naštěstí se zde nabízí varianta použití OPC technologie, kdy OPC klient je volně ke stažení a jeho použití by nemělo být náročné jak na hardwarové tak softwarové požadavky a ani finančně.
Vlastní práce
4.3
Obr. 5
4.4
23
Komunikační diagram
Komunikační diagram
Tvorba aplikace
Vzhledem k tomu, že s programem CW začínám, rozhodl jsem se pro tvorbu aplikace takovým stylem, kdy budu provádět a simulovat jednotlivé dílčí kroky, které ve finále propojím. 4.4.1
Simulace vstupu
V prvním kroku jsem se rozhodl pro simulaci vstupních hodnot a jejich zobrazení v jednoduché aplikaci. Cílem zde je vytvořit aplikaci, která má za cíl funkčnost, nikoliv vzhled. Pro simulační vstup bude potřeba použití virtuálního ovladače, který nám nahradí reálný stroj. CW v základu obsahuje několik z nich, ale každý slouží pro simulaci jiných hodnot. Musíme najít takový, který je schopen simulovat logické hodnoty true/false, protože stejné hodnoty dostaneme i z jednotek PLC. Jediný, který se nám nabízí je ovladač Dummy. 4.4.2
Simulační ovladač Dummy
Tento ovladač vrací hodnoty vstupních kanálů podle toho, jak si je definujete v jeho konfiguračním souboru. Jeho další vlastností je možnost nastavit prodlevu a úspěšnost čtení nebo zápisu dat na kanály. Je to dobrá vlastnost, kdy můžeme simulovat i vstupy, u kterých by nebyla jistota úspěšného přenosu dat. Seznam jeho kanálů není pevně daný, ani nemá žádné předdefinované, které by nešly použít. Jejich definice se odvíjí od použitého mapovacího souboru. Také nevyžaduje speciální soubor parametrů. Namísto parametrického souboru ovladač pracuje s vlastním konfiguračním souborem, ve kterém jsou uvedeny jak hodnoty vstupních kanálů, které vrací do aplikace, tak konfigurační parametry. Jméno konfiguračního souboru se odvozuje od jména parametrického souboru. Místo souboru s příponou 'par' se ovladač snaží otevřít soubor s příponou 'dum'. Tento soubor se hledá podle sekce directories. Hodnoty kanálů se dají v konfiguračním souboru měnit i za běhu aplikace. K tomu můžete použít běžný textový editor. Tvorba parametrického souboru má následující pravidla: • každá definice kanálu musí být zapsána na zvláštním řádku, řetězce pak v apostrofech.
Vlastní práce
24
• kanál = hodnota ( např. 10 = true ) • speciální parametry mají zápis - název = hodnota ( např. success = 90 ) Konfigurace ovladače v aplikaci Nejprve je potřeba ovladač vytvořit, pojmenovat a následně přiřadit mapovací a konfigurační soubor. Bez těchto hodnot nás program nepustí dál. Proto je dobré, vytvořit si dopředu alespoň prázdné soubory, které přiřadíme ovladači. Jejich editaci je možno provézt později v samotném vývojovém prostředí. Výsledek vypadá následovně:
Obr. 6
Nastavení ovladače dummy.dll
Mapovací soubor určuje množinu kanálů, jejich typ a směr. Potřebuji pouze vstupní hodnoty typu boolean, proto konfigurační soubor bude vypadat následovně: begin 1000-1999 boolean input end. Počet kanálů v něm pro mě není závazný, tímto jen říkám aplikaci, aby na kanálech s těmito čísly čekala tyto hodnoty. Do konfiguračního souboru už je potřeba zapsat konkrétní kanály tzn. jejich číslo a hodnotu. Výsledný soubor: 1000 = true 1006 = true 1001 = false 1007 = false 1002 = true 1008 = false 1003 = true 1009 = true 1004 = true 1010 = false 1005 = false 1011 = true Uvažuji 12 kanálů, protože to je maximální počet pro jeden PLC stroj v laboratoři. Tímto jsme také dokončili konfiguraci ovladače. Další možné parametry: • delay -prodleva pro simulaci čtení a zápisu kanálů v milisekundách • success - úspěšnost pro simulaci čtení a zápisu kanálů v procentech • monitorinput - zapnutí (1) nebo potlačení (0) výpisů operací čtení kanálů do okna ladicích zpráv • monitoroutput - zapnutí (1) nebo potlačení (0) výpisů operací zápisu kanálů do okna ladicích zpráv
Vlastní práce
25
Při konfiguraci simulačního ovladače je potřeba dát si pozor na jednu věc. V manuálu je popsána situace kdy je řečeno, že můžete ponechat jak původní mapovací i konfigurační soubor. Dokonce by ovladač neměl vyžadovat vůbec mapovací soubor. Ovšem naše situace byla jiná, protože v tomto případě jsme neměli žádný původní mapovací soubor. A vzhledem k tomu, že obecně konfigurace ovladače vyžaduje oba dva soubory, nemůžeme mapovací soubor přeskočit. Proto bylo třeba vytvořit si mapovací soubor, který bude nasazen jako ,,původní" soubor. Zde je velmi dobře vidět, jak je mapovací soubor důležitý. Z něho aplikace čerpá seznam kanálů a jejich typ. 4.4.3
Kanály
Jak je vidět z konfigurace, ovladač obsahuje množinu kanálů a hodnot na nich. Je zde ale otázka jak k těmto hodnotám přistoupíme, jak je dostaneme přímo do aplikace? V tuto chvíli bychom neměli jak tyto hodnoty přečíst. Proto je nutné definovat a určit kanály, na kterých budeme moci číst jednotlivé hodnoty. K tomu nám slouží sekce channel. Zde můžeme buď vytvořit 12 kanálů v podsekci Skalární, nebo vytvořit pole hodnot v podsekci Pole. Pro mě výhodnější bude zvolit možnost vytvoření celého pole kanálů. K jeho vytvoření jsou potřeba atributy jméno, horní a dolní index pole a ovladač, na který jsou kanály napojeny. Ve chvíli, kdy přiřadíme poli ovladač, se nám přiřadí automaticky typ kanálu, podle zvolených indexů. V mapovacím souboru jsme definovali kanály 1000-1999 jako vstupní typu boolean. Proto když zvolíme dolní index 1000 a horní 1299, tak kanály budou automaticky stejného typu. Při nastavení rozsahu indexů mimo definice mapovacího souboru, nás program nepustí dál a bude trvat na opravě. Rozsah pole opět neznamená nutnost, využít všech jeho hodnot. Ale je lepší si zvolit rezervu pro kanály, než v budoucnu muset přepisovat celý konfigurační soubor. Dále je možné definovat atributy jako počáteční hodnota, prodleva komunikace, komentář. 4.4.4
Zobrazení
Pro zobrazení hodnot využiji grafický editor a jeho indicátory. Ty vytvoříme přetažením z palety nástrojů, v které je najdu pod Ploché přístroje - Zobrazování - Binární. Je zde možnost i vytvoření jednoho a jeho nakopírování. Ovšem při kopírování se nemění jméno, takže výsledek by byl nepřehledný a museli bychom nastavit každému jiný identifikátor. Zajímavé je, že pokud bychom nechali stejné identifikátory, při běhu programu to nevadí a program ignoruje více indikátorů se stejným identifikátorem, což je naopak oproti klasickému programování, ať už objektovému nebo procedurálnímu. Dokonce pokud jsou dva se stejným identifikátorem, můžou zobrazovat jiné hodnoty. Po jejich vytvoření je potřeba jim určit, jaký výraz budou vyhodnocovat a zobrazovat. Je zde možné nastavit přímo konkrétní proměnnou, nebo i výraz, který bude vyhodnocován. Ve výsledku pak může indikátor vypadat následovně (v textovém editoru): indicator indicator_1; gui owner = PLC_automat_1; position = 800, 157; window disable = zoom, minimize, maximize; end_window; end_gui;
Vlastní práce
26
expression = vs_dummy[1000]; end_indicator; Na první řádku vidíme typ a identifikátor prvku (jeho název), dále pak gui, v kterém jsou hodnoty týkající se zobrazení prvku, jako jeho majitel (panel, kde je prvek umístěn), pozice prvku na panelu a další nastavení okna. Za gui následují už nepovinné atributy, které nám můžou definovat další chování prvku. Tedy zde máme přiřazení výrazu, který určuje, že indicator_1 bude vyhodnocovat hodnotu vs_dummy[1000], což je prvek pole. 4.4.5
Výsledek
Po definici ovladače, přiřazení kanálů a přiřazení výrazů indikátorům, které budou zobrazovat, můžeme spustit aplikaci a zjistit jestli úspěšně simuluje vstupní hodnoty. Výsledek by mohl vypadat následovně:
Obr. 7
Simulace vstupních hodnot
Jak je vidět, pro ovladač Dummy se otevře navíc dialogové okno, v kterém je možnost nastavit prodlevu přenosu pro lepší představu nebo napodobení reálných vstupů a dále je zde vidět i jeho parametrický soubor, z kterého bere hodnoty, a v kterém pokud uděláme změny i za běhu programu, tak se promítnout v aplikaci. Díky této části jsem mnohem lépe pochopil práci s kanály, jak na nich komunikace probíhá, jak číst nebo teoreticky zapisovat data a celkově jsem si udělal už určitý náhled na celé vývojové prostředí.
4.5
Komunikace po sítí
V této části práce se zaměřím na komunikaci po sítí, aby bylo možné data přenášet např. v rámci podniku. Samotnou část ale dále rozdělím ještě na dva úkoly. První z nich bude samotná komunikace, která se bude týkat správného nastavení kanálů, ovladačů a přenášení hodnot mezi dvěma aplikacemi. Druhá pak se bude zabývat přenosem dat mezi jednotlivými kanály, kdy bude potřeba předat data z jednoho kanálu na druhý. 4.5.1
Komunikace
Vzhledem k tomu, že se opět jedná o práci s kanály, bude zde potřeba další ovladač. Pro propojení několika aplikací, běžících na různých počítačích byl určen ovladač CWNETDRV. Ke
Vlastní práce
27
komunikaci využívá protokol TCP/IP, což je logické v dnešní době, kdy ho každý počítač stejně využívá pro klasickou komunikaci přes síť. Činnost ovladače můžeme rozdělit na server/klient, popřípadě jejich kombinaci. Příklady zapojení jsou následující:
Obr. 8
Komunikace klient/server
server/klient - klasický způsob, kdy si klient žádá o hodnoty kanálů na straně serveru
Obr. 9
Komunikace klient/server/klient
klient/server/klient - podobný způsob zapojení, jen díky TCP/IP protokolu je možné provádět komunikaci s více klienty, kdy se data mohou lišit nebo mohou být odeslána na oba vstupy
Obr. 10
Komunikace server/klient/server
server/klient/server - klient zapisuje nebo čte data na různé servery, záleží na konfiguraci kanálů
Obr. 11
Komunikace server-klient/klient-server
server-klient/klient-server - aplikace je zároveň klient i server, obě tyto části jsou propojeny Princip komunikace je v základě jednoduchý. Komunikaci vyvolává klient a jsou dva způsoby jak ji může vyvolat:
Obr. 12
Princip komunikace přes http - čtení
Aplikace si vyžádá data ze serveru. V tomto případě jde o čtení dat z ovladače, kdy je požadavek předán klientovi, a ten ho pošle dál na server. Ten načte svoje aktuální hodnoty na dotazovaných kanálech a odešle je zpět klientovi, který je předá aplikaci.
Vlastní práce
Obr. 13
28
Princip komunikace přes http - zápis
V druhém případě si aplikace může vyžádat zápis dat, kdy je opět předán přes klienta požadavek na server. Ten přijatá data předá aplikaci, na které je spuštěn, a podle nastavení je může pouze uschovat nebo vyslat signál ostatním stanicím o změně hodnot. Celá komunikace probíhá na základě vyjímek a jejich zpracování, kdy ovladač CWNETDRV má pro tyto vyjímky vyhrazeny kanály. 4.5.2
Konfigurace serveru
Mapovací soubor pro server: begin 1 real input 2 real input 3 real input 4 real input 5 real input 6 boolean output 7 real input 8 string input 9 string input 1000 - 1299 boolean output 1300 - 1999 real output end. Mapovací soubor se zde neliší moc od použitého pro ovladač Dummy. Obsahuje seznam kanálů s tím rozdílem, že kanály 1-9 jsou pevně dány potřeby ovladače. Kanály 1300-1999 se chystám použít pro odzkoušení funkčnosti přenosu dat. Parametrický soubor: [options] max_exceptions = 200 [local_server] port = 8901 client = 192.168.1.2 client = any block = 1000, 1299, boolean, output
29
Vlastní práce
block
= 1300,
1999, real,
output
Na první pohled je vidět rozdíl. Soubor je rozdělen na sekce. První sekce options slouží ke konfiguraci chování ovladače. Řádek max_exception = 200 určuje délku fronty vyjímek pro ovladač. Nejsou-li výjimky od ovladače potvrzovány, řadí se do fronty až do jejího zaplnění. V sekci local_server je vlastní definice serveru. Kanály jsou zde zapsané do bloků. Další věc co zde je nová, je IP adresa serveru, aby mohlo dojít k adresaci v síti. Dále je číslo portu, na kterém se otevírá síťové spojení. Musí být větší než 5500 a musí být unikátní pro obě strany. Řádek client = any znamená, že server akceptuje všechny připojené klienty a všechny ostatní definice klientů se ignorují. 4.5.3
Konfigurace klienta
Mapovací soubor: begin 1 real input 2 real input 3 real input 4 real input 5 real input 6 boolean output 7 real input 8 string input 9 string input 1000 - 1299 boolean input 1300 - 1999 real input end. Mapovací soubor má stejný počet kanálů. Pro prvních devět se ani neliší jejich směr, ale pro kanály, které používáme pro přenos dat platí obrácené pravidlo. Místo výstupu je na nich očekáván vstup a to právě ze strany serveru. Parametrický soubor: [options] max_exceptions = 200 [remote_server_1] server timeout connect_on_startup auto_connect block block
= = = = = =
192.168.1.2:8901 2000 false true 1000,1299, 1000, boolean,input 1300,1999, 1100, real, input
Parametrický soubor pro klienta je obsáhlejší. Kromě IP serveru, je za ní zapsán navíc port. Timeout určuje jak dlouho se bude čekat na odezvu serveru v milisekundách. Connect_on_startup je možnost navázání spojení se serverem při spuštění aplikace. Implicitně je nastaven na false. Auto_connect je příznak automatického navázání spojení se
Vlastní práce
30
serverem. Je-li tento parametr nastaven na hodnotu true, klient se pokusí navázat spojení se serverem automaticky při požadavku na přenos kanálů, pokud spojení ještě není navázáno. Zbytek je definice kanálů. Nyní můžeme odzkoušet, jestli jsou ovladače správně nastaveny. Pro tento test jsem nastavil kanály pro přenos čísla. Na straně serveru si nastavím přístroj control, který je schopný zapisovat data na kanál. Na straně klienta pak přístroj meter, který slouží ke zobrazování. Číslo kanálu, na které oba tyto přístroje zapisují musí být stejné. Aplikace by byla schopná spuštění i při jiném nastavení, ovšem by nedošlo k předání hodnoty. Přesněji by se hodnoty předaly, ale nebylo by nic co by hodnotu ze serveru zobrazilo. Výsledek tohoto testu:
Obr. 14
Test přenosu hodnot přes http
4.5.4
Předání dat mezi kanály
Zde nastal zajímavý moment práce, kdy jsem musel vyřešit jak dostat data z výstupu jednoho ovladače na vstup druhého. Také zde je asi největší rozdíl aspoň oproti klasickému programování. Ze začátku jsem bral kanály, jako druh proměnné (což v podstatě jsou), a tak jsem hledal jak přiřadit hodnotu jedné proměnné jiné. Ať Pascal nebo C++ jsou programy, kde přiřazení má určitou formu ,,=". Stejné jsem hledal i zde. Po delším zamyšlení jsem si uvědomil velmi důležitou věc, že k systému CW nemůžu přistupovat stejně. Zde by ani toto přiřazení nebylo kam zapsat, protože tu není žádný hlavní blok programu. Celá aplikace je řízena změnou dat, kdy tyto změny jsou podměty, co vyvolávají reakce jednotlivých přístrojů. Proto zde je potřeba napsat části programu přímo k nim. Tyto části se nazývají procedury. 4.5.5
Procedury
Důležitým prvkem u procedur je, že vždy musí mít svého vlastníka. Vyplývá to z funkce programu, kdy se procedury volají při události (stisk tlačítka, změna hodnoty, aktivace prvku). Pokud by neměla svého vlastníka, nemohla by tedy být zavolána. Nerozlišuje se, jestli jde o proceduru nebo funkci. Zde se jednoduše volá procedura, která může a nemusí vracet hodnotu. Předávání hodnoty je zde podobné jako v ostatních programech. Můžeme předávat parametry odkazem nebo hodnotou, stejně tak si můžeme v těle procedury definovat potřebné proměnné nebo přistupovat ke globálním.
Vlastní práce
31
Procedura OnActivate OnActivate je výjimečná událostní procedura, která je volána vždy při aktivaci přístroje. Přístroje nám zobrazují hodnoty, zapisují, nebo mají jiné funkce, a aktivace přístroje je čas, kdy k těmto událostem dochází. Mimo tyto aktivace přístroje nepracují, kromě těch, které se podílejí na interakci s okolím. Můžeme tedy napsat proceduru OnActivate(), která zajistí předání hodnot mezi kanály, vždy když se aktivuje přístroj indicator, který nám slouží k jednoduché indikaci stavu kanálu: procedure OnActivate(); begin vys_http[1000] = vs_dummy[1000]; end_procedure; Tento řádek nám zaručí předání hodnoty, ale musíme ho napsat pro každý indikátor. Nyní máme spojení mezi dvěma aplikacemi a možnost,jak předat hodnoty mezi kanály. Výsledné spojení:
Obr. 15
4.6
Výsledný přenos přes http protokol
Náhrada simulačního vstupu
Cílem práce je nahrazení simulovaného vstupu za pomocí vhodné technologie, tedy OPC standardu. Vzhledem k průtahům při dodání potřebného softwarového vybavení nebylo možné práci plně zrealizovat v době odevzdání dokumentace. Pracuji na dalším vývoji. Je předpoklad pro nasazení aplikace v laboratoři inteligentních systémů. Aktuální zrevidovaná verze bude k dispozici na https://akela.mendelu.cz/~xmac/Bakalarska%20prace/. Proto zde rozeberu teoretickou konfiguraci a nastavení ovladačů. Jako způsob, kterým nahradit simulační vstup, jsem vybral možnost propojení pomocí OPC standardu. Technologie OPC je v dnešní době poměrně rozšířená a využívá ji mnoho výrobců, proto by bylo dobré před samotným popisem ovladače, serveru a jejich konfigurace si popsat tento standard detailněji. 4.6.1
OPC standard
OPC (OLE for Process Control) je standard průmyslové komunikace, vytvořený ve spolupráci mnoha světových dodavatelů automatizačních prostředků, hardwaru a softwaru, v oblasti automatizace a společnosti Microsoft. Je společným rozhraním pro vzájemnou komunikaci
Vlastní práce
32
mezi různými zařízeními určenými pro monitorování a řízení technologických procesů. Jeho úkolem je zabránit závislosti daného monitorovacího nebo řídicího softwaru na výrobci hardwaru. Standard OPC je založen na metodách OLE/COM/DCOM. OLE neboli Object Linking and Embedding v překladu znamená propojení a vložení objektů. Objekty jsou definovány technologií COM, což představuje model komponent objektu. Microsoft využívá tuto technologii v rámci svých operačních systémů, aby umožnil vzájemnou komunikaci mezi aplikacemi. Pro řešení komunikace mezi více PC byla technologie COM rozšířena na DCOM neboli Distributed COM. Termín OPC je nyní znám i jako Open Connectivity, neboli otevřená konektivita využívající otevřené standardy. (STIANKO, 2012) 4.6.2
Architektura OPC
Komunikační protokol je založen na architektuře klient-server. Server je určen ke komunikaci se zařízením, které potřebujeme monitorovat. Informace z něj převádí na opc protokol, který poté odešle klientovi. Komunikace probíhá většinou přes už zavedenou podnikovou síť (nejčastěji LAN) viz obrázek
Obr. 16
Architektura OPC (FOXON, 2012)
V podstatě tedy můžeme říci, že pokud máme k zařízení patřičný OPC server a v programu, v kterém chceme data dále zpracovat, patřičný OPC klient, nemusíme řešit další ovladače, což je hlavním účelem tohoto standardu. 4.6.3
Specifikace OPC
V první verzi vydané už v roce 1998 byli tři specifikace,každá s jiným zaměřením: • OPC Data Access (OPC DA) - určuje přístup k datům v reálném čase. • Alarms and Events - stanovuje poskytování informací o výskytech specifikovaných událostí a výstrah klientům OPC. • OPC Historical Data Access - popisuje přístup k historickým datům uloženým v databázi. Později byli definovány další specifikace:
Vlastní práce
33
• OPC Overview - obecný popis metody OPC, jejích výhod a způsobu použití. • OPC Common Definitions and Interfaces - stanovuje případy použití většího počtu specifikací. • OPC Batch - podobně jako OPC DA, ale místo spojitých provozů je určena pro technologie s šaržovou výrobou (potravinářství, farmacie apod.). • OPC Security - určena k důkladnějšímu zabezpečení přístupu obsluhy při ovládání technologického zařízení z klientů OPC prostřednictvím serverů OPC s využitím zabezpečení systému Windows. • OPC XML DA - vymezuje integrování OPC a XML do internetových aplikací. • OPC Complex Data - určuje způsob popisu struktury komplexních dat a metody přístupu k těmto datům. (STIANKO, 2012) OPC standardu se daří a dosahuje velkého pokroku. Společnost OPC Foundation proto vydala v roce 2009 poslední sadu specifikací OPC - UA neboli Unified Architecture. Je to velká změna v tom, že tato nová specifikace sjednocuje minulé do jedné obsáhlé, založené na technologii SOA( architektura orientovaná na službu). 4.6.4
Přenos dat
Pro široké využití OPC standardu jsou definovány tyto typy komunikace: • Synchronní komunikace vždy čekající na přenos dat z/do zařízení. • Synchronní komunikace pracující s vyrovnávací pamětí serveru (cache). • Asynchronní komunikace (vždy komunikuje se zařízením). • Periodická komunikace serveru se zařízením a zpětné volání klienta při změně dat. • CW využívá ve verzi jedna pouze synchronní přenos, ve verzi dva pak přechází na asynchronní, kdy synchronní je volaný pouze na žádost klienta. (STIANKO, 2012) 4.6.5
OPC klient
CW řeší problematiku propojení z pohledu klienta. Zde jsou dva aspekty, které nás zajímají na straně serveru při jeho konfiguraci. Existují dvě hlavní verze standardu OPC Data Access( určuje přístup k datům v reálném čase) verze 1 a 2. Tyto verze se v určitých částích liší a to především v rozhraních, kdy ve verzi dvě byli určité rozhraní zcela nahrazeny jinými. Rozdíl je také v asynchronním přenosu dat, který ve verzi jedna trpěl nedostatky, a proto byl ve verzi dva přepracován. Konfigurace OPC klienta OPC klient v CW je v podstatě jen další ovladač, a platí pro něj stejná pravidla. Musí mít svůj mapovací a parametrický soubor. Mapovací obsahuje jako u ostatních seznam kanálů, jejich směr a rozsah. Pro parametrický soubor už je nastavení jiné. Jeho struktura odpovídá souborům *.INI. Soubor je rozdělený na dvě sekce [server] a [channels]. Sekce [server] musí obsahovat identifikátor třídy serveru, tzv. CLSID (Class Identifier). CLSID je globálně unikátní identifikátor (GUID — Globally Unique Identifier), 128-bitové číslo používané v COM k jednoznačné identifikaci tříd, rozhraní, typových knihoven apod. Pokud má být server vytvořen na vzdáleném počítači, je nutno definovat parametr host=\\remotehost. Dále je zde možnost nastavit synchronní komunikaci pro OPC servery
Vlastní práce
34
verze dvě a to pomocí příkazu sync=true. Pro možnost, kdy OPC server potřebuje čas pro svoji inicializaci, je zde příkaz wait_time=5, který udává prodlevu v sekundách. Sekce [channels] obsahuje definice jednotlivých kanálů v podobě číslo_kanálu=identifikátor položky OPC serveru. Pokud identifikátor položky OPC serveru označuje pole, na místě čísla kanálu je interval čísel zahrnující celkový počet prvků pole. První a poslední číslo kanálu jsou odděleny znakem '-'. Protože na identifikátor položky nejsou ve standardu OPC kladena žádná omezení, jsou za identifikátor považovány všechny znaky za prvním rovnítkem až po konec řádku. Definice kanálu nevyžaduje žádné další údaje (např. typ dat nebo směr přenosu), protože OPC rozhraní umožňují všechny informace získat za běhu serveru. Tomuto ,,ručnímu" vytvoření a nastavení se lze vyhnout, protože CW dodává spolu s ovladačem i aplikaci pro vytvoření mapovacího a parametrického souboru. Aplikace sama detekuje OPC servery, má přitom na výběr ze tří způsobů jejich vyhledání. Je zde možnost nastavit i verze OPC. Dále se zde dají kanály nastavit i s jejich číslem pomocí grafického rozhraní, také prodleva a synchronní přenos. Výsledek ale zůstává stejný, a je dobré vědět o obou způsobech. Příklad parametrického souboru: [server] CLSID={F8582CF2-88FB-11D0-B850-00C0F0104305} host=\\remotehost [channels] 100=Random.Int4 103=Random.Real4 104=Random.Real8 105=Square Waves.Real8 108=Write Only.UInt2 109=Write Only.UInt4 110-119=Random.StringArray 120-129=Random.Real8Array 4.6.6
OPC server
Je program, který komunikuje s připojeným zařízením jeho komunikačním protokolem (např. Modbus, MPI, PPI, atd...), získaná data převádí do formátu OPC a poskytuje je nadřazeným aplikacím ve formátu OPC. Konfiguraci serveru budeme moct rozdělit na dvě části. V první by jsme se zaměřili na nastavení samotné komunikace mezi objekty, v druhé pak na hodnoty, které se budou přenášet. Jak bylo řečeno, úkolem první části je konfigurace samotných zařízení. Můžeme k nim přistupovat jako ke dvěma objektům, které vzájemně spojuje sběrnice viz obrázek:
Vlastní práce
Obr. 17
35
Propojení PC stanice/Simatic
Pro spojení přes síť musíme nastavit u obou prvků IP adresu. U objektu, který nám představuje jednotku Simatic, můžeme mít v závislosti na programu,v kterém konfiguraci provádíme, dvojí možnost. Nastavení adresy ručně nebo program bude sám schopný detekce zařízení a jeho identifikace. Druhý krok pak představuje nastavení IP adresy u PC stanice. V této části je ještě jedna podstatná věc. U PC stanice máme v podstatě dvě rozhraní, jedno pro komunikaci přes síť a druhé, které nám představuje OPC server samotný. Zde je ještě potřeba nastavit propojení mezi nimi. Po celkovém nastavení otestujeme komunikaci mezi zařízeními. Druhá část se týká samotného nastavení prvků, které bude OPC server monitorovat. Zde bychom už měli mít k dispozici seznam hodnot, které nám poskytuje stanice Simatic. V OPC serveru budeme muset vytvořit jednotlivé položky a přiřadit jim hodnoty se seznamu Simaticu. Výsledný přenos mezi serverem a klientem by se poté dal symbolicky znázornit následovně:
Obr. 18
Komunikace mezi aplikaci CW a OPC serverem
Aplikace se v tuto chvíli chová jako klient, kdy vyvolává komunikaci s žádostí o data. Žádost předá ovladači, který ji přeloží na komunikaci přes OPC standard a pošle ji na OPC server. Z něj pak ovladač opět přeloží data pro aplikaci, aby je mohla dále zpracovat.
4.7
Vizualizace
Cílem bylo vytvořit aplikaci, kde by se dali potřebné informace najít rychle a přehledně. Po menší úvaze jsem se rozhodl pro vzhled aplikace v podobě reálných obrazů jednotlivých strojů. Následně pak přiřazení jednotlivých indikátorů ke spínačům na obrázku. Velká výhoda systému CW je v jeho možnostech nastavení, které platí i u indikátorů. Kromě základních vlastností lze nastavit i jeho vzhled. Je tak možné mu přiřadit jiný vzhled pro stavy true/false, než blikající žárovku, která se do této aplikace nehodí. Menší zádrhel byl nový vzhled. CW podporuje pouze formát *.ico pro jednotlivé ikony. Navíc rozeznává svůj vlastní formát *.ico a formát OS. Oba mají stejnou příponu, ale jejich zobrazení se značně liší. Pro formát OS nejde nastavit velikost, bere se automaticky podle systému. Proto je lepší navrhnout si vlastní ikonu v programu Ikoner, který je dodáván současně s CW.
Vlastní práce
36
Poslední věc byla rozhodnutí v umístění indikátorů. Byly zde dvě možnosti. Umístit pouze indikátory k jednotlivým spínačům, nebo ještě duplikovat každý indikátor a udělat druhou indikaci na boku aplikace, kde by byly seřazeny, aby výškově odpovídali jednotlivým spínačům. První možnost se mi zdála jako nedostatečná. Výsledný vzhled:
Obr. 19
Výsledný vzhled aplikace
Diskuze a závěr
37
5 Diskuze a závěr Se systémem Control Web jsem neměl doposud žádné zkušenosti, ani s podobnými systémy. Práci jsem si vybral z důvodu možnosti pracovat na něčem novém, s čím jsem se během studia nesetkal. Také mi téma přišlo zajímavé a perspektivní do budoucna. A za toto rozhodnutí jsem velmi rád. Program mě během prvních pár hodin zaujal svými možnostmi a funkčností. Při tvorbě aplikace jsem postupoval po jednotlivých krocích, kdy každému předcházelo prostudování dokumentace programu. Každý z těch kroků byl zaměřený na určitou část, proto bylo stále co pročítat. Byla zde i nutnost uvědomit si a pracovat jinak, než jsem byl zvyklý z klasického programování. Cílem práce bylo zjistit, jaké jsou možnosti propojení pneumatické linky FMS 200 a systému Control Web a následné navržení aplikace, která by toto spojení umožnila. Po analýze možnostech propojení a navržení nejvhodnější varianty byla vytvořena aplikace sloužící pro přehlednou vizualizaci jednotlivých přístrojů. Momentálně jsou vstupy simulované, z důvodu nečekaného opoždění při dodávání softwaru a nutnosti použití jiného programu pro konfiguraci poslední části. Na konfiguraci stále pracuji a předpokládám reálné nasazení aplikace v prostorách laboratoře. Zpětně můžu hodnotit, že mi tato práce dala velké množství zkušeností, jak v obecném řešení problému, tak co se týče konkrétní oblasti programování a automatizace.Získal jsem díky tomu povědomí o vytváření a funkčnosti těchto typů programů a chodu automatizační techniky. Je zde i možnost dalšího pokračování v této oblasti, kdy by se dalo rozvíjet řízení PLC strojů dalších prvků. Při rozhodování o možnostech napojení reálného prvku mě oslovil OPC standard svoji základní myšlenkou. Zbavení přenosu dat a jejich zpracování na závislosti programů a softwarové podpoře od výrobce zařízení, respektive na podmínkách programu pro zpracování informací. OPC server, který je schopný s daným prvkem komunikovat a dostat z něj potřebné informace, tyto data přetransformuje do podoby OPC standardu a pomocí sítě je odešle OPC klientovi, který už je přetransformuje do podoby, kterou vyžaduje program. Komunikace s celou řadou prvků tak může probíhat v rámci jedné sítě za pomocí jednoho protokolu. Vzhledem k široké podpoře tohoto standardu, je v dnešní době velké množství jako OPC serverů tak i klientů, a výrobci zařízení už s touto možností počítají a zahrnují ji do svých technologií. Úskalí zde může být konfigurace samotných serverů, respektive klientů, kdy výrobce jednotlivých zařízení dodává softwarovou podporu nejen pro OPC standard, a pro konfiguraci může dodat jeden obecný program pro různé standardy. Zde pak záleží na dobře zpracované dokumentaci a další podpoře od výrobce. V této práci je rozhodně prostor pro další vývoj. Díky OPC technologii je zde možnost napojení dalších pneumatických či jiných prvků, a také nejen jejich vizualizace, ale i řízení. Díky OPC standardu budeme mít možnost výběru i několika různých programů pro zpracování těchto dat v závislosti na naší potřebě.
Literatura
38
6 Literatura NĚMEC, ZDENĚK. Prostředky automatického řízení: elektrické [online]. Ústav automatizace a informatiky Fakulta strojního inženýrství Vysoké učení technické v Brně, 2002 [cit. 201205-21]. Dostupné z: http://drogo.fme.vutbr.cz/opory/pdf/PAR_el.pdf BÍLÝ, R. Control Web 2000. Praha: Computer Press, 1999. ISBN 80-7226-258-0.3. CHLEBNÝ, JAN. Automatizace a automatizační technika. 4., aktualiz. vyd. Brno: Computer Press, 2009, vii, 296 s. ISBN 978-80-251-2523-6. ARLOW, JIM A ILA NEUSTADT. UML 2 a unifikovaný proces vývoje aplikací: objektově orientovaná analýza a návrh prakticky. Vyd. 1. Překlad Bogdan Kiszka. Brno: Computer Press, 2007, 567 s. ISBN 978-80-251-1503-9. ŠMEJKAL, LADISLAV A LUBOŠ URBAN. Programovatelné automaty – PLC, nebo PAC?. [online]. [cit. 2012-04-21]. Dostupné z: http://www.odbornecasopisy.cz/index.php?id_document=28832 SIEMENS. Efektivní a progresivní automatizace [online]. 2005. vyd. [cit. 2012-05-21]. Dostupné z: http://www1.siemens.cz/ad/current/content/data_files/automatizacni_systemy/prumy slove_automatizacni_systemy_simatic/simatic_plc/simatic_s7_300/_prospekty/overvie w_simatic_s7_300_2005_cz.pdf SMC. International Training: FMS 200 [online]. 2012. vyd. [cit. 2012-04-16]. Dostupné z: http://www.smctraining.com/ENG/fms200.htm FOXON. OPC Servery. [online]. [cit. 2012-04-20]. Dostupné z: http://www.foxon.cz/opcservery-c-72.html?zenid=08aba7be5abb0d0eb521d94662da9d3b STIANKO, MARTIN A JAROMÍR PETERKA. OPC v průmyslové komunikaci. [online]. [cit. 2012-0421]. Dostupné z: http://www.odbornecasopisy.cz/index.php?id_document=32378 MORAVSKÉ PŘÍSTROJE. Control Web [online]. 4.10.2010. [cit. 2012-04-15]. Dostupné z: http://www.mii.cz/art?id=179&lang=405 MORAVSKÉ PŘÍSTROJE. Control Web 6: Dokumentace Control Web. 2012. vyd.
