MAST – multiagentní simulační systém

MAST – multiagentní simulační systém

Příspěvek posuzuje úlohu simulace při návrhu a implementaci multiagentních řídicích systémů. Je uvedena případová studie agentního simulačního nástroje MAST, vytvořeného ve Výzkumném středisku Rockwell Automation, Praha, a jeho použití pro simulaci a řízení modelu výrobní linky v laboratoři CDAC na univerzitě v Cambridge.

1. Úvod

Technika multiagentních systémů sehrává stále významnější roli při realizaci konceptu do značné míry distribuovaného, robustního a flexibilního řízení výrobních procesů. Ukazuje se, že „klasické“, centralizované přístupy k řešení určitých typů úloh selhávají, a to zejména tam, kde jsou kladeny zvýšené požadavky na:

• flexibilitu výrobního zařízení, kdy se vyžaduje schopnost řídicího systému okamžitě reagovat na změny konfigurace a velikosti výrobních sérií produktu, na změny ve výrobních postupech apod.,

• robustnost, jako schopnost detekovat a eliminovat poruchu výrobní jednotky bez nutnosti zastavení celého procesu výroby.

V takových případech se stále častěji zvažují řešení založená na aplikaci teorie multiagentních systémů. V nich jsou rozhodovací a řídicí procesy distribuovány v komunitě autonomních, vzájemně kooperujících jednotek (subsystémů), v ideálním případě bez jakéhokoliv centrálního rozhodovacího prvku. Tyto jednotky – agenty – dokážou řešit svoje úlohy, popř. reagovat na lokální poruchy, samostatně, s využitím znalosti svých vlastních schopností. Znalost schopností ostatních (okolních) agentů, včetně jejich představ o případném sociálním chování celé komunity, je jednotlivými agenty používána pro vzájemnou spolupráci a koordinaci. Je tomu tak např. v případě, kdy agent není schopen lokálně zvládnout vzniklou situaci (nejčastěji poruchu), kdy se rekonfigurují výrobní zařízení, modifikují plány výroby apod.

Agenty mezi sebou komunikují prostřednictvím krátkých zpráv, nejčastěji v textové podobě. Ty musí po syntaktické a především po sémantické neboli obsahové stránce odpovídat jednotným pravidlům. V prvním případě hraje jednotící roli organizace FIPA (Foundation for Intelligent Physical Agents), poskytující standardy pro komunikaci mezi agenty, správu agentů v rámci agentní komunity a mechanismus zasílání zpráv [7]. Pro porozumění významu obsahu zprávy musí agenty sdílet společnou ontologii, nabízející jim sémantický popis klíčových slov používaných ve zprávách a jejich případné vazby, a to pro danou aplikační oblast.

2. Použití agentů pro řízení v reálném čase

Teorii multiagentních systémů lze dnes použít na všech úrovních řízení a organizace podniku, tj. od řízení v reálném čase, přes plánování a rozvrhování výroby až po správu dodavatelsko-odběratelského řetězce. V případě použití agentů pro řízení v reálném čase je jejich charakteristikou přímá vazba na fyzické zařízení výrobního systému. Takový agent, častěji označovaný jako holon či holonický agent [4], je obvykle implementován jako modul zapouzdřující v sobě subsystém řízení v reálném čase (subsystém reálného času), zapsaný v jazyce kontaktních schémat (Ladder Diagram – LD) a běžící v programovatelném automatu (Programmable Logic Controller – PLC), spolu se softwarovým agentem „pracujícím pomaleji než v reálném čase„, který je implementován v některém z vyšších programovacích jazyků (C++ nebo Java) a je provozován na PC. Důležitým aspektem je implementace komunikačního rozhraní mezi těmito dvěma subsystémy, zajišťující přenos informací ze subsystému reálného času (např. údaje z čidel, identifikace poruchových stavů apod.) do softwarového agentu, který řeší vzniklou situaci např. spoluprací s jinými agenty. Zmíněné rozhraní je používáno i opačným směrem, tj. od softwarového agentu do subsystému reálného času, tak aby agent mohl přímo ovlivňovat akční členy fyzického výrobního zařízení. V současnosti je značné úsilí věnováno rozšíření již existující architektury PLC o podporu běhu programů sestavených v jazycích C++ a Java tak, aby i softwarový agent implementovaný v některém z těchto jazyků mohl být provozován přímo uvnitř PLC paralelně se subsystémem reálného času.

