(57)【要約】      （修正有）【課題】複数のＥＣＵを備える車両においてＥＣＵの故障に起因する不具合の発生を低減する。【解決手段】車両システムは、配設された複数のアプリに応じた制御を実行可能な複数のＥＣＵ（２１０，２２０，２３０）と、複数のＥＣＵの各々について、故障に関するパラメータを取得する第１取得手段と、複数のアプリの各々について、当該アプリの停止に起因して発生し得る不具合の度合いを示すリスクランクを取得する第２取得手段と、故障に関するパラメータ及びリスクランクに基づいて、複数のアプリのうち少なくとも１つの対象アプリを、対象アプリが配設されたＥＣＵとは異なるＥＣＵに移動させるべきか否かを判定する判定手段と、対象アプリを移動させるべきと判定された場合に、対象アプリを、対象アプリが配設されたＥＣＵとは異なるＥＣＵに移動させる移動手段とを備える。【選択図】図１
2018099972.tif 000002
【特許請求の範囲】
【請求項１】
配設された複数のアプリに応じた制御を実行可能な複数のＥＣＵと、
前記複数のＥＣＵの各々について、故障に関するパラメータを取得する第１取得手段と、
前記複数のアプリの各々について、当該アプリの停止に起因して発生し得る不具合の度合いを示すリスクランクを取得する第２取得手段と、
前記故障に関するパラメータ及び前記リスクランクに基づいて、前記複数のアプリのうち少なくとも１つの対象アプリを、前記対象アプリが配設されたＥＣＵとは異なるＥＣＵに移動させるべきか否かを判定する判定手段と、
前記対象アプリを移動させるべきと判定された場合に、前記対象アプリを、前記対象アプリが配設されたＥＣＵとは異なるＥＣＵに移動させる移動手段と
を備える車両システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載される複数のＥＣＵ（Electronic Control Unit）にアプリを配置する車両システムの技術分野に関する。
【背景技術】
【０００２】
相互に通信可能とされた複数の電子制御ユニット（ＥＣＵ）を備える車両が知られている。このような車両には、各ＥＣＵの故障による不具合の発生を回避するために、ＥＣＵの故障を検出する機能が備えられる場合がある。例えば特許文献１では、ＥＣＵ間のメッセージの応答時間に基づいて、ＥＣＵの故障を予測するという技術が開示されている。その他にも、特許文献２から４では、車両に関連する故障を検出するための技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−１４７５５５号公報
【特許文献２】特開２０１２−４７５９号公報
【特許文献３】特開２０１１−５８５１０号公報
【特許文献４】特開２００４−２７２３７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
複数のＥＣＵを備える車両では、各ＥＣＵにアプリが配置されることにより特定の機能が実現されが、ＥＣＵが故障してしまうと、アプリに応じた機能を発揮することができなくなってしまう。この際、走行性能に大きく寄与するアプリの機能が停止すると、運転者に違和感を与えてしまうおそれがある。
【０００５】
上述した特許文献１に記載の技術では、ＥＣＵの故障の発生が予測できるとされているものの、その後の処理（つまり、故障への対応）については何ら言及されていない。このため、仮にＥＣＵの故障が予測できたとしても、故障に起因する不具合の発生を防止することはできないという技術的問題点が生ずる。
【０００６】
本発明は、上記問題点に鑑みてなされたものであり、複数のＥＣＵを備える車両においてＥＣＵの故障に起因する不具合の発生を低減することが可能な車両システムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
本発明の車両システムは上記課題を解決するために、配設された複数のアプリに応じた制御を実行可能な複数のＥＣＵと、前記複数のＥＣＵの各々について、故障に関するパラメータを取得する第１取得手段と、前記複数のアプリの各々について、当該アプリの停止に起因して発生し得る不具合の度合いを示すリスクランクを取得する第２取得手段と、前記故障に関するパラメータ及び前記リスクランクに基づいて、前記複数のアプリのうち少なくとも１つの対象アプリを、前記対象アプリが配設されたＥＣＵとは異なるＥＣＵに移動させるべきか否かを判定する判定手段と、前記対象アプリを移動させるべきと判定された場合に、前記対象アプリを、前記対象アプリが配設されたＥＣＵとは異なるＥＣＵに移動させる移動手段とを備える。
【０００８】
本発明の車両システムによれば、ＥＣＵの故障に関するパラメータと、アプリのリスクランクに基づいて、アプリを他のＥＣＵに移動させるべきか否かが判定される。このため、単にＥＣＵの故障に関するパラメータに応じてアプリを移動させるべきか判定する場合と比べると、アプリが停止した場合に発生し得る不具合を考慮した適切な判定を行うことができる。よって、仮にＥＣＵに故障が発生した場合であっても、アプリの停止により大きな不具合が発生してしまうことを抑制できる。
【０００９】
本発明の作用及び他の利得は次に説明する実施するための形態から明らかにされる。
【図面の簡単な説明】
【００１０】
【図１】実施形態に係る車両システムの構成を示すブロック図である。
【図２】実施形態に係る車両システムの動作の流れを示すフローチャートである。
【図３】劣化判定指数と故障予測数との関係を示すグラフである。
【図４】劣化判定指数と故障発生確率との関係を示すグラフである。
【図５】アプリのリスクランクと許容故障確率との関係を示す表である。
【図６】アプリ移動処理時の動作の一例を示す概念図（その１）である。
【図７】アプリ移動処理時の動作の一例を示す概念図（その２）である。
【図８】アプリ移動処理時の動作の一例を示す概念図（その３）である。
【図９】アプリ移動処理時の動作の一例を示す概念図（その４）である。
【図１０】アプリ移動処理時の動作の一例を示す概念図（その５）である。
【図１１】アプリ移動処理時の動作の一例を示す概念図（その６）である。
【図１２】アプリ移動処理時の動作の一例を示す概念図（その７）である。
【発明を実施するための形態】
【００１１】
本発明の車両システムに係る実施形態を図面に基づいて説明する。
【００１２】
＜車両システムの構成＞
まず、本実施形態に係る車両システムの構成について、図１を参照して説明する。図１は、実施形態に係る車両システムの構成を示すブロック図である。
【００１３】
図１に示すように、本実施形態に係る車両システムは、自動車等の車両に搭載されるものであり、統合制御ＥＣＵ１００と、第１ＥＣＵ２１０と、第２ＥＣＵ２２０と、第３ＥＣＵ２３０とを備えて構成されている。ただし、統合制御ＥＣＵ１００は必須な構成要素ではない。
【００１４】
統合制御ＥＣＵ１００は、ＣＰＵ（Central Processing Unit）等の演算回路を有する制御ユニットである。統合制御ＥＣＵ１００は、第１ＥＣＵ２１０、第２ＥＣＵ２２０、及び第３ＥＣＵ２３０（以下では、これらをまとめて「ＥＣＵ２００」と称することがある）と通信可能に構成されており、ＥＣＵ２００の各々の制御（状態管理を含む）を実行可能に構成されている。
【００１５】
第１ＥＣＵ２１０、第２ＥＣＵ２２０、及び第３ＥＣＵ２３０は、互いに通信可能に接続されている。ＥＣＵ２００は、その内部にアプリが配置されることで、該アプリに応じた処理を実行可能な制御ユニットである。なお、ＥＣＵ２００の数は２つ以上であればよく、本実施形態のように３つに限定されるものではない。
【００１６】
＜車両システムの動作＞
次に、本実施形態に係る車両システムの動作について、図２を参照して説明する。図２は、実施形態に係る車両システムの動作の流れを示すフローチャートである。
【００１７】
図２に示すように、本実施形態に係る車両システムの動作時には、まずＥＣＵ２００内に配置されているアプリの個数ｎが取得される（ステップＳ１０１）。
【００１８】
続いて、劣化判定指数Ｒが取得される（ステップＳ１０２）。劣化判定指数Ｒとは、ＥＣＵ２００の各々の劣化度合いを示すパラメータであり、ＥＣＵ２００のハード仕様や搭載環境から求めることができる。劣化判定指数Ｒの具体例としては、ハンダ部が劣化する要因となるサーマルショック回数や、コンデンサの熱によるドライアップを推測可能な積算温度等が挙げられる。劣化判定指数Ｒは、例えばＥＣＵ２００が有するメモリ等に記憶されている。
【００１９】
続いて、劣化判定指数ＲからＥＣＵ２００の故障確率Ｊが算出される（ステップＳ１０３）。以下では、故障確率Ｊの算出方法について、図３及び図４を参照して詳細に説明する。図３は、劣化判定指数Ｒと故障予測数との関係を示すグラフである。また図４は、劣化判定指数Ｒと故障発生確率Ｊとの関係を示すグラフである。
【００２０】
図３に示すように、ＥＣＵ２００における劣化判定指数Ｒと故障予測数との関係は、劣化による寿命故障を前提とすれば、正規分布に近いものとなる。図３に示す例でも、耐久性の異なる複数のＥＣＵ２００（廉価版、通常版、高耐久性版）について、それぞれ正規分布となっていることが分かる。
【００２１】
図４に示すように、故障確率Ｊは、劣化判定指数Ｒが正規分布となる場合、評価結果や過去の同様のＥＣＵ２００の故障実績等から、最小二乗法で近似式を算出して決定することができる。ただし、このような故障確率Ｊの算出方法は、あくまで一例であり、他の手法を利用して故障確率Ｊを算出するようにしてもよい。
【００２２】
以上のような故障確率Ｊの算出までの処理は、統合制御ＥＣＵ１００で実行されてもよいし、ＥＣＵ２００の各々で実行されてもよい。
【００２３】
図２に戻り、ＥＣＵ２００の各々について故障確率Ｊが算出されると、以降の処理が、アプリの個数ｎに応じた回数だけループされる。即ち、ＥＣＵ２００に配置された複数のアプリの各々について、繰り返し処理が実行される。
【００２４】
まずは、アプリのサイズＳｉｚｅ［ｉ］が取得される（ステップＳ１０４）。続いて、アプリ毎に設定されたリスクランクから許容故障確率Ｃ［ｉ］が取得される（ステップＳ１０５）。以下では、アプリのリスクランクと許容故障隔離Ｃ［ｉ］との関係について、図５を参照して説明する。図５は、アプリのリスクランクと許容故障確率との関係を示す表である。
【００２５】
図５に示すように、リスクランクは、アプリの重要度に応じて決定される。リスクランクは、１〜９の９段階で表される値であり、アプリの重要度が高いほど大きい値となる。なお、ここでの「重要度」とは、アプリの実行する制御の重要性を示す値であり、本実施形態ではアプリが正常に動作しなくなった場合に発生し得る不都合の影響度が用いられている。
【００２６】
具体的には、動作不良により重大事故の可能性があるアプリのリスクランクは“９”である。動作不良により軽少事故の可能性があるアプリのリスクランクは“８”である。動作不良によりイレギュラーな事態が発生しユーザが不満を感じるアプリのリスクランクは“７”である。動作不良により車両の走行機能が少なくとも部分的に停止しユーザが不満を感じるアプリのリスクランクは“６”である。動作不良により車両の走行性能が低下、又は付加機能が停止してユーザが不満を感じるアプリのリスクランクは“５”である。動作不良により便利機能の不具合が発生する、又は多数のユーザが不快に感じるアプリのリスクランクは“４”である。動作不良により少数のユーザが不快に感じるアプリのリスクランクは“３”である。動作不良によりごく少数のユーザが不快に感じるアプリのリスクランクは“２”である。動作不良による影響が無視できるアプリのリスクランクは“１”である。
【００２７】
上述したリスクランクには、そのランクに対応した許容故障確率Ｃ［ｉ］が設定されている。許容故障確率Ｃ［ｉ］は、そのアプリが故障確率Ｊをどの程度まで許容できるかを示す値であり、リスクランクが高い程、許容できる故障確率が低く設定されている。このため、アプリのリスクランクが分かれば、その値から許容故障確率Ｃ［ｉ］を算出することができる。なお、リスクランクは、予め設定されるものではなく、外部から取得されるようなものであってもよいし、過去のデータから学習されるものであってもよい。また、アプリによっては、リスクランクではなく許容故障確率Ｃ［ｉ］をそのまま処理に用いてもよい。
【００２８】
再び図２に戻り、許容故障確率Ｃ［ｉ］が算出されると、故障確率Ｊ［ｉ］が許容故障確率Ｃ［ｉ］以下であるか否かが判定される（ステップＳ１０６）。即ち、現在アプリが配置されているＥＣＵ２００の故障確率Ｊ［ｉ］が、そのアプリの許容故障確率Ｃ［ｉ］を満たしているか否かが判定される。
【００２９】
故障確率Ｊ［ｉ］が許容故障確率Ｃ［ｉ］以下である場合には（ステップＳ１０６：ＹＥＳ）、ＥＣＵ２００の故障確率Ｊ［ｉ］が、そのアプリの許容故障確率Ｃ［ｉ］を満たしていると判断できるため、以降の処理は省略される。一方で、故障確率Ｊ［ｉ］が許容故障確率Ｃ［ｉ］以下でない場合には（ステップＳ１０６：ＮＯ）、ＥＣＵ２００の故障確率Ｊ［ｉ］が、そのアプリの許容故障確率Ｃ［ｉ］を満たしていないと判断できるため、アプリを現在のＥＣＵ２００から他のＥＣＵ２００に移動すべきと判定し、ステップＳ１０７以降の処理を実行する。
【００３０】
まずは、ＥＣＵ２００間の通信線を利用して、自ＥＣＵ（即ち、対象となるｉ番目のアプリが現在配置されているＥＣＵ２００）の故障確率Ｊ［ｉ］と、アプリの許容故障確率Ｃ［ｉ］とが、他のＥＣＵ（即ち、対象となるｉ番目のアプリが配置されていないＥＣＵ２００）に出力される（ステップＳ１０７）。
【００３１】
自ＥＣＵ２００からの出力を受信した他のＥＣＵ２００は、アドレスＡｄｒｅｓｓ［ｊ］と、故障確率Ｒ［ｊ］と、空きスペースＦ［ｊ］と、許容故障確率がＣ［ｉ］よりも低いアプリの容量合計Ｓ［ｊ］とを取得し出力する。これらの情報は、自ＥＣＵ２００に入力される（ステップＳ１０８）。
【００３２】
続いて、対象アプリのサイズＳｉｚｅ［ｉ］が、他のＥＣＵ２００における最大の空きスペースＭＡＸ（Ｆ）以下であるか否かが判定される（ステップＳ１０９）。対象アプリのサイズＳｉｚｅ［ｉ］が、他のＥＣＵ２００における最大の空きスペースＭＡＸ（Ｆ）以下である場合（ステップＳ１０９：ＹＥＳ）、対象アプリを他のＥＣＵ２００に移動可能と判断できる。
【００３３】
続いて、自ＥＣＵ２００の許容故障確率Ｃ［ｉ］と、他のＥＣＵ２００の故障確率Ｊ［ｊ］との差が所定値以下であるか否かが判定される（ステップＳ１１０）。即ち、移動先候補である他のＥＣＵ２００の故障確率Ｊ［ｊ］が、自ＥＣＵ２００の許容故障確率Ｃ［ｉ］よりも所定値以上小さいか否かが判定される。なお、所定値は、判定時のマージンとして予め設定される値である。
【００３４】
自ＥＣＵ２００の許容故障確率Ｃ［ｉ］と、他のＥＣＵ２００の故障確率Ｊ［ｊ］との差が所定値以下であると判定された場合（ステップＳ１１０：ＹＥＳ）、仮にアプリを移動しても許容故障確率Ｃ［ｉ］が満たされないと判断し、アプリの移動を実行せずに一連の処理が終了する。一方で、自ＥＣＵ２００の許容故障確率Ｃ［ｉ］と、他のＥＣＵ２００の故障確率Ｊ［ｊ］との差が所定値以下でないと判定された場合（ステップＳ１１０：ＮＯ）、アプリの移動によって許容故障確率Ｃ［ｉ］が満たされると判断し、対象アプリが自ＥＣＵ２００から他のＥＣＵ２００に移動される。具体的には、対象アプリを他のＥＣＵ２００の空きスペースにコピーすると共に（ステップＳ１１１）、自ＥＣＵ２００から対象アプリが削除される（ステップＳ１１２）。
【００３５】
他方で、対象アプリのサイズＳｉｚｅ［ｉ］が、他のＥＣＵ２００における最大の空きスペースＭＡＸ（Ｆ）以下でない場合（ステップＳ１０９：ＮＯ）、このままでは対象アプリを他のＥＣＵ２００に移動できないと判断できる。この場合には、他のＥＣＵ２００に配置されている他のアプリを削除することで、対象アプリを移動できるようにならないか検証される。具体的には、対象アプリのサイズＳｉｚｅ［ｉ］が、他のＥＣＵ２００における最大の空きスペースＭＡＸ（Ｆ）に、他のＥＣＵにおける許容故障確率がＣ［ｉ］よりも高いアプリの容量合計Ｓ［ｊ］を加えた値（即ち、ＭＡＸ（Ｆ＋Ｓ））以下であるか否かが判定される（ステップＳ１１３）。
【００３６】
サイズＳｉｚｅ［ｉ］がＭＡＸ（Ｆ＋Ｓ）以下であると判定された場合（ステップＳ１１３：ＹＥＳ）、他のＥＣＵ２００に配置されているアプリを移動させれば、自ＥＣＵ２００の対象アプリを他のＥＣＵ２００に移動できるようになると判断できる。このため、他のＥＣＵ２００に配置されているアプリが一時的にバッファへ退避され（ステップＳ１１４）、自ＥＣＵ２００の対象アプリが空きスペースの増加した他のＥＣＵ２００にコピーされる（ステップＳ１１５）。なお、サイズＳｉｚｅ［ｉ］がＭＡＸ（Ｆ＋Ｓ）以下でないと判定された場合（ステップＳ１１３：ＮＯ）、他のＥＣＵ２００に配置されているアプリを移動させても、自ＥＣＵ２００の対象アプリを他のＥＣＵ２００に移動できるようにはならいと判断できる。このため、対象アプリの移動は実行されず処理が終了する。
【００３７】
＜アプリ移動処理の具体例＞
次に、上述した処理によってアプリが移動される場合の具体的な動作について、図６から図１２を参照して説明する。図６から図１２は夫々、アプリ移動処理時の動作の一例を示す概念図である。
【００３８】
図６に示すように、第１ＥＣＵ２１０に、アプリＡ、アプリＢ及びアプリＣが配置されており、第２ＥＣＵ２２０に、アプリＤ、アプリＥ及びアプリＦが配置されており、第３ＥＣＵ２３０に、アプリＧ及びアプリＨが配置されている例を考える。なお、アプリＡの許容故障確率Ｃは７０％、アプリＢの許容故障確率Ｃは７５％、アプリＣの許容故障確率Ｃは８０％、アプリＤの許容故障確率Ｃは５５％、アプリＥの許容故障確率Ｃは５０％、アプリＦの許容故障確率Ｃは９０％、アプリＧの許容故障確率Ｃは７５％、アプリＨの許容故障確率Ｃは７５％であるとする。また、現時点における第１ＥＣＵ２１０の故障確率Ｊは７０％、第２ＥＣＵ２２０の故障確率Ｊは３０％、第３ＥＣＵ２３０の故障確率Ｊは３２％であるとする。
【００３９】
図７に示すように、第１ＥＣＵ２１０の劣化具合（即ち、故障確率Ｊ）が７１％に進行したことにより、アプリＡの許容故障確率７０％が満たされなくなる。よって、アプリＡが移動の対象アプリとして処理が開始される。第１ＥＣＵ２１０は、まず自身の劣化具合情報である７１％と、対象アプリＡの許容故障率７０％を、第２ＥＣＵ２２０及び第３ＥＣＵ２３０に出力する。この結果、第２ＥＣＵ２２０からは、空きサイズ１０ＫＢ、及びアプリＡの許容故障確率Ｃよりも高いアプリＢのサイズ１０ＫＢを示す情報が送られてくる。また、第３ＥＣＵ２３０からは、空きサイズ１５ＫＢを示す情報が送られてくる。
【００４０】
図８に示すように、上述した情報を受信した結果、空きスペースの最大サイズが第３ＥＣＵ２３０の１５ＫＢであるため、アプリＡは第３ＥＣＵ２３０に移動可能であると判定され、実際に第３ＥＣＵ２３０へと移動される。第３ＥＣＵの故障確率Ｊは３２％であるため、アプリＡの許容故障確率Ｃ７０％は満たされる。
【００４１】
図９に示すように、第１ＥＣＵ２１０の故障確率Ｊが更に７５％まで進行すると、次はアプリＢの許容故障確率７５％が満たされなくなる。よって、この場合はアプリＢが移動の対象アプリとして処理が開始される。第１ＥＣＵ２１０は、まず自身の劣化具合情報である７６％と、対象アプリＢの許容故障率７５％を、第２ＥＣＵ２２０及び第３ＥＣＵ２３０に出力する。この結果、第２ＥＣＵ２２０からは、空きサイズ１０ＫＢ、及びアプリＢの許容故障確率Ｃよりも高いアプリＦのサイズ１０ＫＢを示す情報が送られてくる。また、第３ＥＣＵ２３０からは、空きサイズ５ＫＢを示す情報が送られてくる。
【００４２】
図１０に示すように、上述した情報を受信した結果、第２ＥＣＵ２２０における空きスペースのサイズとアプリＦとの合計値２０ＫＢなので、アプリＢとアプリＦとの入れ替えが実行される。第２ＥＣＵの故障確率Ｊは３１％であるため、アプリＢの許容故障確率Ｃ７５％は満たされる。また、第１ＥＣＵの故障確率Ｊは７６％であるため、アプリＦの許容故障確率Ｃ９０％は満たされる。
【００４３】
図１１に示すように、第１ＥＣＵ２１０の故障確率Ｊが更に８１％まで進行すると、次はアプリＣの許容故障確率８０％が満たされなくなる。よって、この場合はアプリＣが移動の対象アプリとして処理が開始される。第１ＥＣＵ２１０は、まず自身の劣化具合情報である８１％と、対象アプリＣの許容故障率８０％を、第２ＥＣＵ２２０及び第３ＥＣＵ２３０に出力する。この結果、第２ＥＣＵ２２０からは、空きサイズ５ＫＢを示す情報が送られてくる。また、第３ＥＣＵ２３０からは、空きサイズ５ＫＢを示す情報が送られてくる。
【００４４】
図１２に示すように、上述した情報を受信した結果、アプリＣは、第２ＥＣＵ２２０及び第３ＥＣＵ２３０のいずれにも移動することができず、また他のアプリとの入れ替えもできないと判断される。よって、この場合はアプリＣの移動が実行されないまま処理が終了する。
【００４５】
＜実施形態の効果＞
以上説明したように、本実施形態に係る車両システムによれば、ＥＣＵ２００の故障確率Ｊの上昇によって許容故障確率Ｃを満たさなくなったアプリが、他のＥＣＵに移動可能であるか否かが判定され、移動可能である場合（具体的には、移動先のＥＣＵ２００に十分な空きスペースが存在し、且つ移動後に許容故障確率Ｃが満たされる場合）に、他のＥＣＵ２００へと移動される。
【００４６】
上述したように複数のＥＣＵ２００間でアプリを移動させれば、アプリの許容故障確率Ｃを好適に満たし続けることが可能となり、結果としてアプリ停止による不具合の発生を抑制することができる。また、許容故障確率Ｃが低い（言い換えれば、停止することで大きな不具合に繋がる可能性が高いアプリ）が優先的に移動されることになるため、アプリ停止による不具合の発生を好適に防止することができる。
【００４７】
本発明は、上述した実施形態に限られるものではなく、特許請求の範囲及び明細書全体から読み取れる発明の要旨或いは思想に反しない範囲で適宜変更可能であり、そのような変更を伴う車両システムもまた本発明の技術的範囲に含まれるものである。
【符号の説明】
【００４８】
１００  統合制御ＥＣＵ
２１０  第１ＥＣＵ
２２０  第２ＥＣＵ
２３０  第３ＥＣＵ
Ｒ  劣化判定指数
Ｊ  故障確率
Ｃ  許容故障確率
【図１】
2018099972.tif 000003
【図２】
2018099972.tif 000004
【図３】
2018099972.tif 000005
【図４】
2018099972.tif 000006
【図５】
2018099972.tif 000007
【図６】
2018099972.tif 000008
【図７】
2018099972.tif 000009
【図８】
2018099972.tif 000010
【図９】
2018099972.tif 000011
【図１０】
2018099972.tif 000012
【図１１】
2018099972.tif 000013
【図１２】
2018099972.tif 000014