Simulink モデル検証のための継続的インテグレーション

これは2部構成のシリーズの最初の記事です。パート 1 では、バージョン管理向けの GitLab^® と継続的インテグレーション (CI) 向けの Jenkins^® の活用について見ていきます。パート 2 の GitLab を使用した Simulink モデルの検証のための継続的インテグレーションでは、バージョン管理と CI の両方に GitLab を使用する方法について説明します。

継続的インテグレーション (CI) は人気が高まり、モデルベースデザインの不可欠な部分になりつつあります。しかし、CIとは何でしょうか?その利点は何ですか? また、どのような問題を解決しようとしていますか?Simulink^® はどのように CI エコシステムに適合しますか?プロジェクトで CI を最大限に活用するにはどうすればよいでしょうか? 

モデルベースデザインには精通しているが、CI は初めてという場合は、次のような疑問が湧くかもしれません。この技術記事では、一般的な CI ワークフローを検討し、それをモデルベース デザインに適用します。次に、Jenkins、GitLab、 Simulink Test を使用してそのワークフローの例を見ていきます。 

この例で使用されているプロジェクトはダウンロード可能です。 

CI とは何ですか?

CI は、開発者がソース コードの変更を定期的に中央リポジトリに送信してマージするアジャイル手法のベスト プラクティスです。これらの「変更セット」は自動的に構築、認定され、リリースされます。図 1 は、この基本的な CI ワークフローと開発ワークフローを示しています。 

ワークフローの開発部分では、モデルとテストが開発、検証、マージ、レビューされ、開発者のデスクトップ上のバージョン管理システムに送信されます。次に、バージョン管理システムはワークフローの自動化された CI 部分をトリガーします。CI ワークフローの重要な部分は次のとおりです。 

ビルド: ソース コードやモデルがオブジェクトファイルや実行可能ファイルになります。 

テスト: テストは品質ゲートとして実行されます。 

パッケージ: 実行可能ファイル、ドキュメント、アーティファクト、その他の成果物は、エンドユーザーへの配布用にバンドルされます。 

デプロイ: パッケージが実稼働環境にデプロイされます。 

これら 4 つのステップをまとめて CI「パイプライン」と呼びます。パイプラインは通常自動化されており、システムに応じて完了するまでに数分から数日かかる場合があります。これらのステップ全体を通じて、部品表、テスト結果、レポートなど、多数のアーティファクトが作成されることに注意してください。 

CI ワークフローは、バージョン管理システムに関連する開発者ワークフローと組み合わせられることがよくあります。これらのワークフローでは、開発者は多くの場合、変更をローカル リポジトリに保存し、デプロイ前にローカル CI パイプラインを使用して変更を検証します。 

CI の利点は何ですか?

CI を実装したチームは通常、次のような利点を報告しています。 

• 再現性。 CI パイプラインは、ビルド、テスト、パッケージ化、デプロイメント向けに繰り返し可能な一貫した自動化プロセスを提供します。繰り返し可能な自動化により、開発者は必要な作業に集中でき、プロジェクトの時間を節約できます。これはリスク低減の重要な側面でもあり、多くの場合、認証の要件となります。
• 品質保証。手動テストは効果的ですが、数日前のスナップショットに基づいていることが多く、再現性に欠けます。CI では、変更は常に最新のコード ベースに対してテストされます。
• 開発時間の短縮。品質保証が組み込まれた繰り返し可能なプロセスにより、高品質の製品をより早く提供できるようになりました。自動デプロイメントとは、コードが常に本番環境に対応できる状態であることを意味します。
• コラボレーションの向上。 CI を使用すると、開発者は変更セットを管理し、コードを生産ラインにマージするための定義されたプロセスを持つことができます。一貫したプロセスにより、大規模なチームの管理が可能になり、新しい開発者の増員にかかるコストが削減されます。
• 監査対応コード。 CI ワークフローは広範な監査証跡を提供します。CI パイプラインを通過するすべての変更について、変更を行ったユーザー、変更をレビューしたユーザー、変更の性質、依存関係、テストとその結果、および途中で生成された関連レポートとアーティファクトの数を識別できます。

