Universitatea Politehnica 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 mezoscopic:

Intervenția echipajelor de urgență

Absolvent Alexandru Nica

Coordonator Ș.L.Dr.Ing. Monica Pătrașcu

Bucureşti, 2013

2

CUPRINS

INTRODUCERE ...................................................................................................................................4

1 AGENȚI ȘI SISTEME MULTI-AGENT .......................................................................................6

1.1 O scurtă istorie a agenților .............................................................................................................6

1.2 Definiția agenților ..........................................................................................................................7

1.3 Tipuri de agenți ..............................................................................................................................7

1.4 Sisteme multi-agent .....................................................................................................................10

2 SISTEME MULTI-AGENT UTILIZATE ÎN MANAGEMENTUL SITUAȚIILOR DE URGENȚĂ ...........................................................................................................................................13

2.1 Conceptul de oraș inteligent ........................................................................................................13

2.2 Arhitectura CitySCAPE ..............................................................................................................14

2.3 eScape ...........................................................................................................................................15

3 STUDIU DE CAZ ............................................................................................................................17

3.1 Programarea orientată agent ........................................................................................................17

3.2 Mediul de programare: NetLogo .................................................................................................18

3.3 Aplicația .......................................................................................................................................18

3.3.1 Descrierea aplicației ...............................................................................................................18

3.3.2 Modelul lumii ........................................................................................................................20

3.3.3 Sistemul multi-agent de control al traficului .........................................................................20

3.3.4 Agentul dispecer ....................................................................................................................22

3.3.5 Agenții de control al intersecției ...........................................................................................23

3.4 Scenarii de test .............................................................................................................................25

3.5 Instrumente folosite .....................................................................................................................26

3.5.1 Butoane .................................................................................................................................26

3.5.2 Elemente de tip Slide-Bar .....................................................................................................27

3.5.3 Monitoarele ...........................................................................................................................27

3

3.6 Rezultate ......................................................................................................................................28

3.6.1 Scenariul 1 – Intervenția unui singur echipaj ........................................................................28

3.6.2 Scenariul 2 – Intervenția a câte unui echipaj din fiecare categorie ........................................30

3.6.3 Scenariul 3 – Intervenția tuturor echipajelor de intervenție din fiecare categorie .................33

4 Concluzii .............................................................................................................................................37

5 Anexe ..................................................................................................................................................38

5.1 Anexa A – Procedura „setUpEnv” ...............................................................................................38

5.2 Anexa B – Procedura „simulate” ..................................................................................................40

BIBLIOGRAFIE ..................................................................................................................................46

4

INTRODUCERE

Conglomeratele urbane sunt în continuă expansiune într-o viziune a orașelor viitorului (Smart City), atât infrastructura, cât și numărul automobilelor, începând din ultimele două decenii, au crescut în mod semnificativ. O dată cu numărul mare de autovehicule, apare și problema dirijării traficului în cazul situațiilor de urgență. Astfel, a apărut necesitatea tratării, în cadrul acestei lucrări, a măsurilor de management al traficului după producerea unui seism sau a unui alt tip de hazard.

Scopul principal al acestei lucrări este modelarea unui sistem multi-agent care să

asigure un răspuns rapid al echipajelor de intervenție (pompieri, poliție, ambulanță) în situații de urgență și totodată să se mențină un flux relativ constant al traficului, reducându-se astfel numărul victimelor și a pagubelor materiale.

Pentru a înțelege modelul implementat, este necesară mai întâi o însușire a conceptului

de agent, elementul de bază într-un sistem multi-agent. Prezentarea unei scurte istorii a agenților în capitolul 1, împreună cu definirea conceptului de agent și a diferitelor tipuri de agenți, ajută la formarea unei imagini generale asupra agenților și, împreună cu informațiile legate de sistemele multi-agent, asigură baza pentru înțelegerea acestui model.

În capitolul 2 sunt prezentate scurte informații legate de conceptul de oraș inteligent

(Smart City) unde sunt des utilizate sistemele multi-agent. Mai sunt prezentate și informații cu privire la arhitectura CitySCAPE, în special sistemul eSCAPE, două dintre țesuturile componente ale acestuia fiind modelate în cadrul acestei lucrări.

Studiul de caz din capitolul 3 prezintă implementarea aplicației, programul și limbajul

utilizat, instrumentele folosite cât și alte informații relevante legate de implementare. Mai sunt prezentate componente ale aplicației, în special interfața, și funcționalitatea acesteia. Tot

5

aici se va face o prezentare a scenariilor de simulare posibile și comportamentul sistemului multi-agent implementat. În final, capitolul 4, conține concluziile.

6

CAPITOLUL 1

1 AGENȚI ȘI SISTEME MULTI-AGENT

1.1 O scurtă istorie a agenților

Din totdeauna, oamenii au fost fascinați de ideea unei entități neumane. Noțiuni populare despre androizi, humanoizi, roboți și alte creaturi din romane științifico-fantastice au pătruns în cultura noastră, formând fundalul inconștient față de care sunt percepuți agenții.

Conceptul de agent poate fi urmărit înapoi la primele zile de cercetare în inteligența artificială distribuită în anii ’70 făcut de Carl Hewitt asupra modelului actor. Acesta a propus conceptul de un obiect de sine stătător, interactiv și în același timp, de executare, pe care l-a numit actor.

Un actor „este un agent de calcul, care are o adresă e-mail și un comportament. Actorii comunică prin pasare de mesaje și efectuează simultan acțiunile lor” (Hewitt, 1977). Acest obiect a avut o stare internă încapsulată și putea raspunde la mesaje de la alte obiecte similare. Multe dintre ideile introduse în modelul actor sunt acum consacrate și aplicate în sistemele agent. În linii mari, cercetarea privind agenții poate fi împărțită în două fire cronologice principale: primul se întinde pe perioada 1977 până în ziua curentă, iar cel de-al doilea din 1990 până în ziua curentă. Primul fir s-a ocupat cu studiul agenților inteligenți, mai exact asupra comunicării între agenți, descompunerea și distribuirea sarcinilor, coordonare și cooperare, rezolvarea conflictelor prin negociere, etc. Scopul principal a fost de a specifica, analiza, proiecta și integra sisteme compuse din mai mulți agenți de colaborare.

7

Din 1990, un alt fir distinct apare exact pe munca de cercetare și dezvoltare a agenților software, gama de tipuri de agenți investigate devenind mult mai largă. Deși acest fir de cercetare se ocupă cu studiul altei componente tot apar unele suprapuneri privind tipologii generale asupra agenților.

1.2 Definiția agenților

A da o definiție pentru cuvântul agent este destul de dificil. În mare se pot identifica două motive din cauza cărora este dificilă o definire precisă a ceea ce este un agent. În primul rând, cercetătorii din domeniul agenților nu omit atribuirea unui înțeles asemănător cu cel folosit să definească agenții de turism sau agenții imobiliari. În al doilea rând el este de fapt un termen paravan pentru domeniul de cercetare și dezvoltare. Cuvântul agent mai este folosit și ca sinonim pentru softbots (roboți software), taskbots (roboți axați pe rezolvarea sarcinilor), roboți, agenți autonomi și asistenți personali. Apariția atâtora sinonime este datorată rolurilor multiple pe care le poate juca. Mai mult, din cauza multitudinii de roluri pe care agenții îl pot juca, există acum o serie de adjective care preced cuvântul agent, după cum se poate observa și în clasificarea agenților realizată de Kingis în 1995: agenți de căutare, agenți de dezvoltare, agenți de analiză, agenți de testare, agenți de ambalare și agenți de ajutor. (Hyacinth, 1996) Hyacinth (Hyacinth, 1996) a definit un agent referindu-se la o componentă software sau hardware care este capabilă să acționeze în mod corespunzător pentru a îndeplini sarcini „în numele” utilizatorului său.

