(57)【要約】【課題】複数のＣＰＵコアを有するマルチコア演算装置において、適切に分散処理を行う。【解決手段】マルチコア演算装置１０は、第１コア１と、第１コア１とは独立して動作する第２コア２と、共有メモリ４とを備え、両コアは共有メモリ４を介して通信する。第１コア１は、制御対象である車両用駆動伝達装置１００の挙動変化の順序を示す挙動スケジュールを決定する挙動スケジュールアプリケーションを実行する。第２コア２は、車両用駆動伝達装置１００を動作させるアクチュエータ１２０を制御するアクチュエータ制御アプリケーションと、物理情報を取得して提供するセンシングアプリケーションとを実行する。【選択図】図６
2018013843.tif 000002
【特許請求の範囲】
【請求項１】
第１コアと、前記第１コアとは独立して動作する第２コアとの少なくとも２つの独立したＣＰＵコアと、
複数の前記ＣＰＵコアが共通して使用する共有メモリと、
を備えたマルチコア演算装置であって、
複数の前記ＣＰＵコアが、前記共有メモリを介して通信を行い、
制御対象である車両用駆動伝達装置の挙動変化の順序を示す挙動スケジュールを決定するソフトウェアである挙動スケジュールアプリケーションと、
決定された前記挙動スケジュールに従って、前記車両用駆動伝達装置を動作させるアクチュエータを制御するソフトウェアであるアクチュエータ制御アプリケーションと、
少なくとも前記挙動スケジュールを決定するための物理情報を取得して、少なくとも前記挙動スケジュールアプリケーションに当該物理情報を提供するソフトウェアであるセンシングアプリケーションと、を実行するものであり、
前記第１コアが、前記挙動スケジュールアプリケーションを実行し、
前記第２コアが、前記アクチュエータ制御アプリケーション及び前記センシングアプリケーションを実行する、マルチコア演算装置。
【請求項２】
前記車両用駆動伝達装置は、変速比を変更可能な変速装置を有し、前記挙動スケジュールアプリケーションは、前記変速装置に供給する流体圧の変化を前記挙動スケジュールとして決定する、請求項１に記載のマルチコア演算装置。
【請求項３】
前記車両用駆動伝達装置は、油圧制御アクチュエータを有し、前記アクチュエータ制御アプリケーションは、変調パターンを出力することによって前記油圧制御アクチュエータを制御する、請求項１又は２に記載のマルチコア演算装置。
【請求項４】
前記車両用駆動伝達装置は、少なくとも前記挙動スケジュールを決定するための前記物理情報を検出するセンサを有し、前記センシングアプリケーションは、前記センサにより検出された当該物理情報を取得する、請求項１から３の何れか一項に記載のマルチコア演算装置。
【請求項５】
さらに、前記アクチュエータ及び前記物理情報を検出するセンサを含む周辺デバイスとの通信を行う外部通信インターフェイスと、少なくとも前記外部通信インターフェイス及び前記共有メモリに対してＤＭＡ転送を行うＤＭＡコントローラとを備え、
前記外部通信インターフェイス及び前記ＤＭＡコントローラは、前記第１コア及び前記第２コアの内、前記第２コアによって実行されるアプリケーションによってのみ用いられ、
前記第１コアは、前記挙動スケジュールアプリケーションの実行による演算結果である前記挙動スケジュールを前記共有メモリに書き込み、
前記第２コアは、前記共有メモリに記憶された前記挙動スケジュールを前記共有メモリから読み出し、当該挙動スケジュールに基づいて前記アクチュエータ制御アプリケーションを実行すると共に、前記アクチュエータ制御アプリケーションの実行による演算結果を、ＤＭＡ転送により前記外部通信インターフェイスを介して前記アクチュエータに提供し、
さらに、前記第２コアは、前記センシングアプリケーションの実行により、前記外部通信インターフェイスが前記センサから受け取った前記物理情報を、ＤＭＡ転送により前記外部通信インターフェイスから前記共有メモリに記憶させる、請求項１から４の何れか一項に記載のマルチコア演算装置。
【請求項６】
複数の前記ＣＰＵコア及び前記共有メモリを収容する外囲器は、複数の入出力端子を備え、
前記第１コア及び前記第２コアには、それぞれ占有する前記入出力端子が割り当てられている、請求項１から５の何れか一項に記載のマルチコア演算装置。
【請求項７】
さらに、前記車両用駆動伝達装置に異常が生じた場合に、当該異常に対する対処を行うソフトウェアであるフェールセーフアプリケーションを実行するものであり、
当該フェールセーフアプリケーションは、前記第１コアによって実行される、請求項１から６の何れか一項に記載のマルチコア演算装置。
【請求項８】
前記共有メモリには、複数のデータの整合性が確保された状態で利用される複数のデータの集合であるデータグループが少なくとも１つ設定され、
前記データグループを含む共有資源を使用する権利であるアクセス権を管理する共有資源管理機能ブロックを備え、
前記共有資源は、前記アクセス権を有する前記ＣＰＵコアが使用可能であり、
前記ＣＰＵコアのそれぞれは、前記共有資源に対する前記アクセス権を獲得した後、当該共有資源を使用し、使用を終えた後に、前記アクセス権を解放するものであり、
前記共有資源管理機能ブロックは、１つの前記ＣＰＵコアが特定の前記共有資源に対する前記アクセス権を獲得した場合に、他の全ての前記ＣＰＵコアによる当該特定の前記共有資源の使用を禁止する排他処理を実行する、請求項１から７の何れか一項に記載のマルチコア演算装置。
【請求項９】
前記共有資源管理機能ブロックが、１つの前記ＣＰＵコアに特定の前記共有資源に対する前記アクセス権を与えて前記排他処理を実行している場合、
他の前記ＣＰＵコアは、当該アクセス権が解放された後の、次の前記アクセス権を獲得する権利であるアクセス予約権を前記共有資源管理機能ブロックに設定する、請求項８に記載のマルチコア演算装置。
【請求項１０】
前記ＣＰＵコアが、前記アクセス権の解放を待ち、前記ＣＰＵコアによる演算処理の実行が停止する状態であるデッドロックが生じて、予め規定されたタイムアウト時間を経過した場合には、少なくとも前記デッドロックが生じた前記ＣＰＵコアによる演算処理を初期状態に戻す処理であるリセット処理が、当該ＣＰＵコア、又は複数の前記ＣＰＵコアを統括管理する管理機能ブロックによって実行され、
前記共有資源に含まれるメモリ、又はそれぞれの前記ＣＰＵコアが占有するメモリの記憶領域に、当該リセット処理によって初期状態とならない記録領域が設定され、
前記リセット処理の実行時に、少なくとも前記アクセス権の獲得に失敗した回数を含むフェール情報が、前記記録領域に記録される、請求項８又は９に記載のマルチコア演算装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のＣＰＵコアを備えたマルチコア演算装置に関する。
【背景技術】
【０００２】
複数のＣＰＵコアを有するマルチコア演算装置が知られている。米国特許出願公開第２０１２／０２４６６５０Ａ１（特許文献１）には、複数のＣＰＵコア（プロセッサコア（６，７，１３，１４））を有するマルチコア演算装置（マルチコアマイクロコントローラ（５））が開示されている（背景技術において括弧内の符号は特許文献１のもの。）。マルチコアマイクロコントローラ（５）には、センサ素子（１）及びアクチュエータ（３）が接続されている。例えば、１つのプロセッサコア（６）は、センサ素子（１）のセンサ値を読み込み、物理現象を検出する。別のプロセッサコア（７）はアクチュエータ（３）を制御するためのパラメータを決定してアクチュエータ（３）に出力する。つまり、センサ素子（１）の検出結果に基づくアクチュエータ（３）の制御は、複数のプロセッサコア（６）によって分散処理されている。
【０００３】
一般的に、このように複数のプロセッサコアを用いた分散処理を行うことで、マイクロコントローラ全体の演算負荷を分散させて、演算能力を向上させることができる。但し、１つのプロセッサコアによる演算を、例えば単純に２つのプロセッサコアによる演算に換えても、処理速度が１／２になったり、処理量が２倍になったりするものではない。例えば、分散処理には、分散させた演算の同期や相互の演算時期の調整など、分散処理を管理する処理、いわゆるオーバーヘッド処理が発生し、このオーバーヘッド処理の分だけ、全体の演算量が増大する。また、プロセッサコアは、しばしば、メモリや通信制御器、Ａ／Ｄコンバータなどの周辺機能ブロックも利用しながら演算を行うが、複数のプロセッサコアが同じ周辺機能ブロックを利用する場合もある。例えば、１つのプロセッサコアがそのような周辺機能ブロックを使用している場合には、他のプロセッサコアは当該周辺機器ブロックが利用できるようになるまで待機する必要があり、演算待ち時間が生じることもある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開第２０１２／０２４６６５０Ａ１号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記背景に鑑みて、複数のＣＰＵコアを有するマルチコア演算装置において、適切に分散処理を行うことが望まれる。
【課題を解決するための手段】
【０００６】
１つの態様として、第１コアと、前記第１コアとは独立して動作する第２コアとの少なくとも２つの独立したＣＰＵコアと、複数の前記ＣＰＵコアが共通して使用する共有メモリと、を備えたマルチコア演算装置は、
複数の前記ＣＰＵコアが、前記共有メモリを介して通信を行い、
制御対象である車両用駆動伝達装置の挙動変化の順序を示す挙動スケジュールを決定するソフトウェアである挙動スケジュールアプリケーションと、
決定された前記挙動スケジュールに従って、前記車両用駆動伝達装置を動作させるアクチュエータを制御するソフトウェアであるアクチュエータ制御アプリケーションと、
少なくとも前記挙動スケジュールを決定するための物理情報を取得して、少なくとも前記挙動スケジュールアプリケーションに当該物理情報を提供するソフトウェアであるセンシングアプリケーションと、を実行するものであり、
前記第１コアが、前記挙動スケジュールアプリケーションを実行し、
前記第２コアが、前記アクチュエータ制御アプリケーション及び前記センシングアプリケーションを実行する。
【０００７】
例えば、車両用駆動伝達装置の挙動は、歯車などの機械構成要素の選択によって規定される。また、選択された歯車の接続（連結）などは、制御構成要素を介して実現されることが多い。ここで、機械構成要素の挙動に関する演算と、制御構成要素の挙動に関する演算とは、それぞれ異なるハードウェア資源を用いて実行されてもよい。しかし、制御対象が車両用駆動伝達装置の場合などでは、上述したように、機械構成要素と制御構成要素との挙動変化に順序依存性がある。このため、これら２つの制御をそれぞれ異なるハードウェア資源を用いて実行すると、互いに不要な待ち時間が生じて演算効率が低下する場合がある。本構成によれば、車両用駆動伝達装置の挙動変化の順序を示す挙動スケジュールが、１つのＣＰＵコアによって演算されるから、そのように演算効率が低下することが抑制される。
【０００８】
車両用駆動伝達装置において、歯車の連結などを実際に実現するためには、一般的にアクチュエータが必要である。アクチュエータは、当然ながらマルチコア演算装置の外部に備えられているから、制御信号やデータなどはマルチコア演算装置のインターフェイス機能ブロックを介して伝達される。また、車両用駆動伝達装置の動作状態などを示す物理情報を検出するセンサなども、マルチコア演算装置の外部に備えられている。従って、そのようなセンサによる検出情報も、マルチコア演算装置のインターフェイス機能ブロックを介して伝達される。例えば、アクチュエータ制御アプリケーションとセンシングアプリケーションとが異なるＣＰＵコアによって実行されていると、アクチュエータとセンサとが、同じ時期に同じインターフェイス機能ブロックを使おうとして、一方のＣＰＵコアに待ち時間が生じる場合がある。このような待ち時間は、何れのＣＰＵコアにも生じる場合があるので、全体として演算効率が低下する場合がある。本構成によれば、アクチュエータ制御アプリケーションとセンシングアプリケーションとが同じＣＰＵコアで実行されるから、そのように演算効率が低下することが抑制される。
【０００９】
マルチコア演算装置のさらなる特徴と利点は、図面を参照して説明する実施形態についての以下の記載から明確となる。
【図面の簡単な説明】
【００１０】
【図１】マルチコア演算装置を含む車両用駆動伝達装置の模式的ブロック図
【図２】車両用駆動伝達装置の制御処理の負荷を模式的に示す図
【図３】車両用駆動伝達装置の制御処理の流れを模式的に示す図
【図４】マルチコア演算装置の構成を示す模式的ブロック図
【図５】分散処理による車両用駆動伝達装置の制御処理の負荷を模式的に示す図
【図６】各ＣＰＵコアと機能ブロックとの関係を示す模式的ブロック図
【図７】入出力端子の一例を示す平面図
【図８】排他処理の一例を示す状態遷移図
【図９】排他処理及び予約処理の一例を示す状態遷移図
【発明を実施するための形態】
【００１１】
以下、マルチコア演算装置（Multi Core Processor）の実施形態を図面に基づいて説明する。本実施形態では、マルチコア演算装置は、車両用駆動伝達装置を制御対象とする半導体大規模集積回路（システムＬＳＩ）である。ここで、車両用駆動伝達装置とは、車両の車輪へ、駆動力源の駆動力を伝達する装置である。車両用駆動伝達装置は、少なくとも、駆動力源の側からの駆動力を受け取る入力部材と、車輪の側へ駆動力を提供する出力部材とを有し、入力部材と出力部材との間に、駆動力を伝達する伝動部材を有している。即ち、入力部材と出力部材とは、１つ以上の伝動部材を介して駆動連結されている。尚、駆動連結とは、２つの回転要素が駆動力を伝達可能に連結された状態を指し、当該２つの回転要素が一体的に回転するように連結された状態、或いは当該２つの回転要素が一又は二以上の伝動部材を介して駆動力を伝達可能に連結された状態を含む。
【００１２】
駆動力源は、回転電機や内燃機関、及びこれらを組み合わせたハイブリッド駆動機関などである。また、本実施形態では、駆動力を伝達する機構は、トルクコンバータ及び遊星歯車機構を備えたトルクコンバータ式自動変速装置、平歯車機構とクラッチ操作を自動的に行う機構とを備えた自動クラッチ式自動変速装置などの有段の変装装置、径が変わるプーリーにベルトやチェーンを架け渡して無段階で変速するＣＶＴ（Continuously Variable Transmission）などである。上述した伝動部材には、回転を同速で又は変速して伝達する各種の部材が含まれる。例えば、これらの変速装置が有する軸、歯車機構、ベルト、チェーン等は伝動部材に含まれる。また、回転及び駆動力を選択的に伝達する係合装置、例えば摩擦係合装置（ブレーキ、クラッチ）や噛み合い式係合装置等も伝動部材に含まれる。
【００１３】
また、よく知られているように、これらの変速装置では、摩擦係合装置や噛み合い式係合装置の係合状態の切り換えや、プーリーの径の変更などが、油圧回路を介した油圧制御によって行われる。本実施形態においては、マルチコア演算装置が制御対象とする車両駆動伝達装置にそのような油圧回路も含む。
【００１４】
図１は、マルチコア演算装置１０を用いて車両用駆動伝達装置１００を制御する車両用駆動制御装置２００の模式的ブロック図である。本実施形態では、図１に示すように、車両用駆動伝達装置１００は、自動変速装置１０１（A/T : Automatic Transmission）、油圧回路１０２（H/C : Hydraulic Circuit）、油圧回路１０２を制御するソレノイドなどのアクチュエータ（ACT-1, ACT-2, … ,ACT-n）、自動変速装置１０１や油圧回路１０２における物理現象を検出するセンサやスイッチ（S-1, S-2, … , S-n）を備えている。例えば、シフトポジションスイッチや、シフトポジションセンサ、油圧センサ、油温センサ、回転センサ等である。アクチュエータ、センサ、スイッチは、それぞれ複数備えられており、本実施形態では、油圧制御アクチュエータ群１２０（HCA : Hydraulic Control Actuators）、センサ群１３０（SEN/SW : Sensors / Switches）として例示している。尚、これらの油圧制御アクチュエータ群１２０及びセンサ群１３０は、マルチコア演算装置１０の外部に備えられた周辺デバイスに相当する。
【００１５】
また、本実施形態では、マルチコア演算装置１０は、第１コア１（CPU1）と第２コア２（CPU2）との２つの独立したＣＰＵコア３と、複数のＣＰＵコア３が共通して使用する共有メモリ４（Global RAM）と、ＤＭＡコントローラ６（DMAC : Direct Memory Access Controller）と、外部通信インターフェイス７（PI : Peripheral Interface）と、ＣＡＮトランシーバ８（CANT : CAN Transceiver）とを備えている。尚、本実施形態では、マルチコア演算装置１０が２つのＣＰＵコア３を有するデュアルコアの形態を例示するが、当然ながら３つ以上のＣＰＵコア３を有していてもよい。尚、マルチコア演算装置１０の構造上は、ＤＭＡコントローラ６及び外部通信インターフェイス７を、複数のＣＰＵコア３が共通して使用することが可能である（図４参照）。しかし、本実施形態では、ＤＭＡコントローラ６及び外部通信インターフェイス７は、第２コア２のみが使用し、第１コア１はこれらを使用しない。つまり、本実施形態では、ＤＭＡコントローラ６及び外部通信インターフェイス７は、単独のＣＰＵコア３（第２コア２）のみが使用する。従って、複数のＣＰＵコア３の間での調停（例えば排他処理等）を行う必要がなく、第２コア２の管理下において適時これらの機能部を用いたアプリケーションの実行が可能である。
【００１６】
マルチコア演算装置１０は、外部通信インターフェイス７を介して、車両用駆動伝達装置１００の油圧制御アクチュエータ群１２０、センサ群１３０に接続されている。また、マルチコア演算装置１０は、ＣＡＮトランシーバ８を介して、車両の車内ネットワーク３００（C/N : Car Network；図２等参照）に接続されて、各種の車内システムとＣＡＮ（Controller Area Network）規格で通信する。本実施形態では、車内システムとして、アンチロック・ブレーキ・システム３０１（ABS : Antilock Brake System）、電気式パワーステアリング３０２（EPS : Electric Power Steering）、故障診断システム３０３（DIAG : Diagnosis）などを例示している。
【００１７】
図２は、車両用駆動伝達装置１００に対する制御処理の負荷を模式的に示している。図２は、並列処理を行わずに、車両用駆動伝達装置１００を制御した場合の処理負荷を例示している。車両用駆動伝達装置１００に対する制御処理は、複数のアプリケーション（ソフトウェア）を組み合わせて実行されている。自動変速装置１０１及び油圧回路１０２に関するアプリケーションは、変速機制御アプリケーションＡＰ１（挙動スケジュールアプリケーション）及びフェールセーフアプリケーションＡＰ４である。車内ネットワーク３００に関するアプリケーションは、通信アプリケーションＡＰ５である。センサ群１３０に関するアプリケーションは、センシングアプリケーションＡＰ３である。油圧制御アクチュエータ群１２０に関するアプリケーションは、アクチュエータ制御アプリケーションＡＰ２である。
【００１８】
ところで、図２に示すように、変速機制御アプリケーションＡＰ１には、特に自動変速装置１０１に関連したアプリケーションである変速制御アプリケーションＡＰ１ａと、特に油圧回路１０２に関連したアプリケーションである油圧制御アプリケーションＡＰ１ｂとがある。変速制御アプリケーションＡＰ１ａは、変速比に応じたギヤの組み合わせなどを決めるアプリケーションである。油圧制御アプリケーションＡＰ１ｂは、変速制御アプリケーションＡＰ１ａが決定したギヤの組み合わせなどに応じて、自動変速装置１０１のクラッチやブレーキなどの係合装置を制御するための油圧、つまり油圧回路１０２における各所の油圧を決定する。
【００１９】
変速制御アプリケーションＡＰ１ａと、油圧制御アプリケーションＡＰ１ｂとは、このように順序依存性を有するため、総称して変速機制御アプリケーションＡＰ１と称する。また、変速機制御アプリケーションＡＰ１は、車両用駆動伝達装置１００におけるギヤやクラッチなどの挙動スケジュールを決定するアプリケーションということもできるので、挙動スケジュールアプリケーションと称することもできる。尚、フェールセーフアプリケーションＡＰ４は、油圧制御アプリケーションＡＰ１ｂの決定した油圧に応じて、対象となるクラッチやブレーキが正常に動作したか否かなどを判定し、異常が生じていた場合にはその対処を行うアプリケーションである。従って、フェールセーフアプリケーションＡＰ４も、変速制御アプリケーションＡＰ１ａ及び油圧制御アプリケーションＡＰ１ｂに対して順序依存性を有しているということができる。従って、フェールセーフアプリケーションＡＰ４も、挙動スケジュールアプリケーションに含めることができる。
【００２０】
図３は、これらのアプリケーションを並列処理することなく、直列処理した場合の制御処理の流れを模式的に示している。処理の優先順位は、図３の上段側のアプリケーションの方が、下段側のアプリケーションよりも高い。つまり、最も優先順位の高いアプリケーションは、アクチュエータ制御アプリケーションＡＰ２であり、続いてセンシングアプリケーションＡＰ３、通信アプリケーションＡＰ５である。挙動スケジュールアプリケーションである変速機制御アプリケーションＡＰ１及びフェールセーフアプリケーションＡＰ４は最も優先順位が低い。但し、挙動スケジュールアプリケーションは、車両用駆動伝達装置１００においてメインのアプリケーションとして実行される。
【００２１】
即ち、メインのアプリケーションとして、変速制御アプリケーションＡＰ１ａ、油圧制御アプリケーションＡＰ１ｂ、フェールセーフアプリケーションＡＰ４が、順に実行され、１サイクルずつ周期的に繰り返される。あるサイクルの処理が実行されている間に、前回のサイクルにおいて決定された油圧を満足するように、アクチュエータ制御アプリケーションＡＰ２が実行される。同様に、あるサイクルの処理が実行されている間に、センシングアプリケーションＡＰ３が実行されて、各種センサやスイッチからの検出結果が取得される。即ち、メインの処理の実行中に、アクチュエータ制御アプリケーションＡＰ２やセンシングアプリケーションＡＰ３を実行するための割り込み処理が実行される。通信アプリケーションＡＰ５の実行が要求される場合も同様に割り込み処理が実行される。図３において、白抜きの丸印は割り込みの発生を示し、破線の矢印はメイン処理に対して割り込み処理が実行されていることを示している。
【００２２】
一般的に、このような割り込み処理は、全体の演算速度を低下させる。例えば、これらのアプリケーションを並列処理することなく、直列処理した場合には、図２に示すように、演算負荷は最大演算能力に対して約９０％に達する。コンピュータシステムを安定的に運用する上では、演算負荷は７０％以下程度に抑えることが好ましい。本実施形態では、マルチコア演算装置１０を用いて並列処理を実現することによって、割り込み処理も削減し、演算負荷を低減させる。但し、処理を分割した場合には、その分割によって新たな処理が発生することがある。このような新たな処理をオーバーヘッド処理と称する。このため、単純に複数のアプリケーションを複数のＣＰＵコア３に分散させた場合には、オーバーヘッド処理が増加して、演算負荷の低減効果が限定的となることもある。本実施形態では、マルチコア演算装置１０のハードウェア構成も考慮し、そのようなオーバーヘッド処理も抑制して、適切に分散処理を実現する。
【００２３】
図４のブロック図は、マルチコア演算装置１０の構成を模式的に示している。図５は、図２に対応する図であり、車両用駆動伝達装置１００に対する制御処理を分散させた場合の負荷を模式的に示している。図６は、図１に対応するブロック図であり、車両用駆動伝達装置１００に対する制御処理を分散させる際の、各アプリケーションとマルチコア演算装置１０のハードウェア構成との関連を示している。
【００２４】
図１を参照して上述したように、マルチコア演算装置１０は、第１コア１と第２コア２との２つの独立したＣＰＵコア３を備えている。図４に示すように、本実施形態では、第１コア１と、第２コア２とは異なる構成のＣＰＵコア３であるが、第１コア１と第２コア２とは、同一の構成のＣＰＵコア３であってもよい。本実施形態では、第１コア１は、ＣＰＵコア３の中核となる第１マイクロプロセッサ１１（MPU : Micro Processing Unit）、第１割り込みコントローラ１２（INTC : Interrupt Controller）、浮動小数点演算ユニット１３（FPU : Floating-point Processing Unit）を有している。また、第１コア１には、共有メモリ４（Global RAM）の他に、第１コア１が占有する第１専用メモリ１９（Local RAM）が接続されている。第１コア１から第１専用メモリ１９に対するアクセス速度は、第１コア１から共有メモリ４へのアクセス速度に比べて高速である。
【００２５】
第２コア２は、第２マイクロプロセッサ２１（MPU）、第２割り込みコントローラ２２（INTC）を有している。第１コア１と同様に、第２コア２にも、第２コア２が占有する第２専用メモリ２９（Local RAM）が接続されている。第２コア２から第２専用メモリ２９に対するアクセス速度も、第２コア２から共有メモリ４へのアクセス速度に比べて高速である。
【００２６】
第１コア１及び第２コア２には、フラッシュメモリインターフェイス９０（FRASH I/F）を介して、アプリケーション（プログラムコード）が格納されたコード用フラッシュメモリ９（PGM FRASH）が接続されている。また、第１コア１、第２コア２及びフラッシュメモリインターフェイス９０は、マルチコア演算装置１０の中核となる機能ブロック（システム）を結ぶ連結バス２０（I-BUS : System Interconnect Bus）に接続されている。連結バス２０には、図１を参照して上述した共有メモリ４（Global RAM）及びＤＭＡコントローラ６（DMAC）も接続されている。
【００２７】
共有メモリ４は、第１コア１及び第２コア２の双方が利用するため、競合するおそれがある。このため、共有メモリ４を利用する権利（アクセス権）を管理するための機能ブロックとして、排他制御レジスタ４１（MEVR : Mutual Exclusion Value Resister）が設けられている。排他制御レジスタ４１は、第１コア１と第２コア２との間で、後述する相互排他値を管理する。管理の詳細については後述する。尚、本実施形態では、第１コア１と第２コア２との構成が異なり、一時記憶領域を大量に利用したり、浮動小数点を用いたりした複雑な演算は、第２コア２に比べて、第１コア１の方が適している。このため、共有メモリ４も第１コア１には直接接続されているが、第２コア２には連結バス２０を介して接続されている。
【００２８】
排他制御レジスタ４１は、共有資源５の１つである共有メモリ４に割り当てられた共有資源管理機能ブロックである。本実施形態では、第１コア１及び第２コア２が互いに他方のＣＰＵコア３に対して割り込み処理を要求するための共有資源管理機能ブロックとして、内部コア割り込み制御レジスタ４７（ICIR : Internal Core Interrupt Control Resister）も設けられている。例えば、第１コア１は、第２コア２によって利用することができてもよく、同様に第２コア２は、第１コア１によって利用することができてもよい。このような場合、第１コア１及び第２コア２は、相互に共有資源５となることができる。
【００２９】
１つの態様として、第１専用メモリ１９が、連結バス２０及び第１コア１を介して、第２コア２から利用可能であってもよい。第２コア２が、第１専用メモリ１９を利用する場合、同時に第１コア１が第１専用メモリ１９を利用すると好ましくないため、排他処理（排他制御）を行うことが好ましい。内部コア割り込み制御レジスタ４７はこのような場合に、排他処理を行うことができる。同様に、第２専用メモリ２９も、連結バス２０及び第２コア２を介して、第１コア１から利用可能であってもよい。当然ながら、第１専用メモリ１９及び第２専用メモリ２９の内の、一方のみが共有でき、他方は共有できない構成であってもよい。
【００３０】
第１コア１及び第２コア２は、マルチコア演算装置１０の内部バスであるプロセッサバス３０（P-BUS : Processor Bus）にも接続されている。また、プロセッサバス３０には、連結バス２０も接続されている。プロセッサバス３０には、上述した外部通信インターフェイス７やＣＡＮトランシーバ８（CANT）の他、ＡＤコンバータ３１（ADC : Analogue Digital Converter）、入出力レジスタ３２（I/O : Input / Output Terminal Register）、リセットコントローラ３３（RSTC : Reset Controller）、データ用フラッシュメモリ３４（DATA FLASH）などの機能ブロックが接続されている。入出力レジスタ３２は、マルチコア演算装置１０から出力されるデータを保持して、出力端子として機能する入出力端子１０ｔ（図７参照）から出力させ、入力端子として機能する入出力端子１０ｔからマルチコア演算装置１０に入力されたデータを保持して、マルチコア演算装置１０の機能ブロックに提供する機能ブロックである。リセットコントローラ３３は、ＣＰＵコア３を含む機能ブロックをリセットする機能ブロックである。データ用フラッシュメモリ３４は、書き込み及び書き換え可能な不揮発性のメモリであり、マルチコア演算装置１０への電源供給が途絶えた後も保持する必要のあるデータを格納することができる。
【００３１】
以下、このようなマルチコア演算装置１０により、車両用駆動伝達装置１００の制御ソフトウェア（アプリケーション）を分散処理する実施形態について説明する。図５は、第１コア１（CPU1）及び第２コア２（CPU2）へのアプリケーションの割り当てと処理負荷とを示している。図６は、マルチコア演算装置１０の機能ブロックの内、各ＣＰＵコア３により実行されるアプリケーションとの関連性が強い機能ブロックと、各ＣＰＵコア３との関係を示している。
【００３２】
図５に示すように、第１コア１（CPU1）が、変速機制御アプリケーションＡＰ１（挙動スケジュールアプリケーション）、フェールセーフアプリケーションＡＰ４を実行し、第２コア２（CPU2）が、アクチュエータ制御アプリケーションＡＰ２及びセンシングアプリケーションＡＰ３を実行する。後述するように、第１コア１は、さらに通信アプリケーションＡＰ５も実行するが、相対的に処理負荷の高い第１コア１であっても、負荷は最大演算負荷の７０％以下に収まっている。負荷分散の観点からは、適切な分散処理が実現できている。
【００３３】
具体的には、上述したように順序依存性の高い変速機制御アプリケーションＡＰ１及びフェールセーフアプリケーションＡＰ４は、１つのＣＰＵコア３（本実施形態では第１コア１）に集約されている。順序依存性の高い処理を複数のハードウェアに分割すると、待ち時間や同期処理時間など、オーバーヘッド処理に要する時間が大きくなる傾向がある。本実施形態のように、１つのハードウェア（ＣＰＵコア３）に順序依存性の高いアプリケーションを集約することによって、そのようなオーバーヘッド処理の発生を抑制し、分散処理による処理時間の増加を抑制することができる。
【００３４】
本実施形態では、第１コア１により通信アプリケーションＡＰ５が実行される形態を例示しているが、通信アプリケーションＡＰ５は、第１コア１及び第２コア２の何れのＣＰＵコア３によって実行されてもよい。プログラムコードの生成の容易性や、デバッグの容易性、複数のＣＰＵコア３の負荷バランスなどを考慮して、アプリケーションを実行するＣＰＵコア３が選択されればよい。例えば、ＣＡＮは汎用的な通信規格であるから、接続形態や通信速度などを設定することによって、自動的に基本的なプログラムコードを発生させるような自動ツールも実用化されている。第１コア１及び第２コア２が、互いにハードウェア構造や、オペレーティングシステムなどのコンピュータアーキテクチャが異なるような場合には、そのような自動ツールが利用可能なコンピュータアーキテクチャを有するＣＰＵコア３に通信アプリケーションＡＰ５を割り当てると好適である。
【００３５】
図５を参照して上述したように、アクチュエータ制御アプリケーションＡＰ２及びセンシングアプリケーションＡＰ３は、第２コア２（CPU2）が実行する。アクチュエータ制御アプリケーションＡＰ２では、例えば、予めマルチコア演算装置１０内のメモリに設定された変調パターンをＤＭＡ転送によって出力することによって油圧制御アクチュエータ群１２０を制御し、油圧制御アクチュエータ群１２０からの状態信号などをシリアル通信によってマルチコア演算装置１０内に取り込む。また、センシングアプリケーションＡＰ３では、例えば、センサ群１３０による検出結果をＤＭＡ転送によってマルチコア演算装置１０内のメモリに取り込み、センサ群１３０の制御などをシリアル通信によって行う。
【００３６】
図６に示すように、第１コア１は、変速機制御アプリケーションＡＰ１（挙動スケジュールアプリケーション）の実行による演算結果である挙動スケジュールを共有メモリ４に書き込む。第２コア２は、共有メモリ４に記憶された挙動スケジュールを共有メモリ４から読み出し、当該挙動スケジュールに基づいてアクチュエータ制御アプリケーションＡＰ２を実行する。アクチュエータ制御アプリケーションＡＰ２の実行による演算結果は、第２コア２の指令を受けたＤＭＡコントローラ６により、外部通信インターフェイス７にＤＭＡ転送され、外部通信インターフェイス７を介して油圧制御アクチュエータ群１２０に提供される。さらに、第２コア２は、センシングアプリケーションＡＰ３の実行により、センサ群１３０からの物理情報を外部通信インターフェイス７に受け取らせる。外部通信インターフェイス７がセンサ群１３０から受け取った物理情報は、第２コア２の指令を受けたＤＭＡコントローラ６により、外部通信インターフェイス７から共有メモリ４にＤＭＡ転送され、共有メモリ４に記憶される。
【００３７】
このように、アクチュエータ制御アプリケーションＡＰ２及びセンシングアプリケーションＡＰ３では、ＤＭＡコントローラ６や外部通信インターフェイス７を断続的に使用する。一方、変速機制御アプリケーションＡＰ１やフェールセーフアプリケーションＡＰ４では、ＤＭＡコントローラ６や外部通信インターフェイス７は使用しない。ＤＭＡコントローラ６や外部通信インターフェイス７は、共有メモリ４と同様に共有資源５であるから、異なるアプリケーションが同じ共有資源５を使用するためには調停が必要である。ここで、それらの異なるアプリケーションが異なるＣＰＵコア３によって実行されていると、異なるＣＰＵコア３の間で調停が必要となるため、通信時間や待ち時間などのオーバーヘッド時間が大きくなる。
【００３８】
特に本実施形態のように、第１コア１と第２コア２との独立性が高く、互いに直接接続されずに連結バス２０（I-BUS）を介して通信を行うような構成では、調停によるオーバーヘッド時間は長くなる傾向がある。さらに、図３に示すように、アクチュエータ制御アプリケーションＡＰ２及びセンシングアプリケーションＡＰ３は、１回の制御周期が相対的に短いため、高い頻度で断続的にＤＭＡコントローラ６や外部通信インターフェイス７を使用する。このため、調停によるオーバーヘッド時間が大きくなる傾向がある。本実施形態では、アクチュエータ制御アプリケーションＡＰ２及びセンシングアプリケーションＡＰ３が異なるＣＰＵコア３に分散されることなく、１つのＣＰＵコア３（ここでは第２コア２）によって実行される。従って、分散処理によるオーバーヘッドの発生が抑制されて、適切な分散処理が実現される。
【００３９】
尚、変速機制御アプリケーションＡＰ１においても、車内ネットワーク３００を介して変速指令などを受け取る場合がある。つまり、変速機制御アプリケーションＡＰ１もＣＡＮトランシーバ８を利用する場合がある。本実施形態では、主にＣＡＮトランシーバ８を用いるアプリケーションである通信アプリケーションＡＰ５は、変速機制御アプリケーションＡＰ１と共に第１コア１によって実行される。従って、同一の共有資源５を利用するアプリケーションを異なるＣＰＵコア３に分散させないという観点からも、第１コア１への通信アプリケーションＡＰ５の割り当ては適切ということができる。
【００４０】
また、上述したように、プロセッサバス３０に接続されたＡＤコンバータ３１や、入出力レジスタ３２、データ用フラッシュメモリ３４も、共有資源５の１つということができる。そして、入出力レジスタ３２に接続された入出力端子１０ｔ（図７参照）も共有資源５の１つということができる。入出力端子１０ｔの種別によっては、その属性を、マルチコア演算装置１０内で実行されるソフトウェアによって変更することが可能である。しかし、複数のＣＰＵコア３により複数のソフトウェア（アプリケーション）が並行して実行されるような場合には、ＤＭＡコントローラ６などと同様に、調停が必要である。従って、第１コア１及び第２コア２には、それぞれ占有する入出力端子１０ｔが割り当てられていると好適である。
【００４１】
図７は、複数のＣＰＵコア３及び共有メモリ４を収容し、複数の入出力端子１０ｔを備える外囲器１０ｐの模式的な外形図である。本実施形態では、ＢＧＡ（Ball Grid Array）タイプの半導体パッケージを例示している。例えば、図７に示すように、第１コア１が占有する第１端子群１ｔや、第２コア２が占有する第２端子群２ｔが予め割り当てられていると好適である。尚、このような端子の割り当ては、ハードウェア構造上、固定的に割り当てられていてもよいし、マルチコア演算装置１０の内部の不図示のレジスタによる設定など、ソフトウェア的に割り当てられていてもよい。
【００４２】
上述したように、同じ共有資源５を異なるＣＰＵコア３が利用することができるだけ少なくなるように、それぞれのＣＰＵコア３にアプリケーションを割り当てることで、適切な分散処理を実現することができる。しかし、全ての共有資源５が単一のＣＰＵコア３によって利用されるように、それぞれの共有資源５を占有させることは現実的ではない。例えば、共有メモリ４は、第１コア１と第２コア２との通信を媒介するためにも用いられるので、第１コア１及び第２コア２の何れかに占有させることはできない。従って、共有メモリ４の使用に際しては、調停処理が必要である。
【００４３】
本実施形態では、排他制御レジスタ４１（MEVR）を用いて排他処理が実施される。ここで、排他処理とは、１つのＣＰＵコア３が共有資源５（例えば共有メモリ４内の特定のデータグループ（DATA Gr.））にアクセスしている間は、他のＣＰＵコア３による同一の共有資源５へのアクセスを制限する処理である。排他制御レジスタ４１は、共有資源５を使用する権利であるアクセス権（後述するロックナンバー）を管理する共有資源管理機能ブロックの１つである。換言すれば、管理対象の共有資源５と排他制御レジスタ４１のロックナンバーとは互いに紐付けされている（関連付けられている）。
【００４４】
本実施形態では、共有メモリ４の内部に、第１コア１及び第２コア２の双方がデータを少なくとも参照する共通の記憶領域（データグループ(DATA Gr.)）が設定されている。このようなデータグループは、複数個設定することができる。ここで、１つのデータグループをデータ[a]、データ[b]、データ[c]による“[a, b, c]”とする。データ[a]、データ[b]、データ[c]は、それぞれ異なるデータであり、それぞれ異なるタイミングに書き込まれる（更新される）ものとする。但し、これらのデータは、データが取得されたタイミング（更新されたタイミング）が整合性を持っている状態で用いられる必要がある。例えば、これら３つのデータが、センシングアプリケーションＡＰ３によって取得されるデータであれば、全てが図３における同一の制御周期（例えば第１周期Ｔ１）で取得され、記憶されたデータであることが求められる。異なる制御周期で取得されたデータ、例えば、第１周期Ｔ１で取得されたデータと、第２周期Ｔ２で取得されたデータとが混在している状態は、整合性を有していない状態である。
【００４５】
以下、図３を参照して例示する。
[a, b, c] = [a1, b1, c1]  ：  整合性有り（同一の制御周期（Ｔ１）で取得）
[a, b, c] = [a2, b1, c1]  ：  整合性無し（異なる制御周期（Ｔ１，Ｔ２）で取得）
【００４６】
例えば、ＣＰＵコア３が単一で、図３に示すように、直列処理によってアプリケーションが実行される場合には、プログラムカウンタは１つしかなく、命令も１つずつ順に実行される。従って、上記の例であれば、データ[a1]、データ[b1]、データ[c1]を取得した後、データ[a2]を取得するよりも前に、データグループ[a, b, c]を利用する命令が実行されれば、データの整合性が保たれる。ここで、問題となるのは、いわゆる「割り込み処理」であるが、これは、「割り込み禁止」の処理を行うことによって回避することができる。
【００４７】
しかし、本実施形態のように、複数のアプリケーションが複数のＣＰＵコア３によって並列処理される場合には、そのような「割り込み禁止」の処理では上記のようなデータの整合性が保てないことがある。プログラムカウンタは、ＣＰＵコア３ごとに存在し、割り込み禁止処理は、それぞれのＣＰＵコア３にのみ効力を有する。例えば、第２コア２がデータグループ[a, b, c]を更新し、第１コア１及び第２コア２がデータグループ[a, b, c]を参照する場合、第２コア２がデータの整合性を保つように制御されていても、第１コア１が整合性の取れていない状態のデータグループ[a, b, c]を参照してしまうようなことが生じ得る。具体的には、第２コア２がデータを更新し、“[a, b, c] = [a2, b1, c1]”となっている状態で、第１コア１がデータグループ[a, b, c]を参照すると、整合性の取れていないデータを用いた制御が実行されてしまうことになる。
【００４８】
このような事象を回避するため、複数のデータグループのそれぞれにロックナンバーと称されるアクセス権を割り当て、ロックナンバーを取得しなければ、対象となるデータグループを参照できないように排他制御が行われる。排他制御レジスタ４１（共有資源管理機能ブロック）は、そのようなアクセス権（ロックナンバー）を管理する機能部である。本実施形態において、排他制御レジスタ４１は、複数ビットを有するレジスタである。１つのデータグループに対するロックナンバーは、後述するように１ビットで足りるため排他制御レジスタ４１は、複数のデータグループに対する排他制御を行うことができる。ロックナンバーは、排他制御を実施して更新・参照を行うデータグループのそれぞれに対して、それぞれ別に割り当てられる。
【００４９】
即ち、本実施形態では、共有メモリ４には、複数のデータの整合性が確保された状態で利用される複数のデータの集合であるデータグループが少なくとも１つ設定され、マルチコア演算装置１０には、データグループを含む共有資源５を使用する権利であるアクセス権（ロックナンバー）を管理する排他制御レジスタ４１（共有資源管理機能ブロック）が備えられる。以下で詳細に説明するように、共有資源５は、アクセス権を有するＣＰＵコア３が使用可能である。ＣＰＵコア３のそれぞれは、共有資源５に対するアクセス権を獲得した後、当該共有資源５を使用し、使用を終えた後に、アクセス権を解放する。排他制御レジスタ４１（共有資源管理機能ブロック）は、１つのＣＰＵコア３が特定の共有資源５に対するアクセス権を獲得した場合に、他の全てのＣＰＵコア３による当該特定の共有資源５の使用を禁止する排他処理を実行する。
【００５０】
図８は、排他処理の一例を示している。始めに第１コア１（CPU1）が共有メモリ４内のデータグループ[a, b, c]を使用するために、排他制御レジスタ４１（MEVR）に対してアクセス権の取得を要求する（＃１１ｒ）。アクセス権は、ロックナンバーと称される場合があるため、この要求を行う際のコマンド（アクセス権要求コマンド）は、図中において“LOCK＿REQ”と表す。アクセス権要求コマンドを受けた排他制御レジスタ４１は、データグループ[a, b, c]に割り当てられたアクセス権が空いている場合には、当該アクセス権に対応する排他制御レジスタ４１のレジスタ値である相互排他値（MEV : Mutual Exclusion Value）を“０”から“１”に変更すると共に、アクセス権を付与することを通知する応答を行う（＃１１ａ）。尚、相互排他値が“０”の場合は、アクセス権が空いていることを示し、“１”の場合はアクセス権が使用中であることを示し、アクセス権取得の成功を通知する応答は“ACK(success)”と表す。アクセス権を取得した第１コア１は、共有メモリ４（Global RAM）のデータグループ[a, b, c]を利用する。例えば、第１コア１は、データグループ[a, b, c]に格納されたデータを参照する。
【００５１】
第１コア１は、共有メモリ４の利用を終えると、アクセス権を解放する。本実施形態では、アクセス権解放要求コマンド（UNLOCK＿REQ）を排他制御レジスタ４１に送信する（＃１２ｒ）。コマンドを受信した排他制御レジスタ４１は、相互排他値を“１”から“０”に変更する。排他制御レジスタ４１は、この際、第１コア１に対して、＃１２ａに示すように応答してもよいし、応答しなくてもよい。
【００５２】
第１コア１がアクセス権を獲得している間に、第２コア２がアクセス権要求コマンド（LOCK＿REQ）を排他制御レジスタ４１に送信した場合（＃２１ｒ）、排他制御レジスタ４１は、アクセス権が使用中であることを通知する応答を行う（＃２１ａ）。図８に示すように、排他制御レジスタ４１は、アクセス権取得の失敗を通知する応答“ACK(fail)”を第２コア２に送信する。
【００５３】
排他制御レジスタ４１は、第１コア１からのアクセス権解放要求コマンド（UNLOCK＿REQ）の送信（＃１２ｒ）に基づき、相互排他値が“０”となった後で、第２コア２からのアクセス権要求コマンド（LOCK＿REQ）を受け取ると（＃２２ｒ）、相互排他値を“１”に変更すると共に、アクセス権取得の成功“ACK(success)”を通知する（＃２２ａ）。アクセス権を取得した第２コア２は、共有メモリ４（Global RAM）のデータグループ[a, b, c]を利用する。例えば、第２コア２は、データグループ[a, b, c]のデータを更新する。ここで、異なるタイミングで、データ[a]、データ[b]、データ[c]が更新される場合には、全てのデータの更新が完了するまで、第２コア２がアクセス権を保有していることが好ましい。このように、排他制御レジスタ４１が、共有メモリ４のデータグループ[a, b, c]に対するアクセス権を管理することによって、データの整合性を保持した状態で適切にデータグループ[a, b, c]を複数のＣＰＵコア３が利用することができる。
【００５４】
第２コア２は、データグループ[a, b, c]の利用を終えると、アクセス権を解放する（＃２３ｒ）。アクセス権解放要求コマンド（UNLOCK＿REQ）を受信した排他制御レジスタ４１は、相互排他値を“０”に変更する。ここで、第２コア２が再びアクセス権要求コマンド（LOCK＿REQ）を送信すると（＃２４ｒ）、排他制御レジスタ４１はアクセス権取得の成功“ACK(success)”を通知する（＃２４ａ）。第２コア２は続けてアクセス権を獲得し、再び共有メモリ４（Global RAM）を利用する。
【００５５】
第２コア２は、２度目のデータグループ[a, b, c]の利用を終えると、アクセス権を解放する（＃２５ｒ）。アクセス権解放要求コマンド（UNLOCK＿REQ）を受信した排他制御レジスタ４１は、相互排他値を“０”に変更する。ここで、第２コア２が、さらにアクセス権要求コマンド（LOCK＿REQ）を送信すると（＃２６ｒ）、排他制御レジスタ４１はアクセス権取得の成功“ACK(success)”を通知する（＃２６ａ）。第２コア２は３回続けてアクセス権を獲得し、データグループ[a, b, c]を利用する。
【００５６】
第１コア１は、第２コア２が最初に共有メモリ４のアクセス権を獲得した後、複数回アクセス権の取得を試みるが（＃１３ｒ，＃１４ｒ，＃１５ｒ，＃１６ｒ）、何れも失敗する（＃１３ａ，＃１４ａ，＃１５ａ，＃１６ａ）。この間、第１コア１は、いわゆるデッドロックの状態となって、データグループ[a, b, c]を利用した演算を実行することができない。このため、第１コア１は、処理時間が長引いたり、規定されたタイムアウト時間に達して処理が未完了のままリセットされてしまったりする場合がある。
【００５７】
そこで、図９に示すように、さらに予約フラグ（RSV＿CPU1, RSV＿CPU2）を設けて、アクセス予約権を設定することができるようにすると好適である。予約フラグ（アクセス予約権）は、変数として設定されている。各ロックナンバーに対して、各ＣＰＵコア３の予約フラグが設定されている。本実施形態では、第１コア１の予約フラグは第１予約フラグ４３（RSV＿CPU1）であり、第２コア２の予約フラグは第２予約フラグ４５（RSV＿CPU2）である。各ＣＰＵコア３は、アクセス権を獲得しようとする前に、対象のアクセス権に対応する他のＣＰＵコア３の予約フラグを確認する（後述する“CHK”）。他のＣＰＵコア３の予約フラグが予約状態（“１”）でなければ、ロックナンバー（アクセス権）の取得を要求する。尚、他のＣＰＵコア３は、予約フラグを有効にすることなく、ロックナンバーを獲得している場合がある。この場合には、ロックナンバーの獲得に失敗することになるので、自己の予約フラグが有効状態（予約状態）となるように、予約フラグをセットする。即ち、排他制御レジスタ４１（共有資源管理機能ブロック）が、１つのＣＰＵコア３に特定の共有資源５に対するロックナンバー（アクセス権）を与えて排他処理を実行している場合、他のＣＰＵコア３は、当該ロックナンバーが解放された後の、次のロックナンバーを獲得する権利であるアクセス予約権を排他制御レジスタ４１に予約フラグとして設定する。
【００５８】
以下、図９を参照して具体例を示す。予約フラグも用いた排他制御では、第１コア１は始めに他のＣＰＵコア３の予約フラグを確認する。本実施形態では、第１コア１は、２つの内の他方のＣＰＵコア３である第２コア２の予約フラグ（第２予約フラグ４５）の状態を確認する（＃１１ｃ）。第２予約フラグ４５の値は、非有効状態（予約権が設定されていない状態）を示す“０”であり、第１コア１によるデータグループ[a, b, c]へのアクセスが可能であるとの判定が示される（Judge(success)：＃１１ｊ）。第２コア２による予約がないことが確認されると、図８と同様に、第１コア１はアクセス権の取得を要求し（＃１１ｒ）、排他制御レジスタ４１は、相互排他値を“１”に変更すると共に、アクセス権の付与を通知する（＃１１ａ）。
【００５９】
ここで、第２コア２がアクセス権の取得を試みるケースを考える。第２コア２は、アクセス権の要求に先立って、第１コア１の予約フラグ（第１予約フラグ４３）の状態を確認する（＃２１ｃ）。第１コア１による予約権が設定されていなことから、第２コア２によるデータグループ[a, b, c]へのアクセスが可能であるとの判定が示される（Judge(success)：＃２１ｊ）。第２コア２は、この判定結果に基づいて、アクセス権の取得を要求する（＃２１ｒ）。しかし、予約フラグの確認は、アクセス予約権の設定状態の確認にすぎない。この場合には、既に第１コア１にアクセス権を与えているため、排他制御レジスタ４１は、アクセス権取得の失敗を通知する応答“ACK(fail)”を第２コア２に送信する（＃２１ａ）。アクセス権取得の失敗を通知された第２コア２は、第２コア２の予約フラグ（第２予約フラグ４５）の値を有効状態（予約権が設定された状態）を示す“１”に設定する（RSV＿SET：＃２１ｓ）。アクセス予約権を設定した後、第２コア２は、再度、アクセス権の取得を要求するが（＃２７ｒ）、第１コア１がアクセス権を開放しておらず、再度、アクセス権取得の失敗を通知する応答“ACK(fail)”が第２コア２に通知される（＃２７ａ）。
【００６０】
一方、排他制御レジスタ４１は、第１コア１からのアクセス権解放要求コマンド“UNLOCK＿REQ”の送信（＃１２ｒ）に基づき、相互排他値を“０”に設定し、アクセス権解放要求コマンド“UNLOCK＿REQ”を受け付けたことを第１コア１に応答する（＃１２ａ）。第１コア１は、続けてデータグループ[a, b, c]を利用するために、第２コア２の予約フラグ（第２予約フラグ４５）の状態を確認する（＃１７ｃ）。第２予約フラグ４５の値は、上述したように“１”であり、予約権が設定された状態である。従って、第１コア１によるデータグループ[a, b, c]へのアクセスが不可であるとの判定が示される（Judge(fail)：＃１７ｊ）。第１コア１は、再度、第２予約フラグ４５の状態を確認するが（＃１８ｃ）、状態が変わっていないため、再度、アクセスが不可であるとの判定が示される（Judge(fail)：＃１８ｊ）。尚、他のＣＰＵコア３の予約フラグの状態により、ロックナンバーの取得が妨げられている場合には、自己の予約フラグを有効状態に設定しないことが好ましい。相互予約の状態となって何れのＣＰＵコア３もロックナンバーを獲得できなくなることを抑制するためである。
【００６１】
自己の予約フラグ（第２予約フラグ４５）を有効状態に設定している第２コア２は、第１コア１の予約フラグ（第１予約フラグ４３）の状態を確認することなく、アクセス権要求コマンド“LOCK＿REQ”を送信する（＃２８ｒ）。上述したように、第２予約フラグ４５が“１”であるため、アクセス権（ロックナンバー）は第１コア１に獲得されることなく解放状態である。従って、排他制御レジスタ４１は、相互排他値を“１”に変更すると共に、アクセス権取得の成功“ACK(success)”を通知する（＃２８ａ）。また、ロックナンバーを取得したことにより、第２コア２は、自己の予約フラグ（第２予約フラグ４５）の値を非有効状態（予約していない状態）の“０”に変更する（RSV＿Release：＃２８ｓ）。
【００６２】
ここで、第１コア１が、第２コア２の予約フラグ（第２予約フラグ４５）の状態を確認すると（＃１９ｃ）、第２コア２による予約権が解除されているので、第１コア１によるデータグループ[a, b, c]へのアクセスが可能であるとの判定が示される（Judge(success)：＃１９ｊ）。第１コア１は、この判定結果に基づいて、アクセス権の取得を要求するが（＃１９ｒ）、既に第２コア２にアクセス権が与えられているため、排他制御レジスタ４１は、アクセス権取得の失敗を通知する（ACK(fail)：＃１９ａ）。アクセス権取得の失敗を通知された第１コア１は、第１コア１の予約フラグ（第１予約フラグ４３）の値を有効状態（予約権が設定された状態）を示す“１”に設定する（RSV＿SET：＃１９ｓ）。
【００６３】
以上、図９を参照して説明したように、排他制御レジスタ４１（共有資源管理機能ブロック）に予約フラグを設けて、各ＣＰＵコア３がアクセス予約処理を行うことによって、デッドロックの発生を抑制することができる。
【００６４】
ところで、デッドロックの発生原因は、図８に例示したような形態に限定されるものではない。ＣＰＵコア３が、同時に複数の共有資源５を利用するような場合において、複数のＣＰＵコア３が、互いに一部の共有資源５のアクセス権を獲得すると、互いに処理を実行することができずにビジー状態（busy）が継続することがある。この場合には、何れのＣＰＵコア３も処理を完了できないので、共有資源５も解放されず、全てのＣＰＵコア３がタイムアウトとなることもある。そのような事象も含めて、デッドロックの発生が抑制されるように設計されていてもデッドロックが発生してしまうことはある。デッドロックが発生したことを把握し、発生原因を解析することで、プログラムを変更してアプリケーションの改良を試みることができる。
【００６５】
例えば、ＣＰＵコア３が、アクセス権の解放を待ち、ＣＰＵコア３による演算処理の実行が停止する状態であるデッドロックが生じて、予め規定されたタイムアウト時間を経過した場合には、少なくともデッドロックが生じたＣＰＵコア３による演算処理を初期状態に戻す処理（リセット処理）が、当該ＣＰＵコア３、又は複数のＣＰＵコア３を統括管理する管理機能ブロックによって実行される。この管理機能ブロックとは、例えば、リセットコントローラ３３である。リセット処理が実行された場合には、少なくともアクセス権の獲得に失敗した回数を含むフェール情報が、マルチコア演算装置１０内の記録領域に記録される。例えば、共有資源５に含まれるメモリ（共有メモリ４、データ用フラッシュメモリ３４）、又はそれぞれのＣＰＵコア３が占有するメモリ（第１専用メモリ１９、第２専用メモリ２９）の記憶領域に、リセット処理によって初期状態とならない記録領域が設定される。尚、記録領域は、データ用フラッシュメモリ３４など、好ましくは電源が供給されていない状態でもデータが保持されている不揮発性のメモリに設定されているとよい。尚、フェール情報は、リセット処理が実行された回数を含むリセット情報であってもよい。
【００６６】
〔実施形態の概要〕
以下、上記において説明したマルチコア演算装置（１０）の概要について簡単に説明する。
【００６７】
１つの態様として、第１コア（１）と、前記第１コア（１）とは独立して動作する第２コア（２）との少なくとも２つの独立したＣＰＵコア（３）と、複数の前記ＣＰＵコア（３）が共通して使用する共有メモリ（４）と、を備えたマルチコア演算装置（１０）は、
複数の前記ＣＰＵコア（３）が、前記共有メモリ（４）を介して通信を行い、
制御対象である車両用駆動伝達装置（１００）の挙動変化の順序を示す挙動スケジュールを決定するソフトウェアである挙動スケジュールアプリケーション（ＡＰ１）と、
決定された前記挙動スケジュールに従って、前記車両用駆動伝達装置（１００）を動作させるアクチュエータ（１２０）を制御するソフトウェアであるアクチュエータ制御アプリケーション（ＡＰ２）と、
少なくとも前記挙動スケジュールを決定するための物理情報を取得して、少なくとも前記挙動スケジュールアプリケーション（ＡＰ２）に当該物理情報を提供するソフトウェアであるセンシングアプリケーション（ＡＰ３）と、を実行するものであり、
前記第１コア（１）が、前記挙動スケジュールアプリケーション（ＡＰ１）を実行し、
前記第２コア（２）が、前記アクチュエータ制御アプリケーション（ＡＰ２）及び前記センシングアプリケーション（ＡＰ３）を実行する。
【００６８】
例えば、車両用駆動伝達装置（１００）の挙動は、歯車などの機械構成要素（１０１）の選択によって規定される。また、選択された歯車の接続（連結）などは、制御構成要素（１０２）を介して実現されることが多い。ここで、機械構成要素（１０１）の挙動に関する演算と、制御構成要素（１０２）の挙動に関する演算とは、それぞれ異なるハードウェア資源を用いて実行されてもよい。しかし、制御対象が車両用駆動伝達装置（１００）の場合などでは、上述したように、機械構成要素（１０１）と制御構成要素（１０２）との挙動変化に順序依存性がある。このため、これら２つの制御をそれぞれ異なるハードウェア資源を用いて実行すると、互いに不要な待ち時間が生じて演算効率が低下する場合がある。本構成によれば、車両用駆動伝達装置（１００）の挙動変化の順序を示す挙動スケジュールが、１つのＣＰＵコア（３（１））によって演算されるから、そのように演算効率が低下することが抑制される。
【００６９】
車両用駆動伝達装置（１００）において、歯車の連結などを実際に実現するためには、一般的にアクチュエータ（１２０）が必要である。アクチュエータ（１２０）は、当然ながらマルチコア演算装置（１０）の外部に備えられているから、制御信号やデータなどはマルチコア演算装置（１０）のインターフェイス機能ブロック（６，７）を介して伝達される。また、車両用駆動伝達装置（１００）の動作状態などを示す物理情報を検出するセンサ（１３０）なども、マルチコア演算装置（１００）の外部に備えられている。従って、そのようなセンサ（１３０）による検出情報も、マルチコア演算装置（１０）のインターフェイス機能ブロック（６，７）を介して伝達される。例えば、アクチュエータ制御アプリケーション（ＡＰ２）とセンシングアプリケーション（ＡＰ３）とが異なるＣＰＵコア（３）によって実行されていると、アクチュエータ（１２０）とセンサ（１３０）とが、同じ時期に同じインターフェイス機能ブロック（６，７）を使おうとして、一方のＣＰＵコア（３）に待ち時間が生じる場合がある。このような待ち時間は、何れのＣＰＵコア（３）にも生じる場合があるので、全体として演算効率が低下する場合がある。本構成によれば、アクチュエータ制御アプリケーション（ＡＰ２）とセンシングアプリケーション（ＡＰ３）とが同じＣＰＵコア（３（２））で実行されるから、そのように演算効率が低下することが抑制される。
【００７０】
ここで、前記車両用駆動伝達装置（１００）は、変速比を変更可能な変速装置（１０１）を有し、前記挙動スケジュールアプリケーション（ＡＰ１）は、前記変速装置（１０１）に供給する流体圧の変化を前記挙動スケジュールとして決定すると好適である。
【００７１】
例えば、車両用駆動伝達装置（１００）の挙動は、機械構成要素である変速装置（１０１）における、歯車の組み合わせの選択や径が可変のプーリーの径の設定によって規定される。また、選択された歯車の組み合わせやプーリーの径の変更など機械構成要素の挙動は、制御構成要素の一例としての流体圧回路（１０２）などを介して実現されることが多い。上述したように、機械構成要素（変速装置（１０１））の挙動に関する演算と、制御構成要素（流体圧回路（１０２））の挙動に関する演算とは、それぞれ異なるハードウェア資源を用いて実行されてもよい。しかし、車両用駆動伝達装置（１００）が制御対象の場合には、機械構成要素（変速装置（１０１））と制御構成要素（流体圧回路（１０２））との挙動変化に順序依存性があるため、上述したように演算効率が低下するおそれがある。挙動スケジュールアプリケーション（ＡＰ１）の実行により、変速装置（１０１）の挙動を実現する流体圧の変化が挙動スケジュールとして決定されることで、演算効率を低下させることなく、円滑に車両用駆動伝達装置（１００）を制御することができる。
【００７２】
また、前記車両用駆動伝達装置（１００）は、油圧制御アクチュエータ（１２０）を有し、前記アクチュエータ制御アプリケーション（ＡＰ２）は、変調パターンを出力することによって前記油圧制御アクチュエータ（１２０）を制御すると好適である。
【００７３】
上述したように、車両用駆動伝達装置（１００）の制御構成要素は、例えば流体圧回路（１０２）などを介して実現されることが多い。また、流体圧回路（１０２）には、一般的に、油圧制御アクチュエータ（１２０）が備えられている。油圧制御アクチュエータ（１２０）の作動量は、種々の方法で制御可能であるが、例えば指令値に応じたパルス幅変調や、振幅変調などの変調を利用した制御であると、応答性がよく、好ましい。従って、アクチュエータ制御アプリケーション（ＡＰ２）が、変調パターンを出力することによって、油圧制御アクチュエータ（１２０）を制御するものであると好適である。
【００７４】
また、前記車両用駆動伝達装置（１００）は、少なくとも前記挙動スケジュールを決定するための前記物理情報を検出するセンサ（１３０）を有し、前記センシングアプリケーション（ＡＰ３）は、前記センサ（１３０）により検出された当該物理情報を取得すると好適である。
【００７５】
第１コア（１）による挙動スケジュールの決定に当たっては、自動変速装置（１０１）や油圧回路（１０２）における物理現象の検出が重要である。このため、多くの場合、車両用駆動伝達装置（１００）には、シフトポジション、油圧、油温等を検出するセンサが備えられている。第１コア（１）とは別の第２コア（２）により実行されるセンシングアプリケーション（ＡＰ３）により、そのようなセンサ（１３０）が検出した物理情報が取得されると、挙動スケジュールの演算に影響を与えることなく、適切な物理情報を得ることができる。
【００７６】
また、マルチコア演算装置（１０）は、さらに、前記アクチュエータ（１２０）及び前記物理情報を検出するセンサ（１３０）を含む周辺デバイスとの通信を行う外部通信インターフェイス（７）と、少なくとも前記外部通信インターフェイス（７）及び前記共有メモリ（４）に対してＤＭＡ転送を行うＤＭＡコントローラ（６）とを備え、
前記外部通信インターフェイス（７）及び前記ＤＭＡコントローラ（６）は、前記第１コア（１）及び前記第２コア（２）の内、前記第２コア（２）によって実行されるアプリケーションによってのみ用いられ、
前記第１コア（１）は、前記挙動スケジュールアプリケーション（ＡＰ１）の実行による演算結果である前記挙動スケジュールを前記共有メモリ（４）に書き込み、
前記第２コア（２）は、前記共有メモリ（４）に記憶された前記挙動スケジュールを前記共有メモリ（４）から読み出し、当該挙動スケジュールに基づいて前記アクチュエータ制御アプリケーション（ＡＰ２）を実行すると共に、前記アクチュエータ制御アプリケーション（ＡＰ２）の実行による演算結果を、ＤＭＡ転送により前記外部通信インターフェイス（７）を介して前記アクチュエータ（１２０）に提供し、
さらに、前記第２コア（２）は、前記センシングアプリケーション（ＡＰ３）の実行により、前記外部通信インターフェイス（７）が前記センサ（１３０）から受け取った前記物理情報を、ＤＭＡ転送により前記外部通信インターフェイス（７）から前記共有メモリ（４）に記憶させると好適である。
【００７７】
多くの場合、ＤＭＡコントローラ（６）や外部通信インターフェイス（７）などの機能部は、マルチコア演算装置（１０）が有する複数のＣＰＵコア（３）が利用できる。但し、これらの機能部を複数のＣＰＵコア（３）が利用する場合には、複数のＣＰＵコア（３）の間で、排他処理などの調停が必要となる。上記のように、ＤＭＡコントローラ（６）及び外部通信インターフェイス（７）を、単独のＣＰＵコア（３）（第２コア（２））のみが使用すると、そのような調停を行う必要がなく、第２コア（２）の管理下において適時これらの機能部を用いたアプリケーションの実行が可能である。その結果、通信時間や待ち時間などのオーバーヘッド時間が抑制でき、マルチコア演算装置（１０）の演算効率が向上する。
【００７８】
また、複数の前記ＣＰＵコア（３）及び前記共有メモリ（４）を収容する外囲器（１０ｐ）は、複数の入出力端子（１０ｔ）を備え、前記第１コア（１）及び前記第２コア（２）には、それぞれ占有する前記入出力端子（１０ｔ）が割り当てられていると好適である。
【００７９】
入出力端子（１０ｔ）を複数のＣＰＵコア（３）の間で共用していると、演算に待ち時間が生じる場合がある。しかし、第１コア（１）及び第２コア（２）に、占有する入出力端子（１０ｔ）が割り当てられていると、そのような待ち時間を生じることなく、円滑に車両用駆動伝達装置（１００）を制御することができる。
【００８０】
１つの態様として、マルチコア演算装置（１０）は、さらに、前記車両用駆動伝達装置（１００）に異常が生じた場合に、当該異常に対する対処を行うソフトウェアであるフェールセーフアプリケーション（ＡＰ４）を実行するものであり、当該フェールセーフアプリケーション（ＡＰ４）は、前記第１コア（１）によって実行されると好適である。
【００８１】
車両用駆動伝達装置（１００）に異常が生じた場合には、車両用駆動伝達装置（１００）の全体の挙動スケジュールに迅速に反映させることが望ましい。従って、フェールセーフアプリケーション（ＡＰ４）は、挙動スケジュールアプリケーション（ＡＰ１）が実行される第１コア（１）によって実行されると好適である。
【００８２】
また、前記共有メモリ（４）には、複数のデータの整合性が確保された状態で利用される複数のデータの集合であるデータグループが少なくとも１つ設定され、マルチコア演算装置（１０）は、前記データグループを含む共有資源（５）を使用する権利であるアクセス権を管理する共有資源管理機能ブロック（４１，４３）を備え、前記共有資源（５）は、前記アクセス権を有する前記ＣＰＵコア（３）が使用可能であり、前記ＣＰＵコア（３）のそれぞれは、前記共有資源（５）に対する前記アクセス権を獲得した後、当該共有資源（５）を使用し、使用を終えた後に、前記アクセス権を解放するものであり、前記共有資源管理機能ブロック（４１，４３）は、１つの前記ＣＰＵコア（３）が特定の前記共有資源（５）に対する前記アクセス権を獲得した場合に、他の全ての前記ＣＰＵコア（３）による当該特定の前記共有資源（５）の使用を禁止する排他処理を実行すると好適である。
【００８３】
例えば、共有資源（５）が共有メモリ（４）のデータグループであり、排他処理が実行されない場合には、ＣＰＵコア（３）が整合性の確保されていないデータを用いてアプリケーションを実行するおそれがあり、制御の信頼性が低下する。このような事象は、共有メモリ（４）のデータグループに限らず、入出力端子（１０ｔ）のデータを設定する入出力レジスタなどの他の共有資源でも発生する場合がある。排他処理を行うことによって、共有資源（５）の一貫性を保つことが可能となり、演算の安定性を担保することができる。
【００８４】
ここで、前記共有資源管理機能ブロック（４１，４３）が、１つの前記ＣＰＵコア（３）に特定の前記共有資源（５）に対する前記アクセス権を与えて前記排他処理を実行している場合、他の前記ＣＰＵコア（３）は、当該アクセス権が解放された後の、次の前記アクセス権を獲得する権利であるアクセス予約権を前記共有資源管理機能ブロック（４１，４３）に設定すると好適である。
【００８５】
アクセス権を有するＣＰＵコア（３）がアクセス権を解放した後、すぐにアクセス権を獲得すると、排他処理により、他のＣＰＵコア（３）は依然としてアクセス権を獲得することができない。このようなタイミングでのアクセス権の獲得失敗が続くと、当該他のＣＰＵコア（３）は、いわゆるデッドロックの状態となって、共有資源（５）を利用した演算を実行することができず、処理時間が長引いたり、規定されたタイムアウト時間に達して処理が未完了になってしまったりする。上述したように、アクセス予約権が設定されると、デッドロックの発生を抑制することができる。
【００８６】
１つの態様として、前記ＣＰＵコア（３）が、前記アクセス権の解放を待ち、前記ＣＰＵコア（３）による演算処理の実行が停止する状態であるデッドロックが生じて、予め規定されたタイムアウト時間を経過した場合には、少なくとも前記デッドロックが生じた前記ＣＰＵコア（３）による演算処理を初期状態に戻す処理であるリセット処理が、当該ＣＰＵコア（３）、又は複数の前記ＣＰＵコアを統括管理する管理機能ブロック（３３）によって実行され、
前記共有資源（５）に含まれるメモリ（４，３４）、又はそれぞれの前記ＣＰＵコア（３）が占有するメモリ（１９，２９）の記憶領域に、当該リセット処理によって初期状態とならない記録領域が設定され、
前記リセット処理の実行時に、少なくとも前記アクセス権の獲得に失敗した回数を含むリセット情報が、前記記録領域に記録されると好適である。
【００８７】
デッドロックの状態が解消されない場合には、リセット処理が実行される。アクセス権の獲得に失敗したことを示す情報が記録領域に記録されることで、マルチコア演算装置（１０）のデバッグ等の際に、デッドロックの発生頻度の把握や、発生したＣＰＵコア（３）の特定を行うことができる。そして、これらの情報に基づいて、車両用駆動伝達装置（１００）を制御するアプリケーション（プログラム、ソフトウェア）の改良や、共有資源管理機能ブロック（４１，４３）による排他処理及び予約処理等の改良を行うことができる。
【符号の説明】
【００８８】
１        ：第１コア
２        ：第２コア
３        ：ＣＰＵコア
４        ：共有メモリ
５        ：共有資源
６        ：ＤＭＡコントローラ
７        ：外部通信インターフェイス
１０      ：マルチコア演算装置
１０ｐ    ：外囲器
１０ｔ    ：入出力端子
３３      ：リセットコントローラ（管理機能ブロック）
３４      ：データ用フラッシュメモリ
４１      ：排他制御レジスタ（共有資源管理機能ブロック）
４１ｒ    ：予約レジスタ（共有資源管理機能ブロック）
４３      ：内部コア割り込み制御レジスタ（共有資源管理機能ブロック）
１００    ：車両用駆動伝達装置
１０１    ：自動変速装置
１０２    ：油圧回路
１２０    ：油圧制御アクチュエータ群（油圧制御アクチュエータ）
１３０    ：センサ群（センサ）
２００    ：車両用駆動制御装置
ＡＰ１    ：変速機制御アプリケーション
ＡＰ１ａ  ：変速制御アプリケーション
ＡＰ１ｂ  ：油圧制御アプリケーション
ＡＰ２    ：アクチュエータ制御アプリケーション
ＡＰ３    ：センシングアプリケーション
ＡＰ４    ：フェールセーフアプリケーション
【図１】
2018013843.tif 000003
【図２】
2018013843.tif 000004
【図３】
2018013843.tif 000005
【図４】
2018013843.tif 000006
【図５】
2018013843.tif 000007
【図６】
2018013843.tif 000008
【図７】
2018013843.tif 000009
【図８】
2018013843.tif 000010
【図９】
2018013843.tif 000011