JP6890460B2 - 車両制御システム検証手法および検証装置および制御装置 - Google Patents

Description

本発明は、車両制御システム検証手法および検証装置および制御装置に関する。

本技術分野の背景技術として、特開２００６−０１２００８号公報（特許文献１）がある。この公報には、「理想クロック条件と伝搬クロック条件との２種類のモードを有するタイミングモデルを用いて、効率良く、機能ブロックを含んだＬＳＩの設計を行う方法を提供する。」ことを課題とし、解決手段として、「複数のフリップフロップを含む機能ブロックを用いたＬＳＩ設計方法であって、第１モードと第２モードで使用可能なタイミングモデルを準備するステップと、機能ブロックを１又は複数含む機能要素の機能設計を行うステップと、機能設計で定められた機能要素に対し、機能ブロックのタイミングモデルを第１モードで用いて論理合成するステップと、論理合成された機能要素に対し、タイミングモデルを第１モードで用いて第１タイミング解析を行うステップと、論理合成と第１タイミング解析の結果に基づきレイアウトを行うステップと、レイアウト後にタイミングモデルを第２モードで用いて第２タイミング解析を行うステップと、を含むことを特徴とするＬＳＩ設計方法。」が記載されている。

また別の背景技術として、特開平１０−３４０２９２号公報（特許文献２）がある。この公報には、「半導体集積回路の設計において、タイミング制約を満足させるために発生する論理設計を含めたレイアウト設計の繰り返しフローを削減し設計時間の短縮を図るレイアウト方法の提供。」を課題とし、解決手段として、「下地基板上で複数のトランジスタから構成された論理機能単位のセルを配置し、セル間を信号配線で接続する半導体集積回路のレイアウトを行う際に、配置処理の中で、与えられた最大遅延時間の要求に対する遅延時間余裕度の無い、または少ない信号パス系列を構成するセルに対し、遅延時間余裕度が大きくなる度合と高密度化を考慮した上で配線改善処理と、セルを論理的に等価で駆動能力の異なるセルに置き換えるセル置換処理とを自動選択して実行する。」と記載されている。

特開２００６−０１２００８号公報 特開平１０−３４０２９２号公報

上記背景技術では、論理機能を物理エレメントに配置した場合の遅延時間の演算方法や、改善部分の自動選択の方法などが記載されているが、機能配置について多くの候補を選択する場合等に必要な演算の効率方法については述べられておらず、さらに安全機能などシステムとして充足が必須の機能とそれ以外の機能について異なる判定方法を用いることなどは記載されていない。

特に制御成立性については、論理アーキテクチャおよび物理アーキテクチャの最適設計および最適配置において、無数の組み合わせの中から制御成立性を満たすアーキテクチャを選定および設計を行う必要がある。その場合に、上記各論理機能の物理エレメント上での動作についてシミュレーションを行うなどにより多くの組み合わせや動作パターンを検証する内容においては、一つの組合せに対する演算時間が多くかかり、最適設計に費やす時間が多くなるという問題点がある。

本発明は上記状況に鑑みて為されたものであり、論理機能を物理エレメントに配置した場合の効率的な制御成立性の判定方法と、安全に関する要件を充足するための判定方法を実現するシステムを提供する。

上記課題を解決するために、本発明の一実施の態様は、例えば特許請求の範囲に記載されている技術的思想を用いればよい。

本発明によれば、論理機能を物理エレメントに配置した場合の効率的な制御成立性の判定方法と、安全に関する要件を充足するための判定方法を実現するシステムを提供することができる。

車両制御システム検証装置である。 システムの例である。 物理アーキテクチャの例である。 コントローラの構成例である。 物理アーキテクチャのパラメータの例である。 論理アーキテクチャの例である。 論理アーキテクチャのパラメータの例である。 論理アーキテクチャを物理アーキテクチャに配置した例である。 安全性検証の処理フローである。 時間要件テーブルの例である。 ベンチマークスコアの例である。 本発明の第１の実施例にかかるアーキテクチャ評価結果の表示例である。 本発明の第３の実施例にかかるアーキテクチャ評価結果の表示例である。 本発明の第４の実施例にかかる車両制御システムである。 アーキテクチャ構成情報の例である。

以下、本発明に好適な実施形態の例（実施例）を説明する。本実施例は、主には車両制御システムの検証装置について説明しており、車両システムの検証における実施に好適であるが、それ以外への適用を妨げるものではない。

