Universitatea Politehnic Bucureti

Facultatea de Automatic i Calculatoare

Departamentul de Automatic i Ingineria Sistemelor

LUCRARE DE LICEN

Managementul situaiilor de urgen utiliznd

sisteme multi-agent. Aplicaie la nivel
macroscopic: Protocoale sisteme critice

Absolvent
George-Alexandru Serea
Coordonator
S.l. dr. ing. Monica Ptracu

Bucureti 2013

Cuprins
1. Introducere ........................................................................................................................... 1
2. Ageni inteligeni i Sisteme Multi-Agent (MAS) ........................................................... 2
2.1. Ageni inteligeni .......................................................................................................... 2
2.1.1 Ageni care se bazeaz pe reflexe simple ............................................................. 2
2.1.2 Ageni care pstreaz o imagine a lumii .............................................................. 3
2.1.3 Ageni care se bazeaz pe un scop ........................................................................ 3
2.1.4. Ageni care se bazeaz pe utilitate ....................................................................... 3
2.1.5. Proprietile agenilor inteligeni ......................................................................... 4
2.2. Sisteme Multi-Agent (MAS) ........................................................................................ 4
2.2.1. Clasificarea Sistemelor Multi-Agent (MAS) ....................................................... 4
2.2.1.1. Clasificarea pe clase ........................................................................................ 6
2.2.1.2. Clasificarea bazat pe Inferen .................................................................... 7
2.2.1.3. Clasificarea bazat pe Percepie ................................................................... 7
2.3. Exemple de utilizare a Sistemelor Multi-Agent ....................................................... 8
3. Sisteme Multi-Agent utilizate n managementul situaiilor de urgen ...................... 9
3.1. Prezentarea arhitecturii CityScape ............................................................................. 9
3.1.1. inSCAPE .................................................................................................................. 9
3.1.2. eSCAPE .................................................................................................................. 10
3.2. Formularea problemei ................................................................................................ 11
3.2.1. esutul Protocoale sisteme critice .................................................................. 11
3.2.2. esutul Avertizri i controlul panicii .......................................................... 11
3.3. Soluia propus ........................................................................................................... 12
4. Studiu de caz ...................................................................................................................... 14
4.1. Descrierea aplicaiei .................................................................................................... 14
4.2. Prezentarea Toolkit-ului Custom City Builder...................................................... 15
4.2.1. Generarea unui cartier de cldiri i pavarea drumurilor aferente ................ 17
4.2.2. Adugarea identificatorului unic pentru fiecare cldire n parte ................. 18
4.2.3. Setarea perimetrului restricionat n jurul unei cldiri ................................... 19
4.2.4. Marcarea poziiei viitoare a unui agent i testarea in-cone ............................. 20
4.2.5. Modelarea deplasrii i a redresrii unui agent mobil ................................... 22
4.2.6. Adugarea de ageni ntr-un model cu restricie pe populaie ..................... 24
4.3. Modelul lumii .............................................................................................................. 26
4.3.1. Sistemele critice .................................................................................................... 26
4.3.1.1. Aeroportul ..................................................................................................... 26
4.3.1.2. Gara din afara oraului ................................................................................ 27
4.3.1.3. Gara din ora ................................................................................................. 27

4.3.1.4. Spitalul ........................................................................................................... 28

4.3.1.5. Centrala nuclear .......................................................................................... 28
4.3.1.6. Hidrocentrala ................................................................................................ 28
4.3.2. Ageni implicai n implementarea protocoalelor sistemelor critice ............ 29
4.3.2.1. Agenii de percepie ai mulimii DP ........................................................... 29
4.3.2.2. Agenii inclui n mulimea DA ................................................................... 30
4.3.2.3. Agenii de control ai mulimii DC ............................................................... 31
4.3.3. Agenii inteligeni mobili .................................................................................... 32
4.3.3.1. Pietonii............................................................................................................ 33
4.3.3.2. Agenii inteligeni din categoria rutier .................................................... 33
4.3.3.3. Agenii inteligeni de tip tren...................................................................... 34
4.3.3.4. Agenii inteligeni de tip avion ................................................................... 34
4.4. Scenarii de simulare .................................................................................................... 35
4.4.1. Scenariul 1: Cutremur de magnitudine 5 pe scara Richter............................. 36
4.4.2. Scenariul 2: Izbucnirea unui incendiu n spital ................................................ 37
4.4.3. Scenariul 3: Prbuirea avionului ...................................................................... 38
4.4.4. Scenariul 4: Ameninarea cu bomb a grii din ora ...................................... 39
4.4.5. Scenariul 5: Intrarea Aeroportului ntr-o pan de curent ............................... 40
4.4.6. Scenariul 6: Evacuarea oraului ......................................................................... 41
5. Concluzii ............................................................................................................................. 42
Anexe ....................................................................................................................................... 43
Procedurile setup i go ........................................................................................................ 43
Procedura de aplicare a evenimentului selectat asupra unui sistemul critic ............ 43
Procedura de micare a agenilor inteligeni ................................................................. 44
Procedurile utilizate n pentru construirea unui cartier .............................................. 45
Procedura care seteaz perimetrul resticionat ............................................................. 48
Procedura care seteaz interfaa, adaugnd senzorii i elementele de afiare
specifice sistemelor critice................................................................................................. 48
Procedura de adugare a senzorilor pentru sisteme critice ......................................... 49
Procedura de actualizare a timpului de rulare .............................................................. 49
Bibliografie .............................................................................................................................. 50

1. Introducere

n ultimele decenii, avansul tehnologic a permis mbuntirea calitii i

siguranei vieii umane, lucru reflectat n creterea i evoluia continu a sistemelor
urbane pn la megalopolisuri cu densiti locale ale populaiei de peste 10,000 de
locuitori pe kilometru ptrat. Aceast aglomerare ridic noi probleme n ceea ce
privete rspunsul sistemelor dedicate de intervenie n cazul situaiilor critice i
evidenieaz punctele slabe ale infrastucturii existente n majoritatea marilor orae.
Echipajele de intervenie ntmpin probleme datorit traficului supra-aglomerat i a
ambuteliajelor, iar evacuarea populaiei afectate este i ea ngreunat.
n lucrarea de fa vom urmri managementul situaiilor de urgen la nivel
macroscopic (ora) i vom implementa protocoale pentru sisteme critice i o form
minimal de avertizri, utiliznd programare orientat agent (AOP) pentru
modelarea sistemului multi-agent.
Aplicaia dezvoltat este flexibil, modelul lumii putnd fi modificat cu
uurin datorit construirii acestuia prin intermediul procedurilor de construcie a
cartierelor, cldirilor i a drumurilor. Analog, modificarea protocoalelor critice
utilizate se realizeaz prin intermediul procedurilor realizate.
n capitolul doi se prezint conceptele de agent i sisteme multi-agent (MAS), o
clasificare a acestora, dar i soluii deja implementate a acestor sisteme pentru
probleme de modelare actuale.
Capitolul trei restnge aria de acoperire a acestor sisteme i introduce
aritectura CitySCAPE i aplicabilitatea acesteia n cadrul lucrrii de fa, descriind
soluia de implementare propus.
Studiul de caz regsit n capitolul patru descrie modelarea lumii, att la
nivelul sistemelor critice considerate, ct i la nivelul agenilor inteligeni dezvoltai
pentru simularea traficului sau a populaiei. Totodat, se prezint toolkit-ul realizat
pentru testarea i implementarea soluiei propuse, evideniind utilitatea acestuia
pentru realizarea modelului lumii. De asemenea, capitolul patru conine scenariile de
simulare prin care sunt utilizate protocoalele sistemelor critice implementate i
efectul acestora asupra modelului lumii realizat.
Concluziile din capitolul cinci evidenieaz rezultatele obinute, dar i viitoare
implementri sau mbuntiri ce pot fi aduse lucrrii prezentate, n scopul realizrii
unui model al lumii ct mai apropiat realitii.
1

2. Ageni inteligeni i Sisteme Multi-Agent (MAS)

2.1. Ageni inteligeni

Agenii inteligeni sunt programe individuale, autonome ce au ca scop
ndeplinirea anumitor sarcini, numite deseori task-uri, care pot interaciona cu
mediul n care opereaz i, totodat, cu ali ageni inteligeni. Exist o posibil
definiie n literatura de specialitate (Wooldridge, 2002): Un agent este un sistem
computaional care este situat ntr-un mediu i care este capabil de aciuni autonome n acest
mediu n aa fel nct s i ating obiectivele stabilite.
Mediul n care un agent opereaz, conform (Russell & Norvig, 2010) se poate
clasifica n funcie de urmtoarele proprieti:
accesibil vs. inaccesibil. Un mediu accesibil este un mediu din care agentul
poate obine informaii complete si corecte despre starea curent.
deterministic vs nedeterministic. Mediul deterministic este acela n care
pentru orice aciune exist o consecin clar, sigur; nu exist nici o
incertitudine n ceea ce privete rezultatul unei aciuni.
static vs. dinamic. Un mediu static se poate considera neschimbat n lipsa
aciunilor agenilor, pe cnd asupra unui mediu dinamic opereaz i alte
entiti care nu depind de ageni.
discret vs. continuu. Putem numi un mediu discret dac exist un numr
exact, finit de aciuni si percepii n el.
Datorit faptului c agenii inteligeni sunt menii s ndeplineasc diferite
sarcini i c pot comunica fie ntre ei, fie cu mediul nconjurtor n scopul de a
extrage informaii din mediul n care sunt plasai prin intermediul senzorilor, exist
mai multe clasificri ale acestora, n funcie de criteriul considerat.
O clasificare remarcabil provine din (Russell & Norvig, 2010). Cartea
propune clasificarea agenilor n 4 categorii:
ageni reflex (ageni simpli care se bazeaz pe reflexe simple la input)
ageni care pstreaz o imagine a lumii
ageni care se bazeaz pe un scop
ageni care se bazeaz pe o utilitate

2.1.1 Ageni care se bazeaz pe reflexe simple

Axai pe stabilirea legturilor dintre intrri i ieiri, agenii care se bazeaz pe
reflexe sunt cei mai simpli. Practic, n funcie de intrarea perceput, acest tip de agent
2

returneaz o ieire prestabilit. Este de la sine neles c nu se pune problema

construirii unei tabele explicite care mapeaz legturile intrare-ieire posibile datorit
numrului extraordinar de combinaii posibile, ns la baza acestor ageni stau reguli
de tip condiie-aciune. De remarcat este faptul c acest tip de agent nu se modific
n timpul execuiei, motiv pentru care poate fi considerat a fi static din punct de
vedere al regulilor aplicate.

2.1.2 Ageni care pstreaz o imagine a lumii

Spre deosebire de agenii reflexivi la care aciunea este dictat exclusiv de ceea
ce se petrece n mediul nconjurtor, agenii care pstreaz o imagine a lumii se
folosesc de senzorii pentru a creea o stare intern ce ilustreaz situaia curent a
mediului. Pentru realizarea ct mai fildel i actualizarea acestei stri interne, agentul
are nevoie de dou tipuri de informaii. Pe de-o parte are nevoie de informaii
referitoare la evoluia lumii independent de aciunile sale i, pe de alt parte, de
informaii despre modul n care agentul modific mediul n care opereaz i ce
amprent las asupra sa. De notat este faptul c unui agent reflex (simplu) i se poate
atribui o stare intern, iar trecerea ctre noua stare intern se va face prin mbinarea
informaiilor provenite de la senzori cu informaiile strii interne. Apoi aceast nou
stare este interpretat prin intermediul regulilor prestabilite.

2.1.3 Ageni care se bazeaz pe un scop

