HoPHiL GEN3 (Holistic Open Platform HiL Test Bench)

Deterministische, abteilungsübergreifende Systemlösung für Hardware-in-the-Loop-Test

Dieses Dokument ergänzt das technischen Datenblatt mit dem Fokus auf betriebswirtschaftliche, entscheidungsrelevante Vorteile (weniger technisch) inkl. Projekterfahrung sowie Einstiegspfade für einen Proof of Concept.

Einleitung und Ausgangslage

Die Anforderungen an moderne Validierungs- und Testinfrastrukturen sind im wirtschaftlichen Wandel: Mehr Funktionsumfang und Varianten, höhere Buslast (CAN FD/Ethernet) sowie zusätzliche Security-Mechanismen (z. B. SecOC/E2E) treffen auf den Anspruch nach stabiler, wiederholbarer Regression, CI-Automatisierung und verkürzten Release-Zyklen (u. a. OTA) - bei gleichzeitigem Kostendruck. In der Praxis bleibt Validierung dadurch nicht nur ein reines Feature-Thema, sondern auch eine Frage von Effektivität, Einsatzbreite, Reproduzierbarkeit und Durchsatz im Dauerbetrieb. Auch aus betriebswirtschaftlicher Sicht, haben Punkte langfristig gesehen, wesentlichen Einfluss auf den Erfolg und die Handlungsfähigkeit des Teams.

HoPHiL GEN3 adressiert diese Themen, und definiert sich als modular skalierbare Plattform für Entwicklung, Labor, HiL-Testplätze, Systemtests (bis hin zum Fahrzeug) und Prototypen-/Akquiseprojekte. Entscheidend ist dabei nicht nur der Funktionsumfang, sondern die Fähigkeit, Komplexität abteilungsübergreifend zu reduzieren: über offene APIs, ein rollen- und erfahrungsabhängiges UI, hohe Anpassbarkeit (Integration in bestehende Umgebungen und firmenspezifische Prozesse, optional Fremdgeräte-Ansteuerung) sowie Feature- und Durchsatz-Skalierung. Damit werden stabile, tägliche Regressions und reproduzierbare Analysen - inklusive der besseren Auffindbarkeit sporadischer Fehler - organisatorisch und technisch erleichtert.

Diese Entscheidungsvorlage fasst die relevanten Vorteile, Einsatzpfade und wirtschaftlichen Effekte zusammen.

Entscheidungsrelevante Punkte im Überblick ergänzt um betriebswirtschaftliche Kriterien
Stabilere Regression, höherer Durchsatz, verkürzte Release-Zyklen. Determinismus & Reproduzierbarkeit unter Last, über lange Laufzeiten müssen gewährleistet werden. Instabile Regression führt zu Verzögerungen (z. B. Timeouts), erschwert Analysen.
Abteilungsübergreifende Systemlösung wird ermöglicht durch kompakte Baugröße, skalierbaren Funktionsumfang, attraktive Kosten, hohe Anpassbarkeit und breiten Feature-Umfang. Eine homogene Lösung gewährt eine effiziente Wissensweitergabe.
Benutzerfreundliches, rollen-/erfahrungsabhängiges UI: Komplexität wird je nach Bedienerlevel reduziert (Einsteiger bis Experte) - weniger Einarbeitung, weniger Fehler.
Reduziert Validierungs-Komplexität durch eine deterministische Plattform (statt Tool-Fragmentierung). Eine Tool-Fragmentierung erhöht Reibungsverluste und senkt die Effizienz im Betrieb.
Hohe Anpassungsfähigkeit: Integration in bestehende Umgebungen und firmenspezifische Prozesse; optional Ansteuerung von Fremdgeräten. Eine hochflexibile Einbindung erlaubt höchste Effektivitäts-Level.
Kundenspezifische, spezialisierte Testlösungen (nicht "von der Stange") lassen sich gezielt umsetzen. Dies erfordert oft Eingriffe auf tiefster technischer Ebene (HW + SW).
Skalierung auf Feature und Durchsatz-Ebene + Redundanz bei Kosten deutlich unter Legacy-Systemen. Es darf keinen Single Point of Failure geben, der Entwicklung und Regression blockiert!
Parallelisierung und "Daily 24/7 Regression" ist möglich, Total Cost of Ownership (TCO) darf das nicht blockieren. Setup-Ausfälle oder eine laufende Regression dürfen keine Handlungsunfähigkeit des Teams erwirken.
International einsetzbar - keine Gebietseinschränkung, keine einschränkenden Remote oder Virtualisierungsrichtlinien. Die Effektivität darf nicht unter unnötiger Lizenz-/Gebietsrestriktionen leiden. Setup-Sharing und Virtualisierung muss erlaubt sein.
Die Testinfrastruktur muss auch nach Start-of-Production langfristig verfügbar und betreibbar bleiben (10+ Jahre). Auch hier beeinflussen Baugröße der Systeme (=Lagerkosten), Wartungskosten und Zeit für evtl. Abbau/Re-Inbetriebnahme langfristig die Strategie.

