Was Tests in den frühen Phasen des V-Modells Tests

Wichtigste Erkenntnisse

• Tests -in-the-Loop Tests am nützlichsten, wenn sie die Regelungsabsicht überprüfen, bevor software hardware die Diagnose hardware Störsignale hardware .
• Die Rückverfolgbarkeit der Anforderungen verleiht den MIL-Ergebnissen einen dauerhaften Wert, da dieselben Nachweise sowohl in software als auch in hardware übernommen werden können.
• Eine mangelhafte Planentreue und eine lückenhafte Abdeckung führen zu falscher Sicherheit, wodurch grundlegende Konstruktionsfehler in spätere und kostspieligere Phasen verschoben werden.

Tests -in-the-Loop Tests schon früh aus, da sie Lücken in den Anforderungen und Steuerungsfehler aufdecken, bevor die Kosten für die Behebung dieser Fehler durch Code, hardware und Laborzeit in die Höhe schnellen.

Dieser schnelle Gewinn ist von Bedeutung, da schlechte software die Vereinigten Staaten im Jahr 2022 mindestens 2,41 Billionen Dollar. Für Teams, die Steuerungssysteme entwickeln, beginnt ein Großteil dieser Verschwendung schon lange vor Tests physikalischen Tests . Modellbasierte Tests diese Verschwendung, indem sie die Logik anhand der Anforderungen überprüfen, solange das Design noch leicht zu überprüfen ist. Sie erhalten schnelleres Feedback, klarere Fehlerursachen und einen übersichtlicheren Weg in spätere Verifikationsphasen.

„Model-in-the-Loop Tests das Verhalten vor der Implementierung

Tests ein Reglermodell vor Beginn der Implementierung anhand eines Anlagenmodells Tests . Dabei werden Logik, Zustandsübergänge, Grenzwerte und Reaktionen überprüft, solange alles noch auf mathematischer Ebene stattfindet. So erkennen Sie das beabsichtigte Verhalten frühzeitig. Sie können Designfehler beheben, bevor sie durch die Codestruktur oder hardware verdeckt werden.

Ein Entwurf für eine Traktionskontrolle verdeutlicht den Nutzen. Das Reglermodell kann Radgeschwindigkeitssignale aus einem simulierten Fahrzeugsystem auslesen und entscheiden, wann das Drehmoment auf rutschigem Untergrund gedrosselt werden muss. Wenn der Schlupfschwellenwert falsch ist oder die Zustandsmaschine zwischen den Regelmodi schwankt, zeigt sich das Problem bereits auf der Entwurfsebene. Sie benötigen weder kompilierten Code noch einen Prüfstand, um dies zu erkennen.

Deshalb gehört MIL an den Anfang einer ernsthaften Verifikation. Es sollte als frühe Verifikationsphase dienen und nicht als schnelle Modelldemonstration. Eine sinnvolle MIL-Kampagne vergleicht das Verhalten mit den erwarteten Ergebnissen, Fehlerreaktionen und Anforderungsschwellenwerten. Außerdem zeigt sie auf, ob das Anlagenmodell zu einfach ist, um als zuverlässig zu gelten. In diesem Fall besteht die richtige Lösung oft in einer besseren Modellierung, da zusätzliche Testläufe ein schwaches Anlagenmodell nicht korrigieren können.

Die „Model-in-the-Loop“-Simulation entspricht dem frühen V-Modell

Die „Model-in-the-Loop“-Simulation gehört auf die linke Seite des V-Modells, wo aus Systemanforderungen Steuerlogik und ausführbarer Entwurf werden. Sie liefert Ihnen eine testbare Form des Entwurfs, noch bevor mit software begonnen wird. Dieser Zeitpunkt ist entscheidend. Fehler lassen sich in einem frühen Stadium leichter isolieren, da noch weniger Implementierungsdetails eine Rolle spielen.

