JP2007295482A - データ伝送システム - Google Patents

Abstract

【課題】ＵＤＰ／ＩＰ伝送手順のような無手順伝送であることによる優位性を保ちながら、データ欠損の生じるリスクを最小限に抑えることが可能なデータ伝送システムを提供する。また、ＵＤＰ／ＩＰ伝送手順のような無手順伝送と、ＴＣＰ／ＩＰ伝送手順のような有手順伝送の相互の利点を有効に活用したデータ伝送システムを提供する。
【解決手段】ＵＤＰ／ＩＰ伝送手順のような無手順伝送でデータ伝送を行うシステムにおいて、装置（Ａ）１から装置（Ｂ）２にデータ４を送信５する場合に、宛先に自装置のアドレスも含めて送信し、装置（Ａ）１が自ら送信したデータ４を折り返しデータ４として受信６する。折り返しデータ４と応答データ７を確認８することにより、データ４の送信が正常に行われたかどうかを確認することができる。
【選択図】 図１

Description

本発明は、上下水道プラントなどの監視制御システムにおけるデータ伝送システムに関する。

プラントの監視制御システムなどの伝送制御において、最も注力されるのは伝送されるデータの欠損が発生しないようにすることである。その為に、従来から様々な制御理論や手法が考えられているが、現在に至るまで確実に送受を行う方法は確立されていない、と言える。

一般的に、伝送は大きく分けてＴＣＰ（トランスミッション・コントロール・プロトコル）／ＩＰ（インターネット・プロトコル）伝送、ＵＤＰ（ユーザー・データプログラム・プロトコル）／ＩＰ伝送、及び近年急速に普及してきたＨＴＴＰ（ハイパー・テキスト・トランスファー・プロトコル）伝送があるが、このうち、監視制御において用いられているのはＴＣＰ／ＩＰ伝送とＵＤＰ／ＩＰ伝送の２種である。

すなわち、ＨＴＴＰ伝送は、広域監視等の無線ＬＡＮを構築する場合には用いられるが、有線ＬＡＮによる高速性を要求される監視制御（特に中央監視制御）では、現状では一般的とはいえない。

一般的に、小容量ではあるが高速な伝送を要求される場合にはＵＤＰ／ＩＰ伝送が用いられ、低速でも大容量のデータ伝送にはＴＣＰ／ＩＰ伝送が用いられることが多い。

しかし、ＴＣＰ／ＩＰ伝送は回線接続時の手順が複雑であり、かつリソース消費量がＵＤＰ／ＩＰ伝送手順に対して大きいというデメリットがあるため、監視制御システムにおいてはＵＤＰ／ＩＰ伝送を用い場合が一般的と言える。

大容量のデータ伝送を扱う場合には、ＵＤＰ／ＩＰ伝送手順を用いた分割伝送により対応する手順が一般的である。（ファイル伝送については除く。ＦＴＰ（ファイル・トランスファー・プロトコル）は基本的にＴＣＰ／ＩＰ手順である。）
ＵＤＰ／ＩＰ伝送手順を用いた分割伝送を行う場合、最もリスクが高いのが伝送パケットの損失であるため、その回避と、リカバリ方法が重要課題である。

ＴＣＰ／ＩＰ伝送手順が確実な電話回線を用いた相手との通話（電話をかけて相手が電話口に出た時に会話が始まるため、確実に相手が受信していることが判る）であるとした場合、ＵＤＰ／ＩＰ伝送手順は、野球の投手が捕手に向かって一方的にボールを投げるのと同じであり、捕手の構えたミットにボールが（それがストライクかボールかは別として）届いた場合に伝送が行われたと判断されることになる。（相手が受信しているかどうかの確実な判断はない。）
また、伝送失敗時のリトライ処理も、ＴＣＰ／ＩＰ伝送がＩＥＥＥ規格の所定の手順に従って理論的な制御の中で再送を実行してくれるのに対し、ＵＤＰ／ＩＰ伝送手順では、再送手順も送信側と受信側で事前に取り決めた手順において処理しなければならない。

