図面 (/)

技術 設計支援ツール

出願人 株式会社デンソークリエイト
発明者 栗山順次山路厚西村隆伊藤善博原健三
出願日 2019年9月23日 (1年9ヶ月経過) 出願番号 2019-172387
公開日 2021年4月1日 (3ヶ月経過) 公開番号 2021-051405
状態 特許登録済
技術分野 ストアードプログラム CAD
主要キーワード 算出項目 維持速度 不整合箇所 設計態様 要求グループ 信頼性要件 トレーサビリティ管理 ドライバー入力
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2021年4月1日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

所定の約束事に縛られることなく、自由にメタモデルやメタモデルを構成するメタクラスを変更する事ができるようにする。

解決手段

システム開発要件定義論理設計制御設計、及び物理設計と、ソフトウェア開発仕様定義基本設計、及び詳細設計の中の同一工程で、複数のメタクラスでメタモデルを定義し、いずれか一の工程でのメタクラスと他の工程でのメタクラスとを少なくとも所有関係若しくは参照関係のいずれかで関連付け、いずれか1の工程でのメタクラスの生成、変更、削除により、他のメタクラスとの所有関係若しくは参照関係に不整合を生じるとき、当該不整合を許容しつつ、当該ディスプレイビューに不整合を表示する。

概要

背景

プログラム開発手法として、特許文献1には、開発すべき対象と開発の手順を表にまとめ、モデリングツールを用いてメタモデルを定義し、メタモデルを構成するブロックを特定したりメタモデルの意味を定めたりする手法が示されている。

概要

所定の約束事に縛られることなく、自由にメタモデルやメタモデルを構成するメタクラスを変更する事ができるようにする。システム開発要件定義論理設計制御設計、及び物理設計と、ソフトウェア開発仕様定義基本設計、及び詳細設計の中の同一工程で、複数のメタクラスでメタモデルを定義し、いずれか一の工程でのメタクラスと他の工程でのメタクラスとを少なくとも所有関係若しくは参照関係のいずれかで関連付け、いずれか1の工程でのメタクラスの生成、変更、削除により、他のメタクラスとの所有関係若しくは参照関係に不整合を生じるとき、当該不整合を許容しつつ、当該ディスプレイビューに不整合を表示する。

目的

本件の開示は上記点に鑑みてなされたもので、所定のルールに縛られることなく、自由にメタモデルの定義やメタモデルを構成するコンポーネントを変更できるようにすることを課題とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

少なくとも一工程の設計を支援する設計支援ツールであって、同一工程に、二以上のメタクラスによってメタモデルを定義し、前記同一工程の設計をこのメタモデルに基づいて行い、前記メタモデルの前記二以上のメタクラス間を少なくとも所有関係と参照関係のいずれか一つの関係によって関連付け、前記同一工程での設計結果は、ディスプレイビューとして表示され、前記二以上のメタクラスのいずれか一のメタクラスの生成、変更、削除により前記二以上のメタクラスの他のメタクラスとの前記所有関係若しくは前記参照関係の少なくとも一つに不整合を生じるとき、当該不整合を許容しつつ、前記ディスプレイのビューに前記不整合を表示する設計支援ツール。

請求項2

少なくとも二工程の設計を支援する設計支援ツールであって、同一工程に、一以上のメタクラスによってメタモデルを定義し、前記同一工程の設計をこのメタモデルに基づいて行い、いずれか一の工程でのメタクラスと、他の工程でのメタクラスとを少なくとも所有関係と参照関係のいずれか一つの関係によって関連付け、前記メタモデルに基づく設計結果は、ディスプレイにビューとして表示され、前記いずれか一の工程での前記メタクラスの生成、変更、削除により、前記他の工程での前記メタクラスとの前記所有関係若しくは前記参照関係の少なくとも一つに不整合を生じるとき、当該不整合を許容しつつ、前記ディスプレイの前記ビューに当該不整合を表示する設計支援ツール。

請求項3

少なくとも一工程の設計を支援する設計支援ツールであって、同一工程に、一以上のメタクラスによってメタモデルを定義し、前記同一工程の設計をこのメタモデルに基づいて行い、前記メタモデルに基づく設計結果に対応する二以上のコンポーネントの相互の関係を少なくとも所有関係と参照関係のいずれか一つの関係によって関連付け、前記設計結果は、ディスプレイにビューとして表示され、前記設計結果に対応する前記二以上のコンポーネントの何れか一つのコンポーネントの生成、変更、削除により、前記二以上のコンポーネントの他のコンポーネントに不整合を生じるとき、当該不整合を許容しつつ、前記ディスプレイの前記ビューに当該不整合を表示する設計支援ツール。

請求項4

前記メタモデルに基づく設計は、システム開発要件定義論理設計制御設計、及び物理設計と、ソフトウェア開発仕様定義基本設計、及び詳細設計の中の工程で行う請求項1乃至3いずれか記載の設計支援ツール。

請求項5

前記いずれか一のメタクラスの生成、変更、削除は、前記ディスプレイの前記ビューで行う請求項1若しくは2記載の設計支援ツール。

請求項6

前記いずれか一のメタクラスの生成、変更、削除は、前記ディスプレイの前記ビューに反映される請求項1若しくは2記載の設計支援ツール。

請求項7

前記いずれか一の前記コンポーネントの生成、変更、削除は、前記ディスプレイの前記ビューで行う請求項3記載の設計支援ツール。

請求項8

前記いずれか一の前記コンポーネントの生成、変更、削除は、前記ディスプレイの前記ビューに反映される請求項3記載の設計支援ツール。

技術分野

0001

本明細書の記載は、自動車自動運転等の大規模なシステムの開発に使用可能な設計支援ツールに関する。

背景技術

0002

プログラム開発手法として、特許文献1には、開発すべき対象と開発の手順を表にまとめ、モデリングツールを用いてメタモデルを定義し、メタモデルを構成するブロックを特定したりメタモデルの意味を定めたりする手法が示されている。

先行技術

0003

米国特許出願公開第2010/0162208号明細書

発明が解決しようとする課題

0004

特許文献1に記載のメタモデル生成装置は、その内容を厳格に適用するメタモデルと、書き換え可能なメタモデルとを定めている。そして、書き換え可能なメタモデルに関しては、例えば、AがBから派生し、AとBとはCと複合関係にあり、かつ、CのAに対する関係が1:1に対応する場合に、AとCとの関係においてAをBの形に置き換えるなどとする手法を開示している。

0005

しかしながら、実際のプログラムの開発においては、設計者はメタモデルの中で所定のルールに縛られること無く、自由度をもって定義や関連する動作を変更できるようにすることのニーズが高い。一方で、大きなシステム開発では関連するメタモデルも多く、且つ、多くの開発者が夫々対応するメタモデルを同時平行的に開発することも通常である。

0006

本件の開示は上記点に鑑みてなされたもので、所定のルールに縛られることなく、自由にメタモデルの定義やメタモデルを構成するコンポーネントを変更できるようにすることを課題とする。その上で、変更によってシステム全体に不整合が生じた場合に容易に修正できるようにすることを課題とする。

課題を解決するための手段

0007

本件明細書の第1の開示は、少なくとも一工程の設計を支援する設計支援ツールである。そして、同一工程に、二以上のメタクラスによってメタモデルを定義し、同一工程の設計をこのメタモデルに基づいて行う。

0008

