特開 2024-81375 信号生成装置、信号解析システム及び信号生成方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024081375

(43)【公開日】2024-06-18

(54)【発明の名称】信号生成装置、信号解析システム及び信号生成方法

(51)【国際特許分類】

   H04L 1/00 20060101AFI20240611BHJP

   G06F 11/10 20060101ALI20240611BHJP

   H04L 25/02 20060101ALI20240611BHJP

【ＦＩ】

H04L1/00 A

G06F11/10 604

H04L25/02 301Z

【審査請求】未請求

【請求項の数】8

【出願形態】ＯＬ

(21)【出願番号】P 2022194956

(22)【出願日】2022-12-06

(71)【出願人】

【識別番号】000003997

【氏名又は名称】日産自動車株式会社

(74)【代理人】

【識別番号】110000486

【氏名又は名称】弁理士法人とこしえ特許事務所

(72)【発明者】

【氏名】岡本 幸代

【テーマコード（参考）】

5K014

5K029

【Ｆターム（参考）】

5K014AA01

5K014BA06

5K014EA01

5K014HA01

5K029AA01

5K029BB03

5K029CC01

5K029DD13

5K029EE11

(57)【要約】

【課題】ＣＲＣシグナル値の設定エラーを防止できる、信号生成装置を提供する。
【解決手段】
ネットワークシステムで用いられる信号を生成する信号生成装置であって、コントローラ１０は、少なくともＩＤ（Identifer）とシグナル値を含んだメッセージフレームを取得し、メッセージフレームが予め定められた所定水準に対応するフレームである場合には、ソフトウェアライブラリに格納された規格決定用ロジックと、データベースを用いて、メッセージフレームに該当するＣＲＣ規格を選択し、ソフトウェアライブラリに格納されたＣＲＣ計算用ロジックを用いて、ＣＲＣ規格に準じたＣＲＣシグナル値を計算し、ＣＲＣシグナル値を付与したメッセージフレームを生成する。
【選択図】図１

【特許請求の範囲】

【請求項1】

ネットワークシステムで用いられる信号を生成する信号生成装置であって、
ＣＲＣ規格を決定するための規格決定用ロジックと、ＣＲＣ計算用ロジックが組み込まれたソフトウェアライブラリと、
前記ソフトウェアライブラリを参照して、ネットワークシステムで用いられる信号を生成するコントローラを備え、
前記コントローラは、
少なくともＩＤ（Identifer）とシグナル値を含んだメッセージフレームを取得し、
前記メッセージフレームが予め定められた所定水準に対応するフレームである場合には、前記規格決定用ロジックを用いて、前記メッセージフレームに該当するＣＲＣ規格を選択し、
前記ＣＲＣ計算用ロジックを用いて、前記ＣＲＣ規格に準じたＣＲＣシグナル値を計算し、
前記ＣＲＣシグナル値を前記メッセージフレームに付与することで新たなメッセージフレームを生成する信号生成装置。

【請求項2】

請求項１記載の信号生成装置であって、
前記規格決定用ロジックは、フレーム種別とＤＬＣから該当する前記ＣＲＣ規格を決定するロジックであり、
前記コントローラは、
前記規格決定用ロジックを用いて、取得された前記メッセージフレームのＩＤを元に、データベースを参照して得られる前記フレーム種別と前記ＤＬＣから、前記メッセージフレームに該当するＣＲＣ規格を選択する信号生成装置。

【請求項3】

請求項２記載の信号生成装置であって、
前記データベースは、前記メッセージフレームのプロパティを示す情報として、ＩＤ、メッセージ名、ＤＬＣ、フレーム種別、シグナル名、及びシグナルビット位置を含んでおり、
前記コントローラは、、前記データベースから得られる前記プロパティを参照して、前記メッセージフレームから前記フレーム種別と前記ＤＬＣを取得する信号生成装置。

【請求項4】

請求項３記載の信号生成装置であって、
前記コントローラは、前記プロパティを参照して前記シグナルビット位置を取得し、前記プロパティで定められた前記シグナルビット位置に、前記ＣＲＣシグナル値を格納する信号生成装置。