n unele cazuri nu este suficient ca agentul s dein informaii doar despre
starea curent a mediului n care opereaz, motiv pentru care acest tip de ageni
conin i informaii referitoare la scopul pe care l au, informaii care denot starea n
care doresc s se ajung. Asemenea ageni estimeaz att consecinele aciunilor lor,
ct i avansul ctre scopul pe care l au de ndeplinit pentru a alege cea mai bun
variant posibil la momentul respectiv. Cartea reuete s evidenieze diferenele
dintre aceste tipuri de ageni astfel: considerm un agent inteligent de tip main. Un
agent reflexiv ar putea frna n momentul n care maina din faa sa frneaz pentru
c recunoate stopul central de pe lunet, fr a ine cont de alte considerente, pe
cnd un agent care cu o stare intern face distincia n mod intern ntre mainile cu i
fr stop central i se comport identic pentru amndou; frneaz. Considernnd
ns ca agentul ajunge la o intersecie, nu ar fi nici o diferen ntre cei doi, direcia ar
fi probabil total aleatoare, una dintre cele disponibile. Dac, n schimb, agentul are
un scop i presupunem c este un taxi care trebuie s ajung la o anumit destinaie,
el va alege ruta necesar pentru destinaia respectiv (Russell & Norvig, 2010).

2.1.4. Ageni care se bazeaz pe utilitate

De cele mai multe ori, scopurile nu sunt suficiente pentru a determina un
comportament de calitate n ceea ce privete agenii inteligeni. Spre exemplu, exist
foarte multe rute care duc taxiul la destinaie, ns unele sunt mai scurte i rapide, iar
3

altele sunt mai lungi i duc la ntrzieri. n astfel de cazuri este indicat ca agentul s
poat face distincia ntre dou decizii corecte i s o poat alege pe cea mai
favorabil. Pentru adugarea acestei puteri de decizie, agenilor inteligeni li se
atribuie mijloace prin care msoar utilitatea aciunilor lor i, astfel, determin cele
mai bune rspunsuri i aciuni. Practic, utilitatea atribuie fiecrei aciuni posibile un
numr real, direct proporional cu beneficiile aduse. Utilitatea ajut n cazuri n care
scopurile nu pot distinge ntre dou soluii i creeaz un echilibru ntre ele, de
exemplu alegerea vitezei optime n asa fel nct sigurana s nu fie riscat. De
asemenea, un agent bazat pe scopuri nu poate face distincia ntre dou scopuri, unul
mai uor realizabil dect cellalt, pe cnd utilitatea poate msura eventuala realizare
a scopului i ajut agentul n luarea deciziei corecte (Russell & Norvig, 2010).

2.1.5. Proprietile agenilor inteligeni

Pentru a fi cu adevrat inteligent, (Wooldridge, 2002) afirm c un agent
trebuie s integreze urmtoarele proprieti:
autonomie. Fiecare agent are eluri i resurse individuale i este capabil s
lucreze n lipsa interveniei exterioare
reactivitate. Un agent inteligent este menit s ofere mediului n care opereaz
un rspuns pe baza percepiilor dobndite
proactivitate. Agentul trebuie s fie capabil s ia iniiativa n aa manier nct
s i satisfac cerinele
sociabilitate. Pentru ndeplinirea cerinelor, agentul trebuie s fie capabil s
interacioneze si cu ali ageni, nu neaprat de acelai fel

2.2. Sisteme Multi-Agent (MAS)

Potrivit (Fulbright & Stephens, 1994), un sistem multiagent este constituit din
mai muli ageni inteligeni care opereaz n acelai mediu. Practic, ei interacioneaz att
cu mediul, ct i cu ali ageni, nu neaprat de acelai tip. Mai mult, dei agenii
mpart mediul, fiecare agent n parte percepe i acioneaz n mod independent. Vom
prezenta n continuare clasificarea propus de ctre aceti autori.

2.2.1. Clasificarea Sistemelor Multi-Agent (MAS)

Clasificarea Sistemelor Multi-Agent se afl n strns legtur cu agenii care
compun sistemul, motiv pentru care (Fulbright & Stephens, 1994) prezint modelarea
fiecrui agent n parte prin prisma a patru mulimi disjuncte:
o muime a datelor stocate, numit D
mulimea starilor externe, specifice mediului, notat S
o mulime format din partiii ale lui S, notat T, care reprezint percepiile
fiecrui agent
4

mulimea aciunilor posibile, numit A

n plus, agenii dispun i de urmtoarele patru operaii, definite ca produs

cartezian astfel:
percepe: S T evidenieaz abilitatea finit a agentului de a scana mediul
infer: D x T D reprezint abilitatea cognitiv
selecteaz: D x T A permite agentului s aleag aciunea potrivit
acioneaz: A x S S reprezint abilitatea agentului de a aciona asupra
mediului
Fiecare agent opereaz i actualizeaz
aceste patru mulimi n momentul executrii.
Dac considerm doi ageni care lucreaz n
acelai mediu, ei vor mpri S, dar vor avea
mulimile T, D i A proprii. Acest tip de sistem
poarta numele de Sistem multi-agent de tip 1
(Figura 2.1). Operaia de mprire a unei
mulimi poart numele de cuplare.

Figur 2.1. Ageni mprind acelai mediu

(Fullbright & Stephens, 2006)

De menionat este faptul c toate sistemele existente n natur sunt sisteme multiagent de tip 1 (Fulbright & Stephens, 1994).
Folosind operaia de cuplare, putem realiza
o clasificare pertinent a sistemelor multi-agent
mprind i mulimile individuale, evidenind
astfel opt tipuri distincte de sisteme prezentate n
Figura 2.2.
Aadar, indentificm urmtoarele tipuri de
Sisteme Multi-Agent:
cu ageni autonomi ( tip 1 )
cu ageni cuplai perceptual ( tip 2 )
cu ageni cu inferen cuplat ( tip 3 )
cu ageni cognitiv-distribuii ( tip 4 )
cu ageni cognitiv-cuplai ( tip 5 )
cu ageni cu inferena distribuita ( tip 6 )
cu ageni cu percepia distribuit ( tip 7 )
cu un singur agent ( tip 8 )
Clasificarea rezultat permite gruparea
tipurilor rezultate n clase distincte de sisteme
multi-agent, fiecare clas evideniind metodologia
principal dup care se face separarea sistemelor.
5

Figur 2.2. Tipuri de cuplri posibile

(Fullbright & Stephens, 2006)

2.2.1.1. Clasificarea pe clase

Excluznd cazurile extreme, anume tipul 1 i tipul 8, n funcie de poziia n
care apare mulimea A (intern sau extern), putem distinge dou mari clase de
sisteme multi-agent, prezentate n Figura 2.3:
clasa Cuplat de Sisteme Multi-Agent, din care fac parte tipurile 2, 3 i 5. n
aceast clas agenii conin intern mulimea A. Specific acestei clase este faptul
c agenii pot aciona n mod independent unii fa de ceilali.
clasa Distribuit de Sisteme Multi-Agent, constituit din tipurile 4, 6 i 7 n
care mulimea A este mprit de ctre toi agenii i, drept urmare, acetia nu
pot aciona n mod independent, ci doar colectiv.

Figur 2.3. Clasa Cuplat vs. Clasa Distribuit a Sistemelor Multi-Agent

(Fullbright & Stephens, 2006)

De asemenea, mprind clasele n centralizate i descentralizate obinem

aceiai aranjare:
clasa de Control Descentralizat, care cuprinde tipurile 2,3 i 5 ( chiar i tipul 1)
i nglobeaz Clasa Cuplat
clasa de Control Centralizat format din tipurile 4, 6 i 7 (chiar i tipul 8) i
cuprinde Clasa Distribuit

2.2.1.2. Clasificarea bazat pe Inferen

Clasificarea bazat pe Inferen se axeaz pe poziionarea mulimii D i,
implicit, a funciei infer, mprind Sistemele Multi-Agent astfel:
SMA cu ageni neinfereniali, care realizeaz operaia de cuplare prin prisma
mulimii D, i care cuprinde tipurile 3, 5 i 7
SMA cu ageni infereniali, cu funcie de inferen proprie, incluznd tipurile
1,2, 4, 6 i 8
2.2.1.3. Clasificarea bazat pe Percepie
Urmrind n schimb localizarea funciei percepie i a matricei T, se obine
clasificarea bazat pe Percepie, ilustrat n Figura 2.4.

Figur 2.4. Clasificarea bazat a Sistemelor Multi-Agent

(Fullbright & Stephens, 2006)

Practic, aceast clasificare evidenieaz tipurile care folosesc n mod individual

sau realizeaz operaia de cuplare prin matricea de percepii T.
7

2.3. Exemple de utilizare a Sistemelor Multi-Agent

Sistemele Multi-Agent sunt din ce n ce mai folosite, nu doar pentru a simula
i testa un raionament ori o soluie pentru infrastructuri, ci i pentru a oferi o soluie
complet automatizat i capabil s preia o responsabilitate din ce n ce mai mare.
Acest lucru este posibil datorit puterii acestor sisteme de a mpri o problem sau
cerin i de a-i facilita rezolvarea prin intermediul mai multor ageni, folosind o
inteligen distribuit pentru a realiza o soluie colectiv.
Soluia descris n (Remagnino et al, 2004) reuete s fie din ce n ce mai
convenabil datorit att tehnologiei deja existente, ct i a tehnologiei n curs de
dezvoltare n ceea ce privete camerele de supraveghere. n locul unui sistem pur
centralizat n care camerele doar furnizeaz datele, iar rolul de a extrage informaia
este ndeplinit de ctre supervizor, se propune transferul rolului de a extrage
informaia util din date de la supervizor la sisteme de calcul responsabile pentru un
grup de camere sau chiar incluznd aceast operaie n camerele inteligente. Astfel,
supervizorul este liber s interpreteze informaia deja prelucrat i s gestioneze mai
bine i mult mai rapid situaiile ce necesit intervenia sistemului. n plus, utilizarea
sistemului multi-agent propus ofera multe avantaje cheie:
se obine un grad nalt de autonomie
sistemul automat de supraveghere este mai flexibil datorit descentralizrii i
capt rezisten la eventuale probleme hardware sau software
sistemul este adaptiv datorit antrenrii camerelor-agent i nu mai este
dependent de luminozitatea ambiental sau condiiile meteo
Cea mai frecvent utilizare a sistemelor multi-agent este aceea de a simula
comportamentul mediilor foarte dinamice, precum ntlnim n (Nguyen et al, 2012).
Se propune o arhitectur multi-agent cu componente spaial-temporare pentru
simularea transportului urban modern care se adreseaz n mod direct nevoilor
organizatorice. Aceast arhitectur este corelat cu datele statistice reale ale oraului
La Rochelle i, astfel, realizeaz un prototip al micrii populaiei care este folosit
pentru identificarea posibilelor mbuntiri sau modificri ce pot fi aduse oraului.
Utilizarea acestor sisteme nu este restricionat la nivel mezo sau macroscopic,
ci poate servi i la nivel microscopic sau local. (Cabrera et al, 2011) descrie un
asemenea scenariu i realizeaz optimizarea departamentelor de urgen din cadrul
spitalelor prin utilizarea unui model orientat agent pentru generarea unui sistem
decizional responsabil de funcionarea acestor departamente. Totodat se urmrete
gsirea unei configuraii optime care include doctori, asistente medicale cu rolul de a
tria urgenele i personal administrativ. Scopul este fie minimizarea timpului de
ateptare al pacienilor, fie maximizarea fluxului de gestiune al urgenelor.

3. Sisteme Multi-Agent utilizate n managementul

situaiilor de urgen

3.1. Prezentarea arhitecturii CityScape

Managementul situaiilor de urgen ntr-un mod eficient presupune
realizarea unei infrastructuri capabile s acioneze att local, ct i la nivel mezo sau
macroscopic. Acest fapt recomand utilizarea arhitecturii CitySCAPE deoarece aceasta
este modular i prezint o structur ierarhic care implementeaz un caracter
descentralizat la nivelurile inferioare i, totodat, componente centralizate pentru
nivelurile superioare (Ptracu & Drgoicea, 2013).
Arhitectura CitySCAPE este constituit din dou sisteme interconectate i
interdependente (Figura 3.1):
inSCAPE sau Integrated Networked CitySCAPE
eSCAPE sau Emergent CitySCAPE

Figur 3.1. Arhitectura CitySCAPE la nivel macroscopic

(Ptracu & Drgoicea, 2013)

CitySCAPE funcioneaz asemenea unui organism viu, unde peste un suport de tip
schelet (inSCAPE) se plaseaz organele (eSCAPE) i sisteme nervoase (reele de
comunicaie).
(Ptracu & Drgoicea, 2013)

3.1.1. inSCAPE
Responsabil pentru integrarea i interconectarea dispozitivelor i a serviciilor,
inSCAPE asigur integritatea structural a arhitecturii realiznd interconectarea pe
vertical ntre subsisteme (Figura 3.2 stnga), i, totodata, integrarea pe orizontal
(Figura 3.2 dreapta).
9

Figur 3.2. Interconectarea vertical (stnga) i Integrarea orizontal (dreapta)

(Ptracu & Drgoicea, 2013)

3.1.2. eSCAPE
eSCAPE este format din multiple celule i esuturi, mpreun cu relaile dintre
acestea. Este constituit din patru tipuri de esuturi, fiecare responsabil de o singur
funcie a sistemului de siguran (Figura 3.3):
protocoale ale sistemelor critice
intervenia echipajelor de urgen
avertizri i controlul panicii
controlul traficului

Figur 3.3. Structura eSCAPE

(Ptracu & Drgoicea, 2013)

Fiecare celul < . > = {Dc, DP, DA, Ucomm} este format dintr-o mulime de
dispozitive de control (Dc), dispozitive de percepie (DP), dispozitive de acionare
(DA) i o unitate de comunicaie (Ucomm). Aceste celule vor fi implementate prin
intermediul Sistemelor Multi-Agent formnd un mediu activ de simulare i testare.
Mai multe n celule de acelai tip pot forma un esut << . >> = { < . >i | i=1,n} (Ptracu
& Drgoicea, 2013).
10

3.2. Formularea problemei

Lucrarea de fa urmrete implementarea protocoalelor sistemelor critice prin
intermediul unui sistem multi-agent folosind arhitectura CitySCAPE. Datorit
strnsei legturi dintre esuturile acestei arhitecturi, modelul va ngloba i o parte din
esutul responsabil pentru avertizri i controlul panicii, reflectat prin intermediul
unei interfee grafice de monitorizare care urmrete att strile de funcionare a
sistemelor critice modelate, ct i evenimentele sau hazardele la care este supus
fiecare structur n parte.

3.2.1. esutul Protocoale sisteme critice

Conform modelului prezentat n (Ptracu & Drgoicea, 2013), acest esut este
format din celule de tipul Protcoale de Urgen pentru sisteme Critice, <PUC> = {DC,
DP, DA, Ucomm} pentru care DC conine protocoalele specifice zonei n care celulele sunt
implementate, DP este constituit din ageni pentru percepie ce culeg informaii din
zonele de interes, DA reprezint agenii care acioneaz i implementeaz
protocoalele. Totalitatea celulelor provenite dintr-o singur zon formeaz
submuimea esutului <<PUC>> responsabil exclusiv pentru zona respectiv.
n cadrul aplicaiei dezvoltate, mai multe asemenea celule de tip <PUC> au
fost implementate. Exist, aadar, o mulime de asemenea celule pentru fiecare
sistem critic existent n modelul lumii generat de aplicaie, ct i o celul pentru
ntreaga zon, responsabil pentru evenimente seismice. De exemplu, n momentul
n care este detectat un cutremur, aceasta va decide dac oprete sau nu funcionarea
fiecrui sistem critic n parte i, totodat, dac ntrerupe traficul feroviar sau rutier.
De asemenea, aceast celul <PUC> simuleaz i comportamentul pietonilor,
oprindu-i n cazul unui cutremur perceptibil, ce depete trei-patru grade pe scara
Richter.

3.2.2. esutul Avertizri i controlul panicii

Datorit stnsei legturi dintre aceste dou esuturi, aplicaia conine
fragmente i din esutul Avertizri i controlul panicii, mai exact implementeaz o
form de avertizri prin intermediul interfeei de monitorizare. Aceast interfa
prezint starea actual a fiecrui sistem critic prin intermediul unor elemente de
afiare ce sunt modificate n funcie de percepiile agenilor de tip senzor existeni.
Aceste informaii ar putea fi apoi preluate de ctre un esut complet de tip
Avertizri i controlul panicii pentru a realiza managementul populaiei conform
protocolului specific zonei.

11

3.3. Soluia propus

Pentru managementul situaiilor de urgen utiliznd protocoale ale
sistemelor critice s-au realizat multiple celule responsabile pentru fiecare sistem critic
n parte. Aceste celule sunt formate din senzori i un mecanism de inferen care citete
i interpreteaz informaia provenit din partea senzorilor, dar i din elementele de
afiare aferente ce sunt schimbate n funcie de inferenele generate.
Fiecare sistem critic se poate afla fie n stare funcional, fie n stare
nefuncionala, iar esutul implementat stabilete starea sistemului prin intermediul
protocoalelor sistemelor critice, cu ajutorul agenilor de tip senzor i a mecanismului de
inferen. Apoi implementarea parial a esutului Avertizri i controlul panicii
preia informaia i actualizeaz elementele de afiare ataate sistemului.
Celulele esutului Protocoale sisteme critice urmresc evenimentele ce pot fi
aplicate fiecrui sistem critic n parte. Exemple de evenimente sunt: izbucnirea unui
incendiu, nregistrarea unui cutremur, lansarea unei ameninri teroriste,
desfurarea unui jaf sau ntreruperea curentului electric. n general aceste valori
sunt booleene, putnd exprima doar o valoare de adevr, ns celulele implementate
pentru evenimente seismice necesit citirea unei intensiti, nu doar a unei stri. n
consecin, aplicaia a realizat un model flexibil pentru celulele esutului care permite
modelarea att a cutremurelor, ct i a evenimentelor de tip booleean oferind
senzorilor o valoare citit sau nregistrat care reflect starea actual, dar i a unei
valori de prag care, odat atins, activeaz alerta. Mai mult, modelul dezvoltat nu
este restrns doar la aceste tipuri de evenimente, ci permite adugarea cu uurin a
altora prin simpla adugare n cadrul mecanismului de inferen i a senzorilor,
respectiv a elementelor de afiare aferente.
Modelul lumii este constituit din cldiri sau structuri generalizate care
dobndesc sau nu diverse funcionaliti, astfel devenind gri, centrale nucleare,
hidrocentrale, aeroporturi sau spitale. n mod implicit n jurul fiecrei cldiri se poate
seta un perimetru izolat pentru a separa populaia de forele de intervenie cu
ajutorul activrii unei alarme. Acest lucru seste posibil deoarece fiecare cldire este
refereniat n mod unic cu ajutorul unui cmp identificator.
O cldire armat sau cu alarma activ va trece n mod automat n starea
nefuncional i va fi izolat. Decizia de a izola sau nu o cldire este stabilit de ctre
esutul Protocoale sisteme critice, pe cnd izolarea cldirii n caz de alarm intr n
atribuiile esutului de avertizri, demonstrnd astfel strnsa legtur dintre aceste
dou esuturi distincte. Mai departe, un esut de tip Intervenie echipaje de urgen
ar putea procesa cererea, iar un esut de tip Controlul traficului ar fi responsabil

12

pentru gestiunea traficului n scopul minimizrii timpului de intervenie al acestor

echipaje. Aceste esuturi nu fac obiectul prezentei lucrrii.
Pentru realizarea celulelor s-au modelat ageni de tip senzor i element de
afiare, fiecare senzor fiind legat n mod implicit de un element de afiare. ns
corespondena nu este bilateral, elementele de afiare care evidenieaz starea alarmei
sau starea de funcionare nefiind, n general, conectate la un senzor.
Mai mult, am implementat ageni inteligeni pentru a simula att
comportamentul traficului rutier, ct i feroviar sau aerian. De asemenea modelul
este prevzut cu ageni inteligeni de tip pietoni care se depleazeaz pe trotuare. n
momentul n care unei cldiri i este stabilit starea de armat se creeaz un
perimetru n jurul acesteia din care agenii deja prezeni vor fugi, iar restul agenilor
l vor evita. Pentru a realiza o simulare fidel, n momentul n care un pieton ajunge
n faa unui perimetru armat, el se va opri pentru a simula formarea mulimilor, iar
pietonii deja aflai n permetru vor fi nlocuii de fore de intervenie.
Agenii inteligeni sunt reactivi la mediul n care se afl, interacionnd cu
modelul lumii prin scanri periodice. Aadar, autovehiculele tiu ntotdeauna care
sunt direciile posibile i sigure n care se pot deplasa, trenurile tiu cnd ajung la
captul inei i staioneaz, pietonii nu ies niciodat de pe trotuar, iar avioanele caut
n permanen un aeroport funcional care s le faciliteze aterizarea.
De asemenea, mecanismul de inferen responsabil pentru managementul
sistemelor critice este un agent inteligent care conlucreaz cu agenii senzor i agenii
element de afiare pentru a implementa protocoalele sistemelor critice i a ilustra starea
curent a sistemului urmrit.
Aplicaia dezvoltat permite aplicarea de evenimente asupra uneia sau a
tuturor sistemelor critice ori a cldirilor. n mod asemntor, se pot arma cldirile i
astfel se poate simula evacuarea i punerea n carantin a oraului. Este de menionat
faptul c trenurile se opresc dac ina pe care se depleazeaz face parte din sistemul
critic armat. Astfel, n cazul unui eveniment care a determinat scoaterea din
funcionare a aeroportului, avioanele nu vor mai ateriza, iar trenurile aferente
aeroportului se vor opri, iar scoaterea din funcionare a grii periferice va opri toate
trenurile prezente n model.
Totodat se poate simula prbuirea avionului prin intermediul interfeei
grafice, indiferent de locul n care acesta se afl. n momentul activrii acestui
eveniment, avionul va intra n vrie pe partea stng i se va prbui. Dac zona
catastrofei va fi o cldire, aceasta va determina apariia unui incendiu i i se va activa
perimetrul, altfel vom avea drep consecine stricarea i blocarea oselei sau
distrugerea copacilor afectai.
13

4. Studiu de caz

4.1. Descrierea aplicaiei

Aplicaia realizat genereaz un model al lumii n care plaseaz ageni
inteligeni mobili sau fici i urmrete simularea diverselor scenarii de urgen prin
adugarea de evenimente pentru sistemele critice modelate. Agenii mobili sunt de
tip pieton, main, autobuz, camion, tren sau avion i modeleaz fluxul traficului
rutier, feroviar i aerian, pe cnd agenii fici reprezint sistemele critice, cldirile,
drumurile rutiere, trotuarele, lacurile, rurile, inele de tren, pdurea, dar i
elementele de afiare prin prisma crora s-a realizat interfaa grafic de tip centru de
monitorizare.
Implementarea acestui sistem multi-agent s-a realizat n platforma de
programare orientat agent NetLOGO care ne pune la dispoziie patru tipuri
distincte de ageni prezentate n (Wilensky, 1999):
turtles care reprezint agenii inteligeni mobili ce se deplazeaz n lumea
creat virtual i ndeplinesc diferite roluri sau funcionaliti
patch-uri ce simbolizeaz agenii statici din care este format lumea virtual.
Practic, acest tip de ageni sunt fici n sistemul de axe cartezian pe care
NetLOGO l folosete ca sistem de referin att 2D, ct i 3D
link-uri pentru evidenierea legturilor dintre agenii inteligeni
observer sau agentul inteligent ce urmrete evoluia lumii i a agenilor
existeni, ndeplinind rolul de supervizor n cadrul acestei platforme
Modelarea lumii ncepe prin intermediul patch-urilor, apoi prin adugarea
agenilor fici ce au de ndeplinit roluri specifice zonei n care sunt amplasai i, n
cele din urm, a agenilor mobili care implementeaz un anume comportament. Mai
mult, exist o legtur foarte strns ntre un agent de tip turtle i patch-ul pe care se
afl, acestea avnd acces direct asupra variabilelor locale declarate, att pentru citire,
ct i pentru scriere. n plus, orice patch sau orice turtle poate opera cu alte patch-uri
sau turtles, ns nu pot aduga n mod direct ali ageni. Doar observer-ul sau
supervizorul include i aceast funcionalitate (Wilensky, 1999).
Totodat, NetLOGO pune la dispoziia utilizatorului interfee de intrare sau
ieire precum butoane, slider-e, liste de selecie, elemente pentru plotare sau
monitorizarea unei variabile sau valorii returnate de un reporter i i permite astfel
acestuia dezvoltarea unei aplicaii flexibile i complete prin care se poate opera uor
cu lumea virtual creat.
14

