JP2007109085A - 発熱制御方法、装置およびシステム - Google Patents

Abstract

【課題】コンピュータシステムの発熱を効率良く制御する。
【解決手段】 ソフトウェアスタックに含まれる制御スタック１１０の制御実行部１１４は、受信部１１２によりメインプロセッサおよびグラフィックプロセッサの温度を受信する。これらの温度に基づいて、サーマルエラーが発生したと判別したとき、制御実行部１１４は、動作中のアプリケーションの種別を、種別取得部１１６により取得する。そして、ハードウェアの動作を調整するハードウェア制御処理、アプリケーションの動作内容を変更するソフトウェア制御処理を行って、ハードウェアの発熱状態を制御する。ソフトウェア制御処理を行うのにあたっては、サーマルエラーが発生した部位、および動作中のアプリケーションの種別の組合せに応じた制御方式をリアクションテーブル１１８から取得して、取得した制御方式で制御する。
【選択図】図３

Description

本発明は、発熱制御技術に関し、とくにコンピュータシステムにおけるハードウェアの発熱を制御する方法、装置およびシステムに関する。

チップなどのハードウェアが高温になると、動作不良を起こしたり、長期信頼性が低下するため、コンピュータシステムにおいて、ハードウェアの発熱に対して、さまざまな対策がとられている。たとえば、チップの上部にヒートシンクを設けたり、チップの周辺にファンを設けるなど、チップから発生する熱を逃がす方法が用いられている。

一方、コンピュータアプリケーションがますます複雑になり、高速な処理システムが必要とされている。とくに、リアルタイムのアプリケーションは、毎秒何千メガビットの処理速度を要求する。このような需要に促され、マイクロプロセッサなどのハードウェアの高性能化が進む一方である。このようなハードウェアは、その性能を発揮するほど発熱量が大きいため、ヒートシンクやファンでもとりきれない発熱が生じうる。

そのため、機器内部の温度上昇により、システムの誤動作、ハングアップ、異常終了などのトラブルが発生しうる。これらのトラブルが発生するたびに、ユーザは再起動などの復帰操作をしなければならない。とくにゲーム機のような、連続した使用が楽しむための条件の一つである機器では、これらのトラブルは、製品のイメージを悪くする可能性がある。

本発明は上記事情に鑑みてなされたものであり、その目的は、コンピュータシステムにおけるハードウェアの発熱を効率良く制御する技術を提供することにある。

本発明にかかる態様は、コンピュータシステムのハードウェアにおける、発熱状態の制御対象となる対象部位の発熱を制御する方法に関する。この方法は、対象部位の発熱状態を取得し、取得した発熱状態に応じて、発熱状態を変化させるように、動作中のアプリケーションの動作内容を変更して対象部位の発熱状態を制御するものである。

また、本発明を装置、システム、プログラム、プログラムを記憶した記憶媒体として表現したものも、本発明の態様としては有効である。

本発明は、コンピュータシステムにおいて、ハードウェアの発熱を制御することにおいて有利である。

コンピュータシステムを用いた機器内部の温度上昇に起因するコンピュータシステムの誤動作、ハングアップ、異常終了などのトラブルに対して、たとえばヒートシンクのフィンを増やしたり、冷却ファンのパワーを大きくするなど冷却機構の冷却能力を高め、温度の上昇自体を防ぐ回避方法が考えられる。

ここで、ゲーム機を例にして考える。ゲーム機のメーカと、そのゲーム機で動作するアプリケーションすなわちゲームソフトウェア（以下略してゲームソフトという）のメーカとは通常異なる。ゲームソフトがハードウェアを使用する仕様によって、このゲームソフトの動作中にゲーム機のハードウェアの発熱量が変わってくる。

また、近年、およびこれからの傾向として、ゲーム機といえとも、ゲームソフトを実行する機能のみならず、他の機能、たとえばコンテンツを保存して配信するホームサーバ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）やＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）などの記録媒体に記録されたマルチメディアデータの再生機器、ＰＶＲ（Ｐｅｒｓｏｎａｌ Ｖｉｄｅｏ Ｒｅｃｏｒｄｅｒ）、ネットワークルータなどとしての機能も備えるものが多い。マルチ機能を有するゲーム機では、使用中の機能の種別、同時に使用されている機能の多さによって、ハードウェアの発熱量が変わってくる。

すなわち、ゲーム機の動作中の発熱量は、動作中のゲームソフトの仕様や、同時に使用されている機能の多さなどの使用状態によって異なる。安全を期するために、ゲーム機のメーカ側において、冷却機構の冷却能力にマージンを持たせてゲーム機を設計することが行われている。

この方法では、ゲーム機の大きさまたは消費電力を増大させてしまうという問題がある。また、実際の使用において、ゲーム機のハードウェアがシステムにトラブルをきたすほど発熱する場合はそれほど多くないため、実際の発熱量に比べ、冷却機構の冷却能力が無駄になるときが多い。

このような問題は、ゲーム機に限らず、コンピュータシステムを用いるいかなる機器においても存在しうる。

本発明者は、コンピュータシステムのハードウェアの発熱を効率良く制御するために、下記の技術を提案する。