【請求項5】

請求項３記載の信号生成装置であって、
前記コントローラは、取得された前記メッセージフレームに含まれる前記シグナル値を編集して、新たなシグナル値を設定し、
前記ＣＲＣ計算用ロジックを用いて、前記ＩＤと前記新たなシグナル値に基づき、前記ＣＲＣ規格に準じた前記ＣＲＣシグナル値を計算する信号生成装置。

【請求項6】

請求項１又は２記載の信号生成装置であって、
所定水準は機能安全規格を定めた水準であり、
前記コントローラは、前記メッセージフレームが前記所定水準に対応するフレームではない場合には、前記ＣＲＣシグナル値を計算するための処理を実行しない信号生成装置。

【請求項7】

請求項１又は２記載の信号生成装置を含む信号解析システムにおいて、
前記新たなメッセージフレームを受信するコントロールユニットを備え、
前記コントロールユニットは、
受信した前記メッセージフレームに付与された前記ＣＲＣシグナル値を取得し、
前記ＣＲＣシグナル値とＣＲＣ計算値とを照合する信号解析システム。

【請求項8】

コントローラにより実行される、ネットワークシステムで用いられる信号を生成する信号生成方法であって、
前記コントローラは、
少なくともＩＤ（Identifer）とシグナル値を含んだメッセージフレームを取得し、
前記メッセージフレームが予め定められた所定水準に対応するフレームである場合には、ソフトウェアライブラリに格納された規格決定用ロジックを用いて、前記メッセージフレームに該当するＣＲＣ規格を選択し、
前記ソフトウェアライブラリに格納されたＣＲＣ計算用ロジックを用いて、前記ＩＤとシグナル値に基づき、前記ＣＲＣ規格に準じたＣＲＣシグナル値を計算し、
前記ＣＲＣシグナル値を前記メッセージフレームに付与することでメッセージフレームを生成する信号生成方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、信号生成装置、信号解析システム及び信号生成方法に関するものである。

【背景技術】

【0002】

従来より、車両における電子制御装置（ＥＣＵ）の動作を、シミュレータを用いて試験する試験方法が知られている（例えば特許文献１）。この試験方法では、シミュレータは、ＥＣＵのソフトウェアが正常に作動するかを試験するために、アプリケーションに所定の試験条件を示すシミュレーションデータをＥＣＵ側の通信ＩＦに入力し、そのシミュレーションデータを用いてアプリケーションが演算した結果のデータを取得して、その演算結果データからＣＰＵボード内の試験結果判定部が試験結果を判定する。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２０－１４４２７４号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ところで、車両におけるＥＣＵがＡＳＩＬ（Automotive Safety Integrity Level）等の所定水準に準拠したシステムを制御するユニットである場合には、ＥＣＵが送受信するデータフレームにＣＲＣシグナル値を付与する必要がある。上記の試験方法において、アプリケーションを用いた演算処理によりシグナル値を編集すると、ＣＲＣシグナル値の設定エラーが発生し、メッセージ内容に誤りであると認識され、シミュレーションを適切に実施できないという問題がある。

【0005】

本発明が解決しようとする課題は、ＣＲＣシグナル値の設定エラーを防止できる、信号生成装置、信号解析システム及び信号生成方法を提供することである。

【課題を解決するための手段】

【0006】

本発明は、少なくともＩＤ（Identifer）とシグナル値を含んだメッセージフレームを取得し、メッセージフレームが所定水準に対応するフレームである場合には、ソフトウェアライブラリ１２に格納された規格決定用ロジックを用いて、メッセージフレームに該当するＣＲＣ規格を選択し、ソフトウェアライブラリ１２に格納されたＣＲＣ計算用ロジックを用いて、ＣＲＣ規格に準じたＣＲＣシグナル値を計算し、ＣＲＣシグナル値をメッセージフレームに付与することでメッセージフレームを生成することによって、上記課題を解決する。

【発明の効果】

【0007】

