LUCRARE DE LICENȚĂ Managementul situațiilor de urgență...

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

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

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

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.

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

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

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

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


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


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


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.

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


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)


Figură 3.3. Structura eSCAPE


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.

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

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.

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ă.

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

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.

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ă

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

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

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

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

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

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

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

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

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

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ș

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

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>


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

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.

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

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

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

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

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

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

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

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ă

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

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

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.

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 )

[

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"))

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 ))

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 ))

[

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

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" ]

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"


adauga-senzori-monitorizare ( [id] of one-of gara-oras ) [ "alarma"


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

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

LUCRARE DE LICENȚĂ Managementul situațiilor de urgență...

Documents

Transcript of LUCRARE DE LICENȚĂ Managementul situațiilor de urgență...