本ページは、2023年11月28日に実施したセミナー「欧州最新事例とサステナブルMBSEの実践方法」の中で「欧州MBSE最新事例」としてご講演いただきました、オーストリアのPalfinger社のZingel氏による事例講演セッションに対して、参加・視聴された皆様から寄せられましたご質問とそれに対する回答を一覧記載したものです。
| 質問 | 回答 |
| MBDや1DCAEの考え方も取り入れているかと思いますが、設計者自身にこういったツールや手法を取り入れさせるためにどういった取り組みをされたのか、非常に関心があります。 | 我々の目標は、これまで当社のトップスペシャリストの頭の中にしかなく、また、コンピュータ処理可能なデータベースとして存在していなかったエンジニアリング関連情報のトレーサビリティを実現することです。異なる種類のモデル間での情報の追跡と変換を大幅に容易にし、また、促進するための重要な前提条件である整合の取れたデータ構造の確立に取り組んでいます。残念ながらドメイン設計固有のシミュレーションモデルの組み込みはまだ始まっていません。 |
| 具体的なダイアグラムの使い方や事例も多く、参考になりました。ご紹介いただいた開発プロセスのモジュールレベル（L3）までがiQUAIVSでの対象でしたが、コンポーネントレベル(L4)とは具体的にどのようなつながりを持たせているのでしょうか。 | これまで、L0 からシステム(L1)、サブシステム(L2)、モジュール(L3)までのSystem of Systems をモデリングすることに 焦点を当ててきました。現在、私たちは要件管理ツールとのインターフェイスを確立し、リンクされた要件およびシステムアーキテクチャモデルをPDFまたは Excel形式でドメイン設計のエキスパートに提供することに重点を置いています。私たちの長期的な目標は、モデルを通じて情報を直接リンクすることですが、これは非常に複雑で、特に一貫性と正確さを保つのが非常に難しいため、実現にはまだ数年かかると考えています。 |
| MBSEの適用にiQUAVISを活用していることは参考になりました。 適用にあたっての苦労やその解決の取組みを教えてください。 |
大きな苦労はありませんでしたが、ツール導入に伴うリソースと有益と分かっていても時間のかかる活動をすべてカバーするためのリソースが不足していたことは苦労した点です。 例えば、専門的なトレーニング資料の準備、非常に充実していてかつわかりやすいトレーニングカリキュラムやサンプルモデルの準備、専門的かつ包括的なドキュメントなどです。 電通総研によるサポートは、ツールの機能や方法論のサポートなどの多岐に渡って、常に完璧でした。 |
| ツリーの正しさ、確らしさをどうチェックし担保されているのか、教えていただきたいです。 | 一貫性と確からしさのチェックは、ツールによってのみ、正しく行われています。例えば、各機能が少なくとも 1 つのコンポーネントに割り当てられます。iQUAVIS は、コネクタが一致するポートに接続しているかどうか、つまり、転送されたデータ/エネルギー/物質も同一であるかどうか、およびフローの方向が一致しているかどうかもチェックできます。将来的には、AIを活用することも考えています。 |
| パートナー企業とiQUAVISのモデルを共有した開発をされているのでしょうか。 | これまでのところ、パートナー企業とiQUAVISのモデルを共有したプロジェクトは 1 つだけで、プレゼンテーションでご紹介した海洋クレーンプロジェクトです。最近我々は実際に、サブシステムに関係しているパートナーと iQUAVIS で共同作業を開始しました。特にドイツの自動車産業では数年前から議論されてきたような、仕様書の転送やモデルの直接転送はまだ行っていません。しかし、トラックやその他の商用車の OEM との協力がますます緊密になるにつれ、このシナリオもますます現実的になってきています。 iQUAVIS を要件管理ツールと連携させ、少なくとも両方のモデルから生成される仕様書を作成し、コラボレーションに使用できるようにしたいと考えています。 2024年に実現する計画です。 |
| 組織として、MBSEのプロセスを標準化して、形式知として運用していますか。 | その通りです。我々はプロセスを標準化しており、それゆえ、方法論またはMBSE ツールとして 、MBSEで使用するコンポーネントも標準化しています。これらのプロセスの詳細に関する知識は機密扱いとなりますが、これらのプロセスに関する知識を抽象的なレベルでパートナーと共有しています。 |
| 各ダイヤグラムの作成のプロセスは明確になっていますか。 | 適用分野（範囲、領域）、要件、条件があまりにも多様であるため、個々の図に対する詳細な手順（作成プロセス）はまだ定義していません。ただし、トレーニングの一環として、サイズ、レイアウト、特定の構文などに関するモデリング手順を開発チームへの推奨事項として規定しています。 |
| プロセスを改善する努力は行っていますか。 | 我々は研究開発部門に所属していますが、プロセスやデータのトピックに関して設計メンバーと頻繁に意見交換しています。 |
| ハードルを下げることで、モデルの内容、質に、ばらつきが出てくると思うが、質を保つためにどうしているか。 | 我々は優れたユーザートレーニングや実地トレーニング（継続的なサポートとコンサルティング）によって品質の問題を回避しようと努めていますが、他方では、プロジェクトにて作成されたモデルに対してレビューや独自の助言を行うこともあります。もちろん、中心となるメソッドおよびツール部門によるこのような関与には限界があり、我々は利用ユーザーに対し、モデルを無駄にしないよう、目的主導型のモデリングに従うように指示しています。 |
| MBSEプロセスで作成したダイアグラムなどをレビューできる人はいますか。 | もちろんいます。私のチームメンバーは、リソースが利用可能な限り、リクエストに応じてレビューしています。 |
| 一貫性がモデルベースの利点でもあると思うが、システムモデルの管理者はいますか。 | 一貫性がモデルベースの利点であるという点はまさしくその通りです。各モデルには最初の相談先となる所有者がおり、その所有者がコンテンツの責任を負います。加えて、私のチームには、ライセンス割当、アクセス権、メタモデル、モデルテンプレート、モデル構造などを管理する専門家がいます。 |
| ハードウェアと、それを制御するソフトウェアを開発していると思いますが、ハードウェア（またはハードウェアを備えたシステム）を、要件を満たす為めにプロジェクト中に研究開発を行うのでしょうか。 それとも、プロジェクトの前に開発し、要件を満たすために最適化されたハードウェアの組み合わせだけを考慮するのでしょうか。 質問の背景として、プロジェクト中にハードウェアを開発する場合、MBSE で最適化された仕様を決定するために様々な候補を考慮する必要があるという理解であるためです。よって、貴社の開発スタイルは後者 (プロジェクトの前に開発し、最適化された組み合わせだけ考慮)と推測しますが、それを確認させて頂きたいです。 |
両法のパターンで開発をし、お客様へ提供しています。クレーンやリフティングプラットフォームは、標準製品として購入することも可能ですし、注文に従ったコンフィギュレーションとして購入することも可能です。また、フルカスタマイズやカスタム製品を開発したりというケースもあります。MBSE アプローチはそれぞれのパターンにも適用しています。 |
| 複雑なシステムは見える化しても依然複雑だと感じました。あの巨大かつ複雑なツリーがシステム設計の観点で設計者の意図を正しく反映できているかの確認はどのように行うのでしょうか。 | ツリーはモデル全体またはその一部を表現した 1 つにしか過ぎません。これだけでも、特にナビゲーション機能とフィルタリング機能を利用して要素間の関係を理解することに「正しい」視点に貢献できます。ツリーが設計者のニーズを満たしていることを確認する最善の方法は、できるだけ多くの設計者にそれをコラボレーションに使用させ、何が良いのか、何が改善できるのかフィードバックを提供することです。また、システム設計の役割を持つ人だけが、ツリーがうまく機能するかどうか、レイアウト、フィルター、タグなどを再構成する必要があるかどうか、または図、行列、ワークシートが必要かどうかを判断できます。さらに、それぞれのニーズをより適切にカバーすることができます。 |
| SEに対してリーンMBSEはどのくらい効果がありましたか。 | 過去も今も、リーンMBSEは、Palfinger社のシステムエンジニアリングの中核的な役割を担うものの一つです。実際のプロジェクトでは、ほぼすべてのエンジニアリング作業がコンピューターを使用して行われます。ドキュメントではなくモデルを使用して作業が行われる割合が増えるほど、情報の品質と一貫性が向上し、より多くのメリットが得られます。今日では、システムの機械設計を行うには2Dおよび3DCADツールを使用することが完全に確立されており、ポンチ絵やテキストで説明したりするドキュメントを使用してこれを行うことは決してありません。同じことが包括的なシステムアーキテクチャにも当てはまり、機械設計だけでなく、もちろん油圧設計、電気/電子設計、またはソフトウェア設計にも重要な境界条件と設計仕様を提供する必要があります。 |
| Palfinger社でのリーンMBSE導入においてどのような支援を受けましたか。 | 必要なあらゆる優れたサポートとコンサルティングを、リモートまたはオンサイトで常に受けており、現在でも受けています。また、電通総研もPalfingerを訪問しており、例えば iQUAVIS の開発ロードマップに関して直接意見交換をしたりしています。 |
| ユースケースを分析し、ステークホルダ間の関係におけるリスクを検討していくということでした。これは、リスクを抽出する良い方法だと思います。ただ、静的な抽出方法であるようにも思いました。たとえば、調達する部品の含有化学物質に規制物質が加わったり、ユニットに使われているＣＰＵが廃止になってしまったりといった、将来起こりうるリスクがあります。こうした、リスクにはどう対応されているのでしょうか。 | 当社では、システムアーキテクチャモデルにおいて購入部品に至るまでトレーサビリティをさらに深くカバーするよう努めていますが、ご指摘のようなリスクは通常、当社のサプライチェーン管理システムによってカバーされています。ただし、当社のシステムアーキテクチャモデルでは、重要なコンポーネントの使用状況の相互依存性を明確にして管理しやすくするためのトレーサビリティを確立しています。具体的には、CPU やその他の電子機器が納品に関して非常に困難な事態に見舞われたということがすでにあり、他のサプライヤーとは少し異なる制御システムコンポーネントを使用するなどの対策を定義して実装する必要がありました。この場合も、影響分析を実施し、他の供給部品を使用する開発プロジェクトの設計仕様を導き出すために、どのコンポーネントがどこでどの機能を提供または貢献するかについての知識が必要となります。方法論的な観点から、私たちは常に、特定の情報や関係がデータシステム内でどの程度利用可能であるのか、それとも、iQUAVIS でより簡単に実現できる新たな情報を確立する必要があるのかを常に確認し、改善しています。 |
株式会社電通総研 構想設計・システムズエンジニアリング担当
E-mail：g-mbse-mfg@group.dentsusoken.com
