Technologie PCB - Comment repérer les défauts logiciels lors de la conception de PCB

Comment éviter ces erreurs cachées mais courantes de bogues logiciels dans le processus de conception de PCB et introduire plusieurs techniques pour aider les ingénieurs à trouver les erreurs cachées dans le logiciel PCB Replica Board (www.pcbwork.net). La plupart des projets de développement logiciel reposent sur une combinaison de vérification de code, de tests structurels et de tests fonctionnels pour identifier les défauts logiciels. Bien que ces techniques traditionnelles soient si importantes qu'elles peuvent détecter la plupart des problèmes logiciels, elles ne peuvent pas détecter de nombreuses erreurs courantes dans les systèmes complexes d'aujourd'hui.

Les tests structurels ou les tests de boîte blanche peuvent être efficaces pour détecter les erreurs de logique, de flux de contrôle, de calcul et de données dans le Code. Ce test nécessite une vue d'ensemble du fonctionnement interne du logiciel (d'où le nom "boîte blanche" ou "boîte en verre") pour comprendre les détails de la structure du logiciel. Il examine chaque expression conditionnelle, opération mathématique, entrée et sortie. Comme de nombreux détails doivent être testés, les tests de structure examinent une unité logicielle à la fois, généralement une fonction ou une classe.

L'examen du Code utilise également les mêmes techniques sophistiquées que la mise en œuvre de la détection de défauts et de problèmes potentiels. Comme pour les tests de la boîte blanche, chaque unité du logiciel est généralement examinée, car un processus d'examen efficace nécessite un examen centralisé et détaillé.

Contrairement à la censure et aux tests de boîte blanche, les tests fonctionnels ou les tests de boîte noire supposent une ignorance de la mise en œuvre du logiciel. Il teste la sortie pilotée par une entrée contrôlée. Les tests fonctionnels se composent de programmes de test écrits par un testeur ou un développeur. Ils spécifient les sorties de programme attendues qui correspondent à un ensemble spécifique d'entrées de programme. Une fois le test exécuté, le testeur compare la sortie réelle à la sortie attendue pour déterminer le problème. Les tests de boîte noire peuvent être efficaces pour détecter les besoins non satisfaits, les problèmes d'interface, les problèmes de performance et les erreurs dans les fonctions les plus courantes du programme.

Bien que la plupart des erreurs cachées dans des programmes logiciels spécifiques puissent être découvertes en combinaison avec ces techniques, elles ont également des limites. La révision du Code et les tests de la boîte blanche ne ciblent qu'une petite partie du Code à la fois, tout en ignorant le reste du système. Les tests de boîte noire traitent généralement le système dans son ensemble, ignorant les détails de mise en œuvre. Certains problèmes importants ne peuvent être découverts qu'en prêtant attention aux détails de leur interaction dans l'ensemble du système; Les méthodes traditionnelles ne permettent pas d'identifier ces problèmes de manière fiable. Un examen global du système logiciel doit être effectué pour déterminer la cause spécifique d'un problème particulier. Comme il n'est généralement pas possible d'analyser en profondeur chaque détail d'un programme et son interaction avec toutes les autres parties du Code, l'analyse doit porter sur des aspects spécifiques du programme qui sont connus pour causer des problèmes.

Cet article explorera trois domaines potentiellement problématiques:

* débordement de pile

* conditions de concurrence

Impasse

Les lecteurs peuvent lire la deuxième partie de cet article en ligne, qui explorera les questions suivantes:

* problèmes de temps

* conditions de rentrée

Tous les problèmes ci - dessus sont courants dans les systèmes utilisant la technologie de conception en temps réel multitâche.

Débordement de pile

Le processeur utilise la pile pour stocker des variables temporaires, passer des paramètres à la fonction appelée, enregistrer l'état du thread, etc. si le système n'utilise pas de mémoire virtuelle (En d'autres termes, il ne peut pas transférer des pages de mémoire sur le disque pour libérer de l'espace mémoire pour d'autres utilisations), la pile est fixée à la taille du produit lorsqu'il quitte l'usine. Si, pour une raison quelconque, la pile est hors de portée de l'allocation du programmeur, le Programme devient incertain. Cette instabilité peut entraîner de graves défaillances du système. Il est donc important de s'assurer que le système est capable d'allouer suffisamment de piles dans le pire des cas.

La seule façon de s'assurer qu'un débordement de pile ne se produise jamais est d'analyser le Code, de déterminer l'utilisation maximale de la pile du programme dans tous les cas possibles, puis de vérifier si suffisamment de piles sont allouées. Il est peu probable que ce test déclenche une combinaison particulière d'entrées instantanées et entraîne le pire scénario pour le système.

Le concept de l'analyse en profondeur de la pile est relativement simple:

1. Créez un arbre d'appel pour chaque thread indépendant.

2. Déterminez l'utilisation de la pile pour chaque fonction dans l'arbre d'appel.

3. Vérifiez chaque arbre d'appel pour déterminer quel chemin d'appel de la racine de l'arbre à la "feuille" externe nécessite le plus de piles.

4. Ajoutez l'utilisation maximale de la pile pour chaque arbre d'appel de thread indépendant.

5. Déterminez l'utilisation maximale de la pile pour chaque routine de service d'interruption (ISR) dans chaque priorité d'interruption et calculez le total. Toutefois, si l'ISR lui - même n'a pas de pile, mais utilise une pile qui interrompt les Threads, le nombre maximal de piles utilisées par l'ISR doit être ajouté à la pile de chaque thread.

6. Pour chaque priorité dans la disposition et la conception du PCB, ajoutez le nombre de piles utilisées pour sauvegarder l'état du processeur lorsque l'interruption se produit.

Si vous utilisez RTOS, ajoutez le nombre maximal de piles nécessaires à l'utilisation interne de RTOS lui - même (contrairement aux appels système causés par le Code d'application inclus à l'étape 2).

En outre, il y a deux choses importantes à considérer. Tout d'abord, une arborescence d'appels construite uniquement à partir du code source d'un langage de haut niveau peut être incomplète. La plupart des compilateurs utilisent des bibliothèques d'exécution pour optimiser les tâches de calcul courantes telles que la multiplication et la Division d'entiers de grande valeur, les opérations en virgule flottante, etc. ces appels ne sont visibles que dans le langage assembleur généré par le compilateur. L'exécution des fonctions de bibliothèque elles - mêmes peut prendre beaucoup d'espace de pile et elles doivent être incluses dans l'analyse. Si vous utilisez le langage C + +, tous les types de fonctions (méthodes) suivants doivent également être inclus dans l'arbre d'appel: Corps de structure, destructeurs, opérateurs de surcharge, structures de réplication et fonctions de transformation. Tous les pointeurs de fonction doivent également être analysés et les fonctions qu'ils appellent sont incluses dans l'analyse.