JR東における鉄道システムがIT化されてきた歴史と品質向上への取り組み(中編)。ソフトウェア品質シンポジウム 2014

2014年9月30日

鉄道は乗客を安全に運ぶという点で信号や列車の制御システムに非常に高い品質が求められる一方、ダイヤなど旅客情報については大量の情報を処理して乗客に提供しなければならないという複雑なシステムで構築されています。そして現在そのシステムの多くがIT化されています。

鉄道の安全性や正確性、そして快適性などをITがいかに支えてきたのか。9月11日に東洋大学で開催された「ソフトウェア品質シンポジウム 2014」では、JR東日本のIT化や品質向上の取り組みについて東日本旅客鉄道株式会社 松本雅行氏のセッション「鉄道信号システムへのアシュアランス技術の適用」が行われました。本記事ではその内容をダイジェストで紹介します。

本記事は前編中編後編の3つに分かれています。いまお読みの記事は中編です。

鉄道システムの革新

信号によって輸送業務を司っていますが、輸送業務には大きく分けて5つに分類できます。

1つは「輸送計画」。どんな列車をどこに走らせるか。言ってみれば列車ダイヤを最初に作る作業です。それを輸送計画業務といいます。それから作ったダイヤに基づいて列車を実際に運転する。それを「輸送管理」と言います。従いまして、列車が何かの故障で乱れたり遅れたり、そうしたときには、なるべく早く復旧、元に戻す、正しいダイヤの運転に戻す、そういうことをするのもこの輸送管理業務のなかに含まれているわけです。

「進路制御」というのは、先ほど転てつ器を制御してと言いましたが、その駅での、どの番線に列車を通すのか、それを司ります。「列車制御」は実際の列車をどのぐらいのスピードで運転するか、これは運転手が昔は自分でコントロールしていたわけですけど、それを信号に従って列車速度を決めて運転する。これを列車制御といいます。

「信号制御」は、信号機とか転てつ器をどう制御するのか。信号機を赤にするのか青にするのか。あるいは転てつ器で左を開通させるのか右側を開通させるのか。それを制御するのが信号制御です。

実はこれらは、最初は全部人手。人間がやってたんですね。昔、信号制御っていうのは、駅に必ずちょっとタワーみたいな高いところに人がいて、信号扱者っていうんですが、そこに大きなレバーがあって、そのレバーを扱って転てつ器だとか信号機を制御してました。そういう時代があったんです。運転も含めて人間がやってた。これを装置あるいはコンピュータで扱うように革新してきたということをこれからお話していきたいと思います。

まず列車ダイヤですが、「輸送総合システム」とわれわれは名前をつけていますが、コンピュータでダイヤを、自動的にとはいいませんが、人間が色んな条件をいれてあげて、計算やなんかは全部コンピュータが行います。

ダイヤを作るというのは意外と大変でして。何が大変かといいますと、鉄道は線路が何々線、何々線といっぱいあるんですね。それが独立してあればそう大したことないんですけど、ある駅で交差する、あるいはそこで終点の駅である、そうしますと、乗り継ぎの待ち時間があるときは30分だったり、あるときは2時間待ったりというようなダイヤでは、お客様が非常に不便なんですね。そうすると、その乗り継ぎのところの接続を、10分だったら10分ぐらいにするという調整をやるのが非常に大変なわけです。

単線も、列車走らせる分には大体もう、距離と停車駅が決まればそれで半分自動的に決まるんですけど、そこの乗り継ぎのところの接続をどうするか、これが大変で。

昔は管理局っていうのがあったんです。各県ほどではないんですけど、何ヶ所かあって。乗り継ぎを調整する会議を毎年というかダイヤ改正の度にやってたんです。ダイヤ改正の2年ほど前にやって。その会議っていうのは、各局のダイヤを作成する担当者が全員集まって、しかも国鉄時代ですから、全国から何百人という人が集まります。

