JP7490486B2

JP7490486B2 - ソフトウェア照会情報管理システム、及びソフトウェア照会情報管理方法

Info

Publication number: JP7490486B2
Application number: JP2020126962A
Authority: JP
Inventors: 岳彦長野
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2020-07-28
Filing date: 2020-07-28
Publication date: 2024-05-27
Anticipated expiration: 2040-07-28
Also published as: EP3945416B1; CN114003271A; JP2022024404A; US20220035621A1; EP3945416A1

Description

本発明は、ソフトウェア照会情報管理システム、及びソフトウェア照会情報管理方法に
関する。

特許文献１には、車両の設計過程において、デザインが法規制に合致するか確認する作
業に多大な労力を必要としている課題を解決することを目的として構成された車両設計支
援装置について記載されている。車両設計支援装置は、車両に取り付けられる部材ごとに
部材に関する法規制についての情報を格納する法規制情報格納手段と、車両の形状を定め
る車両形状情報を入力する手段と、車両に取り付けられる部材の形状及び部材の取り付け
位置を定める部材形状情報を入力する手段と、部材に関する部材関連法規制情報を法規制
情報格納手段から読み出し、部材が部材関連法規制情報に含まれる規制条件を満たすか否
かを判定する判定部と、判定部の判定結果に応じて、部材の表示形式を変えて表示させる
出力部とを備える。

特許文献２には、変更の影響範囲をファイルの部分まで特定できるようにすることを目
的として構成されたファイル管理装置について記載されている。ファイル管理装置は、第
１の表形式のファイルの第１の部分を特定する情報と、第２の表形式のファイルの第２の
部分を特定する情報との対応関係を記憶する記憶部と、第１の部分についての影響範囲の
検索依頼を受信すると、記憶部を参照して、第１の部分を特定する情報に対応づけられた
第２の部分を特定する情報を抽出し、検索依頼に対する応答として、第２の部分を特定す
る情報と第２の部分を含む第２の表形式のファイルを特定する情報とを出力する制御部と
を備える。

特許文献３には、分散して試験されている開発中の車載機器から、開発者が真に必要と
するログ情報を過不足なく効率的に取得することを目的として構成された車載機器ログ収
集システムに関して記載されている。車載機器ログ収集システムは、車載機器のログ情報
からログ情報のうち優先的な解析対象となるサマリ情報を抽出するための条件、及び、抽
出したサマリ情報をログ管理装置に送信する旨の指示が記載された解析スクリプトを車載
ログ収集装置に送信し、車載機器に不具合が発生した時点のログ情報をサマリ情報から抽
出するログ管理装置と、解析スクリプトに基づき、ログ情報からサマリ情報を抽出し、抽
出したサマリ情報、及び、不具合が発生した時点をログ管理装置に送信する車載ログ収集
装置と、を備える。

特開２００５－１７３７６１号公報特開２０１４－１３０５４７号公報特開２０１７－２２０１３５号公報

昨今、無線通信技術の進展により、自動車メーカ等の車両の提供者が、車両の製造時や
販売後に、ＯＴＡ（Over The Air）を介して、車両に搭載されているＥＣＵ（Electronic
Control Unit）等の機器へのソフトウェアの組み込みや更新（性能変更、機能変更、機
能追加等）を行うことが可能となっている。これにより車両の提供者は、例えば、将来的
な自動運転機能の追加等を見越した自動車の開発や生産、販売を行うことが可能になり、
今後は車両に搭載されているソフトウェアの更新機会は急増していくものと考えられる。

こうした状況に鑑み、ＷＰ２９（自動車基準調和世界フォーラム）においてソフトウェ
アの更新について国際基準の策定が進められている。ＷＰ２９では、例えば、ソフトウェ
アの更新が車両の型式認証（型式認可）に与える影響を評価しその結果を文書化すること
、ソフトウェアの更新が既に受けている型式認証の内容に影響を与える場合は当局（国土
交通省等）へ報告を行うこと、型式認証を受けている車載システムに組み込まれている一
つ以上のソフトウェアをバージョンレベルで区別して集約した番号を定義する概念（以下
、「ソフトウェア照会番号」と称する。）を導入すること、当局の要請に応じてソフトウ
ェアの更新に関連するエビデンス等の情報を提出すること等の制度化が検討されている。

上記の制度が開始された場合、車両の提供者は、車両に搭載されている多数の機器につ
いて、それらに組み込まれているソフトウェアに基づいたソフトウェア照会番号の付与や
、それらのソフトウェアを更新した際の型式認証に与える影響の分析、型式認証に関して
報告する必要のあるエビデンス等の取得を効率よく確実に行う必要がある。

しかし車両に搭載される機器の多くは通常はサプライヤ等の機器の供給者から車両の提
供者（ＯＥＭ）に供給されており、トレーサビリティ情報等のソフトウェアに関する情報
は供給者（サプライヤ）側で管理されているため、上記の制度への対応に際しては、車両
の提供者（ＯＥＭ）側で管理されている型式認証等の情報とソフトウェアに関する情報と
を関連づけるために煩雑な作業が発生することが予想される。

ここで上記の特許文献１に記載の車両設計支援装置は、車両に取り付けられる部材が部
材関連法規制情報に含まれる規制条件を満たすか否かを判定するが、機器の供給者側で管
理されている情報と車両の提供者側で管理されている情報とを統括的に管理する技術につ
いては何も開示されていない。

また、上記の特許文献２に記載のファイル管理装置は、変更の影響範囲をファイルの部
分まで特定するが、ソフトウェアを更新した際の型式認証に与える影響の分析や、型式認
証に関して報告する必要のあるエビデンスの具体的な取得方法についてはとくに言及して
いない。

また、上記の特許文献３に記載の車載機器ログ収集システムは、分散して試験されてい
る開発中の車載機器から、開発者が真に必要とするログ情報を取得するものであり、ソフ
トウェアを更新した際の型式認証に与える影響の分析や、型式認証に関して報告する必要
のあるエビデンスの取得方法については開示していない。

本発明はこのような背景に鑑みてなされたものであり、車両に搭載されている機器に組
み込まれるソフトウェアについての法定の認可に関する情報を効率よく管理し、ユーザが
必要とする情報を効率よく取得して提供することが可能な、ソフトウェア照会情報管理シ
ステム、及びソフトウェア照会情報管理方法を提供することを目的とする。

上記目的を達成するための本発明の一つは、車両に搭載される機器の機能を実現するソフトウェアについての法定の認可に関する情報を管理する情報処理システムであって、車両について法定の認可を受けるための要件を規定する法規を特定する情報である法規ＩＤに関連づけて、前記法規が前記機器に要求する仕様に関する情報である機器要求仕様を記憶し、前記機器要求仕様と関連づけられた機器のトレーサビリティに関する情報であるトレーサビリティ情報を記憶し、前記トレーサビリティ情報は、前記機器に組み込まれるソフトウェアを特定するソフトウェアＩＤを含み、取得した前記トレーサビリティ情報に関連づけられている前記機器要求仕様に対応する前記法規ＩＤと、一つ以上の前記ソフトウェアＩＤとを関連づける情報であるソフトウェア照会情報を生成し、前記機器に生じたイベントに関する情報であり、当該イベントが生じた前記機器を特定する情報と当該機器の機能を実現する前記ソフトウェアのソフトウェアＩＤとを対応づけた情報を含むイベント情報を記憶し、前記ソフトウェア照会情報に基づき、前記イベント情報における前記ソフトウェアＩＤに対応する前記法規ＩＤに関連づけられている他の前記ソフトウェアの前記ソフトウェアＩＤを特定し、前記トレーサビリティ情報に基づき、特定した前記ソフトウェアＩＤが組み込まれている前記機器を特定し、特定した前記機器が他の機器との間で行った通信の内容を含む通信データを前記機器の間を通信可能に接続する通信ネットワークに接続されたバストレーサにより取得し、前記通信データに基づき、前記法定の認可を受けるために必要なエビデンスを生成する。

その他、本願が開示する課題、及びその解決方法は、発明を実施するための形態の欄、
及び図面により明らかにされる。

本発明によれば、車両に搭載されている機器に組み込まれるソフトウェアについての法
定の認可に関する情報を効率よく管理し、ユーザが必要とする情報を効率よく取得して提
供することができる。

ソフトウェア照会情報を説明する図である。認可ソフトウェア照会情報の一例である。車両構成情報の一例である。（ａ）、（ｂ）は、トレーサビリティ情報の例である。ソフトウェア照会情報管理システムの概略的な構成を示す図である。ソフトウェア照会情報管理システムを構成する情報処理装置の例である。テスト履歴情報の一例である。テスト車両情報の一例である。不具合情報の一例である。ソフトウェア照会番号生成処理を説明するフローチャートである。トレーサビリティ情報とその変換を説明する図である。ソフトウェア更新管理処理を説明するフローチャートである。ソフトウェア照会情報参照処理を説明するフローチャートである。ソフトウェア照会情報管理画面の一例である。関連情報照会画面の一例である。ソフトウェア照会情報新規登録画面の一例である。ソフトウェア照会情報更新画面の一例である。ソフトウェア照会番号の更新要否判断ができなかった場合の表示例である。ソフトウェア照会情報管理システムの利用態様を説明する図である。エビデンスの取得に際して構築されるテスト環境の一例である。エビデンス生成処理を説明するフローチャートである。通信データ取得処理を説明するフローチャートである。通信データの例である。

以下、本発明の実施形態について図面を参照しつつ説明する。尚、以下の説明において
、同一の又は類似する構成について共通の符号を付して重複した説明を省略することがあ
る。また、共通の構成を有する複数の個体に共通の符号を付すとともに、当該符号に各個
体を区別するためアルファベット等の文字を付すことがある。

以下の説明において、「法規」とは、車両が型式認証等の保安基準を満たしているか否
かの認証（認可）を受けるために遵守する必要がある法令（法律、政令、規則等）をいう
。また、法規は日本国のものに限定されず、車両の輸出先（仕向国）における法規も含む
。

以下の説明において、「ソフトウェア」とは、ＥＣＵ（Electronic Control Unit）等
の情報処理装置に書き込まれた制御命令、及び制御命令の実行に必要なデータをいう。

以下の説明において、「ソフトウェアを機器に組み込む」とは、ソフトウェアを機器の
記憶素子に記録する（記憶させる、書き込む、ダウンロードする等）ことをいう。また、
以下の説明において、「情報を管理する」とは、情報をデータベース等に格納（記憶）し
、検索、更新、削除等の操作が可能な状態で管理することをいう。

以下の説明において、「トレーサビリティ」を「トレサビ」と略記することがある。ま
た以下の説明において、「エビデンス」とは、テスト結果、ソフトウェア実行結果（実行
ログ等）、レビュー結果等、車両の提供者が型式認証等に際して当局（国土交通省等）に
提出する関連資料のことをいう。