本発明によれば、ＣＲＣシグナル値の設定エラーを防止できる。

【図面の簡単な説明】

【0008】

【図1】図１は、本発明の一実施の形態に係る信号解析システムを示すブロック図である。

【図2】図２は、コントローラ１０で実行される制御フローを示すフローチャートである。

【図3】図３は、データベース２０に登録されている送信フレームの構成と、各データ値を示す説明図である。

【図4】図４は、図２に示すステップＳ４０のサブフローのフローチャートである。

【図5】図５は、規格決定用ロジックを説明するための概念図である。

【図6】図６は、データベース２０に登録されている受信フレームの構成と、各データ値を示す説明図である。

【図7】図７は本実施形態の変形例に係る信号解析システムを示すブロック図である。

【図8】図８は本実施形態の変形例に係る信号解析システムを示すブロック図である。

【図9】図９は本実施形態の変形例に係る信号解析システムを示すブロック図である。

【発明を実施するための形態】

【0009】

以下、本発明に係る信号解析システムの一実施の形態を図面に基づいて説明する。図１は、本発明の一実施の形態に係る信号解析システムを示すブロック図である。信号解析システム相当するシミュレータ１１は、コントローラ１０、ソフトウェアライブラリ１２、データベース２０と、車両３０に搭載されるＥＣＵ３１、３２を備えている。本実施形態に係る信号解析システムは、ＥＣＵ間を送受信されるプロトコルメッセージを解析して、ＣＲＣシグナル値を自動生成して、ＡＳＩＬ等の所定水準（機能安全規格を定めた水準）に準拠したメッセージフレームに付与する。

【0010】

コントーラ１０は、ハードウェア及びソフトウェアを備えたコンピュータにより構成され、プログラムを格納したメモリと、このメモリに格納されたプログラムを実行するＣＰＵ等を有している。コントーラ１０は、ＥＣＵ３１、３２から送信されるプロトコルメッセージを取得して、プロトコルメッセージに対して信号解析を行い、ＡＳＩＬ対応フレームに格納されるＣＲＣシグナル値を計算し、新たなプロトコルメッセージを生成して、ＥＣＵ３１、３２に送信する。なお、シミュレータ１１を有する装置が、本発明の「信号生成装置」に相当し、シミュレータ１１で実行される信号処理方法が本発明の「信号生成方法」に相当する。

【0011】

ソフトウェアライブラリ１２は、ＣＲＣシグナル値の計算に使用されるロジックを格納する。ロジックは、少なくとも、ＣＲＣ規格を決定するための規格決定用ロジックと、ＣＲＣ計算用ロジックを含んでいる。規格決定用ロジックは、フレーム種別とＤＬＣ（Data Length Code）から該当するＣＲＣ規格を決定するためのロジックである。ＣＲＣ規格は、フレーム内におけるＣＲＣの計算方法を定めており、フレーム種別とＤＬＣに応じて決まる。ＣＲＣ計算用ロジックは、メッセージフレームに含まれるＣＲＣシグナル値を除いたシグナル値とＩＤから、ＣＲＣ規格に準じたＣＲＣシグナル値を計算するためのロジックである。ロジックはライブラリ化されて、ソフトウェアライブラリ１２に格納されている。

【0012】

またデータベース２０は、メッセージフレームのプロパティを示す情報として、ＩＤ、メッセージ名、ＤＬＣ、フレーム種別、シグナル名、及びシグナルビット位置を含んでいる。プロパティは、フレーム領域に関するデータであり、データベース２０に登録されている。プロパティは、メッセージフレームから、シグナルビット位置、フレーム種別、又はＤＬＣ等を取得するために参照されるデータである。プロパティに含まれる各情報については後述する。なお、コントローラ１０及びソフトウェアライブラリ１２及びデータベース２０を含むシミュレータ１１が、ＣＡＮ測定解析ツールに相当する。

【0013】