1.3 Tipuri de agenți

În această secțiune scopul principal va fi plasarea agenților existenți în diferite clase de agenți prin investigarea diferitelor tipologii de agenți. O tipologie se referă la studiul științific al trăsăturilor tipice sau a relațiilor dintre diverse tipuri de entități.

În primul rând, agenții pot fi clasificați în funcție de mobilitate lor, mai exact prin capacitatea lor de a se deplasa în unele rețele, de aceea putem identifica agenții ca fiind mobili sau statici.

8

În al doilea rând, agenții pot fi clasificați ca fiind deliberativi sau reactivi. Agenții deliberativi derivă din paradigma de gândire deliberativă: agenții posedă un model intern simbolic, raționament și se angajează în planificări și negocieri, cu scopul de a realiza o coordonare cu alți agenți. Studii asupra agenților reactivi provin din cercetări efectuate de către Brooks în 1986 și Agre & Chapman în 1987. Acești agenți nu au modele interne, simbolice ale mediului lor și acționează cu ajutorul unui stimul / răspuns de tip comportament pentru a răspunde la starea actuală a mediului în care sunt încorporați (Ferber, 1994). Într-adevăr, Brooks a susținut că un comportament inteligent poate fi realizat fără un fel de reprezentări explicite, simbolice reprezentărilor tradiționale ale inteligenței artificiale (Brooks, 1991).

În al treilea rând, agenții pot fi clasificați în funcție de mai multe atribute ideale și

primare pe care ar trebuie să le prezinte. Din aceste atribute se pot identifica: autonomia, învățarea și colaborarea. Autonomia se referă la principiul că agenții pot opera pe cont propriu fără a fi nevoie de orientare umană, chiar dacă acest lucru nu ar fi uneori valoros. Prin urmare, agenții au stări interne individuale și obiective, și acționează în așa fel încât să își îndeplinească obiectivele în numele utilizatorului. Un element-cheie al autonomiei lor este proactivitate lor, și anume capacitatea acestora de a lua inițiativă, decat să acționeaze mai degrabă ca un răspuns la mediul lor (Wooldridge & Jennings, 1995). Cooperarea cu alți agenți este extrem de importantă: acesta este motivul pentru a avea mai mulți agenți, spre deosebire de a avea doar unul. În scopul de a coopera, agenții trebuie să posede o capacitate socială, și anume capacitatea de a interacționa cu alți agenți și, eventual, cu omul prin intermediul unui limbaj de comunicare (Wooldridge & Jennings, 1995). Este totuși posibil ca agenții să-și coordoneze acțiunile fără a coopera (Nwana et al., 1996). În cele din urmă, pentru ca sistemele de agenți să fie cu adevărat inteligente, aceștia ar trebui să învețe cum să reacționeze și / sau să interacționeze cu mediul lor extern. Agenții sunt (sau ar trebui să fie) văzuți ca biți de inteligență. Deși inteligența poate fi definită în multe feluri, cel mai potrivit ar fi să fie văzută ca un atribut cheie al oricărei ființe inteligente manifestată prin capacitatea sa de a învăța. Capacitatea de a învăța a crescut o dată cu îmbunătățirea performanțelor. Prin aceste 3 atribute se poate observa din figura 1.1 modul în care se pot obține patru tipuri de agenți: agenți de colaborare, agenți de învățare prin colaborare, agenți de interfață și agenți inteligenți.

9

Figura 1.1 – O imagine parțială a tipologiei unui agent (Hyacinth, 1996)

Aceste distincții nu sunt definitive. De exemplu, cu agenții de colaborare, se pune mai

mult accent pe cooperare și pe autonomie decât pe învățare, prin urmare, nu implică faptul că agenții de colaborare nu învață niciodată. De asemenea, pentru agenții de interfață, se pune mai mult accent pe autonomie și pe învățare decât pe cooperare. Nu se consideră nimic din ce se află în afara zonei de intersecție ca fiind un agent. De exemplu, cele mai multe sisteme experte sunt în mare parte autonome, dar, de obicei, ele nu cooperează sau nu învață. În mod ideal, agenții ar trebui să facă toate cele trei atribute la fel de bine, dar acest lucru este mai mult o aspirație și va dura până va deveni o realitate. Agenții cu adevărat inteligenți nu există încă: într-adevăr, așa cum Maes în 1995 notează „actualii agenți disponibili în comerț abia iși justifică numele, dar atributul de inteligent” (Foner, 1993). Deși el a scris acest lucru în 1993, acest lucru se aplică și astăzi:

"... I find little justification for most of the commercial offerings that call themselves

agents. Most of them tend to excessively anthromomorphize the software, and then conclude that it must be an agent because of that very anthropomorphization, while simultaneously failing to provide any sort of discourse or "social contract" between the user and the agent. Most are barely autonomous, unless a regularly-scheduled batch job counts. Many do not degrade gracefully, and therefore do not inspire enough trust to justify more than trivial delegation and its concomitant risks" (Foner, 1993)

În al patrulea rând, agenții pot fi, uneori, clasificați în funcție de rolurile lor (de

preferat, în cazul în care rolurile sunt cele mai importante), de exemplu, World Wide Web (WWW), agenți de informare. Această categorie de agenți exploatează, de obicei, motoarele de căutare pe internet, cum ar fi WebCrawlers, Lycos și Spiders. În esență, agenții ajută la gestionarea unei cantități mari de informații din rețelele de arie largă, cum ar fi internetul.

10

Acești agenți de informare se mai pot numi și agenți internet. La rândul lor, agenții de informare pot fi statici, mobili sau deliberativi. (Hyacinth, 1996)

În al cincilea rând poate fi adaugată și categoria de agenți hibrid care combină două sau mai multe tipologii agent într-un singur agent.

Lista următoare acoperă majoritatea tipurilor de agenți investigați până în prezent. Am

exclus agenții de învățare prin colaborare, a se vedea figura 1.1, pe motiv că nu se știu multe de existența agenților care colaborează și învață dar nu sunt autonomi. Prin urmare se pot identifica șapte tipuri de agenți:

- agenți de colaborare - agenți de interfață; - agenți mobili; - agenți de informare / agenți internet; - agenți reactivi; - agenți hibrid; - agenți inteligenți.

Există unele aplicații care combină agenții din două sau mai multe categorii, și ne

referim la acestea ca sisteme agent eterogene. Astfel de aplicații există deja, chiar dacă acestea sunt relativ puține.

Un alt aspect de notat este că agenții nu trebuie să fie binevoitori unul cu celălalt. Este

foarte posibil ca agenții să fie în competiție unul cu celălalt sau poate chiar antagonic față de celălalt.

1.4 Sisteme multi-agent Un sistem multi-agent este un sistem informatic compus din mai mulți agenți inteligenți ce interacționează într-un mediu. Sistemele multi-agent pot fi folosite pentru a rezolva probleme care sunt dificile pentru un singur agent sau pentru un sistem monolitic. Inteligența sistemului poate fi furnizată prin intermediul unor metode, funcții, proceduri sau algoritmi de căutare sau printr-o abordare de căutare și prelucrare.

11

În mod normal componentele dintr-un sistem multi-agent sunt agenții software, dar sunt și sisteme multi-agent în care agenții software sunt înlocuiți de roboți, oameni sau echipe de oameni. Un sistem multi-agent poate chiar să conțină o combinație om-agent.

Agenții pot fi împărțiti în diferite tipuri: • Agenți pasivi sau agenți fără obiective (cum ar fi obstacole, copaci sau obiecte în orice

simulare simplă); • Agenți activi, cu obiective simple (cum ar fi păsări în stoluri, sau lupii și oile din modelul

pradă-prădător); • Agenți complecși (cum ar fi agentul cognitiv, care are o mulțime de calcule complexe).

