特許 7588213 車両制御装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-13

(45)【発行日】2024-11-21

(54)【発明の名称】車両制御装置

(51)【国際特許分類】

   G06F 11/14 20060101AFI20241114BHJP

   B60W 50/023 20120101ALI20241114BHJP

【ＦＩ】

G06F11/14 641

B60W50/023

【請求項の数】 5

(21)【出願番号】P 2023508440

(86)(22)【出願日】2021-09-27

(86)【国際出願番号】 JP2021035372

(87)【国際公開番号】W WO2022201597

(87)【国際公開日】2022-09-29

【審査請求日】2023-08-25

(31)【優先権主張番号】P 2021046953

(32)【優先日】2021-03-22

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】509186579

【氏名又は名称】日立Ａｓｔｅｍｏ株式会社

(74)【代理人】

【識別番号】110002572

【氏名又は名称】弁理士法人平木国際特許事務所

(72)【発明者】

【氏名】蛯名 朋仁

【審査官】田中 幸雄

(56)【参考文献】

【文献】特開２００８－３０５３１７（ＪＰ，Ａ）

【文献】特開２０１３－５４４３４（ＪＰ，Ａ）

【文献】特開２０１８－９２５７１（ＪＰ，Ａ）

【文献】国際公開第２０１７／０２２３６４（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １１／１４

Ｂ６０Ｗ ５０／０２３

(57)【特許請求の範囲】

【請求項1】

第１コアと第２コアとを少なくとも有するマルチコアＣＰＵと、
各コアがアクセス可能に構成され、少なくとも通信パラメータを保存する共有データメモリと、
前記マルチコアＣＰＵの動作を監視するとともに前記マルチコアＣＰＵにリセット信号を出力する監視部と、
を備え、
前記第２コアは、リセット解除から前記第１コアによるＯＳ初期化完了までの間に、前記共有データメモリにアクセスして通信パラメータの確認を行い、前記共有データメモリに保存される通信パラメータに基づいて外部との通信を行うことを特徴とする車両制御装置。

【請求項2】

前記共有データメモリには、リセット前の現在使用中の通信パラメータが保存され、
前記第２コアは、前記共有データメモリに保存される現在使用中の通信パラメータに基づいて外部との通信を行う請求項１に記載の車両制御装置。

【請求項3】

前記共有データメモリには、通信を行うプログラムが更に保存されている請求項１又は２に記載の車両制御装置。

【請求項4】

前記共有データメモリには、スクリプトを解釈して実行するプログラムが更に保存されている請求項１又は２に記載の車両制御装置。

【請求項5】

前記共有データメモリには、通信パラメータのデフォルト値が更に保存され、
予期せぬ異常によってリセットされた場合に、前記第２コアは前記デフォルト値に基づいて外部との通信を行う請求項１～４のいずれか一項に記載の車両制御装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両制御装置に関し、特にマルチコアＣＰＵを備える車両制御装置に関する。
本願は、２０２１年３月２２日に出願された日本国特願２０２１－０４６９５３号に基づき優先権を主張し、その内容をここに援用する。

【背景技術】

【0002】

近年、自動車等の車両において、エンジン制御、ブレーキ制御、トランスミッション制御、ドア制御、エアコン制御等を行うために複数のＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ、すなわち車両制御装置）が搭載されている。これらのＥＣＵは、車載ネットワークを介して互いに通信し協働することにより、車両の安全走行等を実現している。

【0003】

ＥＣＵは、複数のコアを有するマルチコアＣＰＵを備える場合がある。マルチコアＣＰＵでは、一般的に、いずれかのコアに異常が生じた場合、異常状態から回復させるべくマルチコアＣＰＵ全体のリセットが行われる。しかし、マルチコアＣＰＵ全体がリセットされると、リセット解除からＯＳ初期化完了までの間に通信が途絶する問題がある。また、通信途絶によって、他のＥＣＵからは異常であると判定されてしまう。

【0004】

このような問題を解決するため、例えば下記特許文献１に記載のように、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）を使用してリセット解除からＯＳ初期化完了までの時間を短縮する技術が検討されている。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１３-２４６４９５号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかし、上記特許文献１に記載の技術では、リセット解除からＯＳ初期化完了までの時間を短縮できるが、改善余地があった。