第1の開示は、メタモデルの二以上のメタクラス間を少なくとも所有関係と参照関係のいずれか一つの関係によって関連付け、同一工程での設計結果は、ディスプレイビューとして表示する。そして、いずれか一のメタクラスの生成、変更、削除により、他のメタクラスとの所有関係若しくは参照関係の少なくとも一つに不整合を生じるとき、当該不整合を許容しつつ、ディスプレイのビューに不整合を表示する設計支援ツールである。

0009

この第1の開示によれば、設計者は特別なルールに縛られることなく、自由にメタクラスの生成、変更、削除ができるので、自由度の高い設計支援ツールとすることができる。かつ、メタクラスの生成、変更、削除で他のメタクラスとの間で不整合が発生したときには、その不整合箇所をディスプレイのビューに表示するので、設計者は不整合に気づき、通常の設計操作で不整合を解消することができる。

0010

本件明細書の第2の開示は、少なくとも二工程の設計を支援する設計支援ツールである。そして、同一工程に一以上のメタクラスによってメタモデルを定義し、同一工程の設計をこのメタモデルに基づいて行う。

0011

第2の開示は、いずれか一の工程でのメタクラスと、他の工程でのメタクラスとを少なくとも所有関係と参照関係のいずれか一つの関係によって関連付け、いずれか一の工程での設計結果は、ディスプレイにビューとして表示される。

0012

そして、第2の開示は、いずれか一の工程でのメタクラスの生成、変更、削除により、他の工程でのメタクラスとの所有関係若しくは参照関係の少なくとも一つに不整合を生じるとき、当該不整合を許容しつつ、ディスプレイのビューに当該不整合を表示する設計支援ツールである。

0013

この第2の開示によれば、設計者は特別なルールに縛られることなく、自由にメタモデルの生成、変更、削除ができるので、自由度の高い設計支援ツールとすることができる。かつ、メタクラスの生成、変更、削除で他のメタモデルとの間で不整合が発生したときには、その不整合箇所をディスプレイのビューに表示するので、設計者は不整合に気づき、通常の設計操作で不整合を解消することができる。

0014

本件明細書の第3の開示は、少なくとも一工程の設計を支援する設計支援ツールである。そして、同一工程に一以上のメタクラスによってメタモデルを定義し、同一工程の設計をこのメタモデルに基づいて行う。

0015

第3の開示は、メタクラスに基づく設計結果に対応するコンポーネントが二以上あり、二以上のコンポーネントの相互の関係を少なくとも所有関係と参照関係のいずれか一つの関係によって関連付けている。そして、いずれか一工程での設計結果は、ディスプレイにビューとして表示される。

0016

第3の開示は、設計結果のいずれか一のコンポーネントの生成、変更、削除により、他のコンポーネントの所有関係若しくは参照関係の少なくとも一つに不整合を生じるとき、当該不整合を許容しつつ、ディスプレイのビューに当該不整合を表示する。

0017

この第3の開示によれば、設計者は特別なルールに縛られることなく、自由に設計結果のコンポーネントの生成、変更、削除ができるので、自由度の高い設計支援ツールとすることができる。かつ、設計結果のコンポーネントの生成、変更、削除で他のコンポーネントとの間で不整合が発生したときには、その不整合箇所をディスプレイのビューに表示するので、設計者は不整合に気づき、通常の設計操作で不整合を解消することができる。

0018

本件明細書の第4の開示は工程に関し、工程は、システム開発の要件定義論理設計制御設計、及び物理設計と、ソフトウェア開発仕様定義基本設計、及び詳細設計の中の工程である。第4の開示に関する工程は、大規模なシステムの開発に適している。

0019

本件明細書の第5の開示は、いずれか一の工程でのメタクラスの生成、変更、削除はディスプレイのビューで行うことができる。設計者は、ディスプレイのビューを見ながら、キーボードマウス等で操作できるので、特別なプログラム能力が要求されることなく、簡易に設計を行うことができる。

0020

本件明細書の第6の開示は、いずれか一の工程でのメタクラスの生成、変更、削除はディスプレイのビューに反映される。設計者は、ディスプレイのビューを見ながら設計結果を検討することができるので、設計が容易となる。

0021

本件明細書の第7の開示は、第5の開示と同様、いずれか一の工程での設計結果のコンポーネントの生成、変更、削除はディスプレイのビューで行うことができる。設計者は、ディスプレイのビューを見ながら、キーボードやマウスで操作できるので、特別なプログラム能力が要求されることなく、簡易に設計を行うことができる。

0022

本件明細書の第8の開示も、第6の開示と同様、いずれか一の工程での設計結果のコンポーネントの生成、変更、削除はディスプレイのビューに反映される。設計者は、ディスプレイのビューを見ながら設計結果を検討することができるので、設計が容易となる。

図面の簡単な説明

0023

図1は、システム開発の開発手順を示す説明図である。
図2は、メタモデルを示す説明図である。
図3は、システム開発の要件定義のメタモデルを示す説明図である。
図4は、システム開発の要件定義の設計結果を示す説明図である。
図5は、システム開発の論理設計のメタモデルを示す説明図である。
図6は、システム開発の論理設計の設計結果を示す説明図である。
図7は、システム開発の制御設計のメタモデルを示す説明図である。
図8は、システム開発の制御設計の設計結果を示す説明図である。
図9は、システム開発の物理設計のメタモデルを示す説明図である。
図10は、システム開発の物理設計の設計結果を示す説明図である。
図11は、ソフトウェア開発の仕様定義のメタモデルを示す説明図である。
図12は、ソフトウェア開発の仕様定義の設計結果を示す説明図である。
図13は、ソフトウェア開発の基本設計のメタモデルを示す説明図である。
図14は、ソフトウェア開発の基本設計の設計結果を示す説明図である。
図15は、ソフトウェア開発の詳細設計のメタモデルを示す説明図である。
図16は、ソフトウェア開発の詳細設計の設計結果を示す説明図である。
図17は、ソフトウェア開発の詳細設計の設計結果を示す説明図である。
図18は、データベースとビューとの関係を示す説明図である。
図19は、データベースとビューとの関係を示す説明図である。
図20は、ビューの例を示す説明図である。
図21は、データベースのデータ構造を示す説明図である。
図22は、設計結果間の不整合を示す説明図である。
図23は、設計結果間の不整合を示す説明図である。
図24は、設計結果間の不整合を示す説明図である。
図25は、メタモデルと設計結果間の不整合を示す説明図である。
図26は、導出関係を示す説明図である。
図27は、導出関係を示す説明図である。

0024

まず、一般的なシステム開発の流れを自動車の自動運転システムの例を用いて説明する。大きな手順として、先にシステム開発100を行い、次いでそのシステムに適合したソフトウェア開発200を行う。

0025

システム開発100では、図1に示すように、最初に要件定義110を行う。要件定義110は開発目標の設定であり、例えばクルーズコントロールを行うと定めることである。次いで、論理設計120に入る。論理設計120は、機能定義及び入力と出力とを定めることである。クルーズコントロールのシステムでは、入力としてドライバー要請や、自動車の走行状態渋滞の有無を含めた道路の状態等がある。出力としては、どのような制御を行うかの制御項目があり、アクセルの程度、ブレーキのかけ具合ハンドル操作等がある。

0026

システム開発100は、次いで制御設計130を行う。制御設計130は回路設計で、各制御でどのような計算式を用いるのかを定める。例えば、車速の検出や障害物の検出をどのように行うのか等がある。