V procesu návrhu a implementace agentního systému představuje simulace, na rozdíl od použití v klasických, centralizovaných řídicích systémech, mnohem komplexnější proces, zahrnující širší spektrum úloh než jen vlastní simulaci v klasickém pojetí. Jedním z hlavních rozdílů je, že chování agentního systému jako celku nemusí být deterministické, ale je spíše emergentní: rozhodovací procesy a znalosti, „po částech„ vlastněné jednotlivými agenty, utvářejí globální chování systému, jež je obtížně predikovatelné. Souvisí to např. se způsobem spolupráce mezi agenty, kdy určitý agent žádaný o poskytnutí určité služby jiným agentem může spolupráci odmítnout např. pro vlastní vytížení (služba již byla poskytnuta jinému agentu) nebo na základě jemu známé lokální skutečnosti (např. výskyt poruchy), která je volajícímu agentu neznámá. Z toho plyne, že experimentální testování chování systému přímo na fyzickém výrobním zařízení by bylo nejenom extrémně nákladné, ale v mnoha případech i v praxi nerealizovatelné.

K simulaci, která představuje pro tyto případy nejvhodnější řešení, je třeba mít k dispozici:

• přesný model řízeného procesu, popř. výrobního závodu, a vhodný simulační nástroj pro jeho provozování v čase; tím se agentní vrstvě řízení vlastně poskytne softwarová emulace fyzického výrobního zařízení (snímačů a akčních členů, s nimiž agenty interagují); použití standardních nástrojů pro diskrétní simulaci, jako jsou Arena, Matlab, Grasp nebo Silk, je pro tyto účely limitované, zejména z důvodu obtížně realizovatelného provázání s agentní vrstvou,

• vhodné prostředí pro běh vlastních agentů, tzv. agentní platformu, nabízející prostředky pro vytváření agentů, registrování a vyhledávání služeb, jež agenty v komunitě nabízejí, a především mechanismus zasílání zpráv mezi agenty; na základě porovnání dostupných agentních platforem v [8] je jako nejvhodnější možné doporučit volně dostupné (open source) platformy JADE [3] a FIPA-OS [1], popř. komerční nástroj JACK,

• integrační strategii, usnadňující pozdější přechod od simulace k řízení reálného systému, neboť agentní vrstvu řízení, navrženou pro účely simulace, lze s výhodou použít i pro řízení fyzického výrobního procesu, kdy je vazba na emulovanou fyzickou vrstvu nahrazena připojením k reálnému řízenému procesu; je tedy třeba zvolit takové rozhraní mezi agenty a emulovaným fyzickým procesem, které takový přechod umožní bez nutnosti dodatečných modifikací agentů (na pracovišti autora je v současnosti implementováno řešení založené na použití řídicího automatu ControlLogix, jehož paměť, konkrétně datová tabulka s hodnotami proměnných, je použita jako médium pro sdílení informací mezi oběma vrstvami, když rozhraní pro zápis a čtení hodnot proměnných v datové tabulce je dostupné jazykům C++ a Java),

• uživatelské rozhraní pro všechny fáze analýzy a návrhu agentního řídicího systému a simulace (simulační systém by měl být především vybaven vhodným vizualizačním modulem pro grafickou prezentaci chování agentního systému a interakci s uživatelem, který např. modeluje poruchy výrobních zařízení, mění jejich parametry, vkládá objednávky na výrobu apod.).

