組込ソフトウェア向けインターフェース シミュレータ（SILS）による開発効率の向上
Improvement of development efficiency by embedded software for interface simulator（SILS）
京谷 智哉＊

中越 敏典＊Tomoya Kyotani, Toshinori Nakagoshi

昨今、車載向け組込ソフトウェアは、EV（Electric Vehicle）、ADAS（Advanced Driver Assistance
System）開発の盛り上がりによって、ますます複雑化・大規模化するとともに、機能安全要求の高まりによる高品質化、及び、開発競争による更なる開発期間短縮が求められている。
当社もそのような環境の中にあるが、対応策の１つとして PC 上で動作する SILS（Software In theLoop Simulation）に分類されるシミュレータを開発し、開発効率を飛躍的に向上させることができた。
本稿では、このシミュレータを開発するに至った背景、シミュレータの概要、及び導入効果について紹介する。
Recently automotive embedded software is increasingly complicated and large scale due to theexcitement of EV（Electric Vehicle）and ADAS（Advanced Driver Assistance System）development.
In addition, it is required both higher quality by increasing functional safety requirement and further
shortening of development period by development competition.
Although we are also in such an environment, as one of the countermeasures, we developed asimulator classified as SILS（Software In the Loop Simulation）that runs on PC, and improved thedevelopment efficiency dramatically.
In this paper, we introduce the background of the development of this simulator, the outline of thesimulator, and the introduction effects.

ソフトウェア開発を行うために必要な環境としては、

1．
まえがき

大きく、設計ツール（文書作成ツール、モデリングツール

車載向け組込ソフトウェアの開発は、車両メーカー／等）、ソフトウェア開発環境（コンパイラ）、テスト環境

車載組込機器ベンダーからの要求による車両機能改善・が挙げられる。設計ツールやソフトウェア開発環境に機能追加に伴う仕様変更や、複数機種への機能水平展開

関しては、よほど特殊な場合を除いて汎用 PC 上で動作による機能移植、車載組込機器ベンダーからの要求にするツールを使用するが、テスト環境に関しては、開発よるコストダウン、及び性能改善に伴うハードウェアしたソフトウェアを実行する環境に依存する。
車載向け組込ソフトウェア開発においては、主となる回路変更による仕様変更等の様々な開発要件に対応してテスト環境が開発対象ハードウェアの実機環境であり、ソフトウェアを変更する内容となる。

これが唯一のテスト環境となる場合が多い。

開発の流れとしては、これら複数の開発要件に対応したソフトウェア変更を車両開発における試作車イベント

このような状況の中、数年前までは、少数の開発担当ごとの要求に合わせて順々に行い、複数回のリリースを者が「設計⇒実装⇒テスト」のサイクルを短期間で回し経て開発完了へ向かうという形が一般的である。特に、ながら開発を進めることができた。

車両と密な関係を持つ ECU（Electronic Control Unit：

しかしながら、昨今の先進運転支援システムをはじめ電子制御ユニット）に関しては、実車評価結果に応じてとする車両電装化技術の急速な発展により、機能安全にソフトウェア変更を行う場面が増え、短期間に複数回の対応した高い品質が求められる機能の増加、マイコンのリリースを行う状況が発生しやすい。

高性能化に伴い可能となった複雑・大規模な機能要件の＊関西事業部 第六技術部

1

MSS 技報・Vol.29

実装、グローバル展開の流れからの機種数の増加、及び状況が増えると、車載向け組込システムの評価で一般的競争激化によるリードタイムの圧縮等々への対応が求めに使用する測定機器も不足する。
これらの測定機器の中でも特に必須のものは価格が高られ、少なくとも、今までの開発体制では、これらに対応することが難しくなっている。対応策として開発要員く、費用の面から容易に台数を増やすことが難しい。

を増やし、開発サイクルを複数の開発担当者が並行して(3)

ハードウェア実機環境の使用可能時期、期間の制限

ハードウェア実機環境は当社が主に受託しているアプリ