0027

その上で、物理設計140を行う。物理設計140は文字通り物理的にどのECUに制御を割り振るのかの設計である。例えば、車速検出センサECUで計算するのか、エンジンコントロールECUで計算させるのかの役割分担がある。

0028

ソフトウェア開発200は、以上のシステム開発100で定めた概要を具体的にソフトウェアに落とし込む開発であり、まずソフトウェアの仕様定義210を定める。上記の物理設計140で車速検出機能をエンジンコントロールECUが受け持つとした際に、このソフトウェア仕様定義210でエンジンコントロールECUのより具体的な詳細を定める。

0029

次いで、ソフトウェアの基本設計220を行う。この基本設計220ではシステム開発100で定めた各機能を複数のレイヤーに分割して、各機能毎にどのような入力を得てどのように出力するのかを定める。そして、入力と出力との間に支障がある場合にはどのようにチェックするのかを定める。

0030

その後に、ソフトウェアの詳細設計230を行う。詳細設計は具体的な演算方法フローチャート等にまとめ、プログラム言語で記載できるようにするものである。この詳細設計230によってプログラムのソースコード確定する。

0031

システム開発100でも、ソフトウェア開発200でも、別の観点で設計内容を現せば、論理式10を定め、それをどのように物理的に配置するのかの配置設計20を行い、具体的にECU上に実装する実装工程30を繰り返すこととなる。

0032

上述の説明は、最上位工程である要件定義110から下位工程へ段階的に詳細化していくトップダウン開発の設計手順を説明したが、この設計手順は工程が進むにつれて設計内容が細分化されるため、トップから一貫した設計が可能である。ただし、システム全体の完全な理解が必要とされるため、大規模で複雑なシステムでは難易度が極めて高くなる。換言すれば、ある程度詳細なレベルまで進まなければシステム開発を進めることができない。

0033

上述の説明とは逆に、最初にシステムを構成する個々のパーツ細部まで設計し、それらのパーツを組み合わせてシステムを開発するボトムアップ開発の設計手法もある。これは、すでに開発済の既存パーツを使用したり、各パーツを並行して開発したりするのに向いている。

0034

一方で、各パーツを組み合わせたときに上位工程との間で不整合が生じたり、また、各パーツ間でも不整合が発生する可能性がある。また、このボトムアップ開発は、最適なパーツの開発は出来ても、部分最適となって全体最適とはならない場合もある。

0035

本例の設計システムは、後述する柔軟性により、トップダウン開発にも、ボトムアップ開発にも適用することができる。ただ、トップダウン開発を行うにしろ、ボトムアップ開発を行うにしろ、どのようなシステムを作るのかを決める要件定義110から詳細な制御を定義して具体的なフローチャート等を作成するソフトウェアの詳細設計230までに多数の定義が存在し、それらは常に矛盾なく引き継がれなければならない。

0036

本例の設計支援ツールでは、システム開発100の要件定義110からソフトウェア開発200の詳細設計230までの一連開発設計を全て受け持つことが可能である。但し、本例の設計支援ツールは、必ずしも全ての工程に用いなければならないものではない。開発の内容に応じては、例えば、システム開発100のみに使用することも、システム開発100の要件定義110のみの工程に使用することも、システム開発100の要件定義110とソフトウェア開発200の仕様定義210のみの工程に使用することも可能である。

0037

本例の設計支援ツールが採用する構成は、上述のシステム開発100の要件定義110からソフトウェア開発200の詳細設計230までの開発を、まず、設計すべき項目をメタモデル300として表し、メタモデル300に基づいて設計を行う。

0038

従って、各設計工程110、120、130、140、210、220、及び230には、それぞれ開発の方向性を定めるメタモデル300の策定と、メタモデル300に基づきなされる設計結果305とがある。

0039

メタモデル300は、図2に示すように、メタモデルを構成する要素であるメタクラス330間の関係を線で結んで両者の関係を規定している。図2の例で、第1メタクラス3301と第2メタクラス3302とを結ぶ先端に黒四角を示す線は、上下関係で規定する所有301を表し、下位である第2メタクラス3302は上位である第1メタクラス3301の要素であることを示す。

0040

図2の例で、第2メタクラス3302と第3メタクラス3303とを結ぶ矢印は参照302を表し、第2メタクラス3302で規定する内容、例えばフィールドは、第3メタクラスで規定するフィールドを参照して動作するものであることを示す。参照302は両メタクラス間でやり取りされるデータに何らかの関連があることを示す。

0041

例えば、第2メタクラス3302が入力ポートである場合、第2メタクラス3302の入力ポートは、第3メタクラス3303の制御ロジック要素のデータを参照302する関係となる。そして、第2メタクラス3302と第3メタクラス3303との関係は、上下関係である必要はなく、また、同一工程である必要もない。他の工程で設計した制御ロジック要素の内容を第2メタクラス3302の入力ポートが参照302することも可能である。

0042

図2の例で、第3メタクラス3303と第4メタクラス3304とを結ぶ先端に白三角を示す線は継承303を表し、第4メタクラス3304は第3メタクラス3303と同一レベルであること、換言すれば、第4メタクラス3304は第3メタクラス3303の一種類であることを示す。

0043

例えば、第3メタクラス3303が制御ロジック要素で、第4メタクラス3304が波形である場合、制御ロジック要素の一種類として波形が挙げられることを示している。

0044

図2の例で、破線は導出304を表し、導出304は他の工程との関係を示している。例えば、システム開発100及びソフトウェア開発200の各工程の中で、一の工程のメタクラス330と他の工程のメタクラス330が導出304関係で結ばれていると、一の工程のメタクラス330の内容に基づいて他の工程のメタクラス330が規定されることを示している。この導出304は、トレース情報として用いられるもので、詳細は後述するが、導出304の関係を要求元要求先で特定することで、工程を跨ぐ設計情報トレースが可能となる。

0045

設計結果305は、メタクラス330の内容を具体的にしたものである。例えば、メタクラス330が入力ポートである場合、設計結果305は、第1入力ポート、第2入力ポート、及び第3入力ポートの三つの入力ポートを用いるなど、入力ポートの名称やサイズ等より具体的内容を規定する。そのため、一のメタクラスに基づく設計結果305が複数のコンポーネントを持つ場合もある。各コンポーネント間の関係としては、所有301と参照302がある。

0046

以下に、本例の設計支援ツールの使用例を、自動運転システムの開発に使用する例を用いてより詳細に説明する。

0047

図3は、要件定義110のメタモデル300の一例を示す。メタクラス330としてシステム要件111を挙げており、更に、システム要件111は、第1システム要件1110とこの第1システム要件1110と所有301の関係にある第2システム要件1111が規定される。即ち、メタモデル300ではシステム要件111が多重であることを規定している。

0048

要件定義110のメタモデル300では、第2システム要件1111は、機能要件112のメタクラス330と非機能要件113のメタクラス330が継承303の関係にある。そして、非機能要件113のメタクラス330には、信頼性要件114、保守性要件115及び効率性要件116のメタクラス330が継承303の関係にある。従って、第2システム要件1111には、機能要件112と、信頼性要件114、保守性要件115及び効率性要件116の非機能要件113とがあることが規定される。

0049

要件定義110の設計は、このメタモデル300に従って行われる。例えば図4に示すように、クルーズコントロールの場合には、定速走行117を行うことが含まれ、定速走行117を行うためには、ドライバーによる設定1171と実際に定速走行を行う上での各種要件である走行1172が必要になる。ドライバーによる設定には、設定スイッチ等各種機器からの信号入力を確認する。