Modelul pe care l vom descrie i utiliza n aceast lucrare este prezentat n

Figura 4.1.

Figur 4.1. Modelul implementa utiliznd platforma de programare NetLOGO

Pentru realizarea modelului, dar i pentru a permite un grad nalt de

flexibilitate n etapa de generare am dezvoltat un pachet de programe numit Toolkit
care utilizeaz i prezint funcionaliti izolate ce sunt apoi incluse n aplicaia
dezvoltat. Acest lucru permite studierea ntr-un mediu perfect controlat i izolat a
diverselor funcionaliti sau proceduri necesare realizrii lumii prezentate. n
continuare vom prezenta aplicaiile acestui Toolkit.

4.2. Prezentarea Toolkit-ului Custom City Builder

Toolkit-ul Custom City Builder trateaz ase funcionaliti implementate i i
permite utilizatorului s le neleag i s le modifice sau mbunteasc fr a fi
nevoie s le integreze ntr-un sistem complex. Fiecare program de test este construit
pe baza unui model standard propus n (Wilensky, 1999) ce conine n mod automat
dou proceduri:
procedura setup care realizeaz operaile necesare crerii lumii sau a mediului
de test
procedura go care conine instruciunile agenilor inteligeni prezeni n model

15

Acest model este respectat chiar i n cazuri n care agenii nu au de simulat un

comportament inteligent anume. n astfel de cazuri, funcia go doar actualizeaz
contorul tick-urilor.
Tick-urile reprezint o metod de a numra ciclurile de operare, att n cazul
agenilor mobili, ct i n cazul celor fici. Pentru a realiza aceast eviden,
procedurii de setup i se adaug instruciunea reset-ticks care aduce contorul la 0, iar n
cadrul procedurii go se adaug instruciunea tick. Acest model propus de (Wilensky,
1999) este recomandat deoarece i permite utilizatorului s separe instruciunile de
generare de cele de rulare sau simulare. Mai mult, aceste valori sunt folosite pentru
actualizarea plotrilor. Astfel, n momentul n care valoarea din contorul ticks se
incrementat, plotrile sunt actualizate. Pasul fiecrei incrementri este salvat n
variabila global, implicit, tick-advance care poate fi setat doar la valori pozitive,
att ntregi, ct i reale. Alegerea acestei valori se face n funcie de fiecare sistem de
multi-agent implementat n parte i se reflect n principal n rezultatele plotrii.
Funcionalitatea aceasta este justificat deoarece NetLOGO permite salvarea
rezultatelor culese prin intermediul plotrilor n fisiere de extensie .csv ce pot fi apoi
folosite ca fiind date de intrare pentru modele dezvoltate cu ajutorul altor platforme
de dezvoltare. Practic, tick-advance simbolizeaz perioada de eantionare la care se
nregistreaz valorile.
Datorit acestui fapt, exist o diferen clar ntre cicluri de operare i ticks. n
mod natural, n cadrul unui cilcu de operare se execut o singur dat toate
instruciunile specificate n procedura repetitiv go, pe cnd un tick nu este
restricionat la un singur ciclu de operare, n funcie de setarea pentru tick-advance.
De exemplu, unui tick i poate corespunde fie un singur ciclu de operare n mod
implicit, fie 2 cicluri de operare dac se alege valoarea 0.5 pentru variabila tickadvance sau se poate implementa ca un ciclu de operare s conin 2 tick-uri alegnduse valoarea 2 pentru tick-advance.

Aplicaiile ce aparin acestui toolkit testeaz urmtoarele funcionaliti:

generarea unui cartier de cldiri cu drumuri i trotuare aferente unei structuri
matriceale
alocarea unui identificator unic fiecrei cldiri din cartierul generat
setarea unui perimetru de siguran n jurul unei cldiri, pe baza
identificatorlui specificat
determinarea unei viitoare poziii pe baza unei formule proprii i testarea
acesteia pentru direcii aleatoare sau nu, dar i vizualizarea efectului
procedurii in-cone desennd zona selectat i evidenierea direciilor care
formeaz multiplii de unghiuri drepte cu orientarea curent
modelarea deplasrii unui agent pe un drum orizontal i redresarea acestuia
dup perturbare prin translatare n lateral, specificnd totodat viteza.
adugarea de ageni ntr-o lume cu restricie de populaie de tip insul i
afiarea unui mesaj de eroare la eventuala depire a limitei de populaie.
16

4.2.1. Generarea unui cartier de cldiri i pavarea drumurilor aferente

Generarea cartierului de cldiri cu construirea drumurilor i a trotuarelor
aferente unei structuri matriceale este prezentat n fiierul generare_cartier.nlogo
din cadrul toolkit-ului i permite modificarea facil a parametrilor disponibili prin
intermediul elementelor de interfa de tip slider prevzute n platforma de
programare NetLOGO. Lista complet a acestor parametri este:
start-x ce simbolizeaz poziia pe axa orizontal din care se ncepe construirea
primei cldiri
start-y care marcheaz poziia pe axa vertical pentru inceperea construirii
primei cldiri. De menionat este faptul c acest set de coordonate (start-x,
start-y) marcheaz colul din dreapta-sus al primei cldiri construite.
Construirea cldirilor ncepe tot din partea dreapta-sus a cartierului, linie cu
linie, de la dreapta la stnga
size-x simbolizeaz numrul de cldiri ce vor fi construite pe orizontala sau
numrul de coloane din din matricea de cldiri
size-y, n mod analog, marcheaz numrul de linii din matricea de cldiri
marime-cldiri reprezint latura cldirilor, ce vor fi ptrate
Figura 4.2 arat un exemplu de generare a unui cartier cu numr maxim de
cldiri de dimensiune minim, pornind din colul din dreapta-sus al interfeei.

Figur 4.2. Generarea unui cartier cu numr maxim de cldiri de dimensiune minim

17

Algoritmul apeleaz proceduri distincte; una pentru adugarea cldirilor i o a

doua pentru construirea drumurilor sau a trotuarelor. Datorit faptului c n
modelul lumii s-au considerat trotuare de lime 1, construcia acestora s-a realizat
printr-o selecie de patch-uri pentru a micora timpul de execuie a procedurii setup.

4.2.2. Adugarea identificatorului unic pentru fiecare cldire n parte

Procedurile prezentate n alocare_identificator.nlogo completeaz generarea
de cartiere prin identificarea n mod unic a fiecrei cldiri n parte. Figura 4.3
exemplific generarea unui astfel de cartier i, n linia de comand dar i n textul
ajuttor, modificarea culorii unei singure cldiri.

Figur 4.3. Generarea unui cartier cu cldiri identificate n mod unic

Procedura de generare a cldirilor adaug fiecare cldire ntr-o list denumit

generic cldiri ce va conine toate cldirile. NetLOGO indexeaz aceste liste de la 0,
motiv pentru care la nceputul procedurii se determin numrul de elemente din list
ce va fi folosit ca identificator unic. Astfel se leag identificatorul de indexul listei i
se asigur c cldirea n are identificatorul n pentru eliminarea eventualelor greeli.
Un exemplu de instruciune care referenieaz o anume cldire, dar i efectul
rezultat dup executia acesteia este ilustrat n Figura 4.4.

18

Figur 4.4. Modificarea cldirii cu identificator 28 prin setarea culorii roie

4.2.3. Setarea perimetrului restricionat n jurul unei cldiri

Pentru simularea unui perimetru restricionat, s-a adugat variabila booleean
safe, specific patch-urilor. Aceasta are rolul de a separa zonele sigure de cele nesigure
i va fi folosit de ctre agenii inteligeni pentru a le resticiona accesul. Agenii
proveniti dintr-o zon sigur nu vor intra n perimetrul nesigur. Mai mult, cei deja
aflai n perimetrul setat fie vor iei din acesta (specific agenilor inteligeni de tip
rutier), fie vor fi nlocuii de echipaje de intervenie (specific agenilor inteligeni de
tip pieton). Setarea perimetrului restricionat n jurul unei cldiri i evidenierea
acestuia este exemplificat n Figura 4.5.

Figur 4.5. Exemplu de setare a perimetrului restrictionat pentru cladirea cu identificatorul 12

19

4.2.4. Marcarea poziiei viitoare a unui agent i testarea in-cone

Rolul modelului pozitie_viitoare_agent.nlogo este de a ajuta utilizatorul s
testeze formule implementate n cod pentru determinarea unei viitoare poziii sau a
unei poziii de interes. Spre exemplu, a fost folosit pentru testarea formulei de
determinare a patch-ului pentru executarea virajului la stnga al agenilor inteligeni
de tip rutier. De asemenea, testarea i nelegerea instruciunii in-cone este util
pentru agenii care nu sunt restricionai la un drum exact, spre exemplu agenii
inteligeni de tip avion. Instruciunea in-cone ar putea fi folosit, aadar, pentru
implementarea radarului necesar evitrii accidentelor aeriene. Figura 4.6 ofer un
exemplu de testare pentru aceast funcie. Ultima funcionalitate, test-directii, este pur
vizual. Aceasta evidenieaz patch-urile care formeaz o intersecie de drumuri cu
sens unic, de o band, n poziia agentului.

Figur 4.6. Testarea instruciunii in-cone prin intermediul modelului realizat n toolkit

20

De asemenea, Figura 4.7 ilustreaz determinarea poziiei viitoare, rezultate n

urma virrii la stnga a unui agent inteligent de tip rutier, evidenind n acelai timp
i drumurile adiacente lui. Se remarc faptul c direcia de deplasare a agentului s-a
schimbat datorit activrii switch-ului random-heading. n cazul activrii acestuia,
agentul va alege un punct cardinal aleatoriu care va servi ca orientare. Modelul lumii
ce va fi realizat cu ajutorul acestui toolkit nu conine dect drumuri verticale i
orizontale, motiv pentru care s-au ales ca orientri posibile punctele cardinale n
cadrul acestui model de test.

Figur 4.7. Afiarea poziiei rezultate n urma realizrii virajului la stnga pentru un agent orientat spre EST

Dei este un model de test cu complexitate i numr de linii de cod reduse,

acesta permite utilizatorului s ncerce n mod eficient orice formul pentru
determinarea patch-ului de interes, ntr-un mediu izolat, ideal testrii. Pentru
determinarea acestui patch se folosete procedura patch-at-heading-and-distance
explicat n (Wilensky, 1999). Modificarea formulei de determinare presupune
modificarea parametrilor trimii acestei proceduri.

21

4.2.5. Modelarea deplasrii i a redresrii unui agent mobil

Aplicaia de test redresare_deplasare_agent.nlogo propune o soluie pentru
modelarea virrii cu vitez variabila a agenilor mobili. Aceast problem apare n
momentul n care agenii mobili pot accelera i decelera, ori pot avea viteze mai mari
dect 1. Pentru un agent, viteza 1 reprezint avansul n urma unei executri a
procedurii forward. Practic, aceast procedur deplaseaz agentul cu numrul
specificat de patch-uri, acest numr putnd fi natural, real sau chiar i negativ. n
cazul agenilor inteligeni de tip rutier care sunt capabili s accelereze i decelereze,
virarea introduce deplasarea de pe poziia central a drumului. Mai multe deplasri
de acest tip pot determina agentul s ajung n poziii nedorite, motiv pentru care am
decis s tratez aceast problem. Soluia prezentat este destinat modelrii unui
trafic rutier cu viteze variabile, capabil s accelereze i s frneze. Modelul lumii
realizat n aplicaia dezvoltat pentru aceast lucrare are implementate aspecte
precum vitez maxim, accelerare, decelerare, distan de frnare, distane ntre
ageni, indice de virare setate pentru fiecare tip de agent inteligent mobil existent
(oameni, maini, camioane, autobuze, trenuri i avioane), ns modelarea acestor
micri complexe nu face obiectul lucrrii i au fost folosite n scopul unor viitoare
mbuntiri. De fapt, modelul actual folosete vitezele setate, ns acestea au
valoarea constant 1 deoarece miscrile curbilinii, distanele dintre ageni,
acceleraile, frnarea i distanele de frnare nu au fost implementate. Rolul acestei
aplicaii de test este de a oferi o soluie i o nelegere a acestei soluii n scopul unei
viitoare implementri.
Figura 4.8 prezint interfaa generat de aplicaia test. Se remarc faptul c
agentul pornete dintr-o poziie translatat.