Ein Batteriemanagement-Controller veranschaulicht diesen Ablauf sehr gut. In den Anforderungen werden Spannungsgrenzen, Temperaturreaktionen und die Schützlogik festgelegt. Anschließend überprüft MIL diese Regeln anhand eines Batteriesystemmodells unter Lade-, Entlade- und Sensorfehlerbedingungen. Wenn sich der Schütz bei Übertemperatur zu spät öffnet, erkennt das Team, dass der Entwurf fehlerhaft ist und die Modelllogik korrigiert werden muss, bevor mit software begonnen wird.

Das V-Modell wird oft als klar strukturierte Kette dargestellt, doch leistungsschwache Teams betrachten MIL als optional, da Code und hardware konkreter hardware . Diese Gewohnheit verlangsamt die Validierung. Wenn die frühen Phasen des V-Modells ausführbare Designprüfungen beinhalten, wird in späteren Phasen weniger Zeit darauf verwendet, die grundlegende Absicht nachzuweisen. Stattdessen wird mehr Zeit auf software , den Zeitplan für die Integration und die Genauigkeit der physikalischen Schnittstellen verwendet.

Ausführbare Anlagenmodelle machen das Verhalten des Reglers frühzeitig sichtbar

Ausführbare Anlagenmodelle machen das Verhalten von Reglern sichtbar, da sie dynamische Eingaben, Zustandsrückkopplungen und Betriebsbeschränkungen liefern, die bei statischen Analysen nicht erkennbar sind. Sie verwandeln die Regelungslogik in ein Regelkreis-System. Man kann beobachten, wie sich die Wechselwirkungen im Laufe der Zeit entwickeln. Dabei werden instabile, verzögerte oder widersprüchliche Reaktionen deutlich.

Betrachten wir einen Motorantriebsregler mit Strombegrenzung, Drehzahlregelung und thermischem Schutz. Ein Anlagenmodell kann Lastsprünge, Sensorrauschen und Sättigungseffekte im gesamten Regelkreis nachbilden. Wenn der Strombegrenzer bei einer plötzlichen Drehmomentanforderung mit dem Drehzahlregler in Konflikt gerät, lässt sich diese Wechselwirkung in der Simulation messen. So lassen sich Überschwingen, Verzögerungen oder Schwingungen erkennen, lange bevor ein Umrichter oder ein Leistungsprüfstand gebucht werden muss.

Die Qualität des Regelobjekts bestimmt die Obergrenze für den MIL-Wert. Ein vereinfachtes Regelobjekt eignet sich zwar zur Überprüfung der Zustandslogik oder der Schwellenwertbehandlung, deckt jedoch keine Kopplungseffekte auf, die von komplexeren physikalischen Zusammenhängen abhängen. Die Modellgenauigkeit sollte auf die jeweilige Fragestellung abgestimmt sein. Wenn das Testziel die Qualität der Transientenregelung ist, muss das Regelobjekt das Transientenverhalten mit einer ausreichend hohen Genauigkeit abbilden, damit die Ergebnisse aussagekräftig sind.

Testfälle sollten sich direkt auf die Systemanforderungen zurückführen lassen

Testfälle in MIL sollten direkt auf die Systemanforderungen abgebildet werden, damit jedes Ergebnis eine relevante Entwurfsfrage beantwortet. Diese Verknüpfung macht Fehler verwertbar. Außerdem verhindert sie Tests modellbasierte Tests einer langen Reihe interessanter Diagramme ohne Verifikationswert werden. Wenn ein Test keine Verknüpfung zu einer Anforderung aufweist, dient er selten als Orientierung für den nächsten Entwicklungsschritt.

Ein Beispiel hierfür ist ein Bremsmischregler. Sie können Tests auf der Grundlage von Drehmomentverteilungsgrenzen, Regeln für die Abschaltung der regenerativen Bremsung, dem zeitlichen Ablauf der Pedalansprache und Ausweichzuständen bei Fehlern erstellen. Diese Verknüpfungen sorgen dafür, dass sich das Team auf die Systemanforderungen konzentriert und die Arbeit eng mit der Verifikation verknüpft bleibt. Die ersten Durchläufe sollten in der Regel folgende an die Anforderungen geknüpfte Prüfungen abdecken:

• Die normalen Betriebspunkte sollten mit dem angegebenen Regelziel übereinstimmen.
• Der Verlust eines Sensors sollte den erforderlichen Ausweichzustand auslösen.
• Die Begrenzungen der Stellglieder sollten die Stabilität innerhalb festgelegter Grenzen gewährleisten.
• Die Start- und Abschaltabläufe sollten die Zeitvorgaben einhalten.
• Bei der Fehlerbehebung sollte die Steuerung erst nach erfolgreichen Prüfungen wiederhergestellt werden.

Die Rückverfolgbarkeit ist auch hilfreich, wenn die MIL-Ergebnisse in die Überprüfungsphase einfließen. Ein fehlgeschlagener, an eine Anforderung geknüpfter Test liefert Ihnen eine präzise Problemstellung, die erwartete Reaktion und einen Nachweispfad. Das verkürzt die Diskussion und hilft den Teams, sich darauf zu einigen, was als Nächstes behoben werden muss. Ohne Rückverfolgbarkeit führen Fehler häufig zu Debatten über Modellannahmen, anstatt zu gezielten Korrekturen am Design.

Wie sich „Model-in-the-Loop“ von software Loop“ unterscheidet

Der Hauptunterschied zwischen „Model-in-the-Loop“ und software besteht darin, dass bei MIL das ausführbare Design getestet wird, während software die software getestet wird. Bei MIL wird geprüft, ob die Regelungsabsicht korrekt ist. Bei SIL wird geprüft, ob der Code diese Absicht beibehält. Jede Stufe beantwortet eine andere Verifikationsfrage.

Ein Drehzahlregler macht die Trennung deutlich sichtbar. Mit MIL lässt sich nachweisen, dass Gain-Scheduling, Anti-Windup-Logik und Fehlerzustände anhand eines Anlagenmodells wie vorgesehen funktionieren. Im Rahmen Software wird anschließend überprüft, ob generierte oder manuell programmierte software unter denselben Eingangsbedingungen und zeitlichen Annahmen dieselben Ergebnisse software . Eine Abweichung bei SIL deutet auf Probleme bei der Implementierung, der Datentypisierung, dem Solver oder der Codegenerierung hin.

„MIL fragt, ob die Regelungsabsicht korrekt ist.“

Die MIL-Ergebnisse sollten den Übergang zu SIL strukturieren

Die MIL-Ergebnisse sollten den Übergang zu SIL strukturieren, da sie die erwarteten Ergebnisse, Akzeptanzbereiche, Randfälle und die Zustandsabdeckung definieren, bevor die Codeausführung in den Mittelpunkt rückt. Diese Struktur verringert Diskussionen darüber, was software ausmacht. Die beabsichtigte Reaktion ist bereits bekannt. SIL überprüft dann, ob die Implementierung diese beibehält.

Ein Steuergerät für eine aktive Federung liefert eine praxisnahe Abfolge. MIL ermittelt die zu erwartenden Dämpferbefehle bei Schlaglochbefahren, Karosserieneigung und Sensorausfällen. Genau diese Szenarien werden zu SIL-Regressionsfällen mit numerischen Toleranzen und Bestehenskriterien. Teams, die OPAL-RT für spätere Ausführungsphasen einsetzen, profitieren besonders davon, wenn die MIL-Ergebnisse bereits Schnittstellen, Abtastzeiten und Akzeptanzgrenzen mit dieser Präzision beschreiben.

Diese Übergabe funktioniert am besten, wenn Sie mehr als nur Diagramme beibehalten. Speichern Sie Eingabemengen, erwartete Zustandsübergänge, Signaltoleranzen und Fehlerhinweise in einer Form, die software wiederverwenden kann. So verbringen Sie weniger Zeit damit, Tests neu zu erstellen, und haben mehr Zeit, um aussagekräftige Unterschiede zu überprüfen. SIL sollte sich wie eine strengere Implementierungsprüfung anfühlen, die auf derselben Evidenzbasis wie MIL aufbaut.

