知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-03-10
(45)【発行日】2023-03-20
(54)【発明の名称】中央制御システムおよび方法
(51)【国際特許分類】
G08G 1/09 20060101AFI20230313BHJP
G08G 1/00 20060101ALI20230313BHJP
【ＦＩ】
G08G1/09
G08G1/00 A
【請求項の数】
15
(21)【出願番号】P 2020554952
(86)(22)【出願日】2018-12-21
(65)【公表番号】
(43)【公表日】2021-02-25
(86)【国際出願番号】 GB2018053764
(87)【国際公開番号】W WO2019122933
(87)【国際公開日】2019-06-27
【審査請求日】2021-08-18
(31)【優先権主張番号】1721827.2
(32)【優先日】2017-12-22
(33)【優先権主張国・地域又は機関】GB
(31)【優先権主張番号】17275199.2
(32)【優先日】2017-12-22
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】520223228
【氏名又は名称】ファーフェッチ ユーケー リミテッド
【氏名又は名称原語表記】Ｆａｒｆｅｔｃｈ ＵＫ Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】Ｌｅｇａｌ Ｄｅｐａｒｔｍｅｎｔ， ４ｔｈ Ｆｌｏｏｒ， Ｔｈｅ Ｂｏｗｅｒ， ２１１ Ｏｌｄ Ｓｔｒｅｅｔ， Ｌｏｎｄｏｎ ＥＣ１Ｖ ９ＮＲ， Ｕｎｉｔｅｄ Ｋｉｎｇｄｏｍ
(74)【代理人】
【識別番号】110002745
【氏名又は名称】弁理士法人河崎特許事務所
(72)【発明者】
【氏名】ラム，メイリーン
(72)【発明者】
【氏名】ゾカンテ，パオロ
(72)【発明者】
【氏名】コーエン，アビー
【審査官】甲斐 哲雄
(56)【参考文献】
【文献】米国特許出願公開第２０１７／０１４８３１６（ＵＳ，Ａ１）
【文献】国際公開第２０１７／１１１１２７（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１７／０２６１９８６（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０８Ｇ １／００－９９／００
Ｇ０６Ｆ １６／００－１６／９５８
(57)【特許請求の範囲】
【請求項1】
１つ以上の遠隔配置対話ユニット（１８Ａ～１８Ｄ）を広域通信ネットワーク（２２）を介して制御するための制御信号を生成するためのコンピュータ実施中央制御システム（１０）であって、前記１つ以上の遠隔配置対話ユニット（１８Ａ～１８Ｄ）のそれぞれは、前記各遠隔配置対話ユニット（１８Ａ～１８Ｄ）のローカル環境（２０Ａ～２０Ｄ）において対応するローカル制御システムに動作可能に結合され、前記遠隔配置対話ユニット（１８Ａ～１８Ｄ）のそれぞれは、前記各動作可能に結合されたローカル制御システムと対話しかつ該ローカル制御システムの動作条件を変更するように構成され、前記コンピュータ実施中央制御システム（１０）は、指定環境要件（ＳＥＲ）（２１６Ａ、２４０）に関する要求された制御パラメータ（２３８）（ＲＣＰ）の値を変更するように構成された制御信号に対するリクエスト（２３０）を前記１つ以上の遠隔配置対話ユニット（１８Ａ～１８Ｄ）のうち１つから受信するためのリクエストインターフェイス処理部（３０）であって、前記ＲＣＰ（２３８）の前記値は、前記各遠隔配置対話ユニット（１８Ａ～１８Ｄ）の前記ローカル環境（２０Ａ～２０Ｄ）における前記対応するローカル制御システムの前記動作条件を決定し、前記ＳＥＲ（２１６Ａ、２４０）は、前記ＲＣＰ（２３８）の前記値を変更することによって満たされるべき、前記各遠隔配置対話ユニット（１８Ａ～１８Ｄ）の前記ローカル環境（２０Ａ～２０Ｄ）の制約環境要件を含み、前記リクエストは、前記ＲＣＰ（２３８）の現在値、前記ＳＥＲ（２４０）の指定値、および前記ＳＥＲ（２１６Ａ、２４０）に関する１つ以上のローカル環境パラメータ（ローカルＣＥＲ）（２１６Ｂ、２１６Ｃ、２４２、２４４）の現在値を含み、前記ローカルＣＥＲ（２１６Ｂ、２１６Ｃ、２４２、２４４）は、前記各遠隔配置対話ユニット（１８Ａ～１８Ｄ）の前記ローカル環境（２０Ａ～２０Ｄ）において前記ＲＣＰ（２３８）が取り得る値を制限する制約環境要件を含み、前記ＳＥＲ（２１６Ａ、２４０）の現在値は、前記ＲＣＰ（２３８）および前記１つ以上の遠隔配置対話ユニット（１８Ａ～１８Ｄ）の前記１つ以上のローカルＣＥＲ（２４２、２４４）の前記現在値から計算され得る、リクエストインターフェイス処理部（３０）と、
前記リクエストインターフェイス処理部（３０）において受信された前記リクエスト（２３０）を予め定義された計算ルール（１１Ａ）に従って処理するためのパラメータ計算システム（３６）であって、前記計算ルール（１１Ａ）は、前記パラメータ計算システム（３６）に、前記リクエスト（２３０）を処理し、前記要求された制御パラメータ（２３８）（ＲＣＰ）の値に関する前記制御信号を生成するよう指示する、パラメータ計算システム（３６）と、
リクエストを行っている遠隔配置対話ユニット（１８Ａ～１８Ｄ）に前記生成された制御信号を送信するための送信部（４０）とを備え、
前記パラメータ計算システム（３６）は、
前記遠隔配置対話ユニット（１８Ａ～１８Ｄ）に関連付けられた複数の現在の外部環境パラメータ（外部ＣＥＲ）（１９０Ａ～１９０Ｃ）を単一の外部ＣＥＲパラメータ（２０２Ａ～２０２Ｃ）に分類するための分類エンジン（９２）と、
パラメータ計算処理部（９４）であって、
前記ＲＣＰ（２３８）の前記現在値および前記１つ以上の遠隔配置対話ユニット（１８Ａ～１８Ｄ）の前記１つ以上のローカルＣＥＲ（２４２、２４４）の前記現在値に前記計算ルール（１１Ａ）を適用することによって前記ＳＥＲ（２００Ａ～２００Ｅ）の前記現在値を計算し、
前記ＳＥＲの前記現在値に対する前記複数の現在の外部ＣＥＲ（１９０Ａ～１９０Ｃ）の影響を判定するために、前記単一の外部ＣＥＲパラメータ（２０２Ａ～２０２Ｃ）の前記値を用いて前記ＳＥＲ（２００Ａ～２００Ｅ）の前記現在値をカテゴリー分類し、
前記ＳＥＲの前記カテゴリー分類された現在値を前記ＳＥＲ（２１６Ａ、２４０）の前記指定値と比較し、前記ＳＥＲ（２１６Ａ、２４０）の前記現在値と前記指定値との相違度の分類に応じて、前記ＳＥＲの前記現在値と前記ＳＥＲの前記指定値とが同等となるように前記ＲＣＰ（２３８）の前記値を調整するための複数の所定のアクションから対応する所定のアクションを選択し、かつ
前記選択された所定のアクションを用いて前記制御信号を形成して、前記リクエストを行っている遠隔配置対話ユニット（１８Ａ～１８Ｄ）についての前記ＲＣＰの現在値を、前記ＳＥＲの前記指定値を満たすように調整するように構成される、パラメータ計算処理部（９４）とを備えるコンピュータ実施中央制御システム（１０）。
【請求項2】
前記パラメータ計算システム（３６）は、前記ＳＥＲ（２００Ａ～２００Ｅ）の前記現在値を計算する際に前記パラメータ計算処理部（９４）によって使用されるための外部ＣＥＲ（１９０Ａ～１９０Ｃ）の値を要求しかつ取得するように構成される情報収集処理部（９０）をさらに備える、請求項１に記載のコンピュータ実施中央制御システム（１０）。
【請求項3】
前記情報収集処理部（９０）は、前記リクエスト（２３０）において指定された前記１つ以上のパラメータから、前記要求された外部ＣＥＲ（１９０Ａ～１９０Ｃ）のうちの少なくともいくつかを特定するように構成される、請求項２に記載のコンピュータ実施中央制御システム（１０）。
【請求項4】
前記リクエスト（２３０）は、前記遠隔配置対話ユニット（１８Ａ～１８Ｄ）の位置を含むローカルＣＥＲを含み、前記情報収集処理部（９０）は、前記遠隔配置対話ユニット（１８Ａ～１８Ｄ）の前記位置を用いて、どの外部ＣＥＲ（１９０Ａ～１９０Ｃ）が前記分類された単一の外部ＣＥＲパラメータ（２０２Ａ～２０２Ｃ）の生成に使用されるべきかを判定する、請求項２または３に記載のコンピュータ実施中央制御システム。
【請求項5】
前記パラメータ計算システム（３６）は、前記パラメータ計算処理部（９４）から前記制御信号を受信し、かつ前記ローカルＣＥＲおよび外部ＣＥＲ（２１２、２１４）、前記カテゴリー分類および分類の結果、ならびに前記制御信号を、前記遠隔配置対話ユニット（１８Ａ～１８Ｄ）に提供し履歴パラメータデータとして使用するために、パラメータ結果格納部（３８）に格納するように構成された結果処理部（９６）をさらに備える、請求項２～４のいずれか一項に記載のコンピュータ実施中央制御システム（１０）。
【請求項6】
前記リクエストインターフェイス処理部（３０）は、１つ以上の履歴情報パラメータ（２４２、２４４）を含むリクエスト（２３０）を受信するように構成され、前記情報収集処理部（９０）は、前記パラメータ結果格納部（３８）に格納された前記履歴パラメータデータから前記履歴情報パラメータの値を検索するように構成される、請求項５に記載のコンピュータ実施中央制御システム。
【請求項7】
前記分類エンジン（９２）は、複数の異なる外部ＣＥＲ（１９０Ａ～１９０Ｃ）を異なる組み合わせで互いに組み合わせて、前記外部ＣＥＲを記述する単一の総合外部ＣＥＲ分類（１９２）を得るように構成された分類生成行列（１９１）を備える、請求項１～６のいずれか一項に記載のコンピュータ実施中央制御システム。
【請求項8】
前記分類エンジン（９２）は、前記複数の外部ＣＥＲを定性記述を含む複数のシナリオ（１９２）に分類するように構成され、各定性記述には、前記定性記述を定量的分類として操作するために使用され得る特定のスコアが割り当てられている、請求項７に記載のコンピュータ実施中央制御システム。
【請求項9】
前記パラメータ計算処理部（９４）は、前記対応する所定のアクションを前記分類生成行列において示される複数の所定の命令のうちの１つとして提供するように構成される命令生成行列（２０１）を備え、前記命令生成行列は、前記ＲＣＰの前記現在値における前記１つ以上のローカル環境パラメータ（ローカルＣＥＲ）の前記現在値に基づく前記現在のＳＥＲ値（２００Ａ～２００Ｅ）と、前記単一の外部総合ＣＥＲ分類（２０２Ａ～２０２Ｃ）とによって索引付けされる、請求項７または８に記載のコンピュータ実施中央制御システム。
【請求項10】
前記受信されたリクエスト（２３０）のステータスを通知するための通知システム（３４）をさらに備え、前記通知システム（３４）は、前記リクエストが処理され、前記制御信号が前記リクエストを行っている遠隔対話ユニット（１８Ａ～１８Ｄ）にオンデマンドで送信可能な状態になったときに、前記リクエストを行っている遠隔対話ユニット（１８Ａ～１８Ｄ）に少なくとも通知を送るように構成され、前記送信部（４０）は、前記リクエストを行っている遠隔対話ユニットからのプル命令を受信した時点で前記制御信号を前記リクエストを行っている遠隔対話ユニット（１８Ａ～１８Ｄ）に送信するように構成される、請求項１～９のいずれか一項に記載のコンピュータ実施中央制御システム。
【請求項11】
前記パラメータ計算システム（３６）が前記リクエストを処理して前記制御信号を生成できるようになるまで前記リクエスト（２３０）を格納するためのリクエストキュー（３２）をさらに備え、前記通知システム（３４）は前記リクエストキュー（３２）に結合され、前記通知システム（３４）は、前記リクエストが処理待機中であるか、処理中であるか、あるいは処理済みであるかを示す、前記リクエスト（２３０）のステータスのリアルタイムレコードを特定し、かつ前記リクエストを行っている遠隔対話ユニット（１８Ａ～１８Ｄ）に前記リクエストのステータスをオンデマンドで提供するように構成される、請求項１０に記載のコンピュータ実施中央制御システム。
【請求項12】
前記リクエストインターフェイス処理部（３０）は、１つ以上の異なる遠隔配置対話ユニット（１８Ａ～１８Ｄ）に関するプロキシリクエストを受信するように構成され、前記パラメータ計算システムは、前記リクエストを行っている遠隔配置対話ユニットではなく、前記１つ以上の異なる遠隔配置対話ユニットを制御するための制御信号を生成するように構成される、請求項１～１１のいずれか一項に記載のコンピュータ実施中央制御システム。
【請求項13】
前記ＳＥＲの前記指定値は、前記コンピュータ実施中央制御システム（１０）に格納された所定の値であり、前記受信されたリクエスト（２３０）は、前記ＳＥＲの前記所定の格納された値が、その比較において前記指定ＳＥＲとして使用されるべきであるということを前記パラメータ計算処理部（９４）に対して示すトリガ識別子を含む、請求項１～１２のいずれか一項に記載のコンピュータ実施中央制御システム。
【請求項14】
前記リクエストインターフェイス処理部（３０）は、複数の遠隔配置対話ユニット（１８Ａ～１８Ｄ）に関するリクエスト（２３０）を受信し、かつ前記リクエストを、それぞれが前記１つ以上の遠隔配置対話ユニット（１８Ａ～１８Ｄ）のサブセットに関連している複数のサブリクエストに分割するように構成され、前記パラメータ計算システム（３６）は、前記複数のサブリクエストのそれぞれを処理し、かつ前記遠隔配置対話ユニット（１８Ａ～１８Ｄ）のそれぞれを制御するための前記サブリクエストのそれぞれのための制御信号を生成するように構成される、請求項１～１３のいずれか一項に記載のコンピュータ実施中央制御システム。
【請求項15】
１つ以上の遠隔配置対話ユニット（１８）を広域通信ネットワーク（２２）を介して制御するための制御信号を生成するためのコンピュータ実施方法であって、指定環境要件（ＳＥＲ）（２１６Ａ、２４０）に関する要求された制御パラメータ（２３８）（ＲＣＰ）の値を変更するように構成された制御信号に対するリクエスト（２３０）を複数の遠隔配置対話ユニット（１８Ａ～１８Ｄ）のうち１つから受信するステップであって、前記１つ以上の遠隔配置対話ユニット（１８Ａ～１８Ｄ）のそれぞれは、前記各遠隔配置対話ユニット（１８Ａ～１８Ｄ）のローカル環境（２０Ａ～２０Ｄ）において対応するローカル制御システムに動作可能に結合され、前記遠隔配置対話ユニット（１８Ａ～１８Ｄ）のそれぞれは、前記各動作可能に結合されたローカル制御システムと対話しかつ該ローカル制御システムの動作条件を変更するように構成され、前記ＲＣＰ（２３８）の前記値は、前記各遠隔配置対話ユニット（１８Ａ～１８Ｄ）の前記ローカル環境（２０Ａ～２０Ｄ）における前記対応するローカル制御システムの前記動作条件を決定し、前記ＳＥＲ（２１６Ａ、２４０）は、前記ＲＣＰ（２３８）の前記値を変更することによって満たされるべき、前記各遠隔配置対話ユニット（１８Ａ～１８Ｄ）の前記ローカル環境（２０Ａ～２０Ｄ）の制約環境要件を含み、前記リクエストは、前記ＲＣＰ（２３８）の現在値、前記ＳＥＲ（２４０）の指定値、および前記ＳＥＲ（２１６Ａ、２４０）に関する１つ以上のローカル環境パラメータ（ローカルＣＥＲ）（２１６Ｂ、２１６Ｃ、２４２、２４４）の現在値を含み、前記ローカルＣＥＲ（２１６Ｂ、２１６Ｃ、２４２、２４４）は、前記各遠隔配置対話ユニット（１８Ａ～１８Ｄ）の前記ローカル環境（２０Ａ～２０Ｄ）において前記ＲＣＰ（２３８）が取り得る値を制限する制約環境要件を含み、前記ＳＥＲ（２１６Ａ、２４０）の現在値は、前記ＲＣＰ（２３８）および前記１つ以上のローカルＣＥＲ（２４２、２４４）の前記現在値から計算され得る、ステップと、
リクエストインターフェイス処理部（３０）において受信された前記リクエスト（２３０）を予め定義された計算ルール（１１Ａ）に従って処理するステップであって、前記計算ルール（１１Ａ）は、パラメータ計算システム（３６）に、前記リクエスト（２３０）を処理し、前記要求された制御パラメータ（２３８）（ＲＣＰ）の値に関する前記制御信号を生成するよう指示する、ステップと、
リクエストを行っている遠隔配置対話ユニット（１８Ａ～１８Ｄ）に前記生成された制御信号を送信するステップとを含み、
前記処理ステップは、
前記遠隔配置対話ユニット（１８Ａ～１８Ｄ）に関連付けられた複数の現在の外部環境パラメータ（外部ＣＥＲ）（１９０Ａ～１９０Ｃ）を単一の外部ＣＥＲパラメータ（２０２Ａ～２０２Ｃ）に分類するステップと、
前記ＲＣＰ（２３８）の前記現在値および前記１つ以上のローカルＣＥＲ（２４２、２４４）の前記現在値に前記計算ルール（１１Ａ）を適用することによって前記ＳＥＲ（２００Ａ～２００Ｅ）の前記現在値を計算するステップと、
前記ＳＥＲの前記現在値に対する前記複数の現在の外部ＣＥＲ（１９０Ａ～１９０Ｃ）の影響を判定するために、前記単一の外部ＣＥＲパラメータ（２０２Ａ～２０２Ｃ）の前記値を用いて前記ＳＥＲ（２００Ａ～２００Ｅ）の前記現在値をカテゴリー分類するステップと、
前記ＳＥＲの前記カテゴリー分類された現在値を前記ＳＥＲ（２１６Ａ、２４０）の前記指定値と比較し、前記ＳＥＲ（２１６Ａ、２４０）の前記現在値と前記指定値との相違度の分類に応じて、前記ＳＥＲの前記現在値と前記ＳＥＲの前記指定値とが同等となるように前記ＲＣＰ（２３８）の前記値を調整するための複数の所定のアクションから対応する所定のアクションを選択するステップと、
前記選択された所定のアクションを用いて前記制御信号を形成して、前記リクエストを行っている遠隔配置対話ユニット（１８Ａ～１８Ｄ）についての前記ＲＣＰの現在値を、前記ＳＥＲの前記指定値を満たすように調整するステップとを含む、コンピュータ実施方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、中央制御システムおよび方法に関する。より詳細には、本発明は、遠隔（遠隔配置）対話ユニットからリクエストを受信し、次いで、遠隔対話ユニットが環境要件に応じて最も効率的に動作することを可能にする制御信号を遠隔対話ユニットに提供するように構成された処理アーキテクチャに関するが、これに限定されるものではない。１つの非限定的な応用分野は、自立走行電気自動車の燃料管理である。
【背景技術】
【0002】
多種多様なシステムがリアルタイム環境で動作しており、リアルタイム環境において、システムの正確かつ効率的な動作は、当該システムのユーザの環境選好の常時変化するパラメータに左右される。その結果、これらの環境で動作するシステムは、しばしば、その動作の方式を変更する必要があり、その決定は、通常、これらの環境条件およびユーザの選好の継続的なモニタリングに依存している。いくつかのシナリオにおいて、不正確または非効率的なアクションは、実際、システムの動作に非常に有害となるか、さらには末期的な状態をもたらす場合があることが分かっている。
【0003】
このようなシステムの１つの非限定的な例は、自走車両の燃料レベルの管理において見られ、この場合、不適切な管理は、燃料が入手できない場所での車両の燃料切れにつながり得る。このことは、電気自動車の場合、特に重要な検討事項である。なぜなら、再充電ステーションは比較的数が少なく、非線形的な充電消費は、しばしば、旅程計画の主要な要素であるからである。電気自動車の充電には時間もかかり、ユーザは、充電ステーションでの所望滞在時間に関する具体的な要件を有している場合があり、充電残量レベルの管理を誤ると、ユーザが望むよりも長い時間にわたって車両を充電しなければならない場合がある。
【0004】
典型的には、リアルタイム環境での分散システムの動作には、しばしば、様々な程度のユーザ入力が必要とされており、ある場所での動作が最適でなかった場合、ユーザは、これを補正するためにシステム内で変更を行う必要がある。しかしながら、このような解決方法により、いくつかの問題が生じる。ユーザがシステムに対してローカルな変更を行う際、ユーザは、ユーザの決定に影響を及ぼし得る、システム全体からのすべての関連情報を把握していない場合がある。例えば、前述の電気自動車の例に戻ると、車両の運転者が燃料消費を削減したい場合、運転者は、低速だが距離が短い経路を取るように目的地への経路を変更する場合がある。しかしながら、この新たな経路上に運転者が気づいていない障害物が存在する可能性があり、この障害物により、運転者の車両は、以前の経路よりも多くの燃料（資源）を消費することになる場合があり、これはつまり、行われている変更が、実際には、運転者の情報不足によって最適以下のものとなっていることを意味する。この方法はまた、運転者がすべての情報を把握しているか否かに関わらず、単純なヒューマンエラーの可能性をもたらすものでもある。
【0005】
ほとんどの分野において、システム自動化に向けての注力が高まっている。例えば、自動車分野では、自動運転車両の使用に関する多くの開発がなされており、自動運転車両では、車両内の制御システムが車両速度、制動（車両のクルーズコントロールと組み合わせた）や自動経路探索などの車両の様々な側面を制御することが可能である。しかしながら、適切かつ効率的なアクションという点では、これらの自動化システムは、依然としてユーザの対話に依存している。上記の車両の例では、これは、ユーザが、燃料残量レベルをモニタリングし、再給油を行うことができるように車両に対して進行方向を変更する指示を行う必要があるということに現れている。
【0006】
本発明は、このような背景に鑑みて成されたものであり、リアルタイム環境モニタリングに依存する既存システムが有する前述の問題の少なくとも一部を回避しようとするものである。より詳細には、本発明は、リアルタイム環境で動作する遠隔対話ユニットに命令を提供（分散システム内で）し、それによって、資源が効率的にかつ当該遠隔対話ユニットのユーザの選好に応じて消費されるようにすることができるリアルタイム処理アーキテクチャを提供することを目的とする。
【発明の概要】
【0007】
本発明の一態様によると、１つ以上の遠隔配置対話ユニットを広域通信ネットワークを介して制御するための制御信号を生成するためのコンピュータ実施制御システムが提供される。前記中央制御システムは、指定環境要件（ＳＥＲ）に関する要求された制御パラメータ（ＲＣＰ）の制御信号に対するリクエストを１つ以上の遠隔配置対話ユニットのうち１つから受信するためのリクエストインターフェイス処理部であって、前記リクエストは、前記ＲＣＰの現在値、前記ＳＥＲの指定値、および前記ＳＥＲに関する１つ以上のローカル環境パラメータ（ローカルＣＥＲ）の現在値を含み、前記ＳＥＲの現在値は、前記ＲＣＰおよび前記１つ以上の遠隔配置対話ユニットの前記１つ以上のローカルＣＥＲの前記現在値から計算され得る、リクエストインターフェイス処理部と、
前記リクエストインターフェイス処理部において受信された前記リクエストを予め定義されたルールに従って処理し、前記ＲＣＰに関する前記制御信号を生成するためのパラメータ計算システムと、リクエストを行っている遠隔配置対話ユニットに前記生成された制御信号を送信するための送信部とを備え、前記パラメータ計算システムは、前記遠隔配置対話ユニットに関連付けられた複数の現在の外部環境パラメータ（外部ＣＥＲ）を単一の外部ＣＥＲパラメータに分類するための分類エンジンと、パラメータ計算処理部であって、前記ＲＣＰの前記現在値および前記１つ以上の遠隔配置対話ユニットの前記１つ以上のローカルＣＥＲの前記現在値に前記ルールを適用することによって前記ＳＥＲの前記現在値を計算し、前記ＳＥＲの前記現在値に対する前記複数の現在の外部ＣＥＲの影響を判定するために、前記単一の外部ＣＥＲパラメータの前記値を用いて前記ＳＥＲの前記現在値をカテゴリー分類し、前記ＳＥＲの前記カテゴリー分類された現在値を前記ＳＥＲの前記指定値と比較し、前記ＳＥＲの前記現在値と前記指定値との相違度の分類に応じて、前記ＳＥＲの前記現在値と前記ＳＥＲの前記指定値とが同等となるように前記ＲＣＰの前記値を調整するための対応する所定のアクションを選択し、かつ前記選択された所定のアクションを用いて前記制御信号を形成して、前記リクエストを行っている遠隔配置対話ユニットについての前記ＲＣＰの現在値を、前記ＳＥＲの前記指定値を満たすように調整するように構成される、パラメータ計算処理部とを備える。
前記リクエストインターフェイス処理部において受信された前記リクエストを予め定義されたルールに従って処理し、前記ＲＣＰに関する前記制御信号を生成するためのパラメータ計算システムと、リクエストを行っている遠隔配置対話ユニットに前記生成された制御信号を送信するための送信部とを備え、前記パラメータ計算システムは、前記遠隔配置対話ユニットに関連付けられた複数の現在の外部環境パラメータ（外部ＣＥＲ）を単一の外部ＣＥＲパラメータに分類するための分類エンジンと、パラメータ計算処理部であって、前記ＲＣＰの前記現在値および前記１つ以上の遠隔配置対話ユニットの前記１つ以上のローカルＣＥＲの前記現在値に前記ルールを適用することによって前記ＳＥＲの前記現在値を計算し、前記ＳＥＲの前記現在値に対する前記複数の現在の外部ＣＥＲの影響を判定するために、前記単一の外部ＣＥＲパラメータの前記値を用いて前記ＳＥＲの前記現在値をカテゴリー分類し、前記ＳＥＲの前記カテゴリー分類された現在値を前記ＳＥＲの前記指定値と比較し、前記ＳＥＲの前記現在値と前記指定値との相違度の分類に応じて、前記ＳＥＲの前記現在値と前記ＳＥＲの前記指定値とが同等となるように前記ＲＣＰの前記値を調整するための対応する所定のアクションを選択し、かつ前記選択された所定のアクションを用いて前記制御信号を形成して、前記リクエストを行っている遠隔配置対話ユニットについての前記ＲＣＰの現在値を、前記ＳＥＲの前記指定値を満たすように調整するように構成される、パラメータ計算処理部とを備える。
【0008】
したがって、本発明は、多数の異なるローカル変数および外部変数を想定することが可能であり、かつ、遠隔配置対話ユニットに対し、その環境制約および、特に、指定環境制約（ＳＥＲ）を満たすように当該対話ユニットを制御する選択された制御パラメータの値に基づいて制御信号を提供することが可能な制御システムを提供する。このような制御の簡略化は、多くの場合において何百、何千もの想定および考慮すべき制約が存在するにも関わらず、制御を容易に実施する必要があり、したがって、指定された制約を得るための単一の制御パラメータに制限された制御システムにおいて非常に有利である。上記システムは多くの異なるローカル環境制約および外部環境制約を想定しているため、上記制御信号は、先行技術のシステムによって可能なものよりも正確である。この制御信号は、これらの制約における変化に対する応答性を有しており、また、数千個の遠隔配置対話ユニットを扱うために完全にスケーラブルである。
【0009】
本明細書に記載される実施形態のいくつかにおいて、前記パラメータ計算システムは、前記ＳＥＲの前記現在値を計算する際に前記パラメータ計算処理部によって使用されるためのＣＥＲの値を要求しかつ取得するように構成される情報収集処理部をさらに備える。前記情報収集処理部、前記リクエストにおいて指定された前記１つ以上のパラメータから、前記要求された外部ＣＥＲのうちの少なくともいくつかを特定するように構成されてもよい。
【0010】
本明細書に記載されるいくつかの実施形態において、前記リクエストは、前記遠隔配置対話ユニットの位置を含むローカルＣＥＲを含み、前記情報収集処理部は、前記遠隔配置対話ユニットの前記位置を用いて、どの外部ＣＥＲが前記分類された単一の外部ＣＥＲパラメータの生成に使用されるべきかを判定する。位置に基づいて制約を提供することは、環境条件が想定される場合に非常に有利である。なぜなら、これらは位置ごとに大きく異なり得るからである。
【0011】
一実施形態において、上記情報収集処理部は、内部データベースおよび外部データ源からのリクエストに関する情報を収集し、受信された情報からパラメータ値を計算するかあるいは受信された情報をさらなる処理のために集計するように構成される。
【0012】
本発明のいくつかの実施形態において、前記パラメータ計算システムは、前記パラメータ計算処理部から前記制御信号を受信し、かつ前記ローカルＣＥＲおよび外部ＣＥＲ、前記カテゴリー分類および分類の結果、ならびに前記制御信号を、前記遠隔対話ユニットに提供し履歴パラメータデータとして使用するために、パラメータ結果格納部に格納するように構成された結果処理部をさらに備える。これらの実施形態において、前記リクエストインターフェイス処理部は、１つ以上の履歴情報パラメータを含むリクエストを受信するように構成され、前記情報収集処理部は、前記ローカルデータ格納部に格納された前記履歴パラメータデータから前記履歴情報パラメータの値を検索するように構成される。履歴パラメータデータを生成し、その後に使用することは非常に有利である。例えば、制御信号に対する現在のリクエストが、過去のリクエストに非常に類似しているかあるいは同一である場合、上記パラメータ計算処理を回避することができ、制御信号をこの履歴データから直接生成することができる。
【0013】
いくつかの実施形態において、前記分類エンジンは、複数の異なる外部ＣＥＲを異なる組み合わせで互いに組み合わせて、前記外部ＣＥＲを記述する単一の総合外部ＣＥＲ分類を得るように構成された分類生成行列を備える。
【0014】
いくつかの実施形態において、前記分類エンジンは、前記複数の外部ＣＥＲを定性記述を含む複数のシナリオに分類するように構成され、各定性記述には、前記定性記述を定量的分類として操作するために使用され得る特定のスコアが割り当てられている。
【0015】
いくつかの実施形態において、前記パラメータ計算処理部は、前記対応する所定のアクションを前記行列において示される複数の所定の命令のうちの１つとして提供するように構成される命令生成行列を備え、前記行列は、前記ＲＣＰの前記現在値における前記１つ以上のローカル環境パラメータ（ローカルＣＥＲ）の前記現在値に基づく前記現在のＳＥＲ値と、前記単一の外部総合ＣＥＲ分類とによって索引付けされる。多数の制限および分類を想定すると、単一の総合外部ＣＥＲ分類または取るべき所定のアクションを決定する多くの異なる方法が存在するが、行列を使用することにより、この技術を実施するための簡素で容易な方法が提供される。
【0016】
本発明のいくつかの実施形態において、前記システムは、前記受信されたリクエストのステータスを通知するための通知システムをさらに備え、前記通知システムは、前記リクエストが処理され、前記制御信号が前記リクエストを行っている遠隔対話ユニットにオンデマンドで送信可能な状態になったときに、前記リクエストを行っている遠隔対話ユニットに少なくとも通知を送るように構成され、前記送信部は、前記リクエストを行っている遠隔対話ユニットからのプル命令を受信した時点で前記制御信号を前記リクエストを行っている遠隔対話ユニットに送信するように構成される。
【0017】
いくつかの実施形態において、前記パラメータ計算システムが前記リクエストを処理して前記制御信号を生成できるようになるまで前記リクエストを格納するためのリクエストキューが備えられ、前記通知システムは前記リクエストキューに結合され、前記通知システムは、前記リクエストが処理待機中であるか、処理中であるか、あるいは処理済みであるかを示す、前記リクエストのステータスのリアルタイムレコードを特定し、かつ前記リクエストを行っている遠隔対話ユニットに前記リクエストのステータスをオンデマンドで提供するように構成される。
【0018】
いくつかの実施形態において、リクエストインターフェイス処理部は、各受信されたリクエストに識別子を割り当てるように構成されていてもよく、通知システムは、この識別子を用いてリクエストのリアルタイムステータスを判定するように構成される。これにより、システム全体にわたってリクエストを追跡することが可能となる。
【0019】
いくつかの実施形態において、リクエストインターフェイス処理部は、リクエストの正確性および完全性を確認し、リクエストを処理することができない場合には、リクエストを行っている遠隔対話ユニットに通知するように構成される。このような確認は、リクエストが通信中に破損する可能性があり、したがって再度送られる必要があり得る場合に重要である。
【0020】
いくつかの実施形態において、前記リクエストインターフェイス処理部は、１つ以上の異なる遠隔配置対話ユニットに関するプロキシリクエストを受信するように構成され、前記パラメータ計算システムは、前記リクエストを行っている遠隔配置対話ユニットではなく、前記１つ以上の異なる遠隔配置対話ユニットを制御するための制御信号を生成するように構成される。これにより、１つの遠隔配置対話ユニットを前記システムとの通信ポイントとして機能させることができ、すべての対話ユニットがシステムと直接通信可能ではないが、別の遠隔配置対話ユニットを介して間接的に通信可能となるため、対話ユニットを簡素化することができる。
【0021】
いくつかの実施形態において、前記ＳＥＲの前記指定値は、前記制御システムに格納された所定の値であってもよく、前記受信されたリクエストは、前記ＳＥＲの前記所定の格納された値が、その比較において前記指定ＳＥＲとして使用されるべきであるということを前記パラメータ計算処理部に対して示すトリガ識別子を含むことができる。
【0022】
本発明のいくつかの実施形態において、前記リクエストインターフェイス処理部は、複数の遠隔配置対話ユニットに関するリクエストを受信し、かつ前記リクエストを、それぞれが前記１つ以上の遠隔配置対話ユニットのサブセットに関連している複数のサブリクエストに分割するように構成され、前記パラメータ計算システムは、前記複数のサブリクエストのそれぞれを処理し、かつ前記遠隔配置対話ユニットのそれぞれを制御するための前記サブリクエストのそれぞれのための制御信号を生成するように構成される。これにより、送信効率を大きく向上させることができると共に、通信が遮断されたとき（車両の例においては、車両が例えばトンネル内にあるとき）にリクエストの受信が断続的になるという問題を解消することができる。
【0023】
本発明の別の態様によると、１つ以上の遠隔配置対話ユニットを広域通信ネットワークを介して制御するための制御信号を生成するためのコンピュータ実施方法が提供される。前記方法は、指定環境要件（ＳＥＲ）に関する要求された制御パラメータ（ＲＣＰ）の値の制御信号に対するリクエストを複数の遠隔配置対話ユニットのうち１つから受信するステップであって、前記リクエストは、前記ＲＣＰの現在値、前記ＳＥＲの指定値、および前記ＳＥＲに関する１つ以上のローカル環境パラメータ（ローカルＣＥＲ）の現在値を含み、前記ＳＥＲの現在値は、前記ＲＣＰおよび前記１つ以上のローカルＣＥＲの前記現在値から計算され得る、ステップと、前記リクエストインターフェイス処理部において受信された前記リクエストを予め定義されたルールに従って処理し、前記ＲＣＰに関する前記制御信号を生成するステップと、リクエストを行っている遠隔配置対話ユニットに前記生成された制御信号を送信するステップとを含み、前記処理ステップは、前記遠隔配置対話ユニットに関連付けられた複数の現在の外部環境パラメータ（外部ＣＥＲ）を単一の外部ＣＥＲパラメータに分類するステップと、前記ＲＣＰの前記現在値および前記１つ以上のローカルＣＥＲの前記現在値に前記ルールを適用することによって前記ＳＥＲの前記現在値を計算するステップと、前記ＳＥＲの前記現在値に対する前記複数の現在の外部ＣＥＲの影響を判定するために、前記単一の外部ＣＥＲパラメータの前記値を用いて前記ＳＥＲの前記現在値をカテゴリー分類するステップと、前記ＳＥＲの前記カテゴリー分類された現在値を前記ＳＥＲの前記指定値と比較し、前記ＳＥＲの前記現在値と前記指定値との相違度の分類に応じて、前記ＳＥＲの前記現在値と前記ＳＥＲの前記指定値とが同等となるように前記ＲＣＰの前記値を調整するための対応する所定のアクションを選択するステップと、前記選択された所定のアクションを用いて前記制御信号を形成して、前記リクエストを行っている遠隔配置対話ユニットについての前記ＲＣＰの現在値を、前記ＳＥＲの前記指定値を満たすように調整するステップとを含む。
【0024】
実施形態の前述の特徴は、種々の方法で組み合わせが可能であり、本発明の実施形態の以下の具体的な説明において具体的に記載されていない場合には、当該説明に追加することができる。
【図面の簡単な説明】
【0025】
本発明の理解をより容易にするため、例として、添付の図面を参照する。
【図1A】複数の遠隔対話ユニットおよびそれらの関連システムならびに外部情報ソースと組み合わせた中央制御システムを示す概略ブロック図であり、本発明の実施形態に係る使用シナリオを示す図である。
【発明を実施するための形態】
【0026】
以下、添付の図面を参照しながら、具体的な実施形態について説明する。
【0027】
まず図１Ａを参照すると、本発明の第１実施形態に係る中央制御システム１０のための使用シナリオが示されており、同システムは、取るべきアクションを決定し、１つ以上の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄから当該アクションを実行するための制御信号を生成するためのリクエストを処理し、１つ以上の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが取ることができるアクションは、典型的には、１つ以上の制約環境要件（ＣＥＲ）によって制限されており、ＣＥＲのうち１つ以上は、遠隔対話ユニットのローカル電子制御部（図示せず）によって指定され、指定環境要件（ＳＥＲ）と称される。ローカル電子制御部は、特定のアクションを実行する遠隔対話ユニットによって直接制御できる適した環境制約を決定するように構成されており、ローカル電子制御部は、この環境制約をＳＥＲとして指定する。別の実施形態において、ＳＥＲは、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのユーザによって選択されてもよい。ＣＥＲ、特にＳＥＲは、典型的には、１つの特定の値、または値の範囲のいずれかとして定量的に表される。
【0028】
これらのＣＥＲは、特定の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが存在するローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄに特有であってもよく、したがって、関連遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄにのみ影響する。特に、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのユーザによって指定されたＳＥＲは、ローカルＣＥＲの非限定的な例である。これらのローカルＣＥＲは、典型的には、関連ローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄの一部を形成するハードウェアメモリ（図示せず）などのローカルデータ格納部に格納されており、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、このローカルデータ格納部にアクセスしてローカル環境要件を検索するように構成される。ローカルデータ格納部は、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄの一部を形成するように構成されてもよい。
【0029】
ＣＥＲは、ローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄの外部にあってもよく、複数の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのアクションを制限するように機能してもよい。このような外部ＣＥＲは、典型的には、１つ以上の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに事前に知られておらず、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄまたは中央制御システム１０が制約の影響を受けてはじめて知られるものである。なお、図示の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄの数は、あくまでも例示を目的としたものであり、典型的には、数万個の遠隔対話ユニットがシステムと任意の時点で動作している。
【0030】
図１Ｂは、本発明の一実施形態における様々な種類のすべての制約環境要件（ＣＥＲ）２１０間の潜在的関係を説明するための例を示す。最初の分割により、ＣＥＲは、ローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄに固有のもの（ローカルＣＥＲ２１２と称する）と、ローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄの外部にあるもの（外部ＣＥＲ２１４と称する）とに分けられる。上記説明に従って、ローカルＣＥＲ２１２は、自身が存在するローカル環境に固有の複数の個別ＣＥＲ２１６Ａ、２１６Ｂ、２１６Ｃを含む。図示の例では、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのローカル電子制御部、またはローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄに関連付けられた遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのユーザによって指定された１つのＳＥＲ２１６Ａも示されており、このＳＥＲは、上記に示したローカルＣＥＲのうちの１つである。同様に、外部ＣＥＲ２１４は、ローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄの外部にあり、複数の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのアクションを制限するように機能することができる複数の個別ＣＥＲ２１８Ａ、２１８Ｂ、２１８Ｃを含む。なお、図１Ｂに示すローカルＣＥＲ２１６Ａ、２１６Ｂ、２１６Ｃおよび外部ＣＥＲ２１８Ａ、２１８Ｂ、２１８Ｃの数は、あくまでも例示を目的としたものである。
【0031】
図１Ａの使用シナリオに戻ると、取るべきアクションは、典型的には、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって利用される特定のコマンドパラメータを変更することによって決定され得、この特定のコマンドパラメータが変更されると、アクションが取られる。このコマンドの実行は、典型的には、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが存在するローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄにおける少なくとも１つの対応するシステムの動作条件に影響する。ローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄは、典型的には、多数のシステムを含み、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが取るアクションがこれらのシステムのサブセットの動作条件にのみ影響するように構成されてもよい。
【0032】
遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、典型的には、外部通信ネットワーク２２を介して中央制御システム１０に自身のリクエストを送信するように構成される。次いで、中央制御システム１０は、１つ以上のローカルデータベース１２、１４、１６にアクセスして、受信されたリクエストを中央制御システムが有効に処理することを可能にすると共に、当該リクエストの結果を必要に応じて格納するように構成されてもよい。いくつかの実施形態において、データベース１２、１４、１６は、中央制御システム１０とは異なる物理的位置に配置されており、通信ネットワーク（例えば、クラウド・ストレージ・ソリューションの場合）を介して中央制御システム１０に結合されている。加えて、他のいくつかの実施形態において、中央制御システム１０は、Application Programming Interfaces（ＡＰＩ）、ローカルファイル、キャッシングシステムまたはメッセージングシステムからデータを検索するように構成されてもよく、同様に、リクエストの結果は、ＡＰＩ、ローカルファイル、キャッシングシステムまたはメッセージングシステムに送られてもよい。ローカルデータベース１２、１４、１６に格納された情報は、受信されたリクエストをどのようにして処理するかを中央制御システム１０に対して指示することが可能な１組の規定ルール１１Ａ、１１Ｂ、１１Ｃを含む。ローカルデータベース１２、１４、１６に格納された情報は、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄおよびそれらに関連付けられた環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄに関する定性情報および定量情報（図示せず）をさらに含んでいてもよく、当該情報は、受信されたリクエストを中央制御システム１０が処理するために必要である。ローカルデータベース１２、１４、１６に格納された情報は、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって行われた以前のリクエストに関する履歴情報（図示せず）も含んでいてもよく、当該情報は、現在のリクエストの処理において使用され得る。中央制御システム１０は、処理されたリクエストの結果を１つ以上のデータベース１２、１４、１６に格納するように構成されてもよい。前述の情報は、単一のハードウェアデータベースに格納されてもよく、あるいは複数のハードウェアデータベースに格納されてもよい。あるいは、１つ以上のデータベースは、データの検索または格納を行うために中央制御システム１０によって使用されるＡＰＩ、メッセージングシステムまたはイベントシステムであってもよい。
【0033】
受信されたリクエストを処理する際、中央制御システム１０は、１つ以上の外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃにアクセスし、そこから情報を検索するようにさらに構成されてもよい。これらの外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃのそれぞれは、要求された情報を中央制御システム１０に提供するように構成されたインターフェイス２５を含む。これらは、要求された情報が格納され、中央制御システム１０からの情報リクエストの受信時にインターフェイス２５がアクセスするように構成された、１つ以上のデータベース２６Ａ、２６Ｂ、２６Ｃをさらに含む。外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃは、ＡＰＩ、イベントシステムまたはメッセージングシステムを介して中央制御システム１０と通信してもよい。要求された情報は、中央制御システム１０がその機能、すなわち、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって生成されたリクエストの処理を実行するのに役立つ任意の情報を含む。要求された情報は、１つ以上のローカルデータベース１２、１４、１６から入手できない情報も含んでいてもよい。
【0034】
特に、中央制御システム１０が外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃにアクセスすることが可能であるということにより、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが取るべきアクションを決定するためにリクエストを処理する際に明確な利点がもたらされる。先のシステムにおける中央制御システム１０および遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、いずれも、局所的な情報にアクセスを有するが、前述の通り、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄおよびこれらが動作するローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄに対して直接的な影響を有し得る外部因子がしばしば存在する。これらは、前述の非局所的な外部ＣＥＲの形態を取り得る。局所的な情報のみでは、取るべきアクションの計算において、これらの外部因子を考慮にいれることが必然的にできなくなり、したがって、結果として取られるアクションは、最適以下となり得る。これにより、取られるアクションを後で調整することが必要となる場合があり、いくつかのシナリオにおいては、最適以下のアクションは、当初の所望の目的を達成する程度に修正することができない場合がある。外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃへのアクセスを提供するにあたり、中央制御システム１０は、これらの外部因子に関する情報をその計算に含めることができ、当該情報は、このような外部因子に関する現在および将来の予測の両方を含んでいてもよい。いくつかの実施形態において、外部ＣＥＲに関する情報は、中央制御システム１０の内部データベース１２、１４、１６においても入手可能であってもよい。これは、例えば、中央制御システム１０がこのような情報を外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃから以前に検索し、格納した場合に起こり得る。
【0035】
なお、以下の説明において、要求された制御パラメータの計算について言及する場合、この計算は、対応するアクションが、制御パラメータの計算済みの値が供給されたＣＥＲに準拠しているか否か、よって、取るべきアクションが、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが指定制約内で動作することを可能にするか否かを判定する効果を計算することをさらに含む。
【0036】
中央制御システム１０は、受信されたリクエストが処理された場合、その結果が、中央制御システム１０が遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄから上記計算の結果についてのリクエスト（すなわち、プルリクエスト）を受信した時点で、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに送信されるように構成される。遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが中央制御システム１０とは別に配置され、かつこれら両要素間の通信が、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ、例えば、ローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄが無線通信範囲が不良な領域に位置していることによって中断されやすい本システムにおいて、プルシステムは有利である。遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、計算を受信できる状態である場合、例えば、このようなリクエストを中央制御システム１０から確実に検索できる場合にのみ、当該計算の結果を要求するように構成されてもよい。遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、無線信号の送受信に関連する構成要素が、使用中でないときにはパワーダウンされ、それにより、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄの総電力消費を低減するように構成されてもよい。上記に示した電気自動車の例に戻ると、このことは特に有用である。なぜなら、電力は、分配すべき資源を含む場合があり、不要な電力消費を削減することは、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが効率的に機能するために重要となり得るからである。さらに、何千個もの遠隔対話ユニットを有する分散システムにおいて、中央サーバは、計算結果を複数の遠隔対話ユニットに常にプッシュしようとするならば非常にビジーな状態になり得る。処理用資源のこのようなボトルネックと消耗は、本実施形態のプルシステムを用いることによって回避される。
【0037】
図１Ａの中央制御システムのいくつかの実施形態において、中央制御システムは、別の遠隔対話ユニットについての計算を要求するプロキシとして機能する遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄからのリクエストを受信するように構成されてもよい。電気自動車の例に戻ると、これは、車両集団の中の１台以上の車両が取るべきアクションを決定するためのリクエストを送出するように構成された車両集団制御部を含んでいてもよい。このような実施形態において、制御システム（１０）によって計算されるＳＥＲは、元のリクエストを行った遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄの外部にあるので、外部ＣＥＲ２１８Ａ、２１８Ｂ、２１８Ｃを含んでいてもよい。この場合、取るべきアクションは、当該リクエストを行った遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄの動作条件に影響しない場合がある。代わりに、取るべきアクションは、当該リクエストが関連している別の遠隔対話ユニットにローカルな環境の動作条件に影響し得る。
【0038】
いくつかの実施形態において、中央制御システム１０は、１つのＳＥＲに対応する１種類の計算を実行することができるように構成されてもよい（ただし、計算は複数の遠隔対話ユニットに関して行われ得る）。前述の電気自動車の例に戻ると、電気自動車１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、特定の条件がトリガされた時点でリクエストを送るように構成されてもよい。例えば、これは、車両が特定の充電レベルに達し、その後まもなく再充電が必要となる場合を含んでいてもよい。本例において、ＳＥＲ（充電レベルである）は、すべての遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄから受信されたすべてのリクエストについて同じとなる。その結果、指定ＳＥＲ（所望の充電レベル）は、システムにとって既知であり得るため、中央制御システム１０に対して提供されなくてもよい。同様に、現在のＳＥＲ（現在の充電レベル）は特定のトリガされたリクエストの受信から分かる（予め定められている）ため、システム（１０）は、これを計算しなくてもよい。なぜなら、同システムは、この単一のシナリオにおいてのみ、要求された制御パラメータ（例えば速度）に関して制御信号の決定を行うように構成されるからである。ＳＥＲに関する情報は、１つ以上のローカルデータベース１２、１４、１６に格納されてもよい。
【0039】
次に図２Ａを参照すると、本発明の第１実施形態に係る中央制御システム１０がより詳細に示されている。本システム１０は、取るべきアクションを決定するためのリクエストを処理し、１つ以上の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに対して当該アクションの実行を指示するための制御信号を生成する。図２Ａにおいては、簡明を期すために、１つの遠隔対話ユニット１８Ａのみが示されているが、多数の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄがリクエストを送出することができ、これらのリクエストが本発明の一実施形態に従って中央制御システム１０によって同時に並行して扱われ得ることが理解される。遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、典型的には、外部通信ネットワーク２２を介して中央制御システム１０にリクエストを送信するように構成される。
【0040】
中央制御システム１０は、遠隔対話ユニット１８Ａからのリクエストを受信するリクエストインターフェイス処理部３０を含む。リクエストインターフェイス処理部３０は、受信されたリクエストを受信し、かつ中央制御システム１０によってさらに処理されるのに適したフォーマットとなるように処理するように構成される。この情報処理は、リクエストを実行するために中央制御システム１０によってどの情報を検索する必要があるかを判定することを含んでいてもよい。さらに、この処理は、単一のリクエストを複数のリクエストに分割すること、または自動的に生成された情報（例えば、日付、タイムスタンプ、固有識別子）をリクエストのデータ構造に付加することを含んでいてもよい。リクエストのデータ構造は、どの情報を検索する必要があるかをリクエストインターフェイス処理部３０に指示するために構成される。リクエストのデータ構造は、リクエストを中央制御システム１０および遠隔対話ユニット１８Ａによって後で追跡することを可能にする固有リクエスト識別子をさらに含んでいてもよい。
【0041】
リクエストは外部通信ネットワーク２２を介して受信されるので、リクエストが送信中に何らかの形のデータ破損を起こし得るか、あるいは、遠隔対話ユニット１８Ａがリクエストの処理に必要なすべての情報を提供しなかったということが考えられる。本発明のいくつかの実施形態において、リクエストインターフェイス処理部３０は、リクエストの正確性および完全性を確認し、データが完全かつ未破損である場合にのみリクエストを処理するようにさらに構成されてもよい。
【0042】
ひとたびリクエストが処理されると、当該リクエストは、次いで、リクエストインターフェイス処理部３０に結合されたリクエストキュー３２に渡されてもよく、処理が可能となるまでそこで保持される。リクエストキューは、リクエストのステータスのリアルタイムレコード、特に、当該リクエストがプロセス待機中であるか、処理中であるか、あるいは処理済みであるかについてのリアルタイムレコードを保持するように構成された通知システム３４にさらに結合されている。例えば、リクエストがキュー３２に入ると、リクエストが処理待機中であることを示すようにリクエストのステータスを更新すべきであることを示す命令が通知システム３４に送られる。通知システム３４は、最初の情報リクエストのステータスに関する情報について対話ユニット１８Ａからクエリを受信するようにも構成され、そして、このクエリの受信時にこのリクエストステータス情報を遠隔対話ユニット１８Ａに提供するようにさらに構成される。
【0043】
リクエストインターフェイス処理部３０が、前述のようにリクエストの正確性および完全性を確認するように構成される本発明の一実施形態において、リクエストインターフェイス処理部３０は、リクエストが処理できない場合、遠隔対話ユニット１８Ａに通知するように構成されてもよい。これは、例えば、リクエストインターフェイス処理部３０がさらに通知システム３４に結合されることによって行われるが、リクエストが処理できない場合、リクエストインターフェイス処理部３０は、リクエストのステータスが処理不可能であることを示す命令を通知システム３４に送るように構成されてもよい。
【0044】
次にリクエストキュー３２に移ると、キュー３２は、パラメータ計算システム３６にさらに結合されており、パラメータ計算システム３６は、リクエストを処理し、遠隔対話ユニット１８Ａによって最初に要求された制御パラメータの値を計算するように構成される。キュー３２の先頭にあるリクエストが処理可能であると判定された場合、キュー３２は、要求された制御パラメータが計算され得るようにパラメータ計算システム３６にリクエストを提供するように構成される。この時点で、キュー３２はまた、リクエストのステータスが処理中に変わったことを通知システム３４に指示するように構成される。パラメータ計算システム３６は、要求された制御パラメータを計算するために、必要に応じて、内部データベース１２、１４、１６および外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃのいずれかに対して情報を要求することができるように構成される。要求された情報は、最初のリクエストの一部であると判定される。この情報は、上記説明に従ってアクセスされ得る。
【0045】
パラメータ計算システム３６は、内部パラメータ結果格納部３８にさらに結合されている。制御パラメータの計算が完了すると、パラメータ計算システム３６は、計算の結果を、計算結果をその計算を開始させたリクエストに関連付けることを可能にする付加情報と共にパラメータ結果格納部３８に格納するように構成される。例えば、これは、前述のような固有識別子を含んでいてもよい。計算済みの制御パラメータがパラメータ結果格納部３８によって格納された場合、パラメータ計算システム３６は、この計算が完了したことをリクエストキュー３２に知らせるようにさらに構成される。次いで、リクエストキュー３２は、その後、制御パラメータが計算済みであることを示すように通知システム３４のリクエストのステータスを更新する。
【0046】
中央制御システム１０は、パラメータ結果格納部３８に結合されたパラメータ・リクエスト・ハンドラ（送信部）４０をさらに備える。パラメータ・リクエスト・ハンドラ４０は、パラメータ結果格納部３８にアクセスして特定のリクエストに関連付けられた計算済み制御パラメータを検索するためのプル命令を遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄから受信し、その後、遠隔対話ユニット１８Ａに、この計算済み制御パラメータを当該遠隔配置対話ユニットのための有効制御信号として提供するように構成される。このような命令は、リクエストのステータス、すなわち、制御パラメータが計算済みであり、したがって検索可能な状態にあるということを通知システム３４から判定し、その後、制御パラメータを検索するように指示する遠隔対話ユニット１８Ａによって開始されてもよい。特定のリクエストに関連付けられた計算済み制御パラメータにアクセスするために、遠隔対話ユニット１８Ａからの命令は、前述の固有識別子などの情報を含んでいてもよく、パラメータ・リクエスト・ハンドラ４０は、この情報を用いてパラメータ結果格納部３８から正確な計算済み制御パラメータを検索するように構成されてもよい。パラメータ・リクエスト・ハンドラは、リクエストキュー３２に結合されるようにさらに構成される。要求された制御パラメータが検索され、遠隔対話ユニット１８Ａに供給されると、パラメータ・リクエスト・ハンドラ４０は、制御パラメータが検索されたこと、およびリクエストがキュー３２から取り除かれてもよいことをリクエストキュー３２に知らせる。次いで、リクエストキュー３２は、その後、制御パラメータが検索されたことを示すようにリクエストのステータスを更新するよう通知システム３４に指示する。さらなる実施形態において、通知システム３４に格納される通知は、制御パラメータが計算されてから設定時間が経過した後に取り除かれるように構成されてもよい。これにより、古い通知や無関係な通知によって通知システムが過負荷状態となることが防止される。同様に、いくつかの実施形態において、リクエストは、この時にリクエストキュー３２から取り除かれてもよい。
【0047】
ひとたび制御パラメータが遠隔対話ユニット１８Ａに供給されると、供給された制御パラメータに基づいて、遠隔対話ユニット１８Ａによってアクションが自動的に開始されてもよい。本発明の別の実施形態において、パラメータ・リクエスト・ハンドラ４０は、計算済み制御パラメータに基づいて特定のアクションを取るよう遠隔対話ユニット１８Ａに命令するコマンド信号を遠隔対話ユニット１８Ａに送るように構成されてもよい。
【0048】
次に図２Ｂを参照すると、本発明の中央制御システム１０の別の実施形態がより詳細に示されており、この実施形態において、システムは、リクエストデータ構造から１つ以上の情報パラメータを取り出し、リクエストが処理されている間、それらをパラメータ結果格納部３８に格納するように構成される。これは、リクエストを識別するために必要でないすべての情報パラメータを格納することを含んでいてもよい。例として、これは、固有リクエスト識別子以外の情報パラメータをすべて格納することを含んでいてもよい。リクエストのデータ構造は、情報パラメータを分離することを可能にして、それらをリクエストから取り出し、パラメータ結果格納部３８に格納することができるように構成される。図３を参照し、リクエストのデータ構造についてより詳細に説明する。本実施形態により、リクエストインターフェイス処理部３０、リクエストキュー３２、通知システム３４およびパラメータ計算システム３６の間で送信されるデータリクエストのサイズを可能な限り小さくし、それによって、リクエストが送信され得る速度を高め、結果として全体的な処理速度を高めることが可能となる。典型的には、格納される情報パラメータは、リクエストの処理のある特定の段階中にのみ必要となる。本実施形態において、これらの情報パラメータは、リクエストの処理を可能にするために必要なときにのみアクセスされる。
【0049】
なお、個々の構成要素の機能および中央制御システム１０の全体の概略的な機能は、他の実施形態に関して前述したものと同様である。この理由および簡潔のため、以下の説明では、図２Ａの中央制御システム１０と図２Ｂに示す本実施形態との差異についてのみ着目する。
【0050】
本実施形態において、リクエストは、リクエストインターフェイス処理部３０によって遠隔対話ユニット１８Ａから受信される。リクエストデータを受信すると、リクエストインターフェイス処理部３０は、リクエストをリクエストキュー３２、通知システム３４およびパラメータ計算システム３６によって識別可能とするためにどの情報パラメータが必要であるかをまず識別するように構成される。いくつかの実施形態において、これは、固有リクエスト識別子を含んでいてもよい。次いで、必要でない情報パラメータが、データリクエスト構造から取り出され、リクエストインターフェイス処理部３０に通信可能に結合されたパラメータ結果格納部３８に渡される。次いで、これらの情報パラメータは、パラメータ結果格納部３８に格納される。格納される情報パラメータは、リクエストの処理ステータスに関する情報を含んでいてもよい。このようなパラメータが最初に要求されたとき、要求された制御パラメータの計算が可能な場合、そのステータスを「処理待機中」としてもよい。リクエストインターフェイス処理部３０が最初のリクエストの正確性および完全性を判定するように構成された実施形態において、ステータスは、「処理不可能」としてもよく、リクエストは、リクエストキュー３２に進むことはない。いくつかの実施形態において、上記実施形態において説明したように、リクエストインターフェイス処理部３０は、次いで、リクエストが処理不可能であることを遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに通知するように構成されてもよい。
【0051】
上記のようなリクエストを識別するために必要な情報パラメータは、コピーされてもよく、送信されてもよく、かつ、取り出された情報パラメータに関連付けて格納されてもよい。これは、取り出された情報パラメータを、それらがその後アクセスされたときに特定のリクエストに関連付けることができるようにするためである。
【0052】
リクエストデータ構造から分離されなかった情報パラメータは、次いで、リクエストキュー３２に渡され、リクエストは、処理可能な状態になるまでそこで保持される。次いで、リクエストは、前述の実施形態と類似の方法で、中央制御システムの中を進む。要求された制御パラメータを計算するために、リクエストがパラメータ計算システム３６に到達したとき、リクエストデータ構造に含まれる残りの情報パラメータは、パラメータ計算システム３６にどのように計算を実行するかを指示するのに十分でない場合がある。本実施形態において、リクエストデータがパラメータ計算システム３６によって受信されると、パラメータ計算システム３６は、リクエストについて格納された情報パラメータを、自身が通信可能に結合されているパラメータ結果格納部３８から検索するように構成される。これを可能にするため、パラメータ計算システム３６は、識別情報パラメータを用いて、関連情報パラメータをパラメータ結果格納部に問い合わせ、その後、制御パラメータの計算に用いるためにそれらを検索するように構成される。計算が完了すると、パラメータ計算システム３６は、リクエストのステータスに関する、パラメータ結果格納部３８に格納された情報パラメータを「処理済み」とするように更新するように構成される。これは、遠隔対話ユニット１８Ａに計算が完了したことを通知するよう通知システム３４に指示するためにリクエストキュー３２にその旨を通知することと併せて行ってもよく、あるいは、計算済み制御パラメータをパラメータ結果格納部３８に格納することと併せて行ってもよい。
【0053】
通知システム３４は、遠隔対話ユニット１８Ａにリクエストのステータスを通知する際、格納された情報パラメータを検索するために、パラメータ結果格納部３８にさらに通信可能に結合される。例えば、計算が完了した旨の通知を提供するよう指示されたとき、通知システム３４は、その通知を送信する前に、識別情報パラメータを用いて、リクエストのステータスに関する情報パラメータまたは他の所要情報を検索してもよい。
【0054】
図２Ａおよび図２Ｂの中央制御システム１０のさらなる実施形態において、中央制御システム１０は、制御パラメータが計算されたとき、自動的に遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに通知するように構成されてもよい。この通知は、リクエストキュー３２が、通知システムに対し、要求された制御パラメータが計算されたことを指示するときに通知システム３４から送られるプッシュ通知の形態を取ってもよい。これは、元のリクエストを送出した遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが、アクションを決定する対象である遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄとは異なる場合に、上記実施形態において特に有用であり得る。このシナリオにおいて、これらの遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのうちの第２の遠隔対話ユニットは、元のリクエストに関連して自身がアクションを取る必要があることを認識していない場合がある。その結果、通知に対して定期的で推測的なプルリクエストを行うように第２の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄを構成することは、非効率的となり得る。よって、アクションが必要とされる場合にプッシュ通知を提供するように中央制御システム１０を構成することがより効率的である。ただし、プッシュ通知構成は、前述の実施形態のプルシステムと併せて利用されてもよいことが理解される。例えば、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、計算済み制御パラメータのプル命令を開始することが可能であってもよい。
【0055】
さらに、ある特定の実施形態において、パラメータ計算システム３６が計算を完了したとき、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄにリクエストキュー３２を通知するために送られる命令は、すぐに処理されなくてもよい。代わりに、パラメータ計算システム３６は、この通知をリクエストキュー３２に送るためのリクエストを送るように構成されてもよい。次いで、この通知は、リクエストがリクエストキュー３２の先頭に到達して初めて通知システム３４に送られる。このような実施形態において、リクエストキュー３２は、この種のリクエストと制御パラメータ計算リクエストとを区別するように構成される。リクエストの種類が判定されると、リクエストキューは、次いで、リクエストの種類に応じてアクションを実行する。以下に、図４Ａ、図４Ｂおよび図４Ｃを参照し、リクエストキューが行う方法についてより詳細に説明する。
【0056】
図３に移ると、リクエストインターフェイス処理部３０によって受信されるために遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに送られ得るリクエストの例示的なデータ構造２３０が示されている。データ構造２３０は、複数の情報パラメータを含み、これらは、リクエストを一意に識別する目的および要求された制御パラメータ（ＲＣＰ）の値を提供するために中央制御システム１０がどのようにリクエストを処理すべきかを判定する目的の両方に使用されてもよい。これらの情報パラメータはすべて、リクエストの処理全体を通して不変または静的であるように構成されてもよい。この場合、新たなリクエストは、情報パラメータのいずれかが変化した場合に送出されることが必要となる。あるいは、上記構造は、情報パラメータが遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄからの命令に応じて変化するように構成されてもよい。これにより、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、全く新たなリクエストを送る必要なしに、以前に送られたより短い更新リクエストの形態でリクエストに対する変更を送ることが可能となる。
【0057】
情報パラメータは、固有リクエスト識別子２３２を含んでいてもよく、これは、リクエストインターフェイス処理部３０による受信時にリクエストに割り当てられてもよく、あるいは、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄがパラメータ計算リクエストを開始するときに割り当てられてもよい。情報パラメータは、リクエストのリクエスト元である遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄを識別するリクエストのソース２３４をさらに含んでいてもよい。情報パラメータは、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって計算すべき要求された制御パラメータ（ＲＣＰ）の識別子をさらにまた含んでいてもよい。同様に、情報パラメータは、計算すべきＲＣＰ２３８の現在値を含んでいてもよい。これは、以下に説明するように、リクエストを処理するために提供されてもよい。いくつかの実施形態において、ＲＣＰの現在値は、不明であってもよく、計算される必要があってもよいので、必ずしも提供されなくてもよい。これは、ＲＣＰの現在値の計算が、最初のリクエストを行わなかった１つ以上の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８ＤのローカルＣＥＲに関する情報を必要とする場合に起こり得る。情報パラメータはまた、処理すべきリクエストのステータス２３６を含んでいてもよく、これは、典型的には、リクエストが中央制御システム１０の機構を進むにつれて更新される。
【0058】
情報パラメータは、前述の実施形態に係る遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって指定されたＳＥＲ２４０を含む、制御パラメータの値を提案する際に上記計算が考慮に入れる１つ以上のＣＥＲ２４０、２４２、２４４をさらにまた含んでいてもよい。各リクエストにおいて指定されたＳＥＲは、当該リクエストの固定値を取り、満たすことが所望される指定環境制約に向けられたものである。アクションが実行され得るように計算すべき制御パラメータを遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが要求するとき、これには、典型的には、結果として取られるアクションが、対応するローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄをある特定の動作条件に準拠させるものであることも必要となる。この情報は、制御パラメータの計算を準備する際に考慮に入れられる。情報パラメータは、リクエストを処理するために中央制御システム１０がローカルデータベース１２、１４、１６および／または外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃから検索する必要がある所要情報２４６、２４８、２５０の識別子をさらに含んでいてもよい。これらは、外部ＣＥＲのリクエスト、適切な計算ルール１１Ａ、１１Ｂ、１１Ｃのリクエストおよび現在のリクエストに関する履歴情報を含んでいてもよい。別の実施形態において、このような所要情報２４６、２４８、２５０は、リクエストによって促されることなく、中央制御システム１０によって識別されてもよい。これは、計算すべき制御パラメータを評価する際にシステムがこのような所要情報を識別することができることによって可能となり得る。
【0059】
遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが第２の遠隔対話ユニットに対するリクエストを開始する特定の実施形態において、データ構造２３０は、計算が行われる対象となる、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに関するプロキシ情報パラメータをさらに含んでいてもよい。
【0060】
図４Ａは、中央制御システム１０の一実施形態の動作方法５０を詳細に示している。システム１０は、ステップ５２において、前述の実施形態に係る遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄから制御パラメータ計算リクエストが受信されたとき、動作を開始する。リクエストは、リクエストインターフェイス処理部３０によって受信される。リクエストの受信に続いて、ステップ５４において、リクエストインターフェイス処理部３０によってリクエスト自体が処理される。この処理は、リクエストが、中央制御システム１０によるさらなる処理に適したフォーマットにあること、リクエストを処理するためにどの情報が必要であるかを判定すること、リクエストに固有識別子を割り当てること、およびリクエストを確実に処理することができるようにリクエストの正確性および完全性を確認することのうちいずれか１つ以上を保証することを含んでいてもよい。
【0061】
これに続いて、ステップ５６において、リクエストがリクエストキュー３２に入れられ、同時に、このリクエストに対応するエントリを生成し、そのステータスを「処理中」として指定する命令が通知システム３４に送られる。ひとたびリクエストがキュー３２に配置されると、次いで、ステップ５８において、リクエストがキュー３２の先頭にあるか否か、したがってリクエストが処理可能であるか否かが判定される。なお、本発明の実施形態において、以前のリクエストが、処理されなくなった状態でキューに残っていることが考えられ得る。これは、上記の説明に従って、制御パラメータが計算されかつ検索されて初めてリクエストが取り除かれる場合にあてはまる。この場合、現在のリクエストがキュー３２の先頭に位置するためには、ステータスが「未処理」または「処理中」であるリクエストのキューの先頭にあるだけでよい。加えて、特定の実施形態において、パラメータ計算システム３６は、多数のリクエストを同時に処理することが可能であってもよい。この場合、現在のリクエストがキュー３２の先頭に位置するためには、ステータスが「未処理」であるリクエストのキューの先頭にあることと、他のリクエストが処理中であり得るが、現在のリクエストを追加で処理するのに十分な資源がシステム内に存在することとが必要となる。
【0062】
リクエストが上記実施形態のいずれかに係るキューの先頭にあると判定された場合、リクエストおよびその他の付加メタデータがパラメータ計算システム３６に渡され、次いで、ステップ６０において、制御パラメータが計算される。制御パラメータの計算に含まれるこれらのステップについて、以下にさらに説明する。ただし、ステップ５８において、関連実施形態に係るキュー３２の先頭にリクエストがないと判定された場合、システム１０は、ステップ５９において、関連実施形態に係るキュー３２の先頭にリクエストがくるまで待機するように構成される。ひとたびリクエストがキュー３２の先頭に到達すると、リクエストはパラメータ計算システムに渡され、ステップ６０において、制御パラメータが計算される。
【0063】
ひとたび制御パラメータが計算されると、ステップ６２において、制御パラメータは、パラメータ結果格納部３８に格納される。この時点で、計算済み制御パラメータが格納されたことがリクエストキュー３２に通知され、これに応じて、対応するリクエストに関するエントリを、そのステータスを「処理済み」として指定するように更新する命令が通知システム３４に送られる。計算済み制御パラメータがパラメータ結果格納部に格納されたとき、計算の結果もまた、さらなる計算においてパラメータ計算システム３６によってアクセス可能となるように内部データベース１２、１４、１６のうち１つ以上に格納されてもよい。１つ以上の内部データベース１２、１４、１６に格納される計算結果は、パラメータ結果格納部に格納される情報とは異なるように構成されてもよい。例えば、データベース１２、１４、１６に格納される情報は、実行された計算に関するリクエストまたは所要情報の条件に関するデータを含んでいてもよい。これにより、上記データベースのうち１つから単に情報を検索すればよく、積極的な計算が必要とされないため、同じ条件での同じ制御パラメータに対するその後のリクエストをより早く実現することが可能になるという利点がもたらされる。加えて、この構成により、データの検証およびメンテナンス／トラブルシューティングをより容易にすることができる。
【0064】
上記のプロセス５０に戻ると、ステップ６２において、ひとたび計算済み制御パラメータが格納されると、ステップ６４において、システム１０は、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが、パラメータ・リクエスト・ハンドラ４０を介して、パラメータ結果格納部３８から制御パラメータを検索することを要求したか否かを判定するように構成される。これは、典型的には、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが、通知システム３４に対してステータスの更新を要求し、制御パラメータの計算が完了したことを知らされた後に起こる。遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが制御パラメータの検索を要求したと判定された場合、ステップ６６において、パラメータ・リクエスト・ハンドラ４０は、計算済み制御パラメータをパラメータ結果格納部３８から検索し、計算済み制御パラメータを、それを要求した遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに送信するように構成される。同時に、パラメータ・リクエスト・ハンドラ４０は、制御パラメータが検索されたことをリクエストキュー３２に通知するように構成され、リクエストのステータスを「検索済み」に更新する命令が通知システム３４に送られる。前述のシステム１０のいくつかの実施形態によると、計算済み制御パラメータが検索されると、リクエストキュー３２および／または通知システム３４は、これら２つの構成要素が無関係なリクエストや古いリクエストによって過負荷状態とならないように、対応するリクエストを削除するように構成されてもよい。
【0065】
ステップ６６に続いて、あるいは、ステップ６４において、計算済み制御パラメータが要求されなかったと判定された場合、方法５０は、ステップ６８において、別のリクエストが処理に利用可能であるかの判定に進む。このようなリクエストは、前のリクエストの処理中にシステム１０によって受信されている場合がある。あるいは、前のリクエストが受信された後であるが、そのリクエストが処理される前に、受信されている場合がある。ステップ６８において、処理され得る別のリクエストがあると判定された場合、方法５０は、ステップ５８に戻ることによって処理を進め、リクエストがキュー３２の先頭にあり、したがって処理可能な状態であるか否かを判定する。あるいは、現在処理すべきリクエストが存在しないと判定された場合、ステップ７０において、方法５０は、検索を待機している１つ以上の制御パラメータが存在するか否かの判定に進む。まだ検索されていない１つ以上の制御パラメータが存在すると判定された場合、方法５０は、ステップ６４に戻り、制御パラメータのうち１つが要求されたか否かを判定する。代わりに、すべての制御パラメータが検索されたと判定された場合、方法は、最初に戻り、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのうちの１つからの新たな制御パラメータ計算リクエストを待機する。
【0066】
データリクエスト構造の情報パラメータの一部またはすべてが処理中にパラメータ結果格納部３８に格納されるさらなる実施形態において、図４Ａの方法は、これを実現するために適宜変更されてもよい。例として、ステップ５６は、リクエストインターフェイス処理部３０が情報パラメータのうち１つ以上を分離し、それらを、リクエストをリクエストキュー３２に入れる前にパラメータ結果格納部３８に格納するように変更されてもよい。同様に、方法は、ステップ６０といった、格納された情報が必要とされる場合は必ず、格納された情報パラメータに対するアクセスおよび／または変更を含むように変更されてもよい。
【0067】
次に図４Ｂを参照すると、指定された制御パラメータの値のリクエストを送り、その後、制御パラメータの値を中央制御システム１０から検索する際に遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄにおいて実行されるさらなる手順７０が示されている。これは、中央制御システム１０および遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって行われる態様の両方を組み合わせてリクエストが行う全手順を説明するために、図４Ａと組み合わせて示されている。特に、示される手順７０は、リアルタイム環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄで動作する遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄを想定しており、環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄにおける条件が急速に変化し得るということを反映させるために、制御パラメータのリクエストを繰り返し（周期的に）送る。したがって、制御パラメータは、環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄでのシステムの最も効率的な動作ごとに異なる必要がある場合があり、これは、制御パラメータの計算を繰り返し要求することによって行うことができる。本例の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、制御パラメータの計算の手動によるリクエストが中央制御システム１０にいつでも送られ得るように構成されてもよい。
【0068】
遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄにおける手順７０は、ステップ７２において、指定された制御パラメータの値を計算するためのリクエストを中央制御システム１０に送ることによって開始される。
【0069】
いくつかの実施形態において、リクエストが送られた後、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、次いで、ステップ７４において、さらなるステップが実行されるまでの所定の時間待機するように構成される。この所定の時間は、要求された計算が中央制御システム１０によって行われることを可能にするために導入される。所定の時間は、調整可能であってもよい。この調整は、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのユーザによって手動で行われてもよい。あるいは、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、例えば、リクエストの複雑性、制御パラメータを必要とするアクションがタイムクリティカルであるか否か、リクエストの完了にかかる予測時間等の付随因子に応じて、この時間を自動的に調整してもよい。
【0070】
ひとたび所定時間が経過すると、ステップ７６において、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、次いで、中央制御システム１０の通知システム３４からの最初の制御パラメータ計算リクエストのステータス更新を要求し、前述の説明に従って、リクエストのステータスの通知を受信するように構成される。リクエストのステータスを受信すると、ステップ７８において、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、次いで、リクエストが中央制御システム１０によって処理されたか否かを判定する。制御パラメータ計算リクエストがまだ完了していない場合、手順はステップ７４に戻り、さらなる所定時間待機する。ここで、この時間は、最初のステータス更新リクエストを送る前に待機した以前の時間と同じであっても異なっていてもよい。
【0071】
制御パラメータ計算リクエストが完了したと判定された場合、ステップ８０において、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、次いで、計算済み制御パラメータをパラメータ結果格納部３８から検索（プル）するように構成される。これは、計算済み制御パラメータのリクエストをパラメータ・リクエスト・ハンドラ４０に送信することによって行われてもよく、このリクエストは、その後、上記に示した説明に従って遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに返信される前にパラメータ結果格納部３８から検索される。ひとたび制御パラメータが遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって受信されると、ステップ８２において、遠隔対話ユニットは、次いで、検索された制御パラメータに基づいてアクションを実行する。前述のように、このアクションは、典型的には、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが存在するローカル環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄでの少なくとも１つの対応するシステムの動作条件に影響するアクションを含む。遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが第２の遠隔対話ユニットについて計算すべき制御パラメータに関するリクエストを開始する実施形態において、取られるアクションは、第２の遠隔対話ユニットにローカルな環境に影響する。中央制御システム１０のいくつかの実施形態において、パラメータ・リクエスト・ハンドラは、直接制御信号を遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに出力するように構成される。この制御信号は、計算済み制御パラメータに基づいてアクションを実行するよう遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに指示するように構成される。このように、中央制御システム１０は、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが取るべき適切なアクションを、指定制御パラメータの特定の値に対してどのように応答するかを解釈するための当該ユニット自体によるさらなる処理を必要とすることなく、指示し得る。
【0072】
ひとたびアクションが実行されると、手順７０は、次いで、ステップ８４において、中央制御システム１０からの制御パラメータ計算リクエストが遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに手動で入力されたか否かを判定することにより処理を進める。手動で入力された場合、手順７０はステップ７２に戻り、制御パラメータ計算リクエストは、中央制御システム１０に送られて処理に供される。手動によるリクエストが入力されなかった場合、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、ステップ８６において、所定の時間が経過したか否かを判定するように構成される。制御パラメータのリクエストを繰り返し送るように構成された遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄの一実施形態において、この所定の時間は、自動での制御パラメータ計算リクエスト間の時間を含む。前述のように、所定の時間は、上記にその一部を述べた付随因子に応じて、自動でまたは手動で調整可能であってもよい。所定の時間が経過すると、手順７０はステップ７２に戻り、リクエストは、前述のように中央制御システム１０に送られる。所定の時間が経過していない場合、手順７０は、ステップ８４に戻り、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、制御パラメータ計算の手動によるリクエストが入力されたか否かを判定する。
【0073】
次に図４Ｃに移ると、パラメータ計算システム３６の動作方法２６０のさらなる手順が示されており、この手順において、パラメータ計算システム３６は、制御パラメータ計算の完了時に遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄにプッシュ通知を送るためのリクエストをリクエストキュー３２に送るように構成され、リクエストキュー３２は、通知リクエストと制御パラメータ計算リクエストとを区別し、それに応じて動作するように構成される。本実施形態におけるリクエストキュー３２の動作について、図４Ｄを参照してより詳細に述べる。
【0074】
図４Ｃに戻り、手順２６０は、ステップ６０において、パラメータ計算格納部３８が制御パラメータの計算を完了したときに開始される。計算が完了した後、パラメータ計算システム３８は、次いで、ステップ２６２において、要求された制御パラメータをパラメータ結果格納部３８に格納する。情報パラメータも同様にパラメータ結果格納部３８に格納される実施形態において、パラメータ計算システム３６もまた、この時点で必要に応じて関連情報パラメータを更新してもよい。これは、例えば、リクエストのステータスを「処理済み」となるように更新することを含んでいてもよい。
【0075】
要求された制御パラメータがひとたびパラメータ結果格納部３８に格納されると、パラメータ計算システム３６は、次いで、ステップ２６４において、取るべきアクションを決定するための制御パラメータが計算され、当該制御パラメータをパラメータ・リクエスト・ハンドラ４０に対して要求することができることを関連遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに知らせるプッシュ通知を関連遠隔対話ユニットに送ることを要求するリクエストをリクエストキュー３２に送る。リクエストは、リクエストキューが、当該リクエストが通知リクエストであることを識別することができ、かつ当該リクエストが関連している最初の制御パラメータリクエストを識別することができるように構成される。手順２６０は、次いで、ステップ６４において、前述の実施形態に従って、計算済み制御パラメータが要求されたか否かの判定に進む。
【0076】
図４Ｄを参照すると、制御パラメータを計算し、制御パラメータが計算されたことを遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに通知するためのリクエストを受信するようにリクエストキュー３２が構成される実施形態における、リクエストキュー３２の動作方法を示す手順２７０が示されている。これは、図４Ａ、図４Ｂおよび図４Ｃに示す方法と併せて使用されてもよい。手順２７０は、ステップ５８において、リクエストがキューの先頭にあると判定されたときに開始される。本実施形態において、リクエストは、制御パラメータ計算リクエストまたはプッシュ通知リクエストのいずれに関連していてもよい。リクエストキュー３２は、次いで、ステップ２７２において、リクエストの性質、すなわち、リクエストが制御パラメータ計算リクエストであるか、あるいはプッシュ通知リクエストであるかを判定する。制御パラメータ計算リクエストであると判定された場合、手順は、ステップ６０において、要求された制御パラメータの計算に進み、図４Ａおよび図４Ｃに示す手順に従って、処理を継続する。
【0077】
ステップ２７４において、リクエストがプッシュ通知リクエストに関連していると判定されると、リクエストキュー３２は、ステップ２７６において、関連遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄにプッシュ通知を送る旨の命令を通知システム３４に送る。この命令は、通知システムが、通知が送られるべき遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄに加えて、プッシュ通知が関連している最初の制御パラメータリクエストを識別することができるように構成されてもよい。これは、制御パラメータ計算リクエストを開始した遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄを含んでいてもよく、あるいは、前述の実施形態のいずれかに係る第２の遠隔対話ユニットを含んでいてもよい。
【0078】
通知システム３４は、次いで、ステップ２７８において、関連遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄにプッシュ通知を送る。このような実施形態において、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄは、このようなリクエストの受信および処理を行い、その後、提供された情報に基づいて動作することができるように構成される。遠隔対話システム１８Ａ、１８Ｂ、１８Ｃ、１８Ｄにプッシュ通知が送られると、次いで、ステップ２８０において、処理すべき別のリクエストが存在するか否かが判定される。存在する場合、手順２７０は、リクエストの性質を判定するためにステップ２７２に戻る。ステップ２８０において、処理すべき別のリクエストが存在しないと判定された場合、リクエストキュー３２は、ステップ２８２において、次のリクエストがキューに入るのを待機する。ひとたびリクエストが受信されると、手順２７０は、ステップ２７２に戻り、リクエストの性質を判定する。
【0079】
いくつかの実施形態において、リクエストキューは、１つのカテゴリーのリクエストに対して追加で選好を割り当て、当該タイプのリクエストを他のリクエストに優先して処理するようにさらに構成されてもよい。例えば、制御パラメータ計算リクエストは、プッシュ通知リクエストに優先するとされてもよい。このような実施形態において、リクエストキューは、キューにあるすべてのリクエストを検査するように構成されてもよく、優先リクエストが、優先度の低いリクエストより後に処理される予定になっている場合は、優先リクエストがキューにおいてより高い順位に配置されるようにキューの順序を並び替える。これは、複数の制御パラメータ計算リクエストが送出され、完了した計算の通知を提供する前にすべての制御パラメータを計算することが好ましい場合に有利である。
【0080】
なお、図４Ｃおよび図４Ｄに示される実施形態と併せて、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄの対応する方法７０は、プッシュリクエストの受信および処理を可能にするために変更されてもよい。これは、例えば、ステップ７４、７６および７８を、プッシュ通知が受信されるのを待機することを含む単一のステップで置き換えることを含んでいてもよい。同様に、方法７０は、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが第２の遠隔対話ユニットについての制御パラメータ計算を要求する場合、変更されてもよい。この場合、同方法は、リクエストを行う遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄと第２の遠隔対話ユニットとで異なっていてもよい。このような実施形態において、リクエストを行う遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄのための方法は、単にステップ７２を含むものであってもよく、第２の遠隔対話ユニットのための方法は、ステップ７２、７４、７６および７８を、プッシュ通知が受信されるのを待機することを含む単一のステップで置き換えることを含んでいてもよい。
【0081】
図１および図２の中央制御システム１０の実施形態の要素に戻ると、図５は、パラメータ計算システム３６をより詳細に示している。パラメータ計算システム３６は、まず、リクエストキュー３２から制御パラメータ計算リクエストを受信するように構成された情報収集処理部９０を備える。情報収集処理部９０は、制御パラメータ計算リクエストを行うために必要な情報に関する任意のメタデータを分析し、その後この情報を検索するように、さらに構成される。したがって、情報収集処理部９０は、所要情報を当該情報が格納されている場所に対して要求するように適切に構成される。これは、前述の内部データベース１２、１４、１６および外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃを含み得る。情報それ自体は、中央制御システム１０にどのようにして受信されたリクエストを処理するかを指示することができる１組の規定ルール１１Ａ、１１Ｂ、１１Ｃ、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄとそれらに関連付けられた環境２０Ａ、２０Ｂ、２０Ｃ、２０Ｄとに関する定性情報および定量情報、ならびに遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって行われた以前のリクエストに関する情報を含む、上記で説明した情報のいずれを含んでいてもよい。
【0082】
パラメータ計算システム３６は、情報収集処理部９０に結合された予備計算処理部（または分類エンジン）９２をさらに備える。情報収集処理部９０は、最初の制御パラメータ計算リクエストを、当該リクエストに関連付けられた収集済みの情報に付加して、予備計算処理部９２に送信するように構成される。予備計算処理部は、次いで、制御パラメータ計算リクエストが実現されるために必要な収集済みの情報の前処理を実行するように構成される。これは、収集された情報を用いて、制御パラメータ自体の計算の実行に必要な初期計算を実行することを含んでいてもよい。これはまた、さらなる処理に適した形式の収集済みの情報の集計の形式を含んでいてもよい。この集計の結果、収集済みの情報が集計パラメータに分類されるという形式となる。単一の分類への多数のパラメータの簡略化は、典型的には、行列構造１９１（図９に示されるような）を用いて行われる。一実施形態において、例えば、分類エンジン９２は、遠隔配置対話ユニット１８Ａ～１８Ｄに関連付けられた複数の現在の外部環境パラメータ（外部ＣＥＲ）を単一の外部ＣＥＲパラメータ２０２Ａ～２０２Ｃ（後述の図９の説明を参照）に分類するように構成される。
【0083】
単一の制御パラメータ計算リクエストが実現されるためには、収集された情報に対して、複数の初期計算を実行することも必要である場合がある。これらの計算のそれぞれは、収集された情報の異なるサブセットを使用してもよい。これらの計算は、後の計算を処理するための第１の計算の結果にも依存し得る。したがって、本発明のいくつかの実施形態において、予備計算処理部９２は、必要な計算または他の前処理アクションを依頼することを可能にする処理キュー（図示せず）をさらに含んでいてもよい。このような実施形態において、このキューは、公知の原理に従って動作し、上記計算または他の前処理アクションのそれぞれを、それらがキューの先頭に到達した際に処理する。さらなる実施形態において、予備計算処理部９２は、多数の計算または前処理アクションを同時に処理するように構成されてもよい。これは、処理キューを使用して行ってもよいし、処理キューを使用せずに行ってもよい。
【0084】
パラメータ計算システム３６は、予備計算処理部９２に結合されたパラメータ計算処理部９４も備える。パラメータ計算処理部９４は、上記リクエストおよび任意の前処理済みの情報を予備計算処理部９２から受信するように構成される。パラメータ計算処理部９４は、前処理済みの情報を利用して、最初のリクエストによって判定された指定環境要件の指定値を遠隔配置対話ユニット１８Ａ～１８Ｄが満たすことを可能にするために必要な制御パラメータの現在値の調整を計算するように構成される。これが行われる方法について、以下により詳細に説明する。次いで、この計算の結果および当該結果が対応するリクエストは、パラメータ計算システム３６に備えられ、かつパラメータ計算処理部９４に結合された結果処理部９６に送信される。結果処理部９６は、これらの結果を受信し、かつ、それらを中央制御システム１０のパラメータ結果格納部３８に格納されるのに適したフォーマットとなるように処理するように構成される。結果処理部９６は、計算の結果および関連データを内部データベース１２、１４、１６のうち１つ以上に格納するようにさらに構成される。前述したように、これにより、将来の制御パラメータ計算リクエストをより速く実行することが可能になり得る。結果処理部はまた、上記計算が行われたことを結果キュー３２に知らせるようにも構成され、その結果、結果キュー３２は、次いで、リクエストのステータスを「処理済み」となるように更新するよう通知システム３４に指示することができる。いくつかの実施形態において、結果処理部９６は、パラメータ結果格納部３８に格納された、制御パラメータ計算リクエストのステータスに関する情報パラメータを当該ステータスが「処理済み」となるように更新するように構成される。
【0085】
次に、パラメータ計算システム３６の動作方法１００について、図６を参照してより詳細に説明する。方法１００は、ステップ１０２において、情報収集処理部９０によってリクエストキュー３２からリクエストが受信されたときに開始される。受信されたリクエストは、上述の実施形態に従って値を計算すべき制御パラメータに関する情報を含んでいてもよい。
【0086】
制御パラメータ計算リクエストの受信に続いて、パラメータ計算システム３６は、ステップ１０４において、内部データベース１２、１４、１６および外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃから関連情報を検索するように構成される。これは、関連情報ソースに所要情報のリクエストを送ることによって行われてもよい。情報収集処理部は、要求された情報を取得するための最も有力なソースを特定するように構成されてもよい。リクエストは、有線通信方式または無線通信方式を含む、適した通信チャネル用いて送信されてもよい。ひとたびリクエストが内部データベース１２、１４、１６または外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃによって受信されると、上記情報が入手可能である場合、リクエストは、送信された情報を受信するように構成された情報収集処理部９０に送り返される。
【0087】
いくつかの稀なケースにおいて、制御パラメータ計算リクエストを実現するために必要な情報が、情報収集処理部９０にとって入手不可能であることが考えられる。これは、情報収集処理部９０が内部データベース１２、１４、１６および／または外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃと通信を行うことができないためであり得る。あるいは、所要情報は、単に、情報の潜在的なソースのすべてから入手できない場合がある。したがって、本発明のいくつかの実施形態において、所要情報が入手不可能であると判定された場合、情報収集処理部は、その旨の情報をリクエストキュー３２に通信するように構成されてもよい。リクエストキューは、次いで、リクエストのステータスを「処理不能」となるように更新するよう通知システム３４に指示するように構成されてもよい。リクエストはまた、次いで、リクエストキュー３２から取り除かれるように構成されてもよい。いくつかの実施形態において、情報収集処理部は、パラメータ結果格納部３８に格納された、制御パラメータ計算リクエストのステータスに関する情報パラメータを、「処理不能」となるように更新するように構成される。
【0088】
所要情報がすべて検索されたシナリオに戻ると、情報収集処理部９０は、ステップ１０６において、必要な前処理アクションまたは計算を実行するように構成された予備計算処理部９２にこの情報を渡すように構成されるが、このようなアクションまたは計算については、先に詳述した。これは、前述の予備計算処理部９２の実施形態のいずれを用いて行ってもよい。予備計算処理部９２が処理キューを備える実施形態の場合、リクエストおよび関連付けられた情報が予備計算処理部９２によって受信されると、必要な前処理アクションのそれぞれがキューに入れられ、アクションは、それがキューの先頭にあるときに予備計算処理部９２によって実行される。このような前処理アクションの例としては、ＲＣＰの現在値の計算が含まれ得る。この計算は、ＲＣＰの現在値が最初のリクエストと共に送出されない場合に必要になり得る。これは、ＲＣＰの現在値の計算が、最初のリクエストを行わなかった１つ以上の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８ＤのローカルＣＥＲに関する情報を必要とするシナリオにおいて起こり得る。
【0089】
ひとたび必要な前処理アクションまたは計算が実行されると、制御パラメータ計算リクエストの詳細、内部データベース１２、１４、１６および／または外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃからの情報ならびに前処理済みの情報がパラメータ計算処理部９４に渡される。パラメータ計算処理部９４は、ステップ１０８において、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって最初に要求された制御パラメータの値を計算するように構成される。これが行われ得る方法について、図６、図７Ａおよび図７Ｂを参照してより詳細に説明する。ひとたび上記計算が行われると、ステップ１１０において、その結果が結果処理部９６に渡される。この時点で、計算された結果はパラメータ結果格納部３８および関連内部データベース１２、１４、１６に格納され、図４Ａを参照して説明した方法に従って、リクエストキュー３２に通知が送られる。制御パラメータ計算リクエストのステータスに関連付けられた情報パラメータがパラメータ結果格納部３８に格納される特定の実施形態において、リクエストのステータスを「処理済み」に更新するために、パラメータ結果格納部３８に命令が送られる。
【0090】
図５のパラメータ計算システム３６の実施形態に戻ると、図７において、パラメータ計算処理部９４のより詳細な図が示されている。パラメータ計算処理部９４は、まず、情報受信・連結処理部１２０を備える。これは、予備計算処理部９２によって提供される情報を受信するように構成される。提供される情報は、要求された制御パラメータ計算を含んでいてもよい。これは、要求された制御パラメータの計算に必要な関連情報をさらに含んでいてもよく、この情報は、内部データベース１２、１４、１６および／または外部情報提供サーバ２４Ａ、２４Ｂ、２４Ｃから受信されたものであってもよく、あるいは、前述のように、予備計算処理部９２によって実行された前処理の結果であってもよい。情報受信・連結処理部１２０は、最初の制御パラメータリクエストを実現するのに必要な情報のすべてが情報受信・連結処理部１２０に提供された時点を判定するように構成される。この判定は、受信された情報と必要であると判定された情報とを比較することによって行われてもよい。これは、任意の適したマッチング技術によって、例えば、受信された情報に、どの情報が必要であるかを識別するリクエストに含まれた識別子との比較に適した識別子を含めることによって行ってもよい。いくつかの実施形態において、この判定は、上記情報が、フィルタリングルール１１Ａ、１１Ｂ、１１Ｃなどの所定の要件セットを満たしているか否かを判定することをさらに含んでいてもよい。判定は、受信された情報の正確性および完全性を確認することをさらに含んでいてもよい。いくつかの実施形態において、上記情報のすべてが取得されたと判定される時まで、情報受信・連結処理部１２０は、上記情報のすべてをローカルメモリ、ファイルまたはデータベースなどのローカル一時格納部に保持するように構成される。これは、予備計算処理部９２が一度にすべての所要情報を供給しない実施形態、例えば、予備計算処理部９２にキューが備えられ、制御パラメータ計算リクエストを実現するために多数の前処理アクションが必要である場合に、特に重要であり得る。いくつかの実施形態において、すべての所要情報が提供されることなく、上記計算が開始される、すなわち、計算のいくつかの側面は、所要情報のすべてが提供されることなく直ちに行われ得ることが考えられる。これらの実施形態において、情報受信・連結処理部１２０は、要求された制御パラメータの計算の一部が開始され得るのに十分な情報が供給された時点を判定するように構成されてもよい。この処理は、すべての情報が提供されるまで、計算の後続の部分に対して繰り返されてもよい。これは、処理の全体的な速度を高めるために情報がオンザフライで受信および処理される場合に用いられる。
【0091】
パラメータ計算処理部９４は、情報受信・連結処理部１２０に通信可能に結合されたパラメータ計算エンジン１２２をさらに備える。パラメータ計算エンジン１２２は、要求された制御パラメータの値を決定するのに必要なすべての所要情報に加えて、パラメータ計算リクエストを情報受信・連結処理部１２０から受信するように構成される。この受信は、上記説明に従って、情報受信・連結処理部１２０がすべての所要情報を有していると判定されたときに行われる。あるいは、別の実施形態によると、この受信は、上記計算の一部を行うのに十分な情報が存在すると判定されたときに行われてもよい。パラメータ計算エンジン１２２は、次いで、この情報を利用して、要求された制御パラメータを計算するか、あるいは制御パラメータの計算の一部を行うようにさらに構成される。これは、受信された情報を、提供された計算ルール１１Ａ、１１Ｂ、１１Ｃと組み合わせて用いることによって行われ、当該ルールは、１つ以上の内部データベース１２、１４、１６から検索された情報に含まれていてもよい。以下に、制御パラメータが計算される方法について、図８Ａ、図８Ｂおよび図８Ｃを参照してより詳細に説明する。パラメータ計算エンジン１２２は、制御パラメータを最初のリクエストに関連付けることを可能にする付加メタデータと共に、計算された制御パラメータの値を適したフォーマットで結果処理部に送信するようにさらに構成される。
【0092】
以下に、図６のステップ１０８において最初に言及したパラメータ計算処理部９４の動作方法１３０について、図８Ａを参照してより詳細に説明する。方法１３０は、ステップ１３２において、情報受信・連結処理部１２０によって予備計算処理部９２から情報が受信されたときに開始される。この情報が受信されると、ステップ１３４において、制御パラメータ計算の実行に必要な情報のすべてが提供された否かが判定される。これは、上記に示した説明にしたがって行われてもよい。欠けている所要情報が残っていると判定された場合、方法１３０はステップ１３２に戻り、予備計算処理部９２からさらなる情報の受信を待機する。いくつかの実施形態において、情報受信・連結処理部１２０が所要情報のすべてを受信し終えなければならない所定の期間が設けられてもよい。すべての所要情報が受信されずにこの所定の期間が経過した場合、リクエストの処理は、時間切れとなり、計算は終了する。終了した時点で、これを反映するように、リクエストのステータスを前述の実施形態のいずれかに従って更新してもよい。ただし、所要情報のすべてが供給されたと判定された場合、パラメータ計算処理部９４は、ステップ１３６において、要求された制御パラメータ（ＲＣＰ）の現在値の使用が遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって設定されたＳＥＲを満たすアクションがもたらすか否かを評価する。制御パラメータの現在値が遠隔対話ユニットによって設定されたＳＥＲを満たすアクションをもたらす場合、制御パラメータの現在値はＳＥＲに準拠しているとされる。この評価は、パラメータ計算処理部９４が検索された計算ルール１１Ａ、１１Ｂ、１１Ｃを利用して、現在の制御パラメータ値２３８、ローカルＣＥＲ２４０、２４２、２４４に関して提供された情報、関連外部ＣＥＲおよび入手可能な関連履歴情報を計算の入力として、現在の制御パラメータ値を用いてアクションの結果を評価する計算を実行することによって行われる。この計算は、典型的には、特定の値またはある一定の値の範囲であることをＳＥＲが必要とする動作条件の数値を返す。例証として、また、前述の電気自動車の例に戻ると、ＳＥＲは、車両が３０～５０キロメートル走行するように運転されなければならないということであり得るが、その場合、調整すべき制御パラメータは、車両が走行可能な距離（例えば、車両の速度）に直接的な影響を及ぼす。計算された値は、次いで、その値が当該制約に準拠しているか否かを判定するためにＳＥＲと比較される。電気自動車の場合、計算の結果は、車両が現在の速度では２５キロメートルしか走行できないというものであり得る。この場合、パラメータ計算処理部は、現在の制御パラメータはＳＥＲに準拠したアクションをもたらさないと判定することになる。準拠が評価される度合いは、二者択一（すなわち、準拠しているか、準拠していないか）となるように構成されてもよく、あるいは、様々な準拠度が存在するように、例えば、準拠度の分類が存在するように構成されてもよい。以下に、これについて図８Ｂを参照してさらに述べる。
【0093】
ステップ１３６において、ひとたび準拠性が評価されると、パラメータ計算処理部９４は、次いで、ステップ１３８において、リクエストにおけるＲＣＰの最初に受信された値が、ＳＥＲに十分に準拠した対応するアクションをもたらすか否かを判定する。もたらすと判定された場合、方法１３０は、ＲＣＰの最初に受信された値および関連付けられた情報（リクエスト識別子２３２など）を結果処理部９６に渡し、そこで、この情報は、次いで、前述の説明に従って配布される。ただし、ステップ１３８において、ＲＣＰの最初に受信された値が、ＳＥＲに十分に準拠していない対応するアクションをもたらすと判定されると、方法１３０は、ステップ１３９において、以前の計算の結果および最初に供給された情報を用いて、ＲＣＰの新たな値を計算する処理に進む。以下に、これが行われる方法について、図８Ｃを参照してより詳細に説明する。方法１３０は、次いで、制御パラメータの新たな値および関連付けられた情報（リクエスト識別子２３２など）を前述のように結果処理部９６に渡す（図６のステップ１１０を参照）。パラメータ計算処理部９４は、命令生成行列（図示せず）を備える。この行列の機能は、ＲＣＰの最初に受信された値のＳＥＲに対する準拠度を考慮する分類・カテゴリー分類システムにより、ローカルＣＥＲおよび外部ＣＥＲを考慮して決定される。以下に、これについて、ステップ１５４、１５６および１５８を参照してより詳細に説明する。
【0094】
最初に図８Ａのステップ１３６において言及した、ＲＣＰの現在値の使用が遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって設定されたＳＥＲを満たすアクションをもたらすか否かを評価する際に使用される動作方法１５０を、特定の実施形態について、図８Ｂを参照してより詳細に説明する。方法１５０は、ステップ１５２において、上記計算の実行に必要な情報がパラメータ計算処理部９４によって受信されたときに開始される。この情報は、現在のＲＣＰ値２３８、ローカルＣＥＲ２４０、２４２、２４４に関して提供された情報、関連外部ＣＥＲの値および入手可能な関連履歴情報（以前のＣＥＲ２１２、２１４、カテゴリー分類・分類の結果および制御パラメータ値など）を前述したように含んでいてもよい。パラメータ計算処理部９４は、次いで、ステップ１５４において、供給された計算ルール１１Ａ、１１Ｂ、１１Ｃを用いて、ＳＥＲに対する現在の制御パラメータ値の準拠性をローカルＣＥＲに応じて分類する。この分類は、典型的には、図８Ａを参照した前述の説明に従って計算を実行することを含むが、計算は、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄにローカルな環境制約のみを考慮して実行される。遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄが第２の遠隔対話ユニットについての制御パラメータ計算を要求する実施形態において、ローカル環境制約は、計算が行われる対象となっている遠隔対話ユニットにローカルなものである。電気自動車の例に戻ると、これは、車両の重量、車両の充電レベルおよび車両のタイヤの状態などの因子を含み得る。ひとたび計算が行われると、当該計算によって得られた値は、ＳＥＲと比較され、その結果は、当該比較の結果として分類され、分類は、命令生成行列２０１（例を用いて後述する）の形式でも表され得る、供給された計算ルール１１Ａ、１１Ｂ、１１Ｃによって決定される。分類は、計算された値のＳＥＲに対する準拠性を示す２つ以上のカテゴリーまたはクラスを含んでいてもよい。一実施形態において、分類は、二者択一的であって、計算された値がＳＥＲに準拠しているか否かを単に示すものであってもよい。別の実施形態において、分類は、計算された値とＳＥＲとのより詳細な関係を記述するために、さらなる分離を含んでいてもよい。非限定的な例として、分類は、計算された値が、必要な値よりも５～１０％大きいか、あるいは、必要な値よりも１５～２０％小さいということを示してもよい。
【0095】
ステップ１５４において、ひとたびこの分類が行われると、方法１５０は、次いで、ステップ１５６において、供給された計算ルール１１Ａ、１１Ｂ、１１Ｃを用いて、外部ＣＥＲを分類することにより処理を継続する。これは、外部ＣＥＲのみを考慮する分類を行うことを含む。これらの因子は、典型的には、外部情報提供部２４Ａ、２４Ｂ、２４Ｃによって提供されるが、電気自動車の例に戻ると、これらは、天候、現在の関連交通状況、他の車両の速度および関連道路閉鎖などの因子を含んでいてもよい。外部ＣＥＲはまた、他の遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄから受信された情報も含んでいてもよく、当該ユニットから受信された情報は、現在の計算に関連し得る。
【0096】
ステップ１５６において、ひとたびこの分類が行われると、方法１５０は、次いで、ステップ１５８において、ステップ１５４および１５６で割り当てられた分類に応じて現在の制御パラメータ値をさらにカテゴリー分類することにより処理を継続する。これは、ＩＦ－ＴＨＥＮ論理構造を用いて行われてもよく、分類がある一定の要件を満たす場合、特定のカテゴリー分類が与えられる。あるいは、上記方法はまた、ルックアップ行列も含んでいてもよく、ルックアップ行列は、現在の制御パラメータ値のための適切なカテゴリー分類を探索するために上記２つの与えられた分類をピボットポイントとして用いる。
【0097】
別の実施形態において、ステップ１５４、１５６および１５８は、分類がローカルＣＥＲと外部ＣＥＲとで別々にではなく、同時に行われるように組み合わされる。このように、上記の別々の分類は行われず、代わりに、パラメータ計算処理部９４によって実行されている１つの計算に続いてカテゴリー分類が行われる。これは、計算がローカルＣＥＲおよび外部ＣＥＲを同時に考慮するように、供給された計算ルール１１Ａ、１１Ｂ、１１Ｃを適切に構成することによって行われてもよい。
【0098】
さらなる実施形態において、ステップ１５６は、外部ＣＥＲの分類がローカルＣＥＲのうちの１つ以上も考慮するように変更されてもよい。このシナリオにおいて、ローカルＣＥＲの分類は、やはり外部ＣＥＲを考慮することなく行われる。これは、この分類を行う際に計算がローカルＣＥＲと併せて外部ＣＥＲを考慮するように、供給された計算ルール１１Ａ、１１Ｂ、１１Ｃを適切に構成することによって行われてもよい。
【0099】
上記に示した実施形態に従ってひとたびカテゴリー分類が割り当てられると、次いで、制御パラメータの最初に提案された値が、図８Ａのステップ１３８において説明したように、ＳＥＲに従う対応するアクションをもたらすか否かが判定される。
【0100】
以下に、図８Ａのステップ１３９で最初に言及した、制御パラメータの新たな値の計算に際して使用される動作方法１６０について、図８Ｃを参照してより詳細に説明する。方法１６０は、ステップ１６２において、レコードが受信されたときに開始され、このレコードは、現在の制御パラメータ値に関する情報、以前に計算された制御パラメータ値、方法１５０のステップ１５８において当該レコードに割り当てられたカテゴリー分類、計算ルール１１Ａ、１１Ｂ、１１ＣおよびローカルＣＥＲや外部ＣＥＲなどの他の提供された情報を含む。パラメータ計算処理部９４は、次いで、ステップ１６４において、現在の制御パラメータリクエストに割り当てられたカテゴリー分類についての関連履歴情報にアクセスする。要求された制御パラメータの適切な新たな値を計算するためには、現在のリクエストと同じカテゴリー分類を有する計算のために行われた以前の計算を考慮することが有利である。過去の結果により、現在のリクエストにおける特定の制御パラメータ値を使用することによって生じる可能性が高い将来の結果の指標が提供され得る。このように、現在の計算に関連していない情報をフィルタリングすることは有利であり、同じカテゴリー分類を有する情報のみを選択的に含めることにより、このようなフィルタを実現するための適した方法が提供される。適切な場合、パラメータ計算処理部９４は、他のカテゴリー分類に関する情報を、これらが現在のリクエストに関する関連情報を提供する場合には考慮してもよい。これは、他のカテゴリー分類に関する情報を考慮することによって、要求された制御パラメータの計算が改善される場合、例えば、より正確な統計的分析が可能となる場合に有利であり得る。
【0101】
ステップ１６４において、ひとたび関連情報がアクセスされると、方法１６０は、次いで、ステップ１６６において、このアクセスされた情報および供給された計算ルール１１Ａ、１１Ｂ、１１Ｃを用いて制御パラメータの新たな値を計算する処理に進む。これは、現在の制御パラメータ値を、現在のカテゴリー分類に関連付けられた特定のルールに従って、例えば、現在値の値を特定の割合だけ増減させるか、あるいは当該値を絶対量だけ増減させることによって調整するパラメータ計算ルールを含んでいてもよい。これはまた、パラメータ計算処理部９４が、制御パラメータの現在値に対してなすべき適切な調整を決定するために、履歴情報に対してデータ解析技術を実施することも含んでいてもよく、データ解析技術は、供給された計算ルール１１Ａ、１１Ｂ、１１Ｃによって指定される。データ解析技術は、最小二乗推定法やベイズの線形回帰技術などの線形回帰法またはベイズの推論などの他の統計的推論法を含み得る。データ解析技術はまた、提供された履歴情報を統計モデルの訓練に用いる、ニューラルネットワークの訓練および使用も含んでいてもよく、当該モデルは、次いで、制御パラメータの調整された値および制御パラメータ調整の結果を予測するために使用される。なお、上記各技術は例示として示されるものであり、制御パラメータ調整の推定値の計算を可能にする任意の技術が使用され得る。上記データ解析技術により、計算すべき制御パラメータおよびローカルＣＥＲ・外部ＣＥＲとの組み合わせと、遠隔対話ユニット１８Ａ、１８Ｂ、１８Ｃ、１８Ｄによって提供されたＳＥＲとの間に関係が形成される。このように、パラメータ計算処理部９４は、制御パラメータ値の変化に起因するアクションの結果をより良好に予測し、それによって、ＳＥＲを満たすという目的を達成するための適切な制御パラメータ値を提案することが可能である。
【0102】
ひとたび制御パラメータの新たな値が計算されると、方法１６０は、次いで、前述のように、制御パラメータ新たな値および関連付けられた情報（リクエスト識別子２３２など）を結果処理部９６に渡し、制御信号を生成する。
【0103】
前述の実施形態に係る中央制御システム１０は、ロギングシステム（図示せず）をさらに備えてもよい。ロギングシステムは、中央制御システム１０に送信されたリクエストに関連する情報をそれらの処理のステータスと共に格納するように構成されてもよい。加えて、ロギングシステムは、中央制御システム１０の動作中に発生した異常状態またはエラーを記録してもよい。ログ自体は、ローカルデータベース１２、１４、１６のうち１つ以上に格納されてもよい。
【0104】
以下に、中央制御システム１０が使用時にどのように構成され得るかの例について、１台以上の電気自動車に制御信号を提供する中央制御システム１０を参照して説明する。なお、これは可能な使用の一例であり、他の利用が本システムについて想定される。
【0105】
本例示の目的で、上記電気自動車は、特定の目的地まで走行し、当該目的地に特定の充電レベルで到着する必要があり、これは、旅程中に車両の速度を変化させることにより行われる。このシナリオにおいて、特定の目的地までの距離がＳＥＲとして考えられてもよく、当該目的地に車両が到着する充電レベルがローカルＣＥＲとして考えられてもよい。さらに、このシナリオにおいて、上記自動車は、経路上に充電ステーションがないために、旅程中に充電することができない。ある一定の充電レベルで目的地に到着することが有利であり得る理由としては、ユーザが将来の旅行を計画し、その旅行をするために十分な充電も必要としている場合や、目的地に到達してから車両を一度充電する予定であるが、当該目的地において車両の充電を行うことができる時間が限られている場合が含まれ得る。
【0106】
これを行うために、この目的の達成のために適切な走行速度を計算する中央制御システムと通信を行うように構成された、車両内にある対話ユニットにリクエストが送られる。ＳＥＲ（３０～５０キロメートルを走行）、計算すべき制御パラメータ（車両の速度）、制御パラメータの現在値および車両のローカルＣＥＲ（現在の充電レベル、車両の重量、タイヤの状態、車両内の他のシステムの電力消費、目的地までの経路）を示すリクエストが対話ユニットに送られる。このリクエストはまた、経路上の交通状況、経路上の道路閉鎖および経路上の気象状況に関する情報も必要とすることも示している。このリクエストはまた、当該リクエストのソースの表示および固有リクエスト識別子も提供する。ひとたびこのリクエストが送られると、対話ユニットは、次いで、エネルギーを節減するためにパワーダウンするように構成される。対話ユニットは、次いで、周期的にパワーアップし、かつ中央制御システム１０にクエリを送信することによりリクエストの状態を問い合わせるように構成される。
【0107】
このリクエストを受信すると、中央制御システムは、当該リクエストを処理し、これをリクエストキューに入れる。リクエストがキューに入ると、通知システムは、処理待機中であることを示すように更新される。ひとたび上記リクエストがキューの先頭に到達すると、当該リクエストは情報収集処理部に渡され、そこで、内部ソースおよび外部ソースから所要情報に対する要求が行われる。外部ソースとしては、気象情報サービス、交通情報、他の車両から入手され得る情報（車両の速度など）および全地球測位システム（ＧＰＳ）ナビゲーション情報が含まれ得る。ひとたび上記リクエストが処理にかけられると、通知処理部は、リクエストの状態の変化（すなわち、処理中であること）を示すように更新される。情報収集処理部はまた、内部データベース１２、１４、１６からの適切な計算ルール１１Ａ、１１Ｂ、１１Ｃ、当該車両および他の類似の車両の速度に関する以前の計算、ならびにこれらの計算の結果を検索する。これに続いて、検索された情報およびリクエストは、次いで、予備計算処理部に渡され、そこで、生の検索済み情報に対し、当該情報が制御パラメータ計算に使用され得るように、必要な計算が行われる。これは、ＧＰＳナビゲーション情報を交通状況の通知と組み合わせて、車両のアイドリングによる車両の充電消費に影響を与え得る特定の速度制限を有する経路上のエリアを特定することを含んでいてもよい。予備計算処理部（分類エンジン）９２はまた、前述の外部ソースから最初に検索された情報を用いて分類行列１９１（図９を参照）も生成する。
【0108】
上記必要な計算がすべて実行されると、すべての処理された情報は、次いで、パラメータ計算処理部９４に渡される。次いで、車両がその現在の速度（要求された制御パラメータ２３８）で走行可能な距離（ＳＥＲ）を判定するための計算が、ローカルＣＥＲ２４２、２４４（初期充電レベルなど）を考慮して行われる。この計算は、性質上、数値的である。この計算に続いて、上記自動車が走行可能な所望の距離と実際の距離との差異が求められ、結果がそれに応じて分類される。例えば、上記自動車が３０キロメートル（要求されたＳＥＲのパラメータの（指定）値）走行する必要があるが、２４キロメートル（ＳＥＲの現在値）しか走行できない場合、上記計算は、現在の制御パラメータを「不足」として分類してもよい。これに続いて、外部環境制約を考慮すること以外は同様にして計算および分類が行われ、当該環境制約は、概して、定性的な形式、例えば、「雪」または「晴れ」とされる気象状況として提供される。この情報が外部ＣＥＲの分類を判定するためにどのように使用され得るかの例が、図９に示されている。同図において、複数の外部ＣＥＲ１９０Ａ、１９０Ｂ、１９０Ｃが、３つのシナリオ１９３における分類行列１９１においてそれぞれ評価され、各シナリオにおいて、外部ＣＥＲ１９０Ａ、１９０Ｂ、１９０Ｃのそれぞれについて、定性記述（例えば、道路閉鎖なし、既知の交通渋滞なし）が返されるが、この情報は、前述のように外部ソースから最初に検索されたものであり、分類行列１９１は、予備計算処理部（分類エンジン）９２によって生成されたものである。これらの定性記述は、次いで、組み合わせて評価され、シナリオ１９３のそれぞれにおける外部分類１９２が得られる。別の実施形態において、外部分類１９２は、パラメータ計算処理部９４の動作の前に、行列１９１を用いて予備計算処理部（分類エンジン）９２内で決定されてもよい。このような分類が行われ得る１つの方法は、各定性記述に特定のスコアを割り当てることであってもよく、この場合、これらのスコアの合計または他の組み合わせを用いて、当該シナリオに合計スコアが割り当てられ、この合計スコアを用いて、提供された計算ルールに従って、シナリオに総合分類が割り当てられる。これは、定性情報の可能な数値化の例である。しかしながら、定性情報の分類を可能にする任意の適した方法が使用されてもよい。
【0109】
車両がその所望の目的地に特定の燃料レベルで到達できるように制御パラメータの新たな値を計算するために、上記２種類の分類は、次いで、パラメータ計算処理部９４によって使用されて、要求された制御パラメータ２３８の現在値のカテゴリー分類が前述のように判定される。要求された制御パラメータの現在値をカテゴリー分類するためにこれらの分類がどのように使用され得るかの例が、図１０に示されている。この図において、参照テーブル（あるいは命令生成行列）２０１が示されており、同テーブルには、速度の現在値についての５つのカテゴリーのローカルＣＥＲ分類２００Ａ、２００Ｂ、２００Ｃ、２００Ｄ、２００Ｅ（すなわち、目標距離を１５％以上下回る２００Ａ、目標距離を１５％未満かつ５％を超えて下回る２００Ｂ、目標距離の５％以内である２００Ｃ、目標距離を１５％未満かつ５％を超えて上回る２００Ｄ、および目標距離を１５％以上上回る２００Ｅ）および３つのカテゴリーの外部ＣＥＲ分類２０２Ａ、２０２Ｂ、２０２Ｃの一覧が示されており、これらの分類については図９を参照して既に述べた。分類の各組み合わせ（この組み合わせは、カテゴリー分類として知られている）について、命令の形式で一連の特定のアクションが提案される。この提案されるアクションは、予め定められたものであってもよく、あるいは、前述のようにデータ解析技術によって得られるものであってもよい。このような提案されるアクション（命令）について、図１０を参照して説明する。現在の速度におけるローカルＣＥＲ分類によって、走行が目標距離の５％以内となると判定され、外部ＣＥＲ分類が、例えば、「不良」であると判定された場合、提案される一連のアクション（命令）は、速度を５％減少させることである。提案されるアクションは、例示であり、車両の現在の速度などのその他の因子によって変化し得る（すなわち、車両が高速で走行している場合、提案されるアクションおよびカテゴリー分類は、車両が低速で走行している場合に提案されるものとは異なり得る）。さらに、これらの提案されるアクション（命令）はまた、時間に相関して変化し得る。なぜなら、利用可能な履歴データが増加し、より正確なアクションが提案され得るからである。ローカルＣＥＲおよび外部ＣＥＲの分類が判定されると、パラメータ計算処理部９４は、当該カテゴリー分類に対する提案されたアクション（命令）を参照し、これを用いて、要求された制御パラメータの新たな値を計算する。
【0110】
この制御パラメータの計算が行われると、次いで、結果は、結果処理部９６に渡されて、中央制御システム１０の内部データベース３８に格納され、リクエストが処理済みであり車両の対話ユニットによって検索が可能な状態になったとして、リクエストキューおよび通知システムが更新される。
【0111】
上記車両は、環境要件において起こり得る変化に応じて当該車両がその速度を調整することができるように、これらのリクエストを周期的に行うことができるように構成される。時間が経つにつれ、中央制御システム１０が利用可能な情報が増加するので、リクエストの目的を達成する際の計算結果の精度が向上する。図１１を参照すると、連続したパラメータリクエスト１８２Ａ、１８２Ｂ、１８２Ｃ、１８２Ｄ、１８２Ｅ、１８２Ｆの考えられる経時的推移が示されている。１８２Ａにおいて、要求された制御パラメータの初期値が中央制御システム１０に入力され、車両が走行する距離は、所与の最大値１８４を超えると計算される。その結果、中央制御システム１０は、これを補正する試みで、制御パラメータの新たな値を計算する。後の時間１８２Ｂにおいて、車両は、以前に計算された制御パラメータ値をその初期値として用いて、別のリクエストを送る。すると、車両が走行する距離は、所与の最小値１８６未満であると計算されると判定される。以前に計算された制御パラメータ値が誤りであり得る理由は、中央制御システム１０が正確な提案を行うのに十分な情報を有していなかったからであり得る。あるいは、環境制約が、リクエスト間で変化したことが考えられる（例えば、経路上で交通渋滞が発生したことが考えられる）。その結果、中央制御システム１０は、これを補正する試みで、制御パラメータの新たな値を再度計算する。時間が経つにつれ、そして試みを連続的に行うにつれ、中央制御システム１０は、必要最小限度１８６から最大限度１８４までの範囲の走行距離をもたらす制御パラメータ値を提案するために、より多くの情報を吸収することになる。走行すべき距離の最小限度および最大限度が連続的なパラメータリクエスト間で変更される場合も考えられる。この場合、この時点までに中央制御システム１０によって吸収された知識を用いて、当該変更を踏まえた制御パラメータの提案値が提供される。
【0112】
なお、上記の例は、本発明が利用され得る一分野に過ぎない。他の応用分野としては、異なる地理的場所における資源レベルがその資源の消費に対応するのに最適なレベルに維持され、自システムに接続された他のシステムの動作が、この資源レベルが維持されることに依存している分散資源管理システムが含まれ得る。このようなシステムが採用される用途にかかわらず、当該システムは、全体として効率的な動作を維持するためにどのようにしてシステムを動作させなければならないかに影響する複数の外部因子および内部因子のすべてを考慮しなければならない。さらに、本明細書に記載される異なる実施形態の特徴、利点および機能は、状況が許す場合には、組み合わせてもよいことが理解される。
【0113】
本発明のいくつかの例示的な実施形態およびその装置の異なる機能の実施について詳細に記載したが、当業者であれば、本システムの基本構成を改変して、記載された機能を、それがどのようにして実現されるかに関する説明を必要とすることなく、実行することが容易にできると理解される。したがって、本明細書において、システムのいくつかの機能は、必要とされる詳細な実装について説明することなく、様々な箇所で記載されているが、機能をシステムにコード化する当業者の能力を想定すれば必要ではない。加えて、本発明の異なる態様の特徴、機能および利点は、状況が許す場合には、組み合わせや置き換えが可能であることが理解される。
【図1A】
【図1B】
【図2A】
【図2B】
【図3】
【図4A】
【図4B】
【図4C】
【図4D】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図8C】
【図9】
【図10】
【図11】