In der heutigen schnelllebigen Welt, in der Elektronikiterationen mit Lichtgeschwindigkeit durchgeführt werden, vergessen wir oft einen der kritischsten Aspekte der Entwicklung: das Testen. Es ist immer leicht, das Testen zu übersehen, einfach weil es die letzte Stufe ist, die uns davon abhält, unser Produkt auf den Markt zu bringen. In der Produktentwicklung befinden wir uns ständig im Lager von „gut genug“ versus „erschöpfend getestet“. Diese Situation tritt normalerweise auf, weil wir keine Zeit haben zu testen, erneut zu testen und dann noch mehr zu testen.
In der besten aller Situationen hätten wir ein vollständiges Testteam eingestellt, das ausgestattet ist, um erschöpfende Tests durchzuführen. Selbst wenn wir dieses ausgeklügelte Testteam haben, sind wir wirklich in der Lage, sie für jede Modifikation, jede kleine und unbedeutende Änderung, die wir an unseren Prototypen vornehmen, zu nutzen? In den meisten Fällen lautet die Antwort nein, und in diesem Artikel möchte ich das Problem mit einer Lösung angehen, bei der Sie Ihren Kuchen haben und ihn auch essen können. In diesem Artikel werden wir ein sehr kostengünstiges, dennoch hochwirksames und ziemlich erschöpfendes Testsystem überprüfen, das Ihnen das Preis-Leistungs-Verhältnis bietet, nach dem Sie gesucht haben.
Es ist in der Industrie durchaus üblich, eine automatisierte Testumgebung einzurichten (hauptsächlich für Tests auf Produktionsebene). Für die Produktentwicklung ist dies jedoch keine gängige Praxis. Wie oben erwähnt, erfordern die Kosten und die Entwicklungszeit für die Einrichtung von ausgefeilten automatisierten Testgeräten einen hohen Aufwand. Diese Art von Kosten und Aufwand ist nur für die Produktion in großen Mengen oder für geringe Mengen mit sehr ausgeklügelten Testkonfigurationen gerechtfertigt (z.B. Raumfahrtsysteme in geringer Stückzahl, die viele Male umwelttechnisch getestet werden müssen). Für den Rest der Welt greifen wir auf grundlegende, mühsame manuelle Tests zurück. Diese Art von Tests kann von ADC/DAC-Validierung, Protokollprüfungen, Tests des Energieverbrauchs usw. reichen. Unabhängig vom Testtyp besteht die Hoffnung, dass er nur einmal oder zweimal durchgeführt werden muss und dann an die Testgruppe "über die Mauer geworfen" werden kann.
Die Realität ist, dass wir während unserer Entwicklung, sei es in den Phasen des Hardware-Designs/Respins oder der eingebetteten Softwareentwicklung, unbeabsichtigt etwas zum Ausfall bringen. Einige Beispiele könnten eine Lötbrücke über Pads oder Treibercode sein, der in andere Treibercodes übergeht und so einen Ausfall verursacht. Unabhängig vom Ergebnis ist klar, dass Tests nicht nur ein- oder zweimal stattfinden. Probleme treten auf, und erschöpfende Tests sind in der Regel zu anstrengend, um sie nach dem zehnten Mal des Überarbeitens einer Platine durchzuführen. Die offensichtliche Antwort auf das Problem ist, automatisierte Systeme erschöpfende Regressionstests durchführen zu lassen. Aber was ist die Lösung für den eingebetteten Ingenieur, der wenig Geld und Zeit hat, um ein umfassendes automatisiertes Testsystem zu entwickeln?
Für eingebettete Systeme gibt es eine kostengünstige, dennoch sehr skalierbare und praktische automatisierte Testlösung. Obwohl sie nicht perfekt ist, bietet sie dem Entwicklungsingenieur die höchste Rendite für seine Investition. Das Konzept besteht darin, ein einfaches Gerät zu verwenden, das analoge Signale steuern, analoge Signale lesen, verschiedene serielle Protokollströme generieren und Wellenformen analysieren kann. Ein Beispiel für ein kostengünstiges Gerät, das solche Spezifikationen besitzt, ist das Analog Discovery 2. Obwohl es sich um ein 5V-Gerät handelt, hat es dennoch viel zu bieten. Ich betrachte es als mein Schweizer Taschenmesser für die Entwicklung eingebetteter Systeme. Es gibt andere vergleichbare Produkte auf dem Markt, aber ich habe festgestellt, dass dieses Gerät besonders gut für meine Anwendungen funktioniert. Das Gerät kann über Ihren Desktop-Computer oder sogar einen Raspberry Pi betrieben werden. Es verfügt auch über eine Python-Bibliothek, die es dem Benutzer ermöglicht, schnell Testabläufe zusammenzustellen. Zur Vereinfachung habe ich die vollständige Konfiguration dockerisiert und für alle Architekturen erstellt.
Lassen Sie uns ein reales Beispiel betrachten, das in diesem Repository gefunden werden kann. Der Einfachheit halber wird unser eingebettetes Ziel ein Arduino Duo sein. Unten sehen Sie, wie unser vollständiges Test-Setup aussieht:
Die Idee hier ist zu demonstrieren:
Warum sollten wir so etwas automatisieren wollen? Nehmen wir an, wir arbeiten eine Platine in der Nähe des ADC um, oder jemand ändert die Treiber, die mit dem ADC interagieren. Sind wir zu 100% sicher, dass ein einfaches manuelles ADC-Lesen mit ein paar gedrehten Knöpfen an einem Netzteil ausreicht, um unsere Hardware/Software zu testen? Wenn nicht, warum lassen wir nicht die Automatisierung jede Permutation und jeden Sonderfall abdecken, sodass wir es nicht müssen? Und nur um sicher zu gehen, warum nicht dasselbe 100 Mal durchführen... einfach weil wir es können! Dies kann viel ausgefeilter und komplizierter werden (z.B. Protokolltests, ADC-Filtertests usw.), aber dieser Artikel wird sich nur auf die Grundlagen beschränken.
Das Testskript ist ziemlich einfach. Vorausgesetzt, Ihr Arduino (d.h., das zu testende eingebettete Gerät) wurde mit den richtigen Programmierdateien geladen und alles wurde ordnungsgemäß angeschlossen, würden Sie das Testskript auf Ihrem Computer wie folgt ausführen:
python -m pytest test_arduino_hil.py
Dies wird den Analog Discovery 2 auslösen, um durch den Spannungsbereich des ADC des Arduino zu fegen und zu validieren, dass die Eingangsspannung mit der vom ADC abgelesenen Ausgangsspannung übereinstimmt. Anstatt manuell mit einem Tischgerät zu fegen, hat das Skript es für Sie mit einem einzigen Befehl erledigt. Für ein triviales Beispiel wie dieses scheint es unnötig, aber dieser Prozess zahlt sich aus, wenn Tests in einer regressionsähnlichen Weise kombiniert werden.
In Verbindung mit unserem CI/CD-System können wir die folgenden Stufen sehen, die ausgeführt und bestanden werden:
Die oben abgebildeten Stufen sind:
Wenn wir uns den Abschnitt Tests genauer ansehen, können wir feststellen, dass diese Tests von Gitlab erfasst und analysiert wurden:
Wir haben jetzt eine Softwarekonfiguration, die es uns ermöglicht, unser Design lokal und ferngesteuert zu testen (mit unserem CI/CD-System). Dies ermöglicht es dem Entwicklungsingenieur, sich weiterhin auf das Design zu konzentrieren, anstatt auf Tests und Debugging später.
In diesem Artikel haben wir das Konzept der Verwendung von automatisierten Tests zur Validierung eines Designs gleichzeitig und nachträglich überprüft. Ob es sich um eine kleine Überarbeitung oder eine monumentale Designänderung handelt, automatisierte Regressionstests zahlen sich aus, wenn es darum geht, unbeabsichtigte Konsequenzen auszuschließen (d.h., ein Problem beheben, ein anderes verursachen). Der empfohlene Prozess besteht darin, diese Testskripte parallel zum Designentwicklungsprozess zu schreiben (ähnlich wie Testgetriebene Entwicklung). Diese automatisierten Tests in Verbindung mit einem CI/CD-System zu nutzen, bietet den zusätzlichen Vorteil, zu demonstrieren, dass unsere Boards auf einem entfernten Ziel funktionieren und jederzeit und überall von jedem getestet werden können.
Möchten Sie mehr darüber erfahren, wie Altium Ihnen bei Ihrem nächsten PCB-Design helfen kann? Sprechen Sie mit einem Experten bei Altium oder entdecken Sie mehr über die häufigsten DFM-Probleme und ihre Lösungen. Hier können Sie eine kostenlose Testversion von Altium Designer herunterladen.