JP5195913B2 - マルチコアシステム、車両用電子制御ユニット、タスク切り替え方法 - Google Patents

マルチコアシステム、車両用電子制御ユニット、タスク切り替え方法 Download PDF

Info

Publication number
JP5195913B2
JP5195913B2 JP2010521618A JP2010521618A JP5195913B2 JP 5195913 B2 JP5195913 B2 JP 5195913B2 JP 2010521618 A JP2010521618 A JP 2010521618A JP 2010521618 A JP2010521618 A JP 2010521618A JP 5195913 B2 JP5195913 B2 JP 5195913B2
Authority
JP
Japan
Prior art keywords
cpu core
task
core
cpu
processing load
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2010521618A
Other languages
English (en)
Other versions
JPWO2010010723A1 (ja
Inventor
一美 山田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toyota Motor Corp
Original Assignee
Toyota Motor Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toyota Motor Corp filed Critical Toyota Motor Corp
Priority to JP2010521618A priority Critical patent/JP5195913B2/ja
Publication of JPWO2010010723A1 publication Critical patent/JPWO2010010723A1/ja
Application granted granted Critical
Publication of JP5195913B2 publication Critical patent/JP5195913B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G06F11/1641—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/004—Error avoidance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/508—Monitor
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Hardware Redundancy (AREA)
  • Microcomputers (AREA)

Description

本発明は、複数のＣＰＵコアがタスク毎に処理を実行するマルチコアシステム、車両用電子制御ユニット及びタスク切り替え方法に関する。
プログラムの実行処理では、プログラムからＣＰＵの実行単位であるタスクを生成し、複数のタスクをスケジューリングしながら実行している。実行時間を保証する必要のある処理では、スケジューラが各タスクの優先度を決定し、優先度に応じてディスパッチャがＣＰＵにタスクを割り当てることができる。
そして複数のＣＰＵコアが実装されたコンピュータでは、複数のタスクを各ＣＰＵコアに時間的に重複して割り当てることで、処理効率を向上させている（例えば、特許文献１参照。）。特許文献１には、各タスクの並列処理可能度を算出し、並列処理可能度と処理時間の大小に応じて、各タスクを各ＣＰＵコアへ割り当てるマルチプロセッサシステムが記載されている。
また、複数のＣＰＵコアを別のＯＳ上で動作させ、各ＯＳでそれぞれタスクを分担して実行する場合がある（例えば、特許文献２参照。）。特許文献２には、ＯＳ毎に負荷を判定し、処理負荷の低いＯＳ上で作動しているＣＰＵコアを処理負荷の大きいＯＳ上で作動させることで、ＯＳ間の処理負荷を調整するマルチプロセッサシステムが記載されている。
しかしながら、特許文献２に記載されているようにＣＰＵコアに動的にタスクを割り当てると、不都合が生じる場合がある。例えば、モータ制御の一連のプロセスでは、前回のタスクの実行結果を次のタスクのフィードバック制御に適用してタスクを実行することが多い。例えば、電気モータの回転数を急激に増大させることは困難なので、電気モータの通電量をフィードバック制御により決定するタスクは、前回の通電量に応じた目標値が得られるように電気モータの通電量を演算する。
このように、制御系のマルチコアシステムでは、前回のタスクの実行結果を利用できないと期待した実行結果が得られないことがあり、処理負荷に応じて単にタスクを割り当てるＣＰＵコアを切り替えたり、新たなＣＰＵコアに並列処理を依頼すると制御量が急変し制御が破綻するおそれがあるという問題がある。
一般に、複数のＣＰＵコアは共有メモリやＩＰＣ（Inter Process Communication）などにより実行結果を受け渡すことができるが、共有メモリの内容が破壊されたり、プロセス間通信が遅延したりすることがあるため、かかる仕組みに期待するだけでは十分でない。
また、このようなマルチコアシステムの負荷分散は、情報処理系のタスクにおいては従来から知られているが、情報処理系のタスクではデータの入力と出力がほぼ一対一に対応し、前回のタスクの実行結果が次のタスクに必要となることは少ないため、制御処理系のタスクでは、前回のタスクの実行結果を考慮したタスクの割り当てについて、これまで提案されていない。
特開平１０−１４３３８０号公報 特開２００７−１８８２１２号公報
上記課題に鑑み、本発明は、制御の急変を生じさせずにタスクを実行するＣＰＵコアを切り替えることができるマルチコアシステム、車両用電子制御ユニット及びタスク切り替え方法を提供することを目的とする。
上記課題に鑑み、本発明は、制御系のプログラムを当該マルチコアシステムが実行して生成したタスクを、ＣＰＵコアに割り当てて実行するマルチコアシステムであって、第１のＣＰＵコア１が実行する前記タスクを、第２のＣＰＵコア２に切り替えて実行する際、タスクを第２のＣＰＵコア２に試験実行させる試験実行指示手段（例えば、ディスパッチャ３３）と、第１のＣＰＵコアの実行結果と第２のＣＰＵコアの実行結果が一致したか否かを判定する判定手段と、第１のＣＰＵコアの実行結果と第２のＣＰＵコアの実行結果が一致すると判定された場合、前記タスクの割り当て先を第２のＣＰＵコアに確定する割り当て確定手段と、を有することを特徴とする。
制御の急変を生じさせずにタスクを実行するＣＰＵコアを切り替えることができるマルチコアシステム、車両用電子制御ユニット及びタスク切り替え方法を提供することができる。
マルチコアシステムによる負荷分散を模式的に説明する図の一例である。 ＣＰＵコア１とＣＰＵコア２の処理負荷に偏りがある場合の負荷分散を模式的に示す図である。 マルチコアシステムが実現するプラットフォームを模式的に示す図の一例である。 マルチコアシステムを搭載したＥＣＵ（電子制御ユニット）の概略構成図の一例である。 マルチコアシステムの機能ブロック図の一例である。 優先テーブルの一例を示す図である。 一致判定テーブルの一例を示す図である。 マルチコアシステムがタスクをＣＰＵコアに割り当てる手順を示すフローチャート図の一例である。 処理の平準化、CPUコアの停止の手順の一例を示すフローチャート図の一例である。 ＣＰＵコアが３以上の場合の処理負荷の平準化を模式的に示す図の一例である。 マルチコアシステムによる負荷分散を模式的に説明する図の一例を示す（実施例２）。 マルチコアシステムの機能ブロック図の一例である（実施例２）。 マルチコアシステムが、高負荷となったＣＰＵコア１と、タスクＡの実行結果が最も早く一致したＣＰＵコア２にタスクＡの割り当て先を決定する手順を示すフローチャート図の一例である。
符号の説明
１１ ＡＰ（制御系のプログラム）
１２ ＯＳ
１３ ＯＳ間連携部
１４ ハードウェアリソース（ＨＷ）
２５ センサ類
２６ アクチュエータ類
５０ ＥＣＵ（電子制御ユニット）
１００ マルチコアシステム
以下、本発明を実施するための最良の形態について図面を参照しながら実施例を挙げて説明する。
図１Ａは、本実施形態のマルチコアシステム１００による負荷分散を模式的に説明する図の一例を示す。図１Ａのマルチコアシステム１００は、２つのＣＰＵコア１とＣＰＵコア２（以下、区別しない場合、ＣＰＵコア1~nという）とを有し、ＣＰＵコア１はスケジューリングされた結果に応じてタスク１、タスク２を実行している。そして、例えばＯＳ（Operating System）がＣＰＵコア１の処理負荷が高くなったこと又は高くなる可能性（以下、高負荷推定という場合がある）を検出すると、ＣＰＵコア２がＣＰＵコア１から所定のタスク（図ではタスクＡ）のコンテキストを受け取り（必ずしも受け取らなくてもよい）、ＣＰＵコア２がタスクＡを試験実行する。また、ＣＰＵコア１は、制御上の要請によりタスクＡを実行（以下、実需の実行という場合がある）するか、又は、ＣＰＵコア１もタスクＡを試験実行する。すなわち、いずれの場合もＣＰＵコア１がタスクＡを実行する。
そして、ＯＳはＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果が一致するか否かを判定し、一致する場合に、タスクＡを実行するＣＰＵコア1~nをＣＰＵコア１からＣＰＵコア２に切り替える。
ＣＰＵコア１とＣＰＵコア２の実行結果を検証した後に、タスクＡを実行するＣＰＵコア1~nを切り替えることで、前回の実行結果が今回の実行結果に反映される制御系の処理においても、タスクＡの演算結果に基づく制御に破綻をきたすことなく実行するＣＰＵコア1~nを切り替えることができる。また、タスクＡを割り当てた後、ＣＰＵコア１はタスクＢを実行し、ＣＰＵコア２はタスクＡを実行するので、マルチコアシステム１００の処理負荷を分散することができる。
図１Ｂは、ＣＰＵコア１とＣＰＵコア２の処理負荷に偏りがある場合の負荷分散を模式的に示す図である。例えば、ＯＳがＣＰＵコア１と２の処理負荷に偏りを検出するか又は偏りを予測すると（以下、偏り推定という場合がある）、図１Ａと同様に、ＣＰＵコア２がＣＰＵコア１から所定のタスク（図ではタスクＡ）のコンテキストを受け取り（必ずしも受け取らなくてもよい）、両者がタスクＡを実行する。ＯＳは、両者でタスクＡを実行し実行結果が一致した場合に、タスクＡを実行するＣＰＵコア1~nをＣＰＵコア２に切り替える。したがって、ＣＰＵコア２が起動している状態でも、実行結果を検証した後、負荷分散することができる。
図２は、マルチコアシステム１００が実現するプラットフォームを模式的に示す図の一例である。マルチコアシステム１００は、１つのハードウェアリソース（以下、ＨＷという）１４上で１以上のＯＳ１、ＯＳ２（以下、区別しない場合、ＯＳ１２という）を独立かつ並行に動作させることができる。また、ＯＳ１上ではアプリケーションＡＰ１〜ＡＰｎ（以下、区別しない場合、単にＡＰ１１という）が独立に実行可能であり、例えばＡＰ１の処理がＡＰ２の処理結果に影響を与えないようになっている。
このＡＰ１１のそれぞれが例えば、エンジン制御プログラム、白線や歩行者を認識する撮影系を処理するカメラ制御プログラム、ナビゲーションプログラム、等である。本実施形態のマルチコアシステム１００は、エンジンやアクチュエータなどのハードウェアを制御する制御系のＡＰ１１（ＡＰ１１から生成されるタスク）の実行時における、負荷分散を可能とする。また、カメラ制御プログラムは、カメラで撮影した画像を処理するものであるが、処理結果（例えば、幅員、曲率などの白線情報が得られる）を用いて例えば電動パワーステアリングの操舵角を制御することがあるため、制御系のプログラムと一体である。また、このように車外を撮影するカメラだけでなく、運転者の脇見や眠気の強さを検出するカメラ制御プログラムにおいても、脇見や眠気の強さの検出結果がブザー音を吹鳴するなどの制御に利用されるので制御系のプログラムに含まれる。同様に、ナビゲーションプログラムにおいても自車位置が交差点手前やカーブ手前に来るとシフトダウンや減速するなどの車両制御に関わるため、制御系のプログラムに含まれる。また、照明、施錠／解錠、ワイパー等を制御するボディ系を制御するプログラムも制御系のプログラムに含まれる。
また、マルチコアシステム１００に好適なＡＰ１１は制御の有無により判別されるだけでなく、処理態様からも判別可能である。ＡＰ１１のタスクが、電気モータの通電量やエンジン回転数のように物理状態が連続的に変化するハードウェアを制御するタスクの場合、ＣＰＵコア1~nは同じタスクの過去の実行結果が用いてタスクを実行する。したがって、制御系のＡＰ１１とは、ＣＰＵコア1~nが過去の実行結果を用いて同じタスクを実行するプログラム、又は、過去の実行結果が次の実行結果に反映されるプログラムと定義することができる。このような制御はフィードバック制御に多く実装されている。
本実施形態では、ＣＰＵコア１とＣＰＵコア２によりＯＳ１を実行し、ＣＰＵコア１とＣＰＵコア２でＡＰ１１のタスクＡ〜Ｃを実行しているものとする。各タスクＡ〜ＣとＡＰ１〜ＡＰｎは１対１に対応してもよいし、しなくてもよい。なお、図ではＡＰ１１はＯＳ１上で実行されているが、マルチコアシステム１００がマルチＯＳのプラットフォームの場合、ＡＰ１１の一部又は全てがＯＳ２で実行されていてもよい。
ＨＷ１４は、ＣＰＵコア１〜ｎに加え、メモリ（ＲＡＭ２１、ＣＰＵコアのキャッシュメモリ、記憶装置２２）１４ａ、Ｉ／Ｏデバイス（例えば、アクチュエータとのインターフェイス、スイッチ素子、タッチパネル、ディスプレイ等）１４ｂ、その他のハードウェアを有する。ＨＷ１４には少なくとも２以上のＣＰＵコア１，２（マルチコア型）又は複数のＣＰＵ（マルチＣＰＵ型）が備えられている。ＣＰＵコア１とＣＰＵコア２は、それぞれが同じアーキテクチャのホモジニアスでもよいし、異なるアーキテクチャを用いたヘテロジニアスでもよい。
ＯＳ間連携部１３は、ユーザ（例えば運転者）が存在を意識することのない常駐型のソフトウェアで、ＯＳ１とＯＳ２に対しＨＷ１４を論理的（時間的にも）に分割して割り当てる。したがって、マルチＯＳでないマルチコアシステム１００ではＯＳ間連携部１３は不要となる。後述するＯＳの機能は、ＯＳ１又はＯＳ間連携部１３いずれにより提供されてもよく、ＯＳ間連携部１３がない場合はＯＳ１により後述する機能を提供する。
ＯＳ間連携部１３は、この論理分割を利用して複数の仮想的な計算機の実行環境を作り、それらの実行環境の上でＯＳ１を動作させる。ＨＷ１４はＯＳ間連携部１３によりＯＳ１から隠蔽されている。ＯＳ間連携部１３は、ＯＳ１の負荷状況を監視しており、例えば、負荷が大きくなるとＣＰＵコア３にＯＳ２を新たに割り当て実行環境を生成したり、実行後はＯＳ１とＯＳ２が情報交換するためのＯＳ間通信手段を提供する。なお、ＯＳ１はシステムコールを発行することで各種のサービスをＯＳ間連携部１３に要求することができ、ＯＳ１とＯＳ間連携部１３とは相互に通信可能である。
〔車両用電子制御ユニットへの適用〕
車両に搭載される制御システムは多様化しており、ＣＰＵ間で生じる負荷の調整に対するニーズが高くなっている。このため、本実施形態のマルチコアシステム１００の一応用例として、車両用電子制御ユニットに好適に搭載することができる。
図３は、マルチコアシステム１００を搭載したＥＣＵ（電子制御ユニット）５０の概略構成図の一例を示す。ＥＣＵ５０は、例えばエンジンを制御するエンジンＥＣＵ、ハイブリッド車のモータジェネレータを制御するモータＥＣＵ、又は、エンジンとモータに必要なトルク指令値を指示するハイブリッドＥＣＵ等である。上述したように、ナビＥＣＵ等にマルチコアシステム１００を適用してもよい。
ＥＣＵ５０は、マルチコアシステム１００、ＲＡＭ２１、記憶装置２２、通信インターフェイス２３及び入出力インターフェイス２４、が内部バスで接続されている。通信インターフェイス２３は、例えばＣＡＮ（Controller
Area Network）やＬＩＮ（Local Interconnect Network）、ＦｌｅｘＲａｙ等の車載ＬＡＮに接続されており、他のＥＣＵ５との間で通信データを送受信する。例えば、通信インターフェイス２３は、ナビゲーションシステムを制御するナビＥＣＵやブレーキＥＣＵ等と接続されており、各ＥＣＵとの協調制御が可能となる。
また、入出力インターフェイス２４には、センサ類２５及びアクチュエータ類２６が接続されている。ＥＣＵ５０がエンジンを制御する場合、センサ類２５は、例えば、エアフローセンサ、クランクポジションセンサ、Ｏ２センサ等の各種のセンサであり、アクチュエータ類２６はスロットルバルブ、燃料噴射弁等の各種のアクチュエータである。また、ＥＣＵ５０がモータＥＣＵの場合、センサ類２５は、例えば相電流の電流値を検出する電流センサ、モータのロータの回転角を検出するレゾルバ等であり、アクチュエータ類２６は、例えばモータジェネレータである。
記憶装置２２はＥＥＰＲＯＭ、ハードディスクドライブやフラッシュメモリ等を実体とし、ＯＳのプログラムやデータが格納されたＯＳファイル、ＡＰ１１のプログラムやデータが格納されたＡＰファイルを記憶している。例えば、イグニッションのオンによりＥＣＵ５０に電力が供給されると、ＣＰＵコア１がＯＳファイルを実行し、ＯＳ間連携部１３を起動した後、ＯＳ１と予め定められたＡＰ１１を起動する。
〔マルチコアシステム１００の機能ブロック図〕
マルチコアシステム１００の機能ブロックについて図４を用いて説明する。図４の各ブロックは、ＯＳ１又はＯＳ間連携部１３により提供される。後述する優先テーブル３４や一致判定テーブル３７は、予めＨＷ１４のメモリ１４ａに記憶されていてもよいし、起動時に記憶装置２２からメモリ１４ａにコピーされてもよい。
ＯＳ１は、ＡＰ１１をＣＰＵの処理単位であるタスクに区分して、複数のタスクをスケジューリングしながら実行していく。タスクは、ＯＳ１が取り扱う処理の最小単位である。タスクは、ＡＰ１１のオブジェクトコードを実体とする。タスクはＴＣＢ（Task Control Block）により管理されており、ＴＣＢにはタスクの状態（実行可能状態、実行中状態、待機中状態）、タスクの識別情報、タスクへのポインタ、属性（再配置可能、再使用可能、再入可能等）、前のタスクのリンク情報、次のタスクのリンク情報、タスクの所有者（ＡＰ１１の識別情報）、コンテキスト（レジスタの内容等ＣＰＵコアの状態）等が登録されている。なお、コンテキストには、タスクの直前の実行結果が含まれる。
〔タスクスケジューリング〕
タスクスケジューラ３１は、タスクの優先度やタスクの状態に基づきメモリ１４ａ上にあるタスクの中から次にＣＰＵコア１及びＣＰＵコア２に割り当てるタスクを決定している。タスクスケジューラ３１は適切な優先度を付与して、タスクＡ、Ｂをタスクキューに登録する。ソフトウェア割り込み、ハードウェア割り込み、Ｉ／Ｏ割込み、システムコールなどの優先度の高い割込みが生じた場合は、タスクスケジューラ３１は強制的にタスクを切り替える（プリエンプション）。このようにタスクＡ、Ｂの優先度は、割込みなどの優先度に応じて相対的に定められるようになっている。なお、図では優先度の値が小さいほど優先度が高いとした。
優先度の最も高いタスクが先頭にくるよう、タスクキューはタイムスライス毎にソートされ、優先度が同じタスクの場合は、ＦＩＦＯ形式で順に実行される。
ディスパッチャ３３は各タスクの実行完了や他のタスクの割込みを検出すると、実行していたタスクのコンテキストをメモリ１４ａに保存して、次のタスクをＣＰＵコア１に実行させる。例えば、タスクキューを参照して最も優先度の高いタスクをそのＣＰＵコア１に割り当て、格納してあるそのタスクのコンテキストをＣＰＵコア１に復帰させる。この処理を繰り返し、１つのＣＰＵコア１で複数のタスクを実行する。
複数のＣＰＵコア１，２を備えるマルチコアシステム１００では、ＣＰＵコア毎にタスクキューが設けられることが多い。原則的に、同じタスクは同じＣＰＵコアのタスクキューに登録される。これにより、フィードバック制御のように過去の実行結果を利用するタスクから別のタスクにコンテキストスイッチする際、退避するコンテキストを低減してオーバヘッドを抑制し、また、退避するコンテキストに漏れがあっても、同じＣＰＵコアにより同じタスクを実行する限り、実行結果に連続性を保つことができる。
ＣＰＵコアとタスクの割り付けにはいくつか方法がある。例えば、ＣＰＵコア１とＣＰＵコア２の処理負荷を均等にするのであれば、タスク数が均等になるようにタスクＡ、Ｂ等を各タスクキューに割り当てればよい。一方、可能な限りＣＰＵコア１のみで全てのタスクを処理することで、他方のＣＰＵコア２を停止しておき消費電力を低減したい場合がある。このような場合、可能な限りＣＰＵコア１のタスクキューにタスクを登録しておき、ＣＰＵコア１の処理負荷が高くなった場合に、ＣＰＵコア２のタスクキューにタスクを登録すればよい。また、いったん複数のＣＰＵコア１，２が作動した状態では、タスクを均等に割り当てることで、ＣＰＵコア間の処理負荷を平準化することができる。本実施形態のマルチコアシステム１００は、このような考え方から、図示するように、当初（ＥＣＵ５０の起動時）、ＣＰＵコア１にのみタスクを割り当て消費電力の低減を図り、ＣＰＵコア２が起動した後は処理負荷を平準化する。
〔高負荷推定、偏り推定〕
負荷推定部３２は、ＣＰＵコア２が起動していない状態では、ＣＰＵコア１の処理負荷が高くなったこと、又は、高くなる可能性があることを検出し（高負荷推定）、ＣＰＵコア２が起動した後はＣＰＵコア１とＣＰＵコア２の処理負荷の差が所定値以上になったこと又はなる可能性があることを検出する（偏り推定）。
・ＣＰＵコア２が起動していない状態
処理負荷が高くなったことは、ＣＰＵコア１の使用率Ｒ１、タスクキューに登録されたタスク数Ｎ１、又は、制御対象の状態、のいずれか１以上から検出される。使用率Ｒ１は、所定時間Ｔ０（例えば、数十ミリ秒から数秒程度）におけるＣＰＵコア１がタスクを実行した時間Ｔの割合である。したがって、使用率Ｒ１＝Ｔ／Ｔ０。ＯＳ１が起動しただけの定常状態をアイドル状態というが、アイドル状態の処理負荷は十分に低いので、使用率Ｒ１が閾値Ｒ０より高ければタスクの実行による処理負荷が高いことが検出できる。同様の考え方により、タスクキューのタスク数Ｎ１が所定数Ｎ０より大きいの場合、ＣＰＵコア１の処理負荷が高くなったことを検出できる。また、乗員がＡＰ１１を起動する場合があるので、この起動操作から処理負荷が高くなったことを検出してもよい。
また、制御対象の状態から処理負荷が高くなったことを検出することができる。一般に、高速に状態が変化する制御対象を制御する場合、同じ制御対象を制御する場合でも状態変化が遅い場合よりも処理負荷が高くなる。例えば、エンジン回転数が高くなると、回転数制御や点火制御の時間間隔が回転数に比例して短くなるので、処理負荷は回転数に比例して高くなる。モータのトルクを制御する場合も同様である。したがって、センサ類２５から検出されるクランクポジションやロータの回転角速度が閾値以上になった場合に、処理負荷が高くなったことを検出することができる。なお、この場合、車速も大きくなっているので、車速が閾値以上になったことから処理負荷が高くなったことを検出してもよい。
以上から、負荷推定部３２は、処理負荷が高くなったことを次の条件のいずれか又は２以上の組み合わせにより検出する。ＴＲ１〜２、ＴＮ１〜２、ＴｄＲ１〜２、ＴｄＮ１〜２、ＴＲ１２、ＴＮ１２、ＴｄＲ１２、ＴｄＮ１２、ＴＳ、は閾値である。
使用率Ｒ１（＝Ｔ／Ｔ０）＞ ＴＲ１
、タスク数Ｎ１ ＞ＴＮ１ 、車両の状態値Ｓ ＞ ＴＳ
一方、処理負荷が高くなる可能性は、使用率Ｒ１の時間的な変化速度ｄＲ、タスク数Ｎ１の時間的な変化速度ｄＮ１、車両の状態値Ｓの時間的な変化速度ｄＳ、から検出することができる。負荷推定部３２は、使用率Ｒ１、タスク数Ｎ１、車両の状態値Ｓ、をそれぞれ時系列に監視し、変化速度ｄＲ１、ｄＮ１、ｄＳがそれぞれの閾値を超えた状態が所定時間Ｐ以上となった場合に、処理負荷が高くなる可能性があることを検出する。以上から、負荷推定部３２は、処理負荷が高くなる可能性のあることを次の条件のいずれか又は２以上の組み合わせにより検出する。
なお、使用率Ｒ１、タスク数Ｎ１、車両の状態値Ｓ、のいずれか又は２以上の組み合わせから、処理負荷が高くなる可能性を検出してもよい。
使用率Ｒ１の増加率ｄＲ１ ＞ ＴｄＲ１ 、タスク数Ｎ１の増加率ｄＮ１ ＞ ＴｄＮ１ 、車両の状態値Ｓの増加率ｄＳ＞ＴｄＳ
・ＣＰＵコア２が起動した後
ＣＰＵコア２が起動した後も、ＣＰＵコア２の使用率Ｒ２，タスク数Ｎ２、車両の状態値Ｓは、ＣＰＵコア１と同様に算出される。そして、負荷推定部３２は、ＣＰＵコア１とＣＰＵコア２の処理負荷が偏っていること、又は、偏る可能性のあることを検出する。
負荷推定部３２は、次の条件のいずれか又は組み合わせにより、ＣＰＵコア１とＣＰＵコア２の処理負荷が偏っていることを検出する。
使用率Ｒ１−使用率Ｒ２ ＞ ＴＲ１２
タスク数Ｎ１−タスク数Ｎ２ ＞ ＴＮ１２、
この場合、ＣＰＵコア１の処理負荷が高いことを意味するので、ＣＰＵコア２にタスクを割り当てる。
使用率Ｒ２−使用率Ｒ１ ＞ ＴＲ１２
タスク数Ｎ２−タスク数Ｎ１ ＞ ＴＮ１２、
この場合、ＣＰＵコア２の処理負荷が高いことを意味するので、ＣＰＵコア１にタスクを割り当てる。こうすることで、処理負荷を平準化できる。なお、車両の状態値Ｓは、ＣＰＵコア１，２に共通なので偏りを検出するには適当でないため、高負荷推定部３２は偏り推定に車両の状態値Ｓを用いない。
同様に、負荷推定部３２は、次の条件のいずれか又は組み合わせにより、ＣＰＵコア１とＣＰＵコア２の処理負荷が偏る可能性のあることを検出する。
使用率Ｒ１の増加率ｄＲ１−使用率Ｒ２の増加率ｄＲ２ ＞ ＴｄＲ１２ 、
タスク数Ｎ１の増加率ｄＮ１−タスク数Ｎ２の増加率ｄＮ２＞ ＴｄＮ１２
以上のようにして、負荷推定部３２は、高負荷推定及び偏り推定を検出する。
なお、ＣＰＵコア１又は２の処理負荷が低くなった場合（使用率Ｒ１がＴＲ１より小さい閾値以下、タスク数Ｎ１がＴＮ１より小さい閾値以下、のいずれか1以上の条件を満たす場合）、処理負荷が低くなったＣＰＵコア１又は２を停止させてもよい。一部のＣＰＵコア1~nを停止させることで消費電力を低減できる。この場合、停止するＣＰＵコア1~nで実行していたタスクは、別のＣＰＵコア1~nに割り当てられるが、これまで説明したように、実行結果が一致するか否かを判定した後に割り当てることで、制御の急変を防止する。
〔タスクの試験実行〕
ディスパッチャ３３が、処理負荷の低いＣＰＵコア２が試験実行するタスクＡを決定する方法について説明する。なお、図１Ａにて説明したように、ＣＰＵコア1~nがタスクを実行する場合、本実施例のマルチコアシステム１００では、制御上の要請（実需）によりタスクを実行する場合と、試験的にタスクを実行する場合がある。いずれの場合も、ディスパッチャ３３がタスクをＣＰＵコア1~nに割り当てる。また、タスクの実行が、試験的な実行から実需の実行に移行することもある。このため、「割り当て」と「試験実行」の区別は明確でないが、本実施例ではＣＰＵコア1~nが試験実行することに特徴があるため、ディスパッチャ３３によるタスクの割り当てを、ＣＰＵコア1~nに「試験実行させる」と表記する場合がある。
ＣＰＵコア２が試験実行するタスクＡを決定する方法には、静的な決定方法と動的な決定方法がある。静的な決定方法は、各タスクを優先的に実行するＣＰＵコア1~nを定めておく方法である。
図５Ａは優先テーブル３４の一例を示す図である。優先テーブル３４には、タスク毎に、優先的に試験実させるＣＰＵコア1~nが優先順位と共に登録されている。図１Ａに示したようにＣＰＵコア２の起動前、タスクＡはＣＰＵコア１で実行されているが、優先テーブル３４によればタスクＡはＣＰＵコア２で優先的に実行すべきことになる。したがってＣＰＵコア２が起動した後は、ディスパッチャ３３は、タスクＡをＣＰＵコア２に試験実行させることを決定できる。
ディスパッチャ３３は、ＣＰＵコア２の起動後も優先テーブル３４に従い、タスクＡを試験実行させるＣＰＵコア２を決定することができる。例えば図１Ｂの状態で処理負荷の偏り推定が検出された場合、優先テーブル３４によれば処理負荷の高いＣＰＵコア１で実行されているタスクＡはＣＰＵコア２で優先的に実行すべきなので、ディスパッチャ３３は、タスクＡをＣＰＵコア２に試験実行させることを決定できる。
その後、例えばＣＰＵコア２の処理負荷が高くなった場合、タスクＡ又はタスクＣを他のＣＰＵコアに移動するが、優先テーブル３４によれば、タスクＡ及びＣはいずれも最も優先的に割り当てられるＣＰＵコア２に割り当てられている。このため、ディスパッチャ３３は優先テーブル３４を参照して、優先順位が２番目のＣＰＵコア１にタスクＡを試験実行させる。なお、ＣＰＵコア１の処理負荷も高ければＣＰＵコア３を起動すればよい。
したがって、優先テーブル３４を適切に調整しておけば、ディスパッチャ３３が優先順位にしたがいタスクを試験実行させるＣＰＵコアを決定し、処理負荷を平準化することができる。
これに対し、動的な決定方法は、高負荷推定時又は偏り推定時の、ＣＰＵコア１（又はＣＰＵコア２）の状態に応じて、ディスパッチャ３３が、タスクを試験実行させるＣＰＵコア1~nを決定する方法である。例えば、ＣＰＵコア１でタスクＡを実行中であれば、タスクＡはそのままＣＰＵコア１で実行し、タスクＢはＣＰＵコア２で実行することで、コンテキストスイッチに伴うオーバヘッドを低減し、また、退避や復帰に伴うエラーを低減できる。この場合、ＣＰＵコア１は、タスクＡの実行結果をＩ／Ｏデバイス１４ｂを介してアクチュエータ類２６に供給できるので、制御を継続しながら試験実行できる。
タスクＢ以外に、ＣＰＵコア１で実行中でないタスクが複数ある場合がある（タスクＢとタスクＣがある場合）、どちらをＣＰＵコア２に試験実行させるかを決定する必要がある。この場合、ディスパッチャ３３はタスクキューに登録された各タスクの優先度を参照し、最も優先度の低いタスク又はタスクキューの最後尾のタスクをＣＰＵコア２に試験実行させる。こうすることで、後述する一致判定を行う時間的な余裕が生まれる。
〔試験実行に伴う実行結果の取り扱い〕
ところで、ＣＰＵコア１又はＣＰＵコア２で実行した実行結果（数値）は、ＣＰＵコア１、２のレジスタ１、２からそれぞれのデータバッファに格納された後、バスの調停を経て、ＲＡＭ２１、通信インターフェイス２３又は入出力インターフェイス２４に送出される。しかしながら、ＣＰＵコア２が試験的に実行したタスクＡの実行結果は、まだ実行結果の検証が不十分な状態である。また、ＣＰＵコア１によるタスクＡの実行は、車両制御上の要請による実需の実行とは限らない。また、仮にＣＰＵコア２の実行結果が正しく、ＣＰＵコア１の実行が実需によるものでも、同じ複数の実行結果は不要である。
すなわち、タスクＡを試験実行することにより、不要な実行結果が入出力インターフェイス２４等に出力されるおそれを生じさせる。そこで、ディスパッチャ３３がタスクＡをＣＰＵコア２に試験実行させた場合、有効化無効化切り替部３５は、ＣＰＵコア２が実行結果を入出力インターフェイス２４等に出力することを禁止する。また、ディスパッチャ３３が実需でないタスクＡをＣＰＵコア１に試験実行させた場合、有効化無効化切り替部３５は、ＣＰＵコア１が実行結果を入出力インターフェイス２４等に出力することを禁止する。こうすることで実需の実行結果のみが入出力インターフェイス２４に出力される。具体的には、有効化無効化切り替部３５は、例えばＣＰＵコア１やＣＰＵコア２のレジスタからデータバッファへの格納を禁止したり、データバッファに格納された実行結果を消去する。
〔実行結果の一致の判定〕
負荷推定部３２が高負荷推定又は偏り推定を検出すると、以上のようにディスパッチャ３３は、静的又は動的な方法でＣＰＵコア２にタスクＡを試験実行させるタスクを決定する。ディスパッチャ３３は割込み発生時と同様に、ＣＰＵコア１におけるコンテキストをＣＰＵコア２に復帰させる。なお、ＣＰＵコア１からＣＰＵコア２へコンテキスト（実行結果）を受け渡すことは必ずしも必要でない。これは、本実施形態では実行結果の一致を判定するからである。しかし、コンテキストを復帰することで、ＣＰＵコア１とＣＰＵコア２の実行結果が一致するまでの時間を短縮できることが期待できる。
そして、一致判定部３６はＣＰＵコア１によるタスクＡの実行結果と、ＣＰＵコア２によるタスクＢの実行結果とを比較し、両者が一致するか否かを判定する。実行結果は、ＣＰＵコア１と２のレジスタに格納されるので、一致判定部３６は２つのレジスタの内容の排他的論理和（Ｘｏｒ）をとり、全ビットが「０」であれば一致すると判定する。
一致する場合、割り当て確定部３８は、タスクＡを割り当てるＣＰＵコア1~nをＣＰＵコア２に確定する。割り当て確定部３８は、有効化無効化切り替部３５、ディスパッチャ３３及びタスクスケジューラ３１に確定したＣＰＵコア２を通知する。これにより、有効化無効化切り替部３５は、ＣＰＵコア２が実行結果を出力することを許可する。また、ディスパッチャ３３は、ＣＰＵコア１で実行しているタスクＡを強制的に終了させる。また、タスクスケジューラ３１は、ＣＰＵコア１のタスクキューからタスクＡを消去し、消去したタスクＡをＣＰＵコア２のタスクキューに登録する。
ところで、一致判定においては、実行結果が完全には一致しないものの、比較の結果に大きな差異がない場合がある。エンジンやモータ制御の場合、目標制御量とのわずかな差異であればそれを許容して、ＣＰＵコア間の処理負荷を平準化した方が好ましいとも考えられる。また、このような許容値はタスク毎に異なると考えられる。
そこで、マルチコアシステム１００は、一致判定テーブル３７に、タスク毎の実行結果の差異の許容値を登録しておく。図５Ｂは一致判定テーブル３７の一例を示す。一致判定部３６は、タスク毎に一致判定テーブル３７を参照して、許容範囲であれば一致すると判定する。以下では、許容範囲に入った場合を含めて「一致」したという。
また、一致しない場合、タスクＡを別のＣＰＵコア２に割り当てないと、ＣＰＵコア間の処理負荷の平準化を図れず、実行結果が遅延するおそれがある。そこで、一致判定部３６は、比較の結果が一致しない場合、一致するまで待機する。これにより、処理の平準化を促すことができる。
一方、長時間の待機は実需の演算の遅延をもたらすので、図５Ｂの一致判定テーブル３７には最大待機時間がタスク毎に登録されている。一致判定部３６は、比較の結果が一致しない場合、最大待機時間の間、繰り返しタスクを実行し、一致するまで待機する。最大待機時間内に、実行結果が一致しない場合、ディスパッチャ３３は次のタスク（例えば、タスクＢ）をＣＰＵコア２に試験実行させて、一致判定部３６は、再度、ＣＰＵコア１とＣＰＵコア２によるタスクＢの実行結果が一致するか否かを判定する。こうすることで、実行結果が一致しやすいタスクをＣＰＵコア２に割り当てることができる。なお、最大待機時間内であっても、タスクキューに優先度の高いタスクが登録されれば、一致判定のタスクはディスパッチャ３３により強制的に終了させられる。
〔マルチコアシステム１００の処理手順〕
・ＣＰＵコア２の起動前
以上の構成に基づき、マルチコアシステム１００がタスクＡをＣＰＵコア２に移動させる手順を図６のフローチャート図に基づき説明する。図６の手順は、マルチコアシステム１００が起動中、所定のサイクル時間毎に繰り返し実行される。スタート時、ＣＰＵコア２は起動しておらず、ＣＰＵコア１が全てのタスクを実行しており、負荷推定部３２はＣＰＵコア１の処理負荷を常時監視している。
サイクル時間毎に、負荷推定部３２は、処理負荷が高くなったか否か又は高くなる可能性があるか否かを判定する（Ｓ１０）。高負荷推定されなければ（Ｓ１０のＮｏ）、図６の処理はそのまま終了する。
高負荷推定した場合（Ｓ１０のＹｅｓ）、負荷推定部３２はディスパッチャ３３にタスクの試験実行を要求する。ディスパッチャ３３は、静的又は動的のいずれかの予め定められた方法で、割り当てるタスクＡを決定し、ＣＰＵコア２に試験実行させる。ＣＰＵコア１がタスクＡを実行していない場合、ディスパッチャ３３はＣＰＵコア１にタスクＡを実行させる（Ｓ２０）。
なお、ＣＰＵコア２が起動している場合は、ＣＰＵコア２の処理負荷が十分に低いことを確認しておく。また、タスクＡをＣＰＵコア２に試験実行させる際、有効化無効化切り替部３５は、ＣＰＵコア２による実行結果の出力を禁止する。同様に、ＣＰＵコア１によるタスクＡの実行が実需の実行でない場合、有効化無効化切り替部３５はＣＰＵコア１による実行結果の出力を禁止する。
そして、一致判定部３６は、ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果を比較する（Ｓ３０）。一致判定部３６は、一致判定テーブル３７を参照し差異が許容量の範囲内であるか否かに応じて、一致したか否かを判定する（Ｓ４０）。
ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果が一致した場合（Ｓ４０のＹｅｓ）、割り当て確定部３８はタスクＡの割り当て先をＣＰＵコア２に確定する（Ｓ５０）。これにより、ディスパッチャ３３は、ＣＰＵコア１に対するタスクＡの割り当てを終了し、有効化無効化切り替部３５はＣＰＵコア２によるタスクＡの実行結果の出力を許可し、タスクスケジューラ３１は、ＣＰＵコア１のタスクキューからタスクＡを消去し、消去したタスクＡをＣＰＵコア２のタスクキューに登録する。
以上で、処理負荷が低い間は消費電力を低減し、処理負荷が高くなった場合には２つのＣＰＵコアの処理負荷を平準化し、実行時間を保証することができる。
ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果が一致しない場合（Ｓ４０のＮｏ）、一致判定部３６は、一致判定テーブル３７のタスクＡの最大待機時間の間、繰り返し実行されるタスクＡの実行結果を比較する（Ｓ６０、Ｓ７０）。フィードバック制御であれば、実行の繰り返しにより２つの処理結果が接近することが期待できるので、待機することで処理の平準化を促進することができる。
・ＣＰＵコア２の起動後
続いて、ＣＰＵコア１とＣＰＵコア２がいずれもタスクを実行している状態で、処理負荷が偏った場合又は偏るおそれがあることが検出された場合の、処理手順について図７に基づき説明する。
サイクル時間毎に、負荷推定部３２は、処理負荷が偏ったか否か又は偏る可能性があるか否かを判定する（Ｓ１１）。
負荷推定部３２が偏り推定した場合（Ｓ１１のＹｅｓ）、負荷推定部３２はディスパッチャ３３にタスクの試験実行を要求する。ディスパッチャ３３は、静的又は動的のいずれかの予め定められた方法で、割り当てるタスクＡを決定し、ＣＰＵコア２に試験実行させる。また、ＣＰＵコア１がタスクＡを実行していない場合、ディスパッチャ３３はＣＰＵコア１にタスクＡを試験実行させる（Ｓ２０）。タスクＡをＣＰＵコア１に試験実行させる際、有効化無効化切り替部３５は、ＣＰＵコア２による実行結果の出力を禁止する。同様に、ＣＰＵコア１によるタスクＡの実行が実需の実行でない場合、有効化無効化切り替部３５はＣＰＵコア１による実行結果の出力を禁止する。
そして、一致判定部３６は、ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果を比較する（Ｓ３０）。一致判定部３６は、一致判定テーブル３７を参照し差異が許容量の範囲内であるか否かに応じて、一致したか否かを判定する（Ｓ４０）。
ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果が一致した場合（Ｓ４０のＹｅｓ）、割り当て確定部３８はタスクＡの割り当て先をＣＰＵコア１に確定する（Ｓ５０）。これにより、ディスパッチャ３３は、ＣＰＵコア１に対するタスクＡの割り当てを終了し、有効化無効化切り替部３５はＣＰＵコア２によるタスクＡの実行結果の出力を許可し、タスクスケジューラ３１は、ＣＰＵコア１のタスクキューからタスクＡを消去し、消去したタスクＡをＣＰＵコア２のタスクキューに登録する。以上で、２つのＣＰＵコア１，２間で処理負荷が偏った場合は処理負荷を平準化することができる。
ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果が一致しない場合（Ｓ４０のＮｏ）、一致判定部３６は、一致判定テーブル３７のタスクＡの最大待機時間の間、繰り返し実行されるタスクＡの実行結果を比較する（Ｓ６０、Ｓ７０）。これにより、可能な限り、処理を平準化することができる。
なお、図７では、ＣＰＵコアが２つの場合を説明したが、３つ以上のＣＰＵコアがそれぞれタスクを実行している場合、ディスパッチャ３３は、処理負荷の最も高いＣＰＵコアのタスクを最も低いＣＰＵコアに割り当てる。図８は、ＣＰＵコアが３以上の場合の処理負荷の平準化を模式的に示す図の一例である。図８では、ＣＰＵコア１の処理負荷が大、ＣＰＵコア２の処理負荷が小、ＣＰＵコア３の処理負荷が中、である。この場合、ディスパッチャ３３は、ＣＰＵコア１で実行されているタスクＡ又はＢを、ＣＰＵコア２に割り当てる。
また、平準化するのでなく、ＣＰＵコア２で実行されているタスクＣを、処理負荷が中程度のＣＰＵコア３に割り当てることで、ＣＰＵコア２を停止させ消費電力を低減できる場合がある。平準化するか消費電力の低減を図るかは、ＣＰＵコア１の処理負荷の大きさや、ＣＰＵコア２を停止させた際、ＣＰＵコア３の処理負荷がどの程度になるか等に応じて、定めることができる。
動的な決定方法の場合、ＣＰＵコア１で実行しているタスクＡをＣＰＵコア２にも試験実行させればよいが、静的な決定方法の場合、ＣＰＵコア２に試験実行させるタスクを決定する。静的な決定方法の場合、ディスパッチャ３３は、処理負荷の最も低いＣＰＵコア２に優先的に割り当てられているタスクであって、現在は処理負荷の最も高いＣＰＵコア１に割り当てられてるタスクを、優先テーブル３４を参照して決定する。そしてそのタスクを最も処理負荷の高いＣＰＵコア１と低いＣＰＵコア２に試験実行させる。試験実行させるタスクを優先テーブル３４により決定することで、処理負荷の平準化が容易になる。
ステップＳ１１に戻り、偏り推定されない場合（Ｓ１１のＮｏ）、負荷推定部３２は、ＣＰＵコア２の処理負荷が低いか否かを判定する（Ｓ１１０）。この判定の閾値は、ＣＰＵコア２を停止しそのタスクをＣＰＵコア１にて実行しても、ＣＰＵコア１の処理負荷が高くなることのないように定められる。したがって、使用率Ｒ１、タスク数Ｎ１、車両の状態値Ｓを判定する各閾値は、ＴＲ１
、ＴＮ１ 、ＴＳよりも小さい。
ＣＰＵコア２の処理負荷が低い場合（Ｓ１１０のＹｅｓ）、高負荷推定された場合と同様の処理によりＣＰＵコア２を停止させることができる。
具体的には、負荷推定部３２は、負荷推定部３２はディスパッチャ３３にタスクの試験実行を要求する。ディスパッチャ３３は、静的又は動的のいずれかの予め定められた方法で、割り当てるタスクＡを決定し、ＣＰＵコア１に試験実行させる。また、ＣＰＵコア２がタスクＡを実行していない場合、ディスパッチャ３３はＣＰＵコア２にタスクＡを試験実行させる（Ｓ１２０）。タスクＡを試験実行させる際、有効化無効化切り替部３５は、ＣＰＵコア１が実行結果を出力することを禁止し、ＣＰＵコア２によるタスクＡの実行が実需の実行でない場合、ＣＰＵコア２が実行結果を出力することを禁止する。
そして、一致判定部３６は、ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果を比較する（Ｓ１３０）。一致判定部３６は、一致判定テーブル３７を参照し差異が許容量の範囲内であるか否かに応じて、一致したか否かを判定する（Ｓ１４０）。
ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果が一致した場合（Ｓ１４０のＹｅｓ）、割り当て確定部３８はタスクＡの割り当て先をＣＰＵコア１に確定する（Ｓ１５０）。これにより、ディスパッチャ３３は、ＣＰＵコア２に対するタスクＡの割り当てを終了し、有効化無効化切り替部３５はＣＰＵコア１によるタスクＡの実行結果の出力を許可し、タスクスケジューラ３１は、ＣＰＵコア２のタスクキューからタスクＡを消去し、消去したタスクＡをＣＰＵコア１のタスクキューに登録する。
また、マルチタスクシステム１００は、例えばクロックの供給を終了してＣＰＵコア２を停止する。これにより、消費電力を低減できる。このようにして、処理負荷が低いＣＰＵコア２を停止して、消費電力を低減することができる。
ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果が一致しない場合（Ｓ１４０のＮｏ）、一致判定部３６は、一致判定テーブル３７のタスクＡの最大待機時間の間、繰り返し実行されるタスクＡの実行結果を比較する。待機することで消費電力の低減を促進しやすくなる。
以上説明したように、本実施形態のマルチコアシステム１００は、制御系のプログラムから生成されたタスクの実行結果を急変させずに、タスクを実行するＣＰＵコアを切り替えることができる。
実施例１のマルチコアシステム１００は、最大待機時間を上限に、ＣＰＵコア１とＣＰＵコア２の実行結果が一致するまで待機した。しかし、負荷分散では、高負荷となった例えばＣＰＵコア１から、可能な限り早くタスクＡを他のＣＰＵコア２に割り当てることが好ましい。
ところで、複数のＣＰＵコア1~nがある場合、処理負荷を分散するためにタスクの割り当て先は最も処理負荷の小さいＣＰＵコアとすることが一般的である。しかし、制御系のタスクでは、制御の連続性を確保したままタスクの割り当て先を切り替える必要があるので、処理負荷の低いＣＰＵコア1~nにタスクを割り当てるよりも、早く処理負荷を分散できるという観点から、割り当て先のＣＰＵコア1~nを選定する方が好ましい場合もある。すなわち、処理負荷が低いＣＰＵコア1~nにタスクを割り当てて、実行結果が一致するまで時間を掛けるよりも、多少、処理負荷が高くても、早く一致する実行結果が得られるＣＰＵコアの方が割り当て先として最適となる場合がある。
そこで、本実施例では、割り当て先として複数のＣＰＵコア1~nがある場合、最も早く実行結果が一致したＣＰＵコア1~nにタスクを割り当てるマルチコアシステム１００について説明する。
図９は、本実施例のマルチコアシステム１００による負荷分散を模式的に説明する図の一例を示す。本実施例のマルチコアシステム１００は、複数のＣＰＵコア1~nに同じタスクを試験実行させ、最も早く実行結果が一致したＣＰＵコア1~nをタスクの割り当て先に確定する。
図９では、マルチコアシステム１００は４つのＣＰＵコア１〜４を有する。ＣＰＵコア１はタスクＡ、タスクＢを、ＣＰＵコア４はタスクＤをそれぞれ実行している。ＣＰＵコア１が高負荷になったので、実施例１と同様に例えばディスパッチャ３３がタスクＡをＣＰＵコア２〜３に試験実行させる。高負荷判定部は、各ＣＰＵコア1~nの処理負荷を監視しており、処理負荷が所定値以下のＣＰＵコア1~nを抽出し、ディスパッチャ３３に通知する。図９では、ＣＰＵコア４の処理負荷が高いので、ディスパッチャ３３はＣＰＵコア４にタスクＡを試験実行させない。
一致判定部３６は、ＣＰＵコア１によるタスクＡの実行結果とＣＰＵコア２によるタスクＡの実行結果を比較し、ＣＰＵコア１によるタスクＡの実行結果とＣＰＵコア３によるタスクＡの実行結果を比較する。そして、一致判定部３６は、ＣＰＵコア１によるタスクＡの実行結果に、最も早く実行結果が一致したＣＰＵコア1~nを検出する。割り当て確定部３８は最も早く実行結果が一致したタスクＡの割り当て先をＣＰＵコア２に確定する。
こうすることで、割り当て先のＣＰＵコア1~nを確定するまでの時間を短縮できるので、複数のＣＰＵコア1~n間で処理負荷を分散する際に、制御が不安定になるリスクを低減できる。
〔マルチコアシステム１００の機能ブロック〕
図１０は、本実施例におけるマルチコアシステム１００の機能ブロック図の一例を示す。なお、図１０において図４と同一部には同一の符号を付しその説明は省略する。負荷推定部３２は、全てのＣＰＵコア1~nの処理負荷を監視している。そして、いずれかのＣＰＵコア1~nの処理負荷が高くなったこと、又は、高くなる可能性があることを検出する。なお、全てのＣＰＵコア1~nの処理負荷が一様に高負荷推定されることは少ないので、本実施例では、高負荷推定と偏り推定は同義としてよい。負荷推定部３２が、例えば、ＣＰＵコア１について高負荷推定した場合、負荷推定部３２は、例えば、処理負荷が所定値以下のＣＰＵコア２、３を、タスクＡを割り当てる候補のＣＰＵコア1~nに決定する。
ディスパッチャ３３は、候補に決定されたＣＰＵコア２，３に、それぞれタスクＡを試験実行させる。また、高負荷のＣＰＵコア１がタスクＡを実行していない場合は、ディスパッチャ３３はＣＰＵコア１にタスクＡを試験実行させる。こうすることで、各ＣＰＵコア１〜３は、それぞれタスクＡを実行する。なお、ＣＰＵコア２とＣＰＵコア３がタスクＡの実行を開始する時刻は、ＣＰＵコア２とＣＰＵコア３の処理状況により定まるので、ＣＰＵコア２とＣＰＵコア３が同時にタスクＡの実行を開始するとは限らない。
そして、本実施例の一致判定部３６は、高負荷のＣＰＵコア１によるタスクＡの実行結果と、判定用にタスクＡが割り当てられた各ＣＰＵコア２の実行結果、高負荷のＣＰＵコア１によるタスクＡの実行結果と、判定用にタスクＡが割り当てられた各ＣＰＵコア３によるタスクＡの実行結果をそれぞれ比較する。一致判定部３６は、最も早く実行結果が一致した例えばＣＰＵコア２の識別情報を割り当て確定部３８に通知する。
割り当て確定部３８はタスクＡの割り当て先をＣＰＵコア２に確定する。割り当て確定部３８は、有効化無効化切り替部３５、ディスパッチャ３３及びタスクスケジューラ３１に確定したＣＰＵコア２の識別情報を通知する。これにより、有効化無効化切り替部３５は、ＣＰＵコア２が実行結果を出力することを許可する。また、ディスパッチャ３３は、ＣＰＵコア１とＣＰＵコア３で実行しているタスクＡを強制的に終了させる。また、タスクスケジューラ３１は、ＣＰＵコア１のタスクキューからタスクＡを消去し、消去したタスクＡをＣＰＵコア２のタスクキューに登録する。
こうすることで、マルチコアシステム１００は、高負荷となったＣＰＵコア１と、タスクＡの実行結果が最も早く一致したＣＰＵコア２をタスクＡの割り当て先に確定でき、割り当て先のＣＰＵコア1~nを確定するまでの時間を短縮できる。
〔マルチコアシステム１００の処理手順〕
図１１は、マルチコアシステム１００が、高負荷となったＣＰＵコア１と、タスクＡの実行結果が最も早く一致したＣＰＵコア２にタスクＡの割り当て先を確定する手順を示すフローチャート図の一例を示す。なお、ＣＰＵコア１〜４は起動していてもよいし、起動していなくてもよい。
負荷推定部３２はＣＰＵコア１〜４の処理負荷を常時監視している。負荷推定部３２は、処理負荷が高くなったか否か又は高くなる可能性があるか否かを判定する（Ｓ１０）。高負荷推定されなければ（Ｓ１０のＮｏ）、負荷分散する必要はないので、図６の処理はそのまま終了する。
高負荷推定された場合（Ｓ１０のＹｅｓ）、負荷推定部３２はタスクＡの仮の割り当て先を決定する（Ｓ１２）。仮の割り当て先は処理負荷が所定値以下のＣＰＵコア２，３である。
ディスパッチャ３３は、静的又は動的のいずれかの予め定められた方法で決定されたタスクＡをＣＰＵコア２とＣＰＵコア３に試験実行させる（Ｓ２１）。高負荷のＣＰＵコア１がタスクＡを実行していない場合は、ディスパッチャ３３はＣＰＵコア１にタスクＡを試験実行させる。
ディスパッチャ３３がタスクＡをＣＰＵコア２，ＣＰＵコア３に試験実行させる際、有効化無効化切り替部３５は、ＣＰＵコア２、３による実行結果の出力を禁止し、ＣＰＵコア１によるタスクＡの実行が実需の実行でない場合、ＣＰＵコア１による実行結果の出力を禁止する。
そして、一致判定部３６は、ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果、ＣＰＵコア１とＣＰＵコア３によるタスクＡの実行結果、をそれぞれ比較する（Ｓ３０）。一致判定部３６は、一致判定テーブル３７を参照し差異が許容量の範囲内であるか否かに応じて、一致したか否かを判定する（Ｓ４０）。
ＣＰＵコア１とＣＰＵコア２によるタスクＡの実行結果が最も早く一致した場合（Ｓ４０のＹｅｓ）、割り当て確定部３８はタスクＡの実行結果をＣＰＵコア２に確定し、ＣＰＵコア１とＣＰＵコア３によるタスクＡの実行結果が最も早く一致した場合（Ｓ４０のＹｅｓ）、割り当て確定部３８はタスクＡの実行結果をＣＰＵコア３に確定する（Ｓ５０）。一致するか否かの判定は、実施例１と同様に最大待機時間の間、繰り返される。
割り当て確定部３８は、有効化無効化切り替部３５、ディスパッチャ３３及びタスクスケジューラ３１に確定したＣＰＵコアを通知する。これにより、有効化無効化切り替部３５は、ＣＰＵコア２が実行結果を出力することを許可する。また、ディスパッチャ３３は、ＣＰＵコア１とＣＰＵコア３で実行しているタスクＡを強制的に終了させる。また、タスクスケジューラ３１は、ＣＰＵコア１のタスクキューからタスクＡを消去し、消去したタスクＡをＣＰＵコア２のタスクキューに登録する。
本実施例のマルチコアシステム１００によれば、割り当て先のＣＰＵコア1~nを確定するまでの時間を短縮できるので、複数のＣＰＵコア間で処理負荷を分散する際に、制御が不安定になるリスクを低減できる。
なお、本国際出願は、２００８年７月２２日に出願した日本国特許出願２００８−１８８８３０号に基づく優先権を主張するものであり、日本国特許出願２００８−１８８８３０号の全内容を本国際出願に援用する。

Claims (18)

  1. 制御系のプログラムを当該マルチコアシステムが実行して生成したタスクを、ＣＰＵコアに割り当てて実行するマルチコアシステムであって、
    第１のＣＰＵコアが実行する前記タスクを、第２のＣＰＵコアに切り替えて実行する際、 前記タスクを第２のＣＰＵコアに試験実行させる試験実行指示手段と、
    第１のＣＰＵコアの実行結果と第２のＣＰＵコアの実行結果が一致したか否かを判定する判定手段と、
    第１のＣＰＵコアの実行結果と第２のＣＰＵコアの実行結果が一致すると判定された場合、前記タスクの割り当て先を第２のＣＰＵコアに確定する割り当て確定手段と、
    を有することを特徴とするマルチコアシステム。
  2. 前記試験実行指示手段は、前記タスクを二以上の第２のＣＰＵコアに試験実行させ、
    前記判定手段は、第１のＣＰＵコアの実行結果と二以上の第２のＣＰＵコアの実行結果をそれぞれ比較し、
    前記割り当て確定手段は、二以上の第２のＣＰＵコアのうち、最も早く第１のＣＰＵコアの実行結果と一致したＣＰＵコアに、前記タスクの割り当て先を確定する、
    ことを特徴とする請求項１記載のマルチコアシステム。
  3. 第１のＣＰＵコアの処理負荷及び処理負荷の増加率を検出する処理負荷検出手段を有し、
    前記処理負荷検出手段により、第１のＣＰＵコアの処理負荷が第１の閾値よりも高負荷になったことが検出された場合、又は、第１のＣＰＵコアの処理負荷の前記増加率が第３の閾値よりも大きくなったため高負荷になることが予測された場合、
    前記試験実行指示手段は、前記タスクを第２のＣＰＵコアに試験実行させる、
    ことを特徴とする請求項１又は２記載のマルチコアシステム。
  4. 第２のＣＰＵコアがタスクを実行していない場合、
    前記試験実行指示手段は、第１のＣＰＵコアが実行している前記タスクを第２のＣＰＵに試験実行させる、
    ことを特徴とする請求項１又は２記載のマルチコアシステム。
  5. 第１及び第２のＣＰＵコアの処理負荷及び処理負荷の増加率を検出する処理負荷検出手段を有し、
    前記処理負荷検出手段により、第１のＣＰＵコアの処理負荷と第２のＣＰＵコアの処理負荷の差が第４の閾値より大きくなったため処理負荷に偏りが生じたことが検出された場合、又は、第１のＣＰＵコアの処理負荷の前記増加率と第２のＣＰＵコアの処理負荷の前記増加率との差が第５の閾値より大きくなったため処理負荷に偏りが生じることが予測された場合、
    前記試験実行指示手段は、処理負荷が高い又は高くなることが予想される第１又は第２のＣＰＵコアが実行する前記タスクを、処理負荷が低い又は低くなることが予想される第１のＣＰＵコア又は第２のＣＰＵコアに試験実行させる、
    ことを特徴とする請求項１又は２記載のマルチコアシステム。
  6. 前記判定手段は、第１のＣＰＵコアの実行結果の値と第２のＣＰＵコアの実行結果の値の差が、所定範囲内であれば一致したと判定する、
    ことを特徴とする請求項１又は２記載のマルチコアシステム。
  7. 前記差は、前記タスクに応じて予め定められている、ことを特徴とする請求項６記載のマルチコアシステム。
  8. 前記判定手段が、第１のＣＰＵコア及び第２のＣＰＵコアによる前記タスクの実行結果が一致しない場合と判定した場合、前記試験実行指示手段は予め定められた待機時間の範囲内で前記タスクを第２のＣＰＵコアに試験実行させることを継続し、
    前記待機時間まで第２のＣＰＵコアが前記タスクを試験実行しても、第１のＣＰＵコア及び第２のＣＰＵコアによる前記タスクの実行結果が一致しない場合、前記試験実行指示手段は、前記判定手段が一致判定した前記タスクとは別のタスクを第２のＣＰＵに試験実行させ、
    第１のＣＰＵコア及び第２のＣＰＵコアによる前記別のタスクの実行結果が一致しない場合、前記試験実行指示手段は予め定められた前記待機時間の範囲内で前記別のタスクを第２のＣＰＵコアに試験実行させることを継続し、
    タスクが試験実行されている間に、試験実行中のタスクよりも優先度の高いタスクが生成された場合、前記試験実行指示手段は第１のＣＰＵコア及び第２のＣＰＵコアによるタスクの試験実行を終了する、
    ことを特徴とする請求項１又は２記載のマルチコアシステム。
  9. 優先的に割り当てるＣＰＵコアを前記タスクに対応づけて登録した優先テーブルを有し、
    前記試験実行指示手段は、前記優先テーブルを参照して前記タスクを試験実行させるＣＰＵコアを決定する、
    ことを特徴とする請求項１記載のマルチコアシステム。
  10. 前記試験実行指示手段が第２のＣＰＵコアに試験実行させるタスクは、
    前記処理負荷検出手段が、第１のＣＰＵコアの処理負荷が第１の閾値よりも高負荷となったことを検出した時若しくは高負荷になることを予測した時に、第１のＣＰＵコアが実行しているタスクである、
    ことを特徴とする請求項３記載のマルチコアシステム。
  11. 第１のＣＰＵコア及び第２のＣＰＵコアの実行結果が一致した場合、
    第２のＣＰＵコアは、タスクの実行結果を制御対象に出力する、
    ことを特徴とする請求項１０記載のマルチコアシステム。
  12. 前記処理負荷検出手段は、所定時間に対する前記タスクの実行時間の割合であるＣＰＵコア使用率が閾値ＴＲ１より大、又は、待機しているタスクの数が閾値ＴＮ１より大、の少なくともいずれかを満たす場合に、第１のＣＰＵコアの処理負荷が第１の閾値よりも高負荷であることを検出し、
    ＣＰＵコア使用率の増加率が閾値ＴｄＲ１より大、又は、待機しているタスクの数の増加率が閾値ＴｄＮ１よりも大、の少なくともいずれかを満たす場合に、第１のＣＰＵコアの処理負荷が高負荷になることを予測する、
    ことを特徴とする請求項３記載のマルチコアシステム。
  13. 前記処理負荷検出手段は、エンジン回転数又は車速が閾値ＴＳより大の場合に、第１のＣＰＵコアの処理負荷が閾値よりも高負荷であることを検出し、
    エンジン回転数又は車速の増加率が閾値ＴｄＳより大の場合に、第１のＣＰＵコアの処理負荷が高負荷になることを予測する、
    ことを特徴とする請求項３記載のマルチコアシステム。
  14. 前記処理負荷検出手段は、
    所定時間に対する前記タスクの実行時間の割合である第１のＣＰＵコアのＣＰＵコア使用率と第２のＣＰＵコアのＣＰＵコア使用率の差が閾値ＴＲ１２より大、又は、第１のＣＰＵコアによる実行を待機しているタスクの数と第２のＣＰＵコアによる実行を待機しているタスクの数の差が、閾値ＴＮ１２より大、の少なくともいずれかを満たす場合に、第１のＣＰＵコアと第２のＣＰＵコアの処理負荷の偏りを検出し、
    第１のＣＰＵコアのＣＰＵコア使用率と第２のＣＰＵコアのＣＰＵコア使用率との差の増加率が閾値ＴｄＲ１２より大、又は、第１のＣＰＵコアによる実行を待機しているタスクの数と第２のＣＰＵコアによる実行を待機しているタスクの数の差の増加率が閾値ＴｄＮ１２より大、の少なくともいずれかを満たす場合に、第１のＣＰＵコアと第２のＣＰＵコアの処理負荷に偏りが生じることを予測する、ことを特徴とする請求項５記載のマルチコアシステム。
  15. 第１及び第２のＣＰＵコアの処理負荷を検出する処理負荷検出手段を有し、
    前記処理負荷検出手段が、第２のＣＰＵコアの処理負荷が第２の閾値よりも低いことを検出した場合、
    前記試験実行指示手段は、第２のＣＰＵコアが実行する前記タスクを、第１のＣＰＵコアに試験実行させ、
    前記判定手段は、第１のＣＰＵコアと第２のＣＰＵコアの実行結果が一致したか否かを判定し、
    前記判定手段が一致すると判定した場合、前記タスクを実行するＣＰＵコアを第２のＣＰＵコアから第１のＣＰＵコアに切り替え、第２のＣＰＵコアを停止させる、
    ことを特徴とする請求項１記載のマルチコアシステム。
  16. 当該マルチコアシステムは前記制御系のプログラムを実行することで、
    同一のハードウェアをフィードバック制御するためのタスクであって、過去の実行結果により決定された制御量を用いて前記ハードウェアの次回の制御量を決定するタスクを生成する、
    ことを特徴とする請求項１記載のマルチコアシステム。
  17. 請求項１〜１６いずれか１項記載のマルチコアシステムと、
    前記制御系のプログラムを記憶した記憶手段と、
    アクチュエータと接続されるインターフェイスと、
    を有することを特徴とする車両用電子制御ユニット。
  18. 制御系のプログラムをマルチコアシステムが実行して生成したタスクを、ＣＰＵコアに割り当てて実行するマルチコアシステムのタスク切り替え方法であって、
    第１のＣＰＵコアが実行する前記タスクを、第２のＣＰＵコアに切り替えて実行する際、試験実行指示手段が、前記タスクを第２のＣＰＵコアに試験実行させるステップと、
    判定手段が、第１のＣＰＵコアの実行結果と第２のＣＰＵコアの実行結果が一致したか否かを判定するステップと、
    第１のＣＰＵコアの実行結果と第２のＣＰＵコアの実行結果が一致すると判定された場合、割り当て確定手段が、前記タスクの割り当て先を第２のＣＰＵコアに確定するステップと、を有することを特徴とするタスク切り替え方法。
JP2010521618A 2008-07-22 2009-02-23 マルチコアシステム、車両用電子制御ユニット、タスク切り替え方法 Expired - Fee Related JP5195913B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010521618A JP5195913B2 (ja) 2008-07-22 2009-02-23 マルチコアシステム、車両用電子制御ユニット、タスク切り替え方法

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2008188830 2008-07-22
JP2008188830 2008-07-22
PCT/JP2009/053200 WO2010010723A1 (ja) 2008-07-22 2009-02-23 マルチコアシステム、車両用電子制御ユニット、タスク切り替え方法
JP2010521618A JP5195913B2 (ja) 2008-07-22 2009-02-23 マルチコアシステム、車両用電子制御ユニット、タスク切り替え方法

Publications (2)

Publication Number Publication Date
JPWO2010010723A1 JPWO2010010723A1 (ja) 2012-01-05
JP5195913B2 true JP5195913B2 (ja) 2013-05-15

Family

ID=41570191

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010521618A Expired - Fee Related JP5195913B2 (ja) 2008-07-22 2009-02-23 マルチコアシステム、車両用電子制御ユニット、タスク切り替え方法

Country Status (4)

Country Link
US (1) US8856196B2 (ja)
JP (1) JP5195913B2 (ja)
DE (1) DE112009001700B4 (ja)
WO (1) WO2010010723A1 (ja)

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8293548B2 (en) * 2009-03-04 2012-10-23 Unilumin Group Co., Ltd. LED light module for street lamp and method of manufacturing same
JP4901915B2 (ja) * 2009-06-18 2012-03-21 株式会社東芝 映像処理装置、処理ユニット及びｉｐアドレス管理方法
JP5515810B2 (ja) 2010-02-05 2014-06-11 日本電気株式会社 負荷制御装置
EP2369477B1 (en) * 2010-02-22 2017-10-11 Telefonaktiebolaget LM Ericsson (publ) Technique for providing task priority related information intended for task scheduling in a system
US20130061098A1 (en) * 2010-05-10 2013-03-07 Toyoya Jidosha Kabushiki Kaisha Failure check apparatus and failure check method
US9152523B2 (en) * 2010-09-15 2015-10-06 Qualcomm Incorporated Batching and forking resource requests in a portable computing device
US9098521B2 (en) * 2010-09-15 2015-08-04 Qualcomm Incorporated System and method for managing resources and threshsold events of a multicore portable computing device
DE102011086530A1 (de) * 2010-11-19 2012-05-24 Continental Teves Ag & Co. Ohg Mikroprozessorsystem mit fehlertoleranter Architektur
JPWO2012098683A1 (ja) * 2011-01-21 2014-06-09 富士通株式会社 スケジューリング方法およびスケジューリングシステム
WO2012098684A1 (ja) 2011-01-21 2012-07-26 富士通株式会社 スケジューリング方法およびスケジューリングシステム
CN103339604B (zh) * 2011-01-31 2016-10-26 株式会社索思未来 程序生成装置、程序生成方法、处理器装置以及多处理器***
JPWO2012137238A1 (ja) * 2011-04-04 2014-07-28 株式会社日立製作所 計算機システム
DE102011105617A1 (de) * 2011-06-28 2013-01-03 Audi Ag Kraftfahrzeug mit einer Vielzahl von Betriebskomponenten
JP5341957B2 (ja) * 2011-07-20 2013-11-13 トヨタ自動車株式会社 内燃機関の制御装置
JP5760846B2 (ja) * 2011-08-22 2015-08-12 トヨタ自動車株式会社 内燃機関の制御装置
JP2014066165A (ja) * 2012-09-25 2014-04-17 Toyota Motor Corp エンジン制御装置
US9507500B2 (en) * 2012-10-05 2016-11-29 Tactual Labs Co. Hybrid systems and methods for low-latency user input processing and feedback
US9608876B2 (en) 2014-01-06 2017-03-28 Microsoft Technology Licensing, Llc Dynamically adjusting brand and platform interface elements
US9501808B2 (en) * 2014-01-06 2016-11-22 Microsoft Technology Licensing, Llc Division of processing between systems based on business constraints
US9483811B2 (en) 2014-01-06 2016-11-01 Microsoft Technology Licensing, Llc Division of processing between systems based on external factors
US9785481B2 (en) * 2014-07-24 2017-10-10 Qualcomm Innovation Center, Inc. Power aware task scheduling on multi-processor systems
JP6152228B2 (ja) * 2014-09-12 2017-06-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 電子制御ユニット、車載ネットワークシステム及び車両用通信方法
US10089197B2 (en) * 2014-12-16 2018-10-02 Intel Corporation Leverage offload programming model for local checkpoints
JP6879625B2 (ja) * 2016-12-27 2021-06-02 東芝インフラシステムズ株式会社 プログラマブルコントローラ、管理装置および制御システム
KR102309429B1 (ko) * 2017-03-20 2021-10-07 현대자동차주식회사 차량 및 그 제어 방법
JP6617744B2 (ja) * 2017-04-05 2019-12-11 トヨタ自動車株式会社 車両システム
US10606714B2 (en) 2017-09-05 2020-03-31 International Business Machines Corporation Stopping central processing units for data collection based on event categories of events
US10740030B2 (en) 2017-09-06 2020-08-11 International Business Machines Corporation Stopping a plurality of central processing units for data collection based on attributes of tasks
DE102017217016A1 (de) * 2017-09-26 2019-03-28 Robert Bosch Gmbh Verteilvorrichtung und Verfahren zum Verteilen von Datenströmen für ein Steuergerät für ein hochautomatisiert fahrbares Fahrzeug
JP2019074851A (ja) * 2017-10-13 2019-05-16 株式会社デンソー 電子制御装置
JP6902992B2 (ja) * 2017-12-19 2021-07-14 日立Astemo株式会社 自動車用電子制御装置
US20190243698A1 (en) * 2018-02-02 2019-08-08 Robert Bosch Gmbh Electronic Control Unit for Flexible Replacement of Replaceable Components in a Vehicle
DE112018007744T5 (de) * 2018-07-19 2021-04-08 Mitsubishi Electric Corporation Bildschirmerzeugungsvorrichtung und Bildschirmerzeugungsverfahren
JP7342669B2 (ja) * 2019-12-04 2023-09-12 株式会社デンソー 電子制御装置
JP2021124902A (ja) * 2020-02-04 2021-08-30 トヨタ自動車株式会社 車両制御装置、車両制御方法、及び車両制御プログラム
TWI756974B (zh) 2020-12-09 2022-03-01 財團法人工業技術研究院 機器學習系統及其資源配置方法
CN114257549B (zh) * 2021-12-21 2023-01-10 北京锐安科技有限公司 一种流量的转发方法、装置、设备及存储介质
US20230341921A1 (en) * 2022-04-26 2023-10-26 Western Digital Technologies, Inc. Data Storage With Real Time Dynamic Clock Frequency Control

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005031736A (ja) * 2003-07-07 2005-02-03 Hitachi Information Systems Ltd サーバ負荷分散装置及びサーバ負荷分散方法及びクライアントサーバシステム
JP2006133995A (ja) * 2004-11-04 2006-05-25 Toshiba Corp プロセッサシステム及びその制御方法
JP2006185152A (ja) * 2004-12-27 2006-07-13 Hitachi Ltd アプリケーション運用制御方法およびシステム
WO2007037006A1 (ja) * 2005-09-29 2007-04-05 Fujitsu Limited マルチコアプロセッサ

Family Cites Families (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4356546A (en) * 1980-02-05 1982-10-26 The Bendix Corporation Fault-tolerant multi-computer system
US5694603A (en) * 1982-09-28 1997-12-02 Reiffin; Martin G. Computer memory product with preemptive multithreading software
US5168566A (en) * 1983-11-25 1992-12-01 Sharp Kabushiki Kaisha Multi-task control device for central processor task execution control provided as a peripheral device and capable of prioritizing and timesharing the tasks
JPH0778785B2 (ja) * 1986-03-29 1995-08-23 株式会社東芝 プロセッサ選択方法
JPS6345670A (ja) * 1986-08-13 1988-02-26 Hitachi Ltd プロセツサ間同期装置
US4914570A (en) * 1986-09-15 1990-04-03 Counterpoint Computers, Inc. Process distribution and sharing system for multiple processor computer system
US4807228A (en) * 1987-03-18 1989-02-21 American Telephone And Telegraph Company, At&T Bell Laboratories Method of spare capacity use for fault detection in a multiprocessor system
US5404521A (en) * 1990-07-31 1995-04-04 Top Level Inc. Opportunistic task threading in a shared-memory, multi-processor computer system
CA2067576C (en) * 1991-07-10 1998-04-14 Jimmie D. Edrington Dynamic load balancing for a multiprocessor pipeline
JPH05265975A (ja) * 1992-03-16 1993-10-15 Hitachi Ltd 並列計算処理装置
US5287508A (en) * 1992-04-07 1994-02-15 Sun Microsystems, Inc. Method and apparatus for efficient scheduling in a multiprocessor system
JPH0830471A (ja) * 1994-07-14 1996-02-02 Hitachi Ltd ジョブの実行プロセサ変更方式
US5956482A (en) * 1996-05-15 1999-09-21 At&T Corp Multimedia information service access
US5889989A (en) * 1996-09-16 1999-03-30 The Research Foundation Of State University Of New York Load sharing controller for optimizing monetary cost
JPH10143380A (ja) 1996-11-07 1998-05-29 Hitachi Ltd マルチプロセッサシステム
US5903717A (en) * 1997-04-02 1999-05-11 General Dynamics Information Systems, Inc. Fault tolerant computer system
JPH11261702A (ja) * 1998-03-06 1999-09-24 Fujitsu Ltd 負荷予測によるシステム最適化制御装置
US6182085B1 (en) * 1998-05-28 2001-01-30 International Business Machines Corporation Collaborative team crawling:Large scale information gathering over the internet
US6952827B1 (en) * 1998-11-13 2005-10-04 Cray Inc. User program and operating system interface in a multithreaded environment
US6230313B1 (en) * 1998-12-23 2001-05-08 Cray Inc. Parallelism performance analysis based on execution trace information
JP4137264B2 (ja) * 1999-01-05 2008-08-20 株式会社日立製作所 データベース負荷分散処理方法及びその実施装置
US6647408B1 (en) * 1999-07-16 2003-11-11 Novell, Inc. Task distribution
US6625725B1 (en) * 1999-12-22 2003-09-23 Intel Corporation Speculative reuse of code regions
US20020032754A1 (en) * 2000-04-05 2002-03-14 Gary Logston Method and apparatus for profiling in a distributed application environment
JP4475614B2 (ja) * 2000-04-28 2010-06-09 大正製薬株式会社 並列処理方法におけるジョブの割り当て方法および並列処理方法
JP2002215599A (ja) * 2001-01-18 2002-08-02 Mitsubishi Electric Corp マルチプロセッサシステムおよびその制御方法
US20030005380A1 (en) * 2001-06-29 2003-01-02 Nguyen Hang T. Method and apparatus for testing multi-core processors
JP3632635B2 (ja) * 2001-07-18 2005-03-23 日本電気株式会社 マルチスレッド実行方法及び並列プロセッサシステム
US6931576B2 (en) * 2002-01-07 2005-08-16 Sun Microsystems, Inc. Data integrity device providing heightened error protection in a data processing system
US7249358B2 (en) * 2003-01-07 2007-07-24 International Business Machines Corporation Method and apparatus for dynamically allocating processors
JP3970786B2 (ja) * 2003-03-05 2007-09-05 株式会社日立製作所 マルチプロセッサシステム
US7093147B2 (en) * 2003-04-25 2006-08-15 Hewlett-Packard Development Company, L.P. Dynamically selecting processor cores for overall power efficiency
US7594228B2 (en) * 2003-09-23 2009-09-22 Lam Siu H Method and apparatus to perform task scheduling
EP1679595A4 (en) * 2003-10-29 2008-06-04 Ibm INFORMATION SYSTEM, LOAD CONTROL METHOD AND PROGRAM, AND RECORDING MEDIUM
US20080246772A1 (en) * 2003-11-19 2008-10-09 Lucid Information Technology, Ltd. Multi-mode parallel graphics rendering system (MMPGRS) employing multiple graphics processing pipelines (GPPLS) and real-time performance data collection and analysis during the automatic control of the mode of parallel operation of said GPPLS
US7961194B2 (en) * 2003-11-19 2011-06-14 Lucid Information Technology, Ltd. Method of controlling in real time the switching of modes of parallel operation of a multi-mode parallel graphics processing subsystem embodied within a host computing system
US20050137928A1 (en) * 2003-12-19 2005-06-23 Juergen Scholl Process management monitoring
JP2005190038A (ja) * 2003-12-25 2005-07-14 Hitachi Ltd プロセッサの診断処理方法および診断処理プログラム
JP2006031358A (ja) * 2004-07-15 2006-02-02 Ziosoft Inc ボリュームレンダリング等の画像処理システム
JP4410661B2 (ja) * 2004-11-09 2010-02-03 株式会社日立製作所 分散制御システム
GB0507150D0 (en) * 2005-04-08 2005-05-18 Ibm A method or apparatus for running a test program in a computer system
DE102005037246A1 (de) 2005-08-08 2007-02-15 Robert Bosch Gmbh Verfahren und Vorrichtung zur Steuerung eines Rechnersystems mit wenigstens zwei Ausführungseinheiten und einer Vergleichseinheit
US7610425B2 (en) * 2005-08-22 2009-10-27 Sun Microsystems, Inc. Approach for managing interrupt load distribution
US7412353B2 (en) * 2005-09-28 2008-08-12 Intel Corporation Reliable computing with a many-core processor
JP2007188212A (ja) 2006-01-12 2007-07-26 Seiko Epson Corp マルチプロセッサ及びマルチプロセッサの制御方法をコンピュータに実行させるためのプログラム
US20070288734A1 (en) * 2006-06-08 2007-12-13 Luick David A Double-Width Instruction Queue for Instruction Execution
US20080091974A1 (en) * 2006-10-11 2008-04-17 Denso Corporation Device for controlling a multi-core CPU for mobile body, and operating system for the same
US8032888B2 (en) * 2006-10-17 2011-10-04 Oracle America, Inc. Method and system for scheduling a thread in a multiprocessor system
JP2008102778A (ja) * 2006-10-19 2008-05-01 Fujitsu Ltd 情報処理装置、情報処理装置の制御方法及びプログラム
JP2008188830A (ja) 2007-02-02 2008-08-21 Dic Corp プロセス印刷方法及び印刷データ作成装置
FR2912526B1 (fr) * 2007-02-13 2009-04-17 Thales Sa Procede de maintien du synchronisme d'execution entre plusieurs processeurs asynchrones fonctionnant en parallele de maniere redondante.
US20090064166A1 (en) * 2007-08-28 2009-03-05 Arimilli Lakshminarayana B System and Method for Hardware Based Dynamic Load Balancing of Message Passing Interface Tasks
JP4872944B2 (ja) * 2008-02-25 2012-02-08 日本電気株式会社 運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラム
US8037350B1 (en) * 2008-04-30 2011-10-11 Hewlett-Packard Development Company, L.P. Altering a degree of redundancy used during execution of an application
US8904003B2 (en) * 2008-06-30 2014-12-02 Oracle America, Inc. Method and system for delegated job control across a network
US8429652B2 (en) * 2009-06-22 2013-04-23 Citrix Systems, Inc. Systems and methods for spillover in a multi-core system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005031736A (ja) * 2003-07-07 2005-02-03 Hitachi Information Systems Ltd サーバ負荷分散装置及びサーバ負荷分散方法及びクライアントサーバシステム
JP2006133995A (ja) * 2004-11-04 2006-05-25 Toshiba Corp プロセッサシステム及びその制御方法
JP2006185152A (ja) * 2004-12-27 2006-07-13 Hitachi Ltd アプリケーション運用制御方法およびシステム
WO2007037006A1 (ja) * 2005-09-29 2007-04-05 Fujitsu Limited マルチコアプロセッサ

Also Published As

Publication number Publication date
DE112009001700T5 (de) 2011-06-01
DE112009001700B4 (de) 2019-02-07
US8856196B2 (en) 2014-10-07
WO2010010723A1 (ja) 2010-01-28
US20100262971A1 (en) 2010-10-14
JPWO2010010723A1 (ja) 2012-01-05

Similar Documents

Publication Publication Date Title
JP5195913B2 (ja) マルチコアシステム、車両用電子制御ユニット、タスク切り替え方法
US6675191B1 (en) Method of starting execution of threads simultaneously at a plurality of processors and device therefor
US9164799B2 (en) Multiprocessor system
US20100049960A1 (en) Operating system startup control method and information processing apparatus
JP2009541636A (ja) 内燃機関のエンジン制御部の機能を監視するための方法および装置
US20090059951A1 (en) Program control device
JP2012128788A (ja) 車両制御装置、データ通信方法
JP2011141782A (ja) 情報処理装置、電子制御ユニット、タスク割り当て方法
CN111791886B (zh) 用于车辆的实时控制***以及经由实时控制***执行车辆控制的方法
JP2005276097A (ja) 割り込み依頼プログラムおよびマイクロコンピュータ
JP4908587B2 (ja) 複数の実行ユニットを有するシステムを切り替える方法
Becker et al. Investigation on AUTOSAR-compliant solutions for many-core architectures
JP2014191655A (ja) マルチプロセッサ、電子制御装置、プログラム
Li et al. Multi-mode virtualization for soft real-time systems
US20050160425A1 (en) Limitation of the response time of a software process
US20080184258A1 (en) Data processing system
CN105474174B (zh) 控制时间密集的指令
US8555285B2 (en) Executing a general-purpose operating system as a task under the control of a real-time operating system
JP5699896B2 (ja) 情報処理装置、異常判定方法
JP7271973B2 (ja) 車両制御装置、動作クロック切換方法
WO2022137651A1 (ja) 車両制御装置
WO2019044226A1 (ja) アクセス制御装置
JPH0926888A (ja) 排他制御装置
US20090217279A1 (en) Method and Device for Controlling a Computer System
JP7421634B2 (ja) 制御装置及び方法

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120703

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120824

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121009

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121203

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130108

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130121

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160215

Year of fee payment: 3

R151 Written notification of patent or utility model registration

Ref document number: 5195913

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160215

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees