Diplomov´a pr´ace

(1)

CESK´ˇ E VYSOKÉ U ˇCENÍ TECHNICKÉ V PRAZE

Fakulta elektrotechnick´a

Diplomov´ a pr´ ace

Bc. Martin Ron

Energetick´ e ´ uspory v simulaci digit´ aln´ı tov´ arny

Katedra ˇr´ıdic´ı techniky

Vedouc´ı pr´ace: Ing. Pavel Burget, Ph.D.

(2)

(3)

(4)

(5)

Podˇ ekov´ an´ı

Dˇekuji svým rodiˇc˚um, kteˇr´ı mˇe podporovali v pr˚ubˇehu celého studia a v dobˇe psan´ı této práce obzvláˇst’. Chci také podˇekovat svému vedouc´ımu Ing. Pavlu Burgetovi Ph.D. za jeho veden´ı a cenné rady.

(6)

(7)

Abstrakt

Tato práce se zabývá návrhem pluginu pro digitáln´ı továrnu Tecno- matix - konkrétnˇe pro jej´ı prostˇred´ı Process Simulate. Popisuji zde postup návrhu architektury pluginu pro modelován´ı a simulaci profilu PROFIenergy, jeho programován´ı a jeho pouˇzit´ı pˇri virtuáln´ım zprovoznˇen´ı modelového pˇr´ıpadu. V popisu návrhu architektury pluginu se zabývám návrhem stavového automatu pro simulaci profilu PROFIenergy, ideou jeho pouˇzit´ı v Process Simulate a jeho napojen´ı na jiˇz existuj´ıc´ı komponenty tohoto prostˇred´ı. V ˇcásti o programován´ı mimo jiné vysvˇetluji chován´ı vybraných funkc´ı knihovny Tecnoma- tix.NET API, návrh simulaˇcn´ıho stavového automatu a jeho zaˇclenˇen´ı do prostˇred´ı Process Simulate. Zabývám se dvˇema funkˇcn´ımi strukturami prostˇred´ı Process Simulate CEE - logickým blokem a uˇzivatelskou funkc´ı.

V závˇereˇcné ˇcásti práce popisuji postup pˇri virtuáln´ım zprovozˇnován´ı modelu výrobn´ı buˇnky robotu, jej´ı simulaci a výstupn´ı data ze simulace za pouˇzit´ı vytvoˇreného pluginu.

Kl´ıˇcová slova: Tecnomatix, Process Simulate, stavový automat, Tecno- matix.NET API, virtuáln´ı zprovoznˇen´ı, PROFIenergy

(8)

(9)

Abstract

The scope of this thesis is about design of plugin for digital manufactu- ring tool Tecnomatix - with focus on its suite Process Simulate. I describe here procedure of designing architecture of plugin for modeling and simulation of PROFIenergy profile, its programming and its usage for virtual commissioning of demonstrative robotic cell. During description of design of the plugin architecture I develop system of state automata for simulation of PROFIenergy profile, I explain way of its usage in Process Simulate suite and integration with its existing components. In the part about programming beside other I describe behavior of functionalities I picked up from library Tecnomatix.NET API, I describe design of code implementing state automata and integration of its components with Process Simulate. I furthermore explain the two functioning structures of Process Simulate CEE used in my program - the logic block and the user functions. In the last part of thesis I describe procedure used for virtual commissioning of demonstrative model of production cell of robot, simulation of example and outputted data gained from simulation using developed plugin.

Keywords: Tecnomatix, Process Simulate, state automata, Tecnoma- tix.NET API, virtual commissioning, PROFIenergy

(10)

(11)

(12)

Obsah

1 Uvod´ 1

2 Metodologick´y rozbor 3

2.1 PROFIenergy profil . . . 3

2.2 Tecnomatix . . . 3

2.3 Objektovˇe orientovan´e programov´an´ı a C# . . . 5

3 Reˇˇ sen´ı 8 3.1 Formulace pˇredstavy ˇreˇsen´ı . . . 8

3.2 Stavov´y automat PROFIenergy . . . 11

3.3 V´yvoj architektury pluginu . . . 14

3.4 Uˇzivatelsk´a funkce - implementace stavov´eho automatu . . . 17

3.4.1 Obecn´e vlastnosti a ˇzivotn´ı cyklus uˇzivatelsk´e funkce . . . 17

3.4.2 Pouˇzit´y stavov´y automat . . . 18

3.5 Process Simulate Command . . . 27

3.5.1 Pˇriˇrazen´ı logick´eho bloku . . . 28

3.5.2 Z´aznam PE stav˚u robot˚u . . . 34

3.5.3 Z´aznam polohy kloub˚u robot˚u . . . 35

3.5.4 Grafick´e uˇzivatelsk´e rozhran´ı . . . 36

3.6 Postup pˇri aplikaci pluginu . . . 40

3.6.1 Instalace . . . 41

3.6.2 Pouˇzit´ı . . . 42

(13)

OBSAH

4 Virtu´aln´ı zprovoznˇen´ı 46

4.1 Konverze VKRC ˇr´ıdic´ıch sign´al˚u na PE-ID . . . 47

4.2 Vnitˇrn´ı odliˇsnosti VKRC PE stavov´eho stroje . . . 48

4.3 Demonstraˇcn´ı PLC program . . . 50

4.4 Modelov´an´ı pˇr´ıpadu v Process Simulate . . . 50

4.5 Pˇripojen´ı sign´al˚u . . . 52

4.6 Simulovan´a spotˇreba . . . 54

5 Z´avˇer 57

(14)

Seznam obr´ azk˚ u

1 Z´akladn´ı tˇr´ıvrstv´a architektura Tecnomatixu podle [1] . . . 4

2 Z´akladn´ı architektura pluginu . . . 10

3 Diagram definice PROFIenergy standardu . . . 12

4 Zadáván´ı uˇzivatelských funkc´ı do logických blok˚u . . . 16

5 Diagram upraven´eho stavov´eho automatu pluginu . . . 19

6 Vývojový diagram simulace stavového automatu v uˇzivatelské funkci . . . 24

7 Prototyp logick´eho bloku . . . 29

8 UML diagram commandu . . . 29

9 Postup vytvoˇren´ı uˇzivatelsk´e funkce pomoc´ı API . . . 33

10 GUI - z´aloˇzka nastaven´ı ˇci vytvoˇren´ı logick´eho bloku pro PE . . . 37

11 GUI - chybov´a hl´aˇska - cesta k souboru neexistuje . . . 38

12 GUI - záloˇzka k ovládán´ı záznamu dat ze simulace . . . 39

13 Registrov´an´ı commandu pluginu . . . 41

14 Zaˇrazen´ı tlaˇc´ıtka pluginu v PS . . . 42

15 Workflow pro uloˇzen´ı z´aznam˚u . . . 43

16 Workflow pro pˇriˇrazen´ı ˇci znovunastaven´ı PE funkˇcnosti . . . 44

17 Workflow pro aktivaci záznamu - stejný postup pro klouby i PE stavy robotu 44 18 Pˇrehled logického bloku VKRC PE standardu . . . 49

19 Struktura operac´ı v sekvenˇcn´ı editoru . . . 51

20 Nastaven´ı pˇrechodov´ych podm´ınek operace . . . 51

21 Nastaven´ı pˇripojen´ı k OPC serveru . . . 53

22 Pˇripojen´ı sign´al˚uv Process Simulate k OPC . . . 54

(15)

SEZNAM OBR ´AZK˚U

23 Graf simulovan´e spotˇreby . . . 55 24 Graf zmˇeˇren´e spotˇreby . . . 55

(16)

Seznam tabulek

1 PROFIenergy data z dokumentace pouˇzit´eho kontroleru KRC . . . 14

2 PE ˇcasován´ı a mapován´ı názv˚u parametr˚u uˇzivatelské funkce . . . 23

3 N´azvy stav˚u ve v´yˇctu enStates a jejich ekvivalent v diagramu 5 . . . 25

4 Konverzn´ı funkce VKRC vstup˚u na ID PE stavu . . . 48

5 Obsah CD . . . 59

(17)

SEZNAM V ´YPIS˚U K ´ODU

Seznam v´ ypis˚ u k´ odu

1 Pˇr´ıklad obsahu .csv souboru s PE ˇcasován´ım . . . 30 2 Pˇredloha prázdné uˇzivatelské funkce . . . 45

(18)

1 Uvod ´

V souˇcasnosti se pozornost v naˇs´ı spoleˇcnosti hodnˇe obrac´ı na efektivitu vyuˇzit´ı zdroj˚u.

Plýtván´ı je nˇeco, co si pˇri rostouc´ı spotˇrebˇe nem˚uˇzeme z dlouhodobého hlediska dovolit.

Obzvláˇst’ to plat´ı o plýtván´ı energi´ı. I kdyˇz zat´ım je neefektivn´ı nakládán´ı s energiemi postiˇzeno jen ekonomickými ztrátami, je to dostateˇcná motivace pro oblast automatizo- vané výroby, kde spotˇreba elektrické energie hraje nezanedbatelnou roli. Energetická krize moˇzná nenastoup´ı, kdyˇz budeme schopni dostateˇcnˇe pos´ılit výrobu energie, ale ekonomické hledisko zde z˚ustane v kaˇzdém pˇr´ıpadˇe.

Energeticky úsporný reˇzim elektrických spotˇrebiˇc˚u nen´ı nic nového a zvláˇstˇe v sou- kromém sektoru je u komplikovanˇejˇs´ıch zaˇr´ızen´ı vyˇzadovaným standardem. V automatizaci výroby se vˇsak dlouhodobˇe klade výkon na prvn´ı m´ısto a energetická efektivita je ˇcasto odsouvána do pozad´ı. V posledn´ı dobˇe vˇsak zájem o zefektivnˇen´ı distribuce a nakládán´ı s energi´ı výraznˇe vzrostl. PROFINET & PROFIBUS International (PI) se rozhodl vy- tvoˇrit profil, který by unifikoval principy v úsporných opatˇren´ıch. Mnoho výrobc˚u zaˇr´ızen´ı se zaˇc´ıná postupnˇe pˇripojovat k tomuto novému vývojovému proudu. Nejsp´ıˇs je PI jednou z prvn´ıch organizac´ı, která se t´ımto smˇerem vydává. Technologie zabývaj´ıc´ı se touto proble- matikou je rozhodnˇe perspektivn´ı a dá se pˇredpokládat, ˇze kdo nasmˇeruje své snaˇzen´ı t´ımto smˇerem ted’, z´ıská brzy náskok v rychle se rozv´ıjej´ıc´ım odvˇetv´ı automatizované výroby.

Projekt, na kterém jsem v rámci ˇreˇsen´ı své diplomové práce spolupracoval, je zamˇeˇren právˇe na optimalizaci automatizované výroby z hlediska spotˇreby energie. Zabývá se optimalizac´ı robotických cest pˇri zachován´ı provádˇených operac´ı, plánován´ım pohybu ma- teriál˚u ve výrobn´ı lince a optimalizac´ı sekvenc´ı výrobn´ıch úkon˚u a také vyuˇzit´ım profilu PROFIenergy k úspoˇre energie ve chv´ıl´ıch neˇcinnosti zaˇr´ızen´ı. K simulaci a modelován´ı zkoumaných problém˚u vyuˇz´ıváme software digitáln´ı továrny Tecnomatix. Odtud vzeˇslo zadán´ı mé diplomové práce, protoˇze Tecnomatix jeˇstˇe nepodporuje modelován´ı a simulaci zm´ınˇeného profilu PROFIenergy a pro testován´ı navrˇzených optimalizac´ı je tato funkˇcnost zapotˇreb´ı.