Požadavky na simulační nástroje a platformy pro agentně orientovaná řešení si žádají nové typy komplexních vývojových a simulačních prostředí. Jedním z prvních nástrojů tohoto druhu je systém MAST (Manufacturing Agent Simulation Tool), vyvíjený ve Výzkumném středisku Rockwell Automation v Praze.

3. Agentní simulační nástroj MAST

3.1 Charakteristka nástroje MAST
Vývoj agentního modelovacího a simulačního nástroje MAST byl zahájen přibližně před třemi roky v rámci projektu zaměřeného na výzkum tzv. holonických systémů, tj. aplikaci multiagentních technik v oblasti průmyslového řízení. Původní ideou bylo vytvořit agentní řešení problému přepravy kusového materiálu ve výrobním závodu prostřednictvím dopravních pásů, popř. automatických samonaváděných vozíků. Důraz byl kladen především na identifikaci agentů pro základní typy výrobních a dopravních komponent, jako je výrobní jednotka, dopravní pás, výhybka, vozík apod., a na specifikaci komunikačních protokolů a scénářů používaných pro spolupráci mezi agenty.

Pro programovou implementaci byl zvolen jazyk Java, a to především pro přenositelnost programů v něm vytvořených mezi různými hardwarovými platformami a operačními systémy a též díky existenci velkého množství volně použitelných multiagentních vývojových platforem (viz výčet v předchozí kapitole) založených na jazyce Java a kompatibilních se standardy FIPA. Původně byla vybrána platforma FIPA-OS. Pro problémy s výpočetní a paměťovou náročností byl systém posléze přenesen na platformu JADE. Výhodou použití objektově orientovaného jazyka – v tomto případě jazyka Java – je, že popis agentů pro jeden konkrétní typ výrobní komponenty je reprezentován jedinou třídou obsahující obecný popis atributů agentu daného typu a množinu pravidel, podle nichž se agent chová (tj. např. způsob reakce na poruchu). Takováto třída je použita pro vytvoření libovolného počtu vlastních instancí agentů (kdy jsou obecně specifikované atributy naplněny konkrétními hodnotami, tj. např. jmény spolupracujících agentů), aniž by bylo nutné programovat chování každého agentu individuálně.

Pro testování funkceschopnosti navrženého agentního systému bez vazby na reálné výrobní zařízení bylo dále nutné navrhnout simulaci, resp. emulaci výrobního prostředí. Zjednodušeně řečeno, simulovanými pohyby virtuálních výrobků (kusů materiálu) jsou iniciovány virtuální snímače, které posílají signály příslušným agentům, a naopak, řídicí zásahy vykonávané agenty se propagují zpět do simulace prostřednictvím virtuálních akčních členů.

Cílem činnosti agentů je zajišťovat dopravu výrobků mezi uživatelem specifikovanými výrobními jednotkami (např. stroji), které jsou propojeny sítí dopravních pásů (se specifikovanou cenou za dopravu) a výhybek. Ty přehazují výrobky mezi pásy tak, aby bylo dosaženo cíle dopravy za co nejnižší cenu, jak je názorně naznačeno na obr. 1. Agenty, reprezentující jednotlivé komponenty jako výrobní jednotky, pásy, výhybky apod., spolu vzájemně spolupracují prostřednictvím zasílání zpráv. Účelem je určit optimální trasy dopravním systémem (viz kap. 3.3), a to bez pomoci jakéhokoliv centrálního rozhodovacího prvku. Hlavní důraz je kladen na schopnost reagovat na poruchu v systému – uživatel může simulovat poruchu libovolné komponenty (např. dopravního pásu) a sledovat reakci agentů v jejich snaze nalézt alternativní dopravní cesty.

Podívejme se v dalším textu podrobněji na agent výrobní jednotky a agent křižovatky dopravních pásů.

