JP2020101877A - 車両用電子制御装置、異常信号生成方法、異常信号生成プログラム - Google Patents

Abstract

【課題】コストの高いシミュレーションの導入や検証対象のシステムの変更を行うことなく、自動車に搭載されるシステムが故障した場合の影響を検証する車両用電子制御装置を提供する。【解決手段】車両用電子制御装置１３００は、仮想化環境１２００と、ハイパーバイザ１１００と、ＥＣＵ１０００とを含む。ハイパーバイザは、信号生成に関する条件を定める信号生成テーブル１１２１に基づき、模擬的に故障を引き起こす異常信号を生成する信号生成部１１２０と、当該異常信号をテスト用実行環境となる検証対象のシステムに転送する信号転送部１１１０を備える。【選択図】図１

Description

本発明は、車両用電子制御装置、異常信号生成方法、異常信号生成プログラムに関する。

ハードウエアとソフトウエアの統合化が進む中、ソフトウエアとハードウエアとの互換性を検証することが重要である。特に、多様なセンサ等のハードウエアシステム及び当該センサのロジックを制御するアプリ等のソフトウエアシステムが搭載される自動車では、車両に関する機能安全規格を満たし、安全性を確保するために、搭載されるハードウエアシステムまたはソフトウエアシステムが故障した場合に、自動車全体にどのような影響が与えられるかを検証し、システム間のやり取りに生じる信号を制御する手法が求められている。

これに対して、特開２０１３−１６１２９９号公報（特許文献１）には、「複数のプログラムが記憶されたプログラム記憶手段１３と、前記プログラムを実行する１つ以上の演算手段１１と、外部の回路と通信可能な複数のインタフェース２０と、を有する情報処理装置１００であって、前記プログラムがアクセス可能な前記インタフェースが登録されたインタフェース登録テーブル３４と、前記インタフェースにアクセス要求した前記プログラムが、前記インタフェースにアクセスすることが許可されている場合、前記プログラムの代わりに前記インタフェースにアクセスするアクセス制御手段３３と、を有する」が記載されている。

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

上記の特許文献１においては、自動車に搭載されるＥＣＵ等の制御装置と、ハイパーバイザ上に動作するアプリケーションとのI/Oを制御する情報処理装置が記載されている。特許文献１に係る発明によれば、あるアプリケーションが特定のI/Oポート（例えば、ＥＣＵのI/Oポート）にアクセスする命令を実行し、当該命令に対してアクセス違反が検出された場合には、ハイパーバイザがアプリケーションの代わりに当該命令を実行することにより、アクセス違反を防止することができる。

しかし、特許文献１では、自動車に搭載されるハードウエアシステムまたはソフトウエアシステムの故障をシミュレート及び評価することが検討されていない。このため、ハードウエアまたはソフトウエアの動作を検証するためには、ＨＩＬＳ（Hardware In the Loop Simulation）やｖＨＩＬＳ（Virtual Hardware in the Loop Simulation）等のシミュレーション手段、あるいはハードウエアの直接的な変更が必要となる。しかし、これらのシミュレーション手段は導入コストが高く、ハードウエアの直接的な変更では、速いペースで進化していく車載用デバイスのニーズに対応することが難しい。また、自動車に搭載されるハードウエア及びソフトウエアシステムの耐故障性検証のニーズに充分応えられてないといった課題がある。

そこで、本発明は、コストの高いシミュレーション手段の導入や検証対象のシステムの変更を行うことなく、自動車に搭載されるシステムが故障した場合の影響を検証する手段を提供することを目的とする。

上記の課題を解決するために、代表的な本発明の異常信号生成ハイパーバイザを含む車両用電車制御装置の一つは、ハイパーバイザを含む車両用電子制御装置であって、前記ハイパーバイザは、異常信号生成部と、信号転送部とを備え、前記異常信号生成部は、信号生成に関する条件を定める信号生成テーブルに基づき、異常信号を生成し、前記信号転送部は、前記異常信号をテスト用実行環境に転送する。

本発明によれば、コストの高いシミュレーション手段の導入やハードウエアシステム及びソフトウエアシステムの変更を行うことなく、自動車に搭載されるシステムが故障した場合の影響を検証することができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明に係る車両用電子制御装置の一例を示すブロック図である。 本発明に係る分散型システムの一例を示す図である。 本発明に係る信号生成テーブルの一例を示す図である。 本発明に係る実施例１において、ハードウエアシステム又はソフトウエアシステムから受信した信号を用いて異常信号を生成する処理の一例を示す図である。 本発明に係る実施例１において、ハードウエアシステム又はソフトウエアシステムの状態情報を用いて異常信号を生成する処理の一例を示す図である。

以下、図面を参照して、本発明の実施形態について説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

