分散デバイス制御システム
【課題】デバイスの制御をネットワーク経由で他のコンピュータから行う際に、リアルタイム性を保証する。
【解決手段】データ伝送システムと、これに接続されたコンピュータおよびデバイスとから構成され、前記コンピュータから前記データ伝送システムを介して前記デバイスを制御する分散デバイス制御システムであって、前記データ伝送システムは、複数のノードが論理的にリング型の接続をしたものであり、前記ノードの各々が、あらかじめ定められたタイミングで固定長のフレームを送信することでデータ通信速度を保証すると共に、デッドライン保証可能な通信タスクのみを登録することで通信タスクの最大遅延を保証する通信手段と、デバイスデータの形式を変換するデバイスデータ変換手段と、を備える。
【解決手段】データ伝送システムと、これに接続されたコンピュータおよびデバイスとから構成され、前記コンピュータから前記データ伝送システムを介して前記デバイスを制御する分散デバイス制御システムであって、前記データ伝送システムは、複数のノードが論理的にリング型の接続をしたものであり、前記ノードの各々が、あらかじめ定められたタイミングで固定長のフレームを送信することでデータ通信速度を保証すると共に、デッドライン保証可能な通信タスクのみを登録することで通信タスクの最大遅延を保証する通信手段と、デバイスデータの形式を変換するデバイスデータ変換手段と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してデバイスを制御する分散デバイス制御システムに関する。
【背景技術】
【０００２】
近年、自動車などを構成する各部の機構が電動化され電子制御化される傾向にある。このように、操作情報を電気信号に置き換え、コンピュータで制御することにより機器（デバイス）を操縦するシステムはＸｂｙＷｉｒｅと呼ばれる。例えば、ブレーキやスロットル、ステアリングといった従来は機械的な結合で操作されていた機構が、モータを利用した機構に置き換えられる。
【０００３】
このようなデバイスの制御にはミリ秒オーダー以下でのリアルタイム性を要求されるため、デバイスに内蔵されたＥＣＵか、またはデバイスが接続されているノードで動作するデバイスドライバによって制御されることが一般的である。
【０００４】
デバイスにＥＣＵを内蔵した場合は、デバイス自体が高価になってしまう。また、デバイスが接続されているノードにデバイスドライバを実行させると、そのノードが過負荷になってしまう事態が想定される。
【０００５】
従来、ネットワークを介して接続された他のコンピュータに接続されたデバイスを、あたかも自ノードに直接接続されているかのように取り扱う仮想デバイスドライバの仕組みが提案されている（特許文献１−３）。しかしながら、これらの提案では通信のリアルタイム要求を考慮していないため、上記のような厳しいリアルタイム性を要求される車載システム等には適用できない。
【０００６】
なお、本発明者は、データ送信のトラフィック量を管理・調整してリアルタイム性を確保する技術を発明し出願済みである（特許文献４）。
【特許文献１】特開２００２−２４１５４号公報
【特許文献２】特開２００５−２９３４１７号公報
【特許文献３】特開２００６−１７２１４２号公報
【特許文献４】特開２００７−７４２１８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、デバイスの制御をネットワーク経由で他のコンピュータから行う際に、リアルタイム性を保証することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、以下の構成によって上記目的を達成する。
【０００９】
本発明は、データ伝送システムと、これに接続されたコンピュータおよびデバイスとから構成され、前記コンピュータから前記データ伝送システムを介して前記デバイスを制御する分散デバイス制御システムである。ここで、前記データ伝送システムは、複数のノードが論理的にリング型の接続をしたものであり、前記ノードの各々が、あらかじめ定められたタイミングで固定長のフレームを送信することでデータ通信速度を保証すると共に、デッドライン保証可能な通信タスクのみを登録することで通信タスクの最大遅延を保証する通信手段と、当該ノードに接続されたコンピュータまたはデバイスからデバイス制御に
関するデータを得たときに、該データを前記通信手段が通信可能なデータ形式に変換してから前記通信手段に送出するとともに、前記通信手段から当該ノードに接続されたコンピュータまたはデバイスについてのデバイス制御に関するデータを得たときに、当該ノードに接続されたコンピュータまたはデバイスが受理可能なデータ形式に変換してから該コンピュータまたはデバイスに出力する、デバイスデータ変換手段と、を備える。
【００１０】
このように、リング型ネットワークを採用し、各ノードが固定長のフレームを送信すると共に、その送信タイミングがあらかじめ定められている。これにより、あるノードにおいてフレームの送信要求があってから、そのフレームがネットワーク内の他のノード（送信先ノード）に送信されるまでの時間の最大値（最悪遅延時間）に上限を設けることができる。この最悪遅延時間は、送信タイミングが来るまでの待ち時間と、ネットワーク全体にフレームが送信される転送時間との合計として求められる。これらはいずれも固定された値であるため、本データ伝送システムにおいては、この最悪遅延時間以内でのフレームの送信が保証されることになる。
【００１１】
なお、論理的なリング型ネットワークには、ネットワークが物理的にリング型になっているネットワーク以外のネットワークも含まれる。すなわち、各ノードがデータの受信は上流ノードから行い、データの送信は下流ノードへ行うことで、全体として通信路がリング型となっているネットワークであれば、物理的形態を問わずに含むものである。なお、以下本明細書中では「リング型ネットワーク」の語は、このような論理的な意味で用いる。
【００１２】
そして、上記のようにデータ転送量が保証された上で、通信手段は、デッドラインを保証できる場合だけその通信タスクを登録する。したがって、ネットワーク内の全てのノードについてデータ送信のデッドラインを保証することが可能となる。
【００１３】
このように、通信タスクの最大遅延を保証可能なデータ伝送システムを介して、コンピュータがリモートのデバイスを制御するため、リアルタイム性の確保が可能となる。
【００１４】
なお、前記コンピュータは前記デバイスを制御するためのデータを前記デバイスデータ変換手段に所定の周期で送信することが好適である。この周期的な要求（制御データの通信）の通信タスクを通信手段に登録することで、この通信タスクに必要なネットワークリソースを確保することができる。
【００１５】
また、前記通信手段は、固定長のフレームを送信する送信制御手段であって、上流ノードから受信したフレームを下流ノードへ転送するとともに、あらかじめ定められたタイミングで自ノードからのフレームを送信する送信制御手段と、各周期においてデッドラインが定められた周期的なデータ送信の実行要求を受け付ける送信要求受付手段と、前記要求されたデータ送信のデッドライン保証が可能か否かを判定し、デッドライン保証可能であれば、該要求されたデータ送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたデータ送信の全てについてデッドラインを保証できる場合に、前記要求されたデータ送信を、実行する通信タスクとして登録し、前記送信制御手段は、前記登録された通信タスクのデータを、該通信タスクの前記デッドラインに応じた優先度で送信することが好適である。
【００１６】
本発明におけるスケジュール可能性判定手段は、デッドラインモノトニック（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 ]