衝突警報装置(CWS / Collision Warning System)での仕様記述例
要求・デザイン・知識・並列エンジニアリングツール DRIP


モデルベース開発

XMBD-擦り合わせ型V字プロセス
ここでは、Collision Warning System (CWS/衝突警報装置)を例に、DRIPの運用方法を下記の流れで説明します。

目次

CWSイメージ

ここでは、上図の流れでのCWSを例として進めます。


ハイレベル要求 / High- level req

DRIPでハイレベル要求を記入する場合、上図の様な書き方になります。 線の上部は自然言語による自由な記述、下部は形式言語による具体的な記述になります。
自然言語で書かれた仕様の内容を受けて、必要に応じて形式言語の部分を記述していく形となります。
形式言語部分で書かれている「言葉」は、言葉であり、変数でもあります。これについては、「変数」で後述します。

ここで形式言語で書くことによる利点については、後述の「実現可能分析」をご参照ください。

DRIPでは、技術的な要求の他にビジネス面での要求を記述する事も可能です。
例えば、上記の様なコスト面での要求です。
これを記述できることによる利点ついても、「実現可能分析」で後述します。


その他、環境に関する仕様の記述も可能です。
上記の例では、想定される道路の状態を書いています。
形式言語の部分では、路面の摩擦係数の想定範囲を記述しています。

変数 / Variables

形式言語で書かれる仕様書中に登場する「言葉」は、ここで「変数」として定義することが可能です。
各変数の呼称を統一する事が出来、単位や型(数値や浮動小数、文字列など)の他に、許容範囲や許容値の設定も可能です。

知識 / Knowledge

プロジェクトがゼロからスタートする事は稀であり、開始時には既に何らかの「過去の資産」が残っている事が常です。
DRIPは、そうした「過去の資産」も取り込む事が可能です。

ここでは、凡例としてセンサーのデータベースを記入しています。
形式言語の部分では、各センサーの数値情報が記入されます。
これは、後述の「妥当性検証」で活用されます。

取り込んだ上記の仕様書より、センサーに2のタイプ(選択肢)つある事が判ります。


他にも、過去の資産を取り込みます。
取り込んだ上記の仕様書からは、警報システムに3つのタイプ(選択肢)がある事が判ります。

過去の資産の他にも、DRIPは原理原則などを記入する事も可能です。
上記の仕様書からは、車の各制動の原則が判ります。

これら「知識」も、「要求」と同じ画面構成・ルール・操作方法で記述する事が出来ます。


デザイン / Design

「デザイン」も、「要求」や「知識」と同じ画面構成・ルール・操作方法で記述する事が出来ます。

上記の仕様書から、「衝突回避」の仕様の土台として「知識」の「車両停止パフォーマンス」(VehStopPerf)が引用され、それに加えて障害物との距離と検出範囲の関係性が追記されている事が判ります。

「設計調査」では、センサーシステム(SensData)と警告システム(WsysdB)を「知識」から任意でひとつずつ抽出して引用する方針である事が判ります。


実現可能分析 / nfeasibility analysis

「実現可能性分析」では、これまで「変数」、「要求」、「デザイン」及び、そこで引用して使用されている「知識」で書かれた形式言語の式を使用して、各仕様が矛盾や間違いを含んでいないか、実現妥当性分析を行います。

上図では、Conbination Analysis機能によって、「デザイン」で未確定だったセンサーシステム(SensData)と警告システム(WsysdB)の全ての組合せを自動抽出し、それぞれの実現可能性を演算します。
更に「変数」において値の範囲が指定されている場合も、実現可能性演算に反映されます。

上図は全パターンの妥当性分析の結果です。
他の各仕様書で形式言語で記述された式が、ここに集められます。
全6パターンが存在し、そのうちの5番目の組合せならFeasible(実現可能)であることが判ります。

デザイン側に戻り、実現可能性分析で「Feasible(可能)」であったパターンから任意の物を選び(この事例では1パターンのみが候補となる)形式記述で記入します。
これでデザインの仕様書は、実現可能な組合せでの「知識」の上に書かれたものとして成立します。

こうして、具体的に「知識」の情報を抽出して記述する事によって、これら仕様書群は他の組合せを完全に排除して実現可能なもののみに「ロック」します。
また、ここで選択したものは、時間が経つと経緯を忘れてしまう事が往々にありますが、「この選択をした経緯と理由」をコメントで残すことで、後年にこの仕様書を再利用しようと考えた場合でも、過去の経緯を調べなおすといった様な手間が生じなくなります。

どう実現可能なのか?
ここで必要となるのが、前述の実現可能性分析でFeasible(実現可能)と判断されたとしても、「どの程度、どう可能なのか?」が必要となります。
以後は、実現可能性分析結果の根拠となる、演算結果について説明いたします。

実現可能性分析の結果は上図の様な図表で表すことが可能です。
上記の例では、摩擦係数の許容範囲が表示されています。

上図では、「ブレーキを踏んだ時の車速」の許容範囲が表示されえいます。
これにより、「実現可能ではあるが、前述の『変数』の項目で指定した範囲である時速80km〜時速150km全てで成り立つ訳ではなく、時速80km〜103kmの範囲でのみ成立する」事が判ります。


