JP6847382B1 - 設計支援ツール - Google Patents

Abstract

【課題】メタモデルを用いて設計を行うに際して、設計のニーズに応じた表示形態を設計者に提示する。【解決手段】システム開発の要件定義、論理設計、制御設計、及び物理設計と、ソフトウェア開発の仕様定義、基本設計、及び詳細設計の中の少なくとも一工程の設計を、メタモデルを用いて行う設計支援ツールで、設計内容をディスプレイにビューとして表示する。ビュー表示は、ＥＲダイヤグラム、ツリーダイアグラム、ドキュメントフォーム及びツリーグリッドの中の少なくとも２つの形態で表示する。【選択図】図２０

Description

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

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

米国特許出願公開第２０１０／０１６２２０８号明細書

特許文献１に記載のメタモデル生成装置は、設計者がコンピューターのディスプレイを見ながら、キーボードやマウスを操作してメタモデルを構成するブロックを特定できるようにしている。

しかしながら、特許文献１に記載のメタモデル生成装置は、専らメタモデルの生成に関する技術である。そのため、設計者が実際にディスプレイを見ながら操作する際に、設計内容をどのような形態で設計者に表示するのかは、検討していない。

一般に、メタモデル等のプログラムを作成するソフトウェアは、そのソフトウェアに適した表示形式を採用している。例えば、プログラムの詳細を設計する場合には、表形式でプログラムを表示ことが多く、プログラムの全体構造を設計する場合には、ダイヤグラム形式でプログラムを表示することが多い。そのため、特許文献１に記載のメタモデル生成装置は、そのプログラムに適した単一の表示形式でプログラムを表示していると考えられる。

ただ、例えば、自動車の自動運転のシステム開発を行う場合には、非常に多くのソフトウェアが組み合わされて全体のプログラムが構成される。そのため、膨大なプログラムの全体像を把握するニーズもあり、一方で、ソフトウェアの詳細を確認するニーズもある。

本件の開示は上記点に鑑みてなされたもので、設計者がプログラムを設計する場合や、設計したプログラムを確認する場合に、設計者のニーズに応じた形態でプログラムを表示できるようにすることを課題とする。

本件明細書の第１の開示は、少なくとも一工程の設計を支援する設計支援ツールである。そして、少なくとも一つのメタクラスによってメタモデルを定義し、工程の設計をこのメタモデルに基づいて行い、設計内容をデータベースに格納する。第１の開示は、設計内容をディスプレイにビューとして表示すると共に、このビューを用いて少なくともメタモデル若しくはメタモデルに基づく設計結果の生成、変更、削除を行うことができる。このビューは、記載形式の異なる複数の表示である。記載形式の異なる複数の表示のいずれのビューを用いてメタモデル若しくはメタモデルに基づく設計結果の生成、変更、削除を行ってもデータベースでは同じ設計情報として記録され、データベースに格納された同じ設計情報に基づいて記載形式の異なる複数の表示の他の表示のビューでその生成、変更、削除が反映される。

第１の開示によれば、設計者は設計内容に応じてビューの表示を切り替えることができる。例えば、設計内容の全体像を把握するにはＥＲダイヤグラムを用いることができ、詳細な設計を行う際にはドキュメントフォームを用いることができる。設計者は自身が望むビューを用いて設計ができるので、効率的に設計することが可能である。第１の開示によれば、記載形式の異なる複数の表示のいずれのビューを用いてメタモデル若しくはメタモデルに基づく設計結果の生成、変更、削除を行っても、単に表示形式が相違するのみで、データベースでは同じ設計情報として記録される。即ち、データベース内で表示形式に応じてデータの変換を行う必要がない。そのため、データベースに格納された同じ設計情報に基づいて記載形式の異なる複数の表示の他の表示のビューでその生成、変更、削除が反映されることとなる。

本件明細書の第２の開示は、ディスプレイのビューは、ＥＲダイヤグラム、ツリーダイアグラム、ドキュメントフォーム及びツリーグリッドの中の少なくとも二つの表示である。設計者は多様なビューの選択が可能である。

