Toolchain DevOps del veicolo definito dal software

Nell'intero settore automobilistico, la transizione ai veicoli software-defined (SDV) richiede un approccio unico per lo sviluppo, la distribuzione, il monitoraggio e la gestione di stack di software per automobili. I produttori di apparecchiature originali automobilistiche (OEM) adottano una strategia di spostamento a sinistra, che implica l'esecuzione di test all'inizio del ciclo di sviluppo del prodotto.

Nell'approccio in questo articolo, lo stack software in-vehicle viene sottoposto a simulazione e test completi in un ambiente basato sul cloud. L'architettura di esempio seguente illustra come sfruttare gli stack software e le distribuzioni offerti dal gruppo di lavoro di Eclipse SDV. È possibile usare questi componenti con GitHub e i servizi di Azure per sviluppare uno stack di software per automobili end-to-end, implementare il software nei test del ciclo (SIL), orchestrare l'hardware nel test del ciclo (HIL) e convalida della flotta di veicoli di ingegneria.

In questo articolo viene descritto come:

• Integrare gli strumenti di sviluppo all'avanguardia nel processo di sviluppo.
• Usare e gestire il codice sorgente del settore automobilistico.
• Creare automaticamente ambienti di veicoli virtuali come parte delle pipeline di integrazione continua e recapito continuo (CI/CD) e gestire l'esecuzione per i test virtuali.
• Orchestrare le distribuzioni per i test SIL (test virtuali) e i test HIL.
• Usare servizi altamente scalabili per raccogliere e analizzare i dati prodotti durante i test di convalida e l'utilizzo sul campo.

Architettura

Questo diagramma mostra l'architettura della toolchain SDV per automobili.

Scaricare un file PowerPoint di questa architettura.

Workflow

L'architettura è costituita da sei blocchi predefiniti principali:

1. La toolchain SDV è un approccio plug-and-play aperto e configurabile. Questo approccio sfrutta gli asset e i servizi Microsoft per sviluppatori e DevOps. Riduce la dipendenza dal processore nel veicolo stabilendo ambienti di controllo elettronici virtuali configurabili e flessibili (vECU) e ambienti vHPC (Virtual High Performance Computer) in Azure. Questi ambienti consentono di accelerare lo sviluppo, il test e la convalida del software automobilistico. Questo approccio garantisce la compatibilità con il processore perimetrale e nel veicolo per garantire la parità di bit, temporizzazione e codice.

2. Uno stack di software automobilistico comprende una vasta gamma di tecnologie e framework. Gli standard del settore e gli sforzi collaborativi, ad esempio il gruppo di lavoro software-defined di Eclipse Foundation, spesso regolano queste tecnologie e framework. I progetti Eclipse includono componenti non differenzianti per la connettività dei veicoli, la messaggistica e i protocolli di comunicazione, ad esempio un livello di astrazione di gemelli digitali nel veicolo, sistemi avanzati di assistenza guida (ADAS) e soluzioni di guida autonoma.

   Gli stack di software automobilistici offrono una solida base per gli sviluppatori di automaker e software. Garantiscono un'integrazione e una compatibilità senza problemi nell'ecosistema automobilistico e forniscono un approccio basato sulla community ai progressi tecnologici.

3. GitHub Marketplace e Azure Marketplace consentono ai partner, ad esempio fornitori di software di livello 1 e fornitori di software per automobili, di offrire soluzioni, ad esempio stack di software automobilistici gestiti, vECU e strumenti per sviluppatori. È possibile integrare queste soluzioni con la toolchain SDV.

4. Con i test HIL, è possibile eseguire test e convalida nell'hardware di destinazione. Per la convalida con il processore perimetrale e in-vehicle, i test HIL usano lo stesso concetto di orchestrazione dei test SIL. L'hardware specializzato è connesso con accesso rapido alla rete e reti sicure.

5. La messaggistica, i dati e l'analisi dei veicoli forniscono l'infrastruttura necessaria per:

   • Gestione di veicoli e dispositivi.
   • Distribuzione e gestione di applicazioni di veicoli connessi con dipendenze ai componenti software nel veicolo.
   • Fornitura di analisi dei dati per servizi di progettazione, operazioni e mobilità.

   Per informazioni sulla raccolta e l'analisi dei dati per la convalida dei componenti e del sistema, vedere Analisi dei dati per i veicoli di test automobilistici.