モデルベースデザインは CI にどのように適合しますか? 

設計上、CI ワークフローとツールは言語やドメインに依存しません。つまり、課題は CI ツール、システム、プロセスにモデルベースデザインを理解させることで、Simulink と関連ツールを CI ワークフローの共通言語にすることです。 

これは、モデルベースデザインの 3 つの主要コンポーネント (検証、コード生成、テスト) を CI ワークフローに統合することによって実現できます (図 2)。モデルベースデザインでは、ビルド フェーズの前に検証フェーズを含む CI パイプラインにマッピングされる早期検証を重視します。コード生成はビルド フェーズで行われます。テスト フェーズでは、シミュレーションによる動的テストと生成されたコードの静的分析を実行できます。 

以下は、私たちがどのように CI ワークフローにモデルベースデザインを理解させ、その言語を話せるようにしたかまとめたものです。 

開発。MATLAB^®、Simulink、コーダー、ツールボックスが、開発作業に使用されます。MATLABプロジェクトは、作業を整理し、共同作業を行い、バージョン管理システムと連携するために使用されます。 

テスト。Simulink Check は、シミュレーションとコード生成の前にモデルの品質チェックを実行するために使用されます。Simulink Testは、シミュレーション ベースのテストの開発、管理、実行に使用されます。Simulink Coverage™ は、カバレッジを測定し、テストの有効性を評価するために使用されます。品質チェック、テスト結果、カバレッジ メトリックは、開発者が自分の作業を認定するための品質ゲートとして使用できます。 

マージ。MATLAB のファイルとフォルダーの比較機能は、MATLABファイルを比較してマージするために使用されます。モデル比較ツールは、 Simulinkモデルを比較およびマージするために使用されます。 

レビュー。レビューは、変更がバージョン管理システムに送信される前の品質プロセスの最終ステップです。ここでは、 MATLABスクリプトとSimulinkモデルへの変更を確認します。事前資格審査のテスト結果も、提出前の最終的な品質ゲートとして確認されます。 

送信。MATLABプロジェクトは、バージョン管理システムへのインターフェースを提供します。 

確認。ローカル検証に使用されるものと同じツールであるSimulink Check が、CI システム内での自動検証に使用されます。 

ビルド。MATLAB Coder™、 Simulink Coder™、Embedder Coder は、ソフトウェアインザループ (SIL) テスト用のコードを生成するために使用されます。 

テスト。ローカル テストに使用されるものと同じツールである Simulink Test が、CI システム内の自動テストに使用されます。 

パッケージとデプロイ。パッケージ化とは、実行可能ファイル、ドキュメント、アーティファクト、その他のアーティファクトをエンド ユーザーに配布するためにまとめることです。デプロイメントは、パッケージ化されたソフトウェアのリリースです。モデルベースデザインのワークフローでは、これらのフェーズは組織やグループによって大きく異なり、多くの場合、さまざまなビルドと認証アーティファクトを 1 つの製品にバンドルして、他のチームに提供できるようにします。 

最新の開発ツールとプラクティスにより、開発者はより堅牢なシステムを作成し、機能を早期かつ頻繁にテストできるようになります。CI システムをワークフローに統合すると、ユニットレベルのテストとシステムレベルのテストが自動化されます。つまり、開発者は機能が正しく統合されているかどうかの検証ではなく、新しい機能の開発に集中できることになります。 

次のケーススタディでは、CI とモデルベースデザインを組み込んだワークフローについて説明します。 

ケーススタディ: CI システム内で検証、構築、テストされたSimulinkモデル 

この例では、CI を使用したモデルベースデザインを使用して、自動車の車線追従システムに対して要件ベースのテストを実行します (図 3)。

使用するパイプライン (図 4) は、Jenkins ビルドごとに実行されます。

パイプラインのフェーズは次のとおりです。 

1. 標準への準拠を確認する:MATLABユニット スクリプトは、単純なモデル アドバイザー チェックを実行します。評価基準により、モデルに接続されていない線がないことが保証されます。
2. ビルドモデル:MATLAB ユニット テスト ファイルは、モデル用の量産 SIL コードをビルドします。警告なしにビルドが成功した場合、評価基準はパスとなります。
3. テストケースを実行します。Simulink Testのテスト スイートでは、いくつかの運転シナリオを使用して車線追従コントローラーをテストします。コントローラーの正常な動作を確認するために、次の 3 つの評価基準が使用されます。
   • 衝突回避:運転シナリオ中のどの時点でも、自車は先頭車両と衝突しません。
   • 安全な距離の維持:自車と先頭車とのタイムギャップは1.5秒以上です。2 台の車間の時間差は、計算された車間距離と自車の速度の比率として定義されます。
   • 車線追従:車線の中心線からの横方向の偏差は0.2メートル以内です。
4. パッケージ アーティファクト:前の各段階では、モデル アドバイザー レポート、生成された実行可能ファイル、将来の使用や参照のためにアーカイブできる一連のテスト結果などのアーティファクトが生成されます。

ワークフローの手順

ワークフローは次のステップで構成されます (図 5)。 

1. Jenkins でビルドをトリガーし、検証とビルドのステージをパスしたことを確認する。
2. Jenkins でのテストケースの失敗を検出する。
3. デスクトップ版の MATLAB 上で問題を再現する。
4. 評価基準を緩和することでモデルの問題を修正する。
5. テストケースが確実にパスするようにローカルでテストする。
6. テストブランチでの変更をマージしてレビューする。
7. Git™ への変更をコミットし、Jenkins でビルドをトリガーする。
8. Jenkins で検証、ビルト、テストを行う。

CI ループの最初の失敗したパスが左上に示されています。CI テストの失敗、ローカルでの再現、基準の緩和、および CI ワークフローの正常な完了を示します。

ワークフローの詳細

1. まず Build Now を選択して Jenkins でビルドをトリガーします。Simulink Check がチェックされ、コード生成がパスになります。

2. 次に、 2 番目の検証フェーズでテストケースの失敗を検出します。テストスイート LaneFollowingTestScenarios の テストケース LaneFollowingTestScenarios が評価基準を満たしていません。

3. 失敗をより理解するために、Simulink Test を使用してローカルで失敗を再現します。テストファイル LaneFollowingTestScenarios.mldatx を開き、テストケース LFACC_Curve_CutInOut_TooClose を実行します。安全距離の評価基準を満たしていないことに注意してください。先頭車両と自車両間の時間差を確立するには、より柔軟性が必要です。

4. 問題を理解した上で、次に問題を修正します。LaneFollowingTestBenchExample.slx モデルを開き、Collision Detection/Test Assessments Test Sequence ブロックに移動します。最初の評価では、自車と先頭車両との間の時間差が、一度に 2 秒以上 1.5 秒を下回ってはならないと主張しています。

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);

この評価は、テスト対象の攻撃的な運転操作には制限が厳しすぎます。この例では、時間差が一度に 5 秒以上 0.8 秒を下回らないように評価基準を緩和します。

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); 

5. この問題はシミュレーションでは修正されたようです。確認するには、ローカルでテストします。(モデルを保存して、テスト マネージャーでテストを再実行)新しい評価基準にパスしていることに注意してください。

6. 問題は修正され、ローカルで検証されました。次にモデル比較ツールを使って、バージョン管理にコミットする前に変更をレビューします。

モデル比較ツールのパブリッシュ機能を使用してコードをレビューすることもできます。

7. バグが修正されたので、これらの変更をMATLABプロジェクトとともに GitLab にプッシュし、評価基準の変更を通知するコミット メッセージを追加します。

次に、GitLab の最新のコミットを記録します。

GitLab は Jenkins でビルドを自動的にトリガーします。Jenkins プロジェクト ダッシュボードには、ビルドのステータスと進行状況が表示されます。

8. Jenkins ビルドが実行されます。検証、構築、テストのパイプラインフェーズがパスしていることを確認します。

これで、マージ リクエストを開始して、テスト ブランチの変更をメイン ブランチにマージできるようになりました。GitLabのリポジトリで、ブランチを選択し、テスト ブランチ上の最新のコミットの横にあるマージリクエストをクリックします。

フォームに記入し、マージリクエストを送信します。

ブランチのオーナーとして、マージボタンクリックして、マージリクエストを承認します。すべての変更がメイン ブランチにキャプチャされました。

例の使用:ツール、リソース、要件 

次のセクションでは、開始する際に役立つリソース、必要なツール、およびそれらの構成方法について説明します。 

システムの構成

Jenkins は CI システムとして活用され、GitLab はバージョン管理システムとして活用されています。MATLAB、Jenkins、GitLab は連携して動作するように設定する必要があります。次のチュートリアルがセットアップに役立ちます。 

• MATLAB プロジェクトを構成する
• Jenkins の構成
• Jenkins をトリガーするように GitLab を設定する

チュートリアルは GitLab と Jenkins に固有のものですが、概念は他のバージョン管理システムや CI システムにも適用できます。 

必要ツール

この例では次のツールが必要です。 

• Jenkins インストールバージョン 2.7.3 以降。Jenkins は継続的インテグレーションに使用されます。
• Jenkins 用 MATLAB プラグインバージョン 1.0.3 以降。MATLAB、 Simulink、 Simulink Test はすべて、このプラグインを利用して Jenkins と通信します。GitHubで詳細を見る。
• 必要な追加プラグイン:
  • GitLab
  • TAP プラグイン
  • HTML パブリッシャー プラグイン
• GitLab アカウント。GitLab はソース管理に使用され、クラウド サービスとして利用できます。MATLABプロジェクトには、GitLab との通信用の Git インターフェイスが含まれています。

CI のライセンスに関する考慮事項

複数のホストまたはクラウド上で CI を実行する予定がある場合は、 Continuous-integration@mathworks.com に連絡してサポートを依頼してください。注: MATLAB、Simulink Coder 、コンパイラなどの変換用製品には、クライアント アクセス ライセンス (CAL) が必要になる場合があります。

付録MATLAB、GitLab、Jenkins の設定

手順 1. ソース管理を使用するようにMATLABプロジェクトを構成する

この例の最初のステップは、GitLab でソース管理を使用するようにプロジェクトを構成することです。 

1. MBDExampleWithGitAndJenkins という名前の新しいディレクトリを作成して、そこに例を読み込んで、MATLAB プロジェクト MBDExampleWithGitAndJenkins.prj を開きます。
2. GitLab で、リモート リポジトリとなる新しいプロジェクトを作成します。MBDExampleWithGitAndJenkins という名前を付けて、ホスト先の URL を記録します。
3. MATLABで、ソース管理を使用するようにプロジェクトを変換します。プロジェクトタブで、ソース管理の使用をクリックします。

ソース管理にプロジェクトを追加をクリックします。

4. 変換をクリックします。

5. 完了したら、プロジェクトを開くをクリックします。

プロジェクトは現在、ローカル Git ソース管理下にあります。

手順 2. 変更をコミットし、ローカルリポジトリを GitLab にプッシュする

1. プロジェクトタブのリモートをクリックします。

2. GitLab のリモートオリジンの URL を指定します。

検証をクリックして、リモートリポジトリへの接続が成功していることを確認し、OK をクリックします。これで、プロジェクトは GitLab を使用して変更をプッシュおよびプルするように構成されました。

3. コミットをクリックして、最初のコミットを実行します。

4. プッシュをクリックして、ローカル リポジトリからリモート GitLab リポジトリにすべての変更をプッシュします。

5. GitLab ダッシュボードを更新し、 MATLABプロジェクトの内容を確認します。

手順 3: テストブランチを作成する

このステップでは、メイン ブランチとマージする前に変更をテストおよび検証するためのテスト ブランチを作成します。

1. ブランチをクリックします。

2. ブランチとタグの作成セクションを展開して、ブランチに「Test」という名前を付けて、作成をクリックします。

3. ブランチ ブラウザでテストを確認します。テストブランチから、スイッチ、閉じると順にをクリックします。

4. MATLABで、プッシュを選択して、これらの変更を GitLab にプッシュし、GitLab の Test ブランチを確認します。

手順 4: MATLAB を呼び出すように Jenkins を設定する

1. 必要なプラグインを 2 つインストールします。
   • GitLab プラグイン— このプラグインを使用すると、GitLab は Jenkins ビルドをトリガーし、その結果を GitLab UI に表示できるようになります。
   • MATLAB プラグイン— このプラグインは MATLAB と Jenkins を統合し、MATLAB とSimulink を呼び出すための Jenkins インターフェイスを提供します。
2. 新規アイテムを選択し、MBDExampleUsingGitAndJenkins という新しい FreeStyle プロジェクトを作成します。
3. ソース コード管理で Git を有効にし、Jenkins を GitLab リポジトリにポイントして、ビルドするテスト ブランチに入ります。注: ログインまたはパスワードと GitLab API トークンが必要です。

4. GitLab のテスト ブランチにプッシュ リクエストが行われたときにビルドを実行するようにビルド トリガーを構成します。Build Triggers で、Advanced > Secret token の順に選択します。このトークンは、GitLab がビルドをリクエストし、Jenkins で認証するために使用されます。シークレット トークンと GitLab Webhook をメモします。

5. ビルド環境を構成します。Use MATLAB version を選択して、MATLAB ルートを入力します。

6. ビルド ステップを構成します。

Add build step をクリックして、Run MATLAB Command を選びます。コマンド openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecModelAdvisor
を入力して、プロジェクトを開き、モデル アドバイザー チェックを実行します。

もう一度 Add build step をクリックして、Run MATLAB Command を選びます。次のコマンドを入力します。openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecControllerBuild。

Add build ste をクリックして、MATLAB テストを実行を選びます。TAP test results と Cobertura code coverage を選択して、ビルド構成を完了させます。

手順 5: TAP 結果のパブリッシュ

Add post-build action > Publish TAP Results の順にクリックします。TAP テスト結果がパブリッシュされる相対パスを入力します。

このアクションは TAP テスト結果を解析して、TAP Extended Test Resultsが選択されているときに表示できるようにします。出力には、実行されたテスト ケースの概要、結果の概要、 MATLABコンソールからのログが含まれます。

TAP プラグインは最新のテスト実行の結果も収集し、以下に示すようにヘルス ダイアグラムを表示します。図をクリックすると、以前のビルドにアクセスできます。

手順 6: HTML レポートのパブリッシュ

Add post-build action >Publish HTML reports の順にクリックします。HTML レポートがパブリッシュされる相対ルート パスと、そのパスにあるインデックス ページのファイル名を入力します。

パブリッシュする HTML レポートの数だけエントリを追加します。このシナリオには、2 つの Web レポートがあります。モデル アドバイザーの概要とコード生成レポート。これらはMATLAB組み込み関数を使用して作成された標準レポートです。カスタム HTML レポートを追加できます。 

メインの Jenkins ジョブ ページには、すべての HTML レポートの最後のビルドに対応するレポート リンクが表示されます。Publishing オプションで「Always link to last build」チェックボックスをオンにすると、プラグインはビルドのステータスに関係なく、最後のビルドのレポートを公開します。このチェックボックスがオンになっていない場合、プラグインは最後の「成功」ビルドにのみリンクします。 

手順 7: Jenkins でビルドをトリガーするように GitLab を構成する

