[1999年06月~1999年10月]PHS組込み開発

1999年の夏ごろ、仕事で組込みの開発をした。
工場内で既設のPHS交換網を利用して製造ラインに不具合が発生した場合に迅速にPHSにアラートを通知するシステムである。

要件定義と使用する機器の選定は発注元でおおよそ決まっており要件の分析からではなかった。
まぁ、PHSの回線交換機を介するようなシステムは自分一人では思いつかないので要件定義がまとまった後というのは私としてはシステム作りに専念できるのでよかった。

どんなシステムかというと製造ラインからあがってくるアラートをTCP/IPの通信で受信してそれをPHSの回線交換機を通してPHSへこれまたTCP/IPの通信で送信するというものだ。

PHSは10数台、いくつかのグループに分けられてそのグループピングもシステムの設定で変更できるようにする。

また、PHS側はアラートを受けたらそのアラートは既読にするといった双方向の処理を行う。
アラートの通知にはリアルタイム性が必要なので既読にされなければ指定回数の再送が行われる。
グループ内の誰かが既読にすれば再送は行わないとか少々細かい設定も行う。

PHSとのやり取りは、なぜemailではないのか？

1999年である。この年にDocomoのiModeは開始された基盤も何もかも一般的ではない時代である。
PHSのショートメールみたいなものは？ソフトウェアとして当時出回っているようなものもなくそもそも受信したものに対して既読にするような双方向性は更に難しかった。
そしてリアルタイムに直ぐに通知されなければならなかったので常に受信状態にある必要があった。

そういった事を考慮した結果、Ｐ社のPHSが採用された。
このPHSは大画面を有しており、専用の開発ツールを用いて電話やTCP/IP通信の開発を行えた。
※専用の開発ツールは当時まだ開発中の中途半端な製品だったのでしばしば誤動作に悩まされた。私が使うのが2例目という代物だ。

PHSの開発言語はC言語だ。
組込み用に実行モジュールを小さくしないといけないためコンパイラはマイクロソフトやボーランドものは使えずアメリカ直輸入(商事会社経由)のDiabCというものを使う必要があった(当然初めて聞いた)。
価格は50万円、打ち合わせの最中にＰ社担当から伝えられたのだがこの値段に発注元もこの価格には空いた口が塞がらなかった。
後日、コンパイラを手にしたのだが、英語マニュアルのみで分からないことがあったら中継した商事会社が通訳してアメリカの担当者に問い合わせてその内容を返信するといったものだった。
なんだか面倒なのでマニュアルは英文をひたすら読んだ。
少々、パソコン用とは構文が違うところなどあり悩んだところもあったが通訳してもらうことなく作業できた。

PHSの画面の設計を行ったのだが、これは、非常に悩んだ。
裏ではTCP/IPで通信処理、それで受け取った電文を画面に表示する
一覧表示でページングや未読、既読などの機能を配置した。
当時の携帯メールのような画面を設計書に書いてみた。
書いてみたものの開発ツールは初めて使うし何ができて何ができないか良くわかってない。
絵に描いた餅みたいな設計書を作ってみたところ、これが、打ち合わせでOKになるから、時間稼ぎもできず作れるかどうかわからないまま不安を一気に抱えることになる。

加えてPHSは、TCP/IPの接続が切れたら再接続をして常につながっている必要がある。
PHSの小さい筐体に単純に複数スレッドが共存することになる。
というような困難を抱えてPHSの部分は開発を行った。

そしてPHSと通信を行うサーバー側はWindows NT上で動作するC/C++で開発を行った。
アラートを受信する通信部分、アラートをグルーピングしてPHSに送信する部分、PHSから既読の通知を受信する部分、PHSから接続されたり切断されたを管理する部分。
かなりもりもりだったが標準的な作りを心がけた。

でも難しい部分は多い、アラート送信中に切断された場合や未読の状態で切断された場合、再接続されたら直ぐにアラームとバイブを鳴動させないといけない。
などなどイレギュラーなケースが多い。
通信プログラムで完璧を目指すことは実に難しい。