3.2 Agent výrobní jednotky
Agent výrobní jednotky představuje obecnou výrobní jednotku (nejčastěji se bude jednat o určitý stroj nebo zásobník), která z pohledu dopravního systému umožňuje přijímat, zpracovávat či skladovat a opětovně odesílat výrobky. Předpokládá se, že k výrobní jednotce je připojen jeden nebo několik vstupních dopravních pásů pro dodávku výrobků a jeden výstupní pás pro jejich odesílání.

Hlavní vlastností agentu výrobní jednotky je schopnost na požádání odeslat určitý výrobek, přičemž úkolem je dopravit jej do požadované cílové výrobní jednotky. Tato událost je iniciována zprávou zaslanou jiným agentem, popř. uživatelem, který přepravu požaduje. Například zpráva, jejímž prostřednictvím jednotka W3 z obr. 1 žádá jednotku W2 (chápanou v tomto případě jako sklad výrobků či kusového materiálu) o zaslání výrobku s identifikačním číslem v#1245, vypadá v zápisu podle standardu FIPA takto:

Atribut request v záhlaví zprávy určuje tzv. performativ, tj. typ zprávy (zde jde o žádost o provedení nějaké akce), sender a receiver značí odesílatele a příjemce zprávy a content je vlastní obsah zprávy. V něm odesílatel žádá o zaslání výrobku specifikovaného atributem popisVyrobku. Ten obsahuje jednak identifikační číslo výrobku a také požadovaný cíl, kam se má výrobek zaslat (obecně se může lišit od odesílatele zprávy). Zápis v jazyce XML může vypadat např. takto:

Důležitý je atribut cilovaVyrobniJednotka, který je během celé dopravy systémem využíván pro určení cíle transportu výrobku, zejména při průchodech výhybkami, jež rozhodují, na který ze svých výstupních pásů výrobek nasměrovat, aby dosáhl požadovaného cíle po optimální trase.

V okamžiku, kdy agent W2 přijme zprávu, zkontroluje, zda výrobek s identifikačním číslem v#1245 je skutečně k dispozici. Jestliže se tento výrobek v jednotce W2 nenachází, agent posílá zamítavou odpověď (performativ refuse). V opačném případě předá výrobek svému výstupnímu pásu a agent W3 informuje o souhlasu s vykonáním požadované akce (performativ agree).

3.3 Agent křižovatky dopravních pásů a hledání optimální trasy
Tento agent hraje významnou roli při určování optimální trasy přepravy prostřednictvím dopravních pásů. Při volbě cenově orientovaného modelu dopravy, ve kterém je pro každý dopravní pás zvolena cena za použití (v systému MAST je cena rovna době v sekundách, kterou výrobek potřebuje k přejetí ze začátku na konec pásu), přičemž je pro dopravu zvolena taková posloupnost pásů, aby součet jejich cen od zdroje k cíli byl co nejmenší. Znamená to tedy, že v okamžiku, kdy výrobek vstupuje do výhybky, musí agent výhybky rozhodnout, na který ze svých výstupních pásů výrobek nasměruje tak, aby i po zbytek trasy (tj. od výhybky k cíli – viz zmíněný atribut cilovaVyrobniJednotka) putoval výrobek po cestě s nejmenší cenou.

Pro tyto účely agent výhybky spravuje pro každý ze svých výstupních pásů tabulku názvů dosažitelných cílů s cenami dopravy do těchto cílů. Uvedené informace jsou v systému předávány prostřednictvím zpráv zasílaných mezi sousedícími agenty, a to proti směru chodu dopravních pásů, tedy od cílových výrobních jednotek (jež tuto komunikaci iniciují při svém vzniku) směrem ke zdrojovým výrobním jednotkám. V okamžiku, kdy agent výhybky takovou zprávu od svého výstupního pásu přijme, zapamatuje si dostupné cíle pro tento pás obsažené ve zprávě. Současně tuto informaci zkombinuje se známými cíli dostupnými po svých ostatních výstupních pásech a výsledek pošle všem svým vstupním pásům. Ty ke každému cíli připočtou vlastní cenu a předají informaci opět dále proti směru svého chodu. Zmíněným způsobem jsou o dostupnosti cílů informovány všechny výhybky v systému až po zdrojové výrobní jednotky.