(19)

Hlavn´ım c´ılem tedy bylo naprogramovat pro prostˇred´ı Process Simulate (souˇcást di- gitáln´ı továrny Tecnomatix) plugin, který by umoˇznil modelovat a simulovat PE profil, tento plugin otestovat a vytvoˇrit pro nˇej základn´ı energetický model robota, který je pro testován´ı pouˇzit.

(20)

2 Metodologick´ y rozbor

V této kapitole pop´ıˇsu základn´ı pouˇzitou terminologii a objasn´ım volbu prostˇredk˚u k ˇreˇsen´ı práce.

2.1 PROFIenergy profil

R´ızen´ı a monitorov´ˇ an´ı spotˇreby energie je poˇrád d˚uleˇzitˇejˇs´ı ve vˇsech ˇcástech auto- matizované výroby. Z toho d˚uvodu vznikl na základech standardu PROFINET profil PROFIenergy (dále v textu PE). Úkolem profilu PE je standardizovat rozhran´ı pro z´ıskáván´ı dat o mˇeˇrené energetické spotˇrebˇe a definovat sadu pˇr´ıkaz˚u, které umoˇzn´ı pˇrevádˇet spotˇrebiˇce do energeticky úsporných reˇzim˚u. V souˇcasnosti existuje mnoho zaˇr´ızen´ı, která nˇejakým zp˚usobem mˇeˇr´ı svoji energetickou spotˇrebu a mohou být pˇrevedena do úsporných mód˚u, ale tyto pˇrevody jsou ˇcasto pˇr´ıliˇs ˇcasovˇe nároˇcné ˇci nespolehlivé. PE profil by mˇel tyto nedostatky odstranit a dát do rukou uˇzivatel˚u spolehlivý nástroj k mˇeˇren´ı a managementu energetických spotˇreb. PE profil je zamˇeˇren jak na autonomn´ı rozhodován´ı o pˇreveden´ı do

´

usporn´eho reˇzimu zaˇr´ızen´ı, tak na extern´ı ˇr´ızen´ı spotˇreby. [2]

2.2 Tecnomatix

Digitáln´ı továrna (Digital factory) je obecnˇe soubor programových nástroj˚u, které umoˇz- ˇ

nuj´ı modelovat a simulovat pr˚umyslovou výrobu. Zabývá se ˇcástmi výroby nebo i celými továrnami. Umoˇzˇnuje tak rychle vyv´ıjet nové pracovn´ı postupy a nasazovat je do praxe rychleji, t´ım, ˇze prototyping výroby m˚uˇze prob´ıhat v simulovaném prostˇred´ı, stejnˇe jako testován´ı ˇci validace. Odpadá tak nutnost odstavovat reálnou výrobnu pro d´ılˇc´ı testy a zkra- cuje výraznˇe dobu potˇrebnou na zprovozˇnován´ı linky napˇr´ıklad pˇri zmˇenˇe technologických postup˚u apod.[1][3]

Tecnomatix se snaˇz´ı tomuto ideálu pˇribl´ıˇzit. Jedná se o bal´ık velkého mnoˇzstv´ı nej- r˚uznˇejˇs´ıch nástroj˚u rozˇclenˇených do nˇekolik aplikac´ı oznaˇcovaných jako prostˇred´ı. Dále

(21)

2.2 Tecnomatix

v sobˇe integruje datovou základnu a tzv. eMServer, který zprostˇredkovává pˇr´ıstup k da- tové základnˇe, spravuje pˇr´ıstupy a zpˇr´ıstupˇnuje nˇekteré nástroje ke zmˇenám na datech.

Data jsou tak pˇr´ıstupná pro vˇsechna prostˇred´ı, která v sobˇe Tecnomatix integruje a je tak usnadnˇena kooperace vývojáˇr˚u na vˇsech dotˇcených úrovn´ıch plánován´ı a návrhu výroby.

Z´akladn´ı architektura podle [1] je zobrazena na obr´azku 1. Ve stˇredn´ı vrstvˇe je zobrazeno

Obrázek 1: Základn´ı tˇr´ıvrstvá architektura Tecnomatixu podle [1]

jeˇstˇe datové úloˇziˇstˇe SystemRoot, které je pˇreruˇsovanou ˇcarou spojeno s vrstvou klient˚u.

V SystemRootu jsou ukládána 3D modelovac´ı data k objekt˚um, strojová data pro simulace apod., obvykle bývá SystemRoot na sd´ıleném úloˇziˇsti, ale jeho um´ıstˇen´ı pro klienty nen´ı pevné a ˇcasto klientské aplikace vyuˇz´ıvaj´ı lokáln´ı kopii jen ˇcásti této datové základny oznaˇcované jako SystemRoot.

Zm´ın´ım zde dva hlavn´ı stavebn´ı kameny Tecnomatixu, a totiˇz Process Simulate a Process Designer. Process Designer je nástroj urˇcený pˇredevˇs´ım k plánovac´ım úkol˚um ve výrobˇe, umoˇzˇnuje rychle zobrazovat a analyzovat data týkaj´ıc´ı se výroby a podporuje také 3D zobrazen´ı oblast´ı zájmu. Zprostˇredkuje tedy pˇredevˇs´ım pˇr´ıstup k dat˚um na eMServeru a umoˇzˇnuje kombinovat informace z´ıskané z 3D zobrazen´ı s dalˇs´ımi plánovac´ımi nástroji eMServeru. [4]

Process Simulate (dále v textu ˇcasto jen PS) je pak urˇcen pro designován´ı, analyzován´ı, simulaci a optimalizaci výrobn´ıch proces˚u, a to od té nejvyˇsˇs´ı úrovnˇe - hlediska celé továrny - aˇz po tu nejniˇzˇs´ı - úroveˇn výrobn´ı buˇnky ˇc´ıtaj´ıc´ı tˇreba jediného robota. Obsahuje nástroje

(22)

pro 3D modelován´ı výrobn´ıch zdroj˚u, simulaci v závislosti na ˇcase a také v závislosti na událostech v modelu - jako napˇr´ıklad signál odeslaný z virtuáln´ıho senzoru.[3] Prostˇred´ı PS disponuje reˇzimem nazývanýmCEE (Cyclic Event Evaluation), kde ˇr´ıd´ıc´ı entitou nen´ı ˇ

cas, ale simulované signály a události, napˇr´ıklad signál senzoru pˇribl´ıˇzen´ı apod. Naˇs´ım c´ılem je simulovat novˇe se rozˇsiˇruj´ıc´ı standard PROFIenergy, a to na úrovni jednotlivých zaˇr´ızen´ı, a proto je simulaˇcn´ı prostˇred´ı PS v reˇzimu CEE vhodná volba. Simulace profilu PE je v souˇcasné dobˇe do jisté m´ıry implementována v programu Plant Simulation.

V prostˇred´ı PS se objevuj´ı prvn´ı náznaky zájmu o problematiku energetických spotˇreb.

Napˇr´ıklad KUKA RCS controller v8.3 pro PS umoˇzˇnuje v rámci analýzy pohybu KUKA robot˚u zobrazovat simulovanou energetickou spotˇrebu. Odtud tedy vycház´ı motivace pro programován´ı rozˇs´ıˇren´ı PROFIenergy funkˇcnosti pro Process Simulate.

2.3 Objektovˇ e orientovan´ e programov´ an´ı a C#

V textu zabývaj´ıc´ım se ˇreˇsen´ım práce ˇcasto pouˇz´ıvám term´ıny z objektového progra- mován´ı. Je to výhodný postup i pro vysvˇetlen´ı hierarchie datové struktury studie v Tec- nomatixu, protoˇze i ta je navrˇzena ve smyslu objektového programován´ı. Uvedu tedy jen velice povrchovˇe pouˇzité pojmy.

Objektový pˇr´ıstup k programován´ı se snaˇz´ı o dosaˇzen´ı podobnosti struktury modelo- vaného problému s programem. Objekt v ˇreˇseném problému, napˇr´ıklad robot, obvykle dostane pˇriˇrazen objekt v programu, napˇr´ıklad tˇr´ıdu názvu robot. Robot se um´ı hýbat, tedy i tˇr´ıda bude obsahovat funkce názvu pohyb, která bude mˇenit vnitˇrn´ı promˇennou robotu. ˇReknˇeme, ˇze máme typ robota KUKA a máme od nˇej v továrnˇe tˇri kusy, pak ob- jektovˇe modelovaná paralela bude m´ıt tˇr´ıdu KUKA a budeme od této tˇr´ıdy vytváˇret tˇri instance (lze chápat jako realizace). Vztahtˇr´ıda - instance lze tedy chápat jako vztahtyp - realizace. Instance tˇr´ıdy mus´ı být vytvoˇrena tzv. konstruktorem - speciáln´ı metodou pro generaci instance. Pokud je konstruktor úmyslnˇe znepˇr´ıstupnˇen, obvykle je nˇekde jinde vy- tvoˇrena tzv. továrn´ı metoda, která má ke konstruktoru zprostˇredkovaný pˇr´ıstup a zajiˇst’uje proveden´ı nˇejakých pˇr´ıdavných úkon˚u pˇri vytváˇren´ı instance. Dalˇs´ı uˇziteˇcnou vlastnost´ı

(23)

2.3 Objektovˇe orientovan´e programov´an´ı a C#

je tzv. dˇediˇcnost. Tˇr´ıda m˚uˇze dˇedit od jiné tˇr´ıdy, jako pˇr´ıklad mˇejme tˇr´ıdu robot a od n´ı dˇed´ıtˇr´ıda KUKA. Teprve aˇz kdyˇz máme ve výrobn´ı buˇnce konkrétn´ı kusy robot˚u KUKA, jedná se o instance. Tˇr´ıda také m˚uˇze být statická a m´ıt statické metody. Taková tˇr´ıda dokáˇze vykonávat své funkce (poskytovat hodnoty statických promˇenných, nechat na sobˇe volat statické metody apod.) aniˇz by mˇela vygenerovanou svoji instanci. Dalˇs´ım nástrojem pro zpˇrehlednˇen´ı kódu je tzv. implementován´ı rozhran´ı. Rozhran´ı je zvláˇstn´ı datový typ, který neobsahuje naprogramovanou funkˇcnost, ale pouze výˇcet metod a promˇenných. Kdyˇz nˇekterá tˇr´ıda implementuje rozhran´ı, znamená to, ˇze je zaruˇceno, ˇze tato tˇr´ıda má v sobˇe naprogramovanou funkˇcnost vˇsech metod a obsahuje vˇsechny promˇenné, které jsou dekla- rovány v rozhran´ı. Kontrolu existence hlaviˇcek metod a promˇenných provád´ı pˇrekladaˇc kódu.