回すも、品質・コスト・工期に関する多くの問題を抱えケーションソフトウェア開発だけでなく、ハードウェアている。
当社では、車載向け組込ソフトウェア開発の中でもアドライバソフトウェア開発、システムテストの検証でもプリケーションソフトウェアを中心とした受託開発を使用するため、各担当者の使用希望時期が重なり、使用行っているが、その中で、これらの問題解決策の１つと可能時期、期間が制限される状況が発生しやすい。

してシミュレータの開発を行った。
2.1.2

2．インターフェースシミュレータ開発の背景

客先試験場への移動（出張）が必要

前項 2.1.1 で述べた原因により、ハードウェア実機環境の使用が客先試験場に制限される場合に、テスト業務の当社が車載向け組込ソフトウェア開発の受託を開始しため、頻繁に客先試験場への移動が必要となった。

た当時は、まだ機種数が少ないうえ、開発規模も小さく、少人数での開発が主であったが、委託元での開発機種の特に当社の場合、客先が遠隔地であったこともあり、グローバル展開が一気に加速し、機種数が増え始め、開テスト業務における客先への移動時間が大きなウェイト

発規模が増大すると、少人数体制では全ての開発に対応を占めることになり、開発コストに影響を与えることとするのが難しい状況となった。

なった。

そこで、開発要員の増員を行い、開発体制強化を図った
2.1.3

が、複数の担当者が並行して開発を進める中で、テストデバッグが容易に行えない

ソフトウェア開発においてデバッグは重要な作業項目

環境に起因する表１に示す問題点が浮上してきた。

であるが、以下のようなデバッグが容易に行えない状況

以降に、これらの問題点の原因を示す。

が発生した。
2.1

問題点の原因2.1.1(1)

ハードウェア実機環境の稼働率が高い

設計・実装完了後、すぐにテスト開始できない

前項で述べた原因から、ハードウェア実機環境の稼働

この問題は、ソフトウェアのテスト環境として使用する率が高い状況が発生しやすく、デバッグ実施に当たってハードウェア実機環境の不足が主な原因であり、以下のは実機環境を使用するための調整が必要となることや、状況で発生した。

使用できる期間も制限されることが多く、気軽にデバッグ(1)できない。

開発対象のハードウェアの不足(2)

新システム開発初期や、原低対応でのハードウェア構成

デバッグの準備に時間がかかる

変更の試作段階では、開発対象ハードウェアの製造数がハードウェア実機環境でのデバッグにおいては、マイ限られるため、構築可能なハードウェア実機環境の数がコン端子へのデバッグ用モニタ出力を測定器でモニタ限られる。

できるようにする等、ハードウェア回路への細工が必要(2)な場合が多い。

ハードウェア実機環境で必須の測定機器の不足

また、バグ改修やデバッグコードの挿入等によるソフト機種展開が増え、複数機種の開発が並行して行われる
表1

ウェア変更の度に、実機へ書き込むオブジェクトの生成

テスト環境に起因する問題点

問題点
設計・実装完了後、すぐにテスト開始できない客先試験場への移動（出張）が必要
デバッグが容易に行えないフォールト注入テスト実施のしきいが高い
統合検証・回帰テストの網羅不足（試験実施に時間がかかり、短期間で頻繁にリリースが必要な場合に発生）を行うためのコンパイルを実施しなければならないが、影響を受ける
プロジェクト管理項目

機種によっては、このコンパイルに非常に時間がかかるコスト工期ものがあり、デバッグを長期化させる要因となった。

○○

(3)

○○
○

○

○

○

○

○

品質

ソフトウェアデバッグが難しい

ソフトウェアデバッグにおいては、ソフトウェアを実行停止→変数値を操作（動作条件変更) →実行再開の流れで操作したい場面が多いが、ハードウェア実機環境においては、デバッガ等を用いてソフトウェアの実行を○停止させたとしてもハードウェア回路は動作し続ける

2

MSS 技報・Vol.29

ため、ソフトウェアの実行を再開させた際に、想定しないた、専用ハードウェアを必要としない汎用 PC 上で動作状態になる場合が多い。そのため、デバッグを行うためするシミュレータを構築し、ソフトウェア開発に適用すのハードウェア知識が必要であり、経験の浅い担当者でることが、車載向け組込ソフトウェア開発における問題あると、デバッグを実施すること自体が難しい。

