JP2019220041A - 移動体制御システムの評価装置及び評価方法 - Google Patents

Abstract

【課題】制御システムの製品系列を考慮した上でアーキテクチャの再利用性（共通性）の評価を行う移動体制御システムの評価装置及び評価方法を提供する。【解決手段】車両制御システムの機能要件ごとに設定される、複数の論理アーキテクチャ６０１間の再利用性および／または論理アーキテクチャ６０１を配置する複数の物理アーキテクチャ３００間の再利用性を評価する車両制御システムの評価装置１００であって、論理アーキテクチャ６０１の論理エレメントを物理アーキテクチャ３００の物理エレメントに配置する機能配置部１０１と、機能配置部１０１により配置された複数の論理アーキテクチャ６０１間の再利用性および／または複数の物理アーキテクチャ３００間の再利用性を、機能要件の差分に基づいて評価するアーキテクチャ評価部１０３と、アーキテクチャ評価部１０３により評価された再利用性の評価結果を出力する評価結果出力部１０４と、を有する。【選択図】図１

Description

本発明は、移動体制御システムの評価装置及び評価方法に関する。

特許文献１には、情報処理装置を用いたアプリケーションアーキテクチャの設計方法として、所定の論理機能を動作させるモジュール群、そのモジュール群を動作させる仮想マシン群、その仮想マシン群を動作させる物理マシン群に関しての設計事項となる依存関係及び設計アスペクトに関する情報を入力する段階と、入力された依存関係及び設計アスペクトに関する情報についてＤＳＭ（Ｄｅｐｅｎｄｅｎｃｙ Ｓｔｒｕｃｔｕｒｅ Ｍａｔｒｉｘ）形式の設計マトリクスの入れ替えを行うことによって、ＤＳＭ形式上でモジュール群、仮想マシン群、及び物理マシン群に対するそれぞれの割り当てを段階的に再配置してアーキテクチャの適正化処理を図る段階と、を行い、その結果として仮想化環境やクラウド環境などに適したアーキテクチャの良好な設計解を導出することができる車両制御システム検証装置が開示されている。

特表２００７−５０６５９１号公報

しかしながら、特許文献１に開示された車両制御システム検証装置では、論理機能により記述される論理アーキテクチャの論理エレメント（Ｓｏｆｔｗａｒｅ：以下、Ｓ／Ｗとも言う）を、物理構成により記述される物理アーキテクチャの物理エレメント（Ｈａｒｄｗａｒｅ：以下、Ｈ／Ｗとも言う）に配置（マッピング）した後、アーキテクチャの性能等の評価を行っている。ここで、Ｈ／Ｗの一例として、車両に搭載されているＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）、マイコンなどが挙げられる。

ここで車両などのように複数の製品系列を有する場合、これら複数の製品系列を考慮した上で当該製品系列におけるアーキテクチャの再利用性（共通性）の評価を行う必要がある。しかしながら、特許文献１には、複数の製品系列を考慮した上でアーキテクチャの再利用性の評価を行うことに関して何ら記載されていない。このことは、車両制御システムに限らず、他の制御システムについても同じことが言える。

したがって、本発明は、制御システムの製品系列を考慮した上でアーキテクチャの再利用性（共通性）の評価を行うことを目的とする。

上記課題を解決するため、車両制御システムの機能要件ごとに設定される、複数の論理アーキテクチャ間の再利用性、および／または前記論理アーキテクチャを配置する複数の物理アーキテクチャ間の再利用性を評価する移動体制御システムの評価装置であって、前記論理アーキテクチャの論理エレメントを前記物理アーキテクチャの物理エレメントに配置する機能配置部と、前記機能配置部により配置された複数の前記論理アーキテクチャ間の再利用性、および／または複数の前記物理アーキテクチャ間の再利用性を、前記機能要件の差分に基づいて評価する評価部と、前記評価部により評価された再利用性の評価結果を出力する評価結果出力部と、を有する構成とした。

本発明によれば、制御システムの製品系列を考慮した上でアーキテクチャの再利用性（共通性）の評価を行うことができる。

実施の形態にかかる車両制御システムの評価装置の機能構成を説明する。 評価対象の車両制御システムを備える車両システムの概略構成例を説明する図である。 車両制御システムで用いられる物理アーキテクチャの一例を説明する図である。 ＥＣＵの内部構成例を説明する図である。 物理アーキテクチャに付与されるパラメータの一例を説明する図である。 、車両制御システムの論理アーキテクチャの機能構成の一例を説明する図である。 論理アーキテクチャに付与されるパラメータの一例を説明する図である。 複数の製品系列での機能要件の管理方法の一例を説明する図である。 全モデル（製品系列）の論理機能・機能要件をフィーチャーツリー構造で表した図である。 Ｈモデルの論理機能・機能要件をフィーチャーツリー構造で表した図である。 Ｍモデルの論理機能・機能要件をフィーチャーツリー構造で表した図である。 Ｌモデルの論理機能・機能要件をフィーチャーツリー構造で表した図である。 Ｈモデルの論理アーキテクチャの構成例を説明する図である。 Ｍモデルの論理アーキテクチャの構成例を説明する図である。 Ｌモデルの論理アーキテクチャの構成例を説明する図である。 各モデルにおける物理アーキテクチャの構成例を説明する図である。 物理アーキテクチャの物理エレメントに対して論理アーキテクチャの論理エレメントを機能配置する場合の一例を説明する図である。 各モデルにおいて、どの物理エレメント（ＥＣＵ）にどの論理エレメント（論理機能）が配置されているのかを示す表である。 Ｓ／Ｗの再利用の一例を説明する模式図である。 評価装置によるＳ／Ｗの再利用性の評価結果の表示方法を説明する図である。 各モデルにおける物理エレメント（ＥＣＵ）と、当該物理エレメントに実装された論理機能との関係をパターンごとに示した図である。 物理アーキテクチャの再利用の一例を説明する模式図である。 評価装置によるＨ／Ｗの再利用性の評価結果の表示方法を説明する図である。 論理アーキテクチャの再利用性の評価結果の表示方法について説明する図である。 物理アーキテクチャの再利用性の評価結果の表示方法について説明する図である。 第２の実施形態にかかる各モデル（Ｈモデル、Ｍモデル、Ｌモデル）に実装された論理機能を表形式で表したものである。 ミドルウェアも考慮したＥＣＵの再利用性に必要な情報の管理表を示す。

＜車両制御システムの評価装置＞
初めに、本発明の実施の形態にかかる車両制御システムの評価装置１００の機能構成を説明する。実施の形態では、車両制御システムの評価装置１００により第１車両制御システム２が有する論理アーキテクチャを物理アーキテクチャ上に配置した際のアーキテクチャの再利用性を評価する場合を例示して説明するが、車両制御システムの評価装置１００の評価対象は車両制御システムに限定されるものではなく、様々な制御システムのアーキテクチャの再利用性の評価に適用することができる。
図１は、本発明の実施の形態にかかる車両制御システムの評価装置１００の機能構成を説明する図である。

図１に示すように、車両制御システムの評価装置１００（以下、評価装置１００とも言う）は、機能配置部１０１と、安全検証部１０２と、アーキテクチャ評価部１０３と、評価結果出力部１０４と、を有して構成されている。

機能配置部１０１は、論理アーキテクチャ６０１と物理アーキテクチャ３００とを入力とし、機能配置の例（図３参照）のように論理アーキテクチャ６０１（論理エレメント）を所定の物理アーキテクチャ（物理エレメント）上に配置する。

安全検証部１０２は、機能配置後のアーキテクチャと安全分析情報４０とを入力とし、前記アーキテクチャが安全分析情報４０の要件を満たしているか否かの観点で安全性の検証を行い、安全性検証ＯＫ又はＮＧ，ＮＧの場合の理由を出力する。

