Appunti Sistemi embedded e real time

Sistemi embedded e real time

Capitolo 1 – Introduzione ai sistemi embedded

1.1 Introduzione generale

Un sistema embedded è un sistema programmabile non pensato per essere riprogrammato dall’utente. È un’applicazione specializzata. Inoltre, i sistemi embedded sono fortemente immersi nell’ambiente circostante, ci sono sensori per interagire con l’utente. L’UI è invisibile o comunque non usuale (formata ad esempio da LED o LCD).

Un sistema embedded è quindi una struttura di supporto al funzionamento di un’applicazione, presentando come caratteristiche:

• Un significativo livello di interazione con l’esterno;
• Comandi o modalità operative che non sono selezionati direttamente da un operatore;
• Sono calcolatori elettronici con un loro software, quindi vanno programmati.

La diffusione dei sistemi embedded è vasta: sono in decine di microprocessori secondari del PC; in tastiere, monitor LCD con processori specializzati; telefoni cellulari; orologi; USB; ecc. Tra il 98% e il 99% dei dispositivi programmabili sono sistemi embedded. I campi di applicazione sono molteplici e spaziano dall’automotive, avionica, automazione industriale, telecomunicazioni agli apparati medicali, domotica, ecc.

1.1.1 Caratteristiche dei sistemi embedded

A differenza dei moderni calcolatori elettronici, che sono dotati di un hardware molto potente e vario (molta memoria, molte CPU, ecc.), i sistemi embedded vengono sviluppati per eseguire un singolo compito e sono quindi ottimizzati seguendo particolari criteri.

Inoltre, i calcolatori elettronici ad uso generale seguono standard e architetture di riferimento, mentre per i sistemi embedded è complesso definire degli standard in quanto, per ciascuna specifica applicazione di quest’ultimi, è necessario fare scelte progettuali differenti. Le tipiche funzionalità di un sistema embedded prevedono:

• Elaborazione: capacità di elaborare dati del mondo esterno, necessita di una determinata potenza di calcolo;
• Comunicazione: capacità di trasmettere segnali da/verso il mondo esterno e dall’interno del sistema embedded;
• Memorizzazione: quante informazioni devo salvare all’interno del sistema embedded.

Per ogni sistema embedded vanno considerati i seguenti parametri:

• Costo finale: per le scelte progettuali da prendere bisogna valutare bene dove viene integrato il sistema ed il suo costo;
• Time to market: impiegare troppo tempo per la progettazione del sistema embedded significa spesso essere superati dall’evoluzione del mercato. È dunque importante il momento in cui si vuole porre il dispositivo sul mercato;
• Volume: quanti pezzi del sistema penso di produrre;
• Interfacce di comunicazione: di solito a basso costo, ma sempre incidenti sul prezzo finale;
• Interfacce utente: qualche pulsante e/o led, ad esempio uno schermo LCD;
• Consumo energetico e tempo di vita.

Anche le capacità devono essere ben rapportate alle specifiche del sistema embedded:

• Dimensione del codice: il software deve essere bilanciato;
• Quality of Service: molte applicazioni hanno dei requisiti stringenti in termini di QoS, ad esempio i servizi in tempo reale (limiti temporali);
• Aggiornamento del software: è utile includere questa capacità per il produttore di aggiornare senza ritirare il prodotto, permettendo di risolvere eventuali guasti;
• Affidabilità: valutazione realistica della probabilità di guasto;
• Manutenibilità: probabilità che il sistema possa essere riparato/sostituito in un certo intervallo di tempo;
• Disponibilità: probabilità che il sistema funzioni in ogni momento, vogliamo che abbia un valore alto (dipende dalla manutenibilità e affidabilità);
• Safety: proprietà legata al fatto che un uso incorretto o un guasto provochi danni a cose o persone;
• Sicurezza: capacità di resistere agli usi non autorizzati/pensati in fase di progettazione.

Capitolo 2 – Introduzione ai sistemi real-time

2.1 Introduzione generale

Un sistema real-time è un sistema che deve lavorare secondo dei vincoli temporali ben precisi. Il sistema riceve un input, calcola un corretto output e questo calcolo viene effettuato entro dei limiti temporali. La maggior parte dei sistemi embedded è anche real-time e viceversa.

