列車ダイヤについて -- 3-5 相互直通運転の話
2018年3月17日
3-5 相互直通運転の話
電車を利用していると、何かの原因で電車が止まって相互直通運転をやめるというのが、どうしても気になります。
どうしても細かなことだけが気になって、（肝心なことが気にならないのが）ボクの悪いクセですが、
そうでなくても、すぐに相互直通運転をやめて、それでも電車が折り返しできないからさらに遅れるというのは、
気になる人が多いのではないでしょうか。
3-2 電車とビットコイン？？ でもブロックチェーンの技術が、相互直通運転の列車の運転状況の把握に利用できる
のではないかと述べました。
ここでは、列車のダイヤの作成・管理などに使われる、RDB（関係データベース）を使って、相互直通運転を
もっと上手に管理できないのかという話です。
RDBは、ひとつのデーターベースのなかでデータ完全性を維持し、データーの不整合を発生させない能力に非常にすぐれており、
銀行の勘定系のシステムなどでも用いられています。しかし、他のデーターベースと連携することは不得手です。
他のデーターベースと連携することは不得手ということは、いろいろな場合に問題になります。
例えば、連結財務諸表を作る場合です。
多くの会社で、会計処理にERP（Enterprise Resources Planning、基幹系情報システム）を使用しています。
多くのERPが、RDBを使ってデーターを保存しています。
材料の購入から貯蔵、材料を使っての製品の制作などの過程で、材料の量の管理とそれにともなう会計情報を関連づけて
管理するなどは非常に得意です。
しかし、独立したERPのデーターを必要に応じて連携するということは不得手です。
個別の財務諸表がそれぞれ異なるERPで管理されているとして、それをもとに連結財務諸表を作成したとします。
その後、個別財務諸表の一部を変更しても、連動して連結財務諸表が修正されるということはありません。
もちろん、連結の企業集団すべてをひとつのERPで管理すればいつでもただちに連結財務諸表を作成できますが、
初期導入時の構成が大変ですし、新しく小会社を連結するという時の構成の変更も大変です。
ここから鉄道の話に戻りますが、
相互直通運転をしているそれぞれの会社が、それぞれのRDBを使ってデーターを保存しています。
何かの運転障害が起きたので、ダイヤを変更するとします。その連絡を受けた他の会社もダイヤを変更します。
ところが、運転障害が起きた直後ですから、変更したダイヤをさらに変更することもあります。
その時、他の会社のダイヤも連動して修正されれば良いのですが、そう都合良くはいきません。
関東に京浜急行電鉄という会社があります。
この会社はシステムを使わず、人間が運行管理をしていることで有名です。
そして「いっとこダイヤ」というのも有名です。都営地下鉄内で運転障害が起きて、ダイヤが変更された時、
やって来る列車をとりあえず止めずにそのまま走らせて、走っているうちにどのように事態を収束するかを考え実施する
というような意味です。
やって来る列車をとりあえず止めずにそのまま走らせるといっても、素人がただそのまま走らせていればいいというものでは
ありません。必ずどこかで行き詰まります。
京急線での運行管理の経験豊富な人たちが行っているので、無事事態を収束できるのだと思います。
秋田新幹線は盛岡〜秋田間では、普通電車も走っています。
もしこの区間で運転障害が起きた場合、まず東北新幹線の運行管理をおこなっている、
cosmos(Computerized Safety, Maintenance and Operation Systems of Shinkansen）の大宮センターで
新幹線のダイヤを変更します。それが完了した後、秋田支社の運行管理センターで、普通電車のダイヤを変更すると聞いたことがあります。
「いっとこダイヤ」だったら、普通電車もとりあえず走らせておいて、そのうちにダイヤを変更することができるかもしれませんが、
現実にはできないようです。（秋田新幹線を利用する機会はあまりないので、それほど正確ではないかもしれません。）
連結の企業集団すべてをひとつのERPで管理するように、相互直通運転をするすべての会社の列車を管理するような
RDBがあれば良いのですが、ERPと同じで最初の構成が大変で、しかも日常使っている時はかえって不便なこともあります。
ERPで、ある子会社の仕訳を間違えて別の子会社の仕訳として記帳した、ということはあってはならないことです。
しかし、まだ後で修正して事なきを得ることもあります。
鉄道の場合、つねにリアルタイムで実際の列車が走ってますから、このようなことがあると一大事です。
それではどうすれば良いかですが、個別のRDBで会社ごとにダイヤを管理していて、
それと平行して、関連するすべての会社のダイヤを別のRDBに記録するというような方法が考えられます。
実現可能性があるかどうかは知りませんが、もし実現できるとすれば一番可能性があるのが
JR東日本ではないかと思います。
JR東日本では、東京圏のダイヤをATOS（Autonomous decentralized Transport Operation control System）
というシステムで管理しており、ダイヤの管理は東京総合指令室にあるコンピューターで行われています。
ただし、あまりに管理する範囲が広いので、東海道線方面とか宇都宮線方面というようにいくつかのシステムを使って
個別に管理しています。例えば山手線で一本の電車が1分遅れたために、その前の電車を30秒待たせる時に、東京圏全体の
運行状況をすべて把握して行っても何のメリットもありません。
ところが、上野東京ラインとか湘南新宿ラインのような、何かあるとすぐ直通運転を中止するような線区の運行管理には
全体を管理するデーターベースがあると容易になります。
ひとつのデーターベースのなかでデータ完全性を維持するのがRDBの重要な機能なので、いくつかのRDBにアプリケーションで
管理してデーターを記録するというのは本末転倒した話で、具体的にどうすれば良いかはよくわかりません。
しかし、もし個別の管理と並行して全体の管理をするようなシステムが実現できるとすれば、
同じ場所で同じ会社の人が管理している、JR東日本の東京総合指令室が一番実現可能性が高いのではないかと思います。
京急線の例のように人間が運行管理をすれば、融通がきくので個別の管理と並行して全体の管理をすることが可能なのかも
しれません。
相互直通運転の問題は、アメリカのアムトラックのように、貨物鉄道会社が管理する線路を旅客列車が走る場合や、
ヨーロッパのように上下分離が進み、かついくつかの運行会社が同じ線路上を運行する場合にも、問題になります。
日本で日本人がやれば出来るでは、海外進出できないので、
個別の管理と並行して全体の管理をするようなシステムが実現できれば良いと思います。