【0007】

本発明は、このような技術課題を解決するためになされたものであって、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止できる車両制御装置を提供することを目的とする。

【課題を解決するための手段】

【0008】

本発明に係る車両制御装置は、第１コアと第２コアとを少なくとも有するマルチコアＣＰＵと、各コアがアクセス可能に構成され、少なくとも通信パラメータを保存する共有データメモリと、前記マルチコアＣＰＵの動作を監視するとともに前記マルチコアＣＰＵにリセット信号を出力する監視回路と、を備え、前記第２コアは、リセット解除から前記第１コアによるＯＳ初期化完了までの間に、前記共有データメモリにアクセスして通信パラメータの確認を行い、前記共有データメモリに保存される通信パラメータに基づいて外部との通信を行うことを特徴としている。

【0009】

本発明に係る車両制御装置では、第２コアは、リセット解除から第１コアによるＯＳ初期化完了までの間に、共有データメモリにアクセスして通信パラメータの確認を行い、共有データメモリに保存される通信パラメータに基づいて外部との通信を行うので、ＯＳ初期化の完了を待たずに通信が可能となる。その結果、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止することができる。

【発明の効果】

【0010】

本発明によれば、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止することができる。

【図面の簡単な説明】

【0011】

【図1】第１実施形態に係る車両制御装置を備えた車両制御システムを示す構成図である。

【図2】第１実施形態に係る車両制御装置のリセット解除後の制御を示すシーケンス図である。

【図3】第２実施形態に係る車両制御装置のリセット前後の制御を示すシーケンス図である。

【図4】第３実施形態に係る車両制御装置のリセット前後の制御を示すシーケンス図である。

【発明を実施するための形態】

【0012】

以下、図面を参照して本発明に係る車両制御装置の実施形態について説明する。

【0013】

[第１実施形態]
図１は第１実施形態に係る車両制御装置を備えた車両制御システムを示す構成図である。本実施形態の車両制御装置１０は、ＥＣＵにより構成され、他の複数のＥＣＵ（ＥＣＵ２０、ＥＣＵ３０）とともに車両制御システムを形成する。ここでは、例えば車両制御装置１０はエンジン制御を担当し、ＥＣＵ２０はブレーキ制御を担当し、ＥＣＵ３０はトランスミッション制御を担当する。そして、車両制御装置１０、ＥＣＵ２０及びＥＣＵ３０は、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の車載ネットワーク１５により接続され、該車載ネットワーク１５で通信を行い協働することで、車両の安全走行等を実現している。

【0014】

図１に示すように、車両制御装置１０は主に、マルチコアＣＰＵ１１と、マルチコアＣＰＵ１１の動作を監視する監視ＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）１２とを備えている。

【0015】

マルチコアＣＰＵ１１は、複数のコア（第１コア１１１－１，第２コア１１１－２，…第ｎコア１１１－ｎ）と、複数のコアに対して１対１に設けられたプログラムメモリ（プログラムメモリ１１２－１，プログラムメモリ１１２－２，…プログラムメモリ１１２－ｎ）及びデータメモリ（データメモリ１１３－１，データメモリ１１３－２，…データメモリ１１３－ｎ）とを有する。各プログラムメモリ及び各データメモリは、対応するコアの機能を果たすためのプログラム及びデータを保存する。なお、ｎは２以上の自然数である。

【0016】

本実施形態において、第１コア１１１－１に対応するプログラムメモリ１１２－１には、リセット解除後に実行するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の初期化に関する初期化プログラムと、第１コア１１１－１に割り当てられた処理を行うためのアプリケーションソフトウェア（以下では、単に「アプリケーション」という）とが保存されている。第２コア１１１－２に対応するプログラムメモリ１１２－２には、リセット解除後に実行する通信処理に関する通信プログラムと、第２コア１１１－２に割り当てられた処理を行うためのアプリケーションとが保存されている。

【0017】

