DRIP -ドリップ-
要求・デザイン・知識・並列エンジニアリングツール


モデルベース開発

XMBD-擦り合わせ型V字プロセス

プロセスの改善とコスト削減を促す

要求・デザイン・知識・並列エンジニアリングツール DRIPは、モデルベース開発における課題のひとつとして挙げられる事の多い「人を介する事でコストのかかっている部分」に対して、ツールベースでの正確性(品質)を保証し、かつ、要所での「人の判断」を柔軟に取り入れる事で、プロセスの改善とコスト削減を促すツールです。


モデルベース開発における課題(コストのかかる部分)

モデルベース開発において、要求と実装デザインの間、つまりシステムデザインの領域にツールチェーンギャップがあると言われています。

ツールチェーンギャップは、「要求側(多くはOEM)で書かれた仕様書が実装側(多くはサプライヤ)で、書いた仕様の意図通りに解釈されているか?」とも言えます。
ここにギャップが生じていると、ウォーターフォールがスムーズに流れず、次工程にうまく渡すことができません。

実装においても同様に、「いま作りこんでいる実装が、要求側の意図通りになっているか?」と言った課題が常に付いて回ります。
この部分の整合性を取る作業は、ほとんど人の手で行われているのが現状です。

このため、照合、仕様変更時のテスト、仕様書に対する実装の評価、仕様書そのものの整合性検証といった様々なステップで多くの工数が費やされています。


ツールチェーンギャップ

・あいまいな情報
 −複数の解釈
 −情報過多
 −要求、設計、知識を同時にエンジニアリングすることができない
 −要求の不一致
・テストシナリオとローレベル要求が実装に依存してしまう
・実装が要求を満たしているか容易に判らない

ツールチェーンギャップとして、上記の様な問題が考えられます。


あいまいな情報...複数の解釈

10秒したら車速が時速80kmを超える。

例えば、上記の様な仕様があったと仮定します。

この時、読む側にとってこの仕様は「10時点を含むか?」、「時速80km丁度の値は含むか?」が"あいまい"であると言えます。



あいまいな情報...情報過多


膨大な情報の中なら必要な情報のみを選別しなくてはならない
ある担当者がプロジェクトにアサインされたとします。

このとき、プロジェクトが何もない状態から立ち上がる事は、まずありません。
既存のプロジェクトの成果物としての仕様書、参考資料、既に持っている情報のデータベースや、周知の事実、物理現象(水は100度で沸騰するなど)といった情報が一度に集まってくる事になります。

この中から必要な情報を選別して仕事を進める事は非常に多くの工数を要します。

あいまいな情報...要求、設計、知識を同時にエンジニアリングすることができない

これら要求(Requirment)、デザイン(Design)、知識(Knowledge)といったものを同時にエンジニアリング(一元的に管理して作業)していく事は非常に困難です。

あいまいな情報...要求の不一致

「これら要求が、背反・相互作用の観点から互いに整合性を取れているか?」の確認をとる事も困難です。


テストシナリオとローレベル要求が実装に依存してしまう

多くの事例(例えばOEMがサプライヤに実装を依頼しているときなど)では、人がテストシナリオを書き、人がそれを読んで解釈し、そのテストケースをSimulinkやCといったプラットフォーム内に実装します。

この場合、10のテストケースが実装されたと仮定すると、テストシナリオに変更を加えられた時には10のモデル(テストケース)も全て修正しなくてはならない事を意味します。

プラットフォーム(実装媒体)が変わった場合も同様です。
たとえばテストケースの書かれた部分のプラットフォームがSimulinkからCに変更された場合、10のテストケースがあれば10のCコードを新規に書き起こす必要があります。
これは非常に非効率です。


実装が要求を満たしているか容易に判らない

例えばOEMがサプライヤにアーキテクチャ設計を送って実装を依頼したとき、サプライヤ側が「人が要求を読んで解釈」するとします。
実装が完了したら、OEM側がそれを「人が品質検証」するとします。
その場合、このプロセスにおける正確性(品質)を保証する事は非常に困難です。


