マルチコアシステム
【課題】高いセキュリティ性を維持しつつメモリ保護領域への各コアのアクセス権限を動的に変化させることを可能とする。
【解決手段】マルチコアシステムは、メモリの保護領域に対する各コアのアクセス権限に関する情報を保持するアクセス設定情報部と、アクセス設定情報部で保持されるアクセス設定情報に応じて各コアによるメモリの保護領域へのアクセスを制限又は許可するメモリ保護部と、アクセス設定情報部にて保持されるアクセス設定情報を変更する保護管理部と、所与の識別情報を保持する不変情報保持部とを備え、アクセス設定情報部は、保護管理部からの識別情報が不変情報保持部内の所与の識別情報と対応した場合に、アクセス設定情報への保護管理部のアクセスを許可し、保護管理部からの識別情報が所与の識別情報と対応しなかった場合に、アクセス設定情報への保護管理部のアクセスを制限する。
【解決手段】マルチコアシステムは、メモリの保護領域に対する各コアのアクセス権限に関する情報を保持するアクセス設定情報部と、アクセス設定情報部で保持されるアクセス設定情報に応じて各コアによるメモリの保護領域へのアクセスを制限又は許可するメモリ保護部と、アクセス設定情報部にて保持されるアクセス設定情報を変更する保護管理部と、所与の識別情報を保持する不変情報保持部とを備え、アクセス設定情報部は、保護管理部からの識別情報が不変情報保持部内の所与の識別情報と対応した場合に、アクセス設定情報への保護管理部のアクセスを許可し、保護管理部からの識別情報が所与の識別情報と対応しなかった場合に、アクセス設定情報への保護管理部のアクセスを制限する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、種類の異なる２つ以上のソフトウェアを実行する複数のコアと、前記複数のコアにより共有されるメモリとを備えるマルチコアシステムに関する。
【背景技術】
【０００２】
従来から、プロセッサと、書込み読出し可能メモリ間に、書込み禁止領域のアドレス設定及び書込み禁止を設定すると、アドレスバスにて該プロセッサよりのメモリアドレスを監視し、書込み禁止のアドレスになったら、該プロセッサよりの書込み信号を書込み禁止信号とし、書込み禁止解除を設定すると、書込み禁止を解除するメモリ保護回路を設け、該メモリ保護回路に書込み禁止領域のアドレス設定及び書込み禁止，解除の設定を行うことにより、書込み読出し可能メモリに書込み禁止領域を設定し、設定された領域を禁止設定から解除設定迄の期間書込み禁止領域とすることを特徴とするメモリ保護方法が知られている（例えば、特許文献１参照）。
【特許文献１】特開平５−１１３９３３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上述の特許文献１に記載されるメモリ保護方法は、単一のプロセッサコアを用いるシステムに係る方法であり、また、メモリ保護領域を変更する際のセキュリティが考慮されていない。マルチコアシステムは、複数のコアにより複数の性質の異なるソフトウェアを実行する関係上、各コアに割り当てられるソフトウェアの性質が異なり、それに伴い各コアに対して、それぞれが実行するソフトウェアの性質に応じたメモリ領域を割り当てなければならず、単一のプロセッサコアを用いるシステムとは大きく異なる事情がある。また、セキュリティが考慮されない場合には、悪意のあるプログラム等によりメモリ保護領域が自由に変更されうるという問題がある。
【０００４】
そこで、本発明は、マルチコアシステムにおいて、高いセキュリティ性を維持しつつメモリ保護領域への各コアのアクセス権限を動的に変化させることを可能とすることを目的とする。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、第１の発明は、種類の異なる２つ以上のソフトウェアを実行する複数のコアと、前記複数のコアにより共有されるメモリとを備えるマルチコアシステムであって、
前記メモリの保護領域に対する各コアのアクセス権限に関する情報を保持するアクセス設定情報部と、
前記アクセス設定情報部で保持されるアクセス設定情報に応じて各コアによる前記メモリの保護領域へのアクセスを制限又は許可するメモリ保護部と、
前記アクセス設定情報部にて保持される前記アクセス設定情報を変更する保護管理部と、
所与の識別情報を保持する不変情報保持部とを備え、
前記アクセス設定情報部は、前記保護管理部からの識別情報が前記不変情報保持部内の所与の識別情報と対応した場合に、前記アクセス設定情報への前記保護管理部のアクセスを許可し、前記保護管理部からの識別情報が前記不変情報保持部内の所与の識別情報と対応しなかった場合に、前記アクセス設定情報への前記保護管理部のアクセスを制限することを特徴とする。
【０００６】
第２の発明は、第１の発明に係るマルチコアシステムにおいて、
前記２つ以上のソフトウェアは、第１のソフトウェアと、前記第１のソフトウェアよりも重要性の高い（要求される信頼性が高い）第２のソフトウェアとを含み、
前記保護管理部は、前記複数のコアのうちの特定のコアにより実行されるソフトウェアの種類が前記第１のソフトウェアから前記第２のソフトウェアに変更される際に、該特定のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更することを特徴とする。
【０００７】
第３の発明は、第１の発明に係るマルチコアシステムにおいて、
前記所与の識別情報は、ハードウェア回路上に実装されたＩＤ情報であって前記保護管理部に固有のＩＤ情報であることを特徴とする。
【０００８】
第４の発明は、第１の発明に係るマルチコアシステムにおいて、
前記不変情報保持部は、複数のコアのうち前記保護管理部を動作させるコアの優先順位を定める情報を更に保持することを特徴とする。
【０００９】
第５の発明は、第１の発明に係るマルチコアシステムにおいて、
前記２つ以上のソフトウェアは、車両制御に関する車両制御系ソフトウェアと、車両制御以外のマルチメディア系ソフトウェアとを含み、
前記複数のコアは、前記車両制御系ソフトウェアを常時実行する第１のコアと、前記マルチメディア系ソフトウェアを実行する第２のコアとを含み、
前記アクセス設定情報は、前記第１のコアによる前記メモリの保護領域へのアクセスを許可する情報を含む一方、前記第２のコアによる前記メモリの保護領域へのアクセスを制限する情報を含み、
前記保護管理部は、前記第２のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更することを特徴とする。
【００１０】
第６の発明は、第５の発明に係るマルチコアシステムにおいて、
前記第１のコアの状態を監視する状態監視部と、
前記状態監視部により前記第１のコアの高負荷状態若しくは不具合状態が検出された場合に、前記保護管理部に対して前記アクセス設定情報の変更を要求する負荷調整部とを更に備えることを特徴とする。
【００１１】
第７の発明は、第６の発明に係るマルチコアシステムにおいて、
前記負荷調整部は、前記保護管理部が、前記第２のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更するのに応じて、前記車両制御系ソフトウェアの少なくとも一部のタスクの担当を、前記第１のコアから前記第２のコアに変更することを特徴とする。
【００１２】
第８の発明は、第１の発明に係るマルチコアシステムにおいて、
前記保護管理部により前記アクセス設定情報が変更された際の状況を記憶する状況保存部を更に備えることを特徴とする。
【００１３】
第９の発明は、第６の発明に係るマルチコアシステムにおいて、
前記状態監視部は、前記状況保存部に記憶された状況が検出された場合に、前記保護管理部に対して前記アクセス設定情報の変更を要求することを特徴とする。
【００１４】
第１０の発明は、車載システムを構築するために用いられるマルチコアシステムを特徴とする。
【発明の効果】
【００１５】
本発明によれば、マルチコアシステムにおいて、高いセキュリティ性を維持しつつメモリ保護領域への各コアのアクセス権限を動的に変化させることが可能となる。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。
【実施例１】
【００１７】
図１は、本発明の実施例１によるマルチコアシステム１００の主要構成を示す図である。図１において、セクション１０２は、ソフトウェアにより実現される機能部を示し、セクション１０４は、ハードウェア構成を示す。
【００１８】
本実施例のマルチコアシステム１００は、ハードウェア構成として、複数のプロセッサコア（ＣＰＵ）と、動的メモリ保護制御部１０と、メモリ保護機構３０と、メインメモリ３２とを備える。図示のマルチコアシステム１００は、Ｎ個のプロセッサコア（コア１、コア２、コア３、・・・、コアＮ）を備える。コアの個数Ｎは、２以上の整数であれば任意である。複数のプロセッサコアは、後述の高信頼ＯＳのみを実行するコアと、原則として後述の通常ＯＳのみを実行するコアとに分類される。但し、原則として通常ＯＳのみを実行するコアは、後述の如く所定の場合に限り例外的に高信頼ＯＳを実行するようなコアを含む。
【００１９】
動的メモリ保護制御部１０は、アクセス設定情報部１１と、不変情報保持部１２とを備える。アクセス設定情報部１１は、メモリ保護範囲の情報を格納するアクセス設定情報領域であり、内部構成としては、図２に示すような設定レジスタと、図３に示すような設定テーブルからなる。設定レジスタは、マジックナンバーが書き込まれる特殊キーレジスタと、領域設定レジスタとを備える。領域設定レジスタに書き込まれた内容は、後述のマジックナンバーの照合が取れることを条件として、設定テーブルに反映される。設定テーブルには、例えば、図３に示すように、ＣＰＵ（コア）のＩＤ毎に、メインメモリ３２におけるアクセス可能領域が設定される。この設定テーブルのアクセス設定情報は、後述のメモリ保護範囲の動的な切替のためにメモリ保護機構３０により参照される。尚、セキュリティ担保の観点から、後述の保護管理部２３のみが設定レジスタのアドレス情報を保持し、後述の保護管理部２３しか設定レジスタにアクセスできないようにされる。
【００２０】
各コアのアクセス可能領域は、コア毎に異なってもよいし、一部若しくは全部が重複してもよい。但し、後述の高信頼ＯＳのみを実行するコアに係るアクセス可能領域は、原則として後述の通常ＯＳのみを実行するコアに係るアクセス可能領域に対して、少なくとも部分的に異なるように設定される。これは、高信頼ＯＳの実行が通常ＯＳの実行により阻害されないようにするためである。以下では、高信頼ＯＳのみを実行するコアのみがアクセス可能なメモリ領域を、「メモリ保護領域」ともいう。
【００２１】
図４は、アクセス設定情報部１１におけるアクセス設定情報（メモリ保護領域）を変更する際の処理フローの一例を示す。
【００２２】
ステップ００１では、保護管理部２３は、アクセス設定情報を変更しようとする際、アクセス設定情報部１１の特殊キーレジスタへ所与のマジックナンバーを書き込む。
【００２３】
ステップ００２では、アクセス設定情報部１１のハードウェア回路は、書き込まれたマジックナンバーが、ハードウェア回路上に実装されたキーと一致するか否かを判定する。また、即ち、保護管理部２３は、自身のＩＤ（マジックナンバー）をレジスタに書き込み、アクセス設定情報部１１のハードウェア回路は、保護管理部２３により書き込まれたＩＤが、不変情報保持部１２の不変情報（保護管理部２３を一意に識別するＩＤ情報）と一致するか否かを判定する。
【００２４】
ステップ００３では、書き込まれたマジックナンバーが、ハードウェア回路上に実装されたキーと一致する場合のみ、設定テーブルのロックを解除する。マジックナンバーがハードウェア回路上に実装されたキーと一致しない場合には、設定テーブルのロックを解除せず、アクセス設定情報変更処理はエラーとなる。
【００２５】
ステップ００４では、保護管理部２３は、領域設定レジスタに、どのＣＰＵが、どのメモリ領域へアクセス出来るかを表す設定値を書き込む。この書き込み内容は、ロックが解除されている設定テーブルのデータに反映される。即ち、設定テーブルのデータ（アクセス設定情報）は、保護管理部２３により書き込まれた内容に従って変更される。
【００２６】
ステップ００５では、アクセス設定情報の変更処理の完了後、設定テーブルをロックする。尚、再びアクセス設定情報の変更を行う場合には、ステップ００１からステップ００５の手順を繰り返す。
【００２７】
図１に戻る。不変情報保持部１２は、ソフトウェアによって変更が不可能な情報を保持する。即ち、不変情報保持部１２は、所定の情報（不変情報）が埋め込まれたハードウェア回路上の改変不能な領域である。不変情報保持部１２は、上述の如くアクセス設定情報の変更処理を可能としたことにより副次的に生じうるセキュリティホールの発生を防止すべく、設定される。具体的には、不変情報保持部１２に保持される不変情報は、保護管理部２３を一意に識別するＩＤ情報（上述のマジックナンバー）や、保護管理部２３を動作させるコア番号の優先順位等を含んでよい。これらの不変情報は、いずれも悪意あるプログラムやソフトウェア・バグによるアクセス設定情報部１１へのアクセスを防止するための情報である。保護管理部２３を動作させるコア番号の優先順位を含む理由としては、ハードウェア不具合等により、保護管理部２３の動作するコア自体が動作しなくなった場合にも、規定された優先順位に従って、次に優先順位の高いコア上で、保護管理部２３を新たに起動可能にするためである。
【００２８】
メモリ保護機構３０は、複数のコア１、コア２、コア３、・・・、コアＮのうちの任意のコアからのメインメモリ３２へのアクセス要求を受けると、アクセス設定情報部１１の設定テーブルのデータに従って、当該コアによるメインメモリ３２へのアクセス要求を制限／許可する。例えば、図３に示す設定テーブルのデータの場合に、コア２がメインメモリ３２のアドレス番号０ｘ４０００＿００００に書き込み要求を発したとき、アドレス番号０ｘ４０００＿００００はコア２にとってアクセス可能領域でないため、当該書き込み要求は制限される（却下される）。
【００２９】
メインメモリ３２は、複数のコア１、コア２、コア３、・・・、コアＮによって共有される主記憶装置であり、例えば、半導体素子を利用して電気的にデータを記憶する揮発性記憶装置である。メインメモリ３２は、複数のメモリから構成されてもよい。
【００３０】
本実施例のマルチコアシステム１００では、大きく分けて高信頼ＯＳと通常ＯＳの２種類のソフトウェアプログラムが複数のコア１、コア２、コア３、・・・、コアＮによって実行される。高信頼ＯＳは、要求される信頼性が高いソフトウェアであり、車両システムにおいては、車両制御に関連するソフトウェア（例えばＡＢＳや、追従走行制御システムや制動力制御システム等の車両制御系ソフトウェア）であってよい。他方、通常ＯＳは、要求される信頼性が高信頼ＯＳほど高くないソフトウェアであり、車両制御に直接的に関係しないソフトウェア、例えば利便性に関連するソフトウェア（例えば、ナビゲーションシステムや情報検索システム等のマルチメディア系ソフトウェア）であってよい。
【００３１】
高信頼ＯＳ及び通常ＯＳを実行するコアは、原則としてそれぞれ所定されているが、後述の如く、高信頼ＯＳ側で高負荷状態が検出された場合等の所定の場合には、アクセス設定情報が変更されることと協調して、通常ＯＳを実行するコアのうちの少なくとも１つのコアが、高信頼ＯＳを実行するように高信頼ＯＳ側に移譲されることになる。
【００３２】
マルチコアシステム１００は、その主要なソフトウェア機能部として、ＯＳ内処理管理部２０を備える。また、マルチコアシステム１００は、その他、複数ＯＳ制御やＯＳ間通信機能を備える。ＯＳ内処理管理部２０は、高信頼エリアで機能する負荷調整部２１及び状態モニタ部２２、並びに保護管理部２３を備えると共に、通常エリアで機能する負荷調整部２４及び状態モニタ部２５を備える。
【００３３】
負荷調整部２１は、上述のアクセス設定情報の変更に伴う各コア間の負荷を調整する部分である。負荷調整部２１は、状態モニタ部２２による負荷状態の監視結果の通知を受けて、負荷の調整が必要であるか否かの判断を行う。判断内容としては、例えば以下のようなロジックが考えられる。先ず、高信頼ＯＳ内で、タスク処理が可能か否かを判定する。これは、現在の負荷状態や、負荷状態の想定持続時間等に基づいて判断されてもよい。高信頼ＯＳ内で、タスク処理が可能であると判断した場合には、負荷の調整は不要と判断する。他方、高信頼ＯＳ内で、タスク処理が不能であると判断した場合には、高信頼ＯＳ側タスクのうち、タスクの優先度情報（既知の設定値）からサスペンド若しくは停止してもよいタスクを抽出し、当該抽出したタスクをサスペンド若しくは停止することで、高信頼ＯＳ内でタスク処理が可能となるか否かを判定する。抽出したタスクをサスペンド若しくは停止することで、高信頼ＯＳ内でタスク処理が可能と判断した場合には、負荷の調整は不要と判断する。他方、抽出したタスクをサスペンド若しくは停止しても、高信頼ＯＳ内でタスク処理が不能な高負荷状態であると判断した場合には、アクセス設定情報を変更して高信頼ＯＳの使用コアを増やす手順へと移行する。即ち、負荷調整部２１は、保護管理部２３に対してアクセス設定情報の変更の要求（高信頼ＯＳの使用コアの増加の要求）を行う。負荷調整部２１は、保護管理部２３から使用コアの増加を行った旨の通知を受けると、状態モニタ部２２による負荷状態の監視結果に基づいて、増加通知に係る新たなコアを含めて負荷調整を行い、上述の高信頼ＯＳ内でタスク処理が不能な状態を解消する。例えば、増加通知に係る新たなコアに対して、高信頼ＯＳ内の処理不能であったタスク処理を割り当てることで、上述の高信頼ＯＳ内でタスク処理が不能な状態を解消する。尚、この際、サスペンド若しくは停止するために抽出したタスクについても、増加した高信頼ＯＳ側のコアを用いて実行するようにしてもよい。
【００３４】
状態モニタ部２２は、高信頼ＯＳ内における各コアの負荷や不具合をモニタリングする部分である。状態モニタ部２２は、ＯＳの管理情報であるＣＰＵ負荷率や、メモリ使用率等の統計データを監視し、高負荷やハードウェア不具合状態が検出された場合に、その旨を負荷調整部２１に通知する。状態モニタ部２２は、例えば高信頼ＯＳを実行するコアのＣＰＵ使用率が７０％を超えた場合に、高負荷状態を検出することとしてもよい。また、状態モニタ部２２は、例えば高信頼ＯＳを実行するコアの不具合を表すアラームが発生した場合に、ハードウェア不具合状態を検出することとしてもよい。
【００３５】
保護管理部２３は、上述の如くアクセス設定情報の変更を行う主体となる部分であり、負荷調整部２１からの要求を受けて、アクセス情報設定部１１へアクセスを行う。また、通常ＯＳ側の負荷調整部２４との連携機能として、コア使用要求機能やコア移譲完了通知の受け取り機能を有する。これについては図５に示すシーケンスを参照されたい。
【００３６】
負荷調整部２４は、状態モニタ部２５による負荷状態の監視結果に基づいて、通常ＯＳ内で各コア間の負荷を調整する部分である。また、負荷調整部２４は、高信頼ＯＳ側へのコアの移譲を行うための調整が完了した際に、保護管理部２３にコア移譲完了通知を行う。
【００３７】
状態モニタ部２５は、通常ＯＳ側において各コアの負荷や不具合をモニタリングする部分である。
【００３８】
図５は、実施例１によるマルチコアシステム１００における高負荷状態発生時の処理シーケンスを示す図である。ここでは、一例として、マルチコアシステム１００は、４つのコア１、コア２、コア３及びコア４を含み、デフォルト設定として、コア１及びコア２が、通常時（即ち後述の高負荷状態発生等に伴うコアの移譲が行われない時）の高信頼ＯＳの使用コアとして設定されており、コア３及びコア４が、通常時の通常ＯＳの使用コアとして設定されているものとする。また、これに伴い、アクセス設定情報部１１の設定テーブルには、デフォルト設定として、コア１及びコア２のみがアクセス可能な領域（即ち、コア３及びコア４がアクセス不能なメモリ保護領域）が設定されているものとする。
【００３９】
図５を時系列で参照するに、先ず、高信頼ＯＳ側で高負荷状態が発生すると、状態モニタ部２２において、当該高負荷状態が検知される。例えば、図５のＣ部に示すように、コア１及び２により実行されるべきタスクがタスクＵ，Ｖ，Ｗ，Ｘ，Ｙ及びＺであり、タスクＵ及びＸが所定時間内に処理不能である場合に、高負荷状態が検知される。高負荷状態が検知されると、高信頼ＯＳ側の負荷調整部２１に通知され、負荷調整部２１において、上述の如く、高信頼ＯＳの使用コアを増やすべきか否かが判断される。高信頼ＯＳの使用コアを増やすべきと判断した場合には、その旨の要求（使用コア数変更依頼）が保護管理部２３に対して行われる。保護管理部２３は、この要求を受け付けて、通常ＯＳ側の負荷調整部２４に対して、通常ＯＳの使用コア（例えばコア３）の高信頼ＯＳでの使用要求を行う。通常ＯＳ側の負荷調整部２４は、この要求を受け付けて、通常ＯＳ側の状態モニタ部２５に対して、通常ＯＳ上の各タスクの動作情報を取得するように要求する。通常ＯＳ側の状態モニタ部２５は、この要求を受け付けて、通常ＯＳ上の各タスクの動作情報を取得し、負荷調整部２４に供給する。負荷調整部２４は、状態モニタ部２５から通常ＯＳ上の各タスクの動作情報を取得し、当該取得した情報を考慮して、タスク移動を実施する。例えば、通常ＯＳ側の負荷調整部２４は、図５のＡ部に示すように、コア３のタスクａ及びｂを、コア４に移動する。これにより、コア３が、高信頼ＯＳで使用可能な状態となる。ここで、通常ＯＳ側の使用コア数の削減に伴い、通常ＯＳ側の負荷状態によっては全てのタスクを移動できない可能性が考えられる。その場合には、タスクの優先度に従って移動させるタスク及び終了させるタスクを判断してもよい。タスク移動が完了すると、その旨の通知が（移動完了通知）が保護管理部２３に対してなされ、保護管理部２３は、この通知を受けて、アクセス設定情報を変更する。例えば、図５のＢ部に示すように、コア３のタスクの移動完了通知を受けた場合には、コア３がメモリ保護領域にアクセスできるように、アクセス設定情報部１１にアクセスして、メモリ保護領域に対するアクセス権限を、コア１〜２から、コア１〜３に変更する。このようにしてアクセス設定情報の変更を実施すると、保護管理部２３は、高信頼ＯＳ側の負荷調整部２１に、コア移譲完了通知として、使用可能なコアの増加を通知する。高信頼ＯＳ側の負荷調整部２１は、この通知を受けて、高信頼ＯＳ側の状態モニタ部２２に対して、高信頼ＯＳ上の各タスクの動作情報を取得するように要求する。高信頼ＯＳ側の状態モニタ部２２は、この要求を受け付けて、高信頼ＯＳ上の各タスクの動作情報を取得し、高信頼ＯＳ側の負荷調整部２１に供給する。高信頼ＯＳ側の負荷調整部２１は、状態モニタ部２２から高信頼ＯＳ上の各タスクの動作情報を取得し、当該取得した情報を考慮して、タスク移動を実施する。例えば、高信頼ＯＳ側の負荷調整部２１は、図５のＣ部に示すように、コア１及びコア２のタスクＵ及びＸを、新たなコア３に移動する。この場合、コア３は、メインメモリ３２のメモリ保護領域を用いて、高信頼ＯＳ側のタスクＵ及びＸを実行する。このようにして、高信頼ＯＳ側のコア１及び２が高負荷状態に陥って高信頼ＯＳのタスクＵ及びＸが処理不能となった場合にも、通常ＯＳ側のコア３を利用して、メインメモリ３２のメモリ保護領域で高信頼ＯＳのタスクＵ及びＸを実行することができる。
【００４０】
尚、図５に示した処理シーケンスにおいて、検知された高負荷状態が解消され、状態モニタ部２２の監視結果に基づいて、高信頼ＯＳ側のコア１及びコア２の負荷が所定レベル以下に低減した場合（通常負荷状態又は低負荷状態に戻った場合）、保護管理部２３は、アクセス設定情報部１１にアクセスして、メモリ保護領域に対するコアのアクセス権限を、コア１〜３から、コア１〜２に変更する（元に戻す）。或いは、図５に示した処理シーケンスにおいて、コア３がタスクＵ及びＸを実行し終えた段階で、保護管理部２３は、アクセス設定情報部１１にアクセスして、メモリ保護領域に対するコアのアクセス権限を、コア１〜３から、コア１〜２に変更することとしてもよい。
【００４１】
図６は、実施例１によるマルチコアシステム１００における不具合状態発生時の処理シーケンスを示す図である。図６の処理シーケンスは、上述の図５に示した処理シーケンスに対して、高信頼ＯＳ側で高負荷状態が検出されることに代えて、高信頼ＯＳ側でハードウェア不具合状態が検出されることをトリガとする点だけが異なる。
【００４２】
図６に示す処理シーケンスによれば、例えば図６のＣ部に示すように、高信頼ＯＳ側のコア２が動作不能となり、コア２のタスクＵ及びＸが処理不能となった場合にも、通常ＯＳ側のコア３を利用して、メインメモリ３２のメモリ保護領域で高信頼ＯＳのタスクＵ及びＸを実行することができる。
【００４３】
ところで、近年の車載システムにおいては、実現するサービスの多種多様化による処理性能の向上と、車載環境特有の熱対策等の要望から、上述のような複数のコア１〜Ｎを搭載したシステム（マルチコアシステム１００）が求められている。また、車両を制御する車両制御系ソフトウェアと、進化するマルチメディアサービスを実現するマルチメディア系ソフトウェアが同一のシステム上に搭載されることが要求されている。そのような車両制御系とマルチメディア系とが同居するシステムにおいては、システムの品質・信頼性を守るために、メモリ保護機能が必要不可欠となる。
【００４４】
この点、本実施例によれば、上述の如く、高信頼ＯＳ側のコアのみがアクセス可能なメモリ保護領域を設定することにより、高信頼ＯＳに係るシステムの品質・信頼性を守ることができる。
【００４５】
また、限られたＣＰＵリソースの観点からは、高信頼ＯＳに対して無制限にＣＰＵリソースを割り当てることはできない。従って、高信頼ＯＳを担当するコアが高負荷状態に陥って高信頼ＯＳのタスクが処理不能となる場合が生じうる。かかる場合に、一時的に通常ＯＳ側のコアを利用して、高信頼ＯＳを実行させることも可能ではある。しかしながら、高信頼ＯＳは高品質・信頼性を確保する必要があるが、単に通常ＯＳ側のコアに実行させるだけでは、通常ＯＳ側のコアのアクセス可能領域が不十分である等により、必要な高品質・信頼性を確保することができない場合がある。これは、高信頼ＯＳを担当するコアが高負荷状態に陥った場合だけでなく、高信頼ＯＳを担当するコアが機能不能な不具合状態に陥った場合も同様である。
【００４６】
この点、本実施例によれば、上述の如く、高信頼ＯＳを担当するコアが高負荷状態や不具合状態に陥った場合でも、通常ＯＳ側のコアがメモリ保護領域で高信頼ＯＳのタスクを実行することができるので、高信頼ＯＳに求められる必要な高品質・信頼性を確保しつつ、ＣＰＵリソースを効率的に利用することができる。これにより、車両制御系とマルチメディア系とを効果的に同居させることが可能な車載システムを構築することができる。
【００４７】
また、本実施例によれば、上述の如くアクセス設定情報部１１のアクセス設定情報の変更は、不変情報保持部１２で保持されるキーによる照合が確認された場合に限り実行可能となるので、高いセキュリティ性を維持することができる。また、不変情報保持部１２で保持されるキーは、ハードウェア回路に埋設された不変情報であり、ユーザには知られることのないキーであるため、高いセキュリティ性が維持される。また、不変情報保持部１２で保持されるキーは、ハードウェア回路に埋設された不変情報であり、悪意のあるソフトウェアにより書き換えられることが無いため、高いセキュリティ性が維持される。
【実施例２】
【００４８】
図７は、本発明の実施例２によるマルチコアシステム２００の主要構成を示す図である。図７において、セクション２０２は、ソフトウェアにより実現される機能部を示し、セクション１０４は、ハードウェア構成を示す。ハードウェア構成は、上述の実施例１と同様であってよく、詳細な説明を省略する。
【００４９】
本実施例のマルチコアシステム２００は、上述の実施例１に対して、ＯＳ内処理管理部２２’内に、状況保存部２６と、予測・学習部２７とを追加的に備える点が主に異なる。状況保存部２６は、高信頼エリア及び通常エリアの双方に設けられ、予測・学習部２７は高信頼エリアに設けられる。
【００５０】
状況保存部２６は、アクセス設定情報を変更した状況を格納する部分である。具体的には、状況保存部２６は、アクセス設定情報を変更する事象（例えば上述の高負荷状態）が発生したときのマルチコアシステム２００内の状況、例えば、アクセス設定情報を変更する事象の発生時刻や動作タスク、ＯＳ統計情報（コア、バス等の利用率）等を格納する。或いは、状況保存部２６は、アクセス設定情報を変更する事象が発生したときのマルチコアシステム２００外の状況、例えばアクセス設定情報を変更する事象が発生したときの車両の位置や車両の周囲環境（道路や気温）や車両の走行状態（速度や加速度等）等を格納してもよい。この場合、これらの情報は、車載センサ（車載カメラを含む）により検出された状況に基づいて生成されてもよい。
【００５１】
予測・学習部２７は、高信頼ＯＳ側及び通常ＯＳ側の双方の状況保存部２６に格納されたデータから、上述の如くアクセス設定情報が変更されるような高負荷やハードウェア不具合発生のパターンを分析する機能を備える。また、予測・学習部２７は、その分析した結果に基づいて、高負荷やハードウェア不具合発生が予測されるような前兆パターンの発生を検知したときに、その旨を保護管理部２３に通知する。尚、予測・学習部２７は、上述の如く高信頼エリアのみで動作する。
【００５２】
予測・学習部２７は、例えば、状況保存部２６に格納されたデータに基づいて、アクセス設定情報を変更する事象の発生時間別の偏り、動作アプリケーションによる偏り、ハードウェアの使用率による偏り、ハードウェア種別による不具合の偏りのようなパターンを解析・抽出する。
【００５３】
図８は、実施例２によるマルチコアシステム２００における高負荷／不具合状態発生時の処理シーケンスを示す図である。図８に示す処理シーケンスは、状況保存部２６及び予測・学習部２７による処理が追加されている点が、上述の図５等に示した処理シーケンスと主に異なる。
【００５４】
図８に示す処理シーケンスでは、高負荷／不具合状態が発生すると、その際の状況が状況保存部２６に格納され、予測・学習部２７において高負荷／不具合状態が発生する状況の条件が解析・抽出される．予測・学習部２７により高負荷／不具合状態が発生する状況の条件が解析されると、その条件がモニタ条件として追加され、状態モニタ部２２に通知される。状態モニタ部２２は、モニタ条件が通知されると、以後、高負荷／不具合状態の検知処理の他、モニタ条件に該当する状況が検知されたか否かの判断処理を行い、モニタ条件に該当する状況が検知した場合には、使用コア数変更依頼を保護管理部２３に対して行う。
【００５５】
例えば、図８のＣ部に示すように、コア１及び２により実行されるべきタスクがタスクＵ，Ｖ，Ｗ，Ｘ，Ｙ及びＺとなるような状況が予測された場合には、予め使用コア数変更依頼が保護管理部２３に通知され、コア３がメインメモリ３２のメモリ保護領域を用いて高信頼ＯＳ側のタスクＵ及びＸを実行できる状態が形成される。
【００５６】
このように本実施例２によれば、モニタ条件が追加されると、モニタ条件に該当する状況が検知した場合に、速やかに使用コア数変更依頼が保護管理部２３に出されるので、負荷調整部２１を介して使用コア数変更依頼が保護管理部２３に出される場合に比べて、対応時間を短縮することができる。即ち、高負荷／不具合状態が発生する前にアクセス設定情報を変更しておくことが可能となり、高負荷／不具合状態の発生時にも通常ＯＳ側のコアを利用して、メインメモリ３２のメモリ保護領域で高信頼ＯＳを実行することができる。かかる応答性の向上を実現する本実施例２は、迅速な応答性が要求される車載システムに好適である。
【００５７】
以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。
【００５８】
例えば、上述した実施例では、高負荷／不具合状態の発生時に、メモリ保護領域への通常ＯＳ側のコアのアクセス権限を変更することで、メモリ保護領域の実質的な変更を行っているが、それに加えて、高負荷／不具合状態の発生時に、メモリ保護領域自体を増大させてもよい。例えば、高負荷／不具合状態の発生時に、通常時に使用されていないメモリ領域や、通常時に通常ＯＳ側のコアにより使用されるメモリ領域を、メモリ保護領域として追加設定してもよい。後者の場合（高負荷／不具合状態の発生時に、通常時に通常ＯＳ側のコアによりアクセス可能なメモリ領域を、メモリ保護領域として追加する場合）、設定テーブルのアクセス設定情報を変更することで、当該追加されたメモリ保護領域に対しては、高信頼ＯＳ側のコア及び高信頼ＯＳ側に移譲されたコアのみがアクセス可能とされ、他の通常ＯＳ側のコアはアクセス不能とされる。
【図面の簡単な説明】
【００５９】
【図１】本発明の実施例１によるマルチコアシステム１００の主要構成を示す図である。
【図２】設定レジスタの一例を示す図である。
【図３】設定テーブルのデータの一例を示す図である。
【図４】アクセス設定情報部１１におけるアクセス設定情報（メモリ保護領域）を変更する際の処理フローの一例を示す図である。
【図５】実施例１によるマルチコアシステム１００における高負荷状態発生時の処理シーケンスを示す図である。
【図６】実施例１によるマルチコアシステム１００における不具合状態発生時の処理シーケンスを示す図である。
【図７】本発明の実施例２によるマルチコアシステム２００の主要構成を示す図である。
【図８】実施例２によるマルチコアシステム２００における高負荷／不具合状態発生時の処理シーケンスを示す図である。
【符号の説明】
【００６０】
１〜Ｎ コア
１０ 動的メモリ保護制御部
１１ アクセス設定情報部
１２ 不変情報保持部
２０ ＯＳ内処理管理部
２１ 負荷調整部
２２、２２’ 状態モニタ部
２３ 保護管理部
２４ 負荷調整部
２５ 状態モニタ部
２６ 状況保存部
２７ 予測・学習部
３０ メモリ保護機構
３２ メインメモリ
１００，２００ マルチコアシステム
１０２，２０２ ソフトウェアセクション
１０４ ハードウェアセクション
【技術分野】
【０００１】
本発明は、種類の異なる２つ以上のソフトウェアを実行する複数のコアと、前記複数のコアにより共有されるメモリとを備えるマルチコアシステムに関する。
【背景技術】
【０００２】
従来から、プロセッサと、書込み読出し可能メモリ間に、書込み禁止領域のアドレス設定及び書込み禁止を設定すると、アドレスバスにて該プロセッサよりのメモリアドレスを監視し、書込み禁止のアドレスになったら、該プロセッサよりの書込み信号を書込み禁止信号とし、書込み禁止解除を設定すると、書込み禁止を解除するメモリ保護回路を設け、該メモリ保護回路に書込み禁止領域のアドレス設定及び書込み禁止，解除の設定を行うことにより、書込み読出し可能メモリに書込み禁止領域を設定し、設定された領域を禁止設定から解除設定迄の期間書込み禁止領域とすることを特徴とするメモリ保護方法が知られている（例えば、特許文献１参照）。
【特許文献１】特開平５−１１３９３３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上述の特許文献１に記載されるメモリ保護方法は、単一のプロセッサコアを用いるシステムに係る方法であり、また、メモリ保護領域を変更する際のセキュリティが考慮されていない。マルチコアシステムは、複数のコアにより複数の性質の異なるソフトウェアを実行する関係上、各コアに割り当てられるソフトウェアの性質が異なり、それに伴い各コアに対して、それぞれが実行するソフトウェアの性質に応じたメモリ領域を割り当てなければならず、単一のプロセッサコアを用いるシステムとは大きく異なる事情がある。また、セキュリティが考慮されない場合には、悪意のあるプログラム等によりメモリ保護領域が自由に変更されうるという問題がある。
【０００４】
そこで、本発明は、マルチコアシステムにおいて、高いセキュリティ性を維持しつつメモリ保護領域への各コアのアクセス権限を動的に変化させることを可能とすることを目的とする。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、第１の発明は、種類の異なる２つ以上のソフトウェアを実行する複数のコアと、前記複数のコアにより共有されるメモリとを備えるマルチコアシステムであって、
前記メモリの保護領域に対する各コアのアクセス権限に関する情報を保持するアクセス設定情報部と、
前記アクセス設定情報部で保持されるアクセス設定情報に応じて各コアによる前記メモリの保護領域へのアクセスを制限又は許可するメモリ保護部と、
前記アクセス設定情報部にて保持される前記アクセス設定情報を変更する保護管理部と、
所与の識別情報を保持する不変情報保持部とを備え、
前記アクセス設定情報部は、前記保護管理部からの識別情報が前記不変情報保持部内の所与の識別情報と対応した場合に、前記アクセス設定情報への前記保護管理部のアクセスを許可し、前記保護管理部からの識別情報が前記不変情報保持部内の所与の識別情報と対応しなかった場合に、前記アクセス設定情報への前記保護管理部のアクセスを制限することを特徴とする。
【０００６】
第２の発明は、第１の発明に係るマルチコアシステムにおいて、
前記２つ以上のソフトウェアは、第１のソフトウェアと、前記第１のソフトウェアよりも重要性の高い（要求される信頼性が高い）第２のソフトウェアとを含み、
前記保護管理部は、前記複数のコアのうちの特定のコアにより実行されるソフトウェアの種類が前記第１のソフトウェアから前記第２のソフトウェアに変更される際に、該特定のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更することを特徴とする。
【０００７】
第３の発明は、第１の発明に係るマルチコアシステムにおいて、
前記所与の識別情報は、ハードウェア回路上に実装されたＩＤ情報であって前記保護管理部に固有のＩＤ情報であることを特徴とする。
【０００８】
第４の発明は、第１の発明に係るマルチコアシステムにおいて、
前記不変情報保持部は、複数のコアのうち前記保護管理部を動作させるコアの優先順位を定める情報を更に保持することを特徴とする。
【０００９】
第５の発明は、第１の発明に係るマルチコアシステムにおいて、
前記２つ以上のソフトウェアは、車両制御に関する車両制御系ソフトウェアと、車両制御以外のマルチメディア系ソフトウェアとを含み、
前記複数のコアは、前記車両制御系ソフトウェアを常時実行する第１のコアと、前記マルチメディア系ソフトウェアを実行する第２のコアとを含み、
前記アクセス設定情報は、前記第１のコアによる前記メモリの保護領域へのアクセスを許可する情報を含む一方、前記第２のコアによる前記メモリの保護領域へのアクセスを制限する情報を含み、
前記保護管理部は、前記第２のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更することを特徴とする。
【００１０】
第６の発明は、第５の発明に係るマルチコアシステムにおいて、
前記第１のコアの状態を監視する状態監視部と、
前記状態監視部により前記第１のコアの高負荷状態若しくは不具合状態が検出された場合に、前記保護管理部に対して前記アクセス設定情報の変更を要求する負荷調整部とを更に備えることを特徴とする。
【００１１】
第７の発明は、第６の発明に係るマルチコアシステムにおいて、
前記負荷調整部は、前記保護管理部が、前記第２のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更するのに応じて、前記車両制御系ソフトウェアの少なくとも一部のタスクの担当を、前記第１のコアから前記第２のコアに変更することを特徴とする。
【００１２】
第８の発明は、第１の発明に係るマルチコアシステムにおいて、
前記保護管理部により前記アクセス設定情報が変更された際の状況を記憶する状況保存部を更に備えることを特徴とする。
【００１３】
第９の発明は、第６の発明に係るマルチコアシステムにおいて、
前記状態監視部は、前記状況保存部に記憶された状況が検出された場合に、前記保護管理部に対して前記アクセス設定情報の変更を要求することを特徴とする。
【００１４】
第１０の発明は、車載システムを構築するために用いられるマルチコアシステムを特徴とする。
【発明の効果】
【００１５】
本発明によれば、マルチコアシステムにおいて、高いセキュリティ性を維持しつつメモリ保護領域への各コアのアクセス権限を動的に変化させることが可能となる。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。
【実施例１】
【００１７】
図１は、本発明の実施例１によるマルチコアシステム１００の主要構成を示す図である。図１において、セクション１０２は、ソフトウェアにより実現される機能部を示し、セクション１０４は、ハードウェア構成を示す。
【００１８】
本実施例のマルチコアシステム１００は、ハードウェア構成として、複数のプロセッサコア（ＣＰＵ）と、動的メモリ保護制御部１０と、メモリ保護機構３０と、メインメモリ３２とを備える。図示のマルチコアシステム１００は、Ｎ個のプロセッサコア（コア１、コア２、コア３、・・・、コアＮ）を備える。コアの個数Ｎは、２以上の整数であれば任意である。複数のプロセッサコアは、後述の高信頼ＯＳのみを実行するコアと、原則として後述の通常ＯＳのみを実行するコアとに分類される。但し、原則として通常ＯＳのみを実行するコアは、後述の如く所定の場合に限り例外的に高信頼ＯＳを実行するようなコアを含む。
【００１９】
動的メモリ保護制御部１０は、アクセス設定情報部１１と、不変情報保持部１２とを備える。アクセス設定情報部１１は、メモリ保護範囲の情報を格納するアクセス設定情報領域であり、内部構成としては、図２に示すような設定レジスタと、図３に示すような設定テーブルからなる。設定レジスタは、マジックナンバーが書き込まれる特殊キーレジスタと、領域設定レジスタとを備える。領域設定レジスタに書き込まれた内容は、後述のマジックナンバーの照合が取れることを条件として、設定テーブルに反映される。設定テーブルには、例えば、図３に示すように、ＣＰＵ（コア）のＩＤ毎に、メインメモリ３２におけるアクセス可能領域が設定される。この設定テーブルのアクセス設定情報は、後述のメモリ保護範囲の動的な切替のためにメモリ保護機構３０により参照される。尚、セキュリティ担保の観点から、後述の保護管理部２３のみが設定レジスタのアドレス情報を保持し、後述の保護管理部２３しか設定レジスタにアクセスできないようにされる。
【００２０】
各コアのアクセス可能領域は、コア毎に異なってもよいし、一部若しくは全部が重複してもよい。但し、後述の高信頼ＯＳのみを実行するコアに係るアクセス可能領域は、原則として後述の通常ＯＳのみを実行するコアに係るアクセス可能領域に対して、少なくとも部分的に異なるように設定される。これは、高信頼ＯＳの実行が通常ＯＳの実行により阻害されないようにするためである。以下では、高信頼ＯＳのみを実行するコアのみがアクセス可能なメモリ領域を、「メモリ保護領域」ともいう。
【００２１】
図４は、アクセス設定情報部１１におけるアクセス設定情報（メモリ保護領域）を変更する際の処理フローの一例を示す。
【００２２】
ステップ００１では、保護管理部２３は、アクセス設定情報を変更しようとする際、アクセス設定情報部１１の特殊キーレジスタへ所与のマジックナンバーを書き込む。
【００２３】
ステップ００２では、アクセス設定情報部１１のハードウェア回路は、書き込まれたマジックナンバーが、ハードウェア回路上に実装されたキーと一致するか否かを判定する。また、即ち、保護管理部２３は、自身のＩＤ（マジックナンバー）をレジスタに書き込み、アクセス設定情報部１１のハードウェア回路は、保護管理部２３により書き込まれたＩＤが、不変情報保持部１２の不変情報（保護管理部２３を一意に識別するＩＤ情報）と一致するか否かを判定する。
【００２４】
ステップ００３では、書き込まれたマジックナンバーが、ハードウェア回路上に実装されたキーと一致する場合のみ、設定テーブルのロックを解除する。マジックナンバーがハードウェア回路上に実装されたキーと一致しない場合には、設定テーブルのロックを解除せず、アクセス設定情報変更処理はエラーとなる。
【００２５】
ステップ００４では、保護管理部２３は、領域設定レジスタに、どのＣＰＵが、どのメモリ領域へアクセス出来るかを表す設定値を書き込む。この書き込み内容は、ロックが解除されている設定テーブルのデータに反映される。即ち、設定テーブルのデータ（アクセス設定情報）は、保護管理部２３により書き込まれた内容に従って変更される。
【００２６】
ステップ００５では、アクセス設定情報の変更処理の完了後、設定テーブルをロックする。尚、再びアクセス設定情報の変更を行う場合には、ステップ００１からステップ００５の手順を繰り返す。
【００２７】
図１に戻る。不変情報保持部１２は、ソフトウェアによって変更が不可能な情報を保持する。即ち、不変情報保持部１２は、所定の情報（不変情報）が埋め込まれたハードウェア回路上の改変不能な領域である。不変情報保持部１２は、上述の如くアクセス設定情報の変更処理を可能としたことにより副次的に生じうるセキュリティホールの発生を防止すべく、設定される。具体的には、不変情報保持部１２に保持される不変情報は、保護管理部２３を一意に識別するＩＤ情報（上述のマジックナンバー）や、保護管理部２３を動作させるコア番号の優先順位等を含んでよい。これらの不変情報は、いずれも悪意あるプログラムやソフトウェア・バグによるアクセス設定情報部１１へのアクセスを防止するための情報である。保護管理部２３を動作させるコア番号の優先順位を含む理由としては、ハードウェア不具合等により、保護管理部２３の動作するコア自体が動作しなくなった場合にも、規定された優先順位に従って、次に優先順位の高いコア上で、保護管理部２３を新たに起動可能にするためである。
【００２８】
メモリ保護機構３０は、複数のコア１、コア２、コア３、・・・、コアＮのうちの任意のコアからのメインメモリ３２へのアクセス要求を受けると、アクセス設定情報部１１の設定テーブルのデータに従って、当該コアによるメインメモリ３２へのアクセス要求を制限／許可する。例えば、図３に示す設定テーブルのデータの場合に、コア２がメインメモリ３２のアドレス番号０ｘ４０００＿００００に書き込み要求を発したとき、アドレス番号０ｘ４０００＿００００はコア２にとってアクセス可能領域でないため、当該書き込み要求は制限される（却下される）。
【００２９】
メインメモリ３２は、複数のコア１、コア２、コア３、・・・、コアＮによって共有される主記憶装置であり、例えば、半導体素子を利用して電気的にデータを記憶する揮発性記憶装置である。メインメモリ３２は、複数のメモリから構成されてもよい。
【００３０】
本実施例のマルチコアシステム１００では、大きく分けて高信頼ＯＳと通常ＯＳの２種類のソフトウェアプログラムが複数のコア１、コア２、コア３、・・・、コアＮによって実行される。高信頼ＯＳは、要求される信頼性が高いソフトウェアであり、車両システムにおいては、車両制御に関連するソフトウェア（例えばＡＢＳや、追従走行制御システムや制動力制御システム等の車両制御系ソフトウェア）であってよい。他方、通常ＯＳは、要求される信頼性が高信頼ＯＳほど高くないソフトウェアであり、車両制御に直接的に関係しないソフトウェア、例えば利便性に関連するソフトウェア（例えば、ナビゲーションシステムや情報検索システム等のマルチメディア系ソフトウェア）であってよい。
【００３１】
高信頼ＯＳ及び通常ＯＳを実行するコアは、原則としてそれぞれ所定されているが、後述の如く、高信頼ＯＳ側で高負荷状態が検出された場合等の所定の場合には、アクセス設定情報が変更されることと協調して、通常ＯＳを実行するコアのうちの少なくとも１つのコアが、高信頼ＯＳを実行するように高信頼ＯＳ側に移譲されることになる。
【００３２】
マルチコアシステム１００は、その主要なソフトウェア機能部として、ＯＳ内処理管理部２０を備える。また、マルチコアシステム１００は、その他、複数ＯＳ制御やＯＳ間通信機能を備える。ＯＳ内処理管理部２０は、高信頼エリアで機能する負荷調整部２１及び状態モニタ部２２、並びに保護管理部２３を備えると共に、通常エリアで機能する負荷調整部２４及び状態モニタ部２５を備える。
【００３３】
負荷調整部２１は、上述のアクセス設定情報の変更に伴う各コア間の負荷を調整する部分である。負荷調整部２１は、状態モニタ部２２による負荷状態の監視結果の通知を受けて、負荷の調整が必要であるか否かの判断を行う。判断内容としては、例えば以下のようなロジックが考えられる。先ず、高信頼ＯＳ内で、タスク処理が可能か否かを判定する。これは、現在の負荷状態や、負荷状態の想定持続時間等に基づいて判断されてもよい。高信頼ＯＳ内で、タスク処理が可能であると判断した場合には、負荷の調整は不要と判断する。他方、高信頼ＯＳ内で、タスク処理が不能であると判断した場合には、高信頼ＯＳ側タスクのうち、タスクの優先度情報（既知の設定値）からサスペンド若しくは停止してもよいタスクを抽出し、当該抽出したタスクをサスペンド若しくは停止することで、高信頼ＯＳ内でタスク処理が可能となるか否かを判定する。抽出したタスクをサスペンド若しくは停止することで、高信頼ＯＳ内でタスク処理が可能と判断した場合には、負荷の調整は不要と判断する。他方、抽出したタスクをサスペンド若しくは停止しても、高信頼ＯＳ内でタスク処理が不能な高負荷状態であると判断した場合には、アクセス設定情報を変更して高信頼ＯＳの使用コアを増やす手順へと移行する。即ち、負荷調整部２１は、保護管理部２３に対してアクセス設定情報の変更の要求（高信頼ＯＳの使用コアの増加の要求）を行う。負荷調整部２１は、保護管理部２３から使用コアの増加を行った旨の通知を受けると、状態モニタ部２２による負荷状態の監視結果に基づいて、増加通知に係る新たなコアを含めて負荷調整を行い、上述の高信頼ＯＳ内でタスク処理が不能な状態を解消する。例えば、増加通知に係る新たなコアに対して、高信頼ＯＳ内の処理不能であったタスク処理を割り当てることで、上述の高信頼ＯＳ内でタスク処理が不能な状態を解消する。尚、この際、サスペンド若しくは停止するために抽出したタスクについても、増加した高信頼ＯＳ側のコアを用いて実行するようにしてもよい。
【００３４】
状態モニタ部２２は、高信頼ＯＳ内における各コアの負荷や不具合をモニタリングする部分である。状態モニタ部２２は、ＯＳの管理情報であるＣＰＵ負荷率や、メモリ使用率等の統計データを監視し、高負荷やハードウェア不具合状態が検出された場合に、その旨を負荷調整部２１に通知する。状態モニタ部２２は、例えば高信頼ＯＳを実行するコアのＣＰＵ使用率が７０％を超えた場合に、高負荷状態を検出することとしてもよい。また、状態モニタ部２２は、例えば高信頼ＯＳを実行するコアの不具合を表すアラームが発生した場合に、ハードウェア不具合状態を検出することとしてもよい。
【００３５】
保護管理部２３は、上述の如くアクセス設定情報の変更を行う主体となる部分であり、負荷調整部２１からの要求を受けて、アクセス情報設定部１１へアクセスを行う。また、通常ＯＳ側の負荷調整部２４との連携機能として、コア使用要求機能やコア移譲完了通知の受け取り機能を有する。これについては図５に示すシーケンスを参照されたい。
【００３６】
負荷調整部２４は、状態モニタ部２５による負荷状態の監視結果に基づいて、通常ＯＳ内で各コア間の負荷を調整する部分である。また、負荷調整部２４は、高信頼ＯＳ側へのコアの移譲を行うための調整が完了した際に、保護管理部２３にコア移譲完了通知を行う。
【００３７】
状態モニタ部２５は、通常ＯＳ側において各コアの負荷や不具合をモニタリングする部分である。
【００３８】
図５は、実施例１によるマルチコアシステム１００における高負荷状態発生時の処理シーケンスを示す図である。ここでは、一例として、マルチコアシステム１００は、４つのコア１、コア２、コア３及びコア４を含み、デフォルト設定として、コア１及びコア２が、通常時（即ち後述の高負荷状態発生等に伴うコアの移譲が行われない時）の高信頼ＯＳの使用コアとして設定されており、コア３及びコア４が、通常時の通常ＯＳの使用コアとして設定されているものとする。また、これに伴い、アクセス設定情報部１１の設定テーブルには、デフォルト設定として、コア１及びコア２のみがアクセス可能な領域（即ち、コア３及びコア４がアクセス不能なメモリ保護領域）が設定されているものとする。
【００３９】
図５を時系列で参照するに、先ず、高信頼ＯＳ側で高負荷状態が発生すると、状態モニタ部２２において、当該高負荷状態が検知される。例えば、図５のＣ部に示すように、コア１及び２により実行されるべきタスクがタスクＵ，Ｖ，Ｗ，Ｘ，Ｙ及びＺであり、タスクＵ及びＸが所定時間内に処理不能である場合に、高負荷状態が検知される。高負荷状態が検知されると、高信頼ＯＳ側の負荷調整部２１に通知され、負荷調整部２１において、上述の如く、高信頼ＯＳの使用コアを増やすべきか否かが判断される。高信頼ＯＳの使用コアを増やすべきと判断した場合には、その旨の要求（使用コア数変更依頼）が保護管理部２３に対して行われる。保護管理部２３は、この要求を受け付けて、通常ＯＳ側の負荷調整部２４に対して、通常ＯＳの使用コア（例えばコア３）の高信頼ＯＳでの使用要求を行う。通常ＯＳ側の負荷調整部２４は、この要求を受け付けて、通常ＯＳ側の状態モニタ部２５に対して、通常ＯＳ上の各タスクの動作情報を取得するように要求する。通常ＯＳ側の状態モニタ部２５は、この要求を受け付けて、通常ＯＳ上の各タスクの動作情報を取得し、負荷調整部２４に供給する。負荷調整部２４は、状態モニタ部２５から通常ＯＳ上の各タスクの動作情報を取得し、当該取得した情報を考慮して、タスク移動を実施する。例えば、通常ＯＳ側の負荷調整部２４は、図５のＡ部に示すように、コア３のタスクａ及びｂを、コア４に移動する。これにより、コア３が、高信頼ＯＳで使用可能な状態となる。ここで、通常ＯＳ側の使用コア数の削減に伴い、通常ＯＳ側の負荷状態によっては全てのタスクを移動できない可能性が考えられる。その場合には、タスクの優先度に従って移動させるタスク及び終了させるタスクを判断してもよい。タスク移動が完了すると、その旨の通知が（移動完了通知）が保護管理部２３に対してなされ、保護管理部２３は、この通知を受けて、アクセス設定情報を変更する。例えば、図５のＢ部に示すように、コア３のタスクの移動完了通知を受けた場合には、コア３がメモリ保護領域にアクセスできるように、アクセス設定情報部１１にアクセスして、メモリ保護領域に対するアクセス権限を、コア１〜２から、コア１〜３に変更する。このようにしてアクセス設定情報の変更を実施すると、保護管理部２３は、高信頼ＯＳ側の負荷調整部２１に、コア移譲完了通知として、使用可能なコアの増加を通知する。高信頼ＯＳ側の負荷調整部２１は、この通知を受けて、高信頼ＯＳ側の状態モニタ部２２に対して、高信頼ＯＳ上の各タスクの動作情報を取得するように要求する。高信頼ＯＳ側の状態モニタ部２２は、この要求を受け付けて、高信頼ＯＳ上の各タスクの動作情報を取得し、高信頼ＯＳ側の負荷調整部２１に供給する。高信頼ＯＳ側の負荷調整部２１は、状態モニタ部２２から高信頼ＯＳ上の各タスクの動作情報を取得し、当該取得した情報を考慮して、タスク移動を実施する。例えば、高信頼ＯＳ側の負荷調整部２１は、図５のＣ部に示すように、コア１及びコア２のタスクＵ及びＸを、新たなコア３に移動する。この場合、コア３は、メインメモリ３２のメモリ保護領域を用いて、高信頼ＯＳ側のタスクＵ及びＸを実行する。このようにして、高信頼ＯＳ側のコア１及び２が高負荷状態に陥って高信頼ＯＳのタスクＵ及びＸが処理不能となった場合にも、通常ＯＳ側のコア３を利用して、メインメモリ３２のメモリ保護領域で高信頼ＯＳのタスクＵ及びＸを実行することができる。
【００４０】
尚、図５に示した処理シーケンスにおいて、検知された高負荷状態が解消され、状態モニタ部２２の監視結果に基づいて、高信頼ＯＳ側のコア１及びコア２の負荷が所定レベル以下に低減した場合（通常負荷状態又は低負荷状態に戻った場合）、保護管理部２３は、アクセス設定情報部１１にアクセスして、メモリ保護領域に対するコアのアクセス権限を、コア１〜３から、コア１〜２に変更する（元に戻す）。或いは、図５に示した処理シーケンスにおいて、コア３がタスクＵ及びＸを実行し終えた段階で、保護管理部２３は、アクセス設定情報部１１にアクセスして、メモリ保護領域に対するコアのアクセス権限を、コア１〜３から、コア１〜２に変更することとしてもよい。
【００４１】
図６は、実施例１によるマルチコアシステム１００における不具合状態発生時の処理シーケンスを示す図である。図６の処理シーケンスは、上述の図５に示した処理シーケンスに対して、高信頼ＯＳ側で高負荷状態が検出されることに代えて、高信頼ＯＳ側でハードウェア不具合状態が検出されることをトリガとする点だけが異なる。
【００４２】
図６に示す処理シーケンスによれば、例えば図６のＣ部に示すように、高信頼ＯＳ側のコア２が動作不能となり、コア２のタスクＵ及びＸが処理不能となった場合にも、通常ＯＳ側のコア３を利用して、メインメモリ３２のメモリ保護領域で高信頼ＯＳのタスクＵ及びＸを実行することができる。
【００４３】
ところで、近年の車載システムにおいては、実現するサービスの多種多様化による処理性能の向上と、車載環境特有の熱対策等の要望から、上述のような複数のコア１〜Ｎを搭載したシステム（マルチコアシステム１００）が求められている。また、車両を制御する車両制御系ソフトウェアと、進化するマルチメディアサービスを実現するマルチメディア系ソフトウェアが同一のシステム上に搭載されることが要求されている。そのような車両制御系とマルチメディア系とが同居するシステムにおいては、システムの品質・信頼性を守るために、メモリ保護機能が必要不可欠となる。
【００４４】
この点、本実施例によれば、上述の如く、高信頼ＯＳ側のコアのみがアクセス可能なメモリ保護領域を設定することにより、高信頼ＯＳに係るシステムの品質・信頼性を守ることができる。
【００４５】
また、限られたＣＰＵリソースの観点からは、高信頼ＯＳに対して無制限にＣＰＵリソースを割り当てることはできない。従って、高信頼ＯＳを担当するコアが高負荷状態に陥って高信頼ＯＳのタスクが処理不能となる場合が生じうる。かかる場合に、一時的に通常ＯＳ側のコアを利用して、高信頼ＯＳを実行させることも可能ではある。しかしながら、高信頼ＯＳは高品質・信頼性を確保する必要があるが、単に通常ＯＳ側のコアに実行させるだけでは、通常ＯＳ側のコアのアクセス可能領域が不十分である等により、必要な高品質・信頼性を確保することができない場合がある。これは、高信頼ＯＳを担当するコアが高負荷状態に陥った場合だけでなく、高信頼ＯＳを担当するコアが機能不能な不具合状態に陥った場合も同様である。
【００４６】
この点、本実施例によれば、上述の如く、高信頼ＯＳを担当するコアが高負荷状態や不具合状態に陥った場合でも、通常ＯＳ側のコアがメモリ保護領域で高信頼ＯＳのタスクを実行することができるので、高信頼ＯＳに求められる必要な高品質・信頼性を確保しつつ、ＣＰＵリソースを効率的に利用することができる。これにより、車両制御系とマルチメディア系とを効果的に同居させることが可能な車載システムを構築することができる。
【００４７】
また、本実施例によれば、上述の如くアクセス設定情報部１１のアクセス設定情報の変更は、不変情報保持部１２で保持されるキーによる照合が確認された場合に限り実行可能となるので、高いセキュリティ性を維持することができる。また、不変情報保持部１２で保持されるキーは、ハードウェア回路に埋設された不変情報であり、ユーザには知られることのないキーであるため、高いセキュリティ性が維持される。また、不変情報保持部１２で保持されるキーは、ハードウェア回路に埋設された不変情報であり、悪意のあるソフトウェアにより書き換えられることが無いため、高いセキュリティ性が維持される。
【実施例２】
【００４８】
図７は、本発明の実施例２によるマルチコアシステム２００の主要構成を示す図である。図７において、セクション２０２は、ソフトウェアにより実現される機能部を示し、セクション１０４は、ハードウェア構成を示す。ハードウェア構成は、上述の実施例１と同様であってよく、詳細な説明を省略する。
【００４９】
本実施例のマルチコアシステム２００は、上述の実施例１に対して、ＯＳ内処理管理部２２’内に、状況保存部２６と、予測・学習部２７とを追加的に備える点が主に異なる。状況保存部２６は、高信頼エリア及び通常エリアの双方に設けられ、予測・学習部２７は高信頼エリアに設けられる。
【００５０】
状況保存部２６は、アクセス設定情報を変更した状況を格納する部分である。具体的には、状況保存部２６は、アクセス設定情報を変更する事象（例えば上述の高負荷状態）が発生したときのマルチコアシステム２００内の状況、例えば、アクセス設定情報を変更する事象の発生時刻や動作タスク、ＯＳ統計情報（コア、バス等の利用率）等を格納する。或いは、状況保存部２６は、アクセス設定情報を変更する事象が発生したときのマルチコアシステム２００外の状況、例えばアクセス設定情報を変更する事象が発生したときの車両の位置や車両の周囲環境（道路や気温）や車両の走行状態（速度や加速度等）等を格納してもよい。この場合、これらの情報は、車載センサ（車載カメラを含む）により検出された状況に基づいて生成されてもよい。
【００５１】
予測・学習部２７は、高信頼ＯＳ側及び通常ＯＳ側の双方の状況保存部２６に格納されたデータから、上述の如くアクセス設定情報が変更されるような高負荷やハードウェア不具合発生のパターンを分析する機能を備える。また、予測・学習部２７は、その分析した結果に基づいて、高負荷やハードウェア不具合発生が予測されるような前兆パターンの発生を検知したときに、その旨を保護管理部２３に通知する。尚、予測・学習部２７は、上述の如く高信頼エリアのみで動作する。
【００５２】
予測・学習部２７は、例えば、状況保存部２６に格納されたデータに基づいて、アクセス設定情報を変更する事象の発生時間別の偏り、動作アプリケーションによる偏り、ハードウェアの使用率による偏り、ハードウェア種別による不具合の偏りのようなパターンを解析・抽出する。
【００５３】
図８は、実施例２によるマルチコアシステム２００における高負荷／不具合状態発生時の処理シーケンスを示す図である。図８に示す処理シーケンスは、状況保存部２６及び予測・学習部２７による処理が追加されている点が、上述の図５等に示した処理シーケンスと主に異なる。
【００５４】
図８に示す処理シーケンスでは、高負荷／不具合状態が発生すると、その際の状況が状況保存部２６に格納され、予測・学習部２７において高負荷／不具合状態が発生する状況の条件が解析・抽出される．予測・学習部２７により高負荷／不具合状態が発生する状況の条件が解析されると、その条件がモニタ条件として追加され、状態モニタ部２２に通知される。状態モニタ部２２は、モニタ条件が通知されると、以後、高負荷／不具合状態の検知処理の他、モニタ条件に該当する状況が検知されたか否かの判断処理を行い、モニタ条件に該当する状況が検知した場合には、使用コア数変更依頼を保護管理部２３に対して行う。
【００５５】
例えば、図８のＣ部に示すように、コア１及び２により実行されるべきタスクがタスクＵ，Ｖ，Ｗ，Ｘ，Ｙ及びＺとなるような状況が予測された場合には、予め使用コア数変更依頼が保護管理部２３に通知され、コア３がメインメモリ３２のメモリ保護領域を用いて高信頼ＯＳ側のタスクＵ及びＸを実行できる状態が形成される。
【００５６】
このように本実施例２によれば、モニタ条件が追加されると、モニタ条件に該当する状況が検知した場合に、速やかに使用コア数変更依頼が保護管理部２３に出されるので、負荷調整部２１を介して使用コア数変更依頼が保護管理部２３に出される場合に比べて、対応時間を短縮することができる。即ち、高負荷／不具合状態が発生する前にアクセス設定情報を変更しておくことが可能となり、高負荷／不具合状態の発生時にも通常ＯＳ側のコアを利用して、メインメモリ３２のメモリ保護領域で高信頼ＯＳを実行することができる。かかる応答性の向上を実現する本実施例２は、迅速な応答性が要求される車載システムに好適である。
【００５７】
以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。
【００５８】
例えば、上述した実施例では、高負荷／不具合状態の発生時に、メモリ保護領域への通常ＯＳ側のコアのアクセス権限を変更することで、メモリ保護領域の実質的な変更を行っているが、それに加えて、高負荷／不具合状態の発生時に、メモリ保護領域自体を増大させてもよい。例えば、高負荷／不具合状態の発生時に、通常時に使用されていないメモリ領域や、通常時に通常ＯＳ側のコアにより使用されるメモリ領域を、メモリ保護領域として追加設定してもよい。後者の場合（高負荷／不具合状態の発生時に、通常時に通常ＯＳ側のコアによりアクセス可能なメモリ領域を、メモリ保護領域として追加する場合）、設定テーブルのアクセス設定情報を変更することで、当該追加されたメモリ保護領域に対しては、高信頼ＯＳ側のコア及び高信頼ＯＳ側に移譲されたコアのみがアクセス可能とされ、他の通常ＯＳ側のコアはアクセス不能とされる。
【図面の簡単な説明】
【００５９】
【図１】本発明の実施例１によるマルチコアシステム１００の主要構成を示す図である。
【図２】設定レジスタの一例を示す図である。
【図３】設定テーブルのデータの一例を示す図である。
【図４】アクセス設定情報部１１におけるアクセス設定情報（メモリ保護領域）を変更する際の処理フローの一例を示す図である。
【図５】実施例１によるマルチコアシステム１００における高負荷状態発生時の処理シーケンスを示す図である。
【図６】実施例１によるマルチコアシステム１００における不具合状態発生時の処理シーケンスを示す図である。
【図７】本発明の実施例２によるマルチコアシステム２００の主要構成を示す図である。
【図８】実施例２によるマルチコアシステム２００における高負荷／不具合状態発生時の処理シーケンスを示す図である。
【符号の説明】
【００６０】
１〜Ｎ コア
１０ 動的メモリ保護制御部
１１ アクセス設定情報部
１２ 不変情報保持部
２０ ＯＳ内処理管理部
２１ 負荷調整部
２２、２２’ 状態モニタ部
２３ 保護管理部
２４ 負荷調整部
２５ 状態モニタ部
２６ 状況保存部
２７ 予測・学習部
３０ メモリ保護機構
３２ メインメモリ
１００，２００ マルチコアシステム
１０２，２０２ ソフトウェアセクション
１０４ ハードウェアセクション
【特許請求の範囲】
【請求項１】
種類の異なる２つ以上のソフトウェアを実行する複数のコアと、前記複数のコアにより共有されるメモリとを備えるマルチコアシステムであって、
前記メモリの保護領域に対する各コアのアクセス権限に関する情報を保持するアクセス設定情報部と、
前記アクセス設定情報部で保持されるアクセス設定情報に応じて各コアによる前記メモリの保護領域へのアクセスを制限又は許可するメモリ保護部と、
前記アクセス設定情報部にて保持される前記アクセス設定情報を変更する保護管理部と、
所与の識別情報を保持する不変情報保持部とを備え、
前記アクセス設定情報部は、前記保護管理部からの識別情報が前記不変情報保持部内の所与の識別情報と対応した場合に、前記アクセス設定情報への前記保護管理部のアクセスを許可し、前記保護管理部からの識別情報が前記不変情報保持部内の所与の識別情報と対応しなかった場合に、前記アクセス設定情報への前記保護管理部のアクセスを制限する、マルチコアシステム。
【請求項２】
前記２つ以上のソフトウェアは、第１のソフトウェアと、前記第１のソフトウェアよりも重要性の高い第２のソフトウェアとを含み、
前記保護管理部は、前記複数のコアのうちの特定のコアにより実行されるソフトウェアの種類が前記第１のソフトウェアから前記第２のソフトウェアに変更される際に、該特定のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更する、請求項１に記載のマルチコアシステム。
【請求項３】
前記所与の識別情報は、ハードウェア回路上に実装されたＩＤ情報であって前記保護管理部に固有のＩＤ情報である、請求項１に記載のマルチコアシステム。
【請求項４】
前記不変情報保持部は、複数のコアのうち前記保護管理部を動作させるコアの優先順位を定める情報を更に保持する、請求項１に記載のマルチコアシステム。
【請求項５】
前記２つ以上のソフトウェアは、車両制御に関する車両制御系ソフトウェアと、車両制御以外のマルチメディア系ソフトウェアとを含み、
前記複数のコアは、前記車両制御系ソフトウェアを常時実行する第１のコアと、前記マルチメディア系ソフトウェアを実行する第２のコアとを含み、
前記アクセス設定情報は、前記第１のコアによる前記メモリの保護領域へのアクセスを許可する情報を含む一方、前記第２のコアによる前記メモリの保護領域へのアクセスを制限する情報を含み、
前記保護管理部は、前記第２のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更する、請求項１に記載のマルチコアシステム。
【請求項６】
前記第１のコアの状態を監視する状態監視部と、
前記状態監視部により前記第１のコアの高負荷状態若しくは不具合状態が検出された場合に、前記保護管理部に対して前記アクセス設定情報の変更を要求する負荷調整部とを更に備える、請求項５に記載のマルチコアシステム。
【請求項７】
前記負荷調整部は、前記保護管理部が、前記第２のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更するのに応じて、前記車両制御系ソフトウェアの少なくとも一部のタスクの担当を、前記第１のコアから前記第２のコアに変更する、請求項６に記載のマルチコアシステム。
【請求項８】
前記保護管理部により前記アクセス設定情報が変更された際の状況を記憶する状況保存部を更に備える、請求項１に記載のマルチコアシステム。
【請求項９】
前記状態監視部は、前記状況保存部に記憶された状況が検出された場合に、前記保護管理部に対して前記アクセス設定情報の変更を要求する、請求項６に記載のマルチコアシステム。
【請求項１０】
車載システムを実現する請求項１〜９のうちのいずれか１項に記載のマルチコアシステム。
【請求項１】
種類の異なる２つ以上のソフトウェアを実行する複数のコアと、前記複数のコアにより共有されるメモリとを備えるマルチコアシステムであって、
前記メモリの保護領域に対する各コアのアクセス権限に関する情報を保持するアクセス設定情報部と、
前記アクセス設定情報部で保持されるアクセス設定情報に応じて各コアによる前記メモリの保護領域へのアクセスを制限又は許可するメモリ保護部と、
前記アクセス設定情報部にて保持される前記アクセス設定情報を変更する保護管理部と、
所与の識別情報を保持する不変情報保持部とを備え、
前記アクセス設定情報部は、前記保護管理部からの識別情報が前記不変情報保持部内の所与の識別情報と対応した場合に、前記アクセス設定情報への前記保護管理部のアクセスを許可し、前記保護管理部からの識別情報が前記不変情報保持部内の所与の識別情報と対応しなかった場合に、前記アクセス設定情報への前記保護管理部のアクセスを制限する、マルチコアシステム。
【請求項２】
前記２つ以上のソフトウェアは、第１のソフトウェアと、前記第１のソフトウェアよりも重要性の高い第２のソフトウェアとを含み、
前記保護管理部は、前記複数のコアのうちの特定のコアにより実行されるソフトウェアの種類が前記第１のソフトウェアから前記第２のソフトウェアに変更される際に、該特定のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更する、請求項１に記載のマルチコアシステム。
【請求項３】
前記所与の識別情報は、ハードウェア回路上に実装されたＩＤ情報であって前記保護管理部に固有のＩＤ情報である、請求項１に記載のマルチコアシステム。
【請求項４】
前記不変情報保持部は、複数のコアのうち前記保護管理部を動作させるコアの優先順位を定める情報を更に保持する、請求項１に記載のマルチコアシステム。
【請求項５】
前記２つ以上のソフトウェアは、車両制御に関する車両制御系ソフトウェアと、車両制御以外のマルチメディア系ソフトウェアとを含み、
前記複数のコアは、前記車両制御系ソフトウェアを常時実行する第１のコアと、前記マルチメディア系ソフトウェアを実行する第２のコアとを含み、
前記アクセス設定情報は、前記第１のコアによる前記メモリの保護領域へのアクセスを許可する情報を含む一方、前記第２のコアによる前記メモリの保護領域へのアクセスを制限する情報を含み、
前記保護管理部は、前記第２のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更する、請求項１に記載のマルチコアシステム。
【請求項６】
前記第１のコアの状態を監視する状態監視部と、
前記状態監視部により前記第１のコアの高負荷状態若しくは不具合状態が検出された場合に、前記保護管理部に対して前記アクセス設定情報の変更を要求する負荷調整部とを更に備える、請求項５に記載のマルチコアシステム。
【請求項７】
前記負荷調整部は、前記保護管理部が、前記第２のコアによる前記メモリの保護領域へのアクセスが許可されるように、前記アクセス設定情報を変更するのに応じて、前記車両制御系ソフトウェアの少なくとも一部のタスクの担当を、前記第１のコアから前記第２のコアに変更する、請求項６に記載のマルチコアシステム。
【請求項８】
前記保護管理部により前記アクセス設定情報が変更された際の状況を記憶する状況保存部を更に備える、請求項１に記載のマルチコアシステム。
【請求項９】
前記状態監視部は、前記状況保存部に記憶された状況が検出された場合に、前記保護管理部に対して前記アクセス設定情報の変更を要求する、請求項６に記載のマルチコアシステム。
【請求項１０】
車載システムを実現する請求項１〜９のうちのいずれか１項に記載のマルチコアシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００９−２５１９６７（Ｐ２００９−２５１９６７Ａ）
【公開日】平成２１年１０月２９日（２００９．１０．２９）
【国際特許分類】
【出願番号】特願２００８−９９７８８（Ｐ２００８−９９７８８）
【出願日】平成２０年４月７日（２００８．４．７）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２１年１０月２９日（２００９．１０．２９）
【国際特許分類】
【出願日】平成２０年４月７日（２００８．４．７）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]