その機能を入れるにはメモリーが足りません
夢の自動車電話交換システムの開発実現・・・
出来て当たり前の自動車電話端末ソフトの悲哀
1981年当時、在籍していた松下通信工業では並行して開発がすすめられた海外向け自動車電話には北欧向けの自動車電話NMTモデルと中近東向けの自動車電話とがあった。NMT向きのモデルは寒冷地仕様で人間の生死にもかかわるようなインフラ装置でもあった。中近東向けの自動車電話は王族の方達の通信ニーズを賄うべく当時大型開発として自動車電話向けの電子交換機と通信システム一式を含めた装置を開発納入するという一大プロジェクトとなっていた。こちらの端末はかなり高温な環境で動作するモデルだった。分散処理で構成されるように設計された新型自動車電話交換機は世の中の交換機メーカーからスポットライトの当たる交換機開発となっていた。しかしながら、端末側については、すでに国内でも商用化を遂げたNTT自動車電話に比べると周波数も800MHzのそれから比べると400MHz帯の作りやすいスペックだったり耐環境性能としての温度範囲の縛りは厳しそうなもののハード開発は協力会社に任せていた。自分たちがシステム仕様を決めて作る端末なので設計担当についてもハード・ソフト共に協力会社に依頼する形で試験装置込みでの開発が進められていた。私は、他の端末開発を任されていたのでこの端末ソフト協力会社のメンバーがスムーズに開発環境を使いこなせるようにと自らが整備したデバッガーや磁気テープベースでのミニコンクロス開発環境などの指導を行い、開発の相談にも乗っていた。
事業部を取り巻く状況からは、松下電器グループとしてソフトウェアの開発体制強化の目的に系列のソフトウェア会社を設立してコンピュータメーカー出身のエンジニアらを集めて主だった開発チームに充てられていった。独立系のソフトハウスも様々な開発に参加するようになり事業部のクロス開発マシンの稼働率も高くなっていくとともに開発環境の刷新が求められていった。そうした中でパンチカードと磁気テープとミニコンピュータという規模では対応できなくなってきたのは明らかだった。ボトルネックは開発のターンアラウンドタイムだった。また、マイコンの登場によってマイコン自身で作られた小規模な開発マシンも登場していわゆるCP/Mマシンに毛の生えた環境でフロッピーベースの開発マシンも登場してさまざまな活況を呈していた事業部だったが、開発資産の効率化共有化という観点で議論が沸騰していた。交換機開発チームが当時もっとも大きなプロジェクトだったが、このチームが選定したのは会社で保有利用している電算部門のIBMマシンの上に構築するというクロス開発環境だった。IBM3270の端末スクリーンを使って開発を行うスタイルだった。大型マシンのパワーでの期待や管理の仕組みなどを集約したいという思いもあったのだろう。開発環境に必要となったコンソール系統の開発で必要となったインテル社のMDSという専用開発装置なども合わせて利用するという形態だった。
納入先はオイルダラーの国々 UAE/QATAR
納入先は中近東の王族を対象としたものであったから国内のものと近い形にみえたが、独自の通信方式などを実現したうえで電子交換機の上で自動車電話が必要とする移動しながら中継システムが移っていくという根本的な仕組みを通信制御ユニットの中の管理データもろともユニット間で転送して群体として構成できる電子交換機の達成には社外からは驚異の目と冷ややかな嘲笑とが向けられていた。そんな気合の入った電子交換機プロジェクトとは裏腹にその端末機開発については、独立系ソフトハウスに開発委託をして自らが起草する通信方式を仕様化して提供してきた。そう端末ソフトは電子交換機の難しさに比べたら出来て当たり前の評価もされないものとして会社は捉えていたのだった。ともあれ端末ソフト開発は、端末となるMC6802と疑似基地局となるZ80の2つのモノを開発する形で二人のエンジニアが進められていた。信号フォーマットに必要なパラメータが設定スイッチや表示が出来る装置となっている疑似基地局装置と端末は信号処理としては裏返しなので、リーダーエンジニアが開発してしまっていたようだ。端末としての構造も大半書き上げてしまった課程でもう一人のエンジニアが自動車電話システムの開発進捗に応じて仕上げていくという形で任せていたようだった。
SPEC:MC6802 8kB ROM 1024x4bit RAM
端末ソフト開発チームの支援を任されてはいたものの、私は国内端末の開発をしながら片手間のものだった。彼らが使う開発支援システム一式の開発や整備を引き受けてきたからだったのだが、マイコン草創期と重なり当時流行りとなったパチモンのアップルIIコンピュータもどきなどに話を咲かせるような人たちが開発には参加していたので、休憩の時にはそんな話も弾ませていた。北欧向けの自動車電話の開発には、後輩のエンジニアが担当し、勃興したばかりの組み込みシステムハウスと組んでのソフト開発を進めていた。北欧の自動車電話は雪に閉ざされたときに最後の砦となる死命を決する重要なインフラなので、富裕層向けというよりも普通に必要とする人たちに向けたライフラインを確保するための必須装置なのだった。
どちらも400MHz帯を採用した無線機でケースは共通となったりしていたのだが内実は大きく違っていた。搭載するマイコンはどちらも事業部としては標準のモトローラ6802で8kBのEPROMと周辺LSIはロックウェルのVIA6522を用いていたのだが、違いはRAMのビット幅だった。ハード開発を任された協力会社のエンジニアとしては初めての8ビットマイコン設計ということもあって必要となるメモリののビット幅がバス幅とあっていないことよりもトータルの容量が大きいという点がメリットと考えていたようだ。当然メモリの上位ビットには不定の値が入るので処理しないといけないというありさまだった。
勃興する数多い仕事の中とはいえ、電子交換機・フルターンキーで実現できるという大きな躍進となる大きなプロジェクトの中ではライトの当たらない仕事でレビューも不足していたということになる。しかし、この端末が出来ないことにはシステムにはならないのだった。顧客先は中東の王国のVIP専用のシステムであり現地とのやりとりなどで少しずつ機能についても変更が加わり、全体の仕様を提起する側の凍結も進まないまま二転三転と仕様が変わっていくことが続いていたようだ。磁気テープを抱えて、カードパンチをしつつソース転写しつつの編集をして出来上がってくるのは紙テープとアセンブルリストだった。出来た紙テープを巻き取りリストをファイルに綴じ、デバッガーに紙テープを通してローディングしてデバッグをしてリストに修正点を書きつつパッチを飛ばして開発を進めている。周りから聞こえてくるのは移動局の開発が遅れているとかの声だった。それが当時の組み込み開発だった。実際の開発内容については介入していなかったので、挨拶程度のやり取りで返ってくる返事は「なかなか、こいつは大変ですよ」という返事受け取っていた。サポートとして垣間見ていた、この開発をされていた独立系ソフトハウスの二人の顔色が疲れていることは気がかりだった。
そして誰もいなくなった、担当は自分一人に
危惧は現実となり、いつしか、そのリーダの一人は面倒見切れないということなのか、会社に来なくなってしまったらしい。元締めとなるソフトハウスに問い合わせしても音信不通となり、更に、もう一人も来なくなってしまった。残されたのは未完成の松下からの仕様書とそれに対して作りこみをしていた開発チームの戦いの記録としてのソースだった。いなくなってしまったとはいえ、彼ら二人で端末と試験装置の2つを作り上げていて少なくとも標準的な呼処理という通信手順を一通り確認できるまでには仕上がっていたのだったがシステム仕様を設計されているチームからの回答では、まだ移動機が全然できていないという認識だった。この状況で対応していくために後片付けを責任をもって行うために専任没頭することになった。
ROM容量の8キロバイトというサイズは、当時の北欧向けも国内自動車電話も同様な規模感だったので、特に不足しているという認識はなかったのだが実装されているソースコードで残されている容量は殆どなく、未実装の機能がまだ多く残っているという事態にソースコードをすべて見直すことから手を付けるのだったが大きな問題は、必要なRAMが内蔵のものでは不足していた上に外部に接続した1024ニブルという4ビット幅のメモリにアクセスしてこれを活用するしかなかったのだが空いているビットについてのマスク処理などをしないと活用も難しいのが実情だった。それでもこのメモリを使って信号の誤り訂正処理も実施していたのだった。
開発効率を上げるために、ミニコンクロス環境からマイコン専用開発環境として導入しはじていたHP社のシステムにソースを移行するために一旦磁気テープから紙テープに落としてテレタイプASR33を繋いで紙テープになった長いソースコードを読み込んだ。ラインエディタからフルスクリーンエディタに移り、パンチ過程で時々発生する全穿孔のデータが気持ち悪く混じっていたものも瞬間に抹消できた。1日がかりでまとめた修正を行い紙テープ作成していたTATも高速アセンブルとROM書き込みで一気に早くなった。
ソースコードで見える限りの仕事はこれで効率を上げて開発が進められると感じたのだが、ソースコードでは解決しない大きな問題が控えていた。
まるで賽の河原の石積みのようなありさまだ
量産化と、コストダウンの観点からこうしたメモリ付けになったのだろうが、ソフトウェアの処理がどうなるのかという視点からのコスト意識などは、まだまだ希薄な時代だった。内蔵RAMでは足らないが、外付けの8ビットのRAMは高いということだったのだろう。ある意味貧乏くさい設計こそが端末のスタンスだった。対抗試験を行う交換機や基地局側のカードのソフトを開発しているチームからは、端末担当の私のことは貧乏長屋の住人と呼ばれていたらしいが、事実メモリを買ってもらえないのが実情だった。「よし、おいちゃんがメモリを買ってあげよう」などと弄られているのがよくある風景だった。ドライにハード設計がだめだからと声を大にしていったりすることが出来ないのが私自身が未熟な技術者な点でもあり、ちまちまとアセンブラソースレベルで縮められることを見つけては少しずつ入っていない機能の実装を続けていた。処理コードの最後が共通ならマージするといった当たり前のことをいくら積み重ねても、いれなければならない機能の山は減らない。高価なRAMが載せられないにしても、せめて4bitのRAMの上位ビットはマスクできないかとハード担当に相談すると空いているゲートで出来るという話になった。これで4ビット幅のメモリもカウンタやフラグに命令のオーバーヘッド無しで使えるようになる。それでも減らしたメモリはあっという間に懸案事項の修正や実装で使ってしまう。
他の大きな問題も出てきた。連続送信したまま止まってしまうというのだ。問題の理由は、搭載した周辺チップ6522のクロック割り込み機能のバグだった。自動車電話のシステム自体は、CPUで用いている水晶発振子に基づいて動作してこのケースではモデムチップの関係から3.6864MHzというものだった。実際の動作はこの1/4周波数で動作するので約1MHzの動作クロックということなのだが、問題のあったVIAというチップに周期動作のタイミングとしてモデムから出力されるタイミング信号である送信クロックと受信クロックが割り込みは信号として印加されてソフトウェアはその信号で時間軸の処理切り替えなどをしていたのだが、この割り込み端子で取り込めるエッジ割り込みは動作クロックとの位相があるときには受け付けられないということが判明した。送信タイミングというのはモデムチップの立ち上がりで決まるもので一度そのモードになったら信号が印加されているのにわからないという故障モードになってしまうのだ。組み込みソフトとしては入るはずの割り込みが起きないということを立ち上がり時点で確認しておかないと信号フレームの送信開始をしてしまってからでは送信したままシステムに障害を与えてしまうという動作になってしまったのだった。検知出来ない場合には自分自身をリセットしてタイミングがずれて起動されることを期待するというのが、その解決策だった。立ち上がり時点で送信タイミング信号による割り込み検知を確認をいれておき、送信処理の先頭に終結までのタイマーガード処理などを入れる。必須の修正をいれると。またまたメモリーが枯渇して新たな修正が必要になる。
性能を満足させる修正と機能を満たす修正をしていく必要がありそれぞれ対策をするために必要なステップ数を算出してソースを見直しソースコードのモジュール配置を関連付けでソートしてサブルーチンが短く届くようにするとかいろいろ考えられる策はこうじてみたのだが、ソースコードの似ている部分をまとめてしまうなど色々なアイデアを実践してきたが、ソースコードをいくらみても修正が思いつかなくなった。そうアセンブラで考えてみても答えが浮かばないのだ・・・。
機械語で見直していたら天啓が降りてきた
諦めてアセンブラーソースで解析することをやめて、しばらく16進ダンプリストを眺めて別の視点がないかどうか考えることにして、社員食堂で珈琲をのみながらダンプリストを見ていると気になるもやもやが出てきた。「なんだかExxx, Fxxxが多い」ということだった。モトローラアーキテクチャなのでアドレス配置が最後になることからE000-FFFFが8kBのＲＯＭ配置なので当然なのだが、ここで気になったのはEとFが二進で自分自身には映っていて1110と1111と見えていたのだった。そして上位3ビットがすべて111で共通なので意味がないのではということだった。モヤモヤとなった天啓は、もとよりテーブル化されて各種の仕様変更に耐えられるように設計されていたので処理を一歩進めてアドレス範囲が13ビットの新しい機械語を定義して、その命令部として上位の3ビットに意味を持たせられるのではないかということだった。この降りてきた天啓のアイデアで当時AppleIIに搭載されていたSweet16という仮想マシンに似たようなコンセプトでSweet13とでも呼ぶべき命令を決めてテーブルの圧縮化をさらに果たすことになった。新しい命令として追加されたのは111は機械語呼び出しで後続の13ビットのアドレスを実行する。011はテーブル上の分岐で後続の13ビットのアドレスがさすテーブルへJUMPする。101は直前に終了した命令の結果しだいでの条件分岐命令としてテーブルJUMPする。000は通過情報を示すデータ出力で後続の13ビットのデータとして出力する。この新しい機械語はインタプリタによりフェッチしていく。インタプリタ経由で機械語モジュールを呼び出すので予めレジスタなどをクリアして呼び出すことが実現できた。似たようなモジュールはエントリーが縦積みのコードとなってレジスタのインクリメントが続いたりしていた。飛びこむエントリーに応じて引数が生成されるのである。ちまちました話だが、アセンブラで自前で書いていてはかけないコードなのだ。自在に操れるインタプリタがあって実現できる方法なのだ。組み込みの実装では性能を満たすための速度優先の処理と機能さえ満たせれば処理時間は問題にならないという処理とがある。これは後者に向けた処理でもある。高機能になればなるほどそうした手続きフローとモジュールの集大成となってコードは膨れ上がっていくのであった。
こうした形で大きな短縮が達成できて数百バイトの修正が出来てほっとした。新しく追加した機械語命令をアセンブルするために、マクロ命令機能を用いたのだがアドレス演算した結果をマスクしたりする機能を用いるために今度はマイコン専用開発マシンすらも高速アセンブルが出来なくなった。解決策は、専用のカスタムアセンブラを作ることしかなかった。
アセンブラを定義できるクロス環境
HP社のマイコン専用開発環境が導入されるまでは、松下通信工業自身が開発してきたミニコンなどの流れからマイコンの開発に必要なクロスツール自体もアセンブラを用いて半年以上かけて開発してきた歴史があった。富士通で研修をされてきた先輩たちが8085用のアブソリュートクロスアセンブラを開発して、さらには次の先輩がリロケータブルアセンブラを6800向けに開発されていた。この先輩たちがZ80版のリロケータブルクロスまでを開発されたが、爆発するユーザーニーズにマシンリソースが応えられず各部隊で小さな開発マシンが導入されて氾濫していた。まともに使えて拡張性もあり処理能力があるという目的で筋の良かったツールはHP社の64000というシステムだった。高額なマシンだったがもとより高額なHP社の測定器に慣れてしまっていた事業部では効率の良い物ならばということで導入が進んだ。
こうした流れにのって端末部隊はHP社の開発機器に移行を進めていた。高速なクロスアセンブラがテーブル定義で生成実現できるということが売りの一つでもあったが一般的には6800かZ80かといったマイコンに対応できれば普通は問題がないのだ。しかしながら端末機器を開発していく上では、4ビットマイコンなどを用いて周辺機能を作りこんでいく時代とも重なり様々なマイコンを開発できる機能が評価されてこの汎用アセンブラも導入して活用してきた。端末用のマイコン6802は6800用のアセンブラとして購入されていた。ソースコードではなく実行体としてのものだった。テーブル解釈する新しい機械語を生成させるための手法はマクロ命令だったが、高速なマシンにも関わらず1000ステップほどのテーブルをコンパイルするのにとても遅くなってしまい開発時間が遅くなってしまった。しかたなくこのカスタムアセンブラを作りこむうえで6800に命令追加をしたかったのだが、テーブル定義を行い開発をしたのだが一部分からない点があった。しかしながら、アイデアが沸き、提供されている6800のアセンブラにデバッグ用の命令をいれたソースをアセンブルしてテーブル解釈のトレース情報を入手できるのではというアイデアを試すことが出来て問題点の解決策が見つかった。そして追加のカスタム命令を搭載した6800拡張のSweet13対応クロスアセンブラが完成した。開発速度は追加命令も含めて高速動作するようになり、開発に拍車がかかっていった。しかし、また技術的な大きな壁がそびえたった。
無線機としての性能を活かせない陳腐なハード
「現地で試験していて信号が中継局をへると通らなくなるので使っている信号速度を600bpsから1200bpsに変えてほしい」というものだった。無線電話なので音声帯域である300-3000hzを通すように設計されているのは知っていたのだが、この内容をよく説明してもらうとモデムとして採用しているMSKという方式はサインウェーブの600Hzの谷山と900HZの谷山谷が連続して繋がる形で構成される方式なので、600hzの信号と900hzの信号が同じレベルで再生されないと信号波形が崩れて信号再生が出来なくなるということだった。対応策は二つあって、周波数特性を補正する回路を中継局間に追加して対策するか、信号そのものを通りやすい1200hz/1800hzに切り替えるというものだった。しかし、それは処理速度を二倍にせよとのお題に相違なかった。案の定基地局側のソフトはなんの問題もなく動作して、移動局のそれは受信して圏内表示になることはなかった。「おお、端末ちゃんは残念だったねぇ」と弄られつつも、対策に腐心することになった。処理速度の観点からバッファリング処理や割り込み処理の深さを浅くして時間軸に展開することなどでいわゆる惑星直列的な問題を回避することなどを様々織り込んでこれ以上の策はないというものを作りまずはそれ自身で立ち上げて周辺装置が動作することも確認して、おずおずと基地局交換機が設置してあるラック搭載してある試験用移動機のソフトを交換してみたのだが、着信を行いブザーが鳴動して信号の着信シーケンスが動作したことを伝えてほっと安堵したのだが、ハンドセットを外して応答するとそれは暴走してしまったのだった。応答シーケンスでは受信と送信が同時に動作することが求められていたので最も忙しい瞬間はこの時だった。表示器の更新反応も芳しくないほど移動機の動作は緩慢になりこれ以上のこの機能の追及は無理だと悟った。ハードで改修する策をお願いして、残りの一切のソフト改修については全精力で取り組むことについては言明した。
限界は見えてきたが神は見捨てなかった
基本性能としての検査も大量の移動局を想定した試験の上で、各移動局が互いに邪魔をしないということも大きなポイントだったのだが、その目的で交換機試験ルームにはラックに移動局がたくさんマウントされた試験移動局という装置が並んでソフトウェアの試験を行うのだが、試験官として采配を振るうオーラを放つ新人T大卒であるFさんがだめだしをする。移動局がとる、乱数性が一様でなくて試験移動局で展開している8台程度の条件でも衝突を繰り返してしまうというのが、そのポイントだった。また、搭載しているリソース情報である実在の無線チャネル情報に基づいてすべてのチャネルを再試行してその通話成功に結び付けずに終わってしまうという点もあった。乱数性の問題については、立ち上がり時典で移動局の固有情報であるIDをさらにビット順を逆にした大きな値にしたものを最大値とするカウンターを実装した。これにより移動局ごとに異なる周期の乱数種とともにハードカウンターの内容を受信クロックのジッターするゆれも加えた条件で参照して乱数とした。
すべてのリソースを参照するためにはその乱数で作成した値の最下位と最上位のビットをセットして大きな値の奇数を取り出して、この数値に間隔でリソーステーブルを巡回するステップとした。偶数では全数スキャンが出来ないのでこうした処置をとり実装して再試験をお願いして、若いオーラを放つ試験官の合格印をいただくことが出来た。ともかくアイデアを出して現実解を提供して実績で応えるしかないのだが、ほっとした。
現場で起きる問題は、こうした工場試験では考えつかない条件で問題となって舞い戻ってくるのだが、まだまだそうしたことが続いた。最初に机上で考えたロジックは移動局が最後に電話を終了した後には最後に使った位置に基づいて、周波数リソーステーブルには物理的な経緯配置も記載され書かれているので、その最新利用地域から順に隣接するチャネルをリング状に外側へスキャンするという方式を提案して、その実装をした。ようやくこうした基本的な状況が実装できる程度までメモリに余裕が出来たということでもあるのだが、この仮説は現地で崩された。
いつまでも前の場所から動かんのだよ
移動局の取り扱い方法として電源を切ってしまう使い方をするとそのまま移動した先でいつまでも以前の情報地区のチャネルトライばかりをして使えるようになるまでに時間が長いというのがクレームだった。そして、また砂漠地帯ということもあって異常伝搬も多くて位置マトリックス配置とは異なった強い遠くの電波もあったりして交換機のロジックも含めて難しいことだった。結論として高速にチャネルを利用判定して捕捉するというのが本来求められていた機能要件だということが分かった。電界強度の測定には2段階のセンサー情報があったので、一定時間そのサンプリングをして判断するのだが、悪いチャネルを捨てるためにはサンプリング段階で悪い標本数のリミットを決めておくことで足切りを早くすることができるようにして、それまでののんびりとした机上理論通りに出来ていたロジックから一気に違うマシンに変えていた。目的をはき違えていたのだった。実装されたソースコードを動かすことに力点を置いていたので本質的なこのシステム要件としての所要時間といった視点が抜け落ちていたのだった。こうした実装を追加していくためには、またメモリの圧縮が必要になった。視点を機械語レベルに落としてマクロな俯瞰でとらえた方式にまだ余地はあるのだろうか。同じ手法は使わず違うアプローチとして新たに定義した仮想マシンであるSweet13?のアセンブラー記述をベースに前回の機械語での俯瞰観察を行い、仮想マシンのテーブル内に同様な機能ループが見つかった。ダイヤリングと表示更新を行うという箇所で、これは通話中と発信時の二か所にあった。こうしたテーブルを圧縮する目的でこの機械語に新しい命令であるテーブルとしてのサブルーチンコールを実装することにした。仮想マシンで利用している変数をスタックに押し込んで仮想マシンを呼び出す意味で再帰呼び出しを行うのである。カスタムクロスアセンブラも改版してサブルーチンコール命令が追加されて対応が整った。
この発想で最後の大幅な圧縮を果たすことが出来て凡そ60バイト程度の短縮が出来たので懸案事項を改修できそうだった。
最期のアイデアで残りメモリは3バイト
それでも更に現地で見つかった問題は現地に存在する長いトンネルの存在だった。このトンネルを通過するのに60秒程度要するらしいのだがここには、あの警察無線で作ったトンネル中継装置もないので電話をしたまま入ると切れてしまうのである。交換機の処理としては通話の継続を実現したいのだが、移動局が電界断と判断して切断処理をしてしまうのである。だんだん電界強度が下がっていく過程での切断と、強電界が続いていた状況での電界強度の低下判断を分ける必要があった。電界強度の判定は二段階のセンサーしかないので、サンプリング母数を増やす形にして移動平均としての評価をとるようにロジックを組むことにした。とはいえメモリは貧乏なので圧縮する必要があった。移動平均というよりも電界強度のサンプリング数判定の都度とても強かった場合にのみ記録シフトレジスターに1、悪かった場合には0を詰めていくようにしてすべてが1だった場合には長いタイマーをスタートしてこの先に発生する電界劣化を無視するというロジックを取り入れた。あらかじめテーブルコードの圧縮もしていたのでこれを入れることが出来て移動局のソフトはいよいよ完成した。思えば、なんどもROM書き込みをして現地に出張するK部長に渡すためにTCATまで追いかけて数百個のブツを渡したりして、しかしK部長が現地に着く前にはバグが見つかったりする事態が続いていたので。貧乏長屋のへっぽこ技術屋の気持ちもすっかりいじけていたのだが、ようやく地力をつけて動き出した移動局のソフトは現地で大量改修を進められるようになったのである。仮想マシンによる実装やメモリ幅が足らないことによるオーバーヘッドなどもあり移動局の動きには時折ぎこちなさが見えるのは致し方ないのだが、それでも着信を見逃すことはないのだ。実は着信を受けてベルが鳴りだすまでの間は表示機の更新も含めていろいろなものにユラギが見えるほどなのだ。ただし、このころの自動車電話のUIとしては着信音がするまでに、その表示などを見ることがないので問題がなかったことから、この長い長い闘いは勝利ともいえるのだが、勝ち取った褒章として私は現地で責任をとってROM交換をするという中近東海外ツアーの特賞を突如いただくことになった。
海外現地ツアーの栄誉をいただいた
特賞となった受賞の条件には、実はその数か月前にパスポートを保有していたという事件があり、おかげで即座に特賞の栄誉を受けた。事件とは、その年の初めに兄が国際結婚をすることになりフィリピンのマニラでの結婚式に兄弟を代表して父母と参加することになり当時ようやく出回り始めたVHSビデオカメラのショルダー可搬型のものをレンタルして結婚式とハネムーンツアーにお邪魔虫をするという事態があったからだった。姉妹や私は兄は結婚はしないものと勝手に決めつけていた節があったので突然日本に連れてきたフィリピン人の女性の登場で家族は上へ下への大騒ぎとなっていたのだった。この年はキューピットの活躍で兄に続いて姉にも米国の日本人三世の彼氏が登場するなどしていたので、この特賞での中近東行きについては、私が顔の前に御簾がさがったような現地の女性を連れて帰るのではという噂もたったらしい。何せ、英語との付き合いは父が東京オリンピックの時のキディランドの都内ホテル展開などで会話に苦労したことなどから小学校の子供たちに遊びのように引退した英語の先生の家を訪ねて行う塾に通わせていたのは遠い昔だったし、ともあれ成田から台湾給油で香港トランジットのバーレーンで更にローカル飛行機にトランジットというコースで向かうコースがわたされていた。初めての海外出張は、最初のフィリピン行きとは違っていて一人旅だったし、直行便ではないから乗り換えの昔の香港空港ではビルの谷間に墜落していくかのような印象さえある過激な印象だった。
香港までのJAL便とは違って、香港からはキャセイパシフィックのジャンボだった。ジャンボの機長席の階下のノーズ部分にあるエリアのセンターにある二席の一つが私のシートで初めてのビジネスシートだった。シャンパンをもらったりして喜んでいると隣の席はNECのバーレーンに向かう自動車電話のエンジニアだった。似たような仕事をしている二人の日本人が隣に坐したのはとても奇遇だった。インド上空を通るときにえらく揺れた印象はあったのだが長いフライトの末バーレーンに到着して、ここで半日以上のフライト待ちになった。心配なのは自分が乗る予定のフライト情報が案内板に出ないことだった。次々とフライトがあるので長い待ち時間のフライトだから表示するのは、ずいぶん先だと理解はしていた。
バーレーンの乗り継ぎで右往左往
それでも10時間が過ぎるとようやくフライトの情報が出てゲートナンバーが表示されたのだが、一望できる範囲に当該のゲートは見当たらない。いよいよ搭乗案内が流れるものの自分のゲートがわからないでいたら、小さな飛行機だったのでバスで移動して駐機場から乗り込むというスタイルだったのだが、そうした飛行場の常識を持ち合わせていない自分自身はここでも焦りまくっていた。なんとか小さな飛行機に乗り込みバーレーンから飛び立ったのだが、すぐにまた着陸態勢になってどこかの空港についていたのだが殆どおりる乗客もいなかった。慌てて隣の乗客に尋ねると、こここそがカタールのドーハ空港だった。期待と不安のままに入国検査を受けるのだがフィリピンの時の経験とは違って、パスポートを返してくれない、そしてそのまま外へ追いやられてしまった。不安はピークに達したのだが、ほどなく優しい物腰のチームリーダーと久方ぶりの対面を果たしてパスポートを取られた件を聞くと、「それは預けるということなんだよ」と教えてくれた。正式な国交が無いカタールと日本の関係においてはビザ発給もなくパスポートも帰国させるための人質のようなものらしかった。重ねて言うと、当時の状況では期間を超えた滞在自体が違法なので期間に応じて罰金を納付するということだったらしい。
何もかもが理解できないまま、まだ砂漠の上に立地していることを体感する街並みに向かうためにチームリーダーが乗ってきた車に搭乗しようとしたら大きな声で制された「ドアノブやボディの表面に触ってはいけない」と火傷を負うからだという。必ずドアノブの下から触ってドアをあけないといけないということだった。砂塵をあげながら空港からホテルに向かい、大きなビルもないのが当時のドーハの市内だったが、ようやくホテルにつき会社の先発隊の面々と久しぶりに再会した。なぜかみな一様にひげを蓄えていた。何かが違うとおもった。
ともあれ部屋についたので、砂ぼこりや熱風などの気持ちをリセットしたいのでシャワーを浴びることにした。水を回したつもりがお湯が出たので、慌てて反対のバルブを回したらもっと熱いお湯がでた。そう、蛇口の水が冷たいものというのは世界では非常識なことなのだった。少なくともこの時代のカタールドーハではフィリピンのホテルよりも水は熱いものが蛇口から出てきた。自動車の車体に触っていけないという話でテレビで見た記憶のあるボンネットの上で卵焼きが出来るというシーンを思い出した。夜になれば冷えるのかと思っていても足元にもし、金属製の工具などが落ちていたらそれは蓄熱しているので素手で触ってはいけないそうだった。
ROM交換でサービスインを実感
砂漠の国にきて、現地のサービスセンターに詰めていた仲間と合流してサポート作業を始めた。お客様の電話機も順次リコールをしてサービスセンターに戻ってきたものを交換作業をする。トランクルームに搭載された無線機はA4サイズ厚み5cmほどのサイズとなっている。ワンタッチでマウントから着脱してメンテナンスに移れる。到着早々の洗礼を受けた車体自体の高温環境下での利用によりトランクルームにあったそれも高温となっている。この機種の開発に際して半導体の選定もMIL規格である85度に耐えるものを使っていたことは知っていたのだが実際にその環境で動いている端末を「ほいっ」と渡されて再度過酷な環境について実感した。そして操作ハンドセットなどを介してみるUIのそれには違いなくこのところ苦労して積み上げてきたプログラムが確かに遅いけれど着実に動作しているのが見て取れて私の分身がそこで頑張っていることも確認できた。戻ってきた機械の蓋を開けてロジックボードからUV-EPROMであるi2732を取り外して、書き換え済みのUV-EPROMを実装しなおす。外したUV-EPROMからは遮光シールをはがして、紫外線ランプを搭載したイレーサーのトレイに投入する。消去には15-30分程度を要するがトースターと同様にゼンマイ駆動のタイマースイッチをひねってまとめて消去するという形だ。サービスセンターに詰めていたのは共栄会社のエンジニアの方一人と、事業部の工場から来ていた登山クラブの後輩でもあるエンジニアだった。熱い国ゆえに休憩もきっちりとらないと体が参ってしまう。永らく現地に詰めて何度も私が送付して繰り返してもらったソフトウェアの改修作業のめどがたったことを伝える彼らの苦労話に耳を傾けた。
おもえば現地との打ち合わせはいつも日本の夕方でありこちらの朝であった。国際電話での会議はエコーも聞こえないとても会話それ自体が遠く感じて現地で展開しているチームからの要望内容や問題点報告に聞き入ったことが思い出された。サービスセンター自体は、納入先の通信会社の一角にあり、ランチは、その会社の社員食堂を利用させてもらった。中近東の強い日差しや暑さにも似合う、入社後に富士通出向中からの不思議なつながりとなっていた逞しい頼りになる無線技術者のN技師も現地入りされていた。例の中継装置での位相歪補正回路の実装や伝搬の確認などをされているということだった。「本当に移動機の速度は上げられないのか、基地局間に追加するのは大変なんだぞ」とN技師にも窘められつつも「もう本当に移動機は大変なんすから」と返すのが精いっぱいだった。一緒に食事をとる段になって彼はカレーライスを選択して私は現地の方が食べていたプレート料理(定食)をいただいた。
先だってのフィリピン旅行などでの経験に基づいて料理は手づかみで現地の方と同様にして食べていると「おい、それを食べれるのか、俺には無理だ」とN技師から言われたのだが、現地の方たちがほかのテーブルで食べているスタイルでありむしろスブーンを使って食べている彼が異質な状況でもあった。この食べ方をしていると実は食べる前に香辛料の辛さを指で感じることが出来るということを、以前会社のS部長が朝会のときに話されていたことも切っ掛けだったし事実マニラでは試していたのでごく自然にその食べ方が出来ていた。同じ食べ方をしていたほうが現地の方とのコミュニケーションも受け入れやすいと感じた。
リーダーやN技師に現地の中継基地なども時間をみて来るまで案内していただき砂漠の中の道を走るという体験が出来た。そして、この国で一番怖いのはラクダとの交通事故らしいということもお聞きした。走行しながらかけ放題の電話を使って実際に移動通話中のチャネル切り替えなどがスムースに動いていることも確認できた。チャネルの表示だけを見ていると遠くの基地局をつかんでしまうことも事実異常伝搬として起きていたのだが、新しいロジックではこれを許容して高速により電界強度の強いチャネルを利用可能にしたので、むしろ処理が大変だったのは交換機側の処理だったようだ。
砂漠での移動中にガソリンスタンドで休憩しているとN技師がコンロにかかっていた薬缶のミルクティーを頼んでくれて砂漠の思い出の中にその味をしみこませてくれた。容れ物はとても清潔にはみえなかったのだが、口に含むとその甘さが今までの苦労を流してくれた。
理解されないのは仕方がないか
この開発の過程でもマイコン部品の進歩は続き、EPROMのサイズは2732 / 2764 / 27128と進歩を遂げていった。私が事業部に苦労を掛けてしまったこの自動車電話装置は交換機の安定稼働も含めてシステム規模を拡大して沢山の移動端末を販売してよい売り上げに貢献したらしい。私は、自動車電話のチームを離れて業務用無線のシステムを担当するグループに移っていたのだが、自動車電話のチームの若手メンバーが息を堰切ってきて話をしにきた
若手「あの端末が新しいハードで動作しないのですが・・・」
私「何を変えたんだ、そのままで動くはずだろう」
若手「ROMを27128に変えただけです」
私「まさかリンクしなおしていないだろうな」
若手「???え」
私「あのソフトはE000-FFFFでしか動作しない設計なんだよソースに書いてあるだろう」
若手「??★☆彡」
若手は目を白黒して帰っていった。
ちゃんと直して動いたようだ良かった。
このシステムはエジプトやコロンビアにも納入されていきました。
マイコンがギリギリで動作している設計でしたが安定に動作させることが出来てとても良い経験となりました。端末が呼び出しを受けると表示が揺らぐので着信は鳴動する前にわかるのでしたが、当時の自動車電話はベルがなってからハンドセットを取るのでお客様には気づかれていなかったようです。