実現可能性分析の図表は2軸表記も可能です。
上図は「摩擦係数」と「ブレーキを踏んだ時の車速」の関係性を表したものです。

さきほど、「ブレーキを踏んだ時の車速」が時速80km〜103kmの範囲でのみ成立する事が判りましたが、その他に「摩擦係数」の値にも依存する事が視覚的に理解できます。(図中の青い色の部分が実現可能部分です)

上図では、「ブレーキを踏んだ時の車速」が早い時、「摩擦係数」が大きいほど実現可能領域が広く、しかしながら、摩擦係数が0.5を超えると以降は変わらない事が判ります。

上図は、「減速度」と「ブレーキを踏んだ時の車速」の関係性です。
「ブレーキを踏んだ時の車速」が速いほど、「減速度」が大きくなくてはならない事が判ります。


「ブレーキを踏んだ時の車速」と「ドライバーのリアクションにかかる時間」の関係性はこうなります。
「ドライバーのリアクションにかかる時間」が長いほど「ブレーキを踏んだ時の車速」が遅くなくては成立しない事が判ります。


「ブレーキを踏んだ時の車速」と「ブレーキを踏んだ後の移動距離」の関係性はこうなります。
ここでは、「ブレーキを踏んだ時の車速」が速いほど「ブレーキを踏んだ後の移動距離」が長距離に渡って必要となる事が判ります。
加えて、「ブレーキを踏んだ後の移動距離」が80mを超えた辺りから、「ブレーキを踏んだ時の車速」の許容範囲が次第に厳しくなって来ている事も判ります。
これは、「警告後に停止までかかる制動距離」が「ブレーキを踏んだ後の移動距離」のみで決まるものではなく、「ドライバー認識後に反応するまでの制動距離」にも依存している事から来ています。
前述の実現可能性分析(更にその引用元は「知識」の「車両停止パフォーマンス」の項目)より、
警告後に停止までかかる制動距離 = ドライバー認識後に反応するまでの制動距離 + ブレーキを踏んだ後の移動距離
の式が与えられています。

「ドライバー認識後に反応するまでの制動距離」も「ブレーキを踏んだ後の移動距離」と同様に、車速に依存して長い距離を必要とします。

これより、「ブレーキを踏んだ後の移動距離」が80mを超える辺りからの環境において、「ドライバー認識後に反応するまでの制動距離」の影響が大きくなる(車速が早いとそれだけ「ブレーキを踏んだ後の移動距離」に避ける距離が少なくなる)事が判ります。


アーキテクチャ / Architecture

要求が固まったら、次は、より具体的な仕様としてアーキテクチャを記述します。
アーキテクチャとは、ハードウェアで言うところの構成図や相関図、UMLで言うところの状態マシン図(ステートマシン図)に当たります。

上図左側は、CWSのアーキテクチャを記述しています。
書かれた仕様は上図右側の様にブロックビューやツリービューとして表すことが出来ます。
更にブロックビューでは、サブシステムの中まで影響範囲を辿る事も可能です。

こちらは、車両情報のアーキテクチャの記述例です。

記述されたアーキテクチャはSimulinkモデルとして自動生成する事が可能です。
モデルベース開発でのワークフローでは、この後、出力されたSimulinkモデルを元に実装する流れとなります。
実装されたSimulinkモデルは、後述のテストハーネス自動生成で再利用されます。


ローレベル要求 / Low-Level Requirments

テストケース / Test case

前述のアーキテクチャでは、テストケース(ユースケース)も記述する事が可能です。
上図では、車両と物標(前走車)のシナリオをイメージ図のストーリーでステップ毎に設定しています。


マッピング / Mapping

前述のアーキテクチャの後、実装したSimulinkモデルを、アーキテクチャに記述されたテストケースと組み合わせる事でテストハーネスの自動生成が可能です。

DRIPとSimulinkは別のツールですが、マッピングによってDRIPにSimulinkモデルの構造(モデルの各部位がアーキテクチャのどの部位と対応するか)を理解させる事が可能です。

これ以降はSimulinkモデルはDRIPの管理下に置かれ、DRIPにより生成・改変・実行される形となります。


テストハーネス / Test harness

DRIPによって自動生成されたテストハーネスは上図の様な構成となります。

中央が元々のSimulinkモデルで作りこまれた実装の部分。
左側がDRIPのアーキテクチャに書かれたテストシナリオを埋め込んだ部分。
右上が全出力パラメータをモニターするための部分。
右下がDRIPに書かれた要求やアサーション(形式言語や式)を埋め込んだ部分。この部位が検証に使用され、得られた「結果」がDRIPにフィードバックされます。


結果 / Results

前述のテストハーネスの実行結果がDRIPに戻ってきます。
上図では成功(Success)した事が判ります。


以上がDRIPを使用した工程の基本的な事例です。
ソフトウェア「要求・デザイン・知識・並列エンジニアリングツール 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システム/ロボット
データ収録装置
車載ネットワークツール