Hlavní výhodou tohoto řešení (analogie back-propagation) je schopnost systému reagovat na poruchy jednotlivých komponent. V případě, že agent zaregistruje poruchu svého zařízení (např. zastavení pásu z nějakého důvodu), zašle o ní zprávu sousedním agentům. Ty na ni reagují tak, jako by se jednalo o nový seznam dosažitelných cílů, ovšem nyní prázdný (tzn. žádné dostupné cíle). Tato informace je pak šířena „dále„ již popsaným způsobem, takže o tom, že cesty do určitých cílů již neexistují nebo se změnila jejich cena, jsou následně informovány i ostatní komponenty v systému.

4. Simulace výrobní linky na univerzitě v Cambridge s použitím nástroje MAST

4.1 Experimentální výrobní linka v CADC
Ačkoliv na akademické i podnikové úrovni již existuje mnoho výzkumných aktivit zaměřených na využití agentů pro řízení v průmyslu, skutečných aplikací agentů v reálných provozech je stále velmi málo. Převažujícími důvody jsou větší náklady na implementaci agentního řídicího systému a přetrvávající obavy z přechodu od centralizovaného řízení k řízení plně distribuovanému, které, při neexistenci centrálního rozhodovacího prvku, může vést k výskytu neočekávaného (nikoliv však chybného) chování systému jako celku.

Jedním z mála výzkumných středisek, kde je možné myšlenky agentního řízení aplikovat a experimentálně ověřovat na fyzickém modelu výrobní linky, je Centrum pro distribuovanou automatizaci a řízení (Center for Distributed Automation and Control – CDAC) na univerzitě v Cambridge [2]. Na experimentální výrobní lince jsou baleny produkty značky Gillette (holicí strojek, gel, pěna na holení a deodorant) do dárkových balíčků (dále box) na základě objednávek zadávaných uživatelem (uživatel volí libovolnou kombinaci tří ze čtyř uvedených produktů). Balicí linka (obr. 2) má tři smyčky (hlavní zásobovací smyčku a dvě smyčky pracovní) jednokolejového dopravního systému Montech pro dopravu samohybných kontejnerů s boxy. Navigaci kontejnerů mezi smyčkami zajišťují dvě nezávisle pracující výhybky. Produkty do boxů balí robot Fanuc M6i, který přemísťuje produkty ze skladových jednotek (obsahující čtyři vertikální zásobníky, každý pro jeden typ výrobku) do boxu, jenž byl kontejnerem dopraven do doku v jedné z pracovních smyček.