ここで、ＵＤＰ／ＩＰ伝送手順のリスク面に改めて目を向けてみると、先に述べたように、ＵＤＰ／ＩＰ伝送は「無手順伝送」とも言われ、伝送データの塊であるパケットを投げるだけの処理である。したがって、ＴＣＰ／ＩＰ伝送のように、先に伝送路と手順を完全に確立しておき、有手順による通信を行うものではないため、再送を含めたパケットの消失に対する回避が困難である。

これを回避するためには、ＵＤＰ／ＩＰ伝送を行う側（送信側、受信側ともに）で、その回避策を講じる必要がある。ここが、ＵＤＰ／ＩＰ伝送手順を使用する場合の最も高いリスク要因といえ、プラント監視機能でのボトルネックとなることが多い。

では、何故このような信頼性が薄く、手順も自分で確立しなければならないＵＤＰ／ＩＰ伝送手順が、データの取扱いに慎重性を要求される監視制御システムで用いられているのか。それは、やはり高速かつシステムにおける伝送負荷が低いということに他ならない。

例えば、分散化システムについて考慮してみる。トランザクションと外乱を無視できるものとしたら、有手順伝送であるＴＣＰ／ＩＰ伝送手順に比べて、ブロードキャスト（ネットワークで接続されているすべての端末に対し、相手を特定せずにデータを送ること）、マルチキャスト（一つの情報を同時に複数の相手へネットワークを通じて配信すること）を実行するのに、高速かつ伝送負荷の軽いＵＤＰ／ＩＰ伝送手順は、ＴＣＰ／ＩＰ伝送手順とは比較にならないほど楽である。まさしく「パケットを投げる」という処理と、投げられたパケットを受け取る処理で完結することになる。

さらに、ＵＤＰ／ＩＰ伝送は「無手順伝送」であるため、逆に手順を作成することができ、適用する監視制御システムに最適な伝送手順の構築が可能となるのである。これが、リスクがありながらも監視制御システムでＵＤＰ／ＩＰ伝送手順が用いられている大きな理由であると言える。

では、前述したＵＤＰ／ＩＰ伝送における高いリスクをどのように回避するか。最初に考えられるのは、無手順を有手順にすることである。「パケットを投げる」だけというＵＤＰ／ＩＰ伝送手順を、「パケットの送受信を行う」伝送手順にすることである。これには、ＵＤＰ／ＩＰ手順をＴＣＰ／ＩＰ手順と同様に用いることである。（無手順であるため、伝送送受信の方法を、システムに適したものとすることができるのは先に述べた通り。）
しかし、ＴＣＰ／ＩＰ手順を模倣するような回避方法であれば、それは伝送容量の少ないＴＣＰ／ＩＰ手順となってしまい、何らのメリットも無い。初めからＴＣＰ／ＩＰ手順で伝送を行えば良いだけである。（伝送容量も増えるし、手順を作成する必要も無い。）
そこで、従来、無手順伝送であるＴＣＰ／ＩＰ手順のリスクを回避する方法として、送信パケットの送信時、同一の送信パケット内に挿入される今回データに、Ｎ（Ｎは整数）回の前回データを付加して送信することが、考えられている（例えば、特許文献１参照）。
特開２００２−２０８９３０号公報

上述のように、無手順伝送であるＵＤＰ／ＩＰ伝送手順のリスクを回避する方法として、今回の送信パケットに、今回データとともにＮ（Ｎは整数）回の前回データを付加して送信することが考えられているが、このように、同一のデータを繰り返し送ったとしても、ＵＤＰ／ＩＰ伝送手順においては、相手方に届いたかどうかを確認することができないため、やはり、確実性に欠けるという問題点があった。

そこで、本発明は、従来のこのような問題点に鑑みて為されたもので、ＵＤＰ／ＩＰ伝送手順のような無手順伝送であることによる優位性を保ちながら、データ欠損の生じるリスクを最小限に抑えることが可能なデータ伝送システムを提供することを目的とする。

また、本発明は、ＵＤＰ／ＩＰ伝送手順のような無手順伝送と、ＴＣＰ／ＩＰ伝送手順のような有手順伝送の相互の利点を有効に活用したデータ伝送システムを提供することを目的とする。

