PCB Tecnico - Come trovare i difetti del software nel processo di progettazione PCB

Come evitare questi errori nascosti ma comuni di difetti software nel processo di progettazione PCB e introdurre diverse tecniche per aiutare gli ingegneri a trovare gli errori nascosti nel software della scheda di copia PCB (www.pcbwork.net). La maggior parte dei progetti di sviluppo software si basa su una combinazione di ispezione del codice, test strutturali e test funzionali per identificare i difetti del software. Sebbene queste tecniche tradizionali siano molto importanti e possano trovare la maggior parte dei problemi software, non possono rilevare molti errori comuni nei sistemi complessi di oggi.

I test strutturali o i test a scatola bianca possono trovare efficacemente errori di logica, flusso di controllo, calcolo e dati nel codice. Questo test richiede una panoramica del lavoro interno del software (da qui il nome \"scatola bianca\" o \"scatola di vetro\") per comprendere i dettagli della struttura del software. Controlla ogni espressione condizionale, operazione matematica, input e output. A causa dei molti dettagli che devono essere testati, i test strutturali controllano un'unità software alla volta, di solito una funzione o una classe.

Le revisioni del codice utilizzano anche le stesse tecniche complesse dei difetti di implementazione e dei potenziali problemi di individuazione. Come i test white box, le revisioni vengono solitamente condotte per ogni unità del software, perché un processo di revisione efficace richiede ispezioni centralizzate e dettagliate.

A differenza dei test di revisione e white box, i test funzionali o i test di black box presuppongono che non si sappia nulla sull'implementazione del software. Testa le uscite guidate da ingressi controllati. I test funzionali sono composti da procedure di test scritte da tester o sviluppatori. Specificano l'output previsto del programma corrispondente ad un insieme di input specifici del programma. Dopo l'esecuzione del test, il tester confronta l'uscita effettiva con l'uscita prevista per trovare il problema. I test della scatola nera possono trovare efficacemente requisiti non soddisfatti, problemi di interfaccia, problemi di prestazioni e errori nelle funzioni più comunemente utilizzate del programma.

Sebbene la combinazione di queste tecniche possa trovare la maggior parte degli errori nascosti in un particolare programma software, hanno anche delle limitazioni. Revisione del codice e test white box mirano solo a una piccola parte del codice alla volta, ignorando il resto del sistema. Il test Black Box di solito tratta il sistema nel suo complesso, ignorando i dettagli di implementazione. Alcuni problemi importanti possono essere scoperti solo concentrandosi sui dettagli della loro interazione nell'intero sistema; i metodi tradizionali non possono identificare in modo affidabile questi problemi. Il sistema software deve essere controllato nel suo complesso per trovare la causa specifica del problema specifico. Poiché di solito è impossibile analizzare accuratamente ogni dettaglio del programma e la sua interazione con tutte le altre parti del codice, l'analisi dovrebbe essere mirata agli aspetti specifici del programma che sono noti per causare problemi.

Questo articolo esplorerà tre potenziali aree problematiche:

* Stack overflow

* Condizioni di concorrenza

* Deadlock

I lettori possono leggere la seconda parte di questo articolo online, che esplorerà i seguenti problemi:

* Problemi di tempistica

* Condizioni di reintroduzione

Tutti i problemi di cui sopra sono abbastanza comuni nei sistemi che utilizzano la tecnologia di progettazione multi-task in tempo reale.

Sovraccarico di pile

Il processore utilizza lo stack per memorizzare variabili temporanee, passare parametri alla funzione chiamata, salvare il thread "stato", e così via. Se il sistema non utilizza memoria virtuale (in altre parole, non può trasferire pagine di memoria su disco per liberare spazio di memoria per altri usi), lo stack sarà fissato alla dimensione del prodotto quando esce dalla fabbrica. Se per qualche motivo lo stack esce dall'intervallo assegnato dal programmatore, il programma diventerà incerto. Questa instabilità può causare gravi guasti al sistema. Pertanto, è importante garantire che il sistema possa allocare abbastanza stack nel peggiore dei casi.

L'unico modo per garantire che non si verifichi mai un overflow di stack è analizzare il codice, determinare l'utilizzo massimo di stack del programma in tutte le circostanze possibili e quindi verificare se è allocato abbastanza stack. È improbabile che il test inneschi una combinazione specifica di input istantanei e causi lo scenario peggiore nel sistema.

Il concetto di analisi della profondità dello stack è relativamente semplice:

1. Creare un albero di chiamata per ogni thread indipendente.

2. Determinare l'utilizzo dello stack di ogni funzione nell'albero delle chiamate.

3. Controllare ogni albero di chiamata per determinare quale percorso di chiamata dalla radice dell'albero alla "foglia" esterna richiede più stack.

4. Aggiungere il massimo utilizzo dello stack di ogni albero di chiamata thread indipendente.

5. Determinare l'utilizzo massimo dello stack di ogni routine di servizio di interruzione (ISR) in ogni livello di priorità di interruzione e calcolare il totale. Tuttavia, se l'ISR stesso non ha uno stack e utilizza lo stack del thread interrotto, il numero massimo di stack utilizzato dall'ISR dovrebbe essere aggiunto allo stack di ogni thread.

6. Per ogni priorità nel layout e nella progettazione PCB, aggiungere il numero di stack utilizzati per salvare lo stato del processore quando si verifica un interruzione.

7. Se si utilizza RTOS, aggiungere il numero massimo di stack necessari per l'uso interno dell'RTOS stesso (diverso dalla chiamata di sistema causata dal codice dell'applicazione, che è incluso nel passaggio 2).

Inoltre, ci sono due cose importanti da considerare. In primo luogo, un albero delle chiamate costruito solo da codice sorgente di lingua di alto livello è probabile che sia incompleto. La maggior parte dei compilatori utilizza librerie run-time per ottimizzare le attività di calcolo comuni, come moltiplicazione e divisione di numeri interi di grande valore, operazioni in virgola mobile, ecc. Queste chiamate sono visibili solo nel linguaggio di assemblaggio generato dal compilatore. Le stesse funzioni della libreria runtime possono utilizzare molto spazio stack e devono essere incluse nell'analisi. Se si utilizza il linguaggio C+++++, nell'albero delle chiamate devono essere inclusi anche tutti i seguenti tipi di funzioni (metodi): strutturatori, distruttori, operatori sovraccaricati, strutture di copia e funzioni di conversione. Tutti i puntatori di funzione devono essere analizzati e le funzioni che chiamano sono incluse nell'analisi.