以下の説明において、車両の提供者（自動車メーカ等の車両の製造者、設計者、法規部
門の担当者等（ＯＥＭ））のことを「車両提供者」と称する。また、車両に搭載される機
器（ＥＣＵ等）や車両の外側で車両と連携するサーバ装置等の供給者（サプライヤ）のこ
とを「機器供給者」と称する。但し、車両提供者（ＯＥＭ）及び機器供給者（サプライヤ
）は、いずれも説明の便宜上定義した主体に過ぎず、以下に説明する各種構成の管理主体
や運用主体は必ずしも限定されない。

以下の説明において、作成主体を特に明示していない情報は、例えば、ユーザの入力操
作や既存の情報処理システムにより設定されるものとする。

＜ソフトウェア照会情報＞
車両に搭載されているＥＣＵ等の機器に組み込まれるソフトウェアに関して車両提供者
や機器供給者が管理する情報（以下、「ソフトウェア照会情報６」と称する。）について
説明する。

図１は、ソフトウェア照会情報６を説明する図である。同図に示すように、ソフトウェ
ア照会情報６は、車両提供者２側で管理される情報である認可ソフトウェア照会情報２１
、法規要求情報２２、車両要求仕様２３、車両構成情報２４、システム統合検証結果報告
書２５、適格性検証結果報告書２６、機器要求仕様３１、ソフトウェア３７、及びトレー
サビリティ情報２０を含む。また、ソフトウェア照会情報６は、機器供給者３Ａ～３Ｃ側
で管理される情報である、機器要求仕様３１、設計書３２、及びソースコード３３、ユニ
ット検証結果報告書３４、ＥＣＵ統合検証結果報告書３５、ＥＣＵ適格性検証結果報告書
３６、ソフトウェア３７、及びトレーサビリティ情報３０を含む。ソフトウェア照会情報
６は、車両のモデル等の一定のグループ毎に管理される。本実施形態では、ソフトウェア
照会情報６は、モデル毎に管理されるものとする。

同図に示す情報のうち、認可ソフトウェア照会情報２１は、認可を受けている法規と、
当該認可に関連したソフトウェアとの対応を示す情報である。

図２は、認可ソフトウェア照会情報２１を説明する図である。認可ソフトウェア照会情
報２１は、法規の識別子である法規ＩＤ２１１と、ソフトウェアが更新される等して当該
法規について認可が行われる度に新たに付与される識別子（各認可を区別する識別子）で
あるソフトウェア照会番号（認可識別子）２１２と、ソフトウェアの識別子であるソフト
ウェアＩＤ２１３と、ソフトウェアＩＤ２１３で示されるバイナリデータの完全性を検証
するためのデータである検証データＤ２１４と、を対応づけた情報を含む。上記のソフト
ウェアＩＤ２１３は、ソフトウェアの種類を特定する情報（ＥＣＵを識別するＩＤやモジ
ュールの名称等）、及びソフトウェアのバージョン情報（「v1.0」等）を含む。尚、ソフ
トウェアＩＤがバージョン情報のみを含み、ソフトウェアの種類を特定する情報について
は別に管理するようにしてもよい。このように認可ソフトウェア照会情報２１は、法規Ｉ
Ｄ、ソフトウェア照会番号、及び一つ以上のソフトウェアＩＤ（種類を特定する情報（名
称等）＋バージョン情報）の組合せからなるので、認可を受けている法規と当該認可に関
連したソフトウェアとの対応を、ソフトウェアをバージョンレベルで区別しつつ管理する
ことができる。

例示する認可ソフトウェア照会情報２１において、例えば、符号Ｄ２１Ａで示すレコー
ドの法規ＩＤ２１１には、協定規則第７９号（かじ取装置に係る車両の認可に関する統一
規定）第２シリーズであることを示す「R7902」が設定されている。また、当該レコード
には、当該法規に対応する機能を構成するソフトウェアの組合わせを示すソフトウェア照
会番号２１２として「R7902001」が設定されており、当該レコードは、当該ソフトウェア
の組み合わせを構成するソフトウェアのソフトウェアＩＤが「ECU-A v1.0」、「ECU-B v1
.0」、及び「ECU-C v1.0」であることを示している。

図１に戻り、法規要求情報２２は、認可にあたり法規が要求する内容を示す情報を含む
。同図には「R7902」に準拠するための法規要求情報２２として、「PREQ79-1」、「PREQ7
9-2」があることを例示している。これらは例えば、「最大15秒の経過後に運転者がステ
アリングコントロールを保持していなければ、光学警告を与えるものとする。」、「最大
30 秒の経過後に運転者がステアリングコントロールを保持していなければ、上記の信号
に加えて音響警告を与えるものとする。」等の要件に対応する。

車両要求仕様２３は、法規やその他の要求から導出された車両システムの要求仕様を示
す情報を含む。同図では、車両要求仕様２３として、「SREQ4」、「SREQ5」があることを
例示している。これらは例えば、前述の法規要求から導出される「最大15秒の経過後に運
転者がステアリングコントロールを保持していなければ、光学警告を与えるものとする。
」、「最大30 秒の経過後に運転者がステアリングコントロールを保持していなければ、
上記の信号に加えて音響警告を与えるものとする。」等の要件に対応する。

車両構成情報２４は、車両システムを構成するためのアーキテクチャやＥＣＵ構成、モ
デル等の情報を含む。

図３は、車両構成情報２４に含まれる情報の一例である。例示する車両構成情報２４は
、車両のモデル毎に付与される識別子であるモデルＩＤをルートとして、車両に搭載され
ている機器の識別子である機器ＩＤを階層的（ツリー状）に管理した構造を有する。例示
する車両構成情報２４により、モデルＩＤと当該モデルＩＤのモデルを構成する機器ＩＤ
の対応をとることができる。尚、図１に示した機器供給者３Ａ～３Ｃが管理する情報（機
器要求仕様３１や設計書３２等）にも、通常はモデルＩＤや機器ＩＤが付与されているの
で、これらの情報と車両構成情報２４との対応をとることができる。

図１に示すシステム統合検証結果報告書２５は、車両要求仕様２３、車両構成情報２４
で規定した設計内容の検証に関する各種の情報（テスト仕様書、テスト結果報告等）を含
む。同図では、システム統合検証結果報告書２５として「TRSREQ 4」、「TRSREQ 5」等が
あることを例示している。

適格性検証結果報告書２６は、法規要求情報２２で規定された機能の適格性検証に関す
る各種の情報（テスト仕様書、テスト結果報告等）を含む。同図では、適格性検証結果報
告書２６として「TRPREQ 79-1」、「TRPREQ 79-2」等があることを例示している。

機器要求仕様３１は、車両要求仕様２３と車両構成情報２４に基づき、車両に搭載され
る機器の仕様について要求する内容を示す情報を含む。同図では、「ECU-A」の機器要求
仕様３１として、「REQ A-1」、「REQ A-2」、「REQ A-3」等があることを例示している
。これらは例えば、前述の車両要求仕様２３「SREQ4」から導出される「検出すること（1
5秒）」、「検出すること（30秒）」、及び「ECU-Bに通知すること」に対応する。同図は
他にも、車両要求仕様２３を実現するためにECU-B、ECU-C向けの機器要求仕様があること
を示している。機器要求仕様３１は、車両提供者２が規定し、機器供給者に開示する。Ｅ
ＣＵへの全体要件（例えば「ECU-A要件 v1.0」）は、これらの機器要求仕様（「REQ A-1
」、「REQ A-2」、「REQ A-3」）の組合せで構成される。機器供給者３から車両提供者２
に提示されるソフトウェアは、この要求と対応付けられて管理され、例えば、提供される
ソフトウェアが１つのバイナリデータの場合、ＥＣＵへの全体要件と対応付けられる。

設計書３２は、機器の設計に関する各種の情報（基本設計書、詳細設計書、テスト仕様
書、テスト結果等）を含む。同図では、ＥＣＵの設計書３２（「ECU-A設計書」）として
、「DSN A-1」、「DSN A-2」、「DSN A-2」等からなる設計内容が管理されていることを
例示している。

ソースコード３３は、機器に組み込まれるソフトウェアのソースコードである。同図で
は、ソースコード３３として、複数の関数またはクラス（「Func A-1」、「FuncA-2」、
「FuncA-3」）等からなるソースコード「a1.c」等が管理されていることを例示している
。

ユニット検証結果報告書３４は、関数レベルの検証に関する各種の情報（テスト仕様書
、テスト結果報告等）を含む。同図では、ユニット検証結果報告として、「TRfunc A-1」
、「TRfunc A-2」、「TRfunc A-3」等があることを例示している。

ＥＣＵ統合検証結果報告書３５は、設計書３２で規定した設計内容の検証に関する各種
の情報（テスト仕様書、テスト結果報告等）を含む。同図では、ＥＣＵ統合検証結果報告
として、「TRDSN A-1」、「TRDSN A-2」、「TRDSN A-3」等があることを例示している。

ＥＣＵ適格性検証結果報告書３６は、機器要求仕様３１で規定された機能の適格性検証
に関する各種の情報（テスト仕様書、テスト結果報告等）を含む。同図では、ＥＣＵ統合
検証結果報告として、「TRREQ A-1」、「TRREQ A-2」、「TRREQ A-3」等があることを例
示している。

ソフトウェア３７は、機器要求仕様３１に基づき作成されたソフトウェアを含む。ソフ
トウェアは、機器供給者３によって作成され、車両提供者２に提供される。ソフトウェア
には、制御命令が記述されたバイナリコードと当該制御命令の実行に利用されるデータ（
キャリブレーションデータ等）、それらの完全性を検証するための検証データを含む。ソ
フトウェア３７は、機器供給者３のソースコード３３をコンパイルすることにより生成さ
れる。

トレーサビリティ情報２０は、車両提供者２によって作成／管理される情報（以下、「
成果物」と称する。）間を関連づける情報である。トレーサビリティ情報２０には、法規
要求情報２２と車両要求仕様２３の関連、車両要求仕様２３と機器要求仕様３１の関連、
法規要求情報２２と適格性検証結果報告書２６の関連、車両要求仕様２３と適格性検証結
果報告書２６の関連等がある。

トレーサビリティ情報３０は、機器供給者３によって作成され管理される成果物間を関
連づける情報である。トレーサビリティ情報３０には、機器要求仕様３１と設計書３２の
関連、設計書３２とソースコード３３の関連、ソースコード３３とユニット検証結果報告
書３４、設計書３２とＥＣＵ統合検証結果報告書３５の関連、機器要求仕様３１とＥＣＵ
適格性検証結果報告書３６の関連、機器要求仕様３１とソフトウェア３７の関連等がある
。

図４に、トレーサビリティ情報の例（トレーサビリティ情報２０，３０）を示す。例え
ば、図４（ａ）に例示するトレーサビリティ情報２０は、車両要求仕様２３と機器要求仕
様３１の関連を示し、符号２０ａのレコードは、車両要求仕様「SREQ4 v1.0」が、機器要
求仕様「REQ A-1 v1.0」、「REQ A-2 v1.0」、「REQ B-2 v1.0」、「REQ B-3 v1.0」、「
REQ C-1 v1.0」、「REQ C-2 v1.0」によって満足されることを示す。

