本コンテンツにおけるMBD

本コンテンツ(MBD学習)ではMBD(※)の中でも特にMathWorks社のMATLAB/SimulinkというMBDツールを用いた組込みソフトウェアの開発をMBDとして取り扱い、学習していきます。

_{※ 一般的にMBD(モデルベース開発: Model Based Development)とは物事を抽象化した「モデル」を構築し、そのモデルに基づいて行う開発全般を指します。特に要求やアーキテクチャの表現は関心ごとに応じたビューで表現可能なUMLやSysMLといったモデリング言語を用いて行われることがあります。}

MBDの意義・効能

ソフトウェアの「開発規模の増加」と「開発ライフサイクルの短縮」を背景として、昨今の組込みソフトウェアの開発(特に自動車制御用ソフトウェアの開発)においてMBDが広く用いられています。 MBDでは以下のようなSimulinkモデルによる可読性の高い表現とシミュレーションを用いた検証によって短い期間で多くの機能の開発を実現しています。

MBD導入の目的は、制御装置（コントローラ）と制御対象（センサ、アクチュエータ）の振る舞いをモデル化することでシミュレーションを可能にし、生産性や成果物品質の向上を実現することにあります。

プラントモデルには、センサやアクチュエータだけでなく、車両や関連する他システムなども含まれます。

MBDの開発手法

MBDの活用範囲は幅広く、解決したい課題や開発対象（製品）の特性、開発スタイルなどによって、どの手法を導入するか見極める必要があります。

1. 狭義のMBD

   「狭義のMBD」という呼称が一般的に用いられているわけではなく、他手法と区別するための本コンテンツでの呼称です。

   コントローラの制御ソフトウェアをモデル化して、机上シミュレーションで動作確認し、モデルから自動コード生成を行います。
   センサからの入力値に対し、一意にアクチュエータ指示値が決まる場合は、これだけでも十分にMBD導入効果が得られます。

IPA開発プロセスでの、ソフトウェア詳細設計の出力成果物は以下の2つです。

これらのうち、MBD導入により大きく変わるのは、「ソフトウェア詳細設計書」となります。
会社により呼称は様々ですが、組込みソフトウェアの場合「制御仕様書」と呼ばれることが多く、Wordなどで作成されていました。

これに対し、MBD導入時はこの成果物がSimulinkモデルに置き換わります。

Simulinkモデルはよく「動く仕様書」と言われていました。

実際には「ソフトウェア詳細設計書」の記載内容をモデルだけで表現するのは難しく、モデルに加え補足文書を作成することもあります。

MBDを導入すると、モデルから自動でソースコードを生成できるようになります。
つまり、従来はソフトウェア詳細設計書（制御仕様書）を入力としてコーディング（プログラミング）していた作業が不要になります。

モデルから自動でコード生成することを「自動コード生成」「オートコード」「ACG (Auto Code Generation)」、対して人がコードを書くことを「ハンドコード」と呼び分けることがあります。

ソフトウェアの全てをモデルで記述することは少なく、ハンドコードする部分も少なからず残ります。
一般に、抽象度の高いアプリケーション部分にMBDを導入し、抽象度の低い（よりハードウェアに近い）部分は従来通りハンドコードとすることが多くなります。

自動コード生成の課題

もちろん、MBDを導入＝実装コストゼロ、という単純な話ではなく、いくつか乗り越えるべき課題があります。

コード生成環境の構築コスト

コード生成ツールを使えば、どのようなモデルでも期待通りのソースコードが生成されるわけではありません。
期待通りのソースコードを生成するためには、コード生成ツールの各種パラメータ調整は当然のことながら、ツールに合わせてモデルの書き方を変えなければならないこともあります。

MBDを導入すると、開発プロセスのテスト（検証）の構成が変わります。
ソフトウェアを実際に動かしてテストする動的なテストと、静的解析などを用いて動かさずにテストする静的テストについてそれぞれ紹介します。

動的テスト

概括的には、従来は実装（ソースコード作成）後に実施していた検証の大部分を、ソフトウエア詳細設計（モデル作成）時に前倒しで実施するようになります。
MBD導入時は、要求に対する設計の正当性・妥当性はモデルで検証し、設計に対する実装の正当性・妥当性はBack-to-backテストによる一致性確認などにより担保するようになります。

IPA開発プロセス各アクティビティでの目的別に、主な利用ツールを紹介します。

全てのツールを記載しているわけではなく、また、記載ツールの利用を推奨するものではありません。

各ツールの概説も記載していますが、正確な情報は各ツールのWebサイトやドキュメントをご覧ください。

各ツールのタイトルは、以下の形式で記載しています。
[S/W（ソフトウェア）またはH/W（ハードウェア）] <ツール名>（開発・販売元）

システム・エンジニアリング・プロセス

SYP1 システム要求定義

要件定義およびモデルとのトレーサビリティ確保

[S/W] Simulink Requirements（MathWorks社）

モデルの要素（ブロックなど）と要件を関連付ける。※要件に限らず、設計やコード、テストなども対象。
要件はモデル内に定義することもできるが、モデル外（Microsoft OfficeやDOORSなど）で定義された要件とも関連付け可能。

MATALB R2017aまでは、Simulink Verification and Validationの一部。

Simulinkモデルはデータフロー図です。

制御工学などを学び、ブロック線図の読み書きに慣れている人は、あまり違和感なくSimulinkモデルを読み書きできるでしょう。

一方、C言語のように多くのプログラミング言語は、データフローではなくコントロールフロー(処理の流れ)を記述します。

このため、プログラマーがモデラーに転向(ジョブチェンジ)する際は、モデルがデータフロー図であることに最初は戸惑うかもしれません。

本コンテンツの狙い と 扱う題材

本コンテンツでは、プログラミング経験のある人が、円滑にモデラーとなれるように
以下の単純な処理を題材に、データフローと処理フローの違いについて記載します。

• 題材
  • 変数a(長さ10の配列)の算術平均値と変数bの和を、変数cに代入
  • ただし、変数aの算術平均値が負の場合は、変数cに0を代入

C言語プログラムでは

C言語をはじめ、多くのプログラミング言語は手続き型であり、制御構文(順次、分岐、反復)の組み合わせで実装していきます。

この結果、プログラム(コード)には「処理の流れ」が記述されます。

フローチャートは、処理をアクティビティで、制御構文をシーケンスフローで可視化したものと言えます。

本コンテンツでは、Simulink モデル、特に制御系のコントローラ向けの Simulink モデルの開発初級者が最初に押さえておくべき Simulink ブロックを紹介します。

本篇では、Simulink が提供するブロックの概要について述べ、以降で紹介する Simulink ブロックを列挙します。

Simulink が提供するブロック

Simulink では、プログラムをブロック線図モデルとして構築します。
つまり、様々な機能を持つブロックをグラフィカルに貼り付け、つなぎ合わせることでモデル=プログラムを作成します。

Simulink は優に 200 を超えるブロックを標準で提供しています。
提供されるブロックの種類も、四則演算、比較演算、論理演算といったプリミティブなものから、伝達関数、PIDコントローラ、アナログ・デジタルフィルタといった高機能なものまで、非常に豊富です。

そのような豊富なブロックの中から自身の用途に合致したブロックを見つけ出すのは大変と思われるかも知れませんが、実際にはコントローラ(制御器)用のモデル、それもオートコードを前提としたモデルを作成する際に使用されるブロックの種類はさほど多くはありません。

本コンテンツでは、コントローラ用のモデルを作成する、あるいは読む上で、最低限知っておくべきブロックを紹介します。

本篇では、モデルの構造およびデータ(信号)の生成・保持に関連する下記ブロックについて説明します。

・Subsystem
・Inport
・Outport
・Constant
・Unit Delay

 

Subsystem

Subsystem は複数のブロックをグルーピングして１つの機能単位を作るためのブロックです。
C 言語における "関数" を作るためのブロックと捉えるとよいでしょう。¹

モデルは通常多数のブロックで構成されるため、それらのブロック群を機能的なまとまりに分割するのに Subsystem は使用されます。
また、Subsystem はネストさせることができるため、モデルを Subsystem の階層構造として整理するのにも役立ちます。

アイコン	使用例

Subsystem を作成する際に留意すべき事項としては、"名前"が挙げられます。
C 言語のプログラミングにおいて「関数名」が重視されるのと同様、Subsystem にもその機能・役割が伝わりやすい名前を設定することが、モデルの可読性を向上する上では重要です。

＜続きを見る＞

本篇では、モデルのデータ(信号)に対する演算、例えば算術演算、論理演算、関係(比較)演算に関連する下記ブロックについて説明します。

・Add
・Product
・Relational Operator
・Logical Operator
・Switch

 

Add

Add は入力信号を加算あるいは減算するブロックです。

アイコン	使用例

上表のアイコンに示した通り、Simulink のブロックライブラリには Add 以外に Subtract や Sum というブロックも存在しますが、実際には全て同じ種類のブロックです(どれもブロック種別は Sum になります)。

ブロックパラメータの「アイコン形状」を"四角形"に設定すると Add や Subtract の見た目に、また"円形"に設定すると Sum の見た目になります。
但し、"円形"での表示は、フィードバックループの場合以外は推奨されていません。¹
(個人的には、フィードバックループも含めて"四角形"にした方が統一感も出て、可読性も高くなると思います)

＜続きを見る＞

本篇では、Lookup Table(ルックアップテーブル)を紹介します。

Lookup Table(n-D)

Lookup Table は、入力値に対応する出力値を、予め定義しておいた「表」に基づいて演算するブロックです。
入力値と出力値の関係が単純な計算式では近似できない(精度がとれない)場合や、その関係に適合(調整)の余地を残しておきたい場合などに利用されます。

１つの入力に対応して１つの出力を返すものを 1-D の Lookup Table、２つの入力に対応して 1 つの出力を返すものを 2-D の Lookup Table と呼びます。
(前者をテーブル演算、後者をマップ演算と呼ぶこともあります)

アイコン	使用例 (1-D)

 

1-D Lookup Table

1-D の Lookup Table の使用方法を説明します。
1-D の Lookup Table では、ブロックプロパティで下記のような「表」を設定します。

＜続きを見る＞

本コンテンツでは、Simulink モデル内を流れるデータ=信号、特に複数の信号で合成されるベクトル信号とバス信号について説明します。

信号の種類

Simulink モデルでは、配線されたブロック間を流れるデータのことを信号と呼びます。
信号の種類は、以下の3種類に大別できます。

本コンテンツでは、Simulink のシミュレーションデータの可視化機能について説明します。
シミュレーションデータを可視化するにはどのような方法があるか、またそれらをどのように使い分けると良いかについて説明します。

可視化方法の種類と特徴

開発した制御ロジックが自分の意図通りに動作しているかを視覚的に確認できる、つまりシミュレーション結果の可視化機能は、Simulink の重要な機能の一つです。
Simulink では、シミュレーションの実行中あるいは実行後に、モデル内を流れる/流れていた信号(データ)の値を可視化するための機能が豊富に提供されています。
標準的な機能だけでも、以下のような可視化方法が挙げられます。

• Scope ブロック

• Display ブロック

• 値ラベル

• Floating Scope ブロック

• ……

本コンテンツでは、前回紹介した Simulink の可視化機能の使い方、特に可視化を開始するまでの設定方法について説明します。

Simulink はバージョンを重ねるごとに、機能面でも UI 面でも様々な改善が図られています。
そのため、それまで使っていたメニューが見当たらない、あるいは別の名前に置き換わっている、また別の操作方法に変更されている、ということがよく起こります。

そういった事情を踏まえ、本コンテンツでは、各可視化機能のバージョン毎の操作方法の差異について紹介します。
対象とする MATLAB/Simulink のバージョンは R2015a から R2020b までとします。

Scope ブロック

特にバージョン間での差異はありません。
Scope ブロックを任意のダイアグラム上に配置し、可視化対象とする信号線を Scope ブロックに接続します。

Display ブロック

特にバージョン間での差異はありません。
Display ブロックを任意のダイアグラム上に配置し、可視化対象とする信号線を Display ブロックに接続します。

本コンテンツでは、Stateflow の機能を簡単に紹介し、Simulink との使い分けのポイントについて説明します。

Stateflow の主要機能

Stateflow は非常に豊富な機能を持つツールですが、その主要機能は以下の２つになります。

1. ステートチャートの作成とシミュレーション

2. フローチャートの作成とシミュレーション

    

ステートチャートの作成とシミュレーション

"モード"あるいは"状態"に応じて処理を切り替えたい、例えば出力する値の算出方法を切り替えたい場合に、

• モードや状態がどのように遷移するか

• 各モードや状態でどのように値を算出するか

といった内容をステートチャート(状態遷移図)として記述できます。また、そのシミュレーションが可能です。

開始ボタンと停止ボタンしかもたない単純なストップウォッチを例としたステートチャートの実装例を以下に示します。

ここからは、いくつかのコンテンツに渡って、チュートリアル形式で Stateflow チャートの作成方法やデバッグの方法について説明していきます。

構成

本チュートリアルの構成を以下に示します。

本コンテンツでは、チュートリアルを通じて作成していくモデルとその「お題」について説明します。

お題

下記のような機能を持った「扇風機」を題材とします。

Stateflow チャートの作成方法の解説に先立ち、本コンテンツでは Stateflow チャートを配置することになる Simulink モデルの作成方法について説明します。

モデル作成・編集用の画面 (エディタ)

以降では、Simulink エディタや Stateflow エディタを使用して、モデルを作成していきます。
本節では、以降の解説で登場する Simulink および Stateflow モデルのエディタ画面の構成要素の名称を紹介しておきます。

Simulink エディタ

Simulink モデルを作成するための画面です。
Simulink モデルを新規作成、または既存のモデルを開いたときに表示されます。
この画面上で、Simulink ブロックの配置や結線を行うことで、Simulink モデルの作成を行います。

Stateflow モデルは Chart ブロックの中で作成していきます。
本コンテンツでは、Chart ブロックを新規に追加する方法と、Chart ブロックに対するプロパティ設定の方法を説明します。

チャートの新規追加

Chart ブロックを 先に作成したSimulinkモデル上に新しく追加します。

[例] Chartブロック「FanConteroller」を追加する

