自 動 車

車載ソフトウェアのテスト自動化支援
ツール

Sig_I
Sig_O_Ref
Sig_O_Res
OK/NGNGOK＊片岡智美・坂松本達治

育子・古戸健Test Automation Support Tool for Automotive Software ─ by Tomomi Kataoka, Ikuko Saka, Ken Furuto and Tatsuji
Matsumoto ─ In recent years, automotive components have become more sophisticated and the electronic control
unit (ECU) has employed more complex large-scale software. As the product scale becomes larger, an increasing
number of tests are required to assure product quality. Even in the case that auto-testing tools are used, test patterns
need to be input manually. This process requires significant amounts of man-hours particularly when the producttypes vary and the test patterns need to be modified for input signal changes. In order to improve the efficiency ofthis product development process, we have developed a tool that converts the simulation patterns used in modelbased design into those for product tests. This tool automatically adjusts the input signals, and thus, successfully
reduces the man-hours by 50% and improves the test quality with common test patterns.
Keywords: software, test method, model based development

1.

緒言

当社では、自動車に搭載される電子制御ユニット（以下、流用開発時の品質確保の効率化について述べる。そこでは、）を開発している。ECU のソフトウェア（以下、ECU の入出力インタフェースの設計変更前と設計変更後でECU※1

車載ソフトウェア）は、全く新規に設計されることは少なテストパターンを共通化する技術に取り組んだ。

く、多くの場合、旧モデルの設計を流用して開発される。

次に、２つめの課題であるモデルベース開発の効率化で設計の流用時には、車載ソフトウェアの品質確保のためのは、前記のテストパターン共通化の技術を応用して、設計テストパターンも基本的に流用する。ところが、車両全体シミュレーション用のテストパターンと ECU 実機テスト設計が見直され複数の車載 ECU への機能分割、接続イン用のテストパターンとの共通化に取り組んだ。

タフェースの変更などが行われることがある。この場合、自動車として提供される機能に変更がなくても個々の ECUには信号入力・出力インタフェースの設計変更が生ずるた
め、ECU ごとにテストパターンの再設計が必要という課題

要件定義

があった。
一方、自動車の高機能化により車載ソフトウェアは大規

基本設計模化・複雑化の傾向にある 。テスト項目数の増大、検証（1）

ス開発では、設計図（モデル）をシミュレーションするこ

ECU実機テスト
詳細設計製

設計品質が向上し、テスト工程でのバグ発見と手戻りの減用いるテストパターンをテスト工程で用いるテストパターンと共通化すれば、開発全体が効率化できる。しかし、モデルとテスト工程（HILS ※ 3）での検証対象である ECU とでは信号入力・出力インタフェースが異なるため、信号入力から出力に至るタイミングも異なり、単純に共通化でき単体テスト

設計シミュレーション（図 1）。この手法により、とで、設計を検証する（MILS ※2）

少という効果がある（3）。さらに、設計シミュレーションでHILS

統合テスト

MILS

モレのリスク増大などの問題解決のため、モデルベース開発手法を自動車業界では導入推進している（2）。モデルベー

総合テスト

作

SILS

MILS

SILS

HILS

ECU部品モデル

モデル

実制御部

モデルプログラム

プログラム

車モデル

モデル

モデル

両図1

機モデルベース開発プロセスないという課題があった。
本稿では、まず１つめの課題である車載ソフトウェアの2 0 1 3 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 8 3 号 −（ 83 ）−2.

ECU の流用開発時の品質確保の効率化

タリングを除去する目的で車載ソフトウェアに組み込まれ車載ソている。そのため、構成 1 の場合は、入力操作と同時のタフトウェアの流用開発時に、旧モデルからの機能的な変更イミングではなく、入力操作から前述のフィルタ処理時間がなくてもテストパターンの再設計が必要なケースについ（図では Ta）経過した後に、ユーザのスイッチ操作の状態て説明する。

はソフトウェアの内部情報として確定する。

2−1

テストパターンの再設計に伴う課題

図 2 に、元は 1 つの ECU で提供していた機能を複数の一方、構成 2 の ECU-2 のように、通信でスイッチの入力ECU へ分割配置した例を示す。（a）の構成では、スイッチ情報を受け取る場合は、ECU-1 側で既にフィルタ処理を実“SW_X”の入力を受け、負荷“RLY_Y”を制御するまで施済みのため、ECU-2 側ではフィルタ処理を行わない。その一連の制御を 1 つの ECU で実現している。一方、（b）ののため、信号入力を受けてから制御信号を出力するまでの構成では、ECU-1 で“SW_X”の入力を受け、ECU-2 で時間が異なる。この理由により、機能に変更がなくても、“RLY_Y”の出力を制御するように役割を分ける構成とし構成 1 の ECU のテストパターンから、構成 2 の ECU-2 のている。このように、複数の ECU 間を通信で多重化するこ

