Subsemnatul, legitimat cu [622663]

Universitatea Tehnică „Gheorghe Asachi” din Iași
Facultatea de Automatică și Calculatoare

DOMENIUL: Calculatoare
DEPARTAMENTUL: Calculatoare și Tehnologia
Infor mației

LUCRARE DE LICENȚĂ
SIMULAREA SITUAȚIILOR DE
URGENȚĂ UTILIZÂND SISTEME
MULTI -AGENT

Coordonator științific:
Prof. dr. in f. Mitică CRAUS
Student: [anonimizat]2020-

DECLARAȚIE DE ASUMARE

A AUTENTICITĂȚII LUCRĂRII DE LICENȚĂ

Subsemnatul, legitimat cu
C.I seria nr. , CNP , autorul lucrării
SIMULAREA SITUA ȚIILOR DE URGENȚĂ UTILIZÂND SISTEME MULTI –
AGENT elaborată în vederea susținerii examenului de finalizare a studiilor de licență organizat
de către Facultatea de Automatică și Calculatoare din cadrul Universității Tehnice „Gheorghe
Asachi” din Iași, sesiunea din Septembrie a anului universitar 2020, luând în considerare
conținutul Art. 34 din Codul de etică universitară al Universității Tehnice „Gheorghe Asachi”
din Iași (Manualul Procedurilor, UTI.POM.02 –Funcționarea Comisiei de etică universitară),
declar pe proprie răspundere, că această luc rare este rezultatul propriei activități intelectuale,
nu conține porțiuni plagiate, iar sursele bibliografice au fost folosite cu respectarea legislației
române (legea 8/1996) și a convențiilor internaționale privind drepturile de autor.

Data , Semnătura

Cuprins
1. Introducere ……………… ……………………………………………………………………….. 2
1.1 Prezentarea temei ……….. ……………………………………………………………. 2
1.2 Motiva ția alegerii temei …………………………………………………………….. 3
2. Agenți și sisteme multi -agent ……………………………………………… ………………. 5
2.1 Informații generale …………………………………………… ………………………. 5
2.2 Sisteme multi -agent ……………………….. ………………………………………… 8
2.3 Aplicații ale sistemelor multi -agent ……………….. …………………………. 18
3. Mediul de programare NetLogo …………………………………………………………. 24
3.1 Informații generale ………………………………………………………………….. 24
3.2 Agenți și variabile ………… …………………………………………………. …….. 25
3.3 Interfața matematică ………………. ……………………………………………. … 28
3.4 Desenare și producție ……………………………………………………… ………. 29
4. Aplicație practică și rezultate ………… ………………………………………………….. 32
4.1 Descrierea aplicației ………………………………………………………………… 32
4.2 Implementarea aplicației …….. …………………………………………………… 36
4.3 Rezultate obținute și concluzii ………………………………………………….. 40
5. Concluzii ………………………………………………………………………… ……………… 43
Bibliografie
Anexe

2 | P a g e
1. Introducere
1.1 Prezentarea t emei
Scopul temei este de rea liza un scenariu al situațiilor de urgență cauzate o situație de tip
carantină și alte evenimente, influența lor asupra sistemului ca un într eg, și modul în care modelul
realizat poate f i folosit pentru a înțelege sistemele de intervenție.
Pentru a modela acest scenariu am apelat la agenți și sisteme multi -agent. Sistemele
multiagent (MAS) au apărut ca o nouă metodologie de abordare a problemelor de organizare la
scară largă a sistemelor software. Această metodologie oferă un model conceptua l care ajută la
menținerea constrângerilor; sarcinile convenționale de inginerie software fiind imposibil de
realizat. În ultimii ani, MAS au fost folosite în diferite domenii din informatică și inginerie și au
devenit un instrument versatil care se adrese ază nevoilor ingineriei software. Acestea extind, de
asemenea, spectrul de cerce tare în informatică și au atras din ce în ce mai mult atenția către o gamă
largă de domenii, tre când de la studiul teoretic la practică.
Un agent este o entitate software care caută în mod activ modalități de ași finaliza sarcinile.
Agenții inteligenți au capacitatea de a dobândi cunoștințe prin intermediul proceselor de
soluționare a problemelor. S tudiul comportării sociale a agenților în știința cognitivă reprezintă o
parte i mportantă din domeniul agenților inteligenți. Agenții software se concentreze pe interacțiuni
și colaborări pentru a -și atinge obiectivele într -un context care se schimbă într -o manieră de obicei
neprevăzută.
Necesitatea de a folosi agenți provine din co mplexitatea sistemelor software de mari
dimens iuni, care aduc noi probleme de design pe care tehnologia convențională nu reușește să le
abordeze. De exemplu, agenții mobili au fost propuși pentru a răspunde nevoilor din modelul
client/server, pentru ca un client să fie capabil să migreze la server pentru a efectua operațiuni pe
care a lte mecanisme nu le pot gestiona eficient.
Într-un sistem dinamic distribuit, agenții au capacitate de auto -reglare și pot simplifica
design -ul arhitectural al sistemului. Des ign-ul unui astfel de 2 sistem poate fi extrem de complicat
în arhitecturile tradiționale ale modelării orientate obiect. Modelarea orientată pe agenți aduce o
aborda re neconvențională designului sistemului, cu precădere în definirea componentelor și în

3 | P a g e
integrarea sistemului. Diferite aplicații pot impune cerințe diferite în ceea ce privește pr oiectarea
sistemelor și pot conduce astfel la diferite tipuri de agenți.
1.2 Motivația alegerii temei
O provocare pentru cercetătorii care se ocupă cu modelarea oraș elor este de a găsi
modalități eficiente de a proteja viețile o menești în situații de urgență. De aici derivă și nevoia de
a asigura un flux constant al traficului. D atorită naturii sociale a sistemelor urbane, de cele mai
multe ori deciziile ce trebuie lu ate de către dispeceratele echipajelor de urgență nu sunt
independente, necesitând un nive l ridicat de coordonare din partea componentelor acestora.
În societățile m oderne, situațiile de urgență sunt din ce în ce mai prezente în viața cotidiană.
De aici r eiese necesitatea realizării unui model care simulează intervențoa echipajelor de urgență.
Pentru a fi eficiente, sistemele implementate trebuie să coincidă tipul și numărul echipajelor
necesare, precum și traseele acestora sper zonele afectate. Localizare a zonei în care s -a semnalizat
o situație de urgență este principalul factor care modifică starea traficului.
Cu cât sunt mai fiabile informațiile referitoare la tra fic pe care le deține un echipaj de
intervenție în situații de urgentă, cu atât mai mult a cțiunile sale – alegerile sale de traseu – sunt
mai adecvate. O situație de urgență este î n mod normal caracteriztă de un incident soldat cu pagube
umane sau material e, de dispeceratele echipajelor de urgență care se confruntă cu o situație nouă
în ceea ce privește asignarea numărului de echipaje necesare și selectarea treaseelor acestora, și
bineînțeles participanții la trafic. Acest model permite o abordare simplă fă ră a pierde totuși
infirmații relevante despre interacțiunile inexistente între agenții nu miți mai sus.
În spatele motivației se află și întrebarea: cum reacționează un dispecerat în fața unei
situații de urgență astfel încât echipajele de intervenție să ajungă la locul incidentului în timp util
într-un mediu în care conducătorii auto altereaz ă starea de trafic în mod dinamic.
Prezenta lucrare este structurată pe cinci capitole după cum urmează:
Primul capitol: Introducerea – prezentarea temei și motivați a alegerii acesteia;

4 | P a g e

Al doilea capitol: Agenți și sisteme multi -agent – cuprinde informați i generale despre
agenți și sistemele multi -agent, o detaliere a sistemelor multi -agent, precum și aplicațiile
în care sunt întalnite sistemele multi -agent;
Al treile a capitol: Mediul de programare NetLogo – Acest capitol cuprinde informații
generale despr e mediul de programare, modul de definire a agenților și variabilelor, intefața
matematică, desenarea și producția;
Capitoul patru : Aplicația practică dezvoltată – prezintă descrierea aplicației,
implementarea acesteia și rezultatele obținute ;
Capitolul ci nci: Concluziile – prezintă concluziile la care am ajuns în urma desfășurării
lucrării de diplomă.

5 | P a g e
2. Agenții și sistemele multi -agent
2.1 Informații generale
Un agent este o entitate software sau hardware situată într -un mediu de execuție și care este
capabilă de acțiuni autonome pentru a -și îndeplini obiectivele proiectate. Situarea înseamnă că
agentul este pa rte integrantă din mediul său de execuție, cu care interacționează în mod continuu:
percepe mediul prin intermediul senzorilor și acționează asup ra lui prin intermediul efectorilor.
Autonomia înseamnă că agenții acționează independent de utilizator sau pro prietar [1].
Un sistem multi -agent este compus din agenți care interacționează. De obicei, presupunem
că agenții operează într -un mediu deschis:
inaccesibil: agenții nu au informații complete și actuale despre starea mediului;
nedeterminist: acțiunile nu au u n singur efect garantat; agenții au doar control parțial și
acțiunile pot eșua, iar dacă e necesar, trebuie să -și refacă planurile;
dinamic: medi ul poate fi modificat și de ceilalți agenți; starea mediului se poate schimba
în timpul executării unei acțiuni ;
continuu: mediul nu are un număr finit de stări.
Un agent inteligent este un agent cu un comportament flexibil, ceea ce presupune:
proactivi tate: comportament orientat către scop, preluarea inițiativei;
reactivitate: răspunsuri prompte la schimbările din mediu;
abilități sociale: posibilitatea de a interacționa cu alți agenți (sau cu oameni).
Diferența principală dintre agenți și obiectele di n programarea orientată pe obiecte este
gradul de a utonomie. În obiecte, metodele sunt apelate direct, iar flux ul de control se mută direct
în metodă. Decizia de execuție este la sursă (obiectul care apelează). Agenții primesc solicitări de
a îndeplini acț iuni, dar un agent poate refuza o solicitare. Decizia de execuție este la destinație
(agentul care primește cer erea).
Mobilitatea reprezintă schimbarea perspectivei agentului asupra mediului. Poate fi
schimbarea poziției fizice (agent hardware, robot) sau deplasarea pe o altă mașină (agent software).
Sistemele multi -agent pot avea: mobilitate slabă, în care se tra nsferă codul și starea datelor

