JP7134903B2

JP7134903B2 - 不具合再現支援システム、不具合再現支援方法

Info

Publication number: JP7134903B2
Application number: JP2019039838A
Authority: JP
Inventors: 岳彦長野; 辰昭長船
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2019-03-05
Filing date: 2019-03-05
Publication date: 2022-09-12
Anticipated expiration: 2039-03-05
Also published as: JP2020144542A; US11294795B2; EP3705998A1; US20200285560A1; EP3705998B1

Description

本発明は、不具合再現支援システム、不具合再現支援方法に関する。

車両の故障等の不具合の原因を特定するため、特許文献１に記載の技術がある。特許文献１では、使用履歴の異なる車両の故障診断をする際に、あらかじめベースとなる車両を準備しておき、故障診断を受ける際には、ベース車両の中から診断を受ける車両と似た車両を選定し、その車両に対して制御データを転送して故障診断をすることによって、不具合の再現率を高める技術が開示されている。

特開２００４－２２７４３９号公報

特許文献１では、用意されたベース車両に対し、制御データのみを転送して不具合の再現率を高めている。しかし、ソフトウェアプログラムの不具合再現の観点では、前提とするプログラムやテスト環境が揃わないと、不具合が再現しないことが多い。上記特許文献１は、類似するベース車両に制御データを送ることにより、不具合の再現性を限定的に高めることが出来るが、不具合の再現要因が他にあるため、効果が限定的であり、必ずしも迅速に不具合の再現環境を構築して不具合を再現できないと考える。

そこで本発明は、車両出荷後に製品不具合が発生した際に、不具合の再現環境を迅速に構築し、再現させるための情報を提供することで、不具合の再現を早めることを目的とする。

本発明の一態様にかかる不具合再現支援システムは、異常車両の不具合の再現を支援する不具合再現支援システムであって、前記異常車両から受信した構成情報であって異常が検知されたハードウェアのハードウェア情報を含む前記構成情報と、あらかじめ記憶部に記憶された車両の構成情報とに基づいて、前記異常車両のハードウェア情報と同じハードウェア情報を含む構成情報を取得する構成情報取得部と、前記構成情報取得部により取得された構成情報に含まれるソフトウェア情報と同じソフトウェア情報を含むソフトウェアを記憶部から取得する構成情報判定部と、前記構成情報判定部により取得されたソフトウェアを、前記不具合を再現するための不具合再現環境に配信する配信部と、を備えることを特徴とする不具合再現支援システムとして構成される。

また、本発明は、上記不具合再現支援システムで行われる不具合再現支援方法としても把握される。

本発明の一態様によれば、出荷後に製品不具合が発生した際に、不具合の再現環境を迅速に構築し、再現させるための情報を提供することで、不具合の再現を早めることができる。

一実施形態に係る不具合再現支援システムの構成図。不具合を再現するテスト環境配布の手順を示すフローチャート。図２における車両が不具合の内容を構成管理システムサーバに送信する手順を示すフローチャート。図１における構成管理DBに保存されている車両の構成管理情報の一例を示す図。図３における車両から不具合再現支援システムに送信されるメッセージを示す図。図２における類似車種一覧作成の手順を示すフローチャート。図６における類似車種一覧の内容の一例を示す図図２におけるテスト環境配布の手順を示すフローチャート。図１における不具合報告DBの一例を示す図。図２におけるテストレポートの一例を示す図。

以下、図面を参照して本発明の実施形態を説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。

図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。

以下の説明では、「テーブル」、「リスト」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。

同一あるいは同様な機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。

また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ、ＧＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）および／またはインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であれば良く、特定の処理を行う専用回路（例えばＦＰＧＡやＡＳＩＣ）を含んでいてもよい。

プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

図１は、本実施例に係る不具合再現支援システムの一例を示す図である。不具合再現支援システム1000は、構成管理システムサーバ10と、テスト車両管理サーバ20と、ディーラ車両管理サーバ21と、仮想テスト環境管理サーバ22と、不具合原因調査端末23とを有している。

構成管理システムサーバ10は、出荷後の車両情報、不具合情報、開発時のテスト環境に関係する情報を管理するサーバである。構成管理システムサーバ10は、管理対象車両30から受信した情報をもとにOEMのテスト環境242及びテスト車両241aや、ディーラの車両241bからなる不具合テスト環境24に対し、不具合を再現させるソフトウェアプログラムを配布する。