テストパターンへは、先に述べた入出力信号の種別や、信とにより車両全体の電線長を短くしてコストを削減できる。

号の有無などの入出力インタフェース部の変更に加えて、ECU 構成が変更された場合でもテスト設計を効率的に行入力操作から制御出力までの経過時間も調整する必要がうため、同一機能のテストは、構成 1 の ECU 用のテストパあった。

ターンを、構成 2 の ECU-1 および ECU-2 に流用したい。

これら ECU への入出力インタフェースや入出力タイミ

このとき、図 2 の（c）（d）に示すように、個々の入出力信号ングの違いに対応するためには、個別に手作業でテストパの種別（ジカ線※4、あるいは、通信）や、信号の有無など、ターンを作り直す必要がある。テスト実施の効率化を図る

インタフェース部に違いがあるため、テストパターンの多ため、市販のテスト自動化装置を導入した場合でも、テスくの関連箇所を変更しなければならない。

トパターンの作り直しは必要である。特に、当社が開発対

また、図 2 の（e）（f）で、構成 1 の ECU と構成 2 の ECU-象としているボディ制御 ※ 6 用の ECU ソフトウェアには、2 のテストパターンの例に着目してスイッチ入力のタイミ多くの入出力信号があることから、入出力インタフェースングを比較する。これは、入力インタフェースがジカ線入部の変更に伴う影響範囲は大きくなる傾向があり、テスト入力に変更されたケースである。

パターン修正の作業量が課題となっていた。また、人手に一般的に、ジカ線からスイッチ入力の情報を取得する場よる作業が多く発生することから、テストパターン作成時合、ソフトウェアでフィルタ処理が行われる。フィルタ処に人為的なミスが入り込む可能性があり、テスト品質の面

理とは、信号の状態を定期的に観測し、あらかじめ定義しでも懸念があった。

力から CAN※5

た時間を超えて同じ状態が継続した場合にソフトウェア内部の入力情報として確定する方式で、スイッチ接点のチャ2−2

入出力信号割付変換ツールの作成

そこで、２-１で示した課題に対応するために、元となるテストパターンに対して、信号名や入力種別、入力操作タイミングなど、入出力信号の割付に伴う変更点を自動的に変換する入出力信号割付変換ツール（以下、割付変換ツール）を開

設計変更前（流用元）設計変更後（流用後）（a）1ECU構成の例（構成1）（b）2ECU構成の例（構成2）SW̲X

SW̲XRLY̲YECU

具体的には、図 3（a）に示すような、入力情報と、その入力に対してソフトウェア内部で入力情報が確定するタイ

ミングを同じタイミングとした場合の「基準テストパター

ECU-2

RLY̲Y駆動

ECU-1
SW̲X

（e）構成1のテストパターンの例

ECU

ON
OFF
ON

を、前述の割付変換ツールで、入力種別に応じて、例えば（d）構成2の入出力信号の例

SW̲X

RLY̲Y

発した。

ン」を事前に作成しておく。この「基準テストパターン」（c）構成1の入出力信号の例（内部情報）

RLY̲Y

ECU-1

ECU

SW̲X

ジカ線
通信

ジカ線入力タイプの場合は、図 3（b）に示すように、入力

RLY̲Y駆動

フィルタ処理によりスイッチ操作時点からソフトウェア内部で確定するまでの時間 Ta を遡って、「基準テストパター

CAN̲Sw̲X（f）構成2のテストパターンの例
SW̲Xン」より早いタイミングで変化するテストパターンを自動

ON

OFFON
（内部情報）

Ta

ECU-2

ECU-1
Ta

OFF
Ta：フィルタ処理の時間RLY̲YONOFF

また、この割付変換ツールには、幾つかの変換用のパラメータを持たせて、テストパターンに含まれる信号毎に個ONCAN̲Sw̲XON的に生成する。

ECU-2

別に設定できるようにした（表 1）。パラメータには、満たすべき機能が同じ場合でもテストパターンの差異として表れる、信号名の変更、通信とジカ線の種別の変更、変化タ
図2