Pro řízení veškerých činností balicí linky byl navržen multiagentní systém zahrnující tzv. agenty zdrojů (resource agents), tj. např. agent robotu, výhybky, skladové jednotky apod., agenty objednávek (order agents), zpracovávající uživatelem vkládané objednávky, a agenty výrobků (product agents), reprezentující jednotlivé boxy. Pro lokalizaci boxů v systému se používá metoda automatické identifikace (Auto-ID, viz http://www.epcglobalinc.org), nahrazující čárové kódy radiofrekvenčními identifikačními čipy (Radio Frequency Identification – RFID), nesoucími, obvykle ve formě 96bitového slova, tzv. elektronický kód produktu (Electronic Product Code – EPC). Kód jednoznačně identifikuje nejenom typ, ale i konkrétní kus výrobku (tzn. dva výrobky téhož typu mají, na rozdíl od čárového kódu, jiný EPC). Čtení zajišťují tzv. čtečky RFID (na obr. 2 čtvercové skříňky napravo od robotů), využívající vysokofrekvenční rádiové vlny. Současný agentní řídicí systém, běžící na standardním PC, byl implementován v jazyce Java s použitím komerčního agentního vývojového prostředí JACK. Vazbu mezi agenty a fyzickými snímači a akčními členy zajišťuje mechanismus tzv. tabule (blackboard – [6]). To je program, běžící též na PC, který obsahuje synchronizovanou kopii datových registrů PLC (Omron) s daty ze snímačů a akčních členů, z nichž mohou jednotlivé agenty číst, popř. do nich zapisovat.

V současné době je technické vybavení laboratoře CDAC výrazně rozšiřováno. Zejména je přidávána další dvojice robotu se skladovou jednotkou a dále je přidáván nový policový skladový systém (na obr. 2 zcela vpravo) pro dlouhodobé skladování výchozích produktů Gillette i zkompletovaných boxů. Policový skladový systém je obsluhován pojízdným jeřábovým robotem pohybujícím se po visuté kolejnici.

S rozšířením hardwaru laboratoře vyvstal požadavek na nový agentní řídicí systém. Bylo shledáno, že nástroj MAST a jeho agentní řešení pro skladování a přepravu materiálu mohou být, po snadném rozšíření, použity zpočátku pro simulaci a po vyřešení určitých technických obtíží (viz kap. 4.6) i pro fyzické řízení veškerých činností balicí linky. V rámci tohoto rozšíření byly implementovány nové agenty, zejména v dalším textu zmíněný agent čtečky RFID, modifikovaný agent výhybky, agent robotu a skladové jednotky a agenty reprezentující objednávky a vlastní výrobky.

4.2 Agent čtečky RFID
Při implementaci agentu čtečky RFID bylo hlavní úsilí věnováno návrhu mechanismu pro poskytování čtených EPC, jimiž je agent zásobován z fyzického čtecího zařízení, jiným agentům. Řešení je založeno na obecném mechanismu subscribe – inform (tj. objednej si – budeš informován), který umožňuje jednomu agentu (řekněme A) objednat si u jiného agentu (B) zasílání informací pokaždé, když u B nastane určitá událost. Agent čtečky RFID informuje ostatní agenty o dvou událostech:

• produkt s čipem RFID vstoupil do pole čtecího zařízení (jak se na samohybném kontejneru pohybuje kolem čtečky),

• produkt opustil čtecí pole.

V obou případech zasílá agent čtečky zprávu obsahující EPC všem agentům, které si přejí být o některé z těchto událostí informovány.

4.3 Agent výhybky
Informace ze čteček RFID jsou využívány především dvěma agenty ovládajícími výhybky navigující kontejnery s boxy mezi hlavní zásobovací dopravní smyčkou a dvěma pracovními smyčkami s roboty. S výhodou byl použit dosavadní agent výhybky systému MAST (kap. 3.3), jehož možnosti byly doplněny schopností získávat informace o identifikačních kódech přijíždějících boxů od agentů čteček RFID fyzicky umístěných před výhybkou. Jeden z problémů, který bylo nutné vyřešit, spočíval v tom, že identifikační kód přijatý výhybkou neobsahuje informaci o destinaci výrobku, tj. jméno některé z pracovních (balicích) stanic, kde se kontejner s boxem nachází během činnosti robotu. Jednou z možností by bylo vytvořit speciální agent, jenž by obsahoval aktuální informaci o destinaci všech boxů. Ten by byl dotazován agenty výhybek. V případě selhání tohoto agentu by však byla informace o místech plnění boxů kompletně ztracena. To zřejmě vede k selhání systému jako celku. Rozumnější řešení je tuto informaci distribuovat, a to nejlépe tak, že každý box je reprezentován vlastním agentem nesoucím informaci o cíli dopravy. Jméno tohoto agentu – pod nímž je v systému zaregistrován, a které tak může být použito jako tzv. parameter receiver, tedy příjemce při zasílání zprávy – se zvolí shodné s EPC. Agent výhybky pak získá potřebný údaj o místě určení přímo od agentu boxu.

4.4 Agent robotu a skladové jednotky
Agent robotu řídí balicí operace fyzicky prováděné robotem Fanuc M6i. Plnění boxu je robotem zahájeno při přijetí žádosti přímo od agentu boxu, a to v okamžiku, kdy kontejner s boxem dorazí do pracovní stanice. Zpráva zaslaná robotu obsahuje specifikaci obsahu dárkového balíčku. Agent robotu zahájí komunikaci s agentem skladové jednotky, přičemž cílem je zjistit index zásobníku, v němž se produkt daného typu nachází. Je-li produkt ve skladové jednotce, robot jej vyjme ze zásobníku a uloží do boxu. Uvedený postup se pro jednotlivé produkty opakuje.

4.5 Agent objednávky a výrobku
Agent objednávky, automaticky vytvořený při vložení objednávky dárkového balíčku, zahájí vyjednávání s existujícími agenty výrobků reprezentujícími dostupné boxy v systému (ať již prázdné či naplněné). V případě, že existuje vhodný prázdný box a agent s ním asociovaný je ochoten spolupracovat (tj. „nepracuje„ právě pro jiný objednávkový agent), převezme tento agent další zpracování objednávky. Při tom postupuje tak, že nejprve zjistí, jaké skladové jednotky jsou v systému přítomny (agentní systém umožňuje vyhledávat agenty podle nabízených služeb) a tyto jednotky kontaktuje. Cílem kontaktu je zjistit, která z nich obsahuje požadované produkty. Následně agent boxu pro vybranou skladovou jednotku určí vhodnou pracovní stanici, kde bude obsloužen robotem, a jméno této stanice si zapamatuje jako svůj cíl dopravy (ten pak sděluje výhybkám – viz kap. 4.3). Jakmile robot dokončí všechny operace (agent boxu je informován o výsledku), vrací se box zpět do hlavní zásobovací smyčky. Jestliže je objednávka splněna, je o tom agent objednávky agentem boxu informován. Není-li tomu tak, agent boxu po určité době opakuje vyjednávání se skladovými jednotkami s cílem doplnit chybějící produkty.

4.6 Použití agentů systému MAST pro fyzické řízení linky
Hlavním problémem při aplikaci systému MAST pro řízení výrobní linky je vytvořit rozhraní pro přístup agentů (naprogramovaných v jazyce Java a běžících v PC) k parametrům snímačů a akčních členů linky. V současné implementaci jsou virtuální snímače a akční členy (v emulaci výrobního zařízení poskytované systémem MAST) přímo svázány s odpovídajícími agenty. Místo toho bude použito sdílení parametrů v paměti (datové tabulce) programovatelného automatu ControlLogix (viz kap. 2). Je zřejmé, že simulační část systému MAST (emulující výrobní proces), která je takto propojena s agentní vrstvou, může být velmi snadno nahrazena vazbou na fyzický hardware, tj. vazbou na fyzické snímače a akční členy spojené přes I/O modul s PLC (agentní vrstva řízení zůstává beze změny).

6. Závěr

V příspěvku je ukázána role simulace při návrhu a implementaci multiagentních řídicích systémů. Z uvedeného je zřejmé, že simulační systémy pro tento typ úloh reprezentují komplexní vývojová prostředí pro agentní řešení spíše než jen jednoúčelové simulační nástroje. Jako jeden z prvních nástrojů tohoto druhu je prezentován systém MAST. Je ukázáno jeho použití v případě simulace reálného (byť experimentálního) výrobního provozu a jsou diskutovány možnosti použití agentů implementovaných v systému MAST pro reálné řízení výrobní linky.

Pavel Vrba, Ph.D.,
Výzkumné středisko Rockwell Automation, Praha
(pvrba@ra.rockwell.com)