0050

走行1172を定めるためには、更に、目標速度維持に必要な加減速度を算出してエンジンコントロールECUに要求を出力する定速走行の実施118と、ドライバーの要求に応じた各種モードで速度調整を行う目標速度の調整119が必要となる。定速走行の実施118を行うに際しても、追従モード先行車の有無や先行車の速度等を検出して車速の維持速度算出1181を行ったり、より適した車速とすべくエンジンコントロールECUに制御要求1182を行ったりする。

0051

目標速度の調整119を行うためには、ドライバーからの目標速度の増加要求があったか、逆に目標速度の減少要求があったか等の要求を確認する。そして、目標速度を変更する場合にも急な加減速控えてなだらかな増減とする。特に、追従モードでは目標速度と先行車の速度との比較等、各種の検討項目1191を検討することとなる。

0052

このように、要件定義110の設計では、システムが達成したい機能の概要をシステム要件111として定め、その機能に関連する動作や、関連する制御対象等を書き出すこととなる。定速走行117、設定1171、走行1172、定速走行の実施118、目標速度設定119、項目1181、1182、及び検討項目1191は、いずれも多重化されたシステム要件111に対応し、かつ、システム要件111の機能要件112に対応する。

0053

そして、定速走行117、設定1171、走行1172、定速走行の実施118、目標速度設定119、項目1181、1182、及び検討項目1191の各項目が、設計結果305での各コンポーネントとなる。各コンポーネント間の関係は参照302の関係となる。

0054

図5は、論理設計120のメタモデル300の一例を示す。システム1201のメタクラス330はシステム機能構造1200と所有301の関係にあり、システム機能構造1200はシステム1201を含むことを規定している。また、システム1201は、入力ポート1202、出力ポート1203及びサブシステム1204のメタクラス330と所有301の関係にあり、システム1201は、入力ポート1202、出力ポート203及びサブシステム1204を有している。同様に、サブシステム1204も入力ポート1205と出力ポート1206を有している。

0055

また、システム1201は、システム構成要素1207のメタクラス330と継承303の関係にあり、システム1201にはシステム構成要素1207が含まれることが規定されている。更に、システム構成要素1207のメタクラス330は導出304の関係が規定され、この導出304の関係は要件定義110のメタモデル300のシステム要件111、より具体的には第2システム要件1111のメタクラス330に結ばれている。従って、論理設計120のシステム1201は、システム構成要素1207を介して、要件定義110のシステム要件111から導出されるものであることが規定される。

0056

論理設計120の設計は、図6に示すように、例えばドライバーの要求判定項目121では、ドライバーから減速を求める操作がなされたかどうかの判定を行う減速判定1211や、増速を求める操作がされたか否かの判定を行う増速判定1212に基づき、車速設定判断1213を行う。また、ドライバーが先行車との車間距離縮める操作をしたかどうかの判定を行う車間短判定1214や、車間距離を長くとる操作をしたか否かの判定を行う車間長判定1215を行って、車間距離を定める車間設定判断1216を行う。

0057

同様に、車速算出項目122では、各種センサからの信号に基づいて加減速度の演算を行う加速度演算1221、および、実際の車輪速度を定める車輪演算1222によって車速を算出する。そして、この車速算出項目122で演算された車速と、ドライバーの要求判定項目121の車速設定判断1213で判断された要求車速との差を、車速差分算出項目123で計算する。同様に、車間距離差分算出項目124では、要求判定項目121で定めた車間設定判定1216と車間距離算出項目125で定めた車間距離との差分を車間距離差分演算1241にて計算する。

0058

この車間距離差分算出項目124からの設定車間距離と車間距離差分、車速差分算出項目123からの設定車速と車速差分、システム状態判定項目126からのクルーズコントロールのオンオフとクルーズコントロールのモード等の各種の情報が、ドライバー通知出力項目127と目標加減速量算出項目128に入力する。

0059

ドライバー通知出力項目127はドライバーに車速等の情報をいかに素早くかつ適正に表示するかを表示出力1271で判断して、メータ等各種の機器に出力する情報を定める。目標加減速量算出項目128では、エンジンコントロールECUに出力する目標加減速度を演算する。

0060

メタモデル300との関係では、例えば、システム機能構造1200が全体構造を示し、そこに含まれるシステム1201にはドライバーの要求判定項目121、車速算出項目122、車速差分算出項目123、車間距離差分算出項目124、車間距離算出項目125、システム状態判定項目126、ドライバー通知出力項目127及び目標加減速量算出項目128が対応する。各システム1201には入力ポート1202と出力ポート1203が設けられている。

0061

システム1201としてドライバーの要求判定項目121を挙げると、そのサブシステム1204に対応するものは、減速判定1211、増速判定1212、車速設定判断1213、車間短判定1214、車間長判定1215、及び車間設定判断1216があり、各サブシステム1204は入力ポート1205と出力ポート1206を備えている。

0062

これをメタクラス330と設計結果305のコンポーネントとの関係にすれば、メタクラス330にはサブシステム1204が対応し、減速判定1211、増速判定1212、車速設定判断1213、車間短判定1214、車間長判定1215、及び車間設定判断1216が設計結果305の各コンポーネントとなる。

0063

次に、制御設計130のメタモデル300を図7に基づいて説明する。制御設計130は、論理設計120のシステム1201やサブシステム1204での制御を設計するもので、入力ポート1300及び出力ポート1301は、システム1201の入力ポート1202、出力ポート1203や、サブシステム1204の入力ポート1205、出力ポート1206に対応する。

0064

図7に示すように、制御ロジック要素1302は入力ポート1300及び出力ポート1301と参照302の関係にあり、論理設計120の入力ポート及び出力ポートはこの制御ロジック要素1302を参照している。

0065

そして、制御ロジック要素1302のメタクラス330には、波形1303、パルス1304、定数1305及び演算1306が継承303の関係にあり、波形1303、パルス1304、定数1305及び演算1306を用いて制御ロジックが組まれることが規定されている。

0066

更に、演算1306のメタクラス330は、単項演算1307と多項演算1308のメタクラス330と継承303の関係にあり、かつ、単項演算1307と多項演算1308のメタクラス330にもそれぞれ複数のメタクラス330が継承303関係にある。これらのメタクラス330に含まれる項目を用いて演算1306を行うことが規定されている。

0067

図8は、制御設計130の一例を示す。この例は、論理設計120のシステム状態判定項目126に対応する。入力ポート1202に対応するイグニッションスイッチが入っているか否か12021と、クルーズコントロールのオンオフの状態12022との信号を、第1アンド回路1311で演算する。そして、この第1アンド回路1311からの信号とユニット遅れ信号とをXオア回路1312で論理演算して、クルーズコントロールのオンオフを出力する。この出力12031は、論理設計120の出力ポート1203に対応する。

0068

また、Xオア回路1312からの出力とクルーズコントロールのモード信号12023を、第2アンド回路1313で演算する。ここで、モード信号12023は、論理設計120の入力ポート1202に対応する。そして、第2アンド回路1313の出力とユニットの遅れ信号を加算回路1314で加算演算して、クルーズコントロールのモードを出力する。出力12032が、論理設計120の出力ポート1203に対応する。

0069