DRIPの提案

要求・デザイン・知識・並列エンジニアリングツール DRIPでは、そうしたMBDの課題に対して上図の様なツールチェーンを提供する事により、要求から実装までをツールベースで繋げる事が可能となります。

上図では、「検証と妥当性確認 (Verification and Validation)」にSimulinkモデルの情報をインポートしています。これを実装アーキテクチャと呼称します。

実装アーキテクチャを、マッピングを介して「ローレベルエンジニアリング(デザインアーキテクチャやローレベル要求、テストケース)」と連結します(マッピングA)。

さらに(デザイン)アーキテクチャとハイレベルエンジニアリング間をマッピングする事で、実装は「ハイレベルエンジニアリング(要求・デザイン・知識)」まで連結する事になります(マッピングB)。

こうした操作により、実装から要求までの関連付けがツールベースで可能となります。


ハイレベルエンジニアリング


要求の記述例(デザイン、知識も書式は全く同じ)
ここでは、要求、デザイン(設計)、知識を記述します。
これらは全く同じプラットフォーム(画面構成、ルール・作法、操作方法・操作感)上で記述されます。
プラットフォームとしてのDRIPは、要求・デザイン・知識の間でのトレーサビリティを実現しており、各仕様間の該当箇所同士への遷移も容易に行う事が出来ます。


各仕様書にはWordの様に、自由に文書・段落を記述する事ができ、更に重要部分は「式」の形で残すことが出来ます。


式の例(要求にはこの様なビジネス面からの仕様も記述可能)
ここで、知識とは過去のプロジェクトの資産やデータベース(例えば多種存在する警報装置の情報など)、全員が共通で知っている常識や物理現象といったような情報の集積を指します。

デザインでは、具体的な仕様と共に、知識から「何を引用するか?」を明確にする事が可能です。
しかし、膨大な知識情報の中から、このプロジェクトに適切な情報のみを選別する事は非常に困難です。その解決策の一つとして、先述の「式」が有用となります。

各仕様書内に書かれた「式」は、収集後分析され、実現可能性分析(より正しくは実行不可能性分析)を行う事で記述された全ての要求、デザイン、知識の仕様(式)がすべて成立するかを検証する事が可能です。

更に、膨大な知識情報の中から「何を引用したら背反が生じないか?」の抽出パターンを自動算出し、その全パターンの実現不可能性分析を自動で行います。
ユーザーは、「実現可能」と判断された抽出パターンの中から任意の情報を選択する事が可能です。


ローレベルエンジニアリング

ローレベルエンジニアリングでは、(デザイン)アーキテクチャとローレベル要求、テストケースの仕様を記述します。
アーキテクチャでは、各要素とその関係性を記述します。
テキストで記述する事は、コピー&ペースト等、操作性の面で多くの利点があります。

更に、記述したアーキテクチャ仕様を視覚化機能によりボックスビュー(関係性解析・影響解析)やツリービュー(親子関係の解析)といった、視覚化機能により様々な視点から確認する事が可能です。

ローレベル要求では、形式言語をベースとした日本語で仕様書を記述します。
ここでは、ある程度型に当てはめた記述方法をする事で、記述した日本語を時相論理式として保存する技術を採用しています。

これにより、記述した仕様が実際にツールで利用する事の出来るだけではなく、 日本語で記述したローレベル要求を英語に変換といった操作も可能になります。


時相論理式とCNL(Controlled Natural Language)を踏まえた形式言語

DRIPの形式言語はCNL(Controlled Natural Language)をベースに、時相論理式を踏まえた制御用文章としての日本語フォーマットを使用しています。


形式言語での日本語の記述例(英語など多言語に対応)

記述した日本語は時相論理式として管理

テストケースでは、アクター単位でテストシナリオの仕様を書いていく事となります。
これもまた、式をベースとした日本語を採用しており、これ自体がDRIP内で機能する事となります。