6 | P a g e
(valorile variabilelor interne) sau mobilitate puternică, în care se transferă și contextul de execuție:
stiva, re gistrele procesorului, adresa instrucțiunii curente etc.
O arhitectură definește modulele care compun un agent și modul lor de interacțiune,
precum și modalitatea în care datele de la senzori și starea curentă a agentului determină acțiunile
și următoarea stare internă a agentului. Un agent este într -o continuă interacțiune cu mediul:
primește date de la senzori ( numite percepte) privind starea mediului, își modifică starea internă și
efectuează acțiuni. Acțiunile pot schimba starea mediului. În general, m ediul conține și alți agenți.
Arhitecturile logice folosesc reprezentări simbolice bazate pe logică ale mediul ui, de
exemplu, logică predicativă de ordin întâi sau logică temporală. Manipularea acestor cunoștințe se
face prin demonstrații automate de teor eme. Pentru a efectua o acțiune, un astfel de agent încearcă
mai întâi să găsească o acțiune care poate fi dedu să din baza lui de cunoștințe. Dacă nu poate,
încearcă apoi să găsească o acțiune care nu este interzisă explicit. Avantaje: semantica elegantă ș i
formalizarea matematică bună. Dezavantaje: transformarea stărilor mediului într -o reprezentare
simbolică este dificilă, iar demonstrarea de teoreme este lentă.
Arhitecturile reactive se bazează pe existența unor comportamente aranjate pe straturi. Mai
multe comportamente se pot activa simultan atunci când precondițiile lor permit acest lucru, da r
comportamentelo r le sunt atribuite priorități diferite. Acțiunea aleasă de un agent este dată de
comportamentul activ cel mai prioritar.
Comportamentul global rezultat din compunerea unei mulțimi de comportamente reactive
este emergent: nu poate fi descris complet doar pe baza comportamentelor individuale, ci poate fi
observat doar atunci când agentul rulează efectiv.
Avantaje: simplitatea, rapiditatea și rob ustețea.
Dezavantaje: dificultatea de a învăța comportamente noi, lipsa unei metodologii clare
pentru construirea unor astfel de sisteme (din cauza comportamentului global emergent),
dificultatea de a construi agenți cu un număr mare de straturi de compo rtament.
Arhitectura BDI (engl. “Beliefs -Desires -Intentions”) este probabil ce a mai cunoscută
arhitectură de agenți. Se bazează pe studiile psihologice asupra raționamentului practic, care
presupune a decide ce scopuri trebuie atinse și cum se pot atinge aceste scopuri. Convingerile

7 | P a g e
reprezintă informațiile agentului despre mediu, in clusiv despre ceilalți agenți din mediu. Dorințele
reprezintă obiectivele sau stările de lucruri pe care agentul le -ar dori realizate, într -o lume ideală.
Dorințele necontradict orii adoptate de agent se numesc scopuri. Intențiile sunt dorințele pe care
agentul s -a angajat să le realizeze, adică pentru care a început execuția unui plan.
Există mai multe strategii de angajament:
Angajament orb: agentul își menține o intenție până când crede că aceasta a fost îndeplinită;
Angajament singular: agentul își menț ine o intenție până când crede că a fost îndeplinită
sau este imposibil de îndeplinit;
Angajament deschis: agentul își menține o intenție până când crede că a fost îndeplinită
sau este imposibil de îndeplinit sau scopul nu mai există.
Dacă mediul se schim bă rar, se comportă mai bine agenții care nu se opresc din execuție
ca să -și reconsidere intențiile. Dacă mediul se schimbă frecvent, se comportă mai bine agenții care
se opresc să-și reconsidere intențiile după fiecare acțiune.
Arhitectura PRS (engl. “P rocedural Reasoning System”) este o implementare a arhitecturii
BDI. Planurile PRS au un context (precondițiile), un scop (postcondițiile) și un corp (rețeta
planului, cursul de acțiune). Deoarece algoritmii de planificare standard sunt lenți și complecși, se
folosesc de obicei biblioteci de planuri deja calculate, care care descriu secvențele de acțiuni care
trebuie efectuate pentru a atinge anumite scopuri.
Arhitecturile stra tificate au mai multe straturi dispuse într -o ierarhie, cu diferite niveluri
de abstractizare, de exemplu:
Nivelul inferior: strat reactiv, fără un model al mediului;
Nivelul mediu: strat proactiv, de planificare, bazat pe cunoștințe simbolice despre mediu ;
Nivelul superior: strat social, pentru reprezentarea altor agenți cu scopuril e, convingerile
lor etc.

8 | P a g e
2.2 Sisteme multi -agent
Un sistem multi -agent (SMA) este un sistem distribuit format dintr -o colec ție de agen ți
autonomi care interac ționează într -un mediu comun, fiecare agent având cunoștin țe, capacită ți de
acțiune și scopuri proprii [FERBER, 94].
Un sistem multi -agent este definit ca un sistem compus din elementele următoare:
1. Un mediu E, adică un spa țiu prevăzut cu o metrică;
2. Un ansamblu de obie cte O. Fiecărui obiect din O i se poate asocia un anumit loc (o pozi ție)
în E. Aceste obiecte sunt pasive, în sensul că ele pot fi percepute, create, distruse și
modificate de către agen ți;
3. Un ansamblu A de agen ți care sunt obiecte particulare (A ⊆ O) și care reprezint ă entitățile
active ale sistemului;
4. Un ansamblu de rela ții R care unește obiectele (și deci și agen ții) între ele;
5. Un ansamblu de opera ții O p permi țând agen ților lui A să perceapă, producă, transforme și
manipuleze obiectele din O;
6. Operatori a vând sarcina de a reprezenta aplicarea acestor opera ții și reac ția lumii la această
tentativă de modificare, denumită regula universului.
Există un caz particular în care A = O și E este mulțimea vidă. In acest caz, relațiile R
definesc o rețea: fiecare a gent este legat direct la un ansamblu de alți agenți care sunt denumiți
"legături" ale celui dintâi. Acest tip de sisteme poartă numele de sisteme multi -agent pur
comunicante și sunt des întâlnite în inteligen ța artificială distribuită. Domeniile în care p ot fi
aplicate sunt cele ale cooperării între module logice a căror func ție este de a rezolva o problemă
sau de a elabora/realiza o expertiză (cum ar fi interpretarea semnalelor) pornind de la module
specializate, ca în cazul unui sistem de control distrib uit; aceste sisteme se caracterizează prin
faptul că interac țiunile sunt comunica ții inten ționate și modul de lucru este asemănător celui al
unui organism social.
In situația în care agenții sunt situați, E este în general un spațiu metric și agenții sun t
capabili de a percepe propriul mediu, adică de a recunoaște obiectele din mediu în funcție de

9 | P a g e
capacitățile lor perceptive, și de a acționa, adică de a transforma starea sistemului prin modificarea
pozițiilor și relațiilor existente între obiecte [FERBER, 94].
Un aspect important al arhitecturii unui SMA este facilitatea cu care se pot adăuga sau
șterge (elimina) agenți din respectivul SMA [CHAFIN, 92].
Se definește arhitectura statică, arhitectura în care toate componentele SMA, ca și intrările
și ieș irile sale sunt definite în specificația proiectului. Intr -o arhitectură dinamică, componentele
nu sunt toate cunoscute, iar specificația și proveniența intrărilor, ca și destinația ieșirilor pentru
fiecare componentă, nu sunt fixe.
In timp ce în arhitec tura statică trebuie să fie prezente toate elementele pentru ca sistemul
să funcționeze, în arhitectura dinamică unii agenți pot participa sau nu o oarecare perioadă de timp
și, de asemenea, pot intra sau abandona participarea la sistem. Totuși, pentru ca acest lucru să fie
posibil, trebuie să existe suficiente suprapuneri ale domeniilor tratate; în caz contrar acțiunea
cerută nu se va executa niciodată [1].
In construcția sistemelor multi -agent s -a impus o nouă paradigmă metodologică de
programare, propusă de Shoham, respectiv programarea orientată pe agenți (AOP=Agent -Oriented
Programming). Programarea orientată pe agenți poate fi văzută, din punct de vedere ingineresc, ca
o specializare a paradigmei programării orientate pe obiecte. Intuitiv, în timp ce prog ramarea
orientată pe obiecte (OOP=Object -Oriented Programming) propune c onsiderarea unui sistem de
prelucrare ca o colecție de module care comunică între ele prin transmitere de mesaje, AOP
specializează acest model prin fixarea stărilor (numite acum stări mentale) acestor module (numite
acum agenți), stări care sunt compuse d in componente mentale (convingeri, intenții, obligații,
angajamente, decizii etc.). In acest context, obiectele sunt specializate în module intenționale. O
prelucrare într -un astfel de model constă în acțiunile acestor agenți, acțiuni prin care agenții cer
sau oferă informații, asistă sau intră în competiție cu alți agenți existenți în sistem. Comunicarea
între agen ți diferă în func ție de tipul de comunicare inten ționată, iar efectele a cesteia sunt diferite
în func ție de inten țiile particulare [FLOREA, 98].
Modelele de coordonare ordonează cunoștințele dispersate, disponibilitățile și planurile
unor agenți inteligenți, astfel încât ei să poată să -și cumuleze acțiunile sau să rezolve o p roblemă.
Intr-un sistem multi -agent un operator trebuie să se coordoneze cu un sistem de control, acesta