Figur 4.8. Interfaa aplicaiei de test pentru redresarea direciei de deplasare a unui agent mobil

22

Se observ faptul c viteza de deplasare este variabil pentru a-i permite

utilizatorului s identifice etapele prin care se manifest redresarea, dar i pentru a
testa n ce distan agentul inteligent revine n poziia central n funcie de avansul
setat.
n momentul n care se aplic o perturbaie asupra poziiei agentului, acesta
este translatat n mod aleatoriu fie n stnga, fie n dreapta, cu o distan de 0.4 patchuri. S-a ales aceast valoare deoarece alegerea unei valori egale cu 0.5 patch-uri
introduce o ambiguitate n ceea ce privete alegerea poziiei de redresare. Pentru
valori mai mari se alege patch-ul de lng drum. Acest inconvenient se poate corecta
prin setarea unei variabile interne agentului inteligent care s rein poziia dorit, de
exemplu urmtoarea poziie din drum sau, n cazul implementrii acestei soluii,
poziia la care agentul dorete s ajung dup virare.

Figur 4.9. Poziia unui agent mobil n urma redresrii

De asemenea, poziia la care agentul dorete s ajung este evideniat prin

culoarea roie. Astfel utilizatorului i este descris ntregul proces de redresare i
poate urmri n mod exact etapele prin care acesta se manifest i dac apare
fenomenul de depire, n care agentul iese de pe drumul stabilit datorit vitezei
prea mari ori a translatrii prea puternice. Datorit acestui fapt, aplicaia de test
permite simularea mai multor scenarii pentru a determina dac i ct este nevoie ca
agentul mobil s ncetineasc n momentul efecturii unui viraj, pentru ca acesta s
nu ias de pe banda dorit. Un exemplu de redresare este oferit n Figura 4.9.
Dei aceast soluie nu este implementat n modelul lumii realizat n cadrul
lucrrii actuale, ofer o utilitate i o modalitate de test ce poate servi multor modele
realizate n NetLOGO, motiv pentru care am decis s includ i s pstrez modelul de
test n toolkit.

23

4.2.6. Adugarea de ageni ntr-un model cu restricie pe populaie

Agenii din modelul lumii realizat sunt restricionai la o anume poziionare.
Spre exemplu, mainile sunt adugate doar pe drumuri iar pietonii doar pe trotuare,
motiv pentru care toolkit-ul include aplicaia de test pozitii_disponibile_agenti.nlogo,
al crei rol este acela de a-i oferi utilizatorului o soluie pentru adugarea de ageni
ntr-un mediu cu restricie a poziiilor disponibile.
Modelul lumii generat de aplicaia test este de tip insul i conine pmnt pe
care agenii pot sta n partea dreapt-sus i ap n rest. Dup realizarea acestui model
se adaug cte 30 de ageni pn la detectarea locurilor insuficiente. Figura 4.10
prezint starea n care se afl modelul dup adugarea a 60 de ageni.

Figur 4.10. Modelul test n urma adugrii a 60 de ageni

Se poate observa cum fiecare poziie din insul poate fi ocupat de un singur
agent, iar dispunerea acestora este n mod aleatoriu. De asemenea, orientarea
agenilor rmne la valoarea aleatorie stabilit n momentul adugrii. De fapt, dup
ce un agent este creat, acesta este mutat pe un patch de tip pmnt care nu conine
nici un agent. Pentru aceast funcionalitate se folosesc procedurile count, move-to i
turtles-on mpreun cu filtrarea agenilor prin operatorul with (Wilensky, 1999).
24

n momentul n care pe insula nu mai este loc pentru nc 30 de ageni

adugarea este anulat, iar utilizatorul primete un mesaj infomativ de tip usermessage, dup cum se poate observa n Figura 4.11.

Figur 4.11. Afiarea mesajului de eroare la depirea limitei insulei

Adiional, modelul de test conine o procedur infinit (Wilensky, 1999)

numit testeaza-patch-ahead pentru a exemplifica utilizarea agenilor prin prisma
altor ageni inteligeni. Procedura alege un agent n mod aleatoriu i l coloreaz
verde, iar apoi modific agentul aflat pe patch-ul din faa agentului curent
schimbndu-i culoarea n albastru i orientndu-l spre agentul apelant (verde).
Aceast procedur minimal ofer utilizatorului un exemplu simplu, funcional i
flexibil de a gestiona agenii din interiorul altor ageni inteligeni.

25

4.3. Modelul lumii

Modelul lumii este realizat prin intermediul agenilor n NetLOGO. Modelul
actual este constituit din ageni de tip fix numii patch-uri ce sunt grupai si formeaz
cldiri, drumuri, trotuare, zone de iarb, zona dedicat interfeei i elemente de
afiare. Peste acest model se plaseaz agenii inteligeni de tip pieton, main,
autobuz, camion, tren (formai din locomotive, respectiv vagoane) i avion. n acest
subcapitol vom drescrie realizarea modelului lumii prin aceti ageni.

4.3.1. Sistemele critice

Sistemele critice existente n aplicaia dezvoltat sunt:

aeroportul
gara din afara oraului
gara din ora
spitalul
centrala nuclear
hidrocentrala

Fiecare sistem critic este format dintr-un set de ageni de tip patch care au
acelai tip i acelai identificator n aa fel nct s lucreze ca un tot unitar. Aceste
sisteme sunt salvate n lista cladiri-monitorizate. De asemenea, orice sistem critic este
prevzut cu o mulime de senzori ce verific diverse evenimente sau stri ce pot
caracteriza sistemul. n cadrul esutului Protocoale sisteme critice realizat, senzorii
reprezint elemente ale mulimii DP. Mecanismul de inferen folosit n procedura
actualizeaza-monitorizarea verific senzorii fiecrui element din lista sistemelor critice
i pe baza acestor verificri decide dac se trece n starea de funcionare sau
nefuncionare i dac se activeaz alarma. Acesta reprezint componentele mulimii
DC din cadrul celulelor <PUC> implementate. Mecanismul este responsabil i pentru
actualizarea elementelor de afiare ce prezint starea curent a acestor sisteme.
Mulimea DA este constituit din elementele de afiare i metodele prin care deciziile
inferenei sunt reflectate n modelul lumii.
4.3.1.1. Aeroportul
Aeroportul (Figura 4.12) este primul sistem critic
adugat att n lista cldirilor afiate, ct i n lista
cldirilor, avnd identificatorul unic 0 i tipul setat
aeroport. Situat n partea stng-sus a modelului
lumii, acesta este conine un grup de patch-uri care
formeaz pista de aterizare pentru avioane i un grup
care realizeaz iluminarea pistei. De asemenea, conine
Figur 4.12. Aeroportul

26

senzori pentru detectarea incendiilor, cutremurelor, a penelor de curent i a

ameninrilor teroriste. n plus, este prevzut cu dou ine de tren i un drum ce
faciliteaz transportul de pasageri.
n cazul n care aeroportul este trecut n starea nefuncional trenurile aferente
acestuia vor fi oprite pe ine, iar avioanele nu vor mai ateriza, ci vor fi redirecionate
ctre alt aeroport. Pentru a evidenia aceast redirecionare, avioanele crora nu le
este permis aterizarea sunt colorate roz. Un exemplu pentru aterizare vs.
redirecionare este ilustrat n figura 4.13.

Figur 4.13. Aeroport funcional (stnga) vs. Aeroport nefuncional (dreapta)

4.3.1.2. Gara din afara oraului

Al doilea sistem critic adugat i listat este
gara din afara oraului, prezentat n Figura 4.14.
Aceasta are identificatorul unic 1 i tipul setat gar.
Rolul ei este de a uni gara din ora cu aeroportul
pentru a permite transportul feroviar al pasagerilor
ce vor s ajung la aeroport. Conine patru ine
pentru trenuri i un drum care permite traficului
rutier s o viziteze.
Scoaterea din funcionare a acestei gri
implic oprirea tuturor trenurilor i blocarea
ntregului trafic feroviar.

Figur 4.14. Gara din afara oraului

4.3.1.3. Gara din ora

Gara din ora reprezint al treilea sistem critic
implementat i are identificatorul unic 2, tipul fiind tot de tip
gar. Aceasta este nconjurat de drumuri, trotuare i cldiri,
iar activarea alarmei determin setarea de perimetru restricionat
n ora, n jurul ei, mpreun cu oprirea trenurilor specifice.
Poziionarea acesteia este prezentat n Figura 4.15.
27

Figur 4.15. Gara din

ora

4.3.1.4. Spitalul
Spitalul nu ocup o poziie standard n cadrul modelului
lumii. La fiecare executare a procedurii setup, o cldire mare
este aleas n mod aleatoriu i devine spital, motiv pentru care
identificatorul unic este variabil, iar tipul este spital. Pentru a
putea fi identificat uor, spitalul este redesenat ca o cruce roie
peste un fundal galben, dup cum arat Figura 4.16.

Figur 4.16. Spitalul

4.3.1.5. Centrala nuclear

Centrala nuclear ocup ante-penultima
poziie n lista cldirilor, fiind situat naintea
barajului i a hidrocentralei. Tipul este setat ca fiind
centrala-nucleara, iar construirea ei este realizat
prin intermediul procedurii de adugare a unui
cartier. Practic, se adaug un cartier format dintr-o
singur cldire, de dimensiune 20 (fa de
dimensiunea 6 a cldirilor normale). Poziionarea i
aspectul centralei nucleare sunt ilustrate n figura
4.17.

Figur 4.17. Centrala nuclear

4.3.1.6. Hidrocentrala
Hidrocentrala ocup ultima poziie
din liste, fiind ultima cldire sau structur
adugat
modelului
lumii,
avnd
identificatorul unic de valoare maxim i
tipul setat hidrocentrala. n componena
ei intr i barajul, care este o structur
distinct, ns nemodelat ca fiind un
sistem critic, iar legtura cu restul
modelului lumii se face prin intermediul
unui drum adiacent. Pentru asigurarea
unui efect aspect schematic realist s-au
Figur 4.18. Hidrocentrala i barajul
modelat dou lacuri, unul de acumulare i
unul de vrsare, conectate prin intermediul unui ru ce trece prin hidrocentral. De
fapt, hidrocentrala este format din dou zone distincte, de-o parte i de alta a rului,
ce au acelai tip i identificator unic. Structura hidrocentralei este vizibil n Figura
4.18.

28

4.3.2. Ageni implicai n implementarea protocoalelor sistemelor

critice
Agenii implicai n implementarea prtocolalor de urgen pentru sistemele
critice sunt agenii de tip senzor i elementele de afiare, mpreun cu agentul
inteligent <PUC> care realizeaz mecanismul de inferen. Funionalitatea <PUC>
este ilustrat n Figura 4.19.

Figur 4.19. Funcionarea esutului <PUC>

(Ptracu & Drgoicea, 2013)

esutul <PUC> (Protocoale de Urgen pentru sisteme Critice) descris n

(Ptracu & Drgoicea, 2013) este folosit n lucrarea de fa. El este format din celule
de tip <PUC> = {DC, DP, DA, Ucomm}, Ucomm fiind implementat la nivelul platformei de
programare NetLOGO.
4.3.2.1. Agenii de percepie ai mulimii DP
Agenii care formeaz mulimea DP sunt de tip senzor. Un astfel de senzor este
exemplificat n Figura 4.20. Senzorii sunt adugai sistemelor critice pentru a urmri
o stare sau un eveniment. n mod implicit, senzorii sunt poziionai n mod aleatoriu
peste sistemul critic considerat i sunt ascuni. Afiarea sau ascunderea senzorilor se
poate realiza prin intermediul butonului arata/ascunde senzori din interfaa grafic.
29

Senzorii conin urmtorii parametrii:

id-senzor care conine identificatorul unic
pentru fiecare senzor n parte
cladire-id ce simbolizeaz identificatorul
cldirii pe care este montat
eveniment-urmarit ce are valori precum
cutremur, incendiu etc
intensitate; reflect starea curent sau
intensitatea evenimentului urmrit n
momentul actual
prag care este setat la intensitatea pentru
care senzorul se activeaz. Spre exemplu,
senzori pentru evenimente precum
incendii sau jafuri au aceast valoare
setat la 1, pe cnd cei responsabili pentru
Figur 4.20. Un element de tip senzor
cutremure conin valoarea magnitudinii pe
scara Richter la care sistemul este scos din funiune.

