Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
16 www markttechnik de Nr 48 2020 der SMD-Oberflächenmontage 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 der in den meisten Fällen mit dem Ausführen von Software beginnt« erläutert Räty »Die dazu verwendete Software wird als Production Testing Software kurz 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 der Hintergrunddatenspeicherung zum Sammeln und Speichern der Ergebnisse für jede Einheit identifiziert beispielsweise durch eine Seriennummer « Bisher sei es meist üblich gewesen die Testsoftware als Softwaresystem für jedes Produkt separat zu entwickeln und die meisten Tests als Software innerhalb der MCU auszuführen Dieses Entwicklungsmodell habe viele verschiedene Architekturen mit unterschiedlichen Designs und einer großen Vielfalt an Software erzeugt die im Grunde eine einfache Aufgabe erledigt habe Hardwarekomponenten auf Existenz und korrekte Funktion zu testen Das Überdenken der Produktionstests begann mit einem Blick auf den Kern des PTSW was allen Produktionstests gemeinsam ist Dazu teilte das Bittium-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 Testen von Hardwareblöcken zu vereinfachen •Testlogik so weit wie möglich in die Automatisierung verschieben außerhalb des 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 Weil das Framework den Protokollkern implementiert beschränken sich die restlichen Schritte lediglich auf produktspezifische und Hardwareblockbezogene Implementierungen Dies allein verkürzt die Entwicklungszeit erheblich »Weil 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« unterstreicht der Experte »Und weil das Protokoll gleich bleibt kann auch die Testlogik außerhalb der Software entwickelt werden Diese Logik wiederum kann für verschiedene Produkte wiederverwendet werden « Ein einfaches Beispiel für den Testansatz betrachtet zwei verschiedene Produkte die denselben Sensor-IC und denselben Anzeige-IC enthalten aber unterschiedliche Hardware »Nehmen wir an dass beide ICs über einen I2 C-Bus mit den Produkt-MCUs verbunden sind« so Räty »Dies ist eine typische Architektur für Sensoren und für einige Displays Die Produktionstests für diese beiden Produkte ihre Sensorund 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 •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 I2 C-Bus Bei den beiden Produkten sind insgesamt nur vier Tests nötig da die Testlogik auch bei einem Produktwechsel gleichbleibt und auch die ICs für Sensor und Anzeige bei beiden Geräten gleich sind Bei der traditionellen Testmethode hätten insgesamt acht Tests durgeführt werden müssen « 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 Das bedeutet weniger EmbeddedProgrammierung was wiederum 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 Cimplementiert« schlussfolgert Räty »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 « nw n Fokus|Fertigung Bild Bittium 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