JP2009277052A - 分散デバイス制御システム - Google Patents
分散デバイス制御システム Download PDFInfo
- Publication number
- JP2009277052A JP2009277052A JP2008128225A JP2008128225A JP2009277052A JP 2009277052 A JP2009277052 A JP 2009277052A JP 2008128225 A JP2008128225 A JP 2008128225A JP 2008128225 A JP2008128225 A JP 2008128225A JP 2009277052 A JP2009277052 A JP 2009277052A
- Authority
- JP
- Japan
- Prior art keywords
- data
- node
- transmission
- frame
- communication
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Multi Processors (AREA)
Abstract
【課題】デバイスの制御をネットワーク経由で他のコンピュータから行う際に、リアルタイム性を保証する。
【解決手段】データ伝送システムと、これに接続されたコンピュータおよびデバイスとから構成され、前記コンピュータから前記データ伝送システムを介して前記デバイスを制御する分散デバイス制御システムであって、前記データ伝送システムは、複数のノードが論理的にリング型の接続をしたものであり、前記ノードの各々が、あらかじめ定められたタイミングで固定長のフレームを送信することでデータ通信速度を保証すると共に、デッドライン保証可能な通信タスクのみを登録することで通信タスクの最大遅延を保証する通信手段と、デバイスデータの形式を変換するデバイスデータ変換手段と、を備える。
【選択図】図4
【解決手段】データ伝送システムと、これに接続されたコンピュータおよびデバイスとから構成され、前記コンピュータから前記データ伝送システムを介して前記デバイスを制御する分散デバイス制御システムであって、前記データ伝送システムは、複数のノードが論理的にリング型の接続をしたものであり、前記ノードの各々が、あらかじめ定められたタイミングで固定長のフレームを送信することでデータ通信速度を保証すると共に、デッドライン保証可能な通信タスクのみを登録することで通信タスクの最大遅延を保証する通信手段と、デバイスデータの形式を変換するデバイスデータ変換手段と、を備える。
【選択図】図4
Description
本発明は、ネットワークを介してデバイスを制御する分散デバイス制御システムに関する。
近年、自動車などを構成する各部の機構が電動化され電子制御化される傾向にある。このように、操作情報を電気信号に置き換え、コンピュータで制御することにより機器(デバイス)を操縦するシステムはXbyWireと呼ばれる。例えば、ブレーキやスロットル、ステアリングといった従来は機械的な結合で操作されていた機構が、モータを利用した機構に置き換えられる。
このようなデバイスの制御にはミリ秒オーダー以下でのリアルタイム性を要求されるため、デバイスに内蔵されたECUか、またはデバイスが接続されているノードで動作するデバイスドライバによって制御されることが一般的である。
デバイスにECUを内蔵した場合は、デバイス自体が高価になってしまう。また、デバイスが接続されているノードにデバイスドライバを実行させると、そのノードが過負荷になってしまう事態が想定される。
従来、ネットワークを介して接続された他のコンピュータに接続されたデバイスを、あたかも自ノードに直接接続されているかのように取り扱う仮想デバイスドライバの仕組みが提案されている(特許文献1−3)。しかしながら、これらの提案では通信のリアルタイム要求を考慮していないため、上記のような厳しいリアルタイム性を要求される車載システム等には適用できない。
なお、本発明者は、データ送信のトラフィック量を管理・調整してリアルタイム性を確保する技術を発明し出願済みである(特許文献4)。
特開2002−24154号公報
特開2005−293417号公報
特開2006−172142号公報
特開2007−74218号公報
本発明は、デバイスの制御をネットワーク経由で他のコンピュータから行う際に、リアルタイム性を保証することを目的とする。
本発明は、以下の構成によって上記目的を達成する。
本発明は、データ伝送システムと、これに接続されたコンピュータおよびデバイスとから構成され、前記コンピュータから前記データ伝送システムを介して前記デバイスを制御する分散デバイス制御システムである。ここで、前記データ伝送システムは、複数のノードが論理的にリング型の接続をしたものであり、前記ノードの各々が、あらかじめ定められたタイミングで固定長のフレームを送信することでデータ通信速度を保証すると共に、デッドライン保証可能な通信タスクのみを登録することで通信タスクの最大遅延を保証する通信手段と、当該ノードに接続されたコンピュータまたはデバイスからデバイス制御に
関するデータを得たときに、該データを前記通信手段が通信可能なデータ形式に変換してから前記通信手段に送出するとともに、前記通信手段から当該ノードに接続されたコンピュータまたはデバイスについてのデバイス制御に関するデータを得たときに、当該ノードに接続されたコンピュータまたはデバイスが受理可能なデータ形式に変換してから該コンピュータまたはデバイスに出力する、デバイスデータ変換手段と、を備える。
関するデータを得たときに、該データを前記通信手段が通信可能なデータ形式に変換してから前記通信手段に送出するとともに、前記通信手段から当該ノードに接続されたコンピュータまたはデバイスについてのデバイス制御に関するデータを得たときに、当該ノードに接続されたコンピュータまたはデバイスが受理可能なデータ形式に変換してから該コンピュータまたはデバイスに出力する、デバイスデータ変換手段と、を備える。
このように、リング型ネットワークを採用し、各ノードが固定長のフレームを送信すると共に、その送信タイミングがあらかじめ定められている。これにより、あるノードにおいてフレームの送信要求があってから、そのフレームがネットワーク内の他のノード(送信先ノード)に送信されるまでの時間の最大値(最悪遅延時間)に上限を設けることができる。この最悪遅延時間は、送信タイミングが来るまでの待ち時間と、ネットワーク全体にフレームが送信される転送時間との合計として求められる。これらはいずれも固定された値であるため、本データ伝送システムにおいては、この最悪遅延時間以内でのフレームの送信が保証されることになる。
なお、論理的なリング型ネットワークには、ネットワークが物理的にリング型になっているネットワーク以外のネットワークも含まれる。すなわち、各ノードがデータの受信は上流ノードから行い、データの送信は下流ノードへ行うことで、全体として通信路がリング型となっているネットワークであれば、物理的形態を問わずに含むものである。なお、以下本明細書中では「リング型ネットワーク」の語は、このような論理的な意味で用いる。
そして、上記のようにデータ転送量が保証された上で、通信手段は、デッドラインを保証できる場合だけその通信タスクを登録する。したがって、ネットワーク内の全てのノードについてデータ送信のデッドラインを保証することが可能となる。
このように、通信タスクの最大遅延を保証可能なデータ伝送システムを介して、コンピュータがリモートのデバイスを制御するため、リアルタイム性の確保が可能となる。
なお、前記コンピュータは前記デバイスを制御するためのデータを前記デバイスデータ変換手段に所定の周期で送信することが好適である。この周期的な要求(制御データの通信)の通信タスクを通信手段に登録することで、この通信タスクに必要なネットワークリソースを確保することができる。
また、前記通信手段は、固定長のフレームを送信する送信制御手段であって、上流ノードから受信したフレームを下流ノードへ転送するとともに、あらかじめ定められたタイミングで自ノードからのフレームを送信する送信制御手段と、各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、前記要求されたデータ送信のデッドライン保証が可能か否かを判定し、デッドライン保証可能であれば、該要求されたデータ送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信することが好適である。
本発明におけるスケジュール可能性判定手段は、デッドラインモノトニック(Deadline
Monotonic)法によって、すでに登録された通信タスク及び要求されたデータ送信の全てについてデッドライン保証が可能であるか判定することが好適である。
Monotonic)法によって、すでに登録された通信タスク及び要求されたデータ送信の全てについてデッドライン保証が可能であるか判定することが好適である。
より具体的には、送信要求受付手段が受け付けるデータ送信要求には、情報として、データ送信の送信周期、1周期あたりの送信データ量及び各周期におけるデッドラインが含まれることが好ましい。ここで、各周期におけるデッドラインは送信周期と同じか送信周期よりも短い時間である。
まず、スケジュール可能性判定手段は、1周期あたりの送信データ量及び自ノードの通信速度から、要求されたデータ送信に要する送信所要時間を算出する。次に、スケジュール可能性判定手段は、送信周期、算出した送信所要時間、及びデッドラインを用いてデッドラインモノトニック法によって、スケジュール可能性を判定する。
なお、スケジュール可能性判定手段は、送信周期、送信所要時間、及びデッドラインが、デッドライン保証可能な必要十分条件を満たすか否かを判定する必要はなく、デッドライン保証可能なための十分条件を満たすか否かのみを判定するようにしても良い。デッドラインモノトニック法では、必要十分条件の判定は複雑であり処理に時間を要するため、処理の軽い十分条件での判定を用いることも好ましい。
本発明におけるデータ伝送システムにおいては、前記複数のノードのうちの少なくとも1つのノードは、各ノードにおけるフレームの送信順序を管理するフレーム割当管理手段を有することが好適である。フレーム割当管理手段は、各ノードのフレーム送信タイミングをあらかじめ定義した送信順序テーブルを有する。そして、各ノードの送信制御手段は、この送信順序テーブルにしたがってフレームの送信を行うことも好適である。ここで、送信順序テーブルにおいて、1周期(サイクル)における各ノードのフレーム送信回数が同じであれば、各ノードに与えられる通信帯域(単位時間あたりに送信可能なデータ量)が均等になる。一方、必要とする通信帯域が多いノードほど、1周期内における送信回数を多く定めれば、そのようなノードに広い通信帯域を与えることができる。
また、本発明におけるスケジュール可能性判定手段は、データ送信の実行要求がデッドライン保証不可能であると判定された場合に、前記フレーム割当管理手段に対して、自ノードに対するフレーム割当量の増加を要求することが好適である。
このようにすれば、データ送信の実行要求が動的に変化する場合であっても、フレーム割当量を増加することで、動的に対応することが可能となる。
また、本発明における送信制御手段は、登録された通信タスクのデータをフレーム長よりも短い固定長に分割し、前記優先度に応じた順序で分割データを組み立ててフレームを生成して送信することが好ましい。
このように短いデータに分割することで、サイズは大きいが優先度の低いデータを送信している際に優先度の高いデータ送信が要求された場合に即座に対応することができる。
なお、本発明は、上記手段の少なくとも一部を有するデータ伝送システムとして捉えることができる。また、本発明は、上記処理の少なくとも一部を含むデータ伝送方法、または、かかる方法を実現するためのプログラムとして捉えることもできる。上記手段及び処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
デバイスの制御をネットワーク経由で他のコンピュータから行う際に、リアルタイム性を保証することが可能となる。
(第1の実施形態)
〈システム概要〉
図1に本実施形態に係る分散デバイス制御システムの概要図を示す。図1Aに示すように、本分散デバイス制御システムは、データ伝送システム1,ECU3,デバイス4等から構成される。データ伝送システム1は、複数のノード2をリング状に接続したリング型のネットワークを形成している。そして、ECU3やデバイス4はノード2に接続されている。なお、以下の明細書中では、個別のノードを区別して説明する場合には、ノード2a,2b等のような符号を付して説明するが、個々のノードを区別する必要がない場合にはノード2と称する。ECUやデバイスについても同様である。
〈システム概要〉
図1に本実施形態に係る分散デバイス制御システムの概要図を示す。図1Aに示すように、本分散デバイス制御システムは、データ伝送システム1,ECU3,デバイス4等から構成される。データ伝送システム1は、複数のノード2をリング状に接続したリング型のネットワークを形成している。そして、ECU3やデバイス4はノード2に接続されている。なお、以下の明細書中では、個別のノードを区別して説明する場合には、ノード2a,2b等のような符号を付して説明するが、個々のノードを区別する必要がない場合にはノード2と称する。ECUやデバイスについても同様である。
このようなデータ伝送システム1の具体例として、車両内ネットワークを挙げることができる。その場合、デバイス4には、エンジン、ブレーキ、アクセル、車載カメラ、レーダー、シートなどの機器が含まれる。ECU(電子制御装置)3は、デバイス4の制御を行う。
本システムにおいて、デバイス4は、制御信号の入力を受け取ってそれにしたがって動作したり、自身の状態を表す信号を出力したりする。機器の種類によっては、いずれか一方のみを行う場合もある。そして、ECU3は、デバイス4に制御信号を出力して制御したり、デバイス4からの信号を受信したりする。ここで、本分散デバイス制御システムにおけるデバイス4の制御は、デバイス4と直接接続されたECU以外からも可能としている。例えば、図1Aを参照すると、ECU3aが、データ伝送システム1を経由して、デバイス4bやデバイス4cを制御することができる。
なお、データ伝送システム1には、デバイス4の制御に関する通信以外の通信もやりとりされる。例えば、ECU間の通信などが行われる。
1つのノードについて着目すると、図1Bに示すように、隣接ノードからのフレームを受信し、必要があればこのフレームを自ノードで処理するとともにさらに下流の隣接ノードに対して送信(転送)する。したがって、このようなリング型のネットワークでは、通信回線のビジー/アイドルの判定が容易である。また、フレームの衝突を回避できる。
自ノードが送信したフレームは、ネットワーク内の全てのノードによって転送されて自ノードまで戻ってくる。したがって、自ノードが送信したフレームが1周して戻ってきたことを確認することで、ネットワーク内の全てのノードにこのフレームが到達したことを確認できる。1周して戻ってきたフレームは、送信元のノードが破棄することで、ネットワーク内から取り除かれる。
各ノード2は、固定長のフレームを隣接するノードに対して送信する。定常状態においては、図1Aに示すように、リング中を複数の固定長のフレームが同時に流れることになる。
図1Aにはリング型のネットワークトポロジーを示したが、本実施形態では論理的にリング型になっていれば、実際の物理的なトポロジーについてはどのようなものでも採用できる。
基本的には、ノード間の接続に全二重可能な媒体を採用することで、どのような接続形態でもリング型の通信を実現することは可能である。図2,3に採用可能な物理的なトポロジーの例を示した。図に示すように、物理的なトポロジーとして、リング型(図2A)、スター型(図2B)、バス型(図2C)、ディジーチェーン型(図3A,B)を採用可能である。また、1対1の接続(図3C)もリング型に含まれる。
通信リンクを半二重とすることも可能であるが、リング型以外の物理トポロジーでは半二重の場合には通信効率が落ちる。ただし、バス型は同時に1ノードしか通信できないので、リングが全二重であっても通信効率が悪い。また、複数の中継を行う箇所(スター型のハブ、ディジーチェーン型の途中等)がある場合には、その部分が通信速度のボトルネックとなりうる(特にスター型のハブ)。
このように、物理的なトポロジーはどのような形態であっても良いものの、物理的にもリング型となっていることが好適である。したがって、以下では、特に断りの無い限り物理的なトポロジーもリング型であるとして説明する。
〈機能構成及び処理フロー〉
図4は、ノード2の機能構成を示す図である。各ノード2は、データ送信管理部21、フレームスケジューラ22、デバイスデータ変換部25、受信インタフェース23、及び送信インタフェース24を備える。図4では、2つノード2a,cについてのみ各機能部を記載しているが、これらの機能部は全てのノード2が共通して備えている。また、ネットワーク内の1つのノード(図ではノード2b)は、さらに、各ノードのフレーム送信順序を管理するフレーム割当管理部5を備える。
図4は、ノード2の機能構成を示す図である。各ノード2は、データ送信管理部21、フレームスケジューラ22、デバイスデータ変換部25、受信インタフェース23、及び送信インタフェース24を備える。図4では、2つノード2a,cについてのみ各機能部を記載しているが、これらの機能部は全てのノード2が共通して備えている。また、ネットワーク内の1つのノード(図ではノード2b)は、さらに、各ノードのフレーム送信順序を管理するフレーム割当管理部5を備える。
データ送信管理部21の詳細については後述するが、ECU3やデバイスデータ変換部25からの通信タスクの要求を受け付け、デッドラインを守って送信可能であるか否かのスケジュール可能性判定を行う。デッドラインを保証できる場合は通信タスクの登録を受け付けるが、デッドラインを保証できない場合には登録を拒否する。このようにすることで、データ送信管理部21は、各通信タスクがデッドラインまでに通信相手先までデータが到達することを保証できる。すなわち、ネットワーク層レベルで通信のデッドライン保証を行う。
フレームスケジューラ22は、フレーム割当管理部5から指示されたタイミングで自ノードからフレームを送信する。このようにあらかじめ定められた送信順序でフレームスケジューラ22がフレーム送信を行うことで、送出したフレームが所定時間内に通信相手先まで到達することを保証する。すなわち、データリンク層レベルで通信のデッドライン保証を行う。
デバイスデータ変換部25は、ノード2とECU3またはデバイス4との間のデータ形式と、データ伝送システム1内でのデータ形式との変換を行う。デバイスデータ変換部25は、ECU3やデバイス4と直接接続される。図4の例では、ノード2aのECU3aが、ノード2cのデバイス4cを制御するものとする。ECU3aはノード2aのデバイスデータ変換部25と直接接続されており、デバイスドライバ31aはその先の処理(データ変換や通信処理など)を考慮する必要がないのでECU3aのデバイスドライバ31aから見ると、デバイスデータ変換部25は操作すべきデバイスと同等に扱える。このことは操作される側のデバイス4cにとっても同じように当てはまり、デバイス4cからみるとノード2cから制御されていると同等であるため、デバイス4cは従来の装置をそのまま使用することができる。
これらの各機能部は、メモリに格納されたプログラムを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は、デバイスデータ変換部25やECU3からデータ(パケット)送信の要求を受け付ける。送信要求受付部211が受け付けるパケット送信の要求は、一定周期ごとに所定のデータ量を送信する必要があり、送信開始から所定の時間(デッドライン)以内にデータの送信を完了する必要がある。
図11は、周期的なパケット送信の通信タスクを説明する図である。図11Aに示すよ
うに、一定周期Tごとに所定量のパケットを送信する必要がある。また、この送信を完了する制限時間であるデッドラインDが定められている。なお、パケットの送信はデッドライン以内に完了すれば、正しく処理されたものとみなされる。したがって、図11Bに示すように、複数の通信タスクが存在する状況では、各通信タスクのデータを連続して送信する必要はなく、他の通信タスクによる割り込みが発生しても構わない。
うに、一定周期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の処理は省略してもかまない。ただし、DM法による判定は処理負荷が大きいため、ステップS22のような簡単な判定でスケジュール可能性を満たさないことを先に判断するのは有効である。
次に、登録された通信タスクのデータを送信する処理について、図13,14を参照して説明する。図13に示すように、各ノードは、登録された通信タスクのパケットを細かい単位(例えば48バイト)に分割して、通信タスク毎の送信キューに格納しておく。そして、この細かく分割したデータ(エレメントフレームと呼ぶ)を組み立てて、例えば1500バイトのフレームを生成してまとめて送信する。
フレームスケジューラ22が行う、フレーム組み立ての処理について図14を参照して説明する。フレームスケジューラ22は、未送信のデータがある通信タスクの中から、最も高い優先度を持つ通信タスクを選択する(S30)。ここで、通信タスクはデッドラインが短いものほど高い優先度が設定される。そして、選択された通信タスクのバッファ(送信キュー)からエレメントフレームを1つ取り出して、フレームを構築する(S31)。フレームが完成したか、すなわち1500バイトなどの固定長に達したかが判断され(S32)、フレームが完成していない場合には、ステップS30に戻る。フレームが完成
したら、そのフレームを送信バッファに格納する。フレームスケジューラ22は、次の送信タイミングで、送信バッファからこのフレームを取り出して送信する(S33)。
したら、そのフレームを送信バッファに格納する。フレームスケジューラ22は、次の送信タイミングで、送信バッファからこのフレームを取り出して送信する(S33)。
[デバイス制御処理]
次に、上記で説明したデータリンク層およびネットワーク層レベルで通信のリアルタイム性が保証されたデータ伝送システム1を経由した、リモートデバイスの制御処理について説明する。
次に、上記で説明したデータリンク層およびネットワーク層レベルで通信のリアルタイム性が保証されたデータ伝送システム1を経由した、リモートデバイスの制御処理について説明する。
図4において、ノード2aに接続されたECU3aがデータ伝送システム1を経由して、ノード2cに接続されたデバイス4cを制御する場合を例に挙げて説明する。ECU3aは、デバイス4cに対応するデバイスドライバ31aを有している。図15に、デバイス制御処理の流れを示すシークエンス図を示す。
ECU3a上で動作するプログラムは、デバイスドライバ31aのAPIを呼び出すことで、デバイス4cの制御を行う。ECU3aとノード2aは直接接続されており、デバイスドライバ31aは、デバイス制御に関するデータ(デバイスデータ)をI/O空間に書き込んで(S40)、デバイスデータ変換部25に通知する。デバイスドライバ31aとデバイスデータ変換部25aは、このI/O空間上でデータのやりとりを行う。
そして、デバイスデータ変換部25は、ECU3やデバイス4からの信号をI/O空間経由で得たとき(S41)に、データ伝送システム1を使って、デバイスデータの送信を行う。つまり、デバイスデータ変換部25が、データ送信管理部21(送信要求受付部211)に対して、データ送信の要求を行う。
ここで、ECUがデバイスの使用を開始するとき(デバイス制御コマンドがオープンであるとき)には、デバイスデータ変換部25はデータ送信管理部21(送信要求受付部211)に対して、通信タスクの登録を要求する(S42)。
ECU3からデバイス4への制御は、通常、一定間隔(周期)で行われる周期的な通信タスクである。そして、これらのデバイスの制御はデッドラインの要求が定められるので、上記で説明したデッドラインが定められた周期的なデータ送信になる。なお、デバイスの制御が周期的に行われない場合であっても、その制御の最小起動間隔を周期とする周期的な通信タスクと捉えればよい。
データ送信管理部21のスケジュール可能性判定部213は、この通信タスクを登録可能であるか判定するためにスケジュール可能性判定処理を行う(S43)。通信タスクの登録要求が受け付けられることで、データ伝送システム1内におけるデバイスデータの通信は、所定の最大遅延時間以内で完了することが保証される。もちろん、ネットワーク帯域や各ノードに割り当てるフレーム割当量を、デバイス制御に係わる通信のリアルタイム要件を満たせるように設計しておく必要がある。
デバイスオープン時の通信タスク登録処理が終了したら、または、デバイスオープン以外のデバイス制御を行う場合は、ステップS44に進んで、I/O空間経由で取得したデバイスデータを、データ伝送システム1を経由するデータ形式に変換する。具体的には、データ伝送システム1内でのデータ形式は、制御対象のデバイスまで、操作(コマンド)の内容とその操作に用いるデータとが伝送可能な形式であれば、どのような形式であっても構わない。例えば、デバイスを識別する識別子とI/O空間に書き込まれたデータとを一つにまとめたデータ形式に変換することが考えられる。そして、デバイスデータ変換部25は、データ変換したデータを、データ送信管理部21に送出する(S45)。データ送信管理部21は、得られたデータを通信データとしてネットワークに送信する。
デバイスデータ変換部25によってデータ形式が変換されたデバイスデータは、データ伝送システム1内を転送されて、操作対象のデバイス4cが接続されたノード2cが受信する。このデバイスデータを受信したノード2cは、このデバイスデータの宛先が自ノードに接続されたデバイス4cであることが分かるので、このデータをデバイスデータ変換部25cに送出する。
ノード2cのデバイスデータ変換部25cは、デバイスデータを受信(S46)すると、このデータの形式を変換(S47)した上でI/O空間に書き込んで(S48)、デバイス4cに出力する。デバイス4cはI/O空間経由でデバイスデータを取得(S49)し、その内容にしたがった動作を行う。これにより、ノード2aのデバイスドライバ31aから、ノード2cのデバイス4cの操作が行える。
ここで、データ伝送システム内1の最大遅延が保証されることから、この最大遅延時間と各ノードでの処理時間を加えた時間以内で、デバイスの制御が実現されることになる。
なお、上記の説明では、ECUからデバイスを制御する操作を例に挙げて説明したが、デバイスからのデータをECUに送信する操作も同様である。
〈実施形態の効果〉
まず、リング型ネットワークを構築し、送信順序テーブルによって各ノードのフレーム送信タイミングを規定することで、あるノードから送出されたフレームがリング型ネットワーク内の全ノードまで到達する時間(到達遅延)及びノード間の通信速度を保証することができる。
まず、リング型ネットワークを構築し、送信順序テーブルによって各ノードのフレーム送信タイミングを規定することで、あるノードから送出されたフレームがリング型ネットワーク内の全ノードまで到達する時間(到達遅延)及びノード間の通信速度を保証することができる。
そして、データ送信管理部が、デッドラインモノトニック法によってデッドラインを保証可能な通信タスクのみを受け付ける。これにより、ECUやデバイス間で通信を行う場合の通信を、デッドラインを保証することができる。なお、デッドラインモノトニック法で使用するデータ通信速度が上述のように保証されているので、通信タスクのデッドライン保証がより正確なものとなる。
このように、あるノードで受け取られたデータが相手ノードに到達するまでの最悪遅延時間を保証することができるため、送信側と受信側の通信以外での処理に必要を加えることで、処理も含めたエンド・トゥー・エンドの処理時間を算出することが可能となる。
また、送信を要求されたデータを細かい単位に分割してから再度組み立てる構成としているので、優先度は低いがサイズの大きいデータの送信を要求された後に、優先度の高いデータ送信を要求された場合でも、優先度の高いデータがブロックされることがない。
そして、上記のように通信のリアルタイム性が保証された通信ネットワーク(データ伝送システム)を介してデバイス制御を行うので、リモートのデバイスを制御する場合であってもリアルタイム性を確保することが可能となる。さらに、このようにリアルタイム要件を満たしてリモートのデバイスを制御可能であるので、デバイス自体がデバイスドライバを実行するためのプロセッサを持つ必要が無くなり、コストの削減が可能となる。
また、デバイスドライはネットワーク上のどのノードに接続されたECUでも実行可能であるため、ECUの負荷が大きくなった場合には、負荷の少ない他のECUでデバイスドライバを実行することができる。これにより、演算資源を有効に活用することが可能となる。
(第2の実施形態)
第2の実施形態は、主に、スケジュール可能性判定部213が行う処理が第1の実施形態と異なり、その他については第1の実施形態と同様である。したがって、同様の部分については説明を省略する。
第2の実施形態は、主に、スケジュール可能性判定部213が行う処理が第1の実施形態と異なり、その他については第1の実施形態と同様である。したがって、同様の部分については説明を省略する。
図16は、本実施形態におけるスケジュール可能性判定部213のスケジュール可能性判定処理を示すフローチャートである。図16の処理のうち、第1の実施形態(図12)と異なる点は、ステップS27の処理が加わっている点である。
ステップS22でデータ転送量が自ノードに割り当てられた最大転送量を超えると判定された場合、又は、ステップS24でデッドラインモノトニック法によって要求された通信タスクのデッドラインを保証できないと判定された場合に、すぐに通信タスクの登録を拒否するのではなく、ステップS27に進んで、フレーム割当管理部5に対してフレーム割当量の増加を要求する。
フレーム割当管理部5は、フレーム割当量の増加を求められた場合には、フレームの割当て増加が可能であるか判断する。なお、このように後からフレームの割当量を増加できうるように、当初の送信順序テーブルには空きスロットを設けておき、各ノードからの要求に応じて送信タイミングを割り当てればよい。
あるいは、次のような構成を採用しても良い。すなわち、各ノードは通常時においては割り当てられたスロットの全てを使用しないようにする。例えば、フレーム割当管理部5は、各ノードに1サイクルあたりN回の送信機会(スロット)を与えるが、ノード側では1サイクルあたりN−k回(例えばk=2)の送信しか行わないこととする。各ノードが使用している1サイクルあたりのスロット数はフレーム割当管理部5に通知されることとし、フレーム割当管理部5で集中管理できるようにしておく。そして、あるノードでデッドラインが守れないと判断した場合は、まず割り当てられた送信機会を全て使用する。それでもデッドラインを守れない場合には、ステップS27においてフレーム割当量の増加を要求する。フレーム割当管理部5は、他のノードに割り当てられているがそのノードが使用していないタイムスロットがある場合には、そのタイムスロットを増加要求したノードに対して割り当てることとしても良い。
フレーム割当量の増加要求が受け入れられた場合には、ステップS20に戻って再びスケジュール可能性の判定を行う。一方、増加要求が受け入れられなかった場合には、要求された通信タスクの登録を拒否する。
このように送信順序テーブルにおける各ノードへのフレーム割当量を動的に変化させることで、第1の実施形態の効果に加えて、動的に変化する通信要求に対しても対応することが可能となる。
(変形例)
上記の実施形態では、デバイスドライバ31とデバイスデータ変換部25との間のデータのやりとりをI/O空間経由で行うこととしているが、ネットワークインタフェース経由でデータのやりとりをしても構わない。さらに、デバイスドライバ31に対応する側のデバイスデータ変換部25を省略して、デバイスドライバ31自体が、データ送信管理部21が受理可能なデータ形式でデータを作成して、制御対象デバイスが接続されているノード宛てに送信するよう要求しても構わない。
上記の実施形態では、デバイスドライバ31とデバイスデータ変換部25との間のデータのやりとりをI/O空間経由で行うこととしているが、ネットワークインタフェース経由でデータのやりとりをしても構わない。さらに、デバイスドライバ31に対応する側のデバイスデータ変換部25を省略して、デバイスドライバ31自体が、データ送信管理部21が受理可能なデータ形式でデータを作成して、制御対象デバイスが接続されているノード宛てに送信するよう要求しても構わない。
1 データ伝送システム
2 ノード
3 ECU
4 デバイス
5 フレーム割当管理部
21 データ送信管理部
22 フレームスケジューラ
23 受信インタフェース(I/F)
24 送信インタフェース(I/F)
25 デバイスデータ変換部
2 ノード
3 ECU
4 デバイス
5 フレーム割当管理部
21 データ送信管理部
22 フレームスケジューラ
23 受信インタフェース(I/F)
24 送信インタフェース(I/F)
25 デバイスデータ変換部
Claims (5)
- データ伝送システムと、これに接続されたコンピュータおよびデバイスとから構成され、前記コンピュータから前記データ伝送システムを介して前記デバイスを制御する分散デバイス制御システムであって、
前記データ伝送システムは、複数のノードが論理的にリング型の接続をしたものであり、
前記ノードの各々が、
あらかじめ定められたタイミングで固定長のフレームを送信することでデータ通信速度を保証すると共に、デッドライン保証可能な通信タスクのみを登録することで通信タスクの最大遅延を保証する通信手段と、
当該ノードに接続されたコンピュータまたはデバイスからデバイス制御に関するデータを得たときに、該データを前記通信手段が通信可能なデータ形式に変換してから前記通信手段に送出するとともに、前記通信手段からデバイス制御に関するデータを得たときに、当該ノードに接続されたコンピュータまたはデバイスが受理可能なデータ形式に変換してから該コンピュータまたはデバイスに出力する、デバイスデータ変換手段と、
を備えることを特徴とする分散デバイス制御システム。 - 前記通信手段は、
固定長のフレームを送信する送信制御手段であって、上流ノードから受信したフレームを下流ノードへ転送するとともに、あらかじめ定められたタイミングで自ノードからのフレームを送信する送信制御手段と、
各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたデータ送信のデッドライン保証が可能か否かを判定し、デッドライン保証可能であれば、該要求されたデータ送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
を有し、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、
前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信する
ことを特徴とする請求項1に記載の分散デバイス制御システム。 - 前記複数のノードのうちの少なくとも1つのノードは、各ノードにおけるフレームの送信順序を管理するフレーム割当管理手段を有し、
前記送信制御手段は、前記フレーム割当管理手段から通知されたタイミングで自ノードからのフレームを送信する
ことを特徴とする請求項2に記載の分散デバイス制御システム。 - 前記スケジュール可能性判定手段は、データ送信の実行要求がデッドライン保証不可能と判定された場合に、前記フレーム割当管理手段に対して、自ノードに対するフレーム割当量の増加を要求する
ことを特徴とする請求項3に記載の分散デバイス制御システム。 - 前記コンピュータは前記デバイスを制御するためのデータを前記デバイスデータ変換手段に所定の周期で送信する
ことを特徴とする請求項1〜4のいずれかに記載の分散デバイス制御システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008128225A JP2009277052A (ja) | 2008-05-15 | 2008-05-15 | 分散デバイス制御システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008128225A JP2009277052A (ja) | 2008-05-15 | 2008-05-15 | 分散デバイス制御システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009277052A true JP2009277052A (ja) | 2009-11-26 |
Family
ID=41442417
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008128225A Pending JP2009277052A (ja) | 2008-05-15 | 2008-05-15 | 分散デバイス制御システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2009277052A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019106830A1 (ja) * | 2017-12-01 | 2019-06-06 | 株式会社日立製作所 | 分散制御装置 |
WO2022190430A1 (ja) * | 2021-03-08 | 2022-09-15 | オムロン株式会社 | 制御システム、設定方法およびネットワークコントローラ |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06314239A (ja) * | 1993-04-28 | 1994-11-08 | Hitachi Ltd | プロセッサシステム |
JPH0993276A (ja) * | 1995-09-21 | 1997-04-04 | Mitsubishi Electric Corp | リング型ネットワークのアクセス制御方法、およびリング型ネットワークシステム |
JP2001186518A (ja) * | 1999-12-27 | 2001-07-06 | Hitachi Kokusai Electric Inc | ディジタル画像データの伝送システム |
JP2002024154A (ja) * | 2000-07-07 | 2002-01-25 | Toshiba Corp | プログラム実行方法およびプログラム実行装置 |
JP2007074218A (ja) * | 2005-09-06 | 2007-03-22 | Toyota Infotechnology Center Co Ltd | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 |
JP2007219937A (ja) * | 2006-02-17 | 2007-08-30 | Toyota Infotechnology Center Co Ltd | タスク管理システム、タスク管理方法およびタスク管理プログラム |
-
2008
- 2008-05-15 JP JP2008128225A patent/JP2009277052A/ja active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06314239A (ja) * | 1993-04-28 | 1994-11-08 | Hitachi Ltd | プロセッサシステム |
JPH0993276A (ja) * | 1995-09-21 | 1997-04-04 | Mitsubishi Electric Corp | リング型ネットワークのアクセス制御方法、およびリング型ネットワークシステム |
JP2001186518A (ja) * | 1999-12-27 | 2001-07-06 | Hitachi Kokusai Electric Inc | ディジタル画像データの伝送システム |
JP2002024154A (ja) * | 2000-07-07 | 2002-01-25 | Toshiba Corp | プログラム実行方法およびプログラム実行装置 |
JP2007074218A (ja) * | 2005-09-06 | 2007-03-22 | Toyota Infotechnology Center Co Ltd | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 |
JP2007219937A (ja) * | 2006-02-17 | 2007-08-30 | Toyota Infotechnology Center Co Ltd | タスク管理システム、タスク管理方法およびタスク管理プログラム |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019106830A1 (ja) * | 2017-12-01 | 2019-06-06 | 株式会社日立製作所 | 分散制御装置 |
WO2022190430A1 (ja) * | 2021-03-08 | 2022-09-15 | オムロン株式会社 | 制御システム、設定方法およびネットワークコントローラ |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4995101B2 (ja) | 共有リソースへのアクセスを制御する方法及びシステム | |
EP1303083B1 (en) | Packet scheduling apparatus | |
US20080123541A1 (en) | Method For Allocating Data To At Least One Packet In An Integrated Circuit | |
JP4856790B2 (ja) | 中継器 | |
JP2002164916A (ja) | 中継装置 | |
US20080107050A1 (en) | Non-destructive media access resolution for asynchronous traffic in a half-duplex braided-ring | |
JP2007142764A (ja) | 局側装置における帯域割当装置、帯域割当方法および帯域割当プログラム | |
CN101286949A (zh) | 基于IEEE802.16d标准的无线Mesh网MAC层资源调度策略 | |
WO2013073172A1 (ja) | 中継装置、中継装置の制御方法、およびコンピュータプログラム | |
WO2005125123A1 (en) | Packet queuing system and method | |
EP3487132A1 (en) | Packet processing method and router | |
JP2009277052A (ja) | 分散デバイス制御システム | |
JP2009278408A (ja) | データ伝送システム | |
JP5307745B2 (ja) | トラヒック制御システムと方法およびプログラムならびに通信中継装置 | |
CN113438153B (zh) | 一种车载网关、智能汽车及控制方法 | |
JP2007074218A (ja) | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 | |
JP7044081B2 (ja) | 車載用通信システム | |
US20070280685A1 (en) | Method of Optimising Connection Set-Up Times Between Nodes in a Centrally Controlled Network | |
WO2016088371A1 (ja) | 管理ノード、端末、通信システム、通信方法、および、プログラム記録媒体 | |
US8018957B2 (en) | Gateway system with automatic dispatch mechanism and method thereof | |
Shokry et al. | Hardware EDF scheduler implementation on controller area network controller | |
Bartolini et al. | Using priority inheritance techniques to override the size limit of CAN messages | |
Gutiérrez et al. | Response time analysis in AFDX networks | |
JP2001007862A (ja) | 通信負荷分散方法 | |
CN112822125A (zh) | 一种业务流的传输方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100927 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120906 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120918 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20130129 |