Culoarea unui senzor este aleas n funcie de culoarea patch-ului pe care este
amplasat, n aa fel nct acesta s poat fi observat uor n momentul n care este
setat ca fiind vizibil.
4.3.2.2. Agenii inclui n mulimea DA
Mulimea DA opereaz n mod direct cu
agenii de tip element de afiare, modificndu-le
culoarea n funcie de datele furnizate de ctre
mulimea Dp. Fiecare sistem critic are asociat o
mulime de elemente de afiare prin care animeaz
efectele deciziilor luate de ctre mecanismul de
inferen. n Figura 4.21 se arat cum interfaa
arat utilizatorului c sistemul critic Aeroport nu
mai este funcional datorit detectrii unui
cutremur ce depeste magnitudinea prag. De
asemenea, se remarc faptul c alarma nu a fost
declanat deoarece acest eveniment nu
presupune intervenia forelor speciale, spre
deosebire de un incendiu sau o ameninare
terorist.

Figur 4.21. Elementele de afiare

responsabile pentru sistemul critic
Aeroport

30

De fapt, mulimea DA este constituit din implementarea protocoalelor

sistemelor critice i nu din ageni de tip element de afiare. Mulimea opereaz cu
acetia deoarece ei reflect diferitele implementri, n funcie de evenimente.

Elemente ale mulimii DA sunt protocoale precum:

scoaterea din funcionare a unui sistem critic n momentul n care un
eveniment de interes este detectat
activarea alarmei sistemului critic i determinarea perimetrului de siguran
n jurul acesteia n momentul n care evenimentele detectate necesit aciunea
forelor de intervenie. Astfel de evenimente sunt incendiul, ameninarea
terorist sau jaful
oprirea funionrii aeroportului i a grilor n prezena cutremurelor de
magnitudine cel puin egal cu 4 grade pe scara Richter
trecerea n regim nefuncional a centralei nucleare la detectarea cutremurelor
de magnitudine mai mare sau egal cu 5.5 grade pe scara Richter
scoaterea din funcionare a hidrocentralei pentru cutremure de magnitudine 5
oprirea spitalului n timpul cutremurelor de cel puin 6 grade
oprirea trenurilor n momentul n care gara aferent este scoas din regimul
de funcionare
redirecionarea traficului aerian ctre alt aeroport n cazul nefuncionrii
aeroportului
evacuarea oraului n momentul n care se activeaz alarma pentru toate
cldirile urbane
blocarea drumului n urma prbuirii unui avion
activarea alarmei datorit incendiului rezultat n urma prbuirii avionului

n modelul realizat blocarea strzilor se realizeaz prin setarea lor ca fiind

nesigure i evidenierea prin culoarea roie. n cazul lumii reale, aceast
implementare s-are realiza prin intermediul echipajelor de poliie. Acestea ar fi
responsabile pentru setarea perimetrului i blocarea drumurilor.
4.3.2.3. Agenii de control ai mulimii DC
n componena mulimii DC intr mecanismul de inferen i baza de reguli
considerat. Mecanismul de inferen este implementat prin intermediul unei
proceduri ce acioneaz n funcie de baza de reguli implementat. Astfel, pentru
fiecare sistem critic n parte se verific informaia provenit din partea senzorilor i
se decide dac asupra sistemului critic acioneaz evenimente sau hazarde. Mai mult,
n funcie de numrul i tipul hazardelor dedectate se decide scoaterea din
funcionare a sistemului critic i, dac este cazul, activarea alarmei i setarea
perimetrului de siguran. Figura 4.22 prezint o variant n pseudocod a
mecanismului de inferen implementat n cadrul aplicaiei dezvoltate.

31

Figur 4.22. Implementarea n pseudocod a mecanismului de inferen pentru sistemele critice

4.3.3. Agenii inteligeni mobili

Modelarea comportamentului agenilor mobili existeni s-a realizat clasificarea
acestora n funcie de categoria de trafic din care fac parte. Astfel au rezultat
urmtoarele categorii:
pietoni
categoria rutier, ce conine mainile, autobuzele i camioanele
categoria feroviara pentru trenuri
categoria aerian pentru avioane
Agenii inteligeni mobili, cu excepia trenurilor, au comportamenul simulat
cu ajutorul a dou proceduri distincte:
procedura orienteaza-ageni, care orienteaz agenii inteligeni n funcie de
poziiile posibile i sigure
procedura misca-agenti care efectueaz deplasarea acestora n direcia rezultat
din procedura de orientare

32

4.3.3.1. Pietonii
Pietonii au un comportament limitat, modelul
neavnd treceri de pietoni sau semafoare. n
consecin, pietoni se deplaseaz pe trotuarele din
jurul cldirilor, schimbnd n mod aleatoriu direcia
n momentul n care urmeaz s ias de pe trotuar.
Numrul de pietoni din jurul fiecrei cldiri este
alocat aleatori, bazndu-se pe selecia patch-urilor
libere de tip trotuar. Un exemplu de dispunere a
pietonilor pe trotuarul din jurul unei cldiri este
prezentat n Figura 4.23.

Figur 4.23. Pietonii din jurul unei

cldiri

4.3.3.2. Agenii inteligeni din categoria rutier

n cazul agenilor inteligeni de tip main,
autobuz i camion a fost necesar dezvoltarea unei
proceduri de orientare mai complicate datorit
nevoii s se respecte un minimum de reguli de
circulaie. Dup adugarea pe osea, aceti ageni
sunt orientai n direcia dictat de drum printr-o
procedur special de apelat de setup. n rest,
orientarea se face pe baza scanrii patch-urilor care
marcheaz poziiile rezultate n urma ieirii din
intersecie prin deplasare nainte (galben), virare la
stnga (mov) sau virare la dreapta (roz), dup cum
sunt marcate n Figura 4.24.

Figur 4.24. Direciile verificate de

ctre agenii rutieri

Adiional acestei condiii de orientare, agenii inteligeni din categoria rutier

sunt condiionai i la naintare pentru a ntoarce n momentul n care ajung ntr-o
nfundtur. De asemenea, un agent va nainta doar dac poziia dorit este liber.
Mai mult, odat aleas direcia dorit, agenii inteligeni din categoria rutier o
pstreaz timp de dou cicluri, n cazul n care poziia este ocupat de ctre un alt
agent rutier. De menionat este faptul c mainile i schimb orientarea n funcie de
direcia de mers aleas, roile fiind pe partea trotuarelor.
Comportamentul simulat de ctre agenii inteligeni rutieri permite
modificarea modelului lumii prin adugarea sau eliminarea de drumuri fr a fi
nevoie s se intervin la nivel de agent sau intersecie. Practic, dac un drum este
sigur, acesta va fi strbtut de agenii rutieri. De asemenea, implementarea aceasta
permite simularea evacurii oraului, deoarece agenii caut drumuri sigure i astfel
ajung s caute drumurile ce ies din ora. n plus, procedura orienteaza-agenti
incorporeaz i mecanisme de decongestionare a traficului n caz de blocaj din
diverse motive, permind totodat formarea de cozi pentru evacuarea oraului.
33

4.3.3.3. Agenii inteligeni de tip tren

Agenii inteligeni de tip tren sunt organizai la nivel de ansamblu i nu la
nivel de locomotiv sau vagon, dup cum este prezentat n Figura 4.25. n momentul
adugrii trenurilor, acestea sunt formate n totalitate din vagoane. Apoi se
determin n mod automat primul, respectiv ultimul vagon al fiecrui tren iar acestea
sunt modificate n locomotive.

Figur 4.25. Trenurile care circul pe ruta Aeroport-Gar periferie, aflate n micare

Asemenea trenurilor din lumea real, agenii inteligeni staioneaz n

momentul n care ajung n staiile aflate de la capetele de in. Practic, locomivele
verific dac trenul poate avansa cu viteza setat, n direcia setat. Direcia este
precizat prin specificarea unei viteze pozitive sau negative. n cazul n care
locomotivele unui tren verific existena inei n poziia viitoare, trenul este avansat.
Altfel, s-a ajuns n staie i trenurile staioneaz. Fiecare agent inteligent de tip tren
are un cuplu de variabile proprii, timp-stationare, respectiv timp-ajuns-gara, care
permit staionarea. Datorit acestui fapt, fiecare tren poate avea un timp propriu de
staionare n gar. n mod implicit, toate trenurile staioneaz 2 secunde, dar valoarea
aceasta se poate modifica pentru fiecare tren n parte, din linia de comand setnd
variabila timp-stationare.
4.3.3.4. Agenii inteligeni de tip avion
Agenii inteligeni de tip avion (Figura 4.26) zboar
deasupra modelului lumii i aterizeaz dac aeroportul
este funcional, ori sunt redirecionai altfel. Avioanele
cunosc altitudinea maxim i altitudinea actual, folosindo pe cea din urm att pentru aterizare, ct i pentru
prbuire. n momentul prbuirii avionul intr n vrie pe
partea stng, efectul principal al prbuirii fiind incediul
i ruperea copacilor sau deteriorarea carosabilului, n
funcie de locul n care acesta se prbuete. Utilizatorul
alege intrarea n vrie prin intermediul butonului special
din interfa numit generic prabuseste avionul.
34

Figur 4.26. Agent inteligent de

tip avion

4.4. Scenarii de simulare

nainte de simulare, vom prezenta componentele intefeei realizate, dup cum
sunt evideniate n Figura 4.27.

Figur 4.27. Evidenierea zonelor componente ale interfeei realizate

Interfaa grafic este mprit n cinci zone distincte dup cum urmeaz:
zona pentru setarea lumii (galben), prin care putem alege numrul de ageni
inteligeni i tipul acestora. De asemenea, de aici putem arta sau ascunde
senzorii specifici fiecrui sistem critic. Tot aici se regsesc butoanele pentru
rularea simulrii (butonul go), dar i pentru micorarea numrului de cadre pe
secund (butonul slow).
zona de gestionare a evenimentelor (portocaliu) care ne permite simularea
unui cutremur de magnitudine selectat din elementul de tip slider, precum i
adugarea de evenimente sub forma de incendii, ameninri, pan de curent
sau jafuri n mod izolat pentru fiecare sistem critic n parte. n plus, zona
permite setarea perimetrului de siguran att pentru un spaiu restrns
(cldire), ct i pentru ntreg oraul sau chiar pentru toate structurile din
model, dar i anularea tuturor evenimentelor
zona modelului lumii (rou) n care agenii inteligeni reacioneaz la
evenimentele adugate
zona cu elemente statistice (albastru) precum graficele care urmresc
autovehiculele, ct i numrul agenilor inteligeni de tip rutier prezeni n
ora, dar i timpul efectiv de execuie al modelului
zona de monitorizare (roz) n care regsim agenii de tip elemente de afiare
responsabili pentru reflectarea strilor actuale ale tuturor sistemelor critice din
modelul lumii, fiecare putnd avea evenimente distincte de urmrit.
35

4.4.1. Scenariul 1: Cutremur de magnitudine 5 pe scara Richter

Pentru simularea unui cutremur se alege magnitudinea dorit din zona de
evenimente i se actualizeaz cutremurul prin intermediul butonului specific.
Efectele simulrii sunt ilustrate n Figura 4.28, mpreun cu animaia miscrii
pmntului ce are rolul de a evidenia magnitudinea setat.

Figur 4.28. Simularea unui cutremur de 5 grade pe scara Richter

Se remarc urmtoarele consecine:

autovehiculele i oamenii s-au oprit datorit magnitudinii de peste 4 grade.
Graficele evidenieaz oprirea tuturor autovehiculelor, indiferent de poziia n
care se afl, motiv pentru care toate trec n staionare iar graficul responsabil
cu urmrirea numrului total de autovehicule aflate n ora rmne constant
aeroportul, garile i hidrocentrala sunt scoase din funcionare avnd
intensitile prag pentru cutremur sub valoarea setat (4, 4, respectiv 5 grade
Richter)
centrala nuclear i spitalul nc funcioneaz deoarece magnitudinea
cutremurului nc nu le-a depit valorile prag de 5.5, respectiv 6 grade
n urma opririi aeroportului, avioanele nu vor mai ateriza i vor fi
redirecionate ctre un alt aeroport. Refuzul permisiunii de aterizare este
simbolizat prin modificarea culorii fiecrui avion n parte
trenurile sunt oprite att din motivul opririi grilor, ct i datorit
mecanismului propriu de siguran pentru a nu deraia

36

4.4.2. Scenariul 2: Izbucnirea unui incendiu n spital

Din zona de evenimente se selecteaz din listele de tip chooser cladireeveniment opiunea Spitalul, respectiv din eveniment-selectat opiunea incendiu.
Apoi se apas pe butonul Aplica pentru a aduga evenimentul de izbucnire a unui
incendiu n spital. Figura 4.29 prezint rezultatele scenariului.

Figur 4.29. Simularea izbucnirii unui incendiu n sistemul critic Spital

Se constat:
scoaterea spitalului din starea de funcionare, cauza fiind vizibil datorit
elementelor de afiare; senzorii au detectat un incendiu
activarea alarmei i, implicit, restictionarea primetrului din jurul spitalului n
scopul de a facilita eventualele echipaje de intervenie chemate de esutul
Intervenie echipaje de urgen
pietonii din jurul spitalului au fost nlocuii de echipaje de intervenie pentru a
simboliza necesitatea i prezena acestora
autovehiculele nu intr n perimetrul restricionat din jurul spitalului
trenurile, avioanele i restul agenilor inteligeni ce nu interacioneaz cu zona
spitalului nu sunt afectai de acest eveniment deoarece el este de tip local

37

4.4.3. Scenariul 3: Prbuirea avionului

Prbuirea avionului este activat de ctre utilizator; acesta intr n vrie din
momentul n care utilizatorul apas butonul aferent din zona evenimentelor a
interfeei grafice. n funcie de locul n care avionul atinge pmntul, se identific
urmtoarele posibile efecte directe:
lovirea unei cldiri sau a unui sistem critic determin incendierea acestuia i
activarea senzorilor i a strilor aferente
prbuirea pe sau n jurul unui drum duce la stricarea drumului i setarea
zonei respective a acestuia ca fiind nesigur
picajul n pdurea existent determin ruperea i distrugerea copacilor din
zona afectat
n funcie de zona producerii catastrofei, aceste efecte pot fi singulare sau pot
fi combinate. Exemple de prbuire ale avioanelor sunt prezente n Figura 4.30.

Figur 4.30. Exemplificarea efectelor rezultate n urma prbuirii avioanelor

Efectele prbuirii avioanelor n zone diferite, prezentate n figur sunt:

incendierea unei cldiri n urma lovirii avionului
stricarea drumului dintre hidrocentral i centrala-nuclear
ruperea copacilor din pdure, cei situai sub hidrocentral
prbuirea avionului n lac nu produce nici un efect

38

4.4.4. Scenariul 4: Ameninarea cu bomb a grii din ora

Figura 4.31 ilustreaz n mod 3D efectele adugrii unui eveniment de tip
ameninare cu bomb pentru gara din ora. S-a preferat trecerea la acest mod
deoarece efectele prezentate au mai mult o reonan local i sunt mai bine observate
la nivel mezoscopic.

Figur 4.31. Ilustrarea 3D a efectelor ameninrii grii din interiorul oraului cu bomb

Figura evidenieaz urmtoarele consecine:

activarea alarmei pentru gara din ora i setarea perimetrului restricionat, ce
implic i scoaterea acesteia din funcionare, chiar dac agenii de tip element
de afiare nu sunt vizibili din perspectiva aleas
oprirea trenurilor aferente grii din ora, indiferent de poziia n care sunt
surprinse
evitarea drumurilor setate ca fiind nesigure din partea autovehiculelor din
zona afectat
nlocuirea agenilor inteligeni de tip pieton cu ageni de tip echipaj de
intervenie
oprirea agenilor inteligeni de tip pieton n momentul n care acetia ntlnesc
perimetrul restricionat i, astfel, simularea formrii mulimii de spectatori
ngreunarea traficului local datorit anulrii rutelor din jurul grii i obligrii
agenilor de tip autovehicul s se ntoarc pe acelai drum

39

4.4.5. Scenariul 5: Intrarea Aeroportului ntr-o pan de curent

n cazul intrrii sistemului critic Aeroport ntr-o pan de curent, acesta este
trecut n mod automat n modul nefuncional, iar avioanele ajunse nu vor mai
ateriza, ci vor fi redirecionate ctre alt aeroport. Refuzul aterizrii este evideniat
prin schimbarea culorii avioanelor n roz.
De asemenea, Figura 4.32 evidenieaz neafectarea traficului n urma acestui
eveniment. Acest lucru se datoreaz faptului c pana de curent nu pune n pericol
sigurana conductorilor auto i nu necesit echipaje de intervenie, ci doar
rezolvarea problemei care a dus la pana de curent resimit. Mai mult, perspectiva
3D aleas reuete s ilustreze zborul avioanelor peste modelul lumii.

Figur 4.31. Urmrile intrrii aeroportului ntr-o pan de curent

De asemenea, figura permite vizualizarea pdurii i a organizrii geografice

implementate n model i a pomilor plasai de-o parte i de alta a drumurilor i
cldirilor izolate sau aflate la periferia oraului.

40

4.4.6. Scenariul 6: Evacuarea oraului

Alegnd setarea perimetrului pentru toate cldirile din ora se realizeaz, de
fapt, simularea evacurii oraului i punerea acestuia sub carantin. Evacuarea
determi autovehiculele s formeze cozi pentru a putea iei din ora, aa cum este
exemplificat i n Figura 4.32.

Figur 4.32. Ilustrarea evacurii i punerii oraului n carantin, evidenind totodat formarea
de cozi de autovehicule ce vor s ias din ora

n plus, datorit activrii alarmelor, sistemele critice poziionate n ora, cum

ar fi spitalul sau gara, vor trece n nefuncioare i vor avea activ starea de alarm,
dup cum se poate observa n Figura 4.33.

Figur 4.33. Strile evideniate de ctre elementele de afiare n urma evacurii oraului

41

5. Concluzii

n lucrarea de fa am implementat esutul Protocoale Sisteme Critice al

arhitecturii CitySCAPE prin intermediul unui sistem multi-agent, utiliznd platforma
orientat-agent NetLOGO. De asemenea, aplicaia dezvoltat vine nsoit de un
toolkit propriu prin care se pot aduga i testa funcionaliti noi sau deja
implementate. Modelul lumii include ageni inteligeni care redau comportamentul
traficului rutier, feroviar i aerian, i evidenieaz efectul realizat asupra populaiei
urbane i extra-urbane, rezultat n urma aplicrii protocoalelor sistemelor critice la
nivel macroscopic.
Modelul realizat este flexibil, pemind modificarea rapid a modelului lumii
cu ajutorul procedurilor specializate n construirea drumurilor i a cartierelor, n aa
fel nct s poat implementa i testa multiple infrastructuri propuse sau deja
existente. Se poate modifica chiar i mrimea interfeei cu ajutorul modificrii
fiierului de configuraie.
Dei nu au fcut obiectul lucrrii de fa, aplicaia nglobeaz multipli
parametri ce pot fi utilizai pentru modelarea comportamentului agenilor inteligeni.
Astfel de parametri, precum viteza, indicii de acceleraie i deceleraie, distanele de
frnare, distanele dintre ageni, dar i indici de virare, pot fi stabilii att pentru o
ntreag categorie, ct i pentru fiecare agent inteligent n parte, realiznd astfel
tipuri specifice fiecrei categorii. Spre exemplu, o asemenea setare individual
aplicat mainilor ar putea modela un ofer grbit sau un vrstnic, introducnd astfel
noi capabiliti modelului.
Prin intermediul studiului de caz, am demonstrat utilitatea i eficiena
aplicrii de protocoale ale sistemelor critice n scopul obinerii unui mediu citadin
mai sigur i mai flexibil, capabil s gestioneze hazardele i catastrofele la care este
vulnerabil, n scopul minimizri pagubelor nregistrate. De menionat este faptul c
aplicaia dezvoltat permite att simulri constituite dintr-un singur hazard, ct i
din scenarii n care apar dou sau chiar mai multe hazarde, cum ar fi izbucnirea unui
incendiu urmat de un cutremur, i aa mai departe, urmrind astfel eficiena acestor
protocoale n momente cruciale.

42

Anexe
Procedurile setup i go
to setup
clear-all
; global variables setup:
set butoane []
set cladiri-monitorizate []
set senzori-monitorizare []
set-default-shape senzori "senzor"
set-default-shape copaci "tree"
set elemente-afisare []
set cladiri []
setup-globals
; environmental setup:
setup-harta
; interface setup:
setup-interfata
; agents setup:
setup-agenti
reset-timer
reset-ticks
end
to go
; agent motion:
orienteaza-agenti
misca-agenti
tick
end

Procedura de aplicare a evenimentului selectat asupra unui