これでPHSとサーバ側アプリはできた。
いよいよ結合テストである。

関西の仕事だったし(私は福岡)、第一PHSの交換機など簡単に用意できない。
大体、NTと交換機はどうやってつなぐ？
それはLanRoverを使う。当時、雑誌でそういうものがあるというのは知っていたのだが、実際に使用するとは思ってみなかった。LANの口とRS232Cがいくつかついた代物だった。
機器の設定に癖があり最初はかなり悩んだ。

そう、このシステム開発は悩み放しである。

さてNTとLanRoverをつなげた先はPHSの室内アンテナをつなぐ。
PHSを同時4台まで接続可能な電波を発する機械だ。
これでPHSと接続する。
と結合テスト環境が整ったことになる。

NT側のサーバアプリを起動した状態でPHSから接続を試みる。PHSの電源を入れるとPHSのアプリが自動起動されて接続を試みるのである。
PHSアプリと同じような動きをするアプリをNT上で作って事前にテストしていたので直ぐにつながった・・・んな訳がない。
LanRoverは曲者だった。説明書が難解でつなげるまでに一苦労だった。それでも半日くらいでつながったと記憶している。

そしてアラートを発生させる自作のドライバーからアラートを投げてみるとPHSに受信音とバイブがなり受信できた。しかし、画面表示などはいくつかうまく行っていない点もある。
そう、絵に描いた餅を実現するのは困難なのである。

しかし、Ｐ社担当者の方がPHSの開発ツールを熟知しておりメールのやり取りでいろいろ難問を解決することができた。
そして開発ツールの障害も結構見つけた(P社さん俺に感謝してくれ)。

とまぁ、かなりの苦戦を強いられてさすがに普通に働いていたのでは、締め切りに間に合わせる自信がなかったので寝袋持参で会社に寝泊まりしながら作り続けた。
アイデアが枯渇するか、眠気に襲われたらそく寝袋行き、夢で何か思い付くか目が覚めたらプログラミングとテストをしばらく繰り返した。

何とか完成して現地の工場へ…
工場は建設中だったのでところどころ工事現場をくぐってサーバー室へ。
おもちゃだったPHSの室内アンテナから交換機へ移行、PHSの数もテスト時の2台から10数台に増加。

新品のPHSを10数台開封して電池を付けてアプリをケーブルでつないで転送する。
1台転送するのに15分は掛かるので15分×14台＝3.5時間なのでこれで確実に半日がつぶれる。
これは、何を意味するかといえば、なにか問題があるとアプリの入れ替えに半日すっ飛ぶということである。
現在のiPhoneやAndroidのように回線経由で変更できればいいのだが･･･そんな手段はないケーブルのみだ。

初日は交換機も設置中だったので思ったように作業ができずに2日目に繋がったと記憶している。
さてテスト、PHSは床に並べてアラートをサーバーに送ってみた。
床のPHSが一斉にアラーム音とバイブで振動した。
発注元の担当者と一緒に床のPHSのアラームを両手で止めてまわった。
発注元の担当者もこのとき初めて動作したのを見た、絵に描いた餅がつき立ての餅になった瞬間だ。

テストのため100アラート連続発生などいろいろやっているとその騒がしさからギャラリーが増えた。
そうそう複数アラートが同時発生してもアラームは1回しか鳴らないようにするなど細かく作ったっけ。

日本ではこの仕組みの開発は2件目、LanRoverを通信に用いた例では日本初だった。

p.s.
同型のPHSです。
JRA(日本中央競馬会)が投票用のPHSとして開発。
こちらは2000年2月下旬提供なので、私の半年後に運用が始まったのね。でも直ぐに携帯サイトから投票できるようになりサービスは終了しました。
http://www.nttdocomo.co.jp/corporate/technology/rd/technical_journal/bn/vol8_2/041.html

同型のLanRoverです。
RAS(リモートアクセスサーバー)という分類でしたね。
http://www.flickr.com/photos/vibrant/525157217/