IoT-Geräteentwicklung Framework-Ansatz vereinfacht Produktionstest für IoT-Devices

Anbieter zum Thema

Parasoft® Deutschland GmbH

NetModule AG

TXOne Networks

Wo bislang ein verhältnismäßig hoher Aufwand für den Test von IoT-Geräten betrieben werden musste, könnte ein Software Framework für mehr Effizienz in diesem Bereich sorgen. Wie das aussehen kann, lesen Sie hier.

Devices für das Internet of Things sind häufig kleine, batteriebetriebene Produkte mit eingeschränkter Funktionalität – ob es sich um einen Fitnesstracker handelt, ein Smart Meter für die Heizung, ein Sensor in einer Fabrik oder ein Gateway für ein Automobilsystem. Diese Produkte werden in der Regel in Massenproduktion hergestellt, mit strengen Vorgaben für die Materialkosten (BOM - Bill of Materials) und Produktionseffizienz. Die Herstellung von IoT-Geräten umfasst die Produktionsprüfung aller Einheiten.

Der Aufwand für diese Testverfahren war bisher im Verhältnis sehr hoch, da die Testsoftware als Softwaresystem für jedes Produkt separat entwickelt wurde. Das verlangsamt die Produktion und erhöht die Kosten. In diesem Beitrag zeige ich auf, welche Vorteile ein Software Framework für Produktionstests bietet und welche Grundsätze für den Aufbau eines solchen Frameworks beachtet werden sollten.

Wie ein IoT-Gerät entsteht

Der typischer Aufbau eines IoT-Devices 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 Regulierung der zusätzlichen Funktionen erforderlich ist – beispielsweise Datenerfassung über Sensoren oder die Kommunikation über Bluetooth. Nach der Oberflächenmontage (SMD) muss jede Einheit getestet werden, 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 Zum Beispiel durch eine Seriennummer.

Datenanalyse mit Bots

IIoT-Einstieg: Schlüsselfertige Komplettlösungen und vordefinierte Analytic-Bots

Bisher war es meist üblich, die Testsoftware als Softwaresystem für jedes Produkt separat zu entwickeln und die meisten Tests als Software innerhalb der MCU auszuführen. Dieses 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.

Grundsätze für ein Produktionstest Software Framework

Das Überdenken der Produktionstests begann mit einem Blick auf den Kern des PTSW, was allen Produktionstests gemeinsam ist und ob dies verallgemeinert werden könnte. Dazu teilte unser Team die Software in Schichten auf und verallgemeinerte die Kommunikation, den Hardwarezugriff und die Testlogik so weit wie möglich. Dies geschah nach folgenden Grundsätzen:

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

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

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

• Unterstützung für produktspezifische Erweiterungen beibehalten

Mit diesem Ansatz wurde die nächste Generation von Software-Frameworks für Produktionstests als Kerndesign für das Protokoll erstellt und eine Spezifikation für die HAL (Hardware Abstraction Layer) entwickelt, 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. Dies allein verkürzt die Entwicklungszeit erheblich. 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.

Risikoanalyse, Segmentierung und Bedrohungsprävention:

Cybersicherheit für IoT

Deutliche Verringerung von Testprozessen und Aufwand

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. Nehmen wir zur Demonstration an, dass beide ICs über einen I2C-Bus (Inter-Integrated Circuit) mit den Produkt-MCUs verbunden sind. Dies ist eine typische Architektur für Sensoren (und für einige Displays). Die Produktionstests für diese beiden Produkte, ihre Sensoren und Displays 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

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

In diesem Fall hängen all diese 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 I2C-Bus.

Bei den beiden Produkten sind insgesamt nur vier Tests nötig, da die Testlogik auch bei einem Produktwechsel gleich bleibt und auch die ICs für Sensor und Anzeige bei beiden Geräten identisch sind. Bei der traditionellen Testmethode hätten insgesamt acht Tests durgeführt werden müssen.

Industrial Internet of Things

Werkzeugmaschinen werden fit für IIoT-Anwendungen

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. Dies bedeutet weniger Embedded-Programmierung, was eine schnellere Änderung des Testsystems bedeutet.

Um die Portierung des Systems auf eine neue Plattform zu vereinfachen und die Ressourcenmenge gering zu halten, wurden diese Kernfunktionalitäten fast ausschließlich in C implementiert. Darüber hinaus wurden die Portierungsaufgaben optimiert, um Entwicklungen mit sogenannten Continuous Integration (CI) Systemen zu unterstützen. Mithilfe der Beispielcodes, die normalerweise vom MCU-Lieferanten in seinem Board Support Package (BSP) bereitgestellt werden, können die Softwareentwickler die anfängliche Portierung des Frameworks sehr schnell durchführen.

Der Ansatz des automatisierten Software Frameworks hat sich bewährt, um die Effizienz und Kosteneinsparungen bei Tests zur Herstellung von IoT-Geräten deutlich zu verbessern.

* Timo Räty arbeitet als Senior Principal Engineer bei Bittium.

(ID:47049840)