メイン ブランチで新しいプッシュが発生したときに Jenkins で自動ビルドをトリガーするように GitLab を構成します。これを行うには、Settings > Webhooks の順に移動します。Build Trigger の構成で Jenkins により提供された Webhook URL と Secret token を使用して、Push events を選択します。

注: GitLab が Jenkins のインストールを見つけられるように、URL セクションで localhost の代わりに完全修飾ドメイン名を使用します。。

Test のプルダウンから Push Events を選択して、統合をテストします。GitLab は「フックが正常に実行されました:「HTTP 200」と表示され、Jenkins はビルドを開始します。

手順 8: Jenkins から GitLab への認証の設定

Jenkins ビルド ステータスを GitLab に自動的にパブリッシュするには、Jenkins から GitLab への認証を構成する必要があります。

1. API スコープを選択して、GitLab で個人用アクセス トークンを作成します。

2. トークンをコピーし、Jenkins のシステム構成で GitLab 接続を作成します。
   注: 接続は複数の Jenkins ジョブで再利用でき、ユーザーに少なくとも「メンテナー」権限がある場合はグローバルに構成できます。

手順 9: Jenkins を GitLab パイプラインに統合する

Jenkins を GitLab パイプラインに統合するには、Jenkins で GitLab 接続を構成し、ジョブのステータスを GitLab にパブリッシュする必要があります。

1. Jenkins ジョブの General セクションで GitLab Connection を選択します。

2. ビルド後のアクションを追加して、ビルド ステータスを GitLab にパブリッシュします。
   注: このアクションにはパラメーターがなく、既存の GitLab 接続を使用して GitLab にビルド ステータスをパブリッシュし、各コミットとマージ リクエストの双方向トレーサビリティを作成します。

手順 10: 要件ベースのテスト メトリックの視覚化 (R2020b)

要件ベースの テスト指標により、要件ベースのテスト作業の状態と品質を評価できます。メトリックの結果は、モデル テスト ダッシュボードを使用して視覚化できます。

1. 以下の関数を基に、collectModelTestingResults.m というファイルを作成します。この関数は、メトリック エンジン インフラストラクチャを初期化し、利用可能なすべてのモデル メトリックを収集します。

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 

2. このファイルをプロジェクトとパスに追加します。
3. new collectModelTestingResults function を 2 度呼び出すことで、メトリクスの結果を収集できるように Jenkins を構成します。最初の呼び出しは、 Simulink Test Manager とのメトリック統合を初期化します。2 番目は、エクスポートされたSimulink Test Manager の結果を使用してメトリック結果を収集します。
   1. もう一度 Add build step をクリックして、Run MATLAB Command を選びます。次のコマンドを入力します。 openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
      このビルドステップは Run MATLAB Tests の前に配置します。
   2. もう一度 Add build stepをクリックして、MATLAB コマンドを実行を選びます。コマンドをもう一度入力してください: openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
      このビルドステップをMATLAB テストを実行するの後に配置します。

4. メトリックの結果を派生ディレクトリにアーカイブします。エクスポートされたテスト マネージャーの結果もアーカイブする必要があります。これにより、 MATLABに再度ロードされたときにメトリック結果を完全にナビゲートできるようになります。

Add post-build action をクリックして、Archive the artifacts を選びます。パスを derived/**,matlabTestArtifacts/*.mldatx と入力して、ディレクトリに保存されているすべてのファイルをアーカイブします。

注: テスト マシン以外のマシン上の MATLAB で、これらの結果を表示するには、次の手順を実行します。

• アーカイブされたアーティファクト (派生ディレクトリとテスト結果の MLDATX ファイル) をダウンロードします。
• CI ジョブの実行に使用されたプロジェクトと同じバージョンのローカル コピーを抽出してコピーします。
• MATLAB でプロジェクトを開き、モデル テスト ダッシュボードを起動します。

CI によって生成された結果は、ダッシュボードに表示されます。

Jenkins^® は LF Charities Inc. の登録商標です。