監視ＩＣ１２は、特許請求の範囲に記載の「監視部」に相当するものであり、マルチコアＣＰＵ１１から出力される信号１３に基づいて、マルチコアＣＰＵ１１が正常に動作しているか否かを監視する。また、監視ＩＣ１２は、信号１３が途絶した場合、マルチコアＣＰＵ１１に異常が発生しているものとしてリセット信号１４をマルチコアＣＰＵ１１に出力し、マルチコアＣＰＵ１１をリセットさせることができる。更に、電源投入（言い換えれば、電源ＯＮ）直後の場合、電源電圧が低電圧であるため、監視ＩＣ１２はリセット信号１４をマルチコアＣＰＵ１１に出力し、マルチコアＣＰＵ１１をリセットさせることができる。そして、電源電圧が安定した後、監視ＩＣ１２はリセット信号１４の出力を停止する。これによって、マルチコアＣＰＵ１１のリセットが解除され、マルチコアＣＰＵ１１が動作を開始する。

【0018】

マルチコアＣＰＵ１１は、各コアがアクセスできる共有データメモリ１１５と、各コアと接続される通信デバイス１１４とを更に備えている。各コアは、バス１１６を介して通信デバイス１１４及び共有データメモリ１１５とそれぞれ接続されている。共有データメモリ１１５には、コア間で共有する通信パラメータ等のデータが保存されている。通信パラメータとしては、通信速度、データサイズ及び送信周期等が挙げられる。

【0019】

マルチコアＣＰＵ１１は、一つのＩＣで構成されても良く、複数のＩＣで構成されても良い。また、監視ＩＣ１２は、必ずしもマルチコアＣＰＵ１１から独立して設ける必要がなく、該監視ＩＣ１２に相当する監視機能をマルチコアＣＰＵ１１に組み込むようにしても良い。

【0020】

このように構成された車両制御装置１０では、ＯＳを搭載しており、各制御処理に関するプログラムはＯＳの管理下で動作する。そして、異常等の原因でマルチコアＣＰＵ１１がリセットされた場合、ＯＳは、リセット解除後に初期化処理を行う。ＯＳの初期化処理では、ＯＳはデバイスの初期化及びアプリケーションの初期化を行い、更にアプリケーションの実行を行う。

【0021】

そして、複数のコアを有するマルチコアＣＰＵ１１では、初期化の一貫性を保つために、１つのコアにより初期化を実行するようになっている。上述したように、第１コア１１１－１に対応するプログラムメモリ１１２－１には、リセット解除後に実行するＯＳの初期化に関する初期化プログラムが保存されているので、従って、第１コア１１１－１はリセット解除後のＯＳ初期化処理を行う。

【0022】

一方、第２コア１１１－２に対応するプログラムメモリ１１２－２には、リセット解除後に実行する通信処理に関する通信プログラムが保存されているので、第２コア１１１－２はリセット解除後の通信処理を行う。その際に、第２コア１１１－２は、リセット解除後に実行する通信プログラムによって、共有データメモリ１１５にアクセスして通信パラメータの確認を行い、更に共有データメモリ１１５に保存される通信パラメータに基づいて外部との通信を行う。なお、第２コア１１１－２の通信処理は、第１コア１１１－１によるＯＳの初期化処理と並行して実行される。

【0023】

そして、第１コア１１１－１によるＯＳ初期化処理が完了し、第１コア１１１－１におけるアプリケーションの起動した時点で、通信の切り替えが行われる。すなわち、第２コア１１１－２の通信プログラムが停止し、第１コア１１１－１が主導する通信処理を開始する。

【0024】

以下、図２を基に車両制御装置１０におけるリセット解除後の制御を説明する。ここでは、電源ＯＮによるリセットの解除から、ＯＳの初期化、通信、アプリケーション実行といった一連の処理の例を挙げて説明する。なお、図２において、ステップＳ２１１～Ｓ２１４は第１コア１１１－１により行われる処理であり、ステップＳ２２１～Ｓ２２５は第２コア１１１－２により行われる処理である。

【0025】

図２に示すように、電源ＯＮによるリセット解除後、第１コア１１１－１は、まずＯＳを起動し（ステップＳ２１１）、次にＯＳの初期化処理を行う（ステップＳ２１２）。このとき、第２コア１１１－２は、第１コア１１１－１の処理と並行して各処理を行う。

