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

Absolvent

Ujvarosi-Brezeanu Alexandru

Coordonator

As. Dr. Ing. Monica Pătraşcu

Bucureşti, 2012

CUPRINS

1. INTRODUCERE 3

2. AGENŢI ŞI SISTEME MULTI-AGENT 6

2.1. Apariţia noţiunii de agent 6

2.2. Definiţiile agenţilor 9

2.3. Clasificarea agenţilor 13

2.4. Implementări ale agenţilor 15

2.5. Sisteme multi-agent 17

2.6. Implementări ale sistemelor multi-agent 18

3. SMART CITY ŞI CitySCAPE 22

3.1. Conceptul Smart City 22

3.2. Conceptul CitySCAPE 26

3.3. Structura şi funcţionalitatea CitySCAPE 26

3.4. eSCAPE 27

4. STUDIU DE CAZ 30

4.1. Programarea orientată agent 30

4.2. Alegerea mediului de programare: NetLOGO 31

4.3. Particularităţi de programare în limbajul NetLOGO 32

4.3.1. Modelul „Prădător-Pradă: Oaie vs. Lup” 36

4.4. Descrierea aplicaţiei 43

4.4.1. Ce anume implementăm? 43

4.4.2. Modelul lumii 44

4.4.3. Sistemul multi-agent de control al traficului 46

4.4.3.1. Agentul de intersecţie şi agentul semafor 47

1

4.4.3.2. Agentul de control al intersecţiei 49

4.4.3.3. Comunicarea inter-agenţi 51

4.4.4. Scenarii 52

4.4.4.1. Scenariul 1 – Un singur echipaj de intervenţie 52

4.4.4.2. Scenariul 2 – Mai multe echipaje de intervenţie 54

4.4.5. Instrumente 55

4.4.5.1. Butoane 56

4.4.5.2. Elemente de tip Slide-Bar 56

4.4.5.3. Monitoare 58

4.4.5.4. Reprezentări grafice 58

4.5. Rezultate simulări 60

4.5.1. Scenariul 1 – Un singur echipaj de intervenţie 60

4.5.2. Scenariul 2 – Mai multe echipaje de intervenţie 62

5. CONCLUZII 68

6. ANEXE 70

6.1. Procedura SETUP 70

6.2. Procedura GO 73

7. BIBLIOGRAFIE 76

2

1. INTRODUCERE

La mai puţin de 100 de ani de la apariţia primelor realizări în domeniul

sistemelor de calcul, ne aflăm într-o perioadă în care aproape oriunde şi în orice

domeniu există un sistem de conducere: procese de fabricaţie, mijloace de transport,

echipamente medicale, sisteme de supraveghere etc.

Deşi această evoluţie fulminantă pare că s-a petrecut doar prin încercarea de a

se îmbunătăţi performanţele proceselor, există totuşi un criteriu de care s-a ţinut cont în

mod special: siguranţa. Omul, prin natura lui, caută să îşi asigure securitatea, să

gândească, să creeze şi să construiască medii de viaţă în care să se simtă în siguranţă.

Un domeniu în care s-a investit mult şi s-au făcut progrese majore este protecţia

seismică. Într-o lume în care tot ce este antropologic este relativ uşor de controlat şi de

observat, singurele sincope majore care pot apărea în încercarea de a trăi în siguranţă

sunt cauzate de fenomenele naturale, care sunt greu de prezis şi imposibil de controlat.

Unul dintre cele mai distrugătoare fenomene ale naturii este cutremurul, mai ales că

afectează major punctele cheie ale mediului în care funcţionează societatea: clădirile.

Progresele făcute în dezvoltarea de tehnologii care să reducă pagubele produse

de seisme asupra clădirilor sunt importante. Dar pe lângă pagubele fizice cauzate asupra

clădirilor, mai există şi pagube colaterale: panică, accidente, blocaje în trafic, daune ale

conductelor de alimentare (gaz, apă), incendii, victime etc. Astfel, în ultimul timp a

apărut şi o direcţie aparte de dezvoltare a strategiilor împotriva seismelor: rezolvarea

urgenţelor apărute în urma unui seism major. Pentru că în astfel de situaţii timpul este o

variabilă critică, complexitatea sistemului generat de aceste urgenţe este imensă. Astfel,

apare nevoia unei paradigme care să fie capabilă să proceseze rapid informaţiile, să le

comunice eficient şi să rezolve situaţiile apărute cu un minim de pierderi de resurse, fie

3

ele umane şi/sau materiale. Una din paradigmele care ar putea face faţă acestor cerinţe

ar fi modelarea (unui sistem de monitorizare şi/sau control al situaţiilor critice) bazată

pe agenţi sau, mai precis, un sistem multi-agent.

În lucrarea de faţă, voi modela un sistem multi-agent, care să gestioneze traficul

în situaţii de urgenţă (blocaje, ambuteiaje, accidente) şi să ofere o viteză ridicată de

deplasare a maşinilor de intervenţie, care să reducă numărul victimelor şi proporţiile

pagubelor materiale. De asemenea, simularea cuprinde şi reprezentări grafice şi

instrumente de monitorizare ale agenţilor, precum şi posibilitatea de a efectua

modificări ale datelor şi variabilelor, care afectează mai mult sau mai puţin evoluţia

sistemului.

Pentru o mai bună înţelegere a modelului implementat, capitolul 2 cuprinde

informaţii legate de noţiunea de agent inteligent, drumul până la definitivarea acestei

noţiuni, primele implementări ale sistemelor cu agenţi inteligenţi. Tot în acest capitol

voi prezenta conceptul de sistem multi-agent, modul lui de comportare, cum se

implementează, precum şi câteva aplicaţii şi/sau implementări făcute până acum.

În capitolul 3, sunt prezentate pe scurt informaţii legate de primele proiecte care

au apărut în dezvoltarea sistemelor de gestionare a situaţiilor de urgenţă. Un concept

care cuprinde acest modul, pe lângă multe altele, este Smart City (Oraş Inteligent), care

presupune un nivel înalt de tehnologizare şi mai ales de automatizare al

infrastructurilor, atât fizice, cât şi de comunicaţie.

Capitolul 3 continuă cu prezentarea unui concept care vizează exact problema

managementului în situaţii de urgenţă apărute în urma cutremurelor. Astfel, în

cuprinsul acestui capitol, voi sintetiza conceptul de CitySCAPE, un concept care

integrează cerinţele unui oraş inteligent, bazat pe o structură multiagent, pentru a reliefa

utilitatea aplicaţiei care însoţeşte această lucrare.

Studiul de caz din capitolul 4 prezintă implementarea aplicaţiei, programele

informatice utilizate în conceperea acesteia, funcţionalitatea, modul de interacţionare cu

utilizatorul, precum şi alte detalii şi informaţii relevante legate de implementare. De

4

asemenea, sunt ilustrate componentele interfeţei aplicaţiei şi funcţionalitatea ei. Tot aici

vor fi expuse şi rezultatele obţinute în urma simulării a două scenarii.

Conluziile care au fost deduse în urma rezultatelor obţinute şi eventualele

îmbunătăţiri care se pot aduce acestei aplicaţii vor fi tratate în capitolul 5, urmând ca, în

capitolul 6, să prezint procedurile “setup” şi “go”, care stau la baza funcţionării aplicaţiei.

Acestea două conţin alte proceduri, care completează funcţionarea modelului de sistem

multi-agent. Aceste proceduri vor fi explicate prin câteva exemple de cod, însoţite de

descrieri.

5

2. AGENŢI ŞI SISTEME MULTI-AGENT

2.1. Apariţia noţiunii de agent

În zilele noastre, noţiunea de agent sau multiagent este din ce în ce mai des

folosită în construirea diferitelor sisteme inteligente. Domeniile în care întâlnim astfel

de sisteme sunt din ce în ce mai diversificate, astfel că răspândirea agenţilor este absolut

evidentă. Având în faţă acest fapt, întrebarea care se pune este de unde a pornit această

idee /noţiune.

În multe din cărţile sau lucrările care conţin în cuprinsul lor chestiuni legate de

agenţi / multi-agenţi, se tratează o scurtă istorie a originilor acestei idei / noţiuni de

agent. Însă majoritatea lor nu merg foarte departe cu această căutare a originilor, din

raţiuni evidente legate de extinderea lucrărilor respective pe spaţii foarte mari.

Unii autori, (Heath, 2010), consideră că, pentru a ajunge la adevăratele origini

ale noţiunii de agent, trebuie să pornim încă de acum cîteva sute de ani, când oamenii

de ştiinţă ai vremurilor începeau să descopere trăsăturile şi comportamentele sistemelor

neliniare. Există câteva exemple de teorii care au fost lansate de către aceştia (“Mâna

invizibilă” a lui Adam Smith), însă acestea erau imposibil de probat şi chiar erau

considerate doar filosofii, întrucât la vremea aceea exista convingerea că natura are un

comportament pur liniar (filosofie newtoniană) şi că aceste comportamente pot fi

identificate printr-o aproximare. Cu toate că această aproximare nu funcţiona în cazul

oricărui sistem, teoriile de mai sus au rămas privite ca simple filosofii.

Această situaţie era datorată în mare parte faptului că oamenii de ştiinţă nu

aveau la îndemână instrumentele sau mijloacele tehnice necesare pentru un studiu mai

6

aprofundat al sistemelor neliniare. Primii paşi considerabili în această direcţie au fost

făcuţi odată cu inventarea Maşinii Turing, în 1936, de către Alan Turing. Cu toate că

această maşină nu a fost construită, practic, niciodată, ea constituia un experiment

mental despre limitele calcului mecanic. Ideea de bază a acestei maşini era că ea putea să

execute orice procedură matematică, ceea ce a însemnat că maşinile pot reprezenta

sisteme de orice fel. Mai târziu, un alt savant pe nume Alonzo Church, împreună cu

Alan Turing, au lansat o teorie formală a calculului sub numele de Conjectura Church-

Turing, care postulează că orice procedură algoritmică poate fi executată de către o

maşină Turing. Acest fapt însemna, la acel moment, că o maşină poate să memoreze şi

să recreeze sistemele neliniare întâlnite în natură. (Barker-Plummer, 2012)

Următorul pas în dezvoltare a fost făcut de către John von Neumann, la puţin

timp după lansarea primului calculator funcţional, ENIAC. Împreună cu Stanislaw

Ulam, aveau viziunea că, pe lângă uzul de simplu executor de calcule, un calculator

poate folosi la completarea proceselor experimentale. Procesul însemna să construieşti

modelul unui proces pe calculator, rularea experimentului, compararea rezultarelor cu

ipotezele, formarea unei noi ipoteze şi reluarea procesului. Aceasta este de fapt ideea de

bază a unei simulări computerizate. (Heath, 2010)

Mai departe, von Neumann credea că este nevoie de o maşină care să simuleze

complexitatea mediului înconjurător, inclusiv proprietăţi precum auto-multiplicarea. În

acea vreme, filosofia de studiere a sistemelor din natură era de tipul top-down, adică

desfacerea sistemelor complexe în bucăţi mai mici, studierea comportamentelor

bucăţilor şi apoi reformarea sistemului din bucăţile studiate. Ajuns într-un impas,

colegul lui, S. Ulam, i-a sugerat ideea să construiască această maşină pornind de la o

aproximare cu automate celulare, creând astfel complexitatea din aplicarea unor reguli la

nivel de celulă.

Un automat celular este, după cum sugerează şi numele, o entitate care se

autoguvernează, există într-un spaţiu bidimensional de tip tablă de şah şi are capacitatea

de a relaţiona cu entităţile din jurul său. Această gândire de tip automat celular a adus

două contribuţii majore în dezvoltarea aplicaţiilor practice pe care le avea calculatorul la

momentul acela (Heath, 2010). Unu la mână: faptul că celulele pot lua decizii simultan

şi individual şi doi la mână: modificarea logicii la nivel de celulă duce la modificarea

7

comportamentului global, astfel apărând filosofia down-top, care se utilizează în

dezvoltarea domeniului Inteligenţă Artificială.

După construcţia teoretică a maşinii auto-multiplicabile, oamenii de ştiinţă au

început să studieze şi să înţeleagă sistemele din mediul înconjurător cu ajutorul

automatelor celulare. Cel mai cunoscut exemplu este Jocul Vieţii (Game of Life)

(Figura 2.1), propus de Conway (Gardner, 1970). Jocul este o reţea de celule, fiecare

având două stări posibile: vie sau moartă. Vecini ai celulei se consideră celulele adiacent

vertical, orizontal sau diagonal. Conway a propus 4 reguli simple pentru fiecare celulă:

1. Orice celulă vie cu mai puţin de doi vecini vii moare, cauză a subpopulării

2. Orice celulă vie cu doi sau trei vecini vii supravieţuieşte până la următoarea

generaţie

3. Orice celulă vie cu exact trei vecini vii moare, datorită suprapopulării

4. Orice celulă moartă cu exact trei vecini vii devine o celulă vie, ca urmare a

reproducerii

Figura 2.1. Jocul Vieţii (The Game of Life)

(Conway, 1970)

8

După începerea utilizării cu succes a acestei modalităţi de reprezentare a

proceselor din natură, oamenii de ştiinţă din diferite domenii au început să modeleze

diferite sisteme neliniare. Astfel, automatele celulare au ajuns să fie utilizate cu succes în

domeniile tehnologice, dar şi în domenii precum ecologie, biologie, economie sau alte

ştiinţe sociale. În toate aceste domenii de activitate ştiinţifică, existau multe sisteme care

erau extrem de greu de analizat, datorită instabilităţii şi neliniarităţii care le caracterizau.

După implementarea şi sintetizarea rezultatelor modelării şi simulării proceselor

de mai sus, au apărut automate celulare din ce în ce mai performante şi mai autonome,

apărând printre altele şi denumire de agenţi autonomi, care ar îngloba mai multe celule.

În acest moment al dezvoltării apare pentru prima dată denumirea de agent autonom,

urmând ca după însuşirea termenului să apară diferite clasificări şi proprietăţi, care vor fi

tratate mai jos, în subcapitolul următor.

2.2. Definiţiile agenţilor

Etimologia cuvântului „agent” provine din limba latină, de la cuvântul „agere”,

care înseamnă „a face”. De aici putem deduce că un agent inteligent este o entitate care

este derogată să execute anumite instrucţiuni. Dacă aruncăm o scurtă privire în

Dicţionarul Explicativ al Limbii Române, nu întâlnim o definiţie tehnică a termenului

de “agent”, iar termenul de multi-agent nu există. La o căutare rapidă pe internet, apar

dificultăţi de găsire a unei definiţii concrete a termenului, inclusiv la căutări în limba

engleză. De aici putem spune că nu există o definiţie universală, care să încapsuleze

absolut toate proprietăţile unui agent, însă există o multitudine de definiţii acceptate

