Lambdaカクテル

ウェブアプリケーションエンジニアです.玉石混淆です.

電車プログラミング:列車とプログラミングの意外な共通点

先日数時間電車に乗る機会があった。地方民としては電車に乗ることはあまり頻繁なことではない。まあ僕の住んでいる地域では気動車しか走れない非電化区間なのだが。

さて、電車の中から外を見ていると、なんとなく鉄道標識が目に留まる。システム好きなのでしばらく調べてしまった。すると、意外とプログラミングとの共通点があるというか、互いに取り入れられそうな考え方が幾つかあってなんか得した気持ちになった。その備忘録としてこの記事を書く。

僕はそんなに鉄道に詳しくないから、大雑把な記述がなされていたりするかもしれない。間違っていたら修正する。

安全性

最近メニーコアとかビッグデータとかで並列性とか並行性が取り沙汰され持て囃されているが、そこで肝心なのがデータや処理の安全性だ。この手に強いのが関数型言語で、データをイミュータブル(変更不可能なもの)とすることで安全性を担保している言語が多い。一度作成したデータは干渉できないとされる。

また、スレッドセーフという考えもある。マルチスレッド環境下で動作させても支障なく動作する目安になる。

ここで鉄道に着目してみる。鉄道には閉塞システムが存在する。駅間の軌条をいくつかの区間に分割し、そこを一つの列車が「閉塞」するというシステムだ。またこの区間そのものを閉塞とも呼ぶらしい。

電気信号などの手段(レールに電流を流すのがポピュラーらしい)により列車がある閉塞に進入したことを検知すると、その閉塞の直前に設けられた「閉塞信号」が赤色で点燈(停止現示という言い方をする)し、一つの閉塞に二本以上の列車が進入することを防ぎ、衝突や脱線を防護するしくみだ。

列車が閉塞を抜けて次の閉塞に進入すると、信号は順次「停止→警戒→注意→減速→進行」を現示(表示するという意味)する。各列車は前方の列車に衝突しないよう、閉塞信号機の指示を受けて加減速を行っている。これらは自動で(自動式の場合)行われる。

さて、プログラミングの話に戻る。プログラミングではこの機能はセマフォやロックにあたる。そもそもセマフォの語源は鉄道や道路の信号の事なのだ。もしくは、タスクのキューに該当するかもしれない。一度にこなせるタスクは一つだけで、場合によってはその受け入れを制限するという意味では、リバースプロキシサーバのようにも見える。

他にも似たようなシステムはいくつかある。今時大抵の言語には例外処理機構が備わっており、例外がスローされるとその時点での処理は停止し、別途の処理を特別に開始する。

鉄道にも同じようなシステムが存在し、防護無線と呼ばれる。正式には列車防護無線装置と呼ぶ。鉄道の乗務員がレールに異常を発見したりして緊急停車する場合などに運転席などから起動させることができ、半径数km以内にある全ての列車に報知されるシステムだ。これを受信しても自動停止しないので運転手が手動で鉄道を停止させることとなる。事故現場への冒進(本来止まるべきところに進入することを言う)を防ぐことができる。

また他にも踏切に設置された踏切支障報知装置(いわゆる踏切の非常ボタン)も同じように特殊発光信号機(踏切のそばにある信号機。略称、特発)を起動させて列車に停止を促すシステムとなっている。

両者ともに停止後は司令所の指示を受けて動くことになる。まさしくtry-catchステートメントだ。

まだまだあるぞ。ハード寄りの話題になるが、ウォッチドッグタイマ(WDT)というのがあり、一定時間以上CPUのフラグを立てないでいるとプログラムが暴走していると判定し、強制リセットが作動する機構だ。フラグは定期的にクリアされるため、プログラムは定期的にフラグを立てにいかなければならない。

鉄道ではデッドマン装置/緊急列車停止装置がこれにあたる。デッドマン装置は主に地下鉄や私鉄に導入されているシステムで、マスコン(アクセルにあたるレバー)にスイッチが搭載されており、運転中に手を離すと自動的に非常ブレーキが作動する機構だ。運転士が失神したり突然死した場合の列車の安全性を確保するシステムだ。緊急列車停止装置は、一定期間列車の操作(マスコンやブレーキなどの操作)がなかった場合に警告を発し、運転士はリセットボタンをその都度押さなければならず、押さなかった場合自動的に非常ブレーキが作動する機構だ。これもデッドマン装置と同様の趣旨で装備されている。

データを最優先

鉄道の各種保安装置の意義は、乗客らの命を守ることである。プログラミングもそう設計されるべきだし、事実大抵のプログラムはそう設計されている。この場合、乗客にあたるのはデータだ。エラーを食ったら、とりあえずデータを避難させたりすることが必要だと思う。

レールというプログラム

レールはプログラムに見たてられる。一定方向に走って行き、一定区間ごとにデータを乗り降りさせる。他の処理とぶつからないようにスケジューリングがなされている。そしてなにより、複線化(マルチスレッド!)することで処理できるデータ量が上昇する。事故が起これば大混乱になる。そして、レールやダイヤの設計が後から響いてくる。

今回はこのくらいにしておくが、まだ時間があったらこんな記事を書いてみようと思う。

ろくに感謝されないのも列車とプログラミングの共通点だなぁ……