上記目的を達成するために、本発明に係るデータ伝送システムは、第１の装置から第２の装置に対して、無手順伝送によりデータを伝送するデータ伝送システムにおいて、第１の装置に設けられ、第２の装置に対して送信するデータが折り返しデータとして自装置でも受信できるように送信する手段と、第１の装置に設けられ、折り返しデータの受信状態から伝送中の異常発生を検出する手段とを備えたことを特徴とする。

また、本発明に係るデータ伝送システムは、第１の装置から第２の装置に対して、無手順伝送によりデータを伝送するデータ伝送システムにおいて、第１の装置に設けられ、第２の装置に対して送信するデータが折り返しデータとして自装置でも受信できるように送信する手段と、第２の装置に設けられ、第1の装置から送信されたデータを受信したとき、第１の装置に対して応答データを送信する手段と、第１の装置に設けられ、折り返しデータの受信状態と応答データの受信状態とから伝送中の異常発生を検出する手段とを備えたことを特徴とする。

また、本発明に係るデータ伝送システムは、第１の装置から第２の装置に対して、データを伝送するデータ伝送システムにおいて、第１の装置に設けられ、第２の装置に対して無手順伝送によりデータを定周期で送信するとともに、無手順伝送により送信された複数周期分のデータを一括して有手順伝送により再送する手段と、第２の装置に設けられ、第１の装置から無手順伝送により定周期で送信されたデータを受信して処理を行う手段と、第２の装置に設けられ、第１の装置から有手順伝送により再送されたデータを受信する手段と、第２の装置に設けられ、無手順伝送により定周期で送信されたデータの受信に異常が発生した場合に、有手順伝送により再送され受信されたデータによりデータのリカバリを行う手段とを備えたことを特徴とする。

本発明によれば、相手方の装置に対して送信するデータが折り返しデータとして自装置でも受信できるようにして伝送中の異常発生を検出することにより、無手順伝送であることによる優位性を保ちながら、データ欠損の生じるリスクを最小限に抑えることができる。

また、無手順伝送と、有手順伝送とを併用することにより、両者の相互の利点を有効に活用することもできる。

以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下の図において、同符号は同一部分または対応部分を示す。

（第１の実施形態）
まず、本発明の第１の実施形態について説明する。なお、以下の説明においては、無手順伝送の例として、ＵＤＰ／ＩＰ伝送手順を用いた場合について説明しているが、必ずしもＵＤＰ／ＩＰ伝送手順に限らず、他の無手順伝送であってもよいことは言うまでもない。

この第１の実施形態は、パケットの損失を最小限に抑えることを中心に考えた実施形態で、その概略構成を図１に示す。

図１において、装置（Ａ）１は、例えばプラント監視制御システムの監視制御装置、装置（Ｂ）２は、例えばＰＬＣで、装置（Ａ）１と装置（Ｂ）２は、伝送路（Ｃ）３を経由して、表示や制御のためのデータの授受を行うように構成されている。

ここで、装置（Ａ）１から装置（Ｂ）２への１０ＭＢのＥｔｈｅｒｎｅｔ（イーサーネット、登録商標）を用いたＰｔｏＰ（ポイント・ツー・ポイント）伝送を例に考える。（ＰｔｏＰ伝送は、「１対１伝送」であるため、この場合は検証がやりやすい。）
装置（Ａ）１は、定周期で装置（Ｂ）２にＵＤＰ／ＩＰ伝送手順で、一定量のデータを送信する装置であるとする。この場合、装置（Ａ）１では、送信するために自分のＩＰ Ａｄｄｒｅｓｓ（アドレス）とＰｏｒｔ（ポート）によりデータを送信するための出口を自分の中で作成する。

次に、データを送信する相手（装置（Ｂ）２）の「開いているであろう」Ｐｏｒｔに対して、ＤａｔａＧｒａｍ（データ・グラム）と呼ばれるパケットを送信する。これにより、装置（Ａ）１と装置（Ｂ）２を結ぶ伝送路（Ｃ）３に、装置（Ａ）１からの伝送データ４が装置（Ｂ）２に向けて流れ出し、データ送信５が行われることになる。