車両３０に搭載されるＥＣＵ３１、３２は、電子制御機器であり、ステアリング、ブレーキなどの車載機器と通信網で接続されており、車載機器に対して制御指令を送信する。ＥＣＵ３１、３２は、ＡＳＩＬで定められた安全性水準を満たすために、通信網の送受信データとして、ＣＲＣを付与したプロトコルメッセージを送受信する必要がある。

【0014】

本実施形態では、ＥＣＵ３１、３２のソフトウェアの動作解析のために、ＣＡＮ測定解析ツールシミュレータ１１（コントローラ１０及びソフトウェアライブラリ１２及びデータベース２０を含む）を、ＥＣＵ３１、３２が接続されているネットワークに接続する。
そして、シミュレータ１１は、ＥＣＵ３１から、プロトコルメッセージを取得し、ＣＲＣシグナル値以外の任意のシグナル値を変更した後、ＣＲＣ計算を行う。コントーラ１０は、ＣＲＣ計算の結果物であるＣＲＣシグナル値を、フレーム内の指定領域に格納して、新たなプロトコルメッセージをＥＣＵ３２に送信する。
ＥＣＵ３２は、シミュレータ１１から取得したメッセージフレームに格納されているＣＲＣシグナル値とＣＲＣ計算値を照合することで、誤りの有無を判定する。

【0015】

ところで、ＡＳＩＬ等の所定水準を準拠したシステムにおいてプロトコルメッセージを送受信する際には、所定水準に対応したメッセージフレームでデータを送受信する必要がある。例えば所定の水準がＡＳＩＬ等の機能安全規格（自動車安全水準）である場合には、メッセージフレーム内にＣＲＣ（Cyclic Redundancy Check：データ誤りチェックコード）をシグナル値として付与する必要がある。なお以下の説明では、プロトコルメッセージをＣＡＮメッセージとして、実施形態を説明するが、プロトコルメッセージはＬＩＮメッセージでもよい。

【0016】

ＡＳＩＬ対応ＣＡＮフレームにＣＲＣシグナル値を付与するために、フレーム内のシグナル値を編集するとＣＲＣシグナル値の設定エラー（データ不整合）になることがある。従来はネットワークシミュレーションツールを使用して、ＡＳＩＬ対応ＣＡＮフレームを受信する。ＣＡＮフレームの種別は、ＣＡＮ－ＨＳ、ＣＡＮ－ＦＤ等があり、ＣＲＣを計算するための規格がフレーム種別に応じて決まっている。そのため、従来は、ＣＡＮフレームの種別に応じて該当するＣＲＣ規格を選択して、編集するシグナル値を元に、エクセル等のマクロでＣＲＣシグナル値を計算していた。また、ネットワークシミュレーションツールより、ＣＡＮフレームに格納されるＩＤやシグナルをバイト単位で書き換えることで、シグナル設定を行っていた。このような従来の方法では、ＣＲＣシグナル値の計算は手動計算のため、例えば、ユーザがＣＲＣの計算ロジックやＣＲＣ規格の仕様を理解していない場合には、ＣＲＣシグナル値の設定エラー（データ不整合）が頻発するという問題がある。また、フレーム種別判断とＣＲＣ計算を、ユーザが手作業で実施した場合には、平均的なネットワーク周期送信時間内で終わらせることは難しく、Signal値の変更・送信作業が不可能であった。

【0017】

本実施形態に係る信号解析システムは、上記問題を解決するために、ＣＲＣ計算のためのロジックを、ソフトウェアライブラリ１２に格納し、データベース２０のプロパティを参照して、ＣＲＣシグナル値の計算を自動化（標準化）している。また、信号解析システムは、ＣＲＣシグナル値の自動計算により、リアルタイムなフレームの送受信を可能としている。

【0018】

以下、図２を参照して、信号解析システムにおける信号生成処理（信号解析方法）を説明する。図２はコントーラ１０で実行される制御フローを示すフローチャートである。

【0019】

ステップＳ１０にて、コントーラ１０は、ＥＣＵ３１から、少なくともＩＤ、ＤＬＣ、シグナルの領域に各データを含んだ、ＣＡＮフレームを取得する。ステップＳ２０にて、コントーラ１０は、取得されたメッセージフレームに含まれるシグナル値を編集して新たなシグナル値を設定する。