この技術は、コンピュータシステムのハードウェアにおける、発熱状態の制御対象となる対象部位の発熱状態を取得し、取得した発熱状態に応じて、該発熱状態を変化させるように、動作中のアプリケーションの動作内容を変更して前記対象部位の発熱状態を制御する。

ここで、「アプリケーションの動作内容を変更する」とは、アプリケーションを直接操作して、アプリケーションが必要とするハードウェアの処理能力が変化するようにその動作内容を変更することを意味し、この変更によって対象部位の発熱状態が変わりうる。例えば、通常モードで動作中のアプリケーションの動作モードを、通常モードが必要とする処理速度より低い処理速度を要求する低速にモードに変更することや、アプリケーションの主となる機能部分を通常モードのままにし、ほかの機能の処理モードを低速モードに変更する。動作中のアプリケーションを停止させることもこの「変更」に含まれる。

また、取得した発熱状態に応じて、システムのハードウェアに含まれ、その動作状態が対象部位の発熱状態に影響を与える部位の動作を調整してもよい。

ここの「調整」は、上記部位の動作を直接調整することを意味し、たとえば、プロセッサの動作周波数を調整することや、ファンの回転数を調整することなどとすることができる。

すなわち、アプリケーションの動作内容の変更と、ハードウェアの動作調整とを併用して、対象部位の発熱状態を制御してもよい。

さらに、対象部位がとりうる発熱状態毎の制御方式を規定する制御方式リストを保持し、この制御方式リストから、対象部位の発熱状態に対応する制御方式を取得して、取得された制御方式で対象部位の発熱状態を制御するようにしてもよい。

「制御方式」とは、アプリケーションの動作内容の変更方式、ハードウェアの調整方式、またはそれらの組合せを示すものである。

ここで、制御方式リストについて、メインプロセッサとグラフィックプロセッサを備え、ゲーム機能とＰＶＲ機能が実行可能なシステムの例を用いて具体的に説明する。このシステムにおいて、ゲーム機能とＰＶＲ機能は、ゲームＬＰＡＲとＰＶＲＬＰＡＲによって実現される。なお、 ＬＰＡＲは、システムリソースを論理的に分割して使用するロジカルパーテーション機能すなわち論理区画機能であり、本明細書においては、論理的に分割された区画上で実行されるソフトウェアのスタックと同じ意味で用いるとともに、同じＬＰＡＲに属するソフトウェアを同じ種別とする。

図１は、このシステムにおける、２つのＬＰＡＲのうちのゲームＬＰＡＲの動作中の制御方式リストの例を示す。メインプロセッサとグラフィックの発熱状態のレベルは、温度の高い順からレベルＡ〜Ｉの９つに分けられ、それぞれのレベルに応じた制御方式が決められている。

たとえば、メインプロセッサの発熱状態がレベルＩに達したとき、制御方式「９」として「メインプロセッサ動作抑制」が決められている。ここの「メインプロセッサ動作抑制」は、メインプロセッサの周波数を下げるなど、ハードウェアの動作の直接的な調整である。

また、メインプロセッサの発熱状態がレベルＩより上のレベルＨにあるとき、制御方式「８＆１１＆１２」として、「データ保護の上ゲームＬＰＡＲサスペンド、警告メッセージ表示、ログ記録」が決められている。「データ保護の上ゲームＬＰＡＲサスペンド」は、ソフトウェアの動作内容の変更であり、この制御は、たとえばデータをセーブするなどの猶予時間を与えてゲームＬＰＡＲをサスペンドモードにする。

さらに高いレベルＧの場合には、制御方式「７＆１１＆１２」として、「ゲームＬＰＡＲサスペンド、警告メッセージ表示、ログ記録」が決められている。レベルＨの場合の「データ保護の上ゲームＬＰＡＲサスペンド」に対して、レベルＧにおいては、データの保護より発熱の抑制が優先される。

最も高いレベルＡは、メインプロセッサが正常動作不可能になる直前などの危険状態を示し、この状態に対して、制御方式「１」として「システムシャットダウン」が決められている。

グラフィックプロセッサに対しても同じように、その発熱状態のレベルに応じて、制御方式が決められている。

また、複数の種別のアプリケーションが同時に動作している場合において、各動作中のアプリケーションの種別を取得し、取得された種別の組合せに応じて、動作中のアプリケーションの動作内容を変更するようにしてもよい。たとえば、各々のアプリケーションの種別毎に優先度を付与し、動作中のアプリケーションの種別の優先度に応じて、優先度が低い種別のアプリケーションほど、その動作を抑制するように動作内容を変更する。

さらに、アプリケーションが実現する機能ごとに優先度を付与し、動作中のアプリケーションに対して、優先度が低い機能ほど、この機能を実現する部分の動作を抑制するように動作内容を変更するようにしてもよい。

また、本発明にかかる態様において、対象部位の発熱状態が規定の正常状態の範囲を外れたときに、対象部位の発熱状態が正常状態の範囲に戻るように変更または調整し、この変更または調整の後、対象部位の発熱状態が正常状態の範囲に戻ったときに、復帰処理、すなわち変更の取り消し、調整の復元を行うことが好ましい。

さらに、対象部位の発熱状態が規定の正常状態の範囲を外れたときに、ユーザに通知してもよく、この場合、対象部位の発熱状態が正常状態の範囲を外れた頻度が一定の閾値を超えたときにおいてのみ通知することが好ましい。