Je tˇreba upozornit na term´ınvlastnost tˇr´ıdy. Je to zvláˇstn´ı druh metody, která z´ıskává nebo nastavuje hodnoty promˇenné v tˇr´ıdˇe. Navenek pˇritom vypadá jako promˇenná a pouˇz´ıvá se jako promˇenná. Jej´ım pouˇzit´ım jsou tak zapouzdˇreny obˇe metody, které jsou pro z´ıskán´ı a nastaven´ı promˇenné zapotˇreb´ı. Vlastnost tˇr´ıdy zpˇrehledˇnuje a zjednoduˇsuje pouˇz´ıván´ı soukromých promˇenných t´ım, ˇze programátor s vlastnost´ımanipuluje stejnˇe jako kdyby se jednalo o obyˇcejnou promˇennou.

Dále se jeˇstˇe zm´ın´ım o událostech tzv.events. Jedná se o jakési vlajky, které ˇr´ıkaj´ı, ˇze se v programu stalo nˇeco, na co jsme chtˇeli dostat upozornˇen´ı. Událostem se pak pˇriˇrazuj´ı po- sluchaˇci - metody, které v okamˇziku vzniku události nˇejak reaguj´ı. Napˇr´ıklad kdyˇz uˇzivatel stiskne tlaˇc´ıtko v uˇzivatelském rozhran´ı, vznikne událost a obsluˇzná nebo téˇz naslouchaj´ıc´ı metoda tuto událost obslouˇz´ı nˇejakou reakc´ı. Výhoda spoˇc´ıvá v niˇzˇs´ım výpoˇcetn´ım zat´ıˇzen´ı, protoˇze dokud nevznikne událost, ˇzádné obsluˇzné výpoˇcty se neprovád´ı.

Nakonec k dˇediˇcnosti. Typicky vˇsechny tˇr´ıdy maj´ı svého pˇredka krom jediné, od které zprostˇredkovanˇedˇed´ıvˇsechny tˇr´ıdy. Podobnˇe je tomu u datové struktury Tecnomatixu, kde je nejvyˇsˇs´ı úroveˇn projekt, a vˇse ostatn´ı patˇr´ı pod nˇej. Mohou zde být paraleln´ı projekty, ale nemohou být naˇcteny najednou v jednom prostˇred´ı.

Dalˇs´ı ot´azkou byla volba programovac´ıho jazyka. Tecnomatix.NET API n´as omezuje na

(24)

jazyky pro platformu .NET, tu vˇsak podporuj´ı v základˇe tˇri programovac´ı jazyky, které jsou zároveˇn dokumentovány v [5], jedná se o jazyky:

• Visual Basic .NET

• C++

• C#

Kdyˇz jsem procházel dokumentaci [5], nejlépe zdokumentována byla syntaxe C#, proto jsem zvolil pro vývoj pluginu tento jazyk. Jako vývojové prostˇred´ı jsem pouˇzil MS Visual Studio.

Pouˇzil jsem zde pojemAPI, to znamenáApplication Programming Interface, v pˇrekladu rozhran´ı pro programován´ı aplikac´ı. Je to obvykle knihovna tˇr´ıd a metod, které zprostˇredkuj´ı unifikovaný pˇr´ıstup do ucelené aplikace, aby mohla být obohacena o nˇejakou rozˇsiˇruj´ıc´ı funkˇcnost.

(25)

3 Reˇ ˇ sen´ı

Nástroje pro ˇreˇsen´ı jsou dány zadán´ım práce. Nejprve jsem tedy prozkoumal moˇznosti, které nab´ız´ı knihovny softwaru Tecnomatix. Ukázalo se, ˇze API pro vývoj aplikac´ı pro Tecnomatix je velmi rozsáhlé, a pˇresto nepokrývá vˇsechny prostˇredky, které bych pro pro- gramován´ı pluginu rád vyuˇzil. Tecnomatix je uzavˇrená aplikace bez moˇznosti zkoumán´ı jej´ıho zdrojového kódu, tato softwarová politika výrobce na mˇe kladla výrazná omezen´ı, která bylo nutno obcházet ˇci jinak redukovat. Pro vývoj pluginu jsem postupnˇe navrhl celkem tˇri ˇreˇsen´ı, pˇriˇcemˇz prvn´ı dvˇe se dostala do slepé uliˇcky teprve v pr˚ubˇehu jejich vývoje.

Poˇzadovaného výsledku jsem dosáhl aˇz ve tˇret´ı generaci pluginu.

3.1 Formulace pˇ redstavy ˇ reˇ sen´ı

Pˇri n´avrhu ˇreˇsen´ı jsem ale vˇzdy pouˇzil z´akladn´ı ideovou strukturu, kterou nyn´ı pop´ıˇsu.

Protoˇze profil PROFIenergy (dále jen PE) v základu popisuje stavový automat, je páteˇr´ı mého pluginu vˇzdy stavový automat. Tento automat mus´ı m´ıt nastavitelné ˇcasové podm´ınky pˇrechodu mezi stavy, pˇriˇcemˇz ˇcas se uvaˇzuje jako podm´ınka jen mezi pevnˇe danými stavy.

Zároveˇn je zde pˇrirozenˇe poˇzadavek na to, aby pouˇzit´ı stavového automatu hladce zapa- dalo do struktury simulace v prostˇred´ı Process Simulate (dále jen PS), protoˇze plugin by mˇel být pouˇzit na jiˇz existuj´ıc´ı projekty a studie. Z toho také vyplývá nutnost zachovat konzistenci jiˇz existuj´ıc´ıch datových struktur studie.

Tento poˇzadavek nelze s ohledem na ostatn´ı poˇzadavky stoprocentnˇe uspokojit. Pokud pouˇziji kv˚uli poˇzadavku na kompatibilitu pouze datové struktury, které jsou v Tecnoma- tixu jiˇz vytvoˇreny, nelze s jistotou urˇcit, zda v´ıcenásobné pouˇzit´ı v nˇekteré studii nepovede k naruˇsen´ı funkce studie. Pˇr´ıkladem m˚uˇze být tˇreba ˇreˇsen´ı pomoc´ı operac´ı. V prostˇred´ı PS operace mohou reprezentovat nesimulované ˇcasové úseky (tzv. non-sim operace), nab´ız´ı se tedy moˇznost vyuˇzit´ı tˇechto operac´ı k simulován´ı pˇrechodu mezi jednotlivými PE stavy.

Non-sim operace vˇsak v nˇekterých studi´ıch uˇz mohly být k simulován´ı pouˇzity a mohlo by se stát, ˇze by m˚uj plugin pojmenoval operaci stejnˇe a vznikla by tak duplicita, která m˚uˇze

(26)

vést k nestabilitˇe PS. Kaˇzdý objekt ve studii má sice vlastn´ı unikátn´ı ID, jenˇze naˇc´ıtán´ı tohoto ID z eMServeru je pomalé, obzvláˇst’ pokud je provádˇeno na vzdálené klientské stanici.

Takové ˇreˇsen´ı nen´ı nejvhodnˇejˇs´ı. Samotný PS nejsp´ıˇse vyuˇz´ıvá nˇejaký zp˚usob indexován´ı objekt˚u, ale nen´ı moˇzné k tomuto indexován´ı pˇristupovat pomoc´ı API, a tak jediné spo- lehlivé ˇreˇsen´ı za pouˇzit´ı Tecnomatix API je skuteˇcnˇe pouˇz´ıt unikátn´ı jméno operace. Lze samozˇrejmˇe pouˇz´ıt dostateˇcnˇe komplikované jméno, takˇze se duplicita stane sp´ıˇse otázkou pravdˇepodobnosti. To je jen jedna ukázka toho, jaké problémy z posledn´ıho poˇzadavku vyplývaj´ı.

Dalˇs´ı výrazný poˇzadavek je hromadné pouˇzit´ı pluginu. Uˇzivatel pˇred sebou m˚uˇze m´ıt des´ıtky zaˇr´ızen´ı ve studii. U kaˇzdého tohoto zaˇr´ızen´ı chce modelovat a simulovat pomoc´ı pluginu profil PE a vzniklá reˇzijn´ı data mus´ı z˚ustat v mez´ıch pˇrehlednosti typických pro zaˇzitou praxi. Komplexita prostˇred´ı Tecnomatix pˇrirozenˇe vede k ohromnému mnoˇzstv´ı dat uˇz jen v prostˇred´ı PS, a to pro kaˇzdou studii. Tato data se tˇr´ıd´ı podle r˚uzných kritéri´ı a uˇzivatelé by mˇeli být zvykl´ı pracovat s pomˇernˇe rozsáhlou mnoˇzinou jednotlivých typ˚u dat. Ovˇsem na nejvyˇsˇs´ı úrovni tˇr´ıdˇen´ı dat by nemˇel plugin vytváˇret v´ıce neˇz pár datových entit pro jedno zaˇr´ızen´ı, které by mˇelo disponovat PE funkcionalitou. Tento poˇzadavek vyplynul z okolnost´ı aˇz ˇcasem, kdy se ukázal v té dobˇe zvolený postup jako nevhodný právˇe kv˚uli velkému mnoˇzstv´ı vytváˇrených datových objekt˚u na jedno zaˇr´ızen´ı, se kterými se musel uˇzivatel potýkat ve studii, aniˇz by je potˇreboval pˇr´ımo upravovat.

Plugin má nejen simulovat chován´ı zaˇr´ızen´ı podle PE standardu, ale mus´ı umoˇzˇnovat i zaznamenávat pr˚ubˇeh pˇrechod˚u a setrváván´ı v jednotlivých PE stavech. Je tedy nutné umoˇznit vytvoˇren´ı nˇejakého druhu databáze, v n´ıˇz by kaˇzdé dotˇcené zaˇr´ızen´ı mˇelo uchováno záznam svých stav˚u v závislosti na simulovaném ˇcase. Tato databáze mus´ı být na poˇzadavek uˇzivatele zpˇr´ıstupnˇena prostˇrednictv´ım souboru, aby bylo moˇzné v extern´ım programu analyzovat výsledky simulace.

Vˇsechny v´yˇse zm´ınˇen´e poˇzadavky na tomto m´ıstˇe shrnu.

• Integrovatelnost do prostˇred´ı Tecnomatix

(27)

3.1 Formulace pˇredstavy ˇreˇsen´ı

• Stavov´y automat zahrnuj´ıc´ı ˇcasov´e podm´ınky pˇrechodu

• Konzistence dat

• Hromadn´e pouˇzit´ı

V souˇcasné verzi pluginu jsem tedy vzhledem k tˇemto poˇzadavk˚um sledoval následuj´ıc´ı rozdˇelen´ı. Zamˇeˇril jsem se na prostˇred´ı Process Simulate (PS), protoˇze v nˇem je studie si- mulována, je tedy logické, ˇze na tomto m´ıstˇe by se mˇela funkˇcnost PE standardu zaˇr´ızen´ım pˇriˇrazovat. Základn´ı ˇcást´ı pluginu je stavový automat. Tato ˇcást mus´ı být co nejlépe inte- grována do PS a mus´ı s n´ım co nejménˇe interferovat. Dalˇs´ım stavebn´ım kamenem je ˇcást pro záznam stav˚u v ˇcase pro kaˇzdé dotˇcené zaˇr´ızen´ı. Tato ˇcást bude napojena na stavový automat a na simulátor integrovaný v PS. Nav´ıc bude podporovat export záznam˚u do souboru. Tˇret´ı souˇcást´ı pluginu je správce pˇredchoz´ıch dvou ˇcást´ı, který má za úkol pˇriˇrazovat zaˇr´ızen´ım ve studii PE funkˇcnost realizovanou stavovým automatem a dále má za úkol spravovat záznam stav˚u. Konfigurace stavového automatu pro konkrétn´ı ˇcasován´ı automatu naˇctené ze souboru také spadá do jeho pole p˚usobnosti. Vˇsechny tˇri souˇcásti mus´ı být zastˇreˇseny uˇzivatelským rozhran´ım. Popsaná architektura pluginu je vidˇet na obrázku 2.