6. Le operazioni dei veicoli autonomi (AVOps) consentono agli OEM di automobili di sviluppare soluzioni di guida automatizzate in Azure. La soluzione AVOps descrive:

   • Come gestire le operazioni dei dati (DataOps) per i veicoli autonomi.
   • Estrazione automatica delle funzionalità, etichettatura e training del modello per la percezione e la fusione dei sensori (MLOps).
   • Test di modelli sviluppati in ambienti simulati (ValOps).

   Questa soluzione si integra con la toolchain SDV fornendo modelli sottoposti a training ed eseguendo la convalida software.

Questa architettura è incentrata su una toolchain SDV generale e su uno stack software automobilistico. Fornisce esempi di implementazioni che usano progetti open source sotto la panoramica del gruppo di lavoro eclipse SDV, ad esempio Eclipse uProtocol, Eclipse Chariott, Eclipse Ibeji, Eclipse Freyja e Eclipse Agemo.

Microsoft è membro del gruppo di lavoro del veicolo software-defined eclipse, un forum per la collaborazione open source per le piattaforme software del veicolo.

La toolchain SDV per automobili è costituita dai componenti seguenti.

• Gli strumenti di sviluppo includono servizi di sviluppo e collaborazione, ad esempio GitHub, Microsoft Dev Box, Visual Studio Code e Registro Azure Container. Questa architettura usa anche le funzionalità di analisi del codice di GitHub. Il motore di analisi CodeQL rileva i bug di sicurezza nel codice sorgente e gli avvisi di superficie nelle richieste pull prima che il codice vulnerabile venga unito e rilasciato.

• Sviluppo, convalida e integrazione è un metodo che combina metadati e servizi di orchestrazione. Consente agli sviluppatori di configurare, compilare, distribuire e orchestrare ambienti di esecuzione virtuale su richiesta. Gli sviluppatori possono semplificare il processo di sviluppo e test, integrarsi con toolchain esistenti e supportare più formati di applicazione, file binari, sistemi operativi e ambienti di runtime.

• L'ambiente di esecuzione è costituito da servizi e componenti di Azure che consentono ambienti cloud e perimetrali affidabili, ripetibili e osservabili per creare, testare e convalidare stack di software automobilistici. Questi componenti possono includere:

  • Ambienti di distribuzione di Azure.
  • Raccolta di calcolo di Azure.
  • Registro Container.
  • Azure Arc.
  • Calcolo di Azure, ad esempio macchine virtuali (VM) di Azure basate su ARM64 e calcolo ad alte prestazioni.
  • Servizi di rete di Azure e servizi di connettività, ad esempio Azure ExpressRoute.

I flussi di lavoro seguenti illustrano come uno sviluppatore definisce, orchestra ed esegue test virtuali per il software automobilistico.

Flusso di lavoro: Distribuire vECU

Questa soluzione descrive in che modo uno sviluppatore di software automobilistico per l'azienda fittizia Contoso Automotive usa la toolchain SDV automobilistica per:

• Configurare un ambiente di sviluppo in pochi minuti.
• Attivare una modifica dell'aggiornamento nell'infrastruttura cloud SIL per distribuire un vECU eseguito in una macchina virtuale basata su ARM64.

Contoso Automotive aggiunge una nuova unità HPC (Automotive High Performance Compute) a un modello di veicolo imminente e deve eseguire l'onboarding di un nuovo team di sviluppo per sviluppare applicazioni in contenitori. L'hardware per il veicolo non è ancora disponibile, ma le sequenze temporali compresse indicano che la funzionalità software deve essere sviluppata e convalidata in parallelo.

Scaricare un file PowerPoint di questa architettura.

1. Lo sviluppatore di automobili crea e si connette a una scatola di sviluppo Microsoft. La casella di sviluppo è preconfigurata con tutti gli strumenti di sviluppo necessari (ad esempio Visual Studio Code e Android Studio) e tutte le estensioni necessarie (ad esempio GitHub Copilot) per essere compatibili con le applicazioni Contoso Automotive.

2. Lo sviluppatore di automobili esegue un check-out del codice dell'applicazione automobilistica e dei metadati che descrivono la configurazione futura del veicolo, le UNITÀ HPC e le UNITÀ di calcolo incluse e la distribuzione necessaria per eseguire la convalida SIL.

3. Lo sviluppatore di automobili usa le estensioni dei metadati per modificare le configurazioni, ad esempio modificando le caratteristiche del HPC in base alle nuove informazioni del team di progettazione.

4. La modifica della configurazione attiva l'estensione per l'elaborazione dei metadati. Esegue la convalida dei metadati, genera tutti gli artefatti necessari e configura una campagna di distribuzione dell'ambiente di esecuzione.