［実施例１の概要］
本発明では、自動車に搭載されるハードウエアシステム（Electric Control Unit、映像撮影システム、ブレーキ制御システム等）と、ソフトウエアシステム（Operating System等のスーパーバイザ及びその上に実装されるアプリ）との間のやり取り（信号の通信など）を制御するハイパーバイザが用いられる。一般的には、ハードウエアシステムやソフトウエアシステムにおいて生じる信号は、信号の発生源から直接に送信先に送信される。しかし、本発明では、特定のアプリ又はハードウエア宛に送信される信号は、送信先に到達する前に、ハイパーバイザで一旦捕捉され、予め用意される信号生成テーブルに基づいて異常信号が生成される。このように、信号生成テーブルに基づいて異常信号が送信先（テスト用実行環境となる検証対象のシステム）に転送されることで、送信先のシステムにおいて所望の故障を模擬的にシミュレートすることができる。また、異常信号を送信先に転送した後、宛先のシステムにおける動作の結果（システムがどう反応したか）をデータログ等で記録することで、異常信号がシステムに与えた影響を評価・検証することができる。これにより、自動車に搭載されるハードウエアシステムとソフトウエアシステムの互換性を、コストの高いシミュレーション手段の導入やハードウエアシステム及びソフトウエアシステムの変更を用いることなく、検証することが可能となる。

まず、図１を参照して、本発明に係る車両用電子制御装置１３００の構成について説明する。車両用電子制御装置１３００とは、自動車における様々な機能を総合的に制御し、車両に搭載されるセンサ等のハードウエアシステム及び当該ハードウエアシステムのロジックを制御するアプリ等のソフトウエアシステムを管理するシステムである。図１に示されるように、車両用電子制御装置１３００は、仮想化環境１２００と、ハイパーバイザ１１００と、ＥＣＵ１０００とを含む。

ＥＣＵ（Electronic Control Unit）１０００とは、エンジン、モーター、メーター、トランスミッション、ブレーキ、エアバッグ、ランプ、パワーステアリング、パワーウィンドウ、カーエアコン、電子キーの車両側受信部、カーオーディオ、カーナビゲーションシステム、カメラ、温度計、各種センサ等の機能を制御する補助装置である。図１に示されるように、ＥＣＵ１０００は、複数のＣＰＵ１０１０、１０１５と、メモリ１０３０と、ハードウエア信号を発信するハードウエア信号転送部１０２０とを含む。
なお、図１では、ＣＰＵを二つ有し、メモリとハードウエア信号転送部を１つずつ有するＥＣＵ１０００を示したが、本発明はそれに限定されず、各部品の数を適宜に変更してもよい。

次に、ハイパーバイザ１１００について説明する。
一般的に、自動車などに搭載される電子処理システムは、RAMやCPUなどのハードウエア資源を提供するハードウエア層と、一つまたは複数の仮想機械の稼働を管理するハイパーバイザ層と、それぞれの仮想機械のOS（Operating System）を実装するスーパーバイザ層と、アプリケーションソフトウェアが稼働するアプリケーション層からなる。そして、ハイパーバイザは、仮想機械を制御する上位の制御プログラムとして、下位の層で実装されるスーパーバイザやアプリケーションソフトウェアにリソースの分配などを行う。そして、本発明におけるハイパーバイザは、外部の装置とのコミュニケーションを統括する。つまり、本発明におけるハイパーバイザ１１００は、ＥＣＵ１０００（すなわち、ハードウエア層）と、後述する仮想化環境１２００（すなわち、スーパーバイザ層及びアプリケーション層）の稼働を管理し、ＥＣＵ１０００と仮想化環境１２００との間におけるコミュニケーション（信号のやり取りなど）を制御するものである。

図１に示されるように、ハイパーバイザ１１００は、ＥＣＵ１０００及び仮想化環境１２００から生じる信号を送受信する信号転送部１１１０と、後述する処理によって異常信号（所望の故障を検証対象のシステムにおいて模擬的に引き起こす信号）を生成する異常信号生成部１１２０と、異常信号の生成条件を示す信号生成テーブル１１２１と、信号のハイパーバイザにおける動作や生成結果を記録するデータログ１１３０とを含む。
また、図１に示されるように、信号転送部１１１０は、異常信号生成部１１２０と通信可能であり、異常信号生成部１１２０は、信号転送部１１１０で受信される信号と、信号生成テーブル１１２１とに基づいて、異常信号を生成する。ハイパーバイザは、ＥＣＵ１０００におけるＣＰＵ１０１０、１０１５やメモリ１０３０などのリソースを用いて、仮想化環境１２００を構成する。
なお、図１では、ＥＣＵ１０００が１つのハードウエア信号転送部１０２０を備える場合を示しているが、ハードウエア信号転送部１０２０を複数備えられてもよい。そして、ハードウエア信号転送部１０２０が複数備えられている場合には、それぞれのハードウエア信号転送部に対応する信号転送部ｇａ信号転送部１１１０内に備えられていてもよい。