一方で、装置（Ｂ）２は、装置（Ａ）１から定周期で伝送データ４が来ることが判っているため、あらかじめ受信のためのＰｏｒｔを開いて装置（Ａ）１からの伝送データ４を待つ。この段階で、装置（Ａ）１と装置（Ｂ）２は、投手と捕手の関係となっている。

ここで、装置（Ａ）１は伝送データ４を装置（Ｂ）２に向かって投げているだけ、装置（Ｂ）２は伝送データ４が届くのを待っているだけの関係である。装置（Ａ）１から投げられた伝送データ４が直球であるのか、変化球であるのかは知らない。また、投げられたデータ４がどのような外乱を受けることになるのかも知らないし関知していない。装置（Ｂ）２は、投げられたデータが届くのを期待しているだけである。

この状態で、投げられた伝送データ４が、図２に示すように、外乱（Ｄ）９により、装置（Ｂ）２が期待した時間内に届かなかった場合（送信データ未達１０の場合）はどうなるか？ 装置（Ｂ）２は、伝送データ４を受信するためのＰｏｒｔを閉じることになるのか、それとも届くのをひたすら待ちつづけるのかは、伝送手順の設計者により左右されることになる。

仮に、装置（Ｂ）２が伝送データ４を受信するＰｏｒｔを閉じた場合、遅れて届いた伝送データ４を受け取る相手は存在しなくなる。この場合は、ＩＥＥＥの規程に従って一定時間で伝送データ４は伝送路上から消滅する。（いつまでも残っていては、伝送路をふさぐことになるため。）
また、装置（Ｂ）２が、伝送データ４が届くのを待ちつづけるとしたら、一定周期でデータを送信している装置（Ａ）１からの次のデータはどうなるか？ 図３に示すように、伝送路上に残っている先に送信されたデータと、その後に送信されたデータが衝突を起こしてしまう。ここに、伝送路上でのデータの衝突（コリジョン）１３が発生することになり、装置（Ｂ）２には送信データ未達１０となる。しかも、装置（Ａ）１からの定周期データの送信周期が短いほど発生頻度が高くなることは容易に想像がつく。

回避策の１つは、送信データを受信する装置（Ｂ）２が、一定時間にデータが届かなかったことを、装置（Ａ）１に通知することである。例えば、図４に示すように、装置（Ａ）１に再送要求１７を行うことである。この場合、先に投げたデータが装置（Ｂ）２に届いていないことが装置（Ａ）１に伝わるため、次の２つの方法が取れる。

１つは、同じデータを再送することである。この場合は、それ以降データを送信する周期が、少なくとも１周期毎遅れることになる。（再送時にさらにパケットが損失しなければ。）
２つめは、装置（Ｂ）２に届かなかったデータは諦めて、伝送路上で消失するのに十分な時間を待ってから、次のデータを送信することである。（伝送路上でのＤａｔａｇｒａｍ（データグラム）パケット消失の時間を正確に測ることや制御することは不可能なため、規格の理論値となる。）この場合、データ送信の周期遅れはなくなるが、データが１周期分なくなる。

どちらを選択するべきかは、そのデータの重要性や監視制御システムのあり方によって選択するべきであるが、回避策１には、もう一つの問題がある。装置（Ｂ）２から装置（Ａ）１に伝わるべき、データが届かなかったという情報も損失した場合である。この場合は、装置（Ｂ）２はデータを受信していないし、装置（Ａ）１は装置（Ｂ）２にデータが届いていないことを知らずに定周期伝送を継続する為、装置（Ａ）１と装置（Ｂ）２との間でデータ送受信の認識に差異が生じる。

こう考えれば、回避策２の方が良いように思われるが、データが伝送路上で完全に消失する時間はどのくらいであるか不明のため、装置（Ａ）１が定周期送信をおこなう時間より長い場合は、更なる遅延が発生する要因となってしまい、回避策にならない。（自己矛盾である。）
このように考えると、伝送において、データが相手に届いたかどうかを１００％確実に検出する方法はないことになる。では、この場合の伝送において１００％確実なものは、何があるのか？
この状況において確実にいえることは、装置（Ａ）１においては、データを送信したか否かであり、装置（Ｂ）２についてはデータを受信したか否かだけである。さらに、データの送受信が確実に行われたか否かがわからないということである。既に述べたように、データの損失が発生する可能性は必ずあるため、装置（Ａ）１と装置（Ｂ）２の間で、送受信完了のやり取りを行うことは確実性に欠けることになる。

