V字プロセスと、すりあわせ型"X"MBD
- eXtended Model Based Development -

モデルベース開発

V字プロセスとXMBD/擦り合せモデルベース開発

Waterfall (ウォーターフォール)

生産プロセスでの従来型モデルはWaterfallとも呼ばれ、要求仕様から設計・仕様策定・実装と、上流から下流に向けて作業が流れて行くイメージでした。

Requirement(要求仕様)からImplementation(実装)へ至る段階で要求はだんだんと具体的になり、ソフトウエアとしては完全な(意味が固定される)ものとなって行くとされていました。

前工程の完了を待って次工程に進む段取りを守る事で前工程の品質を担保し、基本的に前工程への後戻りはしない(それぞれの工程で完全に仕上げる)という前提の考え方です。
この考え方は長い間ソフトウエア開発の中心的な概念でした。

このプロセスでは、それぞれの工程に問題がない(それぞれの工程で問題を完全にクリアする)ことが前提になります。
従って、テストについてもUnit TestingからCalibration Relerseへ進むにつれ、テスト出来る項目が次第に少なくなって行きます。

このプロセスの大きな問題は、前工程に何らかの問題が潜んでいた場合に、後工程での発見・修正が難しい点にあります。


X字プロセス1


Waterfallプロセスを真ん中で折り返したものが、いわゆるV字プロセスと呼ばれているものです。

ここではValidation やCalibrationの結果作り出された製品は、Requirementを 満足したものとして定義されます。
Validation やCalibrationの結果がRequirementと きちんと合っているかどうか(上図より破線の部分)は重要な問題です。

この段階のキーアイデアは、「“Implement(実装)”は“Specification(仕様)”をきちんと満足させなければならない」という(上図より実践の)部分に置かれておりました。

この段階では、“Specifications”を出来る限り実現可能にするという事が重要で、
  • “仕様”を出来る限り具体的に作成すること
  • “仕様”に対する“単体テスト” を行うこと
  • “仕様”と“実装”間の“単体テスト”を行うこと

が、主な課題となっており、Specification(仕様)を如何に正確にInplementation(実装)するかが注目されていました。


X字プロセス2


V字プロセスの第2段階では、より合理的な考え方がなされ、上図のDesignとSpecification、 Unit TestingからIntegration, Calibrationのベクトルが重要視されます。

ここでは開発期間の短縮が語られ、設計工程の迅速化がテーマとなっていました。

プラントや制御へのモデルの活用の重要性が盛んに語られるようになってきました。
モデルを使用することで、Designの課題はもっと明確になって来ました。
しかし、この段階ではまだ非合理的で、Designと実行可能なSpecificationの境界は依然として不明確なままでした。
自動コード生成がごく当たり前に使われるようになってきたのもこの時代です。

V字の右側のラインでは、MIL / SIL / HILシミュレーションによる事前(仮想)テストによる“プロトタイプ”実テストの回数削減が話題になりました。
Specificationが複雑になるにつれテスト対象と種類が増え、これらに対応するために(仮想)シミュレーションを用いた事前 Calibrationが要望される様になって来ました。


X字プロセス3 (MBSE:Model Based Systems Engineering/モデルベースシステムズエンジニアリング)


MBD(モデルベース開発)の第3段階はRequirement(要求定義)をどの様にMBDの中で位置づけるか、といった部分になります。
現在 多くのところで課題になっているのが、この段階でMBSE(Model Based Systems Engineering)とも呼ばれています。

ここで一番問題となるのは、Requirement(要求定義)の具現化(モデル化)です。
多くの場合、上層部や企画部門から出されるRequirement(要求定義)は、一般的に非常に抽象化された形で表現されることが多く、きちんとした形で(時には自然言語を使ってでも)表現することは、なかなか難しいのが現状です。

特に“system of system”と呼ばれる様な非常に複雑なシステムで、 Requirement(要求定義)をきちんと定義する事は、ほとんど不可能とも言われています。

Requirement(要求定義)の一層の具体化するには、
  • 構造化要求の分析
  • Requirement(要求定義)に対する事前設計検証

等が非常に重要と言われていますが、この具体的な手段は、まだ一般化されていません。

このプロセスは、今日 “State of Art(最先端)”と言われており、ほとんどのツールやプロセスは、この“パラダイム”より構築されています。
しかし、Requirement(要求定義)をきちんと定義することは、実際の製品開発のプロセスからは非常に難しい(ここからスタートすることはほとんど無理)事もわかってきました。


X字プロセス4 実際の製品開発プロセス