仮想化環境１２００とは、ハイパーバイザ１１００によって構成され、仮想機械やアプリケーションを互いに独立した状態で実行させる論理空間である。図１に示されるように、仮想化環境１２００内には、１つまたは複数のスーパーバイザ１２１０が実装される。このスーパーバイザ１２１０は、後述するアプリケーションにリソースを与え、当該アプリケーションの動作を管理するものであり、例えば、WindowsやLinux等のＯＳ（オペレーティングシステム）であってもよい。スーパーバイザ１２１０には、スーパーバイザ上で稼働するアプリケーションのリソース使用率や動作の結果を記録するデータログ１２１１を備える。上述したように、スーパーバイザ１２１０の上では、アプリケーション（以下、「アプリ」という）１２１２が実装される。そして、アプリ１２１２は、車載のセンサ等のハードウエアの制御を行うプログラムであり、例えば、カメラ等のセンサによって撮像される画像を処理する画像処理プログラムであってもよい。
また、上述したように、アプリ１２１２は、ハイパーバイザ１１００の信号転送部１１１０を介して、ＥＣＵ１０００に信号を送信したり、ＥＣＵから信号を受信したりする。さらに、アプリ１２１２は、アプリ内におけるリソース使用率や動作の結果を記録するデータログ１２１３を備える。

図１に示されるデータログ分析部１４００は、車両用電子制御装置１３００内に備えられていてもよく、ネットワークを介して車両用電子制御装置１３００と通信を行う遠隔のデバイスに備えられていてもよい。ここで、データログ分析部１４００とは、ハイパーバイザのデータログ１１３０と、スーパーバイザ１２１０のデータログ１２１１と、アプリ１２１２のデータログ１２１３のデータを取得し、後述する処理によって生成される異常信号の動作結果を分析するものである。データログ分析部１４００は、例えば、ＥＣＵ１０００から発信された信号に基づいて生成した異常信号を信号転送部１１１０によってアプリ１２１２に送信した場合に、ハイパーバイザ、スーパーバイザ、及びアプリのそれぞれにおける影響を評価するために、それぞれのデータログの情報を取得して分析してもよい。

次に、図１に示される車両用電子制御装置１３００の具体例を説明する。ハードウエア信号転送部１０２０がIntelのＡＰＩＣ（登録商標），AMDのAVID（登録商標）、ＡＲＭのGIC（登録商標）、又はＡＲＭのＡＭＢＡ（登録商標）仕様のデバイス等として構成された場合には、信号転送部１１１０は、ハードウエア信号転送部１０２０から転送されるハードウエア信号をハイパーバイザで捕捉する構成にしてもよい。ここで説明した例以外にも、車両用電子制御装置１３００を用いる様々な具体例は可能である。

次に、図２を参照して、本発明に係る分散型システム１００の構成の一例について説明する。以上では、本発明に係る仮想化環境、ハイパーバイザ、及びＥＣＵが一体となる車両用電子制御装置について説明したが、本発明はそれに限定されず、上述した車両用電子制御装置の構成要素がお互いに離れており、インターネット等のネットワークにより接続される構成も可能である。

図２に示されるように、分散型システム１００は、中央サーバ１５０と、ＥＣＵ１１８、１１９をそれぞれ搭載する自動車１２０、１２１と、ネットワーク１７５とからなる。中央サーバ１５０は、ネットワーク１７５を介して自動車１２０、１２１と接続される。

中央サーバ１５０は、仮想化環境１１０と、ハイパーバイザ１１２とを含む検証部１０４と、ＣＰＵ１１３と、メモリ１１４と、記憶部１１５と、通信部１１６とを含むリソース管理部１０６とからなる。
中央サーバ１５０とは、検証対象のシステム（アプリ等のソフトウエア又はＥＣＵ等のハードウエアシステム）の耐故障性を検証するために、特定のエラーや故障を引き起こす異常信号の影響を検証するテスト用実行環境１１１を提供するサーバ装置である。このテスト用実行環境１１１とは、異常信号を模擬的にシミュレートし、当該信号の動作結果や影響を検証・分析するための空間である。
なお、本実施例では、一例として、テスト用実行環境１１１が仮想化環境において作成される論理空間を説明するが、テスト用実行環境１１１はこれに限定されず、特定のハードウエアデバイスとしてもよい。例えば、テスト用実行環境１１１は、異常信号の動作・影響を検証するために予め設定されたＥＣＵ、カメラ、自動運転システム、ブレーキ制御部等のハードウエアであってもよい。

中央サーバ１５０のハイパーバイザ１１２は、ＣＰＵ１１３、メモリ１１４、及び記憶部１１５の物理リソースを用いて、テスト用実行環境１１１を含む仮想化環境１１０を作成する。また、ハイパーバイザ１１２は、上述したように、異常信号生成部１１７を含んでいる。この異常信号生成部１１７は、検証対象のシステムの耐故障性を検証するための異常信号を生成する機能部である。そして、異常信号生成部１１７は、例えば自動車１２０、１２１のＥＣＵ１１８、１１９からの信号（元信号）をネットワーク１７５を介して受信し、後述する異常信号生成テーブルに基づいて受信した信号を加工し、これをテスト用実行環境１１１に転送してもよい。あるいは、新たな異常信号を異常信号生成テーブルに基づいて生成して、この異常信号をＥＣＵ１１８又は１１９に転送してもよい。