Wichtigste Entscheider-KPIs

~4 - 32x
schnellerer Durchsatz
0%
jährliche Lizenzkosten (OPEX Anteil), Wartungsverträge auf Wunsch möglich.
1/8 der CAPEX
Investitionsausgaben im Vergleich zu Legacy-Systemen
6+ Abteilungen
eine Systemlösung
AGB-safe Deployment
frei über Standort, Remote und VM nutzbar.
kein Hersteller-Lock-in
und offene, Python-basierte API

1. HoPHiL als Systemlösung

HoPHiL GEN3 ist als deterministische Validierungsplattform ausgelegt: Fault Injection, Disturbance-Emulation, Restbus-Simulation, SecOC/E2E-Manipulation, Messung, GUI und Automatisierung greifen ineinander.

Einsatzbereiche über den gesamten Entwicklungszyklus

Im Vordergrund oder unauffällig im Hintergrund

HoPHiL ist so konzipiert, dass es unterschiedliche Ansteuerkonzepte unterstützt - je nach Use Case und Toolchain:

Abteilungsübergreifende Standardisierung: ein System, mehrere Ausprägungen

Abteilungen (HW-Labor, SW-Entwicklung, HiL/Validation, Fahrzeug-/Systemtest, EoL) haben unterschiedliche Anforderungen - trotzdem profitieren sie stark von einer gemeinsamen Plattform. HoPHiL kann als einheitlicher Systemstandard dienen, während User-Interface und Hardwareausprägung rollen- und aufgabenspezifisch als Subset bereitgestellt werden. So lassen sich Setup- und Prozesswissen effizient zwischen Abteilungen übertragen, ohne dass jede Einheit ein "Vollsystem" mit Preis-, Größen- oder Komplexitäts-Overhead betreiben muss.

Warum das in der Praxis oft ein No-Go ist und was HoPHiL anders macht:
Viele Systeme scheitern abteilungsübergreifend an Preis, Baugröße oder Komplexität (zu teuer, zu groß, zu kompliziert zu betreiben).
HoPHiL wurde genau auf diese Kriterien optimiert: gutes Preis/Leistungs-Verhältnis, kompakte Baugröße, und eine Komplexität, die durch UI-Workflows und modulare Subsets beherrschbar bleibt.
Ergebnis: ein Systemstandard, der skalierbar eingeführt werden kann (Start mit Subset, später erweitern), ohne Reibungsverluste zwischen Abteilungen.

2. Technische Differenzierung: Stabilität & Determinismus

Für Validierungsentscheidungen zählt nicht nur Funktionsumfang, sondern vor allem Stabilität im Dauerbetrieb. HoPHiL reduziert typische Instabilitätsquellen klassischer Setups (z.B. OS-Jitter, Tool-Synchronisation, RBS-Timeouts, SecOC-Flakiness) durch Einsatz von ineinandergreifenden Echtzeitsystemen.

Ineinandergreifende Echtzeitsysteme

Die Funktion ist nicht auf ein einziges Echtzeitsystem begrenzt sondern der Einsatz von getrennten aber ineinandergreifenden Echtzeitsystemen bringt gezielte Wirkung in folgenden Bereichen:

Typische Engpässe - und was HoPHiL anders macht