ここにリスク回避策のリスクが生じることになる。リスクがリスクを生むのである。したがって、リスクが回避できないのであれば、生じる可能性のあるリスクを最小限に抑える方法を考えるしかない。

装置（Ａ）１はデータを送信したことを知っている。装置（Ｂ）２はデータを受信したか否かを知っている。ただし、その接点はどこにも存在しない。このように仮定した上で、効果のある方法を考案する。

伝送路を太くする（回線を早くする）といった物理的な施策もあるが、ここでは、伝送制御をソフトウェアの観点から可能性を低く方法論を考えることに限定する。まず、３者（装置（Ａ）１、伝送路（Ｃ）３、装置（Ｂ）２）を切り分けて考える。

装置（Ａ）１においてであるが、装置（Ａ）１が知りえるのはデータを送信したか否かである。では、どうやって（なぜ）、装置（Ａ）１はデータを伝送したか否かを知りえているか。データを送信するために開いた回線（Ｐｏｒｔ）にデータを正常に書き込んだため、データの送信が終わった、つまり正常にデータが送信されたと認識する。だが、この時に本当にデータは送信されているのか？
装置（Ａ）１が行ったことは、Ｐｏｒｔを開いてデータを書き込んだことだけである。自分のＰｏｒｔから先にある伝送路にデータが流れたことを知っているわけではない。書込みが完了したため（それも自分で判断して）、伝送データが送信されたと認識しているにすぎない。ここに落とし穴が無いか？確実にデータが伝送路に送信されていることが認識できるのは、伝送路上に自分が送信した（と思っている）データが装置（Ｂ）２によって読込まれるか、外乱による損失等によりパケットが消滅するまでの間、伝送路上に存在することが確認できた場合のみではないのか。

装置（Ａ）１が伝送路上にデータが送信されたことを確実に知りえるためには、自分が伝送路上に送信したデータを、自分で受信すれば良い。そうすれば、伝送路上にデータが存在していることは判る。ただし、この場合、送信したデータを自分で読んでしまうことにより、伝送路上のデータがなくなる可能性があるため、装置（Ｂ）２にはデータが届かなくなる。

装置（Ａ）１が伝送路上にデータが送信されたことを確実に知りえるためには、自分が伝送路上に送信したデータを、自分で受信すれば良い。そうすれば、伝送路上にデータが存在していることは判る。ただし、この場合、送信したデータを自分で読んでしまうことにより、伝送路上のデータがなくなる可能性があるため、装置（Ｂ）２にはデータが届かなくなる。

したがって、装置（Ａ）１からデータを送信する場合には、自身に対してもデータが折り返し送信されてくるように、自分自身に対しても送信を実行する。これにより、自分に対して送信されるデータを読むことになるため、伝送路上のデータは消滅しないことになる。

すなわち、この第１の実施形態においては、装置（Ａ）１から装置（Ｂ）２にデータを送信する場合に、パケットのヘッダー部に、宛先として、装置（Ｂ）２のアドレスだけではなく、自分自身の装置（Ａ）１のアドレスも含めて送信する。

このように、自分自身の装置（Ａ）１のアドレスも含めて送信することにより、図１に示すように、装置（Ａ）１が自ら送信したデータ４を、装置（Ａ）１で、折り返しデータとして受信６することができる。そして、この装置（Ａ）１から送信したデータ４を装置（Ｂ）２で受信すると、装置（Ｂ）２は、受信したデータと同じ内容のデータを、応答データ７として装置（Ａ）１に対して返信する。

装置（Ａ）１では、折り返しデータ４と応答データ７とを確認８することにより、装置（Ａ）１から装置（Ｂ）２に対するデータ４の送信が正常に行われたかどうかを確認することができる。

まず、装置（Ａ）１で折り返しデータ４が受信されなかった場合は、データ４の送信が正常に行われなかったことが分かる。