このように、制御設計130では論理設計120で定めた項目を具体的な論理演算式に落とし込む。メタモデル300と設計結果305との関係では、入力ポートがメタクラス330に対応する。そして、設計結果305のコンポーネントとしては、イグニッションスイッチが入っているか否か12021と、クルーズコントロールのオンオフの状態12022とが挙げられる。

0070

図9は、物理設計140のメタモデル300の一例を示す。最上位にシステム物理構造1400のメタクラス330があり、要素1401のメタクラス330が所有301の関係にある。ECU1402のメタクラス330が継承303の関係にあるように、要素1401の一例はECU1402である。

0071

要素1401のメタクラス330に機能コンポーネント割り当て1403、入力ポート1404及び出力ポート1405のメタクラス330が所有301の関係にあるように、要素1401(ECU1402)には、機能コンポーネント割り当て1403、入力ポート1404及び出力ポート1405が備わっている。

0072

機能コンポーネント割り当て1403には導出304が示されており、物理設計140の機能コンポーネント割り当て1403は、論理設計120のサブシステム1204と導出304の関係にある。従って、サブシステム1204は、機能コンポーネント割り当て1403で規定される機能を達成することとなる。また、機能コンポーネント割り当て1403には、ソフトウェアの仕様定義210からの導出304もあるが、この点は後述する。

0073

図10に物理設計の設計結果305の一例を示す。この例では、役割分担するECU1402として、ブレーキECU141、自動運転を支援するADASECU142、メータECU143、エンジンコントロールECU144、及びパワステECU145が挙げられる。

0074

各ECU141、142、142、144、145に入力するセンサ信号が入力ポート1404に対応する。本例では、以下の例がある。車輪速を示すパルス信号を出力する車輪速センサ1461、内部のECUで先行車との車間距離を算出してその算出結果である車間距離信号を出力するミリ波レーダ1462、タッチパネル1463に設けられた各種ボタンの操作で判断されるドライバーの要求設定等である。ドライバーの操作例としては、クルーズコントロールのモード、車速の設定、クルーズコントロールのオンオフや、車間距離の設定等がある。

0075

イグニッションスイッチ1464からのオンオフ信号で、エンジンが運転中であるのか停止しているのかを判断する。カメラ1465からの画像情報で、車線を検出する。また、加速度センサ1466からの信号で、ヨーレートや進行方向の加減速の加速度を検出する。ステアリングセンサ1467からの信号により、ハンドル操舵角度を検出する。

0076

各ECU1402の処理内容としては、例えば、自動運転を支援するADASECU142には以下のものがある。車間距離算出1420、車速差分算出1421、車間距離差分算出1422、ドライバー入力判定1423、目標加減速量算出1424、システム状態判定1425、及び車両状態判定1426である。

0077

各ECU1402での演算結果が出力される対象としては、メータECU143からの設定した車間距離に関する表示、クルーズコントロールのオンオフの表示、設定した車速の表示、及びクルーズコントロールのモードの表示がある。これらの表示が車載ディスプレイ1471に出力される。

0078

また、エンジンコントロールECU144からは、吸入空気量を制御するスロットルバルブに対して、より具体的には、スロットルバルブを回動させるスロットルモータ1472に対して、スロットルモータ1472の回転信号が出力される。パワステECU145からは、パワーステアリング装置に対して、パワーステアリングモータ1473の回転信号が出力される。これらの出力が、メタモデル300の出力ポート1405に対応する。

0079

メタモデル300と設計結果305との関係は、既述の通りであるが、例えば、メタクラス330をECU1402とした場合、ブレーキECU141、自動運転を支援するADASECU142、メータECU143、エンジンコントロールECU144、及びパワステECU145が設計結果305のコンポーネントに対応する。

0080

続いて、ソフトウェア開発200の詳細を説明する。ソフトウェアの仕様定義210のメタモデル300の一例を図11に示す。所有301の関係は、ソフトウェア要求仕様2100、要求グループ2101、ソフトウェア要求2102の各メタクラス330の間にある。従って、ソフトウェア要求仕様2100は要求グループ2101を含み、要求グループ2101はソフトウェア要求2102を含む多重の構造となる。

0081

ソフトウェア要求2102のメタクラス330には、機能要求2103と非機能要求2104のメタクラス330が継承303の関係にあり、非機能要求2014のメタクラス330は、更に、信頼性要求2105、効率性要求2106、及び保守性要求2107のメタクラス330が継承303の関係にある。従って、ソフトウェア要求2102には、機能要求2103と、信頼性要求2105、効率性要求2106、保守性要求2107の非機能要求2104とが規定される。

0082

ソフトウェア要求2102のメタクラス330は、上述のシステム開発100における物理設計140の機能コンポーネント割り当て1403のメタクラス330と導出304の関係にある。従って、機能コンポーネント割り当て1403で規定される機能には、ソフトウェア要求2102での機能要求2103や非機能要求2104が対応する。

0083

このソフトウェア開発200におけるソフトウェアの仕様定義210の設計結果305の一例を、図12に示す。ソフトウェア仕様定義210では、各ECU1402でどのようなソフトウェアを受け持つのかを定める。例えば、自動運転を支援するADASECU142に対する項目211では、ECUに共通する保守性に対する保守性要求2120、ECUに共通する使用性に対する使用性要求2121、ECUの効率性に対する効率性要求2122、及び、ECUの信頼性に対する信頼性要求2123がある。

0084

各要求2120〜2123に対しては更に下のレイヤーが定められる。例えば、保守性要求2120に対しては、ソフトウェアを他の車両にも用いるときにソフトウェアの変更箇所を少なくするソフトウェア保守性要求2130が挙げられる。また、使用性要求2121に対しては、ユーザー(ドライバー)に対して自動運転を支援する機能の内、何が有効となっているのかを常に表示する機能の状態表示要求2131が挙げられる。

0085

効率性要求2122に対しては、プログラムサイズ要求2132とCPU負荷要求2133がある。プログラムサイズ要求2132は、例えば、各種メモリーの容量に対して実際の使用領域を70%以内に抑える要求である。また、CPU負荷要求2133は、例えば、定常的な自動運転支援の状態で、CPUの平均負荷を60%以内に抑える要求である。定常的な自動運転支援の例として、例えば、車線に沿った走行(レーンキーピングアシスト)を実行中で、緊急ブレーキを常に操作できるよう準備しつつ、先行車との車間距離を保ちながら、一定速度で追従走行をする例が挙げられる。

0086

信頼性要求2123に対しては、例えば、ソフトウェアを構成するパーツの一部に不具合が生じた際にも、その不具合の影響を受けていない他のパーツでは動作を継続させるパーツ信頼性要求2134が挙げられる。これらの各要求2120〜2123や2130〜2134は、メタモデル300の非機能要求2104に対応する。従って、メタモデル300と設計結果305との関係では、非機能要求2104がメタクラス330であり、各要求2120〜2123や2130〜2134は、設計結果305のコンポーネントに対応する。
図13は、ソフトウェア基本設計220のメタモデル300の一例を示す。ソフトウェア基本設計220ではソフトウェア仕様定義210で定めた要求を実現するための、機能とデータとを定義する。ソフトウェア構造2200、レイヤー2201及び要素2202のメタクラス330が所有の関係にあるので、ソフトウェア構造2200にはレイヤー2201が含まれ、レイヤー2201には要素2202が含まれる。

0087

また、レイヤー2201及び要素2202のメタクラス330がソフトウェア構成要素2203のメタクラス330と継承303の関係にあるので、ソフトウェア構成要素2203の種類としてレイヤー2201及び要素2202が挙げられることとなる。