テスト車両管理サーバ20は、自動車メーカのテスト車両241を管理するサーバである。テスト車両管理サーバ20は、テスト車両の使用状況に関する情報と内部構成情報を構成管理システムサーバ10から取得し、テスト車両241で発生した不具合の内容と当該内容に関係する情報（例えば、図９の不具合情報）を構成管理システムサーバ10に送信し、不具合報告データベース15に記録する。

ディーラ車両管理サーバ21は、テスト車両管理サーバ20と同様の機能を、ディーラが保有する車両で再現させるためのサーバである。

仮想テスト環境管理サーバ22は、自動車メーカの仮想テスト環境を管理するサーバである。仮想テスト環境管理サーバ22は、テスト車両管理サーバ20と同様の機能を、仮想テスト環境242で再現させる。

不具合原因調査端末23は、自動車メーカやディーラからの情報提供や、自動車メーカ内部での再現試験などで蓄積した原因調査結果を保存・参照するための端末である。不具合原因調査端末23は、テスト車両241及び仮想テスト環境242からなる不具合再現環境24に接続される。本システムでは、このような環境のもと、出荷後の自動車車両である管理対象車両30の不具合を再現する処理が行われる。

構成管理システムサーバ10は、構成管理DB11と、テスト車両管理DB12と、ソフトリリース管理DB13と、BOMDB14と、不具合報告DB15と、仮想テスト環境DB16と、テスト予約DB17とを記憶する。

構成管理DB11は、市場に出荷される車両を車両固有の番号ごとに管理し、部品となるハードウェアと、そのハードウェアで動作するソフトウェアプログラムの組み合わせパタンと、組み合わされたソフトウェアプログラムを管理するデータベースである。

テスト車両管理DB12は、自動車メーカ内部で使用されているテスト用車両、その使用状況及び使用時の動作ソフトウェアプログラムなどの情報を管理するデータベースである。

ソフトリリース管理DB13は、アプリケーションプログラム毎にそのリビジョン毎のバックアップデータと、リリース時期などを管理するデータベースである。

BOMDB14は、車両毎のハードウェア設計情報を管理するデータベースである。

不具合報告DB15は、市場で起きた不具合情報を管理するデータベースである。

仮想テスト環境DB16は、テスト車両241以外の車両を模擬したテスト環境の使用状況及び使用時の動作ソフトウェアプログラムなどの情報を管理するデータベースである。

テスト予約DB17は、テスト車両241及び仮想テスト環境242の使用予約を管理するデータ
ベースである。

管理対象車両30は、市場に出荷された車両をさし、複数のECU33をネットワークで接続するためのネットワークノードとなるゲートウェイ31と、ゲートウェイ31がECU33から取得したネットワークパケットを、公衆回線などを使って構成管理システムサーバに通信するための通信装置32と、エンジン制御や自動運転制御などを行うECU33からなる。

図２は、不具合が発生した、もしくは不具合の予兆を検出した車両30からの通知を受け、構成管理システムサーバ10が、不具合再現環境24に、当該車両30に関連する不具合再現環境を構築し、再現テストを行う担当者にテストレポートを配布する手順を示すフローチャートである。

ステップS101で車両30のECU33は、ECU上で動作するソフトウェアプログラムの不具合を検知すると、ステップS102に進む。ステップS102では、ECU33は、不具合の内容と、不具合を発生した車両30の構成情報をメッセージ化し、構成管理システムサーバ10に送信し、ステップS103に進む。ステップS102の具体的な処理については、図３を用いて後述する。

ステップS103では、構成管理システムサーバ10は、車両30から受信したメッセージに含まれるVIN（Vehicle Identification Number：車両固有の番号情報）をキーに、構成管理DB11に保存されている構成情報を取得し、ステップS104に進む。ステップS104では、構成管理システムサーバ10は、車両30から送信された構成情報と、構成管理システムサーバ10の構成管理DB11に登録されている情報の構成が同一か否かを判定する。構成管理システムサーバ10は、両者の構成が同一でないと判定した場合（ステップS104;NO）、不具合再現環境24が構築できないと判断し、処理を終了する。

一方、構成管理システムサーバ10は、両者の構成が同じであると判定した場合は（ステップS104;YES）、不具合再現環境24が構築可能であると判断し、ステップS105へ進む。構
成情報の構成が同一か否かは、例えば、構成情報として車両番号(VIN)、ECUの識別情報、マイコンの識別情報を含み、これらの値が同一である場合に、両者の構成が同一であると判定すればよい。