＜車両制御システム検証装置＞
車両制御システム検証装置の全体を図１に示す。車両制御システム検証装置１００は、機能配置部１０１、安全性検証部１０２、アーキテクチャ定量評価部１０３、遅延時間計算部１０４、制御成立性判定部１０５から構成される。

機能配置部（配置部）１０１では、論理アーキテクチャ６０１と物理アーキテクチャ２を入力とし、機能配置の例のように論理アーキテクチャを物理アーキテクチャ上に配置を行う。

安全性検証部（検証部）１０２は、機能配置後のアーキテクチャとそのパラメータを入力とし、安全性検証のフローに従い、安全性の検証を行い、安全性検証のＯＫまたはＮＧ、ＮＧの場合の理由を出力する。

アーキテクチャ定量評価部１０３は前記検証結果を受け、主に安全性検証がＯＫのアーキテクチャについて評価を行い、評価結果を出力する。このようにして車両制御システムの検証および評価を実施する。

遅延時間計算部１０４は、機能配置後、特に安全性検証でＯＫと判定されたアーキテクチャの情報を基に、後述する遅延時間計算を実施する。制御成立性判定部１０５は、遅延時間計算部１０４の計算結果とアーキテクチャの情報を基に制御成立性判定を行い、ＯＫまたはＮＧと、その評価結果を出力する。

論理アーキテクチャ、物理アーキテクチャ、機能配置、安全性検証の内容については後述する。

＜車両制御システムの構成＞
評価を行う車両制御システムの構成を示す。図２は車両制御システムおよび車両制御装置を有する車両システムの概要である。以下図示の各符号について説明する。
１は、自動車など内部に車両制御システムを有する車両システムである。
２は、例えば車載ネットワーク（ＣＡＮ：Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ、ＣＡＮＦＤ：ＣＡＮ ｗｉｔｈ Ｆｌｅｘｉｂｌｅ Ｄａｔａ−ｒａｔｅ、Ｅｔｈｅｒｎｅｔ（登録商標）、等）とコントローラ（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ等）により構成される車両制御システムである。
３は、車両システム１の外部と無線通信（例えば携帯電話の通信、無線ＬＡＮ、ＷＡＮ、Ｃ２Ｘ（Ｃａｒ ｔｏ Ｘ：車両対車両または車両対インフラ通信）等のプロトコルを使用した通信、またはＧＰＳ：Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍを用いた通信）を行い、外界（インフラ、他車、地図）の情報または自車に関する情報を取得・送信などの無線通信を実施、または診断端子（ＯＢＤ）やＥｔｈｅｒｎｅｔ端子、外部記録媒体（例えばＵＳＢメモリ、ＳＤカード、等）端子などを有し、車両制御システム２と通信を実施する通信装置である。
４は、例えば２と異なる、または同一のプロトコルを用いたネットワークにより構成される車両制御システムである。
５は、車両制御システム２の制御に従い、車両運動を制御する機械および電気装置（例えばエンジン、トランスミッション、ホイール、ブレーキ、操舵装置等）の駆動を行うアクチュエータ等の駆動装置である。
６は、外界から入力される情報を取得し情報を生成するための情報を出力する、カメラ、レーダ、ＬＩＤＡＲ、超音波センサなどの外界センサ、および、車両システム１の状態（運動状態、位置情報、加速度、車輪速度等）を認識する力学系センサにより構成される認識装置である。
７は、ネットワークシステムに有線または無線で接続され、ネットワークシステムから送出されるデータを受信し、メッセージ情報（例えば映像、音）など必要な情報を表示または出力する、液晶ディスプレイ、警告灯、スピーカなどの出力装置である。
８は、ユーザが車両制御システム２に対して、操作の意図や指示を入力する入力信号を生成するための、例えばステアリング、ペダル、ボタン、レバー、タッチパネル、等の入力装置である。
９は、車両システム１が外界に対して、車両の状態等を通知するための、ランプ、ＬＥＤ、スピーカ等の通知装置である。

車両制御システム２は、その他の車両制御システム４、無線通信部３、駆動装置５、認識装置６、出力装置７、入力装置８、通知装置９などと接続され、それぞれ情報の送受信を行う。

