Den Produktentwicklungszyklus mit schnelleren Tests beschleunigen V-Diagramm bedienen

Elektromechanische Systeme wandeln Energie in mechanische Arbeit um und umgekehrt. Die Systeme verfügen über Steuerelektronik (z. B. ein elektronisches Steuergerät) bzw. Embedded-Controller (wie eine Line-Replaceable-Unit, LRU). Darauf wird maßgeschneiderte Software zur Steuerung der mechanischen und physischen Komponenten sowie Aktoren mithilfe der Werte von Sensoren und anderen Systemen ausgeführt. Elektromechanische Systeme sorgen für den Fahrzeugantrieb und erfüllen eine Reihe weiterer Funktionen an Bord von Flugzeugen, Landfahrzeugen und Schiffen.   

Abbildung 1. Beispielhafte Fahrzeugkategorien und gängige darin enthaltene Varianten elektromechanischer Systeme

Auch wenn die Eigenschaften, Funktionsweisen und Auslegungsanforderungen dieser Systeme mitunter stark variieren, folgen Entwicklung und Test von elektromechanischen Fahrzeugsystemen dem gleichen grundlegenden Ablauf. Systemingenieure konstruieren das Fahrzeug und definieren die Anforderungen, denen die Systeme, Subsysteme und Komponenten des Fahrzeugs gerecht werden müssen. Verschiedene Teams kümmern sich um die Erfüllung dieser Anforderungen, indem sie die Steuerelektronik, die Software und die mechanischen Komponenten entsprechend den vorliegenden Spezifikationen entwickeln. Die Teams folgen ihren eigenen Entwicklungsabläufen (in der Regel einer agilen Methode, die an die jeweiligen Vorgaben angepasst ist) beim Durchlaufen der Entwurfs- und Validierungsschritte für ihren Teil des elektromechanischen Fahrzeugsystems. Anschließend wird das System iterativ aufgebaut, integriert und phasenweise getestet – so entsteht das fertige Fahrzeug.

Abbildung 2. Verallgemeinerter Produktentwicklungsprozess für elektromechanische Systeme

Der Entwicklungsprozess, also die unterschiedlichen Phasen von den Anforderungen über den Entwurf bis hin zur Validierung, lässt sich auf verschiedene Weise beschreiben, so z. B. durch das V-Modell (Abbildung 3). Wenngleich das V-Modell durch zahlreiche Varianten und Interpretationen etwas verwirrend erscheinen mag, handelt es sich um einen nützlichen Referenzrahmen für die Evaluierung einer universellen Testarchitektur, mit der die verschiedenen Testanforderungen im Entwurfsprozess erfüllt werden können.

Abbildung 3. Die V-Modell-Methode zur Abbildung des Entwicklungsprozesses und der zugehörigen Testarten

In der Regel werden auf der linken Seite des V zunächst die allgemeinen Anforderungen und ausgehend davon die detaillierten Spezifikationen formuliert, die sich aus den verschiedenen Entscheidungen im Entwurfsprozess ergeben. Diese Entscheidungen werden auf Grundlage einer zunehmend modellbasierten Entwurfsstrategie getroffen, die verschiedene computergestützte Engineering-Tools (CAE) umfasst – je nach Art des zu entwickelnden Systems. Weitere Informationen können Sie der Fachliteratur zu den Themen digitale Transformation und digitale Zwillinge entnehmen. An der Unterseite des V sind die Systeme in die grundlegenden Teilkomponenten zerlegt; der Entwurf ist bereit zur Implementierung, die Prototypen der Komponenten können erstellt werden. Außerdem wird Programmcode auf die Prototypen implementiert. Diese führen Software aus, weshalb die Unterseite des V gelegentlich mit „Implementierung“ beschriftet ist. Der rechte Arm des V zeigt die Integration der verschiedenen Komponenten miteinander, überprüft den Betrieb auf Einhaltung der Spezifikationen und validiert die Leistung hinsichtlich der Anforderungen in jedem Integrationsschritt von den Basiskomponenten bis hin zum Fahrzeug.