【0020】

新たなシグナル値の設定について、図３を参照して説明する。図３は、データベース２０に登録されているプロパティと、シミュレータ１１で処理されるデータフレームの構成を示す説明図である。図３は、フレーム種別（ＣＡＮ－ＨＳ）の例を示している。図３（а）はプロパティの説明図である。図３（а）に示すように、データベース２０のプロパティは、少なくとも、ＩＤ、メッセージ名、ＤＬＣ、フレーム種別、及びシグナルビット位置を含んでいる。また、シグナルビット位置「０～１」の領域と「２」の領域の一部は、シグナル名（Signal 1）のデータ格納領域であり、シグナルビット位置「２」の領域の一部と「３」の領域はシグナル名（Signal 2）のデータ格納領域であり、シグナルビット位置「５」の領域はシグナル名（ＣＲＣ）のデータ格納領域であり、シグナルビット位置「６」の領域はシグナル名（ＣＬＫ：Clock）のデータ格納領域である。データフレームにおけるシグナル値等のデータの格納位置は可変であるが、データベース２０にプロパティを登録することで、データの格納位置（格納領域）が指定される。なお、図３に示すシグナルビット位置のレイアウトは一例であり、各データの格納位置をメッセージ毎に変えて、レイアウトを自由に定義してもよい。例えば、ＣＲＣの格納領域をシグナルビット位置「７」としてもよい。

【0021】

ステップＳ１０にて、コントーラ１０は、ＩＤ、ＤＬＣ、データ領域の各シグナル値を取得する。ステップＳ２０にて、コントーラ１０は、ステップＳ１０の制御処理で取得したＣＡＮフレームのＩＤをキーとし、データベース２０のプロパティを参照して、シグナル値、ＣＲＣ、ＣＬＫの各種データの格納領域を計算する。さらに、図３（а）のSignal 1の値を、Signal 1の格納領域へ格納する。同様に、Signal 2と、ＣＬＫについても格納領域へ値の格納をする。このとき、シミュレータ１１は、図３（ｂ）の説明図の通りに値が代入される。また、コントーラ１０は、ＣＲＣの格納領域を除き、データを格納していない領域には、パディングデータ（Padding Data）を格納する。図３（ｃ）は、パディングデータ（Padding Data）格納後の、データフレームの構成を示す説明図である。これにより、コントーラ１０は新たなシグナル値を設定する。

【0022】

ステップＳ３０にて、コントーラ１０は、データベース２０に含まれるプロパティを参照して、ＣＡＮフレームのフレーム種別とＤＬＣを取得する。ステップＳ４０にて、コントーラ１０はＣＲＣ規格を選択する。図４はＣＲＣ規格を選択する制御フローのサブフローを示すフローチャートである。

【0023】

ステップＳ４１にて、コントローラ１０はステップＳ１０の制御処理で取得したフレームがＡＳＩＬに対応するフレームであるか否か判定する。コントーラ１０は、ステップＳ１０の制御処理で取得したメッセージフレームのＩＤをキーとし、データベース２０のプロパティを参照して、シグナル名にＡＳＩＬに対応するフレームに付随するＣＲＣ及びＣＬＫが含まれているかの計算をする。ＣＲＣ及びＣＬＫのシグナル名が含まれているときは、ＡＳＩＬに対応するフレームであると判定する。フレームがＡＳＩＬに対応するフレームではない場合には、シミュレータ１１は制御フローを終了させて、後述するＣＲＣシグナル値を計算するための処理を実行しないため、ステップＳ７０へ進む。

【0024】

