Struttura agenti

Gli agenti sviluppati tramite l’utilizzo del framework JaCaMo prevedono una certa struttura che è importante specificare al fine di poter descrivere in modo chiaro le scelte che sono state prese.

Le principali caratteristiche sono:

• initial goal
  Un agente può o meno avere un obiettivo iniziale. Nel caso in cui sia presente, tale agente darà inizio a un certo flusso di esecuzione appena la sua inizializzazione sarà completata.
• initial belief
  Le credenze iniziali entrano a far parte della conoscienza dell’agente e verranno salvata nella Belief Base (BB). Durante l’esecuzione è possibile consultare la BB al fine di poter porre delle condizioni sull’esecuzione di alcuni flussi.
• plan
  Un piano non è altro che un flusso di esecuzione che può essere azionato da un evento interno, ovvero a causa dell’agente stesso, o esterno, nel caso in cui sia causato dalla percezione dell’agente all’ambiente in cui si trova.

Questi tre elementi sopra elencati costituiscono il modo per permettere agli agenti all’interno del sistema di interagire tra loro, comunicando tramite messaggi che andranno a scatenare l’esecuzione di piani. Un agente può sempre accedere alle operazioni degli Artefatti che gli appartengono, creando quindi la possibilità di eseguire comportamente complessi.

Agenti nel MAS

Nel sistema multi-agente sono previsti un totale di 7 diversi tipi di agenti. Prima di andare a spiegare le comunicazioni che intercorrono tra agenti, è importante spiegare il ruolo di ogni agente all’interno del sistema.

setupAgent

Il setupAgent ha lo scopo di occuparsi dell’autenticazione con i Services, di reperire le configurazioni attualmente valide periodicamente e di condividerle con gli altri agenti.

Nel MAS esiste un unico setupAgent, in quanto un solo agente è in grado di svolgere questo compito in modo efficiente.

Al fine di adempiere al suo scopo, il setupAgent utilizza operazioni presenti nell’AuthenticationArtifact, nel SettingsArtifact e nel CommonArtifact.

Il comportamento dell’agente è rappresentato nel diagramma a stati seguente.

Questo agente ha un iniatial goal, che viene utilizzato per iniziare il suo flusso di esecuzione nel momento in cui l’agente è stato creato.
L’initial goal citato prende il nome di authentication, e permette di andare a chiamare l’operazione retrieveAuthenticationData esposta dall’AuthenticationArtifact al fine di autenticarsi con l’Auth Service.
Una volta ottenuto il token, il relativo plan viene azionato, il quale va a richiamara l’operazione getSettings presente nel SettingsArtifact: questa piano ha l’obiettivo di andare a recuperare le configurazioni valide e di iniziare un ciclo di richieste, al fine di aggiornare le configurazioni nel caso in cui avvengano dei cambiamenti. Per iniaziare il ciclo appena citato, viene utilizzato il piano wait, il quale richiama updateSettings ogni 20 secondi. Il piano updateSettings recupera il token presente nella Belief Base dell’agente, chiama nuovamente getSettings per recuperare le configurazioni e termina ripetendo la chiamata a wait, creando quindi il ciclo.

Infine, ogni volta che le configurazioni vengono recuperate, viene scatenato un altro plan, ovvero settings, che chiama l’operazione shareSettings presente nel CommonArtifact, la quale ha il compito di condividere con gli altri agenti le configurazioni trovate.

discoverComponentsAgent

Il discoverComponentsAgent viene utilizzato per scoprire se sulla stessa rete LAN del sistema multi-agente sono presenti degli Edge con i quali comunicare.

Per fare questo, dopo la sua creazione l’agente inizia a cercare di adempiere al suo scopo, stabilito tramite l’initial goal discover. Questo porta alla chiamata dell’operazione discoverComponents, la quale si trova nel DiscoverComponentsArtifact. Questa operazione itera su tutti gli indirizzi della rete locale in cui si trova il sistema, ricercando componenti che siano in grado di restituire un Thing Descriptor valido.
Come detto in precedenza, un requisito del sistema multi-agente è quello di essere in grado di aggiungere dinamicamente nuovi Edge connessi; per questa ragione, una volta terminata l’operazione di ricerca, tramite l’uso del piano wait, si attendono 20 secondi, e poi il piano discover viene nuovamente chiamato. Questo crea un ciclo che permette al sistema di aggiornarsi nel caso in cui sia necessario.

