Embedded

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

openOSEK

definisce 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.