5. Al termine di tutte le modifiche alla configurazione, lo sviluppatore invia una richiesta pull che attiva un'azione GitHub per la distribuzione.

6. L'azione GitHub di distribuzione attiva i metadati e i servizi di orchestrazione, che eseguono la campagna di distribuzione.

7. I metadati e i servizi di orchestrazione usano l'ambiente di sviluppo di Azure per distribuire il calcolo necessario per simulare la nuova versione dell'architettura elettronica automobilistica.

8. I metadati e i servizi di orchestrazione impostano lo stato desiderato del calcolo in base alla campagna. I servizi usano l'archivio artefatti per montare e configurare le immagini vHPC e ECU necessarie.

Flusso di lavoro: aggiornamenti soTA (Software over the air) per applicazioni automobilistiche

Contoso Automotive vuole distribuire applicazioni automobilistiche in contenitori nella propria flotta di test di progettazione per eseguire test di integrazione. Lo sviluppatore di automobili compila, testa e convalida la nuova versione dell'applicazione e la distribuisce nel veicolo.

Scaricare un file PowerPoint di questa architettura.

1. Lo sviluppatore di automobili crea una versione. La versione contiene una definizione dello stato desiderato per il contenitore dello stack software e una definizione della compilazione.

2. La toolchain e i servizi di orchestrazione attivano il processo di rilascio. I servizi distribuiscono l'infrastruttura necessaria per compilare, convalidare e rilasciare contenitori software.

3. Durante l'esecuzione, le applicazioni vengono compilate, convalidate e rilasciate con strumenti basati su contenitori. A seconda dei requisiti degli strumenti, possono essere distribuiti in servizio Azure Kubernetes (servizio Azure Kubernetes) per le applicazioni in contenitori oppure possono essere distribuiti in macchine virtuali dedicate.

   Al termine della compilazione, i risultati vengono inseriti nel Registro Container per i contenitori rilasciati e le modifiche vengono registrate nel server OTA.

4. Il client OTA ha un agente OTA dedicato per le applicazioni basate su contenitori. L'agente di ricerca dello stato desiderato si connette alla toolchain e ai servizi di orchestrazione per recuperare la definizione dello stato desiderato.

5. Il motore di orchestrazione del contenitore scarica e attiva i contenitori desiderati da Registro Container.

Flusso di lavoro: stack di software automotive

In questa soluzione, uno stack di software per automobili generico sincronizza lo stato con il cloud di Azure.

Lo stack include i componenti seguenti:

• Un registro dei servizi consente di registrare e individuare i servizi all'interno del veicolo.

• La gestione dinamica degli argomenti consente ai servizi di sottoscrivere e pubblicare messaggi in argomenti denominati, astraendo il protocollo di comunicazione.

• Il servizio gemelli digitali nel veicolo mantiene lo stato del veicolo, inclusi i segnali provenienti da UNITÀ di calcolo e UNITÀ di calcolo, ad esempio AD/ADAS e infotainment.

• La sincronizzazione cloud di Gemelli digitali sincronizza lo stato locale del veicolo con lo stato nel cloud per fornire prodotti e servizi digitali che non richiedono una connessione diretta all'auto.

Scaricare un file PowerPoint di questa architettura.

1. Tutti i componenti registrano le proprie funzionalità tramite il Registro di sistema del servizio.

2. Il calcolo del veicolo registra le descrizioni dello stato al provider di gemelli digitali del servizio gemelli digitali nel veicolo. Dopo la registrazione, le unità di calcolo possono pubblicare gli aggiornamenti sullo stato.

   1. Il calcolo del veicolo registra oggetti di stato complessi e interazioni.
   2. Registrare le CPU del veicolo quali segnali sono disponibili per le applicazioni automobilistiche e quali comandi possono essere accettati.

3. Il gemello digitale nel veicolo pubblica le modifiche e gli aggiornamenti dello stato per la gestione dinamica degli argomenti. Questi aggiornamenti sono organizzati in argomenti.

4. Le applicazioni automobilistiche possono sottoscrivere messaggi provenienti da qualsiasi origine gestita dalla gestione dinamica degli argomenti. Queste applicazioni vengono sottoscritte agli argomenti pertinenti e reagiscono alle modifiche dello stato. Possono anche pubblicare i propri messaggi.

5. Il servizio gemelli digitali nel veicolo pubblica anche gli argomenti selezionati nel servizio di sincronizzazione cloud di Gemelli digitali.