次に、図２に示すように、装置（Ａ）１における、折り返しデータ４と応答データ７との確認１２において、装置（Ａ）１で折り返しデータ４は受信したが、外乱（Ｄ）９によりパケット損失が生じて、装置（Ｂ）２に送信データが未達１０の場合は、装置（Ｂ）２からの応答データが未送信１１となるため、装置（Ａ）１において、応答データ７が受信されず、異常が発生したことが分かる。

また、図３に示すように、装置（Ａ）１で折り返しデータは受信したものの、送信データが衝突（コリジョン）１３により、装置（Ｂ）２に送信データが未達１０となった場合、あるいは装置（Ｂ）２に送信データが到達し装置（Ｂ）２から応答データが送信１４されたが、応答データが衝突（コリジョン）１５となった場合は、いずれの場合も、装置（Ａ）１で応答データが未受信１６となるので、異常が発生したことが分かる。

このように、折り返しデータを受信したことにより、装置（Ａ）１から伝送路（Ｃ）３に対して送信データが出力されたことが確認できるとともに、折り返しデータを受信したが、応答データが受信できなかったことにより、装置（Ｂ）２がビジィあるいは異常で受信できなかったか、あるいは伝送路で何らかの異常が発生したことが分かる。

また、折り返しデータと、応答データの両方を受信した場合に、それらのデータを比較して、データの内容が異なっている場合は、装置（Ｂ）２の近辺で異常が発生したことが分かる。なお、装置（Ａ）１から送信される元のデータと受信した応答データとを比較するのではなく、折り返しデータと、応答データを比較しているが、これは、送信される元のデータはいつ消滅するかが特定できない（次のデータを送るために、送ったらすぐ消滅することもありうる）のに対し、折り返しデータの消滅や応答データの消滅のタイミングは、規格で分かるため、折り返しデータと応答データを比較する方が好都合なためである。

以上のようにして、伝送中に異常が発生したことが分かった場合は、装置（Ａ）１から装置（Ｂ）２にデータを再送することにより、装置（Ｂ）２では、受信できなかったデータのリカバリ（修復）ができることになる。

次に、装置（Ｂ）２を中心に考える。装置（Ｂ）２は、装置（Ａ）１からの伝送データを受信するのみであるため、先に述べた装置（Ａ）１のような方法で確認することはできない。常に受身の状態である。この場合、データの受信に関しては、送信元である装置（Ａ）１と伝送路（Ｃ）３に任せる以外に無いため、受信したデータが期待したデータであるか否かを確認することができるだけである。

では、受信したデータが期待したデータでなかった場合（パケット損失等による異常ではなく、受信データそのものが異常データである場合）や、期待した時間内にデータが受信できなかった場合に、どのような振る舞いをすれば良く、また、その旨を、どうやって装置（Ａ）１に対して通知して、データの再送をおこなってもらえばよいのかについては、不可能ということになる。

装置（Ａ）１に対して、通知を行うためには伝送路にデータを送信する必要があるが、その装置（Ｂ）２からのデータが確実に装置（Ａ）１に届く保証は無く、かつ、装置（Ａ）１が行っている定周期でのデータ送信との関係で、受信待ち時間の間に、装置（Ａ）１は次の周期のデータを送信している可能性が高いためである。

したがって、装置（Ｂ）２は、期待したデータが届かなかった場合の処理を自身で完結して処理する以外に方法はないのかということになるが、装置（Ａ）１と連携することで被害を最小限に留める事は可能である。

方法としては、装置（Ａ）１から装置（Ｂ）２が正常にデータを受信したかどうかに関わらず、先に送信したデータも再送してもらうのである。どの程度（周期）まで遡って再送をおこなうかは、システムのあり方とデータの重要性によって異なる。無限に遡って、装置（Ａ）１から再送をおこなうと、不必要な伝送負荷が発生するし、また装置（Ａ）１の伝送性能を保証することもできなくなる。

