(57)【要約】【課題】バッファのサイズを適切に決定することができる決定装置および決定方法を提供すること。【解決手段】実施形態に係る決定装置は、検出部と、決定部とを備える。検出部は、複数のアプリケーションを並列して処理可能なＣＰＵおよびＣＰＵの処理結果を一時的に格納するバッファを有する電子装置について、ＣＰＵの処理に伴う負荷を検出する。決定部は、検出部によって検出された負荷が高負荷であった場合、高負荷の状況を学習し、学習結果に基づいてアプリケーション毎にバッファのサイズを決定する。【選択図】図４
2020004230.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションを並列して処理可能なＣＰＵおよび前記ＣＰＵの処理結果を一時的に格納するバッファを有する電子装置について、前記ＣＰＵの処理に伴う負荷を検出する検出部と、
前記検出部によって検出された前記負荷が高負荷であった場合、当該高負荷の状況を学習し、学習結果に基づいて前記アプリケーション毎に前記バッファのサイズを決定する決定部と
を備えることを特徴とする決定装置。
【請求項２】
前記高負荷の状況を示す高負荷情報を履歴情報として記憶部に記憶する記憶処理部をさらに備え、
前記決定部は、
前記記憶部に記憶された前記履歴情報に基づいて前記バッファのサイズを決定すること
を特徴とする請求項１に記載の決定装置。
【請求項３】
前記履歴情報には、
前記高負荷の継続時間および前記高負荷の発生周期を示す情報が含まれ、
前記決定部は、
前記継続時間および前記発生周期に基づいて前記バッファのサイズを決定すること
を特徴とする請求項２に記載の決定装置。
【請求項４】
前記決定部は、
前記継続時間が前記発生周期の時間以下であった場合、当該継続時間に相当するサイズを前記バッファのサイズとして決定すること
を特徴とする請求項３に記載の決定装置。
【請求項５】
前記検出部は、
前記電子装置の現在位置を示す位置情報をさらに検出し、
前記記憶処理部は、
前記検出部が検出した前記位置情報を前記高負荷情報に対応付けて前記履歴情報として記憶し、
前記決定部は、
前記位置情報毎に前記バッファのサイズを決定すること
を特徴とする請求項２〜４のいずれか１つに記載の決定装置。
【請求項６】
前記検出部は、
前記ＣＰＵが現在処理中の前記アプリケーションの組み合わせを示す使用アプリ情報をさらに検出し、
前記記憶処理部は、
前記検出部が検出した前記使用アプリ情報を前記高負荷情報に対応付けて前記履歴情報として記憶し、
前記決定部は、
前記組み合わせ毎に前記バッファのサイズを決定すること
を特徴とする請求項２〜５のいずれか１つに記載の決定装置。
【請求項７】
前記複数のアプリケーションそれぞれの優先度に関する優先度情報を取得する取得部をさらに備え、
前記決定部は、
前記学習結果および前記優先度情報に基づいて前記バッファのサイズを決定すること
を特徴とする請求項１〜６のいずれか１つに記載の決定装置。
【請求項８】
複数のアプリケーションを並列して処理可能なＣＰＵおよび前記ＣＰＵの処理結果を一時的に格納するバッファを有する電子装置について、前記ＣＰＵの処理に伴う負荷を検出する検出工程と、
前記検出工程によって検出された前記負荷が高負荷であった場合、当該高負荷の状況を学習し、学習結果に基づいて前記アプリケーション毎に前記バッファのサイズを決定する決定工程と
を含むことを特徴とする決定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、決定装置および決定方法に関する。
【背景技術】
【０００２】
従来、例えば、複数のアプリケーションを並列して処理可能なＣＰＵ（Central  Processing  Unit）を備えた電子装置がある。また、かかる電子装置は、例えば、ＣＰＵの処理に伴う負荷が高い場合に、ＣＰＵの処理結果を一時的にバッファに格納して、アプリケーションの動作が遅延しないようにする技術がある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−２２０１１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の技術では、例えば、バッファのサイズが足りない場合、映像のカクツキや音切れ等が発生するおそれがある。また、バッファのサイズが不必要に大きいと、コストの増加や半導体チップの大型化を招くおそれがある。このように、従来は、バッファのサイズを適切に決定する点で改善の余地があった。
【０００５】
本発明は、上記に鑑みてなされたものであって、バッファのサイズを適切に決定することができる決定装置および決定方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決し、目的を達成するために、本発明に係る決定装置は、検出部と、決定部とを備える。前記検出部は、複数のアプリケーションを並列して処理可能なＣＰＵおよび前記ＣＰＵの処理結果を一時的に格納するバッファを有する電子装置について、前記ＣＰＵの処理に伴う負荷を検出する。前記決定部は、前記検出部によって検出された前記負荷が高負荷であった場合、当該高負荷の状況を学習し、学習結果に基づいて前記アプリケーション毎に前記バッファのサイズを決定する。
【発明の効果】
【０００７】
本発明によれば、バッファのサイズを適切に決定することができる。
【図面の簡単な説明】
【０００８】
【図１】図１は、実施形態に係る車載装置を備えた車両を示す図である。
【図２】図２は、実施形態に係る車載装置の構成を示す図である。
【図３】図３は、実施形態に係る決定方法の概要を示す図である。
【図４】図４は、実施形態に係る決定装置の構成を示すブロック図である。
【図５】図５は、履歴情報を示す図である。
【図６】図６は、実施形態に係る決定装置が実行する学習処理の処理手順を示すフローチャートである。
【図７】図７は、実施形態に係る決定装置が実行する決定処理の処理手順を示すフローチャートである。
【図８】図８は、変形例に係る履歴情報を示す図である。
【発明を実施するための形態】
【０００９】
以下、添付図面を参照して、本願の開示する決定装置および決定方法の実施形態を詳細に説明する。なお、この実施形態により本発明が限定されるものではない。なお、以下では、決定装置を有する車載装置を電子装置の一例として説明する。
【００１０】
まず、図１〜図３を用いて、実施形態に係る決定方法の概要について説明する。図１は、実施形態に係る車載装置を備えた車両を示す図である。図２は、実施形態に係る車載装置の構成を示す図である。図３は、実施形態に係る決定方法の概要を示す図である。
【００１１】
図１に示す車載装置Ｓは、いわゆるＥＣＵ（Electronic  Control  Unit）であり、各種車載器を電子制御する。車載器には、例えば、アクセル、ブレーキおよびステアリングといった走行系の電子機器や、ナビゲーション装置、オーディオ機器等といったマルチメディア機器等を含む。
【００１２】
また、図１に示すように、車載装置Ｓは、ＣＰＵ（Central  Processing  Unit）やメモリ等を結合して、１つの半導体チップに集約したＳｏＣ（System  on  Chip）を含んで構成される。具体的には、図１に示すように、ＳｏＣとして構成された車載装置Ｓは、車載器を制御するためのアプリケーションを複数格納しており、ＣＰＵが複数のアプリケーションを並列して処理可能となっている。
【００１３】
つまり、車載装置Ｓは、１つの半導体チップにより、複数の車載器を制御可能に構成される。これにより、各車載器を制御する専用ＩＣ（Integrated  Circuit）を実装する必要が無くなるため、車載装置Ｓの小型化に資することができる。
【００１４】
図２には、車載装置Ｓの構成を示している。図２に示すように、車載装置Ｓは、決定装置１と、ＣＰＵ２と、ＲＡＭ（Random  Access  Memory）３と、ＲＯＭ（Read  Only  Memory）４と、ＤＭＡＣ５と、通信Ｉ／Ｆ６とを有する。
【００１５】
決定装置１は、ＲＡＭ３の領域であるバッファ３２のサイズを決定するが、かかる点の詳細については後述する。
【００１６】
ＣＰＵ２は、ＲＯＭ４に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ４は、車載装置Ｓの起動時にＣＰＵ２によって実行されるブートプログラムや、車載装置Ｓのハードウェアに依存するプログラム等を格納する。また、ＲＯＭ４は、ＣＰＵ２によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス（Ｉ／Ｆ）６は、ネットワークを介して他の機器からデータを受信してＣＰＵ２や決定装置１へ送り、ＣＰＵ２や決定装置１が生成したデータを、ネットワークを介して他の機器へ送信する。
【００１７】
ＣＰＵ２は、通信Ｉ／Ｆ６を介して、ディスプレイやプリンタ等の周辺機器１００を制御する。ＣＰＵ２は、通信Ｉ／Ｆ６を介して、周辺機器１００からデータを取得する。また、ＣＰＵ２は、生成したデータを、通信Ｉ／Ｆ６を介して周辺機器１００へ出力する。
【００１８】
また、ＲＡＭ３は、ＣＰＵ２が実行する第１アプリ３１ａや第２アプリ３１ｂ等といったアプリケーション３１のプログラムが格納される領域と、第１アプリ用３２ａや第２アプリ用３２ｂ等のバッファ３２が格納される領域とを有する。バッファ３２は、例えば、リングバッファを採用可能であるが、リングバッファに限定されず、種々のバッファが採用されてもよい。
【００１９】
例えば、ＣＰＵ２は、ユーザの指示によりアプリケーション３１を読み出して処理を行い、その処理結果を周辺機器１００へ出力する。また、ＣＰＵ２は、アプリケーション３１の処理に伴う負荷が高い場合には、各アプリケーション３１に対応するバッファ３２に処理結果を一時的に格納する。
【００２０】
ＤＭＡＣ５は、バッファ３２に一時的に格納された処理結果を、ＤＭＡ（Direct  Memory  Access）転送する。つまり、ＤＭＡＣ５は、ＣＰＵ２に代わって周辺機器１００へ処理結果の転送を行う。これにより、ＣＰＵ２が転送処理を行わずにすむため、処理負荷が高くなることを抑制できる。
【００２１】
このように、バッファ３２にＣＰＵ２の処理結果を一時的に格納することで、ＣＰＵ２の処理負荷が高くなることを抑制できるため、バッファ３２のサイズ（容量）を適切に決定することが重要である。
【００２２】
しかしながら、従来は、バッファのサイズを適切に決定する点で改善の余地があった。例えば、バッファのサイズが足りない場合、映像のカクツキや音切れ等が発生するおそれがある。また、バッファのサイズが不必要に大きいと、コストの増加や半導体チップの大型化を招くおそれがある。
【００２３】
そこで、実施形態に係る決定方法では、ＣＰＵ２の実際の負荷の状況を学習して適切なバッファ３２のサイズを決定する。具体的には、実施形態に係る決定装置１は、まず、ＣＰＵ２の処理に伴う負荷を検出する。
【００２４】
図３には、検出した負荷の一例を示す。図３では、縦軸に負荷率、横軸に時間のグラフを示している。なお、負荷率とは、使用率とも呼ばれ、アプリケーション３１がＣＰＵ２の処理時間を占有している割合であり、負荷率が高い程、ＣＰＵ２の負荷が高いことを示している。つまり、図３に示す負荷率が１００％は、ＣＰＵ２が高負荷であることを示している。なお、負荷率が１００％の場合にＣＰＵ２が高負荷であるとしたが、例えば、負荷率が所定値（例えば、８０％）以上を高負荷としてもよい。
【００２５】
実施形態に係る決定装置１は、ＣＰＵ２が高負荷であった場合、高負荷の状況を学習し、学習結果に基づいてアプリケーション３１毎にバッファ３２のサイズを決定する。
【００２６】
図３に示す例では、ＣＰＵ２は、１周期あたりの高負荷の継続時間は１００ｍｓ（ミリ秒、以下同様）であり、高負荷の発生周期は１００ｍｓである。かかる場合、実施形態に係る決定装置１は、バッファ３２のサイズを１００ｍｓに相当するサイズとして決定する。
【００２７】
つまり、実施形態に係る決定装置１は、ＣＰＵ２がアプリケーション３１を所定の条件で使用した場合における高負荷の継続時間および高負荷の発生周期を学習し、学習した内容を充足するようなバッファ３２のサイズを学習結果として決定する。
【００２８】
なお、バッファ３２の決定方法については、上記した方法以外にも種々の方法が適用できるが、かかる点については後述する。
【００２９】
このように、実施形態に係る決定方法では、ＣＰＵ２の実際の高負荷の状況を学習することによって、バッファ３２のサイズを適切に決定することができる。
【００３０】
なお、図２では、決定装置１とＣＰＵ２とが別体で構成される場合を示しているが、例えば、ＣＰＵ２が決定装置１の機能を有してもよい、つまり、ＣＰＵ２と決定装置１とが一体となった構成であってもよい。
【００３１】
次に、図４を参照して、実施形態に係る決定装置１の構成について詳細に説明する。図４は、実施形態に係る決定装置１の構成を示すブロック図である。図４に示すように、実施形態に係る決定装置１は、制御部２０と、記憶部３０とを備える。
【００３２】
制御部２０は、検出部２１０と、取得部２２０と、記憶処理部２３０と、決定部２４０とを備える。記憶部３０は、履歴情報３１０を記憶する。
【００３３】
ここで、決定装置１は、たとえば、ＣＰＵ、ＲＯＭ、ＲＡＭ、データフラッシュ、入出力ポートなどを有するコンピュータや各種の回路を含む。
【００３４】
コンピュータのＣＰＵは、たとえば、ＲＯＭに記憶されたプログラムを読み出して実行することによって、制御部２０の検出部２１０、取得部２２０、記憶処理部２３０および決定部２４０として機能する。
【００３５】
また、制御部２０の検出部２１０、取得部２２０、記憶処理部２３０および決定部２４０の少なくともいずれか一つまたは全部をＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）等のハードウェアで構成することもできる。
【００３６】
また、記憶部３０は、たとえば、ＲＡＭやデータフラッシュに対応する。ＲＡＭやデータフラッシュは、履歴情報３１０や、各種プログラムの情報等を記憶することができる。なお、決定装置１は、有線や無線のネットワークで接続された他のコンピュータや可搬型記録媒体を介して上記したプログラムや各種情報を取得することとしてもよい。
【００３７】
制御部２０は、ＣＰＵ２の処理に伴う負荷を検出し、ＣＰＵ２が高負荷である場合、高負荷の状況を学習し、学習結果に基づいてアプリケーション３１毎にバッファ３２のサイズを決定する。
【００３８】
検出部２１０は、ＣＰＵ２の処理に伴う負荷を検出する。例えば、検出部２１０は、上記したように、負荷率や使用率を負荷として検出する。あるいは、検出部２１０は、ＣＰＵ２に対して所定のテストタスクの実行を要求し、その応答速度により負荷を検出してもよい。
【００３９】
また、検出部２１０による検出処理のタイミングは、任意である。例えば、検出部２１０は、所定のアプリケーション３１が実行中の場合にのみ負荷の検出を行ってもよい。つまり、実行中のアプリケーション３１が無い場合、検出処理を行わない。
【００４０】
あるいは、検出部２１０は、複数のアプリケーション３１が並列して処理されている場合や、やり取りするデータ量が比較的多いアプリケーション３１が処理されている場合に、検出処理を行ってもよい。つまり、検出部２１０は、ＣＰＵ２が高負荷となる可能性が高い場合に限って、検出処理を行ってもよい。
【００４１】
また、検出部２１０は、車載装置Ｓの現在位置を示す位置情報を検出する。位置情報の検出は、例えば、ＧＰＳ（Global  Positioning  System）を利用して位置情報を取得してもよく、あるいは、図示しないナビゲーション装置等が取得した位置情報を取得してもよい。
【００４２】
また、検出部２１０は、ＣＰＵ２が現在処理中のアプリケーション３１の組み合わせを示す使用アプリ情報を検出する。
【００４３】
取得部２２０は、複数のアプリケーション３１それぞれの優先度に関する優先度情報を取得する。例えば、「優先度が高い」アプリケーション３１とは、ユーザの使用頻度が高いアプリケーション３１や、電話（ハンズフリー通話）等の割り込み系のアプリケーション３１、緊急通報等の緊急性の高いアプリケーション３１等を含む。
【００４４】
具体的には、例えば、アイコン表示された各アプリケーション３１の選択回数の統計をとり、選択回数が多いほど、使用頻度が高いとして優先度を高くする。あるいは、予めユーザから優先すべきアプリケーション３１の指示を受け付けて、かかるアプリケーション３１の優先度を高くしてもよい。
【００４５】
記憶処理部２３０は、検出部２１０によって検出された高負荷の状況を示す高負荷情報を履歴情報３１０として記憶部３０に記憶する処理を行う。例えば、記憶処理部２３０は、ＣＰＵ２が高負荷となった継続時間や、高負荷の発生周期を含む高負荷情報を履歴情報３１０として記憶する。また、記憶処理部２３０は、上記した位置情報や使用アプリ情報等を対応付けた高負荷情報を履歴情報３１０として記憶する。なお、履歴情報３１０の詳細については後述する。
【００４６】
決定部２４０は、検出部２１０によって検出された負荷が高負荷であった場合に、高負荷の状況を学習し、学習結果に基づいてアプリケーション３１毎にバッファ３２のサイズを決定する。
【００４７】
例えば、決定部２４０は、記憶処理部２３０によって記憶された履歴情報３１０に基づいて学習し、バッファ３２のサイズを決定する。このように、過去の高負荷の状況からバッファ３２のサイズを決定することで、より適切なバッファ３２のサイズを決定することができる。ここで、図５を用いて、履歴情報３１０について説明する。
【００４８】
図５は、履歴情報３１０を示す図である。図５では、「テレビ」、「ラジオ」および「ハンズフリー」として動作するアプリケーション３１を例に挙げて説明する。図５に示すように、履歴情報３１０には、「位置情報」、「使用アプリ情報」、「継続時間」および「発生周期」といった項目が含まれる。
【００４９】
「位置情報」は、検出部２１０が検出した位置情報に属するエリアの情報である。かかるエリアは、例えば、都道府県や市区町村、あるいは、ＣＰＵ２の負荷が高くなる領域（例えば、電波強度が弱く、受信感度を高くするアプリケーション３１をＣＰＵ２がデフォルトで実行しなければいけない領域）や、電波の受信状態が良好なエリア、ノイズエリア（マルチパスが発生しているエリア等）等である。
【００５０】
「使用アプリ情報」は、上記した使用アプリ情報であり、負荷検出時に使用していたアプリケーション３１の組み合わせである。「継続時間」は、高負荷の状況が継続した時間である。「発生周期」は、高負荷の発生する周期である。
【００５１】
図５に示す履歴情報３１０では、例えば、位置情報「Ａエリア」において、「テレビ」、「ラジオ」および「ハンズフリー」を使用した場合、高負荷の状態が１００ｍｓ継続し、それが１００ｍｓ周期で発生することを示す。
【００５２】
決定部２４０は、履歴情報３１０に基づいてバッファ３２のサイズを決定するが、決定する場合に、継続時間が発生周期の時間以下であるか否かで決定するバッファ３２のサイズが異なる。つまり、決定部２４０は、継続時間および発生周期に基づいてバッファ３２のサイズを決定する。
【００５３】
まず、継続時間が発生周期の時間以下である場合について説明する。ここでは、図５の位置情報「Ａエリア」を例に挙げて説明する。
【００５４】
「Ａエリア」について、決定部２４０は、「テレビ」、「ラジオ」および「ハンズフリー」が使用された場合、それぞれのアプリケーション３１のバッファ３２のサイズを継続時間である１００ｍｓに相当するサイズに決定する。
【００５５】
また、「Ａエリア」について、決定部２４０は、「ラジオ」および「ハンズフリー」が使用された場合、それぞれのアプリケーション３１のバッファ３２のサイズを継続時間である５０ｍｓに相当するサイズに決定する。
【００５６】
「Ａエリア」について、決定部２４０は、「ハンズフリー」のみが使用された場合、それぞれのアプリケーション３１のバッファ３２のサイズを継続時間である２５ｍｓに相当するサイズに決定する。
【００５７】
つまり、決定部２４０は、継続時間が発生周期の時間以下である場合、継続時間分の処理結果のデータを格納可能なサイズに決定する。これにより、高負荷時に格納されたバッファ３２のデータを、高負荷時ではない期間にすべて出力できるため、ＣＰＵ２の動作遅れが発生することを防止することができる。
【００５８】
さらに、上記したように、決定部２４０は、位置情報毎にバッファ３２のサイズを決定するため、位置情報に合わせて適切なバッファ３２のサイズを決定できる。
【００５９】
さらに、上記したように、決定部２４０は、使用アプリの組み合わせ毎にバッファ３２のサイズを決定するため、使用アプリの組み合わせに合わせて適切なバッファ３２のサイズを決定できる。
【００６０】
次に、継続時間が発生周期の時間を超えた場合について説明する。ここでは、図５の位置情報「Ｃエリア」について、「テレビ」、「ラジオ」および「ハンズフリー」が使用された場合を例に挙げて説明する。つまり、継続時間が１００ｍｓ、発生周期が５０ｍｓの場合である。
【００６１】
決定部２４０は、継続時間が発生周期の時間を超えた場合、継続時間よりも長い時間のデータを格納できるバッファ３２のサイズにする必要がある。つまり、継続時間１００ｍｓよりも長い時間のデータを格納可能なサイズにする必要がある。
【００６２】
仮に、継続時間と同じ時間のバッファ３２のサイズとした場合、高負荷時にバッファ３２に格納したデータを高負荷時ではない時間にすべて処理できないため、高負荷の状況が複数周期繰り返された場合、バッファ３２が空になり、結果、ＣＰＵ２の動作が遅れることとなる。
【００６３】
そのため、決定部２４０は、継続時間が発生周期の時間を超えた場合、継続時間よりも長い時間のデータを格納できるバッファ３２のサイズに決定する。このとき決定するバッファ３２のサイズは、例えば、過去に、高負荷の状況が何周期繰り返されたかを計測しておき、かかる周期数に基づいてバッファ３２のサイズを決定することが好ましい。
【００６４】
これにより、アプリケーション３１を終了するまでの間に、バッファ３２が空になってＣＰＵ２の動作が遅れることを防止できる。このように、決定部２４０は、継続時間および発生周期に基づいてバッファ３２のサイズを決定することで、より適切なバッファ３２のサイズを決定できる。
【００６５】
なお、決定部２４０は、履歴情報３１０の中に、対応する継続時間および発生周期が存在しない（まだ、学習できていない）場合には、例えば、バッファ３２のサイズをデフォルト値に設定する。
【００６６】
なお、決定部２４０は、継続時間が発生周期の時間を超えた場合、ユーザに対して、アプリケーション３１の停止を通知（例えば、コーション表示）してもよい。例えば、決定部２４０は、ラジオやテレビの電波強度が比較的弱いエリアでは、電波が弱い旨を通知するとともに、ラジオやテレビのアプリケーション３１を強制的に終了させたり、あるいは、他のアプリケーション３１を提案したりしてもよい。
【００６７】
つまり、決定部２４０は、高負荷となる可能性が高いアプリケーション３１を停止させることで、ＣＰＵ２の負荷を下げる。これにより、高負荷によりＣＰＵ２の動作が遅くなることを防ぐことができる。
【００６８】
また、決定部２４０は、履歴情報３１０に加えて、取得部２２０が取得したアプリケーション３１の優先度情報に基づいてバッファ３２のサイズを決定してもよい。
【００６９】
具体的には、決定部２４０は、履歴情報３１０に基づいて決定したバッファ３２のサイズについて、優先度が高いアプリケーション３１ほど、バッファ３２のサイズを小さくする。一方、優先度が低いアプリケーション３１ほど、バッファ３２のサイズを大きくする。
【００７０】
これにより、優先度が高いアプリケーション３１の応答性を向上させることができる。つまり、ユーザが頻繁に使用するアプリケーション３１や、割り込み系のアプリケーション３１、緊急性の高いアプリケーション３１の応答性を向上させることができるため、ユーザの満足度を向上させることができる。
【００７１】
次に、図６を用いて、実施形態に係る決定装置１が実行する学習処理の処理手順について説明する。図６は、実施形態に係る決定装置１が実行する学習処理の処理手順を示すフローチャートである。
【００７２】
図６に示すように、まず、検出部２１０は、車載装置Ｓの現在位置を示す位置情報を検出し、決定部２４０は、検出された現在の位置情報で使用アプリの電波が良好であるか否かを判定する（ステップＳ１０１）。
【００７３】
決定部２４０は、使用アプリの電波が良好であった場合（ステップＳ１０１，Ｙｅｓ）、ＣＰＵ２が高負荷の状況であるか否かを判定する（ステップＳ１０２）。決定部２４０は、ＣＰＵ２が高負荷の状況であった場合（ステップＳ１０２，Ｙｅｓ）、高負荷の状況を示す高負荷情報を履歴情報３１０として記憶し（ステップＳ１０３）、学習処理を終了する。
【００７４】
一方、ステップＳ１０１において、決定部２４０は、現在の位置情報で使用アプリの電波が良好でなかった場合（ステップＳ１０１，Ｎｏ）、ユーザに対してコーション表示して、アプリケーション３１を停止し（ステップＳ１０４）、処理を終了する。
【００７５】
また、ステップＳ１０２において、決定部２４０は、ＣＰＵ２が高負荷の状況でなかった場合（ステップＳ１０２，Ｎｏ）、処理をステップＳ１０１へ移行する。
【００７６】
次に、図７を用いて、実施形態に係る決定装置１が実行する決定処理の処理手順について説明する。図７は、実施形態に係る決定装置１が実行する決定処理の処理手順を示すフローチャートである。
【００７７】
まず、図７に示すように、決定部２４０は、履歴情報３１０が記憶部３０にあるか否かを判定する（ステップＳ２０１）。決定部２４０は、記憶部３０に履歴情報３１０があった場合（ステップＳ２０１，Ｙｅｓ）、履歴情報３１０を学習して、バッファ３２のサイズを決定し（ステップＳ２０２）、処理を終了する。
【００７８】
一方、決定部２４０は、記憶部３０に履歴情報３１０がなかった場合（ステップＳ２０１，Ｎｏ）、バッファ３２のサイズをデフォルト値として設定し（ステップＳ２０３）、処理を終了する。
【００７９】
上述してきたように、実施形態に係る決定装置１は、検出部２１０と、決定部２４０とを備える。検出部２１０は、複数のアプリケーション３１を並列して処理可能なＣＰＵ２およびＣＰＵ２の処理結果を一時的に格納するバッファ３２を有する車載装置Ｓ（電子装置の一例）について、ＣＰＵ２の処理に伴う負荷を検出する。決定部２４０は、検出部２１０によって検出された負荷が高負荷であった場合、当該高負荷の状況を学習し、学習結果に基づいてアプリケーション３１毎にバッファ３２のサイズを決定する。これにより、バッファ３２のサイズを適切に決定することができる。
【００８０】
なお、上述した実施形態に係る決定部２４０の決定処理は一例であって、種々の決定方法を採用可能である。決定部２４０の他の決定処理について図８を用いて説明する。
【００８１】
図８は、変形例に係る履歴情報３１０を示す図である。図８に示すように、変形例に係る履歴情報３１０は、「位置情報」、「使用日時」、「使用アプリ情報」、「継続時間」、「発生周期」といった項目を有する。
【００８２】
「使用日時」は、アプリケーション３１が使用された日時を示す情報である。つまり、図８に示すように、位置情報および使用アプリ情報が同じであっても、日時毎に継続時間および発生周期が異なる。
【００８３】
かかる場合、決定部２４０は、例えば、最も悪い状況に基づいてバッファ３２のサイズを決定する。つまり、決定部２４０は、バッファ３２のサイズを、継続時間１５０ｍｓに相当するサイズにする。これにより、ＣＰＵ２の動作が遅れることを高確率で防止することができる。
【００８４】
あるいは、決定部２４０は、すべての継続時間（１００ｍｓ、１５０ｍｓおよび７５ｍｓ）の平均値をバッファ３２のサイズとしてもよい。あるいは、決定部２４０は、最新の継続時間（７５ｍｓ）をバッファ３２のサイズとしてもよい。
【００８５】
さらなる効果や変形例は、当業者によって容易に導き出すことができる。このため、本発明のより広範な態様は、以上のように表しかつ記述した特定の詳細および代表的な実施形態に限定されるものではない。したがって、添付の特許請求の範囲およびその均等物によって定義される総括的な発明の概念の精神または範囲から逸脱することなく、様々な変更が可能である。
【符号の説明】
【００８６】
１    決定装置
２    ＣＰＵ
３    ＲＡＭ
４    ＲＯＭ
５    ＤＭＡＣ
６    通信Ｉ／Ｆ
２０    制御部
３０    記憶部
３１    アプリケーション
３２    バッファ
１００    周辺機器
２１０    検出部
２２０    取得部
２３０    記憶処理部
２４０    決定部
３１０    履歴情報
Ｓ    車載装置
【図１】
2020004230.tif 000003
【図２】
2020004230.tif 000004
【図３】
2020004230.tif 000005
【図４】
2020004230.tif 000006
【図５】
2020004230.tif 000007
【図６】
2020004230.tif 000008
【図７】
2020004230.tif 000009
【図８】
2020004230.tif 000010