ECU 構成とテストパターンの例−（ 84 ）− 車載ソフトウェアのテスト自動化支援ツール

イミングの変更、および信号の削除等を行うための項目を

（a）基準テストパターン
ONOFFONOFF

入力情報
出力期待値

ON

（内部情報）

出力期待値

用すると、テストパターンの変換工数を約 20 ％削減でき→tるという結果が得られた。また、ツールで自動変換するこ

変化のタイミングを前倒しとにより、対象信号の見落としによる変換の抜けモレを防Ta

ONOFF

負荷駆動が影響を受ける後継車種に流用する場合を想定した。
検証により、①の手作業実施時に比べて②のツールを適（b）ジカ線入力用テストパターン
入力情報
ON
スイッチ操作（ジカ線） OFF

その変更により該当の入力信号を含む、全体の 2 割の機能→t

ぐことができ、より早い段階でテスト設計品質を高めることができた。

Ta＝入力フィルタ確定までの時間（c）通信入力用テストパターン
入力情報

ON

（内部情報）

ON

出力期待値

ONOFF

スイッチ操作（CAN）

負荷駆動→t3.

モデルベース開発におけるテストの高効率化
3−1

課題

モデルベース開発時のソフトウェアテストのモデルベース開発では、設計段階でシミュレー

ションにより制御の正しさを検証する。そのシミュレー
図3

ション技術には、車載ソフトウェア開発の上流工程から順信号入力タイミング変換の例に、設計したモデルの検証（MILS）、モデルから生成したソースコード（プログラム）の検証（SILS ※ 7）、ECU にプ

表1

ログラムを組み込んだ状態での検証（HILS）、の種類があ

信号割付設定パラメータの設定例

る（図 1）。

（a）信号割付設定パラメータの説明

No意味説

各検証段階では、同一の入力信号の組み合わせに対し検明① I/O 種別

I：ECU への入力／ O：ECU からの出力② 実装種別O：実装／ N:非実装③ 基本信号名

基準テストパターンで定義する信号名④ 対象 Unit 信号名

変換先の信号名⑤ 対象 Unit フレーム名 変換先のフレーム名（CAN 信号の場合）⑥ 信号種別P：Port 信号／ C：CAN 信号⑦ ON 側調整時間（ms） OFF から ON に変化時のタイミング調整時間⑧ OFF 側調整時間（ms） ON から OFF に変化時のタイミング調整時間

証対象であるモデル、プログラム、ECU 実機がすべて同一の動きとなることを確認する必要がある。
このためには、MILS、SILS、HILS 間でテストパターンを共通化してテストすることが、品質確保のためにも検証作業の効率化のためにも重要である。ところが、設計シミュレーションの実施対象であるモデルと ECU では、検証対象の範囲が異なるため、テストパターンの共通化に課題があった。以下に、設計シミュレーションと実機において、検証範囲が異なる理由を説明する。
一般に、車載ソフトウェアは、入力処理部とアプリ（b）信号割付設定パラメータの設定例⑥⑦⑧

ケーション部と出力処理部の各モジュールから構成されSW_XP3030る（図 4（a））。この構成では、入出力インタフェースに変CAN_Sw_00 CAN_Sw_X F_CAN_Z

C00①②③④I

O

SW_00

IO⑤

更があった場合に該当するモジュールのみを差し替えれば、アプリケーション部の作りに影響を与えることがない設定できるようにし、一つの設定ファイルのみで一元管理できるように工夫した。なお、タイミングを調整するための時間幅は、変換元となるテストパターンに対して相対的（a）ECUのソフトウェアの構成な時間として設定できるようにした。これにより、既に特R̲IN

定の車種用に作成済みのテストパターンがある場合には、改めて「基準テストパターン」を作成する必要はなく、別になった。
2−3

割付変換ツールの適用と効果

入力信号のタイ

アプリ機能A

出力

アプリ機能A

出力R̲OUT

差し替え可能の入力タイプのテストパターンに直接変換することも可能

プが変更になり、変更後の車種用のテストパターンを作成

ジカ線
入力R̲IN

CAN
入力

R̲OUT（b）モデルの入出力インタフェースするケースを想定して、①従来どおりの手作業でテストパM̲IN

ターンを変更した場合、②今回作成した割付変換ツールをアプリ
機能A

M̲OUT

適用した場合、の作業工数を比較検証した。テスト対象は、流用元の車種から、9 個の信号の入力タイプが変更になり、

図4