今ですと、コンベンションセンターのような大きな会議施設もありますが、当時はそういうのがないので、だいたい温泉地のでっかい旅館で分宿してやるわけですね。当時は、これを称して温泉会議と呼んで、1ヶ月くらい泊まり込んで調整するわけです。そういう大変な作業だったんですが、この輸送総合システムを使えば、もちろん人間がこっちを優先にしようとか、そういう条件は入れてやらないといけないんですが、あとは自動的にやってくれると。かなり、楽になりました。これを1992年から使い始めたんです。

fig

また、先ほどの輸送管理と進路制御。これはどういうふうにしたかといいますと、これは先ほど言いましたように、転てつ器とかなんかは駅で扱ってたということで、このマルが1つの駅なんです。ちょっと小さいですけど、先ほど言ったレバーが駅にあって、それを使って転てつ器の向きを、各駅で制御する。そうしますと、人がいっぱい必要なわけです。

CTC、ATOSの登場

これをもっと効率よくやろうじゃないかということで1ヶ所に集めてリモートコントロールするようなものを作ろうということで、CTC、CentralizedTrafficControlという装置が、これはアメリカのほうで開発されました。これを使って、今まで駅にいた人間を中央に集めてそこでリモートコントロールをすると。

fig

昭和40年代、これが相当行われました。

そしてコンピュータが登場してきますと、これを自動的にやろうということで、PRC、ProgrammedRouteControlという装置を開発して、導入しました。これは言ってみれば業務効率化ということで導入しました。今、民鉄も私どもの会社も、ほとんどはこのPRCを使っています。名前は、いろいろ会社によって呼び方は違いますけども。

ところが、実は首都圏というのはお客さんが黙っててもいっぱい来ていただけるんで、あまり効率化しなくてもいい、そういう背景があったので、昔のままだったんです。ですから、私が東京で勤めたのが昭和57年ですので、もう大分前なんですけども、そのときは、電話とホワイトボードで、いま列車はどこにいるか手分けして、それで列車の運行管理をやっていました。

ところがJRになりまして、三井造船にいらっしゃった山下勇さんという方が初代の会長でみえて、首都圏の先ほどのような状況を見て何をやってるんだと。このコンピュータが発達してる時代に、紙とホワイトボードと電話でやっていると。それで開発したのがATOSというシステムです。

ATOSは、旅客サービスや安全性、信頼性の向上、指令業務効率化などを目指しています。これまでは大きな表示盤を置いていたんですが、コンピュータの画面で全部指令ができるようにしようということで、1996年に中央線で使用を開始しています。今、首都圏のほとんどの線区はこのシステムで管理しておりますし、今年の3月には中央線で使用開始してるものの取り換えを行っているということで、一応、1サイクル回って2サイクル目に入ってきています。

fig

これはATOSのシステム構成、中央のシステム、それから線区のシステムと駅。各駅にコンピュータを置きます。先ほど言ったCTCのときの大きな問題っていうのは、大きな駅っていうのは中央のPRCでコントロールできなかったんです。それはなぜかといいますと、駅独特の「構内入れ換え」という作業があって、駅独自のダイヤを持っていたんです。そのダイヤを中央で作成し管理するっていうのは、できなかったんです。

このATOSを作るときにはそれをやめようということで、中央で持っていダイヤを逆に駅に持ってきました。分散システムの構成ですね。駅では、本線のダイヤと駅構内のダイヤをミックスして、それで管理すると。

fig

日々のダイヤは毎日夜中に中央の輸送総合システムから各駅に配信する。駅は4日分のダイヤを持っていて、もしもネットワークが壊れたり、あるいは中央のシステムがダウンしても、少なくともそのダイヤに基づいた運転は駅独自でできるようにすると。そういう、自律分散システムを構築したというのが、大きな特徴であると思っています。

このスライドはATOSを入れた効果を表わしてるグラフです。ATOSを導入した後は、非常に復旧が早くできるようになったということがお分かりになるかと。平均して3時間14分が、2時間34分になっています。