に対する解決策の１つになると考えた。

2.1.4

3．
インターフェースシミュレータの概要

フォールト注入テスト実施のしきいが高い

ハードウェア実機環境でのデバッグにおいてフォール

本章では、開発したシミュレータで採用したシミュト注入テストを行う場合には、ハードウェア回路の改造

レーション手法及びシミュレータの適用範囲について述を必要とする、又は特殊な治具を製作する必要がある。

べる。

そのため、テスト実施に当たっては、相応のハードウェア3.1知識を持つ担当者が必要であり、準備にも時間がかかる。

シミュレーション手法

今回、シミュレータを構築するために採用したシミュ

また、誤操作によりハードウェアを故障させてしまう

レーション手法は SILS と呼ばれるものである。

場合もある。

以降に一般的なシミュレーション手法、及び手法とし2.1.5

統合検証・回帰テストの網羅不足て SILS を選択した理由を述べる。

ハードウェア実機環境上でのテストにおいては、テスト3.1.1

項目に応じた試験系の準備が必要であり、１つのテスト

一般的なシミュレーション手法

特殊ハードウェアを使用せず汎用 PC 上で動作させる項目を実施するために相応の時間がかかる。

シミュレータを構築するためのシミュレーション手法とそのため、短期間で頻繁にリリースを繰り返す開発においては、時間的制約からリリースまでに実施する回帰

しては、一般的に、大きく以下の３つがある。

テスト項目を優先順位に応じて絞って対応せざるを得な(1)

MILS ：Model In the Loop Simulation

い場面があり、網羅範囲が不十分であることが原因で、(2)

SILS ：Software In the Loop Simulation

後工程でバグが見つかる等、問題発覚が遅れるケースが(3)

SPILS ：Simulator based Processor In the LoopSimulation

あった。

MILS は、モデル記述された制御モデルをテスト対象と2.2

問題点への対策し、制御モデルの処理内容の妥当性の検証を行うために用いる手法である。主にシステム開発の上流設計の検証

前節で挙げたテスト環境に起因する問題の原因は、で用いられる。

主として活用できるテスト環境がハードウェア実機環境

SILS は、C 言語等で記述されたソースコードをテストのみであることによる。
当社が受託開発する車載向け組込ソフトウェアの開発対象とし、ソースコードのロジック検証を行うために対象は、ハードウェア回路構成への依存度が少ないアプ用いる手法である。主にソフトウェア開発フェーズでのリケーションに該当する部分が大半を占めており、ソフ検証で用いられる。

トウェアのデバッグ、テストにおいてハードウェアとのSPILS は、実マイコンに書き込み動作させるものと結合が必要な項目が少なく、必ずしもハードウェア実機同じオブジェクトコードをテスト対象とし、命令セット環境を必要としない内容が多い。

シミュレータ上で実マイコン上に書き込む全てのプログ

また、ソフトウェア開発においては、昨今の開発規模ラムを動作させ、実動作と等価な検証を行うための手法増加傾向の中で、開発期間の確保も重要となってきてである。SILS と同様にソフトウェア開発フェーズでのいる。そのため、システム開発初期段階でハードウェア検証に用いられるが、性能評価に関する検証でも用いる開発が並行に進んでいる状況において、ハードウェアことが可能な点が異なる。
これらのシミュレーション手法の構成概要を表２に示す。

実機環境の使用に制約がある場合でも、ソフトウェアロジックに関するデバッグ・評価を、品質を確保しつつ3.1.2効率よく進めたい状況にある。

SILS 手法を選択した理由

今回、シミュレータを構築する際の手法として SILS

これらを踏まえて、ハードウェア回路構成に依存しないミドルウェアやアプリケーション等のソフトウェアを採用した理由は以下によるものである。

（以降、本稿では、これらを総称したものをアプリケー(1)

ソースコードでのロジック検証が必須

車載向け組込ソフトウェア開発では、ソースコードでションと呼ぶ）をデバッグ・評価することを主目的とし

3