mai mult sau mai puţin de către lumea academică. Mulţi oameni de ştiinţă au formulat

o definiţie care să fie cât mai concisă, cât mai cuprinzătoare şi cât mai exactă. În (Buiu

& Albu, 2000) apare o listare de definiţii care au fost emise de către oamenii de ştiinţă

care au studiat sistemele cu agenţi inteligenţi.

9

Figura 2.2. Definiţia agentului, conform Russel-Norvig

(Buiu & Albu, 2000)

Definiţia AIMA (Russel-Norvig):

Un agent este orice entitate care poate fi văzut ca percepând mediul prin

intermediul senzorilor şi acţionând apoi asupra mediului prin efectori. (Figura 2.2)

Această definiţie depinde însă de modul de definire a mediului, percepţiei şi acţiunilor.

Dacă mediul este un generator de semnale (percepţii), iar acţiunile sunt considerate

semnale de ieşire, atunci agentul nu se diferenţiază cu nimic faţă de un program

software obişnuit. Această problemă se poate rezolva prin impunerea unei restricţii la

definirea mediului, percepţiei şi/sau acţiunilor. (Buiu & Albu, 2000)

Definiţia Woodridge-Jennings:

Agenţii sunt entităţi cu următoarele proprietăţi: autonomie, abilităţi sociale,

reactivitate, implicare activă, adaptare, mobilitate, veridicitate şi bunăvoinţă. Cu toate că

acestea nu sunt proprietăţile complete ale unui agent, pe baza acestora se poate formula

o definiţie destul de curpinzătoare. (Buiu & Albu, 2000)

Definiţia MuBot:

Termenul de agent este folosit pentru a reprezenta două concepte ortogonale.

Primul se referă la abilitatea de execuţie autonomă a agentului. Al doilea se referă la

abilitatea agentului de a se descărca în medii orientate pe judecată şi raţionament. (Buiu

& Albu, 2000)

10

Definiţia Maes:

Agenţii autonomi sunt sisteme de calcul care „trăiesc” într-un mediu dinamic şi

complex, percep şi acţionează autonom în acest mediu, realizând un set de scopuri sau

task-uri pentru care au fost proiectate. (Buiu & Albu, 2000)

Definiţia KidSim:

Agentul este o entitate software persistentă dedicată unui scop anume. Atributul

de “persistent” distinge agenţii de subrutine: agenţii au propria lor idee despre cum

trebuie dus la îndeplinire task-ul, propria lor agendă de lucru. Noţiunea de “scop

special” distinge agenţii de aplicaţiile multifuncţionale – în general, agenţii sunt mult

mai mici. (Buiu & Albu, 2000)

Definiţia Hayes-Roth:

Agenţii inteligenţi îndeplinesc în mod continuu trei funcţii: precepţia condiţiilor

dinamice ale mediului, acţiunea pentru modificarea condiţiilor mediului şi

logică/raţiune pentru a interpreta percepţiile, a rezolva problemele şi a determina

acţiunile. (Buiu & Albu, 2000)

O completare şi nu neapărat o definiţie, este observaţia lui Foner, care spune că

agentul este neapărat atât inteligent, cât şi autonom (Buiu & Albu, 2000). Tot acesta a

sintetizat şi principalele caracteristici care caracterizează un agent:

1. Autonomie

O autonomie cât mai mare acordată agentului face ca acesta să poată

îndeplini o succesiune de acţiuni independent de utilizator.

2. Caracter

Toţi agenţii trebuie să fie înzestraţi cu educaţia de a executa o acţiune în

diferite moduri. În mod ideal, agenţii ar trebui înzestraţi cu capacităţi de

învăţare şi cu memorie.

3. Comunicativitate

Pentru a fi sigur că agentul îndeplineşte cerinţele, utilizatorul trebuie să

comunice cu acesta. Comunicarea poate fi o simplă conversaţie sau se

11

poate efectua la un nivel mai înalt, în care ambele părţi interacţionează

repetat şi îşi amintesc discuţiile anterioare.

4. Risc şi încredere

Scopul principal al agentului este acela de a prelua din acţiunile

utilizatorului. Această preluare este, practic, o delegare din partea

utilizatorului. Prin aceasta, utilizatorul se supune unui risc ca agentul să

nu execute corect o anumită acţiune. Riscul trebuie echilibrat cu un grad

de încredere, care se bazează pe câtă încredere se poate acorda agentului

şi cât de mult ar costa o greşeală.

5. Domeniul de interes

Domeniul este în strânsă legătură cu caracteristica de mai sus. Astfel,

dacă domeniul de interes este un joc, o greşeală a agentului nu este

semnificativă. Dacă însă vorbim despre domeniul financiar-bancar,

posibilitatea utilizării unui agent este aproape nulă, datorită caracterului

neconsistent şi imprevizibil al agenţilor.

6. Cooperare

Utilizatorul şi agentul colaborează în efectuarea unei anumite acţiuni. În

sistemele orientate pe agenţi, utilizatorul şi agentul se află la acelaşi nivel,

în timp ce în sistemele neorientate pe agenţi, utilizatorul specifică exact

printr-o interfaţă ce acţiune urmează a fi executată

7. Antropomorfism

Cu toate că comportamentul agenţilor ne-ar determina să afirmăm că

toţi agenţii sunt antropomorfi, există şi aplicaţii care pot fi încadrate la

categoria agenţilor, dar nu sunt antropomorfe (ex.: aplicaţiile de sortare a

mailurilor, care învaţă treptat de la utilizator)

8. Mobilitate

Conceptul de agent mobil este ilustrat în figura 2.3

12

Figura 2.3. Structura unui agent mobil

(Buiu & Albu, 2000)

2.3. Clasificarea agenţilor

O clasificare a agenţilor în funcţie de proprietăţile de mai sus este prezentată în

tabelul 2.1. (Buiu & Albu, 2000)

Tabelul 2.1. Clasificarea agenţilor

(Buiu & Albu, 2000)

PROPRIETATE NOŢIUNI

ECHIVALENTE ÎNŢELES

reactiv percepţie şi acţiune răspunde la schimbările

mediului

autonom exercită control asupra

propriilor sale acţiuni

orientat pe scop

nu este limitat la a

reacţiona la schimbările

mediului

continuu în timp este un proces care se

derulează încontinuu

comunicativ abilitate socială comunică cu alţi agenţi,

inclusiv cu oameni

13

cu învăţare adaptiv îşi schimbă comportarea pe

baza experienţei acumulate

mobil capabil să se mişte de la o

maşină la alta

flexibil acţiunile nu sunt

prestabilite

caracter

„personalitate” de încredere

şi cu stări emoţionale

stabile

O altă clasificare a agenţilor a fost realizată de Hyacinth Nwana, care consideră

că agenţii trebuie clasificaţi urmând câteva atribute principale pe care ar trebui să le

manifeste (Buiu & Albu, 2000). Conform acestei clasificări, agenţii ar trebui să aibă

următoarele trei atribute: autonomie, învăţare şi cooperare. În figura 2.4., este

prezentată clasificarea agenţilor gândită de către Nwana.

Figura 2.4. Clasificarea agenţilor conform lui Nwana

(Buiu & Albu, 2000)

După cum se observă în figura de mai sus, Nwana împarte agenţii în patru categorii:

Agenţi colaborativi

Agenţi colaborativi care învaţă

Agenţi de interfaţă

Adevăraţii agenţi inteligenţi

14

O a treia clasificare a agenţilor ar fi clasificarea după aşa-zisa taxonomie,

conform căreia agenţii se clasifică în felul următor:

Figura2.5. Clasificarea agenţilor bazată pe taxonomie

(Buiu & Albu, 2000)

2.4. Implementări ale agenţilor

În lumea tehnologiei, termenul de agent inteligent este adesea utilizat ca agent

software inteligent, pentru că marea majoritate a aplicaţiilor care utilizează agenţi sunt

aplicaţii software. Astfel, în mod practic, când vorbim de agenţi, vorbim de fapt despre

agenţi software.

Agenţii software sunt, aşa cum spune şi numele, programe sau aplicaţii

construite prin programarea într-un limbaj orientat pe agent. O definiţie concludentă şi

concisă este următoarea: agentul este o entitate software care funcţionează în mod

continuu şi autonom într-un mediu înconjurător format deseori din alţi agenţi şi/sau

procese. Cu alte cuvinte, un agent este independent şi funcţionează mult timp, şi nu are

nevoie mereu de ghidare şi intervenţii din partea utilizatorului. (Serenko & Detlor,

2004)

15

Ca mod de implementare în viaţa de zi cu zi şi în tehnologia răspândită în

societate, agenţii pot fi împărţiţi în trei categorii principale: agenţi utilizator, agenţi de

servicii şi agenţi independenţi. Această împărţire în categorii se referă la modul de

interacţionare a agenţilor cu alţi agenţi, cu alte programe, cu alţi utilizatori şi cu oamenii

sau cu grupuri de oameni. (Serenko & Detlor, 2004)

Agenţii utilizator se referă la acei agenţi care sunt integraţi în cadrul altui

software, făcând utilizarea acestuia mult mai atractivă şi mai interactivă. Aceşti agenţi

interacţionează direct cu utilizatorul şi cu sistemul (softul), punând la dispoziţia

utilizatorului chestiuni diverse pe care sistemul nu le poate asigura de unul singur,

asigurând o utilizare mai uşoară şi mai practică a softului. Exemplele cele mai elocvente

ale unor astfel de agenţi sunt asistenţii inteligenţi implementaţi în serviciile de e-

mailing, care ajută utilizatorul să îşi aranjeze toate e-mailurile primite. Această aranjare

presupune ca agentul să observe şi să înveţe din acţiunile utilizatorului, înregistrează e-

mailurile primite şi trimise, adresele către/de la care au fost trimise/primite e-mailurile,

reţine ce e-mailuri au fost şterse, iar pe baza acestor informaţii culese, construieşte un

profil al utilizatorului. Pe baza acestui profil, agentul poate face sugestii utilizatorului

pentru următoarea acţiune, făcând mai practică această activitate. (Serenko & Detlor,

2004)

Agenţii de servicii sunt integraţi ca parte a unor sisteme foarte complicate. De

multe ori, utilizatorul nu este conştient că există agenţi care execută părţi din atribuţiile

sistemului respectiv. Astfel, scopul acestor agenţi este să crească eficienţa şi/sau

flexibilitatea serviciilor oferite se sistem, să asigure o viteză de transfer de date ridicată,

să reducă costurile aferente procesării informaţiei şi să redistribuie în mod inteligent

traficul existent în reţeaua internă a sistemului. Agenţii de servicii sunt implementaţi în

aplicaţiile deja folosite de companii sau utilizatori individuali, care, însă, erau oarecum

depăşite, pentru ca aceste aplicaţii să aibă parte de o îmbunătăţire substanţială a

performanţelor. Pentru că nu au o prezenţă foarte evidentă în sistemele în care sunt

implementaţi, agenţii de servicii nu beneficiază de o inovativitate mare, proiectarea lor

având accentul pus pe eficientizare şi îmbunătăţire a performanţelor unor diverse

sisteme. (Serenko & Detlor, 2004)

16

Agenţii independenţi sunt construiţi pentru a înlocui aplicaţiile existente în

diferite domenii, pentru a oferi mai multe servicii şi pentru a spori interactivitatea

aplicaţiei. Aceşti agenţi sunt prevăzuţi cu un nivel mare de inovativitate, pentru că nu

sunt parte a unui sistem, ci chiar ei înşişi constituie sistemul. Implementările acestor

agenţi au fost numeroase mai ales în domeniul cumpărăturilor pe Internet, pentru că

agenţii au capacitatea de a procesa un volum mare de informaţii. Un astfel de agent este

WhenUShop, care poate fi instalat într-un browser de internet ca un simplu toolbar, iar

scopul lui este să analizeze site-ul comercial, ofertele acestuia, să găsească detaliile

produselor, iar la sfârşit să comunice detaliile relevante despre un anumit produs către

un utilizator. (Serenko & Detlor, 2004)

După cum reiese din această clasificare, agenţii sunt la bază programe obişnuite,

însă sunt înzestraţi cu capacităţi distinctive precum învăţare, autonomie, comportament

propriu şi flexibilitate.

2.5. Sisteme multi-agent

Aşa cum precizam la începutul capitolului, termenul de multi-agent nu are o

definiţie concisă în Dicţionarul Explicativ al Limbii Române, însă este uşor de dedus

care este definiţia sau sensul acestui termen. Un sistem multi-agent este un sistem

format din mai mulţi agenţi, de diferite tipuri, care conlucrează pentru a rezolva

anumite cerinţe sau pentru a asigura anumite performanţe ale unor sisteme. Per

ansamblu, domeniul de studiu al sistemelor multi-agent se ocupă cu analiza şi

dezvoltarea de arhitecturi sofisticate de control şi rezolvare de probleme în domeniul

Inteligenţei Artificiale. (Schurr et al., 2005)

Sistemele multi-agent se folosesc îndeosebi atunci când vorbim despre sisteme

de o mare complexitate, fie că vorbim despre viteză de procesare mare, sau despre

întinderea sistemului pe o arie largă. De fapt, prin complexitate mărită înţelegem faptul

că pentru un sistem monolitic sau pentru un singur agent ar fi foarte greu sau chiar

imposibil să satisfacă cerinţele sistemului. Astfel, sistemele multi-agent sunt o soluţie

practică pentru a putea modela şi rezolva sisteme complexe.

17

În fond, un sistem multi-agent are foarte multe asemănări cu un sistem social,

atât ca structură, cât şi ca funcţionalitate. Să luăm ca exemplu de sistem social o

companie, care este împărţită pe departamente. Fiecare departament se ocupă cu

anumite activităţi, comunică cu celelalte departamente, se coordonează reciproc, totul

pentru un anumit scop – aici fiind vorba de profit. Analog, un sistem multi-agent este

format din mai mulţi agenţi. Fiecare agent are anumite atribuţii, comunică cu ceilalţi

agenţi şi se coordonează reciproc, pentru a satisface anumite cerinţe ale sistemului – aici

vorbim de performanţe impuse.

2.6. Implementări ale sistemelor multi-agent

Sistemele multi-agent sunt folosite în diverse domenii, precum modelarea

sistemelor sociale (Davidsson, 2000), comerţ online, răspunsul la dezastre (Schurr et al.,

2005), controlul traficului etc. Toate aceste sisteme folosesc comunicarea inter-agenţi şi

comunicarea cu utilizatorii pentru a duce la bun sfârşit anumite cerinţe.

Sistemele multi-agent folosite pentru modelarea sistemelor sociale se bazează pe

considerarea drept agent a oricărei componente a mediului sistemului social. Astfel,

prin atribuirea unor reguli şi comportamente, sistemul multi-agent modelează

comportamentul global al sistemului social în cauză. Scopul acestor modelări este acela

