Aktuální vydání

celé číslo

11

2021

Monitorování stavu zařízení, diagnostika, řízení údržby

Snímače a systémy řízení polohy a pohybu (motion control)

celé číslo

Použití inteligentních agentů pro zajištění dostupnosti a rozložení zátěže řídicích systémů

číslo 3/2005

Použití inteligentních agentů pro zajištění dostupnosti a rozložení zátěže řídicích systémů

Příspěvek stručně shrnuje základní pojmy z oboru inteligentních agentů. Na případu výpočetního systému s požadovanou dostupností a spolehlivostí ukazuje netradiční možnost použití jednoduchého multiagentního systému a probírá jeho hardwarové i softwarové aspekty.

1. Úvod

Existuje mnoho pracovišť, na kterých je požadována trvalá a bezpečná dostupnost výpočetní techniky a současně i její dostatečný výkon. Mezi taková pracoviště patří všechny výrobní provozy založené na počítačích, dále řídicí a dohledová centra podniků a provozoven, zejména pracoviště v nepřetržitém provozu. V článku [1] bylo ukázáno, že takovým pracovištěm je i pult centralizované ochrany PCO. Dostupnost výpočetní techniky se ve zmíněných případech řeší zálohováním, i vícenásobným, a vhodným přepínáním zátěže. Dokonalé zálohování však vede k cenám hardwaru řádově v mnohonásobku ceny PC, a z tohoto důvodu je pro mnoho malých a středních firem v podstatě nedosažitelné.

Dále bylo ukázáno, že samotné zálohování hardwaru je nedostačující. V běžných aplikacích v průmyslovém řízení je totiž hardware mnohokrát spolehlivější než software. Je to dáno tím, že v tomto případě vesměs jde o unikátní aplikace „ušité na míru„ dané technologii, danému problému. Na rozdíl od programů typu „textový editor„, provozovaných denně v milionech kopií, jsou technologické a dohledové aplikace používány a testovány jen v omezeném rozsahu. Například kritické a havarijní stavy jsou (naštěstí) vyzkoušeny vesměs jen v umělých podmínkách při simulovaných situacích. Přitom je ale dobře známo, že k většině havárií dochází právě proto, že se řízený proces dostal mimo projektované podmínky: havárie obvykle nastávají v situacích, které projektant neuvážil, a proto v nich systém nemohl ani testovat.

Z uvedených důvodů je vhodné a potřebné zabývat se zejména dostupností a spolehlivostí z hlediska softwaru.

2. Teoretický pohled na softwarové agenty

Protože jsme se zabývali řešením založeným na metodě inteligentních softwarových agentů, přiblížíme si nejprve některé základní principy z této oblasti.

2.1 Budoucnost je distribuovaná

V oblasti vývoje rozsáhlých programových celků se již dávno ví, že řešit komplexní úkol jako celek je těžší a pracnější než rozložit jej na více menších a samostatně řešitelných modulů. V teorii programování to vedlo ke vzniku postupů, jak programovat modulární celky, jejichž části (moduly) ale většinou byly úzce lokalizovány. To znamená, že po svém naprogramování a odladění byly části sestaveny do jednoho většího celku, typicky do jediného výsledného programu, nebo do dvou jeho disjunktních částí (např. klient-server). Podstatné přitom je, že celek byl dekomponován pro potřeby naprogramování, a nikoliv pro potřeby provozování výsledného systému.

Právě architektury jako klient-server či vícevrstvé architektury ukázaly, že modularita je výhodná i při provozování systému. V jistém smyslu lze říci, že metoda agentů je abstrakcí vícevrstvé architektury, jejím zobecněním do velkého počtu vrstev. Jakmile se připustí, aby se na plnění společného úkolu podílelo více různých složek, je vhodné se ptát po jejich vzájemných vztazích a také po jejich umístění. Pokud jde o vztahy mezi moduly, jsou v zásadě dvě možnosti: buď jsou všechny moduly rovnocenné, nebo jsou některé z nich privilegované. V druhém případě se hovoří o vztahu agentu a jeho manažeru. Typickým příkladem může být model uplatňovaný u různých monitorovacích systémů, které mají za úkol dohlížet na stav sítě: do klíčových míst sítě se umísťují prvky fungující jako sběrače informací – agenty. Získaná data většinou nijak podrobněji nevyhodnocují, pouze je předávají dál tomu modulu, který si je od nich vyžádá. Tím bývá hlavní modul příslušného monitorovacího systému, označovaný jako manažer. Manažer vyhodnocuje získaná data a v návaznosti na to podniká další akce (např. informuje uživatele o stavu sítě). Na tomto principu je v současnosti založena většina prostředků pro správu sítě. Také na protokol SNMP (Simple Network Management Protocol) lze nahlížet jako na konvenci o způsobu komunikace mezi manažerem a jeho agenty. Z uvedeného je však zřejmé, že v těchto případech jsou agenty spíše jednoduché programy, které mají k inteligentnímu chování daleko. Proto se zde uspořádáním agent-manažer nebudeme zabývat; případné zájemce odkazujeme na článek [2].