本件明細書の第３の開示は、少なくとも二つの表示が、同時にディスプレイのビューに表示される。第３の開示によれば、設計者は設計内容に応じて二つ以上のビューを見比べることができる。例えば、ＥＲダイヤグラムを用いて設計内容の全体像を把握しつつ、ドキュメントフォームを用いて詳細な設計を行うことができる。そのため、設計者は効率的に設計することが可能である。

本件明細書の第４の開示は、少なくとも二工程の設計を支援する。そして、少なくとも二工程がディスプレイのビューに同時に表示される。第４の開示によれば、設計者は設計内容に応じて二つ以上のビューを見比べることができる。例えば、ＥＲダイヤグラムを用いてシステム開発の要件定義を確認しつつ、ドキュメントフォームを用いてソフトウェア開発の詳細設計を行うことができる。そのため、設計者は効率的に設計することが可能である。

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

設計者は、自身で設計しやすいと判断するビューを用いて、メタモデルやそれに基づく設計内容の生成、変更、削除を行うだけで、その生成、変更、削除をデータベースに反映させることができる。そのため、設計者は効率的に設計することが可能である。

図１は、システム開発の開発手順を示す説明図である。 図２は、メタモデルを示す説明図である。 図３は、システム開発の要件定義のメタモデルを示す説明図である。 図４は、システム開発の要件定義の設計結果を示す説明図である。 図５は、システム開発の論理設計のメタモデルを示す説明図である。 図６は、システム開発の論理設計の設計結果を示す説明図である。 図７は、システム開発の制御設計のメタモデルを示す説明図である。 図８は、システム開発の制御設計の設計結果を示す説明図である。 図９は、システム開発の物理設計のメタモデルを示す説明図である。 図１０は、システム開発の物理設計の設計結果を示す説明図である。 図１１は、ソフトウェア開発の仕様定義のメタモデルを示す説明図である。 図１２は、ソフトウェア開発の仕様定義の設計結果を示す説明図である。 図１３は、ソフトウェア開発の基本設計のメタモデルを示す説明図である。 図１４は、ソフトウェア開発の基本設計の設計結果を示す説明図である。 図１５は、ソフトウェア開発の詳細設計のメタモデルを示す説明図である。 図１６は、ソフトウェア開発の詳細設計の設計結果を示す説明図である。 図１７は、ソフトウェア開発の詳細設計の設計結果を示す説明図である。 図１８は、データベースとビューとの関係を示す説明図である。 図１９は、データベースとビューとの関係を示す説明図である。 図２０は、ビューの例を示す説明図である。 図２１は、データベースのデータ構造を示す説明図である。 図２２は、設計結果間の不整合を示す説明図である。 図２３は、設計結果間の不整合を示す説明図である。 図２４は、設計結果間の不整合を示す説明図である。 図２５は、メタモデルと設計結果間の不整合を示す説明図である。 図２６は、導出関係を示す説明図である。 図２７は、導出関係を示す説明図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

従って、各設計工程１１０、１２０、１３０、１４０、２１０、２２０、及び２３０には、それぞれ開発の方向性を定めるメタモデル３００の策定と、メタモデル３００に基づきなされる設計結果３０５とがある。

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

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

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

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

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

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

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

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

図３は、要件定義１１０のメタモデル３００の一例を示す。メタクラス３３０としてシステム要件１１１を挙げており、更に、システム要件１１１は、第１システム要件１１１０とこの第１システム要件１１１０と所有３０１の関係にある第２システム要件１１１１が規定される。即ち、メタモデル３００ではシステム要件１１１が多重であることを規定している。

要件定義１１０のメタモデル３００では、第２システム要件１１１１は、機能要件１１２のメタクラス３３０と非機能要件１１３のメタクラス３３０が継承３０３の関係にある。そして、非機能要件１１３のメタクラス３３０には、信頼性要件１１４、保守性要件１１５及び効率性要件１１６のメタクラス３３０が継承３０３の関係にある。従って、第２システム要件１１１１には、機能要件１１２と、信頼性要件１１４、保守性要件１１５及び効率性要件１１６の非機能要件１１３とがあることが規定される。

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

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

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

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