Pˇreruˇsovaná spojnice mezi blokem Stavový automat a Záznam PE stav˚u zaˇr´ızen´ı znaˇc´ı výmˇenu dat.

Obr´azek 2: Z´akladn´ı architektura pluginu

(28)

Pˇri vytváˇren´ı pˇredstavy o realizaci této architektury jsem se pro splnˇen´ı poˇzadavku na integrovatelnost drˇzel myˇslenky, ˇze datová struktura mus´ı být alespoˇn ˇcásteˇcnˇe vytvoˇritelná manuáln´ım zadáván´ım pˇr´ıkaz˚u v prostˇred´ı PS. Zkombinován´ı jiˇz existuj´ıc´ıch stavebn´ıch ka- men˚u by mˇelo vést k integrovatelnému ˇreˇsen´ı. Pokusil jsem se tedy vˇzdy nejdˇr´ıve sestavit funkˇcn´ı prototyp datové struktury manuálnˇe v PS a pomoc´ı nˇej simulovat PE funkcionalitu. Kdyˇz jsem dospˇel k funkˇcn´ımu prototypu, pˇreˇsel jsem k programován´ı automatického sestaven´ı této struktury. Uˇzivatel ve výsledku mus´ı m´ıt k dispozici nástroj, který bude s rozumnou nároˇcnost´ı umoˇzˇnovat vytváˇren´ı a konfiguraci této struktury. Podobnˇe jsem pak zaˇcal programovat také záznamovou ˇcást pluginu. Pak je na ˇradˇe refaktoring kód˚u a ladˇen´ı.

3.2 Stavov´ y automat PROFIenergy

Profil PROFIenergy je v [2] rozsáhle popisován do detail˚u. Jsou zde popsány protokoly komunikace, zp˚usob ovládán´ı a mnoho dalˇs´ıch d˚uleˇzitých aspekt˚u, které jsou d˚uleˇzité pro výrobce, jenˇz chce ve svém zaˇr´ızen´ı implementovat funkci PE standardu. Pro potˇreby simulace a modelován´ı tohoto standardu v prostˇred´ı Process Simulate je pro mˇe vˇsak esenciáln´ı právˇe definice stavového automatu PE a ˇcásteˇcnˇe také protokol ovládán´ı - konkrétnˇe popis zp˚usobu, jakým má být zaˇr´ızen´ı pˇrevádˇeno do jednotlivých energetických mód˚u. Ostatn´ı aspekty profilu PE tedy nebudu zmiˇnovat.

Standard PROFIenergy (PE) definuje podle [2] mód Operate, Ready to operate, 31 ad- resovatelných Energy-saving mód˚u, Sleep mode a Power off mód. Diagram mód˚u a po- volených pˇrechod˚u mezi nimi je znázornˇen na obrázku 3. Ve stˇredn´ım sloupci se nacház´ı PE módy, kterých zaˇr´ızen´ı m˚uˇze dosáhnout. Kdyˇz zaˇr´ızen´ı pˇrecház´ı mezi módy, nevrac´ı na vyˇzádán´ı ID, které by popisovalo tento jeho stav. Z hlediska aplikace PE standardu to ani nen´ı bezpodm´ıneˇcnˇe nutné a benefity, které by z této informace vyplývaly, jsou zanedbatelné, pˇr´ıpadnˇe nahraditelné. Aby PE standard byl samostatný modulárn´ı celek, jsou tyto postupy v´ıce neˇz pochopitelné. Standard jako takový nav´ıc modeluje ve svém stavovém automatu i pˇrechodové stavy mezi jednotlivými PE módy. Jak je na diagramu 3

(29)

3.2 Stavov´y automat PROFIenergy

Obr´azek 3: Diagram definice PROFIenergy standardu

vidˇet, standard pˇredpokládá moˇznost pˇrecházen´ı i mezi pˇrechodovými stavy. Také z jednot- livýchEnergy-saving mód˚u je moˇzno pˇrej´ıt zpˇet do stav˚uPˇrechod do Energy-saving. Velké mnoˇzstv´ı pˇrechod˚u je vˇsak podle standardu pouze volitelných. Je nutné splnit podm´ınku, ˇze alepsoˇn jeden pˇrechod vede do nˇekterého zEnergy-saving mód˚u a alespoˇn jeden pˇrechod vede zEnergy-saving módu doReady to operate módu. Nav´ıc jsou pak volitelné pˇrechody mezi jednotlivými Energy-saving módy, to uˇz záleˇz´ı na výrobci zaˇr´ızen´ı.

Dalˇs´ım volitelným módem je jeˇstˇeSleep mode WOL. Ten má oproti standardn´ımEnergy- savingmód˚um zvláˇstn´ı chován´ı. Jedná se o úsporný mód vyvinutý p˚uvodnˇe pro pr˚umyslové

(30)

poˇc´ıtaˇce [2]. Zaˇr´ızen´ı do tohoto módu m˚uˇze pˇrej´ıt, ale v pr˚ubˇehu pˇrechodu dojde k odpojen´ı sbˇernice a zaˇr´ızen´ı tak nem˚uˇze pˇrij´ımat ˇzádné pˇr´ıkazy profilu PE po sbˇernici. Sbˇernice se zapne aˇz po pˇrijet´ı speciáln´ıho probouzec´ıho packetu, tzv. Magic Packet. Po probuzen´ı je definováno v PE standardu, ˇze zaˇr´ızen´ı automaticky pˇrejde do stavu Ready to operate.

Profil PE poˇc´ıtá i se stavem Power off, je to pˇrirozený stav zaˇr´ızen´ı, kdy je zcela odpojeno od pˇr´ıvodu energie. Tento stav je termináln´ı a podobnˇe jako v pˇr´ıpadˇe stavu Sleep mode WOLnen´ı napájená sbˇernice a nen´ı moˇzné komunikac´ı pˇres PROFINET zaˇr´ızen´ı zapnout. Tento stav tedy do stavového automatu nen´ı zahrnut, nepˇredpokládá se ani moˇznost vypnout zaˇr´ızen´ı pomoc´ı nˇejakého pˇr´ıkazu PE profilu, protoˇze by taková moˇznost postrádala smysl pro PE. Formálnˇe je ale tento stav alespoˇn uveden a má i své Mode ID.

Ovládán´ı pˇrechod˚u je realizováno pomoc´ı kombinace nˇekolika signál˚u. Prvn´ım je pˇr´ıkaz, ten m˚uˇze nabývat tˇr´ı hodnot, a totiˇz Start Pause,End Pause aGo Sleep Mode WOL. Pˇri pouˇzit´ı prvn´ıho pˇr´ıkazu Start Pause je oˇcekáván jeˇstˇe signál s ID poˇzadovaného Energy- saving módu. V pˇr´ıpadˇe prvn´ıch dvou ˇr´ıdic´ıch pˇr´ıkaz˚u signál poˇzadovaného módu nehraje roli, pˇri pˇr´ıkazu Go Sleep Mode WOL se pˇrejde do módu Sleep mode WOL, pˇri pˇr´ıkazu End Pause se zaˇcne pˇrecházet pˇr´ımo do módu Ready to operate. Pro pˇr´ıkazStart Pause je jeˇstˇe d˚uleˇzitý parametr pˇr´ıkazu, v nˇemˇz by mˇela být pˇredána doba, na kterou je poˇzadovaná pauza zaˇr´ızen´ı, neˇz jej bude potˇreba pˇrevést do stavu Ready to operate. V pˇr´ıpadˇe, ˇze se zaˇr´ızen´ı dokáˇze autonomnˇe rozhodovat, který Energy-saving mód je pro tuto dobu nej- vhodnˇejˇs´ı, pouˇzije se pˇredaný parametr jako rozhodovac´ı kritérium.

Zaˇr´ızen´ı, které máme k dispozici, je kontroler KUKA RCS v8.2. Tento kontroler podporuje profil PROFIenergy ve velmi základn´ı podobˇe. Podporuje jeden Energy-saving mód a podporuje i mód Sleep mode WOL. Krom toho pˇrirozenˇe podporuje i Ready to operate a Operating. Mezi módy jsou implementovány jen základn´ı nutné pˇrechody, ˇzádný z voli- telných nen´ı implementován. Je sice moˇzné vyslat poˇzadavek na nepodporované pˇrechody mezi stavy, ale taková akce vede k nepˇredv´ıdatelnému chován´ı kontroleru, proto jsem ne- povolené pˇrechody neuvaˇzoval. Náˇs kontroler také nedisponuje autonomn´ım rozhodován´ım o Energy-saving módech, volba úsporného reˇzimu záleˇz´ı pouze na ˇr´ıdic´ım PLC. V doku-

(31)

3.3 V´yvoj architektury pluginu

mentaci kontroleru jsou uvedena data k jednotlivým energetickým mód˚um, jak je vidˇet v tabulce 1.

Jm´eno m´odu Drive Bus OFF Hibernate Ready to operate

Jm´eno dle PE Energy-saving Sleep mode WOL Ready to operate

Trv´an´ı pˇrechodu do m´odu 5s 50s 0

Trv´an´ı pˇrechodu doOperate 20s 50s 0

Minim´aln´ı doba setrv´an´ı 0 10s 0

Energetick´a spotˇreba 150W 30W 220W

Tabulka 1: PROFIenergy data z dokumentace pouˇzit´eho kontroleru KRC

Pozdˇeji se pˇri mˇeˇren´ı spotˇreby v jednotlivých stavech ukázalo, ˇze reálná spotˇreba se od té v dokumentaci m´ırnˇe liˇs´ı, jak je znát z grafu 24.

3.3 V´ yvoj architektury pluginu

Postup popisovaný v podkapitole 3.1 jsem stavˇel na myˇslence, ˇze veˇskeré pˇr´ıkazy, které jsou umoˇznˇeny zadávat uˇzivateli manuálnˇe, je moˇzné zadávat i prostˇrednictv´ım API pro- stˇred´ı PS. Tato myˇslenka se ukázalá být z ˇcásti chybná.

V prvn´ı generaci pluginu jsem modeloval stavový automat pomoc´ı non-sim operac´ı, které umoˇzˇnovaly vynutit v simulaci ˇcasovou prodlevu. Podm´ınky pˇrechodu mezi stavy pak zajiˇst’ovalyTransition condition, které se kontroluj´ı na konci operace. Záznam o dobˇe strávené v jednotlivých PE stavech byl poˇrizován na základˇe informace, která operace je právˇe aktivn´ı.