装置（Ａ）１からデータを再送することにより、装置（Ｂ）２で受信できなかったデータのリカバリ（修復）を行うことについては、例えば特許文献１に記載されている。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。この実施形態は、ＵＤＰ／ＩＰ伝送手順のような無手順伝送と、ＴＣＰ／ＩＰ伝送手順のような有手順伝送の相互の利点を有効に活用したものである。なお、以下の説明においては、無手順伝送の例として、ＵＤＰ／ＩＰ伝送手順を、また有手順伝送の例として、ＴＣＰ／ＩＰ伝送手順を用いた場合について説明しているが、必ずしもＵＤＰ／ＩＰ伝送手順、ＴＣＰ／ＩＰ伝送手順に限らず、他の無手順伝送、有手順伝送であってもよいことは言うまでもない。

ここで、再度装置（Ａ）１に戻して、再度再送の仕組みについて考察する。先にＵＤＰ/ＩＰ伝送は手軽で高速であり、ＴＣＰ/ＩＰ伝送は手順が複雑であり、かつ切断が発生した時の再接続が煩雑であることは既に述べた。だが、ＴＣＰ/ＩＰ伝送はＵＤＰ/ＩＰ伝送よりも容量の大きいデータを１度に送信することが可能である。ＴＣＰ/ＩＰ伝送で送信可能なデータは、ＵＤＰ/ＩＰ伝送の約８倍である（だからと言って、伝送効率が８倍になるわけではないが）。

したがって、高速性を要求されるデータの送信に使用しなければ問題無い、ということになる。このＴＣＰ/ＩＰ伝送を再送データの伝送に使用することは十分に考えられる。事実、ネットワーク接続の確認に頻繁に使用されるＰｉｎｇコマンドはＴＣＰ/ＩＰを使用している。そうすれば、ＴＣＰ/ＩＰで確立されている伝送路を通じて、データの再送を実行すればよい。そうすれば、装置（Ａ）１は定周期伝送をＵＤＰ/ＩＰ伝送で実行し、再送処理をＴＣＰ/ＩＰ伝送で行うことができる。８周期前のデータを再送することができれば、ほとんどデータの欠落はなくなると考えられる。ただし、この方法は使用するＰｏｒｔ数に制約が無く、かつＴＣＰ/ＩＰ伝送をおこなうのに十分なリソースが確保できる、と言う条件がある。

このように、定周期伝送をＵＤＰ/ＩＰ伝送で実行し、再送処理をＴＣＰ/ＩＰ伝送で行うようにした第２の実施形態の概略構成を図５に示す。すなわち、この第２の実施形態においては、図６に示すように、装置（Ａ）１は装置（Ｂ）２に対し、例えば第１の実施形態に示すような方法で、定周期伝送をＵＤＰ/ＩＰ伝送で実行し、３周期分のデータを一括してＴＣＰ/ＩＰ伝送で再送１８する。

装置（Ｂ）２においては、通常はＵＤＰ/ＩＰ伝送で受信したデータで処理を行い、ＵＤＰ/ＩＰ伝送によるデータの受信で異常が発生した場合に、ＴＣＰ/ＩＰ伝送で再送されたデータによりデータのリカバリ（修復）を行う。

このようにすることにより、小容量ではあるが高速な伝送を行うことができるＵＤＰ／ＩＰ伝送手順と、低速でも大容量の伝送を行うことができＵＤＰ/ＩＰ伝送に較べて確実な伝送が可能なＴＣＰ／ＩＰ伝送手順の相互の利点を有効に活用することができる。

（実施形態の効果）
上述の第１および第２の実施形態で説明したように、Ｅｔｈｅｒｎｅｔ伝送を行う装置（Ａ）、伝送路（Ｃ）、装置（Ｂ）について、それぞれの役割を明確にし、効率を最大限に、損失（率）を最小限に抑えることで伝送制御の信頼性を高めることが可能となる。

無論、装置（Ａ）と装置（Ｂ）は逆の立場（送信側と受信側、という意味において）になることが考えられるため、装置（Ａ）、装置（Ｂ）の両方に送受信の仕組みを入れておく必要がある。そうした場合に、前述した機能を用いて双方向での送受信が高まることにより、伝送データが確実に送信され、受信側の装置がデータを受信したことを、伝送制御を用いて相手側装置に通知することも可能となる接点を作れば良い。

