GC ONLINE Vol.07 :
(株)デンソー シャシーコントロール機器部様の
「カバレッジマスターwinAMS」を使用した単体テスト自動化適用事例

今までどのような開発に携わってこられたか、自己紹介を含めて教えてください。

牧野様：
従来から、機能安全マイコンの開発を軸足として、マイコン周りの開発環境に携わっています。その中の１つとして、マイコンシミュレータを使ったカバレッジ、MC/DCの計測を行う環境や、マイコンの内部値をロギングしてEPS(電動パワーステアリング)に適合させたりするようなツールを開発してきました。

現在では、特に冗長系機能安全に関連するマイコン技術企画として、機能安全要求レベルが最も高いASIL-Dに関する安全コンセプトの構築、検証等に関わっています。

渡辺様：
2005年ごろから、EPSの部署で仕事をしており、もう13年になります。最初はEPS-ECUの制御ソフトウエア開発を担当していましたが、当時周りのエンジニアの開発作業を見ていると、単体テストを始め、かなりの部分が手作業で行われていました。この部分を効率化できないかと思い、自分の興味もあり、ある時、プログラミングにより自動化を行うツールを作って提案しました。すると、周りのエンジニアに喜ばれました。これが切っ掛けとなり、単体テストの自動化に関する業務に関わるようになりました。

牧野様は、機能安全にかかわるマイコンの開発に携わってこられたとお伺いしました。そこで、機能安全マイコンとはどの様なものかを教えていただけませんか？

牧野様：
まず、機能安全マイコンのヒストリーについて紹介したいと思います。私は、1990年ごろから「ABS（アンチロック・ブレーキシステム）」のソフトウエアの開発を、カーメーカーと一緒に始めました。その頃から「セーフティーシステム」に関わるようになっていました。2002年ごろにEPSの部署に異動し、電動パワステのソフトウエア開発を行いました。その経験を活かし、2004年ごろから「機能安全マイコン」の企画・開発を、マイコンメーカーと一緒に行うようになりました。

「機能安全マイコン」とは、自動車の中でも「走る、曲がる、止まる」と言う、安全性が特に求められる重要な部分の制御を行うマイコンのことです。

その当時は、自動車向けの機能安全規格ISO26262はありませんでしたので、メタ規格であるIEC61508が機能安全の要求事項でした。当時のマイコンは、シングルコアが主流でしたが、ロックステップ型のデュアルマイコンでのセーフティ構成に関する議論が始まり、このアーキテクチャをどのようにするかについて、深く関わってきました。

当時は、故障が起きたらシステムを止める「フェール・セーフ」としての考え方が主流でしたが、2010年ごろから、故障しても制御を続ける「フェール・オペレーショナル」の考え方が主流になっています。デンソーでも、1系統から2系統への設計、いわゆる「冗長機能安全」への流れになっており、そのために、マルチコアマイコンあるいは独立２マイコンが新たなセーフティの要件となっています。

牧野様：
車載ソフトには、様々な新しい要求が発生していますが、これを実現する上で、従来のソフトウエア資産を継承していかなければ、開発の現場には受け入れられないという現実があります。大きな考え方の1つは、新しい要求に対し、ソフトに負担をかけずにハードウエアで機能を実現することです。例えば、安全設計の機能に「スタック・セパレーション」や「メモリ・プロテクション」があります。これらの機能をソフトウエアでゴリゴリと書いていたのでは、設計が困難であり、最終的なパフォーマンスも出ないと言う課題に当たってしまいます。

そこで、ハードウエアと連携して機能を実現する必要があります。「フォルト・トレラント・タイム」すなわち故障が起きてからの時間要求が短いものはハードウエアで、そうでないものはソフトウエアで実現する様なバランスを取ることが重要な設計技術の一つとなります。技術者にとっては面白くやりがいのある部分だと思います。

現在、EPSの開発部隊を始め、他部署でもカバレッジマスターを標準的にご利用いただいておりますが、採用の切っ掛けについて教えていただけますか？