Hinweis: Wenn die Einzelheiten zu Systemen, Subsystemen und Komponenten bereitgestellt werden, erfolgt parallel die Entwicklung von Software sowie von elektrischen und mechanischen Komponenten, vergleiche Abbildung 2. Der Entwicklungsprozess liegt im Allgemeinen in den Händen von Design- und Testteams mit dem erforderlichen Know-how.

Hinweis: Die Begriffe „Verifikation“ und „Validierung“ werden eher unterschiedslos verwendet, manchmal wird der Oberbegriff „V&V“ herangezogen. Während der Verifizierung fragen Sie sich vermutlich, ob Sie das System richtig konstruieren. Außerdem möchten Sie sicherstellen, dass Ihr System wie erwartet (innerhalb einer gewissen Toleranz) funktioniert, indem Sie einen Abgleich mit den Spezifikationen vornehmen. Während der Validierung stellen Sie sich hingegen die Frage, ob Sie das richtige System konstruieren. Es ist wichtig, dass Ihr fertiges System die Aufgaben ausführen kann, für die es ausgelegt wurde, und zwar bei akzeptabler Leistung, die anhand festgelegter Anforderungen gemessen wird.

Die kurzen Beschreibungen und Definitionen der folgenden Tests sind ungefähr in der Reihenfolge, wie sie Ihnen im Produktentwicklungsprozess begegnen, wobei dieser in der Praxis stark iterativ ist. Die Fähigkeit zum schnellen und effizienten Durchlaufen des V-Modells ist nicht nur ein Wettbewerbsvorteil, sondern sogar die Schlüsselkompetenz einer leistungsfähigen Testorganisation. Einer der Kritikpunkte am V-Modell ist allerdings, dass es ähnlich dem Wasserfallmodell den Entwicklungsprozess lediglich in Phasen abbildet.

Model-in-the-Loop-Test (MIL)

Beim MIL-Test werden sowohl der Regler als auch die Regelstrecke softwareseitig modelliert. Diese Art Test wird früh im Entwurfsprozess durchgeführt, um Reglerstrategien und Systemverhalten in einer Softwaresimulationsumgebung zu prüfen.

Software-in-the-Loop-Test (SIL)

Beim SIL-Test modellieren Sie die Regelstrecke, verbinden Sie jedoch mit dem tatsächlichen Steuercode, der in der gewählten Entwicklungsumgebung erstellt und ausgeführt sowie auf dem Entwicklungssystem kompiliert und ausgeführt wird, gelegentlich auch auf einer virtuellen Maschine.

Processor-in-the-Loop-Test (PIL)

Der PIL-Test ähnelt dem SIL-Test, doch der Steuercode wird für die jeweiligen Prozessorarchitekturen und Betriebssysteme erstellt und kompiliert, die auf dem fertigen System verwendet werden sollen. Wenn Sie beispielsweise den Code auf einem bestimmten FPGA mit spezifischen Einstellungen ausführen, kompilieren Sie den Code für genau jenes Szenario, um die Funktionsfähigkeit auf der tatsächlichen Verarbeitungsarchitektur und die ausreichende Verfügbarkeit von Ressourcen sicherzustellen. Dies ist ein separat bezeichneter Testschritt, da die Implementierung der verwendeten Verarbeitungsarchitektur und -hardware ein schwieriger und zeitraubender Vorgang sein kann, besonders wenn etwaige Schritte zur Entwurfsoptimierung am elektronischen Steuergerät (ECU) eine eingeschränkte Softwarefunktionalität zur Folge haben.

Rapid Control Prototyping (RCP)