また、図４（ｂ）に例示するトレーサビリティ情報３０は、設計書３２とソースコード
３３の関連を示し、符号３０ａのレコードは、設計「DSN A-1 v1.0」が、関数「FUNC A-1
v1.0」で実装されていることを示す。トレーサビリティ情報２０では、要求仕様等は夫
々ＩＤが付与され、ＩＤ間の関連が示される。このようなトレーサビリティ情報の表現例
としては、同図に例示した表形式等がある。

図１に示した情報は、例えば、車両モデル単位で管理される。図１では、「ECU-A」の機
器供給者３の管理情報の例（機器供給者３Ａの情報）について説明したが、機器要求仕様
３１、設計書３２、及びソースコード３３、ユニット検証結果報告書３４、ＥＣＵ統合検
証結果報告書３５、ＥＣＵ適格性検証結果報告書３６、及びソフトウェア３７は、機器供
給者３毎に作成され、管理される。例えば、「ECU-B」、「ECU-C」の機器供給者３は夫々
、機器供給者３Ｂの情報、機器供給者３Ｃの情報を管理する。

＜ソフトウェア照会情報管理システム＞
続いて、一実施形態として示す情報処理システム（以下、「ソフトウェア照会情報管理
システム１」と称する。）について説明する。

図５にソフトウェア照会情報管理システム１の概略的な構成を示している。ソフトウェ
ア照会情報管理システム１は、図１に示したソフトウェア照会情報６を管理するシステム
であり、車両提供者２側で管理される情報処理システムである車両提供者システム１００
、個々の機器供給者３Ａ～３Ｃ側で管理される情報処理システムである一つ以上の機器供
給者システム２００、テスト車両管理装置３００、ソフトウェア配信装置４００、及びテ
スト結果解析装置５００を含む。これらのシステムや装置は、いずれも一つ以上の情報処
理装置を用いて構成されている。尚、図１に示したソフトウェア照会情報６のうち同図に
明示していない情報は、車両提供者システム１００または機器供給者システム２００にお
いて、データベース等を用いて検索、更新、削除等の操作が可能な状態で管理されている
ものとする。

車両提供者システム１００と機器供給者システム２００は、通信ネットワークを介して
通信可能に接続されている。また、車両提供者システム１００は、テスト車両管理装置３
００、ソフトウェア配信装置４００、及びテスト結果解析装置５００と通信ネットワーク
を介して通信可能に接続されている。上記の各通信ネットワークは、有線又は無線方式の
通信基盤を用いて構成され、例えば、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Are
a Network）、ＣＡＮ（Controller Area Network）、インターネット、専用線、各種公衆
通信網等である。

図６に車両提供者システム１００、機器供給者システム２００、テスト車両管理装置３
００、ソフトウェア配信装置４００、及びテスト結果解析装置５００を構成する情報処理
装置（コンピュータ）のハードウェア構成例を示している。例示する情報処理装置１０は
、プロセッサ１１、主記憶装置１２、補助記憶装置１３、入力装置１４、出力装置１５、
及び通信装置１６を備える。これらは図示しないバス（bus）等の通信手段を介して通信
可能に接続されている。

情報処理装置１０は、例えば、デスクトップ型のパーソナルコンピュータ、オフィスコ
ンピュータ、メインフレーム、移動通信端末（スマートフォン、タブレット、ウェアラブ
ル端末、ノートブック型のパーソナルコンピュータ等である。情報処理装置１０には、例
えば、オペレーティングシステム、デバイスドライバ、ファイルシステム、ＤＢＭＳ（Da
taBase Management System）（リレーショナルデータベース、ＮｏＳＱＬ等）等が導入さ
れていてもよい。また、情報処理装置１０は、例えば、クラウドシステムにより提供され
るクラウドサーバのように仮想的な情報処理資源を用いて実現されるものであってもよく
、車両提供者システム１００や機器供給者システム２００はクラウドサービスとして提供
されるものであってもよい。

プロセッサ１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Pro
cessing Unit）、ＧＰＵ（Graphics Processing Unit）、ＡＩ（Artificial Intelligenc
e）チップ、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Spec
ific Integrated Circuit）等を用いて構成されている。

主記憶装置１２は、プログラムやデータを記憶する装置であり、例えば、ＲＯＭ（Read
Only Memory）、ＲＡＭ（Random Access Memory）、不揮発性メモリ（ＮＶＲＡＭ（Non
Volatile RAM））等である。

補助記憶装置１３は、例えば、ＳＳＤ（Solid State Drive）、ハードディスクドライ
ブ、光学式記憶装置（ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）等）、
ストレージシステム、ＩＣカード、ＳＤカードや光学式記録媒体等の記録媒体の読取／書
込装置、クラウドサーバの記憶領域等である。補助記憶装置１３には、記録媒体の読取装
置や通信装置１６を介してプログラムやデータを読み込むことができる。補助記憶装置１
３に格納（記憶）されているプログラムやデータは主記憶装置１２に随時読み込まれる。

入力装置１４は、外部からの入力を受け付けるインタフェースであり、例えば、キーボ
ード、マウス、タッチパネル、カードリーダ、音声入力装置等である。

出力装置１５は、処理経過や処理結果等の各種情報を出力するインタフェースである。
出力装置１５は、例えば、上記の各種情報を可視化する表示装置（液晶モニタ、ＬＣＤ（
Liquid Crystal Display）、グラフィックカード等）、上記の各種情報を音声化する装置
（音声出力装置（スピーカ等））、上記の各種情報を文字化する装置（印字装置等）であ
る。出力装置１５は、入力装置１４とともにユーザインタフェースを構成する。

尚、例えば、情報処理装置１０が通信装置１６を介して他の装置（スマートフォン、タ
ブレット、ノートブック型コンピュータ、各種携帯情報端末等）と情報の入力や出力を行
う構成としてもよい。

通信装置１６は、他の装置との間の通信を実現する。通信装置１６は、通信ネットワー
クを介した他の装置との間の通信を実現する、無線方式又は有線方式の通信インタフェー
スであり、例えば、ＮＩＣ（Network Interface Card）、無線通信モジュール、ＵＳＢ（
Universal Serial Bus）モジュール、シリアル通信モジュール等である。

図５に戻り、各システムや装置が備える機能について説明する。車両提供者システム１
００は、トレーサビリティ情報管理部１１０、情報管理部１１１、法規情報管理部１１２
、トレーサビリティ情報変換部１１３、情報統合部１１４、ソフトウェア照会番号生成部
１１５、ソフトウェア照会情報管理部１１６、テスト関連情報管理部１１８、不具合情報
管理部１１９、及びソフトウェア更新管理部１２５を備える。これらの機能は、車両提供
者システム１００を構成する情報処理装置１０のプロセッサ１１が、主記憶装置１２に格
納されているプログラムを読み出して実行することにより、もしくは、情報処理装置１０
のハードウェア（ＦＰＧＡ、ＡＳＩＣ、ＡＩチップ等）により実現される。

トレーサビリティ情報管理部１１０は、機器供給者システム２００から送られてくるト
レーサビリティ情報（後述のトレーサビリティ情報３０’）を受信して管理する。また、
トレーサビリティ情報管理部１１０は、図１に示した、車両提供者２が生成するトレーサ
ビリティ情報２０を管理する。

情報管理部１１１は、図１に示した車両要求仕様２３、車両構成情報２４、機器要求仕
様３１、ソフトウェア３７、システム統合検証結果報告書２５、及び適格性検証結果報告
書２６を管理する。尚、これらの情報は、情報管理部１１１が、複数のエンジニアリング
ツールによって別々に管理する構成としてもよいし、一つのエンジニアリングツールによ
って統合的に管理する構成としてもよい。要は、情報管理部１１１が必要とされる情報を
必要なときに提供できる構成であればよい。

法規情報管理部１１２は、車両の型式認証に際して適用される法規に関する情報（以下
、「法規情報１１２１」と称する。）を管理する。法規情報１１２１は、法規要求情報２
２、当局への届出書類のテンプレート、及び届出済み書類等を含む。法規情報管理部１１
２は、日本国だけでなく、日本国以外の車両の輸出先（仕向国）の法規情報も管理する。
仕向国情報で特定される輸出先の法規情報から、輸出先において型式認証を取得するため
に必要な情報を得ることができる。

トレーサビリティ情報変換部１１３は、機器供給者３が作成した形式で作成されたトレ
ーサビリティ情報３０’を読み出し、車両提供者が利用可能な共通の表現形式（以下、「
共通形式」とも称する。）に変換する。上記共通形式として、例えば、ＲＤＦ（Resource
description Framework）がある。

情報統合部１１４は、共通形式に変換されたトレーサビリティ情報３０’とトレーサビ
リティ情報２０とに基づき、車両提供者システム１００及び機器供給者システム２００の
夫々において管理される情報（情報管理部１１１、及び法規情報管理部１１２の夫々が管
理する情報）を関連づけることにより、法規要求情報２２、車両要求仕様２３、機器要求
仕様３１、設計書３２、ソースコード３３、及び法規要求情報２２を関連づけた情報に法
規ＩＤを関連づけた情報である車両トレーサビリティ情報４０（図１に示したソフトウェ
ア照会情報６の全部または一部に相当する情報）を生成する。このように、ＲＤＦ形式等
の共通形式でトレーサビリティ情報を管理することにより、ＳＰＡＲＱＬ（Protocol and
RDF Query Language）等の問い合わせ言語を利用することが可能になり、多角的で柔軟
な検索が可能な検索システムを容易に実現することができる。

ソフトウェア照会番号生成部１１５は、車両トレーサビリティ情報４０に基づき認可ソ
フトウェア照会情報２１を生成する。

ソフトウェア照会情報管理部１１６は、情報統合部１１４が生成した車両トレーサビリ
ティ情報４０と、ソフトウェア照会番号生成部１１５が生成した認可ソフトウェア照会情
報２１（図１の認可ソフトウェア照会情報２１に相当）とを関連づけて管理する。これに
よりソフトウェア照会情報６のうち機器に組み込まれるソフトウェアに関する情報がソフ
トウェア照会番号及び法規ＩＤと関連づけられる。また、ソフトウェア照会情報管理部１
１６は、ユーザからの要求に応じて車両トレーサビリティ情報４０を検索し、検索した結
果をユーザに返す。ソフトウェア照会情報管理部１１６の詳細については後述する。

テスト関連情報管理部１１８は、車両に搭載されている機器について開発時や以前の保
守時等の過去に行ったテストに関する情報（過去に実施したテストの履歴に関する情報（
以下、「テスト履歴情報１１８１」と称する。）や、過去に実施したテストで用いた車両
に関する情報（以下、「テスト車両情報１１８２」と称する。）を管理する。テスト関連
情報管理部１１８は、ソフトウェア照会情報管理部１１６に、管理しているテスト履歴情
報１１８１やテスト車両情報１１８２に基づく情報であるテスト情報４１を随時提供する
。