アーキテクチャ評価部１０３は、機能配置後のアーキテクチャについて、後述するアーキテクチャの再利用性の評価とアーキテクチャの定量評価を行う。

評価結果出力部１０４は、アーキテクチャ評価部１０３によるアーキテクチャの再利用性の評価結果５０を表示装置（図示せず）に所定の形式で出力する。このようにして車両制御システム２の検証及び評価を実施する。

前述した理論アーキテクチャ、物理アーキテクチャ、機能配置、アーキテクチャの再利用性評価の詳細は後述する。

＜車両制御システムの構成＞
次に、評価装置１００による評価対象となる第１車両制御システム２を備える車両システム１の概略構成を説明する。
図２は、評価対象の第１車両制御システム２を備える車両システム１の概略構成例を説明する図である。実施形態では、車両システム１は自動車などの車両が該当し、当該車両の内部に第１車両制御システム２を有している。

車両システム１は、第１車両制御システム２と、通信装置３と、第２車両制御システム４と、駆動装置５と、認識装置６と、出力装置７と、入力装置８と、通知装置９と、を有して構成されている。

第１車両制御システム２（以下、車両制御システム２とも言う）は、車載ネットワークとコントローラにより構成されている。車載ネットワークの一例として、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＣＡＮＦＤ（ＣＡＮ ｗｉｔｈ Ｆｌｅｘｉｂｌｅ Ｄａｔａ−ｒａｔｅ）、Ｅｔｈｅｒｎｅｔ（登録商標）などが挙げられる。また、コントローラの一例として、ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）などが挙げられる。車両制御システム２は、通信装置３、第２車両制御システム４、駆動装置５、認識装置６、出力装置７、入力装置８、通知装置９などに接続され、それぞれの情報の送受信を行う。

通信装置３は、車両システム１の外部と無線通信などのプロトコルを使用した通信、又はＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）を用いた通信を行い、外界（インフラ、他車両、地図）の情報又は自車に関する情報を取得、送信などの無線通信を行う。ここで無線通信とは、例えば、携帯電話の通信、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、Ｃ２Ｘ（Ｃａｒ ｔｏ Ｘ：車両対車両または車両対インフラ通信）が挙げられる。また、通信装置３は、診断端子（ＯＢＤ：Ｏｎ−Ｂｏａｒｄ Ｄｉａｇｎｏｓｔｉｃｓ）やＥｔｈｅｒｎｅｔ端子、外部記録媒体（例えばＵＳＢメモリ、ＳＤカード、等）端子などを有し、車両制御システム２との通信が可能となっている。

第２車両制御システム４は、車両制御システム２とは異なるプロトコル又は同一のプロトコルを用いたネットワークにより構成されている。

駆動装置５は、車両制御システム２による制御に応じて車両の運動を制御する機械及び電気装置（例えば、エンジン、トランスミッション、ホイール、ブレーキ、操舵装置など）の駆動を行う装置であり、例えばアクチュエータである。

認識装置６は、車両システム１の外部又は車両システム１の状態に関する情報を取得する装置であり、例えば、車載カメラ、レーダ、ＬＩＤＡＲ、超音波センサなどの外界センサや、車両システム１の状態（運動状態、位置情報、加速度、車輪速度など）を認識する力学系センサにより構成されている。

出力装置７は、ネットワークシステムに有線又は無線で接続され、ネットワークシステムから送出されるデータを受信し、メッセージ情報（例えば、映像や音）など運転者に必要な情報を表示又は出力する装置であり、例えば、液晶ディスプレイ、警告灯、スピーカなどの出力装置である。

入力装置８は、運転者が車両制御システム２に対して、操作の意図や指示を入力する入力信号を生成するための装置であり、例えば、ステアリング、ペダル、ボタン、レバー、タッチパネルなどの装置である。

通知装置９は、車両システム１が外界に対して、車両の状態などを通知するための装置であり、例えば、ランプ、ＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）、スピーカなどの装置である。

＜物理アーキテクチャ＞
次に、車両制御システム２で用いられる物理アーキテクチャ３００の一例を説明する。
図３は、車両制御システム２で用いられる物理アーキテクチャ３００の一例を説明する図である。

図３に示すように、物理アーキテクチャ３００はハードウェア（Ｈａｒｄｗａｒｅ：Ｈ／Ｗ）構成とも言う。物理アーキテクチャ３００は、ネットワークリンク３０１とＥＣＵ３０２とを有して構成されている。ネットワークリンク３０１は、車載ネットワーク上のネットワーク装置を接続するものであり、例えば、ＣＡＮバスなどである。ＥＣＵ３０２は、ネットワークリンク３０１、図示しない他のネットワークリンク（専用線含む）、駆動装置５又は認識装置６に接続され、駆動装置５又は認識装置６の制御及び情報取得、ネットワークとのデータの送受信を行う。ＥＣＵ３０２は、複数のネットワークリンク３０１に接続され、それぞれのネットワークリンク３０１との間でデータの送受信を行うゲートウェイ（Ｇａｔｅｗａｙ：ＧＷ）の役割も担っている。

ネットワークトポロジの例として、実施形態では、図３に示すように２つのＣＡＮバスに複数のＥＣＵ３０２が接続されているバス型の場合を例示して説明したが、これに限定されるものではなく、例えば、複数のＥＣＵがＧＷに直接接続されているスター型や、ＥＣＵが一連のリンクにリング状に接続されているリンク型、それぞれの型が混在し複数のネットワークにより構成される混在型などでもよい。ＥＣＵ３０２は、ネットワークを介して受信したデータに基づいて、駆動装置５への制御信号の出力、認識装置６からの情報の取得、ネットワークへの制御信号及び情報の出力、内部状態の変更、などの制御処理を行う。前述したＥＣＵ３０２、ネットワークリンク３０１、及びＥＣＵ３０２内のプロセッサ（ＣＰＵ）を、以下、物理エレメントとも言う。

＜ＥＣＵの内部構成＞
次に、前述したＥＣＵ３０２の内部構成例を説明する。
図４は、ＥＣＵ３０２の内部構成例を説明する図である。

図４に示すように、ＥＣＵ３０２は、プロセッサ４０１と、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）４０２と、タイマ４０３と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）４０４と、ＲＡＭ（Ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）４０５とを有して構成されており、これらの各装置は内部バス４０６により接続されている。プロセッサ４０１は、例えば、ＣＰＵなどの演算処理装置であり、キャッシュやレジスタなどの記憶素子を有し、制御を実行する。Ｉ／Ｏ４０２は、ネットワークリンク３０１又はネットワークや専用線で接続された駆動装置５又は／及び認識装置６に対してデータの送受信を行う。タイマ４０３は、図示しないクロックなどを使用し、時間及び時刻の管理を行う。ＲＯＭ４０４は、制御プログラム及び不揮発性のデータの保存を行う。ＲＡＭ４０５は、制御プログラム以外のプログラム及び揮発性のデータの保存を行う。内部バス４０６は、ＥＣＵ３０２内部での通信に用いられる。

＜物理アーキテクチャのパラメータ＞
次に物理アーキテクチャ３００のパラメータの一例を説明する。
図５は、物理アーキテクチャ３００に付与されるパラメータの一例を説明する図であり、（Ａ）は物理アーキテクチャ３００が有する物理エレメント（ＥＣＵ又はプロセッサなど）に付与されるパラメータの一例であり、（Ｂ）は物理アーキテクチャが有するネットワークに付与されるパラメータの一例である。