de a observa importanţa anumitor variabile sau reguli în comportamentul unui agent,

precum şi ponderea acestora în comportamentul global al sistemului social.

Aşa cum spuneam şi în primul capitol, în cazul unor situaţii de urgenţă timpul

este o variabilă critică. Iar cantitatea de informaţii care trebuie transmisă imediat după

producerea unui dezastru natural este imensă, astfel că sistemele multi-agent ar putea

prelua această complexitate, pentru o gestionare cât mai eficientă. În prezent există

câteva concepte şi prototipuri ale sistemelor multi-agent care să asigure un răspuns cât

mai bun la problemele care ar putea apărea în urma unor dezastre naturale.

18

Conceptul pe care mă voi baza în realizarea aplicaţiei este denumit CitySCAPE

(Pătraşcu, 2011), o arhitectură care urmăreşte realizarea unui sistem de răspuns la

dezastre naturale, atât din punct de vedere structural, la nivel fizic, cât şi din punct de

vedere social, la nivel de societate. Acest concept va fi prezentat mai pe larg în capitolul

următor. Pe lângă acest concept, există şi un prototip de sistem software care

gestionează răspunsul la dezastre: DEFACTO (Demonstrating Effective Flexible

Agent Coordination of Teams through Omnipresence). Acest software pune la

dispoziţia utilizatorului uman un vizualizator, care îi permite să aibă o interacţiune

omniprezentă cu agenţii. Pe lângă acest instrument, DEFACTO mai pune la dispoziţie

un vizualizator 3D, care ajută utilizatorul uman să înţeleagă comportamentul global al

agenţilor. Pentru o vizualizare a fiecărui task al agenţilor sau al utilizatorului uman,

există şi un mod de vizualizare 2D, care permite afişarea tuturor taskurilor individuale.

(Schurr et al., 2005)

Figura 2.6. Imagini din aplicaţia DEFACTO

(Schurr et al., 2005)

O altă implementare foarte utilizată a sistemelor multi-agent se referă controlul

inteligent al traficului din aglomerările urbane. În zilele noastre, traficul este dirijat şi

reglat cu ajutorul semafoarelor montate în intersecţii, care reglează timpul de aşteptare

al autoturismelor până să intre în intersecţie. Problema acestui sistem este că durata de

19

aşteptare este fixă şi nu se adaptează la traficul curent. Soluţia acestei probleme a venit

odată cu apariţia sistemelor multi-agent: fiecare intersecţie a unei aglomerări urbane

este dotată cu semafoare controlate de agenţi. Aceşti agenţi cooperează şi comunică

pentru a menţine timpul de aşteptare global al autoturismelor la un nivel cât mai mic.

Există numeroase exemple de implementări, însă în lucrarea de faţă voi prezenta

o singură idee de implementare, idee pe care am utilizat-o în programarea aplicaţiei. În

(Hirankitti et al., 2007), se consideră o intersecţie a două drumuri cu câte 3 benzi pe

sens (de menţionat: implementarea este făcută pentru un trafic adaptat cerinţelor legale

din Marea Britanie: circulaţia se desfăşoară pe banda din stânga). Astfel, precum reiese

din figura 2.7, există un număr de 12 combinaţii ale luminilor semafoarelor. Agenţii

sunt conştienţi, prin intermediul senzorilor, câte maşini aşteaptă pe fiecare bandă, pe

fiecare drum, iar în funcţie de aceste numere, ia o decizie cu privire la combinaţia de

lumini ale semafoarelor necesară pentru a reduce acest număr.

Figura 2.7. Structura intersecţiei şi combinaţiile posibile de lumini ale semafoarelor

(Hirankitti et al., 2007)

Aceşti agenţi care controlează intersecţiile comunică între ei, transmiţând date

privitoare la densitatea traficului, lungimea cozii de aşteptare, precum şi direcţiile în

care vor ieşi autoturismele din intersecţie. Astfel, dacă un agent decide să dea liber

autoturismelor care virează dreapta, alertează agentul din intersecţia vecină că urmează

să sosească un număr de autoturisme în acea direcţie. (Figura 2.8)

20

Figura 2.8. Structura sistemului multi-agent de control al traficului

(Hirankitti et al., 2007)

Prin această comunicare, sistemul multi-agent rezolvă uşor problemele de trafic,

sau, mai bine zis, reduce timpul de aşteptare al autoturismelor faţă de un sistem de

control de trafic obişnuit.

21

3. SMART CITY ŞI CitySCAPE

3.1. Conceptul Smart City

În contextul modernizării tuturor domeniilor la nivelul tehnologiei secolului 21,

au apărut şi câteva idei şi concepte legate de necesitatea modernizării filozofiei de

urbanism, ajungându-se astfel la termenul de oraş inteligent. În zilele noastre,

performanţele urbanistice nu mai depind numai de dotările şi infrastructura fizică a

oraşului, ci şi de calitatea infrastructurii sociale (capitalul intelectual şi social) a oraşelor,

care determină, în fond, competitivitatea între oraşe. (Caragliu et al., 2009)

Noţiunea de oraş inteligent, ne duce, astfel, cu gândul la o simbioză între

infrastructura fizică şi infrastructura socială, totul construit pe baza tehnologiilor de

informaţii şi comunicare (TIC). O definiţie exactă a acestui concept a fost dată de N.

Komninos, în anul 2006. El consideră că un oraş inteligent este constituit pe trei

dimensiuni, integrând inteligenţa umană (a individului), inteligenţa colectivă şi

inteligenţa artificială disponibilă în oraş. (Komninos, 2006)

Prima dimensiune se referă clar la creativitatea şi inventivitatea individului care

trăieşte în oraş. Aceste calităţi ale individului îşi lasă amprenta pe modul în care se

organizează instituţiile, întreprinderile şi viaţa socială. A doua dimensiune se referă la

capacitatea comunităţilor de oameni de a conlucra şi de a comunica. Aici vorbim de

colaborarea între diferite instituţii şi/sau întreprinderi. A treia dimensiune se referă la

elementele inteligenţei artificiale integrate în infrastructura de comunicaţii a oraşului şi

în tot ceea ce înseamnă spaţiu digital. (Komninos, 2006)

Practic, un oraş inteligent determină o zonă care integrează activităţi bazate pe

cunoaştere; rutine de cooperare socială, care să determine schimbul de cunoştinţe şi

22

inovaţia; infrastructură avansată de comunicaţii pentru managementul de cunoştinţe şi

inovaţii; şi abilităţi de a rezolva probleme de ultim moment, bazate pe capacităţile

inteligente ale echipamentelor existente.

Conceptul de SMART City este un derivat al conceptului de oraş inteligent, dar

care se bazează mai mult pe sisteme integrate, senzori şi aplicaţii interactive. Totuşi,

ideea de bază rămâne: integrarea inteligenţei umane, inteligenţei sociale şi inteligenţei

artificiale.

Totuşi, ca să definim concis acest concept de SMART City (numit în

continuare “oraş inteligent”), există un model de oraş inteligent, elaborat de

Universitatea Tehnică din Viena, în colaborare cu Universitatea din Ljubljana şi

Universitatea Tehnică din Delft, care a constituit în cele din urmă modelul european de

oraş inteligent.

Oraşul inteligent, conform modelului european (SCREC, 2007), este un oraş

care îmbină şase caracteristici (Figura 3.1), determinate de dotările şi activităţile unor

cetăţeni prezenţi în viaţa civică, independenţi şi stăpâni pe propriile decizii. Astfel, un

oraş inteligent ar trebui să aibă performanţe în economie, mobilitate (transport),

protecţia mediului înconjurător, să aibă oameni capabili şi calificaţi, activi în viaţa

socială, să aibă o guvernare inteligentă şi, nu în ultimul rând, un nivel de trai ridicat

(educaţie, sănătate, turism, cultură etc.).

Figura 3.1. Modelul european de oraş inteligent

(SCREC, 2007)

23

În momentul de faţă, există câteva oraşe pe planetă care au implementat acest

concept, la o scară mai mult sau mai puţin extinsă, încercând să se modernizeze. Printre

aceste oraşe, amintim Amsterdam, Dubai, Malaga, Cairo, Malta SmartCity.

Figura 3.2. Amsterdam Smart City / Malaga Smart City

(ASC, 2012) (SCM, 2012)

Un oraş inteligent este alcătuit din mai multe componente, de altfel, ca orice

oraş normal: clădiri, drumuri, uzine etc. Astfel, conceptul de oraş inteligent poate fi

construit din noţiunile de clădire inteligentă, control al traficului inteligent etc. Aceste

noţiuni au început să fie implementate nu neapărat în cadrul unor proiecte de dezvoltare

la nivel de oraş inteligent, ci şi ca paşi importanţi către construirea unei structuri de oraş

inteligent.

Sistemele inteligente au început să fie implementate pe din ce în ce mai multe

clădiri, pentru că aceste construcţii consumă 70% din energia totală consumată şi peste

35% din emisiile de carbon (Bartlett, 2012). Astfel, o gestiune inteligentă a resurselor ar

duce la reducerea acestor valori şi, implicit, la un mediu încojurător mai sănătos.

Analog, asigurând o gestiune inteligentă a traficului, emisiile de carbon ar scădea

considerabil, având aceleaşi efecte benefice asupra mediului înconjurător.

Pe lângă oraşele care deja au implementat câteva elemente ale unui oraş

inteligent, pe planetă apar din ce în ce mai multe proiecte de modernizare a oraşelor în

această direcţie, semn că populaţia globului este conştientă de necesitatea acestei

schimbări de viziune asupra urbanismului şi de beneficiile care apar atât la nivel local,

cât şi la nivel global. Companiile care se ocupă cu implementarea echipamentelor,

24

dezvoltarea aplicaţiilor ş.a.m.d., au început să lanseze propriile viziuni ale structurii unui

oraş inteligent.

Compania Hitachi a lansat în 2010 propriul concept privind structura unui oraş

inteligent. După cum se observă în figura 3.3, ei consideră că un oraş inteligent are în

centrul structurii sale un management al oraşului, orientat pe dezvoltare, iar în jurul

acestui centru se află 3 componente esenţiale: energie, transport şi mediu înconjurător.

Fiecare dintre acestea alcătuiesc o infrastructură inteligentă (dotată cu senzori şi

elemente de execuţie), iar aceste infrastructuri sunt interconectate pentru a asigura o

creştere a nivelului de trai al locuitorilor. (Kohno, 2010)

Figura 3.3. Conceptul de Smart City, în viziunea Hitachi

(Kohno, 2010)

Conceptul SMART City reprezintă o viziune de viitor către care tinde

organizarea oraşelor secolului 21. Infrastructura de oraş inteligent, în forma prezentată,

permite (şi necesită) integrarea protecţiei structurilor fizice şi sociale împotriva

dezastrelor naturale, precum seismele.

25

3.2. Conceptul CitySCAPE

După cum am prezentat în paragrafele anterioare, există deja câteva oraşe care

au implementat conceptul de oraş inteligent la diferite nivele de autonomie şi

inteligenţă. Cu toate că atributele de oraş inteligent înseamnă multe direcţii de

implementare, pentru această lucrare, dupa cum spuneam şi în introducere, doresc să

dezvolt mai mult partea referitoare la controlul inteligent al oraşului în cazul unor

dezastre naturale (în particular, seisme), şi aici mă refer atât la perioada de manifestare a

fenomenelor, cât şi la perioada imediat următoare, aceea de limitare a pagubelor şi de

rezolvare a urgenţelor.

Un astfel de concept referitor la protecţia inteligentă împotriva seismelor la nivel

de oraş, nu numai de clădire, este CitySCAPE (Pătraşcu, 2011) – a Synergic Control

Architecture for Protection against Earthquakes.

CitySCAPE este o arhitectură care controlează şi monitorizează sistemele de

protecţie seismică, atât la nivel structural, cât şi la nivel social. Aceste două componente

sunt interconectate, acest fapt fiind evident, deoarece scopul unei clădiri este acela de a

găzdui activitatea umană. Scopul CitySCAPE este acela de a prezenta o viziune

modulară, ierarhizată, îndeplinind principalele caracteristici ale unui sistem de protecţie

seismică: asigurarea parametrilor de protecţie seismică, toleranţă la defecte,

implementabilitate, autonomie în funcţionare, integrarea infrastructurilor existente,

raport convenabil complexitate/cost. (Pătraşcu, 2011)

3.3. Structura şi funcţionalitatea CitySCAPE

La nivel macroscopic, CitySCAPE este format din două subsisteme

interconectate şi interdependente: eSCAPE şi inSCAPE. Amândouă sunt la fel de

importante privind funcţionarea CitySCAPE, integrând atât componente hardware, cât

şi factorul uman. (Figura 3.4.)

26

Figura 3.4. Structura CitySCAPE la nivel macroscopic

(Pătraşcu, 2011)

eSCAPE – Emergent CitySCAPE: Acest sistem modelează, controlează şi

monitorizează protecţia entităţiilor vii. eSCAPE priveşte sistemul social şi

comportamentele indivizilor umani în timpul cutremurelor ca un tot unitar, construind

o reţea de comunicaţie flexibilă. (Pătraşcu, 2011)

inSCAPE – Integrated Network CitySCAPE: acest sistem integrează şi

interconectează un sistem ierarhizat de control al vibraţiilor seismice. (Pătraşcu, 2011)

3.4. eSCAPE

În continuare, voi prezenta pe larg conceptul de eSCAPE, deoarece în lucrarea

de faţă va fi implementat un model al unei componente a acestui concept. Aşa cum am

menţionat mai sus, eSCAPE este responsabil de modelarea, controlarea şi

monitorizarea comportamentului uman şi a sistemului social în condiţii de dezastre

naturale.

Pentru a putea efectua aceste funcţii asupra sistemului social, considerăm că

eSCAPE este format din ţesuturi, care reprezintă o parte a sistemului de protecţie.

Deosebim 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

27

dispozitive de control, percepţie şi acţionare, precum şi un dispozitiv de comunicaţie

(Pătraşcu, 2011). O structură este prezentată vizual în figura 4.2.

Figura 3.5. eSCAPE (Pătraşcu, 2011)

Cele 4 ţesuturi, părţi ale sistemului de protecţie, sunt:

1. controlul traficului

2. avertizări şi controlul panicii

3. intervenţie echipaje de urgenţă

4. protocoale sisteme critice

În această lucrare, pentru partea aplicativă, voi trata două dintre aceste patru

ţesuturi: controlul traficului şi intervenţia echipajelor de urgenţă. După cum am arătat

mai sus, un ţesut este compus din mai multe dispozitive. În cazul ţesutului responsabil

cu controlul traficului, aceste dispozitive sunt:

- dispozitivele de control: pot fi considerate microprocesoare, pe care sunt

implementaţi algoritmii care definesc agenţii

- dispozitivele de percepţie: sunt senzorii care măsoară debitul traficului,