MSS 技報・Vol.29

記述されたレガシーコードをベースに機能変更・追加をセットシミュレータを使用する必要があること、シミュ行う派生開発が中心であり、ソースコードのロジック検レータ内に組み込む電子回路シミュレータをマイコン仕証が必須である。

様に従って構築する必要があることから、シミュレータ自体がマイコンのハードウェア回路構成に密に依存する

また、昨今、モデルベース開発によりモデル記述を使構成となる。

用してソフトウェアの開発を進める場面が増えつつあるが、その多くは、モデル記述から生成したソースコード

そのため、マイコン及びその周辺回路の仕様変更に伴をレガシーコード上に組み込み、デバッグ、評価を行ういシミュレータを変更しなければならない。特に、マイ必要があり、その場合もソースコードのロジック検証がコンを全くシリーズの異なるものに置き換える場合は、必須となる。

大規模な変更が必要となる。

(2)

アプリケーションのロジック検証を目的とした場合、導入コストを抑えることができる

今回の問題の解決に当たっては、複数の担当者が並行アプリケーション自体がマイコン仕様に依存することがして開発を進められることが前提となり、テスト環境をほとんど無いため、マイコン仕様の変更によってシミュ各担当者に割り当てることを考慮する必要がある。このレータの変更が発生する状況は避けたい。
SILS では、プラントモデル内に組み込む電子回路シ場合、テスト環境の導入・維持に必要なコストが重要にミュレータ、制御対象シミュレータの構成に関しては、なる。
MILS の場合はモデル記述及びその検証を行うための特にハードウェア回路構成に依存しなければならない等モデリングツールが、SPILS の場合はマイコン対応のの制約が無く、シミュレータ構築時にハードウェア回路専用命令セットシミュレータがそれぞれ必要となるが、構成への依存度を調整することができ、シミュレータ変どちらも初期導入費、維持費が高額なものが多く、かつ更の頻度を少なくすることが可能である。

使用するユーザごとにライセンス購入等が必要になる場
3.2

合が大半であり、必要数に応じた導入コストを要する。

シミュレータ適用範囲

SILS に関しては、手法実現に当たって安価な汎用ソフト想定しているシミュレータの適用範囲を図１に示す。

ウェアを用いて構築することができ、大幅な追加コスト

シミュレータの主な適用範囲は、ソフトウェア開発 Vをかけずに、必要な数のテスト環境を立ち上げることが字モデルの右側、具体的には、検証フェーズでのソフト可能である。

ウェア結合テスト、ソフトウェアテストに関するソース(3)

コードレベルでのロジック検証及びソースコード対象のシミュレータ変更の頻度を抑えることができるデバッグである。

SILS と SPILS を比べると、マイコン上で組み込む全また、ソフトウェア開発 V 字モデルの右側だけでなてのプログラムを動作させることができ、性能を含めたく、左側の設計フェーズでのソフトウェア設計、及び多くの検証が可能な SPILS が魅力的に見える。

ソフトウェア構築におけるコーディング等においても、

しかし、SPILS では、マイコン仕様に依存した命令設計変更における影響分析や、コーディング時のソース
表2

構成概要

テスト対象
(モデル記述)シミュレータ適用範囲

システム
設計

制御対象
モデル

ソフトウェア
要求分析

制御対象
モデル

ソフトウェア
結合テスト

ソフトウェア
設計

ハ回路IF
モデル

•

テスト対象
(ソースコード)

制御対象
シミュレータソフトウェアテスト体
テ専 ス
オ 用 トテブテス ジェ ストトク ツー
トコー ルにド よ対 る象

SILS

電子回路
シミュレータソフトウェア
構築

SPILS

制御対象
シミュレータ

単電子回路
シミュレータ
メモリ
回路IF
マップIF
モデル
モデル

•

命令セット
シミュレータ
テスト対象(オブジェクトコード)

システム
テストードド ウェ
ウ ライ アハ ェア バ 実機
結 ー 結 ソフ 環
※ 合 ドウ 合 トウ 境•
ド テス ェ テラス ェ でシ 評価 イ ト ア- ト ア のテ-上ソバス
ス
フ
テ 含む ソ
位 トトウ
フ
ム
ソ
トウ
試
ェフ
験
アト
ェ
ア

