(57)【要約】【課題】構成や制御を簡易なものとしながらも、ペイロード長を変更することによってネットワークバスの通信負荷を軽減することが可能な車載ネットワークシステムを提供する。【解決手段】受信ノード３００は、ペイロード長情報であるＤＬＣ２４をフロー制御フレームＦＣに付加するとともに、フロー制御フレームＦＣを制御用プロトコルに従って送信ノード３００に送信する。送信ノード３００は、フロー制御フレームＦＣの受信後に送信するコンセキュティブフレームＣＦのペイロード長を、ＤＬＣ２４に基づいて決定する。【選択図】図１
2016225791.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載された機器（５０１〜５０４）を制御するために複数のノード（２００，３００，４０１〜４０４）がネットワークバス（１００）を介して制御用プロトコルに従って通信する車載ネットワークシステム（１０）であって、
前記ネットワークバスに接続され、ファーストフレームを送信する送信ノード（２００）と、
前記ネットワークバスに接続され、前記ファーストフレームの受信後にフロー制御フレームを送信する受信ノード（３００）と、を備え、
前記受信ノードは、ペイロード長に関する情報であるペイロード長情報（２４，３４）を前記フロー制御フレーム（ＦＣ）に付加するとともに、該フロー制御フレームを前記制御用プロトコルに従って前記送信ノードに送信し、
前記送信ノードは、前記フロー制御フレームの受信後に送信するコンセキュティブフレーム（ＣＦ）のペイロード長を、前記ペイロード長情報に基づいて決定することを特徴とする車載ネットワークシステム。
【請求項２】
前記受信ノードは、前記フロー制御フレームのヘッダのデータレングスコード（２４）を変更可能であり、
前記送信ノードは、前記コンセキュティブフレームのペイロード長を、該データレングスコードに基づいて決定することを特徴とする請求項１に記載の車載ネットワークシステム。
【請求項３】
前記受信ノードは、前記フロー制御フレームのペイロード（３２）に前記ペイロード長情報（３４）を付加することを特徴とする請求項１に記載の車載ネットワークシステム。
【請求項４】
前記受信ノードは、前記ネットワークバスの通信負荷が大きい場合は、該通信負荷が小さい場合と比べて前記コンセキュティブフレームのペイロード長が小さくなるように前記ペイロード長情報を決定することを特徴とする請求項２又は３に記載の車載ネットワークシステム。
【請求項５】
前記受信ノードは、前記車両に搭載された機器の故障が生じている場合は、該故障が生じていない場合と比べて前記コンセキュティブフレームのペイロード長が小さくなるように前記ペイロード長情報を決定することを特徴とする請求項２又は３に記載の車載ネットワークシステム。
【請求項６】
前記受信ノードは、前記ネットワークバスに接続されアクティブ状態にあるノードが多い場合は、該ノードが少ない場合と比べて前記コンセキュティブフレームのペイロード長が小さくなるように前記ペイロード長情報を決定することを特徴とする請求項２又は３に記載の車載ネットワークシステム。
【請求項７】
車両に搭載された機器（５０１〜５０４）を制御するために複数のノード（２００，３００，４０１〜４０４）がネットワークバス（１００）を介して制御用プロトコルに従って通信する車載ネットワークシステム（１０）であって、
前記ネットワークバスに接続され、ファーストフレームを送信する送信ノード（２００）と、
前記ネットワークバスに接続され、前記ファーストフレームの受信後にフロー制御フレームを送信する受信ノード（３００）と、を備え、
前記送信ノードは、前記ネットワークバスに接続されているノードの応答時間が長い場合は、該応答時間が短い場合と比べて、前記フロー制御フレームの受信後に送信するコンセキュティブフレーム（ＣＦ）のペイロード長を小さくすることを特徴とする車載ネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載された機器を制御するために複数のノードがネットワークバスを介して制御用プロトコルに従って通信する車載ネットワークシステムに関する。
【背景技術】
【０００２】
車両に搭載されるセンサやアクチュエータといった機器の多くは、電子制御装置によって電気的に制御されている。近年の車両の高性能化や高機能化に伴い、制御対象となる車両搭載機器は増加する傾向にある。このため、当該車両搭載機器を制御するために複数のノードが制御用プロトコルに従って通信を行う車載ネットワークシステムにおいて、ネットワークバスの通信負荷の増大は無視できないものとなっている。
【０００３】
また、高性能化や高機能化とともに、車両の安全性の確保も重要な社会的ニーズとなっている。車両の機能安全に関し導入された国際規格においても、車両に異常が発生した際に、所定時間内に車両を安全な状態に移行させることが求められている。ネットワークバスの通信負荷が過大となり、各ノードが効率良く通信を行えない状態では、このような移行も適切に行えなくなるおそれがある。
【０００４】
このような課題の解決を図るものとして、下記特許文献１に記載されたネットワークシステムが知られている。当該ネットワークシステムは、ネットワークバスを介して送受信されるフレームのペイロード長が変更可能となっている。ペイロード長を変更することによって、過大になったネットワークバスの通信負荷の軽減や各ノードの処理負荷の軽減を図り、各ノード間の通信の効率を改善することが可能となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１３−２３９８８６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記特許文献１に記載されたネットワークシステムでは、各ノードが送受信するフレームのペイロード長を決定するために、専用のプロトコルに従ってフレームの送受信を行う。すなわち、各ノードは、車両搭載機器を制御するための制御用プロトコルに従う通信に先駆けて、ペイロード長の決定のためだけに用意されたプロトコルに従ってフレームの送受信を行う。各ノードは、ペイロード長を決定した後に、当該ペイロード長のフレームを制御用プロトコルに従って送受信する。
【０００７】
このように、上記特許文献１に記載されたネットワークシステムでは、ペイロード長の決定のために、車両搭載機器の制御では通常使用しない専用プロトコルを実装する必要がある。このため、当該ネットワークシステムでは、その構成や制御が複雑になるという課題があった。また、当該ネットワークシステムは、ペイロード長を決定する際に、制御用プロトコルに従うフレームの送受信を中断する必要があるため、効率の面でも改善の余地を残していた。
【０００８】
本発明はこのような課題に鑑みてなされたものであり、その目的は、構成や制御を簡易なものとしながらも、ペイロード長を変更することによってネットワークバスの通信負荷を軽減することが可能な車載ネットワークシステムを提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明に係る車載ネットワークシステムは、車両に搭載された機器（５０１〜５０４）を制御するために複数のノード（２００，３００，４０１〜４０４）がネットワークバス（１００）を介して制御用プロトコルに従って通信する車載ネットワークシステム（１０）であって、前記ネットワークバスに接続され、ファーストフレームを送信する送信ノード（２００）と、前記ネットワークバスに接続され、前記ファーストフレームの受信後にフロー制御フレームを送信する受信ノード（３００）と、を備える。前記受信ノードは、ペイロード長に関する情報であるペイロード長情報（２４，３４）を前記フロー制御フレーム（ＦＣ）に付加するとともに、該フロー制御フレームを前記制御用プロトコルに従って前記送信ノードに送信し、前記送信ノードは、前記フロー制御フレームの受信後に送信するコンセキュティブフレーム（ＣＦ）のペイロード長を、前記ペイロード長情報に基づいて決定する。
【００１０】
本発明では、送信ノードは、フロー制御フレームの受信後に送信するコンセキュティブフレームのペイロード長を、ペイロード長情報に基づいて決定する。したがって、本発明によれば、ペイロード長情報を変更することにより、コンセキュティブフレームのペイロード長を変更してネットワークバスの通信負荷を軽減することが可能となる。
【００１１】
さらに、受信ノードは、ペイロード長情報を負荷したフロー制御フレームを、制御用プロトコルに従って送信ノードに送信する。したがって、本発明によれば、車両に搭載される機器を制御するために通常使用される制御用プロトコルに従ってペイロード長を変更することが可能となり、ペイロード長の決定のために専用プロトコルを実装する必要が無い。
【００１２】
また、上記課題を解決するために、本発明に係る車載ネットワークシステムは、車両に搭載された機器（５０１〜５０４）を制御するために複数のノード（２００，３００，４０１〜４０４）がネットワークバス（１００）を介して制御用プロトコルに従って通信する車載ネットワークシステム（１０）であって、前記ネットワークバスに接続され、ファーストフレームを送信する送信ノード（２００）と、前記ネットワークバスに接続され、前記ファーストフレームの受信後にフロー制御フレームを送信する受信ノード（３００）と、を備える。前記送信ノードは、前記ネットワークバスに接続されているノードの応答時間が長い場合は、該応答時間が短い場合と比べて、前記フロー制御フレームの受信後に送信するコンセキュティブフレーム（ＣＦ）のペイロード長を小さくする。
【００１３】
本発明でも、車両に搭載される機器を制御するために通常使用される制御用プロトコルに従って、各ノードの処理負荷に応じてペイロード長を変更することが可能となり、各ノード間の通信を効率良く行わせることが可能となる。
【発明の効果】
【００１４】
本発明によれば、構成や制御を簡易なものとしながらも、ペイロード長を変更することによってネットワークバスの通信負荷を軽減することが可能な車載ネットワークシステムを提供することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の第１実施形態に係る車載ネットワークシステムの機能的構成を示すブロック図である。
【図２】図１の送信ノードと受信ノードとのフレームの送受信を説明する説明図である。
【図３】図２のフロー制御フレームの構成を示す模式図である。
【図４】図１の受信ノードの監視部の処理の流れを示すフローチャートである。
【図５】図１の受信ノードの通信制御部の処理の流れを示すフローチャートである。
【図６】図１の送信ノードの監視部の処理の流れを示すフローチャートである。
【図７】図１の送信ノードの通信制御部の処理の流れを示すフローチャートである。
【図８】ネットワークバスの通信負荷の変化に伴うコンセキュティブフレームのペイロード長の変化の例を示すタイムチャートである。
【図９】機器の状態の変化に伴うペイロード長の変化の例を示すタイムチャートである。
【図１０】エンジン回転数の変化に伴うコンセキュティブフレームのペイロード長の変化の例を示すタイムチャートである。
【図１１】ノードの状態の変化に伴うコンセキュティブフレームのペイロード長の変化の例を示すタイムチャートである。
【図１２】本発明の第２実施形態に係るノードの最大応答時間の変化に伴うコンセキュティブフレームのペイロード長の変化の例を示すタイムチャートである。
【図１３】本発明の実施形態の変形例に係るフロー制御フレームの構成を示す模式図である。
【発明を実施するための形態】
【００１６】
以下、添付図面を参照しながら本発明の実施形態について説明する。説明の理解を容易にするため、各図面において同一の構成要素に対しては可能な限り同一の符号を付して、重複する説明は省略する。
【００１７】
まず、図１を参照しながら、本発明の第１実施形態に係る車載ネットワークシステム１０の構成について説明する。車載ネットワークシステム１０は、車両（不図示）に搭載された機器Ａ５０１，Ｂ５０２，Ｃ５０３，Ｄ５０４を制御するためのシステムである。車載ネットワークシステム１０は、複数のノードをネットワークバス１００に接続することで構成されている。各ノードは、ネットワークバス１００を介して所定のフレームを相互に送受信することによって通信可能とされている。
【００１８】
図１は、複数のノードのうち、機器Ａ５０１（例えばエンジン）を制御するノードＡ４０１と、機器Ｂ５０２（例えばステアリング装置）を制御するノードＢ４０２と、機器Ｃ５０３（例えば空調装置）を制御するノードＣ４０３と、機器５０４Ｄ（例えば照明装置）を制御するノードＤ４０４と、を模式的に示している。また、図１は、各ノードの構成の詳細を例示するものとして、送信ノード２００と、受信ノード３００と、を模式的に示している。すなわち、ノードＡ４０１〜Ｄ４０４は、いずれも後述する送信ノード２００及び受信ノード３００と同様の構成を備え得るものである。
【００１９】
各ノードは、その一部又は全部が、アナログ回路で構成されるか、デジタルプロセッサとして構成される。いずれにしても、受信した信号に基づいて制御信号を出力する機能を果たすため、各ノードには機能的な制御ブロックが構成される。
【００２０】
図１は、送信ノード２００及び受信ノード３００を機能的な制御ブロック図として示している。尚、送信ノード２００及び受信ノード３００を構成するアナログ回路又はデジタルプロセッサに組み込まれるソフトウェアのモジュールは、必ずしも図１に示す制御ブロックに分割されている必要はなく、複数の制御ブロックの働きをするものとして構成されていても構わず、更に細分化されていても構わない。後述する処理を実行できるように構成されていれば、送信ノード２００及び受信ノード３００の内部の実際の構成は当業者が適宜変更できるものである。
【００２１】
送信ノード２００は、ネットワークバス１００に接続され、監視部２１０と、通信制御部２２０と、送信データ生成部２３０と、を有している。
【００２２】
監視部２１０は、車載ネットワークシステム１０の通信に関係する種々の要素を監視する部分である。監視部２１０は、応答時間監視部２１１と、アクティブノード監視部２１２と、を有している。応答時間監視部２１１は、送信ノード２００が他のノードにフレームを送信したタイミングから、当該他のノードのアクノリッジメントを受信するタイミングまでに経過した時間である「応答時間」を監視する。また、アクティブノード監視部２１２は、車載ネットワークシステム１０に接続されている各ノードが、所定の処理を実行している状態である「アクティブ状態」と、処理を実行していない状態である「スリープ状態」のいずれにあるかを監視する。監視部２１０は、応答時間監視部２１１及びアクティブノード監視部２１２の監視結果に基づいて、通信制御部２２０に対してペイロード長の変更を要求する。
【００２３】
通信制御部２２０は、ネットワークバス１００を介した送信ノード２００の通信を制御する部分である。通信制御部２２０は、送受信制御部２２１と、フロー制御部２２２と、ペイロード長変更制御部２２３と、を有している。送受信制御部２２１は、ネットワークバス１００を介して、所定のプロトコルに従って他のノードとフレームの送受信を行う。送受信制御部２２１は、車両を通常走行させるために機器を制御する際は、予め定められた制御用プロトコルに従ってフレームの送受信を行う。フロー制御部２２２は、送信ノード２００と他のノードとのフレームの送受信において、フレームの送信レートの管理を行う。ペイロード長変更制御部２２３は、前述した監視部２１０からの要求に基づいて、送信ノード２００が送信するフレームのペイロード長の変更を行う。
【００２４】
送信データ生成部２３０は、車両に搭載された機器を制御するために必要となる所定のデータを生成する部分である。送信データ生成部２３０は、生成したデータの送信を通信制御部２２０に要求し、当該データを付加したフレームを通信制御部２２０からネットワークバス１００を介して送信する。
【００２５】
受信ノード３００は、ネットワークバス１００に接続され、監視部３１０と、通信制御部３２０と、受信データ処理部３３０と、を有している。
【００２６】
監視部３１０は、車載ネットワークシステム１０の通信に関係する種々の要素を監視する部分である。監視部３１０は、バス負荷監視部３１１と、故障状態監視部３１２と、車両状態監視部３１３と、アクティブノード監視部３１４と、を有している。バス負荷監視部３１１は、ネットワークバス１００の通信負荷を監視する。故障状態監視部３１２は、ネットワークバス１００を介した各ノードの通信によって制御される機器が、正常に動作する「正常状態」と、正常に動作することができない「故障状態」と、のいずれにあるかを監視する。車両状態監視部３１３は、車載ネットワークシステム１０が搭載される車両の状態を監視する。具体的には、車両状態監視部３１３は、当該車両のエンジンのクランキングや回転数上昇など、各ノードの処理負荷が変化する要因となる車両状態の監視を行う。アクティブノード監視部３１４は、ネットワークバス１００に接続されている各ノードが、所定の処理を実行している状態である「アクティブ状態」と、処理を実行していない状態である「スリープ状態」と、のいずれにあるかを監視する。
【００２７】
通信制御部３２０は、ネットワークバス１００を介した受信ノード３００の通信を制御する部分である。通信制御部３２０は、送受信制御部３２１と、フロー制御部３２２と、ペイロード長変更通知制御部３２３と、を有している。送受信制御部３２１は、ネットワークバス１００を介して、所定のプロトコルに従って他のノードとフレームの送受信を行う。送受信制御部３２１は、車両を通常走行させるために機器を制御する際は、予め定められた制御用プロトコルに従ってフレームの送受信を行う。フロー制御部３２２は、受信ノード３００と他のノードとのフレームの送受信において、フレームの送信レートの管理を行う。ペイロード長変更通知制御部３２３は、送信ノード２００に対してペイロード長の変更の通知を行う。
【００２８】
続いて、図２及び図３を参照しながら、送信ノード２００と受信ノード３００との通信について説明する。図２は、上方から下方にかけて時間の流れを示し、送信ノード２００と受信ノード３００との間で送受信されるフレームの送信方向を矢印で示している。
【００２９】
送信ノード２００と受信ノード３００とは、ネットワークバス１００（図１参照）を介して、国際規格（ＩＳＯ１５７６５−２）に定義されているプロトコルに従ってフレームの送受信を行っている。まず、送信ノード２００は、マルチフレームの送信開始に際し、受信ノード３００にファーストフレーム（First Frame）ＦＦを送信する。具体的には、前述した送信ノード２００の通信制御部２２０が、ネットワークバス１００を介して受信ノード３００にファーストフレームＦＦを送信する。
【００３０】
このファーストフレームＦＦを受信した受信ノード３００は、そのアクノリッジメントとして、フロー制御フレーム（Flow Control Frame）ＦＣを送信ノード２００に送信する。このフロー制御フレームＦＣでは、１つのフロー制御フレームＦＣを受信することで送信ノード２００から送信が許可されるコンセキュティブフレーム（Consecutive Frame）ＣＦの数と、各コンセキュティブフレームＣＦの送信間隔とを指定する情報が付加されている。
【００３１】
このフロー制御フレームＦＣ（２０）は、図３に示されるように、ヘッダ２１と、ペイロード２２と、フッタ２３と、から成る。
【００３２】
ヘッダ２１は、ＳＯＦ（Start Of Frame）、ＩＤ（識別子）等の複数のパケットによって構成されている。同様に、ヘッダ２１に続くペイロード２２も、ＰＣＩ（Protocol Control Information）等の複数のパケットから構成されている。
【００３３】
また、ヘッダ２１の末尾には、ＤＬＣ（Data Length Code：データレングスコード）２４が付加されている。このＤＬＣ２４は、ペイロード２２のペイロード長に関する情報（ペイロード長情報）である。
【００３４】
受信ノード３００は、このフロー制御フレームＦＣを受信した後、フロー制御フレームＦＣの指定に基づいて、コンセキュティブフレームＣＦを送信する。図２では、１つのフロー制御フレームＦＣを受信することで送信ノード２００から送信が許可されるコンセキュティブフレームの数を３、各コンセキュティブフレームＣＦの送信間隔を１０ｍｓｅｃとした場合を示している。
【００３５】
以上のように構成された車載ネットワークシステム１０では、各ノードがネットワークバス１００を介して効率良く通信を行うことを可能とするために、送受信するフレームのペイロード長を適宜変更する。具体的には、車載ネットワークシステム１０は、ネットワークバス１００の通信負荷や、各ノードの処理負荷が過大となる場合等に、フレームのペイロード長を比較的小さいものに変更して各負荷の軽減を図る。以下、図４乃至図７を参照しながら、このペイロード長の変更について詳述する。
【００３６】
図４は、受信ノード３００の監視部３１０が実行する許容受信ペイロード長Ｐｒ算出フローを示している。許容受信ペイロード長Ｐｒとは、そのときの車載ネットワークシステム１０の状態において、受信ノード３００が受信を許容できるペイロード長として最も大きい値である。
【００３７】
受信ノード３００の監視部３１０は、図４のステップＳ１１で、監視処理を実行する。すなわち、監視部３１０は、バス負荷監視部３１１によるネットワークバス１００の通信負荷の監視と、故障状態監視部３１２による機器の状態の監視と、車両状態監視部３１３による車両の状態の監視と、アクティブノード監視部３１４による各ノードの監視と、を行う。
【００３８】
次に、監視部３１０は、ステップＳ１２で、受信ノード３００が受信するフレームのペイロード長Ｐの変更が必要であるか否かを判定する。ここでは、監視部３１０は、ステップＳ１１における監視処理の結果に基づいて、ペイロード長Ｐの変更の要否を判定する。ここで行われる判定の具体的な方法については後述する。ペイロード長Ｐの変更が必要ではないと判定した場合（Ｓ１２：ＮＯ）、監視部３１０は、処理を終了する。一方、ペイロード長Ｐの変更が必要であると判定した場合（Ｓ１２：ＹＥＳ）、監視部３１０は、ステップＳ１３の処理に進む。
【００３９】
次に、監視部３１０は、ステップＳ１２で、許容受信ペイロード長Ｐｒを算出する。ここでは、監視部３１０は、ステップＳ１１における監視処理の結果に基づいて許容受信ペイロード長Ｐｒを算出する。
【００４０】
図５は、受信ノード３００の通信制御部３２０が実行するペイロード長Ｐ仮決定フローを示している。通信制御部３２０は、このペイロード長Ｐ仮決定フローを、受信ノード３００の監視部３１０が許容受信ペイロード長Ｐｒ算出フローを実行した後に実行する。ペイロード長Ｐ仮決定フローは、受信ノード３００が受信するフレームのペイロード長Ｐを最適なものに決定するために実行される処理フローである。後述するように、ペイロード長Ｐは送信ノード２００の通信制御部２２０によって変更される可能性があるため、ここでは「仮決定」と称している。
【００４１】
受信ノード３００の通信制御部３２０は、図５のステップＳ２１で、受信ノード３００がファーストフレームＦＦ（図２参照）を受信したか否かを判定する。受信ノード３００がファーストフレームＦＦを受信していないと判定した場合（Ｓ２１：ＮＯ）、通信制御部３２０は、ファーストフレームＦＦの受信を待機する。一方、受信ノード３００がファーストフレームＦＦを受信したと判定した場合（Ｓ２１：ＹＥＳ）、通信制御部３２０は、ステップＳ２２の処理に進む。
【００４２】
次に、通信制御部３２０は、ステップＳ２２で、ファーストフレームＦＦのペイロード長Ｐを取得する。具体的には、通信制御部３２０は、受信ノード３００が受信したファーストフレームＦＦの構成を確認することで、そのペイロード長Ｐを取得する。
【００４３】
次に、通信制御部３２０は、ステップＳ２３で、ファーストフレームＦＦのペイロード長Ｐが許容受信ペイロード長Ｐｒよりも大きいか否かを判定する。ファーストフレームＦＦのペイロード長Ｐが許容受信ペイロード長Ｐｒよりも大きいと判定した場合（Ｓ２３：ＹＥＳ）、すなわち、受信ノード３００が受信を許容できるものよりも大きいペイロード長のフレームを送信ノード２００が送信している場合、通信制御部３２０は、ステップＳ２４の処理に進む。
【００４４】
次に、通信制御部３２０は、ステップＳ２４で、ペイロード長Ｐを許容受信ペイロード長Ｐｒに仮決定する。すなわち、通信制御部３２０は、ペイロード長Ｐを、ファーストフレームＦＦのペイロード長Ｐよりも小さい許容受信ペイロード長Ｐｒに仮決定する。
【００４５】
次に、通信制御部３２０は、ステップＳ２５で、フロー制御フレームＦＣ（図２参照）を送信ノード２００に送信する。ここでのフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４（図３参照）は、ペイロード長Ｐとして前述のように仮決定された許容受信ペイロード長Ｐｒを特定するものである。具体的には、通信制御部３２０のペイロード長変更通知制御部３２３が、ペイロード長Ｐが許容受信ペイロード長Ｐｒに変更されたことを示す情報（ペイロード長情報）をＤＬＣ２４に付加する。
【００４６】
これに対し、ステップＳ２３で、ファーストフレームＦＦのペイロード長Ｐが許容受信ペイロード長Ｐｒよりも大きくないと判定した場合（Ｓ２３：ＮＯ）、通信制御部３２０は、ステップＳ２４の処理を実行することなくステップＳ２５の処理に進む。
【００４７】
次に、通信制御部３２０は、ステップＳ２５で、フロー制御フレームＦＣを送信ノード２００に送信する。ここでのフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４（図３参照）は、ペイロード長Ｐが前回送信したフレームのものと同一であることを示す情報（ペイロード長情報）が付加されている。
【００４８】
図６は、送信ノード２００の監視部２１０が実行する許容送信ペイロード長Ｐｔ算出フローを示している。許容送信ペイロード長Ｐｔとは、そのときの車載ネットワークシステム１０の状態において、送信ノード２００が送信を許容できるペイロード長として最も大きい値である。
【００４９】
送信ノード２００の監視部２１０は、図６のステップＳ３１で、監視処理を実行する。すなわち、監視部２１０は、応答時間監視部２１１による応答時間の監視と、アクティブノード監視部２１２による各ノードの状態の監視と、を行う。
【００５０】
次に、監視部２１０は、ステップＳ３２で、送信ノード２００が送信するフレームのペイロード長Ｐの変更が必要であるか否かを判定する。ここでは、監視部２１０は、ステップＳ３１における監視処理の結果に基づいて、ペイロード長Ｐの変更の要否を判定する。ここで行われる判定の具体的な方法については後述する。ペイロード長Ｐの変更が必要ではないと判定した場合（Ｓ３２：ＮＯ）、監視部２１０は、処理を終了する。一方、ペイロード長Ｐの変更が必要であると判定した場合（Ｓ３２：ＹＥＳ）、監視部２１０は、ステップＳ３３の処理に進む。
【００５１】
次に、監視部２１０は、ステップＳ３３で、許容送信ペイロード長Ｐｔを算出する。ここでは、監視部２１０は、前述したステップＳ３１における監視処理の結果に基づいて、許容送信ペイロード長Ｐｔを算出する。
【００５２】
図７は、送信ノード２００の通信制御部２２０が実行するペイロード長Ｐ決定フローを示している。通信制御部２２０は、このペイロード長Ｐ決定フローを、送信ノード２００の監視部２１０が前述した許容送信ペイロード長Ｐｔ算出フローを実行した後に実行する。ペイロード長Ｐ決定フローは、送信ノード２００が送信するフレームのペイロード長Ｐを最適なものに決定するために実行される処理フローであり、前述したペイロード長Ｐ仮決定フローによって仮決定したペイロード長Ｐを最終決定するものである。
【００５３】
送信ノード２００の通信制御部２２０は、図７のステップＳ４１で、送信ノード２００がフロー制御フレームＦＣ（図２参照）を受信したか否かを判定する。送信ノード２００がフロー制御フレームＦＣを受信していないと判定した場合（Ｓ４１：ＮＯ）、通信制御部２２０は、フロー制御フレームＦＣの受信を待機する。一方、送信ノード２００がフロー制御フレームＦＣを受信したと判定した場合（Ｓ４１：ＹＥＳ）、通信制御部２２０は、次にステップＳ４２の処理に進む。
【００５４】
次に、通信制御部２２０は、ステップＳ４２で、フロー制御フレームＦＣのペイロード長Ｐを取得する。具体的には、通信制御部２２０は、送信ノード２００が受信したフロー制御フレームＦＣの構成を確認することで、そのペイロード長Ｐを取得する。
【００５５】
次に、通信制御部２２０は、ステップＳ４３で、フロー制御フレームＦＣのペイロード長Ｐが許容送信ペイロード長Ｐｔよりも大きいか否かを判定する。フロー制御フレームＦＣのペイロード長Ｐが許容送信ペイロード長Ｐｔよりも大きいと判定した場合（Ｓ４３：ＹＥＳ）、すなわち、受信ノード３００が受信を許容できるものよりも大きいペイロード長のフレームを送信ノード２００が送信している場合、通信制御部２２０は、ステップＳ４４の処理に進む。
【００５６】
次に、通信制御部２２０は、ステップＳ４４で、ペイロード長Ｐを許容送信ペイロード長Ｐｔに決定する。すなわち、通信制御部２２０は、ペイロード長Ｐを、フロー制御フレームＦＣのペイロード長Ｐよりも小さい許容送信ペイロード長Ｐｔに決定する。
【００５７】
次に、通信制御部２２０は、ステップＳ４５で、コンセキュティブフレームＣＦ（図２参照）を受信ノード３００に送信する。ここでのコンセキュティブフレームＣＦのペイロード長Ｐは、Ｓ４４で決定されたように許容送信ペイロード長Ｐｔと同一のものである。
【００５８】
これに対し、ステップＳ４３で、フロー制御フレームＦＣのペイロード長Ｐが許容送信ペイロード長Ｐｔよりも大きくないと判定した場合（Ｓ４３：ＮＯ）、通信制御部２２０は、ステップＳ４４の処理を実行することなくステップＳ４５の処理に進む。
【００５９】
次に、通信制御部２２０は、ステップＳ４５で、コンセキュティブフレームＣＦを受信ノード３００に送信する。ここでのコンセキュティブフレームＣＦのペイロード長Ｐは、Ｓ４２で取得したフロー制御フレームＦＣのペイロード長Ｐと同一のものである。
【００６０】
続いて、図８乃至図１１を参照しながら、図４に示されるステップＳ１２や図６に示されるステップＳ３２におけるペイロード長の変更要否の判定について説明する。
【００６１】
図８は、受信ノード３００のバス負荷監視部３１１が監視しているネットワークバス１００の通信負荷と、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐの変化を示している。
【００６２】
図８に示されるように、時刻ｔ１１までは、ネットワークバス１００の通信負荷は比較的小さいため、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐは比較的大きい６４バイトに設定される。
【００６３】
時刻ｔ１１で、ネットワークバス１００の通信負荷が予め定められた閾値Ｌ１を上回ると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０は、ネットワークバス１００の通信負荷が閾値Ｌ１を上回ったことで、各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４（図３参照）を、ペイロード長Ｐが４８バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、６４バイトから４８バイトに減少する。
【００６４】
ネットワークバス１００の通信負荷がさらに増加し、時刻ｔ１２で、予め定められた閾値Ｌ２を上回ると、監視部３１０はペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが３２バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、４８バイトから３２バイトに減少する。
【００６５】
時刻ｔ１２後にネットワークバス１００の通信負荷が減少し、時刻ｔ１３で閾値Ｌ２以下になると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、受信ノード３００は、ネットワークバス１００の通信負荷が閾値Ｌ２以下になったことで、各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが４８バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、３２バイトから４８バイトに増加する。
【００６６】
ネットワークバス１００の通信負荷がさらに減少し、時刻ｔ１４で閾値Ｌ１以下になると、監視部３１０はペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが６４バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、４８バイトから６４バイトに増加する。
【００６７】
以上のように、受信ノード３００は、ネットワークバス１００の通信負荷が大きい場合は、該通信負荷が小さい場合と比べて送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが小さくなるようにペイロード長情報であるＤＬＣ２４を決定する。これにより、各ノード間の通信を効率良く行わせることが可能となる。
【００６８】
図９は、受信ノード３００の故障状態監視部３１２が監視している機器Ａ〜Ｄの故障の有無と、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐの変化を示している。
【００６９】
図９に示されるように、時刻ｔ２１までは、機器Ａ〜Ｄのいずれも正常状態であるため、各ノードの処理負荷は比較的小さい。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐは比較的大きい６４バイトに設定される。
【００７０】
時刻ｔ２１で、機器Ｂが故障状態になると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、１つの機器が故障状態になったことで、各ノードの処理負荷が上昇したと判定し、当該処理負荷を軽減して各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４（図３参照）を、ペイロード長Ｐが４８バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、６４バイトから４８バイトに減少する。
【００７１】
時刻ｔ２２で、機器Ａも故障状態になると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０は、２つの機器が故障状態になったことで、各ノードの処理負荷がさらに上昇したと判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが３２バイトとなるように設定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、４８バイトから３２バイトに減少する。
【００７２】
時刻ｔ２３で、機器Ｂのみが正常状態に復帰すると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、故障状態にある機器が１つに減少したことで、各ノードの処理負荷が低下したと判定し、各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが４８バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、３２バイトから４８バイトに増加する。
【００７３】
時刻ｔ２４で、機器Ａも正常状態に復帰すると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０は、すべての機器が正常状態になったことで、各ノードの処理負荷がさらに低下したと判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが６４バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、４８バイトから６４バイトに増加する。
【００７４】
以上のように、受信ノード３００は、車両に搭載された機器の故障が生じている場合は、該故障が生じていない場合と比べて送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが小さくなるように、ペイロード長情報であるＤＬＣ２４を決定する。これにより、車両に搭載された機器の故障に応じて、各ノード間の通信を効率良く行わせることが可能となる。
【００７５】
図１０は、受信ノード３００の車両状態監視部３１３が監視する車両状態と、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐの変化を示している。
【００７６】
時刻ｔ３１で、ユーザがイグニションスイッチをＯＦＦ状態からＯＮ状態に切り替えると、車両のエンジン回転数が増加を開始する。時刻ｔ３１では、ネットワークバス１００の通信負荷が比較的小さいため、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐは比較的大きい６４バイトに設定される。
【００７７】
時刻ｔ３２で、エンジン回転数が予め定められた閾値Ｎ１を上回ると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０は、エンジン回転数が閾値Ｎ１を上回ったことで、ネットワークバス１００の通信負荷が大きくなったと判定し、各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣ（２０）のヘッダ２１のＤＬＣ２４（図３参照）を、ペイロード長Ｐが４８バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、６４バイトから４８バイトに減少する。
【００７８】
エンジン回転数がさらに増加し、時刻ｔ３３で、予め定められた閾値Ｎ２を上回ると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０は、エンジン回転数が閾値Ｎ１よりも大きい閾値Ｎ２を上回ったことで、ネットワークバス１００の通信負荷がさらに大きくなったと判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが３２バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、４８バイトから３２バイトに減少する。
【００７９】
時刻ｔ３３後にエンジン回転数が減少し、時刻ｔ３４で閾値Ｎ２以下になると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０は、エンジン回転数が閾値Ｎ２以下になったことで、ネットワークバス１００の通信負荷が小さくなったと判定し、各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが４８バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、３２バイトから４８バイトに増加する。
【００８０】
エンジン回転数がさらに減少し、時刻ｔ３５で閾値Ｎ１以下になると、監視部３１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０は、エンジン回転数が閾値Ｎ１以下になったことで、ネットワークバス１００の通信負荷がさらに小さくなったと判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが６４バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、４８バイトから６４バイトに増加する。
【００８１】
以上のように、受信ノード３００は、車両状態に基づいてネットワークバス１００の通信負荷を判定するとともに、ネットワークバス１００の通信負荷が大きい場合は、通信負荷が小さい場合と比べて送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが小さくなるように、ペイロード長情報であるＤＣＬ２４を決定する。これにより、各ノード間の通信を効率良く行わせることが可能となる。
【００８２】
図１１は、受信ノード３００のアクティブノード監視部３１４又は送信ノード２００のアクティブノード監視部２１２が監視する各ノードの状態と、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐの変化を示している。
【００８３】
図１１に示されるように、時刻ｔ４１までは、ノードＡ４０１，Ｂ４０２，Ｃ４０３，Ｄ４０４（図１参照）の全てがアクティブ状態であるため、ネットワークバス１００の通信負荷が比較的大きい。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐは比較的小さい１６バイトに設定される。
【００８４】
時刻ｔ４１で、ノードＡ４０１がスリープ状態になると、監視部３１０や監視部２１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０や監視部２１０は、１つのノードがスリープ状態になったことで、ネットワークバス１００の通信負荷が低下したと判定し、各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４（図３参照）を、ペイロード長Ｐが３２バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、１６バイトから３２バイトに増加する。
【００８５】
時刻ｔ４２で、ノードＢ４０２もスリープ状態になると、監視部３１０や監視部２１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０や監視部２１０は、２つのノードがスリープ状態になったことで、ネットワークバス１００の通信負荷がさらに低下したと判定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、３２バイトから４８バイトに増加する。
【００８６】
時刻ｔ４３で、さらにノードＣ４０３もスリープ状態となると、監視部３１０や監視部２１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０や監視部２１０は、３つのノードがスリープ状態になったことで、ネットワークバス１００の通信負荷がさらに低下したと判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが６４バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、４８バイトから６４バイトに増加する。
【００８７】
時刻ｔ４４で、ノードＡ４０１及びノードＢ４０２が正常状態に復帰すると、監視部３１０や監視部２１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０や監視部２１０は、２つのノードがアクティブ状態に復帰したことで、ネットワークバス１００の通信負荷が上昇したと判定し、各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが３２バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、６４バイトから３２バイトに減少する。
【００８８】
時刻ｔ４５で、ノードＣ４０３もアクティブ状態に復帰すると、監視部３１０や監視部２１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部３１０や監視部２１０は、すべてのノードがアクティブ状態になったことで、ネットワークバス１００の通信負荷が上昇したと判定する。これに基づき、受信ノード３００は、送信ノード２００に送信するフロー制御フレームＦＣのヘッダ２１のＤＬＣ２４を、ペイロード長Ｐが１６バイトとなるように決定する。したがって、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが、３２バイトから１６バイトに減少する。
【００８９】
以上のように、受信ノード３００は、ネットワークバス１００に接続されアクティブ状態にあるノードが多い場合は、該ノードが少ない場合と比べて送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐが小さくなるように、ペイロード長情報であるＤＬＣ２４を決定する。これにより、ネットワークバス１００の負荷に応じて、各ノード間の通信を効率良く行わせることが可能となる。
【００９０】
続いて、図１２を参照しながら、本発明の第２実施形態について説明する。第２実施形態は、送信ノード２００自身がコンセキュティブフレームＣＦのペイロード長を変更する点で前述した第１実施形態と同一の構成を備えている。したがってここでは、前述した第１実施形態と異なる点のみ説明する。
【００９１】
図１２は、送信ノード２００の応答時間監視部２１１が監視している各ノードの応答時間のうち最大のもの（ノード最大応答時間）と、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐの変化を示している。
【００９２】
図１２に示されるように、時刻ｔ５１までは、ノード最大応答時間は比較的小さいため、送信ノード２００が送信するコンセキュティブフレームＣＦのペイロード長Ｐは比較的大きい６４バイトに設定される。
【００９３】
時刻ｔ５１で、ノード最大応答時間が予め定められた閾値Ｔ１を上回ると、監視部２１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部２１０は、ノード最大応答時間が閾値Ｔ１を上回ったことで、各ノードの処理負荷が上昇したと判定し、各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、送信ノード２００は、コンセキュティブフレームＣＦのペイロード長Ｐを４８バイトに設定する。
【００９４】
ノード最大応答時間がさらに増加し、時刻ｔ５２で、予め定められた閾値Ｔ２を上回ると、監視部２１０はペイロード長Ｐの変更が必要と判定する。これに基づき、送信ノード２００は、コンセキュティブフレームＣＦのペイロード長Ｐを３２バイトに設定する。
【００９５】
時刻ｔ５３後にノード最大応答時間が減少し、時刻ｔ５３で閾値Ｔ２以下になると、監視部２１０はペイロード長Ｐの変更が必要と判定する。すなわち、監視部２１０は、ノード最大応答時間が閾値Ｔ２以下になったことで、各ノードの通信の効率を改善するためにペイロード長Ｐの変更が必要と判定する。これに基づき、送信ノード２００は、コンセキュティブフレームＣＦのペイロード長Ｐを４８バイトに設定する。
【００９６】
ノード最大応答時間がさらに減少し、時刻ｔ５４で閾値Ｔ１以下になると、監視部２１０はペイロード長Ｐの変更が必要と判定する。これに基づき、送信ノード２００は、コンセキュティブフレームＣＦのペイロード長Ｐを６４バイトに設定する。
【００９７】
以上のように、送信ノード２００は、ネットワークバス１００に接続されているノードの応答時間が長い場合は、該応答時間が短い場合と比べて送信するコンセキュティブフレームＣＦのペイロード長Ｐを小さくする。これにより、各ノードの処理負荷に応じて、各ノード間の通信を効率良く行わせることが可能となる。
【００９８】
続いて、本発明の実施形態の変形例に係るフロー制御フレームについて図１３を参照しながら説明する。本変形例に係るフロー制御フレームＦＣ（３０）は、国際規格（ＩＳＯ１５７６５−２）に従って構成されており、ヘッダ３１と、ペイロード３２と、フッタ３３と、から成る。
【００９９】
本変形例に係るフロー制御フレームＦＣ（３０）は、前述した実施形態に係るフロー制御フレームＦＣ（２０）と異なり、ＤＬＣ（Data Length Code）３４がペイロード３２の末尾に付加されている。このＤＬＣ２４は、ペイロード２２のペイロード長に関する情報（ペイロード長情報）である。これにより、前述した前述した実施形態に係るフロー制御フレームＦＣ（２０）と同様の効果を奏することができる。
【０１００】
以上、具体例を参照しつつ本発明の実施の形態について説明した。しかし、本発明はこれらの具体例に限定されるものではない。すなわち、これら具体例に、当業者が適宜設計変更を加えたものも、本発明の特徴を備えている限り、本発明の範囲に包含される。前述した各具体例が備える各要素およびその配置、条件などは、例示したものに限定されるわけではなく適宜変更することができる。
【０１０１】
例えば、前述した実施形態では、送信ノード２００の監視部２１０が応答時間監視部２１１及びアクティブノード監視部２１２の各機能部を有し、受信ノード３００の監視部３１０がバス負荷監視部３１１、故障状態監視部３１２、車両状態監視部３１３及びアクティブノード監視部３１４の各機能部を有しているが、本発明はこれに限定されるものではない。すなわち、これらの機能部を送信ノード２００の監視部２１０と受信ノード３００の監視部３１０のいずれに配置するかは、ネットワークトポロジーに応じて当業者が適宜選択することができるものである。
【符号の説明】
【０１０２】
１０：車載ネットワークシステム
２１，３１：ヘッダ
２２，３２：ペイロード
２４，３４：データレングスコード（ペイロード長情報）
１００：ネットワークバス
２００：送信ノード
３００：受信ノード
４０１，４０２，４０３，４０４：ノード
５０１，５０２，５０３，５０４：機器
ＣＦ：コンセキュティブフレーム
ＦＣ：フロー制御フレーム
Ｐ：ペイロード長
【図１】
2016225791.tif 000003
【図２】
2016225791.tif 000004
【図３】
2016225791.tif 000005
【図４】
2016225791.tif 000006
【図５】
2016225791.tif 000007
【図６】
2016225791.tif 000008
【図７】
2016225791.tif 000009
【図８】
2016225791.tif 000010
【図９】
2016225791.tif 000011
【図１０】
2016225791.tif 000012
【図１１】
2016225791.tif 000013
【図１２】
2016225791.tif 000014
【図１３】
2016225791.tif 000015