＜物理アーキテクチャ＞
図３は、車両制御システム２の物理アーキテクチャ例を示している。物理アーキテクチャ３００はＨ／Ｗ（Ｈａｒｄｗａｒｅ）構成とも呼ぶ。３０１は車載ネットワーク上のネットワーク装置を接続するネットワークリンクであり、例えばＣＡＮバスなどのネットワークリンク、３０２はネットワークリンク３０１および駆動装置５や認識装置６や３０１以外のネットワークリンク（専用線含む）に接続され、駆動装置５や認識装置６の制御および情報取得、ネットワークとのデータ送受信を行うＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：電子制御ユニット）を示している。ＥＣＵは複数のネットワークリンク３０１を接続し、それぞれのネットワークリンクとデータの送受信を行うゲートウェイ（以下ＧＷ）の役割も担う。

ネットワークトポロジの例は、図３に示す２つのバスに複数のＥＣＵが接続されているバス型の例以外にも、複数のＥＣＵが直接ＧＷに接続されるスター型や、ＥＣＵが一連のリンクにリング状に接続されているリンク型、それぞれの型が混在し複数のネットワークにより構成される混在型、等がある。ＥＣＵ３０２はネットワークから受信したデータをもとに、駆動装置５への制御信号の出力、認識装置６からの情報の取得、ネットワークへの制御信号および情報の出力、内部状態の変更、などの制御処理を行う。

ＥＣＵ３０２、ネットワーク３０１、およびＥＣＵ内のプロセッサを以下「物理エレメント」とも呼ぶ。

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

＜物理アーキテクチャのパラメータ＞
物理アーキテクチャの物理エレメント（ＥＣＵ、プロセッサ）に付与するパラメータについて、図５Ａに示す。パラメータとしては、演算性能、ＲＡＭ量、ＲＯＭ量、コストを有し、アーキテクチャの評価に使用する。

安全性関連のパラメータとして、ハードウェアとして対応可能な安全度を有する。例としてはＡＳＩＬやＱＭなどである。多重度は例えば２重系で１系統の故障にも対応可能な場合には２（多重度の数）とする。故障率は前記物理エレメントの故障確率を安全検証に使用するパラメータとして入力する。診断率は物理エレメントで有する機能（例えばマイコン診断など）の診断のカバレッジを示している。

ＥＣＵの内部にマイコンが配置されている場合、検証の際にはＥＣＵ、プロセッサのいずれかにパラメータが付与されており、そのどちらかのパラメータを使用する。ＥＣＵとマイコンの双方にパラメータが付与されている場合には、安全性を考慮し、より悪い結果を出力するパラメータ（例えばＡＳＩＬとして低い値）を検証に使用することにより、誤って高い検証結果を出すことがなくなり、全体としての安全性を確保することが可能となる。

また、ネットワークに付与するパラメータを図５Ｂに示す。ネットワークは通信速度、コスト、多重度（通信線の冗長度）のパラメータを有する。

＜論理アーキテクチャ＞
車両制御システムの論理アーキテクチャ例について図６に示す。
６０１は、車両制御システムの論理アーキテクチャ全体を示している。
６０２は、複数の認識装置６および通信装置３から出力される外界認識情報を統合した外界認識マップを作成する統合認識部である。
６０３は、統合認識部６０２により生成された外界認識マップおよびユーザ入力部６０４から入力されたユーザ入力により、自動運転制御情報（軌道等）の生成および出力、出力管理部６０５への出力指示、および通知管理部６０６への通知指示を行う自動運転制御部である。
６０４は、入力装置８からの入力に従い、ユーザの指示情報を生成するユーザ入力部である。
６０５は、自動運転制御部６０３および異常検出部６０７の出力に応じ出力装置７への出力指示を行う出力管理部である。
６０６は、自動運転制御部６０３および異常検出部６０７の出力に応じ通知装置９への通知指示を行う通知管理部である。
６０７は、自動運転制御部６０３からの自動運転制御情報等の通知または図示していない各部からの通知により異常を検出する異常検出部である。
６０８は、異常検出部６０７の異常検出結果等により、運動制御部６０９に対する出力を自動運転制御部６０３からの入力またはユーザ入力部６０４からの入力または安全制御部６１０の入力に切替える切替部である。
６０９は、切替部６０８からの軌道情報または運動制御情報、認識装置６から取得する車両システム１の状態、および駆動装置５からの応答、に従い複数の駆動装置５に対して制御を行う運動制御部である。
６１０は、異常検出の通知を受けた場合の制御を実施する安全制御部である。