Naproti tomu v případě, že v systému operuje větší množství rovnocenných agentů, musejí tyto agenty vykazovat alespoň minimum inteligentního chování. Přinejmenším musejí mít schopnost vzájemné komunikace, koordinace a kooperace. Vhodné též je, aby agenty měly společnou bezpečnostní politiku. To vystupuje do popředí zejména tehdy, když agenty nejsou umístěny jen na jediném počítači, ale když jsou distribuovány na více počítačích propojených v síti, nebo když se dokonce jedná o mobilní agenty, které se mohou v síti pohybovat a spouštět se podle potřeby na různých místech.

2.2 Pojem inteligentních agentů

Pro software, který podle pokynů (pravidel) uživatele samostatně jedná, se vžilo označení inteligentní agent. Inteligentní agent má tyto základní vlastnosti:

  • Agent je autonomní – má kontrolu nad vlastními akcemi, nad vlastním chováním. To znamená, že je schopen provádět uživatelem definované úlohy nezávisle na uživateli, často i bez jeho přítomnosti nebo vedení. Uživatel jednou specifikuje, co, kde a kdy má agent vykonávat, a ten vykonává daný úkol pouze tehdy, když nastanou vhodné podmínky.

  • Agent je řízen cílem. Agentem může být program, skript nebo množina pravidel, jejichž chování je cíleno k dosažení určitého výsledku.

  • Agent reaguje – registruje změny prostředí a na změny odpovídá provedením akce.

Vedle těchto základních vlastností mohou mít agenty ještě mnoho dalších charakteristik:

  • Agent může být mobilní – podle potřeby se může přemísťovat v síti z jednoho stroje na druhý, vykonávat činnost na různých místech a zase se deaktivovat.

  • Agent může být vybaven schopností kooperace, tzn. že může komunikovat s ostatními agenty, může s nimi své akce koordinovat. Poznamenejme, že právě schopnost kooperace agentů je klíčovou charakteristikou, která přináší důležitou kvalitativní změnu. Schopnost kooperativního zpracování úloh se někdy pokládá za mezník mezi klasickým pojetím umělé inteligence a mezi tzv. moderním pojetím, založeným na multiagentních systémech [3].

  • Agent může být vybaven schopností přizpůsobení, zejména schopností učit se na základě předchozí zkušenosti a vyvíjet se. Pokusy o genetický vývoj agentů jsou již známy, zatím jen se spornými výsledky.

2.3 Sítě agentů

Protože síla a smysl agentů se plně projeví teprve při vzájemné interakci, mají vztahy mezi agenty a okolím zásadní důležitost. Operační systém běžného počítače není vybaven prostředky pro podporu agentů a jejich vzájemné komunikace. Proto se nad operačním systémem realizuje nadstavba, která představuje plnou podporu pro agentové řešení. Hovoří se o agentové platformě. Má-li podobu samostatné aplikace, teoreticky může být na jednom počítači spuštěno i několik agentových platforem. Každý agent se projevuje jako vlákno (thread) nebo samostatný proces, může tedy vykonávat úlohy podle vlastní iniciativy. Obráceně platforma poskytuje agentům prostředí pro existenci a činnost v počítačových sítích, tedy umožňuje agentu operovat na jednom či více počítačích. V tomto smyslu se hovoří o síti agentů. Každá platforma reprezentuje jeden uzel v síti agentů.

Základním pojmem v síti agentů je pojem služby. V síti se v zásadě vyskytují agenty poskytující služby a agenty tyto služby využívající. Obvykle je agent pro některé služby poskytovatelem a pro jiné zase spotřebitelem. Mnoho služeb poskytuje agentům přímo platforma. V zásadě lze služby v agentské síti rozdělit na síťové a aplikační. Síťové služby zabezpečují síťovou infrastrukturu a integrují jednotlivé součásti sítě. Jde zejména o:

  • komunikační služby, tedy o prostředky ke komunikaci mezi jednotlivými entitami sítě,

  • identifikační služby, jejichž smyslem je starost o identitu jednotlivých entit sítě, tedy zejména vytváření jednoznačných identifikátorů pro entity, řízení jejich užívání a rušení,

  • adresářové služby, které umožňují sdílet informace o entitách a o službách v síti agentů,

  • řídicí služby, umožňující řídit ostatní prvky sítě (agenty, služby, platformy či další síťové služby – jde o služby na metaúrovni, především zamýšlené jako prostředek pro řízení sítě člověkem – operátorem).

Aplikační služby poskytují veškeré řídicí a zpracovávací funkce aplikace. Jsou plně závislé na konkrétní aplikaci.

Obr. 1.

Obr. 1. Vzájemná vazba mezi platformou, agenty a službami

Vzájemnou vazbu mezi platformou, agenty a službami vysvětluje obr. 1. Podrobnější vysvětlení architektury agentských sítí a doporučení k jejich konstrukci lze nalézt v článcích [4] a [5].

