2020年03月03日

事例:シーサイドラインの逆走事故


初めての方はこちらを「はじめに
全ての記事は「メニュー」にまとまっています

この事故は、丁度「事例:ボーイング737MAXの墜落事故」の記事の頃の事で、同じ「自動」に関する事故として、当時から注目していました。今回、詳細な調査結果が発表されたようなので、事例:ボーイング737MAXの墜落事故と同様に「「自動」は簡単ではない」に関する事例として取り上げてみたいと思います。
※事例はその事自身を考察するものではなく、具体的な例を通して今までの記事の内容の理解の助けとするものです。

事故の内容


事故の内容は以下のようなものでした。
無人運転の列車が始発駅で逆走して車止めに衝突したというものですね。
横浜シーサイドラインという会社が運行する金沢シーサイドラインという路線です。
この時はたまたま始発駅だから車止めにぶつかったわけですが、普通の駅だったら、どうなったのでしょうか。
制御されないまま反対方向に走って行ってしまったのでしょうか。
考えただけでも恐ろしいですね。

事故の原因


事故の原因としては、以下のように早い段階からシステムの欠陥が指摘されています。

そして、今回の調査結果は以下のように、ほぼ上で指摘された通りの内容のようです。
設計の問題に加えて、保守も難しい状態になっていたようです。

なぜ緊急停止しなかったのか


事故が起きた時に、私がシステムとして最も気になった点は「なぜ緊急停止しなかったのか」という事です。
鉄道の事は全く詳しくないですが、仕組みとしては普通の列車でも自動で止まる装置が備わっているものだと思っていたので、このように無人で自動運転するものなら、その辺は万全だろうと思っていました。
ですから、逆走は何かしらの障害で発生したとしても、最悪でも緊急停止はするはずだと思っていたのです。
車止めに衝突したという結果からすれば、そういうものは作動していないようなので、自分がイメージする「自動」のシステムと根本的に設計思想が違いそうな気がして、非常に気になりました。

その部分については、上のニュースでは以下のように書かれています。
逆走を検知し非常ブレーキをかけるシステムも作動しなかった

これだと良く分からないので、大本と思われる、以下の運輸安全委員会の報告書を読むと、そもそも「そういう仕様ではない」ようです。該当部分と思われるところを引用します。
経過報告

ATC車上装置の装置メーカーによると、本件車両の後退検知機能は、
車両が上り勾配で停止し緩やかに後退した場合などを想定しており、
進行方向等の情報が正しくATC車上装置に入力されることを前提としているため、
進行方向が不明な状態では動作しないとのことであった。
上りで後ずさりしてしまった場合の検知機能という事のようですね。つまり、そもそも逆走に対する検知機能というものは最初から無いようです。

調査報告書を全て読むのは素人にはさすがに厳しいですが、以下は説明用としてまとまっていて、素人でも幾分かは分かりやすいです。
この資料によると、車両の設計は
2000型車両の設計において、制御回路などは過去に大きな不具合が 発生していなかった1000型車両や普通鉄道車両を参考にした。
ということのようです。
1000型車両というのは前のバージョンで、やはり無人走行の車両です。(参考:横浜新都市交通1000形電車)1000型車両の時から逆走の検知が考慮されていなかったのかどうかは分かりません。説明資料にはこんな記述もあります。
一部の搭載機器については変更を行った。その際に、新たな機器には普通鉄道車両や他の新交通システムなどで実績のある機器を採用した。
つまり1000型車両から、設計思想が伝わらずに、表面的な変更をしてしまって、問題を作りこんでしまったのかもしれません。「事例:ボーイング737MAXの墜落事故」の中でも、全く同様の作りこみ原因に触れました。
我々の業界でも良く経験する問題ですね。
ソースや仕様を引き継いだ人が、「これはこうしちゃえばいいんじゃないの?」と表面的に見える事だけで安易に修正してしまい、後で大問題になるというパターンです。他人のコードをいじらなければならなくなった時に「この処理いらないんじゃない?」と思って削って、問題を誘発したことはありませんか?
考え方とか思想みたいなものは伝えるのは難しいので、中々厄介な問題です。

対応策にみる「自動」


さて、先程の説明資料の最後には「再発防止策」についてもまとまっています。以下は緊急停止部分に関して、実際に取られた対応の内容です。
(3) ATC車上装置の後退検知機能について、進行方向の指令線であるF 線及びR線が断線等により、ともに無加圧となった状態で車両の走行を 検知したとき、非常ブレーキが動作するようにソフトウェアを変更した。
素人なので、良く分からないのですが、資料の途中にシステム全体の簡単なブロック図があって、それと併せてみると、我々の言葉で言うとどうも「アルゴリズムを直しました」と言っているように思えます。

合っているかどうかは別にして、今回調べて自分なりに理解した範疇では、やはり「自動」に対するアプローチが違うような気がします。自分の考えは図で示せば以下のようなイメージです。
53N051_001.jpg

つまり、手動でできる事が基本の機能であって、自動というのはあくまで手動でできる事を代わりにやってくれるに過ぎないという考えです。
自動が無くても機能としては何も問題が無く、あれば「使い勝手が良くなる」だけという位置づけです。一般的にはウィザードは大体こういう構造になっているのではないでしょうか。

手動の方が幅が広い(機能が多い)のもポイントです。
もし自動で手動でできる事が全てできるなら、同じ幅になって、その時は手動は要らないかもしれません。しかし、なかなかそういうパターンはなく、一般的にはこの様な形になると思います。
この場合、自動でカバーしきれない部分は手動のお世話になる事になります。「自動で何かあっても手動でなんとかできる」という安心感の源です。

この考え方の基で、今回の自動運転の構造を表してみると、以下の様になります。
53N051_002.jpg

ただ「無人」ですから、基本の手動の部分を人がやれません。ですから自動部分で全てを賄えるようにしたくなりますが、それだと「自動で何かあっても手動でなんとかできる」という安心感に結びつきません。
ですから、「自動で何かあった場合」に対処する「緊急停止」みたいなものは、手動側に欲しいわけです。

この辺が説明資料を見るとどうも全てが自動側にあるような気がします。今回の事故の内容である、逆走に対する処理が通常の運行システムの「一部」になっているように見えます。
53N051_003.jpg

もちろん、この記事の趣旨は列車のシステムを論じる事では無いので、実際にどうなっているのかは論点ではないですし、そもそも素人に分かる事ではありません。
あくまで例えとして考えるだけなので、例えば、極端な事を言えば、先頭車両と最後尾の車両にセンサーを付けて、物が近づいたら緊急停止を割り込むような独立したシステムを用意できれば、それが「手動側」というイメージです。車両の自動運転のシステムとは別系の独立したシステムという事です。
ちなみに、そういう事は難しいという意味なのか、こちらの記事では「有人」を主張しています。

こういう構造の感覚はフェイルセーフとか不完全性定理のようなものに近い気がします。
一つの系(システム)の中で全てを解決することはできなくて、その系の解決不能な問題を解決する為には、その系の「外側」に解決する手段を持つ必要があるという意味です。全てを想定できると考えるのは危険で、想定をすり抜けて来た障害を抑え込む「最後の砦」を用意するのがより安全な構造と言えます。
自動の場合は手動がそれにあたるという事になります。

関連記事



記事一覧


  • メニュー
    全ての記事が分類整理され、選択的にアクセスするためのトップ
  • 用語集
    ブログ内で使用されている専門用語や独自の用語などを簡単に説明したものです。


記事を広める




posted by 善 at 19:34 | Comment(0) | 事例 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。