0088

そして、ソフトウェア構成要素2203のメタクラス330は、ソフトウェア仕様定義210のソフトウェア要求2102のメタクラス330と導出304の関係にある。従って、ソフトウェア基本設計220のレイヤー2201やレイヤー2201に含まれる要素2202は、ソフトウェア仕様定義210のソフトウェア要求2102と関係づけられている。

0089

このソフトウェア基本設計220の設計結果305の一例を、図14に示す。例えば、自動運転ではアプリケーションレイヤー(APPレイヤー)221には、車速偏差2210、車間距離偏差2211、及び目標制御量2212の項目がある。その下のレイヤーであるアプリケーションフレームワークレイヤー(AFWレイヤー)222には、先行車の有無2220、クルーズコントロールの制御状態2221、外部システム制御量2222の項目が入る。

0090

更にその下のレイヤーであるプラットフォームレイヤー(PFレイヤー)223には、先行車情報2230、自車走行情報2231、外部システム状態2232、スイッチ状態2233、及び外部システム要求2234の項目がある。そして、最も下のレイヤーであるハードウェアレイヤー(HWレイヤー)224には、上記各項目の前提となる信号を出力する各機器として、車載機器にも利用可能なネットワークコントローラ(受信)2240、イグニッションスイッチ2241、各種スイッチ2242、及び車載機器にも利用可能なネットワークのコントローラ(送信)2243がある。

0091

従って、APPレイヤー221、AFWレイヤー222、PFレイヤー223、HWレイヤー224が、メタモデル300のレイヤー2201に対応する。そして、車速偏差2210、車間距離偏差2211、及び目標制御量2212の項目、先行車の有無2220、クルーズコントロールの制御状態2221、外部システム制御量2222の項目、先行車情報2230、自車走行情報2231、外部システム状態2232、スイッチ状態2233、及び外部システム要求2234の項目、車載機器にも利用可能なネットワークのコントローラ(受信)2240、イグニッションスイッチ2241、各種スイッチ2242、及び車載機器にも利用可能なネットワークのコントローラ(送信)2243が、各レイヤー2201に含まれる要素2202に対応する。

0092

なお、図14では、APPレイヤー221からHWレイヤー224までの各レイヤー間の関係を破線の矢印で示している。例えば、HWレイヤー224のイグニッションスイッチ2241からの信号はPFレイヤー223の外部システム状態2232の項目に取り込まれ、スイッチ状態2233の項目と共にAFWレイヤー222のクルーズコントロールの制御状態2221の項目に取り込まれる。そして、この制御状態2221は、APPレイヤー221の車速偏差2210と車間距離偏差2211に出力する。

0093

従って、図14の矢印は、設計結果305の各レイヤー2201間の関係を示すもので、メタモデル300の矢印とは関係ない。

0094

メタモデル300と設計結果305との関係も上述の通りである。例えば、レイヤー2201がメタクラス330であり、APPレイヤー221、AFWレイヤー222、PFレイヤー223、HWレイヤー224が、設計結果305のコンポーネントである。

0095

ソフトウェアの詳細設計230は、この基本設計220の機能を実現するための詳細な制御を定義するものである。メタモデル300の一例を図15に示す。要素2300のメタクラス330は、基本設計220の要素2202のメタクラス330と同じである。

0096

要素2300のメタクラス330には、関数2301、データ2302、入力ポート2303及び出力ポート2304の各メタクラス330と所有301の関係にある。従って、要素2300は、関数2301、データ2302、入力ポート2303及び出力ポート2304を備えている。

0097

データ2302のメタクラス330は関数2301のメタクラス330にも所有301の関係となっているので、データ2302は、要素2300に用いられると共に、関数2301にも用いられることとなる。

0098

このソフトウェア詳細設計230の設計結果305は、例えば、フローチャートを用いたり、また、図16のように、表を用いたりして演算処理を規定する。図16の例では、入力項目231として「1.クルーズコントロールの状態」、「2.車両の速度」、「3.先行車の有無」、「4.実測車間距離」、「5.設定車間距離」がある。出力項目232としては、「1.実測車間距離と設定車間距離との差」がある。内部データ233には、「1.目標車速」と「2.実測車速」がある。

0099

このソフトウェア詳細設計230の設計結果305は、上記例以外に、例えば、図17のように状態遷移制御を用いてクルーズコントロールスイッチの操作がなされた際の状態が追従走行234と定速走行235とで切り替わることを示したりする。なお、図17の状態遷移では追従走行234と定速走行235の定義が記載されてないが、実際の詳細設計では定義を詳細に規定する。

0100

メタモデル300と設計結果305との関係も上述の通りである。例えば、入力項目231がメタクラス330であり、「1.クルーズコントロールの状態」、「2.車両の速度」、「3.先行車の有無」、「4.実測車間距離」、「5.設定車間距離」が設計結果305のコンポーネントである。

0101

このように、本例の設計支援ツールは、システム開発100の要件定義110からソフトウェア開発200の詳細設計230までの一連の開発設計を全てメタモデル300に定義して、このメタモデル300の定義内容に沿って設計を進める。そして、その間のメタモデル300の情報も設計結果305も一つのデータベース310(図18)で記録している。なお、データベース310は、物理的に一つである必要はなく、分散配置されてもよい。

0102

例えば、データベース310に設計結果として、サブシステム3100にシステム状態判定3101が書き込まれると、そのシステム状態判定3101は、図18に示すように、論理設計120のシステム状態判定126としても表示でき、物理設計140のシステム状態判定1425としても表示できる。

0103

本例の設計支援ツールは、図19に示すように、複数の形式で設計結果305を表示することができる。換言すれば、本例の設計ツールは、複数の画面から設計情報を入力することができる。図19はソフトウェア基本設計220の設計結果305を示しているが、左のビュー307は実体関連図であるERダイヤグラムで、図14と同じである。このERダイヤグラムの記載内容は、右側画面表形式のビュー307でも表示できる。なお、ビュー307は、液晶ディスプレイ320(図27)に表示される。

0104

表形式のビュー307は、APPレイヤー221の債務として、「加減速の目標量を車速と車間距離との差から表示する。」と記載し、要素2202には、「1.車間距離偏差2211」、「2.目標制御量2212」、「3.車速偏差2210」の名称と、それぞれの要素2202の責務が記載されている。AFWレイヤー222以下のレイヤー2201に付いても同様に表示される。

0105

これは、ERダイヤグラムのビュー307でも、表形式のビュー307でも、単に表示の仕方が異なるのみで、データベース310内では同じ情報として格納されているからである。

0106

本例の設計ツールで用いるビュー307の形式は、ERダイヤグラム3070、表形式のドキュメントフォーム3072に限らず、図20に示すように、ツリーダイアグラム3071やツリーグリッド3073として表すこともできる。設計者は設計の各ニーズに応じて使用しやすいビュー307を適宜選択することができる。全体の構造を概観するには、ERダイヤグラム3070が望ましく、各項目の詳細を定義するには表形式のドキュメントフォーム3072が望ましい。

0107

但し、図20の4種類のビュー307は、いずれも設計を行う上で利用しやすい例であるが、本例の設計支援ツールで用いるビュー307は、この4種類に限定されるものではない。逆に、ビュー307の種類を4種類より少なくすることも可能である。

0108