Mediile, de asemenea, pot fi împărțite în: • Mediul virtual; • Mediul discret; • Mediul continuu.

Mediile agenților pot fi organizate în funcție de diferite proprietăți, cum ar fi:

accesibilitatea (în funcție de posibilitățile de a aduna informații complete despre mediul înconjurător), determinismul (în cazul în care o acțiune realizată în mediu provoacă un efect definit), dinamica (cât de multe entități pot influența mediul în acest moment), discreția (dacă numărul de acțiuni posibile în mediul este finit), episodicitatea (dacă acțiunile agentului în anumite perioade de timp influențează alte perioade) și dimensionalitatea (dacă caracteristicile spațiale sunt factori importanți ai mediului și agentul consideră spațiul în cadrul proceselor decizionale). Acțiunile agentului în mediu sunt mediate de obicei prin intermediul unui middleware adecvat. Acest middleware oferă o abstracție de design de primă clasă pentru sistemele multi-agent, furnizarea de mijloace care să reglementeze accesul la resurse și coordonarea agentului.

Agenții dintr-un sistem multi-agent au mai multe caracteristici importante: • Autonomie: agenții sunt cel puțin parțial independenți, conștienți de sine, autonomi; • Vizualizări locale: nici un agent nu are o imagine de ansamblu completă a sistemului, sau

sistemul este prea complex pentru un agent de a face utilizarea practică a acestor cunoștințe;

• Descentralizare: nu există nici un agent de control desemnat (sau sistemul este redus în mod eficient la un sistem monolitic).

12

Studiul sistemelor multi-agent reprezintă unul dintre domeniile de cercetare a

inteligenței artificiale distribuite și utilizează agenți autonomi care au propriile lor acțiuni și comportamente. Agenții dintr-un sistem multi-agent sunt concepuți să acționeze în calitate de experți într-o anumită zonă. Caracteristica principală este de a controla propriul comportament și, dacă este necesar, de a acționa fără nici o intervenție a omului sau a altor sisteme.

Potrivit Sawyer (Sawyer, 2003), Internetul este un exemplu de sistem multi-agent deoarece este constituit din mii de calculatoare independente, pe care rulează programe software autonome, care sunt capabile de comunicare cu un program care rulează pe oricare alt nod din rețea.

13

CAPITOLUL 2 2 SISTEME MULTI-AGENT UTILIZATE ÎN MANAGEMENTUL SITUAȚIILOR DE URGENȚĂ

2.1 Conceptul de oraș inteligent

Termenul de „Oraș inteligent” (Smart City) a fost definit de Komninos ca o simbioză între infrastructura fizică și infrastructura socială. El consideră că un oraș inteligent este construit pe trei dimensiuni, integrând inteligența umană (a individului), inteligența colectivă și inteligența artificială disponibilă în oraș. Un oraș este un sistem interconectat de sisteme. Este un trepied care se bazează pe un sprijin pentru și între fiecare dintre pilonii săi pentru a deveni un oraș inteligent pentru toți (Komninos, 2002).

Orașele și zonele urbane au devenit ecosisteme complexe unde grija principală este asigurarea unei dezvoltări durabile și prosperitate pentru cetățeni. În astfel de zone urbane, locuitorii, oamenii de afaceri și autoritățile publice exemplifică anumite nevoi și cereri din partea unor domenii cum ar fi sistemul medical, energie și mediu, siguranță și servicii publice. Aceste domenii sunt din ce în ce mai solicitate și depind de aplicații bazate pe Internet, de platforme de management al conținutului și infrastructuri de tip broadband. De aceea, orașele și zonele urbane, sunt puse în fața problemei de menținere și îmbunătățire a infrastructurii și de a stabili un proces eficient, eficace, deschis participării publice și inovativ prin care se poate raspunde cererii cetățenilor.

Orașele inteligente stimulază creșterea economică durabilă și prosperitate pentru

cetățenii lor. Liderii lor au instrumentele de analiză a datelor pentru a lua decizii mai bune, pentru a anticipa probleme și să le rezolve în mod proactiv și de a coordona resursele pentru a funcționa în mod eficient.

14

Cum cererile populației urbane cresc și bugetul este din ce în ce mai restrâns, soluția

este aceea de a privi orașul ca un întreg. Colectând și analizând datele generate în fiecare secundă a fiecărei zi, putem forma o imagine de ansamblu care să ajute la luarea deciziilor și a modului în care se poate asigura suportul în orașul modern. Cu cât sanatatea cetățenilor este mai bună, cu atât este mai puternică vitalitatea economică a orașului.

2.2 Arhitectura CitySCAPE

Dintre toate atributele unui oraș inteligent, în această lucrare se face referire la partea de control inteligent al traficului în cazul dezastrelor naturale, în mod special seisme. Acest atribut de control al traficului va fi axat pe perioada de producere a seismului, căt și pe perioada imediat următoare, care necesită intervenția echipajelor de urgență cu scopul de a reduce pagubele.

O arhitectură axată pe partea de protecție inteligentă împotriva seismelor atât la nivel mezoscopic, nu numai macroscopic, este CitySCAPE (Pătrașcu & Drăgoicea, 2013) – a Citywide Synergic Control Architecture for Protection against Earthquakes. CitySCAPE este o arhitectură dedicată părții de control și monitorizare a sistemelor urbane, asigură integritatea structurală, implementează și supraveghează normele de protecție socială, asigură răspuns rapid al echipajelor de urgență în caz de dezastre.

CityScape este format din două subsisteme interconectate și interdependente: eSCAPE și inSCAPE (figura 2.1), care integrează atât componente hardware cât și software. Sistemul eScape (Emergent CitySCAPE) modelează, controlează și monitorizează protecția entităților vii. Această componentă controlează sistemul social și monitorizează comportamentul uman în timpul cutremurelor folosind o rețea flexibilă de comunicație. Sistemul inScape (Integrated Networked CitySCAPE) integrează și interconectează un sistem ierarhizat de control al vibrațiilor seismice. (Pătrașcu & Drăgoicea, 2013)

15

Figura 2.1 CityScape – o perspectivă a nivelului macroscopic (Pătrașcu & Drăgoicea, 2013)

2.3 eScape

Dintre cele două subsiteme, sistemul eSCAPE este cel mai potrivit să descrie modelul implementat în lucrarea de față și va fi detaliat în rândurile ce vor urma.

Sistemul eSCAPE are ca rol principal protecția vieții și a sistemelor critice, prezentând o entitate de decizie care va decide, de exmplu care sunt zonele cu risc ridicat sau ce zone trebuiesc eliberate ca să poată interveni echipajele de urgență. eScape este format din țesuturi care reprezintă o parte a sistemului de protecție. Se pot deosebi 4 tipuri de țesuturi, fiecare având funcții caracteristice. Fiecare din aceste țesuturi este alcătuit din celule. Presupunem că celulele sunt alcătuite dintr-un set de dispozitive de control, percepție și acționare, precum și un dispozitiv de comunicație. (Pătrașcu & Drăgoicea, 2013). O structură este prezentată în figura 2.2.

Figura 2.2 Țesuturile eScape (Pătrașcu & Drăgoicea, 2013)

16

Cele 4 țesuturi sunt :

1. Controlul traficului 2. Avertizări și controlul panicii 3. Intervenția echipajelor de urgență 4. Protocoale sisteme critice

Dintre cele patru țesuturi, cele de interes în cadrul acestei lucrări sunt: controlul traficului și intervenția echipajelor de intervenție. Fiecare țesut este compus din mai multe dizpozitive. În cazul țesutului responsabil de controlul traficului, aceste dispozitive sunt:

- dispozitive de control: agenții de control al intersecțiilor - dispozitive de percepție: senzorii montați la intrările adiacente fiecărei

intersecții - dispozitive de acționare: echipamentele care formează fazele luminoase ale

semaforului