fig

新幹線の司令室COMTRAC

新幹線は今年開業してから50年が経つのですけれど、開業当初からCTCが使われていました。CTCは使ってたんですが、開業当初はいわゆるPRCはなくて、岡山開業の47年に「COMTRAC」というPRCと同じ機能をもったシステムを導入しました。ところが、1号機だったんで、なかなか上手く動かなかったということで、岡山開業から3年後の博多開業にあわせて、新幹線の走行管理システムのスタンダードにしようとCOMTRACフェーズIIというシステムを作ったんです。実は私、国鉄に入ったのが昭和47年ですから、入って直ぐこのシステム作りを担当したんですが、お陰様でCOMTRACフェーズIIというのは非常に上手くいって、その後の新幹線の運行管理システムの基本になっています。

これは、司令室の様子です。先ほどのATOSとは大分様子が違うと思います。大型表示盤があって、制御卓があります。

fig

新幹線の輸送管理システムは、原点がCTC。CTCにダイヤ管理とかこういうものを加えてCOMTRACと。さらに、ATOSと同じように、保守作業管理ですとか車両管理、あるいは電力管理、これらを全部トータルにしたシステムを構築しようということで、COMTRACの取り換えにあわせて、1995年にCOSMOSという名前をつけたシステムに取り換えたんです。これは、先ほどの大型表示盤を止めて、こういうCRT管理端末で表示できるようにしました。

fig

COSMOSはここにありますように、8つのサブシステムからなってまして、システム構成もこのように各サブシステムをネットワークで結ぶ膨大なシステムを構築したわけです。

fig
fig

このATOS・COMTRACの稼働率をプロットしたのがこのグラフです。平均すると、99.99%(フォーナイン)です。ただ、COSMOSはハード故障で相当長く止めたのが2008年にありまして、このときがフォーナインを維持できませんでスリーナインになってしまったんですが。平均すると99.998%ですから、かなり安定して稼働していると思います。

fig

ちなみに私が担当した、博多開業のときのCOMTRACフェーズIIは最初の年が99.7%ですから、いかに安定したシステムになったかというのがお分かりになると思います。

列車制御システム

次に列車制御システムの話です。列車の運転というのは、初めは運転手の注意力に頼っていたわけで、しばしば大事故を起こしてきました。

その大きな事故を列記しますと、1956年に参宮線の六軒駅というところで、列車衝突事故を起こしています。これは赤信号を無視して進んでしまった、運転手が信号を見落として進んでしまったために、本線の列車とぶつかったという。

この事故によって、車内警報装置、赤信号が近づいてくると車内に警報をならすという装置を開発して導入したんです。ところが、皆さんよくご存知だと思うんですけど、1962年に三河島駅で多重衝突、3列車がぶつかってしまうという事故が起きます。160人のお客様が亡くなったという大事故でした。この事故に対する対策として、ただ警報だけ出してたのではだめだと。あわせてブレーキを出して列車を止めるようにしようということで開発したのがATSで、この事故の数年後にATSを国鉄全線に入れて対策をとります。

ところがその後、関西本線であるいは山陽本線で脱線事故が起きます。これは、本線を真っ直ぐ通過する場合には90キロないし100キロで過ぎるんですが、分離機で側線のほうに入っていくときは45キロにスピードを落とさなきゃいけないんですね。ところがこの2つの事故とも、元々は本線を通過する列車だったんですが、工事等の都合でその日は側線のほうに入る、これを運転手が失念して90キロで進んだために分離機のところで脱線してしまったと。しかもこの山陽本線の西明石駅の事故のときには、運転手が飲酒してたということで、非常に社会的にも取り上げられました。

