Il codice, qui, muove qualcosa.

E quando muove la cosa sbagliata non si torna indietro con un aggiornamento. Un motore ha già fatto quel movimento, un pezzo si è già spostato, a volte c’è una persona seduta sopra.

È la ragione per cui questo software si scrive in un altro modo. E soprattutto si prova in un altro modo.

Dove si complica

Cinque problemi che il software tradizionale non ha.

La prova

Non si prova cliccando

Per sapere se una logica funziona serve il pezzo fisico che si muove, o una simulazione fedele di come si comporta. Il ciclo scrivi-prova-correggi è più lento e più costoso, e va messo in conto quando si stimano i tempi.

Il tempo

Un attuatore non aspetta

Un ritardo che su uno schermo nessuno noterebbe, qui diventa un movimento fuori tempo. Le tolleranze sono strette e non si recuperano con più potenza di calcolo: si recuperano scrivendo il codice in un altro modo.

La distanza

Il dispositivo non è dove sei tu

Sta in una sala, in un capannone, su un impianto. Aggiornarlo, capire perché si è fermato, e sapere in che stato è senza andarci di persona sono tre problemi separati, e vanno risolti prima di installarne cento.

Il confine

Quando non funziona, serve chi legge entrambi i lati

Fra chi ha fatto la meccanica e chi ha scritto il software c’è una zona grigia dove i problemi si rimbalzano. Serve qualcuno che sappia leggere tutti e due i lati abbastanza da dire dove sta la cosa, invece di difendere il proprio pezzo.

Il campo

Quello che è già installato resta installato

Un aggiornamento sbagliato su un dispositivo che sta a duecento chilometri non si annulla premendo un tasto. Ogni modifica va pensata sapendo che il ritorno indietro costa un viaggio.

Dove l’abbiamo fatto

Mechit — software di controllo per simulatori di guida.

Prima

Simulatori installati in sale aperte al pubblico: cabine che si muovono su attuatori, comandi che devono rispondere subito, e una gestione della sala che deve funzionare senza un tecnico presente.

Dopo

Il software delle schede che comandano i motori, le interfacce per chi usa la macchina, e il sistema che gestisce la sala.

Perché conta

Il pezzo che manca sta sempre in mezzo.

Chi costruisce macchine ha ingegneri che sanno tutto della parte meccanica. Le software house sanno fare applicazioni. Nel mezzo c’è la riga di codice che traduce un comando in un movimento, e non è il mestiere pieno di nessuno dei due.

È il punto in cui i progetti si fermano: non perché manchi la competenza, ma perché quella competenza sta divisa fra due fornitori che si rimbalzano il problema.

Non facciamo la macchina. Facciamo la parte che la fa muovere.

Non è questa la pagina, se

Serve automazione industriale certificata.

Il mondo dei controllori industriali ha tecnologie, norme e certificazioni proprie, e non è il nostro mestiere. Se quello che ti serve vive dentro una linea di produzione con requisiti di sicurezza certificati, ti serve qualcun altro — e conviene saperlo adesso.

Noi lavoriamo su schede programmabili di uso generale: quelle che comandano un motore, leggono un sensore, aprono un varco, parlano con un server.

Come si comincia

Se la parte software non esiste ancora, si parte dal capire cosa serve davvero e cosa costa — Build Plan. Se esiste, funziona a metà, e nessuno riesce a dire di chi è il problema, la porta è Rescue.

Se invece sai già cosa va fatto e vuoi vedere come lavoriamo prima di impegnarti, c’è il Dry Run: due settimane, e finisce lì.

Astrorei · When software matters

Quando il software diventa
una questione di business.