10 | P a g e
trebuind să îndeplinească rolul care i -a fost încredin țat. Deci, trebuie să fie definit un model de
coordonare adaptat acestei condi ții. In particular, trebuie să se dea operatorului posibilitatea să
interac ționeze pe mai m ulte nivele de decizie. Operatorul trebuie să fie capabil să identifice cu
ușurin ță pe ce nivel de decizie este situat și, pe acest nivel, să -și substituie decizia cu aceea a
sistemulu i de control (modul consultant) sau să -și orienteze decizia într -un mod diferit (modul de
supraveghere). Controlul de nivel inferior trebuie să fie automat în totalitate, operatorul
interac ționând cu sistemul în modul de supraveghere.
Criteriile pentru al ocarea activităților (acțiunilor) corespund în mod direct scopurilor de
proiectare:
se alocă activitățile agenților astfel încât să minimizeze comunicarea inter -agent și să
maximizeze coeziunea agentului;
alocarea acțiunilor independente și a acțiunilor ca re completează resursele agentului de la
diferiți a genți trebuie să expl oateze concurența și dependențele activităților ;
alocarea activităților pentru agenți trebuie făcută astfel încât să permită operatorului să
identifice centrele de decizie și nivelele de decizie. Operatorul trebuie să în țeleagă unde și
cum este luată fieca re decizie. Sistemul trebuie să fie transparent pentru operator.
In modelele bazate pe cooperare, toate deciziile vor fi descentralizate și subcomponentele
vor interacționa direct înt re ele. In aceste aplicații decizia nu va fi centralizată, ci se va dist ribui.
De obicei, se consideră că un sistem de control descentralizat este preferabil unui sistem de control
autonom. Distribuția deciziilor permite operatorului să identifice unde, cu m și care decizie este
luată. In sistemele complet descentralizate, deci zia este “ascunsă” de interacțiunile inter -agent.
Coordonarea este esența unui SMA fără de care nu există nici un beneficiu al interac țiunii
între agen ți, iar în aceste condi ții, grup ul de agen ți degenerează rapid într -o colec ție de agen ți
individuali cu un comportament haotic.
Sunt câteva motive pentru care agen ții au nevoie să fie coordona ți:
în primul rând, pentru a preveni haosul. Nici un agent nu posedă o viziune globală asupra
întregului grup din care face parte, lucru foarte probabi l în orice comunitate cu o
complexitate rezonabilă;

11 | P a g e

în al doilea rând, agenții întâlnesc constrângeri globale. Agenții care realizează
managementul de rețea pot să răspundă unor eventuale eșecuri în timpi de ordinul
secundelor sau de ordinul orelor. Coordo narea comportamentelor agenților este prin
urmare esențială la apariția unor astfel de constrângeri;
agenții în SMA posedă diferite capacită ți și posibilită ți de expertiză. Acesta este unul din
motiv ele utilită ții coordonării agen ților;
acțiunile agen ților sunt foarte des interdependente și, prin urmare, un agent trebuie să
aștepte un alt agent să -și completeze task -ul înainte de a -și executa propriul task. Astfel de
activită ți independente trebuie să fie coordonate.
Alocarea (sau repartiția) task -urilor a re loc prin definiția mecanismelor organizaționale
prin care agenții pot să pună în comun competența lor, în scopul de a realiza un obiectiv colectiv.
Este vorba despre descrierea modalității de atri buire a task -urilor știind că posibilitățile unui agent
depind de aptitudinile sale intrinseci (arhitectura de care dispune, capacități cognitive, tipuri de
comunicare avute în vedere), a mijloacelor energetice de care dispune (timpul de calcul și
autonomi a energetică), a resurselor externe (instrumente, surse d e energie) și a constrângerilor de
mediu [2].
Task -urile care reclamă mai multe mijloace, de lucru sau de pricepere, pe care un singur
agent nu este capabil să le furnizeze, trebuie să fie descompuse m ai întâi în mai multe subtask -uri,
apoi repartizate unor diferi ți agen ți. Aceste două opera ții sunt evident legate, deoarece
descompunerea task -urilor trebuie adesea să ia în considera ție competen ța agen ților prezen ți și să
faciliteze astfel reparti ția car e urmează.
De cele mai multe ori, într -o rețea semantică , agenții se identifică cu nodurile acesteia.
Există deci o ierarhie cu două tipuri de agenți: agenți de siguranță și agenți de conducere a
sistemului. Această relație ierarhică definește un mod de i nteracțiune client -server [TURGAI,
98][TURTUR1, 97].
Agenții de nivel superior selectează agen ții de nivel inferior pentru a executa activită ți.
Acest proces este prezentat în figura 1. Fiecare agent prezintă o opinie asupra controlului
sistemului. Agen ții de nivel superior selectează agen ții de nivel inferior pentru a executa activită ți
în mod independent, neexistând cooperare între agen ți pentru luarea deciziilor.

12 | P a g e
Fiecare subsistem este asociat unui agent “subsistem” care îl conduce. Datorită faptului că
pot apare conflicte de utilizare a sistemului, aceast ă arbitrare este făcută, în mod natural, de către
agen ții de conducere a sistemului, conform priorită ților agen ților de supraveghere.

Figura 1 – Activități distribuite în modul client -server
Coope rarea de tip partajare a task -urilor se verifică atunci când un agent detectează că nu
are informație suficientă pentru a executa un anumit task. Agentul trebuie deci să stabilească relații
de cooperare cu alți agenți. Utilizând cunoștințele despre coopera re, agentul va verifica în modelul
agenților cuno scuți dacă există agenți capabili să îl ajute. Dacă există unul sau mai mulți agenți ce
pot să -i ofere ajutor, primul pas este de a intra în negociere cu ei. Se numește agent organizator,
agentul care iniția ză o negociere și agenți colaboratori – agenții c are răspund cererii de negociere.
Obiectivul negocierii este încărcarea și responsabilizarea unuia sau mai multor colaboratori pentru
executarea unui task dat, venind astfel în ajutorul organizatorului [3].
In figura 2 este ilustrată această formă de interac țiune, partajarea task -urilor reprezentate
prin numere și ordonarea temporală a evenimentelor.

13 | P a g e

Figura 2 – Interacțiune prin partajare de task -uri
Cooperarea de tip partajare de rezultate se verifică atunc i când un agent dispune de un
anumit tip de infor mație și verifică în propriul model de agenți cunoscuți că există unul sau mai
mulți agenți interesați în acest tip de informație. Dacă există agenți interesați, această informație
le este transmisă voluntar .
In figura 3 este prezentată această formă de interacțiune, partajarea rezultatelor, în care, ca
și în figura anterioară, numerele reprezintă ordonarea temporală a evenimentelor.

Figura 3 – Pratajarea rezultatelor

14 | P a g e
Intr-un proces de luare a deciziilor conflictele sunt, de cele mai multe ori, inevita bile. Un
mod de a elimina conflictele constă în restrângerea analizei, selectând doar informația relevantă,
dezvoltând numai o alternativă și, în cazul în care aceasta eșuează, schimbând -o. Această strategie
mai are și avantajul de a accelera luarea decizi ilor. Atunci când cantitatea de informație se reduce,
atât analiza cât și luarea deciziilor sunt mai rapide.
Problema importantă care apare constă în calitatea alegerii. Situațiile conflictuale conduc
la rezultate stimulative în procesul luării deciziilo r. Analiza comparativă a alternativelor multiple
și simultane permite evaluarea op țiunilor și luarea unei decizii corecte. In plus, mai au și avantajul
de a găsi solu ții de mijloc: dacă o op țiune eșuează, se poate comuta ra pid la o altă alternativă.

Figura 4 – Inițierea unei negocieri de tip Rețea contractuală

Figura 5 – Agenții colaboratori trimit propuneri de execuție a task -ului către organizatori

15 | P a g e

Figura 6 – Agentul organizator selecționează un agen t collaborator și trimite cerere de execuție a
task-ului către acesta (k ≤𝑛)

Figura 7 – Agentul colaborator informează organizatorul despre acceptul sau refuzul cererii de
execuție a task -ului.

Figura 8 – Dacă agentul colaborator k refuză execuția tas k-ului, agentul organizator va trimite o
cerere d e execuție a task -ului către următorul agent selecționat (p ≤ n)

Figura 9 – Agentul colaborator trimite rezultatul execuției task -ului către agentul organizator.
Cum s -a văzut în considerațiile anterioare , rezolvarea unui conflict obligă la o luar e de
decizie. Această luare de decizie ia în considerare analiza și compararea diferitelor alternative și
eventual, o alegere, în cazul în care consensul nu este posibil. Din acest motiv nu este posibilă