ステップＳ１０の制御処理で取得したフレームがＡＳＩＬに対応するフレームである場合には、コントーラ１０は、ステップＳ４２～Ｓ４５の処理を実行する。コントーラ１０は、ステップＳ４２～Ｓ４５の処理フローにおいて、規格決定用ロジックを用いて、メッセージフレームに該当するＣＲＣ規格を選択する。図５は、規格決定用ロジックを説明するための概念図である。図５に示すように、ＣＲＣ規格は、フレーム種別とＤＬＣの条件により決まる。例えばメッセージフレームの種別が、ＣＡＮ－ＨＳ又はＣＡＮ－ＦＤ＿Ｃｏｎｔａｉｎｅｒである場合には、ＣＲＣ規格はＣＲＣ８となる。また、メッセージフレームの種別がＣＡＮ－ＦＤ＿Ｒｅｇｕｌａｒである場合に、ＤＬＣが８バイト以下であるときにはＣＲＣ規格はＣＲＣ８となり、ＤＬＣが８バイトを超えるのときにはＣＲＣ規格はＣＲＣ１６となる。つまり、規格決定用ロジックは、メッセージフレームの種別とＤＬＣの長さの条件に対して、該当するＣＲＣ規格を決定するための判定ロジックに相当する。なお、図５には図示されていないが、規格決定用ロジックは、ＬＩＮメッセージにも対応できるようなロジックとしてもよい。

【0025】

ステップＳ４２にて、コントーラ１０は、フレーム種別がＣＡＮ－ＦＤ＿ｒｅｇｕｌａｒであるか否か判定する。フレーム種別がＣＡＮ－ＦＤ＿ｒｅｇｕｌａｒである場合には、ステップＳ４３にて、コントーラ１０は、ＤＬＣが８バイトを超えるか否か判定する。ＤＬＣが８バイトを超える場合、すなわちＤＬＣが９バイト以上である場合には、コントーラ１０はＣＲＣ規格（ＣＲＣ１６）を選択する（ステップＳ４４）。一方、フレーム種別がＣＡＮ－ＦＤ＿ｒｅｇｕｌａｒではない場合（ステップＳ４２の判定で「Ｎｏ」）、又は、フレーム種別がＣＡＮ－ＦＤ＿ｒｅｇｕｌａｒであり、かつ、ＤＬＣが８バイト以下である場合（ステップＳ４３の判定で「Ｎｏ」）には、コントーラ１０はＣＲＣ規格（ＣＲＣ８）を選択する（ステップＳ４５）。コントーラ１０は、ステップＳ４０の制御処理により、ＣＲＣ規格を自動選択し、ステップＳ５０へ進む。

【0026】

ステップＳ５０にて、コントーラ１０は、ＣＲＣ計算用ロジックを用いて、ＩＤとシグナル値に基づき、ＣＲＣ規格に準じたＣＲＣシグナル値を計算する。シグナル値は、ステップＳ２０で設定したシグナル値でよい。なお、ＩＤとシグナル値からＣＲＣシグナル値を計算方法は、ＣＲＣ規格に準じた公知の方法を適用すればよいが、本実施形態では、ソフトウェアライブラリ１２に格納されたＣＲＣ計算用ロジックを用いて、ＣＲＣ計算処理をしているため、ＣＲＣシグナル値の自動計算を可能としている。

【0027】

ステップＳ６０にて、コントーラ１０は、データベース２０のプロパティを参照して決定したＣＲＣの格納領域（シグナルバイト位置「５」）に、ＣＲＣシグナル値（コードデータ：0ｘ1Ａ）を格納する。これにより、コントーラ１０は、図３（ｄ）に示すようなＣＡＮフレームを構成とするＣＡＮメッセージを生成する。図３（ｄ）は、ＣＲＣシグナル値を格納後の、データフレームの構成を示す説明図である。ステップＳ７０にて、コントーラ１０は、ＣＡＮメッセージをＥＣＵ３２に送信する。これにより、コントーラ１０による信号解析処理の制御フローが終了する。

【0028】