În cazul celui de-al doilea țesut, țesutul de intervenție a echipajelor de urgență, avem următoarele dispozitive:

- dispozitive de control: agentul dispecer - dispozitive de percepție: sisteme prezente în afara clusterului de clădiri - dispozitive de acționare: echipajele de întervenție

Aceste două țesuturi vor fi modelate în lucrarea de față, în capitolul următor, la nivel mezoscopic (cluster de clădiri).

17

CAPITOLUL 3 3 STUDIU DE CAZ

3.1 Programarea orientată agent

Conceptul de programare orientată agent a fost introdus de către profesorul Yoav Shoham de la Universitatea Standford drept o nouă paradigmă de programare care combină noțiuni mentalistice pentru a programa agenți autonomi. Contribuția importantă a programării orientate agent ca o nouă paradigmă de programare a fost să ofere o modalitate de a ajuta programatorii să dezvolte sisteme autonome. Limbajele de programare orientate agent au de obicei constructe de programare de nivel înalt care să faciliteze (în comparație cu limbajele de programare tradiționale) dezvoltarea de sisteme care funcționează și reacționează în mod constant la evenimentele care caracterizează schimbările în dinamica mediului în care se află. Agenții trebuie mereu să-și modifice acțiunile în funcție de modificările produse în mediu, aceste acțiuni nefiind doar reactive ci și proactive, cu scopul de a îndeplini obiective pe termen lung. Datorită caracteristicilor sale, programarea orientată agent, facilitează munca programatorului prin asigurarea că agenții se comportă într-un mod, referit de multe ori în literatura de specialitate, ca fiind „rațional”. Chiar dacă în două decenii programarea orientată agent a avut contribuții impresionante în sprijinirea programării vizate pe comportament autonom, acesta tot nu a putut să îndeplinească toate cerințele așteptate în contextul sistemelor multi-agent. Sistemele multi-agent sunt în mod normal utilizate pentru a dezvolta sisteme foarte complexe, care nu numai că prezintă multe entități autonome, dar trebuie să și interacționeze în moduri complexe și trebuie să aibă structuri sociale și norme pentru a reglementa comportamentul

18

social global care se așteaptă de la agenți și, la fel de important, un mediu partajat care poate constitui o sursă importantă și eficientă a mijloacelor de coordonare pentru agenți. Comparată cu programarea orientată pe obiecte, programarea orientată agent se diferențiază în mod special prin limbajul interfeței. Spre deosebire de programarea orientată agent în care agenții folosesc un limbaj comun, cu o semantică independentă de agent, în programarea orientată pe obiecte înțelesul unui mesaj variază de la un obiect la altul.

3.2 Mediul de programare: NetLogo Acest mediu a fost ales datorită utilizării pe scara largă, cât și a instrumentelor prezente. NetLogo este un mediu de modelare programabil pentru simularea fenomenelor naturale și sociale. Acesta a fost scris de Uri Wilensky în 1999 și a fost în continuă dezvoltare încă de atunci de către Centrul Connected Learning and Computer-Based Modeling (Wilensky, 1999). Lumea din interiorul NetLogo este alcatuită din agenți. În NetLogo se pot distinge patru tipuri de agenți și anume:

- Turtles; - Patches; - Links; - Observer.

Turtles sunt agenți care se mișcă în lume. Lumea este bidimensională și este împărțită

într-o grilă de patches. Fiecare patch este un pătrat de „pământ” peste care se pot deplasa turtles. Links sunt agenți care conectează doi turtles. Observer-ul nu are o locație, el putând privi din afară lumea în care sunt turtles și patches. Acesta nu doar observă ci poate da și instrucțiuni agenților.

3.3 Aplicația 3.3.1 Descrierea aplicației

Având stabilite noțiunile de bază cu privire la paradoxul de programare utilizat cât și a limbajului și mediului de programare, putem continua cu descrierea efectivă a aplicației

19

implementate. Aplicația are ca punct cheie simularea unui sistem multi-agent de control al traficului care facilitează intervenția rapidă a mai multor echipaje de intervenție în locațiile în care s-au produs calamități, străbătând mai multe intersecții care alcătuiesc modelul lumii.

În cadrul acestei simulări, am utilizat un sistem alcătuit din 11 intersecții, fiecare cu propriul lui agent, agent autonom, obținându-se un sistem multi-agent în care agenții au ca și scop principal asigurarea unui flux constant de trafic prin observarea secțiunilor de drum adiacente lor și asigurarea în același timp a unui timp minim de așteptare al echipajelor de urgență ce trebuie să raspundă unei intervenții la una din locații. Pentru a diferenția tipurile de echipaje de intervenție, acestea au fost colorate diferit. În tabelul următor sunt marcate tipul echipajului, urmate de culoarea cu care au fost reprezentate și indicatorul pentru incidentele la care trebuie să răspundă ficare categorie de echipaj de intervenție.

Echipaj Culoare Indicator incident

Ambulanță Roșu

Poliție Albastru

Salvare Galben

Pentru partea aplicativă, cu scopul de a evidenția modul de funcționare și beneficiile acestui sistem multi-agent, s-a lăsat posibilitatea ajustării scenariului, având posibilitatea de a selecta numărul de incidente ce pot apărea la un moment dat, acoperind în acest fel majoritatea situațiilor ce pot aparea în cazul unor situații de urgență. Datorită posibilității de ajustare a scenariului, se poate observa funcționarea sistemului de control al traficului atunci când este prezent un singur tip de echipaj de urgență sau mai multe echipaje de urgență de tipuri diferite, care pot fi prezente în același timp într-o intersecție, observându-se

20

prioritizarea echipajelor. Funcționalitatea sistemului multi-agent este prezentată mai detaliat în secțiunile ce vor urma. 3.3.2 Modelul lumii

Dimensiunea modelului este de 65 x 37 agenți statici, rezultând într-un număr total de

2405 agenți statici.

Figura 3.1 Modelul Lumii

Modelul lumii utilizat în mediul NetLogo este cel continuu, însemnând că odată ce un agent părăsește mediul prin una din ieșiri, el va fi repoziționat în mod aleator pe una din intrări în lume. Agenții statici sunt utilizați pentru a crea mediul, reprezentat prin clădiri, copaci, apă și secțiuni de drum ce alcătuiesc intersecțiile. Agenții mobili sunt reprezentați de mașini care se deplasează pe rețeaua de drumuri. Mai sunt prezenți și agenții inteligenți care gestionează sistemul de control al traficului, prezenți în fiecare intersecție, și agenții responsabili de îndrumarea echipajelor de intervenție.

3.3.3 Sistemul multi-agent de control al traficului

Implementarea este realizată pe principiul sistemulului non-ierarhic. Într-un sistem non-ierarhic sunt folosiți agenții de control autonomi însemnând că fiecare agent dintr-un astfel de sistem este responsabil pentru propria sa zonă și comunică cu agenții din apropiere pentru a evalua situația din imediata sa vecinatate, după cum se poate observa în figura 3.2.

21

Agenții din zonele alăturate se consultă și negociază pe baza propriilor priorități. Datorită acestei interacțiuni, se ajunge într-un mod indirect ca toți agenții să fie influentați unul de celalalt.

Figura 3.2 Agenții dintr-o structură non-ierarhică (Tampère et al., 2008)

Fiecare intersecție este condusă de o unitate de control local, agentul de control al intersecției. Acesta supervizează tronsoanele de drum adiacente cu scopul de a asigura o performanță ridicată a intersecției și a străzilor ca un întreg. Agenții de control ai intersecției se preocupă cu buna funcționare a operațiunii de control a traficului în propria lor intersecție. Deși în mod individual pot lua deciziile corecte pentru propriile lor intersecții, aceste decizii ar putea, în unele cazuri să aibe un efect negativ pentru străzi, privite ca un întreg. În acest caz, intervine o formă de negociere între agenții intersecției ce au o stradă comună și încearcă să ajungă la un consens pentru a îndeplini obiectivele ambilor agenți. Acest sistem poate fi usor extins și la un nivel mai mare: agenți de control al cartierelor sau agenți de control al sectoarelor.