そして、定速走行１１７、設定１１７１、走行１１７２、定速走行の実施１１８、目標速度設定１１９、項目１１８１、１１８２、及び検討項目１１９１の各項目が、設計結果３０５での各コンポーネントとなる。各コンポーネント間の関係は参照３０２の関係となる。

図５は、論理設計１２０のメタモデル３００の一例を示す。システム１２０１のメタクラス３３０はシステム機能構造１２００と所有３０１の関係にあり、システム機能構造１２００はシステム１２０１を含むことを規定している。また、システム１２０１は、入力ポート１２０２、出力ポート１２０３及びサブシステム１２０４のメタクラス３３０と所有３０１の関係にあり、システム１２０１は、入力ポート１２０２、出力ポート２０３及びサブシステム１２０４を有している。同様に、サブシステム１２０４も入力ポート１２０５と出力ポート１２０６を有している。

また、システム１２０１は、システム構成要素１２０７のメタクラス３３０と継承３０３の関係にあり、システム１２０１にはシステム構成要素１２０７が含まれることが規定されている。更に、システム構成要素１２０７のメタクラス３３０は導出３０４の関係が規定され、この導出３０４の関係は要件定義１１０のメタモデル３００のシステム要件１１１、より具体的には第２システム要件１１１１のメタクラス３３０に結ばれている。従って、論理設計１２０のシステム１２０１は、システム構成要素１２０７を介して、要件定義１１０のシステム要件１１１から導出されるものであることが規定される。

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

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

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

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

メタモデル３００との関係では、例えば、システム機能構造１２００が全体構造を示し、そこに含まれるシステム１２０１にはドライバーの要求判定項目１２１、車速算出項目１２２、車速差分算出項目１２３、車間距離差分算出項目１２４、車間距離算出項目１２５、システム状態判定項目１２６、ドライバー通知出力項目１２７及び目標加減速量算出項目１２８が対応する。各システム１２０１には入力ポート１２０２と出力ポート１２０３が設けられている。

システム１２０１としてドライバーの要求判定項目１２１を挙げると、そのサブシステム１２０４に対応するものは、減速判定１２１１、増速判定１２１２、車速設定判断１２１３、車間短判定１２１４、車間長判定１２１５、及び車間設定判断１２１６があり、各サブシステム１２０４は入力ポート１２０５と出力ポート１２０６を備えている。

これをメタクラス３３０と設計結果３０５のコンポーネントとの関係にすれば、メタクラス３３０にはサブシステム１２０４が対応し、減速判定１２１１、増速判定１２１２、車速設定判断１２１３、車間短判定１２１４、車間長判定１２１５、及び車間設定判断１２１６が設計結果３０５の各コンポーネントとなる。

次に、制御設計１３０のメタモデル３００を図７に基づいて説明する。制御設計１３０は、論理設計１２０のシステム１２０１やサブシステム１２０４での制御を設計するもので、入力ポート１３００及び出力ポート１３０１は、システム１２０１の入力ポート１２０２、出力ポート１２０３や、サブシステム１２０４の入力ポート１２０５、出力ポート１２０６に対応する。

図７に示すように、制御ロジック要素１３０２は入力ポート１３００及び出力ポート１３０１と参照３０２の関係にあり、論理設計１２０の入力ポート及び出力ポートはこの制御ロジック要素１３０２を参照している。

そして、制御ロジック要素１３０２のメタクラス３３０には、波形１３０３、パルス１３０４、定数１３０５及び演算１３０６が継承３０３の関係にあり、波形１３０３、パルス１３０４、定数１３０５及び演算１３０６を用いて制御ロジックが組まれることが規定されている。

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

図８は、制御設計１３０の一例を示す。この例は、論理設計１２０のシステム状態判定項目１２６に対応する。入力ポート１２０２に対応するイグニッションスイッチが入っているか否か１２０２１と、クルーズコントロールのオンオフの状態１２０２２との信号を、第１アンド回路１３１１で演算する。そして、この第１アンド回路１３１１からの信号とユニットの遅れ信号とをＸオア回路１３１２で論理演算して、クルーズコントロールのオンオフを出力する。この出力１２０３１は、論理設計１２０の出力ポート１２０３に対応する。

