Page 1
Universitatea Politehnică București
Facultatea de Automatică și Calculatoare
Departamentul de Automatică și Ingineria Sistemelor
LUCRARE DE LICENȚĂ
Managementul situațiilor de urgență utilizând
sisteme multi-agent. Aplicație la nivel
macroscopic: „Protocoale sisteme critice”
Absolvent
George-Alexandru Serea
Coordonator
S.l. dr. ing. Monica Pătrașcu
București 2013
Page 2
Cuprins
1. Introducere ........................................................................................................................... 1
2. Agenți inteligenți și Sisteme Multi-Agent (MAS) ........................................................... 2
2.1. Agenți inteligenți .......................................................................................................... 2
2.1.1 Agenți care se bazează pe reflexe simple ............................................................. 2
2.1.2 Agenți care păstrează o imagine a lumii .............................................................. 3
2.1.3 Agenți care se bazează pe un scop ........................................................................ 3
2.1.4. Agenți care se bazează pe utilitate ....................................................................... 3
2.1.5. Proprietățile agenților inteligenți ......................................................................... 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 Percepție ................................................................... 7
2.3. Exemple de utilizare a Sistemelor Multi-Agent ....................................................... 8
3. Sisteme Multi-Agent utilizate în managementul situațiilor 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 „Avertizări și controlul panicii” .......................................................... 11
3.3. Soluția propusă ........................................................................................................... 12
4. Studiu de caz ...................................................................................................................... 14
4.1. Descrierea aplicației .................................................................................................... 14
4.2. Prezentarea Toolkit-ului „Custom City Builder” ...................................................... 15
4.2.1. Generarea unui cartier de clădiri și pavarea drumurilor aferente ................ 17
4.2.2. Adăugarea identificatorului unic pentru fiecare clădire în parte ................. 18
4.2.3. Setarea perimetrului restricționat în jurul unei clădiri ................................... 19
4.2.4. Marcarea poziției viitoare a unui agent și testarea in-cone ............................. 20
4.2.5. Modelarea deplasării și a redresării unui agent mobil ................................... 22
4.2.6. Adăugarea de agenți într-un model cu restricție pe populație ..................... 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 orașului ................................................................................ 27
4.3.1.3. Gara din oraș ................................................................................................. 27
Page 3
4.3.1.4. Spitalul ........................................................................................................... 28
4.3.1.5. Centrala nucleară .......................................................................................... 28
4.3.1.6. Hidrocentrala ................................................................................................ 28
4.3.2. Agenți implicați în implementarea protocoalelor sistemelor critice ............ 29
4.3.2.1. Agenții de percepție ai mulțimii DP ........................................................... 29
4.3.2.2. Agenții incluși în mulțimea DA ................................................................... 30
4.3.2.3. Agenții de control ai mulțimii DC ............................................................... 31
4.3.3. Agenții inteligenți mobili .................................................................................... 32
4.3.3.1. Pietonii............................................................................................................ 33
4.3.3.2. Agenții inteligenți din categoria rutieră .................................................... 33
4.3.3.3. Agenții inteligenți de tip tren ...................................................................... 34
4.3.3.4. Agenții inteligenți 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: Prăbușirea avionului ...................................................................... 38
4.4.4. Scenariul 4: Amenințarea cu bombă a gării din oraș ...................................... 39
4.4.5. Scenariul 5: Intrarea Aeroportului într-o pană de curent ............................... 40
4.4.6. Scenariul 6: Evacuarea orașului ......................................................................... 41
5. Concluzii ............................................................................................................................. 42
Anexe ....................................................................................................................................... 43
Procedurile setup și go ........................................................................................................ 43
Procedura de aplicare a evenimentului selectat asupra unui sistemul critic ............ 43
Procedura de mișcare a agenților inteligenți ................................................................. 44
Procedurile utilizate în pentru construirea unui cartier .............................................. 45
Procedura care setează perimetrul resticționat ............................................................. 48
Procedura care setează interfața, adaugând senzorii și elementele de afișare
specifice sistemelor critice................................................................................................. 48
Procedura de adăugare a senzorilor pentru sisteme critice ......................................... 49
Procedura de actualizare a timpului de rulare .............................................................. 49
Bibliografie .............................................................................................................................. 50
Page 4
1
1. Introducere
În ultimele decenii, avansul tehnologic a permis îmbunătățirea calității și
siguranței vieții umane, lucru reflectat în creșterea și evoluția continuă a sistemelor
urbane până la megalopolisuri cu densități locale ale populației de peste 10,000 de
locuitori pe kilometru pătrat. Această aglomerare ridică noi probleme în ceea ce
privește răspunsul sistemelor dedicate de intervenție în cazul situațiilor critice și
evidențiează punctele slabe ale infrastucturii existente în majoritatea marilor orașe.
Echipajele de intervenție întâmpină probleme datorită traficului supra-aglomerat și a
ambuteliajelor, iar evacuarea populației afectate este și ea îngreunată.
În lucrarea de față vom urmări managementul situațiilor de urgență la nivel
macroscopic (oraș) și vom implementa protocoale pentru sisteme critice și o formă
minimală de avertizări, utilizând programare orientată agent (AOP) pentru
modelarea sistemului multi-agent.
Aplicația dezvoltată este flexibilă, modelul lumii putând fi modificat cu
ușurință datorită construirii acestuia prin intermediul procedurilor de construcție a
cartierelor, clădirilor ș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 soluții deja implementate a acestor sisteme pentru
probleme de modelare actuale.
Capitolul trei restânge aria de acoperire a acestor sisteme și introduce
aritectura CitySCAPE și aplicabilitatea acesteia în cadrul lucrării de față, descriind
soluția de implementare propusă.
Studiul de caz regăsit în capitolul patru descrie modelarea lumii, atât la
nivelul sistemelor critice considerate, cât și la nivelul agenților inteligenți dezvoltați
pentru simularea traficului sau a populației. Totodată, se prezintă toolkit-ul realizat
pentru testarea și implementarea soluției propuse, evidențiind utilitatea acestuia
pentru realizarea modelului lumii. De asemenea, capitolul patru conține scenariile de
simulare prin care sunt utilizate protocoalele sistemelor critice implementate și
efectul acestora asupra modelului lumii realizat.
Concluziile din capitolul cinci evidențiează rezultatele obținute, dar și viitoare
implementări sau îmbunătățiri ce pot fi aduse lucrării prezentate, în scopul realizării
unui model al lumii cât mai apropiat realității.
Page 5
2
2. Agenți inteligenți și Sisteme Multi-Agent (MAS)
2.1. Agenți inteligenți
Agenții inteligenți sunt programe individuale, autonome ce au ca scop
îndeplinirea anumitor sarcini, numite deseori „task”-uri, care pot interacționa cu
mediul în care operează și, totodată, cu alți agenți inteligenți. Există o posibilă
definiție în literatura de specialitate (Wooldridge, 2002): „Un agent este un sistem
computațional care este situat într-un mediu și care este capabil de acțiuni autonome în acest
mediu în așa fel încât să își atingă obiectivele stabilite.”
Mediul în care un agent operează, conform (Russell & Norvig, 2010) se poate
clasifica în funcție de următoarele proprietăți:
accesibil vs. inaccesibil. Un mediu accesibil este un mediu din care agentul
poate obține informații complete si corecte despre starea curentă.
deterministic vs nedeterministic. Mediul deterministic este acela în care
pentru orice acțiune există o consecință clară, sigură; nu există nici o
incertitudine în ceea ce privește rezultatul unei acțiuni.
static vs. dinamic. Un mediu static se poate considera neschimbat în lipsa
acțiunilor agenților, pe când asupra unui mediu dinamic operează și alte
entități care nu depind de agenți.
discret vs. continuu. Putem numi un mediu discret dacă există un număr
exact, finit de acțiuni si percepții în el.
Datorită faptului că agenții inteligenți sunt meniți să îndeplinească diferite
sarcini și că pot comunica fie între ei, fie cu mediul înconjurător în scopul de a
extrage informații din mediul în care sunt plasați prin intermediul senzorilor, există
mai multe clasificări ale acestora, în funcție de criteriul considerat.
O clasificare remarcabilă provine din (Russell & Norvig, 2010). Cartea
propune clasificarea agenților în 4 categorii:
agenți reflex (agenți simpli care se bazează pe reflexe simple la input)
agenți care păstrează o imagine a lumii
agenți care se bazează pe un scop
agenți care se bazează pe o utilitate
2.1.1 Agenți care se bazează pe reflexe simple
Axați pe stabilirea legăturilor dintre intrări și ieșiri, agenții care se bazează pe
reflexe sunt cei mai simpli. Practic, în funcție de intrarea percepută, acest tip de agent
Page 6
3
returnează o ieșire prestabilită. Este de la sine înțeles că nu se pune problema
construirii unei tabele explicite care mapează legăturile intrare-ieșire posibile datorită
numărului extraordinar de combinații posibile, însă la baza acestor agenți stau reguli
de tip condiție-acțiune. De remarcat este faptul că acest tip de agent nu se modifică
în timpul execuției, motiv pentru care poate fi considerat a fi static din punct de
vedere al regulilor aplicate.
2.1.2 Agenți care păstrează o imagine a lumii
Spre deosebire de agenții reflexivi la care acțiunea este dictată exclusiv de ceea
ce se petrece în mediul înconjurător, agenții care păstrează o imagine a lumii se
folosesc de senzorii pentru a creea o stare internă ce ilustrează situația curentă a
mediului. Pentru realizarea cât mai fildelă și actualizarea acestei stări interne, agentul
are nevoie de două tipuri de informații. Pe de-o parte are nevoie de informații
referitoare la evoluția lumii independentă de acțiunile sale și, pe de altă parte, de
informații 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 către noua stare internă se va face prin îmbinarea
informațiilor provenite de la senzori cu informațiile stării interne. Apoi această nouă
stare este interpretată prin intermediul regulilor prestabilite.
2.1.3 Agenți care se bazează pe un scop
În unele cazuri nu este suficient ca agentul să dețină informații doar despre
starea curentă a mediului în care operează, motiv pentru care acest tip de agenți
conțin și informații referitoare la scopul pe care îl au, informații care denotă starea în
care doresc să se ajungă. Asemenea agenți estimează atât consecințele acțiunilor lor,
cât și avansul către scopul pe care îl au de îndeplinit pentru a alege cea mai bună
variantă posibilă la momentul respectiv. Cartea reușește să evidențieze diferențele
dintre aceste tipuri de agenți astfel: considerăm un agent inteligent de tip mașină. Un
agent reflexiv ar putea frâna în momentul în care mașina din fața sa frânează pentru
că recunoaște stopul central de pe lunetă, fără a ține cont de alte considerente, pe
când un agent care cu o stare internă face distincția în mod intern între mașinile cu și
fără stop central și se comportă identic pentru amândouă; frânează. Considernând
însă ca agentul ajunge la o intersecție, nu ar fi nici o diferență între cei doi, direcția 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ă destinație,
el va alege ruta necesară pentru destinația respectivă (Russell & Norvig, 2010).
2.1.4. Agenți care se bazează pe utilitate
De cele mai multe ori, scopurile nu sunt suficiente pentru a determina un
comportament de calitate în ceea ce privește agenții inteligenți. Spre exemplu, există
foarte multe rute care duc taxiul la destinație, însă unele sunt mai scurte și rapide, iar
Page 7
4
altele sunt mai lungi și duc la întârzieri. În astfel de cazuri este indicat ca agentul să
poată face distincția între două decizii corecte și să o poată alege pe cea mai
favorabilă. Pentru adăugarea acestei puteri de decizie, agenților inteligenți li se
atribuie mijloace prin care măsoară utilitatea acțiunilor lor și, astfel, determină cele
mai bune răspunsuri și acțiuni. Practic, utilitatea atribuie fiecărei acțiuni posibile un
număr real, direct proporțional cu beneficiile aduse. Utilitatea ajută în cazuri în care
scopurile nu pot distinge între două soluții și creează un echilibru între ele, de
exemplu alegerea vitezei optime în asa fel încât siguranța să nu fie riscată. De
asemenea, un agent bazat pe scopuri nu poate face distincția între două scopuri, unul
mai ușor realizabil decât celălalt, pe când utilitatea poate măsura eventuala realizare
a scopului și ajută agentul în luarea deciziei corecte (Russell & Norvig, 2010).
2.1.5. Proprietățile agenților inteligenți
Pentru a fi cu adevărat inteligent, (Wooldridge, 2002) afirmă că un agent
trebuie să integreze următoarele proprietăți:
autonomie. Fiecare agent are țeluri și resurse individuale și este capabil să
lucreze în lipsa intervenției exterioare
reactivitate. Un agent inteligent este menit să ofere mediului în care operează
un răspuns pe baza percepțiilor dobândite
proactivitate. Agentul trebuie să fie capabil să ia inițiativa în așa manieră încât
să își satisfacă cerințele
sociabilitate. Pentru îndeplinirea cerințelor, agentul trebuie să fie capabil să
interacționeze si cu alți agenți, nu neapărat de același fel
2.2. Sisteme Multi-Agent (MAS)
Potrivit (Fulbright & Stephens, 1994), „un sistem multiagent este constituit din
mai mulți agenți inteligenți care operează în același mediu”. Practic, ei interacționează atât
cu mediul, cât și cu alți agenți, nu neapărat de același tip. Mai mult, deși agenții
împart mediul, fiecare agent în parte percepe și acționează în mod independent. Vom
prezenta în continuare clasificarea propusă de către acești autori.
2.2.1. Clasificarea Sistemelor Multi-Agent (MAS)
Clasificarea Sistemelor Multi-Agent se află în strânsă legătură cu agenții care
compun sistemul, motiv pentru care (Fulbright & Stephens, 1994) prezintă modelarea
fiecărui agent în parte prin prisma a patru mulțimi disjuncte:
o muțime a datelor stocate, numită D
mulțimea starilor externe, specifice mediului, notată S
o mulțime formată din partiții ale lui S, notată T, care reprezintă percepțiile
fiecărui agent
Page 8
5
mulțimea acțiunilor posibile, numită A
În plus, agenții dispun și de următoarele patru operații, definite ca produs
cartezian astfel:
percepe: S T evidențiează 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ă acțiunea potrivită
acționează: A x S S reprezintă abilitatea agentului de a acționa asupra
mediului
Fiecare agent operează și actualizează
aceste patru mulțimi în momentul executării.
Dacă considerăm doi agenți care lucrează în
același mediu, ei vor împărți S, dar vor avea
mulțimile T, D și A proprii. Acest tip de sistem
poarta numele de „Sistem multi-agent de tip 1”
(Figura 2.1). Operația de împărțire a unei
mulțimi poartă numele de cuplare.
De menționat este faptul că „toate sistemele existente în natură sunt sisteme multi-
agent de tip 1” (Fulbright & Stephens, 1994).
Folosind operația de cuplare, putem realiza
o clasificare pertinentă a sistemelor multi-agent
împărțind și mulțimile individuale, evidențiând
astfel opt tipuri distincte de sisteme prezentate în
Figura 2.2.
Așadar, indentificăm următoarele tipuri de
Sisteme Multi-Agent:
cu agenți autonomi ( tip 1 )
cu agenți cuplați perceptual ( tip 2 )
cu agenți cu inferență cuplată ( tip 3 )
cu agenți cognitiv-distribuiți ( tip 4 )
cu agenți cognitiv-cuplați ( tip 5 )
cu agenți cu inferența distribuita ( tip 6 )
cu agenți cu percepția distribuită ( tip 7 )
cu un singur agent ( tip 8 )
Clasificarea rezultată permite gruparea
tipurilor rezultate în clase distincte de sisteme
multi-agent, fiecare clasă evidențiind metodologia
principală după care se face separarea sistemelor.
Figură 2.1. Agenți împărțind același mediu
(Fullbright & Stephens, 2006)
Figură 2.2. Tipuri de cuplări posibile
(Fullbright & Stephens, 2006)
Page 9
6
2.2.1.1. Clasificarea pe clase
Excluzând cazurile extreme, anume tipul 1 și tipul 8, în funcție de poziția în
care apare mulțimea 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ă agenții conțin intern mulțimea A. Specific acestei clase este faptul
că agenții pot acționa în mod independent unii față de ceilalți.
clasa Distribuită de Sisteme Multi-Agent, constituită din tipurile 4, 6 și 7 în
care mulțimea A este împărțită de către toți agenții și, drept urmare, aceștia nu
pot acționa în mod independent, ci doar colectiv.
De asemenea, împărțind clasele în centralizate și descentralizate obținem
aceiași 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ă
Figură 2.3. Clasa Cuplată vs. Clasa Distribuită a Sistemelor Multi-Agent
(Fullbright & Stephens, 2006)
Page 10
7
2.2.1.2. Clasificarea bazată pe Inferență
Clasificarea bazată pe Inferență se axează pe poziționarea mulțimii D și,
implicit, a funcției inferă, împărțind Sistemele Multi-Agent astfel:
SMA cu agenți neinferențiali, care realizează operația de cuplare prin prisma
mulțimii D, și care cuprinde tipurile 3, 5 și 7
SMA cu agenți inferențiali, cu funcție de inferență proprie, incluzând tipurile
1,2, 4, 6 și 8
2.2.1.3. Clasificarea bazată pe Percepție
Urmărind în schimb localizarea funcției percepție și a matricei T, se obține
clasificarea bazată pe Percepție, ilustrată în Figura 2.4.
Practic, această clasificare evidențiează tipurile care folosesc în mod individual
sau realizează operația de cuplare prin matricea de percepții T.
Figură 2.4. Clasificarea bazată a Sistemelor Multi-Agent
(Fullbright & Stephens, 2006)
Page 11
8
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 raționament ori o soluție pentru infrastructuri, ci și pentru a oferi o soluție
complet automatizată și capabilă să preia o responsabilitate din ce în ce mai mare.
Acest lucru este posibil datorită puterii acestor sisteme de a împărți o problemă sau
cerință și de a-i facilita rezolvarea prin intermediul mai multor agenți, folosind o
inteligență distribuită pentru a realiza o soluție colectivă.
Soluția descrisă în (Remagnino et al, 2004) reușește să fie din ce în ce mai
convenabilă datorită atât tehnologiei deja existente, cât și a tehnologiei în curs de
dezvoltare în ceea ce privește camerele de supraveghere. În locul unui sistem pur
centralizat în care camerele doar furnizează datele, iar rolul de a extrage informația
este îndeplinit de către supervizor, se propune transferul rolului de a extrage
informația utilă din date de la supervizor la sisteme de calcul responsabile pentru un
grup de camere sau chiar incluzând această operație în camerele inteligente. Astfel,
supervizorul este liber să interpreteze informația deja prelucrată și să gestioneze mai
bine și mult mai rapid situațiile ce necesită intervenția sistemului. În plus, utilizarea
sistemului multi-agent propus ofera multe avantaje cheie:
se obține un grad înalt de autonomie
sistemul automat de supraveghere este mai flexibil datorită descentralizării și
capătă rezistență la eventuale probleme hardware sau software
sistemul este adaptiv datorită antrenării camerelor-agent și nu mai este
dependent de luminozitatea ambientală sau condițiile meteo
Cea mai frecventă utilizare a sistemelor multi-agent este aceea de a simula
comportamentul mediilor foarte dinamice, precum întâlnim în (Nguyen et al, 2012).
Se propune o arhitectură multi-agent cu componente spațial-temporare pentru
simularea transportului urban modern care se adresează în mod direct nevoilor
organizatorice. Această arhitectură este corelată cu datele statistice reale ale orașului
La Rochelle și, astfel, realizează un prototip al mișcării populației care este folosit
pentru identificarea posibilelor îmbunătățiri sau modificări ce pot fi aduse orașului.
Utilizarea acestor sisteme nu este restricționată 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 funcționarea acestor departamente. Totodată se urmărește
găsirea unei configurații optime care include doctori, asistente medicale cu rolul de a
tria urgențele și personal administrativ. Scopul este fie minimizarea timpului de
așteptare al pacienților, fie maximizarea fluxului de gestiune al urgențelor.
Page 12
9
3. Sisteme Multi-Agent utilizate în managementul
situațiilor de urgență
3.1. Prezentarea arhitecturii CityScape
Managementul situațiilor de urgență într-un mod eficient presupune
realizarea unei infrastructuri capabile să acționeze atât local, cât ș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 (Pătrașcu & Drăgoicea, 2013).
Arhitectura CitySCAPE este constituită din două sisteme interconectate și
interdependente (Figura 3.1):
inSCAPE sau „Integrated Networked CitySCAPE”
eSCAPE sau „Emergent CitySCAPE”
„CitySCAPE funcționează asemenea unui organism viu, unde peste un suport de tip
schelet (inSCAPE) se plasează organele (eSCAPE) și sisteme nervoase (rețele de
comunicație).”
(Pătrașcu & Drăgoicea, 2013)
3.1.1. inSCAPE
Responsabil pentru integrarea și interconectarea dispozitivelor și a serviciilor,
inSCAPE asigură integritatea structurală a arhitecturii realizând interconectarea pe
verticală între subsisteme (Figura 3.2 stânga), și, totodata, integrarea pe orizontală
(Figura 3.2 dreapta).
Figură 3.1. Arhitectura CitySCAPE la nivel macroscopic
(Pătrașcu & Drăgoicea, 2013)
Page 13
10
3.1.2. eSCAPE
eSCAPE este format din multiple celule și țesuturi, împreună cu relațile dintre
acestea. Este constituit din patru tipuri de țesuturi, fiecare responsabil de o singură
funcție a sistemului de siguranță (Figura 3.3):
protocoale ale sistemelor critice
intervenția echipajelor de urgență
avertizări și controlul panicii
controlul traficului
Fiecare celulă < . > = {Dc, DP, DA, Ucomm} este formată dintr-o mulțime de
dispozitive de control (Dc), dispozitive de percepție (DP), dispozitive de acționare
(DA) și o unitate de comunicație (Ucomm). Aceste celule vor fi implementate prin
intermediul Sistemelor Multi-Agent formând un mediu activ de simulare și testare.
Mai multe n celule de același tip pot forma un țesut << . >> = { < . >i | i=1,n} (Pătrașcu
& Drăgoicea, 2013).
Figură 3.2. Interconectarea verticală (stânga) și Integrarea orizontală (dreapta)
(Pătrașcu & Drăgoicea, 2013)
Figură 3.3. Structura eSCAPE
(Pătrașcu & Drăgoicea, 2013)
Page 14
11
3.2. Formularea problemei
Lucrarea de față urmărește implementarea protocoalelor sistemelor critice prin
intermediul unui sistem multi-agent folosind arhitectura CitySCAPE. Datorită
strânsei legături dintre țesuturile acestei arhitecturi, modelul va îngloba și o parte din
țesutul responsabil pentru avertizări și controlul panicii, reflectat prin intermediul
unei interfețe grafice de monitorizare care urmărește atât stările de funcționare a
sistemelor critice modelate, cât și evenimentele sau hazardele la care este supusă
fiecare structură în parte.
3.2.1. Țesutul „Protocoale sisteme critice”
Conform modelului prezentat în (Pătrașcu & Drăgoicea, 2013), acest țesut este
format din celule de tipul „Protcoale de Urgență pentru sisteme Critice”, <PUC> = {DC,
DP, DA, Ucomm} pentru care DC conține protocoalele specifice zonei în care celulele sunt
implementate, DP este constituit din agenți pentru percepție ce culeg informații din
zonele de interes, DA reprezintă agenții care acționează și implementează
protocoalele. Totalitatea celulelor provenite dintr-o singură zonă formează
submuțimea țesutului <<PUC>> responsabilă exclusiv pentru zona respectivă.
În cadrul aplicației dezvoltate, mai multe asemenea celule de tip <PUC> au
fost implementate. Există, așadar, o mulțime de asemenea celule pentru fiecare
sistem critic existent în modelul lumii generat de aplicație, cât și o celulă pentru
întreaga zonă, responsabilă pentru evenimente seismice. De exemplu, în momentul
în care este detectat un cutremur, aceasta va decide dacă oprește sau nu funcționarea
fiecărui 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 depășește trei-patru grade pe scara
Richter.
3.2.2. Țesutul „Avertizări și controlul panicii”
Datorită stânsei legături dintre aceste două țesuturi, aplicația conține
fragmente și din țesutul „Avertizări și controlul panicii”, mai exact implementează o
formă de avertizări prin intermediul interfeței de monitorizare. Această interfață
prezintă starea actuală a fiecărui sistem critic prin intermediul unor elemente de
afișare ce sunt modificate în funcție de percepțiile agenților de tip senzor existenți.
Aceste informații ar putea fi apoi preluate de către un țesut complet de tip
„Avertizări și controlul panicii” pentru a realiza managementul populației conform
protocolului specific zonei.
Page 15
12
3.3. Soluția propusă
Pentru managementul situațiilor de urgență utilizând 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 citește
și interpretează informația provenită din partea senzorilor, dar și din elementele de
afișare aferente ce sunt schimbate în funcție de inferențele generate.
Fiecare sistem critic se poate afla fie în stare funcțională, fie în stare
nefuncționala, iar țesutul implementat stabilește starea sistemului prin intermediul
protocoalelor sistemelor critice, cu ajutorul agenților de tip senzor și a mecanismului de
inferență. Apoi implementarea parțială a țesutului „Avertizări și controlul panicii”
preia informația și actualizează elementele de afișare atașate sistemului.
Celulele țesutului „Protocoale sisteme critice” urmăresc evenimentele ce pot fi
aplicate fiecărui sistem critic în parte. Exemple de evenimente sunt: izbucnirea unui
incendiu, înregistrarea unui cutremur, lansarea unei amenințări teroriste,
desfășurarea unui jaf sau întreruperea curentului electric. În general aceste valori
sunt booleene, putând exprima doar o valoare de adevăr, însă celulele implementate
pentru evenimente seismice necesită citirea unei intensități, nu doar a unei stări. În
consecință, aplicația a realizat un model flexibil pentru celulele țesutului care permite
modelarea atât a cutremurelor, cât ș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 restrâns doar la aceste tipuri de evenimente, ci permite adăugarea cu ușurință a
altora prin simpla adăugare în cadrul mecanismului de inferență și a senzorilor,
respectiv a elementelor de afișare aferente.
Modelul lumii este constituit din clădiri sau structuri generalizate care
dobândesc sau nu diverse funcționalități, astfel devenind gări, centrale nucleare,
hidrocentrale, aeroporturi sau spitale. În mod implicit în jurul fiecărei clădiri se poate
seta un perimetru izolat pentru a separa populația de forțele de intervenție cu
ajutorul activării unei alarme. Acest lucru seste posibil deoarece fiecare clădire este
referențiată în mod unic cu ajutorul unui câmp identificator.
O clădire armată sau cu alarma activă va trece în mod automat în starea
nefuncțională și va fi izolată. Decizia de a izola sau nu o clădire este stabilită de către
țesutul „Protocoale sisteme critice”, pe când izolarea clădirii în caz de alarmă intră în
atribuțiile țesutului de avertizări, demonstrând astfel strânsa legătură dintre aceste
două țesuturi distincte. Mai departe, un țesut de tip „Intervenție echipaje de urgență”
ar putea procesa cererea, iar un țesut de tip „Controlul traficului” ar fi responsabil
Page 16
13
pentru gestiunea traficului în scopul minimizării timpului de intervenție al acestor
echipaje. Aceste țesuturi nu fac obiectul prezentei lucrării.
Pentru realizarea celulelor s-au modelat agenți de tip senzor și element de
afișare, fiecare senzor fiind legat în mod implicit de un element de afișare. Însă
corespondența nu este bilaterală, elementele de afișare care evidențiează starea alarmei
sau starea de funcționare nefiind, în general, conectate la un senzor.
Mai mult, am implementat agenți inteligenți pentru a simula atât
comportamentul traficului rutier, cât și feroviar sau aerian. De asemenea modelul
este prevăzut cu agenți inteligenți de tip pietoni care se depleazează pe trotuare. În
momentul în care unei clădiri îi este stabilită starea de „armată” se creează un
perimetru în jurul acesteia din care agenții deja prezenți vor fugi, iar restul agenților
îl vor evita. Pentru a realiza o simulare fidelă, în momentul în care un pieton ajunge
în fața unui perimetru armat, el se va opri pentru a simula formarea mulțimilor, iar
pietonii deja aflați în permetru vor fi înlocuiți de forțe de intervenție.
Agenții inteligenți sunt reactivi la mediul în care se află, interacționând cu
modelul lumii prin scanări periodice. Așadar, autovehiculele știu întotdeauna care
sunt direcțiile posibile și sigure în care se pot deplasa, trenurile știu când ajung la
capătul șinei și staționează, pietonii nu ies niciodată de pe trotuar, iar avioanele caută
în permanență un aeroport funcțional care să le faciliteze aterizarea.
De asemenea, mecanismul de inferență responsabil pentru managementul
sistemelor critice este un agent inteligent care conlucrează cu agenții senzor și agenții
element de afișare pentru a implementa protocoalele sistemelor critice și a ilustra starea
curentă a sistemului urmărit.
Aplicația dezvoltată permite aplicarea de evenimente asupra uneia sau a
tuturor sistemelor critice ori a clădirilor. În mod asemănător, se pot arma clădirile și
astfel se poate simula evacuarea și punerea în carantină a orașului. Este de menționat
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
funcționare a aeroportului, avioanele nu vor mai ateriza, iar trenurile aferente
aeroportului se vor opri, iar scoaterea din funcționare a gării periferice va opri toate
trenurile prezente în model.
Totodată se poate simula prăbușirea avionului prin intermediul interfeței
grafice, indiferent de locul în care acesta se află. În momentul activării acestui
eveniment, avionul va intra în vrie pe partea stângă și se va prăbuși. Dacă zona
catastrofei va fi o clădire, aceasta va determina apariția unui incendiu și i se va activa
perimetrul, altfel vom avea drep consecințe stricarea și blocarea șoselei sau
distrugerea copacilor afectați.
Page 17
14
4. Studiu de caz
4.1. Descrierea aplicației
Aplicația realizată generează un model al lumii în care plasează agenți
inteligenți mobili sau ficși și urmărește simularea diverselor scenarii de urgență prin
adăugarea de evenimente pentru sistemele critice modelate. Agenții mobili sunt de
tip pieton, mașină, autobuz, camion, tren sau avion și modelează fluxul traficului
rutier, feroviar și aerian, pe când agenții ficși reprezintă sistemele critice, clădirile,
drumurile rutiere, trotuarele, lacurile, râurile, șinele de tren, pădurea, dar și
elementele de afișare prin prisma cărora s-a realizat interfața 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 dispoziție patru tipuri
distincte de agenți prezentate în (Wilensky, 1999):
turtles care reprezintă agenții inteligenți mobili ce se deplazează în lumea
creată virtual și îndeplinesc diferite roluri sau funcționalități
patch-uri ce simbolizează agenții statici din care este formată lumea virtuală.
Practic, acest tip de agenți sunt ficși în sistemul de axe cartezian pe care
NetLOGO îl folosește ca sistem de referință atât 2D, cât și 3D
link-uri pentru evidențierea legăturilor dintre agenții inteligenți
observer sau agentul inteligent ce urmărește evoluția lumii și a agenților
existenți, îndeplinind rolul de supervizor în cadrul acestei platforme
Modelarea lumii începe prin intermediul patch-urilor, apoi prin adăugarea
agenților ficși ce au de îndeplinit roluri specifice zonei în care sunt amplasați și, în
cele din urmă, a agenților mobili care implementează un anume comportament. Mai
mult, există o legătură foarte strânsă între un agent de tip turtle și patch-ul pe care se
află, acestea având acces direct asupra variabilelor locale declarate, atât pentru citire,
cât și pentru scriere. În plus, orice patch sau orice turtle poate opera cu alte patch-uri
sau turtles, însă nu pot adăuga în mod direct alți agenți. Doar observer-ul sau
supervizorul include și această funcționalitate (Wilensky, 1999).
Totodată, NetLOGO pune la dispoziția utilizatorului interfețe de intrare sau
ieșire precum butoane, slider-e, liste de selecție, elemente pentru plotare sau
monitorizarea unei variabile sau valorii returnate de un reporter și îi permite astfel
acestuia dezvoltarea unei aplicații flexibile și complete prin care se poate opera ușor
cu lumea virtuală creată.
Page 18
15
Modelul pe care îl vom descrie și utiliza în această lucrare este prezentat în
Figura 4.1.
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ă funcționalități izolate ce sunt apoi incluse în aplicația
dezvoltată. Acest lucru permite studierea într-un mediu perfect controlat și izolat a
diverselor funcționalități sau proceduri necesare realizării lumii prezentate. În
continuare vom prezenta aplicațiile acestui Toolkit.
4.2. Prezentarea Toolkit-ului „Custom City Builder”
Toolkit-ul „Custom City Builder” tratează șase funcționalități implementate și îi
permite utilizatorului să le înțeleagă și să le modifice sau îmbunătățească fără 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 conține în mod automat
două proceduri:
procedura setup care realizează operațile necesare creării lumii sau a mediului
de test
procedura go care conține instrucțiunile agenților inteligenți prezenți în model
Figură 4.1. Modelul implementa utilizând platforma de programare NetLOGO
Page 19
16
Acest model este respectat chiar și în cazuri în care agenții nu au de simulat un
comportament inteligent anume. În astfel de cazuri, funcția go doar actualizează
contorul tick-urilor.
Tick-urile reprezintă o metodă de a număra ciclurile de operare, atât în cazul
agenților mobili, cât și în cazul celor ficși. Pentru a realiza această evidență,
procedurii de setup i se adaugă instrucțiunea reset-ticks care aduce contorul la 0, iar în
cadrul procedurii go se adaugă instrucțiunea tick. Acest model propus de (Wilensky,
1999) este recomandat deoarece îi permite utilizatorului să separe instrucțiunile de
generare de cele de rulare sau simulare. Mai mult, aceste valori sunt folosite pentru
actualizarea plotărilor. Astfel, în momentul în care valoarea din contorul ticks se
incrementată, plotările sunt actualizate. Pasul fiecărei incrementări este salvat în
variabila globală, implicită, tick-advance care poate fi setată doar la valori pozitive,
atât întregi, cât și reale. Alegerea acestei valori se face în funcție de fiecare sistem de
multi-agent implementat în parte și se reflectă în principal în rezultatele plotării.
Funcționalitatea aceasta este justificată deoarece NetLOGO permite salvarea
rezultatelor culese prin intermediul plotărilor î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 eșantionare 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
instrucțiunile specificate în procedura repetitivă go, pe când un tick nu este
restricționat la un singur ciclu de operare, în funcție 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 tick-
advance sau se poate implementa ca un ciclu de operare să conțină 2 tick-uri alegându-
se valoarea 2 pentru tick-advance.
Aplicațiile ce aparțin acestui toolkit testează următoarele funcționalități:
generarea unui cartier de clădiri cu drumuri și trotuare aferente unei structuri
matriceale
alocarea unui identificator unic fiecărei clădiri din cartierul generat
setarea unui perimetru de siguranță în jurul unei clădiri, pe baza
identificatorlui specificat
determinarea unei viitoare poziții pe baza unei formule proprii și testarea
acesteia pentru direcții aleatoare sau nu, dar și vizualizarea efectului
procedurii in-cone desenând zona selectată și evidențierea direcțiilor care
formează multiplii de unghiuri drepte cu orientarea curentă
modelarea deplasării unui agent pe un drum orizontal și redresarea acestuia
după perturbare prin translatare în lateral, specificând totodată viteza.
adăugarea de agenți într-o lume cu restricție de populație de tip insulă și
afișarea unui mesaj de eroare la eventuala depășire a limitei de populație.
Page 20
17
4.2.1. Generarea unui cartier de clădiri și pavarea drumurilor aferente
Generarea cartierului de clădiri cu construirea drumurilor și a trotuarelor
aferente unei structuri matriceale este prezentată în fișierul „generare_cartier.nlogo”
din cadrul toolkit-ului și permite modificarea facilă a parametrilor disponibili prin
intermediul elementelor de interfață de tip slider prevăzute în platforma de
programare NetLOGO. Lista completă a acestor parametri este:
start-x ce simbolizează poziția pe axa orizontală din care se începe construirea
primei clădiri
start-y care marchează poziția pe axa verticală pentru inceperea construirii
primei clădiri. De menționat este faptul că acest set de coordonate (start-x,
start-y) marchează colțul din dreapta-sus al primei clădiri construite.
Construirea clădirilor începe tot din partea dreapta-sus a cartierului, linie cu
linie, de la dreapta la stânga
size-x simbolizează numărul de clădiri ce vor fi construite pe orizontala sau
numărul de coloane din din matricea de clădiri
size-y, în mod analog, marchează numărul de linii din matricea de clădiri
marime-clădiri reprezintă latura clădirilor, ce vor fi pătrate
Figura 4.2 arată un exemplu de generare a unui cartier cu număr maxim de
clădiri de dimensiune minimă, pornind din colțul din dreapta-sus al interfeței.
Figură 4.2. Generarea unui cartier cu număr maxim de clădiri de dimensiune minimă
Page 21
18
Algoritmul apelează proceduri distincte; una pentru adăugarea clădirilor și o a
doua pentru construirea drumurilor sau a trotuarelor. Datorită faptului că în
modelul lumii s-au considerat trotuare de lățime 1, construcția acestora s-a realizat
printr-o selecție de patch-uri pentru a micșora timpul de execuție a procedurii setup.
4.2.2. Adăugarea identificatorului unic pentru fiecare clădire în parte
Procedurile prezentate în „alocare_identificator.nlogo” completează generarea
de cartiere prin identificarea în mod unic a fiecărei clădiri în parte. Figura 4.3
exemplifică generarea unui astfel de cartier și, în linia de comandă dar și în textul
ajutător, modificarea culorii unei singure clădiri.
Procedura de generare a clădirilor adaugă fiecare clădire într-o listă denumită
generic „clădiri” ce va conține toate clădirile. NetLOGO indexează aceste liste de la 0,
motiv pentru care la începutul procedurii se determină numărul de elemente din listă
ce va fi folosit ca identificator unic. Astfel se leagă identificatorul de indexul listei și
se asigură că clădirea n are identificatorul n pentru eliminarea eventualelor greșeli.
Un exemplu de instrucțiune care referențiează o anume clădire, dar și efectul
rezultat după executia acesteia este ilustrat în Figura 4.4.
Figură 4.3. Generarea unui cartier cu clădiri identificate în mod unic
Page 22
19
4.2.3. Setarea perimetrului restricționat în jurul unei clădiri
Pentru simularea unui perimetru restricționat, s-a adăugat variabila booleeană
safe, specifică patch-urilor. Aceasta are rolul de a separa zonele sigure de cele nesigure
și va fi folosită de către agenții inteligenți pentru a le resticționa accesul. Agenții
proveniti dintr-o zonă sigură nu vor intra în perimetrul nesigur. Mai mult, cei deja
aflați în perimetrul setat fie vor ieși din acesta (specific agenților inteligenți de tip
rutier), fie vor fi înlocuiți de echipaje de intervenție (specific agenților inteligenți de
tip pieton). Setarea perimetrului restricționat în jurul unei clădiri și evidențierea
acestuia este exemplificată în Figura 4.5.
Figură 4.4. Modificarea clădirii cu identificator 28 prin setarea culorii roșie
Figură 4.5. Exemplu de setare a perimetrului restrictionat pentru cladirea cu identificatorul 12
Page 23
20
4.2.4. Marcarea poziției 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 poziții sau a
unei poziții de interes. Spre exemplu, a fost folosit pentru testarea formulei de
determinare a patch-ului pentru executarea virajului la stânga al agenților inteligenți
de tip rutier. De asemenea, testarea și înțelegerea instrucțiunii in-cone este utilă
pentru agenții care nu sunt restricționați la un drum exact, spre exemplu agenții
inteligenți de tip avion. Instrucțiunea in-cone ar putea fi folosită, așadar, pentru
implementarea radarului necesar evitării accidentelor aeriene. Figura 4.6 oferă un
exemplu de testare pentru această funcție. Ultima funcționalitate, test-directii, este pur
vizuală. Aceasta evidențiează patch-urile care formează o intersecție de drumuri cu
sens unic, de o bandă, în poziția agentului.
Figură 4.6. Testarea instrucțiunii in-cone prin intermediul modelului realizat în toolkit
Page 24
21
De asemenea, Figura 4.7 ilustrează determinarea poziției viitoare, rezultate în
urma virării la stânga a unui agent inteligent de tip rutier, evidențiând în același timp
și drumurile adiacente lui. Se remarcă faptul că direcția de deplasare a agentului s-a
schimbat datorită activării switch-ului „random-heading”. În cazul activării acestuia,
agentul va alege un punct cardinal aleatoriu care va servi ca orientare. Modelul lumii
ce va fi realizat cu ajutorul acestui toolkit nu conține decât drumuri verticale și
orizontale, motiv pentru care s-au ales ca orientări posibile punctele cardinale în
cadrul acestui model de test.
Deși este un model de test cu complexitate și număr 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 testării. Pentru
determinarea acestui patch se folosește procedura patch-at-heading-and-distance
explicată în (Wilensky, 1999). Modificarea formulei de determinare presupune
modificarea parametrilor trimiși acestei proceduri.
Figură 4.7. Afișarea poziției rezultate în urma realizării virajului la stânga pentru un agent orientat spre EST
Page 25
22
4.2.5. Modelarea deplasării și a redresării unui agent mobil
Aplicația de test „redresare_deplasare_agent.nlogo” propune o soluție pentru
modelarea virării cu viteză variabila a agenților mobili. Această problemă apare în
momentul în care agenții mobili pot accelera și decelera, ori pot avea viteze mai mari
decât 1. Pentru un agent, viteza 1 reprezintă avansul în urma unei executări a
procedurii forward. Practic, această procedură deplasează agentul cu numărul
specificat de patch-uri, acest număr putând fi natural, real sau chiar și negativ. În
cazul agenților inteligenți de tip rutier care sunt capabili să accelereze și decelereze,
virarea introduce deplasarea de pe poziția centrală a drumului. Mai multe deplasări
de acest tip pot determina agentul să ajungă în poziții nedorite, motiv pentru care am
decis să tratez această problemă. Soluția prezentată este destinată modelării unui
trafic rutier cu viteze variabile, capabil să accelereze și să frâneze. Modelul lumii
realizat în aplicația dezvoltată pentru această lucrare are implementate aspecte
precum viteză maximă, accelerare, decelerare, distanță de frânare, distanțe între
agenți, indice de virare setate pentru fiecare tip de agent inteligent mobil existent
(oameni, mașini, camioane, autobuze, trenuri și avioane), însă modelarea acestor
mișcări complexe nu face obiectul lucrării și au fost folosite în scopul unor viitoare
îmbunătățiri. De fapt, modelul actual folosește vitezele setate, însă acestea au
valoarea constantă 1 deoarece miscările curbilinii, distanțele dintre agenți,
accelerațile, frânarea și distanțele de frânare nu au fost implementate. Rolul acestei
aplicații de test este de a oferi o soluție și o înțelegere a acestei soluții în scopul unei
viitoare implementări.
Figura 4.8 prezintă interfața generată de aplicația test. Se remarcă faptul că
agentul pornește dintr-o poziție translatată.
Figură 4.8. Interfața aplicației de test pentru redresarea direcției de deplasare a unui agent mobil
Page 26
23
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 poziția centrală în funcție de avansul
setat.
În momentul în care se aplică o perturbație asupra poziției agentului, acesta
este translatat în mod aleatoriu fie în stânga, fie în dreapta, cu o distanță de 0.4 patch-
uri. S-a ales această valoare deoarece alegerea unei valori egale cu 0.5 patch-uri
introduce o ambiguitate în ceea ce privește alegerea poziției de redresare. Pentru
valori mai mari se alege patch-ul de lângă drum. Acest inconvenient se poate corecta
prin setarea unei variabile interne agentului inteligent care să rețină poziția dorită, de
exemplu următoarea poziție din drum sau, în cazul implementării acestei soluții,
poziția la care agentul dorește să ajungă după virare.
De asemenea, poziția la care agentul dorește să ajungă este evidențiată prin
culoarea roșie. Astfel utilizatorului îi este descris întregul proces de redresare și
poate urmări în mod exact etapele prin care acesta se manifestă și dacă apare
fenomenul de depășire, în care agentul iese de pe drumul stabilit datorită vitezei
prea mari ori a translatării prea puternice. Datorită acestui fapt, aplicația de test
permite simularea mai multor scenarii pentru a determina dacă și cât este nevoie ca
agentul mobil să încetinească în momentul efectuării unui viraj, pentru ca acesta să
nu iasă de pe banda dorită. Un exemplu de redresare este oferit în Figura 4.9.
Deși această soluție nu este implementată în modelul lumii realizat în cadrul
lucrării 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ă păstrez modelul de
test în toolkit.
Figură 4.9. Poziția unui agent mobil în urma redresării
Page 27
24
4.2.6. Adăugarea de agenți într-un model cu restricție pe populație
Agenții din modelul lumii realizat sunt restricționați la o anume poziționare.
Spre exemplu, mașinile sunt adăugate doar pe drumuri iar pietonii doar pe trotuare,
motiv pentru care toolkit-ul include aplicația de test „pozitii_disponibile_agenti.nlogo”,
al cărei rol este acela de a-i oferi utilizatorului o soluție pentru adăugarea de agenți
într-un mediu cu restricție a pozițiilor disponibile.
Modelul lumii generat de aplicația test este de tip insulă și conține pământ pe
care agenții pot sta în partea dreaptă-sus și apă în rest. După realizarea acestui model
se adaugă câte 30 de agenți până la detectarea locurilor insuficiente. Figura 4.10
prezintă starea în care se află modelul după adăugarea a 60 de agenți.
Se poate observa cum fiecare poziție din insulă poate fi ocupată de un singur
agent, iar dispunerea acestora este în mod aleatoriu. De asemenea, orientarea
agenților rămâne la valoarea aleatorie stabilită în momentul adăugării. De fapt, după
ce un agent este creat, acesta este mutat pe un patch de tip „pământ” care nu conține
nici un agent. Pentru această funcționalitate se folosesc procedurile count, move-to și
turtles-on împreună cu filtrarea agenților prin operatorul with (Wilensky, 1999).
Figură 4.10. Modelul test în urma adăugării a 60 de agenți
Page 28
25
În momentul în care pe insula nu mai este loc pentru încă 30 de agenți
adăugarea este anulată, iar utilizatorul primește un mesaj infomativ de tip user-
message, după cum se poate observa în Figura 4.11.
Adițional, modelul de test conține o procedură infinită (Wilensky, 1999)
numită „testeaza-patch-ahead” pentru a exemplifica utilizarea agenților prin prisma
altor agenți inteligenți. Procedura alege un agent în mod aleatoriu și îl colorează
verde, iar apoi modifică agentul aflat pe patch-ul din fața agentului curent
schimbându-i culoarea în albastru și orientându-l spre agentul apelant (verde).
Această procedură minimală oferă utilizatorului un exemplu simplu, funcțional și
flexibil de a gestiona agenții din interiorul altor agenți inteligenți.
Figură 4.11. Afișarea mesajului de eroare la depășirea limitei insulei
Page 29
26
4.3. Modelul lumii
Modelul lumii este realizat prin intermediul agenților în NetLOGO. Modelul
actual este constituit din agenți de tip fix numiți patch-uri ce sunt grupați si formează
clădiri, drumuri, trotuare, zone de iarbă, zona dedicată interfeței și elemente de
afișare. Peste acest model se plasează agenții inteligenți de tip pieton, mașină,
autobuz, camion, tren (formați din locomotive, respectiv vagoane) și avion. În acest
subcapitol vom drescrie realizarea modelului lumii prin acești agenți.
4.3.1. Sistemele critice
Sistemele critice existente în aplicația dezvoltată sunt:
aeroportul
gara din afara orașului
gara din oraș
spitalul
centrala nucleară
hidrocentrala
Fiecare sistem critic este format dintr-un set de agenți de tip patch care au
același tip și același identificator în așa fel încât să lucreze ca un tot unitar. Aceste
sisteme sunt salvate în lista cladiri-monitorizate. De asemenea, orice sistem critic este
prevăzut cu o mulțime de senzori ce verifică diverse evenimente sau stări ce pot
caracteriza sistemul. În cadrul țesutului „Protocoale sisteme critice” realizat, senzorii
reprezintă elemente ale mulțimii DP. Mecanismul de inferență folosit în procedura
actualizeaza-monitorizarea verifică senzorii fiecărui element din lista sistemelor critice
și pe baza acestor verificări decide dacă se trece în starea de funcționare sau
nefuncționare și dacă se activează alarma. Acesta reprezintă componentele mulțimii
DC din cadrul celulelor <PUC> implementate. Mecanismul este responsabil și pentru
actualizarea elementelor de afișare ce prezintă starea curentă a acestor sisteme.
Mulțimea DA este constituită din elementele de afișare și metodele prin care deciziile
inferenței sunt reflectate în modelul lumii.
4.3.1.1. Aeroportul
Aeroportul (Figura 4.12) este primul sistem critic
adăugat atât în lista clădirilor afișate, cât și în lista
clădirilor, având identificatorul unic 0 și tipul setat
„aeroport”. Situat în partea stângă-sus a modelului
lumii, acesta este conține un grup de patch-uri care
formează pista de aterizare pentru avioane și un grup
care realizează iluminarea pistei. De asemenea, conține
Figură 4.12. Aeroportul
Page 30
27
senzori pentru detectarea incendiilor, cutremurelor, a penelor de curent și a
amenințărilor teroriste. În plus, este prevăzut cu două șine de tren și un drum ce
facilitează transportul de pasageri.
În cazul în care aeroportul este trecut în starea nefuncțională trenurile aferente
acestuia vor fi oprite pe șine, iar avioanele nu vor mai ateriza, ci vor fi redirecționate
către alt aeroport. Pentru a evidenția această redirecționare, avioanele cărora nu le
este permisă aterizarea sunt colorate roz. Un exemplu pentru aterizare vs.
redirecționare este ilustrat în figura 4.13.
4.3.1.2. Gara din afara orașului
Al doilea sistem critic adăugat și listat este
gara din afara orașului, 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. Conține patru șine
pentru trenuri și un drum care permite traficului
rutier să o viziteze.
Scoaterea din funcționare a acestei gări
implică oprirea tuturor trenurilor și blocarea
întregului trafic feroviar.
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 clădiri,
iar activarea alarmei determină setarea de perimetru restricționat
în oraș, în jurul ei, împreună cu oprirea trenurilor specifice.
Poziționarea acesteia este prezentată în Figura 4.15.
Figură 4.13. Aeroport funcțional (stânga) vs. Aeroport nefuncțional (dreapta)
Figură 4.14. Gara din afara orașului
Figură 4.15. Gara din
oraș
Page 31
28
4.3.1.4. Spitalul
Spitalul nu ocupă o poziție standard în cadrul modelului
lumii. La fiecare executare a procedurii setup, o clădire 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 ușor, spitalul este redesenat ca o cruce roșie
peste un fundal galben, după cum arată Figura 4.16.
4.3.1.5. Centrala nucleară
Centrala nucleară ocupă ante-penultima
poziție în lista clădirilor, fiind situată înaintea
barajului și a hidrocentralei. Tipul este setat ca fiind
„centrala-nucleara”, iar construirea ei este realizată
prin intermediul procedurii de adăugare a unui
cartier. Practic, se adaugă un cartier format dintr-o
singură clădire, de dimensiune 20 (față de
dimensiunea 6 a clădirilor normale). Poziționarea și
aspectul centralei nucleare sunt ilustrate în figura
4.17.
4.3.1.6. Hidrocentrala
Hidrocentrala ocupă ultima poziție
din liste, fiind ultima clădire sau structură
adăugată modelului lumii, având
identificatorul unic de valoare maximă și
tipul setat „hidrocentrala”. În componența
ei intră și barajul, care este o structură
distinctă, însă nemodelată ca fiind un
sistem critic, iar legătura cu restul
modelului lumii se face prin intermediul
unui drum adiacent. Pentru asigurarea
unui efect aspect schematic realist s-au
modelat două lacuri, unul de acumulare și
unul de vărsare, conectate prin intermediul unui râu ce trece prin hidrocentrală. De
fapt, hidrocentrala este formată din două zone distincte, de-o parte și de alta a râului,
ce au același tip și identificator unic. Structura hidrocentralei este vizibilă în Figura
4.18.
Figură 4.16. Spitalul
Figură 4.17. Centrala nucleară
Figură 4.18. Hidrocentrala și barajul
Page 32
29
4.3.2. Agenți implicați în implementarea protocoalelor sistemelor
critice
Agenții implicați în implementarea prtocolalor de urgență pentru sistemele
critice sunt agenții de tip senzor și elementele de afișare, împreună cu agentul
inteligent <PUC> care realizează mecanismul de inferență. Funționalitatea <PUC>
este ilustrată în Figura 4.19.
Țesutul <PUC> („Protocoale de Urgență pentru sisteme Critice”) descris în
(Pătrașcu & Drăgoicea, 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. Agenții de percepție ai mulțimii DP
Agenții care formează mulțimea DP sunt de tip senzor. Un astfel de senzor este
exemplificat în Figura 4.20. Senzorii sunt adăugați sistemelor critice pentru a urmări
o stare sau un eveniment. În mod implicit, senzorii sunt poziționați în mod aleatoriu
peste sistemul critic considerat și sunt ascunși. Afișarea sau ascunderea senzorilor se
poate realiza prin intermediul butonului „arata/ascunde senzori” din interfața grafică.
Figură 4.19. Funcționarea țesutului <PUC>
(Pătrașcu & Drăgoicea, 2013)
Page 33
30
Senzorii conțin următorii parametrii:
id-senzor care conține identificatorul unic
pentru fiecare senzor în parte
cladire-id ce simbolizează identificatorul
clădirii pe care este montat
eveniment-urmarit ce are valori precum
„cutremur”, „incendiu” etc
intensitate; reflectă starea curentă sau
intensitatea evenimentului urmărit î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 când cei responsabili pentru
cutremure conțin valoarea magnitudinii pe
scara Richter la care sistemul este scos din funțiune.
Culoarea unui senzor este aleasă în funcție de culoarea patch-ului pe care este
amplasat, în așa fel încât acesta să poată fi observat ușor în momentul în care este
setat ca fiind vizibil.
4.3.2.2. Agenții incluși în mulțimea DA
Mulțimea DA operează în mod direct cu
agenții de tip element de afișare, modificându-le
culoarea în funcție de datele furnizate de către
mulțimea Dp. Fiecare sistem critic are asociată o
mulțime de elemente de afișare prin care animează
efectele deciziilor luate de către mecanismul de
inferență. În Figura 4.21 se arată cum interfața
arată utilizatorului că sistemul critic Aeroport nu
mai este funcțional datorită detectării unui
cutremur ce depășeste magnitudinea prag. De
asemenea, se remarcă faptul că alarma nu a fost
declanșată deoarece acest eveniment nu
presupune intervenția forțelor speciale, spre
deosebire de un incendiu sau o amenințare
teroristă.
Figură 4.20. Un element de tip senzor
Figură 4.21. Elementele de afișare
responsabile pentru sistemul critic
Aeroport
Page 34
31
De fapt, mulțimea DA este constituită din implementarea protocoalelor
sistemelor critice și nu din agenți de tip element de afișare. Mulțimea operează cu
aceștia deoarece ei reflectă diferitele implementări, în funcție de evenimente.
Elemente ale mulțimii DA sunt protocoale precum:
scoaterea din funcționare 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ă acțiunea
forțelor de intervenție. Astfel de evenimente sunt incendiul, amenințarea
teroristă sau jaful
oprirea funționării aeroportului și a gărilor în prezența cutremurelor de
magnitudine cel puțin egală cu 4 grade pe scara Richter
trecerea în regim nefuncțional a centralei nucleare la detectarea cutremurelor
de magnitudine mai mare sau egală cu 5.5 grade pe scara Richter
scoaterea din funcționare a hidrocentralei pentru cutremure de magnitudine 5
oprirea spitalului în timpul cutremurelor de cel puțin 6 grade
oprirea trenurilor în momentul în care gara aferentă este scoasă din regimul
de funcționare
redirecționarea traficului aerian către alt aeroport în cazul nefuncționării
aeroportului
evacuarea orașului în momentul în care se activează alarma pentru toate
clădirile urbane
blocarea drumului în urma prăbușirii unui avion
activarea alarmei datorită incendiului rezultat în urma prăbușirii avionului
În modelul realizat blocarea străzilor se realizează prin setarea lor ca fiind
nesigure și evidențierea prin culoarea roșie. În cazul lumii reale, această
implementare s-are realiza prin intermediul echipajelor de poliție. Acestea ar fi
responsabile pentru setarea perimetrului și blocarea drumurilor.
4.3.2.3. Agenții de control ai mulțimii DC
În componența mulțimii DC intră mecanismul de inferență și baza de reguli
considerată. Mecanismul de inferență este implementat prin intermediul unei
proceduri ce acționează în funcție de baza de reguli implementată. Astfel, pentru
fiecare sistem critic în parte se verifică informația provenită din partea senzorilor și
se decide dacă asupra sistemului critic acționează evenimente sau hazarde. Mai mult,
în funcție de numărul și tipul hazardelor dedectate se decide scoaterea din
funcționare 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 aplicației dezvoltate.
Page 35
32
4.3.3. Agenții inteligenți mobili
Modelarea comportamentului agenților mobili existenți s-a realizat clasificarea
acestora în funcție de categoria de trafic din care fac parte. Astfel au rezultat
următoarele categorii:
pietoni
categoria rutieră, ce conține mașinile, autobuzele și camioanele
categoria feroviara pentru trenuri
categoria aeriană pentru avioane
Agenții inteligenți mobili, cu excepția trenurilor, au comportamenul simulat
cu ajutorul a două proceduri distincte:
procedura orienteaza-agenți, care orientează agenții inteligenți în funcție de
pozițiile posibile și sigure
procedura misca-agenti care efectuează deplasarea acestora în direcția rezultată
din procedura de orientare
Figură 4.22. Implementarea în pseudocod a mecanismului de inferență pentru sistemele critice
Page 36
33
4.3.3.1. Pietonii
Pietonii au un comportament limitat, modelul
neavând treceri de pietoni sau semafoare. În
consecință, pietoni se deplasează pe trotuarele din
jurul clădirilor, schimbând în mod aleatoriu direcția
în momentul în care urmează să iasă de pe trotuar.
Numărul de pietoni din jurul fiecărei clădiri este
alocat aleatori, bazându-se pe selecția patch-urilor
libere de tip „trotuar”. Un exemplu de dispunere a
pietonilor pe trotuarul din jurul unei clădiri este
prezentat în Figura 4.23.
4.3.3.2. Agenții inteligenți din categoria rutieră
În cazul agenților inteligenți de tip mașină,
autobuz și camion a fost necesară dezvoltarea unei
proceduri de orientare mai complicate datorită
nevoii să se respecte un minimum de reguli de
circulație. După adăugarea pe șosea, acești agenți
sunt orientați în direcția dictată de drum printr-o
procedură specială de apelată de setup. În rest,
orientarea se face pe baza scanării patch-urilor care
marchează pozițiile rezultate în urma ieșirii din
intersecție prin deplasare înainte (galben), virare la
stânga (mov) sau virare la dreapta (roz), după cum
sunt marcate în Figura 4.24.
Adițional acestei condiții de orientare, agenții inteligenți din categoria rutieră
sunt condiționați și la înaintare pentru a întoarce în momentul în care ajung într-o
înfundătură. De asemenea, un agent va înainta doar dacă poziția dorită este liberă.
Mai mult, odată aleasă direcția dorită, agenții inteligenți din categoria rutieră o
păstrează timp de două cicluri, în cazul în care poziția este ocupată de către un alt
agent rutier. De menționat este faptul că mașinile își schimbă orientarea în funcție de
direcția de mers aleasă, roțile fiind pe partea trotuarelor.
Comportamentul simulat de către agenții inteligenți rutieri permite
modificarea modelului lumii prin adăugarea sau eliminarea de drumuri fără a fi
nevoie să se intervină la nivel de agent sau intersecție. Practic, dacă un drum este
sigur, acesta va fi străbătut de agenții rutieri. De asemenea, implementarea aceasta
permite simularea evacuării orașului, deoarece agenții 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, permițând totodată formarea de cozi pentru evacuarea orașului.
Figură 4.23. Pietonii din jurul unei
clădiri
Figură 4.24. Direcțiile verificate de
către agenții rutieri
Page 37
34
4.3.3.3. Agenții inteligenți de tip tren
Agenții inteligenți de tip tren sunt organizați la nivel de ansamblu și nu la
nivel de locomotivă sau vagon, după cum este prezentat în Figura 4.25. În momentul
adăugării trenurilor, acestea sunt formate în totalitate din vagoane. Apoi se
determină în mod automat primul, respectiv ultimul vagon al fiecărui tren iar acestea
sunt modificate în locomotive.
Asemenea trenurilor din lumea reală, agenții inteligenți staționează în
momentul în care ajung în stațiile aflate de la capetele de șină. Practic, locomivele
verifică dacă trenul poate avansa cu viteza setată, în direcția setată. Direcția este
precizată prin specificarea unei viteze pozitive sau negative. În cazul în care
locomotivele unui tren verifică existența șinei în poziția viitoare, trenul este avansat.
Altfel, s-a ajuns în stație și trenurile staționează. Fiecare agent inteligent de tip tren
are un cuplu de variabile proprii, timp-stationare, respectiv timp-ajuns-gara, care îî
permit staționarea. Datorită acestui fapt, fiecare tren poate avea un timp propriu de
staționare în gară. În mod implicit, toate trenurile staționează 2 secunde, dar valoarea
aceasta se poate modifica pentru fiecare tren în parte, din linia de comandă setând
variabila timp-stationare.
4.3.3.4. Agenții inteligenți de tip avion
Agenții inteligenți de tip avion (Figura 4.26) zboară
deasupra modelului lumii și aterizează dacă aeroportul
este funcțional, ori sunt redirecționați altfel. Avioanele
cunosc altitudinea maximă și altitudinea actuală, folosind-
o pe cea din urmă atât pentru aterizare, cât și pentru
prăbușire. În momentul prăbușirii avionul intră în vrie pe
partea stângă, efectul principal al prăbușirii fiind incediul
și ruperea copacilor sau deteriorarea carosabilului, în
funcție de locul în care acesta se prăbușește. Utilizatorul
alege intrarea în vrie prin intermediul butonului special
din interfață numit generic „prabuseste avionul”.
Figură 4.25. Trenurile care circulă pe ruta Aeroport-Gară periferie, aflate în mișcare
Figură 4.26. Agent inteligent de
tip avion
Page 38
35
4.4. Scenarii de simulare
Înainte de simulare, vom prezenta componentele intefeței realizate, după cum
sunt evidențiate în Figura 4.27.
Interfața grafică este împărțită în cinci zone distincte după cum urmează:
zona pentru setarea lumii (galben), prin care putem alege numărul de agenți
inteligenți și tipul acestora. De asemenea, de aici putem arăta sau ascunde
senzorii specifici fiecărui sistem critic. Tot aici se regăsesc butoanele pentru
rularea simulării (butonul go), dar și pentru micșorarea numărului 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
adăugarea de evenimente sub forma de incendii, amenințări, pană de curent
sau jafuri în mod izolat pentru fiecare sistem critic în parte. În plus, zona
permite setarea perimetrului de siguranță atât pentru un spațiu restrâns
(clădire), cât și pentru întreg orașul sau chiar pentru toate structurile din
model, dar și anularea tuturor evenimentelor
zona modelului lumii (roșu) în care agenții inteligenți reacționează la
evenimentele adăugate
zona cu elemente statistice (albastru) precum graficele care urmăresc
autovehiculele, cât și numărul agenților inteligenți de tip rutier prezenți în
oraș, dar și timpul efectiv de execuție al modelului
zona de monitorizare (roz) în care regăsim agenții de tip elemente de afișare
responsabili pentru reflectarea stărilor actuale ale tuturor sistemelor critice din
modelul lumii, fiecare putând avea evenimente distincte de urmărit.
Figură 4.27. Evidențierea zonelor componente ale interfeței realizate
Page 39
36
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 simulării sunt ilustrate în Figura 4.28, împreună cu animația miscării
pământului ce are rolul de a evidenția magnitudinea setată.
Se remarcă următoarele consecințe:
autovehiculele și oamenii s-au oprit datorită magnitudinii de peste 4 grade.
Graficele evidențiează oprirea tuturor autovehiculelor, indiferent de poziția în
care se află, motiv pentru care toate trec în staționare iar graficul responsabil
cu urmărirea numărului total de autovehicule aflate în oraș rămâne constant
aeroportul, garile și hidrocentrala sunt scoase din funcționare având
intensitățile prag pentru cutremur sub valoarea setată (4, 4, respectiv 5 grade
Richter)
centrala nucleară și spitalul încă funcționează deoarece magnitudinea
cutremurului încă nu le-a depășit valorile prag de 5.5, respectiv 6 grade
în urma opririi aeroportului, avioanele nu vor mai ateriza și vor fi
redirecționate către un alt aeroport. Refuzul permisiunii de aterizare este
simbolizat prin modificarea culorii fiecărui avion în parte
trenurile sunt oprite atât din motivul opririi gărilor, cât și datorită
mecanismului propriu de siguranță pentru a nu deraia
Figură 4.28. Simularea unui cutremur de 5 grade pe scara Richter
Page 40
37
4.4.2. Scenariul 2: Izbucnirea unui incendiu în spital
Din zona de evenimente se selectează din listele de tip chooser „cladire-
eveniment” opțiunea „Spitalul”, respectiv din „eveniment-selectat” opțiunea „incendiu”.
Apoi se apasă pe butonul „Aplica” pentru a adăuga evenimentul de izbucnire a unui
incendiu în spital. Figura 4.29 prezintă rezultatele scenariului.
Se constată:
scoaterea spitalului din starea de funcționare, cauza fiind vizibilă datorită
elementelor de afișare; senzorii au detectat un incendiu
activarea alarmei și, implicit, restictionarea primetrului din jurul spitalului în
scopul de a facilita eventualele echipaje de intervenție chemate de țesutul
„Intervenție echipaje de urgență”
pietonii din jurul spitalului au fost înlocuiți de echipaje de intervenție pentru a
simboliza necesitatea și prezența acestora
autovehiculele nu intră în perimetrul restricționat din jurul spitalului
trenurile, avioanele și restul agenților inteligenți ce nu interacționează cu zona
spitalului nu sunt afectați de acest eveniment deoarece el este de tip local
Figură 4.29. Simularea izbucnirii unui incendiu în sistemul critic Spital
Page 41
38
4.4.3. Scenariul 3: Prăbușirea avionului
Prăbușirea avionului este activată de către utilizator; acesta intră în vrie din
momentul în care utilizatorul apasă butonul aferent din zona evenimentelor a
interfeței grafice. În funcție de locul în care avionul atinge pământul, se identifică
următoarele posibile efecte directe:
lovirea unei clădiri sau a unui sistem critic determină incendierea acestuia și
activarea senzorilor și a stărilor aferente
prăbușirea pe sau în jurul unui drum duce la stricarea drumului și setarea
zonei respective a acestuia ca fiind nesigură
picajul în pădurea existentă determină ruperea și distrugerea copacilor din
zona afectată
În funcție de zona producerii catastrofei, aceste efecte pot fi singulare sau pot
fi combinate. Exemple de prăbușire ale avioanelor sunt prezente în Figura 4.30.
Efectele prăbușirii avioanelor în zone diferite, prezentate în figură sunt:
incendierea unei clădiri în urma lovirii avionului
stricarea drumului dintre hidrocentrală și centrala-nucleară
ruperea copacilor din pădure, cei situați sub hidrocentrală
prăbușirea avionului în lac nu produce nici un efect
Figură 4.30. Exemplificarea efectelor rezultate în urma prăbușirii avioanelor
Page 42
39
4.4.4. Scenariul 4: Amenințarea cu bombă a gării din oraș
Figura 4.31 ilustrează în mod 3D efectele adăugării unui eveniment de tip
amenințare 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.
Figura evidențiează următoarele consecințe:
activarea alarmei pentru gara din oraș și setarea perimetrului restricționat, ce
implică și scoaterea acesteia din funcționare, chiar dacă agenții de tip element
de afișare nu sunt vizibili din perspectiva aleasă
oprirea trenurilor aferente gării din oraș, indiferent de poziția în care sunt
surprinse
evitarea drumurilor setate ca fiind nesigure din partea autovehiculelor din
zona afectată
înlocuirea agenților inteligenți de tip pieton cu agenți de tip echipaj de
intervenție
oprirea agenților inteligenți de tip pieton în momentul în care aceștia întâlnesc
perimetrul restricționat și, astfel, simularea formării mulțimii de spectatori
îngreunarea traficului local datorită anulării rutelor din jurul gării și obligării
agenților de tip autovehicul să se întoarcă pe același drum
Figură 4.31. Ilustrarea 3D a efectelor amenințării gării din interiorul orașului cu bombă
Page 43
40
4.4.5. Scenariul 5: Intrarea Aeroportului într-o pană de curent
În cazul intrării sistemului critic Aeroport într-o pană de curent, acesta este
trecut în mod automat în modul nefuncțional, iar avioanele ajunse nu vor mai
ateriza, ci vor fi redirecționate către alt aeroport. Refuzul aterizării este evidențiat
prin schimbarea culorii avioanelor în roz.
De asemenea, Figura 4.32 evidențiează neafectarea traficului în urma acestui
eveniment. Acest lucru se datorează faptului că pana de curent nu pune în pericol
siguranța conducătorilor auto și nu necesită echipaje de intervenție, ci doar
rezolvarea problemei care a dus la pana de curent resimțită. Mai mult, perspectiva
3D aleasă reușește să ilustreze zborul avioanelor peste modelul lumii.
De asemenea, figura permite vizualizarea pădurii și a organizării geografice
implementate în model și a pomilor plasați de-o parte și de alta a drumurilor și
clădirilor izolate sau aflate la periferia orașului.
Figură 4.31. Urmările intrării aeroportului într-o pană de curent
Page 44
41
4.4.6. Scenariul 6: Evacuarea orașului
Alegând setarea perimetrului pentru toate clădirile din oraș se realizează, de
fapt, simularea evacuării orașului și punerea acestuia sub carantină. Evacuarea
determiă autovehiculele să formeze cozi pentru a putea ieși din oraș, așa cum este
exemplificat și în Figura 4.32.
În plus, datorită activării alarmelor, sistemele critice poziționate în oraș, cum
ar fi spitalul sau gara, vor trece în nefuncțioare și vor avea activă starea de alarmă,
după cum se poate observa în Figura 4.33.
Figură 4.32. Ilustrarea evacuării și punerii orașului în carantină, evidențiând totodată formarea
de cozi de autovehicule ce vor să iasă din oraș
Figură 4.33. Stările evidențiate de către elementele de afișare în urma evacuării orașului
Page 45
42
5. Concluzii
În lucrarea de față am implementat țesutul „Protocoale Sisteme Critice” al
arhitecturii CitySCAPE prin intermediul unui sistem multi-agent, utilizând platforma
orientată-agent NetLOGO. De asemenea, aplicația dezvoltată vine însoțită de un
toolkit propriu prin care se pot adăuga și testa funcționalități noi sau deja
implementate. Modelul lumii include agenți inteligenți care redau comportamentul
traficului rutier, feroviar și aerian, și evidențiează efectul realizat asupra populației
urbane și extra-urbane, rezultat în urma aplicării protocoalelor sistemelor critice la
nivel macroscopic.
Modelul realizat este flexibil, pemițând modificarea rapidă a modelului lumii
cu ajutorul procedurilor specializate în construirea drumurilor și a cartierelor, în așa
fel încât să poată implementa și testa multiple infrastructuri propuse sau deja
existente. Se poate modifica chiar și mărimea interfeței cu ajutorul modificării
fișierului de configurație.
Deși nu au făcut obiectul lucrării de față, aplicația înglobează multipli
parametri ce pot fi utilizați pentru modelarea comportamentului agenților inteligenți.
Astfel de parametri, precum viteza, indicii de accelerație și decelerație, distanțele de
frânare, distanțele dintre agenți, dar și indici de virare, pot fi stabiliți atât pentru o
întreagă categorie, cât și pentru fiecare agent inteligent în parte, realizând astfel
tipuri specifice fiecărei categorii. Spre exemplu, o asemenea setare individuală
aplicată mașinilor ar putea modela un șofer grăbit sau un vârstnic, introducând astfel
noi capabilități modelului.
Prin intermediul studiului de caz, am demonstrat utilitatea și eficiența
aplicării de protocoale ale sistemelor critice în scopul obținerii unui mediu citadin
mai sigur și mai flexibil, capabil să gestioneze hazardele și catastrofele la care este
vulnerabil, în scopul minimizări pagubelor înregistrate. De menționat este faptul că
aplicația dezvoltată permite atât simulări constituite dintr-un singur hazard, cât și
din scenarii în care apar două sau chiar mai multe hazarde, cum ar fi izbucnirea unui
incendiu urmată de un cutremur, și așa mai departe, urmărind astfel eficiența acestor
protocoale în momente cruciale.
Page 46
43
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 ( one-
of 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 )
[
Page 47
44
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 mișcare a agenților inteligenți 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"))
Page 48
45
[
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 patch-
ahead ( 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 următoarei clădiri de adăugat
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 size-
y 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 ))
Page 49
46
; 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-y-
cladiri 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 ))
[
Page 50
47
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
Page 51
48
Procedura care setează perimetrul resticționat 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 = id-
cladire-tinta ]
[
set intensitate 1
]
end
Procedura care setează interfața, adaugând senzorii și
elementele de afișare 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 gara-
periferie ) "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 centrala-
nucleara ) "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" ]
Page 52
49
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 adăugare 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 ) cladiri-
monitorizate
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 ( timer-
running / 60 ) " minute si " floor ( timer-running mod 60 ) " secunde ")
end
Page 53
50
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 multi-
camera visual surveillance, Pattern Recognition, vol. 37, Elsevier, pg. 675-689, ISSN 0031-
3203
Nguyen Q.T., Bouju A., Estraillier P., 2012, Multi-agent arhitecture with space-
time 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
Pătrașcu M., Drăgoicea 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-720-
490-5
Teahan W.J., 2010, Artificial Intelligence – Agents and Environments, Ventus
Plblishing ApS, ISBN 978-87-7681-528-8