Figura 3.3 Agenții dintr-o structură ierarhică (Tampère et al., 2008)

22

Decizia de implementare folosind un sistem non-ierarhic a fost aleasă pe baza criteriului de robustețe. După cum se poate observa în figura 3.3, într-un sistem ierarhic toți agenții sunt supervizați de către un coordonator și comunicarea se realizează strict între agent și coordonator fiind un sistem centralizat. 3.3.4 Agentul dispecer

Agentul dispecer este responsabil cu partea de intervenție a echipajelor de urgență. El determină apariția unui incident și asignează un echipaj către acea locație. Echipajul sub îndrumarea agentului dispecer va parcurge distanța cea mai scurtă până la locația producerii incidentului. Traseele cele mai scurte sunt determinate în momentul generării mediului și sunt memorate local de catre agentul dispecer (într-o eventuală viitoare implementare, această acțiune se poate realiza folosind un algoritm optimizat). Dupa cum se poate observa în figura 3.4, în momentul producerii incendiului, agentul dispecer a asignat un echipaj de intervenție, mașina de pompieri, către locația la care s-a produs incendiul.

Figura 3.4 Intervenția unui echipaj de pompieri

Traseul pe care îl va urma mașina de pompieri este marcat în figura 3.4 cu culoarea roșie. După cum se poate observa, mașina de pompieri va parcurge distanța cea mai scurtă până la locul producerii incendiului. Pentru a putea ajunge cât mai repede în locul în care s-a produs incidentul, trecerea este facilitată prin intermediul agentului de control al intersecției care va modifica fazele

23

semaforului încât să permită trecerea în siguranță a mașinii de pompieri. Dupa soluționarea incidentului, mașina de pompieri se va întoarce în stația din care a venit. 3.3.5 Agenții de control al intersecției

Agentul de control al intersecției este responsabil cu stabilirea culorii fazelor semaforului și este totodată și cel responsabil pentru menținerea unui flux constant de trafic.

În figura 3.5 se pot observa agenții poziționați în fiecare intersecție cât și zona de care

răspund. Acești agenți observă zona asignată lor și pe baza cunoștintelor lor vor asigura un flux constant.

Figura 3.5 Pozitionarea agenților în intersecții

Modul în care se asigură schimbarea culorii verzi a semaforului este bazată pe un sistem valoric, însemnând ca fiecare mașină prezentă pe unul din drumurile adiacente intersecției în care este poziționat agentul are o valoare 1, iar pentru a asigura prioritizarea echipajelor de intervenție, acestea au valorile: poliție = 50, pompieri = 100 și ambulanța = 150. Utilizarea acestui sistem valoric asigură că în intersecție vor fi mereu prioritare ambulanțele, urmate de pompieri și poliție.

Acest sistem valoric este baza pentru sistemul decizional al agentului de control al

intersecției. Pentru o mai bună înțelegere a acestui sistem am prezentat un exemplu în figura 3.6 unde în fiecare intersecție sunt prezente mai multe mașini. Fiecărei secțiuni de drum

24

asociată intersecției i se atribuie o coordonată spațială (N = Nord, S = Sud, E = Est, V = Vest) și i se va determina valoarea de prioritate Vi .

Figura 3.6 Model intersecție

În cazul de față valorile de prioritate pentru fiecare secțiune de drum sunt:

VN = 2 * 1 = 2 (3.1) VS = 3 *1 = 3 (3.2) VE = 1 + 150 = 151 (3.3) Vv = 1 (3.4)

Dupa determinare valorilor de prioritate se determină maximul dintre cele 4 valori:

MAX(VN, VS, VE, VV) (3.5)

care în cazul de față este VE rezultând în acordarea culorii verzi a semaforului a

autoturismelor pe secțiunea de drum poziționată în partea de est față de agentul de control al traficului. Aceste atribuiri de valori, acordate fiecărui tip de autoturism, țin mai mult de nivelul de cunoaștere a agentului care dictează nivelul decizional, din acest motiv sistemul se adaptează foarte ușor la diferite situații de congestie în trafic. În funcție de necesități, se pot schimba valorile echipajelor de intervenție, cum ar fi a mașinilor de pompieri în zonele predispuse la incendii prin atribuirea unei valori mai mari față de celelalte tipuri de echipaje. În zone urbane foarte populate, în care transportul public este foarte utilizat, se pot atribui valori mai mari autovehiculelor de transport public (autobuz, tramvai, troleibuz) față de cele a autovehiculelor de transport personal. Capacitatea aceasta de a-și modifica sistemul valoric

25

ține de partea de învațare a agentului, el putând să se adapteze diferitelor situații ce pot apărea cu scopul de a menține eficiența sistemului. Determinarea numărului și a tipului de autovehicule se poate realiza prin intermediul unui contor de trafic. Un contor de trafic este un dispozitiv, de cele mai multe ori de natură electrică, folosit pentru a număra, clasifica sau măsura viteza de trecere a autovehicului de-a lungul carosabilului. Dispozitivul este, de obicei, montat în imediata apropiere a carosabilului sau direct pe carosabil, cum ar fi tuburile rutiere pneumatice stabilite pe carosabil, senzori piezo-electrici încorporați în pistă, bucle inductive, montate în carosabil, sau o combinație a acestora pentru a detecta autovehiculele care trec. Unul dintre primele unități numărătoare de trafic, numite înregistratoare de trafic, a fost introdus în 1937 și funcționa folosind o bandă de senzori aplicată pe stradă. (USDT, 2011)

3.4 Scenarii de test

Pentru a putea simula cât mai multe situații, aplicația prezintă setări prin care se pot selecta numărul de incidente ce se pot produce din fiecare categorie. După cum se poate observa în figura 3.7 , se poate seta numărul de incidente la care trebuie să raspundă echipajul de pompieri, poliție sau ambulanță.

Figura 3.7 Instrumentele prin care se poate seta numărul de incidente S-a dorit posibilitatea ajustării scenariului pentru a evidenția eficiența aplicației, cât și flexibilitatea logicii implementate, atât în cazul unui scenariu simplu în care ar putea să intervină puține echipaje, cât și în situațiile mult mai complexe în care sunt nevoite să intervină toate echipajele din fiecare categorie. Pentru a putea deosebi tipurile de agenți mobili, facilitând urmărirea simulării, fiecare agent a fost colorat diferit. Mașinile au fost colorate cu gri, iar echipajele de intervenție au fost

26

colorate diferit în funcție de tipul lor. Echipajele de poliție au fost colorate cu albastru, cele de pompieri cu roșu și ambulanțele au fost colorate cu galben.

3.5 Instrumente folosite

Pentru a putea interacționa cu mediul, este nevoie de utilizarea unui set de instrumente. Aceste instrumente ajută la observarea anumitor variabile, la controlul și declanșarea anumitor evenimente. 3.5.1 Butoane

În această aplicație sunt folosite 3 butoane: „Setează mediul”, „Adăugare incidente” și „Simulare”, care se pot observa în figura 3.8.

Figura 3.8 Butoanele folosite în aplicație

