1. ホーム
  2. 製品・技術情報
  3. デバイスサーバとは?(シリアル - イーサネット・ガイド)

製品・技術情報

デバイスサーバとは?(シリアル - イーサネット・ガイド)

  • 2010.02.16

第2章 シリアル - イーサネットのアプリケーション

シリアル - イーサネットは、シリアルとイーサネットインターフェースの融合によりどんな製品やプロセスにも対応します。一般的に、イーサネットポートが装備できない数百万台以上のレガシータイプのシリアルデバイスは、現在でも汎用的に使用されています。この変換機能は、ビジネスにも製造にも重要な分野となるでしょう。しかし、シリアルデバイスサーバは、これらのレガシータイプのシリアルデバイスをイーサネットLAN/WANへの接続を可能としその他でも利用可能であることによりデータ収集、デバイスの管理および工業用制御などはるかに多くの使い方をもたらします。

デバイスサーバ・オペレーションモード

この章では、デバイスサーバのいろいろなオペレーションモードについて説明します。このオプションには、ホストコンピュータにインストールしたドライバを使用するオペレーションモード、TCP/IPソケット・プログラミングのコンセプトによるオペレーションモード、適切に構成されたデバイスサーバのペア間通信に関係するオペレーションモードなどを含みます。ここで説明するオペレーションモードは、広範囲のアプリケーションに適します。

  • データ収集
  • 工場自動化
  • セキュリティ/出席/入出退管理
  • 医療自動化
リアルCOMモード

シリアルデバイスサーバの殆どの製造業者は、Windows 95/98/MEおよびWindows NT/2000/XPで動作するネイティブ・リアルCOMドライバを提供しておりその多くはLinuxおよびUnixのOS用にfixed ttyドライバも提供しています。シリアルデバイスサーバのシリアルポート用としてホストコンピュータに仮想ローカルCOMポートを作ることによってドライバは、ホストとシリアルデバイス間に透過的コネクションを確立します。これが重要な点でありユーザーは、アプリケーション用に新しくシリアル通信のソフトウェアの書き直しまたは、購入する必要がありません。実際のところシリアルデバイスサーバ用のドライバは、しばしばポート・リダイレクト・ソフトウェアを参照します。その主な機能は、コンピュータがシリアルポートのイーサネットカードを通してリダイレクトすることです。実際のリアルCOMドライバは、リモートのシリアルポートとPC間のデータを転送するばかりでなくRTS, CTS、DTR, DSRおよびDCDピンのようなシリアルポートのライン信号も操作できます。実際、リアルCOMドライバは、世界中広く行きわたっているシリアルデバイスの殆どを制御できる最高の能力を提供します。

リアルCOMモード : シングルホスト・アプリケーション

シングルホスト・アプリケーションは、PCのCOMポートに直接接続されるカードリーダのようなシリアルデバイスをホストとデバイスを自然な形で延長してセットアップします。即ち、1台のホストがシリアルデバイスに接続されホストコンピュータだけがデバイスサーバのシリアルポートに接続されたシリアルデバイスをアクセスすることができます。
ここに示した図は、シングルホストモード用に構成された典型的なデバイスサーバの動作例を描いたものです。この場合、カードリーダは、IPアドレス 192.168.127.254 に設定されたシングルポートのデバイスサーバに接続されデバイスサーバのイーサネットポートは、LANに接続されています。このLANは一般的には、hubまたはスイッチに接続するストレート結線のイーサネットケーブルを使います。IPアドレスを 192.168.127.10 にセットしたホストコンピュータは、同じLANに接続されています。

構成図は、データがカードリーダからイーサネット上でホストコンピュータを経由してユーザープリケーションまで届く場合の一般的な通信路を示しています。留意しておくことは、シリアルデバイスサーバが自動的にイーサネット上を転送できるシリアルデータを準備するということです。

デバイスサーバのファームウェアには、TCP/IPのプロトコルスタックがフル装備されていてイーサネットフレームでフォーマットしたTCPパケットの中へシリアルデータを最適になるようにパックしホストのイーサネットカードに送ります。ホストコンピュータは、自身のTCP/IPプロトコルスタックを通してホスト・アプリケーションにシリアルデータを安全に送ります。

リアルCOMモード : マルチホスト・アプリケーション

マルチホスト・アプリケーションは、1台もしくはそれ以上のコンピュータが複数のシリアルデバイスにアクセスできる環境を設定するための様々な手段を提供します。また、インターネットへのアクセスを可能にするオプションも含みます。正確に表現するとマルチホスト・アプリケーションは、次のように特徴付けられます。

  1. 1台以上のホストがデバイスサーバのシリアルポートに接続されたシリアルデバイスにアクセスできます。
  2. ホストとデバイスサーバは、別なLANに設置できます。(即ち、デバイスサーバをコンフィギュアすることにより送信データは、1台あるいは2台のルータを通すことができます)。

