GC ONLINE Vol.02 : モデルベース開発におけるモデルとコードの比較検証と課題

自動車業界の動向

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

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

 

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

現在、制御系機器のほとんどは、マイコンを使った電子制御が行われており、制御対象は複雑化しています。自動車においても、制御対象のほとんどは電子制御化されており、１台の車には多数の制御対象があります。

制御系機器での制御の基本は「フィードバック制御」です。これは、右の図のように、まず制御対象を動かし、制御の目標値に対してどのくらいのズレがあるかをフィードバックして、次の制御量を補正すると言うものです。何度かこの制御ループを実行することで、制御対象が目標値に近づいて行きます。

フィードバック制御では、制御対象を１つのブラックボックスとして、出力結果を使った制御をします。ここでは、制御対象の内部の詳細なメカニズムがどうなっているかは、考える必要がありません。このため、制御ソフトの設計にとっては、次のような利点があります。

自動車の様な多数の制御対象を持つシステムでは、制御対象の内部動作をソフト開発者が全て理解するのは現実には不可能であり、より大きな機能をブロックとして捉え、これをブラックボックスとしたフィードバック制御で、ソフトを設計する方が、より現実的な手法となります。

モデルベース開発とは、エンジンなど制御対象の動作を数学演算アルゴリズムやステートマシンなどで表現した「モデル」を作成し、このモデルに対してコントローラを設計することを指します。コントローラも、システム設計時にはモデルで設計し、MATLAB/Simulinkのシミュレーションでシステム動作を検証した後に、マイコンコードに変換してECUに実装します。

 

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

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

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

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

2009年7月に、自動車分野での機能安全規格のドラフト「ISO/DIS-26262」が一般公開されました。ソフトウエアレベルの規格「ISO-26262-6」の中では、組込みソフトウエアの単体レベルでのカバレッジや、機能を設計したモデルと実装する組込みコードの間の比較に関する項目が規定されています。

この中においても、単体レベルでの検証項目の１つに、設計した機能モデルと実装する組込みコードの間の比較検証に関する項目が盛り込まれています。このテストは、「Back-to-Back」テストと呼ばれており、機能がシミュレーション可能なモデルの場合に、そのモデルの実行結果（期待する仕様動作）と、実装するコードの実行結果（ECUでの動作）とが「背中合わせに」一致しているかを比較検証するものです。。

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

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

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

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

サンプルモデルの内容

モデルには簡単なPID制御モデルを使用します。制御対象（プラント）はソレノイドコイルを用いたアクチュエータを想定しており、コントローラにアクチュエータの制御位置を入力すると、コントローラはソレノイドコイルを駆動して、制御位置に動くようにフィードバック制御を行います。

今回は、このコントローラに対して、MATLAB/Simulinkのモデルでそのまま実行した結果（仕様となる期待値）と、このコントローラをマイコン（M32R）に実装した場合の動作結果との比較を行います。

MATLAB/Simulinkによる仕様モデル

MATLAB/Simulinkで設計したPID制御モデルは下の図のようになっています。左側の「ref」信号が制御位置入力、「picontroller」がコントローラブロック、右側のブロックがソレノイドコイルによるアクチュエータのモデルです。

また、コントローラの中身は下のようにモデリングされています。これらの制御モデルの信号は、すべて浮動小数点（floating point）精度で作成されています。

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

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

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

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

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

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

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

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

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

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

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

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

プラントや信号発生器などの他の要素は、Simulinkのものをそのまま使用します。

結果を比較検証

では、モデル実行（MILS）とコード実行（SILS）により出力されたCSVファイルを比較してみます。下の図は、右がモデル実行（MILS）、左がターゲットコード実行（SILS）による、制御されたアクチュエータの位置（y）を示しています。グラフからはほとんど違いが分かりませんが、数値では、確かに両者の結果が異なっています。

では、波形の一部を拡大表示して比較してみます。下の図は、この両者を重ねて表示し、上の波形の立ち上がり部分の誤差を比較した物です。制御信号は矩形波であるため、立ち上がり部分急峻に変化するため、この部分の誤差が多くなっています。この誤差の要因は、浮動小数点演算のモデルを固定小数点のコードに変換して実行したために起こる、演算精度の違いによる物です。下図では、MC-Checkerの誤差許容範囲表示機能を使用して、出力値「y」の誤差が0.2%以上ある部分を、薄いブルーで表示しています。

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

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

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

テストの網羅性の観点で考えると、モデルをテストする場合であれば、モデルの機能や特性を網羅してテスト出来る入力信号が必要になります。入力信号のレンジや精度などの網羅性の他に、時間的な応答特性、過渡特性を考慮する必要があります。

本稿のソレノイドコイルによるアクチュエータの場合であれば、サンプルで使用した矩形波の様な急峻な立ち上がり信号に対しては、アクチュエータが追従しきれず、大きなフィードバック制御が行われるため、固定小数点のマイコン演算では制御結果の誤差が大きくなります。しかし、もしも緩やかなサイン波のような信号を入力した場合は、アクチュエータが十分に追従し大きなフィードバック制御が起こらないため、固定小数点のマイコン演算でも誤差は問題とならないかも知れません。

このことより、コード化することにより発生する誤差や問題点を検出するためには、設計したモデルの特性を網羅してテスト可能なテスト信号を与えることが必要となります。

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

 

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

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

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

製品のお問い合わせは

モデル/コード一致性確認ツール「MC-Checker」、本ページ内容に関するお問い合わせは、ガイオ・テクノロジー営業部（ご購入前の製品についてのお問い合わせ窓口）までお願い致します

 

 

Copyright(c) 2012 GAIO TECHNOLOGY CO., LTD. All Rights Reserved