図５の（Ａ）に示すように、物理アーキテクチャ３００の物理エレメントに付与されるパラメータは、演算性能と、ＲＡＭ量と、ＲＯＭ量と、対応安全度と、コスト（ＥＣＵなどの部品費用）と、マイコン種別と、ＯＳ・ＢＳＷ・ＨＶ種別と、を含んでいる。これらのうち、演算性能、ＲＡＭ量、ＲＯＭ量、対応安全度、コストは、ＥＣＵ又はプロセッサの持つパラメータであり、物理アーキテクチャ３００の定量評価に使用される。

また、マイコン種別（例えばチップベンダ名、型番）、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、ＢＳＷ（Ｂａｓｉｃ Ｓｏｆｔｗａｒｅ）の種別、それらに含まれるＨＶ（Ｈｙｐｅｒｖｉｓｏｒ）の実装の有無やその種類は、物理アーキテクチャ３００の再利用評価に使用されるＰＦ（Ｐｌａｔｆｏｒｍ）の情報である。Ｓ／Ｗは、これらＰＦ上で実行されるため、Ｓ／Ｗの再利用性を評価する際にこれらのパラメータが必要となる。

ここで対応安全度とは、安全性関連のパラメータであり、ハードウェアとして対応可能な安全度の要求レベルを評価するための情報である、例えば、対応安全度は、ＡＳＩＬ（Ａｕｔｏｍｏｔｉｖｅ Ｓａｆｅｔｙ Ｉｎｔｅｇｒｉｔｙ Ｌｅｖｅｌ）、ＱＭ（Ｑｕａｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ）などが挙げられえる。

また図５の（Ｂ）に示すように、物理アーキテクチャ３００のネットワークに付与されるパラメータは、通信速度と、コスト（ネットワークケーブルなどの費用）と、多重度と、を含んでいる。多重度は通信線の冗長度を示すパラメータである。

＜論理アーキテクチャ＞
次に、車両制御システム（例えば車両制御システム２）の論理アーキテクチャ６０１の機能構成の一例を説明する。
図６は、車両制御システム（第１車両制御システム２）の論理アーキテクチャ６０１の機能構成の一例を説明する図である。

図６に示すように、車両制御システム２の論理アーキテクチャ６０１は、統合認識部６０２と、自己位置推定部６０３と、経路計画部６０４と、周辺状況認知部６０５と、行動計画部６０６と、車両運動制御部６０７と、縦方向制御部６０８と、横方向制御部６０９と、を有して構成されている。これらの機能は、例えば、ＥＣＵ３０２のプロセッサ４０１が、ＲＯＭ４０４などに記憶された制御プログラムを実行することで、ＥＣＵ３０２（物理エレメント）上に実装される。

統合認識部６０２は、複数の認識装置６及び通信装置３から出力された情報（図中の矢印）を受信して認識結果の情報を出力する複数の認識部と、を有する。実施形態では、複数の認識部は、ＧＰＳなどを用いて高精度な地図情報を取得し、当該地図情報を出力する高精度地図認識部６０２１と、車載カメラやレーダなどの外界センサを用いて道路の車線情報を取得する車線認識部６０２２と、同じく外界センサを用いて道路に設置された標識や標示に関する情報を取得する標識／標示認識部６０２３と、同じく外界センサを用いて道路に設置された信号機の信号を取得する信号認識部６０２４と、同じく外界センサを用いて歩行者に関する情報を取得する歩行者認識部６０２５と、同じく外界センサを用いて周辺の車両に関する情報を取得する車両認識部６０２６と、車両の運動状態などの情報を取得する車両状態認識部６０２７と、を有して構成されている。

自己位置推定部６０３は、認識装置６から出力された情報と、統合認識部６０２（高精度地図認識部６０２１）から出力された地図情報とに基づいて、自己（自車両）の位置情報を推定すると共に、推定した自己位置情報を経路計画部６０４及び周辺状況認識部６０５に対して出力する。

経路計画部６０４は、統合認識部６０２（高精度地図認識部６０２１）から出力された地図情報と、自己位置推定部６０３から出力された自己位置情報とに基づいて自車両が走行する経路を演算及び決定する。

周辺状況認識部６０５は、統合認識部６０２から出力された外界認識情報（位置図情報、車線情報、標識／標示情報、信号情報、歩行者情報、車両情報）、車両運動状態、及び自己位置情報を統合して周辺情報を生成する。

行動計画部６０６は、周辺状況認知部６０５により生成された周辺情報と、統合認識部６０２（車両状態認識部６０２７）から出力された車両運動状態と、経路計画部６０４により決定された経路情報とに基づいて自動運転制御情報（軌道情報など）の生成及び出力を行う。

車両運動制御部６０７は、行動計画部６０６により生成された軌道情報と、統合認識部６０２（車両状態認識部６０２７）から出力された車両運動状態とに基づいて車両の運動制御値を算出し、縦方向制御部６０８及び横方向制御部６０９に対して出力する。

縦方向制御部６０８は、車両運動制御部６０７により算出された運動制御値に基づいて駆動装置５を駆動して車両の縦方向の運動制御を行い、横方向制御部６０９は、車両運動制御部６０７により算出された運動制御値に基づいて駆動装置５を駆動して車両の横方向の運動制御を行う。

＜論理アーキテクチャのパラメータ＞
次に論理アーキテクチャ６０１のパラメータの一例を説明する。
図７は、論理アーキテクチャ６０１のパラメータの一例を説明する図であり、（Ａ）は論理アーキテクチャ６０１の主機能に付与されるパラメータの一例であり、（Ｂ）は論理アーキテクチャ６０１の論理接続に対するパラメータの一例である。

図７の（Ａ）に示すように、論理アーキテクチャ６０１の主機能に付与されるパラメータは、演算量と、消費ＲＡＭと、消費ＲＯＭと、要求安全度と、Ｓ／Ｗ規模・複雑度を含んでいる。これらのパラメータのうち、演算量と、消費ＲＡＭと、消費ＲＯＭは、主に論理アーキテクチャ６０１の定量評価に使用される。また、Ｓ／Ｗ規模や複雑度は、後述する論理エレメントの再利用性の重み付けに使用される。ここで要求安全度とは、当該論理機能に要求される安全度であり、例えば、ＡＳＩＬやＱＭが付与され、当該安全レベルでの安全機能の実行が要求される。

図７の（Ｂ）に示すように、論理アーキテクチャ６０１の論理接続に関するパラメータは通信量を含んでいる。この通信量は論理アーキテクチャ６０１の定量評価に使用される。

＜製品系列と機能要件＞
次に複数の製品系列での機能要件の管理方法の一例を説明する。
図８は、複数の製品系列での機能要件の管理方法の一例を説明する図である。

図８に示すように、実施形態において製品系列とは、例えば、車両では高級モデル（Ｈｉｇｈ−ｇｒａｄｅモデル：以下、Ｈモデルとも言う）から普及モデル（Ｍｉｄｄｌｅ――ｇｒａｄｅ：以下、Ｍモデルとも言う）、廉価モデル（Ｌｏｗ−ｇｒａｄｅモデル：以下、Ｌモデルとも言う）を製品系列と言い、一つ一つの製品をモデルと言う。ただし実施形態において、製品系列は他の全く異なる車種も含み、ソフトウェアやＥＣＵを再利用して開発する範囲のことを言う。

また、実施形態において機能要件は車両制御システム２が有する論理機能の概要や使用を示す。例えば、車両制御システム２において、「車両運動制御」という論理機能の機能要件では、入力は軌道情報、出力は運動制御値であり、演算するアルゴリズムの概要やその動作範囲などが機能要件として定義される。

図８では、各モデルがどのような論理機能を有しているかを表形式のマトリクス状に管理している場合を例示して説明する。図８では、「〇」が論理機能の有無、アルファベットが異なる場合は該当する論理機能の機能要件が異なることを示している。