2.4 Mobilní agenty

Zvláštním typem inteligentního agentu je mobilní agent. Mobilní agent je inteligentní agent, který není vázán na místo svého vzniku. Pracuje samostatně ve prospěch uživatele; při plnění úkolu se podle svého rozhodnutí přesouvá v síti, aby získal výhodu lokálního přístupu k požadovanému, vzhledem k uživateli vzdálenému, zdroji. Při přesunu agentu v síti je nutné přenést jeho programový kód (nejčastěji je program agentu zapsán interpretovatelným jazykem) a jeho stav. Každý agent je globálně jednoznačně identifikován jménem, které je složeno ze jména autority (vlastníka agentu) a jednoznačného jména v rámci autority. Pro přenos vnitřního stavu agentu je nutné jeho stav sekvenčně zakódovat. Proces kódování stavu agentu do posloupnosti se nazývá serializace, opačný postup deserializace. V současné době lze využít serializační metodu poskytovanou jazykem Java nebo serializační službu systému CORBA (Common Request Broker Architecture Externalization Service).

Přenos agentu mezi agentskými platformami zahrnuje zejména akce uvedené v následujících odstavcích.

2.4.1 Inicializace přenosu

Jako parametr této akce je nutné zadat cílovou platformu a pracovní místo v této platformě. Dojde k ukončení vlákna (thread) zdrojového agentu. Poté se identifikují a serializují ty údaje o stavu agentu, které se mají přenést, a zahájí se přenos agentu ve vhodném přenosovém protokolu.

2.4.2 Přenos tříd

Přenesou se třídy potřebné pro běh agentu na cílové agentské platformě. Přenos zahrnuje nejen vlastní třídu agentu, ale všechny další třídy, které agent ke své práci potřebuje. Není však vždy nutné přenášet všechny třídy, protože cílová agentská platforma mohla potřebné třídy získat již dříve. Přenos potřebných tříd má několik základních variant:

  • Automatický přenos všech potřebných tříd. V této variantě je nutné, aby zdrojová agentská platforma byla schopna všechny potřebné třídy identifikovat.

  • Automatický přenos pouze agentské třídy. Ostatní třídy se přenesou na žádost cílové agentské platformy v okamžiku, kdy je při běhu agentu potřebuje. Problém nastává, odpojí-li se po přenosu agentu zdrojová agentská platforma nebo vzdálený klient.

  • Přenáší se seznam všech potřebných tříd, cílová agentská platforma si ihned vyžádá všechny třídy, které ještě nemá.

2.4.3 Příjem a spuštění agentu

Na cílové platformě je agent přijat, deserializován a poté spuštěn.

2.5 Bezpečnostní rizika mobilních agentů

Z jednoduché úvahy plyne, že použití mobilních agentů nejen že je velmi účinné, ale může být také zdrojem významných bezpečnostních rizik. Proto je bezpečnostní služba nedílnou součástí agentské platformy. Základní funkce bezpečnostní služby zahrnují:

  • Autentizaci klientu pro vzdálené vytvoření agentů. Tato služba se obvykle používá, chce-li uživatel na vzdálené platformě vytvořit agent, přičemž jde o systém, který nepracuje s mobilními agenty. K autentizaci se používají obvyklé postupy – ochrana heslem, autentizace předmětem (kartou apod.).

  • Vzájemnou autentizaci agentských platforem. Tím se rozumí autentizace bez interakce uživatele. Lze ji realizovat udržováním důvěrné informace na agentské platformě, např. metodami asymetrické kryptografie (podpis privátním klíčem). Před přijetím agentu musí mít cílová agentská platforma přístup k informacím o zdrojové agentské platformě i o agentu, aby s jejich znalostí mohla aplikovat vhodnou bezpečnostní politiku po přijetí agentu.

  • Zjištění práv agentu. Současně s přenosem agentu se musí přenášet jeho práva na uskutečňování určitých akcí, přičemž na hostitelské agentské platformě se mohou práva oslabit aktuálně aplikovanou bezpečnostní politikou.

  • Uplatnění bezpečnostní politiky. Agent i agentská platforma umožňují konzumentům služeb přístup ke svým metodám, ale musí mít nad přístupem kontrolu. Přístup může kontrolovat agent nebo agentská platforma – musejí být schopny identifikovat žadatele a zjistit jeho práva. Alternativně mohou vytvořit přístupový seznam a předat jej komunikačnímu podsystému, který jej bude při žádosti o přístup kontrolovat.

  • Volbu bezpečnosti komunikačního kanálu. Žadatel o komunikaci si může vybrat úroveň jejího zabezpečení (odolnost proti odposlouchávání a dekódování přenášených dat, odolnost proti poškození nebo neautorizovaným změnám v datech při přenosu, odolnost proti ztrátě některých zpráv nebo jejich opakovanému doručení).

