INTRODUZIONE.

Il mercato automotive sta seguendo un processo evolutivo di trasformazione senza precedenti, caratterizzato da elevata complessità, con l’obiettivo di ridefinire il concetto futuro di mobilità.

Questo processo spingerà i paesi a dotarsi di politiche industriali adeguate ed i fornitori del settore ad affrontare un profondo mutamento per seguire l’evoluzione tecnologica.

Focalizziamoci sulla tematica della guida autonoma e consideriamo la classificazione della SAE International (Society of Automotive Engineer) che ha definito sei diversi livelli di automazione^[1] in funzione del grado di intervento umano richiesto:

• Livello 0 – Nessuna automazione.
• Livello 1 – Assistenza alla guida.
• Livello 2 – Automazione parziale.
• Livello 3 – Automazione condizionale.
• Livello 4 – Alta automazione.
• Livello 5 – Automazione completa.

Attualmente la tecnologia industrializzata consente di raggiungere il livello 2, in cui uno o più sistemi di assistenza del guidatore possono assumere il controllo dello sterzo e di accelerazione/decelerazione, mentre il guidatore monitora l’ambiente di guida.

In questo contesto la digitalizzazione è assoluta protagonista e si sta diffondendo in ogni piega del settore Automotive, creando nuove opportunità e modelli di business.

A testimonianza della crescente complessità digitale dell’auto basti pensare che a oggi, un veicolo passeggeri di nuova generazione di media portata, può includere tra i 1500 ai 3000 chip. Numero destinato solo a crescere.

Di fronte a un tale contesto di mercato, i fornitori Automotive o potenziali tali, come lo è NIER, non possono permettersi di rimanere passivi, piuttosto dovrebbero adottare approcci esplorativi, aperti alla innovazione con un allargamento del proprio spettro di competenze per sviluppare modalità di collaborazione con OEM o TIER.

[1]Documento “SAE J3016 Levels of Driving”

