Il proliferare del software nella gestione degli autoveicoli ha creato una forte esigenza di standardizzazione e regolamentazione delle loro procedure di progettazione e realizzazione. Da questa esigenza nasce AUTOSAR (AUTomotive Open System Architecture). In questo articolo verranno descritte le caratteristiche principali dello standard AUTOSAR e di alcune sue implementazioni.

La piattaforma AUTOSAR nasce dall’attività dell’omonimo consorzio nato nel 2003 da un gruppo di importanti attori nel panorama automobilistico (BMW Group, DaimlerChrysler, Volkswagen, Bosch, Continental e Siemens VDO). Le realtà industriali che da allora si sono associate al consorzio sono tantissime, a riprova della comune necessità di una regolamentazione del settore e anche a onore della incessante attività svolta dal consorzio. Quanto messo a punto, negli anni, è una architettura software che permette di coniugare le necessità e gli interessi dei produttori di autoveicoli e dei produttori di hardware e software utilizzati nel settore automotive.

Lo standard AUTOSAR (figura 1 e 2) permette la gestione standardizzata delle funzionalità dell’intero “sistema autoveicolo” semplificando la scalabilità delle performances, la migrazione verso diversi ambienti operativi (altri veicoli o altre piattaforme), la collaborazione allo stesso progetto di più fornitori specializzati, la gestione dei canali di comunicazione presenti sul veicolo e la manutenibilità del prodotto per l’intero ciclo di vita.

Figura 1: struttura base.

La Storia

Il consorzio, nato da una volontà quasi esclusivamente teutonica, si è espanso raccogliendo sempre maggiori consensi e coinvolgendo oggi, oltre ai membri fondatori, Ford, General Motors, PSA Peugeot, Citroën, Toyota e Volkswagen Group, anche altre 160 realtà industriali che partecipano in modo fondamentale allo sviluppo ed alla definizione della piattaforma. Quello che però è interessante sottolineare è la crescente accettazione dello standard presso costruttori e fornitori che permette oggi di dire che l’80% delle auto commercializzate nel mondo sono costruite da membri del consorzio AUTOSAR.

Figura 2: struttura dei componenti e delle interfacce AUTOSAR.

Struttura generale della piattaforma

AUTOSAR nasce per integrare le  caratteristiche suddette, per agevolare lo sviluppo di software di gestione dell’autoveicolo ma anche per la gestione di tutti i servizi che i produttori devono offrire a un utente sempre più evoluto ed esigente. Sono infatti contemplati anche aspetti quali il rispetto dell’ambiente (con riduzione dei consumi) e i sistemi di sicurezza, il comfort e l’intrattenimento dei passeggeri, l’assistenza alla guida e una particolare attenzione alla sicurezza in ambienti ad alta densità di traffico. La caratteristica principale di AUTOSAR è però quella di offrire una piattaforma di sviluppo del software che permette di “astrarre” dal contesto hardware in cui il software dovrà funzionare e quindi di massimizzare la possibilità di utilizzo su veicoli e strutture diverse. Inoltre, come immaginabile, il riutilizzo di codice verificato a fondo aumenta, oltre che l’efficienza produttiva, anche la sicurezza intrinseca del sistema. È ovvio che se, per ipotesi, il processo di astrazione potesse riguardare tutti i dispositivi di un autoveicolo, si potrebbero equipaggiare molti tipi di vetture con lo stesso software di gestione semplicemente configurandone alcune performances. È a questo limite teorico che AUTOSAR e i membri del consorzio tendono. Altro fronte sul quale AUTOSAR promette benefici è quello della qualità del software, che sta diventando un aspetto dalle dimensioni ragguardevoli in un contesto in cui sono sempre più richieste certificazioni secondo lo standard automotive Spice (ISO/IEC 15504) o Cmmi (Capability Maturity Model Integration).

Figura 3: Dettaglio ECU e bus virtuale.

Principali caratteristiche

Le funzioni per le quali AUTOSAR rappresenta una risorsa innovativa e pressoché unica al mondo sono:

• l’implementazione e standardizzazione delle funzioni basilari di un sistema intese come un “Core Standard” adatto a diverse applicazioni OEM;
• il trasferimento di funzioni attraverso la rete presente sul veicolo;
• la scalabilità verso differenti veicoli e varianti di piattaforma;
• la definizione di funzioni generiche implementate indifferentemente su supporti prodotti da fornitori diversi;
• attivazione di ridondanze per garantire maggiore sicurezza;
• manutenibilità del progetto lungo tutta la vita del prodotto;
• incremento dell’utilizzo di hardware “standard” ovvero facilmente reperibile sul mercato;
• gestione dell’aggiornamento del software veicolo lungo tutta la vita del prodotto.

Tutti questi punti sono perseguiti implementando una metodologia automatizzata che parte dalla definizione di un modello del sistema, passa alla definizione delle proprietà e delle funzioni comprendendo la topologia delle risorse hardware per poi avere come prodotto finale l’eseguibile da caricare sulle varie ECU del sistema (figura 3). In questo modo AUTOSAR permette di evitare di strutturare il software di gestione usando il comune approccio basato sulle risorse fisiche (ECU based) e di passare invece a un approccio basato sulle funzioni da implementare (function based). AUTOSAR prevede, durante la definizione del modello del “sistema veicolo”, l’uso di componenti software interconnessi mediante un componente virtuale definito Virtual Function Bus. I componenti software sono i particolari più piccoli nei quali l’applicazione può essere suddivisa. Le interfacce standard di questi componenti software sono descritti dagli standard AUTOSAR. Rispettando le interfacce definite dallo standard, è comunque possibile definire liberamente le funzionalità di un componente. Il bus virtuale di interconnessione tra i componenti rappresenta tutti i servizi di interconnessione presenti nel sistema veicolo e consente al progettista di focalizzare l’attenzione sulla applicazione anziché sulle caratteristiche delle infrastrutture. L’uscita di un componente è così disponibile per l’ingresso del componente che deve farne uso senza che occorra definire quale sia la sorgente e la destinazione dei dati scambiati. Ovviamente AUTOSAR definisce per ogni componente software le porte di ingresso e di uscita e il formato dei dati scambiati, in modo da rendere trasparente (ed esente da errori) tutta questa parte dell’attività. Vantaggio non trascurabile di questo approccio è la possibilità di verificare tutte le interazioni tra i componenti ancor prima di aver definito il comportamento del software di gestione del sistema. Una modellizzazione di questo tipo consente anche una semplificazione enorme nell’eventualità che si debbano apportare modifiche al software di gestione.

Figura 4: schermata Basic Software Builder.

Architettura del software

La struttura basata sui componenti software di AUTOSAR utilizza un’architettura a strati (layer) per svincolare le funzionalità dall’hardware e dai servizi software che le supporteranno nella realtà del sistema.

• Basic Software Layer: questo strato non ha altre funzionalità specifiche oltre a quella di rendere lo strato superiore (Runtime Environment) indipendente dal hardware del sistema. Questa funzione è realizzata mediante specifiche API. Ovviamente questo strato è dipendente dall’hardware del sistema.(Runtime Environment) indipendente dal hardware del sistema. Questa funzione è realizzata mediante specifiche API. Ovviamente questo strato è dipendente dall’hardware del sistema.
• Runtime Environment: gestisce lo scambio dei dati tra i componenti software e le connessioni tra l’applicazione, l’hardware del sistema e i vari componenti software.
• Application layer: questo è l’unico strato non composto da software standardizzato in quanto è quello in cui risiede l’applicazione. Questo approccio basato su funzionalità software permette di definire il “sistema veicolo” senza pensare alle ECU e addirittura ignorando se due componenti software dei quali si definiranno poi le caratteristiche si troveranno sulla stessa ECU oppure no. Sarà cura degli strati “bassi” del software connettere i componenti e garantire il loro accesso alle risorse hardware. La sequenza delle operazioni utilizzate per la definizione del “sistema veicolo” in tutte le sue componenti è riassumibile nei seguenti passi.

Nella release 4.0 è stato introdotto il supporto alle piattaforme con processore multicore nelle quali, per garantire la corretta esecuzione dei tasks ma per non abbandonare la filosofia “distributiva” di AUTOSAR, si ricorre a un un attento uso di code e spinlocks.

