(57)【要約】【課題】デバイスへの入出力タイミングを一定に保持しながら、その入出力タイミングを任意に指定できるネットワークＩ／Ｏシステムを提供する。【解決手段】入出力デバイス１４１，１４２を有するデバイス端末１３０と、デバイス端末と通信ネットワークを介して接続され、デバイス端末を入出力デバイスにアクセスさせるための要求フレーム１１７，１１８を生成してデバイス端末に発行するＥＣＵ１２０とを備え、要求フレームには、デバイス端末が入出力デバイスにアクセスすべきタイミングを示す時間情報２０３，２０４が付加されており、デバイス端末は、要求フレームを受信すると、要求フレームに付加された時間情報を参照し、当該時間情報に示されたタイミングになるまで待機してから入出力デバイスにアクセスする。【選択図】図１２
2010251929.tif 000002
【特許請求の範囲】
【請求項１】
入出力デバイスを有するデバイス端末と、
このデバイス端末と通信ネットワークを介して接続され、前記デバイス端末を前記入出力デバイスにアクセスさせるための要求フレームを生成して前記デバイス端末に発行するホスト端末とを備え、
前記要求フレームには、前記デバイス端末が前記入出力デバイスにアクセスすべきタイミングを示す時間情報が付加されており、
前記デバイス端末は、前記要求フレームを受信すると、前記要求フレームに付加された前記時間情報を参照し、当該時間情報に示されたタイミングになるまで待機してから前記入出力デバイスにアクセスすることを特徴とするネットワークＩ／Ｏシステム。
【請求項２】
請求項１記載のネットワークＩ／Ｏシステムにおいて、
送信される毎にカウントアップされるサイクルカウント値サイクル番号が付加された基準フレームを、前記デバイス端末及び前記ホスト端末に対して一定周期で送信する基準端末をさらに備え、
前記要求フレームに付加された前記時間情報は、前記デバイス端末が前記入出力デバイスにアクセスするタイミングにおけるサイクルカウント値を示すサイクル時間情報と、当該サイクルカウント値が付加された基準フレームを受信したタイミングからの経過時間を示す相対時間情報とを組み合わせて構成されており、
前記デバイス端末は、前記サイクル時間情報が示すサイクルカウント値が付加された基準フレームを受信したタイミングからの経過時間をカウントし、その経過時間が前記相対時間情報が示す時間に達したタイミングで前記入出力デバイスにアクセスすることを特徴とするネットワークＩ／Ｏシステム。
【請求項３】
請求項１記載のネットワークＩ／Ｏシステムにおいて、
前記ホスト端末及び前記デバイス端末は、一定周期で繰り返されるコミュニケーションサイクルにおいて自己に割り当てられたスロットのタイミングを共通の時間認識に従って認識し、当該スロット内で他端末へのフレームの送信を行っており、
前記コミュニケーションサイクルには、繰り返される毎にカウントアップされるサイクルカウント値が付加されており、
前記要求フレームに付加された前記時間情報は、前記デバイス端末が前記入出力デバイスにアクセスするタイミングにおけるサイクルカウント値を示すサイクル時間情報と、当該サイクルカウント値が付加されたコミュニケーションサイクルにおける基準タイミングからの経過時間を示す相対時間情報とを組み合わせて構成されており、
前記デバイス端末は、前記サイクル時間情報が示すサイクルカウント値が付加されたコミュニケーションサイクルにおける基準タイミングからの経過時間をカウントし、その経過時間が前記相対時間情報が示す時間に達したタイミングで前記入出力デバイスにアクセスすることを特徴とするネットワークＩ／Ｏシステム。
【請求項４】
請求項２又は３記載のネットワークＩ／Ｏシステムにおいて、
前記サイクル時間情報は、前記ホスト端末が前記要求フレームを発行するタイミングにおけるサイクルカウント値に、予め定めた遅延サイクル値を加算したものであることを特徴とするネットワークＩ／Ｏシステム。
【請求項５】
請求項２記載のネットワークＩ／Ｏシステムにおいて、
前記相対時間情報は、前記ホスト端末が、直近の基準フレームを受信したタイミングから前記要求フレームを発行するタイミングまでに要した時間であることを特徴とするネットワークＩ／Ｏシステム。
【請求項６】
請求項３記載のネットワークＩ／Ｏシステムにおいて、
前記相対時間情報は、直近のコミュニケーションサイクルにおける基準タイミングから前記ホスト端末が前記要求フレームを発行するタイミングまでに要した時間であることを特徴とするネットワークＩ／Ｏシステム。
【請求項７】
請求項２記載のネットワークＩ／Ｏシステムにおいて、
前記ホスト端末と前記デバイス端末は、それぞれ、直近に受信した基準フレームに付加されたサイクルカウント値を保持するサイクルカウント保持レジスタと、前記直近の基準フレームを受信したタイミングからの経過時間を相対時間情報として保持する相対時間カウンタとを備え、
前記要求フレームに付加された前記サイクル時間情報は、前記要求フレームが生成されたタイミングで前記ホスト端末のサイクルカウント保持レジスタに保持されているサイクルカウント値に、予め定めた遅延サイクル値を加算したものであり、
前記要求フレームに付加された前記相対時間情報は、前記要求フレームが生成されたタイミングで前記ホスト端末の相対時間カウンタに保持されている相対時間情報であり、
前記要求フレームを受信した前記デバイス端末は、当該要求フレームに含まれる前記サイクル時間情報と前記相対時間情報の値が、自己の前記サイクルカウント保持レジスタのサイクル時間情報と自己の前記相対時間カウンタの相対時間情報の値に一致するタイミングで前記入出力デバイスにアクセスすることを特徴とするネットワークＩ／Ｏシステム。
【請求項８】
請求項３記載のネットワークＩ／Ｏシステムにおいて、
前記ホスト端末と前記デバイス端末は、それぞれ、直近のコミュニケーションサイクルに付加されたサイクルカウント値を保持するサイクルカウント保持レジスタと、前記直近のコミュニケーションサイクルにおける基準タイミングからの経過時間を相対時間情報として保持する相対時間カウンタとを備え、
前記要求フレームに付加された前記サイクル時間情報は、前記要求フレームが生成されたタイミングで前記ホスト端末のサイクルカウント保持レジスタに保持されているサイクルカウント値に、予め定めた遅延サイクル値を加算したものであり、
前記要求フレームに付加された前記相対時間情報は、前記要求フレームが生成されたタイミングで前記ホスト端末の相対時間カウンタに保持されている相対時間情報であり、
前記要求フレームを受信した前記デバイス端末は、当該要求フレームに含まれる前記サイクル時間情報と前記相対時間情報の値が、自己の前記サイクルカウント保持レジスタのサイクル時間情報と自己の前記相対時間カウンタの相対時間情報の値に一致するタイミングで前記入出力デバイスにアクセスすることを特徴とするネットワークＩ／Ｏシステム。
【請求項９】
請求項７又は８記載のネットワークＩ／Ｏシステムにおいて、
前記ホスト端末は、前記要求フレームに付加する前記時間情報の更新を一時的に停止する時間情報更新マスク手段をさらに備え、
前記時間情報更新マスク手段が前記時間情報の更新を停止している間に生成された要求フレームを受信した複数の前記デバイス端末は、対応する前記入出力デバイスに同時にアクセスすることを特徴とするネットワークＩ／Ｏシステム。
【請求項１０】
請求項１から３のいずれか記載のネットワークＩ／Ｏシステムにおいて、
前記ホスト端末は複数存在していることを特徴とするネットワークＩ／Ｏシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを経由してデバイスへの入出力を行うネットワークＩ／Ｏシステムに関する。
【背景技術】
【０００２】
車輌、ロボットなどの分野における組込み制御には、センサやアクチュエータなど、多数のデバイスを統合的に運用できる制御システムが求められる。そのような制御システムの構成方法としては、１つの電子制御ユニット（ＥＣＵ（Electronic Control Unit））と多数のデバイスを信号線で個別に接続する方式がある。しかし、この方式では、配線量や配線長が増大し、コストアップや信頼性・保守性の低下を招いてしまう。そのため、近年では、（１）処理系毎に設けた複数のＥＣＵを、管轄するデバイスの近くにそれぞれ分散配置し、各ＥＣＵ間を通信ネットワークで結ぶことによって協調動作を行う分散制御方式や、（２）多数のデバイスを通信ネットワークで結び、その通信ネットワークを介してＥＣＵから各デバイスにアクセスするネットワークＩ／Ｏ方式などの省配線技術が多く使われるようになった。
【０００３】
この種の通信ネットワークのうち、車輌制御などの分野で広く使われているものとしてＣＡＮ（Controller Area Network：ISO 11898）がある（非特許文献１等参照）。ＣＡＮは、通信を必要とする事象が発生したタイミングごとに通信を開始するイベントトリガ型のネットワークである。ＣＡＮにおける通信の基本単位はフレームと呼ばれるデータ列であり、その中にはフレームの優先度を示す識別子（ＩＤ）が含まれている。優先度の異なる２つ以上のフレームの間で競合が発生した場合、最も優先度の高いフレームがデータ送信を継続する。一方、低優先度のフレームは、競合を検出した時点でデータ送信を中断し、高優先度フレームの通信が完了した時点で再度送信を試みる。この方式では、ネットワーク上の通信が混雑してくると、優先度の低いフレームは、自フレームより優先度の高い送信待ちフレームが全て送信されるまで送信されないため、ネットワークの状態によって通信遅延時間が大きく変動するという問題がある。すなわち、イベントトリガ型のネットワークでは、同一ネットワーク上に複数の端末が存在すると、一の端末は他の端末がどのタイミングで通信を開始するか知ることができない。そのため、２つ以上の端末が同時に通信を開始してしまうアクセス競合によって、通信を必要とする事象が発生してからフレームを送信するまでの間に不規則な遅れ時間が生じ、通信遅延時間が変動する可能性がある。
【０００４】
このようなアクセス競合の問題を解決した通信ネットワークの１つとして、ＦｌｅｘＲａｙ（登録商標）がある（非特許文献１等参照）。ＦｌｅｘＲａｙにおける最も大きなアクセス単位は、一定の大きさを持つ固定長のコミュニケーションサイクルである。このコミュニケーションサイクルは、複数のタイムスロット（スロット）で構成されており、この各タイムスロットの中であらかじめ通信内容が定められた通信フレームが送信されるようになっている。これによりＦｌｅｘＲａｙを利用した通信は、コミュニケーションサイクルのサイクル長で定まる時間間隔で周期的に実行される。すなわち、ＦｌｅｘＲａｙは、あらかじめ通信内容がスケジューリングされたタイムトリガ型のネットワークであり、アクセス競合に起因してフレームの送信タイミングが変動しないため、通信遅延時間を一定に保持できる
【非特許文献１】佐藤道夫著，「車載ネットワーク・システム徹底解説」，ＣＱ出版，２００５年１２月
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記のＦｌｅｘＲａｙでは、各デバイスにアクセスするサンプリング周期はコミュニケーションサイクルのサイクル長で定まるため任意に指定できない。また、サンプリングする際の位相も、コミュニケーションサイクル中のタイムスロットの位置で定まるために任意に指定できない。さらに、全ての通信がコミュニケーションサイクルの中に含まれることから、１つのネットワーク中には異なるサンプリング周期のデバイスアクセスを混在させることができない。
【０００６】
本発明の目的は、デバイスへの入出力タイミングを一定に保持しながら、その入出力タイミングを任意に指定でき、なおかつ異なる入出力タイミングを混在させることが可能なネットワークＩ／Ｏシステムを提供することにある。
【課題を解決するための手段】
【０００７】
本発明は、上記目的を達成するために、入出力デバイスを有するデバイス端末と、このデバイス端末と通信ネットワークを介して接続され、前記デバイス端末を前記入出力デバイスにアクセスさせるための要求フレームを生成して前記デバイス端末に発行するホスト端末とを備え、前記要求フレームには、前記デバイス端末が前記入出力デバイスにアクセスすべきタイミングを示す時間情報が付加されており、前記デバイス端末は、前記要求フレームを受信すると、前記要求フレームに付加された前記時間情報を参照し、当該時間情報に示されたタイミングになるまで待機してから前記入出力デバイスにアクセスするものとする。
【発明の効果】
【０００８】
本発明によれば、デバイスへの入出力タイミングを一定に保持しながら、その入出力タイミングを任意に指定することができ、なおかつ異なる入出力タイミングを混在させることができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施の形態を図面を用いて説明する。
【００１０】
図１は本発明の第１の実施の形態に係るネットワークＩ／Ｏシステムの構成図であり、本実施の形態はイベントトリガ型ネットワークの代表的な１つであるＣＡＮ（Controller Area Network：ISO11898）に本発明を適用した例である。
【００１１】
この図に示すＣＡＮネットワーク１００には、入出力デバイスを有するデバイス端末１３０Ａ〜１３０Ｄと、デバイス端末１３０Ａ〜１３０Ｄに対して要求フレーム１１７，１１８を発行するＥＣＵ（ホスト端末）１２０と、デバイス端末１３０及びＥＣＵ１２０に基準フレーム１１６を送信して通信サイクルの基準時間を管理する基準端末１１０が接続されている。
【００１２】
なお、本実施の形態におけるデバイス端末１３０Ａ〜１３０Ｂには入力デバイス１４１（後の図７参照）としてセンサＳが、デバイス端末１３０Ｃ〜１３０Ｄには出力デバイス１４２（図７参照）としてモータＭが接続されている。また、本実施の形態におけるＥＣＵ１２０は、一定周期でセンサＳの値を読み込み、その読み込んだ値を信号処理した結果によりモータＭへのトルク指令値を更新している。
【００１３】
図２は本実施の形態における基準端末１１０の構成図である。なお、先の図と同じ部分には同じ符号を付して説明は省略する（後の各図も同様とする）。
【００１４】
この図に示すように基準端末１１０は、一定周期で周期トリガ信号１１４を発生させる周期トリガ発生手段１１２と、基準フレーム１１６に付加するサイクルカウント値１１５を周期トリガ信号１１４の発生毎にカウントアップするサイクルカウンタ１１３と、周期トリガ信号１１４が発生したタイミングで基準フレーム１１６を生成する基準フレーム生成手段１１１と、生成された基準フレーム１１６をＣＡＮネットワーク１００に送信するネットワークインタフェース１０１を備えている。
【００１５】
図３は基準フレーム１１６の構成図である。ＣＡＮには用途に応じていくつかのフレーム形式が存在するが、ここではデータの送信を目的としたデータフレーム形式を使用するものとする。
【００１６】
この図において、基準フレーム１１６のアービトレーションフィールドには、最高優先度に設定された識別子（ＩＤ）の情報が含まれている。ＣＡＮの通信フレームには、通信の目的毎に一意に指定されたＩＤが含まれており、ＩＤ番号が大きいほど通信の優先順位が高い。すなわち、基準フレーム１１６は、他のいずれのデータフレームよりも通信優先度が高く設定されており、アクセス競合の影響を受けることなく正確に一定の周期で各端末に送信される。
【００１７】
基準フレーム１１６のデータフィールドには、サイクルカウンタ１１３が生成した最新のサイクルカウント値１１５の情報が含まれている。このサイクルカウント値１１５は、ＣＡＮネットワーク１００に接続された全ての端末で共通して認識される基準サイクル時間として使用される。基準フレーム１１６を受信したＥＣＵ１２０およびデバイス端末１３０Ａ〜１３０Ｄは、基準フレーム１１６を受信したタイミングで基準サイクル時間の進行を認識する。
【００１８】
図４は本実施の形態におけるＥＣＵ１２０の構成図である。  
この図に示すように、ＥＣＵ１２０は、プロセッサ（制御用プロセッサ）１２１と、プロセッサインタフェース１２２と、ネットワークインタフェース１０１と、受信フレーム解読手段１２３と、サイクルカウント保持レジスタ１２４と、サイクル遅延指定レジスタ１２５と、加算器１２６と、相対時間カウンタ１２７と、時間情報更新マスク手段１２９と、送信フレーム生成手段１２８を備えている。
【００１９】
ネットワークインタフェース１０１で受信されたフレーム（受信フレーム）は、受信フレーム解読手段１２３によって解読される。受信フレームが基準フレーム１１６であった場合、フレーム解読手段１２３はサイクル更新トリガ２００を発生させると同時に、基準フレーム１１６に含まれているサイクルカウント値１１５をサイクルカウント保持レジスタ１２４に格納する。サイクルカウント保持レジスタ１２４に格納されたサイクルカウント値１１５は、その時点における基準サイクル時間となる。
【００２０】
相対時間カウンタ１２７は、基準フレーム１１６の受信時に生成されるサイクル更新トリガ２００を受信するとカウント値をゼロクリアし、そこからの経過時間（相対時間）を一定周期（例えば１ビットの通信時間幅など）でカウントアップしていく。したがって、相対時間カウンタ１２７が出力する相対時間情報２０４は、基準フレーム１１６を最後に受信してからの経過時間を示し、基準サイクル時間の間隔（基準フレーム１１６の送信周期）より必然的に短くなる。
【００２１】
ＥＣＵ１２０は、デバイス端末１３０Ａ〜１３０Ｄに対して入出力デバイス１４１，１４２へのアクセスを要求する場合、プロセッサ１２１の指示に基づき、送信フレーム生成手段１２８においてデバイス出力要求フレーム１１７またはデバイス入力要求フレーム１１８（冒頭のように、両者をまとめて要求フレーム１１７，１１８と称することがある）を生成し、ＣＡＮネットワーク１００を介してデバイス端末１３０Ａ〜１３０Ｄに送信する。
【００２２】
図５はデバイス出力要求フレーム１１７の構成図であり、図６はデバイス入力要求フレーム１１８の構成図である。
【００２３】
これらの図において、要求フレーム１１７，１１８のデータフィールドには、サイクル時間情報２０３と相対時間情報２０４が埋め込まれている。これらサイクル時間情報２０３と相対時間情報２０４は、デバイス端末１３０Ａ〜１３０Ｄが入出力デバイス１４１，１４２にアクセスすべきタイミングを示す時間情報として利用される。
【００２４】
要求フレーム１１７，１１８に埋め込まれるサイクル時間情報２０３は、デバイス端末１３０Ａ〜１３０Ｄが入出力デバイス１４１，１４２にアクセスするタイミングにおける基準フレーム１１６のサイクルカウント値１１５を示す。本実施の形態におけるサイクル時間情報２０３としては、サイクルカウント保持レジスタ１２４に保持されているサイクルカウント値２０１に、サイクル遅延指定レジスタ１２５に保持されている遅延サイクル値２０２を加算した値が使用されており、このサイクルカウント値２０１と遅延サイクル値２０２の加算は加算器１２６が行っている。遅延サイクル値２０２は、ＥＣＵ１２０が要求フレームを生成したときから入出力デバイスがアクセスされるまでに要する遅れ時間を、基準サイクル時間の整数倍の値で定義したものである。遅延サイクル値２０２は、プロセッサ１２１の指示により予め定めてサイクル遅延指定レジスタ１２５に格納しておく。
【００２５】
要求フレーム１１７，１１８に埋め込まれる相対時間情報２０４は、ＥＣＵ１２０が直近の基準フレーム１１６を受信したタイミングからの経過時間を示す。本実施の形態における相対時間情報２０４としては、要求フレーム１１７，１１８が生成されたタイミングで相対時間カウンタ１２７に保持されている相対時間情報２０４が使われている。すなわち、ＥＣＵ１２０が、直近の基準フレーム１１６を受信したタイミングから要求フレーム１１７，１１８を発行するタイミングまでに要した時間が使用されている。
【００２６】
本実施の形態において、ＥＣＵ１２０が生成した要求フレーム１１７，１１８は、ＣＡＮネットワーク１００を経由してデバイス端末１３０Ａ〜１３０Ｄに送られるため、ネットワークのアクセス競合の影響により、デバイス端末１３０Ａ〜１３０Ｄ側で受け取られるタイミングが不規則に変動する可能性がある。しかし、本実施の形態における要求フレーム１１７，１１８に埋め込まれた時間情報２０３，２０４は、ＥＣＵ１２０が要求フレーム１１７，１１８を生成した時点で確定する。そのため、ネットワークのアクセス競合によって通信時間が変動しても、デバイス端末１３０Ａ〜１３０Ｄが入出力デバイス１４１，１４２にアクセスするタイミングには影響を与えない。
【００２７】
時間情報更新マスク手段１２９は、要求フレーム１１７，１１８に付加する時間情報２０３，２０４の更新をプロセッサ１２１の指示に応じて一時的に停止するものである。時間情報更新マスク手段１２９は、標準動作時において、サイクル時間情報２０３と相対時間情報２０４をそのまま中継し、送信フレーム生成手段１２８に渡す処理を行う。しかし、プロセッサ１２１の指示によって時間情報更新マスク信号２０９が有効化されると、その時点におけるサイクル時間情報２０３と相対時間情報２０４を保持し、送信フレーム生成手段１２８に渡す時間情報の更新を停止する。この機能を利用すると、複数のデバイス端末におけるデバイス入出力動作タイミングを完全に一致させることが可能となる。例えば、デバイス端末１３０Ｃと１３０Ｄに対して、それぞれに宛てたデバイス出力要求フレーム１１７を生成する場合、時間情報更新マスク信号２０９を有効化してから２つのデバイス出力要求フレーム１１７を生成すると、その２つの要求フレーム１１７に埋め込まれる時間情報（サイクル時間情報２０３，相対時間情報２０４）を完全に同じものにすることができる。これにより、デバイス端末１３０Ｃがこれに対応する出力デバイス１４２（モータＭ）にアクセスする時刻と、デバイス端末１３０Ｄがこれに対応する出力デバイス１４２（モータＭ）にアクセス時刻を一致させることができる。
【００２８】
図７は本実施の形態におけるデバイス端末１３０の構成図であり、図８は入力送信要求フレーム２２１の構成図であり、図９は入力データ送信フレーム２２２の構成図である。
【００２９】
図７に示すデバイス端末１３０は、ネットワークインタフェース１０１と、受信フレームの中から基準フレーム１１６を検出する基準フレーム検出器１３１と、デバイス入力要求フレーム１１８またはデバイス出力要求フレーム１１７を検出する入出力要求フレーム検出器１３４と、入力データ送信要求フレーム２２１（図８参照）を検出する送信要求フレーム検出器１３３と、相対時間カウンタ１２７と、サイクルカウント保持レジスタ１２４と、相対時間情報保持レジスタ１３６と、サイクル時間情報保持レジスタ１３７と、出力用データ保持レジスタ１４３と、情報比較手段１３８と、データ出力バッファ１４０と、出力デバイス１４２と、入力デバイス１４１と、データ入力バッファ１３９と、入力データ送信フレーム生成手段１３５を備えている。
【００３０】
デバイス端末１３０が基準フレーム１１６を受信すると、基準フレーム検出器１３１が受信を検出し、サイクル更新トリガ２００を発生させる。またそれと同時に、基準フレーム検出器１３１は、基準フレーム１１６に含まれているサイクルカウント値１１５をサイクルカウント保持レジスタ１２４に格納する。サイクルカウント保持レジスタ１２４に格納されたサイクルカウント値１１５は、その時点における基準サイクル時間となる。
【００３１】
相対時間カウンタ１２７は、基準フレーム１１６の受信時に生成されるサイクル更新トリガ２００を受けるとカウント値をゼロクリアし、そこからの経過時間を一定周期（例えば１ビットの通信時間幅など）でカウントアップしていく。したがって、相対時間カウンタ１２７が出力する相対時間情報２０４は、最後に基準フレーム１１６を受信してからの経過時間を示す。なお、図７では、相対時間カウンタ１２７は、サイクル更新トリガ２００をサイクルカウント保持レジスタ１２４から受信するように記載してあるが、基準フレーム検出器１３１から直接受信してもよい。
【００３２】
デバイス端末１３０がデバイス出力要求フレーム１１７を受信すると、入出力要求フレーム検出器１３４がその受信を検出し、デバイス出力要求フレーム１１７に含まれるサイクル時間情報２０３と、相対時間情報２０４と、出力データ２０７を抽出する。そして、入出力要求フレーム検出器１３４は、抽出したサイクル時間情報２０３をサイクル時間情報保持レジスタ１３７に格納し、抽出した相対時間情報２０４を相対時間情報保持レジスタ１３６に格納し、抽出した出力データ２０７を出力データ保持レジスタ１４３に格納する。ここで、出力データ保持レジスタ１４３に格納された出力データ２０７は、すぐに出力デバイス１４２に出力されず、下記の条件を満たしたときに初めて出力される。
【００３３】
ここで、情報比較手段１３８は、サイクル時間情報保持レジスタ１３７からのサイクル時間情報２０３とサイクルカウント保持レジスタ１２４からのサイクルカウント値２０１とを比較しつつ、相対時間情報保持レジスタ１３６からの相対時間２０４と相対時間カウンタ１２７からの相対時間２０４とを比較し、その両方の比較結果が一致したときにデバイスアクセストリガ２０６を生成する。データ出力バッファ１４０は、情報比較手段１３８で生成されたデバイスアクセストリガ２０６が入力されると、出力データ保持レジスタ１４３の出力値（出力データ２０７）を取り込み、それを出力デバイス１４２に出力する。
【００３４】
一方、デバイス端末１３０がデバイス入力要求フレーム１１８を受信すると、入出力要求フレーム検出器１３４がその受信を検出し、デバイス入力要求フレーム１１８に含まれるサイクル時間情報２０３と、相対時間情報２０４を抽出する。そして、入出力要求フレーム検出器１３４は、抽出したサイクル時間２０３をサイクル時間情報保持レジスタ１３７に格納し、抽出した相対時間情報２０４を相対時間情報保持レジスタ１３６に格納する。
【００３５】
そして、情報比較手段１３８は、その時点におけるサイクルカウント値２０１と相対時間２０４を、それぞれサイクル時間情報保持レジスタ１３７と相対時間情報保持レジスタ１３６の出力値２０３，２０４と比較し、両方とも比較結果が一致したときに、デバイスアクセストリガ２０６を生成する。データ入力バッファ１３９は、生成されたデバイスアクセストリガ２０６が入力されると、入力デバイス１４１から入力データ２２７を取り込んでそれを保持する。
【００３６】
その後、デバイス端末１３０が入力データ送信要求フレーム２２１を受信すると、送信要求フレーム検出器１３３がその受信を検出し、入力データ送信トリガ２０８を生成する。送信フレーム生成手段１３５は、入力データ送信トリガ２０８が入力されると、データ入力バッファ１３９によって保持されている入力データ２２７を埋め込んだ入力データ送信フレーム２２２（図９参照）を生成する。これにより生成された入力データ送信フレームは、ＣＡＮネットワーク１００を経由してＥＣＵ１２０に送られる。
【００３７】
上記のように、本実施の形態におけるデバイス端末１３０は、要求フレーム１１７，１１８に付加された時間情報（サイクル時間情報２０３，相対時間情報２０４）を参照し、その時間情報に示されたタイミングになるまで待機してから入出力デバイス１４１，１４２にアクセスしている。より具体的には、サイクル時間情報２０３及び相対時間情報２０４を参照したデバイス端末１３０は、サイクル時間情報２０３と同じサイクルカウント値の基準フレーム１１６を受信するまで待ち、その基準フレーム１１６の受信タイミングからの経過時間を相対時間カウンタ１２７でカウントし、そのカウント時間が相対時間情報２０４が示す時間に達したタイミングで入出力デバイス１４１，１４２にアクセスしている。そのため、ネットワークのアクセス競合によって通信時間が変動し、デバイス端末１３０Ａ〜１３０Ｄが要求フレーム１１７，１１８を受信するタイミングが変動しても、デバイス端末１３０Ａ〜１３０Ｄが入出力デバイス１４１，１４２にアクセスするタイミングは変動しない。
【００３８】
図１０は本実施の形態におけるＥＣＵ１２０とデバイス端末１３０Ａ〜１３０Ｄの間における各種フレームの流れを図示したものである。ここでは、デバイス出力時のフレームの流れを図１０（ａ）に、デバイス入力時のフレームの流れを図１０（ｂ）に示した。なお、いずれもサイクル遅延指定レジスタ１２５における遅延サイクル値２０２の値を「１」に設定した場合の例である。各図において、基準時間と記載しているタイミングが基準フレーム１１６の受信タイミングであり、このタイミングで基準サイクル時間が１つずつ進んでいく。また、Ｔと表現されているのが、要求フレーム１１７，１１８を生成する時点における相対時間である。
【００３９】
図１０（ａ）では、ＥＣＵ１２０がデバイス出力要求フレーム１１７を送信し、それをデバイス端末１３０が受信している。このデバイス出力要求フレーム１１７には、デバイス出力を実行すべきタイミングを示すサイクル時間情報（基準時間２）２０３と、相対時間情報（Ｔ）２０４と、出力データ２０７が埋め込まれている。デバイス出力要求フレーム１１７を受信したデバイス端末１３０は、サイクルカウント保持レジスタ１２４と相対時間カウンタ１２７の出力値２０１，２０４が、デバイス出力要求フレーム１１７に埋め込まれたサイクル時間情報２０３と相対時間情報２０４に一致するまで待ってから、与えられたデータ２０７を出力デバイス１４２に出力している。
【００４０】
図１０（ｂ）では、ＥＣＵ１２０がデバイス入力要求フレーム１１８を送信し、それをデバイス端末１３０が受信している。このデバイス入力要求フレーム１１８には、デバイス入力を実行すべきタイミングを示すサイクル時間情報（基準時間２）２０３と、相対時間情報（Ｔ）２０４が埋め込まれている。デバイス入力要求フレーム１１８を受信したデバイス端末１３０は、サイクルカウント保持レジスタ１２４と相対時間カウンタ１２７の出力値２０１，２０４が、デバイス入力要求フレーム１１８に埋め込まれたサイクル時間情報２０３と相対時間情報３０４に一致するまで待ってから、入力デバイス１４１からのデータ入力を実行し、データ入力バッファ１３９に格納する。そして、ＥＣＵ１２０は、デバイス入力を実行すべきタイミングの経過後において、入力データ送信要求フレーム２２１をデバイス端末１３０に送信する。なお、このフレーム２２１はＣＡＮの仕様において、応答データを求めるリモートフレーム形式で実装するものとする。リモートフレームを受け取ったデバイス端末１３０は、折り返して、入力データ２２７を埋め込んだ入力データ送信フレーム２２２をＥＣＵ１２０に送信する。ＥＣＵ１２０が入力データ送信フレーム２２２を受信し、そこに埋め込まれたデータをプロセッサ１２１が読み取ることにより、デバイス端末１３０からのデータ入力手続きが完了する。
【００４１】
つぎに本実施の形態の効果について説明する。  
本実施の形態が比較対象とするＦｌｅｘＲａｙ等の方式では、コミュニケーションサイクルに基づいて通信内容が予めスケジューリングされているので、競合に起因する入出力タイミングの変動の発生を防止でき、通信遅延時間を一定に保持することができる。しかしながら、その一方で、コミュニケーションサイクルのサイクル長と無関係にデバイスへの入出力タイミングを任意に設定することができず、複数の異なるサンプリング周期を混在させることができない等の制約を受ける場合があった。
【００４２】
これに対して、本実施の形態のネットワークＩ／Ｏシステムでは、ＥＣＵ１２０から送信される要求フレーム１１７，１１８にデバイス端末１３０が入出力デバイス１４１，１４２にアクセスすべきタイミングを示す時間情報２０３，２０４を付加し、当該要求フレーム１１７，１１８を受信したデバイス端末１３０を、当該時間情報２０３，２０４に示されたタイミングに達するまで待機させてから入出力デバイス１４１，１４２にアクセスするように構成している。
【００４３】
このようにネットワークＩ／Ｏシステムを構成すると、例えアクセス競合によって通信遅延が発生しても、その遅延時間が前記時間情報２０３，２０４によって定めた時間よりも短ければ、ＥＣＵ１２０が各要求フレーム１１７，１１８を生成した周期とデバイス１４１，１４２へのアクセスが実際に実行されるタイミングとを一致させることができる。また、タイムトリガ方式のような周期に係る制約が存在しないため、各デバイス端末１３０におけるデバイスへのアクセスタイミングを通信時間の長さと無関係に自由に設定できる。例えば、上記の実施の形態のように時間情報更新マスク手段１２９を用いれば、複数のデバイス端末１３０に対して順番に要求フレームを送信した場合であっても、その複数のデバイス端末１３０を各デバイスに同時にアクセスさせることができる。
【００４４】
したがって、本実施の形態によれば、入出力デバイスへのアクセスタイミングを一定に保持することができるとともに、当該アクセスタイミングを周期に制約されることなく任意に指定することができる。
【００４５】
さらに、上記で説明した本実施の形態のネットワークＩ／Ｏシステムは、サイクル時間２０１が含まれた基準フレーム１１６を送信する基準端末１１０を備えており、その基準サイクル時間２０１に基づいて設定したサイクル時間情報２０３及び相対時間情報２０４を要求フレーム１１７，１１８に埋め込んでデバイス端末１３０に送信し、その後、デバイス端末１３０が受信した基準フレーム１１６の基準サイクル時間２０１が要求フレーム１１７，１１８に埋め込まれたサイクル時間情報２０３の値に達し、かつ、その基準フレーム１１６を受信したときからの経過時間が要求フレーム１１７，１１８に埋め込まれた相対時間情報２０４の値に達するときまで待ってから、入出力デバイス１４１，１４２にデバイス端末１３０をアクセスさせている。
【００４６】
このような構成と異なり、各端末ごとに個別に経過時間を管理する方式では、各端末が管理する時間の周期数精度が悪いと、時間のずれが徐々に累積して端末間で時間が一致しなくなるという問題が発生する場合がある。しかし、上記のようにサイクル時間情報２０３に相対時間情報２０４を組み合わせて利用すると、基準フレーム１１６が配信されるごとに各端末が管理する相対時間が初期化されて時間のずれが累積しないので、端末間での時間を一致させることができる。
【００４７】
また、上記の構成と異なり、ネットワーク経由で全端末に時間を配信する方式では、時間の分解能を高めるほど、情報量が増大してネットワーク負荷が高くなるという問題がある。しかし、上記のように、共通の時間情報であるサイクル時間情報２０３に、各端末が個別に生成する高分解能の相対時間情報２０４を組み合わせて利用すると、実質的な時間分解能を高く維持したまま配信する時間の分解能を低く抑えられるので、ネットワーク負荷を軽減することができる。
【００４８】
またさらに、上記で説明した本実施の形態のネットワークＩ／Ｏシステムは、サイクル時間情報２０３として、ＥＣＵ１２０が要求フレーム１１７，１１８を発行するタイミングにおけるサイクルカウント値２０１に、予め定めた遅延サイクル値２０２を加算したものを利用している。
【００４９】
このように遅延サイクル値２０２を含めて決定したサイクル時間情報２０３を利用すると、要求フレーム１１７，１１８の発行時（Ｉ／Ｏアクセス要求時）から、入出力デバイス１４１，１４２へのアクセス実行時（Ｉ／Ｏアクセス実行時）までの遅延時間を、複雑な処理を必要としない簡単な構成で通信ごとに設定することができる。このため、優先度が高く通信の競合がほとんど発生しないデバイスへのアクセス要求には遅延時間（遅延サイクル値２０２）を短く設定してリアルタイム性を高めることができ、一方、優先度が低く通信の競合が頻発するデバイスへのアクセス要求には遅延時間を長く設定して確実にアクセス実行することができる。
【００５０】
ところで、上記の説明では、図１に示したように、１つのＥＣＵ１２０が全てのデバイス端末１３０を管理する構成について述べたが、同じ構成のＥＣＵ１２０が複数混在する場合に対しても本発明は適用可能である。
【００５１】
図１１は本発明の第１の実施の形態の変形例に係るネットワークＩ／Ｏシステムの構成図である。
【００５２】
この図に示すネットワークＩ／Ｏシステムは、ＣＡＮネットワーク１００に対して、基準端末１１０と、複数のＥＣＵ１２０Ａ〜１２０Ｃと、デバイス端末１３０Ａ〜１３０Ｃが接続されている。ＥＣＵ１２０Ａ〜１２０Ｃは、それぞれデバイス端末１３０Ａ〜１３０Ｃに搭載されたデバイス１４１，１４２に対して入出力を実施する。
【００５３】
このように、互いに独立したタイミングで動作する複数のＥＣＵ１２０が混在する場合、従来型イベントトリガ方式では、それぞれのネットワークアクセスが互いに競合するため、通信遅れ時間が不規則に変化し、予測できないという問題がある。正確に一定の周期を保ってデバイス１４１，１４２にアクセスしたい用途では、あらかじめ全ての通信を計画することで競合の発生を回避したタイムトリガ型ネットワーク（ＦｌｅｘＲａｙ等）が使用される。しかしながら、このタイムトリガ方式では、スケジューリングされた一連の通信を一定周期で繰り返すため、全てのデバイス１４１，１４２に対して、同じアクセス周期を適用しなければいけないという制約がある。
【００５４】
しかしながら、本発明を適用した場合には、イベントトリガ型ネットワークであっても競合の影響を受けず、一定周期のデバイスアクセスを正確に実行することができ、なおかつ複数のアクセス周期を混在させることができる。この点について下記で説明する。
【００５５】
図１２は本変形例において各ＥＣＵがそれぞれ独立したタイミングでデバイスへの出力を実施したタイミング例を示す図である。  
この図において、上から４つの信号は、上から順番に、基準端末１１０、ＥＣＵ１２０Ａ、１２０Ｂ、１２０Ｃがフレームデータを生成するタイミングを示したものである。ネットワーク通信の優先度は基準端末１１０が最も高く、それからＥＣＵ１２０Ａ、１２０Ｂ、１２０Ｃの順となっている。競合の調停を経てＣＡＮネットワークに実際に出力される信号は、図１２において上から５つ目の信号である。なお、各ＥＣＵ１２０やデバイス端末１３０の動作については、前述の例と同じであるので省略する。
【００５６】
各ＥＣＵ１２０が生成するフレームは、いずれもデバイス出力要求フレーム１１７であり、デバイス出力を実行すべきタイミングのサイクル時間情報２０３と、相対時間情報２０４と、出力するデータ２０７が埋め込まれている。相対時間情報２０４は、要求フレーム１１７を生成するタイミングにおける相対時間カウンタ１２７の値がそのまま埋め込まれており、サイクル遅延指定レジスタ１２５の設定値は全て１とする。
【００５７】
図１２において上から６〜８つ目の信号は、デバイス出力要求フレーム１１７を受信したデバイス端末１３０が、それぞれ要求フレーム１１７に含まれた時間情報２０３，２０４に従って、デバイス出力を実行したタイミングである。このように、競合を調停した結果、ＣＡＮネットワーク上にフレームデータが流れるタイミングは時間的にばらつきがあるが、フレームデータ１１７に含まれる時間情報２０３，２０４に基づいてデバイスアクセスを再現した結果、各ＥＣＵ１２０がフレームデータ１１７を生成した周期と、実際にデバイス出力を実行するタイミングを一致させることができる。また、タイムトリガ方式のような周期に係る制約が存在しないため、複数のデバイス端末１３０に対して、それぞれ異なる周期でアクセスすることができる。このように複数のＥＣＵ１２０が設けられている場合にも、入出力デバイスへのアクセスタイミングを一定に保持することができるとともに、当該アクセスタイミングを周期に制約されることなく任意に指定することができる。
【００５８】
上記の実施の形態で説明したネットワークＩ／Ｏシステムの適用先としては、例えば、パワーショベル（油圧ショベル）等の建設機械の分野が考えられる。
【００５９】
図１３は本発明の第２の実施の形態に係るネットワークＩ／Ｏシステムを備えるパワーショベルの構成図である。  
この図に示すパワーショベルの本体３００には、パワーショベル全体の制御を統括するＥＣＵ１２０と、デバイス端末１３０Ａ〜１３０Ｃが設けられており、ＥＣＵ１２０と各デバイス端末１３０Ａ〜１３０ＣはＣＡＮネットワーク１００によって接続されている。本実施の形態におけるデバイス端末１３０Ａ〜１３０Ｃには、出力デバイス１４２として油圧バルブが実装されている。具体的には、デバイス端末１３０Ａの油圧バルブ操作によってブームシリンダ３０４が伸縮され、デバイス端末１３０Ｂの油圧バルブ操作によってアームシリンダ３０３が伸縮され、デバイス端末１３０Ｃの油圧バルブ操作によってアタッチメントシリンダ３０２が伸縮される。
【００６０】
上記のブーム、アーム、及びバケット（アタッチメント）３０１から成るパワーショベルの作業装置のように、複数の可動軸で構成されたシリアルリンク構造によって先端部（バケット）の位置決めを行う装置では、先端位置を任意の軌道で動かすために、全ての可動軸を連動させて動かすことが求められる。このような装置に対して本発明を適用すると、アクセス競合に起因する通信遅延時間の変動の影響を受けずに、各可動軸に対応した全ての油圧バルブを、同じタイミングで操作することができるため、先端部の移動軌跡を正確に制御できる。
【００６１】
また、例えば、従来方式のイベントトリガ型ネットワークを利用して通信遅延時間が変動した場合には、油圧バルブの操作量を更新する周期が一定とならないため、作業装置の動きがぎこちなくなったり、それによる振動を起こしたりすることが考えられる。しかし、本発明を適用すれば、デバイス（油圧バルブ）への出力更新周期を一定に保つことができるため、作業装置の滑らかな動きが期待できる。
【００６２】
さらに、上記の軌道制御のように、複数の可動軸を連動させて動かさなければならないシステムには、全ての通信をあらかじめスケジューリングすることでアクセス競合を排除したタイムトリガ方式が利用されることが多い。このタイムトリガ方式では、ネットワークに接続された全てのＥＣＵと全てのデバイス端末を、あらかじめ設定したタイムテーブルに従って動作させる必要がある。そのため、デバイス端末の増減などによりタイムテーブルに変更が生じた場合、ネットワークにつながる全ての端末のソフトウェアを同時に変更する必要があるという煩雑さがあった。例えば、上記のパワーショベルの例では、作業内容に応じてバケット３０１を他のアタッチメント（例えば、打撃で物を破壊するブレーカー、物をつかむグラップル、鉄骨などを切断するカッターなど）に交換する場合があるが、各アタッチメントで可動軸数などの仕様が異なっているときには、アタッチメント毎に異なるタイムテーブルが必要となる。
【００６３】
これに対して、本実施の形態のネットワークＩ／Ｏシステムでは、デバイスが動作するタイミングは必ずＥＣＵ１２０側から指示されるため、デバイス端末１３０側でタイムテーブルを把握して、自分でデータ送信タイミングを判断する必要がない。このため、アタッチメント変更などによってデバイス構成が変更になった場合であっても、ＥＣＵ１２０に係るソフトの変更だけで対応することができる。
【００６４】
次に本発明の第３の実施の形態について説明する。
【００６５】
図１４は本発明の第３の実施の形態に係るネットワークＩ／Ｏシステムの構成図であり、本実施の形態はタイムトリガ型ネットワークの代表的な１つであるＦｌｅｘＲａｙ（登録商標）に本発明を適用した例である。ＦｌｅｘＲａｙの通信周期はコミュニケーションサイクルと呼ばれ、このコミュニケーションサイクルには、１つのフレームが送受信される時間区分であるスロットが複数定義されている。ＦｌｅｘＲａｙでは、ネットワーク上の各端末が、共通の時間認識に従って、各コミュニケーションサイクル内において自端末に割り当てられたスロットのタイミングを認識し、当該スロット内で他端末へのフレームの送信を行っている（詳細は後述するが、例えば、ＦｌｅｘＲａｙ対応ＥＣＵ４１０は割り当てられたスロット内で要求フレーム４１７，４１８を送信し、ＦｌｅｘＲａｙ対応デバイス端末４３０Ａ〜４３０Ｄは入力データ送信フレーム４２２を送信している）。
【００６６】
この図に示すＦｌｅｘＲａｙネットワーク４００には、ＦｌｅｘＲａｙ対応ＥＣＵ（以下、ＥＣＵと称することがある）４１０と、複数のＦｌｅｘＲａｙ対応デバイス端末４３０Ａ〜４３０Ｄ（以下、デバイス端末と称することがある）が接続されている。先述のＣＡＮを使ったシステムには、全端末が共通認識可能な基準サイクル時間を作るために、一定周期で基準フレーム１１６を送信する基準端末１１０が設けられていたが、本実施の形態ではこのような端末は不要である。これは、ＦｌｅｘＲａｙのようなタイムトリガ型ネットワークでは、ネットワークに接続された全端末に時間を共通認識する機能が実装されており、その全端末が予め定められたスケジュールに従ったタイミングで通信を行っているからである。
【００６７】
図１５はＦｌｅｘＲａｙの動作の概要図である。
【００６８】
この図に示すようにＦｌｅｘＲａｙは、一定長の通信サイクルであるコミュニケーションサイクルを繰り返し実行することで動作している。コミュニケーションサイクルは、ＦｌｅｘＲａｙにおいて最大の通信周期単位であり、各コミュニケーションサイクルにはそれぞれサイクル番号（サイクルカウント値）が付加されている。サイクル番号はサイクルの繰り返し毎に１つずつカウントアップされる。
【００６９】
各コミュニケーションサイクルの中身は、あらかじめ計画しておいた通信だけが含まれる固定長の静的セグメントと、必要に応じて動的な通信割当てを行う可変長の動的セグメントと、余った時間であるネットワーク・アイドル時間から構成される。
【００７０】
静的セグメントの中には固定長の静的スロットが複数含まれており、各スロットにはスロット番号が割り当てられている。個々のスロットは、それぞれどういう通信に使用するのか用途が定められている。定められた用途において通信の必要が無かった場合、そのスロットは使用されず、他の用途への流用も行わない。そのため、定められた用途において通信の必要が生じた場合は、他の用途との間で通信の競合は発生せず、競合に起因する通信遅れ時間の変動も存在しない。
【００７１】
図１５に示すように、本実施の形態における静的セグメントのスロット１にはＥＣＵ４１０からデバイス端末４３０Ａへのセンサ入力要求フレームが割り当てられており、スロット２にはＥＣＵ４１０からデバイス端末４３０Ｂへのセンサ入力要求フレームが割り当てられており、スロット３にはＥＣＵ４１０からデバイス端末４３０Ｃへのモータ出力要求フレームが割り当てられており、スロット４にはＥＣＵ４１０からデバイス端末４３０Ｄへのモータ出力要求フレームが割り当てられており、スロット５にはデバイス端末４３０ＡからＥＣＵ４１０へのセンサ入力データ送信フレームが割り当てられており、スロット６にはデバイス端末４３０ＢからＥＣＵ４１０へのセンサ入力データ送信フレームが割り当てられている。
【００７２】
図１６は本実施の形態におけるＥＣＵ４１０の構成図である。  
この図に示すＦｌｅｘＲａｙ対応ＥＣＵ４１０は、プロセッサ（制御用プロセッサ）１２１と、プロセッサインタフェース１２２と、サイクル遅延指定レジスタ１２５と、サイクルカウント取得手段４１１と、加算器１２６と、相対時間カウンタ１２７と、時間情報更新マスク手段１２９と、スロット番号指定レジスタ４１４と、ＦｌｅｘＲａｙ送信フレーム生成手段４１３と、ＦｌｅｘＲａｙ受信フレーム解読手段４１２と、ＦｌｅｘＲａｙインタフェース４０１を備えている。
【００７３】
本実の形態では、第１の実施の形態において基準サイクル時間の進行を認識するために使用していた基準フレーム１１６の代わりに、コミュニケーションサイクル中において任意に設定したタイミング（基準タイミング）を基準にして基準サイクル時間を認識している。基準タイミングとしては、例えば、コミュニケーションサイクルが開始したタイミング（開始タイミング）を利用することができる。
【００７４】
各端末に設けられたＦｌｅｘＲａｙインタフェース４０１は、コミュニケーションサイクル中における現在の時間を認識する機能を有している。このＦｌｅｘＲａｙインタフェース４０１により各端末は、コミュニケーションサイクルにおける基準タイミング、そして、現在の時刻を共通認識することができる。
【００７５】
サイクルカウント取得手段４１１は、コミュニケーションサイクルにおける基準タイミングを検出すると、サイクル更新トリガ２００を生成すると同時にサイクルカウント値１１５を取得する。ＦｌｅｘＲａｙの通信フレーム・フォーマット中には、コミュニケーションサイクルのサイクル番号が含まれており、そこから取得できるサイクル番号をサイクルカウント値１１５として利用する。
【００７６】
相対時間カウンタ１２７は、サイクルカウント取得手段４１１からサイクル更新トリガ２００を受けるとカウント値をゼロクリアし、そこからの経過時間を一定周期（例えば１ビットの通信時間幅など）でカウントアップして基準タイミングからの経過時間を示す相対時間情報２０４を生成する。
【００７７】
サイクル遅延指定レジスタ１２５には、プロセッサ１２１の指示に従って、あらかじめ遅延サイクル値２０２が格納されている。遅延サイクル値２０２は、ＥＣＵ４１０がデバイス出力要求フレーム４１７又はデバイス入力要求フレーム４１８を生成したときから、デバイス端末４３０によってデバイス入力又はデバイス出力が実行されるまでに要する遅れ時間であり、コミュニケーションサイクル長の整数倍で定義されている。
【００７８】
加算器１２６は、サイクル遅延指定レジスタ１２５の出力（遅延サイクル値２０２）と、サイクルカウント取得手段４１１の出力（サイクルカウント値１１５）とを加算して、サイクル時間情報２０３を取得する。サイクル時間情報２０３は、デバイス入力（出力）を実行するべきタイミングを示すもので、時間情報更新マスク手段１２９に出力されている。
【００７９】
デバイス端末４３０に対してデバイス入力（出力）を指示する場合、プロセッサ１２１は、まず、指示の伝達対象となるデバイス端末４３０を示すスロット番号を、スロット番号指定レジスタ４１４に格納する。例えば、デバイス端末１３０Ａに対してセンサＳからの入力を指示する場合、図１５記載のスロット番号定義に従って、スロット番号指定レジスタ４１４に「１」を書き込む。次に、プロセッサ１２１は、ＦｌｅｘＲａｙ送信フレーム生成手段４１３に対してフレームの生成を指示する（フレーム生成指示２１１）。プロセッサ１２１からのフレーム生成指示２１１を受けると、ＦｌｅｘＲａｙ送信フレーム生成手段４１３は、時間情報更新マスク手段１２９から渡されたサイクル時間情報２０３と相対時間情報２０４を埋め込んで、スロット番号指定レジスタ４１４の出力値が指すスロット用の要求フレーム４１７，４１８（送信フレーム）を生成する。ＦｌｅｘＲａｙインタフェース４０１は、該当するスロットのタイミングを待って、ＦｌｅｘＲａｙ送信フレーム生成手段４１３が生成した要求フレーム４１７，４１８を該当するデバイス端末４３０に送信する。
【００８０】
なお、時間情報更新マスク手段１２９は、第１の実施の形態と同様に、プロセッサ１２１からの時間情報更新マスク信号２０９を受けて、ＦｌｅｘＲａｙ送信フレーム生成手段４１３に渡す時間情報の更新を停止することができる。これにより、時間情報の更新停止中に生成された複数の要求フレーム４１７，４１８には、デバイス入力（出力）を実行するべき時間として、全く同じ時間を埋め込むことができる。
【００８１】
図１７は本実施の形態におけるデバイス端末４３０の構成図である。  
この図に示すＦｌｅｘＲａｙ対応デバイス端末４３０は、ＦｌｅｘＲａｙインタフェース４０１と、サイクルカウント取得手段４１１と、相対時間カウンタ１２７と、ＦｌｅｘＲａｙ入出力要求フレーム検出器４３１と、出力データ保持レジスタ１４３と、相対時間情報保持レジスタ１３６と、サイクル時間情報保持レジスタ１３７と、情報比較手段１３８と、データ出力バッファ１４０および出力デバイス１４２と、ＦｌｅｘＲａｙ送信フレーム生成手段４１３と、入力デバイス１４１と、データ入力バッファ１３９を備えている。
【００８２】
サイクルカウント取得手段４１１は、コミュニケーションサイクルにおける基準タイミングを検出すると、サイクル更新トリガ２００を生成すると同時に、ＥＣＵ４１０と同様にサイクルカウント値２０１を取得する。相対時間カウンタ１２７は、サイクルカウント取得手段４１１からサイクル更新トリガ２００を受けるとカウント値をゼロクリアし、そこからの経過時間を一定周期（例えば１ビットの通信時間幅など）でカウントアップして相対時間情報２０４を生成する。
【００８３】
デバイス端末４３０がデバイス出力要求フレーム４１７を受信すると、ＦｌｅｘＲａｙ入出力要求フレーム検出器４３１がデバイス出力要求フレーム４１７を検出する。そして、入出力要求フレーム検出器４３１は、デバイス出力要求フレーム４１７に含まれる出力データ２０７と、相対時間情報２０４と、サイクル時間情報２０３を抽出し、その抽出したデータ２０７，２０４，２０３をそれぞれ、出力データ保持レジスタ１４３と、相対時間情報保持レジスタ１３６と、サイクル時間情報保持レジスタ１３７に保存する。
【００８４】
そして、情報比較手段１３８は、相対時間情報保持レジスタ１３６の出力値（相対時間情報２０４）と相対時間カウンタ１２７の出力値（相対時間情報２０４）を比較しつつ、サイクル時間情報保持レジスタ１３７の出力値（サイクル時間情報２０３）とサイクルカウント取得手段４１１の出力値（サイクルカウント値２０１）を比較し、その両方の比較結果が一致したときにデバイスアクセストリガ２０６を生成する。データ出力バッファ１４０は、生成されたデバイスアクセストリガ２０６を受けると、出力データ保持レジスタ１４３から出力データ２０７を取り込み、これを出力デバイス１４２に出力する。
【００８５】
一方、デバイス端末４３０がデバイス入力要求フレーム４１８を受信すると、ＦｌｅｘＲａｙ入出力要求フレーム検出器４３１がデバイス入力要求フレーム４１８を検出する。そして、入出力要求フレーム検出器４３１は、デバイス入力要求フレーム４１８に含まれる相対時間情報２０４とサイクル時間情報２０３を抽出し、その抽出したデータ２０４，２０３をそれぞれ、相対時間情報保持レジスタ１３６とサイクル時間情報保持レジスタ１３７に保存する。
【００８６】
そして、情報比較手段１３８は、デバイス入力を実行すべき時間を示す相対時間情報保持レジスタ１３６とサイクル時間情報保持レジスタ１３７の出力値（相対時間情報２０４，サイクル時間情報２０３）を、それぞれ相対時間情報２０４とサイクルカウント値２０１と比較し、両方が一致したときにデバイスアクセストリガ２０６を生成する。データ入力バッファ１３９は、生成されたデバイスアクセストリガ２０６を受けると入力デバイス１４１から入力データ２２７を取り込み、ＦｌｅｘＲａｙ送信フレーム生成手段４１３に渡す。
【００８７】
ＦｌｅｘＲａｙ送信フレーム生成手段４１３は、データ入力バッファ１３９から入力データ２２７を受け取ると、図１５記載のスロット番号定義に従い、自端末に割り当てられたスロット用に入力データ２２７を埋め込んだ入力データ送信フレーム４２２を生成する。ＦｌｅｘＲａｙインタフェース４０１は、生成された入力データ送信フレーム４２２を該当スロットのタイミングを待って送信する。
【００８８】
デバイス端末４３０が送信した入力データ送信フレーム４２２はＥＣＵ４１０によって取り込まれ、そこのＦｌｅｘＲａｙ受信フレーム解読手段４１２によって入力データ２２７を取り出される。取り出された入力データ２２７は、プロセッサインタフェース１２２経由でプロセッサ１２１から参照することができる。
【００８９】
したがって、タイムトリガ型ネットワークを利用した本実施の形態においても、第１の実施の形態と同様に、入出力デバイスへのアクセスタイミングを一定に保持することができるとともに、当該アクセスタイミングを通信周期に制約されることなく任意に指定することができる。
【００９０】
また、第１の実施の形態と比較した場合の本実施の形態のメリットとしては、第１に、タイムトリガ型ネットワークでは全ての端末の通信サイクルを同期させるための構成要素（基準端末１１０）が必ず必要となるが、各端末で時間を共通認識する機能が実装されている本実施の形態では、このような構成要素を追加する必要が無く、簡単な構成で同様の効果を得られるという点がある。また、第２に、第１の実施の形態のように基準時間情報（基準フレーム１１６）をネットワークに周期的に配信する必要が無いので、ネットワーク負荷を軽減できるという点が挙げられる。
【図面の簡単な説明】
【００９１】
【図１】本発明の第１の実施の形態に係るネットワークＩ／Ｏシステムの構成図。
【図２】本発明の第１の実施の形態における基準端末１１０の構成図。
【図３】本発明の第１の実施の形態における基準フレーム１１６の構成図。
【図４】本発明の第１の実施の形態におけるＥＣＵ１２０の構成図。
【図５】本発明の第１の実施の形態におけるデバイス出力要求フレーム１１７の構成図。
【図６】本発明の第１の実施の形態におけるデバイス入力要求フレーム１１８の構成図。
【図７】本発明の第１の実施の形態におけるデバイス端末１３０の構成図。
【図８】本発明の第１の実施の形態における入力送信要求フレーム２２１の構成図。
【図９】本発明の第１の実施の形態における入力データ送信フレーム２２２の構成図。
【図１０】本発明の第１の実施の形態に係るＥＣＵ１２０とデバイス端末１３０Ａ〜１３０Ｄの間における各種フレームの流れを示す図。
【図１１】本発明の第１の実施の形態の変形例に係るネットワークＩ／Ｏシステムの構成図。
【図１２】本発明の第１の実施の形態の変形例において各ＥＣＵがそれぞれ独立したタイミングでデバイスへの出力を実施したタイミング例を示す図。
【図１３】本発明の第２の実施の形態に係るネットワークＩ／Ｏシステムを備えるパワーショベルの構成図。
【図１４】本発明の第３の実施の形態に係るネットワークＩ／Ｏシステムの構成図。
【図１５】本発明の第３の実施の形態におけるＦｌｅｘＲａｙの動作の概要図。
【図１６】本発明の第３の実施の形態におけるＥＣＵ４１０の構成図。
【図１７】本発明の第３の実施の形態におけるデバイス端末４３０の構成図。
【符号の説明】
【００９２】
１００      ＣＡＮネットワーク
１１０      基準端末
１１５      サイクルカウント値
１１６      基準フレーム
１１７      デバイス出力要求フレーム
１１８      デバイス入力要求フレーム
１２０      ＥＣＵ（ホスト端末）
１２４      サイクルカウント保持レジスタ
１２６      加算器
１２７      相対時間カウンタ
１２９      時間情報更新マスク手段
１３０      デバイス端末
１３７      サイクル時間情報保持レジスタ
１４１      入力デバイス
１４２      出力デバイス
２０１      基準サイクル時間
２０２      遅延サイクル値
２０３      サイクル時間情報
２０４      相対時間情報
２０７      出力データ
２２１      入力送信要求フレーム
２２２      入力データ送信フレーム
２２７      入力データ
４００      ＦｌｅｘＲａｙネットワーク
４０１      ＦｌｅｘＲａｙインタフェース
４１７      デバイス出力要求フレーム
４１８      デバイス入力要求フレーム
４２２      入力データ送信フレーム
４３０      ＦｌｅｘＲａｙ対応デバイス端末
【図１】
2010251929.tif 000003
【図２】
2010251929.tif 000004
【図３】
2010251929.tif 000005
【図４】
2010251929.tif 000006
【図５】
2010251929.tif 000007
【図６】
2010251929.tif 000008
【図７】
2010251929.tif 000009
【図８】
2010251929.tif 000010
【図９】
2010251929.tif 000011
【図１０】
2010251929.tif 000012
【図１１】
2010251929.tif 000013
【図１２】
2010251929.tif 000014
【図１３】
2010251929.tif 000015
【図１４】
2010251929.tif 000016
【図１５】
2010251929.tif 000017
【図１６】
2010251929.tif 000018
【図１７】
2010251929.tif 000019