Sequenze di comunicazione degli agenti

Come detto precedentemente, la comunicazione degli agenti permette l’esecuzione di alcuni piani, che vanno a costituire l’effettivo funzionamento del sistema.

Prima andare a spiegare nel dettaglio quali messaggi gli agenti si scambiano, è necessario fare una premessa: di seguito saranno presenti quattro diagrammi di sequenza, ognuno dei quali avrà lo scopo di mettere in evidenza solo i messaggi che ogni agente manda all’esterno. Questo è stato fatto per una questione di semplicità di tali diagrammi e anche perché il comportamento interno di ogni agente è già stato descritto in precedenza.

All’interno dei diagrammi di sequenza proposti si metteno in evidenza anche le comunicazioni con i Service e con Edge, andando a fornire un certo grado di completezza anche sotto questo punto di vista.

I diagrammi di seguito saranno divisi in base a delle fasi che verranno descritte per ogni capitolo, sempre per mantenere una certa semplicità nella comprensione.

Fase di inizializzazione

Rientrano in questa fase i comportamenti dei due agenti che si dedicano a recuperare periodicamente dati utili per l’intero sistema, ovvero setupAgent e discoverComponentsAgent.
Nonostante il loro comportamento sia ripetuto a intervalli regolari di tempo, verrà mostrato un’unica iterazione.

Il primo diagramma di sequenza mostra i messaggi che vengono scambiati con il fine di condividere le configurazioni con tutti gli agenti che ne prevedono l’utilizzo.
Il flusso viene iniziato da setupAgent, il quale manda una richiesta di autenticazione verso l’Auth Service; questo viene fatto al fine di ottenere un token che permetta al sistema multi-agente di essere riconosciuto dai Service.
Una volta ottenuto il token, setupAgent invia un’altra richiesta HTTP, ma in questo caso indirizzata a Settings Service; il servizio, se la richiesta va a buon fine, restituisce l’ultima configurazione creata dall’utente ancora valida.
Una volta che il setupAgent crea le configurazioni riconosciute dal sistema da quelle ricevute dal Settings Service, manda un messaggio che viene ricevuto da tutti gli agenti interessati. Questo messaggio prende il nome di setupSettings e viene recapitato a samplingCoordinatorAgent e timeBasedActuatorAgent.
A parte l’effettiva autenticazione, il recupero e la condivisione delle configurazioni viene ripetuta regolarmente, al fine di aggiornarle nel caso in cui vengano modificate e di propagare tale cambiamento.

Il secondo diagramma di sequenza riportato per la fase di inizializzazione riguarda il recupero e la condivisione dei componenti fisici nella serra e dei Thing Descriptor.
In questo caso, l’agente che si occupa di iniziare questo flusso è il discoverComponentsAgent; per prima cosa viene mandato un messaggio a Edge, di modo da poter ottenere il Thing Descriptor. Tramite questo, discoverComponentsAgent è in grado di estrarre anche i componenti fisici nella serra con i quali è possibile comunicare, che sia tramite azioni o accedendo a delle proprietà.
A questo punto vengono creati due messaggi:

• setupComponents: condivide la lista dei componenti a sampleBasedActuatorAgent, timeBasedActuatorAgent e samplingCoordinatorAgent.
• setupTds: gli agenti ai quali vengono propagati i Thing Descriptor sono sampleBasedActuatorAgent, timeBasedActuatorAgent e samplingAgent.

Nella sua interezza, la sequenza di messaggi appena descritta viene ripetura regolarmente, al fine di riuscire ad intercettare eventuali cambiamenti. Questo permette di riuscire a modificare dinamicamente la lista di componenti e Thing Descriptor senza dover mettere mano al codice, inserendo nuovi attuatori e sensori in modo molto agile.

Fase di campionamento

La fase di campionamento riguarda il comportamento centrale del sistema e coinvolge diversi agenti. Il campionamento viene svolto periodicamente, a intervalli di tempo molto brevi, di modo che il sistema possa monitorare dati aggiornati e compiere azioni nel caso sia ritenuto necessario.

Il flusso di esecuzione in questo caso viene iniziato dal samplingCoordinatorAgent: quest’ultimo richiede ad un samplingAgent di occuparsi dell’effettivo recupero dei dati. Al fine di ottenere i nuovi dati, samplingAgent manda una richiesta a Edge, che può essere effettuata grazie all’uso dei Thing Descriptor. Edge restituisce quindi i dati, e samplingAgent li consegna al samplingCoordinatorAgent per mezzo del messaggio chiamato checkSamples.
Una volta ottenuta la media dei nuovi dati campionati, viene verificato se la differenza tra gli ultimi dati e quelli appena recuperati supera un certo delta: nel caso in cui sia così, allora è previsto che tali dati vengano resi persistenti. Per fare in modo che questo avvengo, samplingCoordinatorAgent manda un messaggio chiamato uploadPersistence a persistenceAgent. Questo agente si occupa di mandare una HTTP Post a Persistence Service, effettuando così la richiesta che tali dati campionati vengano salvati sul database.
Un altro flusso di messaggi opzionale è quello che viene eseguito nel caso in cui la media dei dati campionati non rientri tra il valore minimo e massimo delle configurazioni attuali. Se ciò avviene, allora è richiesto che uno o più attuatori vengano azionati perché tali dati possano poi tornare nell’intervallo di valori previsto. Per fare ciò samplingCoordinatorAgent, manda il messaggio actuate a sampleBasedActuatorAgent, il quale, per mezzo dei Thing Descriptor, potrà comunicare con Edge per fare in modo che dei componenti fisici svolgano determinate azioni.

Fase di attuazione a tempo

Nella fase precedente è stato identificato in quale caso è previsto che uno o più attuatori performino un’azione. Questo si basava però sui dati campionati.
Oltre ad un’attuazione basata sui dati campionati, esiste anche un’attuazione basata sul tempo. Esistono infatti delle configurazioni che prevedono un certo comportamento degli attuatori in base alla fascia oraria.
Tale esigenza non viene gestita nella fase precedente, ma timeBasedActuatorAgent ha il compito di farlo.

Come si vede nel diagramma di sequenza proposto sotto, timeBasedActuatorAgent invia un messaggio a sé stesso, ovvero checkSettings. Questo va a controllare in base alle configurazioni quali azioni deve svolgere ogni attuatore, e utilizzando le informazioni nel Thing Descriptor, viene mandato a Edge l’azione che deve essere eseguita.
Questo controllo appena descritto avviene periodicamente, di modo da intercettare velocemente il momento effettivo in cui un certo attuatore deve essere acceso o spento.