デバイスサーバの個々のポートをどのように設定するかによって2つの異なった状態を作り上げることができます。

サーバの共有

サーバの共有は、特にマルチポートのデバイスサーバに適用され2台もしくはそれ以上のホストが同じデバイスサーバを共有するように1台のデバイスサーバを設定します。しかし、各ホストは、デバイスサーバのシリアルポートの1もしくはそれ以上のポートを占有(エクスクルーシブ)します。

例えば、ここに図示したように16ポートのシリアルデバイスは、そのポートを2台の異なるホストが共有します。ホストAは、ポート1から8までのエクスクルーシブの制御が与えられホストBは、ポート9から16までのエクスクルーシブの制御が与えられています。このタイプの設定は、ユーザーがデバイスサーバのシリアルポートのすべてを無駄なく使用できるのでより経済的です。この場合、2台のポートの両方ともCOM3からCOM10までのラベルをもっているので混乱しないで下さい。COMポートの名称は、異なる2台のホストに存在しそれぞれがOSをもっていますが衝突は、起きないことは明白です。

ポートの共有
■ 非同期ポートの共有
このオプションは、2台もしくはそれ以上のホストが1台のデバイスサーバ上にある1つの同じポートもしくは複数のポートへのアクセスを共有できるようにデバイスサーバを設定します。例えば、図に示すようにデバイスサーバのポート1を設定することによりホストAとホストBの両方がこれら2つのポートへのアクセス権を持てるようになります。

