Webプログラマの夏休み PHPでNゲージ模型を自由自在に動かそう[動画つき]

第2回補足 実装に注意!

この記事を読むのに必要な時間:およそ 1 分

動画の修正とお詫び

第2回「オブジェクト化しよう」において,当初,Nゲージが衝突してしまう動画が掲載されており,驚かれた方もいらっしゃると思います。深くお詫び申し上げます。意図して行ったものではないのですが,せっかくの機会でもありますので,機器制御というテーマでこの事故について分析してみたいと思います。

第2回に上がっていた「衝突の動画」

ニコニコ動画:http://www.nicovideo.jp/watch/sm7922804

この動画は,動作確認時に最初の段階で撮影されたものです。結論から申し上げますと,ハードウェアに故障が発生し,ポイントに電流が流れたままになってしまいました。このため,画面奥側のポイントが切り替わらず,衝突につながったものです。

原因究明に大変時間がかかったのですが,故障が発生している回路を使わないよう,空いている回路に新しいポイントを割り当て,プログラムを修正して(オブジェクト指向にしたおかげで1ヵ所変えるだけでした),撮影を再開しました。第2回で現在公開されている動画は,こうして撮影されたものです。余談ですが,電流が流れ続けたことによりポイントは焼損してしまいました写真)。

焼損したポイント

焼損したポイント

組込みシステムと安全対策

組込みシステムは,機器制御という性質上,事故と無縁でいることはできません。このため,とくに重大な部分は何重にも安全を確保することになります。たとえば今回のシステムでは,LANはリアルタイム性が保証されていないため,タイミング制御が必要な部分はすべてハードウェア側で処理しています。LANが遅延したり,通信ができなかったり,スクリプトが異常終了したりした場合でも,ダメージを受けることはないように設計してあります。通電時には基板のLEDが点灯し,ポイントのコネクタはレールとは色が異なるので,配線ミスもすぐにわかるようになっています。しかしハード故障については考慮が足りず,このような結果になってしまいました。

この連載でNゲージを選んだ理由の1つは,鉄道というのは何よりも安全が重視されるものであり,ぜひそのような考え方も知ってほしいと考えたからです。筆者自身が悪い見本を示す形になってしまいましたが,今回の件をふまえて,このような故障モードのときにも安全側にシャットダウンするよう,ハードウェアを改修しようと考えています。検討した範囲では,ファームウェアの修正だけで済むと見込んでいます。

なお,今回はハードウェアの故障でしたが,もちろんソフトウェアが原因の故障もあります。次回は,ソフトウェアの不具合を見つけるためのツールを取り上げる予定です。どうぞこれからもご愛読いただければ幸いです。

著者プロフィール

木元峰之(きもとみねゆき)

独立系ソフトハウスに8年間勤務,パッケージソフトの開発や記事執筆などを行う。現在はフリーのコンサルタント。SWESTなどのワークショップで分科会のコーディネータを務める。デジタル回路設計歴30年,プログラミング歴27年。

きもと特急電子設計
URL:http://business.pa-i.org/

コメント

コメントの記入