ˇ ´ ˇen´ı technick´ Cesk e vysok´ e uc e v Praze ´ Fakulta elektrotechnicka ˇ´ıdic´ı techniky Katedra r
´ PRACE ´ DIPLOMOVA
Automatick´ e bezobsluˇ zn´ eˇ r´ızen´ı syst´ em˚ u z´ aloˇ zn´ıch motorgener´ atorov´ ych zdroj˚ u
Praha, 2009
Jan Bedn´aˇr
ˇ ´ ˇen´ı technick´ Cesk e vysok´ e uc e v Praze ´ Fakulta elektrotechnicka ˇ´ıdic´ı techniky Katedra r
Automatick´ e bezobsluˇ zn´ eˇ r´ızen´ı syst´ em˚ u z´ aloˇ zn´ıch motorgener´ atorov´ ych zdroj˚ u
ˇ sitel: Reˇ Vedouc´ı pr´ace: Oponent:
Jan Bedn´aˇr Ing. Pavel Burget Ing. Milan Egart
ˇ ıdic´ı techDiplomov´a pr´ace v r´amci prezenˇcn´ıho magistersk´eho studia na katedˇre R´ ˇ niky, fakulty elektrotechnick´e, Cesk´eho vysok´eho uˇcen´ı technick´eho v Praze. ˇ ıdic´ı technika Studijni obor: MKM01 - R´
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem zadanou diplomovou pr´aci zpracoval s´am s pˇrispˇen´ım vedouc´ıho pr´ace a konzultanta a pouˇz´ıval jsem pouze podklady (literaturu, projekty, SW atd.) uveden´e v pˇriloˇzen´em seznamu. M´am d˚ uvod proti uˇzit´ı tohoto ˇskoln´ıho d´ıla ve smyslu § 60 Z´akona ˇc.121/2000 Sb. , o pr´avu autorsk´em, o pr´avech souvisej´ıc´ıch s pr´avem autorsk´ ym a o zmˇenˇe nˇekter´ ych z´akon˚ u (autorsk´ y z´akon).
V Praze dne podpis
i
Podˇ ekov´ an´ı Je mou milou povinnost´ı podˇekovat lidem, bez nichˇz by tato diplomov´a pr´ace nevznikla. Dˇekuji pˇredevˇs´ım vedouc´ımu pr´ace Ing. Pavlu Burgetovi za konzultace k v´ yvojov´emu prostˇred´ı CoDeSys a pˇripom´ınky k navrh˚ um strategie ˇr´ızen´ı. D´ale konzultantu Ing. Milanu Egartovi za cenn´e rady pˇri n´avrhu ˇr´ıdic´ıho algoritmu. D´ıky patˇr´ı t´eˇz Ing. Martinu K˚ urkovi za rady k v´ yvojov´emu prostˇred´ı ControlWeb. V neposledn´ı ˇradˇe m´ ym rodiˇc˚ um a sestˇre za podporu bˇehem cel´eho studia.
ii
Abstrakt Pˇredkl´adan´a diplomov´a pr´ace pojedn´av´a o v´ yvoji programov´eho ˇreˇsen´ı pro automatick´e bezobsluˇzn´e pˇripojov´an´ı z´aloˇzn´ıho motorgener´atoru k z´alohovan´e soustavˇe. Fyzick´a ˇc´ast syst´emu byla vyprojektov´ana pro danou aplikaci - ˇreˇsen´ı na m´ıru“. C´ılem ” vytv´aˇren´eho programu pro PLC bylo ˇreˇsen´ı pˇrepojov´an´ı z´alohovan´e z´atˇeˇze mezi prim´arn´ı ´ s´ıt´ı a z´aloˇzn´ım zdrojem. Udaje o technologii jsou vizualizov´any v panelov´em PC ve dveˇr´ıch rozvadˇeˇce. Kvalita nap´ajec´ı soustavy i z´alohovan´e soustavy je mˇeˇrena speci´aln´ımi pˇr´ıstroji. Souˇc´ast´ı ˇreˇsen´ı kromˇe programu pro ovl´ad´an´ı pˇrep´ın´an´ı je i monitorov´an´ı jednotliv´ ych stav˚ u obou motorgener´ator˚ u, stav˚ u v´ ykonov´ ych pˇrep´ınac´ıch prvk˚ u v rozvadˇeˇc´ıch, sledov´an´ı a archivov´an´ı dat z mˇeˇric´ıch pˇr´ıstroj˚ u. Fyzick´e propojen´ı PLC kontrol´eru s panelov´ ym PC je provedeno dnes standardn´ım Ethernetem 100 Mb/s a data se pˇren´aˇsej´ı pomoc´ı otevˇren´eho protokolu pro vz´ajemnou komunikaci r˚ uzn´ ych typ˚ u zaˇr´ızen´ı MODBUS TCP/IP. Mˇeˇric´ı pˇr´ıstroje jsou ke kontrol´eru PLC fyzicky pˇripojeny pr˚ umyslovou s´eriovou datovou linkou RS-485 a protokol je MODBUS RTU. Cel´ y syst´em je vzd´alenˇe monitorov´an z centr´aln´ıho dohledu. K tomuto u ´ˇcelu jsou d˚ uleˇzit´e stavy a hodnoty technologie sledov´any a zas´ıl´any pomoc´ı s´ıt’ov´eho protokolu pro spr´avu s´ıt’ov´ ych prvk˚ u SNMP na server. Zde jsou archivov´any a je moˇzn´e sestavovat r˚ uzn´e statistiky.
iii
Abstract Presented diploma thesis discuss the development of software solution of operation free connection back-up motorgenerator with deposit system. Hardware of the solution was done and was designed directly for this aplication. The goal of program in PLC was solution of making reconnection of back-up part of technology between primary power line and secondary power source. Data of whole technology can bee seen in vizualization program in panel PC, which is situated in doors of control panel.Quality of power system line and back up system line is measured with special devices. Is included besides program to contorl switching and monitor individual states of both dieselagregates, states of power switch units in control panels, watch and archive of dates from measurement units. Hardware connection between PLC and panel PC is realized by nowadays standard Ethernet 100 Mb/s. Data are transmited with open source protocol, which is designed to communication of different types of units, MODBUS TCP/IP. Measuring units are connected with PLC via industrial serial bus named RS-485 and protocol is MODBUS RTU. Whole system is remotely monitored by central supervisor. To this purpose are significant states and values of technology transmited via network protocol SNMP. In central supervisor station are data archived and is able to make various statistics.
iv
ˇ e Vysok´e Uˇcen´ı Technick´e v Praze Cesk´ Fakulta elektrotechnick´a Katedra ˇr´ıdic´ı techniky
´ ´I DIPLOMOVE ´ PRACE ´ ZADAN Student:
Bc. Jan Bedn´ aˇ r
Studijn´ı program: Elektrotechnika a informatika (magistersk´ y), strukturovan´ y ˇ Obor: Kybernetika a mˇeˇren´ı, blok KM1 - R´ıdic´ı technika N´azev t´ematu: Automatick´e bezobsluˇzn´e ˇr´ızen´ı syst´em˚ u z´aloˇzn´ıch motorgener´atorov´ ych zdroj˚ u Pokyny pro vypracov´an´ı 1. Teoretick´ y rozbor funkce syst´emu motor-generatorov´ ych zdroj˚ u a v´ ykonov´ ych pˇrep´ınac´ıch syst´em˚ u ATS-Automatic Transfer Switch. 2. Teoretick´ y rozbor ˇcasov´eho harmonogramu a topologie ˇr´ızen´ı. ˇ - sestava pro modul´arn´ı programovateln´ 3. N´avrh ˇreˇsen´ı RS y automat (PLC). 4. N´avrh ˇreˇsen´ı vzd´alen´eho ˇr´ızen´ı, dohledu a vizualizace na PC-komunikace ModBus. ˇ 5. Komplexn´ı realizace RS. 6. Implemetace registru ud´alost´ı a diagnostiky syst´emu. 7. Vizualizace oper´atorsk´eho grafick´eho rozhran´ı (LCD-touchscreen) s vyuˇzit´ım prostˇred´ı ControlWeb5. 8. Popis ostatn´ıch moˇznost´ı ˇr´ıdic´ıho syst´emu. Seznam odborn´e literatury: Dod´a vedouc´ı pr´ace
Vedouc´ı pr´ace: Ing. Pavel Burget
Platnost zad´an´ı: do konce zimn´ıho semestru 2008/2009
L.S. ˇ prof. Ing. Michael Sebek, DrSc. doc. Ing. ˇ Boris Sim´ak, CSc. vedouc´ı katedry
dˇekan
V Praze dne 10.9.2007
vi
Obsah Seznam obr´ azk˚ u
ix
Seznam tabulek
xi
Seznam zkratek
xiii
´ 1 Uvod 1.1 Z´aloˇzn´ı zdroje el. energie a jejich funkce . . . . . . . . . . . . . . . . . 1.1.1 Motorgener´ator a jeho funkce . . . . . . . . . . . . . . . . . . . 1.1.1.1 Princip ˇcinnosti . . . . . . . . . . . . . . . . . . . . . . 1.1.1.2 Proveden´ı a regulace . . . . . . . . . . . . . . . . . . . 1.1.1.3 N´avrat k s´ıti . . . . . . . . . . . . . . . . . . . . . . . 1.1.1.4 Vybaven´ı a technologie . . . . . . . . . . . . . . . . . . 1.1.1.5 Provozn´ı m´ody z´aloˇzn´ıch motorgener´atorov´ ych zdroj˚ u. 1.1.2 Zdroje UPS - Uninterruptible Power Supply . . . . . . . . . . . 1.1.2.1 Princip ˇcinnosti . . . . . . . . . . . . . . . . . . . . . . 1.2 Pˇrep´ınac´ı, monitorovac´ı prvky a jejich funkce . . . . . . . . . . . . . . . 1.2.1 Motorov´ y pˇrep´ınaˇc SOCOMEC ATyS . . . . . . . . . . . . . . . 1.2.2 Automatick´ y pˇrep´ınaˇc s´ıt´ı LOVATO ATL . . . . . . . . . . . . 1.2.3 Multifunkˇcn´ı mˇeˇric´ı pˇr´ıstroj SOCOMEC DIRIS A4x . . . . . . . 1.3 Obecn´e poˇzadavky na ˇr´ıdic´ı syst´em . . . . . . . . . . . . . . . . . . . . ˇ ızen´ı rozvadˇeˇc˚ 1.3.1 R´ u ATS 1000 a ATS 200 . . . . . . . . . . . . . . . ˇ 1.3.2 R´ızen´ı rozvodny . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Datov´ a komunikace a pouˇ zit´ e protokoly 2.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Princip a form´at r´amce . . . . . . . . . . . . . . . . . . . . 2.2 RS-485 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Protokol TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 TCP - Transmission Control Protocol . . . . . . . . . . . . 2.3.2 IP - Internet Protocol . . . . . . . . . . . . . . . . . . . . 2.3.2.1 Smˇerov´an´ı, verze IP, IP adresy a jejich struktura 2.4 Protokol MODBUS . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Datov´ y model . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Implementace MODBUSu . . . . . . . . . . . . . . . . . . vii
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . . . . . . .
1 3 3 3 5 6 7 8 9 10 12 12 14 14 16 16 20
. . . . . . . . . .
23 23 23 24 27 28 29 29 31 33 37
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
37 37 40 40 42 44 45
3 V´ yvojov´ a prostˇ red´ı 3.1 CoDeSys - Controlled Development System . . . . . . . . . 3.1.1 Uk´azkov´ y program . . . . . . . . . . . . . . . . . . 3.2 ControlWeb 5 SP11 . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Zaloˇzen´ı nov´e aplikace . . . . . . . . . . . . . . . . 3.2.2 Datov´e elementy, ovladaˇce a parametrick´e soubory . 3.2.3 Uˇzivatelsk´a pr´ava . . . . . . . . . . . . . . . . . . . 3.2.4 Pˇreklad a generov´an´ı aplikace . . . . . . . . . . . . 3.2.5 Datovˇe ˇr´ızen´e aplikace . . . . . . . . . . . . . . . . 3.2.5.1 Rozbˇeh a zastaven´ı aplikace . . . . . . . . 3.2.5.2 Periodick´e ˇcasov´an´ı . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
47 47 51 59 60 62 64 66 66 67 68
. . . . . . . . . .
69 69 70 71 72 73 73 76 76 81 86
5 Program pro panelov´ e PC v ControlWebu 5.1 Propojen´ı ControlWebu a PLC WAGO . . . . . . . . . . . . . . . . . . . 5.1.1 Tvorba aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89 89 94
2.5
2.4.2.1 MODBUS TCP/IP . . . . . . . . . . . . 2.4.2.2 MODBUS na s´eriov´e lince . . . . . . . . Protokol SNMP - Simple Network Management Protocol 2.5.1 Historie . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 SNMP Global Naming Tree . . . . . . . . . . . . 2.5.3 Typy SNMP objekt˚ u . . . . . . . . . . . . . . . . 2.5.4 MIB datab´aze - Management Information Base .
4 Program pro PLC WAGO ˇ ıdic´ı syst´em rozvadˇeˇc˚ 4.1 R´ u ATS1000 a ATS200 4.1.1 Program analogy . . . . . . . . . . 4.1.2 Program init SNMP . . . . . . . . . 4.1.3 Program komunikace MIB . . . . . . 4.1.4 Program komunikace ModBus . . . . 4.1.5 Program komunikace RS485 . . . . 4.1.6 Program PLC PRG . . . . . . . . . . 4.1.7 Program rizeni gen1 . . . . . . . . ˇ ıd´ıc´ı syst´em nov´e rozvodny . . . . . . . . . 4.2 R´ 4.3 S´ıt’ov´e promˇenn´e . . . . . . . . . . . . . . .
6 Z´ avˇ er
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
101
A Obsah pˇ riloˇ zen´ eho CD
I
viii
Seznam obr´ azk˚ u 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19
Konstrukce synchronn´ıho stroje . . . . . . . . . Princip synchronn´ıho stroje . . . . . . . . . . . Uk´azka motorgener´ator˚ u . . . . . . . . . . . . . pˇr´ıklad motorgener´atorov´eho zdroje 2000 kVA . pˇr´ıklady UPS zdroj˚ u . . . . . . . . . . . . . . . UPS - Voltage Dependent . . . . . . . . . . . . UPS - Voltage Independent . . . . . . . . . . . UPS - Voltage and Frequency Independent . . . Uk´azka v´ ykonov´eho pˇrep´ınˇce SOCOMEC ATyS Zjednoduˇsen´e sch´ema pˇripojen´ı . . . . . . . . . Mechanismu pˇrep´ın´an´ı u SOCOMEC ATYSu . . Uk´azka automatick´eho pˇrep´ınaˇce s´ıt´ı ATL . . . Uk´azka multifunkˇcn´ıho mˇeˇric´ıho pˇr´ıstroje DIRIS Sch´emata zapojen´ı . . . . . . . . . . . . . . . . Blokov´e sch´ema cel´eho syst´emu . . . . . . . . . Dlouhodob´ y v´ ypadek . . . . . . . . . . . . . . . Kr´atkodob´ y opakovan´ y v´ ypadek . . . . . . . . . Princip oˇsetˇren´ı v´ ypadku . . . . . . . . . . . . . Princip pˇrip´ın´an´ı a odep´ın´an´ı outlet˚ u . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
4 4 6 8 10 10 11 11 12 13 13 14 15 15 16 17 17 19 22
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15
Ethernetov´ y r´amec . . . . . . . . . . . . . . . . . . . . . . . . . . . Princip zapojen´ı sbˇernice RS-485 . . . . . . . . . . . . . . . . . . . Omezen´ı na maxim´aln´ı pˇrenosovou rychlost . . . . . . . . . . . . . Pˇr´ıklad implementace protokolu MODBUS . . . . . . . . . . . . . . Z´akladn´ı tvar MODBUS zpr´avy . . . . . . . . . . . . . . . . . . . . MODBUS transakce s bezchybn´ ym proveden´ım poˇzadavku . . . . . Datov´ y model (a) s oddˇelen´ ymi bloky, (b) s jedin´ ym blokem . . . . Obecn´ y postup zpracov´an´ı MODBUS poˇzadavku na stranˇe serveru . Pˇrehled funkˇcn´ıch k´od˚ u. . . . . . . . . . . . . . . . . . . . . . . . . MODBUS TCP/IP zpr´ava . . . . . . . . . . . . . . . . . . . . . . . MODBUS zpr´ava na s´eriov´e lince . . . . . . . . . . . . . . . . . . . RTU r´amec zpr´avy . . . . . . . . . . . . . . . . . . . . . . . . . . . ASCII r´amec zpr´avy . . . . . . . . . . . . . . . . . . . . . . . . . . Form´at SNMP zpr´avy) . . . . . . . . . . . . . . . . . . . . . . . . . SNMP Global Naming Tree . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
24 24 26 31 31 32 33 34 35 37 38 39 39 42 43
ix
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12
V´ yvojov´e prostˇred´ı CoDeSys 2.3.8.5 . . . . . . . . . . . . . Task manager . . . . . . . . . . . . . . . . . . . . . . . . . HW konfigurace PLC . . . . . . . . . . . . . . . . . . . . . Z´akladn´ı struktura programu - softwarov´ y task manager . Program pro ˇr´ızen´ı ventil´atoru chladiˇce . . . . . . . . . . . Program pro ovl´ad´an´ı ventilu v kombinaci jazyk˚ u LD a ST Vizualizace . . . . . . . . . . . . . . . . . . . . . . . . . . Komunikaˇcn´ı parametry a nahr´av´an´ı projektu do PLC . . webserver PLC . . . . . . . . . . . . . . . . . . . . . . . . Logo ControlWebu . . . . . . . . . . . . . . . . . . . . . . Spr´ava datov´ ych element˚ u a kan´al˚ u . . . . . . . . . . . . . Uˇzivatelsk´e u ´ˇcty . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
49 51 52 54 55 56 57 58 59 59 63 65
4.1 4.2 4.3 4.4
Blok programu pˇrepnut´ı stykaˇce do polohy 1 . . . . . . . . . . . . . . . . Prvn´ı ˇc´ast programu - nastaven´ı do v´ ychoz´ıho stavu . . . . . . . . . . . . Druh´a ˇc´ast programu - testov´an´ı v´ ypadku, start agreg´atu . . . . . . . . . Tˇret´ı ˇc´ast programu - pˇrepnut´ı na gener´ator, testov´an´ı s´ıtˇe po dobu T3 , pˇrepnut´ı zpˇet na s´ıt’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ Ctvrt´ a ˇc´ast programu - dochlazen´ı a vyhˇr´ıv´an´ı agreg´atu . . . . . . . . . . Prvn´ı ˇc´ast hlavn´ıho programu - oˇsetˇren´ı pˇrip´ın´an´ı outlet˚ u . . . . . . . . . Druh´a ˇc´ast hlavn´ıho programu - oˇsetˇren´ı pˇrip´ın´an´ı/odp´ın´an´ı outlet˚ u dle mnoˇzstv´ı paliva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vlasnosti sd´ılen´ ych promˇenn´ ych . . . . . . . . . . . . . . . . . . . . . . . (a) Bez sd´ılen´ ych promˇenn´ ych (b) Sd´ılen´e promˇenn´e netvar001“ . . ” Bin´arn´ı vstupy PLC WAGO 750-430 . . . . . . . . . . . . . . . . . . . . Diagnostick´ y n´astroj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deklarace kan´al˚ u v prostˇred´ı CW . . . . . . . . . . . . . . . . . . . . . . V´ yvoj grafick´e podoby aplikace . . . . . . . . . . . . . . . . . . . . . . . Celkov´ y pohled na vizualizaci . . . . . . . . . . . . . . . . . . . . . . . .
77 77 78
4.5 4.6 4.7 4.8 4.9 5.1 5.2 5.3 5.4 5.5
x
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
79 80 83 83 86 87 91 93 95 95 100
Seznam tabulek 1.1 1.2 1.3
Vysvˇetlen´ı ˇcasov´ ych interval˚ u . . . . . . . . . . . . . . . . . . . . . . . . Vysvˇetlen´ı priorit pˇripojov´an´ı outlet˚ u . . . . . . . . . . . . . . . . . . . . Odpojov´an´ı outlet˚ u v z´avislosti na mnoˇzstv´ı paliva . . . . . . . . . . . .
18 20 21
2.1 2.2
Datov´ y model MODBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . MODBUS chybov´e k´ody . . . . . . . . . . . . . . . . . . . . . . . . . . .
33 36
3.1 3.2
Seznam programovac´ıch jazyk˚ u . . . . . . . . . . . . . . . . . . . . . . . Uk´azka adresace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50 52
5.1 5.2
Modifik´atory pˇrenosu z CW do PLC . . . . . . . . . . . . . . . . . . . . Modifik´atory pˇrenosu z CW do PLC . . . . . . . . . . . . . . . . . . . .
90 91
xi
xii
Seznam zkratek Symbol
V´ yznam
AES ARP ATS DES IAB IANA IP ISO MTG, MG MIB OID SNMP TCP UPS
Advanced Encryption Standard Address Resolution Protocol Automatic Transfer Switch Data Encryption Standard Internet Acitivities Board Internet Assigned Numbers Authority Internet Protocol International Organization for Standardization Motor-generator Management information base Object Identifier Simple Network Protocol Transmission Control Protocol Uninterruptible Power Supply (Source)
ADU HDLC PDU SDLC
Protokoly Administration Data Unit High-Level Data Link Control Protocol Data Unit Standard-Level Data Link Control
NRZ NRZI
K´ odov´ an´ı dat Non Return to Zero Non Return to Zero Invert
xiii
Symbol
V´ yznam
CFC FBD IL LD PLC POU SFC ST
PLC automat WAGO Continuous Function Chart Function Data Box Instruction List Ladder Diagram Program Logic Controller Program Organisation Unit Sequential Function Chart Statement List aplikace ControlWeb
CW
ControlWeb UPS
VD VFD VFI VI
Voltage Voltage Voltage Voltage
Dependent and Frequency Dependent and Frequency Independent Independent
xiv
Kapitola 1 ´ Uvod V dneˇsn´ı dobˇe, kdy se spoleˇcnost st´av´a st´ale v´ıce z´avisl´a na elektrick´e energii, m˚ uˇze jej´ı nedostatek ˇci dokonce v´ ypadek znamenat velk´e probl´emy v mnoha pˇr´ıpadech doprov´azen´e finanˇcn´ımi ztr´atami. Proto jsou d˚ uleˇzit´e technologie vybavov´any z´aloˇzn´ımi zdroji energie. Ty lze jednoduˇse rozdˇelit na z´aloˇzn´ı zdroje pro kr´atk´e v´ ypadky a z´aloˇzn´ı zdroje pro dlouhodob´e dod´avky v´ ykonu. Pokud je poˇzadavek pouze na kr´atkodob´e z´alohov´an´ı, postaˇc´ı jako z´aloˇzn´ı zdroje UPS. Ty jsou v z´avislosti na konstrukci rychl´e a nˇekter´e typy dokonce pˇreklenou v´ ypadek bez odpojen´ı z´ateˇze. Takov´ y z´aloˇzn´ı zdroj je moˇzn´e pouˇz´ıt napˇr. pro m´alo v´ yznamn´e datov´e centrum, kdy UPS dod´avaj´ı energii po dobu potˇrebnou k bezpeˇcn´emu vypnut´ı poˇc´ıtaˇc˚ u. V pˇr´ıpadˇe, kdy je poˇzadavek na dlouhodob´e z´alohov´an´ı elektrickou energi´ı, je nutn´e uvaˇzovat napˇr. o motorgener´atoru. Tato varianta umoˇzn ˇuje z´alohovat v podstatˇe neomezenou dobu (pokud bude pr˚ ubˇeˇznˇe doplˇ nov´ano palivo a splnˇeny poˇzadavky na start stroje). Proto se v praxi ˇcasto vyuˇz´ıv´a spojen´ı UPS a motorgener´atoru, kdy UPS udrˇzuj´ı nap´ajen´ı po dobu startov´an´ı agreg´atu. Tato varianta se oznaˇcuje jako okamˇzit´e, nepˇreruˇsiteln´e pˇrevzet´ı z´atˇeˇze. Kdyˇz je agreg´at nastartov´an a pˇripojen´ y synchronn´ı stroj je schopen dod´avat energii do z´atˇeˇze, je nutn´e pˇrepojit technologie z prim´arn´ı s´ıtˇe na z´aloˇzn´ı motorgener´ator. Na trhu existuj´ı tzv. ATS (Automatic Transfer Switch)jednotky, kter´e pˇri napˇet´ı z motorgener´atoru poˇzadovan´ ych parametr˚ u automaticky zajist´ı pˇrepnut´ı. Pojem ATS, nebo-li Automatic Transfer Switch je definov´an americk´ ym patentem pod ˇc´ıslem US Patent 68761031 s n´azvem Automatic Transfer Switch system and controller. V abstraktu lze nal´ezt z´akladn´ı specifikace. Napˇr´ıklad ukazuje, jak zahrnout do jedin´eho syst´emu prim´arn´ı zdroj energie (jeho pˇr´ıpadnou regulaci, filtraci a pˇremˇenu na uˇziteˇcn´ y ˇ ıdic´ı syst´em tak´e implementuje pˇrep´ınac´ı prvky (hovoˇr´ı v´ ykon) a z´aloˇzn´ı zdroj energie. R´ se o elektromagnetick´em principu), vestavˇen´ y mikrokontrol´er pro monitorov´an´ı s´ıt’ov´eho a generovan´eho napˇet´ı a v neposledn´ı ˇradˇe tak´e uˇzivatelsk´e rozhran´ı pro ovl´ad´an´ı cel´eho syst´emu a z´ısk´av´an´ı potˇrebn´ ych informac´ı o syst´emu. Pro pˇrehlednost se uˇz´ıvaj´ı LED kontrolky pro rychl´e z´ısk´an´ı souhrnn´e informace o ATS syst´emu. Tato diplomov´a pr´ace se zab´ yv´a ˇreˇsen´ım obdobn´eho syst´emu, monitorov´an´ım jeho stavu a tak´e specifick´ ym ˇreˇsen´ım pˇripojov´an´ı a odpojov´an´ı z´atˇeˇze v z´avislosti na hladinˇe pohonn´ ych hmot. Cel´a technologie je ˇr´ızena pomoc´ı dvou PLC automat˚ u WAGO. Prvn´ı 1
Automatic transfer switch systems and controllers, Patent ID: US6876103, Issue Date: April 05, 2005, v´ıce na http://www.patents.com/Automatic-transfer-switch-systems-controllers/US6876103/en-US/
1
obsluhuje rozvadˇeˇce ATS a druh´ y ˇreˇs´ı syst´em pˇrip´ın´an´ı a odp´ın´an´ı z´atˇeˇze v z´avislosti na mnoˇzstv´ı paliva v n´adrˇzi. Z´aroveˇ n pˇri prvn´ım pˇripnut´ı na motorgener´ator po v´ ypadku ’ zajiˇst uje postupn´e pˇripnut´ı cel´e z´ateˇze, aby nedoch´azelo k odbˇerov´ ym ˇspiˇck´am. Technologie je monitorov´ana pomoc´ı panelov´eho PC vestaven´eho do dveˇr´ı rozvadˇeˇce ATS. S obˇema PLC je komunikace zajiˇstˇena pomoc´ı ethernetu s uˇzit´ım deterministick´eho pr˚ umyslov´eho protokolu MODBUS TCP/IP. ˇ Casov´ e odezvy v ˇr´adu mikrosekund jsou potˇrebn´e v aplikac´ıch pro ˇr´ızen´ı r˚ uzn´ ych zaˇr´ızen´ı a nejl´epe jsou dosaˇziteln´e zaˇr´ızen´ımi se zabudovan´ ym speci´aln´ım softwarem. Pouˇz´ıvat pro takovou aplikaci standardn´ı protokol Ethernet nen´ı vhodn´e. Nutnost´ı je urˇcit´a modifikace pro zvl´adnut´ı ˇr´ızen´ı v re´aln´em ˇcase. Proto byl upraven standard MODBUS i pro rozhran´ı ethernet a oznaˇcuje se jako MODBUS TCP/IP. Pro sbˇer informac´ı o cel´em syst´emu a jejich archivaci na jednom m´ıstˇe je vyuˇzit protokol SNMP. Pˇri definovan´ ych zmˇen´ach na zaˇr´ızen´ı, v rozvadˇeˇci (napˇr. pˇrepnut´ı stykaˇce) je odesl´an SNMP Trap na definovanou adresu. Zde je zpracov´an pomoc´ı filtru v programu SNMPc a uloˇzena pˇr´ısluˇsn´a informace. V sestaven´e vizualizaci je tak´e moˇzn´e se pod´ıvat, jak´e zaˇr´ızen´ı odeslalo zpr´avu a zpr´avu si pˇreˇc´ıst, pˇr´ıpadnˇe reagovat. Popsan´ ym zp˚ usoben je ˇreˇseno informov´an´ı o stavech technologie, tedy bin´arn´ı informace (zapnuto/vypnuto). SNMP Trap zpr´avy maj´ı v´ yhodu, ˇze je pˇr´ısluˇsn´e zaˇr´ızen´ı odes´ıl´a asynchronnˇe, vˇzdy, kdyˇz dojde k urˇcit´e ud´alosti. Z´aroveˇ n SNMP protokol umoˇzn ˇuje pouˇzit´ı MIB datab´aze. Takto jsou pˇren´aˇseny informace o analogov´ ych hodnot´ach, jako jsou napˇr. proudy a napˇet´ı v prim´arn´ı s´ıti, kdy naposledy byl nastartov´an agreg´at apod. Na tyto informace je nutn´e se pˇr´ısluˇsn´eho zaˇr´ızen´ı zeptat pomoc´ı standardn´ıch pˇr´ıkaz˚ u, kter´e jsou rozebr´any v n´asleduj´ıc´ıh kapitol´ach.
2
1.1 1.1.1
Z´ aloˇ zn´ı zdroje el. energie a jejich funkce Motorgener´ ator a jeho funkce
Motorgener´ator se spalovac´ım motorem je soustroj´ı sloˇzen´e ze spalovac´ıho motoru a gener´atoru na spoleˇcn´e hˇr´ıdeli. Zaˇr´ızen´ı slouˇz´ı k v´ yrobˇe elektrick´e energie. Spalovac´ı motor m˚ uˇze b´ yt benz´ınov´ y nebo naftov´ y. Gener´ator m˚ uˇze b´ yt bud’ dynamo, nebo altern´ator. Zaˇr´ızen´ı se pouˇz´ıv´a jako zdroj elektrick´e energie v m´ıstech, kde nen´ı k dispozici rozvodn´a s´ıt’, jako ˇspiˇckov´ y zdroj, nebo jako z´aloˇzn´ı zdroj pro zajiˇstˇen´ı nepˇretrˇzit´e dod´avky elektrick´e energie pro zpravidla dlouhodobˇejˇs´ı dod´avky energie (hodiny aˇz dny). M˚ uˇze b´ yt konstruov´an jako stacion´arn´ı, nebo jako mobiln´ı. Oznaˇcuje se t´eˇz jako agreg´at (obecnˇejˇs´ı pojem), pˇr´ıpadnˇe dle typu spalovac´ıho motoru (nafta, benzin, zemn´ı plyn, popˇr. bioplyn) jako naftov´ y (ˇcastˇeji diesel), nebo jako benz´ınov´ y agreg´at. Rozsah vyuˇzit´ı motorgener´ator˚ u je velice ˇsirok´ y, napˇr. jde o oblasti, kde v´ ypadek energie m˚ uˇze m´ıt v´ yznamnˇe negativn´ı dopad s moˇznost´ı ohroˇzen´ı zdrav´ı ˇci ˇzivota (zdravotnick´a zaˇr´ızen´ı, ozbrojen´e sloˇzky, leteck´a doprava, poˇz´arn´ı ventilace, glob´aln´ı z´achrann´ y syst´em pˇri ˇziveln´ ych pohrom´ach). V tˇechto oblastech je ˇcasto vyuˇzit´ı motorgener´atoru urˇceno normativnˇe. Lze pˇredpokl´adat dlouhodobˇejˇs´ı v´ ypadky energie, napˇr. v energeticky nadmˇernˇe zat´ıˇzen´ ych provozech s moˇznost´ı negativn´ıho dopadu v´ ypadku energie na materi´aln´ı hodnoty a to jak v´ yrobn´ıho zaˇr´ızen´ı, tak zpracov´avan´e produkce pˇri pˇreruˇsen´ı ˇcinnosti (v´ yrobn´ı ˇci obchodn´ı). V´ ypadek m˚ uˇze m´ıt nepˇr´ızniv´ y vliv na dobr´e obchodn´ı jm´eno pˇri poskytov´an´ı sluˇzeb z´akazn´ıkovi (obchodn´ı domy, banky, . . .). Pokryt´ı odbˇerov´ ych ˇspiˇcek je dalˇs´ı oblast´ı pouˇzit´ı motorgener´ator˚ u, protoˇze pˇri pravideln´em pˇrekraˇcov´an´ı limitu energetick´eho odbˇeru (ˇctvrhodinov´e maximum urˇcen´e smlouvou s rozvodn´ ymi z´avody) vznikaj´ı vysok´e finanˇcn´ı n´aklady - pen´ale. Motorgener´ator je zapojen tak, aby tento u ´sek n´arazov´e potˇreby e-nergie sv´ ym provozem pˇreklenul. Motorgener´ator m˚ uˇze b´ yt vybaven extern´ı n´adrˇz´ı s automatick´ ym pˇreˇcerp´av´an´ım paliva, ˇc´ımˇz se prodluˇzuje doba chodu zaˇr´ızen´ı.
1.1.1.1
Princip ˇ cinnosti
Spalovac´ı motor vytvoˇr´ı toˇciv´ y moment. Ten je pˇren´aˇsen rotaˇcn´ı spojkou na altern´ator. Cel´e soustroj´ı motorgener´atoru pˇrev´ad´ı kinetickou energii na energii elektrickou. Bud´ıc´ım vinut´ım proch´az´ı stejnosmˇern´ y proud pˇriv´adˇen´ y pˇres sbˇerac´ı krouˇzky, vznik´a toˇciv´e magnetick´e pole, kter´e ve statorov´em vinut´ı indukuje tˇr´ıf´azov´e stˇr´ıdav´e napˇet´ı s kmitoˇctem u ´mˇern´ ym ot´aˇck´am hˇr´ıdele a poˇctu p´ol˚ u.
3
Obr´azek 1.1: Konstrukce synchronn´ıho stroje
Konstrukce dle obr. 1.1 obsahuje n´asleduj´ıc´ı ˇc´asti: stator (1), rotor (2), magnetick´ y obvod statoru (3), statorov´e vinut´ı (4), rotorov´e vinut´ı (5), p´oly (6), sbˇerac´ı krouˇzky (7), hˇr´ıdel (8). Ve statoru altern´atoru, kter´ y se podob´a dut´emu v´alci, je magnetick´ y obvod sloˇzen´ y z plech˚ u. Plechy se izoluj´ı lakem nebo zvl´aˇstn´ım druhem pap´ıru. Jsou v nich vytvoˇreny chladic´ı kan´aly, kudy vzduch nebo jin´ y plyn odv´ad´ı z magnetick´eho obvodu teplo. Na vnitˇrn´ım obvodu plech˚ u jsou dr´aˇzky s mˇedˇen´ ymi vodiˇci, kter´e vytv´aˇrej´ı trojf´azov´e vinut´ı. Zaˇc´atky vinut´ı jsou pˇripojeny na svorky altern´atoru, odkud se stˇr´ıdav´ y elektrick´ y proud odeb´ır´a a vede se do rozvodny a d´ale ke spotˇrebitel˚ um. Konce vinut´ı jsou spojeny do uzlu. Jednotliv´e vodiˇce jsou izolov´any.
Obr´azek 1.2: Princip synchronn´ıho stroje
Pro dvojp´olov´ y altern´ator plat´ı: ω · T = 2π kde T =
60 n
→
f1 =
n 60
⇒
ω=
2π · n , 60
(1.1)
. Ot´aˇcky rotoru synchronn´ıho stroje jsou oznaˇcov´any jako n. 4
Pro obecn´ y p-p´olov´ y altern´ator plat´ı: f1 = p ·
n , 60
(1.2)
kde f1 je frekvence indukovan´eho napˇet´ı do statoru (kotvy2 ). Pˇripoj´ı-li se ke svork´am vinut´ı statoru (kotvy) trojf´azov´a z´atˇeˇz (z´atˇeˇz altern´atoru), vinut´ım statoru bude proch´azet stˇr´ıdav´ y elektrick´ y proud, jehoˇz smˇer je d´an Lenzov´ ym z´akonem. T´ım, ˇze vinut´ım statoru proch´az´ı stˇr´ıdav´ y trojf´azov´ y proud, vznik´a podobnˇe jako u asynchronn´ıho stroje toˇciv´e magnetick´e pole s ot´aˇckami ns1 , kter´e m´a stejnou rychlost ot´aˇcen´ı jako rotor a jeho magnetick´e pole. Skluz stroje je tedy nulov´ y a stroj se naz´ yv´a synchronn´ı. Plat´ı ns1 = n,
s = 0,
f1 = p ·
ns1 60
(1.3)
Synchronn´ı altern´ator m´a na statoru trojf´azov´e vinut´ı a na rotoru tzv. budic´ı vinut´ı. Jestliˇze pohon ot´aˇc´ı rotorem a v jeho budic´ım vinut´ı proch´az´ı stejnosmˇern´ y proud, vznik´a toˇciv´e magnetick´e pole, kter´e v trojf´azov´em vinut´ı statoru vyvol´a (indukuje) trojf´azov´e stˇr´ıdav´e napˇet´ı. Druh´e toˇciv´e magnetick´e pole vyvol´a stˇr´ıdav´ y proud, kter´ y zaˇcne proch´azet trojf´azov´ ym vinut´ım statoru pˇri pˇripojen´ı altern´atoru ke spotˇrebiˇci. Stroj se naz´ yv´a synchronn´ı, protoˇze se obˇe toˇciv´a magnetick´a pole ot´aˇcej´ı se stejn´ ymi ot´aˇckami. Altern´atory se podle zaˇr´ızen´ı, kter´e je poh´an´ı, dˇel´ı na turboaltern´atory, altern´atory poh´anˇen´e spalovac´ımi motoryhydro a altern´atory, kter´e jsou pomalobˇeˇzn´e s velk´ ym pr˚ umˇerem a malou d´elkou rotoru. Rotor pracuje vˇetˇsinou i jako setrvaˇcn´ık, aby vyrovn´aval nerovnomˇernosti zp˚ usoben´e chodem p´ıstov´ ych motor˚ u.
1.1.1.2
Proveden´ı a regulace
Motorgener´atory lze rozdˇelit z pohledu d´ılensk´eho proveden´ı na: • compact - proveden´ı nekryt´e, neodhluˇcnˇen´e • silent - proveden´ı s kapot´aˇz´ı, odhluˇcnˇen´e • super silent - proveden´ı s kapot´aˇz´ı, speci´alnˇe odhluˇcnˇen´e • proveden´ı v kontejneru - kryt´e proveden´ı, urˇcen´e pro venkovn´ı um´ıstˇen´ı • mobiln´ı, stacion´arn´ı
2
kotva - m´ısto, kde se indukuje napˇet´ı
5
Obr´azek 1.3: Uk´azka motorgener´ator˚ u
Silov´e v´ ystupn´ı obvody ve spojen´ı s ˇr´ıdic´ı automatikou zajiˇst’uj´ı pˇredevˇs´ım automatick´e pˇrep´ın´an´ı mezi s´ıt´ı dodavatele elektrick´e energie a motorgener´atorem a tak´e elektrick´e a mechanick´e blokov´an´ı za u ´ˇcelem ochrany s´ıtˇe dodavatele proti dod´avce elektrick´e energie pˇri ˇcinnosti motorgener´atoru. N´avrat k nap´ajen´ı z´atˇeˇze z rozvodn´e s´ıtˇe po obnovˇe dod´avky napˇet´ı lze prov´est tˇremi z´akladn´ımi zp˚ usoby: 1. bez zpˇetn´e synchronizace 2. se zpˇetnou synchronizac´ı 3. s postupn´ ym pˇred´av´an´ım z´atˇeˇze
1.1.1.3
N´ avrat k s´ıti
Pˇri n´avratu s´ıtˇe motorgener´ator bez zpˇ etn´ e synchronizace urˇcitou dobu d´ale nap´aj´ı z´atˇeˇz a sleduje kvalitu s´ıtˇe. Pokud jsou po definovanou dobu parametry s´ıtˇe v definovan´ ych toleranc´ıch, ˇr´ıdic´ı automatika odpoj´ı stykaˇc nap´ajen´ı z´atˇeˇze z motorgener´atoru a s definovan´ ym zpoˇzdˇen´ım pˇripoj´ı z´atˇeˇz na nap´ajec´ı s´ıt’. Z´atˇeˇz je v tomto typu ˇr´ızen´ı motorgener´atoru bˇehem v´ yˇse uveden´eho definovan´eho zpoˇzdˇen´ı bez nap´ajen´ı. Pˇri tomto typu pˇrep´ın´an´ı nen´ı provedena synchronizace chodu motorgener´atoru se s´ıt´ı. Pˇri n´avratu s´ıtˇe motorgener´ator se zpˇ etnou synchronizac´ı urˇcitou dobu d´ale nap´aj´ı z´atˇeˇz a sleduje kvalitu s´ıtˇe. Pokud jsou po definovanou dobu parametry s´ıtˇe v definovan´ ych toleranc´ıch, ˇr´ıdic´ı jednotka provede synchronizaci motorgener´atoru se s´ıt´ı a pˇripoj´ı s´ıt’ na z´atˇeˇz. Po definovan´em ˇcase (cca 0,5 s - nastaviteln´e) ˇr´ıdic´ı automatika odpoj´ı motorgener´ator od z´atˇeˇze. Po v´ yˇse uveden´ y ˇcas je motorgener´ator pˇripojen paralelnˇe k s´ıti. Pˇri n´avratu s´ıtˇe je tedy z´atˇeˇz nap´ajena bez pˇreruˇsen´ı. Pˇri n´avratu s´ıtˇe motorgener´ator s postupn´ ym pˇ red´ av´ an´ım z´ atˇ eˇ ze urˇcitou dobu d´ale nap´aj´ı z´atˇeˇz a sleduje kvalitu s´ıtˇe. Pokud jsou po urˇcenou dobu parametry s´ıtˇe v definovan´ ych toleranc´ıch, ˇr´ıdic´ı jednotka provede synchronizaci motorgener´atoru se s´ıt´ı, ’ pˇripoj´ı s´ıt na z´atˇeˇz a postupnˇe pˇred´a nap´ajen´ı z´atˇeˇze na rozvodnou s´ıt’. Tento proces trv´a cca 10 s a je pˇri nˇem zajiˇstˇeno, ˇze nedojde ke zpˇetn´emu toku proudu do s´ıtˇe (zpˇetn´emu 6
nap´ajen´ı). Pˇrej´ım´an´ı z´atˇeˇze prob´ıh´a bez proudov´ ych r´az˚ u. Parametry pˇrej´ım´an´ı z´atˇeˇze jsou voliteln´e. Pokud v dobˇe pˇred´av´an´ı z´atˇeˇze dojde k v´ ypadku s´ıtˇe, motorgener´ator pˇrevezme nap´ajen´ı z´atˇeˇze bez zpoˇzdˇen´ı. Pˇri n´avratu s´ıtˇe je tedy z´atˇeˇz rovnˇeˇz nap´ajena bez pˇreruˇsen´ı. Ve vˇsech pˇr´ıpadech motorgener´ator po definovanou dobu (cca 5 min) d´ale bˇeˇz´ı v tzv. dochlazovac´ım reˇzimu a n´aslednˇe je vypnut a je znovu pˇripraven k provozu. Pokud v dobˇe bˇehu motoru v dochlazovac´ım reˇzimu (po odpojen´ı stykaˇce motorgener´atoru) dojde k v´ ypadku s´ıtˇe, motor s mal´ ym zpoˇzdˇen´ım pˇreb´ır´a nap´ajen´ı z´atˇeˇze. Cel´ y tento proces prob´ıh´a automaticky a nevyˇzaduje ˇz´adn´ y z´asah obsluhy. Testov´an´ı soustroj´ı je vˇzdy prov´adˇeno bezv´ ypadkov´ ym zp˚ usobem. Motorgener´atory jsou vˇetˇsinou vybaveny elektrick´ ym pˇredehˇrevem chladic´ı kapaliny dieselmotoru. To umoˇzn ˇuje dos´ahnout 100% v´ ykonu stroje do 10 s. Chladiˇc uzavˇren´eho chladic´ıho syst´emu je um´ıstˇen na stroji, ale lze ho um´ıstit i mimo. U chladiˇce um´ıstˇen´eho na stroji je potˇreba vyˇreˇsit vhodn´ ym zp˚ usobem pˇr´ıvod a odvod vzduchu.
1.1.1.4
Vybaven´ı a technologie
Motorgener´atory lze obecnˇe rozdˇelit do skupin dle dod´avan´ ych v´ ykon˚ u, m´ısta pouˇzit´ı, ovl´ad´an´ı apod. Pˇr´ıkladem m˚ uˇze b´ yt n´asleduj´ıc´ı dˇelen´ı. Do prvn´ı skupiny mohou patˇrit pˇrenosn´a soustroj´ı ve v´ ykonech do cca 20 kVA, existuj´ı varianty s ruˇcn´ım startem, elektrick´ ym start´erem. S kapot´aˇz´ı i bez n´ı. Vyznaˇcuj´ı se nen´aroˇcn´ ym provozem a tich´ ym chodem. Druh´a skupina zahrnuje motorgener´atory s v´ ykony do cca 2000 kVA. Tˇret´ı skupina je specifick´a, zahrnuje motorgener´atory se stˇredn´ımi v´ ykony (cca do 200 kVA). V´ yhodou je robustn´ı konstrukce, m´ısta urˇcen´ı jsou pˇredevˇs´ım pr´ace v n´aroˇcn´em a pracn´em prostˇred´ı. Vznˇetov´e motory soustroj´ı b´ yvaj´ı dnes vybaveny modern´ımi prostˇredky pro dosaˇzen´ı vysok´ ych v´ ykon˚ u. Tˇemi jsou napˇr. syst´em Common-rail pˇr´ım´eho vysokotlak´eho vstˇriku nafty. Palivo vstˇrikovan´e do v´alc˚ u pod vysok´ ym tlakem tvoˇr´ı l´epe hoˇrlavou smˇes, ˇc´ımˇz se dosahuje vyˇsˇs´ı u ´ˇcinnosti motoru, vyˇsˇs´ıho v´ ykonu a toˇciv´eho momentu. D˚ uleˇzit´ ym faktorem je niˇzˇs´ı spotˇreba, hluˇcnost apod. Oproti jin´ ym syst´em˚ um je tlak paliva vytv´aˇren nez´avisle na ot´aˇck´ach motoru a vstˇrikovan´em mnoˇzstv´ı paliva - d´ıky z´asobn´ıku tlaku. Jako altern´atory se dnes pouˇz´ıvaj´ı ˇctyˇrp´olov´e bezkart´aˇcov´e jednoloˇziskov´e samobudic´ı a samoregulaˇcn´ı stroje vybaven´e elektronickou regulac´ı. Alternativn´ı maj´ı vlastn´ı chladic´ı syst´em, bez´ udrˇzbov´a loˇziska a jsou vybaveny automatick´ ym elektronick´ ym napˇet’ov´ ym regul´atorem pro zvl´adnut´ı skokov´e z´atˇeˇze. Obecnˇe lze ˇr´ıci, ˇze motorgener´ator v proveden´ı Silent oproti proveden´ı bez kapot´aˇze dosahuje sn´ıˇzen´ı u ´rovnˇe hluku minim´alnˇe o 20 dB ve vzd´alenosti jeden metr od stroje v kaˇzd´em smˇeru. Ve standardn´ım vybaven´ı je chladiˇc s ventil´atorem poh´anˇen´ ym od motoru, vzduchov´ y filtr, plnopr˚ utokov´ y olejov´ y a palivov´ y filtr, uzavˇren´ y chladic´ı okruh, elektrick´ y pˇredehˇrev chladic´ıho okruhu pro hladk´ y start, elektrick´ y start´er, mechanick´ y nebo elektronick´ y regul´ator ot´aˇcek motoru, spoleˇcn´ y ocelov´ y r´am pro motor i gener´ator s antivibraˇcn´ımi elementy a zvedac´ı oka pro transport. Standardem je t´eˇz vybaven´ı kompletn´ım ˇr´ıdic´ım syst´emem. Ten obsahuje voltmetr, amp´ermetr, mˇeˇriˇc frekvence, poˇcitadlo motohodin, automatiku kontroly motoru, z´asuvky a svorkovnice. 7
Spr´avn´ y v´ ykon soustroj´ı je urˇcov´an v´ıce faktory. Nejd˚ uleˇzitˇejˇs´ı informac´ı je velikost, charakter a chov´an´ı nap´ajen´e z´atˇeˇze. Sm´ıˇsen´a z´atˇeˇz se obvykle sest´av´a ze spotˇreby pˇrev´aˇznˇe ˇcinn´eho charakteru (ˇz´arovkov´e osvˇetlen´ı), induktivn´ıch spotˇrebiˇc˚ u (motory v´ ytah˚ u, ˇcerpadel, ventil´ator˚ u) a v neposledn´ı ˇradˇe b´ yvaj´ı na stranˇe MTG z´atˇeˇz´ı i UPS. Pro stanoven´ı jmeno-vit´eho v´ ykonu je nutn´e zn´at i rozbˇehov´e proudy a u ´ˇcin´ıky alespoˇ n nejv´ yznamnˇejˇs´ıch spotˇrebiˇc˚ u. Podstatn´ y je i ˇcinitel harmonick´eho zkreslen´ı vstupn´ıho proudu THDI a vlastnost soustroj´ı, kter´a urˇcuje toleranci n´ahradn´ıho zdroje v˚ uˇci skokovˇe pˇripojen´e z´atˇeˇzi. Pamatovat je nutn´e tak´e na symetrii zat´ıˇzen´ı. Dalˇs´ım parametrem ovlivˇ nuj´ıc´ım volbu syst´emu energocentra je vstupn´ı Power Factor. Obvykl´a hodnota pro velk´e syst´emy je cca 0,8 a lze dos´ahnout aˇz hodnotu 1. Pro niˇzˇs´ı hodnoty Power Factoru je nezbytn´ y zv´ yˇsen´ y v´ ykon gener´atoru.
Obr´azek 1.4: pˇr´ıklad motorgener´atorov´eho zdroje 2000 kVA
1.1.1.5
Provozn´ı m´ ody z´ aloˇ zn´ıch motorgener´ atorov´ ych zdroj˚ u
Ostrovn´ı provoz je provozem jednoho zdroje v m´ıstech mimo dosah veˇrejn´e distribuˇcn´ı ˇ ıdic´ı syst´em zajiˇst’uje s´ıtˇe. Motorgener´ator slouˇz´ı jako jedin´ y zdroj elektrick´e energie. R´ pˇredevˇs´ım dohled nad vˇsemi technologick´ ymi parametry soustroj´ı. N´ahradn´ı zdroj obvykle pracuje v manu´aln´ım provozu. Z´ askok s dvoj´ım pˇ reruˇ sen´ım se pouˇz´ıv´a vˇsude, kde technologick´a potˇreba vyˇzaduje n´ahradu elektrick´e energie z veˇrejn´e s´ıtˇe z´askokov´ ym zdrojem pˇri jej´ım selh´an´ı. Vedle technologick´ ych parametr˚ u vlastn´ıho motorgener´atoru monitoruje ˇr´ıdic´ı syst´em i parametry distribuˇcn´ı s´ıtˇe. N´ahradn´ı zdroj obvykle pracuje v automatick´em reˇzimu. Po v´ ypadku standardn´ıho zdroje, na z´akladˇe nastaven´ ych parametr˚ u automatika rozhodne o chov´an´ı a startu soustroj´ı. Po nastartov´an´ı pˇreb´ır´a motorgener´ator spotˇrebu chr´anˇen´e technologie. Toto ˇreˇsen´ı je charakteristick´e dvˇema pˇreruˇsen´ımi v dod´avce elektrick´e energie. Poprv´e v okamˇziku kdy dojde k selh´an´ı hlavn´ıho zdroje a podruh´e pˇri n´avratu s´ıtˇe. Prvn´ı v´ ypadek je zp˚ usoben nenad´alou poruchou a lze jej oˇcek´avat kdykoli. Doba pˇreruˇsen´ı je d´ana nas8
tavitelnou dobou rozhodov´an´ı o startu soustroj´ı, startem a pˇr´ıpravou na pˇrevzet´ı z´atˇeˇze. Druh´ y v´ ypadek nast´av´a po n´avratu s´ıtˇe. Doba pˇreruˇsen´ı je pak d´ana nastavitelnou dobou rozhodov´an´ı o odstaven´ı soustroj´ı a ˇcasem nutn´ ym pro pˇred´an´ı z´atˇeˇze zpˇet s´ıti. Pˇrepnut´ı z motorgener´atoru na s´ıt’ nelze prov´est bez jist´e prodlevy, pˇri n´ıˇz jsou souˇcasnˇe odpojeny stykaˇc s´ıtˇe i stykaˇc motorgener´atoru. Toto ˇreˇsen´ı nepoˇc´ıt´a se zpˇetnou synchronizac´ı n´ahradn´ıho zdroje. Kr´ atkodob´ y chod se s´ıt´ı odpov´ıd´a situaci v´ yˇse popsan´emu stavu s t´ım rozd´ılem, ˇze po n´avratu veˇrejn´e s´ıtˇe doch´az´ı k synchronizaci gener´atoru. Oba zdroje jsou tak ve f´azi a pˇri zajiˇstˇen´ı limitace zpˇetn´e dod´avky do veˇrejn´eho zdroje jsou obˇe s´ıtˇe kr´atkodobˇe ˇ ıdic´ı propojeny. V´ ypadek tak nast´av´a pouze v okamˇziku n´ahl´eho s´ıt’ov´eho v´ ypadku. R´ elektronika zajiˇst’uje tak´e synchronizaci se s´ıt´ı a regulaci v´ ykonu gener´atoru tak, aby byla zpˇetn´a dod´avka limitov´ana a pˇrevzet´ı z´atˇeˇze z MTG na s´ıt’ bylo mˇekk´e. V pˇr´ıpadˇe testovac´ıho provozu za pˇr´ıtomnosti s´ıtˇe gener´ator z´atˇeˇz pˇrevezme a s´ıti opˇet pˇred´a bez poruch nebo pˇreruˇsen´ı. Paraleln´ı chod se s´ıt´ı je umoˇznˇen v´ yˇse popsan´ ym zp˚ usobem, ˇr´ıdic´ı syst´em pak zajiˇst’uje ˇr´ızen´ y export/import energie do soustavy chr´anˇen´e n´ahradn´ım zdrojem. V´ yhoda tohoto ˇreˇsen´ı spoˇc´ıv´a v moˇznosti pˇripojit motorgener´ator paralelnˇe k s´ıti pˇred oˇcek´avan´ ym (pl´anovan´ ym) v´ ypadkem s´ıtˇe a dos´ahnout tak zcela neruˇsen´eho technologick´eho procesu. Ekonomicky zvl´aˇstˇe v´ yhodnou vlastnost´ı tohoto ˇreˇsen´ı je vyuˇzit´ı soustroj´ı pro pˇreklenov´an´ı energetick´ ych ˇspiˇcek nad sjednan´ y energetick´ y diagram. Multi mode - provoz dvou a v´ıce paraleln´ıch zdroj˚ u. Paraleln´ı chod zdroj˚ u je vhodn´ y pro pˇr´ıpady, kdy je vyˇzadov´ana vˇetˇs´ı spolehlivost (redundance zdroj˚ u), celkovˇe vˇetˇs´ı pohotovostn´ı v´ ykon n´ahradn´ıho zdroje nebo promˇenliv´a, technologicky podm´ınˇen´a v´ ykonov´a potˇreba (nen´ı nutno vˇzdy provozovat jeden velmi v´ ykonn´ y ale nezat´ıˇzen´ y zdroj). Paraleln´ı syst´emy lze provozovat prakticky ve stejn´ ych funkˇcn´ıch modech jako samoˇ ıdic´ı statn´e motorgener´atory, od ostrovn´ıho provozu po paraleln´ı chod soustavy se s´ıt´ı. R´ syst´em pln´ı jeˇstˇe funkci v´ ykonov´eho managementu a sleduje stejnomˇern´ y probˇeh jednotliv´ ych stroj˚ u. V´ ykonov´ y management zajist´ı, aby bylo vˇzdy v chodu jen nezbytn´e mnoˇzstv´ı soustroj´ı nutn´ ych pro bezprobl´emov´ y chod tohoto energocentra. Soustroj´ı jsou tak pˇripojov´ana, nebo odpojov´ana dle okamˇzit´ ych a pˇredpo-kl´adan´ ych potˇreb kritick´e z´atˇeˇze, coˇz pˇrisp´ıv´a ke stabilitˇe cel´eho nap´ajec´ıho syt´emu a z´aroveˇ n dok´aˇze drˇzet provozn´ı n´aklady v pˇredpokl´adan´ ych ekonomick´ ych mez´ıch. Paraleln´ı ˇrazen´ı zdroj˚ u lze prov´adˇet i dodateˇcnˇe.
1.1.2
Zdroje UPS - Uninterruptible Power Supply
UPS jsou zaˇr´ızen´ı jejichˇz funkc´ı je zpravidla kr´atkodob´a (minuty aˇz hodiny) dod´avka energie v pˇr´ıpadˇe nestability vstupn´ıho napˇet´ı ˇci pˇri u ´pln´em v´ ypadku s´ıtˇe. Jejich u ´lohou je chr´anit data a citliv´a zaˇr´ızen´ı pˇred poˇskozen´ım vlivem nepˇredv´ıdan´ ych ud´alost´ı na s´ıti jako jsou ˇsumy, r´azy, napˇet’ov´e ˇspiˇcky, poklesy napˇet´ı nebo u ´pln´e v´ ypadky. Dojde-li k v´ ypadku elektrick´e energie, z´aloˇzn´ı zdroj dod´av´a spotˇrebiˇci energii ze sv´ ych akumul´ator˚ u. Vzhledem k cenˇe elektronick´ ych zaˇr´ızen´ı a pˇren´aˇsen´ ych dat jsou UPS nezbytn´ ym vybaven´ım vˇsech informaˇcn´ıch syst´em˚ u. 9
Obr´azek 1.5: pˇr´ıklady UPS zdroj˚ u
1.1.2.1
Princip ˇ cinnosti
Existuj´ı tˇri z´akladn´ı skupiny UPS zdroj˚ u liˇs´ıc´ıch se dle metody pˇrepnut´ı mezi s´ıt´ı a bateriemi. Voltage Dependent - napˇet’ovˇe z´avisl´ y, t´eˇz oznaˇcovan´ y jako off-line. Pˇrep´ın´a chr´anˇenou technologii pomoc´ı rel´e na z´aloˇzn´ı mˇeniˇc nap´ajen´ y z akumul´ator˚ u. Doch´az´ı zde ke kr´atkodob´emu (zhruba 5 ms) v´ ypadku. UPS v norm´aln´ım (s´ıt’ov´em) reˇzimu nap´aj´ı z´atˇeˇz pˇr´ımo ze s´ıtˇe, kdy parametry s´ıtˇe mohou b´ yt upravov´any pasivn´ımi filtry. Stˇr´ıdaˇc nepracuje. Pˇri v´ ypadku vstupn´ıho s´ıt’ov´eho napˇet´ı se aktivuje stˇr´ıdaˇc bˇehem nˇekolika ms (cca 5 ms) a z´atˇeˇz je nap´ajena z bateri´ı. Modifikac´ı je Voltage & Frequency Dependent. Tyto typy odstraˇ nuj´ı probl´emy s v´ ypadkem proudu a ˇc´asteˇcn´e ruˇsen´ı s´ıtˇe.
Obr´azek 1.6: UPS - Voltage Dependent
Voltage Independent - napˇet’ovˇe nez´avisl´ y, t´eˇz line-interactive. Principem je pˇres regulaˇcn´ı transform´ator vyrovn´avat mimoˇr´adn´e anom´alie elektrick´e s´ıtˇe. Z´akladn´ım rysem tˇechto UPS je napˇet’ov´a a frekvenˇcn´ı nez´avislost pouze v bateriov´em reˇzimu. UPS v norm´aln´ım (s´ıt’ov´em) reˇzimu nap´aj´ı z´atˇeˇz pˇres filtry pˇr´ımo ze s´ıtˇe. Parametry s´ıtˇe jsou upravov´any s´ıt’ov´ ym pˇrizp˚ usobovac´ım ˇclenem tak, aby vstupn´ı napˇet´ı bylo korigov´ano v z´avislosti na jeho hodnotˇe. Tato korekce m˚ uˇze b´ yt realizov´ana skokovˇe (pˇrep´ın´an´ı odboˇcek na autotransform´atoru) nebo line´arnˇe (Delta konverze). Stˇr´ıdaˇc je synchronizov´an se s´ıt´ı (line interactive), je vˇsak vˇetˇsinou ve stavu napr´azdno. V reˇzimu bez pˇr´ıtomnosti s´ıtˇe je bˇehem nˇekolika ms energie dod´av´ana stˇr´ıdaˇcem z bateri´ı. Nejdokonalejˇs´ı UPS tohoto typu maj´ı plynul´e ˇr´ızen´ı v´ ystupn´ıho napˇet´ı a bezsp´ınaˇcov´ y 10
pˇrechod mezi s´ıt’ov´ ym a bateriov´ ym reˇzimem (Delta konverze). Tento typ odstraˇ nuje nedostatky jako jsou v´ ypadek proudu, napˇet’ov´e r´azy, pokles napˇet´ı, podpˇet´ı a pˇrepˇet´ı.
Obr´azek 1.7: UPS - Voltage Independent
Voltage Frequency Independent - napˇet’ovˇe a frekvenˇcnˇe nez´avisl´ y, t´eˇz true online double conversion. Principem je nap´ajen´ı spotˇrebiˇce prostˇrednictv´ım mˇeniˇce trvale z akumul´ator˚ u, kter´e jsou souˇcasnˇe dob´ıjeny ze s´ıtˇe. UPS prov´ad´ı stabilizaci a filtraci napˇet´ı. V pˇr´ıpadˇe v´ ypadku ˇci poklesu napˇet´ı dod´avaj´ı akumul´atory energii bez jak´ehokoliv pˇreruˇsen´ı. Zajiˇst’uje napˇet’ovou a frekvenˇcn´ı nez´avislost ve vˇsech reˇzimech. V norm´aln´ım (s´ıt’ov´em) reˇzimu je vstupn´ı napˇet´ı usmˇernˇeno a touto energi´ı se nap´aj´ı stˇr´ıdaˇc. V pˇr´ıpadˇe potˇreby jsou baterie dob´ıjeny. V z´alohovac´ım reˇzimu je nap´ajen stˇr´ıdaˇc z akumul´ator˚ u. Vˇsechny UPS jsou vybaveny automatick´ ym by-passem. Z´akladn´ım znakem tˇechto UPS je trval´a napˇet’ov´a a frekvenˇcn´ı nez´avislost na vstupn´ım napˇet´ı (mimo reˇzim by-pass). Umoˇzn ˇuj´ı mimoˇr´adnˇe pˇresnou stabilizaci v´ ystupn´ıho napˇet´ı a kmitoˇctu. Stˇr´ıdaˇc je trvale v provozu a energie pˇrech´az´ı dvˇema pˇremˇenami AC/DC/AC - coˇz je nˇekdy uv´adˇeno jako dvoj´ı konverze. Tento typ odstraˇ nuje nedostatky typu v´ ypadek proudu, napˇet’ov´e r´azy, pokles napˇet´ı, podpˇet´ı a pˇrepˇet´ı, ruˇsen´ı, transientn´ı a harmonick´e3 zkreslen´ı, frekvenˇcn´ı kol´ıs´an´ı.
Obr´azek 1.8: UPS - Voltage and Frequency Independent
3
zp˚ usobeno nelinearitou - vznikaj´ı vyˇsˇs´ı harmonick´e sloˇzky, lich´e se projevuj´ı jako ruˇsen´ı
11
1.2 1.2.1
Pˇ rep´ınac´ı, monitorovac´ı prvky a jejich funkce Motorov´ y pˇ rep´ınaˇ c SOCOMEC ATyS
Motorov´e pˇrep´ınaˇce ˇrady ATyS jsou 3- nebo 4-p´olov´e pˇrep´ınaˇce d´alkovˇe ovladateln´e pomoc´ı beznapˇet’ov´ ych kontakt˚ u. Jsou kombinac´ı dvou odpojovaˇc˚ u z´atˇeˇze vz´ajemnˇe mechanicky a elektricky blokovan´ ych (mont´aˇz z´ady k sobˇe“). Umoˇzn ˇuj´ı pˇrepojen´ı nap´ajec´ı ” s´ıtˇe a pˇrepnut´ı pod z´atˇeˇz´ı dvou nap´ajec´ıch obvod˚ u pˇri dodrˇzen´ı bezpeˇcn´e izolace. Pˇri pˇrep´ın´an´ı se m˚ uˇze nach´azet ve tˇrech stabiln´ıch poloh´ach oznaˇcovan´ ych I, 0, II.
Obr´azek 1.9: Uk´azka v´ ykonov´eho pˇrep´ınˇce SOCOMEC ATyS
Pˇrep´ınaˇce jsou vybaveny motorov´ ym natahov´an´ım pruˇziny, kter´a pot´e pˇrem´ıst´ı kontakty. Tento zp˚ usob je zvolen s ohledem na co nejvyˇsˇs´ı rychlost pˇrepnut´ı. T´ım se eliminuje vznik oblouku, kter´ y poˇskozuje kontakty opalov´an´ım. Vˇsechny pˇr´ıstroje maj´ı rovnˇeˇz moˇznost ruˇcn´ıho ovl´ad´an´ı pomoc´ı dod´avan´e p´aky. Bezobsluˇzn´ y provoz zajiˇst’uje elektronicky ˇr´ızen´ y modul motorizovan´eho ovl´ad´an´ı:
• d´alkovˇe ˇr´ızen´ y . . . ATyS 3 je ˇr´ızen beznapˇet’ov´ ymi kontakty, umoˇzn ˇuj´ıc´ımi operaci pˇrepnut´ı mezi polohou I, 0 nebo II, z extern´ı ˇr´ıdic´ı logiky, • automaticky ˇr´ızen´ y . . . ATyS 6 zahrnuje kontroln´ı rel´e, ˇcasovaˇce a testovac´ı funkce k zajiˇstˇen´ı pˇrep´ın´an´ı Norm´aln´ı / Z´aloˇzn´ı s´ıt’.
Informace o poloh´ach, pˇr´ıtomnosti zdroje, napˇet´ı a kmitoˇctu jsou zobrazeny pˇr´ımo na pˇr´ıstroji. Jako pˇr´ısluˇsenstv´ı slouˇz´ı tak´e kontroln´ı panel d´alkov´eho ovl´ad´an´ı modul vestaviteln´ y do dveˇr´ı rozvadˇeˇce. K pˇripojen´ı se vyuˇz´ıv´a konektor RJ45. Po jeho pˇripojen´ı se znepˇr´ıstupn´ı funkce ˇceln´ıho panelu na pˇrep´ınaˇci. Jako dalˇs´ı pˇr´ısluˇsenstv´ı je moˇzn´e pouˇz´ıt komunikaˇcn´ı modul rozhran´ı RS-485 s protokolem JBUDS/MODBUS. 12
Obr´azek 1.10: Zjednoduˇsen´e sch´ema pˇripojen´ı
Obr´azek 1.11: Mechanismu pˇrep´ın´an´ı u SOCOMEC ATYSu
13
1.2.2
Automatick´ y pˇ rep´ınaˇ c s´ıt´ı LOVATO ATL
Jedn´a se o ˇr´ıdic´ı jednotku pro ovl´ad´an´ı v´ ykonov´ ych pˇrep´ınaˇc˚ u. Modul je urˇcen pro automatick´e pˇrep´ın´an´ı mezi hlavn´ı s´ıt´ı a z´aloˇzn´ım nap´ajen´ım. Pˇr´ıstroj je v panelov´em proveden´ı v krytu a m´a dva v´ ystupy automatick´e a / nebo manu´aln´ı ovl´ad´an´ı stykaˇc˚ u nebo jistiˇc˚ u s motorov´ ym pohonem. Pro nap´ajen´ı kontroleru je moˇzn´e zvolit variantu na 230 V, nebo 12 /24 V. Pro sledov´an´ı s´ıtˇe jsou k dispozici vstupy pro tˇri f´aze a nulov´ y vodiˇc. Na ˇceln´ım panelu je moˇzn´e sledovat f´azov´e a sdruˇzen´e napˇet´ı a stav stykaˇc˚ u. Modul disponuje ˇctyˇrmi pracovn´ımi reˇzimy (OFF, MANUAL, AUTO, TEST). Konfigurace se prov´ad´ı pomoc´ı dodan´eho softwaru pˇripojen´ım na rozhran´ı RS-232. Varianta ATL-30 disponuje i rozhran´ım RS-485 s protokolem MODBUS.
Obr´azek 1.12: Uk´azka automatick´eho pˇrep´ınaˇce s´ıt´ı ATL
1.2.3
Multifunkˇ cn´ı mˇ eˇ ric´ı pˇ r´ıstroj SOCOMEC DIRIS A4x
Pˇr´ıstroje DIRIS A40 a A414 jsou multifunkˇcn´ı mˇeˇric´ı pˇr´ıstroje urˇcen´e pro mˇeˇren´ı v s´ıt´ıch n´ızk´eho a vysok´eho napˇet´ı. Veˇsker´e parametry lze zobrazit na displeji um´ıstˇen´em na ˇceln´ım panelu, nˇekter´e parametry lze nastavit (napˇr. pˇrevodn´ı pomˇer proudov´eho transform´atoru). Na panelu se zobrazuj´ı rovnˇeˇz mˇeˇren´e hodnoty a ˇcasov´e funkce. Pˇr´ıstroj lze snadno rozˇs´ıˇrit pomoc´ı dodateˇcn´ ych modul˚ u s doplˇ nkov´ ymi funkcemi pro • mˇeˇren´ı spotˇreby • mˇeˇren´ı a zpracov´an´ı informac´ı o harmonick´ ych sloˇzk´ach • signalizaci alarm˚ u • signalizaci alarm˚ u pˇres RS-485 s protokolem JBUS/MODBUS
4
oproti A40 umoˇzn ˇuje mˇeˇrit proud i nulov´ ym vodiˇcem tˇr´ıf´azov´e soustavy v zapojen´ı do hvˇezdy
14
Obr´azek 1.13: Uk´azka multifunkˇcn´ıho mˇeˇric´ıho pˇr´ıstroje DIRIS
Pˇr´ıstroj DIRIS pomoc´ı 6 tlaˇc´ıtek na pˇredn´ım panelu nahrad´ı nˇekolik jednofunkˇcn´ıch analogov´ ych nebo digit´aln´ıch mˇeˇr´ıc´ıch pˇr´ıstroj˚ u jako jsou panelov´e voltmetry, ampermetry nebo mˇeˇridla v´ ykonu. Nav´ıc umoˇzn ˇuje centralizovat tyto parametry na PC nebo PLC pomoc´ı komunikace RS-485 a pouˇzit´ı protokolu JBUS/MODBUS nebo PROFIBUS-DP. Rozmˇery a design pˇr´ıstroj˚ u jsou pˇrizp˚ usobeny pro jejich snadnou mont´aˇz do dveˇr´ı rozvadˇeˇc˚ u. Funkci pˇr´ıstroj˚ u lze snadno rozˇs´ıˇrit pomoc´ı z´asuvn´ ych modul˚ u, tyto moduly lze doplˇ novat postupnˇe, dle potˇreb uˇzivatel˚ u. Mˇeˇren´ı okamˇzit´ ych efektivn´ıch hodnot(TRMS) zahrnuje bˇeˇzn´ y proud f´az´ı, pr˚ umˇern´e a maxim´aln´ı hodnoty ve voliteln´em ˇcasov´em rozmez´ı, f´azov´a a sdruˇzen´a napˇet´ı, kmitoˇcet, ˇcinn´ y f´azov´ y v´ ykon ve 4 kvadrantech, jalov´ y f´azov´ y v´ ykon ve 4 kvadrantech, zd´anliv´ y f´azov´ y v´ ykon, u ´ˇcin´ık (PF) jednotliv´ ych f´az´ı s indikac´ı induktivn´ı nebo kapacitn´ı, m´ıra harmonick´ ych sloˇzek (THD) aˇz do 49. harmonick´e. Mˇeˇren´ı celkov´e spotˇreby, ˇcinn´e spotˇreby ve 4 kvadrantech, jalov´e spotˇreby ve 4 kvadrantech, zd´anliv´e spotˇreby, provozn´ı hodiny s rozliˇsen´ım 1/100 hod. pro mˇeˇren´ı provozn´ı doby.
Obr´azek 1.14: Sch´emata zapojen´ı
15
1.3
Obecn´ e poˇ zadavky na ˇ r´ıdic´ı syst´ em
Cel´a ˇr´ızen´a ˇca´st se skl´ad´a ze dvou z´avisl´ ych celk˚ u, jak ukazuje n´asleduj´ıc´ı obr´azek.
Obr´azek 1.15: Blokov´e sch´ema cel´eho syst´emu
Z´akladn´ım prvkem cel´eho syst´emu z´alohov´an´ı je motorgener´ator MG KOHLER, kter´ y je prim´arn´ım z´aloˇzn´ım zdrojem a jeho v´ ykon m´a pˇri dneˇsn´ı spotˇrebˇe rezervu. Standardn´ı cesta nap´ajen´ı je z prim´arn´ı s´ıtˇe pˇres rozvadˇeˇc ATS 1000 do pole nov´e rozvodny RH 9, odkud je d´ale rozv´adˇeno. Samostatnou vˇetev nap´ajen´ı tvoˇr´ı R-APV. Jedn´a se o nejd˚ uleˇzitˇejˇs´ı ˇc´ast technologie a z´aloha je zde dvojn´asobn´a. Standardnˇe je tato ˇc´ast nap´ajena z prim´arn´ı s´ıtˇe. Pokud s´ıt’ vypadne, bude nap´ajena z MG KOHLER pˇres ATS 1000 a ATS 200. V pˇr´ıpadˇe poruchy budou v ATS 200 a ATS SDMO pˇrepnuty stykaˇce do takov´e polohy, aby nap´ajen´ı R-APV ˇslo z MG SDMO.
1.3.1
ˇ ızen´ı rozvadˇ R´ eˇ c˚ u ATS 1000 a ATS 200
Z´akladn´ım prvkem ˇr´ıdic´ıho algoritmu je tzv. pˇrep´ınac´ı sch´ema. V projektu nen´ı ˇreˇseno pˇrif´azov´an´ı motor˚ u obsaˇzen´ ych v technologii (ˇcerpadla, . . . ). Oproti tomu je pouˇzit jednoduˇsˇs´ı princip, kdy pˇri v´ ypadku nap´ajen´ı je pˇrepnut v´ ykonov´ y pˇrep´ınaˇc SOCOMEC ATYS do tzv. nulov´e polohy (0) a zde setrv´av´a urˇcit´ y ˇcas. V tomto ˇcase by mˇelo doj´ıt k zastaven´ı toˇciv´ ych stroj˚ u a vybit´ı indukˇcnost´ı. Tato doba je z´avisl´a na prvc´ıch pouˇzit´ ych v technologii a je nutn´e ji nastavit individu´alnˇe v kaˇzd´e aplikaci. Aˇz po uplynut´ı t´eto doby je moˇzn´e prov´est druhou f´azi pˇrepnut´ı. Jedn´a se zde o pˇrep´ın´an´ı proud˚ u v ˇr´adu 102 A, proto je samotn´ y pˇrep´ınaˇc vybaven motorick´ ym natahov´an´ım pruˇziny, kter´a pˇresune v co nejkratˇs´ı dobˇe (s potlaˇcn´ım jiskˇren´ı) kontakty do nov´e polohy. Tento pohon je ovl´ad´an logikou. V pˇr´ıpadˇe popisovan´eho ˇreˇsen´ı se jedn´a o pulsn´ı logiku. D´elka, tvar a amplituda pulsu jsou definov´any - pravo´ uhl´ y puls amplitudy do 24V a d´elky minim´alnˇe 1s. Tyto u ´daje bylo nutn´e vz´ıt v u ´vahu pˇri n´avrhu algoritmu. Dalˇs´ım krokem pˇri n´avrhu je prvn´ı spuˇstˇen´ı programu (napˇr. po resetu PLC). Mus´ı b´ yt zajiˇstˇeny n´asleduj´ıc´ı poˇzadavky. Je-li pˇr´ıtomna prim´arn´ı s´ıt’, nastavit v´ ykonov´e pˇrep´ınaˇce SOCOMEC ATYS do polohy I. Pˇri n´abˇehu programu a souˇcasn´em nap´ajen´ı z prim´arn´ı s´ıtˇe nesm´ı doj´ıt k manipulaci s kontakty. Pokud by byl realizov´an algoritmus, kter´ y by zajistil pˇrepnut´ı do nulov´e polohy a opˇetovn´e pˇrepnut´ı na s´ıt’, doˇslo by k v´ ypadku 16
nap´ajen´ı technologie a z´aroveˇ n ke zbyteˇcn´emu pˇrep´ınan´ı mezi kontakty a t´ım i k jejich opotˇrebov´an´ı. Samozˇrejmost´ı je dodrˇzen´ı pˇrep´ınac´ıho sch´ematu. Pokud nebude pˇr´ıtomna prim´arn´ı s´ıt’, bude se ˇcekat nastaven´ y ˇcas (m˚ uˇze b´ yt shodn´ y s ˇcasem T1 ) a pokud v t´eto dobˇe nebude pˇr´ıtomna s´ıt’ provede se cyklus oˇsetˇren´ı v´ ypadku. Pokud prim´arn´ı s´ıt’ na zaˇc´atku bude pˇr´ıtomna, program bude testovat s´ıt’ na v´ ypadek. Je poˇzadov´ana reakce na dva typy v´ ypadk˚ u. Prvn´ım (viz obr. 1.16) je dlouhodob´ y v´ ypadek. Trv´a delˇs´ı ˇcas neˇz je doba T1 . Ve vˇetˇsinˇe pˇr´ıpad˚ u se nastavuje v z´avislosti na pˇripojen´e technologii v rozmez´ı 10 ÷ 30s. Druh´ ym typem v´ ypadku (viz obr. 1.17) je urˇcit´ y poˇcet C1 opakovan´ ych kr´ atkodob´ ych v´ ypadk˚ u za nastavenou dobu T6 . Poˇcet v´ ypadk˚ u i doba T6 se liˇs´ı v z´avislosti na charakteru a kvalitˇe prim´arn´ı s´ıtˇe a pˇripojen´e technologii. Plat´ı ovˇsem, ˇze T6 T1 .
Obr´azek 1.16: Dlouhodob´ y v´ ypadek
Obr´azek 1.17: Kr´atkodob´ y opakovan´ y v´ ypadek
Po zjiˇstˇen´ı v´ ypadku je startov´an motorgener´ator. Urˇcitou dobu trv´a, neˇz na jeho v´ ystupu je pˇr´ıtomno napˇet´ı poˇzadovan´e kvality. Je vhodn´e poznamenat, ˇze v tomto momentˇe nen´ı k dispozici nap´ajec´ı napˇet´ı, proto nelze pˇrepnout v´ ykonov´e pˇrep´ınaˇce. Na obr. 1.16 a obr. 1.17 je tato doba naznaˇcena logaritmickou kˇrivkou (gener´ator) pˇred dobou T2 . V momentˇe, kdy je napˇet´ı poˇzadovan´e kvality, lze zaˇc´ıt s pˇrepnut´ım pˇrep´ınaˇce SOCOMEC ATYS. Nejprve do nulov´e polohy. Zde se setrv´av´a dobu T2 . Ta se vol´ı dle pˇripojen´e technologie, je nutn´e vz´ıt v u ´vahu, jak rychle dobˇehne nejpomalejˇs´ı elektrick´ y toˇciv´ y stroj a dle toho volit celkovou dobu T2 . V´ yznam t´eto doby je pops´an v´ yˇse. Po jej´ım uplynut´ı je moˇzn´e v pˇrepnut´ı pokraˇcovat a nastavit pˇrep´ınaˇc do polohy II. 17
ˇ ıd´ıc´ı program tesV t´eto poloze je dod´av´ana elektrick´a energie z motorgener´atoru. R´ tuje prim´arn´ı s´ıt’. V pˇr´ıpadˇe, ˇze je vyhodnocena pˇr´ıtomnost prim´arn´ı s´ıtˇe, je spuˇstˇeno testov´an´ı kvality s´ıtˇe po dobu T3 . Zde mus´ı b´ yt uplatnˇena n´asleduj´ıc´ı podm´ınka. Pokud z jak´ehokoliv d˚ uvodu bude prim´arn´ı s´ıt’ ztracena, pˇri jej´ım znovuobjeven´ı se mus´ı ˇcas T3 zaˇc´ıt poˇc´ıtat znovu. Tato podm´ınka vych´az´ı ze skuteˇcnosti, kdy prim´arn´ı s´ıt’ m˚ uˇze po n´abˇehu jeˇstˇe kol´ısat. S opˇetovn´ ym pˇrepojen´ım technologie je nutn´e vyˇckat aˇz do doby, kdy odezn´ı poˇc´ateˇcn´ı probl´emy s n´arazy“ zp˚ usoben´e n´abˇehem s´ıtˇe a okamˇzit´ ym pˇripojen´ım ” mnoha zaˇr´ızen´ı. D´ale se na obr. 1.16 a obr. 1.17 vyskytuje ˇcasov´ y interval T4 . Ten je moˇzn´e nazvat ˇ casem pro dochlazen´ı stroje. Vznˇetov´ y motor pˇri pr´aci do z´atˇeˇze vyv´ıj´ı kromˇe mechanick´e pr´ace tak´e teplo. To je odv´adˇeno chladiˇcem. Startovac´ı teplota, nastaven´a na termostatu vyhˇr´ıvaˇce kolem 80 ◦ C, je menˇs´ı neˇz je teplota vznˇetov´eho motoru pˇri chodu. Po skonˇcen´ı dod´avky elektrick´e energie se nech´a beˇzet motor bez z´atˇeˇze a t´ım dojde k pomˇernˇe u ´ˇcinn´emu ochlazen´ı na teplotu v bl´ızkosti teploty vyhˇr´ıvac´ı. Pˇri implementaci ˇr´ıdic´ıho algoritmu je nutn´e br´at v u ´vahu n´asleduj´ıc´ı. Pro velk´e“ agreg´aty m˚ uˇze doba T4 ” dos´ahnout ˇr´adu minut (napˇr. pro motor 600 kVA se obecnˇe doporuˇcuje T4 = 300s). Pokud v t´eto dobˇe dojde k v´ ypadku, je nutn´e na nˇej reagovat. Mnoho jednoduch´ ych ATS kontroler˚ u od renomovan´ ych firem s touto variantou nepoˇc´ıt´a. Jeden z hlavn´ıch poˇzadavk˚ u na tento vyv´ıjen´ y syst´em byl, aby v pˇr´ıpadˇe v´ ypadku prim´arn´ı s´ıtˇe v dobˇe dochlazen´ı T4 bylo reagov´ano a s´ıt’ testov´ana na v´ ypadek. V pˇr´ıpadˇe v´ ypadku pot´e jeho oˇsetˇren´ı, aniˇz by doˇslo k zastaven´ı motorgener´atoru. Pokud probˇehne dochlazen´ı v poˇr´adku (nedojde k v´ ypadku a je dopoˇc´ıt´an ˇcas T4 ) lze zastavit motorgener´ator. Posledn´ım ˇcasov´ ym intervalem na obr. 1.16 a obr. 1.17 je doba vyˇck´av´an´ı na vyhˇr´ıv´an´ı stroje T5 . Tato doba n´asleduje ihned po skonˇcen´ı doby dochlazen´ı T4 . M´a velk´ y v´ yznam, vznˇetov´ y motor nemus´ıme dochlazovat na pˇresnou teplotu nastavenou termostatem vyhˇr´ıvaˇce, staˇc´ı pouze zaˇc´ıt dochlazovat a vlivem nelinearity procesu (po uvolnˇen´ı z´atˇeˇzˇe motorgener´atoru - odpoj´ı se altern´ator - bude pracovat bez z´atˇeˇze a nebude vyv´ıjet nadmˇern´e teplo) se motor zpoˇc´atku bude ochlazovat pomalu, ale postupnˇe se teplota bude sniˇzovat rychleji. Proto lze motor zastavit dˇr´ıve a urˇcitou dobu vyˇckat do vyhˇr´ıv´an´ı. Efekt dochlazen´ı a vyhˇr´ıv´an´ı bude velmi podobn´ y, ale uˇsetˇr´ı se pohonn´e hmoty a elektrick´a energie na vyhˇr´ıv´an´ı. Tato doba se vol´ı v rozmez´ı 60 ÷ 120s.
Tabulka 1.1: Vysvˇetlen´ı ˇcasov´ ych interval˚ u
T1 T2 T3 T4 T5
doba testov´an´ı dlouhodob´eho v´ ypadku ˇcek´an´ı na zastaven´ı toˇciv´ ych stroj˚ u doba testov´an´ı kvality prim´an´ı s´ıtˇe doba dochlazen´ı motorgener´atoru ˇcek´an´ı do zaˇc´atku vyhˇr´ıv´an´ı
C1 T6
poˇcet kr´atk´ ych opakovan´ ych v´ ypadk˚ u doba testov´an´ı opakovan´ ych v´ ypadk˚ u 18
Obr´azek 1.18: Princip oˇsetˇren´ı v´ ypadku
19
1.3.2
ˇ ızen´ı rozvodny R´
V tomto projektu je pˇripojen´a technologie sloˇzena z r˚ uznorod´ ych zaˇr´ızen´ı. Jsou jimi hlavnˇe UPS, d´ale obecn´a z´atˇeˇz (charakteru kapacitn´ı-induktivn´ı) a dalˇs´ı. Z´aloˇzn´ı zdroj je koncipov´an pˇredevˇs´ım pro nap´ajen´ı v´ ypoˇcetn´ıho centra. Z nˇekolika pomˇernˇe z´avaˇzn´ ych d˚ uvod˚ u, mezi nˇeˇz patˇr´ı postupn´e proudov´e zatˇeˇzov´an´ı jak motorgener´atoru, tak i prim´arn´ı s´ıtˇe a tak´e potlaˇcen´ı nadmˇern´eho opotˇreben´ı kontakt˚ u vlivem jiskˇren´ı z d˚ uvod˚ u sp´ın´an´ı velk´ ych proud˚ u, byl realizov´an tzv. prioritn´ı syst´em pˇripojov´an´ı. Ten zajiˇst’uje, ˇze technologie je rozdˇelena na ˇc´asti s ohledem na poˇzadavky jejich chodu v pˇr´ıpadˇe v´ ypadku5 . Z´aroveˇ n s t´ım je rozloˇzeno pˇripnut´ı outlet˚ u na urˇcit´ y, pˇredem definovan´ y, ˇcasov´ y horizont. Nedojde tedy k pˇripnut´ı vˇsech outlet˚ u najednou. To m´a kladn´ y vliv nejen na opotˇreben´ı kontakt˚ u, ale i na proudov´e odbˇerov´e ˇspiˇcky jednak ze s´ıtˇe, ale tak´e z motorgener´atoru pˇri pˇrip´ın´an´ı technologie. Kdyby doˇslo k pˇripnut´ı najednou, mus´ı motorgener´ator dodat a pokr´ yt velk´ y proudov´ y n´araz, to ovˇsem nepˇrispˇeje k jeho bezporuchov´emu chodu (mus´ı se zv´ yˇsit ot´aˇcky, aby mohl pracovat v oblasti vyˇsˇs´ıho v´ ykonu a z´aroveˇ n je mechanicky zatˇeˇzov´an na hˇr´ıdeli altern´atorem). Pˇri v´ ypadku elektrick´e energie dojde k automatick´emu odepnut´ı (odpadnut´ı) vˇsech v´ yvod˚ u v rozvodnˇe. Jednotliv´ ym outlet˚ um byla pˇriˇrazena priorita dle jejich d˚ uleˇzitosti, pˇriˇcemˇz v´ yvod s nejvyˇsˇs´ı prioritou je oznaˇcen jako 1 a vzr˚ ustaj´ıc´ı ˇc´ıslo oznaˇcuje niˇzˇs´ı prioritu. Ta pˇredstavuje poˇrad´ı v jak´em se maj´ı outlety pˇripojovat. Mezi jednotliv´ ymi pˇripojen´ımi je ponech´an ˇcasov´ y rozestup. Vˇse je pˇrehlednˇe zpracov´ano v n´asleduj´ıc´ı tabulce.
Tabulka 1.2: Vysvˇetlen´ı priorit pˇripojov´an´ı outlet˚ u
v´ yvod
priorita
ˇcas pˇripnut´ı
celkov´ y ˇcas
RH_1_1 RH_2_1 RH_2_2
p1 p2 p3
30s p1 + 20s p2 + 30s
30s 50s 80s
Pˇri chodu z´aloˇzn´ıho zdroje v dlouhodob´em reˇzimu (dlouhodob´ y v´ ypadek el. energie) je nutn´e zachovat nepˇretrˇzit´e nap´ajen´ı vybran´ ych d˚ uleˇzit´ ych technologi´ı a stanovit priority v´ yvod˚ u, kter´e budou pˇri urˇcit´e hladinˇe pohonn´ ych hmot a v definovan´ y ˇcas odepnuty. Syst´em ˇr´ızen´eho odp´ın´an´ı je navrˇzen na nepˇretrˇzit´ y provoz po dobu 24 hodin pˇri dod´avce el. energie do technologie s prioritou 1 (nen´ı zde uvaˇzov´ana varianta doplnˇen´ı paliva do n´adrˇze po dobu oˇsetˇrov´an´ı v´ ypadku - nejhorˇs´ı varianta). Priorita zde opˇet pˇredstavuje poˇrad´ı v jak´em se budou outlety pˇripojovat. Odpojov´an´ı tedy bude v opaˇcn´em poˇrad´ı.
5
D´ale bude pojem ˇc´ ast technologie oznaˇcov´an slovem outlet
20
Tabulka 1.3: Odpojov´an´ı outlet˚ u v z´avislosti na mnoˇzstv´ı paliva
v´ yvod
priorita
≥80%
≥50%
≤30%
RH_1_1 RH_2_1 RH_2_2
p1 p2 p3
I I I
I I 0
I 0 0
Posledn´ı variantou, kter´a m˚ uˇze nastat je, ˇze pˇri oˇsetˇren´ı v´ ypadku dojde k doplnˇen´ı paliva. T´ım m˚ uˇze doj´ıt ke zmˇenˇe hladiny o jeden i v´ıce stav˚ u (vˇzdy je vˇsak zmˇena natolik pomal´a, aby byly pˇripnuty pˇr´ısluˇsn´e outlety vˇcas). Je proto nutn´e uzp˚ usobit ˇr´ıdic´ı program, aby kromˇe odpojov´an´ı technologi´ı dok´azal i technologie dle jejich priorit pˇripojovat. Zde jiˇz nen´ı striktn´ı poˇzadavek na ˇcasov´e odstupˇ nov´an´ı, protoˇze ke zmˇenˇe hladiny nebude 6 doch´azet ˇcasto . Empiricky byla zjiˇstˇena ˇcetnost a d´elka v´ ypadk˚ u. Zpracov´an´ım poskytnut´ ych dat byly z´ısk´any pˇribliˇzn´e u ´rovnˇe hladin a pˇr´ısluˇsn´e poˇzadavky na outlety. Z toho vych´az´ı u ´daje v tabulce 1.3. V pˇr´ıpadˇe neoˇcek´avan´e ud´alosti (napˇr. porucha hlavn´ıho motorgener´atoru KOHLER) je z´aloˇzn´ı SDMO.
6
N´adrˇz pro v´ ykon 600kVA m˚ uˇze m´ıt objem 1m3 , spotˇreba motoru pˇribliˇznˇe 80 l/h. Cyklus zjiˇstˇen´ı 1 nov´e hladiny je v ˇr´ adu 10 s. I s pˇripojen´ım stykaˇce pˇr´ısluˇsn´ ych outlet˚ u je zajiˇstˇena rychlost dostateˇcnˇe velk´a oproti ˇcerpadlu na naftu.
21
Obr´azek 1.19: Princip pˇrip´ın´an´ı a odep´ın´an´ı outlet˚ u
22
Kapitola 2 Datov´ a komunikace a pouˇ zit´ e protokoly 2.1
Ethernet
Ethernet je jeden z typ˚ u lok´aln´ıch s´ıt´ı, kter´ y realizuje vrstvu s´ıt’ov´eho rozhran´ı. Popularita spoˇc´ıv´a v jednoduchosti protokolu a t´ım i snadn´e implementaci i instalaci.
2.1.1
Princip a form´ at r´ amce
Klasick´ y Ethernet pouˇz´ıval sbˇernicovou topologii se sd´ılen´ ym m´ediem. Jednotliv´e stanice jsou na nˇem identifikov´any sv´ ymi hardwarov´ ymi adresami (MAC adresa). Kdyˇz stanice obdrˇz´ı paket s jinou neˇz vlastn´ı adresou, zahod´ı jej. Pro pˇr´ıstup ke sd´ılen´emu pˇrenosov´emu m´ediu se pouˇz´ıv´a metoda CSMA/CD (Carrier Sense with Multiple Access and Collision Detection). Stanice, kter´a potˇrebuje vys´ılat, naslouch´a, co se dˇeje na pˇrenosov´em m´ediu. Pokud je v klidu, zaˇcne stanice vys´ılat. M˚ uˇze se st´at (v d˚ usledku zpoˇzdˇen´ı sign´alu), ˇze dvˇe stanice zaˇcnou vys´ılat pˇribliˇznˇe ve stejn´ y okamˇzik. Jejich sign´aly se pochopitelnˇe navz´ajem seˇctou. Tato situace se naz´ yv´a kolize a vys´ılaj´ıc´ı stanice ji poznaj´ı podle toho, ˇze na pˇr´ıposlechu nosn´e nemaj´ı shodn´ y sign´al, kter´ y vys´ılaj´ı. Stanice, kter´a detekuje kolizi, vyˇsle kr´atk´ y sign´al (nazvan´ y jam“ o 32 bitech). Pot´e se vˇsechny vys´ılaj´ıc´ı stanice odmlˇc´ı a pozdˇeji se ” pokus´ı o nov´e vys´ıl´an´ı. P˚ uvodn´ı protokol s pˇrenosovou rychlost´ı 10 Mbit/s byl vyvinut firmami DEC, Intel a Xerox pro potˇreby kancel´aˇrsk´ ych aplikac´ı. Pozdˇeji byl v ponˇekud pozmˇenˇen´e podobˇe normalizov´an institutem IEEE jako norma IEEE 802.3. Tato norma byla pˇrevzata ISO jako ISO 8802-3. Form´at r´amc˚ u lok´aln´ı s´ıtˇe Ethernet II a IEEE 802.3 se skl´ad´a z pol´ı • preambule - 8 byte, stˇr´ıdavˇe bin´arn´ı 0 a 1, posledn´ı byte m´a tvar 10101011 a oznaˇcuje zaˇc´atek vlastn´ıho r´amce, slouˇz´ı k synchronizaci, posledn´ı byte se nˇekdy naz´ yv´a omezovaˇc poˇc´atku r´amce (Starting Frame Delimiter, SFD),
23
• pˇr´ıznak zaˇc´atku r´amce - 1B, • c´ılov´a adresa - fyzick´a MAC adresa o d´elce 48 bit˚ u, m˚ uˇze b´ yt individu´aln´ı (unicast), skupinov´a (multicast) a vˇseobecn´a (broadcast), • zdrojov´a adresa - fyzick´a adresa stejn´eho typu jako c´ılov´a, vˇzdy individu´aln´ı adresa konkr´etn´ı stanice, • typ protokolu nebo d´elka – pro Ethernet II je to pole urˇcuj´ıc´ı typ vyˇsˇs´ıho protokolu, – pro IEEE 802.3 ud´av´a toto pole d´elku pole dat, • data - pole dlouh´e minim´alnˇe 46 oktet˚ u a maxim´alnˇe 1500 oktet˚ u, minim´aln´ı d´elka je nutn´a pro spr´avnou detekci koliz´ı, • datov´a v´ yplˇ n - vypln´ı r´amec, pokud je pˇrepravovan´ ych dat m´enˇe neˇz 64B, • kontroln´ı souˇcet - (Frame Check Sequence, FCS) 32-bitov´ y CRC, poˇc´ıt´a se ze vˇsech pol´ı s v´ yjimkou preambule a FCS.
Obr´azek 2.1: Ethernetov´ y r´amec
2.2
RS-485
Jedn´a se o pr˚ umyslovou s´eriovou datovou komunikaci. Jej´ıch sluˇzeb vyuˇz´ıv´a mnoho r˚ uzn´ ych pr˚ umyslov´ ych sbˇernic (napˇr. PROFIBUS-DP, MODBUS atd.).
Obr´azek 2.2: Princip zapojen´ı sbˇernice RS-485
24
Linka RS-485 pˇredstavuje klasickou sbˇernici, kde lze jedn´ım p´arem vodiˇc˚ u propojit mezi sebou aˇz 32 zaˇr´ızen´ı, kter´a si maj´ı mezi sebou pˇren´aˇset data. Jde o obousmˇern´ y pˇrenos dat, ale protoˇze nelze po jednom p´aru najednou pˇren´aˇset data obˇema smˇery, je zde vyˇzadov´ano ˇr´ızen´ı smˇeru pˇrenosu. Bˇeˇznˇejˇs´ı je pouˇzit´ı dvouvodiˇcov´e verze sbˇernice RS-485, existuje i m´enˇe zn´am´a ˇctyˇrvodiˇcov´a verze, vyuˇz´ıvan´a napˇr´ıklad sbˇernic´ı Measurement Bus (DIN 66 348). Ta narozd´ıl od dvouvodiˇcov´e nab´ız´ı obousmˇernou komunikaci, tzn. nen´ı nutn´e se zab´ yvat ˇr´ızen´ım smˇeru komunikace, ale zase se u n´ı vyskytuje u ´skal´ı v podobˇe omezen´e vz´ajemn´e komunikace mezi zaˇr´ızen´ımi. Je totiˇz nutn´e pouˇz´ıt komunikaˇcn´ı model Master/Slave, kde v´ ystup nadˇrazen´e Master jednotky je pˇripojen na vstup vˇsech Slave jednotek a v´ ystupy vˇsech Slave jednotek na vstup Master jednotky. Terminace veden´ı je velice podstatn´a hlavnˇe pˇri vyˇsˇs´ıch rychlostech a delˇs´ıch kabelech. Hlavn´ımi d˚ uvody jsou pˇredevˇs´ım odrazy na konci veden´ı, definov´an´ı u ´rovnˇe na veden´ı a podm´ınka minim´aln´ıho zat´ıˇzen´ı vys´ılaˇce. Pro RS-485 nen´ı terminace zcela jednoduch´a. Jelikoˇz kaˇzd´e zaˇr´ızen´ı komunikuje obousmˇernˇe, nejsme schopni urˇcit, kde je vys´ılaˇc a kde pˇrij´ımaˇc. To se mˇen´ı podle toho, kter´e zaˇr´ızen´ı pr´avˇe vys´ıl´a. Proto je nutn´e na oba konce RS-485 veden´ı pˇripojit 100 Ω termin´ator. Protoˇze vˇsechny zaˇr´ızen´ı maj´ı tˇr´ıstavov´e v´ ystupy, nast´avaj´ı situace, kdy jsou vˇsechny vys´ılaˇce ve stavu vysok´e impedance a na veden´ı, d´ıky terminaˇcn´ım odpor˚ um, nen´ı definovan´ y ˇz´adn´ y stav (<200 mV). V tomto stavu je ale ˇz´adouc´ı aby napˇet´ı definovalo klidov´ y stav, tedy <-200 mV. Hodnoty terminaˇcn´ıch odpor˚ u jsou spoˇc´ıt´any tak, aby zapojen´ı vyhovˇelo maxim´aln´ımu poˇctu zaˇr´ızen´ı o vstupn´ı impedanci 12 kΩ, tj. 32, na jednom veden´ı. D˚ uleˇzit´e je aby terminaˇcn´ı odpory Rt byly pouze dva a to na konci kabelu (mohou b´ yt souˇc´ast´ı posledn´ıho zaˇr´ızen´ı na veden´ı). Jednotliv´e vodiˇce jsou oznaˇceny bud’ jako A(-), B(+), kde A(-) oznaˇcuje tzv. invertovan´ y vodiˇc a B(+) neinvertovan´ y vodiˇc. Logick´ y stav 1 (nˇekdy oznaˇcen´ y jako OFF), reprezentuje napˇet’ov´ y rozd´ıl (A − B) < −0.3 V, zat´ımco logick´ y stav 0 (ON) reprezentuje rozd´ıl (A − B) > +0.3 V. Pˇrenos pomoc´ı rozd´ılov´eho napˇet´ı eliminuje vliv naindukovan´eho ruˇsiv´eho napˇet´ı vztaˇzen´eho k nulov´emu potenci´alu, protoˇze se na obou vodiˇc´ıch naindukuje stejn´a velikost napˇet´ı. Spr´avn´ y vys´ılaˇc by mˇel generovat na v´ ystupu u ´rovnˇe +2 V a -2 V a pˇrij´ımaˇc by mˇel b´ yt jeˇstˇe schopen rozliˇsit u ´roveˇ n +200 mV a -200 mV jako platn´ y sign´al.
25
Obr´azek 2.3: Omezen´ı na maxim´aln´ı pˇrenosovou rychlost
Graf na obr. 2.3 ukazuje z´avislost pˇrenosov´e rychlosti na nˇekolika z´akladn´ıch podm´ınk´ach. 1. Maxim´aln´ı rychlost pˇrenosu na kr´atk´e vzd´alenosti, kde lze vliv veden´ı zanedbat, je d´ana v´ ystupn´ımi parametry vys´ılaˇce. Jedn´a se o dobu trv´an´ı n´abˇeˇzn´ ych a sestupn´ ych hran. Standard pˇredpokl´ad´a rychlost 10Mbit/s. 2. Veden´ı delˇs´ı neˇz 10m. Mus´ıme br´at v u ´vahu ztr´aty zp˚ usoben´e kapacitami a tzv. skin efektem, pˇri kter´em se proud zaˇc´ın´a ˇs´ıˇrit pouze po obvodu vodiˇc˚ u. Pravidlem pro standardn´ı TP kabely je, ˇze rychlost pˇrenosu (Mbit/s) n´asoben´a d´elkou veden´ı (m) je menˇs´ı neˇz 108 . Napˇr´ıklad pro 100m dlouh´ y kabel dost´av´ame maxim´aln´ı rychlost 1Mbit/s. 3. Posledn´ı omezen´ı se t´ yk´a velmi dlouh´ ych veden´ı. Rychlost je limitovan´a ohmick´ ym odporem veden´ı a n´asledn´ ym u ´tlumem sign´alu. Maxim´aln´ı d´elka kabelu vypl´ yv´a z jeho odporu, kter´ y by nemˇel b´ yt vetˇs´ı neˇz impedance veden´ı, tedy 1000 Ω. Nezanedbateln´a je tak´e kapacita veden´ı. Z podstaty RS-485 vypl´ yvaj´ı jist´a specifika, kter´a mus´ı software zajiˇst’ovat. Pˇredevˇs´ım se jedn´a o programov´e pˇridˇelov´an´ı komunikaˇcn´ıho m´edia jednotliv´ ym stanic´ım tak, aby nedoch´azelo ke vz´ajemn´ ym koliz´ım a z´aroveˇ n aby byla odezva stanic dostateˇcnˇe rychl´a. Je nutn´e pˇren´aˇset data, i bitovou a bytovou synchronizaci. Pro pˇrenos jednotliv´ ych bit˚ u je tedy vhodn´a jedna z modulac´ı pouˇz´ıvan´ ych v datov´ ych s´ıt´ıch (napˇr. k´odov´an´ı NRZ1 , NRZI2 , f´azov´a modulace NRZ, nebo diferenci´aln´ı f´azov´a modulace). Pro zajiˇstˇen´ı bytov´e synchronizace m´ame opˇet nˇekolik moˇznost´ı. Asi nejjednoduˇsˇs´ı je definov´an´ı jednoho specifick´eho bytu jako synchronizaˇcn´ı znaku. Lze tak´e vyuˇz´ıt pˇrenosov´ ych 3 protokol˚ u SDLC/HDLC , vhodn´ ych pro vysokorychlostn´ı pˇrenosy dat. 1
Non Return to Zero Non Return to Zero Invert 3 High-Level Data Link Control - detekuje chyby a ˇr´ıd´ı tok dat, synchronn´ı, asynchronn´ı pˇrenosy 2
26
Ze s´ıt’ov´eho hlediska se u RS-485 jedn´a o sbˇernicovou topologii. Jelikoˇz Slave stanice nemaj´ı ˇz´adnou moˇznost, jak zaˇc´ıt bez moˇzn´e kolize vys´ılat, mus´ı jim b´ yt pˇridˇeleno pr´avo vys´ılat Master stanic´ı. Mluv´ıme tedy o centr´aln´ım pˇridˇelov´an´ı, konkr´etnˇe pˇridˇelov´an´ı na v´ yzvu (pooling), kde se centr´aln´ı stanice (Master) periodicky dotazuje vˇsech Slave stanic, zda maj´ı data k odesl´an´ı. Pakliˇze ano, dotazovan´a stanice je ihned odeˇsle. Nem´a-li data k odesl´an´ı, odpov´ı pouze potvrzovac´ım paketem, nebo neodpov´ı v˚ ubec. Tato metoda se jev´ı jako nejv´ yhodnˇejˇs´ı pro Multipoint zapojen´ı. V syst´emech, kde Master stanice nem´a prioritn´ı funkci, je moˇzn´e pouˇz´ıt i jin´e pˇr´ıstupov´e metody. Napˇr´ıklad metoda n´ahodn´eho pˇr´ıstupu ALOHA. Jak´akoliv stanice vyˇsle svoje data bez ohledu na stav pˇrenosov´eho kan´alu. Dojde-li ke kolizi, pak tato stanice nedostane potvrzen´ı o doruˇcen´ı a opakuje vys´ıl´an´ı. U RS-485 je implementov´ana metoda ALOHA vylepˇsen´a o pˇr´ıposlech nosn´e“. Stanice v tomto pˇr´ıpadˇe zah´aj´ı vys´ıl´an´ı pouze v pˇr´ıpadˇe, ” je-li kan´al v klidov´em stavu. U obou tˇechto metod je nezbytnˇe nutn´ y pˇrenosov´ y protokol s detekc´ı chyb.
2.3
Protokol TCP/IP
Vzhledem ke sloˇzitosti probl´em˚ u je s´ıt’ov´a komunikace rozdˇelena do tzv. vrstev, kter´e zn´azorˇ nuj´ı hierarchii ˇcinnost´ı. V´ ymˇena informac´ı mezi vrstvami je pˇresnˇe definov´ana. Kaˇzd´a vrstva vyuˇz´ıv´a sluˇzeb vrstvy niˇzˇs´ı a poskytuje sv´e sluˇzby vrstvˇe vyˇsˇs´ı. Komunikace mezi stejn´ ymi vrstvami dvou r˚ uzn´ ych syst´em˚ u je ˇr´ızena komunikaˇcn´ım protokolem za pouˇzit´ı spojen´ı vytvoˇren´eho sousedn´ı niˇzˇs´ı vrstvou. Architektura umoˇzn ˇuje v´ ymˇenu protokol˚ u jedn´e vrstvy bez dopadu na ostatn´ı. Pˇr´ıkladem m˚ uˇze b´ yt moˇznost komunikace po r˚ uzn´ ych fyzick´ ych m´edi´ıch - ethernet, token ring, s´eriov´a linka. Architektura TCP/IP vyuˇz´ıv´a ˇctyˇri vrstevy z referenˇcn´ıho modelu OSI: • • • •
aplikaˇcn´ı vrstva (application layer) transportn´ı vrstva (transport layer) s´ıt’ov´a vrstva (network layer) vrstva s´ıt’ov´eho rozhran´ı LLC (logical link control)
Vrstva s´ıt’ov´eho rozhran´ı LLC je ˇc´ast spojov´e (linkov´e) vrstvy a umoˇzn ˇuje ˇr´ıdit pˇr´ıstup k fyzick´emu pˇrenosov´emu m´ediu. Je specifick´a pro kaˇzdou s´ıt’ v z´avislosti na jej´ı implementaci. S´ıt’ov´a vrstva MAC zajiˇst’uje pˇredevˇs´ım s´ıt’ovou adresaci, smˇerov´an´ı a pˇred´av´an´ı datagram˚ u. Obsahuje protokoly IP, ARP, RARP, ICMP, IGMP, IGRP, IPSEC. Je implementov´ana ve vˇsech prvc´ıch s´ıtˇe - smˇerovaˇc´ıch i koncov´ ych zaˇr´ızen´ıch. Transportn´ı vrstva je implementov´ana aˇz v koncov´ ych zaˇr´ızen´ıch a umoˇzn ˇuje pˇrizp˚ usobit chov´an´ı s´ıtˇe potˇreb´am aplikace. Poskytuje spojovan´e (protokol TCP, spolehliv´ y) ˇci nespojovan´e (UDP, nespolehliv´ y) transportn´ı sluˇzby. Aplikaˇcn´ı vrstva je nejvyˇsˇs´ı vrstvou standardn´ıho modelu ISO. To jsou programy (procesy), kter´e vyuˇz´ıvaj´ı pˇrenosu dat po s´ıti ke konkr´etn´ım sluˇzb´am pro uˇzivatele. Pˇr´ıkladem 27
mohou b´ yt Telnet, FTP, HTTP, DHCP, DNS apod. Aplikaˇcn´ı protokoly pouˇz´ıvaj´ı vˇzdy jednu ze dvou z´akladn´ıch sluˇzeb transportn´ı vrstvy: TCP nebo UDP, pˇr´ıpadnˇe obˇe dvˇe (napˇr. DNS). Pro rozliˇsen´ı aplikaˇcn´ıch protokol˚ u se pouˇz´ıvaj´ı tzv. porty, coˇz jsou domluven´a ˇc´ıseln´a oznaˇcen´ı aplikac´ı. Kaˇzd´e s´ıt’ov´e spojen´ı aplikace je jednoznaˇcnˇe urˇceno ˇc´ıslem portu, transportn´ım protokolem a adresou poˇc´ıtaˇce.
2.3.1
TCP - Transmission Control Protocol
Protokol TCP je jedn´ım ze z´akladn´ıch protokol˚ u Internetu, konkr´etnˇe implementuje transportn´ı vrstvu. Jedn´a se o spojovˇe orientovan´ y protokol pro pˇrenos toku bajt˚ u. Pouˇzit´ım TCP mohou aplikace na r˚ uzn´ ych poˇc´ıtaˇc´ıch propojen´ ych do s´ıtˇe vytvoˇrit spojen´ı, pˇres kter´e se budou pˇren´aˇset data. Vytvoˇren´e spojen´ı garantuje spolehliv´e doruˇcov´an´ı dat ve spr´avn´em poˇrad´ı. Protokol TCP podporuje aplikaˇcn´ı protokoly jako napˇr. WWW, emailu nebo SSH. V souˇcasnosti je zdokumentov´an v IETF RFC 793. V sadˇe protokol˚ u Internetu je TCP prostˇredn´ı vrstvou mezi IP protokolem pod n´ım a aplikac´ı nad n´ım. Aplikace ke vz´ajemn´e komunikaci vyuˇz´ıvaj´ı spolehliv´e spojen´ı na zp˚ usob roury, zat´ımco IP protokol poskytuje jen nespolehliv´e pakety. TCP pouˇz´ıv´a sluˇzby IP protokolu opakovan´ ym odes´ıl´an´ım nespolehliv´ ych paket˚ u. Pˇri ztr´atˇe paketu zajiˇst’uje spolehlivost a pˇreuspoˇr´ad´av´an´ım pˇrijat´ ych paket˚ u zajiˇst’uje spr´avn´e poˇrad´ı. T´ım TCP pln´ı u ´lohu transportn´ı vrstvy ve zjednoduˇsen´em modelu ISO/OSI poˇc´ıtaˇcov´e s´ıtˇe. Aplikace pos´ıl´a proud bajt˚ u TCP protokolu k doruˇcen´ı. Protokol TCP rozdˇeluje tento proud bajt˚ u do segment˚ u4 . TCP n´aslednˇe pˇred´a takto vznikl´e pakety IP protokolu k pˇrepravˇe s´ıt´ı do TCP modulu na druh´e stranˇe spojen´ı. D´ale TCP ovˇeˇr´ı, zda-li se nˇekter´e pakety neztratily (kaˇzd´emu paketu je pˇridˇeleno ˇc´ıslo sekvence, kter´e se tak´e pouˇzije k ovˇeˇren´ı spr´avn´eho poˇrad´ı dat). Modul TCP na stranˇe pˇr´ıjemce pos´ıl´a zpˇet potvrzen´ı pro pakety kter´e byly u ´spˇeˇsnˇe pˇrijaty. Pokud by se odesilateli potvrzen´ı nevr´atilo do definovan´e doby (RTT - Round-Trip Time), data by byla povaˇzov´ana za ztracen´a a bylo by nutn´e je vyslat znovu. Testov´an´ı na poˇskozen´ı dat napˇr. ˇsumem kan´al se prov´ad´ı kontroln´ım souˇctem. K rozliˇsen´ı komunikuj´ıc´ıch aplikac´ı pouˇz´ıv´a TCP protokol tzv. ˇc´ısla port˚ u. Kaˇzd´a 5 strana TCP spojen´ı m´a pˇridruˇzeno 16 b bezznam´enkov´e ˇc´ıslo portu pˇridˇelovan´e aplikacemi. Porty jsou rozˇclenˇeny do tˇrech skupin • dobˇre zn´am´e porty - pˇriˇrazov´any organizac´ı IANA (Internet Assigned Numbers Authority) a jsou vesmˇes pouˇz´ıvan´e syst´emov´ ymi procesy, Tyto porty uˇz´ıvaj´ı aplikace bˇeˇz´ıc´ı jako servery a pasivnˇe pˇrij´ımaj´ıc´ı spojen´ı, pˇr´ıkladem jsou FTP (porty 21, 20), SMTP (port 25), DNS (port 53) a HTTP (port 80), • registrovan´e porty - jsou typicky pouˇz´ıvan´e aplikacemi koncov´ ych uˇzivatel˚ u pˇri otev´ır´an´ı spojen´ı k server˚ um, tak´e mohou identifikovat sluˇzby, • dynamick´e/priv´atn´ı porty - mohou b´ yt tak´e pouˇz´ıv´any koncov´ ymi aplikacemi, ale nen´ı to obvykl´e. 4
Velikost segment˚ u je urˇcena parametrem MTU (Maximum Transmission Unit) linkov´e vrstvy s´ıtˇe, ke kter´e je poˇc´ıtaˇc pˇripojen. 5 existuje max. 65 535 port˚ u
28
2.3.2
IP - Internet Protocol
Protokol IP je datov´ y protokol pouˇz´ıvan´ y pro pˇrenos dat pˇres paketov´e s´ıtˇe. Tvoˇr´ı z´akladn´ı protokol dneˇsn´ıho Internetu. Data se v IP s´ıti pos´ılaj´ı po bloc´ıch naz´ yvan´ ych datagramy. Jednotliv´e datagramy putuj´ı s´ıt´ı zcela nez´avisle, na zaˇc´atku komunikace nen´ı potˇreba navazovat spojen´ı ˇci jinak vytv´aˇret datovou cestu, pˇrestoˇze spolu tˇreba pˇr´ısluˇsn´e stroje nikdy pˇredt´ım nekomunikovaly. Protokol IP v doruˇcov´an´ı datagram˚ u poskytuje nespolehlivou sluˇzbu, oznaˇcuje se tak´e jako best effort, v pˇrekladu nejlepˇs´ı u ´sil´ı“. Tedy, vˇsechny stroje na trase se datagram ” snaˇz´ı podle sv´ ych moˇznost´ı poslat bl´ıˇze k c´ıli, ale nezaruˇcuj´ı prakticky nic. Datagram v˚ ubec nemus´ı dorazit, nebo naopak m˚ uˇze b´ yt doruˇcen nˇekolikr´at a nen´ı ani zaruˇceno poˇrad´ı doruˇcen´ ych paket˚ u. Pokud aplikace potˇrebuje spolehlivost, je potˇreba ji implementovat v jin´e vrstvˇe s´ıt’ov´e architektury, typicky TCP protokol, kter´ y je bezprostˇrednˇe nad IP. Pokud by s´ıt’ ˇcasto ztr´acela pakety, mˇenila jejich poˇrad´ı nebo je poˇskozovala, v´ ykon s´ıtˇe pozorovan´ y uˇzivatelem by byl mal´ y. Na druhou stranu pˇr´ıleˇzitostn´a chyba nem´ıv´a pozorovateln´ y efekt. Nav´ıc se obvykle pouˇz´ıv´a vyˇsˇs´ı vrstva, kter´a ji automaticky oprav´ı.
2.3.2.1
Smˇ erov´ an´ı, verze IP, IP adresy a jejich struktura
Kaˇzd´e s´ıt’ov´e rozhran´ı komunikuj´ıc´ı prostˇrednictv´ım IP m´a pˇriˇrazeno jednoznaˇcn´ y identifik´ator, tzv. IP adresu. V kaˇzd´em datagramu je pak uvedena IP adresa odes´ılatele i pˇr´ıjemce. Na z´akladˇe IP adresy pˇr´ıjemce pak kaˇzd´ y poˇc´ıtaˇc na trase prov´ad´ı rozhodnut´ı, jak´ ym smˇerem paket odeslat - tzv. smˇerov´an´ı. Na starosti to maj´ı specializovan´e stroje oznaˇcovan´e jako smˇerovaˇce (routery). Dnes se nejˇcastˇeji pouˇz´ıv´a verze oznaˇcovan´a ˇc´ıslem 4 (naz´ yvan´a IPv4), obsahuj´ıc´ı 32 b adresy. Navrhovan´ ym n´astupcem je IPv6. V internetu pozvolna doch´azej´ı adresy a IPv6 m´a krom jin´eho adresy 128 b, kter´e poskytuj´ı vˇetˇs´ı adresn´ı prostor (IPv4 m´a miliardy adres, IPv6 stovky sextili´on˚ u). Adresa IP je jednoznaˇcn´a identifikace konkr´etn´ıho zaˇr´ızen´ı v prostˇred´ı Internetu. Veˇsker´a data pos´ılan´a s´ıt´ı obsahuj´ı IP adresu odesilatele i pˇr´ıjemce. Protoˇze by pro bˇeˇzn´e uˇzivatele poˇc´ıtaˇcov´ ych s´ıt´ı bylo velice obt´ıˇzn´e pamatovat si ˇc´ıseln´e adresy, existuje syst´em specializovan´ ych poˇc´ıtaˇc˚ u DNS (Domain Name System), kter´e pˇrev´adˇej´ı dom´enov´a jm´ena na IP adresy a opaˇcnˇe. Adresa IPv4 je 32 b ˇc´ıslo, zapisovan´e po jednotliv´ ych bajtech des´ıtkovˇe, oddˇelen´ ych 32 9 teˇckami, napˇr. 192.168.1.10. Takov´ ych ˇc´ısel existuje celkem 2 ≈ 4·10 . Urˇcit´a ˇc´ast adres je ovˇsem rezervov´ana pro vnitˇrn´ı potˇreby protokolu a nemohou b´ yt pˇridˇeleny. D´ale pak praktick´e d˚ uvody vedou k tomu, ˇze adresy je nutno pˇridˇelovat hierarchicky, takˇze cel´ y adresn´ı prostor nen´ı moˇzn´e vyuˇz´ıt beze zbytku.Nedostatek adres se ˇreˇs´ı r˚ uzn´ ymi zp˚ usoby: • dynamick´ ym pˇridˇelov´an´ım - kaˇzd´ y uˇzivatel dostane doˇcasnou IP adresu, pˇri pˇr´ıˇst´ım pˇripojen´ı m˚ uˇze tent´ yˇz uˇzivatel dostat u ´plnˇe jinou adresu
29
• pˇrekladem adres - (NAT - Network Address Translation), ke spr´avˇe tohoto pˇridˇelov´an´ı slouˇz´ı specializovan´e s´ıt’ov´e protokoly, jako napˇr. DHCP6 . Adresa IPv4 se dˇel´ı na tˇri z´akladn´ı ˇc´asti - adresa s´ıtˇe, adresa pods´ıtˇe a adresa poˇc´ıtaˇce. Koncepce adresy m´a velk´ y v´ yznam pro smˇerov´an´ı – mimo c´ılovou s´ıt’ se smˇeruje podle adresy s´ıtˇe, a aˇz kdyˇz je IP datagram doruˇcen do n´ı, zaˇc´ın´a se br´at ohled i na detailnˇejˇs´ı ˇc´asti adresy. Adresu s´ıtˇe pˇridˇeluje poskytovatel pˇripojen´ı - lok´aln´ı registr´ator. Strukturu lok´aln´ı ˇc´asti adresy (zda bude rozdˇelena na pods´ıtˇe, jak´a ˇc´ast bude vˇenov´ana adrese pods´ıtˇe a jak´a adrese poˇc´ıtaˇce) urˇcuje spr´avce s´ıtˇe. Ten tak´e pˇridˇeluje adresy. Hranici mezi adresou pods´ıtˇe a poˇc´ıtaˇce urˇcuje maska pods´ıtˇe. Jedn´a se o 32 b hodnotu zapisovanou podobnˇe jako IP adresa. V bin´arn´ım tvaru obsahuje jedniˇcky tam, kde se v adrese nach´az´ı s´ıt’ a pods´ıt’, a nuly tam, kde je poˇc´ıtaˇc. Maska pods´ıtˇe je spoleˇcnˇe s IP adresou souˇca´st´ı z´akladn´ı konfigurace s´ıt’ov´eho rozhran´ı, obvykle se pˇred´av´a protokolem DHCP. V zaˇc´atc´ıch Internetu bylo rozdˇelen´ı adresy na s´ıt’ a lok´aln´ı ˇc´ast fixn´ı. Prvn´ıch 8 b adresy urˇcovalo s´ıt’, zbytek pak stroj v s´ıti. To vˇsak umoˇzn ˇovalo pouze 256 s´ıt´ı a v kaˇzd´e mohlo b´ yt pˇres 16 milion˚ u stanic. Nyn´ı je moˇzno pˇredˇel mezi adresou s´ıtˇe a lok´aln´ı ˇc´ast´ı adresy umist’ovat libovolnˇe. Dan´a adresa se pak znaˇc´ı kombinac´ı prefixu a d´elky ve formˇe 192.168.24.0/21 coˇz znamen´a, ˇze tato s´ıt’ je urˇcena prvn´ımi 21 b adresy, zbytek je adresa stanice. Tato s´ıt’ pouˇz´ıv´a rozsah adres 192.168.24.0 – 192.168.31.255. Nejniˇzˇs´ı adresa v s´ıti (s nulovou adresou stanice) slouˇz´ı jako oznaˇcen´ı cel´e s´ıtˇe, nejvyˇsˇs´ı adresa v s´ıti slouˇz´ı jako adresa pro vˇsesmˇerov´e vys´ıl´an´ı (broadcast), takov´e adresy tedy nelze pouˇz´ıt pro norm´aln´ı u ´ˇcely. Adresy 127.x.x.x (tzv. localhost, nejˇcastˇeji se pouˇz´ıv´a adresa 127.0.0.1) jsou rezervov´any pro tzv. loopback, logickou smyˇcku umoˇzn ˇuj´ıc´ı pos´ılat pakety s´am sobˇe. D´ale jsou vyˇclenˇeny rozsahy tzv. intern´ıch (neveˇrejn´ ych) IP adres, kter´e se pouˇz´ıvaj´ı pouze pro adresov´an´ı vnitˇrn´ıch s´ıt´ı (napˇr. lok´aln´ıch) • ve tˇr´ıdˇe A: 10.0.0.0 aˇz 10.255.255.255 (celkem 16 777 214 adres) • ve tˇr´ıdˇe B: 172.16.0.0 aˇz 172.31.255.255 (celkem 16kr´at 65 534 adres (tj. celkem 1 048 544)) • ve tˇr´ıdˇe C: 192.168.x.0 aˇz 192.168.x.255 (celkem 256kr´at 254 adres)
6
Dynamic Host Configuration Protocol umoˇzn ˇuje nastavit vˇsem stanic´ım sadu parametr˚ u nutn´ ych pro komunikaci vˇcetnˇe parametr˚ u doplˇ nuj´ıc´ıch a uˇzivatelsky definovan´ ych, v´ yznamn´ ym zp˚ usobem tak zjednoduˇsuje a centralizuje spr´ avu poˇc´ıtaˇcov´e s´ıtˇe, parametry nastaviteln´e pomoc´ı DHCP (IP adresa, maska s´ıtˇe, br´ana, DNS servery)
30
2.4
Protokol MODBUS
Jedn´a se o otevˇren´ y komunikaˇcn´ı protokol na u ´rovni aplikaˇcn´ı vrstvy ISO/OSI modelu, umoˇzn ˇuj´ıc´ı komunikaci typu klient-server mezi zaˇr´ızen´ımi na r˚ uzn´ ych typech s´ıt´ı a sbˇernic. Vytvoˇren byl v roce 1979 francouzskou firmou MODICON, dnes souˇc´ast´ı SCHNEIDER ELECTRIC. V souˇcasn´e dobˇe je podporov´ana cel´a ˇrada komunikaˇcn´ıch m´edi´ı napˇr. s´eriov´e linky typu RS-232, RS-422 a RS-485, optick´e a r´adiov´e s´ıtˇe nebo s´ıt’ Ethernet s vyuˇzit´ım upraven´eho protokolu MODBUS TCP/IP. Komunikace prob´ıh´a metodou poˇzadavek-odpovˇed’ a poˇzadovan´a funkce je specifikov´ana pomoc´ı k´odu funkce, jeˇz je souˇc´ast´ı poˇzadavku.
Obr´azek 2.4: Pˇr´ıklad implementace protokolu MODBUS
Protokol MODBUS definuje strukturu zpr´avy na u ´rovni protokolu (PDU – Protocol Data Unit) nez´avisle na typu komunikaˇcn´ı vrstvy. V z´avislosti na typu s´ıtˇe, na kter´e je protokol pouˇzit, je PDU rozˇs´ıˇren o dalˇs´ı ˇc´asti a tvoˇr´ı tak zpr´avu na aplikaˇcn´ı u ´rovni (ADU – Application Data Unit).
Obr´azek 2.5: Z´akladn´ı tvar MODBUS zpr´avy
K´od funkce ud´av´a serveru jak´ y druh operace m´a prov´est. Rozsah k´od˚ u je 1 aˇz 255, pˇriˇcemˇz k´ody 128 aˇz 255 jsou vyhrazeny pro ozn´amen´ı z´aporn´e odpovˇedi (chyby). Nˇekter´e k´ody funkc´ı obsahuj´ı i k´od podfunkce upˇresˇ nuj´ıc´ı bl´ıˇze poˇzadovanou operaci. Obsah datov´e ˇc´asti zpr´avy poslan´e klientem slouˇz´ı serveru k uskuteˇcnˇen´ı operace urˇcen´e k´odem funkce. Obsahem m˚ uˇze b´ yt napˇr´ıklad adresa a poˇcet vstup˚ u, kter´e m´a server pˇreˇc´ıst nebo hodnota registr˚ u, kter´e m´a server zapsat. U nˇekter´ ych funkc´ı nejsou pro proveden´ı operace zapotˇreb´ı dalˇs´ı data a v tom pˇr´ıpadˇe m˚ uˇze datov´a ˇc´ast ve zpr´avˇe u ´plnˇe chybˇet. Pokud pˇri prov´adˇen´ı poˇzadovan´e operace nedojde k chybˇe ( obr. 2.6), odpov´ı server zpr´avou, kter´a v poli K´od funkce“ obsahuje k´od poˇzadovan´e funkce jako indikaci u ´spˇeˇs” 31
n´eho vykon´an´ı poˇzadavku. V datov´e ˇc´asti odpovˇedi pˇred´a server klientovi poˇzadovan´a data (pokud jsou nˇejak´a).
Obr´azek 2.6: MODBUS transakce s bezchybn´ ym proveden´ım poˇzadavku
Pokud pˇri vykon´av´an´ı poˇzadovan´e operace dojde k chybˇe, je v poli K´od funkce“ vr´acen ” k´od poˇzadovan´e funkce s nastaven´ ym nejvyˇsˇs´ım bitem indikuj´ıc´ım ne´ uspˇech (exception response). V datov´e ˇc´asti je vr´acen chybov´ y k´od (exception code) upˇresˇ nuj´ıc´ı d˚ uvod ne´ uspˇechu. Maxim´aln´ı velikost PDU je zdˇedˇena z prvn´ı implementace MODBUSu na RS-485, kde byla maxim´aln´ı velikost ADU 256 byt˚ u. Tomu odpov´ıd´a maxim´aln´ı velikost PDU 253 byt˚ u.
velikost ADU na RS-485 velikost ADU na TCP/IP
253 B PDU + adresa (1 B) + CRC (2 ) ≈ 256 B 253 B PDU + MBAP ≈ 260 B
Protokol MODBUS definuje 3 z´akladn´ı typy zpr´av (PDU): • Poˇzadavek (Request PDU) – 1 byte . . . K´od funkce – n byt˚ u . . . Datov´a ˇc´ast poˇzadavku – adresa, promˇenn´e, poˇcet promˇenn´ ych • Odpovˇed’ (Response PDU) – 1 byte . . . K´od funkce (kopie z poˇzadavku) – m byt˚ u . . . Datov´a ˇc´ast odpovˇedi – pˇreˇcten´e vstupy, stav zaˇr´ızen´ı • Z´aporn´a odpovˇed’ (Exception Response PDU) – 1 byte . . . K´od funkce + 80h (indikace ne´ uspˇechu) – 1 byte . . . Chybov´ y k´od (identifikace chyby) K´ odov´ an´ı dat Protokol MODBUS pouˇz´ıv´a tzv. big-endian“ reprezentaci dat. To znamen´a, ˇze pˇri ” pos´ıl´an´ı datov´ ych poloˇzek delˇs´ıch neˇz 1 byte je jako prvn´ı pos´ıl´an nejvyˇsˇs´ı byte a jako posledn´ı nejniˇzˇs´ı byte.
32
2.4.1
Datov´ y model
Datov´ y model MODBUSu je zaloˇzen na sadˇe tabulek, s charakteristick´ ym v´ yznamem. Definov´any jsou ˇctyˇri z´akladn´ı tabulky: Tabulka 2.1: Datov´ y model MODBUS
tabulka
poloˇzka
pˇr´ıstup
popis
adresa
diskr´etn´ı vstupy c´ıvky
1b
ˇcten´ı
data poskytov´ana I/O syst´emem
10000÷19999
1b
ˇcten´ı/z´apis
vstupn´ı registry uchov´avac´ı registry
16 b
ˇcten´ı
data modifikovateln´a aplikaˇcn´ım 0÷9999 programem data poskytovan´a I/O syst´emem 30000÷39999
16 b
ˇcten´ı/z´apis
data modifikovateln´a aplikaˇcn´ım 40000÷49999 programem
Mapov´an´ı tabulek do adresn´ıho prostoru je z´avisl´e na konkr´etn´ım zaˇr´ızen´ı. Kaˇzd´a z tabulek m˚ uˇze m´ıt vlastn´ı adresn´ı prostor nebo se mohou ˇc´asteˇcnˇe ˇci u ´plnˇe pˇrekr´ yvat. Kaˇzd´a z tabulek m˚ uˇze m´ıt dle protokolu aˇz 65 536 poloˇzek. Z d˚ uvodu zpˇetn´e kompatibility b´ yv´a adresn´ı prostor rozdˇelen na bloky o velikosti 10 000 poloˇzek tak, jak je uvedeno ve sloupci adresa“ ( tabulka 2.1). Pˇr´ıstupn´a je kaˇzd´a poloˇzka jednotlivˇe nebo lze pˇristupovat ke ” skupinˇe poloˇzek najednou. Velikost skupiny poloˇzek je omezena maxim´aln´ı velikost´ı datov´e ˇc´asti zpr´avy. Na obr. 2.7 jsou zn´azornˇeny dva moˇzn´e zp˚ usoby organizace dat v zaˇr´ızen´ı, obr. 2.7(a) zn´azorˇ nuje zaˇr´ızen´ı, u kter´eho nen´ı ˇz´adn´ y vztah mezi poloˇzkami jednotliv´ ych tabulek a kaˇzd´a tabulka m´a tedy sv˚ uj oddˇelen´ y prostor v aplikaˇcn´ı pamˇeti zaˇr´ızen´ı. Do jednotliv´ ych tabulek lze pˇristupovat prostˇrednictv´ım pˇr´ısluˇsn´e funkce MODBUSu. Oproti tomu obr. 2.7(b) zn´azorˇ nuje zaˇr´ızen´ı, kter´e m´a pouze jeden datov´ y blok. K poloˇzk´am lze pˇristupovat prostˇrednictv´ım r˚ uzn´ ych funkc´ı MODBUSu v z´avislosti na tom, co je pro aplikaci v dan´em okamˇziku v´ yhodn´e.
Obr´azek 2.7: Datov´ y model (a) s oddˇelen´ ymi bloky, (b) s jedin´ ym blokem
Adresovac´ı model Protokol MODBUS pˇresnˇe definuje adresovac´ı pravidla ve zpr´av´ach (PDU). V MODBUS 33
zpr´av´ach jsou datov´e poloˇzky adresov´any od 0 do 65 535. D´ale je definov´ano adresov´an´ı v r´amci datov´eho modelu sloˇzen´eho ze 4 datov´ ych blok˚ u (tabulek), datov´e bloky jsou ˇc´ıslov´any od 1 do n. Mapov´an´ı poloˇzek datov´eho modelu do aplikace v serveru je z´avisl´e na v´ yrobci. Definice MODBUS transakc´ı Stavov´ y diagram na obr. 2.8 ukazuje obecn´ y postup zpracov´an´ı MODBUS poˇzadavku na stranˇe serveru. Jakmile server zpracuje poˇzadavek, sestav´ı odpovˇed’ a odeˇsle ji klientovi. V z´avislosti na v´ ysledku zpracov´an´ı poˇzadavku je vytvoˇrena jedna ze dvou moˇzn´ ych odpovˇed´ı: • Pozitivn´ı odpovˇed’ (Response) – k´od funkce v odpovˇedi = k´od funkce v poˇzadavku • Negativn´ı odpovˇed’ (Exception Response) – k´od funkce v odpovˇedi = k´od funkce v poˇzadavku + 80h – je vr´acen k´od chyby ud´avaj´ıc´ı d˚ uvod ne´ uspˇechu
Obr´azek 2.8: Obecn´ y postup zpracov´an´ı MODBUS poˇzadavku na stranˇe serveru
34
Kategorie k´ od˚ u funkc´ı MODBUS protokol definuje tˇri skupiny k´od˚ u funkc´ı • veˇrejn´e k´ody funkc´ı - jasnˇe definovan´e, garantov´ana unik´atnost, schvalov´any spoleˇcnost´ı MODBUS-IDA.org, veˇrejnˇe zdokumentovan´e, dostupn´ y test shody, zahrnuj´ı veˇrejn´e pˇriˇrazen´e k´ody funkc´ı i nepˇriˇrazen´e k´ody rezervovan´e pro budouc´ı pouˇzit´ı, • uˇzivatelsky definovan´e k´ody funkc´ı - dva rozsahy uˇzivatelsky definovan´ ych k´od˚ u funkc´ı: 65 ÷ 72 a 100 ÷ 110, umoˇzn ˇuj´ı uˇzivateli implementovat funkci, kter´a nen´ı definov´ana touto specifikac´ı, nen´ı garantov´ana unik´atnost k´od˚ u, lze je po projedn´an´ı pˇresunout do veˇrejn´ ych k´od˚ u, • rezervovan´e k´ody funkc´ı - k´ody funkc´ı, kter´e jsou v souˇcasnosti pouˇz´ıv´any nˇekter´ ymi firmami a kter´e nejsou dostupn´e pro veˇrejn´e pouˇzit´ı
Obr´azek 2.9: Pˇrehled funkˇcn´ıch k´od˚ u
35
Z´ aporn´ e odpovˇ edi Kdyˇz klient pos´ıl´a serveru poˇzadavek, oˇcek´av´a na nˇej odpovˇed’. Mohou nastat ˇctyˇri situace. • Server pˇrijme bezchybnˇe poˇzadavek a je schopen jej norm´alnˇe zpracovat, vr´at´ı klientovi norm´aln´ı odpovˇed’. • Server poˇzadavek nepˇrijme z d˚ uvodu komunikaˇcn´ı chyby, nen´ı vr´acena ˇz´adn´a odpovˇed’. Na stranˇe klienta dojde k vyprˇsen´ı ˇcasov´eho limitu pro pˇr´ıjem odpovˇedi. • Server pˇrijme poˇzadavek, ale detekuje komunikaˇcn´ı chybu (parita, CRC apod.), nevrac´ı ˇz´adnou odpovˇed’. Na stranˇe klienta dojde k vyprˇsen´ı ˇcasov´eho limitu pro pˇr´ıjem odpovˇedi. • Server pˇrijme bezchybnˇe poˇzadavek, ale nen´ı schopen jej norm´alnˇe zpracovat, vr´at´ı klientovi z´apornou odpovˇed’ s ud´an´ım d˚ uvodu ne´ uspˇechu. Norm´aln´ı a z´aporn´a odpovˇed’ se liˇs´ı nejvyˇsˇs´ım bitem k´odu funkce. Je-li bit nulov´ y, jedn´a ’ ’ se o norm´aln´ı odpovˇed , je-li bit nastaven´ y, jedn´a se o z´apornou odpovˇed . V pˇr´ıpadˇe z´aporn´e odpovˇedi je v datov´e ˇc´asti pˇred´an k´od chyby. V n´asleduj´ıc´ı tabulce je seznam moˇzn´ ych chybov´ ych k´od˚ u. Tabulka 2.2: MODBUS chybov´e k´ody
k´od
jm´eno
01 02 03 04 05
ileg´aln´ı funkce ileg´aln´ı adresa dat ileg´aln´ı hodnota dat selh´an´ı zaˇr´ızen´ı potvrzen´ı
06 07 0A
0B
v´ yznam
poˇzadovan´a funkce nen´ı serverem podporov´ana zadan´a adresa je mimo serverem podporovan´ y rozsah pˇred´avan´a data jsou neplatn´a pˇri prov´adˇen´ı poˇzadavku doˇslo k neodstraniteln´e chybˇe k´od urˇcen´ y k pouˇzit´ı pˇri programov´an´ı. Server hl´as´ı pˇrijet´ı platn´eho poˇzadavku, ale jeho vykon´an´ı bude trvat delˇs´ı dobu zaˇr´ızen´ı je k´od urˇcen´ y k pouˇzit´ı pˇri programov´an´ı. Server je zanepr´azdnˇen´e zanepr´azdnˇen vykon´av´an´ım dlouho trvaj´ıc´ıho pˇr´ıkazu. chyba parity pamˇeti k´od urˇcen´ y k pouˇzit´ı pˇri pr´aci se soubory. Server pˇri pokusu pˇreˇc´ıst soubor zjistil chybu parity br´ana – pˇrenosov´a k´od urˇcen´ y k pr´aci s br´anou (gateway). Br´ana nen´ı cesta nedostupn´a schopn´a vyhradit intern´ı pˇrenosovou cestu od vstupn´ıho portu k v´ ystupn´ımu. Pravdˇepodobnˇe je pˇret´ıˇzen´a nebo nespr´avnˇe nastaven´a. br´ana – c´ılov´e zaˇr´ızen´ı k´od urˇcen´ y k pr´aci s br´anou (gateway). C´ılov´e zaˇr´ızen´ı neodpov´ıd´a neodpov´ıd´a, pravdˇepodobnˇe nen´ı pˇr´ıtomno.
36
2.4.2
Implementace MODBUSu
MODBUS standard definuje kromˇe aplikaˇcn´ı vrstvy ISO/OSI modelu i nˇekter´e implementace protokolu na konkr´etn´ı typ s´ıtˇe nebo sbˇernice. Pˇr´ıkladem je MODBUS TCP/IP a MODBUS na s´eriov´e lince pro fyzickou vrstvu RS-232 a RS-485.
2.4.2.1
MODBUS TCP/IP
Protokol Modbus TCP, vyvinut´ y v roce 1979 spoleˇcnost´ı Modicon, je dnes levn´ ym a jednoduˇse pouˇziteln´ ym protokolem, kter´ y je povaˇzov´an za standard. Byl zaˇclenˇen do protokolu IP jako TCP 502 a v souˇcasn´e dobˇe se jeho v´ yvoj op´ır´a o organizaci Modbus.org, jej´ımˇz c´ılem je zdokonalovat a propagovat Modbus jako prvn´ı pr˚ umyslov´ y internetov´ y protokol. Ke sbˇernic´ım s protokolem Modbus je pˇripojeno pˇres milion s´eriov´ ych zaˇr´ızen´ı, zat´ımco s protokolem Modbus TCP/IP jich pracuje nˇekolik set tis´ıc. Velkou pˇrednost´ı protokolu je jeho stabilita. Protokol je s´am o sobˇe otevˇren´ y a informace o nˇem jsou volnˇe dostupn´e. V aplikac´ıch klient/server umoˇzn ˇuje komunikaci v re´aln´em ˇcase mezi zaˇr´ızen´ımi pˇres Ethernet TCP/IP s dobou odezvy od 0,24 s aˇz 1 s. Implementace sluˇzby I/O scanning zvyˇsuje v´ ykonnost protokolu, pouˇz´ıv´a se pro rychlou v´ ymˇenu dat se vzd´alen´ ymi vstupnˇe/v´ ystupn´ımi jednotkami nebo frekvenˇcn´ımi mˇeniˇci. Sledov´an´ı je prov´adˇeno z ˇr´ıdic´ıho syst´emu pomoc´ı dotaz˚ u Modbus TCP Read/Write. Pokud je tˇreba zajistit synchronizaci v re´aln´em ˇcase v rozs´ahlejˇs´ıch distribuovan´ ych aplikac´ıch, pˇrich´az´ı v u ´vahu sluˇzba Global Data. Umoˇzn ˇuje zaˇr´ızen´ım na s´ıti zapisovat (publish), nebo z´ısk´avat (subscribe) data. Doba v´ ymˇeny dat se tak redukuje na polovinu, nen´ı tˇreba se na data dotazovat. Na obr. 2.10 je zn´azornˇen form´at zpr´avy na TCP/IP. Pro identifikaci MODBUS ADU je pouˇzita MBAP hlaviˇcka (MODBUS Application Protocol Header). Pro pos´ıl´an´ı MODBUS/TCP ADU je na TCP vyhrazen registrovan´ y port 502.
Obr´azek 2.10: MODBUS TCP/IP zpr´ava
2.4.2.2
MODBUS na s´ eriov´ e lince
MODBUS Serial Line protokol je typu Master-Slave a je definov´an na s´ıt’ov´e vrstvˇe ISO/OSI modelu. Na fyzick´e u ´rovni mohou b´ yt pouˇzita r˚ uzn´a s´eriov´a rozhran´ı, napˇr´ıklad RS-232 nebo RS-485 a jejich varianty. Princip komunikace je Master/Slave, tedy v jeden okamˇzik m˚ uˇze b´ yt na sbˇernici pouze jeden master a 1 aˇz 247 slave jednotek. Komunikaci vˇzdy zahajuje master, slave nesm´ı 37
nikdy vys´ılat data bez povˇeˇren´ı mastera. Master pos´ıl´a poˇzadavky slave jednotk´am ve dvou reˇzimech:
• unicast reˇzim . . . master adresuje poˇzadavek jedn´e konkr´etn´ı slave jednotce a ta poˇsle odpovˇed’, • broadcast reˇzim . . . master pos´ıl´a poˇzadavek vˇsem jednotk´am, ˇz´adn´a jednotka neodpov´ı.
Adresn´ı prostor zahrnuje 256 r˚ uzn´ ych adres. Master nem´a ˇz´adnou specifickou adresu, pouze slave jednotky musej´ı m´ıt adresu a ta mus´ı b´ yt v cel´e MODBUS s´ıti jedineˇcn´a. Pravidlem je, ˇze adresa 0 je vyhrazena pro broadcast a adresy 248 ÷ 255 jsou rezervov´any.
Obr´azek 2.11: MODBUS zpr´ava na s´eriov´e lince
Na obr. 2.11 je zn´azornˇen z´akladn´ı form´at MODBUS aplikaˇcn´ı zpr´avy na s´eriov´e lince. Zpr´ava kromˇe standardn´ı MODBUS PDU obsahuje pole Adresa jednotky“. Toto pole ” obsahuje adresu slave jednotky. Pole Kontroln´ı souˇcet“ slouˇz´ı k detekci chyb a obsahuje ” CRC nebo LRC k´od v z´avislosti na vys´ılac´ım reˇzimu. Protokol MODBUS definuje dva s´eriov´e vys´ılac´ı reˇzimy, MODBUS RTU a MODBUS ASCII. Reˇzim urˇcuje v jak´em form´atu jsou data vys´ıl´ana a n´aslednˇe dek´odov´ana. Kaˇzd´a jednotka mus´ı podporovat reˇzim RTU, reˇzim ASCII je nepovinn´ y. Vˇsechny jednotky na jedn´e sbˇernici musej´ı pracovat ve stejn´em vys´ılac´ım reˇzimu.
MODBUS RTU V reˇzimu RTU obsahuje kaˇzd´ y 8 b byte zpr´avy dva 4 b hexadecim´aln´ı znaky. Vys´ıl´an´ı zpr´avy mus´ı b´ yt souvisl´e, mezery mezi znaky nesmˇej´ı b´ yt delˇs´ı neˇz 1.5 znaku. Zaˇc´atek a konec zpr´avy je identifikov´an podle pomlky na sbˇernici delˇs´ı neˇz 3.5 znaku. Form´at RTU r´amce je zn´azornˇen na obr. 2.12. K detekci chyb slouˇz´ı 16-bitov´e CRC pole s generuj´ıc´ım polynomem x16 + x15 + x2 + 1. Kaˇzd´a jednotka mus´ı podporovat sudou paritu. Pokud nen´ı pouˇzita parita, je nahrazena druh´ ym stop bitem.
38
Obr´azek 2.12: RTU r´amec zpr´avy
Form´at bytu (11 bit˚ u) 1 8 1 1
start bit datov´ ych bit˚ u bit parita stop bit
MODBUS ASCII V reˇzimu ASCII je kaˇzd´ y 8 b byte pos´ıl´an jako dvojice ASCII znak˚ u. Oproti reˇzimu RTU je tedy pomalejˇs´ı, ale umoˇzn ˇuje vys´ılat znaky s mezerami aˇz 1 s. Zaˇc´atek a konec zpr´avy je totiˇz urˇcen odliˇsnˇe od RTU m´odu. Zaˇc´atek zpr´avy je indikov´an znakem :“ a konec ” zpr´avy dvojic´ı ˇr´ıdic´ıch znak˚ u CR, LF. Form´at ASCII r´amce je na obr. 2.13. K detekci chyb slouˇz´ı 8 b LRC pole. Kaˇzd´a jednotka mus´ı podporovat sudou paritu. Pokud nen´ı pouˇzita parita, je nahrazena druh´ ym stop bitem.
Obr´azek 2.13: ASCII r´amec zpr´avy
Form´at bytu (10 bit˚ u) 1 7 1 1
start bit datov´ ych bit˚ u bit parita stop bit
39
2.5
Protokol SNMP - Simple Network Management Protocol
Protokol SNMP byl p˚ uvodnˇe urˇcen pro usnadnˇen´ı spr´avy s´ıtˇe, moˇznosti jeho vyuˇzit´ı jsou podstatnˇe vˇetˇs´ı a st´ale ˇcastˇeji pronik´a i do pr˚ umyslov´e automatizace a mˇeˇric´ı techniky. Protokol je asynchronn´ı, transakˇcnˇe orientovan´ y, zaloˇzen´ y na modelu klient/server. Strana, kter´a pos´ıl´a poˇzadavky (SNMP klient), m˚ uˇze b´ yt napˇr. jednoduch´ y SNMP browser ˇci sloˇzit´ y NMS (Network Management System). Na stranˇe zaˇr´ızen´ı je SNMP agent (SNMP server), kter´ y na poˇzadavky odpov´ıd´a. V´ yjimku tvoˇr´ı tzv. trapy, kter´e agenti vys´ılaj´ı asynchronnˇe pˇri v´ yskytu jednotliv´ ych ud´alost´ı (v´ ypadek proudu, pˇrekroˇcen´ı mezn´ıch u ´daj˚ u, pˇripojen´ı nov´eho zaˇr´ızen´ı). Je nutn´e pˇredem definovat adresu, kam se informace pos´ıl´a. Pro pˇrenos dat se pouˇz´ıv´a protokol UDP, pˇriˇcemˇz je definov´ano pˇresnˇe m´ısto, kam se mohou pˇripojovat uˇzivatelsk´e aplikace jednotliv´ ych firem, kter´e spravuje organizace IANA (Internet Assigned Numbers Authority - doslovnˇe: Internetov´a autorita pro pˇridˇelov´an´ı ˇc´ısel). Typick´ ymi u ´lohami pro SNMP protokol jsou • • • • • • •
zjiˇst’ov´an´ı stavov´ ych informac´ı o zaˇr´ızen´ıch (mnoˇzstv´ı voln´e pamˇeti, poˇcet spojen´ı, poˇcet pˇrihl´aˇsen´ ych uˇzivatel˚ u, ...) nastavov´an´ı parametr˚ u (atribut˚ u) na s´ıt’ov´ ych prvc´ıch monitorov´an´ı uptimu monitorov´an´ı verz´ı bˇeˇz´ıc´ıch syst´em˚ u sbˇer dat o existuj´ıc´ıch s´ıt’ov´ ych rozhran´ıch (ifName, ifDescr, ifSpeed, ifType, ifPhysAddr) measuring network interface throughput (ifInOctets, ifOutOctets) dotazov´an´ı ARP7 (ipNetToMedia)
SNMP je uzp˚ usobeno k pˇrenosu nad nespolehliv´ ym kan´alem, vyuˇz´ıv´a protokol UDP. ’ Bˇez´ı na nejr˚ uznˇejˇs´ıch s´ıt ov´ ych protokolech. Od verze SNMP v2 pracuje jako samostatn´ y aplikaˇcn´ı protokol. Typicky bˇeˇz´ı na portu 161 pro agenty a 162 pro management. Agent odpov´ıd´a na portu, na kter´em pˇriˇsel dotaz, TRAP zas´ıl´a na port 162. SNMP v1 neposkytoval zabezpeˇcen´ı, autentizace se pos´ılala po s´ıti v plain textu. SNMP v1 a SNMP v2 (RFC 1441, RFC 1452) nejsou kompatibiln´ı, dva zp˚ usoby spolupr´ace ˇreˇs´ı RFC 1908 a to pomoc´ı proxy agentu a dvouprotokolov´e s´ıtˇe. SNMP v3 (RFC 3411, RFC 3418, 2004) je nejnovˇejˇs´ı standard. Souˇcasn´ı klienti obvykle podporuj´ı vˇsechny tˇri m´ody protokolu (viz RFC 3584). SNMP v3 ˇreˇs´ı autentizaci a zabezpeˇcen´ı pomoc´ı ˇsifrov´an´ı (AES - Advanced Encryption Standard).
2.5.1
Historie
Protokol SNMP zaˇcal vznikat v roce 1988 jako reakce na potˇrebu efektivn´ı platformy pro spr´avy poˇc´ıtaˇcov´ ych s´ıt´ı. V roce 1990 byl instituc´ı IAB (Internet Acitivities Board) potvrzen jako standard s´ıtˇe internet. Prvn´ı specifikace protokolu, RFC 1157, vznikla v 40
roce 1989 a stanovovala vlastnosti SNMP v1. Specifikovala jen pˇr´ıkazy get, get next, set, trap a vyuˇz´ıvala pouze ochranu heslem - community string. Toto byl pravdˇepodobnˇe hlavn´ı nedostatek, kter´ y pˇretrval jeˇstˇe ve v2, kter´a d´ale definovala pˇr´ıkaz get bulk pro snazˇs´ı z´ısk´av´an´ı informac´ı z tabulek (napˇr. routing table atp.). Ochrana heslem je nedostateˇcn´a, protoˇze heslo lze pomˇernˇe jednoduˇse zjistit analyz´atorem paket˚ u. Souˇcasn´a specifikace protokolu SNMP v3 poch´az´ı z roku 1998 (pˇrijata 2002) a umoˇzn ˇuje ochranu dat i pomoc´ı DES8 ˇsifrovac´ıho algoritmu.
• •
get-request get-next-request
• •
set-request trap
•
get-response
•
get-bulk
•
inform
z´ısk´an´ı informace z MIB umoˇzn ˇuje managerovi z´ıskat informace o objektech v MIB bez znalosti jejich pˇresn´ ych jmen, umoˇzn ˇuje postupn´e proch´azen´ı cel´ ym hierarchick´ ym stromem zmˇena hodnoty promˇenn´e agenta jedin´ y typ pˇr´ıkazu vys´ılan´ y bez pˇredchoz´ıho vyˇz´ad´an´ı, agent jej zas´ıl´a managerovi jako reakci na specifikovanou ud´alost, zpr´ava z˚ ust´av´a nepotvrzen´a, proto agent nem´a jistotu, zda byla doruˇcena agent vykon´a tuto operaci jako reakci na pˇredchoz´ı pˇr´ıkazy je to vlastnˇe odpovˇed’ agenta managerovi. Odpovˇed’ obsahuje i dotaz, protoˇze protokol nezajiˇst’uje souvislost mezi dotazem a odpovˇed´ı operace, kter´a je souˇc´ast´ı SNMP v2, umoˇzn ˇuje vyˇz´adat si k pˇreˇcten´ı celou skupinu informac´ı z MIB, ˇc´ımˇz se mnohdy urychluje komunikace umoˇzn ˇuje komunikaci dvou manager˚ u mezi sebou
Protokol SNMP v1 je z´akladn´ı, SNMP v2 obsahuje nav´ıc autentizaci a SNMP v3 nav´ıc ˇsifrov´an´ı. Nejv´ıce zaˇr´ızen´ı podporuje SNMP v2. Na monitorovan´e stranˇe jsou shromaˇzd’ov´any informace o stavu zaˇr´ızen´ı. Z´ıskan´ y obsah zpr´av se na monitorovac´ı stranˇe m˚ uˇze d´ale zpracov´avat (tabulky, grafy). Na monitorovan´e stranˇe m˚ uˇze existovat moˇznost konfigurace, kdy agent zaˇsle managerovi informace automaticky bez jeho poˇzadavku. K tomu dojde zpravidla potom, kdy byla splnˇena pˇredem definovan´a podm´ınka (v´ ypadek, kolize, dosaˇzen´ı hraniˇcn´ı hodnoty), agent neˇcek´a na odpovˇed’. Takov´e konfiguraci agenta se ˇr´ık´a SNMP TRAP.
8
DES je symetrick´ a ˇsifra vyvinut´ a v 70. letech. V souˇcasnosti je tato ˇsifra povaˇzov´ana za nespolehlivou, protoˇze pouˇz´ıv´ a kl´ıˇc pouze o d´elce 56 b. Nav´ıc algoritmus obsahuje slabiny, kter´e d´ale sniˇzuj´ı bezpeˇcnost ˇsifry. D´ıky tomu je moˇzn´e ˇsifru prolomit u ´tokem hrubou silou za m´enˇe neˇz 24 hodin.
41
Obr´azek 2.14: Form´at SNMP zpr´avy)
Kaˇzd´a hodnota v SNMP je jednoznaˇcnˇe identifikov´ana pomoc´ı ˇc´ıseln´eho identifik´atoru OID - Object Identifier. Tento identifik´ator je tvoˇren posloupnost´ı ˇc´ısel oddˇelen´ ych teˇckou, hodnota vznikne doplnˇen´ım nadˇrazen´eho OID o aktu´aln´ı ˇc´ıslo. Cel´a tato stromov´a struktura je uloˇzena v MIB datab´azi. Nav´ıc datab´aze obsahuje jm´ena a popisy jednotliv´ ych hodnot (OID). MIB m˚ uˇze b´ yt doplnˇena o dalˇs´ı hodnoty pomoc´ı ˇc´asti struktury uloˇzen´e v MIB souboru. Pˇr´ıkladem OID m˚ uˇze b´ yt hodnota 1.3.6.1.2.1.2.2.1.6.1, kter´e odpov´ıd´a textov´a verze z MIB datab´aze iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifPhysAddress. Textov´a reprezentace MIB je pojmenovan´ y modul, kter´ y mus´ı vyhovovat syntaktick´ ym pravidl˚ um podmnoˇziny jazyka ASN.1 (Abstract Syntax Notation One) a seskupuje dohromady odpov´ıdaj´ıc´ı definice. Jeden nebo v´ıce tˇechto modul˚ u je uchov´ano jako standardn´ı ASCII soubor.
2.5.2
SNMP Global Naming Tree
Kaˇzd´ y objekt zaˇr´ızen´ı mus´ı m´ıt jedineˇcn´e jm´eno, aby se na nˇej dalo odkazovat. Protoˇze jedno zaˇr´ızen´ı m˚ uˇze obsahovat objekty definovan´e nez´avisle nˇekolika r˚ uzn´ ymi v´ yrobci, sch´ema pro pojmenov´an´ı tˇechto objekt˚ u muselo b´ yt navrˇzeno tak, aby nemohlo doj´ıt k z´amˇenˇe. Centr´aln´ı registr vˇsech moˇzn´ ych objekt˚ u by byl nekoneˇcnˇe velik´ y, byla proto zvolena koncepce hierarchick´eho stromu SNMP Global Naming Tree, vyvinut´eho organizac´ı ISO (www.iso.org).
42
Obr´azek 2.15: SNMP Global Naming Tree
Standardn´ı MIB struktura tedy odpov´ıd´a tomuto SNMP Global Naming Tree, kter´ y se skl´ad´a z objekt˚ u root, subtree a leaf. Kaˇzd´a ˇc´ast tohoto stromu m´a oznaˇcen´ı, kter´e se skl´ad´a ze dvou ˇc´ast´ı - struˇcn´eho textov´eho popisu a ˇc´ıseln´eho k´odu. Koˇrenov´ y uzel (root) je s´am bez popisu, ale pod n´ım jsou vˇzdy minim´alnˇe tˇri uzly
• • • •
iso(1) ccitt(0) set-request joint-iso-ccitt(2)
spravov´an organizac´ı ISO, spravov´an organizac´ı ITU-T (b´ yval´e CCITT), zmˇena hodnoty promˇenn´e agenta, spoleˇcnˇe spravov´ano ISO a ITU-T.
Jednotliv´ ym v´ yrobc˚ um zaˇr´ızen´ı jsou pˇridˇelov´any subtree (jsou jmenov´ani v´ ykonn´ ymi autoritami) a mohou si tak vytv´aˇret vlastn´ı neomezenou strukturu. Takto vznikl´e priv´atn´ı MIB popisuj´ı vlastnosti konkr´etn´ıho zaˇr´ızen´ı. Vˇetˇsinou jsou ale v´ yrobci zveˇrejˇ nov´any, pr´avˇe z d˚ uvodu umoˇznˇen´ı spr´avy tˇechto prvk˚ u i aplikacemi jin´ ych v´ yrobc˚ u. Jm´eno uzlu, tzv. object identifier, je tak tvoˇreno sekvenc´ı ˇc´ıseln´ ych k´od˚ u na cestˇe z root“ pˇres subtree“ aˇz k dan´emu objektu typu leaf“. Tato decim´aln´ı notace reprezen” ” ” tuje tedy cestu ke kaˇzd´e z funkc´ı nebo schopnost´ı dan´eho zaˇr´ızen´ı. Jde o podobn´ y syst´em jako pˇri specifikac´ıch pln´ ych cest k soubor˚ um v syst´emech UNIX a DOS, pˇriˇcemˇz nejvyˇsˇs´ı u ´roveˇ n zaˇc´ın´a v objektu (root). Textov´ y popis slouˇz´ı ke snazˇs´ı orientaci v t´eto struktuˇre. Na obr. 2.15 je schematicky zn´azornˇena ˇc´ast t´eto struktury, kde je vidˇet postaven´ı jednotliv´ ych objekt˚ u, funkc´ı a cestu k jejich dosaˇzen´ı. Ve vˇetvi internet(1) jsou vytvoˇreny tˇri logick´e skupiny 43
•
Management Branch
• • •
Experimental Branch Private Branch joint-iso-ccitt(2)
2.5.3
standardn´ı MIB, kter´e byly vytvoˇreny org´anem IETF (www.ietf.org), jsou um´ıstˇeny v ˇc´asti (... internet(1)mgmt(2)) hierarchick´e struktury MIB a obsahuj´ı definovan´e objekty pro nˇekter´e bˇeˇzn´e s´ıt’ov´e zaˇr´ızen´ı a protokoly. Tuto skupinu podporuj´ı zaˇr´ızen´ı vˇetˇsiny v´ yrobc˚ u a tak umoˇzn ˇuj´ı jejich nez´avislou spr´avu tato vˇetev zahrnuje MIB, kter´e jsou zat´ım ve v´ yvoji zmˇena hodnoty promˇenn´e agenta priv´atn´ı MIB jednotliv´ ych v´ yrobc˚ u jsou lokalizov´any v ˇc´asti (iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)). Tato vˇetev tak umoˇzn ˇuje jednotliv´ ym v´ yrobc˚ um vytv´aˇret MIB pro sv´a vlastn´ı zaˇr´ızen´ı, jimˇz nedostaˇcuj´ı standardn´ı MIB, napˇr. object identifier 1.3.6.1.4.1.45 reprezentuje cestu k objekt˚ um firmy SynOptics, 1.3.6.1.4.1.23 cestu k objekt˚ um Novell, 1.3.6.1.4.1.9 cestu k objekt˚ um Cisco, atd.
Typy SNMP objekt˚ u
SNMP objekty mohou b´ yt v z´asadˇe dvou typ˚ u - skal´arn´ı hodnoty a tabulky. Objekty typu skal´ar mohou nab´ yvat pouze jednoduch´e nestrukturovan´e hodnoty. Jedn´a se o standardn´ı typy •
Integer
•
Counter
•
Gauge
•
TimeTicks
• •
IpAddress OCTET STRING
•
OBJECT IDENTIFIER
cel´e ˇc´ıslo, vˇetˇsina implementac´ı omezuje tento typ velikost´ı 32 b, nez´aporn´ y integer, plynule se zvˇetˇsuje aˇz do hodnoty (232 1), pot´e znovu od nuly, absolutn´ı hodnota je m´enˇe d˚ uleˇzit´a neˇz rozd´ıl od posledn´ıho vzorku, ze kter´eho lze usuzovat na rychlost zmˇen, nez´aporn´ y integer, hodnota m˚ uˇze vzr˚ ustat i klesat, ale nem˚ uˇze pˇrekroˇcit max. hodnotu (231), nez´aporn´ y integer, ˇcas v setin´ach sekundy od jist´e doby (modulo (232 - 1)), napˇr. doba chodu zaˇr´ızen´ı 32 b IP adresa sekvence byt˚ u, uˇz´ıv´a se k vyj´adˇren´ı ˇretˇezce znak˚ u (jm´eno syst´emu), nebo libovoln´ ych bin´arn´ıch dat (MAC adresy zaˇr´ızen´ı) reprezentuje jm´eno uzlu, SNMP dovoluje dalˇs´ı typy skal´arn´ıch hodnot (NULL, Opaque a Network Address), kter´e se ale nepouˇz´ıvaj´ı
Jako rozˇs´ıˇren´ı tˇechto nestrukturovan´ ych jednoduch´ ych objekt˚ u dovoluje standard SNMP strukturovat data do tabulek. Tyto tabulky jsou pak uspoˇr´ad´any do ˇr´adk˚ u a sloupc˚ u (ob44
doba datab´azov´ ych z´aznam˚ u). Jednotliv´e poloˇzky takov´eto tabulky mohou b´ yt libovoln´e skal´arn´ı hodnoty. Tabulky nelze do sebe vnoˇrovat. Nelze prov´adˇet SNMP operace nad tabulkami jako celkem, ale jen nad jednotliv´ ymi skal´arn´ımi objekty - hodnotami v tabulce. Pˇr´ıkladem tabulky mohou b´ yt smˇerovac´ı tabulky router˚ u tcpConnTable (object identifier 1.3.6.1.2.1.6.13) a jednotliv´e sloupce reprezentuj´ı hodnoty tcpConnState, tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress a tcpConnRemPort. Identifikace jednotliv´ ych pol´ı v SNMP tabulk´ach se prov´ad´ı pomoc´ı index˚ u. Tˇemi jsou bud’ jednoduch´e hodnoty nebo sady hodnot. K jednotliv´ ym pol´ım pak m˚ uˇzeme pˇristupovat n´ahodnˇe, tedy pˇr´ıkazem get se specifikac´ı pozice nebo sekvenˇcnˇe pˇr´ıkazem get-next proch´azet celou tabulku.
2.5.4
MIB datab´ aze - Management Information Base
MIB je datab´aze, kter´a dovoluje jednoznaˇcnˇe identifikovat informace vyuˇz´ıvan´e syst´emem spr´avy. Aby mohl SNMP manager i agent tyto informace z´ıskat a pˇred´avat, tak je nutn´a znalost struktury MIB. B´aze dat je objektovˇe orientovan´a. Data jsou uloˇzena jako objekty a sdruˇzuj´ı se do tˇr´ıd. Jednotliv´e objekty maj´ı hodnoty. Kaˇzd´ y ˇr´ızen´ y objekt v MIB obsahuje veˇsker´e informace potˇrebn´e pro popis. Zp˚ usob pojmenov´an´ı objekt˚ u je zaloˇzen na jejich vztahu. Jeden objekt m˚ uˇze obsahovat jin´e objekty nebo jin´e tˇr´ıdy. MIB je tedy tvoˇrena jedn´ım stromem. Kaˇzd´ y agent by mˇel udrˇzovat objekty standardn´ı MIB (napˇr. s´ıt’ov´e adresy, typy rozhran´ı, ˇc´ıtaˇce). Jsou definov´any tˇri mechanismy pro pˇrid´an´ı: • • •
pˇrid´an´ı nov´ ych objekt˚ u prostˇrednictv´ım definice nov´e verze MIB-II pˇrid´an´ı nestandardn´ıch objekt˚ u pˇrid´an´ım experiment´aln´ı vˇetve pˇrid´an´ı vlastn´ıch objekt˚ u v r´amci podstromu soukrom´e vˇetve
Do MIB byly zaˇrazeny jen nejnutnˇejˇs´ı objekty. Pˇredem byly vylouˇceny objekty sv´ ym zp˚ usobem nadbyteˇcn´e, kter´e maj´ı konkr´etn´ı vztahy s jin´ ymi objekty v MIB. Jednoduchost definice a omezen´a velikost b´aze umoˇzn ˇuje zaruˇcit minim´aln´ı dopad na ˇcinnost a sloˇzitost agent˚ u. To se projev´ı v n´aroc´ıch na zpracovatelsk´ y syst´em. Dnes lze nal´ezt spoustu existuj´ıc´ıch a v praxi pouˇz´ıvan´ ych syst´em˚ u, kter´e 24 hodin dennˇe, 7 dn´ı v t´ ydnu, 365 dn´ı v roce monitoruj´ı stav syst´em˚ u a sluˇzeb v poˇc´ıtaˇcov´e s´ıti. V pˇr´ıpadˇe v´ ypadku informuj´ı definovan´ ymi kan´aly (nejˇcastˇeji email, SMS, vizu´aln´ı v´ ystraha) pˇr´ısluˇsnou obsluhu, popˇr. spust´ı definovanou akci. D´ıky podpoˇre SNMP nen´ı probl´em realizovat syst´em pro sbˇer informac´ı z agent˚ u, kteˇr´ı SNMP podporuj´ı, a sestavit tak konkr´etn´ı aplikaci, kter´a se bude chovat podle naˇsich poˇzadavk˚ u. N´aslednˇe pak lze realizovat skuteˇcnˇe velmi jednoduˇse syst´em, kter´ y bude pˇr´ısluˇsn´a data zpˇr´ıstupˇ novat na webov´ ych str´ank´ach. Nav´ıc z´ısk´ame moˇznost testov´an´ı a monitorov´an´ı ˇr´ızen´eho syst´emu tˇret´ı stranou.
45
46
Kapitola 3 V´ yvojov´ a prostˇ red´ı 3.1
CoDeSys - Controlled Development System
Software CoDeSys je univerz´aln´ı v´ yvojov´e prostˇred´ı pro aplikaˇcn´ı programy ˇr´ıdic´ıch syst´em˚ u PLC. Bylo vytvoˇreno firmou 3S (Smart Software Solution) dle standardu IEC 611311 3 , kter´ y popisuje jednotnost a ˇc´asteˇcnou zamˇenitelnost d´ıky tomu, ˇze definuje povinn´e jazyky a jejich syntaxi tak, aby program´ator nemusel zn´at mnoˇzstv´ı navz´ajem r˚ uzn´ ych jazyk˚ u. Norma vˇsak nic neˇr´ık´a o zp˚ usobu ovl´ad´an´ı programu a zp˚ usobu konfigurace hardwarov´ ych perif´eri´ı a komunikac´ı, takˇze kaˇzd´ y v´ yrobce vol´ı vlastn´ı zp˚ usob ˇreˇsen´ı. CoDeSys obsahuje celkem ˇsest r˚ uzn´ ych programovac´ıch jazyk˚ u (pˇriˇcemˇz norma IEC 61131-3 definuje pouze pˇet programovac´ıch jazyk˚ u). Mezi jazyky je moˇzn´e volnˇe pˇrep´ınat a na kaˇzdou danou ˇc´ast programu pouˇz´ıt nejvhodnˇejˇs´ı programovac´ı jazyk. Jedn´a se o n´asleduj´ıc´ı jazyky: • IL ... instrukˇcn´ı list (PLC assembler), • LD ... ˇzebˇr´ıˇckov´ y diagram (Ladder Diagram) – je v souˇcasn´e dobˇe nejobl´ıbenˇejˇs´ı jazyk uˇz´ıvan´ y program´atory, • FBD ... funkˇcn´ı diagram (Function Block Diagram) je LD rozˇs´ıˇren´ y o vol´an´ı funkc´ı, • SFC ... sekvenˇcn´ı funkˇcn´ı diagram (Sequential Function Chart) je jazyk vhodn´ y pro sekvenˇcn´ı aplikace, kdy vstup do dalˇs´ı ˇc´asti programu je podm´ınˇen vykon´an´ım ˇc´asti pˇredchoz´ı a splnˇen´ım zadan´ ych podm´ınek, urˇcit´a varianta obecn´ ych Petriho s´ıt´ı, • ST ... strukturovan´ y text (Structured Text) – je vyˇsˇs´ı programovac´ı jazyk vhodn´ y pro pokroˇcil´e matematick´e aplikace a sloˇzit´e algoritmy, jazyk je velmi podobn´ y napˇr. prostˇred´ı Pascal, 1
Mezin´ arodn´ı norma IEC 61131 (zpracovan´a organizac´ı PLCopen a ofici´alnˇe vydan´a Mezin´arodn´ı elektrotechnickou komis´ı (International Electrotechnical Commission – IEC)) se vˇenuje programovateln´ ym automat˚ um – jejich funkci, proveden´ı hardwaru a komunikac´ı i zp˚ usob˚ um jejich programov´an´ı. Odborn´e veˇrejnosti je nejzn´ amˇejˇs´ı jej´ı tˇret´ı ˇc´ ast, tj. IEC 61131-3, t´ ykaj´ıc´ı se programov´an´ı automat˚ u (forma uˇzivatelsk´ ych program˚ u, deklarace promˇenn´ ych a typ˚ u dat, zp˚ usoby aktivace program˚ u a popis programovac´ıch jazyk˚ u).
47
• CFC ... spojit´ y funkˇcn´ı diagram (Continuous Function Chart). CoDeSys umoˇzn ˇuje pˇri pr´aci na projektu jeho naprogramov´an´ı (textov´e a grafick´e editory), odladˇen´ı a testov´an´ı, vizualizaci procesu, uveden´ı do provozu, vytvoˇren´ı dokumentace. V popisovan´em ˇreˇsen´ı je vyuˇz´ıv´ano PLC od spoleˇcnosti WAGO. V´ yrobce mus´ı dodat knihovny a ovladaˇce, aby bylo moˇzn´e se k PLC pˇripojit a vytv´aˇret programy. V n´asleduj´ıc´ı kapitole bude pops´ano zaloˇzen´ı, sestaven´ı a nakonec i vloˇzen´ı kompilovan´e aplikace do PLC kontrol´eru. Tato verze prostˇred´ı je 2.3.8.5 (vyd´ana 5.10.2007) a podporuje PLC s firmwarem FW14 a niˇzˇs´ı. Jeho v´ yhodou je pln´a podpora MIB tabulek pro SNMP protokol.
Zaloˇzen´ı nov´eho projektu se skl´ad´a z v´ ybˇeru spr´avn´eho v´ yrobce a kontrol´eru (v pˇr´ıpadˇe, ˇze je nainstalov´ana podpora v´ıce v´ yrobc˚ u a jejich PLC kontroler˚ u). V tomto n pˇr´ıpadˇe se jedn´a o model s ethernetov´ ym rozhran´ım s oznaˇcen´ım WAGO 750-841. Z´aroveˇ je nutn´e vybrat verzi firmwaru. Je nab´ıdnuta moˇznost firmware do verze 11 (...-FW11) a od verze 12 (FW12-...). Dalˇs´ı dialog s n´azvem Terget Settings (viz obr. 3.1) obsahuje pˇet karet. Z´aloˇzka Memory Layout ukazuje z´akladn´ı adresy pro k´od, pamˇet’ov´ y prostor, vstupy, v´ ystupy apod. a jejich rozsah. Z´aroveˇ n je zde zobrazena informace o maxim´aln´ım poˇctu POUs (viz d´ale). Karta General obsahuje check box Online Change. Zaˇskrtnut´ım se pamˇet’ rozdˇel´ı na polovinu a je moˇzn´e prov´adˇet pˇri pˇripojen´ı k PLC jednoduch´e zmˇeny programu (nen´ı nutn´e pro zmˇenu programu se odhlaˇsovat od PLC). Karta Network functionality obsahuje check box Support network variables. Pokud jsou propojeny alespoˇ n dvˇe PLC, je moˇzn´e pomoc´ı tˇechto s´ıt’ov´ ych promˇenn´ ych prov´adˇet v´ ymˇenu informac´ı. V t´eto pr´aci byly s´ıt’ov´e promˇenn´e pouˇzity a konfigurace bude pops´ana v dalˇs´ı kapitole. Posledn´ı kartou je Visualization. Zde je moˇzn´e nastavit velikost obrazovky na kterou se tvoˇr´ı vizualizace (optimalizace velikosti). Pokud je poˇzadavek na zobrazen´ı vizualizace na web-serveru v PLC, je nutn´e zaˇskrtnou check box Web visualization, d´ale pokud je obsaˇzeno vykreslov´an´ı trend˚ u a ukl´ad´an´ı hodnot, je moˇzn´e je archivovat pˇr´ımo v PLC v pamˇeti - Store trend data in the PLC. To jsou podstatn´e konfiguraˇcn´ı kroky pˇri tvorbˇe programu do PLC. Dalˇs´ım krokem je zaloˇzen´ı programu. Ten se skl´ad´a z tzv. POU (Program Organization Unit). Podm´ınkou je alespoˇ n jeden blok POU pojmenovan´ y PLC_PRG(PRG).
48
Obr´azek 3.1: V´ yvojov´e prostˇred´ı CoDeSys 2.3.8.5
V´ ysledn´ y program se m˚ uˇze skl´adat z blok˚ u programu (PRG). Program je POU, kter´e vrac´ı nˇekolik hodnot v pr˚ ubˇehu operace. Jsou glob´alnˇe ˇrazen´e v projektu a vˇsechny z´ıskan´e hodnoty jsou z pˇredeˇsl´eho bˇehu. Lze je volat (ne vˇsak z funkc´ı). Pokud je vol´an program z jin´eho POU a jeho hodnoty se zmˇenily, zmˇeny se projev´ı aˇz pˇri dalˇs´ım vol´an´ı programu, dokonce i kdyˇz je vol´an z jin´eho POU. Tyto zmˇeny proto hraj´ı roli pouze, kdyˇz prob´ıh´a vol´an´ı stejn´e instance. Deklarace se provede kl´ıˇcov´ ym slovem PROGRAM. Dalˇs´ım POU je funˇ cn´ı blok (FB). Poskytuje jednu ˇci v´ıce hodnot v pr˚ ubˇehu operace. Oproti funkci nem´a n´avratovou hodnotu. Deklarace se provede kl´ıˇcov´ ymi slovy FUNCTION_BLOCK. Vol´an´ı se provede pomoc´ı instanc´ı. Posledn´ım POU jsou funkce (FUN), kter´e jedin´e pˇred´avaj´ı n´avratov´ y element. Ten se m˚ uˇze skl´adat z jednotliv´ ych promˇenn´ ych nebo i cel´ ych struktur. Pˇri deklaraci je nutn´e uv´est n´avratov´ y typ, dle FUNCTION ’nazev’: INT. Dialogov´e okno pro zaloˇzen´ı nov´eho bloku POU je na obr. 3.1. Je moˇzn´e vybrat z n´asleduj´ıc´ıch programovac´ıch jazyk˚ u. 49
Tabulka 3.1: Seznam programovac´ıch jazyk˚ u
IL LD FBC SFC ST CFC
Instruction List Ladder Diagram - ˇzebˇr´ıˇckov´ y diagram Function Block Diagram Sequential Function Chart Structured Text Continuous Function Chart
Programovac´ı jazyk SFC vych´az´ı z Grafcetu a je vhodn´ y pro sekvenˇcn´ı program, jak bude uk´az´ano d´ale. Jednotliv´e kroky SFC lze s v´ yhodou programovat pomoc´ı ˇzebˇr´ıˇckov´ ych diagram˚ u, kde se uˇz´ıv´a tzv. kontakt˚ u a c´ıvek. T´ım je sestaven poˇzadovan´ y logick´ y v´ yraz. Dalˇs´ı moˇznost´ı, kter´a bude uk´az´ana je jazyk ST. Jedn´a se o strukturovan´ y text a proto m˚ uˇze vzd´alenˇe pˇripom´ınat jazyk Pascal. Automat PLC pracuje v tzv. scan cyklu, kdy nejprve je zjiˇstˇen stav vstup˚ u, n´aslednˇe je vyhodnocen program a zaps´any hodnoty na v´ ystupy. Dneˇsn´ı PLC automaty toto sch´ema dodrˇzuj´ı, ale z´aroveˇ n umoˇzn ˇuj´ı definovat spuˇstˇen´ı program˚ u-task˚ u v nˇekolika reˇzimech. Z tohoto d˚ uvodu je nutn´e vytvoˇren´ y program pˇridat do seznamu spouˇstˇen´ ych. K tomu slouˇz´ı dialog Task configuration. Ten je moˇzn´e naj´ıt na z´aloˇzce Resources. Je moˇzn´e vybrat vykon´av´an´ı cyklick´e s definovanou periodou, voln´ y bˇeh (freewheeling) programu a spouˇstˇen´ı (extern´ı) ud´alost´ı (triggered by event).
Z´aroveˇ n je moˇzn´e pˇridat vykon´an´ı programu pˇri urˇcit´e ud´alosti. Tou m˚ uˇze b´ yt napˇr. start nebo zastaven´ı hlavn´ıho programu, reset kontroleru apod. Uveden´e moˇznosti jsou zobrazeny na obr. 3.2
50
Obr´azek 3.2: Task manager
3.1.1
Uk´ azkov´ y program
V t´eto kapitole budou uk´az´any moˇznosti programov´an´ı PLC s uˇzit´ım jazyka SFC, LD a ST. Uk´azkov´ y program bude kombinovat ˇr´ızen´ı a monitoring technologie pomoc´ı vizualizace pˇr´ımo na webserveru PLC. Oper´ator m´a dvˇe tlaˇc´ıtka k ovl´ad´an´ı ventilu, pro otevˇren´ı a zavˇren´ı. Logick´a hodnota log. 1 pˇredstavuje akci. Ventil se otev´ır´a 5s. D´ale jsou v technologii um´ıstˇeny dva teplomˇery (TTY 4-20mA) ke sledov´an´ı teploty tekutiny. Pˇri pˇrekroˇcen´ı nastaven´e teploty na prvn´ım teplomˇeru je automaticky spuˇstˇen ventil´ator chladiˇce. K monitorov´an´ı technologie bude sestavena vizualizace. Nejprve je nutn´e dle zad´an´ı definovat vstupy a v´ ystupy pro PLC. Zde se jedn´a o jeden logick´ y (tlaˇc´ıtko) a dva analogov´e (teplomˇery) vstupy. D´ale tˇri logick´e v´ ystupy, prvn´ı pro ovl´ad´an´ı ventilu a dva pro ovl´ad´an´ı ventil´atoru chladiˇce. 51
Obr´azek 3.3: HW konfigurace PLC
Nyn´ı jsou definovan´e glob´aln´ı promˇenn´e. Jedn´a se o vstupy (uvozen´e %I ) tlacitko open na adrese %IX2.0, tlacitko close na adrese %IX2.1, teplomer 1 na adrese %IW0 a teplomer 2 na adrese %IW1. V´ ystupy jsou ventil open na adrese %QX0.0, ventil close na adrese %QX0.1, chladic na adrese %QX0.2. Adresov´e prostory pro vstupy a v´ ystupy jsou oddˇelen´e. Zkratka %IW0 znamen´a vstupn´ı slovo (1WORD ≈ 2BYTE ≈ 16bit). Tabulka 3.2: Uk´azka adresace
WORD BYTE %IW0 %QW0
bits
%IB0, %IB1 %IX0.0 .. %IX0.15 %QB0, %QB1 %QX0.0 .. %QX0.15
Je mnoho variant ˇreˇsen´ı. V takto jednoduch´em pˇr´ıpadˇe je vcelku zbyteˇcn´e pouˇz´ıvat SFC, ale pro pˇrehlednost a vysvˇetlen´ı pojm˚ u bude pouˇzito. Z´akladn´ı kostra programu je v 52
jazyce ST. Program PLC PRG pln´ı funkci task manageru“. Cyklicky se spouˇst´ı uveden´e ” dva programy. Prvn´ı chlazen´ ı je pro ˇr´ızen´ı ventil´atoru a druh´ y ventily pro ovl´ad´an´ı ventilu. Na obr. 3.5 je v oknˇe chlazeni(PRG) z´akladn´ı kostra v jazyce SFC. • init . . . inicializace programu, pˇrepoˇcet teploty, • teplota mezA . . . pˇri pˇrekroˇcen´ı mezn´ı hodnoty teploty dojde k zapnut´ı ventil´atoru, • teplota mezB . . . pˇri poklesu teploty pod mezn´ı teplotu dojde k vypnut´ı ventil´atoru, Na obr. 3.6 je v oknˇe ventily (PRG) z´akladn´ı kostra v jazyce SFC. • init . . . inicializace programu, pˇrepoˇcet teploty, • ventil A . . . otevˇren´ı ventilu, ventil se otev´ır´a 5 s (akce d´elky 5 s). Kˇr´ıˇzek v prav´em doln´ım rohu bloku pˇredstavuje akci pˇri opuˇstˇen´ı bloku. Toho lze uˇz´ıt pro vypnut´ı servopohonu ventilu, • ventil B . . . uzavˇren´ı ventilu, ventil se uzav´ır´a 5 s (akce d´elky 5 s). Kˇr´ıˇzek v prav´em doln´ım rohu bloku pˇredstavuje akci pˇri opuˇstˇen´ı bloku. Toho lze uˇz´ıt pro zavˇren´ı servopohonu ventilu, Na obr. 3.6 je pro otevˇren´ı ventilu pouˇzit jazyk ST a pro zavˇren´ı ventilu jazyk LD. Je zde vidˇet jeho hlavn´ı charakteristika, kdy jako podm´ınka je kontakt2 tlacitko close a jako c´ıvky3 jsou ventil close.
2 3
v lev´e ˇcast´ı ˇzebˇr´ıkov´eho diagramu, vlastnost logick´e podm´ınky - napˇr. log. vstup v prav´e ˇc´ asti ˇzebˇr´ıkov´eho diagramu, vlastnost logick´e akce - napˇr. log. v´ ystup
53
Obr´azek 3.4: Z´akladn´ı struktura programu - softwarov´ y task manager
54
Obr´azek 3.5: Program pro ˇr´ızen´ı ventil´atoru chladiˇce
55
Obr´azek 3.6: Program pro ovl´ad´an´ı ventilu v kombinaci jazyk˚ u LD a ST
Ke sledov´an´ı stavu technologie m˚ uˇze slouˇzit jednoduch´a vizualizace. Tu je moˇzn´e sestavit (v z´akladn´ım oknˇe CoDeSysu karta Visualization) pomoc´ı z´akladn´ıch nab´ızen´ ych objekt˚ u. Stav bin´arn´ıch promˇenn´ ych je moˇzn´e zobrazit kontrolkami. Promˇenn´a, dle jej´ıhoˇz stavu se bude mˇenit barva, se uvede do pol´ıˇcka Change color“. Je nutn´e jeˇstˇe doupravit barvy. ” V horn´ı ˇca´sti obrazovky je zobrazov´an den v t´ ydnu, datum a aktu´aln´ı ˇcas v PLC. K´od %t%A pˇredstavuje oznaˇcen´ı pro den v t´ ydnu, %d.%m.%y je oznaˇcen´ı pro datum a %H:%M:%S pro aktu´aln´ı ˇcas. 56
Obr´azek 3.7: Vizualizace
Pro zobrazen´ı teploty je pouˇzit k´od t = %2.1f [◦ C]. Zad´a se jako text a do pol´ıˇcka textdisplay se uvede jm´eno promˇenn´e, kter´a se bude zobrazovat. Uveden´ y form´at je moˇzn´e pouˇz´ıt jen pro promˇenn´e typu REAL a znamen´a zobrazen´ı jako float typ, v ˇr´adu des´ıtek s jedn´ım desetinn´ ym m´ıstem. V tuto chv´ıli je jiˇz program ve f´azi, kdy je moˇzn´e jej nahr´at do PLC. Pˇredt´ım je jeˇstˇe vhodn´e zkompilovat cel´ y projekt kl´avesou F11. Z´aroveˇ n CoDeSys upozorn´ı, zda-li jsou nˇejak´e chyby pˇri pˇrekladu a napov´ı, jak mohly vzniknout. Pokud je projekt bez chyb, je moˇzn´e se pˇripojit k PLC a nahr´at program. K tomu je nutn´e vybrat nebo zadat jednak metodu pˇr´ıstupu (pro WAGO 750-841 pˇrich´az´ı v u ´vahu 4 RS-232 a Ethernet) a port (COMx) nebo IP adresu . Pˇripojen´ı k PLC se provede poloˇzkou v menu Online-Login. Pot´e bude program nahr´av´an do PLC. Lze pouˇz´ıt rozhran´ı RS-232 nebo Ethernet. Ten je ˇreˇsen jako emulace s´eriov´e linky na rychlosti 119kBd/s. Kdyˇz dojde k nahr´an´ı projektu, je nutn´e jeˇstˇe prov´est spuˇstˇen´ı programu v PLC. Bez toho nebude PLC plnit poˇzadovanou funkci. V pˇr´ıpadˇe, kdy dojde k v´ ypadku nap´ajen´ı PLC, jeho resetov´an´ı apod., dojde ke ztr´atˇe programu a je nutn´e PLC znovu nahr´at. Existuje varianta, kdy se program zavede do bootROM pamˇeti a pˇri restartu PLC nabootuje z tohoto programu. To se provede v menu Online-Create boot project. Z´aroveˇ n je nutn´e pˇr´ımo na PLC d´at DIP pˇrep´ınaˇc do 4
pozn. pokud je CoDeSys instalov´ an pˇri zapnut´em firewallu na lok´aln´ım PC, nebude spr´avnˇe instalov´an blok komunikaˇcn´ıch paramatr˚ u
57
bootovac´ı polohy“. ”
Obr´azek 3.8: Komunikaˇcn´ı parametry a nahr´av´an´ı projektu do PLC
K PLC je moˇzn´e se pˇripojit vzd´alenˇe pˇres internet, adresa je http://’ip_adresa’/webserv/index.ssi, vˇetˇsinou staˇc´ı zadat pouze IP adresu a automaticky se poˇzadavek pˇresmˇeruje na tuto. Ale k ochranˇe nastaven´ı PLC je moˇzn´e nastavit pˇresmˇerov´an´ı pˇr´ımo na vizualizaci http://’ip_adresa’/plc/webvisu.htm. 58
Obr´azek 3.9: webserver PLC
3.2
ControlWeb 5 SP11
ControlWeb je v´ yvojov´e prostˇred´ı od spoleˇcnosti Moravsk´e pˇr´ıstroje. Jedn´a se o otevˇren´ y komponentov´ y pr˚ umyslov´ y ˇr´ıdic´ı a informaˇcn´ı syst´em re´aln´eho ˇcasu pro operaˇcn´ı syst´emy Windows. Vytvoˇren´e aplikace je moˇzn´e nasadit i na embedded syst´emech na b´azi Windows CE. Control Web je na naˇsem trhu ˇspiˇckou v oboru.
Obr´ azek 3.10: Logo ControlWebu
59
V souˇcasnoti je k dispozici verze ControlWeb 6. Sestaven´a aplikace byla vyvinuta v ControlWebu 5 SP11. Koncepˇcnˇe vych´az´ı z osvˇedˇcen´e architektury pˇredch˚ udc˚ u ControlPanel a ControlWeb2000. Nasazen´ı tˇechto syst´em˚ u je moˇzn´e od jadern´ ych elektr´aren a celopodnikov´ ych informaˇcn´ıch syst´em˚ u pˇres tramvaje aˇz po pˇr´ım´e ˇr´ızen´ı jednotliv´ ych stroj˚ u dokazuje velmi ˇsirok´e moˇznosti tˇechto produkt˚ u. Distribuovanost, propojitelnost v poˇc´ıtaˇcov´ ych s´ıt´ıch a vestavˇen´ y HTTP server je u tohoto syst´emu i nad´ale naprostou samozˇrejmost´ı. ControlWeb m˚ uˇze pracovat stejnˇe jako jin´e SCADA/HMI syst´emy pouˇz´ıvan´ ych v pr˚ umyslu. K dispozici jsou historick´e trendy apod. Nav´ıc ale dod´av´a skuteˇcnou programovatelnost a otevˇrenou, komponentovou architekturu. Mnoˇzina virtu´aln´ıch pˇr´ıstroj˚ u nen´ı pevnˇe d´ana a zabudov´ana v syst´emu. Kaˇzd´ y pˇr´ıstroj je dynamicky linkovan´a knihovna detekovan´a pˇri startu syst´emu. Nen´ı proto probl´em mnoˇzinu virtu´aln´ıch pˇr´ıstroj˚ u libovolnˇe upravovat. Prostˇred´ı umoˇzn ˇuje pr´aci v re´aln´em ˇcase. Nespol´eh´a se na tzv. datab´azi tag˚ u, kter´a je aktualizov´ana maxim´aln´ı moˇznou rychlost´ı“(coˇz v praxi m˚ uˇze znamenat i intervaly ” nˇekolika des´ıtek sekund mezi komunikacemi s automaty pˇripojen´ ymi pˇres DDE). Kaˇzd´ y vstupnˇe/v´ ystupn´ı kan´al je ˇcten pˇresnˇe v dobˇe, kdy jej nˇejak´ y virtu´aln´ı pˇr´ıstroj (nebo skupina virtu´aln´ıch pˇr´ıstroj˚ u) poˇzaduje. Real-time ˇcasov´an´ı je pˇresnˇe monitorov´ano a ˇr´ızeno. Vizualizovat technologie je moˇzn´e i prostˇrednictv´ım standard˚ u HTTP a HTML. ControlWeb obsahuje plnohodnotn´ y HTTP server dynamicky tvoˇr´ıc´ı str´anky podle stavu technologie pracuj´ıc´ı i na starˇs´ıch operaˇcn´ıch syst´emech (napˇr. Windows 95). Nav´ıc dok´aˇze prostˇrednictv´ım HTTP a HTML technologii i ˇr´ıdit. V´ ysledn´a aplikace nez´avis´ı na pouˇzit´em hardware. Native ovladaˇce dok´aˇz´ı pracovat efektivnˇeji neˇz napˇr. DDE ovladaˇce. DDE je samozˇrejmˇe plnˇe podporov´ano spolu s OPC (OLE for Process Control) a ˇradou dalˇs´ıch standard˚ u pro pr˚ umyslov´e automaty, samostatn´e moduly a mˇeˇric´ı karty. Rozhran´ı ovladaˇc˚ u je plnˇe dokumentov´ano a otevˇreno, takˇze kaˇzd´ y si m˚ uˇze doplnit ovladaˇc podle sv´ ych potˇreb. Je zajiˇstˇena podpora nejrozˇs´ıˇrenˇejˇs´ıch pr˚ umyslov´ ych standard˚ u pro v´ ymˇenu dat a spolupr´aci mezi aplikacemi COM/OLE, ActiveX, ODBC, SQL.
3.2.1
Zaloˇ zen´ı nov´ e aplikace
Nejprve je nutn´e poznamenat, ˇze lze aplikaci vytv´aˇret v grafick´em prostˇred´ı, nebo pro zkuˇsen´e program´atory existuje i textov´a verze.
60
Pˇri prvn´ım vytv´aˇren´ı aplikace v prostˇred´ı ControlWeb je moˇzn´e vyuˇz´ıt sluˇzby pr˚ uvodce novou aplikac´ı. Prvn´ı d˚ uleˇzit´ y krok je volba mezi m´odem re´aln´eho ˇcasu a aplikac´ı ˇr´ızenou daty. V m´odu re´aln´eho ˇcasu m´a autor aplikace zcela pod kontrolou veˇsker´e ˇcasov´an´ı syst´emu. Z´akladn´ım poˇzadavkem na takov´eto aplikace je vhodn´ y n´avrh struktury, aby se na dan´em poˇc´ıtaˇci stihlo vˇse vykonat v pˇredepsan´em ˇcase. Tento m´od je vhodn´ y, pokud se budou poˇc´ıtaˇcem pˇr´ımo regulovat spojit´e soustavy, ˇr´ıdit stroje a v´ yrobn´ı linky v re´aln´em ˇcase, realizovat sloˇzitˇejˇs´ı ˇr´ıdic´ı algoritmy, simulovat, modelovat a vizualizovat re´aln´ y syst´em ve vazbˇe na re´aln´ y ˇcas. S v´ yhodou je moˇzn´e realizovat soft-PLC, probl´emem je ovˇsem mal´a odolnost v˚ uˇci nevhodnˇe zvolen´e konstrukci programu. Oproti tomu v aplikaci ˇr´ızen´e daty je ˇcinnost jednotliv´ ych komponent odvozena od zmˇen datov´ ych element˚ u, kter´ ymi jsou promˇenn´e a kan´aly. Tedy pokud nˇekter´ y virtu´aln´ı pˇr´ıstroj zmˇen´ı svou v´ ystupn´ı hodnotu, aktivuj´ı se veˇsker´e pˇr´ıstroje, kter´e tuto promˇennou ˇctou. Syst´em tuto ˇcinnost prov´ad´ı nepˇretrˇzitˇe s maxim´aln´ı rychlost´ı, je ovˇsem nemoˇzn´e tuto rychlost pˇredem stanovit. Aplikaˇcn´ı program se skl´ad´a z jednotliv´ ych virtu´aln´ıch pˇr´ıstroj˚ u, jedn´a se o samostatn´e programov´e komponenty. Tato koncepce je v´ yhodn´a pˇredevˇs´ım pro otevˇrenost. Nen´ı omezen poˇcet a typ pouˇz´ıvan´ ych pˇr´ıstroj˚ u. Aplikace je zpracov´av´ana pln´ ym nativn´ım v´ ykonem poˇc´ıtaˇce, kompilac´ı dojde k pˇrekladu na ekvivalent k´odu v jazyce C. Aplikace jsou plnˇe pˇrenositeln´e mezi platformami i verzemi syst´emu. Jednotliv´e virtu´aln´ı pˇr´ıstroje jsou propojeny hierarchickou strukturou ˇcasov´an´ı a viditelnosti (lev´ y sloupec v grafick´em v´ yvojov´em prostˇred´ı). Viditelnost urˇcuje, kde na obrazovce se bude pˇr´ısluˇsn´a komponenta zobrazovat a ˇcasov´an´ı urˇcuje, kdy a za jak´ ych podm´ınek bude pˇr´ıstroj aktivov´an. Je vhodn´e jednotliv´e pˇr´ıstroje pojmenovat unik´atn´ımi jm´eny, aby je bylo moˇzn´e volat a pˇred´avat jim hodnoty. Jako z´aklad aplikace slouˇz´ı tzv. panel. Oznaˇcovan´ y t´eˇz jako kontejner. Jedn´a se o standardn´ı okno syst´emu MS Windows, lze nav´ıc definovat kdo a jak m˚ uˇze zav´ırat okna, ˇci mˇenit jejich velikost. Do tˇechto panel˚ u se vkl´adaj´ı instance komponent. Pro vytvoˇren´ı z´akladn´ıho okna slouˇz´ı n´asleduj´ıc´ı k´od. Pokud by byla aplikace re´aln´eho ˇcasu, je z´aroveˇ n nutn´e uv´est poloˇzku timer. Prvn´ı parametr je periodicita spouˇstˇen´ı pˇr´ıstroje a druh´ y pˇredstavuje posunut´ı prvn´ıho spuˇstˇen´ı od p˚ ulnoci. Pˇrednastaven´e parametry se do k´odu nezapisuj´ı. 61
rem = ’hlavni okno aplilace’; (*poznamka*) (* timer = krok, pocatek; *) owner = background; (*kdo je vlastnikem pristroje*) position = 0, 0, 672, 570; (*x,y poloha leveho dolniho rohu, sirka, vyska panelu*) win_title = ’Popisek’; win_disable = move, zoom, minimize, maximize; (*zakazane operace s panelem*) procedure OnStartup(); (*procedura pri startu aplikace*) begin Show(); (*zobrazeni panelu*) Select(); (*vytazeni panelu na povrch*) end_procedure;
Do z´akladn´ıho panelu bude um´ıstˇen dalˇs´ı panel. Pˇri poklep´an´ı myˇs´ı bude otevˇren panel nazvan´ y panel_RH1. owner = zakladni_okno; position = 6, 9, 54, 206; mode = border_only; procedure OnMouseDown( MouseX, MouseY : longint; LeftButton, MiddleButton, RightButton : boolean ); begin panel_RH1.Show(); panel_RH1.Select(); end_procedure;
3.2.2
Datov´ e elementy, ovladaˇ ce a parametrick´ e soubory
Pˇr´ıstroje si mus´ı vymˇen ˇovat data. K tomu slouˇz´ı glob´aln´ı a lok´aln´ı datov´e elementy, • glob´aln´ı ... pouˇziteln´e v cel´em aplikaˇcn´ım programu, pro pˇrenos a sd´ılen´ı dat, • lok´aln´ı ... pˇr´ısluˇs´ı jednomu virtu´aln´ımu pˇr´ıstroji, existuj´ı lok´aln´ı konstanty (nemˇenn´e), promˇenn´e (nastavov´any na inicializaˇcn´ı hodnotu) a statick´e promˇenn´e (uchov´avaj´ı aktu´aln´ı hodnotu). Z hlediska zp˚ usobu pouˇz´ıv´an´ı jsou rozliˇseny tˇri z´akladn´ı druhy datov´ ych element˚ u, • konstanty ... obsahuj´ı inicializaˇcn´ı hodnotu, • promˇenn´e ... uchov´an´ı dat, kter´e se mˇen´ı v pr˚ ubˇehu bˇehu aplikace, glob´aln´ı/lok´aln´ı, • kan´aly ... pro pˇrenos dat mezi aplikaˇcn´ım programem a vstupnˇe/v´ ystupn´ımi zaˇr´ızen´ımi, nutn´e ovladaˇce kan´al˚ u, kter´e zajiˇst’uj´ı automatick´ y pˇrenos – vstupn´ı ... z pohledu CW je moˇzn´e pouze ˇc´ıst, – v´ ystupn´ı ... lze ˇc´ıst i zapisovat, ˇcten´a hodnota je vˇsak hodnotou naposledy zapsanou, – obousmˇern´e ... ˇcteny/zapisov´any, ˇcten´ı je provedeno pˇr´ımo ze zaˇr´ızen´ı, 62
Kan´aly vzhledem k vazbˇe na ovladaˇce mohou b´ yt pouze glob´aln´ı. Ovladaˇce jsou totiˇz tak´e glob´aln´ı.
Obr´azek 3.11: Spr´ava datov´ ych element˚ u a kan´al˚ u
Ovladaˇc je programov´a komponenta, kter´a spojuje aplikaci5 sestavenou v prostˇred´ı ControlWeb s konkr´etn´ım zaˇr´ızen´ım. Ovladaˇc dost´av´a poˇzadavky na ˇcten´ı nebo z´apis dat prostˇrednictv´ım kan´al˚ u. Cel´ y mechanismus v´ ymˇeny dat prob´ıh´a dle obr´azku vlevo. J´adro syst´emu informuje ovladaˇc, ˇze dle programu je nutn´e pˇreˇc´ıst urˇcit´ yu ´daj z kan´alu. Ovladaˇc sestav´ı poˇzadavek odpov´ıdaj´ıc´ı komunikaˇcn´ımu protokolu pro pˇr´ısluˇsn´e zaˇr´ızen´ı a odeˇsle poˇzadavek do zaˇr´ızen´ı. To odpov´ı na poˇzadavek a poˇsle ovladaˇci odpovˇed’ v definovan´em form´atu. Ten dek´oduje zpr´avu a z´ısk´a pˇr´ısluˇsn´ y dotazovan´ y u ´daj. J´adro je informov´ano, ˇze je k dispozici poˇzadovan´ yu ´daj. Tato hodnota je pˇriˇrazena do kan´alu a dle k´odu je hodnota dopoˇc´ıt´ana.
5
m˚ uˇze vyuˇz´ıvat sluˇzeb neomezen´eho poˇctu ovladaˇc˚ u souˇcasnˇe
63
Parametrick´e soubory *.par slouˇz´ı k definici ˇcinnosti ovladaˇc˚ u. Jejich struktura nen´ı pˇredeps´ana a z´aleˇz´ı jen na typu ovladaˇce. Zpravidla b´ yvaj´ı textov´e a lze je libovolnˇe editovat. D˚ uleˇzit´a pozn´amka se t´ yk´a pouˇz´ıv´an´ı tabul´atoru. Pˇri jeho pouˇzit´ı dojde k chybˇe pˇrekladu aplikace. Parametrick´e soubory by mˇely obsahovat • nastaven´ı komunikace s vstupnˇe/v´ ystupn´ım zaˇr´ızen´ım, • mapov´an´ı kan´al˚ u do pamˇeti vstupnˇe/v´ ystupn´ıho zaˇr´ızen´ı, • dalˇs´ı informace ovlivˇ nuj´ıc´ı funkˇcnost ovladaˇce. Mapovac´ı soubory *.dmf ukl´adaj´ı informace o typech a smˇerech vˇsech kan´al˚ u, ketr´e jsou spojeny s dan´ ym ovladaˇcem. Jsou vˇzdy textov´e. Pro spr´avnou funkci a pouˇz´ıv´an´ı kan´al˚ u jsou potˇreba ovladaˇc ’nazev’.dll, mapovac´ı soubor ’nazev’.dmf a parametrick´ y soubor ’nazev’.par.
3.2.3
Uˇ zivatelsk´ a pr´ ava
Vytvoˇren´e aplikace ˇcasto slouˇz´ı pro ˇr´ızen´ı sloˇzit´ ych technologi´ı. Proto je vhodn´e vytvoˇrit autorizovan´ y pˇr´ıstup k technologii a v´est evidenci osob pracuj´ıc´ıch se zaˇr´ızen´ım. K dispozici je n´apovˇeda, jak vytvoˇrit uˇzivatelsk´e skupiny a v tˇechto skupin´ach potom vytv´aˇret pˇr´ımo jednotliv´e uˇzivatele. Hlavn´ı spr´avce syst´emu oznaˇcovan´ y jako root m´a ID 0 a nepˇrihl´aˇsen´ y uˇzivatel none m´a ID 2^32 ~ 4294967296. To je moˇzn´e zjistit z obr. 3.12. Povolen´ı pˇr´ıstupov´ ych pr´av je moˇzn´e nˇekolika zp˚ usoby. V datov´ ych inspektorech, nebo jednoduˇsˇs´ı zp˚ usob je vyuˇz´ıt pr˚ uvodce. Nen´ı-li dosud stanoveno heslo spr´avce, pr˚ uvodce upozorn´ı na tuto skuteˇcnost a umoˇzn´ı jeho zad´an´ı. Poprv´e toto heslo m˚ uˇze zadat kdokoliv. Pˇrid´avat uˇzivatele m˚ uˇze jen spr´avce. Uˇzivatel je definov´an pˇr´ıstupov´ ym jm´enem a heslem, d´ale lze uˇzivatele seskupovat do skupin. To je v´ yhodn´e, protoˇze se m˚ uˇze u stroje stˇr´ıdat pˇri smˇenn´em provozu v´ıce lid´ı se stejn´ ym opr´avnˇen´ım a je vhodn´e rozliˇsit, kdo v danou chv´ıli na stroji pracoval. Pro lepˇs´ı orientaci je moˇzn´e zad´avat i cel´e jm´eno a dalˇs´ı vlastnosti.
64
Obr´azek 3.12: Uˇzivatelsk´e u ´ˇcty
Aby bylo moˇzn´e pracovat s uˇzivatelsk´ ymi jm´eny pˇr´ımo v aplikaci, je sestaven´ y program program_uzivatele, kter´ y pˇr´ımo ˇcte syst´emovou promˇennou a ukl´ad´a do glob´aln´ı promˇenn´e uzivatel pˇrihlaˇsovac´ı jm´eno pr´avˇe pˇrihl´aˇsen´eho uˇzivatele. Tuto promˇennou lze zobrazovat pˇr´ımo v komponentˇe string_display. owner = ovladani; position = 66, 88, 57, 20; procedure OnActivate(); var UserLevel : longcard; UserLogin : string; UserFull : string; begin system.GetActualUser( UserLevel, UserLogin, UserFull ); if UserLogin = ’root’ then uzivatel = ’root’; elsif UserLogin = ’technolog’ then uzivatel = ’technolog’; elsif UserLogin = ’servis’ then uzivatel = ’servis’; elsif UserLogin = ’user’ then uzivatel = ’user’; elsif UserLogin = ’none’ then uzivatel = ’none’; end; (*hhh*) end_procedure;
65
3.2.4
Pˇ reklad a generov´ an´ı aplikace
V prostˇred´ı ControlWeb lze vyuˇz´ıt k tvorbˇe aplikace grafick´e n´astroje, nebo textov´e programov´an´ı. Oba zp˚ usoby jsou oznaˇcov´any jako dvojcestn´e programov´an´ı. Kaˇzdou aplikaci lze vytv´aˇret dle aktu´aln´ıho poˇzadavku bud’ graficky nebo textovˇe. Pˇrechod mezi reˇzimy se naz´ yv´a pˇrekl´apˇen´ı. Textov´a i grafick´a podoba aplikace je navz´ajem z´astupn´a. Bylo nutn´e zvolit jednu pro ukl´ad´an´ı a z´alohov´an´ı. Vybr´ana byla textov´a podoba, protoˇze je moˇzn´e ji otevˇr´ıt v textov´em editoru a pˇredstavuje snazˇs´ı manipulaci. Dalˇs´ım nem´enˇe d˚ uleˇzit´ ym hlediskem je v pˇr´ıpadˇe poruchy archivn´ıho m´edia moˇznost obnovit alespoˇ n ˇc´ast k´odu. Pˇrechody mezi reˇzimy se oznaˇcuj´ı pˇreklad (z textov´e do grafick´e) a generov´an´ı (z grafick´e do textov´e). Pˇ reklad kontroluje form´aln´ı spr´avnost textu a podle nˇej vytv´aˇr´ı bin´arn´ı podobu aplikace. Existuj´ı tˇri druhy pˇreklad˚ u. Pˇ reklad po ˇ c´ astech, t´eˇz oznaˇcovan´ y jako inkrement´aln´ı pˇreklad. ControlWeb pˇrekl´ad´a aplikaci po jednotliv´ ych ˇc´astech - komponent´ach. Pokud se vyskytne chyba, po jej´ım opraven´ı se bude pokraˇcovat v pˇrekladu od m´ısta, kter´e skonˇcilo pˇrekladem ˇr´adnˇe bez chyby. Jednoduch´ y pˇ reklad je nejrychlejˇs´ı, kontroluje se pouze syntaktick´a spr´avnost aplikace. Tedy vˇsechny tˇr´ıdy pˇr´ıstroj˚ u exituj´ı a syst´em zn´a knihovny, v´ yrazy obsahuj´ı zn´am´e funkce a datov´e elementy maj´ı korektn´ı inicializaˇcn´ı hodnoty. Ale nezav´ad´ı ovladaˇce a nepˇrekl´ad´a vzd´alen´e moduly. Pˇ reklad pro pˇ reklopen´ı mus´ı zajistit kontrolu datov´ ych soubor˚ u (zda se daj´ı naˇc´ıst) a zav´est do pamˇeti. Tento pˇreklad se uˇz´ıv´a pˇri pˇrechodu z textov´eho do grafick´eho reˇzimu. Pˇ reklad pro spuˇ stˇ en´ı kontroluje kompletn´ı aplikaci, syntaktickou i s´emantickou str´anku. Prov´ad´ı se vˇzdy, pˇri poˇzadavku na spuˇstˇen´ı aplikace. Generov´ an´ı prov´ad´ı pˇrevod z grafick´e formy na textovou. V´ ysledn´ y generovan´ y text neb´ yv´a identick´ y s t´ım pˇred pˇreklopen´ım. Je to d´ano optimalizac´ı pˇri generov´an´ı. Pˇredevˇs´ım se ponech´av´a v textu jen k´od, kter´ y se liˇs´ı od pˇrednastaven´eho. Prob´ıh´a standardn´ı form´atov´an´ı. Z´aroveˇ n je zajiˇstˇena zpˇetn´a kompatibilita s pˇredchoz´ımi generacemi syst´emu (ControlPanel). Koment´aˇre je nutn´e uvodit kl´ıˇcov´ ym slovem rem = ’text’. Jinak bude pˇri pˇreklopen´ı ztracen.
3.2.5
Datovˇ eˇ r´ızen´ e aplikace
Takto vytvoˇren´e aplikace vyˇzaduj´ı pouze minim´aln´ı znalost vizualizovan´e technologie. Aplikace se o v´ ymˇenu dat mezi poˇc´ıtaˇcem a technologi´ı star´a sama a optimalizuje tak datov´ y tok a rychlost odezvy vizualizace. Program´ator tak z´ısk´av´a maxim´aln´ı zjednoduˇsen´ı. To je ovˇsem vykoupeno nemoˇznost´ı ˇcasov´an´ı kan´al˚ u a pˇr´ıstroj˚ u, nen´ı vazba na re´aln´ y ˇcas a t´ım nemoˇznost m´ıt plnou kontrolu nad n´aroˇcnou technologii. Doporuˇcuje se vyuˇz´ıt tento typ aplikace v pˇr´ıpadech, kdy je poˇzadavek archivace a vizualizace bez potˇreby ˇr´ıdit ˇcasov´an´ı dˇej˚ u. D´ale napˇr. vizualizace pomal´ ych dˇej˚ u“. ” Aplikace pracuje v z´avislosti na mnoˇzstv´ı komunikovan´ ych dat, cel´ y bˇeh je ˇr´ızen 66
j´adrem. To optimalizuje rychlost komunikace dle jejich mnoˇzstv´ı a z´aroveˇ n spouˇst´ı z´avisl´e pˇr´ıstroje, jejichˇz obsah je d´an daty z´ıskan´ ymi z kan´alu. J´adro pracuje cyklicky, v kaˇzd´em kroku zmˇeˇr´ı potˇrebn´a data, vyhodnot´ı v´ ysledky, aktivuje pˇr´ıstroje a zap´ıˇse patˇriˇcn´e v´ ysledky zpˇet do technologie. Aplikace vnitˇrnˇe definuje umˇel´e zdrˇzen´ı mezi jednotliv´ ymi kroky j´adra, aby byl zajiˇstˇen chod aplikace a zbytku operaˇcn´ıho syst´emu. Pro verzi ControlWeb 2000 byla s ohledem na OS Windows 2000 a dostupn´ y hardware doba zdrˇzen´ı 5 ms. Tato doba odpov´ıd´a dvˇema st˚ um operac´ı za sekundu. D´elka kroku j´adra b´ yv´a r˚ uzn´a, z´avis´ı na d´elce komunikac´ı. Kaˇzd´ y krok dokonˇc´ı sv´e komunikace a teprve pot´e se spouˇst´ı pˇr´ıstroje. J´adro neprov´ad´ı kroky, pokud to nen´ı vyˇzadov´ano. Komunikace kan´al˚ u prob´ıh´a automaticky. Syst´em zajist´ı vhodnou periodicitu obnovov´an´ı dat, jejich bezpeˇcn´e odmˇeˇren´ı a podle zmˇeny hodnot i aktivaci pˇr´ıstroj˚ u, kter´e kan´aly pouˇz´ıvaj´ı. Z principu se j´adro snaˇz´ı z´ısk´avat data z kan´al˚ u co nejˇcastˇeji. To znamen´a, maxim´aln´ı rychlost´ı kterou dovol´ı komunikace a bˇeh pˇr´ıstroj˚ u. Nˇekter´e aplikace nepotˇrebuj´ı mˇeˇrit rychlostmi v ˇr´adech milisekund. Proto kan´aly obsahuj´ı parametr s doporuˇcenou periodou mˇeˇren´ı kan´alu. Anal´ yzou tˇechto dob m˚ uˇze doj´ıt k znaˇcn´emu zv´ yˇsen´ı zefektivnˇen´ı bˇehu v´ ysledn´e aplikace. V´ ystupn´ı kan´aly nen´ı tˇreba specialnˇe oˇsetˇrovat. Staˇc´ı zapsat jejich novou hodnotu a o vˇse ostatn´ı se staraj´ı ovladaˇce pˇr´ısluˇsn´ ych kan´al˚ u. 3.2.5.1
Rozbˇ eh a zastaven´ı aplikace
Je nutn´e zajistit, aby pˇri rozbˇehu byly vˇzdy stejn´e podm´ınky. Mechanismus rozbˇehu zahrnuje inicializaci v´ ystupn´ıch kan´al˚ u. T´ım se zajist´ı shodnost dat mezi aplikac´ı a technologi´ı. D´ale inicializace pˇr´ıstroj˚ u, nastaven´ı poˇc´ateˇcn´ıch hodnot pˇr´ıstroj˚ um, obnoven´ı dat ze z´aloh pˇr´ıstroj˚ u backup a proveden´ı prvn´ı komunikace, kter´a pˇrenese pˇripraven´a data do technologie. N´aslednˇe jsou spuˇstˇeny pˇr´ıstroje. Je moˇzn´e tak´e pouˇz´ıt pˇr´ıstroj startup. Ten zajist´ı spuˇstˇen´ı j´adra jako prvn´ı pˇred ostatn´ımi pˇr´ıstroji. Zastaven´ı aplikace je jednoduˇsˇs´ı, lze povolit pouˇzit´ı standardn´ıho zav´ırac´ıho kˇr´ıˇzku v prostˇrd´ı MS Windows, nebo doplnit do aplikace tlaˇc´ıtko s n´asleduj´ıc´ım k´odem. owner = ovladani; (*vzdy musi byt vyplnen vlastnik pristroje*) position = 5, 532, 118, 26; win_disable = zoom, maximize; (*urcuje jake operace budou zakazany s pristrojem*) mode = text_button; (*jak bude pristroj vypadat*) font = ’Arial (Central European)’, 10, normal; true_text = ’Konec’; false_text = ’Konec’; logic = set_true_on_press; (*jakou bude pristoj vykonavat logickou funkci*) procedure OnMouseDown( MouseX, MouseY : longint; LeftButton, MiddleButton, RightButton : boolean ); begin core.StopApplication(); (*samotny prikaz pro zastaveni chodu aplikace*) end_procedure;
Aplikace m˚ uˇze obsahovat pˇr´ıstroj terminate. Je nepovinn´ y, aktivov´an pˇri zastaven´ı aplikace. Mohou v nˇem b´ yt obsaˇzeny akce pro bezpeˇcn´e zastaven´ı, nebo nov´ y start aplikace v budoucnu. Pˇr´ıkladem je ruˇsen´ı doˇcasn´ ych soubor˚ u ˇci tvorba z´aloh. Pˇr´ıstroj m˚ uˇze bˇeˇzet 67
libovolnou dobu, z´aroveˇ n prob´ıh´a komunikace i aktivov´an´ı ostatn´ıch pˇr´ıstroj˚ u. Pˇri dobˇehu pˇr´ıstroje terminate se aplikace ukonˇc´ı. 3.2.5.2
Periodick´ eˇ casov´ an´ı
Pˇri vizualizaci v aplikaci ˇr´ızen´e daty je tak´e uvaˇzovat periodick´e ˇcasov´an´ı. Vyˇzaduje to tvorba graf˚ u z namˇeˇren´ ych dat ˇci archivace dat. Existuj´ı tˇri z´akladn´ı zp˚ usoby. • Relativn´ı (jednoduch´ a)perioda - j´adro aktivuje pˇr´ıstroj nejdˇr´ıve po uplynut´ı definovan´e periody, ta je v´az´ana ke startu aplikace. • Absolutn´ı perioda (s posunut´ım) - perioda je urˇcena ˇcasov´ ym posunem v˚ uˇci re´aln´emu ˇcasu. Aktivace probˇehne v momentˇe souˇctu posunut´ı a celistv´eho n´asobku periody poˇc´ıtan´e od p˚ ulnoci ˇ • Casovaˇ c - CW obsahuje pˇristroje, kter´e vlastn´ı aktivaci ˇs´ıˇr´ı na ostatn´ı a t´ım je ˇcasuj´ı. Sequencer zajiˇst’uje aktivaci dle urˇcit´e posloupnosti, selector aktivuje na z´akladˇe vyhodnocen´ı urˇcit´e podm´ınky, iterator prov´ad´ı aktivaci cyklicky.
68
Kapitola 4 Program pro PLC WAGO 4.1
ˇ ıdic´ı syst´ R´ em rozvadˇ eˇ c˚ u ATS1000 a ATS200
K sestaven´ı koneˇcn´e verze programov´eho vybaven´ı pro PLC automat WAGO byl pouˇzit produkt spoleˇcnosti 3S-software GmbH (Smart Software Solution) nazvan´ y CoDeSys ve verzi 2.3.8.5 (build Oct 5 2007). Program je sestaven jako multitaskov´ y. CoDeSys umoˇzn ˇuje nastavit spouˇstˇen´ı podprogram˚ u pomoc´ı menu - karta Resources-Task configuration. Lze volit mezi: • • •
cyclic cyklick´e vykon´av´an´ı tasku s definovanou periodou freewheeling volnˇe bˇeˇz´ıc´ı task, pro technologie bez nutnosti re´aln´eho ˇcasu triggered by event spouˇstˇen´ı vnˇejˇs´ı ud´alost´ı
Uvedenou moˇznost spouˇstˇen´ı task˚ u nebylo moˇzn´e pouˇz´ıt. Pˇri pˇrep´ın´an´ı mezi jednotliv´ ymi u ´lohami doch´azelo k chyb´am. Proto byla u ´spˇeˇsnˇe vyzkouˇsena varianta, kdy v hlavn´ım programu PLC PRG(PRG) jsou vol´any jednotliv´e programy. Je tak zajiˇstˇeno cyklick´e vykon´av´an´ı program˚ u. Uveden´e podprogramy ˇreˇs´ı jednotliv´e operace mezi nimiˇz je pˇrepoˇcet poˇctu vzork˚ u z analogov´ ych mˇeˇriˇc˚ u proudu na v´ yslednou hodnotu, inicializace SNMP TRAP zpr´av pro zmˇeny stavu bin´arn´ıch vstup˚ u, inicializace zpr´av z datab´aze MIB, komunikace po datov´e lince RS-485 s uˇzit´ım protokolu MODBUS RTU, ˇr´ızen´ı v´ ykonov´eho pˇrep´ınaˇce SOCOMEC 1250A v rozvadˇeˇci ATS1000, ovl´ad´an´ı motorgener´ator˚ u (start), ˇr´ızen´ı v´ ykonov´eho pˇrep´ınaˇce SOCOMEC 250A v rozvadˇeˇci ATS200, ovl´ad´an´ı a ˇr´ızen´ı testu bez z´atˇeˇze a testu se z´atˇeˇz´ı. D´ale jsou sestaveny funkˇcn´ı bloky pro pˇrepnut´ı kontakt˚ u u v´ ykonov´ ych pˇrep´ınaˇc˚ u. Jedn´a se o rutiny, kter´e jsou vˇzdy stejn´e a jejich struktura jako funkˇcn´ı blok je v´ yhodn´a pro pouˇzit´ı v ostatn´ıch programech. Pro datovou komunikaci po RS-485 jsou sestaveny strukturovan´e datov´e prvky pro f´azov´a a sdruˇzen´a napˇet´ı, proudy, v´ ykony (ˇcinn´ y, jalov´ y, zd´anliv´ y) a u ´ˇcin´ık. Mˇeˇren´ı prob´ıh´a na tˇr´ıf´azov´e s´ıti, proto objekty mus´ı b´ yt strukturovan´e a jejich poloˇzky jsou pr´avˇe jednotliv´e vlastnosti s´ıtˇe ve f´az´ıch. 69
TYPE ’datovy typ’: STRUCT f1 : [WORD, INT]; f2 : [WORD, INT]; f3 : [WORD, INT]; END_STRUCT END_TYPE
Objekt pro uchov´an´ı informac´ı o motorgener´atoru vypad´a n´asledovnˇe. TYPE zarizeni : STRUCT proudy : proudy_fazove; sdruzena_napeti : napeti_sdruzena; fazova_napeti : napeti_fazova; frekvence : WORD; cinny_vykon : vykon_cinny; jalovy_vykon : vykon_jalovy; zdanlivy_vykon : vykon_zdanlivy; ucinik : power_factor; total_kW : WORD; total_kVAr : WORD; total_kVA : WORD; total_PF : WORD; tlak_oleje : WORD; teplota_oleje : WORD; teplota_chlazeni : WORD; otacky_stroje : WORD; napeti_baterky : WORD; spotreba : WORD; teplota_okoli : WORD; ECM_baterka : WORD; pocet_startu : WORD; pocet_hodin : WORD; aktualni_den : WORD; aktualni_den_2 : STRING; aktualni_mesic : WORD; aktualni_rok : WORD; aktualni_hodina : WORD; aktualni_minuta : WORD; palivo : WORD; END_STRUCT END_TYPE
Aby bylo moˇzn´e k tˇemto u ´daj˚ um pˇristupovat i z panelov´eho PC s prostˇred´ım ControlWeb, je kaˇzd´emu zaˇr´ızen´ı pˇriˇrazena poˇc´ateˇcn´ı adresa v pamˇeti, od kter´e se zaˇc´ınaj´ı ukl´adat naˇcten´e hodnoty. Objekt zarizeni zab´ır´a vˇzdy 48 WORD˚ u, ale vyuˇz´ıvaj´ı se pouze nˇekter´e. diris AT %MW200 : zarizeni; (*pouzito 23xWORD*) kohler AT %MW250 : zarizeni; (*pouzito 38xWORD*) lovato_DMK AT %MW300 : zarizeni; (*pouzito 23xWORD*) lovato_RGK AT %MW350 : zarizeni; (*pouzito 30xWORD*)
4.1.1
Program analogy
Hodnota proud˚ u ve f´az´ıch prim´arn´ı s´ıtˇe je sn´ım´ana proudov´ ymi mˇeˇriˇci, kvantov´ana a vzorkov´ana. V´ yslednou ˇc´ıselnou reprezentaci je nutn´e pˇrepoˇc´ıtat pomoc´ı linearizaˇcn´ı kˇrivky na skuteˇcnou hodnotu proudu. K tomu slouˇz´ı uveden´ y program. 70
PROGRAM analogy VAR chyba_PSU : BOOL; proud_L1 : REAL; proud_L1_k : REAL := 1.0E-4; proud_L1_q : REAL := -3.1402E-16; -----------------------------------------(*====== vypocet hodnoty dle linearizacni krivky ’y = k*x + q’ (y - hodnota, x - namerene vzorky z D/A) ==== *) proud_L1 := (proud_L1_k*%IW0 + proud_L1_q); (*_proud_L1 = %IW0*) IF analogy.psu < 20 THEN (*hlidani poruchy nabijecky*) chyba_PSU := TRUE; ELSE chyba_PSU := FALSE; END_IF; END_VAR
%REGRESE...funkce pro MATLAB% % function [k, q] = regrese (x,y) % funkce vypocita linearni regresi ze zadanych vektoru X a Y dle y = kx + q % % INPUT: % x ... vektor hodnot osy X % y ... vektor funkcnich hodnot (osa y) % OUTPUT: % k ... smernice primky % q ... posunuti primky % TESTOVACI DATA: % x = [1 2 4 5]; % y = [5.5 4 2 1.5]; function [k,q] = regrese(x,y) x = x; y = y; delkaX = length(x); delkaY = length(y); if delkaX ~= delkaY disp(sprintf(’velikost vektoru X je %d a vektoru Y je %d’,delkaX, delkaY)); end soustava(1) = delkaX; soustava(2) = sum(x); soustava(3) = sum(x); soustava(4) = sum(x(:).^2); soustava(5) = sum(y); soustava(6) = sum(x(:).*y(:)); soustavaA = [soustava(1), soustava(2);... soustava(3), soustava(4)]; soustavaB = [soustava(5);... soustava(6)]; koeficienty = soustavaA \ soustavaB; k = koeficienty(2); q = koeficienty(1); end
Konstanty linearizaˇcn´ı funkce jsou vypoˇcten´e pro st´avaj´ıc´ı analogovou kartu v PLC, v pˇr´ıpadˇe v´ ymˇeny senzoru nebo karty je moˇzn´e konstanty zmˇenit. Jejich v´ ypoˇcet lze prov´est pomoc´ı line´arn´ı regresn´ı funkce. V´ yˇse je uvedena funkce v MATLABu pro v´ ypoˇcet konstant line´arn´ı regresn´ı funkce.
4.1.2
Program init SNMP
Uveden´ y program slouˇz´ı pro definici SNMP TRAP zpr´av. Ty se nejprve sestav´ı z parametru a textu, pot´e prob´ıh´a inicializace fronty. SNMP TRAPy jsou pos´ıl´any z´aroveˇ n s jejich hod71
notou v pˇr´ıpadˇe, ˇze dojde ke zmˇenˇe logick´eho stavu dan´e logick´e promˇenn´e odpov´ıdaj´ıc´ı vstupu PLC1 . PROGRAM init_SNMP VAR k : INT; (*index cyklu FOR (vynulovani FRONTY pri startu aplikace)*) END_VAR -------------------------------------------------------------------------(*definice parametru a textu*) (* aaa_bbb_ccc_ddd aaa ... zakaznik bbb ... lokalita ccc ... rozvadec, nebo urcita skupina celku ddd ... logicky signal*) Init_Variables[1].parametr:=1; ... (*inicializace fronty*) FOR k:= 0 TO 500 DO traps_to_send[k].VALUE := 0; END_FOR;
4.1.3
Init_Variables[1].text:= ’aaa_bbb_ccc_ddd’;
Program komunikace MIB
Program zajiˇst’uje poskytov´an´ı analogov´ ych informac´ı o technologii. Je vytvoˇrena mnoˇzina analogov´ ych hodnot, kter´e je moˇzn´e pomoc´ı protokolu SNMP a tabulky MIB vzd´alenˇe vyˇc´ıtat. Tuto funkci zpˇr´ıstupˇ nuje aˇz posledn´ı firmware PLC verze 14, kter´a podporuje tabulky MIB. Z´aroveˇ n je k dispozici knihovna do prostˇred´ı CoDeSys, kter´a zajiˇst’uje rozhran´ı pro vzd´alen´ y pˇr´ıstup. Jedn´a se o funkci SNMP_SET_PLCDATA_WRITEAREA(writeArea_index, writeArea_Value); PROGRAM komunikace_MIB VAR (*********************SNMP MIB - write area*************************) writeArea_Value : DWORD; (*posilana hodnota*) writeArea_index : BYTE:= 1; (*index zpravy*) writeArea_wasSend : BOOL; (*posilani se zdarilo*) END_VAR -------------------------------------------------------------------------FOR writeArea_index :=1 TO 255 BY 1 DO IF (writeArea_index = 1) THEN writeArea_Value:= REAL_TO_DWORD(analogy.proud_L1); ...; ELSIF (writeArea_index = 7) THEN writeArea_Value:= diris_A.fazova_napeti.f1; ...; ELSIF (writeArea_index = 27) THEN writeArea_Value:= kohler.fazova_napeti.f1; ...; ELSIF (writeArea_index = 64) THEN writeArea_Value:= lovato_RGK.fazova_napeti.f1; ...; ELSIF (writeArea_index = 92) THEN writeArea_Value:= lovato_DMK.fazova_napeti.f1; END_IF; SNMP_SET_PLCDATA_WRITEAREA(writeArea_index, writeArea_Value); END_FOR; 1
SNMP TRAP zpr´ avy pos´ıl´ any asynchronnˇe, viz...kapitola[2.1.1]
72
4.1.4
Program komunikace ModBus
Uveden´ y program slouˇz´ı pro pˇrepoˇcet hodnot z ControlWebu na pouˇziteln´ y form´at pro PLC. Jedn´a se pˇredevˇs´ım o zad´av´an´ı hodnot ˇcas˚ u z ControlWebu, kdy je potˇreba kv˚ uli ˇcasovaˇc˚ um v PLC pˇrev´est u ´daj z [s] na [ms]. D´ale je zde zpracov´ana adresa SNMP serveru. Z CW se pˇren´aˇs´ı jako ˇctyˇri ˇc´ısla v rozsahu 0-255 a zde jsou ˇc´ısla pˇrevedena na form´at STRING a operac´ı skl´ad´an´ı STRING ˇretˇezc˚ u CONCAT sloˇzena cel´a IP adresa SNMP serveru. PROGRAM komunikace_ModBus VAR END_VAR -----------------------------------------------------(*prevedeni konstant zadanych v ControlWebu na hodnoty casu*) IF CW_T1 = 0 THEN (*pripad, kdy WAGO startuje a CW nedava cyklicky hodnoty na vystup*) CW_T1 := 10; ...; END_IF; IF CW_SNMP_1a = 0 THEN CW_SNMP_1a := 123; CW_SNMP_1b := 456; CW_SNMP_1c := 789; CW_SNMP_1d := 123; END_IF; T1 := DWORD_TO_TIME(CW_T1 * 1000); ...; ipconfig := CONCAT(CONCAT(CONCAT(CONCAT(CONCAT(CONCAT( WORD_TO_STRING(CW_SNMP_1a) , ’.’ ), WORD_TO_STRING(CW_SNMP_1b)) , ’.’), WORD_TO_STRING(CW_SNMP_1c)) , ’.’) , WORD_TO_STRING(CW_SNMP_1d)) ;
4.1.5
Program komunikace RS485
Program zajiˇst’uje cyklick´e vyˇc´ıt´an´ı informac´ı ze zaˇr´ızen´ı pˇripojen´ ych na lince RS-485. Jako protokol je pouˇzit MODBUS RTU, kdy jednotka master je PLC a pˇripojen´a zaˇr´ızen´ı jsou jednotkami slave. Pro spr´avnou funkci je nutn´e pˇridat knihovny Ethernet.lib, mod_com.lib, WagoLibEthernet_01.lib, Modb_l05.lib, SerComm.lib a serial_interface_01.lib. Pro zajiˇstˇen´ı cyklick´eho vyˇc´ıt´an´ı zaˇr´ızen´ı je sestavena kombinace gener´ator-puls˚ u (uˇzit´ı komponenty BLINK) a ˇradiˇce moduloX (komponenta COUNTER UP). (*Komponenta BLINK - generator pulsu*) casovani_RS485(ENABLE:= TRUE, TIMELOW:= T#0.5s, TIMEHIGH:=T#0.5s);
Gener´ator puls˚ u je pouˇzit pro ˇcasov´an´ı ˇradiˇce, kter´ y inkrementuje svou hodnotu. Podle poˇctu vyˇc´ıtan´ ych zaˇr´ızen´ı je urˇcen parametr X ˇradiˇce. (*Komponenta CTU - citac modulo*) radic_RS485(CU:=casovani_RS485.OUT, RESET:=radic_RESET, PV:=radic_PV); radic_RESET := radic_RS485.Q; radic_CV := radic_RS485.CV;
Samotn´e vyˇc´ıt´an´ı a zpracov´an´ı naˇcten´ ych u ´daj˚ u prob´ıh´a n´asledovnˇe. V momentˇe, ˇze je v ˇradiˇci poˇzadovan´a hodnota a gener´ator m´a aktivn´ı puls, pˇred´a se pˇr´ısluˇsn´a adresa a 73
d´elka vyˇc´ıtan´ ych dat a provede se vyˇcten´ı, zpracov´an´ı u ´daj˚ u. V neaktivn´ı p˚ ulperiodˇe je vyˇck´av´an´ı a ukl´ad´an´ı.
(*Zarizeni na RS485 na ModBus adrese 5 - DIRIS *) IF radic_CV = 0 THEN zarizeni_A :=’DIRIS_1@1’; adresa_Slave := 5; adrese_v_zarizeni_slave := 768; pocet_prenasenych_dat := 22; start_RS485 := TRUE; diris_A.proudy.f1 ELSIF casovani_RS485.OUT = FALSE THEN start_RS485 := FALSE; END_IF;
:= ((prijata_data.Data[5] * 256 + prijata_data.Data[6])/100);
Nastaven´ı parametr˚ u se provede n´asledovnˇe.
PROGRAM komunikace_RS485 VAR casovani_RS485 : BLINK; (*definice generatoru pulsu BLINK*) radic_RS485 : CTU; (*definice citace CTU*) ModBus_Master : MODBUSMASTER_RTU; (*komunikace po kanale MODBUS*) (*kruhovy radic RS485 realizovany jako citac modulo 8*) radic_RESET : BOOL; radic_PV : WORD := 9; (*prednastavena hodnota - pocet zarizeni na sbernici*) radic_CV : WORD; (*aktualni hodnota*) (*RS485 - komunikace po kanale MODBUS*) adresa_Slave : BYTE; (*adresa Slave zarizeni, typ BYTE, standardne 5, jinak nastavit*) kod_funkce : BYTE; (*kod pozadovane funkce - 3~ReadHoldingRegister, 5~ForceSingleCoil*) pocatecni_adresa_pameti : WORD; (*pocatecni adresa v zarizeni Slave od niz se cte/zepisuje*) pocet_prenasenych_dat : WORD; (*pocet dat prenasenych v jednom cteni/zapisu*) zarizeni_na_sbernici : BYTE := 2; (*poradove cislo zarizeni na sbernici RS485 - Master~16#02*) rychlost_prenosu : COM_BAUDRATE := 960; (*rychlost prenosu po sbernici - rychlost delena 10*) typ_parity : COM_PARITY := 2; (*typ parity 0~NO, 1~ODD-licha, 2~EVEN-suda *) pocet_stopbitu : COM_STOPBITS := 1; (*pocet StopBitu 1~jeden, 2~dva*) pocet_bitu : COM_BYTESIZE := 8; (*pocet datovyxh bitu 7~sedm, 8~osm*) rizeni_prenosu : COM_FLOW_CONTROL := 4; (*0~NO, 1~Xon/Xoff, 2~RTS/CTS, 3~FullDuplex, 4~HalfDuplex*) start_RS485 : BOOL; (*zahajeni komunikace po RS485*) prijata_data : typRING_BUFFER;(*buffer, kam se ukladaji prijata data, nutno RING_BUFFER*) odesilana_data : typRING_BUFFER; (*buffer, odkad se ctou data, nutno RING_BUFFER*) ErrorCode
: BYTE;
(*Kod Chyby - viz.navod ke zarizeni Slave*)
END_VAR
N´asleduje samotn´ y program pro vyˇc´ıt´an´ı dat po lince RS-485. M˚ uˇze se st´at, ˇze je potˇreba vyˇc´ıtat vˇetˇs´ı mnoˇzstv´ı dat, ale na jedno vyˇcten´ı je omezen´ y rozsah. Proto je nutn´e prov´est v´ıce pˇr´ıstup˚ u od r˚ uzn´ ych adres, jak je naznaˇceno. 74
(*Komponenta BLINK - generator pulsu*) casovani_RS485( ENABLE:= TRUE, TIMELOW:= T#0.5s, TIMEHIGH:=T#0.5s); (*Komponenta CTU - citac modulo*) radic_RS485( CU:=casovani_RS485.OUT, RESET:=radic_RESET, PV:=radic_PV); radic_RESET := radic_RS485.Q; radic_CV := radic_RS485.CV; ErrorCode := ModBus_Master.Error; IF ErrorCode = 0 THEN error := ’OK’; ELSIF ErrorCode = 1 THEN error := ’Illegal Function or Address’; ELSIF ErrorCode = 2 THEN error := ’Illegal DataValue’; ELSIF ErrorCode = 3 THEN error := ’Parameter OutOfRange’; ELSIF ErrorCode = 4 THEN error := ’Illegal Variable Format’; ELSIF ErrorCode = 6 THEN error := ’Slave Busy’; (*...*) ELSIF ErrorCode = 152 THEN error := ’Not Connected Er152’; (*...*) ELSIF ErrorCode = 153 THEN error := ’Not Connected Er153’; (*...*) END_IF; (*Zarizeni na RS485 na adrese 5 - DIRIS *) IF radic_CV = 0 THEN zarizeni :=’DIRIS_1@1’; adresa_Slave := 5; adrese_v_zarizeni_slave := 768; pocet_prenasenych_dat := 22; start_RS485 := TRUE; diris_A.proudy.f1 diris_A.proudy.f2 diris_A.proudy.f3 diris_A.proudy.f0
:= := := :=
((prijata_data.Data[5] * 256 + prijata_data.Data[6])/100); (*~0.1 A*) ((prijata_data.Data[9] * 256 + prijata_data.Data[10])/100); ((prijata_data.Data[13] * 256 + prijata_data.Data[14])/100); ((prijata_data.Data[17] * 256 + prijata_data.Data[18])/100);
ELSIF casovani_RS485.OUT = FALSE THEN start_RS485 := FALSE; END_IF; (*----------------------------------------------------------*) IF radic_CV = 1 THEN zarizeni :=’DIRIS_1@2’; adresa_Slave := 6; adrese_v_zarizeni_slave := 798; pocet_prenasenych_dat := 30; start_RS485 := TRUE; diris_A.cinny_vykon.f1 := prijata_data.Data[5] * 256 + prijata_data.Data[6]; diris_A.cinny_vykon.f2 := prijata_data.Data[9] * 256 + prijata_data.Data[10]; diris_A.cinny_vykon.f3 := prijata_data.Data[13] * 256 + prijata_data.Data[14]; ELSIF casovani_RS485.OUT = FALSE THEN start_RS485 := FALSE; END_IF;
75
4.1.6
Program PLC PRG
Hlavn´ı program, vˇzdy mus´ı b´ yt obsaˇzen jeden s t´ımto jm´enem. V tomto syst´emu je pouˇzit pouze jako taskmanager.
PROGRAM PLC_PRG VAR monitor : monitor_SFC; memory : memory_SFC; END_VAR ----------------------------------------------------------------(**AUTOMATICKY REZIM -- osetreni MG1 - ATS1000 -- SOCOMEC 1250A*) IF (System_On AND Auto AND Q1_On_Automat_Mode AND NOT Q1_On_Blokade_Mode) THEN rizeni_gen1;(*spusteni programu-tasku pro rizeni rozvadece ATS1000*) END_IF; (**AUTOMATICKY REZIM -- osetreni MG2 - ATS200 -- SOCOMEC 250A*) IF (System_On AND Auto AND Q2_On_Automat_Mode AND NOT Q2_On_Blokade_Mode) THEN rizeni_gen2;(*spusteni programu-tasku pro rizeni rozvadece ATS200*) END_IF; (**TEST BEZ ZATEZE**) IF (System_On AND Test_Without_Load AND NOT Q1_On_Blokade_Mode AND NOT Q2_On_Blokade_Mode) THEN rizeni_test_A;(*spusteni programu-tasku pro rizeni testu bez zateze*) END_IF;
(**TEST SE ZATEZI**) IF (System_On AND Test_With_Load AND Q1_On_Automat_Mode AND NOT Q1_On_Blokade_Mode AND NOT Q2_On_Blokade_Mode) THEN rizeni_test_B;(*spusteni programu-tasku pro rizeni testu se zateze*) END_IF;
analogy; (*spusteni programu-tasku pro prepocet namerenych hodnot z A/D prevodniku*) komunikace_RS485; (*spusteni programu-tasku pro komunikaci po RS-485*) komunikace_ModBus; (*spusteni programu-tasku pro komunikaci s panelem CW*) monitor; (*spusteni instance FB pro sledovani novych bool udalosti*) memory; (*spusteni instance FB pro ukladani bool udalosti do pole udalosti*) komunikace_MIB; (*spusteni programu-tasku pro definici SNMP analogovych hodnot*) (**nastaveni promennych GEN_Volt_OK
4.1.7
pro sdilene promenne pres UDP-ethernet**) := GEN1_Voltage_Is_OK;
Program rizeni gen1
Tento program je pro pˇrehlednost a pˇredevˇs´ım pro sv˚ uj sekvenˇcn´ı charakter sestaven v SFC (Sequential Function Chart). Pokud dojde k zapnut´ı programu, mus´ı b´ yt zajiˇstˇeno definovan´e chov´an´ı a uveden´ı cel´eho syst´emu do urˇcit´eho stavu, kter´ y je moˇzn´e oznaˇcit jako v´ ychoz´ı. Jedn´a se pˇredevˇs´ım o nastaven´ı v´ ykonov´ ych pˇrep´ınaˇc˚ u do polohy na prim´arn´ı s´ıt’ v pˇr´ıpadˇe, ˇze je s´ıt’ pˇr´ıtomna a pˇrep´ınaˇc je v jin´e poloze. Naopak, pokud jiˇz na s´ıt’ pˇrepnuto je, mus´ı tak z˚ ustat. Proto je v mechanismu pˇrep´ın´an´ı (viz obr. 4.1) nejprve testov´ana podm´ınka v jak´e je stykaˇc poloze. N´aslednˇe je pˇrepnuto do nulov´e pozice a ˇcek´ano dobu T2 . 76
Obr´azek 4.1: Blok programu pˇrepnut´ı stykaˇce do polohy 1
Po pˇrepnut´ı bude program ˇcekat v init_GEN, dokud nenastane v´ ypadek na prim´arn´ı s´ıti.
Obr´azek 4.2: Prvn´ı ˇc´ast programu - nastaven´ı do v´ ychoz´ıho stavu
77
Pokud nastane v´ ypadek, je paralelnˇe testov´ana d´elka v´ ypadku T1 a z´aroveˇ n poˇc´ıt´ano, kolik´at´ y je to v´ ypadek v dobˇe T6 . D´ale je startov´an agreg´at. Na pˇrechodu GEN_OK se ˇcek´a, aˇz bude gener´ator schopen dod´avat energii v poˇzadovan´e kvalitˇe.
Obr´azek 4.3: Druh´a ˇc´ast programu - testov´an´ı v´ ypadku, start agreg´atu
78
Obr´azek 4.4: Tˇret´ı ˇc´ast programu - pˇrepnut´ı na gener´ator, testov´an´ı s´ıtˇe po dobu T3 , pˇrepnut´ı zpˇet na s´ıt’
79
ˇ Obr´azek 4.5: Ctvrt´ a ˇc´ast programu - dochlazen´ı a vyhˇr´ıv´an´ı agreg´atu
80
4.2
ˇ ıd´ıc´ı syst´ R´ em nov´ e rozvodny
Jak jiˇz bylo poznamen´ano dˇr´ıve, pro zajiˇstˇen´ı z´aloˇzn´ıho nap´ajen´ı nejd˚ uleˇzitˇejˇs´ı ˇc´asti technologie byl realizov´an syst´em odp´ın´an´ı a pˇrip´ınan´ı outlet˚ u v z´avislosti na mnoˇzstv´ı pohonn´ ych hmot v n´adrˇzi motorgener´atoru. Instalovan´ y motorgener´ator KOHLER m´a spotˇrebu asi 80 l nafty na hodinu provozu pˇri pln´em zat´ıˇzen´ı. N´adrˇz je dimenzovan´a pro bezprobl´emov´ y chod na pln´ y v´ ykon po dobu 24 hodin bez nutnosti doplnˇen´ı paliva. Kromˇe toho je k dispozici jeˇstˇe z´aloˇzn´ı motorgener´ator SDMO o pˇribliˇznˇe desetinov´em v´ ykonu. Ten slouˇz´ı pouze v kritick´ ych situac´ıch, kdy dojde k poruˇse prim´arn´ıho z´alohov´an´ı. Program je opˇet ˇreˇsen jako multitaskov´ y, kdy jsou jednotliv´e podprogramy cyklicky spouˇstˇeny. K ˇr´ızen´ı jsou pouˇzity i vybran´e sign´aly z rozvadˇeˇce ATS 1000. Jedn´a se o sign´aly informuj´ıc´ı o pˇr´ıtomnosti prim´arn´ıch s´ıt´ı, napˇet´ı dod´avan´em motorgener´atory apod. Hlavn´ı program pro ˇr´ızen´ı je sestaven v SFC diagramu. Obsahuje dvˇe z´akladn´ı vˇetve. Druh´a, jednoduˇsˇs´ı na popis, ˇreˇs´ı pˇrip´ın´an´ı outlet˚ u po znovupˇripojen´ı technologie k prim´arn´ı s´ıti. Zde je nutn´e pˇripnout outlety v urˇcit´ ych ˇcasov´ ych intervalech. Logick´a podm´ınka v pˇrechodu oznaˇcen´em MAINS na obr. 4.6 je pˇrepnut´ı stykaˇce SOCOMEC ATyS do polohy na s´ıt’, sign´al z rozvadˇeˇce ATS 1000 (probˇehlo v poˇr´adku testov´an´ı kvality s´ıtˇe po dobu T3 ), je pˇr´ıtomna prim´arn´ı s´ıt’ a zat´ım po objeven´ı s´ıtˇe pˇripnut´ı neprobˇehlo (tzn. outlety budou pˇrinuty poprv´e, aby nedoˇslo k zacyklen´ı programu). Vˇsechny akce maj´ı stejnou funkci, proto bude pops´ana jen jedna. Akce oznaˇcen´a priorita_2_B pˇripojuje outlety z druh´e priority. Nejprve je v n´abˇeˇzn´e akci (oznaˇcena v lev´em doln´ım rohu p´ısmenem E) provedeno spuˇstˇen´ı ˇcasovaˇce pojmenovan´eho outlet_T1 pˇr´ıkazem start_priorita2:=TRUE;, kter´ y zajist´ı ˇcasov´e rozestupy mezi pˇripnut´ım outlet˚ u. N´asleduj´ıc´ı ˇc´ast k´odu ukazuje poˇc´ıt´an´ı ˇcasov´eho rozestupu ˇcasovaˇcem outlet_T1, po dopoˇc´ıt´an´ı je podm´ınka pro start ˇcasovaˇce zak´az´ana a je spuˇstˇen druh´ y ˇcasovaˇc prepnut´ ı_stykace. Ten zajist´ı poˇzadovan´ y ˇcasov´ y interval, dostateˇcn´ y k pˇrepnut´ı stykaˇce a pˇripnut´ı outlet˚ u. D´ale je nutn´e urˇcit, kter´e outlety v dan´e prioritˇe budou pˇripnuty a kter´e nikoliv. Uˇzivatel m˚ uˇze ve vizualizaci urˇcit seznam pˇrip´ınan´ ych outlet˚ u. Stykaˇce z´aroveˇ n pln´ı nadproudovou ochranu. Tedy v pˇr´ıpadˇe, kdy je nadproudov´a ochrana vypadl´a, nen´ı potˇreba pos´ılat poˇzadavek na pˇripnut´ı stykaˇce, protoˇze je nutn´e, aby pˇriˇsla obsluha osobnˇe a nejprve odstranila chybu a n´aslednˇe ruˇcnˇe provedla nat´ahnut´ı. V momentˇe, kdy urˇcit´ y outlet je jiˇz pˇripnut nebo vypadla nadproudov´a ochrana (sign´al _7_FA7_E), nebude se pos´ılat poˇzadavek na pˇripnut´ı (sign´al _7_FFA7_ON). Po dopoˇc´ıt´an´ı ˇcasu je nastavena promˇenn´a priorita_2_OK, kter´a informuje, ˇze je moˇzn´e pokraˇcovat v pˇrip´ınan´ı dalˇs´ı priority. Nejprve je zkontrolov´ana podm´ınka (NOT _7_FA7_E AND _7_FA7_ON) OR (_7_FA7_E AND NOT _7_FA7_ON). Tedy je pˇripnuto (v tom pˇr´ıpadˇe nen´ı vypadl´a nadproudov´a ochrana), nebo je vypadl´a nadproudov´a ochrana a nem˚ uˇze b´ yt pˇripnuto.
81
outlet_T1(IN := start_priorita2, (*pocitani casu k pripojeni technologie priority 2*) PT:= T1); start_priorita2 := FALSE; prepnuti_stykace(
IN := NOT outlet_T1.Q, (*puls delky T_stykac k prepnuti DEONu*) PT:= T_stykac);
IF prepnuti_stykace.Q THEN IF NOT _7_FA7_E AND NOT _7_FA7_ON THEN _7_FFA7_ON := TRUE; ELSIF _7_FA7_E THEN _7_FFA7_ON := FALSE; END_IF; ELSE _7_FFA7_ON := FALSE; (*V11_ucebna*) END_IF;
(*V11_ucebna*)
(*reseni podminky osetreni dalsi priority*) IF NOT prepnuti_stykace.Q AND (((NOT _7_FA7_E AND _7_FA7_ON) OR (_7_FA7_E AND NOT _7_FA7_ON)) THEN priorita_2_OK := TRUE; (*pokud je vypadla nadproud. ochr. a neni ZV od pripojeneho DEONu*) END_IF;
Pˇred opuˇstˇen´ım akce se jeˇstˇe resetuj´ı oba ˇcasovaˇce. Je to z praktick´ ych d˚ uvod˚ u, aby byl jasnˇe definov´an jejich stav pˇri dalˇs´ım cyklu. St´avalo se, ˇze ˇcasovaˇce z˚ ustaly dopoˇc´ıtan´e, nebo se pˇrednastavily nesmysln´e hodnoty. prepnuti_stykace(IN := FALSE, (*puls delky T_stykac k prepnuti DEONu*) PT:= T_stykac); outlet_T1(IN := FALSE, PT := T1);
N´asleduj´ıc´ı pˇrechod pripojeno_2B) testuje podm´ınky: AND
priorita_2_OK NOT prepnuti_stykace.Q
Prvn´ı vˇetv´ı programu (viz obr. 4.6) je ˇreˇsen´ı pˇripnut´ı outlet˚ u v pˇr´ıpadˇe z´alohov´an´ı z motorgener´atoru. Zde je nutno ˇreˇsit pˇrip´ın´an´ı s ohledem na mnoˇzstv´ı paliva a z´aroveˇ n respektovat ˇcasov´e rozestupy. Logick´a podm´ınka v pˇrechodu oznaˇcen´em GENerator je podobn´a jako v pˇredchoz´ım. Mus´ı b´ yt pˇrepnut stykaˇc SOCOMEC ATyS do polohy na gener´ator, sign´al z rozvadˇeˇce ATS 1000 (byl vyhodnocen v´ ypadek) a je pˇr´ıtomno napˇet´ı z gener´atoru. D´ale se vˇetev dˇel´ı podle mnoˇzstv´ı paliva. Pˇrechod vic_48_proc testuje podminku PHM_ted >= 48. Pokud podm´ınka nen´ı splnˇena (paliva je m´enˇe), pokraˇcuje se druhou vˇetv´ı, nastav´ı se promˇenn´a level_minule:=1 a sk´aˇce se na akci hlidani_PHM. Zde se ˇcek´a aˇz do doby, neˇz dojde k doplnˇen´ı paliva. V akci nazvan´e hlidani_PHM se prov´ad´ı pˇriˇrazen´ı aktu´aln´ı hodnoty do promˇenn´e level_minule v z´avislosti na hladinˇe.
82
Obr´azek 4.6: Prvn´ı ˇc´ast hlavn´ıho programu - oˇsetˇren´ı pˇrip´ın´an´ı outlet˚ u
Obr´azek 4.7: Druh´a ˇc´ast hlavn´ıho programu - oˇsetˇren´ı pˇrip´ın´an´ı/odp´ın´an´ı outlet˚ u dle mnoˇzstv´ı paliva
83
(*---------------------rozmezi 0 - 48%-------------------------------------*) IF PHM_ted < 48 THEN level_ted := 1; (*---------------------rozmezi 48 - 58%-------------------------------------*) ELSIF (PHM_ted >= 48 AND PHM_ted <= 58) THEN level_ted := 2; (*---------------------rozmezi 58 - 65%-------------------------------------*) ELSIF (PHM_ted > 58 AND PHM_ted <= 65) THEN level_ted := 3; (*---------------------rozmezi 65 - 80%-------------------------------------*) ELSIF (PHM_ted > 65 AND PHM_ted <= 80) THEN level_ted := 4; (*---------------------rozmezi 80 - 100%-------------------------------------*) ELSIF (PHM_ted > 80 AND PHM_ted <= 100) THEN level_ted := 5; END_IF;
Pokud dojde ke zmˇenˇe hladiny, vyhodnot´ı se podm´ınka v pˇrechodu zmena_levelu (level_minule <> level_ted) a program skoˇc´ı na akci novy_level. Zde se bude rozhodovat. Pokud doˇslo k doplnˇen´ı paliva, bude program pokraˇcovat hned prvn´ı vˇetv´ı a provede pˇripnut´ı outletu z nov´eho levelu. Program pot´e bude opˇet ˇcekat na novou zmˇenu hladiny.
(*---------------------rozmezi 0 - 48%-------------------------------------*) IF PHM_ted < 48 THEN pripnuto_OK := TRUE; (*---------------------rozmezi 48 - 58%-------------------------------------*) ELSIF (PHM_ted >= 48 AND PHM_ted <= 58) THEN IF prepnuti_stykace.Q THEN IF NOT _7_FA6_E AND NOT _7_FA6_ON THEN (*V11_test prac./ucebna*) _7_FFA6_ON := TRUE; ELSIF _7_FA6_E THEN _7_FFA6_ON := FALSE; END_IF; ELSE _7_FFA6_ON := FALSE; (*V11_test prac./ucebna*) END_IF; IF NOT prepnuti_stykace.Q AND (((NOT _7_FA6_E AND _7_FA6_ON) OR (_7_FA6_E AND NOT _7_FA6_ON)) THEN pripnuto_OK := TRUE; (*pokud je vypadla nadproud. ochr. a neni ZV od pripojeneho DEONu*) END_IF; (*---------------------rozmezi 58 - 65%-------------------------------------*) ELSIF (PHM_ted > 58 AND PHM_ted <= 65) THEN IF prepnuti_stykace.Q THEN ... END_IF; (*---------------------rozmezi 65 - 80%-------------------------------------*) ELSIF (PHM_ted > 65 AND PHM_ted <= 80) THEN IF prepnuti_stykace.Q THEN ... END_IF; (*---------------------rozmezi 80 - 100%-------------------------------------*) ELSIF (PHM_ted > 80 AND PHM_ted <= 100) THEN IF prepnuti_stykace.Q THEN ... END_IF; END_IF;
V pˇr´ıpadˇe poklesu hladiny mus´ı doj´ıt k odpojen´ı outlet˚ u z nov´eho levelu. To se dˇeje opaˇcn´ ym zp˚ usobem neˇz jak´ y byl naznaˇcen pro pˇrip´ın´an´ı. Zde jiˇz nen´ı potˇreba kontrolovat sign´al nadproudov´e ochrany, ale jen nataˇzen´ı jistiˇce. 84
IF prepnuti_stykace.Q THEN IF _7_FA4_ON THEN (*V11_kuchyne*) _7_FFA4_OFF := TRUE; ELSIF NOT _7_FA4_E THEN _7_FFA4_OFF := FALSE; END_IF; ELSE _7_FFA4_OFF := FALSE; (*V11_kuchyne*) END_IF; IF NOT prepnuti_stykace.Q AND NOT _7_FA4_ON THEN priorita_2_OK := TRUE; (*pokud je vypadla nadproud. ochr. a neni ZV od pripojeneho DEONu*) END_IF;
T´ımto je v podstatˇe princip programu pro ˇr´ızen´ı rozvodny pops´an. D´ale se zde vyskytuj´ı podprogramy pro ˇreˇsen´ı stavov´ ych informac´ı pomoc´ı SNMP trap zpr´av, z´apisu analogov´ ych hodnot do MIB datab´aze, vyˇc´ıt´an´ı dat z mˇeˇr´ıc´ıch pˇr´ıstroj˚ u DIRIS po lince RS-485 apod. Princip tˇechto podprogram˚ u je vˇsak shodn´ y jako v rozvadˇeˇci ATS 1000.
85
4.3
S´ıt’ov´ e promˇ enn´ e
Cel´a aplikace je rozloˇzena na dva autonomn´ı PLC automaty. Aby bylo moˇzn´e prov´adˇet spolehliv´e ˇr´ızen´ı v rozvodnˇe, je nutn´e zn´at stav - polohu v´ ykonov´ ych pˇrep´ınaˇc˚ u. V u ´vahu pˇrich´azely dvˇe z´akladn´ı varianty. Prvn´ı byla nataˇzen´ı zpˇetn´e vazby od pomocn´ ych kontakt˚ u obou pˇrep´ınaˇc˚ u do obou PLC jako bin´arn´ı vstupy. Druhou moˇznost´ı bylo pouˇzit´ı s´ıt’ov´ ych promˇenn´ ych, tato varianta se nakonec realizovala. N´ıˇze uveden´ y text pojedn´av´a o pˇrid´an´ı a definici s´ıt’ov´ ych promˇenn´ ych do vytvoˇren´eho projektu. Pˇrid´an´ı a konfigurace s´ıt’ov´ ych promˇenn´ ych v prostˇred´ı CoDeSys vypad´a n´asledovnˇe. Na kartˇe Resources se pˇrid´a nov´ y objekt, zad´a se jeho jm´eno a cesta, kde se bude nach´azet soubor (ve formatu ’nazev’.exp ) uchov´avaj´ıc´ı potˇrebn´e informace o promˇenn´ ych.
Obr´azek 4.8: Vlasnosti sd´ılen´ ych promˇenn´ ych
D´ale je nutn´e uv´est, zda se bude tento soubor v dan´em programu generovat (export before compile) nebo se bude naˇc´ıtat (import before compile). Takto je moˇzn´e pˇridat dalˇs´ı soubor promˇenn´ ych. Pokud je poˇzadavek na s´ıt’ov´e promˇenn´e, mus´ı se pouˇz´ıt tlaˇc´ıtko Add ” network“. T´ım se zobraz´ı dialog, kde je moˇzn´e uv´est, zda-li se v dan´em programu bude pouˇz´ıvat pouze ˇcten´ı s´ıt’ov´ ych promˇenn´ ych, nebo pouze z´apis, nebo jejich kombinace. D´ale je moˇzn´e urˇcit jak bude prob´ıhat pˇrenos aktu´aln´ıho stavu promˇenn´ ych. Jsou tˇri moˇznosti: • cyklick´ y pˇrenos . . . lze nastavit ˇcasov´ y interval ve form´atu T#_ms, • pˇrenos na zmˇenu . . . k pˇrenosu dojde pˇri zmˇenˇe stavu nˇekter´e z promˇenn´ ych, nebo po uplynut´ı nastaven´eho minim´aln´ıho ˇcasu ( Minimum gap“), ” • pˇrenos na zmˇenu urˇcit´e promˇenn´e . . . uvede se promˇenn´a pˇri jej´ıˇz zmˇenˇe dojde k pˇrenosu. 86
Obr´azek 4.9: (a) Bez sd´ılen´ ych promˇenn´ ych netvar001“ ”
(b) Sd´ılen´e promˇenn´e
Pˇredchoz´ı obr´azek zachycuje situaci pˇred pˇrid´an´ım a po pˇrid´an´ı s´ıt’ov´ ych promˇenn´ ych. Jejich definov´an´ı se provede standardn´ım zp˚ usobem a je naznaˇceno v pˇr´ıkladu, kde je definov´ana jedna s´ıt’ov´a promˇenn´a nazvan´a GEN_network, jej´ıˇz typ je BOOL (bin´arn´ı promˇenn´a). VAR_GLOBAL GEN_Volt_OK :BOOL; END_VAR
Na z´avˇer k s´ıt’ov´ ym promˇenn´ ym jeˇstˇe jedna praktick´a zkuˇsenost. Pˇri pouˇzit´ı s´ıt’ov´ ych promˇenn´ ych je nutn´e uv´est a pouˇz´ıt v programu alespoˇ n jednu, jinak pˇri kompilaci programu dojde k ohl´aˇsen´ı chyby Error4061. Pro odstranˇen´ı chyby postaˇc´ı pouze uveden´ı v libovoln´em spouˇstˇen´em POU.
87
88
Kapitola 5 Program pro panelov´ e PC v ControlWebu ControlWeb je k dispozici ve dvou z´akladn´ıch verz´ıch. Prvn´ı je v´ yvojov´a verze nutn´a pro vytvoˇren´ı aplikace. V´ ysledkem je soubor ve form´atu *.cw. Toto samotn´e prostˇred´ı umoˇzn ˇuje vytvoˇrit plnohodnotnou aplikaci. Pokud je ale nutn´e pouˇz´ıvat komunikaˇcn´ı kan´aly ˇci jin´e dalˇs´ı doplˇ nuj´ıc´ı funkce, je nutn´e dokoupit a doinstalovat pˇr´ıdavn´e moduly. Jejich seznam je moˇzn´e naj´ıt na webu spoleˇcnosti Moravsk´e pˇr´ıstroje v sekci Cen´ık. Druh´a verze je oznaˇcov´ana jako Runtime. Vytvoˇren´a aplikace se nejprve pˇreloˇz´ı na form´at *.cwx. Takto z´ıskanou aplikaci je moˇzn´e spustit pˇr´ımo v m´ıstˇe urˇcen´ı. V´ yhodou 1 Runtime verze je mnohem menˇs´ı cena , nev´ yhodou naopak nemoˇznost u ´pravy sestaven´e aplikace.
5.1
Propojen´ı ControlWebu a PLC WAGO
Fyzick´e propojen´ı je provedeno dnes jiˇz pro pr˚ umysl standardn´ım ethernetem 100Mbit/s. Jako protokol je pouˇzit jiˇz zm´ınˇen´ y ModBus TCP/IP. Pˇrenos dat mezi prostˇred´ım ControlWeb a PLC WAGO prob´ıh´a ˇcten´ım a z´apisem do pamˇet’ov´ ych bunˇek v PLC. Pro nastaven´ı poˇzadovan´eho pˇrenosu jsou nutn´e dva soubory. Prvn´ım je ’nazev’.dmf. Zde se definuj´ı tzv. kan´aly. V n´asleduj´ıc´ı ˇc´asti je uk´azka takov´eho souboru. Je nutn´e uv´est o jak´ y typ kan´alu p˚ ujde (real / boolean) a smˇer pˇrenosu z pohledu ControlWebu. Tento soubor s definic´ı kan´alu je shodn´ y pro vˇsechny typy ovladaˇc˚ u kan´al˚ u. Pro uˇzivatelsk´e uˇzit´ı jsou vyhrazeny kan´aly od ˇc´ısla 100. Niˇzˇs´ı maj´ı funkci konfigurace a diagnostiky samotn´ ych PLC kontroler˚ u. Tedy soubor ’*’.dmf m˚ uˇze vypadat n´asledovnˇe. begin 100 300 500 700 end.
-
199 399 599 799
real input (*analogov´ e hodnoty...vstupy*) boolean input (*digit´ aln´ ı ´ udaje...vstupy*) boolean output (*digit´ aln´ ı ´ udaje...v´ ystupy*) real output (*analogov´ e hodnoty...v´ ystupy*)
1 ControlWeb 6 V´ yvojov´ a verze - 21 700 Kˇc, ControlWeb 6 Runtime - 6 500 Kˇc, ovladaˇc Modicon MODBUS TCP/IP - 10 700 Kˇc, citov´ ano 21.10.2008
89
Rozsah kan´al˚ u m˚ uˇze b´ yt libovoln´ y. Pro ovladaˇc kan´alu postaven´eho nad RS-232 se nedoporuˇcuje mˇenit a editovat v´ yˇse popsan´ y soubor, jinak hroz´ı nefunkˇcnost syst´emu a z toho plynouc´ı ˇskody. V t´eto diplomov´e pr´aci byl pouˇzit kan´al MODBUS TCP/IP nad ethernetem a samozˇrejmost´ı byla zkouˇska zmˇeny typu kan´al˚ u. Vˇse fungovalo bez probl´em˚ u. Jedin´ y probl´em, kter´ y se vyskytl, byl s prostˇred´ım ControlWeb. Po editaci souboru ’*’.dmf bylo nutn´e restartovat prostˇred´ı, aby doˇslo k poˇzadovan´ ym zmˇen´am. Druh´ ym d˚ uleˇzit´ ym souborem pro definici komunikaˇcn´ıch kan´al˚ u je soubor ’nazev’.par, oznaˇcovan´ y jako parametrick´ y. Zde prob´ıh´a definice cesty k zaˇr´ızen´ı. Jedn´a se o zad´an´ı adresy zaˇr´ızen´ı (Address). Tou m˚ uˇze b´ yt IP adresy v pˇr´ıpadˇe MODBUS kan´alu nad ethernetem, nebo napˇr´ıklad portu v pˇr´ıpadˇe kan´alu nad RS-232. V´ yhodou takov´eto definice je, ˇze aplikace m˚ uˇze vyuˇz´ıvat v´ıce fyzick´ ych zaˇr´ızen´ı (napˇr. PLC kontroler˚ u), se kter´ ymi prob´ıh´a komunikace. D´ale to je pˇresn´ y rozsah kan´al˚ u (ChFrom a ChTo). Lze definovat samotn´e kan´aly, nebo jejich rozsah. Definice rozsahem je v´ yhodn´a, pokud je poˇzadavek pˇriˇradit urˇcit´e vlastnosti vˇetˇs´ımu poˇctu kan´al˚ u. N´aslednˇe se definuje tzv. oblast (Area). V´ ystiˇznˇejˇs´ı pojmenov´an´ı je modifik´ator pˇrenosu. Existuje ˇctveˇrice modifik´ator˚ u, kter´e byly vyuˇzity pˇri tvorbˇe aplikace.
Tabulka 5.1: Modifik´atory pˇrenosu z CW do PLC
0x 1x 3x 4x
OUTPUT - nastaven´ı bin´arn´ıch v´ ystup˚ u v PLC INPUT - ˇcten´ı bin´arn´ıch vstup˚ u z PLC REGISTER - ˇcten´ı/z´apis analogov´ ych karet PLC (WORD) HOLD - ˇcten´ı/z´apis do pamˇeti PLC (WORD)
Posledn´ım povinn´ ym u ´dajem je offset (Ofs). Ten urˇcuje poˇc´aten´ı adresu v zaˇr´ızen´ı, od kter´e se bude ˇc´ıst nebo zapisovat. S urˇcen´ım hodnoty offsetu b´ yv´a probl´em. Pˇri tvorbˇe t´eto pr´ace bylo zjiˇstˇeno, ˇze funguje n´asleduj´ıc´ı mechanismus. Pokud bude poˇzadavek na ˇcten´ı bin´arn´ıch vstup˚ u PLC, bude pouˇzit modifik´ator pˇrenosu 1x a offset zaˇc´ın´a od 1, protoˇze bude ˇcten bin´arn´ı vstup na prvn´ı adrese. Na obr. 5.1 je naznaˇceno 8DI2 . Protoˇze adresa prvn´ıho vstupu je %IX0.1. Tedy offset bude 1. V tabulka 5.2 je naznaˇcen princip pˇriˇrazen´ı offsetu.
2
Digital Inputs
90
Obr´azek 5.1: Bin´arn´ı vstupy PLC WAGO 750-430
Tabulka 5.2: Modifik´atory pˇrenosu z CW do PLC
WAGO
Area Ofs
%IX0.1 %IX0.2 %IX0.8
1x 1x 1x
1 2 8
%MW0 %MW1
3x 3x
1 2
Podobnˇe funguje i pˇr´ıstup k analogov´ ym kart´am. Tam se pouˇz´ıv´a modifik´ator 3x a jako offset je opˇet 1, pokud se bude ˇc´ıst od prvn´ıho kan´alu prvn´ı karty. V obr. 5.1 je opˇet naznaˇcen pˇr´ıstup k jednotliv´ ym WORD˚ um analogov´ ych karet. Pozor na spr´avnˇe uvedenou oblast Area. Probl´em ovˇsem nast´av´a v pˇr´ıpadˇe, kdy by se mˇelo ˇc´ıst/zapisovat do pamˇeti PLC. V tomto pˇr´ıpadˇe je nutn´e zjistit rozsah adres, kter´e jsou rezervovan´e pro pr´aci PLC a poˇc´ateˇcn´ı adresu pro uˇzivatelsk´a data. Pro tento pˇr´ıpad byla pouˇzita poˇc´ateˇcn´ı adresa v PLC 3064hex , tedy adresa 12388dec . Tato adresa byla zvolena, protoˇze na adrese 3000hex zaˇc´ınaj´ı pamˇet’ov´e registry a n´asleduje oblast pro diagnostiky modul˚ u. Ty zab´ıraj´ı 100xWORD oblast. Naznaˇcen´ y probl´em se vyskytuje aˇz v momentˇe, kdy uˇzivatel-program´ator chce ˇc´ıst nebo zapisovat. Z pˇredchoz´ıho odstavce plyne mechanismus v´ ypoˇctu adresy. Takto z´ıskan´a adresa 12388dec 3 vˇsak nen´ı spr´avn´a. Bylo vyzkouˇseno, ˇze je nutn´e pouˇz´ıt aˇz n´asleduj´ıc´ı adresu, tedy 12389dec . Dalˇs´ımi nepovinn´ ymi u ´daji jsou pˇresnˇejˇs´ı typ kan´alu [Subtype]. M˚ uˇze se jednat o int, int16, jejich neznam´enkov´a verze, bin´arn´ı kan´al atd. K typu kan´alu se v´aˇze i smˇer pˇrenosu [Bidirect]. Jsou dva typy, implicitnˇe je nastaven jednosmˇern´ y z pohledu ControlWebu a 3
3000hex + 100dec → 12388dec ≈ 12388dec
91
nezapisuje se. Pokud poˇzadujeme obousmˇern´ y, pak se zapisuje kl´ıˇcov´ ym slovem bidirect. ˇ Pˇredposledn´ı nepovinn´ y parametr je oznaˇcen´ı kan´al˚ u [ID:x]. C´ıslov´an´ı je plnˇe v rukou program´atora a nem´a vliv na funkˇcnost syst´emu. Posledn´ım u ´dajem je koment´aˇr kan´al˚ u [;comment]. Opˇet dle uv´aˇzen´ı program´atora a slouˇz´ı pˇredevˇs´ım k pˇrehlednosti. Na tomto m´ıstˇe je vhodn´e poznamenat subjektivn´ı dojem z u ´pravy parametrick´eho souboru. Je nevhodn´e pouˇz´ıvat tabul´ator pˇri psan´ı. V pˇr´ıpadˇe jeho pouˇzit´ı se objev´ı pˇri kompilaci aplikace v ControlWebu chyba v parametrick´em souboru a je nutn´e jej cel´ y napsat znovu. Obecnˇe m˚ uˇze vypadat parametrick´ y soubor n´asledovnˇe. Hlaviˇcku je nutn´e uv´adˇet vˇzdy. V z´avislosti na poˇzadavc´ıch ˇr´ızen´ı nebo monitorov´an´ı se vol´ı parametry pˇrenosu, jako je CheckTime nebo Timeout. Pˇr´ıliˇs n´ızk´a hodnota m˚ uˇze v´est k nestabilitˇe komunikace mezi PLC a aplikac´ı ControlWeb, nebo dokonce k p´adu aplikace. Parametr TraceOutput slouˇz´ı k lazen´ı komunikace. Do vytvoˇren´eho souboru se zapisuje veˇsker´a probˇehl´a komunikace po kan´alu. Jedn´a se o v´ ypis, kter´ y je k dispozici pˇri tvorbˇe aplikace v prostˇred´ı ControlWeb. [Modbus] (*typ protokolu kan´ alu*) Mode = RTU (*definice kan´ alu*) CheckTime = 50000 ConnectOnStartup = false Timeout = 1000 EnableMonitor = true DisablePresetSingleRegister = false MaxRegistersInBlock = 100 TraceOutput = None (*trasovaci soubor, C:\XTrace.log*) [Channels] ;------------------------------------------------------------------------------------------------;Block = Address, ChFrom, ChTo, Area, Ofs [,Subtype] [,Bidirect] [,ID:x] [;comment] ;------------------------------------------------------------------------------------------------Block =
[email protected], 100, 105, 3X, 1, uint16, id:0101 ;AI modules [Settings] Timeout = 500 NumRepeat = 1
Pokud by byl pouˇzit kan´al nad RS-232, lze uˇz´ıt protokol SAIA S-BUS. [ComPort] Com = com1 Protocol = sbus SBusMode = Parity BaudRate = 9600 Timeout = 200 RTS = enable [Channels] ;-----------------------------------------------------------------------------;Block = Station, ChannelFrom, ChannelTo, Media, Offset, [Subtype], [Bidirect] ;-----------------------------------------------------------------------------Block = 01, 500, 515, F, 0 ;flagy (bitove promenne) Block = 01, 600, 607, I, 0 ;bitove vstupy Block = 01, 700, 707, O, 16 , bidirect ;bitove vystupy Block = 01, 900, 915, R, 100, uint8, bidirect ;analogove vystupy [Settings] ComDriver = CWCOMM.DLL COM1 Timeout = 500 NumRepeat = 1
92
Jak bylo poznamen´ano, v souboru *.dmf lze kromˇe uˇzivatelsk´ ych kan´al˚ u definovat i kan´aly pro diagnostiku PLC. Pro pˇrehlednost a moˇznost zjiˇstˇen´ı chyb lze v sestaven´e aplikaci nahl´ednout, v jak´em stavu se pr´avˇe PLC nach´az´ı, jeho v´ yrobce, oznaˇcen´ı a typ, verze firmware apod. Tak´e jsou zde zobrazeny vlastnosti aktu´alnˇe zpracov´avan´ ych kan´al˚ u.
Obr´azek 5.2: Diagnostick´ y n´astroj
Aby bylo moˇzn´e tyto diagnostick´e kan´aly pouˇz´ıvat, je nutn´e je uv´est i v parametrick´em souboru. Oba pouˇzit´e soubory jsou zobrazeny n´aslednˇe, z´aroveˇ n jsou uvedeny i jednoduch´e vysvˇetlivky.
begin 1 2 10 11 12 13 14 15 16 17 18 20 21 22 23 24 25 26 27 28 100 200 300 400 500 600 700 800 end.
real input (*ExceptionStatus*) string input (*ConnectedStation*) real input (*StationR*) real input (*ErrCodeR*) string input (*ErrStringR*) real input (*ErrCountR*) real input (*FirstChannelR*) real input (*LastChannelR*) real input (*MediaR*) boolean output (*ResetR*) boolean output (*ClearErrorCounterR*) real input (*StationW*) real input (*ErrCodeW*) string input (*ErrStringW*) real input (*ErrCountW*) real input (*FirstChannelW*) real input (*LastChannelW*) real input (*MediaW*) boolean output (*ResetW*) boolean output (*ClearErrorCounterW*) - 199 real input (*AnalogInputs & DiagWAGO*) - 299 real input - 399 boolean input (*DigitalInputs WAGO_ATS*) - 499 boolean input (*DigitalInputs WAGO_RH*) - 599 boolean output - 699 boolean output - 799 real output - 2000 real input (*DataRS485 WAGO_RH*)
93
[Modbus] (*typ protokolu kan´ alu*) Mode = RTU (*definice kan´ alu*) CheckTime = 50000 ConnectOnStartup = false Timeout = 1000 EnableMonitor = true DisablePresetSingleRegister = false MaxRegistersInBlock = 100 TraceOutput = None (*trasovaci soubor, C:\XTrace.log*) [Channels] ;------------------------------------------------------------------------------------------------;Block = Address, ChFrom, ChTo, Area, Ofs [,Subtype] [,Bidirect] [,ID:x] [;comment] ;------------------------------------------------------------------------------------------------Block =
[email protected], 100, 105, 3X, 1, uint16, id:0101 ;AI modules WAGO_1 ... ATS 1000 (napeti UPS a proudy L1,L2,L3) ;------------------------Block =
[email protected], 106, 112, 3X, 1, uint16, id:0102 ;AI modules WAGO_2 ... RH_x (pt100 a napeti UPS) ;------------------------Block =
[email protected], 115, 115, 4X, 8209, uint16, bidirect id:0103 ;WAGO_ATS-firmware WAGA Block =
[email protected], 116, 116, 4X, 8210, uint16, bidirect id:0104 ;WAGO_ATS-serie WAGA Block =
[email protected], 117, 117, 4X, 8211, uint16, bidirect id:0105 ;WAGO_ATS-vezre kontroleru WAGA Block =
[email protected], 118, 118, 4X, 8212, uint16, bidirect id:0106 ;WAGO_ATS-serie WAGA Block =
[email protected], 119, 119, 4X, 8213, uint16, bidirect id:0106 ;WAGO_ATS-vezre kontroleru WAGA ;------------------------Block =
[email protected], 120, 120, 4X, 8209, uint16, bidirect id:0107 ;WAGO_ATS-firmware WAGA Block =
[email protected], 121, 121, 4X, 8210, uint16, bidirect id:0108 ;WAGO_ATS-serie WAGA Block =
[email protected], 122, 122, 4X, 8211, uint16, bidirect id:0109 ;WAGO_ATS-vezre kontroleru WAGA Block =
[email protected], 123, 123, 4X, 8212, uint16, bidirect id:0110 ;WAGO_ATS-serie WAGA Block =
[email protected], 124, 124, 4X, 8213, uint16, bidirect id:0111 ;WAGO_ATS-vezre kontroleru WAGA ;------------------------Block =
[email protected], 125, 299, 4X, 12489, uint16, id:0112 ;WAGO_ATS-data nactena po RS485(Diris, Kohler, Lovato RGK, DMK) ;------------------------Block =
[email protected], 300, 399, 1X, 1, id:0113 ;DI modules WAGO_ATS ... ATS 1000 (40 DI) ;------------------------Block =
[email protected], 400, 499, 1X, 1, id:0114 ;DI modules WAGO_RH ... RH_x (56 DI) ;------------------------Block =
[email protected], 700, 749, 4X, 12389, uint16, id:0115 ;WAGO_ATS ... zapis hodnot z CW do WAGA (casove T1...T6) Block =
[email protected], 750, 799, 4X, 12389, uint16, id:0116 ;WAGO_RH ... zapis hodnot z CW do WAGA (casy odpinani) ;------------------------Block =
[email protected], 800, 1800, 4X, 12489, uint16, id:0117 ;WAGO_RH - data nactena po RS485(25xDiris - 25xword)
5.1.1
Tvorba aplikace
V momentˇe, kdy jsou definov´any kan´aly pomoc´ı parametrick´eho souboru, je moˇzn´e pˇr´ımo v prostˇred´ı CW udˇelat jejich deklaraci a t´ım je zaˇc´ıt pouˇz´ıvat. Jak vypad´a z´aloˇzka Datov´e inspektory je na n´asleduj´ıc´ım obr´azku. 94
Obr´azek 5.3: Deklarace kan´al˚ u v prostˇred´ı CW
Celkov´ y pohled na grafickou str´anku v´ ysledn´e aplikace pˇrin´aˇs´ı n´asleduj´ıc´ı obr´azek.
Obr´azek 5.4: V´ yvoj grafick´e podoby aplikace
Protoˇze vizualizace je navrˇzena na panelov´e PC s rozliˇsen´ım obrazovky 800x600 bod˚ u, 95
bylo nutn´e dostat maximum informace o technologii na mal´ y prostor. Proto byla oˇr´ıznuta standardn´ı Windows liˇsta. K zastaven´ı aplikace slouˇz´ı pˇr´ısluˇsn´e tlaˇc´ıtko, jehoˇz k´od i s popisky je uveden n´ıˇze.
owner = ovladani (*panel ktery je vlastnikem tlacitka-kazdy pristroj musi mit vlastnika*); position = 5, 532, 118, 26; win_disable = zoom, maximize; (*zakazane operace s pristrojem*) access = [ 0, 10, 100, 1000]; (*uzivatelske skupiny ktere mohou pristroj spustit*) mode = text_button; (*jak bude pristroj vypadat*) font = ’Arial (Central European)’, 10, normal; true_text = ’Konec’; false_text = ’Konec’; logic = set_true_on_press; (*logicka funkce pristroje*) procedure OnMouseDown( MouseX, MouseY : longint; LeftButton, MiddleButton, RightButton : boolean ); begin core.StopApplication(); (*funkce jadra-zastaveni aplikace*) end_procedure;
Dalˇs´ım tlaˇc´ıtkem je moˇzn´e zobrazit klavesnici na obrazovce. Panelov´e PC m´a dotykov´ y 4 displej a ovladan´ı se prov´ad´ı pˇres obrazovku. Pˇr´ıkaz osk.exe je standardn´ı funkce operaˇcn´ıho syst´emu Windows. Jak je patrn´e, chyb´ı zde ˇr´adek definuj´ıc´ı pˇr´ıstupov´a pr´ave (access=[...]). Pokud maj´ı k pˇr´ıstroji pˇr´ıstup vˇsichni uˇzivatel´e (access=[0, 4294967296]), CW automaticky ˇr´adek smaˇze.
owner = ovladani; position = 6, 118, 118, 26; win_disable = zoom, maximize; mode = text_button; font = ’Arial (Central European)’, 10, normal; true_text = ’Klavesnice’; false_text = ’Klavesnice’; logic = set_true_on_press; procedure OnMouseDown( MouseX, MouseY : longint; LeftButton, MiddleButton, RightButton : boolean ); var ErrorCodeKeyboard : longcard; ParametersKeyboard : string; x : longint; y : longint; w : longint; d : longint; Minimized : boolean; ThreadIdentifier : longcard; begin system.RunProgram(ThreadIdentifier, ’C:\WINDOWS\system32\osk.exe’, ParametersKeyboard, x, y, w, d, Minimized); end_procedure;
Lze nastavit, ˇze po spuˇstˇen´ı se automaticky nebude zobrazovat dialogov´e okno pro pˇrihl´aˇsen´ı uˇzivatele. K jeho zobrazen´ı slouˇz´ı n´asleduj´ıc´ı k´od. 4
On Screen Keyboard
96
owner = ovladani; position = 5, 474, 118, 26; win_disable = zoom, maximize; mode = text_button; font = ’Arial (Central European)’, 10, normal; true_text = ’Login’; false_text = ’Login’; logic = set_true_on_press; procedure OnMouseDown( MouseX, MouseY : longint; LeftButton, MiddleButton, RightButton : boolean ); begin system.ShowLoginWindow(); end_procedure;
V prav´e horn´ı ˇc´asti obrazovky, pod logem v´ yrobce, je zobrazen´ı pr´avˇe pˇrihl´aˇsen´eho uˇzivatele. K tomu slouˇz´ı n´asleduj´ıc´ı procedura. owner = ovladani; position = 66, 88, 57, 20; procedure OnActivate(); var UserLevel : longcard; UserLogin : string; UserFull : string; begin system.GetActualUser( UserLevel, UserLogin, UserFull ); if UserLogin = ’root’ then uzivatel = ’root’; elsif UserLogin = ’technolog’ then uzivatel = ’technolog’; elsif UserLogin = ’servis’ then uzivatel = ’servis’; elsif UserLogin = ’obsluha’ then uzivatel = ’obsluha’; elsif UserLogin = ’none’ then uzivatel = ’none’; end; (*hhh*) SetValue(uzivatel); end_procedure;
N´asleduj´ıc´ı dvˇe procedury vyuˇz´ıvaj´ı funkci date a jej´ı parametry pro zobrazen´ı aktu´aln´ıho datumu a ˇcasu. Alarmy jsou zapisov´any do logovac´ıho souboru a je vhodn´e m´ıt pˇr´ımo na obrazovce pˇrehled o aktu´aln´ım ˇcase (liˇsta je automaticky schov´av´ana pro vˇetˇs´ı prostor na obrazovce). timer = 100, 0.1; owner = ovladani; position = 2, 60, 65, 20; procedure OnActivate(); var datum : string; begin datum = date.TodayToString(); SetValue(datum); end_procedure;
97
timer = 5, 0.1; owner = ovladani; position = 68, 60, 55, 20; justify = left; procedure OnActivate(); var cas : string; begin date.GetTimeString(cas); SetValue(cas); end_procedure;
Kontrolky nadproudov´ ych ochran jsou ˇreˇseny jako soubory typu *.ico a zobrazov´any jako ˇcerven´a v pˇr´ıpadˇe vypadnut´ı ochrany vlivem nadproudu nebo zelen´a pokud je vˇse v poˇr´adku.
owner = zakladni_okno; position = 276, 355; win_disable = zoom, maximize; expression = _8_FA1_E; (*logicky signal na ktery se reaguje*) true_icon = ’gledon2.ico’; false_icon = ’gledoff2.ico’; blink_colors true_paper = white; false_paper = white; end_blink_colors;
Podobnˇe je ˇreˇseno i zobrazen´ı, zda-li vˇetv´ı prouch´az´ı proud.
owner = zakladni_okno; position = 269, 389, 5, 50; procedure OnActivate(); begin if _8_FA1_ON = true then box_8_FA1.SetInteriorColor(0, 255, 0); (*prochazi proud-cara je zelena (Red,Green,Blue)*) box_8_FA1.SetBorderColor(0, 255, 0); else box_8_FA1.SetInteriorColor(255, 0, 0); (*neprochazi proud-cara je cervena*) box_8_FA1.SetBorderColor(255, 0, 0); end; end_procedure;
Pro archivov´an´ı stav˚ u syst´emu je pouˇzita komponenta alarm. Je moˇzn´e urˇcit strukturu, jak budou z´aznamy vapadat a tak´e, kter´e u ´daje o ud´alosti budou obsaˇzeny. Z´aznamy mohou obsahovat datum a ˇcas vzniku, d´ale je lze tˇr´ıdit do skupin dle priorit nebo podle ˇc´ast´ı celku (ATS, RH, MTG). Pro kritick´e ud´alosti (napˇr. doch´az´ı palivo) lze nastavit poˇzadavek na potvrzen´ı nastal´e ud´alosti oper´atorem. 98
owner = zakladni_okno; position = 0, 469, 674, 139; record_structure = classify, group, text, value, operator, priority, none; message_content = rise_date, rise_time, priority, group, text, operator, none, none, none, none, none; confirm_access = [ 0..100 ]; file name = ’Alarmy’; type = absolute; length = day; history = 14; access = [ 10..100, 100..1000 ]; name_type = long_name; end_file; item text = ’palivo - mene nez 50% nadrze’; group = ’MTG’; priority = 100; condition = palivo < 50; finish_condition = palivo < 50; expression = palivo; rise_action = write; finish_action = write; confirm_action = write; end_item; item text = ’palivo - mene nez 10% nadrze ’; group = ’MTG’; priority = 1; condition = palivo < 10; finish_condition = palivo < 10; expression = palivo; rise_action = write; finish_action = write; confirm_action = write; end_item;
99
Obr´azek 5.5: Celkov´ y pohled na vizualizaci 100
Kapitola 6 Z´ avˇ er Pˇredl´adan´a pr´ace zpracov´av´a t´ema ˇr´ızen´ı rozvadˇeˇce pro automatick´e bezobsluˇzn´e pˇrep´ın´an´ı z´aloˇzn´ıch zdroj˚ u. C´ılem bylo vytvoˇrit ˇr´ıdic´ı program pˇr´ımo na m´ıru“ jiˇz vyprojek” tovan´emu fyzick´emu ˇreˇsen´ı rozvadˇeˇc˚ u s pˇrep´ınac´ımi prvky ATS. Na z´aˇc´atku pr´ace probˇehlo sezn´amen´ı jednak se samotnou technologi´ı, ale predevˇs´ım s principem a ˇcinnost´ı ATS rozvadˇeˇc˚ u. Souˇc´ast´ı cel´eho syst´emu je i ˇr´ızen´ı pˇrip´ınan´ı a odp´ın´an´ı outlet˚ u rozvodny. V zad´an´ı jsou pˇresnˇe specifikov´any poˇzadavky pro odp´ın´an´ı a pˇrip´ın´an´ı jednotliv´ ych outlet˚ u. V pˇr´ıpravn´e f´azi bylo rozhodnuto, ˇze ˇr´ızen´a technologie bude rozdˇelena na ˇc´ast rozvadeˇc˚ u ATS a rozvodny RH, kaˇzd´a s vlastn´ı jednotkou PLC. Rozdˇelen´ım doˇslo k potˇreb´am komunikace mezi obˇema jedotkami PLC. Z nˇekolika moˇznost´ı byla vybr´ana metoda sd´ılen´ ych promˇenn´ ych. Po pˇr´ıpravn´e f´azi n´asledoval principi´aln´ı n´avrh strategie ˇr´ızen´ı. Zohlednˇen´ ymi parametry n´avrhu byly kromˇe z´akladn´ıch poˇzadavk˚ u p´ısemn´eho zad´an´ı tak´e poˇzadavek na modularitu jednotliv´ ych program˚ u a hlavnˇe pˇrehlednost cel´eho k´odu. S pˇrihl´ednut´ım k poˇzadavk˚ um byly koncepce obou hlavn´ıch program˚ u sestaveny v jazyce SFC (strukturn´ı funkˇcn´ı sch´ema). Program pro ˇr´ızen´ı ATS kop´ıruje sekvenˇcn´ı strukturu cyklu pˇrep´ın´an´ı, ˇc´ımˇz je splˇ nen poˇzadavek na pˇrehlednost. Modularita je zajiˇstˇena pomoc´ı tzv. task-manageru, kdy s ohledem na funkˇcn´ı cyklus PLC jsou postupnˇe vol´any jednotliv´em programy. Vyuˇzit´ı jazyka SFC je v´ yhodn´e i z pohledu testov´an´ı fin´aln´ıho programu pˇr´ımo na technologii. Je na prvn´ı pohled vidˇet, v jak´em stavu se pr´avˇe technologie nach´az´ı a lze jednoduˇse kontrolovat podm´ınky dalˇs´ıho postupu. Vizualizace technologick´eho celku se realizov´ana s vyuˇzit´ım programovac´ıho prostˇred´ı ControlWeb. Vzhledem k rozs´ahlosti grafick´eho prostˇred´ı vizualizace a pouˇzit´emu panelov´emu PC m˚ uˇze na prvn´ı pohled p˚ usobit tˇeˇzkop´adnˇe a pˇreplnˇenˇe. Jsou vˇsak zobrazeny veˇsker´e d˚ uleˇzit´e informace na jedin´e obrazovce, coˇz pˇrisp´ıv´a pˇrehlednosti. Vzhledem k faktu, ˇze je jedn´a o ˇr´ıdic´ı syst´em to pˇrin´aˇs´ı i dalˇs´ı v´ yhodu, ˇze je moˇzn´e z jedin´eho okna sledovat celou technologii. K ovl´ad´an´ı slouˇz´ı dialogov´e okno, kde je moˇzn´e nastavovat ˇcasov´e parametry pˇrep´ınac´ıho cyklu a ˇcasov´a zpoˇzdˇen´ı pˇri pˇrip´ınan´ı outlet˚ u. Moˇznosti testov´an´ı syst´emu ˇrizen´ı byly omezen´e a mohly prob´ıhat pouze mimo pracovn´ı dobu. Pˇri testov´an´ı byly upraveny z´akladn´ı ˇcasov´e parametry, kter´e jsou uloˇzeny jako pˇrednastaven´e hodnoty. Pro zajiˇstˇen´ı pˇrehlednosti byla mod´ıfikov´ana i grafick´a ˇc´ast 101
vizualizace. Jednalo se o celkov´e zobrazen´ı rozvodny - pohled shora a um´ıstˇen´ı obou agreg´at˚ u doprostˇred. K uveden´emu ˇreˇsen´ı na m´ıru“ exituj´ı tak´e ekvivalentn´ı standardizovan´e. Jedn´ım z ” nich m˚ uˇze b´ yt pouˇzit´ı pˇrep´ınaˇc˚ u vyuˇz´ıvaj´ıc´ı technologii oznaˇcovanou jako STS (Static Transfer Switch). Velkou v´ yhodou tohoto ˇreˇsen´ı je t´emˇeˇr nulov´a doba odpojen´ı z´ateˇze. Toto ˇreˇsen´ı je vˇsak nevhodn´e v popisovan´e aplikaci. D˚ uvodem je, ˇze jsou obsaˇzeny toˇciv´e stroje a je nutn´e vyˇckat na jejich zastaven´ı (ˇreˇsen´ı bez pˇrif´azov´av´an´ı z´ateˇze). Na trhu existuje nˇekolik modul˚ u ˇr´ıdic´ıch kontroler˚ u konstruovan´ ych pˇr´ımo pro ˇr´ızen´ı pˇrep´ınaˇc˚ u. Pˇr´ıkladem m˚ uˇze b´ yt model Lovato RGK popsan´ y na zaˇc´atku pr´ace. Zm´ınˇen´e jednotky maj´ı ovˇsem pouze omezen´e moˇznosti vizualizoce ˇr´ızen´e technologie a jejich ovl´adan´ı je t´eˇz omezen´e.
102
Literatura ´, R., Cagaˇ ˇ´ık, M., Sobot´ık, J., [1] B´ıly s, P., Cagaˇ s, R., Hlad˚ uvka, D., Kolar ´leˇ ´k, M., Zgarba, Z.: ControlWeb 2000, Computer Press, Praha 1999, Za sa ˇ ´c ˇ, Z., Fiedler, P., Kuc ˇera, P., Stohl, [2] Zezulka, F., Brada R.: Programovateln´e automaty, skripta FEKT VUT, Brno 1999, ˇ ´skova ´, M., Smejkal, [3] Martina L.: PLC a automatizace 1, BEN, Praha 1999, Programovateln´e automaty, skripta FEKT VUT, Brno 1999, ˇ L.: PLC a automatizace 2, BEN, Praha 2005, [4] Smejkal, ´, A.: Pˇrehled protokolu MODBUS, Plzeˇ [5] Roneˇ sova n 2005, [on-line], hhttp://home.zcu.cz/ ronesova/bastl/files/modbus.pdfi, [cit. 2008-10-30] [6] WAGO Elektro s.r.o: web firmy a manu´aly k modul˚ um [on-line], hhttp://www.wago.comi, [cit. 2008-10-30] ´ pr ˇ´ıstroje a.s.: web firmy [on-line], hhttp://www.mii.cz/i, [cit. 2008[7] Moravske 10-30] [8] KOHLER Power: web firmy [on-line], hhttp://www.kohlerpower.comi, [cit. 200810-30] [9] WIKIPEDIA: internetov´a otevˇren´a hhttp://www.wikipedia.orgi, [cit. 2008-10-30]
encyklopedie
[on-line],
[10] SOCOMEC Group: web firmy [on-line], hhttp://www.socomec.comi, [cit. 200810-30] [11] LOVATO Electric: web firmy [on-line], hhttp://www.lovatoelectric.comi, [cit. 2008-10-30] [12] Regulacni pohony: Programy pro ˇr´ızen´ı hhttp://www.regulacni-pohony.czi, [cit. 2008-10-30] [13] SNMP [on-line], hhttp://www.fi.muni.cz/ podzim/ct/snmp.htmli, [cit. 2008-10-30]
103
-
CoDeSys
[on-line],
kas/p090/referaty/2007-
104
Pˇ r´ıloha A Obsah pˇ riloˇ zen´ eho CD K t´eto pr´aci je pˇriloˇzeno CD, na kter´em jsou uloˇzeny zdrojov´e k´ody pro • ˇr´ızen´ı rozvadˇeˇc˚ u ATS 1000 a ATS 200 pro PLC . . . rizeni_ATS@081007 • ˇz´ızen´ı nov´e rozvodny pro PLC . . . rizeni_RH@081007 • vizualizace v CW pro panelov´e PC . . . MFCR_@_080618 • zdrojov´e k´ody pro LATEX 2ε a obr´azky tohoto dokumentu
I
