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
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.
Top Related