JP7244299B2 - 制御装置、制御装置システム、および、制御装置の制御方法 - Google Patents

Description

本発明は、制御装置、制御装置システム、および、制御装置の制御方法に関する。

特許文献１には、不揮発性記憶装置を少なくとも備える複数のＥＣＵから成るＥＣＵノードにおける記憶情報の書き換えに関する技術が開示されている。ＥＣＵノードは、複数のＥＣＵのうち第１の通信ラインに接続されたマスターＥＣＵと、第２の通信ラインを介してマスターＥＣＵに接続され且つ複数のＥＣＵのうちマスターＥＣＵを除く少なくとも１つのスレーブＥＣＵとから成る。

マスターＥＣＵのフラッシュメモリには、マスター側ルーティンプログラムと、マスター側ブートプログラムと、スレーブ側書換プログラムと、スレーブ側ブートプログラムと、スレーブ側ルーティンプログラムと、転送用プログラムとが格納されている。また、スレーブＥＣＵのフラッシュメモリには、スレーブ側ブートプログラムと、スレーブ側ルーティンプログラムとが格納されている。

特開２００９－１６６６４５号公報

特許文献１におけるＥＣＵノードでは、マスターＥＣＵと、スレーブＥＣＵとは構成が異なる。すなわち、マスターＥＣＵとスレーブＥＣＵとは、分けて準備する必要がある。このような構成の場合、工場等で行われる組み立て作業時において、マスターＥＣＵとスレーブＥＣＵとの取り付けを誤る可能性がある。マスターＥＣＵとスレーブＥＣＵとの取り付けを間違えると、ＥＣＵノードが適切に作動しなくなる虞がある。

本発明は、外部装置と通信可能に設けられる第１制御装置と、第１制御装置を介して外部装置と通信可能に設けられる第２制御装置とのいずれに適用されても制御装置を適切に動作させることを可能とする技術を提供することを目的とする。

上記目的を達成するために本発明の制御装置は、外部装置と通信可能に設けられる第１制御装置と、前記第１制御装置を介して前記外部装置と通信可能に設けられる第２制御装置とのいずれにも使用可能な制御装置であって、前記制御装置は、第１処理と第２処理とを切り換えて実行可能に設けられる制御処理部を有し、前記制御処理部は、前記第１処理の実行中、かつ、所定タイミングから第１時間が経過した場合、前記第１処理から前記第２処理への切り換えを行い、前記所定タイミングから、前記第１時間より短い第２時間が経過するまでの間に、前記外部装置との通信を利用した所定処理の実行要求を受け、前記実行要求が前記第２制御装置として動作する前記制御装置に対して発せられたものである場合、前記第１時間の経過を待たずに前記第１処理から前記第２処理への切り換えを行う構成（第１の構成）になっている。

上記第１の構成の制御装置において、前記第２処理には、自装置が前記第１制御装置と前記第２制御装置とのうちのいずれであるかを判定する判定処理と、自装置が前記第１制御装置である場合に、前記外部装置からの指令を前記第２制御装置に転送するゲートウェイ処理と、が含まれる構成（第２の構成）であることが好ましい。

上記第１又は第２の構成の制御装置において、前記制御処理部は、前記所定タイミングから前記第１時間が経過するまでの間に、自装置に対して発せられた前記所定処理の実行要求を受けた場合、前記所定処理の開始を待つ待機処理を実行する構成（第３の構成）であることが好ましい。

上記第３の構成の制御装置において、前記制御処理部は、前記第２処理の実行中に、自装置に対して発せられた前記所定処理の実行要求を受けた場合、前記待機処理を実行する構成（第４の構成）であることが好ましい。

上記第３又は第４の構成の制御装置は、前記第１処理の実行を可能とする第１ソフトウェアと、前記第２処理の実行を可能とする第２ソフトウェアとを記憶する不揮発性記憶部を更に有し、前記所定処理は、前記第２ソフトウェアを書き換える書き換え処理である構成（第５の構成）であることが好ましい。

上記第５の構成の制御装置において、前記制御処理部は、前記第１処理の実行中に、前記所定タイミングから前記第１時間が経過するまでの間に前記所定処理の実行要求を受けず、且つ、前記第２ソフトウェアに不具合があると判断された場合、前記待機処理を実行する構成（第６の構成）であることが好ましい。

上記第６の構成の制御装置において、前記制御処理部は、先に行われた前記第２ソフトウェアの書き換え処理が中断したと判断された場合と、前記第２ソフトウェアの有効性判定により前記第２ソフトウェアが有効でないと判断された場合とに、前記第２ソフトウェアに不具合があると判断する構成（第７の構成）であってよい。

上記第５から第７のいずれかの構成の制御装置において、前記所定タイミングは、前記第１ソフトウェアの起動後、所定の初期化処理が完了したタイミングである構成（第８の構成）であってよい。

上記目的を達成するために本発明の制御装置システムは、前記第１制御装置として使用される上記構成の制御装置と、前記第２制御装置として使用される上記構成の制御装置と、を有する構成（第９の構成）になっている。

上記目的を達成するために本発明の制御方法は、外部装置と通信可能に設けられる第１制御装置と、前記第１制御装置を介して前記外部装置に通信可能に設けられる第２制御装置とのいずれにも使用可能な制御装置の制御方法であって、前記制御装置は、第１処理と第２処理とを切り換えて実行可能に設けられ、前記第１処理の実行中、かつ、所定タイミングから第１時間が経過した場合、前記第１処理から前記第２処理への切り換えを行い、前記所定タイミングから、前記第１時間より短い第２時間が経過するまでの間に、前記外部装置との通信を利用した所定処理の実行要求を受け、前記実行要求が前記第２制御装置として動作する前記制御装置に対して発せられたものである場合、前記第１時間の経過を待たずに前記第１処理から前記第２処理への切り換えを行う構成（第１０の構成）になっている。

本発明によると、外部装置と通信可能に設けられる第１制御装置と、第１制御装置を介して外部装置と通信可能に設けられる第２制御装置とのいずれに適用されても制御装置を適切に動作させることができる。

制御装置システムが適用された車両を示す模式図 制御装置システムの構成を示すブロック図 制御処理部の構成を示すブロック図 ＲＯＭの構成を示す模式図 マスタースレーブ判定処理の流れを示すフローチャート 書き換え処理の流れを示すシーケンス図 リプログ処理のメインタスクの流れを示すフローチャート ＣＡＮ受信タスクの流れを示すフローチャート 定期タスクの大まかな流れを示すフローチャート メッセージ結合処理の流れを示すフローチャート リプログサービス処理の流れを示すフローチャート リプログサービス処理において、メッセージ内容が強制書き換え要求である場合の処理の流れを示すフローチャート リプログ状態管理処理の流れを示すフローチャート スレーブ向けの強制書き換え要求があった場合の処理の流れを示す模式図 比較例を示す模式図 通常エントリーを説明するためのフローチャート

以下、本発明の例示的な実施形態について、図面を参照しながら詳細に説明する。以下の説明では、本発明の制御装置が車両に搭載されるレーダ装置に適用される場合を例に挙げて説明する。ただし、本発明の制御装置は、車両に搭載されるレーダ装置以外のものに適用されてよい。例えば、車両に搭載されるカメラやＬＩＤＡＲ（Laser Imaging Detection and Ranging）等に適用されてよい。また、本発明は、例えばロボット等の車両以外の移動体に適用されてよい。また、本発明は、家電、ＯＡ機器等の移動体以外の機器に適用されてもよい。本発明は、外部装置と通信可能に設けられる第１制御装置と、第１制御装置を介して外部装置と通信可能に設けられる第２制御装置とを有するシステムに広く適用可能である。

本明細書において、ソフトウェアはコンピュータプログラムを含む。ソフトウェアは、コンピュータプログラムの他に、設定ファイルやデータを保管するファイル等を含んでよい。また、本明細書では、コンピュータプログラムのことを単にプログラムと表現する。また、本明細書では、ソフトはソフトウェアの略語である。また、本明細書では、アプリはアプリケーションソフトウェアの略語である。

＜１．制御装置システム＞
図１は、本発明の実施形態に係る制御装置システムが適用された車両Ｖを示す模式図である。車両Ｖは、一例として、後方監視用に２つのレーダ装置２０１、２０２を有する。詳細には、車両Ｖは、後方用左レーダ装置２０１と、後方用右レーダ装置２０２とを有する。各レーダ装置２０１、２０２は、送受信用のアンテナと、送受信用のアンテナを制御する電子制御装置（ＥＣＵ：Electronic Control Unit）とを有する。以下、電子制御装置のことを単にＥＣＵと記載する。各レーダ装置２０１、２０２が有するＥＣＵは、受信アンテナにより得られた受信信号を処理して、物標までの距離、物標の相対速度、物標の存在する方位等の物標データを取得する。

図２は、本発明の実施形態に係る制御装置システム２００の構成を示すブロック図である。制御装置システム２００は、第１制御装置１と第２制御装置２とを有する。本実施形態では、第１制御装置１はマスターＥＣＵである。第２制御装置２はスレーブＥＣＵである。

