JP2020083170A - 調光ガラス制御装置 - Google Patents

Abstract

【課題】車両に搭載される調光ガラス制御装置において、日射による車室内への入熱量をコントロールすることで、車室内の温度を適切に調整しつつ、燃費の悪化を抑える。【解決手段】電圧ＯＮにより暗色状態から透明状態へ切り替わる調光ガラスの制御装置である。車室内への入熱が必要か否かを判定する判定部（Ｓ１）と、クラウドサーバから取得した日射量Ｓｒｃの推移に基づいて積算入熱量ＩＨＩを予測する予測部（Ｓ３）と、車室内温度Ｔｉと目標車室内温度Ｔｔとの温度差を所定値ＰＶ以下にするのに必要な必要入熱量ＮＨＩを取得する取得部（Ｓ４）とを備えている。暗色状態でも積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達する場合、または、日射入熱量が電圧ＯＮによる消費電力よりも小さい場合には、調光ガラスへの電圧をＯＦＦにする一方、それ以外の場合には、積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達するまで調光ガラスへの電圧をＯＮにする。【選択図】図６

Description

本発明は、ウィンドガラスとして調光ガラスを備える車両に搭載される調光ガラス制御装置に関するものである。

ウィンドガラスとして、電圧を印加することで光透過率が低い状態から高い状態へ切り替わる調光ガラスを備える車両では、日射量に応じて調光ガラスの光透過率を制御することが従来から行われている。

例えば特許文献１には、日射センサにより昼間であることが判断された際に、暖房時の設定温度と車室内温度との差に基づいて、制御手段により調光ガラスの透過率を調整する電動車両の空調制御装置が開示されている。

特開２０１８−１４４７５２号公報

上記特許文献１のものによれば、車室内を昇温させる際に、例えば調光ガラスの透過率を高くし、日光を車室に入れて体感温度を高くしたり、車室の温度の昇温を補助したりすることで、消費電力を抑制することができるとされている。

しかしながら、特許文献１のもののように、日射センサを用いて調光ガラスの透過率を調整する制御方法ないし制御装置には以下のような問題がある。

すなわち、日射センサは、あくまで現在（検出時）の日射量しか検出できないことから、検出時以降の日射量や日照時間（日射量の推移）を予測することは困難である。このため、日射量の推移に照らせば、例えば調光ガラスの光透過率が低い状態でも、日射による車室内への入熱量を十分に確保することができる場合にも、調光ガラスに電圧を印加することで無駄な電力を消費してしまい、燃費が悪化するという問題がある。

また、例えば、電圧を印加して調光ガラスを光透過率が高い状態とし、暖房時の設定温度が車室内温度に到達したときに、電圧の印加を終了して調光ガラスを光透過率が低い状態としても、その後の光透過率が低い状態での入熱により、車室内の温度が予想以上に高くなってしまうケースも想定される。この場合には、暖房時にもかかわらず、逆に車室内を冷房する必要が生じるため、やはり燃費が悪化するという問題がある。

本発明はかかる点に鑑みてなされたものであり、その目的とするところは、調光ガラスを備える車両に搭載される調光ガラス制御装置において、日射による車室内への入熱量をコントロールすることで、車室内の温度を適切に調整しつつ、燃費の悪化を抑える技術を提供することにある。

前記目的を達成するため、本発明に係る調光ガラス制御装置では、クラウドサーバから取得した日射量の推移に応じて、調光ガラスへの電圧のＯＮ／ＯＦＦを制御するようにしている。

具体的には、本発明は、ウィンドガラスとして、電圧を印加することで光透過率が低い状態から高い状態へ切り替わる調光ガラスを備える車両に搭載される調光ガラス制御装置を対象としている。

そして、この調光ガラス制御装置は、車室内の温度と目標車室内温度との温度差に基づいて、車室内への入熱が必要か否かを判定する判定部と、上記判定部により入熱が必要と判定された場合に、クラウドサーバから取得した日射量の推移に基づいて、入熱が必要と判定されてからの経過時間に応じた、日射による車室内への積算入熱量を予測する予測部と、車室内の温度と上記目標車室内温度と外気温度とに基づいて算出される、車室内の温度と当該目標車室内温度との温度差を所定値以下にするために必要な必要入熱量を取得する取得部と、を備え、上記調光ガラスの光透過率が低い状態でも、入熱が必要と判定されてから所定時間までに積算入熱量が必要入熱量に到達する場合、または、日射による車室内への入熱量が、上記調光ガラスの光透過率を高い状態にするための消費電力よりも小さい場合には、上記調光ガラスに電圧を印加しない一方、それ以外の場合には、積算入熱量が必要入熱量に到達するまで、上記調光ガラスに電圧を印加することを特徴とするものである。