例えば、自己位置推定機能に関しては、ＨモデルとＭモデルが該当する論理機能を有しており、Ｌモデルは自己位置推定機能を有していない。周辺状況認知機能に関しては、Ｈモデル、Ｍモデル、Ｌモデルはそれぞれ当該論理機能を有しているが機能要件がそれぞれ異なる。行動計画機能に関しては、ＨモデルとＭモデルとが同様の機能要件を有し、Ｌモデルは異なる機能要件の行動計画を有していることを示している。

また各モデルの論理機能・機能要件をフィーチャーツリー構造などの他の表現方法で表してもよい。
図９は、全モデル（製品系列）の論理機能・機能要件をフィーチャーツリー構造で表した図である。
図１０は、Ｈモデルの論理機能・機能要件をフィーチャーツリー構造で表した図である。
図１１は、Ｍモデルの論理機能・機能要件をフィーチャーツリー構造で表した図である。
図１２は、Ｌモデルの論理機能・機能要件をフィーチャーツリー構造で表した図である。
図９〜図１２において、ツリーの各要素は論理機能と機能要件とを示しており、ツリーの種類は末端が黒丸のツリーはオプションを示し、何れかのモデルで当該機能を有しない場合があることを意味している。また、ツリーの内側に円弧が記載されている場合は選択を示し、各モデルで何れかの機能を選択することを示している。このようにして、製品系列のモデルごとの論理機能と機能要件の管理を行う。

＜各製品系列と論理アーキテクチャ＞
次に、製品系列全体での論理アーキテクチャ６０１の構成例を説明する。
図１３は、Ｈモデルの論理アーキテクチャ６０１の構成例を説明する図である。
図１４は、Ｍモデルの論理アーキテクチャ６０１の構成例を説明する図である。
図１５は、Ｌモデルの論理アーキテクチャ６０１の構成例を説明する図である。
図１３〜図１５では、各モデルで必要な論理機能を示すブロックと、そのインタフェース（接続）とを示している。

図１３に示すＨモデルについては、図６で説明した論理アーキテクチャ６０１の構成例と同様に全ての論理機能を有しているため、全ての論理機能のブロックを有している。一方で、図１４に示すＭモデルについては、統合認識部６０２の信号認識部６０２４と歩行者認識部６０２５との論理機能を有していないため、それらの論理機能が除かれている。また、図１５に示すＬモデルについては、統合認識部６０２の高精度地図認識部６０２１と、標識／標示認識部６０２３と、信号認識部６０２４と、歩行者認識部６０２５と、自己位置推定部６０３と、経路計画部６０４との論理機能を有していないため、それらの論理機能が除かれている。なお、図８で説明した機能要件一覧に示す通り、一部の論理機能（例えば、周辺状況認知）については、モデルにより機能が異なる。このようにしてモデルごとの論理機能の差分を反映した論理アーキテクチャ６０１を構築する。

＜製品系列と物理アーキテクチャ＞
次に製品系列全体における物理アーキテクチャ３００の構成例を説明する。
図１６は、各モデルにおける物理アーキテクチャ３００の構成例を説明する図であり、（Ａ）はＨモデルにおける物理アーキテクチャ３００の構成例であり、（Ｂ）はＭモデルにおける物理アーキテクチャ３００の構成例であり、（Ｃ）はＬモデルにおける物理アーキテクチャ３００の構成例である。このように実施形態では、各モデルにおける物理アーキテクチャ３００の構成例を３パターン示している。

図１６において、ＭＰＵ（Ｍａｐ Ｐｏｓｉｓｉｏｎｉｎｇ Ｕｎｉｔ）、ＡＤ−ＥＣＵ（Ａｕｔｏｎｏｍｏｕｓ Ｄｒｉｖｉｎｇ − Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：以下、ＡＤとも言う）、ＶＭＣ（Ｖｅｈｉｃｌｅ Ｍｏｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ）、ＡＤ（Ｌ）は、物理エレメント（ＥＣＵ）又はＥＣＵの一部の物理エレメントを示しており、ＥＣＵ間の結線はＮＷを示している。

図１６の（Ａ）に示すように、Ｈモデルでは、パターン１〜３の何れも物理エレメンＭＰＵ、ＡＤ、ＶＭＣを用いて、ＡＤとＭＰＵとが接続されていると共に、ＡＤとＶＭＣとが接続された構成となっている。

図１６の（Ｂ）に示すように、Ｍモデルでは、パターン１及びパターン２ではＡＤとＶＭＣとが接続された構成となっており、パターン３では、ＡＤとＭＰＵとが接続されていると共に、ＡＤとＶＭＣとが接続された構成となっている。

図１６の（Ｃ）に示すように、Ｌモデルでは、パターン１ではＡＤのみの構成となっており、パターン２及びパターン３ではＡＤ（Ｌ）のみの構成となっている。

評価装置１００は、前述した各製品系列に対して、複数の物理アーキテクチャ案（実施形態では、パターン１〜パターン３の３パターン）を評価し、比較検討を行うための情報を提示する。そして、ユーザは、評価装置１００での評価結果に基づいて、それぞれの物理アーキテクチャ案の各パターンにおいて各モデル（モデルＨ、Ｍ、Ｌ）の物理アーキテクチャと後述する機能配置について設計を行う。実施形態では、このように物理アーキテクチャを決定した後に、それぞれのＥＣＵに対して論理アーキテクチャの論理機能の配置を行う。

＜論理アーキテクチャの物理アーキテクチャへの機能配置＞
次に、物理アーキテクチャ３００の物理エレメントに対して論理アーキテクチャ６０１の論理エレメントを機能配置する場合の一例を説明する。
図１７は、物理アーキテクチャ３００の物理エレメントに対して論理アーキテクチャ６０１の論理エレメントを機能配置する場合の一例を説明する図であり、（Ａ）は各モデルにおけるパターン１の場合の機能配置の一例であり、（Ｂ）は各モデルにおけるパターン２の場合の機能配置の一例であり、（Ｃ）は各モデルにおけるパターン３の場合の機能配置の一例である。

図１７に示すように、機能配置の組み合わせは表形式によるマトリックス上で管理を行う。実施形態では、図１７に示す各表の行に各モデルの物理エレメント（ＥＣＵ）の一覧を記載し、表の列に論理エレメント（論理機能）の一覧を示している。表において、〇が存在する該当列の論理機能が当該行のＥＣＵ（ＭＰＵ、ＡＤ、ＡＤ（Ｌ）、ＶＭＣ）に配置されていることを示している。例えば、ＨモデルのＡＤ−ＥＣＵには、周辺状況認知機能と行動計画機能とが配置されていることを示している。このようにして、論理アーキテクチャ６０１の機能を物理アーキテクチャ３００に配置を行って管理を行う。これにより、どの論理機能の処理がどの物理エレメント（ＥＣＵ、プロセッサ）上で実行されるかが決定される。

＜論理アーキテクチャの再利用性の評価＞
次に、論理アーキテクチャ６０１の再利用性（共通性）の評価方法について説明する。実施形態では各論理エレメントを実現するためのソフトウェアモジュール（Ｓ／Ｗ）がどれだけ変更なく再利用できるかと言う観点で評価を行う。以下の機能は、評価装置１００のアーキテクチャ評価部１０３により実行される。