【0026】

具体的には、第２コア１１１－２は、まず共有データメモリ１１５にアクセスし、通信パラメータの確認を行う（ステップＳ２２１）。本ステップにおける通信パラメータの確認は、共有データメモリ１１５に正常な通信パラメータが設定されているか否かの確認である。電源ＯＮ直後（言い換えれば、リセット解除直後）は、共有データメモリ１１５の値は不定値であるので、正常な通信パラメータは設定されていない。このため、第２コア１１１－２は通信パラメータ初期化の処理を行う（ステップＳ２２２）。続いて、第２コア１１１－２は、初期化した通信パラメータに基づき、通信デバイス１１４を介して外部装置（例えばＥＣＵ２０やＥＣＵ３０）との通信を開始する（ステップＳ２２３）。

【0027】

そして、第１コア１１１－１によるＯＳの初期化処理が完了すると、第１コア１１１－１は、通信等に関するアプリケーションを起動する（ステップＳ２１３）。このとき、第２コア１１１－２は、通信切り替えの処理を行う（ステップＳ２２４）。具体的には、第２コア１１１－２の通信プログラムが停止し、第１コア１１１－１が主導する通信処理が行われる。続いて、第１コア１１１－１と第２コア１１１－２は、それぞれのアプリケーションを実行する(ステップＳ２１４とステップＳ２２５)。

【0028】

本実施形態の車両制御装置１０によれば、電源ＯＮによるリセット解除から第１コア１１１－１によるＯＳ初期化完了までの間に、第２コア１１１－２は共有データメモリ１１５にアクセスして通信パラメータの確認を行い、通信パラメータの初期化処理を行った後に、初期化した通信パラメータに基づいて外部装置との通信を行うので、ＯＳ初期化の完了を待たずに通信が可能となる。その結果、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止することができる。更に、これによって、通信途絶に起因する他のＥＣＵからの異常判定を回避することができる。

【0029】

［第２実施形態］
第２実施形態に係る車両制御装置１０は、上記第１実施形態と同様な構造を有するが、車両制御装置１０の制御内容において上記第１実施形態と相違している。以下では、その相違点のみを説明する。

【0030】

従来では、例えばエンジン制御とモータ制御のような異なる機能について、別々のＥＣＵを設けてそれぞれの制御を行っていた。近年、装置のコンパクト化やコスト削減等を図るために、異なる機能を持つＥＣＵを統合することが進められている。そして、統合ＥＣＵにおいては、ある機能に異常が発生しても、他の機能の動作を継続することが求められている。

【0031】

異常が発生した場合は、該異常が発生した機能をソフトウェア的に初期化することにより解消する手法があるが、マルチコアＣＰＵ全体をハードウェア的にリセットすることで異常を解消する手法も考えられる。本実施形態では、マルチコアＣＰＵ全体をハードウェア的にリセットすることで異常を解消する手法が採用されている。そして、マルチコアＣＰＵ１１全体のリセットに先立ち、現在使用中の通信パラメータを共有データメモリ１１５に保存しておき、リセット解除後に上記保存された現在使用中の通信パラメータに基づいて通信を行うことにより、リセット前後における通信の連続性を維持することができる。なお、本実施形態でいう異常は、車両に取り付けられたセンサ等を介して検出できる異常である。従って、このような異常に起因するリセットは、意図したリセットである。

【0032】

以下、図３を基に本実施形態に係る車両制御装置のリセット前後の制御を説明する。図３において、ステップＳ３１１～Ｓ３１５は第１コア１１１－１により行われる処理であり、ステップＳ３２１～Ｓ３２５は第２コア１１１－２により行われる処理である。

【0033】

図３に示すように、第１コア１１１－１は、異常を検出すると（ステップＳ３１１）、現在使用中の通信パラメータを保存するように第２コア１１１－２に指示する。第２コア１１１－２は、第１コア１１１－１からの指示に基づき、現在使用中の通信パラメータを保存する（ステップＳ３２１）。このとき、第２コア１１１－２は、現在使用中の通信パラメータを該第２コア１１１－２に対応するデータメモリ１１３－２ではなく、共有データメモリ１１５に保存させる。ここで、共有データメモリ１１５に保存される通信パラメータを通信パラメータ３３１とする。