この構成によれば、判定部により入熱が必要と判定されることを前提として、調光ガラスへの電圧の印加が行われるので、換言すると、入熱が必要ではないと判定された場合（例えば冷房時）には、調光ガラスへ電圧を印加しないので、冷房時に太陽光を積極的に取り込むことによる無駄な電力消費を抑えることができる。

そうして、（Ａ）調光ガラスの光透過率が低い状態でも、予測される積算入熱量が必要入熱量に到達する場合、換言すると、光透過率が低い状態でも、日射による車室内への入熱量を十分に確保することができる場合には、たとえ判定部により入熱が必要と判定されたとしても、調光ガラスに電圧を印加しないので、無駄な電力消費を抑えることができる。

また、（Ｂ）例えば曇りや夜間など、日射による車室内への入熱量が、調光ガラスの光透過率を高い状態にするための消費電力よりも小さい場合には、たとえ判定部により入熱が必要と判定されたとしても、調光ガラスに電圧を印加しないので、効率の悪い電力消費を抑えることができる。

これらに対し、（Ａ）または（Ｂ）以外の場合には、調光ガラスに電圧を印加して調光ガラスを光透過率が高い状態とすることにより、太陽光を積極的に取り込んで車室内の温度を上昇させることができ、これにより、車室内の温度を適切に調整しつつ、暖房時の動力を低減して燃費の向上を図ることができる。しかも、積算入熱量が必要入熱量に到達するまで、調光ガラスへ電圧を印加することから、換言すると、積算入熱量が必要入熱量に到達すれば、調光ガラスへの電圧の印加を終了することから、車室内の温度が予想以上に高くなってしまうのを抑えることができ、これにより、車室内を冷やすことで燃費が悪化するのを抑えることができる。

以上説明したように、本発明に係る調光ガラス制御装置によれば、日射による車室内への入熱量をコントロールすることで、車室内の温度を適切に調整しつつ、燃費の悪化を抑えることができる。

本発明の実施形態に係る車両を模式的に示す図である。 ルーフウィンドガラスを模式的に示す斜視図であり、同図（ａ）は暗色状態を示し、同図（ｂ）は透明状態を示す。 車室内の温度と目標車室内温度との温度差と、必要入熱量との関係を模式的に示す制御マップ図である。 積算入熱量の時間推移の一例を示すグラフ図である。 積算入熱量の時間推移の一例を示すグラフ図である。 調光ガラス制御の一例を示すフローチャートである。

以下、本発明を実施するための形態を図面に基づいて説明する。

−車両の全体構成−
図１は、本実施形態に係る車両１を模式的に示す図である。この車両１は、ルーフウィンドガラス３によって車体ルーフ５（図２参照）の一部が構成されるものである。車両１は、図１に示すように、ＥＣＵ（Electric Control Unit）１０と、室温センサ１１と、外気温センサ１３と、日射センサ１５と、操作パネル１７と、ＧＰＳ装置２０と、ネットワークアクセスデバイス３０と、を備えている。

ＥＣＵ１０は、例えばＣＰＵ（Central Processing Unit）、ＣＰＵが実行するプログラムおよびマップ等を予め記憶したＲＯＭ（Read Only Memory）、ＣＰＵが必要に応じてデータを一時的に格納するＲＡＭ（Random Access Memory）、電源が遮断されている間もデータを保持するバックアップＲＡＭ等を備えた所謂マイクロコンピュータを含んでいる。ＣＰＵはＲＡＭの一時記憶機能を利用しつつ予めＲＯＭに記憶されたプログラムに従って信号処理を行うことにより車両１の各種制御を実行する。

ＥＣＵ１０には、運転席の近傍等に設置された室温センサ１１が検出した車室７（図２参照）内の温度（以下、「車室内温度」ともいう。）Ｔｉを表す信号や、フロントグリル（図示せず）周辺等に装着される外気温センサ１３が検出した外気温度Ｔｏを表す信号や、インストゥルメントパネル（図示せず）等に配置された日射センサ１５が検出した日射量Ｓｒｓを表す信号等がそれぞれ入力される。また、ＥＣＵ１０には、操作パネル１７の操作によって乗員が設定した目標車室内温度Ｔｔを表す信号も入力されるようになっている。さらに、ＥＣＵ１０には、ＧＰＳ人工衛星と通信して車両１の周囲状況や位置情報等の種々の情報を取得するＧＰＳ装置２０から、車両１の現在地情報が入力されるようになっている。