Quando un Edge viene identificato tramite la ricerca su tutti gli indirizzi locali, allora il Thing Descriptor restituito viene analizzato: tramite il TD infatti è possibile estrarre tutti i componenti fisici, che siano attuatori o sensori, con i quali il sistema multi-agente può comunicare, e quali sono le azioni e le proprietà che possono essere richiamate.
Una volta ottenute tutte le informazioni necessarie, utilizzando le operazioni nel CommonArtifact, queste verranno condivise a tutti gli agenti interessati; la chiamata delle operazione nel CommonArtifact viene fatta utilizzando il piano components e il piano thingDescriptors del discoverComponentsAgent.

Il comportamento appena descritto è rapprensentato nel seguente diagramma a stati.

samplingCoordinatorAgent

Il samplingCoordinatorAgent gestisce in che modo compiere il campionamento dei dati e prende decisioni su come reagire ai dati appena ottenuti.

Nel MAS sono stati creati più samplingCoordinatorAgent, ognuno dei quali si occupa di coordinare il campionamento di una categoria diversa di sensori.
Per questo, quando vengono creati, viene anche aggiunto un initial belief, che andrà a costituire la categoria di cui tale agente è responsabile.
Per esempio, nel sistema implementato sono presenti due agenti di questo tipo:

• uno ha come belief temperature, quindi si dedicherà alla coordinazione del campionamento di tutti i sensori che trattano la temperatura;
• il belief dell’altro agente è airHumidity, quindi è dedicato alla gestione del campionamento riguardante l’umidità dell’aria.

Il seguente diagramma a stati rappresenta il comportamento del samplingCoordinatorAgent.

L’initial goal di un samplingCoordinatorAgent è sample, il quale si occupa di recuperare la categoria a cui è assegnato dalla BB e chiama l’operazione sampleOperation presente nel SamplingCoordinatorArtifact. In questo modo l’agente sta richiedendo di campionare i dati di un certo tipo di sensori, senza sapere quale agente adempierà effettivamente alla sua richiesta.
Oltre a ciò, viene anche chiamato wait, di modo da iniziare un ciclo che ogni 5 secondi ripeterà il piano sample.

Come detto in precedenza, il samplingCoordinatorAgent è l’unico ad avere informazioni a sufficienza per riuscire a stabilire come comportarsi alla ricezione dei dati campionati. Quando il campionamento è completato, viene scatenato il piano checkSamples, il quale, se la categoria dei dati ricevuti è quella presente nella sua BB, chiama l’operazione updateOperation presente nel SamplingCoordinatorArtifact.
L’operazione va a stabilire se rendere i dati persistenti e se è opportuno azionare degli attuatori. Questo comportamento è stato descritto nel dettaglio nella sezione precedente relativa al SamplingCoordinatorArtifact.

samplingAgent

Il samplingAgent ha l’unico scopo di comunicare con un determinata lista di componenti fisici collegati a Edge.
Per questa ragione, non ha un initial goal, ma rimane semplicemente in attesa che il suo piano sampling venga azionato. Questo piano utilizza l’operazione getSamples esposta dal SamplingArtifact, la quale effettua l’effettiva operazione di campionamento.

All’interno del MAS è presente un unico samplingAgent al momento, poiché è stato ritenuto sufficiente in fase di verifica del funzionamento del sistema. Aggiungere nuovi agenti di questo tipo è comunque una cosa molto agevole, l’unica cosa necessaria sarebbe stabilire quali categorie dovrebbe prendere in carico un agente, al fine di evitare che più agenti richiedano i dati agli stessi componenti.