また、Ｘオア回路１３１２からの出力とクルーズコントロールのモード信号１２０２３を、第２アンド回路１３１３で演算する。ここで、モード信号１２０２３は、論理設計１２０の入力ポート１２０２に対応する。そして、第２アンド回路１３１３の出力とユニットの遅れ信号を加算回路１３１４で加算演算して、クルーズコントロールのモードを出力する。出力１２０３２が、論理設計１２０の出力ポート１２０３に対応する。

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

図９は、物理設計１４０のメタモデル３００の一例を示す。最上位にシステム物理構造１４００のメタクラス３３０があり、要素１４０１のメタクラス３３０が所有３０１の関係にある。ＥＣＵ１４０２のメタクラス３３０が継承３０３の関係にあるように、要素１４０１の一例はＥＣＵ１４０２である。

要素１４０１のメタクラス３３０に機能コンポーネント割り当て１４０３、入力ポート１４０４及び出力ポート１４０５のメタクラス３３０が所有３０１の関係にあるように、要素１４０１（ＥＣＵ１４０２）には、機能コンポーネント割り当て１４０３、入力ポート１４０４及び出力ポート１４０５が備わっている。

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

図１０に物理設計の設計結果３０５の一例を示す。この例では、役割を分担するＥＣＵ１４０２として、ブレーキＥＣＵ１４１、自動運転を支援するＡＤＡＳＥＣＵ１４２、メータＥＣＵ１４３、エンジンコントロールＥＣＵ１４４、及びパワステＥＣＵ１４５が挙げられる。

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

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

各ＥＣＵ１４０２の処理内容としては、例えば、自動運転を支援するＡＤＡＳＥＣＵ１４２には以下のものがある。車間距離算出１４２０、車速差分算出１４２１、車間距離差分算出１４２２、ドライバー入力判定１４２３、目標加減速量算出１４２４、システム状態判定１４２５、及び車両状態判定１４２６である。

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

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

メタモデル３００と設計結果３０５との関係は、既述の通りであるが、例えば、メタクラス３３０をＥＣＵ１４０２とした場合、ブレーキＥＣＵ１４１、自動運転を支援するＡＤＡＳＥＣＵ１４２、メータＥＣＵ１４３、エンジンコントロールＥＣＵ１４４、及びパワステＥＣＵ１４５が設計結果３０５のコンポーネントに対応する。

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

ソフトウェア要求２１０２のメタクラス３３０には、機能要求２１０３と非機能要求２１０４のメタクラス３３０が継承３０３の関係にあり、非機能要求２０１４のメタクラス３３０は、更に、信頼性要求２１０５、効率性要求２１０６、及び保守性要求２１０７のメタクラス３３０が継承３０３の関係にある。従って、ソフトウェア要求２１０２には、機能要求２１０３と、信頼性要求２１０５、効率性要求２１０６、保守性要求２１０７の非機能要求２１０４とが規定される。

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

このソフトウェア開発２００におけるソフトウェアの仕様定義２１０の設計結果３０５の一例を、図１２に示す。ソフトウェア仕様定義２１０では、各ＥＣＵ１４０２でどのようなソフトウェアを受け持つのかを定める。例えば、自動運転を支援するＡＤＡＳＥＣＵ１４２に対する項目２１１では、ＥＣＵに共通する保守性に対する保守性要求２１２０、ＥＣＵに共通する使用性に対する使用性要求２１２１、ＥＣＵの効率性に対する効率性要求２１２２、及び、ＥＣＵの信頼性に対する信頼性要求２１２３がある。

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

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

信頼性要求２１２３に対しては、例えば、ソフトウェアを構成するパーツの一部に不具合が生じた際にも、その不具合の影響を受けていない他のパーツでは動作を継続させるパーツ信頼性要求２１３４が挙げられる。これらの各要求２１２０〜２１２３や２１３０〜２１３４は、メタモデル３００の非機能要求２１０４に対応する。従って、メタモデル３００と設計結果３０５との関係では、非機能要求２１０４がメタクラス３３０であり、各要求２１２０〜２１２３や２１３０〜２１３４は、設計結果３０５のコンポーネントに対応する。

