Verkürzter Produktentwicklungszyklus durch schnelleres Testen: Die Grundzüge des V-Modells

Überblick

Elektromechanische Systeme wie z. B. das Antriebssystem eines Flugzeugs bestehen aus Software, Reglern und mechanischen Komponenten. Da die Komplexität solcher Systeme zunimmt, bedarf es leistungsfähiger Testverfahren, um die erforderliche Testabdeckung im Rahmen der jeweiligen Projektzeitpläne und Budgetvorgaben erzielen zu können. Außerdem müssen die automatisierten Prüfsysteme, die dabei zum Einsatz kommen, zur Erfüllung von Serviceverträgen für MRO-Güter (Maintenance, Repair, Obsolescence) über viele Jahrzehnte hinweg gewartet sowie zur Durchführung von Systemupgrades in regelmäßigen Abständen modifiziert werden.

Die Unterstützung zunehmend komplexer Prüflinge und Prüfsysteme über so lange Programmlebenszyklen stellt eine Herausforderung dar, zumal angesichts beschränkter Ressourcen. Ein flexibler, plattformbasierter Ansatz unterstützt Sie bei der Entwicklung einer einheitlichen Testarchitektur, mit der diese Herausforderungen bewältigt werden können. Die Vereinheitlichung auf eine einzige Testarchitektur bietet etliche Vorteile, u. a. verkürzte Testentwicklungszeiten und einen verringerten Arbeitsaufwand für Testteams, die in getrennten Gruppen an verschiedenen Stellen im Entwicklungszyklus tätig sind.

Eine einheitliche Testarchitektur für elektromechanische Systeme weist im Idealfall folgende Eigenschaften auf:

• Erfüllen von Testanforderungen im gesamten Entwurfszyklus vom Prototyping bis hin zur Software, von der Validierung elektrischer und mechanischer Eigenschaften über Systemprüfstände und -integrationslabore (Iron Birds) bis hin zu Fertigungstests
• Unterstützung modellbasierter Steuerung, Regelung und Simulation für das frühzeitige Testen im Entwicklungszyklus und zur Abdeckung einer erweiterten Testmatrix mit schwierig zu replizierenden Testfällen und Belastungstests
• Integration einer Vielzahl von I/O-Modulen und Hardware von Drittanbietern wie z. B. Sensoren, Aktoren, Messgeräte und Software, wodurch die Wiederverwendbarkeit maximiert und der Aufwand für die Systemintegration reduziert wird. Damit die unterschiedlichen I/O-Anforderungen für die Testfälle in einem Entwurfsprozess und für das Wiederverwenden in verschiedenen Testprogrammen erfüllt werden können, ist eine konfigurierbare/erweiterbare und verteilte/synchronisierte I/O-Architektur erforderlich.
• Bereitstellung unternehmensübergreifender und IT-freundlicher Datenverwaltungs- und Systemmanagementarchitekturen, um die Entscheidungsfindung zu optimieren, Wiederholversuche zu reduzieren, Berichterstellungszeit und -aufwand zu verringern sowie die Anlagenauslastung und -betriebszeit zu erhöhen.

Inhaltsverzeichnis

  1. Model-in-the-Loop(MIL)-Test
  2. Software-in-the-Loop(SIL)-Test
  3. Processor-in-the-Loop(PIL)-Test
  4. Rapid Control Prototyping (RCP)
  5. Hardware-in-the-Loop(HIL)-Test​
  6. Physikalischer Test
  7. Systemintegrationstest​
  8. Wartungs-, Reparatur- und Überholungsmaßnahmen (MRO)
  9. Feldversuch
  10. Aufbau einer einheitlichen Testarchitektur: Erfüllen der verschiedenen Anforderungen im Entwurfszyklus
  11. Aufbau einer einheitlichen Testarchitektur: Unterstützung modellbasierter Steuerung, Regelung und Simulation
  12. Aufbau einer einheitlichen Testarchitektur: Integration und Interoperabilität
  13. Aufbau einer einheitlichen Testarchitektur: Daten- und Systemmanagement
  14. Bessere Ergebnisse mit einer einheitlichen Testarchitektur
  15. Nächste Schritte​

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 (z. B. eine Line-Replaceable-Unit, LRU), auf denen maßgeschneiderte Software zur Steuerung der mechanischen und physischen Komponenten sowie Aktoren mithilfe der Werte von Sensoren und anderen Systemen ausgeführt wird. Elektromechanische Systeme liefern den Fahrzeugantrieb und erfüllen eine Reihe weiterer Funktionen an Bord von Flugzeugen, Landfahrzeugen und Schiffen.