- dispozitivele de acţionare: sunt exact echipamentele care formează

fazele luminoase ale semafoarelor.

Cât despre dispozitivele de comunicaţie, alegerea acestora depinde foarte mult

de infrastructura fizică, de mediu, de aria acoperită şi de posibilităţile tehnologice, astfel

că aceste dispozitive pot fi routere wireless, module GPRS, comunicaţie prin satelit etc.

28

În lucrarea de faţă va fi modelat, cu ajutorul unui sistem multi-agent, ţesutul

responsabil cu controlul traficului, în timp ce ţesutul responsabil de intervenţia

echipajelor de urgenţă va fi modelat parţial, pentru a scoate în evidenţă interacţiunile

dintre aceste două componente. Astfel, ţesutul responsabil cu intervenţia echipajelor de

urgenţă este reprezentat în aplicaţie prin modulul de comunicaţie şi “dispozitivele de

acţionare”, care iau forma fizică a autoutilitarelor de intervenţie.

În capitolul următor, voi prezenta în detaliu cum sunt reprezentate aceste două

ţesuturi în cadrul aplicaţiei.

29

4. STUDIU DE CAZ

Așa cum reiese din capitolele anterioare, partea aplicativă a acestei lucrări este

implementarea unui sistem inteligent multiagent, care să rezolve problema traficului şi a

deplasării echipajelor de intervenţie. Bineînţeles, proporţiile acestei aplicaţii sunt reduse,

dar esenţa lumii reale este reprezentată cu succes în cadrul simulat.

Aplicaţia care urmează a fi prezentată în paginile următoare se bazează pe câteva

cercetări făcute de către lumea academică în domeniul controlului de trafic şi a

modalităţilor de reprezentare a acestuia în lumea digitală. Din aceste cercetări am făcut

şi alegerea mediului de programare în care am programat aplicaţia, la baza acestei

alegeri stând multitudinea de cazuri în care s-a apelat la această soluţie..

4.1. Programarea orientată agent

Acest concept a apărut odată cu definitivarea denumirii acestei porţiuni a

domeniului inteligenţă artificială şi de la apariţie până în prezent a avut o evoluţie

importantă. Deşi la prima vedere pare că este acelaşi lucru cu programarea orientată pe

obiecte, diferenţa apare la gradul de libertate care se acordă aplicaţiei şi încrederea în

deciziile acesteia. De asemenea, o altă diferenţă majoră între aceste două „paradigme”

este că programarea orientată agent conferă aplicaţiei şi posibilitatea de a învăţa în timp

să ia decizii, bazate sau nu pe un model al utilizatorului.

Conform (Buiu & Albu, 2000), diferenţa esenţială între programarea orientată

pe obiecte (POO) şi cea orientată agent (POA) constă în limbajul interfeţei. Dacă în

POO înţelesul unui mesaj variază de la un obiect la altul, în POA agenţii folosesc un

limbaj comun, cu o semantică independentă de agent.

30

Astfel, POA dă naştere unor întrebări importante: care este limbajul potrivit

pentru comunicarea interagenţi şi cum construim agenţi care să comunice în acest

limbaj? (Buiu & Albu, 2000) În momentul de faţă există două modalităţi de

reprezentare a limbajul de comuicaţie inter-agenţi: limbaje de scripting şi limbaje bazate

de structuri declarative. Este evident faptul că, la ora actuală, predomină limbajele

bazate pe scripting, dar, pe termen lung, se preconizează schimbări majore legate de

construirea comunicaţiei inter-agenţi.

4.2. Alegerea mediului de programare: NetLOGO

Alegerea mediului de programare a fost făcută pe baza faptului că în majoritatea

aplicaţiilor pe care le-am găsit pe această tema erau programate în acest mediu.

NetLOGO (Wilensky, 1999) este un mediu de programare care utilizează programarea

tip scripting şi este foarte accesibil datorită limbajului procedural. După cum reiese şi

din prezentarea făcută în documentaţia care însoţeşte aplicaţia, NetLOGO este un

mediu de programare şi modelare a fenomenelor naturale şi sociale. A fost lansat de

către Uri Wilensky în anul 1999, iar de atunci este în continuă dezvoltare.

În particular, NetLOGO este foarte performant în modelarea sistemelor

complexe în timp. Programatorul poate da instrucţiuni la sute de agenţi independenţi,

astfel având acces la conexiunea care există între nivelul micro, al agenţilor, şi nivelul

macro, care este comportamentul care reiese din interacţiunea agenţilor. Este un mediu

de programare flexibil, care permite modificarea unor parametri, pentru a observa

influenţa acestora asupra sistemului.

NetLOGO este un program care este accesibil şi studenţilor începători, dar

conferă şi instrumente puternice pentru programatorii experimentaţi şi, cel mai

important, probabil, este un software free-source. De asemenea, dispune de o

documentaţie bine pusă la punct şi organizată. Pe lângă modulele de învăţare şi

documentaţie, NetLOGO vine la pachet cu câteva zeci de exemple de simulări ale

fenomenelor naturale şi sociale, care pot fi rulate, modificate şi studiate.

31

Un alt punct forte este faptul că simulările sunt bazate pe maşina virtuală Java,

astfel că aplicaţiile construite în acest program sunt disponibile pe toate sistemele de

operare.

4.3. Particularităţi de programare în limbajul NetLOGO

NetLOGO (Figura 4.1.) este un limbaj foarte eficient de programare orientată

agent, deoarece conţine o multitudine de funcţii şi proceduri care permit utilizatorilor

începători să se descurce uşor la programare, iar utilizatorilor avansaţi să modeleze

sisteme foarte complexe. În această secţiune voi prezenta modul în care se programează

un model / o simulare în NetLOGO, precum şi câteva funcţii / proceduri pe care le-am

folosit în dezvoltarea aplicaţiei.

Figura 4.1. Softul NetLOGO, versiunea 5.0

(Wilensky, 1999)

În primul rând, trebuie precizat faptul că NetLOGO este un program în care se

dezvoltă aplicaţii-simulări, adică aplicaţii în care dorim să observăm ce se întâmplă în

cadrul unui sistem complex, de orice fel ar fi acesta. Singura modalitate prin care se

poate interveni în evoluţia aplicaţiei este modificarea valorilor unor variabile care se

reflectă în comportamentul modelului. Practic, NetLOGO ne ajută să construim un

model al unui sistem complex, să setăm câţiva parametri esenţiali în cadrul sistemului şi

să simulăm diferite comportamente ale sistemului pentru anumite valori ale

parametrilor esenţiali.

Termenii cheie pe care se bazează NetLOGO sunt observer (agent observator),

turtle (agent mobil), patch (agent fix) şi un termen mai puţin uzitat, link (legătură).

Absolut toate modelele sistemelor programate în NetLOGO folosesc două butoane:

setup (setări) şi go (execută). După cum reiese evident din numele acestor două butoane,

32

primul setează şi construieşte un model iniţial al sistemului, urmând ca butonul „go” să

execute modificări asupra acestui model iniţial, respectând comportamentul acordat

agenţilor prin programare. O altă precizare care merită făcută este că în NetLOGO

sistemul modelat poartă denumire de „world model” (model de lume). Acest model al

lumii poate fi de două feluri: fix sau continuu. Modelul fix al lumii înseamnă că lumea

este dimensionată la anumite valori, iar limitele sunt bine stabilite. Modelul continuu

înseamnă că lumea are dimensiuni fixe, dar limitele sunt lipite, astfel că dacă un agent

părăseşte lumea prin partea stângă, el va apărea din nou în partea dreaptă. Acest fapt

permite păstrarea unei continuităţi şi a unei complexităţi mai mari a modelului.

Alegerea tipului modelului lumii se face prin accesarea meniului „Settings” (Setări). Tot

aici, se poate stabili o mărime în pixeli a fiecărui agent fix (minim 10 pixeli), precum şi

dimensiunea lumii.

O aplicaţie NetLOGO este compusă din 3 părţi: interface (interfaţă), info

(informaţii cu privire la sistemul modelat) şi code (partea de programare prin cod a

aplicaţiei) (Figura 4.2.). Interfaţa este partea care se vede şi în aplicaţia propriu zisă,

formată din modelul vizual al lumii, diferite instrumente care vor fi descrise mai jos şi

cele două butoane principale. Info este partea în care programatorul informează

utilizatorul cu privire la scopul aplicaţiei, cum funcţionează, ce simulează, influenţa

parametrilor etc. Code este partea în care se descrie printr-un limbaj de programare

comportamentul agenţilor, care va fi evidenţiat vizual în interfaţă.

Figura 4.2. Cele trei părţi ale aplicaţiei: Interface, Info şi Code

(Wilensky, 1999)

33

Referitor la cele trei tipuri de agenţi principali descrişi mai sus, se poate spune că

împreună formează un ansamblu care poate modela orice sistem complex, căci fiecare

are nişte proprietăţi aparte şi funcţii care ajută la modelarea facilă a comportamentelor

acestora. Cheia prin care aceşti agenţi formează o simbioză eficientă se află în

proprietăţile elementare ale acestora. Astfel, agentul observator „vede” întreaga „lume” şi

cunoaşte exact poziţiile şi atribuţiile agenţilor ficşi şi mobili. Agentul mobil îşi asumă

modelarea comportamentelor care presupun migraţie sau mişcare, iar agentul fix are

rolul de a modela „scena” unde se desfăşoară agenţii mobili. Pe lângă aceşti agenţi

principali prestabiliţi, programatorul mai poate defini alte tipuri de agenţi – breeds – cu

nume sugestive, însă aceşti agenţi sunt asemănători cu agenţii mobili, doar denumirea

fiind diferită, cu scopul de a uşura sarcina programatorului.

Agenţii mobili sunt poziţionaţi întotdeauna deasupra agenţilor ficşi, cu

precizarea că agentul fix de „sub” agentul mobil se poate modifica în timp. O analogie

cu acest mod de reprezentare al lumii ar fi modul în care o maşină circulă pe stradă: ea

ocupă un spaţiu anumit la un moment dat, dar apoi înaintează şi ocupă alt spaţiu. După

cum reiese în mod evident, agenţii ficşi sunt, practic, harta lumii modelate, iar agenţii

mobili pot fi oameni, animale, maşini, orice lucru sau fiinţă care posedă proprietatea de

a se mişca. Din această simplă simbioză se pot modela o varietate imensă de sisteme

complexe.

Agenţii ficşi formează harta modelului lumii, astfel că ei trebuie să deţină nişte

coordonate, care să stabilească poziţionarea lor în cadrul lumii. NetLOGO utilizează

pentru acest fapt un sistem de coordonate cartezian, centrul lumii modelate fiind

considerat punctul de origine, de coordonate 0,0. Astfel, agenţii ficşi formează o lume

alcătuită din pătrăţele, fiecare având coordonatele reglate în funcţie de poziţia faţă de

origine.

Exemplul 1: agentul fix aflat în dreapta-sus faţă de origine are coordonatele 1,1

Exemplul 2: agentul fix aflat în stânga-sus faţă de origine are coordonatele -1,1

Pentru a putea efectua modificări asupra parametrilor simulaţi sau pentru a

observa diferite chestiuni legate de modelul sistemului, NetLOGO dispune şi de

34

instrumente care permit utilizatorului să efectueze aceste operaţiuni. Principalele patru

astfel de instrumente le voi prezenta mai jos, alături de scopul acestora: (Figura 4.3)

Figura 4.3. Principalele instrumente ale interfeţei: Switch (a),

Slider-Bar (b), Monitor (c) şi Plot (d)

(Wilensky, 1999)

1. Switch – acest instrument permite utilizatorului să seteze un parametru cu

valorile adevărat sau fals, acest fapt putând să însemne apariţia unor agenţi

sau activarea unor anumite comportamente

2. Slider-Bar (SB) – acest instrument ajută la modificarea valorilor unor

parametri numerici, care ar putea avea o influenţă asupra probabilităţii de

apariţie a unor comportamente sau pur şi simplu valori numerice utilizate în

codul care însoţeşte aplicaţia

3. Monitor – după cum sugerează şi numele, instrumentul „monitor” permite

utilizatorului să urmărească evoluţia unei variabile în cadrul simulării

4. Plot – domeniul ingineriei ar fi incomplet fără graficele care însoţesc peste

tot modelarea sistemelor. Acest instrument permite afişarea unor grafice

actualizate în timp, care se autodimensionează în cazul în care valorile afişate

depăşesc valorile prestabilite pentru grafic

35

Aceste noţiuni fiind însuşite, mai trebuie precizat un singur lucru: modul în care

modelul lumii simulează timpul. Evoluţia în timp a modelului lumii este simulată prin

acţiunea “tick”, care este apelată întotdeauna de butonul “go”. Acest “tick”, echivalentul

tic-ului produs de un ceas, semnalează agenţilor de toate tipurile să efectueze încă un

pas înainte în evoluţia lor. Astfel, butonul “go” execută întreg codul care modelează

comportamentele agenţilor, apoi apelează “tick”, pentru înaintarea în timp, după care

execută din nou codul, pornind de la starea anterioară. Pentru a facilita vizualizarea

comporamentului, NetLOGO pune la dispoziţia utilizatorului un slide-bar special

pentru ajustarea vitezei simulării (numărul de “tick”-uri pe secundă). (Figura 4.4)

Figura 4.4. SB special pentru setarea vitezei de simulare

(Wilensky, 1999)

Pentru a ilustra toate noţiunile de mai sus şi pentru a clarifica modul lor de

funcţionare, voi prezenta mai jos unul dintre primele modele simulate în NetLOGO,

“Wolf-Sheep Predation” (o traducere aproximativă ar fi: “Prădător-Pradă: Oaie vs.

Lup”). (Wilensky, 1999)

4.3.1. Modelul „Prădător-Pradă: Oaie vs. Lup”

Acest model simulează evoluţia populaţiei de oi şi lupi în cadrul unei lumi,

bazată pe nişte reguli biologice simple. Acest model se poate găsi în Biblioteca de

Modele, care se află instalată pe orice model de NetLOGO, sub denumirea de „Wolf

Sheep Predation”. Ideea acestui model este simplă: simularea comportamentelor oilor şi

lupilor, care migrează pentru a-şi asigura supravieţuirea, prin prădare. Regulile sunt

simple: oile consumă iarbă, lupii mânăncă oi. Presupunem că acest model se află deja

deschis pe platforma de lucru din NetLOGO. (Figura 4.5)

36

Primul lucru care se observă este faptul că acolo unde ar trebui să fie reprezentat

modelul lumii, apare o zonă neagră. Pentru a stabili modelul iniţial al lumii, trebuie să

setăm condiţiile acestei lumi. Cum am precizat şi mai sus, acest lucru se face apăsând

butonul „setup”. După ce a apărut un model al lumii, pentru rularea simulării se apasă