Design-Requirement間で繰り返されるプロセスの経験的モデル
実際の製品開発プロセスを考えた場合、Requirementがスタートになっていることは、ほぼ無いと言っても言い過ぎではなく、V字プロセスのスタート地点は、ほとんど無視されているのが現状のように思われます。

製品開発のスタートの多くはDesignの一部を変更したり、Specificationモデルを変更したり、実装コードを解析することでRequirementを推測したりする作業が行われます。
日本のもの作りの現状を考えた場合、今までのV字プロセスで一般的に語られてきた様に、“Requirement”は必ずしもスタート地点では無く、Code, Models, Design の、どこでもスタート地点になっているのが現実です。

このような意味で、開発は繰り返しの連続(“Requirement”が下流に影響を与えたり、 逆に“Design”や“Implementation”から“Requirement”が推測されたり)と言えます。

このような意味では、西欧型の“State of Art”と呼ばれる“Requirement”をスタートとするのではなく、“State of the Practice” 状態とも呼ばれる、今までの資産の一部を変更することから始まるような、仕事の流れに合ったツールとプロセスの選択が必要です。

注:“State of Practice”は“State of Art(最先端)”に対する造語で、現状を踏まえた上でのプロセス手法であえて訳すと「実用状態」あるいは「模索状態」となります。



X字プロセス5 現状に合った“eXtended / eXtreme”フレームワーク


現状の開発プロセスを踏まえた従来型のMBSEモデルの資産を、そのまま使いながらRequirementをきちんと把握していける、モデリングフレームワークが望まれています。

このフレームワークは、様々な方向からの要求をカバーする必要があります。
ここでは制御モデルに加えて、プラントモデルや実装コード、ユニットテストの結果までが反映されたフレームワークである必要があります。

ここで重要なキーワードは、
  • より具体的な“Requirement”
  • Tests (Unit, Verification, Analysis, Validation)の構造化
  • (requirements, conceptual design)のモデル化
  • 実行可能な(software, tests, analysis,)仕様書
といったものがあります。


擦り合せ型モデルベース開発 "X"MBD -eXtended Model Based Development-

相互に関係する資産がモデル化された「拡張モデリングフレームワーク」が提案されています。

レベル1では従来のV字プロセスの左側をMBDプロセスとして定義します。
その後レベル2で Calibration, Validationを含めた、V字プロセスの全体が実現されます。

相互に関係する資産を生かしながらV字プロセスの以下の部分で、
  • Requirements
  • Design (Design Decisions, Design Assumptions, Functional partitioning, algorithm)
  • Implementation (Software, Software Specs, Executable Algorithm Specifications)
  • Verification and Validation

トレーサビリティと繰り返し環境をサポートします。
注:eXtended Model Based Development は造語で、 相互に関係する“assets(資産)”がモデルである場合の“モデリング フレームワーク”と言った意になります。


X字プロセス6 今後の方向

従来提案されてきたモデルベース開発手法は、“State of Art”として“Requirement”を基本とし、そこから”Waterfall”の流れを踏襲するものでした。

一方で、日本のもの作りの現場では“Requirement”をスタート時点とするのではなく、現状のDesignやSpecificationの改良や変更からスタートすることが一般的になっていました。

そこでは ”Waterfall”の 流れよりも、その部門ごとの「すり合わせ」や「改善」と言った手法が優先され、他の工程との間での「繰り返し」が何度も行われる特長があります。

そのような文化のもとでの モデルベース開発手法として、eXtended Model Based Developmentが最近注目をあびています。
“State of Art”ではなく“State of Practice”をベースにした新しい手法です。

“State of Practice”は、“デザイン“、“レクワイヤメント”、“インプリメント”、Testing等の繰り返しを明確に意識した、「どこからでもスタートすることが出来る」手法です。


“State of Practice”に沿った
eXtended Model Based Development (XMBD)手法の提案
  • “Requirement” “Design” 等相互関連のある“資産”を、抽象化したりモデル化する為の共通フレームワーク
  • 実際に作業をするエンジニアに取って直感的で負担にならない操作
  • 理解を深めやすくフレキシブルな拡張性
  • 実際に作業するエンジニアにとって最先端のサポートを供給
  • “Design-Requirement Iterative Process(“Design”- “Requirement”間で繰り返されるプロセス)”を理解し、促進する為の新しい“ツール”と“環境”の提供

日本のもの作りのプロセスをベースにした新しい概念のV字プロセスを提案します。



お問い合わせ先
株式会社 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システム/ロボット
データ収録装置
車載ネットワークツール