本実施形態では、後方用左レーダ装置２０１のＥＣＵと、後方用右レーダ装置２０２のＥＣＵとのうち、いずれか一方が第１制御装置（マスターＥＣＵ）１となり、他方が第２制御装置（スレーブＥＣＵ）２となる。例えば、後方用左レーダ装置２０１のＥＣＵが第１制御装置１となり、後方用右レーダ装置２０２のＥＣＵが第２制御装置２となる。

制御装置システム２００は、電源３と、第１通信ネットワーク４と、第２通信ネットワーク５とを更に有する。

電源３は、第１制御装置１と第２制御装置２とで共通である。電源３がオンされると、第１制御装置１と第２制御装置２とは同時に動作を開始する。すなわち、第２制御装置２は、第１制御装置１と連動する。電源３は、例えば、車両Ｖがエンジンで駆動される場合にはイグニッションのオンオフに連動してオンオフされてよい。また、電源３は、例えば、車両Ｖが電気自動車である場合には、車両Ｖの駆動系の電源のオンオフに連動してオンオフされてよい。

第１通信ネットワーク４は、第１制御装置１と外部装置６とを通信可能に接続する。すなわち、第１制御装置１は、外部装置６と通信可能に設けられる。本実施形態では、第１通信ネットワーク４はＣＡＮ（Controller Area Network）である。詳細には、第１制御装置１は、第１通信チャンネルＣＨ１がＣＡＮ４に接続され、ＣＡＮ４を介して外部装置６と通信することができる。なお、本実施形態においては、外部装置６は、第１制御装置１および第２制御装置２が有するソフトウェアの書き換えを可能とする書き換え装置である。

第２通信ネットワーク５は、第１制御装置１と第２制御装置２とを通信可能に接続する。本実施形態では、第２通信ネットワーク５もＣＡＮである。詳細には、第１制御装置１の第２通信チャンネルＣＨ２と、第２制御装置２の第２通信チャンネルＣＨ２とが第２通信ネットワーク５により接続されている。なお、第２制御装置２は、第１通信ネットワーク４には直接接続されていない。第２制御装置２は、第１制御装置１を介して外部装置６と通信可能に設けられる。第２制御装置２は、第１制御装置１を介して外部装置６からの指令を受け取る。第２通信ネットワーク５は、ＣＡＮに替えてＬＩＮ（Local Interconnect Network）であってもよい。

第１制御装置１は、第１通信ネットワーク４と第２通信ネットワーク５との接続関係を変更することにより、第２制御装置２になることができる。また、第２制御装置２は、第１通信ネットワーク４と第２通信ネットワーク５との接続関係を変更することにより、第１制御装置１になることができる。すなわち、第１制御装置１と第２制御装置２とは同一の構成を有する制御装置１００である。換言すると、制御装置１００は、第１制御装置１と第２制御装置２とのいずれにも使用可能である。制御装置システム２００は、第１制御装置１として使用される制御装置１００と、第２制御装置２として使用される制御装置１００とを有する。本構成によれば、制御装置システム２００を構成する制御装置の種類が１種類であるために、例えば車両工場等における制御装置の組み付け作業において、制御装置の種類を間違える作業ミスを無くすことができる。

なお、制御装置システム２００が有する制御装置１００の数は２つより多くてもよい。例えば、制御装置システム２００は、第１制御装置（マスターＥＣＵ）１として使用される１つの制御装置１００と、第２制御装置（スレーブＥＣＵ）２として使用される２つ以上の制御装置１００とを有してよい。

＜２．制御装置＞
以下、第１制御装置１と第２制御装置２とのいずれにも使用可能な制御装置１００について詳細に説明する。

（２－１．制御装置の概略構成）
図２に示すように、制御装置１００は制御処理部１０を有する。制御処理部１０は、例えばマイクロコンピュータ（マイコン）である。図３は、本発明の実施形態に係る制御処理部１０の構成を示すブロック図である。図３に示すように、制御処理部１０は、ＣＰＵ（Central Processing Unit）１１と、通信コントローラ１２と、ＲＡＭ（Random Access Memory）１３と、ＲＯＭ（Read Only Memory）１４とを有する。

ＣＰＵ１１は、制御装置１００の動作の全体を制御する。ＣＰＵ１１は、例えば、ＲＯＭ１４に記憶される各種のソフトウェアに含まれるプログラムにしたがって演算処理を行い、各種の機能を発揮させる。

通信コントローラ１２は、制御処理部１０における通信制御を行う。通信コントローラ１２は、例えば、通信フレームを送受信する制御をＣＡＮ通信プロトコルに従って実行する。

ＲＡＭ１３は、揮発性記憶部である。ＲＡＭ１３は、例えばＤＲＡＭ（Dynamic Random Access Memory)やＳＤＲＡＭ（Synchronous Dynamic Random Access Memory)等であってよい。ＲＡＭ１３は、ＣＰＵ１１の演算結果等を一時的記憶する。ＲＡＭ１３は、送受信用のデータを一時的に記憶するバッファを有してよい。このようなバッファはＲＡＭ１３とは別に設けられてもよい。

ＲＯＭ１４は、不揮発性記憶部である。すなわち、制御装置１００は不揮発性記憶部を有する。ＲＯＭ１４は、例えばフラッシュメモリである。ＲＯＭ１４には、制御装置１００に各種の機能を発揮させるためのプログラムやデータを記憶する。図４は、本発明の実施形態に係るＲＯＭ１４の構成を示す模式図である。図４に示すように、ＲＯＭ１４は、ＢＯＯＴソフト１４１と、調整値１４２と、第１ソフトウェア１４３と、第２ソフトウェア１４４とを記憶する。換言すると、不揮発性記憶部は、第１ソフトウェア１４３と、第２ソフトウェア１４４とを記憶する。

ＢＯＯＴソフト１４１は、制御処理部１０のリセット解除直後に実行されるソフトウェアである。調整値１４２は、レーダ装置の個体間ばらつきを補正するための補正データである。

第１ソフトウェア１４３は、第１処理の実行を可能とする。ＣＰＵ１１が、第１ソフトウェア１４３に含まれるプログラムにしたがって演算処理を行うことにより第１処理が行われる。また、第２ソフトウェア１４４は、第２処理の実行を可能とする。ＣＰＵ１１が、第２ソフトウェア１４４に含まれるプログラムにしたがって演算処理を行うことにより第２処理が行われる。すなわち、制御処理部１０は、第１処理と第２処理とを切り換えて実行可能に設けられる。

本実施形態では、第１ソフトウェア１４３は、ＲＯＭ１４に記憶される第２ソフトウェア１４４を書き換えるために利用されるリプログソフトである。第２ソフトウェア１４４は、ユーザアプリであり、レーダ装置２０１、２０２として主だった機能を発揮させるのに利用される。ユーザアプリが起動されることにより、例えばレーダ波の送受信のための信号処理や、物標認識などの処理が可能となる。以下、第１ソフトウェア１４３のことをリプログソフト１４３と呼称することがある。また、第２ソフトウェア１４４のことをユーザアプリ１４４と呼称することがある。また、ＣＰＵ１１が第１ソフトウェア１４３に含まれるプログラムにしたがった演算処理を実行することにより行われる第１処理をリプログ処理と呼称することがある。ＣＰＵ１１が第２ソフトウェア１４４に含まれるプログラムしたがった演算処理を実行することにより行われる第２処理をユーザアプリ処理と呼称することがある。

なお、ＢＯＯＴソフト１４１、調整値１４２、および、リプログソフト１４３は、書き換え不可領域Ｒ１に記憶され、書き換えることができない。一方、ユーザアプリ１４４は書き換え可能領域Ｒ２に記憶され、書き換えることができる。

本実施形態では、ユーザアプリ処理には、判定処理とゲートウェイ処理とが含まれる。すなわち、第２処理には、判定処理とゲートウェイ処理とが含まれる。

判定処理は、自装置が第１制御装置１と第２制御装置２とのいずれであるかを判定する。本実施形態では、第１制御装置１がマスターＥＣＵであり、第２制御装置２がスレーブＥＣＵであるために、以下、前述の判定処理のことをマスタースレーブ判定処理と呼称する。マスタースレーブ判定処理は、ユーザアプリ１４４の起動後、早い段階で実行される。なお、マスタースレーブ判定処理は、定期的に実行される構成であってよい。図５は、本発明の実施形態に係る制御装置１００により実行されるマスタースレーブ判定処理の流れを示すフローチャートである。

ステップＳ１では、制御処理部１０は、自装置が第１制御装置（マスターＥＣＵ）１と第２制御装置（スレーブＥＣＵ）２とのいずれであるかが未確定であるか否かを確認する。マスターとスレーブとのいずれであるかが確定している場合には（ステップＳ１でＮｏ）、制御処理部１０はマスタースレーブ判定処理を終了する。一方、マスターとスレーブとのいずれであるかが未確定である場合には（ステップＳ１でＹｅｓ）、次のステップＳ２に処理を進める。

ステップＳ２では、制御処理部１０は、第１通信チャンネルＣＨ１からＣＡＮ通信の受信履歴があるか否かを確認する。ＣＡＮ通信の受信履歴がある場合には（ステップＳ２でＹｅｓ）、次のステップＳ３に処理を進める。一方、ＣＡＮ通信の受信履歴がない場合には（ステップＳ２でＮｏ）、制御処理部１０は後述のステップＳ５に処理を進める。