【0034】

続いて、第１コア１１１－１は、監視ＩＣ１２に対し、リセット発生する指示を送信する（ステップＳ３１２）。続いて、マルチコアＣＰＵ１１はリセットされる。

【0035】

リセット解除後、第１コア１１１－１は、まずＯＳを起動し（ステップＳ３１３）、次にＯＳ初期化の処理を行う（ステップＳ３１４）。このとき、第２コア１１１－２は、第１コア１１１－１の処理と並行して各処理を行う。

【0036】

具体的には、第２コア１１１－２は、共有データメモリ１１５にアクセスし、共有データメモリ１１５に保存されている通信パラメータ３３１の確認を行う（ステップＳ３２２）。本ステップにおける通信パラメータの確認は、電源ＯＮ直後のメモリの不定値ではないことの確認である。続いて、第２コア１１１－２は、通信パラメータ３３１を参照し、通信パラメータの復帰処理を行う（ステップＳ３２３）。続いて、第２コア１１１－２は、復帰した通信パラメータ（すなわち、通信パラメータ３３１）に基づき、通信デバイス１１４を介して外部装置（例えばＥＣＵ２０やＥＣＵ３０）との通信を開始する（ステップＳ３２４）。

【0037】

そして、第１コア１１１－１によるＯＳの初期化処理が完了すると、第１実施形態で述べたように、第１コア１１１－１は通信等に関するアプリケーションを起動し（ステップＳ３１５）、第２コア１１１－２は通信切り替えの処理を行う（ステップＳ３２５）。その後、第１実施形態で述べた各処理はそれぞれ行われる。

【0038】

本実施形態の車両制御装置１０によれば、上述第１実施形態と同様な作用効果を得られるほか、更に以下の作用効果を奏する。すなわち、リセット前に現在使用中の通信パラメータを共有データメモリ１１５に保存し、リセット解除から第１コア１１１－１によるＯＳ初期化完了までの間に、第２コア１１１－２は共有データメモリ１１５に保存される現在使用中の通信パラメータに基づいて通信を行うので、リセット前後における通信の連続性を維持することができる。なお、上記特許文献１に記載の技術では、リセット解除後に初期通信のみを行うので、リセット前後における通信の連続性を維持できない問題が生じると考えられる。本実施形態の車両制御装置１０によれば、上記特許文献１に記載の技術の問題を解決することができる。

【0039】

なお、本実施形態において、通信パラメータが正常な値か、電源ＯＮ直後のメモリの不定値かを区別するためには、通信パラメータに関する各データを二重化したり、チェックサムやハッシュを付加したりする等、既知の手法を用いることができる。

【0040】

また、本実施形態において、通信パラメータに加えて通信プログラムを更に共有データメモリ１１５に保存するようにしても良い。このようにすれば、複雑な通信処理にも対応できるので、例えば可変値を含む通信も可能となる。更に、共有データメモリ１１５には、スクリプトを解釈して実行するプログラムが保存されても良く、例えばスクリプト言語で記述された通信プログラムが保存される。このようにすれば、複雑な通信処理にも対応できる。

【0041】

［第３実施形態］
第３実施形態に係る車両制御装置１０は、上記第１実施形態と同様な構造を有するが、車両制御装置１０の処理内容において上記第１実施形態と相違している。以下では、その相違点のみを説明する。

【0042】

図４は第３実施形態に係る車両制御装置のリセット前後の制御を示すシーケンス図である。図４において、ステップＳ４１１～Ｓ４１４は第１コア１１１－１により行われる処理であり、ステップＳ４２１～Ｓ４２４は第２コア１１１－２により行われる処理である。

【0043】

図４に示すように、第１コア１１１－１は、まず通信パラメータのデフォルト値の保存処理を行う（ステップＳ４１１）。通信パラメータのデフォルト値は、予期せぬ異常によってリセットが起きた場合に使用される通信パラメータの値であって、予め設定されたものである。このデフォルト値には、予期せぬ異常によるリセットであることを示す通信パターンが予め組み込まれている。デフォルト値は、上述したメモリの不定値と区別するための手法を用いて共有データメモリ１１５に保存されている。ここで、共有データメモリ１１５に保存されるデフォルト値を通信パラメータ４３１とする。