ECU のソフトウェア構成とモデルインタフェース

2 0 1 3 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 8 3 号 −（ 85 ）−ため、アプリケーションの流用効率が高まるというメリッ力タイプ別のテストパターンの違いを吸収する手法が応用

トがある。

できると考えた。

このとき、MILS では、このモジュール化された機能毎

3−2

HILS 用入力信号変換プログラムの作成

そこのアプリケーションの単位で設計シミュレーションを行う

で、このタイミングの違いを吸収する HILS 用入力信号変（図 4（b））。そのため、MILS では、ソフトウェアの内部信換プログラム（以下、入力信号変換プログラム）を作成し号を入力信号として使用するが、HILS では、ECU 装置のハードウェア外部の信号を入力信号として用いる。このよた。その変換処理の 1 例を図 6 に示す。

うに検証対象の外界とのインタフェース部が異なり、入力信号の確定タイミングの違いが生じる。
例えば、入力信号が通信インタフェースによって定期的に入力される信号である場合について、以下に説明する。

（a）MILS用テストパターン
通信故障解除通信故障確定通信故障
信号A （入力信号）
信号X（出力期待値）（a）定期的に受信（正常）（b）受信停止（通信故障発生）

→t

t1

t2

入力信号変換プログラムで自動変換

ＥＣＵ（b）HILS用テストパターン

ECUへの通信入力

通信故障確定の一定時間前に定期送信を停止

通信故障（ECU内部ソフトウェア 正常処理）モデル

モデルへの入力

図5

通信故障

CAN通信
信号C （入力信号）（c）最終受信から規定時間経過後に、通信故障時用の値をセット

正常

通信故障解除時に周期送信を再開信号X（出力期待値）
t0（d）モデルへの入力は、ECU
内部ソフトウェアに同じ

図6t1t2

通信故障時テストパターン変換の例

通信故障時の ECU とモデルの信号の差異

先に述べたように、MILS、HILS で同じタイミングで出力信号を出力させるためには、HILS 用のテストパターン
ECU を対象に通信故障のテストを行う場合、通信線に流では、ECU 内部で通信故障が成立するよりも前のタイミンれる信号を停止させる（図 5 の（a）から（b）への変化）。

グで、ECU 外部での通信の故障が生じるよう設定する必要

ECU に組み込まれたソフトウェアには、規定の時間が経過しても通信からの入力信号が得られない場合には、ソフトがある。
図 6 の例では、MILS 用のテストパターンで通信故障がウェア内部の入力信号に通信故障時用の値をセットする処確定する時間 t1 を基点に、通信故障判定の規定時間だけ理が含まれている（図 5 の（c））。他方、設計シミュレー

遡った時間 t0 に、通信信号 C の定期送信の停止を指示する

ション用のテストシナリオでは、テスト対象のモデルは通波形を生成する。また、MILS 用のテストパターンの通信信インタフェースと切り離された制御機能単独の単位なの故障解除時は、HILS 用テストパターンに、同タイミングで、ソフトウェア内部の入力信号と同様の通信故障時用のt2 で定期送信再開の波形を生成する。

値をセットし、入力する（図 5 の（d））。

この入力信号変換プログラムには、2 − 2 で説明した、入そのため、MILS、HILS で同じタイミングで出力信号を力信号の通信とジカ線の制御タイミングの違いを自動的に出力させたい場合、HILS 用のテストシナリオでは、車載変換する機能も取り込み、MILS 用テストパターンの内部ソフトウェア内部で通信故障が成立するよりも時間的に遡的な信号変化を、HILS 用に ECU の信号入力タイミングへり、通信線に流れる信号を停止するパターンとする必要が変換できるようにした。

ある。

今回開発したテスト支援ツールの全体構成を図 7 に示す。

上記の理由により、モデル用のテストパターンはそのま

本ツールは、MILS 検証時と HILS 検証時のテストパターン

ま ECU 対象のテストに流用することができなかった。前の差異を自動的に吸収する「入力信号変換プログラム」と章で課題となったのは、テスト対象の入力信号のタイプ違「判定処理プログラム」から構成される。前者は、信号入いであり、本章で課題となるのは、テスト対象がモデルと力タイミングの違いを自動変換し、後者は、HILS の検証

ECU の違いの差はあるものの、何れも入力信号のタイミン対象である ECU にハードウェアが含まれることによる出グの違いが問題であるので、先に述べた、流用開発時の入力誤差を自動的に吸収する役割を持つ。

