黒鉄好＠安全問題研究会です。
さて、昨年末、帰省客らを混乱に陥れたＪＲ東日本の新幹線システム障害について、IT情報専門サイト「ITpro」（日経コンピュータ）が詳しい内容を伝えています。
このサイトは、IT技術者などの専門家向けですが、今回の件に関しては、技術的にそれほど難しいことは書かれておらず、皆さんが読んでも十分理解できる内容だと思いますので、全文掲載の上、ブログに発表した私のコメントと併せてお知らせします。
------------------------------------------------------------------
http://itpro.nikkeibp.co.jp/article/NEWS/20090105/322199/（日経コンピュータ）より
JR東が新幹線システム障害の原因発表、前日のダイヤ乱れで修正が限界超え
JR東日本は2009年1月5日、昨年末に東北・上越・山形、秋田の全新幹線がシステム障害で運行できない状態となったトラブルについて原因を発表した。それによると、運行システム内のデータの日付が不正な値になり、その修正に時間がかかったという。
トラブルは新幹線の車両やダイヤ、乗務員割り当てなどの運行全般を管理する情報システム、COSMOS（COmputerized Safety Maintenance and Operation systems of Shinkansen）で発生した。昨年12月29日の早朝にシステムを操作したが、始発の営業運行に向け列車が割り付けられなかった。
引き金となったのは、前日28日の長野新幹線の車両故障や山形・秋田新幹線の強風や雪害。その影響ですべての列車の運行が終了したのが29日の午前1時33分だった。その後29日の臨時を含めて389本の列車が運行できるよう、車両を留置する場所などのデータを変更。作業は午前5時45分まで長引いた。
COSMOSでは午前5時までに運行データを修正し、その日の営業に利用する仕様となっている。しかし当時は午前5時以降に日付を切り替えたため、作成した運行データが1営業日後の30日のものになってしまった。つまりCOSMOS上に29日の運行データが存在しないため、トラブルが発生した。最終的に運行データの日付を修正した後の午前8時55分、東京駅から始発電車が出発することとなった。最終的に運休や遅延で13万7700人の乗客に影響が出た。
JR東はダイヤの混乱が深夜に及ぶ場合、運行データを変更する量を制限したり、人員など体制を強化するとしている。
------------------------------------------------------------------
年末の新幹線のシステム障害について、日経コンピューターのサイトに詳報が出ている。さすがはIT系サイトだけのことはある。
COSMOSが導入されたのは１９９５年だったと記憶している。当時、長野新幹線はまだ開業していなかったから、COSMOS導入後に一気に列車本数が増えることになったわけだ。とはいえ、２年後に長野新幹線が開業することは初めからわかっていたはずだから、それを織り込んでシステムを構築しているはずであり、列車本数の激増がトラブルの原因とは考えにくい。
ATC自体はCOSMOSとは全く別のシステムで制御されているから、COSMOSのトラブルが直ちに事故につながることは考えにくいが、この状態で列車だけ走らせたとしても、表示と違う列車が到着したり、停車位置が予定と全く違っていたりするわけだから、各駅は大混乱に陥っただろう。
変更データ入力の締め切りを午前５時に設定しているのは妥当だと思う。COSMOSの変更データ入力を午前６時以降も認めるとしたら、始発列車が発車後、現に走行中の列車のデータが書き換えられることになり、大混乱が起こることは容易に想像できる。一方、午前４時以前に締め切った場合、今回のような大規模な運用変更に対応できず、入力が時間切れになってしまうおそれがある。
変更データの入力期限を、始発列車の車両が基地から駅に向けて動き出す午前５時半以降でもなく、無駄な余裕時間が生まれるだけでメリットのない午前４時以前でもなく、午前５時としているのは早からず遅からずの絶妙な時間設定だと思う。この設定自体は今後も変更されないだろう。
むしろ、今回の混乱の原因は、余裕を持った態勢を構築できず、東京に１カ所しかないCOSMOSセンターでＪＲ東日本管内の５新幹線のデータを一斉に入力しようとしたことに原因がある。その上、別の報道によれば、自社のシステムでありながら、その変更データの入力期限が午前５時であることをＪＲ東日本は全く知らなかったという。下請け企業にアウトソーシングした事業に関しては知ろうともしない、このような官僚的企業体質もトラブルの根底にある。
別のサイトの記事によれば、お手上げとなったＪＲ東日本は、COSMOS保守業者の担当者を呼び出し、システムの入ったコンピューターの時計を午前５時前の時刻まで巻き戻してデータ入力をしたところ、復旧したという。なるほど、その手があったかと感心したが、一方で今回このような手が使えたのは、COSMOSが制御しているＪＲ東日本管内の５新幹線が全面ストップしていたからである。一部でも正常運行している新幹線があれば、走行中の列車のデータが突然過去に戻ってしまうため、この手は使えないわけで、「一部正常運行、一部不通」という状態で、今回のような事態が起き、時計も巻き戻せないという状況になったらどうするつもりなのだろうか。おそらく、データ入力が間に合わなかった新幹線は終日運休とならざるを得ないだろう。
ＪＲ東日本が、今後、大規模なダイヤ混乱の場合に「運行データを変更する量を制限したり、人員など体制を強化する」としていることは結構なことである。しかし、今後、東北新幹線は新青森まで延び、やがて北海道新幹線と一体となって函館まで到達する。列車本数はさらに増えることになるわけだ。単純比較はできないが、東京・大阪の２カ所に運行システムを設け、ＪＲ東海・西日本と運行会社も異なる中で、国鉄時代からの協力態勢を維持し、分担してデータ変更作業を行っている東海道・山陽新幹線のようにしてほしいと思っている。
-----------------------------------------------------
黒鉄 好 aichi200410@yahoo.co.jp
JR株主・市民の会、安全問題研究会合同ブログ
http://blog.goo.ne.jp/kabunusi_osaka
Created by zad25714. Last modified on 2009-01-13 00:14:25 Copyright: Default
さて、昨年末、帰省客らを混乱に陥れたＪＲ東日本の新幹線システム障害について、IT情報専門サイト「ITpro」（日経コンピュータ）が詳しい内容を伝えています。
このサイトは、IT技術者などの専門家向けですが、今回の件に関しては、技術的にそれほど難しいことは書かれておらず、皆さんが読んでも十分理解できる内容だと思いますので、全文掲載の上、ブログに発表した私のコメントと併せてお知らせします。
------------------------------------------------------------------
http://itpro.nikkeibp.co.jp/article/NEWS/20090105/322199/（日経コンピュータ）より
JR東が新幹線システム障害の原因発表、前日のダイヤ乱れで修正が限界超え
JR東日本は2009年1月5日、昨年末に東北・上越・山形、秋田の全新幹線がシステム障害で運行できない状態となったトラブルについて原因を発表した。それによると、運行システム内のデータの日付が不正な値になり、その修正に時間がかかったという。
トラブルは新幹線の車両やダイヤ、乗務員割り当てなどの運行全般を管理する情報システム、COSMOS（COmputerized Safety Maintenance and Operation systems of Shinkansen）で発生した。昨年12月29日の早朝にシステムを操作したが、始発の営業運行に向け列車が割り付けられなかった。
引き金となったのは、前日28日の長野新幹線の車両故障や山形・秋田新幹線の強風や雪害。その影響ですべての列車の運行が終了したのが29日の午前1時33分だった。その後29日の臨時を含めて389本の列車が運行できるよう、車両を留置する場所などのデータを変更。作業は午前5時45分まで長引いた。
COSMOSでは午前5時までに運行データを修正し、その日の営業に利用する仕様となっている。しかし当時は午前5時以降に日付を切り替えたため、作成した運行データが1営業日後の30日のものになってしまった。つまりCOSMOS上に29日の運行データが存在しないため、トラブルが発生した。最終的に運行データの日付を修正した後の午前8時55分、東京駅から始発電車が出発することとなった。最終的に運休や遅延で13万7700人の乗客に影響が出た。
JR東はダイヤの混乱が深夜に及ぶ場合、運行データを変更する量を制限したり、人員など体制を強化するとしている。
------------------------------------------------------------------
年末の新幹線のシステム障害について、日経コンピューターのサイトに詳報が出ている。さすがはIT系サイトだけのことはある。
COSMOSが導入されたのは１９９５年だったと記憶している。当時、長野新幹線はまだ開業していなかったから、COSMOS導入後に一気に列車本数が増えることになったわけだ。とはいえ、２年後に長野新幹線が開業することは初めからわかっていたはずだから、それを織り込んでシステムを構築しているはずであり、列車本数の激増がトラブルの原因とは考えにくい。
ATC自体はCOSMOSとは全く別のシステムで制御されているから、COSMOSのトラブルが直ちに事故につながることは考えにくいが、この状態で列車だけ走らせたとしても、表示と違う列車が到着したり、停車位置が予定と全く違っていたりするわけだから、各駅は大混乱に陥っただろう。
変更データ入力の締め切りを午前５時に設定しているのは妥当だと思う。COSMOSの変更データ入力を午前６時以降も認めるとしたら、始発列車が発車後、現に走行中の列車のデータが書き換えられることになり、大混乱が起こることは容易に想像できる。一方、午前４時以前に締め切った場合、今回のような大規模な運用変更に対応できず、入力が時間切れになってしまうおそれがある。
変更データの入力期限を、始発列車の車両が基地から駅に向けて動き出す午前５時半以降でもなく、無駄な余裕時間が生まれるだけでメリットのない午前４時以前でもなく、午前５時としているのは早からず遅からずの絶妙な時間設定だと思う。この設定自体は今後も変更されないだろう。
むしろ、今回の混乱の原因は、余裕を持った態勢を構築できず、東京に１カ所しかないCOSMOSセンターでＪＲ東日本管内の５新幹線のデータを一斉に入力しようとしたことに原因がある。その上、別の報道によれば、自社のシステムでありながら、その変更データの入力期限が午前５時であることをＪＲ東日本は全く知らなかったという。下請け企業にアウトソーシングした事業に関しては知ろうともしない、このような官僚的企業体質もトラブルの根底にある。
別のサイトの記事によれば、お手上げとなったＪＲ東日本は、COSMOS保守業者の担当者を呼び出し、システムの入ったコンピューターの時計を午前５時前の時刻まで巻き戻してデータ入力をしたところ、復旧したという。なるほど、その手があったかと感心したが、一方で今回このような手が使えたのは、COSMOSが制御しているＪＲ東日本管内の５新幹線が全面ストップしていたからである。一部でも正常運行している新幹線があれば、走行中の列車のデータが突然過去に戻ってしまうため、この手は使えないわけで、「一部正常運行、一部不通」という状態で、今回のような事態が起き、時計も巻き戻せないという状況になったらどうするつもりなのだろうか。おそらく、データ入力が間に合わなかった新幹線は終日運休とならざるを得ないだろう。
ＪＲ東日本が、今後、大規模なダイヤ混乱の場合に「運行データを変更する量を制限したり、人員など体制を強化する」としていることは結構なことである。しかし、今後、東北新幹線は新青森まで延び、やがて北海道新幹線と一体となって函館まで到達する。列車本数はさらに増えることになるわけだ。単純比較はできないが、東京・大阪の２カ所に運行システムを設け、ＪＲ東海・西日本と運行会社も異なる中で、国鉄時代からの協力態勢を維持し、分担してデータ変更作業を行っている東海道・山陽新幹線のようにしてほしいと思っている。
-----------------------------------------------------
黒鉄 好 aichi200410@yahoo.co.jp
JR株主・市民の会、安全問題研究会合同ブログ
http://blog.goo.ne.jp/kabunusi_osaka
Created by zad25714. Last modified on 2009-01-13 00:14:25 Copyright: Default