![Show Menu](styles/mobile-menu.png)
![Page Background](./../common/page-substrates/page0065.png)
65
SO OPEN SOURCE |
software
EMBEDDED
56 • maggio • 2015
logie embedded a livello hardware e software. Se
tradizionalmente i sistemi embedded si doveva-
no dimensionare su un hardware con risorse li-
mitate di memoria e vari vincoli progettuali, oggi
non è più così, e i moderni SoC (system-on-chip)
sono abbastanza potenti, in termini di memoria
e velocità, per far girare SO più voluminosi e do-
tati di un ricco stack di middleware. Ed è pro-
prio questa dotazione software che oggi rende
possibile la realizzazione delle tecnologie di ulti-
ma generazione, in grado di fornire un’adeguata
connettività per le applicazioni IoT (Internet of
Things). Un altro fattore di stimolo per lo svi-
luppo del comparto open source è costituito dalla
crescente pressione competitiva esercitata sugli
OEM a differenziare i livelli dei propri stack sof-
tware, che li ha ulteriormente spinti all’adozione
del software con codice sorgente libero.
Come accennato, oggi gli ingegneri embedded
hanno davanti a sé un ampio panorama di scelte,
ma individuare il sistema operativo giusto dipen-
de da molti fattori, molti dei quali vanno poi a
condizionare il reale successo del progetto.
I criteri di valutazione di un SO open source em-
bedded sono molto diversi da quelli di selezione
dei sistemi licenziati commercialmente (vedi gra-
fico). Sempre da una survey di VDC risulta che
gli utenti open source valutano certi criteri molto
di più rispetto alle loro controparti indirizzate
sulle versioni commerciali. E le principali diffe-
renze di valutazione si misurano su fattori come
la disponibilità del codice sorgente, la presenza
di strumenti di sviluppo, ma anche la familiarità
dell’interfaccia di programmazione.
Costi primari intrascurabili,
attenzione al supporto tecnico
A prescindere dal fatto che il sistema operativo
venga acquisito da un fornitore di SO, da terze
parti di natura commerciale, o che venga svilup-
pato in-house, la voce di spesa relativa al sup-
porto tecnico si configura sempre come un costo
considerevole. E, osserva VDC, quando l’opzione
del supporto di lungo periodo offerto da un ISV
(independent software vendor) commerciale non
è una soluzione praticabile o giustificabile dal
budget del progetto o dalla roadmap, i team inge-
gneristici possono restringere la ricerca su un SO
open source che si affida all’esperienza di staff
di sviluppo che utilizzano differenti linguaggi di
programmazione, diverse piattaforme, strumen-
ti e ambienti IDE (integrated development envi-
ronment). Su questo punto in particolare, pro-
babilmente ciascuno ha già sperimentato, o può
constatare, quanto possa essere economicamente
costoso, e dispendioso anche in termini di tempo,
organizzare attività di formazione e training per
gli sviluppatori su nuove piattaforme e strumen-
ti di programmazione. Il prezzo da pagare si mi-
sura spesso in vari problemi durante lo sviluppo
del software, e in ritardi nel rispetto delle tabelle
di marcia, che poi si ripercuotono in un allunga-
mento del time-to-market.
Il suggerimento basilare, quando si decide di uti-
lizzare un nuovo SO open source per un progetto
embedded è quindi seguire il principio di partire
con un piano limitato, per consentire ai team di
sviluppo che non hanno familiarità con il softwa-
re di apprendere, eseguire test e fare esperienza.
In effetti, avverte VDC, buttarsi in un grande e
ambizioso progetto senza conoscere i potenziali
problemi, e le incompatibilità hardware e sof-
tware che si potranno incontrare, può esporre a
rischi davvero notevoli, soprattutto se i sistemi
richiedono di essere supportati e aggiornati lun-
go un ciclo di vita del prodotto molto esteso.
Più libertà nell’embedded,
con un framework aperto
Il nome
openOSEKdefinisce un framework
di sistema operativo cross-platform e open
source, che si propone di mantenere una com-
pleta conformità con la specifica (ISO17356)
derivata da OSEK/VDX. La ragione dell’esi-
stenza del progetto, secondo i fautori - pur in
un mercato costellato da diverse valide alter-
native open source, come FreeRTOS, o eCOS
– sta in alcune constatazioni, come il fatto che
la maggior parte di tali alternative siano abba-
stanza voluminose e con prestazioni real-time
non sufficienti; o che la API OSEK sia stata pro-
gettata da un consorzio di fornitori del settore
automotive. L’obiettivo dell’implementazione
openOSEK, in linea con i principi della filosofia
open source, è invece di fornire agli sviluppato-
ri maggior possibilità di scelta. Per tale ragio-
ne, tutti i componenti core di openOSEK sono
rilasciati sotto licenze GNU, con applicazioni e
librerie condivise basate su licenze GPL e LGPL.