Realizace dobrého mobilního agentu je dosti složitá a pracná záležitost. K usnadnění vývoje existuje mnoho proprietárních i obecně dostupných nástrojů. Z firemních nástrojů stojí za pozornost např. Agent Building Environment Toolkit (ABE) od IBM. V oblasti freewaru lze doporučit zejména nástroje uvedené v [6]. Bohužel, nabídka není příliš pestrá, vesměs jde o nástroje založené na implementaci jazyka Java.

2.6 Paralelně pracující agenty

My jsme se mobilními agenty blíže nezabývali, protože v našem případě bylo možné požadovaného cíle dosáhnout jednoduššími prostředky. Namísto mobilních agentů jsme použili koncepci, ve které je na každém počítači připraveno ke spuštění větší množství agentů. Tyto agenty jsou různých tříd, přičemž každá třída je specializována na vykonávání určité operace. Jednotlivé instance agentů dané třídy jsou aktivovány (spouštěny) podle potřeby a po dokončení své operace jsou zase odstraněny. Jde tedy o situaci, kdy v daném okamžiku může být na jednom počítači aktivních několik různých tříd agentů, přičemž každá třída je zastoupena několika shodnými a paralelně pracujícími instancemi. Mobilnost agentů je tedy nahrazena generováním a rušením paralelně běžících instancí agentu, což je mnohem jednodušší jak z hlediska bezpečnosti, tak i z hlediska zatížení sítě. Pro náš zamýšlený účel, levný a robustní počítačový systém s vysokou dostupností, je to zcela vyhovující.

2.7 Normalizace a koordinace prací

Je zřejmé, že vzájemná propojitelnost a zaměnitelnost agentů napsaných v různých prostředích a pro různé platformy by byla výhodou. K tomu je ovšem třeba jistá úroveň kooperace a normalizace mezi výrobci. Proto se stručně zmíníme o některých normalizačních aktivitách, které pokládáme za důležité.

V první řadě je nutné se zmínit o aktivitě FIPA (Foundation for Intelligent Physical Agents). FIPA je nezisková organizace zaměřená na standardizaci a kooperaci heterogenních agentů. Jejím závažným počinem je vytvoření doporučení pro abstraktní architekturu (AAS, Abstract Architecture Specification). Přestože AAS neřeší některé zásadní problémy, jde o doporučení, které významně přispívá k unifikaci. Mezi oblasti, které AAS neřeší, patří životní cyklus a řízení agentu, mobilita agentu a identita agentu. Agentlink je evropská organizace pro agentové metody. Jde o nadnárodní síť, jež sdružuje výzkumníky a vývojáře. Organizace je sponzorována EU, proto je členství bezplatné. Agentcities je celosvětové fórum OpenNET, které je založeno na myšlence bezplatného šíření vědomostí (obdoba generální veřejné licence GPL). Agentlink i Agentcities nabízejí množství otevřených projektů.

Webové adresy nadací a sdružení zabývajících se agentovými metodami jsou v tab. 1.

Tab. 1. Odkazy na webu

http://www.fipa.org Nadace pro inteligentní fyzické agenty (Foundation for Intelligent Physical Agents)
http://www.agentlink.org Agentlink, evropská organizace pro agentové metody
http://www.agentcities.org/index.jsp Agentcities, celosvětové fórum zabývající se agentovými metodami

Multiagentní systémy nejsou pouhou teorií. Přestože jde o obor mladý a dosud se vyvíjející, existují již úspěšné aplikace v praxi. V České republice je znám systém pro výrobní plánování v průmyslu ProPlanT [7], úspěšně aplikovaný ve firmách LIAZ (výroba nákladních automobilů) a TESLA TV (vysílače).

3. Případová studie

Ukažme nyní jeden příklad, jak je možné teorii softwarových agentů aplikovat v praxi. Postavme si následující ambiciózní úlohu: vytvořit systém s nepřetržitou dostupností, jehož funkčnost i dostupnost budou zachovány i při poruše kterékoliv jednotlivé součástky. K tomu jako doplňující požadavek stanovme, aby cena řešení byla minimální, aby bylo možné spolehlivě zálohovat jednotlivé části softwaru a aby programy byly laděny a testovány v malých nezávislých blocích, v případě potřeby i za provozu aplikace. Takové požadavky jsme řešili jako případovou studii pro pult centrální ochrany (PCO), ale mohou se vyskytnout v téměř každé firmě.

3.1 Koncepce hardwaru

Nutnou podmínkou je existence plně funkčního, spolehlivého hardwaru a základního softwaru. Z cenových důvodů se soustředíme na řešení s obecným operačním systémem a s komerčním, dostupným databázovým strojem.

Obr. 2.

Obr. 2. Topologie hardwaru PCO

Jak bylo ukázáno v článku [1], cluster sám o sobě neřeší ani otázku stoprocentní spolehlivosti hardwaru, ani otázku připojených periferií. Proto jsme zvolili robustnější koncepci, jež je založena na plném zálohování. Její princip ukazuje obr. 2.

