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

Post on 22-Jan-2018

668 views 1 download

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

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

Michel Lawaty - Test Automation Engineer Native Instruments GmbH, Berlin

Embedded Testing 2015 - 4. November 2015

Komplete

• Warum Mensch-Maschinen-Schnittstelle (HMI) in Test integrieren?

• Wie HMI in den Test integrieren?

• Kann der Raspberry Pi dabei helfen?

Testpyramide

Component Test

Integration Test

System Test

System Test

DUTx f(x)

POC=Point of ControlPOO=Point of Observation

Black Box

POC POO

DUT=Device under Test

f(x) == erwartetes Ergebnis ?

Use Case

USB

Point of Control

Test Host

POO’s (Points of Observation)

Audio Ausgabe

LEDs leuchtenApplikation reagiert

Abdeckung durch System Test

TestpyramideBL

ACKB

OX

WH

ITEB

OX

Component Test

Integration Test

System Test

Regressionstest• Ist die Qualität gleich geblieben?

• Ausführung nach jeder Änderung

• Manuelle Strategie: gesteuert nach Risiko

• Einfacher durch Automation

Regression Tests

Warum Systemtest automatisieren?

• Genauigkeit z.B. AD-Wandler statt Auge

• Reproduzierbarkeit&Wiederholbarkeit

• Für große Datenmengen

• viele SchnittstellenDUT

Höhere Test Coverage und Test Depth

Warum Systemtest automatisieren?

• Agile Entwicklungsprozesse

• Iterativ & Inkrementell

• „Philosophie“ : Agile Manifesto

• Regular Deliveries & Working Software

Agile Entwicklung

• Bsp. „Scrum“

• „User Stories“ dokumentieren Requirements

• User Story ähnlich zum Use Case

Agile Testing

• Use Case spielt sich am HMI ab

• Systemtest notwendig

• Systemtest = Test am HMI!

Häufigere Ausführung Systemtests

Kontinuierliche Integration• Continuous Integration (CI) ist ein „Muss" im

Agile Development

• Ständige SW-Integration & Testausführung

• Möglichst automatisch

System Test Manuell ?

Systemtest manuell?• Testausführung manuell verursacht hohe Kosten

• Manuelle Ausführung ist fehleranfällig

• Manuell gut für Explorative Tests

System Test Manuell ?

Case Study

Test Aufwand• ca. 17 bestehende Hardware-Produkte

• neue Produkte

• ca. 11 Desktop-Betriebssysteme

• Treiber, Updates

• „Traktor“ hat ca. 300 POC / POO

Testfallexplosion

Test Automatisierung - Wie?

Prüfstand wird benötigt

Data Acquisition and Control Hardware

• Elektrische Aufnahme / Ausgabe von Signalen

• Digital I/O, Analog I/O

• Steuerung über USB / Ethernet

DAQC

DAQC Hardware (COTS)

• Commercial-off-the-shelf (COTS)

• verschiedene Anbieter

• feste Anzahl Kanäle und Messarten

• USB / Ethernet

DAQC

Quelle: LabJack.com

DAQC Hardware (modular)

• Modular

• Praktisch alle Anwendungen

• Kanalanzahl erweiterbar

• Teilw. eigene SW-Suites

Relativ hohe Investition

DAQC

Quelle: http://germany.ni.com/

Case Study

Benötigte DAQC

• ca. 75 Digital Out

• ca. 40 variable Widerstände

• Inkrementalgeber

• Relais

• …

>10000€ für DAQC Hardware

Eigene DAQC-Hardware mit dem Raspberry Pi

• Einplatinen-Computer

• Ethernet

• Erweiterbar

• I2C-Bus / SPIQuelle: Wikipedia. User „Multicherry“

Prüfstand mit Raspberry

DAQC DUTSignal Adaption

Device Under Test• Zu prüfendes Gerät

• Mensch-Maschinen-Schnittstelle (HMI): Sensoren / Aktoren

• Protokoll-Schnittstellen: USB, MIDI

• Periphere Schnittstellen

DUT

Signaladaption

• Signale zum / vom DUT

• Signalkonditionierung

• zusätzliche Funktionen

• Verbindungstechnik

Signal adaption DUT

Beispiel Button

Mechanisch

Elektrisch

• Button ist Taster

• Elektrischer Teil wird emuliert

Beispiel Button• Adaptierung direkt auf der DUT (PCB)

• Adaptierung über Stecker (während Entwicklung)

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

Beispiel Digital Potis

• Abdeckung jeder Anwendung durch ICs

• I2C-Bus / SPI verfügbar

• Mehrere ICs des gleichen Typ

„Maßgeschneidert“ durch eigene Entwicklung

Steuerung

• WebIOPi (http://webiopi.trouch.com/)

• „Internet of Things“ Framework

• Erlaubt Steuerung Shields & Chips

• Apache-Lizenz, Eric Ptak, 2012

Steuerung

• Webserver

• Web Interface

• REST API: HTTP POST, GET

• z.B.: http://webiopi/devices/gpio1/3/value/1

Gute Anbindung an Test Framework

Architektur

DUT

Shields

other Chips

webIOPi

Raspberry

Test Framework

Test Host Signaladaption

Ethernet

Fazit

• Konnektivität zum Test Framework

• Alle „schwierige“ Elektronik ausgelagert

• schneller Testbed Prototype

Fazit

• Keine Echtzeit

• Latenz im ms Bereich (nicht deterministisch)

• Kanalanzahl limitiert

• Mechanik optimierbar

• mehr HW/SW-Entwicklung notwendig

DUT

Signaladaption

webIOPi

Raspberry

Chips

Fazit• DAQC „maßgeschneidert“

Volle Kontrolle

Fazit

• Einfache Vervielfältigung & Verwendung

• Kosten: Testbed bleibt intakt (Wartungsphase)

• tool or toy?

„tool!“

Fragen ?

Kontakt

michel.lawaty@native-instruments.de

embeddedtesting2015.signaladaption.de

de.linkedin.com/in/michellawaty

xing.com/profile/Michel_Lawaty