以下、図面を参照して、本発明の実施形態を具体的に説明する。

図２は、本発明の実施形態にかかるコンピュータシステム５００の構成を示すブロック図である。コンピュータシステム５００は、例としてゲーム機に用いられており、このゲーム機は、ゲーム機能以外に、ＰＶＲとしての機能を有する。

コンピュータシステム５００は、コンピュータシステム５００を効率良く使用するための機能、環境を提供し、システム全体を統括的に制御するオペレーティングシステム（以下、ＯＳという）が実行される。そのＯＳ上で複数のアプリケーションソフトウェア（以下、アプリケーションという）が実行される。

また、図２などにおいて、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされた予約管理機能のあるプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

コンピュータシステム５００は、システムボード１００とソフトウェアスタック２００とを含む。

システムボード１００は、メインプロセッサ１０と、グラフィックプロセッサ２０と、送信部４０とを含む。メインプロセッサ１０とグラフィックプロセッサ２０は協調的に演算処理を行う。メインプロセッサ１０とグラフィックプロセッサ２０のチップ内部に温度センサ３０がそれぞれ設けられている。温度センサ３０と接続されている送信部４０は、温度センサ３０により測定されたメインプロセッサ１０とグラフィックプロセッサ２０の温度をソフトウェアスタック２００、具体的には後述する制御スタック１１０に送信する。

ソフトウェアスタック２００は、制御スタック１１０、システムＬＰＡＲ１２０、ユーティリティＬＰＡＲ１３０、ゲームＬＰＡＲ１４０、ＰＶＲＬＰＡＲ１５０を含む。

システムＬＰＡＲ１２０は、コンピュータシステム５００のＯＳの基本機能を実現するＬＰＡＲであり、ユーティリティＬＰＡＲ１３０は、図示しない表示装置や、各種周辺機器のドライバなどをサポートする。ゲームＬＰＡＲ１４０とＰＶＲＬＰＡＲ１５０は、アプリケーションＬＰＡＲとしてそれぞれゲーム機能とＰＶＲ機能を実行するＬＰＡＲである。

制御スタック１１０は、ソフトウェアスタック２００に含まれる各ＬＰＡＲのスケジューリングなど、ＬＰＡＲの制御を行うとともに、コンピュータシステム５００におけるハードウェア、ここではシステムボード１００に含まれる各構成の動作を制御することもできる。

コンピュータシステム５００において、システムボード１００の発熱状態、ここではメインプロセッサ１０およびグラフィックプロセッサ２０の発熱状態の制御は制御スタック１１０によって行われる。図３は、制御スタック１１０の機能を示す。なお、本発明の趣旨を分かり易くするために、図３は、制御スタック１１０によって実行される各々の機能のうちの、システムボード１００の発熱の制御に関わる機能を示し、他の機能についてはここで省略する。

図３は、制御スタック１１０を示す。制御スタック１１０は、受信部１１２、制御実行部１１４、種別取得部１１６、リアクションテーブル１１８を含む。受信部１１２は、送信部４０から送信されたきたメインプロセッサ１０とグラフィックプロセッサ２０の温度を受信し、種別取得部１１６は、動作中のアプリケーションの種別を取得し、制御実行部１１４は、受信部１１２により受信された温度、および種別取得部１１６により取得された動作中のアプリケーションの種別に応じて制御を実行する。

リアクションテーブル１１８は、制御実行部１１４により行われる制御のうちの、アプリケーションに対する制御の方式を規定するリストである。制御実行部１１４は、リアクションテーブル１１８から、受信部１１２により受信された温度、および種別取得部１１６により取得された動作中のアプリケーションの種別に対応する制御方式を取得し、取得した制御方式で、アプリケーションの制御を行う。

ここで、図４〜図７を参照して、制御実行部１１４の動作を具体的に説明する。

図４は、リアクションテーブル１１８の具体例を示す。なお、リアクションテーブル１１８は、制御実行部１１４が参照することができればいかなる形式で実装されてもよく、ここではたとえばライブラリとして実装されている。

図５〜図７は、制御実行部１１４の処理を示すフローチャートである。制御実行部１１４は、制御を行う際に、サーマルエラーが発生した回数ｉをカウントし、回数ｉのデフォルト値は０である（Ｓ１０）。

制御実行部１１４は、メインプロセッサ１０とグラフィックプロセッサ２０のいずれかの温度が所定の閾値を超えたときに、サーマルエラが発生したとし、制御を開始する（Ｓ１４）。制御実行部１１４は、サーマルエラーが発生したときに、まず、エラーの発生回数ｉを確認する（Ｓ１６）。回数ｉが０回である（Ｓ１６：Ｙｅｓ）ときに、制御実行部１１４は、警告基準時刻Ｔ１とハードウェア制御基準時刻Ｔ２（警告基準時刻Ｔ１とハードウェア制御基準時刻Ｔ２の詳細については後述する）を現在時刻ｔに設定するとともに、サーマルエラーの発生回数ｉに対して１を加算する（Ｓ４０、Ｓ４４）。そして、制御実行部１１４は、ハードウェア制御処理を行う（Ｓ５０）。