ステップＳ３では、制御処理部１０は、ＣＡＮ通信の受信履歴があるために、マスタースレーブ判定情報をマスターに設定する。すなわち、制御処理部１０は、自装置が第１制御装置１であると判定する。制御処理部１０は、マスタースレーブ判定情報をマスターに設定後、次のステップＳ４に処理を進める。

ステップＳ４では、制御処理部１０は、ＣＡＮ５にスレーブ設定データを送信する。これにより、マスタースレーブ判定処理を終了する。なお、スレーブ設定データが送られた制御装置１００は、後述のように、自装置が第２制御装置２であると判定することになる。

ステップＳ５では、制御処理部１０は、ＣＡＮ通信の受信履歴がないために、第２通信チャンネルＣＨ２からスレーブ設定データの受信履歴があるか否かを確認する。スレーブ設定データの受信履歴がある場合には（ステップＳ５でＹｅｓ）、制御処理部１０は次のステップＳ６に処理を進める。一方、スレーブ設定データの受信履歴がない場合には（ステップＳ５でＮｏ）、制御処理部１０は、マスタースレーブ判定処理を終了する。

ステップＳ６では、制御処理部１０は、スレーブ設定データの受信履歴があるために、マスタースレーブ判定情報をスレーブに設定する。すなわち、制御処理部１０は、自装置が第２制御装置２であると判定する。マスタースレーブ判定情報をスレーブに設定後、制御処理部１０は、次のステップＳ７に処理を進める。

ステップＳ７では、制御処理部１０は、ＣＡＮ５にスレーブ設定完了データを送信する。これにより、第２制御装置２と接続される第１制御装置１は、ＣＡＮ５を介して接続される制御装置１００が第２制御装置２であることを認識していることを認識する。制御処理部１０は、スレーブ設定完了データの送信後、マスタースレーブ判定処理を終了する。

ゲートウェイ処理は、自装置が第１制御装置１である場合に、外部装置６からの指令を第２制御装置２に転送する処理である。なお、本実施形態では、ユーザアプリ１４４の起動時においてのみゲートウェイ機能が利用できる。すなわち、リプログソフト１４３の起動時においては、ゲートウェイ機能は利用できない。

本実施形態では、制御装置１００がマスタースレーブ判定処理を行えるために、第１制御装置１と第２制御装置２とを予め区別して準備する必要をなくすことができる。また、本実施形態では、ユーザアプリ１４４の使用時においてのみゲートウェイ機能を利用することができる構成であるために、リプログソフト１４３のデータサイズが大きくなることを抑制することができる。この結果、ユーザアプリ１４４に割り当てることができるデータサイズを増やすことができる。

（２－２．書き換え処理の概要）
図６は、本発明の実施形態に係る制御装置１００で実行される書き換え処理の流れを示すシーケンス図である。なお、書き換え処理は、ソフトウェアの書き換え装置として構成される外部装置６を利用して、ＲＯＭ１４に既に記憶されるユーザアプリ１４４を更新する処理を指す。

外部装置６が、制御処理部１０に対して書き換え処理の開始を通知する（ステップＳ１１）。具体的には、外部装置６が、制御処理部１０に対して、プログラミングセッションへの移行を要求する。これに対応して、制御処理部１０は、プログラミングセッションに移行し、プログラミングセッションへの移行を通知する（ステップＳ１２）。

次に、外部装置６は、制御処理部１０に対してセキュリティ解除を要求する（ステップＳ１３）。リプログソフト１４３には、第３者による不正なリプログラミングを防止するために、セキュリティ機能が組み込まれている。外部装置６は、当該セキュリティ機能を解除すべく所定の要求を行う。これに対応して、制御処理部１０は、外部装置６からの要求が正当な要求であることを条件としてセキュリティ解除を行う（ステップＳ１４）。制御処理部１０は、フラッシュ制御ソフト遷移要求をオンに設定する。

次に、外部装置６は、フラッシュ制御ソフトを転送する（ステップＳ１５）。制御処理部１０は、ＲＯＭ１４に記憶されているプログラムが動作している間は、ＲＯＭ１４の記憶内容を書き換えることができない。このために、外部装置６からＲＯＭ１４の記憶内容を書き換えるためのフラッシュ制御ソフトが転送される。制御処理部１０は、転送されたフラッシュ制御ソフトをＲＡＭ１３に展開する。制御処理部１０は、フラッシュ制御ソフトの利用の準備ができたことを外部装置６に通知する（ステップＳ１６）。ここまでは、ＣＰＵ１１がリプログソフト１４３に含まれるプログラムに従った演算処理を実行することによって行われる。以下は、ＣＰＵ１１が、フラッシュ制御ソフトに含まれるプログラムに従った演算処理を実行することによって行われる。

外部装置６が、現在のユーザアプリ１４４を更新するソフトウェアとして準備された新第２ソフトウェアを制御処理部１０に転送する（ステップＳ１７）。制御処理部１０は、現在のユーザアプリ１４４を転送された新第２ソフトウェアに書き換える。なお、本実施形態では、１回の通信で新第２ソフトウェアの全てのデータが転送されるのではなく、１回の通信で一部のデータが転送され、１回の通信では、当該転送された一部のデータの書き換えのみが行われる。複数回の通信を繰り返すことにより、ソフトウェアの更新処理が完了する。制御処理部１０は、新第２ソフトウェアへの更新（書き換え）を完了すると、そのことを外部装置６に通知する（ステップＳ１８）。

次に、外部装置６は、ＲＯＭ１４の書き換えが正しく行えたかを確認するためにベリファイ実施を要求する（ステップＳ１９）。制御処理部１０は、ベリファイの実施により書き換えが正常に行われたことを確認すると、そのことを外部装置６に通知する（ステップＳ２０）。

次に、外部装置６は、制御処理部１０に対してリセット処理（再起動）を要求する（ステップＳ２１）。これに対応して、制御処理部１０はリセット処理を行い、更新されたユーザアプリ１４４による処理を開始し、リセット処理を行ったことを外部装置６に通知する（ステップＳ２２）。これにより、ユーザアプリ１４４の書き換え処理が終了する。

（２－３．リプログ処理）
リプログ処理には、メインタスクと、ＣＡＮ受信タスクと、定期タスクとが含まれる。ＣＡＮ受信タスクおよび定期タスクは、所定の条件のもと、メインタスクより優先して行われる。定期タスクは、ＣＡＮ受信タスクより優先して行われる。

［２－３－１．メインタスク］
図７は、本発明の実施形態に係るＥＣＵ１００で実行されるリプログ処理のメインタスクの流れを示すフローチャートである。なお、図７には、ＣＰＵ１１がＢＯＯＴソフト１４１に含まれるプログラムに従って演算処理を行うことによって実行される処理も示されている。

ＣＰＵ１１は、リセット後に、ＢＯＯＴソフト１４１に含まれるプログラムに従って演算処理を行うことによりマイコン初期化処理を行う（ステップＳ３１）。リセットには、電源３をオンした際に行われるパワーオンリセットと、ソフトウェア制御の下で実行されるソフトウェアリセット（再起動）とが含まれる。ＣＰＵ１１は、マイコン初期化処理を完了すると、リプログソフト１４３に含まれるプログラムに従った演算処理を行うことによりリプログ処理を開始し、次のステップ３２に処理を進める。なお、リプログ処理の実行中においては、ＣＰＵ１１は、ＲＡＭ１３等に記憶される各種情報を参照しながら処理を進める。

ステップＳ３２では、ＣＰＵ１１は、リセットがパワーオンリセットであったか否かを確認する。リセットがパワーオンリセットである場合（ステップＳ３２でＹｅｓ）、ＣＰＵ１１は、次のステップＳ３３に処理を進める。一方、リセットがパワーオンリセットでない場合（ステップＳ３２でＮｏ）、ＣＰＵ１１は、後述のステップＳ４２に処理を進める。

ステップＳ３３では、ＣＰＵ１１は、リプログ状態を「強制書き換え要求待ち」に設定する。リプログ状態の設定を完了すると、ＣＰＵ１１は、次のステップＳ３４に処理を進める。

ステップＳ３４では、ＣＰＵ１１は、セッションを「デフォルトセッション」に設定する。セッションの設定を完了すると、ＣＰＵ１１は、次のステップＳ３５に処理を進める。

ステップＳ３５では、ＣＰＵ１１は、リプログ初期化処理を行う。ＣＰＵ１１は、例えば、ＣＡＮ通信、タイマ等の初期化処理を行う。リプログ初期化処理が完了すると、ＣＰＵ１１は、次のステップＳ３６に処理を進める。

ステップＳ３６では、ＣＰＵ１１は、割り込み許可を行う。リセット後の初期化処理により、割り込みは禁止状態とされる。当該割り込み許可により、メインタスク中に、詳細は後述するＣＡＮ受信タスクおよび定期タスクを優先して実行することが可能になる。割り込み許可を行うと、ＣＰＵ１１は、次のステップＳ３７に処理を進める。

ステップＳ３７では、ＣＰＵ１１は、所定の条件を満たしたか否かを確認する処理を繰り返す無限ループを開始する。無限ループは、所定の条件を満たした場合に終了する。