Hardware systému může být sestaven z libovolného počtu serverů; na obr. 2 jsou znázorněny jen dva (server A a server B). Každý server je koncipován jako zcela autonomní, tedy je vybaven i svým vlastním nepřerušitelným napájecím zdrojem. Každý server má také své vlastní diskové pole na úrovni RAID-5 (význam viz [1]). Tím je zabezpečeno, že jednotlivé servery jsou už samy o sobě značně odolné a dostupné.

Odolnosti proti poruchám sítě se dosahuje tím, že servery i ostatní zařízení jsou propojeny dvěma nezávislými sítěmi LAN. Protože tato koncepce není úplně běžná, ve stručnosti ji popíšeme. Obě sítě jsou provedeny skutečně jako nezávislé: k propojení se použijí dva kabely, v počítačích včetně serverů jsou dvě síťové karty atd. Běžné síťové karty nejsou k tomuto účelu příliš vhodné, protože je třeba umět dynamicky (za chodu) změnit adresu MAC (Media Access Control) karty. Lépe je použít přímo síťové karty pro to určené. V době, kdy jsme projekt navrhovali, byly na trhu dostupné např. karty Intel PRO/100+ Dual Port Server Adapter, což jsou speciální dvojité karty, nebo jednoduché karty řady 3C980C. Nepochybně existují i další. Jedna z karet je vždy jako činná, druhá jako záložní. Jsou inicializovány a přepínány pro počítače neviditelně, a tedy nezávisle na stavu obou serverů. O to se stará dvojitý dynamický směrovač.

My jsme v projektu použili směrovač řady 4400. SuperStack3 Switch 4400 je řada inteligentních přepínačů Fast Ethernet, jež jsou schopny klasifikovat toky dat a přiřadit jim prioritu (layer 2 – layer 4). Umožňují bezproblémový přenos hlasu a dat spolu s jinými aplikacemi. Switch 4400 přepíná na rychlosti média (wire speed) na 24 portech 10/100BASE-TX a je vybaven dvěma sloty pro vysokorychlostní moduly. Je stohovatelný do celkového počtu osmi přepínačů, a lze tedy vytvořit maximální konfiguraci 192 10/100 portů a osm přídavných gigabitových portů (pro správu celého stohu se potom využije libovolná IP adresa jednoho z přepínačů). Přepínač je vybaven sadou vyspělých funkcí. Při poruše kterékoliv součástky je směrovač schopen detekovat chybu a automaticky rekonfigurovat celou síť tak, že síť je poté schopna pokračovat v provozu. Proces rekonfigurace trvá maximálně šedesát sekund.

Tímto způsobem je na hardwarové úrovni zajištěna nepřetržitá dostupnost pro celý systém.

Součástí této fáze návrhu bylo také rozhodnutí o vhodném základním softwaru, tedy zejména o operačním systému a o databázovém stroji. My jsme zvolili databázový stroj Oracle. Volba vycházela ze schopnosti databáze Oracle rychle a bezpečně provádět replikace a podstatná byla též otázka ceny a licenční politiky.

Obr. 3.

Obr. 3. Obecná hvězdicová topologie hardwaru s nepřetržitou dostupností

Zdůrazněme, že není žádný důvod, proč by se počet serverů měl omezovat na pouhé dva, ukázané na obrázku. Naopak, větší počet serverů by kladně ovlivnil jak zatížitelnost systému, tak jeho odolnost proti útokům DoS. Navíc je možné některé servery umístit do vzdálených míst a tím dále zlepšit zabezpečení systému proti některým druhům útoků a získat rychlejší reakci při obsluze z blízkého serveru. U složitějších aplikací proto bude hardwarový model vypadat spíše jako na obr. 3.

3.2 Agentová dekompozice softwaru

Hardwarový model řešil pouze fyzickou stránku systému, včetně základního programového vybavení, které je univerzální a aplikačně nezávislé. Nijak se zatím nezabýval otázkou funkčnosti aplikace a jejích individuálních požadavků.

Úvahy o struktuře softwaru zahájíme podrobnějším pohledem na databázový stroj. Představme si, že bychom na všech serverech nechali běžet stejnou databázi. Přitom všechny servery budeme pokládat za rovnocenné. To znamená, že databázi je možné měnit na kterémkoliv serveru a provedená změna se automaticky rozšíří na ostatní servery prostřednictvím replikace. V takovém případě dostaneme mimořádně robustní databázový stroj: použitý software (Oracle) je už sám o sobě značně odolný a jeho zmnohonásobení na několika serverech dává tak silnou dodatečnou bezpečnostní rezervu, že celek lze pokládat za v podstatě „neshoditelný„. Právě robustní nepřetržitě dostupná databáze je základem pro naše další úvahy.

Nyní se zabývejme otázkou, proč je robustní databáze tak důležitá. Základem zvolené koncepce je zjištění, že mnoho aplikací pro řízení v průmyslu lze popsat buď jako lineární posloupnost akcí (pipe), nebo jako posloupnost s konečným a obvykle malým množstvím rozvětvení.