また、JRになってからですけども、東中野で列車追突事故があります。これはATSで、ATSの装置っていうのは赤信号に近づきますとまず警報を出します。5秒間、運転手がブレーキも何もしなければ自動でブレーキがかかります。ところが確認ボタンっていうのがあって、確認ボタンを押しますと、運転手が「分かってるよ、あとは俺が運転する」っていう意味を込めて確認ボタンを押すわけです。ところが首都圏ですと年中列車が近づいているもんですから、しょっちゅう警報音が鳴るので、運転手も慢性的に確認ボタンを押してしまう。

ところがその日に限って東中野駅の前の列車がなかなか出発しなかった。運転手は間もなく出発するだろうと思って、ずっととろとろ行ったら、結局ぶつかってしまったと。これでお客様1名、運転手も亡くなって、2人が亡くなっていると。この対策としてATS-Pという、パターンを発生させて、そのパターンに従ってブレーキをかけるようにするというシステムを開発しました。

ATC

一方新幹線は、ATCというのを開業のときから入れております。このATCというのは速度信号を出していて、速度信号より大きな、オーバーする速度で走っていた場合、その区間でスピードを下げてという、こういう段階的にスピードを下げるようなこういう運転速度の制御をします。

fig

ところがこのATCにも問題がありまして、階段状の速度制御で、列車の間隔が決まってるもんですから列車間隔を詰められないと。速度が変化するところで突然ブレーキがかかるので乗り心地が悪い。また、地上の設備がいっぱいあってかなり高いシステムになります。

JR東では、山手・京浜東北などでATCを国鉄時代に導入してたんですが、その老朽時期になって、どういうシステムを導入しようかということで、ここにありますように、前の列車の位置をレールを介して後続列車に教える。後続の列車は車両にメータを積んでおりまして、ブレーキパターンを発生させて、あとはこのブレーキパターンで制御するという方式を開発しました。デジタルATCです。

fig

一方、JRになってから、本来の列車制御ってどうあるべきかていう勉強会をやったときに、海外でもあったんですが、無線を使ってそれぞれの列車が車輪がどれくらい回ったかで位置を計算しておきまして、その位置を無線を介して後続の列車に教える。後続の列車は前の列車の手前に止まればいいということで、そのための速度制御パターンというのを発生させて、それで制御していくと。

先ほどのデジタルATCはこの軌道回路にこの情報を流すんですけど、これは無線で流している。こういう無線を使ったシステム、これを私どもはATACSと呼んで、ずっと開発しているんです。実は3年前の10月10日に仙石線で使用を開始しました。仙石線で使用を開始したというのは試験を首都圏から外れたところでまずやってみようということで仙石線を選びました。2017年目標に埼京線にこのシステムを導入しようということで、今、工事をやっているところです。

fig

ここまでの話は信号制御システムあるいは運行管理システムとあわせた列車制御システムについてでした。こうしたもののおかげで、私どもの一本あたりの列車の遅れ時分は、在来線の場合ですと大体平均1分前後、新幹線の場合ですと、30秒ちょっとに抑えることができています。

fig

海外でこういう話をすると、台風とかそういうときのデータは入れてないんだろうと言われるんですが、実は全てのデータを入れたうえで、この遅れ時分になっています。やはり日本の運転オペレーションの品質というのは相当高い、おそらく世界で一番だと思います。これも技術の進化にともなって、システムを進化させてきたということです。

≫次の後編では、IPネットワークによる情報制御とアシュアランス技術について紹介します。

ソフトウェア品質シンポジウム 2014

ソフトウェア品質シンポジウム 2013

ソフトウェア品質シンポジウム 2012

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : ソフトウェアテスト



≫次の記事
JR東における鉄道システムがIT化されてきた歴史と品質向上への取り組み(後編)。ソフトウェア品質シンポジウム 2014
≪前の記事
JR東における鉄道システムがIT化されてきた歴史と品質向上への取り組み(前編)。ソフトウェア品質シンポジウム 2014

カテゴリ



Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



新着記事 10本


PR - Books


fig

fig

fig