Thema Klassische / fragmentierte Setups (typisch) HoPHiL GEN3
RBS unter Last Timeouts/Flakiness möglich Deterministische Ausführung, stabil in Regression
SecOC in Regression Instabilitäten / schwer reproduzierbar / erschwerte Fehleranalyse Deterministisches Echtzeit-Handling mit erhöhter Analysemöglichkeit
HW-Stimuli/Messung synchron zu Bus Synchronisation über Tools/PC (falls überhaupt möglich) Synchronisiert auf Plattform-Zeitbasis und Teil des Offline Recordings
Debug-/Analysefähigkeit Fehlerursprungsanalyse oft erschwert Entwickelt für Fault Injection und verbesserte Analysemöglichkeit (z. B. Strom/µC-Resets)
Usability/Adoption Komplexe Tool-Kette, Hersteller-Lock-in, "Verpackung" und Ersteindruck täuschen oft. Komplexe Abläufe im UI auf Anwendung vereinfachbar; Konfiguration ist generierbar und teilbar; Entscheidungsbasierte Konfiguration; schnellerer Rollout
Skalierung Single Point of Failure bei teuren Systemen und Durchsatz-Skalierung eingeschränkt. Mehrere Realtime Nodes leistbar (Parallelisierung & Redundanz)
!!!!
Konkrete Mehrwerte für den Validierungsalltag
Schnellere und stabilere Regression und weniger Analysedauer bei Fehlern
Gezielte Erkennung von sporadischen Fehlern und schnellere Device-under-Test Stabilität
Erhöhte Analysefähigkeit durch z. B. High-Resolution Current Measurement: Erkennung Systemzustände des Steuergeräts und unerwartete µC-Resets
Customer-specific Features & Advanced Configuration (Setups + UI)

3. CI/CD (Continuous Integration/Deployment): skalierbar ohne Compliance-Risiko

Für eine skalierbare Regression sind virtuelle Maschinen und Netzwerkbetrieb des Testsetups oft entscheidend um Testsysteme schnell zu klonen oder ein Backup zu erstellen. Der Netzwerkbetrieb und die entscheidungsbasierte Konfiguration ermöglichen ein einfaches Tauschen des Testsetups zwischen Hosts oder eine Parallelisierung. Während bei Vergleichssystemen Lizenz- bzw. AGB-Einschränkungen die VM-Nutzung oder den internationalen Remotezugriff untersagen und somit den Test-Alltag erschweren - wurde HoPHiL gezielt dahingehend entwickelt und verzichtet gänzlich auf derartige Restriktionen. Gleichzeitig ist die Einbindung in bestehende Toolchains und firmenspezifische Prozesse ein zentraler Vorteil.

Praktische Punkte, die in der Umsetzung zählen:

Diese Punkte sind mitentscheidend um Continuous Test / Integration / Deployment effektiv und nachhaltig einzuführen. Der Mehrwert von CI/CD kann entscheidend sein!

Was bietet HoPHiL um CI/CD zu erreichen:
Stabilität in Ausführung über VM und Netzwerk
VM-Nutzung ohne Compliance-Risiko und somit keine Einschränkungen bei Sharing/Klonen/Backups
VM-Performance: typischerweise 4-6 virtuelle CPUs bereits ausreichend und praxisbewährt
Einfacher Wechsel zwischen Hardware-Setups und Setup-Sharing möglich
Testbenches für SW-Entwicklung und Tester (Entkopplung von zentraler Regression)
Einbindung in bestehende Toolchains und firmenspezifische Prozesse (z. B. Jenkins)
Entscheidungsbasierte Konfguration bei Verwendung von unterschiedlich skalierten Systemen.
Durchsatzskalierung aufgrund niedriger Anschaffungskosten/Wartungkosten.
Proven in use - Load Balancing mit Jenkins
Konkrete Mehrwerte für den Validierungsalltag (Annahme: tägliches Continuous Integration)
Höhere Planungssicherheit und deutlich kürzere Release-Zyklen werden möglich.
Ausführung erfolgt automatisiert ohne Test-Engineer zu einem definierten Zeitpunkt, wodurch der Test-Engineer deutlich entlastet wird.
Entwicklung erhält Feedback am nächsten Tag (bestenfalls über Nacht), was eine selbständige Analyse der Entwicklung und eine bessere Zusammenarbeit ermöglicht.
Keine Testausführung mit modifizierten Testscripts und volles Regressionsergebnis mit clean Repository/Sandbox bewirken ein vertrauenswürdiges Ergebnis.
Ergebnisse können täglich eingesehen werden, die TestScript-Stabilität wird erhöht und wird als Trend sichtbar.
Weniger „false negatives“: echte sporadische Timing-/Race-Conditions werden sichtbar und reproduzierbar.
Reproduzierbarkeit beschleunigt Root-Cause-Analyse und reduziert Debug-Schleifen.
Sporadische Fehler können schneller identifiziert und somit die Teststabilität nachhaltig erhöht werden.
Risiko bei Tooling Update ist deutlich reduziert und eine Abschätzung zu Anpassungsaufwand kann am nächsten Tag getroffen werden.
Unerwünschte Seiteneffekte bei Änderungen werden sofort sichtbar.

... und um nur ein paar Vorteile von CI/CD zu nennen - es gibt viele mehr.

4. TCO & Skalierung: Feature- & Durchsatz-Skalierung

