Raspberry Pi im Embedded Testing - „tool“ oder „toy“?
•
2 gostaram•1,190 visualizações
Der Vortragstitel scheint etwas demonstrativ, ist aber eine Hypothese für ein reales Testprojekt in dem Hard- und Softwareprodukte für die Musikproduktion automatisch und entwicklungsbegleitend integriert und getestet werden. Weitere Herausforderung sind die Agilität der Entwicklung und häufigere Releases durch die Einführung von Scrum. Wie bindet man nun eine größere Anzahl eingebetteter Systeme kostengünstig in eine Continuos Integration Umgebung ein? Muss es dafür immer teure DACQ Hardware sein? Dieser Anwenderbericht gibt eine Übersicht der verwendeten Technologien und bewertet Kosten sowie Nutzen des gewählten Ansatzes. Referentenprofil*: Michel Lawaty ist Test Automation Engineer bei der Native Instruments GmbH und arbeitet an Hardware- und Softwareprodukten für die Musikproduktion. Er ist seit 2009 in verschiedenen Bereichen wie Medical, Broadcast und Audio als professioneller Software Tester, Test Automator und Test Manager tätig.
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (11)
Semelhante a Raspberry Pi im Embedded Testing - „tool“ oder „toy“?
Semelhante a Raspberry Pi im Embedded Testing - „tool“ oder „toy“? (20)
Raspberry Pi im Embedded Testing - „tool“ oder „toy“?
- 1. Raspberry Pi im Embedded Testing - „tool“ oder „toy“? Michel Lawaty - Test Automation Engineer Native Instruments GmbH, Berlin Embedded Testing 2015 - 4. November 2015
- 2. Komplete
- 3. • Warum Mensch-Maschinen-Schnittstelle (HMI) in Test integrieren? • Wie HMI in den Test integrieren? • Kann der Raspberry Pi dabei helfen?
- 5. System Test DUT x f(x) POC=Point of Control POO=Point of Observation Black Box POC POO DUT=Device under Test f(x) == erwartetes Ergebnis ?
- 6. Use Case USB Point of Control Test Host POO’s (Points of Observation) Audio Ausgabe LEDs leuchten Applikation reagiert Abdeckung durch System Test
- 8. Regressionstest • Ist die Qualität gleich geblieben? • Ausführung nach jeder Änderung • Manuelle Strategie: gesteuert nach Risiko • Einfacher durch Automation Regression Tests
- 9. Warum Systemtest automatisieren? • Genauigkeit z.B. AD-Wandler statt Auge • Reproduzierbarkeit&Wiederholbarkeit • Für große Datenmengen • viele Schnittstellen DUT Höhere Test Coverage und Test Depth
- 10. Warum Systemtest automatisieren? • Agile Entwicklungsprozesse • Iterativ & Inkrementell • „Philosophie“ : Agile Manifesto • Regular Deliveries & Working Software
- 11. Agile Entwicklung • Bsp. „Scrum“ • „User Stories“ dokumentieren Requirements • User Story ähnlich zum Use Case
- 12. Agile Testing • Use Case spielt sich am HMI ab • Systemtest notwendig • Systemtest = Test am HMI! Häufigere Ausführung Systemtests
- 13. Kontinuierliche Integration • Continuous Integration (CI) ist ein „Muss" im Agile Development • Ständige SW-Integration & Testausführung • Möglichst automatisch System Test Manuell ?
- 14. Systemtest manuell? • Testausführung manuell verursacht hohe Kosten • Manuelle Ausführung ist fehleranfällig • Manuell gut für Explorative Tests System Test Manuell ?
- 15. Case Study Test Aufwand • ca. 17 bestehende Hardware-Produkte • neue Produkte • ca. 11 Desktop-Betriebssysteme • Treiber, Updates • „Traktor“ hat ca. 300 POC / POO
- 17. Test Automatisierung - Wie? Prüfstand wird benötigt
- 18. Data Acquisition and Control Hardware • Elektrische Aufnahme / Ausgabe von Signalen • Digital I/O, Analog I/O • Steuerung über USB / Ethernet DAQC
- 19. DAQC Hardware (COTS) • Commercial-off-the-shelf (COTS) • verschiedene Anbieter • feste Anzahl Kanäle und Messarten • USB / Ethernet DAQC Quelle: LabJack.com
- 20. DAQC Hardware (modular) • Modular • Praktisch alle Anwendungen • Kanalanzahl erweiterbar • Teilw. eigene SW-Suites Relativ hohe Investition DAQC Quelle: http://germany.ni.com/
- 21. Case Study Benötigte DAQC • ca. 75 Digital Out • ca. 40 variable Widerstände • Inkrementalgeber • Relais • … >10000€ für DAQC Hardware
- 22. Eigene DAQC-Hardware mit dem Raspberry Pi • Einplatinen-Computer • Ethernet • Erweiterbar • I2C-Bus / SPI Quelle: Wikipedia. User „Multicherry“
- 23. Prüfstand mit Raspberry DAQC DUT Signal Adaption
- 24. Device Under Test • Zu prüfendes Gerät • Mensch-Maschinen-Schnittstelle (HMI): Sensoren / Aktoren • Protokoll-Schnittstellen: USB, MIDI • Periphere Schnittstellen DUT
- 25. Signaladaption • Signale zum / vom DUT • Signalkonditionierung • zusätzliche Funktionen • Verbindungstechnik Signal adaption DUT
- 26. Beispiel Button Mechanisch Elektrisch • Button ist Taster • Elektrischer Teil wird emuliert
- 27. Beispiel Button • Adaptierung direkt auf der DUT (PCB) • Adaptierung über Stecker (während Entwicklung)
- 28. Shields • Erweiterungsplatinen (Shields) • viele Anwendungen abgedeckt • Digital I/O, Analog I/O • Servomotoren, Kameras, Sensoren • Anbindung an digitale Schaltungslogik (FPGA) GPIO Expander für die Buttons Quelle: https://www.abelectronics.co.uk
- 29. Beispiel Digital Potis • Abdeckung jeder Anwendung durch ICs • I2C-Bus / SPI verfügbar • Mehrere ICs des gleichen Typ „Maßgeschneidert“ durch eigene Entwicklung
- 30. Steuerung • WebIOPi (http://webiopi.trouch.com/) • „Internet of Things“ Framework • Erlaubt Steuerung Shields & Chips • Apache-Lizenz, Eric Ptak, 2012
- 31. Steuerung • Webserver • Web Interface • REST API: HTTP POST, GET • z.B.: http://webiopi/devices/gpio1/3/value/1 Gute Anbindung an Test Framework
- 33. Fazit • Konnektivität zum Test Framework • Alle „schwierige“ Elektronik ausgelagert • schneller Testbed Prototype
- 34. Fazit • Keine Echtzeit • Latenz im ms Bereich (nicht deterministisch) • Kanalanzahl limitiert • Mechanik optimierbar • mehr HW/SW-Entwicklung notwendig
- 36. Fazit • Einfache Vervielfältigung & Verwendung • Kosten: Testbed bleibt intakt (Wartungsphase) • tool or toy? „tool!“