EMB_86

EMBEDDED 86 • NOVEMBRE • 2022 46 attraverso la stessa rete, il requisito di latenza audio non può essere violato, ossia, i pacchetti non posso- no essere abbandonati. Ecco perché sono importanti l’arbitraggio e la messa a punto di precisione delle possibilità di regolazione TSN già esistenti. Tra que- ste possibilità, una delle più note è il TAS ( time-aware shaping ), disponibile negli SDK dei processori di TI considerati come miglioramenti per l’alleggerimen- to del traffico programmato (EST, enhancements for scheduled traffic ). Il TAS fa sì che il traffico a larghez- za di banda inferiore sia trasferito dopo una finestra di tempo predefinita, a prescindere dalla quantità di dati di tipo differente (come i dati di sensori ADAS) trasportata in parallelo. Nel migliore dei casi, inte- grare lo switch hardware TSN come nei processori di TI, ad esempio il DRA821, offre una totale flessibilità software, oltre al supporto da parte di acceleratori hardware che consentono di gestire, inoltrare o ab- bandonare volontariamente i pacchetti di dati. Protezione della comunicazione Oltre alle proprietà fisiche di rete come la latenza e il jitter, l’architettura a zone necessita di un percorso di comunicazione protetto. I metodi di attacco basati su Ethernet e gli strumenti comuni su Internet sa- ranno applicabili in larga misura anche sui veicoli stradali. Se la sicurezza nella rete di un’autovettura viene compromessa, non è possibile alcuna comuni- cazione affidabile e l’intero concetto di separazione degli I/O dall’elaborazione collassa. Per questi mo- tivi, è importante adottare un approccio olistico al tema della cybersicurezza. Oltre alla funzionalità centrale di integrità, autenticità e riservatezza dei dati, l’intero sviluppo e l’intero ciclo di vita del pro- dotto devono essere accompagnati da una mentalità improntata alla sicurezza. Analogamente alla norma ISO 26262 sulla sicurezza funzionale dell’Organizza- zione Internazionale per la Normazione, la ISO/SAE 21434 dell’ISO/ Society of Automotive Engineers è una nuova norma per la progettazione della cybersicu- rezza in campo automobilistico. Inoltre, la UNECE ( United Nations Economic Commission for Europe ) ha pubblicato due normative che specificano le mo- dalità di gestione dei rischi di cybersicurezza per i veicoli e di rilevamento e reazione agli incidenti di sicurezza che riguardano una flotta di veicoli. Non è possibile semplicemente «aggiungere» più sicurezza per una tale diversità di tipologie di dati; anche l’efficienza della comunicazione è fondamen- tale. L’approccio classico di protezione dei pacchetti del protocollo Internet con IPsec è adatto per i dati di controllo e sensori che consumano una ridotta larghezza di banda di rete. Per trasmettere dati per audio, visione o sensori radar è necessario un flusso continuo di pacchetti Internet Protocol, protetti al- meno tramite autenticazione. Realizzare questa con- dizione a livello software, tuttavia, comporterebbe un sovraccarico notevole che andrebbe a consumare risorse vitali del processore. Il superamento di questo collo di bottiglia richiede un nuovo livello inferiore di crittografia e autenti- cazione. Un esempio è MACsec, che può essere ap- plicato al Livello 1 o 2 di un protocollo Ethernet e integrato nell’IP di controllo dell’accesso ai supporti Ethernet oppure nel PHY Ethernet per l’autentica- zione line-rate , la crittografia del payload o entram- be. I requisiti dell’architettura a zone richiedono nuove soluzioni per superare le sfide relative alla distribu- zione dell’alimentazione, a sensori e attuatori, e alla comunicazione dei dati. Il passaggio a fusibili intelligenti decentralizzati, un maggiore utilizzo di attuatori e sensori intelligenti e interfacce a larghezza di banda maggiore con il giusto supporto su combinazioni di tipologie di dati ad elevata diffusione possono risolvere i problemi di progettazione più evidenti nelle implementazioni dell’architettura a zone. Queste soluzioni non verranno realizzate tutte in una volta, ma seguiranno un percorso evolutivo se- quenziale che introdurrà cambiamenti nel tempo a mano a mano che avranno senso dal punto di vista commerciale, riducendo al minimo il rischio di ritar- di dovuti a un’adozione prematura. Il dominio della carrozzeria, con le sue numerose ECU distribuite per attuatori e sensori, sarà uno dei primi a passa- re all’architettura a zone. Il passaggio degli ADAS o del controllo di powertrain e telaio all’architettura a zone potrebbe richiedere più tempo. L’obiettivo finale dell’architettura a zone è realizza- re un veicolo completamente software-defined che combini componenti standardizzati in modo ideale per sensori, attuatori, moduli zonali e collegamenti dati. Tenendo a mente questo obiettivo, idee molto diverse in campi differenti si stanno combinando in modo olistico, gettando le basi per un’innovazione basata sul software destinata a continuare per i de- cenni a venire. HARDWARE | AUTOMOTIVE