Figura 5: i Solar di BOSCH.

Descrizione Ingressi

La descrizione degli ingressi si può dividere in tre sezioni: la prima è la descrizione formale dei componenti software (indipendente dalla implementazione del componente software stesso), dei quali vengono specificate le interfacce e i requisiti hardware. Segue poi la descrizione della topologia del sistema (interconnessione tra le varie ECU) descritta congiuntamente ai bus dati disponibili, ai protocolli usati, al clustering di funzioni e alle caratteristiche specifiche dei dispositivi quali la velocità dei bus, tempistiche, latenze etc. Occorre poi definire la struttura hardware del sistema (processori, attuatori, sensori) ed eventuali particolarità sul processamento dei segnali e sulla programmabilità dei dispositivi.

Figura 6: esempi di applicazione AUTOSAR di Magneti Marelli.

Figura 7: Fiat 500 con AUTOSAR implementato da Magneti Marelli.

Configurazione del sistema

In questa fase i componenti software vengono attribuiti alle varie ECU mediante un processo iterativo che deve tenere conto delle risorse a disposizione e dei limiti del sistema (ad esempio se le velocità di comunicazione permettono la suddivisione di un componente software su due ECU differenti e così via).

Configurazione ECU

In questa fase vengono configurati gli strati Basic Software e Runtime Environment di ogni ECU. Ovviamente questa configurazione viene stabilita in base alla assegnazione dei componenti SW ad ogni ECU.

Generazione degli eseguibili

A questo punto è possibile la generazione degli eseguibili per ogni ECU. Ovviamente è necessario definire anche il comportamento specifico di ciascun componente SW. Questa metodologia è automatizzata grazie all’uso di software appositi che consentono la gestione di ogni singolo passo del processo. Tutte le azioni intraprese fino alla generazione degli eseguibili sono supportate dalla definizione di formati standard di interscambio di dati usando XML. Per supportare la metodologia AUTOSAR è stato sviluppato un meta-modello in UML contenente la descrizione formale di tutti i metodi e delle informazioni a essi correlate. Questo metodologia permette una chiara e immediata visualizzazione della struttura delle informazioni, la garanzia della consistenza delle informazioni stesse e comunque l’enorme facilitazione delle opere di manutenzione del software di sistema.

Implementazioni di AUTOSAR

A questo punto è chiaro che il consorzio AUTOSAR ha svolto in modo preciso e metodico l’ingente attività di definire gli standard, coordinare i membri contributori, accogliere esigenze e richieste ecc. Il risultato di anni di attività sono contenuti nella struttura proposta dal consorzio ma essa non consiste in una specifica implementazione. È per questo che molte aziende attive nel settore della generazione di software hanno provveduto a implementare AUTOSAR in un’apposita suite al fine di agevolare l’utilizzatore finale che voglia utilizzare questo standard per il suo sistema. Queste implementazioni sono state realizzate da realtà diverse che vanno da alcuni membri del consorzio fino a software house che hanno riconosciuto le potenzialità dello standard e del consorzio che lo propone. Dato che lo stesso consorzio ha coniato il paradigma “Un solo standard comune, tante implementazioni”, esistono moltissime implementazioni di AUTOSAR realizzate da entità come Continental Engineering Services, Arctic Core (una versione open source di AUTOSAR), Freescale (Freescale AUTOSAR Software), Renesas Electronics (Renesas Electronics MCAL AUTOSAR package), NEC Electronics (NEC AUTOSAR MCAL per la piattaforma V850), Mentor Graphics (Mentor Graphics VSx), Bosch (CUBAS), Bosch (iSolar), SYSGO (PikeOS RTOS), Vector Informatik GmbH, EB / Elektrobit (EB tresos AutoCore),Tata Elxsi, OpenSynergy, Geensoft AUTOSAR Builder, pulse-AR Tool, EXITE ACE VFB e molti altri. Vediamo quindi ora come le diverse realtà del mondo del software hanno reso possibile il destreggiarsi, ad esempio, tra 50 basic software modules con un totale di più di 6.000 parametri di configurazione.

