JP6864992B2 - 車両制御システム検証装置及び車両制御システム - Google Patents

Description

本開示は、車両制御システム検証装置、車両制御システム、及び車両制御システム検証方法に関する。

近年、自動車の電子制御は急速に複雑化してきており、その対応が緊急課題であり、より信頼性のある車両制御システムが望まれている。このような車両制御システムを実現するためには、車両制御システムで実装される各機能の信頼性を検査できるようにすることが望ましい。

例えば、特許文献１は、要求されるシステムの機能を検査するための信頼性機能を用いて、そのために必要とされる、システムのハードウェアコンポーネントに基づいて、ソフトウェアベースの電子システムの安全性と信頼性を検査することを開示している。また、特許文献２は、安全性重視システムの設計とベリファイのための改良された方法について開示している。特許文献１或いは２によれば、安全性や信頼性に関連する要件に対し、アーキテクチャの設計、インプリメンテーションの内容を検査・検証することができる。

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

しかしながら、特許文献１及び２には、安全分析結果（安全分析情報ともいう）から網羅的に安全機能の要件を検証することや、信頼性における多重度（多重度については特許文献１に記載されている）以外に安全機能同士の関係性を検証することについては開示されていない。従って、特許文献１及び２に開示の技術では、車両制御システムの各機能を検証する上で十分ではない。
本開示はこのような状況に鑑みてなされたものであり、安全分析結果に基づき、機能の設計の安全性を網羅的に検証するための技術を提供するものである。

上記課題を解決するために、本開示の一実施の態様として、例えば特許請求の範囲に記載されている技術的思想を用いればよい。具体的には、本開示による車両制御システム検証装置は、車両制御システムの論理アーキテクチャの安全性を検証するためのプログラムを格納する記憶デバイスと、記憶デバイスからプログラムを読み込み、論理アーキテクチャの安全性を検証するプロセッサと、を備える。当該プロセッサは、与えられる安全分析結果の情報に基づいて、論理アーキテクチャが安全分析結果に対応する論理機能を有するか否かを検証する処理を実行する。

本開示に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本開示の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。
本明細書の記述は典型的な例示に過ぎず、本開示の特許請求の範囲又は適用例を如何なる意味に於いても限定するものではないことを理解する必要がある。

本開示によれば、自動運転システムの論理アーキテクチャおよび物理アーキテクチャと機能配置情報に基づく設計について、安全分析情報に基づき網羅的に検証を行うことが可能となる。

本開示の実施形態による車両制御システム検証装置１００の概略構成を示す図である。 評価対象の車両制御システムを備える車両システム１の概略構成例を示す図である。 車両制御システム２の物理アーキテクチャの例を示す図である。 ＥＣＵ３０２の内部構成例を示す図である。 物理アーキテクチャ２０のパラメータ例を示す図である。 車両制御システム（例えば、第１の車両制御システム２）の論理アーキテクチャ６０１の構成例を示す図である。 論理アーキテクチャ６０１のパラメータ例を示す図である。 論理アーキテクチャが物理アーキテクチャに配置された場合の構成例を示す図である。 安全分析情報として用いることができるＦＴＡ（Fault Tree Analysis）の例を示す図である。 ＦＴＡの各イベントおよび各ゲートに付与するパラメータの例を示す図である。 第１の実施形態による安全性検証処理の概要を説明するためのフローチャートである。 安全要件検証処理（ステップ１１０２）の詳細を説明するためのフローチャートである。 第２の実施形態による安全性定量評価処理の概要を示す図である。 第２の実施形態による安全性定量評価処理の詳細を説明するためのフローチャートである。 第３の実施形態による安全性検証処理の概要を説明するためのフローチャートである。 安全機能連携検証処理（ステップ１５０１）の詳細を説明するためのフローチャートである。 安全制御モデルの例を示す図である。 安全機能の連携に関する配置先と経路の安全要件のチェック例を示す図である。 第４の実施形態による車両制御システムの構成（物理アーキテクチャ）例を示す図である。 第４の実施形態において車両制御システム検証装置１００が受信するアーキテクチャ構成情報の例を示す図である。

本開示の実施形態による車両制御システム検証装置は、与えられる安全分析結果に基づいて、機能の設計の安全性及び配置の適切さを網羅的に検証し、必要な要件を充足しているか否か、安全機能間の連携の有無について検証するものである。具体的には、本開示による車両制御システム検証装置は、与えられる安全分析結果（ＦＴＡ）の情報に基づいて、車両制御システムの論理アーキテクチャが安全分析結果に対応する論理機能を有するか否かを検証する。なお、論理アーキテクチャは、安全分析結果の情報に基づいて構築しても良い。設計時の安全機能の検証は、ＦＴＡの安全性の要件を満足するようにアーキテクチャを設計し、それが実際にターゲットとなるＦＴＡの安全性の要件を満足するか否かチェックするものだからである。

また、車両制御システム検証装置は、車両制御システムの物理アーキテクチャが論理アーキテクチャで要求される安全度及び多重度を満足するか否かを検証する。

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

（１）第１の実施形態
第１の実施形態は、車両制御システムの論理アーキテクチャにおいてＦＴＡで必要とされる安全機能が存在するか、及び車両制御システムの物理アーキテクチャ上に論理アーキテクチャを配置したときに物理アーキテクチャが要求される安全度と多重度を満足するかについて検証することについて開示する。

＜車両制御システム検証装置＞
図１は、本開示の実施形態による車両制御システム検証装置１００の概略構成を示す図である。
車両制御システム検証装置１００は、機能配置部１０１と、安全性検証部１０２と、アーキテクチャ定量評価部１０３と、を備える。

機能配置部１０１は、例えば、論理アーキテクチャ６０１と物理アーキテクチャ２０とを入力とし、機能配置の例（図８参照）のように論理アーキテクチャ６０１を物理アーキテクチャ２０上に配置する処理を実行する。

安全性検証部１０２は、機能配置後のアーキテクチャと安全分析情報（例えばＦＴＡ：Fault Tree Analysis（図９参照））９００を入力とし、本開示で提案される安全性検証のフローに従って設計されたアーキテクチャの安全性の検証を行う。そして、安全性検証部１０２は、検証結果として、安全性検証ＯＫ、或いは安全性検証ＮＧ及びその理由を機能配置部１０１に出力する。なお、検証結果は、アーキテクチャ定量評価部１０３に直接出力されるようにしても良い。

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

なお、車両制御システム検証装置１００は、プロセッサ（ＣＰＵなど）やメモリ（ＲＯＭやＲＡＭなど）などを有するコンピュータによって実現することができる。この場合、機能配置部１０１、安全性検証部１０２、及びアーキテクチャ定量評価部１０３はプログラムによって構成され、プロセッサがプログラムメモリ（ＲＯＭ）から各種プログラムを読み込み、実行するように構成される。
論理アーキテクチャ６０１、物理アーキテクチャ２０、機能配置部１０１、及び安全性検証部１０２の詳細については後述する。

＜車両制御システムの構成＞
図２は、評価対象の車両制御システムを備える車両システム１の概略構成例を示す図である。車両システム１は、自動車などが該当し、内部に車両制御システムを有している。

