Diagnostica remota integrata

Diagnostica remota integrata - IL FUTURO DELLA DIAGNOSTICA REMOTA

 

La capacità di diagnosticare un veicolo è un aspetto molto importante dell'architettura del veicolo. L'approccio più comune seguito nell'industria automobilistica è quello di accedere a tutti i dati diagnostici (DTC, valori di misurazione, ecc.) attraverso la porta OBD-II del veicolo. Sul mercato sono disponibili strumenti che aiutano i tecnici dell'assistenza ad accedere allo stato dei diversi sottosistemi del veicolo in base alla risoluzione dei problemi e ad applicare le procedure di riparazione. Tuttavia, l'approccio dello strumento di assistenza può risolvere il problema solo quando il tecnico è fisicamente presente sul luogo del veicolo.

 

Mentre la mobilità diventa la norma in tutti i settori, la diagnostica remota dei veicoli non può certo essere considerata un'eccezione. Con un maggiore livello di incorporazione dell'elettronica e del software nei veicoli, le aspettative dei clienti per la riduzione dei tempi di fermo e di manutenzione sono in aumento. Sulla base di questa dinamica di cambiamento dei clienti, l'industria sta anticipando e prendendo in considerazione soluzioni che consentano una diagnostica completa dei veicoli in luoghi remoti.

 

Oggi sono disponibili sul mercato numerose soluzioni che affermano di essere competenti nella diagnosi remota tramite i dongle OBD-II. Tuttavia, queste soluzioni sono in grado di leggere solo le informazioni diagnostiche relative alle norme sulle emissioni, limitando così il valore aggiunto per il tecnico dell'assistenza da un punto di vista diagnostico complessivo (On & Off-board).

 

L'approccio diagnostico incorporato (presentato in questo articolo) utilizza come base i componenti infrastrutturali specificati nello standard ISO (cioè ODX, OTX), aprendo così la strada a un'architettura data-driven. I componenti dell'infrastruttura diagnostica di bordo consentono una comunicazione continua con la rete della centralina in modo simile al funzionamento dello strumento di assistenza, permettendo così l'esecuzione di tutti i casi d'uso diagnostici da postazioni remote.

 

 

 

Diagnostica integrata:

 

Visione dell'ecosistema

 

L'intera soluzione è costituita da 5 componenti principali. Unità di controllo telematica (TCU), tempo di diagnostica, sequenze OTX, dati ODX e server diagnostico per supportare le funzioni diagnostiche.

 

La TCU fornisce l'ambiente e le risorse necessarie per l'esecuzione di Diagnostic-Runtime per eseguire vari casi d'uso come la lettura dell'identificatore di dati (DID), la scansione del veicolo, la riprogrammazione, ecc.

Il runtime diagnostico fornisce componenti di infrastruttura per la comunicazione diagnostica in rete (CAN, Ethernet, ecc.). I componenti dell'infrastruttura comprendono API diagnostiche, OTX runtime, API D-Server e API D-PDU. Le API diagnostiche forniscono un livello di comfort in cima ai componenti D-Server e OTX Runtime per fornire un livello di comfort per i casi d'uso di ingegneria, fine linea e assistenza post-vendita. Si tratta di un componente che può essere personalizzato in base ai requisiti diagnostici.

 

OTX Runtime fornisce un ambiente per eseguire le procedure OTX e ottenere i risultati definiti. Le API del D-Server definiscono un'interfaccia di programmazione delle applicazioni orientata agli oggetti per la misurazione e la regolazione e i servizi diagnostici. Le API D-PDU definiscono l'interfaccia di programmazione delle applicazioni per astrarre la comunicazione attraverso i protocolli diagnostici e la descrizione del modulo Modular Vehicle Communication Interface (MVCI).

 

Il server diagnostico ospita l'applicazione che implementa l'HMI per l'utente finale e comunica anche con la TCU per lo scambio di informazioni diagnostiche. La comunicazione tra il server diagnostico e la TCU avviene tramite protocolli di messaggistica standard, come il Message Queuing Telemetry Transport (MQTT), in quanto l'affidabilità della trasmissione dei dati è la massima priorità.

 