Činnost konvenčních aplikací typu PCO začíná v okamžiku, kdy přijímač obdrží signál z některého objektu. Tento signál je zašifrovaný a kódovaný pomocí řady číselníků. Prvním krokem k jeho zpracování proto musí být dešifrování a dekódování a dalším krokem vyhodnocení z hlediska nebezpečných stavů. V našem případě, tj. v případě robustní aplikace, se ale v prvním kroku celý přijatý signál (bez jakéhokoliv zpracování) zapíše do databáze. Teprve v dalším kroku se data signálu načtou z databáze, dešifrují a výsledek se znovu zapíše do databáze (do jiné tabulky). V následujícím kroku se dešifrovaná data načtou, dekódují podle číselníků a zase zapíšou do databáze. Poté jsou zpracována, tzn. opět načtena a vyhodnocena. Informace o tom, že signál byl zpracován, se opět zapíše do databáze. Tímto postupem pokračuje zpracování signálu tak dlouho, dokud není zpracování úplně dokončeno.

Ukáže-li se při zpracování, že je třeba vykonat nějakou akci, např. spustit výjezd zásahového vozidla, vygeneruje se k tomu účelu nový záznam do tabulky akcí a ten se zapíše do databáze. Jinými slovy, odstartuje se nový proces, který bude dále zpracováván asynchronně a nezávisle na původním signálu z čidla. Zpracovává se rovněž metodou načti – spočítej – zapiš.

Tímto způsobem je možné průběh zpracovávání rozepsat na jednotlivé kroky, jejichž ústředním bodem je databáze a společnou vlastností to, že jsou vykonávány asynchronně. Jednotlivé operační kroky mohou mít podobu samostatných programů, jednoduchých agentů. Agent může být koncipován tak, že testuje výskyt nových dat (např. nového záznamu v určité tabulce), a jestliže nová data nalezne, vykoná svou činnost a skončí zápisem výsledků do databáze.

Na první pohled možná není zřejmá výhoda takovéhoto postupu. Mohlo by se zdát, že opakované zápisy a čtení z databáze představují pouze nežádoucí zpomalení aplikace. Uvedená koncepce však přináší četné výhody. Hlavním důvodem, proč jsme takovouto koncepci zpracování zavedli, je distribuovanost. Tím, že se databáze automaticky replikují na všech serverech, v podstatě nezáleží na tom, na kterém serveru se která operace vykonává. Je tedy v zásadě možné agent realizující určitý operační krok spustit podle potřeby buď na jednom serveru nebo na skupině serverů, popř. na všech serverech současně. Dokonce lze týž agent spustit současně ve více instancích na jednom serveru. Agenty pro daný operační krok si začnou navzájem konkurovat a operaci vždy vykoná ten, který k tomu bude mít nejlepší příležitost.

Snadno lze realizovat triviální přidělovací strategii spočívající v přístupu „kdo dřív přijde„. V takovém případě agent, který se ke zpracovávaným datům dostane jako první, zablokuje data pro sebe a pro své zpracování. S výhodou je tak možné realizovat zámek (lock) na daném záznamu. Tato strategie je realizačně velmi jednoduchá, robustní (nepotřebuje žádné centralizované řízení) a současně respektuje i proměnlivé zatížení serverů: agent na vytíženém serveru se k datům dostane později, a proto je menší pravděpodobnost, že úlohu převezme. Lze si ovšem představit i mnohem důmyslnější strategie.

Popisovaná strategie znamená naprostou zastupitelnost: kdyby selhal kterýkoliv server (nebo skupina serverů), agenty na ostatních serverech se o tom nedovědí – a ani nepotřebují dovědět. Automaticky převezmou zátěž z vadného serveru, aniž by byla ohrožena funkčnost aplikace.

Druhou výhodou je jednoduchost ladění. Tím, že se složitá aplikace rozloží na řadu triviálních kroků, každý z nich s jednoznačným a kontrolovatelným výsledkem, se velmi usnadní ladění aplikace. Je tomu tak proto, že v databázi lze vždy nalézt mezivýsledky, podle kterých je možné lokalizovat místo vzniku chyby. Dokonce je touto cestou možné zabezpečit i zotavení dat po některých chybách – stačí vadné záznamy odstranit a nahradit správnými; o další zpracování už se zcela regulérně postarají ostatní agenty. Data lze opravit i za chodu aplikace.

Třetí podstatnou výhodou popsaného řešení je škálovatelnost: při nárůstu zátěže postačí přidat další server a spustit na něm potřebné agenty. Tím se zátěž automaticky rozdělí.

Nezanedbatelnou výhodou je také snadná a centralizovaná správa. Tím, že je celá replikace ponechána na databázovém stroji, omezuje se správa systému na lokální úkony na jednom serveru. Na ostatní servery se změny replikují automaticky.