pe butonul „go”. Viteza de redare a evoluţiei poate fi controlată cu un SB special aflat pe

partea interfaţă. În cadrul acestui model, agenţii mobili sunt reprezentaţi de oi şi de

lupi, în vreme ce agenţii ficşi alcătuiesc terenul acoperit cu iarbă.

Figura 4.5. Modelul Prădător-Pradă: Oaie vs. Lup [NetLOGO User Manual]

(evidenţierea modelului lumii, variantă grafică)

(Wilensky, 1999)

Setările unui model ne permit să explorăm diferite evoluţii ale lumii şi diferite

comportamente ale agenţilor care „populează” lumea. Schimbând diferite setări sau

variind diferite valori ale parametrilor ce caracterizează agenţii, putem observa evoluţiile

în fiecare din condiţiile setate, fapt care atrage o mai bună cunoaştere a fenomenelor

care se petrec în sistemul modelat. După cum se observă în Figura 4.6, apar butoanele

„go” şi „setup”, precum şi switch-uri şi SB.

37

Figura 4.6. Instrumentele Modelului

(Wilensky, 1999)

În cazul acestui model, switch-urile permit utilizatorului să afişeze sau nu

energia agenţilor (variabilă care determină durata de viaţă) şi să adauge o variabilă care

face sistemul mai complex: „populaţia” de iarbă. Astfel, alături de durata de viaţă

limitată a agenţilor mobili, apare şi durata de viaţă a agenţilor ficşi. SB sunt mai

numeroase în acest model, ele permiţând setarea şi/sau modificarea numărului de lupi,

numărului de oi, rata de natalitate şi succesul în căutarea hranei. Practic, există enorm

de multe combinaţii ale acestor variabile, care duc la evoluţii şi mai variate. O simplă

colectare a acestor date poate duce la concluzii extrem de interesante legate de evoluţia

sistemelor complexe.

Din categoria instrumentelor care ajută la observarea comportamentului

modelului, avem atât instrumentul „plot”, cât şi mai multe instrumente „monitor”. În

Figura 4.7., observăm că instrumentele de monitorizare ne arată numărul de oi,

numărul de lupi, precum şi numărul de agenţi ficşi care conţin iarbă. (menţionez că pe

acest monitor numărul agenţilor ficşi care conţin iarbă este împărţit la 4, pentru a

menţine proporţii asemănătoare între populaţiile agenţilor mobili şi ficşi). Astfel, la

fiecare pas de simulare, putem şti exact care este numărul de agenţi prezenţi pe modelul

lumii.

38

Figura 4.7. Monitoarele şi reprezentarea grafică a Modelului

(Wilensky, 1999)

Pe singurul grafic care este utilizat în această aplicaţie apar exact datele

înregistrate pe monitoare, însă sub o formă care să permită observarea pe timp

îndelungat. Astfel, în loc să privim valori la momente de timp, putem avea o viziune

largă asupra evoluţiei populaţiei de agenţi, fie ei ficşi sau mobili. La fel ca mai sus, din

raţiuni care ţin de menţinerea proporţiilor populaţiilor, pe acest grafic, populaţia

agenţilor ficşi este împărţită la 4. Tot în Figura 4.7, putem observa graficul

necompletat.

Figura 4.8. Modelul lumii, după executarea a 87 de paşi

(Wilensky, 1999)

39

Având explicate funcţionalităţile instrumentelor din partea de interfaţă a

aplicaţiei, putem trece la simularea propriu-zisă. Pentru acest lucru este necesar un

simplu click pe butonul „go”. În figurile 4.8-4.10 se poate observa evoluţia

instrumentelor de afişaj şi a modelului lumii.

Figura 4.9. Monitoarele Modelului, după executarea a 87 de paşi

(Wilensky, 1999)

Figura 4.10. Graficul Modelului, după executarea a 87 de paşi

(Wilensky, 1999)

Partea de interfaţă fiind explicată şi presupus asimilată, trecem la explicarea

părţii de cod. Aici trebuie să începem cu precizarea că limbajul NetLOGO este unul

procedural şi foarte simplu de asimilat, în sensul în care, pentru un vorbitor nativ de

limbă engleză, limbajul este asemănător cu limbajul obişnuit. Fiecare dintre tipurile de

agenţi principali au alăturate un număr mare de proceduri specifice, existând însă şi

proceduri care pot fi apelate de către mai multe tipuri de agenţi.

Legătura cu partea de interfaţă se face tocmai prin instrumentele care se află pe

interfaţă. Practic, fiecare instrument reprezintă pentru partea de cod o variabilă globală

utilizată în programarea comportamentelor. Astfel, un switch setează adevărat sau fals o

variabilă boolean, la fel cum un SB ajustează valoarea numerică a unei variabile

numerice. Asemănător se întâmplă şi cu monitoarele şi graficele, care preiau valorile

acestor variabile globale.

40

Butoanele „setup” şi „go” nu se regăsesc însă ca variabile globale în partea de

cod. Ele sunt reprezentate sub formă de procedură definită de utilizator şi sunt lansate

în execuţie la apăsarea butoanelor. Aici se poate înţelege mecanismul prezentat mai sus,

adică butonul „setup” apelează procedura „setup”, care la rândul ei, în partea de cod,

apelează procedurile responsabile cu stabilirea unui model al lumii iniţial, de la care să

înceapă simularea. La fel, butonul „go”, lansează în execuţie procedura „go”, care, la

rândul ei, apelează procedurile responsabile cu simularea comportamentelor agenţilor.

O altă calitate a limbajului NetLOGO este că este un limbaj structurat şi are şi

un comportament de programare orientată pe obiecte, astfel că este uşor de asimilat şi

de către programatorii obişnuiţi cu această paradigmă. În plus, există o multitudine de

modalităţi în care agenţii pot interacţiona unii cu alţii. Cu toate că, la prima vedere,

limbajul pare greoi, pentru că nu permite folosirea unor proceduri decât în anumite

condiţii, manualul utilizatorului ajută programatorul să găsească procedura potrivită

pentru orice situaţie, prin legături către proceduri similare.

Pentru a ilustra faptul că limbajul este unul uşor de asimilat pentru un vorbitor

nativ de limbă engleză, voi prezenta mai jos câteva din procedurile care se utilizează cel

mai des în simularea comportamentelor agenţilor.

Exemplul 1: procedura ask – după cum sugerează şi numele, această procedură

cere unui agent să execute anumite instrucţiuni

Exemplul 2: procedura set – setează o variabilă globală

procedura let – creează o variabilă locală

Exemplul 3: procedura ask turtles-on patches-here – este o procedură

combinată, din care reiese, pentru un vorbitor nativ de limbă

engleză, că se cere agenţilor mobili aflaţi pe agentul fix curent să

execute o anumită instrucţiune

Pe lângă aceste calităţi legate de sintaxa limbajului, există calităţi esenţiale

privind structura limbajului. NetLOGO oferă auto-indentare şi colorarea cuvintelor

cheie pentru a putea permite programatorului să urmărească codul mai uşor.

Compilatorul acestui cod oferă şi asistenţă la problemele de programare, precizând

inclusiv ce agent utilizează procedura în care a detectat o eroare. (Figura 4.11)

41

Figura 4.11. Exemplu de cod NetLOGO

(Wilensky, 1999)

4.4. Descrierea aplicaţiei

4.4.1. Ce anume implementăm?

Stabilind termenii-cheie şi câteva noţiuni elementare de programare în limbajul

NetLOGO, putem trece la descrierea părţii aplicative a prezentei lucrări. Prima

întrebare care se pune în cadrul oricărei aplicaţii este: ce anume vrem să implementăm?

Aşa cum reiese din capitolele anterioare, în cadrul acestei aplicaţii voi simula un sistem

multi-agent de control al traficului, care să permită unuia sau a mai multor echipaje de

intervenţie să străbată cu un timp minim grupul de intersecţii care alcătuiesc modelul

lumii.

42

Modelul lumii utilizat în mediul NetLOGO este cel continuu, adică odată ce un

agent mobil se îndreaptă către o ieşire şi părăseşte dimensiunile lumii, el va apărea în

mod automat în partea cealaltă a lumii. Agenţii ficşi utilizaţi formează de fapt, o reţea

de drumuri intersectate. Agenţii mobili reprezintă maşinile care circulă pe reţeaua de

drumuri stabilită. Pe lângă aceşti agenţi prestabiliţi, există agenţii inteligenţi care

formează sistemul multi-agent de control al traficului. Fiecare dintre aceşti agenţi

inteligenţi reprezintă o intersecţie semaforizată.

Pentru această simulare a comportării unui sistem de control al traficului, am

considerat un sistem alcătuit din 4 drumuri principale, care se intersectează reciproc,

formând un sistem de 4 intersecţii. Astfel, avem un sistem multi-agent care

funcţionează cu 4 agenţi, scopul acestuia fiind asigurarea unui timp de trecere

(aşteptare) minim al echipajelor de urgenţă ce străbat grupul de intersecţii, în diferite

densităţi de trafic. Pe scurt, obiectivul sistemului este să asigure un timp de aşteptare al

echipajelor de urgenţă mai mic decât timpul mediu de aşteptare al celorlalte maşini.

Pentru a evidenţia modul de funcţionare şi beneficiile acestui sistem multi-

agent, am stabilit pentru partea aplicativă două scenarii, care acoperă câteva situaţii care

ar putea să apară în cazul unor situaţii de urgenţă. Primul scenariu este programat astfel

încât să se evidenţieze funcţionarea sistemului de control al traficului pentru un singur

echipaj de urgenţă. Urmărirea eficienţei acestuia este facilă, deoarece pe graficul aferent

simulării apar doar două curbe (roşu – timpul de aşteptare al echipajului de urgenţă;

albastru – timpul mediu de aşteptare). Al doilea scenariu este mai complex, scopul

acestuia fiind de a demonstra funcţionalitatea sistemului în cazul în care prin reţeaua

formată din cele patru intersecţii trec mai multe echipaje de urgenţă de diferite tipuri

(pompieri, ambulanţă SMURD, poliţie). Modul în care acţionează sistemul multi-agent

este prezentat în detaliu în secţiunile următoare.

43

4.4.2. Modelul Lumii

În primul rând, trebuie să stabilim dimensiunile modelului lumii, tipul acestuia

fiind deja ales. Am considerat un model de dimensiunea 77x49 patches (agenţi ficşi)

pentru a reprezenta cele 4 intersecţii şi diferite valori ale densităţii traficului. (Figura

4.12)

Figura 4.12. Setările Modelului Lumii

Drumurile care formează cele patru intersecţii sunt dispuse orizontal şi vertical,

la distanţe egale între ele şi faţă de margine. Drumurile au câte o bandă pe sens de mers,

sensurile posibile de înaintare fiind N, E, S, V. În cvartalele care mărginesc drumurile

se află clădiri, parcuri, etc. Deşi la prima vedere modelul lumii pare de dimensiuni mici,

complexitatea acestuia este asigurată de setarea modelului continuu, care presupune că

odată ce un agent mobil părăseşte lumea, el apare automat în extrema cealaltă a acesteia.

Astfel construit sistemul de drumuri, el formează patru intersecţii, după cum se observă

44

în figura 4.13. Am implementat câte o singură bandă pe sens, iar maşinile pot trece prin

intersecţie mergând în oricare din direcţiile posibile.

Descrierea modelului lumii nu se încheie aici, deoarece acest model nu este

complet fără agenţii prestabiliţi puşi la dispoziţie de mediul de programare NetLOGO.

Agenţii ficşi sunt în număr de 3773, echivalentul produsului dintre dimensiunile lumii

(77 x 49 agenţi ficşi), astfel că ei formează coordonatele modelului lumii. Agenţii ficşi

îndeplinesc diverse roluri: fie sunt agenţi care reprezintă drumuri, fie reprezintă

intersecţii, semafoare sau mai multe dintre acestea. Restul agenţilor fără importanţă

majoră alcătuiesc restul hărţii: clădiri, parcuri etc. De precizat că, în interfaţă, acest rol

este evidenţiat prin culori specifice.

Figura 4.13. Modelul lumii

Agenţii ficşi au următoarele roluri, în funcţie de culoarea şi/sau poziţia pe care o

ocupă. Astfel, agenţii cu rol de drum sunt coloraţi cu alb, însă la fel sunt coloraţi şi

agenţii cu rol de intersecţii. Diferenţa între aceste două roluri se face prin programare, la

nivel de interfaţă nefiind nicio diferenţă. Lângă agenţii de intersecţie, se află agenţii cu

rol de semafor, care au culoarea verde şi roşu, alternativ, conform stării comandate de

către agentul inteligent care controlează intersecţia. Pe lângă aceşti agenţi importanţi,

45

mai deosebim şi agenţii cu rol de trotuar, care au culoarea gri, precum şi agenţii care

definesc spaţiul înconjurător reţelei de drumuri; ei au diverse culori, diferite însă de cele

folosite pentru evidenţierea agenţilor principali.

Agenţii mobili sunt prezenţi pe harta lumii într-un număr care poate fi setat de

către utilizatorul aplicaţiei (detalii în subsecţiunea 4.4.5.). Ei sunt setaţi să aibă formă de

autoturism, şi la generarea lor pe modelul iniţial sunt plasaţi în poziţii aleatoare, dar pe

agenţi ficşi cu rol de drum. De precizat este că agenţii mobili sunt plasaţi numai şi

numai deasupra unor agenţi ficşi-drumuri simpli, fără alte roluri, iar în funcţie de

poziţia ocupată capătă şi un sens de mers. Aceşti agenţi mobili sunt programaţi să

circule numai pe drumuri, să se oprească la culoarea roşie a semaforului, să vireze în

intersecţii şi să accelereze / frâneze în condiţii de siguranţă. Agenţii mobili sunt coloraţi,

la starea iniţială, în albastru.

4.4.3. Sistemul multi-agent de control al traficului

Având stabilite modelul lumii şi caracteristicile agenţilor prestabiliţi din

NetLOGO, trecem la descrierea modului de funcţionare a agenţilor inteligenţi care

controlează câte o intersecţie şi care formează, împreună, sistemul multi-agent de

control al traficului.

Modelul lumii ales în cadrul acestei aplicaţii conţine patru intersecţii

semaforizate, fiecare dintre aceste intersecţii fiind controlate de către un agent definit

prin programare. Acest agent este diferit de agenţii despre care am scris mai sus, prin

prisma faptului că nu este integrat în structura limbajului NetLOGO, funcţionarea lui

fiind descrisă prin linii de cod. Astfel, trebuie să definim elementele unei intersecţii în

cadrul modelului lumii ales. Funcţionalitatea agenţilor care controlează intersecţiile sunt

identice, astfel că nu este nevoie decât de descrierea unui singur agent.

46

4.4.3.1. Agenţii de intersecţie şi agenţii semafor

După cum se observă în figura 4.14, o intersecţie este formată din patru agenţi