Architettura di riferimento [A]

 

L'architettura di cui sopra presuppone che le risorse hardware necessarie siano disponibili all'interno della TCU. Se la TCU presenta limitazioni delle risorse hardware, l'architettura è molto flessibile per supportare tali limitazioni, se presenti.

 

In uno scenario con risorse limitate, è possibile implementare solo i componenti leggeri dell'API D-PDU sulla TCU e il resto dei componenti (API diagnostiche, OTX Runtime, API D-Server) può essere implementato sul server remoto.

 

Di seguito viene presentato il concetto di tale architettura [B].

La selezione dell'architettura richiede un'analisi di compromesso in termini di requisiti aziendali, ad esempio il supporto per la modalità online/offline, i casi d'uso richiesti (funzionalità di servizio completo rispetto alla sola riprogrammazione), ecc.

 

Sfide

 

Se da un lato l'approccio descritto in questo articolo consente di ottenere capacità diagnostiche di nuova generazione, dall'altro pone alcune sfide che devono essere affrontate per diventare un candidato valido per la produzione. Alcune di queste sfide sono indicate di seguito:

 

Gestione delle condizioni del veicolo

Ad esempio, lo stack diagnostico di bordo deve garantire di non sovraccaricare il traffico di rete o interferire con le funzioni del veicolo in caso di guasto.

Sicurezza

I contenuti diagnostici disponibili a bordo e da/verso i dati della TCU devono essere altamente protetti per impedire l'accesso non autorizzato ad essi

Aggiornamenti software

Disponibilità dell'infrastruttura necessaria per supportare gli aggiornamenti over-the-air in caso di guasto dei componenti software della TCU.

Larghezza di banda della cella

Assicurare l'uso ottimale della larghezza di banda cellulare per la trasmissione dei dati tra il server diagnostico e la TCU.

Risorse hardware limitate all'interno della TCU

Il software in esecuzione all'interno della TCU deve essere molto efficiente per operare entro il limite di disponibilità delle risorse, e allo stesso tempo deve garantire che le altre applicazioni della TCU non abbiano un impatto

 

Conclusioni

 

 

I componenti software citati in questo articolo esistono già e sono utilizzati nella produzione di vari casi d'uso per l'ingegneria, la produzione e i servizi post-vendita. Inoltre, sempre più OEM stanno introducendo le TCU come componente fondamentale dell'architettura dei loro veicoli. Il rapido cambiamento delle tendenze tecnologiche, l'evoluzione delle aspettative dei clienti e un mercato altamente competitivo spingeranno gli OEM e i fornitori di TCU ad adottare un approccio dichiarato per costruire i sistemi diagnostici del futuro. In KPIT abbiamo già assistito a questa tendenza con i nostri clienti tecnologicamente avanzati. La piattaforma di diagnostica e connettività di KPIT (K-DCP) è già in produzione (in ambiente embedded) e serve casi d'uso come l'interfacciamento over-the-air delle centraline e la diagnostica remota.

 

Prospettive future

 

La diagnostica integrata dei veicoli ha il potenziale per generare vantaggi lungo tutta la catena del valore del settore automobilistico. All'estremità della catena, gli OEM possono trarre enormi vantaggi dalla riduzione dei costi associati ai richiami dei veicoli e dalle richieste di garanzia senza colpa (NTF), il tutto reso possibile da una diagnostica avanzata e guidata. I rappresentanti del servizio di assistenza beneficeranno di un migliore rapporto Fix-First-Visit, di una riduzione dei tempi e dei costi di assistenza grazie alla diagnostica remota/guidata, di una maggiore efficienza e produttività dei tecnici e, infine, il cliente (proprietario del veicolo) godrà di livelli più elevati di comfort e convenienza grazie alle nuove capacità dei concessionari di assistenza nella manutenzione preventiva/predittiva, con conseguente miglioramento dei tempi di attività del veicolo.

 

Con la prospettiva di creare un vantaggio per tutte le parti coinvolte, è sicuro che lo spazio della diagnostica incorporata continuerà ad evolversi e a crescere e, soprattutto, a trovare sempre più sostenitori!