図１８は、各モデルにおいて、どの物理エレメント（ＥＣＵ）にどの論理エレメント（論理機能）が配置されているのかを示す表であり、（Ａ）はパターン１について整理したものであり、（Ｂ）はパターン２について整理したものであり、（Ｃ）はパターン３について整理したものである。図１８に示す表において、アルファベット（実施形態ではＡ〜Ｇ、ダッシュ（′）を含む）が記載されているマスについて、列に示される論理機能を、行に示されるＥＣＵのＰＦで実装することを示している。また、アルファベットのダッシュの有無は同一種類の論理機能であるが性能（機能要件：例えば、高性能、一般性能など）の違いを示しており、ＡとＡは同じ機能要件、ＡとＡ′は異なる機能要件を実装していることを示している。この情報は機能要件の一覧から取得することも可能である。

ここでパターン１における周辺状況認知機能のＳ／Ｗを例に示すと、ＨモデルではＡＤ−ＥＣＵのＰＦ上で実装され、ＭモデルではＨモデルと異なる機能要件（Ａ′）でＡＤ−ＥＣＵのＰＦ上で実装され、ＬモデルではＨモデル及びＭモデルとさらに異なる機能要件（Ａ″）でＡＤ−ＥＣＵのＰＦ上で実装されることを示している。また、実施形態では、過去資産を有しており、過去資産ではＡＤ−ＥＣＵ上のＰＦ上で実装されたＨモデルと同様の機能要件（Ａ）で開発したＳ／Ｗと、ＡＤＡＳ−ＥＣＵのＰＦ上で実装された機能要件（Ａ″）で開発したＳ／Ｗとを有していることを示している。ここで、過去資産とは、どの物理エレメントに対してどの論理機能を過去に配置したことがあるかを示しており、過去に配置したことのある物理エレメントに対する論理エレメントは、新たな設計において同じ物理エレメントに対してそのまま再利用することができる。

これらの情報に基づいて、Ｓ／Ｗの再利用性（ＳＷ＿Ｒｅｕｓｅ＿Ｒａｔｅ：以下、ＳＷＲとも言う）を以下の数式（１）により算出する。

ここで、ｎは再利用（以下、移植とも言う）するモジュール数、Ｘｎは移植時の変更量を示す。Ｘｎの算出の一例として、例えば、Ｓ／Ｗの変更が全くなく完全に再利用できる場合を１００、過去資産に該当するＳ／Ｗがなく新たに開発する場合を０（ゼロ）、機能仕様の変更（例えば、機能要件Ａから機能要件Ａ′、又は機能要件Ａ″に変更）がある場合には７５、実装するＰＦが変更（例えば、ＭＰＵからＡＤへの変更や、ＡＤＡＳからＡＤへの変更）となる場合には７５、機能仕様の変更とＰＦの変更の２つの変更がある場合には５０として計算する。この計算は簡易的な計算例であり、その他の計算方法としてもよい。

ＰＦの変更の有無については、Ｓ／Ｗが実装される各モデルの物理アーキテクチャ３００のパラメータに含まれるＯＳ、マイコン、ＢＳＷ、ＨＶなどの種別情報から変更の有無を判定する。

前述したＳ／Ｗの再利用の一例を説明する。
図１９は、Ｓ／Ｗの再利用の一例を説明する模式図である。図１９では、周辺状況認知機能のＳ／Ｗの移植を製品系列で行う例について示している。

周辺状況認知機能（Ａ）のＳ／Ｗは、ＨモデルのＡＤ−ＥＣＵに実装されており、同じ機能要件の周辺状況認知機能（Ａ）のＳ／Ｗが過去資産のＡＤ−ＥＣＵにも実装されている。このため、過去資産の周辺状況認知機能（Ａ）のＳ／Ｗは、機能変更もＰＦ変更もなくＨモデルのＡＤ−ＥＣＵに移植できるためＸｎ＝１００となる。一方、ＭモデルにおけるＡＤ−ＥＣＵに実装される周辺状況認知機能（Ａ′）のＳ／Ｗは、ＨモデルのＡＤ−ＥＣＵに実装される周辺状況認知機能（Ａ）から移植されるが、機能要件の変更（ＡからＡ′に変更）があるためＸｎ＝７５となる。また、ＬモデルにおけるＡＤ−ＥＣＵに実装される周辺状況認知機能（Ａ″）のＳ／Ｗは、過去資産のＡＤＡＳに実装される周辺状況認知機能（Ａ″）のＳ／Ｗから移植されるため、ＰＦの変更がありＸｎ＝７５となる。このようにして、各製品系列での論理機能のＳ／Ｗの再利用性の評価を行う。

機能変更がある場合のＸｎの算出方法については、前述した簡易的な算出方法の他に、例えば、変更となる要件数、インターフェース数、Ｓ／Ｗ規模、Ｓ／Ｗの複雑度などにより重み付けを行ってもよい。このようにすると、実際のＳ／Ｗの開発の工数に合わせて再利用性をより適切に評価することができる。また、ＰＦの変更がある場合のＸｎの値についても同様に演算することができ、ＯＳの類似性（例えば、移植容易な場合は数値を高くし、移植が困難な場合は数値を低くする）、マイコンの類似性（例えば、移植容易な場合は数値を高くし、移植が困難な場合は数値を低くする）、ＨＶの有無（例えば、ＨＶがある場合は移植が容易として数値を高くし、ＨＶがない場合は移植が困難として数値を低くする）を反映し重み付けをしてもよい。そうすることにより、実際のＳ／Ｗの開発の工数に合わせて再利用性を適切に評価することができる。

特にＸｎの重み付けの計算については、前述した論理機能に付与された要求安全度に基づいて重み付けを行うことが望ましい。これはＡＳＩＬの安全レベルが高いほど開発にかかる工数が多くなり、変更に伴う工数が大きく変わるためである。よって、論理機能のＳ／Ｗに変更がある場合、再利用性が低くなるように重み付けを行う。これにより実際のＳ／Ｗの開発の工数に合わせて再利用性を評価することが可能となる。

また、前述した算出方法により評価装置１００がＳ／Ｗの再利用性を評価した結果の一例は表示装置（図示せず）に表示される。
図２０は、評価装置１００による再利用性の評価結果の表示方法を説明する図である。

図２０に示すように、各論理機能のＳ／Ｗの再利用性の評価結果を、論理アーキテクチャ６０１のパターンごとに表示している。このように、各論理機能のＳ／Ｗの再利用性と論理アーキテクチャ６０１の各パターンとを同時に表示することにより、論理アーキテクチャ６０１のパターンごとのＳ／Ｗの再利用性の比較を容易化し、論理アーキテクチャ６０１の改善等が容易となる。特に、全てのＳ／Ｗの再利用性の総和（トータル）を出力することにより、論理アーキテクチャ全体での比較及び評価が容易となる。

また、前述した実施形態では、論理機能のＳ／Ｗの移植元について再利用性を評価する場合を例示して説明したが、移植元の選択については前述したＸｎが最小となる移植元のＳ／Ｗを評価装置１００が自動的に探索してもよい。そのようにすることにより、前述した再利用性の評価の最小化が容易となり、最適な論理アーキテクチャ６０１と移植元の検討が容易となる。

＜物理アーキテクチャの再利用性の評価＞
次に物理アーキテクチャ３００の再利用性の評価方法を説明する。物理アーキテクチャ３００については、ＥＣＵとＳ／Ｗとの組み合わせについて、どれだけ変更がなく再利用できるかを評価する。以下の機能は、評価装置１００のアーキテクチャ評価部１０３により実行される。

図２１は、各モデルにおける物理エレメント（ＥＣＵ）と、当該物理エレメントに実装された論理機能との関係をパターンごとに示した図であり、（Ａ）はパターン１について整理したものであり、（Ｂ）はパターン２について整理したものであり、（Ｃ）はパターン３について整理したものである。