(物理的には1つのポートですがシステム的には見かけ上2つのポートになります。しかしながら何故このタイプのポートの共有を非同期と呼ぶのでしょうか?その理由は、ある瞬間1つのポートにアクセスできるのは、たった1台のホストに限られるからです。例えば、ホストAがポート1に接続している時にホストBがこの同じポートへの接続を行おうとするとホストBの要求は、ホストAがそのCOMポートを開放しない限り拒否されます。この種のアプリケーションは、セキュリティの高い環境を要求するシステムに適しています。

■ 同期ポートの共有
同じように1台以上のホストが同じシリアルデバイスに接続することが必要になる場合があります。2台のホストが同じデバイスからデータを受信する場合がそれです。あるいは、使用されている高位レベルのアプリケーションによっては、同期ポートに設定した2台のホストから1つのポートに必要ならばデータを送ることができます。このタイプのアプリケーションは、冗長性(リダンダンシ)を必要とするデータ収集システムやリモートモニタシステムを設定するのに適しています。

例えば、上図に示すように4台の異なるホストがその2ポートのシリアルデバイスサーバを共有しています。今までのソリューションにおいてデータ収集サーバは、シリアルデバイスを制御するための責任があります。他のデータベースサーバまたは、リモートディスプレイがシリアルデータを共有するためにデータ収集サーバあるいはデータベースに問い合わせをすることができます。 しかし、データ収集サーバがクラッシュすれば全体のシステムは、停止してしまいます。これからのソリューションは、同じシリアルデータを受信するためにイーサネット上の最大4台の透過なトンネルをサポートするためにシリアルデバイスサーバを使用することができます。 これらすべての4台のホストは、シリアルデバイスからデータの受信およびデータの送信が共にできます。これらの4台のホストは、異なったホスト間の制御能力を切り換えるためにリダンダントのアプリケーションを確立することができます。また、この機能は、リモートディスプレイまたは監視アプリケーションに役立ちます。

ソケットモード

オペレーションモードの2番目は、ソケットモードと呼ばれるもので最初からドライバをインストールしなくてもTCP/IPネットワーク上のシリアルデバイスサーバに直接アクセスする方法を提供します。シリアルデバイスサーバをTCP/IPネットワーク層上で直接制御するためには、TCP/IPネットワークの基本となる概念の知識、例えばTCP、UDP、 IP、 NetmaskおよびRoutingのようなものが必要です。この知識のないことが重大欠点ではありませんがインターネットに関連する製品および技術は、極めてポピュラーであり殆どのネットワーク技術者は、今やTCP/IPの概念には慣れ親しんでいます。

ソケット(Socket)は、TCP/IPネットワーク上のネットワークデバイスにアクセスするのに使用されている標準のAPI (アプリケーション・プログラミング・インターフェース)です。2種類のAPI規格が通常使われます。もともとの規格は、Unix/Linux環境用に開発され今では一般にもソケットと呼ばれるようになりました。もう一つのソケットAPI規格は、Windows環境で使用されるものでWinSockと呼ばれています。これら2つの規格には、基本的な相違点がありますが2つのシステムから呼び出されるAPI機能の殆どが同じ構造をしており結果的にソケットベースのネットワーク制御プログラムは、UnixとWindows環境間を簡単に移行できます。実際、このようなプログラムは、殆どのシステムのプラットフォーム間で移植可能ですのでWindows, Linux, Sun OSおよびVxWorks, Windows CE, OSのようなRTOS(Real-Time Operating System)を含めてソケットは、システムプログラマの殆どに幅広く採用されています。

TCP対UDP

ソケットモードを詳しく述べる前に2つの転送プロトコルについて簡単に説明しておきます。TCP (Transmission Control Protocol)とUDP (User Datagram Protocol)の2つ共にTCP/IPネットワーク上でデータを送るためIP層の上に位置します。 TCPを特徴付けるこの強力な方法は、コネクション・オリエンテッドで信頼性のあるデータ伝送を提供できることにあるといわれています。コネクション・オリエンテッドの役割は、ホストがデータを転送し始める前に先ず、シリアルデバイスのサーバと接続を確立しなければなりません。これは電話呼び出し業務と似ています。このような場合、先ず会話を始める前に他方の局の誰かに接続しなければなりません。

特徴の2番目は、TCPが信頼のあるデータ転送のメカニズムを提供するということです。このことは、各パケットが配信される前に十分にチェックされ受信デバイスが確証の取れたパケットを受け取った後に送り手にアクノレッジ(正常受信完了)を発行する必要があることを意味します。

このアクノレッジの発行と受信のプロセスは、TCPが伝送エラーを検出可能にして必要に応じて指定のパケットを再送信できるようにします。更にTCPは、自動的にパケットの接続順の番号に基づいてパケットを再組み立てします。このような方法をとることによりこれらの特徴がTCPを自然と信頼のおけるデータ伝送のプロトコルにします。

実際、世界中の応用例においてTCPは、データストリームの伝送に優れており基幹通信メディアの品質が特に信頼のおけない場合においては、大変優れたソリューションとなっています。しかしながらTCPは、本質的に高速応答するプロトコルではありません。例えば、別なネットワークノードと接続を確立しようとすると非常に長い時間待たされることがあります。TCPは、一度切断された接続を再確立しようとしますがTCPは、接続が失敗したことを宣言するのに"分"単位の時間がかかる場合があります。

2番目の転送オプションは、UDPです。これは限られたデータ量をトータル的にみて高速で伝送するのに理想的です。UDPが高速データ伝送を提供するものとして特徴付けられていることは、この理由によります。UDPは、UDPのデータグラム(パケットに入っている情報)を送る前に接続を確立する必要はなく受信者がアクノレッジを発行する必要もありません。更に、UDPのデータグラムは、一般的には通常のTCPパケットサイズよりも小さく応答時間およびデータ伝送効率は、はるかに改良されています。誰かに郵便を送る状況に似ています。封書に宛名を書いた後にすべきことは、最も近くの郵便ポストに入れるだけです。期待することは、封書がその宛先に滞りなくそのまま届くことですが受信者は、アクノレッジの発行を要求されません。UDPの場合、信頼性は、二の次で速度優先プロトコルでありお使いのアプリケーションにそれを組み込むことによって信頼性を強化する可能性もあります。

他に注目に値するUDPプロトコルの特徴は、各ポイント間伝送に付け加えてポイントからマルチポイントへの伝送を処理するブロードキャストまたはマルチキャストの技法を使っていることです。実際、世界の応用例においてUDPは、カードリーダ、制御機器(PLC, CNC等)およびその他の類似機器に接続する場合に使用されるデータパケット伝送として優れています。ネットワーク環境がうまくいっている時にUDPを使って全体の伝送効率を上げることが可能です。

最近のシリアルデバイスサーバは、TCPまたはUDPのどちらかをベースにする通信能力を持っています。上記は、どちらかのプロトコルがお持ちのアプリケーションに向いているかを選択するのに必要な知識を紹介したものです。

アドレスを付ける

シリアルデバイスサーバあるいは特に、デバイスサーバに付属するシリアルポートをTCP/IPネットワーク上でどのように識別するか興味があると思います。TCPとUDPの両方とも特定のネットワークデバイスとの接続を確立するために「IP + ポート番号」を割り当てます。シリアルデバイスサーバに関するものとして例えば、Telnetを使用するとそのシリアルポートに繋がっているデバイスにアクセスできます。下図に一般的な例を示します。192.168.1.10は、シリアルデバイスのIPアドレスであり4001がTCPのポート番号です。このポート番号は、デバイスサーバのポートの1つに対応しています。ホストから次のコマンドを実行すると

Telnet 192.168.1.10 : 4001

システム管理者が簡単にシリアルデバイスへ接続を確立できます。

データパッキング

シリアルデバイスサーバの設計者が考慮しなければならない潜在的問題は、デバイスサーバのイーサネット側とシリアル側間の伝送速度の不一致です。この問題は、デバイスサーバがシリアルデータをイーサネット上のTCPパケットまたはUDPデータグラムに転送する時、そしてデバイスサーバのTCP/IPのソフトウェアがシリアルデータのストリームを1個もしくはそれ以上のパケットもしくはデータグラムに無意味に分割する時に生じます。分割されたシリアルデータを含むパケットもしくはデータグラムがデータ処理を担うアプリケーションに届いた時、アプリケーションは完全に動作不良になります。

この問題に対するソリューションは、シリアルデータのストリームをデバイスサーバのメモリ内部に置いているバッファに入れることです。そしてシリアル伝送に属するデータを1個のパケットもしくはデータグラムでグループとして一緒に送る必要があります。良いデータパックの機能とは、ユーザーが時間制限とデータサイズの制限の両方を設定するとこでありそれによりデータ収集は、シリアルデータを処理するのにどのアプリケーションが使用されていても整合がとれるようになります。

TCPサーバ

TCPサーバモードにおいて、シリアルデバイスサーバは、シリアルデバイスにとってネットワークエージェントとして動作します。例えば、シリアル・コンソールポートを持ったシリアルデバイス(例えばファイルサーバ)があるとします。このシリアル・コンソールポートは、TCPサーバモードの基でシリアルデバイスサーバに接続していますがシリアルデバイスサーバ経路でネットワークにアクセス可能なポイントになります。TCPサーバモードにおけるシリアルデバイスサーバは、コンソール・ホストからのTCP接続を可能にすると共にコンソール・ホストとシリアルデバイス間の2方向伝送を提供します。

上図に示した例で考案します。デバイスサーバがファイルサーバのコンソールポートに接続されています。この場合、ファイルサーバは、大規模サーバルームにあるうちの1つであってもあるいはシステム管理者が容易にアクセスできないリモートの場所に収納されていても構いません。シリアルデバイスサーバのイーサネットポートをLANに接続することによってシステム管理者は、同じLAN上にあるホストからまたは、もしLANが公衆ネットワークに接続されているインターネットに接続されていればそのホストからPCのコンソールマネージメント機能にアクセスできます。

TCPクライアント

TCPクライアントモードのオペレーションは、別なネットワークデバイス(例えばPC)上に置かれているサーバプログラムと通信を頻繁に確立する必要があるシリアルデバイス用に設計されています。この場合、TCPクライアントとして稼動しているシリアルデバイスサーバは、サーバソフトウェアと頻繁にTCP接続を確立します。シリアルデバイスからのデータがサーバソフトウェアに転送された後、シリアルデバイスサーバは、自動的にTCP接続を切断します。接続されている間サーバソフトウェアは、シリアルデバイスサーバ経由でシリアルデバイスへデータを送ることができます。TCPクライアントは、コネクト・オン・デマンド(必要時接続)タイプに適し許可される最大同時TCP接続を超える位の非常に多くのシリアルデバイスを処理するホストに有効な機能と言えるでしょう。加えて、シリアルデバイスは、殆どのサーバソフトウェアと互換性を保証するデータパッキング機能(以前に説明)が搭載されていることを心に留めておいて下さい。

一例として、上図に示すカードリーダを考えてみます。カードリーダは、その機能性から一般的に24時間の運用がされることが多くあります。一度カードリーダにカードを読ませるとそのストアされたデータは、適切なシリアル信号に変換されシリアルデバイスサーバのシリアルポート経由でデバイスサーバへ送られます。デバイスサーバは、既にリモートPCまたはデバイス上の特定サーバのアプリケーションにデータを送る準備が完了しておりシリアルデータをTCPパケットのフォームにしてリモートアプリケーション(上図の場合にはノートPC上にあります)との接続要求を行ってイーサネットを経由してリモートのホストへそのパケットを送ります。

UDPサーバ/クライアント

UDPサーバ/クライアントモードのオペレーションは、UDPプロトコル層上で高速データ伝送を必要とするアプリケーション用として設計されています。UDPサーバ/クライアント機能を持つシリアルデバイスサーバを使うとシリアルデバイスは、殆ど同時に複数の宛先へデータを送ることができます。UDPの本来の高速性とデータパッキング機能のお陰でシリアルデバイスサーバは、古くから使用されているシリアルデバイスを強力にネットワークに接続可能なデバイスに変身させます。スキャナ、カードリーダ、指紋認識装置、光学スキャナのような入力デバイスには、最適な接続といえます。

一例として上図に示した状況を考えます。この場合、アプリケーションは、カードリーダのデータが全てインターネットに接続されている1台以上のホストへ送られることを必要としています。このような要求を実施する方法は、カードリーダに接続されるデバイスサーバをUDPサーバ/クライアントモードに設定すればよいことです。データがホストのそれぞれに送られるようにシステムをセットアップします。