La tipologia del sistema operativo real-time è un fattore critico in tutte le applicazioni safety-critical. La teoria della schedulazione real-time studia cosa è possibile ottenere (in termini di prestazioni) avendo a disposizione un certo hardware, con potenza di calcolo limitata.

I sistemi embedded interagiscono con l’ambiente circostante, reagendo rapidamente ai segnali esterni (esempio: airbag). Non è possibile progettare l’hardware separatamente dal software, bisogna fin da subito stabilire il tipo di applicazione e di conseguenza il tipo di sistema real-time da porre sul sistema embedded.

2.1.1 Teoria della schedulazione real-time

Nella teoria della schedulazione real-time si hanno:

• Una CPU con una certa potenza di calcolo (si noti che in tal caso non si intende la classica CPU del PC ma un qualsiasi dispositivo in grado di eseguire calcoli). Generalmente la potenza di calcolo è limitata;
• Dei processi che svolgono dei task rispettando determinate scadenze per il loro completamento.

L’obiettivo è avere un algoritmo di schedulazione che permetta di rispettare le scadenze. Ammettendo di avere una potenza di calcolo superiore, i tempi di esecuzione dei task sarebbero ridotti, quindi sembrerebbe che la teoria della schedulazione non serva. In realtà, in alcuni casi aumentare la potenza di calcolo non aiuta, mentre in altri non è proprio possibile per motivi di budget.

Un altro problema da dover affrontare nei sistemi real-time riguarda la possibilità di eseguire test: questi infatti possono essere eseguiti, ma non sono sufficienti. Occorre quindi la certezza matematica che il sistema sia ben progettato. I parametri temporali del sistema sono noti a priori.

2.1.2 Esempi di sistemi real-time

Vi sono diversi esempi di sistemi real-time che possono essere considerati:

• Sistemi di controllo ad alto livello: ad esempio una sala di terapia intensiva, in cui dei sistemi di controllo a basso livello mandano i dati a quelli di alto livello, che li processano e li usano per tenere i parametri vitali stabili;
• Processamento di segnali: sistemi radar;
• Mercati finanziari: viene regolato da DB che memorizzano il valore dei titoli, che viene continuamente aggiornato, e in cui i dati vengono considerati in base alla “freschezza” (da quanto tempo sono stati aggiornati).

2.1.3 Nomenclatura dei sistemi real-time

Un sistema effettua il mapping fra un valore di input ed il valore di output risultante. La correttezza logica risiede nel fatto che per un certo valore di input, verrà prodotto il corretto valore di output. Un sistema real-time è un sistema la cui correttezza logica dipende non solo dal risultato fornito come output, ma anche dall’istante temporale in cui l’output è reso disponibile.

Un’applicazione real-time è un programma o insieme di programmi con vincoli temporali ben definiti, mentre un sistema real-time è un insieme di dispositivi hardware e software che rendono possibile la corretta esecuzione di un’applicazione real-time.

I sistemi real-time si possono dividere in:

• Sistemi puramente ciclici: ogni task è eseguito periodicamente (il periodo è fisso).
• Sistemi per lo più ciclici: la maggior parte dei task viene eseguita periodicamente, tuttavia ci sono eventi, come la gestione di errori/guasti, che vanno gestiti a parte.
• Sistemi asincroni ma predicibili: la maggior parte dei task non sono periodici, ma le loro frequenze di esecuzione ricadono entro limiti prefissati.
• Sistemi asincroni e non predicibili: non è noto l’esatto istante di arrivo di un task, ma quando esso arriva, bisogna rispettare vincoli temporali ben precisi (oneroso da un punto di vista computazionale).

Un job è l’unità di lavoro minima che può essere schedulata ed eseguita da un sistema real-time, ed esso può essere ad esempio:

• Un processo eseguito da una CPU;
• La spedizione di un messaggio su un canale di comunicazione;
• La lettura di un file da un dispositivo di massa.

Un task è un insieme di job tra loro correlati, che uniti realizzano una determinata funzione del sistema. Ad esempio, un task può essere formato dal:

• Job che acquisisce i dati di un sensore;
• Job che converte i valori in un formato appropriato;
• Job che aggiorna con i valori convertiti alcune strutture dati.

