Embedded IDE Link 4.2

Produktbeschreibung

• Einführung
• Arbeiten mit Embedded IDE Link
• Embedded Verifikation und Debugging mit MATLAB
• Processor-in-the-Loop-Verifikation mit Simulink
• Projekt- und Bibliothekserstellung mit Real-Time Workshop
• Unterstützte IDEs und Anbieter

Processor-in-the-Loop-Verifikation mit Simulink

Über Embedded IDE Link können Sie komponentenbasierte Tests durchführen, bei denen Simulink als Testumgebung fungiert. In Verbindung mit Real-Time Workshop Embedded Coder erzeugt Embedded IDE Link über Ihr Modell eine PIL-Testumgebung, welche die Schnittstelle zum Datenaustausch zwischen der Hostsimulation und dem auf dem Zielsystem ausgeführten Objektcode darstellt.

Das Original-Simulink-Modell kann dann auch als Embedded Testumgebung verwendet werden, um die Codeausführung auf dem Zielsystem zu verifizieren, während Daten automatisch zwischen dem Code auf dem Zielsystem und dem Modell in Simulink übertragen werden.

PIL-Tests bei Regelungs- und Steuerungsanwendungen

Für jede Anwendung können Open-Loop-Tests erarbeitet werden, die den Signal Builder-Block oder einen anderen Simulink-Quellblock zur Generierung der Eingangs-Teststimuli nutzen. In der Regel werden Closed-Loop-Tests erstellt, indem ein Open-Loop-Test durch ein Streckenmodell ergänzt wird. Bei Ausführung im Rahmen einer PIL-Kosimulation liefert ein Streckenmodell den Testingenieuren überaus genaue Testszenarien, welche gerade die Elemente des dynamischen Softwareverhaltens widerspiegeln, die über einen Open-Loop-Test nicht adressierbar sind.

Funktionale Verifikation mittels PIL

PIL-Tests laufen nicht in Echtzeit, da Simulink die Ausführung des PIL-Codes auf dem Zielprozessor oder dem Befehlssatz-Simulator steuert. Die Simulation wird bei jedem Zeitschritt unterbrochen, während Daten zum Zielprozessor oder zum Befehlssatz-Simulator übertragen werden. Sobald die Ausführung des Objektcodes auf dem Prozessor abgeschlossen ist, werden die Daten zurück zum Host übertragen, um die Hostsimulation fortzusetzen. Anhand dieses Ansatzes können Sie die funktionalen Unterschiede zwischen dem Modell und dem generierten und kompilierten Objektcode prüfen und so eventuell durch den Kompilationsprozess hervorgerufene Abweichungen im Systemverhalten feststellen.

Das Beispiel einer Rauschunterdrückung mit Processor-in-the-Loop-Modell zeigt die Ergebnisse auf dem Host (oben) und dem Zielprozessor (unten) sowie den Unterschied zwischen den beiden Datensätzen (rechts).