図１３は、ソフトウェア基本設計２２０のメタモデル３００の一例を示す。ソフトウェア基本設計２２０ではソフトウェア仕様定義２１０で定めた要求を実現するための、機能とデータとを定義する。ソフトウェア構造２２００、レイヤー２２０１及び要素２２０２のメタクラス３３０が所有の関係にあるので、ソフトウェア構造２２００にはレイヤー２２０１が含まれ、レイヤー２２０１には要素２２０２が含まれる。

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

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

このソフトウェア基本設計２２０の設計結果３０５の一例を、図１４に示す。例えば、自動運転ではアプリケーションレイヤー（ＡＰＰレイヤー）２２１には、車速偏差２２１０、車間距離偏差２２１１、及び目標制御量２２１２の項目がある。その下のレイヤーであるアプリケーションフレームワークレイヤー（ＡＦＷレイヤー）２２２には、先行車の有無２２２０、クルーズコントロールの制御状態２２２１、外部システム制御量２２２２の項目が入る。

更にその下のレイヤーであるプラットフォームレイヤー（ＰＦレイヤー）２２３には、先行車情報２２３０、自車走行情報２２３１、外部システム状態２２３２、スイッチ状態２２３３、及び外部システム要求２２３４の項目がある。そして、最も下のレイヤーであるハードウェアレイヤー（ＨＷレイヤー）２２４には、上記各項目の前提となる信号を出力する各機器として、車載機器にも利用可能なネットワークのコントローラ（受信）２２４０、イグニッションスイッチ２２４１、各種スイッチ２２４２、及び車載機器にも利用可能なネットワークのコントローラ（送信）２２４３がある。

従って、ＡＰＰレイヤー２２１、ＡＦＷレイヤー２２２、ＰＦレイヤー２２３、ＨＷレイヤー２２４が、メタモデル３００のレイヤー２２０１に対応する。そして、車速偏差２２１０、車間距離偏差２２１１、及び目標制御量２２１２の項目、先行車の有無２２２０、クルーズコントロールの制御状態２２２１、外部システム制御量２２２２の項目、先行車情報２２３０、自車走行情報２２３１、外部システム状態２２３２、スイッチ状態２２３３、及び外部システム要求２２３４の項目、車載機器にも利用可能なネットワークのコントローラ（受信）２２４０、イグニッションスイッチ２２４１、各種スイッチ２２４２、及び車載機器にも利用可能なネットワークのコントローラ（送信）２２４３が、各レイヤー２２０１に含まれる要素２２０２に対応する。

なお、図１４では、ＡＰＰレイヤー２２１からＨＷレイヤー２２４までの各レイヤー間の関係を破線の矢印で示している。例えば、ＨＷレイヤー２２４のイグニッションスイッチ２２４１からの信号はＰＦレイヤー２２３の外部システム状態２２３２の項目に取り込まれ、スイッチ状態２２３３の項目と共にＡＦＷレイヤー２２２のクルーズコントロールの制御状態２２２１の項目に取り込まれる。そして、この制御状態２２２１は、ＡＰＰレイヤー２２１の車速偏差２２１０と車間距離偏差２２１１に出力する。

従って、図１４の矢印は、設計結果３０５の各レイヤー２２０１間の関係を示すもので、メタモデル３００の矢印とは関係ない。

メタモデル３００と設計結果３０５との関係も上述の通りである。例えば、レイヤー２２０１がメタクラス３３０であり、ＡＰＰレイヤー２２１、ＡＦＷレイヤー２２２、ＰＦレイヤー２２３、ＨＷレイヤー２２４が、設計結果３０５のコンポーネントである。

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

要素２３００のメタクラス３３０には、関数２３０１、データ２３０２、入力ポート２３０３及び出力ポート２３０４の各メタクラス３３０と所有３０１の関係にある。従って、要素２３００は、関数２３０１、データ２３０２、入力ポート２３０３及び出力ポート２３０４を備えている。

データ２３０２のメタクラス３３０は関数２３０１のメタクラス３３０にも所有３０１の関係となっているので、データ２３０２は、要素２３００に用いられると共に、関数２３０１にも用いられることとなる。

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

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

