IoT-Geräte in der Produktion effizienter testen

Anbieter zum Thema

HTV Halbleiter-Test & Vertriebs-GmbH

ISH Ingenieursozietät GmbH

MEV Elektronik Service GmbH

Vernetzte IoT-Geräte werden in hoher Stückzahl produziert. Doch die Testverfahren und die dafür notwendige Testsoftware wurden bisher für jedes Produkt separat entwickelt. Ein Framework-Ansatz soll das ändern.

Die verbundenen Geräte im Internet der Dinge (IoT) sind häufig kleine, batteriebetriebene Produkte mit einer eingeschränkten Funktionalität. Hierbei kann es sich um einen Fitnesstracker handeln, ein Smart-Meter für die Heizung, ein Sensor in einer Fabrik oder ein Gateway im Automobil.

Alle diese Produkte werden in Massen produziert, mit strengen Vorgaben für die Materialkosten und schließlich muss auch die Produktion effizient arbeiten. Ein Blick auf die Herstellung eines IoT-Geräts umfasst die Produktionsprüfung aller Einheiten. Der Aufwand für die Testverfahren war im Verhältnis bisher sehr hoch. Der Grund: Die Testsoftware als Softwaresystem für jedes Produkt muss separat entwickelt werden.

Eine mögliche Abhilfe verspricht ein Software Framework für Produktionstests. Dazu noch einmal ein Blick auf einen typischen Aufbau eines IoT-Gerätes: Dieser umfasst kleine Sensoren, ein einfaches Display und eine möglichst energiesparende Methode zur Kommunikation, beispielsweise über Bluetooth. Die gesamte Software wird von einer MCU (Micro Controller Unit) ausgeführt, die den größten Teil der Steuerlogik enthält, die zur Steuerung der zusätzlichen Funktionen erforderlich ist. Das kann beispielsweise Datenerfassung über Sensoren oder die Kommunikation über Bluetooth.

Hardwarekomponenten testen

Nach der Oberflächenmontage (SMD) wird jede Einheit getestet, um sicherzustellen, dass alle Hardwarekomponenten ordnungsgemäß gelötet wurden, keine Kurzschlüsse festgestellt werden und die Teile der Einheit im Allgemeinen ordnungsgemäß funktionieren. Sobald die produzierte Einheit die Produktionstests im Werk bestanden hat, wird die endgültige Software mit SKU-Konfiguration für die Artikelidentifikation installiert, das Produkt wird verpackt und ist nun bereit für den Kunden.

Der Produktionstest ist üblicherweise die erste Phase, in der das Gerät eingeschaltet wird und in den meisten Fällen mit dem Ausführen von Software beginnt. Die dazu verwendete Software wird als Production Testing Software (PTSW) bezeichnet.

Die Produktionstests selbst bestehen aus drei separaten Einheiten: der PTSW in dem zu testenden Gerät (DUT – Device Under Test), einer Automatisierungssoftware zur Steuerung der Test-Ausführung und zum Sammeln der Ergebnisse, sowie die Hintergrunddatenspeicherung zum Sammeln und Speichern der Ergebnisse für jede Einheit, identifiziert durch eine Seriennummer.

Den Produktionstest überdenken

Bisher wurde die Testsoftware als Softwaresystem für jedes Produkt separat entwickelt und die meisten Tests als Software innerhalb der MCU ausgeführt. Das Entwicklungsmodell erzeugte viele verschiedene Architekturen mit unterschiedlichen Designs und einer großen Vielfalt an Software, die im Grunde eine einfache Aufgabe erledigt: Hardwarekomponenten auf Existenz und korrekte Funktion zu testen.

Um den Ablauf eines Produktionstests zu überdenken, muss man sich den Kern des PTSW anschauen, was allen Produktionstests gemeinsam ist und ob sich Programmabläufe verallgemeinern lassen. Die Entwickler bei Bittium haben die Software in Schichten aufgeteilt und verallgemeinerten die Kommunikation, den Hardwarezugriff und die Testlogik so weit wie möglich. Dazu die folgenden Grundsätze:

• Testsprache unverändert beibehalten: gemeinsames Kernprotokoll mit der Automatisierung,

• Hardware so weit wie möglich generalisieren, um das Testen von Hardwareblöcken zu vereinfachen,

• Testlogik so weit wie möglich in die Automatisierung verschieben (außerhalb DUT) sowie

• Unterstützung für produktspezifische Erweiterungen beibehalten.

Mit diesem Ansatz ließ sich die nächste Generation von Software-Frameworks für Produktionstests als Kerndesign für das Protokoll erstellen und eine Spezifikation für die HAL (Hardware Abstraction Layer) entwickeln, die für jedes Produkt verwendet wird. Da das Framework den Protokollkern implementiert, beschränken sich die restlichen Schritte lediglich auf produktspezifische und Hardwareblock-bezogene Implementierungen.

Da der größte Teil der Software fertig und getestet ist, können die grundlegenden Teile der HAL-Software für das neue Produkt in Stunden statt in Wochen und Monaten erstellt werden. Da das Protokoll gleich bleibt, kann auch die Testlogik außerhalb der Software entwickelt werden. Diese Logik wiederum kann für verschiedene Produkte wiederverwendet werden.

Testprozesse und Aufwand verringern

Ein einfaches Beispiel für den Testansatz betrachtet zwei verschiedene Produkte, die denselben Sensor-IC (Integrated Circuit) und denselben Anzeige-IC enthalten – aber unterschiedliche Hardware. Beispielsweise können beide ICs über einen I²C-Bus (Inter-Integrated Circuit) mit den Produkt-MCUs verbunden sein. Das ist eine typische Architektur für Sensoren (und für einige Displays). Die Produktionstests für diese beiden Produkte, ihre Sensor und Display-Anzeige könnten ungefähr so aussehen:

• Testen, ob der Sensor an der Adresse „Ap“ gelötet ist und Identifikation zurückmelden,

• Prüfen, ob der Sensor den korrekten Druckwert liefert,

• Testen, ob das Display an der Adresse „Ad“ gelötet ist und Identifikation zurückmelden sowie

• Testen, ob auf dem Display Text und/oder Pixel korrekt angezeigt werden.

In diesem Fall hängen alle Tests von der getesteten Hardware ab. Die Kommunikationsschnittstellen sind in den Hardwarespezifikationen des Sensors und der Anzeigekomponenten beschrieben. Die Schnittstellen hängen nicht von der MCU ab, an die sie angeschlossen sind – abgesehen vom erforderlichen I²C-Bus.

Bei den beiden Produkten sind insgesamt nur vier Tests nötig, da die Testlogik bei einem Produktwechsel gleich bleibt und die ICs für Sensor und Anzeige bei beiden Geräten gleich sind. Bei der traditionellen Testmethode wären insgesamt acht Tests notwendig. Ein weiterer Vorteil: Sollte ein Sensor gegen einen anderen ausgetauscht werden müssen, ändert sich an der Software nichts. Die Testbefehle lassen sich aus der Spezifikation des neuen Sensors auslesen. Der Testfall wird mithilfe eines Texteditors auf die Automatisierung aktualisiert. Vorteil für den Entwickler: Es sind weniger Embedded-Programmierungen notwendig.

* Timo Räty ist Senior Principal Engineer bei Bittium. Seit 2013 trägt er zur Entwicklung der Software-Assets von Bittium bei.

(ID:46973000)