この例において、通常時に主要な制御を行う機能を主機能と呼び、ここでは６０２、６０３、６０４、６０５、６０６、６０９、が該当する。また異常の検出および異常発生後に主要な制御を行う機能を安全機能と呼び、６０７、６０８、６１０、が該当する。

＜論理アーキテクチャのパラメータ＞
論理アーキテクチャのパラメータ例を図７に示す。図７Ａは主機能に付与されるパラメータであり、論理機能のタイプは主機能・安全機能の判定に使用され、実行時間（ある実行環境における）、制御周期（実行周期）、機能の実行優先度、消費ＲＡＭ、消費ＲＯＭは主にアーキテクチャの評価に使用される。

図７Ｂは安全機能に付与されるパラメータであり、論理機能のタイプ、実行時間（ある実行環境における）、制御周期、機能の実行優先度、消費ＲＡＭ、消費ＲＯＭは主機能等同様に使用される。

要求安全度は該当安全機能に要求される安全度であり、例えばＱＭやＡＳＩＬが付与され、該当安全度での安全機能実行を要求される。

独立性要求は、該当する安全機能について、故障発生時に同時に故障するべきではない機能の論理機能名が記載されている。これは例えば安全機能と主機能が同時に故障し、結果として安全制御が不可能となる、共通原因故障や従属故障といった設計を防ぐためのパラメータとなる。

実行時間（ある実行環境における）は、特定の実行環境で実行された時間について、それぞれの論理機能がパラメータとして保持している。実行環境とは、例えばマイコンの種別、動作周波数、等である。これら実行環境における実行時間を保持しておき、物理配置時の実行時間を計算する。そのため実行時間は実行環境ごとに複数持つ可能性がある。実行時間については測定の方法により楽観的または悲観的の２種類を有することがあり、楽観的とは例えば平均値、最頻値、中央値等があり、悲観的とは最悪値、余裕度や安全度を加味した平均値、等があり、ここでは悲観的な値は楽観的な値以上である。

図７Ｃは論理接続に対するパラメータであり、該当通信路での通信量を示している。これはアーキテクチャ定量評価に使用される。

＜機能配置例＞
論理アーキテクチャの物理アーキテクチャへの配置例を図８に示す。このように論理アーキテクチャ上の論理機能を物理アーキテクチャ上に配置する。これにより、どの論理機能の処理がどの物理エレメント（ＥＣＵ、マイコン）上で実施され、ネットワークでの通信においてどのようなデータが処理されるかが決定される。

論理機能間で、ネットワークで複数の経路がある場合には、例えばその中で最小のコスト（通信帯域、ホップ数）となる経路を選択するなどして効率の良い通信を実施する。
機能配置については、例えば前述する論理アーキテクチャの物理アーキテクチャに対する網羅的な配置も実施する。例えば論理アーキテクチャの全ての論理機能（Ｌａ， Ｌｂ， Ｌｃ， ．．．）について、物理アーキテクチャの全てのエレメント（Ｐａ， Ｐｂ， Ｐｃ， ．．．）に対して全ての組合せで配置を行う。例えば最初はＰａに全ての論理機能を集約、次にＰｂに一つだけの論理機能（例えばＬａ）を配置しそれ以外はＰａに全て配置、と順次実施する。全ての組合せで配置を行い、それぞれを評価することにより、最適なアーキテクチャの選択が可能となる。

＜安全性検証＞
安全性検証の処理フローについて図９に示す。安全性検証においては、まず後述する安全要件検証を、機能配置後のアーキテクチャについて実施する（Ｓ９０１）。安全要件の検証結果がＯＫの場合（Ｓ９０２のｙｅｓ）、結果としてＯＫを出力して処理を終了する（Ｓ９０３）。安全要件の検証結果がＮＧの場合（Ｓ９０２のｎｏ）、ＮＧ結果と、いずれの安全要件の検証がＮＧであったかを出力する。このようにして安全性の検証を実施する。