16 | P a g e
distribui rea acestei luări de decizii între diferiți agenți ai comunității multi -agent. Trebuie să se
stabilească numai un singur agent de coordonare a procesului de rezolvare pentru fiecare tip de
conflict care poate apare.
Astfel, pentru rezolvarea conflictelor care pot surveni între diferite alternative propuse de
diverși agenți într -o situație dată, se dovedește necesar să se facă o comparație între diferitele
alternative și să se ia o decizie. Deși rezolvarea unui conflict trebuie să fie realizată prin
colabo rarea diverșilor agenți ai comunității care contribuie la gestionarea alternativelor,
conducerea procesului de rezolvare trebuie să fie făcută numai de un agent. Această capacitate de
a conduce rezolvarea de conflicte trebuie să fie în mod natural atribuit ă unui agent cunoscător al
domeniului.
Această centralizare a rezolvării fiecărui tip de conflict nu este o caracteristică bună a unui
sistem distribuit. Intr -o rețea de sisteme, oricare serviciu central dă naștere la întârzieri în procesul
de rezolvare; de asemenea, ar fi posibil ca un eșec într -un punct să poată cauza eșecul întregului
sistem. Totuși, există posibilită ți să nu se compromită atingerea obiectivelor sistemelor multi –
agent. Un eșec în rezolvarea unui conflict poate să fie depășit prin execu tarea unui plan alternativ,
care implică rez olvarea acestui conflict și care, în concluzie, poate fi executat cu succes.
Pentru fiecare tip de conflict care poate să apară într -un sistem multi -agent, trebuie să
existe un agent capabil să rezolve acest ti p de conflict. Ca urmare, se poate considera că rezolvarea
conflictelor este distribuită între diferi ți agen ți ai comunită ții.
Considerând conflictele ce pot apare într -un SMA în diverse situa ții, se poate realiza o
clasificare a acestora ca pozitive și negative. Astfel, pe parcursul partajării ta sk-urilor sau a
rezultatelor pot apare următoarele tipuri de conflicte [OLIMOU2, 92][JENOLI, 92]:
conflicte pozitive în partajarea task -urilor: apar atunci când există diverși agen ți capabili
să execute un task c erut de un organizator. Această situa ție com petitivă trebuie să fie tratată
printr -un mijloc de negociere;
conflicte negative în partajarea task -urilor: apar când nu există nici un agent capabil să
execute (sau nu dorește să execute) un task cerut de un an umit organizator. Acesta trebuie
să aleagă u n plan alternativ pentru depășirea acestei situa ții;

17 | P a g e

conflicte pozitive în partajarea rezultatelor: apar în cazurile în care, la un moment dat,
există diverși agen ți ce execută un task determinat și produc rezult ate diferite, dar coerente
(complementare sa u identice, dar cu credibilitate diferită);
conflicte negative în partajarea rezultatelor: apar atunci când există agen ți ce execută un
anumit task și produc rezultate antagonice sau lipsite de consisten ță.

Figura 10 – Rezolvarea conflictelor

18 | P a g e
2.3 Aplica ții ale si stemelor multi -agent
În secțiunile ce urmează vom prezenta câteva domenii de utilizare ale agenților inteligenți
și a sistemelor multiagent în anumite probleme din lumea reală.
1. Agenți în comerț ele ctronic (e -commerce) – În ultima vreme, agenții inteligenți sunt deosebit
de utili în domeniul afacerilor electronice (e -bussiness), cu subdomeniile acesteia: comerț
electronic (e -commerce), servicii bancare electronice (e -banking), învățământ electronic ( e-
learning), jocuri de noroc electronice (e-gambling), franciză electronică (e -franchise).
Din 1993 este operațional sistemul FAIS, care se referă la domeniul tranzacțiilor financiare.
Sistemul a fost proiectat și implementat ca un sistem cooperativ incl uzând oameni și agenți
software.
Wenge r și Probst au analizat posibilul rol și impact al paradigmei bazate pe agenți în
domeniul general al furnizării serviciilor financiare, discutând diverse modalități în care agenții
inteligenți ar putea fi folosiți p entru: operațiuni finaciare, tranzacții, segmentul de piață.
Comerțul electronic se referă la partajarea informațiilor despre afaceri, gestionarea
relațiilor de afaceri și conducerea tranzacțiilor de afaceri prin intermediul rețelelor de comunicare.
Come rțul electronic include relații între co mpanii (business to business), relații între clienți
(customer to customer) precum și relații între companii și clienți (business to customer) [4].
Tehnologia agenților inteligenți este folosită în diversele etape ale experienței de vânzare:
Identificare. Ag enții monitorizează o mulțime de senzori sau fluxuri de date și efectuează
anumite acțiuni atunci când apare o anumită condiție prespecificată. Spre exemplu, există
agentul Eyes al site -ului Amazon.com, care monitori zează cataloagele de cărți de vânzare
și notifică cumpărătorii atunci când anumite evenimente sunt interesante pentru cumpărător
(când o anumită carte din categoria X devine disponibilă).
Operații de brokering. Agenții sunt folosiți pentru a indica cumpără torilor (clienților) acele
produse care satisfac cel mai bine cerințele lor.
Negocieri. Agenții sunt folosiți pentru negocierea prețurilor și altor aspecte ale
tranzacțiilor.

19 | P a g e

Plată și livrare. Agenții sunt folosiți pentru a monitoriza diferitele opțiuni de plată și livrare
ale produselor.
Evaluarea serviciilor. Agenții sunt folosiți pentru a evalua serviciile de producție, serviciile
oferite consumatorilor precum și o evaluare a experienței de cumpărare și decizie.
2. Agenți în servicii bancare electronice (e-banking) – În preze nt, metodele de plată
electronică joacă un rol foarte important în toate formele de business on -line. În ciuda dezvoltării
sistemelor bancare electronice, care permit un anumit grad de automatizare, interfețele Web
necesită totuși un grad destul de ridicat de interacțiune umană. Un mediu bazat pe agenți care
furnizează servicii bancare electronice suportă diferite tranzacții în medii software.
Tranzacțiile și ordinele de plată, spre exemplu, pot fi efectuate electronic, dar numai dac ă
omul introduce codul corect sau dacă apasă butonul corect de pe interfața grafică specifică.
Analiștii prezic faptul că în viitorul apropiat oamenii nu vor mai merge la bănci și nici nu
se vor loga la Internet pentru a -și rezolva problemele bancare. Ca o alternativă, oameni i vor delega
gestionarea conturilor bancare, plăților, investițiilor, asigurărilor unui asistent financiar electronic.
Ideea de bază este că entități software vor acționa în folosul oamenilor și/sau furnizorii de
servicii pot automa tiza anumite afaceri e lectronice sau activități comerciale. Ca urmare, se poate
imagina o instituție virtuală (IV) care oferă servicii bancare agenților care accesează serviciile unei
piețe bancare. Este vorba de fapt despre un agent (instituție bancară vi rtuală) care oferă ser vicii
agenților care accesează piața.
Aceste servicii pot fi de două feluri:
plăți electronice care să permită agenților să facă/primească plăți;
gestionare de conturi pentru crearea/păstrarea/închiderea de conturi bancare.
3. Agenț i în Dat a Mining Distr ibuit – Data Mining (DM) sau descoperirea de cunoștințe în
bazele de date (Knowledge Discovery in Databases – KDD) este procesul căutării unor informații
semnificative în volume mari de date, analiza explorării, prin mijloace automate sau semi –
automate, un or mari cantități de date în scopul descoperirii unor șabloane, reguli sau tendințe
semnificative.

20 | P a g e
DM este considerat ca un domeniu de cercetare în cel puțin trei domenii: statistică,
Inteligență Artificială și baze de date. Câteva dintre cele mai popula re tehnici și instrumente
folosite în DM sunt:
1) Metode statistice. Unul dintre principalele scopuri ale DM, și mai general ale inferenței
statistice, este, deseori, extragerea informațiilor cauzale din date. În acest sens, regresia
liniară, regresia multiplă și regresia neliniară sunt câteva dintre metodele de modelare
folosite ca metode statistice în DM.
2) Metode ale Inteligenței Artificiale. Cele mai importante metode de IA folosite în DM sunt
cele ale Inteligenței Computaționale (Compu tational Intell igence) și ale Învățării Automate
(Machine Learning). Dintre metodele Inteligenței Computaționale folosite în DM amintim:
rețele neuronale, sisteme fuzzy, calculul probabilistic, calculul evolutiv. Domeniul
Învățării Automate constă în metod e care să permi tă calculatorului să învețe relații din
anumite seturi de date. Dintre cele mai populare metode ale Învățării Automate folosite în
DM amintim mașinile cu suport vectorial și arborii de decizie.
3) Metode specifice bazelor de date. Cercetătorii din domeniul ba zelor de date au dezvoltat o
serie de metode și mecanisme care să fie folosite în sarcini de DM. În special decoperirea
regulilor de asociere a fost folosită în domeniul DM și este foarte potriv ită pentru seturi
mari de date.
DDM se referă la descoperirea șabloanelor în seturi de date distribuite. Seturile de date
sunt stocate în baze de date locale, găzduite de calculatoare locale, care sunt conectate printr -o
rețea de calculatoare. DM are loc la nivel local și apoi la nvel global unde rezultatele locale
(obținute în urma DM local) sunt combinate pentru a obține rezultatele globale. Figura 11 prezintă
o arhitectură de Data Mining Distribuit [3].

21 | P a g e

Figura 11 – Arhitectura unui sistem de DDM
Cele dou ă metode de bază dezvoltate pentru arhitecturi de DDM sunt: mo delul client –
server și modelul bazat pe agenți.
Modelul bazat pe agenți pentru o arhitectură de DDM poate fi împărțit în: sisteme care
folosesc agenți mobili și sisteme care folosesc agenți st aționari. Păstrarea securității implică faptul
că, în unele si tuații, utilizatorul poate exploata date sensibile, care nu ar trebui să părăsească site –
ul proprietarului. În aceste situații, există opțiunea de a folosi modelul bazat pe agenți mobili, în
care algoritmul de mining și parametrii relevanți ai acestuia sun t trimiși spre site -ul de date iar la
sfârșitul procesului agentul mobil este distrus. În modelul bazat pe agenți, fiecare bază de date
locală are asociat unul sau mai mulți agenți care procesea ză datele locale și comunică rezultatele
celorlalți agenți sau unui agent central supervizor care controlează comportamentul agenților locali
[3].
Agenții pot lucra în paralel și pot și să partajeze informația pe care au obținut -o la un
moment dat. Ca urmare , arhitectura unui sistem de DM folosind agenți inteligenți co nține câțiva
agenți locali corespunzători bazelor de date locale și un agent central corespunzător bazei de date
centrale. Într -o astfel de arhitectură, fiecare agent procesează datele din baza sa de date locală și
comunică rezultatul agentului central, ia r apoi rezultatele explorării vor fi combinate de agentul
central. Figura 12 prezintă arhitectura unui sistem de DM folosind agenți inteligenți.