Tra i macro-temi che caratterizzano la filiera dell’evoluzione automotive, noi vogliamo concentrarci sul ruolo centrale del Software. Il Software è, come sta accadendo in tutti i settori industriali, attore centrale e in particolare è uno dei principali elementi distintivi per l’esperienza a bordo. Il software, inoltre, è un elemento chiave in termini di costo del veicolo, data la crescita notevole del numero di linee di codice richieste. Questo aspetto include il software di controllo delle centraline (ECU – Engine Control Unit) così come dell’infotainment (display installato sull’auto che ha diverse funzioni, come informare su condizioni auto, traffico, clima, ma permette anche di intrattenersi con musica, video e chiamate) e della sensoristica ADAS (Advanced Driver Assistance Systems.

NIER non ha maturato nella sua storia competenze verticali in questo dominio, ma la spinta a voler offrire il nostro contributo ci ha portato con grande entusiasmo a sviluppare un progetto pilota interno di R&D che ci permettesse di specializzare le nostre competenze di sviluppo software acquisite in settori altamente normati e inerenti i sistemi Safety related (Railways, Biomedicale, industriale) anche nel settore Automotive.

Un progetto pilota denominato NRC, ovvero NIERobotCar che possa rappresentare un incubatore di problematiche reali e che si basi su strumenti reali utilizzati in questo dominio.

Prima di guidarvi nella nostra esperienza, è bene dare una breve informativa introduttiva che contestualizzi il perimetro di intervento del progetto. Nel contesto finora descritto è facile immaginare quanti attori siano coinvolti nella progettazione e sviluppo del software che la caratterizza.

Emerge quindi la necessità di standardizzare i processi di sviluppo software al fine di integrare parti di SW sviluppate da più realtà mitigandone la incompatibilità o incoerenza architetturale.

Ed ecco che nel dominio Automotive, il Software viene sviluppato seguendo un framework SW specifico e una architettura SW standardizzata che prende il nome AUTOSAR (AUTomotive Open System Architecture), definito da 9 grandi partner, di cui riportiamo una immagine che già a prima vista comunica la portata di AUTOSAR in termini tecnici/tecnologici e commerciali.

Lo scopo di NIERobotCar (NRC) è quello di creare un basilare prototipo, su piattaforma commerciale, e renderlo una piattaforma Automotive reale, sia a livello HW che SW utilizzando processore presente nelle centraline delle auto moderne, AURIX TC375 della Infineon, su cui implementare la logica ADAS compliant con il framework AUTOSAR utilizzando semplici sensori commerciali. Il prototipo sarà pilotato via Mobile tramite una applicazione sviluppata internamente specificamente per lo scopo.

Ma non dilunghiamoci troppo nell’introduzione e passiamo alla descrizione di dettaglio!

DESCRIZIONE DI DETTAGLIO DEL PROGETTO INTERNO NRC: APPROCCIO TECNOLOGICO.

Com’è fatto NRC.

NRC è una piccola automobile-robot dotata di schede di controllo, moduli di comunicazione wireless, attuatori (motori) e un insieme di semplici sensori che permettono a NRC di monitorare l’ambiente circostante, analogamente a quanto succede nelle automobili “moderne”.

Architettura HW.

La rappresentazione semplificata dell’architettura HW definita per NRC è riportata in Figura 4:

• Shieldbuddy TC375: scheda sviluppata da Hitex che monta il microcontrollore automotive-grade Infineon AURIX TC375. Rappresenta il cuore centrale di NRC, su questa scheda è caricato il software AUTOSAR CLASSIC che controlla tutte le funzionalità del sistema.
• Arduino Due: interpreta i comandi di attuazione ricevuti via CAN bus da Shieldbuddy TC375 generando i segnali di controllo per gli attuatori a cui si interfaccia direttamente. Gestisce inoltre il modulo di comunicazione WIFI (WiFi Shield). Il software sviluppato per Arduino Due non è AUTOSAR compliant, ma è sempre stato sviluppato da NIER nell’ambito di questo progetto.
• WiFi Shield: scheda basata su microcontrollore ESP8266, implementa lo stack di comunicazione WIFI. Per l’interazione di NRC con il mondo esterno, NIER ha sviluppato un semplice protocollo di comunicazione proprietario.
• Sensori e attuatori: si tratta di componenti commerciali e a basso costo, usati per rilevare presenza ostacoli o linee sul terreno, misurare distanza oggetti, pilotare i motori.
• Interfaccia CAN BUS: le schede Shieldbuddy TC375 e Arduino Due comunicano tramite CAN bus, che rappresenta lo standard de-facto per le comunicazioni tra centraline automotive.

Funzionalità Implementate.

La scelta dell’architettura e dei componenti hardware usati in NRC è dipesa dalle funzionalità (semplificate) “caratteristiche” dei sistemi ADAS che si sono volute implementare, che sono le seguenti:

• Line tracking: modalità in cui NRC segue autonomamente una linea nera tracciata sul terreno. Per l’implementazione di questa funzionalità è stata utilizzata la schiera di sensori IR (IR Tracker).
• Emergency brake: modalità in cui NRC esegue una frenata in caso di rilevazione di un ostacolo a distanza ravvicinata.
• Adaptive Cruise Control: modalità in cui NRC si mantiene a una distanza configurabile da un target in movimento davanti a esso.

Queste modalità sono attivabili tramite comandi inviati via WIFI a NRC.

Protocollo di comunicazione custom ed APP Mobile.

Per potere controllare NRC è stata sviluppata una APP mobile, NRC Remote Control APP, sviluppata in tecnologia Flutter al fine di potere essere deployata sia su sistema operativo Android che su iOS. L’ APP è dotata di alcune schermate tramite le quali è possibile selezionare comandi e parametri da inviare a NRC.

La comunicazione tra APP e NRC avviene tramite un protocollo custom, sviluppato appositamente per questo progetto, tramite il quale è possibile inviare a NRC comandi come la velocità e direzione di movimento, la selezione del modo di funzionamento e i relativi parametri. I comandi vengono ricevuti via WIFI da Arduino Due e vengono rigirati su CAN bus per essere trasmessi a ShieldBuddy TC375, che li interpreta ed esegue.

Architettura SW AUTOSAR e toolchain

Lo standard AUTOSAR (dettagli ufficiali: www.autosar.org) definisce tre layer principali che qualunque architettura SW deve possedere (Figura 6):

• Application layer
• Real Time Environment (RTE)
• Basic Software

Ciascun layer è a sua volta formato da moduli SW anch’essi standardizzati, in quanto o già specificati completamente dallo standard (si vedano a esempio tutti i moduli del Basic Software) o per i quali è specificato il tipo di interfaccia.

L’architettura SW di NRC è mostrata nell’immagine seguente:

– Application Layer

A livello di Application Layer, sono stati definiti questi Software Component (SWC), a volte raggruppati in Compositions:

Logic SWC

• Ottiene lo stato dei sensori a infrarossi e la distanza misurata dai sensori a ultrasuoni attraverso il modulo software dedicato alla gestione dei sensori (Sensor Composition);
• Riceve i comandi inviati dall’esterno (tramite il componente CDD Comm) e la velocità di crociera definita dal componente ACC;
• Esegue gli algoritmi opportuni in base alle modalità attive e allo stato dei sensori, determinando i comandi da inviare agli attuatori. Tali comandi sono inviati al nodo esterno su CAN bus.

Sensors Composition

• Sono istanziati SWC di tipo “IR Sensor” per gestire sensori a infrarossi e 3 di tipo “US Sensor” per gestire sensori ultrasonici;
• SWC di tipo IR Sensor: multi-istanziabile, legge periodicamente il segnale digitale in uscita dagli IR sensor attraverso il componente IoHwAbstraction;
• SWC di tpo US Sensor: multi-istanziabile, legge periodicamente la durata di un impulso generato dai sensori ultrasonici (durata proporzionale alla distanza dell’ostacolo), attraverso il componente CDD USTime (Complex Driver che svolge il ruolo di driver di basso livello);
• IoHwAbstraction: software component che fornisce la necessaria astrazione per leggere e scrivere i GPIO connessi ai sensori.

ACC SWC

• Implementa un algoritmo semplificato di Adaptive Cruise Control: modula la velocità di NRC in modo da mantenere costante la distanza da un ostacolo in movimento su traiettoria rettilinea;
• Riceve in input la distanza dall’ostacolo (misurata tramite i sensori ultrasonici), la distanza da mantenere (configurabile tramite comando) e la velocità attuale, generando in output la nuova velocità da applicare a NRC.
• L’algoritmo è stato implementato tramite un approccio Model Based, attraverso un tool dedicato con il quale, una volta definito il modello, si è generato in automatico il codice C AUTOSAR compliant importato poi nel progetto generale.

– Basic Software

Per quel che riguarda invece la configurazione del Basic Software (BSW), è stato necessario inserire nell’architettura e quindi configurare i seguenti moduli:

• ComM, PduR, CanTp, CanIf per gestione CAN bus;
• BswM e EcuM per startup/shutdown ECU Mode Management;
• IoHwAbstraction per gestione dei Digital I/O con cui i sensori si interfacciano al micro;
• OS: anche il sistema operativo deve soddisfare requisiti forniti dallo standard AUTOSAR e deve essere configurato in base all’applicazione che si sta sviluppando.

– Complex Device Driver

Si è anche reso necessario lo sviluppo di due Complex Device Driver, ovvero di moduli che permettono di gestire periferiche non standardizzate da AUTOSAR, ma che sono comunque sviluppati in modo da fornire interfacce standard tali da rendere il Complex Driver integrabile in architettura AUTOSAR compliant.

• CDD Comm. Permette di astrarre il protocollo di comunicazione, interpretando i messaggi ricevuti e fornendo tramite interfaccia standard AUTOSAR un “Id comando” con relativi parametri utilizzabili dagli altri moduli.

• CDD US Time. È il driver per sensori a ultrasuoni, gestisce l’invio di un treno di impulsi e la lettura della durata del tempo di volo, proporzionali alla distanza dell’oggetto. Fornisce tramite interfaccia AUTOSAR il valore della misura effettuata.

– MCAL

È importante osservare infine che è stato necessario configurare anche alcuni componenti di MCAL, il MicroController Abstraction Layer. Questo layer, che fa sempre parte del Basic Software, contiene i moduli più intrinsecamente legati al microcontrollore (a esempio, i device driver delle periferiche del micro), nel nostro caso:

• Can, per gestione periferica CAN bus;
• Gpt e Icu per gestione timer;
• Mcu, per gestione generale micro;
• DIO e Port per gestione pin.

– Toolchain

In questa immagine, possiamo vedere quali tool NIER abbia introdotto col progetto NRC e utilizzato per lo sviluppo e configurazione dei moduli e funzionalità appena visti:

I tool, sopra indicati, permettono di generare il codice C relativo ai layer e moduli AUTOSAR configurati tramite i tool stessi.

Tale codice deve essere poi integrato con i moduli software C sviluppati ad hoc, ovvero il codice dei software component e degli eventuali Complex Device Driver, oltre che, per fare alcuni esempi, il codice di inizializzazione del microcontrollore e della gestione della sequenza di startup.

Il software così ottenuto deve poi essere compilato per il target specifico e deve potere essere debuggato tramite opportuni ambienti e dispositivi, a es. UDE o Lauterbach. Nel caso di NRC è stato utilizzato l’ambiente integrato Hightec Development Platform che mette a disposizione il compilatore C per AURIX TC375 e l’ambiente di debug.

CONCLUSIONI.

Il progetto NIERobotCar ha permesso di sviluppare all’interno di NIER competenze verticali tipiche del settore automotive, quali:

• Approfondimento del framework AUTOSAR CLASSIC;
• Utilizzo pratico dei tool di Authoring e configurazione moduli AUTOSAR (ASW, BSW, Mcal);
• Progettazione di componenti model-based e integrazione del codice-auto generato in architetture SW AUTOSAR compliant;
• Gestione di schede a microcontrollore automotive-grade;
• Conoscenza degli standard tipici automotive (es. CAN bus);

Il prototipo NRC, sul quale sono state implementate e testate le funzionalità che abbiamo descritto in questo articolo, si presta a innumerevoli miglioramenti e aggiornamenti:

• Sostituzione scheda Arduino Due con una seconda Shieldbuddy TC375 in modo da rendere AUTOSAR compliant  anche il software di questa seconda scheda;
• ADAS: upgrade algoritmo ACC (tramite tool model based) per gestione traiettorie curvilinee;
• ADAS: implementazione funzionalità Lane Assist, nella quale NRC rimane all’interno di una corsia delimitata da due linee sul terreno;
• Introduzione di moduli AUTOSAR aggiuntivi quali a es.Memory Stack e Diagnostica;
• Gestione di più core del microcontrollore AURIX TC375;
• Miglioramenti hardware (a es. sensori più performanti, inserimento encoder per misura velocità)

NRC rappresenta quindi un Laboratorio Automotive che NIER potrà sfruttare per proseguire con la crescita interna all’azienda sulle competenze relative al settore, necessarie per garantire che NIER rappresenti un fornitore di servizi di sviluppo SW in ambito automotive credibile e affidabile.