ステップS105では、構成管理システムサーバ10は、完全に不具合が同じ車両同じ車種の構成情報だけでなく、ソフトウェアプログラムのバージョン違いや、不具合を発生したECUの互換ECU、さらにはそれらを搭載した別車両などの類似車種の構成情報の一覧を作成しステップS106に進む。すなわち、構成管理システムサーバ10は、同一車両や同一車種の構成情報のほか、類似車種の構成情報の一覧を作成し、ステップS106に進む。以下では、類似車種の構成情報について説明しているが、同一車両や同一車種の構成情報についても同様に考えることができる。ステップS105の具体的な処理については、図６を用いて後述する。

ステップS106では、構成管理システムサーバ10は、ステップS105で作成されたすべての類似車種に関する構成情報がテスト環境である不具合再現環境24に配布されたか否かを判定する。

構成管理システムサーバ10は、すべての上記類似車種に関する構成情報がテスト環境に配布されたと判定した場合（ステップS106;YES）、処理を終了する。一方、構成管理システムサーバ10は、すべての上記類似車種に関する構成情報がテスト環境に配布されていない、すなわち未配布の構成情報があると判定した場合（ステップS106;NO）、ステップS107に進む。

ステップS107では、構成管理システムサーバ10は、ステップS105で作成された一覧を参照に、不具合再現環境24に対し、テスト用のソフトウェアプログラムを配布し、ステップS108に進む。ステップS107の具体的な処理については、図８を用いて後述する。

ステップS108では、構成管理システムサーバ10が、不具合車両30から受信したメッセージに含まれるVINをキーに、不具合報告DB15の内容を取得し、ステップS105で使用した類似車種の構成情報と結合してテストレポートを作成し、ステップS109に進む。ステップS109では、構成管理システムサーバ10は、ステップS109で作成したテストレポートを、不具合再現環境24からアクセス可能な不具合原因調査端末23や、テスターが使用するPC等の情報処理端末に対しメールなどの形式で送信し、ステップS106に戻る。

図３は、図２における不具合の内容を構成管理システムサーバに送信する手順（ステップS102）を示すフローチャートである。

ステップS301では、ECU33が不具合を検知し、検知した旨とともにその検知情報をゲートウェイ31に通知し、ステップS302に進む。ステップS302では、ゲートウェイ31は、通知された検知情報を読み取り、当該検知情報に含まれるECU33のハードウェア名、ハードウェアID情報を含むハード管理情報を取得し、図５に示す階層構造のデータ形式でゲートウェイ31の内部メモリに記憶し、ステップS303に進む。

ステップS303では、ゲートウェイ31は、通知された検知情報を読み取り、当該検知情報に含まれるECU33に搭載されるソフトウェア名、ソフトウェアIDを含むソフト管理情報を取得し、図５に示すデータ形式でゲートウェイ31の内部メモリに記憶し、ステップS304に進む。ステップS304では、ゲートウェイ31は、ECU33及びECU33に搭載されるソフトウェアのパラメータ情報などの付帯管理情報をECU33から取得し、図５に示すデータ形式でゲートウェイ31の内部メモリに記憶し、ステップS305に進む。ステップS305では、ゲートウェイ31は、内部メモリに記憶したソフト管理情報、ハード管理情報、付帯管理情報を含むこれらのデータに、図５の#1に示すような車両の識別子を追記し、メッセージを作成してステップS306に進む。ステップS306では、ゲートウェイ31は、構成管理システムサーバ10に対し、通信装置32を介して作成したメッセージを送信する。

図４は、構成管理DBに格納されている構成情報の例を示す図である。また、図４の太枠箇所およびこれらをつなぐ矢印は、構成管理システムサーバ10が受け取った構成情報に含まれるハード管理情報、ソフト管理情報、付帯管理情報の関係を示している。構成管理システムサーバ10は、車両30が固有で持つ車両番号（VIN）41をルート情報として保持し、その下層にソフトウェアを搭載するハードウェアである（ECU）の識別情報ECU-ID42が紐付けられて保持される。各ハードウェアは複数のマイコンを有する場合は、更にECUの下層にマイコンの識別情報であるマイコンID43が紐付けられて保持される。更に各ECUやその下層のマイコン毎に、OSやミドルウェア、アプリケーションプログラムといったソフトウェアが搭載されて使用されるため，ECU-ID42やマイコンID43の下層に、ソフトウェアの識別情報であるソフトウェアID44が保持される。