ficşi, de culoare albă, şi patru agenţi ficşi de culoare verde-roşu alternativ. Conform

explicaţiilor de mai sus, aceştia din urmă au rolul de a simula funcţionarea fazelor

luminoase din cadrul unui semafor. Cei patru agenţi de culoare albă joacă rolul de

agenţi de intersecţie.

Figura 4.14. Schema unei intersecţii din cadrul modelului lumii

Agenţii de intersecţie au însuşite, prin programare, câte două direcţii posibile de

deplasare pentru agenţii mobili. Când un agent mobil este suprapus unui agent

intersecţie, el are de ales între două direcţii în care să îşi continue deplasarea. Precum se

observă în figura 4.15, există patru tipuri de agenţi de intersecţie, fiecare având două

direcţii posibile în care permit deplasarea. Pentru o simulare cât mai apropiată de

realitate, agenţii mobili sunt setaţi să aibă tendinţa de a vira în 25% din cazuri; adică

există o şansă din patru ca agentul mobil să vireze la stânga/dreapta şi trei şanse din

patru ca acesta să îşi păstreze direcţia de mers.

Figura 4.15. Direcţiile posibile de înaintare ale agenţilor intersecţii

47

Agenţii semafor sunt patru la număr, ei fiind legaţi direct unul cu altul, în sensul

în care există un număr fix de combinaţii posibile de setări ale fazelor luminoase ale

semafoarelor. Pentru modelul lumii, am ales să construiesc drumuri cu o singură bandă

pe sens, pentru că funcţionalitatea sistemului multi-agent este asemănătoare, indiferent

de numărul de benzi alocate pentru drumuri. Singura diferenţă între cazul de faţă şi

cazurile cu mai multe benzi pe sens, apare la descrierea comportamentului agenţilor

mobili nativi mediului de programare NetLOGO, care nu sunt interesul major al

acestei aplicaţii. Astfel, complexitatea sistemului multi-agent este identică şi

funcţionalitatea lui este mai uşor de urmărit şi înţeles în cazul cu o singură bandă pe

sens.

Revenind la descrierea agenţilor semafor, spuneam că există un număr fix de

combinaţii posibile ale fazelor luminoase lor. Pentru că reţeaua de drumuri din modelul

lumii ales conţine drumuri cu câte o bandă pe sens, acest număr se reduce la patru

combinaţii posibile, precum se observă în figura 4.16. Astfel că, la un moment dat, dacă

un semafor este verde, celelalte trei semafoare alăturate sunt setate pe culoarea roşie.

Figura 4.16. Combinaţiile posibile ale luminilor semafoarelor

4.4.3.2. Agentul de control al intersecţiei

Agenţii semafor care formează sistemul de semafoare sunt controlaţi de către

agentul de control al intersecţiei, care este, de fapt, unul din elementele sistemului

multi-agent. Astfel, pentru cazul de faţă, avem patru astfel de agenţi inteligenţi de

control al intersecţiei, care, prin comunicare şi intercoordonare, formează sistemul

multi-agent de control al traficului.

48

Agentul de control al intersecţiei este, astfel, piesa de bază în cadrul sistemului

multi-agent. Acest agent decide care combinaţie de lumini ale semafoarelor să fie

aleasă, pentru a păstra cât mai mic timpul de aşteptare al echipajelor de urgenţă. Decizia

se ia pe baza unei logici cu care este înzestrat agentul inteligent şi pe baza datelor pe

care agentul le colectează. (Figura 4.17)

Datele pe care agentul le colectează se referă la numărul de maşini care se află pe

linia de aşteptare a fiecăruia dintre cele patru semafoare care formează intersecţia.

Astfel, agentul ştie în orice moment câte maşini aşteaptă la fiecare dintre cele patru

semafoare. În mod logic, acolo unde aşteaptă cele mai multe maşini, el setează culoarea

semaforului verde, oprind celelalte trei direcţii de intrare în intersecţie. Pentru a nu

fragmenta major traficul, schimbând foarte des combinaţiile de culori ale semafoarelor,

din momentul în care agentul setează o combinaţie de culori, trebuie să treacă o

anumită perioadă de timp până când agentul poate schimba din nou combinaţia.

Această impunere în logica agentului este necesară pentru a permite trecerea mai multor

agenţi mobili în timpul unei combinaţii de culori. Această perioadă de timp am definit-

o ca fiind „faza” semaforului.

Începând cu momentul în care butonul „go” este apăsat, agenţii care controlează

intersecţia execută instrucţiunile prezentate în schema logică de funcţionare. Primul pas

este să colecteze datele referitoare la numărul de maşini care se îndreaptă spre

intersecţie. Se notează cu nA numărul de maşini care vin din direcţia nord; cu nB –

numărul de maşini care vin dispre est; nC – maşinile care vin dinspre sud, iar nD –

maşinile care sosesc dinspre vest.

49

Figura 4.17. Schema logică a funcţionării agentului inteligent

care controlează intersecţia

50

Când agentul are aceste date completate, el efectuează comparaţii între aceste

patru variabile şi pe baza rezultatului comparaţiei, activează una din combinaţiile

prezentate în figura 4.16. Astfel, dacă agentul observă că nA este cel mai mare, atunci

activează combinaţia „A”; dacă nB este cel mai mare, atunci se activează combinaţia

„B”; dacă din direcţia sud vin cele mai multe maşini, atunci se activează combinaţia „C”,

iar dacă nD este cel mai mare, atunci se activează combinaţia „D”. Imediat după această

setare, agentul trebuie să aştepte o perioadă de timp egală cu faza semaforului, pentru a

lăsa agenţii mobili să parcurgă intersecţia. După trecerea perioadei de timp, agentul

execută din nou paşii de mai sus. Dacă utilizatorul doreşte să oprească simularea,

depresează butonul „go”, iar aplicaţia se opreşte din execuţie.

În situaţia în care la fiecare semafor aşteaptă acelaşi număr de maşini. Situaţia

este rezolvată acordând priorităţi semafoarelor. Considerăm că prioritatea cea mai mare

o are semaforul care primeşte agenţi mobili din direcţia nord; a doua prioritate -

semaforul care primeşte agenţi mobili din direcţia est; ş.a.m.d. În cazul în care din

direcţia nord şi din direcţia sud aşteaptă acelaşi număr de maşini, agentul va acorda

drept de trecere prin intersecţie agenţilor mobili care vin dinspre nord.

4.4.3.3. Comunicarea inter-agenţi

Până acum am stabilit care este structura unui agent inteligent care controlează

intersecţia, schema logică de funcţionare a acestuia şi ce agenţi controlează, mai rămâne

de stabilit cum comunică cu ceilalţi agenţi. Comunicarea se petrece la nivel formal, prin

mesaje care conţin diverse date. În cadrul simulării, agenţii îşi transmit între ei direcţiile

în care au eliberat drumul, precum şi numărul de maşini care au părăsit intersecţia în

direcţia unui alt agent.

Astfel, cei patru agenţi se coordonează şi se ajută reciproc la colectarea datelor,

pentru a lua decizii cât mai potrivite scopului lor: reducerea timpului de aşteptare al

echipajelor de urgenţă. Comunicarea inter-agenţi este identică în ambele scenarii

prezentate mai sus, diferenţa între cele două situaţii apărând la modul în care se

acţionează în urma acestei comunicări.

51

Presupunem că suntem în cadrul scenariului 1, cu un singur echipaj de urgenţă

prezent pe reţeaua de drumuri a modelului lumii. Echipajul de urgenţă se află pe raza de

acţiune a unui agent inteligent. Acesta este conştient de acest lucru şi eliberează calea,

setând combinaţia corespunzătoare. Echipajul de urgenţă ştie încotro se îndreaptă, însă

agentul observă acest lucru doar când echipajul de urgenţă părăseşte intersecţia. În

momentul în care agentul cunoaşte direcţia de deplasare, adică în ce direcţie a părăsit

echipajul de urgenţă intersecţia, acesta comunică agentului vecin faptul că echipajul se

îndreaptă înspre acea intersecţie. În cadrul scenariului 2, comunicarea se realizează la

fel, doar modul de reacţie al agenţilor se schimbă. Reacţia agenţilor este descrisă în

subsecţiunile ce urmează.

4.4.4. Scenarii

Pentru studiul comportamentului acestui sistem multi-agent, am luat în

considerare două scenarii posibile pentru simularea funcţionării. Primul scenariu este

mai simplu de urmărit şi de înţeles, în vreme ce al doilea scenariu doreşte să dovedească

că aceeaşi logică poate rezolva fără mari modificări situaţii mai complexe. Precum

spuneam la începutul capitolului, primul scenariu se desfăşoară cu un singur echipaj de

urgenţă, scopul acestui scenariu fiind înţelegerea cât mai facilă a ceea ce face sistemul

multi-agent şi cum reacţionează în diferite situaţii. Presupunând că funcţionarea

sistemului a fost însuşită, scenariul al doilea vine să completeze imaginea sistemului prin

supunerea lui la condiţii mai dificile, respectiv prin simularea unei situaţii în care pe

reţeaua de drumuri a modelului lumii circulă mai multe echipaje de intervenţie.

4.4.4.1. Scenariul 1 – Un singur echipaj de intervenţie

Pentru primul scenariu, generarea lumii şi a stării iniţiale se desfăşoară exact

cum am descris mai sus, în primele secţiuni ale acestui capitol. Pentru o urmărire mai

uşoară a simulării, agenţii mobili care reprezintă maşinile au fost colorate în albastru, în

vreme ce agentul mobil care reprezintă echipajul de intervenţie a fost colorat în roşu.

52

Având modelul şi starera iniţială generată, mai trebuie să precizăm cum se

comportă sistemul multi-agent în cadrul acestui scenariu. În primul rând, trebuie

amintit că fiecare semafor are o perioadă de timp care trebuie să treacă pentru a

modifica din nou combinaţia de culori, numită fază. Pe scurt, fiecare semafor are o fază.

În condiţii normale, adică în lipsa echipajelor de urgenţă, aceste faze sunt sincronizate,

semafoarele schimbând combinaţia în acelaşi timp, nu neapărat, însă, în acelaşi fel.

Înainte de a trece la explicarea detaliată a modului de funcţionare, mai trebuie

precizat faptul că mai există un instrument care ajută la luarea deciziilor de către agent.

Acest instrument poartă numele de counter (numărător) şi este practic, un agent cu

poziţie fixă, definit prin programare, rolul lui fiind de a furniza agentului inteligent care

controlează intersecţia informaţii privind cozile de aşteptare. Precum sugerează numele

acestui agent, el este un numărător de maşini (agenţi mobili), însă funcţionarea lui

diferă de cea a unui numărător obişnuit. Astfel, el numără nu maşinile, ci priorităţile

lor. Prioritatea unei maşini obişnuite (albastre) are valoarea numerică 1, în vreme ce

prioritatea echipajului de urgenţă (roşu) are valoarea numerică egală cu 40. În cadrul

interfeţei grafice, se observă că aceste valori ale numărătorilor apar lângă semaforul

aferent direcţiei din care vin agenţii mobili.

Astfel, agentul inteligent cunoaşte priorităţile pentru fiecare direcţie, aceste

informaţii fiind necesare la luarea deciziei de schimbare a combinaţiei de culori. În cazul

acestui scenariu, precum spuneam, există un singur echipaj de urgenţă. Dacă un agent

primeşte informaţia că echipajul de intervenţie se îndreaptă spre el, automat resetează

faza semafoarelor din intersecţie, schimbând combinaţia de lumini astfel încât pe

direcţia din care vine echipajul de intervenţie să fie setată culoarea verde. Prin această

operaţiune, agentul eliberează în avans intersecţia.

În figura 4.18., se prezintă detaliile de mai sus. Echipajul de intervenţie se

îndreaptă spre intersecţie din direcţia vest, iar agentul inteligent a setat combinaţia „D”

(Figura 4.16), aferentă culorii verde pentru direcţia vest, roşu pentru celelalte. A se

observa valorile numărătorilor aferenţi semafoarelor, care redau numărul (suma

priorităţilor) de agenţi mobili.

53

Figura 4.18. Funcţionarea scenariului 1

4.4.4.2. Scenariul 2 – Mai multe echipaje de intervenţie

În cadrul scenariului 2, pe reţeaua de drumuri a modelului lumii circulă patru

echipaje de intervenţie, reprezentând echipajele de pompieri (roşu), SMURD

(portocaliu), ambulanţa (turcoaz) şi poliţie (negru). La fel ca la scenariul 1, există agenţii

numărători, care au exact aceleaşi atribuţii şi poziţii. Diferenţa între aceste două scenarii

apare la stabilirea priorităţilor, pentru setarea agenţilor numărători şi, mai departe,

pentru decizia agentului care controlează intersecţia. Aceste priorităţi sunt setate pe

baza importanţei tipului de echipaj de intervenţie în cazul unei situaţii de urgenţă.

Valorile numerice alocate acestor priorităţi sunt oarecum proporţionale cu importanţa

echipajelor, însă scopul lor principal este de a facilita decizia sistemului multi-agent.

Astfel, cea mai mare prioritate o are echipajul de pompieri (roşu), având, la fel

ca la scenariul 1, valoarea numerică 40. Mai departe, echipajul SMURD (portocaliu) are

o prioritate egală cu valoarea 30. Echipajul de ambulanţă (turcoaz) are prioritatea 25, iar

cel de poliţie (negru) are prioritatea 15. La fel ca la scenariul 1, celelalte maşini

(albastre) au prioritatea 1.

Comportamentul agenţilor în momentul în care primesc informaţia că un

echipaj de intervenţie se îndreaptă către una din intersecţii nu poate fi la fel cu cel din

cazul scenariului 1, pentru că ar apărea momente de blocaj logic. De exemplu, dacă ar

apărea din direcţia vest şi direcţia nord echipaje de intervenţie, agentul nu ar şti pe cine

să lase să treacă. Astfel, comportamentul este puţin simplificat faţă de scenariul 1.

Agentul nu intervine în faza semafoarelor, astfel că fazele semafoarelor rămân

54

sincronizate de la începutul până la sfârşitul simulării. Agentul ia o decizie simplă, la

sfârşitul fiecărei faze, pe baza informaţiilor primite de la agenţii numărători. Acolo unde

sesizează că este cea mai mare prioritate, setează combinaţia care are culoarea verde în

dreptul acelui loc.

Figura 4.19. Funcţionarea scenariului 2

Astfel, apar cazuri în care echipajele aşteaptă la semafor, dar aşteaptă să treacă

echipajele cu o mai mare prioritate. Per ansamblu, timpul mediu de aşteptare este scăzut

la toate echipajele de intervenţie. În figura 4.19., se observă cum trei echipaje de

intervenţie se îndreaptă spre intersecţie. Echipajul de culoare roşie (pompierii) au cea