本例の設計支援ツールは、既述のように、各ビュー307の表示は、単にデータベース310に格納されているデータに基づき、各コンポーネントの見せ方を変更するのみであるため、いずれのビュー307からの入力も、データベース310には同様な入力となる。

0109

図21は、データベース310内でのデータの持ち方の例を示す。例えば、物理設計140のADASECU142の出力ポート1405とメータECU143の入力ポート1404との接続148を定める場合、データベース310内では、接続148自身のID1480と、関連元のID1481及び関連先のID1482によって特定を行う。そして、接続148に関連する各種のデータが格納される。例えば、名称、データ自体、データのバージョン削除情報等がある。

0110

データベース310に格納される情報として、メタクラス330間の関係もある。図21の接続148は参照302の関係であるが、上述の通り、メタクラス330間の関係には所有301、参照302、継承303、及び導出304があるので、その関係がデータベース310に格納される。

0111

データベース310に格納される情報として、メタクラス330とそれに基づく設計結果305のコンポーネントとの関係もある。各コンポーネントとのID情報と、そのコンポーネントとに関係するメタクラス330のID情報が格納される。

0112

データベース310に格納される情報として、他には設計結果305のコンポーネント間の情報もある。記述の通り、メタクラス330に複数の他には設計結果305のコンポーネントが対応する場合がある。その際には、メタクラス330とコンポーネント間の情報のみでなく、コンポーネント間の情報もデータベース310に格納される。コンポーネント間の関係としては、所有と参照がある。

0113

このように、本例の設計支援ツールでは、図20に示した様々なビュー307を用いてメタモデル300を定義したり、メタモデル300に対応させて設計したりすることができる。そして、いずれか一つのビュー307で設計するのみで、設計結果305は、図20の全てのビュー307形式で表示することができる。

0114

そして、いずれか一つのビュー307で設計結果305を変更すれば、変更結果は関連する全てのビュー307に自動で反映される。そのため、関連する設計結果305は常に最新となり、本例の設計支援ツールでは更新漏れ心配がない。

0115

図19の例では、レイヤーを示す左図のAPPレイヤー221の車速偏差2210に変更を加えれば、右図のドキュメントフォームでは、APPレイヤー221の責務やコンポーネントを説明する文書にその変更が反映される。図18の例では、システム開発の論理設計120でシステム状態判定126に変更を加えれば、システム開発の物理設計140のADASECU142のシステム状態判定1425にもその変更が反映される。

0116

このように、本例の設計支援ツールでは特定のルールに縛られることなく、設計の各工程でメタモデル300や設計結果305を自由に変更可能である。そのため、大まかな設計をトップダウン開発で定めるのみで、各コンポーネント側で検討して詳細設計を行うことができる。大規模なシステム開発に適した設計支援ツールである。

0117

同様に、本例の設計支援ツールは、下位設計で詳細設計したコンポーネントを用いて上位設計を行うに際しても、設計の各工程でメタモデル300や設計結果305の書き換えが可能なため、ボトムアップ設計にも適している。

0118

ただ、一方で、トップダウン開発で行った定義を下位工程で変更することが可能となるため、上位工程と下位工程との間や、同位工程のコンポーネント間で不整合が発生する可能性がある。逆に、ボトムアップ開発の場合には、下位工程で定義したメタモデル300や設計結果305とは異なる定義を上位工程の設計で行う必要が生じる場合もある。

0119

例えば、図22に示すように、X設計結果400でコンポーネントA401とコンポーネントB402を使用しており、そのコンポーネントB402はY設計結果410のコンポーネントB411を参照しているときに、Y設計結果410でコンポーネントB411が削除されると、X設計結果400とY設計結果410との間で不整合が発生する。

0120

また、図23に示すように、X設計結果400でコンポーネントA401とコンポーネントB402を使用しており、そのコンポーネントB402はY設計結果410のコンポーネントB411を参照しているときに、同じコンポーネントBがZ設計結果420のコンポーネントB421としても定義されている場合、Y設計結果410のコンポーネントB411とZ設計結果420のコンポーネントB421との間で不整合が発生する。

0121

他の例として、図24に示すように、Y設計結果410のコンポーネントB411がX設計結果400のコンポーネントA401を参照している状態で、X設計結果400のコンポーネントA401が削除される場合もある。引用先の設計結果305が削除され実態が無くなるという不整合が発生する。

0122

他には、図25に示すように、メタモデル300に存在しないパーツが存在する場合もある。図25の例ではユースケース308に対応するのは定速走行3080と追従走行3081であるが、追従走行3081にさらに追従テップ3082が書き加えられると、メタモデル300と設計結果305との間で不整合が発生する。

0123

本例の設計支援ツールは、上述のように設計の各時点での修正を行うことが可能であるため、このような不整合が発生することも許容している。この不整合を許容することで、設計支援ツールとしてのフレキシビリティをもたせ、設計者にストレスを与えることなく設計を継続させることができる。

0124

本例の設計支援ツールは、不整合を許容する代わりに、不整合を検出して不整合を設計者に通知し、設計者が整合性のとれたメタモデル300及びメタモデル300に基づく設計結果305に容易に修正できるようにしている。不整合の検出は、ファイルを開いたタイミングや、削除や編集マージによってメタモデル300の変更が行われたタイミングで行う。

0125

図22の例では、不整合の検出時に「削除されているモデルが見つかりました。」との表示をディスプレイ320(図27)で行い、X設計結果400のファイル名と、関連元であるコンポーネントA401のクラス名、関連a403の関連クラス名、及びコンポーネントB402が何番目のメタモデルであったかを示すコレクションインデックス番号を表示する。

0126

これは、上述の通り、データベース310にメタクラス330とそれに対応するコンポーネントA401、及びコンポーネントB402が格納されており、更に、コンポーネントA401とコンポーネントB402とが参照の関係にあることも格納されているからである。そのため、コンポーネントB402の削除により、参照の関係に不整合が生じることが検出できるのである。

0127

設計者は、このような表示を見た場合、専用の不整合修正機能を用いることなく、設計の際に通常に使用するエディタ機能を用いて修正することが可能である。例えば、Y設計結果410でコンポーネントB411が削除されている場合、コンポーネントB411が削除される前のY設計結果410を使用することで対応できる。

0128

図23の例では、不整合の検出時に「複数のファイルで重複するモデルが見つかりました。」との表示をディスプレイ320に示し、Y設計結果410とZ設計結果420のコンポーネントB411、コンポーネントB421に関する情報を表示する。

0129

データベース310には、X設計結果400のコンポーネントB402とY設計結果410のコンポーネントB411が参照の関係にあることが、それぞれのID情報と共に格納されている。かつ、X設計結果400のコンポーネントB402とZ設計結果420のコンポーネントB421が参照の関係にあることもそれぞれのID情報と共に格納されている。従って、データベース310では、参照の関係に不整合があることを検知できる。

0130

この例でも、設計者は特別な不整合修正機能を用いる必要はない。例えば、最初に見つかったコンポーネントB411を採用し、後に見つかったコンポーネントB421を読み飛ばすことでも対応できる。

0131

設計者が不整合を修正する場合でも、通常のエディタ機能を用いて、最初に見つかったコンポーネントB411を削除し、後に見つかったコンポーネントB421を採用するようにしてもよい。逆に、後に見つかったコンポーネントB421を削除することも可能である。

0132