＜安全要件検証＞
安全要件検証の例においては、該当する安全機能の物理アーキテクチャでの配置先において、安全度、多重度の要件を満たしているかを判定する。これは安全度の場合には該当する安全機能のパラメータにおける要求安全度の値が、配置先の物理エレメントの対応安全度より小さいまたは等しい場合にはＯＫと判定する。具体的には、安全機能の要求安全度がＡＳＩＬ−Ｃの場合、配置先の物理エレメントの対応安全度がＡＳＩＬ−Ｃかそれ以上（ＡＳＩＬ−Ｄ等）の場合にＯＫと判定する。多重度の場合には、該当する安全機能のパラメータにおける多重度の値が、配置先の物理エレメントの多重度より小さいまたは等しい場合にはＯＫと判定する。具体的には、安全機能の多重度が２の場合、配置先の物理エレメントの多重度が２以上の場合にＯＫと判定する。このようにして全体での安全要件の検証を行う。

＜時間要件＞
論理アーキテクチャに付与される時間要件の例について図１０に示す。ここでは１０００が時間要件テーブル全体を示しており、１００１が要件のＩＤ、１００２が時間要件の種別、１００３が制約時間、１００４が、時間要件が要求される論理機能のパスを示している。

要件の種別は、例えば主機能（ＮＦ）と安全機能（ＳＭ）を区別するために用いられる。また制約時間は、各時間要件の入力から出力までの時間の制約を示しており、入力から出力までの処理を制約時間以下で実施するという制約を示している。

ここで機能パスでは、論理アーキテクチャ６０１における上記時間制約が適用される機能パスを示している。ＩＤ１の例では、認識装置６から論理パスＬ１（６０１に図示）を経由して統合認識部６０２、統合認識部６０２から論理パスＬ２を経由して自動運転制御部６０３に、と以下同様の経路についての機能パスが示されている。上記時間制約は、この機能パスを経由し、ＩＤ１の例では認識装置６の入力から駆動装置５に出力が到達するまでの時間制約を示している。

＜遅延時間計算＞
遅延時間計算部１０４で実施される、論理機能が物理エレメントに配置された場合の遅延時間の計算方法について以下説明する。

まず一つ目の例では、各論理機能の実行時間について、物理エレメントの演算性能（例えば動作周波数：ＭＨｚ）における実行時間について各論理機能に予め割り当てておき、配置先の物理エレメントの演算性能との比で再計算を行う。例えば、ある論理機能について、実行環境が物理エレメントＡの演算性能４００ＭＨｚで実行時間ＴＡが１ｍｓであった場合、異なる物理エレメントＢの演算性能８００ＭＨｚに配置した場合には、実行時間ＴＢは下記の通りとなる。

このようにして演算性能の異なる物理エレメントへの配置において論理機能による遅延時間を再計算する。

また別の例では、物理エレメントのプロセッサにおけるベンチマークスコアと、論理機能のタイプ（例えば通常演算、高精度演算、大容量データ演算）により、遅延時間を計算する。これは、演算時間は動作周波数だけでなく、実行する論理機能のタイプや物理エレメント内部の演算装置の構成（例えば物理エレメントのプロセッサにおける高精度演算用のアクセラレータの有無や、データキャッシュの有無など）により演算結果が変動するためである。その場合に使用するベンチマークスコアの例について図１１に示す。ここでは遅延時間計算部１０４が演算する論理機能のタイプごとにベンチマークスコア１１００を有するとする。例えば、ある論理機能について、物理エレメントＡでの実行時間がＴＡであった場合、異なる物理エレメントＢに配置した場合には、実行時間ＴＢは下記の通りとなる。

またネットワークでの遅延時間については、ネットワークの演算性能に対し、論理機能の通信量がビットレートを定義しているため、ネットワークでの遅延時間ＴＮは下記の通り計算できる。

＜制御成立性判定＞
次に制御成立性判定部１０５で実施される制御成立性の判定方法について説明する。制御成立性は、性能換算を行った論理機能の実行時間（遅延時間）について、まずは全体の時間制約を論理機能ごとの遅延時間で合算したものを満たすかを判定し、その後各物理エレメントに配置された論理機能について、占有率が基準値以下であるかを、物理エレメント内で判定する。

全体での制御成立性を満たすか否かの判定は下記の通りとなる。