mai mare prioritate, deci ei au liber la trecere prin intersecţie. Echipajul de ambulanţă

(turcoaz) va fi următorul echipaj care va trece prin intersecţie, urmând ca echipajul de

poliţie să treacă ultimul, având cea mai mică prioritate.

4.4.5. Instrumente

În cadrul interfeţei aplicaţiei, aşa cum precizam la începutul capitolului, există

mai multe tipuri de instrumente, care ajută la observarea şi studierea influenţei anumitor

variabile în comportarea sistemului multi-agent. Dintre cele patru prezentate, în cadrul

aplicaţiei am folosit trei instrumente: elemente de tip slide-bar, monitoare şi

reprezentări grafice. Pe lângă aceste instrumente, apar, bineînţeles, butoanele de „go” şi

55

„setup”. Aceste instrumente sunt folosite în cadrul ambelor scenarii, singura diferenţă

apare la grafice. În rândurile ce urmează, le voi trata funcţionalitatea fiecărui

instrument, urmând ca în cazul graficelor, să explic separat ce afişează pentru fiecare

scenariu în parte.

4.4.5.1. Butoane

Butoanele de „go” şi „setup” apar în cadrul oricărei aplicaţii NetLOGO. Cum

precizam la secţiunea de prezentare a limbajului, butonul „setup” construieşte un model

iniţial al lumii, urmând ca comportamentele să fie generate după apăsarea butonului

„go”. Butonul „setup” construieşte reţeaua de drumuri, stabileşte agenţii de intersecţie,

agenţii de semafoare, agenţii mobili, agenţii ficşi, poziţiile şi proprietăţile acestora

(culoare, direcţie etc.). Foarte important de precizat, butonul „setup” fixează momentul

lumii iniţiale la momentul 0 (zero ticks). În timp ce execută setarea lumii iniţiale,

butonul setup rămâne blocat, urmând a se debloca în momentul în care construcţia

modelului este finaliazată. Asemănător se comportă şi butonul „go”, care poate fi însă

considerat un fel de întrerupător – când este apăsat, se generează comportamentele;

depresarea lui înseamnă oprirea simulării sau pauzarea acesteia. Până când nu este

apăsat butonul de setare încă o dată, simularea poate fi pauzată de oricâte ori se doreşte.

4.4.5.2. Elemente de tip Slide-Bar

În cadrul aplicaţiei am utilizat un număr de patru elemente de tip slide-bar

(SB), care controlează patru variabile globale, cu acelaşi nume, în secţiunea de cod. Cele

patru SB sunt: numer-of-cars, ticks-per-cycle, acceleration şi deceleration.

Primul SB (Figura 4.20.), aşa cum îi spune numele (număr-de-maşini), setează

numărul de maşini care va fi generat pe reţeaua de drumuri. Astfel, pe fiecare porţiune

de bandă de circulaţie care există pe modelul lumii, se generează un număr de maşini

(agenţi mobili) egal cu valoarea acestui slider-bar. Pe modelul lumii ales există 24 de

56

porţiuni de bandă de circulaţie, astfel că la setarea lumii iniţiale se vor genera number-

of-cars * 24 agenţi mobili. Pentru a nu avea probleme de blocaje de trafic (generate de

construcţia şi funcţionarea agenţilor în cadrul NetLOGO, nu din cauza funcţionării

greşite a sistemului multi-agent), am limitat valorile acestui slider-bar de la 1 la 8

(scenariul 1), sau de la 1 la 6 (scenariul 2) (valoarea implicită este 4). Astfel, pe modelul

iniţial al lumii pot exista un număr de maşini de la 24 la 192.

Figura 4.20. Slide-bar number-of-cars

Al doilea slide-bar folosit poartă numele de ticks-per-cycle (Figura 4.21). Acest

SB controlează durata fazei semafoarelor, adică perioada care trebuie să treacă între

două schimbări consecutive de combinaţie de culori. Cum sugerează şi numele, acesta

setează numărul de tick-uri care constituie faza semafoarelor. Valorile posibile sunt de

la 2 la 60, valoarea implicită fiind 20. Această valoare, în urma simulărilor pe care le-am

efectuat, pare a fi valoarea optimă pentru faza semafoarelor.

Figura 4.21. Slide-bar ticks-per-cycle

Celelalte două SB (acceleration şi deceleration) (Figura 4.22) sunt strâns legate

între ele, ele controlând valorile acceleraţiei şi frânării agenţilor mobili aflaţi pe modelul

lumii. În fond, aceste valori reglează cât de mult să înainteze agenţii mobili pentru a fi

în siguranţă (a evita ciocnirile). Valorile lor sunt subunitare, pentru că întregul

reprezintă dimensiunea unui agent fix, iar o viteză de deplasare atât de mare ar face ca

simularea să fie imposibil de urmărit. Pentru accelaraţie, valorile sunt între 0 şi 0.99,

valoarea implicită fiind 0.29. Pentru frânare valorile posibile se situează între 0 şi 0.099,

valoarea implicită fiind 0.086.

Figura 4.22. SB acceleration şi deceleration

57

4.4.5.3. Monitoare

În ambele scenarii, monitoarele urmăresc fazele semafoarelor. Aşa cum reiese

din descrierile celor două scenarii, comportarea fazelor este diferită. Dacă în cadrul

scenariului 1, fazele nu sunt sincronizate, în cadrul scenariului 2, semafoarele îşi

schimbă combinaţiile de lumini în acelaşi timp, nu însă, în acelaşi fel. Acest lucru reiese

din figura 4.23, unde se observă sincronizarea doar în cazul scenariului 2. De precizat

este faptul că monitoarele sunt aşezate exact cum sunt poziţionate semafoarele aferente

pe hartă – astfel, phase1 se referă la semaforul din NV ş.a.m.d.

Figura 4.23. Monitoarele de faze ale semafoarelor

4.4.5.4. Reprezentări grafice

Aşa cum spuneam la începutul acestei secţiuni, graficele diferă major în cadrul

celor două scenarii. La primul scenariu, pe grafic apar doar două curbe, reprezentând

timpul mediu de aşteptare al agenţilor mobili obişnuiţi (curbă albastră) şi timpul de

aşteptare al echipajului de urgenţă (curbă roşie). După cum se observă în figura 4.24,

este foarte uşor de urmărit evoluţia celor două curbe, astfel că scenariul 1 este uşor de

înţeles.

Scenariul 2 însă are un grafic care conţine 5 curbe (Figura 4.25), reprezentând

timpii de aşteptare ai echipajelor de intervenţie şi timpul mediu de aşteptare al

maşinilor obişnuite. Astfel, pe grafic apare o curbă albastră, corespunzătoare maşinilor

obişnuite, o curbă roşie (Pompieri), o curbă portocalie (SMURD), o curbă turcoaz

(Ambulanţa) şi o s’curbă neagră (Poliţia). Cu toate că este mai greu de urmărit, graficul

arată în mod evident că sistemul îşi face treaba, adică asigură în proporţie de 95% din

58

simulare un timp de aşteptare al echipajelor de intervenţie mai mic decât timpul mediu

de aşteptare al maşinilor obişnuite.

Figura 4.24. Reprezentarea grafică a scenariului 1

Figura 4.25. Reprezentarea grafică a scenariului 2

4.5. Rezultate simulări

Pentru fiecare scenariu am rulat 6 simulări, corespunzătoare celor 6 posibilităţi

de densităţi de trafic, date de valoarea SB number-of-cars. Pentru fiecare scenariu, voi

afişa mai jos graficele rezultate dupa 500 de tick-uri (± 20), cu valorile implicite ale SB,

urmând ca apoi să descriu rezultatele obţinute. Pentru a nu ocupa spaţiu mult, influenţa

59

valorilor SB o voi trata în scris, doar cu câteva grafice care să ilustreze exact schimbările

care se produc în funcţionarea sistemului multi-agent.

4.5.1. Scenariul 1 – Un singur echipaj de intervenţie

Scenariul 1 se referă la situaţia în care pe reţeaua de drumuri există un singur

echipaj de intervenţie. Graficele afişează două curbe: curba roşie reprezintă timpul de

aşteptare al echipajului de intervenţie iar curba albastră timpul mediu de aşteptare al

maşinilor obişnuite. Scopul sistemului multi-agent este să asigure un timp de aşteptare

al echipajului de urgenţă mai mic decât timpul de aşteptare mediu al maşinilor

obişnuite.

Figura 4.26. Rezultatele obţinute pentru valori de la 1 la 4

ale SB number-of-cars

Pentru valori de la 1 la 4 ale SB number-of-cars, graficul arată asemănător,

echipajul de intervenţie având timp de aşteptare mereu 0. Pentru valori mai mari de 6,

încep însă să apară timpi diferiţi de zero, însă sub valoarea timpul mediu. Influenţa SB

ticks-per-cycle nu este importantă, deoarece în acest scenariu agenţii resetează faza

semafoarelor, astfel că singurul efect apare la timpul de aşteptare mediu, care creşte

direct proporţional cu valoarea acestui slider-bar.

60

Figura 4.27. Rezultatele obţinute pentru valoarea 8

a SB number-of-cars

Se observă, după graficele de mai sus, că în cadrul acestui scenariu, singurele

dificultăţi în rezolvarea problemei de trafic apar în cazul unui număr mare de maşini şi

implici, a unei densităţi mari de trafic. Faptul că agenţii resetează faza semafoarelor

atunci când primesc informaţia că un echipaj de intervenţie se îndreaptă înspre

intersecţie, face ca timpul de aşteptare al echipajului să rămână cu mult mai mic decât

timpul mediu de aşteptare. Acesta însă este un caz aparte, construit mai degrabă pentru

a înţelege funcţionarea sistemului multi-agent şi pentru o observare mai uşoară a

comportării agenţilor.

4.5.2. Scenariul 2 – Mai multe echipaje de intervenţie

În cadrul acestui scenariu simulăm existenţa a patru echipaje de intervenţie pe

reţeaua de drumuri a modelului lumii, cu diferite priorităţi de intervenţie. Mai jos sunt

afişate graficele celor 6 situaţii de simulare, corespunzătoare celor 6 valori posibile ale

SB number-of-cars.

61

Figura 4.28. Rezultatele obţinute în urma simulării scenariului 2,

pentru toate valoarea 1 a SB number-of-cars

Aşa cum se observă în figura 4.28, pentru densităţi mici de trafic, sistemul

multi-agent nu are nicio problemă în a asigura un timp de aşteptare al echipajelor de

intervenţie mai mic decât timpul mediu de aşteptare. De precizat este faptul că cel mai

important echipaj de intervenţie (echipajul de pompieri) are timpul de aşteptare egal cu

zero aproape tot timpul.

Figura 4.29. Rezultatele obţinute în urma simulării scenariului 2,

pentru toate valoarea 2 a SB number-of-cars

62

La fel ca în cazul anterior, sistemul multi-agent asigură un timp de aşteptare

zero echipajului de pompieri şi unul foarte redus celorlalte echipaje. Singura excepţie

este cazul echipajului de poliţie, care însă are cea mai mică prioritate, deci trebuie să

acorde drept de trecere celorlalte echipaje.

Figura 4.30. Rezultatele obţinute în urma simulării scenariului 2,

pentru toate valoarea 3 a SB number-of-cars

Odată cu creşterea densităţii traficului, creşte şi dificultatea sarcinii sistemului

multi-agent. În cazul cu 72 de maşini pe reţeaua de drumuri, singurul timp de aşteptare

al vreunui echipaj de intervenţie care depăşeşte timpul mediu de aşteptare este cel al

poliţiei.

Figura 4.31. Rezultatele obţinute în urma simulării scenariului 2,

pentru toate valoarea 4 a SB number-of-cars

63

Sistemul multi-agent asigură valori bune ale timpului de aşteptare şi în cazul

unui trafic mai dens, apărând doar două situaţii izolate în care timpul de aşteptare al

unui echipaj de intervenţie a crescut peste timpul mediu de aşteptare.

Figura 4.32. Rezultatele obţinute în urma simulării scenariului 2,

pentru toate valoarea 5 a SB number-of-cars

Pentru un număr de 120 de maşini prezente pe reţeaua de drumuri, sistemul

multi-agent de control al traficului asigură în continuare timpi de aşteptare mai mici ai

echipajelor de intervenţie. În acest caz apar doar trei excepţii de la această regulă.

Figura 4.33. Rezultatele obţinute în urma simulării scenariului 2,

pentru toate valoarea 6 a SB number-of-cars

64

În condiţiile unui trafic super-aglomerat, sistemul multi-agent funcţionează

bine, fiind înregistrate doar 3 depăşiri ale timpului mediu de aşteptare. În afara acestor

3 excepţii, sistemul a asigurat timpi mai mici de aşteptare tuturor echipajelor de

intervenţie.

Aşa cum se observă din figurile 4.28 - 4.33, timpii de aşteptare ai echipajelor de

intervenţie sunt mai mici decât timpul mediu de aşteptare, cu mici excepţii, însă

rezultatele globale reflectă că în 95% din timp, sistemul multi-agent şi-a atins scopul.

Mai mult, singurul echipaj de intervenţie care a avut timp de aşteptare mai mare decât

media a fost echipajul cu cea mai mică prioritate, încă un semn că sistemul multi-agent

a gestionat foarte bine situaţia.

Figura 4.34. Rezultatele simulării scenariului 2

(A): Valoare mică a fazei

(B): Valoare mare a fazei

65

În cazul scenariului 2, agenţii nu mai resetează fazele semafoarelor, astfel că o

variere a SB ticks-per-cycle duce la modificări substanţiale ale performanţelor sistemului

multi-agent. Cu toate că cresc proporţional cu valoarea fazei, timpii de aşteptare ai

echipajelor de intervenţie rămân sub nivelul timpului mediu. După cum se observă în

figura de mai jos, pentru o valoare mică a fazei, timpii rămân sub nivelul mediu, având

chiar valori egale cu 0 în multe din cazuri, în vreme ce pentru o valoarea mare a fazei,

timpii au în continuare valori sub timpul mediu, însă sunt mai mari decât în cazul

anterior. La fel, cazurile în care timpii echipajelor de intervenţie depăşesc timpul mediu

sunt mai dese la valori mari ale fazei.

La valori mari ale fazei timpii de aşteptare sunt mult mai mari, existând şi cazuri

în care timpul de aşteptare al echipajelor cele mai importante depăşesc timpul mediu de

aşteptare, lucru care nu se întâmplă la valori mici ale fazei. După cum se observă în

figura 4.34.A., doar echipajul de poliţie are timpul de aşteptare peste timpul mediu de

aşteptare.

Valorile acceleraţiei nu au o influenţă mare asupra comportamentului sistemului,

însă există o proporţionalitate inversă între valoarea acceleraţiei şi timpii de aşteptare ai

echipajelor de urgenţă. Astfel, la o valoare mică a acceleraţiei, timpii de aşteptare ai