In uno stesso task, un job non può iniziare se il job che lo precede nel task non è terminato.

Per processore, si intende una componente attiva del sistema real-time in grado di eseguire job: possono essere ad esempio CPU, disco rigido, canale di rete. Più il processore è “veloce”, più grande è il numero di job che sarà in grado di eseguire.

Una risorsa è una componente del sistema la cui disponibilità è necessaria per eseguire determinati job. È una componente passiva. La risorsa è un elemento in cui il fattore velocità non incide, ed esempi di essa sono:

• Un semaforo System V che permette di accedere a risorse condivise;
• La memoria di un sistema.

L’istante di rilascio di un job è l’istante temporale in cui un job diviene disponibile per l’esecuzione. La scadenza di un job è l’istante temporale entro cui il job deve aver finito l’esecuzione. Il tempo di risposta del job è l’intervallo fra il suo rilascio e l’istante in cui completa l’esecuzione. La scadenza relativa di un job è il massimo tempo di risposta ammesso per un job. In particolare, abbiamo che: scadenza (assoluta) = istante di rilascio + scadenza relativa.

2.1.4 Sistemi hard real-time e soft real-time

Esistono diverse definizioni di sistemi hard e soft real-time, ciascuna delle quali presenta diverse problematiche.

Una prima definizione può essere la seguente: un sistema hard real-time è un sistema in cui qualcosa che non rispetta i vincoli temporali provoca un danno fatale, con effetti disastrosi; un sistema soft real-time è un sistema in cui la mancanza di una deadline non ha effetti disastrosi.

Tale definizione ha dei limiti: il criterio con cui si definisce un “danno fatale con effetti disastrosi” è soggettivo. Allora, un’altra definizione si basa sulla funzione di utilità dei job, ovvero quanto è “utile” completare quel job dopo la sua scadenza, e tale definizione è:

• In un sistema hard real-time, la funzione di utilità di un job si abbatte se il job è in ritardo;
• In un sistema soft real-time, invece, la funzione di utilità decresce gradualmente in funzione della tardività.

La tardività di un job è il ritardo con cui il job completa la sua esecuzione rispetto alla sua scadenza.

Nel caso di sistemi hard real-time, l’utilità si annulla o diventa negativa al crescere della tardività: avere un’utilità negativa vuol dire che il sistema trae vantaggio dal non completare il job in ritardo.

Anche in tal caso il limite di tale definizione sta nel modo in cui si assegna la funzione di utilità, che è arbitrario e frutto di opinioni personali.

Un’ultima possibile definizione si basa invece sulla violazione dei vincoli temporali:

• In un sistema hard real-time, un job non deve mai violare un vincolo temporale;
• In un sistema soft real-time un job può violare il vincolo temporale in certe condizioni.

In questo caso, il limite della definizione sta nel termine “mai” della definizione hard real-time, la quale corrisponderebbe a una probabilità dello 0%, che non è reale. Pertanto, la definizione effettivamente utilizzata si basa sul vincolo temporale di un job:

• Un vincolo temporale di un job è hard real-time (e di conseguenza anche il job) se è richiesta una validazione che tale vincolo temporale verrà sempre soddisfatto. La validazione è una dimostrazione matematica (oppure un’evidenza sperimentale prodotta tramite un numero esaustivo di test) la quale indica che in nessun possibile caso, le sequenze dei job che si alternano possono fallire e mancare le scadenze.
• Un vincolo temporale di un job è soft real-time se non è richiesta una validazione.

La validazione va effettuata in fase di progettazione del sistema: si effettua l’analisi dei rischi, si pensa alla safety security, alle implicazioni in casi di guasti, ecc.

I meccanismi per la riduzione dei rischi prevedono la definizione di vincoli temporali da rispettare, il rispetto dei vincoli temporali è la condizione per minimizzare i rischi.

2.1.5 Modello di riferimento per sistemi real-time

Occorre definire un modello per realizzare il sistema real-time a partire da un modello teorico. In un sistema hard real-time non è possibile pensare di costruire un sistema che sia il più veloce possibile, ma l’obiettivo reale è verificare se tale sistema rispetta o meno i vincoli temporali definiti, qualunque cosa accada. Non bisogna pensare di poter minimizzare i tempi di risposta, in quanto è un ragionamento che può essere fatto per un singolo task, ma per sistemi con molteplici task, questo introduce difficoltà al problema di far rispettare le scadenze.