図６は、受信フレームの構成を示す説明図である。ＥＣＵ３２は、シグナルバイト位置（図６の例では、シグナルバイト位置「５」）に格納されたＣＲＣシグナル値を取得する。なお、シグナルビット位置とＣＲＣシグナル値の取得は、データベース２０のプロパティを参照してシミュレータ１１で実行される。そして、ＥＣＵ３２は、ＣＲＣシグナル値とＣＲＣ計算値とを照合する。ＥＣＵ３２は、ＣＲＣシグナル値とＣＲＣ計算値が一致しない場合には、ＥＣＵ３１、３２を含むネットワークシステムにおいて異常が生じていると判定する。

【0029】

なお、上記の信号解析システムにおける信号生成処理の制御フローでは、シグナル値を設定する制御フロー（ステップＳ２０）と、ＣＲＣシグナル値を設定する制御フロー（ステップＳ５０）とを別のフローとして説明したが、コントローラ１０は、シグナル値を設定する際に、ステップＳ３０～Ｓ５０の制御フローを実行することで、シグナル値の設定に付随して、ＣＲＣシグナル値を計算してもよい。このとき、ＣＲＣシグナル値の計算に使用されるシグナル値は、ステップＳ１０の制御フローで取得したＣＡＮフレームに含まれるシグナル値を用いてもよい。

【0030】

上記のように、本実施形態に係る信号生成装置及び信号生成方法は、少なくともＩＤ（Identifer）とシグナル値を含んだメッセージフレームを取得し、メッセージフレームが予め定められた所定水準に対応するフレームである場合には、ソフトウェアライブラリ１２に格納された規格決定用ロジックを用いて、メッセージフレームに該当するＣＲＣ規格を選択し、ソフトウェアライブラリ１２に格納されたＣＲＣ計算用ロジックを用いて、ＣＲＣ規格に準じたＣＲＣシグナル値を計算し、ＣＲＣシグナル値をメッセージフレームに付与することでメッセージフレームを生成する。これにより、ユーザは、ＣＲＣ規格に準じたＣＲＣ計算ロジックを知らなくても、ＣＲＣシグナル値をフレームに付与できる。また、ＡＳＩＬ水準に対応するフレームを送受信するＣＡＮネットワークのシミュレーション設計が容易となり、リアルタイムにシグナル値を変更できるようになる。さらに、データベースを使用することで、不要なシグナル値の変更がなくなるため、ＣＲＣシグナル値の設定エラーを防止できる。

【0031】

また本実施形態において、規格決定用ロジックは、フレーム種別とＤＬＣから該当するＣＲＣ規格を決定するロジックであり、コントローラ１０は、ＣＲＣ規格決定用ロジックを用いて、取得したメッセージフレームのＩＤを元に、データベース２０のプロパティを参照して得られるフレーム種別とＤＬＣから、メッセージフレームに該当するＣＲＣ規格を選択する。これにより、メッセージフレームに該当するＣＲＣ規格を自動選択できる。

【0032】

また本実施形態において、データベース２０は、メッセージフレームのプロパティを示す情報として、ＩＤ、メッセージ名、ＤＬＣ、フレーム種別、シグナル名、及びシグナルビット位置を含んでおり、コントローラ１０は、データベース２０から得られるプロパティを参照して、メッセージフレームからフレーム種別とＤＬＣを取得する。これにより、ＣＲＣシグナル値の設定エラーを防止できる。

【0033】

また本実施形態において、コントローラ１０は、データベース２０のプロパティを参照して得られるシグナルビット位置を取得し、プロパティで定められたシグナルビット位置に、ＣＲＣシグナル値を格納する。これにより、ＣＲＣシグナル値の設定エラーを防止できる。

【0034】

また本実施形態において、コントローラ１０は、取得されたメッセージフレームに含まれるシグナル値を編集して新たなシグナル値を設定し、ＣＲＣ計算用ロジックを用いて、ＩＤと新たなシグナル値に基づき、ＣＲＣ規格に準じたＣＲＣシグナル値を計算する。これにより、ＣＲＣシグナル値の設定エラーを防止できる。

【0035】

また本実施形態において、コントローラ１０は、メッセージフレームが所定水準に対応するフレームではない場合には、ＣＲＣシグナル値を計算するための処理を実行しない。これにより、不要な計算処理を省略できる。

【0036】

