GAIO CLUB

2010年05月13日

モデルベース開発におけるモデルとコードの比較検証と課題

技術情報
MATLAB/Simulinkによる車両制御の設計「モデルベース開発」が次第にさかんになって来ました。最近では、仕様モデルから組込みC言語ソースコードを自動生成するオートコードジェネレータ(ACG)の適用も始まっています。
本特集では、モデルベース開発開発において、制御仕様として作成したMATLAB/Simulinkモデルからマイコンへ実装するコードを生成した場合に必要となる、モデル/コード間の比較検証と、その方法や課題について解説します。

自動車業界の動向

  • 自動車用電子制御ユニットの開発手法として、モデルベースの開発が浸透し始めています。自動車業界では、制御システム開発用ソフトウエアツールとして、「MATLAB/Simulink (R)」(MathWorks 社製)が事実上のデファクトとなっていますが、これを利用しているユーザー会議体「MAAB(MathWorks Automotive Advisory Board)」では、モデルベース開発手法の業界標準の策定を行っています。
  • モデルベース開発におけるモデルとコードの比較検証と課題
日本ではJ-MAAB、北米ではNA-MAAB、欧州ではEU-MAABといったように地域毎の要求をまとめる活動も活発化しています。

J-MAAB の活動は、オープンカンファレンスという場で、自動車メーカやECUメーカ以外に対してもその活動成果がオープンにされています。モデルベース開発で行った事例なども多数発表されるようになってきました。このカンファレンスの中で、自動車のECU が複雑で大規模になってきていることや、開発期間を短縮するためには、モデルを基にした開発の導入が急務となってきていることが発表されています。

自動車制御系を中心に盛んになっているモデルベース開発

現在、制御系機器のほとんどは、マイコンを使った電子制御が行われており、制御対象は複雑化しています。自動車においても、制御対象のほとんどは電子制御化されており、1台の車には多数の制御対象があります。
  • 制御系機器での制御の基本は「フィードバック制御」です。これは、右の図のように、まず制御対象を動かし、制御の目標値に対してどのくらいのズレがあるかをフィードバックして、次の制御量を補正すると言うものです。何度かこの制御ループを実行することで、制御対象が目標値に近づいて行きます。
  • フィードバック制御
フィードバック制御では、制御対象を1つのブラックボックスとして、出力結果を使った制御をします。ここでは、制御対象の内部の詳細なメカニズムがどうなっているかは、考える必要がありません。このため、制御ソフトの設計にとっては、次のような利点があります。

・ソフト設計者が制御対象を厳密に知らなくても制御できる
・制御対象が経年変化などで状態を変えてしまう場合でも、それに追従した制御が可能

自動車の様な多数の制御対象を持つシステムでは、制御対象の内部動作をソフト開発者が全て理解するのは現実には不可能であり、より大きな機能をブロックとして捉え、これをブラックボックスとしたフィードバック制御で、ソフトを設計する方が、より現実的な手法となります。
  • モデルベース開発とは、エンジンなど制御対象の動作を数学演算アルゴリズムやステートマシンなどで表現した「モデル」を作成し、このモデルに対してコントローラを設計することを指します。
  • モデルベース開発とは
コントローラも、システム設計時にはモデルで設計し、MATLAB/Simulinkのシミュレーションでシステム動作を検証した後に、マイコンコードに変換してECUに実装します。

仕様モデル動作とマイコン組込みコード動作の違い

従来、ECUへの組込みコードは、仕様情報(仕様書)を基に技術者がソフトウエアをハンドコードする方法で開発されてきましたが、最近では、仕様モデルから組込みC言語ソースコードを自動生成するオートコードジェネレータ(ACG)の適用も始まっています。

しかしながら、ハンドコードやオートコードにより、モデルからC言語のプログラムを生成する以上、正しくロジックが生成されているかどうか、あるいは演算精度や実行の仕組みが異なる場合には、発生する誤差が許容範囲に入るかどうかを検証する必要があります。
仕様モデル動作とマイコン組込みコード動作の違い

自動車機能安全で要求されるモデル/コードの「Back-to-Back」テスト

  • 2009年7月に、自動車分野での機能安全規格のドラフト「ISO/DIS 26262」が一般公開されました。
  • ISO 26262
ソフトウエアレベルの規格「ISO 26262-6」の中では、組込みソフトウエアの単体レベルでのカバレッジや、機能を設計したモデルと実装する組込みコードの間の比較に関する項目が規定されています。
この中においても、単体レベルでの検証項目の1つに、設計した機能モデルと実装する組込みコードの間の比較検証に関する項目が盛り込まれています。このテストは、「Back-to-Back」テストと呼ばれており、機能がシミュレーション可能なモデルの場合に、そのモデルの実行結果(期待する仕様動作)と、実装するコードの実行結果(ECUでの動作)とが「背中合わせに」一致しているかを比較検証するものです。