6. La sincronizzazione cloud di Gemelli digitali può usare un cartografo per eseguire il mapping dei nomi degli argomenti (tramite un servizio di mapping di gemelli digitali) ai nomi equivalenti nel cloud. Questa armonizzazione riduce la dipendenza tra il software del veicolo e il cloud e tra i modelli di veicoli.

7. Il connettore cloud pubblica gli aggiornamenti nel cloud e sottoscrive per ricevere modifiche dello stato pubblicate da altri servizi e applicazioni.

8. Griglia di eventi di Azure instrada i messaggi ai servizi e alle applicazioni pertinenti. Lo stato del veicolo viene archiviato tramite servizi. Ad esempio, cache di Azure per Redis potrebbe archiviare l'ultimo valore noto per l'accesso rapido e il recupero e Azure Esplora dati potrebbe fornire la cronologia e l'analisi dello stato del veicolo a breve termine.

Componenti

In questa architettura vengono usati i componenti di GitHub e Azure seguenti.

Strumenti di sviluppo

• Registro Contenitori è un servizio che è possibile usare per compilare, archiviare e gestire immagini e artefatti del contenitore in un registro privato per tutti i tipi di distribuzioni di contenitori. Il software automobilistico ha adottato applicazioni e carichi di lavoro automobilistici basati su contenitori. La toolchain SDV usa registri contenitori di Azure per lo sviluppo di contenitori, i processi di distribuzione e le pipeline.

• Dev Box offre agli sviluppatori l'accesso self-service a workstation pronte al codice, basate sul cloud note come dev box che possono essere personalizzati con strumenti specifici del progetto, codice sorgente e file binari predefiniti per l'integrazione immediata del flusso di lavoro.

• GitHub è una piattaforma di sviluppo che è possibile usare per ospitare ed esaminare codice, gestire progetti, collaborare e creare software insieme agli sviluppatori che si trovano all'interno o all'esterno dell'organizzazione.

• Visual Studio Code è un editor di codice sorgente leggero disponibile per Windows, macOS e Linux. Include un ricco ecosistema di estensioni per diversi linguaggi e runtime.

Ambiente di esecuzione

• Ambienti di distribuzione di Azure offre una raccolta preconfigurata di risorse di Azure. Consente ai team di sviluppo di creare rapidamente e facilmente l'infrastruttura usando modelli basati su progetti. I modelli stabiliscono coerenza e procedure consigliate, ottimizzando al contempo la sicurezza.

• L'ambiente di calcolo di Azure è una suite completa di servizi cloud che consentono agli sviluppatori di eseguire stack di software, applicazioni e carichi di lavoro per automobili in macchine virtuali e contenitori. Esistono molte varietà di calcolo, tra cui risorse di calcolo ottimizzate per la memoria, ottimizzate per la CPU, prestazioni elevate e calcolo per utilizzo generico.

• La raccolta di calcolo è un servizio che supporta il controllo delle versioni e il raggruppamento delle risorse per semplificare la gestione. È possibile condividere immagini con la community, tra sottoscrizioni e tra i tenant di Microsoft Entra ID. È anche possibile ridimensionare le distribuzioni con repliche di risorse in ogni area di Azure. La raccolta di calcolo fornisce struttura e organizzazione per gli artefatti dello stack di software automobilistico.

• Azure Arc semplifica la governance e la gestione e offre un cloud coerente alla piattaforma di gestione HIL. Gli OEM automobilistici possono usare Azure Arc per controllare e gestire ambienti HIL sempre più complessi nei data center locali e basati sul cloud.

• Archiviazione BLOB di Azure è un servizio che offre un'archiviazione di oggetti altamente scalabile per qualsiasi tipo di dati non strutturati, ad esempio immagini, video, audio e documenti, che gli stack di software automobilistici producono e utilizzano.

• I servizi di rete di Azure sono servizi globali, sicuri e affidabili. Gli stack di software automobilistico e gli strumenti di sviluppo richiedono pipeline di elaborazione dati in modo da poter accedere alle farm HIL per sviluppare e testare soluzioni autonome e di guida assistita. I servizi di rete in Azure offrono diverse funzionalità di rete, ad esempio i servizi di connettività, i servizi di protezione delle applicazioni, i servizi di distribuzione delle applicazioni e il monitoraggio della rete.

Alternative

I servizi di Azure scelti per l'implementazione dell'architettura dipendono da molti fattori.