車両システム１は、例えば、第１の車両制御システム２と、少なくとも１つの通信装置３と、第２の車両制御システム４と、少なくとも１つの駆動装置５と、少なくとも１つの認識装置６と、出力装置７と、入力装置８と、通知装置９と、を備えている。ここでは、例として２つの車両制御システム（第１の車両制御システム２及び第２の車両制御システム４）を挙げたが、２つに限られるものではない。また、複数の車両制御システムが連携して動作するような構成を採用しても良い。

第１の車両制御システム２は、例えば車載ネットワーク（ＣＡＮ：Controller Area Network、ＣＡＮＦＤ：CAN with Flexible Data-rate、Ethernet（登録商標）等）とコントローラ（ＥＣＵ：Electronic Control Unit等）により構成される。第１の車両制御システム２は、第２の車両制御システム４、通信装置３、駆動装置５、認識装置６、出力装置７、入力装置８、及び通知装置９などと接続され、それぞれとの間で情報の送受信を行うように構成されている。

通信装置３は、車両システム１の外部と無線通信（例えば、携帯電話の通信、無線ＬＡＮ、ＷＡＮ、Ｃ２Ｘ（Car to X：車両対車両または車両対インフラ通信）等のプロトコルを使用した通信、またはＧＰＳ（Global Positioning System）を用いた通信）を行い、外界（例えば、インフラ、他車、地図など）の情報または自車に関する情報（例えば、自車の状態を示す情報）を取得・送信などの無線通信を実施、または診断端子（ＯＢＤ）やEthernet（登録商標）端子、外部記録媒体（例えばＵＳＢメモリ、ＳＤカード、等）端子などを有し、第１の車両制御システム２と通信を実施するものである。

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

駆動装置５は、第１の車両制御システム２の制御に従い、車両運動を制御する機械および電気装置（例えばエンジン、トランスミッション、ホイール、ブレーキ、操舵装置等）の駆動を行うものであり、例えばアクチュエータ等が該当する。

認識装置６は、外界から入力される情報を取得し情報を生成するための情報を出力する、カメラ、レーダ、ＬＩＤＡＲ、超音波センサなどの外界センサ、および、車両システム１の状態（運動状態、位置情報、加速度、車輪速度等）を認識する力学系センサにより構成される。

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

入力装置８は、ユーザが第１の車両制御システム２に対して、操作の意図や指示を入力する入力信号を生成するための装置であり、例えばステアリング、ペダル、ボタン、レバー、タッチパネル等が該当する。
通知装置９は、車両システム１が外界に対して、車両の状態等を通知するための装置であり、例えば、ランプ、ＬＥＤ、スピーカ等が該当する。

＜物理アーキテクチャの例＞
図３は、車両制御システム２の物理アーキテクチャの例を示す図である。物理アーキテクチャ２０はＨ／Ｗ（Hardware）構成と呼ぶこともできる。

物理アーキテクチャ２０は、例えば、ネットワークリンク３０１と、ＥＣＵ（Electronic Control Unit：電子制御ユニット）３０２と、によって構成される。

ネットワークリンク３０１は、車載ネットワーク上のネットワーク装置を接続するためのネットワークリンクであり、例えばＣＡＮバスなどのネットワークリンクが該当する。

ＥＣＵ３０２は、ネットワークリンク３０１および駆動装置５や認識装置６や３０１以外のネットワークリンク（専用線含む）に接続され、駆動装置５や認識装置６の制御および情報取得、ネットワークとのデータ送受信を行う。ＥＣＵ３０２は、複数のネットワークリンク３０１と接続され、それぞれのネットワークリンクとデータの送受信を行うゲートウェイ（以下ＧＷ）の役割をも担っている。

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

＜ＥＣＵの内部構成例＞
図４は、ＥＣＵ３０２の内部構成例を示す図である。ＥＣＵ３０２は、内部構成として、例えば、プロセッサ４０１と、Ｉ／Ｏ（Input/Output）デバイス４０２と、タイマ４０３と、ＲＯＭ（Read Only Memory）４０４と、ＲＡＭ（Random Access Memory）４０５と、内部バス４０６と、を備える。

プロセッサ４０１は、キャッシュやレジスタなどの記憶素子を持ち、制御を実行するものであり、例えばＣＰＵなどで構成される。プロセッサ４０１は、後述する論理機能を実行する。

Ｉ／Ｏデバイス４０２は、ネットワークリンク３０１またはネットワークや専用線で接続された駆動装置５または／および認識装置６に対してデータの送受信を行う。Ｉ／Ｏデバイス４０２は、例えば、通信Ｉ／Ｆ（Interface）デバイスで構成することができる。
タイマ４０３は、図示しないクロックなどを使用し、時間および時刻の管理を行う。

ＲＯＭ４０４は、プログラムおよび不揮発性のデータを保存する。ＲＡＭ４０５は、プログラムおよび揮発性のデータを保存する。内部バス４０６は、ＥＣＵ３０２内部での通信に用いられるバスである。

＜物理アーキテクチャのパラメータ＞
図５は、物理アーキテクチャ２０のパラメータ例を示す図である。図５Ａは、物理アーキテクチャ２０の物理エレメント（ＥＣＵやプロセッサ）に付与されるパラメータを示している。図５Ｂは、ネットワークに付与されるパラメータを示している。

（i）物理エレメントのパラメータ
図５Ａに示されるように、物理エレメントのパラメータは、演算性能と、ＲＡＭ量と、ＲＯＭ量と、対応安全度と、コストと、多重度と、故障率と、診断率と、物理依存性と、を含む。これらのパラメータのうち、演算性能（ＭＨｚ：プロセッサの性能）、ＲＡＭ量（ＫＢ：容量）、ＲＯＭ量（ＫＢ：容量）、及びコスト（ｙｅｎ：ＥＣＵやプロセッサの価格）は、ＥＣＵまたはプロセッサの持つパラメータを有するアーキテクチャを定量評価する際に使用される。

対応安全度は、安全性関連のパラメータであり、ハードウェア（ＥＣＵ）として対応可能な安全レベルを示す情報である。対応安全度はＩＳＯ２６２６２で規定されており、例えばＡＳＩＬ（Automotive Safety Integrity Level）やＱＭ（Quality Management）などが該当する。

多重度は、ＥＣＵが有する系統数を示す情報である。例えば、ＥＣＵが２重系統を有し、１系統の故障に対応可能な場合には多重度は２（多重度の数）とされる。

故障率は、物理エレメント（ＥＣＵやプロセッサ）が動作させ続けたときに故障が一回発生する時間（Failure in time）を示す情報であり、安全検証に使用される。

診断率は、物理エレメントで有する機能（例えばマイコン診断など）の診断のカバレッジを示している。これは、例えば、診断率が９９％であれば、９９％の故障には対応できるが残り１％には対応できないことを示している。どの故障に対応できないかは設計時に分かっていることもある。

物理依存性は、該当する物理エレメントがどのハードウェアに依存しているか（例えば、ＥＣＵが別のＥＣＵと同じ電源につながっている場合）を示す情報である。

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

