ホーム > 特許ランキング > Ｇｏｏｇｌｅ ＬＬＣ
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-05-06
(45)【発行日】2022-05-16
(54)【発明の名称】車両システムバスのための拡張可能マッピング
(51)【国際特許分類】
G06F 13/38 20060101AFI20220509BHJP
B60R 16/023 20060101ALI20220509BHJP
【ＦＩ】
G06F13/38 340A
B60R16/023 P
【請求項の数】
16
(21)【出願番号】P 2020529523
(86)(22)【出願日】2019-06-17
(65)【公表番号】
(43)【公表日】2021-07-08
(86)【国際出願番号】 US2019037536
(87)【国際公開番号】W WO2020040848
(87)【国際公開日】2020-02-27
【審査請求日】2020-09-24
(31)【優先権主張番号】62/720,701
(32)【優先日】2018-08-21
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】502208397
【氏名又は名称】グーグル エルエルシー
【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ
【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．
(74)【代理人】
【識別番号】110001195
【氏名又は名称】特許業務法人深見特許事務所
(72)【発明者】
【氏名】ワシルクジーク，トマズ・パウエル
(72)【発明者】
【氏名】カーシェンボイム，イェブゲニー・ルビノビッチ
(72)【発明者】
【氏名】パイク，スティーブ
(72)【発明者】
【氏名】ランドルフ，スコット
【審査官】松平 英
(56)【参考文献】
【文献】特開２０１４－１６２２８６（ＪＰ，Ａ）
【文献】中国特許出願公開第１０７４６５６９５（ＣＮ，Ａ）
【文献】中国特許出願公開第１０４５７１０６９（ＣＮ，Ａ）
【文献】特開２０００－２５７５０１（ＪＰ，Ａ）
【文献】特開２０００－３１０１５２（ＪＰ，Ａ）
【文献】特開２０００－３１０１５３（ＪＰ，Ａ）
【文献】特開２００５－２３６５６０（ＪＰ，Ａ）
【文献】特開２０１１－１０９４５２（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１５／０１９１１７５（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１５／０２３４３８２（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１７／００７２８７６（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１７／０３４４００５（ＵＳ，Ａ１）
【文献】国際公開第２０１７／１４０３６７（ＷＯ，Ａ１）
【文献】スミス クレイグ Craig Smith，カーハッカーズ・ハンドブック，初版，日本，株式会社オライリー・ジャパン，2017年12月25日，pp. 052-055，ISBN : 978-4-87311-823-9
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｂ６０Ｒ ９／００－１１／０６
１６／００－２１／１３
２１／３４－９９／００
Ｇ０６Ｆ ３／００
３／１８
１３／１０－１３／１４
１３／２０－１３／４２
Ｈ０４Ｌ１２／００－１２／９５５
１３／０２－１３／１８
２９／００－２９／１４
Ｈ０４Ｗ ８／２６
２４／００
２８／０２
７２／０４
７４／０４
７４／０８
８４／１２
８８／０８
(57)【特許請求の範囲】
【請求項1】
車両の１つ以上のプロセッサが、オペレーティングシステムを実行することにより前記車両の１つ以上のシステムを制御するステップと、前記１つ以上のプロセッサが、制御バスプロトコルに従い指定されたローカル制御メッセージと前記オペレーティングシステムがサポートする標準制御メッセージとの間の拡張可能マッピングを取得するステップと、
前記１つ以上のプロセッサが実行する前記オペレーティングシステムが、前記標準制御メッセージを生成するステップとを含み、前記標準制御メッセージは、前記１つ以上のシステムの動作状態変更を開始するためのコマンドセットの第１の表現を含み、
前記１つ以上のプロセッサが、前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより、前記ローカル制御メッセージを取得するステップを含み、前記ローカル制御メッセージは、前記コマンドセットの第２の表現を含み、
前記１つ以上のプロセッサが、前記１つ以上のプロセッサと前記１つ以上のシステムとに結合された制御バスを介して前記ローカル制御メッセージを送信することにより、前記１つ以上のシステムの前記動作状態変更を開始するステップを含み、
前記標準制御メッセージをトランスレートすることは、
車両ハードウェア抽象化レイヤを実行することにより前記制御バスと前記オペレーティングシステムとの間のシムを提供することと、
前記車両ハードウェア抽象化レイヤが、前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより、前記ローカル制御メッセージを取得することとを含む、方法。
【請求項2】
前記拡張可能マッピングを取得するステップは、前記ローカル制御メッセージと前記標準制御メッセージとの間の前記拡張可能マッピングを規定するファイルを取得するステップを含む、請求項１に記載の方法。
【請求項3】
前記制御バスを介して第２のローカル制御メッセージを受けるステップと、前記拡張可能マッピングに基づいて、前記第２のローカル制御メッセージをトランスレートすることにより、第２の標準制御メッセージを取得するステップと、
前記第２の標準制御メッセージに基づいて、１つ以上の車両パラメータの１つ以上の動作状態を更新するステップとをさらに含む、請求項１または２に記載の方法。
【請求項4】
前記ローカル制御メッセージと前記標準制御メッセージとの間の異なるマッピングを規定する更新された拡張可能マッピングを取得するステップをさらに含む、請求項１～３のいずれか１項に記載の方法。
【請求項5】
前記車両の前記１つ以上のシステムは前記車両の暖房・換気・空調システムを含む、請求項１～４のいずれか１項に記載の方法。
【請求項6】
前記制御バスプロトコルはコントローラエリアネットワーク（ＣＡＮ）プロトコルを含む、請求項１～５のいずれか１項に記載の方法。
【請求項7】
前記ローカル制御メッセージは、ＤＢＣフォーマットまたはカヤックＣＡＮ定義（ＫＣＤ）フォーマットのうちの一方に従ってフォーマットされたローカル制御メッセージを含む、請求項１～６のいずれか１項に記載の方法。
【請求項8】
前記車両の前記１つ以上のシステムに対し、前記１つ以上のシステムの試験的動作状態変更を開始するための試験的コマンドセットを発行するステップと、前記コマンドセットの発行に応じて、前記試験的動作状態変更の後に、前記１つ以上のシステムから、１つ以上の車両パラメータの各々の実際の動作状態のそれぞれの指示を取得するステップと、
前記試験的コマンドセットについて、前記１つ以上の車両パラメータの前記実際の動作状態の間の１つ以上の依存性を求めるステップと、
前記１つ以上の依存性に基づいて前記拡張可能マッピングを生成することにより、前記コマンドセットを前記ローカル制御メッセージから前記標準制御メッセージにトランスレートするステップとをさらに含む、請求項１～７のいずれか１項に記載の方法。
【請求項9】
車両とやり取りするように構成されたデバイスであって、前記デバイスは、制御バスプロトコルに従い指定されたローカル制御メッセージとオペレーティングシステムがサポートする標準制御メッセージとの間の拡張可能マッピングを格納するように構成されたメモリと、
１つ以上のプロセッサとを備え、
前記１つ以上のプロセッサは、前記オペレーティングシステムを実行することにより前記車両の１つ以上のシステムを制御するように構成され、前記オペレーティングシステムは、前記標準制御メッセージを生成するように構成され、前記標準制御メッセージは、前記１つ以上のシステムの動作状態変更を開始するためのコマンドセットの第１の表現を含み、
前記１つ以上のプロセッサは、前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより前記ローカル制御メッセージを取得するように構成され、前記ローカル制御メッセージは、前記コマンドセットの第２の表現を含み、
前記１つ以上のプロセッサは、前記１つ以上のプロセッサと前記１つ以上のシステムとに結合された制御バスを介して前記ローカル制御メッセージを送信することにより、前記１つ以上のシステムの前記動作状態変更を開始するように構成されており、
前記１つ以上のプロセッサは、
車両ハードウェア抽象化レイヤを実行することにより前記制御バスと前記オペレーティングシステムとの間のシムを提供するように構成され、かつ
前記車両ハードウェア抽象化レイヤによって前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより、前記ローカル制御メッセージを取得するように構成されている、デバイス。
【請求項10】
前記１つ以上のプロセッサは、前記ローカル制御メッセージと前記標準制御メッセージとの間の前記拡張可能マッピングを規定するファイルを取得するように構成されている、請求項９に記載のデバイス。
【請求項11】
前記１つ以上のプロセッサはさらに、前記制御バスを介して第２のローカル制御メッセージを受けるように構成され、
前記拡張可能マッピングに基づいて、前記第２のローカル制御メッセージをトランスレートすることにより、第２の標準制御メッセージを取得するように構成され、かつ、
前記第２の標準制御メッセージに基づいて、１つ以上の車両パラメータの１つ以上の動作状態を更新するように構成されている、請求項９または１０に記載のデバイス。
【請求項12】
前記１つ以上のプロセッサはさらに、前記ローカル制御メッセージと前記標準制御メッセージとの間の異なるマッピングを規定する更新された拡張可能マッピングを取得するように構成されている、請求項９～１１のいずれか１項に記載のデバイス。
【請求項13】
前記車両の前記１つ以上のシステムは前記車両の暖房・換気・空調システムを含む、請求項９～１２のいずれか１項に記載のデバイス。
【請求項14】
前記制御バスプロトコルはコントローラエリアネットワーク（ＣＡＮ）プロトコルを含む、請求項９～１３のいずれか１項に記載のデバイス。
【請求項15】
前記ローカル制御メッセージは、ＤＢＣフォーマットまたはカヤックＣＡＮ定義（ＫＣＤ）フォーマットのうちの一方に従ってフォーマットされたローカル制御メッセージを含む、請求項９～１４のいずれか１項に記載のデバイス。
【請求項16】
命令が格納されたコンピュータ読取可能プログラムであって、前記命令は、実行されると、車両の１つ以上のプロセッサに、オペレーティングシステムを実行することにより前記車両の１つ以上のシステムを制御することと、
制御バスプロトコルに従い指定されたローカル制御メッセージと前記オペレーティングシステムがサポートする標準制御メッセージとの間の拡張可能マッピングを取得することとを実行させ、前記オペレーティングシステムは前記標準制御メッセージを生成するように構成され、前記標準制御メッセージは、前記１つ以上のシステムの動作状態変更を開始するためのコマンドセットの第１の表現を含み、さらに、
前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより前記ローカル制御メッセージを取得することを実行させ、前記ローカル制御メッセージは、前記コマンドセットの第２の表現を含み、さらに、
前記１つ以上のプロセッサが、前記１つ以上のプロセッサと前記１つ以上のシステムとに結合された制御バスを介して前記ローカル制御メッセージを送信することにより、前記１つ以上のシステムの前記動作状態変更を開始することを実行させ、
前記標準制御メッセージをトランスレートすることは、
車両ハードウェア抽象化レイヤを実行することにより前記制御バスと前記オペレーティングシステムとの間のシムを提供することと、
前記車両ハードウェア抽象化レイヤが、前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより、前記ローカル制御メッセージを取得することとを含む、コンピュータ読取可能プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、米国仮特許出願第６２／７２０，７０１号に基づく利益を主張し、その全内容を、その全体が記載されているものとして本明細書に引用により援用する。
【背景技術】
【0002】
背景
車両は、暖房・換気・空調（ＨＶＡＣ）システム、（車内の光および／または車外の光を制御するための）照明システム、娯楽システム、（運転席および／または助手席の位置を制御するための）座席システムなどのような車両システムを制御するために使用する（グラフィカルユーザインターフェイス－ＧＵＩ等の）インターフェイスを提供する、いわゆる「ヘッドユニット」またはその他の一体化されたコンピューティングデバイスを含み得る。ヘッドユニットは、車両システムに対して１つ以上のコマンド（「コマンドセット」と呼ぶこともできる）を発することにより、車両システムのうちの１つ以上の動作状態を変更することができる。（機能および動作双方の観点において）車両システムは同一製造者の異なるモデル間だけでなく異なる製造者のモデル間でも多岐にわたっているので、ヘッドユニットは、車両システムの最大の割合を総合的に制御するコマンドセットを出力するように構成すればよい。なぜなら、コマンドセットを手作業で構成すると時間もコストもかかるからである。
車両は、暖房・換気・空調（ＨＶＡＣ）システム、（車内の光および／または車外の光を制御するための）照明システム、娯楽システム、（運転席および／または助手席の位置を制御するための）座席システムなどのような車両システムを制御するために使用する（グラフィカルユーザインターフェイス－ＧＵＩ等の）インターフェイスを提供する、いわゆる「ヘッドユニット」またはその他の一体化されたコンピューティングデバイスを含み得る。ヘッドユニットは、車両システムに対して１つ以上のコマンド（「コマンドセット」と呼ぶこともできる）を発することにより、車両システムのうちの１つ以上の動作状態を変更することができる。（機能および動作双方の観点において）車両システムは同一製造者の異なるモデル間だけでなく異なる製造者のモデル間でも多岐にわたっているので、ヘッドユニットは、車両システムの最大の割合を総合的に制御するコマンドセットを出力するように構成すればよい。なぜなら、コマンドセットを手作業で構成すると時間もコストもかかるからである。
【0003】
さらに、製造者は、動作状態の各変更を実施するためにコマンドセットをスタティックにコーディング（または言い換えると「ハードコーディング」）することができる。すなわち、製造者は、車両ヘッドユニットが上記１つ以上のシステムと通信できるようにする特定の制御バスプロトコル（その一部はプロプライエタリであってもよい）に従うように、コマンドセットをスタティックにコーディングすることができる。製造者は、車両ヘッドユニットが実行するオペレーティングシステムをハードコーディングすることにより、制御バスプロトコルに従うコマンドセットを生成することができる。コマンドセットの各々は、制御バスによっておよび／または上記１つ以上のシステムの販売業者などによって異なり得るので、車両の特定の構成のためのコマンドセットのスタティックコーディングは時間がかかり、これは、車両モデル装備間でも異なる場合がある。
【発明の概要】
【課題を解決するための手段】
【0004】
概要
概して、本開示の技術は、（車両ヘッドユニット等の）車両コンピューティングデバイスが車両システムバスのための拡張可能マッピングを適用できるようにすることに向けられている。すなわち、車両システムバスは、車両ヘッドユニットと車両の１つ以上のシステムとの間でコマンドセットを伝達するための、異なるプロプライエタリおよびオープン標準に従う場合がある。車両ヘッドユニットは、統一されたコマンドセット（または言い換えると標準コマンドセット）をサポートするオペレーティングシステムを実行することができるのに対し、車両システムバスは、複数の制御バスプロトコルのうちの特定の制御バスプロトコルに従って指定されたローカル制御メッセージを伝達することができる。当該技術の各種局面は、この特定のローカル制御メッセージをサポートするためにオペレーティングシステムをハードコーディングするのではなく、標準コマンドセットと、制御バスがサポートする特定の制御バスプロトコルに従うローカルコマンドセットとの間の拡張可能マッピングを、車両ヘッドユニットが取得することを可能にすることができる。
概して、本開示の技術は、（車両ヘッドユニット等の）車両コンピューティングデバイスが車両システムバスのための拡張可能マッピングを適用できるようにすることに向けられている。すなわち、車両システムバスは、車両ヘッドユニットと車両の１つ以上のシステムとの間でコマンドセットを伝達するための、異なるプロプライエタリおよびオープン標準に従う場合がある。車両ヘッドユニットは、統一されたコマンドセット（または言い換えると標準コマンドセット）をサポートするオペレーティングシステムを実行することができるのに対し、車両システムバスは、複数の制御バスプロトコルのうちの特定の制御バスプロトコルに従って指定されたローカル制御メッセージを伝達することができる。当該技術の各種局面は、この特定のローカル制御メッセージをサポートするためにオペレーティングシステムをハードコーディングするのではなく、標準コマンドセットと、制御バスがサポートする特定の制御バスプロトコルに従うローカルコマンドセットとの間の拡張可能マッピングを、車両ヘッドユニットが取得することを可能にすることができる。
【0005】
よって、当該技術の各種局面は、オペレーティングシステム、制御バス、および／または車両システムのうちの１つ以上に対する更新に対応するためにある期間にわたって更新し得る拡張可能マッピングを、製造者が規定することを可能にすることができる。拡張可能マッピングは、標準コマンドセットとローカルコマンドセットとの間のトランスレーションを規定し、車両ヘッドユニットは、これを適用することにより、標準コマンドセットとローカルコマンドセットとの間のトランスレーションを自動的に行うことができる。当該技術の各種局面は、このようなマッピングをオペレーティングシステム内でスタティックにハードコーディングすることによってローカルコマンドセットのみをサポートするのではなく、拡張可能マッピングのみを規定すればよいので、車両ヘッドユニットオペレーティングシステムを開発できる速度を改善する、新規のまたは変化する制御バスプロトコルとの相互運用性（interoperability）を改善する、また、そうでなければローカルコマンドセットについてフル機能サポートを提供するこのようなオペレーティングシステムの迅速な開発に対応しつつ車両ヘッドユニットオペレーティングシステムの開発を改善することができる。
【0006】
さらに、当該技術の各種局面は、車両システムを制御するために車両ヘッドユニットがコマンドセットを適応させることを可能にすることができる。車両ヘッドユニットは、コマンドセットと車両システムの動作状態の変更との対応関係を求めるハードウェア抽象化レイヤ（hardware abstraction layer）（ＨＡＬ）を実現するように構成することができる。ＨＡＬは、これらの対応関係に基づいて、車両システムの（１つ以上の動作状態によって表される）追加機能をエクスポーズしようとして、コマンドセットを適応させることができる。よって、当該技術は、コマンドセットの手動構成に頼らずに特定のモデルおよび製造者に固有のコマンドセットをＨＡＬが自動的に決定することを可能にすることができる。
【0007】
この点において、当該技術の各種局面は、車両ヘッドユニット自体のより効率的な動作を促進することができる。すなわち、ＨＡＬは、コマンドセットと動作状態変化との対応関係を決定し、この対応関係に基づいて、車両システムの動作状態の変化をより効率的に生じさせるようにコマンドセットを適応させることができる。当該技術は、多数のモデルおよび製造者が選択した車両システムに共通するがいくつかの車両システムにとっては（機能的ではあるものの）非効率的である可能性があるコマンドセットを発行するのではなく、車両システムに動作状態変更を効率的に実行させることによってプロセッササイクルを削減しメモリ帯域幅とそれとともに消費される元のメモリリソースとを節約し結果としてより効率的な電力消費を促進するコマンドセットを、ＨＡＬが適応的に生成することを可能にすることができる。
【0008】
一例において、当該技術の各種局面は方法に向けられており、この方法は、車両の１つ以上のプロセッサがオペレーティングシステムを実行することにより車両の１つ以上のシステムを制御するステップと、１つ以上のプロセッサが、制御バスプロトコルに従い指定されたローカル制御メッセージとオペレーティングシステムがサポートする標準制御メッセージとの間の拡張可能マッピングを取得するステップと、１つ以上のプロセッサが実行するオペレーティングシステムが、標準制御メッセージを生成するステップとを含み、標準制御メッセージは、１つ以上のシステムの動作状態変更を開始するためのコマンドセットの第１の表現を含み、１つ以上のプロセッサが拡張可能マッピングに基づいて標準制御メッセージをトランスレートすることによりローカル制御メッセージを取得するステップを含み、ローカル制御メッセージはコマンドセットの第２の表現を含み、１つ以上のプロセッサが、１つ以上のプロセッサと１つ以上のシステムとに結合された制御バスを介してローカル制御メッセージを送信することにより、１つ以上のシステムの動作状態変更を開始するステップを含む。
【0009】
別の例において、当該技術の各種局面は、車両とやり取りするように構成されたデバイスに向けられており、このデバイスは、制御バスプロトコルに従い指定されたローカル制御メッセージとオペレーティングシステムがサポートする標準制御メッセージとの間の拡張可能マッピングを格納するように構成されたメモリと、１つ以上のプロセッサとを備え、１つ以上のプロセッサは、オペレーティングシステムを実行することにより車両の１つ以上のシステムを制御するように構成され、オペレーティングシステムは、標準制御メッセージを生成するように構成され、標準制御メッセージは、１つ以上のシステムの動作状態変更を開始するためのコマンドセットの第１の表現を含み、１つ以上のプロセッサは、拡張可能マッピングに基づいて標準制御メッセージをトランスレートすることによりローカル制御メッセージを取得するように構成され、ローカル制御メッセージは、コマンドセットの第２の表現を含み、１つ以上のプロセッサは、１つ以上のプロセッサと１つ以上のシステムとに結合された制御バスを介してローカル制御メッセージを送信することにより、１つ以上のシステムの動作状態変更を開始するように構成されている。
【0010】
別の例において、当該技術の各種局面は、命令が格納された非一時的なコンピュータ読取可能記憶媒体に向けられており、上記命令は、実行されると、車両ヘッドユニットの１つ以上のプロセッサに、オペレーティングシステムを実行することにより車両の１つ以上のシステムを制御することと、制御バスプロトコルに従い指定されたローカル制御メッセージとオペレーティングシステムがサポートする標準制御メッセージとの間の拡張可能マッピングを取得することとを実行させ、オペレーティングシステムは標準制御メッセージを生成するように構成され、標準制御メッセージは、１つ以上のシステムの動作状態変更を開始するためのコマンドセットの第１の表現を含み、さらに、拡張可能マッピングに基づいて標準制御メッセージをトランスレートすることによりローカル制御メッセージを取得することを実行させ、ローカル制御メッセージはコマンドセットの第２の表現を含み、さらに、１つ以上のプロセッサが、１つ以上のプロセッサと１つ以上のシステムとに結合された制御バスを介してローカル制御メッセージを送信することにより、１つ以上のシステムの動作状態変更を開始することを実行させる。
【0011】
別の例において、当該技術の各種局面は、第１の車両とインターフェイスする方法に向けられており、この方法は、プロセッサが、第１の車両の１つ以上のシステムに対し、１つ以上のシステムの動作状態変更を開始するためのコマンドセットを発行するステップと、コマンドセットの発行に応じて、動作状態変更後に、プロセッサが、１つ以上のシステムから、１つ以上の車両パラメータの各々の動作状態の指示（indication）を取得するステップと、プロセッサが、コマンドセットについて、１つ以上の車両パラメータの動作状態間の１つ以上の依存性（dependency）を求めるステップと、プロセッサが、１つ以上の依存性に基づいて、第１の車両の１つ以上のシステムと第２の車両の１つ以上のシステムとの間の可変性（variability）に対処する（accommodate）ようにコマンドセットを適応させるステップとを含む。
【0012】
別の例において、当該技術の各種局面は、第１の車両とインターフェイスするように構成されたデバイスに向けられており、ヘッドユニットは、第１の車両の１つ以上のシステムの動作状態変更を開始するためのコマンドセットを格納するように構成された１つ以上のメモリと、１つ以上のプロセッサとを備え、１つ以上のプロセッサは、第１の車両の１つ以上のシステムに対し、コマンドセットを発行するように構成され、コマンドセットの発行に応じて、動作状態変更後に、１つ以上のシステムから、１つ以上の車両パラメータの各々の動作状態の指示を取得するように構成され、コマンドセットについて、１つ以上の車両パラメータの動作状態間の１つ以上の依存性を求めるように構成され、１つ以上の依存性に基づいて、第１の車両の１つ以上のシステムと第２の車両の１つ以上のシステムとの間の可変性に対処するようにコマンドセットを適応させるように構成されている。
【0013】
別の例において、当該技術の各種局面は、実行されると車両の１つ以上のプロセッサに動作を実行させる命令が格納された非一時的なコンピュータ読取可能記憶媒体に向けられており、この動作は、車両の１つ以上のシステムに対し、１つ以上のシステムの動作状態変更を開始するためのコマンドセットを発行することと、コマンドセットの発行に応じて、動作状態変更後に、１つ以上のシステムから、１つ以上の車両パラメータの各々の動作状態の指示を取得することと、コマンドセットについて、１つ以上の車両パラメータの動作状態間の１つ以上の依存性を求めることと、１つ以上の依存性に基づいて、第１の車両の１つ以上のシステムと第２の車両の１つ以上のシステムとの間の可変性に対処するようにコマンドセットを適応させることとを含む。
【0014】
１つ以上の例の詳細を添付の図面および以下の説明に記載する。本開示のその他の特徴、目的、および利点は、上記説明および図面から、ならびに請求項から明らかになるであろう。
【図面の簡単な説明】
【0015】
【図1】本開示に記載の技術の各種局面を実行するように構成された車両の一例を示すブロック図である。
【発明を実施するための形態】
【0016】
詳細な説明
図１は、本開示に記載の技術の各種局面を実行するように構成された一例としての車両１０を示すブロック図である。図１の例における車両１０は、以下の説明では自動車であると想定する。しかしながら、本開示に記載の技術は、一人以上の乗員をある場所と別の場所との間で運ぶことができる任意の種類の車両、たとえば、オートバイ、バス、レクリエーショナル・ビークル（ＲＶ）、セミトレーラートラック、トラクターもしくはその他の種類の農機具、列車、飛行機、ドローン、ヘリコプター、個人用移動車両（personal transport vehicle）などに、適用することができる。
図１は、本開示に記載の技術の各種局面を実行するように構成された一例としての車両１０を示すブロック図である。図１の例における車両１０は、以下の説明では自動車であると想定する。しかしながら、本開示に記載の技術は、一人以上の乗員をある場所と別の場所との間で運ぶことができる任意の種類の車両、たとえば、オートバイ、バス、レクリエーショナル・ビークル（ＲＶ）、セミトレーラートラック、トラクターもしくはその他の種類の農機具、列車、飛行機、ドローン、ヘリコプター、個人用移動車両（personal transport vehicle）などに、適用することができる。
【0017】
図１の例において、車両１０は、プロセッサ１２と、グラフィックス処理装置（ＧＰＵ）１４と、システムメモリ１６とを含む。いくつかの例において、プロセッサ１２、ＧＰＵ１４、およびトランシーバモジュール（図１では図示せず）が、集積回路（ＩＣ）として形成されてもよい。たとえば、ＩＣは、チップパッケージ内の処理チップとみなすことができ、システムオンチップ（ＳｏＣ）であってもよい。
【0018】
プロセッサ１２およびＧＰＵ１４の例は、１つ以上のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルロジックアレイ（ＦＰＧＡ）、またはその他同等の集積もしくは離散論理回路を含むが、これらに限定される訳ではない。プロセッサ１２は車両１０の中央処理装置（ＣＰＵ）を表していてもよい。いくつかの例において、ＧＰＵ１４は、グラフィック処理に適した超並列処理（massive parallel processing）能力をＧＰＵ１４に与える集積および／または離散論理回路を含む専用ハードウェアであってもよい。いくつかの場合において、ＧＰＵ１４は、汎用処理能力を含んでいてもよく、汎用処理タスク（すなわち非グラフィックス関連タスク）を実現するときは汎用ＧＰＵ（ＧＰＧＰＵ）と呼ぶこともできる。専用ＧＰＵ１４として示されているが、ＧＰＵ１４は、下にある回路基板（いわゆる「マザーボード」等）に一体化された集積ＧＰＵを表していてもよく、そうでなければプロセッサ１２に組み込まれていてもよい。
【0019】
プロセッサ１２はさまざまな種類のアプリケーションを実行することができる。アプリケーションの例は、ウェブブラウザ、電子メールアプリケーション、スプレッドシート、ビデオゲーム、または、表示のために見える物体を生成するその他のアプリケーションを含む。システムメモリ１６は、１つ以上のアプリケーションを実行するための命令を格納することができる。プロセッサ１２は、アプリケーションを実行することにより、表示すべき画像コンテンツのグラフィックデータを生成する。プロセッサ１２は、画像コンテンツのグラフィックデータを、プロセッサ１２からＧＰＵ１４に送信された命令またはコマンドに基づいてさらに処理されるようにＧＰＵ１４に送信することができる。
【0020】
プロセッサ１２は、アプリケーションプログラミングインターフェイス（ＡＰＩ）に従ってＧＰＵ１４と通信することができる。加えて、本開示に記載の技術は、ＡＰＩに従って機能しなくてもよく、プロセッサ１２およびＧＰＵ１４は、ＧＰＵ１４との通信のために任意の技術を利用することができる。
【0021】
システムメモリ１６は車両１０のためのメモリを表していてもよい。システムメモリ１６は、１つ以上のコンピュータ読取可能記憶媒体を含み得る。システムメモリ１６の例は、ランダムアクセスメモリ（ＲＡＭ）、電気的消去可能プログラム可能読出専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、または、命令および／またはデータ構造の形態の所望のプログラムコードを搬送または格納するために使用することができコンピュータもしくはプロセッサからアクセスできる、その他の媒体を含むが、これらに限定される訳ではない。
【0022】
いくつかの局面において、システムメモリ１６は、プロセッサ１２について本開示に記載される機能をプロセッサ１２に実行させる命令を含み得る。したがって、システムメモリ１６は、実行されると１つ以上のプロセッサ（たとえばプロセッサ１２）に各種機能を実行させる命令が格納された非一時的なコンピュータ読取可能記憶媒体であってもよい。
【0023】
システムメモリ１６は非一時的な記憶媒体である。「非一時的」という用語は、記憶媒体が搬送波または伝搬信号で実施されるのではないことを示す。しかしながら、「非一時的」という用語は、システムメモリ１６が移動できないことを意味するまたはそのコンテンツがスタティックであることを意味すると解釈されてはならない。一例として、システムメモリ１６を車両１０から取り出して別のデバイスに移動させてもよい。別の例として、実質的にシステムメモリ１６と同様のメモリを自律車両１０に挿入してもよい。特定の例において、非一時的な記憶媒体は、時間の経過に伴って変化し得るデータを（たとえばＲＡＭに）格納してもよい。
【0024】
図１の例にさらに示されるように、車両１０はディスプレイ２０とユーザインターフェイス（user interface）２２とを含み得る。ディスプレイ２０は、任意の種類の、画像をその上に投影できるパッシブ反射スクリーン、または、画像を表示することができるアクティブ反射もしくは放射もしくは透過ディスプレイを表していてもよい（発光ダイオード（ＬＥＤ）ディスプレイ、有機ＬＥＤ（ＯＬＥＤ）ディスプレイ、液晶ディスプレイ（ＬＣＤ）、またはその他任意の種類のアクティブディスプレイなど）。車両１０は、１つのディスプレイ２０を含むものとして示されているが、車両１０の車室全体に配置できる複数のディスプレイを含み得る。いくつかの例において、パッシブバージョンのディスプレイ２０または特定種類のアクティブバージョンのディスプレイ２０（たとえばＯＬＥＤディスプレイ）が、座席、テーブル、ルーフライナー、フローリング、窓（もしくは窓がないか少ない車両では壁）、または車室のその他の部分に、一体化されていてもよい。ディスプレイ２０がパッシブディスプレイを表す場合、ディスプレイ２０は、パッシブディスプレイ２０に画像を投影するかそうでなければ再現することができるプロジェクタまたはその他の画像投影デバイスを含み得る。さらに、ディスプレイ２０は、物理的な機器クラスタ（速度、回転数、エンジン温度などを示す）を仮想的に表す運転席側のダッシュボードに一体化されたディスプレイを含み得る。
【0025】
ディスプレイ２０はまた、自律車両１０と有線または無線通信するディスプレイを表していてもよい。たとえば、ディスプレイ２０は、ラップトップコンピュータ、ヘッドアップディスプレイ、ヘッドマウントディスプレイ、拡張現実コンピューティングデバイスもしくはディスプレイ（「スマート眼鏡」等）、仮想現実コンピューティングデバイスもしくはディスプレイ、携帯電話（いわゆる「スマートフォン」を含む）、タブレットコンピュータ、ゲームシステム、または、車両１０に一体化されたディスプレイの拡張部分としてもしくはその代わりに機能することができる別の種類のコンピューティングデバイス等のコンピューティングデバイスを、表していてもよい。
【0026】
ユーザインターフェイス２２は、車両１０の各種機能を制御するためにユーザがそれとインターフェイスすることができる任意の種類の物理または仮想インターフェイスを表していてもよい。ユーザインターフェイス２２は、物理的なボタン、ノブ、スライダ、またはその他の物理制御機器を含み得る。また、ユーザインターフェイス２２は、車両１０の乗員が、一例としてタッチ感応式スクリーンを介してまたはタッチレスインターフェイスを介して、仮想ボタン、ノブ、スライダまたはその他の仮想インターフェイス要素とやり取りするための、仮想インターフェイスを含み得る。乗員は、ユーザインターフェイス２２とインターフェイスすることにより、車両１０内の環境、車両１０による音声再生、車両１０による動画再生、車両１０を通じた送信（携帯電話の通話など）、または、車両１０が実行できるその他任意の動作のうちの、１つ以上を制御することができる。
【0027】
ユーザインターフェイス２２はまた、車両１０に一体化されたディスプレイの拡張部分としてまたはその代わりに機能するときにディスプレイ２０に拡張されるインターフェイスを表していてもよい。すなわち、ユーザインターフェイス２２は、ヘッドアップディスプレイ（ＨＵＤ）、拡張現実コンピューティングデバイス、仮想現実コンピューティングデバイスもしくはディスプレイ、タブレットコンピュータ、または上記さまざまな種類の拡張ディスプレイ以外のものを介して与えられる、仮想インターフェイスを含み得る。
【0028】
車両１０の文脈において、ユーザインターフェイス２２はさらに、車両１０を手動でまたは半手動で制御するために使用される物理要素を表していてもよい。たとえば、ユーザインターフェイス２２は、車両１０の移動方向を制御するための１つ以上のハンドル、車両１０の移動速度を制御するための１つ以上のペダル、１つ以上のハンドブレーキなどを含み得る。
【0029】
図１の例において、プロセッサ１２、ＧＰＵ１４、システムメモリ１６、ディスプレイ２０、およびＵＩ２２は、自動車の文脈においてヘッドユニット２４（または言い換えると「車両ヘッドユニット２４」）と呼ばれるものを、少なくも一部、集合的に表していてもよい。ヘッドユニット２４は、車両１０のさまざまな部分とインターフェイスすることができるおよび／または乗員のための娯楽および／または車両１０に関する情報を提供することができる（このようなヘッドユニットは「インフォテイメントユニット」または「インフォテイメントシステム」と呼ぶことができる）、任意の一体化されたまたは別個のコンピューティングデバイスを表していてもよい。
【0030】
図１の例にさらに示されるように、車両１０は、複数の異なる車両システム２６Ａ～２６Ｎ（「車両システム２６」）を含み得る。車両システム２６は、暖房・換気・空調（ＨＶＡＣ）システム、温度調整システム（たとえばＨＶＡＣシステムに加えて暖房および／または冷却された座席を含み得る）、（車内照明および／または車外照明を提供するための）照明システム、（乗員の座席の位置を調整するための）座席制御システム、（バックミラー、サイドミラー、バイザーミラーなどを含む車内および／または車外のミラーを制御するための）ミラー制御システム、フロントガラスワイパー制御システム、（ラジオ再生、動画再生、画像表示などを制御するための）娯楽システム、（駐車支援、バックアップ支援などを制御するための）安全支援システム、（サンルーフおよび／またはムーンルーフを制御するための）サン／ムーンルーフ制御システム、ならびに、ヘッドユニット２４等のヘッドユニットを介して制御可能なその他任意の種類の車両システムを、含み得る。車両システム２６の例は、車両システム２６の上記例のうちのいずれかを制御することができる電子制御ユニット（ＥＣＵ）を含み得る。
【0031】
ヘッドユニット２４は、車両システム２６のうちの１つ以上の動作状態を変えるために車両システム２６に対して１つ以上のコマンド（「コマンドセット」と呼ぶことができ、図１では「ＣＳ ２５Ａ～２５Ｎ」として示され、まとめて「ＣＳ ２５」と呼ぶことができる）を発行することができる。（機能および動作双方の観点において）車両システム２６は同一製造者からの車両の異なるモデル間だけでなく異なる製造者からの車両のモデル間でも多岐にわたっているので、ヘッドユニット２４は、車両システム２６の最大の割合を総合的に制御するコマンドセット２５を出力するように構成することができる。なぜなら、コマンドセットを手作業で構成すると時間もコストもかかりエラーが起こり易いからである。
【0032】
さらに、ヘッドユニット２４は、制御エリアネットワーク（ＣＡＮ）プロトコル等の制御バスプロトコルに従ってコマンドセットを出力するように構成されたオペレーティングシステム（「ＯＳ」）３０を実行することができる。ＯＳ３０等のヘッドユニットのオペレーティングシステムは、ＣＡＮプロトコルまたはその他の標準（たとえばオープンまたはプロプライエタリ）制御バスプロトコルを介して車両システム２６と通信するようにスタティックに構成（または言い換えると「ハードコーディング」）されてもよい。すなわち、製造者は、オペレーティングシステムを手動でプログラミングすることにより、オペレーティングシステムが制御バス（説明し易くするために図１の例では示されていない）を介して車両システム２６の各々とインターフェイスすることを可能にしてもよい。
【0033】
車両システム２６の各々に対して正しくインターフェイスするようにオペレーティングシステムをプログラミングすることは、時間がかかるとともに、車両システム２６との正しい相互運用性を保証するには相当なテストを必要とする可能性がある。説明すると、車両特性の状態を伝達するとともに複数の異なる制御バスプロトコルに従って制御される車両システム２６を提供することができる多様な販売業者から、製造者は車両システム２６を調達することができる。製造者は、単一モデル内であっても、（同一モデルの異なるトリム間などで）異なる制御バスプロトコルに従って通信する車両システム２６を調達する必要がある。結果として、製造者は、オペレーティングシステムの２つ以上の異なるバージョンを作成する場合があり、これらのバージョンの各々は、異なる制御バスプロトコルを介して車両システム２６と通信するために個別にハードコーディングされる。加えて、制御バスプロトコルに何らかの変更が加えられると、結果として、制御バスプロトコルの新たなバーションをサポートするようオペレーティングシステムをハードコーディングするために製造者はオペレーティングシステムを更新する場合があり、そうすると、場合によっては製造者が新たなまたは変化する制御バスプロトコルをサポートする能力が低下し、そのために、場合によっては車両１０の安全性、利便性およびその他の面を改善するアップグレードを車両１０が受けられなくなることがある。
【0034】
本開示に記載の技術の各種局面に従うと、車両コンピューティングシステム（一例としてのヘッドユニット２４等）は、車両システムバス（「制御バス」と呼ぶこともできる）のための拡張可能マッピングを適用することができる。先に述べたように、車両システムバスは、ヘッドユニット２４（「車両ヘッドユニット２４」と呼ぶこともできる）と車両の１つ以上のシステム（たとえば車両システム２６）との間でコマンドセット（command set）（「ＣＳ」）２５Ａ～２５Ｎ（「ＣＳ２５」）を伝達するための、異なるプロプライエタリおよびオープン標準に従う場合がある。車両ヘッドユニット２４は、統一されたコマンドセット（または言い換えると標準コマンドセット）をサポートするオペレーティングシステム３０を実行することができるのに対し、車両システムバス２６は、複数のローカル制御バスプロトコルのうちの特定のローカル制御バスプロトコルに従って指定されたローカル制御メッセージを伝達することができる。当該技術の各種局面は、この特定のローカル制御メッセージをサポートするためにオペレーティングシステム３０をハードコーディングするのではなく、標準コマンドセットと、ローカル制御バスがサポートする特定のローカル制御バスプロトコルに従うローカルコマンドセットとの間の拡張可能マッピング（extensible mapping）３１（「ＥＭ３１」）を、車両ヘッドユニット２４が取得することを可能にすることができる。ローカル制御メッセージは、ＤＢＣフォーマットまたはカヤックＣＡＮ定義（Kayak CAN definition）（ＫＣＤ）フォーマットのうちの一方に従ってフォーマットすることができる。
【0035】
動作時、プロセッサ１２は、ＯＳ３０を実行することにより、車両システム２６のうちの１つ以上を制御することができ、ＯＳ３０は、標準コマンドセットをサポートすることができる。ＯＳ３０は、共通または標準制御バスプロトコルに従い標準コマンドセットを１つ以上のメッセージとして出力することができ、これらのメッセージは「標準制御メッセージ」と呼ぶことができる。プロセッサ１２は、システムメモリ１６から、ローカル制御バスプロトコルに従って指定されたローカル制御メッセージとＯＳ３０がサポートする標準制御メッセージとの間のマッピングを規定することができるＥＭ３１を取得することができる。
【0036】
いくつかの例において、プロセッサ１２は、ＯＳ３０と車両システム２６との間のソフトウェアシムレイヤ（software shim layer）と呼ぶことができるもの（図１の例には示されていない制御バスを含む）を提供する、ハードウェア抽象化レイヤ（hardware abstraction layer）（ＨＡＬ）２８を実行することができる。言い換えると、ＨＡＬ２８は、基礎となるヘッドユニットオペレーティングシステム３０（「ＯＳ３０」）を拡張するように構成されたユニットを表し得る。プロセッサ１２は、ＨＡＬ２８に対応付けられた１つ以上のスレッドを含む、ＯＳ３０を表す１つ以上のスレッドを実行することができる。プロセッサ１２は、ＯＳ３０の１つ以上のスレッドに対応付けられた１つ以上のコマンドの形態のＯＳ３０（ＨＡＬ２８を含む）をシステムメモリ１６から取り出し、コマンドを、実行の前に、ローカルメモリ（たとえばレイヤ１（Ｌ１）、レイヤ２（Ｌ２）、および／またはレイヤ３（Ｌ３）キャッシュであり、これらは説明し易くするために図１の例では示されていない）にロードすることができる。このため、ＨＡＬ２８およびＯＳ３０は、プロセッサ１２が実行することを示すために点線を用いてプロセッサ１２に含まれるものとして示されているが、ＨＡＬ２８およびＯＳ３０の長期記憶を示すために実線を用いてシステムメモリ１６にも含まれるものとして示されている。ＨＡＬ２８は、プロセッサ１２によって実行されるものとして示されているが、専用回路またはハードウェアロジックを用いて実現されてもよい。
【0037】
いずれにしても、ＨＡＬ２８は、ＯＳ３０が車両システム２６とインターフェイスすることを可能にするためにソフトウェアシムレイヤを与えるときに、ＥＭ３１を取得することができる。よって、ＯＳ３０は、ＯＳ３０がサポートする制御バスプロトコルに従う標準制御メッセージとして、コマンドセット２５を生成することができる。ＨＡＬ２８は、標準制御メッセージを受け（または場合によってはインターセプトし）、ＥＭ３１に基づいて、標準制御メッセージをトランスレートすることにより、ローカル制御バスに従うローカル制御メッセージを得ることができ、ＯＳ３０はこのようなトランスレートを要求しない（この点においてＯＳ３０から見てトランスペアレント）。
【0038】
ＥＭ３１は標準制御メッセージとローカル制御メッセージとの間のバイト単位のマッピングを規定することができる。すなわち、ＥＭ３１は、標準制御メッセージのバイトごとにマッピングを規定し、如何にして各バイトをメッセージ内に再配置しおよび／または値をコンバートする（たとえば制御メッセージＩＤに対して）ことによりローカル制御バスプロトコルに従うようにするかを、規定することができる。ＨＡＬ２８は、コマンドセット２５のうちの１つ等のコマンドセットの第１の表現を含み得る標準制御メッセージを受けて、車両システム２６のうちの１つ以上の動作状態変更を開始することができる。
【0039】
ＨＡＬ２８は、ＥＭ３１を標準制御メッセージに適用して標準制御メッセージ内のバイトの値を再配置するかそうでなければコンバートすることにより、標準制御メッセージをトランスレートして制御バスプロトコルに従うローカル制御メッセージを得ることができる。よって、ローカル制御メッセージは、コマンドセットの第２の表現を含み得る。ＨＡＬ２８は、プロセッサ１２および車両システム２６に結合された制御バスを介してローカル制御メッセージを送信することにより、車両システム２６のうちの１つ以上の動作状態変更を開始することができる。
【0040】
ＨＡＬ２８は、同様に、車両システム２６から、動作状態２７Ａ～２７Ｎ（「動作状態２７」、図１では「ＳＴ２７Ａ～２７Ｎ」として示される）を含むローカル制御メッセージを受ける（または、場合によっては、ＯＳ３０および車両システム２６から見てトランスペアレントにインターセプトする）ことができる。ローカル制御メッセージはローカル制御バスプロトコルに従っていてもよい。ＨＡＬ２８は、ＥＭ３１に基づいてローカル制御メッセージをトランスレートすることにより、これもＯＳ３０によってサポートされる標準制御メッセージを得ることができる。先に述べたように、ＨＡＬ２８は、このトランスレーションを、基礎となるハードウェアの抽象化の一部として（または言い換えるとシムソフトウェアレイヤ提供の一部として）提供することができ、異なるさまざまなハードウェアプラットフォームにおけるＯＳ３０の場合によってはより単純な開発およびインストールを可能にする。ＨＡＬ２８は標準制御メッセージをＯＳ３０に与えることができ、ＯＳ３０は過去に送られた標準制御メッセージによって要求された動作状態変更の確認を得ることができる。
【0041】
加えて、ヘッドユニット２４は、車両システム２６を制御するためにコマンドセット２５を適応させることができる。先に述べたように、ヘッドユニット２４は、コマンドセット２５と車両システム２６の動作状態２７の変更との対応関係２９（association）（「ＡＳＳＯＣ２９」）を求めるＨＡＬ２８を実現するように構成することができる。ＨＡＬ２８は、これらの対応関係２９に基づいて、車両システム２６の（１つ以上の動作状態２７によって表される）追加機能をエクスポーズしようとして、コマンドセット２５を適応させることができる。よって、当該技術は、ＨＡＬ２８が、特定のモデルおよび製造者固有のコマンドセット２５を自動的に決定することにより、場合によってはコマンドセット２５の手動構成を回避しそれに伴う時間と費用とエラーの可能性を回避することを、可能にすることができる。ＨＡＬ２８は、対応関係２９をＥＭ３１の基礎として使用し、ＥＭは、車両システム２６のさまざまな動作状態変更を実現するために、標準制御メッセージとローカル制御メッセージとの間の各種マッピングを規定する。
【0042】
先に述べたように、ＨＡＬ２８は、一例において、車両システム２６のうちの１つ以上の動作状態を変更するために、ディスプレイ２０が提供するＧＵＩを介して乗員から受けた入力に応じて、ＯＳ３０からの出力を処理するように構成された部分を表していてもよい。ＨＡＬ２８はまた、動作状態２７等のその他の入力に応じて自動的に生成されたＯＳ３０からの出力を処理することもできる。この出力は、ＯＳ３０が動作状態変更を実施するために発行したコマンドセット２５を意味し得る。ＯＳ３０は、コマンドセット２５を一連の「ＳＥＴ」コマンドとして発行することができ、これらのコマンドの各々は、車両システム２６のうちの１つを指定し、この車両システム２６のうちの１つの特性を指定し、指定した特性の値を指定する。ＳＥＴコマンドは、車両システム２６のうちの指定された車両システムが維持する動作状態を指定することができる。
【0043】
ＨＡＬ２８は、車両システム２６の各種特性の現在の動作状態２７を示す、車両システム２６からの入力を、処理することもできる。ＯＳ３０は、車両システム２６が現在の動作状態２７を示す入力を与えることによって応答するときの各種特性について、車両システム２６にクエリする「ＧＥＴ」コマンドを出力することができる。「ＳＥＴ」コマンドと同様、「ＧＥＴ」コマンドの各々は、車両システム２６のうちの１つを指定し、値に関するクエリの対象であるこの車両システム２６のうちの１つの特性を指定することができる。いくつかの例において、車両システム２６は、「ＳＥＴ」コマンドに応じて各種動作状態変更を実行した後に、入力で応答することができる。いずれにしても、ＨＡＬ２８は、出力および入力を処理することによって対応関係２９を求めることができる。
【0044】
説明のために、車両システム２６ＡはＨＶＡＣシステムを表していると想定する。各種ＨＶＡＣシステムは、車両の点火装置状態およびＨＶＡＣシステムの基礎となる環境制御ユニット（environmental control unit）（ＥＣＵ）に応じて動作が異なり得る。さらに、ＨＶＡＣシステム２６Ａの各種特性は、ＨＶＡＣシステム２６Ａのその他の特性、および、場合によっては車両システム２６Ｂ～２６Ｎのその他の特性とやり取りすることができるとみなす。たとえば、ＨＶＡＣ温度を設定するとき、ＨＶＡＣシステム２６Ａはファンの速度を自動的に変更することができる。ＨＡＬ２８は、ＨＶＡＣ温度を設定するために車両システム２６にコマンドセット２５Ａを出力した結果としての動作状態２７Ａが表すＨＶＡＣシステム２６Ａの各種車両特性間の対応関係２９を求めることができる。
【0045】
次に、ＨＡＬ２８は、対応関係２９に基づいてコマンドセット２５を適応させることができる。ＨＡＬ２８は、ＨＶＡＣ温度の設定とファン速度の自動変更との間の依存性を特定する対応関係２９に基づいて、ＨＶＡＣシステム２６Ａのファン速度を以前に設定されたファン速度値（乗員の嗜好に基づいて構成することができる、または乗員が以前にＨＶＡＣシステム２６Ａのファン速度を設定した結果としてのファン速度値）に設定する追加コマンドを含むように、適応させることができる。ＨＡＬ２８は、このようにして、対応関係２９（「依存性２９」と呼ぶこともできる）に基づき、車両１０の車両システム２６と第２の車両の車両システムとの間の可変性に対処するようにコマンドセット２５を適応させることができる。
【0046】
ＨＶＡＣの文脈の範囲外のパラメータ間の依存性の他の例は、（スイッチまたはその他のユーザインターフェイスを介して（ヘッドユニットを介することを含む））直接制御可能でありかつドアまたは点火装置状態に関係がある、内部照明（天井灯、読書灯、フロアライトなど）を含み得る。ＨＡＬ２８は、ドアの状態と、運転席のドアが開いたときの照明の点灯との間の依存性を特定することができ、これは、ＨＡＬ２８が、運転席エリアを照らすのにこの照明が有用であると判断することを可能にする。
【0047】
もう１つの例は、ワイパーおよび洗浄装置の文脈であり、ＨＡＬ２８は、洗浄装置が有効にされたときにワイパーが特定のワイパー速度に設定されたと判断することができ、これは、既存のワイパー速度を上書きし得る。さらに別の例は、先進運転支援システム（advanced driver assistance system）（ＡＤＡＳ）の文脈であり、ＨＡＬ２８は、ＡＤＡＳの各種状態は、車両１０が特定の速度で走行しているときまたは車両１０が特定の状態にあるとき（たとえばリバース運転時、ＡＤＡＳは後方カメラを起動し後方カメラが取り込んだ画像をヘッドユニットを介して表示する）に限って利用できると判断することができる。ＨＡＬ２８は、パラメータを求め、次に、照明、ワイパーおよび洗浄機、ＡＤＡＳ、車両状態および／または速度に関する各種依存性のすべてを特定することができる。
【0048】
加えて、ＨＡＬ２８は、車両１０がオンにされたときに利用できるパラメータのリストを求めることができる。一例として、ＨＡＬ２８は、点火装置がオフにされたときにヘッドライトを起動することを車両１０が許可するか否かを判断することができる。なぜなら、一部の車両は、車両の電源がオフにされたときにヘッドライトを自動的にオフにすることができるからである。ＨＡＬ２８は、各種点火装置状態（たとえば、オフ、アクセサリ、オンなど）に関する各種パラメータ間の依存性を求めることができる。ＨＡＬ２８はまた、車両１０のさまざまな状態（ギアが入っているおよび／または移動しているまたは駐車しているおよび／または移動していないなど）に対する座席間の依存性を判断することもできる。
【0049】
この点について、ＨＡＬ２８は、動作状態２７間の変化を処理することにより、この変化の記録を生成し、動作状態２７をパースすることにより、特性間の因果関係を発見することができ（これを「パラメータ」と呼ぶこともでき、たとえばパラメータＡが変化するとパラメータＢおよびＣも変化する）、この動作状態２７の変化と変化の間の因果関係（または言い換えると依存性）を特定する対応関係２９を生成することができる。いくつかの例において、ＨＡＬ２８は、対応関係２９を、テーブル、リンクされたリスト、グラフ、ツリー、またはその他任意の適切なデータ構造として、格納することができる。その他の例として、ＨＡＬ２８は、機械学習を用いてモデルをトレーニングすることにより、対応関係２９を特定し、対応関係２９に応じたコマンドセット２５の異なるバージョンを動的に生成することができる。このため、ＨＡＬ２８は、依存性２９を求めるために、コマンドセット２５によって開始される動作状態変更と車両パラメータの動作状態２７とについて機械学習を実行することができる。
【0050】
ＨＡＬ２８は、これらの依存性２９の特定後、依存性２９によって特定された特定の動作状態変更について、ＯＳ３０がサポートする標準制御メッセージと、動作状態変更を引き起こすのに使用されるローカル制御バスプロトコルに従うローカル制御メッセージとの間のマッピング３１を規定することができる。このマッピングにより、上記トランスレーションが可能になり、このようなマッピングは、ＥＭ３１が、ＯＳ３０、制御バス、および／または車両システム２６のうちの１つ以上の更新のためにある期間にわたって変化し得るという意味で、拡張可能である。いくつかの例において、ＨＡＬ２８がＥＭ３１を規定するのではなく、製造者が手作業でＥＭ３１をプログラムし、標準制御メッセージとローカル制御メッセージとの間のトランスレーションを実施するためにＨＡＬ２８が実行可能なファイルまたはスクリプトを規定することができる。
【0051】
このように、当該技術の各種局面により、製造者はＥＭ３１を規定することができ、ＥＭ３１は、ＯＳ３１、制御バス、および／または車両システム２６のうちの１つ以上の更新に対処するためにある期間にわたって更新することができる。ＥＭ３１は、標準コマンドセットとローカルコマンドセットとの間のトランスレーションを規定することができ、これを車両ヘッドユニットが適用することにより標準コマンドセットとローカルコマンドセットとの間のトランスレーションを自動的に行うことができる。規定する必要があるのはＥＭ３１だけなので、このようなマッピングをオペレーティングシステム内でスタティックにハードコーディングすることによってローカルコマンドセットのみをサポートするのではなく、当該技術の各種局面は、車両ヘッドユニットオペレーティングシステム（たとえばＯＳ３０）を開発できる速度を改善する、新規のまたは変化する制御バスプロトコルとの相互運用性を改善する、また、そうでなければローカルコマンドセットについてフル機能サポートを提供するこのようなオペレーティングシステムの迅速な開発に対応しつつ車両ヘッドユニットオペレーティングシステムの開発を改善することができる。
【0052】
加えて、当該技術の各種局面は、ヘッドユニット２４自体のより効率的な動作を推進することができる。すなわち、ＨＡＬ２８は、コマンドセット２５と動作状態２７の変化との間の対応関係２９を求め、対応関係２９に基づいて、車両システム２６の動作状態２７の変化がより効率的に生じるように、コマンドセット２９を適応させることができる。多数のモデルおよび製造者が選択した車両システム２６に共通するがいくつかの車両システム２６にとっては（機能的ではあるものの）非効率的である可能性があるコマンドセット２５を発行するのではなく、当該技術は、車両システム２６に動作状態２７の変化をより効率的に生じさせることによってプロセッササイクルを削減しメモリ帯域幅とそれとともに消費される元のメモリリソースとを節約し結果としてより効率的な電力消費を促進するコマンドセット２５を、ＨＡＬ２８が適応的に生成することを可能にすることができる。
【0053】
ＨＶＡＣシステムに関連する説明を行ってきたが、当該技術はその他のシステムに関して適用することもできる。可能ないくつかの例は、ヘッドユニット２４が直接制御し得る内部照明システム（たとえば天井灯、読書灯など）、および、関連するドア開放または点火装置状態を含む。ヘッドユニット２４は、運転席のドアが開いたとき、照明がオンすると判断することができ、それにより、この照明は運転席エリアを照らすのに有用であると判断することができる。別の例として、ヘッドユニット２４は、窓のワイパーおよび洗浄装置間の対応関係を特定することができる。ヘッドユニット２４は、特定の車両状態および／または速度と、先進運転支援システム（ＡＤＡＳ）モードとの間の対応関係を特定することができる（特定のＡＤＡＳモードは車の特定の状態および／または速度においてのみ利用可能）。
【0054】
図２Ａおよび図２Ｂは、図１のヘッドユニットの例をより詳細に示すブロック図である。図２Ａの例に示されるヘッドユニット２４Ａは、図１に示されるヘッドユニット２４の一例である。ヘッドユニット２４Ａは、カーサービス２００の実行環境を提供するＯＳ３０を実行することができる。
【0055】
ヘッドユニット２４Ａはまた、２つの異なるＨＡＬ２８Ａおよび２８Ｂを実行することができる。車両ＨＡＬ２８Ａはトランスレーションサービス２０２を実行することができ、このトランスレーションサービスは、本開示に記載の技術の各種側面に従い、ＥＭ３１に基づいて、標準制御メッセージとローカル制御メッセージとの間の変換を実行することができる。コントローラエリアネットワーク（ＣＡＮ）バスＨＡＬ２８Ｂは、ローカル制御メッセージをユニバーサルシステムバス（ＵＳＢ）信号に、ＵＳＢ信号をローカル制御メッセージにコンバートし、ハードウェアとＯＳ３０との間のもう１つの抽象化レイヤを提供するように構成された部分を表していてもよい。
【0056】
ヘッドユニット２４Ａはまた、物理ＵＳＢインターフェイスであるＵＳＢ２０６を、１つ以上のプロセッサ、固定論理回路、専用信号プロセッサ、専用制御プロセッサ（専用制御バスプロセッサ等）および／またはＵＳＢ ＣＡＮインターフェイス２０８およびゲートウェイ２１０をエクスポーズするその他類似のものを、含み得る。ＵＳＢ ＣＡＮインターフェイス２０８は、ＵＳＢポートを介したＣＡＮ２１１へのアクセスを提供するように構成された部分を表していてもよい。ゲートウェイ２１０は、ＣＡＮ２１１へのアクセスを制御するための制御バスゲートウェイをエクスポーズするように構成された部分を表し、特定の条件が成立するときに（たとえば不正形式のＣＡＮ信号をドロップ）ＣＡＮ２１１へのアクセスを制限することができる、ファイアウォールまたはその他の種類のデバイスを表していてもよい。
【0057】
先に述べたように、トランスレーションサービス２０２は、カーサービス２００またはその他の場所（ＯＳ３０が提供する実行環境で実行される１つ以上のアプリケーション等）から発生したものであってもよい標準制御メッセージをＯＳ３０から受けることができる。トランスレーションサービス２０２は、マッピングを格納することができるファイルまたはその他のデータ構造を表し得る。ＥＭ３１の一例は次の通りである。
【0058】
【数1】
【0059】
上記例において、ＥＭ３１は標準コマンド「vehicleProperty」から始まり、これは、続く部分が車両特性（vehicle property）に関連することを示している（これは動作状態に言及するもう１つのやり方である）。次の行は、車両ＨＡＬ（ＶＨＡＬ）特性識別子（「vhalPropertyId」）を窓の動き（「WINDOW_MOVE」）として指定し、これは、パワーウィンドウの開放と閉鎖とのマッピングを規定する。WINDOW_MOVEは、標準識別子の一例を表していてもよく、車両固有でなくてもよい。３行目は、どのようなアクセス（access）が許可されるかを示し、アクセスを読出／書込（「READ_WRITE」）として指定し、窓の動きの特性を（たとえばＧＥＴコマンドにより）読み出すことが可能でありかつ（たとえばＳＥＴコマンドにより）書き込むことが可能であることを示している。車両の各動作状態は、このようにして車両特性識別子およびアクセスレベルを用いて規定することができる。
【0060】
ＥＭ３１は、車両特性およびアクセスを特定する各動作状態のオープニングステートメントに続いて、車両内の適用可能なエリアごとにマッピングを規定することができる。マッピングは、ＣＡＮ信号（「canSignal」）から始まり、開いている波括弧がその後に続く。各ＣＡＮ信号はそれぞれのエリアを指定することができ、第１のマッピングはエリアを第１列左として特定し（「ROW_1_LEFT」）、これは前の運転席側の窓（左ハンドル車両の場合）を指している。次に、前の運転席側の窓のマッピングはメッセージ識別子（「messageId」）を指定し、これは対応するＣＡＮメッセージ（すなわちこの例では０×１２４）に使用されるメッセージ識別子である。次のメッセージはビット（bit）（ゼロに設定）およびサイズ（size）（４に設定）であり、これらは標準制御メッセージをローカル制御メッセージ（この例ではＣＡＮメッセージと呼ぶことができる）にトランスレートするときに設定する必要があるＣＡＮ固有シンタックスである。
【0061】
次は３つの「conversionEnum」ステートメントであり、これらの各々は開き波括弧と閉じ波括弧によって規定される。「conversionEnum」は、（動作なし窓移動を特定するための）標準制御メッセージの列挙と（動作なし窓移動を特定するための）ＣＡＮメッセージとの間のコンバージョンがあることを示す。この例において、コンバージョンは、ＣＡＮ値ゼロを、動作なし窓移動のＶＨＡＬ値（「vhalValue」）を含まない標準制御メッセージに追加する。次のconversionEnumは、（２である）高速開放のvhalValueを、（０×Ａである）高速開放を実行するためのcanValuenにコンバートすることを指定する。第３のconversionEnumは、（負の２である）高速閉鎖のvhalValueを、（０×Ｂである）高速閉鎖を実行するためのcanValueに置換する。
【0062】
第３のconversionEnumに続いて、ＥＭ３１は、前方右側の助手席側の窓（「ROW_1_RIGHT」）を指定し、これは、第１のＣＡＮ信号ステートメントと同じメッセージ識別子を有するが、４ビットとサイズ４を指定する。ＥＭ３１は、複数のconversionEnumステートメントと、場合によっては車の異なるエリアの、その他のＣＡＮ信号ステートメントとを含み得るが、これは説明し易くするために図示されていない。
【0063】
トランスレーションサービス２０２は、前方右側の運転席側の窓の高速開放を、１以上のバイトのシーケンスとして規定する標準制御メッセージを受け、これは、動作状態変更を、WINDOW_MOVE、ROW_1_LEFT、およびvhalValue２で規定する。トランスレーションサービス２０２は、WINDOW_MOVE、ROW_1_LEFTを、０×１２４のメッセージＩＤで置き換えることによってＣＡＮメッセージを生成することができる。同様に、トランスレーションサービス２０２は、右の運転席側サイドウィンドウの高速開放を指定するＣＡＮメッセージをコンバートし、０×１２４のメッセージＩＤ、ビットサイズ０｜４、および０×ＡのＣＡＮ値を、WINDOW_MOVE、ROW_1_LEFT、およびvhalValue２で置き換えることができる。
【0064】
ＥＭ３１の別の例を以下に示す。これは温度を摂氏（Celsius）で送る。
【0065】
【数2】
【0066】
上記例において、ＥＭ３１はＨＶＡＣ温度セットのvhalPropertyIdを指定する（「HVAC_TEMPERATURE_SET」）。これはＯＳ３０が使用する標準ＩＤである。第３行でアクセスが指定されており、この場合の車両１０はヘッドユニット２４が温度を設定するのを許可しないので（これは専用ボタンまたはその他の制御しか設定することができない）、ＥＭ３１は読出アクセスを設定する。canSignalステートメントにおいて、ＥＭ３１はエリアを前側の列の運転席側と定め、ＣＡＮ固有シンタックスの数を、メッセージＩＤ、ビット、サイズ、スケールおよびオフセットの形態で指定し、これらの各々は一般的なＣＡＮシンタックスである。「conversion（コンバージョン）」が規定され、それによりＥＭ３１は「FAHRENHEIT_TO_CELSIUS」というタイトルの関数に対する方法コールを指定する。
【0067】
トランスレーションサービス２０２は、ＨＶＡＣ温度を要求する標準制御メッセージを受けてＣＡＮメッセージを生成することができる。ＣＡＮメッセージは、０×１２３というメッセージＩＤと、８｜１６としてのビットおよびサイズ（ビット８は温度値がペイロードの８番目のビットから始まる位置にあることを示し、サイズは値がペイロードの２バイトを取ることを示す）とを、スケールおよびオフセットとともに含む。トランスレーションサービス２０２は、このメッセージをＣＡＮ－ＵＳＢ ＨＡＬに転送することができ、これは、ＣＡＮメッセージを、ＵＳＢ ＣＡＮインターフェイスを介しゲートウェイ２１０を介してＣＡＮ２１１に出力する前に、ＵＳＢ信号にコンバートする。ＣＡＮ２１１は、ＣＡＮメッセージを１つ以上の車両システム２６に送信することができ、これらの車両システムは、図２Ａの例において電子制御ユニット（ＥＣＵ）２１２Ａ～２１２Ｎ（「ＥＣＵ２１２」）として示されている。
【0068】
ＨＶＡＣを制御する役割を担うＥＣＵ２１２のうちの１つは、このメッセージに対し、華氏（Fahrenheit）の温度で応答し、ペイロードのビット８で始まる華氏の温度を、スケール２およびオフセット５０の２バイトの温度として指定する（たとえば９０度という温度は４０として指定することができる）。ＨＶＡＣ ＥＣＵ２１２は、ＣＡＮメッセージをＣＡＮバス２１１を介して送信することでき、そうすると、ゲートウェイ２１０、ＵＳＢ ＣＡＮインタ０フェイス２０８、およびＣＡＮ－ＵＳＢ ＨＡＬ ２０４は、ＣＡＮメッセージをトランスレーションサービス２０２に中継する。
【0069】
トランスレーションサービス２０２は、上記マッピングに従ってＣＡＮメッセージをトランスレートすることができ、メッセージＩＤ，ビット、サイズ、スケール、およびオフセットを、HVAC_TEMPERATURE SET、READ、およびROW_1_LEFTに置き換える。トランスレーションサービス２０２は、温度をパースし、FAHRENHEIT_TO_CELSIUS方法を呼び出し、温度を上記方法に送る。トランスレーションサービス２０２は、温度を送る前に、スケールおよびオフセットに従って温度を処理することができる（実際の温度である華氏９０度に戻すために）。FAHRENHEIT_TO_CELSIUS方法は、華氏の温度から摂氏の温度にコンバートし、温度を標準制御メッセージに指定する。トランスレーションサービス２０２は次に、標準制御メッセージをカーサービス２００に送信することができる。
【0070】
上記例では特定のコンバージョンプロセス、すなわちFAHRENHEIT_TO_CELSIUSに関して説明しているが、この技術は他の種類のコンバージョンに関して実施することもできる。たとえば、コンバージョンプロセスの他の例は、車両の走行距離を１回転ごとに計算するRADIUS_TO_CIRCUMFERENCE、読出を対数ポテンショメータから線形スケールまたはその逆にコンバートするLOGまたはEXPONENTを含む。
【0071】
ＥＭ３１の第３の例を以下に示す。これは、＋１／－１イベントとして温度を車両システム２６のＨＶＡＣシステムに送る。
【0072】
【数3】
【0073】
直上の例において、ＥＭ３１は、vhalPropertyIDである「HVAC_TEMPERATURE_SET」を、アクセス「WRITE」および前の左の運転席側のエリア（「ROW_1_LEFT」）とともに指定し、これは、標準制御メッセージのシンタックスにマッピングされる。次に、ＥＭ３１は、messageIdとして０×１２３、ビット０、サイズ２、およびオフセット－１を指定し、これらはすべて、vhalPropertyId、アクセスおよびエリアの代わりに使用されるＣＡＮプロトコルシンタックスを表す。次に、ＥＭ３１は、方法「DELTA_UPDATE」をコールするコンバージョンを指定し、「deltaUpdate」のパラメータ（「params」）をリストする。ＥＭ３１のdeltaUpdateの中には、初期値（「initValue」）として摂氏２０度、および温度の最大ステップ（「maxStep」）サイズがある。
【0074】
トランスレーションサービス２０２は、HVAC_TEMPERATURE_SET、WRITEおよびROW_1_LEFTをリストするカーサービス２００から標準制御メッセージを受けるかそうでなければ取得することができ、これらの標準シンタックス要素を０×１２３、０、２、－１に置き換える。トランスレーションサービス２０２は、ペイロードのビット０において、２バイト温度更新として－１または１を挿入することにより、標準制御メッセージをＣＡＮメッセージにトランスレートすることができる。トランスレーションサービス２０２はＣＡＮメッセージをＣＡＮ－ＵＳＢ ＨＡＬ２０４に出力することができ、これは、ＣＡＮメッセージを、ＵＳＢ ＣＡＮインターフェイス２０８およびゲートウェイ２１０を介してＵＳＢ信号を送信する前に、ＵＳＢ信号にコンバートする。
【0075】
ＣＡＮ２１１は、ＣＡＮメッセージを受け、このＣＡＮメッセージをＥＣＵ２６に中継することができ、ここで、ＥＣＵ２１２のうちの適切なもの（すなわちこの例ではＨＶＡＣ ＥＣＵ）が、ＣＡＮメッセージを処理し、応答ＣＡＮメッセージを出力することができる。応答ＣＡＮメッセージは、トランスレーションサービス２０２に到達する前に、ＣＡＮ２１１、ゲートウェイ２１０、ＵＳＢ ＣＡＮインターフェイス２０８、およびＣＡＮ－ＵＳＢ ＨＡＬ２０４を通ることができる。トランスレーションサービス２０２は、逆トランスレーション、言い換えるとマッピングを、ＥＭ３１の上記例に基づいて、応答ＣＡＮメッセージについて実行することにより、応答標準制御メッセージを取得することができる。トランスレーションサービス２０２は、応答標準制御メッセージをカーサービス２００に出力することができる。
【0076】
図２Ｂの例において、ヘッドユニット２４Ｂは、図１の例に示されるヘッドユニット２４の別の例である。ヘッドユニット２４Ｂは、ヘッドユニット２４Ａと、図２Ｂの例ではゲートウェイ２１０がトランスレーションサービス２０２に関して先に述べたトランスレーションサービスを実行し得る点を除いて、たとえ実質上同様でなくても同様であり得る。ヘッドユニット２４Ｂのトランスレーションサービス２０２は、その他のフォーマット、コンバージョン、またはＥＭ３１に従うゲートウェイ２１０が出力した標準制御メッセージに対するその他のプロセスを実行し得る一般的なＶＨＡＬサービス２２０に置き換えられる。製造者は、ＣＡＮアクセスのファイアウォールを介した追加のセキュリティを提供するために、ゲートウェイ２１０をプログラムすることによりトランスレーションサービス２０２を実行することができる。
【0077】
図３は、本開示に記載の技術の各種局面に従いコマンドセット２５－１Ａを適応させる図１に示されるＨＡＬ２８の一例を示す図である。ＨＡＬ２８は、最初に、最大空調設定を意味し得る「ＭＡＸ ＡＣ」を与えるためにＨＶＡＣシステム２６Ａの各種パラメータを設定する動作状態変更５０Ａのためのコマンドセット２５－１Ａを設定することができる。乗員がＭＡＸ ＡＣ ５０Ａを選択そうでなければ起動したことに応じて、ＨＡＬ２８はコマンド５２Ａ～５２Ｆを発行することができる。
【0078】
コマンド５２ＡはＳＥＴコマンドを指定し、これは変数としてシステム識別子とパラメータと値とを取る。この例のシステム識別子を「ＨＶＡＣ＿ＳＹＳ」と想定し、これは、ＨＶＡＣシステム２６Ａに対応付けられた識別子を表す。コマンド５２Ａ～５２Ｆはすべて、同一のシステム識別子であるＨＶＡＣ＿ＳＹＳを指定する。コマンド５２Ａのパラメータは説明のために「ＦＡＮ」と想定し、これは、ＨＶＡＣシステム２６Ａのファン速度を意味し得る。コマンド５２Ａの値は、ファン速度を「ＨＩＧＨ」に設定する。
【0079】
コマンド５２Ｂは、コマンド５２Ａと同一のシステム識別子を指定するが、ファン速度と「５」に設定する。冗長コマンド（同一パラメータに対して同様または同一の設定を開始しようとし得るコマンドを意味する）がコマンドセット２５－１Ａの中にある。なぜなら、コマンドセット２５－１Ａは、同一製造者の複数の異なるモデルに対しておよび／または異なる製造者の複数の異なるモデルに対してＭＡＸ ＡＣ５０Ａを開始することができる最初の包括コマンドセットであるからである。
【0080】
コマンド５２Ｃは、コマンド５２Ａと同一のシステム識別子を指定するが、ＨＶＡＣシステム２６Ａが維持すべき車室温度を意味する異なるパラメータ「ＴＥＭＰ」を指定する、別のＳＥＴコマンドである。コマンド５２Ｃは、車室温度を値「６５」に設定するこれは説明のため華氏温度であると想定する）。
【0081】
コマンド５２Ｄは、コマンド５２Ａと同一のシステム識別子を指定するが、冷気を排出するための車両１０の車室内の通風孔（vent）または一組の通風孔を意味する異なるパラメータ「ＶＥＮＴ」を指定する、別のＳＥＴコマンドである。コマンド５２Ｄは、ＶＥＮＴを、各種ＥＣＵにおけるダッシュベント（dash vent）を意味し得る、値「ＨＩＧＨ」に設定する。
【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】
本開示の技術は、車両パラメータ間の依存性２９を抽出するためのアルゴリズムを提供することができる。ＨＡＬ２８は、設定（set）／取得（get）できる特性のリストを求めることができる。ある特性から副作用が生じる（たとえば特性を設定するとシステム内の他の特性が変化する）場合、ＨＡＬ２８はこの対応関係２９を検出して記録し、現在許可されていない動作変更を乗員が開始すると、ＨＡＬ２８は、動作変更を開始するためにコマンドセット２５を介して如何にして特性を設定するかを判断することができる。
【0110】
依存性を求めるためにＨＡＬ２８ができることは次の通りである。
１）いつ特性が変化するかを観察しその記録を保持する。
２）データをパースしてパラメータ間の因果関係を発見する。たとえばパラメータＡが変化するとそれに伴ってパラメータＢおよびＣも変化する。
３）これらの因果関係のテーブルを作成し、車両特性についてシステムがアクションを起こすときにこれを参照する。
１）いつ特性が変化するかを観察しその記録を保持する。
２）データをパースしてパラメータ間の因果関係を発見する。たとえばパラメータＡが変化するとそれに伴ってパラメータＢおよびＣも変化する。
３）これらの因果関係のテーブルを作成し、車両特性についてシステムがアクションを起こすときにこれを参照する。
【0111】
ＨＡＬ２８は多数のやり方で実現することができる。いくつかの場合において、ＨＡＬ２８は、機械学習（ＭＬ）トレーニングセットを、ある期間にわたって観察されたデータとして収集することができる。その他の場合において、ＨＡＬ２８は、特性の一時的相互関係を追跡しこの対応関係からヒューリスティックスを求めることができる。いずれの場合も、コンセプトは、コマンドセット２５を各車両の特異性に自動的に適応させることをＨＡＬ２８に実行させ、人間がこれをコードに手作業で入力する必要がないということである。このようにして、ＨＡＬ２８は、複雑さを減じることにより、新たな車両実装を市場に出すことができる。なぜなら、ＨＡＬ２８は、車両内の変化に自動的に適応することができ、ハードコーディングされる必要がないからである。
【0112】
項目１．第１の車両とインターフェイスする方法であって、この方法は、プロセッサが、上記第１の車両の１つ以上のシステムに対し、上記１つ以上のシステムの動作状態変更を開始するためのコマンドセットを発行するステップと、上記コマンドセットの発行に応じて、上記動作状態変更後に、上記プロセッサが、上記１つ以上のシステムから、１つ以上の車両パラメータの各々の動作状態のそれぞれの指示を取得するステップと、上記プロセッサが、上記コマンドセットについて、上記１つ以上の車両パラメータの動作状態間の１つ以上の依存性を求めるステップと、上記プロセッサが、上記１つ以上の依存性に基づいて、上記第１の車両の上記１つ以上のシステムと第２の車両の１つ以上のシステムとの間の可変性に対処するように上記コマンドセットを適応させるステップとを含む。
【0113】
項目２．項目１の方法であって、上記コマンドセットは、上記１つ以上の車両パラメータの第１のサブセットの各々の状態を指定するための第１のコマンドセットを含み、上記コマンドセットを適応させるステップは、上記１つ以上の車両パラメータの第２のサブセットの各々の状態を指定するための第２のコマンドセットを求めるステップを含み、上記１つ以上の車両パラメータの第１のサブセットは、上記１つ以上の車両パラメータの第２のサブセットと異なる。
【0114】
項目３．項目１および２のいずれかの組み合わせに従う方法であって、上記コマンドセットを適応させるステップは、上記プロセッサが、上記コマンドセットを適応させるためにハードウェア抽象化レイヤを実行するステップを含む。
【0115】
項目４．項目１～３のいずれかの組み合わせに従う方法であって、上記１つ以上の依存性を求めるステップは、上記コマンドセットによって開始された上記動作状態変更を、上記１つ以上の車両パラメータの動作状態に対応付けるテーブルを維持するステップを含む。
【0116】
項目５．項目１～４のいずれかの組み合わせに従う方法であって、上記１つ以上の依存性を求めるステップは、上記コマンドセットによって開始された上記動作状態変更と、上記１つ以上の車両パラメータの状態とについて機械学習を実行することにより、上記１つ以上の依存性を識別するステップを含む。
【0117】
項目６．項目１～５のいずれかの組み合わせに従う方法であって、上記コマンドセットのグラフィカルユーザインターフェイス要素表現をディスプレイデバイスを介して表示するステップをさらに含む。
【0118】
項目７．項目１～６のいずれかの組み合わせに従う方法であって、上記コマンドセットは、最初は上記１つ以上のシステムの上記動作状態変更を開始することはできず、上記コマンドセットを適応させるステップは、上記１つ以上のシステムの上記動作状態変更を上記コマンドセットが開始できるように上記コマンドセットを適応させるステップを含む。
【0119】
項目８．項目１～７のいずれかの組み合わせに従う方法であって、上記第１の車両の上記１つ以上のシステムは、上記第１の車両の暖房・換気・空調（ＨＶＡＣ）システムを含む。
【0120】
項目９．項目１～８のいずれかの組み合わせに従う方法であって、上記第１の車両の上記１つ以上のシステムは、第１組の販売業者からのものであり、上記第２の車両の上記１つ以上のシステムは、第２組の販売業者からのものであり、上記第１組の販売業者と上記第２組の販売業者とは、少なくとも１つの販売業者が異なっている。
【0121】
項目１０．第１の車両とインターフェイスするように構成されたデバイスであって、ヘッドユニットは、上記第１の車両の１つ以上のシステムの動作状態変更を開始するためのコマンドセットを格納するように構成された１つ以上のメモリと、１つ以上のプロセッサとを備え、１つ以上のプロセッサは、上記第１の車両の上記１つ以上のシステムに対して上記コマンドセットを発行し、上記コマンドセットを発行したことに応じて、上記動作状態変更後に、上記１つ以上のシステムから、１つ以上の車両パラメータの各々の動作状態のそれぞれの指示を取得し、上記コマンドセットについて、上記１つ以上の車両パラメータの動作状態間の１つ以上の依存性を求め、上記１つ以上の依存性に基づいて、上記第１の車両の上記１つ以上のシステムと第２の車両の１つ以上のシステムとの間の可変性に対処するように上記コマンドセットを適応させるように、構成されている。
【0122】
項目１１．項目１０のデバイスであって、上記コマンドセットは、上記１つ以上の車両パラメータの第１のサブセットの各々の状態を指定するための第１のコマンドセットを含み、上記１つ以上のプロセッサは、上記１つ以上の車両パラメータの第２のサブセットの各々の状態を指定するための第２のコマンドセットを求めるように構成され、上記１つ以上の車両パラメータの第１のサブセットは、上記１つ以上の車両パラメータの第２のサブセットと異なる。
【0123】
項目１２．項目１０および１１のいずれかの組み合わせに従うデバイスであって、上記１つ以上のプロセッサは、上記コマンドセットを適応させるように構成されたハードウェア抽象化レイヤを含むオペレーティングシステムを実行するように構成されている。
【0124】
項目１３．項目１０～１２のいずれかの組み合わせに従うデバイスであって、上記１つ以上のプロセッサは、上記コマンドセットによって開始された上記動作状態変更を、上記１つ以上の車両パラメータの動作状態に対応付けるテーブルを維持するように構成されている。
【0125】
項目１４．項目１０～１３のいずれかの組み合わせに従うデバイスであって、上記１つ以上のプロセッサは、上記コマンドセットによって開始された上記動作状態変更と、上記１つ以上の車両パラメータの状態とについて機械学習を実行することにより、上記１つ以上の依存性を識別するように構成されている。
【0126】
項目１５．項目１０～１４のいずれかの組み合わせに従うのデバイスであって、上記コマンドセットのグラフィカルユーザインターフェイス要素表現を表示するように構成されたディスプレイデバイスをさらに備える。
【0127】
項目１６．項目１０～１５のいずれかの組み合わせに従うのデバイスであって、上記コマンドセットは、最初は上記１つ以上のシステムの上記動作状態変更を開始することはできず、上記１つ以上のプロセッサは、上記１つ以上のシステムの上記動作状態変更を上記コマンドセットが開始できるように上記コマンドセットを適応させるように構成されている。
【0128】
項目１７．項目１０～１６のいずれかの組み合わせに従うのデバイスであって、上記第１の車両の上記１つ以上のシステムは、上記第１の車両の暖房・換気・空調（ＨＶＡＣ）システムを含む。
【0129】
項目１８．項目１０～１７のいずれかの組み合わせに従うデバイスであって、上記第１の車両の上記１つ以上のシステムは、第１組の販売業者からのものであり、上記第２の車両の上記１つ以上のシステムは、第２組の販売業者からのものであり、上記第１組の販売業者と上記第２組の販売業者とは、少なくとも１つの販売業者が異なっている。
【0130】
項目１９．項目１０～１８のいずれかの記載の組み合わせに従うデバイスであって、上記第１の車両はヘッドユニットを含み、上記ヘッドユニットは上記メモリと上記１つ以上のプロセッサとを含む。
【0131】
項目２０．実行されると１つ以上のプロセッサに以下の動作を実行させる命令が格納されたコンピュータ読取可能媒体であって、上記動作は、車両の１つ以上のシステムに対し、上記１つ以上のシステムの動作状態変更を開始するためのコマンドセットを発行することと、上記コマンドセットを発行したことに応じて、上記動作状態変更後に、上記１つ以上のシステムから、１つ以上の車両パラメータの各々の動作状態のそれぞれの指示を取得し、上記コマンドセットについて、上記１つ以上の車両パラメータの動作状態間の１つ以上の依存性を求め、上記１つ以上の依存性に基づいて、上記第１の車両の上記１つ以上のシステムと第２の車両の１つ以上のシステムとの間の可変性に対処するように上記コマンドセットを適応させることを含む。
【0132】
項目２１．車両の１つ以上のプロセッサが、オペレーティングシステムを実行することにより前記車両の１つ以上のシステムを制御するステップと、前記１つ以上のプロセッサが、制御バスプロトコルに従い指定されたローカル制御メッセージと前記オペレーティングシステムがサポートする標準制御メッセージとの間の拡張可能マッピングを取得するステップと、前記１つ以上のプロセッサが実行する前記オペレーティングシステムが、前記標準制御メッセージを生成するステップとを含み、前記標準制御メッセージは、前記１つ以上のシステムの動作状態変更を開始するためのコマンドセットの第１の表現を含み、前記１つ以上のプロセッサが、前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより、前記ローカル制御メッセージを取得するステップを含み、前記ローカル制御メッセージは、前記コマンドセットの第２の表現を含み、前記１つ以上のプロセッサが、前記１つ以上のプロセッサと前記１つ以上のシステムとに結合された制御バスを介して前記ローカル制御メッセージを送信することにより、前記１つ以上のシステムの前記動作状態変更を開始するステップを含む。
【0133】
項目２２．項目２１の方法であって、前記拡張可能マッピングを取得するステップは、前記ローカル制御メッセージと前記標準制御メッセージとの間の前記拡張可能マッピングを規定するファイルを取得するステップを含む。
【0134】
項目２３．項目２１または２２のいずれかの組み合わせに従う方法であって、前記標準制御メッセージをトランスレートするステップは、車両ハードウェア抽象化レイヤを実行することにより前記制御バスと前記オペレーティングシステムとの間のシムを提供するステップと、前記車両ハードウェア抽象化レイヤが、前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより、前記ローカル制御メッセージを取得するステップとを含む。
【0135】
項目２４．項目２１～２３のいずれかの組み合わせに従う方法であって、前記標準制御メッセージをトランスレートするステップは、前記１つ以上のプロセッサの専用制御バスプロセッサが、制御バスゲートウェイを実行することにより、前記制御バスと前記オペレーティングシステムとの間のシムを提供するステップと、前記制御バスゲートウェイが前記拡張可能マッピングに基づいて前記標準制御メッセージを前記ローカル制御メッセージにトランスレートするステップとを含む。
【0136】
項目２５．項目２１～２４のいずれかの組み合わせに従う方法であって、前記制御バスを介して第２のローカル制御メッセージを受けるステップと、前記拡張可能マッピングに基づいて、前記第２のローカル制御メッセージをトランスレートすることにより、第２の標準制御メッセージを取得するステップと、前記第２の標準制御メッセージに基づいて、１つ以上の車両パラメータの１つ以上の動作状態を更新するステップとをさらに含む。
【0137】
項目２６．項目２１～２５のいずれかの組み合わせに従う方法であって、前記ローカル制御メッセージと前記標準制御メッセージとの間の異なるマッピングを規定する更新された拡張可能マッピングを取得するステップをさらに含む。
【0138】
項目２７．項目２１～２６のいずれかの組み合わせに従う方法であって、上記車両の上記１つ以上のシステムは、上記車両の暖房・換気・空調システムを含む。
【0139】
項目２８．項目２１～２７のいずれかの組み合わせに従う方法であって、上記制御バスプロトコルはコントローラエリアネットワーク（ＣＡＮ）プロトコルを含む。
【0140】
項目２９．項目２１～２８のいずれかの組み合わせに従う方法であって、上記ローカル制御メッセージは、ＤＢＣフォーマットまたはカヤックＣＡＮ定義（ＫＣＤ）フォーマットのうちの一方に従いフォーマットされたローカル制御メッセージを含む。
【0141】
項目３０．項目２１～２９のいずれかの組み合わせに従う方法であって、前記車両の前記１つ以上のシステムに対し、前記１つ以上のシステムの試験的動作状態変更を開始するための試験的コマンドセットを発行するステップと、前記コマンドセットの発行に応じて、前記試験的動作状態変更の後に、前記１つ以上のシステムから、１つ以上の車両パラメータの各々の実際の動作状態のそれぞれの指示を取得するステップと、前記試験的コマンドセットについて、前記１つ以上の車両パラメータの前記実際の動作状態の間の１つ以上の依存性を求めるステップと、前記１つ以上の依存性に基づいて前記拡張可能マッピングを生成することにより、前記コマンドセットを前記ローカル制御メッセージから前記標準制御メッセージにトランスレートするステップとをさらに含む。
【0142】
項目３１．車両とやり取りするように構成されたデバイスであって、前記デバイスは、制御バスプロトコルに従い指定されたローカル制御メッセージとオペレーティングシステムがサポートする標準制御メッセージとの間の拡張可能マッピングを格納するように構成されたメモリと、１つ以上のプロセッサとを備え、前記１つ以上のプロセッサは、前記オペレーティングシステムを実行することにより前記車両の１つ以上のシステムを制御するように構成され、前記オペレーティングシステムは、前記標準制御メッセージを生成するように構成され、前記標準制御メッセージは、前記１つ以上のシステムの動作状態変更を開始するためのコマンドセットの第１の表現を含み、前記１つ以上のプロセッサは、前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより前記ローカル制御メッセージを取得するように構成され、前記ローカル制御メッセージは、前記コマンドセットの第２の表現を含み、前記１つ以上のプロセッサは、前記１つ以上のプロセッサと前記１つ以上のシステムとに結合された制御バスを介して前記ローカル制御メッセージを送信することにより、前記１つ以上のシステムの前記動作状態変更を開始するように構成されている。
【0143】
項目３２．項目３１のデバイスであって、前記１つ以上のプロセッサは、前記ローカル制御メッセージと前記標準制御メッセージとの間の前記拡張可能マッピングを規定するファイルを取得するように構成されている。
【0144】
項目３３．項目３１および３２のいずれかの組み合わせに従うデバイスであって、前記１つ以上のプロセッサは、車両ハードウェア抽象化レイヤを実行することにより前記制御バスと前記オペレーティングシステムとの間のシムを提供するように構成され、かつ、前記車両ハードウェア抽象化レイヤによって前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより、前記ローカル制御メッセージを取得するように構成されている。
【0145】
項目３４．項目３１から３３のいずれかの組み合わせに従うデバイスであって、前記１つ以上のプロセッサは、前記１つ以上のプロセッサの専用制御バスプロセッサによって制御バスゲートウェイを実行することにより、前記制御バスと前記オペレーティングシステムとの間のシムを提供するように構成され、かつ、前記制御バスゲートウェイによって前記拡張可能マッピングに基づいて前記標準制御メッセージを前記ローカル制御メッセージにトランスレートするように構成されている。
【0146】
項目３５．項目３１～３４のいずれかの組み合わせに従うデバイスであって、前記１つ以上のプロセッサはさらに、前記制御バスを介して第２のローカル制御メッセージを受けるように構成され、前記拡張可能マッピングに基づいて、前記第２のローカル制御メッセージをトランスレートすることにより、第２の標準制御メッセージを取得するように構成され、かつ、前記第２の標準制御メッセージに基づいて、１つ以上の車両パラメータの１つ以上の動作状態を更新するように構成されている。
【0147】
項目３６．項目３１～３５のいずれかの組み合わせに従うデバイスであって、前記１つ以上のプロセッサはさらに、前記ローカル制御メッセージと前記標準制御メッセージとの間の異なるマッピングを規定する更新された拡張可能マッピングを取得するように構成されている。
【0148】
項目３７．項目３１～３６のいずれかの組み合わせに従うデバイスであって、前記車両の前記１つ以上のシステムは前記車両の暖房・換気・空調システムを含む。
【0149】
項目３８．項目３１～３７のいずれかの組み合わせに従うデバイスであって、前記制御バスプロトコルはコントローラエリアネットワーク（ＣＡＮ）プロトコルを含む。
【0150】
項目３９．項目３１～３８のいずれかの組み合わせに従うデバイスであって、前記ローカル制御メッセージは、ＤＢＣフォーマットまたはカヤックＣＡＮ定義（ＫＣＤ）フォーマットのうちの一方に従ってフォーマットされたローカル制御メッセージを含む。
【0151】
項目４０．命令が格納された非一時的なコンピュータ読取可能記憶媒体であって、前記命令は、実行されると、車両ヘッドユニットの１つ以上のプロセッサに、オペレーティングシステムを実行することにより前記車両の１つ以上のシステムを制御することと、制御バスプロトコルに従い指定されたローカル制御メッセージと前記オペレーティングシステムがサポートする標準制御メッセージとの間の拡張可能マッピングを取得することとを実行させ、前記オペレーティングシステムは前記標準制御メッセージを生成するように構成され、前記標準制御メッセージは、前記１つ以上のシステムの動作状態変更を開始するためのコマンドセットの第１の表現を含み、さらに、前記拡張可能マッピングに基づいて前記標準制御メッセージをトランスレートすることにより前記ローカル制御メッセージを取得することを実行させ、前記ローカル制御メッセージは、前記コマンドセットの第２の表現を含み、さらに、前記１つ以上のプロセッサが、前記１つ以上のプロセッサと前記１つ以上のシステムとに結合された制御バスを介して前記ローカル制御メッセージを送信することにより、前記１つ以上のシステムの前記動作状態変更を開始することを実行させる。
【0152】
限定ではなく例示として、そのようなコンピュータ読取可能記憶媒体は、所望のプログラムコードを命令またはデータ構造の形態で格納するために使用することができるとともにコンピュータがアクセスできる、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または任意の他の記憶媒体を含み得る。また、任意の接続は適切にコンピュータ読取可能媒体と呼ばれる。たとえば、同軸ケーブル、光ファイバケーブル、撚り対線、デジタル加入者線（ＤＳＬ）、または、赤外線、無線、およびマイクロ波等の無線技術を使用して、命令をウェブサイト、サーバまたは他のリモートソースから送信する場合、当該同軸ケーブル、光ファイバケーブル、撚り対線、ＤＳＬ、または、赤外線、無線、およびマイクロ波等の無線技術は、媒体の定義に含まれる。しかしながら、コンピュータ読取可能記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まないがその代わりに非一時的な有形の記憶媒体に向けられることが理解されるはずである。本明細書で使用されるディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタルバーサタイルディスク（ＤＶＤ）、フロッピー（登録商標）ディスクおよびブルーレイ（登録商標）ディスクを含み、ディスク（ｄｉｓｋ）は通常磁気的にデータを再生するものであり、ディスク（ｄｉｓｃ）はレーザでデータを光学的に再生するものである。これらの組み合わせもコンピュータ読取可能媒体の範囲に含まれねばならない。
【0153】
命令は、１つ以上のプロセッサによって実行されてもよく、たとえば、１つ以上のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルロジックアレイ（ＦＰＧＡ）、または他の同等の集積もしくは離散論理回路によって実行されてもよい。したがって、本明細書で使用されている「プロセッサ」という用語は、上記構造、または、本明細書に記載されている技術の実現に適した任意の他の構造のうちのいずれかを指す。加えて、いくつかの局面において、記載されている機能は、専用ハードウェアおよび／またはソフトウェアモジュール内に与えられてもよい。また、当該技術は１つ以上の回路または論理素子において完全に実現することが可能である。
【0154】
本開示の技術は、無線ハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえばチップセット）を含む多様なデバイスまたは装置において実現されてもよい。各種コンポーネント、モジュール、またはユニットは、本開示において、開示されている技術を実行するように構成されたデバイスの機能的側面を強調するように記載されているが、必ずしも異なるハードウェアユニットによる実現を要求していない。むしろ、上述のように、各種ユニットは、ハードウェアユニットにおいて組み合わされてもよい、または、好適なソフトウェアおよび／またはファームウェアとともに上記１つ以上のプロセッサを含む共同作業するハードウェアユニットの集まりによって提供されてもよい。
【0155】
さまざまな実施形態について説明した。これらのおよびその他の実施形態は以下の請求項の範囲に含まれる。
【図1】
【図2A】
【図2B】
【図3】
【図4】
【図5】
【図6】