Electromechanical Systems in VehiclesElektromechanische Systeme in Fahrzeugen

Abb. 1: Ausgewählte Fahrzeugkategorien und ihre gängigen elektromechanischen 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, Software und mechanischen Komponenten passend anhand der 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, womit das fertige Fahrzeug entsteht.

Electromechanical Systems Test Across the Design ProcessTesten elektromechanischer Systeme an jedem Punkt im Entwurfsprozess

Abb. 2: Allgemeiner Produktentwicklungsprozess bei elektromechanischen Systemen

Der Entwicklungsprozess, also die verschiedenen Phasen von den Anforderungen über den Entwurf bis hin zur Validierung, lässt sich auf verschiedene Weise beschreiben, so z. B. durch das Vorgehensmodell oder kurz V-Modell (Abbildung 3). Wenngleich das V-Modell zahlreiche Varianten und Spielarten aufweist, 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.

Design V with Development and Test Tasks

Abb. 3: Das V-Modell zur Darstellung des Entwicklungsprozesses und zugehöriger Testtypen

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 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 Spitze 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, die Software ausführen, weshalb die Spitze des V gelegentlich mit Implementierung gekennzeichnet ist. Der rechte Arm des V zeigt die Integration der verschiedenen Komponenten miteinander und überprüft den Betrieb auf Einhaltung der Spezifikationen. Außerdem wird in jeder Phase der Systemintegration die Leistungsfähigkeit gegen die Anforderungen validiert, angefangen bei den implementierungsnahen Teilkomponenten bis hin zum fertigen 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 Ausdrücke Verifizierung und Validierung werden teils unterschiedslos gebraucht. Zudem wird gelegentlich die Kurzform V&V verwendet. Während der Verifizierung fragen Sie sich vermutlich, ob Sie das System richtig konstruieren, und möchten außerdem sicherstellen, dass Ihr System wie erwartet (innerhalb einer gewissen Toleranz) funktioniert, indem Sie einen Abgleich mit den Spezifikationen vornehmen. Während der Validierung hingegen stellen Sie sich 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 hoch 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 wie das Wasserfallmodell den Entwicklungsprozess lediglich in Phasen abbildet.

Nach oben

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

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

Nach oben

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

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.

Nach oben

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

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.

Nach oben

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.

Nach oben

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

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.

Nach oben

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 Dauerhaltbarkeits-/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.

Nach oben

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 genannt Iron Bird, 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.
Nach oben

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

MRO-Maßnahmen (von engl. Maintenance, Repair, Overhaul) stellen die Dienste, Reparaturen und Upgrades bereit, die Fahrzeuge während ihrer langen, ja häufig jahrzehntelangen und generationsübergreifenden Lebensdauer benötigen. Gelegentlich werden die gleichen Prüfgeräte bzw. entsprechende 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.

Nach oben

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 hierbei sind 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 und Systeminteraktionen sind so komplex, dass sie zu unvorhergesehenem Verhalten führen, das in den vorangegangenen Testprozeduren eventuell nicht berücksichtigt wurde. Mittels Feldversuch wird die Betriebsbereitschaft der Fahrzeuge ermittelt.

Nach oben

Aufbau einer einheitlichen Testarchitektur: Erfüllen der verschiedenen Anforderungen im Entwurfszyklus

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 ist ein klarer Vorteil gegenüber zweckgebundenen Systemen mit starrer Funktionalität, 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.

Nach oben

Aufbau einer einheitlichen Testarchitektur: 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 im Feld möglich waren, im Systemintegrationslabor oder Systemprüfstand durchführen. Verfahren wie z. B. die Aufzeichnung realer Stimulussignale im Feld 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 getestet werden können. Die somit verbesserte Testabdeckung führt zu mehr Sicherheit im Entwurfsprozess.

Nach oben

Aufbau einer einheitlichen Testarchitektur: 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 Kompatiblitä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.

Nach oben

Aufbau einer einheitlichen Testarchitektur: Daten- und Systemmanagement

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. Somit werden Daten zu einem wertvollen Gut und sind nicht länger unnötige Last.

Global aufgestellte Entwicklungs- und Testteams stehen mehr und mehr vor der Herausforderung, an mehreren 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.

Nach oben

Bessere Ergebnisse mit einer einheitlichen Testarchitektur

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 inhouse erfolgt oder etwa vollständig outgesourct wird.

Nach oben

Nächste Schritte​

 

Nach oben