制御対象
シミュレータ•MILS

コード ロジックの事前検証等での活用が可能である。

シミュレーション手法と構成概要

手法

制御対象
モデル

■ソフトウェア設計フェーズでの適用• ソフトウェア設計でのロジック変更影響分析• ソフトウェア構築のコーディング作業でのソースコード ロジック事前検証等※ 命令セットシミュレータ、メモリマップ IF モデル、回路IF モデルの一部は、使用するマイコン仕様に従ったものとする必要がある。

図1

4■ソフトウェア検証フェーズでの適用• ソフトウェア結合テスト、ソフトウェアテストでのソースコード対象ロジック検証• ソースコード対象デバッグ

シミュレータ適用範囲

MSS 技報・Vol.29

(6)機能安全対応の要求がある場合、オブジェクトコード導入のしきいが低い

Windows 搭載の汎用 PC 上で動作するシミュレータででのテストが求められるが、オブジェクトコードを対象あるため、特殊な環境が必要ではない。とした単体テストでソースコードとオブジェクトコードの動作一致を確認できていれば、アプリケーションのまた、必要なツールが特殊用途の専用ツールでは無く、ロジック検証に関しては、シミュレータ上での評価結果

一般的にソフトウェア開発で使用されるソフトウェアをハードウェア実機環境上での評価と同等に扱うことも統合開発環境の Visual Studio のみであるため、導入しや可能と考えており、機能安全対応においてもシミュレーすい。

タの活用が期待できる。
4．インターフェースシミュレータの特徴
4.1

シミュレータの特徴(1)

割込み処理等のイベント処理に制約がある

象が持つ定周期処理、割り込み処理等のイベント処理を順番に実行する仕様であるため、実環境で発生する周期テスト対象処理実行途中での割込み処理実行を行うことができない。

車載向け組込ソフトウェア内のハードウェア回路構成へ

よって、イベント処理の実行順に関して、ハードウェの依存度が少ないアプリケーションをテスト対象とする。
(2)

シミュレータの制約

現状のインターフェースシミュレータでは、テスト対インターフェースシミュレータの特徴を以下にまとめる。
(1)

4.2

ア実機環境と異なることを考慮してテストを実施する

簡易モデルを組み込んだシミュレータ必要がある。

一般的な SILS では、厳密にハードウェア動作やプラント動作を模擬するモデルを組み込むのに対して、イン4.3

ターフェースシミュレータでは、テスト対象ソフトウェ

シミュレータの構成

アのインターフェース観点で、ソフトウェアのロジック

本節では、シミュレータの構成について説明する。

検証を行う上で最低限必要な論理的な振る舞いを模擬

インターフェースシミュレータの構成概要を図２に示す。
(1)

する簡易モデルを組み込む。

プラットフォーム

シミュレータの中核となる部分であり、テスト対象

本シミュレータを “ インターフェースシミュレータ ”

及びシミュレータ内の各機能の実行制御を行う。と呼ぶ理由もこの特徴によるものである。

(2)

また、この特徴から、機能的には同じであるがハードインターフェースアタッチメント

シミュレータとテスト対象間のインターフェースをウェア回路構成が異なる他機種へのシミュレータ流用が行いやすい。
(3)

シミュレータの構築が容易

ECU上での動作範囲

シミュレータ上での動作範囲

実ソフトウェア

実ソフトウェア

インターフェースシミュレータは、シミュレータ構築で必須の以下の作業を容易に行うための仕組みを持つ。
(a) テスト対象とシミュレータ間のインターフェース

アプリケーション(ハードウェア構成非依存部)

接続(b)

シミュレータ内へのモデル組み込み

H/W抽象化ソフトウェア
ドライバソフトウェア

これらにより、シミュレータ導入までの期間を短縮する。
(4)

アプリケーション
インターフェース境界(ハードウェア構成依存部)

同じテスト項目を同条件で何度でも実施可能

シミュレータの振る舞いを制御するためのシナリオ