ネットワークアクセスデバイス３０は、クラウドサーバ４０等の外部のサーバや、他の車両６０に搭載されたネットワークアクセスデバイス等と、携帯電話網やインターネット網といった通信網を介して通信可能に構成されている。ネットワークアクセスデバイス３０は、ＥＣＵ１０と接続されており、これにより、ネットワークアクセスデバイス３０がクラウドサーバ４０や、オペレーションセンター５０のサーバや、他の車両６０のネットワークアクセスデバイス等から取得した情報がＥＣＵ１０に入力されるとともに、ＥＣＵ１０が各種センサやＧＰＳ装置２０等から取得した情報がネットワークアクセスデバイス３０を介してオペレーションセンター５０のサーバ等に送信されるようになっている。

例えば、車両１が駐車した場合に、ＧＰＳ装置２０からＥＣＵ１０に入力された車両１の現在地（駐車位置）情報が、ネットワークアクセスデバイス３０を介して、クラウドサーバ４０に送信されると、クラウドサーバ４０から、車両１が駐車した地域における天候情報（日射量Ｓｒｃの推移等）が、ネットワークアクセスデバイス３０を介して、ＥＣＵ１０に入力されるようになっている。

また、例えば、駐車した車両１から離れた位置に居る乗員が、スマートフォン７０等でオペレーションセンター５０のサーバへ出発時刻を送信すれば、オペレーションセンター５０のサーバから、ネットワークアクセスデバイス３０を介して、駐車している車両１のＥＣＵ１０へ出発時刻等が入力されるようになっている。

さらに、ＥＣＵ１０は、車両１の周辺を走行している他の車両６０のネットワークアクセスデバイスやオペレーションセンター５０のサーバ等から、他の車両６０の車室内温度を読み取り、車両１が現在いる地域における「快適な車室内温度Ｔｔｃ」を算出したり、「快適な車室内温度Ｔｔｃ」をオペレーションセンター５０のサーバ等から取得したりするように構成されている。

−調光ガラス−
図２は、ルーフウィンドガラス３を模式的に示す斜視図であり、同図（ａ）は暗色状態を示し、同図（ｂ）は透明状態を示す。車両１では、ルーフウィンドガラス３として、電圧を印加することで、光透過率が低い状態から光透過率が高い状態へ切り替わる調光ガラス３が用いられている。より詳しくは、調光ガラス３は、電圧が印加されていない場合には、図２（ａ）に示すように、暗色状態（光透過率が低い状態）になる一方、電圧が印加された場合には、図２（ｂ）に示すように、透明状態（光透過率が高い状態）になる。なお、以下では、調光ガラス３に電圧を印加しないことを「電圧をＯＦＦする」ともいい、調光ガラス３に電圧を印加することを「電圧をＯＮする」ともいう。

本実施形態の車両１では、ルーフウィンドガラス３の暗色状態と透明状態との切替えは、ＥＣＵ１０によって実行される。このように、ＥＣＵ１０が、ルーフウィンドガラス３を暗色状態と透明状態とに切替えることで、車両１では燃費の悪化を抑えることが可能となっている。例えば、日差しが強い日における冷房時に、図２（ａ）に示すように、ルーフウィンドガラス３を暗色状態にすれば、日射による車室７内への入熱量（以下、日射入熱量ともいう。）が低減され、その分、冷房に要する動力が低減されることから、燃費の悪化を抑えることができる。また、例えば日差しが強い日における暖房時に、図２（ｂ）に示すように、ルーフウィンドガラス３を透明状態にすれば、日射による車室７内への入熱を積極的に取り入れ、その分、暖房に要する動力が低減されることから、燃費の悪化を抑えることができる。

−調光ガラス制御−
次に、ＥＣＵ１０が実行する調光ガラス制御について説明するが、それに先立ち、本発明を分かり易くするために、従来の調光ガラス制御について説明する。

本実施形態の車両１と同様に、日射センサを備えた従来の車両では、日射センサにより昼間であることが判断された際に、暖房時の設定温度と車室内温度との差に基づいて、調光ガラスの透過率を調整する制御を行うものがある。