また、ここで、故障率及び診断率は、全ての故障モードに対して同じパラメータの例を記載しているが、各エレメントの故障モードごとに異なるパラメータとしても良い。このようにすることにより、故障モードに応じた故障率・診断率による検証および評価が可能になり、より詳細な定量評価、検証が可能となる。

（ii）ネットワークのパラメータ
図５Ｂに示されるように、ネットワークは、通信速度（ｂｐｓ）、コスト（ｙｅｎ：ネットワークケーブルの価格）、及び多重度（通信線の冗長度）のパラメータを有する。

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

車両制御システムの論理アーキテクチャ６０１は、例えば、統合認識部６０２と、自動運転制御部６０３と、ユーザ入力部６０４と、出力管理部６０５と、通知管理部６０６と、異常検出部６０７と、切替部６０８と、運動制御部６０９と、安全制御部６１０と、を備えている。
統合認識部６０２は、複数の認識装置６、及び通信装置３から送信されてくる外界認識情報を統合した外界認識マップを作成する処理を実行する。

自動運転制御部６０３は、統合認識部６０２により生成された外界認識マップ、及びユーザ入力部６０４から入力されたユーザ入力に基づいて、自動運転制御情報（軌道等）を生成し、異常検出部６０７、及び切替部６０８に出力する。また、自動運転制御部６０３は、出力管理部６０５に出力指示を行い、また、通知管理部６０６に通知指示を行う。出力管理部６０５は、自動運転制御部６０３および異常検出部６０７の出力に応じて出力装置７への出力指示を行う。通知管理部６０６は、自動運転制御部６０３および異常検出部６０７の出力に応じて通知装置９への通知指示を行う。
ユーザ入力部６０４は、入力装置８からの入力に従い、ユーザの指示情報を生成する。

異常検出部６０７は、自動運転制御部６０３からの自動運転制御情報等または図示しない各部からの所定情報に基づいて異常を検出し、異常検出結果を切替部６０８、安全制御部６１０、出力管理部６０５、及び通知管理部６０６に出力する。

切替部６０８は、異常検出部６０７の異常検出結果等により、運動制御部６０９に対する出力を自動運転制御部６０３からの入力、ユーザ入力部６０４からの入力、または安全制御部６１０の入力に切替える。具体的には、異常検出部６０７によって異常が検出されると、自動運転制御部６０３からの通常制御系統（主制御系統ともいう：６０２→６０３→６０８→６０９）から異常時制御系統（安全制御系統ともいう：６０２→６１０→６０８→６０９）に切り替えられる。

運動制御部６０９は、切替部６０８から提供される軌道情報または運動制御情報、認識装置６から取得する車両システム１の状態、及び駆動装置５からの応答に従って、複数の駆動装置５に対して制御を行う。

安全制御部６１０は、異常検出の通知を受けた場合の制御を実施する。安全制御部６１０は、自動運転制御部６０３の縮退機能を有しており、緊急時（異常検出時）に自動運転制御部６０３の機能の一部を代替的に実行できるように構成されている。

図６の例では、通常時に主要な制御を行う機能を主機能と呼び、異常の検出および異常発生後に主要な制御を行う機能を安全機能と呼ぶ。主機能には、統合認識部６０２、自動運転制御部６０３、ユーザ入力部６０４、出力管理部６０５、通知管理部６０６、及び運動制御部６０９が該当する。また、安全機能には、異常検出部６０７、切替部６０８、及び安全制御部６１０が該当する。

＜論理アーキテクチャのパラメータ＞
図７は、論理アーキテクチャ６０１のパラメータ例を示す図である。図７Ａは、主機能に付与されるパラメータを示している。図７Ｂは、安全機能に付与されるパラメータを示している。図７Ｃは、論理接続に対するパラメータを示している。

（i）主機能のパラメータ
主機能のパラメータは、論理機能のタイプと、演算量と、消費ＲＡＭと、消費ＲＯＭとを含む。
論理機能のタイプは、論理機能の種別を示す情報であり、主機能・安全機能の判定に使用される。ここでは「主機能」が入力される。

演算量（ＭＨｚ）は、該当する機能を実行するために必要とされるＥＣＵ或いはプロセッサの性能を示す情報である。消費ＲＡＭ（ＫＢ）は、該当する機能を実行するために必要とされるＲＡＭの消費量を示す情報である。消費ＲＯＭ（ＫＢ）は、該当する機能を実行するために必要とされるＲＯＭの消費量を示す情報である。
演算量、消費ＲＡＭ、及び消費ＲＯＭは、主にアーキテクチャの定量評価を行う際に使用される。

（ii）安全機能のパラメータ
安全機能のパラメータは、論理機能のタイプと、安全機能のタイプと、安全制御モードと、演算量と、消費ＲＡＭと、消費ＲＯＭと、要求安全度と、検出対象と、検出故障モードと、検出率と、独立性要求と、を含む。

論理機能のタイプは、論理機能の種別を示す情報であり、主機能・安全機能の判定に使用される。ここでは「安全機能」が入力される。演算量（ＭＨｚ）は、該当する機能を実行するために必要とされるＥＣＵ或いはプロセッサの性能を示す情報である。消費ＲＡＭ（ＫＢ）は、該当する機能を実行するために必要とされるＲＡＭの消費量を示す情報である。消費ＲＯＭ（ＫＢ）は、該当する機能を実行するために必要とされるＲＯＭの消費量を示す情報である。演算量、消費ＲＡＭ、及び消費ＲＯＭは、主にアーキテクチャの定量評価を実行する際に使用される。当該論理機能のタイプ、演算量、消費ＲＡＭ、及び消費ＲＯＭは、主機能と同様にアーキテクチャの定評評価を行う際に使用される。

安全機能のタイプは、該当する安全機能の種別を示す情報であり、後述する安全機能連携の判断に使用される。例えば、安全機能のタイプは、検出・制御・切替のどの機能に該当するかを示す。

安全制御モードは、該当する安全機能が実現すべき安全制御にどのような内容が要求されているかを示す情報である。例えば、機能停止、機能継続などの情報が付与される。また、安全制御モードには、要求される多重度の情報も含まれる。

要求安全度は、該当する安全機能に要求される安全度を示す情報である。例えば、ＱＭやＡＳＩＬが付与され、該当する安全度での安全機能の実行が物理アーキテクチャ上で要求される。

検出対象は、該当する安全機能がイベント（例えば、異常）を検出すべき対象となる論理機能を示す情報である。例えば、該当する機能が異常検出部６０７であるとき、検出対象は統合認識部６０２及び自動運転制御部６０３となる。

検出故障モードは、複数の故障モード（例えば、故障時は停止、故障時は偽値出力、故障時は遅れて値を出力等）のうち該当する論理機能がどの故障モードに対応するかを示す情報である。

検出率は、物理エレメントの「診断率」と同様、該当する安全機能においてどの程度の故障や誤りを検出することができるかを示す情報である。例えば、検出率９９％である場合、９９％の故障・誤りは検出できるが、残り１％の故障・誤りは検出できないことを意味している。

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