図２１に示すように、表の行は全てのモデルのＥＣＵ（ＰＦ）を示しており、表の列は全ての論理機能を実装した場合のＳ／Ｗをモデルごとに示している。図２１に示す表では、アルファベット（実施形態ではＡ〜Ｇ、ダッシュ（′）を含む）が記載されているマスについて、列に示される論理機能を、行に示されるＥＣＵのＰＦで実装することを示している。また、アルファベットのダッシュの有無は同一種類の論理機能であるが性能（機能要件：例えば、高性能、一般性能など）の違いを示しており、ＡとＡは同じ機能要件、ＡとＡ′は異なる機能要件を実装していることを示している。この情報は機能要件の一覧から取得することも可能である。

また、実施形態では、各ＥＣＵについて、各モデルで実装される論理機能のＳ／Ｗが列のグループ（Ｈモデル、Ｍモデル、Ｌモデル）ごとに示されており、列では、全ての論理機能の実装を実現するためのＳ／Ｗをモデルごとに示されている。例えば、ＨモデルにおけるＡＤ−ＥＣＵは周辺状況認知機能（Ａ）と行動計画機能（Ｄ）とが実装されていることを示している。

前述した情報に基づいて評価するＨ／Ｗ（ＥＣＵ）の再利用性（ＨＷ＿Ｒｅｕｓｅ＿Ｒａｔｅ：以下、ＨＷＲとも言う）の評価式は、以下の数式（２）で表すことができる。

ここでｎは移植するモジュール数、ｍはＥＣＵ内のＳ／Ｗのモジュール数、Ｘｎｍは各Ｓ／Ｗの移植時の変更量を示す。Ｘｎｍの算出の一例として、例えば、物理アーキテクチャの変更が全くなく完全に再利用できる場合を１００、過去資産に該当する物理アーキテクチャがなく新たに開発する場合を０（ゼロ）、機能仕様の変更（例えば、機能要件Ａから機能要件Ａ′、又は機能要件Ａ″に変更）がある場合には７５、実装するＰＦが変更（例えば、ＭＰＵからＡＤへの変更や、ＡＤＡＳからＡＤへの変更）となる場合には７５、機能仕様の変更とＰＦの変更の２つの変更がある場合には５０として計算する。この計算は簡易的な計算例であり、その他の計算方法としてもよい。

ＰＦの変更の有無については、Ｓ／Ｗが実装される各モデルの物理アーキテクチャのパラメータに含まれるＯＳ、マイコン、ＢＳＷ、ＨＶなどの種別情報から変更の有無を判定する。

前述した物理アーキテクチャ３００の再利用の一例を説明する。
図２２は、物理アーキテクチャ３００の再利用の一例を説明する模式図である。図２２では、パターン１のＡＤ−ＥＣＵの再利用について、ＨモデルのＡＤ−ＥＣＵを基準としてＭモデルのＡＤ−ＥＣＵ、ＬモデルのＡＤ−ＥＣＵに再利用する場合を例示して説明する。

図２２に示すように、ＨモデルのＡＤ−ＥＣＵには、周辺状況認知機能（Ａ）と行動計画機能（Ｄ）のＳ／Ｗが実装されている。このＨモデルのＡＤ−ＥＣＵを再利用してＭモデルのＡＤ−ＥＣＵを開発する場合、ＭモデルのＡＤ−ＥＣＵに実装される周辺状況認知機能（Ａ′）は機能要件の変更（ＡからＡ′）があるのでＸｎｍは７５となる。ＨモデルのＡＤ−ＥＣＵに実装される行動計画機能（Ｄ）は、ＭモデルのＡＤ−ＥＣＵに実装される行動計画機能（Ｄ）と同じであるので、行動計画機能（Ｄ）のＳ／Ｗは機能要件の変更はなくＸｎｍは１００となる。ＭモデルのＡＤ−ＥＣＵに実装される自己位置推定機能（Ｂ′）と経路計画機能（Ｃ′）は、ＨモデルのＡＤ−ＥＣＵには実装されていないため新規の開発となり、何れもＸｎｍは０（ゼロ）となる。ＬモデルのＡＤ−ＥＣＵについても同様の演算を行い、それらを加算してパターン１におけるＡＤ−ＥＣＵの再利用性の評価を行う。このようにして、製品系列全体でＨ／Ｗの移植を行う場合のＥＣＵの再利用性の評価を行うことができる。

機能変更がある場合のＸｎｍの算出方法については、前述した簡易的な算出方法の他に、例えば、変更となる要件数、インターフェース数、Ｈ／Ｗ規模、Ｈ／Ｗの複雑度などにより重み付けを行ってもよい。このようにすると、実際のＨ／Ｗの開発の工数に合わせて再利用性をより適切に評価することができる。また、ＰＦの変更がある場合のＸｎｍの値についても同様に演算することができ、ＯＳの類似性（例えば、移植容易な場合は数値を高くし、移植が困難な場合は数値を低くする）、マイコンの類似性（例えば、移植容易な場合は数値を高くし、移植が困難な場合は数値を低くする）、ＨＶの有無（例えば、ＨＶがある場合は移植が容易として数値を高くし、ＨＶがない場合は移植が困難として数値を低くする）を反映し重み付けをしてもよい。そうすることにより、実際のＨ／Ｗの開発の工数に合わせて再利用性を適切に評価することができる。

特にＸｎｍの重み付けの計算については、前述した論理機能に付与された要求安全度、及び／又はＥＣＵの対応安全度に基づいて重み付けを行うことが望ましい。これはＡＳＩＬの安全レベルが高いほど開発にかかる工数が多くなり、変更に伴う工数が大きく変わるためである。よって、Ｈ／Ｗに変更がある場合、再利用性が低くなるように重み付けを行う。これにより実際のＨ／Ｗの開発の工数に合わせて再利用性を評価することが可能となる。

また、前述した算出方法により評価装置１００がＨ／Ｗの再利用性を評価した結果の一例は表示装置（図示せず）に表示される。
図２３は、評価装置１００による再利用性の評価結果の表示方法を説明する図である。

図２３に示すように、各Ｈ／Ｗ（ＥＣＵ）の再利用性を、物理アーキテクチャ３００のパターンごとに表示している。このように、各Ｈ／Ｗの再利用性と物理アーキテクチャ３００の各パターンとを同時に表示することにより、物理アーキテクチャ３００のパターンごとのＨ／Ｗの再利用性の比較を容易化し、物理アーキテクチャ３００の改善等が容易となる。特に、全てのＨ／Ｗの再利用性の総和（トータル）を出力することにより、物理アーキテクチャ全体での比較及び評価が容易となる。

なお前述したＨ／Ｗ（ＥＣＵ）の評価式については、移植モジュール数ｎで除算を行っていない。これは同じＨ／Ｗ（ＥＣＵ）は可能な限り再利用を行い製品系列で展開を行うことが望ましいためである。そのため差異が大きい場合でも再利用を行った方が、再利用の数値が高くなる。これにより、より再利用による開発工数を反映した物理アーキテクチャの評価をより適切に行うことができる。また一方で、移植モジュール数ｎで除算を行うことも可能である。これにより、製品展開数を考慮しない再利用性についても評価することが可能となる。

＜評価結果の表示方法＞
次にアーキテクチャの再利用性の評価結果の表示方法について説明する。アーキテクチャの再利用性の評価結果については、内容を確認してアーキテクチャの再設計が可能になるために、要改善となるポイントが確認できることが望ましい。以下の機能は、評価装置１００の評価結果出力部１０４により実行される。
図２４は、論理アーキテクチャ６０１の再利用性の評価結果の表示方法について説明する図である。
図２５は、物理アーキテクチャ３００の再利用性の評価結果の表示方法について説明する図である。