もっとも、日射センサは、あくまで現在（検出時）の日射量しか検出できないことから、検出時以降の日射量や日照時間（日射量の推移）を予測することは困難である。このため、日射量の推移に照らせば、例えば調光ガラスの暗色状態でも、日射による車室内への入熱量を十分に確保することができる場合にも、調光ガラスに電圧をＯＮすることにより無駄な電力を消費してしまい、燃費が悪化するケースがある。

また、電圧ＯＮにより調光ガラスを透明状態とし、暖房時の設定温度が車室内温度に到達したときに、電圧をＯＦＦにして調光ガラスを暗色状態としても、その後の暗色状態での入熱により、車室内の温度が予想以上に高くなってしまうケースも想定される。この場合には、暖房時にもかかわらず、逆に車室内を冷房する必要が生じるため、やはり燃費が悪化するケースがある。

そこで、本実施形態では、クラウドサーバ４０から取得した日射量Ｓｒｃの推移に応じて、調光ガラス３への電圧ＯＮ／ＯＦＦを制御するようにしている。

具体的には、（１）車室内温度Ｔｉと目標車室内温度Ｔｔとの温度差ΔＴに基づいて、車室７内への入熱が必要か否かを判定し、（２）入熱が必要と判定（肯定判定）された場合に、クラウドサーバ４０から取得した日射量Ｓｒｃの推移に基づいて、肯定判定されてからの経過時間に応じた、日射による車室７内への積算入熱量ＩＨＩを予測するとともに、（３）温度差ΔＴを所定値ＰＶ以下にするために必要な必要入熱量ＮＨＩを取得するようにＥＣＵ１０を構成している。

そうして、（４−１）調光ガラス３が暗色状態でも、肯定判定から所定時間ＰＴまでに積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達する場合、または、（４−２）日射入熱量が、調光ガラス３を透明状態にするための消費電力よりも小さい場合には、調光ガラス３への電圧をＯＦＦにする一方、（５）それ以外の場合には、積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達するまで、調光ガラス３への電圧をＯＮにするようにＥＣＵ１０を構成している。

以下、このような制御について詳細に説明する。なお、以下では車両１が駐車した場合を想定して説明を行う。

先ず、ＥＣＵ１０は、スタートスイッチ（図示せず）等からの信号に基づき、車両１が駐車したと判定した場合には、（１）車室内温度Ｔｉと目標車室内温度Ｔｔとの温度差ΔＴに基づいて、車室７内への入熱が必要か否かを判定する。具体的には、ＥＣＵ１０は、室温センサ１１が検出した車室内温度Ｔｉと、乗員が設定した目標車室内温度Ｔｔとの温度差ΔＴが、ΔＴ（＝目標車室内温度Ｔｔ−車室内温度Ｔｉ）＜０なら、冷房時であり車室７内への入熱が不要と判定（否定判定）する。この場合には、ＥＣＵ１０は、運転時または停車時（駐車時を含む）のいずれにおいても、調光ガラス３への電圧をＯＦＦにし、調光ガラス３を暗色状態にする。これにより、日射入熱量が低減され、その分、冷房に要する動力が低減されることから、燃費の悪化を抑えることができる。

これに対し、ＥＣＵ１０は、車室内温度Ｔｉと目標車室内温度Ｔｔとの温度差ΔＴが、ΔＴ（＝目標車室内温度Ｔｔ−車室内温度Ｔｉ）≧設定値Ａ（Ａは０または正の数）なら、暖房時であり車室７内への入熱が必要と判定（肯定判定）する。例えば、設定値Ａを０に設定した場合には、ＥＣＵ１０は、目標車室内温度Ｔｔ≧車室内温度Ｔｉなら肯定判定する。また、ハンチング防止の観点から、設定値Ａを正の数に設定した場合には、車室内温度Ｔｉが目標車室内温度Ｔｔよりも、Ａ以上低ければ、暖房時であり車室７内への入熱が必要と判定（肯定判定）する。

なお、目標車室内温度Ｔｔは、操作パネル１７の操作によって乗員が設定したものに限らず、例えば、車両１の周辺を走行している他の車両６０の車室内温度に基づいて算出された、車両１が現在いる地域における「快適な車室内温度Ｔｔｃ」を採用してもよい。