MIL-Tests verringern das Risiko hardware vor dem HIL

MIL-Tests verringern das Risiko hardware vor hardware , da sie Designfehler beseitigen, für deren Diagnose physikalische Teststände nur bedingt geeignet sind. Sie reduzieren die Unwägbarkeiten, bevor Timing, Schnittstellen und Elektronik ins Spiel kommen. Das spart kostspielige Laborzeit. Außerdem sorgt es dafür, dass sich der HIL-Test auf das Integrationsverhalten konzentriert, anstatt auf die grundlegende Steuerungslogik.

Ein Steuergerät für die elektrische Servolenkung verdeutlicht dies. Wenn MIL bereits die Unterstützungskurven, die Fehlerverriegelung und die Regeln für die Drehmomentüberlagerung überprüft hat, kann sich HIL auf die Sensorlatenz, das Bus-Timing und das Verhalten der Aktuatorschnittstelle konzentrieren. Sind diese Grundlagen bei hardware noch nicht geklärt, lässt sich jeder Fehler nur schwer einordnen. Man fragt sich dann, ob das Problem im Design, im Code, in der Verkabelung oder im Prüfstandsaufbau liegt.

HIL hat eine andere Aufgabe, und es ist zu kostspielig, Unklarheiten in der frühen Entwurfsphase mit sich zu tragen. Die Ressourcen der Entwicklungsabteilung, die Techniker und die Messzeit sind begrenzt. MIL schützt diese Ressourcen, indem es Nachweise liefert, dass das beabsichtigte Regelverhalten stabil ist. Die Teams nutzen HIL dann für das, was es am besten kann: die Überprüfung der Ausführung unter physikalischen Einschränkungen und Schnittstellen-Timing.

Lücken im MIL-Versicherungsschutz wecken in späteren Phasen ein trügerisches Vertrauen

Lücken in der MIL-Abdeckung wecken ein trügerisches Vertrauen, wenn ein Modell zwar gängige Szenarien besteht, jedoch Vorteil , die Fehlerbehandlung oder Anforderungsgrenzen außer Acht lässt. Eine solche Erfolgsquote ist zwar beruhigend, aber irreführend. In späteren Phasen treten dann grundlegende Designprobleme zutage, die bereits früher hätten erkannt werden müssen. Die Kosten für diese Versäumnisse bestehen in der Regel aus Nacharbeit, Verzögerungen und technischer Verschuldung.

Ein Wärmemanagement-Controller kann nominelle Kühltests bestehen und dennoch bei Sensorvereisung, Pumpenverschleiß oder Schwellenwertschwankungen schwerwiegende Fehler aufweisen. Diese Versäumnisse sind oft auf enge Testbereiche oder unzureichende Annahmen hinsichtlich der Anlage zurückzuführen. Sie sind selten böswillig beabsichtigt. Die mit mangelhafter software verbundene technische Verschuldung belief sich in den Vereinigten Staaten im Jahr 2022 1,52 Billionen US-Dollar. Verborgene Lücken in der Verifikation sind einer der stillen Wege, auf denen sich diese Schulden anhäufen.

„Gute MIL-Arbeit schafft Vertrauen, weil sie klarstellt, was bereits abgedeckt wurde und was noch nicht.“

Sie sollten nicht unterstützte Betriebsbereiche, vereinfachte Annahmen zur Anlage sowie Anforderungsbereiche, die noch geprüft werden, dokumentieren. Diese Ehrlichkeit sorgt dafür, dass spätere Fehler weniger überraschend sind und sich leichter einordnen lassen. OPAL-RT passt gut zu dieser disziplinierten Vorgehensweise, da die frühe Modellierung und die spätere Echtzeit-Validierung am besten funktionieren, wenn sie als ein kontinuierlicher Verifikationsprozess betrachtet werden.