−（ 86 ）− 車載ソフトウェアのテスト自動化支援ツール

これらのプログラムを自動テスト装置内に配置すること

今後は、モデルベース開発プロセス下の評価技術のさらで、あらかじめ MILS 用テストパターンを HILS 用に変換なる向上に努め、車載ソフトウェア開発のより一層の高効したファイルを作成することなく、HILS 検証中にリアル率化と高品質化に取り組んでいく。

タイムに入力タイミングの変換を行う構成とした。これにより、入力タイミングが異なるだけのテストパターンファ
イルを複数保管する必要がなくなり、基本となるテストパターンファイルのみを管理対象とすればよく、ファイル管理の手間を効率化できた。

用 語 集ーーーーーーーーーーーーーーーーーーーーーーーーーーーー※1

ECU

Electronic Control Unit ：自動車に搭載される電子制御ユニット。
MILS用テストパターン

信号入力タイミングの違いを自動変換

入力信号変換プログラム

入力信号出力誤差を吸収し判定

判定処理
プログラム

出力期待値
（ファイル）

判定結果 OK/NG

HILS用テストパターン

※2

MILS

Model in the Loop Simulation ：設計したモデル段階の入力信号ʼ

ソフトウェアを検証するプロセス。
ECU出力値（リアルタイムに生成）

検証対象ECU※3

HILS

Hardware in the Loop Simulation ：実車両環境を模擬で自動テスト装置きるシミュレータを使用して ECU を検証するプロセス。
図7

テスト支援ツールの構成

※4

ジカ線

一つの信号のみを送信する導電ケーブル。
3−3

開発プロセスへの適用と手順導入の効果

本ツールをモデルベース開発の手順に織り込み、実際の開発プロ※5

ジェクトに対して適用評価を行った。評価対象としたのは、Controller Area Network ：電子回路や装置を接続するた入力信号数が 20 個以上、出力信号数が 8 個の 1 機能である。

めのネットワーク規格。

CAN

その結果、自動テスト装置の活用を前提に、テスト実施工数を従来比で約 50 ％削減できるという検証結果が得ら※6れた。上流工程で設計シミュレーションを行い、そのテスライトやドアロックなどの内装品などの電子制御。

ボディ制御

トパターンを製品テストにも応用してテストに活用することにより、製品テスト時の手戻りを防ぎ、従来より短期間※7で製品の品質を高めることができた。

Software in the Loop Simulation ：モデルから自動生成

SILSしたソースコード段階のソフトウェアを検証するプロセス。

4.

結言

本稿では、高機能化や複雑化が進む車載ソフトウェアに対し、効率的なテストを行うための支援ツールの開発と、その導入効果について述べた。
第一の課題である車載ソフトウェアの流用開発時の品質確保の効率化については、テストパターンを ECU の設計変更前と設計変更後で共通化を図る技術を構築し、該当するテストパターンの変換工数を 20 ％削減できた。また、第二の課題に対するモデルベース開発の取り組みでは、前記のテストパターン共通化の技術を応用して、設計シミュレー

参考文献（1） 金澤明 他、「車載ソフトの広範囲な起動タイミングの検証」、SEI テ
クニカルレビュー第 172 号、pp106-111（2008）（2） 独立行政法人情報処理推進機構、「『組込みシステムの先端的モデルベース開発実態調査』調査報告書」（2012）（3） 堀川健一 他、「自動車ソフトウェアの標準仕様“AUTOSAR”の評価」、
SEI テクニカルレビュー第 175 号、pp92-97（2009）

ション用のテストパターンを、ECU 実機テスト用のテストパターンと共通化する技術を開発した。これにより、自動テスト装置の活用を前提に、テスト実施工数を従来より約50 ％削減し、また、製品テスト時の手戻りを防ぎ、より短期間で製品の品質を高めることができる目処を得た。

2 0 1 3 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 8 3 号 −（ 87 ）−執筆者 ----------------------------------------------------------------------------------------------------------------片岡智 美＊：㈱オートネットワーク技術研究所
パワーネットワーク研究部 技師

坂育 子 ：住友電装㈱古戸松本エレクトロニクス事業部

健 ：㈱オートネットワーク技術研究所
パワーネットワーク研究部 グループ長

達 治 ：㈱オートネットワーク技術研究所
パワーネットワーク研究部 部長------------------------------------------------------------------------------------------------------------------------------------＊主執筆者−（ 88 ）− 車載ソフトウェアのテスト自動化支援ツール