L'esempio nella sezione Distribuire questo scenario usa il servizio Azure Kubernetes. Kubernetes serverless viene usato per eseguire microservizi, fornire sicurezza e governance di livello aziendale e offrire un'esperienza CI/CD integrata. Come metodo rapido e semplice alternativo, è possibile eseguire microservizi in Istanze di Azure Container. In questa alternativa, non è necessario adottare un servizio di livello superiore, ad esempio il servizio Azure Kubernetes.

L'esempio nella sezione Distribuire questo scenario suggerisce l'uso di Hub eventi di Azure o bus di servizio di Azure per implementare un servizio uBus. Per altre informazioni, vedere Scegliere tra i servizi di messaggistica di Azure. I servizi di messaggistica sono spesso complementari ed è possibile usare più di uno.

Le applicazioni e i servizi in questa architettura vengono distribuiti tramite modelli di Azure Resource Manager o Bicep. In alternativa, è possibile usare gli script Terraform per effettuare il provisioning e gestire l'infrastruttura cloud.

Per alternative al livello di messaggistica, dati e analisi del veicolo dell'architettura, vedere Alternative.

Dettagli dello scenario

Gli SDV autonomi e connessi aprono un nuovo mondo di funzionalità, facilità di servizio e affidabilità. Quando hardware e software sono separati, gli OEM possono sviluppare applicazioni indipendenti per gestire funzioni e servizi specifici. Questo metodo semplifica l'aggiornamento e l'aggiunta di software alla piattaforma complessiva del veicolo.

I produttori di automobili e i loro fornitori sono incoraggiati a regolare le proprie operazioni automobilistiche per consentire cicli di sviluppo software agile, flessibili e adattabili per brevi cicli di sviluppo e rilasci frequenti. Questi cicli consentono di garantire la collaborazione e il miglioramento continuo.

Senza una strategia standardizzata, aperta e configurabile della toolchain, gli OEM potrebbero avere un panorama di strumenti sparsi. Per una strategia di sviluppo software veramente agile, le aziende devono avere una toolchain unificata basata su una piattaforma moderna basata sul cloud nativa di Azure. La piattaforma deve consentire agli sviluppatori di collaborare e riutilizzare il software. Deve fornire agli sviluppatori di terze parti la possibilità di creare applicazioni. La piattaforma è particolarmente utile per gli sviluppatori che hanno una forte esperienza software, ma non un'esperienza hardware precedente.

Questa architettura di esempio automobilistica soddisfa le esigenze del settore automobilistico in rapida evoluzione. Applica il principio di spostamento a sinistra, che sottolinea l'integrazione anticipata dei componenti software e hardware. Consente test e convalida continui a partire dalle prime fasi dello sviluppo. La virtualizzazione svolge un ruolo fondamentale, consentendo la creazione di prototipi virtuali e ambienti di test per accelerare l'innovazione e ridurre i requisiti dei prototipi fisici.

Il cuore di questa architettura è la solida automazione della pipeline CI/CD, che garantisce una perfetta integrazione, test e distribuzione di aggiornamenti software nel ciclo di vita del veicolo. Questa agilità consente aggiornamenti software rapidi, che risoleno tempestivamente vulnerabilità di sicurezza, migliorano le prestazioni e offrono nuove funzionalità. Consente ai consumatori di offrire ai consumatori un'esperienza di guida sicura e ricca di funzionalità.

Il diagramma seguente mostra una panoramica generale dell'architettura della toolchain SDV per automobili.

Scaricare un file PowerPoint di questa architettura.

Potenziali casi d'uso

• Onboarding per sviluppatori: implementare un ambiente di sviluppo automobilistico completamente configurato per accelerare l'onboarding di sviluppatori di software automotive.

• Sviluppo efficiente: simulare il comportamento di varie combinazioni hardware e software. Ridurre la dipendenza dal processore perimetrale o nel veicolo all'inizio del processo di sviluppo.

• Convalida SIL: eseguire pipeline di compilazione, test e convalida automatizzate per convalidare il comportamento dell'applicazione software. Usare le risorse di calcolo nel cloud per un ciclo di sviluppo più rapido.

• Convalida HIL: semplificare la distribuzione e il monitoraggio delle farm HIL.

• Convalida della flotta di test: raccogliere metriche, log e tracce software delle applicazioni software, nonché dati di telemetria del veicolo e dati di segnale. Usare tali dati per creare una visualizzazione completa del comportamento del veicolo per la convalida, l'analisi della causa radice e l'approvazione.

• Versioni software: creare versioni software tracciabili che possono essere aggiornate e gestite per la flotta di veicoli tramite le procedure DevOps.

• Miglioramento continuo: usare le informazioni raccolte dal campo per migliorare le applicazioni software.

Consigli

