TOPPERSプロジェクトの中で、会費をお金ではなく身体で払うべき立場（特別会員）である私は、月に1回、コンポーネント仕様WGの打ち合わせのために名古屋にいっています。先週の火曜日もそうだったのですが、たまにはその話もしてみたいと思います。

まず "TECS" という名称についてですが、TOPPERS Embedded Component System を略したものです。TECSが目指しているものとして、公には次の3点が挙げられています。

1. 大規模アプリを効率よく開発できること
2. ソフトウェア部品の流通性がよくなること
3. 分散処理フレームワークが実現されること

これだけではあまりにも漠然としていて、何のことやらさっぱり分かりませんね。というわけで、私なりに勝手な解釈を付け加えてみたいと思います。

まず、1.の「大規模アプリを効率よく開発できること」についてです。最近では組み込み開発も大規模になってきていて、当然開発に携わる人数も増えてきています。そうなってくると、アプリケーションを部品に分割して、開発境界をはっきりさせる必要が出てくるわけです。TECSでは、コンポーネント図や記述言語を定義することで、そうした部品化がしやすくなります。

次に、2.の「ソフトウェア部品の流通性がよくなること」についてです。μITRONをはじめとしたリアルタイムOSでは、ソフトウェア部品の不足が問題になることがよくあります。TCP/IPプロトコルやファイルシステムなどは割りとあるのですが、GUIツールキットやUSBとなってくると、かなり選択肢が狭くなってきます。しかも、A社のファイルシステムとB社のGUIツールキットでは、相性がいまいちで組み合わせて使いにくかったりもします。そこで、TECSという標準化された枠組みが必要になるわけです。

最後に、3.の「分散処理フレームワークが実現されること」についてです。コンポーネント間の結合は、最も単純な関数呼び出しによるものから、タスク間通信によるもの、シリアル通信やTCP/IPなどによるもの、更には専用ハードウェアの制御を伴うものまでさまざまです。タスク間通信といっても、普通のスレッド形式のものもあれば、メモリ保護カーネルやマルチプロセッサ・カーネルのようなメモリ空間を共有できないものではプロセス間通信に近くなります。汎用の分散フレームワークでは、最も汎用性を高めるために最も重いものにあわせて動的に処理しますが、TECSでは静的な最適化を行うことで、関数呼び出しで済むものは関数呼び出しにというように、最も適した接続方法を適用することができます。

とまあ、こんな風に書いてもよく分かりませんね。興味のある方は一度WGに参加してみてください。会員しか参加できませんが、準会員であれば入会金・年会費とも5,000円でOKのようです。
WGも最初のうちは大勢で打ち合わせをしていたのですが、現在では大体6,7名程度になってしまいました。来るもの拒まず、去るもの追わずという言葉がぴったりな雰囲気です。万年マンパワー不足ですので、冷やかしでもよいので参加していただくと助かります。