Raspberry Pi im Embedded Testing - „tool“ oder „toy“?

463 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Ingenieurwesen
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
463
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
8
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Raspberry Pi im Embedded Testing - „tool“ oder „toy“?

  1. 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. 2. Komplete
  3. 3. • Warum Mensch-Maschinen-Schnittstelle (HMI) in Test integrieren? • Wie HMI in den Test integrieren? • Kann der Raspberry Pi dabei helfen?
  4. 4. Testpyramide Component Test Integration Test System Test
  5. 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. 6. Use Case USB Point of Control Test Host POO’s (Points of Observation) Audio Ausgabe LEDs leuchten Applikation reagiert Abdeckung durch System Test
  7. 7. Testpyramide BLACKBOX WHITEBOX Component Test Integration Test System Test
  8. 8. Regressionstest • Ist die Qualität gleich geblieben? • Ausführung nach jeder Änderung • Manuelle Strategie: gesteuert nach Risiko • Einfacher durch Automation Regression Tests
  9. 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. 10. Warum Systemtest automatisieren? • Agile Entwicklungsprozesse • Iterativ & Inkrementell • „Philosophie“ : Agile Manifesto • Regular Deliveries & Working Software
  11. 11. Agile Entwicklung • Bsp. „Scrum“ • „User Stories“ dokumentieren Requirements • User Story ähnlich zum Use Case
  12. 12. Agile Testing • Use Case spielt sich am HMI ab • Systemtest notwendig • Systemtest = Test am HMI! Häufigere Ausführung Systemtests
  13. 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. 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. 15. Case Study Test Aufwand • ca. 17 bestehende Hardware-Produkte • neue Produkte • ca. 11 Desktop-Betriebssysteme • Treiber, Updates • „Traktor“ hat ca. 
 300 POC / POO
  16. 16. Testfallexplosion
  17. 17. Test Automatisierung - Wie? Prüfstand wird benötigt
  18. 18. Data Acquisition and Control Hardware • Elektrische Aufnahme / Ausgabe von Signalen • Digital I/O, Analog I/O • Steuerung über USB / Ethernet DAQC
  19. 19. DAQC Hardware (COTS) • Commercial-off-the-shelf (COTS) • verschiedene Anbieter • feste Anzahl Kanäle und Messarten • USB / Ethernet DAQC Quelle: LabJack.com
  20. 20. DAQC Hardware (modular) • Modular • Praktisch alle Anwendungen • Kanalanzahl erweiterbar • Teilw. eigene SW-Suites Relativ hohe Investition DAQC Quelle: http://germany.ni.com/
  21. 21. Case Study Benötigte DAQC • ca. 75 Digital Out • ca. 40 variable Widerstände • Inkrementalgeber • Relais • … >10000€ für DAQC Hardware
  22. 22. Eigene DAQC-Hardware mit dem Raspberry Pi • Einplatinen-Computer • Ethernet • Erweiterbar • I2C-Bus / SPI Quelle: Wikipedia. User „Multicherry“
  23. 23. Prüfstand mit Raspberry DAQC DUT Signal Adaption
  24. 24. Device Under Test • Zu prüfendes Gerät • Mensch-Maschinen-Schnittstelle (HMI): Sensoren / Aktoren • Protokoll-Schnittstellen: USB, MIDI • Periphere Schnittstellen DUT
  25. 25. Signaladaption • Signale zum / vom DUT • Signalkonditionierung • zusätzliche Funktionen • Verbindungstechnik Signal adaption DUT
  26. 26. Beispiel Button Mechanisch Elektrisch • Button ist Taster • Elektrischer Teil wird emuliert
  27. 27. Beispiel Button • Adaptierung direkt auf der DUT (PCB) • Adaptierung über Stecker (während Entwicklung)
  28. 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. 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. 30. Steuerung • WebIOPi (http://webiopi.trouch.com/) • „Internet of Things“ Framework • Erlaubt Steuerung Shields & Chips • Apache-Lizenz, Eric Ptak, 2012
  31. 31. Steuerung • Webserver • Web Interface • REST API: HTTP POST, GET • z.B.: http://webiopi/devices/gpio1/3/value/1 Gute Anbindung an Test Framework
  32. 32. Architektur DUT Shields other Chips webIOPi Raspberry Test Framework Test Host Signaladaption Ethernet
  33. 33. Fazit • Konnektivität zum Test Framework • Alle „schwierige“ Elektronik ausgelagert • schneller Testbed Prototype
  34. 34. Fazit • Keine Echtzeit • Latenz im ms Bereich (nicht deterministisch) • Kanalanzahl limitiert • Mechanik optimierbar • mehr HW/SW-Entwicklung notwendig
  35. 35. DUT Signaladaption webIOPi Raspberry Chips Fazit • DAQC „maßgeschneidert“ Volle Kontrolle
  36. 36. Fazit • Einfache Vervielfältigung & Verwendung • Kosten: Testbed bleibt intakt (Wartungsphase) • tool or toy? „tool!“
  37. 37. Fragen ? Kontakt michel.lawaty@native-instruments.de embeddedtesting2015.signaladaption.de de.linkedin.com/in/michellawaty xing.com/profile/Michel_Lawaty

×