I consigli seguenti consentono di garantire una gestione efficace dell'ambiente Azure. Attenersi a queste raccomandazioni, a meno che non si disponga di un requisito per eseguirne l'override.

• Seguire le procedure consigliate quando si distribuiscono e si configurano i servizi di Azure per garantire un ambiente sicuro, efficiente e conveniente.

• Definire le risorse di Azure in base ai requisiti di implementazione. Queste risorse possono includere macchine virtuali, cluster Kubernetes, servizi di messaggistica e servizi di analisi e dati.

• Implementare modelli di Resource Manager per l'infrastruttura come codice (IaC) in modo da automatizzare la distribuzione e mantenere la coerenza.

• Implementare il controllo degli accessi in base al ruolo per concedere autorizzazioni a utenti e servizi in base ai privilegi minimi.

• Usare Centro sicurezza di Azure per monitorare e mitigare in modo proattivo le minacce alla sicurezza.

• È consigliabile usare i servizi di bilanciamento del carico di Azure e i set di disponibilità o le zone di disponibilità per migliorare la scalabilità e la ridondanza.

• Monitorare regolarmente le prestazioni e l'utilizzo delle risorse di Azure in modo da ottimizzare i costi e migliorare le prestazioni. Usare strumenti come Monitoraggio di Azure e Gestione costi Microsoft.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

È possibile eseguire un'infrastruttura di applicazioni end-to-end orientata ai servizi e supporta l'implementazione di una piattaforma di protocollo di comunicazione distribuita in Azure con ci/CD moderno. Se si usa questa soluzione, è necessaria un'architettura affidabile e a disponibilità elevata. Per indicazioni sull'architettura e procedure consigliate per la gestione e l'esecuzione di servizi nel servizio Azure Kubernetes, vedere Panoramica del servizio Azure Kubernetes.

I test HIL sono una parte essenziale e indispensabile del processo di sviluppo del software automobilistico e della strategia di test. Quando si progetta e implementa l'architettura di rete per le farm HIL, è consigliabile progettare per la disponibilità elevata con ExpressRoute. Usare questa strategia per ridurre singoli punti di errore e ottimizzare la disponibilità di ambienti remoti per i team di sviluppo e test.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

La sicurezza è uno degli aspetti più importanti di un'architettura. Per garantire la sicurezza dei sistemi complessi, è necessario comprendere le condizioni aziendali, sociali e tecniche. Prendere in considerazione l'implementazione delle funzionalità di analisi del codice di GitHub, in modo da trovare e correggere i problemi di sicurezza e i difetti critici nelle prime fasi del processo di sviluppo. GitHub supporta gli standard di codifica AUTOSAR C++ e CERT C++, che consente lo sviluppo di applicazioni di sicurezza funzionale.

Prendere in considerazione la protezione della supply chain end-to-end in GitHub.

Prendere in considerazione l'adozione di Azure Key Vault per mantenere la sicurezza end-to-end quando si gestiscono elementi sensibili e critici per l'azienda, ad esempio chiavi di crittografia, certificati, stringa di connessione e password. I moduli di sicurezza hardware gestiti da Key Vault offrono una soluzione affidabile che fortifica l'intero processo di sviluppo software e supply chain. Con i moduli di protezione hardware gestiti da Key Vault, è possibile usare applicazioni automobilistiche per archiviare e gestire in modo sicuro gli asset sensibili e assicurarsi che rimangano protetti da potenziali minacce alla sicurezza informatica. È possibile migliorare ulteriormente la sicurezza regolando l'accesso e le autorizzazioni per le risorse critiche con il controllo degli accessi in base al ruolo.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

• Quando si creano vECU, assicurarsi che le dimensioni della macchina virtuale corrispondano ai requisiti. Se si modifica la configurazione in modo da usare dimensioni maggiori del necessario, aumenta il costo, soprattutto se più computer operano in parallelo per eseguire attività a esecuzione prolungata.

• Per le attività di compilazione, convalida e test che non sono critiche per il tempo, è consigliabile usare Azure Spot Macchine virtuali. È possibile sfruttare la capacità inutilizzata e comportare risparmi significativi sui costi.

• Se si ha un impegno a consumo di Azure, è consigliabile usare le offerte di partner idonee di Azure Marketplace quando si distribuiscono strumenti di sviluppo e vECU nell'ambiente di esecuzione.

• Per suggerimenti sull'esecuzione di carichi di lavoro di sviluppo dei veicoli autonomi, vedere Creare una soluzione AVOps.