ARTOP

L’implementazione in oggetto, AUTOSAR Tool Platform (ARTOP), è un software del quale è disponibile il codice sorgente (gratuito per i membri e i partner del consorzio AUTOSAR). Lo sviluppo di ARTOP è basato sulla attività di una community guidata dallo stesso consorzio e denominata ARTOP User Group. Questa community è suddivisibile in Design Members, Contributing Members e Adopters, dove i nomi descrivono le attività e le prerogative dei vari sotto-gruppi. Per diventare adopter non è richiesta alcuna formalità o caratteristica legale particolare; è sufficiente scaricare Artop dal sito e utilizzarlo secondo le licenze proposte. Artop è in continua evoluzione. Uno dei prodotti di ARTOP è ARText.

ARText

ARText è un framework per AUTOSAR utilizzato all’interno di ARTOP che consente l’utilizzo di un linguaggio testuale per la modellizzazione. Data la ricchezza e complessità di alcuni aspetti dello standard AUTOSAR, l’uso di linguaggi specifici per le varie fasi dello sviluppo consente di aumentare sensibilmente la produttività e la manutenibilità del modello definito. ARText, basandosi su Xtext, offre la possibilità di creare il proprio linguaggio di modellizzazione da utilizzare all’interno della suite. Le già notevoli potenzialità di Xtext sono state inoltre arricchite di estensioni specifiche per AUTOSAR per una completa integrazione con ARTOP dove si troveranno code completion, validazione del progetto integrata, evidenziazione sintassi e accesso diretto da ARText alle entità XML definite in AUTOSAR e viceversa. Inoltre tutti i modelli definiti con ARText possono essere esportati in XML per poter essere usati anche da entità che non usano ARText.

Arc Core

Dal sito svedese rilevabile nel riquadro degli approfondimenti è possibile scaricare i 120 Mb dell’applicazione ARCTIC studio, che rappresenta una ottima implementazione di AUTOSAR. È anche possibile scaricare i trial delle applicazioni utilizzabili per configurare separatamente i vari strati, sopra descritti, di AUTOSAR. Un dettagliato tutorial guiderà l’utente nell’installazione e nell’utilizzo della suite che prevede, come prima operazione, la clonazione di un progetto campione per poi procedere alla sua personalizzazione secondo le esigenze dell’utente. Un esempio di come si presenta il software è rappresentato nella figura 4, che si riferisce al software di configurazione dello strato Basic Software. Nell’immagine sono chiaramente visibili le risorse che possono essere aggiunte al design (porte, PWM, risorse CAN ecc.) e la zona nella quale specificare alcune delle caratteristiche della ECU. Quanto riferito è comunque solo una minima parte delle possibilità del SW messo a disposizione. Sono inoltre state sviluppate specifiche applicazioni dedicate a un uso professionale mentre l’aggiornamento di tutti gli applicativi permette di restare allineati alle novità che il mercato automotive continuamente offre e/o richiede.

EB - ElektroBIT

Un’importante realtà nel mondo del software per ECU è la EB tresos che, contribuendo da anni allo sviluppo e all’affermarsi di AUTOSAR, ha messo a punto un interessante applicativo. L’esigenza di verificare se il sistema veicolo definito seguendo lo standard AUTOSAR è completo ed efficace impone a tutti gli utilizzatori di avere un hardware sul quale effettuarne il debug, ma questo non sempre è possibile, specialmente nelle fasi iniziali del progetto. EB tresos WinCore, sviluppato appositamente da EB tresos per questa esigenza, è un simulatore per il Basic Software layer di AUTOSAR che può essere attivato su piattaforma Win32 e che permette lo sviluppo del modello anche senza che l’hardware sia disponibile. Questo tool, basato sul sistema AUTOSAR che gira su di un comune PC equipaggiato con Windows, contiene tutti i modelli dei moduli software utilizzati nella ECU reale, compreso un Microcontroller Abstraction Layer (MCAL) sotto forma di funzioni stub. È così possibile un debug dell’applicazione in via di sviluppo senza l’accesso all’hadware reale.

Bosh

