Università degli Studi di Firenze

Facoltà di Ingegneria

Dipartimento di Sistemi e Informatica

Tesi di Laurea in Ingegneria Informatica

Specifica e simulazione di sistemi reattivi con Statemate

Candidato: Vincenzo Chiummariello

Relatori: Prof. Alessandro Fantechi

Prof. Enrico Vicario

Anno Accademico 2001-2002

Alla mia gatta Fuffy

I

Indice

Introduzione al lavoro ............................................................................ III 1. Cenni ai sistemi real-time ................................................................... 1

1.1 Introduzione ..........................................................................................................1 1.2 Processi e scadenze .............................................................................................2 1.3 Schedulazione dei processi ..................................................................................4 1.4 Classi di algoritmi e analisi di schedulabilità .........................................................6 1.5 Limiti degli attuali sistemi operativi real-time.........................................................8

2. Analisi del modello teorico ed applicativo...................................... 10

2.1 Il modello teorico .................................................................................................10 2.2 Il modello applicativo...........................................................................................12

2.2.1 I processi specificati .....................................................................................12 2.2.1.1 Rappresentazione convenzionale dei processi .....................................14

2.2.2 Il Kernel Simulator........................................................................................16 2.2.3 Analisi di schedulabilità ................................................................................18

2.2.3.1 Implementazione nel modello dell’analisi di schedulabilità ...................20 2.2.4 Gestione delle risorse ..................................................................................23

2.2.4.1 Il Protocollo di Priority Ceiling................................................................26 2.2.4.2 Analisi di schedulabilità per task pcg ‘dipendenti’ .................................27

3. Introduzione allo strumento di specifica formale I-Logix Statemate MAGNUM........................................................................... 30

3.1 Premessa ............................................................................................................30 3.2 Il Tool-Set di Statemate.......................................................................................31 3.3 La modellazione di sistemi reattivi ......................................................................34

3.3.1 La natura dei sistemi reattivi.........................................................................34 3.3.2 Le tre ‘viste’ nella modellazione di un sistema reattivo ................................35

3.4 I linguaggi di modellazione di Statemate.............................................................37 3.4.1 Activity-Charts ..............................................................................................38 3.4.2 StateCharts ..................................................................................................39 3.4.3 Module-Charts..............................................................................................42 3.4.4 Relazioni tra i tre linguaggi ...........................................................................43 3.4.5 Gestione di sistemi su larga scala................................................................44

4. Confronto tra specifica in SDL e specifica in Statemate ............... 45

4.1 Studio di fattibilità del porting ..............................................................................45 4.2 Specifica Statemate del modello SDL.................................................................48

4.2.1 Processi con più istanze concorrenti............................................................48 4.2.2 IPC, code e PID ...........................................................................................50 4.2.3 Temporizzazione in Statemate.....................................................................55 4.2.4 Versioni realizzate per la gestione del tempo nel modello ...........................58 4.2.5 Semantica delle transizioni ..........................................................................78

4.2.5.1 Stati ritardatori .......................................................................................79 4.2.5.2 Subroutines ...........................................................................................79 4.2.5.3 Variabili contestuali ...............................................................................81

II

5. Analisi del sistema specificato in Statemate .................................. 83 5.1 Versione 13 .........................................................................................................83

5.1.1 Activity-Chart SYSTEM_GRMS ...................................................................85 5.1.1.1 Control-Activity PROC_GEN.................................................................85 5.1.1.2 I processi periodici critici garantiti..........................................................88 5.1.1.3 Il processo ACCEPTANCE ...................................................................91 5.1.1.4 StateChart SCHEDULABILITY_TEST ..................................................94 5.1.1.5 Ancora sul processo ACCEPTANCE ....................................................95 5.1.1.6 StateChart GLOBAL_MONITOR...........................................................97

5.2 Versione 14 .......................................................................................................102 5.2.1 Attivazione/disattivazione del processo ACCEPTANCE............................102 5.2.2 Controllo della scadenza del periodo di ACCEPTANCE............................104 5.2.3 Gestione dei processi terminati da parte del GLOBAL_MONITOR............105 5.2.4 Specifica di task firm one-shot e di vincoli di precedenza..........................106 5.2.5 Specifica di task firm periodici (versione 14b) ............................................109 5.2.6 Specifica di task firm sporadici e di U_TOT (versione 14c)........................111

5.3 Versione 15 .......................................................................................................116 5.3.1 Descrizione delle Charts ............................................................................121

5.3.1.1 ACCEPTANCE....................................................................................121 5.3.1.2 GLOBAL_MONITOR...........................................................................124 5.3.1.3 SEMAPHORE .....................................................................................130 5.3.1.4 Processi PCG......................................................................................136

5.3.2 Procedural StateCharts..............................................................................142 6. Analisi statica e simulazione del modello..................................... 149

6.1 Analisi statica in Statemate ...............................................................................149 6.2 Simulation Tool di Statemate ............................................................................154

6.2.1 Le tre fasi della simulazione interattiva ......................................................155 6.2.2 Profile Editor e Simulation Scope...............................................................155

6.2.2.1 Opzioni di esecuzione .........................................................................157 6.2.3 Temporizzazione nella simulazione ...........................................................159

6.2.3.1 Schema di tempo sincrono vs asincrono.............................................161 6.2.4 Go Commands ...........................................................................................163 6.2.5 Analisi dell’esecuzione simulata.................................................................165

6.2.5.1 Graphic Animation Display ..................................................................165 6.2.5.2 Show Commands ................................................................................166 6.2.5.3 Panels .................................................................................................170 6.2.5.4 Micro-Debugger Tool...........................................................................171 6.2.5.5 Waveforms ..........................................................................................175 6.2.5.6 Monitors...............................................................................................176

6.2.6 Alcuni esempi di simulazione interattiva.....................................................178 6.2.6.1 Primo esempio ....................................................................................178 6.2.6.2 Secondo esempio................................................................................186 6.2.6.3 Terzo esempio.....................................................................................189 6.2.6.4 Quarto esempio...................................................................................193 6.2.6.5 Quinto esempio ...................................................................................197

6.3 Conclusioni........................................................................................................202 6.4 Possibili sviluppi futuri .......................................................................................203

Bibliografia ........................................................................................... 204

III

Introduzione al lavoro L’obiettivo che si prefigge la presente tesi è quello di specificare, verificare e simulare il modello applicativo di un semplice sistema operativo real-time utilizzando in maniera adeguata e corretta i diversi linguaggi formali di modellazione presenti nello strumento I-Logix Statemate MAGNUM. Vi è infatti un crescente interesse nel mondo industriale, soprattutto laddove si realizzino applicazioni safety-critical, per gli strumenti commerciali che permettono di realizzare e verificare le specifiche formali dei sistemi in corso di sviluppo, fino ad arrivare alla generazione automatica del codice a partire da tali specifiche. In questo modo il ciclo di sviluppo, pur se a prezzo di un maggior investimento in tecnologie e strumenti sofisticati, permette di produrre software di maggiore qualità. Tra gli strumenti e i formalismi di maggior successo commerciale si trovano il linguaggio standard SDL, con i relativi strumenti di supporto, e il linguaggio delle StateCharts, quest’ultimo supportato appunto da Statemate. In entrambi i casi però, i formalismi proposti difettano di primitive che permettono di ragionare sui sistemi real-time in modo da predirne il comportamento temporale. Si propone quindi, in questa tesi, di affiancare un modello teorico di un sistema in tempo reale con il modello applicativo di un sistema operativo che si occupi di ricondurre entro certe regole di predicibilità temporale i vari processi real-time. In un precedente lavoro di tesi [2], questo approccio era stato seguito con il linguaggio SDL specificando e simulando il modello applicativo di un semplice sistema real-time. La presente tesi propone invece l’equivalente modello sviluppato con le StateCharts supportate da Statemate. Nell’affrontare questo lavoro si è posto subito il problema se costruire un modello ex-novo in Statemate o se seguire quello già definito da Sauro Carsughi, tentando un’operazione di porting dal linguaggio SDL alle StateCharts. Si è optato per la seconda strada: questa scelta ha permesso infatti di sviscerare le intrinseche differenze tra i due formalismi, studiando una forma di ‘regole di trasformazione’ generali dal primo al secondo che conservassero, per quanto possibile, la semantica delle specifiche trasformate, pur non avendo affrontato il problema da un punto di vista prettamente formale. Dobbiamo dire che tale scelta è stata più volte avvertita, nel corso di questo lavoro, come non perfettamente naturale, proprio per le diverse caratteristiche concettuali dei due linguaggi; in particolare, il trattamento del tempo in Statemate ha richiesto una notevole elaborazione e discussione di varie possibili alternative. L’organizzazione del nostro lavoro risulta quindi la seguente: • Nel primo capitolo (“Cenni ai sistemi real-time”) saranno brevemente introdotti i

concetti fondamentali dei sistemi operativi in tempo reale e le questioni più rilevanti nel loro sviluppo; verrà affrontato il problema della schedulazione di applicazioni critiche, denunciando in relazione ad essa la carenza nei sistemi operativi real-time attualmente disponibili in commercio di strumenti che effettuino l’analisi di schedulabilità dei processi real-time stessi.

IV

• Nel secondo capitolo (“Analisi del modello teorico ed applicativo”) si inizierà ad entrare nel cuore del problema riportando innanzitutto le proprietà e le caratteristiche funzionali principali del modello teorico generale dal quale siamo partiti sulla base dei requisiti richiesti; illustreremo quindi il sistema applicativo completo descrivendo in dettaglio le varie strategie utilizzate per definire il modello dei task real-time specificati e il modello del gestore-simulatore dei processi stessi.

• Nel terzo capitolo (“Introduzione allo strumento di specifica formale I-Logix

Statemate MAGNUM”) introdurremo alcuni dei concetti e delle caratteristiche principali del potente e sofisticato strumento di modellazione per complessi sistemi reattivi Statemate, con particolare riferimento alla versione 2.1 e ai linguaggi di specifica formale, grafici e testuali, da noi utilizzati per la realizzazione del sistema applicativo illustrato nel capitolo precedente.

• Nel quarto capitolo (“Confronto tra specifica in SDL e specifica in Statemate”)

affronteremo in dettaglio le differenze tra i due linguaggi, descrivendo tutti i problemi teorici riscontrati e le relative soluzioni pratiche da noi adottate nella stesura delle specifiche del sistema applicativo di riferimento, con particolare riguardo al meccanismo di comunicazione asincrono tra i processi tramite apposite code, alle diverse versioni realizzate per la gestione del tempo nel modello e, più in generale, alla delicata questione della differente temporizzazione nell’esecuzione delle istruzioni in una transizione di stato SDL e in un corrispondente passo Statemate.

• Nel quinto capitolo (“Analisi del sistema specificato in Statemate”), avvalendoci

delle varie Charts componenti il nostro modello, descriveremo dettagliatamente l’intera specifica Statemate del sistema applicativo, con particolare riferimento alle ultime tre versioni (e relative varianti) realizzate; tali versioni si distinguono dalle precedenti per la possibilità di istanziare e simulare, oltre ai classici processi periodici critici garantiti, anche altre tipologie di task real-time con eventuali vincoli di precedenza e su risorse condivise, mutuamente esclusive e preemptable (sezioni critiche) gestite tramite un apposito protocollo di accesso.

• Nel sesto ed ultimo capitolo infine (“Analisi statica e simulazione del modello”),

dopo aver discusso i risultati ottenuti dall’analisi statica del nostro modello, illustreremo le varie facilities, visuali e testuali, offerte dal Simulation Tool di Statemate, con particolare riferimento alla modalità interattiva e alla delicata questione della diversa temporizzazione nell’esecuzione simulata dei processi real-time rispetto a SDL, soprattutto per quanto riguarda l’overhead di sistema. Riporteremo inoltre i risultati sperimentali ottenuti per alcune situazioni di esempio significative appositamente scelte per mostrare le potenzialità espressive e rappresentative dello strumento utilizzato e il corretto funzionamento del modello applicativo realizzato, e concluderemo la nostra trattazione proponendo alcune possibili linee di sviluppo per il modello stesso.

1

1. Cenni ai sistemi real-time

1.1 Introduzione La differenza tra un sistema operativo di tipo tradizionale ed un sistema in tempo reale sta nel fatto che per quest’ultimo i vincoli temporali costituiscono la definizione di comportamento corretto e non caratterizzano soltanto la bontà delle prestazioni del sistema; in altre parole, mentre per un sistema normale i vincoli temporali possono solo descrivere delle richieste sulla ‘velocità’ o ‘prontezza’ di risposta del sistema (che entro certi limiti possono non essere soddisfatte), per un sistema real-time i vincoli temporali definiscono quali comportamenti sono corretti e quali sono equivalenti al verificarsi di condizione di errore. Un tipico caso di sistema real-time può essere rappresentato, ad esempio, da un computer usato nel controllo di un processo industriale: esso deve lavorare (ad es., rispondere ad eventi esterni) secondo una ‘scala di tempi’ determinata dai vincoli temporali dettati dal processo stesso. Nell'espressione ‘tempo reale’ sono dunque sintetizzati due concetti fondamentali [3]1:

• TEMPO: la parola ‘tempo’ indica che la validità dei risultati di un processo di elaborazione non dipende solo dalla correttezza delle singole operazioni ma anche dal tempo entro cui tali risultati sono prodotti.

• REALE: la parola ‘reale’ indica che la risposta del sistema agli eventi esterni

deve avvenire durante l’evolversi dell’evento stesso e quindi il tempo di sistema deve coincidere con quello dell’ambiente in cui il sistema opera.

Un concetto dunque da chiarire è che il termine ‘real-time’ non significa ‘veloce’ sebbene ancora, in certi casi, vi sia l’abitudine di dire che un sistema di controllo si comporta in tempo reale quando è in grado di reagire velocemente alle azioni di disturbo che si presentano. L’aggettivo ‘veloce’ ha un significato relativo che ha poco senso se non è riferito all'ambiente in cui il sistema stesso opera; le caratteristiche real-time di un sistema sono infatti strettamente legate all'ambiente in cui il sistema deve operare e, qualunque sia la velocità del calcolatore, occorre sempre dimostrare che i vincoli temporali di un processo siano garantiti. Mentre infatti lo scopo di una elaborazione veloce è quello di minimizzare il tempo medio di risposta (prestazione media) di un insieme di processi, l’obiettivo di una elaborazione tempo reale è quello di soddisfare i requisiti temporali individuali di ciascun processo. Per quanto piccolo sia il tempo medio di risposta di un insieme di processi che eseguono su un calcolatore veloce, senza l’ausilio di una metodologia di analisi non si potrà mai avere la garanzia che il requisito temporale di un particolare processo sia rispettato. Così, la proprietà più importante di un sistema real-time non è la velocità ma la prevedibilità. Per prevedibilità di un sistema si intende la capacità di determinare in anticipo se i processi di calcolo potranno essere completati entro i vincoli temporali richiesti (deadlines); essa può dipendere da vari fattori che vanno dalle caratteristiche architetturali della macchina (tecniche di DMA, memoria cache), ai meccanismi del kernel (interruzioni, primitive, gestione della memoria e delle risorse, semafori logici), fino al linguaggio di programmazione usato. 1 Tutte le considerazioni sui sistemi real-time riportate nel presente capitolo, salvo dove indicato diversamente, sono state tratte da [3].

2

1.2 Processi e scadenze Un processo o task è una sequenza di istruzioni che, in assenza di altre attività, viene eseguita dal processore in modo esclusivo e continuativo fino al suo completamento. La differenza principale tra un processo real-time e un processo non real-time consiste nel fatto che il primo deve terminare entro una scadenza temporale prefissata che prende il nome di deadline. La deadline dunque è il tempo massimo entro cui un task deve terminare la sua esecuzione. Nelle applicazioni real-time un risultato prodotto oltre la propria deadline non solo è in ritardo ma è dannoso. Per fare un esempio, si pensi al campo dell’automazione dove generalmente tutti i sistemi automatici utilizzati come controllori sono dei sistemi real-time: poiché l’elemento di controllo rappresenta un anello di retroazione del sistema globale si deve garantire che le operazioni siano svolte entro un tempo limitato affinché il sistema rimanga stabile; superare la deadline significa creare le condizioni per un potenziale disastro. La deadline relativa ad un processo è conseguenza diretta del campo applicativo e della funzione per la quale esso è stato concepito. A seconda delle conseguenze provocate da una mancata deadline, si possono identificare tre categorie principali a cui poter ricondurre la grande varietà di casi particolari: processi con scadenze hard, processi con scadenze firm e processi con scadenze soft. Al fine di poter definire una simile classificazione, ad ogni processo di un sistema real-time è associato un valore computazionale o funzione di costo che, in generale, cambia in relazione al tempo impiegato per il completamento del processo. Per i processi senza vincoli temporali, ossia non real-time, la funzione di costo ha un valore costante indipendente dal tempo di completamento del processo (vedi Figura 1.1d); tale valore è proporzionale all’importanza del processo ed è ‘accumulato’ dal sistema appena il processo viene portato a termine. Per i processi con vincoli temporali invece, la funzione di costo ha pieno valore solo se il processo termina prima della sua scadenza tscad; vengono così individuati i tre tipi di scadenza sopra citati in relazione al degrado della funzione di costo conseguente al mancato rispetto della deadline tscad:

• Una scadenza è di tipo hard se per t > tscad il valore della funzione di costo associata al completamento del processo è pari a –∞ (vedi Figura 1.1a): ciò significa che se tale scadenza non viene soddisfatta non solo il processo fallisce ma vengono inficiati i risultati ottenuti in precedenza da tutte le altre attività; nelle applicazioni critiche si hanno scadenze di tipo hard.

• Una scadenza è di tipo firm se per t > tscad il valore della funzione di costo diviene

nullo (vedi Figura 1.1b) e dunque si ha semplicemente un timeout; se l’esecuzione non è conclusa entro questo timeout non ha senso farla continuare: il processo viene abortito ed eventualmente ripetuto.

• Una scadenza è di tipo soft se per t > tscad il valore associato al completamento del

processo decresce progressivamente per arrivare dopo un certo tempo a zero (vedi Figura 1.1c); con scadenze di questo tipo assume importanza l’obiettivo di minimizzare il ritardo nel caso in cui questo sia inevitabile.

3

E’ facile ricondurre a questa classificazione alcuni esempi di applicazioni real-time. I sistemi di controllo sono essenzialmente sistemi di tipo hard essendo composti da processi che si occupano, ad esempio, di acquisire dati sensoriali, rilevare condizioni critiche, asservire gli attuatori, controllare le azioni senso-motorie e i dispositivi automatici. I sistemi impiegati nelle comunicazioni appartengono per lo più alla classe dei sistemi firm; le scadenze sono usate per garantire che il sistema non rimanga bloccato indefinitamente su operazioni di elaborazione o trasferimento dati che non hanno avuto successo: se una certa operazione non è conclusa entro un preciso timeout viene interrotta e ripetuta da capo; in questo caso il fallimento di un processo resta confinato alla particolare operazione che lo ha generato senza arrecare danno all’intero sistema. Infine, i sistemi di tempo reale di tipo soft sono comuni in diverse aree tra cui multimedialità, grafica interattiva e realtà virtuale; tipici processi soft riguardano ad esempio l’interprete dei comandi utente, la visualizzazione di messaggi su monitor e la rappresentazione dello stato del sistema.

Figura 1.1 – Funzione di costo in relazione alla scadenza: hard (a), firm (b), soft (c), non

real-time (d) Quando le scadenze non portano ad un fallimento generale del sistema, l’obiettivo principale consiste nel cercare di massimizzare la somma delle funzioni di costo dei vari processi tenendo presente che se un processo termina in ritardo il suo valore diminuisce (scadenza soft) o diviene nullo (scadenza firm). Con scadenze di tipo hard invece, l’obiettivo primario è quello di garantire con la massima certezza che ognuna di tali scadenze verrà rispettata (e quindi in definitiva ancora massimizzare la funzione totale di costo in quanto, in caso di superamento di una deadline hard, tale funzione andrebbe a –∞). Dunque gli obiettivi che caratterizzano il progetto di sistemi real-time dipendono principalmente dal tipo di scadenze dei processi componenti e i criteri di progetto variano proprio in funzione di questi obiettivi.

tscad

tscad

tscad

(c) (d)

(a) (b)

4

Per applicazioni di tipo soft e firm sono di solito utilizzati criteri euristici che cercano di fornire il miglior funzionamento possibile del sistema senza dare però alcuna garanzia sul rispetto delle scadenze: tali criteri sono denominati best-effort. Per applicazioni di tipo hard invece tali tecniche di ottimizzazione non sono affatto adeguate. Come è stato detto, le scadenze di tipo hard caratterizzano le applicazioni critiche; lo sfondamento di una deadline può provocare conseguenze catastrofiche su tutto il sistema, e quindi è assolutamente da evitare. In questo contesto allora lo sforzo progettuale è tutto rivolto a garantire un comportamento prevedibile, vale a dire che il sistema deve essere in grado di determinare in anticipo, ad esempio all’istante di creazione, se uno o più processi di calcolo potranno essere completati entro i propri vincoli temporali. Nel caso si abbiano processi hard obbligatori, avere una evoluzione prevedibile del sistema significa garantire in sede di progetto che ciascuno di essi rispetti sempre la propria deadline. Una tale richiesta impone tuttavia che si conoscano a priori il loro numero, i tempi di esecuzione e le risorse utilizzate; devono inoltre essere noti tutti gli eventi esterni che in qualche modo possono influenzare il comportamento del sistema. Molto spesso gran parte di queste informazioni non sono disponibili in sede di progetto, e ciò rende difficile la realizzazione di sistemi prevedibili composti da un elevato numero di processi hard obbligatori. Nel caso invece si abbiano processi hard opzionali, è possibile ottenere con certezza una evoluzione prevedibile del sistema mediante l’utilizzo di adeguate tecniche di analisi. I processi opzionali possono essere accettati o rifiutati; quando uno di essi è attivato, il sistema controlla che i nuovi vincoli temporali imposti possano essere soddisfatti senza invalidare le garanzie offerte ai processi che sono già in corso di esecuzione: una tale valutazione è condotta anche sulla base di informazioni dinamiche, ossia non conoscibili in fase di progetto. Se tali vincoli possono essere soddisfatti il processo viene accettato, altrimenti si ha un rifiuto da parte del sistema. L’utilizzo di processi hard opzionali è motivato dal fatto che, in alcune applicazioni critiche, si preferisce rinunciare del tutto all’esecuzione di un processo, piuttosto che rischiare che il processo superi la deadline durante l’esecuzione. Una deadline superata potrebbe infatti provocare più danno di un ‘aborto’ prematuro del processo: inoltre un processo eliminato con sufficiente anticipo può essere sempre sostituito con una procedura di recupero che porti il sistema in condizioni di sicurezza. Un sistema con tali caratteristiche viene denominato sistema con garanzia, poiché ogni volta che un nuovo processo viene attivato deve essere eseguito un test di garanzia per accettarlo o meno.

1.3 Schedulazione dei processi Quando un singolo calcolatore deve portare a termine l’esecuzione di più processi, si pone il problema di individuare una strategia di gestione che sequenzializzi l’uso della macchina fisica in base ad un criterio prefissato. Schedulare i processi che costituiscono un’applicazione significa assegnare loro, in base ad una particolare strategia, le risorse del sistema, in modo tale che l’esecuzione di ciascun task rispetti anche i vincoli specificati su tutti gli altri; i vincoli, oltre che temporali, possono essere di precedenza e di accesso mutuamente esclusivo a risorse condivise. L’operazione di schedulazione caratterizza i sistemi software multiprogrammati: poiché la risorsa più importante è la CPU, in letteratura si usa parlare di scheduling dei processi limitatamente all’assegnazione di tale risorsa.

5

L’insieme di regole che determinano la scelta del task da mandare in esecuzione tra tutti quelli pronti si chiama algoritmo di schedulazione; in genere, l’ordinamento della coda contenente i processi pronti viene fatto in modo che il processo da eseguire sia sempre il primo della coda. Un vero sistema real-time deve inoltre prevedere che il processo correntemente in esecuzione possa essere interrotto in qualsiasi istante e riportato in coda pronti (ready queue) per consentire ad un processo attivo più importante di completare la sua esecuzione: l’operazione di liberare il processore e riportare il processo in esecuzione in coda pronti viene detta preemption (prelazione). L’assegnazione effettiva della CPU al processo pronto schedulato viene invece detta dispatching, ed è effettuata dal sistema operativo (o meglio dal dispatcher) dopo che un task termina oppure dopo una preemption (vedi Figura 1.2).

Figura 1.2 – Coda dei processi pronti in attesa di esecuzione

In sintesi, il problema dello scheduling di processi real-time consiste nel trovare una schedulazione fattibile ossia tale che:

• tutti i processi terminino entro la propria deadline

• tutti i vincoli di precedenza siano rispettati

• tutte le risorse condivise mutuamente esclusive siano accedute correttamente. Il problema dello scheduling testè enunciato nella sua forma generale è però computazionalmente intrattabile in tempo polinomiale rispetto al numero dei processi (si dice che è un problema NP-hard): non esiste dunque alcun algoritmo di complessità polinomiale nel numero dei processi che sia in grado di trovare una schedulazione fattibile. Allo scopo di realizzare algoritmi di complessità polinomiale vengono fatte perciò delle ipotesi semplificative sul tipo di sistema e/o sul tipo di vincoli che esistono tra i processi cercando di risolvere il problema dello scheduling in casi particolari che possano essere di interesse per applicazioni reali. Alcune tipiche assunzioni che semplificano la ricerca di una schedulazione fattibile sono la possibilità di preemption sui processi, l’assenza di vincoli di precedenza e/o su risorse oppure il considerare tempi di arrivo simultanei per i processi o tempi di calcolo identici o ancora insiemi di processi omogenei (costituiti ad esempio da soli task periodici o da soli task aperiodici).

… esecuzione terminazione dispatching

scheduling

attivazione

preemption

READY QUEUE

P1 P2 P3 P4

6

1.4 Classi di algoritmi e analisi di schedulabilità A seconda delle ipotesi che si assumono sui processi e sul tipo di architettura hardware di supporto all’applicazione gli algoritmi di scheduling per sistemi real-time possono essere suddivisi in diverse classi. Ad esempio, gli algoritmi statici sono quelli in cui la regola di decisione è basata su parametri fissi che sono assegnati ai processi una volta per tutte prima della loro attivazione; al contrario, gli algoritmi dinamici sono quelli in cui la regola di decisione è basata su parametri dinamici che possono variare durante l’esecuzione dei processi. Negli algoritmi off-line tutte le decisioni di scheduling sono prese prima dell’attivazione dei processi sulla base di informazioni note a priori: la schedulazione viene memorizzata in una tabella che verrà eseguita a run-time; negli algoritmi on-line invece le decisioni di scheduling vengono effettuate a run-time sull’insieme corrente dei processi attivi: l’ordinamento dei processi viene quindi ricalcolato ad ogni nuova attivazione. Un criterio generico di schedulazione può fare uso o meno dell’analisi di schedulabilità: per mezzo di essa un sistema real-time cerca di determinare se uno o più processi di calcolo potranno essere completati correttamente nel rispetto dei vincoli specificati, implementando così la caratteristica della prevedibilità; l’analisi di schedulabilità può essere condotta solo a livello statico oppure anche durante l’esecuzione ed i risultati ottenuti rappresentano la base di decisione per la schedulazione dei processi. Nell’eventualità di applicazioni critiche il sistema real-time deve assolutamente prevedere opportuni strumenti che realizzino l’analisi di schedulabilità. In base alle considerazioni fatte viene proposta la suddivisione degli algoritmi di schedulazione nelle seguenti quattro classi [24]: Approcci statici table-driven Realizzano un’analisi di schedulabilità a livello statico la quale produce una tabella che è un vero e proprio piano di schedulazione; tale piano è usato a tempo di esecuzione per regolare lo svolgimento dei processi. Questi approcci vengono applicati ai processi più critici che compongono una certa applicazione poiché sono quelli che forniscono il massimo grado di prevedibilità. Per contro tali approcci sono estremamente poco flessibili: l’aggiunta di un processo al sistema – aggiunta che può essere effettuata solo a livello statico – può determinare una modifica sostanziale del piano di schedulazione. Poiché tale piano non può essere estremamente lungo l’approccio si adatta bene solo a processi periodici: la tabella abbraccia un periodo di tempo che è il minimo comune multiplo dei periodi dei processi in gioco. Approcci statici priority-driven con preemption L’analisi di schedulabilità condotta in fase di progetto non produce più un piano completo di schedulazione ma si limita ad assegnare ad ogni processo un valore di priorità statico secondo un criterio che garantisca l’esecuzione in tempo di tutti i processi; a livello dinamico i processi sono schedulati con strategia highest priority first con preemption: se una certa risorsa è posseduta da un processo e viene richiesta da un altro processo a priorità più alta il processo subisce preemption.

7

Anche questo approccio è utilizzato solitamente per schedulare processi periodici, tuttavia offre un grado di flessibilità maggiore rispetto all’approccio con tabella poiché non si specifica a priori l’istante in cui ciascun processo dovrà essere attivato. L’algoritmo più famoso appartenente a questa classe è il Rate Monotonic concepito nella sua prima versione come base per l’assegnazione della CPU a una serie di processi periodici indipendenti. Per ogni processo si specifica il WCCT (tempo di computazione nel caso peggiore) e il periodo: l’obiettivo è concludere l’esecuzione prima che finisca il periodo. Un processo ha priorità maggiore rispetto ad un altro se il suo periodo è minore: su questa base è possibile dimostrare che, se in presenza di processi indipendenti l’utilizzo della CPU resta confinato entro una certa percentuale (che quantificheremo matematicamente nel paragrafo 2.3 del capitolo seguente), si ha la certezza che il sistema non fallisca mai; inoltre si hanno risultati che permettono una buona flessibilità nel posizionare gli istanti di inizio dei vari processi. Sono state anche proposte estensioni per utilizzare l’algoritmo in presenza di processi aperiodici e di risorse condivise. Approcci dinamici planning-based A differenza dei precedenti due approcci l’analisi di schedulabilità (o almeno una sua parte) è condotta al tempo di esecuzione: ci si rivolge ad un insieme di processi hard dei quali alcuni sono obbligatori, altri opzionali. Quando un processo opzionale viene attivato il sistema stabilisce se in base alla situazione corrente se ne può garantire l’esecuzione in tempo e, in caso affermativo, viene accettato. La scelta effettuata è basata su informazioni che in parte sono disponibili a livello statico e in parte sono invece frutto di una elaborazione delle informazioni conoscibili solo durante l’esecuzione. Viene perciò realizzato un piano di schedulazione per il nuovo processo tale da non compromettere le garanzie offerte ai processi che sono già in corso di esecuzione. Nel caso che non sia possibile offrire una garanzia completa il processo viene rifiutato e vengono eventualmente svolte azioni alternative. Questo approccio presenta una flessibilità maggiore rispetto a quelli visti in precedenza a discapito però di una maggiore complessità. Approcci dinamici best-effort In questo tipo di algoritmi non viene realizzata alcuna analisi di schedulabilità: il sistema cerca di fare del suo meglio per rispettare tutte le scadenze ma non viene data nessuna garanzia di successo; tali approcci sono applicabili soltanto a processi con scadenze di tipo firm o soft e sono spesso corredati da un sistema che gestisce gli eventuali fallimenti. Un esempio tipico di strategia best-effort è l’algoritmo Earliest Deadline First: si sfrutta un sistema di priorità che viene stabilito a livello dinamico e privilegia i processi la cui scadenza è più vicina. Se i processi sono indipendenti e viene contesa una sola CPU l’algoritmo è ottimo, vale a dire che se il problema della schedulazione è risolvibile esso è in grado di trovare una delle possibili soluzioni; questo naturalmente non garantisce alcunché: infatti nel caso in cui non esista soluzione non c’è alcun modo per rendersene conto in tempo. Un altro esempio di algoritmo best-effort basato su un sistema dinamico di priorità è il Least Laxity First: stavolta il processore è assegnato al task avente la laxity minore cioè quello per il quale la differenza tra il periodo e il tempo di computazione nel caso peggiore (WCCT) è minore.

8

1.5 Limiti degli attuali sistemi operativi real-time La maggior parte dei sistemi operativi real-time disponibili in commercio sono basati su un kernel sviluppato a partire da versioni più o meno complesse di sistemi tradizionali di tipo timesharing e si fondano di conseguenza sugli stessi principi su cui sono progettati tali sistemi, ereditando così inevitabilmente alcuni meccanismi di base per la gestione dei processi che non sono adatti a supportare applicazioni in tempo reale. Il principio basilare che caratterizza questi sistemi real-time è quello tipico dei sistemi timesharing multi-utente: vale a dire che tutti i processi del sistema sono considerati come dei task casuali indipendenti di cui quasi nulla è noto. L’obiettivo più importante di questi sistemi real-time è allora quello di minimizzare il tempo medio di risposta agli eventi esterni attraverso un insieme di primitive molto veloci: sebbene questo sia un risultato apprezzabile, come è stato già sottolineato la velocità in sé non implica ‘garanzia’ del rispetto dei vincoli temporali specificati per le attività in tempo reale. Nelle estensioni real-time di sistemi operativi tradizionali il progettista è costretto a trasformare l’insieme dei vincoli temporali dei processi in un insieme di priorità affinché sia possibile schedulare tutti i processi entro le proprie deadline, ma questa trasformazione non risulta sempre di facile attuazione; inoltre, se il sistema non prevede un meccanismo per la gestione esplicita del tempo, lo scheduling prioritario non è sufficiente a garantire il rispetto dei vincoli temporali dei processi. In sintesi, le estensioni real-time di kernel tradizionali timesharing ci forniscono un sistema su cui non possono essere eseguite applicazioni che presentano scadenze di tipo hard; anche raggiungendo un maggiore determinismo nella valutazione dei tempi si ha ancora un sistema che ottimizza il caso medio piuttosto che il caso peggiore, per cui possono essere eseguite con buoni risultati soltanto applicazioni di tipo soft real-time. Per avere un sistema capace di trattare applicazioni real-time e non, le modifiche vengono realizzate come aggiunta al sistema operativo tradizionale, ma muoversi in questa direzione può portare a veri e propri ‘buchi nell’acqua’: un caso tipico è l’esempio di RT-UNIX dove si consiglia di non usare certe chiamate di sistema se non si vogliono avere ‘guai’ per i processi critici. Nonostante tutto ciò, sistemi di questo tipo sono ancora largamente utilizzati e il prezzo che si paga è l’estrema inaffidabilità delle applicazioni su di essi eseguite. Esiste dunque l’esigenza di sviluppare nuove tecniche capaci di aumentare la flessibilità e la prevedibilità del sistema e poter così garantire i vincoli temporali richiesti dai processi. Attualmente nella pratica industriale si fa ricorso in genere a sistemi operativi real-time basati su microkernel (come ad esempio il QNX) i quali utilizzano una architettura che permette di passare da un kernel di piccole dimensioni adatto ad applicazioni real-time embedded (integrate) – il microkernel appunto – ad uno di maggiori dimensioni che fornisce numerose funzionalità aggiuntive, soprattutto di carattere non real-time; l’obiettivo è quello di poter disporre di un sistema organizzato per moduli tale da poter scegliere in base all’applicazione corrente quali componenti utilizzare e quali no (modularità). Il microkernel occupa generalmente pochissimo spazio in memoria ed è dedicato a poche operazioni essenziali ma ora, a differenza delle estensioni real-time dei sistemi timesharing, è specificamente progettato per gestire le applicazioni real-time. Tutti i rimanenti servizi di sistema vengono svolti da moduli esterni ma cooperanti con il microkernel; tali moduli non sono altro che dei processi particolari che, come i task

9

real-time veri e propri, devono essere schedulati dal microkernel per poter eseguire: diventa perciò agevole personalizzare il sistema arricchendolo con nuovi moduli. L’approccio a microkernel utilizzato per la realizzazione di questa nuova classe di sistemi real-time costituisce una valida alternativa alla precedente poiché la realizzazione del kernel in più moduli consente a chi programma di inserire le proprie chiamate al sistema a livelli diversi di astrazione, a seconda del tipo di servizio che vuole ottenere. L’architettura utilizzata risolve i problemi di dimensione e complessità presenti nei sistemi tradizionali arricchiti con nuove funzioni; in questa maniera, con un microkernel creato ex-novo, si ottiene un sistema più veloce e più predicibile rispetto all’altro approccio. Tuttavia, gli strumenti offerti in termini di schedulazione dei processi sono sempre gli stessi: è impossibile gestire applicazioni in cui i processi sono in competizione per risorse diverse dalla CPU, ovvero risorse condivise mutuamente esclusive, in quanto non è previsto nessun sistema a priorità per regolarne l’accesso. Ma ancor peggio, non viene fornito nessuno strumento per effettuare l’analisi di schedulabilità dei processi critici, in modo da avere un sistema prevedibile. Il percorso da seguire, partendo da sistemi con architettura a microkernel, è allora quello di arricchire le funzioni di tali sistemi aggiungendo dei moduli custom cooperanti con il microkernel. Il procedimento per rendere prevedibile un sistema real-time consiste principalmente nell’implementazione di adeguate tecniche di supporto che, utilizzando le informazioni sulla sincronizzazione dei processi, sui tempi di esecuzione di ogni loro parte e su tutti i tipi di vincoli specificati, riescono a fornire un piano di schedulazione per il quale è garantita l’assenza di fallimenti.

10

2. Analisi del modello teorico ed applicativo

2.1 Il modello teorico Come già accennato nel precedente capitolo, i sistemi operativi real-time disponibili in commercio non forniscono generalmente alcun strumento per condurre l’analisi di schedulabilità e regolare in base ad essa l’esecuzione dei processi; essi si limitano a offrire primitive di sistema la cui durata è nota a priori con un piccolo margine di incertezza, rispondendo così al requisito della prevedibilità solo in parte. Il progettista che vuole realizzare una applicazione real-time hard utilizzando una piattaforma commerciale dovrà perciò prevedere la presenza di uno o più moduli aggiuntivi che suppliscano alle carenze denunciate: un approccio di questo tipo comporta tuttavia uno sforzo aggiuntivo che si ripete invariato per ogni nuovo progetto. L’obiettivo del lavoro di Sauro Carsughi [2] – e a cui questa tesi si ispira – consisteva così nell’identificare e specificare formalmente un modello applicativo che effettuasse dinamicamente l’analisi di schedulabilità di un insieme di processi concorrenti nell’uso di risorse esclusive (CPU compresa) e sottoposti a vincoli di scadenza sul completamento, e ne simulasse l’esecuzione su una piattaforma monoprocessore: il modello di sistema anche da noi adottato è perciò costituito da un insieme di task real-time e da un insieme di risorse utilizzabili (vedi Figura 2.1).

Figura 2.1 – Processi concorrenti per le risorse di sistema

Il modello presenta nel complesso una buona espressività, nel senso che comprende una vasta gamma di applicazioni reali; i processi considerati possono essere (come vedremo più avanti) di quattro tipologie predefinite sufficientemente generali e i vincoli che su di essi si possono specificare, e che una schedulazione deve rispettare per essere fattibile, sono di tre tipi: • Vincoli temporali: tutti i processi devono rispettare dei vincoli temporali per

garantire la validità del risultato; in particolare, ci si riferisce alla deadline o scadenza che rappresenta il tempo massimo entro cui un task deve terminare la sua esecuzione.

P1

P2

Pn

risorse di sistema

11

• Vincoli di precedenza: è possibile specificare vincoli di precedenza (singoli) per alcuni processi; qualora siano presenti, i task non possono essere eseguiti in ordine arbitrario.

• Vincoli su risorse: una risorsa è una qualsiasi entità software o hardware che può

essere utilizzata da uno o più processi per portare a termine l’esecuzione; tipicamente una risorsa può essere una struttura dati, una zona di memoria o una porzione di codice. Nel nostro modello è possibile specificare per ogni processo delle risorse condivise che non ammettono l’accesso contemporaneo da parte di più task allo scopo di mantenere la consistenza delle strutture dati interne; esse prendono il nome di risorse mutuamente esclusive o sezioni critiche perché, in caso di richieste simultanee, si ammette l’accesso ad un solo processo per volta. Quando un task entra in una sezione critica, questa non gli può essere revocata fino al termine dell’esecuzione.

L’insieme dei vincoli temporali dei processi vengono trasformati in un insieme di priorità affinché si possa massimizzare l’utilizzazione delle risorse: il task con la priorità più alta esegue per primo; la priorità verrà assegnata ad ogni processo direttamente dall’utente del sistema (che la determina in maniera statica prima dell’attivazione del processo) oppure, per alcune tipologie di task, automaticamente dal sistema stesso (che la calcolerà in maniera dinamica ed in funzione di certi parametri non appena il processo arriva1). Il problema della schedulazione è quindi affrontato con un approccio fixed priority preemptive scheduling, ovvero i processi sono schedulati secondo un protocollo di gestione preemptive della CPU basato su priorità (fissata). La preemption è necessaria ogni qual volta un processo a bassa priorità detiene la CPU e diventa pronto per eseguire un processo a priorità più alta: allora il primo task viene sospeso revocandogli la CPU che viene assegnata al secondo. I processi del nostro modello applicativo ovviamente non eseguono computazioni vere e proprie ma ne simulano lo svolgimento attraverso opportuni blocchi a tempo2 omogenei3 di durata prestabilita: la temporizzazione rilevata risulta comunque – come vedremo nell’ultimo capitolo – praticamente uguale a quella che verrebbe presentata da un vero sistema operativo real-time. L’applicazione realizzata perciò non si limita solo a fornire un valido supporto per la schedulazione dinamica dei task, cercando di analizzare se la schedulazione di un certo insieme di processi è fattibile o meno, ovvero se esiste un assegnamento dei processi al

1 Per arrivo di un processo (o di un task) si intende il momento in cui il processo in questione diventa pronto per eseguire (vedi il paragrafo 3 del primo capitolo). 2 I blocchi a tempo costituiscono, come spiegato in [2], la cosiddetta ‘vista di simulazione’ del processo real-time e sono specificati nel nostro modello Statemate (analogamente al modello SDL di riferimento) tramite opportuni stati di attesa nei quali il processo, non più reale ma fittizio, non esegue alcuna computazione vera ma ne simula un’esecuzione finta che terminerà in base al tempo caratteristico del blocco rappresentato la cui durata, come vedremo meglio nel paragrafo 2.2.1.1, è data dal Worst Case Computation Time (WCCT) della corrispondente sequenza reale di istruzioni. 3 L’esecuzione simulata di un processo real-time può essere decomposta in più di un blocco a tempo dipendentemente dalle risorse alle quali esso deve accedere per completare la sua esecuzione; ad ogni modo ciascun blocco dovrà essere omogeneo: nel nostro caso con questo termine si vuol indicare che, se un processo accede ad una o più sezioni critiche, si dovrà prevedere uno e un solo blocco a tempo per ciascuna differente fase di esecuzione (normale e critica) del processo stesso, come illustrato in Figura 2.3.

12

processore tale che tutti i task siano completati rispettando i vincoli temporali prefissati; essa permette anche, simulando e sincronizzando correttamente l’esecuzione dei vari processi schedulati, di riprodurre le funzionalità basilari tipiche di un sistema operativo real-time, in particolare per ciò che riguarda la gestione della CPU in maniera preemptive, l’acquisizione e il rilascio di sezioni critiche preemptable mediante l’utilizzo di un opportuno protocollo di accesso e la presenza di eventuali vincoli di precedenza tra gli ‘ipotetici’ processi simulati. Tale gestore-simulatore di task real-time (chiamato in [2] Kernel Simulator), a questo primo livello di analisi, può dunque essere visto come una ‘scatola nera’ che riceve in ingresso tutte le richieste dei processi da schedulare e ne produce in uscita la loro esecuzione simulata, mostrando per ogni task tutta la temporizzazione relativa alle sue varie fasi (critiche e non critiche) di computazione.

2.2 Il modello applicativo

2.2.1 I processi specificati Tutti i processi del nostro modello applicativo sono real-time e quindi caratterizzati da vincoli temporali. L’insieme dei task da schedulare non è predeterminato a priori, cioè prima dello start-up del sistema, dato che essi sono attivati dinamicamente e casualmente; in un tale scenario, i criteri di schedulazione possono essere solo di tipo on-line: le decisioni di schedulazione vengono effettuate a run-time sull’insieme corrente dei processi attivi ed il loro ordinamento viene ricalcolato ad ogni nuova attivazione. I task possono essere raggruppati in base a diversi criteri, ma le due categorie più significative ai fini del nostro modello in cui i processi vengono partizionati in base al loro tipo di vincolo temporale sono le seguenti (vedi anche Figura 2.2): • Processi real-time critici (hard): presentano una scadenza che non può essere

assolutamente superata in quanto il superamento di una deadline, oltre al fallimento del task stesso, può provocare conseguenze catastrofiche sull’intero sistema. Questo tipo di processi sono tutti periodici e la loro esecuzione può essere rifiutata al momento dell’attivazione: prima di essere schedulati devono infatti superare (come vedremo meglio più avanti) un test di accettazione in modo da avere la garanzia che il sistema sia in grado di completare la loro esecuzione entro i vincoli temporali specificati. Essi sono perciò processi real-time garantiti e in condizioni di corretto funzionamento del sistema non è praticamente possibile un loro fallimento. Data la loro criticità, possiedono un’alta priorità di esecuzione e possono essere prelazionati esclusivamente da altri processi periodici critici garantiti (pcg). La priorità viene assegnata loro automaticamente dal sistema al momento dell’attivazione secondo il criterio di schedulazione Rate Monotonic: ciò consiste nel dare ad ogni task una priorità direttamente proporzionale alla sua frequenza di richiesta, in modo che ai processi con periodi più brevi venga assegnata una priorità più elevata; a parità di periodo e quindi di priorità, le richieste dei task sono ordinate e servite con strategia FIFO (First In First Out).

13

• Processi real-time firm: per questo tipo di task il superamento di una deadline provoca semplicemente il fallimento dell’esecuzione del processo che così non fornisce alcun contributo al sistema ma non vi arreca nessuna conseguenza catastrofica; questi tipi di processi, come vedremo tra poco, possono essere periodici, sporadici o one-shot, e su di essi (tranne che per gli sporadici) si possono specificare dei vincoli di precedenza singoli. La priorità viene assegnata loro in modo statico: sarà l’utente a deciderla prima dell’attivazione ma non potrà mai essere superiore alla priorità di un qualsiasi processo critico affinché quest’ultimo non subisca mai prelazione da parte dei firm. Poiché i task firm non sono critici per il sistema su di essi non viene eseguito alcun test di garanzia: essi vengono sempre schedulati ma senza avere la certezza del rispetto della deadline e per questo si tratta di processi non garantiti. Il criterio di schedulazione è ora di tipo Best Effort, vale a dire che il sistema cerca di fare del suo meglio per rispettare le deadline dei processi firm: il sistema schedula tali task in accordo alla loro priorità ed anche in questo caso, a parità di priorità, i processi vengono serviti con strategia FIFO. Con questo tipo di approccio è fondamentale il criterio con il quale l’utente assegna le priorità ai vari processi firm: si dovrà far in modo che quei task che hanno una deadline ravvicinata alla fine della loro computazione siano schedulati con una priorità più alta rispetto agli altri. Infine si fa notare che la fattibilità di schedulazione dei processi firm è inversamente proporzionale al carico di lavoro dei processi critici i quali hanno sempre precedenza di esecuzione.

Figura 2.2 – Tipologie di processi real-time specificati nel nostro modello

Priorità: assegnata dall’utente

CRITICI (HARD)

GARANTITI

periodici (senza vincoli di precedenza)

Priorità: assegnata dal sistema

Criterio di schedulazione: Rate Monotonic

FIRM

NON GARANTITI

Criterio di schedulazione: Best Effort

periodici e one-shot (con vincoli di precedenza singoli);

sporadici

14

2.2.1.1 Rappresentazione convenzionale dei processi Il modello del sistema prevede che tutti i processi, sia i critici garantiti che quelli firm non garantiti, siano caratterizzati da un tempo di esecuzione deterministico che rappresenta il valore massimo (caso peggiore) del tempo computazionale e che viene detto appunto Worst Case Computation Time (WCCT). I processi critici sono quelli più significativi del nostro modello applicativo dato che si tratta di processi garantiti: essi sono stati considerati sempre di tipo periodico, cioè generano in modo ripetitivo e ad intervalli costanti nel tempo (periodo) istanze costituite da una sequenza di attività identiche. Questa assunzione è ben fondata e non crea grosse perdite di generalità poiché nei sistemi in tempo reale dedicati al controllo di dispositivi automatici i processi periodici rappresentano la maggior parte delle attività di elaborazione. In particolare, tutte le attività di regolazione, acquisizione di segnali, filtraggio, elaborazione di dati sensoriali, pianificazione di azioni, monitoraggio e comando di attuatori rappresentano processi che devono essere eseguiti con una certa periodicità, a frequenze definite dai vincoli e dai requisiti dell’applicazione. Senza introdurre eccessive restrizioni sono state così assunte le seguenti ipotesi di progetto sui task di tipo pcg: 1. Tutte le richieste di esecuzione delle varie istanze vengono inoltrate ad intervalli di

tempo regolari: in altre parole, si assume che il periodo T di un processo periodico sia costante nel tempo.

2. Il WCCT di un processo periodico è costante nel tempo e non varia da istanza a

istanza. 3. La deadline associata ad un’istanza periodica coincide con la fine del periodo

corrente e quindi coincide anche con l’istante in cui il processo inoltra la successiva richiesta di esecuzione.

4. Non si hanno vincoli di precedenza tra processi periodici critici mentre possono

essere specificati vincoli su risorse condivise mutuamente esclusive (sezioni critiche).

Queste assunzioni permettono di caratterizzare i processi pcg, nel caso non eseguano in sezione critica, per mezzo di due soli parametri: il periodo T e il tempo massimo di computazione WCCT. Se invece sono previste parti di computazione in zona critica, dovrà essere considerata un’opportuna sequenza di WCCT alternati: un WCCT non di sezione critica può essere seguito solo da un WCCT di sezione critica e viceversa, seguendo il principio di omogeneità dei blocchi a tempo accennato precedentemente nel paragrafo 2.1; infatti i vari WCCT in cui viene decomposta l’esecuzione di un task forniranno proprio i tempi dei blocchi a tempo della vista di simulazione del task mentre il periodo ne rappresenterà la deadline. In Figura 2.3 sono rappresentati due esempi di processi periodici che potrebbero essere sia critici che firm; si può vedere come solo il secondo svolga parte della sua computazione in sezione critica: la vista di simulazione del primo task sarà così costituita da un unico blocco di 3 unità di tempo, mentre quella del secondo sarà composta da tre blocchi omogenei rispettivamente di 2, 4 e 3 unità di tempo per un WCCT complessivo di 9 unità di tempo su un periodo di 21.

15

Figura 2.3 – Rappresentazione convenzionale di due processi periodici

Le tre parti computazionali del secondo processo vengono naturalmente eseguite rispettando l’ordine: in pratica è come se vi fossero dei vincoli di precedenza tra computazioni interne ad una stessa istanza del task. Al contrario, nel nostro modello applicativo non sono previsti vincoli di precedenza tra computazioni di processi critici diversi: tale decisione è stata condizionata dal fatto che la teoria del Rate Monotonic, sulla quale si basa il nostro test di garanzia, non tratta nessun tipo di vincoli di precedenza. Per quanto riguarda invece la caratterizzazione dell’insieme dei processi firm non garantiti, bisogna sottolineare che questo insieme non è sottoposto ad alcuna analisi di schedulabilità e quindi può comprendere le più svariate tipologie di processi: nel nostro modello sono state previste tre tipologie predefinite ma nulla vieta ad un utente-progettista di definirne altre a suo piacimento e maggiormente aderenti ai suoi scopi, sempre rispettando comunque le regole di funzionamento del modello applicativo già specificato. Le assunzioni fatte per i critici sono valide anche per i processi periodici firm con la sola differenza che ora è possibile specificare vincoli di precedenza, ma in pratica la loro rappresentazione convenzionale è del tutto equivalente. I processi sporadici sono invece processi aperiodici che possono però essere visti come dei particolari processi periodici in cui il periodo inteso come deadline è ancora costante nel tempo anche se le richieste di esecuzione delle varie istanze successive alla prima non vengono inoltrate ad intervalli di tempo regolari e pari al periodo ma ad istanti di tempo casuali, pur variabili entro un certo range temporale e comunque non prima della scadenza della deadline dell’istanza precedente. I processi one-shot sono infine task aperiodici formati da una unica istanza di esecuzione da completare entro una determinata deadline (per maggiori dettagli su queste ultime tre tipologie di processi real-time vedi il paragrafo 2 del capitolo 5). La rappresentazione convenzionale dei due processi di Figura 2.3 è valida anche nel caso di processi sporadici e one-shot dove per quest’ultimi il periodo T viene sostituito dalla deadline (non periodica). Come già accennato, per i processi firm è possibile specificare anche vincoli di precedenza tra le computazioni di task diversi (vedi Figura 2.4).

sezione critica

WCCT = 3

WCCT = 2 WCCT = 3 WCCT = 4

T = 7

T = 21

P1

P2

16

Figura 2.4 – Rappresentazione di catene di processi con vincoli di precedenza

Nel nostro modello però, per non complicarne troppo la specifica, sono state previste solo due tipologie di processi con vincoli di precedenza, i periodici e i one-shot, sui quali comunque si possono specificare esclusivamente dei vincoli di precedenza singoli: vale a dire che un task può avere al massimo un solo successore ed un solo predecessore. A tal proposito si fa notare che, nel caso si specifichi una catena di processi periodici con vincoli di precedenza, i periodi di questi task dovranno essere molto simili se non addirittura uguali affinché la catena sia consistente nel tempo e non vi siano fallimenti: questo avvertimento è di valenza generale e non dipende affatto da come è stato realizzato il modello applicativo.

2.2.2 Il Kernel Simulator Una volta presentato il modello dei processi al quale si fa riferimento nella nostra specifica è necessario spiegare in che modo si produce la loro esecuzione simulata con tutta la temporizzazione relativa alle varie fasi di computazione. L’idea seguita (mutuata direttamente da [2]) è stata quella di partizionare i processi in due insiemi ben determinati, utilizzando una tecnica di tipo best-effort per la schedulazione di applicazioni non critiche ed un’altra rate-monotonic con analisi di schedulabilità per quelle critiche; ad ogni modo, queste due tecniche devono essere inglobate in un unico piano di schedulazione con un criterio che ne mantenga inalterata la validità: il problema della schedulazione è allora affrontato con un approccio preemptive basato su priorità e, variando la regola di assegnazione delle priorità, si ottengono le due diverse strategie di gestione dei processi sopra citate. Il ‘cuore’ operativo dell’intero sistema applicativo è rappresentato dai tre processi acceptance, global_monitor e semaphore (illustrati dettagliatamente nel capitolo 5) che nel modello SDL proposto in [2] formano il cosiddetto Kernel Simulator. Come già accennato precedentemente, il compito fondamentale del Kernel Simulator è quello di servire dinamicamente le richieste dei vari task assegnando loro il processore in base

P1 P2 P3

P4 P5 P6

P7 P8

VINCOLI DI PRECEDENZA SINGOLI

VINCOLI DI PRECEDENZA MULTIPLI

17

alla priorità: esso accoda tutte le richieste secondo la loro priorità in modo da servire per prime le più urgenti (e a parità di priorità quelle arrivate temporalmente prima). Le decisioni di schedulazione vengono prese a run-time sull’insieme corrente dei task pronti ricalcolandone l’ordinamento ad ogni nuova attivazione ed eventualmente effettuando una prelazione sulla CPU a favore del nuovo processo arrivato se questo ha una priorità strettamente maggiore di quella del task attualmente in esecuzione: un tale servizio, attuando in pieno il multitasking secondo una gestione timesharing e preemptive della CPU, sarebbe già sufficiente a concretizzare un semplice sistema operativo in tempo reale. Il Kernel Simulator va oltre questo primo livello base di elaborazione offrendo ulteriori funzionalità che permettono di realizzare la prevedibilità di sistema, la gestione di risorse condivise, mutuamente esclusive e preemptable (sezioni critiche) e quella di eventuali vincoli di precedenza (singoli): vedi Figura 2.5.

Figura 2.5 – Le funzionalità offerte dal nostro Kernel Simulator

SSIIMMUULLAAZZIIOONNEE

Analisi di schedulabilità

Gestione delle risorse

Vincoli di precedenza

PROCESSI

KERNEL SIMULATOR

Multitasking

+

18

2.2.3 Analisi di schedulabilità I processi per i quali il nostro sistema offre la garanzia del rispetto delle deadline tramite un opportuno test di schedulabilità sono i task periodici privi di vincoli di precedenza che però possono concorrere su risorse condivise mutuamente esclusive (sezioni critiche) e quindi non sono tra loro indipendenti. Il problema dell’analisi di schedulabilità per processi che si sincronizzano su sezioni critiche dipende in modo cruciale dal blocco che tali processi possono subire durante l’accesso a queste risorse comuni; il tempo di blocco dipende poi dal tipo di protocollo usato per gestire tali risorse: tutta la questione inerente la gestione degli accessi alle sezioni critiche e la relativa analisi di schedulabilità verranno affrontate a parte nel prossimo paragrafo. In questo paragrafo quindi verrà trattata solo l’analisi di schedulabilità per processi periodici ed indipendenti ovvero che non entrano mai in sezione critica: per un tale insieme di task la teoria del Rate Monotonic (RM) ci fornisce un criterio ‘sufficiente ma non necessario’ per schedularli e garantirne l’esecuzione; per analizzare se un insieme di processi periodici indipendenti è schedulabile si introduce così il seguente teorema [4]: TEOREMA 1: Un insieme di n task periodici indipendenti schedulati con l’algoritmo del Rate Monotonic rispetterà sempre le deadline per qualunque istante di attivazione dei task se è soddisfatta la disequazione

−≤+++ 12

1

2

2

1

1 n

n

n nTC

TC

TC

L

dove Ci è il tempo di esecuzione e Ti è il periodo (deadline) del task τi. Il rapporto Ci/Ti ci dà la frazione di tempo utilizzata dalla CPU per eseguire il task τi mentre la sommatoria a primo membro prende il nome di fattore di utilizzazione U del processore e rappresenta la frazione di tempo totale utilizzata dalla CPU per eseguire l’insieme di task. Il fattore U fornisce dunque una misura dell’occupazione del tempo di CPU da parte di un insieme di task periodici. Sebbene il fattore di utilizzazione del processore possa essere aumentato allungando i tempi di calcolo Ci e/o diminuendo i valori dei periodi Ti, esiste un limite superiore (upper bound) che ci viene dato dal teorema 1 ed oltre il quale non vi è più garanzia di una schedulazione fattibile; per grossi valori di n l’espressione n(2(1/n)–1) converge rapidamente verso un valore limite maggiore di zero che risulta ln2 ≅ 0.69. Il limite superiore al fattore di utilizzazione che ci viene dato dal Rate Monotonic è però molto pessimistico: esso si riferisce al caso peggiore, in cui cioè non sussiste nessun tipo di correlazione tra i periodi dei processi; ad esempio, il massimo grado di correlazione si ottiene quando i periodi dei task sono legati da relazioni armoniche (multipli tra loro) nel qual caso è consentito, almeno in linea teorica, un fattore di utilizzazione unitario. Uno studio effettuato da Lehoczky, Sha e Ding nel 1989 [32] ha dimostrato che su insiemi di task generati casualmente il limite superiore del fattore di utilizzazione vale mediamente 0.88; si capisce dunque che si può far meglio del bound fornito dal teorema 1 il quale per n grande permette un ‘rendimento’ del processore per l’esecuzione di processi pcg poco sopra il 69% rispetto ad un possibile 88% come valore medio.

19

Per determinare allora se un insieme di task è schedulabile con un fattore di utilizzazione superiore al bound del RM si ricorre alla teoria del GRMS (Generalized Rate Monotonic Scheduling) che rappresenta una generalizzazione del Rate Monotonic. Essa utilizza un test di garanzia di esatta schedulabilità basato sulla zona critica che rappresenta il tempo di risposta più lungo dell’insieme dei processi, il quale a sua volta è il tempo che intercorre tra l’istante di richiesta di un’istanza periodica e l’istante di completamento della stessa (vedi Figura 2.6).

Figura 2.6 – Tempo di risposta o di completamento di un task periodico

Il test di garanzia del GRMS nasce dal seguente teorema [4]: TEOREMA 2: Dato un insieme di n task periodici indipendenti di periodo Ti se un task τi rispetta la sua prima deadline terminando all’istante Ri ≤ Ti quando esso e tutti i task a priorità più alta sono partiti nello stesso istante temporale, allora il task τi rispetterà tutte le sue future deadline con qualunque altro istante di partenza. E’ stata svolta un’ampia trattazione [32] per verificare se un task può rispettare la sua prima deadline. Dato un insieme di n task periodici con periodo (deadline) Tj consideriamo il task τn ed assumiamo che i task τ1…τn-1 abbiano tutti una priorità più alta di τn; in qualunque istante di tempo t la domanda totale e cumulativa sul tempo di CPU di questi n task è data dalla seguente quantità:

=

++

= ∑

= j

n

jj

nnn T

tCTtC

TtCtW

111)( L

dove l’intero superiore del rapporto t/Tj rappresenta il numero di volte che il task τj arriva nel tempo t, il valore Cj è il suo tempo di computazione e quindi il termine

jj T

tC rappresenta la sua domanda all’istante t.

Se ad esempio si ha un task τ1 con periodo T1=10 e tempo di esecuzione C1=5, al tempo t=9 il task ha fatto domanda per 5 unità di tempo ma al tempo t=11, poiché il task è arrivato nuovamente, ha una domanda cumulativa di 10 unità di tempo. Supponiamo ora che il task τn completi la sua esecuzione esattamente al tempo t rispettando la sua deadline: questo significa che la domanda totale cumulativa degli n task fino al tempo t, Wn(t), è esattamente uguale a t, ovvero Wn(t) = t. Un metodo allora per verificare la fattibilità di schedulazione di un task τn quando gli altri task τ1…τn-1 hanno una priorità maggiore di τn viene illustrato dall’algoritmo riportato nel Listato 2.1 mutuato direttamente da [2] che a sua volta lo ha ricavato modificando opportunamente l’algoritmo iterativo proposto da Sha in [4]. L’algoritmo originario di Sha infatti analizza il tempo di completamento del task τn che corrisponde proprio alla zona critica in quanto il task è quello a priorità minore; il tempo di completamento del

C T

t

tempo di risposta

20

task τn viene proprio dato dal valore di Wn(ti) quando questo è uguale a ti; tale procedura però è in grado di trovare il tempo di completamento Wn(ti) = ti per il task τn solo nel caso in cui questo tempo sia minore o uguale della deadline di τn che, come si è detto, coincide con il suo periodo Tn; se invece il processo non è in grado di soddisfare la sua deadline il ciclo dell’algoritmo di Sha non ha più fine e ad ogni iterazione successiva produce numeri sempre più grandi: in [2] vi è stato allora inserito un controllo aggiuntivo (evidenziato in grassetto nel Listato 2.1) che verifica quando il termine Wn(ti) supera il valore della deadline Tn del task τn, nel qual caso non è possibile schedulare il processo in questione garantendo il rispetto della deadline stessa. t0 :=∑ =

n

j jC1

; /* inizializza t0 con la somma dei tempi di esecuzione di tutti i task τ1…τn */

i:=0; /* inizializza l’indice i */ while (Wn(ti) ≤ Tn) loop ti+1 := Wn(ti); if (Wn(ti) = ti) then write(‘task_τn_accepted’); break end if; i:= i + 1; end loop; if Wn(ti) > Tn then write(‘task_τn_refused’) end if;

Listato 2.1 – Algoritmo per il test di schedulabilità esatta basato sulla zona critica

2.2.3.1 Implementazione nel modello dell’analisi di schedulabilità Come in [2], anche nel nostro sistema è stato implementato un apposito processo real-time di tipo pcg, cui è stato dato ancora il nome di acceptance, dedicato ad eseguire il test di garanzia appena visto per i processi periodici critici garantiti. Esso è caratterizzato, come gli altri task periodici, da un tempo massimo di esecuzione (WCCT) e da un periodo coincidente come al solito con la deadline. Ogni tot unità di tempo, pari al proprio periodo, il modulo di acceptance viene schedulato per l’esecuzione e comincia a concorrere con gli altri task per l’acquisizione della sola CPU non dovendo mai entrare in sezione critica. Acceptance è sempre il primo processo pcg ad essere schedulato e, in quanto il primo, è intrinsecamente garantito anche se ovviamente potrà subire (anche subito) preemption da parte di un task pcg a priorità maggiore. La priorità con cui esegue viene stabilita sempre con la teoria del Rate Monotonic, cioè è inversamente proporzionale al suo periodo. Come vedremo meglio più avanti, durante la sua esecuzione acceptance entra in un stato di attesa in cui aspetta le varie richieste di accettazione da parte dei nuovi processi critici attivati e per ognuna ne calcola la fattibilità di schedulazione ritornando l’esito al task in questione: se accettato, un processo periodico avrà sempre la garanzia di rispettare tutte le sue future deadline, salvo fallimento del sistema. Se invece non vi sono richieste pendenti acceptance rimane nello stato di attesa fino al termine del suo tempo di esecuzione (blocco a tempo unico) la cui durata è fissata a priori e può essere eventualmente cambiata prima dello start-up del sistema applicativo; anche il periodo di acceptance può essere cambiato prima dell’avvio in base alla prontezza con la quale si vuole che esso risponda alle richieste dei processi pcg.

21

D’altronde la scelta dei valori del tempo di esecuzione e del periodo determinano anche la misura dell’occupazione del tempo di CPU da parte del modulo di acceptance ossia il suo fattore di utilizzazione: se si ha bisogno di una elevata prontezza sarà necessario aumentarne il tempo di esecuzione e/o la frequenza, variazioni che però creano l’inconveniente di far crescere l’occupazione del processore da parte di acceptance togliendo così risorse agli altri task; aumentando troppo la prontezza del sistema si arriva al paradosso che acceptance è molto veloce nel dare risposta alle richieste dei processi critici ma questa risposta potrebbe essere troppo spesso negativa in quanto il fattore di utilizzazione U4 del processore è molto alto a causa anche (e magari soprattutto) di acceptance. Si tratta dunque di realizzare un buon trade-off tra elevata prontezza di sistema e bassa utilizzazione di CPU da parte di acceptance (vedi Figura 2.7), compromesso che dovrà essere calcolato di volta in volta in funzione del tipo di applicazione che il sistema deve gestire.

Figura 2.7 – Trade-off tra prontezza di sistema e occupazione di CPU da parte di acceptance

Quello che si vorrebbe è che, finché il fattore di utilizzazione U è basso, acceptance abbia periodo breve in modo da aumentare la velocità di risposta alle richieste dei task pcg i quali avranno del resto un’alta probabilità di essere schedulati proprio perché U è basso. Al contrario, con un fattore di utilizzazione elevato, acceptance dovrebbe avere un periodo più lungo in modo da ridurre la sua occupazione del processore e abbassare conseguentemente il valore di U; inoltre, con un fattore di utilizzazione elevato, anche la probabilità di accettare nuove richieste si riduce e quindi è pertinente che acceptance svolga il suo compito con una frequenza ‘rilassata’. Il processo acceptance specificato soddisfa esattamente questa esigenza: esso è stato dotato di un automatismo che sulla base del fattore di utilizzazione corrente ne varia il periodo all’interno di un range discreto di quattro livelli; al di sopra di prestabilite soglie di U il periodo di acceptance viene incrementato portandolo ad un livello superiore. Tutti i parametri concernenti il valore delle soglie di U in cui avviene l’incremento del periodo e il valore dell’incremento stesso possono essere settati prima dello start-up del sistema in modo da adattarli meglio alle proprie esigenze applicative. Analogamente inoltre, qualora il fattore di utilizzazione scenda al di sotto di queste soglie perché qualche processo pcg è stato terminato (kill), con un procedimento perfettamente speculare il periodo di acceptance viene decrementato. Un tale meccanismo di accettazione dei processi possiede un alto grado di flessibilità realizzando un’analisi di schedulabilità di tipo adattativo; la flessibilità è duplice:

4 Il fattore di utilizzazione U cui ci si riferisce è sempre quello dovuto al workload (carico di lavoro) di acceptance e dei soli processi pcg in quanto questi hanno sempre precedenza sui firm che quindi, ai fini dell’analisi di schedulabilità, è come se non esistessero.

Prontezza di sistema ↑ Occupazione di CPU ↑

Prontezza di sistema ↓ Occupazione di CPU ↓

Periodo ↓ Tempo di esecuzione ↑

Periodo ↑ Tempo di esecuzione ↓

MODULO DI ACCEPTANCE

22

1. Il modulo di acceptance si adatta automaticamente e dinamicamente al carico di lavoro corrente dei task pcg variando il proprio periodo in modo da avere sempre un buon trade-off tra prontezza del sistema e occupazione di CPU.

2. Prima dello start-up del sistema l’utente-progettista può cambiare a suo

piacimento il periodo di partenza e/o il tempo massimo di esecuzione di acceptance nonché i valori delle soglie di U in cui deve scattare l’incremento (o il decremento) del periodo e il valore dell’incremento (o decremento) stesso.

Ma il grado di flessibilità del modulo di acceptance e dell’intero sistema applicativo non è finito qui. Ciò che è stato ulteriormente fatto nasce da considerazioni strettamente pratiche e deriva dalla constatazione che in genere, anche nelle grosse applicazioni, il numero di processi critici è basso rispetto al numero totale di processi nel sistema. In particolare, alcune applicazioni potrebbero avere solamente un set di task critici da schedulare nelle prime fasi di avvio e poi nessun altro task critico, altre invece potrebbero non prevedere affatto task critici: in un simile scenario avere il processo acceptance che ogni tot unità di tempo va in esecuzione per aspettare nessuno e togliere invece tempo di CPU agli altri processi è quanto mai controproducente. Si è pensato allora di dotare il sistema di una funzionalità aggiuntiva che permetta semplicemente ad un utente, in qualunque momento di vita del sistema, di poter disattivare acceptance in modo che non vada più in esecuzione e non occupi inutilmente il processore; nell’eventualità poi che vi sia nuovamente bisogno di effettuare l’analisi di schedulabilità acceptance può essere fatto ripartire con la medesima facilità (per maggiori dettagli vedi la specifica della versione 14 nel capitolo 5). Questo ulteriore meccanismo consente al sistema applicativo – che è stato progettato principalmente con lo scopo di gestire processi critici – di diventare all’occorrenza un sistema più semplice che non effettua analisi di schedulabilità ma si limita a schedulare tutti i task pendenti secondo un criterio best-effort basato su priorità. L’analisi di schedulabilità svolta dal modulo di acceptance è applicata a tutti i processi di tipo pcg, sia a quelli indipendenti che a quelli che entrano in sezione critica; per questi ultimi comunque acceptance adotta un apposito test di garanzia basato sul massimo tempo di blocco che un task può subire: ciò sarà illustrato meglio nel prossimo paragrafo. Per i processi critici indipendenti invece, acceptance esegue un test di garanzia molto potente strutturato in due stadi (RM + GRMS) in modo da massimizzare il numero di task che possono esser schedulati: esso si basa sui teoremi 1 e 2 precedentemente visti ed è riportato schematicamente in Figura 2.8. Più in particolare, quando acceptance riceve una nuova richiesta calcola il nuovo fattore di utilizzazione U che si avrebbe se il processo attivato fosse schedulato. Il primo stadio di analisi, poco oneroso dal punto di vista computazionale, verifica semplicemente che il nuovo valore di U non superi l’upper bound fornitoci dalla teoria del Rate Monotonic: se l’esito è positivo il processo viene schedulato, in caso contrario non si ha il rigetto del processo ma si passa al secondo stadio di analisi. Il secondo stadio di analisi è computazionalmente più oneroso del primo e perciò prima di entrarvi si controlla che il nuovo valore di U sia sotto una soglia massima MAX_U la quale viene stabilita prima dello start-up del sistema sulla base del massimo carico di lavoro che si vuole il sistema sopporti per i processi pcg. Così, se U non è minore di MAX_U, la schedulazione del processo viene subito rifiutata; nel caso opposto invece si entra nel secondo stadio nel quale viene svolta un’analisi basata sulla teoria del GMRS e precisamente viene eseguito l’algoritmo riportato nel Listato 2.1: l’esito di questo ultimo test deciderà la ‘sentenza’ finale sulla schedulabilità del task in questione.

23

Figura 2.8 – Analisi di schedulabilità per processi periodici critici garantiti indipendenti

2.2.4 Gestione delle risorse Nel paragrafo precedente abbiamo discusso della schedulazione di processi indipendenti, in generale però i task possono anche interagire tra loro condividendo ad esempio strutture dati e spazi di indirizzamento in memoria; proprio a tal riguardo il nostro modello applicativo (almeno nella sua versione finale) prevede, come in [2], che qualunque tipo di processo simulato possa accedere a risorse comuni mutuamente esclusive: più precisamente sono state previste otto5 sezioni critiche. Uno dei problemi cruciali che si presenta nell’interazione tra task real-time è dovuto al blocco che essi possono subire durante l’accesso alle risorse comuni; a tal proposito precisiamo che un processo si dice ‘bloccato’ quando è in attesa per l’esecuzione di un 5 Tale valore costante assegnato, come vedremo nel paragrafo 3.1.3 del capitolo 5, all’apposito parametro MAX_SC, è stato ereditato – come del resto anche i valori di altri parametri – direttamente dal modello di riferimento [2] ma può eventualmente essere cambiato, tenendo però presente che il suo cambiamento richiede delle opportune (seppur piccole) modifiche in alcune parti della specifica del sistema applicativo stesso.

SCHEDULED

Rate Monotonic

U ≤ n(2(1/n) –1)

GRMS Algoritmo di

schedulabilità esatta

Wn(ti) = ti

U<MAX_U

NO

YES

YES

YES

NO

NO

REFUSED

Indipendent critic task

MODULO DI ACCEPTANCE

24

task a più bassa priorità mentre un processo in attesa per l’esecuzione di un task con priorità maggiore o uguale non è considerato bloccato ma ‘pronto’. Purtroppo una diretta applicazione di meccanismi classici di sincronizzazione come i semafori, i monitors, i locks o gli Ada rendezvous, nonostante protegga la consistenza della risorsa condivisa, può provocare uno spiacevole fenomeno noto come inversione di priorità. Inversione di priorità L’inversione di priorità è quel fenomeno per cui un processo ad alta priorità viene bloccato da un processo a più bassa priorità per un intervallo di tempo indefinito. Una tipica situazione di questo tipo si può verificare quando due processi tentano di accedere ad una struttura dati condivisa. Al fine di mantenere la consistenza dei dati gli accessi devono essere serializzati: se il task a priorità più alta guadagna l’accesso per primo allora l’ordine prioritario viene rispettato; se invece è il task a più bassa priorità ad entrare per primo nella struttura dati allora il processo ad alta priorità viene bloccato per tutta la durata dell’accesso alla struttura da parte del processo a bassa priorità. D’altra parte il blocco del processo ad alta priorità è inevitabile ed è una diretta conseguenza della mutua esclusione degli accessi necessaria a garantire la consistenza della risorsa condivisa. Purtroppo però il blocco del processo ad alta priorità può essere ulteriormente prolungato dall’intervento di altri task a priorità intermedia che, non dovendo accedere alla risorsa, possono effettuare preemption sul processo a bassa priorità; la durata del blocco allora dipende non solo dalla lunghezza della sezione critica ma anche dall’esecuzione di altri eventuali processi a priorità intermedia che possono inserirsi nel mezzo e ‘passare avanti’ al task ad alta priorità: questo è appunto ciò che si dice ‘inversione di priorità’. L’inversione di priorità crea dei seri problemi nei sistemi real-time poiché compromette la schedulabilità e la prevedibilità del sistema stesso; una durata prolungata del blocco può provocare un time-overflow anche in condizioni di bassa utilizzazione del processore. L’inversione di priorità può essere evitata se si impedisce la preemption sui processi che si trovano all’interno di sezioni critiche; questa soluzione tuttavia può essere appropriata solo nel caso di sezioni critiche molto corte poiché dà luogo a bloccaggi inutili. Ad esempio, un task a bassa priorità dentro una sezione critica molto lunga impedirebbe per lungo tempo l’esecuzione di un processo ad alta priorità anche nel caso in cui questo non usi risorse condivise.Una soluzione più efficiente consiste invece nel regolare l’uso delle strutture dati comuni mediante opportuni protocolli di accesso alle sezioni critiche. Possibili soluzioni Il protocollo di Priority Inheritance [3] offre una soluzione al problema di inversione di priorità causato dalla mutua esclusione tra processi: vengono utilizzati dei semafori logici binari per l’accesso alle sezioni critiche in modo da non consentire l’uso di una risorsa condivisa a più di un task per volta; l’inversione di priorità viene evitata attraverso una modifica dinamica della priorità dei processi che causano il blocco.

• Quando un processo τ1 si blocca all’entrata di una sezione critica trasmette la sua priorità al processo τ2 che la detiene, dunque τ2 esegue la sua sezione critica con una priorità pari alla massima priorità dei processi da esso bloccati: si dice che in sezione critica un processo τ ’eredita’ la più alta priorità dei processi da esso bloccati.

25

• All’uscita della sezione critica il processo τ viene riportato al livello di priorità che aveva prima di entrarvi.

• L’ereditarietà della priorità è transitiva: ad esempio, se il processo τ3 blocca τ2 il

quale a sua volta blocca τ1, allora τ3 eredita la priorità di τ1 attraverso τ2. L’applicazione del protocollo di Priority Inheritance risolve pienamente il problema dell’inversione di priorità ma presenta ancora due problemi rilevanti: il primo è che esso non previene lo stallo (deadlock) tra processi; il secondo è che la durata del blocco, se pur limitata, può essere comunque significativa a causa di un possibile blocco a catena [3]. Così, se un tale protocollo può ancora andar bene per i processi firm non garantiti, non è purtroppo di alcun aiuto per effettuare l’analisi di schedulabilità per quelli critici garantiti: ciò perché, proprio a causa dello stallo e delle catene di bloccaggi, il protocollo non ci fornisce un bound preciso e ristretto sul massimo tempo di blocco che un task può subire. Scartata l’ipotesi di implementare nel nostro modello il Priority Inheritance si è così passati a considerare il protocollo di Priority Ceiling Emulation [4]. Questo protocollo è in realtà una semplificazione del ben più complesso Priority Ceiling che vedremo tra poco; nel Priority Ceiling Emulation ogni volta che un task entra in sezione critica si innalza la sua priorità al valore della più alta priorità (chiamata ceiling) dei processi che possono entrare in quella determinata sezione critica. In questa maniera si ottiene lo scopo di evitare l’inversione di priorità, lo stallo e le catene di bloccaggi avendo imposto però una ‘sgradita’ restrizione: un task τ2, una volta entrato in sezione critica, non può sospendere la sua esecuzione a favore di un task τ1 che, pur non concorrendo per la sezione critica e avendo priorità maggiore di τ2, abbia nel contempo priorità inferiore al ceiling di quella sezione; in pratica, ciò equivale ad avere sezioni critiche non preemptable in un elevato numero di casi. Ottenere così certi vantaggi a scapito di sezioni critiche non preemptable non appare un’ottima soluzione: come è stato detto poc’anzi, una tale soluzione può essere appropriata solo nel caso di sezioni critiche molto corte poiché essa dà luogo a bloccaggi inutili. In applicazioni real-time altamente critiche, con una analisi di schedulabilità molto spinta per massimizzare il numero di processi schedulabili, avere dei bloccaggi inutili rappresenta un limite notevole per la qualità della stessa analisi di schedulabilità e per l’efficienza dell’intero sistema applicativo. Inoltre, tutto lo sforzo svolto per la schedulazione di task critici indipendenti con un test di garanzia supplementare (GRMS) verrebbe vanificato nel caso i processi si sincronizzino su sezioni critiche e questo perché non si ha un buon limite superiore sul tempo di blocco di un processo. La soluzione finale è stata allora quella (come fatto in [2]) di regolare gli accessi alle risorse comuni di sistema mediante l’implementazione nel nostro modello del protocollo di Priority Ceiling [3] il quale, anche se a costo di una maggiore complessità realizzativa rispetto agli altri due, offre senza dubbio tutte le caratteristiche desiderabili.

26

2.2.4.1 Il Protocollo di Priority Ceiling Il protocollo di Priority Ceiling consente di risolvere il problema dell’inversione di priorità tra processi che accedono a sezioni critiche condivise evitando nel contempo sia le condizioni di stallo che le catene di bloccaggi pur mantenendo preemptable le sezioni critiche stesse; dei semafori logici binari regolano l’accesso mutuamente esclusivo alle risorse affinché possa accedervi un solo processo per volta. L’idea di base di questo protocollo è quella di assicurare che, quando un processo τ effettua preemption su una sezione critica di un altro processo ed esegue una propria sezione critica Z, la priorità con cui viene eseguita Z sia più alta di tutte le priorità ereditabili dai task correntemente sospesi in sezioni critiche: se questa condizione non può essere soddisfatta il protocollo impedisce al processo τ di entrare in sezione critica e il task che blocca τ eredità la priorità di τ. Questa idea viene realizzata assegnando a ciascun semaforo un tetto di priorità (detto appunto ceiling) pari alla più alta priorità dei processi che possono usare quel semaforo, quindi si consente ad un processo τ di entrare in sezione critica solo se la sua priorità è strettamente maggiore di tutti i tetti di priorità associati ai semafori correntemente bloccati da task diversi da τ. La definizione formale del protocollo di Priority Ceiling può essere descritta dai seguenti punti:

• Sia τ il processo con priorità più elevata tra i processi pronti per cui τ viene schedulato per l’esecuzione.

• Sia S* il semaforo avente il più alto tetto di priorità fra tutti i semafori occupati

da processi diversi da τ e sia c(S*) il suo ceiling.

• Per entrare in una sezione critica ‘custodita’ dal semaforo S il processo τ deve avere una priorità strettamente maggiore di c(S*) altrimenti viene bloccato: in questo caso si dice che τ è bloccato sul semaforo S* da parte del processo che detiene S*.

• Se il processo τ, entrando in sezione critica, blocca dei processi a priorità più

elevata, allora eredità la priorità Ph corrispondente alla più alta priorità dei task bloccati da τ; quando poi τ esce dalla sezione critica riacquista il suo livello di priorità originale.

• Il meccanismo di ereditarietà della priorità è transitivo.

Il protocollo di Priority Ceiling introduce tre forme di blocco sui processi che tentano di accedere alle sezioni critiche, le prime due comuni anche ai protocolli Priority Inheritance e Priority Ceiling Emulation, la terza invece tipica del Priority Ceiling:

1. direct blocking: si ha quando un processo ad alta priorità tenta di entrare in una sezione critica occupata; è la fondamentale forma di blocco e regola gli accessi alle sezioni critiche in modo che siano mutuamente esclusivi assicurando così la consistenza delle risorse condivise.

27

2. push-through blocking: si ha quando un processo a media priorità τM viene bloccato da un processo a bassa priorità τL che eredita la priorità da un processo ad alta priorità τH; questa forma di blocco viene anche denominata blocco indiretto ed è necessaria per evitare il fenomeno dell’inversione di priorità (cioè che un task ad alta priorità sia ritardato indirettamente da un task a media priorità).

3. ceiling blocking: si ha quando un processo tenta di occupare una sezione critica

che non è occupata da nessun altro processo ma tuttavia viene bloccato poiché la sua priorità non è maggiore del più alto tetto di priorità (ceiling) fra tutti i semafori correntemente occupati; questa forma di blocco è necessaria per evitare catene di bloccaggi e situazioni di stallo.

L’importanza rivestita da questo protocollo consiste, oltre alle caratteristiche appena elencate, nell’introdurre dei tempi di blocco solo ed esclusivamente per quei processi che devono accedere alle sezioni critiche. Sui processi che non accedono a sezioni critiche non si hanno forme di blocco di nessun genere (come ad esempio fa l’Emulation) rendendo così possibile un tipo di analisi di schedulabilità strutturata nel modo visto nel paragrafo 2.2.3.1. In particolare, nel caso si avessero dei tempi di blocco anche per i processi indipendenti, l’algoritmo per il test di schedulabilità esatta non sarebbe più applicabile, ma andrebbe modificato opportunamente tenendo in considerazione i tempi di blocco, il che però provocherebbe uno spaventoso aumento della sua complessità computazionale (un tale algoritmo è ancora in fase di studio e forse non è risolvibile con un tempo di calcolo polinomiale). Un ulteriore ed importante motivo per adottare il protocollo di Priority Ceiling sta nel fatto che esso è in grado di fornire un ben preciso limite superiore sul tempo di blocco di un processo che accede a sezioni critiche ma soprattutto questo upper bound è il più basso che finora si sia riusciti a trovare; la forma di blocco ceiling blocking infatti, oltre ad evitare lo stallo e le catene di bloccaggi, consente di migliorare rispetto ad altri protocolli la condizione peggiore di blocco ottenendo il seguente risultato:

Con il protocollo di Priority Ceiling un processo τ può essere bloccato al massimo per la durata di una sola sezione critica: nel caso peggiore questa sarà la più lunga sezione critica gestita da quei semafori che hanno un ceiling maggiore o uguale alla priorità del processo τ.

2.2.4.2 Analisi di schedulabilità per task pcg ‘dipendenti’ Se i processi periodici critici si sincronizzano su sezioni critiche mutuamente esclusive non è più possibile effettuare l’analisi di schedulabilità vista nel paragrafo 2.2.3.1 a causa dei bloccaggi che questi task possono subire. L’acquisizione e il rilascio delle sezioni critiche mediante l’utilizzo del protocollo di Priority Ceiling fornisce comunque, come già osservato, un bound sul massimo tempo di blocco; ciò è fondamentale per poter realizzare un’analisi di schedulabilità anche per questi task pcg non più indipendenti. Come abbiamo appena visto, il tempo di blocco per un processo τi non può superare la durata della più lunga sezione critica appartenente all’insieme βi che contiene tutte le sezioni critiche gestite da quei semafori il cui tetto di priorità (ceiling) risulta maggiore o uguale della priorità di τi; in pratica, l’insieme βi contiene tutte le sezioni critiche che,

28

secondo le regole del protocollo, possono bloccare il processo τi, anche se esso non deve accedere a tutte queste sezioni critiche. Allora sia Bi il tempo massimo di blocco per il processo τi. Si fa notare che in un insieme di n task periodici ordinati per priorità decrescente si ha sempre Bn = 0 poiché, essendo τn il processo a priorità più bassa, non esiste alcun processo a priorità ancora più bassa che possa bloccare τn. Allo scopo di verificare la schedulabilità del processo τi si devono considerare ora, oltre al fattore di utilizzazione proprio del processo (Ci/Ti) e alla preemption eventualmente causata dai task a più alta priorità (τ1…τi-1), anche gli effetti del blocco causato dai task a più bassa priorità il quale, come illustrato nel paragrafo precedente, può essere di tipo diretto, indiretto o ceiling, ma in ogni caso non può superare il tempo Bi. Se per un processo τi la somma degli effetti dovuti alla preemption, all’utilizzazione del processore ed al blocco non supera il limite imposto dalla teoria del Rate Monotonic, ovvero rispetta la condizione:

)12(11

1−≤++∑

−

=

i

i

i

i

ii

k k

k iTB

TC

TC

allora il processo può essere completato entro la propria deadline. Da ciò segue che un insieme di n task periodici che usino il protocollo di Priority Ceiling possono essere schedulati con la teoria del Rate Monotonic se vale la seguente condizione: Questa condizione di schedulabilità è solo sufficiente; d’altronde, allo stato attuale dell’arte sui sistemi real-time, quando si hanno dei tempi di blocco non è possibile far meglio della teoria del Rate Monotonic. Come già detto infatti, un algoritmo di schedulabilità esatta basato sulla zona critica avrebbe una complessità computazionale troppo elevata: una sua realizzazione e implementazione sarebbe del resto controproducente perché produrrebbe per il modulo di acceptance un alto WCCT e conseguentemente un alto fattore di utilizzazione del processore; così l’enorme sforzo computazionale volto a massimizzare il numero di processi schedulabili sarebbe vanificato dal fatto che, a causa dell’alta occupazione di CPU, si riduce in definitiva la possibilità stessa di schedularli. Nel caso dunque di task pcg che, sincronizzandosi su sezioni critiche possono subire un blocco, il modulo di acceptance svolge un unico test di garanzia basato appunto sul massimo tempo di blocco (vedi Figura 2.9). Osserviamo infine che, se pur accedendo ad una sezione critica un processo non subisce blocco (o perché è quello a più bassa priorità o perché è l’unico ad accedere a sezioni critiche), il modulo di acceptance svolgerà il test di garanzia a due stadi illustrato precedentemente in Figura 2.8.

)12(,1,1

1−≤+≤≤∀ ∑

=

i

i

ii

k k

k iTB

TC

nii

29

Figura 2.9 – Analisi di schedulabilità per processi periodici critici garantiti ‘dipendenti’

Rate Monotonic

)12(,1,1

1−≤+≤≤∀ ∑

=

i

i

ii

k k

k iTB

TC

nii

NO

YES SCHEDULED

MODULO DI ACCEPTANCE

Critic task with

blocking time

REFUSED

30

3. Introduzione allo strumento di specifica formale I-Logix Statemate MAGNUM

3.1 Premessa I progettisti degli attuali sistemi integrati (embedded systems) devono affrontare diversi problemi di sviluppo di non trascurabile difficoltà dovuti all’aumento della complessità dei progetti commissionati, alla presenza di nuove caratteristiche, a specifiche ambigue di progetto e al crescere dei requisiti richiesti. Queste sfide della moderna progettazione spesso superano le capacità organizzative e tecnologiche anche dei più equipaggiati gruppi di lavoro. Ancora più preoccupante è l’allarmante percentuale di sistemi complessi e critici (tra cui quelli real-time) tutt’oggi specificati in un formato testuale; questo metodo di comunicazione non formale né verificabile molto spesso implica costosi cicli aggiuntivi di riprogettazione e di debugging del modello. Numerosi studi al riguardo hanno infatti dimostrato che la correzione di un errore durante la realizzazione effettiva del sistema progettato ha un costo dalle 10 alle 1000 volte maggiore rispetto a quello della stessa correzione effettuata in fase di specifica. La generazione di una specifica formale completa e non ambigua rappresenta comunque solo una parte del problema della progettazione degli attuali sistemi integrati. L’altra faccia della questione è quanto accuratamente le specifiche del progettista riflettono i requisiti commissionati dal cliente-utente; infatti, se da una parte il sistema hardware e software può funzionare correttamente nella pratica, dall’altra il progetto stesso implementato potrebbe non soddisfare pienamente i requisiti di sistema precedentemente forniti. Inoltre nei metodi di progettazione tradizionali gli errori nella specifica sono spesso rilevati solo nelle fasi finali di test e d’integrazione del sistema, implicando così difficili e costose correzioni. E’ proprio in quest’ottica che si inserisce lo strumento Statemate MAGNUM della I-Logix (http://www.ilogix.com) a detta della stessa azienda produttrice “il più completo strumento di modellazione grafica e di simulazione per un rapido sviluppo di sistemi integrati complessi”. Statemate fornisce un collegamento diretto e formale tra i requisiti dell’utente e l’implementazione del sistema hardware e software permettendo al progettista di creare una specifica formale del modello completa, corretta e soprattutto eseguibile. Operando su workstation o PC (in rete o stand-alone) con piattaforma Solaris, Unix o Microsoft Windows NT, Statemate rappresenta un ambiente integrato di progettazione e di sviluppo potente, rigoroso e affidabile che permette di creare, tramite appositi formalismi sia grafici che testuali, una specifica visuale che implementa in modo chiaro e preciso le funzionalità richieste e il comportamento caratteristico del sistema da modellare. La specifica realizzata può essere anche animata tramite una simulazione grafica così da permettere al progettista la verifica formale di tutti gli execution scenarios rilevanti analizzando se il comportamento dinamico del sistema e le interazioni tra le sue componenti sono (formalmente) complete, coerenti e corrette. Tali scenari di esecuzione del modello possono essere eventualmente registrati e inclusi in piani di test eseguiti

31

successivamente sul sistema integrato per verificare la corrispondenza tra il modello teorico specificato e il sistema reale effettivamente implementato. Infine, la specifica eseguibile è anche utilizzata per comunicare con il committente o con l’utente finale del sistema e per verificare a priori la corrispondenza tra i requisiti richiesti e le specifiche formalizzate dal progettista, rilevando e correggendo per tempo eventuali errori dovuti all’ambiguità o alla cattiva interpretazione dei requisiti stessi. Complessi embedded systems in campo militare, aereospaziale, automobilistico, ferroviario e medico sono stati specificati usando Statemate MAGNUM ormai giunto alla versione 3.1, anche se quella utilizzata per il nostro progetto è la versione 2.1 sotto Microsoft Windows NT1.

3.2 Il Tool-Set di Statemate Statemate MAGNUM (d’ora in avanti più brevemente Statemate) permette di specificare rapidamente e validare in modo formale sistemi integrati anche molto complessi utilizzando, come vedremo meglio in seguito, un’unica combinazione (vedi il Tool-Set in Figura 3.1) di appositi linguaggi formali di modellazione grafica (Activity-Charts, StateCharts e Module Charts), di comodi strumenti testuali e visuali per la simulazione batch o interattiva (Analysis), di generazione automatica del codice (Code Synthesis) e della documentazione (Documentation) e di definizione di piani di test per la verifica formale del modello, integrando le seguenti caratteristiche: • validazione del comportamento del sistema già nelle prime fasi del processo di

specifica • memorizzazione degli scenari di test durante l’esecuzione simulata • rilevazione e correzione preventiva di errori di specifica prima dell’effettiva

implementazione del modello • collaborazione fattiva tra i progettisti, gli sviluppatori e gli utenti finali del sistema

durante tutte le fasi di progetto • comprensione facilitata delle operazioni eseguite grazie all’animazione grafica del

modello durante la simulazione • generazione di una specifica eseguibile del sistema • prototipizzazione rapida del sistema tramite prototipi virtuali o fisici implementati,

mediante la generazione automatica del codice, in diversi linguaggi di programmazione, tra cui Ada e C (eventualmente utilizzando l’ambiente integrato di sviluppo visuale real-time Rhapsody [13] della stessa I-Logix)

• generazione automatica completa, consistente e formale della documentazione del progetto (project reports)

• riusabilità e standardizzazione delle specifiche di sistema all’interno del gruppo di lavoro o della stessa azienda

• riduzione dei costi e dei tempi di sviluppo di oltre il 30% ammortizzando il costo iniziale dello strumento entro i primi sei mesi di utilizzo.

1 Più precisamente, il pacchetto (con licenza temporanea) è stato installato su PC stand-alone con CPU AMD a 800 Mhz, 256 MB di RAM e sistema operativo Microsoft Windows 2000 (NT 5.0) e gira in emulazione XWindows su server XVision.

32

Figura 3.1 – Statemate MAGNUM Tool-Set

Seguendo l’approccio alla modellazione illustrato nella guida di riferimento principale dello Statemate [1] e da noi adottato in gran parte, per una corretta e completa definizione formale del modello è necessario innanzitutto inserire tutte le informazioni rilevanti per il sistema tramite gli appositi Editors forniti dal pacchetto: i tre tipi di Charts (Graphic Editors) e i Panels grafici (Panel Editor), il Data Dictionary (DataDict Browser) e il Global Definition Set (GDS Editor) testuali (vedi Figura 3.2).

Figura 3.2 – Statemate Main Menu

In ogni caso il Data Entry prevede un controllo rigoroso e automatico dei tipi e della sintassi in-line e un built-in test (Check Model) della consistenza (coerenza), della completezza e della correttezza dei vari elementi del modello, come vedremo meglio nell’ultimo capitolo; inoltre, durante la realizzazione del sistema il progettista può direttamente collegare i requisiti testuali originari alle rispettive componenti della specifica: questi links possono essere poi usati per generare i requirement traceability (RT) reports. In Statemate sono anche previsti strumenti appositi per il querying e il reperimento delle informazioni dal repository del progetto attivo (Workarea Browser, Components Browser, Databank Browser e DataDict Browser) tramite opportuni

33

reports in formato predefinito e comode funzionalità per la generazione automatica e personalizzata della documentazione (Documentor). E’ inoltre prevista la possibilità di eseguire, debuggare e analizzare il modello risultante ed eventualmente di generare il codice corrispondente per la sua effettiva implementazione software e/o hardware. Utilizzando il Simulation Tool di Statemate il modello specificato può essere eseguito passo-passo in modalità interattiva (on-line) o batch (off-line); in entrambi i casi le attività e gli stati correntemente attivi sono via via evidenziati con appositi colori, producendo un’accattivante animazione dei diagrammi di transizione di stato. E’ anche possibile simulare il sistema in base a condizioni casuali e in situazioni più o meno tipiche memorizzando all’occorrenza i risultati ottenuti per poterli riutilizzare e analizzare in seguito. Un’importante precisazione da fare riguardo la simulazione è la possibilità di eseguire solo una parte del modello a patto che tale parte sia sintatticamente valida e corretta; ciò implica che non è necessario aspettare la specifica completa dell’intero modello per poter effettuare una simulazione valida, ma è possibile eseguire e analizzare anche un modello parziale e incompleto alla ricerca preventiva di eventuali errori d’implementazione. Inoltre è possibile collegare porzioni di codice sorgente esterno al modello per completare o implementare processi, funzioni e procedure non (ancora) specificate, per produrre ‘stimoli’ esterni o per elaborare on-line i risultati ottenuti; questa architettura aperta permette a Statemate, pur con le dovute limitazioni, di interfacciarsi con altri strumenti simili. Oltre all’analisi statica, Statemate prevede anche diversi test dinamici indispensabili per analizzare proprietà dinamiche cruciali del modello come la raggiungibilità di una particolare situazione a partire da un determinato stato; questi test sono effettuati dallo strumento utilizzando un particolare tipo di esecuzione esaustiva degli scenari. Una volta che il modello è stato costruito, eseguito e analizzato completamente dal progettista, Statemate può essere opportunamente configurato per tradurre automaticamente la specifica formale in un codice sorgente tipico dei linguaggi di programmazione ad alto livello; questo processo di traduzione corrisponde in definitiva alla compilazione di un programma tradizionale (scritto ad esempio in Pascal) in linguaggio macchina, come del resto l’esecuzione simulata del modello è analoga alla diretta interpretazione del programma stesso. Attualmente nella versione 2.1 è supportata la generazione automatica del codice C e Ada; esiste una variante dello Statemate che supporta anche la traduzione della specifica in linguaggi di descrizione hardware come il VHDL e il Verilog. L’eventuale codice esterno aggiunto dal progettista (ad esempio, per le attività del sistema o per i moduli di basso livello di interfaccia hardware) può comunque essere opportunamente linkato con il codice generato producendo una versione completa e funzionante del sistema. Il codice risultante è spesso denominato prototipale in quanto generato automaticamente solo sulla base delle decisioni di progetto prese durante una prima fase (di solito non definitiva) di preparazione del modello teorico e per questo motivo potrebbe non essere efficiente e ottimizzato come il codice della versione finale, anche se risulterà in ogni caso più veloce nell’esecuzione rispetto alla simulazione (proprio come il codice compilato è più veloce del corrispondente codice interpretato) e magari già soddisfacente per alcuni tipi di sistema. Uno dei principali usi del codice generato è l’osservazione del comportamento del modello in un contesto molto simile a quello del suo ambiente finale; il codice può essere eseguito nell’ambiente reale del sistema oppure in una sua versione simulata. Statemate permette inoltre di costruire una versione software dell’interfaccia utente del sistema finale la quale potrà essere attivata e gestita tramite il codice generato stesso; la configurazione di sistema risultante potrà, ad esempio, essere utilizzata dal committente o dal cliente finale per verificare il funzionamento del modello direttamente sul campo.

34

3.3 La modellazione di sistemi reattivi L’approccio alla modellazione caratteristico di Statemate è comunque particolarmente adatto alla specifica dei cosiddetti ‘sistemi reattivi’ (reactive systems) il cui comportamento può risultare anche molto complesso, implicando un processo di specifica spesso difficile e non esente da errori. A tal proposito bisogna osservare che la maggior parte dei sistemi real-time – che tra l’altro rappresentano proprio la tipologia di sistemi oggetto della nostra specifica – sono intrinsecamente reattivi.

3.3.1 La natura dei sistemi reattivi Un tipico sistema reattivo presenta le seguenti peculiari caratteristiche: • Interagisce continuamente con il suo ambiente (esterno) attraverso appositi segnali

di ingresso e/o uscita che possono essere continui o discreti (nel tempo) e che sono spesso, contrariamente agli inputs e agli outputs dei sistemi cosiddetti trasfomazionali2, di tipo asincrono, ossia i loro valori possono essere usati o aggiornati arbitrariamente in ogni istante di tempo.

• Deve essere in grado di rispondere a segnali di interruzione, ossia eventi (di sistema)

ad alta priorità, anche quando è occupato in altri processi. • Le sue operazioni e le sue reazioni ai segnali d’ingresso spesso sono soggette a

requisiti temporali alquanto stringenti (proprio come un sistema in tempo reale). • Presenta numerosi e diversi possibili scenari di esecuzione in base alla modalità

operazionale corrente, ai valori attuali dei dati e al suo stato precedente. • Il suo comportamento dinamico spesso dipende dalla complessa interazione di

molteplici processi concorrenti. Classici esempi reali di sistemi reattivi sono i sistemi interattivi on-line (come i sistemi automatici per la gestione degli sportelli Bancomat o per le prenotazioni aeree), i sistemi real-time integrati (come i sistemi per l’industria aeronautica, ferroviaria o delle telecomunicazioni) e quelli di controllo (come i sistemi utilizzati in campo chimico, militare, aerospaziale e nell’automazione industriale). Un semplice ma significativo esempio di sistema di tipo reattivo che presenta molte delle caratteristiche precedentemente menzionate – e che tra l’altro è stato utilizzato per scopi didattici in modo ricorrente nella guida di riferimento principale di Statemate [1] per illustrare efficacemente i concetti e le proprietà principali dei linguaggi di modellazione presenti nello strumento – è riportato schematicamente in Figura 3.3.

2 In un sistema trasformazionale la temporizzazione relativa ai segnali di ingresso e di uscita è spesso matematicamente o almeno statisticamente determinabile: il sistema ripetutamente attende l’arrivo di tutti gli input rilevanti, elabora i dati ricevuti e alla fine dell’elaborazione genera i risultati in uscita.

35

Figura 3.3 – Un esempio di sistema reattivo: l’Early Warning System (EWS)

3.3.2 Le tre ‘viste’ nella modellazione di un sistema reattivo Costruire un modello di un sistema – non necessariamente reattivo – può essere in definitiva considerato come una traduzione formale di idee e descrizioni informali (magari espresse in linguaggio naturale) in uno schema organico, corretto e completo utilizzando una terminologia predefinita e concetti ben definiti. Secondo l’approccio alla modellazione tipico di Statemate, le descrizioni utilizzate per ‘catturare’ le specifiche di un sistema reattivo sono organizzate in tre cosiddette viste distinte ma collegate tra loro: l’aspetto funzionale, quello comportamentale (o dinamico) e quello strutturale (vedi lo schema riportato in Figura 3.4): • La vista funzionale ‘cattura’ il what del modello: essa descrive tutte le funzionalità

(capabilities) e i processi del sistema, ossia le cosiddette attività, inclusi i segnali di input e di output e il flusso di informazioni scambiato dal sistema con il suo ambiente esterno o tra le internal activities stesse (vedi Figura 3.6).

• La vista comportamentale (o dinamica) ‘cattura’ invece il when del modello: essa

descrive il comportamento del sistema nel tempo, ossia la dinamica, il controllo (attivazione, sospensione e terminazione) e la temporizzazione delle attività e dei flussi informativi della vista funzionale tramite appositi stati, condizioni, eventi (responsabili delle transizioni di stato) e corrispondenti azioni (vedi Figura 3.7), rispondendo nel contempo a tutte le questioni inerenti la causalità, l’esecuzione concorrente e la sincronizzazione tra le varie componenti del sistema. Esiste dunque uno stretto legame tra l’aspetto funzionale e quello comportamentale: se da una parte infatti le attività e i flussi di dati necessitano di un opportuno controllo per funzionare dinamicamente, dall’altra è pur vero che l’aspetto comportamentale del sistema sarebbe fine a se stesso se non avesse nulla da controllare; in pratica quindi ciascuna attività della vista funzionale può essere corredata da una corrispondente descrizione dinamica della vista comportamentale, la cui funzione è in definitiva quella di controllare le componenti interne dell’attività stessa, come le sue sotto-attività e i flussi informativi scambiati (vedi Figura 3.12).

36

• La vista strutturale infine ‘cattura’ l’how del modello: essa descrive i sotto-sistemi, i moduli (blocchi) e gli oggetti che compongono il sistema reale, incluse le comunicazioni tra di essi (vedi Figura 3.10). Mentre i primi due aspetti costituiscono il modello concettuale del sistema, la vista strutturale ne rappresenta il modello fisico (vedi Figura 3.4) dal momento che riguarda gli aspetti più pratici dell’implementazione del sistema; inoltre, come diretta conseguenza di ciò, il modello concettuale solitamente comprende termini e nozioni mutuati dal dominio del problema, mentre il modello fisico è più legato al dominio della soluzione.

Figura 3.4 – Le tre viste del modello nell’approccio Statemate

Per concludere, la principale connessione tra il modello concettuale e quello fisico (che comunque non riguarda il nostro progetto) si traduce nello specificare i moduli della vista strutturale che effettivamente implementano le attività della vista funzionale (vedi Figura 3.12).

functional view

capabilities & flow of information

What behavioral view

control & timing

When

Conceptual Model

Physical Model structural view

modules/objects & communication links

How

37

3.4 I linguaggi di modellazione di Statemate Le tre viste caratteristiche di un sistema reattivo illustrate precedentemente, nell’approccio di Statemate alla modellazione sono descritte utilizzando tre appositi linguaggi grafici: le Activity-Charts per l’aspetto funzionale, le StateCharts per quello comportamentale (o dinamico) e le Module-Charts per quello strutturale; per informazioni testuali aggiuntive relative ai tre aspetti del modello e alle loro interrelazioni sono invece previsti il Data Dictionary e il Global Definition Set. Anche se le idee che stanno alla base di questi tre formalismi visuali sono state mutuate, come vedremo, da altri linguaggi di modellazione già esistenti – come diagrammi di flusso, diagrammi di transizione di stato, data-dictionaries e mini-specs – i tre linguaggi includono diverse estensioni che ne aumentano l’espressività semplificando nel contempo la modellazione stessa; oltre a ciò, tutti e tre i linguaggi presentano una rigorosa e precisa semantica grazie alla quale la specifica formale del modello può essere direttamente eseguita o tradotta in altri formalismi eseguibili come il codice sorgente C o Ada. Ribadiamo infatti che, allo scopo di assistere gli sviluppatori di sistemi nella cruciale fase di specifica formale del modello, tutti i linguaggi di modellazione di Statemate sono stati progettati tenendo conto di quattro fondamentali caratteristiche: • Chiarezza: gli elementi del modello sono, per quanto possibile, rappresentati

graficamente; ad esempio, figure rettangolari (box) annidate sono utilizzate per rappresentare la gerarchia esistente tra le varie componenti mentre apposite frecce rappresentano flussi di dati o di controllo (vedi Figura 3.6).

• Precisione: tutti i formalismi visuali disponibili nel pacchetto hanno una ben

definita sintassi e una semantica rigorosa, quasi matematica, prerequisiti essenziali per poter effettuare una valida e significativa analisi della specifica.

• Espressività: il set di linguaggi gode del potere espressivo necessario per modellare

in modo esauriente tutti gli aspetti rilevanti di un sistema, in particolare quelli funzionali, dinamici e strutturali (vedi ancora Figura 3.4).

• Eseguibilità: la semantica comportamentale dei linguaggi di specifica, come più

volte sottolineato, è sufficientemente dettagliata e formale da permettere di eseguire direttamente il modello (come un programma software interpretato) e/o di tradurlo automaticamente in codice sorgente compilabile ed eseguibile per scopi implementativi, di simulazione o di prototipizzazione.

Nei prossimi paragrafi verranno descritti separatamente i tre linguaggi di modellazione (anche se nel nostro progetto sono stati utilizzati solo i primi due: le Activity-Charts e le StateCharts) e le loro principali interconnessioni; bisogna comunque osservare che l’intuitivo stile visuale generale e molte delle convenzioni e delle regole sintattiche adottate accomunano fortemente i tre formalismi grafici.

38

3.4.1 Activity-Charts Le Activity-Charts possono essere considerate in pratica dei diagrammi di flusso a più livelli (multi-level data-flow diagrams) tramite i quali è possibile modellare formalmente tutte le funzioni o funzionalità (dette appunto attività) e i dati informativi (data-stores) del sistema, organizzandoli in un’apposita gerarchia (rappresentata graficamente dall’incapsulazione multi-livello delle Charts stesse) e connettendoli attraverso opportuni flussi d’informazione (vedi l’esempio in Figura 3.6). In Statemate questi flussi informativi (info-flow lines) sono stati differenziati, anche se solo da un punto di vista grafico di rappresentazione della freccia, in flussi di dati (linea continua) e in flussi di controllo (linea tratteggiata). Sono disponibili inoltre diversi tipi di attività (data-store, basic, non-basic, internal, external e control activity) e di connettori grafici con relativa semantica ben definita (vedi Figura 3.5 e l’help on-line per maggiori dettagli).

Figura 3.5 – Elementi grafici dell’Activity-Charts Editor

Infine, in aggiunta alle informazioni puramente grafiche, ciascun elemento della descrizione formale del modello ha una sua corrispondente ‘voce’ (entry) nel Data Dictionary contenente eventuali informazioni non grafiche (testuali) relative all’elemento stesso; più in particolare, un’activity entry contiene il nome dell’attività referenziata, il nome della Chart in cui è definita, il tipo di terminazione (che analizzeremo in dettaglio nel paragrafo 1 del capitolo 6) ed eventuali campi nei quali è possibile specificare in modo formale (mini-spec) o informale (long description) opportune descrizioni testuali delle funzioni implementate dall’attività in questione.

39

Figura 3.6 – Esempio3 di activities, data-stores e info-flow lines

3.4.2 StateCharts Le StateCharts rappresentano invece un’estensione dei classici diagrammi di transizione di stato (macchine a stati finiti) permettendo stati multi-livello organizzati e decomposti in modalità or/and e quindi una comoda specifica dell’incapsulamento (vedi Figura 3.7) e della concorrenza (vedi Figura 3.8) degli stati stessi. Le StateCharts Statemate prevedono inoltre un meccanismo di comunicazione (sincrono o asincrono) di tipo broadcast, operatori di conteggio (timeout event) e di ritardo (scheduled action) per la gestione della sincronizzazione e delle informazioni temporali e opportuni connettori per specificare particolari transizioni di stato che dipendono dalle condizioni (dette guardie) o dalla storia (history) della dinamica del sistema (vedi i simboli tondi contenenti le lettere C, S, H e H+ riportati in Figura 3.9 che rappresentano rispettivamente un Condition, uno Switch, un History e un Deep-History Connector): tutto ciò sarà comunque spiegato meglio nei capitoli successivi. La semantica semplice ma rigorosa della coppia event (trigger)/action che sta alla base del comportamento dinamico delle StateCharts con tutte le sue implicazioni concettuali e temporali sarà anch’essa discussa in modo approfondito più avanti e precisamente nei paragrafi 2.3 dei capitoli 4 e 6.

3 L’esempio riportato in figura rappresenta lo schema completo (top-level activity system_grms) del modello applicativo del semplice sistema real-time specificato nella versione 7 del presente lavoro: i box rettangolari rappresentano le varie attività, quelli parzialmente tratteggiati i data-stores e le frecce continue i flussi informativi tra le attività stesse.

40

Figura 3.7 – Esempio4 di StateChart (or-states)

Infine, analogamente alle Activity-Charts, ciascun elemento di una StateChart ha una corrispondente entry (voce) nel Data Dictionary che contiene eventuali informazioni testuali aggiuntive relative all’elemento stesso, come ad esempio un evento composto (compound event) definito da un’espressione formata da più eventi.

4 L’esempio riportato in figura rappresenta la (Generic) StateChart relativa alla specifica dei processi real-time simulati di tipo pcg (periodico critico garantito) implementata nella versione 15 del presente lavoro e che analizzeremo in dettaglio nel paragrafo 3 del capitolo 5: anticipiamo solo che gli stati di una stessa StateChart sono tra loro mutuamente esclusivi (se si è in uno stato non si può essere in nessuno degli altri) e che il simbolo @ indica che il box (stato) in questione è collegato ad un’altra StateChart (off-page Chart) di livello inferiore nella gerarchia delle Carte del modello.

41

Figura 3.8 – Esempio5 di StateChart (and-states)

Figura 3.9 – Elementi grafici dello StateCharts Editor

5 Nell’esempio in figura è stata riportata la StateChart che rappresenta la specifica del processo Clock Manager per la gestione del tempo nel nostro modello applicativo e che verrà illustrata dettagliatamente nel paragrafo 3.1 del capitolo seguente: in questa sede ci limitiamo solo a precisare che la linea tratteggiata serve a dividere la StateChart in questione in due StateCharts concorrenti (and-states).

42

3.4.3 Module-Charts Una Module-Chart (non utilizzata nel nostro progetto) può essere vista come un particolare tipo di diagramma di flusso a blocchi; questi ultimi tipi di diagrammi sono utilizzati per descrivere e modellare formalmente i vari moduli strutturali che costituiscono l’implementazione effettiva del sistema e la sua organizzazione in blocchi hardware e/o software con le loro componenti interne e le rispettive interrelazioni (vedi l’esempio in Figura 3.10).

Figura 3.10 – Esempio6 di Module-Chart

Come nel caso delle attività, i moduli possono essere di vari tipi (internal, environment, top e sub-modules), collegati tra loro da opportuni segnali di comunicazione (vedi Figura 3.11 e l’help on-line per maggiori dettagli) ed eventualmente organizzati in una gerarchia tramite incapsulamento.

Figura 3.11 – Elementi grafici del Module-Charts Editor

Come nei primi due linguaggi, tutti gli elementi di una Module-Chart hanno una corrispondente voce (entry) nel Data Dictionary per poter specificare eventuali informazioni testuali aggiuntive relative alla componente stessa. 6 Nell’esempio in figura è stato riportato il modulo operativo centrale di controllo relativo al semplice sistema di allarme illustrato in Figura 3.3 e tratto dalla guida principale di riferimento di Statemate [1].

43

3.4.4 Relazioni tra i tre linguaggi Le relazioni esistenti tra i tre aspetti o viste fondamentali del modello si traducono più o meno direttamente in corrispondenti connessioni tra i tre tipi di linguaggio (Charts) illustrati (vedi Figura 3.12); la maggior parte di questi collegamenti sono definiti nel Data Dictionary e servono per unire insieme le varie parti componenti del sistema ottenendo così un modello completo, corretto e consistente del sistema stesso.

Figura 3.12 – Relazioni tra i tre tipi di Charts

La principale relazione tra la vista funzionale e quella comportamentale si traduce nel fatto che le StateCharts, come già accennato, servono a descrivere il comportamento dinamico interno delle Activity-Charts controllandone le eventuali sub-activities; per questo motivo in Statemate a ciascuna control-activity di un’attività viene automaticamente associata un’apposita StateChart tramite il simbolo di off-page Chart @ (vedi ad esempio @PROC_GEN e @PROC_ACCEPTANCE in Figura 3.6). Un’altra relazione tra Activity-Charts e StateCharts si ha nel caso in cui un’attività è stata definita nel Data Dictionary entry di uno stato come attiva durante la permanenza del sistema nello stato stesso. Esistono inoltre diversi comandi e controlli per gestire direttamente o riferirsi esplicitamente ad una attività all’interno delle StateCharts, come ad esempio l’azione start(A) o l’evento stopped(A) per comandare la partenza di un’attività o controllarne la sua terminazione (per maggiori dettagli si rimanda ancora una volta al paragrafo 2.3 del capitolo 4). La relazione esistente tra l’aspetto concettuale (functional e behavioral views) e quello fisico (structural view) del modello specificato corrisponde invece al collegamento tra le Activity-Charts e le Module-Charts; tale link può consistere nello specificare quale modulo implementa una data attività o, viceversa, quale attività descrive in dettaglio le funzionalità di un determinato modulo: in entrambi i casi l’associazione viene specificata nella Data Dictionary entry dell’elemento in questione.

44

3.4.5 Gestione di sistemi su larga scala L’approccio metodologico alla modellazione e alla progettazione tipico di Statemate prevede anche lo sviluppo di sistemi grandi e complessi i quali presentano notevoli quantità di informazioni, vari livelli di dettaglio e numerose componenti che si possono ripetere in diverse parti del modello. Questi sistemi ‘a larga scala’ sono spesso sviluppati da distinti gruppi di lavoro ma i linguaggi formali di Statemate ne supportano e ne semplificano la progettazione anche da parte di un unico team. Sebbene una singola chart può potenzialmente rappresentare una gerarchia multi-livello di elementi anche molto complessa è comunque sconsigliabile abusare di questa possibilità quando il modello supera una certa dimensione. E’ proprio in questi casi che le potenzialità espressive dei linguaggi di Statemate vengono in aiuto al progettista permettendo di suddividere le chart di gerarchia complessa in più carte separate (vedi l’esempio in Figura 3.13, in cui una cosiddetta off-page chart è utilizzata per descrivere il contenuto dell’attività A preceduta dall’apposito simbolo @).

Figura 3.13 – Splitting-up e off-page chart

Una questione correlata alle off-page charts riguarda il meccanismo del copy&paste di charts con relativa visibilità e mascheramento delle informazioni secondo precise regole di risoluzione degli elementi del modello, analogamente a come accade per l’utilizzo delle variabili nei tradizionali linguaggi di programmazione. A tal riguardo è anche possibile specificare elementi globali condivisi definendoli nell’apposito Global Definition Set (GDS) del modello. Un’altra potente caratteristica dei linguaggi di modellazione dello Statemate è quella delle cosiddette Generic Charts, particolari carte parametriche che permettono il riuso di parti della specifica; una Generic Chart rende possibile rappresentare componenti comuni e ripetute del modello con una singola carta che può essere istanziata più volte e in più parti del sistema, similmente a come avviene per le procedure in un classico linguaggio di programmazione o per gli oggetti nella OOP. Le carte generiche saranno comunque analizzate più in dettaglio nel paragrafo 2.1 del capitolo seguente. Un’ultima caratteristica di Statemate che contribuisce alla riusabilità della specifica è quella degli User-Defined Types (UDT), particolari tipi di dato definibili direttamente dall’utente e riutilizzabili per definire facilmente altri elementi del modello.

45

4. Confronto tra specifica in SDL e specifica in Statemate

4.1 Studio di fattibilità del porting Come già accennato nell’introduzione al lavoro, lo scopo della presente tesi è in definitiva quello di specificare, verificare e simulare il modello di un sistema applicativo per la gestione di processi real-time (vedi il capitolo 2) utilizzando i linguaggi di modellazione presenti nel software industriale Statemate MAGNUM v2.1 della I-Logix ed illustrati nel terzo capitolo. Innanzitutto bisogna premettere che la prima fase di specifica formale prevede uno studio di fattibilità; prima di affrontare la vera e propria realizzazione del modello è necessario analizzare in modo più approfondito le caratteristiche, le potenzialità e l’espressività dei diversi linguaggi forniti dallo strumento Statemate: Module-Charts, Activity-Charts, StateCharts, Generic Charts e Textual Expression Language. In particolare tale analisi ha un fondamentale linguaggio di riferimento e di confronto, l’SDL (Specification and Description Language: vedi [5] e [6]), con il quale lo stesso modello, come più volte detto, è stato già specificato in una precedente tesi [2], oltre ovviamente a dover tenere conto dei requisiti temporali tipici di un sistema real-time (cfr. il capitolo 1). Alla luce di questi due aspetti, sorge la necessità di un linguaggio adatto alla descrizione, alla modellazione e alla decomposizione funzionale (i processi e i segnali SDL) e comportamentale (gli stati e le transizioni SDL) del sistema e che preveda inoltre delle specifiche funzioni per la gestione esplicita del tempo (i timer e il now SDL). Dallo studio del manuale principale di riferimento dello Statemate [1] si evince innanzitutto che, nonostante gli strumenti di specifica formale forniti dallo strumento siano molto potenti, rigorosi e flessibili, l’approccio alla modellazione è sostanzialmente diverso da quello previsto dallo standard SDL/SDT mentre è più simile a quello dello standard UML (Unified Modeling Language: vedi [25] e [26]) che ritroviamo tra l’altro nel Rhapsody, un altro strumento di specifica formale della I-Logix che può essere considerato un ‘fratello minore’ di Statemate, meno potente ma più commerciale ed user-friendly [13]. In altre parole, mentre un modello realizzato con Rhapsody o eventualmente con VisualSTATE (uno strumento commerciale della IAR Systems per la specifica formale di applicazioni real-time embedded: vedi [14] e [15]) potrebbe essere importato in Statemate senza eccessive modifiche concettuali e semantiche (ma non sintattiche), il porting in Statemate di un modello real-time specificato con SDL non può essere effettuato altrettanto facilmente senza implicare radicali e sostanziali trasformazioni. Questo perché, anche se tutte le entità SDL possono avere un più o meno diretto corrispettivo in Statemate, sono sostanzialmente diverse le modalità di comunicazione, di sincronizzazione temporale e di istanziazione dei succitati processi SDL. Nel modello SDL [2] il sistema principale, chiamato system GRMS (Generalized Rate Monotonic Scheduling), contiene al suo interno i due blocchi (blocks) PROCESSES e KERNEL SIMULATOR, che a loro volta, come in un gioco di scatole cinesi, contengono dei processi (processes) che comunicano tra di loro tramite opportuni segnali (signals) scambiati su appositi canali di comunicazione (signal routes): vedi l’esempio in Figura 4.1.

46

Figura 4.1 – Vista strutturale di un sistema SDL

In particolare, per ogni processo è specificato il numero minimo e il numero massimo di istanze contemporanee, ognuna delle quali è caratterizzata dallo stesso modello interno di comportamento dinamico; tale comportamento è specificato tramite macchine a stati finiti estese [17] rappresentate tramite diagrammi di transizione di stato con una particolare notazione simbolica. Questi diagrammi possono contenere, oltre alla dichiarazione e inizializzazione (testuali) delle variabili locali, richiami a procedure grafiche (anche annidate) espresse da diagrammi di flusso a blocchi (per una descrizione dettagliata della simbologia grafica di SDL-GR si rimanda al capitolo relativo in [2]). Tale approccio può essere ricondotto solo con opportuni artifizi e con certe limitazioni nell’ambiente di sviluppo dello Statemate, ed è questa in definitiva la principale difficoltà di svolgimento della presente tesi. In particolare, escludendo l’uso delle Module-Charts (utili solo per una descrizione strutturale object-oriented e una progettazione ad alto-livello del modello fisico), le Activity-Charts e le StateCharts, pur con le dovute differenze, sembrano le migliori ed uniche ‘candidate’ per la realizzazione di un modello specificato formalmente in SDL. Infatti, mentre la vista strutturale a moduli si occupa esplicitamente del ‘come’ un modello è progettato fisicamente (architettura hardware o software), la vista concettuale riguarda invece gli aspetti più propriamente funzionali (funzionalità e flusso di informazioni) e comportamentali (controllo e temporizzazione) del modello, cioè il ‘cosa’ e il ‘quando’ della specifica formale (vedi Figura 3.4). Questi due aspetti sono implementati in Statemate rispettivamente con il linguaggio visuale delle Activity-Charts e delle StateCharts, opportunamente collegate tra loro e con il Textual Expression Language (cfr. capitolo 3). Alla luce di queste considerazioni i processi ‘statici’ SDL possono essere dunque visti come Top-Level Activities in una decomposizione funzionale multi-livello del modello che tenga conto dei signal routes tra i processi SDL tramite opportune information-flows lines di collegamento tra le attività, mentre il comportamento dinamico interno trova la sua naturale modellazione nelle StateCharts che costituiscono le Control-Activities delle rispettive attività (vedi Figura 3.12). Per quanto riguarda le procedure definite nel modello SDL esse possono essere implementate direttamente come subroutines Statemate testuali (function, procedure o task a seconda del tipo di parametri) utilizzando uno dei quattro linguaggi di programmazione riconosciuti dallo strumento (K&R C, ANSI C, ADA e Statemate Action Language, un intuitivo linguaggio di pseudo-codifica) oppure come funzioni e procedure grafiche usando le cosiddette Procedural StateCharts, sempre comunque tenendo conto delle rispettive proprietà e limitazioni. D’altro canto la maggior parte dei tipi astratti di dato SDL, ossia delle variabili e delle strutture dati (sorts) definite nel linguaggio SDL, può essere utilizzata quasi

47

direttamente in Statemate usando altri tre strumenti forniti dal programma: il Data Dictionary, che caratterizza ogni entità o elemento in Statemate, e il Global Definition Set, usato principalmente nelle Generic Charts e per la riusabilità di tipi definiti dall’utente. Le operazioni definite sui tipi astratti di dato potranno essere realizzate invece per mezzo del Textual Expression Language che consente la manipolazione – tramite opportune azioni – di eventi, condizioni e dati in genere. Quest’ultimi in Statemate possono essere di vari tipi (caratterizzati a loro volta da un modo d’uso contestuale: variable, compound, alias o constant): predefiniti (integer, real, string, bit e bit-array), strutturati (array, record, queue, union ed enumerated type), user-defined type (UDT) o particolari combinazioni dei precedenti. Nello schema fin qui delineato di trasformazione di specifiche SDL in specifiche Statemate restano comunque tre fondamentali questioni da risolvere: 1. La prima, più propriamente pragmatica, si riferisce allo studio dell’approccio più

adatto per implementare in Statemate quei processi SDL che possono avere più di un’istanza concorrente.

2. La seconda invece concerne l’implementazione di un meccanismo interno di Inter-

Process Communication (IPC) asincrono che in SDL è basato su:

• SEGNALI di comunicazione, con eventuali parametri • SIGNAL ROUTES e CANALI per il trasporto dei segnali • CODE: ogni processo ha una sua coda di segnali validi d’ingresso detta

complete valid input signal set input queue • OPERATORI: alle code si può accedere mediante appositi operatori (input,

output, save e priority input) • PID (Process IDentificator): sort numerico predefinito con cui il sistema

identifica univocamente e indirizza esplicitamente l’istanza di un processo, quella del padre (il processo creatore), del figlio (il processo creato) ed eventualmente l’istanza dalla quale è stato ricevuto l’ultimo segnale (il processo sender).

3. La terza infine riguarda la gestione esplicita del tempo di sistema assoluto o relativo

necessaria per la temporizzazione (seppur simulata) e la sincronizzazione dei vari processi real-time, direttamente supportata in SDL con la funzione predefinita now, i timer e appositi tipi di dato predefiniti (Time e Duration), e la differente temporizzazione nell’esecuzione delle istruzioni in una transizione di stato SDL e in un corrispondente passo (step) Statemate.

48

4.2 Specifica Statemate del modello SDL

4.2.1 Processi con più istanze concorrenti Per quanto riguarda il primo punto, non trattato nello schema di trasformazione delle specifiche introdotto in precedenza, a prima vista l’approccio migliore sembrerebbe in effetti quello di utilizzare le cosiddette ‘Carte Parametriche’ (chiamate Generic Charts o semplicemente Generics in Statemate). Queste sono particolari Module-Charts, Activity-Charts e StateCharts che hanno lo scopo di favorire l’eventuale riusabilità delle specifiche all’interno del modello anche se con certe limitazioni, soprattutto per quanto riguarda le regole di visibilità in fase di specifica e di simulazione. Tale obiettivo è raggiunto tramite un’opportuna definizione di tipo Generic (contrapposto a Regular) nel Data Dictionary relativo alla Chart: questo nuovo tipo prevede l’uso di parametri formali per tutte le entità utilizzate all’interno della Chart, i quali sono caratterizzati da un nome di riferimento, un tipo (data-item, evento, condizione o activity) e un modo d’uso (come costante o come porta di ingresso e/o uscita). I parametri formali sono, insieme alle costanti e agli user-defined type dichiarati nei GDS (Global Definition Set), le uniche vie di collegamento possibili tra queste Generic Charts e il resto della gerarchia di Carte del modello. Tali parametri sono poi effettivamente collegati (actual parameters binding) alle entità caratteristiche di ciascuna istanza esistente (generic instance) della Carta Parametrica, tramite opportune definizioni nei rispettivi Data Dictionary, secondo un meccanismo simile a quello della classi istanziate in oggetti. In tal modo possono essere definite facilmente nel modello più istanze concorrenti dello stesso tipo della Generic StateChart di riferimento ma diverse tra loro, magari associando a ciascuna di esse attività, dati e code differenti, in modo simile a quanto avviene per i processi SDL. Nonostante questi indubbi aspetti positivi, è in fase di effettiva implementazione e simulazione del modello che vengono alla luce i non trascurabili limiti di questo tipo di Charts. In particolare, mentre i parametri formali prevedono un binding dinamico (cioè i loro valori vengono letti o aggiornati a run-time, in diretta concomitanza con le operazioni sulle rispettive variabili di riferimento), l’istanziazione delle varie generic instances, in netto contrasto con SDL, è statica, ossia, nel nostro caso, i processi previsti devono essere definiti singolarmente a priori nel modello, specificando tutte le relative interfacce con l’esterno (information-flow lines) ed eventualmente assegnando ‘manualmente’ un PID univoco a ciascuno di essi; come se non bastasse, in fase di simulazione interattiva è possibile monitorare una sola istanza per volta. Queste due fondamentali carenze – unite alla fastidiosa comparsa di irrisolti warnings di completezza nell’analisi statica del modello nel caso si utilizzino off-page Charts (come nelle versioni 13c e 15 descritte nel capitolo successivo), alle definizioni aggiuntive dei parametri nella Generic Chart e al binding degli stessi in tutte le generic instances – ne sconsigliano l’uso, nonostante la potenziale ed elegante riusabilità delle specifiche, a favore delle classiche Regular StateCharts che comunque offrono, tramite il meccanismo del copy&paste, una certa riusabilità delle specifiche, anche se a costo di una conseguente ridondanza apparente (vedi la struttura del modello della versione 7 riportata in Figura 4.2). L’utilizzo delle Carte Regolari infatti prevede ancora la definizione a priori, in fase di specifica, di tutte le istanze (nel nostro caso, i processi periodici critici garantiti e, se presenti, le StateCharts che ne gestiscono i vincoli temporali) previste nel modello ed inoltre ripropone il problema della mancanza di un comodo PID di sistema.

49

Figura 4.2 – Gerarchia del modello della versione 7

50

4.2.2 IPC, code e PID Quest’ultimo aspetto ci introduce nel più generale problema di realizzazione nel nostro modello di un sistema di IPC il più possibile simile a quello previsto in SDL. In particolare, la questione del PID, come già accennato, è in definitiva di facile anche se poco elegante soluzione: è direttamente il progettista ad assegnare univocamente, in fase di specifica, il PID a ciascuna istanza, magari in base al numero progressivo che caratterizza il nome di ciascun processo (ad es. 1 per il PROC1); tale metodo mnemonico permette poi, come vedremo più avanti, di gestire direttamente l’attivazione e l’eventuale killing esplicito dei processi e, tramite un apposito campo record nelle code di sincronizzazione, di identificare gli stessi univocamente nello scambio dei messaggi (message passing). La questione più delicata e complessa da risolvere risulta dunque la realizzazione di un opportuno sistema di Inter-Process Communication (IPC) che, tramite l’utilizzo di apposite code (comunicazione asincrona) di record e l’implementazione di procedure ad hoc per loro gestione (input, output, save e priority input), permetta un corretto e funzionale scambio di messaggi informativi e di controllo tra i vari processi del modello, come già avviene in SDL a livello di sistema (vedi Figura 4.3).

Figura 4.3 – Schema dell’IPC tra processi SDL

In effetti in Statemate sono già previste le cosiddette information-flow lines, canali di comunicazione tra le varie Activity Charts del modello che, al pari dei signal routes SDL, trasportano flussi di dati (data-flow) e di controllo (control-flow) tra i vari processi del sistema (vedi Figura 4.4). Bisogna però notare che, mentre in SDL i segnali provenienti da ogni istanza dello stesso processo, pur essendo distinti, sono trasportati al medesimo processo destinatario da un unico signal route, in Statemate ciascuna istanza dello stesso processo ha una sua ben distinta info-flow line di comunicazione verso un medesimo processo destinatario.

Process Instance

Process Instance

Process Instance

signal route Input queue

Input queue

Input queue

signal

signal

Process Instance

Process Instance

Process Instance

51

Figura 4.4 – Info-flows, Activities e queues del SYSTEM_GRMS

Un’altra differenza sta nel fatto che i segnali SDL sono sorts predefiniti (eventualmente parametrici) gestiti direttamente dal sistema tramite un meccanismo di input/output di tipo FIFO (vedi Figura 4.5) implementato in ogni processo in maniera completamente automatica e trasparente per il progettista, che si limita ad utilizzarlo nel suo lavoro di specifica senza preoccuparsi affatto di tutte le problematiche inerenti l’effettiva realizzazione e la delicata sincronizzazione dello scambio di segnali tra i processi.

Figura 4.5 – Funzionamento dell’input queue in SDL

INPUT QUEUE

S1

S2

PROCESS GRAPH

Stato S1: il segnale ‘a’ innesca la transizione verso lo stato S2

Stato S2: il segnale ‘d’ viene scartato

Stato S2: il segnale ‘a’ innesca una transizione verso un altro stato

a d

a b f a

b

b

d a

a d a b

52

In Statemate invece non esistono questi segnali né tanto meno un meccanismo implicito di sistema per la loro gestione automatica: i segnali SDL possono in effetti corrispondere dal punto di vista semantico, tranne qualche eccezione dettata dal contesto d’uso (come vedremo più avanti), agli eventi (input signal) o alle azioni (output signal) delle StateCharts (la cui dinamica è basata proprio sulla coppia event/action, dove l’evento è il trigger della corrispondente azione), con il non trascurabile problema però di essere segnali istantanei e transienti che non sono, come in SDL, automaticamente salvati (se di uscita) o prelevati (se di ingresso) utilizzando apposite code di sistema. Per gestire la comunicazione tra i processi si è quindi optato per una soluzione in cui si utilizzano specifiche code di eventi – la coda tra l’altro è un tipo predefinito in Statemate – eventualmente strutturate per poter contenere il PID e i parametri dei corrispondenti segnali del modello SDL; da queste code un’apposita routine (static reaction riportata nel Listato 4.1) interna ad un certo stato (GET in Figura 4.6), non appena è verificata la condizione di guardia di coda non vuota (in questo caso [q_length(INPUT_NEW_PROC(1)>0]) preleva, in ordine rigorosamente FIFO (escludendo per ora il caso più complesso del priority input e del save), i vari eventi scritti precedentemente dal processo mittente, fino a quando (evento CICLO) un determinato evento trigger (nel nostro esempio COMPLETE, TPERIODO o KILL) innesca la transizione al successivo stato (vedi ancora Figura 4.6). State GET Defined in chart: EXECUTING_OR_SUSPENDED1 Type: Basic Description: legge dalla coda (non vuota) Static reaction: entering/get!(INPUT_NEW_PROC(1),$EVENTO); if $EVENTO.EVENTO='complete' then COMPLETE else if $EVENTO.EVENTO='tperiodo' then TPERIODO else if $EVENTO.EVENTO='kill' then KILL else CICLO end if end if end if

Listato 4.1 – Routine per la lettura dall’input queue in Statemate

Figura 4.6 – Diagramma di transizione di stato per la lettura dall’input queue in Statemate

53

A questo punto rimangono da implementare ancora due fondamentali operatori SDL che servono ad alterare la normale modalità FIFO di prelevamento dei segnali dall’input queue del processo: il priority input e il save. Il priority input, come suggerisce il nome stesso, viene utilizzato in tutti quei casi in cui si vuole che un determinato segnale abbia sempre la priorità maggiore e debba quindi essere prelevato prima degli altri dall’input queue, indipendentemente dalla sua posizione nella coda stessa; se il segnale specificato nel priority input non è presente nell’input queue, il consueto ordine di prelevamento FIFO rimane inalterato. La Figura 4.7 indica ad esempio la ricezione prioritaria del segnale parametrico “fine(running)” inserito nell’apposito simbolo di input a ‘coda di rondine’ doppia.

Figura 4.7 – Priority input SDL

Il costrutto SDL save è in un certo senso analogo al priority input: seguendo il classico ordine FIFO, vengono prelevati dalla coda di ingresso tutti i segnali che precedono il segnale indicato nel simbolo di input a ‘coda di rondine’ dello stato corrente, con la differenza rispetto alla normale esecuzione che tutti i segnali consumati dalle transizioni di stato implicite e indicati nel save non vengono persi, ma sono salvati nella coda; in un certo senso, è come avere un unico priority input con il salvataggio di tutti gli altri segnali presenti nel save. In SDL è inoltre possibile indicare il salvataggio di tutti i segnali di ingresso utilizzando l’apposita notazione * all’interno del simbolo a forma di parallelogramma del save, come illustrato nel diagramma SDL a sinistra in Figura 4.8. Come al solito il nostro problema è che, mentre in SDL questi due utili meccanismi sono implementati a livello di sistema, in Statemate bisogna sopperire loro in qualche modo; fortunatamente in questo caso, evitando una macchinosa manipolazione delle code, possiamo utilizzare un tipo di segnale persistente: la condizione. Questo particolare tipo di information-item, una volta assunto valore falso (default) o vero, lo mantiene fino al successivo cambiamento, contrariamente ad un evento che come abbiamo visto, se non salvato o consumato immediatamente, viene definitivamente perso. Questa particolarità permette di modellare un priority input SDL direttamente con una condizione Statemate in quanto quest’ultima non viene inserita nell’input queue del processo bypassando quindi il normale ordine FIFO di prelevamento dei segnali dalla coda stessa. Il Listato 4.2 mostra in dettaglio la routine Statemate che implementa il priority input SDL riportato in Figura 4.7: come si può vedere all’entrata nello stato PRIORITY_INPUT_OR_GET il primo controllo effettuato riguarda proprio la condizione (parametrica) ad alta priorità FINE(RUNNING) e solo nel caso tale condizione risulti falsa si passa alla lettura della coda d’ingresso del processo.

54

State PRIORITY_INPUT_OR_GET Defined in chart: WAIT_COMPLETATION_OR_NEW_START Type: Basic Description: controlla il timer FINE(RUNNING) o legge dalla coda Static reactions: entering/if FINE(RUNNING) then TFINE else get!(INPUT_GLOBAL_MONITOR,$APPOGGIO); if $APPOGGIO.EVENTO='partito' then PARTITO_SIG else CICLO end if end if

Listato 4.2 – Priority input Statemate

L’uso della condizione permette inoltre un’elegante e rapida soluzione anche al problema dell’implementazione in Statemate del save SDL, solo però nel caso di save * e di un unico input: a tal proposito vedi la condizione [COMPLETATO] presente nel diagramma Statemate a destra della Figura 4.8 il quale è stato ricavato direttamente dalla corrispondente specifica SDL di sinistra.

Figura 4.8 – Save in SDL e in Statemate

55

4.2.3 Temporizzazione in Statemate Il terzo ed ultimo punto rimasto irrisolto rappresenta una delle questioni più delicate e cruciali dell’intero progetto. La sua criticità risiede nella natura stessa delle StateCharts che male si adatta, almeno nell’ambito dello Statemate, ai vincoli temporali tipici di un sistema real-time; mentre infatti in SDL sono previsti nel linguaggio di specifica stesso dei meccanismi per la gestione esplicita del tempo assoluto (funzione predefinita now) e relativo (timer con relativi sorts Duration e Time), in Statemate le uniche funzioni primitive per la gestione del tempo (relativo) sono tm() e sc!() (vedi Tabella 4.1), molto simili ai timer SDL anche se non altrettanto flessibili.

Espressione Definizione tm (E,T) genera l’evento tm( ) T unità di tempo dall’occorrenza dell’evento E sc! (A,T) esegue l’azione A T unità di tempo a partire dall’istante attuale

Tabella 4.1 – Funzioni per la gestione del tempo in Statemate

In particolare, mentre i timer SDL sono integrati nel sistema e trattati come normali segnali (eventualmente parametrici), in Statemate i timeout events e le scheduled actions sembrano essere delle estensioni temporali introdotte in modo forzato nel sistema che si integrano in maniera problematica con il modello puramente reattivo delle StateCharts e con l’approccio alla temporizzazione delle istruzioni in Statemate (vedi paragrafo 4.2.5). A dimostrazione pratica di ciò, è interessante analizzare il comportamento di questi due costrutti temporali nel caso di sospensione o disattivazione di un’attività tramite gli appositi costrutti Statemate di controllo suspend() e stop(). A tal proposito bisogna osservare che una control-activity (StateChart) può anche controllare direttamente lo stato di tutte le attività ‘sorelle’ (cioè allo stesso livello) tramite quattro apposite azioni previste dallo Statemate: start(), stop(), suspend() e resume(). Più in particolare il comando start() avvia l’attività specificata e tutte le sue sub-activity (anche se control-activity) ed è stato da noi utilizzato per attivare all’occorrenza tutti i processi (eventualmente concorrenti) del nostro sistema, mentre il comando stop() arresta completamente l’attività referenziata con tutte le sue sub-activity (quest’ultimo costrutto comunque non è mai stato utilizzato nella nostra specifica). A queste azioni corrispondono direttamente due eventi, started() e stopped(), che permettono di monitorare lo stato dell’attività in questione. Una control-activity può anche sospendere momentaneamente – tramite il costrutto suspend() – un’attività sorella già avviata (sempre con tutte le sue sub-activity e control-activity), per poi risvegliarla al momento opportuno – tramite il costrutto resume() – facendola ripartire dall’ultima configurazione di stato in cui era stata sospesa, diversamente da quanto avviene con la successione di comandi start(), stop() e start(), che provoca l’arresto completo di tutte le sub-activity e control-activity dell’attività precedentemente avviata e la sua ripartenza ex-novo dalla configurazione di stato iniziale di default. Infine, gli eventi hanging() e active() permettono di controllare se l’attività in questione è rispettivamente sospesa o attiva.

56

Detto ciò, ritornando all’analisi dei due costrutti tm() e sc!() di Statemate, bisogna osservare che i timeout event possono eventualmente essere modificati a run-time facendoli ripartire da zero, ma non sono in alcun modo disattivabili; le scheduled action invece, una volta partite, non sono né modificabili né disattivabili. Inoltre, sospendendo con l’opportuno comando suspend() o arrestando con l’apposito comando stop() le attività in cui sono presenti questi due costrutti temporali, essi (come si è potuto osservare direttamente in fase di simulazione) avanzano e scadono inesorabilmente con il trascorrere del tempo simulato, pur senza produrre gli eventi o le azioni corrispondenti. Allo scopo di chiarire tutti questi aspetti inerenti la temporizzazione in Statemate sono state dunque implementate varie versioni del modello che, fermo restando tutto il resto della specifica formale ereditato dal modello SDL [2] (ossia modellazione del global_monitor, del modulo di acceptance, del proc_gen e, pur se con alcune modifiche formali, di quella dei processi real-time simulati: vedi Figura 4.10) prevedono strategie diverse nella gestione dei vincoli temporali del sistema, ma che comunque presentano risultati sperimentali sempre consistenti con la schedulazione ideale di riferimento e quindi sostanzialmente corretti (anche se con le dovute approssimazioni). In particolare, come vedremo nel paragrafo successivo, le time slices di schedulazione ottenute nella simulazione interattiva delle diverse versioni effettuata con lo stesso test pattern di riferimento sono, ferma restando l’uguaglianza quantitativa dal punto di vista delle temporizzazioni, simili tra loro in termini di passi (steps) solo dal punto di vista qualitativo e in condizioni di regime, ossia una volta esauritosi un ‘transitorio’ dipendente dalle condizioni iniziali (inter-arrival time, ritardi introdotti dal meccanismo di comunicazione asincrono delle code, etc.), anche tenendo conto di un fattore di scala caratteristico della Waveform1 grafica di ciascuna versione.

Figura 4.9 – Waveform d’esempio

1 Le Waveforms utilizzate per i nostri confronti sperimentali saranno illustrate dettagliatamente nel capitolo finale: in questa sede anticipiamo solo che esse sono in pratica delle finestre personalizzabili che permettono in fase di simulazione interattiva del sistema la continua monitorizzazione in tempo reale di variabili (data-items, condizioni, eventi, etc.) o elementi grafici (stati, attività, etc.) del modello specificato tramite un’adeguata rappresentazione visuale dei relativi segnali come ‘forme d’onda’ (vedi ad esempio la Figura 4.9).

57

Figura 4.10 – Specifica ‘standard’ (parentesi continue) e specifica per la gestione del

tempo (parantesi tratteggiata) con riferimento alla gerarchia del modello della versione 7

Specifica dei processi real-time simulati

Specifica del global_monitor

Specifica dei timer per la gestione del tempo

Specifica del proc_gen e dell’acceptance

58

4.2.4 Versioni realizzate per la gestione del tempo nel modello Come accennato alla fine del precedente paragrafo, nello sviluppo della presente tesi si è lavorato proponendo varie versioni per la gestione del tempo del modello di riferimento, al fine di valutare quali costrutti di Statemate potessero meglio rappresentare il sistema oggetto del nostro studio. Queste versioni sono state dunque numerate per poter all’occorrenza tracciare l’history dei tentativi effettuati e delle decisioni di volta in volta prese; non presentiamo però qui le versioni inizialmente sviluppate, ma partiamo da quelle che hanno fornito i risultati più interessanti in termini di adeguatezza di rappresentazione del sistema real-time stesso. Versione 7: questa versione è stata in effetti la prima a presentare un’ottima corrispondenza, anche dal punto di vista temporale, con la sequenza di time slice di una schedulazione preemptive Rate Monotonic calcolata manualmente su carta millimetrata e presa come riferimento teorico ideale, essendo basata sul medesimo test pattern. In essa si usa il costrutto sc!() scheduled action dello Statemate per gestire tutte le scadenze temporali dei vari processi (intertempi tra la creazione e l’eventuale uccisione dei processi, latenza e periodo propri dei processi periodici critici garantiti new_proc in Figura 4.11, il periodo proprio e quello di controllo del proc_acceptance) tramite opportuni eventi scritti alla scadenza nella coda d’ingresso del processo relativo o apposite condizioni.

Figura 4.11 – StateChart new_proc

59

Per gestire il time to complete (TTC) dei vari processi schedulati si usano invece – discostandosi in maniera significativa dal modello SDL [2] – dei timer-contatori unitari e indipendenti (uno per ciascun processo), implementati con un’apposita StateChart (vedi Figura 4.14) e controllati dal global_monitor (vedi Figura 4.12), che tengono conto del TTC, della sospensione e della fine del processo associato, simulando in pratica alcune fasi di esecuzione del processo stesso (vedi Figura 4.13).

Figura 4.12 – Activity Chart PROC_GLOBAL_MONITOR

Figura 4.13 – Diagramma degli stati di un processo periodico critico garantito

Figura 4.14 – StateChart timer_fine1

guarantee READY EXE arrival

termination

scheduling

preemption YES

NO

COMPLETE period expired, new instance

refused

60

Più in dettaglio, appena il processo pronto per la schedulazione (ready) precedentemente accettato dal modulo di acceptance viene mandato in esecuzione (exe) dal global_monitor (vedi l’analisi della specifica del sistema nel capitolo seguente per maggiori dettagli), un apposito evento START_TM (che tra l’altro provoca nel new_proc rispettivo in Figura 4.11 la transizione dallo stato WAIT_ACTIVATION a quello EXECUTING_OR_SUSPENDED) innesca la transizione dallo stato iniziale WAIT_START al successivo stato TIMER (vedi Figura 4.14), in cui viene settata una scheduled action su un tempo unitario tramite l’istruzione sc!(scadenza,1). Allo scadere di questo timer, l’evento generato SCADENZA innesca la successiva transizione di stato in seguito alla quale, se il processo non è stato sospeso (condizione SOSPESO falsa) viene incrementato un apposito contatore N che così tiene conto delle unità di tempo di volta in volta effettivamente consumate dal processo in questione; nel caso invece di condizione SOSPESO vera la StateChart entra nello stato SOSPESO (il processo ha subito preemption da parte di un processo a priorità più alta) e vi rimane fino a quando il processo viene riattivato, con conseguente rientro nello stato TIMER. Tale ciclo si ripete fino a quando il contatore N diventa uguale al valore TTC precedentemente assegnato: a questo punto la StateChart segnala al global_monitor la fine (complete) del processo schedulato tramite un’apposita condizione FINE; la condizione SCHEDULATO, insieme alla condizione SOSPESO, servirà – come vedremo meglio nel primo esempio finale di simulazione interattiva riportato nell’ultimo capitolo – per monitorare, tramite la condizione composta ATTIVO, l’effettivo stato corrente di esecuzione del processo.

Versione 8: questa versione presenta time slice di schedulazione praticamente uguali a quelle della versione 7 dal punto di vista temporale ma diverse in termini di passi, anche tenendo conto di un opportuno fattore di scala di ‘riduzione’ nella Waveform grafica. La gestione delle scadenze temporali dei processi è ancora realizzata all’interno dei processi stessi con il costrutto scheduled action; per conteggiare il TTC del processo top-prio2 effettivamente in esecuzione si usa invece, diversamente dalla versione precedente, un timer-contatore (realizzato con il costrutto tm() timeout event dello Statemate) unitario (il ‘tick’) unico per tutti i processi pcg ed esterno al sistema system_grms, che è avviato proprio dal processo clock tramite l’apposito comando start, abbreviato ‘st!’ (vedi Figura 4.15). Questo ‘orologio’ si limita semplicemente a fornire un riferimento temporale unitario NOW al global_monitor, in base al quale il global_monitor stesso possa tenere conto del tempo effettivamente consumato dal processo top-prio dalla sua effettiva attivazione fino alla sua completa conclusione (segnalata dalla scadenza di un’apposita scheduled action settata sul TTC del processo stesso) o all’eventuale sospensione a causa di un altro processo a priorità più alta, aggiornando di conseguenza in quest’ultimo caso il suo TTC nella coda dei task pronti.

Figura 4.15 – StateChart clock

2 processo a priorità più alta nella coda dei processi pronti.

61

Questo meccanismo di gestione del TTC è del resto analogo a quello utilizzato nel modello SDL di Sauro Carsughi [2]; una differenza sostanziale però è che il nostro NOW non è un tempo globale ed unico di sistema ed inoltre, mentre in SDL un timer all’occorrenza (come quello relativo al TTC del processo sospeso) si può resettare, cioè interrompere definitivamente, in Statemate, come abbiamo visto precedentemente, ciò non è possibile in alcun modo. Per cercare di ovviare in qualche maniera a questo problema si è dunque pensato di utilizzare un’opportuna condizione flag che invalidi questi timer ‘zombie’ un istante prima della loro scadenza (tramite un’opportuna scheduled action ‘inseguitrice’ della scheduled action relativa al TTC del processo sospeso), così che non falsino la schedulazione dei processi facendo terminare prematuramente il processo in esecuzione corrente, come si è potuto osservare proprio grazie all’esecuzione simulata. Questo artificio però, oltre ad essere poco elegante dal punto di vista implementativo, purtroppo non funziona correttamente per alcuni test pattern particolari: per questa ragione questa versione è stata abbandonata a favore delle successive. Versione 9: questa versione in realtà è una variante della versione 7 nella quale, ferma restando tutta la gestione decentralizzata dei vincoli temporali tramite scheduled action e del TTC dei processi schedulati tramite opportuni timer-contatori unitari per ciascun processo, abbiamo provato ad utilizzare i costrutti suspend() e resume() di Statemate (non presenti in SDL) per realizzare elegantemente il meccanismo della preemption. In pratica, il processo global_monitor avvia, tramite il costrutto start(), il timer relativo al processo corrente in esecuzione e, quando necessario, ne sospende – tramite il costrutto suspend() – l’attività a favore del timer di un processo a priorità più alta, per poi riavviarla dalla sua ultima configurazione di stato – tramite il costrutto resume() – quando il processo sospeso è di nuovo top-prio nella tabella di schedulazione, fino alla sua completa e corretta esecuzione. Tramite questo meccanismo si tiene così conto del tempo effettivamente consumato dal processo in questione con l’approssimazione di ±1; come già visto infatti, la scheduled action non si ferma come la StateChart in caso di sospensione dell’attività che le contiene, ma comunque ha una scadenza unitaria. Purtroppo non si è riusciti a portare a termine la simulazione per questa versione in quanto sorgono degli errori imprevisti nell’esecuzione di alcune Procedural StateCharts, dovuti presumibilmente proprio all’uso del costrutto suspend(), che tuttora rimangono irrisolti. Versione 10: questa versione è una diretta evoluzione migliorata della versione 8 e come questa presenta una gestione decentralizzata di tutti i vincoli temporali dei processi (tramite le solite scheduled action), tranne che per il TTC; quest’ultimo infatti viene gestito ancora dal processo global_monitor sfruttando la variabile temporale NOW fornita dal processo clock, con la differenza sostanziale però rispetto alla versione 8 che il contatore-timer che tiene conto del tempo effettivamente consumato dal processo corrente in esecuzione non è più una scheduled action interna al global_monitor, ma è un timeout event interno allo stesso processo clock, concorrente (and-state) e sincronizzato, come del resto tutti gli altri timer del modello, con il timer-contatore NOW. Il vantaggio di questa soluzione è, oltre alla presenza di un’unica semplice StateChart per gestire il TTC di tutti i processi, il fatto che viene risolto elegantemente il problema del reset dei timer ‘zombie’ che affliggeva la versione 8, in quanto ora l’attivazione di un nuovo processo schedulato che ha fatto prelazione sul precedente a priorità più bassa

62

comporta l’immediato ed automatico restart da zero del timer che simula il TTC del processo attualmente in esecuzione. E’ stata comunque prevista un’opportuna condizione di guardia ATTIVO(RUNNING) che, oltre a essere utilizzata per monitorare le time slices del processo correntemente attivo nella Waveform grafica della simulazione interattiva (vedi gli esempi finali illustrati nel capitolo 6), serve ad evitare che un timer scaduto (condizione FINE(RUNNING) resa vera) proprio durante il cambio di contesto (context switching) falsi in qualche modo il segnale di terminazione del processo running (rappresentato dalla condizione TERMINATO composta proprio dalle due condizioni ATTIVO(RUNNING) e FINE(RUNNING)). Per concludere la discussione di questa versione, bisogna osservare che ne è stata realizzata anche una versione alternativa, chiamata 10b, in tutto e per tutto uguale alla presente, sia nella specifica che nella simulazione, tranne per il fatto che i processi periodici critici garantiti indipendenti sono stati definiti come generic instances di una medesima Carta Parametrica (vedi StateChart proc_pcg in Figura 4.16) anziché come separate StateChart ottenute con un copy&paste e con opportuni piccoli riadattamenti delle specifiche.

Figura 4.16 – Generic StateChart proc_pcg

63

In questo modo a costo di una maggiore complessità nell’implementazione della Generic StateChart, dovuta in particolare alle definizioni aggiuntive dei parametri formali, e nella definizione delle rispettive generic instances che, pur conservando le stesse info-flow lines, richiedono il binding di tutti i loro parametri e comunque vanno definite ugualmente tutte a priori nella specifica del modello, si ottiene l’innegabile vantaggio di avere un’unica Chart ‘tipo’ di riferimento (proc_pcg) per tutti i processi periodici critici garantiti presenti o futuri. Inoltre tale approccio, oltre a soddisfare gli auspicabili requisiti di riusabilità, manutenibilità e modularità delle specifiche (similmente a come avviene in SDL), offre probabilmente una maggiore leggibilità ed una minore ridondanza apparente nella gerarchia delle Charts del modello specificato (cfr. la struttura dell’albero in Figura 4.17 con quella in Figura 4.2) e quindi potrebbe essere adottato anche per le altre tipologie di processi real-time.

Figura 4.17 – Gerarchia del modello della versione 10b

Versione 11: la caratteristica principale di questa versione consiste nel fatto che abbiamo una gestione centralizzata di tutti i vincoli temporali dei processi (non solo quindi del TTC) realizzata tramite opportune StateChart concorrenti (and-state interne alla StateChart clock) che eseguono in parallelo e che hanno come unico riferimento temporale la variabile NOW unitaria globale (vedi Figura 4.18). Inoltre, diversamente dalla versione precedente, in questo modello i timer non sono realizzati utilizzando i costrutti temporali tm() e sc!() offerti dallo Statemate, ma sono implementati come ‘timer logici’ tramite opportune semplici StateCharts (vedi i due esempi riportati in Figura 4.19 e in Figura 4.20) peraltro molto simili tra loro e quindi realizzabili con un veloce copy&paste e piccole modifiche alle variabili locali (o eventualmente, se pur con le già accennate limitazioni, come generic instances di opportune Carte Parametriche, come nella versione 10b).

64

Figura 4.18 – StateChart clock con ‘timer logici’ concorrenti (and-state)

Figura 4.19 – StateChart periodo_proc1

Figura 4.20 – StateChart clock_ttc

65

Più in dettaglio, l’evento che nella versione 10 avviava il timeout event in questo caso diventa il trigger dell’azione che setta la scadenza assoluta del timer sommando il NOW corrente alla scadenza relativa fornitale dal global_monitor (nel caso del TTC), dal proc_gen (nel caso del periodo e della latenza dei processi periodici critici garantiti) o dal proc_acceptance (nel caso del periodo e del timer di controllo del processo acceptance); a questo punto si entra in uno stato di attesa dal quale si esce solo quando l’opportuna condizione trigger [NOW=SCADENZA] diventa vera (scadenza del timer), innescando quindi l’azione che segnala la fine del timer in questione al processo interessato. In questo modo, a scapito di un aumento nella complessità e nel numero delle StateCharts (2 per l’acceptance e 2 per ogni processo pcg, oltre a quella per il TTC del processo running: vedi ancora Figura 4.18) anche nel caso di utilizzo delle Generics, e nel numero delle info-flow lines che collegano i vari processi (vedi Figura 4.21), si è ottenuto un modello che presenta il costrutto temporale tm() solo nella StateChart contatore NOW.

Figura 4.21 – Activity-Chart GRMS e info-flow lines tra CLOCK e SYSTEM_GRMS

Questo permette di controllare la ‘risoluzione temporale’ dell’esecuzione simulata variando opportunamente la durata del tick (non necessariamente unitaria o intera) e in teoria anche il playing della simulazione stessa, agendo direttamente sull’unica StateChart che incrementa la variabile NOW, cioè in definitiva il tempo di riferimento del modello. In particolare il controllo della simulazione può essere realizzato utilizzando opportunamente (pur se con le dovute limitazioni) i costrutti suspend() e resume() visti precedentemente, o meglio ancora la condizione stoppato (vedi Figura 4.15) definita appositamente per poter fermare momentaneamente il contatore NOW per poi riavviarlo successivamente, senza però arrestare completamente e far ripartire da capo la

66

StateChart, come invece avverrebbe nel caso utilizzassimo i comandi stop() e start() che così comprometterebbero irrimediabilmente lo svolgimento corretto della simulazione. Bisogna però osservare che tutto ciò può essere ottenuto anche, e in modo a mio parere decisamente più semplice e immediato, gestendo i vincoli temporali tramite timer Statemate distribuiti (tranne che per il TTC) nei rispettivi processi (come nella versione 10) o centralizzati nella StateChart clock (come nella variante 11b, uguale nella specifica e nella simulazione alla versione 11 tranne che per l’uso del costrutto tm() nella realizzazione dei timer) e utilizzando i Go Commands e le comode opzioni temporali del Simulation Tool di Statemate. Nell’esecuzione simulata infatti, oltre allo schema di tempo sincrono o asincrono, si possono settare l’unità di tempo globale utilizzata in tutte le espressioni temporali del modello, il fattore temporale di AutoRun nella simulazione automatica e addirittura i valori e le unità di tempo locali delle singole StateChart (vedi il capitolo 6 per maggiori dettagli). Per concludere, questa versione, diversa nella gestione del tempo e nell’implementazione dei timer dalla versione precedente, è in definitiva una prova sperimentale dell’equivalenza sostanziale, anche se non formale, con il modello implementato nella versione 10. Nel confronto tra i risultati sperimentali bisogna inoltre tener conto di un piccolo fattore di scala di ‘ingrandimento’ e di un anticipo di tutte le time slice nella Waveform dovuto al fatto che per semplificare la realizzazione della specifica non sono stati modellizzati (ossia in pratica sono stati considerati nulli) tutti gli inter-arrival time tra i processi pcg, anche se poi nell’esecuzione simulata del nostro modello le partenze dei processi avvengono in ogni caso in passi, pur se non in tempi, successivi. Versione 12: questa versione è un’alternativa alla versione 11b la quale, come già accennato precedentemente, si differenzia dalla versione 11 solo per il fatto che tutti i ‘timer logici’ sono implementati più semplicemente utilizzando il comodo costrutto temporale tm() di Statemate. In questa versione, fermi restando gli inter-arrival time nulli, si rinuncia all’espressività di modellazione offerta dagli strumenti grafici dello Statemate – in particolare le StateChart concorrenti ed indipendenti (and-state e ortogonality) – a vantaggio di una maggiore sinteticità della specifica formale, in quanto per gestire tutti i vincoli temporali del sistema (compreso il TTC) si utilizzano solo tre StateChart implementate all’interno della Chart clock: il solito contatore temporale unitario NOW, un timer tm() per gestire il TTC del processo running e una nuova StateChart che gestisce tutte le altre scadenze temporali del sistema tramite timer sc!().

Figura 4.22 – StateChart per la gestione della coda e di alcuni vincoli temporali

67

Più in particolare, a parte la solita implementazione del NOW e del timer_ttc (vedi versione 10), la nuova Chart (vedi Figura 4.22) sostanzialmente aspetta che la coda input_clock, nella quale tutti i processi con vincoli temporali scrivono le loro richieste, contenga almeno un elemento e quindi ne preleva con un ciclo tutti gli eventi (stringhe) attualmente presenti, in base ai quali avviare i rispettivi timer (periodo e controllo dell’acceptance, latenza e periodo dei processi periodici), implementati tramite opportune scheduled action. In effetti queste ultime potrebbero essere implementate – in modo comunque più macchinoso – anche come ‘timer logici’ nonostante il fatto che, come evidenziato dal confronto sperimentale tra i risultati di simulazione ottenuti con la versione 10 e con quella 11, i due modelli sarebbero praticamente equivalenti. Questo approccio presenterebbe però il vantaggio di avere un unico timer tm() per il riferimento temporale unitario esterno (il ‘tick’) e una gestione centralizzata e globale di tutte le scadenze temporali (compreso il TTC) completamente trasparente (o quasi) all’utente-progettista e nel contempo più aperta a possibili sviluppi futuri del nostro modello di sistema real-time (ad esempio, sistema multiprocessore): tutto ciò è stato implementato nella versione successiva. Concludiamo osservando che la versione 12 funziona praticamente come la precedente sotto tutti i punti di vista, a parte un piccolo fattore di scala di ‘riduzione’ nella Waveform grafica. Versione 13: questa versione riprende sviluppandoli alcuni interessanti aspetti della versione precedente, in particolare la gestione dei vincoli temporali del sistema tramite un’apposita coda (input_clock) che permette di raccogliere e di prelevare secondo un ordine tipicamente FIFO tutte le richieste di scadenze temporali provenienti dai processi specificati a priori nel modello (definiti, a parte il proc_gen, il global_monitor ed il proc_acceptance, come istanze generiche di una stessa Carta Parametrica); tali richieste vengono quindi processate ed inserite tramite opportune procedure (subroutine implementate in Statemate Action Language) in un’apposita lista ordinata, realizzata mediante rappresentazione collegata (concatenata) di un vettore (LISTA_TIMER) di dimensione prefissata (MAX_LISTA). Ciò implica un radicale cambiamento nella filosofia di gestione dei vincoli temporali, in quanto ora tutte le scadenze temporali (compresi i TTC e gli inter-arrival time tra i processi, in questa versione non necessariamente nulli) non sono più realizzate internamente ai processi stessi tramite opportuni timer Statemate oppure esternamente tramite apposite StateChart contatori, ma sono implementate semplicemente come ‘timer logici’ (vedi versione 11) e gestite direttamente da un unico Clock Manager esterno globale (vedi la specifica della relativa StateChart Statemate riportata in Figura 4.23).

Figura 4.23 – StateChart clock_manager

68

Più in particolare, una volta inizializzati (azione INIT) il record d’appoggio, la lista_timer e i due ‘puntatori’ FIRST (al primo elemento utile o ‘testa’ della lista, inizialmente settato sul valore MAX_LISTA+1 per indicare che la lista è vuota) e FREE (al primo elemento o ‘testa’ della lista libera, inizialmente settato sul valore 0), il clock_manager entra nello stato di attesa WAIT dal quale esce non appena una richiesta di scadenza temporale viene scritta da un processo nella sua coda input_clock (condizione di guardia q_length(INPUT_CLOCK)>0 vera). In questo caso si entra nello stato @AGGIORNA_LISTA_TIMER, la cui StateChart (che analizzeremo in dettaglio più avanti) preleva dalla coda input_clock (non vuota) tutte le richieste di scadenze temporali relative presenti in essa, le rende assolute sommandogli il NOW corrente e le inserisce in maniera ordinata (in base al valore della scadenza assoluta) nella lista_timer, se non piena (in caso contrario l’apposito evento generato en(LISTA_FULL) causa l’uscita dallo stato corrente e l’entrata nello stato di errore senza uscita LISTA_PIENA). Appena concluso con successo (lista non piena) l’aggiornamento completo (coda input_clock vuota) della lista_timer viene generato l’evento en(LISTA_AGGIORNATA) che innesca la transizione dallo stato @AGGIORNA_LISTA_TIMER allo stato @CONTROLLO_TIMER, la cui StateChart (che vedremo in dettaglio più avanti) si occupa di controllare l’eventuale scadenza del/dei timer logico/i in testa alla lista_timer ordinata (non vuota) ed in caso affermativo invia un opportuno segnale (realizzato tramite condizioni, eventi o apposite stringhe scritte nell’input queue) al processo interessato (se necessario individuato tramite un apposito PID) rimuovendo di conseguenza il timer scaduto dalla lista corrente. Una volta terminato questo controllo, viene generato l’evento en(TIMER_CONTROLLATI) che innesca la transizione dallo stato @CONTROLLO_TIMER al successivo stato WAITING, nel quale il clock_manager permane fino a quando non è verificata almeno una delle due condizioni specificate nel trigger della transizione di uscita: la scrittura da parte di un processo di una richiesta temporale nella coda input_clock (q_length(INPUT_CLOCK)>0) o la generazione dell’evento TICK, ossia il tempo dato dalla scadenza del timer unitario tm(TICK,1)/TICK presente nella StateChart concorrente clock (vedi Figura 4.15). Nel primo caso (condizione q_length(INPUT_CLOCK)>0 vera), indipendentemente dalla generazione dell’evento TICK, il processo ritorna nello stato @AGGIORNA_LISTA_TIMER, nel secondo caso invece (evento TICK generato ma coda input_clock vuota, ossia condizione q_length(INPUT_CLOCK)=0 vera) si rientra nello stato @CONTROLLO_TIMER. In pratica, ad ogni colpo di clock (cui corrisponde un incremento unitario della variabile NOW), a meno che non ci sia da aggiornare prima la lista_timer con altre richieste temporali giunte nel frattempo (cioè tra un TICK e l’altro), viene effettuato il controllo di eventuali scadenze di timer logici con conseguente loro rimozione dalla lista stessa. Sempre a proposito della specifica del Clock Manager, cogliamo inoltre l’occasione per osservare che, allo scopo di renderla il più possibile indipendente dal nostro particolare contesto applicativo e favorire così la sua eventuale futura riusabilità in altri modelli, anche se con i necessari riadattamenti (soprattutto per quanto riguarda le interfacce verso l’esterno) e a costo di una maggiore complessità implementativa nella specifica degli altri processi (nel nostro caso dovuta principalmente all’unificazione e alla gestione delle input queues), è stata realizzata una versione alternativa alla 13, denominata 13a. Nella versione 13a il costo di gestione del segnale di scadenza temporale, sempre realizzato come semplice campo di tipo string di un apposito record (formato tra l’altro anche da tre campi di tipo integer, denominati rispettivamente PID, SCADENZA e RUNNING, e da un campo RIMOZIONE di tipo bit), viene spostato dal Clock Manager al processo interessato nel senso che, mentre nella versione 13 il Clock

69

Manager stesso, in caso di scadenza del timer logico in testa alla lista, si occupava di controllare la stringa del campo SEGNALE con una serie di if statements in base alla quale notificare al processo giusto la scadenza del timer richiesto (come abbiamo già accennato, rendendo vera un’opportuna condizione, generando un apposito evento o scrivendo una determinata stringa identificativa nella coda del processo stesso), nella versione 13a questa gestione è demandata direttamente al processo richiedente. Più in particolare, ferme restando tutte le procedure e le StateChart per la gestione della lista ordinata e della variabile temporale NOW, il Clock Manager, al momento della scadenza di un timer logico, si limita semplicemente a restituire il segnale ricevuto al processo stesso che lo ha precedentemente inviato, riscrivendo la medesima stringa direttamente nell’input queue del processo interessato, coda individuata univocamente dal PID presente nel record attualmente processato e successivamente eliminato. A questo punto sarà compito del processo richiedente prelevare dalla sua coda, con opportune azioni, il segnale di scadenza atteso e generare di conseguenza le opportune reazioni, tenendo conto eventualmente della presenza di un priority input o di un save; a tal proposito, non potendo utilizzare in questo caso le comode conditions Statemate per implementare questi ultimi due meccanismi primitivi SDL (vedi Figura 4.7 e Figura 4.8), abbiamo elegantemente risolto il problema utilizzando il costrutto q_urgent_put(queue) grazie al quale è possibile scrivere un elemento in testa alla coda referenziata anziché in fondo, bypassando il normale ordine FIFO di inserimento e conseguente prelevamento dei segnali. Dal confronto diretto dei risultati sperimentali delle due versioni sul medesimo test pattern di riferimento abbiamo comunque potuto osservare che, a parte un trascurabile fattore di scala nelle rispettive Waveform grafiche e l’assenza della condizione composta TERMINATO (ATTIVO(RUNNING) and FINE(RUNNING)), le time slice di schedulazione ottenute in fase di simulazione grafica interattiva risultano praticamente uguali sia dal punto di vista qualitativo (in termini di passi) che quantitativo (in termini di temporizzazioni), almeno nel caso di inter-arrival time non nulli. Versioni 13c e 13d: per inciso bisogna inoltre osservare che sono state realizzate anche due versioni estese della 13a, chiamate 13c e 13d, nelle quali la simulazione del modello è stata effettuata rispettivamente su quattro e cinque processi periodici critici garantiti indipendenti anziché su tre. Innanzitutto, per quanto riguarda la specifica, abbiamo potuto sfruttare la riusabilità offerta dalla Generic StateChart e dal Clock Manager, grazie alla quale i processi aggiuntivi sono stati implementati in modo perfettamente analogo agli altri tre (cioè come generic instances della stessa Carta Parametrica proc_pcg in Figura 4.16), pur se con i necessari adattamenti nel binding dei parametri e le definizioni aggiuntive delle relative info-flow lines di collegamento con tutte le attività esterne rilevanti (vedi Figura 4.24), interfacce basate comunque sul medesimo schema dei precedenti tre processi. Non ci si è dovuti invece occupare di tutto il meccanismo della gestione delle scadenze temporali inglobato all’interno del Clock Manager e praticamente trasparente per l’utente-progettista, che così nella specifica di un nuovo processo si deve solo preoccupare di utilizzare correttamente le code e i segnali di comunicazione tra i vari processi. Per completezza bisogna però anticipare (come vedremo meglio nel capitolo seguente) che per la corretta esecuzione del modello, oltre al rispetto di alcune costanti settabili direttamente in fase di specifica (numero massimo MAX_P di processi e di alcuni indici e parametri, dimensione massima MAX_LISTA della lista dei timer logici, etc.) sono necessarie altre definizioni aggiuntive nella StateChart proc_gen riguardanti i parametri di esecuzione del nuovo processo da simulare (inter-arrival time, latenza, periodo, WCCT e PID) e il comando start() per la sua attivazione.

70

Figura 4.24 – Activity Chart PROC4 e relative interfacce con l’esterno

A tal proposito sottolineiamo che la scelta di tali parametri va effettuata con una certa attenzione se vogliamo una schedulazione significativa rispetto alle precedenti versioni, ossia nella quale siano effettivamente presenti tutti i quattro (o cinque) processi: a parte il PID determinato automaticamente dal numero progressivo del task stesso e la latenza, che nei nostri esempi tutto sommato ha poco significato (in quanto tutti i processi arrivano in tempi sufficientemente vicini da poter essere analizzati dall’acceptance durante la sua prima istanza periodica, e di conseguenza il tempo simulato che intercorre tra l’attivazione iniziale del timer logico della latenza nel relativo proc_pcg e la risposta, positiva o negativa, dello schedulability_test risulta sempre nullo), i periodi e i WCCT vanno scelti in modo tale che l’insieme dei quattro task periodici critici garantiti possa avere una schedulazione fattibile secondo la teoria del Rate Monotonic o del Generalized Rate Monotonic (vedi il paragrafo 2.2.3). Oltre a questa ovvia condizione, verificabile matematicamente a priori o direttamente in fase di esecuzione simulata, gli inter-arrival time, specificati in valore relativo, dovrebbero essere sempre tali che ciascun processo inoltri la sua richiesta di schedulazione all’acceptance al momento giusto affinchè questa non vada persa, ossia o prima della scadenza temporale del timer TCONTROLLO_ACC (nel nostro caso settato al valore di ACCWCASE – 3 a partire dall’istante di attivazione del primo processo) della prima istanza di acceptance o dopo la scadenza del timer TPERIODO_ACC (variato automaticamente e dinamicamente in base al carico di lavoro attuale del sistema) della stessa istanza ma prima della scadenza del timer TCONTROLLO_ACC dell’istanza successiva (e così via per tutte le successive istanze periodiche); in caso contrario il processo ‘fuori tempo’, essendo la sua unica richiesta stata scartata definitivamente dall’input queue dell’acceptance, non verrà mai sottoposto al test di schedulabilità (vedi Figura 4.25) e la sua latenza, per quanto grande, scadrà inesorabilmente, come si è potuto osservare grazie ancora alla simulazione interattiva.

71

Figura 4.25 – StateChart proc_acceptance della versione 13c

A tal riguardo, osserviamo per inciso che il timer di sicurezza TCONTROLLO_ACC, ereditato dal modello SDL nel quale serviva ad evitare che l’acceptance iniziasse ad eseguire il costoso (in termini di complessità computazionale) algoritmo iterativo di schedulabiltà esatta [4] troppo a ridosso del suo WCCT con conseguente rischio di superamento della sua deadline, nel modello Statemate si potrebbe anche omettere in quanto l’analisi di schedulabilità effettuata dalla StateChart schedulability_test viene sempre eseguita, a differenza della corrispondente procedura SDL, in tempo simulato nullo; abbiamo però preferito mantenere ugualmente nella specifica questo timer di controllo, che potrebbe risultare non più così superfluo nel caso dell’esecuzione del prototipo del sistema in un contesto reale anzichè simulato. Allo scopo di superare il precedente indesiderato limite temporale nell’analisi delle richieste dei processi garantiti da parte di acceptance e di evitare tutti i suoi eventuali effetti collaterali – problema che del resto non si presenta nelle versioni precedenti la 13 proprio per la diversa gestione dei segnali e delle code di tutti i processi – in queste versioni abbiamo dunque separato la gestione delle richieste di schedulazione dei task critici (coda request_queue) da quella dei segnali di temporizzazione (timer di controllo e di periodo) relativi ad acceptance (coda input_proc(max_p-1)): in tal modo, oltre a semplificare per certi aspetti la gestione delle richieste stesse, abbiamo rivalutato la presenza della latenza, in quanto ora la possibilità per un processo tardivo di essere sottoposto al test di schedulabilità in istanze periodiche di acceptance successive alla prima dipende proprio dal suo valore. In maniera analoga abbiamo poi separato nel global_monitor la gestione dei segnali di avvenuta partenza dei processi (coda partito_queue) da quella dei segnali di completamento dei processi stessi provenienti dal Clock Manager (coda input_proc(max_p)) ottenendo così, a parità di risultati, un minor numero di info-flow

72

lines di collegamento, un’apprezzabile semplificazione nella StateChart di global_monitor e una gestione delle code stesse più snella ed efficiente. Nonostante il rispetto delle precedenti ipotesi, comunque, dai risultati sperimentali si è potuto anche constatare che, sebbene l’algoritmo di schedulazione sia applicato in maniera corretta, l’approssimazione intrinseca nella modellazione stessa, quando il fattore di utilizzazione U supera un certo valore critico di soglia, invalida il test di garanzia di schedulabilità esatta basata sulla zona critica (subroutine critical_zone_test), in quanto il processo periodico critico garantito a più bassa priorità non riesce a rispettare la sua deadline (periodo), come invece teoricamente dovrebbe avvenire. Per questo motivo, mentre nel caso di tre processi il valore di soglia per U (MAX_U) nella StateChart schedulability_test per la procedura critical_zone_test poteva essere settato senza problemi in qualsiasi versione sul limite massimo teorico di 1 (100%), ottenendo così valori massimi nella simulazione di particolari test pattern anche superiori a 0.99, nel caso di quattro processi effettivamente schedulati per l’esecuzione la soglia MAX_U si è dovuta fissare in modo empirico sul valore 0.88 per non rischiare fallimenti inattesi, con valori massimi raggiunti per U in certi esempi superiori a 0.87 (sia con inter-arrival time nulli che diversi da zero), che per un vero sistema in tempo-reale rappresentano comunque un risultato ancora soddisfacente. Del resto queste ultime considerazioni, a dimostrazione della loro generalità, valgono anche per il modello specificato nella versione 7b, la quale si differenzia dalla versione 7 solo per il fatto che i processi periodici garantiti schedulabili sono quattro, anziché tre, e la cui realizzazione si è resa necessaria proprio per poter aver almeno un mezzo di confronto sulla bontà dei risultati sperimentali ottenuti con la versione 13c, in mancanza questa volta di una schedulazione manuale di riferimento. Più in particolare, fermo restando lo stesso test pattern di riferimento e le necessarie aggiunte dei segnali da monitorare nella Waveform grafica, la sequenza di time slice ottenuta nella simulazione della variante 7b risulta ancora temporalmente uguale e qualitativamente equivalente (in termini di passi) a quella della versione 13c (almeno nel caso di inter-arrival time non nulli), mentre il fattore di utilizzazione massimo e quello a regime (cioè quello calcolato quando il periodo dell’acceptance si è assestato sul suo valore massimo di 250) e il valore di soglia MAX_U citato precedentemente risultano quantitativamente uguali. Per quanto riguarda invece la fase di specifica, bisogna ribadire che l’assenza nella versione 7b di una Generic StateChart per tutti i proc_pcg e i rispettivi timer-contatori del TTC, se da una parte ha semplificato gli adattamenti locali nell’implementazione del quarto processo e del relativo timer (è bastato cambiare il numero di PID ad ogni sua occorrenza), dall’altra ha richiesto il poco elegante uso del meccanismo del copy&paste. Ritornando alle funzioni del Clock Manager, va detto che esso si occupa anche, sempre tramite una procedura realizzata ad hoc (vedi Listato 4.3), di eliminare dalla lista_timer, nel caso di preemption, fallimento o uccisione del processo running – eventi segnalatigli dal global_monitor tramite la modifica di un apposito flag binario dell’elemento scritto nella coda input_clock – il timer logico relativo al TTC del processo referenziato, timer univocamente riconoscibile dalla sua caratteristica stringa ‘complete’ e dal PID del task stesso che vengono passati come parametri alla subroutine in questione.

73

if LISTA_TIMER(FIRST).SEGNALE=SIGNAL and LISTA_TIMER(FIRST).RUNNING=PID then RIMOZIONE_TESTA() else PREC:=FIRST; SUCC:=LISTA_TIMER(FIRST).NEXT; if SUCC/=MAX_LISTA+1 then while LISTA_TIMER(SUCC).SEGNALE/=SIGNAL or LISTA_TIMER(SUCC).RUNNING/=PID loop PREC:=SUCC; SUCC:=LISTA_TIMER(SUCC).NEXT; if SUCC=MAX_LISTA+1 then break end if end loop; if SUCC/=MAX_LISTA+1 then if LISTA_TIMER(SUCC).SEGNALE=SIGNAL and LISTA_TIMER(SUCC).RUNNING=PID then LISTA_TIMER(PREC).NEXT:=LISTA_TIMER(SUCC).NEXT; LISTA_TIMER(SUCC).NEXT:=FREE; FREE:=SUCC; end if end if end if end if

Listato 4.3 – Procedura RIMOZIONE_TIMER

TMP:=FIRST; FIRST:=LISTA_TIMER(FIRST).NEXT; LISTA_TIMER(TMP).NEXT:=FREE; FREE:=TMP

Listato 4.4 – Sotto-procedura RIMOZIONE_TESTA di RIMOZIONE_TIMER

La gestione dei TTC, della tabella TABLE di schedulazione dei processi pronti per l’esecuzione e dei segnali di attivazione/sospensione/completamento dei processi stessi è invece, come nelle precedenti versioni, ancora svolta direttamente dal global_monitor, che comunque si appoggia sempre al Clock Manager per tutte le questioni inerenti la temporizzazione. A questo punto però, fermi restando i già accennati aspetti positivi che questo approccio offre, in particolare la gestione centralizzata e trasparente del tempo basata su di un unico riferimento temporale unitario esterno di sistema, che permette tra l’altro il controllo diretto della risoluzione temporale e del playing dell’esecuzione simulata e un’espandibilità maggiore del modello, bisogna anche osservare che in fase di specifica sono venuti alla luce alcuni non trascurabili problemi implementativi. A parte la gestione delle code e dei segnali di scadenza temporale (complicata dall’uso delle generic instances e dalla realizzazione dei meccanismi SDL priority input e save) e la definizione dei necessari collegamenti (data-flow lines) aggiuntivi tra i processi del sistema, le difficoltà principali nella realizzazione di questa nuova versione sono state riscontrate proprio nell’implementazione delle procedure per la gestione della lista ordinata e soprattutto nella loro corretta integrazione nella semantica di esecuzione delle StateChart. Ciò è dovuto al fatto che le procedure in Statemate presentano delle notevoli limitazioni intrinseche (vedi il paragrafo sulle subroutine), in particolare l’impossibilità di usare puntatori, eventi e code al loro interno, e al problema che, se da una parte le subroutine presentano l’indubbio vantaggio della sequenzialità di esecuzione delle istruzioni (svolte tra l’altro sempre in tempo nullo), dall’altra risentono anch’esse, se pur indirettamente, della particolare e delicata questione della concorrenzialità di esecuzione delle azioni nel medesimo passo nelle StateChart Statemate (vedi paragrafo 4.2.5).

74

Per questo motivo nel Clock Manager, per l’aggiornamento completo e corretto della lista dei timer logici con le richieste temporali prelevate dalla coda input_clock e per il controllo e la rimozione della scadenza dei timer stessi, sono state utilizzate due opportune StateCharts (vedi Figura 4.26 e Figura 4.27) anziché i classici costrutti for e while, fermo restando tutte le procedure per la gestione della lista ordinata (vedi Listato 4.3, Listato 4.4, Listato 4.5, Listato 4.6 e Listato 4.7).

Figura 4.26 – StateChart aggiorna_lista_timer

Figura 4.27 – StateChart controllo_timer

75

if FIRST=MAX_LISTA+1 then INSERIMENTO_TESTA(LISTA) else if LISTA.SCADENZA+NOW<LISTA_TIMER(FIRST).SCADENZA then INSERIMENTO_TESTA(LISTA) else PREC:=FIRST; SUCC:=LISTA_TIMER(FIRST).NEXT; if SUCC/=MAX_LISTA+1 then while LISTA.SCADENZA+NOW>=LISTA_TIMER(SUCC).SCADENZA loop PREC:=SUCC; SUCC:=LISTA_TIMER(SUCC).NEXT; if SUCC=MAX_LISTA+1 then break end if end loop end if; TEMP:=FREE; FREE:=LISTA_TIMER(FREE).NEXT; LISTA_TIMER(TEMP).SEGNALE:=LISTA.SEGNALE; LISTA_TIMER(TEMP).SCADENZA:=LISTA.SCADENZA+NOW; LISTA_TIMER(TEMP).PID:=LISTA.PID; LISTA_TIMER(TEMP).RUNNING:=LISTA.RUNNING; LISTA_TIMER(PREC).NEXT:=TEMP; LISTA_TIMER(TEMP).NEXT:=SUCC end if end if

Listato 4.5 – Procedura INSERIMENTO_LISTA

TMP:=FREE; FREE:=LISTA_TIMER(FREE).NEXT; LISTA_TIMER(TMP).SEGNALE:=LISTA.SEGNALE; LISTA_TIMER(TMP).SCADENZA:=LISTA.SCADENZA+NOW; LISTA_TIMER(TMP).PID:=LISTA.PID; LISTA_TIMER(TMP).RUNNING:=LISTA.RUNNING; LISTA_TIMER(TMP).NEXT:=FIRST; FIRST:=TMP

Listato 4.6 – Sotto-procedura INSERIMENTO_TESTA di INSERIMENTO_LISTA

TMP:=FIRST; FIRST:=LISTA_TIMER(FIRST).NEXT; LISTA_TIMER(TMP).NEXT:=FREE; FREE:=TMP

Listato 4.7 – Procedura RIMOZIONE_HEAD

Bisogna inoltre aggiungere che in fase di esecuzione simulata, pur ottenendo come al solito time slices quantitativamente uguali dal punto di vista temporale a quelle della versione 7 e quindi con ottima approssimazione corrispondenti a quelle ottenute con la schedulazione ideale di riferimento (almeno nel caso di inter-arrival time non nulli), si è potuto osservare che il modello risulta innegabilmente più dispendioso in termini di passi, nel senso che per raggiungere lo stesso istante temporale di schedulazione di riferimento (419 clock units) questa volta sono stati necessari ben 2.500 steps, anziché i 1.100 riscontrati in media nelle precedenti versioni, e questo principalmente a causa della gestione aggiuntiva della coda input_clock e della lista ordinata dei timer logici. Del resto questo sensibile aumento nel numero di passi si manifesta direttamente in una notevole dilatazione proporzionale – secondo un costante fattore di scala – di tutte le time slices di schedulazione rispetto a quelle delle precedenti versioni e in un certo rallentamento nell’aggiornamento delle stesse nella Waveform grafica della simulazione interattiva.

76

Versione 13b: per concludere la trattazione della versione 13 e delle sue varianti, facciamo presente che ne è stata realizzata un’altra versione alternativa, chiamata 13b, che si differenzia dalla 13 solo per l’assenza di inter-arrival time e per il fatto che, allo scopo di evitare l’eventuale – se pur piccolo – ritardo (in termini di passi) introdotto dal meccanismo asincrono di comunicazione della coda input_clock tra l’effettivo istante di attivazione del processo correntemente running (condizione ATTIVO(RUNNING) resa vera e memorizzazione del tempo corrente NOW nella variabile LASTCLOCK) e l’effettivo aggiornamento ed inserimento del relativo timer logico ‘complete’ nella lista ordinata, le due istruzioni LASTCLOCK:=NOW e tr!(ATTIVO($LISTA.PID)) sono state spostate dal global_monitor alla StateChart aggiorna_lista_timer del Clock Manager, più precisamente subito dopo la chiamata alla procedura per l’inserimento nella lista della scadenza TTC aggiornata. In fase di simulazione interattiva abbiamo però potuto constatare che la schedulazione ottenuta con questa versione modificata, sebbene ancora temporalmente uguale a quella delle versioni con inter-time nulli precedenti la 13, presenta alcune differenze in quanto, a parte il solito fattore di scala della Waveform grafica, l’estrema vicinanza dei periodi di alcuni processi (compreso l’acceptance) al raggiungimento del loro minimo comune multiplo dovuta all’assenza di inter-arrival time provoca in questo caso la comparsa imprevista di piccole time slices spurie che comunque non invalidano la correttezza della schedulazione risultante poiché consumano solo e sempre passi svolti in tempo zero. Queste trascurabili interferenze – dovute presumibilmente ai ritardi tra la scrittura delle richieste ‘temporali’ nella coda input_clock e il loro effettivo inserimento nella lista dei timer logici – del resto si riscontrano, se pur diversamente, anche nelle altre versioni e varianti successive alla 13 quando impostiamo a zero il valore degli intertempi e i periodi dei processi sono multipli tra loro; oltre a ciò, a causa della diversa temporizzazione, il context switching della versione 13b risulta di 2-7 passi, leggermente maggiore di quello rilevato in tutte le altre precedenti versioni e varianti (2-4 passi). A conclusione di questo dettagliato excursus sulle varie versioni e relative varianti realizzate per la gestione del tempo nel modello Statemate riportiamo in Tabella 4.1 un riassunto delle loro principali caratteristiche.

77

versione o

variante

gestione dei vincoli

temporali

costrutti temporali

usati

uso di timer logici

context switching (misura in

passi)

numero di passi

all’istante di riferimento

(419)

Carta Parametrica (Generic) per

i processi proc_pcg

inter arrival time

settabili

breve descrizione

7, 7b decentralizzata sc!() no 2-4 1.400 no si timer-contatori

locali unitari per i TTC

8 decentralizzata sc!(), tm() no 2-4 1.100 no si

timer-contatore NOW unitario ext per i TTC e flag di

controllo per i timer ‘zombie’ sospesi

10 decentralizzata (tranne il TTC) sc!(), tm() no 2-4 1.100 no si

timer-contatore NOW unitario per il timer ext tm() del

TTC corrente

10b decentralizzata (tranne il TTC) sc!(), tm() no 2-4 1.100 si si equivalente alla

versione 10

11 centralizzata

nel Clock Manager ext

tm() ‘tick’ unico

unitario si 2-4 1.100 no no

timer-contatore NOW globale unico ext per timer logici

concorrenti

11b centralizzata

nel Clock Manager ext

tm() no 2-4 1.100 no no equivalente alla versione 11

12 centralizzata

nel Clock Manager ext

sc!(), tm() no 2-4 1.100 no no

timer-contatore NOW unico globale

e coda per tutti i timer sc!()

13 centralizzata

nel Clock Manager ext

tm() ‘tick’ unico

unitario

si, con lista

ordinata 2-4 2.500 si si

timer-contatore NOW unico globale

e coda per tutti i timer logici

13a, 13c, 13d

centralizzata e ‘trasparente’

nel Clock Manager ext

‘riusabile’

tm() ‘tick’ unico

unitario

si, con lista

ordinata 2-4 2.500 si si

come nella versione 13, ma il Clock

Manager scrive la scadenza

direttamente e automaticamente

nella coda del processo

richiedente

13b centralizzata

nel Clock Manager ext

tm() ‘tick’ unico

unitario

si, con lista

ordinata 2-7 2.500 si no

come nella versione 13, ma con

lastclock:=now e tr!(attivo(running)) nel Clock Manager

ext

Tabella 4.2 – Versioni e varianti realizzate per la gestione del tempo e loro principali caratteristiche

78

4.2.5 Semantica delle transizioni A questo punto rimane un’ultima ma altrettanto delicata questione da affrontare: la diversa semantica nell’esecuzione delle istruzioni in una transizione di stato SDL e in un corrispondente passo Statemate. La differenza in pratica, al di là di tutte le possibili considerazioni teoriche, consiste nel fatto che, mentre in SDL le istruzioni che fanno parte di una transizione di stato hanno sempre un ordine cronologico di esecuzione deterministico e quindi prevedibile, dettato dalla sequenzialità stessa delle istruzioni, come in un tradizionale linguaggio di programmazione, in Statemate, a parte casi particolari (le context variables e tutti i tipi di subroutines previsti dallo strumento, come vedremo tra poco), l’approccio di esecuzione delle StateCharts è radicalmente diverso. In particolare, in Statemate le istruzioni che fanno parte di un’action (in una transizione di stato) o di una static reaction (interna ad uno stato) non presentano, come in SDL, un rigoroso e predeterminato ordine di esecuzione, ma sono tutte eseguite concorrentemente (at once), aggiornando le variabili (data-item o condition) solo alla fine di un cosiddetto step (passo), in base ai valori del precedente stato. La dinamica delle StateCharts in Statemate può essere così schematizzata con il cosiddetto execution scenario (o run) di un modello (vedi Figura 4.28): partendo da uno stato iniziale (di default), il sistema evolve in una sequenza (chain) di stati passando ad ogni step da uno stato al successivo in risposta (reaction) agli stimoli o cambiamenti (input) esterni, agli eventi derivati e alle azioni generate dalle tutte le relevant reactions (transitions o static reactions) innescate dai rispettivi triggers nel precedente passo.

Figura 4.28 – Model execution scenario

Il problema nasce dal fatto che le transizioni di stato e le azioni, oltre all’esecuzione sequenziale (chain-reaction), data la potenziale natura ‘parallela’ delle StateCharts (nelle attività concorrenti o negli and-states), possono anche essere eseguite simultaneamente nel medesimo passo. Ciò può però condurre a comportamenti contraddittori o non deterministici quando diverse transizioni abilitate contemporaneamente conducono a stati differenti e soprattutto (come accade spesso nel nostro modello) quando uno stesso elemento è modificato e/o utilizzato più di una volta nel medesimo step, cioè in definitiva nel medesimo istante. Tali situazioni di accesso concorrente ad una stessa variabile (sia essa una condizione, un indice, un record o una coda), vengono brevemente chiamate in Statemate, a seconda del contesto, read-write racing o write-write racing situations. Alcune volte i racing riscontrati in fase di simulazione sono solo dei warnings (come nel caso delle input queues che per la loro natura di mezzi di comunicazione asincrona risultano condivisi e quindi ‘gestiti’ contemporaneamente da più processi concorrenti), ma spesso essi indicano problemi più gravi nella specifica del modello e, in quanto errori, vanno evitati o risolti.

status (initial)

… status status status status

step step step step

79

Questi racing errors rimandano direttamente al problema principale e iniziale di mancanza di una prevedibile sequenzialità operazionale e logica (true sequentiality) all’interno di compound actions (azioni composte) e di static reactions eseguite nel medesimo passo di esecuzione. A questo punto, le soluzioni adottabili per ovviare a questo comportamento spesso indesiderato sono tre:

1. Utilizzare appositi stati ‘ritardatori’

2. Utilizzare apposite subroutines

3. Utilizzare le variabili contestuali

Esse verranno illustrate in dettaglio nei paragrafi seguenti.

4.2.5.1 Stati ritardatori In effetti il primo metodo sembrerebbe il più semplice, anche se certamente il meno elegante ed economico dal punto di vista di implementazione pratica della specifica e comunque non sempre adottabile: esso consiste semplicemente nell’aggiungere all’occorrenza tra gli stati già previsti dalla specifica opportuni stati fittizi intermedi che funzionino da ritardatori nell’esecuzione del modello separando azioni o reazioni che operano sulla stessa variabile in blocchi di istruzioni che verranno eseguite in passi consecutivi e distinti, evitando così problemi di racing. Tali stati in pratica introducono nella dinamica del modello tanti step ‘artificiali’ aggiuntivi quanti sono necessari a ricreare una sequenzialità forzata nell’ordine di esecuzione delle operazioni, ma senza alterare in alcun modo la logica e la temporizzazione del sistema: da essi infatti si esce subito grazie alla particolare condizione trigger della transizione di uscita che risulta immediatamente vera ([true]) e il passo stesso viene eseguito nella simulazione Statemate sempre in un tempo nullo (vedi ad es. lo stato INIZIO in Figura 4.25). Questo approccio, anche se poco pratico, è stato tra l’altro utilizzato in tutti quei casi in cui la specifica SDL prevede un entry-point (indicato con una label) nel bel mezzo di una transizione di stato per poter separare le operazioni della compound transition (vedi ad es. lo stato VAR_ASSIGNED ancora in Figura 4.25).

4.2.5.2 Subroutines Il secondo metodo, anche se effettivamente adottato per implementare, con le opportune e necessarie modifiche, tutte le corrispondenti procedure SDL presenti nel modello [2] (vedi come esempio la semplice Procedural StateChart in Figura 4.29), ancora non risulta un approccio molto comodo dal punto di vista prettamente pratico, ma soprattutto presenta serie limitazioni in fase di specifica. Le subroutines implementabili (in C, Ada o Action Language) in Statemate, di qualunque tipo esse siano (functions, procedures o tasks secondo il tipo di parametri), presentano infatti l’indubbio vantaggio rispetto alle normali azioni o reazioni corrispondenti nelle StateCharts, di essere eseguite alla chiamata sempre in un solo passo (cioè in tempo zero, contrariamente alle procedure SDL che invece consumano

80

del tempo nella loro esecuzione) dall’inizio alla fine (come se fossero ‘transazioni atomiche’), ma questa volta rispettando rigorosamente l’ordine sequenziale di esecuzione dei singoli statements. Inoltre, come avviene in un tradizionale linguaggio di programmazione di tipo procedurale (e anche in SDL), tutte le variabili utilizzate (siano esse locali, globali o parametri) vengono aggiornate immediatamente durante l’esecuzione (e non tutte insieme alla fine dello step corrente come nelle StateCharts) e i loro nuovi valori sono subito disponibili per le operazioni dei successivi microstep. Bisogna comunque precisare che neanche le subroutines sono esenti da possibili errori di racing (tra l’altro in questo caso non segnalati in fase di simulazione e quindi completamente sotto la responsabilità del progettista), in particolare sui global elements modificati più di una volta all’interno della stessa subroutine (per ovviare a ciò nel nostro modello sono state utilizzate apposite variabili locali d’appoggio: vedi TABL in Figura 4.29); in questo caso però, anche se magari non corretto, si può determinare con esattezza il valore risultante finale restituito dalla subroutine chiamata, che altro non è che l’ultimo valore assegnato all’elemento in questione. In ogni caso, le subroutine Statemate presentano delle notevoli limitazioni che ne precludono quasi sempre l’uso nella dinamica delle StateCharts come possibile soluzione ai problemi di racing e di non determinismo nella sequenzialità di esecuzione delle istruzioni; un esempio emblematico è rappresentato dalla StateChart schedulability_test (vedi Figura 5.10) che per i suddetti limiti non è stato possibile implementare come subroutine. In particolare le principali limitazioni riscontrate sono le seguenti: • Subroutines richiamate da altre subroutines scritte in codice sorgente (C, Ada) non

possono essere né simulate né debuggate

• All’interno di funzioni e procedure Statemate, indipendentemente dal linguaggio di implementazione usato, non è ammesso alcun tipo di evento (sia esso input, output, variabile locale o globale)

• Nei trigger e nelle azioni non sono ammessi riferimenti ad Activity-Charts

• Non sono ammessi riferimenti a named actions (azioni definite con label

dall’utente)

• Non è ammesso l’uso dell’history state (che comunque non è mai stato utilizzato nel nostro modello)

• Per evitare problemi semantici e conflitti di temporizzazione nella dinamica di

esecuzione del modello, all’interno delle subroutines non è ammesso l’uso delle code (né come parametri di ingresso/uscita né come variabili locali o globali)

In pratica, le precedenti restrizioni riducono il campo d’azione delle subroutines alla sola lettura e scrittura di data-items regolari (che non siano cioè attività, eventi, azioni o code) e ciò, unito ad altre problematiche riguardanti la visibilità delle variabili in esse usate (resolution scope), le rende praticamente inutilizzabili per uno scopo diverso da quello già previsto da una procedura classica.

81

Figura 4.29 – Procedural StateChart RIMOZIONE

4.2.5.3 Variabili contestuali Alla luce quindi delle precedenti considerazioni non rimane altro che la terza ed ultima soluzione che – anche se non certo a favore di una desiderabile leggibilità e un’auspicabile sinteticità della specifica – permette, tranne rare situazioni, di superare eventuali problemi di racing e di temporizzazione delle istruzioni, garantendo quella sequenzialità logica ed operazionale con cui siamo ormai abituati a pensare e a lavorare nei tradizionali linguaggi di programmazione. Le context variables sono espressamente previste in Statemate proprio per ovviare agli inconvenienti succitati, in particolare nei casi di assegnazioni e letture/controlli eseguiti su una stessa variabile nel medesimo passo, che altrimenti avrebbero effetto solo alla fine dello step corrente usando quindi i valori vecchi e ancora non aggiornati del passo precedente. Tipico caso d’utilizzo delle variabili contestuali (che sono identificate dal prefisso $ per distinguerle dalle variabili regolari) è in tutte le iterative actions (cicli for e while) in cui l’indice contatore del ciclo deve essere di volta in volta aggiornato per il corretto funzionamento del loop stesso; un altro classico esempio del loro indispensabile utilizzo è quando vogliamo incrementare ed utilizzare il nuovo valore aggiornato di una variabile all’interno del medesimo step: $N:=N; $N:=$N+1; if $N=10 then action1 else action2 end if In questo caso infatti se usassimo la variabile N senza $ N:=N+1; if N=10 then action1 else action2 end if il controllo if N=10 verrebbe effettuato in base al valore che N aveva alla fine del precedente passo, poiché N viene incrementato solo alla fine del passo corrente. In generale quindi, le variabili contestuali vengono usate in tutte quelle compound actions o static reactions in cui un qualsiasi data-item (sia esso una variabile, una condizione, una coda o un record) deve necessariamente ottenere il suo nuovo valore immediatamente per la corretta esecuzione del passo. Proprio per questo motivo esse non servono nè sono ammesse nelle subroutines nelle quali, per loro stessa natura, tutte le variabili utilizzate si comportano già come context variables (assegnazione immediata).

82

Anche quest’ultimo approccio comunque presenta alcuni piccoli difetti: a parte la già accennata ridondanza apparente del codice, le variabili contestuali hanno una visibilità (scope) molto limitata e, contrariamente a tutti gli altri elementi del modello, non hanno una corrispondente definizione (entry) nel Data Dictionary del sistema ma ereditano il tipo dalla prima espressione ad esse assegnata, e devono essere prima esplicitamente inizializzate per poterle utilizzare (per gli altri elementi ciò non è obbligatorio, anche se spesso consigliabile).

83

5. Analisi del sistema specificato in Statemate

5.1 Versione 13 Di questa versione (con particolare riferimento alla variante 13c) ora analizzeremo ed illustreremo in dettaglio la specifica completa da noi implementata e simulata in Statemate, tralasciando e sottintendendo tutta la complessa e delicata questione della gestione dei vincoli temporali con relative problematiche e soluzioni già ampiamente discussa nel capitolo precedente. Innanzitutto, analogamente a come avviene per i modelli applicativi specificati in SDL, anche il modello Statemate può essere decomposto in vari livelli gerarchici, pur se con modalità e nomenclature diverse. Più in particolare, nel nostro caso la Chart al livello più alto nella gerarchia del modello riportata in Figura 5.1, e quindi la prima in assoluto ad essere attivata allo start-up dell’esecuzione simulata, è l’Activity Chart GRMS, la quale contiene al suo interno due grandi attività: l’attività principale SYSTEM_GRMS e la control-activity CLOCK. Mentra la prima sottende a tutta la modellazione del sistema dei processi, la seconda riguarda solo la trattazione del tempo, secondo quanto illustrato nel capitolo precedente. Queste due attività risultano collegate tra loro tramite opportune info-flow lines per il trasporto dei segnali e il loro nome è preceduto dal simbolo @ per indicare che sono state specificate per comodità di visualizzazione in rispettive off-page Charts appartenenti al livello inferiore (sub-chart): vedi Figura 5.2.

Figura 5.1 – Gerarchia del modello della versione 13c

84

Figura 5.2 – Top-Level Activity Chart GRMS

Aprendo la sub-chart @CLOCK viene infatti visualizzata la control-activity CLOCK, il cui funzionamento è stato già analizzato precedentemente e della quale riportiamo per completezza solo la StateChart senza ulteriori commenti (vedi Figura 5.3).

Figura 5.3 – StateChart clock

85

5.1.1 Activity-Chart SYSTEM_GRMS Aprendo invece la sub-chart @SYSTEM_GRMS viene visualizzata l’Activity Chart SYSTEM_GRMS contenente l’intero sistema modellizzato, con tutti i processi specificati, compresa l’external chart CLOCK, che tra l’altro provvede anche all’attivazione del SYSTEM_GRMS stesso in quanto sua control-activity, e le numerose data-flow lines per il loro collegamento (vedi Figura 5.4).

Figura 5.4 – Schema completo del SYSTEM_GRMS della versione 13c

5.1.1.1 Control-Activity PROC_GEN Iniziamo la descrizione della nostra specifica dal processo proc_gen, che rappresenta la control-activity del BLOCK_GRMS e quindi, almeno nelle prime fasi di vita del sistema, il ‘regista’ di tutte le sue sibling activities (attività sorelle allo stesso livello nella gerarchia delle Charts), occupandosi dell’attivazione (e dell’eventuale uccisione) dei processi simulati con tutti i relativi parametri di esecuzione. Più in particolare (vedi Figura 5.5) nella transizione iniziale (default transition) che conduce nello stato OPT_ASSIGNED vengono inizializzati i soliti record d’appoggio (elementi di code) ma soprattutto vengono inizializzati i vari campi d’interesse del record PROCESSES (riportati per comodità in Tabella 5.1) per tanti elementi del vettore OPT (di dimensione massima MAX_OPT) quanti sono i processi real-time che si vogliono simulare, tenendo presente che il loro numero non può superare il numero di istanze attualmente definite nel modello, nel nostro caso quattro, e che il loro tipo è già fissato a priori nella specifica. In questa versione i task sono sempre periodici critici garantiti e indipendenti, o più brevemente pcg, ma nelle versioni successive introdurremo altre tipologie predefinite con relativi parametri caratteristici di esecuzione.

86

Figura 5.5 – StateChart proc_gen

CAMPO TIPO BREVE DESCRIZIONE

OPERATION string operazione da effettuare con i parametri correnti: creating o killing INTERTIME integer inter-arrival time rispetto all’esecuzione dell’operazione precedente WCASE integer worst case computation time (WCCT) del processo pcg PERIOD integer periodo (ossia priorità secondo il RM) e deadline del processo pcg LATENCY integer tempo di latenza (attesa) massimo per il test di schedulabilità PID integer identificatore numerico univoco del processo (specificato a priori)

Tabella 5.1 – Parametri di esecuzione dei processi pcg simulati

In realtà del vettore OPT si possono inizializzare più elementi di quanti sono gli effettivi processi da attivare in quanto, a parte eventuali errori nella scrittura della stringa identificativa dell’operazione (in tal caso quell’elemento di OPT è semplicemente scartato e si passa al successivo), per specificare un’operazione di ‘uccisione’ forzata (killing) di un task è necessario inizializzare appositamente un elemento aggiuntivo di OPT, che comunque dovrà sempre seguire l’operazione di attivazione (creating) del processo da eliminare. Una volta specificato l’appropriato valore dei parametri di esecuzione per ciascun processo pcg istanziato, magari tenendo conto di alcune ovvie regole (ad es. alcuni tipi interi possono essere 0, come l’intertime, ma mai negativi; il wcase dovrà sempre essere minore o uguale al periodo, che a sua volta non potrà mai essere nullo o negativo; il PID sarà scelto secondo una numerazione progressiva partendo da 1, etc…), si potrà avviare la simulazione del sistema: il proc_gen inizierà così a leggere il primo elemento di OPT, o meglio il campo OPERATION relativo all’operazione da effettuare dopo l’intervallo di tempo (relativo) indicato nel campo INTERTIME. Se la stringa letta non è tra quelle previste (‘creating’ o ‘killing’) il processo si limiterà ad incrementare di un’unità l’indice I (azione INCR_I) della tabella OPT e a controllare

87

(stato CTRL) se il nuovo valore di I è ancora minore del parametro MAX_I (numero di elementi significativi di OPT maggiorato di 2): in caso affermativo (I<MAX_I) si rientra nello stato iniziale OPT_ASSIGNED e si procede alla lettura dell’elemento successivo del vettore OPT; in caso negativo (I>=MAX_I) la StateChart proc_gen terminerà definitivamente la sua esecuzione entrando nello stato senza uscita THE_END. Se invece la stringa è ‘creating’ o ‘killing’ (condizione [OPT(I).OPERATION=’creating’ or OPT(I).OPERATION=’killing’] vera) il processo entrerà rispettivamente (condition connector) nello stato WAIT_CREATING o nello stato WAIT_KILLING dopo avere in entrambi i casi (azione REQUEST_ACTION) scritto nella coda input_clock la sua richiesta ‘taction’ di scadenza temporale data dal valore del campo INTERTIME dell’elemento corrente del vettore OPT. A tal proposito cogliamo ora l’occasione per chiarire la sottile differenza che intercorre tra un condition connector ed uno stato fittizio intermedio che presenti le stesse condizioni di guardia nelle transizioni di uscita: il condition connector non introduce nessun ritardo (sia in termini di passi che di tempo simulato) nell’esecuzione delle operazioni della compound transition della quale fa parte e che infatti viene eseguita tutta in un unico passo; al contrario, uno stato intermedio in sua sostituzione (vedi ad es. lo stato CTRL in Figura 5.5), oltre a permettere la definizione di un’eventuale static reaction al suo interno (la cui presenza è indicata dal simbolo > accanto al nome dello stato), introduce quel piccolo ritardo forzato (sempre in termini di passi svolti in tempo nullo) che potrebbe risultare utile se non indispensabile per evitare eventuali problemi di racing nell’utilizzo (scrittura/scrittura o scrittura/lettura) di una stessa variabile nella medesima transizione, ossia in definitiva nel medesimo step, pur senza alterare in alcun modo la logica e la temporizzazione di funzionamento del sistema (per ulteriori chiarimenti si veda il paragrafo 4.2.5.1). Ritornando alla dinamica del proc_gen, non appena il segnale di scadenza ‘taction’ viene scritto dal Clock Manager (StateChart clock) nell’input queue del processo stesso (condizione [q_length(INPUT_PROC(0))>0] vera, dove 0 è proprio il PID del proc_generator), si innesca la transizione di uscita da uno dei due stati di attesa (WAIT_KILLING o WAIT_CREATING) con conseguente entrata (in entrambi i casi) nello stato ‘ritardatore’ INCR_I che provvede all’incremento unitario dell’indice I e a riportare la StateChart immediatamente ed incondizionatamente (condizione [true] sempre vera!) nello stato iniziale OPT_ASSIGNED per la lettura dell’eventuale elemento significativo successivo di OPT o la conclusione definitiva del ciclo stesso (stato THE_END). Nel caso di uscita dallo stato WAIT_CREATING, nell’azione GO_TO_I viene innazittutto svuotata l’input queue del proc_gen (comando q_flush(INPUT_PROC(0))) in modo da resettare la condizione [q_length(INPUT_PROC(0))>0] di trigger per la successiva operazione; nel contempo viene attivata con l’apposito comando start() l’Activity Chart contenente la generic instance del processo referenziato dal campo PID di OPT (il controllo è effettuato con una semplice serie di if statement che va eventualmente adattata prima dello start-up del sistema al numero e al nome dei processi definiti nella specifica) e, se non ancora attivate, vengono fatte partire anche le due attività global_monitor e acceptance che quindi iniziano la loro esecuzione sempre in contemporanea all’attivazione del primo processo simulato. In seguito all’attivazione della generic instance del processo vengono anche attualizzati tutti i valori dei suoi parametri formali i cui riferimenti (bindings) sono stati aggiornati dal proc_gen stesso (praticamente tutti i campi dell’elemento OPT(I) tranne OPERATION e INTERTIME, dove I coincide proprio con il PID del task attivato) e

88

sono quindi spediti sull’apposita data-flow line di collegamento tra il proc_gen e il proc_pcg stesso (ad esempio, su TO_PROC1_PCG_FROM_GEN transita OPT(1) da proc_gen a proc1). Infine, nel caso di uscita dallo stato WAIT_KILLING, nell’azione KILL_TO_I viene svuotata, come fatto precedentemente nell’azione GO_TO_I, la coda del proc_gen ma viene scritta in testa (comando q_urgent_put) all’input queue del processo referenziato (magari già attivato!) dal campo OPT(I).PID la stringa ‘kill’ che, come vedremo tra poco, segnala al task stesso la sua forzata uccisione da parte del proc_gen.

5.1.1.2 I processi periodici critici garantiti Ora, aprendo la sub-chart di uno qualsiasi dei processi pcg presenti nella specifica (ad es. @PROC1) viene visualizzata una Chart del tipo in Figura 5.6 nella quale, a parte la replica di tutte le necessarie interfacce di collegamento IN/OUT del processo in questione con gli altri processi del sistema già viste nel SYSTEM_GRMS, è presente l’Activity Chart contenente al suo interno come unica control-activity proprio la generic instance (PROC1_PCG<PROC_PCG) del task di tipo pcg con PID=1; le charts degli altri processi pcg sono tutte perfettamente analoghe (è infatti possibile costruirle facilmente con un veloce copy&paste e con opportuni adattamenti formali alla specifica basandosi sempre sulla stessa Generic StateChart di riferimento). Per inciso, la visualizzazione e l’eventuale modifica di tutti i parametri formali della generic instance aperta, del loro tipo e dei relativi actual bindings viene effettuata richiamando l’apposito Data Dictionary Editor della control-activity stessa.

Figura 5.6 – Off-page chart PROC1 della versione 13c

89

A questo punto possiamo passare direttamente alla descrizione della specifica della Carta Parametrica per i processi periodici critici garantiti (pcg) e indipendenti (vedi Figura 5.7), rimandando per tutta la loro analisi teorica al paragrafo 2.2.1. All’attivazione della generic instance la prima azione effettuata (INIT) inizializza i soliti record d’appoggio (componenti di code) e conduce nello stato iniziale TLATENZA: la static reaction al suo interno scrive nella coda input_clock, o meglio nel parametro d’uscita INPUT_CLOCK_P ad essa riferito, la richiesta di scadenza temporale ‘tlatenza’, il cui valore, dato dal parametro d’ingresso LATENCY, indica quanto tempo il processo è disposto ad aspettare per l’esito del test di schedulabilità, insieme al suo PID univoco di riconoscimento; tale PID servirà al Clock Manager per individuare l’input queue giusta nella quale scrivere al momento opportuno l’evento di avvenuta scadenza. Fatto ciò, il processo passa immediatamente (condizione [true] sempre vera) nello stato successivo (WAIT_RESPONSE) inviando nel contempo all’acceptance la sua richiesta di schedulazione con la scrittura (azione WRITE_REQUEST_QUEUE) nella coda REQUEST_QUEUE (ovvero nel parametro d’uscita REQUEST_QUEUE_P) dei valori attuali dei suoi parametri caratteristici di esecuzione: WCASE (tempo di computazione del task nel caso peggiore, chiamato anche WCCT, uguale e costante per ciascuna istanza periodica), PERIOD (costante nel tempo), indicante la deadline dell’istanza corrente e l’istante di inoltro della richiesta di esecuzione della successiva istanza, e il solito PID.

Figura 5.7 – Generic StateChart proc_pcg

90

Tali parametri serviranno, come vedremo tra poco, alla StateChart schedulability_test per effettuare l’analisi di schedulabilità basata sull’algoritmo del Rate Monotonic (RM) o eventualmente il test di garanzia di esatta schedulabilità basato sulla zona critica (Generalized Rate Monotonic Scheduling o GRMS), per la cui teoria si rimanda al paragrafo 2.2.3. Dallo stato WAIT_RESPONSE il processo potrà uscire solo quando almeno un ‘evento’ verrà scritto nella sua input queue (condizione [q_length(INPUT_NEW_PROC_P)>0] vera, ossia coda non vuota): in questo caso la static reaction interna allo stato GET_RESPONSE preleverà dalla succitata coda il primo elemento in testa, in base al quale verrà generato l’evento trigger (TLATENZA, NACK, CICLO o GRANT) che condurrà nel successivo stato (rispettivamente LATENZA, NACK, WAIT_RESPONSE e GRANTED). Nel primo caso (scadenza del timer logico ‘tlatenza’) è stato raggiunto e superato il tempo massimo di attesa da parte del processo per la risposta alla sua richiesta di schedulazione: il task non è riuscito neanche a partire ed entra nello stato senza uscita TLATENZA; contestualmente alla generazione dell’evento TLATENZA viene resa vera la condizione (parametro d’uscita) LATENZA_ACC_P con la quale il processo stesso comunica prontamente all’acceptance o allo schedulability_test che la sua latenza è scaduta indicando così l’inutilità di iniziare il suo test di garanzia o, nel caso invece esso sia già iniziato, la necessità di concluderlo senza successo. Nel secondo caso (generazione dell’evento NACK) il processo è stato rifiutato dallo schedulability_test poiché il sistema non può garantire sulla base del carico di lavoro corrente e della teoria del RM (o eventualmente del GRMS) la fattibilità della schedulazione con l’aggiunta del nuovo task: è stato dunque scritto nell’input queue del processo l’apposito segnale (stringa) ‘nack’ la cui lettura innesca l’entrata nello stato senza uscita NACK. Nel terzo caso (previsto solo per sicurezza, in quanto non possibile in condizioni di corretto funzionamento del sistema), l’elemento letto dall’input queue non corrisponde a nessun segnale atteso e quindi viene generato l’evento CICLO che fa ritornare la StateChart nello stato WAIT_RESPONSE in attesa della scrittura di un successivo evento nella coda; tali cicli sono stati comunque previsti in tutti i casi analoghi di lettura della coda d’ingresso (stati GET_EVENT_FROM_QUEUE e GET_TPERIODO_FROM_QUEUE) dove, come abbiamo potuto osservare grazie alla simulazione, non sempre risultano superflui. Nel quarto ed ultimo caso il processo ha ricevuto dall’acceptance il segnale ‘grant’ con il quale gli viene comunicato l’esito positivo dell’analisi di schedulabilità e la conseguente accettazione della sua richiesta di schedulazione con la garanzia, almeno in linea teorica, di poter rispettare la presente e tutte le sue future deadline periodiche; solo in tali condizioni il task può entrare nello stato GRANTED e poi immediatamente (condizione [true] già vera) nello stato WAIT_ACTIVATION, dopo aver scritto nell’input_clock la richiesta ‘tperiodo’ di scadenza temporale del suo periodo ed aver inviato al global_monitor la richiesta di partenza scrivendo con l’azione WRITE_PARTITO_QUEUE nella coda PARTITO_QUEUE, o meglio nell’apposito parametro d’uscita PARTITO_QUEUE_P, tutti i suoi parametri caratteristici di esecuzione: WCASE, PERIOD, PRIO (che per i task pcg, essendo schedulati con l’algoritmo RM, coincide sempre con il periodo) e il PID. Nello stato WAIT_ACTIVATION il processo attende il segnale START_TM_P con il quale il global_monitor gli comunica la sua effettiva partenza. Come vedremo meglio più avanti nella descrizione dell’acceptance e del global monitor, il task pcg accettato e partito è stato inserito nella tabella TAB dei processi garantiti e in quella TABLE dei

91

processi pronti, ma può prendere possesso della CPU ed eseguire solo se e quando diventa il primo della tabella TABLE per priorità. Se il segnale START_TM_P arriva prima della scadenza del periodo corrente (stringa ‘tperiodo’ scritta dal Clock Manager nella coda d’ingresso INPUT_NEW_PROC_P) e prima di un’eventuale uccisione del processo (stringa ‘kill’ scritta dal proc_gen sempre nell’input queue) il task può entrare nello stato EXECUTING_OR_SUSPENDED. In caso contrario, o meglio nel caso di uccisione ‘forzata’ del processo (in condizioni di normale e corretto funzionamento del sistema il task pcg, essendo per sua natura garantito, non può superare la sua deadline e fallire), la condizione [q_length(INPUT_NEW_PROC_P)>0] vera innesca la transizione dallo stato WAIT_ACTIVATION allo stato GET_EVENT_FROM_QUEUE nel quale, letto il primo elemento della coda d’ingresso (non vuota), viene generato l’evento KILL e il processo entra così nello stato senza uscita KILLED dopo aver comunicato la sua morte all’acceptance rendendo vera la condizione KILLED_ACC_P con l’azione KILLED. Quando si trova nello stato EXECUTING_OR_SUSPENDED, come suggerisce il nome stesso, il processo o sta svolgendo la sua esecuzione simulata oppure è stato momentaneamente sospeso da un processo pronto a priorità più alta; in questo stato si permane finché non viene scritto un segnale nella coda d’ingresso (condizione [q_length(INPUT_NEW_PROC_P)>0] vera): in tal caso si entra nello stato GET_EVENT_FROM_QUEUE la cui static reaction preleva il primo elemento in testa alla coda stessa e in base alla stringa in esso contenuta genera l’evento CICLO, TPERIODO, KILL o COMPLETE. Trascurando il già discusso evento CICLO, nel secondo caso di scadenza prematura del periodo, in modo perfettamente analogo a quanto avviene nel terzo caso già analizzato del KILL, il processo entra nello stato senza uscita FAILURE dopo aver comunicato il suo fallimento all’acceptance sempre tramite l’apposita condizione KILLED_ACC_P con l’azione FAILED. Nel quarto ed ultimo caso invece di corretto funzionamento del sistema il global_monitor ha segnalato al processo il completamento dell’esecuzione della sua istanza periodica corrente scrivendo l’apposita stringa ‘complete’ nell’input queue del processo stesso: l’evento COMPLETE generato di conseguenza conduce la StateChart nello stato di corretta esecuzione SUCCESSFUL_EXECUTED dal quale il task uscirà solo in seguito alla scrittura del segnale di scadenza del timer logico ‘tperiodo’ nella sua coda d’ingresso (condizione [q_length(INPUT_NEW_PROC_P)>0] vera) con conseguente entrata nello stato GET_TPERIODO_FROM_QUEUE e lettura del segnale atteso, lettura che a sua volta genererà l’evento TPERIODO la cui transizione abilitata riporterà la StateChart nello stato GRANTED per la richiesta di partenza della successiva istanza periodica del processo.

5.1.1.3 Il processo ACCEPTANCE Passiamo ora ad analizzare il modulo di acceptance preposto all’analisi di schedulabilità, eventualmente esatta, per i processi pcg, come già spiegato nel paragrafo 2.2.3.1. All’entrata nello stato ritardatore iniziale INIZIO (vedi Figura 5.8) nell’azione INIT vengono inizializzati vari data-items: i campi PID e P (periodo o priorità) della tabella TAB dei processi garantiti (il rimanente campo WCASE non necessita d’inizializzazione), i parametri di esecuzione caratteristici di acceptance (ACCWCASE, ACCPERIOD, STEP, MAXACCPER, MINACCPER), l’indice I della tabella TAB e i soliti record d’appoggio. All’uscita dallo stato INIZIO nell’azione VAR_ASSIGN

92

vengono inizializzate altre variabili: ciascun elemento del vettore V(i) con il limite superiore per il fattore di utilizzazione U fornito dalla teoria del Rate Monotonic per un numero i di processi pcg schedulati (nel nostro caso in teoria massimo1 17, compreso l’acceptance, ma nella pratica non oltre 5), il fattore di utilizzazione stesso con il valore ACCWCASE/ACCPERIOD (a tal proposito notiamo una volta per tutte che il WCCT e il periodo di un qualsiasi processo, sebbene definiti integer, devono essere all’occorrenza ridefiniti real per evitare che venga effettuata una divisione intera tra i loro valori), il PID (variabile ADDRESS) dell’acceptance con il valore convenzionale MAX_P–1 e la prima riga della tabella TAB con alcuni parametri di esecuzione dello stesso acceptance precedentemente inizializzati (ACCWCASE, ACCPERIOD e PID). All’uscita immediatamente successiva dallo stato VAR_ASSIGNED nell’azione USCITA_DA_VAR vengono scritte nella coda input_clock le richieste delle due scadenze temporali relative al processo acceptance (‘tperiodo_acc’ per il suo periodo e ‘tcontrollo_acc’ per il suo timer di controllo) e nella coda PARTITO_QUEUE i soliti parametri necessari (WCCT, PID e periodo); con quest’ultima scrittura il processo comunica al global_monitor, seppur in modo asincrono dovuto all’uso della coda, la sua partenza che, a differenza di quanto avviene per tutti gli altri task pcg, è una partenza immediata e non una richiesta essendo l’acceptance sempre il primo processo real-time di tipo pcg ad essere schedulato e quindi, anche se come gli altri potrà subire preemption, è intrinsecamente garantito e non deve sottostare ad alcun test di garanzia preliminare (il suo fattore di utilizzazione non deve ovviamente superare 1).

Figura 5.8 – StateChart acceptance della versione 13c

1 Tale costante è stata ereditata dal modello SDL di riferimento nel quale bisogna fissare a priori nella specifica il numero minimo e massimo di istanze per un determinato processo; nel nostro caso comunque è possibile cambiare all’occorrenza tale valore modificando semplicemente l’apposito parametro MAX_P.

93

A questo punto si entra nella parte centrale della StateChart: lo stato @WAIT; aprendo la sub-chart ad esso collegata viene visualizzata l’off-page StateChart riportata in Figura 5.9. Il processo entra nello stato iniziale WAIT e vi rimane finché non è verificata almeno una delle tre condizioni di guardia: any(KILLED_ACC), la quale indica che almeno un processo è ‘morto’ (ucciso o fallito); q_length(INPUT_PROC(MAX_P-1))>0, la quale indica che nella coda d’ingresso di acceptance è stato scritto almeno un segnale di scadenza temporale da parte del Clock Manager; q_length(REQUEST_QUEUE)>0, la quale indica che almeno un elemento è stato scritto da un task pcg nella coda di richiesta per l’analisi di schedulabilità. Dunque, appena una delle tre condizioni diventa vera si entra nello stato READ_KILLED_OR_QUEUE: la static reaction al suo interno controlla innanzitutto se un task è morto (priority input SDL) ricercando nell’apposito vettore ‘condiviso’ di condizioni KILLED_ACC l’eventuale relativo elemento reso vero dal processo stesso; in caso affermativo la condizione di flag viene resettata per un suo eventuale futuro utilizzo e il PID del task ucciso (coincidente con l’indice corrente del vettore) viene assegnato alla variabile SENDER che verrà utilizzata dalla procedura REMOVING (vedi Figura 5.66) per la conseguente rimozione del processo referenziato dalla tabella TAB. A tale scopo viene generato l’evento KILLED_OR_FAILED che innesca l’immediata uscita dallo stato @WAIT: nella transizione di stato che ne consegue viene richiamata la succitata Procedural StateChart REMOVING che si occupa anche di aggiornare opportunamente il valore del fattore di utilizzazione U e di decrementare eventualmente il periodo dell’acceptance richiamando l’apposita subroutine DECR_PERIOD (vedi Figura 5.58), la quale a sua volta si occupa di aggiornare nuovamente U, il periodo in questione nella tabella TAB con il nuovo valore calcolato e, se necessario, la tabella stessa tramite la sua sotto-procedura AGGIORNA_ACCPERIODO_TAB (vedi Figura 5.54). Eseguita la procedura REMOVING si rientra nuovamente nello stato @WAIT; nel caso invece, in seguito alla scadenza del timer logico TCONTROLLO (altro priority input SDL), venga scritta la stringa ‘tcontrollo_acc’ nell’input queue dell’acceptance, viene generato l’apposito evento TCONTROLLO che innesca la transizione dallo stato @WAIT allo stato WAIT_COMPLETE. Prima però di analizzare questa situazione, supponiamo che sia verificata la terza ed ultima condizione: q_length(REQUEST_QUEUE)>0.

Figura 5.9 – Sub-Chart wait

94

In questo caso nella static reaction interna allo stato READ_KILLED_OR_QUEUE viene generato l’evento REQUEST_SIG che innesca la transizione dallo stato @WAIT allo stato ritardatore LATENZA durante la quale con azione READ_REQUEST_QUEUE viene prelevato l’elemento in testa alla coda REQUEST_QUEUE e in base ai valori dei suoi campi vengono aggiornate rispettivamente le variabili WCASE, PERIOD e SENDER, che serviranno per il controllo della condizione LATENZA_ACC(SENDER) e per l’aggiornamento del fattore di utilizzazione U in vista della successiva analisi di schedulabilità. Più in particolare, se la latenza del processo con PID=SENDER è già scaduta (condizione [LATENZA_ACC(SENDER)] vera) si rientra immediatamente nello stato @WAIT (è inutile effettuare il test di garanzia); in caso contrario (latenza non ancora scaduta, ossia condizione [not LATENZA_ACC(SENDER)] vera) si entra nello stato @SCHEDULABILITY_TEST per procedere finalmente con il test di garanzia.

5.1.1.4 StateChart SCHEDULABILITY_TEST Aprendo la sub-chart @SCHEDULABILITY_TEST viene visualizzata l’off-page Chart riportata in Figura 5.10 e relativa al test di schedulabilità per i processi pcg (vedi paragrafo 2.2.3.1).

Figura 5.10 – Sub-Chart schedulability_test

Iniziamo la sua analisi: l’azione INCR_I presente nella default transition che conduce nello primo stato APPOGGIO incrementa immediatamente di un’unità, utilizzando un’apposita variabile contestuale, l’indice I del vettore V il cui elemento i-esimo, come abbiamo visto, contiene il valore del limite superiore consentito per il fattore di utilizzazione U per poter garantire una schedulazione fattibile di I processi secondo il

95

Rate Monotonic. All’entrata nello stato APPOGGIO viene salvato in un’apposita variabile d’appoggio il valore corrente di U e solo al suo effettivo aggiornamento (evento wr(APPOGGIO)) si può entrare nel successivo stato intermedio U nel quale viene incrementato il fattore di utilizzazione con il nuovo contributo WCASE/PERIOD dato proprio dal processo che richiede di essere schedulato. All’avvenuto aggiornamento di U (evento wr(U)) si entra nello stato CTRL_1_U che rappresenta il primo stadio del test di schedulabilità (vedi ancora il paragrafo 2.2.3.1): se il nuovo valore di U appena calcolato non è superiore all’upper bound V(I) (condizione [U<=V(I)] vera) allora si entra nello stato LATENZA dal quale si arriva nello stato finale THE_END direttamente o meno a secondo che la latenza del processo sia scaduta o meno. Nel primo caso (condizione [not LATENZA_ACC(SENDER)] vera) il processo è accettato per la schedulazione (nell’azione GRANT_TO_SENDER viene scritta l’apposita stringa ‘grant’ nell’input queue del task referenziato dal PID SENDER) e viene inserito nella giusta posizione nella tabella TAB dei processi garantiti dall’apposita procedura (Procedural StateChart) AGGIORNO_TABELLA (vedi Figura 5.56); la tabella è gestita come una coda e viene ordinata in base alle priorità, ossia ai periodi. Nel secondo caso invece (condizione [LATENZA_ACC(SENDER)] vera) il processo è rifiutato (nell’azione NACK_TO_SENDER viene scritta l’apposita stringa ‘nack’ nell’input queue del task referenziato dal PID SENDER): il fattore di utilizzazione U ‘riacquista’ il suo valore originale (conservato in APPOGGIO) e viene decrementato di un’unità l’indice I che rappresenta il numero di processi pcg attualmente presenti nella tabella TAB e quindi schedulati. Ritornando allo stato CTRL_1_U, se il valore di U aggiornato è maggiore dell’upper bound V(I) (condizione [U>V(I)] vera) allora si entra nello stato CTRL_2_U, dal quale si esce o per entrare nello stato NACK già visto o per entrare nello stato ACCETTATO: nel primo caso il nuovo valore di U è maggiore della soglia massima MAX_U (questo parametro viene stabilito a priori sulla base del massimo carico di lavoro che si vuole il sistema sopporti per i processi pcg e, come nel nostro caso, può teoricamente essere persino 1 anche se poi nella pratica un valore di 0.95 è più che accettabile per i nostri esperimenti) e quindi il processo viene direttamente rifiutato senza ulteriori ‘appelli’; nel secondo caso invece (condizione [U<MAX_U] vera) si passa al secondo stadio dell’analisi di schedulabilità: la complessa Procedural StateChart CRITICAL_ZONE_TEST (vedi Figura 5.57) effettua un test di garanzia di esatta schedulabilità basato sulla zona critica: l’esito di questo algoritmo, riportato nella variabile ACCEPTED, deciderà la sentenza finale sulla schedulabiltà del processo richiedente, ferma restando la condizione sulla sua latenza. Comunque, per qualsiasi combinazione di eventi e per qualunque risultato sul test di schedulabiltà, alla fine si entra sempre nello stato THE_END nel quale viene generato l’evento USCITA che innesca la transizione dallo stato @SCHEDULABILITY_TEST allo stato @WAIT.

5.1.1.5 Ancora sul processo ACCEPTANCE A questo punto, l’ultima transizione di uscita dallo stato @WAIT che ci rimane da analizzare è quella innescata all’evento TCONTROLLO generato in seguito alla scadenza del timer logico di sicurezza ‘tcontrollo_acc’ (per il cui significato si rimanda alle considerazioni relative alla versione 13 nel paragrafo 4.2.4), settato dall’azione

96

USCITA_DA_VAR al valore2 ACCWCASE–3, dove ACCWCASE è il Worst Case Computation Time (fissato a priori e costante contrariamente al periodo che può invece variare, seppur in modo discreto ed entro certi limiti, durante l’esecuzione simulata) dell’acceptance. In tale evenienza il processo entra nello stato WAIT_COMPLETE richiamando nel contempo la subroutine INCR_PERIOD (vedi Figura 5.60) la quale, in modo perfettamente duale alla procedura DECR_PERIOD (vedi Figura 5.58), incrementa all’occorrenza il periodo dell’acceptance, in modo da far diminuire il fattore di utilizzazione U; in tal caso la Procedural StateChart si occupa dell’aggiornamento del valore di U e la sotto-procedura AGGIORNA_ACCPERIODO_TAB (vedi Figura 5.54) di quello del periodo dell’acceptance nella tabella TAB, con eventuale suo riordinamento. In tale stato (WAIT_COMPLETE) il processo aspetta finché il global_monitor non gli comunica il completamento della sua istanza periodica corrente rendendo vera la condizione COMPLETATO, appositamente scelta per poter implementare il costrutto save SDL nella specifica Statemate (come descritto nel paragrafo 4.2.2). Appena tale condizione diventa vera l’acceptance entra finalmente nello stato @EXECUTED_AND_WAIT_PERIOD nel quale l’istanza corrente è stata correttamente eseguita e il processo non aspetta altro che la scadenza del timer logico del suo corrente periodo. A tale scopo (vedi StateChart in Figura 5.11) esso rimane nello stato WAIT_QUEUE fino a quando non viene scritto almeno un evento nella sua coda d’ingresso, nel qual caso (condizione [q_length(INPUT_PROC(MAX_P-1))>0] vera) si entra nello stato READ_FROM_QUEUE la cui static reaction preleva il primo elemento della coda e, se la stringa letta è proprio quella attesa, cioè ‘tperiodo_acc’ (e in condizioni di normale funzionamento del sistema non può essere altrimenti, ossia non ci può essere un ciclo), genera l’evento TPERIODO_ACC. Questo evento a sua volta innesca la transizione dallo stato @EXECUTED_AND_WAIT_PERIOD allo stato VAR_ASSIGNED con conseguente ripartenza – dopo aver resettato la condizione COMPLETATO – di una nuova successiva istanza periodica di acceptance, con un periodo magari diverso, e dei relativi timer logici di periodo e di controllo.

Figura 5.11 – Sub-Chart executed_and_wait_period

2 Tale valore è stato direttamente mutuato delle specifiche del modello SDL nel quale per il modulo di acceptance è previsto un margine di sicurezza del 30% (3/ACCWCASE, dove ACCWCASE è fissato a 10).

97

5.1.1.6 StateChart GLOBAL_MONITOR L’ultima Chart del modello che rimane da analizzare è il processo global_monitor che, pur avendo una specifica relativamente semplice, rappresenta il cuore di tutto il funzionamento del sistema real-time simulato, occupandosi di regolare e sincronizzare gli accessi alla CPU da parte dei vari processi pronti schedulandoli secondo una gestione multitasking, timesharing e preemptive delle risorse basata su priorità. Ma procediamo con ordine: aprendo la sub-chart @PROC_GLOBAL_MONITOR presente nel SYSTEM_GRMS viene visualizzata la relativa off-page chart riportata in Figura 5.12. In questa Activity Chart, fermi restando tutti i collegamenti IN/OUT con le altre Carte del modello, è presente come unica internal activity la control-activity @GLOBAL_MONITOR, la cui off-page Chart contiene a sua volta la StateChart global_monitor riportata in Figura 5.13.

Figura 5.12 – Off-page chart PROC_GLOBAL_MONITOR

Iniziamo dunque l’analisi dettagliata di quest’ultima: nell’azione INIT_TABLE lungo la default transition che conduce nello stato iniziale WAIT_PROCESS vengono inizializzati, oltre ai necessari record d’appoggio, i campi PID e P (priorità o periodo) della tabella TABLE che rappresenta la coda dei processi pronti e che sarà ordinata, come la tabella TAB dei processi garantiti, sempre in base alla priorità dei task stessi. Una volta entrato alla sua attivazione nello stato WAIT_PROCESS, il global_monitor vi rimane fino a quando non viene scritto almeno un elemento nella coda

98

PARTITO_QUEUE da parte di un task real-time che ha quindi richiesto di essere schedulato; a tal proposito ricordiamo che il primo processo garantito a scrivere nella coda PARTITO_QUEUE sarà necessariamente l’acceptance, anche se poi potrà subire magari immediatamente preemption da parte di un task pcg a priorità più alta, cioè con un periodo minore, secondo l’algoritmo di schedulazione Rate Monotonic. Appena ciò accade (condizione [q_length(PARTITO_QUEUE)>0] vera) la StateChart entra nel successivo stato RUN dopo aver letto l’elemento in testa alla coda PARTITO_QUEUE ed aver aggiornato di conseguenza tutti i rispettivi campi – P ossia periodo o priorità, TTC ossia time-to-complete (inizialmente coincidente con il WCASE del processo) e il solito PID – del primo elemento della tabella TABLE.

Figura 5.13 – StateChart global_monitor della versione 13c

La static reaction interna allo stato ritardatore RUN si occupa di aggiornare con il valore TABLE(1).PID (non appena questo viene effettivamente scritto) la variabile integer RUNNING (inizializzata di default a 0 dal sistema stesso) che conterrà sempre il PID del task a priorità più alta (top-prio) nella tabella TABLE e quindi correntemente in possesso della CPU, o eventualmente il PID dell’ultimo processo che ha eseguito nel caso non ci siano momentaneamente più processi pronti da schedulare. Una volta aggiornato il valore di RUNNING, la generazione dell’evento corrispondente (wr(RUNNING)) innesca l’azione TIMER e la transizione nel successivo stato @WAIT_COMPLETATION_OR_NEW_START.

99

Nell’azione TIMER vengono effettuate diverse importanti operazioni: innanzitutto viene salvato nell’apposita variabile LASTCLOCK il valore del contatore NOW che rappresenta il tempo assoluto corrente ed unico di riferimento per tutto il nostro sistema simulato; tale variabile, come vedremo tra poco, servirà a calcolare il tempo effettivamente consumato dal processo RUNNING dalla sua effettiva attivazione alla sua eventuale sospensione (preemption) da parte di un altro processo pcg pronto a priorità più alta. Oltre a questo, nell’azione TIMER viene generato l’evento START_TM(RUNNING) con il quale il global_monitor, come già accennato, segnala prontamente al processo con PID=RUNNING la sua effettiva attivazione; a tal riguardo, viene anche resa vera la condizione ATTIVO(RUNNING) che permette di monitorare in ‘tempo reale’ lo stato di attivazione del task referenziato tramite l’apposita waveform grafica della simulazione interattiva (vedi gli esempi illustrati alla fine del capitolo 6). Infine, sempre in tale azione, viene scritta nella coda input_clock del Clock Manager la richiesta di scadenza temporale ‘complete’ relativa al TTC attuale del processo attivato (campo TABLE(1).TTC) corredandola del suo univoco PID di riconoscimento (variabile RUNNING) per la successiva identificazione del timer logico in questione nel caso di scadenza o rimozione dello stesso.

Figura 5.14 – Sub-Chart wait_completation_or_new_start

Una volta entrati nello stato @WAIT_COMPLETATION_OR_NEW_START (vedi StateChart in Figura 5.14), si permane nello stato iniziale WAIT_QUEUE fino a quando non viene scritto almeno un elemento o nella coda PARTITO_QUEUE o nell’input queue del global_monitor stesso (condizione [q_length(INPUT_PROC(MAX_P))>0 or q_length(PARTITO_QUEUE)>0] vera, dove MAX_P è proprio il PID convenzionalmente assegnato al global_monitor). In tale evenienza si entra nello stato READ_QUEUE, la cui static reaction controlla innanzitutto (priority input SDL) che la coda d’ingresso del global_monitor non sia vuota, nel qual caso ne preleva il primo elemento controllando se la stringa in esso contenuta è proprio quella attesa (‘complete’) e se il suo PID coincide con il valore corrente di RUNNING. Quest’ultima condizione, come del resto l’evento CICLO, è stata aggiunta semplicemente per sicurezza in quanto, se la specifica è corretta e tutto funziona ‘a dovere’, l’unico segnale che può essere scritto nell’input queue del global_monitor è proprio quello di ‘complete’ e si riferisce sempre al processo

100

RUNNING. In caso affermativo (scadenza del timer logico relativo al TTC del task pcg attualmente in esecuzione ossia completamento corretto della sua istanza periodica corrente) viene resa vera l’apposita condizione di monitoraggio FINE(RUNNING) e viene nel contempo generato l’evento TFINE che a sua volta innesca l’azione FINITO e la transizione dallo stato @WAIT_COMPLETATION_OR_NEW_START allo stato PID. Ritornando invece allo stato READ_QUEUE interno alla sub-chart WAIT_COMPLETATION_OR_NEW_START, nel caso l’unica coda non vuota sia PARTITO_QUEUE, ne viene letto l’elemento in testa aggiornando con i valori dei suoi campi (PID, WCASE e PERIODO) rispettivamente le variabili SENDER, WCASE e PERIODO relative al nuovo processo partito (azione READ_PARTITO) e viene inoltre generato l’evento PARTITO_SIG che a sua volta innesca la transizione dallo stato corrente @WAIT_COMPLETATION_OR_NEW_START allo stato PERIODO. In questo stato ritardatore si controlla se il periodo del processo che richiede di essere schedulato è minore oppure maggiore o uguale del periodo del primo (top-prio) processo nella tabella TABLE che sta attualmente eseguendo. Nel primo caso (condizione [PERIODO<TABLE(1).P] vera) secondo la teoria del Rate Monotonic il nuovo arrivato ha priorità maggiore del task RUNNING e quindi quest’ultimo subisce prelazione da parte del primo: nell’azione che ne consegue (PREEMPTION) viene innanzitutto resa falsa la condizione di monitoraggio ATTIVO(RUNNING) scrivendo nel contempo nella coda input_clock una richiesta di rimozione (flag binario RIMOZIONE posto uguale a 1) del timer logico relativo al TTC corrente del processo appena sospeso; tale timer ‘zombie’ verrà univocamente riconosciuto nella lista_timer grazie alla sua caratteristica stringa ‘complete’ e al suo PID coincidente con il valore attuale di RUNNING. Oltre a questo, viene calcolato tramite la differenza tra il NOW corrente e il LASTCLOCK precedente il tempo simulato effettivamente trascorso (ELAPSED) dall’attivazione del processo RUNNING alla sua attuale sospensione: tale valore viene poi sottratto dal TTC presente in TABLE(1).TTC e il nuovo TTC ottenuto verrà infine utilizzato per aggiornare correttamente il campo TABLE(1).TTC. Osserviamo per inciso che per imporre la giusta sequenzialità nell’esecuzione delle precedenti operazioni abbiamo dovuto utilizzare, come fatto del resto anche in altri casi analoghi, apposite context variables identificabili dal simbolo $. Fatto ciò, si entra nello stato ritardatore INS nel quale, non appena viene effettivamente scritto il valore aggiornato del TTC nella prima riga della tabella TABLE (evento wr(TABLE(1).TTC)), è generato l’evento EXIT che a sua volta innesca la transizione dallo stato INS al successivo stato PID e la chiamata alla procedura INSERIMENTO (vedi Figura 5.61), la quale si occupa (tramite un’opportuna Procedural StateChart) di inserire il nuovo processo pcg pronto nella giusta posizione nella tabella TABLE in base al suo periodo, ossia in definitiva alla sua priorità; in questo caso particolare il nuovo arrivato, avendo priorità più alta di quello RUNNING, diventerà necessariamente il primo della tabella, ma in generale l’inserimento può avvenire in qualsiasi posizione. Nel secondo caso invece (condizione [PERIODO>=TABLE(1).P] vera) il nuovo task partito, avendo priorità minore o uguale a quello attualmente in esecuzione, non può fare prelazione su quest’ultimo (anche se ha lo stesso periodo, è comunque arrivato dopo) e quindi viene semplicemente inserito tramite la solita procedura INSERIMENTO nella sua giusta posizione nella tabella TABLE dei processi pronti ordinati per priorità decrescente, ovvero periodo crescente; fatto ciò il processo global_monitor rientra nuovamente nello stato @WAIT_COMPLETATION_OR_NEW_START dove attenderà il completamento del task RUNNING o la partenza di un nuovo processo.

101

Ritornando infine alla situazione di corretto completamento dell’istanza periodica corrente del task RUNNING, nella compound action FINITO vengono eseguite due azioni: COMPLETE_TO_RUNNING e RIMOZIONE(). La prima si occupa di resettare (ossia rendere false) le due condizioni di monitoraggio ATTIVO(RUNNING) e FINE(RUNNING) e di spedire il segnale di avvenuta terminazione al processo referenziato dal PID RUNNING; a tal proposito osserviamo che per i task simulati viene scritta l’apposita stringa ‘complete’ nella rispettiva input queue, mentre per il processo acceptance, caratterizzato per convenzione dal PID MAX_P–1, viene resa vera l’apposita condizione COMPLETATO. La seconda rappresenta invece la chiamata alla semplice procedura RIMOZIONE che si occupa di rimuovere il primo elemento (il processo top-prio appena completato) della tabella TABLE scalando di una posizione tutti gli altri elementi fino alla prima riga vuota (PID=1000, corrispondente per nostra convenzione al null SDL). In qualsiasi modo ci si arrivi, nello stato PID si controlla il campo PID della prima riga della tabella TABLE: se tale valore è 1000 (condizione [TABLE(1).PID=1000] vera) vuol dire che, in seguito alla rimozione dell’unico processo appena terminato, la tabella dei processi pronti è diventata vuota e quindi è necessario ritornare nello stato iniziale WAIT_PERIOD dove attendere la partenza di un nuovo task. Se al contrario tale valore è diverso da 1000 (condizione [TABLE(1).PID/=1000] vera) allora vuol dire che, nonostante la rimozione del processo top-prio completato oppure in seguito all’inserimento di un nuovo processo ad alta priorità, il primo elemento della solita tabella contiene già un nuovo processo pronto per la schedulazione che, essendo top-prio per costruzione, può prendere subito possesso della CPU ed eseguire. In quest’ultimo caso, in modo perfettamente analogo a quanto già visto precedentemente, all’entrata nello stato ritardatore RUNNING viene aggiornato opportunamente il valore di RUNNING la cui effettiva scrittura (evento wr(RUNNING)) innesca l’azione TIMER e la transizione dallo stato RUNNING allo stato @WAIT_COMPLETATION_OR_NEW_START.

102

5.2 Versione 14 In questa versione, ferme restando tutte le soluzioni adottate nella specifica della versione precedente, innanzitutto abbiamo aggiunto la possibilità di poter all’occorrenza disattivare/riattivare il modulo di acceptance direttamente in fase di esecuzione simulata, agendo sull’apposito pulsante di tipo toggle presente nel pannello relativo (vedi Figura 5.15). Abbiamo poi, come vedremo in seguito, aggiunto anche altre interessanti funzionalità al nostro modello applicativo, come il controllo della scadenza del periodo di acceptance, la gestione dei processi terminati da parte del global_monitor, la specifica di altre tipologie di task real-time non garantiti (one-shot, periodici e sporadici) con eventuali vincoli di precedenza e la definizione del fattore di utilizzazione totale U_TOT.

Figura 5.15 – Pannello d’esempio della versione 14

5.2.1 Attivazione/disattivazione del processo ACCEPTANCE Questa funzionalità aggiuntiva del sistema è stata motivata, come discusso in [2], dal fatto che l’esecuzione periodica del modulo di acceptance per l’analisi di schedulabilità di task critici potrebbe risultare inutile se non addirittura controproducente ad un certo istante di vita del sistema stesso, ma grazie ad essa un utente-progettista può direttamente disattivare e riattivare dall’esterno il processo in questione in base alle esigenze delle applicazioni attualmente in esecuzione. Ciò è stato realizzato definendo, a differenza della specifica SDL (che riportiamo in Figura 5.16), un unico data-item di tipo condition (DEACTIVATED) il quale permette di avere un evento persistente che, senza usare code aggiuntive, non vada perso nelle altre transizioni di stato per esso non rilevanti e che nel contempo non interferisca con gli altri segnali eventualmente presenti nell’input queue del processo acceptance stesso (vedi Figura 5.17). Più in dettaglio, la

103

condizione DEACTIVATED, resa vera tramite l’apposito pulsante del pannello, diventa rilevante solo quando l’acceptance ha completato correttamente la sua istanza corrente di esecuzione e quindi si trova nello stato EXECUTED; in tal caso la transizione di stato relativa alla condizione vera succitata risulta abilitata e conduce il processo nello stato PREACTIVATED, dal quale si esce o in seguito alla riattivazione dell’acceptance (condizione DEACTIVATED resa falsa ripremendo il solito pulsante) con conseguente rientro nello stato EXECUTED oppure alla ricezione nell’input queue del segnale di scadenza del periodo (evento TPERIODO_ACC) proveniente dal Clock Manager. In quest’ultimo caso, dopo aver resettato la condizione COMPLETATO (azione fs!(COMPLETATO)), si passa nello stato di effettiva disattivazione del modulo di acceptance (DEACTIVATED), dal quale si potrà eventualmente uscire per riprendere il normale funzionamento del processo solo quando la condizione DEACTIVATED sarà nuovamente resa falsa. Per inciso osserviamo che, pur avendo seguito lo stesso schema di funzionamento della specifica SDL [2] nella realizzazione del meccanismo di disattivazione/riattivazione dell’acceptance (vedi ancora Figura 5.16), abbiamo ritenuto opportuno aggiungere due apposite static reactions interne allo stato DEACTIVATED che provvedono ad aggiornare correttamente il valore del fattore di utilizzazione relativo ai task periodici critici garantiti: all’entrata nello stato di disattivazione U viene decrementato del fattore di utilizzazione relativo all’acceptance (ACCWCASE/ACCPERIODO), mentre all’uscita (riattivazione) U viene rincrementato dello stesso valore. In tal modo è possibile monitorare direttamente durante la simulazione (dagli appositi Monitor o dallo stesso pannello visto sopra) l’eventuale variazione del fattore di utilizzazione conseguente alla sospensione momentanea o al fallimento definitivo (vedi più avanti) del processo acceptance, possibilità non prevista nel modello di riferimento [2].

Figura 5.16 – Disattivazione/riattivazione di acceptance nella specifica SDL

104

Figura 5.17 – StateChart acceptance della versione 14

5.2.2 Controllo della scadenza del periodo di ACCEPTANCE Inoltre sempre nell’acceptance (vedi ancora Figura 5.17) è stato aggiunto un ulteriore controllo che tenga conto dell’eventuale scadenza prematura del periodo (deadline) del processo in questione (evento TPERIODO_ACC) quando questo si trova ancora nello stato WAIT_COMPLETE in attesa del segnale del suo completamento (condizione COMPLETATO vera), con conseguente segnalazione dell’avvenuto fallimento al global_monitor (azione FAILED) e transizione nello stato senza uscita FAILURE, all’entrata del quale viene infine aggiornato il valore del fattore di utilizzazione dei processi periodici critici garantiti anche se, come nel caso di disattivazione momentanea, l’acceptance non viene rimosso dalla tabella TAB dei task garantiti. A rigore però tale controllo risulta, almeno nel modello Statemate, sia teoricamente che praticamente superfluo in quanto l’acceptance, come abbiamo già visto, è sempre il primo task real-time di tipo pcg ad essere schedulato e, essendo il primo, è intrinsecamente garantito e quindi in condizioni di normale funzionamento del sistema e in assenza di errori nella specifica stessa o nell’assegnazione delle priorità agli eventuali processi firm non garantiti non potrà mai fallire, come del resto abbiamo potuto verificare sperimentalmente in varie esecuzioni simulate del modello, anche nel caso limite di un fattore di utilizzazione del processore con valore di picco superiore a 0.98 e con valore di regime (cioè quando il periodo dell’acceptance si è assestato sul valore massimo di 250) superiore a 0.92.

105

5.2.3 Gestione dei processi terminati da parte del GLOBAL_MONITOR Un’altra modifica effettuata nella presente versione è stata quella di implementare anche nel global_monitor la gestione degli eventuali processi uccisi (killed) o falliti (failed) in maniera analoga a come è stato fatto nell’acceptance per i processi garantiti nella tabella TAB. Ciò è stato ottenuto definendo un apposito vettore di condizioni (KILLED_GM) con tutte le data-flow lines per il suo ‘trasporto’ e i necessari controlli aggiuntivi per la gestione del segnale in questione; oltre infatti all’individuazione del PID del processo morto, in questo caso bisogna anche distinguere se il task è quello attualmente in esecuzione o meno e comportarsi di conseguenza, in particolare per quanto riguarda il reset della condizione ATTIVO(RUNNING) e del timer logico ‘complete’ relativo al suo TTC e la chiamata alla relativa procedura (RIMOZIONE o RIMOZIONE_I) per la rimozione del task ucciso o fallito dalla tabella TABLE dei processi pronti (vedi le transizioni uscenti dallo stato CTRL in Figura 5.18).

Figura 5.18 – StateChart global_monitor della versione 14

In questo modo in fase di simulazione è possibile rilevare immediatamente per tutti i processi pronti (anche per quelli non garantiti che vedremo più avanti) e senza i ritardi introdotti dall’acceptance (solo per i processi garantiti) l’eventuale fallimento di un task che ha superato la propria deadline o la sua uccisione in seguito all’apposito segnale proveniente dal proc_generator, anche se a costo di un piccolo aumento nella complessità del global_monitor e con la limitazione che il killing forzato di un processo e i suoi due parametri (inter-arrival time e PID del task da eliminare) devono essere definiti necessariamente a priori dall’utente-progettista nella specifica del modello e non possono essere spediti direttamente dall’ambiente esterno, magari utilizzando la comoda GUI di un pannello, in quanto ciò potrebbe portare – a meno di non ricorrere ad ulteriori specifiche – ad errate condizioni di non determinismo (più transizioni abilitate contemporaneamente nel medesimo stato) nell’esecuzione simulata del processo stesso.

106

5.2.4 Specifica di task firm one-shot e di vincoli di precedenza L’ultima modifica è stata l’implementazione di una seconda Carta Parametrica (oltre a quella già presente per i processi periodici critici garantiti e indipendenti che abbiamo già visto nell’analisi della versione 13) per la specifica di task real-time firm (cioè non garantiti) di tipo one-shot (vedi Figura 5.19), ossia per tutti quei processi aperiodici costituiti da un’unica istanza di esecuzione da completare entro una determinata deadline (impropriamente chiamata ancora periodo).

Figura 5.19 – Generic StateChart proc_one_shot

Questa nuova tipologia di processi, decisamente più semplici ma forse anche meno interessanti degli hard garantiti finora considerati, offrono però la possibilità (insieme ai task periodici firm non garantiti che vedremo più avanti) di poter specificare dei vincoli di precedenza tra le computazioni di processi diversi. Infatti, mentre i task critici proprio per essere garantiti devono superare, come abbiamo già visto, un test di schedulabilità (eventualmente esatta) basato sulla teoria del Rate Monotonic e del GRMS che non tratta nessun tipo di vincoli di precedenza, i task firm non garantiti nel nostro modello, non dovendo essere sottoposti a tale analisi da parte di acceptance, possono prevedere dei vincoli di precedenza, per semplicità comunque supposti sempre singoli (vedi Figura 5.20); ogni processo può avere cioè al massimo un solo predecessore e un solo successore che non sia se stesso, cercando ovviamente di evitare catene chiuse di stallo.

Figura 5.20 – Rappresentazione di una catena di processi con vincoli di precedenza

singoli

107

Per quanto invece riguarda il criterio di schedulazione di tali processi firm, esso è di tipo best effort: il sistema non offre più nessuna garanzia di successo ma cerca di fare del suo meglio per rispettare la deadline dei task, schedulandoli secondo la loro priorità e, a parità di priorità, secondo l’ordine di arrivo, fermo restando il rispetto di tutti gli eventuali vincoli di precedenza per essi specificati. Secondo questo approccio la priorità non è più assegnata automaticamente e dinamicamente dal sistema, ma deve essere fissata a priori dall’utente-progettista prima dell’esecuzione del modello, scegliendola in modo tale che quei processi che hanno una deadline ravvicinata alla fine della loro computazione siano schedulati prima degli altri e rispettando sempre la condizione che la priorità di un task firm non sia superiore a quella di un qualsiasi task critico, per evitare la prelazione di quest’ultimo da parte del primo con conseguente eventuale invalidazione del test di garanzia. Analizziamo ora più in dettaglio il funzionamento della Generic StateChart proc_one_shot riportata in Figura 5.19: dopo le solite istruzioni di inizializzazione dei record d’appoggio (azione INIT) si entra nel primo stato (PRE) dal quale si esce diversamente a secondo della condizione verificata, ossia se il processo in questione ha (PRE/=1000) o meno (PRE=1000) un processo predecessore da aspettare (tale parametro di esecuzione, come tutti gli altri, va deciso e definito a priori nel proc_generator: vedi Tabella 5.2).

CAMPO TIPO BREVE DESCRIZIONE OPERATION string operazione da effettuare con i parametri correnti: creating o killing INTERTIME integer inter-arrival time rispetto all’esecuzione dell’operazione precedente WCASE integer worst case computation time (WCCT) del processo one-shot PERIOD integer deadline del processo one-shot (periodica per i processi periodici) PID integer identificatore numerico univoco del processo (specificato a priori) PRE integer PID del processo predecessore nei vincoli di precedenza (singoli) SUCC integer PID del processo successore nei vincoli di precedenza (singoli) PRIO integer priorità assegnata dall’utente-progettista (0 è la massima priorità)

Tabella 5.2 – Parametri di esecuzione dei processi one-shot simulati

In entrambi i casi viene settato un timer logico sulla scadenza della deadline (period) del task stesso: nel primo caso (presenza del predecessore) si entra in uno stato (WAIT_PREDECESSOR) dal quale si esce in uno dei due casi: o in seguito alla scadenza della deadline (evento TDEADLINE scritto dal Clock

Manager nell’input queue INPUT_NEW_PROC_P del processo) con conseguente entrata, prima nello stato GET_EVENT_FROM_QUEUE, e subito dopo nello stato senza uscita FAILURE con relativa azione FAILED che comunica l’avvenuto fallimento al global_monitor

o in condizioni di corretto funzionamento, in seguito alla ricezione del segnale di ‘via

libera’ (condizione GO resa vera) da parte del processo predecessore con PID=PRE. Nel secondo caso (assenza del predecessore) invece si entra direttamente nello stato PARTITO_AND_WAIT_ACTIVATION evitando l’attesa del ‘via libera’. A tal proposito bisogna osservare che, se da una parte l’uso di un apposito vettore condiviso di condizioni di guardia (GO) per sincronizzare l’esecuzione di catene di due o più processi con vincoli di precedenza non è così flessibile come il meccanismo di

108

Inter-Process Communication (IPC) di tipo asincrono implementato nel global_monitor del modello SDL [2] (vedi Figura 5.21) in quanto in Statemate le info-flow lines relative al GO vanno definite tutte a priori nella specifica anche in assenza di vincoli per evitare warnings di completezza nell’analisi statica del modello (warning che comunque non è possibile evitare nel caso di un solo processo che prevede la possibilità di tali vincoli), dall’altra è pur vero che tale approccio è decisamente più semplice, comodo ed immediato e non presenta effetti collaterali indesiderati da gestire, come il riempimento dei buffer di ricezione e di spedizione nel caso di task morti, anche nell’eventualità che si debbano gestire vincoli di precedenza multipli.

Figura 5.21 – Meccanismo di IPC per gestire i vincoli di precedenza nel modello SDL

Ritornando alla dinamica della StateChart proc_one_shot, all’entrata nello stato PARTITO_AND_WAIT_ACTIVATION il processo scrive i suoi parametri caratteristici di esecuzione (PERIOD, WCASE, PRIO e PID) nell’apposita coda PARTITO_QUEUE che, appena possibile, verrà letta dal global_monitor il quale provvederà ad inserire il processo nella tabella dei task pronti (TABLE) in base alla sua priorità (prio) che in questo caso, come già detto, non dipende più dal periodo (come nell’algoritmo di schedulazione Rate Monotonic per processi periodici critici garantiti) ma deve essere adeguatamente assegnata a priori dall’utente. A questo punto, se il task riesce ad essere schedulato per l’esecuzione simulata prima della scadenza della sua deadline (ricordiamo che il processo non è garantito), ossia riceve per tempo il segnale START_P dal global_monitor, allora potrà entrare finalmente nello stato EXECUTING_OR_SUSPENDED dal quale uscirà o al completamento della sua prima e unica istanza di esecuzione (segnale COMPLETE spedito dal global_monitor e prelevato dall’input queue e stato finale SUCCESSFUL_EXECUTED) o alla scadenza prematura della sua deadline (segnale TDEADLINE prelevato dall’input queue, azione FAILED e stato senza uscita FAILURE) oppure in seguito alla sua forzata uccisione da parte del proc_generator (segnale KILL prelevato dall’input queue, azione KILLED e stato senza uscita KILLED). L’evento CICLO viene generato all’interno dello stato GET_EVENT_FROM_QUEUE nel caso il segnale prelevato dall’input queue non corrisponda a nessun evento rilevante (COMPLETE, TDEADLINE o KILL) per le transizioni di stato che permettono l’uscita dallo stato stesso.

KERNEL SIMULATOR

msgsnd[id.P2]

segnale di via libera

msgrcv[id.P1]

P1 P2

109

Nel caso invece il processo si trovi ancora nello stato PARTITO_AND_WAIT_ACTIVATION quando il timer della sua deadline scade (evento TDEADLINE scritto nella coda INPUT_NEW_PROC_P), esso passerà direttamente nello stato GET_EVENT_FROM_QUEUE e subito dopo nello stato FAILURE dopo aver comunicato al global_monitor il suo fallimento (azione FAILED). Infine, in caso di corretto completamento del task (stato SUCCESSFUL_EXECUTED), verrà spedito il segnale di via libera (condizione GO(SUCC) resa vera) all’eventuale ed unico processo successore con PID=SUCC tramite le opportune info-flow lines aggiuntive di collegamento tra tutti i processi one-shot con potenziali vincoli di precedenza. A tal riguardo osserviamo che nella presente versione abbiamo istanziato per i nostri esperimenti, oltre a due processi periodici critici garantiti (proc1_pcg e proc2_pcg), due processi one-shot firm non garantiti (proc3_os e proc4_os) che possono avere vincoli di precedenza singoli, ma nulla vieta ad un utente-progettista di aggiungere all’occorrenza altri processi dei due tipi finora definiti, rispettando naturalmente le specifiche degli stessi e definendo opportunamente i loro parametri di esecuzione nel vettore OPT di record PROCESSES del proc_gen; del resto l’aggiunta di altri task è facilitata e in un certo senso automatizzata dalla riusabilità delle specifiche offerta dalle Carte Parametriche, in quanto le generic instances dei nuovi processi possono essere definite e collegate con il resto del sistema ricopiando lo stesso modello di riferimento di altre istanze simili e adattandolo con semplici modifiche alle info-flow lines e al binding dei parametri al contesto specifico. In particolare, nel nostro caso, i processi one-shot, pur avendo una specifica per certi aspetti diversa da quella dei processi periodici critici garantiti, presentano in pratica gli stessi collegamenti con le altre Charts del sistema (proc_gen, global_monitor e clock), a parte la presenza aggiuntiva dei segnali GO per la gestione di eventuali vincoli di precedenza e l’assenza delle interfacce con il modulo di acceptance (ricordiamo infatti che i one-shot non sono sottoposti all’analisi di schedulabilità come i proc_pcg); inoltre tutta la loro gestione (attivazione iniziale, schedulazione su base prioritaria con preemption, vincoli temporali, eventuale uccisione, etc.), per come è stato progettato il sistema, può continuare ad essere svolta dai processi già preposti allo scopo (proc_generator, global_monitor e Clock Manager) senza richiedere alcuna modifica sostanziale, a patto naturalmente di conoscere e rispettare le specifiche dello schema di funzionamento già presenti.

5.2.5 Specifica di task firm periodici (versione 14b) Abbiamo poi realizzato una prima variante della presente versione, denominata 14b, nella quale è stata aggiunta la possibilità di poter istanziare, oltre ai processi periodici critici garantiti e a quelli one-shot (per un totale comunque di quattro processi al fine di non complicare troppo la specifica e la simulazione del modello), un nuovo tipo di processo: quello periodic firm non garantito. Questa tipologia di processi presenta in pratica lo stesso schema di funzionamento di quelli one-shot e la stessa regola di assegnazione manuale della priorità con strategia di schedulazione ancora di tipo best-effort senza analisi di schedulabilità (sono infatti anch’essi non garantiti) e con analoga possibilità di definire dei vincoli di precedenza (singoli) ma con l’unica sostanziale differenza che sono per l’appunto periodici: la specifica della loro Carta Parametrica (riportata in Figura 5.22) è dunque molto simile a quella della Generic StateChart proc_one_shot (cfr. Figura 5.19).

110

Figura 5.22 – Generic StateChart proc_periodic

Più in particolare, la scadenza temporale data dal loro periodo non rappresenta più solo la deadline limite per il corretto completamento dell’esecuzione dell’istanza corrente del processo ma, come per i task periodici critici garantiti, segna anche l’istante di ripartenza del processo stesso (il nome dell’azione nella quale viene settato il timer in questione è stato infatti cambiato nel più proprio SET_PERIOD): a tale scopo è stato aggiunto un apposito stato GET_TPERIODO_FROM_QUEUE che si occupa di prelevare dall’input queue del task il segnale TPERIOD non appena il Clock Manager lo scrive nella coda stessa (condizione q_length(INPUT_NEW_PROC_P)>0 vera che innesca l’uscita dallo stato SUCCESSFUL_EXECUTED). Il resto della specifica non viene analizzato in quanto perfettamente uguale a quello dei processi one-shot, a parte due piccole ma interessanti modifiche: la prima effettuata nella static reaction interna allo stato PARTITO_AND_WAIT_ACTIVATION per resettare al valore falso la condizione GO di via libera resa precedentemente vera dall’eventuale processo predecessore e indicare così allo stesso che il suo successore non è morto; la seconda effettuata nell’azione GO_TO_SUCC (non più static reaction interna allo stato SUCCESSFUL_EXECUTED) per evitare di rendere inutilmente vera ad ogni conclusione di esecuzione della corrente istanza periodica la condizione GO di via libera all’eventuale processo successore nel caso quest’ultimo sia morto (fallito o ucciso) e non abbia quindi resettato la condizione stessa. Tale controllo di sicurezza è tutto sommato inutile nel nostro modello in quanto, a differenza del sistema SDL, il meccanismo di sincronizzazione tra processi periodici con vincoli di precedenza è stato realizzato, come già visto, utilizzando un opportuno vettore condiviso di condizioni di guardia che non risente di eventuali problemi legati alla ripetizione periodica di alcune azioni inutili, ripetizione che invece nel modello [2], a causa del riempimento dei buffer previsti dal meccanismo implementato di IPC, può

111

risultare alla lunga potenzialmente dannosa; ciò nonostante questo meccanismo di comunicazione asincrona è stato ugualmente realizzato per dimostrare che, sotto certi aspetti, la specifica Statemate risulta più semplice e meno problematica della corrispondente specifica SDL, a patto di usare ‘intelligentemente’ e correttamente tutti gli strumenti offerti dal tool. In definitiva nella versione 14b per i nostri esperimenti sono state definite le generic instances (con tutte le necessarie interfacce e il corretto binding dei parametri) per tre processi periodici (proc1_p, proc3_p e proc_4) firm non garantiti con vincoli singoli di precedenza, specificandone come al solito gli opportuni parametri di esecuzione (analoghi a quelli per i one-shot riportati in Tabella 5.2: intertime, wcase, period, pid, pre, succ e prio) nel vettore OPT di record PROCESSES del proc_gen, oltre alla generic instance (già presente) dell’unico processo di tipo periodico critico garantito (proc2_pcg) con relativi parametri (intertime, wcase, period, latency e pid: vedi Tabella 5.1) e interfacce di collegamento. A tal riguardo bisogna osservare che nella specifica di una catena di processi periodici con vincoli di precedenza i periodi di tali processi devono essere molto simili se non addirittura uguali tra di loro, affinché la catena sia sempre consistente nel tempo e alla lunga non vi siano fallimenti, come del resto abbiamo potuto constatare direttamente nei nostri esperimenti. Per comodità infine abbiamo lasciato nella specifica della versione 14b la Generic StateChart proc_one_shot e le Charts, ereditate dalla precedente versione 14, relative alle istanze di due processi one-shot e di un processo di tipo pcg, scollegandole dal resto del modello, in modo da poterle eventualmente reinserire con facilità nel presente o nei futuri progetti.

5.2.6 Specifica di task firm sporadici e di U_TOT (versione 14c) Ferme restando tutte le specifiche della versione 14b, ne abbiamo poi realizzato una variante migliorata, denominata 14c, che sostanzialmente introduce due interessanti novità: o la prima è stata la possibilità di definire, oltre alle tipologie già presenti (processi

periodici critici garantiti indipendenti, one-shot e periodici firm non garantiti con eventuali vincoli di precedenza singoli), un ulteriore tipo di task real-time firm non garantito, quello sporadic

o la seconda è stata la definizione di un secondo fattore di utilizzazione, chiamato

U_TOT, non previsto nel modello SDL [2], che tenga conto dell’effettivo ed istantaneo carico di lavoro totale della CPU dato dalla somma del fattore di utilizzazione (WCCT/PERIODO) di tutti i processi pronti attualmente presenti in TABLE.

In particolare, in tutte le Procedural StateChart di global_monitor preposte all’aggiornamento della struttura dati TABLE (INSERIMENTO, RIMOZIONE, REMOVING_1 e RIMOZIONE_I) sono state aggiunte opportune istruzioni per l’incremento e il decremento del fattore U_TOT, analoghe a quelle già presenti nelle corrispondenti procedure di acceptance che si occupano dell’aggiornamento della tabella TAB dei processi garantiti, con la piccola differenza tecnica però, che nelle procedure di rimozione dei processi pronti U_TOT, contrariamente a U, potrebbe essere

112

decrementato fino a zero ma data l’approssimazione nel suo calcolo per avere sempre il valore zero preciso risulta necessario arrotondare il risultato ottenuto nel caso il suo valore assoluto sia minore di 10-15. La nuova variabile U_TOT, a differenza di U (rinominata U_PCG per meglio distinguerla), non si limita dunque a considerare staticamente il fattore di utilizzazione dei soli processi periodici critici garantiti ma, non dovendo essere utilizzata dal modulo di acceptance per l’analisi di schedulabilità, include anche quello di tutti gli altri task firm non garantiti visti finora, in particolare di quelli sporadici, purché ovviamente pronti per l’esecuzione. L’utilità di tale fattore è infatti collegata proprio alle specifiche che caratterizzano i task sporadic: essi sono ancora processi firm non garantiti (cioè non sottoposti ad alcun test di accettazione preliminare e quindi subito pronti appena attivati) sempre schedulati secondo un approccio best-effort in base alla priorità fissa loro assegnata manualmente dall’utente prima dello start-up del sistema, ma a differenza dei precedenti non prevedono nessun tipo di vincoli di precedenza e soprattutto sono aperiodici; ciò nonostante essi possono essere visti come dei particolari processi periodici per i quali il periodo inteso come deadline è sì costante nel tempo (come ad esempio per i periodici firm), ma le richieste di esecuzione delle varie istanze successive alla prima, anche se caratterizzate dallo stesso WCCT, non vengono inoltrate ad intervalli di tempo regolari e pari al periodo ma ad istanti casuali, pur variabili entro un certo range temporale fissato a priori. A tale scopo, come vedremo più avanti nell’analisi della specifica Statemate per questa nuova tipologia di processi, si è comunque potuta utilizzare la comoda funzione matematica predefinita RAND_IUNIFORM(). Ritornando al fattore di utilizzazione U_TOT, il suo monitoraggio tramite il meter presente nell’apposito pannello di simulazione (vedi Figura 5.23) permette di seguire in tempo reale l’andamento del workload corrente del processore (tra l’altro debolmente correlato con U) in modo da potersi rendere conto se ad un certo istante di vita del sistema esiste il rischio che un processo sporadico firm non garantito a bassa priorità e magari arrivato in un momento critico di schedulazione possa superare la sua deadline periodica e quindi fallire. Proprio in previsione di tale situazione è stata data la possibilità all’utente-progettista di poter modificare direttamente e agevolmente in fase di esecuzione simulata del modello il valore della deadline periodica (period) dei due processi sporadici (proc3_s e proc4_s) utilizzati nei nostri esperimenti utilizzando gli intuitivi controlli presenti nel solito pannello di Figura 5.23: in tal modo, ad esempio, se ad un certo momento riteniamo o constatiamo che sussistano le condizioni per il fallimento della successiva istanza di esecuzione di proc4, allora è sufficiente aumentare adeguatamente il periodo del processo sporadico in questione prima della sua successiva ripartenza (tale valore viene infatti riletto dal task ad ogni suo nuovo restart) agendo sul relativo slider o knob e ritardando così la scadenza della futura deadline a rischio di superamento. A tal proposito ricordiamo che, data la generazione random dell’istante di ripartenza di un task sporadico, a parità di condizioni iniziali, si potranno avere sequenze di time slice di schedulazione magari molto simili tra loro ma mai perfettamente uguali, e questo vale anche se andiamo indietro e avanti nella medesima sessione di simulazione: insomma, in questo caso non è possibile affidarsi alla ripetibilità degli esperimenti. Nel pannello della versione 14c sono inoltre presenti, oltre ai push button e ai display di controllo già visti per il clock NOW, per il processo acceptance, per il PID running e per il fattore di utilizzazione U_PCG, due lamp aggiuntivi la cui eventuale accensione sta ad indicare che il rispettivo fattore di utilizzazione (U_PCG oppure U_TOT) ha superato, anche se solo momentaneamente, il limite massimo teorico del 100%.

113

Figura 5.23 – Pannello IN/OUT della versione 14c

Il verificarsi di questa condizione di guardia (resa vera rispettivamente all’interno della StateChart schedulabilty_test prima dell’esito stesso dell’analisi di schedulabilità e al termine della procedura di inserimento di un nuovo processo pronto nella tabella TABLE) in entrambi i casi segnala una situazione di errore: più precisamente, nel caso di U_PCG il superamento del valore unitario indica che l’ultimo processo critico che ha richiesto di essere schedulato al modulo di acceptance è stato rifiutato (NACK) in quanto il sistema non avrebbe potuto garantirne la corretta esecuzione; nel caso di U_TOT invece il superamento del valore unitario è preludio al fallimento di uno o più processi firm non garantiti. Fatte queste debite osservazioni sulla versione 14c, passiamo ora ad analizzare più in dettaglio la specifica della Carta Parametrica relativa alla tipologia di processi sporadici implementata nel nostro modello Statemate e riportata per comodità del lettore in Figura 5.24. Appena la generic instance del task viene attivata (l’istante di partenza è indicato dal valore del campo INTERTIME del vettore OPT) dal proc_generator con l’opportuno comando start() vengono innanzitutto inizializzati i record d’appoggio (azione INIT) e viene settato il timer logico TPERIOD (scrivendo l’apposita stringa con relativo PID nella coda INPUT_CLOCK del Clock Manager) in base al valore del parametro d’ingresso PERIOD corrispondente al campo PERIOD preventivamente impostato, come tutti gli altri parametri rilevanti per questa tipologia di processi, sempre nel proc_generator (vedi Tabella 5.3).

114

CAMPO TIPO BREVE DESCRIZIONE

OPERATION string operazione da effettuare con i parametri correnti: creating o killing INTERTIME integer inter-arrival time rispetto all’esecuzione dell’operazione precedente WCASE integer worst case computation time (WCCT) del processo sporadico PERIOD integer periodo e deadline del processo sporadico (eventualmente variabile) PID integer identificatore numerico univoco del processo (specificato a priori) PRIO integer priorità assegnata dall’utente-progettista (0 è la massima priorità) MIN_RANGE integer valore minimo dell’istante di ripartenza del processo sporadico MAX_RANGE integer valore massimo dell’istante di ripartenza del processo sporadico

Tabella 5.3 – Parametri di esecuzione dei processi sporadic simulati

A questo punto, non dovendo essere sottoposto ad alcun test di schedulabilità, il task diventa subito pronto per eseguire: all’entrata nello stato PARTITO_AND_WAIT_ACTIVATION scrive così alcuni suoi parametri di esecuzione (WCASE, PRIO, PID e PERIOD) nella coda PARTITO_QUEUE e aspetta il segnale di effettiva partenza (evento START_P) da parte del global_monitor che comunque prima provvede ad inserirlo nella giusta posizione (in base alla sua priorità) nella tabella TABLE dei processi pronti.

Figura 5.24 – Generic Statechart proc_sporadic

Ora, se l’evento START_P viene generato prima della scadenza della deadline periodica TPERIOD, allora il task può entrare nello stato di effettiva esecuzione simulata (EXECUTING_OR_SUSPENDED), anche se potrà eventualmente subire preemption da parte di un processo firm a priorità più alta (cioè con un valore più basso del parametro PRIO) o da un qualsiasi processo critico garantito.

115

Se invece la deadline scade (evento TPERIOD) o il task viene ucciso (evento KILL) prima della ricezione del segnale START_P o del segnale COMPLETE esso fallirà (o morirà) entrando nello stato senza uscita FAILURE (o KILLED) dopo aver comunicato (azione FAILED o KILLED) l’avvenuto suo fallimento (o uccisione) al global_monitor che provvederà in entrambi i casi a rimuoverlo dalla tabella TABLE e a decrementare di conseguenza il valore del fattore di utilizzazione U_TOT. Al contrario, in condizioni di corretto funzionamento, al completamento dell’istanza corrente (segnalata dalla scadenza del timer logico COMPLETE settato sul WCCT del processo) il global_monitor scrive la stringa ‘complete’ nell’input queue INPUT_NEW_PROC_P del processo stesso che può così uscire dallo stato EXECUTING_AND_SUSPENDED per entrare finalmente, una volta passato dallo stato GET_EVENT_FROM_QUEUE (prelevamento dell’evento dalla coda), nello stato SUCCESSFUL_EXECUTED; nell’azione RANDOM_START, come già accennato, viene generato in modo random l’istante di ripartenza (variabile INSTANT) della successiva istanza di esecuzione del processo sporadic utilizzando la funzione matematica predefinita RAND_IUNIFORM(MIN_RANGE,MAX_RANGE) che per l’appunto restituisce un valore intero casuale compreso nell’intervallo chiuso individuato dai due parametri interi MIN_RANGE e MAX_RANGE (specificati negli appositi campi del vettore OPT relativo al task in questione prima dello start-up del sistema). Dunque, allo scadere del periodo (segnale ‘tperiod’ letto dalla coda all’interno dello stato GET_TPERIOD_FROM_QUEUE) il task esce dallo stato EXECUTING_AND_SUSPENDED ma non può ricominciare subito, come avveniva per gli tutti altri processi periodici, l’esecuzione di una nuova identica istanza, poiché deve per l’appunto aspettare nello stato WAIT_START l’intervallo di tempo indicato da INSTANT – ossia in definitiva il segnale ‘tstart’ di scadenza del timer appositamente settato nella precedente azione SET_START – prima di poter impostare nuovamente il timer della sua deadline periodica (azione SET_TPERIOD all’uscita dallo stato GET_TSTART_FROM_QUEUE) e ripartire da capo con la successiva istanza (che così risulterà ‘casualmente’ diversa dalla precedente). Infine, per quanto riguarda i collegamenti con gli altri processi del sistema (proc_gen, global_monitor e clock), i processi sporadici presentano le stesse identiche data-flow lines degli altri processi firm non garantiti visti precedentemente (one-shot e periodic), con la differenza che rispetto a questi non richiedono interfacce bidirezionali aggiuntive per il segnale GO in quanto, data la loro intrinseca casualità, non è possibile definire alcun tipo di vincoli di precedenza tra di essi. A conclusione di questa parte inerente la versione 14, facciamo brevemente presente che ne è stata realizzata un’ulteriore variante, denominata 14d, nella quale, ferme restando tutte le specifiche e le considerazioni della versione 14c, sono stati semplicemente definiti quattro processi di tipo periodico critico garantito e indipendente (come nelle versioni 7b e 13c) con il solo scopo di verificare sperimentalmente che tutte le aggiunte, le modifiche e i miglioramenti introdotti in queste ultime versioni (14, 14b e 14c) non influenzano in alcun modo la correttezza di schedulazione dei preesistenti task pcg, ed infatti in fase di esecuzione simulata abbiamo ottenuto per stessi test pattern di riferimento risultati uguali nel caso di inter-arrival time non nulli, e risultati molto simili nel caso di inter-arrival time nulli, ma comunque sempre equivalenti dal punto di vista delle temporizzazioni.

116

5.3 Versione 15 In questa ultima versione, ferme restando ancora tutte le soluzioni, le considerazioni e i risultati della precedente, è stata introdotta nel modello un’ultima ma fondamentale funzionalità: la possibilità di poter simulare l’esecuzione delle varie tipologie predefinite di task real-time anche in sezione critica, gestendo correttamente l’accesso alle ‘ipotetiche’ risorse di sistema condivise, mutuamente esclusive e preemptable (CPU a parte) che tali sezioni critiche rappresentano tramite un opportuno meccanismo di sincronizzazione semaforica e l’efficiente protocollo di Priority Ceiling (per la cui teoria si rimanda al paragrafo 2.2.4.1). Questa funzionalità aggiuntiva, se da una parte ha indubbiamente ampliato le potenzialità di modellazione e di simulazione del sistema, ha richiesto però dei notevoli adattamenti nella specifica formale e nei data-items di tutte le Charts: innanzitutto nel global_monitor (vedi ad esempio i nuovi campi di TABLE evidenziati in Tabella 5.4), poi nell’acceptance (vedi ad esempio i nuovi campi di TAB evidenziati in Tabella 5.5) e nelle varie Carte Parametriche dei task simulati e infine, anche se in misura ridotta, nelle strutture dati caratteristiche del Clock Manager (vedi i nuovi campi evidenziati in Tabella 5.6 e in Tabella 5.7) e del proc_gen (vedi i nuovi campi del vettore OPT evidenziati in Tabella 5.8), comprese le loro sub-charts e le rispettive subroutines (grafiche o testuali).

Tabella 5.4 – Struttura dati di TABLE (tabella dei processi pronti) della versione 15

Tabella 5.5 – Struttura dati di TAB (tabella dei processi garantiti) della versione 15

117

CAMPO TIPO BREVE DESCRIZIONE SEGNALE string stringa identificativa del timer logico SCADENZA integer scadenza relativa del timer logico RIMOZIONE bit flag per richiamare la procedura RIMOZIONE_TIMER RUNNING integer PID del processo del quale rimuovere all’occorrenza il timer logico PID integer PID del processo che ha richiesto il timer logico FG bit flag per segnalare la presenza o meno di un blocco successivo SMP integer numero del semaforo dell’eventuale sezione critica del processo

Tabella 5.6 – Struttura dati di INPUT_CLOCK_ELEMENT della versione 15

CAMPO TIPO BREVE DESCRIZIONE

SEGNALE string stringa identificativa del timer logico SCADENZA integer scadenza assoluta del timer logico NEXT integer riferimento all’elemento successivo nella LISTA_TIMER RUNNING integer PID del processo del quale rimuovere all’occorrenza il timer logico PID integer PID del processo che ha richiesto il timer logico FG bit flag per segnalare la presenza o meno di un blocco successivo SMP integer numero del semaforo dell’eventuale sezione critica del processo

Tabella 5.7 – Struttura dati di ELEMENTO_LISTA_TIMER della versione 15

CAMPO TIPO MIN (default) MAX BREVE DESCRIZIONE

OPERATION string stringa vuota - operazione da effettuare con i parametri

correnti: ‘creating’ oppure ‘killing’

INTERTIME integer 0 - inter-arrival time rispetto all’esecuzione dell’operazione precedente

FWCASE integer 0 - worst case computation time del primo blocco a tempo del processo (obbligatorio)

SWCASE integer 0 - worst case computation time del secondo blocco a tempo del processo (opzionale)

TWCASE integer 0 - worst case computation time del terzo blocco a tempo del processo (opzionale)

PERIOD integer 1 - periodo e/o deadline del processo (per i pcg rappresenta anche la priorità secondo il RM)

LATENCY integer 0 - tempo di latenza (attesa) massimo per il test di schedulabilità (solo per i processi pcg)

PID integer 0 MAX_P identificatore numerico univoco del processo (specificato manualmente a priori)

PRE integer 0 1000 PID del processo (one-shot o periodic) predecessore nei vincoli di precedenza

SUCC integer 0 1000 PID del processo (one-shot o periodic) successore nei vincoli di precedenza

PRIO integer 0 - priorità assegnata dall’utente-progettista ai processi non pcg (0 è la massima priorità)

MIN_RANGE integer 0 - valore minimo dell’istante di ripartenza di un processo sporadico

MAX_RANGE integer 0 - valore massimo dell’istante di ripartenza di un processo sporadico

SC integer 0 MAX_SC numero della sezione critica relativa al secondo blocco a tempo del processo

Tabella 5.8 – Parametri di esecuzione dei processi simulati nella versione 15

118

Figura 5.25 – Gerarchia del modello della versione 15

119

In seguito a questi sostanziali cambiamenti e aggiunte, abbiamo finalmente ottenuto un modello Statemate che, sebbene decisamente più complesso nella specifica del precedente, è praticamente equivalente (pur se con alcune limitazioni dovute alle semplificazioni adottate nella realizzazione del modulo di acceptance per i task pcg e del meccanismo di IPC per la gestione dei processi con vincoli di precedenza) al modello applicativo di riferimento finale [2], ferme restando ovviamente tutte le differenze intrinseche (positive o negative che siano) nella sintassi, nella semantica e nella temporizzazione dei due tool di specifica formale affrontate nel capitolo 4, ed altre piccole discrepanze già viste o che analizzeremo nel capitolo seguente. Il nucleo dell’intero sistema è ancora il global_monitor che però, arricchito di tutte le necessarie sub-chart e coadiuvato nel suo compito di gestore dei task simulati dal nuovo processo semaphore, è diventato a tutti gli effetti il Kernel Simulator progettato nel modello applicativo [2] per fornire quelle funzionalità basilari tipiche di un semplice sistema operativo in tempo reale. Di seguito sono riportate, rispettando l’ordine della loro gerarchia presente in Figura 5.25, le varie Charts del modello modificate o aggiunte rispetto alla precedente versione, trascurandone le Sub-Charts meno significative ma comprendendo tutte le Procedural StateCharts. Data la discreta complessità e la sostanziale equivalenza con la specifica SDL di riferimento, per la descrizione dettagliata di tutte le nuove funzionalità implementate si rimanda invece direttamente al capitolo “Specificazione del modello applicativo” della tesi [2], mentre per la parte teorica inerente è possibile riferirsi al capitolo 2 del presente lavoro. Nelle pagine seguenti quindi ci limiteremo solo ad illustrare a grandi linee le principali novità e modifiche apportate alle varie Carte raffigurate, con particolare riguardo comunque al global_monitor e al nuovo processo semaphore. Prima però di procedere con quest’ultima analisi delle specifiche osserviamo che sono state realizzate quattro varianti della versione 15, le quali si differenziano dalla versione originale solo perché: o nella versione 15 sono stati definiti quattro task pcg non più indipendenti, data la

loro possibile sincronizzazione su sezioni critiche condivise mutuamente esclusive con conseguente possibilità di blocco

o nelle versioni successive abbiamo cercato di considerare le combinazioni più

indicative di tutte le altre tipologie di processi real-time da noi previste così da poterne effettuare diverse esecuzioni simulate (vedi gli esempi finali illustrati nel capitolo 6), lasciando comunque sempre almeno una generic instance, con relativa Carta Parametrica, per ciascun tipo di task non utilizzato (scollegato) nel sistema corrente, così da consentire ad un utente-progettista o ad un futuro sviluppatore il suo eventuale riutilizzo.

Più in particolare, nella versione 15a sono stati definiti (e quindi sono simulabili cambiando a piacere i loro parametri di esecuzione: vedi Tabella 5.8) due processi pcg e due sporadici firm non garantiti; la deadline periodica di questi ultimi due task può essere eventualmente cambiata all’occorrenza anche durante la simulazione interattiva tramite il solito pannello di controllo illustrato in Figura 5.23. Nella versione 15b invece sono stati istanziati due task pcg e due one-shot firm non garantiti; questi ultimi due processi possono essere legati da un vincolo di precedenza singolo.

120

Nella versione 15c sono altresì presenti solo task firm non garantiti: uno di tipo sporadico (con deadline eventualmente variabile a run-time) e tre di tipo periodico (questi ultimi tre, come i one-shot, possono costituire una catena di processi con vincoli di precedenza singoli). Infine, nella versione 15d è stata prevista una generic instance per ciascuna tipologia di task real-time predefiniti (pcg, one-shot, periodic e sporadic) tenendo presente che, sebbene in teoria sia possibile specificare in entrambi i sensi un vincolo di precedenza tra il processo one-shot e quello periodico (firm non garantito), nella pratica è permessa solo la catena periodico –> one-shot, in quanto in caso contrario (one-shot –> periodico) il task periodico successore sarebbe destinato inevitabilmente al fallimento per superamento della sua deadline. Prima di passare alla descrizione della specifica delle Charts relative alla versione 15, riassumiamo nella Tabella 5.9 le principali caratteristiche delle varie versioni finora realizzate dal punto di vista dei processi simulabili; per questo tralasciamo tutte le versioni precedenti la 13d in quanto in esse l’unica tipologia di task definita è quella dei periodici critici garantiti (pcg) indipendenti, ossia senza vincoli di precedenza e con l’unico blocco a tempo di esecuzione non in sezione critica.

processi real-time istanziati (simulabili) versione pcg one-shot periodic sporadic vincoli di

precedenza n. max di blocchi

sezioni critiche

13d 1 14 1 14b 1 14c 1 14d 1 15 3 15a 3 15b 3 15c 3 15d 3

Tabella 5.9 – Principali caratteristiche delle versioni successive alla 13c

121

5.3.1 Descrizione delle Charts Nella Top-Level Activity-Chart SYSTEM_GRMS (riportata in Figura 5.26) ci limitiamo ad osservare che l’unica attività aggiunta allo schema generale del sistema è il già citato processo SEMAPHORE, la cui Control-StateChart regola gli accessi alle sezioni critiche mediante l’utilizzo di semafori logici binari e il protocollo di Priority Ceiling, scambiando opportuni segnali d’interazione (attraverso apposite code e condizioni) con il global_monitor e con i vari task real-time istanziati nel modello (come del resto si può notare anche dall’off-page Chart PROC1_PCG illustrata in Figura 5.29). Vediamo ora più in dettaglio le modifiche effettuate nella versione 15 per realizzare l’accesso alle sezioni critiche.

Figura 5.26 – Schema completo del SYSTEM_GRMS della versione 15

5.3.1.1 ACCEPTANCE Nel modulo di acceptance (vedi Figura 5.27) l’unica differenza che risalta ad una prima osservazione è la presenza della nuova Sub-Chart @SCHEDULABILITY_TEST_SC (vedi Figura 5.28); tale StateChart implementa la procedura SDL schedulabilty_test_sc e viene utilizzata dal proc_acceptance per l’analisi di schedulabilità solamente nel caso vi siano almeno due processi pcg che entrano in sezione critica (contatore NUMSC>1) con conseguente possibile presenza di tempi di blocco; nel caso infatti vi sia al massimo un solo task pcg che entra in sezione critica (contatore NUMSC<=1) con conseguente assenza di tempi di blocco (processi indipendenti), l’acceptance eseguirà il solito test di garanzia a due stadi (RM + eventuale GRMS) già visto in tutte le precedenti versioni (StateChart @SCHEDULABILITY_TEST).

122

Figura 5.27 – StateChart proc_acceptance della versione 15

Figura 5.28 – Sub-StateChart schedulability_test_sc del proc_acceptance

123

Figura 5.29 – Activity-Chart PROC1_PCG della versione 15

Figura 5.30 – StateChart global_monitor della versione 15

124

5.3.1.2 GLOBAL_MONITOR Passiamo ora all’analisi del global_monitor: dalla Figura 5.30 si può notare che la StateChart in questione si è notevolmente complicata, soprattutto per quanto riguarda la zona dello stato @CLOSE nel quale si entra dallo stato @WAIT_COMPLETATION_OR__NEW_START in seguito al completamento (evento TFINE) di un blocco a tempo di esecuzione simulata di un qualche processo. In tal caso infatti (vedi Figura 5.32), dopo aver spedito il segnale ‘complete’ al task che ha testè terminato il suo blocco (azione COMPLETE_TO_RUNNING), si controlla se il blocco appena concluso era di sezione critica (variabile SMP). In caso negativo (SMP=0) si rimuoverà tramite l’apposita procedura RIMOZIONE (vedi Figura 5.67) il (primo) processo da TABLE se esso non ha ulteriori blocchi a tempo (FG=0) da eseguire (e la transizione entrando nello stato SKEDULE proseguirà dallo stato ‘esterno’ PID), mentre se ha ancora uno o due blocchi a tempo da eseguire (FG=1), si andrà nello stato @WAIT_FOLLOWING_PARTS senza rimuovere il processo da TABLE. In caso positivo invece (SMP/=0), il segnale ‘complete’ viene spedito anche al processo semaphore (azione COMPLETE_TO_SEM) con l’indicazione del numero di sezione critica: se il blocco a tempo di sezione critica appena terminato è l’ultimo (FG=0), il processo viene rimosso da TABLE tramite la procedura RIMOZIONE e lo stato successivo è @WAIT_SEM_0; se invece deve essere eseguito un ultimo blocco a tempo non di sezione critica (FG=1), si controlla se il processo ha ereditato una priorità più alta (boostprio) durante l’esecuzione in sezione critica: in tale eventualità lo si riporta alla priorità originaria contenuta nell’apposito campo OWN di TABLE ed è inoltre necessario vedere se il processo, tornato alla sua priorità originaria, mantiene priorità maggiore del secondo processo pronto in TABLE. Se il processo non ha più la massima priorità verrà dunque rimosso da TABLE e lo stato successivo sarà @WAIT_SEM_0, altrimenti il processo rimane in testa alla coda TABLE e lo stato successivo sarà @WAIT_SEM_1. Prima di analizzare le tre sub-chart dello stato @CLOSE osserviamo che, se nello stato @WAIT_COMPLETATION_OR__NEW_START viene generato (in seguito alla scrittura nella coda BOOSTPRIO_QUEUE) l’evento BOOSTPRIO_SIG, si entra nel nuovo stato @BOOSTPRIO nel quale (vedi Figura 5.31) al processo indicato dal parametro SENDER viene fatta ereditare la priorità (più alta) del task che SENDER sta bloccando nell’accesso ad una sezione critica. Più in particolare, nella tabella TABLE viene cercata la riga corrispondente al processo con PID=SENDER e viene cambiato il valore del campo P con la nuova priorità ereditata: se il processo non è quello che sta correntemente eseguendo (in caso contrario si torna direttamente allo stato @WAIT_COMPLETATION_OR__NEW_START) si dovrà controllare se la nuova priorità ereditata sia superiore a quella del processo che possiede attualmente la CPU. In caso negativo la procedura MOVE_FORWARD (vedi Figura 5.64) sposterà semplicemente in avanti in TABLE (se necessario) il processo con la nuova priorità ereditata e si ritornerà ancora una volta nello stato @WAIT_COMPLETATION_OR__NEW_START. In caso positivo invece il processo con la priorità ereditata effettuerà preemption su quello che sta correntemente eseguendo, la procedura MOVE_FORWARD provvederà a spostare il processo con la priorità ereditata in testa a TABLE e quello che ha subito prelazione in seconda posizione, e infine si uscirà nello stato esterno AGG.

125

Figura 5.31 – Sub-StateChart boostprio del global_monitor

Ritorniamo dunque all’analisi delle tre sub-StateCharts di CLOSE partendo da @WAIT_SEM_0 e @WAIT_SEM_1: in ambedue questi stati gli unici due segnali attesi sono le condizioni GOON e q_length(S_PARTITO_QUEUE)>0 rese vere dal processo semaphore. Se si entra in @WAIT_SEM_0 (vedi Figura 5.33) significa che il processo che ha appena terminato il suo blocco a tempo di sezione critica non deve eseguire nessun altro blocco a tempo. Allora, con la condizione GOON semaphore comunica che non c’è nessun nuovo processo che è entrato in sezione critica dopo la liberazione del semaforo e il global_monitor provvede a schedulare il prossimo processo pronto di TABLE ripartendo dallo stato esterno PID. Al contrario, la condizione q_length(S_PARTITO_QUEUE)>0 vera indica che un nuovo processo è entrato in sezione critica dopo la liberazione del semaforo: questo nuovo task verrà così inserito in TABLE (vedi procedura INSERIMENTO in Figura 5.61) e solo ora il global_monitor potrà schedulare il processo con la priorità più alta ripartendo ancora una volta dallo stato esterno PID. Se invece si entra in @WAIT_SEM_1 (vedi Figura 5.34) significa che il processo che ha appena terminato il suo blocco a tempo di sezione critica deve eseguire un ulteriore ed ultimo blocco a tempo. La condizione GOON ha lo stesso significato di sopra ma ora lo stato di arrivo è @WAIT_FOLLOWING_PARTS, nel quale si aspetterà il verificarsi della condizione q_length(PARTITO_QUEUE)>0 relativa appunto all’ultimo blocco a tempo. Se invece diventa vera la condizione q_length(S_PARTITO_QUEUE)>0, ovvero un nuovo processo è pronto ad eseguire in sezione critica, si controlla il valore della sua priorità: se questa è superiore a quella del processo in testa a TABLE quest’ultimo, dopo l’aggiornamento del fattore di utilizzazione totale U_TOT, viene eliminato dalla tabella sovrascrivendone la prima riga con i valori del nuovo processo letti dalla coda S_PARTITO_QUEUE, e si riparte dallo stato esterno AGG; in caso contrario il nuovo task pronto viene semplicemente inserito nella giusta posizione in TABLE dalla procedura INSERIMENTO e si entra nello stato @WAIT_FOLLOWING_PARTS.

126

Figura 5.32 – Sub-StateChart close del global_monitor

Figura 5.33 – Sub-StateChart wait_sem_0 di close

127

Figura 5.34 – Sub-StateChart wait_sem_1 di close

Le tre figure seguenti (Figura 5.35, Figura 5.36 e Figura 5.37) illustrano la specifica Statemate della StateChart @WAIT_FOLLOWING_PARTS e delle relative Sub-Chart: in questo stato il sistema è in attesa dell’arrivo del terzo ed ultimo blocco a tempo del processo che sta correntemente eseguendo, vale a dire aspetta il verificarsi della condizione q_length(PARTITO_QUEUE)>0, ma poiché possono verificarsi anche altre condizioni trigger, sono previste transizioni per tutti i segnali possibili. La Figura 5.36 mostra lo stato @PARTITO nel quale si entra in seguito all’evento PARTITO_SIG generato contestualmente alla lettura dalla coda (non vuota) PARTITO_QUEUE (esecuzione non in sezione critica) o S_PARTITO_QUEUE (esecuzione in sezione critica): se i dati prelevati dalla coda si riferiscono al blocco a tempo aspettato, cioè al processo che sta correntemente eseguendo (RUNNING=SENDER), dopo aver aggiornato opportunamente U_TOT e TABLE si esce nello stato esterno LASTCLOCK ossia in definitiva si rientra in @WAIT_COMPLETION_OR__NEWSTART; se invece i valori si riferiscono all’arrivo di un nuovo processo (RUNNING/=SENDER) si controlla se quest’ultimo ha priorità di esecuzione rispetto a quello che sta attualmente eseguendo: le due transizioni che ne scaturiscono sono analoghe a quelle già viste in WAIT_SEM_1. La Figura 5.37 mostra invece lo stato @BOOST_PRIO nel quale si entra in seguito all’evento BOOSTPRIO_SIG generato contestualmente alla lettura dalla coda (non vuota) BOOSTPRIO_QUEUE; in esso si controlla se la nuova priorità che verrà ereditata dal processo specificato dal parametro SENDER è più alta di quello che sta correntemente eseguendo: se è più alta, il task che sta attualmente eseguendo viene rimosso da TABLE per mezzo della solita procedura RIMOZIONE ed eseguirà quello con la priorità ereditata.

128

Infine la parte destra della Figura 5.35 mostra la generazione dell’evento KILLED_OR_FAILED in seguito all’uccisione o al fallimento di un processo: la transizione che ne scaturisce è quasi identica a quella presente in Figura 5.30, in cui lo stato di partenza è però WAIT_COMPLETION_OR__NEWSTART, che abbiamo già visto nella versione 14 e che è stata adattata al nuovo modello tramite l’aggiunta dello stato @W_SEM_0 (praticamente equivalente a @WAIT_SEM_0: cfr. Figura 5.33 e Figura 5.38). Il resto della specifica del global_monitor è sostanzialmente rimasto invariato: per la sua descrizione si rimanda quindi ai paragrafi 5.1.1.6 e 5.2.3.

Figura 5.35 – Sub-StateChart wait_following_parts di close

Figura 5.36 – Sub-StateChart partito di wait_following_parts

129

Figura 5.37 – Sub-StateChart boost_prio di wait_following_parts

Figura 5.38 – Sub-StateChart w_sem_0 del global_monitor

Figura 5.39 – StateChart semaphore della versione 15

130

5.3.1.3 SEMAPHORE Come già accennato precedentemente, il processo semaphore gestisce gli accessi alle otto3 sezioni critiche condivise, mutuamente esclusive e preemptable mediante l’utilizzo di semafori di mutua esclusione e implementando il protocollo di Priority Ceiling. Tale protocollo di accesso richiede che ad ogni sezione critica venga assegnato un tetto di priorità, detto appunto ceiling, pari alla più alta priorità dei processi che possono entrare in quella sezione (per maggiori dettagli si rimanda alla parte teorica relativa). Per convenzione si è deciso che le prime due sezioni critiche (1 e 2) sono riservate esclusivamente ai processi periodici critici garantiti: ciò è necessario affinché sia possibile determinare con esattezza i loro tempi di blocco e conseguentemente poterne eseguire l’analisi di schedulabilità. La priorità dei pcg è determinata dal sistema in modo inversamente proporzionale al loro periodo, secondo la schedulazione Rate Monotonic: poiché si è stabilito che il periodo più corto non possa essere inferiore alle 10 unità di tempo, ne segue che il ceiling delle prime due sezioni critiche è uguale a 10. Si è poi deciso che le successive due sezioni critiche (3 e 4) possano essere accedute da task con una priorità massima di 500 (cioè con valore di priorità >= 500 poiché, secondo la teoria del RM, ad un numero più alto corrisponde una priorità più bassa), le successive tre sezioni critiche (5, 6 e 7) da processi con una priorità massima di 1000 (cioè con valore di priorità >= 1000) e infine l’ultima sezione critica (MAX_SC ovvero 8) da processi con una priorità massima di 1500 (cioè con valore di priorità >= 1500). In questa maniera si hanno 4 (valore contenuto nel parametro MAX_S) differenti ceiling rispettivamente di valore 10, 500, 1000 e 1500: questi valori possono essere cambiati dal progettista, facendo però attenzione in quanto il loro cambiamento può richiedere anche delle modifiche a livello di specifica del processo semaphore. Poiché si hanno 4 ceiling, in base alla definizione del protocollo di Priority Ceiling, si rendono necessari 4 semafori logici binari, uno per ciascun ceiling: se ad esempio la sezione critica 2 è occupata e la 1 è libera, nessun processo potrà entrare nella 1 finché anche la 2 non sarà libera, proprio perché le due sezioni hanno lo stesso ceiling e quindi lo stesso semaforo. Ma partiamo con l’analisi della specifica (vedi Figura 5.39); nell’azione INIT vengono inizializzate le due strutture dati principali su cui lavora la StateChart: la prima è una matrice (array di record) denominata TABLE che serve per la gestione dei 4 semafori ed è inizializzata come in Tabella 5.10.

Tabella 5.10 – Struttura dati di TABLE (tabella dei 4 semafori logici binari)

3 Tale valore, come già anticipato nel capitolo 2, è stato ereditato direttamente dalle specifiche SDL di riferimento e nel nostro modello è memorizzato nell’apposito parametro MAX_SC.

131

Il campo CEIL di TABLE contiene il ceiling del semaforo, il campo P conterrà la priorità del processo che è entrato in possesso di una delle sezioni critiche gestite dal quel semaforo ed infine il campo PID l’identificatore numerico relativo al processo in questione. Se il task non può entrare nella sezione critica richiesta esso verrà considerato bloccato e perciò inserito nella struttura dati denominata QUE che rappresenta proprio la coda dei processi bloccati.

Tabella 5.11 – Struttura dati di QUE (tabella dei processi bloccati)

La tabella QUE ha una capienza massima di MAX_P-2 processi bloccati ed ogni sua riga è composta dai 7 campi seguenti (vedi Tabella 5.11): • PID: contiene il PID del processo bloccato. • WCASE: contiene il worst case computation time relativo alla sezione critica. • PRIO: contiene la priorità del processo (ossia il periodo per i task di tipo pcg). • FG: contiene il valore del flag binario (bit) spedito a semaphore mediante la coda

DEMAND_QUEUE: se esso vale 0 (default), il processo bloccato terminerà la sua istanza di esecuzione dopo la sezione critica; se invece vale 1, il processo bloccato dovrà eseguire una terza ed ultima fase di esecuzione non critica dopo la sezione critica. Tale parametro non serve comunque a semaphore ma bensì al global_monitor al quale verrà inviato al momento opportuno.

• SEM: contiene il numero (da 1 a 4 o meglio da 1 a MAX_S) del semaforo che gestisce la sezione critica in cui il processo bloccato attende di entrare.

• SC: contiene il numero (da 1 a 8 o meglio da 1 a MAX_SC) della sezione critica. • PERIOD: contiene il valore del periodo del processo e serve, insieme a WCASE, per

il calcolo del fattore di utilizzazione totale U_TOT corrente. La struttura dati QUE viene inizializzata come la riga 2 della Tabella 5.11: il campo PID è inizializzato con il valore ‘null’ convenzionale (1000), mentre il campo PRIO viene posto ad un valore altissimo (1000000) poiché esso rappresenta (come al solito) la chiave di ordinamento della coda; in testa vi saranno quindi sempre i processi bloccati con priorità più alta, ossia con un basso valore numerico di PRIO. Contrariamente a SDL, non è invece necessario inizializzare il vettore binario CRITIC in quanto in Statemate il valore di default di una variabile di tipo bit è proprio 0; tale array infatti è composto da 8 (MAX_SC) bit, uno per sezione critica: qualora un processo fallisca all’interno di una sezione critica, essa verrà chiusa ponendo ad 1 il corrispondente elemento del vettore CRITIC.

132

Figura 5.40 – Sub-StateChart waiting di semaphore

Contestualmente all’azione INIT il processo semaphore entra nello stato iniziale @WAITING (vedi Figura 5.40) in cui aspetta le richieste di accesso a sezioni critiche da parte dei processi real-time simulati (scritte nell’apposita coda DEMAND_QUEUE) e i segnali ‘complete’ e ‘failed’ (scritti nella sua input queue SEMAPHORE_QUEUE) per entrare successivamente, in base all’evento generato (DEMAND, COMPLETE o FAILED), nella corrispondente Sub-StateChart (@DEMAND, @COMPLETE o @FAILED), dalla quale comunque alla fine ritornerà sempre nello stato @WAITING. La Figura 5.41 mostra la StateChart demand: attraverso il valore del parametro SC letto dalla coda DEMAND_QUEUE viene determinato quale dei 4 semafori è quello che gestisce la sezione critica in questione (vedi la chart ctrl_sc in Figura 5.42). La variabile MAXCEIL memorizza il valore del ‘tetto’ di priorità più alto scelto fra l’insieme dei semafori correntemente bloccati: questo equivale a prendere il valore numerico più basso dei campi CEIL di TABLE il cui campo corrispondente PID non è ‘null’ (1000); a questo scopo MAXCEIL è stata inizializzata con un valore molto elevato (900000). In base al protocollo di Priority Ceiling si ricorda che un processo può entrare in sezione critica solo se la sua priorità è più alta del più alto ceiling associato ai semafori correntemente bloccati: per come è stata definita la priorità (valore numerico basso implica priorità alta) questo si traduce nel verificare che il parametro PRIO prelevato dalla coda DEMAND_QUEUE sia inferiore a MAXCEIL. Se ciò è verificato, unitamente al fatto che la componente di CRITIC corrispondente alla sezione critica richiesta sia settata a 0 (in caso contrario viene scritto il segnale ‘disabled’ nella coda del task SENDER), il processo può entrare in sezione critica: allora semaphore scriverà nell’apposita coda S_PARTITO_QUEUE i parametri di esecuzione del task comunicando così al global_monitor che un nuovo processo è pronto ad eseguire in sezione critica, quindi introdurrà i valori del processo partito in TABLE e cambierà opportunamente il valore di MAXCEIL.

133

Figura 5.41 – Sub-StateChart demand di semaphore

Figura 5.42 – Sub-StateChart ctrl_sc di demand

Se al contrario il valore di PRIO del task non è minore di MAXCEIL il processo sarà bloccato e perciò inserito nella sua giusta posizione nella coda ordinata QUE tramite l’apposita procedura INSERT (vedi Figura 5.63); prima dell’inserimento in QUE comunque, viene verificato se è necessario innalzare la priorità del processo che blocca il task in questione: in caso affermativo (vale a dire che il valore di PRIO è compreso tra il valore del campo CEIL e del campo P di un qualche semaforo occupato) vengono spediti al global_monitor tramite l’apposita coda BOOSTPRIO_QUEUE la nuova priorità (PRIO) e il PID del processo a cui va innalzata (TABLE(J).PID); inoltre viene aggiornato il campo P in TABLE con la priorità innalzata (PRIO).

134

Figura 5.43 – Sub-StateChart complete di semaphore

La Figura 5.43 mostra la StateChart complete nella quale si entra alla ricezione nell’input queue SEMAPHORE_QUEUE del segnale ad alta priorità ‘complete’; questo segnale viene inviato dal global_monitor al semaphore, insieme al parametro SMP indicante il numero di semaforo occupato da un processo, quando il processo in questione ha terminato l’esecuzione della propria sezione critica, subito dopo aver reinizializzato ai valori di default i campi P e PID del semaforo indicato in SMP in modo da renderlo libero. In tale Chart verrà poi cambiato opportunamente il valore della variabile MAXCEIL: si fa notare che, se ad esempio il semaforo rilasciato è il 3 con ceiling pari a 1000, significa che i semafori 1 e 2 sono liberi (altrimenti sarebbe stato rilasciato prima l’1 in base alla priorità) e quindi MAXCEIL assumerà il valore del ceiling del semaforo 4, se questo è occupato, altrimenti il valore elevatissimo di default (900000). A questo punto, poiché si è liberato un semaforo, si deve andare a vedere se nella tabella dei processi bloccati QUE vi è un task che può accedere alla sua sezione critica. Osserviamo che, in base alla definizione del protocollo di Priority Ceiling, è sufficiente avere un’unica coda dei processi bloccati anziché tante code distinte quanti sono i semafori; il processo in testa alla coda è infatti sempre quello a priorità più alta: se questo processo non può entrare in sezione critica perché ha una priorità inferiore al più alto ceiling dei semafori occupati, l’eventuale task che lo segue in coda, avendo una priorità minore o al più uguale, a maggior ragione non potrà entrare nella sua sezione critica. Dunque, se il primo processo di QUE non può accedere alla sua sezione critica, prima di ritornare nello stato @WAITING si rende vera la condizione GOON in modo da comunicare al global_monitor che nessun altro processo è entrato in sezione critica. Se

135

invece questo processo non può entrarvi perché la sua sezione critica è stata chiusa a causa di un qualche fallimento (cioè la componente del vettore di stato CRITIC relativa alla sezione critica di interesse è settata ad 1), esso riceverà da semaphore tramite la sua input queue il segnale ‘disabled’ (che, come vedremo tra poco, lo farà a sua volta fallire) e verrà dunque rimosso da QUE tramite l’apposita procedura REMOVE (vedi Figura 5.65); si andrà così a considerare il processo successivo in coda QUE il quale, dopo l’elaborazione della subroutine REMOVE, sarà diventato il primo della tabella dei processi bloccati. Quando un task della coda QUE riesce ad entrare in sezione critica, i suoi parametri di esecuzione vengono inviati al global_monitor tramite la coda S_PARTITO_QUEUE, il processo viene rimosso dalla coda e vengono aggiornati opportunamente i valori di TABLE e MAXCEIL.

Figura 5.44 – Sub-StateChart failed di semaphore

Infine la Figura 5.44 mostra la StateChart failed nella quale si entra alla ricezione nell’input queue SEMAPHORE_QUEUE del segnale ‘failed’ spedito da un qualche processo che ha superato il suo vincolo temporale (deadline) insieme al parametro SC contenente il numero della sezione critica relativa al processo stesso. Se il task fallito è al momento all’interno della sua sezione critica (vale a dire che il suo PID è presente nella struttura dati TABLE), la chart provvede ad eliminare questo processo da TABLE e a chiudere la sezione critica interessata settando a 1 la componente di CRITIC relativa ad SC; se poi il processo occupava il semaforo con il ceiling più alto, è opportuno verificare se qualche eventuale task bloccato può entrare in sezione critica: a tale scopo l’entrata nello stato SKEDULE conduce direttamente nello stato @COMPLETE. Se invece il processo non è al momento all’interno della sua sezione critica e dunque è bloccato in coda QUE, esso viene semplicemente rintracciato ed eliminato dalla tabella con la procedura REMOVE alla quale viene passato come parametro il numero di riga individuato.

136

Figura 5.45 – Generic StateChart proc_pcg della versione 15

5.3.1.4 Processi PCG Passando ora all’analisi della Carta Parametrica che implementa la ‘vista di simulazione’ dei processi real-time di tipo pcg (vedi Figura 5.45) nella versione 15 possiamo notare che l’unica novità è l’introduzione di due nuovi stati: FAILURE_CRITICAL_SECTION_CLOSED e @CRITICAL_SECTION. Il primo rappresenta semplicemente lo stato di fallimento senza uscita nel quale il task simulato finisce nel caso riceva nella sua input queue il segnale ‘disabled’ con il quale semaphore gli comunica che la sezione critica richiesta è stata chiusa. Il secondo stato è stato appositamente implementato per gli altri due eventuali blocchi a tempo (del quale il secondo in sezione critica) di esecuzione del task. Più in particolare, una volta superato il test di schedulabilità e settato il timer logico relativo al suo periodo (stato GRANTED), il processo controlla innanzitutto se è previsto anche un secondo blocco di computazione in sezione critica: in caso negativo (SWC=0) l’esecuzione simulata procede secondo lo stesso identico schema già illustrato nelle versioni precedenti; in caso positivo invece (SWC/=0), dopo aver scritto i parametri di esecuzione nell’apposita coda PARTITO_QUEUE ‘indirizzata’ al global_monitor, si entra nel nuovo stato @CRITICAL_SECTION. Nella StateChart contenuta al suo interno (vedi Figura 5.46) il processo aspetta l’evento START_TM_P dal global_monitor per entrare nello stato di effettiva esecuzione o sospensione simulata (EXECUTING_OR_SUSPENDED_1) dal quale uscirà – in condizioni di normale e corretto funzionamento del sistema – solo in seguito alla ricezione nella sua input queue

137

del segnale ‘complete’ (che genera a sua volta l’evento COMPLETE_FWC) con il quale global_monitor gli comunica il completamento del suo primo blocco a tempo. A questo punto si controlla la presenza di un terzo ed ultimo blocco omogeneo a tempo di esecuzione simulata (non in sezione critica): in caso negativo (TWC=0) si entra nello stato @CRITICAL_SECTION_OR_BLOCKED_0, in caso affermativo invece nello stato @CRITICAL_SECTION_OR_BLOCKED_1. Le semplici StateChart contenute al loro interno sono praticamente uguali (vedi Figura 5.47) tranne che per le transizioni d’ingresso e d’uscita: più precisamente, nel caso di assenza del terzo blocco opzionale, analogamente a come avviene nell’azione WRITE_PARTITO_QUEUE_0, il processo nell’azione DEMAND_0 scrive i suoi parametri di esecuzione nell’apposita coda (in questo caso è la DEMAND_QUEUE ed è indirizzata al processo semaphore) impostando a 0 il flag di presenza di un successivo blocco di computazione. Nel caso invece di presenza del terzo blocco a tempo, analogamente a come avviene nell’azione WRITE_PARTITO_QUEUE_1, il processo nell’azione DEMAND_1 scrive i suoi parametri di esecuzione nell’apposita coda, impostando però a 1 il flag di presenza di un successivo blocco di computazione. Una volta entrati nello stato WAIT_QUEUE (che simula l’attesa di esecuzione e l’esecuzione stessa in sezione critica del task in questione) si potrà uscire – come del resto avviene anche per lo stato EXECUTING_OR_SUSPENDED_1 di livello superiore – solo quando almeno un evento verrà scritto nella coda d’ingresso INPUT_NEW_PROC_P. Nel caso di EXECUTING_OR_SUSPENDED_1 i segnali possibili sono, oltre al già discusso ‘complete’, ‘tperiodo’ e ‘kill’: il segnale ‘tperiodo’ indica la scadenza prematura della deadline periodica del task pcg, con conseguente generazione dell’evento TPERIODO, che innesca a sua volta l’entrata nello stato esterno senza uscita FAILURE e la segnalazione dell’avvenuto fallimento al global_monitor, all’acceptance e al semaphore; il segnale ‘kill’ indica invece l’uccisione forzata del processo, con conseguente generazione dell’evento KILL, che innesca a sua volta l’entrata nello stato esterno senza uscita KILLED. Nel caso invece di @CRITICAL_SECTION_OR_BLOCKED_0 i segnali possibili sono ‘complete’, ‘tperiodo’ e ‘disabled’: il segnale ‘complete’ indica il corretto completamento dell’istanza corrente di esecuzione simulata in sezione critica del processo, con conseguente generazione dell’evento COMPLETE, che innesca a sua volta l’entrata nello stato esterno SUCCESSFUL_EXECUTED; per il segnale ‘tperiodo’ vale quanto detto sopra, mentre per il segnale ‘disabled’ si rimanda alla precedente discussione sullo stato FAILURE_CRITICAL_SECTION_CLOSED. Nel caso infine di @CRITICAL_SECTION_OR_BLOCKED_1, i segnali possibili sono ancora ‘complete’, ‘tperiodo’ e ‘disabled’: il segnale ‘complete’ indica anche in questo caso il corretto completamento dell’istanza corrente di esecuzione simulata in sezione critica del processo, con conseguente generazione però dell’evento COMPLETE_SC, che innesca a sua volta l’azione WRITE_PARTITO_QUEUE_3 e l’entrata nello stato esterno WAIT_ACTIVATION relative al terzo ed ultimo blocco a tempo del task. Per quanto riguarda infine la specifica delle Generic StateCharts relative alle altre tipologie di processi real-time modellate nel nostro sistema (sporadici, one-shot e periodici firm), le modifiche introdotte sono praticamente uguali a quelle appena illustrate per i task pcg: osserviamo solo che per i processi che possono prevedere dei vincoli di precedenza singoli (one-shot e periodici non garantiti) nelle Activity-Charts contenenti le loro generic instances si può notare la presenza aggiuntiva, oltre che del già citato semaphore, di tutti i task loro potenziali predecessori o successori con relative data-flow lines di collegamento costituite dall’apposito vettore di condizioni GO.

138

Figura 5.46 – Sub-StateChart critical_section di proc_pcg

Figura 5.47 – Sub-StateCharts critical_section_or_blocked_0 e

critical_section_or_blocked_1 di critical_section

139

Figura 5.48 – Activity-Chart PROC3_S della versione 15a

Figura 5.49 – Generic StateChart proc_sporadic della versione 15a

140

Figura 5.50 – Activity-Chart PROC4_OS della versione 15b

Figura 5.51 – Generic StateChart proc_one_shot della versione 15b

141

Figura 5.52 – Activity-Chart PROC1_P della versione 15c

Figura 5.53 – Generic StateChart proc_periodic della versione 15c

142

5.3.2 Procedural StateCharts In questa sezione riportiamo per completezza tutte le StateCharts procedurali utilizzate nel nostro sistema applicativo (con particolare riferimento alle versioni finali) e che abbiamo spesso richiamato nelle precedenti descrizioni; per motivi di tempo e di spazio però, non ci addentreremo in una loro discussione dettagliata.

Figura 5.54 – Subroutine AGGIORNA_ACCPERIODO_TAB di proc_acceptance

Figura 5.55 – Subroutine AGGIORNO_OLDB di schedulability_test_sc

143

Figura 5.56 – Subroutine AGGIORNO_TABELLA di proc_acceptance

Figura 5.57 – Subroutine CRITICAL_ZONE_TEST di schedulability_test

144

Figura 5.58 – Subroutine DECR_PERIODO di proc_acceptance

Figura 5.59 – Subroutine ELIMINO_RIGA di schedulability_test_sc

145

Figura 5.60 – Subroutine INCR_PERIODO di proc_acceptance

Figura 5.61 – Subroutine INSERIMENTO di global_monitor

146

Figura 5.62 – Subroutine INSERISCO_AGGIORNO di schedulability_test_sc

Figura 5.63 – Subroutine INSERT di demand

147

Figura 5.64 – Subroutine MOVE_FORWARD di global_monitor

Figura 5.65 – Subroutine REMOVE di semaphore

Figura 5.66 – Subroutine REMOVING di proc_acceptance

148

Figura 5.67 – Subroutine RIMOZIONE di global_monitor

Figura 5.68 – Subroutine RIMOZIONE_I di global_monitor

Figura 5.69 – Subroutine SC_TEST di schedulability_test_sc

149

6. Analisi statica e simulazione del modello

6.1 Analisi statica in Statemate Prima di poter effettuare correttamente una qualsivoglia simulazione di esecuzione del modello specificato è spesso consigliabile, se non indispensabile, effettuare un’analisi statica delle specifiche stesse. In Statemate MAGNUM v2.1, pur essendoci già in fase di specifica uno stretto controllo sui tipi di dati utilizzati e sulla sintassi degli statements che li manipolano, è disponibile un apposito strumento di analisi statica (Check Model) con il quale è possibile effettuare, in qualsiasi fase della specifica formale, una verifica statica (parziale o completa) delle Charts e delle subroutines utilizzate nel modello. Più in particolare, tale controllo (incrociato) serve a rilevare tutti gli eventuali problemi di completezza e/o di correttezza nella specifica corrente (project workarea) inclusa nell’ambito di visibilità della definizione corrente (definition scope), comprensivi del loro codice di riferimento interno di error handling e di una sintetica ma indicativa descrizione sulla natura dell’errore stesso (cfr. l’help on line di Statemate). Il test di completezza (completeness check) rileva la mancanza o la ridondanza delle informazioni nella specifica del modello. Ad esempio, una transizione di stato senza un elemento trigger (evento o condizione) è incompleta (missing warning): vedi la transizione dallo stato S1 allo stato S2 in Figura 6.1.

Figura 6.1 – Completeness warning

Un tipico caso di ridondanza invece è quando un elemento (ad esempio una condizione) è definito nel Data Dictionary del modello ma non è utilizzato in nessuna parte della specifica formale stessa (vedi ad esempio il Listato 6.1). Il test di correttezza (correctness check) serve invece a rilevare errori (non warnings) di inconsistenza nella specifica del modello. A tal proposito, bisogna infatti precisare che la presenza di completeness warnings in fase di analisi statica del modello, anche se spesso sconsigliabile, rappresenta raramente una condizione di fatal error che impedisce l’esecuzione o simulazione (parziale o totale) del modello stesso (vedi ancora il Listato 6.1), in quanto la mancanza o la ridondanza delle informazioni potrebbero essere legate alla natura sperimentale delle varie versioni intermedie di un sistema non ancora ben definito né completamente specificato dal progettista, ma tuttavia parzialmente funzionante.

S1 S2

S3

E[C]

150

Al contrario i correctness errors, in quanto tali, devono essere necessariamente evitati o risolti in qualsiasi fase della specifica per permettere una corretta esecuzione e simulazione del modello. Ad esempio, la presenza di un ciclo (loop) in una compound transition è considerato un errore di correttezza (vedi la transizione composta caratterizzata dai triggers [C1] e [C2] in Figura 6.2), in quanto nelle StateCharts Statemate una transizione, anche se composta, è sempre svolta in un unico passo (a tal proposito osserviamo che i pallini neri in figura non rappresentano stati ma condition connectors) e la presenza al suo interno di un ciclo potrebbe dare luogo ad errate situazioni di non-determinismo.

Figura 6.2 – Correctness error

Un altro tipico caso di errore di correttezza è quando un data-item di tipo non ancora definito (undefined textual element) è utilizzato nel modello in modo ‘incoerente’ (ad esempio, in alcune parti della specifica è usato come integer mentre in altre come string). Tale errore del resto è emblematico del rigido static type checking caratteristico di Statemate e della maggior parte dei linguaggi di specifica formale. Considerando ora il nostro modello, dal Listato 6.1 contenente i risultati di un’analisi statica completa (ricordiamo che è possibile anche un checking parziale delle singole Charts) effettuata sulla versione 7 del sistema, si osserva immediatamente che non risultano errori di correttezza, mentre i vari avvisi di completezza sono tutti riconducibili a due ben distinti gruppi. Correctness: ------------ No errors Completeness: ------------- o (C2005) Elements that are not referenced in Statemate expressions and definitions: condition attivo_1 o (C2005) Elements that are not referenced in Statemate expressions and definitions: condition attivo_2 o (C2005) Elements that are not referenced in Statemate expressions and definitions: condition attivo_3 o (C2005) Elements that are not referenced in Statemate expressions and definitions: condition attivo_acceptance_17

[not C2]

[C2]

[C1] [not C1]

E

151

o (C7221) Controlled-termination subactivities that are not stopped by the statechart: TFINE1 TFINE2 TFINE3 TFINE_ACC o (C7221) Controlled-termination subactivities that are not stopped by the statechart: ACCEPTANCE PROC_GLOBAL_MONITOR PROC1 PROC2 PROC3

Listato 6.1 – Risultati dell’analisi statica del nostro sistema (versione 7)

I primi quattro completeness warnings, riguardanti delle condizioni, a prima vista sembrerebbero un tipico caso di ridondanza degli elementi; in realtà, come vedremo meglio nel paragrafo 6.2.6, gli elementi segnalati sono delle compound conditions definite esclusivamente per scopi di monitoraggio in fase di simulazione (vedi Figura 6.23) che non vengono quindi mai utilizzate (referenced) direttamente o indirettamente nella specifica formale del modello. Gli altri avvisi rimanenti richiedono invece un apposito approfondimento. A tal proposito bisogna innazitutto premettere che, nel caso di activation style di tipo software (vedi il paragrafo 6.2.2.1) – che come vedremo è proprio la nostra situazione – per ciascuna (sub)attività si può specificare un Termination Type caratteristico, che dipende strettamente dalla natura stessa dell’Activity-Chart e che influisce direttamente nell’analisi, nella simulazione e nella generazione del codice sorgente del modello. In particolare, i possibili tipi di attività sono tre:

1. Procedure-like (mini-specs) 2. Reactive-controlled (controlled-termination) [default] 3. Reactive-self (self-termination)

Tutti i tre tipi di attività sono avviate, tramite l’apposito costrutto start(), dalla Control-Activity sorella appartenente al stesso livello nella gerarchia delle Charts. Una prima differenza risiede nel fatto che una procedure-like Activity, quando avviata, completa la sua esecuzione in un singolo passo (proprio come una subroutine), mentre i due tipi reactive (che possono essere data-driven o event-driven) rimangono attivi per un certo numero di steps, in base alla loro specifica. Per quanto riguarda la terminazione invece, una reactive-controlled Activity normalmente viene disattivata, tramite l’apposito costrutto stop(), dalla stessa Control-Activity (rappresentata da una StateChart opportuna) che l’ha attivata precedentemente, mentre una reactive-self Activity, come indica il termine stesso, termina autonomamente la propria esecuzione al momento opportuno. Per la loro intrinseca natura, le procedure-like Activities possono contenere esclusivamente mini-specs, mentre i due tipi reattivi sia mini-specs che Control-Activities. Da queste considerazioni e dall’analisi del nostro modello si evince facilmente che tutte le attività specificate sono di tipo reattivo: quasi tutte le nostre attività contengono infatti come unica sub-activity una Control-Activity (vedi la gerarchia del system_grms in Figura 6.3), come del resto è tipico in tutti i sistemi real-time altamente reattivi.

152

Figura 6.3 – Gerarchia del system_grms della versione 7

In particolare, dall’albero della struttura delle Charts si può osservare che solo le attività system_grms e proc_global_monitor contengono come sub-activities, oltre alla già citata Control-Activity, anche delle Basic-Activities; tutte le altre attività (i timer tfine, i processi proc e l’acceptance) contengono come unica sub-activity la relativa StateChart di controllo. Più precisamente, tutte le nostre attività sono di tipo reactive-controlled e infatti le relative Control-Activities non hanno mai un termination connector; ciò implica che, come visto precedentemente, le Activities dovrebbero essere fermate dalle stesse StateCharts che le hanno precedentemente attivate, ma questo nella nostra specifica non accade, da cui i completeness warnings riscontrati. Questo apparente problema, che del resto non compromette la corretta esecuzione della specifica, è legato alla natura stessa del nostro modello in cui tutti i processi periodici real-time simulati e le attività implementate per gestirli (il global_monitor, l’acceptance e i timer), una volta avviati, non prevedono una definitiva ed esplicita terminazione.

153

Abbiamo così sostituito i connettori terminali con appositi stati senza uscita che, se da una parte implicano i già visti problemi di completezza (in pratica si possono avere attività cosiddette zombie che, anche se risultano sempre attive, in realtà non contribuiscono più all’effettivo comportamento dinamico del sistema), dall’altra permettono una significativa visione persistente dello stato in cui la StateChart stessa si è bloccata nella sua esecuzione (vedi come esempio lo stato killed in Figura 6.4).

Figura 6.4 – Alcuni stati terminali del new_proc

Figura 6.5 – Obiettivo della fase di simulazione

Specifica formale

del modello

Hardware

e/o software eseguibile

Simulazione

errori di progetto nella specifica

validazione

154

6.2 Simulation Tool di Statemate In Statemate è possibile, oltre all’analisi statica appena vista, anche un’analisi dinamica del modello specificato tramite l’apposito strumento di simulazione (Analyzer) che permette un’utile e completamente personalizzabile esecuzione simulata (testuale e/o grafica) del modello stesso; con essa il progettista può controllare e verificare passo-passo il comportamento dinamico del sistema tramite l’animazione grafica delle Charts e la monitorizzazione dei valori delle varie componenti, effettuando la simulazione su diversi test patterns alla ricerca di eventuali errori di progetto nella specifica (debugging). Lo scopo finale della simulazione è infatti quello di testare il pieno soddisfacimento dei requisiti specificati e validare il modello realizzato prima di passare alla fase ultima di implementazione (HW e/o SW): vedi Figura 6.5. Più in particolare, il Simulation Tool di Statemate [12] presenta diverse utili funzionalità, alcune delle quali saranno illustrate dettagliatamente nei paragrafi seguenti: • Sono disponibili due differenti modalità di esecuzione simulata: la modalità

interattiva on-line (da noi utilizzata) che fornisce un completo controllo in tempo reale del sistema durante tutte le fasi della simulazione, e la modalità batch off-line che permette invece una simulazione automatica programmata tramite l’apposito Simulation Control Language (SCL).

• La simulazione può essere globale (avviandola dal menù principale dello Statemate) oppure locale (avviandola all’interno stesso di un Activity-Chart o di una StateChart per simulare l’intera Chart o parte di essa).

• Nel caso di simulazione globale è previsto un apposito file di configurazione (Simulation Profile) in cui è possibile definire il campo di visibilità della sessione corrente di simulazione (Simulation Scope) e settare tutti i parametri di esecuzione, in modo da poter usare tali impostazioni anche in altre sessioni successive.

• E’ possibile memorizzare appositi playback scripts che permettono di automatizzare le esecuzioni del modello ripetendole nel medesimo execution scenario.

• E’ possibile memorizzare appositi trace files che permettono di esaminare a posteriori i risultati della simulazione effettuata.

• Per scopi di debugging sono previste apposite Monitor Windows che permettono di visualizzare in tempo reale ed eventualmente modificare il valore corrente degli elementi del sistema.

• Possono essere impostate apposite Waveforms per avere una comoda rappresentazione grafica dinamica dell’execution history del modello (valori passati e presenti)

• Tramite i Panels completamente personalizzabili è possibile realizzare un’intuitiva e realistica Graphical User Interface (GUI) attraverso la quale modificare gli inputs e monitorare gli outputs del sistema simulato.

• E’ possibile implementare particolari StateCharts aggiuntive denominate Testbenches (o Watchdog) che permettono di monitorare (observers) o guidare (drivers) il comportamento dinamico dell’intero modello durante la sua esecuzione simulata senza essere soggette alle regole di visibilità (resolution scope) delle normali Charts.

155

6.2.1 Le tre fasi della simulazione interattiva D’ora in avanti, se non diversamente indicato, con il termine ‘simulazione’ ci riferiremo sempre alla simulazione interattiva in quanto è la modalità da noi utilizzata costantemente nell’analisi dinamica del modello specificato per la sua semplicità d’uso, la comoda interfaccia grafica e l’espressività di rappresentazione dei risultati. L’esecuzione tipica di una cosiddetta interactive simulation session si compone di tre fasi principali: 1. STARTING: l’Interactive Simulation Tool viene avviato in modalità globale (dal

menù principale dello Statemate) o locale (dall’apposito menù del Graphic Editor all’interno di una StateChart o di un’Activity-Chart).

2. SETUP: in questa fase preliminare si definisce il campo d’azione della simulazione

(Simulation Scope), si specificano gli eventuali files in cui memorizzare gli inputs e gli outputs e si impostano i parametri di esecuzione (vedi il paragrafo successivo).

3. EXECUTING e OBSERVING: in quest’ultimo ma fondamentale passo avviene

l’effettiva esecuzione simulata del modello utilizzando i diversi comandi interattivi disponibili e visualizzando i risultati tramite gli appositi strumenti testuali e grafici.

6.2.2 Profile Editor e Simulation Scope Il Profile Editor (vedi Figura 6.6) è stato introdotto nel Simulation Tool di Statemate con lo specifico scopo di fornire al progettista la possibilità di costruirsi facilmente un ambiente di simulazione robusto ma soprattutto riusabile; esso infatti permette di specificare graficamente (eventualmente memorizzandolo una volta per tutte) il campo di visibilità, ossia le design components (Charts, Monitors, Panels e Waveforms) della simulazione, di definire comodi meccanismi automatici per tenere traccia degli input e degli output e di personalizzare e salvare tutti i parametri utilizzati durante la sessione di simulazione, in definitiva cioè di avere un unico framework di riferimento sia per la simulazione interattiva che per quella batch. In particolare, il Profile Editor permette di salvare più analysis profile files direttamente nel Project Databank per poterli così modificare e utilizzare successivamente anche in sessioni diverse di simulazione del modello. La fase preliminare e fondamentale di questo meccanismo consiste nel connettere alcune o tutte le componenti (eventualmente con i relativi discendenti) del nostro modello presenti nel Workarea Browser (vedi Figura 6.3) o definite appositamente per l’esecuzione simulata (come Monitors, Waveforms o Panels) nello Scope Definition (visualizzabile in modalità testuale o grafica) del Simulation Profile corrente (vedi ancora Figura 6.6). In questo modo è possibile personalizzare facilmente ogni sessione di simulazione, includendo di volta in volta solo gli elementi di interesse; un risultato simile è ottenuto, con qualche limitazione, avviando la simulazione direttamente all’interno della Chart d’interesse (simulazione locale) anziché dal Profile Editor (simulazione globale).

156

Figura 6.6 – Simulation Profile Editor Window

157

6.2.2.1 Opzioni di esecuzione Come abbiamo già accennato nella sezione precedente, prima di iniziare la simulazione vera e propria del modello, è possibile settare opportunamente alcuni parametri (magari memorizzandone le impostazioni nell’apposito Simulation Profile file), tra i quali le modalità di esecuzione: lo stile di attivazione (behavior pattern) delle Activity-Charts nell’apposita finestra Execution Parameters (vedi Figura 6.7), che può essere software (default) o hardware, e lo schema temporale (time model) di esecuzione del modello nella relativa finestra Time Settings (vedi Figura 6.8), che invece può essere asincrono (default) oppure sincrono.

Figura 6.7 – Execution Parameters Window

158

Figura 6.8 – Time Settings Window

Per quanto riguarda l’activaton style delle attività, quello hardware caratterizza le cosiddette perpetual activities il cui comportamento è infatti caratteristico della specifica di sistemi hardware: questo tipo di attività sono sempre attive e non necessitano di una Control-Activity per partire o fermarsi; se non sono basic-activities, tutte le sub-activities partono e si fermano in concomitanza con la loro parent-activity appartenente al livello immediatamente superiore nella gerarchia delle Charts. Al contrario, lo stile di attivazione software (adottato tra l’altro nella simulazione del nostro modello) è basato su un approccio più tipicamente software, in cui un’attività viene esplicitamente (ri)attivata (started o resumed), fermata (stopped) o eventualmente sospesa (suspended) dalla rispettiva Control-Activity appartenente allo stesso livello nella gerarchia delle Charts.

159

6.2.3 Temporizzazione nella simulazione Collegata in qualche modo allo stile di attivazione delle Activities, vi è la cruciale scelta dello schema temporale più adatto all’esecuzione simulata del modello specificato. Bisogna infatti premettere che nei sistemi reattivi e real-time, differentemente da quelli puramente trasformazionali, il concetto di sequenzialità e di concorrenza e tutte le problematiche legate alla loro interrelazione con il tempo assumono un importanza fondamentale, soprattutto in fase di simulazione. Abbiamo già visto precedentemente nel paragrafo 2.5 del capitolo 4 come lo scenario di esecuzione di un modello consiste in una determinata sequenza discreta di passi tra gli stati le cui transizioni e reazioni sono innescate o abilitate dai relativi triggers (input esterni o cambiamenti interni relativi al passo precedente) e dal progredire del tempo (scheduled actions e timeout events). A questo punto sorgono due delicate questioni: • Gli stimoli esterni possono interferire in qualche modo con le reazioni a catena

interne oppure diventano rilevanti solo dopo il completamento di tutti i cambiamenti interni?

• Fino a quando i cambiamenti esterni si accumulano per guidare l’esecuzione del

passo corrente? Questi due quesiti riguardano tra l’altro tutti i tipi di sistemi reattivi, in quanto inerenti esclusivamente l’ordine di esecuzione delle operazioni e non la natura quantitativa del tempo trascorso. D’altra parte, tutte le problematiche riguardanti la gestione esplicita e quantitativa del tempo non possono essere ignorate quando il modello specificato prevede timeout events e/o scheduled actions che dipendono necessariamente da un clock corrente di sistema, reale o simulato che sia. In tal caso, sorge spontanea un’altra fondamentale domanda: • Cosa e in che modo è responsabile del progredire del tempo durante l’esecuzione

simulata del modello? Innazittutto bisogna precisare che il tempo presente in tutte le espressioni temporali utilizzate nella specifica del modello viene sempre misurato, in fase di esecuzione simulata, in unità di tempo astratte comuni all’intera StateChart e, se non diversamente specificato (vedi la voce local clocks in Figura 6.8), all’intero modello (vedi la voce global clock in Figura 6.8). Quando poi l’esecuzione del modello (prototipo) avverrà in un ambiente reale o in un contesto ancora simulato dove però diventano significative unità concrete di tempo, come secondi o millisecondi, allora il progettista o l’utente dovrà stabilire a priori, una volta per tutte, la relazione formale esistente tra il tempo simulato del modello e il tempo reale. A tal proposito, è interessante citare un passo tratto dalla tesi di Sauro Carsughi [2] riguardante i timer SDL:

160

“A conclusione di questa parte, si precisa che nessuna unità di tempo, ad esempio il millisecondo, è specificata per i sort Time e Duration. L’utilizzo di una determinata unità di tempo dipende dal contesto dell’applicazione, e quindi non è definita formalmente. L’unità di tempo verrà scelta dallo specificatore al momento della simulazione, ma è buona regola indicarla in un modo informale, ad esempio con un commento, nella specificazione del sistema. In genere si tende ad utilizzare il secondo piuttosto che le sue frazioni, in quanto permette ‘all’occhio umano’ di analizzare meglio il funzionamento e l’evoluzione del sistema, e quindi la correttezza delle specifiche.”

Dal precedente discorso si evince che, almeno in una prima fase di specifica informale, l’approccio alla trattazione del tempo in Statemate è molto simile a quello presente in SDL. La differenza principale invece risiede nel fatto che in una simulazione SDL il tempo di sistema, una volta partito, è reale, assoluto (vedi la funzione predefinita now) e non può essere in alcun modo accelerato o fatto tornare indietro durante l’esecuzione (seppur simulata) del modello; inoltre tutte le operazioni da eseguire durante una transizione di stato o l’esecuzione di una procedura sono sì sequenziali, ma consumano a loro volta una seppur piccola quantità di tempo (il cosiddetto overhead di sistema, fortemente dipendente dalla capacità di calcolo della CPU) che quando diventa confrontabile con il tempo delle computazioni simulate non può essere più trascurata se si desidera una simulazione ancora fedele. Al contrario, in Statemate il tempo utilizzato nella simulazione interattiva è proprio un tempo simulato, indipendente dalla macchina fisica e fittizio, che come tale può essere, tra le altre cose, accelerato, fermato (con il comando pause) e addirittura riportato indietro (per il numero di passi specificato nella voce Goback Limit: vedi Figura 6.7), in pratica controllato passo-passo dall’utente stesso; inoltre, se da una parte la dinamica dello step nelle StateCharts Statemate pone potenziali problemi di non-determinismo e di racing (vedi ancora il paragrafo 2.5 del capitolo 4), dall’altra, come vedremo tra poco, si ha in compenso l’indubbio vantaggio rispetto alla simulazione SDL di poter considerare sempre un tempo nullo per l’esecuzione di un passo indipendentemente dal tipo e dalla complessità computazionale delle istruzioni e dalla potenza di calcolo della CPU utilizzata. Questa sostanziale differenza nella dinamica della simulazione pone un’altra interessante questione: per i nostri scopi di specifica formale di un sistema real-time è più adatta la simulazione ‘reale’ ma per così dire intrinsecamente limitata presente in Cinderella SDL oppure quella più flessibile ma in un certo senso ‘artificiale’ offerta da Statemate? Bisogna comunque osservare che, almeno ad un primo sguardo, i due diversi approcci, nei limiti delle citate differenze implicite e rappresentative, portano – per gli stessi test patterns d’esempio – a risultati sperimentali molto simili tra loro considerando anche il fatto che l’implementazione del modello, semplificazioni a parte, non è e non può essere perfettamente uguale e soprattutto che diversa è la ‘misura’ dell’overhead presente nella simulazione dei due tool. Mentre infatti in SDL l’overhead intrinseco di sistema (dovuto al context switching, al meccanismo dei timer e all’interpretazione stessa dei costrutti SDL in fase di simulazione) è sempre quantificabile in unità temporali effettive (anche se non è possibile raffrontare con precisione il tempo di simulazione con quello reale) che per quanto piccole non sono mai nulle, in Statemate l’overhead risultante dall’esecuzione simulata dei task real-time (e più in particolare il cambio o commutazione di contesto) è misurabile solo in termini di passi che, in tutte le prove da

161

noi effettuate e indipendentemente dal loro numero (mai inferiore comunque alle 2 unità), risultano sempre svolti in tempo simulato nullo. Come semplice verifica sperimentale di ciò si può osservare ad esempio che, sebbene il fattore di utilizzazione U massimo ottenuto in analoghe simulazioni del modello sia sempre lo stesso nei due linguaggi, mentre in Statemate - modificando l’opportuno parametro di soglia MAX_U nello schedulability_test - si possono ottenere (come nell’esempio di simulazione riportato nel paragrafo 6.2.6.2) valori di picco per U anche maggiori di 0.98 (ma ovviamente minori del limite ideale massimo teorico del 100%) – valori che del resto non sono probabilmente riscontrabili in nessun sistema operativo reale correttamente funzionante – in una simulazione SDL, più aderente alla realtà, ciò potrebbe non essere possibile proprio a causa della presenza degli effettivi tempi (non passi) di overhead. Tutti i confronti precedenti sono però validi solo nel caso di stile di attivazione software con schema di tempo asincrono (nel modello SDL la comunicazione è esclusivamente asincrona).

6.2.3.1 Schema di tempo sincrono vs asincrono Riprendendo il discorso precedente e per rispondere ai quesiti posti sulla temporizzazione in fase di esecuzione simulata – in particolare a quello relativo alla relazione tra il progredire della simulazione (in steps o supersteps) e l’avanzamento del tempo (in unità) – in Statemate vengono dunque proposti due modelli di tempo in un certo senso complementari: lo schema sincrono e quello asincrono (da noi adottato). Questi due schemi sono strettamente separati sia dal punto di vista teorico (nella semantica delle StateCharts) che da quello pratico (nel Simulation Tool), e non possono essere in alcun modo alternati in una medesima sessione di simulazione (vedi Figura 6.8). Bisogna comunque precisare che in entrambi gli schemi vale l’assunzione che il tempo (simulato) non avanza mai durante l’esecuzione di un passo quindi è come se tutte le static reactions interne agli stati e le transizioni di stato relative ad uno step avvenissero istantaneamente, cioè sempre in tempo zero. Il significato intrinseco di questa assunzione risiede nel fatto che durante uno step non possono aver luogo cambiamenti esterni e che tutte le informazioni temporali necessarie per gestire i timeout events e le scheduled actions in un passo sono ottenute usando un opportuno clock di sistema comune. • Nel modello temporale sincrono gli steps e il tempo sono direttamente collegati tra

loro (step-dependent), nel senso che il sistema esegue un passo di simulazione ogni unità di tempo (clock unit) ovvero il tempo avanza di un’unità ogni simulation step (corrispondenza biunivoca) indipendentemente dagli input esterni. Questo schema è particolarmente adatto alla modellazione di sistemi elettronici digitali (stile di attivazione hardware), nei quali l’esecuzione è sincronizzata su opportuni segnali periodici di clock e i cambiamenti esterni possono avvenire tra due qualsiasi step, ma mai durante un singolo passo. L’esecuzione del modello avviene in cicli, in ciascuno dei quali il tempo viene incrementato di un’unità di tempo, tutti i cambiamenti esterni avvenuti a partire dall’ultimo passo diventano rilevanti e viene eseguito il passo corrente. Nel caso in cui sono stati specificati clocks differenti per le diverse componenti del modello (vedi la voce Local Clocks in Figura 6.8), il tempo è incrementato in base al successivo più piccolo valore di clock, e solo le componenti relative eseguono uno step.

162

• Nel modello temporale asincrono invece non esiste una relazione costante e diretta tra un simulation step e una clock unit (step-independent): diversi passi possono essere eseguiti nel medesimo istante senza implicare un corrispondente avanzamento del tempo e viceversa il tempo può progredire senza che venga eseguito nessun passo. Per questo motivo nel Simulation Tool i passi e il tempo assumono un significato ben distinto nell’esecuzione simulata del modello che così risulta più flessibile e più adatta alla modellazione di sistemi real-time ad attivazione software (come nel nostro caso). Per quanto riguarda poi la temporizzazione dei cambiamenti esterni, in generale essi possono avvenire anche contemporaneamente in un qualsiasi istante tra gli steps; in particolare, secondo l’execution pattern predefinito, il sistema risponde agli input esterni rilevanti eseguendo l’intera sequenza di passi (phases) innescata da tali cambiamenti in una reazione a catena che termina esclusivamente al raggiungimento di uno stato stabile (stationary status). Solo allora il clock di sistema viene incrementato nelle espressioni temporali inerenti tutti i timeout events e le scheduled actions e il sistema diventa nuovamente pronto a reagire ad eventuali ulteriori cambiamenti esterni. Questa serie di passi attivati dai trigger esterni e proseguenti fino al successivo stato stabile, è denominata superstep: secondo questo approccio la simulazione evolve in superstep anziché in step, ma parimenti il tempo non scorre durante un superstep ma solo tra un superstep e l’altro. Dal momento però che adottando questo schema temporale, come abbiamo appena visto, più di un passo alla volta può essere eseguito in uno stesso istante di tempo, potrebbe verificarsi la situazione indesiderata in cui il sistema è in condizione di eseguire un numero illimitato di reazioni senza implicare nessun incremento temporale: è questo il caso del ciclo infinito (infinite loop) illustrato schematicamente in Figura 6.9. In particolare, se il sistema si trova nello stato S1 e viene generato l’evento E oppure equivalentemente se il sistema è nello stato S2 ed è generato l’evento F, il modello simulato si alterna infinitamente tra i due stati S1 e S2. Per evitare questi inconvenienti è previsto tra gli execution parameters (vedi la voce Steps per Go in Figura 6.7) un apposito valore (phase limit) che limita il numero massimo di steps relativi al Go Command che possono aver luogo senza un conseguente avanzamento del tempo: tale limite vale comunque per tutti i supersteps, anche per quelli che non comportano un ciclo infinito.

Figura 6.9 – Esempio di infinite loop

S1 S2

F/E

E/F

163

6.2.4 Go Commands I Go Commands sono tutti quei comandi di simulazione utilizzati per controllare in modo diretto l’esecuzione in steps del modello. La Tabella 6.1 contiene una lista di tali comandi con una breve descrizione valida però solo nel caso di esecuzione di tipo asincrono (che è poi la modalità di nostro interesse). GoStep Esegue un passo senza incrementare il tempo GoStepN Esegue il numero di passi specificato in N GoRepeat Esegue un superstep senza incrementare il tempo GoNext Incrementa il tempo fino alla successiva scheduled actions o timeout

event, poi esegue un GoRepeat GoExtend Esegue un GoRepeat; se non può essere effettuato un superstep, allora

esegue prima un GoNext e poi un GoRepeat GoAdvance Incrementa il tempo in base al valore specificato dall’utente e poi esegue

un GoRepeat AutoGo Se il sistema è in uno stato instabile esegue un GoStep, altrimenti esegue

un GoNext GoBack Annulla gli effetti dell’ultimo Go Command eseguito Pause Sospende a tutti gli effetti (il tempo si ferma) la simulazione in

esecuzione Tabella 6.1 – Go Commands

In generale un Go Command può essere eseguito – richiamandolo dall’apposito Go Menù testuale, dalla comoda Toolbar grafica del simulatore (vedi Figura 6.10) o eventualmente tramite le opportune combinazioni di tasti – ogni qualvolta la simulazione è in attesa di un input (stable o stationary status), tranne però i casi in cui: • La simulazione è in modalità Autorun (vedi più avanti) o batch. • La simulazione si trova in una situazione irrisolta (voluta o imprevista) di non-

determinismo; in questo caso il progettista deve scegliere una tra le soluzioni possibili proposte dal sistema tramite l’apposita finestra di dialogo per consentire il proseguimento dell’esecuzione.

• Il sistema è arrivato in un connettore terminale; in questo caso gli unici comandi possibili sono quit (per uscire definitivamente dal Simulation Tool), restart (per far ripartire la simulazione dall’inizio) e rebuild (restart in caso di cambiamenti apportati alla specifica del modello durante la simulazione).

Bisogna osservare che i comandi GoRepeat, GoExtend, GoNext e GoAdvance (vedi Tabella 6.1) potrebbero portare, in linea teorica, una simulazione di tipo asincrono in un infinite loop (vedi Figura 6.9) ma, come abbiamo già visto, in questi casi l’esecuzione in realtà esegue il numero di passi specificato dall’apposito valore limite Steps per Go (vedi Figura 6.7); quando tale limite è raggiunto viene visualizzato nell’apposita finestra del simulatore il seguente messaggio di avvertimento: Reached MAX NUMBER OF STEPS PER GO limit (see parameter under OPTIONS).

164

Figura 6.10 – Interfaccia utente del simulatore

Possiamo notare che nella Tabella 6.1 manca un ultimo ma fondamentale Go Command: l’AutoRun; questo perché tale comando richiede una spiegazione a parte. In modalità AutoRun (rappresentata da un ‘omino che corre’ in Figura 6.10) la simulazione viene eseguita in modo automatico e l’unica eventuale interazione possibile con l’utente avviene tramite appositi Panels o Monitors; essa in pratica si comporta come se fosse una vera e propria esecuzione in tempo reale del modello che si rivela particolarmente utile quando vogliamo effettuare una simulazione dimostrativa e continuativa del nostro modello definitivo. Tale comportamento ‘real-time’ è ottenuto adottando i seguenti accorgimenti: • Ogni volta che il simulation clock avanza di T unità di tempo, l’esecuzione simulata

subisce un corrispondente ritardo real-time di durata proporzionale a T. • Se non specificato diversamente nell’apposito campo Autorun Time Factor dei Time

Settings (vedi Figura 6.8), un’unità di ritardo real-time corrisponde ad un’unità temporale di simulazione (nel nostro caso 1 millisecondo).

In particolare, in uno schema di esecuzione temporale asincrono, nel caso di presenza di input esterni, l’AutoRun esegue un GoRepeat e il tempo non avanza; in caso di stazionarietà invece, l’AutoRun incrementa continuativamente il simulation clock di un’unità di tempo, a meno che la distanza dalla successiva azione schedulata (o timeout event) non sia minore di un’unità temporale: in tal caso il simulation clock viene fatto avanzare fino a questo istante di schedulazione anziché di un’unità di tempo. La modalità AutoRun può essere interrotta in ogni momento usando l’apposito comando Pause; bisogna però osservare che se l’esecuzione simulata viene fatta ripartire con altri Go Commands (come GoAdvance o GoNext), il simulation clock avanza senza comportare però più nessun corrispondente real-time delay.

165

6.2.5 Analisi dell’esecuzione simulata Quando, in seguito ad un Go Command, viene effettuato un passo di simulazione, la configurazione di stato e il valore delle variabili del sistema possono subire dei cambiamenti. In questa sezione vedremo i vari strumenti messi a disposizione dal Simulation Tool di Statemate per visualizzare l’output della simulazione corrente (come il nuovo stato di una StateChart o i cambiamenti dei data-item avvenuti nell’ultimo step) in modalità grafica (tramite la Chart Animation) e/o testuale (tramite gli Show Commands).

6.2.5.1 Graphic Animation Display Durante l’esecuzione del sistema è possibile collegare la simulazione al Graphic Editor (GE) del modello selezionando le Charts (Activity-Charts o StateCharts) di interesse dall’apposito menù Display del simulatore (vedi Figura 6.10) o aprendole direttamente dal Workarea Browser (vedi Figura 6.3) nel caso si voglia anche modificarle durante la simulazione stessa. Compatibilmente con la dimensione di ciascuna finestra aperta e con la risoluzione dello schermo (almeno 1024x768 a 16 bit di colore) è possibile così monitorare in tempo reale la dinamica delle configurazioni e delle transizioni di stato di più StateCharts e lo stato di attivazione di più Activity-Charts; tutti i cambiamenti sono rappresentati graficamente tramite l’utilizzo di apposite colorazioni (purtroppo non visibili chiaramente nella Figura 6.11 in bianco e nero), eventualmente personalizzabili dall’utente.

Figura 6.11 – Esempio di Animated Chart

166

6.2.5.2 Show Commands Sempre durante l’esecuzione simulata del modello è possibile visualizzare varie informazioni testuali sui cambiamenti nelle componenti grafiche e non grafiche del sistema selezionando l’opportuna voce (Changes, Future, Racing, Clock o Examine) dalla finestra Show (vedi Figura 6.12) richiamata dal menù Analyze (vedi Figura 6.10). • Changes Questa opzione permette di visualizzare tutti i cambiamenti di stato e delle variabili avvenuti nel sistema dall’ultimo passo di simulazione (vedi Figura 6.12), compresi i cambiamenti manuali effettuati durante l’ultimo Go Command. Prevede due modalità alternative di visualizzazione: nell’Automatic Update (da noi utilizzata) tutti i cambiamenti rilevanti sono automaticamente aggiornati in tempo reale ad ogni step mentre in quella Freeze (default) le informazioni correnti vengono mantenute senza subire cambiamenti fino alla successiva riattivazione dell’opzione Changes da parte dell’utente.

Figura 6.12 – Show Changes Window

• Future Questa opzione permette di visualizzare tutte le scheduled actions e i timeout events programmati che devono ancora scadere (vedi Figura 6.13). In particolare, sono previsti tre campi informativi: Time, indicante le unità di tempo globale che mancano allo scadere del timer (se tale valore è 0, la scadenza avverrà immediatamente prima del successivo passo); Type, indicante il tipo di timer (evento, azione) e Name/Definition, indicante il nome o un’espressione che descrive univocamente il timer in questione. Inoltre sono presenti le due modalità esclusive di visualizzazione (Automatic Update e Freeze) già viste nell’opzione Changes.

167

Figura 6.13 – Show Future Window

• Racing Questa opzione, se è stata preventivamente settata l’apposita voce nella relativa finestra di dialogo richiamata dal menù Options del simulatore, permette di visualizzare in dettaglio (vedi Figura 6.14) eventuali problemi di racing (vedi sezione relativa) riscontrati durante l’esecuzione simulata del modello, siano essi di tipo read/write o di tipo write/write (il tipo di interesse può essere impostato nell’apposita finestra Execution Parameters: vedi Figura 6.7). La presenza di racing warnings viene inoltre prontamente segnalata dal messaggio “Racing problem encountered” nella finestra del simulatore (vedi Figura 6.10). Infine sono presenti le solite due modalità di visualizzazione: Automatic Update e Freeze.

Figura 6.14 – Show Racing Window

168

• Clock Questa opzione permette di visualizzare informazioni sul Global Clock di sistema e sugli eventuali Local Clocks di componenti del modello (vedi Figura 6.15). In particolare, per il Global Clock sono mostrati il tempo corrente (current time) in unità scelte (nel nostro caso millisecondi) o in generale nel formato standard (HH:MM:SS), il numero totale di passi (step number) effettuati dall’inizio della simulazione, il numero di steps (phase number) eseguiti nell’istante di tempo corrente e l’unità temporale (clock unit) specificata nel finestra di dialogo dei Time Settings (vedi Figura 6.8). Per ciascuna componente di sistema invece sono specificati l’unità di tempo locale (local clock unit) – solo però nel caso di schema temporale sincrono – e l’unità dei timer (timeout/schedule unit), utilizzata per misurare la durata delle azioni schedulate e degli eventi temporizzati in entrambi gli schemi di tempo. Infine sono presenti le solite due modalità di visualizzazione: Automatic Update e Freeze.

Figura 6.15 – Show Clock Window

• Examine Il comando Examine (selezionabile dal menù Analyze del simulatore) permette di analizzare durante la simulazione il valore attuale di elementi (semplici o strutturati), di espressioni e di code (vedi Figura 6.16) ed è quindi molto utile in fase di testing e di debugging del modello. In particolare, la voce Examine permette di visualizzare il valore corrente di un elemento, la voce Evaluate il valore corrente di un’espressione e la voce Examine Queue il contenuto e la lunghezza di una coda. Inoltre nel campo History vengono memorizzati tutti gli oggetti esaminati precedentemente, nel campo Expression

169

viene visualizzato il nome della componente attualmente esaminata e nel campo Results sono mostrati i valori aggiornati richiesti (nel nostro caso sono visualizzati i primi tre elementi del vettore di record OPT). Infine il bottone con i 3 puntini sospensivi serve a richiamare il Select Element Browser per selezionare le variabili d’interesse.

Figura 6.16 – Examine Window

170

6.2.5.3 Panels I cosiddetti ‘pannelli finti’ (mock-up panels) disponibili nel Simulation Tool di Statemate forniscono un’intuitiva interfaccia grafica utente (GUI) di simulazione facilmente e completamente personalizzabile che permette un comodo controllo esterno del comportamento dinamico del sistema durante la sua esecuzione simulata. I Panels sono composti da input ed output interactors (vedi Figura 6.17) ed eventualmente dalle più disparate forme grafiche colorate costruite dal progettista-utente sempre tramite l’apposito Panel Graphic Editor (modulo PGE).

Figura 6.17 – Esempio di Panel GUI

Ciascuno di questi oggetti grafici, un po’ come avviene nei linguaggi di programmazione visuali (ad es. Microsoft Visual Basic), può essere collegato ad un determinato elemento (testuale o grafico) del modello specificato (ad es. un evento, una condizione, un data-item, uno stato, un’attività etc.). Questi bindings permettono poi di guidare direttamente l’esecuzione simulata del sistema inserendo opportuni valori di input tramite gli IN interactors e osservandone i risultati in tempo reale durante la simulazione tramite gli OUT interactors. In una stessa sessione di simulazione si possono usare più pannelli, definiti magari in base ad un raggruppamento logico di elementi correlati del modello, siano essi interni o esterni. Inoltre è possibile, se si dispone del software e dell’hardware adeguato, visualizzare i pannelli su terminali differenti oppure visualizzare uno stesso pannello

171

contemporaneamente su terminali diversi; ciò offre un effetto altamente realistico e permette di controllare anche un sistema complesso costituito da molte componenti. Naturalmente i pannelli possono sempre essere integrati dagli altri meccanismi di IN/OUT della simulazione, come Monitors, Animated Charts, Show Commands e Simulation Control Language (SCL) Programs, fornendo così un completo controllo dello stato del sistema in ogni istante di simulazione. In definitiva con i pannelli è possibile creare rapidamente un’interfaccia uomo-macchina per scopi di testing e debugging ed eventualmente per automatizzare l’ambiente di simulazione. I Panels, come tutte le altre facilities del Simulation Tool (Monitors e WaveForms), una volta definiti e salvati nel Workarea Browser del progetto, possono essere richiamati e modificati successivamente ma soprattutto possono essere aggiunti o rimossi, sempre tramite il Profile Editor, nello Scope Definition della sessione corrente di simulazione (vedi Figura 6.6).

6.2.5.4 Micro-Debugger Tool Il Simulation Tool di Statemate, oltre a permettere tramite gli strumenti grafici e testuali sopra visti il debugging runtime delle Charts che rappresentano la specifica formale del modello, forniscono una ulteriore facility per testare in fase di esecuzione simulata le eventuali procedure testuali e grafiche presenti nella specifica: il cosiddetto Micro-Debugger Tool. Come abbiamo visto nel paragrafo 2.5.2 del capitolo 4, la semantica di esecuzione del modello in steps prevede un’esecuzione atomica in tempo nullo di una qualsiasi procedura (sia testuale che grafica) chiamata durante l’esecuzione del modello stesso; quando una subroutine è invocata, esegue dall’inizio alla fine tutte le operazioni previste in un solo passo (tempo zero) rispettando rigorosamente l’ordine prescritto, e solo quando ritorna l’esecuzione del sistema può continuare secondo il suo normale flusso. Parimenti, nel caso di procedure annidate quella chiamante non avanza fino a quando la procedura chiamata non le ritorna il controllo. Alla luce delle considerazioni sopra esposte gli strumenti standard di debugging del Simulation Tool, basandosi sui (super)steps, risultano inadatti all’analisi e al testing delle subroutines, la cui dinamica invece si basa sui cosiddetti micro-steps, da cui il termine micro-debugger. In particolare, per richiamare il Micro-Debugger Tool è necessario definire preventivamente (all’inizio o anche durante la simulazione, ma comunque prima della chiamata alla subroutine d’interesse) i relativi breakpoints per le tutte le eventuali procedure da analizzare: tale impostazione viene effettuata dall’apposita finestra di dialogo (Simulation Breakpoint Editor) richiamabile dalla voce Actions del Simulation Execution Menù (vedi Figura 6.10) e può essere, come al solito, salvata nel Simulation Environment della sessione corrente per un futuro riutilizzo. In tal modo, ogni volta che la simulazione incontra un breakpoint attivo, il flusso normale di esecuzione in steps si arresta temporaneamente e viene avviato automaticamente il Micro-Debugger Tool per la subroutine in questione. A questo punto lo strumento prevede un’apposita finestra di controllo (vedi Figura 6.19) tramite la quale è possibile tra l’altro selezionare, modificare e monitorare in tempo reale le variabili d’interesse, visualizzare lo stack per procedure annidate, controllare manualmente l’esecuzione in micro-steps della subroutine e visualizzare gli eventuali messaggi d’errore:

172

• mStep: esegue un singolo micro-step della procedura • mStepN: esegue N micro-steps alla volta • Continue: continua l’esecuzione della subroutine fino al successivo breakpoint

oppure fino alla fine del contesto corrente • Run-To-End: esegue fino alla fine della procedura corrente • Stack: mostra i livelli di annidamento delle procedure attive in formato tabulare • Data Monitor Display: visualizza in tempo reale durante l’esecuzione simulata

della subroutine il nome, il tipo, il valore e lo scope (L = Locals; P = Parameters; G = Globals) delle variabili precedentemente selezionate dall’apposita finestra di dialogo (vedi Figura 6.18) richiamabile dal pulsante Add

• Command Line: permette l’inserimento diretto da parte dell’utente di opportuni

comandi per esaminare gli elementi; i risultati ottenuti sono mostrati nell’apposita area Results (vedi Figura 6.19).

Figura 6.18 – Select Element Window

173

Figura 6.19 – Micro-Debugger Tool Window

Quindi, una volta selezionati gli elementi d’interesse da monitorare, la subroutine invocata può essere simulata passo-passo e debuggata a run-time, proprio come una normale StateChart, ma l’esecuzione in questo caso avviene in micro-steps, anziché in passi; una volta completate (correttamente) tutte le procedure nello stack, il Micro-Debugger Tool viene chiuso automaticamente e la simulazione continua normalmente in steps. In particolare, nel caso di textual procedures, il codice sorgente è visualizzabile direttamente nel Micro-Debugger Tool (nella Code Window viene evidenziata la linea corrente in esecuzione), mentre per le graphical procedures (come nel nostro caso) un’apposita finestra del Graphic Editor in modalità read-only (vedi Figura 6.20) permette di seguire visivamente in tempo reale l’esecuzione dei micro-steps della subroutine. Bisogna comunque precisare che procedure testuali richiamate da procedure a loro volta testuali e implementate in codice C o Ada non possono essere né simulate né debuggate. Per quanto riguarda invece le procedure grafiche, una volta attivate, esse devono necessariamente eseguire fino al loro (corretto) completamento (termination connector); se una subroutine raggiunge uno stato stabile (ossia nessun altro micro-steps può essere eseguito sulla base dei valori correnti delle variabili locali, globali o dei parametri), la procedura in questione ritorna immediatamente restituendo i valori correnti di tutte le sue variabili globali e parametriche, è quindi generato un apposito messaggio di run-time error e la simulazione viene di conseguenza interrotta fino a nuovo ordine.

174

Figura 6.20 – Graphical Procedure Debugging

Infine, per entrambi i tipi di subroutine (testuale e grafica), vale il discorso che più procedure invocate nella stessa compound action sono debuggate sequenzialmente ma, secondo la tipica semantica dello Statemate, sono trattate come concorrenti con conseguenti eventuali problemi di racing nel caso di variabili condivise (i parametri IN e IN/OUT sono tutti assegnati immediatamente all’inizio del passo, mentre quelli IN/OUT e OUT sono aggiornati solo alla fine del passo); per risolvere questi conflitti è comunque possibile creare una determinata sequenzialità nell’esecuzione delle subroutine concorrenti passando come parametri opportune variabili contestuali.

175

6.2.5.5 Waveforms Un altro potente e comodo strumento grafico messo a disposizione dal simulatore di Statemate sono le cosiddette Waveforms che si rivelano particolarmente utili quando vogliamo effettuare – magari tramite il comando AutoRun – una simulazione dimostrativa e continuativa del nostro modello definitivo e già debuggato. Le Waveform sono in pratica delle finestre personalizzabili che permettono in fase di simulazione la continua monitorizzazione in tempo reale di variabili (data-items, condizioni, eventi, etc.) o elementi grafici (stati, attività, etc.) del modello specificato tramite un’adeguata rappresentazione dei relativi segnali come ‘forme d’onda’ (vedi Figura 6.23). Esse prevedono due modalità di esecuzione: l’on-line mode (da noi utilizzata) che permette all’utente di interagire direttamente con lo strumento durante la simulazione e allo strumento stesso di comunicare continuamente con il sistema simulato per poter visualizzare il valore aggiornato in tempo reale delle componenti d’interesse, e l’off-line mode, utilizzato invece per un’analisi a posteriori dei risultati tramite la post-elaborazione di opportuni trace files generati durante la simulazione stessa. Come abbiamo già visto per i Panels, le varie impostazioni di una Waveform Window possono essere personalizzate e memorizzate in un apposito Profile durante o dopo la simulazione stessa; tale profilo, identificato dal nome dato alla Waveform associata, può essere così modificato e riutilizzato in sessioni successive di simulazione collegandolo allo Scope Definition della sessione corrente di simulazione tramite il Profile Editor (vedi Figura 6.6). Una Waveform comunque può anche essere creata e attivata durante la fase di simulazione tramite l’apposita voce del menù Display del simulatore. Il Waveform Tool all’attivazione prevede inoltre un controllo a priori sulla correttezza degli elementi specificati nel profilo corrente, in seguito al quale vengono mostrati tutti gli errori riscontrati, che possono essere di vari tipi: un elemento nello scope non univoco o non più esistente, tipi incoerenti, un indice di un elemento che non rispetta i limiti del vettore di appartenenza, etc. Tutti gli elementi errati sono ignorati e perciò non vengono visualizzati nella Waveform in questione. In particolare, un data-item specificato nel profilo ma non (ancora) definito nella specifica del modello, è trattato dal Waveform Tool come intero e un apposito messaggio segnala questa situazione; se però tale elemento è utilizzato nello scope in un modo differente (ad esempio, come stringa) allora il tool segnala l’errore solo a run-time. Una volta attivata, la Waveform mostra il tipo, il nome e il valore corrente (nel formato grafico e/o testuale più appropriato per quel tipo) di tutti gli elementi selezionati (precedentemente o a run-time) incrementando, in base ai Go Commands effettuati, una scala del tempo trascorso e del numero di steps eseguiti; è così possibile tenere traccia, una volta fermata o terminata la simulazione, dell’intera storia dei cambiamenti rilevanti avvenuti nel sistema fino all’istante/passo attuale, e questo meccanismo si è rilevato molto utile nell’analisi dei vari esempi di simulazione interattiva (vedi paragrafo 6.2.6).

176

6.2.5.6 Monitors Un’ultima facility testuale disponibile nel Simulation Tool di Statemate è data dalle cosiddette Monitor Windows, molto simili alle Debug Windows presenti negli ambienti grafici di sviluppo di diversi linguaggi tradizionali (come il Borland C++). I Monitor infatti rappresentano principalmente un comodo strumento di debugging utilizzabile durante l’esecuzione simulata del modello, fornendo all’utente lo stato e il valore di elementi grafici e/o testuali in una essenziale visione tabulare (vedi Figura 6.22). Oltre all’output del sistema, un Monitor può anche essere utilizzato come input device permettendo, durante la simulazione, la modifica delle variabili selezionate tramite l’apposito Element Selection Browser (vedi Figura 6.21).

Figura 6.21 – Monitor Element Selection

177

Inoltre, come tutti i tools di Statemate, anche la tabella di un Monitor è facilmente personalizzabile: una volta inseriti gli elementi d’interesse, è possibile in ogni momento aggiungerne nuovi o rimuovere e cambiare la posizione di quelli già presenti (utilizzando gli appositi comandi); gli elementi poi possono anche essere ordinati in base al nome, al tipo o alla rilevanza per il successivo passo; è possibile infine visualizzare il nome completo di un elemento ed eventualmente cambiare il tipo di formattazione (Value Format o base di numerazione) utilizzato per rappresentare un data-item di tipo integer o bit-array. Come al solito, le varie impostazioni di un Monitor possono poi essere salvate, richiamate e modificate successivamente e il Monitor stesso, una volta presente nel Project Workarea, può essere inserito o rimosso dal Simulation Scope del profilo della sessione di simulazione corrente o di altre sessioni (re-usability). Per concludere analizziamo brevemente i campi presenti in un Monitor: • Name: questo campo contiene il nome dell’elemento. • Type: questo campo indica il tipo dell’elemento (DI = data-item; CO = condition;

EV = event; ST = state; AC = activity). • Value: in questo campo viene visualizzato il valore corrente dell’elemento. L’utente

può applicare ‘stimoli’ esterni al sistema modificando opportunamente questo valore. Nel caso di variabili ‘numeriche’, basta inserire il nuovo valore del tipo appropriato (in caso di errore di immissione il valore rimane inalterato ed è visualizzato un apposito messaggio); nel caso di elementi di tipo stringa il testo deve essere inserito tra due apici, mentre la generazione di un evento o il cambiamento di una condizione avviene cliccando con il mouse nel relativo Value field.

• Status: in questo campo compare lo stato corrente di un elemento. Nel caso di

elementi testuali, i valori possibili sono rd (read), wr (written) o ch (changed); nel caso di stati, i valori possibili sono en (entered) o ex (exited); infine, nel caso di attività i valori possibili sono st (started) o sp (stopped).

Figura 6.22 – Esempio di Monitor Window

178

6.2.6 Alcuni esempi di simulazione interattiva A conclusione del presente capitolo in questa sezione riportiamo sinteticamente alcuni indicativi esempi di simulazione interattiva del nostro modello (con particolare riferimento alla versione 7 e alla versione 15), illustrando i risultati sperimentali ottenuti anche in un’accattivante ‘veste grafica’ direttamente confrontabile, almeno dal punto di vista qualitativo, con la sequenza di time slices teorica e ideale degli stessi processi schedulati, facendo uso delle Waveforms descritte nel paragrafo 6.2.5.5.

Figura 6.23 – Waveform Window della versione 7

6.2.6.1 Primo esempio Nel nostro primo esempio, relativo alla versione 7, le componenti monitorate nella Waveform grafica (vedi Figura 6.23) sono le seguenti: • RUNNING: rappresenta il PID del processo correntemente in esecuzione • ATTIVO_1: rappresenta la condizione composta schedulato and not sospeso(1) • ATTIVO_2: rappresenta la condizione composta schedulato and not sospeso(2) • ATTIVO_3: rappresenta la condizione composta schedulato and not sospeso(3) • ATTIVO_ACCEPTANCE_17: rappresenta la condizione composta schedulato

and not sospeso(17) relativa all’acceptance

179

• SOSPESO(1): rappresenta la condizione di processo 1 schedulato ma sospeso • SOSPESO(2): rappresenta la condizione di processo 2 schedulato ma sospeso • SOSPESO(3): rappresenta la condizione di processo 3 schedulato ma sospeso • SOSPESO(17): rappresenta la condizione di processo 17 (acceptance) schedulato

ma sospeso • FINE(1): rappresenta la condizione di processo 1 completato • FINE(2): rappresenta la condizione di processo 2 completato • FINE(3): rappresenta la condizione di processo 3 completato • FINE(17): rappresenta la condizione di processo 17 (acceptance) completato Tutti questi segnali rappresentano nell’ordine il PID del processo attualmente in esecuzione simulata, le condizioni di effettiva esecuzione simulata (attivazione), quelle di sospensione (in questo caso il processo attivo ha subito preemption ossia prelazione da parte di un processo a priorità maggiore: vedi ad esempio nella Waveform in Figura 6.23 l’acceptance che proprio all’inizio della sua esecuzione subisce preemption dal task 1 a priorità più alta che a sua volta poi subisce preemption dal task 2 a massima priorità) e quelle di terminazione dei processi relativi, ma solo le quattro condizioni ATTIVO_N sono state rappresentate come sequenza di time slice nel grafico Excel1 di schedulazione preemptive con l’aggiunta però delle deadlines periodiche (vedi Figura 6.24). Inoltre, nel Listato 6.2 seguente abbiamo riportato un file di log in formato testo nel quale sono state registrate automaticamente (ossia senza la necessità di un apposito processo register come in [2]) le varie temporizzazioni, in valore assoluto, relative a tutti i segnali sopra citati (tranne il RUNNING, la cui sequenza è riportata a parte nel Listato 6.3) ottenute durante l’esecuzione simulata del nostro sistema fino all’istante di riferimento di 209 clock units. #Absolute time, steps, data-item, type (C=Condition), value (1=true, 0=false) 1.000000 12 ATTIVO_ACCEPTANCE_17 C 1 1.000000 22 SOSPESO(17) C 1 1.000000 22 ATTIVO_ACCEPTANCE_17 C 0 1.000000 24 ATTIVO_1 C 1 4.000000 51 SOSPESO(1) C 1 4.000000 51 ATTIVO_1 C 0 4.000000 53 ATTIVO_2 C 1 12.000000 99 FINE(2) C 1 12.000000 99 ATTIVO_2 C 0 12.000000 101 FINE(2) C 0

1 Tale grafico è stato ottenuto rappresentando in Excel la sequenza di time slices derivante da una schedulazione RM ideale dei processi real-time simulati calcolata in maniera esatta su carta millimetrata.

180

12.000000 102 SOSPESO(1) C 0 12.000000 102 ATTIVO_1 C 1 29.000000 171 FINE(1) C 1 29.000000 171 ATTIVO_1 C 0 29.000000 173 FINE(1) C 0 29.000000 174 SOSPESO(17) C 0 29.000000 174 ATTIVO_ACCEPTANCE_17 C 1 39.000000 215 FINE(17) C 1 39.000000 215 ATTIVO_ACCEPTANCE_17 C 0 39.000000 217 FINE(17) C 0 39.000000 219 ATTIVO_3 C 1 68.000000 340 SOSPESO(3) C 1 68.000000 340 ATTIVO_3 C 0 68.000000 342 ATTIVO_2 C 1 76.000000 374 FINE(2) C 1 76.000000 374 ATTIVO_2 C 0 76.000000 376 FINE(2) C 0 76.000000 377 SOSPESO(3) C 0 76.000000 377 ATTIVO_3 C 1 77.000000 382 FINE(3) C 1 77.000000 382 ATTIVO_3 C 0 77.000000 384 FINE(3) C 0 91.000000 395 ATTIVO_1 C 1 111.000000 479 FINE(1) C 1 111.000000 479 ATTIVO_1 C 0 111.000000 481 FINE(1) C 0 111.000000 483 ATTIVO_ACCEPTANCE_17 C 1 121.000000 523 FINE(17) C 1 121.000000 523 ATTIVO_ACCEPTANCE_17 C 0 121.000000 525 FINE(17) C 0 126.000000 535 ATTIVO_3 C 1 132.000000 564 SOSPESO(3) C 1 132.000000 564 ATTIVO_3 C 0 132.000000 566 ATTIVO_2 C 1 140.000000 598 FINE(2) C 1 140.000000 598 ATTIVO_2 C 0 140.000000 600 FINE(2) C 0 140.000000 601 SOSPESO(3) C 0 140.000000 601 ATTIVO_3 C 1 164.000000 698 FINE(3) C 1 164.000000 698 ATTIVO_3 C 0 164.000000 700 FINE(3) C 0 181.000000 711 ATTIVO_1 C 1 196.000000 776 SOSPESO(1) C 1 196.000000 776 ATTIVO_1 C 0 196.000000 778 ATTIVO_2 C 1 204.000000 810 FINE(2) C 1 204.000000 810 ATTIVO_2 C 0 204.000000 812 FINE(2) C 0 204.000000 813 SOSPESO(1) C 0 204.000000 813 ATTIVO_1 C 1 209.000000 834 FINE(1) C 1 209.000000 834 ATTIVO_1 C 0 209.000000 836 FINE(1) C 0

Listato 6.2 – Log relativo alle temporizzazioni di esecuzione simulata dei task (versione 7)

181

#Absolute time, steps, data-item, type (I=Integer), numeric value 1.000000 10 RUNNING I 17 1.000000 23 RUNNING I 1 4.000000 52 RUNNING I 2 12.000000 102 RUNNING I 1 29.000000 174 RUNNING I 17 39.000000 218 RUNNING I 3 68.000000 341 RUNNING I 2 76.000000 377 RUNNING I 3 91.000000 393 RUNNING I 1 111.000000 482 RUNNING I 17 126.000000 533 RUNNING I 3 132.000000 565 RUNNING I 2 140.000000 601 RUNNING I 3 181.000000 709 RUNNING I 1 196.000000 777 RUNNING I 2 204.000000 813 RUNNING I 1

Listato 6.3 – Log relativo alla temporizzazione simulata di RUNNING (versione 7)

Figura 6.24 – Le linee verticali sotto l'asse del tempo indicano le deadlines periodiche

PROCESS2 (PID) PERIOD (deadline) WORST CASE INTER-TIME ACCEPTANCE (17) 100 (iniziale) 10 1

TASK1 (1) 90 20 1 TASk2 (2) 64 8 3 TASK3 (3) 120 30 2

Tabella 6.2 – Test pattern del primo esempio

2 Non abbiamo specificato la tipologia di task real-time simulati poiché nella versione 7 gli unici processi implementati sono quelli periodici critici garantiti (pcg) e indipendenti (ossia senza sezioni critiche).

17 3 2 1

182

Dal confronto dei due grafici precedenti, che sono basati sul medesimo test pattern d’esempio riportato in Tabella 6.2 e sullo stesso algoritmo di schedulazione Rate Monotonic, si può notare come unica differenza la presenza imprevista, nel caso reale di simulazione (rappresentato in Figura 6.23), del processo 3 tra i passi 377 e 382, ovvero tra gli istanti temporali 76 e 77; nel caso ideale (rappresentato in Figura 6.24) la sequenza dei task è infatti 17, 1, 2, 1, 17, 3, 2, (3), 1, 17, 3, 2, 3, 1, 2, 1, dove (3) è proprio il processo intruso assente. A tal proposito bisogna ribadire che tutte le eventuali piccole discrepanze riscontrabili tra i due schemi di schedulazione sono sempre dovute, a meno di errori di specifica, ad alcune semplificazioni adottate nel modello stesso e alle approssimazioni intrinseche nella natura stessa della nostra simulazione (come gli inevitabili passi di overhead) la quale, anche se formalmente corretta, non è, non potrà e del resto non vuole neanche essere una riproduzione esattamente fedele dell’esecuzione di un modello matematico di un sistema real-time ideale. In questo caso comunque la time slice inattesa relativa al processo 3 non è dovuta, come si potrebbe supporre, all’overhead di sistema dovuto al context switching in quanto questo in tutte le nostre simulazioni, come già anticipato e contrariamente a SDL, introduce dei ritardi solo in termini di passi e non di tempo, come del resto si può osservare direttamente dal file di log del Listato 6.2. La presenza del residuo di esecuzione simulata del task 3 in questo esempio è dovuta semplicemente al fatto che nel nostro modello il processo acceptance (come del resto anche global_monitor e semaphore) non sono attivati subito allo start-up del sistema, ma partono solo all’istante in cui effettivamente servono, ossia contestualmente all’attivazione del primo task real-time arrivato; nel nostro caso dunque il modulo di acceptance parte all’istante 1 contemporaneamente al task 1: dato però che il processo 1 ha priorità maggiore (periodo minore) di acceptance, quest’ultimo subisce preemption prima di poter iniziare a consumare effettivamente il proprio TTC; la sua piccola time slice che appare all’inizio della Waveform in Figura 6.23, pur consumando infatti 10 passi, viene svolta in tempo simulato nullo (vedi le temporizzazioni relative alla condizione ATTIVO_ACCEPTANCE_17 nelle prime righe del Listato 6.2), analogamente a come avviene nel caso i vari task simulati arrivino tutti allo stesso istante di tempo (anche se in passi successivi) ossia con inter-arrival time nulli (come nel secondo esempio). Per questo motivo, quando all’istante 29 il processo acceptance può finalmente ripartire dopo avere aspettato i task 1 e 2 (entrambi a priorità più alta), deve eseguire l’intero suo blocco di computazione simulata (10 unità di tempo) e così, quando all’istante 68 il task 2 riparte con la sua seconda istanza periodica, il task 3 a bassa priorità, partito all’istante 39 (terminazione dell’acceptance), non è ancora riuscito, per una sola unità di tempo (30-[68-39]), a completare la sua prima istanza di esecuzione che potrà concludere solo dopo il task 2 all’istante 77 (vedi ancora il Listato 6.2). Prima di passare ad una rapida esposizione dei risultati ottenuti con la versione 15 per questo stesso esempio osserviamo che dall’apposita Monitor Window (vedi Figura 6.22) si possono monitorare in tempo reale diverse variabili, tra le quali di particolare interesse il PID RUNNING (numero intero che come abbiamo già visto identifica univocamente il processo attualmente in esecuzione), il fattore di utilizzazione U (numero reale) della CPU ed il periodo ACCPERIODO (variabile) dell’acceptance: si osserva così che, durante l’esecuzione simulata, U assume un valore di picco di 0.6972 e di 0.6372 a regime, mentre ACCPERIODO, inizialmente 100 (valore minimo), si assesta sul valore massimo di 250.

183

Nelle figure seguenti abbiamo semplicemente riportato alcuni snap-shots catturati durante la simulazione interattiva della versione 15 eseguita sullo stesso test pattern utilizzato precedentemente per la versione 7 (vedi Tabella 6.2). Da queste figure si può constatare direttamente, anche con il supporto dei due file di log relativi a tutta la temporizzazione dei vari segnali monitorati (vedi Listato 6.4 e Listato 6.5), la perfetta corrispondenza in termini temporali (pur se non in termini di passi) dei risultati sperimentali ottenuti con le due diverse versioni. Ricordiamo infatti che dalla prima versione (7) all’ultima realizzata (15d) abbiamo effettuato diverse modifiche nella gestione del tempo e aggiunto varie funzionalità al sistema applicativo: ciò nonostante la schedulazione ottenuta dall’esecuzione simulata di tutte le versioni implementate risulta sempre uguale dal punto di vista delle temporizzazioni e quindi in tutti i casi equivalente alla schedulazione ideale di riferimento con ottima approssimazione. Chiarito ciò, ci limitiamo ad osservare che dalla versione 13c (anche se con alcune variazioni sul tema nelle varie versioni successive) sono state aggiunte altre utili voci nell’apposita Monitor Window (come NOW e U_TOT: vedi Figura 6.26) ed è stato costruito un Pannello per il monitoraggio (OUT) e il controllo (IN) di vari parametri d’interesse (alcuni dei quali già presenti nella Monitor Window) durante la simulazione stessa (vedi Figura 6.25).

Figura 6.25 – Pannello IN/OUT della versione 15

184

Figura 6.26 – Monitor Window della versione 15 (primo esempio)

Per quanto riguarda infine la Waveform in Figura 6.27 relativa alla simulazione della versione 15 (della quale per problemi di spazio non abbiamo potuto riportare tutto il grafico fino all’istante di riferimento della Figura 6.23) bisogna precisare che, rispetto alla versione 7, sono stati modificati e aggiunti alcuni segnali che descriviamo brevemente di seguito e i più rilevanti dei quali, come già accennato, sono stati registrati durante l’esecuzione simulata in un apposito file di log (vedi Listato 6.5) direttamente confrontabile con quello ottenuto dalla versione 7 (vedi Listato 6.2): • ARRIVO(X): rappresenta l’evento di arrivo del processo con PID=X che però non

può eseguire in quanto la CPU è concessa ad un task con priorità maggiore o uguale • ATTIVO(X): rappresenta la condizione di effettiva esecuzione simulata del task X • FINE(X): rappresenta l’evento di completamento di esecuzione (simulata) del

corrente blocco a tempo del processo con PID=X • PREEMPTED: rappresenta l’evento di preemption del processo RUNNING da

parte di un task pronto a priorità maggiore • SEZIONE_CRITICA: rappresenta la condizione (composta) di esecuzione in

sezione critica • KILLED_GM(X): rappresenta la condizione di fallimento o uccisione del task X

185

Figura 6.27 – Waveform Window della versione 15 (primo esempio)

#Absolute time, steps, data-item, type (I=Integer), numeric value 1.000000 17 RUNNING I 17 1.000000 33 RUNNING I 1 4.000000 77 RUNNING I 2 12.000000 151 RUNNING I 1 29.000000 250 RUNNING I 17 39.000000 312 RUNNING I 3 68.000000 471 RUNNING I 2 76.000000 525 RUNNING I 3 91.000000 614 RUNNING I 1 111.000000 738 RUNNING I 17 126.000000 827 RUNNING I 3 132.000000 871 RUNNING I 2 140.000000 927 RUNNING I 3 181.000000 1146 RUNNING I 1 196.000000 1235 RUNNING I 2 204.000000 1289 RUNNING I 1

Listato 6.4 – Log relativo alla temporizzazione simulata di RUNNING (versione 15)

#Absolute time, steps, data-item, type (C=Condition, E=Event), value (1=true or generated, 0=false) 1.000000 19 ATTIVO(17) C 1 1.000000 31 ATTIVO(17) C 0 1.000000 31 PREEMPTED E 1 1.000000 35 ATTIVO(1) C 1 4.000000 75 ATTIVO(1) C 0 4.000000 75 PREEMPTED E 1 4.000000 79 ATTIVO(2) C 1 6.000000 112 ARRIVO(3) E 1 12.000000 146 FINE(2) E 1 12.000000 146 ATTIVO(2) C 0 12.000000 153 ATTIVO(1) C 1 29.000000 245 FINE(1) E 1

186

29.000000 245 ATTIVO(1) C 0 29.000000 252 ATTIVO(17) C 1 39.000000 307 FINE(17) E 1 39.000000 307 ATTIVO(17) C 0 39.000000 314 ATTIVO(3) C 1 68.000000 469 ATTIVO(3) C 0 68.000000 469 PREEMPTED E 1 68.000000 473 ATTIVO(2) C 1 76.000000 520 FINE(2) E 1 76.000000 520 ATTIVO(2) C 0 76.000000 527 ATTIVO(3) C 1 77.000000 537 FINE(3) E 1 77.000000 537 ATTIVO(3) C 0 91.000000 616 ATTIVO(1) C 1 101.000000 676 ARRIVO(17) E 1 111.000000 733 FINE(1) E 1 111.000000 733 ATTIVO(1) C 0 111.000000 740 ATTIVO(17) C 1 121.000000 795 FINE(17) E 1 121.000000 795 ATTIVO(17) C 0 126.000000 829 ATTIVO(3) C 1 132.000000 869 ATTIVO(3) C 0 132.000000 869 PREEMPTED E 1 132.000000 873 ATTIVO(2) C 1 140.000000 922 FINE(2) E 1 140.000000 922 ATTIVO(2) C 0 140.000000 929 ATTIVO(3) C 1 164.000000 1054 FINE(3) E 1 164.000000 1054 ATTIVO(3) C 0 181.000000 1148 ATTIVO(1) C 1 196.000000 1233 ATTIVO(1) C 0 196.000000 1233 PREEMPTED E 1 196.000000 1237 ATTIVO(2) C 1 204.000000 1284 FINE(2) E 1 204.000000 1284 ATTIVO(2) C 0 204.000000 1291 ATTIVO(1) C 1 209.000000 1321 FINE(1) E 1 209.000000 1321 ATTIVO(1) C 0

Listato 6.5 – Log relativo alle temporizzazioni di esecuzione simulata dei task (versione 15)

6.2.6.2 Secondo esempio Questo secondo esempio, il cui test pattern è illustrato in Tabella 6.3, è stato ancora simulato con la versione 15 e lo abbiamo appositamente riportato per evidenziare due interessanti aspetti del nostro modello applicativo.

PROCESS (PID) PERIOD (deadline) WCCT INTER-TIME ACCEPTANCE (17) 100 (iniziale) 10 0

TASK1 pcg (1) 59 20 0 TASk2 pcg (2) 40 12 0 TASK3 pcg (3) 119 31 0

Tabella 6.3 - Test pattern del secondo esempio

187

Il primo aspetto è rappresentato dal fatto che, come già sottolineato più volte, l’overhead di sistema presente in tutte le nostre esecuzioni simulate è esclusivamente quantificabile in termini di passi svolti sempre in tempo simulato nullo (vedi ad esempio il Listato 6.6): questo ci permette, come in questo caso, di ottenere in fase di simulazione un valore di picco per il fattore di utilizzazione dei task periodici critici garantiti (U_PCG) e per quello istantaneo totale (U_TOT) maggiore di 0.98 (vedi Monitor in Figura 6.28) ed un valore di regime (quando cioè, proprio per far diminuire l’alto fattore di utilizzazione, il periodo dell’acceptance viene automaticamente incrementato al suo valore massimo di 250) per U_PCG maggiore di 0.92 (vedi Monitor in Figura 6.29). Questo fatto non ha peraltro comportato mai alcun fallimento per nessuno dei processi pcg schedulati, almeno fino all’istante di riferimento da noi considerato (10.000 clock units per un totale di ben 62.640 passi). Confrontando quanto risulta dall’analogo esperimento effettuato in [2] sul modello realizzato in SDL, si nota che in quest’ultimo l’overhead di sistema rientra nel tempo simulato, e quindi non si riescono ad ottenere dei così alti valori del fattore di utilizzazione. Riteniamo peraltro la modalità di simulazione SDL più realistica, dal momento che in un vero sistema operativo real-time sono inevitabili ed effettivi i tempi di overhead.

Figura 6.28 – Monitor Window della versione 15 (secondo esempio)

Figura 6.29 – Monitor Window della versione 15 (secondo esempio)

188

Il secondo aspetto riguarda invece il comportamento del nostro sistema nel caso di intertempi di arrivo tutti nulli: in tali condizioni, come già accennato nel primo esempio e come del resto si può osservare direttamente dalle prime righe del Listato 6.6, anche se i vari task pcg arrivano in passi successivi e quindi tra un arrivo e l’altro trovano lo spazio (sempre in termini di passi) per essere attivati (vedi le piccole time slices iniziali del task 17 o acceptance e del task 1 nella Waveform di Figura 6.30), in realtà l’unico processo che inizia veramente a consumare dall’istante 0 il suo TTC è solo quello a priorità più alta, ossia il 2. Così, quando gli altri task vengono (ri)attivati, si trovano a dover completare l’intero loro blocco a tempo (vedi ancora il solito file di log registrato in fase di simulazione fino all’istante di riferimento della Waveform e che da ora in poi conterrà anche RUNNING).

Figura 6.30 – Waveform Window della versione 15 (secondo esempio)

#Absolute time, steps, data-item, type, value 0.000000 12 RUNNING I 17 0.000000 14 ATTIVO(17) C 1 0.000000 26 ATTIVO(17) C 0 0.000000 26 PREEMPTED E 1 0.000000 28 RUNNING I 1 0.000000 30 ATTIVO(1) C 1 0.000000 41 ATTIVO(1) C 0 0.000000 41 PREEMPTED E 1 0.000000 43 RUNNING I 2 0.000000 45 ATTIVO(2) C 1 0.000000 59 ARRIVO(3) E 1

189

12.000000 123 FINE(2) E 1 12.000000 123 ATTIVO(2) C 0 12.000000 128 RUNNING I 1 12.000000 130 ATTIVO(1) C 1 32.000000 237 FINE(1) E 1 32.000000 237 ATTIVO(1) C 0 32.000000 242 RUNNING I 17 32.000000 244 ATTIVO(17) C 1 40.000000 294 ATTIVO(17) C 0 40.000000 294 PREEMPTED E 1 40.000000 296 RUNNING I 2 40.000000 298 ATTIVO(2) C 1 52.000000 365 FINE(2) E 1 52.000000 365 ATTIVO(2) C 0 52.000000 370 RUNNING I 17 52.000000 372 ATTIVO(17) C 1 54.000000 387 FINE(17) E 1 54.000000 387 ATTIVO(17) C 0

Listato 6.6 – Log relativo alle temporizzazioni di esecuzione simulata dei task (secondo esempio)

6.2.6.3 Terzo esempio In questo terzo esempio, come si può notare dal test pattern in Tabella 6.4, utilizziamo alcune delle funzionalità aggiunte al modello applicativo con l’ultima versione realizzata, in particolare la possibilità di specificare, oltre ad un primo blocco a tempo di esecuzione normale (la cui durata è indicata dal parametro FWCASE), anche un secondo blocco (SWCASE) di esecuzione in sezione critica con relativa sezione critica interessata (parametro SC) ed eventualmente un terzo, ed ultimo, blocco omogeneo (TWCASE) ancora di esecuzione normale.

Parametri di esecuzione

TASK1 pcg

TASK2 pcg

TASK3 pcg

INTERTIME 2 4 2 FWCASE 10 8 6 SWCASE 8 6 5 TWCASE - - 7 PERIOD 90 64 120 LATENCY 20 130 400

PID 1 2 3 PRE - - -

SUCC - - - PRIO - - -

MIN_RANGE - - - MAX_RANGE - - -

SC 1 1 2

Tabella 6.4 – Test pattern del terzo esempio

190

In tal modo la schedulazione risultante diventa più articolata ed interessante e permette di testare sul campo la correttezza del protocollo di Priority Ceiling per l’accesso alle risorse di sistema condivise, mutuamente esclusive e preemptable (sezioni critiche). A tal proposito abbiamo ‘catturato’ dalla Waveform grafica della simulazione interattiva una particolare sequenza di time slice (vedi Figura 6.31) che illustra proprio il funzionamento di tale protocollo. Con riferimento anche alle righe appositamente evidenziate nel solito file di log (vedi Listato 6.7), nel quale per l’occasione è stata aggiunta pure la condizione SEZIONE_CRITICA, osserviamo che il task 1, finita la sua prima parte di esecuzione normale, entra in sezione critica ma quasi alla fine della sua conclusione subisce preemption dal task 2 a priorità più alta. Quest’ultimo processo termina quindi il suo primo blocco normale, ma al momento di entrare nella stessa sezione critica viene bloccato dal task 1 che conclude la parte rimanente della sua esecuzione in sezione critica con priorità momentaneamente innalzata (boostprio), per poi rilasciare la risorsa al processo 2 e riacquistare la sua priorità originale. Per inciso osserviamo infine che, pur basandosi sullo stesso test pattern, la sequenza di schedulazione ottenuta con la nostra simulazione, anche se come si può verificare risulta formalmente corretta, si discosta da quella ottenuta nell’analogo esperimento fatto in [2] con SDL, a causa delle diverse condizioni iniziali di esecuzione simulata dovute ad alcune semplificazioni da noi effettuate nella specifica del modulo di acceptance, e alla solita assenza nel nostro sistema dei tempi di overhead, in particolare per quanto riguarda il context switching e il test di schedulabilità.

Figura 6.31 – Waveform Window della versione 15 (terzo esempio)

191

#Absolute time, steps, data-item, type, value 2.000000 22 RUNNING I 17 2.000000 24 ATTIVO(17) C 1 2.000000 36 ATTIVO(17) C 0 2.000000 36 PREEMPTED E 1 2.000000 38 RUNNING I 1 2.000000 40 ATTIVO(1) C 1 6.000000 89 ATTIVO(1) C 0 6.000000 89 PREEMPTED E 1 6.000000 91 RUNNING I 2 6.000000 93 ATTIVO(2) C 1 8.000000 130 ARRIVO(3) E 1 14.000000 164 FINE(2) E 1 14.000000 164 ATTIVO(2) C 0 14.000000 181 ATTIVO(2) C 1 14.000000 181 SEZIONE_CRITICA C 1 20.000000 216 FINE(2) E 1 20.000000 216 ATTIVO(2) C 0 20.000000 216 SEZIONE_CRITICA C 0 20.000000 241 RUNNING I 1 20.000000 243 ATTIVO(1) C 1 26.000000 280 FINE(1) E 1 26.000000 280 ATTIVO(1) C 0 26.000000 297 ATTIVO(1) C 1 26.000000 297 SEZIONE_CRITICA C 1 34.000000 342 FINE(1) E 1 34.000000 342 ATTIVO(1) C 0 34.000000 342 SEZIONE_CRITICA C 0 34.000000 367 RUNNING I 17 34.000000 369 ATTIVO(17) C 1 44.000000 424 FINE(17) E 1 44.000000 424 ATTIVO(17) C 0 44.000000 429 RUNNING I 3 44.000000 431 ATTIVO(3) C 1 50.000000 466 FINE(3) E 1 50.000000 466 ATTIVO(3) C 0 50.000000 483 ATTIVO(3) C 1 50.000000 483 SEZIONE_CRITICA C 1 55.000000 513 FINE(3) E 1 55.000000 513 ATTIVO(3) C 0 55.000000 513 SEZIONE_CRITICA C 0 55.000000 542 ATTIVO(3) C 1 62.000000 582 FINE(3) E 1 62.000000 582 ATTIVO(3) C 0 70.000000 629 RUNNING I 2 70.000000 631 ATTIVO(2) C 1 78.000000 676 FINE(2) E 1 78.000000 676 ATTIVO(2) C 0 78.000000 693 ATTIVO(2) C 1 78.000000 693 SEZIONE_CRITICA C 1 84.000000 728 FINE(2) E 1 84.000000 728 ATTIVO(2) C 0 84.000000 728 SEZIONE_CRITICA C 0 92.000000 795 RUNNING I 1 92.000000 797 ATTIVO(1) C 1 102.000000 854 FINE(1) E 1 102.000000 854 ATTIVO(1) C 0 102.000000 861 ARRIVO(17) E 1 102.000000 871 ATTIVO(1) C 1 102.000000 871 SEZIONE_CRITICA C 1

192

110.000000 918 FINE(1) E 1 110.000000 918 ATTIVO(1) C 0 110.000000 918 SEZIONE_CRITICA C 0 110.000000 943 RUNNING I 17 110.000000 945 ATTIVO(17) C 1 120.000000 1000 FINE(17) E 1 120.000000 1000 ATTIVO(17) C 0 128.000000 1047 RUNNING I 3 128.000000 1049 ATTIVO(3) C 1 134.000000 1086 FINE(3) E 1 134.000000 1086 ATTIVO(3) C 0 134.000000 1094 RUNNING I 2 134.000000 1096 ATTIVO(2) C 1 134.000000 1100 ARRIVO(3) E 1 142.000000 1143 FINE(2) E 1 142.000000 1143 ATTIVO(2) C 0 142.000000 1160 RUNNING I 3 142.000000 1162 ATTIVO(3) C 1 142.000000 1162 SEZIONE_CRITICA C 1 147.000000 1192 FINE(3) E 1 147.000000 1192 ATTIVO(3) C 0 147.000000 1192 SEZIONE_CRITICA C 0 147.000000 1220 RUNNING I 2 147.000000 1222 ATTIVO(2) C 1 147.000000 1222 SEZIONE_CRITICA C 1 147.000000 1225 ARRIVO(3) E 1 153.000000 1257 FINE(2) E 1 153.000000 1257 ATTIVO(2) C 0 153.000000 1257 SEZIONE_CRITICA C 0 153.000000 1282 RUNNING I 3 153.000000 1284 ATTIVO(3) C 1 160.000000 1324 FINE(3) E 1 160.000000 1324 ATTIVO(3) C 0 182.000000 1441 RUNNING I 1 182.000000 1443 ATTIVO(1) C 1 192.000000 1498 FINE(1) E 1 192.000000 1498 ATTIVO(1) C 0 192.000000 1515 ATTIVO(1) C 1 192.000000 1515 SEZIONE_CRITICA C 1 198.000000 1555 ATTIVO(1) C 0 198.000000 1555 PREEMPTED E 1 198.000000 1555 SEZIONE_CRITICA C 0 198.000000 1557 RUNNING I 2 198.000000 1559 ATTIVO(2) C 1 206.000000 1606 FINE(2) E 1 206.000000 1606 ATTIVO(2) C 0 206.000000 1623 RUNNING I 1 206.000000 1625 ATTIVO(1) C 1 206.000000 1625 SEZIONE_CRITICA C 1 208.000000 1640 FINE(1) E 1 208.000000 1640 ATTIVO(1) C 0 208.000000 1640 SEZIONE_CRITICA C 0 208.000000 1667 RUNNING I 2 208.000000 1669 ATTIVO(2) C 1 208.000000 1669 SEZIONE_CRITICA C 1 214.000000 1704 FINE(2) E 1 214.000000 1704 ATTIVO(2) C 0 214.000000 1704 SEZIONE_CRITICA C 0

Listato 6.7 – Log relativo alle temporizzazioni di esecuzione simulata dei task (terzo esempio)

193

Parametri di esecuzione

TASK1 pcg

TASK2 pcg

TASK3 one-shot

TASK4 one-shot

INTERTIME 2 2 4 2 FWCASE 5 9 15 10 SWCASE 5 11 - 10 TWCASE - - - - PERIOD 50 70 120 120 LATENCY 20 130 - -

PID 1 2 3 4 PRE - - 1000 3

SUCC - - 4 1000 PRIO - - 1100 1050

MIN_RANGE - - - - MAX_RANGE - - - -

SC 1 1 - 4

Tabella 6.5 – Test pattern del quarto esempio

6.2.6.4 Quarto esempio Anche in questo esempio abbiamo ripetuto un esperimento effettuato in [2], mutuandone i parametri per l’esecuzione simulata (vedi Tabella 6.5), ottenendo ancora una volta, per le stesse ragioni accennate in precedenza, una sequenza di time slice differente (almeno in certi tratti), anche se sempre consistente con il nostro modello di riferimento e comunque formalmente corretta. D’altronde ciò che vogliamo evidenziare con questo esempio è il fatto che, mentre nelle simulazioni SDL l’overhead di sistema dovuto al complesso meccanismo di IPC implementato per la sincronizzazione di processi legati da vincoli di precedenza, per quanto piccolo, è comunque maggiore di 0 in termini temporali, nelle simulazioni Statemate, analogamente a come avviene per il cambio di contesto, l’overhead necessario alla nostra gestione dei vincoli di precedenza è quantificabile solo in termini di passi svolti sempre in tempo simulato nullo. Ma procediamo con ordine. Dalla Tabella 6.5 si può osservare che i processi real-time simulati in questo esempio con la versione 15b sono di due tipi: i soliti periodici critici garantiti non indipendenti, che condividono la stessa sezione critica, e i one-shot, processi aperiodici firm (non garantiti). Questi ultimi sono caratterizzati da: o un’unica istanza di esecuzione, eventualmente formata anche da più blocchi

omogenei a tempo, dei quali il secondo sempre in sezione critica (come per il task 4), da completare entro una determinata deadline (parametro PERIOD)

o un valore di priorità (parametro PRIO) stabilito prima dello start-up del sistema

dall’utente-progettista e comunque non inferiore al periodo dei task pcg o una strategia di schedulazione di tipo best-effort (highest priority first con

preemption) o la possibilità, come per i periodici firm non garantiti che vedremo nel successivo

esempio, di essere legati da vincoli di precedenza singoli, come del resto è stato fatto in questo caso.

194

Più in particolare, dal valore degli appositi parametri PRE e SUCC si può vedere come il task 3 non abbia nessun predecessore (PRE=1000 ossia PID ’null’) ma un solo successore, il task 4 (SUCC=4) a priorità più alta (PRIO=1050), e corrispondentemente il task 4 abbia come unico predecessore il task 3 (PRE=3) ma nessun successore (SUCC=1000). Abbiamo infine omesso i parametri di esecuzione del processo pcg acceptance dato che sono sempre gli stessi in tutti gli esempi. Dall’osservazione diretta della sequenza di time slice riportata nella Waveform grafica di Figura 6.32 e dalle temporizzazioni dei relativi segnali memorizzate nell’apposito file di log (vedi Listato 6.8) possiamo osservare come, terminato il task pcg a più bassa priorità (acceptance con PID=17), possa finalmente partire il task one-shot firm 3 (il task one-shot 4 infatti, pur avendo una priorità maggiore del 3, non può partire dovendo aspettare il via libera proprio da quest’ultimo) che, dopo aver subito preemption dal task pcg 1, completa il suo primo ed unico blocco di esecuzione simulata all’istante 67. A questo punto viene contemporaneamente attivato il task successore 4 (dalle righe evidenziate nel Listato 6.8 si può infatti constatare che, sebbene l’overhead tra FINE(3) e ATTIVO(4) sia di 16 steps, il tempo trascorso tra i due segnali è identicamente nullo) il quale però, essendo non garantito, subisce preemption anche nella sua sezione critica (che tra l’altro è custodita da un semaforo diverso da quello relativo alla sezione critica dei due task pcg) dai processi pcg che diventano pronti durante la sua esecuzione. In pratica tutti, acceptance compreso, diventano pronti, anche trascurando la piccola time slice intrusa che appare tra i passi 897 e 900 e che però non consuma tempo: vedi le due righe evidenziate ancora nel Listato 6.8. Per questo motivo il task 4 riesce a completare la sua unica istanza di esecuzione, formata da due blocchi, solamente all’istante 127 (vedi la riga evidenziata alla fine del Listato 6.8), pochissimi istanti prima della scadenza della sua deadline a 130 clock units (tempo di arrivo + periodo).

Figura 6.32 – Waveform Window della versione 15b

195

#Absolute time, steps, data-item, type, value 2.000000 22 RUNNING I 17 2.000000 24 ATTIVO(17) C 1 2.000000 36 ATTIVO(17) C 0 2.000000 36 PREEMPTED E 1 2.000000 38 RUNNING I 1 2.000000 40 ATTIVO(1) C 1 4.000000 79 ARRIVO(2) E 1 7.000000 96 FINE(1) E 1 7.000000 96 ATTIVO(1) C 0 7.000000 113 ATTIVO(1) C 1 7.000000 113 SEZIONE_CRITICA C 1 8.000000 129 ARRIVO(3) E 1 12.000000 163 FINE(1) E 1 12.000000 163 ATTIVO(1) C 0 12.000000 163 SEZIONE_CRITICA C 0 12.000000 188 RUNNING I 2 12.000000 190 ATTIVO(2) C 1 21.000000 240 FINE(2) E 1 21.000000 240 ATTIVO(2) C 0 21.000000 257 ATTIVO(2) C 1 21.000000 257 SEZIONE_CRITICA C 1 32.000000 319 FINE(2) E 1 32.000000 319 ATTIVO(2) C 0 32.000000 319 SEZIONE_CRITICA C 0 32.000000 344 RUNNING I 17 32.000000 346 ATTIVO(17) C 1 42.000000 401 FINE(17) E 1 42.000000 401 ATTIVO(17) C 0 42.000000 406 RUNNING I 3 42.000000 408 ATTIVO(3) C 1 52.000000 468 ATTIVO(3) C 0 52.000000 468 PREEMPTED E 1 52.000000 470 RUNNING I 1 52.000000 472 ATTIVO(1) C 1 57.000000 504 FINE(1) E 1 57.000000 504 ATTIVO(1) C 0 57.000000 521 ATTIVO(1) C 1 57.000000 521 SEZIONE_CRITICA C 1 62.000000 551 FINE(1) E 1 62.000000 551 ATTIVO(1) C 0 62.000000 551 SEZIONE_CRITICA C 0 62.000000 576 RUNNING I 3 62.000000 578 ATTIVO(3) C 1 67.000000 608 FINE(3) E 1 67.000000 608 ATTIVO(3) C 0 67.000000 614 RUNNING I 4 67.000000 616 ATTIVO(4) C 1 74.000000 661 ATTIVO(4) C 0 74.000000 661 PREEMPTED E 1 74.000000 663 RUNNING I 2 74.000000 665 ATTIVO(2) C 1 83.000000 717 FINE(2) E 1 83.000000 717 ATTIVO(2) C 0 83.000000 734 ATTIVO(2) C 1 83.000000 734 SEZIONE_CRITICA C 1 94.000000 794 FINE(2) E 1 94.000000 794 ATTIVO(2) C 0 94.000000 794 SEZIONE_CRITICA C 0 94.000000 819 RUNNING I 4

196

94.000000 821 ATTIVO(4) C 1 97.000000 841 FINE(4) E 1 97.000000 841 ATTIVO(4) C 0 97.000000 858 ATTIVO(4) C 1 97.000000 858 SEZIONE_CRITICA C 1 102.000000 893 ATTIVO(4) C 0 102.000000 893 PREEMPTED E 1 102.000000 893 SEZIONE_CRITICA C 0 102.000000 895 RUNNING I 17 102.000000 897 ATTIVO(17) C 1 102.000000 900 ATTIVO(17) C 0 102.000000 900 PREEMPTED E 1 102.000000 902 RUNNING I 1 102.000000 904 ATTIVO(1) C 1 107.000000 935 FINE(1) E 1 107.000000 935 ATTIVO(1) C 0 107.000000 952 ATTIVO(1) C 1 107.000000 952 SEZIONE_CRITICA C 1 112.000000 984 FINE(1) E 1 112.000000 984 ATTIVO(1) C 0 112.000000 984 SEZIONE_CRITICA C 0 112.000000 998 RUNNING I 17 112.000000 1000 ATTIVO(17) C 1 122.000000 1055 FINE(17) E 1 122.000000 1055 ATTIVO(17) C 0 122.000000 1060 RUNNING I 4 122.000000 1062 ATTIVO(4) C 1 122.000000 1062 SEZIONE_CRITICA C 1 127.000000 1092 FINE(4) E 1 127.000000 1092 ATTIVO(4) C 0 127.000000 1092 SEZIONE_CRITICA C 0

Listato 6.8 – Log relativo alle temporizzazioni di esecuzione simulata dei task (quarto esempio)

parametri di esecuzione

TASK1 periodic

TASK2 sporadic

TASK3 periodic

TASK4 periodic

INTERTIME 2 2 4 2 FWCASE 5 8 15 10 SWCASE 5 12 5 10 TWCASE - 4 - - PERIOD 120 83 120 120 LATENCY - - - -

PID 1 2 3 4 PRE 1000 - 1 3

SUCC 3 - 4 1000 PRIO 600 1600 1100 1050

MIN_RANGE - 1 - - MAX_RANGE - 10 - -

SC 3 8 5 6

Tabella 6.6 – Test pattern del quinto esempio

197

6.2.6.5 Quinto esempio In questo quinto ed ultimo esempio, come si può osservare dalla Tabella 6.6, abbiamo simulato, utilizzando l’apposita versione 15c, quattro processi esclusivamente di tipo firm non garantito, in particolare: o tre task periodici, di cui il terzo ed il quarto condividono la sezione critica (o meglio

il semaforo che le custodisce) i quali, formando una catena di processi con vincoli di precedenza (il task 1 deve precedere nell’esecuzione il task 3 che a sua volta è il predecessore del task 4), hanno tutti lo stesso periodo e sono inoltre caratterizzati da un valore di priorità compatibile con il ceiling del semaforo relativo alla sezione critica d’interesse

o un task sporadico, ossia un processo real-time aperiodico che può essere visto come

un periodico per il quale il periodo inteso come deadline è ancora costante, ma la richiesta di esecuzione di ciascuna istanza successiva alla prima viene inoltrata, scaduta la deadline della precedente istanza, ad un istante di tempo casuale, pur se variabile entro l’intervallo temporale individuato dai due estremi (compresi) MIN_RANGE e MAX_RANGE specificati.

Figura 6.33 – Waveform Window della versione 15c

198

L’interesse di questo esempio non è comunque nei tre task periodici o nei loro vincoli di precedenza ma piuttosto nel fatto che al processo sporadico, pur avendo tre blocchi di computazione e un periodo minore rispetto agli tre task simulati, è stata appositamente assegnata la priorità più bassa: ciò comporta prima o poi (l’aleatorietà del risultato è dovuta alla casualità stessa degli istanti di ripartenza delle varie istanze dello sporadic) l’inesorabile fallimento del processo in questione, come abbiamo potuto constatare dall’osservazione di diverse esecuzioni simulate del nostro modello. Questo è mostrato, ad esempio, dalla Waveform in Figura 6.33 nella quale, come indicato anche dalla riga finale evidenziata nel corrispondente file di log del Listato 6.9, all’istante 180 diventa vera la condizione KILLED_GM(2). #Absolute time, steps, data-item, type, value 2.000000 22 RUNNING I 1 2.000000 24 ATTIVO(1) C 1 2.000000 27 ATTIVO(1) C 0 2.000000 27 PREEMPTED E 1 2.000000 29 RUNNING I 17 2.000000 31 ATTIVO(17) C 1 4.000000 53 ARRIVO(2) E 1 12.000000 118 FINE(17) E 1 12.000000 118 ATTIVO(17) C 0 12.000000 123 RUNNING I 1 12.000000 125 ATTIVO(1) C 1 17.000000 155 FINE(1) E 1 17.000000 155 ATTIVO(1) C 0 17.000000 172 ATTIVO(1) C 1 17.000000 172 SEZIONE_CRITICA C 1 22.000000 202 FINE(1) E 1 22.000000 202 ATTIVO(1) C 0 22.000000 202 SEZIONE_CRITICA C 0 22.000000 223 RUNNING I 2 22.000000 225 ATTIVO(2) C 1 22.000000 228 ATTIVO(2) C 0 22.000000 228 PREEMPTED E 1 22.000000 230 RUNNING I 3 22.000000 232 ATTIVO(3) C 1 37.000000 313 FINE(3) E 1 37.000000 313 ATTIVO(3) C 0 37.000000 330 ATTIVO(3) C 1 37.000000 330 SEZIONE_CRITICA C 1 42.000000 360 FINE(3) E 1 42.000000 360 ATTIVO(3) C 0 42.000000 360 SEZIONE_CRITICA C 0 42.000000 377 RUNNING I 2 42.000000 379 ATTIVO(2) C 1 42.000000 382 ATTIVO(2) C 0 42.000000 382 PREEMPTED E 1 42.000000 384 RUNNING I 4 42.000000 386 ATTIVO(4) C 1 52.000000 442 FINE(4) E 1 52.000000 442 ATTIVO(4) C 0 52.000000 459 ATTIVO(4) C 1 52.000000 459 SEZIONE_CRITICA C 1 62.000000 514 FINE(4) E 1 62.000000 514 ATTIVO(4) C 0 62.000000 514 SEZIONE_CRITICA C 0 62.000000 531 RUNNING I 2

199

62.000000 533 ATTIVO(2) C 1 70.000000 578 FINE(2) E 1 70.000000 578 ATTIVO(2) C 0 70.000000 595 ATTIVO(2) C 1 70.000000 595 SEZIONE_CRITICA C 1 82.000000 660 FINE(2) E 1 82.000000 660 ATTIVO(2) C 0 82.000000 660 SEZIONE_CRITICA C 0 82.000000 677 ATTIVO(2) C 1 86.000000 702 FINE(2) E 1 86.000000 702 ATTIVO(2) C 0 97.000000 774 ATTIVO(2) C 1 102.000000 809 ATTIVO(2) C 0 102.000000 809 PREEMPTED E 1 102.000000 811 RUNNING I 17 102.000000 813 ATTIVO(17) C 1 112.000000 870 FINE(17) E 1 112.000000 870 ATTIVO(17) C 0 112.000000 875 RUNNING I 2 112.000000 877 ATTIVO(2) C 1 115.000000 897 FINE(2) E 1 115.000000 897 ATTIVO(2) C 0 115.000000 914 ATTIVO(2) C 1 115.000000 914 SEZIONE_CRITICA C 1 122.000000 960 ATTIVO(2) C 0 122.000000 960 PREEMPTED E 1 122.000000 960 SEZIONE_CRITICA C 0 122.000000 962 RUNNING I 1 122.000000 964 ATTIVO(1) C 1 127.000000 995 FINE(1) E 1 127.000000 995 ATTIVO(1) C 0 127.000000 1012 ATTIVO(1) C 1 127.000000 1012 SEZIONE_CRITICA C 1 132.000000 1058 FINE(1) E 1 132.000000 1058 ATTIVO(1) C 0 132.000000 1058 SEZIONE_CRITICA C 0 132.000000 1076 RUNNING I 2 132.000000 1078 ATTIVO(2) C 1 132.000000 1078 SEZIONE_CRITICA C 1 132.000000 1081 ATTIVO(2) C 0 132.000000 1081 PREEMPTED E 1 132.000000 1081 SEZIONE_CRITICA C 0 132.000000 1083 RUNNING I 3 132.000000 1085 ATTIVO(3) C 1 147.000000 1166 FINE(3) E 1 147.000000 1166 ATTIVO(3) C 0 147.000000 1183 ATTIVO(3) C 1 147.000000 1183 SEZIONE_CRITICA C 1 152.000000 1213 FINE(3) E 1 152.000000 1213 ATTIVO(3) C 0 152.000000 1213 SEZIONE_CRITICA C 0 152.000000 1227 RUNNING I 2 152.000000 1229 ATTIVO(2) C 1 152.000000 1229 SEZIONE_CRITICA C 1 152.000000 1232 ATTIVO(2) C 0 152.000000 1232 PREEMPTED E 1 152.000000 1232 SEZIONE_CRITICA C 0 152.000000 1234 RUNNING I 4 152.000000 1236 ATTIVO(4) C 1 162.000000 1292 FINE(4) E 1 162.000000 1292 ATTIVO(4) C 0

200

162.000000 1309 ATTIVO(4) C 1 162.000000 1309 SEZIONE_CRITICA C 1 172.000000 1364 FINE(4) E 1 172.000000 1364 ATTIVO(4) C 0 172.000000 1364 SEZIONE_CRITICA C 0 172.000000 1378 RUNNING I 2 172.000000 1380 ATTIVO(2) C 1 172.000000 1380 SEZIONE_CRITICA C 1 177.000000 1410 FINE(2) E 1 177.000000 1410 ATTIVO(2) C 0 177.000000 1410 SEZIONE_CRITICA C 0 177.000000 1427 ATTIVO(2) C 1 180.000000 1448 KILLED_GM(2) C 1 180.000000 1449 KILLED_GM(2) C 0 180.000000 1451 ATTIVO(2) C 0

Listato 6.9 – Log relativo alle temporizzazioni di esecuzione simulata dei task (quinto esempio)

E’ possibile però evitare tale fallimento intervenendo, oltre che a priori nella specifica dei parametri di esecuzione del task sporadico o degli altri task, anche direttamente in fase di simulazione per mezzo dei comandi presenti nel Pannello IN/OUT da noi costruito; più in particolare, siamo riusciti a salvare il processo in questione in uno dei seguenti modi: o disattivando il modulo di acceptance subito dopo la conclusione della sua prima

istanza periodica tramite l’apposito pulsante deactivated (vedi Figura 6.34), cosa del resto più che ragionevole data la totale assenza di task pcg da schedulare

o modificando durante la simulazione, ma comunque prima del fallimento del task

sporadico, il valore della deadline periodica per la seconda e di conseguenza per tutte le successive istanze di esecuzione del task stesso, tramite l’apposita slider proc2 period (vedi Figura 6.35).

Il tipo, i tempi ed i valori dei cambiamenti da noi proposti possono ovviamente anche essere diversi ma si tenga presente che, dato il non-determinismo intrinseco in questa tipologia di processi real-time, non è possibile affidarsi, come nei precedenti esempi, alla ripetibilità e alla prevedibilità dei risultati sperimentali.

201

Figura 6.34 – Pannello della versione 15c (pulsante deactivated)

Figura 6.35 – Pannello della versione 15c (slider proc2 period)

202

6.3 Conclusioni A conclusione del nostro lavoro possiamo riportare delle considerazioni relative sia al modello che abbiamo realizzato, sia ad un suo confronto con l’analogo lavoro svolto in precedenza con il linguaggio SDL. Poiché sostanzialmente riteniamo che il nostro modello abbia soddisfatto i requisiti principali che ci eravamo posti all’inizio, discuteremo prima del confronto con il modello SDL di riferimento, rimandando al prossimo paragrafo la discussione dei possibili miglioramenti da apportare al nostro sistema applicativo. Ad ogni modo bisogna osservare che, attraverso la simulazione effettuata su numerosi insiemi di processi (tasking set) – dei quali per motivi di spazio sono stati illustrati solamente cinque casi – appositamente scelti per testare tutti gli aspetti salienti del modello e tutte quelle funzionalità per le quali esso è stato progettato, si è potuto verificare sperimentalmente il corretto funzionamento del sistema implementato: la sequenzializzazione logica e la temporizzazione rilevata nell’esecuzione simulata dei vari task real-time è infatti in tutti i casi esattamente quella attesa, essendo sempre praticamente uguale, dal punto di vista quantitativo, a quella che verrebbe presentata da un vero e proprio sistema operativo real-time che abbia la stessa strategia di schedulazione e la medesima gestione delle risorse del nostro Kernel Simulator. La simulazione Statemate presenta però, come più volte sottolineato, una non trascurabile differenza rispetto a quella corrispondente SDL: l’overhead di sistema da noi riscontrato, peraltro intrinseco nel modello stesso, è sempre quantificabile in termini di passi svolti in tempo nullo, da cui l’equivalenza sostanziale, dal punto di vista delle temporizzazioni, delle nostre varie versioni tra loro e con la schedulazione ideale di riferimento. Nelle simulazioni SDL invece, l’overhead di sistema e l’interpretazione stessa dei costrutti del linguaggio formale durante la fase di simulazione consumano dei tempi che, per quanto piccoli, non sono mai nulli, e quindi tale equivalenza si ottiene solo con una certa, seppur buona, approssimazione. D’altro canto, per questi stessi motivi e come già osservato precedentemente, una simulazione Statemate di un modello di sistema real-time risulta più artificiale e meno realistica della corrispondente simulazione SDL. Confrontando altresì i due formalismi, per alcuni aspetti la specifica Statemate si è mostrata più rapida e sintetica di quella corrispondente SDL per quanto riguarda, ad esempio, la realizzazione dell’IPC per la gestione dei vincoli di precedenza singoli tra processi o la decomposizione multi-livello del modello tramite le off-page Charts e, più in generale, l’information hiding che le caratterizza. Per altri aspetti invece la specifica Statemate è risultata indubbiamente più complessa e dispendiosa, in particolare per quanto riguarda la gestione delle Generic Charts, dell’input queue dei processi e dei timer logici, oltre alla delicata questione della temporizzazione nell’esecuzione delle istruzioni. Comunque, quello che è stato da noi percepito come un maggiore costo nella stesura delle specifiche Statemate, viene ampiamente ripagato, almeno nei confronti della versione dello strumento Cinderella SDL [31] utilizzata in [2], dalle numerose funzionalità aggiuntive offerte dal Simulation Tool di Statemate (Analyzer e Panel Graphic Editor) e dalle altre componenti opzionali (C Code Generator, Reports, Documentor, Dataport: vedi Figura 3.2) o di terze parti (Requirements Trace (RT) e Configuration Management (CM) Interface Tools, VisSim: vedi Figura 3.1) incluse come add-ons o supportate nella versione completa dello strumento della I-Logix.

203

6.4 Possibili sviluppi futuri Gli sviluppi che si possono delineare per il lavoro fin qui svolto seguono, a nostro avviso, tre differenti direzioni: 1. Riconsiderazione di alcuni aspetti del modello che hanno sofferto dell’impostazione

di porting da SDL a Statemate data fin dall’inizio del progetto. 2. Ulteriori funzionalità che possono essere sviluppate come aggiunte al modello

applicativo per una sua maggiore usabilità. 3. Utilizzo migliore delle varie features offerte dallo strumento I-Logix Statemate

MAGNUM, ulteriormente ampliate e perfezionate nell’ultima versione 3.1. Alla prima categoria possono ricondursi la specifica del modulo di acceptance, la gestione poco efficiente delle tabelle dei processi garantiti, pronti o bloccati, il meccanismo di IPC che non prevede vincoli di precedenza multipli, ed infine la questione rimasta in sospeso sull’utilizzo dei costrutti suspend() e resume() per realizzare la preemption simulata dei task real-time (vedi versione 9 nel paragrafo 4.2.4). Per quanto riguarda invece le funzionalità aggiuntive, si potrebbe prendere in esame il Mapping Tool prospettato in [2] per SDL, per l’eventuale mappatura automatica, in Statemate, della vista vera dei processi real-time a quella corrispondente di simulazione, e magari l’automatizzazione, tramite appositi scripts, nella creazione della specifica e dei collegamenti per alcune Charts del modello, come ad esempio quelle contenenti le generic instances dei task real-time da simulare; per quest’ultimo punto si può peraltro sfruttare il fatto che i files relativi alla specifica formale Statemate delle varie Charts sono sempre in formato testo. Inoltre, come proposto anche in [2], un’altra possibile evoluzione del sistema applicativo potrebbe consistere nell’ampliare le funzionalità offerte dal Kernel Simulator implementando, ad esempio, ulteriori politiche di scheduling per i processi real-time simulati. Infine, un più ampio utilizzo delle funzionalità offerte da Statemate potrebbe consistere in: • Generazione automatica del codice sorgente in C, tramite l’apposito strumento

separato, o in altri linguaggi di programmazione più o meno diffusi, come Ada, VHDL e Verilog, delle specifiche realizzate; si potrebbe in questo modo ottenere un, seppur semplice, sistema operativo real-time consistente con le simulazioni effettuate.

• Creazione di ulteriori Pannelli di interfaccia grafica utente di ingresso e uscita

(IN/OUT GUI) per un intuitivo e completo controllo visuale di tutti i parametri di esecuzione caratteristici dei vari processi real-time simulati.

• Utilizzo del nuovo e sofisticato strumento separato di Model Checking, aggiunto

nell’ultima release dello Statemate, così da poter affiancare alle simulazioni effettuate i risultati di opportune verifiche formali.

204

Bibliografia [1] D. Harel, M. Politi. Modeling Reactive System with Statecharts: The Statemate

Approach, I-Logix Inc., February 1999. [2] S. Carsughi. Specifica e Simulazione di Sistemi in Tempo Reale mediante SDL.

Tesi di laurea, Facoltà di Ingegneria, Università degli Studi di Firenze, Settembre 2001.

[3] G. C. Buttazzo. Sistemi in Tempo Reale. Pitagora Editrice Bologna, 1995. [4] L. Sha, R. Rajkumar, S. Sathaye. Generalized Rate-Monotonic Scheduling

Theory: A Framework for Developing Real-Time Systems. Proceedings of the IEEE, 82:68-81, January 1994.

[5] J. Ellsberger, D. Hogrefe, A. Sarma. Formal Object-Oriented Language for

Communicating Systems. Prentice Hall, 1997 [6] F. Belina, D. Hogrefe, A. Sarma. SDL with Applications from Protocol

Specification. Prentice Hall, 1991. [7] D. Harel, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtull-

Trauring, M. Trakhtenbrot. STATEMATE: A Working Environment for the Development of Complex Reactive Systems. IEEE Transactions on Software Engineering, Vol. 16, n. 4, April 1990.

[8] D. Harel, E. Geri. Executable Object Modeling with StateCharts. IEEE, July 1997. [9] I-Logix Inc. Statemate MAGNUM Quick Reference Guide, June 2000. [10] I-Logix Inc. Tutorial for Statemate MAGNUM 2.0, March 1999. [11] I-Logix Inc. Statemate MAGNUM Methodology and Style Guidelines, June 2000. [12] I-Logix Inc. Statemate MAGNUM Simulation Reference Manual, June 2000. [13] I-Logix Inc. Rhapsody Brochure, December 1999. [14] Iar Systems. Concept Guide for IAR visualSTATE version 4, October 1999. [15] Iar Systems. IAR visualSTATE version 4 Reference Guide, October 1999. [16] I-Logix Inc. Statemate MAGNUM Brochure, November 2000. [17] B. P. Douglass. Finite State Machines and State Charts, I-Logix Inc., November

1998.

205

[18] D. Harel, A. Naamad. The STATEMATE Semantics of Statecharts, ACM Transaction on Software Engineering and Methodology, October 1996.

[19] D. Harel. Statecharts: A Visual Formalism for Complex Systems, Science of

Computer Programming 8, July 1987. [20] D. Harel. On Visual Formalisms, Comm. ACM 31, May 1988. [21] D. Harel, M. Politi. Modeling Reactive Systems with Statecharts, McGraw-Hill,

New York, 1998. [22] D. Harel, M. Politi. The Languages of STATEMATE, tech. report, I-Logix Inc.,

Andover, MA, 1991. [23] H. Gomma, Software Design Methods for Concurrent and Real-Time Systems,

Addison-Wesley, 1993. [24] P. Ramanritham, J. A. Stankovic. Scheduling Algorithms and Operating System

Support for Real-Time Systems, Proceedings of the IEEE, 82:55-67, January 1994. [25] B. P. Douglass. The UML For Systems Engineering, 1999. [26] B. P. Douglass. UML Statecharts, I-Logix Inc., 1999. [27] D. Harel, A. Pnueli. On the development of reactive systems, Logics and Models

of Concurrent Systems, K. R. Apt. Ed. New York. Springer-Verlag, 1985. [28] D. Harel., A. Pnueli., J. P. Schmidt., R. Sherman. On the formal semantics of

statecharts, 2nd IEEE Symp. Logic in Computer Science, New York, IEEE Press, 1987.

[29] I-Logix Inc. The STATEMATE approach to complex systems, Burlington, MA,

tech. report, 1989. [30] D. Hatley and I. Pirbhai, Strategies for Real-Time System Specification, Dorset

House, New York, 1987. [31] Cinderella SDL v.1.1. Cinderella APS, Copenhagen, Denmark, 1998. [32] J. P. Lehoczky, L. Sha, Y. Ding. The Rate-Monotonic Scheduling Algorithm –

Exact Characterization and Average Case Behaviour. Proceedings of the IEEE Real-Time Systems Symposium, pp. 166-171, December 1989.

[33] L. Sha, R. Rajkumar, J. P. Lehoczky. Priority Inheritance Protocols: An

Approach to Real-Time Synchronization. IEEE Transactions on Computers, 39, No. 9, September 1990.

[34] E. Vicario, A. Fedeli. Un benchmark di sistemi fixed priority preemptive.

Dipartimento di Sistemi e Informatica, Università degli Studi di Firenze, 2001.