（iii）論理接続のパラメータ
論理接続に対するパラメータは、該当する通信路の通信量を含む。当該通信量は、アーキテクチャを定量評価する際に使用される。

（iv）以上説明したパラメータについては、アーキテクチャ設計時に必須の組み合わせがある。従って、必須のパラメータが付与されていない場合には、アーキテクチャ検証時にＮＧとして判断する必要がある。例えば、安全機能のタイプが「検出」であるにも拘らず、検出対象、検出故障モード、及び検出率等のパラメータが付与されていない場合には安全性検証時にＮＧが出力される。

＜機能配置例＞
図８は、論理アーキテクチャが物理アーキテクチャに配置された場合の構成例を示す図である。

機能配置部１０１は、与えられた論理アーキテクチャ６０１（図６参照）を、与えられた物理アーキテクチャ２０（図３参照）上に配置する。これにより、どの論理機能の処理がどの物理エレメント（ＥＣＵ、マイコン）上で実行され、ネットワークでの通信にどのような内容が実施されるかが決定される。

図８の配置例では、互いに関連性が強い論理機能が同一のＥＣＵに配置される。例えば、主機能である、統合認識部６０２と自動運転制御部６０３、及びユーザ入力部６０４と出力管理部６０５がそれぞれ同一のＥＣＵに配置される。安全機能である異常検出部６０７と安全制御部６１０が同一のＥＣＵに配置される。また、安全機能である切替部６０８と主機能である運動制御部６０９が同一のＥＣＵに配置される。

なお、論理機能間で、ネットワークで複数の経路がある場合には、例えばその中で最小のコスト（通信帯域、ホップ数）となる経路を選択するなどして効率の良い通信を実施することが好ましい。

＜安全分析情報＞
図９は、安全分析情報として用いることができるＦＴＡ（Fault Tree Analysis）の例を示す図である。ＦＴＡ９００は、ツリー状の構造を表しており、トップイベント（トップ事象）９０１と、それぞれの葉となるイベント９０３と、分岐のゲート９０２と、を含んでいる。

トップイベント（ツリーの最上部の事象）は、ハザードイベント（危険な事象）とされ、ＡＮＤやＯＲのゲートで下位の事象と連結され、トップイベントの発生原因となる下位イベントに分解される。ＯＲのゲートは、どちらかの事象が発生した場合に上位の事象が発生することを意味し、ＡＮＤのゲートは両方の事象が発生した場合にのみ上位の事象が発生することを意味する。このようにして最上位のハザードを発生させるイベントの関係性を明確化することができる。

＜イベント及びゲートのパラメータ＞
図１０は、各イベントおよび各ゲートに付与するパラメータの例を示す図である。図１０Ａは、各イベントに付与するパラメータを示している。図１０Ｂは、各ゲートに付与するパラメータを示している。

（i）イベントのパラメータ
イベントのパラメータは、該当するイベントの上位に位置するイベント（上位イベント）又はゲート（上位ゲート）と、イベント種別（中間イベントか基本イベントか）と、故障機能と、故障モードと、を構成項目として有している。故障機能と故障モードの組み合わせでイベントの内容が表わされている。故障機能と故障モードについては、基本事象だけでなく、中間事象にも記載する。そのようにすることにより、例えばコンポーネントの故障だけでなくシステムレベルでの故障についても記載可能である。

なお、故障機能に関しては、論理機能の内容を示すテーブル（図示せず）が別途用意されており、当該テーブルを参照することにより各論理機能の内容を把握することができるようになっている。

（ii）ゲートのパラメータ
ゲートのパラメータは、各ゲートの上位に位置するイベントまたはゲートと、ゲートの種別（ＯＲまたはＡＮＤ）と、を構成項目として有している。

（iii）以上のパラメータにより、いずれかのイベント（論理機能の故障）が発生した場合に、どのような条件でハザードが発生するかを表現することが可能になる。

＜安全性検証処理＞
図１１は、第１の実施形態による安全性検証処理の概要を説明するためのフローチャートである。以下では、プログラムとしての安全性検証部１０２を動作主体として処理概要について説明するが、プログラムは車両制御システム検証装置１００のプロセッサによって読み込まれ、実行されるものであるので、安全性検証部１０２を「プロセッサ」と読み替えることも可能である。

（i）ステップ１１０１
安全性検証部１０２は、まず、機能配置後のアーキテクチャについて安全要件検証処理を実行する。安全要件検証処理の詳細については後述する（図１２参照）。

（ii）ステップ１１０２
安全性検証部１０２は、安全要件の検証結果がＯＫの場合には（Ｓ１１０２でｙｅｓ）、処理をステップ１１０３に移行させ、安全要件の検証結果がＮＧの場合には（Ｓ１１０２でｎｏ）、処理をステップ１１０４に移行させる。

（iii）ステップ１１０３
安全性検証部１０２は、安全性検証結果としてＯＫを出力して処理を終了する。

（iv）ステップ１１０４
安全性検証部１０２は、ＮＧ結果とその理由、及び何れの安全要件の検証がＮＧであったかを出力する。このようにして安全要件の検証が実施される。

＜安全要件検証処理＞
図１２は、安全要件検証処理（ステップ１１０２）の詳細を説明するためのフローチャートである。

（i）ステップ１２０１
安全要件検証処理において、安全性検証部１０２は、安全分析情報９００の全てのイベントについてステップ１２０２〜ステップ１２０５の処理を繰り返す。

（ii）ステップ１２０２
安全性検証部１０２は、それぞれのイベントについて、対応する安全機能がアーキテクチャ上に存在しているかを確認する。具体的には、該当する（処理対象の）イベント（例えば、ＥＴ３）の故障機能（例えば、図１０の論理機能１）のパラメータが、対応する安全機能における検出故障モードと検出対象に存在するかチェックされる。対応する安全機能がある場合（ステップ１２０２でｙｅｓの場合）、処理はステップ１２０３に移行する。対応する安全機能がない場合（ステップ１２０２でｎｏの場合）、処理はステップ１２０５に移行する。

（iii）ステップ１２０３
安全性検証部１０２は、物理アーキテクチャ２０における、該当する安全機能の配置先において、安全度及び多重度の要件を満たしているか判定する。

安全度の場合には、該当する安全機能のパラメータである要求安全度の値が、配置先の物理エレメントの対応安全度より小さいか、または等しい場合にはＯＫと判定される。具体的には、安全機能の要求安全度がＡＳＩＬ−Ｃの場合、配置先の物理エレメントの対応安全度がＡＳＩＬ−Ｃかそれ以上（ＡＳＩＬ−Ｄ等）の場合にＯＫと判定される。

多重度の場合には、該当する安全機能のパラメータである安全制御モードに含まれる要求多重度の値が、配置先の物理エレメントの多重度より小さいまたは等しい場合にはＯＫと判定される。具体的には、安全機能の要求多重度が２の場合、配置先の物理エレメントの多重度が２以上の場合にＯＫと判定される。