モデル/コード間の誤差の要因とは

モデルからコードを開発した場合、様々な要因の動作の違い、誤差が発生する可能性があります。正しく制御ロジックが設計、または自動生成されているかどうか、マイコン実装による制御誤差はどの程度かを確認しておくことが必要となっています。モデルからコードを生成した場合に、含まれる可能性のある誤差の要因には、以下のような物があります。

人が介在した開発でのヒューマンエラーの混入の可能性がある

これは、仕様書やモデルの構造を見ながら、人の手で実装コードが作成された場合や、既存のレガシーコードを基にして、人の手でモデルを作成した場合です。人が介在する以上、ヒューマンエラーを確認する必要があります。

オートコードジェネレータで自動生成されたコードでも、実行環境の違いにより、制御結果にズレが生じる

これは、浮動小数点演算で設計されたモデルから固定小数点演算の実装コードを、オートコードジェネレータで生成した場合などです。固定小数点に変換する際には、小数点位置を決める必要があります。指定した小数点位置を使用した演算において、数値がレンジを超えないかどうかを確認する必要があります。また、小数点演算の丸め誤差の影響を確認する必要もあります。

OS、ドライバ、通信のオーバーヘッドによる遅延などの影響により、制御結果にズレが生じる

これは機能ブロック単体に依存した問題とは異なりますが、1つのモデル動作を複数のタスク、ECUに処理分散した場合に、通信オーバーヘッドなどによる処理遅延の影響を検証するものです。

コンパイラのコード展開特性により、想定したアルゴリズムと異なる結果が生じる

クロスコンパイラの仕様や、コンパイラの最適化オプションの利用などにより、モデル上で想定した演算の順番で、コードが生成されない場合などがあります。

モデル/コードの単体レベル比較検証サンプル

ではここで、1つの制御モデルを使用して、モデルとコードの単体レベルでの動作比較を行ってみます。

サンプルモデルの内容

モデルには簡単なPID制御モデルを使用します。制御対象(プラント)はソレノイドコイルを用いたアクチュエータを想定しており、コントローラにアクチュエータの制御位置を入力すると、コントローラはソレノイドコイルを駆動して、制御位置に動くようにフィードバック制御を行います。
PID制御モデル
今回は、このコントローラに対して、MATLAB/Simulinkのモデルでそのまま実行した結果(仕様となる期待値)と、このコントローラをマイコン(M32R)に実装した場合の動作結果との比較を行います。

MATLAB/Simulinkによる仕様モデル

MATLAB/Simulinkで設計したPID制御モデルは下の図のようになっています。左側の「ref」信号が制御位置入力、「picontroller」がコントローラブロック、右側のブロックがソレノイドコイルによるアクチュエータのモデルです。
また、コントローラの中身は下のようにモデリングされています。これらの制御モデルの信号は、すべて浮動小数点(floating point)精度で作成されています。
モデル図

オートコードジェネレータによりC言語コード化した制御関数

次に、上のコントローラブロックを実マイコンで動作させる場合を考えます。今回は、マイコンにM32Rを使用し、固定小数点演算でコントローラを実現します。下が、dSPACE社のオートコードジェネレータ TagetLink で生成したコードです。
(※ソースコードを短く表示するために、コメントなど一部を省略、調整しています。)

モデルからコードを生成する単位に関しては、通常、1つのSimulink機能ブロックを1つの関数にマッピングして出力する方法が採られます。

各信号は、モデルの信号名「ref」「u」「y」が、コードのグローバル変数「Sa1_ref」「Sa1_u」「Sa1_y」に対応しています。Simulinkの信号線は、浮動小数点で設計されていますが、M32Rへの実装では、ビット幅16ビットの整数変数で、固定小数点で扱われます。ここでの小数点位置のスケーリングは、入力信号「Sa1_ref」「Sa1_y」が LSB: 2^-11、「Sa1_u」が LSB: 2^-6 で行っています。
dSPACE社のオートコードジェネレータ TagetLink で生成したコード

MC-Checkerを使用して モデル/コードを実行

では、上のMATLAB/Simulink仕様モデルと実装コードの動作比較検証を行ってみます。比較実行には、モデル/コードの一致性検証ツール「MC-Checker」を使用します。

仕様モデルはMATLAB/SimulinkでそのままMILS実行