図４では、例えば、OSを識別するためのソフトウェアIDとしてOS01が記憶され、アプリケーション２（App2）を識別するためのソフトウェアIDとしてapp2が記憶されている。

図４では特に示していないが、実際には、上述したソフト管理情報、付帯管理情報に記憶されているソフトウェアを実行するためのソフトウェアプログラムやパラメータ情報といった実体データが格納されているものとする。

図５は、図３で説明した車両30から送信されるメッセージの一例である。メッセージの内容は、図４で示した構成情報のうち、故障等の不具合を起こしたハードウェアとソフトウェアの組に関するものとなる。図４に示したApp2というソフトウェアが不具合を起こした場合を例に、メッセージの一例を示す。メッセージに記録される情報は、図４に示した不具合が発生した車両30の固有情報VINから、不具合が検出されたApp2に至るまでの階層ごとの情報が記録される。記録される内容は、各行に記録された情報が、固有番号、ハードウェア、ソフトウェアを区別するための種別51と、記録された情報の内容を示す名称52と、記録された内容を識別するための値（ID）53と、階層を構築する際に必要となる、各情報の上位にある名称52と値（ID）53の組からなる親情報54からなる。

図５では、例えば、不具合を検出したソフトウェアであるアプリケーションApp2の上位階層がST01により識別されるハードウェアであるマイコンST01であり、マイコンST01の上位階層がAD01により識別されるハードウェアであるECU-AD01であり、ECU-AD01の上位階層が010により識別される車両010であることを示している。

図６は、図２における類似車種一覧作成手順（ステップS105）を示すフローチャートである。ステップS601では、構成管理システムサーバ10は、車両30から図５に示したメッセージを受け取り、受け取ったメッセージに含まれるソフト管理情報を抽出し、ステップS602に進む。

ステップS602では、構成管理システムサーバ10は、メッセージのソフト管理情報に含まれるソフ
トウェア名およびソフトウェアID（例えば、図５では、名称：Application、値：app2）をキーに、ソフトリリース管理DB13の中から、同じソフトウェア名およびソフトウェアIDを含むソフトウェアを検索する。構成管理システムサーバ10は、同じソフトウェア名およびソフトウェアIDを含む同一および類似のソフトウェアに関する情報を全ての組み合わせについて取得して一覧を作成し、ステップS603に進む。同一のソフトウェアとは、例えば、同じソフトウェア名およびソフトウェアIDを含み、かつリリースされたバージョンに関する情報が同じソフトウェアである。また、類似のソフトウェアとは、例えば、同じソフトウェア名およびソフトウェアIDを含み、かつリリースされたバージョンに関する情報が異なるソフトウェアである。

図示は省略しているが、ソフトリリース管理DB13には、例えば、ソフトウェアを識別するためのソフトウェアID、ソフトウェア名、リリース時期、バージョン、利用形態、対象端末といったソフトウェアの構成に関する情報が記憶されている。利用形態は、ソフトウェアの利用形態であり、例えば、クラウド上でソフトウェアを利用する形態、ダウンロードしてソフトウェアを利用する形態がある。また、対象端末は、ソフトウェアの利用端末であり、例えば、ＰＣ(Personal Computer)かスマートフォンといった情報処理端末がある。

ステップS603では、構成管理システムサーバ10は、メッセージに含まれるハード管理情報を抽出し、ステップS604に進む。

ステップS604では、構成管理システムサーバ10は、ハード管理情報に含まれるハードウェア名やハードウェアIDをキーに、BOMDB14の中から、同じハードウェア名およびハードウェアIDを含むハードウェアを検索する。構成管理システムサーバ10は、同じハードウェア名およびハードウェアIDを含む同一および類似のハードウェアに関する情報を全ての組み合わせについて取得して一覧を作成し、ステップS605に進む。同一のハードウェアとは、例えば、同じハードウェア名およびハードウェアIDを含み、かつリリースされたバージョンに関する情報が同じハードウェアである。また、類似のハードウェアとは、例えば、同じハードウェア名およびハードウェアIDを含み、かつリリースされたバージョンに関する情報が異なるハードウェアのほか、異なるハードウェア名およびハードウェアIDであっても互換機、後継機に該当するハードウェアである。

