アメリカの本屋さんの店頭にはたいていバーゲン本ワゴンがあって、売れ残ったり、
賞味期限切れあるいはそれに近い本(去年版の旅行ガイドとか旧版コンピュータプログラムの手引書とか) が投げ売られています。
毎月第一日曜のリバモアでのスワップミートの帰りは、一休みを兼ねてカフェが併設されているプレザントンのBordersによく立ち寄りました。
ある日ここのバーゲンワゴンから買ったのがこの本。 定価$20.00のところわずか$5.00。
ずばり自分の欲しい本ではなかったとしても、これなら損はしないでしょう。 |
リアルタイム コンピューティングの黎明について調べていたら、
NASAのアーカイブ サイトに行き当たりました。
NASAでは過去に発行された文献の電子化が進められていて、
多くの文献が電子ファイルで読めます。 今回、 Computers in Spaceflight: The NASA Experience という文献を見つけました。 すこし読んでみると、あれえ? なんだか強い既視感を感じました。 本棚からComputers In Spaceを取り出して読み直してみると、 なるほど、これらはいずれも同一の著者 Dr. James E. Tomayko によるもので、 NASAの文献が1988年のオリジナル、それを一般向けにレイアウトしなおしたのがComputers In Space ということのようです。 本書の章立ては大きく有人飛行/無人探査機/地上支援システムの3つで、 それぞれのパートの中では時代順にコンピュータ技術開発の説明が進んでいきます。 Computers In Spaceに比べると各セクションが不足なくカバーされており、 それぞれのトピックスでのエピソードも豊富です。 ところでこの文献は全文HTML化されていたので、ダウンロードしてLinux Zaurus C-860で読むことにしました。 じっくり本を読む時間がとれない毎日にあって、いつも持ち歩いているZaurusに入れておけばちょっとした暇に読み進めることができます。 Linux Zaurusにはウェブ ブラウザがあるのでいちおうはそのまま読めますが、本としてじっくり読むとなると適切な美しいフォントを選ぶことができません。 そこで付属のワードプロセサ、HancomWordに内容を移し、Helveticaフォントを使ってレイアウトしなおしてから読みました。 こうすれば自慢のCGシリコンLCDならではの美しい文字で読むことができます。 やはり本と言うからにはフォントが美しいのが絶対的な条件です。 しかし考えてみれば、キロバイト単位のコアメモリと戦うエンジニアのストーリーを読んでいる自分の手のひらの上のこのマシンは、 256メガバイトの全半導体式不揮発性記憶装置をもち、250MHzクロックの32ビットRISCプロセサを搭載したマシンで、 しかも内蔵バッテリーで最大8時間連続動作できます。 当時のエンジニアの手にかかれば、このマシンにちょとした改造を施すだけで、 おそらくスペースシャトルのフライトに必要なすべての処理をまかなえることでしょう。 これもあらためて感嘆せずにはいられません。 本書はオリジナルのペーパーをスキャンしてOCRしたようで、各部にOCRにありがちな誤植が数多く目に付きました。 そこで読み進めながら誤植と思われる箇所にマークをつけておき、読み終わったのちに誤植箇所をリストにして、 NASAのヒストリー・ディビジョンに電子メールで送りました。 現在アップロードされている2005年07月15日バージョンは、私の指摘した箇所が修正され、欠落していたいくつかの写真が貼り付けられたものです。 リアルタイム コンピューティングとソフトウェア品質保証について学ばせていただいたお礼に、ささやかな貢献ができました。 |
ジェミニ8号カプセル(実物)。
全ディスクリート構成のフライト コンピュータの計算機語長は39ビットで、 ビット シリアル処理 (1ビットずつ処理が進む)。 マシンサイクルは140ms (=わずか7Hz!!!!) 主記憶はコアメモリで4096ワード。 (1バイト8ビットに換算すれば19.5キロバイト)。 本体メモリの小ささを補うために、初めて外部記憶装置(テープドライブ)が採用され、 必要なソフトウェアをフライト中にテープからインストールした。 1回のインストールには6分を要した。 2004年 ニール・アームストロング博物館にて。 |
コンピュータが大きな部屋を占有する真空管のカタマリの時代にあって
宇宙船に搭載することのできる小型軽量のマシンを産み出し、
ソフトウェア工学という言葉すらなかった時代に数々の失敗をもとにさまざまなソフトウェア開発プロセスを確立していったことなど、
感嘆せずにはいられないストーリーがこの2冊の本に書かれています。 メモリの制約から超職人芸的なプログラミングを余儀なくされていたこと、 新しいマシンアーキテクチャに移行する苦労を低減するためのリアルタイム高級言語の開発、 モジュール設計とソフトウェアテスティング、 パフォーマンス要求と保守性を維持するためのアーキテクチャのせめぎあい、 定義された開発プロセスを定着させることによる信頼性の確保など、 現在でもエンジニアとマネージャを悩ませつづけているテーマが今から40年も前に取り組まれていたことを知ると、 あらためて先駆者の偉大さにひれ伏してしまいます。 米ソの宇宙開発競争の中でアポロ計画のオンボード・ソフトウェアの開発もまた時間との戦いで進められていました。 フライト クルーから要望のあった改善提案は、工数・納期不足が理由でほとんど取り入れることができませんでした。 最初のアポロ有人フライトが目前に迫っても、ソフトウェアはおよそすべてのモジュールにバグが含まれているような状態でした。 ほとんどはフライトに支障を及ぼさないような影響の小さなものであったとはいえ、 ユニット・テストさえ行われていないモジュールも多く、 システム・テストの結果は正式なテスト結果報告書にはまとめられておらず、 その品質は十分に保障できるものではなかったのです。 大気圏再突入に向けて地球周回軌道を離脱するためのエンジン点火時刻の計算に至ってはなんと138秒もの狂いがあることが事前に判明し、 クルーはオンボード・コンピュータの計算結果を無視して、 地上管制からの連絡による点火時刻をクルーがオンボード・コンピュータに手入力するような手順が直前に決定されていました。 このバグだらけのフライト・ソフトウェアは、しかし実際に飛ぶことはありませんでした。 1967年1月27日に発生したアポロ1号発射台での火災事故により計画は一時 無期限延長扱いになり、 アポロ宇宙船をより安全なものにする努力が開始されたからです。 酸素100%の司令船雰囲気は窒素・酸素混合に改められ、司令船ハッチの緊急開放所要時間が短縮されただけではなく、 オンボード コンピュータのソフトウェアは定義された開発プロセスに基づきテスト・文書化・レビューが繰り返され、 その品質は格段に向上しました。 ・・・もし小さなスパークが3名のクルーの命を奪っていなかったら? さらに、素人向けだと思っていた1994年版のComputers In Spaceを読み返してみたら本文中で CMM に触れられていることに気づきびっくりしました。 が、著者のDr. James E. Tomayko は カーネギーメロン大学ソフトウェア工学研究所 の人だとわかり、大納得。 この2冊の本は、現代の代表的なソフトウェア品質管理手法が産み出されるに至った歴史を伝えてくれているのです。 |
アポロ宇宙船の誘導コンピュータ
"AGC (Apollo Guidance Computer)"のユーザーインターフェイス ユニット、DSKY (DiSplay and KeYboard unit)。
アポロ16号の司令船に使用されていた実物。熱膨張係数差による半田付けクラックで表示欠けに悩んでいた!
1999年 スミソニアン博物館にて。 |