マイコン内部ハードウェアを記述したファイルを作成し、シミュレータに読み込ませることで、シナリオに従ったテストを実行することがマイコン外部ハードウェアできる。

ECU間
通信

これにより、同じテスト項目を同条件で何度でも実施外部ECUすることが可能である。
(5)

プラント
(制御対象)

テスト結果をファイル出力可能

テスト対象

アプリケーション(ハードウェア構成非依存部)(2) インターフェースアタッチメント(1) プラットフォーム(3) 模擬機能
簡易ハードウェアモデル

(4)シナリオ

簡易プラントモデル(5) モニタ機能機能(6) 統合開発環境

テスト対象内の変数値や、モデルの動作状態をモニタ

インターフェース シミュレータ(Visual Studio)ファイルとして出力することが可能である。
汎用PC搭載OS：Windows

このファイルを利用することでテスト結果のエビデンス作成を効率的に行える。

図25

インターフェースシミュレータ構成概要

MSS 技報・Vol.29

シミュレータのシナリオ機能、又はデバッグ機能接続する。また、テスト対象とのインターフェース差異を吸収する役割を持つ。

（統合開発環境 Visual Studio の機能）を使用して、変数(3)値を任意の値に書き換えることにより、フォールト注入模擬機能を行う。

簡易ハードウェアモデル及び簡易プラントモデルが組み込まれ、インターフェースアタッチメントを介しシミュレータを使用したテストでは、ハードウェア動作て、テスト対象のインターフェースに対する振る舞い模との厳密な連携動作を検証するのではなく、フォールト擬を行う機能である。

発生時に行うべきソフトウェアの機能連携に着目したロジック検証を行うこととなる。

また、シミュレータ構築の際にモデルを容易に組み込

フォールト注入テストに関連する機能の多くは、機能むための仕組みを持つ。
(4)

安全に関係したものであり、車両自体の振る舞いに影響シナリオ機能するものであるため、その最終的な検証及び妥当性確認

ファイルで入力されるシナリオ記述に従い、模擬機能内のモデルの振る舞いを制御する。

を車両環境と同等な環境で行う必要があるが、事前に(5)シミュレータ上で十分なソフトウェアのロジック検証をモニタ機能行うことにより、後工程での手戻りを抑えることができる。

テスト対象内の変数やシミュレータ内モデル内の動作

図３にシミュレータを使用してのフォールト注入イ状態をモニタする。モニタ結果をファイルとして出力する。
(6)

メージを示す。

統合開発環境(5)

Windows のソフトウェア統合開発環境である Visual

ソフトウェアデバッグ

設計フェーズ、検証フェーズを問わず、ソースコードStudio 上で、テスト対象、及びシミュレータを動作させ、ロジックのデバッグで使用可能である。

デバッグ機能として Visual Studio を利用する。

統合開発環境 Visual Studio 上でテスト対象、及び4.4シミュレータの用途

シ ミ ュ レ ー タ を 動 作 さ せ る 構 成 で あ る た め、Visual
Studio が持つ豊富な機能を利用して、容易にデバッグをインターフェースシミュレータの用途を以下にまとめる。
(1)

行うことができる。

ソフトウェア結合テスト

アプリケーション内のモジュール結合テスト、機能

5．
インターフェースシミュレータ導入効果

結合テスト等、ソフトウェアの組合せに関するロジック

インターフェースシミュレータ導入により、導入前に検証で使用する。

発生した問題の多くを改善することができた。以下に

ただし、4.2 節で述べた制約があるため、複数の周期処理間、割り込み処理間でのインターフェース確認を行その効果についてまとめる。

う必要があるテスト項目については、特定条件下という(1)開発担当者が自席で動作可能なシミュレータ環境を制約付きで検証を行うことになる。
(2)

テスト環境のボトルネック解消

持ち、必要な時期に必要な期間、ソフトウェアデバッグ、ソフトウェアテスト

ソフトウェアテストで行う妥当性確認に関しても、ソフトウェア結合テスト、及びソフトウェアテストをハードウェア実機環境と併用することで、シミュレータ実施するための環境を使用できるようになった。これにの適用が可能である。