【0044】

そして、マルチコアＣＰＵ１１に予期せぬ異常が発生した場合、監視ＩＣ１２は、リセット信号１４をマルチコアＣＰＵ１１に出力する。これによって、マルチコアＣＰＵ１１はリセットされる。

【0045】

リセット解除後、第１コア１１１－１は、まずＯＳを起動し（ステップＳ４１２）、次にＯＳ初期化の処理を行う（ステップＳ４１３）。このとき、第２コア１１１－２は、第１コア１１１－１の処理と並行して各処理を行う。

【0046】

具体的には、第２コア１１１－２は、共有データメモリ１１５にアクセスし、共有データメモリ１１５に保存されている通信パラメータ４３１を確認し、メモリの不定値ではないことをチェックし（ステップＳ４２１）、通信パラメータ４３１を取得する（ステップＳ４２２）。これによって、ステップＳ４１１で設定されたデフォルト値が取得される。

【0047】

続いて、第２コア１１１－２は、取得した通信パラメータ４３１に基づき、通信デバイス１１４を介して外部装置（例えばＥＣＵ２０やＥＣＵ３０）との通信を開始する（ステップＳ４２３）。そして、通信パラメータ４３１には予期せぬ異常によるリセットのことを示す通信パターンが組み込まれているため、他のＥＣＵ（ＥＣＵ２０及びＥＣＵ３０）は車両制御装置１０でそれを把握できる。

【0048】

そして、第１コア１１１－１によるＯＳの初期化処理が完了すると、第１実施形態で述べたように、第１コア１１１－１は、通信等に関するアプリケーションを起動し（ステップＳ４１４）、第２コア１１１－２は、通信切り替え処理を行う（ステップＳ４２４）。その後、第１実施形態で述べた各処理がそれぞれ行われる。

【0049】

本実施形態の車両制御装置１０では、第１コア１１１－１は通信パラメータのデフォルト値を予め設定し、共有データメモリ１１５に保存しておく。そして、予期せぬ異常によってリセットが生じた場合、第２コア１１１－２は該デフォルト値に基づいて通信を行うことで、ＯＳ初期化の完了を待たずに通信が可能となる。その結果、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止することができる。また、これによって、通信途絶に起因する他のＥＣＵからの異常判定を回避することができる。

【0050】

なお、本実施形態において、通信パラメータのデフォルト値はステップＳ４１１で第１コア１１１－１により設定されるが、例えばフラグのみを設定し、ステップＳ４２１では、フラグが検知されると、固定の通信パラメータを第２コア１１１－２に送信するようにしても良い。

【0051】

また、上記３つの実施形態において、電源ＯＮによるリセットのパターン（第１実施形態）、意図したリセットのパターン（第２実施形態）、及び、予期せぬ異常によるリセットのパターン（第３実施形態）をそれぞれ説明した。例えば他のＥＣＵへの通信データに上記３つのパターンをそれぞれ識別できる識別番号等を付した状態で送信すれば、他のＥＣＵに車両制御装置１０が正常か異常かを明確に伝えることができる。

【0052】

以上、本発明の実施形態について詳述したが、本発明は、上述の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の精神を逸脱しない範囲で、種々の設計変更を行うことができるものである。

【符号の説明】

【0053】

１０ 車両制御装置
１１ マルチコアＣＰＵ
１２ 監視ＩＣ（監視部）
１３ 信号
１４ リセット信号
１５ 車載ネットワーク
２０，３０ ＥＣＵ
１１１－１ 第１コア
１１１－２ 第２コア
１１１－ｎ 第ｎコア
１１２－１，１１２－２，…１１２－ｎ プログラムメモリ
１１３－１，１１３－２，…１１３－ｎ データメモリ
１１４ 通信デバイス
１１５ 共有データメモリ
１１６ バス

【図1】

【図2】

【図3】

【図4】