まず、仕様となるモデルの動作をMATLAB/Simulink上でそのまま実行して、結果を取得します。これが仕様上の期待値となります。MC-Checkerを使用すると、評価対象のブロックを指定するだけで、入出力(ref、u、yの各信号)をCSVファイルに出力することが出来ます。コントローラをモデルで実行するため、このシミュレーションは、MILS(Model In the Loop Simulation)と呼ばれています。
MILS(Model In the Loop Simulation)

実装コードはマイコン・コア・シミュレータで ターゲットコード実行

次に、オートコードジェネレータでコード化したオートコードは、ターゲットマイコン(M32R)のクロスコンパイラでコード化し、マイコン・コア・シミュレータ(※)で実行します。MC-Checkerでは、コントローラの部分のモデルを取り外し、代わりにマイコン・コア・シミュレータに接続して、コンパイルされたコードを実行します。

※マイコン・コア・シミュレータ: ターゲットコードを実行することが可能なシミュレータで、マイコン命令レベルで等価な動作が可能。

コントローラをマイコン・コア・シミュレータ(プロセッサモデル)で実行するため、このシミュレーションは、SPILS(Simulator-based Processor In the Loop Simulation)と呼ばれています。

プラントや信号発生器などの他の要素は、Simulinkのものをそのまま使用します。
SPILS(Simulator-based Processor In the Loop Simulation)

結果を比較検証

では、モデル実行(MILS)とコード実行(SILS)により出力されたCSVファイルを比較してみます。下の図は、右がモデル実行(MILS)、左がターゲットコード実行(SILS)による、制御されたアクチュエータの位置(y)を示しています。グラフからはほとんど違いが分かりませんが、数値では、確かに両者の結果が異なっています。
MILSとSILS
では、波形の一部を拡大表示して比較してみます。下の図は、この両者を重ねて表示し、上の波形の立ち上がり部分の誤差を比較した物です。制御信号は矩形波であるため、立ち上がり部分急峻に変化するため、この部分の誤差が多くなっています。この誤差の要因は、浮動小数点演算のモデルを固定小数点のコードに変換して実行したために起こる、演算精度の違いによる物です。下図では、MC-Checkerの誤差許容範囲表示機能を使用して、出力値「y」の誤差が0.2%以上ある部分を、薄いブルーで表示しています。

このような誤差が、システムの制御に問題ない範囲であることを確認することが必要です。
誤差許容範囲表示機能

モデル/コード比較検証に使用するテストケース

モデル/コードの比較検証を行う場合、1つの大きな課題があります。本稿のサンプルでは特に触れていませんが、テストに使用する入力データ(信号)に、何を使用するかという点です。

テストの網羅性の観点で考えると、モデルをテストする場合であれば、モデルの機能や特性を網羅してテスト出来る入力信号が必要になります。入力信号のレンジや精度などの網羅性の他に、時間的な応答特性、過渡特性を考慮する必要があります。
  • 本稿のソレノイドコイルによるアクチュエータの場合であれば、サンプルで使用した矩形波の様な急峻な立ち上がり信号に対しては、アクチュエータが追従しきれず、大きなフィードバック制御が行われるため、固定小数点のマイコン演算では制御結果の誤差が大きくなります。しかし、もしも緩やかなサイン波のような信号を入力した場合は、アクチュエータが十分に追従し大きなフィードバック制御が起こらないため、固定小数点のマイコン演算でも誤差は問題とならないかも知れません。
  • モデル/コード比較検証に使用するテストケース
このことより、コード化することにより発生する誤差や問題点を検出するためには、設計したモデルの特性を網羅してテスト可能なテスト信号を与えることが必要となります。

この様なテストケースを生成するツールは、「モデルベーステスト(MBT)」ツールと呼ばれており、定理証明、モデル検査、制約論理プログラミングなど、様々なアプローチを用いてテストケース生成を自動化する試みが行われています。

モデル/コードの単体レベルでの比較検証を自動化するツール MC-Checker

この様に、モデルベース開発において、ソフトウエアの単体レベルでの検証として、モデル/コードの動作比較検証を行うことが要求されています。しかしながら、製品を構成するブロックの数は膨大であるため、SimulinkとICEを使用して、これを手作業で行うのは現実的でありません。

そこで、ガイオは、本稿のサンプルの実行で使用した「MC-Checker」を提案しています。このツールは、サンプルで説明したモデル/コードの比較検証を効率よく、短時間で行うための機能を搭載しています。また、コードの実行環境にはマイコン・コア・シミュレータを使用しており、自動車機能安全「ISO 26262」で要求される、ターゲットコードを使用しての動作比較検証が可能になっています。
モデルベース開発

人気のコラム

最新のコラム