1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra řídicí techniky Diplomová práce Průmyslová komunikace PROFInet 2004 Ondřej Net...
ˇ e vysok´e uˇcen´ı technick´e v Praze Cesk´ Fakulta elektrotechnick´a
Katedra ˇr´ıdic´ı techniky
Diplomov´a pr´ace
Pr˚ umyslov´ a komunikace PROFInet
2004
Ondˇrej Net´ık
Prohl´ aˇ sen´ı: Prohlaˇsuji, ˇze jsem svou diplomovou pr´aci vypracoval samostatnˇe a pouˇzil jsem pouze podklady (literaturu, projekty, SW atd.) uveden´e v pˇriloˇzen´em seznamu. Nem´am z´avaˇzn´ y 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 souvisejc´ı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: ..................................
Abstrakt PROFInet je z pohledu n´avrhu technologie, konfigurovatelnosti a diagnostiky jednotliv´ ych ˇca´st´ı mocn´ y n´astroj pro ˇr´ızen´ı, k pˇrenosu dat vyuˇz´ıv´a standardu Ethernet a TCP-IP, nad nimi je implementov´ana vrstva DCOM kterou je vytvoˇren objektov´ y model PROFInetu. Linux je stabiln´ı, ˇcasem provˇeˇren´ y a volnˇe ˇsiˇriteln´ y operaˇcn´ı syst´em. Spojen´ı PROFInetu a Linuxu d´av´a dobr´ y z´aklad pro pouˇzit´ı v aplikac´ıch pro ˇr´ızen´ı. Tato pr´ace se vˇenuje adaptaci PROFInetu pod operaˇcn´ı syst´em Linux a rozˇsiˇruje ho o webov´e rozhran´ı pro pˇr´ıstup k objekt˚ um PROFInetu protokolem HTTP (webov´ y prohl´ıˇzeˇc) a o webov´e sluˇzby pˇr´ıstupn´e protokolem SOAP pro snadnˇejˇs´ı integraci do manaˇzersk´ ych aplikac´ı.
Abstract PROFInet is powerfull tool for control from viewpoint of design a technologi, configuration and diagnostic. It used Etherned and TCP-IP standard, above them is implemented DCOM layer that create PROFInet model. Linux is stable, time verified and free distributed operating system. Association of PROFInet and Linux are good base for use in aplication of control. This work concered with implementation PROFInet server under Linux and extend it with web interface for access to object of PROFInet with HTTP protocol and webservices for access with SOAP protocol.
Atributy komponenty Akv´arium . . . . . . . . Atributy komponenty Control . . . . . . . . . Adres´aˇrov´a struktura komponenty Akv´arium . Adres´aˇrov´a struktura pro sestaven´ı komponent
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
58 60 62 63
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
´ Uvod P˚ uvodn´ı z´amˇer t´eto pr´ace bylo adaptovat verzi 1.2 (popˇr´ıpadˇe v2.0) PROFInet serveru do operaˇcn´ıho syst´emu Linux s hlavn´ım zamˇeˇren´ım na implementaci Softwarov´eho Realtimu (viz. [4]). L´eto 2003 jsem str´avil ve firmˇe IFAK v Magdeburgu, kde jsem mˇel na t´eto implementaci pracovat. Z d˚ uvodu zdrˇzen´ı specifikace1 PROFInet serveru v2.0 bylo od tohoto z´amˇeru upuˇstˇeno a po dohodˇe s vedouc´ım diplomov´e pr´ace a konzultantem ve firmˇe IFAK se n´apln´ı cel´e pr´ace stala implementace PROFInet serveru pod OS Linux, Webov´e rozhran´ı a Webov´e sluˇzby. Vu ´ vodu cel´e pr´ace bych chtˇel ˇcten´aˇre sezn´amit se z´akladn´ımi vlastnostmi PROFInetu a postupem n´avrhu aplikace. Protoˇze tyto skuteˇcnosti byly dobˇre pops´any v [1], je tato kapitola sp´ıˇse urˇcena k definici pojm˚ u, upozornˇen´ı na odliˇsnosti pˇri pouˇzit´ı a implementov´an´ı PROFInet serveru a vlastn´ı aplikace pod operaˇcn´ım syst´emem Linux. V n´asleduj´ıc´ı kapitole se zamˇeˇr´ıme na popis adaptace PROFInet serveru z platformy operaˇcn´ıho syst´emu Windows do Linuxu. Postup koresponduje s obecn´ ym postupem popsan´ ym v [2]. Dalˇs´ı kapitola rozˇsiˇruje st´avaj´ıc´ı Linuxovou implementaci PROFInet serveru o web rozhran´ı, na kterou navazuje kapitola o webov´ ych sluˇzb´ach, kter´e slouˇz´ı pˇredevˇs´ım k vizualizaci a ovlivnˇen´ı z´akladn´ıch parametr˚ u serveru. V posledn´ı kapitole je uk´azka aplikace na Linuxov´em PROFInet serveru implementov´ana na pr˚ umyslov´em poˇc´ıtaˇci, se znaˇcnˇe omezen´ ymi prostˇredky - model akv´aria. Touto prac´ı bych chtˇel rozˇs´ıˇrit diplomovou pr´aci [1], z kter´e jsem ˇcerpal z´akladn´ı informace. Dalˇs´ımi informaˇcn´ımi zdroji o adaptaci serveru byl pˇredevˇs´ım [2], obecn´e informace o PROFInet serveru jsou specifikov´any v [3], specifikace webov´eho rozhran´ı je pops´ana v [4]. V pr´aci jsou zachov´any nˇekter´e anglick´e n´azvy, pro kter´e neexistuje jednoznaˇcn´ y pˇreklad do ˇcesk´eho jazyka.
1
kterou m´ a na starosti organizace PROFIBUS International
Kapitola 1 PROFInet 1.1
´ Uvod
PROFInet klade vˇetˇs´ı d˚ uraz na n´avrh struktury a funkce cel´eho ˇr´ızen´eho procesu neˇz na implementaci hardwarov´ ych ˇca´st´ı. Komponenta (objekt) pˇredstavuje funkˇcn´ı celek PROFInetu, jeˇz s okol´ım komunikuje pomoc´ı povinnˇe implementovan´ ych rozhran´ı dan´e specifikac´ı [3]. Pro interakci mezi jednotliv´ ymi komponentami PROFInetu se vyuˇz´ıv´a standardu 1 DCOM firmy Microsoft. Ten definuje nad kaˇzdou komponentou jedno nebo v´ıce rozhran´ı, pomoc´ı nichˇz se pˇristupuje k funkc´ım a dat˚ um. DCOM definuje zp˚ usob jak funkce vyvol´avat, ale zp˚ usob jejich implementace je skryt.
1.2
Model PROFInetu
PROFInet Runtime model reprezentuje funkˇcn´ı celky, kter´e jsou fyzicky pˇr´ıtomny v zaˇr´ızen´ı a pˇr´ıstupn´e z okol´ı pomoc´ı definovan´ ych rozhran´ı a metod. PhysicalDevice (oznaˇceno PDev) reprezentuje hardware-poˇc´ıtaˇc nebo PLC. Umoˇzn ˇ uje pˇr´ıstup k s´ıti pomoc´ı IP adresy. Na kaˇzd´em zaˇr´ızen´ı existuje pouze jedno PhysicalDevice (obr. 1.1). PDev obsahuje alespoˇ n jedno LogicalDevice (oznaˇceno LDev), kter´e je tvoˇreno softwarem (firmware), jako autonomn´ı jednotka. Bˇeˇzn´ y pomˇer mezi PDev a LDev je 1:1, coˇz znamen´a, ˇze jeden softwarov´ y program (nebo nˇekolik kooperativnˇe pracuj´ıc´ıch program˚ u) bˇeˇz´ı na jednom hardwaru. LDev nab´ız´ı bˇeˇzn´e automatizaˇcn´ı funkce, jako je identifikace nebo diagnostika zaˇr´ızen´ı. Slouˇz´ı jako v´ ychoz´ı bod (objekt) pro pˇr´ıstup k RTAuto objekt˚ um. ACCO (Active Control Connection Object) objekt implementuje konfigurovateln´a propojen´ı mezi RTAuto (Runtime Automation Object) objekty. RTAuto reprezentuje funkˇcn´ı v´ ykonou ˇca´st zaˇr´ızen´ı (vstupy/v´ ystupy). Na jedno LDev zaˇr´ızen´ı pˇripad´a jeden ACCO objekt. Kaˇzd´emu RTAuto objektu v re´aln´em zaˇr´ızen´ı odpov´ıd´a ES-Auto2 objekt v n´avrhov´em 1 2
Distributed Common Object Model Engineering System, tzn. obraz re´ aln´eho objektu v n´ avrhov´em prostˇred´ı
2
PROFInet
Obr´azek 1.1: Runtime model
prostˇred´ı, LDev zaˇr´ızen´ı v dobˇe n´avrhu odpov´ıd´a ES-Device. D´ıky t´eto reprezentaci m˚ uˇze n´avrh cel´eho syst´emu prob´ıhat bez znalost´ı implementace konkr´etn´ıho zaˇr´ızen´ı, n´avrh´aˇr jen definuje propojen´ı mezi jednotliv´ ymi objekty. IP adresa PROFInet serveru jednoznaˇcnˇe identifikuje PDev zaˇr´ızen´ı, k LDev a k RTAuto objekt˚ um se pˇristupuje pomoc´ı jednoznaˇcn´eho jm´ena definovan´eho v r´amci n´avrhu. Logick´e zaˇr´ızen´ı se m˚ uˇze nach´azet v jednom z n´asleduj´ıc´ıch stav˚ u: Non Existent zaˇr´ızen´ı nen´ı nap´ajeno (neexistuje); Initializing - prob´ıh´a inicializace zaˇr´ızen´ı; Ready zaˇr´ızen´ı je pˇripraveno, v´ ystupy RTAuto zaˇr´ızen´ı jsou v definovan´e hodnotˇe; Operating - pracovn´ı reˇzim zaˇr´ızen´ı; Defect - nastala bl´ıˇze nespecifikovan´a chyba, je nutn´ y vnˇejˇs´ı z´asah.
1.3
COM terminologie
LDev, PDev a RTAuto je v PROFInetu pˇredstavov´an COM3 objektem, kter´ y se skl´ad´a ze dvou z´akladn´ıch ˇca´st´ı, kter´e m˚ uˇzeme od sebe oddˇelit: • interface (rozhran´ı) - zprostˇredkov´av´a pˇr´ıstup k objekt˚ um, je jednoznaˇcnˇe deklarov´ano, nen´ı z´avisl´e na v´ yvojov´em prostˇredku. • implementace - vlastn´ı implementace deklarovan´ ych metod rozhran´ı. Pro specifikaci rozhran´ı COM objektu je pouˇzit Interface Definition Language (IDL jazyk), jehoˇz syntaxe je velice podobn´a jazyku C. Definice rozhran´ı se skl´ad´a z nˇekolika prvk˚ u: 3
Common Object Model
1.3 COM terminologie
3
atribut˚ u rozhran´ı uveden´ ych v hranat´ ych z´avork´ach, kl´ıˇcov´eho slova interface za kter´ ym n´asleduje n´azev rozhran´ı a za znakem “:” jm´eno rodiˇcovsk´eho rozhran´ı. Ve sloˇzen´ ych z´avork´ach je obsaˇzena deklarace metod rozhran´ı. Metody rozhran´ı jsou definov´any jako v´ ystupn´ı (uvozen´e kl´ıˇcov´ ym slovem propget) nebo vstupn´ı (uvozen´e kl´ıˇcov´ ym slovem propput). Popis IDL jazykem je urˇcen pˇredevˇs´ım klient˚ um a proto se na popis obsaˇzen´ y v IDL souboru mus´ıme d´ıvat z pohledu klienta. Proto vstupn´ı metoda, kter´a prov´ad´ı z´apis do COM objektu je definov´ana z pohledu klienta kl´ıˇcov´ ym slovem propput. Pˇr´ıklad definice rozhran´ı COM objektu je na obr. 1.2, v´ıce informac´ı o IDL jazyku [5]. [ object, uuid(4DDFB88B-AD0E-4D65-BDB7-8A0EDEB77501), dual, helpstring("Aqarium Up"), pointer_default(unique) ] interface IAqa1 : IDispatch { // v´ ystupn´ ı metoda [propget] HRESULT pH([out, retval] long *pVal); // vstupn´ ı je souˇ casnˇ e definov´ ana i jako v´ ystupn´ ı metoda // z d˚ uvodu moˇ znosti c ˇten´ ı [propget] HRESULT kysliceni([out, retval] VARIANT_BOOL *pVal); [propput] HRESULT kysliceni([in] VARIANT_BOOL Val); }; Obr´azek 1.2: Definice rozhran´ı v jazyce IDL Argumenty metod jsou naz´ yv´any atributy 4 . Metody umoˇzn ˇ uj´ı serveru nab´ızet sv´e sluˇzby (funkce) klient˚ um. Komunikace mezi serverem a klientem m˚ uˇze prob´ıhat synchronnˇe nebo asynchronnˇe. Asynchronn´ı komunikace se pouˇz´ıv´a pro zpˇetn´e informov´an´ı serveru, ˇze poˇzadovan´a funkce (metoda) na stranˇe klienta skonˇcila (napˇr. ventil dos´ahl polohy zavˇreno). D´ıky asynchronn´ı komunikaci odpad´a komunikace typu polling, server nemus´ı cyklicky testovat stav klienta. Tento zp˚ usob komunikace se v PROFInetu oznaˇcuje event - zas´ıl´an´ı ud´alost´ı.
1.3.1
Rozhran´ı IUnknown
Kaˇzd´e COM rozhran´ı je odvozeno od z´akladn´ıho rozhran´ı, od tzv. IUnknown rozhran´ı. Obsahuje pˇresnˇe tˇri metody: AddRef(), Release() a QueryInterface(). COM definuje tato pravidla, kter´a urˇcuj´ı ˇzivotnost (lifetime) objektu: • pokud je vytvoˇrena dalˇs´ı reference na objekt, mus´ı b´ yt zavol´ana metoda AddRef() 4
v anglick´em jazyku property
4
PROFInet • pokud je ruˇsena reference na objekt, mus´ı b´ yt zavol´ana metoda Release()
N´avratov´a hodnota je poˇcet referenc´ı na konkr´etn´ı objekt, pokud dos´ahne nuly, objekt nen´ı uˇz´ıv´an ˇza´dn´ ym jin´ ym objektem a je odstranˇen z pamˇeti. QueryInterface() - metoda pro dynamick´e proch´azen´ı rozhran´ı, jako parametr ji pˇred´ame jm´eno rozhran´ı, na kter´e chceme z´ıskat ukazatel, pokud toto rozhran´ı neexistuje, je navr´acen chybov´ y k´od.
1.3.2
Rozhran´ı IDispatch
PROFInet objekty vedle povinn´eho rozhran´ı IUknown implementuj´ı dalˇs´ı standardn´ı rozhran´ı IDispatch, kter´e slouˇz´ı k nepˇr´ım´emu vol´an´ı metod objektu. Toto rozhran´ı definuje celkem ˇctyˇri metody, nejd˚ uleˇzitˇejˇs´ı metoda invoke() a GetIDsOfName(). Klientsk´a aplikace zn´a pouze jm´eno volan´e funkce, kter´e pˇred´a jako parametr funkci GetIDsOfName(). Funkce vyhled´a v tabulce uloˇzen´e v komponentˇe jak´e jedineˇcn´e ˇc´ıslo DispID (v r´amci jedn´e komponenty) odpov´ıd´a zadan´emu jm´enu funkce a vr´at´ı jej klientovi. Se z´ıskan´ ym DispID n´aslednˇe vol´a metodu Invoke(), kter´a provede poˇzadovanou funkci. D´ıky tomuto syst´emu lze v programu volat funkce, kter´e v dobˇe pˇrekladu nejsou zn´amy5 . V´ıce informac´ı [5]. COM model definuje tyto tˇri komunikaˇcn´ı cesty: • InProc - komunikace v r´amci jednoho procesu • InterProc - mezi dvˇema procesy ale v r´amci jednoho ”poˇc´ıtaˇce” • Remote - mezi dvˇema zaˇr´ızen´ımi (poˇc´ıtaˇci) pomoc´ı rozˇs´ıˇren´eho protokolu COM, naz´ yvan´eho DCOM. V PROFInetu je komunikace typu InProc pˇrevedena na pˇr´ım´e vol´an´ı funkce pomoc´ı tabulky virtu´aln´ıch funkc´ı (obr. 1.3).
Obr´azek 1.3: Vol´an´ı metod v r´amci jednoho procesu - InProc
5
tento zp˚ usob vol´ an´ı se oznaˇcuje OLE Automation
1.4 Rozhran´ı PROFInetu
1.4
5
Rozhran´ı PROFInetu
PDev, LDev a RTAuto objekty maj´ı definov´ano rozhran´ı ICBABrowse pomoc´ı nˇehoˇz lze z´ıskat ukazatel na n´asleduj´ıc´ı objekt v hierarchii (obr. 1.4). Nad objektem RTAuto je definov´ano tzv. User Specific Interface, kter´ ym je d´an prostor pro definici vlastn´ıch rozhran´ı (funkc´ı), kter´a definuj´ı funkci cel´eho serveru. Kaˇzd´ y objekt m´a z´akladn´ı rozhran´ı (ICBAPhysicalDevice, ICBALogicalDevice...), na kter´e z´ısk´ame ukazatel pˇri pˇrechodu z nadˇrazen´eho objektu pomoc´ı rozhran´ı ICBABrowse. Toto rozhran´ı poskytuje z´akladn´ı informace o objektu, jako je: n´azev, v´ yrobce, seriov´e ˇc´ıslo, datum sestaven´ı atp. Protoˇze popis jednotliv´ ych rozhran´ı a pochopen´ı jejich funkce je d˚ uleˇzit´ y pro dalˇs´ı pr´aci, n´asleduje jejich kr´atk´ y popis. V´ıce informac´ı lze z´ıskat v [3]. Verze 2.0 PROFInet serveru rozˇsiˇruje sadu rozhran´ı o dalˇs´ı, viz [4].
Obr´azek 1.4: Seznam rozhran´ı nad objekty PROFInetu
Physical Device - ICBAPhysicalDevice - informace o hardwaru, v´ ychoz´ı bod pro objekty LDev.
6
PROFInet - ICBABrowse - pˇrechod na LDev zaˇr´ızen´ı.
Logical Device - ICBALogicalDevice - informace o softwaru, v´ ychoz´ı bod pro objekty RTAuto a ACCO. - ICBABrowse - pˇrechod na objekty RTAuto - ICBAState - ˇcten´ı stavu LDev objektu. - ICBATime - vlastn´ı ˇcas LDev objektu. - ICBAGroupError - diagnostika zaˇr´ızen´ı (rozebr´ana v pr´aci [1]). RTAuto Objekt - ICBARTAuto - identifikace objektu. - ICBABrowse - pˇrechod na User Specific Interface. - User Specific Interface - uˇzivatelem definovan´e rozhran´ı pracuj´ıc´ı nad atributy objektu. ACCO Objekt - ICBAAccoMgt - tvorba a ruˇsen´ı propojen´ı mezi objekty. - ICBAAccoServer - konfigurace poskytovatele dat. - ICBAAccoCallback - spravuje asynchronn´ı vyvol´an´ı ud´alosti na stranˇe pˇr´ıjemce dat. - ICBAAccoSync - synchronn´ı ˇcten´ı/z´apis atribut˚ u. - ICBAGroupError - diagnostika (rozebr´ana v pr´aci [1]).
1.5
Komunikace
Pˇri komunikaci typu InterProc a Remote Call (obr. 1.5) je pouˇzit model vol´an´ı proxy/stub (viz. [5]). Proxy se smˇerem ke klientovi chov´a jako origin´aln´ı volan´ y objekt, jako by byl na lok´aln´ım zaˇr´ızen´ı. Stub vykon´av´a ˇra´dn´e vol´an´ı objektu na stranˇe serveru a n´avratovou hodnotu vrac´ı pˇres RPC a proxy zpˇet klientovi. Spojen´ı pˇres proxy/stub pomoci RPC obstar´av´a COM, je zcela transparentn´ı.
1.5 Komunikace
7
Obr´azek 1.5: Vol´an´ı metod mezi procesy - InterProc a Remote Call
1.5.1
ACCO objekt
ACCO objekt vytv´aˇr´ı a udrˇzuje propojen´ı mezi RTAuto objekty. Tyto propojen´ı jsou vytv´aˇreny a ruˇseny dynamicky za bˇehu serveru, jsou nahr´av´any z konfiguraˇcn´ıho a monitorovac´ıho softwaru iMap. Data jsou pˇren´aˇsena v definovan´ ych ˇcasov´ ych intervalech (QoS 6 ), spoleˇcnˇe s kvalitativn´ı 7 zn´amkou (QC ). Objekty, mezi kter´ ymi prob´ıh´a pˇrenos dat jsou oznaˇcov´any jako provider zdroj dat a consumer - pˇr´ıjemce dat. Inici´atorem pˇri vytv´aˇren´ı spojen´ı je zdroj dat, datov´e typy pˇren´aˇsen´ ych dat mus´ı b´ yt stejn´e jak u poskytovatele tak u pˇr´ıjemce dat. Pˇri naˇcten´ı konfigurace rozhran´ı z IDL souboru mus´ı m´ıt pro poskytovatele dat atribut [propget], pro pˇr´ıjemce dat [propput]. Pˇr´ıjemce i poskytovatel si udrˇzuje vlastn´ı z´aznamy o vytvoˇren´ ych spojen´ı. Vytv´aˇret/ruˇsit spojen´ı lze pomoc´ı rozhran´ı ACCO objektu ICBAAccoMgt, konfigurace jiˇz vytvoˇren´eho spojen´ı (napˇr. zmˇena QoS) se mˇen´ı pomoc´ı rozhran´ı ICBAAccoServer. Rozhran´ı ICBAAccoCallBack obsahuje funkci, kterou poskytovatel vol´a na stranˇe pˇr´ıjemce pˇri ˇza´dosti o pˇrenos hodnoty.
1.5.2
Marshalling
Marshalling prov´ad´ı konverzi argument˚ u pˇred´avan´ ych metodˇe do spr´avn´eho tvaru pro dan´e zaˇr´ızen´ı. Jedn´a se o konverze typu little/big endian, k´odov´an´ı ˇc´ısel apod. D´ale se star´a o vytv´aˇren´ı proxy na stranˇe klienta a stub na stranˇe serveru pro volan´e metody. Jejich strukturu zn´a z popisu rozhran´ı (metod) IDL jazykem. Existuj´ı dva druhy marshallingu: - universal marshalling - pouˇz´ıv´an v Javˇe, Visual Basicu. Pro vol´an´ı metod definovan´e v rozhran´ı pouˇz´ıv´a IDispatch rozhran´ı. - standard marshalling - pouˇz´ıv´an v C/C++. V PROFInetu je pouˇzit standardn´ı marshalling, kter´ y vyuˇz´ıv´a standardu RPC. Rozhran´ı objekt˚ u PDev, LDev a RTAuto jsou definovany jako OLE Automation - pˇr´ıstup je moˇzn´ y 6 7
Quality of Service Quality Code
8
PROFInet
pomoc´ı IDispatch interface, narozd´ıl od objektu ACCO8 , ke kter´emu se m˚ uˇze pˇristupovat jen pˇri pouˇzit´ı standardn´ıho marshallingu - nem´a rozhran´ı IDispatch. Aby mohly jazyky jako je Visual Basic k ACCO objektu pˇristupovat je nutn´e pouˇz´ıt tzv. Automation Wrapper, kter´ y Visual Basic aplikaci poskytne IDispatch rozhran´ı. Zp˚ usob konverze argument˚ u je podrobnˇeji pops´an v kap. 2.6. V´ıce informac´ı lze z´ıskat v [3] a [2].
1.6
Shrnut´ı
Popsan´e vlastnosti PROFInet serveru jsou souˇca´st´ı specifikace, ale v pouˇzit´e verzi PROFInet serveru 1.2 nejsou zdaleka vˇsechny implementov´any. Nˇekolik z´asadn´ıch omezen´ı t´eto verze: - moˇzn´ y pomˇer mezi LDev a RTAuto objektem je pouze 1:1. - nen´ı podporov´ana komunikace typu zas´ıl´ an´ı zpr´ av.
8 nem´ a OLE Automation rozhran´ı, d´ıky omezen´e mnoˇzinˇe datov´ ych typ˚ u, kter´e tento typ marshallingu umoˇzn ˇuje
Kapitola 2 PROFInet a Linux V t´eto kapitole lze nal´ezt informace o adaptaci PROFInet serveru pod operaˇcn´ı syst´em Linux. Je zde nast´ınˇen princip funkce jednotliv´ ych ˇca´st´ı serveru (base, rpc, dcomrt, dcomap) a jejich vz´ajemn´a spolupr´ace. Tato fakta se op´ıraj´ı pˇrev´aˇznˇe o dokumentaci [2] a vlastn´ı zkuˇsenost s adaptac´ı.
2.1
´ Uvod
Operaˇcn´ı syst´em Linux je jiˇz ˇcasem provˇeˇren´ y, stabiln´ı operaˇcn´ı syst´em, kter´ y 1 oproti jin´ ym operaˇcn´ım syst´em˚ um je volnˇe ˇsiˇriteln´ y pod licenc´ı GPL . Monolitick´e j´adro operaˇcn´ıho syst´emu, kter´e oddˇeluje hardware poˇc´ıtaˇce od aplikac´ı, je velice dobˇre ˇsk´alovateln´e. D´ıky tomu lze Linux provozovat i na poˇc´ıtaˇc´ıch s velice omezen´ ymi syst´emov´ ymi zdroji. PROFInet lze obecnˇe pˇrev´est do libovoln´eho operaˇcn´ıho syst´emu, kter´ y m´a ANSI C pˇrekladaˇc, umoˇzn ˇ uje bˇeh v´ıce vl´aknov´ ych aplikac´ı (multi-threading) a m´a implementov´anu TCP/IP vrstvu (obr. 2.1). Vrstva TCP-IP nen´ı souˇca´st´ı PROFInet implementace. Pˇr´ıstup k TCP-IP vrstvˇe je v Linuxu moˇzn´ y pomoc´ı BSD socket interface, kter´ y je souˇca´st´ı knihovny Glibc. Jakoˇzto kaˇzd´ y Unixov´ y syst´em podporuje multi-threading (knihovna pthread). Jako pˇrekladaˇc ANSI C jazyka lze pouˇz´ıt gcc [8]. Zdrojov´ y k´od PROFInet serveru lze z´ıskat z web str´anek spoleˇcnosti PROFIBUS Interˇ ast national http://www.profibus.com2 , tato ˇca´st k´odu je na obr. 2.1 zv´ yraznˇena modˇre. C´ oznaˇcena zelenˇe, je specifick´a pro konkr´etn´ı platformu, pro konkr´etn´ı operaˇcn´ı syst´em. Prim´arnˇe je PROFInet server vyv´ıjen ve verzi pro operaˇcn´ı syst´em VxWorks a Windows, ve kter´e je tak´e dostupn´ y na web str´ank´ach firmy PROFIBUS. Verze pro operaˇcn´ı syst´em Linux se objevila aˇz ned´avno.
10
PROFInet a Linux
Aplication Aplikace & OS, nejsou soucasti PROFInet Runtime Source
System Integration
Operating System (Linux)
User Interface RTAuto
DCOM
PDev
Casti, ktere je nutne portovat pro konkretni operacni system
Na obr. 2.1 je zn´azornˇeno, kter´e komponenty3 PROFInet serveru mus´ı b´ yt adaptov´any v z´avislosti na c´ılov´e platformˇe. Tyto ˇca´sti jsou od j´adra PROFInetu oddˇeleny, jsou ve zvl´aˇstn´ıch adres´aˇr´ıch, pojmenovan´ ych podle c´ılov´e platformy (obr. 2.2). Jednotliv´e komponenty PROFInet serveru jsou od sebe oddˇeleny podle funkc´ı, kter´e vykon´avaj´ı (detailnˇeji pops´any v n´asleduj´ıc´ım textu): - base - trasovac´ı syst´em PROFInetu, spoleˇcn´e funkce vˇsem ostatn´ım ˇca´stem. - rpc - implementace RPC4 syst´emu. - dcomrt - implementace DCOM vrstvy. - automarshall - typov´e konverze. - acco - realizuje a udrˇzuje propojen´ı mez´ı objekty. - device - podp˚ urn´e funkce pro vytvoˇren´ı modelu PROFInetu (PDev, LDev a RTAuto objekty). 1
General Public Licence pˇr´ıstupn´e jen pro ˇcleny organizace 3 v´ yraz komponenta je v PROFInet terminologii pouˇz´ıv´ ano jak pro oznaˇcen´ı jednotliv´ ych ˇca ´st´ı serveru (RPC, BASE, DCOM, Marshaller) tak i pro cel´ y PROFInet server jako d´ılˇc´ı ˇca ´st vˇetˇs´ı technologie. 4 Remote Procedure Call 2
2.3 Komponenta BASE
11
Obr´azek 2.2: Struktura adres´aˇr˚ u
Kaˇzd´a z komponent m´a svoji vlastn´ı adaptaci do syst´emu, na kter´em bude provo´ zov´ana nez´avisle na ostatn´ıch komponent´ach (ˇsed´e adres´aˇre na obr. 2.2). Upravy prov´adˇen´e program´atorem pˇri pˇrevodu softwaru na jinou platformu jsou povoleny pouze v tˇechto adres´aˇr´ıch.
2.3
Komponenta BASE
Jsou zde definov´ana pˇredevˇs´ım makra pro pr´aci s kritick´ ymi sekcemi, s alokac´ı pamˇeti, s ˇretˇezci. D´ale je zde implementov´an trasovac´ı syst´em, kter´ y se z ostatn´ıch vrstev vol´a pomoc´ı maker, podle charakteru ˇza´dan´eho v´ ypisu a d˚ uleˇzitosti.
2.3.1
Kritick´ e sekce
Pro pr´aci s kritick´ ymi sekcemi byly zvoleny tzv. mutexy standartu POSIX [10], [9], ty umoˇzn ˇ uj´ı uzamknout objekt, k nˇemuˇz pak m´a pˇr´ıstup jen jedno vl´akno. Dalˇs´ı alternativou je pouˇzit´ı semafor˚ u.
12
PROFInet a Linux
Pro pr´aci s mutexy jsou definov´any n´asleduj´ıc´ı funkce, kaˇzd´a z komponent PROFInetu si zav´ad´ı sv´a pomocn´a makra, kter´a jsou smˇeˇrov´ana na tyto funkce. Argumentem tˇechto funkc´ı je datov´a struktura, kter´a m´a prvky typu: pthread mutex t (vlastn´ı mutex) a pthread t (vl´akno, kter´e vlastn´ı mutex - v souˇcasn´e verzi PROFInetu (v1.2) nepouˇzito). InicializeCriticalSection(pCritSec) - inicializuje mutex. DeleteCriticalSection(pCritSec) - Ruˇs´ı mutex. EnterCriticalSection(pCritSec) - Zamkne (mutex) kritickou sekci pro ostatn´ı procesy, ostatn´ı procesy mus´ı ˇcekat na uvolnˇen´ı. LeaveCriticalSection(pCritSec) - Odemˇcen´ı kritick´e sekce.
2.3.2
Trasovac´ı syst´ em
Pro kaˇzdou komponentu serveru lze nastavit jednu z u ´ rovn´ı trasovac´ıch zpr´av. Jsou definov´any tyto u ´ rovnˇe (uspoˇra´d´ano sestupnˇe) trasovac´ıch zpr´av a chybov´ ych hl´aˇsen´ı: FATAL, ERROR, UNEXP, WARN, NOTE, CHAT. Pˇri zpravˇe typu FATAL je v´aˇznˇe naruˇsen chod syst´emu, nelze pokraˇcovat v ˇcinnosti. Naopak zpr´ava typu CHAT je informativn´ı a m´a sp´ıˇse v´ yznam pro ladˇen´ı syst´emu. Kaˇzd´a komponenta PROFInetu vkl´ad´a hlaviˇckov´ y soubor podle sv´eho jm´ena ( xxxtrc.h, kde xxx je jm´eno komponenty). Kaˇzd´ y soubor komponenty m´a definov´ano specifick´e makro (obr. 2.3), podle kter´eho se v xxxtrc.h urˇc´ı, o kter´ y soubor se jedn´a. Nastav´ı se makra: CBA TRACE FILE ID a CBA TRACE FILE NAME. D´ale se nastav´ı u ´ roveˇ n trasov´an´ı cel´e komponenty makrem CBA TRACE LEVEL a nastav´ı se pomocn´e makro CBA COMPONENT XXX pro hlaviˇckov´ y soubor gtrace.h. Do souboru xxxrc.h se vkl´ad´a dalˇs´ı soubor gtrace.h ve kter´em se nadefinuje podle jm´ena komponenty makra CBA TRACE COMPONENT NAME a CBA TRACE COMPONENT ID spoleˇcn´e vˇsem soubor˚ um komponenty. D´ıky tomuto syt´emu lze snadno v trasovac´ıch v´ ypisech uv´adˇet n´azev komponenty, jm´eno souboru odkud zpr´ava poch´az´ı a volit d˚ uleˇzitost trasovac´ıch v´ ypis˚ u pro kaˇzdou z komponent. Na obr. 2.3 je pˇr´ıklad definice u ´ rovnˇe trasovac´ıch hl´aˇsen´ı pro komponentu DCOM (v hierarchii adres´aˇr˚ u oznaˇcena jako DCOMRT). Soubor activate.c nastav´ı specifick´e makro a vloˇz´ı do sv´e hlaviˇcky soubor dcomtrc.h kter´ y vkl´adaj´ı i ostatn´ı zdrojov´e soubory komponenty. Dojde k definici prav´eho jm´ena souboru, kter´e se vyuˇzije v trasovac´ıch hl´aˇsen´ıch a nastav´ı se trasovac´ı u ´ roveˇ n, d´ale se vloˇz´ı soubor gtrace.h, kde se nastav´ı jm´eno komponenty. Trasovac´ı v´ ypis se vol´a makrem: CBA TRACE X(), kde X je poˇcet argument˚ u. Pokud je X rovn´e nule, m´a funkce argumenty: LEVEL - ud´avaj´ıc´ı uroveˇ n t´eto hl´aˇsky a MESSAGE ˇ ıslo X ud´av´a poˇcet dalˇs´ıch argument˚ - zpr´ava, kter´a se zobraz´ı. C´ u, kter´e se vytisknou ve zpr´avˇe (stejn´a syntaxe jako u pˇr´ıkazu printf()). Funkce definovan´e v t´eto komponentˇe tvoˇr´ı z´aklad pro ostatn´ı komponenty PROFInetu. Pro bliˇzˇs´ı informace doporuˇcuji nahl´ednout do zdrojov´eho k´odu t´eto komponenty (konkr´etn´ı soubory uvedeny n´ıˇze).
Obr´azek 2.3: Princip funkce trasovac´ıho syst´emu
Soubory urˇ cen´ e pro adaptaci ./v1.2-src/base/test/linux/cfg trccfg.h trccfg.c basecfg.h
2.4
Komponenta RPC
Na program´atorovi je napojit implementovanou TCP/IP vrstvu operaˇcn´ıho syst´emu na RPC5 vrstvu PROFInetu. Stavy vyvolan´e na TCP/IP vrstvˇe jsou do RPC vrstvy pˇred´av´any pomoc´ı metod: • OnConnectInd() - indikace ˇza´dosti o nov´e pˇripojen´ı. • OnConnectCnf() - pˇripojen´ı vytvoˇreno. • OnTCPDataInd() - indikace dat na soketu. • OnTCPClose() - klient uzavˇrel spojen´ı. RPC s TCP/IP vrstvou komunikuje pomoc´ı metod: • RPC CONNECT() - ˇza´dost o vytvoˇren´ı nov´eho komunikaˇcn´ıho soketu. • RPC SEND() - posl´an´ı dat. 5
Remote Procedure Call
14
PROFInet a Linux • RPC CLOSESOCKET() - uzavˇren´ı soketu.
d´ale je nutn´e implementovat komplexnˇejˇs´ı metody, nejd˚ uleˇzitˇejˇs´ı z nich: • RpcSysTCP Listen() - vytvoˇr´ı listen soket, na kter´em server pˇrij´ım´a poˇzadavky a proces Listen Thread, kter´ y ho obsluhuje. • RpcSysTCP Unlisten() - zavˇre listen soket.
RPC Listen Thread
Listen Soket ˇza ´dost o nov´e spojen´ı
Receive Thread
soket
RPC
ACCEPT_NOTIFY accept() nov´ y soket vytvoˇr doˇcasn´ y thread
OnTCPConnecInd read() OnTCPDataInd read()
OnTCPClose zavˇre spojen´ı
thread exit
ˇ adost o nov´e pˇripojen´ı Obr´azek 2.4: Z´
Pˇr´ıchoz´ı spojen´ı jsou obsluhov´any samostatn´ ym procesem Listen Thread() (obr. 2.4)6 , kter´ y je spuˇstˇen pˇri startu serveru metodou RpcSysCreateActiveSocket(). Pˇri ˇza´dosti o nov´e pˇripojen´ı vytvoˇr´ı Listen Thread() dalˇs´ı proces Receive thread(), kter´ y pˇreˇcte data z pˇr´ıchoz´ıho spojen´ı a skonˇc´ı. Pˇri vytvoˇren´ı tohoto vl´akna je vrstva RPC informov´ana vol´an´ım metody OnTCPConnectInd() o nov´em spojen´ı a metodou OnTCPDataInd() o datech na konkretn´ım soketu obsluhovan´ ym pˇr´ısluˇsn´ ym Receive thread(). Spojen´ı je ukonˇceno vzd´alen´ ym klientem, kter´ y ˇza´dal o pˇripojen´ı nebo RPC vrstvou, metodou OnTCPClose(). Pokud chce server poslat data klientovi, vytvoˇr´ı metoda RPC CONNECT() aktivn´ı ´ eˇsn´e vytvoˇren´ı tohoto soket a proces (ReceiveThread()), kter´ y tento soket obsluhuje. Uspˇ soketu je pˇred´ano RPC vrstvˇe metodou OnTCPConnectCnf(). Data jsou pos´ıl´ana metodou RPC SEND() (obr. 2.5). 6
ˇca ´st, kter´ a se mus´ı adaptovat podle c´ılov´e platformy je na n´ asleduj´ıc´ıch obr´ azc´ıch zv´ yraznˇena r˚ uˇzovˇe
2.5 Komponenta DCOM
15 system. adaptace
RPC
nav´ az´ an´ı spojen´ı
RPC_CONNECT
Receive Thread
Soket
vytvoˇr doˇcasn´ y
thread
OnTCPConnectCnf
vytvoˇr soket
read()
OnTCPDataInd
RPC_SEND posl´ an´ı
send()
dat
Obr´azek 2.5: Aktivn´ı pˇripojen´ı
Soubory urˇ cen´ e pro adaptaci ./v1.2-src/rpc/test/linux/ rpc cfg.h rpc cfg.c
2.5
Komponenta DCOM
PROFInet server je navrˇzen tak, aby mohl b´ yt implementov´an i pod syst´emy, kde nen´ı dostupn´ y DCOM, proto pˇrin´aˇs´ı vlastn´ı implementaci vrstvy DCOM. Na syst´emech, kde se DCOM nach´az´ı, mus´ı b´ yt vypnut, aby byl dostupn´ y standartnˇe definovan´ y port pro DCOM, port 135. Na Linuxov´em syst´emu mus´ı b´ yt PROFInet server spuˇstˇen s pr´avy uˇzivatele root, protoˇze bˇeˇzn´ y uˇzivatel nem˚ uˇze otevˇr´ıt port s ˇc´ıslem niˇzˇs´ım jak 1024. Budouc´ı verze PROFInet serveru (v2.0) by mˇela umˇet vyuˇz´ıvat implementovan´ y DCOM v syst´emech MS Windows 2000, PROFInet server se bude chovat jako standardn´ı COM aplikace. Program´ator mus´ı adaptovat nˇekolik funkc´ı (sekvenc´ı) DCOM vrstvy (obr. 2.6): • Inicializace DCOM vrstvy (sekv. I, obr. 2.6). Vytvoˇr´ı propojen´ı s niˇzˇs´ı RPC vrstvou. • Spuˇstˇen´ı DCOM (sekv. II, obr. 2.6). Vytvoˇr´ı server soket na portu 135. • Zavˇren´ı DCOM (sekv. III, obr. 2.6). Zastav´ı DComPingThread a zavol´a metodu DComClose vrstvy DCOM. • Implementov´an´ı ˇcasovaˇce (Timer) (sekv. IV, obr. 2.6) pro cyklickou kontrolu dostupnosti objekt˚ u. Timer ˇreˇsen jako samostatn´ y proces DComPingThread, kter´ y periodicky vol´a funkci DComPingObject. Funkce jsou vol´any z nadˇrazen´e aplikaˇcn´ı vrstvy (pˇr´ımo z hlavn´ı main() funkce) pomoc´ı metod DComOsInit(), DComOsOpen() a DComOsClose().
16
PROFInet a Linux Nadˇrazen´ a aplikaˇcn´ı
vrstva DComOsInit I.
DCOM adaptace
DCOM Ping Thread
PROFInet DCOM
StartDComTask DComInit
DComOsOpen DComOpen
II. DComOsClose
DComClose
III.
IV.
Timer
EVENT
DComPingObjects
Obr´azek 2.6: Sekvence DCOM vrstvy
Soubory urˇ cen´ e pro adaptaci ./v1.2-src/dcomrt/test/linux/cfg dcomcfg.h dcomcfg.c
2.6
Komponenta Automarshal
Automarshaller vytv´aˇr´ı proxy a stub rozhran´ı pro vˇsechny metody popsan´e IDL souborem. K´od pro proxy a stub je z IDL souboru generov´an MIDL7 kompil´atorem a upraven programem TypeLib converter (je souˇca´st´ı profinetu), pak je staticky zahrnut do k´odu serveru.
2.6.1
Inline assembler
Pˇrev´aˇzn´a ˇca´st k´odu urˇcen´a k adaptaci je v inline8 asembleru. Linuxov´ y inline asembler pouˇz´ıv´a AT&T syntaxi [6], kter´a se od intelovsk´eho asembleru pouˇz´ıvan´eho v syst´emu Windows pˇredevˇs´ım odliˇsuje v tˇechto bodech: - poˇrad´ım parametr˚ u (nejprve zdroj, pak c´ıl). - konstantn´ı parametry uvozeny znakem $. - nutnost´ı ud´avat datov´ y typ parametr˚ u. - syntaxe adresov´an´ı pamˇeti je zcela odliˇsn´a. 7 8
Microsoft IDL compiler asembler, kter´ y je pˇr´ımo vkl´ ad´ an do zdrojov´eho k´ odu jazyka C
2.6 Komponenta Automarshal
17
Na obr´azku 2.8 je pˇr´ıklad nejprve v assembleru itelovsk´em a pak v asembleru AT&T. Samotn´a syntaxe assembleru AT&T je naznaˇcena na obr´azku 2.7. __asm__ __volatile__ ("assembler k´ od" : mapov´ an´ ı v´ ystupn´ ıch promˇ enn´ ych : mapov´ an´ ı vstupn´ ıch promˇ enn´ ych : seznam modifikovan´ ych registr˚ u, seznam modifikovan´ e pamˇ eti ); Obr´azek 2.7: Syntaxe AT&T assembleru Kl´ıˇcov´e slovo volatile ˇr´ık´a pˇrekladaˇci, aby n´ami zapsan´ y k´od v assembleru d´ale neoptimalizoval. Na promˇenn´e pouˇzit´e v jazyku C se v inline assembleru odk´aˇzeme pomoc´ı z´apisu %x, kde x urˇcuje poˇrad´ı promˇenn´e v seznamu mapovan´ ych promˇenn´ ych v assembleru (obr. 2.7). Znak %% uvozuje jm´ena registr˚ u. V z´apisu mapovan´ ych promˇenn´ ych lze pouˇz´ıt dalˇs´ıch atribut˚ u (v naˇsem pˇr´ıkladˇe ”g”), kter´e slouˇz´ı zejm´ena k optimalizaci v´ ysledn´eho k´odu pˇrekladaˇcem. Windows: Linux:
asm {mov edx, size}; __asm__ __volatile__ ("movl %0, %%edx": :"g"(size):"%edx"); Obr´azek 2.8: pˇr´ıklad inline assembleru v syst´emu Windows a Linux
D˚ uvodem pouˇzit´ı tak znaˇcn´e ˇca´sti k´odu v assembleru je, ˇze potˇrebujeme m´ıt u ´ plnou kontrolu nad vol´an´ım funkc´ı, pomoc´ı asembleru nahrad´ıme ˇca´st, kterou za n´as jinak dˇel´a pˇrekladaˇc jazyka C utomaticky (tj. pˇrekop´ırov´an´ı parametr˚ u metody na z´asobn´ık, zavol´an´ı metody, vr´acen´ı n´avratov´e hodnoty funkce).
2.6.2
Konfigurace
Automarshaller lze konfigurovat n´asleduj´ıc´ımi makry, jejichˇz nastaven´ı mus´ı korespondovat s moˇznostmi c´ılov´eho syst´emu: - AM MAX ARGUMENTS - definuje maxim´aln´ı poˇcet argument˚ u metod, implicitnˇe nastaven na 16. - AM MAX COMPONENTS - maxim´aln´ı poˇcet prvk˚ u v datov´e struktuˇre. - AM USE FLOATINPOINT - zapnout podporu ˇc´ısel s pohyblivou desetinou ˇca´rkou, implicitnˇe povoleno. - AM USE INT64 - podpora 64-bitov´eho datov´eho typu integer, implicitnˇe zak´az´ano. - AM CLIENT HEAP SIZE, AM SERVER HEAP SIZE - velikost heap pamˇeti pro marshalling, implicitnˇe 1kb.
18
PROFInet a Linux n´ azev v marshalleru BYTE WORD DWORD FLOAT BOOL UINT QWORD
dat. typ v Linux unsigned char unsigned short unsigned int float unsigned short unsigned int pomocn´a struktura
Tabulka 2.1: Datov´e typy
Dalˇs´ım krokem je sjednocen´ı datov´ ych typ˚ u (tab. 2.1) mezi r˚ uzn´ ymi platformami. Datov´ y typ QWORD (64bit) je v operaˇcn´ım syst´emu Linux implementov´an jako struktura s dvˇema prvky - vyˇsˇs´ı a niˇzˇs´ı DWORD (dvˇe samostatn´e promˇenn´e o 32bitech). Pˇri vol´an´ı metody deklarovan´e pomoc´ı IDL jazyka: HRESULT LogicalDevice([in] BSTR Name, [out, retval] ICBALogicalDevice **ppLDev); je stav na z´asobn´ıku naznaˇcen v tab. 2.2. Automarshaler ukl´ad´a parametry metody na z´asobn´ık n´asleduj´ıc´ım zp˚ usobem: • promˇ enn´ a o velikosti do 4 byte - promˇenn´e typu signed/unsigned char, short, long, float a ukazatele jsou uloˇzeny jako typ DWORD (double word). • promˇ enn´ a o velikosti 8 byte - promˇenn´e typu double a date jsou uloˇzeny jako typ dvou DWORD. • datov´ a struktura - ukl´ad´a se jen pointer na tuto strukturu. adr. na z´ asob. z´asobn´ık z´asobn´ık - 1 z´asobn´ık - 2 z´asobn´ık - 3
jm´ eno parametru ICBALogicalDevice **pLDev BSTR Name ukazatel na rozhran´ı n´avratov´a adresa metody
uloˇ zen´ y typ DWORD - ukazatel LDev DWORD - ukazatel na Name DWORD DWORD
Tabulka 2.2: Stav z´asobn´ıku pˇri vol´an´ı metody Adaptace funkc´ı a maker pomoc´ı inline assembleru: • AM InterlockedIncrement - prov´ad´ı inkrementaci promˇenn´e, pˇriˇcemˇz je zaruˇcena exkluzivita pˇr´ıstupu, opakem je funkce AM InterlockedDecrement. • FORMAT IID - prov´ad´ı form´atov´an´ı identifik´atoru rozhran´ı do srozumiteln´e textov´e podoby.
2.7 ACCO objekt
19
• AM DEFINE PARBUFFER(par, nArguments) - prov´ad´ı alokaci pole typu DWORD o velikosti nArguments, vrac´ı pointer par ukazuj´ıc´ı na jeho zaˇca´tek. nuje tabulku 2.2, tuto funkci nen´ı nutno adaptovat, • AM UnMarshalParam - vyplˇ uvedena jen pro u ´ plnost. • ASM CALL VOID FUNC PAR(func, par1, parBuffer) - prov´ad´ı vol´an´ı funkce urˇcen´e ukazatelem func s polem argument˚ u na kter´e ukazuje ukazatel parBuffer 9 , na prvn´ı z argument˚ u metody ukazuje par1. Proces Marshallingu je skonˇcen vytvoˇren´ım pole (tab. 2.2) o maxim´aln´ı velikosti AM MAX ARGUMENTS typu DWORD s hodnotami (s ukazateli), kter´e obsahuj´ı argumenty metody, ukazatel na rozhran´ı ke kter´emu metoda pˇr´ısluˇs´ı a n´avratov´e adresy. V´ıce informac´ı lze z´ıskat v [2] a pˇr´ım´ ym studiem zdrojov´ ych soubor˚ u marshalleru.
Soubory urˇ cen´ e pro adaptaci ./v1.2-src/dcomap/test/linux/cfg am cfg.h am cfg.c
2.7
ACCO objekt
Acco objekt, kter´ y vytv´aˇr´ı, ruˇs´ı a udrˇzuje propojen´ı mezi RTAuto objekty je snadno adaptov´an do Linuxu. Je zde jen nˇekolik ˇcasov´ ych konstant, kter´e mus´ı b´ yt konfigurov´any (v souboru accocfg.h) jako je minim´aln´ı hodnota pro QoS, ˇcasov´e meze pro ruˇsen´ı spojen´ı atp. V [2] je doporuˇceno zachovat pˇrednastaven´e hodnoty. Jedin´a funkce k adaptaci je CBA Acco ReviseQos() kter´a prov´ad´ı revizi hodnoty QoS s ohledem na minim´aln´ı hodnotu QoS (definov´ana makrem), aby nedoch´azelo ke spojen´ım s hodnotou QoS = 0. Zbytek funkc´ı nen´ı tˇreba adaptovat, jejich v´ yznam je podrobnˇe rozebr´an v [2]. K ACCO objektu patˇr´ı i tak zvan´ y perzistentn´ı proces, kter´ y bˇeˇz´ı na pozad´ı syst´emu a ukl´ad´a aktu´aln´ı informace o objektech (o propojen´ı mezi objekty). Pˇri obnovov´an´ı bˇehu syst´emu po jeho p´adu m˚ uˇze b´ yt tato konfigurace nahr´ana a syst´em nemus´ı b´ yt znovu konfigurov´an z n´avrh´aˇrsk´e stanice (programem iMap).
Soubory urˇ cen´ e pro adaptaci ./v1.2-src/dcomap/test/linux/cfg accocfg.h accocfg.c 9
podle tab. 2.2 je na prvn´ım m´ıstˇe pole argument˚ u posledn´ı argument
20
2.8
PROFInet a Linux
Device
Tato ˇca´st adaptace obsahuje podp˚ urn´e funkce pro vybudov´an´ı modelu PROFInetu (viz d´ale). Je zde vytvoˇren obecn´ y prostˇredek pro pr´aci s dynamick´ ymi seznamy objekt˚ u, pro jejich vyhled´av´an´ı, pro udrˇzen´ı jejich konzistence pˇri souˇcasn´em pˇr´ıstupu nˇekolika proces˚ u. Mezi funkce, kter´e je tˇreba adaptovat, patˇr´ı: funkce pro pr´aci s ˇcasem, datem a zejm´ena ymi funkce hlavn´ıho vl´akna, kter´a periodicky vol´a CBA Timer Call pro pr´aci s uˇzivatelsk´ ˇcasovaˇci. Funkce pracuj´ıc´ı se seznamem objekt˚ u jsou zcela platformˇe nez´avisl´e, zp˚ usob jejich pouˇzit´ı je rozebr´an v [2]. PROFInet pouˇz´ıv´a sv´e softwarov´e ˇcasovaˇce, funkce CBA Timer Call pracuje nad uspoˇra´dan´ ym seznamem ˇcasovaˇc˚ u (uspoˇra´dan´ y podle ˇcasu vyprˇsen´ı), kdyˇz nˇekter´ y z nich ˇ vyprˇs´ı, vol´a se tzv. Callback funkce, kter´a je s dan´ ym ˇcasovaˇcem sv´az´ana. Casovaˇce mohou b´ yt typu: jednor´ azov´ e - Callback funkce je vol´ana jednou po uplynut´ı ˇcasu; cyklick´ eCallback funkce je vol´ana periodicky s periodou ˇcasovaˇce; n-n´ asobn´ e - Callback funkce je n-kr´at opakov´ana s periodou ˇcasovaˇce. Informace o struktuˇre ˇcasovaˇc˚ u lze nal´ezt v souboru ./dcomap/device/timers.c, popis ˇcasovaˇc˚ u v [2] je velice stroh´ y. Soubory vytv´aˇrej´ıc´ı “strukturu” PROFInetu jsou zejm´ena v adres´aˇri ./dcomap/device. Jedn´a se o objektovou strukturu, kde z´akladn´ım prvkem je PDev objekt, na nˇej je nav´az´an seznam s LDev objekty a seznam tabulky s atributy RTAuto objekt˚ u. Pro ilustraci je pˇriloˇzena pˇr´ıloha 6, 7, 8. Soubory urˇ cen´ e pro adaptaci ./v1.2-src/dcomap/test/linux/cfg DevCfg.h DevCfg.c
2.9
Aplikace PROFInet
Jedn´a se o aplikaci vytvoˇrenou nad jiˇz popsan´ ymi vrstvami. Pˇri kompilaci se ke zdrojov´emu k´odu PROFInetu pˇrid´a v´ ystup po kompilaci IDL soubor˚ u popisuj´ıc´ı rozhran´ı, kter´e je naˇcteno do datov´e struktury. Z t´e je vytvoˇrena hierarchick´a struktura objekt˚ u popsan´a v´ yˇse. Funkce pracuj´ıc´ı nad touto datovou strukturou se nal´ezaj´ı v souboru ./dcomap/test/linux/sysobj.c. IDL soubor se nejprve kompiluje MIDL kompil´atorem (souˇca´st´ı Visual Studia) a posl´eze se AMCvtTlb konvertorem pˇrevede do vhodn´eho form´atu (tento form´at je d˚ ukladnˇe pops´an v [2]) pro zaˇclenˇen´ı do PROFInetu. Pˇri inicializaci PROFInet objekt˚ u je nejprve zavol´ana funkce SysLinux Startup(), kter´a vytvoˇr´ı PDev objekt s jedn´ım obecn´ ym LDev objektem. Funkce SysLinux InitUserObjects() naˇc´ıt´a datovou strukturu vytvoˇrenou AMCvtTlb konvertorem a podle n´ı vytv´aˇr´ı funkc´ı SysLinux Add LDev() LDev objekty a RTAuto objekty. Posloupnost pˇr´ıkaz˚ u, jenˇz tato funkce prov´ad´ı je naznaˇcena na (obr. 2.9). Tyto funkce nen´ı tˇreba adaptovat, jedn´a se o funkce, kter´e volaj´ı jiˇz dˇr´ıve implementovan´e a adaptovan´e funkce (napˇr. obr. 2.9). Souˇca´st´ı PROFInet aplikace je i definice vlastn´ı funkˇcnosti komponenty. Postup vytv´aˇren´ı PROFInet komponenty je do podrobna pops´an v [1] a v [2]. Detailn´ı informace lze tak´e z´ıskat ze zdrojov´eho k´odu.
2.10 Pˇ reklad PROFInet serveru
21
SysLinux_Add_LDev() { ... // Vytvoˇ r nov´ e LDev zaˇ rı ´zen´ ı a registruj ho u PDev objektu CBA_LDev_Construct(); ... //pˇ res vˇ sechny RTAuto objekty naleˇ zej´ ıc´ ı k LDev while(otherRTAuto) { ... // vol´ an´ ı funkce: SysLinux_Add_RTAuto() { // Vytvoˇ r nov´ y RTAuto objekt a registruj ho u LDev objektu CBA_RTAuto_Construct(); ... // Registruj RTAuto objekt pro pouˇ zit´ ı pomoc´ ı DCOM vrstvy CBA_RTAuto_Register(); } ... } ... // Registruj LDev objekt pro pouˇ zit´ ı pomoci DCOM vrstvy CBA_LDev_Register(); ... } Obr´azek 2.9: Postup vytv´aˇren´ı PROFInet objekt˚ u Soubory urˇ cen´ e pro adaptaci ./v1.2-src/dcomap/test/linux/ sysobj.h sysobj.c ./v1.2-src/dcomap/test/linux/cfg syscfg.h syscfg.c
2.10
Pˇ reklad PROFInet serveru
Pro sestaven´ı cel´e aplikace byl naps´an Makefile [9], kter´ y se nach´az´ı v adres´aˇri ./dcomap/test/linux. Pˇr´ıkaz make 10 lze spustit s tˇemito argumenty (ale lze i vyvolat make pro konkretn´ı soubor, napˇr. make trccfg.o): release, debug a clean. Argument release je implicitn´ı, je generov´an ˇcist´ y k´od bez informac´ı pro debuger 11 . Debug (make s argumentem debug) informace se skl´adaj´ı i se zdrojov´eho k´odu samotn´e aplikace, v´ ysledn´ y k´od je nadmˇernˇe velik´ y. Pˇr´ıkaz make clean odstran´ı vˇsechny *.o soubory. Jednotliv´e zdrojov´e soubory se kompiluj´ı postupnˇe, v´ ysledek kompilace je uloˇzen do 10 11
interpretuje Makefile v aktu´ aln´ım adres´ aˇri program pro trasov´ an´ı bˇehu aplikace
22
PROFInet a Linux
adres´aˇre ./dcomap/test/linux. Server byl odladˇen pomoc´ı kompil´atoru gcc [8] verze 2.95.3.
2.11
Shrnut´ı
V t´eto kapitole jsem nast´ınil postup adaptace PROFInet serveru z platformy s operaˇcn´ım syst´emem Windows na syst´em Linux (intelovsk´a 32bit architektura). D´ıky ˇclenˇen´ı aplikace do adres´aˇr˚ u podle funkce a udrˇzen´ı odstupu obecn´eho k´odu od implementaˇcnˇe z´avisl´e je vˇse pˇrehledn´e a ˇciteln´e. K´od PROFInetu koresponduje s dod´avanou dokumentac´ı [2]. Trasovac´ı syst´em spolu s filtrem v´ ypisu pro jednotliv´e komponenty je podrobn´ y a velice uˇziteˇcn´ y pˇri ladˇen´ı cel´eho syst´emu, kaˇzd´e vol´an´ı i zd´anlivˇe nepodstatn´e funkce m˚ uˇze b´ yt zobrazeno v trasovac´ıch v´ ypisech.
Kapitola 3 Webov´ e rozhran´ı Tato kapitola vych´az´ı ze specifikace webov´eho rozhran´ı popsan´eho v [4], nˇekter´e ˇca´sti byli rozˇs´ıˇreny pro dosaˇzen´ı vˇetˇs´ı flexibility (v textu je na nˇe upozornˇeno). Tato specifikace je v tzv. draft (v´ yvojov´e) verzi a proto se d´a oˇcek´avat, ˇze se bude ˇcasem mˇenit a d´ale rozˇsiˇrovat. V z´avˇeru kapitoly je pops´ana vlastn´ı implementace tohoto rozhran´ı, kter´a pracuje na Linuxovsk´e platformˇe s webov´ ym serverem Apache.
3.1
´ Uvod
Webov´e rozhran´ı pro PROFInet umoˇzn ˇ uj´ı pˇr´ıstup ke komponent´am PROFInetu pomoc´ı standardn´ıch protokol˚ u HTTP. Data jsou pos´ıl´ana ve standardizovan´em tvaru (HTML, XML) a jsou zobrazeny obvykl´ ym web prohl´ıˇzeˇcem (Microsoft Explorer, Mozilla, Opera...). Protokol DCOM nen´ı internetov´ ym protokolem1 , port 135 nen´ı pˇr´ıstupn´ y z okoln´ıho svˇeta, proto pˇr´ıstup k PROFInetu pˇres standardn´ı web prohl´ıˇzeˇc je velice ˇza´dan´ y.
3.2
C´ıl implementace
Specifikace popsan´a v [4] definuje vlastnosti, kter´e by mˇel PROFInet server s Webov´ ym rozhran´ım splˇ novat: • Adresov´an´ı - jednoznaˇcn´e adresov´an´ı objekt˚ u a atribut˚ u PROFInetu. • Design HTML str´anek - definuje CSS styl str´anek, rozvrˇzen´ı str´anky atp 2 . • N´azvy nemˇenn´ ych atribut˚ u PROFInet objekt˚ u, jako je ConnState, ConnChannel, atp. • Zabezpeˇcen´ı - omezen´ı pˇr´ıstupu k nˇekter´ ym atribut˚ um komponenty. Podle “mnoˇzstv´ı” implementovan´ ych vlastnost´ı lze server rozdˇelit do nˇekolika tˇr´ıd, jejich popis ud´av´a tab. 3.1. 1 2
bezpeˇcnostn´ı d˚ uvody ve specifikaci [4] nen´ı zcela dokonˇceno
vlastnosti statick´e HTML str´anky zahrnuje tˇr´ıdu 0 + dynamicky generovan´e str´anky zahrnuje tˇr´ıdu 1 + dynamick´e str´anky v XML(+XSL) form´atu tˇr´ıda 3 zahrnuje tˇr´ıdu 2 + Webov´e sluˇzby
role povinn´e nepovinn´e nepovinn´e doporuˇcen´e
Tabulka 3.1: Rozdˇelen´ı PROFInet serveru podle hloubky web integrace
Tˇ r´ıda 0 nab´ız´ı jen z´akladn´ı funkce. Syst´em t´eto tˇr´ıdy nem˚ uˇze b´ yt zaintegrov´an do sloˇzitˇejˇs´ıch celk˚ u, jako je topologie s tzv. plant serverem (viz. kap. 3.3). Str´anky jsou staticky zaintegrov´any v syst´emu. Pˇr´ıstup je moˇzn´ y jen pˇres web prohl´ıˇzeˇc. Tˇ r´ıda 1 a 2 nab´ız´ı vˇetˇs´ı flexibilitu, generov´an´ı HTML str´anek je dynamick´e, data z´ısk´av´ana pˇr´ımo z PROFInet serveru. Tˇ r´ıda 3 doporuˇcen´a a nejv´ yhodnˇejˇs´ı z hlediska integrace zaˇr´ızen´ı do vˇetˇs´ıch celk˚ u (viz. kap. 3.3). V t´eto pr´aci se pˇredevˇs´ım zamˇeˇruji na ˇca´st webov´eho rozhran´ı, kter´a splˇ nuje tˇ r´ıdu 1 a tˇ r´ıdu 3, tj. generovan´a str´anka je dynamick´a v HTML nebo textov´e podobˇe s podporou Webov´ ych sluˇzeb. Generov´an´ı str´anek v XML form´atu nebude d´ale rozeb´ır´ano. Tak´e ot´azka zabezpeˇcen´ı atribut˚ u proti neopr´avnˇen´emu pˇr´ıstupu nen´ı ˇreˇsena.
3.3
Topologie Web serveru
Je zde nˇekolik moˇzn´ ych zp˚ usob˚ u jak zaintegrovat webov´e rozhran´ı do PROFInet serveru, z´aleˇz´ı na konkr´etn´ı aplikaci a moˇznostech hardwaru, na kter´em je PROFInet server provozov´an. Integrovan´ y Webserver
Obr´azek 3.1: Integrovan´ y web server
3.3 Topologie Web serveru
25
V t´eto situaci je web server urˇcen jen pro jedno konkr´etn´ı fyzick´e zaˇr´ızen´ı (obr. 3.1). Web server a fyzick´e zaˇr´ızen´ı maj´ı stejnou IP adresu. Web server pˇristupuje k PROFInet komponentˇe pˇr´ımo, pˇres rozˇs´ıˇren´e rozhran´ı PROFInetu. Vhodn´e ˇreˇsen´ı pro syst´emy, kter´e nemaj´ı v operaˇcn´ım syst´emu implementov´ano DCOM rozhran´ı. Extern´ı Webserver
Obr´azek 3.2: Extern´ı web server Web server nen´ı souˇca´st´ı PROFInet serveru, je spuˇstˇen na jin´em fyzick´em zaˇr´ızen´ı, proto m´a i jinou IP adresu (obr. 3.2). Komunikace mezi nimi prob´ıh´a pˇres standardn´ı rozhran´ı PROFInetu - DCOM. Web server m˚ uˇze sdruˇzovat informace z nˇekolika fyzick´ ych zaˇr´ızen´ı a vhodn´ ym zp˚ usobem je distribuovat. PROFInet proxy a Webserver
Obr´azek 3.3: PROFInet proxy
26
Webov´ e rozhran´ı
M˚ uˇze b´ yt ˇreˇseno jako integrovan´ y nebo extern´ı web server. Web server mus´ı ˇreˇsit pˇr´ıstup k nˇekolika fyzick´ ym zaˇr´ızen´ım na jedn´e IP adrese, toto je ˇreˇseno pˇriˇrazen´ım logick´eho zaˇr´ızen´ı k re´aln´emu fyzick´emu zaˇr´ızen´ı (obr. 3.3). Plant Server
Obr´azek 3.4: Konfigurace s plant serverem
Plant server shromaˇzd’uje informace z okoln´ıch PROFInet komponent pˇres jejich intern´ı nebo extern´ı web servery (obr. 3.4). Komunikace prob´ıh´a v´ yhradnˇe pomoc´ı HTTP protokolu v kombinaci s HTML, pˇr´ıpadnˇe XML. Plant server adresuje pouze web servery (jako “obyˇcejn´ y” web prohl´ıˇzeˇc) PROFInet zaˇr´ızen´ı. Web servery implementovan´e na stranˇe PROFInet zaˇr´ızen´ı mus´ı b´ yt alespoˇ n tˇr´ıdy 1 (tab. 3.1) a mus´ı m´ıt implementov´an mechanizmus pro dynamick´e z´ısk´av´an´ı hodnot ze syst´emu.
3.4
Adresn´ı sch´ ema
Adresov´an´ı PROFInet objektu pˇres web rozhran´ı se sest´av´a z adresy web serveru + adresy PROFInet objektu nebo atributu. Toto adresn´ı schema je spoleˇcn´e jak pro skriptovac´ı rozhran´ı (kap. 3.6), tak i pro Webservices (kap. 4.5). kompletn´ı adresa = cesta k webserveru + adresa v PROFInet serveru
3.4.1
Syntaxe adresov´ an´ı v r´ amci PROFInet serveru
Adresov´an´ı objektu v r´amci PROFInet serveru: PDev|LDev|RTAuto.Atribut.Connection • PDev, LDev, RTAuto - jm´eno PDev, LDev a RTAuto zaˇr´ızen´ı, PDev m˚ uˇze b´ yt nahrazeno IP adresou. Jednotliv´e objekty jsou oddˇeleny znakem ”|”.
3.4 Adresn´ı sch´ ema
27
• Atribut - jm´eno atributu PROFInet objektu. Objekt a atribut je oddˇelen znakem ”.” • Connection - moˇzn´ y pˇr´ıstup k vlastnostem propojen´ı3 mezi objekty, n´azev atributu obsahuje jm´eno promˇenn´e objektu RTAuto. Atribut a Connection je oddˇeleno znakem ”.”. Extenz´ı Connection se m˚ uˇzeme dot´azat na vlastnosti atribut˚ u objektu RTAuto v (tab. 3.2). Connection = ConnState
Moˇ zn´ y v´ ystup Up Down
ConnChannel
QC Quality Code
DCOM Local None Good (NC)-OK Good (C)-Local Override Uncertain-Last usable value Uncertain-Substitute set Uncertain-QoS violation Bad QC unknown-Value 0xabcd
v´ yznam Spojen´ı s t´ımto atributem je vytvoˇren´e Neexistuje spojen´ı s t´ımto atributem data se pˇren´aˇsej´ı pˇres DCOM lok´aln´ı propojen´ı atribut nen´ı propojen hodnota ok pouˇzita posledn´ı platn´a hodnota pouˇzita substitue hodnota alarmuj´ıc´ı QoS
Tabulka 3.2: Vlastnosti propojen´ı
Pˇ r´ıklad adresov´ an´ı atribut˚ u RTAuto objektu N´asleduj´ıc´ı pˇr´ıklad je uk´azkou adresace atributu CounterValue objektu RTAuto Counter, kter´ y je patˇr´ı do LDev objektu LDev Counter. N´azev PDev objektu je suchac01, ale lze pouˇz´ıt i IP adresu zaˇr´ızen´ı. suchac01|LDev Counter|RTAuto Counter.CounterValue Dalˇs´ı pˇr´ıklad rozˇsiˇruje pˇredch´azej´ıc´ı adresaci o dotaz na vlastnost ConnChannel atributu CounterValue. suchac01|LDev Counter|RTAuto Counter.CounterValue.ConnChannel 3
interconnections
28
3.4.2
Webov´ e rozhran´ı
Z´ apis do atributu RTAuto objektu
Pro pˇriˇrazen´ı hodnoty do atributu je pouˇzito dalˇs´ı kl´ıˇcov´e slovo value, kter´e je od n´azvu atributu oddˇeleno znakem “&“. Nov´a hodnota atributu je pˇred´ana textov´e podobˇe. PDev|LDev|RTAuto.Atribut&value=hodnota Pˇri u ´ spˇeˇsn´em z´apisu do promˇenn´e vr´at´ı webov´ y server ˇretˇezec “OK” jinak je n´avratov´a hodnota typu “103! Write error, internal error-code: 0xHRESULT”, kde HRESULT je n´avratov´a hodnota funkce, kter´a prov´adˇela z´apis. Pˇ r´ıklad z´ apisu do atributu Provedeme z´apis hodnoty 10 do atributu Run, RTAuto objektu RTAuto Counter, patˇr´ıc´ı k logick´emu zaˇr´ızen´ı LDev Counter, to vˇse zapouzdˇren´e fyzick´ ym zaˇr´ızen´ım na IP adrese 147.32.87.233. 147.32.87.233|LDev Counter|RTAuto Counter.Run&value=10
3.4.3
Form´ at odpovˇ ed´ı z webov´ eho serveru
Form´at dat, kter´e web server vrac´ı na naˇsi ˇza´dost m˚ uˇzeme ovlivnit dalˇs´ım kl´ıˇcov´ ym slovem type. PDev|LDev|RTAuto.Atribut&type=format Moˇzn´e hodnoty kl´ıˇcov´eho slova type jsou v (tab. 3.3). V adresaci lze libovolnˇe kombinovat kl´ıˇcov´a slova value a type. type= plain html xml
Popis ˇcist´ y text text form´atovan´ y do HTML str´anky XML v´ ystup podle specifikovan´eho standardu
Tabulka 3.3: Moˇzn´ y form´at navr´acen´ ych dat
3.5
Kompletn´ı adresa
K adrese v r´amci PROFInet serveru, popsan´e v (kap. 3.4.1), pˇrid´ame kl´ıˇcov´e slovo name, oddˇelen´e od adresy web serveru znakem “?”. V (tab. 3.4) je form´aln´ı z´apis. http://IP adr/profinet?name=PDev|LDev|RTAuto.Atribut&type=format Tabulka 3.4: Form´at kompletn´ı adressy
3.5 Kompletn´ı adresa
29
Pˇ r´ıklad kompletn´ı adresy Tento pˇr´ıklad ukazuje adresov´an´ı atributu CounterValue, s poˇzadovan´ ym v´ ystupem dat v html formˇe. Adresa (IP) web serveru nemus´ı b´ yt shodn´a s adresou fyzick´eho zaˇr´ızen´ı PROFInet zaˇr´ızen´ı, z´aleˇz´ı na pouˇzit´e topologii webov´eho serveru (viz. kap. 3.3). http://147.32.87.233/profinet?name=suchac01|LDev Counter| RTAuto Counter.CounterValue&type=html Dalˇs´ı pˇr´ıklad poˇzaduje z´apis do atributu Run, s poˇzadavkem o form´atov´an´ı potvrzen´ı do plain formy. Webov´ y server je spuˇstˇen na vyhrazen´ ym portu 8000. http://147.32.87.233:8000/profinet?name=suchac01|LDev Counter| RTAuto Counter.Run&value=1&type=plain Tuto syntaxi lze jiˇz zapsat do adresn´ıho ˇra´dku webov´eho prohl´ıˇzeˇce.
3.5.1
Adresov´ an´ı v´ıce atribut˚ u souˇ casnˇ e
Lze pouˇz´ıt t´eto konstrukce pro adresov´an´ı v´ıce atribut˚ u PROFInet serveru souˇcasnˇe. http://WebServeru?list=name=”Device1” name=”Device2”&type=format Jednotliv´e adresn´ı sekvence zaˇc´ınaj´ıc´ı name= jsou od sebe oddˇeleny znakem ’ ’ (mezera) 4 . Odpovˇed’ na tento soubor adresn´ıch sekvenc´ı je zasl´an ve stejn´em poˇrad´ı jako dotazy. Pod symbolick´ ym n´azvem DeviceX se skr´ yv´a adresa v r´amci PROFInet komponety popsan´e jiˇz dˇr´ıve (kap. 3.4.1).
3.5.2
Adresov´ an´ı atribut˚ u PDev a LDev objekt˚ u
Jm´ena atribut˚ u PDev a LDev objekt˚ u jsou pevnˇe d´ana a jsou urˇcena jen pro ˇcten´ı. Oddˇelen´ı PDev nebo LDev objekt˚ u od jm´ena atributu je opˇet znakem “.”, jako pˇri adresov´an´ı atributu RTAuto objektu. Podrobnˇejˇs´ı v´ yznam sloˇzitˇejˇs´ı atribut˚ u bude zm´ınˇen pozdˇeji, ve vlastn´ı implementaci webov´eho rozhran´ı. Name Producer Product SerialNo Date Revision LDevNames
jm´eno PDev objektu, je z´amˇenn´e s IP adresou objektu v´ yrobce fyzick´eho zaˇr´ızen´ı (hardwaru) jm´eno produktu seriov´e ˇc´ıslo datum v´ yroby nebo kompilace serveru revize seznam LDev objekt˚ u Tabulka 3.5: Atributy PDev objektu
4
lze pouˇz´ıt i znak &
30
Webov´ e rozhran´ı Name Producer Product SerialNo Date Time Revision State SetStateActive SetStateDeactive GroupError ACCOInformation RTAutoNames ConnectionNames ConnectionInfo
jm´eno LDev objektu producent softwaru jm´eno produktu seriov´e ˇc´ıslo datum aktu´aln´ı ˇcas LDev objektu revize stav objektu (viz. kap. 1.2) pˇrejdi do aktivn´ıho stavu pˇrejdi do stavu pˇripraveno informace funkˇcnosti objektu informace o ACCO objektu, tzv. “ACCOPingFactor” seznam RTAuto objekt˚ u, kter´e vlastn´ı tento LDev objekt seznam n´azv˚ u propojen´ı mezi RTAuto objekty detailn´ı informace o propojen´ı Tabulka 3.6: Atributy LDev objektu
3.6
Implementace webov´ eho rozhran´ı
Byla zvolena implementace integrovan´eho web serveru (kap. 3.3), protoˇze operaˇcn´ı syst´em Linux nem´a implementov´an DCOM. Ke st´av´aj´ıc´ı verzi PROFInetu je dops´ano rozˇsiˇruj´ıc´ı rozhran´ı, kter´e zprostˇredkov´av´a pˇr´ımou komunikaci mezi PROFInetem a vnˇejˇs´ım CGI skriptem (obr. 3.5). PROFInet Server Webové Rozhraní
IPC komunikace
CGI html, plain APACHE HTTP komunikace klient
Obr´azek 3.5: Blokov´e schema webov´eho rozhran´ı Obsluha klientsk´ ych poˇzadavk˚ u je zn´azornˇena na (obr. 3.6), kde klient (web browser) pˇred´a dotaz CGI skriptu metodou POST, GET nebo jako obyˇcejn´ y parametr dle specifikace
3.6 Implementace webov´ eho rozhran´ı
31
popsan´e v´ yˇse (kap. 3.4). CGI skript provede “rozebr´an´ı” (parsing) tohoto ˇretˇezce a pˇres IPC message system pos´ıl´a jednotliv´e dotazy PROFInetu. Web rozhran´ı na stranˇe PROFInetu vyvol´a pˇr´ısluˇsnou metodu a jej´ı n´avratovou hodnotu poˇsle opˇet pˇres IPC zpˇet pˇr´ısluˇsn´emu CGI skriptu. CGI provede u ´ pravu odpovˇedi do ˇza´dan´eho form´atu (implementov´an HTML a “plain text” form´at). Na stranˇe PROFInetu je kaˇzd´ y poˇzadavek obsluhov´an zvl´aˇstn´ım procesem (thread) s nastavenou niˇzˇs´ı prioritou neˇz m´a cel´ y server. Browser (klient)
Webov´e rozhran´ı
CGI script
POST nebo GET dotaz
Answer thread
PROFInet
Parsing
(HTTP protokol) IPC Request nov´e vl´ akno Vol´ an´ı funkce
IPC Response ˇ Odpovˇed
konec
(HTTP protokol)
vl´ akna Form´ atov´ an´ı do HTML
nebo PLAIN text PROFInet server s Webov´ ym rozhran´ım
APACHE PC s OS Linux
Obr´azek 3.6: Princip funkce webov´eho rozhran´ı
3.6.1
Data od klienta
ˇ Cten´ ı dat Pˇred´an´ı dat od klienta CGI skriptu m˚ uˇze b´ yt uskuteˇcnˇeno nˇekolika zp˚ usoby. Nejednoduˇsˇs´ı zp˚ usob, kde se ne´ uˇcasn´ı web server(Apache), je pˇr´ımo zavol´an´ı skriptu z pˇr´ıkazov´e ˇra´dky a pˇred´an´ı dat v argumentu. Dalˇs´ı moˇznost´ı je: GET Pˇri pˇred´av´an´ı metodou GET je web serverem nastavena promˇenn´a prostˇred´ı REQUEST METHOD na hodnotu GET a data jsou pˇred´any pˇres promˇenou prostˇred´ı QUERY STRING. Metoda je omezena ve velikosti pˇred´avan´ ych dat. POST Pˇri metodˇe POST nastav´ı web server promˇenou prostˇred´ı REQUEST METHOD na hodnotu POST, d´ale je nastavena promˇenn´a prostˇred´ı CONTENT LENGHT, kter´a ud´av´a velikost dat. Data ˇcteme standardn´ımi funkcemi pro pr´aci s datov´ ymi 5 proudy (fread, fwrite) ze standardn´ıho vstupu (stdin) [9]. Velikost pˇred´avan´ ych dat nen´ı prakticky omezeno. 5
stream
32
Webov´ e rozhran´ı
Metodu POST je vhodn´e vyuˇz´ıt pˇri jednor´azov´em adresov´an´ı v´ıce atribut˚ u PROFInet komponenty, nebo napˇr. pˇri z´apisu textov´eho ˇretˇezce do atributu RTAuto objektu, kdy velikost pˇred´avan´ ych argument˚ u m˚ uˇze b´ yt i nˇekolik kilobyte. Zpracov´ an´ı dat Po naˇcten´ı dat od klienta do mezi pamˇeti prob´ıh´a jejich rozebran´ı na jednotliv´e adresn´ı sekvence (syntaxe tˇechto sekvenc´ı viz kap. 3.4). Pˇrijat´ y datov´ y blok je nejprve rozdˇelen na jednotliv´e adresn´ı sekvence a pak je kaˇzd´a sekvence rozdˇelena na konkretn´ı ˇca´sti, kter´e koresponduj´ı s n´azvy objekt˚ u a atribut˚ u v PROFInet serveru (adresn´ı sch´ema PROFInet objektu viz. kap. 3.4.1). Tyto informace jsou uloˇzeny do datov´e struktury (obr. 3.8), kter´a je n´aslednˇe posl´ana PROFInet serveru pomoc´ı IPC komunikace.
3.6.2
IPC Komunikace
N´azvem IPC n´ astroje nebo System V IPC se oznaˇcuj´ı n´astroje pro komunikaci mezi procesy. Tyto n´astroje se prvnˇe objevily v Unixu AT&T System V.2 a obsahuj´ı funkce pro pr´aci se semafory, sd´ılenou pamˇet´ı a komunikaci pomoc´ı zpr´av mezi procesy. Vˇsechny tyto tˇri n´astroje maj´ı podobn´e funkˇcn´ı rozhran´ı. Z´akladn´ı funkce pro komunikaci jsou: Ovl´ad´an´ı IPC message system se dˇeje pomoc´ı tˇechto funkc´ı: msgget - proces vytvoˇr´ı frontu zpr´av funkc´ı msgget. Vstupem t´eto funkce je jedineˇcn´e ˇc´ıslo v r´amci poˇc´ıtaˇce a atributy, kter´e nastavuj´ı vlastnosti fronty (napˇr. pr´ava pˇr´ıstupu). Pokud fronta v syst´emu neexistuje je nutn´e nastavit atribut IPC CREAT. Atributy se nastavuj´ı logick´ ym souˇctem vˇsech ˇza´dan´ ych atribut˚ u. N´avratovou hodnotou t´eto funkce je identifik´ ator fronty zpr´av. msgsnd Funkce msgsnd umoˇzn ˇ uje pˇridat do fronty novou zpr´avu. Funkci pˇred´ame identifik´ ator fronty, pointer na pos´ılan´a data a jejich velikost. Data, kter´a chceme pˇren´aˇset, mus´ı m´ıt form´at podle obr. 3.7. msgrcv Funkce msgrcv z´ısk´a zpr´avu z fronty zpr´av. Funkci pˇred´ame identifik´ ator fonty, ’ ukazatel na alokovanou pamˇet , kam bude zpr´ava uloˇzena a maxim´aln´ı velikost ˇcten´e zpr´avy. Posledn´ım parametrem jsou atributy, kter´ ymi lze nastavit bude-li ˇcten´ı z fronty blokuj´ıc´ı nebo ne (atribut IPC NOWAIT). Pˇri u ´ spˇeˇsn´em proveden´ı vrac´ı funkce poˇcet pˇrijat´ ych byt˚ u. msgctl Funkc´ı msgctl lze ˇc´ıst nastaven´ı fronty zpr´av, smazat zpr´avy ˇcekaj´ıc´ı na vyzvednut´ı ˇci frontu zpr´av u ´ plnˇe odstranit ze syst´emu. Detailn´ı popis IPC syst´emu lze naj´ıt v [9]. Fronty zpr´av se v pouˇzit´ı podobaj´ı pojmenovan´ym rour´ am, odpadaj´ı vˇsak komplikace s otev´ır´an´ım a zav´ır´an´ım roury. Pˇri pouˇz´ıv´an´ı zpr´av se ovˇsem nevyhneme probl´em˚ um, jako je blokov´an´ı pˇri pln´ ych front´ach. Maxim´aln´ı velikost zpr´avy je nastavena syst´emem na 8kb, maxim´aln´ı velikost fronty zpr´av je nastavov´ana PROFInet serverem pomoc´ı makra MAXMSG BUFFER.
3.6 Implementace webov´ eho rozhran´ı
33
struct zprava { long int typ_zpravy; /* Data, kter´ a chceme pˇ ren´ est */ }; Obr´azek 3.7: Struktura IPC zpr´avy
Komunikace mezi CGI a PROFInet serverem Pˇri komunikaci mezi CGI skriptem a webov´ ym rozhran´ım na stranˇe PROFInet serveru je pr´avˇe pouˇzit IPC message system. Datov´a struktura, kter´a je ve zpr´avˇe pos´ıl´ana je na obr. 3.8. ...struct... { integer ID; string PDevName; string LDevName; string RTAutoName; string Property; string Value; string Connection; }...; Obr´azek 3.8: Struktura IPC zpr´avy pouˇzit´a pˇri komunikaci
klientsk´ a fronta
klient (CGI)
B
listen fronta PROFInet serveru
vytvoˇr frontu zpr´ av B
poˇsli dotaz na listen frontu (A)
zasl´ an´ı odpovˇedi
zpracov´ an´ı
dotazu zavˇri frontu zpr´ av
PROFInet server CGI skript
s webov´ ym rozhran´ım
Obr´azek 3.9: Fronty Zpr´av
Po rozebr´an´ı datov´eho ˇretˇezce od klienta a uloˇzen´ı jeho jednotliv´ ych ˇca´st´ı do struktury (obr. 3.8) jsou vytvoˇreny dvˇe komunikaˇcn´ı fronty zpr´av. Fronta zpr´av A (obr. 3.9) slouˇz´ı
34
Webov´ e rozhran´ı
k napojen´ı na listen frontu PROFInet serveru (vytvoˇrena bez atributu IPC CREAT, kap. 3.6.2) a posl´an´ı t´eto datov´e struktury (request = poˇzadavek), fronta zpr´av B je vytvoˇrena s identifik´ atorem fronty odpov´ıdaj´ıc´ı PID6 ˇc´ıslu klientsk´eho CGI skriptu7 . PID ˇc´ıslo procesu je tak´e souˇca´st´ı pos´ılan´e datov´e struktury (obr. 3.8) v poloˇzce ID. Po zpracov´an´ı poˇzadavku na stranˇe PROFInet serveru (kap.3.6.3) se server pˇripoj´ı na klientskou frontu zpr´av (fronta B)a zaˇsle odpovˇed’ na poˇzadavek. Odpovˇed’ na tento poˇzadavek m˚ uˇze b´ yt v nˇekter´ ych pˇr´ıpadech vˇetˇs´ı, neˇz je maxim´aln´ı povolen´a velikost zpr´avy. V takov´em pˇr´ıpadˇe rozdˇel´ı server odpovˇed’ do 8kb paket˚ u a ty poˇsle CGI skriptu postupnˇe. Celkov´ y poˇcet a poˇrad´ı konkr´etn´ıho paketu CGI skript zjist´ı z promˇenn´e typ zpravy obsaˇzen´e ve struktuˇre odpovˇedi (obr. 3.7) Form´at odpovˇedi poslan´ y PROFInet serverem zpˇet CGI skriptu je ˇretˇezec znak˚ u, kde jsou jednotliv´e hodnoty oddˇeleny znakem “;”. CGI skript mus´ı tato data interpretovat klientovi podle ˇza´dan´eho typu8 v´ ystupu (plain text nebo html )9 . Form´ at v´ ystupu “PLAIN TEXT” ˇ ezec znak˚ Retˇ u od PROFInet serveru je pˇr´ımo interpretov´an klientovi, jednotliv´e ˇza´dosti (sekvence) jsou oddˇeleny odˇra´dkov´an´ım, jednotliv´e hodnoty jsou oddˇeleny znakem “;”. Na zaˇca´tek zpr´avy je CGI skriptem pˇrid´ana informace o typu dat pro web server: ContentType: text/plain. Form´ at v´ ystupu “HTML” Jsou definov´any implicitn´ı str´anky pro PROFInet objekty PDev, LDev, RTAuto a pro ˇ ezec s odpovˇed´ı od PROFInet serveru je atributy tˇechto objekt˚ u (pˇr´ıloha 9 aˇz 12). Retˇ rozebr´an a vloˇzen do tˇechto str´anek. Vzhled je definov´an pomoc´ı kask´adov´eho stylu (CSS), vˇetˇs´ıch zmˇen lze dos´ahnout zmˇenou CGI skriptu. Na zaˇca´tek zpr´avy je CGI skriptem pˇrid´ana informace o typu dat pro web server: Content-Type: text/html. Pˇ r´ıklady form´ atov´ an´ı v´ ystupu http://147.32.87.233/profinet?list= name=suchac01|LDev Counter|RTAuto Counter.Run name=suchac01|LDev Counter|RTAuto Counter.CounterValue&type=plain Jedn´a se ˇza´dost o hodnotu atributu Run a CounterValue v plain formˇe, obdrˇzen´a odpovˇed’ bude tato: Content-Type: text/plain ’1’ ’17’ 6
Process Identification Number t´ım je zaruˇcena jednoznaˇcnost v r´ amci syst´emu 8 pokud nen´ı uˇzivatelem specifikov´ an typ v´ ystupu, tak v´ ystup je stejn´ y jako by byl poˇzadov´ an “plain”, ale neobsahuje hlaviˇcku definuj´ıc´ı typ dat pro web server. 9 form´ at XML nen´ı implementov´ an 7
3.6 Implementace webov´ eho rozhran´ı
3.6.3
35
Struktura webov´ eho rozhran´ı
Server pˇrij´ım´a poˇzadavky na listen IPC frontˇe, na kterou klient pos´ıl´a datovou strukturu z obr. 3.8, kde ID je PID ˇc´ıslo klienta. Server po pˇrijet´ı zpr´avy (obr. 3.9) vytvoˇr´ı nov´ y proces (Answer Thread ), kter´emu pˇred´a pˇrijat´a data a d´al ˇcek´a na dalˇs´ıho klienta. Tento nov´ y proces vyhodnot´ı ˇza´dost a v´ ysledek zaˇsle zpˇet klientovi. Pak nastav´ı pˇr´ıznak, ˇze jeho ˇcinnost byla ukonˇcena, coˇz pro rodiˇcovsk´ y proces znamen´a, ˇze m˚ uˇze uvolnit jim pouˇz´ıvanou pamˇet’ a smazat ho ze seznamu aktivn´ıch proces˚ u (seznam vˇsech bˇeˇz´ıc´ıch Answer Thread ). Obsluha klientsk´e ˇza´dosti prob´ıh´a pˇres implementovan´e funkˇcn´ı rozhran´ı, kter´e se sest´av´a z funkc´ı popsan´ ych n´ıˇze. Jsou rozdˇeleny do skupin podle objektu, nad kter´ ym pracuj´ı. Typy funkc´ı a argument˚ u koresponduj´ı s typy pouˇz´ıvan´ ymi v implementaci PROFInet serveru (dcom s8 ∼ char, dcom u8 ∼ unsigned char, atp.) Physical device Funkce pracuj´ıc´ı s objektem PDev maj´ı jen v´ ystupn´ı argument(y). • dcom_s32 dcom_s8 dcom_s8 dcom_s8 dcom_s32 dcom_s32
• dcom_s32 GetPDevInfoList(dcom_s8 *str); Funkce vrac´ı vˇsechny vlastnosti PDev zaˇr´ızen´ı v ˇretˇezci data oddˇeleny znakem “;”. • dcom_s32 GetLDevList(dcom_s8 *str); Funkce vrac´ı seznam LDev objekt˚ u, kter´e PDev obsahuje. N´azvy jsou oddˇeleny znakem “;”. Logical device Funkce pracuj´ıc´ı nad objektem LDev maj´ı jako vstupn´ı parametr datovou strukturu profinet items t, kter´a je shodn´a se strukturou na obr. (3.8). Zde jiˇz je nutn´e adresovat konkr´etn´ı LDev zaˇr´ızen´ı, protoˇze se jich na PDev objektu m˚ uˇze nach´azet nˇekolik. • dcom_s8 *GetLDevName(profinet_items_t *pt); dcom_s8 *GetLDevProducer(profinet_items_t *pt); dcom_s8 *GetLDevProduct(profinet_items_t *pt); dcom_s8 *GetLDevSerial(profinet_items_t *pt); dcom_s8 *GetLDevRevision(profinet_items_t *pt); dcom_u16 GetLDevDate(dcom_u8 *str, profinet_items_t *pt); • dcom_s32 GetLDevInfoList(dcom_s8 *str, profinet_items_t *pt); Funkce vr´at´ı vˇsechny vlastnosti PDev, popsan´e v´ yˇse, v ˇretˇezci kde jsou jednotliv´e hodnoty oddˇeleny znakem “;”.
36
Webov´ e rozhran´ı • dcom_s32 GetPingFactor(dcom_s8 *value, profinet_items_t *pt); Funkce vr´at´ı hodnotu ping faktor ACCO objektu, jedn´a se o z´akladn´ı parametr ACCO objektu, viz [3]. • STATEDEF GetLDevState(profinet_items_t *pt); Funkce vrac´ı stav LDev, m˚ uˇze nab´ yvat tˇechto hodnot: NonExistent, Initializing, Operating, Ready, Defect. • dcom_s32 GetLDevTime(dcom_s8 *Value,profinet_items_t *pt); Informace o aktu´aln´ım ˇcase LDev objektu, m˚ uˇze b´ yt nastaven zcela nez´avisle na PDev objektu a i na ostatn´ıch LDev objektech. • GROUPERRORDEF GetLDevGroupError(profinet_items_t *pt); Funkce vr´at´ı informaci o funkˇcnosti LDev: NonAccessiable, Ok, Problem, Unknown. • dcom_s32 GetConnectionInfo(dcom_s8 *buff, conpair_list_t *ptList, profinet_items_t *pt); Detailn´ı informace o propojen´ı, v ˇretˇezci vr´at´ı poloˇzky oddˇelen´e znakem “;”: ID propojen´ı; provider; jm´eno atributu providera; jm´eno propojen´ı; datov´ y typ propojen´ı; hodnota; stav propojen´ı; komunikaˇcn´ı kan´al; kvalita (QoS). • dcom_s32 GetConnectionNames(dcom_s8 *buff, conpair_list_t *ptList, profinet_items_t *pt); Funkce vr´at´ı seznam n´azv˚ u nav´azan´ ych spojen´ı s okoln´ımi objekty. • dcom_s32 SetLDevState_Deactivate(profinet_items_t *pt); Uvede LDev objekt (a t´ım i jeho RTAuto objekty) do stavu Ready, tj. objekt zpracov´av´a vstupy, ale v´ ystupy jsou zmraˇzeny. • dcom_s32 SetLDevState_Activate(profinet_items_t *pt); Uvede LDev objekt (a t´ım i jeho RTAuto objekty) do stavu Operating, tj. norm´aln´ı pracovn´ı stav objektu. • dcom_s32 GetRTAutoList(dcom_s8 *list, profinet_items_t *pt); Seznam jmen RTAuto objekt˚ u.
• dcom_s32 GetPropertiesNames(dcom_s8 *buff, list_t *ptList, profinet_items_t *pt); Seznam vˇsech atribut˚ u RTAuto objektu v ˇretˇezci sestaven´em n´asledovnˇe: jm´eno promˇenn´e; jej´ı datov´ y typ; pr´ava modifikace;. Tyto funkce pˇr´ımo volaj´ı funkce nebo pˇristupuj´ı k datov´ ym struktur´am PROFInetu. Pro pˇredstavu doporuˇcuji nahl´ednout do zdrojov´ ych k´odu webov´eho rozhran´ı.
3.6.4
Zp˚ usob obsluhy ˇ z´ adosti
V okamˇziku vytvoˇren´ı procesu Answer Thread pˇreb´ır´a tento proces kontrolu nad zpracov´an´ım poˇzadavku. Procesu je pˇred´ana pˇrijat´a struktura, kter´a specifikuje ˇza´dost. Podle poˇctu vyplnˇen´ ych pol´ıˇcek nejprve Answer Thread urˇc´ı, nad kter´ ym objektem se bude pracovat, v´ ybˇer provede pomoc´ı konstrukce switch(...) a case (obr. 3.10). Z objekt˚ u PDev a LDev je moˇzn´e atributy jen ˇc´ıst, podle jm´ena ˇza´dan´eho atributu zavol´a proces pˇr´ısluˇsnou funkci (kap. 3.6.3). Atributy nad objekty RTAuto je moˇzno jak ˇc´ıst tak do nich zapisovat, jako indikace z´apisu mus´ı b´ yt promˇenn´a Value (obr. 3.8) nenulov´a. ptRequest = ...; //ukazatel na pˇ rijatou strukturu s poˇ zadavkem switch(typZadosti) { case PDev:
// dotaz nad PDev objektem ... if(!strcmp(atribut,’’Producer’’)) GetPDevName(buffer); ...
break; case LDev:
//dotaz nad LDev objektem ... if(!strcmp(atribut,’’Product’’)) buffer=GetPDevName(ptRequest); ....
break; case RTAuto: //dotaz nad RTAuto objektem ... break; } Obr´azek 3.10: Obsluha ˇza´dosti webov´ ym rozhran´ım Soubory s implementac´ı webov´eho rozhran´ı jsou pevnou souˇca´st´ı PROFInet serveru. Pˇri jak´ekoliv zmˇenˇe v k´odu web rozhran´ı je nutno pˇrekompilovat cel´ y server.
38
Webov´ e rozhran´ı Soubory s implementac´ı webov´ eho rozhran´ı ./v1.2-src/dcomap/test/ IPCmsg.c IPC komunikace, Answer Thread() linux/webint webint.c funkce pro komunikaci s PROFInetem webint.h deklarace funkc´ı web cfg.h spoleˇcn´e datov´e struktury CGI skriptu a webov´eho rozhran´ı
Zapnut´ı webov´eho rozhran´ı v PROFInet serveru je uskuteˇcnˇeno spuˇstˇen´ım samostatn´eho procesu, kter´e vytvoˇr´ı listen frontu a ˇcek´a na ˇza´dosti od CGI skriptu.
3.6.5
Struktura CGI skriptu
CGI skript pˇrevezme poˇzadavek (argumenty) od klienta, vytvoˇr´ı napojen´ı na listen frontu zpr´av na PROFInet server, zaˇsle poˇzadavek a ˇcek´a na odpovˇed’ (pops´ano v kap. 3.6.2). V pˇr´ıpadˇe adresov´an´ı v´ıce atribut˚ u souˇcasnˇe (kap. 3.5.1), je vytvoˇren dynamick´ y seznam s jednotliv´ ymi dotazy, kter´ y je postupnˇe zas´ıl´an na webov´e rozhran´ı PROFInet serveru. Sch´ema zpracov´an´ı poˇzadavku je zobrazeno na obr. (3.11). Funkce SendRequest() 10 a WaitForResponse() maj´ı nastaveny ˇcasov´e limity jak dlouho se funkce opakuje pˇri ne´ uspˇeˇsn´em odesl´an´ı/pˇrijet´ı11 . Funkce pro form´atov´an´ı v´ ystupu do html nebo plain textov´e podoby pˇrihl´ıˇzej´ı na typ dotazu (napˇr. dotaz na hodnotu atributu RTAuto objektu, PDev objektu atp.)
./cgi
3.7
Soubory s implementac´ı CGI skriptu profinet-cgi.c vlastn´ı CGI skript format.c funkce pro form´atov´an´ı v´ ystupu do HTML nebo PLAIN, defaultn´ı str´anky objekt˚ u PDev, LDev, RTAuto. parse.c funkce pro rozebr´an´ı poˇzadavku od CGI skriptu web cgi.h deklarace funkc´ı CGI skriptu
Postup sestaven´ı aplikace, konfigurace
Po z kompilov´an´ı CGI skriptu gcc [8] kompil´atorem jej nakop´ırujeme do adres´aˇre, ve kter´em m˚ uˇze Apache server spouˇstˇet CGI skripty (obvykle adres´aˇr /cgi-bin). Cesta k tomuto adres´aˇri mus´ı b´ yt nastaven´a v makru CGI BIN v konfiguraˇcn´ım souboru ./dcamap/test/linux/webint/web cfg.h, d´ale mus´ı b´ yt ve stejn´em souboru nastaveno makro CSS NAME, kter´e se odkazuje na pouˇzit´ y kask´adov´ y styl (CSS). Detailnˇejˇs´ı konfigurac´ı Apache serveru bude uk´az´ana pˇri konfigurov´an´ı aplikace modelu akv´aria. 10 ve skuteˇcnosti se jedn´ a o nˇekolik funkc´ı, zde je tato mnoˇzina nazv´ ana souhrnnˇe takto, jen pro ilustraci probl´emu 11 reˇzim pˇr´ıj´ım´ an´ı je v tzv. neblokuj´ıc´ım reˇzimu [9]
3.8 Shrnut´ı
39
// provedeme rozebr´ an´ ı adresn´ ıho r ˇetˇ ezce na jednotliv´ e // a uloˇ zı ´me do dynamick´ e struktury, kter´ a odpov´ ıd´ a struktuˇ re // pro komunikaci mezi CGI a webov´ ym rozhran´ ım profinetu Cutting(pBegin, request); // pointer pBegin ukazuje na zaˇ ca ´tek dynamick´ eho seznamu // datov´ ych struktur pList = pBegin; while (pList->next != NULL) { //dokud nen´ ı seznam pr´ azdn´ y SendRequest(pList); // poˇ sle prvek seznamu na webov´ e rozhran´ ı // PROFInetu pomoc´ ı IPC message syst´ emu WaitForResponse(pResponse); // c ˇek´ a na odpovˇ ed’ s nastaven´ ym // c ˇasem pro vyprˇ sen´ ı z ˇa ´dosti FormatToPLAINOutput(pResponse, Output); // nebo FormatToHTMLOutput(pResponse, Output); printf(‘‘%s‘‘, Output); pList=pList->Next; } Obr´azek 3.11: Struktura CGI skriptu pro webov´e rozhran´ı
3.8
Shrnut´ı
IPC komunikace byla zvolena pro svoj´ı flexibilitu a rychlost. Komunikace nen´ı z´avisl´a na pˇredstaven´em CGI skriptu, ten m˚ uˇze b´ yt nahrazen jin´ ym, napsan´ ym ve skriptovac´ım jazyce, napˇr. v Perlu nebo PHP. Jedin´e, co je nutn´e zachovat, je datov´a struktura pro v´ ymˇenu dat. Webov´e rozhran´ı, kter´e je souˇca´st´ı PROFInet serveru, bude tˇreba ˇcasem upravovat a doplˇ novat o dalˇs´ı funkce, postupnˇe s rozvojem PROFInetu jako celku. Toto je hlavn´ı nev´ yhoda oproti pouˇzit´ı extern´ıho webov´eho serveru s pouˇzit´ım komunikaˇcn´ıho protokolu DCOM. CGI skript je spouˇstˇen Apachem, webov´ ym serverem, jeho konfigurace a veˇsker´e n´aleˇzitosti pro spuˇstˇen´ı cel´e aplikace budou uk´az´any na modelu akv´aria v z´avˇeru t´eto pr´ace.
40
Webov´ e rozhran´ı
Kapitola 4 Webov´ e sluˇ zby 4.1
´ Uvod
Web Services se do ˇcesk´eho jazyka pˇrekl´ad´a jako Webov´e sluˇzby, ale tento n´azev nen´ı zcela ekvivalentn´ı, nebot’ se nejedn´a jen o sluˇzby poskytovan´e pˇres web. Web Services je n´asledn´ık syst´emu vzd´alen´eho vol´an´ı procedur v distribuovan´ ych syst´emech jako jsou RPC, 1 2 CORBA , RMI . Oproti sv´ ym pˇredch˚ udc˚ um nen´ı tak vyzr´al´ y (neˇreˇs´ı prozat´ım napˇr´ıklad autentizaci), ale jedn´a se o jednoduch´ y, otevˇren´ y a zcela platformˇe nez´avisl´ y komunikaˇcn´ı syst´em. Technologii Webov´ ych sluˇzeb tvoˇr´ı tˇri ˇca´sti: - komunikaˇcn´ı protokol pro vzd´alen´e vol´an´ı procedur SOAP 3 , kter´ y pˇren´aˇs´ı data zapsan´a v XML jazyku. - jazyk pro popis poskytovan´ ych sluˇzeb, zvan´ y WSDL4 - mechanismus pro nalezen´ı sluˇzeb5 , pouˇz´ıvaj´ı se dva standardy UDDI a WSII
4.2
SOAP
Protokol SOAP vznikl v roce 1998 ve firmˇe Microsoft, pozdˇeji se na jeho rozˇs´ıˇren´ı pod´ılelo mnoho firem, vˇcetnˇe IBM. Paralelnˇe s n´ım vzniklo mnoho podobn´ ych protokol˚ u jako XML-RPC, WDDX, XMI. Verze SOAP 1.2 byl pˇrijat konsorciem W3C. Protokol SOAP pos´ıl´a argumenty volan´e funkce metodou POST a jsou zaps´any pomoc´ı XML jazyka. Pomoc´ı XML jazyka si lze pˇred´avat jak jednoduch´ y text, tak i sloˇzit´e objekty a struktury. Pˇri pouˇzit´ı XML sch´ema lze nav´ıc jednotn´ ym a rozˇsiˇriteln´ ym zp˚ usobem definovat strukturu a typ pˇred´avan´ ych dat. Pomoc´ı XML NameSpace lze zabr´anit koliz´ım mezi stejn´ ymi n´azvy pro r˚ uzn´e typy. 1
Common Object Request Broker Architecture Remote Method Invocation 3 Simple Object Access Protocol 4 Web Service Description Language 5 v t´eto pr´ aci se jimy nebudeme zab´ıvat 2
42
Webov´ e sluˇ zby
SOAP zpr´ava se skl´ad´a ze tˇrech ˇca´st´ı: Envelope, Header a Body. Envelop (ob´alka) je koˇrenov´ ym tagem cel´e zpr´avy. V nˇem je obsaˇzena ˇca´st uvozen´a tagem Header (hlaviˇcka zpr´avy), tato ˇca´st je nepovin´a, pomoc´ı n´ı lze nastavit parametry komunikace. Za hlaviˇckou zpr´avy n´asleduje povinn´a ˇca´st uvozen´a tagem Body (tˇelo zpr´avy), kter´e jiˇz obsahuje jm´eno volan´e metody a jej´ı argumenty. P˚ uvodn´ı implementace pˇren´aˇsela SOAP zpr´avy protokolem HTTP, v souˇcasnosti existuj´ı implementace i pro pˇrenos pomoc´ı protokolu SMTP6 .
4.2.1
Pˇ r´ıklad SOAP komunikace
Mˇejme napˇr´ıklad funkci boolean jePrvocislo(long cislo);, kter´a m´a ˇc´ıseln´ y argument cislo a vrac´ı pravdivostn´ı hodnotu podle toho, zda cislo je ˇci nen´ı prvoˇc´ıslo. Vzhledem k tomu, ˇze webov´a sluˇzba muˇze b´ yt implementov´ana v libovoln´em jazyce, jsou typy boolean a long definov´any v XML schema a ne nutnˇe pˇr´ıtomn´e v konkr´etn´ım jazyce. SOAP vyˇzaduje, aby kaˇzd´a funkce byla v urˇcit´em jmenn´em prostoru. U objektovˇe orientovan´eho jazyku je t´ımto prostorem objekt a funkce odpov´ıd´a jeho metodˇe. U jazyk˚ u, kter´e nejsou objektovˇe orientovan´e nem´a jmenn´ y prostor pˇr´ımou interpretaci, ale mus´ıme nˇejak´ y definovat. Jmenn´ y prostor je urˇcen URI adresou. Pˇr´ıklad SOAP zpr´avy je na (obr. 4.1). <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xs="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> <env:Body> <m:jePrvocislo xmlns:m="urn:mojeURI" > 1987 Obr´azek 4.1: SOAP zpr´ava pro vol´an´ı funkce
Zpr´ava je pˇrenesena na server, kter´ y funkci implementuje pomoc´ı protokolu HTTP a metodou POST (nejˇcastˇeji). Funkce na stranˇe serveru je jednoznaˇcnˇe urˇcena sv´ ym jm´enem a jmenn´ ym prostorem. Ve vol´an´ı metody na (obr. 4.1) jsou celkem definov´any ˇctyˇri prefixy jmenn´ ych prostor˚ u: env pouˇzit´ y pro tagy samotn´eho SOAPu, xs pro XML schema, xsi pro instanci XML schema a n´ami definovan´ y m jako jmenn´ y prostor naˇs´ı funkce. N´azvy prefix˚ u lze volit libovolnˇe, d˚ uleˇzit´e je, ke kter´ ym URI se v´aˇz´ı. 6
Simple Mail Transport Protocol = protokol urˇcen´ y na doruˇcov´ an´ı elektronick´e poˇsty
4.3 WSDL
43
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <env:Body> <ns1:jePrvocisloResponse xmlns:ns1="urn:mojeURI" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> true Obr´azek 4.2: SOAP zpr´ava pro vr´acen´ı n´avratov´e hodnoty
4.3
WSDL
Jazyk WSDL (Web Services Description Language) je urˇcen pro definici nab´ızen´ ych sluˇzeb vzd´alen´ ym serverem. Jazyk je velice obecn´ y, aby byla zachov´ana platformn´ı nez´avislost. Nejednoduˇsˇs´ı bude uk´azat popis jednoduch´e sluˇzby na pˇr´ıkladu (obr. 4.3). WSDL dokument obsahuje popis jedn´e sluˇzby (kl´ıˇcov´e slovo service), coˇz je nejvˇetˇs´ı jednotka. Jedna sluˇzba m´a jednu, nebo nˇekolik bran (kl´ıˇcov´e slovo port). Kaˇzd´a br´ana m´a vazbu (kl´ıˇcov´e slovo binding), coˇz je zp˚ usob, jak se dan´a br´ana vol´a (napˇr. SOAP pˇres HTTP) a nˇejakou pˇr´ıstupovou adresu(URL). Lze tedy m´ıt pro jednu sluˇzbu v´ıce bran s r˚ uzn´ ymi vazbami, tj. volat jednu sluˇzbu r˚ uzn´ ymi zp˚ usoby, napˇr. prvn´ı br´ana: SOAP pˇres HTTP, druh´a br´ana: SOAP pˇres HTTP nad SSL atp. Vazby odkazuj´ı na rozhran´ı (portType), kter´e je souhrnem operac´ı (operation). Rozhran´ı v objektovˇe orientovan´em jazyku odpov´ıd´a objektu, jednotliv´e operace odpov´ıdaj´ı metod´am nad t´ımto objektem. Kaˇzd´a operace definuje obvykle dvˇe zpr´avy (message), jednu vstupn´ı (input) a jednu v´ ystupn´ı (output). Kaˇzd´a zpr´ava m˚ uˇze obsahovat nˇekolik ˇca´st´ı (part), kter´e odpov´ıdaj´ı argument˚ um a n´avratov´ ym hodnot´am. Dokument v jazyce WSDL pˇr´ısluˇsej´ıc´ı k Webov´e sluˇzbˇe ji plnˇe popisuje, pokud tedy m´ame WSDL popis sluˇzby, m˚ uˇzeme sluˇzbu plnˇe vyuˇz´ıvat (obvykle ke staˇzen´ı ze serveru, kter´ y sluˇzbu poskytuje).
4.4
N´ astroje pro implementaci
Z freewarov´ ych n´astroj˚ u je asi nejzn´amˇejˇs´ı Apache Axis pracuj´ıc´ı v Javˇe, kter´ y zahrnuje WSDL gener´ator a tak´e n´astroj pro generov´an´ı kostry funkc´ı z WSDL souboru. Za nejrychlejˇs´ı (nejrychleji reaguj´ıc´ı na poˇzadavky) je povaˇzov´an n´astroj gSOAP [7], kter´ y pracuje s jazykem C/C++. Zat´ımco Axis dok´aˇze SOAP zpr´avy generovat dynamicky v okamˇziku, kdy konkr´etn´ı sluˇzbu potˇrebuje, gSOAP prov´ad´ı generov´an´ı SOAP zpr´av v pr˚ ubˇehu kompilace zdrojov´ ych k´od˚ u bez moˇznosti zmˇeny za bˇehu programu. Je to kompro-
mis mezi flexibilitou a extr´emn´ı rychlost´ı cel´e aplikace. Obsahuje takt´eˇz gener´ator WSDL popisu sluˇzby a inverzn´ı gener´ator kostry programu z WSDL souboru (zat´ım ve f´azi v´ yvoje, nepodporuje vˇsechny konstrukce jazyka WSDL). Pro u ´ plnost lze jmenovat i komerˇcn´ı n´astroje jako je WebSphere (IBM), Oracle9iAS (Oracle), .NET (Microsoft).
4.5
Implementace Webov´ ych sluˇ zeb
K implementaci webov´ ych sluˇzeb byl vyuˇzit projekt gSOAP [7], kter´ y pˇr´ımo pracuje v jazyku C a je volnˇe ˇsiˇriteln´ y. Vytvoˇren´ı aplikace pomoc´ı t´eto implementace je snadn´e a rychl´e. Aplikace pro webov´e sluˇzby je tak´e tvoˇrena CGI skriptem, kter´ y obsluhuje SOAP komunikaci s klientem. Pro pˇr´ıstup k dat˚ um z PROFInetu vyuˇz´ıv´a jiˇz dˇr´ıve popsan´ y CGI 7 skript (kap. 3.6.5), kter´ y spouˇst´ı s pˇresmˇerovan´ ym standardn´ım v´ ystupem do roury [9], ze kter´e ˇcte data z PROFInetu a ty poskytuje klientovi pomoc´ı protokolu SOAP (obr. 4.4). Hlavn´ı souˇca´st´ı gSOAPu je pˇrekladaˇc soapcpp2, kter´ y z hlaviˇckov´eho souboru nab´ızen´ ych funkc´ı (nazv´an profinet.h) vygeneruje kostru webov´e sluˇzby, xml strukturu jednotliv´ ych dotaz˚ u (request) a odpovˇed´ı (response). Souˇca´st´ı generovan´eho k´odu je i WSDL popis sluˇzby. Nejd˚ uleˇzitˇejˇs´ı z generovan´ ych soubor˚ u jsou tyto: - soapClient.c - pˇripraven´e kostry jednotliv´ ych sluˇzeb pro stranu klienta (proxy), 7
tzv. pipe
4.5 Implementace Webov´ ych sluˇ zeb
45
PROFInet Server Webové Rozhraní IPC message
CGI pro
pipe
CGI pro
html, plain
SOAP APACHE
HTTP Browser
SOAP Webové sluzby
Obr´azek 4.4: Struktura rozhran´ı pro webov´e sluˇzby
kaˇzd´a ze sluˇzeb nejprve provede serializaci (pops´ano d´ale) argument˚ u metody, pak odesl´an´ı na server, kter´ y sluˇzbu poskytuje. Po pˇrijet´ı odpovˇedi provede deserializaci odpovˇedi. Tento soubor se pˇrid´av´a jen ke klientsk´e aplikaci. - soapServer.c - pˇripraven´e kostry webov´ ych sluˇzeb pro stranu serveru (stub), po deserializaci pˇrijat´e zpr´avy do konkretn´ıch argument˚ u je zavol´ana poˇzadovan´a funkce, v´ ysledek je serializov´ an a zasl´an nazpˇet klientovi. Pˇrid´av´a se k aplikaci, kter´a sluˇzby poskytuje. - soapC.c - funkce pro serializaci a deserializaci spoleˇcn´e jak stranˇe klienta tak serveru. N´azvem serializace je nazv´an proces, kter´ y zkonvertuje argumenty funkce do XML struktury. Proces deserializace je postup obr´acen´ y. Informace lze naj´ıt v dokumentaci k projektu gSOAP [7].
4.5.1
Nab´ızen´ e sluˇ zby
Seznam nab´ızen´ ych sluˇzeb definujeme v hlaviˇckov´em souboru, oznaˇcen profinet.h jeho souˇca´st´ı je tak´e definice jmenn´eho prostoru. Protoˇze jazyk C nen´ı objektov´ y, je pˇr´ısluˇsnost promˇenn´e ˇci metody k urˇcit´emu jmenn´emu prostoru vyj´adˇrena definovan´ ym oper´atorem “ “ (dvˇe podtrˇz´ıtka). Na obr. 4.5 je uk´azka deklarace nab´ızen´ ych sluˇzeb pro pˇr´ıstup k PROFInetu. Prvn´ıch nˇekolik ˇra´dk˚ u nen´ı koment´aˇr, pˇrekladaˇc soapcpp2 je zpracov´av´a a z´ısk´av´a z nich informace o jmenn´ ych prostorech, jm´eno generovan´eho WSDL souboru, kde se bude skript nal´ezat (d˚ uleˇzit´e pro WSDL soubor), atd. D´ale m´ame definovanou strukturu LDevNames t (obr. 4.5), kter´a patˇr´ı do jmenn´eho prostoru ns a obsahuje ukazatel na datov´ y typ LDev Name. Struktura m´a speci´aln´ı tvar (viz. [7]) pro definici dynamick´ ych pol´ı (pˇredem nev´ıme kolik objekt˚ u LDev PDev objekt obsahuje), velikost pole je urˇcena size. N´azev datov´eho typu poloˇzky pole je vhodn´e si
46
Webov´ e sluˇ zby
//gsoap //gsoap //gsoap //gsoap //gsoap
ns ns ns ns ns
service name: profinet service namespace: http://suchac01/profinet.wsdl service location: http://suchac01/cgi-bin/ service executable: profinet-soap.cgi schema namespace: urn:profinet
typedef char* ns__LDevName; typedef struct ns__LDevNames_tag { ns__LDevName *__ptr; int __size; } ns__LDevNames_t; int ns__GetLDevNames(char *PDevName, ns__LDevNames_t **LDevNames); ... Obr´azek 4.5: uk´azka ze souboru profinet.h pro webov´e sluˇzby
nadefinovat, nebot’ se prom´ıtne ve vygenerovan´em XML dotazu ˇci odpovˇedi. Specifikaci nab´ızen´ ych sluˇzeb pro PROFInet je moˇzno nal´ezt v dokumentaci [4]. Nab´ızen´ e sluˇ zby pro objekt PDev N´asleduj´ıc´ı funkce maj´ı vstupn´ı argument jm´eno PDev objektu, v´ ystupn´ım argumentem je datov´a struktura. Pro v´ıce informac´ı nahl´ednˇete do v´ yˇse zm´ınˇen´eho hlaviˇckov´eho souboru s nab´ızen´ ymi sluˇzbami. Adresov´an´ı jednotliv´ ych objekt˚ u v r´amci PROFInet komponenty je shodn´e s webov´ ym rozhran´ım (kap. 3.4.1). • int ns GetPDevInformation() - naˇcte kompletn´ı informace o objektu PDev do datov´e struktury. • int ns GetLDevNames() - z´ısk´av´a seznam vˇsech LDev objekt˚ u do dynamick´eho pole ˇretˇezc˚ u. Nab´ızen´ e sluˇ zby pro objekt LDev Vstupn´ım argumentem n´asleduj´ıc´ıch sluˇzeb je jm´eno LDev objektu. • int ns GetLDevInformation() - vrac´ı datovou strukturu s kompletn´ımi informacemi o LDev objektu. • int ns GetGroupError() - informace o funkˇcnosti objektu. • int ns GetACCOInformation() - Informace o ACCO objektu.
4.5 Implementace Webov´ ych sluˇ zeb
47
• int ns GetState() - stav objektu. • int ns SetState() -nastav stav objektu (Operate nebo Ready). • int ns GetRTAutoNames() - jm´ena podˇrazen´ ych RTAuto objekt˚ u. Nab´ızen´ e sluˇ zby pro RTAuto objekt • int ns GetRTAutoPropertyNames() - vstupn´ım argumentem je jm´eno RTAuto8 objektu, v´ ystupem je dynamick´a struktura s atributy objektu. • int ns GetProperty() - vstupem je atribut RTAuto objektu, v´ ystupem hodnota atributu • int ns SetProperty() - vstupem je atribut RTAuto objektu a jeho nov´a hodnota hodnota, v´ ystupem je informace zda-li byl z´apis u ´ spˇeˇsn´ y. Nab´ızen´ e sluˇ zby pro informace o propojen´ı • int ns GetConnectionQuality() - vstupem je jm´eno propojen´ı, vrac´ı jeho QoS (Quality of Servis). • int ns GetConnectionState() - vstupem je jm´eno propojen´ı, vrac´ı jeho stav. • int ns GetConnections() - vrac´ı jm´ena vˇsech propojen´ı nad konkr´etn´ım LDev objektem. • int ns GetConnectionsInfo() - detailn´ı informace o propojen´ı mezi objekty nad konkr´etn´ım LDev objektem. Datov´e poloˇzky struktur, kter´e jsou n´avratov´e hodnoty popsan´ ych funkc´ı lze nal´ezt v souboru profinet.h.
4.5.2
generov´ an´ı SOAP zpr´ av
Na obr. 4.6 je uk´az´an vygenerovan´ y SOAP dotaz pro sluˇzbu zapsanou na obr. 4.5. Tag <ns:GetLDevNames> urˇcuje jm´eno volan´e sluˇzby. Mezi tagy a je vloˇzeno jm´eno PDev objektu. V z´ahlav´ı dotazu je naˇcten´ı jmen´ ych prostor˚ u pro SOAP, XML a n´aˇs jmenn´ y prostor ns - profinet. Na dotaz (obr. 4.6) obdrˇz´ıme odpovˇed’ na obr. (4.7). Dotaz m˚ uˇzeme zaslat na port webov´eho serveru demonstraˇcnˇe napˇr´ıklad pomoc´ı telnet klienta. Pˇri pouˇzit´ı gSOAP knihovny se tvorbou zpr´av na u ´ rovni SOAP protokolu nemus´ıme zab´ yvat, vˇse prob´ıh´a zcela transparentnˇe. Uˇzivatel, kter´ y chce vyuˇz´ıvat nˇekterou ze vzd´alen´ ych sluˇzeb, potˇrebuje zn´at jen WSDL soubor, kter´ y obsahuje jej´ı popis, z nˇej pomoc´ı aplikace wsdlcpp 9 vygeneruje hlaviˇckov´ y soubor, kter´ y jiˇz muˇze kompilovat soapcpp2 pˇrekladaˇcem. Program wsdlcpp je ve v´ yvoji a nezvl´ad´a nˇekter´e sloˇzitˇejˇs´ı konstrukce. 8 jm´enem RTAuto objektu je myˇslena kompletn´ı cesta v r´ amci komponety, tedy vˇcetnˇe PDev a LDev objektu 9 souˇca ´st gSOAP projektu
Aplikace vytvoˇren´a pro obsluhu webov´ ych sluˇzeb m˚ uˇze b´ yt vytvoˇrena dvˇema zp˚ usoby: - CGI skript, kter´ y je vol´an nadˇrazen´ ym webov´ ym serverem jako klasick´ y CGI skript. - Stand Alone server, kter´ y je zcela autonomn´ı. Z´ısk´ame kompaktn´ı, v´ ykonou aplikaci pro pr´aci se SOAP protokolem. Interpretaci webov´ ych str´anek, podporu cgi skript˚ u, pos´ılan´ı dat (pˇripad´a v u ´ vahu jen metoda GET), je nutno do implementovat. Postup implementace je podobn´ y, liˇs´ı se v algoritmu, kter´ y vyvol´av´a jednotliv´e sluˇzby (s menˇs´ımi u ´ pravami lze pˇrej´ıt od jednoho typu k druh´emu). Jak jiˇz bylo naps´ano v u ´ vodu, pro u ´ˇcely PROFInetu byl zvolen prvn´ı z jmenovan´ ych zp˚ usob˚ u, tedy webov´e sluˇzby pomoc´ı CGI skriptu.
4.5.4
Struktura CGI skriptu
Funkce main() CGI skriptu pro obsluhu webov´ ych sluˇzeb obsahuje pouze tyto funkce: int main() { struct soap soap; soap_init(&soap);
Webov´ e sluˇ zby soap_serve(&soap); soap_end(&soap); return(0); }
Funkc´ı soap init() provedeme inicializaci promˇenn´ ych prostˇred´ı (struktura soap) pro vlastn´ı SOAP komunikaci na implicitn´ı hodnoty. Mezi promˇenn´ ymi je napˇr. nastaven´ı verze HTTP protokolu, ˇcasov´e limity pro pˇr´ıjem, port pro stand alone server, komprese zpr´av, SSL podpora atd. Jejich pˇr´ıpadnou zmˇenu m˚ uˇzeme prov´est pˇr´ım´ ym z´apisem do datov´e struktury soap. Funkce soap serve() pˇrijme poˇzadavek od klienta, provede deserializaci (z´ısk´an´ı argument˚ u metody ze SOAP zpr´avy) zpr´avy a zavol´a pˇr´ısluˇsnou sluˇzbu (metodu). V´ ystup metody je serializov´ an do SOAP zpr´avy a zasl´an zpˇet klientovi. Tato funkce je souˇca´st´ı generovan´eho souboru soapServer.c. y soket v soap struktuˇre, uvoln´ı pamˇet’. Funkce soap end() zavˇre pouˇz´ıvan´ Funkce pro inicializaci (soap init()) a konec (soap end()) SOAP komunikace jsou obsaˇzeny v knihovnˇe projektu gSOAP, v souboru stdsoap2.c. D´ale by mˇela n´asledovat implementace jednotliv´ ych sluˇzeb deklarovan´ ych v hlaviˇckov´em souboru (profinet.h). Pro naˇs´ı uk´azkovou funkci GetLDevNames() (obr. 4.5) m´ame tuto vygenerovanou kostru: int
V tˇele t´eto funkce zavol´ame spuˇstˇen´ı CGI skriptu webov´eho rozhran´ı (kap. 3.6.5) s pˇresmˇerovan´ ym v´ ystupem do roury. CGI skriptu pˇred´ame parametry jako pˇri vol´an´ı pˇr´ıkazu z pˇr´ıkazov´e ˇra´dky, nelze pouˇz´ıt metodu POST - standardn´ı vstup, protoˇze ten pouˇz´ıv´a samotn´ y SOAP protokol (pˇred vol´an´ım skriptu je nutn´e deaktivovat promˇenou prostˇred´ı REQUEST METHOD a po proveden´ı pˇr´ıkazu ji opˇet nastavit na hodnotu POST (kap. 3.6.1)). V´ ysledek naˇcten´ y z roury uloˇz´ıme do datov´e struktury LDevNames. Pro u ´ spˇeˇsn´e dokonˇcen´ı sluˇzby nesm´ıme zapomenout na vol´an´ı return(SOAP OK). V´ıce se o implementaci sluˇzby nemus´ıme starat, pˇr´ıjem dat, vol´an´ı sluˇzby a zasl´an´ı odpovˇedi zaopatˇr´ı metoda soap serve().
N´asleduje uk´azka zdrojov´eho k´odu klientsk´e aplikace, kter´a vyuˇz´ıv´a sluˇzbu GetLDevNames(). N´azev metody volan´e klientem m´a o proti metodˇe definovan´e na stranˇe serveru
4.6 Shrnut´ı
51
ˇ asteˇcn´a prefix soap call . Jedn´a se jen o rozˇs´ıˇren´ı p˚ uvodn´ı metody o dalˇs´ı argumenty. C´ definice t´eto metody je v obsaˇzena v souboru soapClient.c. Klient m´a informace pouze o argumentech metody a pouˇzit´ ych datov´ ych typech, o tˇele metody nev´ı nic. int main() { struct soap soap; ns__LDevNames_t *LDevNames; int i; soap_init(&soap); soap_call_ns__GetLDevNames( &soap, "http://192.168.0.100:8000/cgi-bin/profinet-soap.cgi", "", "192.168.0.100",// jm´ eno PDev &LDevNames // n´ avratov´ a hodnota ); if(soap.error) soap_print_fault(&soap,stderr); else for(i=0;i__size;i++) printf("%s\n",LDevNames->__ptr[i]); soap_end(&soap); } Sluˇzbu poskytuje server na adrese uveden´e ve druh´em argumentu volan´e funkce. V´ ystupem bude pole datov´ ych struktur LDevNames t (definice na obr. 4.5) o d´elce size.
4.6
Shrnut´ı
Vytv´aˇren´ı webov´ ych sluˇzeb pomoc´ı projektu gSOAP je velice rychl´ y, pˇred program´atorem je naprosto skryt pˇrenos zpr´av mezi poskytovatelem a klientem, (de)serializace (pˇrijat´ ych)odes´ılan´ ych zpr´av (z)do XML jazyka, navazov´an´ı spojen´ı atp. Pro uˇzivatele nen´ı rozd´ıl mezi vol´an´ım lok´aln´ı funkce a pouˇzit´ı funkce distribuovan´e v r´amci webov´ ych sluˇzeb. Webov´e sluˇzby pro PROFInet poskytuj´ı tomuto standardu dalˇs´ı komunikaˇcn´ı rozhran´ı pro z´ısk´av´an´ı informac´ı o technologii na platform´ach, kde nen´ı moˇzn´e pouˇz´ıt DCOM protokol. Vol´an´ı funkc´ı pomoc´ı webov´ ych sluˇzeb lze l´epe zakomponovat do aplikac´ı psan´ ych napˇr. v jazyku C nebo Java neˇz pˇri pouˇzit´ı webov´eho rozhran´ı, kter´e je sp´ıˇse urˇceno pro vizualizaci technologie. Implementovan´ ymi funkcemi nebyly vyˇcerp´any vˇsechny vlastnosti PROFInetu, kter´e by bylo vhodn´e distribuovat ˇci pomoc´ı webov´ ych sluˇzeb ovlivˇ novat. Jedn´a se sp´ıˇse o jeden z prvn´ıch pokus˚ u o implementaci, slouˇz´ıc´ı k demonstraˇcn´ım u ´ˇcel˚ um.
52
Webov´ e sluˇ zby
Kapitola 5 Model akvaria V t´eto kapitole se sezn´am´ıme s modelem akv´aria na kter´em bude uk´az´ano vyuˇzit´ı webov´eho rozhran´ı a webov´ ych sluˇzeb. Podrobn´ y popis tvorby PROFInet komponenty pro OS Windows byl pops´an v [1], postup je totoˇzn´ y s Linuxem.
5.1
Popis modelu Vzduch
pH
Topení
T
Krmení Osvetlení
O2 T Chov ryb
Filtrace
cirkulace vody
Obr´azek 5.1: Schema akv´aria Model akv´aria je tvoˇren tˇremi n´adobami kask´adnˇe propojen´ ymi (obr. 5.1), ze tˇret´ı n´adoby je voda pˇreˇcerp´av´ana zpˇet do prvn´ı n´adoby. Prvn´ı n´adoba slouˇz´ı jako pˇr´ıpravna
54
Model akvaria
vody, druh´a je pro chov ryb a tˇret´ı je pouze filtraˇcn´ı. Instalovan´e sn´ımaˇce a akˇcn´ı ˇcleny na modelu jsou tyto: Prvn´ı n´ adoba - pˇ r´ıpravna vody1 : - mˇeˇren´ı teploty (T1). - mˇeˇren´ı pH. * tˇr´ıstupˇ nov´e topen´ı. * vzduchov´an´ı. Druh´ a n´ adoba - chov ryb - mˇeˇren´ı teploty (T2). - mˇeˇren´ı okysliˇcen´ı vody. * krmiˇcka. * osvˇetlen´ı akv´aria. Tˇ ret´ı n´ adoba - filtrace * ˇcerpadlo pro cirkulaci vody. Sn´ımaˇce a akˇcn´ı ˇcleny komunikuj´ı s pr˚ umyslov´ ym poˇc´ıtaˇcem prostˇrednictv´ım sbˇernice RS-485 (obr. 5.2). Na pr˚ umyslov´em poˇc´ıtaˇci je spuˇstˇena PROFInet komponenta Akv´ arium, kter´a komunikuje pomoc´ı ovladaˇce (pops´ano d´ale) se sn´ımaˇci a akˇcn´ımi ˇcleny um´ıstˇen´ ymi na modelu, jedn´a se o transformaˇcn´ı uzel (proxy) mezi RS-485 a PROFInetem. Na tomto poˇc´ıtaˇci neprob´ıh´a generov´an´ı akˇcn´ı veliˇciny, to m´a na starosti komponenta Control, kter´a na z´akladˇe zmˇeˇren´ ych hodnot ovl´ad´a vyt´apˇen´ı a okysliˇcov´an´ı akv´ari´ı, z t´eto stanice lze tak´e mˇenit ˇza´dan´e veliˇciny a spouˇstˇet jednor´azov´e krmen´ı. Jedn´a se o pomalou soustavu.
5.1.1
Pˇ rechod od RS-485 k PROFinetu
Na pr˚ umyslov´em poˇc´ıtaˇci na kter´em bˇeˇz´ı PROFInet server je v pozad´ı spuˇstˇen program - ovladaˇc, kter´ y zajiˇst’uje pˇresun hodnot ze sn´ımaˇc˚ u do sd´ılen´e pamˇeti a zpˇet, ze sd´ılen´e pamˇeti do akˇcn´ıch ˇclen˚ u. Sn´ımaˇce a akˇcn´ı ˇcleny jsou pˇripojeny ke sbˇernici RS-485. Jsou cyklicky ˇcteny vˇsechny sn´ımaˇce na modelu a jejich hodnoty ukl´ad´any do sd´ılen´e pamˇeti, ke kter´e mohou pˇristupovat dalˇs´ı procesy. Tento ovladaˇc je souˇca´st´ı diplomov´e pr´ace [12]. Spuˇstˇen´ı ovladaˇce je automatick´e pˇri spuˇstˇen´ı komponenty Akv´aria 2 . Sd´ılen´a pamˇet’ov´a oblast pro v´ ymˇenu dat m´a podobu: 1 2
typedef struct share_memory4exchange_tag { //obraz senzoru int basin1_temperature; int basin1_pH; int basin2_temperature; int basin2_oxygen; //obraz akcnich clenu unsigned short pump; unsigned short light; unsigned short heating_unit; unsigned short oxygenator; unsigned short feeding; } share_memory4exchange_t;
Ovladaˇc sbˇernice RS485 provad´ı z´apis do promˇen´ ych obrazu senzor˚ u, PROFInet aplikace zapisuje do obrazu akˇcn´ıch ˇclen˚ u. Proces, kter´ y prov´ad´ı z´apis ˇci ˇcten´ı z t´eto oblasti, nastav´ı semafor (vstup do kritick´e sekce) aby byla zachov´ana konzistence dat. Ovladaˇc prov´ad´ı cyklick´e ˇcten´ı senzor˚ u, z´apis do akˇcn´ıch ˇclen˚ u prov´ad´ı jen tehdy, pokud obdrˇz´ı od PROFInet aplikace sign´al. Sign´alem pro z´apis do akˇcn´ıch ˇclen˚ u byl opˇet pouˇzit sd´ılen´ y semafor, kter´ y je nastaven komponentou Akv´arium tehdy, jeli poˇzadov´an z´apis do akˇcn´ıch ˇclen˚ u. Hodnoty ze sn´ımaˇc˚ u jsou ˇcteny v celoˇc´ıseln´e podobˇe, desetin´a ˇca´rka m´a pevn´e m´ısto: u hodnoty teploty dˇel´ıme 10, u hodnoty pH a okysliˇcen´ı dˇel´ıme 100. Tuto u ´ pravu prov´ad´ı PROFInet komponenta akv´aria a d´ale tyto hodnoty distribuuje v podobˇe desetin´eho ˇc´ısla (float).
56
Model akvaria
Funkce pro pr´ aci se sd´ılenou pamˇ et´ı Funkce pro pr´aci se sd´ılenou pamˇet´ı opˇet spadaj´ı do IPC n´astroj˚ u pˇredstaven´ ych jiˇz dˇr´ıve. Sd´ılen´a pamˇet’ je speci´aln´ı skupina adres, kter´e vytv´aˇr´ı IPC pro jeden proces a objev´ı se v adresov´em prostoru tohoto procesu. Jin´e procesy si potom mohou tento segment sd´ılen´e pamˇeti pˇripojit ke sv´emu vlastn´ımu adresov´emu prostoru. • shmget() - podobnˇe jako u IPC sign´al˚ u vr´at´ı identifik´ator sd´ılen´e pamˇeti, jenˇz je pak vyuˇz´ıv´an ostatn´ımi funkcemi. • shmat() - pˇripojen´ı sd´ılen´e pamˇeti k aktu´aln´ımu procesu. • shmdt() - odpoj´ı sd´ılenou pamˇet’ od aktu´aln´ıho procesu (pamˇet’ ale z˚ ustane zachov´ana, nen´ı ruˇsena). • shmctl() - funkce pro ˇr´ızen´ı sd´ılen´e pamˇeti (i jej´ı ruˇsen´ı). Pouˇ zit´ı semafor˚ u Pro pr´aci se semafory se pouˇzij´ı tˇri funkce: • semget() - inicializuje sd´ılen´ y semafor a vrac´ı na nˇej identifik´ator. Souˇcasnˇe nastaven atribut (SEM UNDO), aby pˇri ukonˇcen´ı procesu, operaˇcn´ı syst´em zaruˇcil, uvolnˇen´ı semaforu. To znamen´a, pokud je proces pˇri n´ahl´em ukonˇcen´ı v kritick´e sekci, operaˇcn´ı syst´em tuto sekci odemkne. • semop() - operace se semaforem, tato funkce umoˇzn ˇ uje zmˇenu jeho hodnoty o definovanou velikost (obvykle +1 nebo -1). Pokud by hodnota semaforu po proveden´ı t´eto operace mˇela m´ıt z´apornou hodnotu, je vstup do kritick´e sekce zakaz´an - prov´adˇen´ı y k´od a procesu je pozastaveno (BLOKING MODE), nebo funkce jen vr´at´ı chybov´ oˇsetˇren´ı nech´a na program´atorovi (NONBLOKING MODE). • semctl() - pomoc´ı t´eto funkce muˇzeme nastavit semafor na konkretn´ı hodnotu, nebo semafor odstranit z pamˇeti.
5.2
N´ avrh PROFInet komponent
Budeme se zab´ yvat programov´ ym ˇreˇsen´ım PROFInet komponent pouˇzit´ ych k ˇr´ızen´ı modelu a vytvoˇren´ı reprezentace komponenty do n´avrhov´eho prostˇred´ı iMap. Vz´ajemn´e propojen´ı mezi RTAuto objekty je naznaˇceno v pˇr´ıloze 13. Specifikace ˇcinnosti PROFInet komponenty popsan´a d´ale se definuje v souboru sysobj.c.
5.2.1
Vytvoˇ ren´ı IDL popisu komponenty
Vytvoˇren´ y IDL soubor s popisem rozhran´ı komponenty je nejprve kompilov´an pˇrekladaˇcem midl (souˇca´st Micro$oft Visial Studia): midl /Oicf idl.idl.
5.2 N´ avrh PROFInet komponent
57
V´ ystupem je kromˇe jin´ ych soubor idl.tlb, kter´ y je vstupem do konvertoru AMCvtTlb (souˇca´st PROFInetu): AMCvtTlb /noprototypes /prefix=SR idl.tlb. Parametr /noprototypes zakazuje generov´an´ı prototypy funkc´ı pro jejich pˇr´ım´e vol´an´ı, parametr /prefix=SR urˇcuje prefix u n´azv˚ u generovan´ ych datov´ ych struktur, kter´ y mus´ı korespondovat s oznaˇcen´ım v PROFInet komponentˇe. Po t´eto konverzi z´ısk´ame soubory idl t.h a idl t.c, ve kter´ ych jsou datov´e struktury s definic´ı rozhran´ı RTAuto objekt˚ u, viz [2]. Tento soubor je staticky zahrnut do k´odu komponenty (pops´ano v kap. 2.9).
5.2.2
Vytvoˇ ren´ı reprezentace komponenty pro iMap
Pro vytvoˇren´ı XML souboru, kter´ y je vyuˇzit v iMapu jako reprezentace komponenty byl pouˇzit program Component Editor 3 . Program m´a “pˇr´ıvˇetiv´e” uˇzivatelsk´e rozhran´ı, po zad´an´ı n´azvu komponenty, pˇr´ımo definujeme n´azvy vstupn´ıch/v´ ystupn´ıch atribut˚ u RTAuto objekt˚ u a jejich datov´e typy. V´ ystupem tohoto programu je XML soubor, kter´ y lze vloˇzit do knihovny komponent v iMap prostˇred´ı. Strukturu xml souboru lze nal´ezt v [4]. Znaˇcnou nev´ yhodou tohoto programu je, ˇze nedoch´az´ı k souˇcasn´emu generov´an´ı IDL souboru. Program´ator tak mus´ı dvakr´at definovat to sam´e rozhran´ı, vˇzdy v jin´em jazyku.
5.2.3
Komponenta Akv´ arium
Kaˇzd´e z akv´ari´ı je reprezentov´ano jedn´ım RTAuto objektem. Z d˚ uvodu omezen´ı PROFInet serveru v1.2 na poˇcet RTAuto objekt˚ u kter´e mohou b´ yt v jednom LDev objektu (pomˇer 1:1), pˇripad´a na kaˇzd´e akv´arium jeden LDev objekt (obr. 5.3). V PROFInet komponentˇe je Prumyslove PC Physical Device: mitelinux
LDev_Aqa1
LDev_Aqa2
LDev_Aqa3
Obr´azek 5.3: Komponenta akv´arium zaregistrov´an uˇzivatelsk´ y ˇcasovaˇc, kter´ y periodicky spouˇst´ı Callback (kap. 2.8) funkci, a ta ˇcte hodnoty sn´ımaˇc˚ u ze sd´ılen´e pamˇeti a ukl´ad´a je do v´ ystupn´ıch atribut˚ u RTAuto objekt˚ u. Naopak vstupn´ı atributy RTAuto objekt˚ u zapisuje do sd´ılen´e pamˇeti, kde je pˇreb´ır´a a d´ale distribuuje ovladaˇc aˇz po zasl´an´ı sign´alu (viz pˇredeˇsl´a kapitola). Tento sign´al je v´az´an na funkci SysLinux Property Put() 4 , kter´a je v PROFInet komponentˇe vyvol´ana jen tehdy, 3 4
ke staˇzen´ı na str´ ank´ ach www.profibus.com viz soubor sysobj.c
58
Model akvaria
pokud se mˇen´ı vstupn´ı atributy RTAuto objektu. Struktura ˇr´ıd´ıc´ı smyˇcky je zn´azornˇena na obr. (5.4). void DCOM_FKT_HUGE SysLinux_ScanCycleCallBack(...) { SysLinux_ReadValueFromShareMemory(&getvalue); ... // zapsat hodnoty z naˇ cten´ e struktury ‘‘getvalue’’ // do v´ ystupn´ ıch atribut˚ u RTAuto objektu ... } ˇ ıdic´ı smyˇcka pro komponentu Akv´ Obr´azek 5.4: R´ arium
V´ yznam atribut˚ u komponenty Akv´ arium V tab. 5.1 jsou atributy RTAuto objekt˚ u komponenty Akv´arium. Atribut RTAuto Aqa1 oxygenator heating unit basin1 pH basin1 temperature RTAuto Aqa2 light feeding basin2 oxygen basin2 temperature RTAuto Aqa3 pump
Datov´ y typ
I/O V´ yznam
bool bool float float
in in out out
ovl´ad´an´ı vzduchov´an´ı ovl´ad´an´ı vyt´apˇen´ı hodnota pH teplota vody
bool bool float float
in in out out
osvˇetlen´ı krmiˇcka obsah kysl´ıku ve vodˇe teplota vody
bool
in
ovl´ad´an´ı ˇcerpadla
Tabulka 5.1: Atributy komponenty Akv´arium
5.2.4
Komponenta Control
Komponenta je rozdˇelena do tˇr´ı RTAuto objekt˚ u (obr. 5.5): - HeatingControl - ˇr´ızen´ı vyt´apˇec´ı jednotky. - OxygenControl - ˇr´ızen´ı okysliˇcen´ı vody. - ControlStation - komponenta vyuˇzit´a k vizualizaci a k nastaven´ı ˇza´dan´ ych hodnot - teploty a okysliˇcen´ı vody.
5.2 N´ avrh PROFInet komponent
59 PC
Physical Device: suchac01
LDev_HeatingControl
LDev_ControlStation
LDev_OxygenControl
Obr´azek 5.5: Komponenta Control
V´ ystup objekt˚ u (akˇcn´ı veliˇciny) HeatingControl a OxygenControl se generuje jen tehdy, pokud se mˇen´ı nˇekter´ y z jejich vstup˚ u, proto je v´ yhodn´e akce tˇechto RTAuto objekt˚ u zahrnout do funkce SysLinux Property Put(), kter´a je syst´emem PROFInetu vol´ana, pokud nˇekter´ y provider chce prov´est z´apis do atributu RTAuto objektu. Vstupn´ı atributy objektu ControlStation jsou zaps´any do “lok´aln´ıch” promˇenn´ ych (obrazy vstup˚ u). Pro objekt ControlStation je do PROFInet syst´emu zaregistrov´an ˇcasovaˇc s Callback funkc´ı, kter´a cyklicky pˇrepisuje informace (v textov´e podobˇe) na monitoru a generuje hodnoty v´ ystupn´ıch atribut˚ u. V´ yznam atribut˚ u komponenty Control V tab. 5.2 jsou atributy RTAuto objekt˚ u komponenty Control. RTAuto objekt RTAuto HeatingControl m´a informaci o teplot´ach v prvn´ı n´adrˇzi (t1) a v n´adrˇzi 2 (t2) a hodnotu ˇza´dan´e teploty v druh´em akv´ariu (W temperature). Podle velikosti odchylky t1 a t2 od ˇza´dan´e hodnoty je ovl´ad´ano vyt´apˇen´ı prvn´ı n´adrˇze. Objekt RTAuto OxygenControl vyhodnocuje odchylku ˇza´dan´e hodnoty okysliˇcen´ı od skuteˇcn´e hodnoty a podle n´ı ovl´ad´a (zapnuto/vypnuto) vzduchov´an´ı prvn´ı n´adrˇze. Objekt RTAuto ControlStation je urˇcena k vizualizaci a k nastavov´an´ı ˇza´dan´ ych hodnot. Atributy s prefixem set jsou urˇceny k nastaven´ı ˇza´dan´ ych hodnot z extern´ı komponenty nebo napˇr. pˇres webov´e rozhran´ı. Tyto atributy jsou akceptov´any jen tehdy, pokud je komponenta pˇrepnut´a do stavu vzd´ alen´eho ovl´ ad´ an´ı. Jinak je moˇzn´e ˇza´dan´e hodnoty ovlivnit jen z textov´eho rozhran´ı (termin´alu) t´eto komponenty. Stav ovl´ad´an´ı (remote/local) je signalizov´ano atributem remote status a je moˇzn´e ho nastavit jen z textov´eho rozhran´ı komponenty Control. Atributy s postfixem status odpov´ıdaj´ı stavu akˇcn´ıch ˇclen˚ u, vyuˇzito pro jejich monitorov´an´ı. Ovl´ad´an´ı krmen´ı (feeding), osvˇetlen´ı (light) a cirkulace vody (pump) je pouze manu´aln´ı, nen´ı ˇr´ızeno automaticky.
60
Model akvaria
Atribut Datov´ y typ I/O RTAuto HeatingControl t1 float in t2 float in W temperature float in heating unit bool out RTAuto OxygenControl oxygen float in W oxygen float in oxygenator bool out RTAuto ControlStation pH alarm float in t1 float in t2 float in oxygen float in oxygenator status bool in heating status bool in set W temperature float in set W oxygen float in set light bool in set pump bool in set feeding bool in light bool out pump bool out feeding bool out W temperature float out W oxygen float out remote status bool out
V´ yznam teplota v n´adrˇzi 1 teplota v n´adrˇzi 2 ˇza´dan´a hodnota teploty ovl´ad´an´ı vyt´apˇen´ı stav okysliˇcen´ı ˇza´dan´a hodnota okysliˇcen´ı ovl´ad´an´ı oxygenatoru hodnota pH teplota v n´adrˇzi 1 teplota v n´adrˇzi 1 stav okysliˇcen´ı vody oxygenator zapnut/vypnut vyt´apˇen´ı ˇza´dan´a hodnota teploty ˇza´dan´a hodnota okysliˇcen´ı osvˇetlen´ı zapnuto/vypnuto cirkulace vody krmiˇcka akˇcn´ı ˇclen akˇcn´ı ˇclen akˇcn´ı ˇclen akˇcn´ı ˇclen akˇcn´ı ˇclen status vzd´alen´eho ovl´ad´an´ı
Tabulka 5.2: Atributy komponenty Control
5.3 Spuˇ stˇ en´ı komponenty
5.3
61
Spuˇ stˇ en´ı komponenty
Pro u ´ spˇeˇsn´e spuˇstˇen´ı komponenty je nutn´e prov´est tuto sekvenci pˇr´ıkaz˚ u: ych sekc´ı (v - BASE Startup() - inicializace trasovac´ıho syst´emu, inicializace kritick´ nˇekter´ ych syst´emech potˇreba). - RpcInit() - inicializace RPC syst´emu, spuˇstˇen´ı ˇcasovaˇce, kter´ y odpojuje klienty kteˇr´ı neodpov´ıdaj´ı do ˇcasov´eho limitu. - SysLinux DComOsInit() - inicializace DCOM syst´emu, nastaven´ı UUID ˇc´ısla (kap. 1.3) cel´e komponenty. - SysLinux DComOsOpen() - otevˇren´ı portu, spuˇstˇen´ı ping threadu (kap. 2.5). - SysLinux Device Startup() - SysLinux Startup() - vytvoˇr´ı objektov´ y model PROFInetu - PDev s jedn´ım implicitn´ım LDev objektem, kter´e je pozdˇeji nahrazen LDev objektem definovan´ y uˇzivatelem. - SysLinux InitUserObjects() - vytvoˇr´ı objekty LDev, prvn´ı LDev objekt nahrad´ı implicitnˇe definovan´ y pˇredchoz´ı funkc´ı. D´ale inicializuje uˇzivatelsk´e RTAuto objekty i s jejich metodami. - SysLinux StartTimerThread() - spust´ı proces, kter´ y obsluhuje uˇzivatelsk´e ˇcasovaˇce. - SysLinux AttacheToShareMemory() - u komponenty akv´arium se pˇripoj´ıme ke sd´ılen´e pamˇeti. - SysLinux StartScanCycle() - zaregistrujeme uˇzivatelsk´ y ˇcasovaˇc pro cyklus ˇcten´ı/z´apis promˇenn´ ych komponenty. - SysLinux StartPersist Thread() - zvl´aˇstn´ı proces, kter´ y ukl´ad´a informace o propojen´ı mezi RTAuto objekty do pevn´e pamˇeti. - SysLinux Persist InitConnections() - pokud se v pevn´e pamˇeti nach´az´ı informace o propojen´ı mezi objekty, dojde k jejich naˇcten´ı a opˇetovn´emu zaveden´ı. - SysLinux All LDev OnStateChanged() - do t´eto chv´ıle byli vˇsechny LDev objekty ve stavu Ready, v´ ystupy byly na definovan´ ych hodnot´ach (implicitnˇe nulov´e), t´ımto pˇr´ıkazem pˇrejdeme do stavu Operate, norm´aln´ı reˇzim LDev objektu. - msgCGI Init() - spuˇstˇen´ı hlavn´ıho procesu pro webov´e rozhran´ı. Po tˇechto inicializaˇcn´ıch pˇr´ıkazech je vytvoˇreno nˇekolik kooperativnˇe pracuj´ıc´ıch proces˚ u. Ukonˇcovac´ı sekvence pˇr´ıkaz˚ u je analogick´a k inicializaˇcn´ım funkc´ım (opaˇcn´em poˇrad´ı neˇz pˇri spouˇstˇen´ı). Sekvence spouˇstˇen´ı a ukonˇcen´ı bˇehu komponenty je zahrnuta v souboru main.c.
62
Model akvaria
5.4
Konfigurace
Pro interpretaci webov´ ych str´anek byl zvolen webov´ y server Apache verze 1.3.28, s tˇemito zakompilovan´ ymi moduly: http core - neodˇeliteln´a ˇca´st webov´eho serveru; mod cgi -podpora CGI skript˚ u; mod include - podporu SSI5 ; mod alias - pro moˇznost pouˇzit´ı alias˚ u v konfiguraˇcn´ım souboru serveru; mod access - ˇr´ızen´ı pˇr´ıstupu. Server je spuˇstˇen na portu 8000 (zvoleno). CGI skripty jsou smˇeˇrov´any do adres´aˇre ./cgi-bin.
5.4.1
Komponenta Akv´ arium
Tato komponenta je spuˇstˇena na pr˚ umyslov´em poˇc´ıtaˇci. V adres´aˇri /home/profinet se nach´azej´ı vˇsechny n´aleˇzitosti nutn´e pro bˇeh PROFInet komponenty spolu s webov´ ym rozhran´ım a sluˇzbami. Struktura adres´aˇr˚ u je zn´azornˇena v tab. 5.3. Pro komunikaci se Adres´ aˇ r Soubor ./htdocs profinet.shtml query.html profinet.css ./cgi-bin profinet.cgi profinet-soap.cgi ./ PROFInet Aqarium httpd httpd.conf
Popis v´ ychoz´ı str´anka PDev objektu dialog pro ruˇcn´ı zad´an´ı dotazu definice kask´adov´eho stylu skript pro webov´e rozhran´ı skript pro webov´e sluˇzby PROFInet komponenta Apache server konfiguraˇcn´ı soubor Apache
Tabulka 5.3: Adres´aˇrov´a struktura komponenty Akv´arium sn´ımaˇci a akˇcn´ımi ˇcleny se souˇcasnˇe s komponentou spouˇst´ı ovladaˇc sbˇernice RS-485, n´azev ovladaˇce je aquacomm a pˇredpokl´ad´a se, ˇze je uloˇzen v adres´aˇri /home/rs485. PROFInet komponentu je nutn´e spustit s pr´avy uˇzivatele root, webov´ y server m˚ uˇze b´ yt spuˇstˇen pod libovoln´ ym uˇzivatelem, automaticky pˇrejde pod uˇzivatele apache. Pr˚ umyslov´ y poˇc´ıtaˇc, na kter´em bˇeˇz´ı tato komponenta m´a k dispozici 16Mb pamˇeti RAM a 16Mb pamˇeti FLASH (uˇzit´a jako FLASH disk). Proto je komponenta sestavena s nejniˇzˇs´ı moˇznou trasovac´ı u ´ rovn´ı (v´ ysledn´ y k´od je o p˚ ulku menˇs´ı neˇz pˇri pln´em trasov´an´ı) a Apache server jen s nejnutnˇejˇs´ımi moduly, kter´e jsou zahrnuty ve spustiteln´e ˇca´sti Apache serveru. Logovac´ı zpr´avy o bˇehu Apache server jsou nastaveny na minim´aln´ı hodnotu a smˇeˇrov´any do RAM disku6 , protoˇze FLASH disk je pˇri bˇehu syst´emu v reˇzimu pouze pro ˇcten´ı (RO), do reˇzimu z´ apis povolen (RW) se pˇrejde speci´aln´ım pˇr´ıkazem.
5.4.2
Komponenta Control
Komponenta Control je spuˇstˇena na “norm´aln´ım” poˇc´ıtaˇci s operaˇcn´ım syst´emem Linux (pouˇzit RedHat v8.0) s j´adrem 2.4.18. Komponenta muˇze b´ yt po sv´em pˇreloˇzen´ı spuˇstˇena 5 6
Server Side Include oblast v pamˇeti RAM chovaj´ıc´ı se jako pevn´ y disk
Obˇe komponenty byli sestaveny pˇrekladaˇcem gcc verze 2.95.3, nˇekter´e ˇca´sti pro komponentu akv´aria museli b´ yt kompilov´any staticky 7 , kv˚ uly probl´em˚ um s rozd´ılnou knihovnou glibc na obouch syst´emech. Na obr. 5.4 je adres´aˇrov´a struktura, v´ ychoz´ı adres´aˇr je 8 /$(HOME)/PROFInet . Adres´ aˇ r ./Aqaria.Pn ./Aqaria.iMap ./Aqaria Control ./RS485 ./gen ./lib ./v1.2-src ./cgi ./cgi-soap ./apache
Popis zdrojov´e soubory komponenty Akvarium komponenty pro iMap zdrojov´e soubory komponenty Control zdrojov´e soubory ovladaˇce RS485 generovan´e spustiteln´e soubory knihovy PROFInetu zdrojov´e soubory PROFInetu, pˇreloˇzen´e *.o soubory jsou ukl´ad´any do adrseˇre ./lib zdrojov´e soubory CGI skriptu pro webov´e rozhran´ı zdrojov´e soubory CGI skriptu pro poskytov´an´ı webov´ ych sluˇzeb webov´ y server Apache
Tabulka 5.4: Adres´aˇrov´a struktura pro sestaven´ı komponent Souˇca´st´ı zdrojov´ ych soubor˚ u PROFInetu je i webov´e rozhran´ı (adr. ./dcomap/test/linux/webint), kter´e jsou po pˇreloˇzen´ı nakop´ırov´any s ostatn´ımi *.o soubory do adres´aˇre ./lib. Kaˇzd´ y z ˇca´st´ı (adres´aˇr˚ u) m´a sv˚ uj vlastn´ı Makefile soubor pro pˇreloˇzen´ı zdrojov´ ych k´od˚ u.
5.5
HTML str´ anky modelu
Pro vizualizaci modelu akv´aria lze d´ıky webov´emu rozhran´ı pouˇz´ıt i klasick´ y webov´ y prohl´ıˇzeˇc. D´ıky SSI podpoˇre ve webov´em serveru Apache, lze kdekoliv v HTML k´odu str´anky pouˇz´ıt konstrukce: 7 knihovny, kter´e jsou jinak k aplikaci ”pˇrid´ any” aˇz pˇri spuˇstˇen´ı se staticky pˇridaj´ı ke spustiteln´emu k´ odu aplikace. D˚ usledkem je m´ırn´ y n´ ar˚ ust velikosti aplikace. 8 d˚ uleˇzit´e pˇri sestavov´ an´ı aplikace, nutn´e zachovat
64
Model akvaria
Pokud m´a Apache server zapnutou podporu SSI, pˇri interpretaci str´anky uˇzivateli nech´ape tento v´ yraz jako koment´aˇr9 , ale provede specifikovanou akci (zavol´an´ı cgi skriptu s parametry) a v´ ysledek tohoto skriptu vloˇz´ı m´ısto tohoto koment´aˇre. Vzhled takov´eto str´anky je v pˇr´ıloze 14. Popis vˇsech kl´ıˇcov´ ych slov (pˇr´ıkaz˚ u), pouˇziteln´ ych v SSI v´ yrazech lze nal´ezt [13].
5.6
Uˇ zit´ı webov´ ych sluˇ zeb
Byl naps´an jednoduch´ y klient vyuˇz´ıvan´ y k z´ısk´an´ı z´akladn´ıch informac´ı o modelu webov´ ych sluˇzeb. Program je moˇzn´e sestavit pod operaˇcn´ım syst´emem Linux a Microsoft Windows, je naps´an v jazyce C a vyuˇz´ıv´a knihovny z projektu gSOAP [7]. Prov´ad´ı vizualizaci - jednor´azovˇe naˇcte kompletn´ı informace o PROFinet komponentˇe. Klient demonstruje platformn´ı nez´avislosti webov´ ych sluˇzeb. Verze pro operaˇcn´ı syst´em Windows je sestavena v prostˇred´ı Microsoft Visual Studio.
5.7
Shrnut´ı
Na modelu akv´aria jsem demonstroval z´akladn´ı vlastnosti pˇri pouˇzit´ı webov´eho rozhran´ı a webov´ ych sluˇzeb. Protoˇze se jedn´a o pomalou aplikaci, lze rozdˇelit generov´an´ı akˇcn´ı veliˇciny a pˇr´ım´ı kontakt s technologi´ı do dvou komponent propojen´ ych ethernetem (TCP/IP). Stabilita komponent byla testov´ana v konfiguraci uveden´e v pˇr´ıloze 13. D´ale byl ze dvou stanic sledov´an stav webov´ ymi prohl´ıˇzeˇci, pr˚ ubˇeˇznˇe byli z´ısk´av´any souhrn´e informace pomoc´ı webov´ ych sluˇzeb za souˇcasn´eho monitorov´an´ı pomoc´ı prostˇred´ı iMap. Mezi dalˇs´ı podp˚ urn´e programy pro PROFInet od spoleˇcnosti PROFIBUS patˇr´ı PROFInet Test Tool, kter´ y je spuˇstˇen pod operaˇcn´ım syst´emem Windows 2000 a kter´ y umoˇzn ˇ uje zas´ılat dotazy na vˇsechny definovan´e rozhran´ı PROFInetu.
9
v jazyce HTML je koment´ aˇr uvozen symboly:
Z´ avˇ er Tato pr´ace pˇrin´aˇs´ı souhrn poznatk˚ u pˇri adaptov´an´ı PROFInet serveru na operaˇcn´ı syst´em Linux, implementaci webov´eho rozhran´ı pro pˇr´ıstup k PROFInet objekt˚ um pomoc´ı HTTP protokolu a rozhran´ı pro zpracov´an´ı webov´ ych sluˇzeb pˇri komunikaci protokolem SOAP. K demonstrov´an´ı tˇechto vlastnost´ı byly vytvoˇreny dvˇe PROFInet komponenty, kter´e kooperativnˇe ˇr´ıd´ı re´aln´ y model akv´aria. Adaptace PROFInetu do syst´emu Linux byla pˇred m´ ym dokonˇcen´ım uvˇeˇrejnˇena na str´ank´ach organizace PROFIBUS verz´ı adaptace firmy IFAK (Nˇemecko). V´ ysledn´ y k´od samotn´eho PROFInetu pouˇzit v t´eto pr´aci je z ˇca´sti pˇrevzat od firmy IFAK. Z´ıskan´e znalosti pˇri adaptaci mi napomohly k lepˇs´ımu pochopen´ı jednotliv´ ych ˇca´st´ı PROFInet serveru. Linuxov´a implementace je plnˇe funkˇcn´ı a lze s n´ı nahradit implementaci pod operaˇcn´ım syst´emem Windows. Byli testov´any z´akladn´ı vlastnosti chov´an´ı pˇri v´ ypadku komunikace mezi dvˇemi objekty (pouˇzit´ı definovan´e nebo posledn´ı platn´e hodnoty). Komunikace s n´avrhov´ ym prostˇred´ım od firmy Siemens, iMap, je funkˇcn´ı v pln´em rozsahu, tj. konfigurace a n´asledn´e nahr´an´ı propojen´ı mezi objekty, konfigurace QoS, monitorov´an´ı on-line. Pˇr´ıstup pomoc´ı HTTP protokolu je moˇzn´ y bˇeˇzn´ ym internetov´ ym prohl´ıˇzeˇcem. Aktu´aln´ı informace z PROFInetu jsou z´ısk´av´any pˇres webov´e rozhran´ı, kter´e je tvoˇreno CGI skriptem, kter´ y komunikuje pˇr´ımo s PROFInetem. Jako webov´ y server byl pouˇzit Apache v minim´aln´ı konfiguraci (jen s podporou CGI a SSI). Pro vizulizaci akv´aria byla vytvoˇrena webov´a str´anka, kter´a je cyklicky obnovov´ana a kter´a zobrazuje informace o modelu i o objektech PROFInetu - informace o propojen´ı, diagnostika zaˇr´ızen´ı apod. D´ıky SSI podpoˇre v Apache serveru lze tuto dynamickou str´anku vytvoˇrit velice snadno. Popsan´e webov´e rozhran´ı splˇ nuje vˇsechny specifika popsan´e v [4]. Komunikace s komponentou pomoc´ı SOAP protokolu je vhodn´a pro programy vytvoˇren´e napˇr. v jazyku C nebo Java, kter´e jsou zpracov´av´any na platformˇe, na kter´e nelze pouˇz´ıt standardn´ıho komunikaˇcn´ıho protokolu PROFInetu, DCOM. Byly implementov´any sluˇzby, kter´e pokr´ yvaj´ı distribuci z´akladn´ıch vlastnost´ı PROFInetu. Velikou v´ yhodou SOAP protokolu je, ˇze pˇren´aˇsen´a zpr´ava je zaps´ana ve srozumiteln´e formˇe jak pro poˇc´ıtaˇc, tak pro ˇclovˇeka, v jazyce XML. Klient webov´ ych sluˇzeb m˚ uˇze b´ yt naps´an libovoln´ ym n´astrojem, kter´ y um´ı z WSDL popisu sluˇzeb vygenerovat pˇr´ısluˇsn´e funkce. Dalˇs´ım krokem pˇri rozˇsiˇrov´an´ı webov´eho rozhran´ı a sluˇzeb by mˇelo b´ yt: - zabezpeˇcen´ı proti neopr´avnˇen´emu pˇr´ıstupu a to zejm´ena pˇr´ıstup k atribut˚ um RTAuto objekt˚ u, kter´e v t´eto verzi m˚ uˇze kdokoliv pˇres web modifikovat.
66
Z´ avˇ er - implementovat webov´e sluˇzby za pomoci gSOAP knihovny jako stand alone server by uˇsetˇrilo dalˇs´ı, jinak vyuˇziteln´e pamˇet’ov´e m´ısto v pr˚ umyslov´em poˇcitaˇci - nemusel by se pouˇz´ıt webov´ y server Apache pro vyvol´an´ı skriptu.
Literatura ˇ [1] Kamil Vyˇstejn: Diplomov´ a pr´ ace - PROFInet, CVUT FEL, Praha 2003. [2] PROFInet - Implementation Guide v1.2, July 2002, URL: http://www.profibus.com. [3] PROFInet - Architecture Description and Specification v1.0, August 2001, URL: http://www.profibus.com. [4] PROFInet - Architecture Description and Specification v2.0 (kapitola 4), January 2003, URL: http://www.profibus.com. [5] Dalibor Kaˇcm´aˇr: Programujem v COM a COM+, Computer Press 2000 [6] Inline Assembler URL: http://www.manualy.sk/skolycky/skolicka26.txt [7] Elektronick´a dokumentace k projektu http://www.cs.fsu.edu/∼engelen/soap.html.
gSOAP
2.3,
URL:
[8] Projekt gcc, URL: http://www.gnu.org [9] Richard Stones, Neil Matthew: Linux, zaˇc´ın´ ame programovat, Computer Press 2000. [10] Bill O. Gallmeister: POSIX.4: Programing for the Real World, O´Reilly & Associates, Inc. 1995. [11] Martin Kuba: Web Services, UVT-MU 2003. ˇ ıd´ıc´ı syst´em chovu ryb, CVUT ˇ [12] Kelbel Jan: Diplomov´ a pr´ ace - R´ FEL, Praha 2004. [13] Projekt Apache: URL: http://www.apache.org.
68
LITERATURA
Pˇ r´ılohy
Obr´azek 6: Pˇr´ıloha: Datov´a struktura objektu Physical Device
ii
Pˇ r´ılohy
Obr´azek 7: Pˇr´ıloha: Datov´a struktura objektu Logical Device
iii
Obr´azek 8: Pˇr´ıloha: Datov´a struktura objektu RTAuto
iv
Pˇ r´ılohy
Obr´azek 9: Pˇr´ıloha: Implicitn´ı HTML str´anky objektu Physical Device
v
Obr´azek 10: Pˇr´ıloha: Implicitn´ı HTML str´anky objektu Logical Device
vi
Pˇ r´ılohy
Obr´azek 11: Pˇr´ıloha: Implicitn´ı HTML str´anky objektu RTAuto
Obr´azek 12: Pˇr´ıloha: Modifikace atributu objektu RTAuto
vii
Obr´azek 13: Pˇr´ıloha: N´avrh propojen´ı mezi objekty
Obr´azek 15: Pˇr´ıloha: HTML str´anka vytvoˇrena pomoc´ı SSI - komponenta Control
x
Pˇ r´ılohy
Obsah pˇ riloˇ zen´ eho CD Adres´ aˇ r ./Aqaria.Pn/ ./Aqaria.iMap/ ./Aqaria Control/ ./RS485/ ./gen/ ./lib/ ./v1.2-src/
Popis zdrojov´e soubory komponenty Akvarium komponenty pro iMap zdrojov´e soubory komponenty Control zdrojov´e soubory ovladaˇce RS485 generovan´e spustiteln´e soubory knihovy PROFInetu zdrojov´e soubory PROFInetu, pˇreloˇzen´e *.o soubory jsou ukl´ad´any do adrseˇre ./lib ./cgi/ zdrojov´e soubory CGI skriptu pro webov´e rozhran´ı ./cgi-soap/ zdrojov´e soubory CGI skriptu pro poskytov´an´ı webov´ ych sluˇzeb ./apache/ webov´ y server Apache ./gSOAP-linux-2.3/ knihovny pro gSOAP (verze pro linux) ./gSOAP-win32-2.3/ knihovny pro gSOAP (verze pro win32) ./soap-client-linux/ uk´azkov´ y SOAP klient (verze pro linux) ./soap-client-win32/ uk´azkov´ y SOAP klient (verze pro win32) ./docs/ dokumentace ./docs/dp/ diplomnov´a pr´ace v .pdf a .ps verzi ./AllInOne.tar.gz vˇse zabalen´e v archivu zd˚ uvodu zachovan´ı atribut˚ u jednotliv´ ych soubor˚ u