より、複数の開発担当者を投入して並行開発を行う様な例えば、ハードウェア実機環境上で確認が困難な複雑な局面においても効率的に開発を進められるようになった。

組合せパターンの検証に関してはシミュレータを適用し、ハードウェア実機環境での検証が全く不要となる訳

性能面の確認で必要な最低限のパターンをハードウェアではないが、ハードウェア実機環境を必要とする場面を実機環境上で確認する等のテスト戦略が考えられる。
(3)

回帰テスト

シミュレータのシナリオ機能により、過去に行ったテストで使用したシナリオを実行することで、アプリケーションのソースコード ロジック観点での回帰テストが可能である。
(4)

フォールト注入テスト

テスト対象の入力又はテスト対象内へのフォールト注入テストにおいて使用可能である。

図3

6

シミュレータを使用してのフォールト注入イメージ

MSS 技報・Vol.29

大幅に削減でき、該当機種開発に閉じる問題だけでなく、シナリオの作成の効率化や、テスト結果検証の効率化に測定機器不足等を要因とする複数の開発に跨るハード関するものである。
また、今後、新規機種へのインターフェースシミュ

ウェア実機環境不足問題も大幅に改善された。
(2)

レータ導入を進めるに当たっては、シミュレータ構築のデバッグ効率の向上

効率化が鍵となり、構築を容易にする更なる工夫、仕組

インターフェースシミュレータ導入により、高度なみが必要となる。

デバッグ環境を使用できるようになったため、実装時や今後、これらの課題の改善を進めながら、新規機種へ不具合調査でのデバッグ効率化が図れた。の展開を行っていく計画である。

特に、不具合調査時の効果は大きく、ハードウェア実機環境上で再現が難しい現象を、シミュレータ上で比較

7．
むすび的容易に再現でき、原因特定の効率化が図れた。
(3)

本稿では、当社で開発したインターフェースシミュ

フォールト注入テストの実施効率の向上

従来、フォールト注入テストはハードウェア実機環境

レータについて、導入背景、特徴、用途、導入効果をを用いて行っていたため、ハードウェアへの細工やテスソフトウェア検証の観点で述べた。しかし、シミュレートコードの埋め込み等の処置が必要であり、環境準備のタの活用については、機能改善を行うことで、まだまだ難しさや、作業効率の問題があったが、シミュレータ領域を拡大できると考えている。また、新たな活用方法を適用によりそれらの問題が解消された。

見出すためにも、改善と合わせて活用の普及も継続的に行っていきたいと考えている。

また、ハードウェア実機環境上での作業機会を必要最小限に減らすことで、ハードウェア故障のリスクを低減

参考文献できた。
(4)(1) 仮想マイコン応用推進協議会／ vECU–MBD WG：

回帰テストの網羅率向上

仮想 ECU 活用のためのユーザ向け導入検討支援

従来、回帰テストはハードウェア実機環境を用いて人手によって行っていたため、実施期間及びテストのガイド，Rev3.1再現性という点で問題があったが、シミュレータ適用にhttp://www.vecu-mbd.org/document/

より、短期間での実施が可能となり、回帰テスト項目の網羅率を上げることができ、さらに、テスト再現性につWindows、Visual Studio は、米国 Microsoft Corporationいても確保することができるようになった。の米国及びその他の国における商標又は登録商標です。

また、CI（Continuous Integration）環境を構築し、更なる効率化を実現することができた。

執筆者紹介

6．
今後の展開

京谷 智哉
1997 年入社。官公庁・防衛関連システムの開発を担当

インターフェースシミュレータの導入により、テスト後、2009 年から車載向け組込システムの開発に携わる。

環境の制約によって引き起こされる多くの問題を改善することができ、その有効性を確認することができた。

中越 敏典

しかし、シミュレータ導入によって見えてきた課題も1992 年入社。通信・防衛関連システムの開発を担当後、あった。その多くは、シミュレータを更に有効活用する

2010 年から車載向け組込システムの開発に携わる。

ための課題であり、例えば、シミュレータに読み込ませる

7

MSS 技報・Vol.29