本連載の第1回で、制御伝送化について取り上げた。これまで、個別の機器・機能ごとに別々の配線を通していたものを、編成全体を貫通するデータバスを通じてデータや指令をやりとりする方法に変えることで、配線の節約とシンプル化・軽量化が実現する仕組みのことだ。また、同じデータバスにつながっていれば、機器同士を連接・連携させるのも容易になるだろう。

ただ、そこでは考えなければならない話がいろいろ出てくる。鉄道以外の分野で、ハード/ソフトのアーキテクチャを設計する場面にも関係する話かもしれない。

鉄道車両に固有の事情

他のヴィークルと比較したときの鉄道車両の特徴は、「複数のハコを連結していること」である。自動車でも飛行機でも艦船でも、IT化によって内部にネットワークを張り巡らせるようになったのは同じだが、複数のハコを連結しているのは鉄道車両ぐらいだ。

すると何が問題になるか。それは、連結が切れて車両が分離したときのことを考えなければならないという点である。これが真っ先に問題になったのはブレーキの分野だ。ちょっと脱線するが、御存知ない方もいらっしゃるかも知れないので、簡単に解説しよう。

鉄道車両のブレーキは、圧縮空気で作動させるのが一般的だ。空気圧縮機で作った圧縮空気を「空気ダメ」に貯めておいて、それを放出することでブレーキを作動させる。単純に考えれば、ブレーキをかけたら圧縮空気を放出してブレーキを作動させればよいのだが、それだと編成が切れたときに空気管も切れてしまうので、ブレーキが効かなくなる。

そこで登場したのが、自動空気ブレーキ。普段は編成を貫通するブレーキ管に圧縮空気を送っておいて、ブレーキをかけると、その圧縮空気を抜く。すると、各車に設置した「三動弁」が作動してブレーキを作動させる仕組みだ。自動空気ブレーキのキモは、編成が切れるとブレーキ管の圧縮空気が抜けるので、そのときにもブレーキがかかる点にある。

ただし、ブレーキを作動させるには空気の供給元が要るので、各車に補助空気ダメを備えて、それを三動弁とつないである。補助空気ダメに貯める圧縮空気は、普段からブレーキ管から供給しておく。それを、制動時に放出するわけだ。

安全側に作用することが大前提

前置きが長くなったが、大事なのは「編成が切れたときには安全側に作用する」ということである。そして、ブレーキ以外の分野でもこの原則を適用するべきである、という話になる。

だから、制御伝送化でも何でも、編成が切れたときには必ず安全側に作動するような設計にしておく必要がある。ソフトウェア制御であれば、制御伝送に使用するデータバスの通信が途絶した場合に安全側に作用するように、ソフトウェアを設計しておく必要があるのではなかろうか。

また、そのデータバスそのものも、障害発生に備えて冗長化しておく方が望ましい。JR東日本と三菱電機が開発したTIMS(Train Information Management System)の場合、ラダー型のネットワークを構成している。編成全体を貫通する伝送路が1本ではなく2本あるので、これをリンク・アグリゲーションとみなして伝送速度向上に使えるし、片方が断線などの事情で通信途絶しても、他方の伝送路で機能を維持できるだろう。

なにしろ、制御伝送化によってさまざまな機能を集約するとともに編成全体で統括制御しているわけだから、それが使えなくなったときのダメージも大きい。データバスの冗長化にしても、自律分散型のアーキテクチャにしても、「機能喪失を防ぐ」「安全側に働く」という原則に則ったものといえる。

車両内だけでなく地上側でも、似たような話はある。例えば、東北新幹線が開業した際の資料を見ると、地上側の通信網は有線の通信網とマイクロ波通信網があり、これらを沿線に平行設置する形になっている。有線の回線が本務で、マイクロ波の回線がバックアップだ。

ずっと地上を這っている有線の通信網に比べると、空間を通じて伝搬するマイクロ波通信網の方が、地震などの自然災害に対する抗堪性が高いと考えられる。また、地上だけで冗長化、あるいはマイクロ波だけで冗長化するよりも、異なる方式を組み合わせて冗長化する方が、トータルで見た抗堪性が高くなるのではないだろうか。

ただし、マイクロ波は直進性が高いから、マイクロ波通信網を設置する場所の選択では、地形に影響される点に留意しなければならないが。

拡張性や保守性も大事

もちろん、冗長性も安全性も抗堪性も大事だが、長く使っている間に機能の追加・機材の追加・能力向上を図る可能性も考慮する必要がある。すると、インタフェースの電気的な仕様に始まり、そこで指令やデータをやりとりするためのプロトコルなど、さまざまな面で「将来の拡張性」を考慮しなければならないはず。

また、独自仕様のハードウェアやプロトコルを使えば、それだけハード/ソフトの開発に時間と費用がかかる上に、将来の維持・保守・アップデートが難しくなる可能性もある。使えるところは汎用品・既製品で済ませる工夫も要るのではないだろうか。

実際、JR東日本で開発を進めている次世代車両制御システム・INTEROS(INtegrated Train control / communication networks for Evolvable Railway Operation System)では、物理層とデータリンク層について100BASE-TXイーサネットを採用、TCP/IPと組み合わせた。

さらに、その上位(セッション層より上)で使用するプロトコルについては、鉄道事業者とメーカーが共同で規定することとしている(TIMSではネットワーク層より上について、主としてメーカーが主導する形で規定していた)。

もちろん、屋内で使用するのが普通のイーサネット機器を、もっと運用環境が厳しい鉄道車両で使用することになるので、損失や減衰などといった問題に対処するため、伝送路の物理的な構成や設計に配慮しなければならない。特に電気車はさまざまな電気系統が入り乱れているから、電気的干渉の問題が考えられそうだ。車両間の接続に使用するコネクタだって、風雨にさらされるのだから、まさか「より対線とRJ45コネクタ」というわけには行くまい。

ちなみにINTEROSのネットワーク構成は「制御系」と「状態監視系」に分離しており、前者は二重系、後者は一重系とのことである。

執筆者紹介

井上孝司

IT分野から鉄道・航空といった各種交通機関や軍事分野に進出して著述活動を展開中のテクニカルライター。マイクロソフト株式会社を経て1999年春に独立。「戦うコンピュータ2011」(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて「軍事研究」「丸」「Jwings」「エアワールド」「新幹線EX」などに寄稿しているほか、最新刊「現代ミリタリー・ロジスティクス入門」(潮書房光人社)がある。