Toto ˇreˇsen´ı mˇelo samo o sobˇe uˇz v prototypu slabá m´ısta. Nˇekteré operace mˇely nulovou délku trván´ı a pouˇz´ıvaly se jako pomocné operace k rozhodován´ı, do které z alternativn´ıch operac´ı se pˇrejde v dalˇs´ım kroku simulace. V takovém pˇr´ıpadˇe operace byla pˇri simulaci v aktivn´ım stavu, aˇckoliv uˇz byla aktivn´ı i jiná operace. Záleˇzelo zˇrejmˇe na vnitˇrn´ım poˇrad´ı

(32)

vyhodnocován´ı operac´ı v simulátoru. Toto chován´ı by bylo jeˇstˇe moˇzné odfiltrovat analýzou vzniklých dat, vyvstal vˇsak jiný problém. Pomoc´ı API nelze nastavovat Transition condition operac´ı tak, jako to lze udˇelat manuálnˇe v prostˇred´ı PS. Tato skuteˇcnost nebyla zpoˇcátku známá kv˚uli nedostateˇcné dokumentaci API, zjistil jsem ji aˇz v pr˚ubˇehu ˇreˇsen´ı.

V dobˇe, kdy jsem vyv´ıjel prvn´ı generaci pluginu, byla vypuˇstˇena verze Tecnomatix 10.

V t´eto verzi pokus o nastaven´ı zˇretˇezen´ı operac´ı pˇres API zp˚usoboval p´ad prostˇred´ı PS.

V následuj´ıc´ı verzi Tecnomatix 11.0 sice tento problém byl odstranˇen, stále ovˇsem chyb´ı moˇznost nastavovatTransition condition operac´ı, takˇze jsem musel hledat jiné ˇreˇsen´ı.

Druhá generace pluginu byla postavena na tzv. logických bloc´ıch. To je struktura, která umoˇzˇnuje v PS pˇriˇrazovat urˇcitým objekt˚um jisté logické chován´ı. Dokonce umoˇzˇnuje pouˇz´ıvat vnitˇrn´ı promˇenné pro jednotlivé bloky. Z mého hlediska pak nejpodstatnˇejˇs´ı vlastnost´ı logických blok˚u byla moˇznost pozdrˇzet výstupn´ı hodnotu o pˇresnˇe definovaný ˇcasový

´

usek. Výstup byl pak vˇzdy opoˇzdˇen o tento ˇcas. Vytvoˇril jsem tedy prototyp s ˇretˇezcem logických blok˚u, kde jeden logický blok reprezentoval jeden PE stav. Musel jsem se tak vzdát moˇznosti pˇriˇrazen´ı stavového automatu pˇr´ımo pod zaˇr´ızen´ı, jehoˇz PE chován´ı si- muluje. Pro jeden stavový automat bylo zapotˇreb´ı celkem 9 logických blok˚u. Je jasné, ˇze se vzr˚ustaj´ıc´ım poˇctem zaˇr´ızen´ı, na které by byl plugin pouˇzit, by neúnosnˇe rostl i poˇcet blok˚u, které by musel uˇzivatel procházet pˇri své práci se studi´ı. Nevhodné smazán´ı nebo odpojen´ı kteréhokoli bloku by naruˇsilo funkcionalitu stavového automatu. Toto ˇreˇsen´ı vedlo k funkˇcn´ımu prototypu a bylo i moˇzné tento prototyp zreprodukovat za pouˇzit´ı API, ale ze zjevných d˚uvod˚u jsem od nˇej upustil.

Tˇret´ı generace pluginu uˇz plnˇe odpov´ıdá poˇzadované architektuˇre, jak je znázornˇena v diagramu na obrázku 2. Stavový automat je realizován pomoc´ı uˇzivatelské funkce. Prostˇred´ı Process Simulate umoˇzˇnuje pouˇz´ıvat takzvané logické bloky - objekty, které umoˇzˇnuj´ı simulovat jistou omezenou logiku. V rámci tˇechto objekt˚u mohou být nastaveny vnitˇrn´ı parametry nebo výstupy na základˇe výsledku výpoˇctu této uˇzivatelské funkce. Prostˇred´ı PS uˇz od prvotn´ı instalace obsahuje nˇekolik základn´ıch uˇzivatelských funkc´ı, jsou jimi detekce nábˇeˇzné hrany (RE ( X ) - rising edge), detekce sestupné hrany (FE ( X ) - falling

(33)

3.3 V´yvoj architektury pluginu

edge), dvˇe verze bistabiln´ıho klopného ˇclenu (SR ( X Y ) - set-reset aRS ( X Y ) - reset- set), generátor náhodného ˇc´ısla (RANDOM ( minValue maxValue )) a výpoˇcet absolutn´ı hodnoty (ABS ( Num )). Pˇri pouˇz´ıván´ı RS funkce jsem zjistil, ˇze nefunguje správnˇe - pˇri nastaven´ı prvn´ıho jej´ıho parametru X na hodnotutrue nespadne jej´ı výstup na false, jak by mˇel. Funkce SR naproti tomu funguje správnˇe a liˇs´ı se od RS jen poˇrad´ım vstupn´ıch parametr˚u. Stejnˇe jako je tomu u RS a SR ˇclen˚u, i pro náˇs plugin je zapotˇreb´ı vnitˇrn´ı pamˇeti. Uˇzivatelská funkce toto zjevnˇe umoˇzˇnuje a zároveˇn nezveˇrejˇnuje nikde v PS své vnitˇrn´ı promˇenné, a tak nevzniká problém s nepˇrehlednost´ı studie pro uˇzivatele. Uˇzivatelská funkce se tedy jev´ı jako ideáln´ı nástroj k realizaci stavového automatu.

Na tomto m´ıstˇe mus´ım vˇsak upozornit na ´uskal´ı pouˇzit´ı uˇzivatelsk´ych funkc´ı v PS. Jak

Obrázek 4: Zadáván´ı uˇzivatelských funkc´ı do logických blok˚u

je vidˇet na obrázku 4, parametry uˇzivatelských funkc´ı se zadávaj´ı ve volnˇe textové podobˇe.

To m˚uˇze svádˇet k pˇripodobˇnován´ı funkce k nˇekterým programovac´ım jazyk˚um, kde jako vstupn´ı parametr funkce m˚uˇze být pouˇzit výraz, ˇci jiná vnoˇrená funkce. Tuto funkˇcnost zde

(34)

ale PS nepodporuje a vstupn´ım parametrem sm´ı být jedinˇe samotný ˇcistý parametr. Kom- binován´ı funkc´ı a vytváˇren´ı výraz˚u je jinak ale v poliValue Expressionumoˇznˇeno a funguje v poˇrádku. Jak je vidˇet na obrázku 4, lze toto omezen´ı obej´ıt vytvoˇren´ım pomocného parametru, jehoˇz hodnota je poté dosazena do uˇzivatelské funkce. Na stejném obrázku je vidˇet, ˇ

ze jsem tuto metodu pouˇzil u parametrurequestedStateID, který je prvn´ım vstupn´ım parametrem funkce PEStateMachine v ˇcervenˇe zvýraznˇené oblasti. Pˇri tomto postupu je nutné brát v úvahu, ˇze vnitˇrn´ı parametry logického bloku jsou vyhodnocovány postupnˇe podle hodnoty v pol´ıˇckuIndex. Na obrázku 4 je vidˇet, ˇze nejdˇr´ıve je vypoˇctena hodnota vnitˇrn´ıho parametrurequestedStateID s indexem 1, a aˇz poté je poˇc´ıtána hodnota parametrucurrent- State s indexem 2 a pˇri jej´ım výpoˇctu je pouˇzit výsledek nyn´ı uloˇzený v requestedStateID.

3.4 Uˇ zivatelsk´ a funkce - implementace stavov´ eho automatu

Kdyˇz jsem vyv´ıjel uˇzivatelskou funkci, aby plnila roli stavového automatu, prozkoumal jsem nˇekolik cest, jak se k tomuto c´ıli dostat, a ne kaˇzdá cesta byla vhodná. Abych mohl navrhnout úˇcinné algoritmy, ˇcasto jsem musel testovat, jak funguje prostˇred´ı PS, aby bylo moˇzné pochopit, proˇc nˇekteré postupy selhávaj´ı. Nejd˚uleˇzitˇejˇs´ımi body tohoto procesu se zabývá tato kapitola.

3.4.1 Obecn´e vlastnosti a ˇzivotn´ı cyklus uˇzivatelsk´e funkce

Uˇzivatelská funkce má pˇredepsanou strukturu, d´ıky n´ıˇz m˚uˇze být zaˇclenˇena do funkˇcnosti prostˇred´ı PS. Implementuje rozhran´ıTecnomatix.Engineering.ITxPlcLogicBehaviorFunction knihovnyTecnomatix.Engineering.dll. Toto rozhran´ı ale vynucuje pouze funkci Evaluate(), coˇz samo o sobˇe nedostaˇcuje. FunkceEvaluate()je volána kaˇzdý krok simulace ve chv´ıli, kdy dojde k vyhodnocován´ıExpression Value, kde je uˇzivatelská funkce pouˇzita. Je-li pouˇzita na v´ıce m´ıstech, pochopitelnˇe je Evaluate() volána v´ıcekrát v jednom kroku simulace.

T´ım se dostávám k otázce ˇzivotn´ıho cyklu tˇr´ıdy uˇzivatelské funkce. V pr˚ubˇehu vývoje pluginu se ukázalo, ˇze pˇri inicializaci pˇri startu programu Process Simulate je vytvoˇrena

(35)

3.4 Uˇzivatelsk´a funkce - implementace stavov´eho automatu

jediná instance od kaˇzdé tˇr´ıdy uˇzivatelské funkce, a to se stane jeˇstˇe pˇred naˇcten´ım jakékoli studie, tedy nezáleˇz´ı, jestli je nˇekde uˇzivatelská funkce pouˇzita. Pˇri startu je volán tedy konstruktor tˇr´ıdy (v kódu 2 je to JmenoTridyUzivatelskeFunkce(), ˇrádek 12). Dále je pˇri naˇcten´ı nˇejaké studie, v n´ıˇz je uˇzivatelská funkce pouˇzita, zavolána metodaParametersTy- pes(), a to právˇe jednou, nezávisle na poˇctu parametr˚u. Tatáˇz metoda ParametersTypes() je volána i v okamˇziku, kdy uˇzivatel otevˇre rozhran´ı pro prohl´ıˇzen´ı a editaci logických blok˚u (viz obrázek 4) a pˇrejde na záloˇzku, na n´ıˇz je vidˇet pouˇzit´ı této uˇzivatelské funkce.

Toto volán´ı probˇehne jen poprvé, pˇri opakovaném zobrazen´ı jiˇz volána nen´ı. Metoda Re- turnValueType() je volána na zaˇcátku kaˇzdého kroku simulace, a to pˇred volán´ım metody Evaluate().

Kaˇzdá uˇzivatelská funkce také mus´ı m´ıt pro svou tˇr´ıdu zavedený atribut (viz ˇrádek 5 výpisu kódu 2) se jménem této funkce, které se pak zobraz´ı v prostˇred´ı PS. Zobrazen´ı jména funkce je jen vedlejˇs´ı role atributu, pˇredevˇs´ım umoˇzˇnuje pomoc´ı reflexe v bˇeˇz´ıc´ım programu (v mém pˇr´ıpadˇe bˇeˇz´ıc´ım PS) pouˇz´ıvat atributem indexovanou tˇr´ıdu. T´ım jsou popsány vˇsechny formáln´ı náleˇzitosti uˇzivatelské funkce.

