モデルベース開発の拡張(XMBD)
- eXtended Model Based Development -

モデルベース開発

V字プロセスとXMBD/擦り合せモデルベース開発
V字プロセスは、今日の開発の現場において多く使われている開発プロセスです。
プロセスを進めるにあたって、我々が認識しなくてはならない事は「V字プロセスを完成させる事で、必ずしも開発プロセスの最適解に到達するわけではない(プロセスに最適解は無い)」点です。

ここでは「V字プロセスで最先端(State of Art)と思われているものに対して、現実はどうなっているのか?」を踏まえて、"モデルベースの拡張"を提案いたします。


V字プロセスで”最先端(State of Art)”と 思われているもの



生産プロセスにおける従来型モデル 「ウォーターフォール」

従来型モデルには下記の特徴があります。
  • 一般的にソフトウェア開発で使われる概念である。
  • 「要求」から「実装」へ進むにつれて具体性を増し非抽象的になっていく。
    「単体テスト」から最終的な「キャリブレーション、検証、リリース」へ進むに従いテストは逆に抽象的になっていく。

製品開発プロセス 合理的なモデル「V字プロセス」(折り返されたウォーターフォール)

@でのテーマ
「実装」は確実に「実装デザイン」を満たしたものでなくてはならない。
そのために「実装デザイン」は可能な限り非抽象的にする必要があり、それには下記の様な事が求められる。
  • 「実装デザイン」を出来る限り具体的に書く。
  • 「実装デザイン」に対する「単体テスト」に重点を置く。
  • 「単体テスト」の範囲は「実装デザイン」と「実装」をカバーする。
    (「実装デザイン」の抽象度でのテストとなる)

Aでのテーマ
メカトロニクスシステムは最終的に要求で定義された品質目標を満たすために…
これらは「要求」の抽象度での要求検証となる。

@とAより、V字の右側プロセスは対応する左側プロセスの抽象度で行われる事が判ります。


製品開発プロセス 合理的なモデル「MBD V字プロセス」(折り返されたウォーターフォール)

@でのテーマ
“システムデザイン”プロセスの加速
フィジカルシステムと制御に「モデル」を使用する。
  • それにより設計ソリューションはより具体的になる。
    しかし、それは論理的根拠があるとは言い難い。
  • 設計ソリューションにおける「システムデザイン」と実行可能な「実装デザイン」との境界が曖昧になっている。
  • 自動実装(自動コーディング)。

Aでのテーマ
  • MIL、SIL、HILシミュレーションの使用による事前仮想テスト
    プロトタイプでの実テスト回数の削減
    テストでカバーできる範囲と種類の増加

  • 仮想シミュレーションで”事前” キャリブレーション

ここでは”抽象レベルの検証”と”非抽象レベルの検証”の統合がなされます。

前述の通り、「要求」や「実装デザイン」のレベルにおいてV字の対応する左右プロセスは、それぞれ同じ抽象度で行われます。
右側で抽象と非抽象の統合がされていますが、これは左側の対応するプロセスが同じ抽象度(設計ソリューションがより具体的)である事が前提となりますます。


製品開発プロセス 合理的なモデル「MBSE V字プロセス」(折り返されたウォーターフォール)

@でのテーマ
“システムデザイン”プロセスの加速
システム・オブ・システムズと言われるような複雑化が進むに従い「設計が要求を正しく捉えて書かれているか?」はこれまで以上に重要となります。

その為には…

が必要になります。

「要求」は抽象的であり「検証」も非構造的ではありますが、具体的な「実装」されたものを「検証」するための「要求」もまた、より具体的である事が求められます。


これが今日一般的に「 State of Arts(最先端) 」と言われているものです。
“State of the Art”は、MBDに用いられるプロセスやツールにおいて最新の開発と一般的に”思われている”ものです。
世のツールは“State of the Art”をサポートする目的で開発されています。

しかし…


V字プロセスの”現実(State of Practice)”



製品開発プロセス 経験に基づいた実証的モデル「デザイン〜要求間で繰り返されるプロセス」

現実には図の様な繰り返しが発生し「State of the Practice」とも言える状況となっています。
これからわかる事は、

  • 「要求」は必ずしもプロセスのスタート地点では無い。
  • 現実の開発はプロセスのどこからでもスタートし得る。
  • コード、モデル、 デザインアイデア、 何れもスタート地点になり得る。
  • 開発は”繰り返し”の連続であり、「要求」は「システムデザイン」、「実装」などと相互に影響を与え合う。
  • 「要求」は「システムデザイン」、「実装」、「テスト」からの”繰り返し”により修正や再定義がなされる。

これが、どの様な開発においても必ず起こり得る「現実」と言えます。


既存のツールやプロセスは”State of Art”を前提として 作られているので、”State of Practice”をモデル化し、サポートさせる為には、その間を紐づけるための“新しいツール”が必要であることが判ります。

※“State of Practice”をベースとしたモデル化プロセスを取り入れ(拡張され)たMBDを”XMBD(拡張モデルベース開発)”と呼称します。


ソフトウェアDRIP(ドリップ)の提案



DRIP + メカトロシステム開発のための 完全なツールチェーン

”現実に起きている状況(State of Practice)” が灰色の線とすると、その”繰り返し”は上図の緑色の囲い部分で特に集中している事が判ります。
ソフトウェアDRIPは、この部分の”繰り返し”を含めてサポートします。この部分を担うツールは、これまでありませんでした。

DRIPは既存の要求管理ソフトと情報の紐づけを行います。

ここでも、DRIPは制御モデルやフィジカルモデルとも情報の紐づけを行います。
DRIPの仲介により”State of Practice”(繰り返し)が”State of Art”(既存のツールがサポートしている範囲)と紐づけられます。

詳しくはこちらをご参照ください。


eXtended Model Based Development -拡張モデルベース開発-


ソフトウェアDRIPは、各プロセス間の”繰り返し”をモデル化し、既存ツールと紐づけ、サポートするプロセス統合環境です。


お問い合わせ先
株式会社 NEAT
愛知県名古屋市千種区池下1-11-21
TEL:052-764-3311FAX:052-764-3632

Engineered Mechatronics, Inc.
28175 Haggerty Road, Novi, MI 48377, USA
TEL:Ph: +1 248 513 8059

* 記載の会社名および製品名は、各社の登録商標および商標です。

MBD・計測
リアルタイムシミュレータ
EMTP-RV
モデルベース開発
RCPシステム/ロボット
データ収録装置