Interfacce hardware software di integrazione/test unità

Question

Sto lavorando a piccoli progetti divertenti che costruiscono un robot. Noi programmatori stiamo lavorando parallelamente alle persone che costruiscono il robot. Quindi è molto spesso il caso che stiamo cercando di eseguire il software modificato ei costruttori hanno cambiato l'hardware. Se i test del software non sono in esecuzione, è sempre difficile capire se il software o l'hardware falliscono o, peggio ancora, se l'integrazione fallisce. Ci sono alcune parti difficili con un test automatico per questo problema.

Abbiamo escogitato alcuni modi per rompere le cose, quindi abbiamo il controllo RC per consentire al robot di eseguire alcuni movimenti senza software assicurando che funzioni ancora. Quindi iniziamo alcuni test del software che fanno in modo che il robot vada in cifre definite per mostrare che il software si comporta allo stesso modo di prima. Ma questo si riduce sempre a un'attività che richiede molto tempo perché non è possibile automatizzarlo e qualcuno deve avviare il test, guardare il test e cercare di capire se il robot ha fatto ciò che dovrebbe fare.

Un altro problema è che test costanti con il nostro hardware reale stanno consumando parti del nostro hardware, giunto, motori, ruote dentate e così via.

Ma il test non ha dimostrato di causare così tanti problemi e consumare così tanto tempo che mi piacerebbe sapere che tipo di tecniche sono utilizzate in altri progetti che si occupano dell'interazione del software hardware e se ci sono strumenti là fuori che possono essere usato.

Answer 1

L'interfaccia tra il robot e il software deve essere definita per prima; non necessariamente esaustivamente, questo potrebbe essere fatto in modo incrementale. Inizia in piccolo, ad esempio con mosse di base (avanti, indietro), quindi, una volta che è stato completamente testato, sia in isolamento che integrato, aggiungi qualche comportamento (ad esempio, gira a sinistra, gira a destra), prova nuovamente. In questo modo, l'intero team può utilizzare ciò che ha appreso durante il progetto per estendere l'interfaccia, riducendo al minimo i reinterventi dell'interfaccia.

L'articolo Progress before Hardware descrive un tale processo con maggiori dettagli, concentrandosi sull'aspetto Test-Driven-Development (TDD).

Vedere anche le risposte alla domanda How to do TDD with hardware.

Answer 2

Penso che sia una situazione molto interessante.

Credo non ci siano problemi con il processo di test. Se prendi in giro il tuo robot e prova contro questo finto, va tutto bene.
Se il robot hardware si comporta in modo diverso come il tuo robot deriso, c'è un altro grosso problema: La comunicazione.

L'interfaccia tra il software e l'hardware è la specifica del "protocollo". Secondo me non deve essere cambiato senza discussione. I ragazzi dell'hardware non possono cambiarlo e anche voi ragazzi del software no! Puoi solo cambiarlo insieme. Nella tua situazione, tutti lo cambiano da solo.

Nella vostra situazione, le vostre squadre sembrano lavorare l'una contro l'altra. Quindi cerca di concentrare i tuoi sforzi nell'interfaccia e in particolare nella comunicazione, non nel test di integrazione che non funzionerà comunque.

Un mio suggerimento sarebbe quello di utilizzare un software di un robot simulato come l'unica specifica. Quindi puoi contare sulla tua simulazione e c'è un punto centrale che definisce la connessione tra hardware e software.
Quando i ragazzi del software vogliono cambiarlo, ok. Devono discuterne con te e cambierai il software simulato. Se l'hardware è stato modificato e la simulazione no, hai delle scuse, perché sviluppi contro le tue specifiche.

Buona fortuna!