配置先の安全度及び多重度がＯＫの場合（ステップ１２０３でｙｅｓの場合）、処理はステップ１２０４に移行する。配置先の安全度及び多重度がＮＧの場合（ステップ１２０３でｎｏの場合）、処理はステップ１２０５に移行する。

（iv）ステップ１２０４
安全性検証部１０２は、該当するイベントの内容をＯＫとする。

（v）ステップ１２０５
安全性検証部１０２は、該当するイベントの内容をＮＧとする。

（vi）ステップ１２０６
安全性検証部１０２は、次のイベントについて処理を行う。全てのイベントについて処理が完了した後、処理はステップ１２０７に移行する。

（vii）ステップ１２０７
安全性検証部１０２は、ステップ１２０１〜ステップ１２０６の処理結果をＦＴＡのツリーに適用して安全要件検証の判定を行う。具体的には、安全性検証部１０２は、ＦＴＡの各イベントについて、上記各イベントのＯＫ及びＮＧの結果をＦＴＡに入力し、ＦＴＡのツリーに従って判定を行う。つまり、各イベントから上部にＯＫ、ＮＧを辿り、各ゲートでの判定をＡＮＤ、ＯＲとして判定し、最上位のイベントが発生するかを判定する。ここでは、安全性検証部１０２は、ＮＧをＴ（Ｔｒｕｅ）、ＯＫをＦ（Ｆａｌｓｅ）とし、ＡＮＤ条件及びＯＲ条件で判定を行い、トップイベント（トップ事象）がＦａｌｓｅの場合にはＯＫを返し、Ｔｒｕｅの場合にはＮＧを返す。このようにして全体での安全要件の検証が行われる。

なお、ＮＧの場合には、記録されたＮＧイベントの全てを返すようにする。これにより、車両制御システム検証装置１００は、ユーザに対して不備のあった安全要件を提示することが可能になる。

（viii）変形例
ステップ１２０３においては、配置先の検証処理では安全度の判定だけを実施しても良い。多重度は別途安全機能連携の検証でも実施するため、ステップ１２０３では省略可能である。これにより、演算量の削減が可能となる。

また、ステップ１２０７においては、ＦＴＡツリーでの判定を行わず、いずれかのイベントでＮＧがあった場合に、その結果を基に安全要件検証をＮＧと判定し、安全要件検証処理を終了しても良い。全ての安全要件には安全機能が対応すべきとして判定することにより、ＦＴＡツリーの演算を行わず、処理時間を短縮することが可能となる。

＜アーキテクチャ定量評価＞
アーキテクチャ定量評価部１０３は、機能配置済みのアーキテクチャで安全性検証結果がＯＫと判定されたアーキテクチャの定量評価を行う。定量評価は、例えば、物理エレメント上の論理機能の使用率の算出、通信の占有率の算出、及び物理エレメントのコストの算出することにより実現することができる。物理エレメント上の論理機能の使用率は、物理アーキテクチャ２０の物理エレメントに配置された複数の論理機能について、演算量、消費ＲＡＭ、及び消費ＲＯＭのそれぞれについて合計値を算出し、物理エレメント上での使用率を計算することにより算出することができる。また、通信の占有率は、ネットワーク上の各論理機能による通信の使用量を合計し、占有率を計算することにより算出することができる。さらに、物理エレメントのコストは、物理アーキテクチャ全体で使用している物理エレメント、つまり論理機能が１つ以上配置されている物理エレメントについてのコストを合計することにより算出することができる。

これらの計算により、安全性が検証されたアーキテクチャの定量評価が可能となる。なお、安全性が検証済みのアーキテクチャのみを定量評価するようにしても良い。これにより、安全性を満たさない不要なアーキテクチャ評価時間を削減することが可能となる。

（２）第２の実施形態
第２の実施形態は、安全性の定量的評価に基づく検証および評価の別形態について開示する。具体的には、第１の実施形態における安全要件検証（ステップ１１０１）、または上述のアーキテクチャ定量評価で実行される、別形態の処理（安全性定量評価処理：トップイベント発生確率算出処理と呼ぶことも可能）について説明する。

＜安全性定量評価処理（トップイベント発生確率算出処理）の概要＞
図１３は、第２の実施形態による安全性定量評価処理の概要を示す図である。当該処理は、トップイベントが発生する確率を算出処理に相当する。

ＦＴＡを構成する複数のイベントのうち１つを選択し、当該イベントに対応する論理機能の検出対象（図７参照）とイベントに対応する論理機能の故障機能及び故障モード（図１０参照）とから、主機能及び安全機能が特定される。
特定された主機能に対応する物理エレメントの故障率（図５参照）、及び主機能の故障を検出する安全機能の検出率（図７参照）が取得される。
次に、取得された故障率及び検出率から残存故障率（検出できない故障の割合）が算出される。
そして、ツリーの条件に合わせて各イベントの残存故障率を積算し、トップイベントの発生確率が算出される。

＜安全性定量評価処理（トップイベント発生確率算出処理）の詳細＞
図１４は、第２の実施形態による安全性定量評価処理の詳細を説明するためのフローチャートである。アーキテクチャ定量評価部１０３は、以下の手順に従って、該当するハザード（トップイベント）の発生確率（残存故障率）を計算する。ここでは、プログラムとしてのアーキテクチャ定量評価部１０３を動作主体として処理内容を説明するが、プログラムは車両制御システム検証装置１００のプロセッサによって読み込まれ、実行されるものであるので、アーキテクチャ定量評価部１０３を「プロセッサ」と読み替えることも可能である。

（i）ステップ１４０１及び１４０６
アーキテクチャ定量評価部１０３は、安全分析情報（ＦＴＡ）の全てのイベントについてステップ１４０２〜ステップ１４０５の処理を繰り返す。

（ii）ステップ１４０２
アーキテクチャ定量評価部１０３は、処理対象のイベントについて、該当する主機能と安全機能を探索する。主機能については、イベントに対応する論理機能（安全機能）の検出対象に検出（監視と言い換えることができる）の対象となる論理機能（主機能）が記載されているので、この情報が抽出される（図１３の例では主機能Ａ）。
安全機能については、処理対象のイベントの故障機能と故障モード（図１０参照）から、対応する安全機能（ここでは安全機能Ａ）が特定される。

（iii）ステップ１４０３
アーキテクチャ定量評価部１０３は、該当する故障モードに対応する故障率であって、主機能Ａが配置されているＥＣＵまたはマイコン（ここではＥＣＵ２）のパラメータに記載される故障率（図５参照）を取得する。

（iv）ステップ１４０４
アーキテクチャ定量評価部１０３は、探索した安全機能（安全機能Ａ）の検出率を当該安全機能のパラメータ（図７参照）から取得する。

（v）ステップ１４０５
アーキテクチャ定量評価部１０３は、取得した故障率及び検出率を（式１）に適用して処理対象のイベントの残存故障率を計算する。
残存故障率＝故障率×（１−検出率）・・・（式１）
ここでは、検出された故障は確実に処理されるものとして計算している。なお、該当する安全機能が無かった場合には、検出率を０として計算される。

