Interfaccia di controllo

Ho letto casualmente su Ars Technica un interessante articolo che riporta i risultati dell’inchiesta della Marina statunitense sulla collisione, avvenuta lo scorso 21 agosto, fra il cacciatorpediniere John S. McCain e un mercantile nello stretto di Singapore.

A parte la mia passione per lo studio del funzionamento dei gruppi, devo alla mia amicizia con il mio compagno di Banca Etica Massimo Marinacci, che è un pilota d’aereo, un certo interesse per procedure e controlli nel lavoro di squadra in situazioni potenzialmente pericolose, come è pilotare un aereo (o condurre una sala operatoria).

L’articolo descrive un fallimento di questo genere. Sono anche andato alla fonte e ho letto direttamente il rapporto d’inchiesta della Marina, che riguarda anche il caso molto simile di un’altra nave, la Fitzgerald, ma il caso della John S. McCain è peculiare perché non ha a che fare solo con il mancato rispetto di procedure di base (per esempio, chiamare via radio l’altra nave per decidere chi passa da una parte e chi dall’altra, segnalare acusticamente il pericolo, eccetera), con l’obbedienza agli ordini o con la chiarezza delle comunicazioni fra i vari ufficiali e marinai, ma anche con l’interfaccia di controllo per guidare la nave (dimenticatevi il timone a ruota dei pirati, le navi ora sono guidate con joystick, trackball e menù a tendina sullo schermo).

La dinamica dell’incidente, infatti, è questa: la nave avanzava a una velocità non proprio bassa (20 nodi) in una zona di mare trafficata, con altre imbarcazioni a breve distanza e una forte corrente laterale, per compensare la quale il timoniere stava virando lievemente a tribordo. Il capitano, vedendo il timoniere molto impegnato, ordina che un ufficiale di guardia lo aiuti prendendo il controllo della velocità su una consolle ausiliaria, mentre il timoniere avrebbe continuato a virare.

Solo che i due fanno un pasticcio perché non leggono bene il menù e all’ufficiale di guardia viene trasferito anche il controllo del timone – che ovviamente non utilizza. In questa condizione il timone si orienta semplicemente al centro della nave e l’effetto della corrente comincia a farsi sentire, portando la prua della nave verso babordo.

Il timoniere si allarma e comunica che il timone non risponde più. Il comando viene quindi spostato a una terza consolle ausiliaria in un altro punto della nave, al momento non presidiata, quindi nessuno riprende immediatamente a timonare: questo non è un problema di interfaccia, evidentemente, ma è un problema di interfaccia il fatto che a questo punto il comandante ordini di ridurre la velocità e che l’ufficiale di guardia non si accorga che le eliche sono disaccoppiate.

Ok, questo va spiegato. I motori della nave sono due ed è possibile che entrambi muovano entrambe le eliche oppure che uno comandi l’elica di sinistra e l’altro l’elica di destra (serve a dare più manovrabilità). In precedenza le due eliche erano state disaccoppiate e quindi per ridurre la velocità non si doveva dare un solo input ma due: evidentemente la segnalazione della condizione delle eliche non è immediatamente visibile e l’ufficiale di guardia non ha capito la situazione (c’era un altro menù a tendina da consultare). Sfortuna ulteriore vuole che il  motore la cui velocità non viene ridotta sia quello di destra, così il risultato netto è che la virata a sinistra della nave aumenta, non più solo per effetto della corrente ma anche per la differente spinta delle eliche.

Il resto segue la stesa linea: il comandante ordina di ridurre ancora la velocità, e siccome viene controllata solo l’elica dal lato sbagliato la differenza di velocità fa sì che la virata della nave aumenti ancora di più. Per di più i timonieri stanno pasticciando in modo simile: la consolle ausiliaria riprende il comando ma il timoniere principale non se ne accorge e riprende anche lui i controlli, col risultato che timona tu-no timono io il timone resta sempre in posizione centrale. Poi il secondo timoniere riprende il controllo lui un’altra volta: alla fine ci saranno cinque persone che in due minuti hanno preso uno dopo l’altro il controllo del timone.