ここでＭＡＸは括弧内での最大の値を返す関数を示している。ここで演算装置における演算を、演算装置内の論理機能の制御周期の最大値の２倍としている理由は、例えば制御周期が１０ｍｓと２０ｍｓの論理機能があり、それぞれが外部から入力を受けて演算を行い、出力を行う場合、最悪のケースでは、２０ｍｓの論理機能が開始された直後にデータの入力を受け、次の開始時間に前記入力されたデータを基に演算を行うまでに２０ｍｓの周期の２倍かかるためである。１０ｍｓの論理機能については、下記占有率の計算が基準値以下の場合にはその周期の間に処理を行うものと考える。

また、ネットワークの遅延時間は、下記計算式により計算する。

上記はネットワークでの衝突等を考慮しない効率的な演算の場合の計算式である。ネットワークにおいて、ネットワークに複数のデータが流れる場合のネットワークの遅延時間として、ネットワークでのスケジューラビリティも考慮したネットワーク遅延時間の計算式は以下になる。

ここでネットワークの他論理機能の通信量については、演算を行う論理機能に対し、優先度の高い論理機能の通信量のみを加算すれば良い。例えば主機能については、（より優先度の高い）安全機能のみを加算する等により、安全性の確保が容易に、かつ簡易な演算が可能となる。

次に物理エレメント内での占有率を計算する。計算式は下記の通りとなる。

ここで占有率が１または下記基準値を超えている場合にはシステムとして論理機能が十分に実行できないため、ＮＧとして判定する。
占有率が１以下の場合には、例えばシステム設計での基準値（例えば０．８以下）や、レイトモノトニックスケジューリングの計算式による基準値等を予め定めておき、それ以下であればＯＫと判定する。

これら判定の結果、全ての物理エレメントについて占有率が基準値以下であると判定した場合には、上記時間要件を満たしているとして判定を行う。

ここでは全体での制御成立性を計算してから個別の物理エレメントでの占有率を判定する順序を説明したが、個別の物理エレメントでの成立性を先に判定しても良い。そのようにすることにより、個別の物理エレメントでの占有率が厳しいと想定される設計の場合の評価では早く判定結果が得られることになる。

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

アーキテクチャ評価結果、特に制御成立性の評価結果の例について図１２に示す。ここでは例として、論理アーキテクチャの物理アーキテクチャへの配置例と、時間要件テーブル１０００を画面等に出力する例について示しており、ここでは論理機能６０２および６０３が配置された物理エレメントにおいて占有率が基準値を超えており、その結果時間制約が満たされていない例を示している。この例ではそれぞれ満たされていない時間要件と、その配置されている論理機能が強調される例を示している。このようにすることにより、制御成立性を満たしていないアーキテクチャの要素とその要因を確認可能になる。

このようにすることにより、制御成立性を判定しながらアーキテクチャの評価を行うことが可能になる。特に、全ての組合せによるスケジューリング可能性を判断することなく、システム内での想定遅延時間の加算と、物理エレメント内でのスケジューリング性の簡易的な評価により制御成立性を効率的に評価し、制御成立性を満たすアーキテクチャを選択して評価することが可能となる。

次に安全関連機能に関する制御成立性を優先して判定する実施例について説明する。第１の実施例と異なる点は、制御成立性判定部１０５において、安全関連機能を優先的に判定する点である。具体的には、図１０に記載した時間要件の例において、安全関連機能としているＩＤ２，ＩＤ３を先に判定し、主機能であるＩＤ１より優先的に制約時間の判定を行う。このようにすることにより、例えば安全機能の時間要件を満たさないアーキテクチャについてはその時点で判定を終了することにより、主機能の時間判定を優先的に行う場合に比べ、判定時間の削減を行うことが可能になる。

また、物理エレメント内での制御成立性の判定についても、安全機能を優先的に判定する。ここで優先的とは、安全関連機能の実行時間については悲観的な実行時間を用い、主機能の実行時間については楽観的な実行時間を用いた場合でも、占有率が基準値を超えていないことを計算するものである。その場合の計算式については下記の通りとなる。

ここで一般的に、機能Ａの楽観的実行時間より機能Ａの悲観的実行時間の方が長い。このようにして判定した場合の占有率が許容値以下であることを確認することにより、全部を悲観的に評価した場合に比べてＯＫとなるパターンが増加し、かつ安全機能の実行については悲観的に見ても実行に失敗することが無いことが確認可能となる。