Inițial, doar butonul „Setează mediul” este singurul deblocat, celelalte 2 butoane rămânând blocate până în momentul apăsării butonului „Setează mediul”. După apăsarea butonului „Setează mediul” se începe construirea modelului inițial al lumii. Acesta construiește străzile, care formează intersecțiile, clădirile, celelalte elemente de mediu (apă, iarbă, copaci), poziționează agenții mobili și statici, și le setează culorile și direcțiile. După ce va termina de executat toate instrucțiunile, el va debloca celelalte 2 butoane. Butonul „Simulare” este singurul buton din cele 3 care are bifată opțiunea „Forever”, însemnând că odată ce s-a apăsat butonul, acesta va rămâne apăsat până în momentul unei noi apăsări, și va executa instrucțiunea care ii este asignată până la nouă apăsare. Apăsarea butonului va apela în mod repetat funcția responsabilă cu deplasarea agenților mobili. Butonul „Adăugare incidente” va determina apariția pe hartă a unui incident, care va fi semnalat agentului dispecer. Acest buton este conceput să lucreze cu uneltele de tip Slide-Bar,

27

pentru a putea declanșa mai multe incidente în același moment de timp, uneltele ce vor fi prezentate în secțiunea ce urmează. 3.5.2 Elemente de tip Slide-Bar

Sunt prezente în aplicație trei unelte de tip „Slide-Bar”. Acestea sunt utilizate pentru a putea varia numărul de incidente ce pot apărea la un anumit moment de timp. Fiecare Slide-Bar are asignată câte o variabilă după cum se poate observa și în figura 3.9.

Figura 3.9 Elemente de tip „Slide-Bar”

Variabilele asignate uneltelor de tip Slide-Bar sunt: „incidente-pompieri”, „incidente-poliție” și „incidente-ambulanță”. Acestea pot modifica valoarea variabilei asignate prin deplasarea liniei roșii de-a lungul bării. Modificarea oricărei dintre valorile celor trei variabile, va determina la momentul apăsării butonului „Adăugare incidente” crearea numărului de incidente asignate de către Slide-Bar și apariția lor pe hartă în una din locații, în mod aleator.

3.5.3 Monitoarele

Monitoarele sunt utilizate pentru a vedea numărul incidentelor la care trebuie să răspundă fiecăre tip de echipaj după cum se poate observa și în figura 3.10.

Figura 3.10 Unelte de tip monitor

28

Fiecare dintre cele 3 monitoare are asignată o variabilă care se va incrementa sau decrementa în funcție de numărul de incidente prezente, facilitând urmărirea intervențiilor echipajelor.

3.6 Rezultate

În cadrul acestei aplicații s-au realizat 3 simulări, care vor ilustra comportamentul aplicației în cazul a 3 scenarii, unul în care este prezent un singur echipaj de intervenție, unul în care sunt prezente câte un echipaj de intervenție din fiecare categorie și ultimul scenariu în care vor fi prezente toate echipajele de intervenție.

3.6.1 Scenariul 1 – Intervenția unui singur echipaj

Scenariul 1 simulează situația apariției unui furt. Pentru a executa acest tip de scenariu este necesar să se seteze numărul de incidente la care trebuie să răspundă un echipaj de poliție la 1, după cum se poate observa în figura 3.11, și să se apase pe butonul de „Adăugare incidente” pentru a anunța agentul dispecer că s-a produs un incident.

Figura 3.11 Setările pentru simularea scenariului 1

După cum se poate observa în monitor-ul din figura 3.11, variabila ce indică numărul de incidente la care trebuie să răspundă un echipaj de poliție s-a incrementat și un echipaj din această categorie va pleca către locul unde s-a produs furtul.

29

Pentru a ajunge la locul producerii incidentului, mașina de poliție va trebuie să treacă prin două intersecții, lucru ce este prezentat în figura 3.12.

Figura 3.12 Intervenția unui echipaj de poliție

O dată ce echipajul ajunge în prima intersecție, figura 3.13, agentul de control al intersecției va stabili fazele semaforului încât să faciliteze trecerea echipajului de poliție, blocând trecerea celuilalt autovehicul prezent în intersecție. Sub îndrumarea agentului dispecer, echipajul de poliție va schimba direcția de deplasare spre dreapta, iar după părăsirea intersecție, agentul de control al interesecției va stabili fazele semaforului pentru a permite trecerea celuilalt autovehicul prezent în intersecție.

Figura 3.13 Agentul de poliție prezent în prima intersecție

30

Deoarece fazele semaforului se schimbă imediat după părăsirea intersecției de către un echipaj, timpul de așteptare pentru celelalte tipuri de autovehicule este relativ mic. Acest timp de așteptare este relativ mic deoarece agentul de control al intersecției verifică în mod constant drumurile adiacente acestuia și prin intermediul sistemului valoric, acesta selectează fazele semaforului pentru a facilita trecerea echipajelor.

Figura 3.14 Agentul de poliție prezent în a doua intersecție

După ce agentul de poliție a trecut de prima intersecție, datorită secțiunii de drum comune, cel de-al doilea agent de control al intersecției recepționează venirea echipajului de poliție și schimbă fazele semaforului pentru a-i facilita trecerea, după cum se observă și în figura 3.14. Deoarece în cazul de față nu este prezent un alt autovehicul în afară de echipajul de intervenție, timpul de așteptare este minim pentru echipajul de intervenție.

Odată ajuns la destinație, variabila ce reține numărul de incidente la care trebuie să răspundă un echipaj de poliție, se va decrementa, acest lucru poate fi constatat în monitor prin schimbarea valorii din 1 în 0. După soluționarea incidentului, echipajul de poliție se va întoarce în poziția inițială în stația de poliție.

3.6.2 Scenariul 2 – Intervenția a câte unui echipaj din fiecare categorie

Față de scenariul 1 în care se simula apariția unui furt, în scenariul 2 se urmărește simularea apariției a trei evenimente (accident, incendiu, infarct). Setările prealabile pentru simularea acestui tip de scenariu se realizează prin setarea numărului de incidente la care

31

trebuie să răspundă fiecare categorie de echipaj de urgență la valoarea 1, după cum se poate observa în figura 3.15.

Figura 3.15 Setările pentru simularea scenariului 2

După apăsarea butonului „Adăugare incidente”, valorile ce rețin numărul de incident la care trebuie să răspundă fiecare echipaj de intervenție vor fi incrementate, iar agentul dispecer va fi anunțat de cele trei incidente care sunt prezentate pe hartă din figura 3.16.

Figura 3.16 Apariția celor trei incidente

Față de scenariul anterior în care trebuia să răspundă un singur echipaj de intervenție, în acest scenariu apare situația în care două echipaje de intervenție, din categorii diferite, ajung concomitent în aceeași intersecție, după cum se poate observa în figura 3.17. Apariția acestei

situații este elementul cheie al acestei simulări, care relevă sistemul de prioritizare a traficului.

32

Figura 3.17 Întâlnirea a două echipaje de intervenție

Pentru a rezolva problema prioritizării traficului, agentul de control al intersecției apelează la sistemul valoric. Astfel, se vor recalcula valorile de prioritate pentru fiecare secțiune de drum asociată intersecției:

VN = 0 (3.6) VS = 150 (3.7) VE = 100 (3.8) Vv = 0 (3.9)

Dupa determinare valorilor de prioritate se determină maximul dintre cele 4 valori: MAX(VN, VS, VE, VV) (3.10)

unde, în cazul de față, este VS care rezultă din acordarea culorii verzi a semaforului

ambulanței.

Datorită sistemului valoric, agentul de control al intersecției a determinat o prioritate mai mare pentru echipajul de ambulanță față de echipajul de pompieri. Astfel, agentul de control al intersecției a stabilit fazele semaforului, încât să faciliteze trecerea ambulanței. Abia după ce ambulanța va trece de intersecție, agentul de control al intersecției va stabili fazele semaforului în favoarea echipajului de pompieri.

33

Pe măsură ce echipajele de urgența ajung la locul producerii incidentelor, variabila ce indică numărul de incidente pentru fiecare categorie în parte, va fi decrementată, lucru ce poate fi observat în figura 3.18

Figura 3.18 Soluționarea multiplelor intervenții

3.6.3 Scenariul 3 – Intervenția tuturor echipajelor de intervenție din fiecare categorie