• Copilot offre suggerimenti e completamento automatico del codice in tempo reale, che accelera il processo di sviluppo software. I software engineer automobilistici possono usare Copilot per scrivere codice in modo rapido ed efficiente, riducendo così il tempo di commercializzazione per le nuove funzionalità e gli aggiornamenti dei veicoli.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

La toolchain SDV per automobili abbraccia le principali strategie di ingegneria del software, ad esempio:

• Provisioning dell'ambiente IaC.
• Pipeline CI/CD per la creazione e il rilascio di stack di software per automobili.
• Test automatizzati per la transizione a un approccio di spostamento a sinistra.
• Configurazione come codice per evitare la deriva della configurazione tra gli ambienti.

Prendere in considerazione l'adozione di queste strategie chiave in tutti i carichi di lavoro per coerenza, ripetizione e rilevamento anticipato dei problemi.

Si consideri un'infrastruttura abilitata da Azure Arc per semplificare la governance e la gestione in ambienti cloud e locali di Azure, test HIL e farm di convalida.

L'assistenza basata sull'intelligenza artificiale di Copilot può migliorare la qualità complessiva del codice riducendo la probabilità di errori umani e standardizzando le procedure di codifica. Il codice di alta qualità è fondamentale nel settore automobilistico in cui la sicurezza e l'affidabilità del software sono fondamentali.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.

Determinare le attività nelle pipeline di compilazione e test che è possibile parallelizzare per migliorare l'efficienza delle prestazioni.

Prendere in considerazione l'implementazione di modelli di efficienza delle prestazioni per applicazioni e carichi di lavoro efficienti basati sull'esempio di protocollo di comunicazione distribuita nella sezione successiva.

Distribuire lo scenario

Il tenant principale per Eclipse SDV è un approccio basato sul codice sorgente, che offre flessibilità per l'implementazione. Gli esempi seguenti usano progetti Eclipse esistenti e ne descrivono l'integrazione con i servizi di Azure.

Esempio: Protocollo di comunicazione distribuito in Azure

Eclipse uProtocol è uno dei molti protocolli di comunicazione distribuiti usati nei settori automobilistici. Si tratta di un protocollo di comunicazione a più livelli indipendente dal trasporto basato su standard automotive e Internet esistenti. Fornisce un linguaggio universale per l'individuazione, la sottoscrizione e la messaggistica, che consente alle app e ai servizi eseguiti in un sistema eterogeneo di comunicare tra loro.

La panoramica seguente descrive i servizi necessari per implementare un protocollo di comunicazione distribuito. Questo esempio usa uProtocol e i servizi di Azure.

Panoramica

Scaricare un file PowerPoint di questa architettura.

• I messaggi vengono inviati dal connettore cloud del veicolo a Griglia di eventi. I messaggi vengono trasferiti tramite la definizione uProtocol su MQTT.

• Il gateway cloud è il servizio cloud con cui i dispositivi si connettono per comunicare con il dominio o il dispositivo back-office.

• UStreamer è un dispatcher di eventi che consente alle entità nei dispositivi di comunicare facilmente con vari protocolli di livello di trasporto. Esegue funzionalità, ad esempio il trasferimento di file e il buffer degli eventi. Ad esempio, quando gli eventi passano da un trasporto all'altro, passano attraverso uStreamer. UStreamer è simile a un router IP.

• UBus è un bus di messaggi che invia CES tra gli uES su un trasporto comune. Fornisce funzionalità multicast e inoltro. Funziona come un commutatore di rete.

• UCDS consente agli uES di individuarsi tra loro, tra cui la posizione (indirizzo) e le proprietà.

• USubscription è un servizio di gestione delle sottoscrizioni che gestisce i modelli di progettazione del server di pubblicazione e del sottoscrittore per le entità utente.

• uTwin è una cache locale di eventi pubblicati. UTwin archivia il messaggio pubblicato tramite una chiave primaria. I componenti software locali possono recuperare la chiave. Questa chiave primaria è il nome completo dell'argomento, incluso il nome del dispositivo. La chiave primaria rappresenta un argomento, quindi solo l'ultimo evento di un determinato argomento viene archiviato in uTwin. La raccolta di eventi archiviati in un'istanza uTwin di un dispositivo, le cui chiavi includono un nome di dispositivo specifico, rappresentano il gemello digitale di tale dispositivo. Esempi di eventi del veicolo includono aggiornamenti per pressione pneumatici, posizione finestra, posizione dell'ingranaggio e modalità veicolo (guida o parcheggiata). Gli eventi possono essere qualsiasi informazione pubblicata nel veicolo e utilizzata per il funzionamento del veicolo o l'attivazione delle sue caratteristiche.