Doposud jsme na aplikaci pohlíželi, jako kdyby k její obsluze stačil konečný počet sekvenčně spouštěných agentů. Bohužel praxe ukazuje, že to není pravda. Doposud popsané řešení by trpělo velmi nepříjemnou vlastností – kdyby některý agent „zamrzl„ poté, co si pro sebe monopolizoval určitá data, ke zpracování těchto dat by nikdy nedošlo. To nelze připustit. Naštěstí je řešení snadné. K systému se přidá určitý počet dohlížecích agentů. Dohlížecí agenty se nepodílejí na řešení úloh přímo. Namísto toho cyklicky procházejí databázovými tabulkami a vyhledávají případy, kdy jsou některá data zpracovávána příliš dlouho. Naleznou-li takový případ, vyřeší ho podle potřeb aplikace. V našem případě PCO se každý takový případ zdokumentuje pro pozdější analýzu, zablokovaný agent se „násilím„ ukončí (a znovu spustí) a data se odblokují. Je-li časový limit správně nastaven, nemusí dojít k žádnému výpadku.

Zvláštním případem dohlížecího agentu je jakýsi „generální inspektor„, který prochází všemi případy a kontroluje, zda byly zpracovány. Jde o zpětnou vazbu, která odhalí i takové případy, kdy by např. operační důstojník přehlédl příkaz k výjezdu, nebo kdy by zásahová skupina sice vyjela, ale k cíli by nedorazila. (Nebo i případ, kdy by zásah proběhl, ale účtárna by zapomněla poslat fakturu.)

3.3 Komunikace jako základ pro existenci agentů

Na první pohled by se mohlo zdát, že realizace agentů tak, jak byly definovány v kapitole o dekompozici softwaru, je složitý úkol. Ve skutečnosti mnoho vlastností, které od agentů požadujeme, lze v dostupných programovacích nástrojích napsat poměrně jednoduše. (Složitá by ovšem byla úplná a komplexní realizace podle některého standardu.) My jsme se soustředili na použití programovacího prostředí Delphi, ve kterém je napojení na databázový stroj Oracle velmi přímočaré a jednoduché, protože jsou k jeho uskutečnění využity osvědčené komponenty přímo v Delphi. Rovněž metoda samostatných programových vláken je v Delphi zvládnuta a nečiní vážnější problémy. Celé programování softwarových agentů se proto redukuje na otázku zajištění spolehlivé komunikace.

Pro komunikaci mezi softwarovými agenty navzájem, popř. mezi agentem a agentovou platformou, lze využít několik metod. Z nich každá má své opodstatnění pro určité případy. Mezi jinými jsou to:

  • CORBA (Common Request Broker Architecture) – umožňuje aplikacím komunikovat nezávisle na platformě, na které běží, na umístění či na jazyce, ve kterém byly vytvořeny,

  • MIDAS (Multi-tier Distributed Aplication Services) – primárně určena pro poskytování distribuovaných aplikačních služeb v decentralizovaných systémech (internet),

  • DCOM – upravená technologie COM (Common Object Model) pro použití v sítích, která umožňuje vytváření objektů COM v rámci sítě.

  • .NET – programový nástroj firmy Microsoft, rozšiřující dříve zavedené metody tak, aby nerozlišovaly, zda fungují v rámci jednoho počítače či v rámci počítačové sítě.

Z těchto možností jsme zvolili komunikační technologii DCOM. Vybrali jsme ji proto, že je v prostředí Delphi připravena k rychlému a snadnému použití.

3.4 Příklad vytvoření komunikačního rozhraní pro agent

Softwarové agenty je možné psát za stejných zásad a s pomocí stejných metod, které se používají k běžnému rutinnímu programování. Pokusná realizace tenkého inteligentního agentu byla řešena v několika diplomových pracích, např. [8], a byla psána v jazyce Delphi. Výsledkem je úvodní řešení, které prokázalo svou funkčnost v laboratorních podmínkách. Jedinou složitější částí úlohy bylo vytvoření komunikačního rozhraní DCOM, které nyní stručně popíšeme.

Metoda DCOM je rozšířením metody COM pro použití v síti. COM zavádí do programování pojmy, jako jsou komponenty či uživatelská rozhraní. DCOM tyto pojmy zobecňuje, použité objekty volané klientem nemusí být umístěny na stejném počítači a lze je volat pomocí sítě. Pouze je třeba zařídit, aby příslušná komponenta byla na počítači zaregistrována, tzn. zapsána do registrů v klíči HKEY_CLASSES_ROOTCLSID, a aby agent správným způsobem přistupoval k rozhraní dané komponenty.

Princip komunikace prostřednictvím DCOM spočívá ve vytvoření dvou spolupracujících částí – serveru a klientu DCOM. Způsob zavedení serveru DCOM do paměti počítače závisí na tom, zda jde o InProcess Server či OutOfProcess Server. InProcess Server je dynamická knihovna (DLL), která vytváří objekty DCOM pro své hostitelské aplikace. Nazývá se InProcess, protože volaná DLL sídlí ve stejném procesu jako volající aplikace.