Questa scena, che a raccontarla così sembra fantozziana, non dura molto: appena tre minuti. E non c’è niente da ridere: sono andati a sbattere e sono morti dieci marinai (nella collisione della Fitzgerald altri sette).

Simulatori e narrazioni

Le analisi successive della Marina si sono concentrate sul mancato rispetto di procedure standard e sull’intreccio diabolico fra una carenza di formazione e capacità di comunicazione da una parte e scarsa comprensibilità dell’interfaccia utente dei comandi dall’altra.

La raccomandazione è di fare più formazione, molta più formazione, ed è qui che lo sviluppatore di videogame che sta dentro di me (molto in fondo, lo ammetto) ha avuto un attimo di sussulto.

Intanto mi sono chiesto: come farà la sua formazione al pilotaggio delle navi la Marina degli Stati Uniti?

Ovvio, con un simulatore.

Certamente ore e ore passate sul simulatore possono far sì che uno sappia istintivamente che deve controllare se le eliche sono disaccoppiate o meno o se sta accettando solo il trasferimento del controllo della velocità o di tutti i comandi.

Il problema che mi pongo, astrattamente, è: sarà sufficiente? Per la Marina degli Stati Uniti immagino di sì, nel senso che dopo gli incidenti sono cadute le teste di un buon numero di ufficiali, compresi due ammiragli, quindi c’è da immaginare che d’ora in poi staranno tutti più attenti.

Molto più attenti.

Ma in generale credo di no, nel senso la pura simulazione dell’uso dei comandi non può essere sufficiente: non riesce a catturare tutto. Per esempio nel caso del volo Air France 447 un errore a uno degli strumenti di bordo causò una catena di eventi che portò alla perdita dell’aereo e di tutte le vite umane a bordo. Molti altri piloti, successivamente, hanno provato a prendere i comandi del simulatore nelle stesse condizioni del guasto e sono riusciti a portare a termine la simulazione correttamente; è evidente che l’interazione dei rapporti umani dentro la cabina, le difficoltà di comunicazione e tutto il resto non sono riproducibili dal solo simulatore dei comandi.

Serve una narrazione: qualcosa che ti faccia vivere il fatto che il comandante dà un ordine non programmato, il tuo compagno fa un errore imprevisto, nessuno prende un’azione risolutiva e la situazione precipita velocemente. Oppure: sei il sottufficiale più alto in grado sul ponte di comando, il comandante è a riposare, l’ufficiale di guardia è inesperto ma non vuole disturbare il comandante nonostante si stia verificando una situazione imprevista, il radar è guasto e il GPS intasato di segnalazioni, le vedette sono sul lato sbagliato, l’altro ufficiale sul ponte confonde le tre navi che vi stanno tagliando la rotta e quelli della sala di battaglia, dove ci sono gli altri radar, non rispondono al citofono (è il caso della Fitzgerald).

Serve una narrazione che integri la simulazione dell’uso dell’interfaccia. E una narrazione più un’interfaccia di controllo è un gioco (un videogame, in questo caso).

Mi è sembrata una bella dimostrazione del valore dei giochi narrativi come strumento per la formazione e la comprensione del mondo. C’è tutto un mondo di serious game finalizzati a questo scopo: quello che sto suggerendo qui è che i serious game per essere efficaci debbano essere anche narrativi.

Avevo un ricordo vago di qualcosa che poteva essere una controprova e me lo sono andato a cercare, trovando conferma. C’è un vecchio articolo che avevo segnalato sullo staff tecnologico della campagna di Obama, che gestiva tutto il centro di comando della campagna elettorale: e questi si allenavano per possibili imprevisti nel giorno delle elezioni facendo… giochi di ruolo, con un vero e proprio master che poneva scenari: cosa facciamo se c’è un blackout che colpisce la costa ovest e taglia le comunicazioni? Se qualcuno cancella per errore il database degli elettori dell’Ohio? Se salta il software che collega tutti i rappresentanti di lista?

Narrazioni, appunto.