Status Definition

In questa parte del modello lo scopo è quello di elaborare in quale stato si troverà il sistema, in conformità a principi logici che dipendono dallo stato attuale, dallo stato richiesto e da alcune variabili.

109

Come già è stato detto nel capitolo 2, si è scelto di definire 6 differenti stati, che rappresentano differenti condizioni della moto, ognuno dei quali è rappresentato nel modello da un numero:

Tabella 4.1. Rappresentazione numerica degli Stati

CALIBRATION 0 MANUAL 1 SEMI-AUTO 2 AUTOMATIC 3 IDLE 10 ALARM 11 Figure 4.3 RideIT_RT_model/STATUS_DEFINITION

110

La determinazione dello stato è elaborata in Simulink nel modo seguente: viene letta la cella di memoria “STATUS”, che rappresenta lo stato in cui la moto si trova nello step di calcolo attuale; si richiamano dagli input lo stato richiesto, il vettore

“BIKE_Feedback” che mette a disposizione la marcia inserita, la velocità di rotazione del motore e i segnali di switch di freno e frizione, inoltre viene letto il numero di riproduzioni del profilo di guida in stato automatico e il set point di marcia, elementi del vettore "BIKE_fdbk". In ultimo vengono estratti la velocità del rullo e il segnale dato dal pulsante di emergenza dal vettore “Utilities”.

Per acconsentire, o meno, lo switch fra i vari stati si tiene in considerazione che lo stato attuale sia diverso da quello di allarme. Il modello esegue poi determinati sotto blocchi in conformità alle differenti condizioni. Esaminiamoli nel dettaglio.

ALARM: questo sottosistema è contraddistinto dalla presenza di un “trigger”, perciò fa sì che l’istruzione contenuta dentro al blocco sia eseguita solo al primo step di calcolo in cui risulta essere verificata la condizione di attivazione, che in questo caso è relativa al segnale booleano “Fungo _emergency”, ossia la richiesta di allarme da parte dall’utente. Quando questo blocco viene eseguito, il sistema impone lo stato come “11”, cioè stato di allarme.

ALARM_to_IDLE: è anch’esso un sottosistema contraddistinto dalla presenza di un “trigger” e l’istruzione contenuta dentro al blocco viene eseguita solo quando

risultano essere verificate contemporaneamente le condizioni poste in ingresso al blocco operatore AND. Infatti se, c’è uno stato di allarme, il pulsante di emergenza è rilasciato, la velocità del rullo trasformata in Km/h è inferiore a 5 e nel motoveicolo c’è la frizione tirata e il freno rilasciato, allora con tali requisiti è possibile uscire dallo stato di allarme, quindi, al verificarsi di tale situazione è consentito il passaggio allo stato IDLE.

SWITCHSTATUS: questa parte di modello è attiva quando lo stato non è di allarme e lo stato richiesto è diverso dallo stato attuale.

Un ciclo “if” determina lo stato in cui ci si può effettivamente portare e come verrà spiegato di seguito, ci sono molteplici le condizioni che devono essere rispettate nella transizione tra stati.

111

Figure 4.4 RideIT_RT_model/STATUS_DEFINITION /SWITCHSTATUS

 Se lo stato attuale è Idle (u1=10), e lo stato richiesto è uno tra Calibration (u2=0), o Manual (u2=1), o Semi-Auto (u2=2), e se il rullo è in movimento (u7 > 5Km/h), allora si continua a lasciare il sistema in Idle, in quanto il passaggio di stato è consentito solo avendo il rullo fermo. Il valore della cella

"STATUS_REQ" diviene “10”, in tale modo non si acconsentono ulteriori switch tra stati, a meno che il sistema non venga riportato in condizioni sicure e venga rinnovata la richiesta da parte dell’utente.

112

Figure 4.5 RideIT_RT_model/STATUS_DEFINITION/SWITCHSTATUS 10 0/1/2 Roll_cond

 Se lo stato attuale è Idle (u1=10), o Calibration (u1=0) e lo stato richiesto è automatico (u2=3), la richiesta non può essere soddisfatta, pertanto non vi è alcun cambiamento di stato.

Figure 4.6 RideIT_RT_model/STATUS_DEFINITION/SWITCHSTATUS 103/ 03 NOT_allowed

 Se lo stato attuale è automatico (u1=3), e lo stato richiesto è uno tra Calibration (u2=0), o Manual (u2=1), o Semi-Auto (u2=2), la richiesta non può essere soddisfatta e s’impone lo stato di Idle non permettendo ulteriori cambiamenti di stato.

Figure 4.7 RideIT_RT_model/STATUS_DEFINITION/SWITCHSTATUS 3 0/1/2 NOT_allowed

113

 Se lo stato attuale è manuale (u1=1), o semiautomatico (u1=2), oppure è idle (u1=10) e lo stato richiesto è Calibration (u2=0) ma la moto non è spenta, la richiesta non può essere soddisfatta perciò si mantiene il sistema allo stato attuale.

Figure 4.8 RideIT_RT_model/STATUS_DEFINITION/SWITCHSTATUS 1/2/10  0 RPM_cond

 Se nel passaggio dallo stato manuale (u1=1) ad automatico (u2=3), non viene rispettata la condizione di coincidenza tra la marcia letta dalla centralina e la prima richiesta di marcia del profilo di guida, il sistema permane in STATUS “1”. Stessa condizione vale se si vuole passare dallo stato semiautomatico (u1=2) ad automatico. In quel caso il sistema permane in STATUS “2”.

Figure 4.9 RideIT_RT_model/STATUS_DEFINITION/SWITCHSTATUS 1/2 3 GEAR_cond

 La transizione da manuale ad automatico, o da semi-auto ad automatico non è consentita neppure se l'operatore non ha stabilito il numero di ripetizioni del profilo da riprodurre (u6=0).

114

Figure 4.10 RideIT_RT_model/STATUS_DEFINITION/SWITCHSTATUS 1/23 Cycles_cond

 Nel caso in cui tutte le condizioni del blocco IF che regolano lo switch tra stati siano soddisfatte, le richieste possono essere acconsentite. Per evitare che si richiedano stati non previsti si satura l'input di stato richiesto tra 0 e 3.

Figure 4.11 RideIT_RT_model/STATUS_DEFINITION/SWITCHSTATUS/Switching_STATUS

La logica di sistema appena descritta per il blocco STATUS_DEFINITION, che rappresenta le diverse modalità operative del sistema stesso, è rappresentabile anche attraverso il diagramma di flusso riportato in figura 4.12. Tale diagramma fa una panoramica di ciò che è stato implementato all’interno del blocco

STATUS_DEFINITION e che si basa su un modello di macchina a stati. Come si

può notare dalla figura 4.12, in primo luogo sono riportati gli stati e i passaggi in ciascuno di essi. Per quanto riguarda le transizioni di stato, vengono indicate solo quelle attive nonché consentite, riportando anche in dettaglio gli eventi e le

condizioni necessarie affinché queste possano essere eseguite. Grazie al diagramma dunque, è più immediato visualizzare il comportamento del sistema durante una simulazione e aiuta a rendersi conto di quel che sta accadendo nel sistema se, ad

115

esempio, non viene soddisfatta una qualche particolare condizione e avviene magari un passaggio forzato di stato, oppure se viene effettuata una richiesta di cambiamento di stato che non è coerente con la logica implementata.

Figure 4.12 State Machine