図７にテスト履歴情報１１８１の一例を示す。例示するテスト履歴情報１１８１は、テ
ストＩＤ８１１、テスト内容８１２、テスト車両構成８１３、ソフトウェア照会番号８１
４、使用治具８１５、テスト実施者８１６、テスト結果８１７、及びエビデンス８１８の
各項目を有する一つ以上のレコードで構成される。

上記項目のうち、テストＩＤ８１１には、車両について実施したテスト毎に付与される
識別子であるテストＩＤが設定される。テスト内容８１２には、当該テストの内容を示す
情報が設定される。テスト車両構成８１３には、テスト車両の構成を示す情報（テスト車
両のモデルＩＤ、テスト車両に搭載されている機器の機器ＩＤ、当該機器に組み込まれて
いるソフトウェアのソフトウェアＩＤ等）が設定される。ソフトウェア照会番号８１４に
は、当該テストに関連づけられたソフトウェア照会番号が設定される。使用治具８１５に
は、当該テストに際して使用した治具を示す情報が設定される。テスト実施者８１６には
、当該テストの実施者の氏名が設定される。テスト結果８１７には、当該テストの結果を
示す情報が設定される。エビデンス８１８には、当該テストを実施した際に取得されたエ
ビデンスの実体やエビデンスの所在（ＵＲＬ等の格納場所を示す情報）が設定される。尚
、エビデンスは、テスト結果解析装置５００によって生成され、ソフトウェア照会情報管
理部１１６を介してユーザに提供される。エビデンスの具体的な生成方法については後述
する。

図８にテスト車両情報１１８２の一例を示す。例示するテスト車両情報１１８２は、モ
デルＩＤ８２１、車両名８２２、及び配置拠点８２３の各項目を有する一つ以上のレコー
ドで構成される。テスト車両情報１１８２の一つのレコードは一台のテスト車両に対応す
る。

上記項目のうち、モデルＩＤ８２１には、当該車両のモデルＩＤが設定される。車両名
８２２には、当該車両の名称が設定される。配置拠点８２３には、当該車両の配置拠点を
示す情報が設定される。

図５に戻り、不具合情報管理部１１９は、車両に搭載されている機器に発生した不具合
（イベント）に関する情報（以下、「不具合情報１１９１」と称する。）を管理する。不
具合情報管理部１１９は、ソフトウェア照会情報管理部１１６やテスト結果解析装置５０
０に、不具合情報１１９１（イベント情報）を随時提供する。不具合情報管理部１１９は
、例えば、実際の車両やテスト環境と通信することにより不具合情報を取得する。但し、
不具合情報の取得方法は必ずしも限定されない。

不具合情報１１９１は、例えば、法規情報１１２１に含まれている当局への届出書類の
テンプレートを利用して作成される。機器に組み込まれるソフトウェアの更新は、例えば
、不具合情報１１９１に登録された不具合の対処を目的として行われる。不具合情報１１
９１は、例えば、車両のテスト時におけるユーザへの不具合の内容の提示やテスト実施後
のエビデンスの生成に用いられる。

図９に不具合情報１１９１の一例を示す。例示する不具合情報１１９１は、不具合ＩＤ
９１１、日時９１２、車両ＩＤ９１３、車両名９１４、モデルＩＤ９１５、原動機型式９
１６、内容９１７、機器名９１８、機器ＩＤ９１９、ソフトウェア名９２１、ソフトウェ
アＩＤ９２２、走行距離９２３、走行ルート９２４、不具合顕在化地点９２５、天気９２
６、及び補足情報９２７の各項目を有する一つ以上のレコードで構成される。

上記項目のうち、不具合ＩＤ９１１には、車両に発生した不具合毎に付与される識別子
である不具合ＩＤが設定される。日時９１２には、当該不具合が発生した日時が設定され
る。車両ＩＤ９１３には、当該不具合が発生した車両（以下、「当該車両」と称する。）
の識別子である車両ＩＤが設定される。車両名９１４には、当該車両の車両名が設定され
る。モデルＩＤ９１５には、当該車両のモデルＩＤが設定される。原動機型式９１６には
、当該車両に搭載されている原動機の型式が設定される。内容９１７には、当該不具合の
内容を示す情報が設定される。機器名９１８には、当該不具合が発生した機器（以下、「
当該機器」と称する。）の名称が設定される。機器ＩＤ９１９には、当該機器の機器ＩＤ
が設定される。

ソフトウェア名９２１には、当該機器に組み込まれているソフトウェアの名称が設定さ
れる。ソフトウェアＩＤ９２２には、当該機器に組み込まれているソフトウェアのソフト
ウェアＩＤが設定される。走行距離９２３には、当該車両の総走行距離が設定される。走
行ルート９２４には、当該不具合が生じた際の当該車両の走行ルートを示す情報が設定さ
れる。不具合顕在化地点９２５には、当該不具合が顕在化した地点を示す情報が設定され
る。天気９２６には、当該不具合が発生した際の天気（天候）を示す情報が設定される。
補足情報９２７には、当該不具合に関する補足情報（証拠に関する情報等）が設定される
。

ソフトウェア更新管理部１２５は、車両に搭載される機器に組み込まれているソフトウ
ェアが更新された場合に、車両トレーサビリティ情報４０や認可ソフトウェア照会情報２
１の更新に関する処理を行う。また、ソフトウェア更新管理部１２５は、ユーザからソフ
トウェアを指定するキー情報（例えば、ソースコードに記述されている関数やクラスの識
別子（以下、「関数ＩＤ」と称する。）、法規ＩＤ、ソフトウェア照会番号、ソフトウェ
アＩＤ等）等を受け付け、受け付けたキー情報を含むソースコードを含むソフトウェア照
会情報６（車両トレーサビリティ情報４０）を特定し、特定したソフトウェア照会情報６
に関する情報をユーザに提供する。ユーザは、上記情報を参照することで、例えば、再認
可を受ける必要のある対象（ソフトウェア、機器、法規等）や認可を受けるために必要な
テスト（検証）に関する情報、テスト結果（エビデンス等）に関する情報等を容易かつ迅
速に得ることができる。

続いて、図５に示した機器供給者システム２００の機能について説明する。同図に示す
ように、機器供給者システム２００は、情報管理部２０１、トレーサビリティ情報管理部
２０２、及びトレーサビリティ情報変換送信部２０３を備える。これらの機能は、機器供
給者システム２００を構成する情報処理装置１０のプロセッサ１１が、主記憶装置１２に
格納されているプログラムを読み出して実行することにより、もしくは、情報処理装置１
０のハードウェア（ＦＰＧＡ、ＡＳＩＣ、ＡＩチップ等）により実現される。

図５に示す情報管理部２０１は、図１に示した、機器要求仕様３１、設計書３２、及び
ソースコード３３、ユニット検証結果報告書３４、統合検証結果報告書３５、適格性検証
結果報告書３６、ソフトウェア３７等（一部のみ図示）のソフトウェア照会情報６の全部
又は一部（成果物）を管理する。情報管理部１１１は、複数のエンジニアリングツールに
よって別々に管理されていてもよいし、一つのエンジニアリングツールによって統合的に
管理されていてもよく、必要なときに必要な情報が参照できる構成になっていればよい。

トレーサビリティ情報管理部２０２は、図１に示したトレーサビリティ情報３０を管理
する。

トレーサビリティ情報変換送信部２０３は、トレーサビリティ情報管理部２０２が管理
するトレーサビリティ情報３０を、車両提供者システム１００に送信する。この際、機器
供給者３側で管理されたトレーサビリティ情報（トレーサビリティ情報３０）のうち機器
供給者３Ａ～３Ｃ側で秘匿化しておきたい情報（例えば、ソースコードの秘匿化しておき
たい部分（関数名等））を変換（暗号化や別のコードで置換する等）し、トレーサビリテ
ィ情報３０’として車両提供者システム１００に送信するようにしてもよい。このように
情報を変換することで、機器供給者３の情報を秘匿したまま、要求からソースコードまで
のトレーサビリティ情報を生成することができる。変換を行う際、トレーサビリティ情報
変換送信部２０３は、例えば、トレーサビリティ情報３０とトレーサビリティ情報３０’
の変換テーブル３８を生成し保存する。機器供給者３が車両提供者２から情報提供が要求
された場合、トレーサビリティ情報変換送信部２０３は、例えば、変換テーブル３８によ
りデータを逆変換し、必要なデータを参照する。

図５に示すテスト車両管理装置３００は、車両について認可に関するテスト（検証）を
実施する際に用いる車両であるテスト車両の提供に関する情報処理（テスト車両の構成に
関する情報の管理、テスト車両の予約処理等）を行う。

図５に示すソフトウェア配信装置４００は、車両に搭載されているゲートウェイ装置や
サーバ装置と通信し、車両に搭載されている機器へのソフトウェアの配信やソフトウェア
の実行に関する処理を行う。また、ソフトウェア配信装置４００は、ソフトウェアの実行
結果をテスト結果解析装置５００に提供する。また、ソフトウェア配信装置４００は、車
両提供者システム１００と通信し、車両に搭載される機器へのソフトウェアの組み込みに
関する各種の情報処理（組み込みに用いる治具に関する情報の管理、治具の予約、治具へ
のソフトウェアの送信等）を行う。

図５に示すテスト結果解析装置５００は、ソフトウェア配信装置４００から提供される
ソフトウェアの実行結果を解析する。また、テスト結果解析装置５００は、後述するバス
トレーサ６０から送られてくる、機器間で行われる通信のデータ（通信データ）に基づき
エビデンスを生成する。テスト結果解析装置５００は、車両提供者システム１００と通信
ネットワークを介して通信することにより、車両提供者システム１００において管理され
ている情報（認可ソフトウェア照会情報２１、不具合情報１１９１等）を随時取得する。

続いて、ソフトウェア照会情報管理システム１において行われる処理について説明する
。

＜ソフトウェア照会情報の生成処理＞
図１０は、ソフトウェア照会情報６（車両トレーサビリティ情報４０、認可ソフトウェ
ア照会情報２１）の生成に際し車両提供者システム１００において行われる処理（以下、
「ソフトウェア照会情報生成処理Ｓ１０００」と称する。）を説明するフローチャートで
ある。以下、同図とともにソフトウェア照会情報生成処理Ｓ１０００について説明する。

尚、ソフトウェア照会情報生成処理Ｓ１０００の開始時において、トレーサビリティ情
報管理部１１０は、トレーサビリティ情報２０（車両提供者２が生成するトレーサビリテ
ィ情報）、及びトレーサビリティ情報３０’（機器供給者システム２００から取得したト
レーサビリティ情報３０’）を管理しているものとする。また、上記開始時において、情
報管理部１１１は、車両要求仕様２３、機器要求仕様３１等の情報を管理しているものと
する。また、上記開始時において、法規情報管理部１１２は、予めユーザ等により設定さ
れた法規情報１１２１を管理しているものとする。

同図に示すように、まずトレーサビリティ情報変換部１１３が、機器供給者（サプライ
ヤ）が作成した形式のトレーサビリティ情報３０’を読み出し、共通形式に変換する（Ｓ
１０１１）。