メタモデル３００と設計結果３０５との関係も上述の通りである。例えば、入力項目２３１がメタクラス３３０であり、「１．クルーズコントロールの状態」、「２．車両の速度」、「３．先行車の有無」、「４．実測車間距離」、「５．設定車間距離」が設計結果３０５のコンポーネントである。

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

例えば、データベース３１０に設計結果として、サブシステム３１００にシステム状態判定３１０１が書き込まれると、そのシステム状態判定３１０１は、図１８に示すように、論理設計１２０のシステム状態判定１２６としても表示でき、物理設計１４０のシステム状態判定１４２５としても表示できる。

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

表形式のビュー３０７は、ＡＰＰレイヤー２２１の債務として、「加減速の目標量を車速と車間距離との差から表示する。」と記載し、要素２２０２には、「１．車間距離偏差２２１１」、「２．目標制御量２２１２」、「３．車速偏差２２１０」の名称と、それぞれの要素２２０２の責務が記載されている。ＡＦＷレイヤー２２２以下のレイヤー２２０１に付いても同様に表示される。

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

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

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

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

図２１は、データベース３１０内でのデータの持ち方の例を示す。例えば、物理設計１４０のＡＤＡＳＥＣＵ１４２の出力ポート１４０５とメータＥＣＵ１４３の入力ポート１４０４との接続１４８を定める場合、データベース３１０内では、接続１４８自身のＩＤ１４８０と、関連元のＩＤ１４８１及び関連先のＩＤ１４８２によって特定を行う。そして、接続１４８に関連する各種のデータが格納される。例えば、名称、データ自体、データのバージョンや削除情報等がある。

データベース３１０に格納される情報として、メタクラス３３０間の関係もある。図２１の接続１４８は参照３０２の関係であるが、上述の通り、メタクラス３３０間の関係には所有３０１、参照３０２、継承３０３、及び導出３０４があるので、その関係がデータベース３１０に格納される。

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

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

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

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

図１９の例では、レイヤーを示す左図のＡＰＰレイヤー２２１の車速偏差２２１０に変更を加えれば、右図のドキュメントフォームでは、ＡＰＰレイヤー２２１の責務やコンポーネントを説明する文書にその変更が反映される。図１８の例では、システム開発の論理設計１２０でシステム状態判定１２６に変更を加えれば、システム開発の物理設計１４０のＡＤＡＳＥＣＵ１４２のシステム状態判定１４２５にもその変更が反映される。

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

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

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

例えば、図２２に示すように、Ｘ設計結果４００でコンポーネントＡ４０１とコンポーネントＢ４０２を使用しており、そのコンポーネントＢ４０２はＹ設計結果４１０のコンポーネントＢ４１１を参照しているときに、Ｙ設計結果４１０でコンポーネントＢ４１１が削除されると、Ｘ設計結果４００とＹ設計結果４１０との間で不整合が発生する。

また、図２３に示すように、Ｘ設計結果４００でコンポーネントＡ４０１とコンポーネントＢ４０２を使用しており、そのコンポーネントＢ４０２はＹ設計結果４１０のコンポーネントＢ４１１を参照しているときに、同じコンポーネントＢがＺ設計結果４２０のコンポーネントＢ４２１としても定義されている場合、Ｙ設計結果４１０のコンポーネントＢ４１１とＺ設計結果４２０のコンポーネントＢ４２１との間で不整合が発生する。

他の例として、図２４に示すように、Ｙ設計結果４１０のコンポーネントＢ４１１がＸ設計結果４００のコンポーネントＡ４０１を参照している状態で、Ｘ設計結果４００のコンポーネントＡ４０１が削除される場合もある。引用先の設計結果３０５が削除され実態が無くなるという不整合が発生する。

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

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

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

図２２の例では、不整合の検出時に「削除されているモデルが見つかりました。」との表示をディスプレイ３２０（図２７）で行い、Ｘ設計結果４００のファイル名と、関連元であるコンポーネントＡ４０１のクラス名、関連ａ４０３の関連クラス名、及びコンポーネントＢ４０２が何番目のメタモデルであったかを示すコレクションのインデックス番号を表示する。

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

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

