JP6922417B2 - 並行処理装置及び並行処理プログラム - Google Patents

Description

本発明は、並行処理装置及び並行処理プログラムに関する。

従来より、電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）を接続し、ＥＣＵに対するリプログアプリ、故障診断アプリ、鍵管理アプリ等の様々な独立したアプリの処理要求を受け付ける処理装置が供されている（例えば特許文献１参照）。

特開２００３−４６５３６号公報

この種の処理装置は、ＥＣＵに対する処理要求を受け付けると、その受け付けた処理要求に応じた処理を実行する。この場合、処理装置は、処理要求の要求先であるＥＣＵとの間で１対１の通信を順番に実行し、処理要求を受け付けた順序にしたがって処理を順番に実行する。即ち、処理装置は、ＥＣＵに対する一の処理要求を受け付けると、その受け付けた一の処理要求に応じた一の処理を開始する。処理装置は、一の処理を完了する前、即ち一の処理を実行中にＥＣＵに対する別の処理要求を受け付けると、その受け付けた別の処理要求に応じた別の処理の開始を待機する。そして、処理装置は、一の処理を完了すると、その待機中の別の処理を開始する。

一方、近年では、制御の複雑化によるＥＣＵのプログラム容量の増加やシステムの複雑化等により、複数の処理をマルチタスクで実行する必要性が増している。しかしながら、前述した一の処理を完了するまで別の処理の開始を待機する構成では、複数の処理をマルチタスクで実行することはできない。

本発明は、上記した事情に鑑みてなされたものであり、その目的は、独立したアプリの処理要求を複数同時に受け付けた場合に、その受け付けた複数の処理要求に応じた複数の処理をマルチタスクで実行することができる並行処理装置及び並行処理プログラムを提供することにある。

請求項１に記載した発明によれば、処理要求受付部（２７）は、一又は複数の装置からデータコミュニケーションモジュールに送信されたアプリであって電子制御装置（１１ａ〜１１ｃ，１２ａ〜１２ｃ，１３ａ〜１３ｃ，１４ａ〜１４ｃ）に対する当該アプリの処理要求を一又は複数の装置からデータコミュニケーションモジュールを介して受け付ける。処理実行部（３１）は、一又は複数の装置から前記データコミュニケーションモジュールを介して一のアプリの処理要求を前記処理要求受付部により受け付け、前記一のアプリの処理要求を受け付け中に、前記一又は複数の装置から前記データコミュニケーションモジュールを介して他のアプリの処理要求を前記処理要求受付部により受け付けると、先に受け付けた前記一のアプリの処理要求と後から受け付けた前記他のアプリの処理要求とを調停する。処理実行部は、前記一のアプリの処理要求の信号を送信してから当該一のアプリの処理要求の信号の応答を受信するまでの期間内で、前記他のアプリの処理要求の信号を送信することで、前記一のアプリの処理要求に応じた前記一の処理と前記他のアプリの処理要求に応じた他の処理とを並行して一以上の前記電子制御装置に実行させ、当該一のアプリの処理要求の信号の応答及び当該他のアプリの処理要求の信号の応答を受信し、複数のアプリの処理要求に応じた複数の処理を並行して一以上の前記電子制御装置に実行させる。

電子制御装置に対する一の処理要求を受け付けると、その受け付けた一の処理要求に応じた一の処理を開始する。その後、一の処理を完了する前、即ち一の処理を実行中に電子制御装置に対する別の処理要求を受け付けると、その受け付けた別の処理要求に応じた別の処理の開始を待機せずに、受け付け中の一の処理要求と別の処理要求とを調停し、それら一の処理要求に応じた一の処理と別の処理要求に応じた別の処理とを並行する。これにより、独立したアプリの処理要求を複数同時に受け付けた場合に、その受け付けた複数の処理要求に応じた複数の処理をマルチタスクで実行することができる。

一実施形態のシステム全体の構成を示す図 中央ゲートウェイ装置の構成を示す機能ブロック図 クライアントプログラムの構成を示す図 データの階層を示す図 セッション状態の遷移を示す図 全体の処理を示すフローチャート 接続態様を示す図 シーケンス図 フローチャート 接続態様を示す図 シーケンス図 フローチャート 接続態様を示す図 シーケンス図 フローチャート 接続態様を示す図 シーケンス図 フローチャート フローチャート 接続態様を示す図 接続態様を示す図 シーケンス図 シーケンス図 シーケンス図 シーケンス図 シーケンス図 シーケンス図

以下、本発明を、車両に搭載される並行処理装置に適用した一実施形態について図面を参照して説明する。
マスタ電子制御装置（以下、マスタＥＣＵ（Electronic Control Unit）と称する）１は、データコミュニケーションモジュール（以下、ＤＣＭ（Data Communication Module）と称する）２と、中央ゲートウェイ装置（以下、ＣＧＷ（Central Gate Way）と称する）３（並行処理装置に相当する）とを有する。

ＤＣＭ２は、センター４、ユーザデバイス５、ツール６との間で車外ネットワークを介したデータ通信を制御する。即ち、ＤＣＭ２は、センター４との間で例えば３Ｇ回線や４Ｇ回線等による移動体通信網を介したデータ通信を制御する。又、ＤＣＭ２は、ユーザデバイス５との間で例えばＷｉＦｉ（登録商標）やＢｌｕｅｔｏｏｔｈ（登録商標）を介したデータ通信を制御する。又、ＤＣＭ２は、ツール６との間で例えば有線接続によるデータ通信を制御する。ＤＣＭ２は、センター４、ユーザデバイス５、ツール６等からアプリを受信すると、その受信したアプリをＣＧＷ３に送信する。例えばユーザがツール６を操作してリプログアプリを起動すると、ＤＣＭ２は、ツール６からリプログアプリを受信し、その受信したリプログアプリをＣＧＷ３に送信する。又、例えばユーザがツール６を操作して故障診断アプリを起動すると、ＤＣＭ２は、ツール６から故障診断アプリを受信し、その受信した故障診断アプリをＣＧＷ３に送信する。

ＣＧＷ３は、ＤＣＭ２からアプリを受信すると、そのアプリの処理要求を受け付ける。ＣＧＷ３は、例えばＤＣＭ２からリプログアプリを受信すると、そのリプログアプリの処理要求を受け付ける。又、ＣＧＷ３は、例えばＤＣＭ２から故障診断アプリを受信すると、その故障診断アプリの処理要求を受け付ける。

ＣＧＷ３は、複数のバス７〜１０を接続しており、車両に搭載されているＥＣＵとの間でバス７〜１０を介したデータ通信を制御する。バス７〜１０は、例えばマルチメディア系のバス、パワトレ系のバス、ボディ系のバス、環境系のバス、シャシ系のバス等である。バス７〜１０は、例えばＣＡＮ（Controller Area Network）（登録商標）、ＬＩＮ（Local Interconnect Network）（登録商標）、ＣＸＰＩ（Clock Extension Peripheral Interface）（登録商標）、ＦｌｅｘＲａｙ（登録商標）、ＭＯＳＴ（Media Oriented Systems Transport）（登録商標）等であり、通信プロトコルが互いに異なり、通信速度や信号フォーマットが互いに異なる。

バス７〜１０にはそれぞれＥＣＵ１１ａ〜１１ｃ、１２ａ〜１２ｃ、１３ａ〜１３ｃ、１４ａ〜１４ｃが接続されている。例えばマルチメディア系のバスには、ナビゲーションの制御を行うナビゲーションＥＣＵ、電子式料金収受システム（ＥＴＣ：Electronic Toll Collection System：登録商標）との通信制御を行うＥＴＣＥＣＵ等が接続されている。例えばパワトレ系のバスには、エンジンの制御を行うエンジンＥＣＵ、ブレーキの制御を行うブレーキＥＣＵ、自動変速機の制御を行うＥＣＴＥＣＵ、パワーステアリングの制御を行うパワステＥＣＵ等が接続されている。例えばボディ系のバスには、ドアのロック／アンロックの制御を行うドアＥＣＵ、メータの表示制御を行うメータＥＣＵ、エアコンの制御を行うエアコンＥＣＵ、ウィンドウの開閉制御を行うウィンドウＥＣＵ等が接続されている。

図２に示すように、ＣＧＷ３は、マイクロコンピュータ（以下、マイコンと称する）１５と、トランシーバ１６と、電源回路１７とを有する。マイコン１５は、ＣＰＵ１８と、非遷移的記録媒体としてのＲＯＭ１９と、ＲＡＭ２０と、フラッシュメモリ２１とが内部バス２２を介して相互接続されている。マイコン１５は、ＲＯＭ１９に格納されている制御プログラムをＣＰＵ１８が実行し、ＣＧＷ３の動作を制御する。トランシーバ１６は、マイコン１５からの命令により、ＤＣＭ２とのデータ通信を制御すると共に、バス７〜１０を介したＥＣＵ１１ａ〜１１ｃ、１２ａ〜１２ｃ、１３ａ〜１３ｃ、１４ａ〜１４ｃとのデータ通信を制御する。電源回路１７は、アクセサリスイッチのオンオフを示すアクセサリ信号及びイグニッションスイッチのオンオフを示すイグニッション信号を入力する。電源回路１７は、例えばアクセサリ信号のオフからオンへの切り換えを検知すると、バッテリ電源から供給された電力から動作電力を生成し、その生成した動作電力をマイコン１５及びトランシーバ１６に供給する。

ＲＯＭ１９には、制御プログラムの１つとしてクライアントプログラムが格納されている。クライアントプログラム２３は、並行処理プログラムを含み、図３に示すように、各種データを格納する機能として、管理情報マスタデータを格納する管理情報マスタデータ格納部２４、管理情報バスマスタデータを格納する管理情報バスマスタデータ格納部２５、管理情報データを格納する管理情報データ格納部２６を有する。管理情報マスタデータ格納部２４は、バス７〜１０の通信速度に関するデータ、スケジューリングの調整に関するデータ等を管理情報マスタデータとして格納している。管理情報バスマスタデータ格納部２５は、管理情報データを割り当て済みのＥＣＵ１１ａ〜１１ｃ、１２ａ〜１２ｃ、１３ａ〜１３ｃ、１４ａ〜１４ｃに関するデータ、バス負荷の調整に関するデータ等を管理情報バスマスタデータとして格納している。管理情報データ格納部２６は、受け付け中の処理要求の優先度に関するデータ、バス７〜１０の状態に関するデータ、ＥＣＵ１１ａ〜１１ｃ、１２ａ〜１２ｃ、１３ａ〜１３ｃ、１４ａ〜１４ｃの状態に関するデータ、処理の進捗状態に関するデータ、処理のセッション状態に関するデータ等を管理情報データとして格納している。図４に示すように、クライアントプログラム２３は、これらの管理情報マスタデータ、管理情報バスマスタデータ、管理情報データを階層化して管理している。

又、クライアントプログラム２３は、処理要求受付部２７、管理情報マスタ更新部２８、管理情報バスマスタ更新部２９、管理情報割り当て部３０、処理実行部３１、スケジューリング調整部３２、バス負荷調整部３３、進捗状態判断部３４、セッション状態判断部３５を有する。

処理要求受付部２７は、ＥＣＵ１１ａ〜１１ｃ、１２ａ〜１２ｃ、１３ａ〜１３ｃ、１４ａ〜１４ｃに対する独立したアプリの処理要求を受け付ける。処理要求受付部２７が処理要求を受け付けるアプリは、例えばリプログアプリ、故障診断アプリ、鍵管理アプリ等である。管理情報マスタ更新部２８及び管理情報バスマスタ更新部２９は、それぞれ処理実行部３１が処理を実行することに応じて変化するバス７〜１０の状態やＥＣＵ１１ａ〜１１ｃ、１２ａ〜１２ｃ、１３ａ〜１３ｃ、１４ａ〜１４ｃの状態を監視し、状態が変化することに応じて管理情報マスタデータ及び管理情報バスマスタデータの更新を行う。管理情報割り当て部３０は、管理情報マスタデータ及び管理情報バスマスタデータを参照し、管理情報データを処理要求に割り当てる。

処理実行部３１は、管理情報マスタデータ、管理情報バスマスタデータ、管理情報データを参照し、複数のアプリの処理要求を調停する。即ち、処理実行部３３は、一のアプリの処理要求を受け付け中に別のアプリの処理要求を受け付けると、一のアプリの処理要求と別のアプリの処理要求との優先度、その時点でのバス７〜１０の状態やＥＣＵ１１ａ〜１１ｃ、１２ａ〜１２ｃ、１３ａ〜１３ｃ、１４ａ〜１４ｃの状態等を判断し、一のアプリの処理要求と別のアプリの処理要求とを調停する。処理実行部３１は、例えば一のアプリの処理要求が別のアプリの処理要求よりも優先度が高ければ一のアプリの処理要求に応じた処理を優先するように調停する。これとは逆に、処理実行部３１は、例えば別のアプリの処理要求が一のアプリの処理要求よりも優先度が高ければ別のアプリの処理要求に応じた処理を優先するように調停する。又、処理実行部３１は、処理要求の要求先であるＥＣＵの負荷やバスの負荷が比較的低ければ処理を実行し、負荷が比較的高ければ処理の実行を待機するように調停する。

スケジューリング調整部３２は、管理情報マスタデータ格納部２４に格納されているスケジューリングの調整に関するデータを用い、スケジューリングの調整を行う。スケジューリング調整部３２は、スケジューリングの調整として例えば信号の送信間隔を調整する。バス負荷調整部３３は、管理情報バスマスタデータ格納部２５に格納されているバス負荷の調整に関するデータを用い、バス負荷の調整を行う。バス負荷調整部３３は、バス負荷の調整としてバスのデータ通信量を調整する。進捗状態判断部３４は、管理情報データ格納部２６に格納されている進捗状態に関するデータを用い、処理の進捗状態の判断を行う。セッション状態判断部３５は、管理情報データ格納部２６に格納されているセッション状態に関するデータを用い、処理のセッション状態の判断を行う。

処理実行部３１は、複数のアプリの処理要求を調停すると、スケジューリング調整部３２により調整されたスケジューリング及びバス負荷調整部３３により調整されたバス負荷にしたがい、進捗状態判断部３４により判断された進捗状態及びセッション状態判断部３５により判断されたセッション状態を監視しながら複数の処理を並行する。

ここで、セッション状態を監視する理由について説明する。図５に示すように、ＥＣＵは、通常状態にあるときにセッション移行要求信号を受信すると、通常状態から故障診断状態に移行するが、その後に故障診断要求信号を受信しない時間が所定時間（例えば５秒）継続すると、タイムアウトが発生して故障診断状態から通常状態から復帰する。このような事情から、クライアントプログラム２３は、セッション移行要求信号を定期的にＥＣＵに送信することで、故障診断要求信号を送信する間隔が所定時間を越えてもＥＣＵを故障診断状態に維持することが可能となる。

又、ＥＣＵは、故障診断状態にあるときにセッション移行要求信号を受信すると、故障診断状態からリプログ状態に移行するが、その後にリプログデータを含むデータ信号を受信しない時間が所定時間（例えば５秒）継続すると、タイムアウトが発生してリプログ状態から通常状態から復帰する。このような事情から、クライアントプログラム２３は、セッション移行要求信号を定期的にＥＣＵに送信することで、リプログデータを含むデータ信号を送信する間隔が所定時間を越えてもＥＣＵをリプログ状態に維持することが可能となる。

次に、上記した構成の作用について図６から図２７を参照して説明する。
ＣＧＷ３において、マイコン１５は、ＣＰＵ１８がクライアントプログラム２３を実行することで以下の制御を行う。

マイコン１５は、アプリの処理要求を処理要求受付部２４が受け付けると（Ｓ１、処理要求受付手順）、その受け付けたアプリの処理要求を調停する（Ｓ２、調停手順）。即ち、マイコン１５は、受け付け中のアプリの処理要求の優先度に関するデータ、バス７〜１０の状態に関するデータ、ＥＣＵ１１ａ〜１１ｃ、１２ａ〜１２ｃ、１３ａ〜１３ｃ、１４ａ〜１４ｃの状態に関するデータを用い、その受け付けた処理要求に応じた処理を実行可能であるか否かを判断し、アプリの処理要求を調停する。マイコン１５は、その受け付けたアプリの処理要求を調停したことでアプリの競合を回避したか否かを判定し（Ｓ３）、アプリの競合を回避したと判定すると（Ｓ３：ＹＥＳ）、管理情報データを処理要求に割り当てる（Ｓ４）。

マイコン１５は、管理情報データを処理要求に割り当てると、管理情報マスタデータを更新する（Ｓ５）。マイコン１５は、複数の処理要求に応じた複数の処理のスケジューリングを調整し（Ｓ６）、複数の処理のスケジューリングを調整すると、管理情報バスマスタデータを更新する（Ｓ７）。マイコン１５は、バス負荷を計算し（Ｓ８）、バス負荷を監視し（Ｓ９）、処理要求の要求先のＥＣＵに送信する信号の送信間隔を調整する（Ｓ１０）。そして、マイコン１５は、進捗状態及びセッション状態を監視しながら複数の処理を並行する（Ｓ１１、処理並行手順）。

以下、ＥＣＵの接続態様として、バスに接続されている同一のＥＣＵに対する複数の処理要求を同時に受け付けた場合、同一のバスに接続されている複数のＥＣＵに対する複数の処理要求を同時に受け付けた場合、別々のバスに接続されている複数の電子制御装置に対する複数の処理要求を同時に受け付けた場合について説明する。

（１）バスに接続されている同一のＥＣＵに対する複数の処理要求を同時に受け付けた場合
図７に示すように、マイコン１５は、ＣＧＷ３がバス４１を接続し、バス４１にエンジンＥＣＵ５１が接続されており、そのエンジンＥＣＵ５１に対するリプログアプリの処理要求と故障診断アプリの処理要求とを同時に受け付けると、それらの処理要求を調停し、図８に示すように、リプログデータを含むデータ信号の送信と故障診断要求信号の送信とを並行する。この場合、同時に受け付けるとは、リプログアプリの処理要求に応じたリプログ処理を実行中に故障診断アプリの処理要求を受け付けた場合、又は故障診断アプリの処理要求に応じた故障診断処理を実行中にリプログアプリの処理要求を受け付けた場合を意味する。

マイコン１５は、リプログデータを含むデータ信号を送信してからリプログ応答信号を受信するまでの期間内において、故障診断要求信号を送信してもエンジンＥＣＵ５１の負荷及びバス４１の負荷に支障がない（例えば他の処理や他のバス通信を妨げない等）と判断すると、その期間内で故障診断要求信号を送信する。又、マイコン１５は、故障診断要求信号を送信してから故障診断データ（例えばＤＴＣコード等の各種データ）を含むデータ信号を受信するまでの期間内において、リプログデータを含むデータ信号を送信してもエンジンＥＣＵ５１の負荷及びバス４１の負荷に支障がないと判断すると、その期間内でリプログデータを含むデータ信号を送信する。このようにして、マイコン１５は、エンジンＥＣＵ５１に対するリプログ処理と故障診断処理とをマルチタスクで実行する。即ち、マイコン１５は、エンジンＥＣＵ５１に対するリプログ処理と故障診断処理とを、一方の処理の完了を待機して他方の処理を開始するのではなく、エンジンＥＣＵ５１の負荷及びバス４１の負荷に応じてマルチタスクで実行することで、それらの処理を完了するまでに要する時間を短縮することが可能となる。

マイコン１５は、図９に示すように、エンジンＥＣＵ５１に対するリプログ処理として、リプログのエントリ処理（Ｓ２１）、エンジンＥＣＵ５１のフラッシュメモリに記憶されているデータの消去（Ｓ２２）、リプログデータを含むデータ信号の送信（Ｓ２３）、リプログ応答信号の受信（Ｓ２４）、リプログの検証（Ｓ２５）、エンジンＥＣＵ５１の初期化（Ｓ２６）を実行する。又、マイコン１５は、エンジンＥＣＵ５１に対する故障診断処理として、故障診断要求信号の送信（Ｓ３１）、故障診断データを含むデータ信号の受信（Ｓ３２）を実行する。

又、マイコン１５は、リプログデータを含むデータ信号の送信と故障診断要求信号の送信とに加え、ＤＣＭ２からのリプログデータの受信を並行しても良い。即ち、図１０に示すように、エンジンＥＣＵ５１のリプログデータがＤＣＭ２に格納されている構成である場合に、図１１に示すように、マイコン１５は、例えば故障診断要求信号を送信してからリプログ応答信号を受信するまでの期間内でリプログデータの要求信号をＤＣＭ２に送信し、故障診断データを含むデータ信号を受信してからリプログデータを含むデータ信号を送信するまでの期間内でＤＣＭ２からリプログデータを含むデータ信号を受信する。

このようにして、マイコン１５は、エンジンＥＣＵ５１に対するリプログアプリの処理要求に応じたリプログ処理及び故障診断アプリの処理要求に応じた故障診断処理と、ＤＣＭ２からリプログデータを取得する処理とをマルチタスクで実行する。マイコン１５は、図１２に示すように、リプログデータの取得処理として、データ要求信号の送信（Ｓ４１）、リプログデータを含むデータ信号の取得（Ｓ４２）を実行する。

このような構成では、ＣＧＷ３においては、ＤＣＭ２から取得したリプログデータをエンジンＥＣＵ５１に送信するので、エンジンＥＣＵ５１に送信するリプログデータを記憶しておくための記憶媒体の容量を低減することができる。尚、データ要求信号をＤＣＭ２に送信するタイミング及びＤＣＭ２からリプログデータを含むデータ信号を受信するタイミングはどのようなタイミングでも良い。又、以上は、エンジンＥＣＵ５１に対する２つの処理要求を同時に受け付けた場合を例示したが、エンジンＥＣＵ５１に対する３つ以上の処理要求を同時に受け付けた場合も同様である。

（２）同一のバスに接続されている複数のＥＣＵに対する複数の処理要求を同時に受け付けた場合
図１３に示すように、マイコン１５は、ＣＧＷ３がバス４２を接続し、バス４２にエンジンＥＣＵ５２とメータＥＣＵ５３とが接続されており、そのエンジンＥＣＵ５２に対するリプログアプリの処理要求とメータＥＣＵ５３に対するリプログアプリの処理要求とを同時に受け付けると、それらの処理要求を調停し、図１４に示すように、エンジンＥＣＵ５２のリプログデータを含むデータ信号の送信とメータＥＣＵ５３のリプログデータを含むデータ信号の送信とを並行する。この場合、同時に受け付けるとは、エンジンＥＣＵ５２に対するリプログアプリの処理要求に応じたリプログ処理を実行中にメータＥＣＵ５３に対するリプログアプリの処理要求を受け付けた場合、又はメータＥＣＵ５３に対するリプログアプリの処理要求に応じたリプログ処理を実行中にエンジンＥＣＵ５２に対するリプログアプリの処理要求を受け付けた場合を意味する。

マイコン１５は、エンジンＥＣＵ５２のリプログデータを含むデータ信号を送信してからリプログ応答信号を受信するまでの期間内において、メータＥＣＵ５３のリプログデータを含むデータ信号を送信してもメータＥＣＵ５３の負荷及びバス４２の負荷に支障がないと判断すると、その期間内でメータＥＣＵ５３のリプログデータを含むデータ信号を送信する。又、マイコン１５は、メータＥＣＵ５３のリプログデータを含むデータ信号を送信してからリプログ応答信号を受信するまでの期間内において、エンジンＥＣＵ５２のリプログデータを含むデータ信号を送信してもエンジンＥＣＵ５２の負荷及びバス４２の負荷に支障がないと判断すると、その期間内でエンジンＥＣＵ５２のリプログデータを含むデータ信号を送信する。

このようにして、マイコン１５は、エンジンＥＣＵ５２に対するリプログ処理とメータＥＣＵ５３に対するリプログ処理とをマルチタスクで実行する。即ち、マイコン１５は、エンジンＥＣＵ５２に対するリプログ処理とメータＥＣＵ５３に対するリプログ処理とを、一方の処理の完了を待機して他方の処理を開始するのではなく、エンジンＥＣＵ５２の負荷、メータＥＣＵ５３の負荷及びバス４２の負荷に応じてマルチタスクで実行することで、それらの処理を完了するまでに要する時間を短縮することが可能となる。

マイコン１５は、図１５に示すように、エンジンＥＣＵ５２に対するリプログ処理として、リプログのエントリ処理（Ｓ５１）、エンジンＥＣＵ５２のフラッシュメモリに記憶されているデータの消去（Ｓ５２）、リプログデータを含むデータ信号の送信（Ｓ５３）、リプログ応答信号の受信（Ｓ５４）、リプログの検証（Ｓ５５）、エンジンＥＣＵ５２の初期化（Ｓ５６）を実行する。又、マイコン１５は、メータＥＣＵ５３に対するリプログ処理として、リプログのエントリ処理（Ｓ６１）、メータＥＣＵ５３のフラッシュメモリに記憶されているデータの消去（Ｓ６２）、リプログデータを含むデータ信号の送信（Ｓ６３）、リプログ応答信号の受信（Ｓ６４）、リプログの検証（Ｓ６５）、メータＥＣＵ５３の初期化（Ｓ６６）を実行する。

この場合も、マイコン１５は、リプログデータを含むデータ信号の送信に加え、ＤＣＭ２からのリプログデータの受信を並行しても良い。即ち、図１６に示すように、エンジンＥＣＵ５２のリプログデータ及びメータＥＣＵ５３のリプログデータがＤＣＭ２に格納されている構成である場合に、マイコン１５は、図１７から図１９に示すように、エンジンＥＣＵ５２に対するリプログ処理及びメータＥＣＵ５３に対するリプログ処理と、リプログデータの取得処理とを並行しても良い。マイコン１５は、図１８に示すように、エンジンＥＣＵ５２のリプログデータの取得処理として、データ要求信号の送信（Ｓ７１）、リプログデータを含むデータ信号の取得（Ｓ７２）を実行する。マイコン１５は、図１９に示すように、メータＥＣＵ５３のリプログデータの取得処理として、データ要求信号の送信（Ｓ８１）、リプログデータを含むデータ信号の取得（Ｓ８２）を実行する。

このような構成でも、ＣＧＷ３においては、ＤＣＭ２から取得したエンジンＥＣＵ５２のリプログデータをエンジンＥＣＵ５２に送信し、ＤＣＭ２から取得したメータＥＣＵ５３のリプログデータをメータＥＣＵ５３に送信するので、エンジンＥＣＵ５２に送信するリプログデータやメータＥＣＵ５３に送信するリプログデータを記憶しておくための記憶媒体の容量を低減することができる。尚、この場合も、データ要求信号をＤＣＭ２に送信するタイミング及びＤＣＭ２からリプログデータを含むデータ信号を受信するタイミングはどのようなタイミングでも良い。又、以上は、同一のバス４２に接続されている２つのＥＣＵ５２，５３に対する２つの処理要求を同時に受け付けた場合を例示したが、３つ以上のＥＣＵに対する３つ以上の処理要求を同時に受け付けた場合も同様である。

（３）別々のバスに接続されている複数ＥＣＵに対する複数の処理要求を同時に受け付けた場合について説明する。
図２０に示すように、マイコン１５は、ＣＧＷ３が第１のバス４３及び第２のバス４３を接続し、第１のバス４３にエンジンＥＣＵ５４が接続されており、第２のバス４４にメータＥＣＵ５５が接続されており、そのエンジンＥＣＵ５４に対するリプログアプリの処理要求とメータＥＣＵ５５に対するリプログアプリの処理要求とを同時に受け付けると、それらの処理要求を調停し、図２０に示すように、エンジンＥＣＵ５４のリプログデータを含むデータ信号の送信とメータＥＣＵ５５のリプログデータを含むデータ信号の送信とを並行する。尚、この場合は、エンジンＥＣＵ５４とメータＥＣＵ５５とが別々のバスに接続されているので、マイコン１５は、バスの通信速度を判断し、エンジンＥＣＵ５４のリプログデータを含むデータ信号の送信とメータＥＣＵ５５のリプログデータを含むデータ信号の送信とを並行する。

この場合も、マイコン１５は、図２１に示すように、エンジンＥＣＵ５４に対するリプログ処理及びメータＥＣＵ５５に対するリプログ処理と、リプログデータの取得処理とを並行しても良い。尚、以上は、２本のバス４３，４４に別々に接続されている２つのＥＣＵ５４，５５に対する２つの処理要求を同時に受け付けた場合を例示したが、３本以上のバスに別々に接続されている３つ以上のＥＣＵに対する３つ以上の処理要求を同時に受け付けた場合も同様である。

次に、鍵管理アプリについて図２２から図２７を参照して説明する。ここでは、ＣＧＷ３が鍵をエンジンＥＣＵ６２及びメータＥＣＵ６３に配布する場合について説明する。尚、ンジンＥＣＵ６２及びメータＥＣＵ６３は、同一のバスに接続されていても良いし別々のバスに接続されていても良い。図２２に示すように、鍵管理アプリは、鍵生成フェーズ、鍵配布フェーズ、鍵確認フェーズ、鍵センター通知フェーズ、ＤＴＣ検証フェーズを含む。

鍵生成フェーズは、工場ツール６１が鍵を生成する場合とＣＧＷ３が鍵を生成する場合とがある。工場ツール６１が鍵を生成する場合では、図２３に示すように、工場ツール６１は、鍵を生成すると、その生成した鍵を特定可能な鍵情報を含む鍵情報信号をＣＧＷ３に送信する。ＣＧＷ３において、マイコン１５は、工場ツール６１から鍵情報信号を受信すると、その受信した鍵情報信号に含まれる鍵情報から鍵を特定し、その特定した鍵を記憶し、応答信号を工場ツール６１に送信する。又、ＣＧＷ３が鍵を生成する場合では、図２４に示すように、工場ツール６１は、鍵生成指示信号をＣＧＷ３に送信する。ＣＧＷ３において、マイコン１５は、工場ツール６１から鍵生成指示信号を受信すると、鍵を生成し、その生成した鍵を記憶し、応答信号を工場ツール６１に送信する。

鍵配布フェーズでは、図２５に示すように、工場ツール６１は、鍵書込指示信号をＣＧＷ３に送信する。ＣＧＷ３において、マイコン１５は、工場ツール６１から鍵書込指示信号を受信すると、記憶している鍵を読出し、その読出した鍵を含む鍵書込要求信号をエンジンＥＣＵ６２及びメータＥＣＵ６３に送信する。マイコン１５は、鍵書込要求信号のエンジンＥＣＵ６２への送信とメータＥＣＵ６３への送信とを並行する。エンジンＥＣＵ６２及びメータＥＣＵ６３は、それぞれＣＧＷ３から鍵書込要求信号を受信すると、その受信した鍵書込要求信号に含まれる鍵を取得して記憶し、鍵書込応答信号をＣＧＷ３に送信する。このようにして、マイコン１５は、エンジンＥＣＵ６２への鍵配布処理とメータＥＣＵ６３への鍵配布処理とをマルチタスクで実行する。即ち、マイコン１５は、エンジンＥＣＵ６２への鍵配布処理とメータＥＣＵ６３への鍵配布処理とを、一方の処理の完了を待機して他方の処理を開始するのではなく、エンジンＥＣＵ６２の負荷、メータＥＣＵ６３の負荷及びバスの負荷に応じてマルチタスクで実行することで、それらの処理を完了するまでに要する時間を短縮することが可能となる。

鍵確認フェーズは、ＣＧＷ３が鍵を確認する場合と工場ツール６１が後段のＤＴＣ検証フェーズにおいて鍵を確認する場合とがある。ＣＧＷ３が鍵を確認する場合では、図２６に示すように、ＣＧＷ３において、マイコン１５は、チェック値要求信号をエンジンＥＣＵ６２に送信する。エンジンＥＣＵ６２は、ＣＧＷ３からチェック値要求信号を受信すると、チェック値を生成し、その生成したチェック値を含むチェック値信号をＣＧＷ３に送信する。ＣＧＷ３において、マイコン１５は、エンジンＥＣＵ６２からチェック値信号を受信すると、その受信したチェック値信号に含まれるチェック値を判定し、エンジンＥＣＵ６２への鍵の書込みを正常に完了しているか否かを確認する。マイコン１５は、エンジンＥＣＵ６２への鍵の書込みを正常に完了しているか否かの確認を完了すると、チェック値要求信号をメータＥＣＵ６３に送信し、メータＥＣＵ６３への鍵の書込みを正常に完了しているか否かの確認を同様の手順にしたがって行う。

又、工場ツール６１が後段のＤＴＣ検証フェーズにおいて鍵を確認する場合では、図２７に示すように、工場ツール６１は、チェック指示信号をＣＧＷ３に送信する。ＣＧＷ３において、マイコン１５は、工場ツール６１からチェック指示信号を受信すると、チェック要求信号をエンジンＥＣＵ６２に送信する。エンジンＥＣＵ６２は、ＣＧＷ３からチェック要求信号を受信すると、鍵の書込みを正常に完了しているか否かを確認し、その確認結果を記憶し、チェック応答信号をＣＧＷ３に送信する。ＣＧＷ３において、マイコン１５は、エンジンＥＣＵ６２からチェック応答信号を受信すると、チェック要求信号をメータＥＣＵ６３に送信し、メータＥＣＵ６３への鍵の書込みを正常に完了しているか否かの確認を同様の手順にしたがって行う。これ以降、工場ツール６１は、ＤＴＣ検証フェーズにおいて、ＤＴＣ要求をエンジンＥＣＵ６２に送信し、確認結果を含むＤＴＣ応答をエンジンＥＣＵ６２から受信すると、その受信したＤＴＣ応答に含まれる確認結果を判定し、エンジンＥＣＵ６２への鍵の書込みを正常に完了しているか否かを確認する。工場ツール６１は、エンジンＥＣＵ６２への鍵の書込みを正常に完了しているか否かの確認を完了すると、ＤＴＣ要求をメータＥＣＵ６３に送信し、メータＥＣＵ６３への鍵の書込みを正常に完了しているか否かの確認を同様の手順にしたがって行う。

以上に説明したように本実施形態によれば、次に示す効果を得ることができる。
ＣＧＷ３において、ＥＣＵ１１ａ〜１１ｃ，１２ａ〜１２ｃ，１３ａ〜１３ｃ，１４ａ〜１４ｃに対する独立したアプリの処理要求を同時に受け付けると、その受け付け中の複数の処理要求を調停し、複数の処理要求に応じた複数の処理を並行するようにした。これにより、独立したアプリの処理要求を複数同時に受け付けた場合に、その受け付けた複数の処理要求に応じた複数の処理をマルチタスクで実行することができる。

又、ＣＧＷ３において、複数の処理要求に応じた複数の処理と、リプログデータをＤＣＭ２から取得する処理とを並行するようにした。これにより、リプログデータをＤＣＭ２から取得し、その取得したリプログデータをＥＣＵ１１ａ〜１１ｃ，１２ａ〜１２ｃ，１３ａ〜１３ｃ，１４ａ〜１４ｃに送信することができ、リプログデータを記憶しておくための記憶媒体の容量を低減することができる。

又、ＣＧＷ３において、受け付け中の処理要求の優先度に関するデータ、バス７〜１０の状態に関するデータ、ＥＣＵ１１ａ〜１１ｃ，１２ａ〜１２ｃ，１３ａ〜１３ｃ，１４ａ〜１４ｃの状態に関するデータを用い、複数の処理要求を調停するようにした。受け付け中の処理要求の優先度、バス７〜１０の状態、ＥＣＵ１１ａ〜１１ｃ，１２ａ〜１２ｃ，１３ａ〜１３ｃ，１４ａ〜１４ｃの状態を指標として複数の処理要求を調停することができる。

又、ＣＧＷ３において、処理の進捗状態やセッション状態を監視しながら複数の処理を並行するようにした。処理の進捗状態やセッション状態の変化に適切に対応しながら複数の処理をマルチタスクで実行することができる。

本開示は、実施例に準拠して記述されたが、当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、更には、それらに一要素のみ、それ以上、或いはそれ以下を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

リプログアプリ、故障診断アプリ、鍵管理アプリ以外のアプリを受け付ける構成であっても良い。
リプログデータがＤＣＭ２に格納されている構成を例示したが、ＤＣＭ２とは別にストレージデバイスが設けられ、リプログデータがストレージデバイスに格納され、ストレージデバイスからリプログデータを取得する処理を並行する構成であっても良い。

図面中、３は中央ゲートウェイ装置（並行処理装置）、７〜１０はバス、１１ａ〜１１ｃ，１２ａ〜１２ｃ，１３ａ〜１３ｃ，１４ａ〜１４ｃは電子制御装置、２７は処理要求受付部、３１は処理実行部、３２はスケジューリング調整部、３３はバス負荷調整部、３４は進捗状態判断部、３５はセッション状態判断部である。

Claims (12)

1. バス（７〜１０）を介して電子制御装置（１１ａ〜１１ｃ，１２ａ〜１２ｃ，１３ａ〜１３ｃ，１４ａ〜１４ｃ）を接続する並行処理装置（３）において、
   一又は複数の装置からデータコミュニケーションモジュールに送信されたアプリであって前記電子制御装置に対する当該アプリの処理要求を前記一又は複数の装置から前記データコミュニケーションモジュールを介して受け付ける処理要求受付部（２７）と、
   前記一又は複数の装置から前記データコミュニケーションモジュールを介して一のアプリの処理要求を前記処理要求受付部により受け付け、前記一のアプリの処理要求を受け付け中に、前記一又は複数の装置から前記データコミュニケーションモジュールを介して他のアプリの処理要求を前記処理要求受付部により受け付けると、先に受け付けた前記一のアプリの処理要求と後から受け付けた前記他のアプリの処理要求とを調停する処理実行部（３１）と、を備え、
   前記処理実行部は、前記一のアプリの処理要求の信号を送信してから当該一のアプリの処理要求の信号の応答を受信するまでの期間内で、前記他のアプリの処理要求の信号を送信することで、前記一のアプリの処理要求に応じた前記一の処理と前記他のアプリの処理要求に応じた他の処理とを並行して一以上の前記電子制御装置に実行させ、当該一のアプリの処理要求の信号の応答及び当該他のアプリの処理要求の信号の応答を受信し、複数のアプリの処理要求に応じた複数の処理を並行して一以上の前記電子制御装置に実行させる並行処理装置。
2. 前記処理要求受付部は、データを前記電子制御装置に送信するアプリの処理要求を受け付け、
   前記処理実行部は、前記複数のアプリの処理要求に応じた前記複数の処理と、前記データを外部から取得する処理とを並行する請求項１に記載の並行処理装置。
3. 前記処理実行部は、受け付け中のアプリの処理要求の優先度に関するデータ、前記バスの状態に関するデータ、前記電子制御装置の状態に関するデータのうち少なくとも何れかを用い、前記複数のアプリの処理要求を調停する請求項１又は２に記載の並行処理装置。
4. 前記複数の処理のスケジューリングを調整するスケジューリング調整部（３２）を備え、
   前記処理実行部は、前記スケジューリング調整部により調整されたスケジューリングにしたがい、前記複数の処理を並行する請求項１から３の何れか一項に記載の並行処理装置。
5. バス負荷を調整するバス負荷調整部（３３）を備え、
   前記処理実行部は、前記バス負荷調整部により調整されたバス負荷にしたがい、前記複数の処理を並行する請求項１から４の何れか一項に記載の並行処理装置。
6. 前記複数の処理の進捗状態を判断する進捗状態判断部（３４）を備え、
   前記処理実行部は、前記進捗状態判断部により判断された進捗状態を監視しながら前記複数の処理を並行する請求項１から５の何れか一項に記載の並行処理装置。
7. 前記複数の処理のセッション状態を判断するセッション状態判断部（３５）を備え、
   前記処理実行部は、前記セッション状態判断部により判断されたセッション状態を監視しながら前記複数の処理を並行する請求項１から６の何れか一項に記載の並行処理装置。
8. 前記処理要求受付部は、同一の電子制御装置に対する一のアプリの処理要求を受け付け、前記一のアプリの処理要求を受け付け中に、他のアプリの処理要求を受け付け、
   前記処理実行部は、前記同一の電子制御装置に対する前記複数のアプリの処理要求に応じた前記複数の処理を並行する請求項１から７の何れか一項に記載の並行処理装置。
9. 前記処理要求受付部は、同一のバスに接続されている複数の電子制御装置に対する一のアプリの処理要求を受け付け、前記一のアプリの処理要求を受け付け中に、他のアプリの処理要求を受け付け、
   前記処理実行部は、前記複数の電子制御装置に対する前記複数のアプリの処理要求に応じた前記複数の処理を並行する請求項１から７の何れか一項に記載の並行処理装置。
10. 前記処理要求受付部は、別々のバスに接続されている複数の電子制御装置に対する一のアプリの処理要求を受け付け、前記一のアプリの処理要求を受け付け中に、他のアプリの処理要求を受け付け、
    前記処理実行部は、前記複数の電子制御装置に対する前記複数のアプリの処理要求に応じた前記複数の処理を並行する請求項１から７の何れか一項に記載の並行処理装置。
11. 前記処理要求受付部は、鍵管理アプリの処理要求を受け付け、
    前記処理実行部は、前記複数の電子制御装置への鍵配布処理を並行する請求項１から１０の何れか一項に記載の並行処理装置。
12. バス（７〜１０）を介して電子制御装置（１１ａ〜１１ｃ，１２ａ〜１２ｃ，１３ａ〜１３ｃ，１４ａ〜１４ｃ）を接続する並行処理装置（３）に、
    一又は複数の装置からデータコミュニケーションモジュールに送信されたアプリであって前記電子制御装置に対する当該アプリの処理要求を前記一又は複数の装置から前記データコミュニケーションモジュールを介して受け付ける処理要求受付手順と、
    前記一又は複数の装置から前記データコミュニケーションモジュールを介して一のアプリの処理要求を前記処理要求受付手順により受け付け、前記一のアプリの処理要求を受け付け中に、前記一又は複数の装置から前記データコミュニケーションモジュールを介して他のアプリの処理要求を前記処理要求受付手順により受け付けると、先に受け付けた前記一のアプリの処理要求と後から受け付けた前記他のアプリの処理要求とを調停する調停手順と、
    前記一のアプリの処理要求の信号を送信してから当該一のアプリの処理要求の信号の応答を受信するまでの期間内で、前記他のアプリの処理要求の信号を送信することで、前記一のアプリの処理要求に応じた前記一の処理と前記他のアプリの処理要求に応じた他の処理とを並行して一以上の前記電子制御装置に実行させ、当該一のアプリの処理要求の信号の応答及び当該他のアプリの処理要求の信号の応答を受信し、複数のアプリの処理要求に応じた複数の処理を並行して一以上の前記電子制御装置に実行させる処理並行手順と、を実行させる並行処理プログラム。

Images