図１１は、トレーサビリティ情報３０’とその変換を説明する図である。トレーサビリ
ティ情報３０’は、図４に例示したトレーサビリティ情報３０がトレーサビリティ情報変
換送信部２０３によって変換されたものである。例示したトレーサビリティ情報３０’の
レコードであるトレーサビリティ情報３０’ａは、機器要求仕様「REQ A-1 v1.0」が、設
計「DSN yyy v1.0」と設計「DSN zzz v1.0」により満足されることを示している。尚、「
DSN yyy v1.0」と設計「DSN zzz v1.0」は、トレーサビリティ情報変換送信部２０３によ
る変換後の表現である。

同図に示すトレーサビリティ情報３０’’は、トレーサビリティ情報変換部１１３によ
って変換された共通形式（ＲＤＦ形式）の情報である。ＲＤＦ型式を用いた場合、情報は
主語／述語／目的語からなる文で表現される。例示するトレーサビリティ情報３０’’で
は、「REQ A v1.0」が主語、「DSN yyy v1.0」と設計「DSN zzz v1.0」が目的語、「REQ
A v1.0」が「DSN yyy v1.0」と設計「DSN zzz v1.0」により満足されることを示す「sati
sfiedby」が述語である。また、ＲＤＦでは、これらの情報をＵＲＩ（Uniform Resource
Identifier）で表現する。このように、ＲＤＦ形式で共通的にトレーサビリティ情報を管
理することによって、問い合わせ言語ＳＰＡＲＱＬ等を利用することが可能になり、関連
する情報の検索が容易になる。

図１０に戻り、次に、情報統合部１１４が、共通形式に変換されたトレーサビリティ情
報３０’’とトレーサビリティ情報２０に基づき、車両提供者システム１００及び機器供
給者システム２００の夫々において管理される情報（情報管理部１１１、及び法規情報管
理部１１２の夫々が管理する情報）を関連づけることにより、法規要求情報２２、車両要
求仕様２３、機器要求仕様３１、設計書３２、ソースコード３３、ソフトウェア３７他、
及び法規要求情報２２を関連づけた情報に法規ＩＤを関連づけた情報である車両トレーサ
ビリティ情報４０を生成する（Ｓ１０１２）。

続くループ処理Ｓ１０１３Ｓ～Ｓ１０１３Ｅでは、ソフトウェア照会番号生成部１１５
が、認可ソフトウェア照会情報２１を生成する。ソフトウェア照会番号生成部１１５は、
毎回のループにおいて、法規情報管理部１１２が管理している法規情報１１２１の法規（
法規ＩＤ）を順次選択する。

上記ループ処理Ｓ１０１３Ｓ～Ｓ１０１３Ｅにおいて、まずソフトウェア照会番号生成
部１１５は、選択中の法規をソフトウェア照会情報管理部１１６が管理する車両トレーサ
ビリティ情報４０と対照し（Ｓ１０１４）、車両要求仕様２３、機器要求仕様３１を介し
て選択中の法規に関連するＥＣＵを取得し、当該機器要求仕様３１を実装したソフトウェ
ア３７の情報を抽出する（Ｓ１０１５）。尚、当該法規がハードウェアのみに関連する場
合は、以降の処理は実施せずに処理を終了する。

ループ処理Ｓ１０１６Ｓ～Ｓ１０１６Ｅでは、ソフトウェア照会番号生成部１１５が、
Ｓ１０１５で抽出した、選択中の法規と関連する、車両トレーサビリティ情報４０を順次
選択し、選択中の車両トレーサビリティ情報４０に含まれているソフトウェアＩＤを取得
する（Ｓ１０１７）。

上記ループ処理Ｓ１０１３Ｓ～Ｓ１０１３Ｅが終了すると、続いて、ソフトウェア照会
番号生成部１１５が、選択中の法規について新たにソフトウェア照会番号を発行（発番）
し、選択中の法規（法規ＩＤ）と新たに発行したソフトウェア照会番号との組を生成する
（Ｓ１０１８）。

続いて、ソフトウェア照会番号生成部１１５は、Ｓ１０１７で生成した法規ＩＤとソフ
トウェア照会番号の組と、Ｓ１０１７で取得した全てのソフトウェアＩＤとを関連づけて
認可ソフトウェア照会情報２１を生成する（Ｓ１０１９）。

続いて、ソフトウェア照会情報管理部１１６が、Ｓ１０１５で抽出した全ての車両トレ
ーサビリティ情報４０を、Ｓ１０１９で生成した認可ソフトウェア照会情報２１と関連づ
けて管理対象として記憶する（Ｓ１０２０）。

以上のように、車両提供者システム１００は、機器供給者システム２００から送られて
くるトレーサビリティ情報３０に基づき、ソフトウェア照会情報６（車両トレーサビリテ
ィ情報４０、認可ソフトウェア照会情報２１）を効率よく生成することができる。

＜ソフトウェア照会情報の更新処理＞
図１２は、機器に組み込まれるソフトウェアの更新に際して車両提供者システム１００
のソフトウェア更新管理部１２５が行う処理（以下、「ソフトウェア更新管理処理Ｓ１２
００」と称する。）を説明するフローチャートである。以下、同図とともにソフトウェア
更新管理処理Ｓ１２００について説明する。

尚、ソフトウェア更新管理処理Ｓ９００の開始時において、トレーサビリティ情報管理
部１１０には、ソフトウェアの更新に伴い、更新されたトレーサビリティ情報２０（車両
提供者が生成するトレーサビリティ情報）、及びトレーサビリティ情報３０’（機器供給
者システム２００から取得したトレーサビリティ情報）が登録されているものとする。

まずソフトウェア更新管理部１２５は、ユーザからモデルＩＤを受け付ける（Ｓ１２１
１）。

次に、ソフトウェア更新管理部１２５は、トレーサビリティ情報変換部１１３及び情報
統合部１１４を介して、新しく登録されたトレーサビリティ情報２０，３０’を用いて車
両トレーサビリティ情報４０を更新する（Ｓ１２１２）。

次に、ソフトウェア更新管理部１２５は、更新前後の車両トレーサビリティ情報４０の
差分を抽出する（Ｓ１２１３）。差分の抽出は、車両トレーサビリティ情報４０の各要素
に含まれるバージョンの相違等により行う。また例えば、不具合等により関数を修正した
場合はソースコード３３に差分が生じるため、これを抽出する。

次に、ソフトウェア更新管理部１２５は、差分を検出した要素に関連する法規ＩＤを抽
出する（Ｓ１２１４）。

続くループ処理Ｓ１２１５Ｓ～Ｓ１２１５Ｅでは、ソフトウェア更新管理部１２５は、
抽出された法規ＩＤを順次選択する。

上記ループ処理において、まずソフトウェア更新管理部１２５は、選択中の法規ＩＤに
ついて、更新後のソフトウェアＩＤを用いてソフトウェア照会情報６を更新して登録する
（Ｓ１２１６）。

次に、ソフトウェア更新管理部１２５は、ソフトウェアの更新が選択中の法規ＩＤの認
証の内容に影響するか否かを判定する（Ｓ１２１７）。認証の内容に影響がある場合（Ｓ
１２１７：影響あり）、処理はＳ１２１８に進み、認証の内容に影響がない場合（Ｓ１２
１７：影響なし）、処理はＳ１２１５Ｅに進み、次の法規ＩＤを選択してループ処理を行
う（Ｓ１２１５Ｓ～Ｓ１２１５Ｅ）。ここで認証の内容に影響があるか否かの判断は、例
えば、トレーサビリティ情報に基づき情報管理部１１１から取得した仕様情報及び検証結
果と、法規情報管理部１１２から取得した届出済み書類に記載の内容を比較し、届出済み
書類の内容に変更を要するか否かを調べることにより行う。そして届出済み書類の内容に
変更が必要な場合は「認証の内容に影響がある」と判断し、変更が不要な場合は「認証の
内容に影響がない」と判断する。

Ｓ１２１８では、ソフトウェア更新管理部１２５は、選択中の法規ＩＤのソフトウェア
照会番号を更新して登録する。

以上により、ユーザは、当該ソフトウェア更新に関連する、または更新の必要があるソ
フトウェア照会番号を効率的に把握することができるようになる。

尚、Ｓ１２１８において、例えば、Ｓ１２１４で取得した認可ソフトウェア照会情報に
関連づけられている車両トレーサビリティ情報４０に関する各種の情報をユーザに提示す
るようにしてもよい。これによりユーザは、例えば、テストが必要となるソフトウェアに
関する各種の情報（法規要求情報２２、車両要求仕様２３、機器要求仕様３１、設計書３
２（基本設計書、詳細設計書、テスト仕様書、テスト結果等）、ソースコード３３、認証
のための提出書類を参照することができ、テスト作業を効率よく進めることができる。

＜ソフトウェア照会情報の参照処理＞
図１３は、ソフトウェア照会情報の参照に際してソフトウェア照会情報管理部１１６が
行う処理（以下、「ソフトウェア照会情報参照処理Ｓ１３００」と称する。）を説明する
フローチャートである。以下、同図とともにソフトウェア照会情報参照処理Ｓ１３００に
ついて説明する。

まずソフトウェア照会情報管理部１１６は、ユーザからモデルＩＤとキーとなる情報（
以下、「キー情報」と称する。）を受け付ける（Ｓ１３１１）。尚、本例では、モデルＩ
Ｄの受け付けは任意であり、キー情報の受け付けは必須であるものとする。

次にソフトウェア照会情報管理部１１６は、ユーザからの入力でモデルＩＤが指定され
ているか否かを確認する（Ｓ１３１２）。モデルＩＤが含まれる場合（Ｓ１３１２：ＹＥ
Ｓ）、処理はＳ１３１６に進み、モデルＩＤが含まれない場合（Ｓ１３１２：ＮＯ）、処
理はＳ１３１３Ｓに進む。

ループ処理Ｓ１３１３Ｓ～Ｓ１３１３Ｅでは、ソフトウェア照会情報管理部１１６は、
登録済みの全てのモデルＩＤ毎の車両トレーサビリティ情報４０を順次選択する。

上記ループ処理において、まずソフトウェア照会情報管理部１１６は、選択中の車両ト
レーサビリティ情報４０が、Ｓ１３１１で受け付けたキー情報を含むか否かを判定する（
Ｓ１３１４）。キー情報を含む場合（Ｓ１３１４：ＹＥＳ）、処理はＳ１３１５に進む。
キー情報を含まない場合（Ｓ１３１４：ＮＯ）、処理はＳ１３１３Ｅに進み、次の車両ト
レーサビリティ情報４０を選択してループ処理Ｓ１３１３Ｓ～Ｓ１３１３Ｅを行う。

Ｓ１３１５では、ソフトウェア照会情報管理部１１６は、選択中の車両トレーサビリテ
ィ情報４０に関連づけられているモデルＩＤを取得して表示し、モデルＩＤの選択を受け
付ける。