図示は省略しているが、BOMDB14には、例えば、ハードウェアを識別するためのハードウェアID、ハードウェア名、リリース時期、バージョン、種別、互換機名、後継機名といったハードウェアの構成に関する情報が記憶されている。種別は、ハードウェアの分類であり、例えば、ECU、Sub Micro Computerがある。また、互換機名は、あるハードウェアと互換性があるハードウェアであり、例えば、ECU（A社、ハードウェアID：AD02）と記憶されている場合には、当該ハードウェアがA社のハードウェアIDが「AD02」で識別されるECUと互換性があることを示している。また、後継機名は、あるハードウェアの後継機となるハードウェアであり、例えば、ECU（B社、ハードウェアID：AD03）と記憶されている場合には、当該ハードウェアがB社のハードウェアIDが「AD03」で識別されるECUと互換性があることを示している。

したがって、構成管理システムサーバ10は、ハードウェア名およびハードウェアIDが異なるハードウェアであっても、互換機名、後継機名に記憶されているハードウェアに類似するハードウェアであるとして、上記一覧を作成する。

ステップS605では、構成管理システムサーバ10は、ステップS602、S604で作成されたハードウェアとソフトウェアの全ての組合せについて、構成管理DB11に対象車種の有無があるか否かの検索（ステップS606-S608）が終了したか否かを判定する。構成管理システムサーバ10は、全ての組み合わせについて検索が終わったと判定した場合（ステップS605;YES）には処理を終了し、終わってないと判定した場合（ステップS605;NO）はステップS606に進む。

ステップS606では、構成管理システムサーバ10は、ステップS602、S604で取得したハードウェア、ソフトウェアの情報の組み合わせをキーに構成管理DB11にアクセスし、対象車種の有無を検索し、ステップS607に進む。

ステップS607では、構成管理システムサーバ10は、ステップS606の結果を受け、対象車種が検索できたか否かを判定する。構成管理システムサーバ10は、検索できなかったと判定した場合は（ステップS607;NO）、ステップS605に戻る一方、対象車種が検索できたと判定した場合は（ステップS607;YES）、ステップS608に進む。

ステップS608では、構成管理システムサーバ10は、対象車種が検索できたと判定した場合、対象車種の情報を図７に示すリストに登録して、ステップS605に進む。

図７は、図６で説明した類似車種一覧の一例を示す図である。類似車種一覧の情報は、車両名71と、ハードウェア名72と、ハードウェアID73と、ソフトウェア名74と、ソフトウェアID75と、図５に示したメッセージに記録されているものと同一構成のものか、ソフトウェアやハードウェアのバージョン違い、互換機、後継機の違いである類似のものかを区
別する区別76の情報からなる。すなわち、区別76は、メッセージに記録されているソフト管理情報、ハード管理情報、付帯管理情報と同じソフト管理情報、ハード管理情報、付帯管理情報を含むデータであるか否かを識別するための情報であり、両者が同じ情報である場合には「当該」が記憶され、両者が異なる情報である場合には「関連」が記憶される。なお、車両名71は、図４に示した構成情報に含まれるVINに対応付けてあらかじめ定められている。図７では、最初のレコードと２番目のレコードの車両名が同じ「セダンＡ」であるが、互いに異なるVINにより識別される。

図８は、図２におけるテスト環境配布手順（ステップS107）を示すフローチャートである。

ステップS801では、構成管理システムサーバ10は、図７に示した類似車種一覧の全てのレコード
についてのソフトウェアプログラムやパラメータの配布が終了したか否かを判定する構成管理システムサーバ10は、全ての車両についてのソフトウェアプログラムやパラメータの配布が終了していると判定した場合（ステップS801;YES）、処理を終了する。一方、構成管理システムサーバ10は、全ての車両についてのソフトウェアプログラムやパラメータの配布が終了してないと判定した場合は（ステップS801:NO）、ステップS802に進む。

ステップS802では、構成管理システムサーバ10は、図７に示した類似車両一覧から、順番に一つのレコードをピックアップし、そのレコードに含まれる車両名をキーに、テスト車両管理DB12に対し、テスト可能な車両があるかを検索し、ステップS803に進む。テスト車両管理DB12には、テスト可能な車種の車両の車両名が、不具合再現環境24のテスト環境242や不具合原因調査端末23に対応付けて格納されているものとする。

ステップS803では、構成管理システムサーバ10は、ステップS802の結果を取得し、該当車両があるか否かを判定する。構成管理システムサーバ10は、該当車両があると判定した場合（ステップS803;YES）はステップS805に進み、該当車両が無いと判定した場合は（ステップS803;NO）ステップS804に進む。