図６は、ステップＳ５０のハードウェア制御処理を示すフローチャートである。制御実行部１１４が行うハードウェア制御処理は、コンピュータシステム５００のハードウェアに含まれており、その動作が発熱状態の制御対象となる対象部位の発熱状態に影響を与える部位の動作を直接調整する処理であり、ここでは、対象部位はメインプロセッサ１０とグラフィックプロセッサ２０であり、制御実行部１１４は、調整する部位を対象部位そのものとする。

制御実行部１１４は、ハードウェア制御処理を行うのにあたり、まず、どのプロセッサの温度が閾値を超えたかを確認する（Ｓ５１、Ｓ５４）。メインプロセッサ１０とグラフィックプロセッサ２０の両方とも温度が閾値を超えた場合（Ｓ５１：Ｙｅｓ）、制御実行部１１４は、たとえばクロックゲーティングなどプロセッサの動作周波数を軽減する手法を用いてメインプロセッサ１０とグラフィックプロセッサ２０の消費電力を下げることによってその両方の動作を抑制する（Ｓ５２）。ここで、メインプロセッサ１０とグラフィックプロセッサ２０の動作を抑制する手法として、メインプロセッサ１０とグラフィックプロセッサ２０に対して同じものを用いてもよいし、それぞれのアーキテクチャーに応じた別々の方法を用いてもよい。

一方、温度が閾値を超えたのはメインプロセッサ１０のみであれば（Ｓ５１：ＮＯ、Ｓ５４：Ｙｅｓ）、制御実行部１１４は、メインプロセッサ１０の動作を抑制する（Ｓ５６）。

また、温度が閾値を超えたのはグラフィックプロセッサ２０のみであれば（Ｓ５１：Ｎｏ、Ｓ５４：Ｎｏ）、制御実行部１１４は、グラフィックプロセッサ２０の動作を抑制する（Ｓ５８）。ここで、メインプロセッサ１０の動作が、グラフィックプロセッサ２０の発熱状態にも影響を与えると考えられるので、グラフィックプロセッサ２０の動作を抑制するのにあたり、メインプロセッサ１０の動作も抑制するようにしてもよい。

制御実行部１１４は、調整開始時すなわちハードウェア制御基準時刻Ｔ２から所定の制限時間Ｃｈ内に、対象部位の温度が閾値以下に戻った場合（Ｓ６０：Ｙｅｓ、Ｓ７０：Ｙｅｓ）、復帰処理を行って（Ｓ８０）、次のエラーが発生するまで待機する。ここでの復帰処理は、ステップＳ５０において調整を行った対象部位の動作を元に戻す処理であり、たとえばプロセッサの動作周波数を元の周波数に戻す処理とすることができる。

一方、調整開始時から制限時間Ｃｈを超えても、対象部位の温度が閾値以下に戻らなかった場合（Ｓ６０：Ｎｏ、Ｓ７０：Ｎｏ）、制御実行部１１４は、ソフトウェア制御処理を行う（Ｓ１００）。

ステップＳ１６に戻り、エラーの発生回数が０ではないとき（Ｓ１６：Ｎｏ）には、制御実行部１１４は、ステップＳ４０において設定された警告基準時刻Ｔ１から今回のエラー発生時刻までの時間（ｔーＴ１）を確認する（Ｓ２０）。この時間が所定の閾値Ａを超えた場合（Ｓ２０：Ｙｅｓ）、制御実行部１１４は、エラーの発生回数ｉを０にリセットするとともに、警告基準時刻Ｔ１を今回のエラー発生時ｔに設定して（Ｓ２４：Ｓ４０）、ステップＳ４４からの処理を行う。一方、時間（ｔ−Ｔ１）が閾値Ａ以内である場合（Ｓ２０：Ｎｏ）、制御実行部１１４は、この時間内におけるエラーの発生頻度を算出するとともに、算出された発生頻度が閾値Ｂを超えたか否かを確認する（Ｓ３０）。

エラーの発生頻度が閾値Ｂを超えた場合（Ｓ３０：Ｙｅｓ）には、制御実行部１１４は、コンピュータシステム５００が実装されたゲーム機のスピーカや表示装置などを用いてエラー発生頻度が高い旨の警告をして（Ｓ３４）ステップＳ４４からの処理を行う。エラーの発生頻度が閾値Ｂ以内である場合（Ｓ３０：Ｎｏ）、制御実行部１１４は、ステップＳ４４からの処理を行う。

ステップＳ４４からの処理は、既に説明済みであるので、ここで説明を省略する。

図７は、図５に示すフローチャートにおけるステップＳ１００のソフトウェア制御処理を示すフローチャートである。前述したように、制御実行部１１４は、制限時間Ｃｈ内に対象部位の温度を閾値以下に戻すことができなかった場合にソフトウェア制御処理を行う。このソフトウェア制御処理は、図４に示すリアクションテーブル１１８を参照して行われる。

リアクションテーブル１１８は、サーマルエラーが発生したプロセッサおよび動作中のアプリケーションの種別の組合せ毎に制御方式（図中リアクション）を段階的に規定するリストである。ここで、サーマルエラーがメインプロセッサ１０のみにおいて発生し、動作中のアプリケーションの種別がゲームのみである場合を例にして、リアクションテーブル１１８およびハードウェア制御処理の詳細について説明する。