牧野様：
機能安全へのソフトウエア対応に関しては、ソフトウエアの機能要素ごとに危険度のレベル付けを行う分析手法である「ソフトウエア・クリティカリティ・アナリシス」や、ソフトウエアの構造の網羅性に着目した分析手法である「ストラクチャル・カバレッジ」の適用がなされてきました。特にコードカバレッジに関しては、NASAが提案していた「MC/DC」の計測を、自社の制御ソフトに適用できないかと考えるようになりました。

当時、組み込みマイコンとペリフェラルのシミュレータを使用したシステムを検討していました。ですが、MC/DCの計測は実行環境のみでは実現できず、元のソースコードに手を入れて、条件文の途中の実行結果を取り出す仕組みが必要となります。これが可能な方法がないかを模索していました。

その時、とある展示会で偶然「カバレッジマスター」と出会い、マイコンの実機コードでカバレッジを測るツールであることを知り、採用を検討しました。2007年ごろのことです。その後、MC/DCが計測できるように機能改善されたため、内製ツールへの取り込みを行いました。初期の内製ツールでは、カバレッジマスターのISSと半導体メーカー製のISSの両方を動作させ、両者の実行結果が一致していることを確認していましたが、一致性が十分に確認できたため、現在ではカバレッジマスターのみを使用した本格運用に至っています。

内製ツールについて、どの様な方法で単体テストの自動化を実現しているのか教えていただけませんか？

渡辺様：
私は、デンソー内製の単体テスト自動実行ツールの開発を行っています。ツール名は「D-SPIDER（ディー・スパイダー）」と言います。バグをクモの巣で捉えるイメージで「スパイダー」と名付けました。Dは「デンソー」のことです。システムの仕組みをご紹介します。

まず、担当者は、デンソーで決めた独自の単体テストデータフォーマットに、テスト対象関数名、テスト設計した入出力変数と入力値、期待値を記載します。色付けや見易さを優先して、CSVファイルではなく、フォーマットの柔軟性が高いエクセルのXLSXファイルを使っています。

ユーザーは、作成したエクセルファイルをD-SPIDERのUIで指定して、実行ボタンを押すだけで済む様にしてあります。D-SPIDERは、CasePlayer2を呼び出し、指定された関数のソースコードを解析して、MC/DC計測用の埋め込みコードを生成します。さらに、クロスコンパイラを呼び出し、MC/DC計測用の埋め込みコードをコンパイルして、カバレッジマスターで実行可能なオブジェクトコードを生成します。

埋め込みコードをコンパイルするためには、埋め込みコード用に元のmakefileを修正する必要があるのですが、この仕組みも自動化しています。

この様にしてD-SPIDERは、単体テスト実行用のオブジェクトコードなどの環境を自動生成したのち、エクセルに記載されたテストケースをカバレッジマスター用のCSVへ変換し、カバレッジマスターを呼び出し、単体テストの実行とMC/DC計測を行います。

カバレッジマスターのCSVの実行結果は、D-SPIDERでデンソーフォーマットのエクセルファイルへ書き戻されます。この中には、テストケース毎の期待値との一致、不一致の結果、MC/DCの網羅率の結果や、カバレッジレポートも含まれています。エクセルファイルの色付けを利用して、例えば期待値と結果が異なっていたテストケースを赤く塗るなど、後からテスト結果を確認しやすいように工夫しています。

ユーザーから見ると、ボタンを押すだけで、所定のマイコンシミュレータでの単体テストが自動実行され、実行結果と期待値判定、MC/DCのパーセンテージを含めた答えが返ってくるような、非常に簡単なインタフェースで使用できます。D-SPIDERは、サーバー運用ではなく、各テスト担当者のクライアントPCにインストールされ、単体テストを駆動するツールとして動作しています。

テストケースはどのようにして作成するのですか？