ステップS804では、構成管理システムサーバ10は、ステップS802の結果を取得し、EIPF（Electronic Integrated PlatForm）などの仮想テスト環境にてテスト可能かを、仮想テスト環境管理DB16に対して検索して使用可能であるか否かを判定する。構成管理システムサーバ10は、は、仮想テスト環境が使用可能であると判定した場合（ステップS804;YES）はステップS805に進み、使用不可能であると判定した場合（ステップS804;NO）はステップS808に進む。仮想テスト環境管理DB16には、現在使用されておらず、仮想テスト環境の使用が可能な仮想テスト環境管理サーバ22のサーバ名やアクセス先が記憶されているものとする。また、仮想テスト環境管理サーバ22には、テスト車両と同じ構成情報を有した仮想的な車両の構成情報が記憶されており、プログラムやパラメータが配布された場合に、仮想環境で不具合再現テストを実行できるものとする。

ステップS805では、構成管理システムサーバ10は、不具合再現環境24にあるテスト車両241や仮
想テスト環境管理サーバ22に構築されている仮想テスト環境が使用可能状態にあるか否か
判定する。構成管理システムサーバ10は、使用可能状態にあると判定した場合は（ステップS805;YES）ステップS806に進み、使用可能状態でないと判定した場合は（ステップS805;NO）ステップS808に進む。不具合再現環境24にあるテスト車両241が使用可能状態にあるか否かの判定は、例えば、テスト車両管理DB12に不具合再現環境24のテスト車両241が記憶されている場合には使用可能と判断すればよい。仮想テスト環境が使用可能状態にあるか否かの判定は、例えば、仮想テスト環境管理サーバ22が仮想テスト環境管理DB16に記憶されている場合には使用可能と判断すればよい。

ステップS806、S807では、構成管理システムサーバ10は、図７に示したソフトウェア名とソフトウェアIDをキーに、構成管理DB11から該当するソフトウェアプログラムやパラメータを取得し、そのプログラムやパラメータを不具合再現環境24のテスト車両241（あるいは不具合原因調査端末23）や仮想テスト環境管理サーバ22に配布し、ステップS801に戻る。

ステップS808では、構成管理システムサーバ10が、ステップS804またはS805でNOと判定された場合、現時点ではすぐに使用できないため、テスト予約DB17に、テスト車両241のテスト車両管理DB12への登録の有無や仮想テスト環境管理サーバ22の空き時間を参照して、使用予約情報を登録して、ステップS801に戻る。上記空き時間は、例えば、仮想テスト環境管理DB16に記憶されている仮想テスト環境管理サーバ22のサーバ名やアクセス先とともに、仮想テスト環境管理サーバ22のスケジュールを記憶しておき、空き時間を判定すればよい。

図９は、不具合原因調査端末23や、ディーラ車両管理サーバ21から入力され、不具合報告DB15に保存されている不具合情報の一例を示す図である。この情報は、図２のステップS108で示した不具合情報の取得の際に使用される情報であり、気候、車両の走行状態・走行環境などの、異常車両に生じた不具合の発生条件を示す不具合発生条件が記憶されている。この情報は管理番号91と、不具合発生日時92と、不具合が発生した車両の固有番号VIN93と、不具合が発生した車両の名称94と、不具合が発生した車両の型式95と、不具合が発生した車両の原動機形式96と、内容97と、不具合が発生したハードウェアの名称98と、不具合が発生したハードウェアのID99と、不具合が発生したソフトウェアの名称910と、不具合が発生したソフトウェアのID911と、不具合が発生した時点の車両の走行距離912と、不具合が発生した際の走行ルート913と、不具合が顕在化した地点情報914と、不具合が発生した際の天気915と、不具合が発生した時の補足情報であるその他916を含む。これらの情報は、図２に示した処理とは別に、他のシステムにより収集され、不具合報告DB15に蓄積されている。