このような分散型システム１００を用いて、共通の仮想化環境下で、複数の検証対象のシステム（自動車等）に対応することにより、検証対象のシステムごとに仮想化環境を用意することが不要となり、システムのリソース（ＣＰＵ，メモリ、Ｉ/Ｏ、ストレージ）を大幅に節約することができる。

次に、図３を参照して、本発明に係る信号生成テーブル１１２１の構成について説明する。信号生成テーブル１１２１は、検証対象のシステム（アプリ等のソフトウエア又はＥＣＵ等のハードウエアシステム）の耐故障性を検証するための異常信号（模擬故障信号）の生成条件を示すテーブルである。図３に示されるように、信号生成テーブル１１２１では、信号を識別する識別子である入力・出力信号ＩＤと、信号のタイミングに関する信号タイミング条件と、信号のデータに関する信号データ条件とが定められている、信号生成テーブル１１２１は手動でユーザによって作成されてもよく、後述するように、過去の異常データの分析に基づいて、人工知能によって自動的に作成されてもよい。

図３に示されるように、信号生成テーブル１１２１は、信号転送部（例えば、図１における信号転送部１１１０）によって受信される信号のうち、加工対象の信号を識別する入力信号ＩＤ１１２２と、対象の信号を出力する際に割り当てる識別子を示す出力信号ＩＤ１１２３と、対象の信号に対して適用するタイミングの変更（遅延等）を示す信号タイミング条件１１２４と、対象の信号に対して適用するデータの変更を示す信号データ条件１１２５と、対象の信号を送信したシステムまたは対象の信号を受信するシステムの状態（異常、正常、信号を送受信してない期間等）を示す状態情報１１２６とを含む。この状態情報（「システム状態」ということもある）１１２６とは、例えば、信号の送信先となるアプリやスーパーバイザ（またはセンサ等のハードウエアデバイス）、のリソース使用率やI/Oデータ通信量が正常か否かを示す情報であってもよい。また、送信先となるソフトウエアシステム又はハードウエアシステムが正常でない場合には、当該システムの異常を示すエラーメッセージ（所定期間内には信号が届いていない、メモリ不足等）を示していてもよい。
なお、説明を簡易にするため、入力識別ＩＤ１１２２が１桁の数字である場合を図３に示しているが、本発明はこれに限定されない。例えば、入力識別ＩＤ１１２２は、特定の信号を一意に識別する文字列であってもよく、特定の信号の種類を示すものであってもよい。信号生成テーブル１１２１が用いられる処理については後述する。

上述したように、信号生成テーブル１１２１は、過去の異常データの分析に基づいて、人工知能によって自動的に生成されてもよい。ここで、人工知能とは、例えば、ルールベースの機械学習、ディープラーニング、次元削減方法、アンサンブル学習、インスタンスベースアルゴリズム、回帰分析、ベイジアンネットワーク、ニューラルネットワーク、クラスター分析、強化学習、又はこれらの技術と他の技術の組み合わせ等が上げられる。
これらの人工知能は、例えば、蓄積された過去の異常データを分析し、様々な条件化でどのような異常信号が生じるか、ソフトウエアシステム又はハードウエアシステムが特定の異常信号を受信した場合にどのように作動するか等を学習し、学習モデルを構築してもよい。そして、構築した学習モデルを使用することで、検証対象となるシステムに特定の異常状態を発生させるための最適な異常信号生成条件を導出し、これらの生成条件を信号生成テーブル１１２１として定めてもよい。これにより、特定の異常状態を最適に引き起こせる条件を自動的に生成することができる。

次に、図４を参照して、ハードウエアシステム又はソフトウエアシステムから受信した信号を用いて異常信号を生成する処理について説明する。上述したように、本処理は対象のシステム（アプリ等のソフトウエア又はＥＣＵ等のハードウエア等）の耐故障性を検証するために、ハードウエアシステム又はソフトウエアシステムから受信した信号（元信号）を、信号生成テーブル１１２１（図３参照）に示される生成条件に基づいて加工し、異常信号を生成する処理である。
なお、以下の説明では、アプリ宛の信号をＥＣＵ側から発信する例として説明するが、本発明はこれに限定されない。例えば、本処理は、特定のソフトウエアシステム宛の信号をハードウエア側から発信する場合に適用してもよく、特定のハードウエアシステム宛の信号をソフトウエア側から発信する場合に適用してもよい（すなわち、検証対象のシステムがソフトウエアかハードウエアかは任意である）。

ステップ２０００では、特定のアプリ（例えば、図１に示されるアプリ１２１２）又はＥＣＵ（例えば、図１に示されるＥＣＵ１０００）宛の信号（元信号）がＥＣＵ又はアプリにおいて発生する。上述したように、この信号は、ＥＣＵにおいて発生したアプリ宛の信号であってもよいし、アプリにおいて発生したＥＣＵ向けの信号であってもよい。具体的には、この信号は、カメラによって取得された画像データを、仮想化環境で稼働する画像処理アプリに加工させる要求信号などが該当する。

ステップ２００１では、信号転送部（例えば、図１に示される信号転送部１１１０）は、ステップ２０００で発生した信号を捕捉する。ここで、「捕捉」とは、信号を捉えて、信号転送部内に一時的に保存することを意味する。