OutOfProcess Server je spustitelný soubor, který dokáže vytvářet objekty DCOM využitelné z jiných aplikací. Název je odvozen z toho, že jako spustitelná aplikace běží server DCOM v jiném procesu než klientská aplikace. Je zřejmé, že v případě agentů půjde o server typu OutOfProcess, jelikož oba navzájem komunikující agenty budou dva na sobě nezávislé programy běžící na dvou různých počítačích.

Pomocí průvodce pro vytvoření Remote data module se v aplikaci vytvoří nový modul. V jednoduchém formuláři lze zadat jméno třídy vytvářeného objektu a základní parametry, způsob zpracování požadavků od klientů (Instancing) a určení způsobu předání požadavku klientu ke zpracování (Threading model). V nově vytvořeném datovém modulu se zajistí přístup k databázi a vloží se komponenta DataSetProvider, která zprostředkuje distribuci databáze po síti. Všechny komponenty se pomocí příslušných vlastností propojí, soubor se zkompiluje a agent je hotov. Takto vytvořený agent je velmi jednoduchý, bude pouze zpřístupňovat určitou předem nastavenou databázi, popř. dotaz na ni, pro svou jednoduchost však neumožní konkrétnější práci. Ostatní programy k výsledkům dotazu mohou přistupovat např. pomocí komponenty DCOMConnection (nachází se na záložce DataSnap).

Podrobnější popis rozhraní i popis práce s DCOM však již přesahuje rámec tohoto článku.

4. Zhodnocení a výhled

Agentová metoda se osvědčila pro realizaci levného a téměř stoprocentně spolehlivého počítačového systému. To ovšem neznamená, že je prosta jakýchkoliv nedostatků.

Mezi největší problémy patří replikace databází. V popsaném konceptu je veškerá komunikace se vzdálenými počítači realizována pomocí replikace databáze. V popisu činnosti jsme a priori předpokládali, že replikace probíhá bezchybně a ihned. Ačkoliv předpoklad spolehlivosti replikace je v praxi víceméně dodržen, nastávají problémy s konečnou rychlostí replikace databází.

Dokud není dokončena replikace databáze ve všech jejích instancích, nelze připustit aktivaci agentu, který reaguje na pozměněný stav databáze. Kdyby to totiž bylo možné, na počítačích bližších zdroji replikace by mohlo dojít k předčasnému spuštění instance agentu a tím např. k přetěžování blízkých počítačů. Jinými slovy, do strategie, podle které soutěží agenty o přidělení úlohy, bude nutné zavést hledisko času, zejména odhad doby šíření replikace na různé instance databáze.

5. Závěr

V článku je ukázán nový postup vytvoření spolehlivého počítačového systému s dostupností zaručenou i při poruše jakékoliv jeho součásti. Přednostmi jsou cena, která je podstatně nižší než při použití clusterové metody, bezpečnost proti chybám softwaru a snadné ladění. Podstatnou výhodou je také relativně jednoduchá realizace za pomoci známých vývojářských nástrojů.

Popsané řešení je výhodné ve všech malých a středních firmách, kde se z jakéhokoliv důvodu požaduje trvalý provoz počítačů, a to i při případných poruchách. Zejména může být výhodně použito pro řízení výrobních zařízení, pro zabezpečení obchodních a manažerských úloh i pro připojení k internetu.

Literatura:
[1] KOKEŠ, J. – KOKEŠ, J.: Zajištění dostupnosti a rozložení zátěže u řídicích systémů. Automa, 2004, roč. 10 , č. 1, s. 47–50.
[2] PETERKA, J.: Model agent/manažer. CHIPweek, č. 12/96, Praha, 1996. Dostupné též na http://www.earchiv.cz/a96/a612k150.php3 [cit. 4. 2. 2005].
[3] KIRN, S. – O’HARE, G. (Eds.): Cooperative Knowledge Processing. Springer-Verlag, London, 1997.
[4] Kol.: Agentcities Network Architecture Recommendation. Agentcities Task Force Recommendation Document, 08. October, 2002.
[5] VLACH, R.: Technologie inteligentních agentů. [Semestrální práce.] MFF UK, 1997. Dostupné též na http://www.ms.mff.cuni.cz/~vlach [cit. 4. 2. 2005].
[6] FIPA: Publicly Available Agent Platform Implementations. Dostupné na http://www.fipa.org/resources/livesystems.html [cit. 4. 2. 2005].
[7] MAŘÍK, V. – PĚCHOUČEK, M. – ŠTĚPÁNKOVÁ, O. – LAŽANSKÝ, J.: ProPlanT: Multi-Agent System for Production Planning. Applied Artificial Intelligence. Dostupné na http://agents.felk.cvut.cz/projects/proplant [cit. 4. 2. 2005].
[8] POLES, P.: Aplikační server. [Diplomová práce.] FSI ČVUT, Praha, 2001.

doc. Ing. Josef Kokeš, CSc.
(kokes@fsid.cvut.cz),
Josef Kokeš (agenti@pepak.net)
Údaje o autorech viz Automa 1/2004, s. 50

Lektoroval: prof. Ing. Vladimír Mařík, DrSc., FEL ČVUT v Praze