テストケースの作成は、各テスト担当者が、関数仕様に基づいて自分で作成します。ここを自動化することは行ってません。デンソーの単体テストは、D-SPIDERのような自動化の仕組みができる前から、長い歴史を持っており、テストデータの設計に関しては、同じ方法を継続して運用しています。

D-SPIDERの前には、カバレッジマスター以外のマイコンシミュレータを使っていたこともありますが、ツールの仕組みが変わっても、テスト担当者は、同じテスト設計方法を継続して使えるようにしています。マイコンが変更された場合でも同様です。そのため、テストケースのファイルは、関数仕様に基づいて作成する方法で、継続して同じものを運用できる様にもしています。

単体テストの自動化を可能にしたことで、どの様なメリットがあったのか、教えていただけますか？

渡辺様：
ソースコードが変更された場合には、同じテストケースをD-SPIDERに掛けて再テストをします。D-SPIDERでのテストは、ボタンを押すだけですべての作業を自動で実行しますので、再テストの工数は最小限で済みます。テストケースを資産化してゆくことで、エンジニアに負担をかけずにソースコード変更時のデグレードをチェックするテストを毎回行えています。

牧野様：
D-SPIDERは、単体テストの準備、実行、結果の判断など、テスト担当者が行うすべての作業を統合化しています。少し前までは、このツールの呼称がなく、ツールを説明するために、「ユーザーの環境に合わせて単体テストの準備から実行評価までを自動で行うツール」のような長い説明文を付けなければなりませんでした。そこで、覚えやすく、クモの巣でバグを捕まえるというイメージで「D-SPIDER」と名付けました。

2012年ごろにEPS向けのツールとして完成しましたが、徐々に社内で浸透するようになりました。現在ではEPS以外の部署にも広がり、今年度は6部署、来年度には12部署まで広げる計画が進んでいます。

では最後に、弊社ガイオに対するリクエストがあればいただけませんでしょうか？

渡辺様：
D-SPIDERを使用している社内ユーザーから、カバレッジマスターに関する質問を受けることがあります。カバレッジマスターは、色々なマイコンに対応できるため、多くの部署に適応できます。その反面、多くのパラメータをもっているため、操作が難しいことがあります。例えば、決められた機能を使いたいだけのユーザー向けには、「簡単UIモード」のようなものがあると、非常に使いやすくなります。

また、表示のカスタマイズの機能があると便利です。例えば、簡単に使いたいユーザーに対しては、限られたメニューやボタンのみが表示できるようになると、より浸透しやすくなると思います。

ガイオさんのツールを採用してから、ユーザーサポートが充実していることもあり、特に不満を持っている点はありません。質問に対する反応が早く、安心して仕事ができています。

牧野様：
単体テストを行うためには、最初のインプットとして、テストケースを考えなければなりません。ここはエンジニアが知恵を絞って汗をかくところなのですが、まだまだ負担が大きいことが課題です。そこで、テストケースの作成をお手伝いする様な自動生成機能を取り入れたいと思っています。例えば、テストケースの観点である変数の最大値、最小値、境界条件±１、同値分割の中間値など、仕様に基づいたテストケースの作成支援を行う機能を提案いただければと思います。カバレッジマスターにもテスト分析機能やエディタがありますが、これをより進めた支援機能を望んでいます。

次にガバナンスの視点からの要望ですが、ツール、開発工程は標準化が進んでゆきます。これを行うには、ツールメーカー間でのツールチェーンが充実することが条件となります。ツールメーカー間のインタフェース部分に踏み込めるように、各メーカーさんで標準化をしていただくと、新しいツールの展開がより早くできるようになると思っています。

また、D-SPIDERは、ガイオさんのツールと連携して機能を実現しています。過去に一度、カバレッジマスターのバージョンアップによって、D-SPIDERのシステムが動かなくなるトラブルがありました。こういった事態を防ぐために、インタフェースの変更点などの情報を、バージョンアップ前の早い段階でいただきたいと思います。