JP2009278408A - データ伝送システム - Google Patents
データ伝送システム Download PDFInfo
- Publication number
- JP2009278408A JP2009278408A JP2008128172A JP2008128172A JP2009278408A JP 2009278408 A JP2009278408 A JP 2009278408A JP 2008128172 A JP2008128172 A JP 2008128172A JP 2008128172 A JP2008128172 A JP 2008128172A JP 2009278408 A JP2009278408 A JP 2009278408A
- Authority
- JP
- Japan
- Prior art keywords
- transmission
- node
- deadline
- frame
- data transmission
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Abstract
【課題】データリンク層レベルまで考量して、デッドラインを保証したリアルタイム通信を実現する。
【解決手段】論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、各ノードは、各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、前記要求されたデータ送信のデッドライン保証が可能か否か判定するスケジュール可能性判定手段と、あらかじめ定められたタイミングでフレームを送信する送信制御手段と、を有し、前記スケジュール可能性判定手段は、全ての通信タスクについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信する。
【選択図】図4
【解決手段】論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、各ノードは、各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、前記要求されたデータ送信のデッドライン保証が可能か否か判定するスケジュール可能性判定手段と、あらかじめ定められたタイミングでフレームを送信する送信制御手段と、を有し、前記スケジュール可能性判定手段は、全ての通信タスクについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信する。
【選択図】図4
Description
本発明は、データ伝送システムに関し、特に遅延保証を可能とするデータ伝送システムに関する。
近年、自動車などを構成する各部の機構が電動化され電子制御化される傾向にある。このように、操作情報を電気信号に置き換え、コンピュータで制御することにより機器を操縦するシステムはXbyWireと呼ばれる。例えば、ブレーキやスロットル、ステアリングといった従来は機械的な結合で操作されていた機構が、モータを利用した機構に置き換えられる。このような電気信号(制御データ)の通信では、ミリ秒オーダー以下のリアルタイム性の確保が必要となる。
また、このような車載ネットワークに種々の機器が接続されることが予想される。例えば、車載カメラは画像データを送信するものであるので、大容量のデータが送信される。さらに、車載カメラの安全支援等の用途が増えるに従い搭載数が増えることが予想され、それらの映像を伝送するためにさらなる広帯域が求められる。
今後予想されるこのような状況において、XbyWireに代表される厳しいリアルタイムが要求されるトラフィックと、映像などの比較的リアルタイム性は低いものの広帯域が要求されるトラフィックの混在を可能とし、かつ、各リアルタイム性を満足するデータ伝送システムが必要とされる。
本発明者は、データリンク層よりも上の層においてデータ送信のトラフィック量を管理・調整してリアルタイム性を確保する技術を発明し出願済みである(特許文献1)。
特開2007−74218号公報
特開2004−15152号公報
特開2003−298599号公報
特許文献1はネットワーク層での送出のリアルタイム性を保証する技術である。あるノードから送信されたデータの伝送遅延を、データリンク層レベル以下で保証する技術は知られていない。
そこで、本発明は、リアルタイム通信において、データリンク層レベルまでを考慮してデッドラインを保証した通信を実現することを目的とする。
本発明は、以下の構成によって上記目的を達成する。
本発明は、論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、各ノードは、各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、前記要求されたデータ送信のデッドライン保証が可能か否かを判定し、デッドライン保証可能であれば、該要求されたデータ送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、固定長のフレームを送信し、上流ノードから受信したフレームを下流ノードへ転送するとともに、あらかじめ定められたタイミングで自ノードからのフレームを送信する送信制御手
段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信することを特徴とする。
段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信することを特徴とする。
論理的なリング型ネットワークには、ネットワークが物理的にリング型になっているネットワーク以外のネットワークも含まれる。すなわち、各ノードがデータの受信は上流ノードから行い、データの送信は下流ノードへ行うことで、全体として通信路がリング型となっているネットワークであれば、物理的形態を問わずに含むものである。なお、以下本明細書中では「リング型ネットワーク」の語は、このような論理的な意味で用いる。
本データ伝送システムでは、固定長のフレームを採用するとともに、各ノードのフレーム送信タイミングがあらかじめ定められている。したがって、あるノードにおいてフレームの送信要求があってから、そのフレームがネットワーク内の他のノード(送信先ノード)に送信されるまでの時間の最大値(最悪遅延時間)は、送信タイミングが来るまでの待ち時間と、ネットワーク全体にフレームが送信される転送時間との合計として求められる。これらはいずれも固定された値であるため、本データ伝送システムにおいては、この最悪遅延時間以内でのフレームの送信が保証されることになる。
また、本データ伝送システムでは、各ノードのフレーム送信タイミングがあらかじめ定められているので、各ノードは単位時間あたりに所定量のデータを伝送できることが保証される。
そして、上記のようにデータ転送量が保証された上で、スケジュール可能性判定手段が、データ送信のデッドラインを保証できる場合だけその通信要求を登録する。したがって、ネットワーク内の全てのノードについてデータ送信のデッドラインを保証することが可能となる。
本発明におけるスケジュール可能性判定手段は、デッドラインモノトニック(Deadline
Monotonic)法によって、すでに登録された通信タスク及び要求されたデータ送信の全てについてデッドライン保証が可能であるか判定することが好適である。
Monotonic)法によって、すでに登録された通信タスク及び要求されたデータ送信の全てについてデッドライン保証が可能であるか判定することが好適である。
より具体的には、送信要求受付手段が受け付けるデータ送信要求には、情報として、データ送信の送信周期、1周期あたりの送信データ量及び各周期におけるデッドラインが含まれることが好ましい。ここで、各周期におけるデッドラインは送信周期と同じか送信周期よりも短い時間である。
まず、スケジュール可能性判定手段は、1周期あたりの送信データ量及び自ノードの通信速度から、要求されたデータ送信に要する送信所要時間を算出する。次に、スケジュール可能性判定手段は、送信周期、算出した送信所要時間、及びデッドラインを用いてデッドラインモノトニック法によって、スケジュール可能性を判定する。
なお、スケジュール可能性判定手段は、送信周期、送信所要時間、及びデッドラインが、デッドライン保証可能な必要十分条件を満たすか否かを判定する必要はなく、デッドライン保証可能なための十分条件を満たすか否かのみを判定するようにしても良い。デッドラインモノトニック法では、必要十分条件の判定は複雑であり処理に時間を要するため、処理の軽い十分条件での判定を用いることも好ましい。
本データ伝送システムにおいては、少なくとも1つのノードが、各ノードにおけるフレ
ームの送信順序を管理するフレーム割当管理手段を有することが好適である。フレーム割当管理手段は、各ノードのフレーム送信タイミングをあらかじめ定義した送信順序テーブルを有する。そして、各ノードの送信制御手段は、この送信順序テーブルにしたがってフレームの送信を行うことも好適である。ここで、送信順序テーブルにおいて、1周期(サイクル)における各ノードのフレーム送信回数が同じであれば、各ノードに与えられる通信帯域(単位時間あたりに送信可能なデータ量)が均等になる。一方、必要とする通信帯域が多いノードほど、1周期内における送信回数を多く定めれば、そのようなノードに広い通信帯域を与えることができる。
ームの送信順序を管理するフレーム割当管理手段を有することが好適である。フレーム割当管理手段は、各ノードのフレーム送信タイミングをあらかじめ定義した送信順序テーブルを有する。そして、各ノードの送信制御手段は、この送信順序テーブルにしたがってフレームの送信を行うことも好適である。ここで、送信順序テーブルにおいて、1周期(サイクル)における各ノードのフレーム送信回数が同じであれば、各ノードに与えられる通信帯域(単位時間あたりに送信可能なデータ量)が均等になる。一方、必要とする通信帯域が多いノードほど、1周期内における送信回数を多く定めれば、そのようなノードに広い通信帯域を与えることができる。
また、本発明におけるスケジュール可能性判定手段は、データ送信の実行要求がデッドライン保証不可能であると判定された場合に、前記フレーム割当管理手段に対して、自ノードに対するフレーム割当量の増加を要求することが好適である。
このようにすれば、データ送信の実行要求が動的に変化する場合であっても、フレーム割当量を増加することで、動的に対応することが可能となる。
また、本発明における送信制御手段は、登録された通信タスクのデータをフレーム長よりも短い固定長に分割し、前記優先度に応じた順序で分割データを組み立ててフレームを生成して送信することが好ましい。
このように短いデータに分割することで、サイズは大きいが優先度の低いデータを送信している際に優先度の高いデータ送信が要求された場合に即座に対応することができる。
また、各ノードには1又は複数の周辺デバイスが接続されており、送信要求受付手段は周辺デバイスからデータ送信の実行要求を受け付けても良い。また、送信要求受付手段は、各ノードの内部に格納されたデバイスやアプリケーションプログラムから、データ送信の実行要求を受け付けても良い。
なお、本発明は、上記手段の少なくとも一部を有するデータ伝送システムとして捉えることができる。また、本発明は、上記処理の少なくとも一部を含むデータ伝送方法、または、かかる方法を実現するためのプログラムとして捉えることもできる。上記手段及び処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
また、本発明における各ノードに1又は複数の周辺デバイスが接続され、各ノードがこれら周辺デバイス間での通信を中継する場合には、リング型に接続された各ノードの全体を、1つのネットワーク中継装置として捉えることができる。
データリンク層レベルまで考慮して、デッドラインを保証するリアルタイム通信が可能となる。
(第1の実施形態)
〈システム概要〉
図1に本実施形態に係るデータ伝送システムの概要図を示す。図1Aに示すように、本データ伝送システム1は、複数のノード2をリング状に接続したリング型のネットワークを形成している。また、各ノードには1つ又は複数の周辺デバイス3が接続されている。
〈システム概要〉
図1に本実施形態に係るデータ伝送システムの概要図を示す。図1Aに示すように、本データ伝送システム1は、複数のノード2をリング状に接続したリング型のネットワークを形成している。また、各ノードには1つ又は複数の周辺デバイス3が接続されている。
このようなデータ伝送システム1の具体例として、車両内ネットワークを挙げることができる。その場合、周辺デバイス3には、エンジン、ブレーキ、アクセル、車載カメラ、
レーダー、シート、ドアなどの装置の状態を検知するセンサや、それらの装置を制御する電子制御装置(ECU)が含まれる。そして、複数のノード2は、これらの周辺デバイス3をスター型に接続するハブであると捉えることができる。
レーダー、シート、ドアなどの装置の状態を検知するセンサや、それらの装置を制御する電子制御装置(ECU)が含まれる。そして、複数のノード2は、これらの周辺デバイス3をスター型に接続するハブであると捉えることができる。
各ノード2は、固定長のフレームを隣接するノードに対して送信する。定常状態においては、図1Aに示すように、リング中を複数の固定長のフレームが同時に流れることになる。
1つのノードについて着目すると、図1Bに示すように、隣接ノードからのフレームを受信し、必要があればこのフレームを自ノードで処理するとともにさらに下流の隣接ノードに対して送信(転送)する。したがって、このようなリング型のネットワークでは、通信回線のビジー/アイドルの判定が容易である。また、フレームの衝突を回避できる。
自ノードが送信したフレームは、ネットワーク内の全てのノードによって転送されて自ノードまで戻ってくる。したがって、自ノードが送信したフレームが1周して戻ってきたことを確認することで、ネットワーク内の全てのノードにこのフレームが到達したことを確認できる。1周して戻ってきたフレームは、送信元のノードが破棄することで、ネットワーク内から取り除かれる。
図1Aにはリング型のネットワークトポロジーを示したが、本実施形態では論理的にリング型になっていれば、実際の物理的なトポロジーについてはどのようなものでも採用できる。
基本的には、ノード間の接続に全二重可能な媒体を採用することで、どのような接続形態でもリング型の通信を実現することは可能である。図2,3に採用可能な物理的なトポロジーの例を示した。図に示すように、物理的なトポロジーとして、リング型(図2A)、スター型(図2B)、バス型(図2C)、ディジーチェーン型(図3A,B)を採用可能である。また、1対1の接続(図3C)もリング型に含まれる。
通信リンクを半二重とすることも可能であるが、リング型以外の物理トポロジーでは半二重の場合には通信効率が落ちる。ただし、バス型は同時に1ノードしか通信できないので、リングが全二重であっても通信効率が悪い。また、複数の中継を行う箇所(スター型のハブ、ディジーチェーン型の途中等)がある場合には、その部分が通信速度のボトルネックとなりうる(特にスター型のハブ)。
このように、物理的なトポロジーはどのような形態であっても良いものの、物理的にもリング型となっていることが好適である。したがって、以下では、特に断りの無い限り物理的なトポロジーもリング型であるとして説明する。
〈機能構成及び処理フロー〉
図4は、ノード2の機能構成を示す図である。各ノード2は、データ送信管理部21、フレームスケジューラ22、受信インタフェース23、及び送信インタフェース24を備える。図4では、1つのノードについてのみ各機能部を記載しているが、これらの機能部は全てのノード2が共通して備えている。また、ネットワーク内の1つのノード(図ではノードA)は、さらに、各ノードのフレーム送信順序を管理するフレーム割当管理部5を備える。
図4は、ノード2の機能構成を示す図である。各ノード2は、データ送信管理部21、フレームスケジューラ22、受信インタフェース23、及び送信インタフェース24を備える。図4では、1つのノードについてのみ各機能部を記載しているが、これらの機能部は全てのノード2が共通して備えている。また、ネットワーク内の1つのノード(図ではノードA)は、さらに、各ノードのフレーム送信順序を管理するフレーム割当管理部5を備える。
データ送信管理部21の詳細については後述するが、周辺デバイス3からの通信タスクの要求を受け付け、デッドラインを守って送信可能であるか否かのスケジュール可能性判定を行う。デッドラインを保証できる場合は通信タスクの登録を受け付けるが、デッドラ
インを保証できない場合には登録を拒否する。このようにすることで、データ送信管理部21は、各通信タスクがデッドラインまでに通信相手先までデータが到達することを保証できる。すなわち、ネットワーク層レベルで通信のデッドライン保証を行う。
インを保証できない場合には登録を拒否する。このようにすることで、データ送信管理部21は、各通信タスクがデッドラインまでに通信相手先までデータが到達することを保証できる。すなわち、ネットワーク層レベルで通信のデッドライン保証を行う。
フレームスケジューラ22は、フレーム割当管理部5から指示されたタイミングで自ノードからフレームを送信する。詳細は後述するが、このようにあらかじめ定められた送信順序でフレームスケジューラ22がフレーム送信を行うことで、送出したフレームが所定時間内に通信相手先まで到達することを保証する。すなわち、データリンク層レベルで通信のデッドライン保証を行う。
これらの各機能部は、メモリに格納されたプログラムをCPUが実行することで実現されても良いし、チップや回路などの専用のハードウェアで実現されても良い。また、ソフトウェアとハードウェアの混合によって実現されても良い。
[データリンク層レベル]
まず、フレームスケジューラ22が行うフレーム制御処理、つまり、データリンク層レベルでのリアルタイム性を保証する仕組みを説明する。図5に、各ノードが行うフレーム制御処理のフローチャートを示す。
まず、フレームスケジューラ22が行うフレーム制御処理、つまり、データリンク層レベルでのリアルタイム性を保証する仕組みを説明する。図5に、各ノードが行うフレーム制御処理のフローチャートを示す。
まず、各ノードは、受信インタフェース23を介して、隣接ノード(上流ノード)からフレームを受信する(S10)。受信されたフレームは、フレームスケジューラ22に渡される。受信フレームを自ノードに接続されている周辺デバイスに送信する必要があれば、その処理を行う(S12)。この判定は、フレームに含まれる宛先情報に自ノード配下の周辺デバイスが指定されているかを判断することで行える。
次に、フレームスケジューラ22は、フレーム割当管理部5から通知される送信順序テーブルを参照して、自ノードの送信順序であるか否かを判定する(S14)。図6に送信順序テーブルの例を示す。図6は、リング型ネットワークがノードA〜Dの4つのノードで構成される場合の送信順序テーブルの例であり、1サイクルを4等分して各ノードに1回ずつの送信タイミングを割り当てている。なお、1サイクルあたりに各ノードの送信タイミングは1回のみである必要はなく、図7に示すように各ノードに1サイクルあたり複数回の送信タイミングが割り当てられても良い。
自ノードの送信順である場合(S14−YES)は、送信バッファからデータを取得して送信する(S16)。なお、送信順序テーブルは、1サイクルの時間を1つのフレームがリング型ネットワークを1周する時間の整数倍として定義することが好ましい。このようにすれば、自ノードの送信タイミングにおいては、以前に自ノードが送信したフレームが周回して戻ってくることになる。
一方、自ノードの送信順でない場合(S14−NO)は、受信したフレームは自ノードが送信したものではないので、これを隣接ノード(下流ノード)に対して転送する(S18)。
このように、フレームスケジューラ22がフレーム割当管理部5から通知される送信順序テーブルにしたがってフレームを送信することで、送信したフレームが他のノードまで送信されるのに要する時間(最悪転送遅延時間)を制御することができる。
送信順序テーブルの1サイクルあたりに送信されるフレーム数をNとする。また、1秒間にいくつのサイクルがリング内を回るかを表すサイクル周波数をH(Hz)とする。また、1フレームのフレーム長をL(バイト)とする。
フレーム長は、ネットワーク内で送信されるデータ長にあわせて設計することが好ましい。小さいデータが頻繁に送信される場合にはフレーム長Lを小さく、大きいデータが頻繁に送信される場合にはフレーム長Lを大きくすることが好適である。
例えば、L=128バイトとすることができる。この場合、ネットワーク帯域(データ
転送速度)が1Gbps(bit per second)であれば、1秒あたりに1000000個のフ
レームが各ノードから送信される。そして、NとHの関係は、N×H=1000000を満たす範囲で適宜設定可能である。例えば、N=125個・H=8kHzや、N=4個・H=250kHzなどとすることができる。
転送速度)が1Gbps(bit per second)であれば、1秒あたりに1000000個のフ
レームが各ノードから送信される。そして、NとHの関係は、N×H=1000000を満たす範囲で適宜設定可能である。例えば、N=125個・H=8kHzや、N=4個・H=250kHzなどとすることができる。
さて、あるフレームがネットワーク内を1周する、すなわち、ネットワーク内の全ノードまで展開される時間(1サイクルの所要時間)をTとする。この場合、そのフレームが送信元ノードより実際に送信されてから送信先ノードまで送信されるのに要する時間は、T未満となる。
また、あるノードでフレームの送信要求があってから実際に送信されるまでには、送信タイミングが得られるまでの待ち時間が発生する。この待ち時間Mは、そのノードに割り当てられたフレームの間隔の最大値より小さくなる。フレーム間隔の最大値は、1サイクルに1回の送信タイミングしか与えられていない場合の値であり、上記のTと等しくなる。
したがって、あるノードで送信要求があってから、そのフレームが送信先のノードまでに到達するのに要する最長時間(最悪転送遅延時間)Wは、W<T+M≦2Tとなる。
最悪転送遅延時間として、8μsが要求される場合には、T=4μs以下とする必要がある。すなわち、H=250kHz以上とする必要があることが分かる。このように、必要とするリアルタイム性に合わせて、送信順序テーブルを適宜設計することで、最悪遅延時間を保証することができる。
次に、具体的な送信順序テーブルの例を用いて、各ノードに割り当てる通信帯域(単位時間あたりのデータ転送量)を容易に設定可能であることを説明する。
図8は、ノード数が4であり、1サイクルあたり8個のフレームを送出するとして定義された送信順序テーブルである。ここでは、4つのノードにはそれぞれ均等にフレーム送出機会が与えられており、したがって各ノードに割り当てられる通信帯域は均等になる。例えば、ネットワーク帯域を1Gbpsとすると、各ノードに与えられる帯域は、1Gbps/8×2=256Mbpsとなることが分かる。
各ノードに割り当てる通信帯域を変える場合には、必要とする通信帯域が多いノードに対して1サイクル内におけるフレーム送出機会を多く与えればよい。図9は、このように各ノードに与えるフレーム送出機会に差を設けた場合であり、1サイクルあたり、ノードAは4回、ノードBは2回、ノードC,Dは1回のフレーム送出機会を与えられている。
この場合、ノードAは、1Gbps/8×4=512Mbpsの通信帯域が与えられる。ノードBは、1Gbps/8×2=256Mbpsの通信帯域が与えられる。ノードC,Dには、1Gbps/8=128Mbpsの通信帯域が与えられる。
このように、送信順序テーブルを用いて各ノードに送信機会を割り当てることで、各ノードの通信帯域を容易に設定することができる。また、各ノードは、送信順序テーブルを
参照することで、自ノードに割り当てられている通信帯域を知ることができる。
参照することで、自ノードに割り当てられている通信帯域を知ることができる。
[ネットワーク層レベル]
次に、データ送信管理部21が行う通信タスクの登録可否判定処理について説明する。つまり、ネットワーク層レベルでのリアルタイム性を保証する仕組みについて説明する。
次に、データ送信管理部21が行う通信タスクの登録可否判定処理について説明する。つまり、ネットワーク層レベルでのリアルタイム性を保証する仕組みについて説明する。
図10に、データ送信管理部21の詳細な機能ブロック図を示す。データ送信管理部21は、送信要求受付部211、通信速度取得部212、スケジュール可能性判定部213、及び通信タスク管理テーブル214を備える。
送信要求受付部211は、周辺デバイス4からデータ(パケット)送信の要求を受け付ける。送信要求受付部211が受け付けるパケット送信の要求は、一定周期ごとに所定のデータ量を送信する必要があり、送信開始から所定の時間(デッドライン)以内にデータの送信を完了する必要がある。
図11は、周期的なパケット送信の通信タスクを説明する図である。図11Aに示すように、一定周期Tごとに所定量のパケットを送信する必要がある。また、この送信を完了する制限時間であるデッドラインDが定められている。なお、パケットの送信はデッドライン以内に完了すれば、正しく処理されたものとみなされる。したがって、図11Bに示すように、複数の通信タスクが存在する状況では、各通信タスクのデータを連続して送信する必要はなく、他の通信タスクによる割り込みが発生しても構わない。
通信速度取得部212は、ノード2のが単位時間あたりに送信可能なデータ転送量(以下、データ送信速度ともいう)をフレーム割当管理部5から通知される送信順序テーブルから取得する。上述したように、ネットワーク帯域と自ノードに割り当てられるフレーム送信機会とから自ノードのデータ送信速度を求めることができる。
スケジュール可能性判定部213は、送信要求受付部211が受け付けたパケット送信の要求について、デッドラインを守って送信することができるか否か判定する。デッドライン保証が可能であれば、通信タスク管理テーブル214に、実行すべき通信タスクとして登録する。
図12を参照して、スケジュール可能性判定部213が行う、スケジュール可能性判定処理について説明する。
まず、通信速度取得部212がフレーム割当量からデータ送信速度を算出する(S20)。スケジュール可能性判定部213は、算出されたデータ送信速度を取得する。
ステップS21で、送信要求受付部211が受け付けたパケット送信要求と、実行する通信タスクとして通信タスク管理テーブル214に格納されているタスクとを合計した場合に必要な、単位時間あたりのデータ転送量を算出する。これは、Σ(各送信の送信データ量/周期)によって求めることができる。
次に、ステップS22で、算出した単位時間あたりのデータ転送量が、ステップS20で算出した単位時間あたりに送信可能な転送量(データ送信速度)以内であるか判定する。ここで、要求されたパケット送信を加えた場合のデータ転送量が最大転送量を超える転送量となる場合は、ステップS26に進み、受け付けたパケット送信要求を登録しないで、その実行を拒否する。一方、算出したデータ転送量が最大転送量以内である場合は、ステップS23に進む。
ステップS23では、要求されたパケット送信の1周期の送信に要する送信所要時間を計算する。送信所要時間は、1周期あたりのデータ転送量を、通信速度取得部212から取得した自ノードのデータ送信速度で割ることによって求めることができる。つまり、(送信所要時間)=(1周期あたりのデータ転送量)/(データ送信速度)、によって求めることができる。
スケジュール可能性判定部213は、ステップS24で、デッドラインモノトニック法を利用して、すでに登録された通信タスク及び要求されたパケット送信についてデッドラインを保証できるか判定を行う。
デッドラインモノトニック法では、各パケット送信の周期、1周期あたりの送信所要時間、及びデッドラインを用いる。これらの情報に基づいてスケジュール可能性を判定する判断方法については、既知の如何なる方法を用いてもかまわない。例えば、スケジュール可能性の必要十分条件となる判定式を用いても良いし、十分条件を用いても良い。
スケジュール可能性の十分条件を表す判定式としては、例えば、以下の判定式を用いることができる。
なお、Ti,Ci,Diは、それぞれ通信タスクiの周期、送信所要時間、デッドラインである。また、通信タスクiは、i=1の通信タスクが最も優先度が高く、iが大きくなるにしたがって優先度が小さくなる。
この他の判定式については、例えば、以下の文献などに記載されている。
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
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
このような判定式にしたがってスケジュール可能性の判定を行い、すでに登録された通信タスクと要求された通信タスクの全てについてデッドラインを守ることができる場合には、ステップS25に進んで、要求されたパケット送信を、実行する通信タスクとして、通信タスク管理テーブル214に格納する。デッドラインを保証できない場合には、ステップS26に進み、受け付けたパケット送信を登録せず、その実行を拒否する。
なお、ステップS22の判定を行わずにステップS24の判定だけでスケジュール可能性を判定できるため、ステップS21,S22の処理は省略してもかまない。ただし、D
M法による判定は処理負荷が大きいため、ステップS22のような簡単な判定でスケジュール可能性を満たさないことを先に判断するのは有効である。
M法による判定は処理負荷が大きいため、ステップS22のような簡単な判定でスケジュール可能性を満たさないことを先に判断するのは有効である。
次に、登録された通信タスクのデータを送信する処理について、図13,14を参照して説明する。図13に示すように、各ノードは、登録された通信タスクのパケットを細かい単位(例えば48バイト)に分割して、通信タスク毎の送信キューに格納しておく。そして、この細かく分割したデータ(エレメントフレームと呼ぶ)を組み立てて、例えば1500バイトのフレームを生成してまとめて送信する。ここで、パケットのエレメントフレームへの分割は、ノード2側で行っても良く、周辺デバイス4側で行っても良い。
フレームスケジューラ22が行う、フレーム組み立ての処理について図14を参照して説明する。フレームスケジューラ22は、未送信のデータがある通信タスクの中から、最も高い優先度を持つ通信タスクを選択する(S30)。ここで、通信タスクはデッドラインが短いものほど高い優先度が設定される。そして、選択された通信タスクのバッファ(送信キュー)からエレメントフレームを1つ取り出しで、フレームを構築する(S31)。フレームが完成したか、すなわち1500バイトなどの固定長に達したかが判断され(S32)、フレームが完成していない場合には、ステップS30に戻る。フレームが完成したら、そのフレームを送信バッファに格納する。フレームスケジューラ22は、次の送信タイミングで、送信バッファからこのフレームをとりだして送信する(S33)。
〈実施形態の効果〉
まず、リング型ネットワークを構築し、送信順序テーブルによって各ノードのフレーム送信タイミングを規定することで、あるノードから送出されたフレームがリング型ネットワーク内の全ノードまで到達する時間(到達遅延)及びノード間の通信速度を保証することができる。
まず、リング型ネットワークを構築し、送信順序テーブルによって各ノードのフレーム送信タイミングを規定することで、あるノードから送出されたフレームがリング型ネットワーク内の全ノードまで到達する時間(到達遅延)及びノード間の通信速度を保証することができる。
そして、データ送信管理部が、デッドラインモノトニック法によってデッドラインを保証可能な通信タスクのみを受け付ける。これにより、周辺デバイス間で通信を行う場合の通信を、デッドラインを保証することができる。なお、デッドラインモノトニック法で使用するデータ通信速度が上述のように保証されているので、通信タスクのデッドライン保証がより正確なものとなる。
このように、あるノードで受け取られたデータが相手ノードに到達するまでの最悪遅延時間を保証することができるため、送信側と受信側の通信以外での処理に必要を加えることで、処理も含めたエンド・トゥー・エンドの処理時間を算出することが可能となる。
また、送信を要求されたデータを細かい単位に分割してから再度組み立てる構成としているので、優先度は低いがサイズの大きいデータの送信を要求された後に、優先度の高いデータ送信を要求された場合でも、優先度の高いデータがブロックされることがない。
(第2の実施形態)
第2の実施形態は、主に、スケジュール可能性判定部213が行う処理が第1の実施形態と異なり、その他については第1の実施形態と同様である。したがって、同様の部分については説明を省略する。
第2の実施形態は、主に、スケジュール可能性判定部213が行う処理が第1の実施形態と異なり、その他については第1の実施形態と同様である。したがって、同様の部分については説明を省略する。
図15は、本実施形態におけるスケジュール可能性判定部213のスケジュール可能性判定処理を示すフローチャートである。図15の処理のうち、第1の実施形態(図12)と異なる点は、ステップS27の処理が加わっている点である。
ステップS22でデータ転送量が自ノードに割り当てられた最大転送量を超えると判定
された場合、又は、ステップS24でデッドラインモノトニック法によって要求された通信タスクのデッドラインを保証できないと判定された場合に、すぐに通信タスクの登録を拒否するのではなく、ステップS27に進んで、フレーム割当管理部5に対してフレーム割当量の増加を要求する。
された場合、又は、ステップS24でデッドラインモノトニック法によって要求された通信タスクのデッドラインを保証できないと判定された場合に、すぐに通信タスクの登録を拒否するのではなく、ステップS27に進んで、フレーム割当管理部5に対してフレーム割当量の増加を要求する。
フレーム割当管理部5は、フレーム割当量の増加を求められた場合には、フレームの割当て増加が可能であるか判断する。なお、このように後からフレームの割当量を増加できうるように、当初の送信順序テーブルには空きスロットを設けておき、各ノードからの要求に応じて送信タイミングを割り当てればよい。
あるいは、次のような構成を採用しても良い。すなわち、各ノードは通常時においては割り当てられたスロットの全てを使用しないようにする。例えば、フレーム割当管理部5は、各ノードに1サイクルあたりN回の送信機会(スロット)を与えるが、ノード側では1サイクルあたりN−k回(例えばk=2)の送信しか行わないこととする。各ノードが使用している1サイクルあたりのスロット数はフレーム割当管理部5に通知されることとし、フレーム割当管理部5で集中管理できるようにしておく。そして、あるノードでデッドラインが守れないと判断した場合は、まず割り当てられた送信機会を全て使用する。それでもデッドラインを守れない場合には、ステップS27においてフレーム割当量の増加を要求する。フレーム割当管理部5は、他のノードに割り当てられているがそのノードが使用していないタイムスロットがある場合には、そのタイムスロットを増加要求したノードに対して割り当てることとしても良い。
フレーム割当量の増加要求が受け入れられた場合には、ステップS20に戻って再びスケジュール可能性の判定を行う。一方、増加要求が受け入れられなかった場合には、要求された通信タスクの登録を拒否する。
このように送信順序テーブルにおける各ノードへのフレーム割当量を動的に変化させることで、第1の実施形態の効果に加えて、動的に変化する通信要求に対しても対応することが可能となる。
(変形例)
上記の実施形態では、ノード2のデータ送信制御部21に対してデータの送信を要求するのは、ノード2に接続された周辺デバイス3であるとして説明した。しかしながら、データの送信を要求するのは、ノード2に組み込まれたECU等のデバイスであってもかまわない。また、ノード2内のアプリケーションプログラムがデータの送信を要求してもかまわない。
上記の実施形態では、ノード2のデータ送信制御部21に対してデータの送信を要求するのは、ノード2に接続された周辺デバイス3であるとして説明した。しかしながら、データの送信を要求するのは、ノード2に組み込まれたECU等のデバイスであってもかまわない。また、ノード2内のアプリケーションプログラムがデータの送信を要求してもかまわない。
1 データ伝送システム
2 ノード
3 周辺デバイス
5 フレーム割当管理部
21 データ送信管理部
22 フレームスケジューラ
23 受信インタフェース(I/F)
24 送信インタフェース(I/F)
2 ノード
3 周辺デバイス
5 フレーム割当管理部
21 データ送信管理部
22 フレームスケジューラ
23 受信インタフェース(I/F)
24 送信インタフェース(I/F)
Claims (6)
- 論理的なリング型ネットワークに接続された複数のノードから構成されるデータ伝送システムであって、
各ノードは、
各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたデータ送信のデッドライン保証が可能か否かを判定し、デッドライン保証可能であれば、該要求されたデータ送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
固定長のフレームを送信する送信制御手段であって、上流ノードから受信したフレームを下流ノードへ転送するとともに、あらかじめ定められたタイミングで自ノードからのフレームを送信する送信制御手段と、
を有し、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、
前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信する
ことを特徴とするデータ伝送システム。 - 前記データ送信の実行要求には、送信周期、1周期あたりの送信データ量、及び各周期におけるデッドラインが含まれ、
前記スケジュール可能性判定手段は、1周期あたりの送信データ量及び自ノードの通信速度から、要求されたデータ送信に要する送信所要時間を算出し、前記送信周期、前記送信所要時間、及び前記デッドラインを用いて、デッドラインモノトニック法によって、前記すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドライン保証が可能か否かを判定する
ことを特徴とする請求項1に記載のデータ伝送システム。 - 少なくとも1つのノードは、各ノードにおけるフレームの送信順序を管理するフレーム割当管理手段を有し、
前記送信制御手段は、前記フレーム割当管理手段から通知されたタイミングで自ノードからのフレームを送信する
ことを特徴とする請求項1又は2に記載のデータ伝送システム。 - 前記スケジュール可能性判定手段は、データ送信の実行要求がデッドライン保証不可能と判定された場合に、前記フレーム割当管理手段に対して、自ノードに対するフレーム割当量の増加を要求する
ことを特徴とする請求項3に記載のデータ伝送システム。 - 前記送信制御手段は、前記登録された通信タスクのデータを、フレーム長よりも短い固定長に分割し、前記優先度に応じた順序で分割データを組み立ててフレームを生成して送信する
ことを特徴とする請求項1〜4のいずれかに記載のデータ伝送システム。 - 各ノードには1又は複数のデバイスが接続されており、前記送信要求受付手段は、該デバイスからデータ送信の実行要求を受け付ける
ことを特徴とする請求項1〜5のいずれかに記載のデータ伝送システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008128172A JP2009278408A (ja) | 2008-05-15 | 2008-05-15 | データ伝送システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008128172A JP2009278408A (ja) | 2008-05-15 | 2008-05-15 | データ伝送システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009278408A true JP2009278408A (ja) | 2009-11-26 |
Family
ID=41443412
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008128172A Withdrawn JP2009278408A (ja) | 2008-05-15 | 2008-05-15 | データ伝送システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2009278408A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013069052A1 (ja) * | 2011-11-08 | 2013-05-16 | 三菱電機株式会社 | デジタル放送受信機 |
WO2021181873A1 (ja) * | 2020-03-12 | 2021-09-16 | オムロン株式会社 | 情報処理装置、マスタ装置、情報処理システム、通知方法および情報処理プログラム |
-
2008
- 2008-05-15 JP JP2008128172A patent/JP2009278408A/ja not_active Withdrawn
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013069052A1 (ja) * | 2011-11-08 | 2013-05-16 | 三菱電機株式会社 | デジタル放送受信機 |
WO2021181873A1 (ja) * | 2020-03-12 | 2021-09-16 | オムロン株式会社 | 情報処理装置、マスタ装置、情報処理システム、通知方法および情報処理プログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7889683B2 (en) | Non-destructive media access resolution for asynchronous traffic in a half-duplex braided-ring | |
JP4995101B2 (ja) | 共有リソースへのアクセスを制御する方法及びシステム | |
TWI336576B (en) | A scheduler system and method thereof | |
US7987302B2 (en) | Techniques for managing priority queues and escalation considerations in USB wireless communication systems | |
US20070127521A1 (en) | Interface between network data bus application and avionics data bus | |
EP1788735B1 (en) | Equipment and method for bandwidth allocation | |
US20090254659A1 (en) | Delayed Downloading Video Service Using Peer-to-Peer (P2P) Content Distribution Network | |
JP4856790B2 (ja) | 中継器 | |
EP2453613A1 (en) | Method and apparatus for allocating and prioritizing data transmission | |
JPWO2008041271A1 (ja) | 送受信システム、ノード及び通信方法 | |
US20160164784A1 (en) | Data transmission method and apparatus | |
CN104717149A (zh) | 一种基于虚拟链路的数据帧调度方法 | |
EP2997762B1 (en) | Method and system for providing deterministic quality of service for communication devices | |
KR101135117B1 (ko) | 이종 프로토콜 통신에서 프로세스의 우선 순위를 조절하여 지연을 보상하는 방법 및 장치 | |
JP4335219B2 (ja) | 無線lanトラヒック優先制御方法及びその装置 | |
US20110047271A1 (en) | Method and system for allocating resources | |
JP2009278408A (ja) | データ伝送システム | |
CN109450817B (zh) | 时间触发以太网多业务消息发送的混合调度方法 | |
JP2009277052A (ja) | 分散デバイス制御システム | |
JP5307745B2 (ja) | トラヒック制御システムと方法およびプログラムならびに通信中継装置 | |
CN113438153B (zh) | 一种车载网关、智能汽车及控制方法 | |
JP6455220B2 (ja) | 通信システム | |
JP2007074218A (ja) | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 | |
JP7044081B2 (ja) | 車載用通信システム | |
KR100950528B1 (ko) | 복수 개의 데이터를 계층별로 처리하는 장치 및 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Withdrawal of application because of no request for examination |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20110802 |