ここで判定を行う論理機能が安全機能か否かは、論理アーキテクチャパラメータの論理機能のタイプを使用する以外に、安全分析結果９００等から入力される安全要件、または安全検証部１０２から出力される安全要件として前記論理機能が用いられているかを判定しても良い。このようにすることにより、論理アーキテクチャパラメータの論理機能のタイプとして安全機能として付与されていた場合でも、安全分析の結果、安全機能として使用されていない機能については安全機能として判定せず、より安全分析結果に基づいた判定を行うことが可能となる。

次に、アーキテクチャ評価結果として、アーキテクチャの改善を行いやすくするための情報を出力する実施例について説明する。

まずは制御周期の改善提案の例について説明する。各演算装置において占有率が１または基準値を超えている場合、いずれかの論理機能の制御周期を増加させて占有率が１または基準値を超え無くなると、制御成立性を満たす可能性がある。そのため、必要な論理機能について制御周期を長くする提案をシステムとして出力を行うことにより、アーキテクチャの改善が行いやすくなる。

この場合、制御周期を長くすることにより、上記の時間要件を満たさなくなる場合は、妥当な改善とはならない。そのため、全ての時間要件を満たしながら制御周期を長くすることが可能か否かを判定する必要があり、制御周期の見直し後、制御成立性１０５での判定がＯＫの内容のみ評価結果として出力する。出力例を図１３に示す。ここでは該当するアーキテクチャの評価結果について、論理機能６０２の制御周期を１０ｍｓから２０ｍｓに変更することにより、占有率を基準値以下にでき、また時間要件を満たしていることを示している。

この場合の占有率の計算は、式（３）による占有率、または式（４）の安全機能優先占有率の双方が使用可能である。特に安全機能優先占有率で計算することにより、演算時間が少なく、かつ安全機能が悲観値でも実行されることを判定することが可能となる。
また、論理機能の移行による改善提案の例について次に説明する。同様に演算装置における占有率が１または基準値を超える場合には、該演算装置から一部の論理機能を異なる演算装置に移動することにより、占有率が１または基準値を超えないことが可能となる。この場合の移行先の候補については、下記の計算式で導出される。

上記式を満たす演算装置に対して論理機能の移行を試行し、再度制御成立性判定部１０５によりを判定した結果ＯＫであった場合に、前記移行を改善提案として出力する。図１３では同様に、論理機能６０３を異なるＥＣＵに配置する改善提案の例について示している。

次に、前記車両制御システム検証を、車両制御システム内で実施する例について説明する。本実施例における車両制御システムの構成について図１４に示す。図１に示す車両制御システム検証装置１００をＥＣＵ３０２に配置し、前記検証を車両制御システム内にて実施する。

本実施例において、車両制御システム検証装置１００はアーキテクチャ情報を、ネットワーク３０１を通じて収集する。車両制御システム検証装置１００が受信するアーキテクチャ構成情報の例を図１５に示す。

図１５Ａは物理アーキテクチャ構成情報を示しており、各物理エレメント名（ＥＣＵ、マイコン）と接続しているネットワーク名、および図５で示す物理エレメントの各種パラメータが情報として入力される。これらは複数のＥＣＵが所有している情報について適宜送信され、車両制御システム検証装置１００が情報を収集し、物理アーキテクチャ情報を構築する。

図１５Ｂは論理アーキテクチャ構成情報を示しており、各論理機能名（ＩＤ）、配置されている物理エレメント名（配置場所）、図７に記載の論理アーキテクチャのパラメータ、が情報として入力される。これらも同様に複数のＥＣＵが所有している情報について適宜送信され、車両制御システム検証装置１００が情報を収集し、論理アーキテクチャ情報を構築する。

これら情報を収集し、前記車両制御システム検証を実施し、ネットワーク等に検証結果を出力する。これにより、車両制御システムの状態について常に検証を実施することが可能となる。

ネットワークで取得する物理アーキテクチャ構成情報、論理アーキテクチャ構成情報、については、全ての情報を受信する必要は無く、差分だけを受信し、前記車両制御システム検証装置１００が差分の更新のみを行い判定をしても良い。そのようにすることにより、通信量を削減することが可能となる。

以上説明した実施例によれば、各論理機能の連携と、該連携の実行時間制約を含む論理アーキテクチャを物理アーキテクチャに配置する配置部と、前記論理アーキテクチャが前記物理アーキテクチャに配置された場合に変換されたパラメータに基づいて処理遅延時間を演算する遅延時間計算部と、前記処理遅延時間の総和が前記実行時間制約を充足するかを検証する検証部と、を含む。

