Sistema operativo in tempo reale

I personal computer sono gestiti da un programma di base: il sistema operativo a condivisione di tempo (time sharing operating system, come DOS, Unix, etc.). Questo gestisce le risorse di sistema eseguendo le attività che gli vengono via via richieste, senza tener conto di correlazione tra esse: cambia l’attività da svolgere in base alle interruzioni (interrupts) richieste dal sistema. Si parla anche di sistema multitasking (esempio Windows Microsoft).

Un sistema operativo in tempo reale (RTOS, Azure Microsoft) è invece un sistema operativo per applicazioni che devono gestire dati ed eventi che hanno dei vincoli temporali definiti in modo accurato e che devono essere svolti in precisa sequenza temporale: tutte le elaborazioni devono avvenire entro tempi definiti e passano da un’attività all’altra in base alle priorità a loro assegnate.

Il sistema operativo ha due aree funzionali, dette Layer.

Il RTOS Layer è il nucleo (“core”) del sistema operativo in tempo reale. Intorno a tale RTOS vengono sviluppate tutta una serie di applicazioni specifiche per l’hardware/ firmware utilizzato (gestione ingressi/uscite, gestione linee di comunicazione seriali, gestione diagnostica, ridondanza, driver per le periferiche, etc.).

Il Runtime Layer è invece l’ambiente dove il codice dell’applicativo viene eseguito. Il programmatore dell’applicativo deve concentrarsi quindi solo sulla strategia del controllo da implementare e non deve occuparsi di tutto il resto.

Speedtronic Mark V IDOS

Per esemplificare, faremo una panoramica del sistema IDOS adottato nello Speedtronic Mark V, visto anche la particolare gestione del programma applicativo.

Segmenti

La strategia di controllo di un turbogas è generalmente tradotta dagli schemi di progetto al linguaggio specifico dell’ambiente di programmazione: nel caso del Mark V si utilizzava un software con interfaccia semigrafica.

Per ottimizzare la velocità di esecuzione era stata introdotta la suddivisione dell’applicativo in segmenti.

I segmenti erano sottoinsiemi della strategia di controllo contenenti blocchi funzionali e sequenze logiche, correlate tra di loro e che dovevano essere eseguiti con una certa cadenza temporale.

I singoli segmenti possono essere eseguiti a frequenze fisse ma diverse (4, 8, 16 o 32 Hz, a seconda dell’applicazione).

Ad esempio, il segmento relativo al controllo di temperatura allo scarico turbina veniva eseguito con una frequenza di 4 Hz: tale scelta è legata alle dinamiche in gioco, determinate dalla costante di tempo di risposta delle termocoppie che, come è noto, risulta essere di 3-4 secondi.

Invece, il segmento relativo al controllo di velocità di rotazione dell’albero turbina deve essere veloce (16-32 Hz), perché la dinamica della variazione di velocità è alta.

I segmenti erano eseguiti dal sistema operativo real-time seguendo l’ordine e le tempistiche imposto in fase di programmazione.

Skew

Per ottimizzare l’impiego del tempo macchina (microprocessore), i segmenti dovevano essere distribuiti opportunamente all’interno del tempo di ciclo. Si introdusse a tale scopo il concetto di slittamento o spostamento temporale (Skew). Lo skew è una “traslazione” temporale di alcuni processi rispetto

all’istante d’inizio del tempo di ciclo.

Questo, affinché la concentrazione di più task non possa determinare l’overflow del processore all’inizio del ciclo è, invece, una sottoutilizzazione dello stesso nella fase terminale del ciclo stesso.

Nell’esempio, il segmento 1 viene eseguito ogni 500 millisecondi e gli altri due segmenti ogni 250 ms. Se non si fosse introdotto uno skew di 85ms, i due task 2 e 3 avrebbero “caricato” la CPU all’inizio del ciclo. Invece, in questo modo, abbiamo ridotto del 33% il carico di lavoro iniziale.

Per questo particolare modo di gestione dei segmenti, era importante progettare la suddivisione della strategia di controllo in modo sequenziale: i risultati del segmento 1 potevano essere utilizzati nel segmento 2 e non viceversa, altrimenti si sarebbe ottenuto un sistema “equivalente” che “girava” con tempo di ciclo doppio. Inoltre, non potevano essere “mischiati” segmenti con tempo di ciclo differenti, altrimenti si sarebbe ottenuto un sistema “equivalente” che “girava” con tempo di ciclo pari al più lento.

Idle-time

Introduciamo ora un nuovo concetto: il tempo di inattività (“Idle time”). Questo è l’indice di inutilizzo del tempo macchina, ed è espresso in percentuale.

Esempio: IDOS IDLE TIME: 97.1%

Ogni applicativo utilizza una certa quantità di tempo di elaborazione. Quando il microprocessore ha completato tutte le attività diventa inattivo. Questo indice è importante per capire, in ogni ciclo di elaborazione, quante risorse sono state richieste dal programma applicativo al sistema di controllo.

Infatti, se vengono caricati programmi molto lunghi, si rischia di ridurre tale parametro. Nel caso di eventi inusuali, quali situazioni di blocco turbogas, in genere vengono attivate tutta una serie di sequenze “dormienti” che possono consumare una notevole quantità extra di risorse CPU e portare a zero lo Idle time.