RS-232Cケーブルのクロス仕様に関する考察

　EIA-232（旧RS-232C＝所謂シリアルインタフェース；以下「RS-232C」）用のケーブルにはストレート仕様とクロス仕様がある。このうち、ストレート仕様には結線上の異同は無いが、クロス仕様には種々の流儀があって、適切なものを選択しないと思い通りに動作しないこともある。
　これは、RS-232Cの本来の目的がモデム（DataSet）と端末装置（DataTerminal）を接続することであって、従って元々はストレート仕様しか存在しなかったからである。パソコンのRS-232Cインタフェースは、モデムに対する端末装置として使うことを想定して設計されたものが多い（稀に、XYプロッタ等の制御を想定して、モデム仕様で設計されているものがある）。端末装置同志を接続するのはRS-232Cの本来の目的ではないから、パソコン同志がRS-232Cで通信する場合には、ちょっとした細工が必要になる。その細工が「信号線をクロスさせて結線することにより互いに相手がモデムであると思い違いさせる」ということである。
　クロス仕様に種々の流儀があるのは、このような「小細工」として自然発生的に作られたものであることに由来する。どのような流儀があるのかを、ざっと見てみよう。

信号線の本来の意味からの考察

　RS-232Cの利用法のうち、一般的に普及している非同期通信で用いる信号線は以下の９本である。（数字は通常のD-sub25でのピン番号）

2 SD（Send Data）送信データ

3 RD（Receive Data）受信データ

4 RTS（Request to Send）モデムに対する送信要求（別名RS）

5 CTS（Clear to Send）モデムからの送信許諾（別名CS）

20 DTR（Data Terminal Ready）端末が回線接続して通信可能（別名ER）

6 DSR（Data Set Ready）回線が接続されて通信可能（別名DR）

8 CD（Carrier Detect）回線にキャリア音検出

7 SG（Signal Ground）信号接地

1 FG（Frame Ground）保安用接地

　クロスケーブルの趣旨から言って、データを通すSDとRDをクロスさせ、２本の接地を直結するのは自明であり、問題になるのは残りの５本である。この５本は、種々の状態を相手に知らせるためのもので、通信中には全てONになっているのが普通である。 RTS・DTRは端末からモデムへ、CTS・DSR・CDはモデムから端末への信号である。
　RS-232Cの規格上、「RTSとCTS」「DTRとDSR」が各々対応する。前者は回線状態に関係なくモデムと端末の通信可能性を通知・制御するものであり、後者は回線の接続状態を通知・制御するものである。 NECがパソコン黎明期に別売附属品として販売していたPC-CA602は、この考えに単純に従って上の２つのペアを対応させ、CDは無結線としている。
　しかし、この結線には、現実的な欠陥がある。パソコンのソフトウェアや周辺機器では、回線状態の直接の指標であるCDを最も簡便な通信可能性指標として用いている場合が多く、このような環境でCDが結線されていないケーブルを用いると、通信可能と看做されなくなり、動作しない結果となる。
　この問題に対処するには、RTSかDTRの何れかをCDとクロスさせれば良い。 RS-232Cの規格上の意味から考えると、回線状態に関連するDTRとクロスさせるのが合理的なように思えるが、 IBM-PC系のパソコンでは、RTSとクロスさせるのが標準になっているらしい（PC-CA602と同様の発想のIBM-PC系用ケーブルを売っているメーカーもあるが）。具体的には、CTSは自機のRTSを直接返し、CDは相手機のRTSを用いる。
　この仕様の理由はよくわからないが、仮説としては、 CTSの動作タイミングに関するRS-232Cの規格を満たすためとも考えられる。規格では、モデムのCTSは常にRTSに反応することが求められている。つまり、RTSがONになった場合はもちろん、OFFになった場合にも直ちに反応してCTSをOFFにせねばならないことになっている。そして、端末側はRTSを一旦OFFにしたら、次にONにする前に CTSがOFFになっていることを確認することになっている。この規格に従った端末装置を使うには、自機のRTSをCTSに返すのが確実である。
　この場合、相手機のRTSの状態をCTSで知ることはできなくなる。そこで、知る手段を確保するためにCDとクロスさせる。即ち、このような消去法でCDとRTSをクロスさせることになったという仮説である。
　IBM-PCはRS-232CにD-Sub9の♂♀逆という妙なコネクタを採用しているが、富士通の非互換機では、標準的なD-sub25を使いつつクロスケーブルの結線はIBM-PCに準じている。 NECが後になって発売した別売附属品PC-9896も概ね同様であるが、何故かDSRを相手機ではなく自機のDTRから取っている。なお、NECはPC-9801/9821シリーズの末期にノートパソコンのスペース節約のため、 RS-232Cにセントロニクスハーフ14の採用を増やしてきた。これに対応するためのケーブルである PC9821N-K05（セントロ同志用）やPC-98HA-16（セントロとD-subの相互接続用）における結線もPC-9896と同様である。

信号線の本来の意味に逆らったクロスについて