次いで、ＥＣＵ１０は、（２）肯定判定された場合に、クラウドサーバ４０から取得した日射量Ｓｒｃの推移に基づいて、肯定判定されてからの経過時間に応じた、日射による車室７内への入熱量の積算値である積算入熱量ＩＨＩを予測する。具体的には、ＥＣＵ１０は、ＧＰＳ装置２０から入力された車両１の現在地（駐車位置）情報を、ネットワークアクセスデバイス３０を介して、クラウドサーバ４０に送信し、クラウドサーバ４０から、車両１の現在地における天候情報（日射量Ｓｒｃの推移）を、ネットワークアクセスデバイス３０を介して取得する。

もっとも、車両１の現在地（駐車位置）が屋内駐車場や地下等の場合には、積算入熱量ＩＨＩを予測することは無意味であることから、ＥＣＵ１０は、クラウドサーバ４０から取得した現在の日射量Ｓｒｃと、日射センサ１５が検出した日射量Ｓｒｓとを比較し、両者の乖離が相対的に大きい場合には、車両１の現在地が屋内等であると判定し、積算入熱量ＩＨＩを予測することなく、調光ガラス３への電圧をＯＦＦにする。

これに対し、日射量Ｓｒｃと日射量Ｓｒｓとの乖離が相対的に小さい場合、換言すると、車両１の現在地が屋外であると判定した場合には、ＥＣＵ１０は、クラウドサーバ４０から取得した日射量Ｓｒｃの推移に基づいて、肯定判定されてからの経過時間に応じた積算入熱量ＩＨＩを、調光ガラス３の暗色状態および透明状態のそれぞれについて予測（算出）する（図４および図５参照）。

次いで、ＥＣＵ１０は、（３）温度差ΔＴを所定値ＰＶ以下にするために必要な必要入熱量ＮＨＩを取得する。具体的には、ＥＣＵ１０は、図３に示すような温度差ΔＴと必要入熱量ＮＨＩとの関係を模式的に示す制御マップ図を用い、車室内温度Ｔｉと外気温度Ｔｏと目標車室内温度Ｔｔとに基づいて、必要入熱量ＮＨＩを取得する。

図３に示す制御マップ図がＲＯＭに記憶されている場合には、ＥＣＵ１０は、室温センサ１１が検出した車室内温度Ｔｉと、外気温センサ１３が検出した外気温度Ｔｏと、目標車室内温度Ｔｔとに基づいて、必要入熱量ＮＨＩを算出（取得）する。例えば、車室内温度Ｔｉが２０（℃）で、目標車室内温度Ｔｔが２５（℃）で、外気温度Ｔｏが１０（℃）の場合に、所定値ＰＶが０に設定されているとすると、制御マップ図から、温度差ΔＴ＝５（℃）を所定値ＰＶ＝０にするために必要な必要入熱量ＮＨＩが３００００（ｋＪ）であると算出される。

一方、図３に示す制御マップ図がオペレーションセンター５０のサーバに記憶されている場合には、ＥＣＵ１０は、車室内温度Ｔｉと外気温度Ｔｏと目標車室内温度Ｔｔを、ネットワークアクセスデバイス３０を介して送信し、オペレーションセンター５０のサーバで算出された必要入熱量ＮＨＩを、ネットワークアクセスデバイス３０を介して受信（取得）するようにしてもよい。このようにすれば、演算に用いる車両電力を節約することができる。

なお、このように必要入熱量ＮＨＩを取得する場合にも、目標車室内温度Ｔｔとして、車両１が現在いる地域における「快適な車室内温度Ｔｔｃ」を用いてもよい。また、所定値ＰＶは０である必要はなく、必要入熱量ＮＨＩが得られたときに、目標車室内温度Ｔｔ−車室内温度Ｔｉ＝ＰＶとなるように、所定値ＰＶを設定してもよい。

図４は、９時から駐車した場合における積算入熱量ＩＨＩの時間推移の一例を示すグラフ図であり、図５は、１５時から駐車した場合における積算入熱量ＩＨＩの時間推移の一例を示すグラフ図である。ＥＣＵ１０は、（４−１）調光ガラス３が暗色状態でも、肯定判定から所定時間ＰＴまでに積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達する場合には、電圧ＯＦＦにする。なお、所定時間ＰＴは、例えば駐車した車両１から乗員が離れている予想時間等であり、操作パネル１７等の操作によって乗員が設定可能となっている。