În plus față de celelalte două scenarii apare situația în care intervin două echipaje de intervenție diferite, la un eveniment comun (incendiu soldat cu victime) unde cele două echipaje sunt pompierii pentru a stinge incendiul și ambulanța pentru acordarea primului ajutor victimelor. Acest incendiu s-a produs datorită unui seism, dar acesta nu a fost singura repercusiune a seismului, determinând și restul echipajele de intervenție să acționeze, cu diferența că nu este necesară prezența simultană a două echipaje de urgență diferite. Setările făcute anticipat pentru simularea acestui tip de scenariu se realizează prin setarea numărului de incidente, la care trebuie să răspundă fiecare categorie de echipaj, la valoarile maxime, prin intermediul componentei de tip Slide-Bar, după cum se poate observa în figura 3.19.

34

Figura 3.19 Setările pentru simularea scenariului 3

După apăsarea butonului „Adăugare incidente”, valorile ce rețin numărul de incidente

vor prelua valorile maxime setate de componenta de Slide-Bar, iar agentul dispecer va fi anunțat de toate cele 14 incidente care sunt prezentate pe hartă din figura 3.20.

Figura 3.20 Apariția tuturor incidentelor

După cum se poate observa, cele două echipaje de intervenție, pompieri și ambulanță, au o locație comună (stânga-sus), iar restul echipajelor trebuie să ajungă la destinații diferite.

35

În acest scenariu apare situația în care toate echipajele de urgență, din toate categoriile, ajung concomitent în diferite intersecții (figura 3.21).

Figura 3.21 Întâlnirea echipajelor de intervenție în intersecție

În cazul de față valorile de prioritate pentru fiecare secțiune de drum sunt: VN = 0 (3.11) VS = 100 (3.12) VE =1 + 2*50 = 101 (3.13) Vv = 0 (3.14)

Dupa determinare valorilor de prioritate se determină maximul dintre cele 4 valori:

MAX(VN, VS, VE, VV) (3.15)

care în cazul de față este VE rezultând în acordarea culorii verzi a semaforului a

autoturismului împreună cu cele două echipaje de poliție aflate pe secțiunea de drum poziționată în partea de est față de agentul de control al traficului.

După cum se poate observa în figura 3.22, pe masură ce echipajele de intervenție

soluționează toate evenimentele, variabilele ce rețin numărul de incidente active se vor

36

decrementa până la atingerea valorii de 0, marcând rezolvarea tuturor incidentelor cauzate de seism.

Figura 3.22 Starea la un moment dat a incidentelor cauzate de seism

37

Capitolul 4 4 Concluzii

În cadrul lucrării a fost prezentată o soluție pentru rezolvarea problemei dirijării traficului în cazul situațiilor de urgență. Au fost tratate măsuri de management al traficului după producerea unui seism sau a unui alt tip de hazard.

Aplicația implementată în lucrarea de față a permis modelarea unui sistem multi-agent care asigură un răspuns rapid al echipajelor de intervenție (pompieri, poliție, ambulanță) în situații de urgență și totodată reușind să mențină un flux relativ constant al traficului.

Rezultatele obținute în urma simulărilor arată că logica de funcționare a agenților care compun sistemul multi-agent este bună. Sistemul multi-agent a reușit să-și îndeplinească obiectivul pentru care a fost proiectat, devenind un instrument de management capabil să rezolve probleme de congestie și pierderi de timp asociate, prin intermediul rețelei de intersecții, fără a compromite capacitatea echipajelor de intervenție de a răspunde prompt situațiilor apărute.

Îmbunătățiri ce pot fi aduse în lucrări viitoare pot include un sistem de determinare activă a direcției de deplasare a agenților, pentru a acoperi situațiile în care apar obstacole sau congestie urbană ridicată. De asemenea, se poate modifica sistemul valoric încât sa permită reprioritizarea traficului în mod activ, în situațiile în care este necesară intervenția unui echipaj de pompieri înaintea unei ambulanțe datorită extinderii rapide a unui incendiu.

38

5 Anexe

5.1 Anexa A – Procedura „setUpEnv”

Procedura setUpEnv este apelată în momentul apăsării butonului „Setează mediul” și setează mediul cu configurația inițială

to setUpEnv clear-all addfiretrucks addpolicecars addambulances addintersections addcars addtree (-3)(3) addtree (2)(3) addtree (-12)(-15) addtree (-21)(-6) addtree (-23)(-11) addtree (-17)(-9) addtree (-31)(-11) addtree (-11)(-5) addtree (-11)(-12) addtree (-28)(-5) addtree (-10)(-17) addtree (-32)(-16) addtree (16)(-14) addtree (-31)(13) addtree (-31)(11) addtree (-24)(13) addtree (-24)(11) addtree (16)(12) addtree (14)(2) ;trotuare ask patches [setuppavement] set fire-incidents 0 set police-incidents 0 set ambulance-incidents 0

39

set active-incident 0 ;drumuri ask patches [setuproads] ;cladiri ask patches [setupbuilding] ;sectiile de politie,pompieri,ambulanta ask patches [setupspecialbuildings] ask patches [setupintersections] reset-ticks end ; proceduri apelate în cadrul procedurii setUpEnv to AddTree [xcord ycord] crt 1 [ set shape "tree" set color 62 set xcor xcord set ycor ycord] end to addfiretrucks addfiretruck(23)(17)(90) set firetruck1 turtle 0 addfiretruck(23)(15)(90) set firetruck2 turtle 1 addfiretruck(23)(13)(90) set firetruck3 turtle 2 addfiretruck(31)(17)(270) set firetruck4 turtle 3 addfiretruck(31)(15)(270) set firetruck5 turtle 4 addfiretruck(31)(13)(270) set firetruck6 turtle 5 end to addpolicecars addpolicecar(-31)(2) set policecar1 turtle 6 addpolicecar(-29)(2) set policecar2 turtle 7 addpolicecar(-27)(2) set policecar3 turtle 8 addpolicecar(-25)(2) set policecar4 turtle 9 end to addambulances addambulance(-4)(-8) set ambulance1 turtle 10 addambulance(-2)(-8) set ambulance2 turtle 11 addambulance(0)(-8) set ambulance3 turtle 12 addambulance(2)(-8) set ambulance4 turtle 13 end to addcars addcar (1)(9)(-90) addcar (-8)(11)(180)

40

addcar (-8)(12)(180) addcar (-27)(-2)(90) addcar (7)(2)(0) addcar (13)(-1)(-90) addcar (-28)(8)(90) addcar (20)(-16)(0) addcar (19)(13)(180) end to addfiretruck [xcord ycord orientare] create-firetrucks 1 [ set xcor xcord set ycor ycord set heading orientare set shape "car" set firetruck-speed 1 set color red set speed 0 ] end to addpolicecar [xcord ycord] create-policecars 1 [ set xcor xcord set ycor ycord set heading 0 set shape "car" set color blue set speed 0 ] end to addambulance [xcord ycord] create-ambulances 1 [ set xcor xcord set ycor ycord set heading 0 set shape "car" set color 44 set speed 0 ] end

5.2 Anexa B – Procedura „simulate” Apelul procedurii simulate este plasat într-o buclă infinită, fiind reapelată cât timp butonul „Simulare” este lasăt în modul activ.