また本実施形態に係る信号解析システムにおいて、新たなメッセージフレームを受信するＥＣＵ３２を備え、ＥＣＵ３２は、受信したメッセージフレームに付与されたＣＲＣシグナル値を取得し、ＣＲＣシグナル値とＣＲＣ計算値とを照合する。これにより、設計開発において満足なＥＣＵ評価が可能になり、品質を向上させることができる。

【0037】

なお本実施形態の変形例として、図７に示すように、信号解析システムはテスタ（ＤＩＡＧテスタ）４０をさらに備えてもよい。図７は本実施形態の変形例に係る信号解析システムを示すブロック図である。テスタ４０は車両３０が搭載するネットワークに接続され、故障発生時の履歴をＥＣＵ３１がＤＴＣ（ダイアグノスティックトラブルコード）として仕様通りに記録しているか否か判定する装置である。ＥＣＵ３１は、ネットワーク上に、ＥＣＵ３２へのメッセージフレームを送信する。その送信データを、シミュレータ１１にて、ＥＣＵ３２がＤＴＣを記録するようなシグナル値に編集した後、本実施形態における信号生成処理の制御フローを行い、再計算したＣＲＣシグナル値を付与したメッセージフレームを、ネットワーク上に送信する。その書き換えられたメッセージフレームをＥＣＵ３２は受信し、本実施形態における信号生成処理の制御フローを行い、故障えの条件に従ってＤＴＣをセットする。ＥＣＵ３２が、正常に診断処理を行った後、テスタ４０から、ＥＣＵ３２にＤＩＡＧリクエストを送信する。ＥＣＵ３２は、テスタ４０からのリクエストに対応するレスポンスデータを、テスタ４０へ送信する。テスタ４０は、ＥＣＵ３２のレスポンスデータからＤＴＣを確認することで、ＥＣＵ３２の診断処理が正常に機能することを確認する。なお、テスタ４０を用いたＥＣＵの動作確認は、ＥＣＵ３１に対しても同様の方法で実行できる。

【0038】

また本実施形態の変形例として、図８に示すように、信号解析システムは送信用シミュレーションコントロールユニット５１及び受信用シミュレーションコントロールユニット５２を備えてもよい。図８は本実施形態の変形例に係る信号解析システムを示すブロック図である。信号解析システムは、必ずしもＥＣＵ３１、３２に含まれる全ての構成を含む必要はなく、ＥＣＵ３１及びＥＣＵ３２の制御用ソフトウェアをＣＡＮ測定解析ツールにＥＣＵ５１及びＥＣＵ５２として書き込んで、１つの解析ツールとしてもよい。例えば、ＣＡＮネットワークシミュレーション設計を実施する際に、信号解析システムを用いて信号解析処理を行う場合には、本変形例のような解析ツール（信号解析システム）を適用するとよい。

【0039】

また本実施形態の変形例として、図９に示すように、信号解析システムは、ＥＣＵ３１とＥＣＵ３２のどちらか一方のＥＣＵのみを含んでいてもよい。図９は本実施形態の変形例に係る信号解析システムを示すブロック図である。例えば、ＥＣＵ３１の送受信信号に対して信号解析処理を行う場合には、本変形例のようなシステムを適用するとよい。

【0040】

なお、ＥＣＵ３１、３２、５１、５２が本発明の「コントロールユニット」に相当する。

【0041】

なお、以上説明した実施形態は、本発明の理解を容易にするために記載されたものであって、本発明を限定するために記載されたものではない。したがって、上記の実施形態に開示された各要素は、本発明の技術的範囲に属する全ての設計変更や均等物をも含む趣旨である。

【符号の説明】

【0042】

１０ コントローラ
１１ シミュレータ
１２ ソフトウェアライブラリ
２０ データベース
３０ 車両
３１ 送信用コントロールユニット
３２ 受信用コントロールユニット
４０ テスタ（ＤＩＡＧテスタ）
５１ 送信用シミュレーションコントロールユニット
５２ 受信用シミュレーションコントロールユニット

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】