ブログ

CATIA Magic Tipsブログ:複数組織の開発体制における課題解決へのCATIA Magicによるアプローチとは?

電通総研では、SysMLに準拠したモデリングツールとして、ダッソー・システムズ社製のCATIA Magicを取り扱っています

本テーマでは、アーキテクチャ設計のフェーズにおいて、CATIA Magicで効率的にシステムI/Fの整合確認を行う方法について御紹介します。

複数組織の開発体制における一貫性のない設計

システム開発の体制がOEMとサプライヤーといった複数組織で構成されている場合、開発プロセスとしては、サブシステム毎に異なるサプライヤーが設計を実施し、OEMがその設計結果を1つのシステムに統合していくことが多いかと思います。その場合、各組織が担当する設計領域間のI/F整合を取る必要がありますが、その際の整合確認が非効率に行われていると、全体としての設計の一貫性を保つことが難しくなります。(図1)

図1. 現状の課題

例えば、各サプライヤーの設計IF情報をドキュメントで一覧表として管理している場合、OEM側でそれらの表をマージして手作業により整合確認することとなり、不整合の発見漏れを起こしてしまう可能性があります。

CATIA Magicによる解決策 -ValidationRule/ActiveValidationRule-

もし、各サプライヤーの設計領域間のI/F整合確認を自動化することができれば、確認作業の時間を短縮し、設計の一貫性を保つことができます。このような方法は、CATIA MagicのValidationRule/ActiveValidationRule機能を用いることで実現することができます。

ValidationRule/ActiveValidationRule機能の強み

以下に機能の強みについて記載します。

  • I/F不整合を起こしているモデル要素を自動検出
    システムモデル上のモデル要素を検査し、設定した整合条件に沿って、I/F不整合を起こしている要素を早急に自動検出します。
  • 自由な整合条件による整合確認が可能
    モデル要素の整合状態を判別する整合条件はユーザ側でカスタマイズして自由に用意することができます。そのため、任意のモデル要素を、不整合を起こしている要素として検出することができます。
    また、整合条件が異なる複数の検査を同時に走らせることも可能です。
  • 検出要素から不整合の内容を早急に把握可能
    不整合の重大度合い(warning、error、fatalなど)やエラーメッセージなどを不整合ごとに設定することができます。そのため、検出されたモデル要素がどのような不整合を起こしているのか早急に把握することができます。
  • 複数の検出結果を一覧表示
    不整合として検出されたモデル要素は検出結果画面に一覧表示されます。また、設定した不整合の重大度合いやエラーメッセージなどもテーブルの列に表示されます。
  • 検出要素をダイアグラム上で確認可能
    検出されたモデル要素は、用いられているダイアグラム上でハイライトされます。また、ハイライトの色は重大度合いごとに異なって表示されます。そのため、ダイアグラム上で周辺の関連要素を確認しながら、効率的に設計を修正することができます。

実際に、CATIA Magic画面を用いて説明したいと思います。ここでは例として、ValidationRuleを用いて以下の2つの要素を検出するケースを挙げます。(図2)

    1. 名前が設定されていないPart
    2. コネクタ接続先のPortと同一の多重度が設定されていないPort

図2. ValidationRule機能による不整合検出

この例では、整合条件を2つ用意し(青枠)、それぞれの検査を同時に走らせることで、異なる不整合を起こしている2つの要素を同時に検出しています。

図2より、検出された要素が検出結果画面(赤枠)に一覧表示されており、生じている不整合の重大度合い(Severity列)やエラーメッセージ(Message列)が関連表示されていることが分かります。また、これらの要素は用いられている内部ブロック図上でハイライトされていることが分かります。①の不整合の重大度合いをwarning、②の不整合の重大度合いをerrorとしているため、検出されたPartは黄色、Portは赤色にハイライトされています。(以下の動画も確認ください。)

ここでは簡単な不整合の例を挙げましたが、より複雑な整合条件を用いることで、他にも様々な整合状態の確認を行うことができます。

ValidationRuleとActiveValidationRuleの違い

ValidationRuleとActiveValidationRuleの大きな違いは、検査対象と検査タイミングです。それぞれについて、以下にまとめます。

  • ValidationRule
    • 検査対象:コンテイメントツリー上の全要素
    • 検査タイミング:手動操作による検査開始時
  • ActiveValidationRule
    • 検査対象:表示中のダイアグラム上の全要素
    • 検査タイミング:ダイアグラムを表示中の間、常に検査している

ValidationRuleは、手動操作によりコンテイメントツリー上の全要素を検査し、その時生じている不整合を検出します。一方でActiveValidationRuleは、表示中のダイアグラムを常に検査しており、生じた不整合をその都度自動検出します。そのためActiveValidationRuleを用いることで、ダイアグラムを作成しながら、並行して整合性を確認することができます。

なお、ActiveValidationRuleの検査対象はコンテイメントツリー上の全要素に設定することもできますが、コンテイメントツリー上のデータ量が多ければ、CATIA Magicのパフォーマンスが落ちるため注意が必要です。

開発プロセスにおける活用案

実際に複数組織で開発プロセスを進める場合には、OEMとサプライヤー間でシステムモデルを共通化することで、モデル上でI/Fの整合確認を自動化することができます。(図3)

例えば、まずOEMが対象システムの概要をダイアグラムで作成し、それぞれの担当領域のみ編集できるようにした上で、各サプライヤーに展開します。その後、各サプライヤーは展開されたモデルを具体化していき、担当領域の設計を行います。そうすることで、ValidationRule/ActiveValidationRule機能により効率的にI/Fの整合確認を行い、不整合の発見漏れを防ぐことができます。

設計したシステムモデルのI/F情報は、GenericTableを用いて一覧表示すれば、CATIA Magic上で表として管理することもできます。(GenericTableについては、「要求の影響範囲の確認を効率化」をご覧下さい。)

図3. CATIA Magicを用いた複数組織における開発プロセス

最後に

本テーマでは、複数組織でシステム開発を行う上でのI/F整合の難しさを背景に、解決策としてCATIA MagicのValidationRule/ActiveValidationRule機能を御紹介し、その強みと実際の開発プロセスにおける活用案についてまとめました。

今回のように、従来のドキュメントベースではなく、モデルベースで設計情報を管理することで、今まで多大な時間を当てていた非効率な作業を"自動化"することができます。"自動化"はモデルベースのメリットの1つであり、CATIA Magicは他にも様々な自動化機能を有しています。それらの機能紹介も随時掲載していきますので、もし今回の内容でCATIA Magicにご興味をお持ちいただけましたら、ぜひそちらもご覧下さい。


本記事は役に立ちましたか?コメント・問合せも承ります。


関連セミナー