　以上とは別に、RTSとDSR、DTRとCTSという、 RS-232Cの規格に真っ向から逆らった結線も多く用いられている。 XYプロッタのメーカーが指定する接続ケーブルや RS-232Cを８芯ケーブルで延ばすことを前提とした機器の指定ケーブルに、この仕様のものが多いようにも思える。
　全くの仮説であるが、この一見奇妙な仕様は、往復のフロー制御を独立に行うために考え出されたとも考えられる。上述したように、RS-232Cの規格では、モデムに対して送信する場合、まずRTSをONにして、CTSがONに変わることを確認することが求められている。従って、CTSがONでないとデータを送信できない仕様の機器が多い。この状況を前提とすると、データを受信できない時には相手機のCTSとクロスしている信号線をOFFにすれば、フロー制御が実現できる。
　ここで素直にCTSとRTSをクロスさせると、 RTSが本来の意味である「送信しようとする意思」と相手機のCTSとクロスすることから生ずる「受信できるという意思」を同時に表明することになり、送受信で独立にフロー制御はできない。
　CTSをDTRとクロスさせれば、「送信しようとする意思」をRTSで、「受信できるという意思」をDTRで、各々独立に表明できる。ただ、この方式に従って作った機器をモデムに接続すれば、「受信できない時は回線を切ってしまう」という強引な動作になってしまうという問題が生ずるが、消去法的に他の選択肢が無い以上、已むを得ないとも言える。
　この場合、相手機の「送信しようとする意思」を知る手段、即ちRTSとクロスさせる信号はDSRでもCDでも良いことになる。実際問題としては、例えばDSRを無結線として RTSをCDとクロスしている製品がある。これは、回線状態の直接の指標であるCDを、最も簡便な通信可能性指標として用いている機器が多い現実に合わせたものであろう。しかし、CDをCTSと共にDTRにクロスさせている製品もある。「CDで状態検知、DTRで状態制御」という最も安直な方法が多く採用されている現実に合わせたものであろうか？
　いずれにしても、消去法的に決められた規格だとすれば、どの現実性を優先するかという立場によって結果が異なることになり、混乱が生ずるのは当然の話であろう。

RTSの意味を巡って

　以上の考察では、RS-232Cの本来の規格を前提として議論を進めてきた。ところが、現実に普通に見かけるモデムの動作を観察してみると、「RTSがOFFになった場合にCTSをOFFにする」という規格を無視して、生きている限り常時CTSをONにしているものが多いようである。このことについて、少し考えてみよう。
　通信という動作について、よくよく考えてみると、「送信しようとする意思」を表明する必然性は無いことがわかる。つまり「相手はいつでもデータを送信したがっている」と考え、自分が忙殺されていて手が回らない場合を除いて常に受信可能にしておくように設計しても、全く実害は無い。CTS/RTSに関して言えば、モデムは端末からのRTSを見てから慌てて(?)受信準備するのではなく、いつでも受信準備ができている状態にしておくわけである。結局、RTSの規格上の機能は冗長で、無くても良いことになる。それならば他の目的に転用できないかと考えるのは自然な発想であろう。
　信号線５本の規格上の意味を見てみると、モデム側が端末側から受信可能かどうかを通知する信号線はあっても、端末側がモデム側から受信可能かどうかを通知する信号線は無いということがわかる。これは、本来モデムは「単なる信号変換器に過ぎない」ものであり、フロー制御などは両側の端末の間で（XON/XOFFなどの方法により）行うべきことだという発想に基づくものだろう。
　しかし、モデムが高機能化し、モデム内部にデータを溜め込んで圧縮したりエラー訂正したりできるようになってくると、モデム自身が端末の都合に「配慮」して端末へのデータ送信を待ったりする必要が生じてくる。この制御の目的にRTSを転用してしまえ、即ちRTSの意味を「端末側が受信できるという意思」に変えてしまえという発想が出てきたのではなかろうか？
　しかも、RTSの意味をこのように変えることは、クロス結線を行う上でも好都合である。先述したように、RTSの本来の意味を残したままでは、 CTS/RTSのペアだけで「送受信で独立なフロー制御」は実現できない。しかし、RTSの本来の意味を放棄してしまえば、単純にCTSとクロスさせるだけで、 RTSは「受信できるという意思を相手に伝える」信号、 CTSは「相手に送信しても良いという相手側の意思を知る」信号ということになり、「独立なフロー制御」が実現できる。
　なおかつ、ストレートでモデムと通信する場合でもクロスで端末同志で通信する場合でも、端末は「自分が受信可能な時にRTSをONにし」「送信時にはCTSがONであることを確認する」という共通の動作で対処できることになり、その意味でも好都合である。
　このようにRTSの意味を変えてしまうためには、 CTSが「RTSに反応して動作する」ことを放棄し、単に「受信可能状態にあることを静的に示す」だけの信号線になることが必須である。
　RS-232Cの信号線の名前は、基本的に端末の立場あるいは端末とモデムを合わせた局全体の立場に立って命名されている。即ち、RTS＝Request to Sendとは、端末が「データを送信(send)したいから、準備をするように要求(request)する」という意味の命名である。しかし、現実的には「（モデムが）データを送信してくるよう要求する」意味に使われる結果になっている。即ち「send」の主語が端末からモデムにスリ替わってしまったわけだ。

2	SD（Send Data）	送信データ
3	RD（Receive Data）	受信データ
4	RTS（Request to Send）	モデムに対する送信要求	（別名RS）
5	CTS（Clear to Send）	モデムからの送信許諾	（別名CS）
20	DTR（Data Terminal Ready）	端末が回線接続して通信可能	（別名ER）
6	DSR（Data Set Ready）	回線が接続されて通信可能	（別名DR）
8	CD（Carrier Detect）	回線にキャリア音検出
7	SG（Signal Ground）	信号接地
1	FG（Frame Ground）	保安用接地