Ingenti risorse sono state dedicate da BOSCH (membro fondatore del consorzio) per lo sviluppo e la crescita di AUTOSAR. Il prodotto che concretizza gli sforzi di una realtà che, solo nella sede indiana, conta più di 4.500 ingegneri è iSolar del quale è possibile vedere in figura 5 una videata. Ovviamente non è possibile descrivere qui tutte le caratteristiche del prodotto che però, per evidenti motivi, non può che essere tra i più avanzati e completi.

Magneti Marelli

È con un pizzico di patrio orgoglio che possiamo annoverare tra gli attori “importanti” del panorama AUTOSAR anche Magneti Marelli che ha accolto la filosofia di AUTOSAR e l’ha applicata alla progettazione delle ECU come mostrato nelle figure 6 e 7.

Alcuni obiettano che...

Date le dimensioni considerevoli dell’argomento, non è possibile in questa sede svilupparne tutti gli aspetti ma è doveroso un accenno alle critiche portate alla struttura AUTOSAR. È stato detto che la generalizzazione delle interfacce tra i moduli software proposta da AUTOSAR impone un aumento della richiesta di risorse hardware e software. Questo può essere vero in sistemi di dimensioni contenute dove l’overhead imposto da AUTOSAR può essere significativo se confrontato con le risorse generali del sistema, ma tale critica non è assolutamente applicabile nel caso di sistemi di dimensioni più consistenti. Infatti la generalizzazione di metodi di accesso alle risorse consente un riutilizzo consistente delle risorse stesse con un conseguente risparmio reale. In altre parole, non c’è convenienza a caricare un sistema operativo evoluto su un microcontrollore povero di risorse (dove è possibile gestire le esigenze con routine software ad hoc) mentre c’è convenienza evidente a caricarlo su una piattaforma “ricca” per la quale non potrei scrivere un software potente e sicuro come un sistema operativo. Credo sia evidente che il sistema autoveicolo stia diventando, per volontà stessa del mercato, di giorno in giorno sempre più ricco e potente e quindi più adatto all’uso di AUTOSAR. Un’altra critica da alcuni avanzata si riferisce alle dimensioni che raggiunte da AUTOSAR negli anni. Effettivamente il voler tenere conto delle esigenze di tutti i membri porta a una notevole quantità di argomenti da definire e regolamentare ma questo, grazie ai metodi utilizzati, non ha ripercussioni sulla sicurezza ed efficienza del sistema che sarà possibile specificare, realizzare e manutenere con AUTOSAR. Probabilmente lo standard potrà risultare “pesante” per alcune realtà industriali ma è chiaro che l’automobile non è più quella di 50 anni fa e occorre preparasi fin da ora, con mezzi adeguati, per quella che sarà in futuro. L’utente finale, comunque, non sarà mai abbastanza consapevole (perché difficilmente percepibile e quantificabile) dell’enorme guadagno che deriva dall’utilizzo di codice generato in modo sicuro. È importante notare che nei bilanci delle ditte del mondo automotive sta diventando una voce sempre più consistente proprio la spesa per argomenti relati alla sicurezza quali test preventivi, verifiche post produzione, adesione a norme vigenti, cause legali per malfunzionamenti. È quindi sicuro il vantaggio derivante dal riutilizzo di codici, strutture e sistemi definiti (e attentamente verificati) una volta per tutte.

Conclusione

AUTOSAR consente quindi, se utilizzato in un contesto opportuno, indubbi e consistenti vantaggi anche perché nato, cresciuto ed educato in una “famiglia” nella quale non esiste un “padre padrone” che detta legge ma un insieme di persone che hanno tutto l’interesse a far crescere sana, forte ed equilibrata questa loro “creatura”. Approccio che si reputa auspicabile anche in altri contesti industriali dove il risparmio non deve essere sempre ottenuto con una riduzione delle risorse, bensì frutto di uno sforzo congiunto di tutti per rendere più sicuro ed efficiente ogni aspetto.

Ti potrebbe interessare anche:

L’elettronica nei veicoli elettrici ed ibridi

Supervisori per componenti a bassissima tensione da Analog Devices

Regolatori Switching ad elevata efficienza