vPIL by efs.
Test speed beyond limit.
Testsoftware und System unter Test gehören entkoppelt.
Wir heben die Ausführung auf eine abstrahierte Ebene.
vPIL by efs ist eine Build- und Ausführungsumgebung für Software Under Test. Statt eine physische PIL-Karte pro Test-PC zu betreiben, läuft die Zielsoftware virtualisiert in QEMU, auf realer Hardware oder unter Windows und Linux. Die Ausführungseinheit wird dadurch beliebig austauschbar. In einem realen Projekt sank die Laufzeit der ACF-Tests von acht Tagen auf unter 30 Minuten. Das entspricht Faktor 400. Verfügbar als eigenständiges Tooling oder als Plugin für PikeTec TPT.
Freigabetests in Minuten
statt in Tagen.
PIL-Karten sind teuer, fehleranfällig und pro Test-PC nur einmal vorhanden. Sie blockieren die CI/CD-Pipeline und machen Entwicklertests praktisch unmöglich. vPIL löst diese Kopplung auf. Tests laufen parallel im CI-Pool, auf dem Buildserver oder lokal am Entwicklerrechner. Mit demselben Compiler und demselben Target wie im Serienbuild.
Entdecken Sie vPIL by efs im Detail.
Kompakt, übersichtlich und auf den Punkt gebracht.
Von der virtualisierten Ausführung bis zur Closed-Loop-Simulation.
Virtualisiertes PIL über QEMU
Wir ersetzen die physische Testkarte durch Emulation.
- Emulierte Zielhardware: Die Serien-Software läuft in QEMU statt auf einem PIL-Board. Kein Hardwareengpass, keine Wartezeit auf freie Prüfplätze.
- Parallelisierung im CI-Pool: Nightly-Tests skalieren horizontal über alle verfügbaren Buildknoten.
- Unterstützte Targets: TriCore, STM32, ARM sowie x86 und x64 unter Windows und Linux.
Plug-and-Play-Connectoren
Wir binden bestehende Testframeworks direkt an.
- Direkte Anbindung: TPT, Google Test, C# und OSLC ohne Anpassungsaufwand.
- Bestandsschutz: Vorhandene Testsuiten laufen auf vPIL, ohne dass sie umgeschrieben werden müssen.
- Plugin oder standalone: Nutzbar als eigenständiges Tooling oder integriert in PikeTec TPT.
Zero-Overhead-Integration von Build-Artefakten
Wir führen aus, was der Serienbuild erzeugt.
- Kein Rebuild: Kompilate im .o-Format werden ohne erneuten Build in eine ausführbare SUT überführt.
- Automatische Schnittstellenadaption: Wrapper und De- beziehungsweise Serialisierer für Binärschnittstellen entstehen generiert, nicht von Hand.
- Seriennähe: Getestet wird exakt das Artefakt, das später ausgeliefert wird.
Austauschbare Execution Targets
Wir wechseln die Ausführungseinheit ohne Änderung am Test.
- Nahtloser Wechsel: Mikrocontroller, Emulator oder SIL, ohne Anpassung an Tests oder SUT.
- Identische Ergebnisse: Derselbe Test, ein anderes Target, dasselbe Resultat.
- Lokale und verteilte Ausführung: Auf dem Entwicklerrechner oder remote auf dem Buildserver.
Timing und Closed Loop
Wir messen unter realen Bedingungen.
- Timingmessung: Ausführung von SUTs mit Realdaten zur Bewertung des Zeitverhaltens.
- Closed-Loop-Simulation: Einbettung der SUT in eigene Simulationsumgebungen, ohne Hardwareprüfstand.
- Entwicklertests mit Seriensetup: Compiler, Target und Toolchain wie im Serienbuild, schon am Arbeitsplatz.
Unser Vorgehen:
Klarheit in vier Schritten.
01 Analyse (1 bis 2 Tage): Wir sichten Toolchain, Testframeworks und Buildumgebung. Wo liegt der Engpass und welche Targets sind im Einsatz?
02 Integration: Anbindung der bestehenden Testsuiten, Aufsetzen der Ausführungsumgebung und Konfiguration der Zielplattformen.
03 Verifikation: Gegenlauf gegen die bisherige PIL-Ausführung. Wir belegen, dass Ergebnisse identisch bleiben.
04 Rollout: Skalierung in der CI/CD-Pipeline und Enablement des Teams. Inklusive Dokumentation und Übergabe.
Acht Tage Testlaufzeit sind keine technische Notwendigkeit.