詳細には、ＣＰＵ１１は、無限ループに入ると、フラッシュ制御ソフト遷移要求があったか否かを確認する（ステップＳ３７１）。ＣＰＵ１１は、フラッシュ制御ソフト遷移要求フラグの設定を確認して、フラッシュ制御ソフト遷移要求があったか否かを確認する。なお、リプログ状態がセキュリティ解除待ちに設定された状態で外部装置６からセキュリティ解除要求（メッセージ）を正常受信すると、フラッシュ制御ソフト遷移要求は「あり」に設定される。この後、通信タイムアウトが発生した場合には、フラッシュ制御ソフト遷移要求は「なし」に設定される。フラッシュ制御ソフト遷移要求はデフォルトでは「なし」に設定される。

ＣＰＵ１１は、フラッシュ制御ソフト遷移要求がなかった場合（ステップＳ３７１でＮｏ）、ユーザアプリ遷移要求があったか否かを確認する（ステップＳ３７２）。ＣＰＵ１１は、ユーザアプリ遷移要求フラグの設定を確認して、ユーザアプリ遷移要求があったか否かを確認する。なお、ユーザアプリ遷移要求は、デフォルトでは「なし」に設定され、強制書き換え要求が所定時間なく、他の所定要件を満たした場合に「あり」に設定される。この点の詳細については後述する。ユーザアプリ遷移要求がなかった場合（ステップＳ３７２でＮｏ）、ＣＰＵ１１は、ステップＳ３７１に処理を戻す。フラッシュ制御ソフト遷移要求があった場合（ステップＳ３７１でＹｅｓ）、ＣＰＵ１１は、無限ループを抜け、次のステップＳ３８に処理を進める。また、ユーザアプリ遷移要求があった場合（ステップＳ３７２でＹｅｓ）、ＣＰＵ１１は、無限ループを抜け、後述のステップＳ４０に処理を進める。

ステップＳ３８では、ＣＰＵ１１は、フラッシュ制御ソフトに遷移するために、データ引き継ぎ処理を行う。ＣＰＵ１１は、フラッシュ制御ソフトと共有したいデータを例えばＲＡＭ１３等に移動する処理を行う。データ引き継ぎ処理が完了すると、ＣＰＵ１１は、次のステップＳ３９に処理を進める。

ステップＳ３９では、ＣＰＵ１１は、フラッシュ制御ソフトにジャンプ（遷移）する。これにより、フラッシュ制御ソフトが起動し、外部装置６と連携した第２ソフトウェアの書き換え処理が開始される。

ステップＳ４０では、ＣＰＵ１１は、ユーザアプリ１４４にジャンプ（遷移）する準備としてリプログ終了処理を行う。ＣＰＵ１１は、例えばＲＡＭ１３のクリアや、ウォッチドッグタイマのタイミング制御など、ソフトウェアリセット実施前に必要な処理を行う。リプログ終了処理が完了すると、ＣＰＵ１１は、次のステップＳ４１に処理を進める。

ステップＳ４１では、ＣＰＵ１１は、ソフトウェアリセットを行う。当該リセットにより、ＣＰＵ１１は、ステップＳ３１の処理に戻り、ステップＳ３２でＮｏを経てステップＳ４２に処理を進める。

ステップＳ４２では、ＣＰＵ１１は、書き換え要求があるか否かを確認する。ＣＰＵ１１は、書き換え要求フラグの設定を確認して、書き換え要求があったか否かを確認する。書き換え要求フラグは、デフォルトにおいて「なし」である。書き換え要求があった場合（ステップＳ４２でＹｅｓ）、ＣＰＵ１１は、次のステップＳ４３に処理を進める。一方、書き換え要求がなかった場合（ステップＳ４２でＮｏ）、ＣＰＵ１１は、後述のステップＳ４６に処理を進める。なお、ステップＳ４１のソフトウェアリセットが行われてステップＳ４２に至った場合には、書き換え要求は「なし」であり、ＣＰＵ１１は、ステップＳ４６に処理を進める。

ステップＳ４３では、ＣＰＵ１１は、リプログ状態を「セキュリティ解除待ち」に設定する。リプログ状態の設定を完了すると、ＣＰＵ１１は、次のステップＳ４４に処理を進める。

ステップＳ４４では、ＣＰＵ１１は、セッションを「プログラミングセッション」に設定する。セッションの設定を完了すると、ＣＰＵ１１は、次のステップＳ４５に処理を進める。

ステップＳ４５では、ＣＰＵ１１は、書き換え要求を「なし」に設定する。書き換え要求の設定を完了すると、ＣＰＵ１１は、上述のステップＳ３５に処理を進める。

ステップＳ４６では、ＣＰＵ１１は、ユーザアプリ１４４にジャンプ（遷移）する。これにより、ユーザアプリ１４４が起動する。ユーザアプリ１４４の起動により、ＣＰＵ１１は、レーダ装置２０１、２０２として機能を発揮するのに必要な処理を適宜行う。また、ユーザアプリ１４４の起動により、制御装置１００が第１制御装置（マスターＥＣＵ）１である場合には、ゲートウェイ処理が可能になる。

［２－３－２．ＣＡＮ受信タスク］
ＣＡＮ受信タスクは、通信コントローラ１２にＣＡＮフレームを受信した時に、割り込みにより実行される。図８は、本発明の実施形態に係る制御装置１００で実行されるＣＡＮ受信タスクの流れを示すフローチャートである。

ステップＳ５１では、ＣＰＵ１１は、通信コントローラ１２から受信したＣＡＮフレームが、自装置が受信すべきＩＤ（Identifier）のＣＡＮフレームであるか否かを確認する。自装置が受信すべきＩＤのＣＡＮフレームである場合（ステップＳ５１でＹｅｓ）、ＣＰＵ１１は、次のステップＳ５２に処理を進める。自装置が受信すべきＩＤのＣＡＮフレームでない場合（ステップＳ５１でＮｏ）、ＣＰＵ１１は、ＣＡＮ受信タスクを終了する。

ステップＳ５２では、ＣＰＵ１１は、ＣＡＮフレームのＩＤ、ＤＬＣ（Data Length Code）、および、データ内容を定期タスクとの共有バッファに格納する。この後、ＣＰＵ１１は、ＣＡＮ受信タスクを終了する。

［２－３－３．定期タスク］
定期タスクは、所定周期で行われる。本実施形態では、定期タスクは、１ミリ秒周期で割り込みにより実行される。定期タスクが実行される周期は適宜変更されてよい。図９は、本発明の実施形態に係る制御装置１００で実行される定期タスクの大まかな流れを示すフローチャートである。なお、定期タスクにおいては、図９に示す処理の他に、カウンタ変数によって１ｍｓ以上の時間のカウントし、ウォッチドッグパルスの反転などの処理も行う。

ステップＳ６１では、ＣＰＵ１１は、メッセージ結合処理を行う。１つのＣＡＮフレームは、８バイトのデータまでしか送信できない。８バイトを超えるサイズのデータ（メッセージ）を送信する場合には、複数のＣＡＮフレームに分けてデータが送信される。複数のＣＡＮフレームに分けて送信されることにより分割されたメッセージは、メッセージ結合処理により結合される。

図１０は、本発明の実施形態に係る制御装置１００によって実行されるメッセージ結合処理の流れを示すフローチャートである。ステップＳ６１１では、ＣＰＵ１１は、ＣＡＮデータがＣＡＮ受信タスクとの共有バッファに格納されているか否かを確認する。ＣＡＮデータが共有バッファに格納されている場合（ステップＳ６１１でＹｅｓ）、ＣＰＵ１１は、次のステップＳ６１２に処理を進める。ＣＡＮデータが共有バッファに格納されていない場合（ステップＳ６１１でＮｏ）、ＣＰＵ１１は、後述のステップＳ６１７に処理を進める。

ステップＳ６１２では、ＣＰＵ１１は、バッファに格納されているＣＡＮデータを所定の順番に従って１つ取り出す。ＣＡＮデータの取り出しが完了すると、ＣＰＵ１１は、次のステップＳ６１３に処理を進める。

ステップＳ６１３では、ＣＰＵ１１は、取り出したＣＡＮデータの内容が適切か否かを確認する。ＣＡＮデータの内容が適切である場合（ステップＳ６１３でＹｅｓ）、ＣＰＵ１１は、次のステップＳ６１４に処理を進める。ＣＡＮデータの内容が不適切な場合（ステップＳ６１３でＮｏ）、ＣＰＵ１１は、ステップＳ６１１に処理を戻す。

ステップＳ６１４では、ＣＰＵ１１は、ＣＡＮデータをメッセージに追加する。先の処置にてメッセージに追加されたＣＡＮデータが存在する場合には、メッセージの結合が行われる。ＣＡＮデータをメッセージに追加すると、ＣＰＵ１１は、次のステップＳ６１５に処理を進める。

ステップＳ６１５では、ＣＰＵ１１は、現在のＣＡＮデータが結合対象となる一連のメッセージの最後のメッセージに該当するか否かを確認する。最後のメッセージである場合には（ステップＳ６１５でＹｅｓ）、ＣＰＵ１１は、次のステップＳ６１６に処理を進める。一方、最後のメッセージでない場合には（ステップＳ６１５でＮｏ）、ＣＰＵ１１はステップＳ６１１に処理を戻す。

ステップＳ６１６では、ＣＰＵ１１は、メッセージ結合完了フラグをオンに設定する。なお、メッセージ結合完了フラグは、デフォルトにおいてオフである。メッセージ結合完了フラグの設定が完了すると、ＣＰＵ１１は、次のステップＳ６１７に処理を進める。

ステップＳ６１７では、ＣＰＵ１１は、外部装置６への応答が必要か否かを確認する。例えば、外部装置６に対してデータ送信の時間間隔を指定する場合等において、外部装置６への応答が必要になる。外部装置６への応答が必要である場合（ステップＳ６１７でＹｅｓ）、ＣＰＵ１１は、次のステップＳ６１８に処理を進める。一方、外部装置６への応答が必要でない場合（ステップＳ６１７でＮｏ）、メッセージ結合処理が完了する。

ステップＳ６１８では、ＣＰＵ１１は、外部装置６への応答のための送信データの作成および送信バッファへの追加処理を行う。これにより、メッセージ結合処理が完了する。ＣＰＵ１１は、メッセージ結合処理が完了すると、次のステップＳ６２に処理を進める。

図９に戻って、ステップＳ６２では、ＣＰＵ１１は、送信制御処理を行う。ＣＰＵ１１は、送信バッファにデータが存在する場合に送信処理を行う。なお、送信バッファにデータがない場合には、送信処理は行われない。送信制御処理が完了すると、ＣＰＵ１１は、次のステップＳ６３に処理を進める。

ステップＳ６３では、ＣＰＵ１１は、リプログサービス処理を行う。リプログサービス処理においては、メッセージ結合処理が完了したメッセージがある場合に、メッセージ内容に応じた処理が実行される。図１１は、本発明の実施形態に係る制御装置１００によって実行されるリプログサービス処理の流れを示すフローチャートである。

ステップＳ６３１では、ＣＰＵ１１は、メッセージ結合完了フラグがオンであるか否かを確認する。メッセージ結合完了フラグがオンである場合（ステップＳ６３１でＹｅｓ）、ＣＰＵ１１は、次のステップＳ６３２に処理を進める。一方、メッセージ結合完了フラグがオフである場合（ステップＳ６３１でＮｏ）、ＣＰＵ１１は、リプログサービス処理を完了する。

ステップＳ６３２では、ＣＰＵ１１は、メッセージ内容に応じた処理を実行する。メッセージ内容に応じた処理を完了すると、ＣＰＵ１１は、次のステップＳ６３３に処理を進める。

ステップＳ６３３では、ＣＰＵ１１は、メッセージ結合完了フラグをオフに設定する。これにより、ＣＰＵ１１は、リプログサービス処理を完了し、次のステップＳ６４に処理を進める。ここで、ステップＳ６４の処理について説明する前に、ステップＳ６３２において、メッセージ内容が強制書き換え要求である場合の処理を詳細に説明する。図１２は、リプログサービス処理において、メッセージ内容が強制書き換え要求である場合の処理の流れを示すフローチャートである。

ステップＳ６３２ａでは、ＣＰＵ１１は、先に強制書き換え要求受信履歴があるか否かを確認する。ＣＰＵ１１は、例えば強制書き換え要求受信履歴フラグを利用して、強制書き換え要求受信履歴があったか否かを確認する。強制書き換え受信履歴がある場合（ステップＳ６３２ａでＹｅｓ）、ＣＰＵ１１は、メッセージ内容に応じた処理を完了し、図１１に示すステップＳ６３３に処理を進める。一方、強制書き換え要求受信履歴がない場合（ステップＳ６３２ａでＮｏ）、ＣＰＵ１１は、次のステップＳ６３２ｂに処理を進める。

ステップＳ６３２ｂでは、ＣＰＵ１１は、メッセージがマスター向けのメッセージであるか否かを確認する。なお、マスター向けのメッセージとは、第１制御装置（マスターＥＣＵ）１向けのメッセージのことであり、本実施形態では、メッセージ内容を確認することによりマスター向けであるか否かが判断可能になっている。メッセージがマスター向けのメッセージである場合（ステップＳ６３２ｂでＹｅｓ）、次のステップＳ６３２ｃに処理を進める。一方、メッセージがマスター向けのメッセージでない場合（ステップＳ６３２ｂでＮｏ）、後述のステップＳ６３２ｆに処理を進める。

ステップＳ６３２ｃでは、ＣＰＵ１１は、強制書き換え要求受信履歴を「あり」に設定する。強制書き換え要求受信履歴の設定が完了すると、ＣＰＵ１１は、次のステップＳ６３２ｄに処理を進める。

ステップＳ６３２ｄでは、ＣＰＵ１１は、リプログ状態を「セキュリティ解除待ち」に設定する。リプログ状態の設定が完了すると、ＣＰＵ１１は、次のステップＳ６３２ｅに処理を進める。

ステップＳ６３２ｅでは、ＣＰＵ１１は、応答データを作成して送信バッファに追加する。応答データは、強制書き換え要求に対して正しく処理が行われたことを外部装置６に知らせるために作成される。なお、外部装置６は、当該応答データを受け取ることにより、セキュリティ解除要求を行う。応答データの作成および送信バッファへの追加処理が完了すると、ＣＰＵ１１は、メッセージ内容に応じた処理を完了し、図１１に示すステップＳ６３３に処理を進める。

ステップＳ６３２ｆでは、ＣＰＵ１１は、マスター向けでないと判断されたメッセージがスレーブ向けのメッセージであるか否かを確認する。なお、スレーブ向けのメッセージとは、第２制御装置（スレーブＥＣＵ）２向けのメッセージのことであり、本実施形態では、メッセージ内容を確認することによりスレーブ向けであるか否かが判断可能になっている。メッセージがスレーブ向けのメッセージである場合（ステップＳ６３２ｆでＹｅｓ）、次のステップＳ６３２ｇに処理を進める。一方、メッセージがスレーブ向けのメッセージでない場合（ステップＳ６３２ｆでＮｏ）、ＣＰＵ１１は、メッセージ内容に応じた処理を完了し、図１１に示すステップＳ６３３に処理を進める。

ステップＳ６３２ｇでは、ＣＰＵ１１は、スレーブ強制書き換え要求待ち時間内であるか否かを確認する。本実施形態では、ＣＰＵ１１は、リプログ初期化処理の完了後からカウンタを用いて経過時間を計測する。この計測時間が１０ｍｓ以内であれば、ＣＰＵ１１は、スレーブ強制書き換え要求待ち時間内であると判断する。計測時間が１０ｍｓを過ぎている場合には、ＣＰＵ１１は、スレーブ強制書き換え要求待ち時間内でないと判断する。すなわち、本実施形態では、スレーブ強制書き換え要求待ち時間は１０ｍｓである。ただし、１０ｍｓは例示にすぎず、当該時間は適宜変更されてよい。スレーブ強制書き換え要求待ち時間内である場合（ステップＳ６３２ｇでＹｅｓ）、ＣＰＵ１１は、次のステップＳ６３２ｈに処理を進める。一方、スレーブ強制書き換え要求待ち時間内でない場合（ステップＳ６３２ｇでＮｏ）、ＣＰＵ１１は、後述のステップＳ６３２ｋに処理を進める。

ステップＳ６３２ｈでは、ＣＰＵ１１は、ユーザアプリ１４４が有効、且つ、リプログ中断情報が「中断なし」と判定される否かを確認する。ユーザアプリ１４４が有効であるか否かは、例えば、ＲＯＭＳＵＭチェック等によるソフトウェアの有効性判定が利用されてよい。リプログ中断情報は、ＲＯＭ１４に保存されるデータである。リプログ中断情報の確認により、「中断なし」か「中断あり」か、を判定することができる。

リプログ中断情報は、ユーザアプリ１４４の書き換えを実施する直前に消去され、ベリファイの完了後に消去される前と異なる値でＲＯＭ１４に保存される。このために、リプログ中断情報がベリファイ完了後に書き込んだ値と一致すれば、前回の書き換え処理は中断することなく正しく終了したと判定できるために、リプログ中断情報は「中断なし」と判定される。一方、リプログ中断情報がベリファイ完了後に書き込んだ値と一致していなければ、リプログ中断情報は「中断あり」と判定される。

ユーザアプリ１４４が有効、且つ、リプログ中断情報が「中断なし」と判定される場合（ステップＳ６３２ｈでＹｅｓ）、ＣＰＵ１１は、次のステップＳ６３２ｉに処理を進める。一方、ユーザアプリ１４４が無効であると判定される場合と、リプログ中断情報が「中断あり」で判定される場合とのうち少なくとも一方が満たされる場合（ステップＳ６３２ｈでＮｏ）、ＣＰＵ１１は、後述のステップＳ６３２ｊに処理を進める。

ステップＳ６３２ｉでは、ＣＰＵ１１は、ユーザアプリ遷移要求を「あり」に設定する。ユーザアプリ遷移要求の設定が完了すると、ＣＰＵ１１は、メッセージ内容に応じた処理を完了し、図１１に示すステップＳ６３３に処理を進める。

ステップＳ６３２ｊでは、ＣＰＵ１１は、リプログ状態を「セキュリティ解除待ち」に設定する。リプログ状態の設定が完了すると、ＣＰＵ１１は、メッセージ内容に応じた処理を完了し、図１１に示すステップＳ６３３に処理を進める。

ステップＳ６３２ｋでは、ＣＰＵ１１は、強制書き換え要求受信履歴を「あり」に設定する。強制書き換え要求受信履歴の設定が完了すると、ＣＰＵ１１は、次のステップＳ６３２ｌに処理を進める。

ステップＳ６３２ｌでは、ＣＰＵ１１は、リプログ状態を「セキュリティ解除待ち」に設定する。リプログ状態の設定が完了すると、ＣＰＵ１１は、次のステップＳ６３２ｍに処理を進める。

ステップＳ６３２ｍでは、ＣＰＵ１１は、応答データを作成して送信バッファに追加する。応答データは、強制書き換え要求に対して正しく処理が行われたことを外部装置６に知らせるために作成される。なお、外部装置６は、当該応答データを受け取ることにより、セキュリティ解除要求を行う。応答データの作成および送信バッファへの追加処理が完了すると、ＣＰＵ１１は、メッセージ内容に応じた処理を完了し、図１１に示すステップＳ６３３に処理を進める。

図９に戻って、ステップＳ６４では、ＣＰＵ１１は、通信タイムアウト判定処理を行う。通信タイムアウト処理では、カウンタを用いて通信が行われていない時間がカウントされる。例えば、フラッシュ制御ソフト遷移要求フラグが「あり」に設定された後、規定通信時間内に外部装置６から通信がなければタイムアウトと判定される。タイムアウトにより、フラッシュ制御ソフト遷移要求フラグは「なし」になり、リプログ状態は「セキュリティ解除待ち」になる。また、例えば、セッション状態がプログラミングセッションになった後に、規定通信時間内に外部装置６から通信がなければタイムアウトと判定される。タイムアウトにより、セッション状態はデフォルトセッションとされ、リプログ状態は「セキュリティ解除待ち」にされる。

ステップＳ６５では、ＣＰＵ１１は、リプログ状態管理処理を行う。図１３は、本発明の実施形態に係る制御装置１００によって実行されるリプログ状態管理処理の流れを示すフローチャートである。

ステップＳ６５１では、ＣＰＵ１１は、リプログ状態が「強制書き換え要求待ち」に設定されているか否かを確認する。リプログ状態が「強制書き換え要求待ち」に設定されていない場合（ステップＳ６５１でＮｏ）、ＣＰＵ１１は、次のステップＳ６５２に処理を進める。一方、リプログ状態が「強制書き換え要求待ち」に設定されている場合（ステップＳ６５１でＹｅｓ）、ＣＰＵ１１は、後述のステップＳ６５４に処理を進める。

ステップＳ６５２では、ＣＰＵ１１は、リプログ状態が異常であるか否かを確認する。リプログ状態が異常とは、各種処理に中で何らかの異常が発生し、リプログ状態が想定される状態にない状態である。リプログ状態が異常であると判断される場合（ステップＳ６５２でＹｅｓ）、ＣＰＵ１１は、次のステップＳ６５３に処理を進める。一方、リプログリプログ状態が異常でないと判断される場合（ステップＳ６５１でＮｏ）、ＣＰＵ１１は、リプログ状態管理処理を終了する。

ステップＳ６５３では、ＣＰＵ１１は、ソフトウェアリセットを行う。異常状態を解消するための処理である。ソフトウェアリセットにより、ＣＰＵ１１は、図７に示すステップＳ３１に処理を戻す。

ステップＳ６５４では、ＣＰＵ１１は、強制書き換え要求待ちカウンタをインクリメントする。ＣＰＵ１１は、リプログ初期化処理の完了後から強制書き換え要求待ちカウンタを用いて経過時間を計測する。ＣＰＵ１１は、インクリメントが完了すると、次のステップＳ６５５に処理を進める。

ステップＳ６５５では、ＣＰＵ１１は、強制書き換え要求待ち時間を超えたか否かを確認する。強制書き換え要求待ち時間は、強制書き換え要求待ちカウンタで計測される時間である。本実施形態では、強制書き換え要求待ち時間は５０ｍｓである。強制書き換え要求待ちカウンタが５０ｍｓを超えた場合、強制書き換え要求待ち時間を超えたと判断される。強制書き換え要求待ちカウンタが５０ｍｓ以下である場合、強制書き換え要求待ち時間内であると判断される。なお、強制書き換え要求待ち時間は５０ｍｓに限らず、適宜変更されてよい。強制書き換え要求待ち時間を超えた場合（ステップＳ６５５でＹｅｓ）、ＣＰＵ１１は、次のステップＳ６５６に処理を進める。一方、強制書き換え要求待ち時間内である場合（ステップＳ６５５でＮｏ）、ＣＰＵ１１は、リプログ状態管理処理を終了する。

ステップＳ６５６では、ＣＰＵ１１は、ユーザアプリ１４４が有効、且つ、リプログ中断情報が「中断なし」と判定されるか否かを確認する。ユーザアプリ１４４が有効、且つ、リプログ中断情報が「中断なし」と判定される場合（ステップＳ６５６でＹｅｓ）、ＣＰＵ１１は、次のステップＳ６５７に処理を進める。一方、ユーザアプリ１４４が無効であると判定される場合と、リプログ中断情報が「中断あり」と判定される場合とのうち少なくとも一方が満たされる場合（ステップＳ６５６でＮｏ）、ＣＰＵ１１は、後述のステップＳ６５８に処理を進める。

ステップＳ６５７では、ＣＰＵ１１は、ユーザアプリ遷移要求を「あり」に設定する。ユーザアプリ遷移要求の設定が完了すると、ＣＰＵ１１は、リプログ状態管理処理を終了する。

ステップＳ６５８では、ＣＰＵ１１は、リプログ状態を「セキュリティ解除待ち」に設定する。リプログ状態の設定が完了すると、ＣＰＵ１１は、リプログ状態管理処理を終了する。

本実施形態では、制御装置１００は、第１制御装置（マスターＥＣＵ）１と第２制御装置（スレーブＥＣＵ）２とのいずれで使用される場合においても、電源３がオンされた場合には、まず、リプログソフト１４３が起動され、リプログ初期化処理を経て無限ループ（図７のステップＳ３７）が実行される。強制書き換え要求がなければ、図１３の流れに従い、ユーザアプリ１４４に不具合がなければ、ステップＳ６５７によりユーザアプリ遷移要求が「あり」となり、無限ループ（ステップＳ３７）を抜け、ステップＳ４１によりソフトリセットされる。この後、リプログソフト１４３が再起動されるが、パワーオンリセットでなく、更に書き換え要求もないために、ステップＳ４６を経てユーザアプリ１４４が起動される。

（２－４．書き換えエントリー条件）
制御処理部１０は、所定条件を満たす場合に、制御装置１００を待機状態に設定する。待機状態とは、外部装置６との通信を利用した所定処理の開始を待つ待機処理を実行する状態である。待機状態において、制御処理部１０は、第１処理から第２処理への切り換えを行わない。これにより、所定処理の開始を待つことができる。本実施形態では、所定条件は、書き換えエントリー条件である。所定処理は、第２ソフトウェア１４４を書き換える書き換え処理である。具体的には、書き換えエントリー条件を満たすと、リプログ処理からユーザアプリ処理への遷移を行わず外部装置６との通信を利用した書き換え処理の開始を待つ待機状態が得られる。本実施形態によれば、第１制御装置１と第２制御装置２とのいずれにも適用できる制御装置１００におけるソフトウェアの書き換え処理を適切に行うことができる。

詳細には、書き換えエントリー条件を満たす方法には、強制エントリーを利用する方法と、通常エントリーを利用する方法と、リカバリーエントリーを利用する方法との３つがある。以下、これらについて説明する。

［２－４－１．強制エントリー］
強制エントリーは、通常エントリーおよびリカバリーエントリーを利用して書き換えエントリー条件を満たすことが出来ない場合でも、書き換えエントリー条件を満たす手法として用意されている。本実施形態では、強制エントリーは、ユーザアプリ１４４の実行は可能であるが、バグ等により、ユーザアプリ１４４の実行中に通常エントリーを利用することができない場合に利用される。なお、ユーザアプリ１４４の実行が可能である場合には、リカバリーエントリーを利用することはできない。

強制エントリーを利用する方法では、書き換えエントリー条件は、所定タイミグから第１時間が経過するまでの間に、自装置に対して発せられた所定処理の実行要求を受けた場合に満たされる。すなわち、制御処理部１０は、所定タイミグから第１時間が経過するまでの間に、自装置に対して発せられた所定処理の実行要求を受けた場合、所定処理の開始を待つ待機処理を実行する。本実施形態では、強制エントリーにより書き換えエントリー条件を満たす場合には、第１の場合と第２の場合とが含まれる。

なお、制御処理部１０は、第１処理の実行中、かつ、所定タイミングから第１時間が経過した場合、第１処理から第２処理への切り換えを行う。

第１の場合は、第１処理の実行中に、所定タイミングから第１時間が経過するまでの間に、第１制御装置１向けの所定処理の要求を受けた場合である。本実施形態では、所定タイミングは、第１ソフトウェア１４３の起動後、所定の初期化処理を完了したタイミングである。詳細には、所定の初期化処理は、リグログ初期化処理（図７のステップＳ３５）である。リプログ初期化処理から時間計測を行うことにより、時間計測を適切に行うことができる。また、本実施形態では、第１時間は強制書き換え要求待ち時間であり、５０ｍｓである。

第１の場合は、具体的には、制御装置１００において、パワーオンリセットによりリプログソフト１４３が起動され、リプログ初期化処理（図７のステップＳ３５）から強制書き換え要求待ち時間（５０ｍｓ）が経過するまでの間に、第１制御装置１向け（マスター向け）の強制書き換え要求を受けた場合である。マスター向けの強制書き換え要求により、図１２に示すステップＳ６３２ｄが実行されてリプログ状態が「セキュリティ解除待ち」になる。すなわち、ユーザアプリ１４４への遷移を行わず外部装置６との通信を利用した書き換え処理の開始を待つ待機状態になる。待機状態においては、第１処理において待機処理が実行される。待機処理とは、図７に示すメインタスクにおけるステップＳ３７の無限ループ内の処理である。待機処理では、外部装置６からのセキュリティ解除要求を待つ。セキュリティ解除要求を正常受信すると、フラッシュ制御ソフト遷移要求が「あり」となり、待機処理から抜けてフラッシュ制御ソフトを用いた書き換え処理が行われることになる。また、待機処理においては、並行して実行される定期タスクにおいて、ユーザアプリ遷移要求が「あり」に設定されることがない。そのため、第１処理から第２処理への切り換えが行われない。

なお、制御装置１００が第１制御装置１である場合には、上記の流れでユーザアプリ１４４の書き換え処理が行われる。ただし、制御装置１００が第２制御装置２である場合には、上記とは異なる流れで、強制エントリーを利用して書き換えエントリー条件が満たされる。これは、第２制御装置２は、第１制御装置１のゲートウェイ処理を利用して外部装置６から指示を受ける構成であり、第２制御装置２には、マスター向けのメッセージは届かないためである。

第２の場合は、第１処理の実行中に、所定タイミングから第１時間より短い第２時間が経過し、且つ、第１時間が経過するまでの間に、第２制御装置２向けの所定処理の要求を受けた場合である。本実施形態では、第２時間はスレーブ強制書き換え要求待ち時間であり、１０ｍｓである。

第２の場合は、具体的には、制御装置１００において、パワーオンリセットによりリプログソフト１４３が起動され、リプログ初期化処理（図７のステップＳ３５）からスレーブ強制書き換え要求待ち時間（１０ｍｓ）が経過し、且つ、強制書き換え要求待ち時間（５０ｍｓ）が経過するまでの間に、第２制御装置２向け（スレーブ向け）の強制書き換え要求を受けた場合である。

なお、制御処理部１０は、所定タイミングから第１時間より短い第２時間が経過するまでの間に、外部装置６との通信を利用した所定処理の実行要求を受け、当該実行要求が第２制御装置２として動作する制御装置１００に対して発せられたものである場合、第１時間の経過を待たずに、第１処理から第２処理への切り換えを行う。

図１４は、スレーブ向けの強制書き換え要求があった場合の処理の流れを示す模式図である。制御装置１００が第１制御装置１である場合、ゲートウェイ処理は不要であり、通常、スレーブ向けの強制書き換え要求は、リプログ初期化処理からスレーブ強制書き換え要求待ち時間（１０ｍｓ）が経過する前に受け取られる。すなわち、上述の「第２の場合」とはならない。第１制御装置１は、図１２のステップＳ６３２ｇでＹｅｓを経て、通常はユーザアプリ遷移要求を「あり」に設定する（ステップＳ６３２ｉ）。この結果、図７におけるステップＳ３７の無限ループから抜けて、ユーザアプリ１４４が起動する。これにより、ゲートウェイ処理が可能になる。本実施形態では、リプログ初期化処理から強制書き換え要求待ち時間（５０ｍｓ）が経過するまでの間にゲートウェイ処理が可能になるように、スレーブ強制書き換え要求待ち時間（１０ｍｓ）が設定されている。

一方、制御装置１００が第２制御装置２である場合、ゲートウェイ処理の利用が必要となるために、制御装置１００は、ＣＡＮ通信（外部通信）を利用して、スレーブ向けの強制書き換え要求をリプログ初期化処理からスレーブ強制書き換え要求待ち時間（１０ｍｓ）が経過する前に受け取ることはできない。ただし、制御装置１００は、強制書き換え要求待ち時間（５０ｍｓ）が経過する前であれば、スレーブ向けの強制書き換え要求を受け取ることができる。

このために、制御装置１００が第２制御装置２である場合には、例えば、制御装置１００のパワーオンリセットの時点からスレーブ向けの強制書き換え要求が実行されることにより、図１２のステップＳ６３２ｇでＮｏを経て、リプログ状態を「セキュリティ解除待ち」にすることができる（ステップＳ６３２ｌ）。すなわち、上述の「第２の場合」を得て、ユーザアプリ１４４への遷移を行わず外部装置６との通信を利用した書き換え処理の開始を待つ待機状態とすることができる。

本実施形態では、制御装置１００が第１制御装置１と第２制御装置２とのうちのいずれとして利用される場合でも、第２処理を開始させることなく所定処理を行うことができる。詳細には、制御装置１００がマスターＥＣＵとスレーブＥＣＵとのうちのいずれとして利用される場合でも、ユーザアプリ１４４を起動させない強制エントリーを利用した書き換え処理を行うことができる。

これについて、図１５に示す比較例を参考に更に説明する。図１５に示す比較例では、制御装置１００が第１制御装置１と第２制御装置２とのいずれとして利用される場合でも、強制エントリー条件が同じとされる。この場合でも、制御装置１００において、パワーオンリセットによりリプログソフト１４３が起動され、リプログ初期化処理から強制書き換え要求待ち時間（例えば１０ｍｓ）が経過するまでの間に、マスター向けの強制書き換え要求を受けることが可能である。すなわち、制御装置１００が第１制御装置１として利用された場合、上述の「第１の場合」を経て強制エントリーすることができる。

しかしながら、制御装置１００が第２制御装置２として利用される場合、第１制御装置１のゲートウェイ処理が前提となる。すなわち、第２制御装置２は、第１制御装置１がゲートウェイ処理可能な状態にならないと、ＣＡＮ通信（外部通信）を利用できない。スレーブ向けの強制書き換え要求を行った場合、第１制御装置１は、図１３と同様の処理により、強制書き換え要求待ち時間の経過を経てユーザアプリ１４４を起動する。この間、第２制御装置２でも、同様に強制書き換え要求待ち時間が経過するために、第１制御装置１がゲートウェイ処理可能となるタイミングでは、第２制御装置２においてもユーザアプリ１４４が起動した状態になる。すなわち、制御装置１００が第２制御装置２として使用される場合には、強制エントリーをすることができない。この点、本実施形態では、マスター向けとスレーブ向けとで強制書き換え要求に対する待ち時間の設定の仕方を変えて処理が行われるために、制御装置１００が第１制御装置１と第２制御装置２とのいずれに利用される場合でも強制エントリーを行うことができる。

［２－４－２．通常エントリー］
書き換えエントリー条件には、第２処理（ユーザアプリ処理）が動作した後に満たされるものがある。本実施形態では、このように書き換えエントリー条件を満たす手法を通常エントリーとしている。

通常エントリーを利用する方法では、書き換えエントリー条件は、第２処理の実行中に、自装置１００に対して発せられた所定処理の実行要求を受けた場合に満たされる。すなわち、制御処理部１０は、第２処理の実行中に、自装置１００に対して発せられた所定処理の実行要求を受けた場合、待機処理を実行する。本実施形態では、通常エントリーにより書き換えエントリー条件を満たす場合は、第２処理の実行中に、外部装置６から第１制御装置１向け又は第２制御装置２向けの所定処理の実行要求を受けた第３の場合である。第３の場合は、具体的には、ユーザアプリ１４４の起動によるユーザアプリ処理の実行中に、外部装置６からマスター向け又はスレーブ向けの書き換え要求を受けた場合である。

図１６は、通常エントリーを説明するためのフローチャートである。ＣＰＵ１１は、ユーザアプリ１４４の起動時において書き換え要求を受けると、ステップＳ７１の処理を行う。ステップＳ７１では、ＣＰＵ１１は、書き換え要求を「あり」に設定する。なお、書き換え要求フラグの状態は、ソフトウェアリセットで消去されない記憶領域に記憶される。書き換え要求を「あり」に設定すると、ＣＰＵ１１は次のステップＳ７２に処理を進める。

ステップＳ７２では、ＣＰＵ１１は、ユーザアプリ終了処理を行う。ユーザアプリ終了処理は、ソフトウェアリセットの前に必要となる処理である。ユーザアプリ終了処理を行うと、ＣＰＵ１１は次のステップＳ７３に処理を進める。

ステップＳ７３では、ＣＰＵ１１はソフトウェアリセットを行う。これにより、図７に示すように、ＣＰＵ１１は、リプログソフト１４３を起動させる。パワーオンリセットでないリセットであり、書き換え要求が「あり」であるために、ステップＳ４２でＹｅｓを経て、リプログ状態が「セキュリティ解除待ち」になる。すなわち、ユーザアプリ１４４への遷移を行わず外部装置６との通信を利用した書き換え処理の開始を待つ待機状態が得られる。

本実施形態によれば、制御装置１００が第１制御装置１と第２制御装置２とのうちのいずれとして利用される場合でも、第２処理を起動させた後に所定処理を開始させることができる。詳細には、制御装置１００がマスターＥＣＵとスレーブＥＣＵとのうちのいずれとして利用される場合でも、ユーザアプリ１４４を起動させた後に通常エントリーを利用した書き換え処理を行うことができる。

［２－４－３．リカバリーエントリー］
書き換えエントリー条件には、ユーザアプリ１４４が不完全な状態でＲＯＭ１４に記憶されていると判断されることにより満たされるものがある。リカバリーエントリーは、不完全なソフトウェアを用いて制御装置１００を起動させることを避けることを目的として設けられている。

リカバリーエントリーを利用する方法では、書き換えエントリー条件は、第１処理の実行中に、所定タイミングから第１時間が経過するまでの間に所定処理の実行要求を受けず、且つ、第２ソフトウェア１４４に不具合があると判断された場合に満たされる。すなわち、制御処理部１０は、第１処理の実行中に、所定タイミングから第１時間が経過するまでの間に所定処理の実行要求を受けず、且つ、第２ソフトウェア１４４に不具合があると判断された場合、待機処理を実行する。本実施形態では、リカバリーエントリーにより書き換えエントリー条件を満たす場合は、第１処理の実行中に、所定タイミングから第１時間が経過するまでの間に所定処理の実行要求を受けず、且つ、第２ソフトウェア１４４に不具合があると判断された第４の場合である。

なお、本実施形態では、制御処理部１０は、先に行われた第２ソフトウェア１４４の書き換え処理が中断したと判断される場合に、第２ソフトウェア１４４に不具合があると判断する。書き換え処理の中断があったか否かは、上述のリプログ中断情報により判断することができる。また、制御処理部１０は、第２ソフトウェア１４４の有効性判定により第２ソフトウェア１４４が有効でないと判断された場合に第２ソフトウェア１４４に不具合があると判断する。第２ソフトウェア１４４の有効性判定には、例えばＲＯＭＳＵＭチェックを利用することができる。本実施形態によれば、第２ソフトウェアに不具合があるか否かを適切に判断することができる。

第４の場合は、具体的には、制御装置１００において、パワーオンリセットによりリプログソフト１４３が起動され、リプログ初期化処理（図７のステップＳ３５）から強制書き換え要求待ち時間（５０ｍｓ）が経過するまでの間に書き換え要求を受けず、且つ、ユーザアプリ１４４に不具合があると判断された場合である。リプログ初期化処理から強制書き換え要求待ち時間（５０ｍｓ）が経過するまでの間に書き換え要求を受けない場合、図１３のステップＳ６５５でＹｅｓとなり、ステップＳ６５６でユーザアプリ１４４に不具合があるか否かが判断される。ユーザアプリ１４４に不具合があるためにステップＳ６５６でＮｏとなり、ステップＳ６５８が実行されてリプログ状態が「セキュリティ解除待ち」になる。すなわち、ユーザアプリ１４４への遷移を行わず外部装置６との通信を利用した書き換え処理の開始を待つ待機状態が得られる。

本実施形態によれば、制御装置１００が第１制御装置１と第２制御装置２とのうちのいずれとして利用される場合でも、ソフトウェアの不具合により第２処理を起動させることができない場合でも、強制エントリーとは別の手法により所定処理を行うことができる。詳細には、制御装置１００がマスターＥＣＵとスレーブＥＣＵとのうちのいずれとして利用される場合でも、ユーザアプリ１４４に不具合が認められる場合にユーザアプリ１４４の書き換え処理を行うように導くことができる。すなわち、不具合があるソフトウェアの実行を事前に防ぐことができる。

＜４．留意事項＞
本明細書における実施形態や変形例の構成は、本発明の例示にすぎない。実施形態や変形例の構成は、本発明の技術的思想を超えない範囲で適宜変更されてもよい。また、複数の実施形態及び変形例は、可能な範囲で組み合わせて実施されてよい。

１・・・第１制御装置
２・・・第２制御装置
６・・・外部装置
１０・・・制御処理部
１４・・・ＲＯＭ（不揮発性記憶部）
１００・・・制御装置
１４３・・・リプログソフト（第１ソフトウェア）
１４４・・・ユーザアプリ（第２ソフトウェア）
２００・・・制御装置システム

Claims (8)

1. 外部装置と通信可能に設けられる第１制御装置と、前記第１制御装置を介して前記外部装置と通信可能に設けられる第２制御装置とのいずれにも使用可能な制御装置であって、
   前記制御装置は、
   第１処理と第２処理とを切り換えて実行可能に設けられる制御処理部と、
   前記第１処理の実行を可能とする第１ソフトウェアと、前記第２処理の実行を可能とする第２ソフトウェアとを記憶する不揮発性記憶部と、
   を有し、
   前記第１処理は、前記外部装置からの要求に従って前記第２ソフトウェアを書き換える書き換え処理を含み、
   前記第２処理は、自装置が前記第１制御装置と前記第２制御装置とのうちのいずれであるかを判定する判定処理、及び自装置が前記第１制御装置である場合に、前記外部装置からの指令を前記第２制御装置に転送するゲートウェイ処理を含み、
   前記制御処理部は、
   当該制御装置のリセット後に前記第１処理を起動し、前記第１処理の実行中、かつ、所定タイミングから第１時間が経過した場合、
   前記第１処理から前記第２処理への切り換えを行い、
   前記所定タイミングから、前記第１時間より短い第２時間が経過するまでの間に、前記外部装置との通信を利用した前記書き換え処理の実行要求を受け、前記実行要求が前記第２制御装置として動作する前記制御装置に対して発せられたものである場合、
   前記第１時間の経過を待たずに前記第１処理から前記第２処理への切り換えを行う、制御装置。
2. 前記制御処理部は、
   前記所定タイミングから前記第１時間が経過するまでの間に、自装置に対して発せられた前記書き換え処理の実行要求を受けた場合、前記書き換え処理の開始を待つ待機処理を実行する、請求項１に記載の制御装置。
3. 前記制御処理部は、
   前記第２処理の実行中に、自装置に対して発せられた前記書き換え処理の実行要求を受けた場合、前記待機処理を実行する、請求項２に記載の制御装置。
4. 前記制御処理部は、
   前記第１処理の実行中に、前記所定タイミングから前記第１時間が経過するまでの間に前記書き換え処理の実行要求を受けず、且つ、前記第２ソフトウェアに不具合があると判断された場合、前記待機処理を実行する、請求項１から３のいずれか１項に記載の制御装置。
5. 前記制御処理部は、先に行われた前記第２ソフトウェアの書き換え処理が中断したと判断された場合と、前記第２ソフトウェアの有効性判定により前記第２ソフトウェアが有効でないと判断された場合とに、前記第２ソフトウェアに不具合があると判断する、請求項４に記載の制御装置。
6. 前記所定タイミングは、前記第１ソフトウェアの起動後、所定の初期化処理が完了したタイミングである、請求項１から５のいずれか１項に記載の制御装置。
7. 前記第１制御装置として使用される請求項１から６のいずれか１項に記載の制御装置と、
   前記第２制御装置として使用される請求項１から６のいずれか１項に記載の制御装置と、
   を有する、制御装置システム
8. 外部装置と通信可能に設けられる第１制御装置と、前記第１制御装置を介して前記外部装置に通信可能に設けられる第２制御装置とのいずれにも使用可能な制御装置の制御方法であって、
   前記制御装置は、第１処理と第２処理とを切り換えて実行可能に設けられると共に、前記第１処理の実行を可能とする第１ソフトウェアと、前記第２処理の実行を可能とする第２ソフトウェアとを記憶し、
   前記第１処理は、前記外部装置からの要求に従って前記第２ソフトウェアを書き換える書き換え処理を含み、
   前記第２処理は、自装置が前記第１制御装置と前記第２制御装置とのうちのいずれであるかを判定する判定処理、及び自装置が前記第１制御装置である場合に、前記外部装置からの指令を前記第２制御装置に転送するゲートウェイ処理を含み、
   当該制御装置のリセット後に前記第１処理を起動し、前記第１処理の実行中、かつ、所定タイミングから第１時間が経過した場合、
   前記第１処理から前記第２処理への切り換えを行い、
   前記所定タイミングから、前記第１時間より短い第２時間が経過するまでの間に、前記外部装置との通信を利用した前記書き換え処理の実行要求を受け、前記実行要求が前記第２制御装置として動作する前記制御装置に対して発せられたものである場合、
   前記第１時間の経過を待たずに前記第１処理から前記第２処理への切り換えを行う、制御方法。

Images