（vi）ステップ１４０７
アーキテクチャ定量評価部１０３は、全てのイベントの残存故障率を計算した後、トップイベントの発生確率をＦＴＡツリーの構造に従って計算する。ここでは、各イベントの残存故障率を算出した後に、ＡＮＤまたはＯＲゲートの演算に従ってトップイベントの発生確率が計算される。また、ここでは、全ての事象を独立と考え、ＯＲゲートではそれぞれのイベントの残存故障率を加算し、ＡＮＤゲートではそれぞれのイベントの残存故障率の掛け算により上位のイベントの発生率が計算される。このようにして安全性の定量評価が実施される。

なお、安全性定量評価の実施を安全要件検証処理（ステップ１１０１）で実行する場合には、例えば、ハザードの残存故障率を、ハザードごとの要求値（例えばＡＳＩＬ−Ｄで１０ＦＩＴ等）と比較し、その値以下であることから検証ＯＫと判断する。

（３）第３の実施形態
第３の実施形態は、安全性検証処理において、安全機能連携を検証する処理（安全機能連携検証処理）を実行することについて開示する。第１の実施形態との差異は、図１１の安全性検証処理に安全機能連携検証処理がさらに実行される点である。以下、第３の実施形態による安全性検証処理について説明する。

＜安全性検証処理の概要＞
図１５は、第３の実施形態による安全性検証処理の概要を説明するためのフローチャートである。図１５に示されるように、第１の実施形態による安全性検証処理（図１１：ステップ１１０１〜ステップ１１０４）にステップ１５０１及びステップ１５０２が追加されている。以下、追加された処理についてのみ説明する。

（i）ステップ１５０１
安全性検証部１０２は、論理機能を配置した後の物理アーキテクチャにおける安全機能の連携について検証する。当該処理の詳細については後述する（図１６参照）。

（ii）ステップ１５０２
安全性検証部１０２は、ステップ１５０１の処理の結果、安全機能連携の検証結果がＯＫであったか否か判定する。所望の安全機能連携が行われている場合（ステップ１５０２でｙｅｓの場合）、処理はステップ１１０３に移行する。所望の安全機能連携が行われていない場合（ステップ１５０２でｎｏの場合）、処理はステップ１１０４に移行する。

＜安全機能連携検証処理の詳細＞
図１６は、安全機能連携検証処理（ステップ１５０１）の詳細を説明するためのフローチャートである。以下では、プログラムとしての安全性検証部１０２を動作主体として安全機能連携検証処理について説明するが、プログラムは車両制御システム検証装置１００のプロセッサによって読み込まれ、実行されるものであるので、安全性検証部１０２を「プロセッサ」と読み替えることも可能である。

（i）ステップ１６０１
安全機能連携検証処理は、論理アーキテクチャの全ての安全機能について実行されるため、安全性検証部１０２は、最初に該当する安全機能のパラメータから安全制御モードを取得する。安全制御モードには機能継続や安全停止等が含まれ、該当する安全機能に対応してその情報が取得される。

（ii）ステップ１６０２
安全性検証部１０２は、安全制御モードに合わせ、安全機能の連携が正しく行われているかについて、論理機能をチェックする。ここで、論理機能のチェックとは、取得した安全制御モードに対応した論理機能の連携が行われているか、安全制御モデル（図７参照）と安全機能の連携を比較することを意味する。図１７は、安全制御モデルの例を示す図である。図１７Ａは、安全制御モードの「安全停止」に対応した安全制御モデルの例を示している。図１７Ｂは、安全制御モードの「機能継続」に対応した安全制御モデルの例を示している。図１７中「Ｓ」はSensorを示し、「Ａ」はActuatorを示す。

図１７Ａの「安全停止」に対応した安全制御モデルでは、パラメータの安全機能タイプ（図７参照）で「検出」機能を持つ安全機能（安全機能Ａ）が、パラメータの検出対象（図７参照）で指定されている主機能Ａ、Ｂ、Ｃと連結されている。また、主機能Ｃの出力が安全機能タイプ（図７参照）で「切替」機能を持つ安全機能（安全機能Ｂ）へと入力されている。安全制御モードで「安全停止」が指定されている場合にはこのような連携が必要となるため、安全性検証部１０２は、このような連携が論理アーキテクチャ上で構築されているか否かチェックする。

図１７Ｂの「機能継続」に対応した安全制御モデルでは、パラメータの安全機能タイプ（図７参照）で「検出」機能を持つ安全機能（安全機能Ａ）が、パラメータの検出対象（図７参照）で指定されている主機能Ａ、Ｂ、Ｃと連結されている点は同様である。一方、「機能継続」を行う場合には、「機能継続」のための制御を行う安全機能が必要となり、検出結果の出力が安全機能タイプ（図７参照）で「制御」機能を持つ安全機能（安全機能Ｃ）へと入力されている。当該安全機能Ｃは、「制御」を行うための入力（Ｓ）をも有している。そして、当該安全機能（安全機能Ｃ）の出力結果が「切替」を行う安全機能（安全機能Ｂ）へと入力される。安全制御モードで「機能継続」が指定されている場合にはこのような連携が必要となるため、安全性検証部１０２は、このような連携が論理アーキテクチャ上で構築されているか否かチェックする。

（iii）ステップ１６０３
安全性検証部１０２は、ステップ１６０２における安全機能連携のチェック結果がＯＫであるか判定する。チェック結果がＮＧであった場合（ステップ１６０３でｎｏの場合）、処理はステップ１６０４に移行する。チェック結果がＯＫであった場合（ステップ１６０３でｙｅｓの場合）、処理はステップ１６０５に移行する。

（iv）ステップ１６０４
ステップ１６０３で論理機能チェックの結果がＮＧであった場合、安全性検証部１０２は、該当する安全要件のチェック結果がＮＧであったこととその理由を出力する。この場合、論理機能チェックＮＧとなる安全要件、またそこで不足していた論理機能の連携の情報が出力される。

ステップ１６０６で安全要件のチェック結果がＮＧであった場合、安全性検証部１０２は、ＮＧ結果とＮＧ理由を出力する。この場合、ＮＧ理由には安全度及び／又は多重度が不足していた安全要件と経路の情報が出力される。

（v）ステップ１６０５
安全性検証部１０２は、ステップ１６０３で確認した安全機能の連携について、配置先と経路の安全要件をチェックする。

図１８は、安全機能の連携に関する配置先と経路の安全要件のチェック例を示す図である。図１８Ａは、安全機能Ａと安全機能Ｂが連携しており、その機能の安全度の要求がＡＳＩＬ−Ｄの例を示している。図１８Ｂは、さらに安全機能の安全制御モードとして機能継続が指定されている場合の評価例を示している。

図１８Ａの場合、安全性検証部１０２は、配置先のＥＣＵ１とＥＣＵ３、その中間のＮＷ（ネットワーク）１、ＥＣＵ２、及びＮＷ２についても要求の安全度（ＡＳＩＬ−Ｄ）を満たしているか否か確認する。また、多重度についても同様に確認する。このようにして機能連携時の安全要件のチェックが行われる。