例えば、９時から駐車した場合には、電圧ＯＮにより調光ガラス３を透明状態にすれば、太陽光を積極的に取り込むことで、図４の実線で示すように、２時間後の１１時には積算入熱量ＩＨＩを必要入熱量ＮＨＩに到達させることができる。もっとも、電圧ＯＦＦにより調光ガラス３を暗色状態にしても、図４の破線で示すように、３時間後の１２時には積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達することになる。それ故、所定時間ＰＴを例えば６時間に設定した場合には、電圧ＯＦＦのままでも、駐車した車両１から離れた乗員が再び車両１に戻ってくるまでに、車室内温度Ｔｉを目標車室内温度Ｔｔに近付けることが可能となる。このように、ＥＣＵ１０は、暗色状態でも、日射入熱量を十分に確保することができる場合には、たとえ入熱が必要と判定したとしても、調光ガラス３に電圧を印加しないので、無駄な電力消費を抑えることができる。

また、ＥＣＵ１０は、（４−２）日射入熱量が、調光ガラス３を透明状態にするための消費電力よりも小さい場合にも、調光ガラス３への電圧をＯＦＦにする。例えば曇りや夜間など、日射入熱量が、調光ガラス３を透明状態にするための消費電力よりも小さい場合には、調光ガラス３を透明状態にしても、効率的な入熱は望めない。そこで、ＥＣＵ１０は、日射入熱量と、調光ガラス３を透明状態にするための消費電力（例えば１．１（Ｗ／ｍ²））とを比較して、日射入熱量が１．１（Ｗ／ｍ²）を下回る場合には、たとえ入熱が必要と判定したとしても、調光ガラス３に電圧を印加しないので、効率の悪い電力消費を抑えることができる。なお、この場合には、駐車している間に車室内温度Ｔｉを目標車室内温度Ｔｔに近付けることはできないが、効率の悪い電力消費を抑えた分の車両電力を、車両１発進後のエアコン（図示せず）による暖房に使うことができる。

そうして、ＥＣＵ１０は、（４−１）および（４−２）以外の場合には、（５）積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達するまで、調光ガラス３への電圧をＯＮにする。具体的には、ＥＣＵ１０は、（４−１）および（４−２）以外の場合には、調光ガラス３への電圧をＯＮにし、図４に示すように、積算入熱量ＩＨＩ（図４の実線）が必要入熱量ＮＨＩ（図４では３００００（ｋＪ））に到達する時間（電圧ＯＮ時間）を算出し、電圧ＯＮ時間だけ電圧ＯＮの状態を継続した後、調光ガラス３への電圧をＯＦＦにする。なお、電圧ＯＮ時間の算出をオペレーションセンター５０のサーバで行い、ネットワークアクセスデバイス３０を介して電圧ＯＮ時間の算出を受信（取得）するようにしてもよい。このようにすれば、演算に用いる車両電力を節約することができる。

例えば、１５時から駐車した場合には、電圧ＯＦＦにより調光ガラス３を暗色状態にすると、図５の破線で示すように、所定時間ＰＴ（例えば６時間）内に、積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達することはないが、電圧ＯＮにより調光ガラス３を透明状態にすれば、太陽光を積極的に取り込むことで、図５の実線で示すように、１時間半後の１６時半には積算入熱量ＩＨＩを必要入熱量ＮＨＩに到達させることができる。

このように、（４−１）および（４−２）以外の場合に、電圧ＯＮにより調光ガラス３を透明状態とすることにより、太陽光を積極的に取り込んで車室内温度Ｔｉを上昇させることができ、これにより、車室内温度Ｔｉを適切に調整しつつ、暖房時の動力を低減して燃費の向上を図ることができる。

ここで、必要入熱量ＮＨＩの算出要素である所定値ＰＶを０に設定した場合には、積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達すると、目標車室内温度Ｔｔと車室内温度Ｔｉとが一致することになる。もっとも、電圧ＯＮ時間経過後に、電圧ＯＦＦにして調光ガラス３を暗色状態としても、日射量Ｓｒｃの推移によっては、暗色状態での入熱により、車室内温度Ｔｉが予想以上に高くなるケースもある。

この点、所定値ＰＶは、上述の如く０である必要はないので、調光ガラス３の暗色状態における積算入熱量ＩＨＩの上昇代を見越して所定値ＰＶを設定すれば、電圧ＯＮ時間だけ電圧ＯＮの状態を継続することで積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達しても、車室内温度Ｔｉが所定値ＰＶだけ目標車室内温度Ｔｔよりも低い状態にすることができる。そうして、その後（電圧ＯＦＦの後）、調光ガラス３の暗色状態における積算入熱量ＩＨＩの上昇代によって、車室内温度Ｔｉを目標車室内温度Ｔｔに近付けることが可能となるので、車室内温度Ｔｉを適切に調整することができる。したがって、車室内温度Ｔｉが予想以上に高くなってしまうのを抑制して、車室７内を冷やすことで燃費が悪化するのを抑えることができる。