Ｓ１３１６では、ソフトウェア照会情報管理部１１６は、ユーザから入力または選択さ
れたモデルＩＤに対応する車両トレーサビリティ情報４０から、前述の入力されたキー情
報に関連する情報（法規ＩＤ、ソフトウェア照会番号、車両要件、適格性検証結果報告書
等）を取得し、取得した情報をユーザに提示する（Ｓ１３１６）。

これによりユーザは、キー情報を適切に指定することにより、ソフトウェアに関する様
々な情報（法規要求情報２２、車両要求仕様２３、機器要求仕様３１等）を容易に参照す
ることができ、これを利用してソフトウェア更新時の影響分析やテスト作業を効率よく進
めることができる。

＜ユーザインタフェース＞
図１４に、ソフトウェア照会情報管理部１１６が、ユーザインタフェースとして表示す
るメニュー画面（以下、「ソフトウェア照会情報管理画面１４００」と称する。）の一例
を示す。同図に示すように、例示するソフトウェア照会情報管理画面１４００は、関連情
報照会ボタン１４１０、新規登録ボタン１４２０、更新ボタン１４３０を有する。

ソフトウェア照会情報管理部１１６は、関連情報照会ボタン１４１０が操作されると図
１５に示す関連情報照会画面１５００を、新規登録ボタン１４２０が操作されると図１６
に示すソフトウェア照会情報新規登録画面１６００を、更新ボタン１４３０が操作される
と図１７に示すソフトウェア照会情報更新画面１７００を、夫々表示する。

図１５に示すように、関連情報照会画面１５００は、モデルＩＤ及びキー情報の入力欄
１５１１、検索結果の表示欄１５１２、テスト関連情報の表示欄１５１３、及び各種メニ
ューの表示欄１５１４を有する。
を有する。

ユーザがキー情報の入力欄１５１１にモデルＩＤやキー情報を入力して検索ボタン１５
１１１を操作すると、ソフトウェア照会情報管理部１１６は、入力された情報を受け付け
る。ソフトウェア照会情報管理部１１６は、例えば、入力されたモデルＩＤに対応する車
両トレーサビリティ情報４０を用いて、キー情報で指定された関数から、これに関連する
各種情報を取得し、取得した情報を検索結果の表示欄１５１２に表示する（尚、情報はリ
ンク先として提供されてもよい。）。入力欄１５１１にモデルＩＤが設定されていない場
合、ソフトウェア照会情報管理部１１６は、全ての車両トレーサビリティ情報４０からこ
れに関連する関数を有する車両トレーサビリティ情報４０を選択し、検索結果の表示欄１
５１２にそのモデルＩＤを選択可能に表示する。

モデルＩＤが選択されると、ソフトウェア照会情報管理部１１６は、選択されたモデル
ＩＤに対応する車両トレーサビリティ情報４０を用いて各種情報を取得して検索結果の表
示欄１５１２に表示する。各種情報は、例えば、法規ＩＤ２１１、ソフトウェア照会番号
２１２、ソフトウェアＩＤ２１３、車両要求仕様２３、システム統合検証結果報告書２５
、適格性検証結果報告書２６、機器要求仕様３１、機器要求仕様３１、設計書３２、ソー
スコード３３、ユニット検証結果報告書３４、ＥＣＵ統合検証結果報告書３５、及びＥＣ
Ｕ適格性検証結果報告書３６を含む。

テスト関連情報の表示欄１５１３には、車両予約ボタン１５１３１、治具予約ボタン１
５１３２、及びセットアップボタン１５１３３が設けられている。

ユーザは、例えば、車両予約ボタン１５１３１を操作することで、テスト車両の予約（
日時の指定、実施場所の指定、車種（型式）の指定、適切なテスト車両が確保することが
できない場合における代替車両の指定等）を行うことができる。車両予約ボタン１５１３
１が操作されると、ソフトウェア照会情報管理部１１６は、例えば、検索結果の表示欄１
５１２に表示中の情報の認可ソフトウェア照会情報２１に関連するテスト情報４１をテス
ト車両管理装置３００に送信する。テスト車両管理装置３００は、上記テスト情報４１を
受信すると、例えば、当該テスト情報４１に基づきテスト車両の予約処理を行い、その結
果（予約に関する情報）をソフトウェア照会情報管理部１１６に送信する。ソフトウェア
照会情報管理部１１６は、上記結果を受信するとその内容（予約状況等）をユーザに提示
する。

またユーザは、例えば、治具予約ボタン１５１３２を操作することで、テストに際して
用いる治具の予約（日時の指定、治具の種類や数の指定等）を行うことができる。治具予
約ボタン１５１３２が操作された場合、ソフトウェア照会情報管理部１１６は、例えば、
検索結果の表示欄１５１２に表示中の情報の認可ソフトウェア照会情報２１に関連するテ
スト情報４１（治具に関する情報）をソフトウェア配信装置４００に送信する。ソフトウ
ェア配信装置４００は、上記テスト情報４１を受信すると、当該テスト情報４１に基づき
治具の予約処理を行い、その結果（予約に関する情報）をソフトウェア照会情報管理部１
１６に送信する。ソフトウェア照会情報管理部１１６は、上記結果を受信するとその内容
（予約状況等）をユーザに提示する。

ユーザがセットアップボタン１５１３３を操作すると、テストに際し必要となるセット
アップ作業（例えば、ソフトウェア配信装置４００へのプログラムの送信、治具へのプロ
グラムのロード等）が自動的に行われる。セットアップボタン１５１３３が操作されると
、ソフトウェア照会情報管理部１１６は、例えば、検索結果の表示欄１５１２に表示中の
情報の認可ソフトウェア照会情報２１に関連するプログラムや、当該認可ソフトウェア照
会情報２１に関連づけられているテスト情報４１に含まれているソフトウェアに関する情
報から特定されるプログラムを、ソフトウェア配信装置４００に送信する。ソフトウェア
配信装置４００は、上記プログラムを受信すると、受信したプログラムを夫々の組み込み
先の機器に書き込む。

各種メニューの表示欄１５１４には、各種情報の登録ボタン１５１４１、及びエビデン
スの生成ボタン１５１４２が設けられている。ユーザは、各種情報の登録ボタン１５１４
１を操作することで、更新しようとするソフトウェアに関連する新たな情報（認可ソフト
ウェア照会情報２１、車両トレーサビリティ情報４０、及びテスト情報４１等）を登録（
ソフトウェア照会情報管理部１１６の管理対象として登録）することができる。またユー
ザが、例えば、エビデンスの生成ボタン１５１４２を操作すると、テスト関連情報管理部
１１８は、テスト情報４１に基づき、エビデンス（例えば、更新したソフトウェアに関す
るエビデンス）を生成してソフトウェア照会情報管理部１１６に入力する。

以上のように、本実施形態のソフトウェア照会情報管理システム１によれば、ユーザは
ソフトウェアを更新した際、当該更新により認可を受けるためのテストが必要なソフトウ
ェアを効率よく確実に特定することができる。また例えば、ソフトウェアが車両のモデル
を跨いで共用されている場合、テストを実施する必要のあるソフトウェアを車両のモデル
を跨いで特定することができる。またユーザは、出力された認可ソフトウェア照会情報２
１を用いて、当局に報告する必要のあるトレーサビリティ情報やエビデンスを効率よく取
得することができる。

図１６に示すように、ソフトウェア照会情報新規登録画面１６００は、モデルＩＤの入
力欄１６２１、生成結果の表示欄１６２２を有する。

ユーザがモデルＩＤの入力欄１６２１にモデルＩＤを入力し、新規登録ボタン１６２１
１を操作すると、ソフトウェア照会情報管理部１１６がモデルＩＤを受け付ける。

ソフトウェア照会情報管理部１１６は、入力されたモデルＩＤに対応するトレーサビリ
ティ情報２０、３０’を用いてトレーサビリティ情報変換部１１３及び情報統合部１１４
とともに車両トレーサビリティ情報４０を生成する。また、ソフトウェア照会番号生成部
１１５は、ソフトウェア照会情報及びソフトウェア照会番号を生成する。

ソフトウェア照会情報管理部１１６は、生成処理の結果と、生成されたソフトウェア照
会番号を生成結果の表示欄１６２２に情報を出力する。

以上のように、本実施形態のソフトウェア照会情報管理システム１によれば、ユーザは
新規に車両を開発した際にソフトウェア照会情報を生成し、認可に際して必要なソフトウ
ェアの組合せとその照会番号を効率的に採番することができる。

図１７に示すように、ソフトウェア照会情報更新画面１７００は、モデルＩＤの入力欄
１７３１、更新結果の表示欄１７３２を有する。

ユーザがモデルＩＤの入力欄１７３１にモデルＩＤを入力し、更新ボタン１７３１１を
操作すると、ソフトウェア照会情報管理部１１６がモデルＩＤの入力を受け付ける。

ソフトウェア照会情報管理部１１６は、入力されたモデルＩＤに対応するトレーサビリ
ティ情報２０、３０’を用いてトレーサビリティ情報変換部１１３及び情報統合部１１４
により車両トレーサビリティ情報４０を更新する。次に、ソフトウェア更新管理部１２５
によりソフトウェア照会情報及びソフトウェア照会番号を更新する。

ソフトウェア照会情報管理部１１６は、更新処理の結果と、更新されたソフトウェア照
会番号を更新結果の表示欄１７３２に情報を表示する。本例では、車両トレーサビリティ
情報４０、ソフトウェア照会情報及びソフトウェア照会番号のいずれも更新が成功したこ
とと、変更箇所から影響を受ける可能性はあるが更新されなかったソフトウェア照会番号
として「R13H001」と表示し、実際に影響があり更新されたソフトウェア照会番号は「R79
02002(更新)」と表示している。

図１８は、ソフトウェア照会情報６の更新時に、ソフトウェア照会情報管理システム１
ではソフトウェア照会番号の更新要否を判断することができなかった場合の表示例である
。同図に示す例は、更新結果の表示欄１７３３以外は、前述と同様の構成である。ソフト
ウェア照会番号の更新要否を判断することができなかった場合、同図の更新結果の表示欄
１７３３に示すように、ソフトウェア照会情報管理部１１６は、車両トレーサビリティ情
報４０、ソフトウェア照会情報は更新が成功したことを表示し、ソフトウェア照会番号の
更新は保留されていることを表示する。またソフトウェア照会情報管理部１１６は、変更
箇所からは影響がある可能性はあるがソフトウェア照会番号の更新要否が判断できなかっ
たことを「R13H001(Pending)」と表示し、実際に影響があり更新されたソフトウェア照会
番号は「R7902002(更新)」と表示している。

以上のように、本実施形態のソフトウェア照会情報管理システム１によれば、ユーザは
ソフトウェアを更新した際にソフトウェア照会情報を更新し、認可に際して必要なソフト
ウェアの組合せとその照会番号を効率的に更新することができる。

以上詳細に説明したように、本実施形態のソフトウェア照会情報管理システム１によれ
ば、ソフトウェア照会情報６を認可ソフトウェア照会情報２１を用いて統一的に管理する
ことができ、車両に搭載される機器に組み込まれるソフトウェアについての法定の認可に
関する情報を効率よく管理することができる。