図１８Ｂの場合、図１８Ｂに示す通りに各機能が配置されている。安全機能の連携については図１８Ａの場合と同様に安全度の判定が行われる。また、図１８Ｂの場合、「機能継続」のための機能が追加されている。「機能継続」の場合には主機能と安全機能で独立し、かつ冗長化した経路が必要となる。主機能による経路が故障等によって使えない場合には別の経路で故障した主機能と同様の機能が実現される必要があるからである。そこで、安全性検証部１０２は、経路探索アルゴリズムにより独立した別の経路があるか検索を行う。独立した経路があり（図１８ＢのＥＣＵ２→ＮＷ２→ＥＣＵ３→ＮＷ６→ＥＣＵ６と、ＥＣＵ４→ＮＷ４→ＥＣＵ５→ＮＷ５→ＥＣＵ６の２つの経路）、さらにそれら経路が所定の安全度を満たしている場合には、安全要件のチェックをＯＫと判定する。なお、上記では「別の経路」と記したが、完全に別の経路が存在する場合だけでなく、ネットワークやＥＣＵが冗長化（内部で多重化）されている構成でも良い。その場合には経路での物理エレメントの多重度が要求されている多重度を超えているか否かで判定することができる。

（vi）ステップ１６０６
安全性検証部１０２は、ステップ１６０５で得られた安全機能連携の安全要件チェック結果がＯＫか否か判断する。安全要件チェック結果がＮＧであった場合（ステップ１６０６でｎｏの場合）、処理はステップ１６０４に移行する。安全要件チェック結果がＯＫであった場合（ステップ１６０６でｙｅｓの場合）、処理はステップ１６０７に移行する。

（vii）ステップ１６０７
安全性検証部１０２は、ＯＫ結果（安全機能連携の安全要件チェックの結果がＯＫであること）を出力する。

（４）第４の実施形態
第４の実施形態は、車両制御システムの安全性検証を車両制御システム内で実行するための構成について開示する。

＜車両制御システム構成＞
図１９は、第４の実施形態による車両制御システムの構成（物理アーキテクチャ）例を示す図である。図１９では、図１に示す車両制御システム検証装置１００がＥＣＵ３０２に配置され、与えられるＦＴＡに基づいて安全性検証処理が車両制御システム内で実行される。第１乃至第３の実施形態では、主に設計時に安全性検証処理が実行されるが、第４の実施形態では、車両制御システム検証装置１００が車両制御システム内に実装されているため、例えば、制御プログラムを書き換えたようなときに安全性検証処理を実行することが可能となる。
第４の実施形態において、車両制御システム検証装置１００は、ネットワークリンク３０１を通じてアーキテクチャ情報を収集する。

＜アーキテクチャ構成情報＞
図２０は、第４の実施形態において車両制御システム検証装置１００が受信するアーキテクチャ構成情報の例を示す図である。図２０Ａは、物理アーキテクチャ構成情報を示している。図２０Ｂは、論理アーキテクチャ構成情報を示している。

物理アーキテクチャ構成情報（図２０Ａ）は、各物理エレメント名（ＥＣＵ、マイコン）と、該当する物理エレメントと接続しているネットワーク名と、物理エレメントの各種パラメータ（図５参照）と、を構成項目として含んでいる。当該物理アーキテクチャ情報は、車両制御システム検証装置１００が、複数のＥＣＵから、それぞれが所有している情報を収集することによって構築される。

論理アーキテクチャ構成情報（図２０Ｂ）は、各論理機能名（ＩＤ）と、配置されている物理エレメント名（配置場所）と、論理アーキテクチャのパラメータ（図７参照）と、を構成項目として含んでいる。当該論理アーキテクチャ情報も、車両制御システム検証装置１００が、複数のＥＣＵから、それぞれが所有している情報を収集することによって構築される。

車両制御システム検証装置１００は、物理アーキテクチャ構成情報及び論理アーキテクチャ情報以外に、ＥＣＵ３０２やネットワークリンク３０１に予め保持された安全分析情報を収集する。そして、車両制御システム検証装置１００は、車両制御システム検証及び安全性検証の処理を実行し、ネットワーク等に検証結果を出力する。これにより、車両制御システムの状態について常に安全性の検証を実施することが可能となる。

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

（５）まとめ
（i）本開示の車両制御システム検証装置は、与えられる安全分析結果の情報に基づいて、車両制御システムの論理アーキテクチャが安全分析結果に対応する論理機能（安全機能）を有するか否かを検証する。このようにすることにより、車両制御システムのアーキテクチャの安全性を網羅的に（一部ではなく）検証することができるようになる。上記論理アーキテクチャは安全分析結果（ＦＴＡ）の情報に基づいて構築されたものであっても良い。これにより、安全分析結果の要件を充足するように設定したアーキテクチャが本当に安全分析結果に対応できるか検証することができるようになる。さらに、車両制御システム検証装置は、論理アーキテクチャが配置される物理アーキテクチャが論理アーキテクチャで要求される安全度及び多重度を満足するか否かを検証する。これにより、論理アーキテクチャ上での安全性を検証できるだけでなく、物理アーキテクチャ上での安全性を検証することができるようになる。また、例えば、安全分析結果がＦＴＡであるとき、ＦＴＡにおける複数のイベントに対応する論理アーキテクチャの安全性検証の結果と物理アーキテクチャの安全性検証の結果とをＦＴＡに当てはめたときにトップイベントが発生するか否かを判定することにより、設計されたアーキテクチャが適切であるか否か効果的に評価することができるようになる。

また、本開示の車両制御システム検証装置は、物理アーキテクチャ（例えば、複数の物理エレメントとネットワークを含む）を定量評価する。具体的には、論理アーキテクチャを物理エレメントに配置したときの、複数の物理エレメントの使用率と、ネットワークの占有率を算出することにより、物理アーキテクチャの定量評価を行うことができる。

（ii）定量評価の別の形態として、本開示の車両制御システム検証装置は、ＦＴＡの複数のイベントのそれぞれについて、論理アーキテクチャにおける、各イベントに対応する論理アーキテクチャの論理機能の残存故障率を、当該論理機能のパラメータである故障率と検出率とから算出し、当該各イベントに対応する論理機能の残存故障率をＦＴＡに適用してトップイベントの残存故障率を算出する。このようにすることにより、安全機能が適切であった場合であってもトップイベント（例えば、危険性のある故障）が発生してしまう確率を提供することが可能となる。そして、この結果に基づいて、さらなるアーキテクチャの改良（故障率を下げたり、検出率を上げたりする）が必要であるか考察することが可能となる。

（iii）本開示の車両制御システム検証装置は、異常発生時に論理アーキテクチャが実現すべき制御内容を示す安全制御モードに対応して各論理機能が連携動作するか否かチェックする。例えば、安全制御モードが安全停止である場合には、異常を検出する機能を有する安全機能と、異常を検出する対象の主機能と、切替機能を有する安全機能とが連携して動作するか否かチェックされる。また、安全制御モードが機能継続である場合には、異常を検出する機能を有する安全機能と、異常を検出する対象の主機能と、代替制御を行う機能を有する安全機能と、切替機能を有する安全機能とが連携して動作するか否かチェックされる。このようにすることにより、アーキテクチャにおける安全機能の連携について検証することができるようになる。また、各安全制御モードの種類に応じた機能連携について検証することができるようになる。