図24の例も同様で、本例の設計支援ツールは、不整合の検出時に「親が存在しないモデルが見つかりました。」との表示をディスプレイ320に示し、X設計結果400のファイル名と、関連a403の関連クラス名を表示する。

0133

図24の例では、本例の設計支援ツールは、Y設計結果410を単体で読み込んだ場合と同じ動作となり、特別な不整合修正機能を提供することはない。設計者は、通常の設計機能を用いてX設計結果400を適切な位置に移動したり、X設計結果400の削除を解除したりすることで対応する。

0134

なお、図22図23、及び図24の例では、不整合の原因となった操作を行ったときにもエラーメッセージを表示する。例えば、図24の例では、X設計結果400の削除時にも、設計支援ツールはエラーメッセージを表示する。

0135

なお、以上の例では設計結果305のコンポーネント間の関係が参照の関係であったが、同様の不整合は所有の関係でも検出できる。データベース310には、設計結果305のコンポーネント間の情報として、参照と所有が格納されている。

0136

図25の例では、本例の設計支援ツールは、不整合の検出時に「メタモデルが存在しないモデルが見つかりました。」との表示をディスプレイ320に示し、メタモデル300のモデルファイル名と存在しないユースケース308に対応する追従ステップ3082のモデル名を表示する。

0137

データベース310では、ユースケース308のメタクラス330と設計結果305のコンポーネントとの関係が格納されている。コンポーネントとして、追従ステップ3082が加わると、追従ステップ3082はメタクラス330にない関係となるので、その不整合を検出することができる。

0138

図25の例も同様で、本例の設計支援ツールは特別な不整合修正機能の提供はしない。設計者は、通常のエディタ機能を用い、追従ステップ3082を削除することで不整合を修正することができる。

0139

本例の設計支援ツールが、上述のエラーメッセージを表示できるのは、データベース310で所有301と参照302の関係を情報として格納しているからである。所有301と参照302は異なるメタクラス330間の関係を規定しており、各工程での設計結果305のコンポーネントは、メタクラス330と関係づけられることで、この関係を踏襲している。

0140

所有301と参照302は、また、設計結果305のコンポーネント間の情報としても、データベース310に格納されている。従って、設計結果305のコンポーネントとメタクラス330との間や、コンポーネントの相互関係に矛盾が生じると、データベース310はその矛盾を検知することができる。

0141

また、本例の設計ツールは、トレーサビリティを自動で確保している。トップダウン開発が分かりやすいが、システム開発100の要件定義110からソフトウェア開発200の詳細設計230までの開発では、上位工程と下位工程との間で一貫性が求められる。こうした工程間の作業成果物(コンポーネント)の関係性一元管理し、設計、製造、保守上のトラブルが発生した際に、速やかに問題の原因を追跡(トレース)できるようにすることが「トレーサビリティ管理」である。

0142

本例の設計支援ツールでは、上位工程から下位工程まで設計情報がメタモデル300で導出304で定義されているので、上位工程で定義したメタモデル300に関連付けて下位工程のメタモデル300を作成することができる。逆に、下位工程で定義したメタモデル300に関連付けて上位工程のメタモデル300を作成することもできる。

0143

図26は、ディスプレイ320での導出304の操作を説明する図である。図に示すように、ディスプレイ320には、上位工程の要件定義110と下位工程のソフトウェア基本設計220とを画面の左右に並べて表示することができる。そして、右側画面のソフトウェア基本設計220のAPPレイヤー221に車間距離偏差コンポーネント2211を設計しようとする場合、マウスで左側画面の定速走行117をドラックして、車間距離偏差コンポーネント2211の場所にドロップする。この直観的な操作で車間距離偏差コンポーネント2211が定速走行117から導出されることとなる。

0144

以上は操作例の説明であるが、データベース310では、設計者が左右画面のメタモデル300を画面上で操作して関係付けることで、導出304が記録される。即ち、データベース310は、設計者の導出の操作をトレース情報として自動的に記録する。

0145

換言すれば、データベース310では、車間距離偏差コンポーネント2211と定速走行117とが導出304の関係にあることを自動的に記録する。より具体的には、どの時点で導出304をおこなったかを、データベース310に格納する。データベース310に格納されるのは、導出304の関係と、導出先のID情報及び導出元のID情報である。そのため、この導出304の関係は、トレース情報として用いることができる。

0146

本例の設計支援ツールでは、この導出304の関係を線で結ぶことで設計者が直観的に把握することができる。図27では、システム開発100の要件定義110、論理設計120及び物理設計と、ソフトウェアの仕様定義210及び基本設計をディスプレイ320に並べて表示し、導出304の関係を線で結んでいる。

0147

例えば、要件定義110の定速走行117と、論理設計120のドライバー通知出力127と、物理設計140のメータECU143と、ソフトウェア仕様定義210の追従走行2109と、基本設計220の車速偏差2210とは導出304の関係にある。従って、この導出関係の線をたどればトレース情報を得ることができる。

0148

このように、本例の設計支援ツールでは、設計の各工程におけるメタモデル300を規定して、その規定に沿った設計を定めている。そして、上位工程、下位工程の各コンポーネント間の導出304関係をデータベース310で記憶している。従って、本例の設計支援ツールは、上位工程の要求が下位工程の機能に全て落とし込まれているのかが直観的に把握できる。換言すれば、上位工程の要求にない機能が下位工程で作られていないかを把握できる。そのため、設計変更を行う際には、設計変更により影響を受ける範囲も把握することができる。

0149

なお、上述の例は、本例の設計支援ツールの望ましい使用例ではあるが、本例の設計支援ツールは特許請求の範囲の記載範囲内で、種々に変更可能である。

0150

自動車の自動運転は用途の一例であって、他のシステム開発に使用可能であることは勿論である。ディスプレイ320は、通常はコンピュータ液晶画面が用いられるが、必要に応じて紙媒体プリントアウトすることも可能である。設計支援ツールの操作も、マウスやキーボードを用いて行うのが通常であるが、入力情報画像認識音声認識で行うことも可能である。また、他の機器で入力された情報を取り込むことで、設計支援ツールを動作させるようにしてもよい。

0151

システム開発100の設計態様は、要件定義110、論理設計120、制御設計130、及び物理設計140と規定し、ソフトウェア開発200の設計態様は、仕様定義210、基本設計220、及び詳細設計230と規定するのが一般的であるが、他の規定の仕方を用いても良い。本例の設計支援ツールの特徴は、設計内容の整合性が把握できることであり、各工程の名称によって本例の設計支援ツールの特徴が変更されるものではない。

実施例

0152

メタモデル300のメタクラス330間の関係は、所有301、参照302、継承303及び導出304を全て備えるのが望ましいが、使用形態によっては、いくつかの関係を削除してもよい。逆に、追加の関係を加えてもよい。本例の設計支援ツールが必要とするのは、所有301と参照302の少なくとも一つである。

0153

本明細書の開示は、設計支援ツールとして利用可能で、例えば、自動車の自動運転システム等の大規模なシステムを開発する際の、工程の設計に用いることができる。

0154

100・・・システム開発、110・・・要件定義、120・・・論理設計、130・・・制御設計、140・・・物理設計、200・・・ソフトウェア開発、210・・・ソフトウェア仕様定義、220・・・ソフトウェアの基本設計、230・・・ソフトウェアの詳細設計、300・・・メタモデル、301・・・所有、302・・・参照、303・・・継承、304・・・導出、305・・・設計結果、307・・・ビュー、310・・・データベース、320・・・ディスプレイ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