業界独り言 VOL374 ETロボコンという教育スタイル

工学院大学で行われていたETロボコンの東京地区大会会場を訪れた。組み込みソフトウェア開発のスキルを競う、モデル設計のレビューと実践性能での検証をかねた形の実践でもある。参加者の対象は、組み込みソフトウェアの会社あるいは、エンタープライズ系からの移行組、またはオブジェクト指向を学ぶ学生あるいは一般・・・。LEGOのMINDSTORMで出来たNXT走行体という共通仕様のロボット群を駆使して、ソフトのみを純然と書き込みトライアルコースを正しくトラックして、あるいはその中のトリッキーなポイントを技を駆使して走らせるということになる。

ちなみに、今年から適用されている新しい走行体は、NXTというもので二輪自立走行するタイプのAppleのあれに近い。さぞや制御が難しいかと思うと、必要な制御機能はドライバーとしてライブラリ提供されているようで、いわゆる技を駆使する点というとライントレースと動輪制御とセンサーからの情報認識ということになる。実態としてコース上に設置されたさまざまな課題に対してどういった戦略で臨むのかということがソフトウェアのモデルとして求められる。その意味では、組み込み制御という観点でのドライバーを開発するといった点が薄まるようにも思えるが一般にドライバー開発に重点を置かれるよりもUIとしての機能期待値に向けた実装で解決しようということなのかも知れない。

実際に高校生のグループやら、専門としてOOPなツールを開発提供しているソフトハウスなどの参加者までがいた。プロがツールでコード生成までも駆使しての実装デモをするようなチームもいれば、一生懸命UMLを勉強してソフト開発を学んでいる学生までさまざまでコースを取り巻く観客席の外側には、各チームが開発したモデルのソフトウェアの工夫がUMLベースで展示されていた。MINDSTORMの実態としては、ARMが載っているようなのだが、実装可能なコードはCまたはC++らしい。昨年までの走行体のモデルではJavaもあったようなのだが、二輪自立制御の処理が追いつかないからか、Javaの適用はないそうだ。

 

仕事の合間をみて、仕事では取り組めない新しい技術に挑戦してもらいたいという業界の流れと、実情としては、そうした技術を定常的には使っていないというギャップがこうした活動をある意味教育として提供しているのだと思う。ただし、完全走行もままならないような状況が続くこうしたコンテスト?コンクール?といった状況は課題が難しすぎるのか、モデルベースでの設計をさせることで問題となっているのかは別にしてもお粗末ではないのか。確かに良い設計 で、スマートに制御されていくものを見て学ぶということが期待値であり、設計を志す者たち同士でのワークショップや懇親会に力点があるということかも知れない。

二兆円市場を支える、エンジニアたちの祭典の出し物としては、今後の日本を支えるスーパースターが登場するという期待値でもなく平均点をあげる底上 げが目的なのだろう。ドライバーレベルにも別次元で取り組み協会提供のライブラリを使わずとも高性能を達成する。そんなチューニング提供するようなクラス の登場も待たれるような気がするのは期待しすぎなのか。ある意味無差別級なコンテスト?ではあるものの提示している環境で制限をしてしまっているのは残念 な気がする。無論、共通のハードを簡易に提供するというくだりで考えていくと管理運営も難しくなってしまうのはやむなしか。

まともな設計をさらりとこなし、ロボットがスムースな身のこなしで技をクリアしていくということでソフトハウスの技量も評価されるという意味では、 よい広告塔になるのかも知れない。先日若手学生にアセンブラベースでのシステム開発の感激を味わってもらいたいと送った寄付金も、MindSTORMの ETロボコンに向けた追加の寄付を考えても良いのかも知れない。

業界独り言 VOL373 組み込み技術(ET)の深みに嵌って

1999 年7の月から始まったローリングストーンのような展開に転がり続けて10年の節目となった。いったいいつからこの仕事をしてきたのかと思い返す。すると体 験してきた様々なエンベッデッドな仕事が実は関連してきたのかと思うような感覚に襲われたりもする。見知った見知らぬ世界に飛び込んで実は孫悟空が飛び 立った釈迦の掌の中での10年だったのかも知れない。ここまできたぞとマークをしてみても、デジャブのような無力感にさいなまれたりもする。仕組みを理解 しようとしない世代の人たちが最前線で仕事をしている日本の組み込み業界の怖さを見るにつけ、進化したのか劣化したのかと悩んでしまう。

理想を追い求めようとしてもビジネスとしての昇華を果たしつつという流れが、邪魔はしないまでも足かせになったりはする。湖上に敷き詰められたとい うよりは浮かべた茣蓙の回廊を走って渡り切るといった達人の映像をみた。常人では5メートルも進めずに湖水に消えてしまうのだが、50メートルあまりの水 上の回廊を走り切り、船にタッチをして、岸辺まで帰ってくるという。この技に到達するには、20年の鍛練が必要だったという。ソフトウェアの世界において は、どんな鍛練でいったいどんな能力が身につくというのだろうか。突然いろいろな現象からの推定の結果がシナプスとしてつながりゴールに到達するといった 感覚もそうしたものの一つかもしれない。

インド人やフランス人など様々な人種の仲間たちと一つの仕事を通してお客様に開発支援というビジネスを展開していくと、コミュニケーションの障害と なるの互いの文化、慣習といったものだったりもする。相手が違う感性の人種であることを理解した上での共同作業をしていくということが必要だと達観するに は数年を要したと思い返す。ベンチャー創業して25年を迎える会社と比較したりもしつつ何をしていたのかを回顧する時間は最近の重要な時間でもある。週末 には、ETロボコンの東京地区大会の観戦にいくことになった。ET技術の中での取り組みということでこじつけてみても楽しみである。

