イプシロン・ロケットの打ち上げが失敗したが、その理由が判明した。信号の遅れだ。一種の遅延である。
起動信号が二つのプロセッサー（演算素子）を通過した際、想定外の 0.07秒の遅れが発生。この影響で復路の信号も遅れ、管制棟のコンピューターは規定時間内に信号を受け取れなかったため、姿勢に異常があると判断したという。──
（ → 朝日新聞 2013年8月31日 （図あり） ）
一方、次の話題もある。enchantMOON がいまだに駄目だ、という話。
enchantMOONをお披露目してきた、2.5.0にしたけど起動後の内部エラーで始まりチュートリアル中のColumbia墜落、頻発プチフリに描線遅延の変な補間、意義不明なパスワードロックと説明抜きでも楽しんで頂けました
— 笑い兎 (@WaraiUsagi) August 31, 2013
#enchantMOON 出荷時点でver 2.5.0だった。おそらく最初からそれなりにこなれたバージョンなんだろうけど、それでもたまに固まるなぁ。シールの概念を理解するのに少し時間かかってしまった。取り敢えずペンの色と太さを変えるシール作って休憩。
— Oishi Masahiro (@masmas) September 1, 2013
“enchantMOONで、手書きガジェットレポートを作ろうとしたが無理かも。 | タロタローグ ブログ：まぁ、書き味は悪くないんだが、大事なところは軒並み駄目って感じだね” http://t.co/zI1aO3oAWl
— zapa (@zapa) September 1, 2013
──
この二つの事例を見て、共通点を感じた。
「イプシロン・ロケットとかけて enchantMOON と解く。その心は？」
次のことだ。
「 OS の難しさを甘く見ている 」
一般に、OS というものは、アプリとは違う。アプリならば単に OS の上でルールに従ってソフトを書くだけだ。その前提となる基盤は定まっている。
しかし OS は違う。OS は、その基盤となる状態（ CPU やメモリなどのハードの状態）が、一定ではない。遅延とか何とかは、ざらに起こる。そのせいでシステムがクラッシュする、というようなことは、頻繁に起こる。（本来は）
だから、そういうことが起こらないように、OS はハードの乱れを吸収するわけだ。
比喩的に言うと、凸凹の地面の上に、きちんと床をつくることに相当する。地面はしばしば歪んだりするのだが、それでも床は一定の安定性を保つ。だから、床の上では、人は一定の仕事ができる。「地面が歪んでいる」というようなことは忘れることができる。
これがソフト屋の発想だ。
しかし OS というものはそうではない。ただのソフトではないのだ。ハードとソフトの間を取り持つものだ。そして、ハードが送ってくる信号は、しばしば乱れるのである。
なのに、ソフト屋は、そのことを理解できないことがある。
──
おそらく上のことが、二つの事例における失敗の理由だろう。
・ イプシロン・ロケットの失敗
・ enchantMOON の失敗
どちらも OS レベルの失敗がある。それはおそらく、「ソフト屋がソフトをつくるつもりで OS をつくったこと」に理由があるのだろう。本来ならば「 OS をつくった経験者」に任せるべきだったのだが、「アプリをつくった経験者」か何かに任せたのだろう。
「おれは大規模な会社のシステムを作ったことがあるんだ。これほどデカいシステムを作ったことがあるんだから、今回の仕事も楽にできるさ」
そう思ったのだろう。しかし、アプリをつくるのと、OS をつくることには、質的な違いがある。どれほどデカいシステムを作ろうと、それはアプリにすぎない。（ハードとは無縁だからだ。） 一方、どれほど小さなシステムだとしても、それがハードと直接連絡するのであれば、それはアプリではなくて OS なのである。当然、ハードの乱れの影響を受ける。
このことを理解できなかったのが、上の二つに共通する失敗だろう。
（ ※ 以上は私のヤマカン的な推測です。当たっている保証はありません。間違っている可能性もある。……本項は、専門家の指摘というより、素人のヤマカンとしてご理解ください。当たっているかもしれないが、はずれているかもしれない。……五分五分よりは、分が悪いです。）
（ ※ 本項は、ことの真偽を示すというよりは、発想のおもしろさを楽しむためのものです。→ 「イプシロン・ロケットとかけて enchantMOON と解く。その心は？」）
Digio2 タッチペン ツインヘッドタイプ 取替式ペン先2個付 ブラック ECTP-02BK
本当の理由は詳細なフロー図を検証しないと分からないし一般の部外者には公開されないため推測で書く｡
まず0.07秒の信号の遅れが原因と言われているが､それを見込んだ冗長性が必要だ｡そうでないとマージンが低く信頼性が下がる｡
正確な時刻の信号取得とそのズレを容認するシステムとは矛盾しているようだが､それをカバーするのが本来正しい設計だ｡
ブレーキを踏むのが0.5秒遅れたために事故りました､とは最終動作を言っているだけでそこに至った速度超過､脇見運転などの主因の説明ではない｡
イプシロンも同じで本来正しく設計すべきゼネラルフローの段階でミスを生じている｡
意外にセンサー系を使う者は時間感覚に疎い｡私は2度ほど大手のセンサーメーカーにクレームを言ったことがある｡
｢電気の世界に 瞬間 はない｡パルスの立ち上がりなのか立ち下がりなのか､どれを基準に信号を得ているのか
このカタログからは読み取れないではないか､タイムチャートがなければ設計もできない 採用不可｣
時間軸に敏感なのは光通信系 半導体系でありピコ秒単位でモノを考える｡ところが一般の制御系はミリ秒ぐらいしか考えない｡
今回のトラブルはPLC（俗にシーケンサ 制御装置のひとつ）を使ったからではと思っている｡PLCは工業系で実績があり信頼性が高い｡
気をつけるのは信号取得のタイミングだ｡これはプログラムがループになっていて高速で循環して監視実行するタイプのため
ループの最初と最後では大きなソフトになると0.05秒ぐらいの時刻差が生じる｡それを踏まえた上で設計をするのだが､コードが次第に
大きくなると見過ごしやすい｡この報を聞いたとき｢あ､PLCのコードが増えたための照合ミスだな｣と思った｡
フェイルセーフが効いたと考えれば許されるが､本質的な制御バグを潰すのを怠ってはいけない｡