ステップ２００２では、信号転送部は、異常信号生成部（例えば、図１に示される異常信号生成部１１２０）が起動中（異常信号生成機能がオンになっているか）か否かを確認する。異常信号生成部が起動中でない場合、本処理はステップ２００３に進み、信号転送部は当該信号を（加工せずに）そのまま送信先に転送する。一方、異常信号生成部が起動中の場合、本処理はステップ２００４へと進む。

ステップ２００４では、信号転送部は、ステップ２００１で受信した信号（例えば、信号に関連付けられているメタデータ）から、当該信号を識別する信号ＩＤを抽出する。

ステップ２００５では、信号転送部は、受信した信号の信号ＩＤに該当する入力信号ＩＤが信号生成テーブル１１２１（図３参照）に存在するか否かを確認する。例えば、信号転送部は、ステップ２００４で信号から抽出した信号ＩＤを、信号生成テーブル１１２１に記録されている入力信号ＩＤと比較し、一致するものがあるかないかを判定する。抽出した信号ＩＤが信号生成テーブルに記録されている入力信号ＩＤに一致しない場合には、本処理はステップ２００３に進み、信号転送部は当該信号を（加工せずに）そのまま送信先に転送する。一方、抽出した信号ＩＤが信号生成テーブルに記録されている入力信号ＩＤに一致する場合には、本処理はステップ２００６へと進む。

ステップ２００６では、信号転送部は、信号の送信先となるシステムの状態情報を取得する。上述したように、この状態情報とは、対象の信号を受信するシステムの状態（正常、異常等）を示す情報である。例えば、信号転送部は、ステップ２００１で受信した信号の送信先となるシステムに対して状態情報の取得要求を送信し、当該送信先から状態情報の通知を受信してもよく、所定のメモリアドレスに保存されている状態情報の管理テーブル等をアクセスし、当該送信先の状態情報を読み込んでもよく、状態情報の取得方法は特に限定されない。

ステップ２００７では、ステップ２００６で取得した状態情報が信号生成テーブル（例えば、図２示される信号生成テーブル１１２１）に記載されている状態情報に一致するか（すなわち、送信先となるシステムが対象の信号を受信するのに適切な状態となっているか）を確認する。ステップ２００６で取得した状態情報と、信号生成テーブルにおいて対象の信号について記載されている状態情報が一致しない場合には、本処理はステップ２００３に進み、信号転送部は当該信号を（加工せずに）そのまま送信先となるシステムに転送する。一方、ステップ２００６で取得した状態情報と、信号生成テーブルにおいて対象の信号について記載されている状態情報が一致する場合には、本処理はステップ２００８へと進む。

ステップ２００８では、異常信号生成部（例えば、図１に示される異常信号生成部１１２０）は、信号生成テーブルに基づいて、受信した信号を加工することにより、異常信号を生成する。ここで、異常信号を生成する処理とは、異常信号生成部が、ステップ２００１で受信した信号に対して、信号生成テーブルに記載されている、当該信号に対応する処理を施し、加工した信号を異常信号として作成することを意味する。より具体的には、異常信号生成部は、信号生成テーブルに記載されている信号タイミングの条件、信号データの変更、及び/又は信号ＩＤの変更を対象の信号に対して適用する処理を行う。この処理では、異常信号生成部は、例えば、受信した元信号のデータ列の所定箇所を所定の値に置換することで、異常信号を生成することを含む。図３を参照して一例を説明すると、信号転送部が入力信号ＩＤ「１」の信号を受信した場合、異常信号生成部は信号生成テーブルに記載されている通り、当該信号に対して、２ナノ秒の遅延を信号のタイミング変更として適用することで異常信号を生成する（なお、入力信号ＩＤ「１」の場合、出力信号ＩＤ及び信号データの変更がないため、異常信号を生成する処理は信号タイミングの変更のみとなる）。
なお、受信した元信号のタイミングを変更することにより異常信号を生成することを一例として説明したが、本発明はこれに限定されず、元信号に対してデータの変更、出力信号ＩＤの変更など、タイミング変更以外の加工が行われていてもよい。異常信号の生成処理が終了すると（信号生成テーブルにおいて対象の信号について記載されている変更がすべて行われた時）、本処理はステップ２００３に進み、信号転送部は異常信号を送信先（例えば、テスト用実行環境となるアプリ、スーパーバイザ、又はハードウエアデバイス）へと転送する。

ステップ２００９では、異常信号が送信先のシステムに転送されると同時に、異常信号の影響を監視するデータログ（例えば、図１に示されるアプリのデータログ１２１３、スーパーバイザのデータログ１２１１、及びハイパーバイザのデータログ１１３０）が起動する。これらのデータログは、異常信号の各層における動作を監視し、記録する診断プログラムであってもよい。例えば、これらのデータログは、アプリ又はスーパーバイザにおけるリソース使用率やI/O通信量等の変化、信号のタイミング、ハードウエアデバイスの温度、電圧、性能等の変化、異常信号の種類や所望の模擬故障に応じて、異常信号の影響を定量化する様々なパラメータを記録してもよい。