RCP wird zur schnellen Iteration möglicher Steuerungspläne mithilfe mathematischer Modelle eingesetzt, die auf einem Echtzeitregler bzw. FPGA ausgeführt werden, der durch reale I/O mit einer echten Regelstrecke verbunden ist.

Hardware-in-the-Loop-Test (HIL)

HIL bezeichnet das Testen von Software auf dem tatsächlichen Embedded-Regler, wobei die umgebenden physischen Komponenten und Sensoren simuliert werden, sodass das ECU die reale elektrische I/O mit Signalaufbereitung, tatsächlichen Laststufen und der Möglichkeit zur Fehlersimulation ausführt.

Physikalischer Test

Anwendungen zum physikalischen Test nutzen wandlerbasierte Messungen (z. B. von Temperatur, Druck, Spannung/Dehnung, Schall, Beschleunigung usw.) zur Prüfung der physikalischen Eigenschaften der jeweiligen Systemkomponenten. Zu den Anwendungen zählt der NVH-Test (Noise, Vibration, Harshness), der Schall- und Schwingungsmessungen von Mikrofonen und Beschleunigungsmessern beinhaltet. Ein weiteres Beispiel ist die Haltbarkeitstest-/Lebensdauerprüfung (Highly Accelerated Life Test, HALT bzw. Highly Accelerated Stress Screen, HASS), mit der das Verhalten des Prüflings unter verschiedenen potenziellen Betriebsbedingungen ermittelt wird.

Systemintegrationstest​

1. Der gesamte rechte Arm des V-Modells stellt die verschiedenen Stufen im Integrationstest dar. Bei der Integration werden in der Regel zwei grundlegende Arten von Systemen eingesetzt:
   Prüfstände auf Systemebene testen die Integration verschiedener Komponenten in ein einzelnes (Sub-)System. Die Prüfstände eignen sich besonders zur Handhabung vieler verschiedener Tests, weil sie die diversen Teilkomponenten miteinander zu einem funktionsfähigen System integrieren. Ein laufendes System erleichtert den Aufbau und die Durchführung von Tests.
2. Das Systemintegrationslabor, auch „Iron Bird“ genannt, das mehrere Subsysteme für den Test auf Fahrzeugebene miteinander integriert, liefert eine näherungsweise Darstellung des Fahrzeugaufbaus und der Systemanschlüsse. Das Labor eignet sich für das Testen von System of Systems (SoS) sowie der Intersystem-Kommunikation/-Interaktion und Randbedingungen. Einige Testfälle können nur bei entsprechender Infrastruktur berücksichtigt werden. Diese ist die letzte Teststufe vor der Erstellung eines Fahrzeugprototyps für die eigentliche Prüfung unter Einsatzbedingungen, also den Feldversuch bzw. Testflug.

Wartungs-, Reparatur- und Überholungsmaßnahmen (MRO)

MRO-Maßnahmen stellen die Dienste, Reparaturen und Upgrades bereit, die Fahrzeuge während ihrer langen, häufig jahrzehntelangen und generationsübergreifenden Lebensdauer benötigen. Gelegentlich werden die gleichen Prüfgeräte bzw. entsprechend modifizierte Versionen für Systemprüfstände verwendet. Die Herausforderung im Zusammenhang mit MRO-Maßnahmen besteht darin, die Testfunktionalität für die Dauer eines Testprogramms effizient aufrechtzuerhalten, da Obsoleszenzprobleme mit der Testerhardware und -software, Personalfluktuation und wechselnde Anforderungen durch periodische Systemupgrades auftreten können.

Feldversuch

Die für den Feldversuch eingesetzten Fahrzeuge sind in der Regel umfassend mit Messgeräten ausgestattet, damit während dieser kostspieligen Tests so viele Betriebsdaten wie möglich erfasst werden. Zentrale Aspekte sind hierbei Gewicht/Größe, Stromversorgung der Prüfgeräte, Datenspeicherung und Datenabruf. Feldversuche sind zwar zeitintensiv und kostspielig, jedoch auch ein wichtiger Teil des Produktentwicklungsprozesses. Denn Modelle sind niemals perfekt ausgereift und Systeminteraktionen sind so komplex, dass sie zu unvorhergesehenem Verhalten führen, das in den vorangegangenen Testabläufen nicht berücksichtigt wurde. Mittels Feldversuch wird die Betriebsbereitschaft der Fahrzeuge ermittelt.