図２４に示すように、論理アーキテクチャ（Ｓ／Ｗ）の再利用性の評価結果の情報として、評価を行ったアーキテクチャのパターン、その中でのＳ／Ｗについて、再利用性が低い（例えばＸｎが１００以下）項目とその理由が記載されている。例えば、評価装置１００は、周辺状況認知機能（Ａ）のＳ／Ｗについて、製品系列のモデルごとに機能差分が有る点と、異なるＰＦに移植しているため再利用性が低下していることを表示装置（図示せず）表示する。このようにしてＳ／Ｗの再利用性が低下している部分とその理由を表示することにより、内容を確認してアーキテクチャや機能要件の再設計を行うことが可能となる。

次に図２５に示すように、物理アーキテクチャ（ＥＣＵ）の再利用性の評価結果の情報として、評価を行ったアーキテクチャのパターン、その中でのＨ／Ｗ（ＥＣＵ）のモデル展開の基準と展開先、ＥＣＵについて再利用性が低下している（例えばＸｎｍが１００以下）項目と、その理由を示している。この例では、ＨモデルのＡＤ＿ＥＣＵをＭモデルのＡＤ−ＥＣＵに展開する場合、周辺状況認知機能（Ａ）と行動計画機能（Ｄ）のＥＣＵには機能差分があり、自己位置推定と経路計画のＥＣＵが追加されている例を示している。ＨモデルのＡＤ−ＥＣＵからＬモデルのＡＤ−ＥＣＵに展開する場合ついても同様である。このようにしてＥＣＵの再利用性が低下している部分とその理由を表示することにより、内容を確認してアーキテクチャや機能要件の再設計を行うことが可能となる。

ここで表示する内容については、前述した機能差分があるという情報だけでなく、関連する各機能要件の違いについて、要件の詳細（例えば性能や仕様のパラメータの違い等）までトレースを行い表示することも可能である。そのようにすることにより、どのような機能が異なっているかも設計時点で可能になり、その差分が許容可能かを評価数値と共に判断して再設計を行うことも可能となる。またこれら表示の際に、図１６や図１８のような機能仕様の差分と機能配置を示す表を同時に表示しても良い。それにより、上記差分について視認が容易となる。

＜アーキテクチャの定量評価＞
アーキテクチャ定量評価においては、上記再利用性の評価を行ったアーキテクチャについて定量評価を行う。定量評価の方法としては、物理アーキテクチャの物理エレメントに配置された複数の論理機能、演算量、消費ＲＡＭ、消費ＲＯＭを合計し、物理エレメント上での使用率を計算する。また通信についても同様にネットワーク上の論理通信の使用量を合計し、占有率を計算する。また物理アーキテクチャ全体で、使用している、つまり論理機能が１つ以上配置されている物理エレメントについてのコスト（例えば、部品コスト費用）を合計する。これら計算により、定量評価が可能である。これにより再利用性と共にこれら定量的評価結果も評価することが可能となる。

以上説明した実施例によれば、製品系列でのアーキテクチャ開発において、論理アーキテクチャと物理アーキテクチャの再利用性について評価を行い、製品系列全体でのアーキテクチャの設計改善が容易となる。特に論理アーキテクチャにおける再利用性については、モデルごとの機能の差分（機能要件の違い、件数、インターフェース数、Ｓ／Ｗ規模、複雑性）や配置された物理アーキテクチャのＰＦの差分（ＯＳ、マイコン、ＢＳＷ、ＨＶ）を考慮した上での評価が可能になり、物理アーキテクチャにおける再利用性については配置されたＳ／Ｗの再利用性を考慮した上で評価を行うことが可能になる。

特に、開発工数に大きく影響がある安全性についてもそれぞれ付与されたパラメータと変更要求に応じて再利用性を評価することが可能となる。

またこれら情報について、再利用性の情報（個別のＳ／Ｗの再利用性の数値、総和）と、再利用性が低下する項目とその理由を表示することにより、再設計がより容易となる。
また別の実施例によれば、論理アーキテクチャや物理アーキテクチャの情報に加え、ミドルウェアについても同様に再利用性を考慮して評価することにより、同様にミドルウェアの情報を含め再利用性を評価して出力することが可能となる。

以上説明した通り、第１の実施の形態では、
（１）車両制御システム２の機能要件（製品系列又はモデルＨ、Ｍ、Ｌ）ごとに設定される、複数の論理アーキテクチャ６０１間の再利用性、および／または論理アーキテクチャ６０１を配置する複数の物理アーキテクチャ３００間の再利用性を評価する車両（移動体）制御システムの評価装置１００であって、論理アーキテクチャ６０１の論理エレメントを物理アーキテクチャ３００の物理エレメントに配置する機能配置部１０１と、機能配置部１０１により配置された複数の論理アーキテクチャ６０１間の再利用性、および／または複数の物理アーキテクチャ３００間の再利用性を、機能要件の差分に基づいて評価するアーキテクチャ評価部１０３と、アーキテクチャ評価部１０３により評価された再利用性の評価結果を出力する評価結果出力部１０４と、を有する構成とした。

このように構成すると、車両制御システム２の製品系列での再利用性（共通性）を考慮した上で論理アーキテクチャ６０１及び物理アーキテクチャ２０の評価を行い、製品系列で最適なアーキテクチャの設計の指針を提供することができる。

（２）また、アーキテクチャ評価部１０３は、論理エレメントが配置された物理エレメントのプラットフォーム（ＰＦ）の情報を用いて、複数の論理エレメント間の再利用性、および／または複数の物理エレメント間の再利用性を算出する構成とした。また、アーキテクチャ評価部１０３は、論理エレメントの機能要件（高性能または一般性能など）の変更情報を用いて、複数の論理エレメント間の再利用性、および／または複数の物理エレメント間の再利用性を算出する構成とした。

このように構成すると、論理アーキテクチャ６０１における再利用性については、モデル（例えばモデルＨ、Ｍ、Ｌ）ごとの論理機能の差分（機能要件の違い、件数、インターフェース数、Ｓ／Ｗ規模、複雑性など）や、論理アーキテクチャが配置された物理アーキテクチャのＰＦの差分（ＯＳ、マイコン、ＢＳＷ、ＨＶ）を考慮した上での評価が可能となり、物理アーキテクチャ２０における再利用性については配置されたＳ／Ｗの再利用性を考慮した上で評価を行うことが可能となる。

（３）また、アーキテクチャ評価部１０３は、論理エレメントの要求安全度（例えば、ＡＳＩＬやＱＭ）または物理エレメントの対応安全度（例えば、ＡＳＩＬやＱＭ）に基づいて、複数の論理エレメント間の再利用性、および／または複数の物理エレメント間の再利用性を算出する構成とした。

このように構成すると、論理エレメントの要求安全度や物理エレメントの対応安全度の安全レベルが高い場合、開発工数が多くなってしまう。そこで、アーキテクチャ評価部１０３は、論理エレメントの要求安全度や物理エレメントの対応安全度に基づいてアーキテクチャの再利用性を評価することで、実際の開発工数を反映したアーキテクチャの再利用性の評価を適切に行うことができる。

（４）また、評価結果出力部１０４は、再利用性の評価結果の出力と共に、再利用性が低下する項目およびその理由を出力する構成とした。

このように構成すると、アーキテクチャの再利用性が低下する項目及び理由が視認により容易に理解できるようになり、再利用性を高めるための設計を効率よく行うことができる。

＜第２の実施の形態＞
次に、本発明の評価装置１００の第２の実施形態を説明する。第２の実施形態では、さらにミドルウェア（ＢＳＷ等）の再利用性を含めた評価を行う点が前述した実施の形態と異なるところである。ミドルウェアについては論理機能を実行するＰＦの一部であるが、製品系列のモデル化開発時に再利用を伴い開発を行うため、その再利用性を含めて評価することも重要となる。ここでミドルウェアとは、例えばＯＳとアプリケーションソフトウェアとの間でデータのやり取りを行うソフトウェアのことを言う。

