特許第6954422号(P6954422)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社デンソーの特許一覧

特許6954422並行処理装置、並行処理方法及び並行処理システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6954422
(24)【登録日】2021年10月4日
(45)【発行日】2021年10月27日
(54)【発明の名称】並行処理装置、並行処理方法及び並行処理システム
(51)【国際特許分類】
   G06F 8/656 20180101AFI20211018BHJP
   B60R 16/023 20060101ALI20211018BHJP
【FI】
   G06F8/656
   B60R16/023 P
【請求項の数】3
【全頁数】20
(21)【出願番号】特願2020-134679(P2020-134679)
(22)【出願日】2020年8月7日
(62)【分割の表示】特願2017-103606(P2017-103606)の分割
【原出願日】2017年5月25日
(65)【公開番号】特開2021-2352(P2021-2352A)
(43)【公開日】2021年1月7日
【審査請求日】2020年8月7日
(31)【優先権主張番号】特願2016-228959(P2016-228959)
(32)【優先日】2016年11月25日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】000004260
【氏名又は名称】株式会社デンソー
(74)【代理人】
【識別番号】110000567
【氏名又は名称】特許業務法人 サトー国際特許事務所
(72)【発明者】
【氏名】原田 雄三
(72)【発明者】
【氏名】佐藤 龍哉
(72)【発明者】
【氏名】森田 泰生
(72)【発明者】
【氏名】中村 翔
(72)【発明者】
【氏名】早川 和明
【審査官】 牛丸 太希
(56)【参考文献】
【文献】 特開2010−271891(JP,A)
【文献】 特開2011−238154(JP,A)
【文献】 特開2016−060388(JP,A)
【文献】 特開2016−024505(JP,A)
【文献】 国際公開第2014/057643(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 8/656
B60R 16/023
(57)【特許請求の範囲】
【請求項1】
リプログの対象である第1電子制御装置及び第2電子制御装置(11a〜11c,12a〜12c,13a〜13c,14a〜14c)と、前記第1電子制御装置のリプログデータ及び前記第2電子制御装置のリプログデータを格納するデータコミュニケーションモジュールと、バス(7〜10)を介して接続される並行処理装置(3)であって、
前記第1電子制御装置及び前記第2電子制御装置へリプログデータを含むデータ信号を送信してから前記第1電子制御装置又は前記第2電子制御装置からリプログ応答信号を受信するまでの期間内において、前記第1電子制御装置又は前記第2電子制御装置のリプログデータの要求信号を前記データコミュニケーションモジュールへ送信し、前記第1電子制御装置及び前記第2電子制御装置からリプログ応答信号を受信してから前記第1電子制御装置又は前記第2電子制御装置へリプログデータを含むデータ信号を送信するまでの期間内においても、前記データコミュニケーションモジュールから前記第1電子制御装置又は前記第2電子制御装置のリプログデータを含むデータ信号を受信する処理実行部(31)を有する並行処理装置。
【請求項2】
リプログの対象である第1電子制御装置及び第2電子制御装置(11a〜11c,12a〜12c,13a〜13c,14a〜14c)と、前記第1電子制御装置のリプログデータ及び前記第2電子制御装置のリプログデータを格納するデータコミュニケーションモジュールと、バス(7〜10)を介して接続される並行処理装置(3)が信号を送受信する方法において、
前記第1電子制御装置及び前記第2電子制御装置へリプログデータを含むデータ信号を送信してから前記第1電子制御装置又は前記第2電子制御装置からリプログ応答信号を受信するまでの期間内において、前記第1電子制御装置又は前記第2電子制御装置のリプログデータの要求信号を前記データコミュニケーションモジュールへ送信し、前記第1電子制御装置及び前記第2電子制御装置からリプログ応答信号を受信してから前記第1電子制御装置又は前記第2電子制御装置へリプログデータを含むデータ信号を送信するまでの期間内において、前記データコミュニケーションモジュールから前記第1電子制御装置又は前記第2電子制御装置のリプログデータを含むデータ信号を受信する並行処理方法
【請求項3】
リプログの対象である第1電子制御装置及び第2電子制御装置(11a〜11c,12a〜12c,13a〜13c,14a〜14c)と、
前記第1電子制御装置のリプログデータ及び前記第2電子制御装置のリプログデータを格納するデータコミュニケーションモジュール(2)と、
バス(7〜10)を介して前記第1電子制御装置、前記第2電子制御装置、及び前記データコミュニケーションモジュールと接続される並行処理装置(3)と、を備える並行処理システムであって
前記並行処理装置は、前記第1電子制御装置及び前記第2電子制御装置へリプログデータを含むデータ信号を送信してから前記第1電子制御装置又は前記第2電子制御装置からリプログ応答信号を受信するまでの期間内において、前記第1電子制御装置又は前記第2電子制御装置のリプログデータの要求信号を前記データコミュニケーションモジュールへ送信し、前記第1電子制御装置及び前記第2電子制御装置からリプログ応答信号を受信してから前記第1電子制御装置又は前記第2電子制御装置へリプログデータを含むデータ信号を送信するまでの期間内においても、前記データコミュニケーションモジュールから前記第1電子制御装置又は前記第2電子制御装置のリプログデータを含むデータ信号を受信する並行処理システム
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、並行処理装置、並行処理方法及び並行処理システムに関する。
【背景技術】
【0002】
従来より、電子制御装置(以下、ECU(Electronic Control Unit)と称する)を接続し、ECUに対するリプログアプリ、故障診断アプリ、鍵管理アプリ等の様々な独立したアプリの処理要求を受け付ける処理装置が供されている(例えば特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2003−46536号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
この種の処理装置は、ECUに対する処理要求を受け付けると、その受け付けた処理要求に応じた処理を実行する。この場合、処理装置は、処理要求の要求先であるECUとの間で1対1の通信を順番に実行し、処理要求を受け付けた順序にしたがって処理を順番に実行する。即ち、処理装置は、ECUに対する一の処理要求を受け付けると、その受け付けた一の処理要求に応じた一の処理を開始する。処理装置は、一の処理を完了する前、即ち一の処理を実行中にECUに対する別の処理要求を受け付けると、その受け付けた別の処理要求に応じた別の処理の開始を待機する。そして、処理装置は、一の処理を完了すると、その待機中の別の処理を開始する。
【0005】
一方、近年では、制御の複雑化によるECUのプログラム容量の増加やシステムの複雑化等により、複数の処理をマルチタスクで実行する必要性が増している。しかしながら、前述した一の処理を完了するまで別の処理の開始を待機する構成では、複数の処理をマルチタスクで実行することはできない。
【0006】
本発明は、上記した事情に鑑みてなされたものであり、その目的は、独立したアプリの処理要求を複数同時に受け付けた場合に、その受け付けた複数の処理要求に応じた複数の処理をマルチタスクで実行することができる並行処理装置、並行処理方法及び並行処理システムを提供することにある。
【課題を解決するための手段】
【0007】
請求項1に記載した発明によれば、並行処理装置(3)は、リプログの対象である第1電子制御装置及び第2電子制御装置(11a〜11c,12a〜12c,13a〜13c,14a〜14c)と、前記第1電子制御装置のリプログデータ及び前記第2電子制御装置のリプログデータを格納するデータコミュニケーションモジュールと、バス(7〜10)を介して接続される。
【0008】
処理実行部(31)は、前記第1電子制御装置及び前記第2電子制御装置へリプログデータを含むデータ信号を送信してから前記第1電子制御装置又は前記第2電子制御装置からリプログ応答信号を受信するまでの期間内において、前記第1電子制御装置又は前記第2電子制御装置のリプログデータの要求信号を前記データコミュニケーションモジュールへ送信し、前記第1電子制御装置及び前記第2電子制御装置からリプログ応答信号を受信してから前記第1電子制御装置又は前記第2電子制御装置へリプログデータを含むデータ信号を送信するまでの期間内においても、前記データコミュニケーションモジュールから前記第1電子制御装置又は前記第2電子制御装置のリプログデータを含むデータ信号を受信する。
【図面の簡単な説明】
【0009】
図1】一実施形態のシステム全体の構成を示す図
図2】中央ゲートウェイ装置の構成を示す機能ブロック図
図3】クライアントプログラムの構成を示す図
図4】データの階層を示す図
図5】セッション状態の遷移を示す図
図6】全体の処理を示すフローチャート
図7】接続態様を示す図
図8】シーケンス図
図9】フローチャート
図10】接続態様を示す図
図11】シーケンス図
図12】フローチャート
図13】接続態様を示す図
図14】シーケンス図
図15】フローチャート
図16】接続態様を示す図
図17】シーケンス図
図18】フローチャート
図19】フローチャート
図20】接続態様を示す図
図21】接続態様を示す図
図22】シーケンス図
図23】シーケンス図
図24】シーケンス図
図25】シーケンス図
図26】シーケンス図
図27】シーケンス図
【発明を実施するための形態】
【0010】
以下、本発明を、車両に搭載される並行処理装置に適用した一実施形態について図面を参照して説明する。
マスタ電子制御装置(以下、マスタECU(Electronic Control Unit)と称する)1は、データコミュニケーションモジュール(以下、DCM(Data Communication Module)と称する)2と、中央ゲートウェイ装置(以下、CGW(Central Gate Way)と称する)3(並行処理装置に相当する)とを有する。
【0011】
DCM2は、センター4、ユーザデバイス5、ツール6との間で車外ネットワークを介したデータ通信を制御する。即ち、DCM2は、センター4との間で例えば3G回線や4G回線等による移動体通信網を介したデータ通信を制御する。又、DCM2は、ユーザデバイス5との間で例えばWiFi(登録商標)やBluetooth(登録商標)を介したデータ通信を制御する。又、DCM2は、ツール6との間で例えば有線接続によるデータ通信を制御する。DCM2は、センター4、ユーザデバイス5、ツール6等からアプリを受信すると、その受信したアプリをCGW3に送信する。例えばユーザがツール6を操作してリプログアプリを起動すると、DCM2は、ツール6からリプログアプリを受信し、その受信したリプログアプリをCGW3に送信する。又、例えばユーザがツール6を操作して故障診断アプリを起動すると、DCM2は、ツール6から故障診断アプリを受信し、その受信した故障診断アプリをCGW3に送信する。
【0012】
CGW3は、DCM2からアプリを受信すると、そのアプリの処理要求を受け付ける。CGW3は、例えばDCM2からリプログアプリを受信すると、そのリプログアプリの処理要求を受け付ける。又、CGW3は、例えばDCM2から故障診断アプリを受信すると、その故障診断アプリの処理要求を受け付ける。
【0013】
CGW3は、複数のバス7〜10を接続しており、車両に搭載されているECUとの間でバス7〜10を介したデータ通信を制御する。バス7〜10は、例えばマルチメディア系のバス、パワトレ系のバス、ボディ系のバス、環境系のバス、シャシ系のバス等である。バス7〜10は、例えばCAN(Controller Area Network)(登録商標)、LIN(Local Interconnect Network)(登録商標)、CXPI(Clock Extension Peripheral Interface)(登録商標)、FlexRay(登録商標)、MOST(Media Oriented Systems Transport)(登録商標)等であり、通信プロトコルが互いに異なり、通信速度や信号フォーマットが互いに異なる。
【0014】
バス7〜10にはそれぞれECU11a〜11c、12a〜12c、13a〜13c、14a〜14cが接続されている。例えばマルチメディア系のバスには、ナビゲーションの制御を行うナビゲーションECU、電子式料金収受システム(ETC:Electronic Toll Collection System:登録商標)との通信制御を行うETCECU等が接続されている。例えばパワトレ系のバスには、エンジンの制御を行うエンジンECU、ブレーキの制御を行うブレーキECU、自動変速機の制御を行うECTECU、パワーステアリングの制御を行うパワステECU等が接続されている。例えばボディ系のバスには、ドアのロック/アンロックの制御を行うドアECU、メータの表示制御を行うメータECU、エアコンの制御を行うエアコンECU、ウィンドウの開閉制御を行うウィンドウECU等が接続されている。
【0015】
図2に示すように、CGW3は、マイクロコンピュータ(以下、マイコンと称する)15と、トランシーバ16と、電源回路17とを有する。マイコン15は、CPU18と、非遷移的記録媒体としてのROM19と、RAM20と、フラッシュメモリ21とが内部バス22を介して相互接続されている。マイコン15は、ROM19に格納されている制御プログラムをCPU18が実行し、CGW3の動作を制御する。トランシーバ16は、マイコン15からの命令により、DCM2とのデータ通信を制御すると共に、バス7〜10を介したECU11a〜11c、12a〜12c、13a〜13c、14a〜14cとのデータ通信を制御する。電源回路17は、アクセサリスイッチのオンオフを示すアクセサリ信号及びイグニッションスイッチのオンオフを示すイグニッション信号を入力する。電源回路17は、例えばアクセサリ信号のオフからオンへの切り換えを検知すると、バッテリ電源から供給された電力から動作電力を生成し、その生成した動作電力をマイコン15及びトランシーバ16に供給する。
【0016】
ROM19には、制御プログラムの1つとしてクライアントプログラムが格納されている。クライアントプログラム23は、並行処理プログラムを含み、図3に示すように、各種データを格納する機能として、管理情報マスタデータを格納する管理情報マスタデータ格納部24、管理情報バスマスタデータを格納する管理情報バスマスタデータ格納部25、管理情報データを格納する管理情報データ格納部26を有する。管理情報マスタデータ格納部24は、バス7〜10の通信速度に関するデータ、スケジューリングの調整に関するデータ等を管理情報マスタデータとして格納している。管理情報バスマスタデータ格納部25は、管理情報データを割り当て済みのECU11a〜11c、12a〜12c、13a〜13c、14a〜14cに関するデータ、バス負荷の調整に関するデータ等を管理情報バスマスタデータとして格納している。管理情報データ格納部26は、受け付け中の処理要求の優先度に関するデータ、バス7〜10の状態に関するデータ、ECU11a〜11c、12a〜12c、13a〜13c、14a〜14cの状態に関するデータ、処理の進捗状態に関するデータ、処理のセッション状態に関するデータ等を管理情報データとして格納している。図4に示すように、クライアントプログラム23は、これらの管理情報マスタデータ、管理情報バスマスタデータ、管理情報データを階層化して管理している。
【0017】
又、クライアントプログラム23は、処理要求受付部27、管理情報マスタ更新部28、管理情報バスマスタ更新部29、管理情報割り当て部30、処理実行部31、スケジューリング調整部32、バス負荷調整部33、進捗状態判断部34、セッション状態判断部35を有する。
【0018】
処理要求受付部27は、ECU11a〜11c、12a〜12c、13a〜13c、14a〜14cに対する独立したアプリの処理要求を受け付ける。処理要求受付部27が処理要求を受け付けるアプリは、例えばリプログアプリ、故障診断アプリ、鍵管理アプリ等である。管理情報マスタ更新部28及び管理情報バスマスタ更新部29は、それぞれ処理実行部31が処理を実行することに応じて変化するバス7〜10の状態やECU11a〜11c、12a〜12c、13a〜13c、14a〜14cの状態を監視し、状態が変化することに応じて管理情報マスタデータ及び管理情報バスマスタデータの更新を行う。管理情報割り当て部30は、管理情報マスタデータ及び管理情報バスマスタデータを参照し、管理情報データを処理要求に割り当てる。
【0019】
処理実行部31は、管理情報マスタデータ、管理情報バスマスタデータ、管理情報データを参照し、複数のアプリの処理要求を調停する。即ち、処理実行部33は、一のアプリの処理要求を受け付け中に別のアプリの処理要求を受け付けると、一のアプリの処理要求と別のアプリの処理要求との優先度、その時点でのバス7〜10の状態やECU11a〜11c、12a〜12c、13a〜13c、14a〜14cの状態等を判断し、一のアプリの処理要求と別のアプリの処理要求とを調停する。処理実行部31は、例えば一のアプリの処理要求が別のアプリの処理要求よりも優先度が高ければ一のアプリの処理要求に応じた処理を優先するように調停する。これとは逆に、処理実行部31は、例えば別のアプリの処理要求が一のアプリの処理要求よりも優先度が高ければ別のアプリの処理要求に応じた処理を優先するように調停する。又、処理実行部31は、処理要求の要求先であるECUの負荷やバスの負荷が比較的低ければ処理を実行し、負荷が比較的高ければ処理の実行を待機するように調停する。
【0020】
スケジューリング調整部32は、管理情報マスタデータ格納部24に格納されているスケジューリングの調整に関するデータを用い、スケジューリングの調整を行う。スケジューリング調整部32は、スケジューリングの調整として例えば信号の送信間隔を調整する。バス負荷調整部33は、管理情報バスマスタデータ格納部25に格納されているバス負荷の調整に関するデータを用い、バス負荷の調整を行う。バス負荷調整部33は、バス負荷の調整としてバスのデータ通信量を調整する。進捗状態判断部34は、管理情報データ格納部26に格納されている進捗状態に関するデータを用い、処理の進捗状態の判断を行う。セッション状態判断部35は、管理情報データ格納部26に格納されているセッション状態に関するデータを用い、処理のセッション状態の判断を行う。
【0021】
処理実行部31は、複数のアプリの処理要求を調停すると、スケジューリング調整部32により調整されたスケジューリング及びバス負荷調整部33により調整されたバス負荷にしたがい、進捗状態判断部34により判断された進捗状態及びセッション状態判断部35により判断されたセッション状態を監視しながら複数の処理を並行する。
【0022】
ここで、セッション状態を監視する理由について説明する。図5に示すように、ECUは、通常状態にあるときにセッション移行要求信号を受信すると、通常状態から故障診断状態に移行するが、その後に故障診断要求信号を受信しない時間が所定時間(例えば5秒)継続すると、タイムアウトが発生して故障診断状態から通常状態から復帰する。このような事情から、クライアントプログラム23は、セッション移行要求信号を定期的にECUに送信することで、故障診断要求信号を送信する間隔が所定時間を越えてもECUを故障診断状態に維持することが可能となる。
【0023】
又、ECUは、故障診断状態にあるときにセッション移行要求信号を受信すると、故障診断状態からリプログ状態に移行するが、その後にリプログデータを含むデータ信号を受信しない時間が所定時間(例えば5秒)継続すると、タイムアウトが発生してリプログ状態から通常状態から復帰する。このような事情から、クライアントプログラム23は、セッション移行要求信号を定期的にECUに送信することで、リプログデータを含むデータ信号を送信する間隔が所定時間を越えてもECUをリプログ状態に維持することが可能となる。
【0024】
次に、上記した構成の作用について図6から図27を参照して説明する。
CGW3において、マイコン15は、CPU18がクライアントプログラム23を実行することで以下の制御を行う。
【0025】
マイコン15は、アプリの処理要求を処理要求受付部24が受け付けると(S1、処理要求受付手順)、その受け付けたアプリの処理要求を調停する(S2、調停手順)。即ち、マイコン15は、受け付け中のアプリの処理要求の優先度に関するデータ、バス7〜10の状態に関するデータ、ECU11a〜11c、12a〜12c、13a〜13c、14a〜14cの状態に関するデータを用い、その受け付けた処理要求に応じた処理を実行可能であるか否かを判断し、アプリの処理要求を調停する。マイコン15は、その受け付けたアプリの処理要求を調停したことでアプリの競合を回避したか否かを判定し(S3)、アプリの競合を回避したと判定すると(S3:YES)、管理情報データを処理要求に割り当てる(S4)。
【0026】
マイコン15は、管理情報データを処理要求に割り当てると、管理情報マスタデータを更新する(S5)。マイコン15は、複数の処理要求に応じた複数の処理のスケジューリングを調整し(S6)、複数の処理のスケジューリングを調整すると、管理情報バスマスタデータを更新する(S7)。マイコン15は、バス負荷を計算し(S8)、バス負荷を監視し(S9)、処理要求の要求先のECUに送信する信号の送信間隔を調整する(S10)。そして、マイコン15は、進捗状態及びセッション状態を監視しながら複数の処理を並行する(S11、処理並行手順)。
【0027】
以下、ECUの接続態様として、バスに接続されている同一のECUに対する複数の処理要求を同時に受け付けた場合、同一のバスに接続されている複数のECUに対する複数の処理要求を同時に受け付けた場合、別々のバスに接続されている複数の電子制御装置に対する複数の処理要求を同時に受け付けた場合について説明する。
【0028】
(1)バスに接続されている同一のECUに対する複数の処理要求を同時に受け付けた場合
図7に示すように、マイコン15は、CGW3がバス41を接続し、バス41にエンジンECU51が接続されており、そのエンジンECU51に対するリプログアプリの処理要求と故障診断アプリの処理要求とを同時に受け付けると、それらの処理要求を調停し、図8に示すように、リプログデータを含むデータ信号の送信と故障診断要求信号の送信とを並行する。この場合、同時に受け付けるとは、リプログアプリの処理要求に応じたリプログ処理を実行中に故障診断アプリの処理要求を受け付けた場合、又は故障診断アプリの処理要求に応じた故障診断処理を実行中にリプログアプリの処理要求を受け付けた場合を意味する。
【0029】
マイコン15は、リプログデータを含むデータ信号を送信してからリプログ応答信号を受信するまでの期間内において、故障診断要求信号を送信してもエンジンECU51の負荷及びバス41の負荷に支障がない(例えば他の処理や他のバス通信を妨げない等)と判断すると、その期間内で故障診断要求信号を送信する。又、マイコン15は、故障診断要求信号を送信してから故障診断データ(例えばDTCコード等の各種データ)を含むデータ信号を受信するまでの期間内において、リプログデータを含むデータ信号を送信してもエンジンECU51の負荷及びバス41の負荷に支障がないと判断すると、その期間内でリプログデータを含むデータ信号を送信する。このようにして、マイコン15は、エンジンECU51に対するリプログ処理と故障診断処理とをマルチタスクで実行する。即ち、マイコン15は、エンジンECU51に対するリプログ処理と故障診断処理とを、一方の処理の完了を待機して他方の処理を開始するのではなく、エンジンECU51の負荷及びバス41の負荷に応じてマルチタスクで実行することで、それらの処理を完了するまでに要する時間を短縮することが可能となる。
【0030】
マイコン15は、図9に示すように、エンジンECU51に対するリプログ処理として、リプログのエントリ処理(S21)、エンジンECU51のフラッシュメモリに記憶されているデータの消去(S22)、リプログデータを含むデータ信号の送信(S23)、リプログ応答信号の受信(S24)、リプログの検証(S25)、エンジンECU51の初期化(S26)を実行する。又、マイコン15は、エンジンECU51に対する故障診断処理として、故障診断要求信号の送信(S31)、故障診断データを含むデータ信号の受信(S32)を実行する。
【0031】
又、マイコン15は、リプログデータを含むデータ信号の送信と故障診断要求信号の送信とに加え、DCM2からのリプログデータの受信を並行しても良い。即ち、図10に示すように、エンジンECU51のリプログデータがDCM2に格納されている構成である場合に、図11に示すように、マイコン15は、例えば故障診断要求信号を送信してからリプログ応答信号を受信するまでの期間内でリプログデータの要求信号をDCM2に送信し、故障診断データを含むデータ信号を受信してからリプログデータを含むデータ信号を送信するまでの期間内でDCM2からリプログデータを含むデータ信号を受信する。
【0032】
このようにして、マイコン15は、エンジンECU51に対するリプログアプリの処理要求に応じたリプログ処理及び故障診断アプリの処理要求に応じた故障診断処理と、DCM2からリプログデータを取得する処理とをマルチタスクで実行する。マイコン15は、図12に示すように、リプログデータの取得処理として、データ要求信号の送信(S41)、リプログデータを含むデータ信号の取得(S42)を実行する。
【0033】
このような構成では、CGW3においては、DCM2から取得したリプログデータをエンジンECU51に送信するので、エンジンECU51に送信するリプログデータを記憶しておくための記憶媒体の容量を低減することができる。尚、データ要求信号をDCM2に送信するタイミング及びDCM2からリプログデータを含むデータ信号を受信するタイミングはどのようなタイミングでも良い。又、以上は、エンジンECU51に対する2つの処理要求を同時に受け付けた場合を例示したが、エンジンECU51に対する3つ以上の処理要求を同時に受け付けた場合も同様である。
【0034】
(2)同一のバスに接続されている複数のECUに対する複数の処理要求を同時に受け付けた場合
図13に示すように、マイコン15は、CGW3がバス42を接続し、バス42にエンジンECU52とメータECU53とが接続されており、そのエンジンECU52に対するリプログアプリの処理要求とメータECU53に対するリプログアプリの処理要求とを同時に受け付けると、それらの処理要求を調停し、図14に示すように、エンジンECU52のリプログデータを含むデータ信号の送信とメータECU53のリプログデータを含むデータ信号の送信とを並行する。この場合、同時に受け付けるとは、エンジンECU52に対するリプログアプリの処理要求に応じたリプログ処理を実行中にメータECU53に対するリプログアプリの処理要求を受け付けた場合、又はメータECU53に対するリプログアプリの処理要求に応じたリプログ処理を実行中にエンジンECU52に対するリプログアプリの処理要求を受け付けた場合を意味する。
【0035】
マイコン15は、エンジンECU52のリプログデータを含むデータ信号を送信してからリプログ応答信号を受信するまでの期間内において、メータECU53のリプログデータを含むデータ信号を送信してもメータECU53の負荷及びバス42の負荷に支障がないと判断すると、その期間内でメータECU53のリプログデータを含むデータ信号を送信する。又、マイコン15は、メータECU53のリプログデータを含むデータ信号を送信してからリプログ応答信号を受信するまでの期間内において、エンジンECU52のリプログデータを含むデータ信号を送信してもエンジンECU52の負荷及びバス42の負荷に支障がないと判断すると、その期間内でエンジンECU52のリプログデータを含むデータ信号を送信する。
【0036】
このようにして、マイコン15は、エンジンECU52に対するリプログ処理とメータECU53に対するリプログ処理とをマルチタスクで実行する。即ち、マイコン15は、エンジンECU52に対するリプログ処理とメータECU53に対するリプログ処理とを、一方の処理の完了を待機して他方の処理を開始するのではなく、エンジンECU52の負荷、メータECU53の負荷及びバス42の負荷に応じてマルチタスクで実行することで、それらの処理を完了するまでに要する時間を短縮することが可能となる。
【0037】
マイコン15は、図15に示すように、エンジンECU52に対するリプログ処理として、リプログのエントリ処理(S51)、エンジンECU52のフラッシュメモリに記憶されているデータの消去(S52)、リプログデータを含むデータ信号の送信(S53)、リプログ応答信号の受信(S54)、リプログの検証(S55)、エンジンECU52の初期化(S56)を実行する。又、マイコン15は、メータECU53に対するリプログ処理として、リプログのエントリ処理(S61)、メータECU53のフラッシュメモリに記憶されているデータの消去(S62)、リプログデータを含むデータ信号の送信(S63)、リプログ応答信号の受信(S64)、リプログの検証(S65)、メータECU53の初期化(S66)を実行する。
【0038】
この場合も、マイコン15は、リプログデータを含むデータ信号の送信に加え、DCM2からのリプログデータの受信を並行しても良い。即ち、図16に示すように、エンジンECU52のリプログデータ及びメータECU53のリプログデータがDCM2に格納されている構成である場合に、マイコン15は、図17から図19に示すように、エンジンECU52に対するリプログ処理及びメータECU53に対するリプログ処理と、リプログデータの取得処理とを並行しても良い。マイコン15は、図18に示すように、エンジンECU52のリプログデータの取得処理として、データ要求信号の送信(S71)、リプログデータを含むデータ信号の取得(S72)を実行する。マイコン15は、図19に示すように、メータECU53のリプログデータの取得処理として、データ要求信号の送信(S81)、リプログデータを含むデータ信号の取得(S82)を実行する。
【0039】
このような構成でも、CGW3においては、DCM2から取得したエンジンECU52のリプログデータをエンジンECU52に送信し、DCM2から取得したメータECU53のリプログデータをメータECU53に送信するので、エンジンECU52に送信するリプログデータやメータECU53に送信するリプログデータを記憶しておくための記憶媒体の容量を低減することができる。尚、この場合も、データ要求信号をDCM2に送信するタイミング及びDCM2からリプログデータを含むデータ信号を受信するタイミングはどのようなタイミングでも良い。又、以上は、同一のバス42に接続されている2つのECU52,53に対する2つの処理要求を同時に受け付けた場合を例示したが、3つ以上のECUに対する3つ以上の処理要求を同時に受け付けた場合も同様である。
【0040】
(3)別々のバスに接続されている複数ECUに対する複数の処理要求を同時に受け付けた場合について説明する。
図20に示すように、マイコン15は、CGW3が第1のバス43及び第2のバス43を接続し、第1のバス43にエンジンECU54が接続されており、第2のバス44にメータECU55が接続されており、そのエンジンECU54に対するリプログアプリの処理要求とメータECU55に対するリプログアプリの処理要求とを同時に受け付けると、それらの処理要求を調停し、図20に示すように、エンジンECU54のリプログデータを含むデータ信号の送信とメータECU55のリプログデータを含むデータ信号の送信とを並行する。尚、この場合は、エンジンECU54とメータECU55とが別々のバスに接続されているので、マイコン15は、バスの通信速度を判断し、エンジンECU54のリプログデータを含むデータ信号の送信とメータECU55のリプログデータを含むデータ信号の送信とを並行する。
【0041】
この場合も、マイコン15は、図21に示すように、エンジンECU54に対するリプログ処理及びメータECU55に対するリプログ処理と、リプログデータの取得処理とを並行しても良い。尚、以上は、2本のバス43,44に別々に接続されている2つのECU54,55に対する2つの処理要求を同時に受け付けた場合を例示したが、3本以上のバスに別々に接続されている3つ以上のECUに対する3つ以上の処理要求を同時に受け付けた場合も同様である。
【0042】
次に、鍵管理アプリについて図22から図27を参照して説明する。ここでは、CGW3が鍵をエンジンECU62及びメータECU63に配布する場合について説明する。尚、ンジンECU62及びメータECU63は、同一のバスに接続されていても良いし別々のバスに接続されていても良い。図22に示すように、鍵管理アプリは、鍵生成フェーズ、鍵配布フェーズ、鍵確認フェーズ、鍵センター通知フェーズ、DTC検証フェーズを含む。
【0043】
鍵生成フェーズは、工場ツール61が鍵を生成する場合とCGW3が鍵を生成する場合とがある。工場ツール61が鍵を生成する場合では、図23に示すように、工場ツール61は、鍵を生成すると、その生成した鍵を特定可能な鍵情報を含む鍵情報信号をCGW3に送信する。CGW3において、マイコン15は、工場ツール61から鍵情報信号を受信すると、その受信した鍵情報信号に含まれる鍵情報から鍵を特定し、その特定した鍵を記憶し、応答信号を工場ツール61に送信する。又、CGW3が鍵を生成する場合では、図24に示すように、工場ツール61は、鍵生成指示信号をCGW3に送信する。CGW3において、マイコン15は、工場ツール61から鍵生成指示信号を受信すると、鍵を生成し、その生成した鍵を記憶し、応答信号を工場ツール61に送信する。
【0044】
鍵配布フェーズでは、図25に示すように、工場ツール61は、鍵書込指示信号をCGW3に送信する。CGW3において、マイコン15は、工場ツール61から鍵書込指示信号を受信すると、記憶している鍵を読出し、その読出した鍵を含む鍵書込要求信号をエンジンECU62及びメータECU63に送信する。マイコン15は、鍵書込要求信号のエンジンECU62への送信とメータECU63への送信とを並行する。エンジンECU62及びメータECU63は、それぞれCGW3から鍵書込要求信号を受信すると、その受信した鍵書込要求信号に含まれる鍵を取得して記憶し、鍵書込応答信号をCGW3に送信する。このようにして、マイコン15は、エンジンECU62への鍵配布処理とメータECU63への鍵配布処理とをマルチタスクで実行する。即ち、マイコン15は、エンジンECU62への鍵配布処理とメータECU63への鍵配布処理とを、一方の処理の完了を待機して他方の処理を開始するのではなく、エンジンECU62の負荷、メータECU63の負荷及びバスの負荷に応じてマルチタスクで実行することで、それらの処理を完了するまでに要する時間を短縮することが可能となる。
【0045】
鍵確認フェーズは、CGW3が鍵を確認する場合と工場ツール61が後段のDTC検証フェーズにおいて鍵を確認する場合とがある。CGW3が鍵を確認する場合では、図26に示すように、CGW3において、マイコン15は、チェック値要求信号をエンジンECU62に送信する。エンジンECU62は、CGW3からチェック値要求信号を受信すると、チェック値を生成し、その生成したチェック値を含むチェック値信号をCGW3に送信する。CGW3において、マイコン15は、エンジンECU62からチェック値信号を受信すると、その受信したチェック値信号に含まれるチェック値を判定し、エンジンECU62への鍵の書込みを正常に完了しているか否かを確認する。マイコン15は、エンジンECU62への鍵の書込みを正常に完了しているか否かの確認を完了すると、チェック値要求信号をメータECU63に送信し、メータECU63への鍵の書込みを正常に完了しているか否かの確認を同様の手順にしたがって行う。
【0046】
又、工場ツール61が後段のDTC検証フェーズにおいて鍵を確認する場合では、図27に示すように、工場ツール61は、チェック指示信号をCGW3に送信する。CGW3において、マイコン15は、工場ツール61からチェック指示信号を受信すると、チェック要求信号をエンジンECU62に送信する。エンジンECU62は、CGW3からチェック要求信号を受信すると、鍵の書込みを正常に完了しているか否かを確認し、その確認結果を記憶し、チェック応答信号をCGW3に送信する。CGW3において、マイコン15は、エンジンECU62からチェック応答信号を受信すると、チェック要求信号をメータECU63に送信し、メータECU63への鍵の書込みを正常に完了しているか否かの確認を同様の手順にしたがって行う。これ以降、工場ツール61は、DTC検証フェーズにおいて、DTC要求をエンジンECU62に送信し、確認結果を含むDTC応答をエンジンECU62から受信すると、その受信したDTC応答に含まれる確認結果を判定し、エンジンECU62への鍵の書込みを正常に完了しているか否かを確認する。工場ツール61は、エンジンECU62への鍵の書込みを正常に完了しているか否かの確認を完了すると、DTC要求をメータECU63に送信し、メータECU63への鍵の書込みを正常に完了しているか否かの確認を同様の手順にしたがって行う。
【0047】
以上に説明したように本実施形態によれば、次に示す効果を得ることができる。
CGW3において、ECU11a〜11c,12a〜12c,13a〜13c,14a〜14cに対する独立したアプリの処理要求を同時に受け付けると、その受け付け中の複数の処理要求を調停し、複数の処理要求に応じた複数の処理を並行するようにした。これにより、独立したアプリの処理要求を複数同時に受け付けた場合に、その受け付けた複数の処理要求に応じた複数の処理をマルチタスクで実行することができる。
【0048】
又、CGW3において、複数の処理要求に応じた複数の処理と、リプログデータをDCM2から取得する処理とを並行するようにした。これにより、リプログデータをDCM2から取得し、その取得したリプログデータをECU11a〜11c,12a〜12c,13a〜13c,14a〜14cに送信することができ、リプログデータを記憶しておくための記憶媒体の容量を低減することができる。
【0049】
又、CGW3において、受け付け中の処理要求の優先度に関するデータ、バス7〜10の状態に関するデータ、ECU11a〜11c,12a〜12c,13a〜13c,14a〜14cの状態に関するデータを用い、複数の処理要求を調停するようにした。受け付け中の処理要求の優先度、バス7〜10の状態、ECU11a〜11c,12a〜12c,13a〜13c,14a〜14cの状態を指標として複数の処理要求を調停することができる。
【0050】
又、CGW3において、処理の進捗状態やセッション状態を監視しながら複数の処理を並行するようにした。処理の進捗状態やセッション状態の変化に適切に対応しながら複数の処理をマルチタスクで実行することができる。
【0051】
本開示は、実施例に準拠して記述されたが、当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、更には、それらに一要素のみ、それ以上、或いはそれ以下を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。
リプログアプリ、故障診断アプリ、鍵管理アプリ以外のアプリを受け付ける構成であっても良い。
【0052】
リプログデータがDCM2に格納されている構成を例示したが、DCM2とは別にストレージデバイスが設けられ、リプログデータがストレージデバイスに格納され、ストレージデバイスからリプログデータを取得する処理を並行する構成であっても良い。
【符号の説明】
【0053】
図面中、3は中央ゲートウェイ装置(並行処理装置)、7〜10はバス、11a〜11c,12a〜12c,13a〜13c,14a〜14cは電子制御装置、27は処理要求受付部、31は処理実行部、32はスケジューリング調整部、33はバス負荷調整部、34は進捗状態判断部、35はセッション状態判断部である。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27