Prüfanforderungen während des Entwicklungszyklus erfüllen

Da Sie nun mit dem Entwicklungsablauf und den entsprechenden Testtypen vertraut sind, leuchtet Ihnen sicherlich der potenzielle Vorteil einer einheitlichen Testarchitektur ein. Wenn Prüfanforderungen im gesamten Entwurfszyklus durch eine einzige Testplattform erfüllt werden können, angefangen bei der frühen Prototyperstellung über die Validierung von Software, elektrischer und mechanischer Komponenten bis hin zu Prüfzellen auf Systemebene und Systemintegrationslaboren, ist eine schnellere Testentwicklung und effizientere Ressourcenauslastung möglich. In allen Phasen des V-Modells und über alle Programme hinweg bietet sich für die technische Ausstattung wie auch für die Mitarbeiter ein höheres Maß an Interoperabilität und Fungibilität. ​Dadurch können die einzelnen Phasen im V-Modell unter Berücksichtigung der jeweiligen Prüffunktionen und -iterationen schneller und einfacher durchlaufen werden.

Eine einheitliche Testarchitektur bietet ähnliche Vorteile wie objektorientierte Programmiermodelle. Wenn Sie die Gewissheit haben, dass Sie im Grunde genommen immer wieder die gleichen Systeme mithilfe wiederkehrender Methoden entwickeln, empfehlen sich zentrale Bausteine, die projektübergreifend eingesetzt und an die jeweiligen Projektanforderungen angepasst werden können.  

Dieser plattformbasierte Ansatz für das Testen zeichnet sich durch mehr Robustheit aus, da Sie mit einer flexiblen, erweiterbaren Plattform, auf der Ihre Testarchitektur beruht, darauf vertrauen können, dass wechselnde und unvorhersehbare Anforderungen an die System- und Testfunktionalität kein unüberwindbares Hindernis darstellen. Mit anderen Worten wappnet Sie dieser Ansatz bestmöglich für das Unbekannte und nimmt künftige Anforderungen vorweg, indem neue Funktionen entwurfstechnisch nicht explizit ausgeschlossen werden. Dies stellt einen klaren Vorteil gegenüber zweckgebundenen Systemen mit starrer Funktionalität dar, bei denen eine etwaige Flexibilität und Erweiterbarkeit in der Entwurfsphase eigens mitberücksichtigt werden müssen. Solche Systeme mit starrer Funktionalität zwingen Sie dazu, den Kosten- und Zeitaufwand sowie den Funktionsumfang gegeneinander abzuwägen.

Unterstützung modellbasierter Steuerung, Regelung und Simulation

Das Testen sollte im Entwicklungsprozess so früh wie möglich stattfinden, damit schneller Iterationen vorgenommen werden können, der Kostenaufwand reduziert und die Sicherheit erhöht wird. Dafür können Sie auf modellbasierte Steuerungs-, Regelungs- und Simulationsfunktionen zurückgreifen, um im Labor Stimuli und praxisnahe Bedingungen angemessen zu simulieren. Auf diese Weise können Sie Analysen, die zuvor nur bei Feldversuchen möglich waren, im Systemintegrationslabor oder Systemprüfstand durchführen. Verfahren wie z. B. die Aufzeichnung realer Stimulussignale bei Außeneinsätzen und die Wiedergabe auf dem System durch modellgesteuerte Betätigung von Stellgliedern gestalten diese Art von Test noch effizienter.
Außerdem lassen sich Testanforderungen von den Zeitplänen anderer Teams abkoppeln, indem deren Komponenten simuliert werden. Doch um die Zuverlässigkeit von Prüfergebnissen sicherzustellen, müssen Sie noch die Genauigkeit und Wirksamkeit der Modelle und Methoden validieren, die zur Simulation von Komponenten eingesetzt werden.
Ein weiterer Vorteil besteht darin, dass schwer zu replizierende, gefährliche und extreme Testfälle besser bearbeitet werden können. Die somit verbesserte Testabdeckung führt zu mehr Sicherheit im Entwurfsprozess.