図２６は、第２の実施形態にかかる各モデル（Ｈモデル、Ｍモデル、Ｌモデル）に実装された論理機能を表形式で表したものである。図２６では、ミドルウェアも考慮した論理機能の再利用性に必要な情報の管理表を示す。ここでは論理機能のＳ／Ｗと同列にミドルウェアを記載している。アルファベットの表記は論理機能のＳ／Ｗと同様で、同じアルファベットでダッシュの表記が無いものは完全再利用（ＨとＨ）、ダッシュの表記があるものは機能仕様が異なる再利用（ＨとＨ’）を示している。異なるアルファベットでは再利用を行わないことを示している（例えばＨとＩ）。

このように再利用性を管理した後の評価方法は前述した第１の実施形態と同様であり、ミドルウェアについても再利用性を評価式（１）により計算し出力する。このようにすることにより、ミドルウェアの再利用性についても評価が可能となる。

また図２７にミドルウェアも考慮したＨ／Ｗ（ＥＣＵ）の再利用性に必要な情報の管理表を示す。ここではモデルごとにミドルウェアを記載している。アルファベットの表記は上記論理機能の場合と同様である。このように再利用性を管理した後の評価は前述した第１の実施形態と同様であり、ＥＣＵに実装されたミドルウェアについてもＥＣＵの再利用性に含めて評価式（２）により計算して出力する。このようにすることにより、ミドルウェアの再利用性も考慮してＨ／Ｗ（ＥＣＵ）の再利用性の評価が可能となる。

以上説明した通り、第２の実施の形態では、
（５）アーキテクチャ評価部１０３は、ミドルウェアの再利用性を含めて複数の論理エレメント間の再利用性、および／または複数の物理エレメント間の再利用性を算出する構成とした。

前述した車両制御システムにおいて、ＯＳと各アプリケーションソフトウェアとの間に入るミドルウェアの開発工数が発生する。
このように構成すると、アーキテクチャ評価部１０３は、ミドルウェアの再利用性を含めてアーキテクチャの再利用性を評価することで、実際の開発工数を反映した評価をより適切に行うことができる。

以上、本発明の実施の形態の一例を説明したが、本発明は、前述した実施の形態を全て組み合わせてもよく、何れか２つ以上の実施の形態を任意に組み合わせても好適である。

また、本発明は、前述した実施の形態の全ての構成を備えているものに限定されるものではなく、前述した実施の形態の構成の一部を、他の実施の形態の構成に置き換えてもよく、また、前述した実施の形態の構成を、他の実施の形態の構成に置き換えてもよい。

また、前述した実施の形態の一部の構成について、他の実施の形態の構成に追加、削除、置換をしてもよい。

１：車両システム、２：第１車両制御システム、３：通信装置、４：第２車両制御システム、５：駆動装置、６：認識装置、７：出力装置、８：入力装置、９：通知装置、４０：安全分析情報、５０：評価結果、１００：車両制御システム評価装置、１０１：機能配置部、１０２：安全性検証部、１０３：アーキテクチャ評価部１０３、１０４：評価結果出力部、２００：論理アーキテクチャ、３００：物理アーキテクチャ、３０１：ネットワークリンク、３０２：ＥＣＵ、４０１：プロセッサ、４０２：Ｉ／Ｏ、４０３：タイマ、４０４：ＲＯＭ、４０５：ＲＡＭ、４０６：内部バス、６０１：論理アーキテクチャ、６０２：統合認識部、６０２１：高精度地図認識部、６０２１：高精度地図認識部、６０２２：車線認識部、６０２３：標識／標示認識部、６０２４：信号認識部、６０２５：歩行者認識部、６０２６：車両認識部、６０２７：車両状態認識部、６０３：自己位置推定部、６０４：経路計画部、６０５：周辺状況認知部、６０６：行動計画部、６０７：車両運動制御部、６０８：縦方向制御部、６０９：横方向制御部

Claims (11)

1. 車両制御システムの機能要件ごとに設定される、複数の論理アーキテクチャ間の再利用性、および／または前記論理アーキテクチャを配置する複数の物理アーキテクチャ間の再利用性を評価する移動体制御システムの評価装置であって、
   前記論理アーキテクチャの論理エレメントを前記物理アーキテクチャの物理エレメントに配置する機能配置部と、
   前記機能配置部により配置された複数の前記論理アーキテクチャ間の再利用性、および／または複数の前記物理アーキテクチャ間の再利用性を、前記機能要件の差分に基づいて評価する評価部と、
   前記評価部により評価された再利用性の評価結果を出力する評価結果出力部と、を有する移動体制御システムの評価装置。
2. 前記評価部は、前記論理エレメントが配置された前記物理エレメントのプラットフォームの情報を用いて、複数の前記論理アーキテクチャ間の再利用性、および／または複数の前記物理アーキテクチャ間の再利用性を算出する請求項１に記載の移動体制御システムの評価装置。
3. 前記評価部は、前記機能要件の変更情報を用いて、複数の前記論理アーキテクチャ間の再利用性、および／または複数の前記物理アーキテクチャ間の再利用性を算出する請求項１に記載の移動体制御システムの評価装置。
4. 前記評価部は、前記物理エレメントに配置される前記論理エレメントの機能要件の変更情報を用いて、複数の前記物理エレメント間の再利用性を算出する請求項３に記載の移動体制御システムの評価装置。
5. 前記評価部は、前記論理エレメントの要求安全度または前記物理エレメントの対応安全度に基づいて、複数の前記論理エレメント間の再利用性、および／または複数の前記物理エレメント間の再利用性を算出する請求項１に記載の移動体制御システムの評価装置。
6. 前記評価結果出力部は、前記再利用性の評価結果の出力と共に、前記再利用性が低下する項目およびその理由を出力する請求項１に記載の移動体制御システムの評価装置。
7. 前記評価部は、ミドルウェアの再利用性を含めて前記複数の論理エレメントおよび前記複数の物理エレメントの少なくとも何れかの再利用性を算出する請求項１に記載の移動体制御システムの評価装置。
8. 車両制御システムの機能要件ごとに設定される、複数の論理アーキテクチャ間の再利用性、および／または前記論理アーキテクチャを配置する複数の物理アーキテクチャ間の再利用性を評価する移動体制御システムの評価方法であって、
   前記論理アーキテクチャの論理エレメントを前記物理アーキテクチャの物理エレメントに配置する機能配置ステップと、
   前記機能配置ステップにより配置された複数の前記論理アーキテクチャ間の再利用性、および／または複数の前記物理アーキテクチャ間の再利用性を、前記機能要件の差分に基づいて評価する評価ステップと、
   前記評価ステップにより評価された再利用性の評価結果を出力する評価結果出力ステップと、を有する移動体制御システムの評価方法。
9. 前記評価ステップは、前記論理エレメントが配置された前記物理エレメントのプラットフォームの情報を用いて、複数の前記論理エレメント間の再利用性、および／または複数の前記物理エレメント間の再利用性を算出する請求項８に記載の移動体制御システムの評価方法。
10. 前記評価ステップは、前記論理エレメントの機能要件の変更情報を用いて、複数の前記論理エレメント間の再利用性、および／または複数の前記物理エレメント間の再利用性を算出する請求項８に記載の移動体制御システムの評価方法。
11. 前記評価ステップは、ミドルウェアの再利用性を含めて複数の前記論理エレメント間の再利用性、および／または複数の前記物理エレメント間の再利用性を算出する請求項８に記載の移動体制御システムの評価方法。

Images