なお、上述の如く、駐車した車両１から離れた位置に居る乗員が、出発時刻が早まった（例えば６時間後から２時間後に変更した）ことを、スマートフォン７０等でオペレーションセンター５０のサーバへ出発時刻を送信すれば、ＥＣＵ１０へ出発時刻等が入力され、所定時間ＰＴが上書きされる。この場合には、例えば図４の破線で示すように、暗色状態でも３時間後には積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達するが、所定時間ＰＴ（２時間）内には、積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達しないので、２時間後に積算入熱量ＩＨＩを必要入熱量ＮＨＩに到達させるべく、電圧ＯＮにして調光ガラス３を透明状態とするようにしてもよい。

−制御フロー−
次に、ＥＣＵ１０が実行する調光ガラス制御の一例について、図６のフローチャートを参照して説明する。なお、この制御フローは、例えば、車両１が駐車した場合や、車両１の走行中に、車室内温度Ｔｉと目標車室内温度Ｔｔとの乖離が相対的に大きくなった場合等にＳＴＡＲＴするように構成されている。

先ず、ステップＳ１では、ＥＣＵ１０が、車室７内への入熱が必要か否かを判定する。具体的には、ＥＣＵ１０は、室温センサ１１が検出した車室内温度Ｔｉと、乗員が設定またはオペレーションセンター５０のサーバ等から取得した目標車室内温度Ｔｔとの温度差ΔＴ（＝Ｔｔ−Ｔｉ）が、例えばΔＴ≧０なら暖房時であり車室７内への入熱が必要と判定（肯定判定）する一方、ΔＴ＜０なら冷房時であり車室７内への入熱が不要と判定（否定判定）する。このステップＳ１での判定がＮＯの場合、すなわち、否定判定した場合には、ステップＳ１０へ進み、調光ガラス３への電圧をＯＦＦにした後、ＥＮＤする。一方、ステップＳ１での判定がＹＥＳの場合には、ステップＳ２に進む。

次のステップＳ２では、ＥＣＵ１０が、車両１の現在地が屋外か否かを判定する。具体的には、ＥＣＵ１０は、クラウドサーバ４０から取得した現在の日射量Ｓｒｃと、日射センサ１５が検出した日射量Ｓｒｓとを比較し、両者の乖離が相対的に小さい場合には、車両１の現在地が屋外であると判定する一方、両者の乖離が相対的に大きい場合には、車両１の現在地が屋内や地下等であると判定する。このステップＳ２での判定がＮＯの場合、すなわち、車両１の現在地が屋外ではない場合には、ステップＳ１０へ進み、調光ガラス３への電圧をＯＦＦにした後、ＥＮＤする。一方、ステップＳ２での判定がＹＥＳの場合には、ステップＳ３に進む。

次のステップＳ３では、ＥＣＵ１０が、積算入熱量ＩＨＩを予測する。具体的には、ＥＣＵ１０は、クラウドサーバ４０から取得した日射量Ｓｒｃの推移に基づいて、ステップＳ１で肯定判定されてからの経過時間に応じた、日射による車室７内への積算入熱量ＩＨＩを算出した後、ステップＳ４に進む。

次のステップＳ４では、ＥＣＵ１０が、必要入熱量ＮＨＩを取得する。具体的には、ＥＣＵ１０は、車室内温度Ｔｉ、目標車室内温度Ｔｔ、および外気温センサ１３が検出した外気温度Ｔｏを、ネットワークアクセスデバイス３０を介して送信し、オペレーションセンター５０のサーバで算出された必要入熱量ＮＨＩを、ネットワークアクセスデバイス３０を介して取得した後、ステップＳ５に進む。

次のステップＳ５では、ＥＣＵ１０が、ステップＳ３で予測した積算入熱量ＩＨＩと、ステップＳ４で取得した必要入熱量ＮＨＩとに基づいて、調光ガラス３が暗色状態でも所定時間ＰＴまでに積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達するか否かを判定する。このステップＳ５での判定がＹＥＳの場合、すなわち、暗色状態でも日射入熱量を十分に確保することができる場合には、ステップＳ１０へ進み、調光ガラス３への電圧をＯＦＦにした後、ＥＮＤする。一方、ステップＳ５での判定がＮＯの場合には、ステップＳ６に進む。