to simulate if (fire-incidents > 0) [ ;interventia primului echipaj if (count fires-on patch -14 14 = 1) [ ask firetruck1 [ set speed 1 if (xcor = 26) and (pycor = 17) [

41

set heading 180 ] if (xcor = 26) and (ycor = 9) [ set heading 270 ] if (xcor = -14) and (ycor = 9) [set heading 0] if (xcor = -14) and (ycor = 14) [ ask fires with [xcor = -14 and ycor = 14] [die] set active-incident active-incident - 1 set xcor 23 set ycor 17 set fire-incidents fire-incidents - 1 set heading 90 set speed 0 ] fd speed ] ] if (count fires-on patch -29 12 = 1) [ ask firetruck4 [ set speed 1 if (xcor = 26) and (pycor = 17) [ set heading 180 ] if (xcor = 26) and (ycor = 9) [ set heading 270 ] if (xcor = -29) and (ycor = 9) [set heading 0] if (xcor = -29) and (ycor = 12) [ ask fires with [xcor = -29 and ycor = 12] [die] set active-incident active-incident - 1 set xcor 31 set ycor 17 set fire-incidents fire-incidents - 1 set heading 90 set speed 0 ] fd speed ] ] ;interventie echipajului 2 de pompieri if (count fires-on patch 0 2 = 1) [ ask firetruck2 [ set speed 1 if (xcor = 26) and (pycor = 15) [ set heading 180 ] if (xcor = 26) and (ycor = 9) [ set heading 270 ] if (xcor = -14) and (ycor = 9) [set heading 0] if (xcor = -14) and (ycor = 14) [ ask fires with [xcor = -14 and ycor = 14] [die] set active-incident active-incident - 1 set xcor 23 set ycor 17 set fire-incidents fire-incidents - 1 set heading 90 set speed 0 ] fd speed ]

42

] ] if (police-incidents > 0) [ if (count thefts-on patch -4 12 = 1) [ ask policecar1 [ set speed 1 if (xcor = -31) and (ycor = 4) [ set heading 90 ] if (xcor = -20) and (ycor = 4) [ set heading 0 ] if (xcor = -20) and (ycor = 8) [ set heading 90 ] if (xcor = -4) and (ycor = 8) [ set heading 0 ] if (xcor = -4) and (ycor = 12) [ ask thefts with [xcor = -4 and ycor = 12] [die] set active-incident active-incident - 1 set xcor -31 set ycor 2 set police-incidents police-incidents - 1 set heading 0 set speed 0 ] fd speed ] ] if (count thefts-on patch 24 3 = 1) [ ask policecar2 [ set speed 1 if (xcor = -29) and (ycor = 4) [set heading 90] if (xcor = 24) and (ycor = 3) [ ask thefts with [xcor = -4 and ycor = 12] [die] set active-incident active-incident - 1 set xcor -29 set ycor 2 set police-incidents police-incidents - 1 set heading 0 set speed 0 ] fd speed ] ] if (count thefts-on patch 11 -17 = 1) [ ask policecar3 [ set speed 1 if (xcor = -27) and (ycor = 4) [set heading 90] if (xcor = 11) and (ycor = -17) [ ask thefts with [xcor = -4 and ycor = 12] [die] set active-incident active-incident - 1 set xcor -27 set ycor 2 set police-incidents police-incidents - 1 set heading 0 set speed 0 ]

43

fd speed ] ] if (count thefts-on patch 27 -16 = 1) [ ask policecar4 [ set speed 1 if (xcor = -25) and (ycor = 4) [set heading 90] if (xcor = -4) and (ycor = 12) [ ask thefts with [xcor = -4 and ycor = 12] [die] set active-incident active-incident - 1 set xcor -25 set ycor 2 set police-incidents police-incidents - 1 set heading 0 set speed 0 ] fd speed ] ] ] if (ambulance-incidents > 0) [ if (count deaths-on patch 13 16 = 1) [ ask ambulance3 [ set speed 1 if (xcor = 0) and (ycor = -6) [set heading 90] if (xcor = 7) and (ycor = -6) [set heading 0] if (xcor = 7) and (ycor = 8) [set heading 90] if (xcor = 13) and (ycor = 8) [set heading 0] if (xcor = 13) and (ycor = 16) [ ask deaths with [xcor = 13 and ycor = 16] [die] set active-incident active-incident - 1 set xcor 0 set ycor -8 set ambulance-incidents ambulance-incidents - 1 set heading 0 set speed 0 ] fd speed ] ] if (count deaths-on patch -14 3 = 1) [ask ambulance2 [ set speed 1 if (xcor = -2) and (ycor = -6) [set heading -90] if (xcor = -7) and (ycor = -6) [set heading 0] if (xcor = -7) and (ycor = 3) [set heading -90] if (xcor = -14) and (ycor = 3) [ ask deaths with [xcor = -14 and ycor = 3] [die] set active-incident active-incident - 1 set xcor -2 set ycor -8

44

set ambulance-incidents ambulance-incidents - 1 set heading 0 set speed 0 ] fd speed ] ] if (count deaths-on patch -26 12 = 1) [ask ambulance1 [ set speed 1 if (xcor = -4) and (ycor = -6) [set heading -90] if (xcor = -7) and (ycor = -6) [set heading 0] if (xcor = -7) and (ycor = 9) [set heading -90] if (xcor = -26) and (ycor = 9) [set heading 0] if (xcor = -26) and (ycor = 12) [ ask deaths with [xcor = -26 and ycor = 12] [die] set active-incident active-incident - 1 set xcor -4 set ycor -8 set ambulance-incidents ambulance-incidents - 1 set heading 0 set speed 0 ] fd speed ] ] if (count deaths-on patch 13 -7 = 1) [ ask ambulance4 [ set speed 1 if (xcor = 2) and (ycor = -6) [set heading 90] if (xcor = 13) and (ycor = -6) [set heading 180] if (xcor = 13) and (ycor = -7) [ ask deaths with [xcor = 13 and ycor = -7] [die] set active-incident active-incident - 1 set xcor 2 set ycor -8 set ambulance-incidents ambulance-incidents - 1 set heading 0 set speed 0 ] fd speed ] ] ] ask cars [ ifelse [pcolor] of patch-ahead 2 = red [set speed 0] [set speed 1] fd speed ] ask intersec1

45

[ switchlights ] ask intersec2 [ switchlights ] ask intersec3 [ switchlights ] ask intersec4 [ switchlights ] ask intersec5 [ switchlights5 ] ask intersec6 [ switchlights ] ask intersec7 [ switchlights ] ask intersec8 [ switchlights ] ask intersec9 [ switchlights9 ] ask intersec10 [ switchlights ] ask intersec11 [ switchlights ] tick end

46

BIBLIOGRAFIE

[1] Tampère C., Immers B., Stada J., Janssens B. 2008. A multi-agent control în road traffic management. Vilnius Gediminas Technical University Publishing House Technika, Lituania [2] Komninos N. 2002. Intelligent Cities: Innovation, knowledge systems and digital spaces. Taylor and Francis, Spon Press, London. [3] USDT U.S. Department of Transportation 2011. Traffic Monitoring Guide. Transportation & Development Institute, SUA [4] Hyacinth S. N. 1996. Software Agents: An Overview. Cambridge University Press, Suffolk

[5] Foner L. N. 1993. What is an Agent, Anyway? A Sociological Case Study. MIT Media Lab, Cambridge [6] Ferber J. 1994. Simulating with Reactive Agents. IOS Press, Amsterdam. [7] Hewitt C. 1977. Viewing Control Structures as Patterns of Passing Messages. MIT Media Lab, Cambridg [8] Wilensky U. 1999. NetLogo. http://ccl.northwestern.edu/netlogo/. Center for Connected Learning and Computer-Based Modeling, Northwestern University, Evanston, IL. [9] Monica Pătrașcu, Monica Drăgoicea 2013 Integrating Services and Sgents 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, p. 167-180, ISBN 978-973-720-490-5

47

[10] Wooldridge M., Jennings N. 1995, Intelligent Agents, Lecture Notes in Artificial Intelligence 890, Heidelberg: Springer Verlag. [11] Nwana H. S., Lee L., Jennings N. R. 1996, Coordination in Software Agent Systems, British Telecommunications Technology Journal [12] Sawyer R. K. 2003 Artificial societies: Multiagent systems and the micro-macro link in sociological theory, Sociological Methods and Research