Kontinuierliche Integration zur Verifikation von Simulink-Modellen
Von David Boissy, Paul Urban, Krishna Balasubramanian, Pablo Romero Cumbreras, Colin Branch und Jemima Pulipati, MathWorks
Wenn Sie R2022a oder höher verwenden und über eine Simulink Check™-Lizenz verfügen, können Sie Ihre CI-Integration optimieren, indem Sie das Support-Paket CI/CD Automation for Simulink Check verwenden. Mit dem Support-Paket können Sie ein Prozessmodell für Ihr Team definieren und Ihr CI-System so einrichten, dass die Tasks in Ihrem Prozess automatisch als Pipeline in CI ausgeführt werden. Das Support-Paket umfasst die Unterstützung mehrerer CI-Plattformen, sodass Sie automatisch Pipelines speziell für Ihr Projekt und Ihren Prozess generieren können und manuelle Updates überflüssig werden.
Hauptmerkmale:
- Integrierte Tasks: Automatisieren Sie allgemeine Tasks in Ihrem modellbasierten Entwicklungs- und Verifizierungsworkflow, indem Sie integrierte Tasks für Aktivitäten wie die Überprüfung von Modellierungsstandards mit Model Advisor, das Ausführen von Tests mit Simulink Test™ und das Generieren von Code mit Embedded Coder® verwenden. Anstatt verschiedene Skripte für Ihre Entwicklungs- und Überprüfungsaktivitäten zu verwalten, können Sie diese integrierten Tasks neu konfigurieren und für eine konsistente Ausführung und organisierte Task-Ergebnisse verwenden.
- Inkrementelle Builds: Identifizieren Sie die Auswirkungen einer Änderung auf Ihr Projekt und führen Sie automatisch nur die betroffenen Tasks erneut aus, um die Build-Effizienz zu verbessern. Die Process Advisor-App und ihr Build-System können Tasks mit veralteten Ergebnissen erneut ausführen und aktuelle Tasks automatisch überspringen.
- Automatische Pipeline-Generierung: Verwenden Sie die Vorlagendatei des Supportpakets, um automatisch Pipelines zu generieren, sodass Sie CI/CD-Konfigurationsdateien nicht manuell aktualisieren müssen, wenn Sie Änderungen an Ihrem Projekt oder Prozess vornehmen. Sie können die Einstellungen des Pipeline-Generators einfach anpassen, um Ihre Tasks in verschiedene Jobs aufzuteilen, Modell-Tasks parallel auszuführen und andere Pipeline-Verhaltensweisen zu ändern.
Weitere Informationen finden Sie unter Kontinuierliche Integration und Integration in Jenkins.
Dies ist der erste Artikel einer zweiteiligen Serie. Teil 1 befasst sich mit der Nutzung von GitLab® für Versionskontrolle und Jenkins® für kontinuierliche Integration (CI). Teil 2, Kontinuierliche Integration zur Verifizierung von Simulink-Modellen mit GitLab, untersucht die Verwendung von GitLab sowohl für die Versionskontrolle als auch für CI.
Kontinuierliche Integration (CI) erfreut sich zunehmender Beliebtheit und wird zu einem integralen Bestandteil von Model-Based Design. Aber was ist CI? Was sind seine Vorteile und welche Probleme versucht es zu lösen? Wie passt Simulink® in das CI-Ökosystem? Und wie können Sie CI am besten für Ihre Projekte nutzen?
Wenn Sie mit Model-Based Design vertraut sind, aber neu bei CI sind, stellen Sie sich möglicherweise diese Fragen. In diesem Fachbeitrag untersuchen wir einen gängigen CI-Workflow und wenden ihn auf Model-Based Design an. Anschließend gehen wir ein Beispiel dieses Workflows mit Jenkins, GitLab und Simulink Test durch.
Das in diesem Beispiel verwendete Projekt ist zum Download verfügbar.
Was ist CI?
CI ist eine bewährte Praxis für eine agile Methodik, bei der Entwickler ihre Quellcodeänderungen regelmäßig übermitteln und in einem zentralen Repository zusammenführen. Diese „Änderungs-Sets“ werden dann automatisch erstellt, qualifiziert und freigegeben. Abbildung 1 veranschaulicht diesen grundlegenden CI-Workflow zusammen mit dem Entwicklungsworkflow.
Im Entwicklungsteil des Workflows werden Modelle und Tests entwickelt, verifiziert, zusammengeführt, überprüft und an ein Versionskontrollsystem auf dem Entwickler-Desktop übermittelt. Das Versionskontrollsystem löst dann den automatisierten CI-Teil des Workflows aus. Die wichtigsten Teile des CI-Workflows sind:
Build: Quellcode und Modelle werden zu Objektdateien und ausführbaren Dateien.
Test: Das Testen wird als Qualitätsschleuse durchgeführt.
Paketieren: Ausführbare Dateien, Dokumentationen, Artefakte und andere Liefergegenstände werden für die Bereitstellung an Endbenutzer gebündelt.
Bereitstellen: Pakete werden in der Produktionsumgebung bereitgestellt.
Zusammen werden diese vier Schritte als CI-„Pipeline“ bezeichnet. Die Pipeline ist normalerweise automatisiert und ihre Fertigstellung kann je nach System zwischen Minuten und Tagen dauern. Es ist erwähnenswert, dass im Laufe dieser Schritte zahlreiche Artefakte erstellt werden, wie z. B. Stücklisten, Testergebnisse und Berichte.
CI-Workflows werden häufig mit Entwickler-Workflows gepaart, die sich auf Versionskontrollsysteme beziehen. In diesen Workflows speichern Entwickler ihre Änderungen häufig in lokalen Repositories und verwenden eine lokale CI-Pipeline, um ihre Änderungen vor der Bereitstellung zu qualifizieren.
Was sind die Vorteile von CI?
Teams, die CI implementiert haben, berichten typischerweise von den folgenden Vorteilen:
- Wiederholbarkeit. Die CI-Pipeline bietet einen konsistenten und wiederholbaren automatisierten Prozess zum Erstellen, Testen, Paketieren und Bereitstellen. Durch wiederholbare Automatisierung können sich Entwickler auf die notwendige Arbeit konzentrieren und bei einem Projekt Zeit sparen. Darüber hinaus ist es ein wichtiger Aspekt der Risikominderung und häufig Voraussetzung für die Zertifizierung.
- Qualitätssicherung. Manuelle Tests sind effektiv, basieren jedoch häufig auf mehrere Tage alten Schnappschüssen und sind nicht wiederholbar. Mit CI werden Änderungen immer anhand der aktuellsten Codebasis getestet.
- Reduzierte Entwicklungszeit. Wiederholbare Prozesse mit integrierter Qualitätssicherung führen zu einer schnelleren Lieferung qualitativ hochwertiger Produkte. Durch die automatisierte Bereitstellung ist Ihr Code immer produktionsbereit.
- Verbesserte Zusammenarbeit. Mit CI verfügen Entwickler über einen definierten Prozess zum Verwalten von Änderungssätzen und zum Einbinden ihres Codes in die Produktionslinie. Einheitliche Prozesse ermöglichen die Verwaltung großer Teams und reduzieren den Aufwand für die Einarbeitung neuer Entwickler.
- Auditfähiger Code. Der CI-Workflow bietet einen umfassende Prüfpfad. Für jede Änderung, die die CI-Pipeline durchläuft, lässt sich ermitteln, wer die Änderung vorgenommen und wer sie überprüft hat, um welche Art von Änderung es sich dabei handelt und welche Abhängigkeiten, Tests und deren Ergebnisse vorliegen. Zudem lässt sich eine beliebige Anzahl zugehöriger Berichte und Artefakte ermitteln, die während des Vorgangs generiert wurden.
Wie passt Model-Based Design in CI?
Der CI-Workflow und die CI-Tools sind von Natur aus sprach- und domänenneutral. Das bedeutet, dass die Herausforderung darin besteht, CI-Tools, -Systemen und -Prozessen beizubringen, Model-Based Design zu sprechen – mit anderen Worten, Simulink und verwandte Tools zur Lingua Franca des CI-Workflows zu machen.
Dies kann durch die Integration von drei Schlüsselkomponenten des Model-Based Designs in den CI-Workflow erreicht werden: Verifikation, Codegenerierung und Testen (Abbildung 2). Beim Model-Based Design wird die frühzeitige Verifikation betont, was der CI-Pipeline mit einer Verifizierungsphase vor der Build-Phase entspricht. Die Codegenerierung findet in der Build-Phase statt. In der Testphase können dynamische Tests durch Simulation und statische Analyse des generierten Codes durchgeführt werden.
Hier ist ein Überblick darüber, wie wir dem CI-Workflow beibringen, Model-Based Design zu sprechen:
Entwickeln. MATLAB®, Simulink, Coder und Toolboxen werden für Entwicklungsaktivitäten verwendet. MATLAB Projekte werden zur Arbeitsorganisation, Zusammenarbeit und Schnittstelle mit Versionskontrollsystemen verwendet.
Testen. Simulink Check wird verwendet, um vor der Simulation und Codegenerierung Modellqualitätsprüfungen durchzuführen. Simulink Test wird zum Entwickeln, Verwalten und Ausführen simulationsbasierter Tests verwendet. Simulink Coverage™ wird verwendet, um die Abdeckung zu messen und die Testwirksamkeit zu beurteilen. Die Qualitätsprüfungen, Testergebnisse und Abdeckungsmetriken können dann als Qualitätsschleuse für Entwickler verwendet werden, um ihre Arbeit zu qualifizieren.
Zusammenführen (Merge). Die Funktion „Compare Files and Folders“ von MATLAB wird zum Vergleichen und Zusammenführen von MATLAB Dateien verwendet. Das Model Comparison Tool dient zum Vergleichen und Zusammenführen von Simulink-Modellen.
Überprüfen. Die Überprüfung ist der letzte Schritt im Qualitätssicherungsprozess, bevor Änderungen an das Versionskontrollsystem übermittelt werden. Änderungen an MATLAB -Skripten und Simulink Modellen werden hier überprüft. Auch die Testergebnisse aus der Vorqualifizierung werden als letztes Qualitätskriterium vor der Einreichung geprüft.
Einreichen. MATLAB Projekte bieten eine Schnittstelle zu Versionskontrollsystemen.
Verifizieren. Für die automatisierte Verifizierung innerhalb des CI-Systems wird Simulink Check verwendet, dasselbe Tool, das für die lokale Verifizierung verwendet wird.
Build. MATLAB Coder™, Simulink Coder™ und Embedder Coder werden zum Generieren von Code für Software-in-the-Loop-Tests (SIL) verwendet.
Testen. Für automatisierte Tests innerhalb des CI-Systems wird Simulink Test verwendet, dasselbe Tool wie für lokale Tests.
Paketieren und bereitstellen. Beim Paketieren werden ausführbare Dateien, Dokumentationen, Artefakte und andere Liefergegenstände für die Bereitstellung an Endbenutzer gebündelt. Unter Bereitstellung versteht man die Freigabe der paketierten Software. In den Arbeitsabläufen für Model-Based Design unterscheiden sich diese Phasen je nach Organisation und Gruppe erheblich und beinhalten häufig die Bündelung verschiedener Builds und Zertifizierungsartefakte zu einem Produkt, das zur Auslieferung an andere Teams bereit ist.
Moderne Entwicklungstools und -praktiken ermöglichen es Entwicklern, robustere Systeme zu erstellen und die Funktionalität frühzeitig und häufig zu testen. Wenn ein CI-System in den Arbeitsablauf integriert ist, werden Tests auf Unit- und Systemebene automatisiert. Dies bedeutet, dass sich der Entwickler auf die Entwicklung neuer Funktionen konzentrieren kann und nicht darauf achten muss, ob die Funktionen korrekt integriert wurden.
Die folgende Fallstudie beschreibt einen Workflow, der CI und Model-Based Design umfasst.
Fallstudie: Ein in einem CI-System verifizierter, erstellter und getesteter Build eines Simulink-Modells
In diesem Beispiel verwenden wir Model-Based Design mit CI, um anforderungsbasierte Tests an einem Spurhaltesystem für Kraftfahrzeuge durchzuführen (Abbildung 3).
Die von uns verwendete Pipeline (Abbildung 4) wird bei jedem Jenkins-Build ausgeführt.
Abbildung 4. Pipeline für ein Beispiel zur Spurhaltung.
Die Phasen in der Pipeline sind wie folgt:
- Überprüfen der Einhaltung der Standards: Ein MATLAB Unit-Skript führt eine einfache Model Advisor-Prüfung aus. Die Bewertungskriterien stellen sicher, dass das Modell keine unverbundenen Linien aufweist.
- Modell erstellen: Eine MATLAB Unit-Testdatei erstellt Produktions-SIL-Code für unser Modell. Die Bewertungskriterien werden erfüllt, wenn der Build ohne Warnung erfolgreich ist.
- Testfälle ausführen: Eine Testsuite in Simulink Test nutzt mehrere Fahrszenarien, um den Spurfolgeregler zu testen. Zur Überprüfung der einwandfreien Funktion des Reglers werden drei Bewertungskriterien herangezogen:
- Kollisionsvermeidung: Zu keinem Zeitpunkt des Fahrszenarios kommt es zu einer Kollision des Ego-Fahrzeugs mit dem vorausfahrenden Fahrzeug.
- Einhaltung des Sicherheitsabstands: Der Zeitabstand zwischen dem Ego-Fahrzeug und dem vorausfahrenden Auto beträgt über 1,5 Sekunden. Der Zeitabstand zwischen den beiden Fahrzeugen wird als Verhältnis des berechneten Voraus-Abstands zur Geschwindigkeit des Ego-Fahrzeugs definiert.
- Spurverfolgung: Die seitliche Abweichung von der Fahrbahnmittellinie beträgt maximal 0,2 Meter.
- Artefakte paketieren: Jede der vorherigen Phasen erzeugt Artefakte, darunter einen Model Advisor-Bericht, eine generierte ausführbare Datei und eine Reihe von Testergebnissen, die zur zukünftigen Verwendung oder Referenz archiviert werden können.
Workflow-Schritte
Der Workflow besteht aus den folgenden Schritten (Abbildung 5):
- Auslösen eines Build in Jenkins und beobachten, ob die Phasen „Verify“ und „Build“ erfolgreich sind.
- Erkennen eines Testfallfehlers in Jenkins.
- Reproduzieren des Problems auf unserem Desktop-MATLAB.
- Beheben des Problems im Modell durch Lockerung der Bewertungskriterien.
- Lokal testen um sicherzustellen, dass der Testfall bestanden wird.
- Zusammenführen und überprüfen der Änderungen im Testzweig.
- Commit der Änderung auf Git™ und Auslösen eines Build in Jenkins.
- Überprüfen, Build erstellen und Testen in Jenkins.
Unser erster fehlgeschlagener Durchlauf durch die CI-Schleife ist oben links dargestellt. Er zeigt das Fehlschlagen des CI-Tests, die lokale Reproduktion, die Lockerung der Kriterien und den erfolgreichen Abschluss des CI-Workflows.
Workflow-Details
- Wir beginnen mit dem Auslösen eines Build in Jenkins durch Auswahl von Build Now. Prüfungen und Codegenerierung in Simulink Check sind erfolgreich.
![Ein Screenshot des Dropdown-Menüs des Jenkins-Dashboards. „Build Now“ ist ausgewählt.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1314375792.adapt.full.medium.jpg/1739442246295.jpg)
- Als nächstes erkennen wir einen Testfallfehler in der zweiten Verifikationsphase. Der Testfall
LFACC_Curve_CutInOut_TooClose
in der TestsuiteLaneFollowingTestScenarios
erfüllt die Bewertungskriterien nicht.
![Ein Screenshot einer Fehlerzusammenfassung.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1274891353.adapt.full.medium.jpg/1739442246310.jpg)
- Um den Fehler besser zu verstehen, reproduzieren wir den Fehler lokal mit Simulink Test. Wir öffnen die Testdatei
LaneFollowingTestScenarios.mldatx
und führen den TestfallLFACC_Curve_CutInOut_TooClose
aus. Beachten Sie, dass die Bewertungskriterien für den Sicherheitsabstand nicht erfüllt werden. Es bedarf mehr Flexibilität bei der Festlegung des Zeitabstands zwischen vorausfahrendem Fahrzeug und Ego-Fahrzeug.
![Ein Screenshot eines Simulink Test mit den bestandenen Bewertungskriterien.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_421698181.adapt.full.medium.jpg/1739442246322.jpg)
- Mit diesem Verständnis des Problems können wir nun das Problem beheben. Wir öffnen das
LaneFollowingTestBenchExample.slx
-Modell und navigieren zum Test-Sequenzblock „Kollisionserkennung/Testbewertungen“. Die erste Einschätzung besagt, dass der Zeitabstand zwischen dem Ego- und dem führenden Auto nicht länger als zwei Sekunden am Stück unter 1,5 Sekunden fallen sollte.
GlobalAssessments % Ensure that the time gap between the ego vehicle and lead vehicle does not dip below % 1.5s for more than 2s at a time. verify(duration(time_gap < 1.5, sec) < 2); % Verify that no collision was detected verify(~collision); % Verify that the absolute value of lateral deviation from the lane centerline does not exceed 0.2m % for more than 5s at a time. verify(duration(abs(lateral_deviation) > 0.2, sec) < 5);
Für das getestete aggressive Fahrmanöver ist diese Einschätzung zu restriktiv. Für die Zwecke dieses Beispiels lockern wir die Bewertungskriterien, um sicherzustellen, dass die Zeitlücke nicht für länger als 5 Sekunden am Stück unter 0,8 Sekunden fällt.
GlobalAssessments % Ensure that the time gap between the ego vehicle and lead vehicle does not dip below % 0.8s for more than 5s at a time. verify(duration(time_gap < 0.8, sec) < 5); % Verify that no collision was detected verify(~collision); % Verify that the absolute value of lateral deviation from the lane centerline does not exceed 0.2m % for more than 5s at a time. verify(duration(abs(lateral_deviation) > 0.2, sec) < 5);
- Das Problem scheint in unserer Simulation behoben zu sein. Zur Bestätigung testen wir lokal, dazu speichern wir das Modell und führen die Tests erneut im Testmanager aus. Beachten Sie, dass es den neuen Bewertungskriterien entspricht.
![Ein Screenshot eines Simulink Test mit den bestandenen Bewertungskriterien.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_915256185.adapt.full.medium.jpg/1739442246342.jpg)
- Wir haben das Problem behoben und lokal verifiziert. Wir verwenden jetzt das Model Comparison Tool, um die Änderungen zu überprüfen, bevor wir sie der Versionskontrolle übergeben.
![Ein Screenshot, der den Vergleich alter und neuer Änderungen im Model Comparison Tool zeigt.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_2114472669.adapt.full.medium.jpg/1739442246359.jpg)
Wir könnten auch die Publish-Funktion des Model Comparison Tool verwenden, um den Code zu überprüfen.
![Ein Screenshot, der den Vergleich alter und neuer Änderungen zeigt, wenn die Publish-Funktion des Model Comparison Tool verwendet wird.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_1389600109.adapt.full.medium.jpg/1739442246379.jpg)
- Nachdem der Fehler behoben ist, übertragen wir diese Änderungen auf den Bereich in GitLab mit MATLAB-Projekten und fügen eine Commit-Nachricht hinzu, um auf die Änderung der Bewertungskriterien hinzuweisen.
Anschließend stellen wir das neuste Commit in GitLab fest.
GitLab löst automatisch einen Build in Jenkins aus. Das Jenkins-Projekt-Dashboard zeigt den Build-Status und den Fortschritt an.
![Ein Screenshot des Jenkins-Projekt-Dashboards, das den Build-Status und den Fortschritt über einen Ladebalken anzeigt.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1160520298.adapt.full.medium.jpg/1739442246410.jpg)
- Der Jenkins-Build wird ausgeführt. Wir sehen, dass die Pipeline-Phasen Verifizieren, Erstellen und Testen nun durchlaufen werden.
Wir können jetzt eine Merge-Anfrage starten, um die Änderungen im Testzweig in den Hauptzweig zu integrieren. In GitLab unter Repository wählen wir Filialen und klicken dann auf Merge request neben dem neuesten Commit im Testzweig.
Wir füllen das Formular aus und senden die Zusammenführungsanfrage ab.
Als Eigentümer des Zweigs können wir die Zusammenführungsanfrage akzeptieren, indem wir auf die Merge-Taste klicken. Alle Änderungen werden jetzt im Hauptzweig erfasst.
![Ein Screenshot der Meldung, die angezeigt wird, wenn eine Merge-Anfrage erfolgreich ist.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_2099516143.adapt.full.medium.jpg/1739442246442.jpg)
Verwendung des Beispiels: Tools, Ressourcen und Anforderungen
In den folgenden Abschnitten werden die Ressourcen beschrieben, die Ihnen den Einstieg erleichtern. Sie erhalten außerdem einen Überblick über die Tools, die Sie benötigen, und wie diese konfiguriert werden sollten.
Systeme konfigurieren
Jenkins wird als unser CI-System und GitLab als unser Versionskontrollsystem genutzt. MATLAB, Jenkins und GitLab müssen für die Zusammenarbeit konfiguriert werden. Die folgenden Tutorials helfen bei der Einrichtung.
- Konfigurieren des MATLAB Projekts
- Konfigurieren von Jenkins
- Konfigurieren von GitLab, um Jenkins auszulösen
Die Tutorials beziehen sich speziell auf GitLab und Jenkins, die Konzepte können jedoch auch auf andere Versionskontroll- und CI-Systeme angewendet werden.
Erforderliche Werkzeuge
Für dieses Beispiel werden folgende Werkzeuge benötigt:
- Jenkins Installation Version 2.7.3 oder höher. Jenkins wird für kontinuierliche Integration verwendet.
- MATLAB Plugin für Jenkins Version 1.0.3 oder höher. MATLAB, Simulink und Simulink Test nutzen alle dieses Plug-In, um mit Jenkins zu kommunizieren. Weitere Informationen auf GitHub.
- Zusätzlich erforderliche Plugins:
- GitLab-Konto. GitLab wird zur Quellcodeverwaltung verwendet und ist als Cloud-Dienst verfügbar. MATLAB-Projekte enthalten eine Git-Schnittstelle für die Kommunikation mit GitLab.
Lizenzüberlegungen für CI
Wenn Sie CI auf vielen Hosts oder in der Cloud durchführen möchten, wenden Sie sich an continuous-integration@mathworks.com um Unterstützung. Hinweis: Für Transformationsprodukte wie MATLAB und Simulink Coder- und Compilerprodukte sind möglicherweise Client Access Licenses (CALs) erforderlich.
Anhang: Konfigurieren von MATLAB, GitLab und Jenkins
Schritt 1: Konfigurieren des MATLAB-Projekts für die Verwendung der Quellcodeverwaltung
Der erste Schritt in unserem Beispiel besteht darin, unser Projekt so zu konfigurieren, dass die Quellcodeverwaltung mit GitLab verwendet wird.
- Erstellen Sie ein neues Verzeichnis mit dem Namen
MBDExampleWithGitAndJenkins
, laden Sie das Beispiel hinein und öffnen Sie MATLABProject MBDExampleWithGitAndJenkins.prj
. - Erstellen Sie in GitLab ein neues Projekt, das als Remote-Repository dient. Nennen Sie es
MBDExampleWithGitAndJenkins
und notieren Sie die URL, unter der es gehostet wird. - Konvertieren Sie das Projekt in MATLAB, um die Quellcodeverwaltung zu verwenden. Klicken Sie auf der Registerkarte Project auf Use Source Control.
![Ein Screenshot, der die Registerkarte „Project “ in MATLAB mit ausgewählter Schaltfläche „Use Source Control“ zeigt.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1426591191.adapt.full.medium.jpg/1739442246462.jpg)
Klicken Sie Add Project to Source Control.
![Ein Screenshot des Popups mit den Quellcodeverwaltungsinformationen. Die Integration ist auf „Keine“ eingestellt und der Repository-Speicherort ist nicht anwendbar. Darin wird angegeben, dass für das Projektstammverzeichnis kein Quellcodeverwaltungssystem erkannt wurde, und es gibt eine Schaltfläche mit der Aufschrift „Projekt zur Quellcodeverwaltung hinzufügen“.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1616796560.adapt.full.medium.jpg/1739442246478.jpg)
- Klicken Sie Convert.
![Ein Popup zum Hinzufügen zur Quellcodeverwaltung. Als Quellcodeverwaltungstool wird Git ausgewählt und das Projekt-Root-Verzeichnis angegeben. Es gibt eine Schaltfläche zum Konvertieren.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_711112368.adapt.full.medium.jpg/1739442246494.jpg)
- Klicken Sie Open Project wenn Sie fertig sind.
![Ein Screenshot, der zeigt, wie Dateien zur Quellcodeverwaltung hinzugefügt werden. Die Dateien haben alle Prüfungen bestanden und eine Schaltfläche „Open Project“ ist vorhanden. Ein Git-Menü mit mehreren Schaltflächen und Logistik wird angezeigt.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1843929107.adapt.full.medium.jpg/1739442246514.jpg)
Das Projekt steht jetzt unter lokaler Git-Quellcodeverwaltung.
Schritt 2: Änderungen übergeben und lokales Repository zu GitLab hochladen
- Auf dem Project -Tab auf Remote klicken.
![Ein Screenshot der MATLAB-Registerkarte „Projekt“ mit hervorgehobener Option „Remote“.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1131172368.adapt.full.medium.jpg/1739442246534.jpg)
- Geben Sie die URL des Remote-Ursprungs in GitLab an.
![Ein Screenshot des Popups „Set Remote“. Es verfügt über ein Formular zum Angeben einer U R L für den Remote-Ursprung. Die angegebene URL ist unscharf und unten befinden sich die Schaltflächen „Validate“ und „OK“.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1715246667.adapt.full.medium.jpg/1739442246550.jpg)
Klicken Sie Validate, um sicherzustellen, dass die Verbindung zum Remote-Repository erfolgreich ist, und klicken Sie auf OK. Das Projekt ist jetzt so konfiguriert, dass Änderungen mit GitLab hoch- und heruntergeladen werden können.
- Klicken Sie Commit um ein erstes Commit durchzuführen.
![Ein Screenshot der MATLAB-Registerkarte „Project“ mit hervorgehobener Schaltfläche „Commit“.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_176678025.adapt.full.medium.jpg/1739442246570.jpg)
![Ein Screenshot des Kommentarfensters mit der Commit-Nachricht als Initial Commit.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_2080776722.adapt.full.medium.jpg/1739442246582.jpg)
- Klicken Sie Push um alle Änderungen vom lokalen Repository in das Remote-Repository von GitLab zu übertragen.
![Ein Screenshot der MATLAB -Registerkarte „Project“ mit ausgewählter Schaltfläche „Push“.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1335693290.adapt.full.medium.jpg/1739442246598.jpg)
- Aktualisieren Sie das GitLab-Dashboard und beobachten Sie den Inhalt des MATLAB Projekts.
Schritt 3: Testzweig erstellen
In diesem Schritt erstellen wir einen Testzweig zum Testen und Überprüfen von Änderungen vor dem Zusammenführen mit dem Hauptzweig.
- Klicken Sie Branches.
![Ein Screenshot der MATLAB -Registerkarte „Project“ mit ausgewählter Schaltfläche „Branches“.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1687868341.adapt.full.medium.jpg/1739442246640.jpg)
- Erweitern Sie Branch and Tag Creation , nennen Sie den Zweig „Test“ und klicken Sie auf Create.
- Beobachten Sie Test im Branch Browser. Klicken Sie im Zweig „Test“ auf Switch, dann auf Close.
- Wählen Sie in MATLAB Push um diese Änderungen auf GitLab zu übertragen und den Test-Zweig in GitLab zu beobachten.
Schritt 4: Konfigurieren von Jenkins, um MATLAB aufzurufen
- Installieren Sie zwei erforderliche Plugins:
- GitLab-Plugin – Mit diesem Plugin kann GitLab Jenkins-Builds auslösen und deren Ergebnisse in der GitLab-Benutzeroberfläche anzeigen.
- MATLAB -Plugin — Dieses Plugin integriert MATLAB mit Jenkins und stellt die Jenkins-Schnittstelle zum Aufrufen von MATLAB und Simulink bereit.
- Wählen Sie New Item und erstellen Sie ein neues FreeStyle-Projekt mit dem Namen
MBDExampleUsingGitAndJenkins
. - Aktivieren Sie Git unter „Source Code Management“, richten Sie Jenkins auf unser GitLab-Repository aus und geben Sie den Testzweig zum Erstellen ein. Hinweis: Es sind Login oder Passwort sowie ein GitLab API-Token erforderlich.
- Konfigurieren Sie den Build Trigger (Build-Auslöser) so, dass ein Build ausgeführt wird, wenn eine Push-Anforderung an den Test-Zweig in GitLab gesendet wird. Wählen Sie im Abschnitt Build Triggers Advanced > secret token. Dieses geheime Token wird von GitLab verwendet, um einen Build anzufordern und sich bei Jenkins zu authentifizieren. Notieren Sie sich das geheime Token und die GitLab-Webhook-URL.
- Konfigurieren Sie die Build-Umgebung. Wählen MATLAB Version verwenden und geben Sie das MATLAB-Stammverzeichnis ein.
- Konfigurieren Sie den Build-Schritt.
Klicken Sie Add build step und wählen Sie Run MATLAB Command. Geben Sie den Befehl openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecModelAdvisor
ein, um das Projekt zu öffnen und Model Advisor-Prüfungen auszuführen.
Klicken Sie Add build step und wählen Sie wieder Run MATLAB Command. Geben Sie den folgenden Befehl ein: openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecControllerBuild.
Klicken Sie Add build step und wählen Sie Run MATLAB Tests. Wählen Sie TAP test results und Cobertura code coverage, um die Build-Konfiguration abzuschließen.
Diese Aktion analysiert die TAP-Testergebnisse und macht sie sichtbar, wenn TAP Extended Test Results ausgewählt ist. Die Ausgabe enthält eine Übersicht über die ausgeführten Testfälle, die Ergebniszusammenfassung und Protokolle aus der MATLAB Konsole.
![Ein Screenshot eines Dropdown-Menüs auf dem Dashboard mit hervorgehobener Option „TAP Extended Test Results“.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_361369158.adapt.full.medium.jpg/1739442246864.jpg)
Das TAP-Plugin sammelt auch die Ergebnisse der letzten Testausführungen und zeigt ein Integritätsdiagramm wie unten dargestellt an. Sie können auf alle vorherigen Builds zugreifen, indem Sie auf das Diagramm klicken.
![Ein Diagramm der TAP-Testergebnisse, das die Jenkins-Build-Nummer auf der X-Achse und die Anzahl der TAP-Tests auf der Y-Achse zeigt. Tests werden farblich als nicht bestanden, bestanden, übersprungen oder auszuführen gekennzeichnet. Mit zunehmender Build-Nummer steigt auch die Anzahl der bestandenen Tests.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1468401417.adapt.full.medium.jpg/1739442246892.jpg)
Schritt 6: Veröffentlichen von HTML-Berichten
Klicken Sie Add post-build action > Publish HTML reports. Geben Sie den relativen Stammpfad ein, in dem der HTML-Bericht veröffentlicht wird, und den Dateinamen der Indexseite, die sich im Pfad befindet.
Fügen Sie so viele Einträge hinzu, wie HTML-Berichte veröffentlicht werden sollen. In diesem Szenario gibt es zwei Webberichte: Die Model Advisor-Zusammenfassung und der Codegenerierungsbericht. Dies sind Standardberichte, die mit integrierten MATLAB-Funktionen erstellt wurden. Sie können benutzerdefinierte HTML-Berichte hinzufügen.
Sie finden auf der Hauptseite des Jenkins-Jobs für jeden HTML-Bericht einen Berichtslink zum letzten Build. Wenn Sie die Checkbox "Always link to last build" (Immer mit letztem Build verknüpfen) unter Publishing options aktivieren, veröffentlicht das Plugin Berichte für den letzten Build, unabhängig vom Build-Status. Wenn diese Checkbox nicht aktiviert ist, verlinkt das Plugin nur auf den letzten „erfolgreichen“ Build.
Schritt 7: Konfigurieren von GitLab zum Auslösen eines Builds in Jenkins
Konfigurieren Sie GitLab so, dass ein automatischer Build in Jenkins ausgelöst wird, wenn ein neuer Push im Hauptzweig erfolgt. Navigieren Sie dazu zu Settings > Webhooks. Verwenden Sie die Webhook-URL und das geheime Token, das von Jenkins in der Build-Trigger-Konfiguration bereitgestellt wird, und wählen Sie Push events.
Hinweis: Verwenden Sie im URL-Abschnitt anstelle von localhost einen vollqualifizierten Domänennamen, damit GitLab die Jenkins-Installation finden kann.
![Ein Screenshot des Webhook-Popups mit ausgefülltem URL-Formular, leerem Feld „Geheimes Token“ und angekreuztem „Push-Ereignisse“ unter „Trigger“ mit einem Formular zum Ausfüllen des Triggers.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1428097271.adapt.full.medium.jpg/1739442246964.jpg)
Im Test-Pulldownmenü, wählen Sie Push Events um die Integration zu testen. GitLab zeigt die Meldung „Hook executed successfully: HTTP 200“ und Jenkins startet einen Build.
![Ein Screenshot des Project Hooks-Popups mit den aktivierten Webhook-Details.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_2045155438.adapt.full.medium.jpg/1739442246983.jpg)
Schritt 8: Konfigurieren der Jenkins-zu-GitLab-Authentifizierung
Um einen Jenkins-Build-Status automatisch auf GitLab zu veröffentlichen, müssen Sie die Jenkins-zu-GitLab-Authentifizierung konfigurieren.
- Erstellen Sie auf GitLab ein persönliches Zugriffstoken mit ausgewähltem API-Bereich.
![Ein Screenshot des Popups für persönliche Zugriffstoken mit Feldern zum Hinzufügen des Namens, des Ablaufdatums und des Geltungsbereichs für das Token mit dem Namen „GitLabToJenkins“. Unter „Scopes“ ist „API“ aktiviert, wodurch vollständiger Lese-/Schreibzugriff auf die API gewährt wird.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1313549631.adapt.full.medium.jpg/1739442246999.jpg)
- Kopieren Sie das Token und erstellen Sie unter Jenkins Configure System eine GitLab-Verbindung.
Hinweis: Verbindungen können über mehrere Jenkins-Jobs hinweg wiederverwendet werden und können global konfiguriert werden, wenn der Benutzer mindestens über „Maintainer“-Rechte verfügt.
Schritt 9: Integrieren von Jenkins in die GitLab-Pipeline
Um Jenkins in die GitLab-Pipeline zu integrieren, müssen Sie die GitLab-Verbindung in Jenkins konfigurieren und den Jobstatus an GitLab veröffentlichen.
- Wählen Sie die GitLab Connection im Abschnitt „General“ Ihres Jenkins-Jobs.
- Fügen Sie eine Post-Build-Aktion hinzu, um den Build-Status in GitLab zu veröffentlichen.
Hinweis: Diese Aktion hat keinen Parameter und verwendet die vorhandene GitLab-Verbindung, um den Build-Status auf GitLab zu veröffentlichen und eine bidirektionale Rückverfolgbarkeit für jede Commit- und Merge-Anfrage zu erstellen.
![Ein Screenshot der hinzugefügten Post-Build-Aktion „Build-Status in GitLab veröffentlichen“. Es gibt eine Schaltfläche für Erweiterte Optionen.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_702713251.adapt.full.medium.jpg/1739442247051.jpg)
Schritt 10: Visualisierung anforderungsbasierter Testmetriken (R2020b)
Anforderungsbasierte Testmetriken ermöglichen Ihnen die Bewertung des Status und der Qualität Ihrer anforderungsbasierten Testaktivitäten. Die Metrikergebnisse können mithilfe des Model Testing Dashboards visualisiert werden.
- Erstellen Sie eine Datei namens
collectModelTestingResults.m
basierend auf der unten gezeigten Funktion. Diese Funktion initialisiert die Infrastruktur der Metrik-Engine und sammelt alle verfügbaren Modellmetriken.
function collectModelTestingResults() % metric capability added in R2020a if exist('metric') metricIDs = [... "ConditionCoverageBreakdown" "CoverageDataService"... "DecisionCoverageBreakdown" "ExecutionCoverageBreakdown"... "MCDCCoverageBreakdown" "OverallConditionCoverage"... "OverallDecisionCoverage" "OverallExecutionCoverage"... "OverallMCDCCoverage" "RequirementWithTestCase"... "RequirementWithTestCaseDistribution" "RequirementWithTestCasePercentage"... "RequirementsPerTestCase" "RequirementsPerTestCaseDistribution"... "TestCaseStatus" "TestCaseStatusDistribution"... "TestCaseStatusPercentage" "TestCaseTag"... "TestCaseTagDistribution" "TestCaseType"... "TestCaseTypeDistribution" "TestCaseWithRequirement"... "TestCaseWithRequirementDistribution" "TestCaseWithRequirementPercentage"... "TestCasesPerRequirement" "TestCasesPerRequirementDistribution"... ]; % collect all metrics for initial reconcile E = metric.Engine(); execute(E, metricIDs); end end
- Fügen Sie diese Datei zu Ihrem Projekt und zum Pfad hinzu.
- Konfigurieren Sie Jenkins zum Sammeln von Metrikergebnissen durch den zweimaligen Aufruf von
new collectModelTestingResults function
. Der erste Aufruf initialisiert die Metrikintegration mit Simulink Test Manager. Der zweite Aufruf sammelt die Messergebnisse mithilfe der exportierten Simulink Test Manager-Ergebnisse.- Klicken Sie Add build step und wählen Sie erneut Run MATLAB Command. Geben Sie den folgenden Befehl ein:
openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
Positionieren Sie diesen Build-Schritt vor dem Schritt Run MATLAB Tests . - Klicken Sie Add build step und wählen Sie wieder Run MATLAB Command. Geben Sie den Befehl erneut ein:
openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
Positionieren Sie diesen Build-Schritt nach dem Schritt Run MATLAB Tests.
- Klicken Sie Add build step und wählen Sie erneut Run MATLAB Command. Geben Sie den folgenden Befehl ein:
- Überprüfen Sie Ergebnisse von Simulink Test Manager im Build-Schritt Run MATLAB Tests.
![Ein Screenshot des Popup-Fensters des Build-Schritts. Das Formular für Simulink Test Manager-Ergebnisse wird ist dem Dateipfad ausgefüllt.](https://ch.mathworks.com/de/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_897862517.adapt.full.medium.jpg/1739442247118.jpg)
- Archivieren Sie die Messergebnisse im abgeleiteten Verzeichnis. Sie müssen auch die exportierten Test-Manager-Ergebnisse archivieren, da diese beim Zurückladen in MATLAB eine vollständige Navigation der Metrikergebnisse ermöglichen.
Klicken Sie Add post-build action und wählen Sie Archive the artifacts. Geben Sie den Pfad derived/**,matlabTestArtifacts/*.mldatxx
ein, um alle in diesem Verzeichnis gespeicherten Dateien zu archivieren.
Hinweis: Um diese Ergebnisse in MATLAB auf einem anderen Computer als dem Testcomputer anzuzeigen, gehen Sie wie folgt vor:
- Laden Sie die archivierten Artefakte herunter (abgeleitetes Verzeichnis und MLDATX-Dateien mit Testergebnissen).
- Extrahieren und kopieren Sie dieselbe Version des Projekts, die zum Ausführen des CI-Jobs verwendet wurde, in eine lokale Kopie.
- Öffnen Sie das Projekt in MATLAB und starten Sie das Model Testing Dashboard.
Die vom CI generierten Ergebnisse werden auf dem Dashboard angezeigt.
Jenkins® ist eine eingetragene Marke von LF Charities Inc.
Veröffentlicht 2024