次のステップＳ６では、ＥＣＵ１０が、日射入熱量が、調光ガラス３を透明状態にするための消費電力以上か否かを判定する。このステップＳ６での判定がＮＯの場合には、ステップＳ１０へ進み、調光ガラス３への電圧をＯＦＦにした後、ＥＮＤする。一方、ステップＳ６での判定がＹＥＳの場合には、ステップＳ７に進む。

次のステップＳ７では、ＥＣＵ１０が、調光ガラス３への電圧をＯＮにした後、ステップＳ８へ進み、積算入熱量ＩＨＩが必要入熱量ＮＨＩに到達するまでの時間である電圧ＯＮ時間を算出し、その後ステップＳ９に進む。

次のステップＳ９では、ＥＣＵ１０が、電圧ＯＮ時間が経過したか否かを判定する。このステップＳ９での判定はＹＥＳになるまで繰り返され、ステップＳ９での判定がＹＥＳの場合には、ステップＳ１０に進み、調光ガラス３への電圧をＯＦＦにした後、ＥＮＤする。

以上説明した実施形態において、ＥＣＵ１０が請求項に記載の各要素の機能を実現するものに相当している。より詳しくは、ステップＳ１が請求項に記載の「車室内の温度と目標車室内温度との温度差に基づいて、車室内への入熱が必要か否かを判定する判定部」に相当している。また、ステップＳ３が請求項に記載の「判定部により入熱が必要と判定された場合に、クラウドサーバから取得した日射量の推移に基づいて、入熱が必要と判定されてからの経過時間に応じた車室内への積算入熱量を予測する予測部」に相当している。さらに、ステップＳ４が請求項に記載の「車室内の温度と目標車室内温度と外気温度とに基づいて算出される、車室内の温度と目標車室内温度との温度差を所定値以下にするために必要な必要入熱量を取得する取得部」に相当している。

（その他の実施形態）
本発明は、実施形態に限定されず、その精神又は主要な特徴から逸脱することなく他の色々な形で実施することができる。

上記実施形態では、ルーフウィンドガラス３に本発明を適用したが、これに限らず、フロントウィンドガラスやリヤウィンドガラスやサイドウィンドガラスに本発明を適用してもよい。

このように、上述の実施形態はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。さらに、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内のものである。

本発明によると、日射による車室内への入熱量をコントロールすることで、車室内の温度を適切に調整しつつ、燃費の悪化を抑えることができるので、調光ガラスを備える車両に搭載される調光ガラス制御装置に適用して極めて有益である。

１ 車両
３ ルーフウィンドガラス（調光ガラス）
７ 車室
１０ ＥＣＵ（調光ガラス制御装置）
４０ クラウドサーバ
ＩＨＩ 積算入熱量
ＮＨＩ 必要入熱量
ＰＴ 所定時間
ＰＶ 所定値
Ｓ１ 判定部
Ｓ３ 予測部
Ｓ４ 取得部
Ｓｒｃ 日射量
Ｔｉ 車室内温度
Ｔｏ 外気温度
Ｔｔ 目標車室内温度
ΔＴ 温度差

Claims (1)

1. ウィンドガラスとして、電圧を印加することで光透過率が低い状態から高い状態へ切り替わる調光ガラスを備える車両に搭載される調光ガラス制御装置であって、
   車室内の温度と目標車室内温度との温度差に基づいて、車室内への入熱が必要か否かを判定する判定部と、
   上記判定部により入熱が必要と判定された場合に、クラウドサーバから取得した日射量の推移に基づいて、入熱が必要と判定されてからの経過時間に応じた、日射による車室内への積算入熱量を予測する予測部と、
   車室内の温度と上記目標車室内温度と外気温度とに基づいて算出される、車室内の温度と当該目標車室内温度との温度差を所定値以下にするために必要な必要入熱量を取得する取得部と、を備え、
   上記調光ガラスの光透過率が低い状態でも、入熱が必要と判定されてから所定時間までに積算入熱量が必要入熱量に到達する場合、または、日射による車室内への入熱量が、上記調光ガラスの光透過率を高い状態にするための消費電力よりも小さい場合には、上記調光ガラスに電圧を印加しない一方、それ以外の場合には、積算入熱量が必要入熱量に到達するまで、上記調光ガラスに電圧を印加することを特徴とする調光ガラス制御装置。

Images