echipajelor de intervenţie sunt mai mari şi viceversa.

66

6. CONCLUZII

În cazul unor calamităţi, sistemele multi-agent par a fi cheia succesului în

asigurarea unor intervenţii prompte şi sigure. Evoluţia tehnologiei permite acordarea

unei mari autonomii acestui tip de sistem, astfel că limitele construirii acestui tip de

sisteme sunt departe de a fi depăşite. Agenţii şi sistemele formate cu agenţi devin din ce

în ce mai utilizate, în din ce în ce mai multe domenii şi arii de lucru. Paradigma

programării orientate pe agent oferă o nouă perspectivă de programare, cu rezultate

spectaculoase la nivel de inovaţie. De asemenea, nu trebuie uitată contribuţia pe care o

au sistemele-multi-agent la dezvoltarea domeniului de Inteligenţă Artificială. Lucrarea

de faţă se doreşte a fi un punct de pornire în această direcţie a managementului

situaţiilor de urgenţă utilizând sisteme multi-agent.

În general, sistemele de control de trafic sunt sisteme complexe, care necesită un

studiu atent şi amănunţit, cu un volum mare de date de analizat. Aplicaţia de faţă

permite observarea comportamentului unui sistem de control al traficului atât la nivel

local, de intersecţie, cât şi la nivel global, de reţea de drumuri şi intersecţii. Sistemele

multi-agent sunt foarte performante în ceea ce priveşte modelarea sistemelor complexe,

astfel această lucrare a ilustrat modul în care sistemele multi-agent pot fi folosite ca şi

sisteme de control al traficului.

Interpretarea rezultatelor a dovedit faptul că sistemul multi-agent a reuşit să îşi

atingă scopul pentru care a fost construit, şi anume să asigure unor echipaje de urgenţă

un timp de trecere cât mai mic printr-o reţea de drumuri şi intersecţii, în drumul lor

către locul de intervenţie. De asemenea, sistemul multi-agent a dovedit că este capabil

să gestioneze un volum de informaţii mare într-un timp scurt, o chestiune vitală în cazul

unui dezastru natural.

67

Rezultatele obţinute arată că logica de funcţionare a agenţilor care compun

sistemul multi-agent este bună, însă scenariul 2 ne arată că nu este perfectă. Trebuie

căutate posibilităţi de îmbunătăţire a funcţionării acestor agenţi, astfel încât timpul de

aşteptare să devină din ce în ce mai mic, până aproape de cazul perfect, care presupune

o valoare nulă a acestei variabile.

Dacă este să vorbim despre îmbunătăţirile care ar putea fi aduse acestei lucrări,

în posibile lucrări viitoare, în primul rând ar trebui construite şi simulate alte scenarii,

mai complexe, cu mai multe variabile, urmând ca pe baza rezultatelor obţinute să se

modeleze alte comportamente şi logici de funcţionare pentru agenţii care compun un

sistem multi-agent. De asemenea, complexitatea modelului lumii poate fi mărită prin

acordarea unor dimensiuni mai mari ale modelului.

Această lucrare prezintă o implementare din domeniul sistemelor multi-agent,

numărul aplicaţiilor în care aceste sisteme pot avea un rol foarte important devenind din

ce în ce mai mare. Sistemele multi-agent sunt integrate din ce în ce mai mult în

tehnologiile de azi, pentru că permit modelarea, controlul şi întreţinerea unor sisteme

din ce în ce mai complexe.

68

6. ANEXE

6.1. Procedura SETUP

Procedura SETUP este accesată în momentul în care se apasă butonul „setup” în

cadrul interfeţei aplicaţiei.

;setarea modelului lumii, o varianta initiala ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; to setup clear-all ask patches [ setup-road ] setup-cars setup-counters set phase1 0 set phase2 0 set phase3 0 set phase4 0 set nr-masini-oprite 0 setup-lights reset-ticks end ; SETUP-ROAD ; procedura setup-road contine, de fapt, setarea agentilor ficsi cu ; rolurile aferente ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; exemplu de setare a agentilor ficsi cu rol de trotuar ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; if (pycor = 7) and (pxcor < -14) [set pcolor gray] if (pycor = 7) and ((pxcor < 13) and (pxcor > -13)) [set pcolor gray] if (pycor = 7) and (pxcor > 13) [set pcolor gray] ; exemplu de setare a agentilor ficsi cu rol de decor; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; if ((pycor < 24) and (pycor > 17)) and ((pxcor < -28) and (pxcor > -38)) [set pcolor orange - 2]

69

if ((pycor < 16) and (pycor > 10)) and ((pxcor < -16) and (pxcor > -38)) [set pcolor orange - 4] if ((pycor < 24) and (pycor > 10)) and ((pxcor < -16) and (pxcor > -24)) [set pcolor orange - 4]

; setarea agentilor ficsi cu rol de drum; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; drumurile orizontale if (pycor < 10) and (pycor > 7) [ set pcolor white ] if (pycor < -7) and (pycor > -10) [ set pcolor white ] ; drumurile verticale if (pxcor < 15) and (pxcor > 12) [ set pcolor white ] if (pxcor < -12) and (pxcor > -15) [ set pcolor white ] ; setarea agentilor ficsi cu rol de intersectie; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

set intersections patches with [ ((pxcor = -14) and (pycor = 9)) or ((pxcor = 13) and (pycor = 9)) or ((pxcor = -14) and (pycor = -8)) or ((pxcor = 13) and (pycor = -8)) ] ; SETUP-CARS ; procedura setup-cars genereaza agentii mobili, ii plaseaza aleator ; pe agentii ficsi cu rol de drum si le confera acestora o directie de ; mers. De asemenea, aceasta procedura creeaza si agentii mobili care ; au rolul de echipaj de interventie. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; exemplu de generare a agentilor mobili; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; set-default-shape turtles "car" crt number-of-cars [ set color blue set ycor 8 set xcor (random 24) - 38 set heading 90 ;;; setarea vitezei initiale set speed 0.1 + random-float .9 set speed-limit 1 set speed-min 0 set turned? false set retras? false set wait-time 0 separate-cars ] ; exemplu de generare a agentilor mobili cu rol de echipaj de urgenta; ; aici - generarea echipajului de pompieri ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; set sample-car one-of turtles ask sample-car [ set color red ]

70

; SETUP-COUNTERS ; procedura setup-counters genereaza agentii numaratori, care ; furnizeaza agentilor care controleaza intersectia date privind ; numarul de masini care se afla in coada de asteptare a semafoarelor ; aferente intersectiei ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; exemplu de generare a agentilor numaratori; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ask patch -15 10 [ sprout-counters 1 [ set numar-masini 0 set hidden? true ] ] ; SETUP-LIGHTS ; procedura setup-lights creeaza agentii semafor si ii initializeaza ; cu culoarea rosie pe toti acestia ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; to setup-lights ask intersections [ ask patch-at 0 1 [ set pcolor red] ask patch-at 2 0 [ set pcolor red] ask patch-at 1 -2 [ set pcolor red] ask patch-at -1 -1 [ set pcolor red] ] end

; RESET-TICKS ; procedura reset-ticks este o procedura integrata in mediul de ; programare NetLOGO. Aceasta seteaza modelul initial la momentul ; zero (adica seteaza pasul de simulare la valoarea zero). ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

71

6.2. Procedura GO

Procedura GO este accesată în momentul în care se apasă butonul „go” în cadrul

interfeţei aplicaţiei. Procedura rulează atâta timp cât butonul „go” rămâne presat.

to go counter-cars set nr-masini-oprite 0 set-signals turn-cars move-cars next-phase plot-data tick end ; COUNTER-CARS ; procedura counter-cars se refera la actiunea agentilor numaratori, ; care numara masinile (prioritatile) care se afla in coada de ; asteptare a semaforului aferent. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; exemplu de functionare a agentilor numaratori; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ask one-of counters-on patch -15 10 [ set numar-masini count turtles-on d1a if member? sample-car turtles-on d1a [ set numar-masini numar-masini + 40 ] set plabel-color white set plabel numar-masini ] ; SET-SIGNALS ; procedura set-signals implementeaza schema logica a agentului care ; controleaza intersectia. In aceasta procedura se ia decizia alegerii ; combinatiei de faze luminoase ale semafoarelor. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; if (nA >= nB) and (nA >= nC) and (nA >= nD) and (phase = 0) [ let signal-type "A" set-signal-colors signal-type pxcor pycor ] if (nB > nA) and (nB >= nC) and (nB >= nD) and (phase = 0) [ let signal-type "B" set-signal-colors signal-type pxcor pycor

72

] if (nC > nA) and (nC > nB) and (nC >= nD) and (phase = 0) [ let signal-type "C" set-signal-colors signal-type pxcor pycor ] if (nD > nA) and (nD > nB) and (nD > nC) and (phase = 0) [ let signal-type "D" set-signal-colors signal-type pxcor pycor ] ; SET-SIGNAL-COLORS ; procedura set-signal-colors este apelata de procedura set-signals. ; Aceasta procedura seteaza fazele luminoase ale semafoarelor. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; exemplu de setare de faze luminoase; ; aici – setarea combinatiei „A” ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ask patch d-x d-y [ ; setare tip "A" if signal-type = "A" [ ask patch-at 0 1 [ set pcolor green] ask patch-at 2 0 [ set pcolor red] ask patch-at 1 -2 [ set pcolor red] ask patch-at -1 -1 [ set pcolor red] ] ; TURN-CARS ; procedura turn-cars simuleaza tendinta de virare a agentilor mobili ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; exemplu ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ask stanga-jos [ if any? turtles-here [ ask turtles-here [ ifelse (heading = 270) and turned? = false [ if (random 4 = 0) and turned? = false [

73

set heading 180 setxy pxcor pycor set turned? true ] ] [ if (random 4 = 0) and turned? = false [ set heading 270 setxy pxcor pycor set turned? true ] ] ] ] ] ; MOVE-CARS ; procedura move-cars se ocupa de miscarea (daca este cazul) a ; agentilor mobili ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; to move-cars ask turtles [ ifelse pcolor = red [ set speed 0] [ ; cod care ajuta la tendita de virare a agentilor mobili

if not member? patch-here (patch-set stanga-sus stanga-jos dreapta-sus dreapta-jos) [ set turned? false] let car-ahead one-of turtles-on patch-ahead 1 ifelse car-ahead != nobody [ set speed [speed] of car-ahead slow-down-car ] ;; accelereaza [ speed-up-car ] ;;; nu iesim din limitele de viteza if speed < speed-min [ set speed speed-min ] if speed > speed-limit [ set speed speed-limit ] fd speed ] ] end ; NEXT-PHASE ; procedura next-phase actualizeaza valoarea fazelor semafoarelor, ; iar, daca este cazul, o reseteaza. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; to next-phase set phase1 phase1 + 1 set phase2 phase2 + 1 set phase3 phase3 + 1 set phase4 phase4 + 1 if phase1 mod ticks-per-cycle = 0

74

[ set phase1 0 ] if phase2 mod ticks-per-cycle = 0 [ set phase2 0 ] if phase3 mod ticks-per-cycle = 0 [ set phase3 0 ] if phase4 mod ticks-per-cycle = 0 [ set phase4 0 ] end ; PLOT-DATA ; procedura plot-data calculeaza valorile necesare pentru afisarea pe ; grafic a curbei timp de asteptare mediu ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; to plot-data ask turtles [ ifelse speed = 0 [ set nr-masini-oprite nr-masini-oprite + 1 set wait-time wait-time + 1 ] [set wait-time 0] ] end

75

7. BIBLIOGRAFIE

[1] ASC. 2012. http://www.amsterdamsmartcity.nl/#/nl, accesat la data de 2.07.2012

[2] Barker-Plummer D. 2012. The Stanford Encyclopedia of Philosophy (Fall 2012 Edition).

http://plato.stanford.edu/entries/turing-machine/, accesat la data 2.07.2012.

[3] Bartlett D. 2012. 5 Ways The Smart City Will Change How We Live In 2012.

http://www.fastcoexist.com/1679062/5-ways-the-smart-city-will-change-how-we-live-

in-2012, accesat la data de 2.07.2012

[4] Buiu C., Albu M. 2000. Agenţi software inteligenţi. ICPE, Bucureşti.

[5] Caragliu A., Del Bo C., Nijkamp P. 2009. Smart cities in Europe.

[6] Conway J. 1970. http://home.adelphi.edu/~stemkoski/mathematrix/life6b.gif, accesat la

data de 2.07.2012.

[7] Davidsson P. 2000. Multi Agent Based Simulation: Beyond Social Simulation. Ronneby

[8] Gardner M. 1970. MATHEMATICAL GAMES The fantastic combinations of John

Conway's new solitaire game "life". http://ddi.cs.uni-

potsdam.de/HyFISCH/Produzieren/lis_projekt/proj_gamelife/ConwayScientificAmerica

n.htm, accesat la data de 2.07.2012.

[9] Heath B. 2010. The History, Philosophy and Practice of Agent-Based Modelling and the

Development of the Conceptual Model for Simulation Diagram. Wright State University.

[10] Hirankitti V., Krohkaew J., Hogger C. 2007. A Multi-Agent Approach for Intelligent

Trafic-Light Control. Proceeding of the World Congress on Engineering Vol. I, Londra

76

77

[11] Kohno M. 2010. Hitachi and Smart City.

http://www.nt.gov.au/lands/growth/weddell/greenindustry/documents/Hitachi%20_Smar

t_City.pdf, accesat la date de 2.07.2012

[12] Komninos N. 2006. The architecture of intelligent cities: integrating human, collective and

artificial intelligence to enhance knowledge and innovation. 2nd IET International

Conference on Intelligent Environments, Atena, Grecia.

http://digital-library.theiet.org/getabs/servlet/GetabsServlet

?prog=normal&id=IEECPS0020060CP5180v1-13000001&idtype=cvips

&gifs=yes&ref=no, accesat la data de 2.07.2012

[13] Pătraşcu M. 2011. Tehnici avansate în controlul vibraţiilor seismice. Bucureşti

[14] Schurr N., Marecki J., Tambe M., Scerri P., Kasinadhuni N., Lewis J.P. 2005.The Future

of Disaster Response: Humans Working with Multiagent Teams using DEFACTO.

[15] SCM. 2012. http://www.smartcitymalaga.es/, accesat la data de 2.07.2012

[16] SCREC. 2007. Smart cities Ranking of European medium-sized cities – Final Report. Centre

of Reginal Science, Viena. http://www.smart-cities.eu/index2.html, accesat la data de

2.07.2012

[17] Serenko A., Detlor B. 2004. Intelligent agents as innovations. Springer-Verlag, Londra.

[18] Wilensky U. 1999. NetLogo. http://ccl.northwestern.edu/netlogo/. Center for Connected

Learning and Computer-Based Modeling, Northwestern University, Evanston, IL.