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

ADAS 先進運転支援システム

ここでは、Collision Warning System (CWS/衝突警報装置)を例に、DRIPの運用方法を下記の流れで説明します。

• CWSイメージ
• ハイレベル要求 / High- Level Requirments
• 変数 / Variables
• 知識 / Knowledge
• デザイン / Design
• 実行不可能性分析 / Infeasibility analysis
• アーキテクチャ / Architecture
• ローレベル要求 / Low-Level Requirments
• テストケース / Test case
• マッピング / Mapping
• テストハーネス / Test harness
• 結果 / Results

CWSイメージ

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

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

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

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

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


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

値 / Variables

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

知識 / Knowledge

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

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

取り込んだ上記の仕様書より、センサーに２つの（高コスト高機能と低コスト低機能の）選択肢がある事が判ります。


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

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

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

デザイン / Design

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

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

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

実行不可能性分析 / Infeasibility analysis

「実行不可能性分析」では、これまで「Variables」、「要求」、「デザイン」及び、そこで引用して使用されている「知識」で書かれた式を使用して、各仕様が矛盾や間違いを含んでいないか、要求の事前検証を行います。

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

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

デザイン側に戻り、実行不可能性分析で「Feasible(可能)」であったパターンから任意の物を選び選択の意思決定を記入します。
これでデザインの仕様書は、「知識」の上に書かれたものの中から実現可能な組合せを踏まえて成立します。
こうして、具体的に「知識」の情報を抽出して記述する事によって、DRIP上の仕様書は意思決定したパターンに内容を確定します。

こうした意思決定のプロセスは、時間が経つと経緯を忘れてしまう事が往々にありますが、「この選択をした経緯と理由」をコメントで残すことで、後年にこの仕様書を再利用しようと考えた場合でも、過去の経緯を調べなおすといった様な手間が生じなくなります。

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

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

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


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

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

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

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


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


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

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

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

ソフトウェア・アーキテクチャ

要求が固まったら、次は、より具体的な仕様としてソフトウェア・アーキテクチャを記述します。
記述にはDRIPのデザイン・アーキテクチャモジュールを使用します。

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

こちらは、車両情報のハードウェア・アーキテクチャの記述例です。
これもDRIPのデザイン・アーキテクチャモジュールに記述します。

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

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

デザイン・アーキテクチャを記述したら、次はその中の個々の要素に対する“振る舞い”の定義が必要になります。
DRIPでは、これをローレベル要求と呼称します。

テストシナリオ定義 / Test case

Ｖ＆ＶのプロセスではV字の左側で書かれた仕様の内容がテスト仕様となります。
DRIPでは、デザイン・アーキテクチャで書いた仕様を再利用して、「仕様と直接つながった情報を用いたテスト仕様」を記述しておくことが可能です。

上図では、車両と物標（前走車）のシナリオをイメージ図のストーリーでステップ毎に設定しています。

マッピング / Mapping

前述のデザイン・アーキテクチャを踏まえて、実装したSimulinkモデルを、テストケースと組み合わせる事でテストハーネスの自動生成が可能です。

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

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

テストハーネス / Test harness

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

中央が元々のSimulinkモデルで作りこまれた部分。
左側がDRIPのテストシナリオを埋め込んだ部分。
右上が全出力パラメータをモニターするための部分。
右下がDRIPで要求に式で書かれたアサーションや、テストシナリオやローレベル要求に形式言語で書かれた期待結果を埋め込んだ部分です。
この部位が検証に使用され、得られた結果により繰り返しが効果的に促され、DRIP上に書かれた仕様書も改善されていきます。

結果 / Results

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


株式会社 NEAT

Engineered Mechatronics, Inc.