Un sistema soft real-time ha dei vincoli in cui il rispetto della scadenza temporale di essi non è essenziale per validità del sistema, quindi è possibile ottimizzare altri parametri:

• Throughput;
• Tempi di risposta.

Si osservi inoltre che proprio per tali caratteristiche dei sistemi soft real-time, per essi i vincoli temporali sono spesso indicati in termini probabilistici (esempio: nel 95% dei casi si ha risposta entro 10 secondi, nel restante 5% dei casi ciò non avviene).

Ogni sistema real-time si può riassumere in 3 componenti:

• Modello del carico: è l’applicazione che il sistema deve supportare;
• Modello delle risorse: risorse del sistema a disposizione dell’applicazione;
• Algoritmi: descrivono come il sistema distribuisce le risorse nel tempo.

In questo modo è possibile catturare la complessità del sistema, omettendo però i dettagli di basso livello. Si osservi che più il modello è semplice, più i risultati ottenuti sono applicabili a modelli analoghi.

È possibile identificare 2 tipologie di risorse differenti:

• Risorse attive: anche dette server o processori (non per forza una CPU). Loro esempi sono: canali di comunicazione, dischi rigidi, computer, DB server, ecc.
• Risorse passive: sono ad esempio memorie, primitive di sincronizzazione, ecc.

Si osservi che una volta che la risorsa è assegnata al job, le sue caratteristiche non influenzano il tempo di esecuzione del job stesso.

Nel modellare un sistema, si indicano con le seguenti notazioni l’elenco dei processori p₁, p₂, ..., p_m e le risorse passive r₁, ..., r_j. Se la risorsa è così abbondante da non essere un problema (esempio: memoria, ovvero c’è sufficiente memoria per eseguire tutti i job), non ha senso inserirla nel modello; se invece non è così, allora ha senso modellarla.

I job all’interno del sistema si categorizzano in base ai vincoli temporali, ai parametri funzionali, alla dipendenza da altri job del sistema, uso delle risorse. L’istante di rilascio dei job si indicano con r_i per il job i-esimo, mentre la deadline (scadenza) è indicata con d_i. Tale istante di rilascio può anche non essere “preciso” ma avvenire in un intervallo del tipo: ±[ ] ∈ , Tale intervallo è detto jitter. La scadenza relativa è il tempo massimo che può intercorrere tra l’istante di rilascio del job ed il suo completamento, ovvero: D_i = d_i - r_i.

L’intervallo di fattibilità è indicato con (r_i, d_i], ovvero è l’intervallo di tempo che intercorre tra r_i e d_i. Molti sistemi real-time sono di tipo periodico (ovvero che presenta solo task periodici), ma in esso deve essere possibile poter gestire i task che arrivano in tempi casuali: quest’ultimi rendono problematico la pre-riservatezza delle risorse. Oltre ai task periodici, abbiamo altre due tipologie di task:

• Task aperiodici: in cui gli istanti di rilascio dei job sono casuali e non predefiniti;
• Task sporadici: gli istanti di rilascio dei job sono casuali, ma esiste un intervallo di tempo minimo tra il rilascio di due job.

Il tempo di esecuzione di un job J_i è l’ammontare di tempo necessario per il suo completamento quando sono disponibili tutte le risorse necessarie, quindi come se eseguisse isolato. Tale valore non dipende dal tipo di scheduling, ma da ciò che il job deve fare e dalle caratteristiche del processore che lo esegue.

Tutti i processori moderni hanno un comportamento non deterministico, ovvero non è possibile prevedere il tempo di esecuzione dei job in quanto questo dipende dallo stato interno del processore stesso. Da ciò segue che il tempo varia da esecuzione ad esecuzione, e quindi è possibile solamente individuare un intervallo: ±[ ] ∈ , Per rispettare le scadenze si considera il worst case: se il risultato è pronto in anticipo, è possibile far attendere il job, mentre se esso arriva in ritardo, bisogna pianificare adeguatamente.