ステップ２０１０では、データログ分析部（例えば、図１に示されるデータログ分析部１４００）がデータログの情報（すなわち、アプリのデータログ１２１３、スーパーバイザのデータログ１２１１、及びハイパーバイザのデータログ１１３０の情報）を取得する。上述したように、データログ分析部とは、それぞれのデータログに記録されている情報に基づいて、異常信号の影響を分析する機能部である。データログ分析部は、例えば、各層のデータログが起動する際に、それぞれのデータログの情報を継続的に取得してもよく、所定の期間（例えば１分）ごとに定期的にデータログの情報を取得してもよい。

ステップ２０１１では、データログ分析部は、ステップ２０１０で取得した各データログの情報を分析する。ここで、分析するとは、異常信号が各層（アプリ層、スーパーバイザ層、ハイパーバイザ層、ハードウエア層等）に与えた影響を評価するために、それぞれのデータログの情報を解析したり、データにおけるパターンや関係を特定したりすることを意味する。例えば、データログ分析部は、データログから取得したリソース使用率、信号のタイミング、ハードウエアデバイスの温度、電圧、性能等のパラメータを所定の閾値に比較することで、異常信号が送信先において故障を引き起こしたか否か、故障の大きさなどを定量化し、検証することができる。

以上、異常信号を生成し、当該異常信号の影響を検証する流れを一つの異常信号について説明したが、本処理は一つの異常信号の生成・検証後に終了する必要はない。本発明の態様の一つでは、本発明に係るハイパーバイザは、以前の異常信号（例えば、第１の異常信号及び/又はそれ以前に送信された過去の信号）の影響に応じて、新しい異常信号（例えば、第２の異常信号）を生成してもよい。例えば、検証対象となるアプリやハードウエアデバイスを特定の故障状態にしたい場合には、まずは第１異常信号を生成・転送し、第１異常信号の動作結果を評価した後（例えば、検証対象が所望の故障状態になったか否かの確認後）、この動作結果に応じた第２異常信号を生成・転送してもよい。このように、模擬故障を連鎖的に引き起こすことが可能となり、故障が連続する状況をシミュレートすることができる。

［実施例２の概要］
次に、図５を参照して、ハードウエアシステム又はソフトウエアシステムの状態情報を用いて異常信号を生成する処理について説明する。ここで説明する処理は、検証対象のシステム（アプリ等のソフトウエア又はＥＣＵ等のハードウエア）の耐故障性を検証するために、実施例１に説明したような元信号を用いずに、検証システムの状態情報を用いて所望の故障を引き起こす異常信号を（一から）生成する処理である。
なお、実施例１に説明した処理と同じように、以下の説明では、アプリ宛の信号がＥＣＵ側で発信することを一例として説明するが、本発明はそれに限定されない。例えば、本処理は、特定のソフトウエアシステム宛の信号がハードウエア側から発信される場合に適用されてもよく、特定のハードウエアシステム宛の信号がソフトウエア側から発信される場合に適用されてもよい。すなわち、検証対象のシステムがソフトウエアかハードウエアかは任意である。

まず、ステップ３０００では、信号転送部は、異常信号生成部（例えば、図１に示される異常信号生成部１１２０）が起動中か否かを確認する。ここで、「起動中」とは、異常信号生成機能がオンになっていることを意味する。異常信号生成部が起動中でない場合、本処理は終了する。一方、異常信号生成部が起動中の場合、本処理はステップ３００１へと進む。

次に、ステップ３００１では、信号転送部は、信号の送信先となるシステムの状態情報を取得する。上述したように、この状態情報とは、対象の信号を受信するシステムの状態（正常、異常等）を示す情報である。例えば、信号転送部は、ステップ検証対象となるシステムに対して状態情報の取得要求を送信し、当該検証対象から状態情報の通知を受信してもよく、所定のメモリアドレスに保存されている状態情報の管理テーブル等をアクセスし、当該検証対象の状態情報を読み込んでもよく、状態情報の取得方法は特に限定されない。ここでは、信号転送部は、検証対象となるシステムの状態情報を継続的に監視してもよく、所定の期間（例えば１分）ごとに定期的にシステムの状態情報を取得してもよい。

次に、ステップ３００２では、信号転送部は、ステップ３００１で取得した状態情報が信号生成テーブル１１２１（図３参照）に記載されている状態情報に一致するかを確認する。すなわち、信号転送部は、検証対象となるシステムが対象の信号を受信するのに適切な状態となっているかを確認する。ステップ３００１で取得した状態情報と、信号生成テーブルにおいて対象の信号について記載されている状態情報が一致しない場合には、本処理は異常信号を生成せずに終了する。一方、ステップ３００１で取得した状態情報と、信号生成テーブルにおいて対象の信号について記載されている状態情報が一致する場合には、本処理はステップ３００３へと進む。

次に、ステップ３００３では、異常信号生成部（例えば、図１に示される異常信号生成部１１２０）は、信号生成テーブルに記載されている生成条件に基づいて、異常信号を生成する。実施例２に係る異常信号生成は、ソフトウエアシステム又はハードウエアシステムからの元信号を用いずに、検証対象のシステムの状態に応じて新たな異常信号を生成する。実施例２は、元信号に依らずに、検証対象のシステムの状態に応じて異常信号を生成する点において実施例１の異常信号生成処理と異なる。ただし、実施例１に係る異常信号生成処理と同様に、実施例２に係る異常信号生成処理では、異常信号生成部は、信号生成テーブルにおいて記載される信号タイミングの条件、信号データの条件、及び/又は信号ＩＤの条件に従って異常信号を生成する。例えば、図３の信号生成テーブルを用いて一例を説明すると、信号転送部は、検証対象となるシステムの状態情報を取得した結果、検証対象となるシステムが「１０ナノ秒以内に信号なし」の状態であると検出した場合に、異常信号生成部は信号生成テーブルに記載されている通り、メモリアドレス０x１０１の内容を含み、出力信号IDが「６」の異常信号を生成する。
ここでは、異常信号の内容に関する条件および出力信号ＩＤに関する条件がある場合を一例として説明したが、本発明はこれに限定されず、異常信号のタイミングに関する条件など、他の条件に従って異常信号を生成することも可能である。異常信号の生成処理が終了すると、本処理はステップ３００６に進み、信号転送部は異常信号を検証対象となるシステムへと転送する。

ステップ３００４では、異常信号が検証対象となるシステムへと転送されると同時に、異常信号の影響を監視するデータログ（例えば、図１に示されるアプリのデータログ１２１３、スーパーバイザのデータログ１２１１、及びハイパーバイザのデータログ１１３０）が起動する。これらのデータログは、異常信号の各層における動作を監視し、動作結果を記録する診断プログラムであってもよい。例えば、これらのデータログは、アプリ又はスーパーバイザにおけるリソース使用率やI/O通信量等の変化、信号のタイミング、ハードウエアデバイスの温度、電圧、性能等の変化、異常信号の種類や所望の模擬故障に応じて、異常信号の影響を定量化するために様々なパラメータを記録してもよい。

ステップ３００５では、データログ分析部（例えば、図１に示されるデータログ分析部１４００）がデータログの情報、すなわち、アプリのデータログ１２１３、スーパーバイザのデータログ１２１１、及びハイパーバイザのデータログ１１３０の情報を取得する。上述したように、データログ分析部とは、それぞれのデータログに記録されている情報に基づいて、異常信号の影響を分析する機能部である。データログ分析部は、例えば、各層のデータログが起動する際に、それぞれのデータログの情報を継続的に取得してもよく、所定の期間（例えば１分）ごとに定期的にデータログの情報を取得してもよい。

ステップ３００６では、データログ分析部は、ステップ３００５で取得した各データログの情報を分析する。ここで、分析するとは、異常信号が各層（アプリ層、スーパーバイザ層、ハイパーバイザ層、ハードウエア層等）に与えた影響を評価するために、それぞれのデータログの情報を解析したり、データにおけるパターンや関係を特定したりすることを意味する。例えば、データログ分析部は、データログから取得したリソース使用率、信号のタイミング、ハードウエアデバイスの温度、電圧、性能等のパラメータを所定の閾値に比較することで、異常信号が送信先において故障を引き起こしたか否か、故障の大きさなどを定量化し、検証することができる。

以上の実施例１及び実施例２において説明した異常信号生成手段では、コストの高いシミュレーション手段の導入やハードウエアシステム及びソフトウエアシステムの変更を用いることなく、自動車に搭載されるシステムが故障した場合の影響を検証することができる。これにより、自動車に搭載されるシステムの耐故障性を検証するためのコスト（金銭的なコスト及びコンピュータリソースの使用率）を抑えることができ、また、ハイパーバイザを備える一般的なコンピュータで検証を行うことが可能となる。このため、耐故障性検証用のシステムの可用性が向上し、検証の効率が上がる効果が得られる。

変形例

以上、ソフトウエアシステム（アプリ、スーパーバイザ等）の状態を示す状態情報を用いて、当該ソフトウエアシステムを検証するための異常信号を生成する例を主に説明したが、本発明はこれに限定されず、ハードウエアシステムを特定の異常状態にする異常信号を生成する構成も可能である。

ハードウエアシステムを特定の異常状態にする異常信号を生成する具体例の一つとしては、映像撮影部、自動運転部、エンジンスロットル部、パワーステアリング部、テレマティクス部、ブレーキ制御部、及び先進運転支援部を搭載する自動車の場合が考えられる。このような自動車には、１つの機能部が故障した場合に、他の機能部がどのような影響を受けるかを検証するニーズがある。そこで、本発明に係る異常信号生成手段によれば、１つの機能部からの信号を、上述した信号生成テーブルに基づいて加工して生成した異常信号を他の機能部に転送することで、他の機能部が特定の異常状態になった場合の動作を検証することができる。

