Vol.3 No.3 2010

35/84

研究論文:複雑システムの信頼性を向上させる開発手法(加藤ほか)−211−Synthesiology Vol.3 No.3(2010)コメント(赤松 幹之)協調動作に関する評価の観点の設定方法、協調動作が満たすべき性質の抽出方法、安全性の考慮の方法などが書かれていませんので、例えばロボット技術者がこれを使えるかどうかが分からないと思います。ロボット関係者がこれを使ってみようと思う手掛かりとなるような説明があることが望まれます。回答(加藤 淳)本論文では構成要素の協調動作を "システムの構成要素における処理がインタフェースを介し、他構成要素の処理と連携すること" と定義いたします。協調動作の整合を "システム仕様に対し構成要素による協調動作が正しく行われていること" と定義いたします。また、協調動作の不整合を "協調動作の整合の定義を満足しないこと" と定義いたします。本論文の1章では、これらを加筆いたします。協調動作に関する評価観点については、協調動作に関連する仕様および協調動作が満たすべき性質を基に設定します。適用事例における測定サブシステムおよび統合制御サブシステムについては、協調動作に関連する仕様からメッセージおよび処理の抜けが懸念されました。また、協調動作に関連する仕様および協調動作が満たすべき性質の中に、100 ms以内などの時間的な制約やメッセージおよび処理のタイミングに関する仕様が存在しました。したがって、4.2節で示す二つを評価観点として設定しました。5章2節2項では、これらを加筆いたします。協調動作が満たすべき性質は、システム仕様とそれをブレークダウンした構成要素仕様との対応関係がまとめられるトレーサビリティマトリクスを用いて抽出します。また、協調動作における安全性の確認については、この研究の課題です。安全性とはシステムが決して悪い状態に到達しない性質を指します。"システムとして悪い状態" をもれなく識別することが困難であるため、協調動作における安全性の確認に漏れが生じる可能性は否定できません。本開発手法に対しFault Tree Analysis(FTA)などのような安全性解析手法を組み合わせることで、本課題の解決策を検討する予定です。議論3 技術の選択質問(上田 完次)「IEEE 1220に従い・・・」のような表現が多数見かけられます。この研究で開発されている手法との関係はどうなのでしょうか。また、なぜIEEE 1220を採用したのか、根拠も明確ではありません。コメント(赤松 幹之)システム設計技術にアーキテクチャ設計以外に何があるのか、同様にアーキテクチャ設計としてIEEE 1220以外に採用しなかった技術についても記載してください。さらに、数あるアーキテクチャ設計手法の中からIEEE 1220を選択したシナリオを明確にするために、他の手法にはどのような欠点があるのかが記載されていると、理解しやすいと思います。モデル検査とは、システムの遷移状態を表すモデルに対して網羅的に検証する技術と1章に記載されていますが、ここで用いられたモデル検査手法はこの研究で独自開発されたものか、既に開発されていたものを適用したのかが分かるように記述をお願いします。モデル検査ツールとして有限オートマトンベースの検査ツールを選定したとあり、そのメリットが書かれていますが、それ以外のツールとして何があって、それらの欠点が何であるかも書いてください。同様にUPPAALの選定についても、もし他の候補があったのでしたら、その点も記載してください。回答(加藤 淳)この研究では既に有効性が認められている技術を選択し、高品質な開発手法を効率よく確立する研究方針を採用しています。本開発手法を構築するにあたり、有効性が認められ標準化されているアーキテクチャ設計手法を適用しています。アーキテクチャ設計手法以外の代表的なシステム設計技術として、構造化分析・設計手法があります。アーキテクチャ設計手法はデータやサービスなど特定の技術要素を中心とするシステム設計には不向きであるものの、特定の技術システムには依存しない汎用的な設計手法です。したがって、この研究ではシステム設計技術としてアーキテクチャ設計手法を選択しました。また、アーキテクチャ設計手法が規定される代表的なシステムエンジニアリング標準として、ISO 15288、ANSI/EIA 632、IEEE 1220がありますが、IEEE 1220は各プロセスにおける作業および手順が詳細に規定されていることからIEEE 1220を採用しました。本論文の3章では、これらの比較について記載いたします。モデル検査は検証技術として既に確立されている技術です。1980年代初頭より研究が開始され、近年、ソフトウェア開発では普及が進んでいます。モデル検査は "モデルを用いた検査" なのですが、検証技術の固有名詞になっています。本論文の1章ではこれらを加筆いたします。モデル検査以外の代表的なシステム検証技術としてテスト手法およびシミュレーション手法がありますが、モデル検査は状態遷移については満たすべき性質が成り立つかどうかを網羅的に検証することができます。したがって、この研究ではシステム検証技術としてモデル検査を採用しました。本論文の3章ではこれらの比較について記載いたします。また、形式手法の中には定理証明という検証技術があります。定理証明とはシステムの仕様や設計を意味論が数学的に定義された言語で記述し、厳密な証明を与える手法です。定理証明はシステムに対する厳密な検証を可能としますが、人間と対話的に証明を進める部分があり多くの労力を要します。定理証明について、現状、筆者らは産業界では適用され有効性が認められているとはいい難い検証技術と考えます。したがって、この研究における検証技術の候補からは除外しました。モデル検査の種類には代表的なものとして、有限オートマトンおよび有限オートマトンを拡張した時間オートマトンがあります。適用するモデル検査およびツールは、評価対象の特徴に応じて選定する必要があります。外部からのイベントをトリガとして状態が遷移するような一般的な状態遷移を評価する場合には、有限オートマトンに対応したモデル検査ツールを選定します。代表的なモデル検査ツールとしてSPINがあります。時間制約を含む状態遷移を評価する場合には、時間オートマトンに対応したモデル検査ツールを選定します。代表的なモデル検査ツールとしてUPPAALがあります。有限オートマトンに対応したモデル検査で確認できる対象は、時間オートマトンに対応したモデル検査ツールを用いても確認することができます。しかし、その逆は成り立ちません。本論文の4章では、これらを加筆いたします。また、今回の適用事例では、協調動作として時間的な制約を評価する必要がありました。また、時間オートマトンに対応したモデル検査ツールについて、産業界の実例に対して適用可能な品質を有するのは、現状はUPPAALのみと筆者らは判断しました。議論4 成果の産業応用コメント(上田 完次)この研究の実例の成果が、実際の産業応用にどのように使われたのか、あるいは、使われる見通しがあるのか、その際の適用限界などについて言及されると、第2種基礎研究として意義が高まると思います。コメント(赤松 幹之)この研究の重要なことは、この手法が産業界などで実際にシステムを開発している人達に使われることだと思います。その意味で、この成果を活用できる対象はどういったシステムなのか、この手法の適用範囲についての説明が望まれます。また、この手法を広めていくための方策などについてもお考えのことがあれば記載してください。回答(加藤 淳)この研究における開発手法は、特定の技術システムに特化しない、

※このページを正しく表示するにはFlashPlayer9以上が必要です