Prima di discutere i problemi relativi allo sviluppo di sistemi real-time, dobbiamo definire esattamente cosa si intende per sistemi real-time e embedded. Sfortunatamente durante l'ultima decade il termine 'real-time' è stato usato in contesti molto ampi per riferirsi a qualsiasi sistema che non sia "batch".

Per cercare di essere specifici in questo documento alcune definizioni da una delle prime versioni del Dictionary of Computing (Oxford Science Publication, 1983) potrebbero rivelarsi utili:

sistemi real-time: tutti quei sistemi per i quali il tempo in cui vengono prodotte le uscite sia significativo. Questo è di solito perchè gli ingressi corrispondono ad alcuni eventi nel mondo fisico e le uscite devono avere una relazione con gli stessi eventi. Esempi di sistemi real-time sono: controlli di processo, sistemi di computer embedded e macchine di distribuzione automatiche.
sistema di computer embedded: tutti quei sistemi che usano un computer come componente, ma la cui funzione primaria non è quella di un computer. Un esempio è un sistema militare di guida.

Quando si misura il tempo nel quale viene prodotta un'uscita, noi normalmente mettiamo in relazione un evento di uscita al tempo nel quale un particolare evento di ingresso è stato ricevuto dal sistema. Per i sistemi real-time questa risposta ingresso-uscita è un requisito del sistema chiaramente identificato. Questo è fondamentalmente ciò che distingue i sistemi IT (Information Technology) dal real-time; i requisiti temporali e quindi di prestazioni hanno la stessa importanza dei requisiti funzionali. Pertanto nel real-time non dobbiamo soltanto eseguire le funzioni corrette, ma ci sono dei chiari limiti temporali entro i quali queste devono essere completate. Si può riassumere questo concetto dicendo:

"La risposta giusta, se arriva in ritardo, è sbagliata"

Quando si specifica la risposta di un sistema generalmente si assume una risposta ingresso-verso-uscita. Tuttavia ci sono quattro possibili misure di risposta:

Ingresso-verso-Uscita: esempio - Rilevazione minaccia per lancio missile
Uscita-verso-Uscita: esempio - Sequenza di un semaforo
Ingresso-verso-Ingresso: esempio - Time-out su una serie di pressioni di tasti
Uscita-verso-Ingresso: esempio - Visualizzazione d'informazioni alla risposta dell'operatore

Inoltre i requisiti temporali possono essere per un tempo minimo e uno massimo. Ad esempio possiamo specificare che il tempo massimo tra la rilevazione della minaccia e il lancio del missile sia di 110 secondi al massimo. Alternativamente, nel caso del semaforo, potremmo specificare che il cambio dello stato avvenga con un tempo monimo di due secondi.

A causa dell'uso (o abuso) della frase real-time, sono state proposte categorie ulteriori. Una documentata è [cooling91]:

Questa tabella usa due categorie per la classificazione:

Velocità della risposta
Criticità della risposta

Rispetto alla velocità della risposta, possiamo classificare i sistemi come veloci o lenti. Bisogna capire che non c'è una netta separazione tra sistemi veloci e lenti. Come classificazione empirica, i sistemi con risposte inferiori al secondo si possono certamente considerare veloci, mentre i sistemi con tempi di risposta misurabili in minuti si possono considerare lenti (lasciando così un'area d'incertezza dell'ordine dei secondi).

Quando si tratta di criticità della risposta si può tracciare una linea molto più chiara tra i sistemi. La definizione data sopra per il real-time era "tutti i sistemi per i quali il tempo al quale le uscite sono prodotte sia significativo."

Un sistema è "hard real-time" quando il tempo di risposta (massimo o minimo) è specificato come valore assoluto. Se questa condizione di risposta non fosse soddisfatta, il sistema deve essere considerato in errore. Nella condizione di errore, il sistema deve effettuare una qualche procedura di recupero dell'errore: continuare con funzionalità ridotte o spegnersi. in casi più estremi questo può portare al danneggiamento o alla perdita dell'apparato e, peggio di tutto, a perdita di vite umane.

È da notare che hard real-time non significa necessariamente veloce (il che è un'assunzione molto comune). Prendete per esempio il controllo di una centrale nucleare. Certi eventi possono impiegare molti minuti o ore prima di diventare critici. Tuttavia c'è un limite temporale assoluto entro il quale deve essere attivata una risposta, altrimenti potrebbero verificarsi delle serie conseguenze. Inoltre hard real-time non significa necessariamente critico per quanto riguarda la sicurezza (un'altra assunzione comune). Il controllo di processo di un laminatoio continuo per l'acciaio è eseguito entro un periodo di tempo definito dopo che il materiale ferroso fuso si è formato. Se non vengono rispettati i tempi prestabiliti, le lastre s'induriscono, rendendo impossibile la laminazione.

Un sistema soft real-time (chiamato anche near real-time) è un sistema dove il tempo di risposta è normalmente un valore medio. Pertanto per ogni risposta c'è una gamma di valori accettabili, per cui la risposta può arrivare in ritardo senza che il sistema venga considerato in errore. Tuttavia se questa risposta non dovesse essere soddisfatta in un certo periodo di tempo (il periodo di campionamento - che può essere di secondi, minuti, ore, giorni, settimane, ecc) allora il sistema potrebbe essere considerato in errore, non adeguato all'operatività (idealmente associato con qualche penalità finanziaria) o non competitivo. Prendete il più quotato esempio di sistema real-time delle società di strumenti CASE: ATM (Automated Teller Machine, lo sportello automatico per la distribuzione di banconote). Il sistema, mediamente, deve avere un tempo di risposta accettabile per l'utente, altrimenti sarà considerato non affidabile e porterà all'insoddisfazione della clientela. Ma data una transazione qualsiasi con un cliente, non ci sono problemi se la risposta è del 10%, 25% o addirittura 50% più lenta delle specifiche. Se questo livello di risposta persistesse, allora naturalmente gli utenti protesterebbero. L'ATM è un esempio di sistema soft real-time lento. Possiamo anche avere sistemi soft real-time molto veloci. Un sistema di video conferenza deve visualizzare lo schermo con un'alta frequenza di aggiornamento delle immagini. Se fallisce sistematicamente di soddisfare la frequenza di aggiornamento delle immagini, il sistema non è ovviamente usabile. Se tuttavia l'anomalia avviene di tanto in tanto, non è un grosso problema, purché il sistema mantenga una connessione affidabile.

Per riassumere:

Un sistema è hard real-time quando il tempo di risposta è specificato come valore assoluto. Questo tempo è normalmente dettato dall'ambiente.

Un sistema è soft real-time quando il tempo di risposta è normalmente specificato come valore medio. Questo tempo è normalmente dettato dagli aspetti commerciali o dal mercato.

Pagina Precedente Pagina Successiva