例えば、上述した自動車の場合、映像撮影部が取得した映像信号を加工して、映像の一部にノイズを導入した（映像の一部を消したり、ぼやかしたり、不鮮明な画像で置き換えたりする処理を施した）異常信号を他の車載機能部に転送することで、映像撮影部が故障した場合に、他の機能部がどう作動するか（例えば、テレマティクス部がどのタイミングで運転者に通知するか、自動運転部がマニュアル運転に切り替えるか、ブレーキ制御部がマニュアル運転に切り替えるか、エンジンスロットル部が自動車の加速を制御するか）を検証することができる。

また、ブレーキ制御部からテレマティクス部に送信されるブレーキ信号を異常信号に変換する（または異常のブレーキ信号を新たに生成する）ことで、テレマティクス部の反応速度（異常通知を運転者に知らせるまでの時間）を検証することができる。

以上、本発明の実施の形態について説明したが、本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。

１０００ ＥＣＵ
１１００ ハイパーバイザ
１１１０ 信号転送部
１１２０ 異常信号生成部
１１２１ 信号生成テーブル
１２００ 仮想化環境
１３００ 車両用電子制御装置
１４００ データログ分析部

Claims (11)

1. ハイパーバイザを含む車両用電子制御装置であって、
   前記ハイパーバイザは、
   異常信号生成部と、信号転送部とを備え、
   前記異常信号生成部は、
   信号生成に関する条件を定める信号生成テーブルに基づき、異常信号を生成し、
   前記信号転送部は、
   前記異常信号をテスト用実行環境に転送する、
   ことを特徴とする車両用電子制御装置。
2. 請求項１に記載の車両用電子制御装置において、
   前記異常信号生成部は、
   前記ハイパーバイザに連携しているソフトウエアシステムまたはハードウエアシステムから受信した元信号を、前記信号生成テーブルに基づいて加工することで、前記異常信号として生成する、
   ことを特徴とする車両用電子制御装置。
3. 請求項２に記載の車両用電子制御装置において、
   前記異常信号生成部は、前記元信号のデータ列の所定箇所を所定の値に置換することで、前記異常信号を生成する、
   ことを特徴とする車両用電子制御装置。
4. 請求項１に記載の車両用電子制御装置において、
   前記異常信号生成部は、
   前記ハイパーバイザに連携しているソフトウエアシステムまたはハードウエアシステムから取得するシステム状態を示す状態情報と、前記信号生成テーブルとに基づき、前記異常信号を生成する、
   ことを特徴とする車両用電子制御装置。
5. 請求項１に記載の車両用電子制御装置において、
   前記信号生成テーブルは、信号を識別する識別子と、信号のタイミングに関する信号タイミング条件と、信号のデータに関する信号データ条件と、が定められたテーブルである、
   ことを特徴とする車両用電子制御装置。
6. 請求項１に記載の車両用電子制御装置において、
   前記信号生成テーブルは、過去の異常データの分析に基づき、人工知能によって生成される、
   ことを特徴とする車両用電子制御装置。
7. 請求項１に記載の車両用電子制御装置において、
   前記ハイパーバイザは、第１の異常信号のテスト用実行環境における動作結果を記録するデータログを含み、
   前記異常信号生成部は、前記データログに記録される前記第１の異常信号の前記動作結果に応じて、第２の異常信号を生成する、
   ことを特徴とする車両用電子制御装置。
8. 請求項１に記載の車両用電子制御装置において、
   前記信号転送部は、
   前記ハイパーバイザに連携しているソフトウエアシステムまたはハードウエアシステムからの信号を受信し、
   前記信号に含まれる信号識別子が、前記信号生成テーブルに予め記録された信号識別子に一致する場合、
   前記異常信号生成部は、
   前記信号識別子を前記信号生成テーブルに基づいて変換することで前記異常信号を生成する、
   ことを特徴とする車両用電子制御装置。
9. 請求項１に記載の車両用電子制御装置において、
   前記異常信号生成部は、
   前記ハイパーバイザに連携しているソフトウエアシステムまたはハードウエアシステムから、当該システムのシステム状態を示す状態情報を取得し、
   前記状態情報に示される前記システム状態が、前記信号生成テーブルに予め記録されたシステム状態に一致する場合、
   前記信号生成テーブルに基づいて、前記異常信号を生成する、
   ことを特徴とする車両用電子制御装置。
10. ハイパーバイザを含む車両用電子制御装置における異常信号生成方法であって、
    前記ハイパーバイザは、
    異常信号生成部と、信号転送部とを備え、
    前記異常信号生成方法は、
    信号生成に関する条件を定める信号生成テーブルに基づき、異常信号を前記異常信号生成部によって生成する工程と、
    前記異常信号を前記信号転送部によってテスト用実行環境に転送する工程と、
    を含む異常信号生成方法。
11. ハイパーバイザを含む車両用電子制御装置における異常信号生成プログラムであって、
    前記ハイパーバイザは、
    異常信号生成部と、信号転送部とを備え、
    前記異常信号生成プログラムは、
    信号生成に関する条件を定める信号生成テーブルに基づき、異常信号を前記異常信号生成部によって生成する手順と、
    前記異常信号を前記信号転送部によってテスト用実行環境に転送する手順と、
    を前記車両用電子制御装置に実行させるための異常信号生成プログラム。

Images