In questo articolo vedremo quali sono le ragioni che inducono alla scelta di un sistema real time ed i criteri di scelta del giusto prodotto.
Figura 1: La dimensione del foot print di alcuni noti sistemi operativi
L’uso di un sistema operativo real-time in un sistema dedicato non sempre è giustificato. Una grossa fetta delle applicazioni commerciali non utilizzano un sistema operativo, ma si basano su un modello ciclico basato anche su evento. In questo articolo si vogliono dare indicazioni di massima sulle ragioni che possono decidere l’acquisto di un kernel real-time. Il firmware potrebbe essere semplicemente un ciclo software principale dove all’interno trovano posto diverse funzioni: il tempo di CPU viene così diviso in maniera paritaria, infatti, non ci sono funzioni più prioritarie a meno di un evento asincrono. Un approccio di questo tipo può rappresentare la scelta ideale per diverse applicazioni, una decisione suggerita anche da ragioni economiche. Quali sono i motivi che possono dare un contributo decisivo per l’acquisito di un kernel real-time? Vediamo le possibili ragioni economiche e tecniche:
ECONOMICHE
• Il costo, tra royalty e licenze, di un sistema operativo è abbastanza alto. Se, poi, per ragioni di progetto non possiamo utilizzare un sistema leggero, il costo può diventare insostenibile perché possono essere introdotti, in ogni caso, dei costi fissi.
• Utilizzare un sistema operativo vuol dire che occorre dotarsi di sistemi di test mirati e spesso anche costosi.
• Se il sistema operativo viene modificato, anche in parte, chi risponde della bontà delle modifiche stesse? È necessario coinvolgere gruppi terzi per verificare le modifiche? E se il sistema operativo aderisce a uno standard, chi certifica che la modifica non pregiudica l’aderenza alle normative in uso? A questo punto si possono innescare processi di verifica a volte anche costosi.
TECNICHE
• Test. L’uso di un sistema operativo introduce, da un punto di vista tecnico, nuove problematiche: chi garantisce che il sistema operativo sopperisce alle sue funzionalità? In questo caso occorre studiare e mettere a punto dei test mirati.
• Codice ombra. L’uso di primitive del sistema operativo introduce potenzialmente un altro problema: se c’è un malfunzionamento e questo coinvolge anche funzioni di libreria, le eventuali indagini risultano abbastanza difficili perché è necessario considerare queste funzioni chiamate ombra.
• Supporto. Il costruttore di un sistema embedded, una volta terminato il suo ciclo di sviluppo, deve approntare politiche di marketing per vendere il frutto del suo lavoro, ma deve anche garantire il supporto tecnico agli eventuali compratori e quindi anche, indirettamente, sul sistema operativo che è parte della sua applicazione. Accanto a queste considerazioni che sembrano sconsigliare l’uso di un sistema operativo, ne esistono altre che ne sollecitano il loro utilizzo.
Le ragioni che sostengono l’uso di un sistema di questo tipo possono riguardare i seguenti argomenti:
Uso di librerie
L’uso di un sistema operativo permette di utilizzare una serie di librerie sufficientemente standardizzate e testate, questo permette la portabilità delle nostre applicazioni.
Safety del codice
Un sistema operativo mette a disposizione il concetto di stratificazione delle chiamate: il software applicativo può interagire con i dispositivi fisici non più direttamente ma in maniera mediata secondo un meccanismo già consolidato e testato. Il sistema operativo può mediare attraverso l’uso di metodi tra i diversi strati, per esempio per mezzo di primitive di sincronizzazione per l’accesso alle risorse condivise e attraverso la notifica degli eventi sincroni o asincroni.
Documentazione
Acquistare un sistema operativo vuol dire ottenere un prodotto sufficientemente testato e documentato. Un insieme di librerie con descrizioni tecniche corredato da esempi d’uso.
Manutenzione/sviluppo
Utilizzare un sistema operativo permette di adoperare concetti quali la modularità. In questo caso diventa più facile pianificare attività suddivise in macro funzioni adoperando le primitive messe a disposizione del sistema.
LA SCELTA DI UN SISTEMA OPERATIVO: ASPETTI TECNICI
Per fare una scelta obiettiva sulle diverse proposte tecniche, l’utilizzatore diretto del sistema non dirige la sua scelta sulla base delle argomentazioni commerciali, ma si dedica all’esame degli aspetti più spiccatamente tecnici. La domanda che deve porsi è quali sono le prerogative di questo sistema operativo. Qual è la sua occupazione di memoria? Il supporto tecnico è efficiente? Quale algoritmo di schedulazione implementa? In seguito si è fatto un piccolo riassunto delle caratteristiche che deve avere un sistema di questo tipo.
Il foot print, termine che vuole indicare l’occupazione di risorse richieste, è un aspetto non secondario da tenere presente nella scelta di un sistema operativo embedded. Il foot print che il tecnico utilizza dipende, in maniera diretta, dalla quantità di memoria disponibile. La quantità di memoria incide direttamente sul numero dei processi consentiti, infatti, se utilizziamo LynxOS un processo occupa 1073 bytes, mentre con ThreadX circa 200 bytes. In Figura 1 il foot print di alcuni sistemi operativi. In ogni caso le prerogative che deve avere un generico sistema operativo sono riassunte in questo modo: Schedulatore, Politiche di gestione delle risorse condivise, Meccanismi di sincronizzazione, Board Support Package (BSP), Timers, Standard, Meccanismi di comunicazione, Gestione della memoria, Memory Protection, Moduli aggiuntivi (stack di protocollo e interfacce grafiche), Moduli aggiuntivi: strategie di debug. Eccoli di seguito in dettaglio.
Schedulatore
Nella maggior parte dei sistemi operativi commerciali o anche open, l’algoritmo di schedulazione è di tipo a priorità. È un algoritmo abbastanza semplice perché ogni task deve avere una priorità diversa. Altri sistemi operativi permettono di condividere la stessa priorità, suddividendo equamente il tempo di CPU tra i task ad uguale priorità mediante un meccanismo chiamato scheduling round robin cooperativo, in questo modo è il processo stesso che deve rilasciare la CPU, o attraverso il meccanismo round robin con prelazione, in questo caso il processo viene forzato a rilasciare la CPU a seguito di un evento asincrono o per il raggiungimento di un numero prestabilito di time slices, o ancora per l’esaurimento del tempo allocato al task per la sua esecuzione (time budget). Esistono poi altre considerazioni da tenere presenti:
• politiche in tempo e spazio, in questo caso è applicabile lo standard di riferimento ARINC-653 dove si prevede uno schedulatore che gestisce le partizioni in tempo e spazio, le partizioni in spazio utilizzano le prerogative di un MMU;
• altri prevedono delle code di priorità di tipo FIFO e Round-Robin;
• esistono poi meccanismi per risolvere il problema dell’inversione di priorità, questi si basano su priority inheritance e priority ceiling.
Politiche di gestione delle risorse condivise
Un sistema operativo che si rispetti deve prevedere algoritmi e servizi che permettono di garantire l’accesso esclusivo alle risorse del sistema. Meccanismi di sincronizzazione: un sistema operativo deve prevedere, per esempio, interfacce software per sincronizzare i processi sulla base di determinati eventi in maniera sincrona o asincrona.
BOARD SUPPORT PACKAGE (BSP)
Sono moduli software che permettono di portare il sistema operativo su differenti architetture. Di solito insieme al BSP è fornito anche un bootloader che ha lo scopo di predisporre una scheda per caricare il sistema operativo, il bootloader è costruito su schede standard e in ogni caso è necessario fare un opportuno lavoro di adattamento per schede specifiche. Timers: servizi che permettono al programmatore di sospendere un task per un determinato quanto di tempo, allo scadere di questo slot temporale il sistema operativo deve rimettere in esecuzione il processo, sempre secondo le politiche di schedulazione in uso. Standard: esistono diversi standard che un produttore deve seguire per rispondere a determinati requisiti di certificabilità.
Esistono per esempio standard quali ARINC-653, DO-178B, ED-12B, DO-254, ED-80, DO-278. Lo standard ARINC-653 è certamente uno dei più citati e interessanti. Il sistema operativo Valid-653™ è una implementazione dello standard ARIC-653 con l’interfaccia APEX (Application/EXecutive) per Integrated Modular Avionics (IMA) systems ed altre applicazioni che vengono definite safety-critical environments. Il sistema Valid-653™ è anche una implementazione nativa dell’ARINC-653 e non richiede nessun’altro sistema operativo. Utilizzando la semantica dello standard ARINC-653, questo sistema operativo implementa il concetto di partizioni sia in tempo che in spazio. Le divisioni delle partizioni in spazio sono garantite mediante l’uso dell'MMU, ad ogni partizione è garantito uno slot di esecuzione definito dal sistema. I threads di ciascuna partizione sono schedulati sulla base della politica priorità preemptive.
MECCANISMI DI COMUNICAZIONE
Ogni sistema operativo fornisce delle primitive per permettere la comunicazione tra processi, parliamo di IPC, mailbox, queue e pipe. Le interfacce di questi meccanismi o sono proprietarie o aderiscono a uno standard, di solito per queste si tenta di seguire lo standard Posix. L’adesione ad uno standard implica anche definire interfacce particolari, per esempio se si aderisce allo standard DO-178B, magari level B, vuol dire che il programmatore non potrà utilizzare strutture dinamiche ma solo statiche. Particolare attenzione va data nella definizione delle strutture, per esempio le interfacce possono anche essere utilizzate sotto interrupt? Se la risposta fosse positiva, allora sarà necessario pensare a politiche di protezione dei dati.
GESTIONE DELLA MEMORIA
A seconda del sistema operativo, possono esserci soluzioni basate sull’allocazione dinamica o statica della memoria. Un sistema dedicato ha, per definizione, poca memoria. Nei sistemi dedicati e, per maggior ragione, in relazione agli standard Do-178B la primitiva malloc non viene utilizzata perché si preferisce utilizzare delle politiche di allocazione statica della memoria. Diversi sistemi operativi, tra cui TNKernel, utilizzano un altro meccanismo, chiamato fixed-sized memory pool. Questa è una particolare gestione che consente l’uso di partizioni fisse di memoria utilizzate in maniera dinamica. In un sistema di questo tipo si dispone di un’area di memoria dove i blocchi, di dimensioni fisse, sono disponibili per essere allocati. Se un processo non ottiene un blocco di memoria allora questo è posto in una coda in attesa del blocco richiesto. Ogni sistema che implementa una politica di questo tipo mette a disposizione un insieme di primitive, a titolo d’esempio la Tabella 1 mostra quali interfacce rende disponibile TNKernel.
Tabella 1: Fixed-sized memory pool functions (TNKernel)
MEMORY PROTECTION
Un sistema operativo real-time di solito fornisce una completa protezione di memoria per i task utente, sfruttando i meccanismi hardware di memory protection, mediante l’utilizzo di una MMU, ad esempio. Per questo, un sistema operativo può garantire il Secure memory protected operation, Secure tasks, Secure interprocess communication e il Secure device drivers. In definitiva può fornire un sistema di protezione per l’accesso a moduli specifici senza che un errore possa pregiudicare l’esecuzione dell’intero sistema.
MODULI AGGIUNTIVI: STACK DI PROTOCOLLO E INTERFACCE GRAFICHE
Un produttore di un sistema operativo è in grado di offrire una serie di moduli opzionali e aggiuntivi che consentono di gestire in maniera integrata, per esempio, le seguenti funzioni:
• Stack di protocollo TCP/IP, comprensivo di Web Server e Web Browser;
• Protocolli ATM, SS7, ISDN, X.25, V5, Frame Relay;
• Interfaccia grafica PEG con driver per svariati LCD e Video controller;
• File System;
• Moduli per la gestione degli errori e strategie di recovery;
• Shell di comando, come VxWorks.
MODULI AGGIUNTIVI: STRATEGIE DI DEBUG
Da diversi anni i produttori di sistemi operativi non si limitano più a fornire lo strato del kernel, ma offrono anche soluzioni integrate di debug e di compilazione, come l’IDE AdaMulti della Green Hills. Queste offerte includono:
• possibilità di debuggare più tasks attraverso diversi AddressSpaces, in un sistema multiprocessore (ogni task nella propria finestra di debug);
• possibilità di creare ed aprire una nuova finestra di debug, contestualmente alla creazione di un nuovo task;
• possibilità di debug multi-task sia tramite ethernet che seriale per la maggior parte delle schede esistenti; possibilità di visualizzare il tempo di esecuzione relativo di tutti i task (incluso il task “idle”);
• possibilità di monitorare lo stato delle variabili in real-time con la possibilità di associare delle azioni ad una certa occorrenza. È chiaro che soluzioni di questo tipo sono certamente utili, ma fanno comunque lievitare il prezzo del prodotto: sono da valutare attentamente.
LA SCELTA DI UN SISTEMA OPERATIVO: ASPETTI COMMERCIALI
Quando si valuta l’uso di un sistema operativo per una applicazione dedicata, occorre tenere presente diversi aspetti, da considerazioni commerciali a quelle tecniche. Le scelte disponibili possono anche non essere mutuamente esclusive, nel senso che i produttori possono prevedere formule commerciali che prevedono royalty e anche licenze particolari. In questo caso, di solito, si formula un accordo di massima (a volte è chiamato accordo quadro) tra l’utilizzatore e il produttore del sistema operativo:
• royalties, per ogni singolo oggetto venduto contenente il binario del sistema operativo, di solito il produttore richiede una somma di denaro da corrispondere per l’uso del sistema stesso: il produttore detiene i diritti sul sistema operativo e questo viene di solito indicato con il termine di royalty;
• costi per le licenze per prodotto o linea di prodotti. Oggi quasi tutti i costruttori di sistemi operativi hanno abbandonato l’uso delle royalty, queste sono state sostituite dalle licenze. La licenza è, banalizzando, il riconoscimento del produttore per l’uso del binario del sistema operativo in un numero imprecisato di oggetti dello stesso tipo, prodotto, o di tipo leggermente diverso, linea di prodotti. Chiaramente la licenza è molto elevata se gli oggetti sono pochi e, al contrario, è bassa su grossi quantitativi;
• costi per le licenze per postazioni di lavoro aggiuntive. Sotto questa denominazione si identifica un altro accordo commerciale. Può capitare che il produttore richieda una licenza per ogni programmatore, o gruppi di programmatori, per utilizzare il prodotto per lo sviluppo di un progetto. Può essere applicabile sia il formato binario o anche il codice sorgente: in questo caso il costo aumenta notevolmente;
• costi per le licenze del codice sorgente. Il produttore può, a fronte di un accordo commerciale, fornire il codice sorgente per modifiche anche parziali del sistema dietro particolari requisiti imposti dal progetto. Il costo di una simile licenza è molto alto e non è comparabile con quella binaria, chiaramente una scelta di questo tipo è obbligatoria se esistono particolari requisiti o vincoli di progetto;
• ogni produttore non si limita a fornire un kernel real-time ma offre soluzioni. Ogni soluzione che propone risponde a una determinata esigenza, così può offrire ambienti integrati di compilazione e debug o anche moduli aggiuntivi quali file system: insomma, sono sistemi altamente scalabili. È chiaro che il costo di un ambiente è direttamente proporzionale alle soluzioni che il cliente richiede;
• Standard. L’aderenza ad uno standard di un sistema operativo fa certamente lievitare il costo. Ma questo tipo di scelta non dipende unicamente dalle singole valutazioni discrezionali, ma occorre anche verificare le reali esigenze del programma.
CARATTERISTICHE DI ALCUNI RTOS
Vediamo le caratteristiche di quattro sistemi operativi che occupano una posizione di mercato non indifferente, sia da un punto di vista commerciale e sia nel mondo open. Questo elenco non vuole assolutamente privilegiare nessuno, se alcune informazioni sono assenti è perché non si sono ottenuti dei riferimenti espliciti dai distributori o dal sito del produttore.
FreeRtos
È un sistema operativo Open Source, portabile, il codice sorgente è disponibile liberamente e non ci sono royalty da conferire ed è corredato da un mini real time scheduler. La fascia di mercato è quella dei piccoli microcontrollori. Scritto in C con parti in assembler, il kernel è abbastanza facile da modificare per portarlo su altre architetture poiché dispone di molte informazioni tecniche sul sito di riferimento. Il suo foot print è abbastanza contenuto ed è rivolto all’essenziale. Ci sono poi diversi BSP disponibili. Il tipo di schedulazione adottata è basata sulla priorità.
VXWorks
VxWorks è parte integrante di Tornado®, un IDE per piattaforme embedded. Questo RTOS è uno dei sistemi operativi più utilizzati nel settore industriale. Tornado ® comprende una serie di strumenti di sviluppo, quali compilatori e utilities. VxWorks è poi estremamente flessibile e dispone di più di 1800 interfacce (API) che consentono al programmatore di rapportarsi in maniera efficiente con i moduli hardware e software integrati con Tornado®. È disponibile per una varietà di microprocessori ed è utilizzato anche per applicazioni critiche. Garantisce il supporto verso queste interfacce di rete: TCP/IP, FTP, SMTP, NFS, PPP, RPC, Telnet, BSD 4.4 TCP/IP networking, IP, IGMP, CIDR, TCP, UDP, ARP, RIP v.1/v.2, Standard Berkeley sockets, zbufs (a.k.a., zero- copy sockets), SLIP, CSLIP, BOOTP, DNS, DHCP, TFTP, NFS, ONC RPC, WindNet SNMP v.1/v.2c with MIB compiler - optional, WindNet OSPF. Sono disponibili diversi BSP per vari microprocessori e schede commerciali. VxWorks garantisce, attraverso sue varianti, la sua adesione a varie normative di riferimento, quale DO-178B e ARINC-653.
Integrity
Elemento di punta della GHS è stato costruito sul microkernel velOSity. Studiato e realizzato per applicazioni per ricavare la massima reliability del sistema. Integrity è disponibile per le architetture PowerPc e MIPS, utilizza il dispositivo MMU per creare partizioni in spazio e in tempo, fornisce un partition scheduling secondo la specifica ARINC-653. Il sistema operativo fornisce interfacce POSIX e proprietarie per utilizzare i servizi di sistema. È possibile la creazione di task in diversi linguaggi quali C, C++ e Ada. Permette il dynamic download dei task e fornisce un analizzatore degli eventi in tempo reale. In debug permette di mettere dei breakpoint su un task specifico e garantisce il Run-time error control che consiste in eccezioni applicative in caso di accesso errato alla memoria o al superamento dello stack di task. Lo scheduler supporta livelli di priorità multiple che garantiscono percentuali fissate di tempo di CPU all’interno di ogni livello di priorità. Per applicazioni che non richiedono memoria protetta e necessitano di un foot print minimo e massima efficienza, Integrity può essere usato in kernel mode. In questo modo, Integrity offre un foot print più piccolo e kernel services più veloci.
LynxOS
LynxOS è un sistema operativo realizzato per il mondo real-time. È conforme a POSIX e UNIXcompatibile. LynxOS è un sistema multiprocesso e multithread progettato per applicazioni complesse per il mondo real-time in grado di rispondere agli stimoli in maniera rapida e deterministica. LynxOS aderisce a diversi standard: è conforme a POSIX 1003.1 e, per la parte real-time, alla normativa 1003.1b e 1003.1c per le estensioni thread. LynxOS è il risultato di un design modulare, questo rende il sistema scalabile e configurabile. Il sistema operativo include le interfacce di sistema di 4.4 BSD e le librerie. Le caratteristiche di LynxOS sono riassunte in Tabella 2.
Tabella 2: Le caratteristiche di LynxOS
ThreadX
È un sistema operativo studiato e realizzato per applicazioni di diverse dimensioni, è real-time ed è esente da royalty. Le sue caratteristiche sono così riassunte:
• Architettura micro-kernel scalare, da 10-15 kb;
• Context switch ridotto;
• Il codice sorgente viene fornito;
• È integrato con un sistema di sviluppo;
• Le interfacce non sono legate al particolare target in uso e questo permette di portare le applicazioni su differenti soluzioni;
• Esiste la possibilità, secondo ciascuna esigenza, di utilizzare moduli aggiuntivi, quali: stack di protocollo, File System, interfaccia grafica PEG con driver per svariati LCD e Video controller. Le caratteristiche sono riassunte in Tabella 3.
Tabella 3: Le caratteristiche di ThreadX
CONCLUSIONI
Da quanto esposto è possibile rendersi conto dell’enorme varietà delle opzioni disponibili. Decidere di acquistare un sistema operativo non è una scelta semplice, ma occorre vagliare ogni aspetto per decidere non in base alle sole considerazioni economiche, ma anche alle reali esigenze del programma.
