Reactis を使った MBD 検証プロセスの構築 ∼ MBD 採用から現在までの道のり ∼ 日産グループは、モデルベース検証プロ 一般的な Validation 作業は、要求から決められ モデルベース検証ツール Reactis を適用していま 期待値と仕様から求められる結果とを比較して セスにおいて、Reactive Systems.,Inc の開発した す。今回、この適用事例およびその経緯を紹介し ます。 当社の量産車における最初のモデルベース開発 （以下 MBD）適用は、2000 モデルイヤーの Sentra る例題（テストケース）をテスト対象に入力し、 両者が一致するか確認することなので、それ自 体は特に難しい作業ではありません。ここで問 題となるのは、「検証の質」、すなわち網羅性を どうやって向上するか、になります。 制御仕様の源となる要求定義の大半は、その CA (Clean Air) です。このクルマは、世界初の P-Z 制御でやりたいことが記述されているのが普通 alifornia Air Resources Board) により認定されまし ースは「やりたいことができるか？」の観点で EV (Partial Zero Emission Vehicle) として CARB (C た。この事により MBD の推進に一気に弾みがつ きました。次のテーマとなったのが、ソフトウェ アの品質でした。Fig.1 が示すように年々、エンジ ン制御に求められる要求は増えており、制御ソフ トウェアは大規模・複雑化しています。同時に、 開発期間の短縮を求められています。こうした厳 しい環境下でソフトウェアの品質を確保するため には、MBD のメリットを活かす体系化された検証 プロセスの構築や開発支援ツール・教育などの環 境整備が必要なので、これらに取り組みました。 であり、当然のことながら制御仕様やテストケ 作られます。これらは想定の範囲内ですから、 制御仕様は正しく作られており、検証で問題が 検出されることも稀です。問題となるのは、 その対極にある「起きて欲しくないことが起き ないか？」であり、これに対する仕様や検証が 抜け漏れることです。しかも、この想定外の 問題を発見できるチャンスは試作ソフトウェア 完成後になるので対策コストは高くなります。 逆に、「起きてほしくないこと」を完璧に要求 定義できるなら、それに基づいた正しい仕様 設計ができますし、検証自体も単なる確認テス トとなるはずですが、これは極めて理想論で 現実には実行不可能です。このような水面下 に隠れた要求を明らかにして、制御仕様がそれ らを満たすことを確認するために、当社では逆 転の発想をしました。 Simulink® を使った「実行可能な制御仕様書」 はコントローラに実装されるべき制御ロジック MBD 検証プロセス： 制御ソフトウェアの検証は大別すると、制御仕 様が要求を満たしているか（Validation）と、制御 ロジックが制御仕様どおりか (Verification）の二つ に分けられます。Reactis は先の二つのうち、Vali dation に対して適用されています。 http://www.reactive-systems.com Copyright（C） 2013 Reactive Systems,Inc All Rights Reserved そのものであり論理的な曖昧さが排除されてい ます。したがって、この「実行可能な制御仕様 書」から、それ自体を 100% 網羅するテストケ ースを生成し、予め用意したテストケースと比 較すれば要求定義や想定条件の網羅性がチェッ クできます。すなわち、両者が等価であれば、 論理的に「やりたいこと」も「起きて欲しく Reactive Systems,inc Tomorrow’s Software Today® ないこと」も想定されており、そのまま結果を 選定理由： ストケースが追加されているのであれば、それ 自動生成できるツールはいくつかありましたが、 クや要求の再定義をおこなうこととなり、同時 ていました。もちろん、当社の業務プロセスに適 のようにして、「実行可能な制御仕様書」に記載 それらの解決も迅速なので導入しました。また、 性が判断されるのです。また、従来よりも早い でも改善･機能追加要望を提案し改良を依頼して ストが安くなることも見込めます。 では、現在も Reactis を標準ツールとして位置付 当時、Simulink® モデルからテストケースを 確認するだけでよいことになります。逆に、テ らの期待値を再考することで、仕様の再チェッ Reactis のコストパフォーマンスの良さは群を抜い に検証の網羅度も向上することができます。こ 用するためには、いくつかの問題がありましたが、 されたロジックは、全ての可能性に対して妥当 検証工程における更なる効率化を図るため、現在 段階で Validation 作業がおこなえるので修正コ います。この様な経緯により当社の検証プロセス ただし、仕様提示前の短期間で膨大な量のテス けています。 手作業では成り立ちません。そこで、Reactis を Reactis の利点： トケースを再び作成しなくてはならないため、 使った自動化が必須となるのです。 積分要素などの状態量を持つロジックの網羅度を 適合 要求把握 Reactis generates tests attaining 100% MC/DC coverage システム 仕様設計 システム 検証 コンポーネント 仕様設計 単なる静的解析に基づいたテストケース生成は、 検証 上げることが困難です。これに対し、Reactis は半 自動ながら動的解析も設定できるので、手間を掛 けずに 100% に近いテストケースが自動生成でき ます。また、自動生成で未達部分が生じても、手 動でのテストケース作成を支援する強力な UI を備 コンポーネント 検証 コンポーネント 詳細設計 えています。これらのアドバンテージを利用して 短期間で網羅度の高いテストケースを作成するこ とができています。 コード生成 インプリメンテーション Fig.2: 当社の MBD 検証プロセスにおける Reactis の位置付け MBD 検証プロセスの啓蒙： 検証プロセスとルールの定義、開発環境の構 築、担当者のスキルアップ、実施状況のモニター および改善活動をおこないました。中でも新しい ルールを設計者に徹底させるための啓蒙活動に苦 労しました。特に検証プロセスの業務適用当初は、 Reactis を効率的に使用するためのノウハウもあま りなく、従来プロセスと比べて作業量が増えたと 実績： MBD 検証プロセスは、エンジンの VVEL(Variable Valve Event & Lift）システムや、GT-R の過給圧制 御システムをはじめとする、全てのパワートレイン 制御開発に適用されています。また、最近では EV、 ボディ電装系の制御開発での業務適用も進んでいま す。 *MATLAB®/Simulink® は、MathWorks,Inc. の登 録商標です。 思う設計者も少なくありませんでしたが、今日で は、様々なツール改善、ノウハウ等により、効率 良く検証できるようになっています。 http://www.reactive-systems.com Copyright（C） 2013 Reactive Systems,Inc All Rights Reserved Reactive Systems,inc Tomorrow’s Software Today®
© Copyright 2024 Paperzz