sistemul critic
to aplica-eveniment-cladire [ cladire-tinta eveniment-propus ]
; selctia cladirii tinta
if ( cladire-tinta = "Aeroportul" ) [ set cladire-tinta ( [id] of ( oneof aeroport ) ) ]
if ( cladire-tinta = "Gara periferie" ) [ set cladire-tinta ( [id] of (
one-of gara-periferie ) ) ]
if ( cladire-tinta = "Gara oras" ) [ set cladire-tinta ( [id] of ( one-of
gara-oras ) ) ]
if ( cladire-tinta = "Spitalul" ) [ set cladire-tinta ( [id] of ( one-of
spital ) ) ]
if ( cladire-tinta = "Centrala nucleara" ) [ set cladire-tinta ( [id] of
( one-of centrala-nucleara ) ) ]
if ( cladire-tinta = "Hidrocentrala" ) [ set cladire-tinta ( [id] of (
one-of hidrocentrala ) ) ]
let senzor-exista ( senzori with [ cladire-id = ( cladire-tinta ) and
eveniment-urmarit = ( eveniment-propus ) ] )
ifelse ( count senzor-exista < 1 )
[

43

user-message (word "Imi pare rau, dar cladirea selectata nu are senzor
pentru " eveniment-propus ".\n\nVa rog selectati alta cladire sau alt
eveniment." )
]
[
ask senzor-exista [
set intensitate prag
]
actualizeaza-monitorizarea
]
end

Procedura de micare a agenilor inteligeni

to misca-agenti
ask turtles with [ categorie = "rutier" ]
[
if (ales-viraj > 0 )
[
set ( ales-viraj ) ( ales-viraj - 1)
if ( virez-stanga > 0 )
[
if ( virez-stanga = ( benzi * 2 - 1 ) )
[
set heading ( heading - 90 )
]
set virez-stanga ( virez-stanga - 1 )
]
]
if ( [tip] of patch-ahead 1 = tip and count turtles-on patch-ahead 1 <
1 )
[
if ( ( [safe] of patch-ahead 1 = true ) or ( [safe] of patch-ahead 1
= safe ) )
[
forward viteza
]
]
]
ask oameni
[
if ( [tip] of patch-ahead viteza = tip and [safe] of patch-ahead viteza
= true )
[
forward viteza
]
]
; trenurile au o alta abordare: orientarea e inclusa in miscare si se
face miscarea pentru fiecare tren in parte
misca-tren tren-1
misca-tren tren-2
misca-tren tren-3
misca-tren tren-4
ask avioane
[
forward viteza
ifelse (([tip] of patch-at-heading-and-distance ( heading
) 2
=
"interfata") and ([tip] of patch-at-heading-and-distance ( heading - 180 )
2 = "interfata"))

44

[
hide-turtle
if ( color = pink )
[
die
]
]
[
show-turtle
]
]
end
to misca-tren [ tren-x ]
ask one-of tren-x with [ locomotiva = true ]
[
ifelse ( ( all? ( tren-x with [ locomotiva = true ] ) [ [tip] of patchahead ( viteza * size ) = "sina" ] ) )
[
if ( timer-running > ( timp-ajuns-gara + timp-stationare ) )
[
ask tren-x [ forward viteza ]
]
]
[
ask tren-x
[
set timp-ajuns-gara timer-running
set viteza ( - viteza )
]
]
]
end

Procedurile utilizate n pentru construirea unui cartier

;; procedura returneaz identificatorul urmtoarei cldiri de adugat
to-report construieste-cartier [ tip-cladiri start-x start-y size-x size-y
marime-cladiri spatiu-cladiri latime-drum marime-trotuar id-cladiri]
let last-id construieste-cladiri tip-cladiri start-x start-y size-x sizey marime-cladiri spatiu-cladiri id-cladiri
;; drumuri
let x1-drum ( start-x + ( latime-drum + latime-trotuar ))
let y1-drum ( start-y + ( latime-drum + latime-trotuar ))
let x2-drum ( x1-drum - (( size-x * marime-cladiri ) + (( size-x - 1 ) *
spatiu-cladiri ) + ( 2 * ( latime-drum + latime-trotuar )) - 1 ))
let y2-drum y1-drum
; construieste drumurile orizontale
repeat ( size-y + 1 )
[
construieste-drum "strada" x1-drum y1-drum x2-drum y2-drum latime-drum
set y1-drum ( y1-drum - ( marime-cladiri + spatiu-cladiri ))
set y2-drum ( y2-drum - ( marime-cladiri + spatiu-cladiri ))
]
set x1-drum ( start-x + ( latime-drum + latime-trotuar ))
set y1-drum ( start-y + ( latime-drum + latime-trotuar ))
set x2-drum x1-drum
set y2-drum ( y1-drum - (( size-y * marime-cladiri ) + (( size-y - 1) *
spatiu-cladiri) + ( 2 * ( latime-drum + latime-trotuar )) - 1 ))

45

; construieste drumurile verticale

repeat ( size-x + 1 )
[
construieste-drum "strada" x1-drum y1-drum x2-drum y2-drum latime-drum
set x1-drum ( x1-drum - ( marime-cladiri + spatiu-cladiri ))
set x2-drum ( x2-drum - ( marime-cladiri + spatiu-cladiri ))
]
;; trotuar
ask patches [ if (( any? neighbors with [ tip = "sosea" ] ) and ( any?
neighbors with [ tip = tip-cladiri ] )) [
set pcolor ( culoare-trotuar )
set tip "trotuar"
set nivel 0
set benzi 1
set safe true
]]
report last-id ; returneaza ultimul id generat.
end
to-report construieste-cladiri [ tip-cladiri start-x-cladiri start-ycladiri X-cladiri Y-cladiri marime-cladiri spatiu-cladiri id-start]
let id-c id-start
let i 0
let dim marime-cladiri - 1
; corectie !
let spatiu spatiu-cladiri + 1 ; corectie !
while [ i < Y-cladiri ]
[
; fiecare rand in parte
let j 0
while [ j < X-cladiri ]
[
let t1 0
let t2 0
; fiecare cladire in parte
let cladire ( patches with [ (pxcor <= ( start-x-cladiri - ( j * dim
)) and pxcor >= ( start-x-cladiri - ( ( j + 1 ) * dim )))
and
(pycor <= ( start-y-cladiri - ( i * dim )) and
pycor >= ( start-y-cladiri - ( ( i + 1 ) * dim ))) ] )
ask cladire
[
set pcolor blue
set nivel 1
set tip tip-cladiri
set id id-c
]
set cladiri lput cladire cladiri
set id-c ( id-c + 1 )
set j ( j + 1 )
set start-x-cladiri ( start-x-cladiri - spatiu )
]
set i ( i + 1 )
set start-y-cladiri ( start-y-cladiri - spatiu)
set start-x-cladiri ( start-x-cladiri + ( X-cladiri * spatiu ))
]
report ( id-c - 1 ) ; returneaza ultimul id adaugat!
end
to construieste-drum [ caz x1 y1 x2 y2 latime]
;; DRUMUL construit contine extremitatile!
ifelse (( x1 = x2 ) or ( y1 = y2 ))
[

46

let cale no-patches

set latime ( latime - 1 ) ; se pierde un patch
ifelse x1 = x2
[
; luam patch-urile intre y1 si y2
if y1 > y2
[
let temp y1
set y1 y2
set y2 temp
]
set cale ( patches with [( pxcor >= x1 - 1 ) and ( pxcor <= x1 +
latime - 1 ) and ( pycor >= y1 ) and ( pycor <= y2 )])
]
[
; luam patch-urile intre x1 si x2
if x1 > x2
[
let temp x1
set x1 x2
set x2 temp
]
set cale ( patches with [( pycor >= y1 - latime ) and ( pycor <= y1 )
and ( pxcor >= x1 ) and ( pxcor <= x2 )])
]
let construit 0
if caz = "strada"
[
ask cale
[
set pcolor ( culoare-sosea )
set nivel 0
set tip "sosea"
set benzi ( ( latime + 1 ) / 2 )
set safe true
]
set construit 1
]
if caz = "trotuar"
[
ask cale [
set pcolor ( culoare-trotuar )
set nivel 0
set tip "trotuar"
set benzi ( ( latime + 1 ) / 2 )
set safe true
]
set construit 1
]
if construit = 0
[
show
"!Primul
parametru
trebuie
sa
fie
ori
<<strada>>
ori
<<trotuar>>!"
]
]
[
show "!Un drum poate fi construit doar pe o abscisa sau ordonata!"
]
end

47

Procedura care seteaz perimetrul resticionat

to seteaza-perimetru-cladire [ id-cladire-tinta tip-cladire ]
ask patches with [ id = id-cladire-tinta and ( tip = tip-cladire ) ]
[
ask patches at-points [[ 3 3 ][ -3 -3 ][ 3 -3 ][ -3 3 ]] with [ tip =
"sosea" or tip = "trotuar" ] ; colturile
[
ifelse ( tip = "sosea" )
[
set pcolor red
]
[
set pcolor pink
]
set safe false
ask oameni-here [ set color 25 ] ;portocaliu => echipaj interventie!
]
ask patches with [ distance myself < 4 and ( tip = "sosea" or tip =
"trotuar" )]
[
ifelse ( tip = "sosea" )
[
set pcolor red
]
[
set pcolor pink
]
set safe false
ask oameni-here [ set color 25 ] ; portocaliu => echipaj interventie!
]
]
; actualizeaza senzor
ask senzori with [ eveniment-urmarit = "alarma" and cladire-id = idcladire-tinta ]
[
set intensitate 1
]
end

Procedura care seteaz interfaa, adaugnd senzorii i

elementele de afiare specifice sistemelor critice
to setup-interfata
;adauga-elemente-monitorizare [ start-x-em start-y-em X-em Y-em dim-em
spatiu-em id-em cladire-parinte stari-urmarite ]
adauga-elemente-monitorizare -100 -36 6 1 3 2 ( [id] of one-of aeroport )
"Aeroport" [ "functionare" "alarma" "incendiu" "cutremur" "pana curent"
"amenintare" ]
adauga-elemente-monitorizare
-60 -36 6 1 3 2 ( [id] of one-of garaperiferie ) "Gara periferie" [ "functionare" "alarma" "incendiu" "cutremur"
"pana curent" "amenintare" ]
adauga-elemente-monitorizare -20 -36 6 1 3 2 ( [id] of one-of gara-oras
) "Gara oras" [ "functionare" "alarma" "incendiu" "cutremur" "pana curent"
"amenintare" ]
adauga-elemente-monitorizare
20 -36 5 1 3 2 ( [id] of one-of centralanucleara ) "Centrala nucleara" [ "functionare" "alarma" "incendiu"
"cutremur" "amenintare" ]
adauga-elemente-monitorizare
60 -36 5 1 3 2 ( [id] of one-of
hidrocentrala ) "Hidrocentrala" [ "functionare" "alarma" "incendiu"
"cutremur" "amenintare" ]

48

adauga-elemente-monitorizare 100 -36 7 1 3 2 ( [id] of one-of spital )

"Spital (galben)" [ "functionare" "alarma" "incendiu" "cutremur" "jaf"
"amenintare" "pana curent" ]
;adauga-senzori-monitorizare [ cladire-parinte stari-urmarite praguri ]
adauga-senzori-monitorizare ( [id] of one-of aeroport ) [ "alarma"
"incendiu" "cutremur" "pana curent" "amenintare" ] [ 1 1 4 1 1 ]
adauga-senzori-monitorizare ( [id] of one-of gara-periferie ) [ "alarma"
"incendiu" "cutremur" "pana curent" "amenintare" ] [ 1 1 4 1 1 ]
adauga-senzori-monitorizare ( [id] of one-of gara-oras ) [ "alarma"
"incendiu" "cutremur" "pana curent" "amenintare" ] [ 1 1 4 1 1 ]
adauga-senzori-monitorizare ( [id] of one-of centrala-nucleara ) [
"alarma" "incendiu" "cutremur" "amenintare" ] [ 1 1 5.5 1 ]
adauga-senzori-monitorizare ( [id] of one-of hidrocentrala ) [ "alarma"
"incendiu" "cutremur" "amenintare" ] [ 1 1 5 1 ]
adauga-senzori-monitorizare ( [id] of one-of spital ) [ "functionare"
"alarma" "incendiu" "cutremur" "jaf" "amenintare" "pana curent" ] [ 1 1 1 6
1 1 1 ]
end

Procedura de adugare a senzorilor pentru sisteme critice

to adauga-senzori-monitorizare [ cladire-parinte stari-urmarite praguri ]
let id-num length senzori-monitorizare
let index-prag 0
foreach stari-urmarite
[
let target item cladire-parinte cladiri
create-senzori 1 [
set hidden? true
move-to one-of target with [ count turtles-here < 1 ]
set id-senzor id-num
set ( id-num ) ( id-num + 1 )
set eveniment-urmarit ( ? )
set cladire-id ( cladire-parinte )
set intensitate 0
set prag item index-prag praguri
set color ( pcolor + 20 )
set senzori-monitorizare lput ( self ) senzori-monitorizare
set index-prag ( index-prag + 1 )
]
]
set cladiri-monitorizate lput ( item cladire-parinte cladiri ) cladirimonitorizate
end

Procedura de actualizare a timpului de rulare

to-report afiseaza-timp-rulare
ifelse ( ticks > last-tick-running )
[
set ( timer-running ) ( timer-running + ( timer - timer-dummy ) )
set last-tick-running ticks
set timer-dummy timer
]
[
set timer-dummy timer
]
report (word floor ( timer-running / 3600 ) " ore, " floor ( timerrunning / 60 ) " minute si " floor ( timer-running mod 60 ) " secunde ")
end

49

Bibliografie

Wooldridge M. 2002, An Introduction to Multiagent System, John Wiley & Sons,

LTD, Chichester, ISBN 978-0470519462
Russell S., Norvig P. 2010, Artificial Intelligence A modern Approach. Third
Edition, Prentice Hall, New Jersey, ISBN 978-0136042594
Fulbright R., Stephens L.M., 1994, Classification of Multiagent Systems,
TECHREPORT 94-06, pg. 94-97
Remagnino P., Shihab A.I., Jones G.A., 2004, Distributed intelligence for multicamera visual surveillance, Pattern Recognition, vol. 37, Elsevier, pg. 675-689, ISSN 00313203
Nguyen Q.T., Bouju A., Estraillier P., 2012, Multi-agent arhitecture with spacetime components for the simulation of urban transportation systems, 15th meeting of the
Euro Working Group on Transportation, Paris
Cabrera E., Luque E., Taboada M., Epelde F., Iglesias M.L., 2011, Optimization
of Healthcare Emergency Departments by Agent-Based Simulation, International
Conference on Computational Science, ICCS 2011, ISBN 978-1-4673-2283-6
Ptracu M., Drgoicea M., Integrating Services and Agents for Control and
Monitoring: A Smart Building Perspective, Preprints of the International Workshop on
Service Orientation in Holonic and Multi Agent Manufacturing and Robotics
SOHOMA13, Valenciennes, France, June 20-22, 2013, pg. 167-180, ISBN 978-973-720490-5
Teahan W.J., 2010, Artificial Intelligence Agents and Environments, Ventus
Plblishing ApS, ISBN 978-87-7681-528-8

50