3.4.2 Pouˇzit´y stavov´y automat

Stavový automat popsaný na obrázku 3 nen´ı pro programován´ı simulace PROFIenergy vhodný. Na jednu stranu je pˇr´ıliˇs sloˇzitý a popisuje i moˇznosti, které výrobce naˇseho robo- tického kontroleru neimplementuje. Na druhou stranu je tento stavový automat o trochu jednoduˇsˇs´ı neˇz aby bylo moˇzné jej pˇr´ımo implementovat v pluginu. Nav´ıc ID stav˚u tak, jak jsou v profilu PE definována, nenechávaj´ı prostor pro zaveden´ı ID pˇrechodovým stav˚um a pro implementaci je potˇreba oznaˇcit kaˇzdý simulovaný stav unikátn´ım ID.

Náˇs kontroler podporuje jen jeden Energy-saving mód, mód Sleep mode WOL a mód Ready to operate, jak je uvedeno v tabulce 1. Vypustil jsem tedy ze stavového automatu vˇsechny dalˇs´ı hypotetickéEnergy-saving módy s t´ım, ˇze jsem strukturu programu udrˇzoval tak, aby bylo moˇzné s rozumnou nároˇcnost´ı pozdˇeji pˇridat dalˇs´ı simulovatelné Energy- saving módy.

(36)

Dále model na obrázku 3 nemodeluje pomoc´ı stavu fázi, kdy je zaˇr´ızen´ı v Energy- saving módu bezprostˇrednˇe po dosaˇzen´ı tohoto stavu a nem˚uˇze jeˇstˇe reagovat na pˇr´ıkazy k pˇrechodu do jiného stavu. Pro potˇreby vývoje pluginu jsem tento stav ve své uˇzivatelské funkci zavedl a nazývám ho jako Nezbytný Energy-saving respektive

Nezbytný Sleep mode WOL. Zjednoduˇsuje se tak sada podm´ınek kontrolovaných pˇri obdrˇzen´ı pˇr´ıkazu k pˇrechodu mezi stavy a eventuáln´ı pˇridán´ı dalˇs´ıch stav˚u se t´ım také stává pro- cedurálnˇejˇs´ı ˇcinnost´ı.

Vznikl tak model stavového automatu, který je moˇzné elegantnˇe implementovat bez naruˇsen´ı poˇzadavk˚u na omezen´ı ˇci integrovatelnost PE stavového automatu. Jeho diagram je na obrázku 5. Jak je z diagramu patrné, kaˇzdý stav má zavedené ID, které se neshoduje

Obrázek 5: Diagram upraveného stavového automatu pluginu

s ID definovaným v PE standardu. Jsou zde také vidˇet podm´ınky pˇrechod˚u. Tam, kde je jako podm´ınka uveden Cas, tam dojde k pˇrechodu pr´ˇ avˇe tehdy, kdyˇz uplyne definovaný ˇ

casový úsek. Tyto ˇcasové úseky se liˇs´ı zaˇr´ızen´ı od zaˇr´ızen´ı a je nutné umoˇznit uˇzivateli

(37)

jejich nastaven´ı na správnou hodnotu. Rozhodl jsem se, ˇze seznam tˇechto ˇcasových konstant bude pˇredáván uˇzivatelské funkci jako parametr v kaˇzdém kroku simulace. Tento postup byl vynucen ˇzivotn´ım cyklem uˇzivatelských funkc´ı. Jedna a tatáˇz instance je pouˇzita pro simulaci mnoha zaˇr´ızen´ı a kaˇzdé m˚uˇze m´ıt jiné ˇcasové konstanty pˇrechod˚u mezi stavy, takˇze nen´ı moˇzné uloˇzit ˇcasován´ı nastálo v této instanci. Nen´ı ani moˇzné s jistotou urˇcit poˇrad´ı, v jakém budou jednotlivá zaˇr´ızen´ı simulována, takˇze ani nˇejaký vnitˇrn´ı indexovaný seznam konstant nen´ı ˇreˇsen´ım.

Dostávám se tak k problému simulován´ı v´ıce zaˇr´ızen´ı v jednom bˇehu simulace. Je uˇz jasné, ˇze stavový automat m˚uˇze být simulován jen pokud dokáˇzeme uchovávat informaci o stavu pro kaˇzdé dotˇcené zaˇr´ızen´ı zvláˇst’. P˚uvodnˇe jsem intuitivnˇe pˇredpokládal, ˇze pro kaˇzdé pouˇzit´ı uˇzivatelské funkce je vytvoˇrena jej´ı samostatná instance. Jak jsem popsal dˇr´ıve, tento pˇredpoklad byl mylný. Musel jsem hledat cestu, jak toto omezen´ı obej´ıt. Po- kud by bylo moˇzné v jediné databázi udrˇzovat informaci o stavu kaˇzdého zaˇr´ızen´ı a tuto databázi spravovat v instanci uˇzivatelské funkce, bylo by to ˇreˇsen´ı. K tomu je potˇreba nˇejakým zp˚usobem indexovat jednotlivá zaˇr´ızen´ı. V prostˇred´ı Tecnomatix na eMServeru je pˇridˇeleno ke kaˇzdému objektu tzv. external ID - unikátn´ı ˇretˇezec znak˚u generovaný pˇri vytvoˇren´ı tzv. plánovac´ıho objektu v databázi. Nast´ın´ım, co je plánovac´ım objektem myˇsleno. Objekty v PS potaˇzmo v Tecnomatixu jsou bud’to plánovac´ı, nebo modelovac´ı, nebo oboj´ı. Plánovac´ı objekt je reprezentace napˇr´ıklad robotu, která ˇr´ıká jen to, ˇze robot je zde pouˇzit a má nˇejaké vlastnosti, ale nic neˇr´ıká o jeho 3D modelu ˇci kinematice. Tyto fyzické vlastnosti jsou zahrnuty v modelovac´ım objektu. Právˇe pouˇzitý pˇr´ıklad robotu je pˇr´ıklad objektu zároveˇn plánovac´ıho i modelovac´ıho. I modelovac´ı objekt má unikátn´ı po- pisovaˇc -object ID - také ˇretˇezec znak˚u. Zde vzniká m´ırné zmaten´ı. Prostˇred´ı PS je stavˇeno jako objektovˇe orientované modelovac´ı prostˇred´ı, existuj´ı tˇr´ıdy objekt˚u a z nich se vytváˇr´ı instance, pˇr´ıkladem je tˇreba tˇr´ıdarobot KUKA KRC5 a z nˇej je vytvoˇreno nˇekolik kus˚u robot˚u tohoto typu. Pro tˇr´ıdu objektu existuje také unikátn´ı ID, a to je v atributu eMSType.

Je jasné, ˇze toto posledn´ı ID je pro mé potˇreby nepouˇzitelné.

Zformuloval jsem pˇredstavu, ˇceho chci dosáhnout. V logickém bloku pˇriˇrazeném konkrét-

(38)

n´ımu zaˇr´ızen´ı v PS je zavolána uˇzivatelská funkce a této funkci je pˇredán unikátn´ı popisovaˇc zaˇr´ızen´ı, podle kterého instance uˇzivatelské funkce vyhledá ve své vnitˇrn´ı databázi stav, v nˇemˇz se dané zaˇr´ızen´ı nacház´ı. Bylo by logické pouˇz´ıt jedno nebo druhé z vhodných ID výˇse popsaných jako identifikátor. Zde vyvstávaj´ı dvˇe pˇrekáˇzky, které v takovém pouˇzit´ı brán´ı. Zaprvé v logickém bloku mohou být pouˇzity parametry, vstupy a výstupy jen a pouze ˇ

c´ıselných typ˚u. Logickou hodnotu boolean povaˇzuji za ˇc´ıslo 1 nebo 0 vzhledem k tomu, ˇze v logickém bloku je moˇzné násobit booleanovskou hodnotou ˇc´ıselnou hodnotu ve smyslu true= 1 af alse= 0. Toto chován´ı logické hodnoty je pˇrekvapivé, ale ˇcasto velmi uˇziteˇcné.

V pˇredchoz´ım odstavci jsem uvedl, ˇze ID objekt˚u jsou ˇretˇezce znak˚u, tedy nesluˇcitelný da- tový typ. Nen´ı ani moˇzné jednoduˇse pˇred vstupem ˇretˇezce do logického bloku pˇrevést ˇretˇezec nˇejakým prostým zobrazen´ım na ˇc´ıslo, protoˇze i vstup logického bloku uˇz mus´ı být ˇ

c´ıslo. Odtud pak vycház´ı druhá pˇrekáˇzka, a totiˇz ˇze nelze hodnotu ID dostat do signálu, aby tento signál pak mohl být pˇredán na vstupu logického bloku, kam lze pˇripojit jen signály. A opˇet zde vyvstává omezen´ı, ˇze signál sm´ı být jedinˇe ˇc´ıselná hodnota, prostˇred´ı PS nic jiného neumoˇzˇnuje. T´ım je vylouˇceno pouˇzit´ı jiˇz existuj´ıc´ıch ID objekt˚u kv˚uli ne- kompatibilitˇe datových typ˚u.

Je nutn´e tedy generovat vlastn´ı ID zaˇr´ızen´ı pro potˇreby hled´an´ı jejich stav˚u pˇri simulaci.

Toto ID mus´ı být unikátn´ı alespoˇn po dobu bˇehu simulace. Jak se pozdˇeji ukázalo, doˇcasná unikátnost ID je bohuˇzel to nejlepˇs´ı, ˇceho lze dosáhnout. Jsou dvˇe moˇznosti, jak zaˇr´ızen´ı ID pˇriˇrazovat. Prvn´ı moˇznost´ı je pouˇz´ıt signál v prostˇred´ı PS. V tom pˇr´ıpadˇe by pˇri simulaci musel být kaˇzdý signál pevnˇe nastavený na unikátn´ı ID zaˇr´ızen´ı, tato hodnota se pˇri kaˇzdém spuˇstˇen´ı simulace mus´ı zkontrolovat a vˇetˇsinou znovu nastavit. Toto ˇreˇsen´ı se jev´ı být tˇeˇzkopádné, kromˇe toho také pˇridˇelává uˇzivateli starosti s novými signály, které mus´ı spravovat. Druhou moˇznost´ı je uloˇzit ID v kaˇzdém logickém bloku v podobˇe konstanty.

Na obrázku 18 v pˇrehledu konstant v zeleném rámeˇcku je vidˇet konstanta s názvem bloc- kID, která pln´ı pˇresnˇe tuto úlohu. Jeˇstˇe je nutné zajistit unikátnost této konstanty. T´ım se zabývá PS command, který popisuji v následuj´ıc´ı kapitole.

Dále je na ˇradˇe vyˇreˇsit databázi stav˚u jednotlivých zaˇr´ızen´ı. Bude existovat jen jedna

(39)