図１０は、図２のステップS109で示したテストレポートの一例を示す図である。テストレポートは、再現したい不具合の番号、題名、内容からなる管理情報1001と、不具合が発生した車両名、型式、原動機形式からなる車両情報1002と、VIN、ハードウェア名、ハードウェアID、ソフトウェア名、ソフトウェアIDからなる構成情報1003と、不具合発生時の
車両の走行距離、走行ルート、不具合顕在化地点、天気、補足情報からなる参考情報1004と、図２のステップS105における類似車両一覧取得で取得した関連車両情報からなる関連車両情報1005を含む。図１０では、構成管理システムサーバ10は、図９に示した不具合情報の最初のレコードに記憶されている情報（＃１）を読み取って管理情報1001、車両情報1002、構成情報1003、参考情報1004に記録するとともに、図７に示した類似車種一覧のうち区別76が「関連」である２番目、３番目、４番目のレコードに記憶されている情報（＃２、＃３、＃４）を読み取って関連車両情報1005に記録し、テストレポートとして出力したことを示している。図１０では、図７に示した類似車種一覧のうち区別76が「当該」である最初のレコードに記憶されている情報（＃１）についてテストレポートに含まれていないが、これをテストレポートに含めてもよい。構成管理システムサーバ10は、図２に示したステップS109において、これらの情報を含むテストレポートを、例えば、不具合原因調査端末23に送信し、不具合再現環境24での不具合再現試験の際に活用される。送信先としては、例えば、不具合原因調査端末23のメールアドレスをあらかじめ構成管理システムサーバ10に記憶させておけばよい。

通常、車両の不具合の再現は、不具合を発生したハードウェアやソフトウェアに関する情報だけでなく、気候、車両の走行状態・走行環境などの条件が複合的に重なり合うことで発生する。そのため、不具合が発生したあと、不具合を再現させる環境を構築する作業に非常に大きな工数を要するが、本実施例のように、テストレポートに図９に示したような不具合情報を含めることで、より一層不具合再現環境の構築を迅速化でき、不具合の再現を早めることができる。

上記実施例では、自動車メーカにおける不具合再現環境24におけるテスト車両や仮想テスト環境に対して構成管理DB11に保存されているソフトウェアプログラムを配布する例について述べた。しかし、配布先として、ディーラ（車両販売先）が不具合再現環境を有している場合には、当該ディーラで保有されている試乗車などのテスト車両241bやディーラの不具合原因調査端末23を用いて不具合再現テストを実行することが考えられる。この場合には、ディーラ車両管理サーバ21が、当該テスト車両241bをテスト車両管理DB12にテスト車両として登録する処理の実行を要求し、当該要求に従って、構成管理システムサーバ10が、その登録処理を実行すればよい。

このように、本実施例では、異常車両の不具合の再現を支援する不具合再現支援システム1000において、異常車両（例えば、車両30）から受信した構成情報であって異常が検知されたハードウェア（例えば、ECU33）のハードウェア情報を含む構成情報と、あらかじめ記憶部（例えば、テスト車両管理DB12）に記憶された車両の構成情報とに基づいて、異常車両のハードウェア情報と同じハードウェア情報を含む構成情報を取得する構成情報取得部（例えば、構成管理システムサーバ10のCPUが実行する構成情報取得プログラム）と、構成情報取得部により取得された構成情報に含まれるソフトウェア情報と同じソフトウェア情報を含むソフトウェアを記憶部（例えば、ソフトリリース管理DB13）から取得する構成情報判定部（例えば、構成管理システムサーバ10のCPUが実行する構成情報判定プログラム）と、構成情報判定部により取得されたソフトウェアを、不具合を再現するための不具合再現環境に配信する配信部（例えば、構成管理システムサーバ10のCPUが実行する配信プログラム）と、を備えるので、例えば、同じハードウェアの構成であってもソフトウェアの違いを考慮して再現テストを行うための環境を迅速に提供することができる。

また、上記構成情報判定部は、ソフトウェアのバージョンが異なるソフトウェア情報を記憶部（例えば、ソフトリリース管理DB13）から取得し、異常車両に類似する類似車種の構成情報（例えば、図７に示した類似車種一覧）として出力し、出力した構成情報のソフトウェア情報を含むソフトウェアを取得するので、同じソフトウェアであってもバージョンの違いを考慮して再現テストを行うための環境を迅速に提供することができる。

また、上記構成情報判定部は、ハードウェアの互換機または後継機となるハードウェアのハードウェア情報を記憶部（例えば、BOMDB14）から取得し、異常車両に類似する類似車種の構成情報（例えば、図７に示した類似車種一覧）として出力し、出力した構成情報のソフトウェア情報を含むソフトウェアを取得するので、同じハードウェアであっても互換機や後継機の違いを考慮して再現テストを行うための環境を迅速に提供することができる。