［システムの利用態様］
図１９は、以上に説明したソフトウェア照会情報管理システム１の利用態様（ユースケ
ース）を説明する図である。

例えば、車両提供者２（ＯＥＭ等）における、設計者や法規部門の担当者は、型式認証
に対応した機能の修正を実施する前に、再度の型式認証を受ける必要か否か、当該再度の
型式認証が必要な型式が当該型式の他にあるか否か等を調べる目的でソフトウェア照会情
報管理システム１を利用する。

また例えば、車両提供者２（ＯＥＭ等）における、設計者や品質管理担当者、もしくは
機器供給者３における設計者は、型式認証に対応する機能の修正を実施した後に、テスト
環境の構築に必要なソフトウェア一式を決定し配布する目的や、型式認証に対応する機能
の修正が完了した後にテストを実施する目的でソフトウェア照会情報管理システム１を利
用する。

また例えば、車両提供者２（ＯＥＭ等）における、設計者や品質管理担当者は、型式認
証に対応する機能の修正を実施した後に、テストを実施しエビデンスを取得する目的でソ
フトウェア照会情報管理システム１を利用する。

このようにソフトウェア照会情報管理システム１は、様々な目的で利用することができ
、ユーザが必要とする情報を迅速に提供することができる。

［テスト環境］
図２０は、エビデンスの取得に際して車両提供者２（ＯＥＭ等）や機器供給者（サプラ
イヤ等）が構築するテスト環境（エビデンスの取得環境）の一例である。同図に示すよう
に、例示するテスト環境２０００は、テスト対象（エビデンスの取得対象）となるソフト
ウェアが配信され実行される一つ以上の機器５１～５４（本例では順にＡＤＥＣＵ（AD:A
utonomous Driving：自動運転）、メータＥＣＵ、ステアリングＥＣＵ、及び作動状態記
録ＥＣＵ）、これらの機器５１～５４を統括制御し携帯通信網等に接続可能なＴＣＵ５６
（TCU：Telematics Control Unit）、バストレーサ６０、及びテスト結果解析装置５００
を含む。これらはＣＡＮ等の通信ネットワーク５０を介して通信可能に接続されている。
ＴＣＵ５６は、例えば、ゲートウェイ５５を介して通信ネットワーク５０に接続する。

機器５１（ＡＤＥＣＵ）は、自動運転の監視や制御に関する情報処理を行う。機器５２
（メータＥＣＵ）は、運転者に対する情報の受け付けや情報の提供を行うユーザインタフ
ェースを備え、例えば、ＩＶＩ（In-Vehicle Infotainment）を構成する。機器５３（ス
テアリングＥＣＵ）は、車両のステアリングの制御に関する情報処理を行う。機器５４（
作動状態記録ＥＣＵ））は、車両の各部（各機能）の作動状態に関する情報の収集や記録
（ログ情報の収集や記録等）に関する情報処理を行う。尚、同図に示す機器５１～５４は
一例に過ぎず、テスト環境２０００は他の種類の制御を行う要素（トランスミッションＥ
ＣＵ、エンジン制御ＥＣＵ等）を含んでいてもよい。

バストレーサ６０は、通信装置を備えた情報処理装置を用いて構成され、通信ネットワ
ーク５０を流れる通信データ（パケット）を取得（パケットキャプチャ）し、取得した通
信データをテスト結果解析装置５００に入力する。テスト結果解析装置５００は、入力さ
れる通信データに基づきエビデンスを生成し、生成したエビデンスを通信ネットワークを
介して車両提供者システム１００に送信する。

尚、テスト結果解析装置５００が備える機能は、例えば、車両提供者システム１００の
機能や機器供給者システム２００の機能としてもよい。また、テスト結果解析装置５００
が備える機能やバストレーサ６０の機能を、車両やテストベッドに実装してもよい。また
、テスト結果解析装置５００の機能を、例えば、車両提供者システム１００、機器供給者
システム２００、テスト環境２０００を構成する車両、テストベッド等の夫々に分散配置
された要素により実現するようにしてもよい。

［エビデンスの生成］
図２１は、テスト環境２０００において取得される情報を利用して、車両提供者システ
ム１００が、ソフトウェア照会情報管理システム１において行われるエビデンスを自動生
成する処理（以下、「エビデンス生成処理Ｓ２１００」と称する。）を説明するフローチ
ャートである。以下、同図とともにエビデンス生成処理Ｓ２１００について説明する。

車両提供者システム１００の不具合情報管理部１１９は、実際の車両やテスト環境から
不具合情報（イベント情報）を随時取得し、取得した不具合情報を不具合情報１１９１と
して記憶する（Ｓ２１１１）。不具合情報管理部１１９は、不具合情報１１９１を、通信
ネットワークを介してテスト結果解析装置５００に随時提供する。図９に示したように、
不具合情報１１９１は、不具合が生じた機器を特定する情報（機器名９１８、機器ＩＤ９
１９）と、当該機器に組み込まれているソフトウェアを特定する情報（ソフトウェア名９
２１、ソフトウェアＩＤ９２２）とを対応づけた情報を含む。

テスト結果解析装置５００は、不具合情報管理部１１９から提供される不具合情報１１
９１と認可ソフトウェア照会情報２１とを対照し、不具合情報１１９１のソフトウェアＩ
Ｄ９２２に関連づけられている法規ＩＤを特定する（Ｓ２１１２）。

続いて、テスト結果解析装置５００は、認可ソフトウェア照会情報２１に基づき、特定
した法規ＩＤに関連づけられている他のソフトウェアＩＤを特定する（Ｓ２１１３）。尚
、テスト結果解析装置５００は、認可ソフトウェア照会情報２１を、例えば、車両提供者
システム１００と通信ネットワークを介して通信することにより随時取得する。

続いて、テスト結果解析装置５００は、車両トレーサビリティ情報４０に基づき、Ｓ２
１１３で特定したソフトウェアＩＤのソフトウェアが組み込まれている機器を特定する（
Ｓ２１１４）。尚、テスト結果解析装置５００は、車両トレーサビリティ情報４０を、例
えば、車両提供者システム１００と通信ネットワークを介して通信することにより取得す
る。

続いて、テスト結果解析装置５００は、Ｓ２１１４で特定した機器に関する通信データ
をバストレーサ６０から取得する（Ｓ２１１５）。尚、通信データは、当該通信データの
送信元を特定する情報と当該通信データの送信先を特定する情報をヘッダ情報等として含
む。

続いて、テスト結果解析装置５００は、Ｓ２１１５で取得した通信データに基づきエビ
デンスを生成し、通信ネットワークを介してテスト関連情報管理部１１８に送信する（Ｓ
２１１６）。テスト関連情報管理部１１８は、送られてきたエビデンスを、テスト履歴情
報１１８１のエビデンス８１８として記憶する。

図２２は、図２０に例示したテスト環境２０００におけるバストレーサ６０が通信デー
タの取得に際し行う処理（以下、「通信データ取得処理Ｓ２２００」と称する。）を説明
するシーケンス図である。例示する通信データ取得処理Ｓ２２００では、バストレーサ６
０が、機器５１（ＡＤＥＣＵ）が主体となって行われる自動運行機能の動作に関する通信
データを取得する。

同図に示すように、まず機器５１（ＡＤＥＣＵ）が動作を開始すると、その旨を通知す
る通信データが通信ネットワーク５０を介して機器５１（ＡＤＥＣＵ）から機器５４（作
動状態記録ＥＣＵ）に送信され（Ｓ２２１１）、機器５４（作動状態記録ＥＣＵ）が上記
通信データを受信して当該通信データの内容を記録（記憶装置に格納。以下同様。）する
。

続いて、機器５１（ＡＤＥＣＵ）が、走行環境が変化したこと（例えば、天候が変化し
路面の状況が変化したこと）を検知すると、その旨を通知する通信データが通信ネットワ
ーク５０を介して機器５１（ＡＤＥＣＵ）から機器５４（作動状態記録ＥＣＵ）に送信さ
れ（Ｓ２２１２）、機器５４（作動状態記録ＥＣＵ）が上記通信データを受信して当該通
信データの内容を記録する。

続いて、機器５１（ＡＤＥＣＵ）が、運転者に対して運転の引継ぎ（手動運転への切り
替え）を促すための警報出力開始指示を含む通信データを機器５２（メータＥＣＵ）に送
信し（Ｓ２２１３）、機器５２（メータＥＣＵ）が上記通信データを受信して警報を出力
（表示、音声出力等）する。

続いて、機器５１（ＡＤＥＣＵ）が、上記警報を作動させた旨を通知する通信データを
通信ネットワーク５０を介して機器５４（作動状態記録ＥＣＵ）に送信し（Ｓ２２１４）
、機器５４（作動状態記録ＥＣＵ）が上記通信データを受信して当該通信データの内容を
記録する。

続いて、機器５１（ＡＤＥＣＵ）が、運転者に対して運転の引継ぎを促した理由（要因
）（例えば、道路の中央線（中央分離線）を検知することができない等）を通知する通信
データを通信ネットワーク５０を介して機器５４（作動状態記録ＥＣＵ）に送信し（Ｓ２
２１５）、機器５４（作動状態記録ＥＣＵ）が上記通信データを受信して当該通信データ
の内容を記録する。

続いて、機器５３（ステアリングＥＣＵ）が、運転者が手動運転を開始したことを検知
した旨を通知する通信データを通信ネットワーク５０を介して機器５１（ＡＤＥＣＵ）に
送信し（Ｓ２２１６）、機器５１（ＡＤＥＣＵ）が上記通信データを受信する。また、機
器５３（ステアリングＥＣＵ）が、自動運転を停止し手動運転が開始された旨を通知する
通信データを通信ネットワーク５０を介して機器５４（作動状態記録ＥＣＵ）に送信し（
Ｓ２２１７）、機器５４（作動状態記録ＥＣＵ）が上記通信データを受信して当該通信デ
ータの内容を記録する。

続いて、機器５３（ステアリングＥＣＵ）が、警報出力停止指示を含む通信データを機
器５２（メータＥＣＵ）に送信し（Ｓ２２１８）、機器５２（メータＥＣＵ）が上記通信
データを受信して警報の出力を停止する。また機器５３（ステアリングＥＣＵ）が、警報
の出力が停止した旨を通知する通信データを通信ネットワーク５０を介して機器５４（作
動状態記録ＥＣＵ）に送信し（Ｓ２２１９）、機器５４（作動状態記録ＥＣＵ）が上記通
信データを受信して当該通信データの内容を記録する。

バストレーサ６０は、以上のシーケンスにおいて通信ネットワーク５０を流れる通信デ
ータを取得（キャプチャ）し、取得した通信データをテスト結果解析装置５００に入力す
る。