HoPHiL skaliert zweifach:

  1. Feature-Skalierung über ein modulares Baukastensystem (Erweiterungsmodule) - die Module definieren den Funktionsumfang des Testsystems. Das erleichtert den Einstieg (nur das benötigte Subset) und erlaubt späteres Erweitern ohne Plattformwechsel.
  2. Durchsatz-Skalierung über mehrere Nodes mit Load Balancing - z. B. 8x HoPHiL ≈ 24k€ CAPEX vs 1x Legacy ≈ 26k€ ermölicht Parallelisierung, kein Single Point of Failure und Time-to-Result von Wochen auf über Nacht.

Skalierung
Kostenblock (Beispiel) Legacy/vergleichbar HoPHiL (1 Node, extended Featureset)
Initial (CAPEX) ≈ 26.000 € ≈ 3.000 €
Jährliche Gebühren ≈ 20% p.a. 0 € (keine jährliche Lizenzgebühr)
3-Jahres-Systemkosten (direkt) ≈ 41.600 € ≈ 3.000 €
Skalierung 1 System 1 System (höheres Hardware-Featureset)
Beispiel bei gleicher Anzahl von je 3x Systemen
=> (41.600 - 3.000) * 3 Systeme = 115.800 € Ersparnis (CAPEX + OPEX über 3 Jahre)

Hinweis: Zahlen/Beispiele sind Erfahrungswerte und müssen je Kundencase validiert werden.

Warum Redundanz kein Nachteil ist:
Redundanz lässt sich in tägliche Regression integrieren (Failover statt Stillstand).
Parallelisierung erhöht Testdurchsatz deutlich, auch ohne Continuous Integration Tool-Kopplung.
Entkopplung: Development/Tester-Benches blockieren die zentrale Regression nicht.
Weniger instabile Runs → weniger Debug-OPEX (Engineering-Zeit).

Durchsatzskalierung & Time-to-Result

Neben Stabilität ist Durchsatz ein direkter Kostenhebel. Aus Projekterfahrung wird eine bis zu ~4x schnellere Test-Case-Ausführung berichtet. Das reduziert Regression-Dauer und erhöht die Anzahl valider Runs pro Tag.

Für den Vergleich ist wichtig: Im klassischen Umfeld wird 1 System verwendet (CAPEX ≈ 26.000 €). Im HoPHiL Umfeld werden 8 Systeme parallel mit Load Balancing betrieben (CAPEX ≈ 8 x 3.000 € = 24.000 €).

Vergleichspunkt Klassisch (1 System) HoPHiL (8 Systeme, Load Balancing)
Systeme parallel 1 8
Anschaffungspreis (CAPEX) ≈ 26.000 € ≈ 24.000 € (8 x 3.000 €)
Regression-Durchsatz limitiert durch 1 System Parallelisierung über 8 Systeme (Load Balancing)
mit ~4x schnellerer Ausführungszeit
Nightly Regression (2100 Tests) ~140 h (1 System) ~6,5 h (Load Balancing)
Time-to-Result / Feedback spät / oft manuelle Nachläufe am nächsten Morgen automatisiert (CI/Reports)
Welche Vorteile entstehen indirekt:
Mehr Runs pro Tag → höhere Testabdeckung ohne zusätzliche Schichten
Schnelleres Debugging → weniger Laborbindung
Weniger instabile Tests → weniger Analysezeit
Höhere Planungssicherheit und kürzere Release-Zyklen

5. Empfohlene Einstiegspfade & Proof of Concept

„Was brauche ich, um zu starten?“ - Die folgenden Pakete sind als Orientierungsrahmen gedacht und werden projektspezifisch angepasst.

Paket Ziel Typische Inhalte
HoPHiL Demo ohne ECU Schnell startfähig mit Showcase Template, Bekanntschaft schließen Basis-Setup + Disturbance/FIU-Profile, UI, Recording, Python-API
Starter (Standalone ECU) Schnell startfähig, erste Use-Cases Basis-Setup, UI, Recording, Python-API
Security & Robustness SecOC/E2E-Regression + Fault Injection RBS + SecOC/E2E + Disturbance/FIU-Profile (konfigurationsabhängig)
CI Dual-Node Max. Durchsatz + Redundanz 2+ HoPHiL Nodes (Regression + Dev/Test), VM-Integration (optional), Setup-Sharing, Jenkins (für Vollautomatisierung)
Custom Solutions Spezielle Tests nicht „von der Stange“ Kundenspezifische Testlogik, UI-Workflows, Integration von Fremdgeräten/Prozessen

Mögliche entscheidungsrelevante Fragen: