データ伝送システム
【課題】データリンク層レベルまで考量して、デッドラインを保証したリアルタイム通信を実現する。
【解決手段】論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、各ノードは、各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、前記要求されたデータ送信のデッドライン保証が可能か否か判定するスケジュール可能性判定手段と、あらかじめ定められたタイミングでフレームを送信する送信制御手段と、を有し、前記スケジュール可能性判定手段は、全ての通信タスクについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信する。
【解決手段】論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、各ノードは、各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、前記要求されたデータ送信のデッドライン保証が可能か否か判定するスケジュール可能性判定手段と、あらかじめ定められたタイミングでフレームを送信する送信制御手段と、を有し、前記スケジュール可能性判定手段は、全ての通信タスクについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ伝送システムに関し、特に遅延保証を可能とするデータ伝送システムに関する。
【背景技術】
【０００２】
近年、自動車などを構成する各部の機構が電動化され電子制御化される傾向にある。このように、操作情報を電気信号に置き換え、コンピュータで制御することにより機器を操縦するシステムはＸｂｙＷｉｒｅと呼ばれる。例えば、ブレーキやスロットル、ステアリングといった従来は機械的な結合で操作されていた機構が、モータを利用した機構に置き換えられる。このような電気信号（制御データ）の通信では、ミリ秒オーダー以下のリアルタイム性の確保が必要となる。
【０００３】
また、このような車載ネットワークに種々の機器が接続されることが予想される。例えば、車載カメラは画像データを送信するものであるので、大容量のデータが送信される。さらに、車載カメラの安全支援等の用途が増えるに従い搭載数が増えることが予想され、それらの映像を伝送するためにさらなる広帯域が求められる。
【０００４】
今後予想されるこのような状況において、ＸｂｙＷｉｒｅに代表される厳しいリアルタイムが要求されるトラフィックと、映像などの比較的リアルタイム性は低いものの広帯域が要求されるトラフィックの混在を可能とし、かつ、各リアルタイム性を満足するデータ伝送システムが必要とされる。
【０００５】
本発明者は、データリンク層よりも上の層においてデータ送信のトラフィック量を管理・調整してリアルタイム性を確保する技術を発明し出願済みである（特許文献１）。
【特許文献１】特開２００７−７４２１８号公報
【特許文献２】特開２００４−１５１５２号公報
【特許文献３】特開２００３−２９８５９９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１はネットワーク層での送出のリアルタイム性を保証する技術である。あるノードから送信されたデータの伝送遅延を、データリンク層レベル以下で保証する技術は知られていない。
【０００７】
そこで、本発明は、リアルタイム通信において、データリンク層レベルまでを考慮してデッドラインを保証した通信を実現することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、以下の構成によって上記目的を達成する。
【０００９】
本発明は、論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、各ノードは、各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、前記要求されたデータ送信のデッドライン保証が可能か否かを判定し、デッドライン保証可能であれば、該要求されたデータ送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、固定長のフレームを送信し、上流ノードから受信したフレームを下流ノードへ転送するとともに、あらかじめ定められたタイミングで自ノードからのフレームを送信する送信制御手
段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信することを特徴とする。
【００１０】
論理的なリング型ネットワークには、ネットワークが物理的にリング型になっているネットワーク以外のネットワークも含まれる。すなわち、各ノードがデータの受信は上流ノードから行い、データの送信は下流ノードへ行うことで、全体として通信路がリング型となっているネットワークであれば、物理的形態を問わずに含むものである。なお、以下本明細書中では「リング型ネットワーク」の語は、このような論理的な意味で用いる。
【００１１】
本データ伝送システムでは、固定長のフレームを採用するとともに、各ノードのフレーム送信タイミングがあらかじめ定められている。したがって、あるノードにおいてフレームの送信要求があってから、そのフレームがネットワーク内の他のノード（送信先ノード）に送信されるまでの時間の最大値（最悪遅延時間）は、送信タイミングが来るまでの待ち時間と、ネットワーク全体にフレームが送信される転送時間との合計として求められる。これらはいずれも固定された値であるため、本データ伝送システムにおいては、この最悪遅延時間以内でのフレームの送信が保証されることになる。
【００１２】
また、本データ伝送システムでは、各ノードのフレーム送信タイミングがあらかじめ定められているので、各ノードは単位時間あたりに所定量のデータを伝送できることが保証される。
【００１３】
そして、上記のようにデータ転送量が保証された上で、スケジュール可能性判定手段が、データ送信のデッドラインを保証できる場合だけその通信要求を登録する。したがって、ネットワーク内の全てのノードについてデータ送信のデッドラインを保証することが可能となる。
【００１４】
本発明におけるスケジュール可能性判定手段は、デッドラインモノトニック（Deadline
Monotonic）法によって、すでに登録された通信タスク及び要求されたデータ送信の全てについてデッドライン保証が可能であるか判定することが好適である。
【００１５】
より具体的には、送信要求受付手段が受け付けるデータ送信要求には、情報として、データ送信の送信周期、１周期あたりの送信データ量及び各周期におけるデッドラインが含まれることが好ましい。ここで、各周期におけるデッドラインは送信周期と同じか送信周期よりも短い時間である。
【００１６】
まず、スケジュール可能性判定手段は、１周期あたりの送信データ量及び自ノードの通信速度から、要求されたデータ送信に要する送信所要時間を算出する。次に、スケジュール可能性判定手段は、送信周期、算出した送信所要時間、及びデッドラインを用いてデッドラインモノトニック法によって、スケジュール可能性を判定する。
【００１７】
なお、スケジュール可能性判定手段は、送信周期、送信所要時間、及びデッドラインが、デッドライン保証可能な必要十分条件を満たすか否かを判定する必要はなく、デッドライン保証可能なための十分条件を満たすか否かのみを判定するようにしても良い。デッドラインモノトニック法では、必要十分条件の判定は複雑であり処理に時間を要するため、処理の軽い十分条件での判定を用いることも好ましい。
【００１８】
本データ伝送システムにおいては、少なくとも１つのノードが、各ノードにおけるフレ
ームの送信順序を管理するフレーム割当管理手段を有することが好適である。フレーム割当管理手段は、各ノードのフレーム送信タイミングをあらかじめ定義した送信順序テーブルを有する。そして、各ノードの送信制御手段は、この送信順序テーブルにしたがってフレームの送信を行うことも好適である。ここで、送信順序テーブルにおいて、１周期（サイクル）における各ノードのフレーム送信回数が同じであれば、各ノードに与えられる通信帯域（単位時間あたりに送信可能なデータ量）が均等になる。一方、必要とする通信帯域が多いノードほど、１周期内における送信回数を多く定めれば、そのようなノードに広い通信帯域を与えることができる。
【００１９】
また、本発明におけるスケジュール可能性判定手段は、データ送信の実行要求がデッドライン保証不可能であると判定された場合に、前記フレーム割当管理手段に対して、自ノードに対するフレーム割当量の増加を要求することが好適である。
【００２０】
このようにすれば、データ送信の実行要求が動的に変化する場合であっても、フレーム割当量を増加することで、動的に対応することが可能となる。
【００２１】
また、本発明における送信制御手段は、登録された通信タスクのデータをフレーム長よりも短い固定長に分割し、前記優先度に応じた順序で分割データを組み立ててフレームを生成して送信することが好ましい。
【００２２】
このように短いデータに分割することで、サイズは大きいが優先度の低いデータを送信している際に優先度の高いデータ送信が要求された場合に即座に対応することができる。
【００２３】
また、各ノードには１又は複数の周辺デバイスが接続されており、送信要求受付手段は周辺デバイスからデータ送信の実行要求を受け付けても良い。また、送信要求受付手段は、各ノードの内部に格納されたデバイスやアプリケーションプログラムから、データ送信の実行要求を受け付けても良い。
【００２４】
なお、本発明は、上記手段の少なくとも一部を有するデータ伝送システムとして捉えることができる。また、本発明は、上記処理の少なくとも一部を含むデータ伝送方法、または、かかる方法を実現するためのプログラムとして捉えることもできる。上記手段及び処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【００２５】
また、本発明における各ノードに１又は複数の周辺デバイスが接続され、各ノードがこれら周辺デバイス間での通信を中継する場合には、リング型に接続された各ノードの全体を、１つのネットワーク中継装置として捉えることができる。
【発明の効果】
【００２６】
データリンク層レベルまで考慮して、デッドラインを保証するリアルタイム通信が可能となる。
【発明を実施するための最良の形態】
【００２７】
（第１の実施形態）
〈システム概要〉
図１に本実施形態に係るデータ伝送システムの概要図を示す。図１Ａに示すように、本データ伝送システム１は、複数のノード２をリング状に接続したリング型のネットワークを形成している。また、各ノードには１つ又は複数の周辺デバイス３が接続されている。
【００２８】
このようなデータ伝送システム１の具体例として、車両内ネットワークを挙げることができる。その場合、周辺デバイス３には、エンジン、ブレーキ、アクセル、車載カメラ、
レーダー、シート、ドアなどの装置の状態を検知するセンサや、それらの装置を制御する電子制御装置（ＥＣＵ）が含まれる。そして、複数のノード２は、これらの周辺デバイス３をスター型に接続するハブであると捉えることができる。
【００２９】
各ノード２は、固定長のフレームを隣接するノードに対して送信する。定常状態においては、図１Ａに示すように、リング中を複数の固定長のフレームが同時に流れることになる。
【００３０】
１つのノードについて着目すると、図１Ｂに示すように、隣接ノードからのフレームを受信し、必要があればこのフレームを自ノードで処理するとともにさらに下流の隣接ノードに対して送信（転送）する。したがって、このようなリング型のネットワークでは、通信回線のビジー／アイドルの判定が容易である。また、フレームの衝突を回避できる。
【００３１】
自ノードが送信したフレームは、ネットワーク内の全てのノードによって転送されて自ノードまで戻ってくる。したがって、自ノードが送信したフレームが１周して戻ってきたことを確認することで、ネットワーク内の全てのノードにこのフレームが到達したことを確認できる。１周して戻ってきたフレームは、送信元のノードが破棄することで、ネットワーク内から取り除かれる。
【００３２】
図１Ａにはリング型のネットワークトポロジーを示したが、本実施形態では論理的にリング型になっていれば、実際の物理的なトポロジーについてはどのようなものでも採用できる。
【００３３】
基本的には、ノード間の接続に全二重可能な媒体を採用することで、どのような接続形態でもリング型の通信を実現することは可能である。図２，３に採用可能な物理的なトポロジーの例を示した。図に示すように、物理的なトポロジーとして、リング型（図２Ａ）、スター型（図２Ｂ）、バス型（図２Ｃ）、ディジーチェーン型（図３Ａ，Ｂ）を採用可能である。また、１対１の接続（図３Ｃ）もリング型に含まれる。
【００３４】
通信リンクを半二重とすることも可能であるが、リング型以外の物理トポロジーでは半二重の場合には通信効率が落ちる。ただし、バス型は同時に１ノードしか通信できないので、リングが全二重であっても通信効率が悪い。また、複数の中継を行う箇所（スター型のハブ、ディジーチェーン型の途中等）がある場合には、その部分が通信速度のボトルネックとなりうる（特にスター型のハブ）。
【００３５】
このように、物理的なトポロジーはどのような形態であっても良いものの、物理的にもリング型となっていることが好適である。したがって、以下では、特に断りの無い限り物理的なトポロジーもリング型であるとして説明する。
【００３６】
〈機能構成及び処理フロー〉
図４は、ノード２の機能構成を示す図である。各ノード２は、データ送信管理部２１、フレームスケジューラ２２、受信インタフェース２３、及び送信インタフェース２４を備える。図４では、１つのノードについてのみ各機能部を記載しているが、これらの機能部は全てのノード２が共通して備えている。また、ネットワーク内の１つのノード（図ではノードＡ）は、さらに、各ノードのフレーム送信順序を管理するフレーム割当管理部５を備える。
【００３７】
データ送信管理部２１の詳細については後述するが、周辺デバイス３からの通信タスクの要求を受け付け、デッドラインを守って送信可能であるか否かのスケジュール可能性判定を行う。デッドラインを保証できる場合は通信タスクの登録を受け付けるが、デッドラ
インを保証できない場合には登録を拒否する。このようにすることで、データ送信管理部２１は、各通信タスクがデッドラインまでに通信相手先までデータが到達することを保証できる。すなわち、ネットワーク層レベルで通信のデッドライン保証を行う。
【００３８】
フレームスケジューラ２２は、フレーム割当管理部５から指示されたタイミングで自ノードからフレームを送信する。詳細は後述するが、このようにあらかじめ定められた送信順序でフレームスケジューラ２２がフレーム送信を行うことで、送出したフレームが所定時間内に通信相手先まで到達することを保証する。すなわち、データリンク層レベルで通信のデッドライン保証を行う。
【００３９】
これらの各機能部は、メモリに格納されたプログラムをＣＰＵが実行することで実現されても良いし、チップや回路などの専用のハードウェアで実現されても良い。また、ソフトウェアとハードウェアの混合によって実現されても良い。
【００４０】
［データリンク層レベル］
まず、フレームスケジューラ２２が行うフレーム制御処理、つまり、データリンク層レベルでのリアルタイム性を保証する仕組みを説明する。図５に、各ノードが行うフレーム制御処理のフローチャートを示す。
【００４１】
まず、各ノードは、受信インタフェース２３を介して、隣接ノード（上流ノード）からフレームを受信する（Ｓ１０）。受信されたフレームは、フレームスケジューラ２２に渡される。受信フレームを自ノードに接続されている周辺デバイスに送信する必要があれば、その処理を行う（Ｓ１２）。この判定は、フレームに含まれる宛先情報に自ノード配下の周辺デバイスが指定されているかを判断することで行える。
【００４２】
次に、フレームスケジューラ２２は、フレーム割当管理部５から通知される送信順序テーブルを参照して、自ノードの送信順序であるか否かを判定する（Ｓ１４）。図６に送信順序テーブルの例を示す。図６は、リング型ネットワークがノードＡ〜Ｄの４つのノードで構成される場合の送信順序テーブルの例であり、１サイクルを４等分して各ノードに１回ずつの送信タイミングを割り当てている。なお、１サイクルあたりに各ノードの送信タイミングは１回のみである必要はなく、図７に示すように各ノードに１サイクルあたり複数回の送信タイミングが割り当てられても良い。
【００４３】
自ノードの送信順である場合（Ｓ１４−ＹＥＳ）は、送信バッファからデータを取得して送信する（Ｓ１６）。なお、送信順序テーブルは、１サイクルの時間を１つのフレームがリング型ネットワークを１周する時間の整数倍として定義することが好ましい。このようにすれば、自ノードの送信タイミングにおいては、以前に自ノードが送信したフレームが周回して戻ってくることになる。
【００４４】
一方、自ノードの送信順でない場合（Ｓ１４−ＮＯ）は、受信したフレームは自ノードが送信したものではないので、これを隣接ノード（下流ノード）に対して転送する（Ｓ１８）。
【００４５】
このように、フレームスケジューラ２２がフレーム割当管理部５から通知される送信順序テーブルにしたがってフレームを送信することで、送信したフレームが他のノードまで送信されるのに要する時間（最悪転送遅延時間）を制御することができる。
【００４６】
送信順序テーブルの１サイクルあたりに送信されるフレーム数をＮとする。また、１秒間にいくつのサイクルがリング内を回るかを表すサイクル周波数をＨ（Ｈｚ）とする。また、１フレームのフレーム長をＬ（バイト）とする。
【００４７】
フレーム長は、ネットワーク内で送信されるデータ長にあわせて設計することが好ましい。小さいデータが頻繁に送信される場合にはフレーム長Ｌを小さく、大きいデータが頻繁に送信される場合にはフレーム長Ｌを大きくすることが好適である。
【００４８】
例えば、Ｌ＝１２８バイトとすることができる。この場合、ネットワーク帯域(データ
転送速度)が１Ｇｂｐｓ(bit per second)であれば、１秒あたりに１００００００個のフ
レームが各ノードから送信される。そして、ＮとＨの関係は、Ｎ×Ｈ＝１００００００を満たす範囲で適宜設定可能である。例えば、Ｎ＝１２５個・Ｈ＝８ｋＨｚや、Ｎ＝４個・Ｈ＝２５０ｋＨｚなどとすることができる。
【００４９】
さて、あるフレームがネットワーク内を１周する、すなわち、ネットワーク内の全ノードまで展開される時間（１サイクルの所要時間）をＴとする。この場合、そのフレームが送信元ノードより実際に送信されてから送信先ノードまで送信されるのに要する時間は、Ｔ未満となる。
【００５０】
また、あるノードでフレームの送信要求があってから実際に送信されるまでには、送信タイミングが得られるまでの待ち時間が発生する。この待ち時間Ｍは、そのノードに割り当てられたフレームの間隔の最大値より小さくなる。フレーム間隔の最大値は、１サイクルに１回の送信タイミングしか与えられていない場合の値であり、上記のＴと等しくなる。
【００５１】
したがって、あるノードで送信要求があってから、そのフレームが送信先のノードまでに到達するのに要する最長時間（最悪転送遅延時間）Ｗは、Ｗ＜Ｔ＋Ｍ≦２Ｔとなる。
【００５２】
最悪転送遅延時間として、８μｓが要求される場合には、Ｔ＝４μｓ以下とする必要がある。すなわち、Ｈ＝２５０ｋＨｚ以上とする必要があることが分かる。このように、必要とするリアルタイム性に合わせて、送信順序テーブルを適宜設計することで、最悪遅延時間を保証することができる。
【００５３】
次に、具体的な送信順序テーブルの例を用いて、各ノードに割り当てる通信帯域（単位時間あたりのデータ転送量）を容易に設定可能であることを説明する。
【００５４】
図８は、ノード数が４であり、１サイクルあたり８個のフレームを送出するとして定義された送信順序テーブルである。ここでは、４つのノードにはそれぞれ均等にフレーム送出機会が与えられており、したがって各ノードに割り当てられる通信帯域は均等になる。例えば、ネットワーク帯域を１Ｇｂｐｓとすると、各ノードに与えられる帯域は、１Ｇｂｐｓ／８×２＝２５６Ｍｂｐｓとなることが分かる。
【００５５】
各ノードに割り当てる通信帯域を変える場合には、必要とする通信帯域が多いノードに対して１サイクル内におけるフレーム送出機会を多く与えればよい。図９は、このように各ノードに与えるフレーム送出機会に差を設けた場合であり、１サイクルあたり、ノードＡは４回、ノードＢは２回、ノードＣ，Ｄは１回のフレーム送出機会を与えられている。
【００５６】
この場合、ノードＡは、１Ｇｂｐｓ／８×４＝５１２Ｍｂｐｓの通信帯域が与えられる。ノードＢは、１Ｇｂｐｓ／８×２＝２５６Ｍｂｐｓの通信帯域が与えられる。ノードＣ，Ｄには、１Ｇｂｐｓ／８＝１２８Ｍｂｐｓの通信帯域が与えられる。
【００５７】
このように、送信順序テーブルを用いて各ノードに送信機会を割り当てることで、各ノードの通信帯域を容易に設定することができる。また、各ノードは、送信順序テーブルを
参照することで、自ノードに割り当てられている通信帯域を知ることができる。
【００５８】
［ネットワーク層レベル］
次に、データ送信管理部２１が行う通信タスクの登録可否判定処理について説明する。つまり、ネットワーク層レベルでのリアルタイム性を保証する仕組みについて説明する。
【００５９】
図１０に、データ送信管理部２１の詳細な機能ブロック図を示す。データ送信管理部２１は、送信要求受付部２１１、通信速度取得部２１２、スケジュール可能性判定部２１３、及び通信タスク管理テーブル２１４を備える。
【００６０】
送信要求受付部２１１は、周辺デバイス４からデータ（パケット）送信の要求を受け付ける。送信要求受付部２１１が受け付けるパケット送信の要求は、一定周期ごとに所定のデータ量を送信する必要があり、送信開始から所定の時間（デッドライン）以内にデータの送信を完了する必要がある。
【００６１】
図１１は、周期的なパケット送信の通信タスクを説明する図である。図１１Ａに示すように、一定周期Ｔごとに所定量のパケットを送信する必要がある。また、この送信を完了する制限時間であるデッドラインＤが定められている。なお、パケットの送信はデッドライン以内に完了すれば、正しく処理されたものとみなされる。したがって、図１１Ｂに示すように、複数の通信タスクが存在する状況では、各通信タスクのデータを連続して送信する必要はなく、他の通信タスクによる割り込みが発生しても構わない。
【００６２】
通信速度取得部２１２は、ノード２のが単位時間あたりに送信可能なデータ転送量（以下、データ送信速度ともいう）をフレーム割当管理部５から通知される送信順序テーブルから取得する。上述したように、ネットワーク帯域と自ノードに割り当てられるフレーム送信機会とから自ノードのデータ送信速度を求めることができる。
【００６３】
スケジュール可能性判定部２１３は、送信要求受付部２１１が受け付けたパケット送信の要求について、デッドラインを守って送信することができるか否か判定する。デッドライン保証が可能であれば、通信タスク管理テーブル２１４に、実行すべき通信タスクとして登録する。
【００６４】
図１２を参照して、スケジュール可能性判定部２１３が行う、スケジュール可能性判定処理について説明する。
【００６５】
まず、通信速度取得部２１２がフレーム割当量からデータ送信速度を算出する（Ｓ２０）。スケジュール可能性判定部２１３は、算出されたデータ送信速度を取得する。
【００６６】
ステップＳ２１で、送信要求受付部２１１が受け付けたパケット送信要求と、実行する通信タスクとして通信タスク管理テーブル２１４に格納されているタスクとを合計した場合に必要な、単位時間あたりのデータ転送量を算出する。これは、Σ（各送信の送信データ量／周期）によって求めることができる。
【００６７】
次に、ステップＳ２２で、算出した単位時間あたりのデータ転送量が、ステップＳ２０で算出した単位時間あたりに送信可能な転送量（データ送信速度）以内であるか判定する。ここで、要求されたパケット送信を加えた場合のデータ転送量が最大転送量を超える転送量となる場合は、ステップＳ２６に進み、受け付けたパケット送信要求を登録しないで、その実行を拒否する。一方、算出したデータ転送量が最大転送量以内である場合は、ステップＳ２３に進む。
【００６８】
ステップＳ２３では、要求されたパケット送信の１周期の送信に要する送信所要時間を計算する。送信所要時間は、１周期あたりのデータ転送量を、通信速度取得部２１２から取得した自ノードのデータ送信速度で割ることによって求めることができる。つまり、（送信所要時間）＝（１周期あたりのデータ転送量）／（データ送信速度）、によって求めることができる。
【００６９】
スケジュール可能性判定部２１３は、ステップＳ２４で、デッドラインモノトニック法を利用して、すでに登録された通信タスク及び要求されたパケット送信についてデッドラインを保証できるか判定を行う。
【００７０】
デッドラインモノトニック法では、各パケット送信の周期、１周期あたりの送信所要時間、及びデッドラインを用いる。これらの情報に基づいてスケジュール可能性を判定する判断方法については、既知の如何なる方法を用いてもかまわない。例えば、スケジュール可能性の必要十分条件となる判定式を用いても良いし、十分条件を用いても良い。
【００７１】
スケジュール可能性の十分条件を表す判定式としては、例えば、以下の判定式を用いることができる。
【００７２】
【数１】
【００７３】
なお、Ｔｉ，Ｃｉ，Ｄｉは、それぞれ通信タスクｉの周期、送信所要時間、デッドラインである。また、通信タスクｉは、ｉ＝１の通信タスクが最も優先度が高く、ｉが大きくなるにしたがって優先度が小さくなる。
【００７４】
また、
【数２】
は、ｘ以上の最小整数を表す。
【００７５】
この他の判定式については、例えば、以下の文献などに記載されている。
Audsley, Burns, Richardson, Wellings, "Hard Real-Time Scheduling: The Deadline-Monotonic Approach", Proceedings of the 8th IEEE Workshop on Real-Time Operating Systems and Software, 1991
【００７６】
このような判定式にしたがってスケジュール可能性の判定を行い、すでに登録された通信タスクと要求された通信タスクの全てについてデッドラインを守ることができる場合には、ステップＳ２５に進んで、要求されたパケット送信を、実行する通信タスクとして、通信タスク管理テーブル２１４に格納する。デッドラインを保証できない場合には、ステップＳ２６に進み、受け付けたパケット送信を登録せず、その実行を拒否する。
【００７７】
なお、ステップＳ２２の判定を行わずにステップＳ２４の判定だけでスケジュール可能性を判定できるため、ステップＳ２１，Ｓ２２の処理は省略してもかまない。ただし、Ｄ
Ｍ法による判定は処理負荷が大きいため、ステップＳ２２のような簡単な判定でスケジュール可能性を満たさないことを先に判断するのは有効である。
【００７８】
次に、登録された通信タスクのデータを送信する処理について、図１３，１４を参照して説明する。図１３に示すように、各ノードは、登録された通信タスクのパケットを細かい単位（例えば４８バイト）に分割して、通信タスク毎の送信キューに格納しておく。そして、この細かく分割したデータ（エレメントフレームと呼ぶ）を組み立てて、例えば１５００バイトのフレームを生成してまとめて送信する。ここで、パケットのエレメントフレームへの分割は、ノード２側で行っても良く、周辺デバイス４側で行っても良い。
【００７９】
フレームスケジューラ２２が行う、フレーム組み立ての処理について図１４を参照して説明する。フレームスケジューラ２２は、未送信のデータがある通信タスクの中から、最も高い優先度を持つ通信タスクを選択する（Ｓ３０）。ここで、通信タスクはデッドラインが短いものほど高い優先度が設定される。そして、選択された通信タスクのバッファ（送信キュー）からエレメントフレームを１つ取り出しで、フレームを構築する（Ｓ３１）。フレームが完成したか、すなわち１５００バイトなどの固定長に達したかが判断され（Ｓ３２）、フレームが完成していない場合には、ステップＳ３０に戻る。フレームが完成したら、そのフレームを送信バッファに格納する。フレームスケジューラ２２は、次の送信タイミングで、送信バッファからこのフレームをとりだして送信する（Ｓ３３）。
【００８０】
〈実施形態の効果〉
まず、リング型ネットワークを構築し、送信順序テーブルによって各ノードのフレーム送信タイミングを規定することで、あるノードから送出されたフレームがリング型ネットワーク内の全ノードまで到達する時間（到達遅延）及びノード間の通信速度を保証することができる。
【００８１】
そして、データ送信管理部が、デッドラインモノトニック法によってデッドラインを保証可能な通信タスクのみを受け付ける。これにより、周辺デバイス間で通信を行う場合の通信を、デッドラインを保証することができる。なお、デッドラインモノトニック法で使用するデータ通信速度が上述のように保証されているので、通信タスクのデッドライン保証がより正確なものとなる。
【００８２】
このように、あるノードで受け取られたデータが相手ノードに到達するまでの最悪遅延時間を保証することができるため、送信側と受信側の通信以外での処理に必要を加えることで、処理も含めたエンド・トゥー・エンドの処理時間を算出することが可能となる。
【００８３】
また、送信を要求されたデータを細かい単位に分割してから再度組み立てる構成としているので、優先度は低いがサイズの大きいデータの送信を要求された後に、優先度の高いデータ送信を要求された場合でも、優先度の高いデータがブロックされることがない。
【００８４】
（第２の実施形態）
第２の実施形態は、主に、スケジュール可能性判定部２１３が行う処理が第１の実施形態と異なり、その他については第１の実施形態と同様である。したがって、同様の部分については説明を省略する。
【００８５】
図１５は、本実施形態におけるスケジュール可能性判定部２１３のスケジュール可能性判定処理を示すフローチャートである。図１５の処理のうち、第１の実施形態（図１２）と異なる点は、ステップＳ２７の処理が加わっている点である。
【００８６】
ステップＳ２２でデータ転送量が自ノードに割り当てられた最大転送量を超えると判定
された場合、又は、ステップＳ２４でデッドラインモノトニック法によって要求された通信タスクのデッドラインを保証できないと判定された場合に、すぐに通信タスクの登録を拒否するのではなく、ステップＳ２７に進んで、フレーム割当管理部５に対してフレーム割当量の増加を要求する。
【００８７】
フレーム割当管理部５は、フレーム割当量の増加を求められた場合には、フレームの割当て増加が可能であるか判断する。なお、このように後からフレームの割当量を増加できうるように、当初の送信順序テーブルには空きスロットを設けておき、各ノードからの要求に応じて送信タイミングを割り当てればよい。
【００８８】
あるいは、次のような構成を採用しても良い。すなわち、各ノードは通常時においては割り当てられたスロットの全てを使用しないようにする。例えば、フレーム割当管理部５は、各ノードに１サイクルあたりＮ回の送信機会（スロット）を与えるが、ノード側では１サイクルあたりＮ−ｋ回（例えばｋ＝２）の送信しか行わないこととする。各ノードが使用している１サイクルあたりのスロット数はフレーム割当管理部５に通知されることとし、フレーム割当管理部５で集中管理できるようにしておく。そして、あるノードでデッドラインが守れないと判断した場合は、まず割り当てられた送信機会を全て使用する。それでもデッドラインを守れない場合には、ステップＳ２７においてフレーム割当量の増加を要求する。フレーム割当管理部５は、他のノードに割り当てられているがそのノードが使用していないタイムスロットがある場合には、そのタイムスロットを増加要求したノードに対して割り当てることとしても良い。
【００８９】
フレーム割当量の増加要求が受け入れられた場合には、ステップＳ２０に戻って再びスケジュール可能性の判定を行う。一方、増加要求が受け入れられなかった場合には、要求された通信タスクの登録を拒否する。
【００９０】
このように送信順序テーブルにおける各ノードへのフレーム割当量を動的に変化させることで、第１の実施形態の効果に加えて、動的に変化する通信要求に対しても対応することが可能となる。
【００９１】
（変形例）
上記の実施形態では、ノード２のデータ送信制御部２１に対してデータの送信を要求するのは、ノード２に接続された周辺デバイス３であるとして説明した。しかしながら、データの送信を要求するのは、ノード２に組み込まれたＥＣＵ等のデバイスであってもかまわない。また、ノード２内のアプリケーションプログラムがデータの送信を要求してもかまわない。
【図面の簡単な説明】
【００９２】
【図１】第１の実施形態に係るデータ伝送システムの構成の概要を示す図である。
【図２】第１の実施形態に係るデータ伝送システムに採用可能な物理的なネットワークトポロジーの例を示す図である。
【図３】第１の実施形態に係るデータ伝送システムに採用可能な物理的なネットワークトポロジーの例を示す図である。
【図４】各ノードの機能構成を示す図である。
【図５】第１の実施形態における、フレーム送信制御処理の流れを示すフローチャートである。
【図６】第１の実施形態における送信順序テーブルの例を示す図である。
【図７】第１の実施形態における送信順序テーブルの例を示す図である。
【図８】第１の実施形態における送信順序テーブルの例を示す図である。
【図９】第１の実施形態における送信順序テーブルの例を示す図である。
【図１０】第１の実施形態におけるデータ送信管理部の機能構成を示す図である。
【図１１】第１の実施形態において要求される、周期通信タスクを説明する模式図である。
【図１２】第１の実施形態におけるスケジュール可能性判定処理の流れを示すフローチャートである。
【図１３】第１の実施形態におけるフレーム送信処理を説明する図である。
【図１４】第１の実施形態におけるフレーム送信処理の流れを示すフローチャートである。
【図１５】第２の実施形態におけるスケジュール可能性判定処理の流れを示すフローチャートである。
【符号の説明】
【００９３】
１ データ伝送システム
２ ノード
３ 周辺デバイス
５ フレーム割当管理部
２１ データ送信管理部
２２ フレームスケジューラ
２３ 受信インタフェース（Ｉ／Ｆ）
２４ 送信インタフェース（Ｉ／Ｆ）
【技術分野】
【０００１】
本発明は、データ伝送システムに関し、特に遅延保証を可能とするデータ伝送システムに関する。
【背景技術】
【０００２】
近年、自動車などを構成する各部の機構が電動化され電子制御化される傾向にある。このように、操作情報を電気信号に置き換え、コンピュータで制御することにより機器を操縦するシステムはＸｂｙＷｉｒｅと呼ばれる。例えば、ブレーキやスロットル、ステアリングといった従来は機械的な結合で操作されていた機構が、モータを利用した機構に置き換えられる。このような電気信号（制御データ）の通信では、ミリ秒オーダー以下のリアルタイム性の確保が必要となる。
【０００３】
また、このような車載ネットワークに種々の機器が接続されることが予想される。例えば、車載カメラは画像データを送信するものであるので、大容量のデータが送信される。さらに、車載カメラの安全支援等の用途が増えるに従い搭載数が増えることが予想され、それらの映像を伝送するためにさらなる広帯域が求められる。
【０００４】
今後予想されるこのような状況において、ＸｂｙＷｉｒｅに代表される厳しいリアルタイムが要求されるトラフィックと、映像などの比較的リアルタイム性は低いものの広帯域が要求されるトラフィックの混在を可能とし、かつ、各リアルタイム性を満足するデータ伝送システムが必要とされる。
【０００５】
本発明者は、データリンク層よりも上の層においてデータ送信のトラフィック量を管理・調整してリアルタイム性を確保する技術を発明し出願済みである（特許文献１）。
【特許文献１】特開２００７−７４２１８号公報
【特許文献２】特開２００４−１５１５２号公報
【特許文献３】特開２００３−２９８５９９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１はネットワーク層での送出のリアルタイム性を保証する技術である。あるノードから送信されたデータの伝送遅延を、データリンク層レベル以下で保証する技術は知られていない。
【０００７】
そこで、本発明は、リアルタイム通信において、データリンク層レベルまでを考慮してデッドラインを保証した通信を実現することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、以下の構成によって上記目的を達成する。
【０００９】
本発明は、論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、各ノードは、各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、前記要求されたデータ送信のデッドライン保証が可能か否かを判定し、デッドライン保証可能であれば、該要求されたデータ送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、固定長のフレームを送信し、上流ノードから受信したフレームを下流ノードへ転送するとともに、あらかじめ定められたタイミングで自ノードからのフレームを送信する送信制御手
段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信することを特徴とする。
【００１０】
論理的なリング型ネットワークには、ネットワークが物理的にリング型になっているネットワーク以外のネットワークも含まれる。すなわち、各ノードがデータの受信は上流ノードから行い、データの送信は下流ノードへ行うことで、全体として通信路がリング型となっているネットワークであれば、物理的形態を問わずに含むものである。なお、以下本明細書中では「リング型ネットワーク」の語は、このような論理的な意味で用いる。
【００１１】
本データ伝送システムでは、固定長のフレームを採用するとともに、各ノードのフレーム送信タイミングがあらかじめ定められている。したがって、あるノードにおいてフレームの送信要求があってから、そのフレームがネットワーク内の他のノード（送信先ノード）に送信されるまでの時間の最大値（最悪遅延時間）は、送信タイミングが来るまでの待ち時間と、ネットワーク全体にフレームが送信される転送時間との合計として求められる。これらはいずれも固定された値であるため、本データ伝送システムにおいては、この最悪遅延時間以内でのフレームの送信が保証されることになる。
【００１２】
また、本データ伝送システムでは、各ノードのフレーム送信タイミングがあらかじめ定められているので、各ノードは単位時間あたりに所定量のデータを伝送できることが保証される。
【００１３】
そして、上記のようにデータ転送量が保証された上で、スケジュール可能性判定手段が、データ送信のデッドラインを保証できる場合だけその通信要求を登録する。したがって、ネットワーク内の全てのノードについてデータ送信のデッドラインを保証することが可能となる。
【００１４】
本発明におけるスケジュール可能性判定手段は、デッドラインモノトニック（Deadline
Monotonic）法によって、すでに登録された通信タスク及び要求されたデータ送信の全てについてデッドライン保証が可能であるか判定することが好適である。
【００１５】
より具体的には、送信要求受付手段が受け付けるデータ送信要求には、情報として、データ送信の送信周期、１周期あたりの送信データ量及び各周期におけるデッドラインが含まれることが好ましい。ここで、各周期におけるデッドラインは送信周期と同じか送信周期よりも短い時間である。
【００１６】
まず、スケジュール可能性判定手段は、１周期あたりの送信データ量及び自ノードの通信速度から、要求されたデータ送信に要する送信所要時間を算出する。次に、スケジュール可能性判定手段は、送信周期、算出した送信所要時間、及びデッドラインを用いてデッドラインモノトニック法によって、スケジュール可能性を判定する。
【００１７】
なお、スケジュール可能性判定手段は、送信周期、送信所要時間、及びデッドラインが、デッドライン保証可能な必要十分条件を満たすか否かを判定する必要はなく、デッドライン保証可能なための十分条件を満たすか否かのみを判定するようにしても良い。デッドラインモノトニック法では、必要十分条件の判定は複雑であり処理に時間を要するため、処理の軽い十分条件での判定を用いることも好ましい。
【００１８】
本データ伝送システムにおいては、少なくとも１つのノードが、各ノードにおけるフレ
ームの送信順序を管理するフレーム割当管理手段を有することが好適である。フレーム割当管理手段は、各ノードのフレーム送信タイミングをあらかじめ定義した送信順序テーブルを有する。そして、各ノードの送信制御手段は、この送信順序テーブルにしたがってフレームの送信を行うことも好適である。ここで、送信順序テーブルにおいて、１周期（サイクル）における各ノードのフレーム送信回数が同じであれば、各ノードに与えられる通信帯域（単位時間あたりに送信可能なデータ量）が均等になる。一方、必要とする通信帯域が多いノードほど、１周期内における送信回数を多く定めれば、そのようなノードに広い通信帯域を与えることができる。
【００１９】
また、本発明におけるスケジュール可能性判定手段は、データ送信の実行要求がデッドライン保証不可能であると判定された場合に、前記フレーム割当管理手段に対して、自ノードに対するフレーム割当量の増加を要求することが好適である。
【００２０】
このようにすれば、データ送信の実行要求が動的に変化する場合であっても、フレーム割当量を増加することで、動的に対応することが可能となる。
【００２１】
また、本発明における送信制御手段は、登録された通信タスクのデータをフレーム長よりも短い固定長に分割し、前記優先度に応じた順序で分割データを組み立ててフレームを生成して送信することが好ましい。
【００２２】
このように短いデータに分割することで、サイズは大きいが優先度の低いデータを送信している際に優先度の高いデータ送信が要求された場合に即座に対応することができる。
【００２３】
また、各ノードには１又は複数の周辺デバイスが接続されており、送信要求受付手段は周辺デバイスからデータ送信の実行要求を受け付けても良い。また、送信要求受付手段は、各ノードの内部に格納されたデバイスやアプリケーションプログラムから、データ送信の実行要求を受け付けても良い。
【００２４】
なお、本発明は、上記手段の少なくとも一部を有するデータ伝送システムとして捉えることができる。また、本発明は、上記処理の少なくとも一部を含むデータ伝送方法、または、かかる方法を実現するためのプログラムとして捉えることもできる。上記手段及び処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【００２５】
また、本発明における各ノードに１又は複数の周辺デバイスが接続され、各ノードがこれら周辺デバイス間での通信を中継する場合には、リング型に接続された各ノードの全体を、１つのネットワーク中継装置として捉えることができる。
【発明の効果】
【００２６】
データリンク層レベルまで考慮して、デッドラインを保証するリアルタイム通信が可能となる。
【発明を実施するための最良の形態】
【００２７】
（第１の実施形態）
〈システム概要〉
図１に本実施形態に係るデータ伝送システムの概要図を示す。図１Ａに示すように、本データ伝送システム１は、複数のノード２をリング状に接続したリング型のネットワークを形成している。また、各ノードには１つ又は複数の周辺デバイス３が接続されている。
【００２８】
このようなデータ伝送システム１の具体例として、車両内ネットワークを挙げることができる。その場合、周辺デバイス３には、エンジン、ブレーキ、アクセル、車載カメラ、
レーダー、シート、ドアなどの装置の状態を検知するセンサや、それらの装置を制御する電子制御装置（ＥＣＵ）が含まれる。そして、複数のノード２は、これらの周辺デバイス３をスター型に接続するハブであると捉えることができる。
【００２９】
各ノード２は、固定長のフレームを隣接するノードに対して送信する。定常状態においては、図１Ａに示すように、リング中を複数の固定長のフレームが同時に流れることになる。
【００３０】
１つのノードについて着目すると、図１Ｂに示すように、隣接ノードからのフレームを受信し、必要があればこのフレームを自ノードで処理するとともにさらに下流の隣接ノードに対して送信（転送）する。したがって、このようなリング型のネットワークでは、通信回線のビジー／アイドルの判定が容易である。また、フレームの衝突を回避できる。
【００３１】
自ノードが送信したフレームは、ネットワーク内の全てのノードによって転送されて自ノードまで戻ってくる。したがって、自ノードが送信したフレームが１周して戻ってきたことを確認することで、ネットワーク内の全てのノードにこのフレームが到達したことを確認できる。１周して戻ってきたフレームは、送信元のノードが破棄することで、ネットワーク内から取り除かれる。
【００３２】
図１Ａにはリング型のネットワークトポロジーを示したが、本実施形態では論理的にリング型になっていれば、実際の物理的なトポロジーについてはどのようなものでも採用できる。
【００３３】
基本的には、ノード間の接続に全二重可能な媒体を採用することで、どのような接続形態でもリング型の通信を実現することは可能である。図２，３に採用可能な物理的なトポロジーの例を示した。図に示すように、物理的なトポロジーとして、リング型（図２Ａ）、スター型（図２Ｂ）、バス型（図２Ｃ）、ディジーチェーン型（図３Ａ，Ｂ）を採用可能である。また、１対１の接続（図３Ｃ）もリング型に含まれる。
【００３４】
通信リンクを半二重とすることも可能であるが、リング型以外の物理トポロジーでは半二重の場合には通信効率が落ちる。ただし、バス型は同時に１ノードしか通信できないので、リングが全二重であっても通信効率が悪い。また、複数の中継を行う箇所（スター型のハブ、ディジーチェーン型の途中等）がある場合には、その部分が通信速度のボトルネックとなりうる（特にスター型のハブ）。
【００３５】
このように、物理的なトポロジーはどのような形態であっても良いものの、物理的にもリング型となっていることが好適である。したがって、以下では、特に断りの無い限り物理的なトポロジーもリング型であるとして説明する。
【００３６】
〈機能構成及び処理フロー〉
図４は、ノード２の機能構成を示す図である。各ノード２は、データ送信管理部２１、フレームスケジューラ２２、受信インタフェース２３、及び送信インタフェース２４を備える。図４では、１つのノードについてのみ各機能部を記載しているが、これらの機能部は全てのノード２が共通して備えている。また、ネットワーク内の１つのノード（図ではノードＡ）は、さらに、各ノードのフレーム送信順序を管理するフレーム割当管理部５を備える。
【００３７】
データ送信管理部２１の詳細については後述するが、周辺デバイス３からの通信タスクの要求を受け付け、デッドラインを守って送信可能であるか否かのスケジュール可能性判定を行う。デッドラインを保証できる場合は通信タスクの登録を受け付けるが、デッドラ
インを保証できない場合には登録を拒否する。このようにすることで、データ送信管理部２１は、各通信タスクがデッドラインまでに通信相手先までデータが到達することを保証できる。すなわち、ネットワーク層レベルで通信のデッドライン保証を行う。
【００３８】
フレームスケジューラ２２は、フレーム割当管理部５から指示されたタイミングで自ノードからフレームを送信する。詳細は後述するが、このようにあらかじめ定められた送信順序でフレームスケジューラ２２がフレーム送信を行うことで、送出したフレームが所定時間内に通信相手先まで到達することを保証する。すなわち、データリンク層レベルで通信のデッドライン保証を行う。
【００３９】
これらの各機能部は、メモリに格納されたプログラムをＣＰＵが実行することで実現されても良いし、チップや回路などの専用のハードウェアで実現されても良い。また、ソフトウェアとハードウェアの混合によって実現されても良い。
【００４０】
［データリンク層レベル］
まず、フレームスケジューラ２２が行うフレーム制御処理、つまり、データリンク層レベルでのリアルタイム性を保証する仕組みを説明する。図５に、各ノードが行うフレーム制御処理のフローチャートを示す。
【００４１】
まず、各ノードは、受信インタフェース２３を介して、隣接ノード（上流ノード）からフレームを受信する（Ｓ１０）。受信されたフレームは、フレームスケジューラ２２に渡される。受信フレームを自ノードに接続されている周辺デバイスに送信する必要があれば、その処理を行う（Ｓ１２）。この判定は、フレームに含まれる宛先情報に自ノード配下の周辺デバイスが指定されているかを判断することで行える。
【００４２】
次に、フレームスケジューラ２２は、フレーム割当管理部５から通知される送信順序テーブルを参照して、自ノードの送信順序であるか否かを判定する（Ｓ１４）。図６に送信順序テーブルの例を示す。図６は、リング型ネットワークがノードＡ〜Ｄの４つのノードで構成される場合の送信順序テーブルの例であり、１サイクルを４等分して各ノードに１回ずつの送信タイミングを割り当てている。なお、１サイクルあたりに各ノードの送信タイミングは１回のみである必要はなく、図７に示すように各ノードに１サイクルあたり複数回の送信タイミングが割り当てられても良い。
【００４３】
自ノードの送信順である場合（Ｓ１４−ＹＥＳ）は、送信バッファからデータを取得して送信する（Ｓ１６）。なお、送信順序テーブルは、１サイクルの時間を１つのフレームがリング型ネットワークを１周する時間の整数倍として定義することが好ましい。このようにすれば、自ノードの送信タイミングにおいては、以前に自ノードが送信したフレームが周回して戻ってくることになる。
【００４４】
一方、自ノードの送信順でない場合（Ｓ１４−ＮＯ）は、受信したフレームは自ノードが送信したものではないので、これを隣接ノード（下流ノード）に対して転送する（Ｓ１８）。
【００４５】
このように、フレームスケジューラ２２がフレーム割当管理部５から通知される送信順序テーブルにしたがってフレームを送信することで、送信したフレームが他のノードまで送信されるのに要する時間（最悪転送遅延時間）を制御することができる。
【００４６】
送信順序テーブルの１サイクルあたりに送信されるフレーム数をＮとする。また、１秒間にいくつのサイクルがリング内を回るかを表すサイクル周波数をＨ（Ｈｚ）とする。また、１フレームのフレーム長をＬ（バイト）とする。
【００４７】
フレーム長は、ネットワーク内で送信されるデータ長にあわせて設計することが好ましい。小さいデータが頻繁に送信される場合にはフレーム長Ｌを小さく、大きいデータが頻繁に送信される場合にはフレーム長Ｌを大きくすることが好適である。
【００４８】
例えば、Ｌ＝１２８バイトとすることができる。この場合、ネットワーク帯域(データ
転送速度)が１Ｇｂｐｓ(bit per second)であれば、１秒あたりに１００００００個のフ
レームが各ノードから送信される。そして、ＮとＨの関係は、Ｎ×Ｈ＝１００００００を満たす範囲で適宜設定可能である。例えば、Ｎ＝１２５個・Ｈ＝８ｋＨｚや、Ｎ＝４個・Ｈ＝２５０ｋＨｚなどとすることができる。
【００４９】
さて、あるフレームがネットワーク内を１周する、すなわち、ネットワーク内の全ノードまで展開される時間（１サイクルの所要時間）をＴとする。この場合、そのフレームが送信元ノードより実際に送信されてから送信先ノードまで送信されるのに要する時間は、Ｔ未満となる。
【００５０】
また、あるノードでフレームの送信要求があってから実際に送信されるまでには、送信タイミングが得られるまでの待ち時間が発生する。この待ち時間Ｍは、そのノードに割り当てられたフレームの間隔の最大値より小さくなる。フレーム間隔の最大値は、１サイクルに１回の送信タイミングしか与えられていない場合の値であり、上記のＴと等しくなる。
【００５１】
したがって、あるノードで送信要求があってから、そのフレームが送信先のノードまでに到達するのに要する最長時間（最悪転送遅延時間）Ｗは、Ｗ＜Ｔ＋Ｍ≦２Ｔとなる。
【００５２】
最悪転送遅延時間として、８μｓが要求される場合には、Ｔ＝４μｓ以下とする必要がある。すなわち、Ｈ＝２５０ｋＨｚ以上とする必要があることが分かる。このように、必要とするリアルタイム性に合わせて、送信順序テーブルを適宜設計することで、最悪遅延時間を保証することができる。
【００５３】
次に、具体的な送信順序テーブルの例を用いて、各ノードに割り当てる通信帯域（単位時間あたりのデータ転送量）を容易に設定可能であることを説明する。
【００５４】
図８は、ノード数が４であり、１サイクルあたり８個のフレームを送出するとして定義された送信順序テーブルである。ここでは、４つのノードにはそれぞれ均等にフレーム送出機会が与えられており、したがって各ノードに割り当てられる通信帯域は均等になる。例えば、ネットワーク帯域を１Ｇｂｐｓとすると、各ノードに与えられる帯域は、１Ｇｂｐｓ／８×２＝２５６Ｍｂｐｓとなることが分かる。
【００５５】
各ノードに割り当てる通信帯域を変える場合には、必要とする通信帯域が多いノードに対して１サイクル内におけるフレーム送出機会を多く与えればよい。図９は、このように各ノードに与えるフレーム送出機会に差を設けた場合であり、１サイクルあたり、ノードＡは４回、ノードＢは２回、ノードＣ，Ｄは１回のフレーム送出機会を与えられている。
【００５６】
この場合、ノードＡは、１Ｇｂｐｓ／８×４＝５１２Ｍｂｐｓの通信帯域が与えられる。ノードＢは、１Ｇｂｐｓ／８×２＝２５６Ｍｂｐｓの通信帯域が与えられる。ノードＣ，Ｄには、１Ｇｂｐｓ／８＝１２８Ｍｂｐｓの通信帯域が与えられる。
【００５７】
このように、送信順序テーブルを用いて各ノードに送信機会を割り当てることで、各ノードの通信帯域を容易に設定することができる。また、各ノードは、送信順序テーブルを
参照することで、自ノードに割り当てられている通信帯域を知ることができる。
【００５８】
［ネットワーク層レベル］
次に、データ送信管理部２１が行う通信タスクの登録可否判定処理について説明する。つまり、ネットワーク層レベルでのリアルタイム性を保証する仕組みについて説明する。
【００５９】
図１０に、データ送信管理部２１の詳細な機能ブロック図を示す。データ送信管理部２１は、送信要求受付部２１１、通信速度取得部２１２、スケジュール可能性判定部２１３、及び通信タスク管理テーブル２１４を備える。
【００６０】
送信要求受付部２１１は、周辺デバイス４からデータ（パケット）送信の要求を受け付ける。送信要求受付部２１１が受け付けるパケット送信の要求は、一定周期ごとに所定のデータ量を送信する必要があり、送信開始から所定の時間（デッドライン）以内にデータの送信を完了する必要がある。
【００６１】
図１１は、周期的なパケット送信の通信タスクを説明する図である。図１１Ａに示すように、一定周期Ｔごとに所定量のパケットを送信する必要がある。また、この送信を完了する制限時間であるデッドラインＤが定められている。なお、パケットの送信はデッドライン以内に完了すれば、正しく処理されたものとみなされる。したがって、図１１Ｂに示すように、複数の通信タスクが存在する状況では、各通信タスクのデータを連続して送信する必要はなく、他の通信タスクによる割り込みが発生しても構わない。
【００６２】
通信速度取得部２１２は、ノード２のが単位時間あたりに送信可能なデータ転送量（以下、データ送信速度ともいう）をフレーム割当管理部５から通知される送信順序テーブルから取得する。上述したように、ネットワーク帯域と自ノードに割り当てられるフレーム送信機会とから自ノードのデータ送信速度を求めることができる。
【００６３】
スケジュール可能性判定部２１３は、送信要求受付部２１１が受け付けたパケット送信の要求について、デッドラインを守って送信することができるか否か判定する。デッドライン保証が可能であれば、通信タスク管理テーブル２１４に、実行すべき通信タスクとして登録する。
【００６４】
図１２を参照して、スケジュール可能性判定部２１３が行う、スケジュール可能性判定処理について説明する。
【００６５】
まず、通信速度取得部２１２がフレーム割当量からデータ送信速度を算出する（Ｓ２０）。スケジュール可能性判定部２１３は、算出されたデータ送信速度を取得する。
【００６６】
ステップＳ２１で、送信要求受付部２１１が受け付けたパケット送信要求と、実行する通信タスクとして通信タスク管理テーブル２１４に格納されているタスクとを合計した場合に必要な、単位時間あたりのデータ転送量を算出する。これは、Σ（各送信の送信データ量／周期）によって求めることができる。
【００６７】
次に、ステップＳ２２で、算出した単位時間あたりのデータ転送量が、ステップＳ２０で算出した単位時間あたりに送信可能な転送量（データ送信速度）以内であるか判定する。ここで、要求されたパケット送信を加えた場合のデータ転送量が最大転送量を超える転送量となる場合は、ステップＳ２６に進み、受け付けたパケット送信要求を登録しないで、その実行を拒否する。一方、算出したデータ転送量が最大転送量以内である場合は、ステップＳ２３に進む。
【００６８】
ステップＳ２３では、要求されたパケット送信の１周期の送信に要する送信所要時間を計算する。送信所要時間は、１周期あたりのデータ転送量を、通信速度取得部２１２から取得した自ノードのデータ送信速度で割ることによって求めることができる。つまり、（送信所要時間）＝（１周期あたりのデータ転送量）／（データ送信速度）、によって求めることができる。
【００６９】
スケジュール可能性判定部２１３は、ステップＳ２４で、デッドラインモノトニック法を利用して、すでに登録された通信タスク及び要求されたパケット送信についてデッドラインを保証できるか判定を行う。
【００７０】
デッドラインモノトニック法では、各パケット送信の周期、１周期あたりの送信所要時間、及びデッドラインを用いる。これらの情報に基づいてスケジュール可能性を判定する判断方法については、既知の如何なる方法を用いてもかまわない。例えば、スケジュール可能性の必要十分条件となる判定式を用いても良いし、十分条件を用いても良い。
【００７１】
スケジュール可能性の十分条件を表す判定式としては、例えば、以下の判定式を用いることができる。
【００７２】
【数１】
【００７３】
なお、Ｔｉ，Ｃｉ，Ｄｉは、それぞれ通信タスクｉの周期、送信所要時間、デッドラインである。また、通信タスクｉは、ｉ＝１の通信タスクが最も優先度が高く、ｉが大きくなるにしたがって優先度が小さくなる。
【００７４】
また、
【数２】
は、ｘ以上の最小整数を表す。
【００７５】
この他の判定式については、例えば、以下の文献などに記載されている。
Audsley, Burns, Richardson, Wellings, "Hard Real-Time Scheduling: The Deadline-Monotonic Approach", Proceedings of the 8th IEEE Workshop on Real-Time Operating Systems and Software, 1991
【００７６】
このような判定式にしたがってスケジュール可能性の判定を行い、すでに登録された通信タスクと要求された通信タスクの全てについてデッドラインを守ることができる場合には、ステップＳ２５に進んで、要求されたパケット送信を、実行する通信タスクとして、通信タスク管理テーブル２１４に格納する。デッドラインを保証できない場合には、ステップＳ２６に進み、受け付けたパケット送信を登録せず、その実行を拒否する。
【００７７】
なお、ステップＳ２２の判定を行わずにステップＳ２４の判定だけでスケジュール可能性を判定できるため、ステップＳ２１，Ｓ２２の処理は省略してもかまない。ただし、Ｄ
Ｍ法による判定は処理負荷が大きいため、ステップＳ２２のような簡単な判定でスケジュール可能性を満たさないことを先に判断するのは有効である。
【００７８】
次に、登録された通信タスクのデータを送信する処理について、図１３，１４を参照して説明する。図１３に示すように、各ノードは、登録された通信タスクのパケットを細かい単位（例えば４８バイト）に分割して、通信タスク毎の送信キューに格納しておく。そして、この細かく分割したデータ（エレメントフレームと呼ぶ）を組み立てて、例えば１５００バイトのフレームを生成してまとめて送信する。ここで、パケットのエレメントフレームへの分割は、ノード２側で行っても良く、周辺デバイス４側で行っても良い。
【００７９】
フレームスケジューラ２２が行う、フレーム組み立ての処理について図１４を参照して説明する。フレームスケジューラ２２は、未送信のデータがある通信タスクの中から、最も高い優先度を持つ通信タスクを選択する（Ｓ３０）。ここで、通信タスクはデッドラインが短いものほど高い優先度が設定される。そして、選択された通信タスクのバッファ（送信キュー）からエレメントフレームを１つ取り出しで、フレームを構築する（Ｓ３１）。フレームが完成したか、すなわち１５００バイトなどの固定長に達したかが判断され（Ｓ３２）、フレームが完成していない場合には、ステップＳ３０に戻る。フレームが完成したら、そのフレームを送信バッファに格納する。フレームスケジューラ２２は、次の送信タイミングで、送信バッファからこのフレームをとりだして送信する（Ｓ３３）。
【００８０】
〈実施形態の効果〉
まず、リング型ネットワークを構築し、送信順序テーブルによって各ノードのフレーム送信タイミングを規定することで、あるノードから送出されたフレームがリング型ネットワーク内の全ノードまで到達する時間（到達遅延）及びノード間の通信速度を保証することができる。
【００８１】
そして、データ送信管理部が、デッドラインモノトニック法によってデッドラインを保証可能な通信タスクのみを受け付ける。これにより、周辺デバイス間で通信を行う場合の通信を、デッドラインを保証することができる。なお、デッドラインモノトニック法で使用するデータ通信速度が上述のように保証されているので、通信タスクのデッドライン保証がより正確なものとなる。
【００８２】
このように、あるノードで受け取られたデータが相手ノードに到達するまでの最悪遅延時間を保証することができるため、送信側と受信側の通信以外での処理に必要を加えることで、処理も含めたエンド・トゥー・エンドの処理時間を算出することが可能となる。
【００８３】
また、送信を要求されたデータを細かい単位に分割してから再度組み立てる構成としているので、優先度は低いがサイズの大きいデータの送信を要求された後に、優先度の高いデータ送信を要求された場合でも、優先度の高いデータがブロックされることがない。
【００８４】
（第２の実施形態）
第２の実施形態は、主に、スケジュール可能性判定部２１３が行う処理が第１の実施形態と異なり、その他については第１の実施形態と同様である。したがって、同様の部分については説明を省略する。
【００８５】
図１５は、本実施形態におけるスケジュール可能性判定部２１３のスケジュール可能性判定処理を示すフローチャートである。図１５の処理のうち、第１の実施形態（図１２）と異なる点は、ステップＳ２７の処理が加わっている点である。
【００８６】
ステップＳ２２でデータ転送量が自ノードに割り当てられた最大転送量を超えると判定
された場合、又は、ステップＳ２４でデッドラインモノトニック法によって要求された通信タスクのデッドラインを保証できないと判定された場合に、すぐに通信タスクの登録を拒否するのではなく、ステップＳ２７に進んで、フレーム割当管理部５に対してフレーム割当量の増加を要求する。
【００８７】
フレーム割当管理部５は、フレーム割当量の増加を求められた場合には、フレームの割当て増加が可能であるか判断する。なお、このように後からフレームの割当量を増加できうるように、当初の送信順序テーブルには空きスロットを設けておき、各ノードからの要求に応じて送信タイミングを割り当てればよい。
【００８８】
あるいは、次のような構成を採用しても良い。すなわち、各ノードは通常時においては割り当てられたスロットの全てを使用しないようにする。例えば、フレーム割当管理部５は、各ノードに１サイクルあたりＮ回の送信機会（スロット）を与えるが、ノード側では１サイクルあたりＮ−ｋ回（例えばｋ＝２）の送信しか行わないこととする。各ノードが使用している１サイクルあたりのスロット数はフレーム割当管理部５に通知されることとし、フレーム割当管理部５で集中管理できるようにしておく。そして、あるノードでデッドラインが守れないと判断した場合は、まず割り当てられた送信機会を全て使用する。それでもデッドラインを守れない場合には、ステップＳ２７においてフレーム割当量の増加を要求する。フレーム割当管理部５は、他のノードに割り当てられているがそのノードが使用していないタイムスロットがある場合には、そのタイムスロットを増加要求したノードに対して割り当てることとしても良い。
【００８９】
フレーム割当量の増加要求が受け入れられた場合には、ステップＳ２０に戻って再びスケジュール可能性の判定を行う。一方、増加要求が受け入れられなかった場合には、要求された通信タスクの登録を拒否する。
【００９０】
このように送信順序テーブルにおける各ノードへのフレーム割当量を動的に変化させることで、第１の実施形態の効果に加えて、動的に変化する通信要求に対しても対応することが可能となる。
【００９１】
（変形例）
上記の実施形態では、ノード２のデータ送信制御部２１に対してデータの送信を要求するのは、ノード２に接続された周辺デバイス３であるとして説明した。しかしながら、データの送信を要求するのは、ノード２に組み込まれたＥＣＵ等のデバイスであってもかまわない。また、ノード２内のアプリケーションプログラムがデータの送信を要求してもかまわない。
【図面の簡単な説明】
【００９２】
【図１】第１の実施形態に係るデータ伝送システムの構成の概要を示す図である。
【図２】第１の実施形態に係るデータ伝送システムに採用可能な物理的なネットワークトポロジーの例を示す図である。
【図３】第１の実施形態に係るデータ伝送システムに採用可能な物理的なネットワークトポロジーの例を示す図である。
【図４】各ノードの機能構成を示す図である。
【図５】第１の実施形態における、フレーム送信制御処理の流れを示すフローチャートである。
【図６】第１の実施形態における送信順序テーブルの例を示す図である。
【図７】第１の実施形態における送信順序テーブルの例を示す図である。
【図８】第１の実施形態における送信順序テーブルの例を示す図である。
【図９】第１の実施形態における送信順序テーブルの例を示す図である。
【図１０】第１の実施形態におけるデータ送信管理部の機能構成を示す図である。
【図１１】第１の実施形態において要求される、周期通信タスクを説明する模式図である。
【図１２】第１の実施形態におけるスケジュール可能性判定処理の流れを示すフローチャートである。
【図１３】第１の実施形態におけるフレーム送信処理を説明する図である。
【図１４】第１の実施形態におけるフレーム送信処理の流れを示すフローチャートである。
【図１５】第２の実施形態におけるスケジュール可能性判定処理の流れを示すフローチャートである。
【符号の説明】
【００９３】
１ データ伝送システム
２ ノード
３ 周辺デバイス
５ フレーム割当管理部
２１ データ送信管理部
２２ フレームスケジューラ
２３ 受信インタフェース（Ｉ／Ｆ）
２４ 送信インタフェース（Ｉ／Ｆ）
【特許請求の範囲】
【請求項１】
論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、
各ノードは、
各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたデータ送信のデッドライン保証が可能か否かを判定し、デッドライン保証可能であれば、該要求されたデータ送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
固定長のフレームを送信する送信制御手段であって、上流ノードから受信したフレームを下流ノードへ転送するとともに、あらかじめ定められたタイミングで自ノードからのフレームを送信する送信制御手段と、
を有し、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、
前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信する
ことを特徴とするデータ伝送システム。
【請求項２】
前記データ送信の実行要求には、送信周期、１周期あたりの送信データ量、及び各周期におけるデッドラインが含まれ、
前記スケジュール可能性判定手段は、１周期あたりの送信データ量及び自ノードの通信速度から、要求されたデータ送信に要する送信所要時間を算出し、前記送信周期、前記送信所要時間、及び前記デッドラインを用いて、デッドラインモノトニック法によって、前記すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドライン保証が可能か否かを判定する
ことを特徴とする請求項１に記載のデータ伝送システム。
【請求項３】
少なくとも１つのノードは、各ノードにおけるフレームの送信順序を管理するフレーム割当管理手段を有し、
前記送信制御手段は、前記フレーム割当管理手段から通知されたタイミングで自ノードからのフレームを送信する
ことを特徴とする請求項１又は２に記載のデータ伝送システム。
【請求項４】
前記スケジュール可能性判定手段は、データ送信の実行要求がデッドライン保証不可能と判定された場合に、前記フレーム割当管理手段に対して、自ノードに対するフレーム割当量の増加を要求する
ことを特徴とする請求項３に記載のデータ伝送システム。
【請求項５】
前記送信制御手段は、前記登録された通信タスクのデータを、フレーム長よりも短い固定長に分割し、前記優先度に応じた順序で分割データを組み立ててフレームを生成して送信する
ことを特徴とする請求項１〜４のいずれかに記載のデータ伝送システム。
【請求項６】
各ノードには１又は複数のデバイスが接続されており、前記送信要求受付手段は、該デバイスからデータ送信の実行要求を受け付ける
ことを特徴とする請求項１〜５のいずれかに記載のデータ伝送システム。
【請求項１】
論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、
各ノードは、
各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたデータ送信のデッドライン保証が可能か否かを判定し、デッドライン保証可能であれば、該要求されたデータ送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
固定長のフレームを送信する送信制御手段であって、上流ノードから受信したフレームを下流ノードへ転送するとともに、あらかじめ定められたタイミングで自ノードからのフレームを送信する送信制御手段と、
を有し、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、
前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信する
ことを特徴とするデータ伝送システム。
【請求項２】
前記データ送信の実行要求には、送信周期、１周期あたりの送信データ量、及び各周期におけるデッドラインが含まれ、
前記スケジュール可能性判定手段は、１周期あたりの送信データ量及び自ノードの通信速度から、要求されたデータ送信に要する送信所要時間を算出し、前記送信周期、前記送信所要時間、及び前記デッドラインを用いて、デッドラインモノトニック法によって、前記すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドライン保証が可能か否かを判定する
ことを特徴とする請求項１に記載のデータ伝送システム。
【請求項３】
少なくとも１つのノードは、各ノードにおけるフレームの送信順序を管理するフレーム割当管理手段を有し、
前記送信制御手段は、前記フレーム割当管理手段から通知されたタイミングで自ノードからのフレームを送信する
ことを特徴とする請求項１又は２に記載のデータ伝送システム。
【請求項４】
前記スケジュール可能性判定手段は、データ送信の実行要求がデッドライン保証不可能と判定された場合に、前記フレーム割当管理手段に対して、自ノードに対するフレーム割当量の増加を要求する
ことを特徴とする請求項３に記載のデータ伝送システム。
【請求項５】
前記送信制御手段は、前記登録された通信タスクのデータを、フレーム長よりも短い固定長に分割し、前記優先度に応じた順序で分割データを組み立ててフレームを生成して送信する
ことを特徴とする請求項１〜４のいずれかに記載のデータ伝送システム。
【請求項６】
各ノードには１又は複数のデバイスが接続されており、前記送信要求受付手段は、該デバイスからデータ送信の実行要求を受け付ける
ことを特徴とする請求項１〜５のいずれかに記載のデータ伝送システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００９−２７８４０８（Ｐ２００９−２７８４０８Ａ）
【公開日】平成２１年１１月２６日（２００９．１１．２６）
【国際特許分類】
【出願番号】特願２００８−１２８１７２（Ｐ２００８−１２８１７２）
【出願日】平成２０年５月１５日（２００８．５．１５）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２１年１１月２６日（２００９．１１．２６）
【国際特許分類】
【出願日】平成２０年５月１５日（２００８．５．１５）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]