図２３の例では、不整合の検出時に「複数のファイルで重複するモデルが見つかりました。」との表示をディスプレイ３２０に示し、Ｙ設計結果４１０とＺ設計結果４２０のファイル名と、コンポーネントＢ４１１、４２１のモデルのパスを表示する。

データベース３１０には、Ｘ設計結果４００のコンポーネントＢ４０２とＹ設計結果４１０のコンポーネントＢ４１１が参照の関係にあることが、それぞれのＩＤ情報と共に格納されている。かつ、Ｘ設計結果４００のコンポーネントＢ４０２とＺ設計結果４２０のコンポーネントＢ４２１が参照の関係にあることもそれぞれのＩＤ情報と共に格納されている。従って、データベース３１０では、参照の関係に不整合があることを検知できる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例えば、要件定義１１０の定速走行１１７と、論理設計１２０のドライバー通知出力１２７と、物理設計１４０のメータＥＣＵ１４３と、ソフトウェア仕様定義２１０の追従走行２１０９と、基本設計２２０の車速偏差２２１０とは導出３０４の関係にある。従って、この導出関係の線をたどればトレース情報を得ることができる。

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

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

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

システム開発１００の設計態様は、要件定義１１０、論理設計１２０、制御設計１３０、及び物理設計１４０と規定し、ソフトウェア開発２００の設計態様は、仕様定義２１０、基本設計２２０、及び詳細設計２３０と規定するのが一般的であるが、他の規定の仕方を用いても良い。本例の設計支援ツールの特徴は、設計結果を複数のビューで見ることができる点にあり、各工程の名称によって本例の設計支援ツールの特徴が変更されるものではない。

メタモデル３００のメタクラス３３０間の関係は、所有３０１、参照３０２、継承３０３及び導出３０４を全て備えるのが望ましいが、使用形態によっては、いくつかの関係を削除してもよい。逆に、追加の関係を加えてもよい。

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

１００・・・システム開発、１１０・・・要件定義、１２０・・・論理設計、１３０・・・制御設計、１４０・・・物理設計、２００・・・ソフトウェア開発、２１０・・・ソフトウェア仕様定義、２２０・・・ソフトウェアの基本設計、２３０・・・ソフトウェアの詳細設計、３００・・・メタモデル、３０５・・・設計結果、３０７・・・ビュー、３１０・・・データベース、３２０・・・ディスプレイ

Claims (5)

1. 少なくとも一工程の設計を支援する設計支援ツールであって、
   少なくとも一つのメタクラスによってメタモデルを定義し、前記工程の設計をこのメタモデルに基づいて行い、
   設計内容をデータベースに格納し、
   前記設計内容は、ディスプレイにビューとして表示されると共に、このビューを用いて少なくとも前記メタモデル若しくは前記メタモデルに基づく設計結果の生成、変更、削除を行うことができ、
   前記ディスプレイのビューは、記載形式の異なる複数の表示であり、記載形式の異なる複数の表示のいずれのビューを用いて前記メタモデル若しくは前記メタモデルに基づく設計結果の生成、変更、削除を行っても前記データベースでは同じ設計情報として記録され、前記データベースに格納された同じ設計情報に基づいて記載形式の異なる複数の表示の他の表示のビューでその生成、変更、削除が反映される
   設計支援ツール。
2. 前記ディスプレイのビューは、ＥＲダイヤグラム、ツリーダイアグラム、ドキュメントフォーム及びツリーグリッドの中の少なくとも二つの表示である
   請求項１記載の設計支援ツール。
3. 前記ディスプレイのビューは、記載形式の異なる複数の表示が、同時に前記ディスプレイのビューに表示される
   請求項１若しくは２記載の設計支援ツール。
4. 少なくとも二工程の設計を支援する設計支援ツールであって、
   少なくとも二工程が前記ディスプレイのビューに同時に表示される
   請求項１若しくは２記載の設計支援ツール。
5. 前記工程は、システム開発の要件定義、論理設計、制御設計、及び物理設計と、ソフトウェア開発の仕様定義、基本設計、及び詳細設計の中のいずれかである
   請求項１乃至４いずれか記載の設計支援ツール。

Images