databáze uloˇzená v instanci tˇr´ıdy uˇzivatelské funkce. Jako vhodný nástroj pro realizaci takové databáze se jev´ı slovn´ık (generická tˇr´ıda jazyka C# -Dictionary), který umoˇzˇnuje s kl´ıˇcem mapovat libovolné datové typy. Vytvoˇril jsem výˇctový typ enStates (energetic states) pro jednoznaˇcný popis PE stavu. Databázi stav˚u zaˇr´ızen´ı tak tvoˇr´ı slovn´ık dekla- race Dictionary<int, enStates> myActualStatesDict;. V kaˇzdém volán´ı funkce Eva- luate(), tedy v kaˇzdém kroku simulace, je ve slovn´ıku vyhledán stav podle kl´ıˇce, kterým je blockID. Pˇri prvn´ım hledán´ı jeˇstˇe nen´ı ve slovn´ıku ˇzádný záznam, a tak je pˇridán s pˇredanýmblockID. D´ıky tomu, ˇze byl pouˇzit slovn´ık, nemus´ı být ID ˇrazena vzestupnˇe, ale mohou být r˚uznˇe zpˇreházena. Dále je potˇreba zaznamenávat okamˇzik, kdy zaˇr´ızen´ı vstou- pilo do nˇekterých stav˚u, aby tak mohlo být simulováno ˇcasován´ı PE. K tomu jsem vyuˇzil dalˇs´ı slovn´ık, který k jednotlivým blockID pˇriˇrazuje ˇcasovou známku (timestamp) vstupu do stavu. Pouˇzit´ım ˇcasových známek se pˇredejde moˇzným komplikac´ım pˇri mˇeˇren´ı ˇcasu, kdyˇz je pˇred uplynut´ım ˇcasového intervalu simulace pozastavena. Omezil jsem se na roz- hodován´ı o ˇcasovˇe závislých událostech jen na základˇe ˇcasu simulace. Pozdˇeji jsem rozˇs´ıˇril uˇzivatelskou funkci jeˇstˇe o jeden slovn´ık, který udrˇzoval informaci o tom, zda robot pˇreˇsel v tomto kroku ze stavu Operating do stavu Ready to operate, aby bylo moˇzné realizovat virtuáln´ı zprovoznˇen´ı VKRC standardu, o tom podrobnˇeji pojednávám v kapitole 4.

Stejnˇe jako blockID vstupuje do uˇzivatelské funkce i sada vˇsech ˇcasových konstant náleˇzej´ıc´ıch konkrétn´ımu zaˇr´ızen´ı. Jejich hodnoty jsou uloˇzeny v konstantách logického bloku a jsou nastaveny pˇri sestavován´ı logického bloku. Pozdˇeji je ovˇsem moˇzno je upravit.

V tabulce 2 uvád´ım seznam názv˚u ˇcasových konstant v uˇzivatelské funkci, jejich ekviva- lenty v diagramu 5 a hodnoty pro náˇs kontroler. Podle názv˚u v této tabulce je pak uloˇzen extern´ı seznam konstant v csv souboru. Po vystavˇen´ı vstupn´ıch parametr˚u uˇzivatelské funkce jsem z´ıskal hlaviˇckuPEStateMachine ( requestedStateID blockID timeToPsaving ti- meMustPsaving timeToReadyFromPsaving timeToSleep timeMustSleep timeToReadyFrom- Sleep ), která je pomˇernˇe dost dlouhá, ale to je jen malá daˇn za pˇrehlednost, kterou za- pouzdˇren´ım vˇseho ostatn´ıho uˇzivateli tato funkce pˇrináˇs´ı. Hned prvn´ım parametrem je requestedStateID, o kterém jsem se jeˇstˇe nezm´ınil. Jak název dává tuˇsit, v tomto parame-

(40)

N´azev parametru Popis ˇci PE ekvivalent Hodnota [s]

timeToPsaving Pˇrechod doEnergy-saving 5

timeMustPsaving Nezbytn´y Energy-saving 0

timeToReadyFromPsaving Pˇrechod doReady to operate 20

timeToSleep Pˇrechod doSleep mode WOL 50

timeMustSleep Nezbytn´y Sleep mode WOL 10

timeToReadyFromSleep Pˇrechod doReady to operate 50

Tabulka 2: PE ˇcasován´ı a mapován´ı názv˚u parametr˚u uˇzivatelské funkce

tru se uˇzivatelské funkci pˇredává poˇzadovaný PE stav, do nˇehoˇz se má pˇrej´ıt. V tuto chv´ıli je na m´ıstˇe pˇredstavit rozhodovac´ı kritéria, podle kterých je stavový automat simulován.

Definoval jsem celkem 10 stav˚u a 1 chybový stav pro úˇcely ladˇen´ı, jejich výˇcet je v tabulce 3. Základn´ı úkony jsem zobrazil ve vývojovém diagramu 6. Pˇredposledn´ı blok je popsán jakoPodle aktuáln´ıho stavu a ˇcasu simulace uloˇz do databáze nový stav. Výkon této operace je nejnároˇcnˇejˇs´ı a nejd˚uleˇzitˇejˇs´ı, proto se budu nyn´ı zabývat jej´ım popisem.

Pˇredpokládejme, ˇze v pˇredchoz´ım kroku jsem z´ıskal z databáze informaci o tom, v kterém PE stavu se tento logický blok potaˇzmo zaˇr´ızen´ı nacházel v minulém simulaˇcn´ım kroku.

Podle toho se pak liˇs´ı reakce uˇzivatelsk´e funkce na poˇzadovan´y stav. Pop´ıˇsu ted’ tyto reakce.

V programu jsem pouˇzil n´azvy stav˚u, jak jsou uvedeny v tabulce 3 ve sloupciN´azev stavu.

Pro stavOperating:

• poˇzadovan´y stav 6=Operating ⇒ nastav aktu´aln´ı stav na Ready

Pro stavReady jsou 3 moˇzn´e v´ystupy:

• nastav ˇcasovou zn´amku na aktu´aln´ı ˇcas simulace

• poˇzadovan´y stav =PSaving ⇒ nastav aktu´aln´ı stav na toPSaving

(41)

Obrázek 6: Vývojový diagram simulace stavového automatu v uˇzivatelské funkci

• poˇzadovan´y stav = Sleep ⇒ nastav aktu´aln´ı stav natoSleep

• poˇzadovan´y stav = Operating ⇒nastav aktu´aln´ı stav naOperating Pro stav toPSaving:

• (ˇcas simulace - ˇcasová známka) ≥ timeToPsaving ⇒ – nastav aktuáln´ı stav namustPSaving

– nastav ˇcasovou zn´amku na aktu´aln´ı ˇcas simulace Pro stav mustPSaving:

• (ˇcas simulace - ˇcasová známka)≥ timeMustPsaving ⇒nastav aktuáln´ı stav naPSa- ving

Pro stav PSaving:

• poˇzadovan´y stav = Ready ⇒ nastav aktu´aln´ı stav na toReadyFromPSaving

(42)

N´azev stavu N´azev v PE diagramu ID v programu

Operating Operating 1

Ready Ready to operate 0

toPSaving Pˇrechod do Energy-saving 2

mustPSaving Nezbytn´y Energy-saving 3

PSaving Energy-saving 4

toReadyFromPSaving Pˇrechod do Ready to operate (z ID=4) 5

toSleep Pˇrechod do Sleep mode WOL 6

mustSleep Nezbytn´y Sleep mode WOL 7

Sleep Sleep mode WOL 8

toReadyFromSleep Pˇrechod do Ready to operate (z ID=8) 9

errorState 10

Tabulka 3: N´azvy stav˚u ve v´yˇctu enStates a jejich ekvivalent v diagramu 5

• poˇzadovan´y stav =Sleep ⇒ nastav aktu´aln´ı stav na toSleep

• nastav ˇcasovou zn´amku na aktu´aln´ı ˇcas simulace

Pro stavtoReadyFromPSaving:

• (ˇcas simulace - ˇcasová známka)≥timeToReadyFromPSaving ⇒nastav aktuáln´ı stav na Ready

Pro stavtoSleep:

• (ˇcas simulace - ˇcasová známka) ≥ timeToSleep ⇒ – nastav aktuáln´ı stav na mustSleep

– nastav ˇcasovou zn´amku na aktu´aln´ı ˇcas simulace

(43)

Pro stav mustSleep:

• (ˇcas simulace - ˇcasová známka) ≥ timeMustSleep ⇒ nastav aktuáln´ı stav na Sleep Pro stav Sleep:

• poˇzadovan´y stav = Ready ⇒ nastav aktu´aln´ı stav na toReadyFromSleep

• nastav ˇcasovou zn´amku na aktu´aln´ı ˇcas simulace Pro stav toReadyFromSleep:

• (ˇcas simulace - ˇcasová známka)≥timeToReadyFromPSaving ⇒nastav aktuáln´ı stav naReady

Pro pˇr´ıpadné pˇridáván´ı stav˚u do stavového automatu je vhodné dodrˇzovat pravidlo, ˇze pˇri pˇrechodu do stavu, v nˇemˇz se následnˇe bude kontrolovat ˇcasová známka, je nutno ˇcasovou známku nastavit na aktuáln´ı ˇcas. Tak je zajiˇstˇeno, ˇze ˇcasovˇe závislá operace bude aktivn´ı jen po definovanou dobu. Jak je vidˇet, vˇsechny kontroly ˇcasové známky pˇredpokládaj´ı, ˇze ˇcas simulace bude neklesaj´ıc´ı. V prostˇred´ı PS je moˇzné v Sequence Editoru spustit simulaci pozpátku v reˇzimu CEE (cyclic event evaluation), coˇz m˚uˇze být nejsp´ıˇs v nˇekterých situac´ıch prospˇeˇsné, nicménˇe ve vˇetˇsinˇe pˇr´ıpad˚u se tato funkce nevyuˇzije a implementace stavového automatu tak, aby fungoval i takto zpˇetnˇe, by se nevyrovnala vynaloˇzenému úsil´ı. Nav´ıc by kód pˇriˇsel do velké m´ıry o svoji pˇrehlednost. Pˇr´ıpady, kdy uˇzivatel pˇrejde v jiˇz jednou spuˇstˇené simulaci zpˇet, mus´ı uˇzivatel opravit manuálnˇe nastaven´ım stavového automatu do správného stavu, a pak opˇetovným spuˇstˇen´ım simulace. Pˇri takovém jednán´ı je ovlivnˇen i záznam stav˚u, pokud byl pˇri této události aktivován, a jeho výstup je tˇreba analyzovat. V záznamech bude v´ıce údaj˚u ve stejném ˇcasovém intervalu, a to je znalost, kterou lze pˇri korekci dat vyuˇz´ıt. Záznamem stav˚u se zabývám podrobnˇe v kapitole 3.5.2.

T´ım je uzavˇren blok Stavový automat v obrázku 2. Vzhledem k tomu, ˇze funkˇcnost stavového automatu pˇricház´ı do prostˇred´ı PS aˇz s uˇzivatelskou funkc´ı, nen´ı moˇzné dodrˇzet

(44)

postup vývoje pluginu, jak byl popsán v úvodu kapitoly. Konkrétnˇe se jedná o krok, kdy je nejprve prototyp funkˇcn´ı datové struktury manuálnˇe sestaven v prostˇred´ı PS, aby tak byla dokázána integrovatelnost a kompatibilita s PS. Sestavován´ı funkˇcn´ıho prototypu tedy pˇriˇslo na ˇradu aˇz po naprogramován´ı uˇzivatelské funkce. Po vyladˇen´ı uˇzivatelské funkce jsem pak mohl uˇz pˇristoupit k automatizaci sestaven´ı funkˇcn´ı struktury - logického bloku, v nˇemˇz je uˇzivatelská funkce pouˇzita. Na tomto m´ıstˇe je vhodné upozornit, ˇze tuto funkci lze k simulován´ı PE standardu pouˇz´ıt samostatnˇe bez dalˇs´ıch nástaveb, pokud uˇzivatel v´ı, jak tato funkce funguje. K praktickému hromadnému pouˇzit´ı je ale zapotˇreb´ı spravuj´ıc´ı nadstavbová aplikace, kterou popisuji v kapitole 3.5.

3.5 Process Simulate Command

Pˇredstava, ˇze by uˇzivatel mˇel provést manuálnˇe des´ıtky malých krok˚u pro kaˇzdé zaˇr´ızen´ı, kterému chce pˇriˇradit chován´ı podle PROFIenergy standardu, je pˇrinejmenˇs´ım odrazuj´ıc´ı.

Pro pohodlné pouˇzit´ı pluginu je také nutné uˇzivateli dodat uˇzivatelské rozhran´ı konzistentn´ı s tˇemi, na které je v rámci nadˇrazené aplikace zvyklý. Na programu Process Simulate je znát, ˇze je sloˇzen z velkého mnoˇzstv´ı d´ılˇc´ıch aplikac´ı, které p˚uvodnˇe stály samostatnˇe, a konzistence uˇzivatelských rozhran´ı nen´ı ani v nˇem plnˇe dodrˇzena. Má vˇsak spoleˇcné prvky a zdá se být logické, ˇze jeho vývojáˇri maj´ı tendenci smˇeˇrovat k urˇcitému sjednocen´ı vzhledu a ovládán´ı. Jedn´ım z bod˚u zadán´ı práce také bylo naprogramovat SW modul pro pˇrenáˇsen´ı extern´ıch dat z a do prostˇred´ı Process Simulate. V pr˚ubˇehu ˇreˇsen´ı práce vznikl konkrétnˇejˇs´ı poˇzadavek na umoˇznˇen´ı exportovat ˇcasový záznam otoˇcen´ı kloub˚u vybraných robot˚u ze simulace do souboru.

Vˇsechny tyto poˇzadavky lze splnit v r´amci moˇznost´ı Tecnomatix.NET API pomoc´ı tzv.

command. Je to funkce typická pro tlaˇc´ıtko - uˇzivatel klikne na tlaˇc´ıtko, a to vyvolá sled nˇejakých akc´ı. Kdyˇz je akce jednou dokonˇcena, nen´ı command aktivn´ı, dokud uˇzivatel opˇet neklikne na tlaˇc´ıtko. Command také umoˇzˇnuje vytváˇret komplexnˇejˇs´ı uˇzivatelské rozhran´ı neˇz jen jedno tlaˇc´ıtko, umoˇzˇnuje pouˇz´ıt vˇetˇsinu GUI (graphical user interface) prvk˚u, které v prostˇred´ı PS najdeme.

(45)

3.5 Process Simulate Command

3.5.1 Pˇriˇrazen´ı logick´eho bloku

Pro simulován´ı PE standardu je nutné pouˇz´ıt logický blok, který umoˇzn´ı pouˇz´ıt uˇziva- telskou funkci na sv˚uj vnitˇrn´ı parametr ˇci na sv˚uj výstup. V PS lze logický blok vytvoˇrit zcela samostatnˇe bez návaznosti na kterýkoli objekt ve studii. Z objektového hlediska nelze m´ıt samostatnˇe stoj´ıc´ı paraleln´ı strom objekt˚u s nezávislým koˇrenem, vˇsechny objekty mus´ı m´ıt spoleˇcného pˇredka, ˇci majitele. Logický blok je povaˇzován za modelovac´ı objekt a pˇri jeho samostatném vytvoˇren´ı se zaˇrad´ı jako potomek ˇci majetek statické vlastnosti Logica- lRoot náleˇzej´ıc´ı statické tˇr´ıdˇe TxDocument. Takto samozˇrejmˇe lze také v logickém bloku simulovat PE standard, a t´ım simulovat nˇejaký virtuáln´ı objekt, který nen´ı ve studii vidˇet.

Praktiˇctˇejˇs´ı je vˇsak pouˇz´ıt moˇznost pˇriˇradit logický blok objektu, který tuto moˇznost podporuje. Obecnˇe kaˇzdý objekt implementuj´ıc´ı rozhran´ı ITxPlcLogicResource m˚uˇze dostat logický blok pˇriˇrazen. Prakticky toto rozhran´ı poˇzaduje pouze dvˇe vˇeci - zaprvé implementaci vlastnostiLogicBehavior, v n´ıˇz se ukládá reference na objekt logického bloku, a zadruhé implementaci veˇrejné metody CopySelfLogicToOtherLogicResource. Logický blok je v API zastoupen tˇr´ıdouTxPlcLogicBehavior. Pro potˇreby programován´ı pluginu nás vˇsak nebude pˇr´ıliˇs zaj´ımat, které objekty mohou logický blok pojmout, ani nebudeme mnoˇzinu takových objekt˚u rozˇsiˇrovat. V zadán´ı práce je urˇceno, ˇze standard PROFIenergy má být aplikován na model robota v PS, takˇze stˇredem naˇseho zájmu je tˇr´ıda TxRobot, která rozhran´ıITx- PlcLogicResource implementuje, ˇc´ımˇz je základn´ı poˇzadavek splnˇen a dále se o nˇej nen´ı tˇreba starat.

Pro logický blok plat´ı jeˇstˇe dalˇs´ı zvláˇstnost, a totiˇz dokud nen´ı jeho vstup ˇci výstup pˇripojen na signál, nen´ı blok se zárukou simulována a je v jakési latentn´ı fázi. Kdyˇz uˇzivatel chce simulovat PE standard, stejnˇe mus´ı k bloku pˇripojit ˇr´ıdic´ı signály, ˇc´ımˇz simulaci bloku aktivuje. Prototyp logického bloku je zobrazen v diagramu na obrázku 7. Zde zobrazené parametry, vstupy a výstupy jsou jen poˇzadované minimum, uˇzivatel m˚uˇze logický blok rozˇs´ıˇrit o libovolnou dalˇs´ı funkˇcnost (vstupy, parametry atd.), dokud se zmˇeny nedotknou zde uvedených prvk˚u, nebude dotˇcena ani PE funkˇcnost. Máme tedy prototyp, command mus´ı jen tento prototyp sestavit, správnˇe propojit vnitˇrn´ı promˇenné a nastavit konstanty

(46)

Obr´azek 7: Prototyp logick´eho bloku

na poˇzadované hodnoty. Tady uvedu zjednoduˇsený UML diagram tˇr´ıd pluginu 8. Neuvád´ım výˇcet metod tˇr´ıd, pouze výˇcet vnitˇrn´ıch promˇenných tˇr´ıd.

Obr´azek 8: UML diagram commandu

Pˇriˇrazen´ı logického bloku objektu robotu prob´ıhá následovnˇe. Nejprve je zkontrolováno, zda robot uˇz má pˇriˇrazený logický blok. Pokud ano, pracuje s t´ımto logickým blokem, pokud ne, je vytvoˇren nový logický blok (instance tˇr´ıdyTxPlcLogicBehavior). Vytvoˇren´ı instance tˇr´ıdyTxPlcLogicBehavior nelze provést prostým volán´ı kontruktoru tˇr´ıdy. Instanci lze vy- tvoˇrit jen pomoc´ı továrn´ı metodyCreateLogicBehavior( TxPlcLogicBehaviorCreationData data ) zavolané na instanci objektu implementuj´ıc´ıho rozhran´ıITxPlcLogicBehaviorCre-

(47)

3.5 Process Simulate Command

ation. Vstupn´ım parametrem je instance tˇr´ıdy TxPlcLogicBehaviorCreationData, kterou uˇz lze vytvoˇrit obvyklým volán´ım konstruktoru tˇr´ıdy. V této instanci je nutné pˇred jej´ım pouˇzit´ım nastavit vˇsechny parametry, které chceme nastavit instanciTxPlcLogicBehavior, pozdˇejˇs´ı zmˇeny parametr˚u jiˇz existuj´ıc´ı instance tˇr´ıdy TxPlcLogicBehavior vedou k nesta- bilitˇe prostˇred´ı PS. Tento postup vytváˇren´ı objekt˚u, kdy se nejprve vytvoˇr´ı datový objekt, který vnáˇs´ı do továrn´ı metody inicializaˇcn´ı informace, je v Tecnomatix.NET API zave- deným standardem a principiálnˇe je vˇzdy stejný. Pouˇzit´ı továrn´ıch metod zde má zajistit, ˇze uˇzivatel nebude vytváˇret sirotˇc´ı objekty - tedy objekty, které by nemˇely svého majitele.

Poté se otevˇre .csv soubor, v nˇemˇz jsou uloˇzeny ˇcasy pˇrechod˚u mezi PE stavy a naˇctou se hodnoty ˇcasových konstant s pevnˇe danými jmény, jak jsou uvedena v tabulce 2 v prvn´ım sloupci Název parametru. Soubor je ve formátu .csv, hodnoty jsou oddˇelené ˇcárkou a pro neceloˇc´ıselné hodnoty je pouˇzita desetinná teˇcka. V prvn´ım sloupci je pevnˇe daný název ˇcasové konstanty, v druhém sloupci pak jej´ı hodnota. Dalˇs´ı sloupce na ˇrádku jsou igno- rovány. Poˇrad´ı ˇrádk˚u m˚uˇze být libovolné a v pˇr´ıpadˇe, ˇze se na ˇrádku vyskytuje neznámý název ˇcasové konstanty, je tento záznam ignorován. Vˇsechny nenalezené ˇcasové konstanty jsou v logickém bloku nastaveny na hodnotu 0. Pˇr´ıklad obsahu souboru je vidˇet ve výpisu 1.

V logickém bloku se pak hledaj´ı podle jména výskyty konstant (instance tˇr´ıdy TxPlcLo-

timeToPsaving, 5.3 timeMustPsaving, 0 timeMustSleep, 10.0 timeToReadyFromSleep, 50

V´ypis 1: Pˇr´ıklad obsahu .csv souboru s PE ˇcasov´an´ım

gicBehaviorConstant), procház´ı se pole konstant, jehoˇz adresa je uloˇzena ve vlastnosti logického bloku Constants. Pokud je nalezen prvn´ı výskyt daného jména konstanty, které odpov´ıdá názvu konstanty z .csv souboru s ˇcasován´ım, pˇriˇrad´ı se jej´ı vlastnosti Value pˇr´ısluˇsná hodnota ze souboru. Pokud konstanta nen´ı v logickém bloku nastavena, je vy- tvoˇrena jej´ı nová instance s názvem, který nebyl nalezen. Opˇet mus´ı být pouˇzita továrn´ı funkce instance tˇr´ıdy TxPlcLogicBehavior s názvem CreateConstant za pouˇz´ıt´ıCreation-