自分が知っている情報を相手に伝達する方法（それも１００％確実に伝達する方法）は存在しないと言える。仮に、装置（Ａ）と装置（Ｂ）の間に、複数の中継点を作ってみても、同様の問題が、今度は装置（Ａ）（装置（Ｂ））と中継点の間で生じるだけである。伝送路を太くする、伝送路の速度を１００ＭＢにしてみる等の施策も、データ欠損の可能性を低くすることはできても、確実とはいえない。

伝送路上をマッピングして、分割したブロックに書き込まれるデータを特定しておく方法も考えられる。ただし、この技術を現実に用いるためにはハードウェア面での改造も必要となる。それは、「Ｅｔｈｅｒｎｅｔ上にあるデータは一定時間で消滅する」ためである。この「一定時間で消滅してしまう」を回避しなければ、上記の技術の現実化は有り得ない。（実現化したとしても、そのブロックに書き込まれているデータを受信側がいつ読込むのかが不定であるため。）
したがって、ＵＤＰ/ＩＰ伝送手順の高速かつ軽量な利点と、低速であり、リソース消費量も大きいが、ＵＤＰ/ＩＰ伝送手順に較べて確実な伝送が可能なＴＣＰ/ＩＰ伝送手順との併合により、基本となるデータ伝送の核の機能を構築する。このような基礎技術が確立されている状態で、はじめて伝送路の２重化や送信データの反転２連送等の付加技術も有効に生きてくることになる。

本発明の第１の実施形態に係るデータ伝送システムの概略構成を示す図。 本発明の第１の実施形態における外乱によるパケット損失が生じた場合の動作を説明するための図。 本発明の第１の実施形態における衝突によるパケット損失が生じた場合の動作を説明するための図。 本発明の第１の実施形態における再送要求を行った場合の動作を説明するための図。 本発明の第２の実施形態に係るデータ伝送システムの概略構成を示す図。 本発明の第２の実施形態の動作を説明するための図。

符号の説明

１…装置（Ａ）
２…装置（Ｂ）
３…伝送路（Ｃ）
４…伝送データ
５…データ送信
６…折り返し受信
７…応答データ
８、１２…折り返しデータ４と応答データ７の確認
９…外乱（Ｄ）
１０…送信データ未達
１１…応答データ未送信
１３…送信データ衝突
１４…応答データ送信
１５…応答データ衝突
１６…データ未受信
１７…再送要求
１８…ＴＣＰ／ＩＰ伝送による再送

Claims (3)

1. 第１の装置から第２の装置に対して、無手順伝送によりデータを伝送するデータ伝送システムにおいて、前記第１の装置に設けられ、前記第２の装置に対して送信するデータが折り返しデータとして自装置でも受信できるように送信する手段と、前記第１の装置に設けられ、前記折り返しデータの受信状態から伝送中の異常発生を検出する手段とを備えたことを特徴とするデータ伝送システム。
2. 第１の装置から第２の装置に対して、無手順伝送によりデータを伝送するデータ伝送システムにおいて、前記第１の装置に設けられ、前記第２の装置に対して送信するデータが折り返しデータとして自装置でも受信できるように送信する手段と、前記第２の装置に設けられ、前記第1の装置から送信されたデータを受信したとき、前記第１の装置に対して応答データを送信する手段と、前記第１の装置に設けられ、前記折り返しデータの受信状態と前記応答データの受信状態とから伝送中の異常発生を検出する手段とを備えたことを特徴とするデータ伝送システム。
3. 第１の装置から第２の装置に対して、データを伝送するデータ伝送システムにおいて、前記第１の装置に設けられ、第２の装置に対して無手順伝送によりデータを定周期で送信するとともに、無手順伝送により送信された複数周期分のデータを一括して有手順伝送により再送する手段と、前記第２の装置に設けられ、前記第１の装置から無手順伝送により定周期で送信されたデータを受信して処理を行う手段と、前記第２の装置に設けられ、前記第１の装置から有手順伝送により再送されたデータを受信する手段と、前記第２の装置に設けられ、無手順伝送により定周期で送信されたデータの受信に異常が発生した場合に、有手順伝送により再送され受信されたデータによりデータのリカバリを行う手段とを備えたことを特徴とするデータ伝送システム。
   
   

Images