Il seguente è il diagramma a stati che descrive il comportamento del samplingAgent.

persistenceAgent

Il persistenceAgent viene utilizzato per rendere persitenti i dati e deve comunicare con il Persistence Service per tale scopo.

Questo agente ha un comportamento molto simile al samplingAgent appena descritto: infatti anche lui non ha un initial goal, semplicemente attende passivamente che il suo piano venga azionato, in questo caso uploadPersistence.
Quando il suo unico piano viene azionato, l’agente recupera dalla sua BB il token necessario per la comuncazione con i servizi e chiama poi l’operazione uploadPersistence presente nel PersistenceArtifact. In questo modo invia effettivamente i dati al Persistence Service, rendendoli permanenti.

Anche in questo caso, come nel precedente, esiste nel sistema un unico persistenceAgent, ma rimane molto semplice aggiungerne altri nel caso in cui il lavoro sia troppo per essere gestito da un solo agente.

sampleBasedActuatorAgent

Come i due agenti precedenti, anche il sampleBasedActuatorAgent non ha un initial goal e rimane in attesa che il suo piano venga avviato.
Lo scopo di questo agente è di comunicare con gli attuatori nel caso in cui i dati campionati non rientrino tra il minimo e il massimo specificati neller configurazioni. La comunicazione è resa possibile dai Thing Descriptor e avviene per mezzo di Edge.

Il piano presente in questo agente si chiama actuate e la sua esecuzione ha una guardia che va a permettere l’adempimento del piano solo nel caso in cui la categoria nella sua BB sia coerente con quella del messaggio ricevuto.
Nel caso in cui lo sia, allora l’agente chiama l’operazione actuate presente nel SampleBasedActuatorArtifact, la quale stabilisce che tipo di azione è necessaria per correggere lo stato registrato dai sensori e invia tali azioni a Edge.

Nel MAS sono presenti 2 sampleBasedActuatorAgent, uno che è responsabile della temperatura e uno dell’umidità dell’aria.
Nel caso in cui si aggiungano altri tipi di sensori su Edge allora sarebbe necessario aggiungere al MAS un altro sampleBasedActuatorAgent dedicato a quella categoria di sensore e nel SampleBasedActuatorArtifact sarebbe necessario specificare il comportamento in base al valore attuale registrato dai sensori.

timeBasedActuatorAgent

L’ultimo tipo di agente prensente nel sistema è timeBasedActuatorAgent. Come detto precedentemente, esistono delle configurazioni che modificano lo stato degli attuatori basandosi su intervalli di tempo; questo agente si occupa di controllare l’ora attuale e verificare che tipo di azione l’attuatore deve svolgere basandosi sulle configurazioni.
Per fare ciò, il timeBasedActuatorAgent ha un initial goal, denominato checkSettings: l’agente recupera dalla sua BB la categoria a cui è assegnato e chiama l’operazione checkSettings prensente nel TimeBasedActuatorArtifact. Questa operazione recupera le configurazioni di tale categoria e verifica che tipo di operazione deve svolgere l’attuatore.
Inoltre il piano checkSettings va anche a chiamare wait, il cui compito è quello di attendere 10 secondi prima di chiamare nuovamente checkSettings. Questo ciclo è necessario, in quando serve per intercettare il momento in cui l’azione dell’attuatore deve effettivamente cambiare. Inoltre, nel caso in cui le configurazioni vengano modificate dall’utente, il sistema se ne accorge. Quindi se un eventuale cambio di stato dell’attuatore è richiesto dall’utente, nel caso peggiore viene performato dopo 10 secondi.

Nel MAS è presente un unico timeBasedActuatorAgent, il quale si dedica all’accensione e allo spegnimento delle luci nella serra: infatti il suo initial belief è light. La ragione per la quale è presente un solo agente di questo tipo è data dal fatto che nell’intero sistema è stato previsto solo questo tipo di attuatore a tempo, ma risulta molto semplice implementarne di nuovi.

Il comportamento dell’agente appena descritto è rappresentabile in un diagramma a stati come segue.