シェルアーキテクチャ自動生成

前述のアーキテクチャ仕様を利用する事で、シェルアーキテクチャ(Simulinkを凡例とすると、その外殻モデル)を仕様書から直接、自動生成する事が出来ます。

これにより、仕様を書く時に意図通りに実装できるかどうかの懸念が軽減されます。
同時に実装する時も、この実装が仕様の意図通りになっているのかの懸念を軽減する事が出来ます。


実装したモデルをインポート

DRIPは作りこんだSimulinkモデルを分析してインポートする事が可能です。

インポートされたSimulinkの実装情報がDRIP内に書かれたどの仕様に対応する情報かを関連付ける事により、 DRIPは外界(別のプラットフォーム)での実装内容を正確に取り込むことが出来ます。


マッピング

モデルのインポートが完了したら、次はマッピングとなります。
まず、インポートしたモデルの実装情報とアーキテクチャ仕様書をマッピングする事により、実装情報はDRIP内に書かれたアーキテクチャの仕様とDRIP内で連結されます。


次に、アーキテクチャ仕様書と要求をマッピングします。
これにより、実装はDRIP内で要求と連結した事になります。



実装から要求までが繋がる
マッピングにより、実装が要求とツールベースで繋がりました。

いま、実装モデル内の各要素は、接続された仕様書内の各対応部分に対応付けられ、トレーサビリティが実現しています。
実装内の任意の要素が、アーキテクチャのどこに対応するのか、要求のどこに対応するのかといったトレーサビリティを容易に取る事が可能です。

反対に、要求やアーキテクチャから実装へのトレーサビリティも取る事が出来ます。

更に、これらの情報を前述の式や形式言語で書かれた要求と共にDRIP内で演算させる事で、後述のテストハーネス自動生成事が可能となります。


テストハーネス自動生成


マッピングにより繋がった各要素の情報からテストハーネスを自動生成
上図はテストハーネスの自動生成例です。

ベースとなった実装モデルが、テストハーネス中央に位置します。
ローレベルエンジニアリングで記述したテストシナリオより、テストケースが生成されモデルの左部に出力しています。
実装の全結果をモニタする為のサブシステムが右に生成されています。
テストシナリオで記述した期待結果と、要求で記述したアサーションが右下に生成されます。
自動生成されたテストハーネスはハイレベルエンジニアリングまで繋がっている為、テストシナリオの期待結果のみならず、要求(アサーション)に対する品質確認も可能です。

Simulinkモデルとして出力されたテストハーネス
マッピングされた各要素を埋め込むことで、テストハーネスの自動生成が実現しました。

更に、このテストハーネスは各マッピング情報から自動生成されているため、中に書かれているテストケースは実装から独立している事になります。
その為、テストシナリオやプラットフォームが変更された場合も、テストケースの再記述をする工数が大幅に軽減されます(再記述時の書き損じのリスクも軽減されます)。


検証と妥当性確認(Verification and Validation)

テストハーネスは、DRIPにより制御されます。
DRIPからテストの実行操作を行い、テスト結果もDRIPで受け取ります。

マッピングにより実装・ローレベルエンジニアリング・ハイレベルエンジニアリングが繋がっている事から、テスト結果はテストシナリオの期待結果に対する結果のみではなく、ハイレベルエンジニアリングに書かれたアサーションに対する結果も得る事が出来ます。

これにより、ツールベースでのV&V(Verification and Validation:検証と妥当性確認)が容易となります。


DRIPでシステム設計プロセスをサポート

DRIPでの各プロセスをV字に当てはめると上図の様になります。


以上のプロセスを以て、要求から実装までのトレーサビリティが取れる様になり、V字プロセスはツールチェーンギャップ無く繋がりました。

要求・デザイン・知識・並列エンジニアリングツール"DRIP"により、プロセスの改善と、コスト削減を促す事が可能となります。




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

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

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

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