（iv）本開示の車両制御システム検証装置は、車両制御システムの物理アーキテクチャ内に配置することも可能である。この場合、車両制御システム検証装置は、外部から入力される、車両制御システムの論理アーキテクチャ及び物理アーキテクチャの情報と安全分析結果の情報を取得し、これらに基づいて、アーキテクチャの安全性について検証する。例えば、論理アーキテクチャについては、それが安全分析結果（ＦＴＡ）に対応する論理機能（安全機能）を有するか否か検証される。物理アーキテクチャについても、要求される安全度及び多重度が充足されるか検証される。このように車両制御システム内に当該車両制御システム検証装置を実装することにより、例えば、制御プログラムを書き換えたような場合にも車両制御システムの安全性を検証することができるようになる。

（v）本開示の実施形態は、その機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

さらに、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本開示は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本開示を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。

加えて、本技術分野の通常の知識を有する者には、本開示のその他の実装がここに開示された本開示の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本開示の範囲と着想は後続する特許請求範囲で示される。

１ 車両システム
２ 車両制御システム
３ 通信装置
４ 車両制御システム
５ 駆動装置
６ 認識装置
７ 出力装置
８ 入力装置
９ 通知装置
２０ 物理アーキテクチャ
１００ 車両制御システム検証装置
１０１ 機能配置部
１０２ 安全性検証部、
１０３ アーキテクチャ定量評価部
３００ 物理アーキテクチャ
３０１ ネットワークリンク
３０２ ＥＣＵ
４０１ プロセッサ
４０２ Ｉ／Ｏデバイス
４０３ タイマ
４０４ ＲＯＭ
４０５ ＲＡＭ
４０６ 内部バス
６０１ 論理アーキテクチャ
６０２ 統合認識部
６０３ 自動運転制御部
６０４ ユーザ入力部
６０５ 出力管理部
６０６ 通知管理部
６０７ 異常検出部
６０８ 切替部
６０９ 運動制御部
６１０ 安全制御部
９００ 安全分析情報
９０１ トップイベント
９０２ ゲート
９０３ イベント

Claims (10)

1. 車両制御システムの論理アーキテクチャの安全性を検証するためのプログラムを格納する記憶デバイスと、
   前記記憶デバイスから前記プログラムを読み込み、前記論理アーキテクチャの安全性を検証するプロセッサと、を備え、
   前記論理アーキテクチャの論理機能は、前記車両制御システムにおいて所定の機能を実現するための主機能と、前記車両制御システムの異常に対応するための安全機能と、によって構成され、
   前記論理アーキテクチャは、前記車両制御システムの物理アーキテクチャに配置され、
   前記プロセッサは、与えられる安全分析結果の情報に基づいて、前記論理アーキテクチャが前記安全分析結果に対応する論理機能を有するか否かを検証する第１の検証処理を実行し、
   前記プロセッサは、さらに、前記主機能に対応する物理アーキテクチャの故障率及び、主機能の故障を検出する安全機能の検出率により算出されたイベントの発生率に基づき安全要件の定量評価を行う第２の検証処理を実行する、車両制御システム検証装置。
2. 請求項１において、
   前記論理アーキテクチャは、前記安全分析結果の情報に基づいて構築されたものである、車両制御システム検証装置。
3. 請求項２において、
   前記安全分析結果の情報は、複数のイベントの発生と最終結果であるトップイベントの発生との関係をツリー構造で表すＦＴＡであり、
   前記プロセッサは、さらに、
   前記ＦＴＡにおける前記複数のイベントに対応する前記第１の検証処理の結果と前記第２の検証処理の結果とを前記ＦＴＡに当てはめたときに前記トップイベントが発生するか否かを判定する処理と、
   前記判定する処理の結果を出力する処理と、
   を実行する、車両制御システム検証装置。
4. 請求項３において、
   前記判定する処理の結果が前記トップイベントの発生を示す場合、前記プロセッサは、さらに、前記物理アーキテクチャの定量評価を行う処理を実行する、車両制御システム検証装置。
5. 請求項４において、
   前記物理アーキテクチャは、複数の物理エレメントとネットワークとを含み、
   前記プロセッサは、前記定量評価を行う処理において、前記論理アーキテクチャを前記物理エレメントに配置したときの、前記複数の物理エレメントの使用率と、前記ネットワークの占有率を算出することにより、前記物理アーキテクチャの定量評価を行う、車両制御システム検証装置。
6. 請求項４において、
   前記プロセッサは、前記定量評価を行う処理において、
   前記複数のイベントのそれぞれについて、前記論理アーキテクチャにおける、各イベントに対応する前記論理アーキテクチャの論理機能の残存故障率を、当該論理機能のパラメータである故障率と検出率とから算出する処理と、
   前記算出された各イベントに対応する論理機能の残存故障率を前記ＦＴＡに適用して前記トップイベントの残存故障率を算出する処理と、
   を実行する、車両制御システム検証装置。
7. 請求項１において、
   前記プロセッサは、さらに、前記車両制御システムの異常発生時に前記論理アーキテクチャが実現すべき制御内容を示す安全制御モードの情報を取得し、前記安全制御モードに対応する、前記論理アーキテクチャの各論理機能が連携して動作するか否かチェックする処理を実行する、車両制御システム検証装置。
8. 請求項７において、
   前記論理アーキテクチャの論理機能は、前記車両制御システムにおいて所定の機能を実現するための主機能と、前記車両制御システムの異常に対応するための安全機能と、によって構成され、
   前記論理機能の連携動作をチェックするとき、前記安全制御モードが安全停止である場合、前記プロセッサは、異常を検出する機能を有する安全機能と、異常を検出する対象の主機能と、切替機能を有する安全機能との連携が前記論理アーキテクチャにおいて構築されているか否か判定する、車両制御システム検証装置。
9. 請求項７において、
   前記論理アーキテクチャの論理機能は、前記車両制御システムにおいて所定の機能を実現するための主機能と、前記車両制御システムの異常に対応するための安全機能と、によって構成され、
   前記論理機能の連携動作をチェックするとき、前記安全制御モードが機能継続である場合、前記プロセッサは、異常を検出する機能を有する安全機能と、異常を検出する対象の主機能と、代替制御を行う機能を有する安全機能と、切替機能を有する安全機能との連携が前記論理アーキテクチャにおいて構築されているか否か判定する、車両制御システム検証装置。
10. 請求項７に記載の車両制御システム検証装置を備え、
    前記車両制御システム検証装置は、前記車両制御システムの物理アーキテクチャを構成する物理エレメントに配置され、
    前記車両制御システム検証装置は、入力される、前記車両制御システムの前記論理アーキテクチャ及び前記物理アーキテクチャの情報と前記安全分析結果の情報とに基づいて、前記論理アーキテクチャが前記安全分析結果に対応する論理機能を有するか否かを検証する、車両制御システム。

Images