Testsystem für embedded black box testing (SPI slave, GPIO, Analog)

[Testsystembauer (Gast)]

Hallo,

für einen Kunden sollen wir ein Testsystem aufbauen, das ein embedded 
Board  (STM32 basiert) als black box testet.
Das embedded Board (UUT - Unit under test nenne ich es mal) hat 
verschiedenste Schnittstellen, die von außen stimmuliert werden sollen. 
Das Testsystem muss folgende Schnittstellen bedienen können:

 - SPI Slave (UUT ist Master!) - ca. alle 1ms eine 20bytes große SPI 
Transaktion.
 - Analoge Signale, die von der UUT ausgewertet werden - Änderungen im 
50ms Bereich.
 - Digitale Signale (Ein- und Außgänge) - Änderungen im 50ms Bereich.
 - CAN Bus - 1MBit

Die Frage ist nun, wie man das am besten angeht. Auf was für einer Basis 
könnte man das Testsystem realisieren (PC mit entsprechender HW 
(Schnittstellenkarten PCIe/USB, aber welche?); Embedded Board mit 
ordentlicher leistung z.B. Zedboard; andere Möglichkeit?)
Das Testsystem soll definierte Testfälle abfahren können und u.U. auch 
auf bestimmte Ereignisse der UUT reagieren können.

Ich bin sehr gespannt auf Ideen/Ansätze.

Danke und Grüße

[Jörg H. (idc-dragon)]

Ich habe mehrere solche Testsysteme konzipiert/gebaut und programmiert, 
für Automotive-Steuergeräte.

Es gibt sündhaft teure Universalsysteme, von Spezialisten einzurichten, 
das wollten wir vermeiden.

Weil die Testfälle durch einen PC gesteuert ablaufen sollen, gilt es 
diesem eine passende Hardware zur Seite zu stellen, die die geforderten 
Schnittstellen hat und die geforderten Echtzeitbedingungen einhalten 
kann. Das ist ein weites Feld...

Angefangen haben wir mit Labjack T7. Unsere letzte Ausbaustufe hat dafür 
einen Arduino Due verwendet, mit einem selbst entwickelten Shield um die 
I/Os wie nötig zu implementieren und auf Stecker zu führen. 
(Level-Shifter, mehr ADCs, CAN Transceiver, einen speziellen SPI-Slave.) 
Das Shield ist ziemlich projektspezifisch. Das hat sich gut bewährt, 
würde ich wieder ähnlich machen, ein passendes Controller-Board suchen 
oder aufbauen, für Interfacing sorgen. Da hat man mehr Kontrolle als mit 
Meßhardware.

Ich habe eine eher generische Firmware gebaut, die zeitgesteuert Befehle 
abarbeitet, die der PC in eine Queue speist und Ergebnisse liest. Das 
Gegenstück auf dem PC ist in Python geschrieben, die Testfälle auch. 
Damit kann man die Tests recht komfortabel formulieren, z.B. vererben. 
Top-Level ist pytest, als Framework für Testdurchführung und 
Zusammenfassung der Ergebnisse.

Sowas kann man an ein CI-System anschließen und automatisiert 
Regression-Tests durchführen. Soweit sind wir aber nicht gegangen.

Bevor die Frage kommt, das ist nicht Open Source, sondern auch für eine 
Firma gebaut. Vielleicht lizensieren sie es ja, ist nicht Kernkompetenz 
sondern Mittel zum Zweck.

Dein System scheint weniger komplexe Anforderungen zu haben. Einzige 
Herausforderung ist der SPI Slave. Wir haben sowas in Hardware auf dem 
Shield implementiert. Der Arduino Due kann zwar auch SPI Slave sein, die 
Echtzeitanforderungen waren uns aber im konkreten Fall zu riskant.

Viele Grüße
Jörg