また、前記検証部は、各前記物理アーキテクチャに配置された前記論理アーキテクチャのエレメントの処理遅延時間の総和が、前記論理アーキテクチャのエレメントに付与された制御周期より小さいまたは等しいことを判定し、前記実行時間制約を充足するかを検証する。

また、前記検証について、安全機能の制御成立性の判定を優先的に実施する。

また、前記制御成立性の判定は、安全機能の実行時間に悲観的な実行時間を用いるか、または主機能の実行時間に楽観的な実行時間を用いる。

また、外部から受信したアーキテクチャの情報に基づき前記検証装置で前記アーキテクチャの検証を行い、検証結果を外部に送信する。

以上説明した実施例によれば、物理アーキテクチャに論理アーキテクチャが配置された場合の制御成立性について、配置された物理アーキテクチャの情報と論理アーキテクチャに付与された情報に基づき制御成立性の判定を効率的に行うことが可能となる。

また別の実施例では、安全関連の機能についての制御成立性の判定について、安全機能を優先的に判定することにより効率的な判定を行うことができ、かつ安全機能の所要時間を悲観的に、主機能の所要時間を楽観的に見積もることにより、安全機能の実行について悲観的な実行時間での実施を保証しかつ主機能は楽観的な性能見積もりにより選択肢を広げる判定を行うことが可能となる。

また別の実施例では、前記制御成立性の判定結果に基づきアーキテクチャの改善または最適化に向けた提案を行うことが可能となる。

さらに別の実施例によれば、これら判定を車両制御システム内で実施することにより、変更となるアーキテクチャ構成情報と制御成立性に基づいた検証を車両制御システム内で実施することが可能となる。

１ 車両システム
２ 車両制御システム
３ 通信装置
４ 車両制御システム
５ 駆動装置
６ 認識装置
７ 出力装置
８ 入力装置
９ 通知装置
１００ 車両制御システム検証装置
１０１ 機能配置部（配置部）
１０２ 安全性検証部（検証部）
１０３ アーキテクチャ定量評価部
１０４ 遅延時間計算部
１０５ 制御成立性判定部
３００ 物理アーキテクチャ
３０１ ネットワークリンク
３０２ ＥＣＵ
４０１ プロセッサ
４０２ Ｉ／Ｏ
４０３ タイマ
４０４ ＲＯＭ
４０５ ＲＡＭ
４０６ 内部バス
６０１ 論理アーキテクチャ
６０２ 統合認識部
６０３ 自動運転制御部
６０４ ユーザ入力部
６０５ 出力管理部
６０６ 通知管理部
６０７ 異常検出部
６０８ 切替部
６０９ 運動制御部
６１０ 安全制御部
１０００ 時間要件テーブル
１１００ ベンチマークスコア

Claims (4)

1. 各論理機能の連携と、該連携の実行時間制約を含む論理アーキテクチャを物理アーキテクチャに配置する配置部と、
   前記論理アーキテクチャが前記物理アーキテクチャに配置された場合に変換されたパラメータに基づいて処理遅延時間を演算する遅延時間計算部と、
   前記処理遅延時間の総和が前記実行時間制約を充足するかを検証する検証部と、
   を含み、
   前記検証について、安全機能の制御成立性の判定を優先的に実施することを特徴とする検証装置。
2. 請求項１に記載の検証装置において、
   前記検証部は、各前記物理アーキテクチャに配置された前記論理アーキテクチャのエレメントの処理遅延時間の総和が、前記論理アーキテクチャのエレメントに付与された制御周期より小さいまたは等しいことを判定し、前記実行時間制約を充足するかを検証することを特徴とする検証装置。
3. 請求項１または２に記載の検証装置を備えた制御装置であって、
   前記制御成立性の判定は、安全機能の実行時間に悲観的な実行時間を用いるか、または主機能の実行時間に楽観的な実行時間を用いることを特徴とする制御装置。
4. 請求項２または３に記載の検証装置を備えた制御装置であって、
   外部から受信したアーキテクチャの情報に基づき前記検証装置で前記アーキテクチャの検証を行い、検証結果を外部に送信することを特徴とする制御装置。

Images