Leiterplattentechnisch - So finden Sie Softwarefehler im PCB-Designprozess

Wie man diese versteckten, aber häufigen Softwarefehler in der PCB-Design Prozess, und Einführung mehrerer Techniken, um Ingenieuren zu helfen, die versteckten Fehler in der Leiterplatte (www.pcbwork.net) software. Die meisten Softwareentwicklungsprojekte basieren auf einer Kombination von Code-Inspektion, Strukturtests und Funktionstests zur Identifizierung von Softwarefehlern. Obwohl diese traditionellen Techniken sehr wichtig sind und die meisten Softwareprobleme finden können, Sie können viele häufige Fehler in heutigen komplexen Systemen nicht erkennen.

Strukturtests oder White-Box-Tests können Logik-, Steuerungsfluss-, Berechnungs- und Datenfehler im Code effektiv finden. Dieser Test erfordert einen Überblick über die interne Arbeit der Software (daher der Name \"white box\" oder \"glasbox\") um die Details der Softwarestruktur zu verstehen. Es prüft jeden bedingten Ausdruck, jede mathematische Operation, Eingabe und Ausgabe. Aufgrund der vielen Details, die getestet werden müssen, überprüft Strukturtests jeweils eine Softwareeinheit, in der Regel eine Funktion oder Klasse.

Code Reviews verwenden auch die gleichen komplexen Techniken wie Implementierungsfehler und potenzielle Problemfindung. Wie White-Box-Tests werden Prüfungen in der Regel für jede Einheit der Software durchgeführt, da ein effektiver Prüfprozess zentralisierte und detaillierte Prüfungen erfordert.

Im Gegensatz zu Review- und White-Box-Tests gehen Funktionstests oder Black-Box-Tests davon aus, dass über die Implementierung der Software nichts bekannt ist. Es prüft die von kontrollierten Eingängen angetriebenen Ausgänge. Funktionstests bestehen aus Testverfahren, die von Testern oder Entwicklern geschrieben wurden. Sie geben die erwartete Programmausgabe an, die einem Satz spezifischer Programmeingänge entspricht. Nachdem der Test ausgeführt wurde, vergleicht der Tester die tatsächliche Ausgabe mit der erwarteten Ausgabe, um das Problem zu finden. Black Box Tests können effektiv unerfüllte Anforderungen, Schnittstellenprobleme, Leistungsprobleme und Fehler in den am häufigsten verwendeten Funktionen des Programms finden.

Obwohl die Kombination dieser Techniken die meisten Fehler finden kann, die in einem bestimmten Softwareprogramm verborgen sind, haben sie auch Einschränkungen. Codeüberprüfung und Whitebox-Tests zielen nur auf einen kleinen Teil des Codes auf einmal ab, wobei der Rest des Systems ignoriert wird. Black Box Testing behandelt normalerweise das System als Ganzes und ignoriert die Implementierungsdetails. Einige wichtige Probleme können nur entdeckt werden, wenn man sich auf die Details ihrer Interaktion im gesamten System konzentriert; Traditionelle Methoden können diese Probleme nicht zuverlässig identifizieren. Das Softwaresystem muss als Ganzes überprüft werden, um die spezifische Ursache des spezifischen Problems zu finden. Da es in der Regel unmöglich ist, jedes Detail im Programm und seine Interaktion mit allen anderen Teilen des Codes gründlich zu analysieren, sollte die Analyse auf die spezifischen Aspekte des Programms gerichtet sein, die bekanntermaßen Probleme verursachen.

In diesem Artikel werden drei potenzielle Problembereiche untersucht:

*Stapelüberlauf

*Wettbewerbsbedingungen

*Stillstand

Leser können den zweiten Teil dieses Artikels online lesen, der die folgenden Themen untersucht:

Zeitliche Probleme

*Wiedereintrittsbedingungen

Alle oben genannten Probleme sind recht häufig in Systemen, die Multi-Task Echtzeit-Design-Technologie verwenden.

Stapelüberlauf

Der Prozessor verwendet den Stack, um temporäre Variablen zu speichern, Parameter an die aufgerufene Funktion zu übergeben, den Thread "Status" zu speichern und so weiter. Wenn das System keinen virtuellen Speicher verwendet (mit anderen Worten, es kann keine Speicherseiten auf die Festplatte übertragen, um Speicherplatz für andere Zwecke freizugeben), wird der Stack auf die Größe des Produkts fixiert, wenn es die Fabrik verlässt. Wenn der Stack aus irgendeinem Grund außerhalb des vom Programmierer zugewiesenen Bereichs geht, wird das Programm unsicher. Diese Instabilität kann schwerwiegende Systemausfälle verursachen. Daher ist es wichtig sicherzustellen, dass das System im schlimmsten Fall genügend Stapel zuweisen kann.

Der einzige Weg, um sicherzustellen, dass ein Stack-Überlauf nie auftritt, ist, den Code zu analysieren, die maximale Stack-Nutzung des Programms unter allen möglichen Umständen zu bestimmen und dann zu überprüfen, ob genügend Stack zugewiesen ist. Es ist unwahrscheinlich, dass der Test eine bestimmte Kombination von Soforteingängen auslöst und das Worst-Case-Szenario im System verursacht.

Das Konzept der Stapeltiefenanalyse ist relativ einfach:

1. Erstellen Sie einen Aufrufbaum für jeden unabhängigen Thread.

2. Bestimmen Sie die Stapelnutzung jeder Funktion im Aufrufbaum.

3. Überprüfen Sie jeden Aufrufbaum, um festzustellen, welcher Aufrufpfad von der Wurzel des Baums zum äußeren "Blatt" den meisten Stapel erfordert.

4. Fügen Sie die maximale Stapelnutzung jedes unabhängigen Thread-Aufrufbaums hinzu.

5. Bestimmen Sie die maximale Stapelnutzung jeder Interrupt Service Routine (ISR) in jeder Interrupt Prioritätsstufe und berechnen Sie die Summe. Wenn der ISR selbst jedoch keinen Stack hat und den Stack des unterbrochenen Threads verwendet, sollte die maximale Anzahl von Stacks, die der ISR verwendet, dem Stack jedes Threads hinzugefügt werden.

6. Für jede Priorität in Leiterplattenlayout und Design, Fügen Sie die Anzahl der Stacks hinzu, die verwendet werden, um den Prozessorstatus zu speichern, wenn ein Interrupt auftritt.

7.Wenn Sie RTOS verwenden, fügen Sie die maximale Anzahl an Stacks hinzu, die für die interne Nutzung des RTOS selbst erforderlich sind (anders als der Systemaufruf, der durch den Anwendungscode verursacht wird, der in Schritt 2 enthalten ist).

Darüber hinaus gibt es zwei wichtige Dinge zu beachten. Erstens ist ein Aufrufbaum, der nur aus hochrangigem Sprachquellcode erstellt wurde, wahrscheinlich unvollständig. Die meisten Compiler verwenden Laufzeitbibliotheken, um gängige Rechenaufgaben zu optimieren, wie Multiplikation und Division von großen Ganzzahlen, Gleitkommaoperationen usw. Diese Aufrufe sind nur in der vom Compiler generierten Assemblersprache sichtbar. Die Laufzeitbibliotheksfunktionen selbst können viel Stapelplatz beanspruchen und müssen in die Analyse einbezogen werden. Wenn Sie die Sprache C++++ verwenden, müssen auch alle folgenden Arten von Funktionen (Methoden) in der Aufrufstruktur enthalten sein: Strukturen, Destruktoren, überladene Operatoren, Kopierstrukturen und Konvertierungsfunktionen. Alle Funktionszeiger müssen ebenfalls geparst werden und die von ihnen aufgerufenen Funktionen werden in die Analyse einbezogen.