1. 先に作成した Simulink モデルファイル(fan_controller.slx)を開きます

2. ツールストリップ上の　（ライブラリブラウザ）を選択します。
   または、MATLAB のコマンドウィンドウ上で “simulink” と入力します

3. 開いたライブラリブラウザ上で、Stateflow カテゴリ中の Chart ブロックを選択(クリック)します

   

本コンテンツでは、以下の定義方法について説明します。

• Stateflow チャートへの入力データの定義
  

• Stateflow チャート内でローカルに使用するローカル変数の定義

• Stateflow チャートからの出力データの定義

• Stateflow チャートから参照する Simulink モデル側の定数の定義 (パラメータ定義)

入力データの新規追加

Simulink モデルから Stateflow チャートに入力されるデータ（信号や定数）を定義します。
本チュートリアルにおける Stateflow チャートへの入力データは以下の通りです。

本コンテンツでは、状態を表現するステートの定義方法について説明します。

ステートの新規追加

Stateflow チャート内に新しいステートを追加します。

[例] 「PowerOff」ステートを定義する

1. Chart ブロックをダブルクリックして開きます（Stateflow エディタを開きます）

2. Stateflowエディタのオブジェクトパレットから(ステート)を選択します

3. そのままマウスポインタをダイアグラム上に移動させ、適当な場所でクリックします

4. ステート内にカーソルが表示されていることを確認し、ステート名 PowerOff を入力します
   (ステート に ? ラベルが表示されているときには、そこをクリックするとカーソルが表示されます）

本コンテンツでは、ステートの変化・移り変わりを表現する遷移の定義方法について説明します。

デフォルト遷移

デフォルト遷移は最初に遷移する状態を示します。

[例] Chart が最初にアクティブになったとき、PowerOffステートに遷移させる

1. Chart ブロックをダブルクリックして開きます（Stateflow エディタを開きます）

2. Stateflow エディタのオブジェクトパレットから　(デフォルト遷移)を選択します

3. そのままマウスポインタをダイアグラム上に移動し、PowerOffステートの境界線上の適当な場所をクリックします

4. 開始擬似状態（●）とPowerOffステート間に遷移線が引かれたことを確認します

本コンテンツでは、ステートや遷移時の振舞いを規定するアクションの定義方法について説明します。

ステートアクションの定義

ステートアクションには以下の種類が存在します。

• entry アクション ： 対象となるステートに遷移したときに実行されるアクション

• during アクション ： 対象となるステートに留まる間、継続して実行されるアクション

• exit アクション ： 対象となるステートから離れるときに実行されるアクション

（※）実際には、on イベントアクションや bind アクションなども存在しますが、本チュートリアルでは扱いません。

ここでは、entry アクションと during アクションの定義方法について説明します。
また、アクションが複雑な場合には、関数を定義してそれを呼び出すこともできますが、その方法についても説明します。
(先に関数定義の方法を説明し、その後でアクション定義の方法について説明します)

本コンテンツでは、ここまでは扱わなかった以下の３つの内容について説明します。

• ヒストリジャンクションの使用方法

• ステートや遷移の評価・実行順序の制御

• グループ化とサブチャート化

   

ヒストリジャンクションの使用方法

今回の扇風機には、以下のような仕様が含まれています。

『運転は前回停止したときに設定されていた風量で開始します。初回は「弱」で開始します。』

上記のような仕様を実現するために、ヒストリジャンクション(履歴ジャンクション)という機構が用意されています。

あるスーパーステート(サブステートをもつステート)にヒストリジャンクションを配置すると、そのスーパーステートを退状して別のステートに移る際、直前にどのサブステートにいたかが記憶されます。そして、再度そのスーパーステートに遷移してきたときに、記憶していた直前のサブステートに遷移させることができます。

Stateflow チャートを含む Simulink モデルのシミュレーションを実行すると、
・ 設計意図通りにステートを遷移するか
・ 特定時点での入力/ローカル/出力データの値が正しいか
などを確認(デバッグ)することができます。

本コンテンツでは、Stateflow チャートをデバッグする方法について説明します。

入力信号の生成

シミュレーションを実行するには、入力信号を生成する必要がありますが、その方法は通常の Simulink モデルをシミュレーションするときと変わりません。
つまり、Simulink の Sources カテゴリのブロックを入力ポートにつなぐ、例えばSignal Builder ブロックで信号を生成する、といった方法が使用できます。

以下では、既にシミュレーションの実行に必要な入力信号は生成できていると仮定します。

シミュレーションの実行

シミュレーションを開始するには、Stateflow エディタのメニュー[シミュレーション]-[実行]を選択します。
または、ツールストリップ上の(実行)でも開始できます。

本チュートリアルでは、扇風機のコントローラモデルの作成を通じて、Stateflow チャートの作成方法やデバッグの方法について解説しました。

本チュートリアルでは、Stateflow が提供する機能のうち、特にステートマシン(状態遷移図)の作成機能にフォーカスしましたが、Stateflow にはそれ以外にもフローチャートの作成機能や真理値表の作成機能など、非常に豊富な機能が備わっています。

本コンテンツにおける設計データとは基本的に以下を指します。

さらに以下の情報が含まれることも想定して記載しています。

データディクショナリを使わない場合は、ベースワークスペースに設計データ（パラメーターなど）を格納してモデルから参照します。

モデルワークスペースを使う選択もありますが、同ワークスペースはバス定義ができないなど制約があるため、本コンテンツでは検討対象としていません。

パラメーターはスクリプトに直接定義し実行することで、ベースワークスペースにMATLAB変数として格納します。

• 単なる数値

  par1 = 1.23;
  par2 = 4;

• データ型を指定した数値

  par1 = single(1.23);
  par2 = int8(4);

• ……

データディクショナリを使う場合、モデルとリンクさせたデータディクショナリに設計データを定義します。

専用機能だけあって、とてもシンプルな構成で設計データの管理を実現できますが、以下のような課題があります。

1. Simulink環境がないと編集できない

2. (使い慣れているExcelなどと比べ) 編集しづらい

3. データ数が増えると表示が遅くなり編集しづらい

また、成果物として別途Excelファイルが必要なことも多いため、以下のような運用も現実的な選択肢となります。

（R2020b時点で）データディクショナリはExcelとのインポート/エクスポートができないため、別途スクリプト等が必要になる。

本コンテンツでは、Simulink でライブラリを作成する方法、またそれを使用する方法について説明します。

ライブラリの作成方法

ライブラリを作成するには、以下の手順を踏む必要があります。

・ 再利用したいブロックをライブラリファイルに配置する
・ 上記のブロックを、ライブラリブラウザーやショートカット(クイック挿入)を使ってモデルへ追加できるように設定する

ライブラリ作成の具体的な方法と、その過程での注意事項について見ていきます。

なお、本コンテンツの内容は R2018b で動作確認しています。

1. ライブラリファイルを作成する

ライブラリブロックを格納するためのライブラリファイルを作成します。
ライブラリファイルは以下の手順で作成できます。

1. Simulink を起動する

2. Simulink スタートページが表示されるので、そこから[空のライブラリ]を選択する¹

Chartに定義した関数はエクスポートすることでモデル全体の共通関数として利用可能になります。

また、複数モデルで関数を共有したい場合は、Chartブロックをライブラリブロックとして作成し、モデルにリンクさせる(モデル上に配置する)ことで実現できます。

ここでは、ライブラリブロックとして作成したChartブロック内の関数を再利用する手順を解説します。

制約

エクスポートするには、引数・戻り値のデータ型や次元などを明確に定義しなければなりません。
つまり、Simulinkブロックで作成するライブラリと異なり、データ型ごとに異なる関数を用意する必要があります。

作成手順 

関数のエクスポート

関数を定義したChartブロックのプロパティで、「チャートレベルの関数をエクスポート」をチェックします。

使われ方に応じて、「エクスポートされた関数をグローバルに可視として扱う」もチェックします。

本コンテンツではブロックにマスクを設定する方法について説明します。また、マスクの便利な使い方についても紹介します。

マスクとは

マスクはブロックの中身・詳細を隠蔽するための仕組みです。

例えば、ライブラリブロックは、利用者にロジックの詳細を晒すことなく(意識させることなく)、必要なパラメータだけ設定すれば動作するブロックとして提供するのが基本ですが、マスクを使用することでそういったことが実現できます。

具体的にはブロックにマスクを設定することで、以下のようなことが可能になります。

• ブロックを独自のアイコンやイメージで表示する
• ブロックをダブルクリックしたときに独自のマスクダイアログを表示する
• マスクダイアログ上でロジックの振舞いを調整するためのパラメータ値を指定/設定する
• ブロック (特にサブシステム) の配下の構造を隠す (明示的に「内部を検索する」を指定したときのみ見えるようにする)

マスクの設定方法

下記のようなライブラリブロックを作成する例を通じて、マスクの設定方法を見ていきます。
MATLAB は R2018b を使用します。

本コンテンツでは、Simulink モデルで可変性を実現する方法について説明します。
可変性を実現する方法としてどのような種類があるか、いずれかを選択するときにどういったことを考慮すれば良いか、などについて説明します。

「可変性の実現」とは

聞き慣れない言葉かも知れませんが、要は「複数の選択肢を切り替える必要があるときに、どのような仕組みで切り替えるか」ということです。
"可変性"という用語が使用されるときに、それと合わせて登場する用語・概念を紹介しておきます。

本コンテンツでは、以下による可変性の実現方法について説明します。

• Switch ブロックまたは Multiport Switch ブロックの使用

• If ブロックまたは Switch Case ブロックの使用

Switch または Multiport Switch を用いた可変性の実現

Switch ブロックあるいは Multiport Switch ブロックでは、切替の条件を表す値を制御ポートに指定して選択肢の切替を行います。
Simulink モデルにおける可変性の実現方法としては、最も基本的な方法になります。

Switch ブロックや Multiport Switch ブロックの使用方法については改めて説明する必要はないでしょう。
「入力される２つの数を、加算するか、減算するかを切り替える」というケースを例に、それぞれの実現方法を以下に示します。

本コンテンツでは、Variant Subsystem ブロックを用いた可変性の実現方法について説明します。

Variant Subsystem の利用手順

Variant Subsystem ブロックを用いると、「インタフェース」は共通だが「中身(実装)」が異なるモジュール(選択肢)を複数定義し、条件に応じて使用するモジュールを切り替えることができます。
これまでと同様、「入力される２つの数を、加算するか、減算するかを切り替える」というケースを例として、Variant Subsystem ブロックの使い方を見ていきます。

1. 可変点の設計

本ケースでは、２つの入力信号に対して行う「演算」として"加算"と"減算"という選択肢が存在します。
実現したい内容に複数の選択肢が存在する箇所、つまり可変点に Variant Subsystem ブロックを配置します。

モデルの規模がある程度大きくなると、同じ (または似ている) 処理が複数個所で必要になることがあります。
このとき、それぞれ個別にモデリングするより、その処理を部品化して再利用した方が様々な点でメリットがあります。

• モデリング・メンテナンスコストの低減

  毎回モデリングする必要がなくなりますし、変更する際の手間も最低限に抑えられます。

• 検証コストの低減

  検証済みの部品を利用することで、利用箇所ごとの検証が不要になります。

• 解析性の向上

  部品をブラックボックスとして扱い、内部の処理内容を読み解く必要がなくなります。

• コード規模の低減

  モデルからコード生成する際、部品を関数化する設定にすることで、利用箇所が多いほどコードの総行数を低減できます。

C言語プログラミングにおける処理の共通化手段は、基本的に関数となります。(関数形式マクロを使った共通化も可能)

これに対し、モデルでは様々な共通化手段が用意されています。
適切な手段を選択すれば共通化のメリットを享受できる反面、選択を誤ると生産性や品質を低下させかねません。

本コンテンツでは、処理の共通化手段と、それらの手段を選択する際の観点を紹介します。

本コンテンツでは、ベクトルを用いた処理の共通化について紹介します。

共通化の基本

モデルの同一階層において、同じ処理が複数箇所で登場する場合は、信号をベクトル化することで処理を共通化することができます。
ベクトルはC言語における配列に相当し、処理の共通化はC言語での for 文を想像してもらうと分かりやすいと思います。

適用例

ベクトルは同一階層であれば、処理の規模が大きくても問題なく、また他の共通化手段との併用もできるなど、柔軟に用いることができます。
また、ベクトル入力に対応している Add ブロックや Logical Operator ブロック、MinMax ブロックなどと組み合わせることで、モデルが簡潔に表現できます。

本コンテンツでは、Simulink関数を用いた処理の共通化について紹介します。

Simulink関数の定義・利用

Simulink関数は、様々な手段で定義・利用(呼び出し)することができます。

Simulinkのバージョンにより選択可能な手段が異なります。例えばMATLAB Functionブロックから呼び出せるのはR2015b以降です。

本コンテンツでは、モデル参照を用いた処理の共通化について紹介します。

大きなモデルを複数人で並行開発する際、モデルファイルを分割するために、モデル参照を利用していることは多いと思います。
この場合、モデルの参照箇所は1つですが、モデル参照は複数箇所から利用することもできるため、処理の共通化手段としても活用できます。

振る舞いのカスタマイズ

モデル参照は、「モデル引数」という仕組みを使って、利用箇所ごとにモデルで使用するパラメータの値を切り替えることができます。

R2019a以降、「モデル引数」は「インスタンスパラメータ」に呼称が変わっています。

 通常、モデル内で利用するパラメータは、ベースワークスペースやデータディクショナリに定義されたパラメータの値を利用します。

モデル参照の場合、参照箇所ごとに「モデルワークスペース」が確保されており、同ワークスペースのパラメータを優先的に利用させることができます。

本コンテンツでは、Simulink モデルの「保守性」を向上させる方法を紹介します。
具体的には、保守性を低下させる要因 (阻害要因) にはどのような種類があるか、またそれぞれの阻害要因を発見・除去するにはどうすれば良いか、などをカタログ形式で示します。

XILS

MILSやHILSなどの in the Loop Simulation はXILSと総称されます。in the Loop Simulation とは検証対象となる電子制御コントローラに接続される外部環境を仮想的に作成し、外部環境に動作指令や動作条件を与え、そのフィードバックをコントローラに与えることにより、コントローラと仮想的な外部環境とでループを形成し、コントローラの振る舞いをシミュレーションを用いて評価することを指します。

XILSの種類

XILSにはコントローラや外部環境(プラントモデル)が割り当てられる範囲は開発フェーズや環境によっていくつかのシミュレーションモードが存在し、シミュレーションモードによってコントローラ及び外部環境は完全・あるいは部分的に疑似的な要素で構成されます。

• MILS (Model in the Loop Simulation)
• SILS  (Software in the Loop Simulation)
• HILS (Hardware in the Loop Simulation)

シミュレーション検証とプロパティ検証

モデルの検証は主に「シミュレーション検証」と「プロパティ検証」の2種類に分類されます。
シミュレーション検証はモデルを動作させ、その振る舞いをもって検証する手法を指します。
プロパティ検証は上位の要求や仕様とモデルとの間で論理的齟齬がないことを静的に解析、評価する手法を指します。

シミュレーション検証

モデルの検証として最も多く用いられている検証がこのシミュレーション検証です。 シミュレーション検証ではSimulinkモデルにおいてシミュレーションを実行し、その振る舞いから詳細仕様との一致性や要求に対する妥当性を検証します。
詳細仕様との一致性検証は主にサブシステムなどの小さな単位をテスト対象とし、オープンループと呼ばれる手法で検証が実施されます。詳細仕様をもとに正解となる入出力をテストベクタとして作成し、シミュレーションを行ってその一致性を検証します。
また、テスト対象をアプリケーション全体とする場合にはMILS/SILS/HILSの使い分けでも紹介したMILSを用いることが多くなります。テスト対象がアプリケーション全体になると一般的にモデルに対する入出力数が多くなり、全ての入出力を定義することが困難になります。そのためMILSでは外部システムを模擬するプラントモデルを作成し、システムのユーザー操作(または故障の発生など)のみを模した入力を作成した上でシナリオテストを実施することが一般的となります。

コンテンツの概要

ここからは Simulink モデルのサブシステムを対象としたシミュレーションによる検証(サブシステム単体検証)について学習していきます。

本コンテンツではサブシステム単体検証環境の概要と、検証環境構築の際に利用できる方法
( MATLAB / Simulink の機能や Simulink ブロックの使い方) を紹介します。

サブシステム単体検証の概要

サブシステム単体検証では入力パターンと期待値を定義したテストベクタを作成し、テストベクタに定義されている入力パターンを検証対象のサブシステムへ入力し、得られた出力を期待値と比較した上で合否判定を行うために以下のような検証実施環境が必要となります。

詳細は次の項目「テストベクタの定義」に記載していますが、テストベクタには入力パターンや期待値の他にも想定する状況を表現するテストシナリオや、他の成果物とのトレーサビリティに関する情報などを記載するため比較的記述の自由度が高い形式のファイルで保管することが望ましいです。

今後は上図のように検証実施環境の外部で定義されたテストベクタを使用して検証を実施していくことを想定した解説を行います。

コンテンツの概要

本コンテンツでは Simulink でモデルを作成した際に、サブシステムを対象として実施される単体テスト(サブシステム単体シミュレーション)を題材にテストベクタの定義の方法を学習します。

テストベクタに記載すべき情報

単体テストの実施に利用するテストベクタには入力値/期待値を含め、それら以外にもいくつか記載しておきたい情報があります。本項目ではそれらの記載しておきたい情報とその理由を解説します。
今回はそれらのような付加情報を記述しやすいように Excel を用いてテストベクタを定義していきます。

1. テスト対象

テスト対象となるサブシステムを特定するための情報です。対象のサブシステムが実装されているモデルとサブシステムを特定するためのモデル内パスを把握できる記述が必要です。

コンテンツの概要

本コンテンツではサブシステム単体検証環境の構築と検証の実施方法を解説します。
前項目「テストベクタの定義」で作成したテストベクタと、対象のサブシステムををサンプルとして単体検証するための環境構築、検証の実施を行います。

構築する検証環境の概要

今回は「単体検証で利用可能な機能」で紹介したうち、以下のブロックを利用した検証環境の構築を実施していきます。

• テストベクタに定義した入力値/期待値の読み込み
  From Spreadsheet ブロック
  
  
• 期待値とサブシステム出力値との比較
  Assertion ブロック

概念としては以下のようにテストベクタに記述されている入力信号値を検証対象のサブシステムに入力し、サブシステムから出力から出力された信号値とテストベクタに記述されている期待値とを比較し、一致性を判定する検証用モデルを作成します。

このような役割を実行するモデルを作成する際にはテストベクタに記述されている入力信号値と期待値を出力するブロックは1か所にまとめられるので実際のモデル構成は以下のようになります。

本コンテンツでは、テストが十分に行えているかを判断するための指標として用いられる「カバレッジ」について説明します。

別のコンテンツで Simulink モデルのカバレッジ計測方法について説明しますが、そこに登場する用語や概念を理解しておくことが本コンテンツの狙いです。 
実際には Simulink モデルに対しては「モデルカバレッジ」が計測されるのですが、使用される用語や概念は「コードカバレッジ」(プログラムのソースコードに対するカバレッジ) の用語・概念とほぼ同じです。
そのため、本コンテンツではコードカバレッジを対象として、その種類や内容について説明します。

カバレッジとは

カバレッジ(網羅率)とは、プログラムに対するテストを行ったときに、そのテストがプログラム(テスト対象)が辿り得る経路(パス)のうち、どれだけの経路を実行したかを示す割合のことです。
カバレッジはテストの十分性を判断するための指標として用いられます。

カバレッジの種類

カバレッジには代表的な「網羅条件」が存在し、テストがその網羅条件をどれだけ満たしているかによって測定されます。
網羅条件の違いにより、以下のようなカバレッジが存在します。

本コンテンツでは、Simulink モデルに対するカバレッジの測定方法を説明します。
カバレッジ測定ツールとして Simulink Verification and Validation (SLVV) を使用し、測定の手順や測定結果の見方などについて説明します。

モデルカバレッジとは

Simulink では、プログラムをブロック線図モデルとして構築します。
構築したプログラム(モデル)に入力データを与えてテスト(シミュレーション)することができますが、特定のツールを使うと、そのテストがモデル内で通り得る制御パスをどれだけ網羅したか(カバレッジ)を測定できます。モデルに対して測定できるカバレッジをモデルカバレッジと呼びます。
モデルカバレッジを測定することで、用意・実行したテストが十分かどうかの判断を行うことが可能となります。

モデルカバレッジを測定できるツールはいくつか存在しますが、ここでは Simulink Verification and Validation (以降、SLVV と表記) を利用します。
また、MATLAB/Simulink は R2016b を使用します。

本コンテンツでは、Stateflow モデルに対するカバレッジの測定方法を説明します。
Simulink モデルカバレッジの測定方法と同様、MATLAB/Simulink R2016b 上で Simulink Verification and Validation (SLVV) を使用します。
なお、測定手順については Simulink モデルのときと変わらないため、本コンテンツでは測定結果の見方を中心に説明します。

Stateflow モデルに対するカバレッジ計測

早速 SLVV で Stateflow モデルのカバレッジを計測してみましょう。

モデルおよびテストデータの準備

以下のようなモデルおよびテストデータを使用します。

また、シミュレーションのオプションは以下のように設定します。

概要

本コンテンツでは SLDV (Simulink Design Verifier) を用いたカバレッジ (網羅率) の充足方法について解説します。
カバレッジを充足させる目的については以下のようなことが挙げられます。

• デッドコード (到達しないブロック) の検出
• 設計時に想定できなかった入力パターンにおける振る舞い検討

本コンテンツで解説する内容は Simulink のアドオン製品「SLDV (Simulink design verifier)」を用いた内容です。
本コンテンツでは MATLAB R2018b を使用しています。

SLDV (Simulink Design Verifier) を用いたカバレッジ充足のためのテスト生成

SLDV では既存のテストをベースとして、既存のテストでは網羅できないパス・判定を網羅できるようなテスト入力を生成することが出来ます。

以下のテストハーネスとテストベクタを既存のテストのサンプルとして、そのカバレッジの充足方法を解説します。
SLDV を用いたカバレッジの充足には「カバレッジデータを利用する方法」と「入力データを利用する方法」の2つの方法があります。

本コンテンツの狙い

本コンテンツでは主に車載制御用コントローラを対象としたHILSに関する以下の概要を知ることを目的としています。

• HILSとはどのような目的で利用されるものか
• HILSとはどのよな仕組みになっているか
• HILSではどのような検証を実施できるか  

HILSとは

HILS(Hardware in the Loop Simulation)とは検証対象となるコントローラは実機、コントローラに接続される環境は疑似である環境下で実施するシミュレーションのことを指します。
コントローラに対して実環境と同等の接続を提供することでコントローラの実環境下に近しい振る舞いを検証することができます。

実環境よりも早期にコントローラの動作検証を実施でき、実環境では評価が困難なシチュエーションの検証(接続部品故障時の振る舞い検証など)を実施することができます。

本コンテンツでは、Simulinkモデルから組込み用Cコードを生成する手順を紹介します。

動作確認環境

本文書の記載内容は、以下の環境で確認しています。

必要なツールボックス

本コンテンツの記載内容を試すには、以下のツールボックスが必要となります。

• Simulink
• MATLAB Coder
• Simulink Coder
• Embedded Coder

何はともあれコード生成

単純な足し算モデルを作る

MATLABを起動し、以下のようなSimulinkモデルを新規作成します。