図７に示すように、制御実行部１１４は、ソフトウェア制御処理（Ｓ１００）を行うのにあたり、まず、種別取得部１１６に動作中のアプリケーションＬＰＡＲの種別を取得させる（Ｓ１０４）。上記例の場合において、動作中のアプリケーションＬＰＡＲの種別はゲームＬＰＡＲ１４０となる。

制御実行部１１４は、サーマルエラーが発生したプロセッサおよび動作中のアプリケーションＬＰＡＲの種別に基づいて、リアクションテーブル１１８から相対応する制御方式を取得する（Ｓ１０８）。図４の最上欄に示すように、この場合に対する制御方式は、「サイレントモード」、「サイレント＆低解像度モード」、「ゲームサスペンド」、「ゲームシャットダウン」、「システムサスペンド」、「システムシャットダウン」の順で段階的に規定されている。制御実行部１１４は、この順で制御を行う。

この場合において、動作中のアプリケーションはゲームのみであり、メインプロセッサ１０のサーマルエラーを引き起こすアプリケーションはゲームであると断定できるため、ゲームＬＰＡＲ１４０に対してその動作を抑制するように規定される。本実施形態において、ゲームアプリケーションの画像描画機能が音声機能より高い優先度を有するとし、ゲームアプリケーションの動作を抑制する際に、まず優先度の低い音声機能を抑制するように、リアクションテーブル１１８の該当欄において、第１のステップの制御方式としては「サイレントモード」が規定されている。

制御実行部１１４は、まず、ソフトウェア制御基準時刻Ｔ３を現在時刻に設定して、第１のステップの制御方式「サイレントモード」に従って、まず、ゲームアプリケーションの音声機能を停止する（Ｓ１１０、Ｓ１１４：Ｎｏ、Ｓ１２４）。そして、音声機能が停止された時刻すなわちソフトウェア制御基準時刻Ｔ３から所定の制限時間Ｃｓ内に、対象部位ここではメインプロセッサ１０の温度が閾値以下に戻った場合（Ｓ１２８：Ｙｅｓ、Ｓ１３０：Ｙｅｓ）、復帰処理（図５におけるＳ８０）を行って、次のエラーが発生するまで待機する。ソフトウェア制御処理における復帰処理は、ステップＳ１２４において行った変更を取り消す処理であり、ここで、ゲームアプリケーションの音声機能を回復させる処理となる。

一方、ステップＳ１２０において設定されたソフトウェア制御基準時刻Ｔ３から制限時間Ｃｓを超えても、メインプロセッサ１０の温度が閾値以下に戻らなかった場合（Ｓ１２８：Ｎｏ、Ｓ１３０：Ｎｏ）、制御実行部１１４は、既に行った制御を続行したまま、次のステップの制御方式に従ってＳ１２０からの処理を行う。ここの例では、第２のステップの制御方式「低解像度モード」が用いられ、サイレントモードが続行されるとともに、ゲームアプリケーションの画像描画モードは低解像度モードにされる。

このように、制御実行部１１４は、規定された複数の制御方式を順に使用し、ある制御方式による制御が、制限時間Ｃｓ以内で対象部位の温度を閾値以下に戻した場合において復帰処理を行ってソフトウェア制御処理を終了する一方、ある制御方式による制御が、制限時間Ｃｓ以内で対象部位の温度を閾値以下に戻すことができなかった場合においては、次の制御方式を加えて制御を行う。

なお、次の制御方式が最後のステップの「システムシャットダウン」である場合（Ｓ１１４：Ｙｅｓ）には、制御実行部１１４は、コンピュータシステム５００全体をシャットダウンする（Ｓ１５０）。

リアクションテーブル１１８の最上欄において、第３、第４、第５、第６のステップの制御方式として「ゲームサスペンド」、「ゲームシャットダウン」、「システムサスペンド」、「システムシャットダウン」が規定されており、それぞれに対応する制御動作は「ゲームＬＰＡＲ１４０をサスペンドモードにする」、「ゲームＬＰＡＲ１４０をシャットダウン」、「システム全体をサスペンドモードにする」、「システム全体をシャットダウン」となる。

また、本実施形態のコンピュータシステム５００において、制御実行部１１４は、アプリケーションＬＰＡＲまたはシステム全体をサスペンドモードにする場合には、データをセーブする猶予時間を確保し、データのセーブを行ってからサスペンドモードにする。

アプリケーションＬＰＡＲまたはシステム全体をシャットダウンするときにおいても同じように、データをセーブする猶予時間を確保し、データのセーブを行ってからシャットダウンする。

以上、サーマルエラーがメインプロセッサ１０のみにおいて発生し、動作中のアプリケーションの種別がゲームのみである場合を例にしてソフトウェア制御処理を具体的に説明した。ここで、リアクションテーブル１１８の最上欄以外の詳細を説明することによって、他の場合におけるソフトウェア制御処理も説明する。

リアクションテーブル１１８において、サーマルエラーがメインプロセッサ１０のみにおいて発生し、動作中のアプリケーションの種別がＰＶＲのみである場合に対して、「ＰＶＲ低速モード」、「ＰＶＲサスペンド」、「ＰＶＲシャットダウン」、「システムサスペンド」、「システムシャットダウン」の順で５つのステップの制御方式が規定されている。「ＰＶＲ低速モード」、「ＰＶＲサスペンド」、「ＰＶＲシャットダウン」は、「録画モードを低速モードにする」、「ＰＶＲＬＰＡＲ１５０をサスペンドモードにする」、「ＰＶＲＬＰＡＲ１５０をシャットダウン」の制御動作にそれぞれ対応する。

