Un Tesla Cybercab impegnato in un servizio robotaxi ad Austin è stato fermato da un problema software durante una prova su strada. L’episodio, raccontato da MotorTrend dopo una serie di corse effettuate nel fine settimana di lancio del servizio, non riguarda una dimostrazione in ambiente controllato: avviene nell’uso ordinario di un veicolo chiamato tramite app, senza conducente a bordo e con un passeggero che si aspetta di raggiungere la propria destinazione.

È un dettaglio rilevante per Tesla e, più in generale, per l’industria della guida autonoma. Nei robotaxi il software non si limita a gestire infotainment, navigazione o funzioni accessorie: coordina la prenotazione, l’arrivo del mezzo, la marcia, le fermate, l’accesso all’abitacolo e la chiusura della corsa. Quando qualcosa va storto, l’effetto immediato non è un semplice disservizio digitale. È un’auto che può non completare il suo compito di trasporto.

Una prima corsa senza problemi, poi l’interruzione

Il test era iniziato in modo regolare. Il Cybercab è stato richiesto attraverso l’app Tesla Robotaxi, che mostrava tempi previsti per il prelievo e la destinazione, oltre a una stima della tariffa. Il veicolo è arrivato dopo 17 minuti, in linea con la previsione indicata, pur fermandosi a una certa distanza dall’ingresso dell’hotel da cui era stata richiesta la corsa.

L’identificazione del mezzo è affidata anche a una barra luminosa colorata, coordinata con l’indicazione visualizzata nell’app. Avvicinandosi al veicolo, una delle due porte ad apertura verso l’alto si apre automaticamente; il movimento rallenta se il sistema rileva una persona troppo vicina. Le porte si richiudono dopo l’allacciamento della cintura di sicurezza.

La prima tratta, breve e diretta verso una caffetteria, è stata descritta come fluida. A bordo, il passeggero può seguire su schermo percorso e rappresentazione delle decisioni di guida, con un’impostazione che richiama quella dell’interfaccia Tesla Full-Self Driving (Supervised). L’abitacolo dispone di prese USB-C, comandi per i finestrini e di un bracciolo centrale regolabile; l’uscita è assistita da immagini provenienti da tre telecamere e da comandi sul display per aprire porte e bagagliaio.

La fase di discesa, però, evidenzia già quanto l’esperienza sia diversa da un’auto tradizionale o da un taxi con autista. Il Cybercab ha effettuato la fermata dall’altro lato della strada e non davanti alla porta della destinazione. È un aspetto apparentemente marginale, ma nella mobilità a chiamata la qualità del servizio passa anche da questi metri finali: attraversamenti, accessibilità per chi ha bagagli o mobilità ridotta, sicurezza dell’area di salita e discesa.

La situazione è cambiata durante il tentativo di tornare all’hotel. La prova è stata interrotta da un glitch software che ha messo fuori uso la corsa. I dettagli tecnici del malfunzionamento non sono stati resi disponibili nel materiale consultato: non è quindi possibile attribuirlo con certezza alla guida autonoma, all’app, alla connettività, ai sistemi di bordo o alla gestione remota della flotta. È una distinzione necessaria, perché in un servizio robotaxi l’intera catena digitale contribuisce al risultato percepito dal cliente.

Il test reale comincia quando il veicolo non completa la missione

Il Cybercab nasce come prodotto dedicato al trasporto autonomo e non come variante di un’auto privata adattata successivamente al servizio. Questo rende l’episodio più significativo sul piano industriale. Una flotta senza conducente viene valutata per la capacità di svolgere corse ripetibili, recuperare anomalie, assistere il passeggero e tornare rapidamente disponibile, non soltanto per le prestazioni nei tragitti che vanno a buon fine.

Un errore software può avere molte conseguenze operative: un utente bloccato a metà della procedura, un veicolo immobilizzato, un intervento da remoto, l’eventuale invio di assistenza fisica e un mezzo sottratto temporaneamente alla flotta. Ciascuno di questi passaggi incide sulla fiducia nel servizio e sul costo per corsa. L’assenza di un conducente elimina un costo potenziale, ma trasferisce una parte della complessità verso ingegneria del software, infrastruttura di supporto, monitoraggio e gestione delle eccezioni.

È proprio qui che la definizione di software-defined vehicle assume un significato concreto. L’auto può migliorare, correggersi e ricevere nuove funzioni tramite aggiornamenti; allo stesso tempo, il software diventa un punto di vulnerabilità capace di bloccare un’intera funzione del prodotto. Nel caso di un veicolo personale, un malfunzionamento può creare disagio al proprietario. Nel caso di un robotaxi, coinvolge contemporaneamente passeggero, operatore della flotta e disponibilità del servizio sul territorio.

Non basta dunque misurare quante corse autonome siano concluse o quanti chilometri vengano percorsi. Per capire la maturità di un’operazione occorrono dati sulle anomalie, sui tempi di ripristino, sulle modalità con cui viene offerta assistenza agli utenti e sulla frequenza con cui un errore viene risolto con un aggiornamento invece che con un intervento sul posto. Il caso di Austin non fornisce questi numeri, ma mostra esattamente perché saranno importanti.

Prezzi e servizio: la prova non riguarda soltanto la guida

La prima corsa ha sollevato anche una questione economica. Per un tragitto di 0,8 miglia, circa 1,3 chilometri, il costo addebitato è stato di 12,68 dollari: 15,85 dollari per miglio. Tesla applica una tariffazione dinamica, e il prezzo può essere letto nel contesto di un servizio appena avviato e di una domanda particolarmente alta nel weekend di debutto. Resta tuttavia un valore molto superiore alla fascia da 1 a 2 dollari per miglio attribuita nel test ai tradizionali servizi di ride-hailing.

La tariffa dinamica è una pratica nota nel trasporto a chiamata, ma nel robotaxi acquista un peso ulteriore. Se il servizio costa sensibilmente più delle alternative umane, l’esperienza deve offrire affidabilità e convenienza tali da giustificare la scelta. Una corsa interrotta da un bug non è perciò soltanto un inconveniente tecnico: mette pressione sulla promessa commerciale nelle prime fasi di adozione, quando i clienti stanno ancora decidendo se considerare il mezzo un esperimento o un’opzione quotidiana.

Anche i dettagli dell’esperienza a bordo parlano della natura ancora sperimentale del modello. I finestrini si abbassano soltanto di pochi centimetri; i sedili sono piatti e pensati per un uso intensivo più che per lunghi viaggi; dopo la corsa l’app propone una valutazione e una mancia. La cabina è silenziosa e il comportamento del veicolo nella prima tratta è stato giudicato rassicurante, ma il servizio deve funzionare come sistema, dall’ordine al prelievo fino alla conclusione e alla fatturazione.

Che cosa Tesla dovrà dimostrare adesso

Un singolo guasto non basta a definire l’affidabilità di una piattaforma, soprattutto nei primi giorni di disponibilità pubblica. Sarebbe altrettanto improprio trattarlo come irrilevante. Le aziende che operano robotaxi, da Tesla a Waymo e Zoox, stanno portando nel traffico reale servizi che dipendono dalla capacità del software di affrontare non solo il normale svolgimento di una corsa, ma anche ogni deviazione dalla norma.

Per Tesla il passaggio successivo sarà dimostrare come il servizio reagisce agli incidenti software: quali strumenti riceve il passeggero, quanto rapidamente viene ripristinata la corsa o fornita un’alternativa, quale supporto interviene e se il problema può essere corretto sull’intera flotta. Finché questi aspetti resteranno opachi, gli utenti valuteranno i robotaxi non soltanto per la qualità della guida autonoma, ma per la loro capacità di non trasformare un tragitto semplice in un problema logistico.

Il test di Austin restituisce quindi un quadro meno lineare del debutto: una prima esperienza di guida completata senza particolari difficoltà, un prezzo elevato nel periodo di lancio e una corsa successiva fermata da un’anomalia software. È il genere di stress test che nessuna presentazione può simulare fino in fondo, perché è nella routine della città che un robotaxi deve dimostrare di essere un servizio di trasporto prima ancora che un prodotto tecnologico.

Fonti