Schwerpunkte

Effiziente Teststrategien von Bittium

Software-Framework-Ansatz vereinfacht Produktionstest

26. November 2020, 13:30 Uhr   |  Nicole Wörner


Fortsetzung des Artikels von Teil 1 .

Framework implementiert den Protokollkern

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 Hardwareblock-bezogene 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.«

Deutlich geringerer Aufwand

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 I2C-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 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
  • 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 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 Embedded-Programmierung, 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 C implementiert«, 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.«

Seite 2 von 2

1. Software-Framework-Ansatz vereinfacht Produktionstest
2. Framework implementiert den Protokollkern

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Verwandte Artikel

elektroniknet