[openrtm-users 00700] Re: RTCProfileのver0.1仕様書

2008年 12月 15日 (月) 19:43:59 JST

末廣様

安藤です

ご意見ありがとうございます。


> RTCの仕様記述を類別すると以下のようなものになると考えています。
>
> 1. 外部から使うための記述
> 1-1 基本（PIM、アプリ非依存）
> 1-2 拡張１（PSM、OpenRTM拡張、アプリ非依存）
> 1-3 拡張２（アプリ依存）
> たとえば、RTSystemEditorとかRTSpaceMonitor(今はないけど)、
> RT作業プログラムシステム(今はないけど)、など
>
> 2. 実装のための記述
> 2-1 実装ツール非依存、アプリ非依存
> 1-1、1-2
> 2-2 実装ツール非依存、アプリ依存
> 1-3（RTSystemEditorでのPortの表示位置など）のように
> アプリ依存だが実装非依存なもの
> 2-3 実装ツール依存
> DataPortの変数名など
>
> 1-1、1-2（2-1）はOpenRTMにおけるRTC仕様記述として
> まとめても良いと思います。（これが改め基本かな）
>
> 1-3（2-2）はアプリ用ですので、たとえばRTSystemEditorにおける
> RTC記述として限定するべきでしょう。RTC仕様記述方式として
> 一般的に定めるのは疑問が残ります。
> （これを拡張と呼ぶなら、いろいろなアプリに拡張できるような
> メタな決め方にしておく必要があるのではないでしょうか）

｛外部利用|実装｝｛基本|拡張｝｛実装ツール非依存|依存｝｛アプリ非依存|依存｝
の組わせで考えよということでしょうか？
この分け方だと分類は奇麗なのですが、実際に仕様記述を何に使用するか
といった観点がいささかぼけてしまうような気がします。

仕様書の一番後ろを読んでいただければわかると思うのですが、
RTCProfileを策定する時点では、

- RTC仕様記述フォーマットとしての利用
- コード生成のための情報として利用
- システム構成時に利用
- RTCリポジトリにおける検索情報として利用
- 既存仕様の再利用
- ドキュメントとして利用

といった利用方法を想定して仕様を考えてあります。
＃他の利用方法も考えられますが、キリがないのでこう決めました。

そこから、
・RTCの本質的な情報：Basic Profile
・ドキュメント情報：Doc　Profile
・ツール等で利用する拡張情報：Ext Profile
の3つに分割しました。

Basic Profile はRTCを外部から見たときどのように見えるかといった情報が含まれます。
OMG RTCからは多少情報は増やしてありますが、これはOpenRTM-aistの仕様に
合わせてあるためです。
上記の利用方法では基本的にこのBasic Profileのみで足りると思います。

ただし、ドキュメント記述に関しては、文書を記述する関係から、
Doc Profileとして、別パッケージとして分離しました。

それ以外の仕様でかつツールに依存する要素はExt Profileに分離しました。
特に、ツールに対する要望をできるだけ取り入れ、かつ本質的な情報と混じらない
ように切り分けるためには、Ext Profileがどうしても必要となってきます。
ツールといっても現状存在するツールはRTCBuilderとRTSystemEditorで、
RTCDebuggerやRTRipositoryもできつつありますが、こちらの手元にはないので
これらのツール用の情報は明示的にはまだ含まれていません。
（ツール作者からご意見は伺っていますが。）

ただ、RTCBuilderやSystemEditor用の情報は他のツールでも使えるかも
しれないので、仕様書に文書として明記ししました。

> 2-3はどうでしょうか？完全にOpenRTM-aist(C++版)とRTCBuilderに
> 依存することになります。
> DataPortの変数名のようなものを標準的に含めようとするならば
> その前にRTCの実装側およびプロキシ側の言語マッピングを
> 定める必要があると思います。

今のところ、OMG RTCにもOpenRTMにも、実装側のAPI標準というのは
ありませんし、美しい標準を目指すのであれば、仰ることはごもっともです。
しかしながら、現状OMG RTCの実装は、C++、Java、Python、.NETともに
1種類づつしかないので、API標準まで決める必要性は感じません。
また、RTCProfileとAPIのマッピングはまた別の問題だと思います。

＃私個人的の中でのプライオリティは
＃「使いやすくちゃんと動く実装」＞「美しく標準に沿った実装」
＃です。標準化はメリットもありますが、時間も手間もかかりますので。。。

なお、変数名は拡張プロファイルですので、先ほどのメールにも書きましたように
どのツールがどのように使おうと自由です。したがって、コードジェネレータが
使うも使わないも自由です。
「もしvarnameがあれば、ジェネレータはその値を変数名に利用することができる」
程度の意味で、かつ
「varnameはもしかしたらないかもしれないので、その時はジェネレータが考えて変数名をつけてね」
という意味でもあります。

実際、これまでのRtcTemplateではポートの名前を使用し、
変数名には：m_portname, ポートオブジェクトインスタンスは：m_portname(In|Out)
のようにしています。
ただ、これが気に入らないとい方もいたので、別名を与えられるようにしたまでです。

> 現状のver0.1仕様書では上記のような区別が不十分に
> 見えますがいかがでしょうか。

現状、これらの仕様に準拠した形でRTCBuilderとRTSystemEditorが
両方とも動作し、連携できているので仕様的に不整合がある等の問題は見つかっておりません。
区別についても、上記の理由、つまり「RTCBuilderとRTSystemEditorの間の連携を行うため」
という目的においては、現状の区別で不便はとくに感じていません。

もし他のツールがこのRTCProfileもしくはRTSProfileを使う上で、
必要な情報が含まれていないといったご要望があれば次のバージョンで
改善したいと考えています。

ちなみに、この仕様書はOMGフォーマットでPIM、PSMが記述されていますが、
これをそのままOMGに持っていくわけでも、その予定もありません。
＃もしそういう機会があれば、参考にはするかもしれませんが。。。

もし持っていくとしても、DocとExtは標準仕様化するのは結構難しいと感じています。
RTCProfileとRTSProfileはあくまでBuilderやSystemEditorなど、今あるツールを
連携させるための仕様です。

以上をご理解いただければと存じます。
-- 
安藤慶昭＠独立行政法人産業技術総合研究所 研究員
                   知能システム研究部門 タスクインテリジェンス研究グループ
                   〒305-8568 茨城県つくば市梅園1-1-1 中央第2
                   TEL: 029-861-5981 FAX: 029-862-6631
                   n-ando ＠ aist.go.jp, n-ando ＠ ieee.org