また、上記配信部は、あらかじめ記憶部（例えば、不具合報告DB15）に記憶された異常車両に生じた不具合の発生条件を示す不具合情報（例えば、図９に示した不具合情報）と、構成情報と、ソフトウェアとを不具合再現環境（例えば、不具合再現環境24や不具合原因調査端末23）に配信するので、再現テストを行うための周辺環境についての情報を提供することができ、不具合発生当時の状況を考慮した不具合の再現がより迅速に行うことができるようになる。

10 構成管理システムサーバ
11 構成管理データベース
12 テスト車両管理データベース
13 ソフトリリース管理データベース
14 BOMデータベース
15 不具合報告データベース
16 仮想テスト環境管理データベース
17 テスト予約データベース
20 テスト車両管理サーバ
21 ディーラ車両管理サーバ
22 仮想テスト環境管理サーバ
23 不具合原因調査端末
24 不具合再現環境
241 テスト車両
242 テスト環境
30 車両
31 ゲートウェイ
32 通信モジュール
33 ECU

Claims

異常車両の不具合の再現を支援する不具合再現支援システムであって、
前記異常車両から受信した構成情報であって異常が検知されたハードウェアのハードウェア情報を含む前記構成情報と、あらかじめ記憶部に記憶された車両の構成情報とに基づいて、前記異常車両のハードウェア情報と同じハードウェア情報を含む構成情報を取得する構成情報取得部と、
前記構成情報取得部により取得された構成情報に含まれるソフトウェア情報と同じソフトウェア情報を含むソフトウェアを記憶部から取得する構成情報判定部と、
前記構成情報判定部により取得されたソフトウェアを、前記不具合を再現するための不具合再現環境に配信する配信部と、
を備えることを特徴とする不具合再現支援システム。
前記構成情報判定部は、ソフトウェアのバージョンが異なるソフトウェア情報を前記記憶部から取得し、前記異常車両に類似する類似車種の構成情報として出力し、出力した構成情報のソフトウェア情報を含むソフトウェアを取得する、
ことを特徴とする請求項１に記載の不具合再現支援システム。
前記構成情報判定部は、前記ハードウェアの互換機または後継機となるハードウェアのハードウェア情報を前記記憶部から取得し、前記異常車両に類似する類似車種の構成情報として出力し、出力した構成情報のソフトウェア情報を含むソフトウェアを取得する、
ことを特徴とする請求項２に記載の不具合再現支援システム。
前記配信部は、あらかじめ前記記憶部に記憶された前記異常車両に生じた不具合の発生条件を示す不具合情報と、前記構成情報と、前記ソフトウェアとを前記不具合再現環境に配信する、
ことを特徴とする請求項３に記載の不具合再現支援システム。
異常車両の不具合の再現を支援する不具合再現支援方法であって、
構成情報取得部が、前記異常車両から受信した構成情報であって異常が検知されたハードウェアのハードウェア情報を含む前記構成情報と、あらかじめ記憶部に記憶された車両の構成情報とに基づいて、前記異常車両のハードウェア情報と同じハードウェア情報を含む構成情報を取得し、
構成情報判定部が、前記構成情報取得部により取得された構成情報に含まれるソフトウェア情報と同じソフトウェア情報を含むソフトウェアを記憶部から取得し、
配信部が、前記構成情報判定部により取得されたソフトウェアを、前記不具合を再現するための不具合再現環境に配信する、
を備えることを特徴とする不具合再現支援方法。
前記構成情報判定部が、ソフトウェアのバージョンが異なるソフトウェア情報を前記記憶部から取得し、前記異常車両に類似する類似車種の構成情報として出力し、出力した構成情報のソフトウェア情報を含むソフトウェアを取得する、
ことを特徴とする請求項５に記載の不具合再現支援方法。
前記構成情報判定部が、前記ハードウェアの互換機または後継機となるハードウェアのハードウェア情報を前記記憶部から取得し、前記異常車両に類似する類似車種の構成情報として出力し、出力した構成情報のソフトウェア情報を含むソフトウェアを取得する、
ことを特徴とする請求項６に記載の不具合再現支援方法。
前記配信部が、あらかじめ前記記憶部に記憶された前記異常車両に生じた不具合の発生条件を示す不具合情報と、前記構成情報と、前記ソフトウェアとを前記不具合再現環境に配信する、
ことを特徴とする請求項７に記載の不具合再現支援方法。