また、サーマルエラーがメインプロセッサ１０のみにおいて発生し、動作中のアプリケーションの種別がゲームとＰＶＲの両方である場合に対して、「ＰＶＲサスペンド」、「ＰＶＲシャットダウン」、「ゲームサイレントモード」、「低解像度モード」、「ゲームサスペンド」、「ゲームシャットダウン」、「システムサスペンド」、「システムシャットダウン」の順で８つのステップの制御方式が規定されている。本実施形態のコンピュータシステム５００は、ゲーム機に用いられたものであるので、ゲームの優先度がＰＶＲより高いとする。したがって、サーマルエラーが発生したときに、優先度の低い種別のアプリケーションからその動作を抑制するように、ＰＶＲＬＰＡＲ１５０の抑制（「ＰＶＲサスペンド」、「ＰＶＲシャットダウン」）が、ゲームＬＰＡＲの抑制（「ゲームサイレントモード」、「低解像度モード」、「ゲームサスペンド」、「ゲームシャットダウン」）より先に行われるようにしている。

また、複数の種別のアプリケーションの動作中にサーマルエラーが発生した場合に、優先度の低いアプリケーションの動作を抑制する際に、この優先度の低いアプリケーションのみの動作中にサーマルエラーが発生した場合と同じステップの制御方式を用いてもよい。たとえば、サーマルエラがメインプロセッサ１０のみにおいて発生し、動作中のアプリケーションの種別がＰＶＲのみである場合に、「ＰＶＲ低速モード」、「ＰＶＲサスペンド」、「ＰＶＲシャットダウン」の順で制御方式が規定されている。それに対応して、サーマルエラがメインプロセッサ１０のみにおいて発生し、動作中のアプリケーションの種別がゲームとＰＶＲの両方である場合には、先に抑制されるＰＶＲに対して、「ＰＶＲ低速モード」、「ＰＶＲサスペンド」、「ＰＶＲシャットダウン」の順の制御方式を用いてもよい。これに対して、本実施形態において、この場合におけるＰＶＲの制御方式として、第１のステップの制御方式として「ＰＶＲ低速モード」ではなく、「ＰＶＲ低速モード」の制御方式よりプロセッサへの負荷をより軽減することができる「ＰＶＲサスペンド」を規定している。こうすることによって、優先度の高いアプリケーションへの影響を迅速に解消することができる。

リアクションテーブル１１８において、サーマルエラーがグラフィックプロセッサ２０のみにおいて発生し、動作中のアプリケーションの種別がゲームのみである場合に対して、「低解像度モード」、「ゲームサスペンド」、「ゲームシャットダウン」、「システムサスペンド」、「システムシャットダウン」の順で５つのステップの制御方式が規定されている。ここで、「サイレントモード」の制御方式がないのは、グラフィックプロセッサ２０が、描画に関わる処理を担うプロセッサであるので、ゲームの音声機能の有無は、グラフィックプロセッサ２０の発熱状態にほぼ影響を与えないからである。

また、サーマルエラーがグラフィックプロセッサ２０のみにおいて発生し、動作中のアプリケーションの種別がＰＶＲのみである場合に対して、「システムサスペンド」、「システムシャットダウン」の順で５つのステップの制御方式が規定されている。ここで、ＰＶＲＬＰＡＲの抑制などを行わずに、第１のステップの制御方式として「システムサスペンド」が規定されている。これは、ＰＶＲＬＰＡＲ１５０がグラフィックプロセッサ２０をほとんど使用しないのに、グラフィックプロセッサ２０においてサーマルエラーが発生したのは、使用環境の問題や、システム全体に何らかのトラブルがあったと考えられるからである。

また、サーマルエラーがグラフィックプロセッサ２０のみにおいて発生し、動作中のアプリケーションの種別がゲームとＰＶＲの両方である場合に対して、動作中のアプリケーションの種別がゲームのみである場合と同じように、「ゲーム低解像度モード」、「ゲームサスペンド」、「ゲームシャットダウン」、「システムサスペンド」、「システムシャットダウン」の順で５つのステップの制御方式が規定されている。

次に、メインプロセッサ１０とグラフィックプロセッサ２０両方においてサーマルエラーが発生した場合について説明する。

この場合、動作中のアプリケーションの種別がゲームのみであるとき、「サイレント＆低解像度モード」、「ゲームサスペンド」、「ゲームシャットダウン」、「システムサスペンド」、「システムシャットダウン」の順で５つの制御方式が規定されている。ここで、第１のステップの制御方式を「サイレントモード」ではなく、「サイレント＆低解像度モード」にしたのは、メインプロセッサ１０とグラフィックプロセッサ２０両方においてサーマルエラーが発生したので、「サイレントモード」だけの制御方式では、サーマルエラーの解消が遅くなるからである。

また、動作中のアプリケーションの種別がＰＶＲのみであるとき、「ＰＶＲサスペンド」、「ＰＶＲシャットダウン」、「システムサスペンド」、「システムシャットダウン」の順で４つの制御方式が規定されている。グラフィックプロセッサ２０をほとんど使用しないＰＶＲしか動作していないのに、グラフィックプロセッサ２０においてサーマルエラーが発生したのは、使用環境の問題や、システム全体に何らかのトラブルがある可能性が高い。そのため、ここでは、第１のステップの制御方式として、「ＰＶＲ低速モード」ではなく、「ＰＶＲサスペンド」を規定し、ＰＶＲＬＰＡＲ１５０の制御ステップを減らしている。また、第１のステップの制御方式を「ＰＶＲサスペンド」とすることによって、データがセーブされるので、もしシステム全体に問題があるとしても、データを保護することができ、安全である。

最後に、動作中のアプリケーションの種別がゲームとＰＶＲ両方であるとき、「ＰＶＲシャットダウン、ゲーム低解像度モード」、「ゲームサスペンド」、「ゲームシャットダウン」、「システムサスペンド」、「システムシャットダウン」の順で５つの制御方式が規定されている。なお、この６つの制御方式は、メインプロセッサ１０とグラフィックプロセッサ２０におけるサーマルエラーが同時に発生しているときの制御方式であり、いずれかの制御方式による制御中に、メインプロセッサ１０あるいはグラフィックプロセッサ２０のサーマルエラーが解消されれば、制御実行部１１４は、そのステップの制御方式から、サーマルエラーが解消されていないプロセッサのみにおいてサーマルエラーが発生した場合の制御方式で制御を行う。たとえば、第１のステップの制御方式「ＰＶＲシャットダウン、ゲーム低解像度モード」で制御を行い、制限時間Ｃｓ内にメインプロセッサ１０の温度が閾値以下になった場合には、制御実行部１１４は、「グラフィックプロセッサのみにおいてサーマルエラが発生し、動作中のアプリケーションがゲームである」場合に対して規定された制御方式のうち、「低解像度モード」の次の制御方式「ゲームサスペンド」で制御を行う。

このように、図２に示すコンピュータシステム５００は、発熱状態の制御対象となるメインプロセッサ１０とグラフィックプロセッサ２０の温度を測定して制御スタック１１０に送信し、制御スタック１１０は、制御対象の温度に応じて、アプリケーションの動作内容を変更することによって制御対象の温度を制御する。こうすることによって、システムに大パワーの冷却装置を設けなくても、確実な温度制御を実現することができる。

また、ゲーム機能の画像描画機能に対して、音声機能より高い優先度を付与し、その動作を抑制する際に、優先度の低い機能から抑制するようにしているので、温度を抑制しながら、優先度の高い機能を引き続き実行することが可能であり、ユーザに与えるストレスが少ない。

また、アプリケーションＬＰＡＲに対して優先度を付与し、優先度の低いＬＰＡＲから動作を抑制するようにしている。こうすることによって、温度を抑制しながら、システムの主要機能すなわち優先度の高いアプリケーションを引き続き実行することが可能である。

さらに、メインプロセッサやグラフィックプロセッサの動作周波数を軽減するなど、ハードウェアの動作調整を併用することによって、より効率良く温度の制御を実現している。

また、システムのとりうる発熱状態毎に制御方式を規定したリアクションテーブル１１８を設けているので、制御実行部１１４は、このテーブルを参照して制御を行うことができ、構成が複雑なシステムでも簡単に制御することができる。

また、サーマルエラーの発生をユーザに警告するようにしているので、ユーザはそれに応じて使用環境に問題があるか否かのチェックをすることなどができ、安全である。通常の使用ではサーマルエラーが頻発する可能性が低いことを想定し、サーマルエラーの発生頻度が所定の閾値を超えたときにおいてのみ警告を行うようにすることによって、頻繁な警告でユーザに煩わしさを感じさせることを避けるとともに、使用環境などに問題がある可能性をユーザに知らせることができる。

また、ＬＰＡＲまたはシステムをサスペンドモードにしたり、シャットダウンしたりするときに、猶予時間を確保してデータをセーブしているので、安全である。

以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

たとえば、図２に示すコンピュータシステム５００は、ゲーム機に用いられるシステムとしたが、本発明による発熱制御技術は、ゲーム機に限らず、コンピュータシステムを用いるいかなる機器にも適用することができる。

また、図２に示すコンピュータシステム５００において、アプリケーションの種別をゲームとＰＶＲの２つにしたが、アプリケーションの種別は２つに限られることがなく、それ以上、以下でもよい。

また、サーマルエラーの発生履歴をログとして記録してもよい。その際、サーマルエラーの発生箇所、動作中のアプリケーションの種別なども記録することが望ましい。後にログに基づいて、システムの発熱要因などを詳細に解析することができ、設計の改良などに用いることができる。

また、サーマルエラーの発生を、たとえばネットワークによってその機器と接続された管理装置に知らせ、遠隔地の管理者による状態の把握を可能にするようにしてもよい。

また、ソフトウェアの動作内容の変更、ハードウェアの動作調整も、上記において説明した変更方式に限られることがない。

さらに、制御方式リストすなわちリアクションテーブル１１８の内容も、固定としなくてもよい。たとえば、ゲームアプリケーションの動作中にサーマルエラーが頻発する場合には、ゲームアプリケーションの動作中においてサーマルエラーが発生した際に、２つのステップの制御方式を同時に用いるようにするなど、より強くその動作を抑制するように制御方式リストを変更してもよい。

また、図２に示すコンピュータシステム５００において、制御対象をメインプロセッサ１０とグラフィックプロセッサ２０にし、それらの内部温度を発熱状態としたが、たとえば、プロセッサ表面、システムボード１００上の他の箇所にも温度センサを設け、各温度センサの平均温度も発熱状態に含むようにとしてもよい。

この場合において、発熱状態の制御としては、平均温度を下げるとともに、これらの測定場所に含まれる所定の場所の温度も閾値を超えないようにすることが望ましい。こうすることによって、ハードウェアの局部だけが熱くなること、すなわちホットスポットを防ぐことができる。

制御方式リストの例を示す図である。 本発明にかかる実施形態のコンピュータシステムを示す図である。 図２に示すコンピュータシステムにおけるソフトウェアスタックの構成を示す図である。 制御方式を規定するリアクションテーブルの例を示す図である。 図３に示す制御スタックにおける制御実行部の処理を示すフローチャートである。 ハードウェアの動作を調整するハードウェア制御処理を示すフローチャートである。 アプリケーションの動作内容を変更するソフトウェア制御処理を示すフロチャートである。

符号の説明

１０ メインプロセッサ、 ２０ グラフィックプロセッサ、 ３０ 温度センサ、 ４０ 送信部、 １００ システムボード、 １１０ 制御スタック、 １２０ システムＬＰＡＲ、 １３０ ユーティリティＬＰＡＲ、 １４０ ゲームＬＰＡＲ、 １５０ ＰＶＲＬＰＡＲ、 ２００ ソフトウェアスタック。

Claims (12)

1. コンピュータシステムのハードウェアにおける、発熱状態の制御対象となる対象部位の発熱状態を取得し、
   取得した発熱状態に応じて、該発熱状態を変化させるように、動作中のアプリケーションの動作内容を変更して前記対象部位の発熱状態を制御することを特徴とする発熱制御方法。
2. 前記制御は、取得した発熱状態に応じて、前記ハードウェアにおける、動作状態が前記対象部位の発熱状態に影響を与える部位の動作を調整することを含むことを特徴とする請求項１記載の発熱制御方法。
3. 前記対象部位がとりうる発熱状態毎の制御方式を規定する制御方式リストを保持し、
   取得した発熱状態に対応する制御方式を前記制御方式リストから取得し、取得した制御方式で前記制御を行うことを特徴とする請求項１または２記載の発熱制御方法。
4. コンピュータシステムのハードウェアにおける、発熱状態の制御対象となる対象部位の発熱状態を取得する熱検出部と、
   該熱検出部により取得された発熱状態に応じて、該発熱状態を変化させるように、動作中のアプリケーションの動作内容を変更する制御部とを備えることを特徴とする発熱制御装置。
5. 前記制御部は、前記熱検出部により取得された発熱状態に応じて、前記ハードウェアにおける、動作状態が前記対象部位の発熱状態に影響を与える部位の動作を調整する処理も行うことを特徴とする請求項４記載の発熱制御装置。
6. 前記対象部位がとりうる発熱状態毎の制御方式を規定する制御方式リストを保持する制御方式リスト保持部を備え、
   前記制御部は、前記熱検出部により取得された発熱状態に対応する制御方式を前記制御方式リストから取得し、取得した制御方式で前記制御を行うことを特徴とする請求項４または５記載の発熱制御装置。
7. 複数の種別のアプリケーションが同時に動作している場合において、各前記アプリケーションの種別を取得するアプリケーション種別取得部を備え、
   前記制御部は、該アプリケーション種別取得部により取得された種別の組合せに応じて、動作中のアプリケーションの動作内容を変更することを特徴とする請求項４から６のいずれか１項記載の発熱制御装置。
8. 各々のアプリケーションが、種別毎に優先度が付与されており、
   前記制御部は、動作中のアプリケーションの種別の優先度に応じて、優先度が低い種別のアプリケーションほど、その動作を抑制するように前記変更を行うことを特徴とする請求項７記載の発熱制御装置。
9. アプリケーションが実現する機能ごとに優先度が付与されており、
   前記制御部は、動作中のアプリケーションに対して、優先度が低い機能ほど、この機能を実現する部分の動作を抑制するように前記変更を行うことを特徴とする請求項４から８のいずれか１項記載の発熱制御装置。
10. 前記制御部は、前記熱検出部により検出された発熱状態が規定の正常状態の範囲を外れたときに、前記対象部位の発熱状態が前記範囲に戻るように前記変更または調整を行うものであり、
    前記変更または調整後、前記対象部位の発熱状態が前記範囲に戻ったときに、前記変更を取り消す処理または前記調整が行われたハードウェアの動作を元に戻す処理を行うことを特徴とする請求項４から９のいずれか１項記載の発熱制御装置。
11. 前記熱検出部により検出された発熱状態が規定の正常状態の範囲を外れたときに、ユーザに通知を行う通知部を備えることを特徴とする請求項４から１０のいずれか１項記載の発熱制御装置。
12. 前記通知部は、発熱状態が前記範囲を外れた頻度が一定の閾値を超えたときに前記通知を行うことを特徴とする請求項１１記載の発熱制御装置。
    

Images