• Le entità utente sono applicazioni e servizi che forniscono funzionalità agli utenti finali. Queste app usano le entità di base per l'individuazione, la sottoscrizione e l'accesso al gemello digitale.

La tabella seguente illustra i servizi suggeriti rilevanti per un'implementazione uProtocol in Azure.

Per altre informazioni sui componenti, gli SDK e la documentazione di uProtocol, vedere il repository GitHub uProtocol.

Effettuare il provisioning dei dispositivi per uProtocol

Scaricare un file PowerPoint di questa architettura.

1. Il sistema di fabbrica commissiona il dispositivo del veicolo allo stato di costruzione desiderato. La commissione include l'installazione e la configurazione iniziali del firmware e del software. Come parte di questo processo, il sistema factory ottiene e scrive il certificato del dispositivo. Il provider di infrastruttura a chiave pubblica crea il certificato.

2. Il sistema di fabbrica registra il veicolo e il dispositivo tramite l'API di provisioning del veicolo e del dispositivo.

3. L'applicazione di registrazione del dispositivo registra l'identità del dispositivo nel provisioning del dispositivo e nel registro dei dispositivi.

4. Le informazioni sull'autenticazione e l'autorizzazione vengono archiviate in Microsoft Entra ID.

5. Il sistema factory attiva il client di provisioning dei dispositivi per connettersi al servizio device provisioning. Il dispositivo recupera le informazioni di connessione alla funzionalità broker MQTT assegnata in Griglia di eventi.

6. Il sistema factory attiva il dispositivo per stabilire una connessione alla funzionalità broker MQTT in Griglia di eventi per la prima volta. Griglia di eventi autentica il dispositivo con il certificato radice di autenticazione client ed estrae le informazioni client.

7. Griglia di eventi gestisce l'autorizzazione per gli argomenti consentiti tramite le informazioni sul dispositivo archiviate in Microsoft Entra ID.

8. Il sistema rivenditore OEM attiva la registrazione di un nuovo dispositivo se è necessaria una sostituzione di parte.

Esempio: Stack di software per automobili Eclipse

L'architettura seguente descrive uno stack di software automobilistico basato sui componenti del progetto Eclipse. In questa architettura, Eclipse uProtocol può essere usato come protocollo di comunicazione.

Scaricare un file PowerPoint di questa architettura.

• Eclipse Chariott è un servizio gRPC che fornisce un'interfaccia comune per interagire con le applicazioni. Le applicazioni possono registrarsi con il registro dei servizi di Eclipse Chariott per annunciare le proprie funzionalità e abilitare l'individuazione dei servizi.

• Eclipse Ibeji offre la possibilità di esprimere una rappresentazione digitale dello stato del veicolo e delle sue funzionalità tramite un'architettura estendibile, aperta e dinamica che consente l'accesso all'hardware, ai sensori e alle funzionalità del veicolo.

• Eclipse Freyja è un'applicazione che consente la sincronizzazione tra lo stato del gemello digitale nel veicolo (il gemello digitale dell'istanza) e lo stato del gemello digitale nel cloud (il gemello digitale canonico).

• Eclipse Agemo è un servizio gRPC che fornisce funzionalità di pubblicazione e sottoscrizione per le applicazioni nel veicolo, tra cui Eclipse Ibeji ed Eclipse Chariott.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Daniel Lueddecke | Cloud Solution Architect, Automotive
• Mario Ortegon Cabrera | Principal Program Manager, MCI SDV & Mobility
• Filippina Prezado | Principal Program Manager, MCI SDV & Mobility
• Sandeep Pujar | Principal PM Manager, Messaggistica di Azure
• Ashita Rastogi | Principal Program Manager, Azure Messaging
• Boris Scholl | General Manager, Partner Architect-Azure Cloud & AI

Altri contributori:

• Frederick Chong | Principal PM Manager, MCIGET SDV & Mobility
• Frank Kaleck | Industry Advisor - Manufacturing, Mobility & Automotive
• Mehmet Kucukgoz | Principal PM Manager, hub IoT di Azure

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• GitHub aggiunge il supporto per gli standard di codifica AUTOSAR C++ e CERT C++
• Attività iniziali di Copilot
• Creare e connettersi a una finestra di sviluppo usando il portale per sviluppatori di Dev Box
• Architettura di riferimento per la messaggistica, i dati e l'analisi del settore automobilistico

Risorse correlate

• Creare una soluzione AVOps