JP6515915B2 - 車載ネットワークシステム - Google Patents

Description

本発明は、車載ネットワークシステムに関する。

従来より、２つのプロセッサ（第１／第２プロセッサ）を搭載する複数のノードを含むデータ・パケット処理装置がある。送信ノードは、リアルタイムに送信したいデータがある場合に、テンプレート・パケットを生成し、通信開始前に、高速処理を行うデータを格納するテンプレート・パケットを受信ノードに通知し、送信ノードと受信ノードとの間でテンプレート・パケットを共有する。

受信ノードは、テンプレート・パケットを受信すると、第２プロセッサで処理を行う。これにより、第１プロセッサの処理負荷を軽減している（例えば、特許文献１参照）。

特開２０１０−２３３２４０号公報

ところで、従来のデータ・パケット処理装置は、テンプレート・パケットという独自のフォーマットを利用しているため、独自のフォーマットに対応した独自の処理が必要になる。独自のフォーマット（データ形式）に対応した独自の処理は、処理時間が長くなるため、高速処理には不向きである。また、これは、独自のフォーマットを用いる場合に限らず、リアルタイムに送信したいデータを区別するために独自のデータを追加する場合においても同様である。

このため、優先的に高速処理を行いたい優先度の高いデータが存在する車載のネットワークには適していない。

そこで、独自のデータ形式や独自のデータを追加することなく、優先度の高いデータを高速で処理することができる、車載ネットワークシステムを提供することを目的とする。

本発明の実施の形態の車載ネットワークシステムは、
第１制御部と、第２制御部と、前記第１制御部及び前記第２制御部を接続するネットワークとを含む、車載ネットワークシステムであって、
前記第１制御部は、
送信データが第１処理速度よりも速い第２処理速度での高速処理の対象であるかどうかを判定する送信データ判定部と、
前記送信データ判定部によって前記高速処理の対象ではないと判定された送信データの前記ネットワークへの送信処理を前記第１処理速度で行う第１処理部と、
前記送信データ判定部によって前記高速処理の対象であると判定された送信データを第１データ長に分割することによって得る、又は、当該送信データに所定のデータを付け足して前記第１データ長にすることによって得る、前記第１データ長のデータの前記ネットワークへの送信処理を前記第２処理速度で行う第２処理部と
を有し、
前記第２制御部は、
前記ネットワークを介して受信した受信データのデータ長が前記第１データ長であるかどうかを判定する受信データ判定部と、
前記受信データ判定部によって前記第１データ長ではないと判定されると、前記第１処理速度で前記受信データの受信処理を行う第３処理部と、
前記受信データ判定部によって前記第１データ長であると判定されると、前記第２処理速度で前記受信データの受信処理を行う第４処理部と
を有する。

このため、受信データのデータ長が第１データ長であるかどうかを判定することで、高速処理（第２処理速度）用のデータであるかどうかを判定することができる。この判定には、独自のデータ形式又はデータを用いる必要はない。

従って、独自のデータ形式や独自のデータを追加することなく、優先度の高いデータを高速で処理することができる、車載ネットワークシステムを提供することができる。

本発明の他の実施の形態の車載ネットワークシステムでは、
前記第２処理部は、さらに、前記送信データをフレームの先頭から第１データ長に分割する際に、前記フレームの最後尾で前記第１データ長未満のデータが生じると、当該データに所定のデータを付け足して前記第１データ長よりも所定データ長だけ短い第２データ長のデータを生成することによって得る、前記第２データ長のデータを前記第２処理速度で送信し、
前記受信データ判定部は、さらに、前記受信データのデータ長が前記第２データ長であるかどうかを判定し、
前記第４処理部は、前記受信データ判定部によって前記第１データ長であると判定された受信データに続く受信データが前記第２データ長であると判定されると、当該受信データが前記送信データから分割された複数の受信データのうちの最後尾の受信データのデータであると判定する。

このため、第２制御部で受信される受信データのデータ長が第２データ長であるかどうかで最後尾の受信データであるかを判定することができる。受信データは、第１制御部で送信データが分割されたデータが第２制御部で受信されたものである。

従って、独自のデータ形式や独自のデータを追加することなく、優先度の高いデータを高速で処理することができ、最後尾の受信データを判別できる、車載ネットワークシステムを提供することができる。

本発明の他の実施の形態の車載ネットワークシステムでは、
前記第１制御部は、
前記高速処理の対象になる送信データの識別子と前記第１データ長とを紐付けたリストデータをさらに有し、
前記送信データ判定部は、前記リストデータの識別子を用いて前記送信データが前記高速処理の対象であるかどうかを判定し、
前記第２処理部は、前記リストデータの前記第１データ長に基づいて、前記第１データ長のデータの送信処理を行い、
前記第２制御部は、
前記リストデータをさらに有し、
前記受信データ判定部は、前記受信データのデータ長及び識別子が、それぞれ、前記リストデータによって紐付けられた前記第１データ長及び前記識別子と一致するかどうかを判定し、
前記第３処理部は、前記受信データ判定部によって一致しないと判定されると、前記第１処理速度で前記受信データの受信処理を行い、
前記第４処理部は、前記受信データ判定部によって一致すると判定されると、前記第２処理速度で前記受信データの受信処理を行う。

このため、送信側の第１制御部では、高速処理の対象になる送信データを識別子とデータ長とで判別でき、受信側の第２制御部では、受信データが高速処理の対象であるかどうかを識別子とデータ長とで判別することができる。

従って、独自のデータ形式や独自のデータを追加することなく、識別子とデータ長とで高速処理の対象であるかどうかを判別することにより、優先度の高いデータを高速で処理することができる、車載ネットワークシステムを提供することができる。

独自のデータ形式や独自のデータを追加することなく、優先度の高いデータを高速で処理することができる、車載ネットワークシステムを提供することができる。

実施の形態の車載ネットワークシステム１００を示す図である。 ＥＣＵ１３０の構成を示す図である。 高速フレーム処理部１３５の構成を示す図である。 リストデータを示す図である。 高速送信処理部１３５Ｃが送信データを分割する手法を説明する図である。 分割データを格納する高速用フレームと、最終フレームと、通常速度処理用のデータのフレームのフレーム構造を示す図である。 高速フレーム処理部１３５が行う送信処理のフローチャートを示す図である。 高速送信処理部１３５Ｃが行う送信処理のフローチャートを示す図である。 高速フレーム処理部１３５が行う受信処理のフローチャートを示す図である。 実施の形態の変形例によるＣＧＷ−ＥＣＵ１１０Ａを示す図である。

以下、本発明の車載ネットワークシステムを適用した実施の形態について説明する。

＜実施の形態＞
図１は、実施の形態の車載ネットワークシステム１００を示す図である。車載ネットワークシステム１００は、優先度の高いデータを高速で処理する。ここで、優先度の高いデータとは、一例として、データ長が比較的長いデータであり、リアルタイム性を必要とするデータである。リアルタイム性を必要とするとは、高速処理を行って、リアルタイムのデータを転送することが求められることをいう。従って、優先度の高いデータは、典型的には、車両の周辺の画像を表すデータである。

車載ネットワークシステム１００は、ＣＧＷ(Central Gateway)−ＥＣＵ(Electronic Control Unit)１１０、バス１２０Ａ、１２０Ｂ、自動運転ＥＣＵ１３０Ａ、及び画像認識ＥＣＵ１３０Ｂを含む。自動運転ＥＣＵ１３０Ａ及び画像認識ＥＣＵ１３０Ｂは、それぞれ、バス１２０Ａ及び１２０Ｂを介してＣＧＷ−ＥＣＵ１１０に接続されている。ここで、自動運転ＥＣＵ１３０Ａ及び画像認識ＥＣＵ１３０Ｂのうちの一方は第１制御部の一例であり、他方は第２制御部の一例である。バス１２０Ａ、１２０Ｂは、ネットワークの一例である。

車載ネットワークシステム１００は、自動運転ＥＣＵ１３０Ａ及び画像認識ＥＣＵ１３０Ｂ以外のＥＣＵも含むが、ここでは一例として、自動運転ＥＣＵ１３０Ａ及び画像認識ＥＣＵ１３０Ｂを示す。なお、自動運転ＥＣＵ１３０Ａ及び画像認識ＥＣＵ１３０Ｂを区別しない場合には、ＥＣＵ１３０と称す。

ＣＧＷ−ＥＣＵ１１０、自動運転ＥＣＵ１３０Ａ、及び画像認識ＥＣＵ１３０Ｂは、一例として、ＣＰＵ(Central Processing Unit)、ＲＡＭ(Random Access Memory)、ＲＯＭ(Read Only Memory)、クロック生成部、入出力インターフェース、通信インターフェース、送受信部、及び内部バス等を含むコンピュータによって実現される。

車載ネットワークシステム１００は、車両に搭載され、自動運転ＥＣＵ１３０Ａ及び画像認識ＥＣＵ１３０Ｂの間で通信を行う。なお、以下では、車両とは、特に断らない限り、車載ネットワークシステム１００が搭載される車両を指す。

ＣＧＷ−ＥＣＵ１１０は、Ｌ７スイッチ、Ｌ３スイッチ、及びＬ２スイッチによるデータ転送処理を行う通常処理部と、メディアアクセスコントローラと、通常処理部よりも高速処理用のフレーム処理を行う高速フレーム処理部と、ＤＭＡ(Direct Memory Access)とを含む。通常処理部は、いずれのスイッチを使うかを切り替えることができる。また、メディアアクセスコントローラと高速フレーム処理とＤＭＡとについては後述する。なお、このようなＣＧＷ−ＥＣＵ１１０をハブＥＣＵとして捉えることもできる。

ここで、Ｌ７スイッチとは、ＯＳＩ(Open Systems Interconnection)参照モデルのレイヤ7（アプリケーション層）に相当するアプリケーションレベルのプロトコル（利用規約）情報を調べてパケットの転送処理を行うスイッチのことである。Ｌ７スイッチは、ソフトウェア的にスイッチングを行う。

また、Ｌ３スイッチとは、ＯＳＩ参照モデルにおけるレイヤ３（ネットワーク層）においてパケットの送信先アドレスを振り分ける仕組みを持ったスイッチのことであり、ソフトウェア的にスイッチングを行う。Ｌ３スイッチでは、転送プロトコルにＩＰ(Internet Protocol)を用いる。なお、Ｌ３スイッチは、ハードウェア的にスイッチングを行うものであってもよい。

また、Ｌ２スイッチとは、ＯＳＩ参照モデルにおけるレイヤ２（データリンク層）において、データに宛先情報として含まれるＭＡＣ（Media Access Control）アドレスで中継先を判断し、中継動作を行うスイッチのことである。Ｌ２スイッチは、ハードウェア的にスイッチングを行う。

バス１２０Ａ、１２０Ｂは、ＯＳＩ参照モデルにおけるレイヤ２（データリンク層）のデータ形式によるデータ通信を行うバスである。図１には、２本のバス１２０Ａ、１２０Ｂを示すが、実際には、ＣＧＷ−ＥＣＵ１１０には、さらに多くのバスが接続され、各バスに様々なＥＣＵが接続される。

自動運転ＥＣＵ１３０Ａは、米国運輸省道路交通安全局（NHTSA）が定めるレベル１以上の自動運転の制御を行うＥＣＵである。自動運転ＥＣＵ１３０Ａは、車両の周辺監視データ（カメラ画像、物標情報、経路情報等）を用いて、車両を走行させるための走行制御データをバス１２０Ａに出力する。また、自動運転ＥＣＵ１３０Ａは、走行状況を表すデータ（マルチメディアデータ）を車内のディスプレイパネル等に表示する。

また、カメラ画像とは、車両に搭載されるカメラ１５０Ａ、１５０Ｂ、１５０Ｃによって取得される画像である。また、物標情報とは、３次元（３Ｄ）の地図に用いる地物や建物等を表す画像等のデータである。また、経路情報とは、地図データにおける自車の位置及び経路を表すデータである。

また、車両を走行させるための走行制御データは、アクセル開度、ブレーキの制動力を制御する制御量、ステアリングの操舵量、ウインカの点灯制御データ、ライト等の点灯制御等であり、例えば、米国運輸省道路交通安全局（NHTSA）が定めるレベル１、２、３、又は４のレベルに従って、車両を走行させる際に車載ネットワークシステム１００に含まれるＥＣＵの制御に必要な制御データである。

なお、ここでは、一例として、自動運転のレベルを米国運輸省道路交通安全局（NHTSA）が定めるレベルで表すが、自動運転のレベル又は自動運転の態様は、他の規格等によって表されるものであってもよい。その場合に、自動運転とは、アクセル操作、ステアリング操作、及びブレーキ操作のうちの少なくとも１つを車両が行うものであればよい。

画像認識ＥＣＵ１３０Ｂは、カメラ１５０Ａ、１５０Ｂ、１５０Ｃによって取得される車両の前方、後方、及び左右側方の画像を表す画像データを画像認識ＥＣＵ１３０Ｂに出力する。画像認識ＥＣＵ１３０Ｂは、カメラ１５０Ａ、１５０Ｂ、１５０Ｃから入力される画像データをバス１２０Ｂを介してＣＧＷ−ＥＣＵ１１０に出力する。ＧＷ−ＥＣＵ１１０は、画像データを自動運転ＥＣＵ１３０Ａに中継（転送）する。

カメラ１５０Ａ、１５０Ｂ、１５０Ｃは、車載ネットワークシステム１００が搭載される車両の前後左右に設けられている。カメラ１５０Ａは、２つの撮像部１５０Ａ１、１５０Ａ２を有するステレオカメラである。カメラ１５０Ａは、車両の前方の立体画像を表す画像データを画像認識ＥＣＵ１３０Ｂに出力する。カメラ１５０Ｂは、車両の後方の画像を表す画像データを画像認識ＥＣＵ１３０Ｂに出力する。カメラ１５０Ｃは、実際には２つあり、車両の左右側方の画像を表す画像データを画像認識ＥＣＵ１３０Ｂに出力する。

図２は、ＥＣＵ１３０の構成を示す図である。図２には、ＥＣＵ１３０のハードウェア的な構成と、ＣＰＵがプログラムを実行することによって実現される機能ブロックとを示す。

ＥＣＵ１３０は、メディアアクセスコントローラ１３１、ＤＭＡ１３２、ＩＰ処理部１３３、ＴＣＰ／ＵＤＰポート１３４、高速フレーム処理部１３５、及びアプリケーション処理部１３６を有する。これらのうち、メディアアクセスコントローラ１３１とＤＭＡ１３２は、ハードウェアとして実現されるものであり、ＩＰ処理部１３３、ＴＣＰ(Transmission Control Protocol)／ＵＤＰ(User Datagram Protocol)ポート１３４、高速フレーム処理部１３５、及びアプリケーション処理部１３６は、ＣＰＵがプログラムを実行することによって実現される機能ブロックである。

メディアアクセスコントローラ１３１は、ＯＳＩ参照モデルにおけるレイヤ２（データリンク層）に属する層である。ＤＭＡ１３２は、ＣＰＵを利用せずに直接的にデータを転送するハードウェア処理部である。ＤＭＡ１３２は、ＯＳＩ参照モデルにおけるレイヤ２（データリンク層）に属する。

ＩＰ処理部１３３は、ＯＳＩ参照モデルにおけるレイヤ３（ネットワーク層）においてパケットの送信先アドレスを振り分ける処理部である。ＴＣＰ／ＵＤＰポート１３４は、トランスポート層（レイヤ４）である。

高速フレーム処理部１３５は、リアルタイムパケット形式の高速用フレームのデータを送受信する。高速フレーム処理部１３５の詳細については、図３を用いて後述する。なお、高速フレーム処理部１３５は、ＯＳＩ参照モデルにおけるレイヤ３（ネットワーク層）に属する。アプリケーション処理部１３６は、アプリケーション層（レイヤ７）である。

上述のようなＥＣＵ１３０は、通常速度処理用のデータと、高速処理用のデータとの送信処理及び受信処理を行う。ＥＣＵ１３０のうち、ＩＰ処理部１３３及びＴＣＰ／ＵＤＰポート１３４は、通常速度処理用のデータの送信処理を行う第１処理部の一例であるとともに、通常速度処理用のデータの受信処理を行う第３処理部の一例である。ここで、通常速度とは、イーサネット（登録商標）のシグナルリンクパケット形式のデータを送受信する速度である。また、高速処理とは、通常速度よりも高速の処理速度であり、例えばイーサネットのリアルタイムパケット形式のデータを送受信する速度である。

図３は、高速フレーム処理部１３５の構成を示す図である。高速フレーム処理部１３５は、主制御部１３５Ａ、送信データ判定部１３５Ｂ、高速送信処理部１３５Ｃ、受信データ判定部１３５Ｄ、高速受信処理部１３５Ｅを有する。これらのうち、送信データ判定部１３５Ｂと高速送信処理部１３５Ｃは、データ送信側の処理部であり、受信データ判定部１３５Ｄ、高速受信処理部１３５Ｅはデータ受信側の処理部である。

主制御部１３５Ａは、高速フレーム処理部１３５の処理を統括する制御部である。主制御部１３５Ａは、送信データ判定部１３５Ｂ、高速送信処理部１３５Ｃ、受信データ判定部１３５Ｄ、高速受信処理部１３５Ｅが行う処理以外の高速フレーム処理部１３５の処理を行う。

送信データ判定部１３５Ｂは、送信データ及び受信データが通常速度処理用のデータと高速処理用のデータとのいずれであるかを判定する。判定には、高速処理用のデータのデータ名、送元ＭＡＣアドレス、及びデータ長を紐付けたリストデータを用いる。リストデータについては、図４を用いて説明する。

高速送信処理部１３５Ｃは、送信データ判定部１３５Ｂによって判定される高速処理用のデータの送信処理を行う。高速送信処理部１３５Ｃは、第２処理部の一例である。

受信データ判定部１３５Ｄは、受信データのデータ長が高速処理用のデータのデータ長であるかどうかを判定する。高速処理用のデータの送元ＭＡＣアドレスとデータ長とを紐付けたリストデータを用いる。

高速受信処理部１３５Ｅは、高速処理用のデータの受信処理を行う。高速受信処理部１３５Ｅは、第４処理部の一例である。

図４は、リストデータを示す図である。リストデータは、送信データ判定部１３５Ｂが、送信データが通常速度処理用のデータと高速処理用のデータとのいずれであるかを判定する際に参照する。また、リストデータは、受信データ判定部１３５Ｄが、受信データが通常速度処理用のデータと高速処理用のデータとのいずれであるかを判定する際に参照する。

リストデータは、高速処理用のデータのデータ名、送元ＭＡＣアドレス、及びデータ長を紐付けたテーブル形式のデータである。データ名は、高速処理用のデータを表す名称であり、データを識別する識別子の一例である。送元ＭＡＣアドレスは、高速処理用のデータの送信元（送り元）になる機器やＥＣＵ等に割り当てられたＭＡＣアドレスである。データ長は、高速処理用のデータのデータ長である。

車載ネットワークシステム１００は、高速処理用のデータと通常速度処理用のデータとをデータ長で区別する。車載ネットワークシステム１００は、高速処理用のデータと通常速度処理用のデータと区別する際に、独自のデータ形式又はデータを用いずに、送信データ又は受信データのデータ長で区別する。

図４に示すように、前カメラ１の画像（カメラ１５０Ａの撮像部１５０Ａ１による画像）は、送元ＭＡＣアドレスがＡＡＡＡ（カメラ１５０ＡのＭＡＣアドレス）であり、データ長は１５００（Byte）である。

前カメラ２の画像（カメラ１５０Ａの撮像部１５０Ａ２による画像）は、送元ＭＡＣアドレスがＡＡＡＡ（カメラ１５０ＡのＭＡＣアドレス）であり、データ長は１４９８（Byte）である。

後カメラ１の画像（カメラ１５０Ｂによる画像）は、送元ＭＡＣアドレスがＢＢＢＢ（カメラ１５０ＢのＭＡＣアドレス）であり、データ長は１５００（Byte）である。側方カメラ１の画像（車両の左側のカメラ１５０Ｃによる画像）は、送元ＭＡＣアドレスがＣＣＣＣ（車両の左側のカメラ１５０ＣのＭＡＣアドレス）であり、データ長は１５００（Byte）である。側方カメラ２の画像（車両の右側のカメラ１５０Ｃによる画像）は、送元ＭＡＣアドレスがＤＤＤＤ（車両の右側のカメラ１５０ＣのＭＡＣアドレス）であり、データ長は１５００（Byte）である。

ここでは、高速処理用のデータのデータ長は、１５００（Byte）又は１４９８（Byte）に設定してある。前カメラ２の画像のデータ長を１４９８（Byte）にしてあるのは、同じ送元ＭＡＣアドレスの前カメラ１の画像のデータ長（１５００（Byte））と区別するためである。

また、画像データは、データ量が大きいため、１５００（Byte）又は１４９８（Byte）以上である場合には、データの先頭から分割する。そして、最後尾のデータであることをデータ長で示すために、１（Byte）少ないデータ長を利用する。すなわち、データ長が１５００（Byte）のデータについてはデータ長が１４９９（Byte）のデータ長を最後尾のデータに利用し、データ長が１４９８（Byte）のデータについてはデータ長が１４９７（Byte）のデータ長を最後尾のデータに利用する。このことについては、図５を用いて後述する。

なお、通常速度処理用のデータのデータ長は、高速処理用のデータに用いるデータ長とは異なるデータ長に設定すればよい。ここでは、１４９７（Byte）、１４９８（Byte）、１４９９（Byte）、及び１５００（Byte）以外のデータ長に設定すればよい。通常速度処理用のデータは、高速処理用のデータよりも通信速度が遅いため、通常速度処理用のデータのデータ長は、高速処理用のデータのデータ長よりも短いことが好ましい。

図５は、高速送信処理部１３５Ｃが送信データを分割する手法を説明する図である。ここでは、一例として、送信データが前カメラ１の画像データであり、データ長が７０００（Byte）である場合について説明する。前カメラ１の画像データは、１５００（Byte）単位で分割される。このようにデータ長が長いデータは、優先度の高いデータの一例である。

高速送信処理部１３５Ｃは、送信データのデータ長が分割単位の１５００（Byte）よりも長いので、送信データを複数に分割する。７０００（Byte）の送信データを先頭から分割すると、４つの１５００（Byte）の分割データと、最後尾の１つの１０００（Byte）の分割データとが得られる。

最後尾の分割データについては、データ長によって高速処理用のデータの最後尾の分割データであると認識されるようにするために、図５に示すように、最後尾の１つの１０００（Byte）の分割データの末尾にパディングを行い、不要なデータ（例えば、１６進法の００ｈ）を４９９（Byte）分付け足して１４９９(Byte)のデータ長にする。このようにして、分割単位（ここでは１５００（Byte））に対して端数になる最後尾の分割データのデータ長を他の分割データのデータ長よりも１（Byte）短いデータ長に設定する。

図６は、分割データを格納する高速用フレームと、最終フレームと、通常速度処理用のデータのフレームのフレーム構造を示す図である。

図６（Ａ）に示す高速用フレームのフレーム構造は、イーサネットの高速用フレーム（リアルタイムパケット）であり、宛先ＭＡＣアドレス、送元ＭＡＣアドレス、データ長、ペイロード、及びＦＣＳ(Frame Check Sequence)を有する。宛先ＭＡＣアドレスは、データの宛先のＭＡＣアドレスである。宛先ＭＡＣアドレス、送元ＭＡＣアドレス、及びデータ長は、Ethernetヘッダを構成する。

分割データは、ペイロードに格納される。図５に示すように、７０００（Byte）の送信データを分割して得られる５つの分割データ（４つの１５００（Byte）の分割データと、パディングされた１４９９（Byte）の最後尾の分割データ）を１つずつペイロードに格納するため、５つの高速用フレームが得られる。データ長は、先頭から４つの高速用フレームでは１５００（Byte）と記載され、最後尾の高速用フレームでは１４９９（Byte）と記載される。

図６（Ｂ）に示す最終フレームは、宛先ＭＡＣアドレス、送元ＭＡＣアドレス、データ長、ＰＬ(Padding Length)値、及びＦＣＳを有する。最終フレームは、最後尾の高速用フレームの後に送信されるフレームであり、最後尾の高速用フレームに含まれるパディングされたデータ長（ＰＬ値）が格納されている。ＰＬ値は、一例として２（Byte）で表され、この場合に最終フレームのデータ長は、２（Byte）になる。なお、上述のようにＰＬ値が４９９（Byte）である場合には、例えば、１６進法で１Ｆ３ｈと表せばよい。

図６（Ｃ）に示す通常速度処理用のデータのフレームは、宛先ＭＡＣアドレス、送元ＭＡＣアドレス、データ長、ＩＰヘッダ、ＵＤＰ／ＴＣＰヘッダ、ペイロード、及びＦＣＳを有するシグナリングパケットである。ここで、高速用フレームで利用するデータ長は、１４９７（Byte）、１４９８（Byte）、１４９９（Byte）、及び１５００（Byte）であるため、これらの最小値をＮ（Byte）（Ｎ＝１４９７）とすると、ＩＰヘッダ、ＵＤＰ／ＴＣＰヘッダ、及びペイロードのデータ長がＮ（Byte）未満であればよい。図６（Ｃ）に示す通常速度処理用のデータのフレームのデータ長は、Ｎ（Byte）未満の値になる。

次に、図７乃至図９を用いて、高速フレーム処理部１３５が行う送信処理及び受信処理について説明する。ここでは、送信側のＥＣＵ１３０と、受信側のＥＣＵ１３０とが予め通信を行い、共通の（同一の）リストデータを保持していることとする。

図７は、高速フレーム処理部１３５が行う送信処理のフローチャートを示す図である。ここでは、一例として、画像認識ＥＣＵ１３０Ｂの高速フレーム処理部１３５が行う送信処理について説明する。

主制御部１３５Ａは、処理をスタートする（スタート）。主制御部１３５Ａは、例えば、車両のイグニッションスイッチがオンにされたときに、処理をスタートする。

主制御部１３５Ａは、アプリケーション処理部１３６からデータＸの送信要求を受け付ける（ステップＳ１）。データＸは、アプリケーション処理部１３６が自動運転ＥＣＵ１３０Ａからバス１２０Ａ、ＣＧＷ−ＥＣＵ１１０、バス１２０、メディアアクセスコントローラ１３１、ＩＰ処理部１３３、及びＴＣＰ／ＵＤＰポート１３４を介して入手する送信データであり、データ名はＸである。

送信データ判定部１３５Ｂは、リストデータ（図４参照）を参照し、データＸのデータ名を検索する（ステップＳ２）。

送信データ判定部１３５Ｂは、データＸのデータ名が高速処理用のデータとして存在するかどうかを判定する（ステップＳ３）。

送信データ判定部１３５ＢによってデータＸのデータ名が存在する（Ｓ３：ＹＥＳ）と判定されると、高速送信処理部１３５Ｃは、高速用フレーム及び最終フレームを生成する（ステップＳ４）。なお、ステップＳ４の処理の詳細については、図８を用いて説明する。

主制御部１３５Ａは、ステップＳ４で生成された高速用フレーム及び最終フレームをＤＭＡ１３２に書き込む（ステップＳ５）。この結果、高速用フレーム及び最終フレームは、ＤＭＡ１３２によってバス１２０Ｂに出力され、ＣＧＷ−ＥＣＵ１１０及びバス１２０Ａを経由して自動運転ＥＣＵ１３０Ａに転送される。

主制御部１３５Ａは、処理を終了するかどうかを判定する（ステップＳ６）。主制御部１３５Ａは、例えば、車両のイグニッションスイッチがオフにされたときに、処理を終了すると判定する。

主制御部１３５Ａは、処理を終了する（Ｓ６：ＹＥＳ）と判定すると、一連の処理を終了する（エンド）。主制御部１３５Ａは、例えば、車両のイグニッションスイッチがオフにされたときに、処理を終了する。また、主制御部１３５Ａは、処理を終了しない（Ｓ６：ＮＯ）と判定すると、フローをステップＳ１にリターンする。

なお、ステップＳ３において、送信データ判定部１３５ＢによってデータＸのデータ名が存在しない（Ｓ３：ＮＯ）と判定された場合には、主制御部１３５Ａは、フローをステップＳ１にリターンする。次の送信データの処理を行うためである。

図８は、高速送信処理部１３５Ｃが行う送信処理のフローチャートを示す図である。図８に示すフローチャートは、ステップＳ４の詳細な処理を表す。

高速送信処理部１３５Ｃは、ステップＳ４の処理を開始（スタート）すると、データＸのデータ長ＤＬＸが、リストデータにおいてデータＸに紐付けられているデータ長ＤＬ１未満（ＤＬＸ＜ＤＬ１）であるかどうかを判定する（ステップＳ４１）。

高速送信処理部１３５Ｃは、データ長ＤＬＸがデータ長ＤＬ１未満ではない（Ｓ４１：ＮＯ）と判定すると、データＸの先頭からデータ長ＤＬ１の分を分割して高速用フレームを生成する（ステップＳ４２）。高速送信処理部１３５Ｃは、ステップＳ４２の処理を終えると、フローをステップＳ４１にリターンする。ステップＳ４２の処理が繰り返されれば、複数の高速用フレームが生成される。例えば、データＸのデータ長が７０００(Byte)でデータ長ＤＬ１が１５００(Byte)である場合には、４つの高速用フレームが生成される。

高速送信処理部１３５Ｃは、ステップＳ４１において、データ長ＤＬＸがデータ長ＤＬ１未満である（Ｓ４１：ＹＥＳ）と判定すると、データＸの残りのデータにパディングを行い、データ長ＤＬ１よりも１(Byte)短いデータ長ＤＬ２の高速用フレームを生成する（ステップＳ４３）。

例えば、データ長ＤＬ１が１５００(Byte)であり、データＸの残りのデータのデータ長が１０００（Byte）である場合には、４９９(Byte)分のパディングを行い、データ長ＤＬ２の高速用フレームとして１４９９（Byte）の最後尾の高速用フレームを生成する。

高速送信処理部１３５Ｃは、ステップＳ４３でパディングを行ったデータ長をＰＬ値として有する最終フレーム（２（Byte））を生成する（ステップＳ４４）。

以上で高速送信処理部１３５Ｃは、ステップＳ４の処理を終了（エンド）する。なお、ここでは、画像認識ＥＣＵ１３０Ｂの高速フレーム処理部１３５が行う送信処理について説明したが、自動運転ＥＣＵ１３０Ａやその他のＥＣＵの高速フレーム処理部１３５が行う送信処理も同様である。

なお、ステップＳ４３において、データＸの残りのデータのデータ長が０（Byte）である場合には、パディングを行わなくてよい。この場合には、ステップＳ４４で生成する最終フレームのＰＬ値を０（Byte）にすればよく、最後尾の高速用フレームは、ステップＳ４２で最後に分割されたデータになる。

また、ステップＳ４３において、データＸの残りのデータのデータ長が０（Byte）である場合には、ステップＳ４３で１４９９（Byte）パディングを行って最後尾の高速用フレームを生成してもよい。この場合には、ステップＳ４４で生成する最終フレームのＰＬ値を１４９９（Byte）にすればよい。

図９は、高速フレーム処理部１３５が行う受信処理のフローチャートを示す図である。ここでは、一例として、自動運転ＥＣＵ１３０Ａの高速フレーム処理部１３５が行う送信処理について説明する。

主制御部１３５Ａは、処理をスタートする（スタート）。主制御部１３５Ａは、例えば、車両のイグニッションスイッチがオンにされたときに、処理をスタートする。

受信データ判定部１３５Ｄは、リストデータを参照し、メディアアクセスコントローラ１３１にあるデータＹの送元ＭＡＣアドレス及びデータ長と照合する（ステップＳ１１）。データＹは、例えば、画像認識ＥＣＵ１３０Ｂから、バス１２０Ｂ、ＣＧＷ−ＥＣＵ１１０、及びバス１２０Ａを介して自動運転ＥＣＵ１３０Ａのメディアアクセスコントローラ１３１に転送される。

受信データ判定部１３５Ｄは、データＹの送元ＭＡＣアドレス及びデータ長に一致する送元ＭＡＣアドレス及びデータ長がリストデータに存在するかどうかを判定する（ステップＳ１２）。

受信データ判定部１３５Ｄは、一致する送元ＭＡＣアドレス及びデータ長がリストデータに存在する（Ｓ１２：ＹＥＳ）と判定すると、データＹをメディアアクセスコントローラ１３１から取り込み、データＹ（最後尾以外の高速用フレーム）のペイロードの部分のデータをアプリケーション処理部１３６に受け渡す（ステップＳ１３）。

この場合、データＹは高速用フレームであるため、アプリケーション処理部１３６に受け渡してデータＸを復元するためである。主制御部１３５Ａは、受信データ判定部１３５ＤがステップＳ１３の処理終えると、フローをステップＳ１にリターンする。

例えば、リストデータに格納されているデータ長が１５００(Byte)であり、データＹのデータ長が１５００(Byte)であり、リストデータに格納されている送元ＭＡＣアドレスとデータＹの送元ＭＡＣアドレスとが一致すると、受信データ判定部１３５Ｄは、データＹのペイロードの部分のデータをアプリケーション処理部１３６に受け渡す。

また、受信データ判定部１３５Ｄは、一致する送元ＭＡＣアドレス及びデータ長がリストデータに格納されていない（Ｓ１２：ＮＯ）と判定すると、前回の処理で高速用フレームを受信したかどうかを判定する（ステップＳ１４）。ステップＳ１５で最後尾の高速用フレームがメディアアクセスコントローラ１３１に存在するかどうかを判定する前に、前回の処理で高速用フレームを受信しているかどうかを判定することとしたものである。

受信データ判定部１３５Ｄは、前回の処理で高速用フレームを受信した（Ｓ１４：ＹＥＳ）と判定すると、ステップＳ１２において一致すると判定した送元ＭＡＣアドレスで、ステップＳ１２において一致すると判定したデータ長よりも１(Byte)短いデータ長のデータＹがメディアアクセスコントローラ１３１に存在するかどうかを判定する（ステップＳ１５）。

受信データ判定部１３５Ｄは、ステップＳ１５において存在する（Ｓ１５：ＹＥＳ）と判定すると、データＹ（最後尾の高速用フレーム）のペイロードの部分のデータをバッファ（ＲＡＭ）に格納する（ステップＳ１６）。主制御部１３５Ａは、受信データ判定部１３５ＤがステップＳ１６の処理終えると、フローをステップＳ１にリターンする。

例えば、リストデータに格納されているデータ長が１５００(Byte)であり、データＹのデータ長が１４９９(Byte)であり、リストデータに格納されている送元ＭＡＣアドレスとデータＹの送元ＭＡＣアドレスとが一致すると、受信データ判定部１３５Ｄは、１４９９(Byte)のデータＹのペイロードの部分のデータをバッファ（ＲＡＭ）に格納する。アプリケーション処理部１３６に受け渡さずに、バッファ（ＲＡＭ）に格納するのは、後の処理でパディングの部分を削除するためである。

受信データ判定部１３５Ｄは、ステップＳ１５において存在しない（Ｓ１５：ＮＯ）と判定すると、ステップＳ１２において一致すると判定した送元ＭＡＣアドレスで、データ長が２(Byte)のデータＹがメディアアクセスコントローラ１３１に存在し、かつ、バッファにペイロードの部分のデータが格納されているかどうかを判定する（ステップＳ１７）。

受信データ判定部１３５Ｄは、上述のようなデータＹがメディアアクセスコントローラ１３１に存在し、かつ、バッファにペイロードの部分のデータが格納されている（Ｓ１７：ＹＥＳ）と判定すると、メディアアクセスコントローラ１３１に存在するデータ長が２(Byte)のデータＹのＰＬ値を読み出し、バッファに格納されているペイロードの部分のデータの末尾からＰＬ値が表すデータ長の部分（パディングされた部分）を削除し、残ったデータをアプリケーション処理部１３６に受け渡す（ステップＳ１８）。この結果、アプリケーション処理部１３６は、ステップＳ１３で入手したデータと、ステップＳ１８で入手したデータとを繋ぎ合わせて、データＸを得る。

例えば、メディアアクセスコントローラ１３１に存在するデータ長が２(Byte)のデータＹのＰＬ値が４９９(Byte)である場合には、バッファに格納されているペイロードの部分のデータ（１４９９(Byte)）の末尾から４９９(Byte)の部分を削除して、残りの１０００(Byte)のデータがアプリケーション処理部１３６に受け渡される。４つの１５００(Byte)のデータと、１つの１０００(Byte)のデータとを先頭から順番に並べると、７０００(Byte)のデータＸが得られる。

主制御部１３５Ａは、ステップＳ１８の処理を終えると、処理を終了するかどうかを判定する（ステップＳ１９）。主制御部１３５Ａは、処理を終了しない（Ｓ１９：ＮＯ）と判定すると、フローをステップＳ１にリターンする。また、主制御部１３５Ａは、処理を終了する（Ｓ１９：ＹＥＳ）と判定すると、一連の処理を終了する（エンド）。主制御部１３５Ａは、例えば、車両のイグニッションスイッチがオフにされたときに、処理を終了する。

なお、受信データ判定部１３５Ｄは、上述のようなデータＹがメディアアクセスコントローラ１３１に存在し、かつ、バッファにペイロードの部分のデータが格納されている状態ではない（Ｓ１７：ＮＯ）と判定すると、データＹをＩＰ処理部１３３に受け渡す（ステップＳ２０）。

この場合には、データＹは高速処理用のデータではなく、通常処理用のデータであるため、ＩＰ処理部１３３、及びＴＣＰ／ＵＤＰポート１３４を経由して、アプリケーション処理部１３６によって受け取られる。主制御部１３５Ａは、受信データ判定部１３５ＤがステップＳ２０の処理終えると、フローをステップＳ１にリターンする。

また、受信データ判定部１３５ＤがステップＳ１４において前回の処理で高速用フレームを受信していない（Ｓ１４：ＮＯ）と判定すると、主制御部１３５Ａは、フローをステップＳ１７に進行させる。

以上のように、受信データのデータ長が高速処理用の所定のデータ長であるかどうかを判定することで、高速処理を行うかどうか判定することができる。この判定には、独自のデータ形式又はデータを用いる必要はない。

従って、独自のデータ形式や独自のデータを追加することなく、優先度の高いデータを高速で処理することができる、車載ネットワークシステム１００を提供することができる。

また、送信データを分割した最後尾のデータにパディングすることにより、最後尾以外のデータよりも１（Byte）少ないデータ長を利用するため、データを受信した受信データ判定部１３５Ｄは、データ長に基づいて受信データの最後尾のデータであることを判別できる。

従って、受信データの最後尾のデータを容易に判別でき、優先度の高いデータを高速で処理することができる、車載ネットワークシステム１００を提供することができる。

また、送信側のＥＣＵ１３０と、受信側のＥＣＵ１３０とが共通の（同一の）リストデータを保持し、リストデータには分割データのデータ長と送元ＭＡＣアドレス（識別子）とが紐付けられているので、送元ＭＡＣアドレス（識別子）とデータ長とで高速処理の対象であるかどうかを判別することにより、優先度の高いデータを高速で処理することができる、車載ネットワークシステムを提供することができる。また、送元ＭＡＣアドレス（識別子）とデータ長とを用いることにより、互いに送元ＭＡＣアドレスが異なるデータ同士のデータ長が同一であっても、データ同士を識別可能である。

なお、以上では、送信データを所定のデータ長（例えば、１５００(Byte)）の分割データに分割して、所定のデータ長にはパディングをする形態について説明したが、送信データのデータ長が所定のデータ長（例えば、１５００(Byte)）に満たない場合に、パディングを行って所定のデータ長（例えば、１５００(Byte)）にしてもよい。

そして、所定のデータ長（例えば、１５００(Byte)）の受信データを受信したＥＣＵ１３０が、所定のデータ長（例えば、１５００(Byte)）と送元ＭＡＣアドレスとに基づいて、高速処理用のデータであると判定するようにしてもよい。すなわち、送信データのデータ長が所定のデータ長（例えば、１５００(Byte)）に満たない場合には、分割処理が行われないことになる。なお、この場合には、１つの送信データの次に、パディングした分のデータ長を表すＰＬ値が記載された最終フレームを送信すればよい。

また、以上では、最後尾の受信データであることを示すデータ長が、最後尾以外の受信データのデータ長よりも１(Byte)短い形態について説明したが、データ長の差は１(Byte)に限られるものではない。

また、以上では、送元ＭＡＣアドレスとデータ長とがリストデータに格納される送元ＭＡＣアドレスとデータ長とに一致するかどうかで受信データが高速処理用のデータであるかどうかを判定する形態について説明したが、送元ＭＡＣアドレスを用いなくてもデータ長だけで判定できる場合には、送元ＭＡＣアドレスを判定に用いなくてもよい。例えば、１５００(Byte)のデータ長にするデータの種類を１種類にしておけば、送元ＭＡＣアドレスを用いなくてもデータ長だけで高速処理用のデータであるかどうかを判定することができる。

図１０は、実施の形態の変形例によるＣＧＷ−ＥＣＵ１１０Ａを示す図である。ＣＧＷ−ＥＣＵ１１０Ａは、複数のプロトコルによるデータを中継する、マルチプロトコルゲートウェイ装置である。

ＣＧＷ−ＥＣＵ１１０Ａは、メディアアクセスコントローラ１３１、ＤＭＡ１３２、ＩＰ処理部１３３、ＴＣＰポート／ＵＤＰポート１３４、高速フレーム処理部１３５、及びアプリケーション処理部１３６Ａ、ＣＡＮ(Controller Area Network)コントローラ１４１、ＬＶＤＳ(Low Voltage Differential Signaling)コントローラ１４２、ＣＡＮ通信部１４３、ＬＶＤＳ通信部１４４を有する。

なお、メディアアクセスコントローラ１３１〜高速フレーム処理部１３５は、図２に示すものと同様である。アプリケーション処理部１３６Ａは、図２に示すアプリケーション処理部１３６に、ＣＡＮプロトコル、ＬＶＤＳプロトコル、及びイーサネットプロトコルの間のデータ変換を行う機能を追加したものである。

図１０では、ＣＡＮプロトコルのデータ（メッセージ）の経路を実線で示し、ＬＶＤＳプロトコルのデータの経路を破線で示し、イーサネットプロトコルのデータの経路を二重線で示す。図１０では、ＣＧＷ−ＥＣＵ１１０Ａに接続されるバスを省略するが、ＣＧＷ−ＥＣＵ１１０Ａの外部に実線、破線、及び二重線で示す経路は、ＣＧＷ−ＥＣＵ１１０Ａに接続されるバスを通る経路である。

ＣＡＮコントローラ１４１は、ＣＡＮプロトコルのデータ（メッセージ）をバスから受け取るインターフェイスである。ＬＶＤＳコントローラ１４２は、ＬＶＤＳプロトコルのデータをバスから受け取るインターフェイスである。ＣＡＮコントローラ１４１及びＬＶＤＳコントローラ１４２は、メディアアクセスコントローラ１３１及びＤＭＡ１３２と同様にハードウェアとして構成される。

ＣＡＮ通信部１４３及びＬＶＤＳ通信部１４４は、ＩＰ処理部１３３〜アプリケーション処理部１３６ＣＰＵと同様にＣＰＵがプログラムを実行することによって得られる機能ブロックである。ＣＡＮ通信部１４３及びＬＶＤＳ通信部１４４は、ＯＳＩ参照モデルにおけるレイヤ３（ネットワーク層）に属し、それぞれ、ＣＡＮデータ及びＬＶＤＳデータの転送処理をする。

また、ここでは、一例として、カメラ１５０Ａ、１５０Ｂ、１５０ＣがＬＶＤＳ形式の画像データを出力することとする。ＬＶＤＳ形式の画像データは、ＬＶＤＳコントローラ１４２に取り込まれ、ＬＶＤＳ通信部１４４を経由してアプリケーション処理部１３６Ａに入り、ＬＶＤＳプロトコルのデータからイーサネットプロトコルのデータに変換されて、高速フレーム処理部１３５に取り込まれる。そして、高速フレーム処理部１３５からＤＭＡ１３２を経由してバスに出力される。

このときに、高速処理の対象になるＬＶＤＳプロトコルのデータのデータ名を格納するリストデータを用いれば、高速処理の対象になるＬＶＤＳプロトコルのデータをアプリケーション処理部１３６Ａでイーサネットプロトコルのデータに変換してから、さらに所定のデータ長（例えば、１５００(Byte)）に分割し、高速用フレーム及び最終フレームを生成し、ＤＭＡ１３２を経由してバスに出力すればよい。

なお、高速処理の対象になるＬＶＤＳプロトコルのデータは、アプリケーション処理部１３６Ａでイーサネットプロトコルのデータに変換してから、ＩＰ処理部１３３及びＴＣＰポート／ＵＤＰポート１３４を経由して、バスに出力すればよい。

なお、ＣＡＮプロトコルのデータは、データ長が短いことから高速処理の対象にしなくてよい。ＣＡＮコントローラ１４１に取り込まれたデータ（メッセージ）は、ＣＡＮ通信部１４３を経由してアプリケーション処理部１３６Ａでイーサネットプロトコルのデータに変換され、ＩＰ処理部１３３及びＴＣＰポート／ＵＤＰポート１３４を経由して、バスに出力するようにすればよい。

以上のように、マルチプロトコルタイプのＣＧＷ−ＥＣＵ１１０Ａにおいても、受信データのデータ長が高速処理用の所定のデータ長であるかどうかを判定することで、高速処理を行うかどうか判定することができ、独自のデータ形式や独自のデータを追加することなく、優先度の高いデータを高速で処理することができる。

以上、本発明の例示的な実施の形態の車載ネットワークシステムについて説明したが、本発明は、具体的に開示された実施の形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

１００ 車載ネットワークシステム
１１０ ＣＧＷ−ＥＣＵ
１２０Ａ、１２０Ｂ バス
１３０ ＥＣＵ
１３０Ａ 自動運転ＥＣＵ
１３０Ｂ 画像認識ＥＣＵ
１３１ メディアアクセスコントローラ
１３２ ＤＭＡ
１３３ ＩＰ処理部
１３４ ＴＣＰポート／ＵＤＰポート
１３５ 高速フレーム処理部
１３５Ａ 主制御部
１３５Ｂ 送信データ判定部
１３５Ｃ 高速送信処理部
１３５Ｄ 受信データ判定部
１３５Ｅ 高速受信処理部
１３６ アプリケーション処理部
１５０Ａ、１５０Ｂ カメラ

Claims (3)

1. 第１制御部と、第２制御部と、前記第１制御部及び前記第２制御部を接続するネットワークとを含む、車載ネットワークシステムであって、
   前記第１制御部は、
   送信データが第１処理速度よりも速い第２処理速度での高速処理の対象であるかどうかを判定する送信データ判定部と、
   前記送信データ判定部によって前記高速処理の対象ではないと判定された送信データの前記ネットワークへの送信処理を前記第１処理速度で行う第１処理部と、
   前記送信データ判定部によって前記高速処理の対象であると判定された送信データを第１データ長に分割することによって得る、又は、当該送信データに所定のデータを付け足して前記第１データ長にすることによって得る、前記第１データ長のデータの前記ネットワークへの送信処理を前記第２処理速度で行う第２処理部と
   を有し、
   前記第２制御部は、
   前記ネットワークを介して受信した受信データのデータ長が前記第１データ長であるかどうかを判定する受信データ判定部と、
   前記受信データ判定部によって前記第１データ長ではないと判定されると、前記第１処理速度で前記受信データの受信処理を行う第３処理部と、
   前記受信データ判定部によって前記第１データ長であると判定されると、前記第２処理速度で前記受信データの受信処理を行う第４処理部と
   を有する、車載ネットワークシステム。
2. 前記第２処理部は、さらに、前記送信データをフレームの先頭から第１データ長に分割する際に、前記フレームの最後尾で前記第１データ長未満のデータが生じると、当該データに所定のデータを付け足して前記第１データ長よりも所定データ長だけ短い第２データ長のデータを生成することによって得る、前記第２データ長のデータを前記第２処理速度で送信し、
   前記受信データ判定部は、さらに、前記受信データのデータ長が前記第２データ長であるかどうかを判定し、
   前記第４処理部は、前記受信データ判定部によって前記第１データ長であると判定された受信データに続く受信データが前記第２データ長であると判定されると、当該受信データが前記送信データから分割された複数の受信データのうちの最後尾の受信データのデータであると判定する、請求項１記載の車載ネットワークシステム。
3. 前記第１制御部は、
   前記高速処理の対象になる送信データの識別子と前記第１データ長とを表すリストデータをさらに有し、
   前記送信データ判定部は、前記リストデータの識別子を用いて前記送信データが前記高速処理の対象であるかどうかを判定し、
   前記第２処理部は、前記リストデータの前記第１データ長に基づいて、前記第１データ長のデータの送信処理を行い、
   前記第２制御部は、
   前記リストデータをさらに有し、
   前記受信データ判定部は、前記リストデータの前記第１データ長に基づいて、前記受信データのデータ長が前記第１データ長であるかどうかを判定する、請求項１又は２記載の車載ネットワークシステム。

Images