Integration und Interoperabilität

Welcher Typ oder welche Marke eines Sensors, Aktors, Messgeräts oder Softwareprogramms Sie für eine bestimmte Funktion einsetzen, ist nicht immer frei wählbar. Denn das Zusammenspiel der verschiedenen Komponenten innerhalb eines Systems beansprucht häufig einen großen Teil des Entwicklungsbudgets für Testsysteme, besonders bei alternden Systemkomponenten in einem nachgerüsteten oder umgebauten Legacy-Testsystem. Die Nutzung einer Plattform mit vielfältiger I/O-Ausstattung und nativer Kompatibilität zu Drittanbietergeräten führt potenziell zu Effizienzsteigerungen, da der Integrationsaufwand durch den Rückgriff auf bereits Vorhandenes minimiert wird. Eine konfigurierbare/erweiterbare und verteilte/synchronisierte I/O-Architektur kann unterschiedliche I/O-Anforderungen für Testfälle im gesamten Entwurfsprozess erfüllen und fördert ein programmübergreifendes Wiederverwenden von Systemen.

Daten- und Systemverwaltung

Eine größere Anzahl von Messungen bei höheren Erfassungsraten führt zu mehr Daten – deutlich mehr Daten – in einer Vielzahl von Formaten. Zudem müssen mehr Kunden auf diese Daten von verschiedenen Testtypen im Entwurfszyklus zugreifen, um weitere Anforderungen bei der Berichterstellung zu erfüllen. Die Brauchbarkeit von Daten und deren tatsächliche Verwendung sicherzustellen ist an sich bereits eine Herausforderung. Deshalb ist es wichtig, dass Sie Daten effektiv finden und laden, interaktiv darstellen und analysieren sowie die Berichterstellung automatisieren können. Eine einheitliche Testarchitektur muss unternehmensweite und IT-freundliche Daten- und Systemmanagement-Frameworks bereitstellen, mit denen die Entscheidungsfindung verbessert, Wiederholungstests reduziert, der Zeitaufwand für die Berichterstellung verringert sowie die Auslastung und Betriebszeit von Anlagen optimiert werden kann.

Global aufgestellte Entwicklungs- und Testteams stehen mehr und mehr vor der Herausforderung, an verschiedenen Standorten verteilte Tester effektiv zu verwalten und die Daten zu korrelieren, die diese generieren. Die effektive Verwaltung verteilter Testsysteme und Daten bietet ein erhebliches Einsparpotenzial, wenn es darum geht, bessere Einblicke in Betriebsabläufe zu erhalten, Ausfallzeiten zu verringern und die Zuverlässigkeit erzeugter Daten zu gewährleisten.

Die Investition in eine einheitliche Testarchitektur, die auf einer softwaredefinierten Testplattform basiert, empfiehlt sich besonders für Teams bzw. Unternehmen, die fortschrittliche elektromechanische Fahrzeugsysteme entwerfen und testen. Eine einheitliche Testarchitektur sorgt für eine schnellere Testentwicklung, bessere Testabdeckung, effizientere Abläufe, einen geringeren Kapitalaufwand sowie eine längere Betriebszeit und Wartbarkeit im Vergleich zu einer benutzerdefinierten Entwicklung, die ausschließlich innerbetrieblich erfolgt oder vollständig ausgelagert wird.