ET8200という機種名で開発してきたのはザイログのZ80ベースのマイコンボードシ リーズであり、16ビットな空間をアセンブラベースで開発していた。ライバル機種はなにかといえば、ACOS450シリーズというNECのコンピュータシ ステムであり嵐の中を突き進むなんとかドンキホーテとサンチョパンサのような無謀な戦いだったのかといえばお客様に必要な機能は提供しつつ競争には打ち 勝ったというシステム開発だった。アセンブラベースでネットワークでブートをして共有DBを照会する日本語表示のシステムを開発したのは、無線機のビジネ スを勝ち取り、お客様の問題解決に必要なシステム構築するというテーマでもあった。

イベント駆動でトランザクションが交換可能な複数ユニットが通信できるバス接続のシステムを作ったのは、実は100人余りの設計人員を投入して御三 家の電子交換機開発に対抗した分散処理型の電子交換システムの開発を横目に見ていたからかも知れない。既成のHPIBのデバイスを用いてZ80とDMAの 組み合わせで開発した分散処理システムは確かにACOS450で構築したRDBのシステムを凌ぐ性能を叩き出してはいた。違いがあるとすれば、ITの方々 が独自に開発しうるようなシステムではなく作りつけ機能に固執したことがあるだろう。お客様のジャーナル処理が実際には最も性能が出ない構成になったの は、当初のシステム性能比較あるいは設計時点で想定していなかった機能だったからでもある。

当時は、Z80でアセンブラで開発していれば出来ないものは、無い・・・ぐらいにとらえていたかも知れない。一年ほどの開発期間で照会系アプリの開 発や、システムを構成するRTOS、ドライバーの開発などを行いGDCを駆使して漢字表示をグラフィックスで実装したりしていたのは、少し国民機と言われ たNECのパソコンの少し前のことでもあった。デバイスはほとんど国産パソコンのような様相で作成した専用システムだった。そしてこれを仕上げてしまっ た、このベンチャー気風の漂うチームでの取り組みには確かに勢いがあった。TRONとは似つかない馬鹿なコーディングを許さないといったポリシーのデザイ ンには、設計したコード自体が他人を慮って最高の条件で動作するということを自然と実現するような流れだった。

ただし、プロの集団での作業とはいえアセンブラーベースでの開発や、Unixではない開発環境で大規模な開発をしていくのには構成管理面では、まだ まだ大変な時代だった。バッチで注意深くアセンブルジョブを消化していくという流れは、のちのUnixの登場でmakeにより解決されるのだが、これはま だアセンブラーベースの大文字の時代である。リアルタイムトレースを使いトランザクションの流れをモニターしつつシステム構成での展開テストを駆使してい くのだが光ファイバー接続で高速UART接続を76.8kbpsで実現してみても複数回線をポーリングしながらサービスするよりも結局4800bpsで同 時4ライン接続をするほうがシステムとしては高速な動作となった。

データベースというにはシンプルなハッシュ検索による直接編成のハードディスク構成にはテストデータを用いたプロトタイピングをすることも必要だっ たが実際に使ったのは自前のFM8でのベーシックコードだった。640*400のスクリーンのピクセルをHDDのレコードに見立てると当時のディスク容量 に匹敵するテスト環境が構築できたので、ハッシュ衝突がどの程度起こり、差し替えといった処理をする必要があるのかということを試行確認してピクセルの色 が変化していく様をモニターしたりしていた。システム開発の責任がすべて自分たちのチームにしかないという切羽詰まった環境でようやく目鼻がつきだしたの は結婚式の少し前だった。しばらく婚約者にもコンタクト出来ないような状況ではあったがエンジニアとしての暮らしはそんなものだろう。

披露宴会場への祝電には、「あなたのソフィアが待っています」と意味深な電報があったのだが、細君やその友達の誤解はあれども、デバッガベンダーの 名前に過ぎなかった。デバッガーと戦っていた・・・そんな時代だった。そのくらいアセンブラーベースの開発は大変なものではあったが開発環境の向上も手 伝って1年あまりで、コンピュータリブレースを実現するほどの規模を作りうるような時代になっていたのは確かだった。もっと実機ではなく開発マシンの上で 評価や開発がしたいという思いに至るには、失敗の経験が必須だった。

システムは完成して、実際の展開テストで中部地区のお客様に納品したのだが、稼働していたNECのコンピュータを撤去して戻れぬ決勝戦といった緊迫 した中で1週間ほどの稼働を見守った。このシステムが繋がる無線センター卓を通じて、宅急便の集荷指示が名古屋の空を電波で飛んだのである。当該車両に積 まれているプリンターにお客様の注文データが印刷されたのである。本来の私がしていたのは、端末側の開発だったのだがシステム開発に借りだされての仕事 を、好奇心いっぱいにやらせてもらった貴重な体験でもあった。

このシステム開発後に、上司として加わったのは米国での先進開発スタイルでのプロジェクトを経験して、志半ばで戻ってきた寡黙なエンジニアだった。 このシステム開発を稼働後の拡張などに没頭している私に声をかけたのは、Unixベースでの開発を経験してきた上司からの小文字世界の誘惑だった。商品開 発としては完了したので、先進工事を進めるような仕事屋としては、次の好奇心の対象に飢えてきていた。技術トップの想いも手伝い、VAX11が導入されて 4.1BSDが導入されるにいたり、端末開発をC言語でやらないかという悪魔の囁きと契約を結んでしまうことになるのは、エンジニアの性だったろう。