ETロボコン　チャンピオンシップ大会レポート

連載 :

2011年12月27日(火)

見応えのあるモデルたち

ETロボコンでは会場に参加チームのモデルが貼り出されます。チャンピオンシップ大会でも参加52チームのモデルがびっしり貼り出されている様は圧巻でした。ここでは、モデルに書かれていたキーワードをご紹介します。「モデルを使った設計図」の範疇を超えて、開発プロセスや開発ツール、要求モデリングなど、組込みの開発現場でもそのまま使用できるような実践的な内容であることが分かります。

表1：モデルで使用されていたキーワード

キーワード	内容
DSL	Domain Specific Language。対象のドメイン（分析対象の領域）に特化した記述方法を定義して、モデル化すること。そのドメイン特有の情報、制限を記述することができるので、設計段階での考慮漏れを減らすことができる。また、ドメインに特化したモデルになるので、可読性も高まる。
DSM	Domain Specific Modeling。DSLを用いた設計手法。
FMEA	故障モード影響解析。故障や障害の種類（故障そのものではない）を故障モードとして定義する。各故障モードが発生した場合にシステムにどのような影響が発生するのか、ボトムアップで解析すること。
FTA	故障の木解析。故障がなぜ発生するのかを解析する。解析には木構造を用いて故障の理由をトップダウンで解析する。故障の発生条件が複合する場合は、木構造中に論理式を用いて表現する。
ISO/IEC9126	要求分析段階での漏れをなくし、品質の高いソフトウェアを作成するための、品質特性と品質副特性を定めた国際規格。
LTSA（並行性）	モデル検査ツール。FSP形式（数式に近い）で記述したモデルで、状態遷移図を作成できる。また、手動で状態遷移の検証が行える。
PFD	プロセスフローダイアグラム。業務プロセス（開発プロセス）の手順をDFDを用いてモデル化したもの。
QFD（品質機能特性）	品質特性（縦軸）と要求（横軸）の関連を表にして表すことで、要求と品質の重要度が明らかになる。これを用いて設計品質を検討する手法。
SPIN	モデル検査ツール。手続き型言語のPromela言語を用いてソフトウェアシステムをモデル化し、 LTL（線形時相論理）を用いた検査式で動作の整合性を検査することができるツール。並行システム上での動作の検証に用いられることが多い。
SysML 内部ブロック図	システムの構造を表す図。システムを構成する部品をブロックとして表現し、各ブロックの繋がりを線で表す。ブロック毎の関係も示す。ソフトウェアだけに限らず、ハードウェアや人も対象となる。
SysML 要求図	SysML言語による要求を記述するための図。要求（または制限）を満たすための要求を抽出していくことで、要求を詳細化する。抽出された各要求は関係を線で結び、どのような関係があるのかを記述する。機能と非機能を同じ図で扱うことができる。
TM	トレーサビリティマトリクス。要求（横軸）がどこの箇所（縦軸）で実現できているのかを、記述する表。
USDM	品質特性や要求を階層的に抽出して、最下層で要件を抽出する要求分析方法。
フェールセーフ	システムに障害が発生した場合に、それによる影響を最小限にするための設計手法
フェールプルーフ	システムで障害そのものが発生しないようにする設計手法
安全性解析	システムが危険な振舞いをしないか解析する
可変部と固定部	可変部は将来仕様変更の可能性がある部分。固定部は将来仕様変更の可能性が少ない部分。分けて開発することで、機能の追加を行いやすくする。
非機能要求	機能的な要求以外の要求のこと。満たすべき性能やハードウェア、制限などを記述する。例：信頼性、開発言語など
並行性設計	マルチタスクOSにおいて、同時に実行するタスク実行周期や共有リソースの設計を行うこと。

[舟元] うーむ。当然だけど、どこもすごくレベルが高かったよ。モデルの基本となる要求、分析、構造・ふるまいの設計結果が全て書かれているのは当たり前。そこにプラスアルファで各チーム独自の取り組みを載せていたりしてね。
[吉田] 地区大会の私たちのモデル、フレーム部分はよく書けているけど、アプリケーションドメインが不足しているということで、評価悪かったよねー。基本を押さえたうえで、プラスアルファに挑戦するようにしないと、チャンピオンシップ大会出場は難しそうね。
[舟元] プラスアルファの部分では各チーム個性を発揮していたよ。大きく分けて要求抽出部分、要素技術部分、検証部分のどれかがプラスアルファ部分になっているチーム多かったように思う。
[吉田] 特にどの部分を強化すると評価が高い、という傾向やトレンドはあったの？
[舟元] 自分には分からなかった。でも、「競技で確実に勝つ」という目的のために、妥当性のある取り組みを行ったことがわかるモデルが高い評価を受けているように見えたよ。
[舟元] あと、個人的に「凄い！」と思ったのは、ロボットを吊ったワイヤーをマイコンで制御して、「走行→定位置まで移動」を繰り返して、難所を複数回検証するための動作を自動化している取り組み。
[吉田] 検証のために何回も走行させるのは大変だもんね。効率良く開発するためには自動化させるのが一番。合理化だね！
[舟元] うちはまず、基本をしっかり押さえたモデルにしよう！