22 | P a g e

Figura 12 – Arhitectura unui sistem de DDM folo sind agenți inteligenți
4. Agenți Web de Informații – Datorită naturii dinamice a World Wibe Web, a creșterii
rapide a cantității de date precum și eterogenității serviciilor, extragerea informațiilor utile din
camtități mari de date stocate a devenit o s arcină care nu poate fi efectuată doar de utilizatori [3].
Conform metaforei “Information Superhighway” a lui Etzioni, un agent de informație ar
putea fi:
conducătorul de pe bancheta din spate care face sugestii la orice moment;
un conducător de taxi care ne conduce la destinație;
un consilier ale cărui cunoștin țe ne scutesc de a aborda personal anumite sarcini.
Agenții inteligenți pentru Internet sunt numiți în general agenți de informații.
Tehnologia agenților de informații este un subdomeniu al tehnolo giei generale a agenților
software inteligenți, fiind o tenhologie interdisciplinară care folosește metode și mecanisme din
Inteligența Artificială, baze de date și sisteme bazate pe cunoștințe, sisteme distribuite de
informații, regăsirea informației (inf ormation retrieval) și interacțiune între utilizator și calculator
(human computer interaction).

23 | P a g e
Scopul acestei tehnologii este de a dezvolta entități computaționale software autonome
(agenți inteligenți) care trebuie să acceseze surse de informații eter ogene și distribuite geografic,
așa cum sunt în Interne t. Acești agenți efectuează căutări active, regăsire, analizare și manipulare
a informațiilor eterogene, precum și vizualizarea acestora.
Agenții de informații caută în mod activ informații pentru uti lizator; ei pot scana în baze
de date on -line, bibliote ci de documente, sau prin directoare în scopul căutării unor documente
care pot fi de interes pentru utilizator. Fiind niște entități inteligente, agenții de informații pot ține
la curent utilizatorul în legătură cu orice dezvoltare a unui anumit domeniu ( spre exemplu dacă
într-o bibliotecă de documente a apărut un document care îl intresa pe utilizator).
Agenții de informații sunt folosiți aproape în toate aplicațiile legate de Web. Spre exemplu,
un agent numit Softbot este implementat pentru a acționa c a un asistent personal a utilizatorilor
Web care caută anumite informații. Agentul va descoperi cea mai bună metodă de căutare și cea
mai bună sursă de date pentru a satisface cerințele utilizatorului. Alte exemple de agenți de
informații sunt: BargainFind er (un agent de cumpărare a compact discurilor), Maxims (un agent
pentru filtrare e -mail-uri, MCL (un agent pentru fixarea de întâlniri), NewT (un agent pentru
filtrarea știrilor).
O altă categorie d e agenți de informații sunt agenții de informații adapt ivi. Aceștia se pot
adapta la schimbările din mediile de informații în care acționează. În această categorie de agenți
adaptivi ar putea intra asistenții personali pe Web care au capacitatea de a învăț a.
Adaptarea unui agent la schimbările care apar în mediul său poate fi realizată în mod izolat
sau în colaborare cu alți agenți, folosind metode de învățare pentru un sigur agent, respectiv mai
mulți agenți. Cele mai cunoscute tipuri de metode de învăța re sunt (așa cum se va vedea în
Capitolu l VIII): învățarea supervizată, învățarea nesupervizată și învățarea prin întărire.

24 | P a g e
3. Mediul de programare NetLogo
3.1 Informații generale
NetLogo este un limbaj și un mediu de simulare bazat pe agenți, putând fi ut ilizat atât de
copii cât și de specialiș ti de nivel înalt datorită unui cod foarte simplu. Conceptul programare
bazată pe agenți se regăsește sub forma de turtles, patches, links și observer. Aceste obiecte
definesc indivizii (agenții), mediul (celula sau substratul), legaturile dintre indivizi și punctul de
vedere (observator extern sau agent/individ). Mediul NetLogo este extrem de util în explorarea
fenomenelor emergente și deține o bibliotecă uriașă cu modele și instrumente din biologie, fizică,
economie , chimie, psihologie sau dinamică de sis teme. Este de asemenea folosit și recomandat în
cursurile online (MOOC) de complexitate realizate de Institutul Santa Fe.
Lumea NetLogo este compusă din agenți. Agenții sunt elemente care pot respecta
instrucțiuni. În NetLogo, există patru tipuri de agenț i: turtles, patch -uri, link -uri și observatorul.
Turtles sunt agenții care se pot deplasa în lume. Lumea este bidimensională și este împărțită într –
o rețea de patch -uri. Fiecare patch este o adevărată bucată de “tere n” pe care turtles se pot deplasa.
Link -urile sunt agenții care leagă două turtles [5].
Observatorul nu are o locație – ne putem imagina că acesta examinează lumea de turtles și
patch -uri. Observatorul nu observă în mod pasiv – el dă instrucțiuni celorlalți agenți. La
inițializarea NetLogo, nu exi stă turtles.
Observatorul poate crea turtles noi. De asemenea, și patch -urile pot să creeze noi turtles.
(Patch -urile nu se pot deplasa, dar în alte privințe sunt la fel de “vii” ca și turtles.) Patch -urile au
coordinate. Patch -ul de coordonate (0, 0) este denumit origine și coordonatele celorlalte patch -uri
sunt distanțele pe verticală și orizontală față de acesta. Numim coordonatele unui patch pxcor și
pycor. La fel ca în planul stand ard de coordinate matematice, pxcor crește pe măsură ce te deplasezi
spre dreapta iar pycor crește pe măsură ce te deplasezi în sus.
Numărul total de patch -uri este stabilit de setările min -pxcor, max -pxcor, min -pycor, și
maxpycor. La inițializarea NetLo go, min -pxcor, max -pxcor, min -pycor, și max -pycor sunt – 16,
16, -16 și, respectiv, 16. Aceasta înseamnă că pxcor și pycor pot varia ambele între -16 și 16, adică
sunt de 33 ori 33, sau 1089 de patch -uri în total. (Numărul de patch -uri se poate modifica di n

25 | P a g e
Setări.) Turtles au coordona tele xcor și ycor. Coordonatele unui patch sunt întotdeauna numere
întregi, dar coordonatele unui turtle pot avea zecimale. Acest lucru înseamnă că un turtle poate fi
poziționat în orice punct în interiorul patch -ului său; nu trebuie să fie în central patc h-ului. Link –
urile nu au coordonate. Fiecare link are două capete, la fiecare capăt fiind câte un turtle. Dacă
oricare turtle moare, moare și link -ul. Un link este reprezentat vizual ca o linie ce leagă două turtles.
3.2 Agenți și variabile
În NetLogo, comenz ile și raportorii indică agenților ce este de făcut. O comandă este o
acțiune pe care un agent trebuie s -o ducă la îndeplinire, rezultând un oarecare efect. Un raportor
reprezintă instrucțiuni pentru calcularea unei valori, pe care ulterior agentul o “rapo rtează” oricui
ar întreba. De obicei, numele unei comenzi începe cu un verb, cum ar fi “create”, “die”, “inspect”,
sau “clear”.
Majoritatea numelor raportorilor sunt substantive sau locuțiuni substantivale. Comenzile și
raportorii construiți în NetLogo s unt numiți primitive. Dicționarul NetLogo are lista completă a
comenzilor și raportorilor încorporați. Comenzile și raportorii definiți de utilizator sunt numiți
proceduri. Fiecare procedură are un nume, precedat de cuvântul -cheie to sau to -report, în func ție
de faptul că e o procedură de comandă sau una de raportor. Cuvântul -cheie end arată finalul
comenzilor din procedură [6].
Odată ce definești o procedură, poți să o utilizezi și în altă parte în program. Multe comenzi
și rapo rtori iau intrări – valori pe care comanda sau raportorul le utilizează pentru îndeplinirea
acțiunilor lor sau pentru calculul rezultatelor acestora. Iată două exemple de proceduri de comandă:

26 | P a g e
Se remarcă utilizarea punct -virgulelor pentru adăugarea de “comentarii” programului.
Come ntariile pot face codul mai ușor de citit și de înțeles, dar nu -i afectează comportamentul.
În acest program,
setup și go sunt comenzi definite de utilizator.
clear -all, create -turtles, reset -ticks, ask, lt (“întoarcere la stânga”), rt (“întoarcere la
dreapta”) și tick, sunt toate comenzi primitive.
random și turtles sunt raportori primitive. random ia un număr unic ca pe o intrare și
raportează un întreg aleator mai mic decât intrarea (în acest caz, între 0 și 9). turtles
raportează un set de agenți con stând din toți turtles. (Setările agenților vor fi explicate
ulterior.)
Setup și go pot fi denumite de alte proceduri, sau de butoane, sau prin Centrul de Comandă.
Multe modele NetLogo au un buton de o singură dată care apel ează o procedură denumită setu p și
un buton de tot timpul care apelează o procedură denumită go.
În Netlogo, se poate specifica care agenți – turtles, patch -uri sau link -uri – trebuie să ruleze
fiecare comandă. Dacă nu se specifică, atunci codul este con dus de către observator. În co dul de
mai jos, observatorul utilizează ask pentru a face setul de toate turtles să ruleze comenzile dintre
parantezele pătrate. clear -all și create -turtles pot fi rulate doar de către observator. Pe de altă parte,
fd poate fi rulat doar de turtles. Alte c omenzi și raportori, cum ar fi set și ticks, pot fi rulate de
diferite tipuri de agenți. Iată câteva caracteristici mai avansate, de care se poate profita pentru
definirea propriilor proceduri.
Variabilele agenților sunt locu rile în care se stochează valo ri (cum ar fi numerele) într -un
agent. Variabila unui agent poate fi o variabilă globală, o variabilă a unui turtle, o variabilă a unui
patch, sau o variabilă a unui link. Dacă o variabilă este globală, există o singură valoar e pentru ea,
și oricare agent o poate accesa [7].
Se poate spune că variavilele globale aparțin observatorului. Variabilele unor turtles, patch –
uri sau linkuri sunt diferite. Fiecare turtle are propria sa valoare pentru fiecare variabilă. La fel este
și în c azul patch -urilor sau link -urilo. Unele variabile sunt construite în NetLogo.

27 | P a g e
De exemplu, fiecare turtle sau link are o variabilă color, și toate patch -urile au o variabilă
pcolor. (Variabila patch -ului începe cu “p” pentru a nu fi confundată cu variabil a unui turtle, de
vreme ce tur tles au acces direct la variabilele patch -ului.) Dacă se stabilește varibila, turtle sau
patch -ul își vor schimba culoarea. Alte variabile de turtle încorporate includ xcor, ycor,și heading.
Alte variabile de patch încorporate includ pxcor și pycor.
Se po t defini, de asemenea, propriile variabile. Se poate construi o variabilă globală prin
adăugarea unui comutator, cursor, selector, sau a unei casete de intrări la prpriul model, sau prin
utilizarea cuvântului -cheie globals la începutul codului, ca de exemp lu:
globals [score]
Se pot defini, de asemenea, noi variabile ale turtles, patch -urilor sau link -urilor folosind cuvintele
cheie turtles -own, patches -own sau links -own, ca de exemplu:
turtles -own [energy speed]
patches -own [friction]
links -own [strength ]
Aceste variabile pot fi folosite în mod liber în modelul propriu. Utilizați comanda set pentru
a le configura. (Orice variabilă ce rămâne nesetată are valoarea de pornire zero.) Variabilele
globale pot fi citi te și stabilite în orice moment de către ori care agent. De asemenea, un turtle poate
citi și configura variabilele de patch ale patch -ului pe care se află. De exemplu, acest cod:
ask turtles [ set pcolor red ]
Determină fiecare turtle să facă patch -ul pe care stă roșu. (Datorită faptului că variabi lele
specifice patch -urilor sunt separate de cele specifice turtles în acest fel, nu se poate ca o variabilă
turtle și o variabilă de patch să aibă același nume.) În alte situații în care se dorește ca un agent s ă
citească variabila altui agent, se poate u tiliza of. Exemplu:
show [color] of turtle 5
;; prints current color of turtle with who number 5

28 | P a g e
3.3 Interfața matematică
Butoanele din interfață oferă o modalitate ușoară de a controla modelul. De obicei , un
model va avea cel puțin un buton “setup”, pentr u a stabili starea inițială a lumii, și un buton “go”
pentru a face modelul să ruleze continuu. Unele modele au butoane suplimentare care realizează
alte acțiuni.
Un buton conține cod NetLogo. Acel cod este rulat când se apasă butonul. Un buton poate
fi fie “buton Once”, fie “buton Forever”. Acest lucru poate fi controlat prin editarea butonului și
bifarea sau debifarea casetei “Forever”. Butoanele Forever continuă să -și execute codul în mod
repetat, pân ă când fie se ajunge la comanda stop, fie utilizator ul apasă butonul din nou pentru a -l
opri. Dacă butonul e oprit, codul nu se întrerupe, ci se așteaptă încheierea execuției codului său.
De obicei, un buton este etichetat cu codul pe care -l execută.
De exemplu, un buton pe care scrie “go” conține de obic ei codul “go”, care înseamnă
“execută procedura go”. (Procedurile sunt definite în tab -ul Code). De asemenea, se poate edita un
buton și introduce un “nume afișat” pentru buton, care e un text ce apare pe buton în loc de cod.
Această funcție ar putea fi ut ilizată dacă se crede că în realitate codul este prea confuz pentru
utilizatori [5].
Când s -a asociat o secvență de cod unui buton, trebuie de asemenea specificați agenții care
vor executa acel cod. Se poat e alege ca observatorul să ruleze codul, sau toți tu rtles, toate patch –
urile sau toate link -urile. (Dacă se intenționează ca un cod să fie executat doar de anumiți turtles
sau anumite patch -uri, se poate crea un buton de observator, care apoi să utilizeze comanda ask
pentru a cere doar unora dintre turtles sau patch -uri să facă ceva.)
Când se editează un buton, există opțiunea de a desemna o tastă asociată butonului. Acest
lucru face ca acea tastă de pe tastatură să se comporte la fel ca o apăsare a buton ului. Dacă butonul
respectiv este un buton Forever, acesta va rămâne activ până când tasta este apăsată din nou (sau
este apăsat butonul). Tastele sunt deosebit de utile pentru jocuri sau orice model în care este
necesară declanșarea rapidă a butoanelor.
În modelele cele mai simple, fiecare variabilă are d oar un fragment de informație, de obicei
un număr sau un șir. Listele permit stocarea mai multor părți de informație într -o singură valoare

29 | P a g e
prin colectarea acelor informații într -o listă. Fiecare valoare din listă poate fi de orice tip: un număr,
sau un și r de caractere, un agent sau un set de agenți, sau chiar o altă listă. Listele permit
încorporarea convenabilă de informații în NetLogo.
În cazul în care agenții efectuează un calcul repetitiv pentru ma i multe variabile, ar putea
fi mai ușor să existe o listă de variabile, în loc de mai multe variabile numerice. Câțiva primitivi
simplifică procesul de realizare a aceluiași calcul pentru fiecare valoare dintr -o listă. Dicționarul
NetLogo are o secțiune ca re specifică toți primitivii asociați listelor.
Toate numerele din NetLogo sunt stocate intern ca numere de dublă precizie în virgulă
mobilă, așa cum sunt definite în standardul IEEE 754. Acestea sunt numere pe 64 biți, constând
dintr -un un bit de semn, u n exponent de 11 biți, și o mantisă de 52 de biți. A se vedea standardul
IEEE 754 pentru detalii. Un "număr întreg" în NetLogo este pur și simplu un număr care se
întâmplă să nu aibă nici o parte fracționară [5].
Nu se face nici o distincție între 3 și 3.0; ele reprezintă același număr. (Acest lucru este
similar cu modul în care majoritatea oamenilor folosesc numerele în viața de zi cu zi, dar diferit
de anumite limbaje de programare. Unele limbaje tratează numerele întregi și cele în virgulă
mobilă ca fiind de tipuri distincte.)
Numerele aleatoare folosite d e NetLogo sunt ceea ce se numește "pseudo -aleatoare".
(Acest lucru este tipic în programare.) Asta înseamnă că, deși par aleatoare, ele sunt, de fapt,
generate de un proces determinist. “Determinist” înse amnă că se obțin aceleași rezultate de fiecare
dată, dacă se pornește de la același seed.
În contextul unei modelări științifice, numerele pseudo -aleatoare sunt de fapt preferabile
celor aleatoaret. Aceasta deoarece este important ca un experiment științ ific să poată fi reprodus –
ca oricine să -l poată în cerca și să obțină același rezultat. Deoarece NetLogo utilizează numere
pseudo -aleatoare, “experimentele” făcute cu el pot fi reproduse și de către alte persoane.
3.4 Desenare și producție
Înainte de plotare , trebuie create una sau mai multe parcele în tab -ul Interface. Pentru mai
multe informații cu privire la utilizarea și editarea parcelelor, se va consulta Ghidul de interfață
(Interface Guide).

30 | P a g e
Cele două comenzi de bază pentru plotare sunt plot și plotxy .
Pentru plot trebuie specificată doar valoarea y care va fi reprezentată. Valoarea x va fi în
mod automat 0 pentru primul punct trasat, 1 pentru al doilea, și așa mai departe. (Asta dacă
"intervalul" de trasare are valoarea implicită 1, se poate schimba intervalul dacă se dorește acest
lucru).
Comanda plot este deosebit de utilă atunci când se dorește ca modelul să traseze un nou
punct la fiecare pas. Exemplu:
plot count turtle
Dacă se dorește specificarea atât a valorilor lui x, cât și celor ale lui y ale punctului dorit, se va
utiliza plotxy. Acest e xemplu presupune că există o variabilă globală numită time:
plotxy time count -turtles
Fiecare parcelă și stilourile (pens) sale de trasat au domenii de configurare și actualizare
care pot conțin e comenzi (de obicei, plot sau plotxy). Aceste comenzi sunt r ulate automat când
sunt declanșate de alte comenzi în NetLogo [8].
Comenzile pentru configurarea plotului și comenzile pentru configurarea instrumentelor
de trasat sunt rulate atunci când sunt lans ate comenzile reset -ticks sau setup -plots. În cazul în care
comanda stop se execută în corpul de configurare al plotării atunci comanda pentru configurarea
instrumentelor de trasare nu va fi rulată.
Comenzile pentru actualizarea plotării și cele pentru a ctualizarea instrumentelor de trasat
sunt rulate atunci la ex ecuția uneia din următoarele comenzi: reset -ticks, tick sau updateplots. În
cazul în care comanda stop se execută în corpul de actualizare al plotării, comanda pentru
actualizarea instrumentelor de trasare nu va fi rulată.
Limitele implicite x și y ale un ui plot sunt numere fixe, dar ele pot fi modificate în timpul
configurării sau pe măsură ce modelul rulează.
Pentru a modifica limitele în orice moment, se utilizează set -plot-x-range și set -plot-
yrange. Sau, se pot lăsa intervalele să crească în mod aut omat. În orice caz, atunci când plotul este
șters, limitele vor reveni la valorile lor implicite.

31 | P a g e
În mod implicit, toate ploturile din NetLogo au funcția de autoscalare activată. Aceasta
înseam nă că, dacă modelul încearcă să ploteze un punct care este în afara limitelor de afișare,
limita de plotare va crește de -a lungul uneia sau a ambelor axe, astfel încât noul punct să fie vizibil.
În ipoteza că intervalele nu vor trebui schimbate de fiecar e dată când se adaugă un nou
punct, atunci când limitele cres c, ele lasă un spațiu suplimentar: 25% dacă cresc orizontal, 10% în
cazul în care cresc pe verticală.
Dacă se dorește dezactivarea acestei caracteristici, se va edita plotul și se va debifa Aut o
Scale. În prezent, nu este posibilă activarea sau dezactiva rea aceastei funcții doar pe o singură axă,
se aplică întotdeauna la ambele axe.
Se poate afișa legenda unui plot bifând casuța "Show legend" în caseta de dialog edit. Dacă
nu se dorește ca un anumit stilou să apară în legendă, se poate debifa casuța "Sh ow legend" pentru
stiloul respectiv, de asemenea, în setările avansate pentru plot (setările avansate pentru plot pot fi
deschise dând click pe butonul cu iconița creion pentru stiloul respectiv în tabelul de stilouri în
caseta de dialog plot edit).
Spați ul de desen este un layer unde agenții turtle pot face semne vizibile. El apare deasupra
patch -urilor, dar sub agenții turtle. Inițial, este gol și transparent. Se poate observa acest spațiu,
însă agenții turtle (și patch -urile) nu pot percepe desenul și n u pot reacționa la el.
Agenții turtle pot desena și șterge liniile din desen utilizând comenzile pen -down și pen –
erase. Când stiloul unui agent turtle este jos (sau pe modul de ștergere), agent ul turtle trasează (sau
șterge) o linie în spatele său ori de câte ori se mișcă.
Liniile sunt de aceeași culoare ca și agentul. Pentru a opri desenarea (sau ștergerea), se
folosește pen -up. Liniile trasate de agenții turtle au în mod normal grosimea de u n pixel. Dacă se
dorește o grosime diferită, se va seta varia bila agentului pen -size la un numar diferit înainte de a
trasa (sau șterge). Pentru agenții noi, variabila este setată la 1.
Liniile trasate atunci când un agent se deplasează într -o direcție i mprecisă, cum rezultă din
utilizarea setxy sau move -to, vor f i trasate pe cea mai scurtă direcție care satisface topologia
curentă [8].

32 | P a g e
4. Aplicația practică și rezultate
4.1 Descrierea aplicației
Termenul Programare orientată spre agent (AOP) definește o nouă paradigmă de
programare. Acesta reprezintă un cadru computațion al a cărui noțiune compozițională centrală este
un agent, văzută ca o componentă software cu calități mentale, abilități de comunicare și o noțiune
de timp. AOP este considerată ca fiind o specializare a programării orientate -obiect (OOP), dar
există unele diferențieri importante între aceste concepte și anume obiectele și agenții diferă în
gradul lor de autonomie.
Spre deosebire de obiectele care invocă direct acțiunile altor obiecte, age nții își exprimă
dorința de a executa o acțiune. De asemenea, agenți i pot avea deseori interese conflictuale, astfel
încât ar putea fi dăunător pentru un agent să execute o cerere de acțiune de la un alt agent.
O diferență suplimentară este flexibilitatea , agenții manifestă adesea comportamente
proactive și adaptive și fo losesc învățarea pentru a -și îmbunătăți performanțele în timp, firul de
control este diferența majoră finală, în timp ce sistemele multi -agent sunt deduse în mod implicit
prin multi -agent, există de obicei un singur fir de control în OOP.
Paradigma AOP a dus la dezvoltare a limbajelor de programare spre agenți, astfel s -a
dezvoltat o serie de limbaje care sunt prezentate în figura 13.

Figura 13 – Sumar specific limbajelor de programare spre agen ți

33 | P a g e
Mediul de programare ales este NetLogo, care este un me diu de programare gratuit pentru
modelarea și simularea fenomenelor naturale și sociale, creat în 1999 de Uri Wilensky, fiind în
permanență dezvoltare .
Aplicația simulează un s istem multi -agent de manangement a situațiilor de urgență la nivel
macroscopic, capabil să asigneze echipaje potrivire de intervenție în funcție de tipul și localizarea
situației semnalate.
Mediul pe care se exersează simularea este construit pe o hartă d e dimensiune 203×161
patches (cu rol de agenți mobili), discontinuă, însemnând că agenții care prin deplasarea lor
depășesc marginile lumii sunt distruși. În acest plan a fost reprezenată structura unui oraș, împărțit
în șase sectoare, ele fiind delimitate de artere rutiere și fiecare fiind colorat diferit. Pentru o
modelare mai apro piată realității, străzile principale ale orașului nu au fost construite simetric față
de centru hărții, iar cele șase sectoare nu au dimensiuni egale. Pe hartă se observă ampla sați patru
agenți. Spitalul, Secția de Poliție, Stația de pompieri și Pista de elicoptere, cât și marcajele zonelor
principale de acces în sectoare – figura 14.

Figura 14 – Modelul orașului

34 | P a g e
În acest model, str ăzile sunt compuse de șapte patch -uri consec utive: dou ă secven țe de trei
patch -uri gri, reprezentand cate trei benzi pentru fiecare sens, despar țite de un patch de culoare
albă care simbolizeaz ă linia dubl ă continu ă. Arterele care formeaza intersec țiile reprezentate sunt
dispuse vertical sau orizontal pe hart ă, dup ă axele Nord -Sud și Vest -Est.
Cele opt intersec ții sunt de dou ă tipuri, șapte dintre ele fiind situate la întalnirea a trei
sensuri de drum, cea de -a opta fiind la intalnirea a dou ă drumuri perpendiculare. Locurile de acces
în car tier sunt marcate în dreptul intersec țiilor corespunzatoare prin etichetele „lntrare". Fiecare
intersec ție este semaforizat ă, cele opt semafoare fiind autonome.

Figura 14 – Intersecție în fomră de T

Figura 15 – Intersecție în formă de cruce

35 | P a g e
După cum s e observa în figurile 16 și 17, o intersec ție co țtine o serie de patch -uri a căror
culoare alterneaz ă între ro și și verde, reprezent ând semafoarele. În func ție de tipul intersec ției
semafoarele sunt în 3 timpi (figura 16), respectiv în 4 timpi ( figura 17).
Intersec țiile în form ă de T con țin nou ă semafoare, c âte un set trei pentru fiecare sens de
mers. Cele trei seturi sunt interconectate, atunci c ând unul din ele arat ă culoarea verde pentru a
permite trecerea participan ților la trafic, celelalt e două sunt setate pe culoarea ro șie. Se disting deci
trei cazuri posibile de func ționare a inter secției în condi ții normale.

Figura 16 – Cele trei stări ale semaforului în intersecția de tip T
Intersecțiile în formă de cruce conțin doisprezece semafoare, la fel, câte un set de trei pe
fiecare sens de mers. În condiții normale de funcționare, cele patru seturi sunt interconectate
asigurând patru stări posibile ale semafoarelor luminoase: atunci când un set este de culoare verde,
celel alte trei sunt de culoare roșie.

Figura 17 – Cele patru stări ale semafoarului în cruce

36 | P a g e
4.2 Implementarea aplicație i
Mulțimea de participanți activi la traffic este compusă din totalitatea agenților
autovehiculelor aflate pe străzi. Acești agenți au formă de autovehicul de culoare albastră și se
deplasează numai pe agenții artere ale orașului. La generare, acest tip d e agent este poziționat
înainte de intrarea în intersecția în formă de cruce, pentru a fi mai ușor împrăștiați pe hartă. Acești
agenți m așină intră în contact cu agenții din intersecții, iar atunci când se deplasează spre marginea
hărții, interacționează ș i cu cei din acea zonă.
Pentru a evita nevoia de a crea agenții automobile din cauza ieșirii unora deja existenți din
lumea simulate, î n momentul poziționării pe unul din patch -urile linitrofe, automobilul este mutat
aleator pe unul din patch -urile șosele lor care reprezintă intrarea în oraș.
La intrarea în intersec țiile în forma de T, automobilelor de pe benzile 1 și 3 le -a fost
atribuit ă prin programare c âte o direc ție de continuare a traseului în timp ce pentru band ă din
mijloc exist ă două posibilit ăți de continuare. Acest ra ționament apare în urma analiz ării
comportamentului șoferilor de a ramane dup ă virare pe aceea și band ă pe care au fost încadra ți
înainte de a vira sau de a -și păstra direc ția de mers. De exemplu, pentru intersec ția din figura 14,
trei șoferi care circul ă dinspre est spre vest, fiecare încadrat pe cate o band ă vor proceda în
următorul mod: șoferul de pe prima band ă va vira spre nord, iar cel de pe a treia band ă va vira spre
sud Șoferul de pe a doua band ă va vira aleator fie spre nord fie spre sud, fiecare dintre aceste dou ă
scenarii av ând o probabilitate de îndeplinire de 50%.

Figura 18 – Comportamentul în intersecție

37 | P a g e
Pentru intersec ția în form ă de cruce, comportamentul șoferilor nu a fost modelat s ă conțină
nicio componenta aleato are. Șoferii de pe prima band ă vireaz ă spre dreapta, cei de pe a dou a band ă
își continu ă drumul iar cele de pe band a a treia vireaz ă spre stanga. Pentru exemplificare se
presupun trei conducatori auto circul ând dinspre sud spre nord, fiecare pe cate o band ă din cele
trei. La intrurea în intersec ție conducatorul auto de pe prima band ă își schimb ă direc ția spre est,
cel de pe a doua band ă își continu ă calatoria spre n ord iar cel încadrat pe banda a treia își schimb ă
traiectoria spre vest. Bineînteles toate ce le trei autovehicule își păstreaz ă încadrarea și dup ă ieșirea
din intersec ție.
Atunci c ând se afl ă într-una din cele șase curbe existente pe hart ă, participan ții la trafic au tendin ța
de a p ăstra banda, vir ând spre st ânga sau spre dreapta în patch -ul de in tersectare al benzilor cu
acela și num ăr ale arterelor perpendiculare care se întâlnesc.

Figura 19 – Comportamentul în curb ă
Interac țiunile dintre agen ții ma șină sunt similare celor din realitate. Atunci c ând un agent
automobil întalne ște în deplasarea sa un alt agent de acela și tip cu o vitez ă mai mic ă, primul agent
își va mic șora viteza pentru a evita o coliziune.
Dispeceratele echipajelor de inter,'entie sunt agenti care, in functie conjunctura, trimit agenti
echipaje de interventie, pentru solution area situatiei de urgenta. Datorita comunicarii intre agenti,
fiecare dispecerat cunoaste tipul s i coordonatele situatiei de urgenta. F iecare institutie decide
trimiterea a 1 -3 echipaje din tipul agentului echipaj de iterventie specific.

38 | P a g e

Figura 20 – Traseul echipajului de poliție
Cunoscând coordonatele evenimentului, dispeceratul poate calcula în prealabil traseul cel
mai scurt și cel mai rapid pe care echipajele de intervenție trebuie să le urmeze pentru a ajunge la
coordonatele situației de urgență.

Figura 21 – Semnele utilizate pentru fiecare agent ce are legătură cu dispecerul
Situațiile de urgență sunt agenți care apar aleator în oras. Fiecare situație de urgență poate
aparține uneia din cele patru categorii modelate : incendiu, furt, accident rut ier și boli. Fiecare
categorie poate avea două grade de magnitudine, diferențiate prin mărimea si mbolului folosit
pentru a o recunoaște – figura 22.

Figura 22 – Tipuri de situații de urgență

39 | P a g e
Gradele de magnitudine sunt atribuite în funcție de:
Investiga rea cauzelor accidentului ;
Necesitatea îngijirii rănilor;
Minimizarea riscului de explozie;
Observarea situației de la înălțime facilitează îndeplinirea sarcinilor celorlalte echipaje.
Echipajele de interven ție sunt agen ți inteligen ți speciali, care sunt crați nurn ai în cazul
semnal ării unei situa ții de urgen ță și dup ă ce agen ții dispecerat au decis num ărul lor necesar.
Pentru simplificarea modelului, s-a considerat c ă fiecare sector are o singu ră strad ă de acces spre
interiorul cartierului, principiul de găsire a traseului o ptim func ționând și la o fragmentare mai
mare a h ărții.
Spre deosebire de agen ții automobil, agen ții echipaje de urgen ță nu au un comportament
care urm ărește ordinea în trafic. Aceste tipuri de agen ți au rolul de a se deplasa într-o durat ă
minim ă de timp la co ordonatele situa ției de urgen ță. Pentru a realiza ace st obiectiv, o ambulan ță,
o mașina de poli ție sau o mașină de pompieri co munică intersec ției importan ța obiectivului . Atunci
când echipajul intr ă într—o intersec ție, schimb ă modul de func ționare al acesteia. To ți agen ții
semafor își schimb ă culoarea în roșu, Cu excep ția agentului de pe band ă de mers pe care se afl ă
echipajul de interven ție. Astfel, de la intrarea p ână la ieșirea vehiculului din intersec ție, ceilal ți
participan ți la trafic sunt op riți. Ajuns la coordonatele punctului de acces în sector, echipajul de
urgen ță este preluat de agentul responsabil pentru situa ții de urgen ță de la nivel mezoscopic.

Figura 23 – Funcționarea unei intersecții în s ituații de urgență

40 | P a g e
Circulând pe artere principale ale orașului modelat, echipajele de int ervenție participă actv
la traffic . Prin urmare a fost implementată inter acțiunea dinte echipajele de urgență și agenții
autovehicul. Atunci când un echipaj de intervenție întâlnește un vehi cul în deplasarea sa, n u se
aplică regula de interacțiune între doi participanți obișnuiți la trafic , ci agentul mașină schimbă
banda pentu a face loc ambulaței/mașinii de poliție/mașinii de pompi eri.
O excepție de la acest tip de comportament o reprezint ă elic opterul. Deoarece acesta nu
necesită un st rat carosabil pentru deplasare, acest echipaj nu ține cont de semafoare și interacțiunea
cu al ți agenți din trafic. La declanș area urgen ței, agentul elicopter se deplasează de -a lungul unei
drepte spre coordo natele incidentului, fiin d preluat de dispe ceratul resp onsabil pentru situații de
urgen ță atunci c ând ajun ge deasupra locației.
4.3 Rezultate obținute și concluzii
Pentru a testa mediul creat am simulat un scenariu de tip car antină. C arantina reprezint ă
izola rea preventive a unei personae sau a unui grup de personae care a intrat în contact cu un
bolnav co ntagios sau care vine dint r-o regiune afectată de o epide mie.
Pentru tratarea acestei probleme dispeceratul echipajelor de urgen țe trimite un număr de
mașin i care vizitează în funcție de magnitudinea situației de urgentă. În cazul unui incident de
magnitu dine medie sun t trimise cinci echipaje de intervenție , dintre care două sunt ambulanțe, un
echipaj de pompieri, un echipaj de poliție și un elicopter . Dacă s e înregistrează totuși un incident
major, dispeceratul decide trimiterea unui număr total de șapte echipaje :
Trei ambulate ;
Două mașini de pompieri;
Un elicopter ;
Un echipaj de poliție .

41 | P a g e

Figura 24 – Răspun sul dispecer atului
Figura 24 prezintă o situație ce implică un echipaj de poliție – cel albastru, un echipaj de
pompieri – cu roșu, un elicopter – dreap ta sus cu alb, ambulață – centru jos cu alb.
În cazul unei situații de urgență de tip carnatin ă, dispecerul utilizează:
Agenții de percepție: senzorii olfactive pentru captarea em isiilor de compuși volatile ale
bacteriilor . Ace ști senzori sunt implemen tați la nivel de clădire, rezultatele măsurătorilor
efectuate în fiecare clădire fiind preluate de dispe ceratul pentru urgențe la ni vel de cluster.
După ce datele au fost prelucrate la nivel de cluster, ele sunt trimise di speceratului
responsabil pentru situațiile de urgență la nivel macroscopic.
Agenții de control: sunt agenți inteligenți cu in ferență bazată pe logic a ce analizeaz ă
informațiile primite de la agenții de percep ție, iar în urma analizei iau o decizie. Un
exemplu de regulă poate fi:

42 | P a g e
Unde inregistrare_s reprezintă infirmațiile primite de la agentul de perc epție , prag și
prag_limita sunt valori minime ale numărului de bacter ii necesare declarării situației de
urgență, iar procedura_ c_mediu și procedura_c_mare sunt deciziile luate de agenții de
contr ol.
Agenții de acționare: sunt reprezentați de echipa jele de intervenție care trebuie să ajungă
la coordonatele situa ției de urgență și semafoarele care facilitează deplasarea echipajelor.

43 | P a g e
5. Concluzii
Scopul temei a fost de rea liza un scenariu al situațiilor de urgență cauzate o situație de tip
carantină și alte evenimente, influența lor asupra sistemului ca un într eg, și modul în care modelul
realizat poate f i folosit pentru a înțelege sistemele de intervenție.
Pentru a modela acest scenariu am apelat la agenți și sisteme multi -agent. Sistemele
multiagent (MAS) au apărut ca o nouă metodologie de abordare a problemelor de organizare la
scară largă a sistemelor software. Această metodologie oferă un model conceptua l care ajută la
menținerea constrângerilor; sarcinile convenționale de inginerie software fiind imposibil de
realizat. În ultimii ani, MAS au fost folosite în diferite domenii din informatică și inginerie și au
devenit un instrument versatil care se adrese ază nevoilor ingineriei software. Acestea extind, de
asemenea, spectrul de cerce tare în informatică și au atras din ce în ce mai mult atenția către o gamă
largă de domenii, tre când de la studiul teoretic la practică.
Un agent este o entitate software care caută în mod activ modalități de ași finaliza sarcinile.
Agenții inteligenți au capacitatea de a dobândi cunoștințe prin intermediul proceselor de
soluționare a problemelor. S tudiul comportării sociale a agenților în știința cognitivă reprezintă o
parte i mportantă din domeniul agenților inteligenți. Agenții software se concentreze pe interacțiuni
și colaborări pentru a -și atinge obiectivele într -un context care se schimbă într -o manieră de obicei
neprevăzută.
Mediul de lucru utilizat pentru a crea și modela scenariul situației de tip carantină este
NetLogo.
Pe viitor aplic ația poate fi extinsă incluzănd și evenimente de tip alunecare de teren,
inunda ție, accident rutier, furt.

44 | P a g e
Bibliografie
[1] note de curs: Modelarea și analiza sistemelor multi -agent , Prof. Dr. Ing. Florin Leon
[2] note de cur s: Sisteme multi agent, dr. Gabriel a CZIBULA
[3] O. Bica, E. Tîrziu, Utilizarea sitemelor multi -agent într -o infrastructură cloud pentru
dezvoltarea sistemelor de gestionare a învăță rii, ICI București
[4] https://en.wikipedia.org/wiki/Multi -agent_system
[5] https://ccl.northwestern.edu/netlogo/docs/ – user manual NetLogo
[6] http://ccl.north western.edu/netlogo -ccl.shtml
[7] http://edutechwiki.unige.ch/en/NetLogo

45 | P a g e
Anexe

46 | P a g e

47 | P a g e