図２３に以上のシーケンスによりバストレーサ６０が取得しテスト結果解析装置５００
に入力される通信データの例（各行が一つの通信データに相当する。）を示す。テスト関
連情報管理部１１８は、テスト結果解析装置５００から入力された通信データに基づきエ
ビデンス８１８を生成する。尚、通信データは事後的な解析のためにエビデンスを生成す
る過程で記録しておくようにしてもよい。例示するように、通信データは、送信元から送
信先に送信された日時を示す情報（以下、「タイムスタンプ」と称する。）を含む。この
タイムスタンプを利用することで、例えば、新たに取得した通信データの発生間隔（タイ
ミング）と過去に取得した通信データの発生間隔（タイミング）とを比較することによる
不具合の検出や予兆検出、警告出力の要否判定等を行うことができる。

以上のように、本実施形態のソフトウェア照会情報管理システム１によれば、テスト環
境２０００で取得される情報を利用してエビデンス８１８を効率よく生成することができ
る。尚、以上に示したエビデンスの生成方法は一例に過ぎず、エビデンスは他の方法によ
って取得してもよい。また以上では、不具合というイベントに関する情報に基づきエビデ
ンスを生成したが、不具合以外の種類のイベントに関する情報に基づきエビデンスを生成
してもよい。

以上、本発明の実施形態について詳述したが、本発明は以上に説明した実施形態に限定
されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の
構成が含まれる。例えば、前述した実施形態は本発明を分かりやすく説明するために詳細
に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されな
い。またある実施形態の構成の一部を他の実施形態の構成に置き換えてもよい。またある
実施形態の構成に他の実施形態の構成を加えてもよい。また各実施形態の構成の一部につ
いて、他の構成の追加、削除、又は置換をしてもよい。

本発明における説明ではコンポーネントとしてＥＣＵの事例を示したが、法規要求やシ
ステム要求を、車載ＥＣＵだけでなく車両外に配置されたサーバ装置と連携して構成する
場合もある。この場合は、システム要求はサーバ装置への要求と車両への要求に分解され
、車両への要求はさらのＥＣＵへの要求に分解される。但し、要求がサーバ装置向けの場
合は、このような場合にも、前述の機器要求仕様３１をサーバ装置への要求として見れば
、同様の管理を行うことができると考えてよい。即ち、車両とサーバ装置に跨る機能に関
しても統一的に認可への影響分析等ができる。

前述の発明では、トレーサビリティ情報変換部１１３は車両提供者システム１００に配
置する例を示したが、機器供給者システム２００のトレーサビリティ情報変換送信部２０
３に配置してもよい。このようにすることで、車両供給者は統一されたフォーマットでト
レーサビリティ情報を受信することができる。

また前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば
集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサが夫々の機能
を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディス
ク、ＳＳＤ（Solid State Drive）等の記憶装置、又は、ＩＣ（Integrated Circuit）カ
ード、ＳＤカード、ＤＶＤ（Digital Versatile Disc）の記録媒体に格納することができ
る。

制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御
線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続され
ていると考えてよい。

１ソフトウェア照会情報管理システム、２車両提供者、３Ａ～３Ｃ機器供給者、６
ソフトウェア照会情報、２１認可ソフトウェア照会情報、２２法規要求情報、２３
車両要求仕様、３０トレーサビリティ情報、３１機器要求仕様、３２設計書、３
３ソースコード、４０車両トレーサビリティ情報、１００車両提供者システム、１
１１情報管理部、１１２法規情報管理部、１１３トレーサビリティ情報変換部、１
１２１法規情報、１１４情報統合部、１１５ソフトウェア照会番号生成部、１１６
ソフトウェア照会情報管理部、１１８テスト関連情報管理部、１１８１テスト履歴
情報、１１８２テスト車両情報、１１９不具合情報管理部、１１９１不具合情報、
２００機器供給者システム、２０２トレーサビリティ情報管理部、２０３トレーサ
ビリティ情報変換送信部、３００テスト車両管理装置、４００ソフトウェア配信装置
、５００テスト結果解析装置、２０００テスト環境、５１～５４機器、５０通信
ネットワーク、５５ゲートウェイ、５６ＴＣＵ、６０バストレーサ、Ｓ７００ソ
フトウェア照会情報生成処理、Ｓ２１００エビデンス生成処理、Ｓ２２００通信デー
タ取得処理

Claims

車両に搭載される機器の機能を実現するソフトウェアについての法定の認可に関する情報を管理する情報処理システムであって、
車両について法定の認可を受けるための要件を規定する法規を特定する情報である法規ＩＤに関連づけて、前記法規が前記機器に要求する仕様に関する情報である機器要求仕様を記憶し、
前記機器要求仕様と関連づけられた機器のトレーサビリティに関する情報であるトレーサビリティ情報を記憶し、
前記トレーサビリティ情報は、前記機器に組み込まれるソフトウェアを特定するソフトウェアＩＤを含み、
取得した前記トレーサビリティ情報に関連づけられている前記機器要求仕様に対応する前記法規ＩＤと、一つ以上の前記ソフトウェアＩＤとを関連づける情報であるソフトウェア照会情報を生成し、
前記機器に生じたイベントに関する情報であり、当該イベントが生じた前記機器を特定する情報と当該機器の機能を実現する前記ソフトウェアのソフトウェアＩＤとを対応づけた情報を含むイベント情報を記憶し、
前記ソフトウェア照会情報に基づき、前記イベント情報における前記ソフトウェアＩＤに対応する前記法規ＩＤに関連づけられている他の前記ソフトウェアの前記ソフトウェアＩＤを特定し、
前記トレーサビリティ情報に基づき、特定した前記ソフトウェアＩＤが組み込まれている前記機器を特定し、
特定した前記機器が他の機器との間で行った通信の内容を含む通信データを前記機器の間を通信可能に接続する通信ネットワークに接続されたバストレーサにより取得し、
前記通信データに基づき、前記法定の認可を受けるために必要なエビデンスを生成する、
ソフトウェア照会情報管理システム。
請求項１に記載のソフトウェア照会情報管理システムであって、
前記ソフトウェアＩＤは、前記ソフトウェアの種類を特定する情報とバージョン情報を含む、
ソフトウェア照会情報管理システム。
請求項１に記載のソフトウェア照会情報管理システムであって、
車両の一つ以上のモデル、一つ以上の前記機器、及び一つ以上の前記法規の組合せの夫々について前記法規ＩＤと、一つ以上の前記ソフトウェアＩＤとを関連づける情報であるソフトウェア照会番号を生成して管理する、
ソフトウェア照会情報管理システム。
請求項３に記載のソフトウェア照会情報管理システムであって、
前記トレーサビリティ情報は前記ソフトウェアのソースコードを含み、
前記ソフトウェア照会情報は、前記ソフトウェア照会番号と前記トレーサビリティ情報とを対応づけた情報であり、
前記ソースコードまたはその一部である関数を特定する情報であるキー情報を受け付け、
受け付けた前記キー情報を含む一つ以上の前記ソフトウェア照会情報を特定し、
特定した前記ソフトウェア照会情報に基づき、前記イベント情報における前記ソフトウェアＩＤに対応する前記法規ＩＤに関連づけられている他の前記ソフトウェアの前記ソフトウェアＩＤを特定する、
ソフトウェア照会情報管理システム。
請求項４に記載のソフトウェア照会情報管理システムであって、
特定した一つ以上の前記ソフトウェア照会番号の前記トレーサビリティ情報に含まれている一つ以上のソフトウェアＩＤを他の前記ソフトウェアの前記ソフトウェアＩＤとして特定する、
ソフトウェア照会情報管理システム。
車両に搭載される機器の機能を実現するソフトウェアについての法定の認可に関する情報を管理する方法であって、
情報処理装置が、
車両について法定の認可を受けるための要件を規定する法規を特定する情報である法規ＩＤに関連づけて、前記法規が前記機器に要求する仕様に関する情報である機器要求仕様を記憶するステップ、及び、
前記機器要求仕様と関連づけられた前記機器のトレーサビリティに関する情報であるトレーサビリティ情報を記憶するステップ、
を実行し、
前記トレーサビリティ情報は、前記機器に組み込まれるソフトウェアを特定するソフトウェアＩＤを含み、
前記情報処理装置が、
取得した前記トレーサビリティ情報に関連づけられている前記機器要求仕様に対応する前記法規ＩＤと、一つ以上の前記ソフトウェアＩＤとを関連づける情報であるソフトウェア照会情報を生成するステップ、
前記機器に生じたイベントに関する情報であり、当該イベントが生じた前記機器を特定する情報と当該機器の機能を実現する前記ソフトウェアのソフトウェアＩＤとを対応づけた情報を含むイベント情報を記憶するステップ、
前記ソフトウェア照会情報に基づき、前記イベント情報における前記ソフトウェアＩＤに対応する前記法規ＩＤに関連づけられている他の前記ソフトウェアの前記ソフトウェアＩＤを特定するステップ、
前記トレーサビリティ情報に基づき、特定した前記ソフトウェアＩＤが組み込まれている前記機器を特定するステップ、
特定した前記機器が他の機器との間で行った通信の内容を含む通信データを前記機器の間を通信可能に接続する通信ネットワークに接続されたバストレーサにより取得するステップ、及び、
前記通信データに基づき、前記法定の認可を受けるために必要なエビデンスを生成するステップ、
を実行する、ソフトウェア照会情報管理方法。
請求項６に記載のソフトウェア照会情報管理方法であって、
前記ソフトウェアＩＤは、前記ソフトウェアの種類を特定する情報とバージョン情報を含む、
ソフトウェア照会情報管理方法。
請求項６に記載のソフトウェア照会情報管理方法であって、
前記情報処理装置が、車両の一つ以上のモデル、一つ以上の前記機器、及び一つ以上の前記法規の組合せの夫々について前記法規ＩＤと、一つ以上の前記ソフトウェアＩＤとを関連づける情報であるソフトウェア照会番号を生成して管理するステップ、
を更に実行する、ソフトウェア照会情報管理方法。
請求項８に記載のソフトウェア照会情報管理方法であって、
前記トレーサビリティ情報は前記ソフトウェアのソースコードを含み、
前記ソフトウェア照会情報は、前記ソフトウェア照会番号と前記トレーサビリティ情報とを対応づけた情報であり、
前記情報処理装置が、
前記ソースコードまたはその一部である関数を特定する情報であるキー情報を受け付け、
受け付けた前記キー情報を含む一つ以上の前記ソフトウェア照会番号を特定するステップ、及び、
特定した前記ソフトウェア照会情報に基づき、前記イベント情報における前記ソフトウェアＩＤに対応する前記法規ＩＤに関連づけられている他の前記ソフトウェアの前記ソフトウェアＩＤを特定するステップ、
を更に実行する、ソフトウェア照会情報管理方法。
請求項９に記載のソフトウェア照会情報管理方法であって、
前記情報処理装置が、特定した一つ以上の前記ソフトウェア照会番号の前記トレーサビリティ情報に含まれている一つ以上のソフトウェアＩＤを他の前記ソフトウェアの前記ソフトウェアＩＤとして特定するステップ、
を更に実行する、ソフトウェア照会情報管理方法。