特表 2024-510746 車両のためのサービス指向データアーキテクチャ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-03-11

(54)【発明の名称】車両のためのサービス指向データアーキテクチャ

(51)【国際特許分類】

   G06F 9/455 20180101AFI20240304BHJP

   G06F 9/54 20060101ALI20240304BHJP

【ＦＩ】

G06F9/455 150

G06F9/54 Z

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023555578

(86)(22)【出願日】2022-03-14

(85)【翻訳文提出日】2023-11-09

(86)【国際出願番号】 US2022020159

(87)【国際公開番号】W WO2022192773

(87)【国際公開日】2022-09-15

(31)【優先権主張番号】63/160,645

(32)【優先日】2021-03-12

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】521411231

【氏名又は名称】ウーブン バイ トヨタ，ユーエス，インコーポレイティド

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100123582

【弁理士】

【氏名又は名称】三橋 真二

(74)【代理人】

【識別番号】100092624

【弁理士】

【氏名又は名称】鶴田 準一

(74)【代理人】

【識別番号】100147555

【弁理士】

【氏名又は名称】伊藤 公一

(74)【代理人】

【識別番号】100123593

【弁理士】

【氏名又は名称】関根 宣夫

(74)【代理人】

【識別番号】100133835

【弁理士】

【氏名又は名称】河野 努

(74)【代理人】

【識別番号】100135976

【弁理士】

【氏名又は名称】宮本 哲夫

(72)【発明者】

【氏名】ジェイソン スティンソン

(72)【発明者】

【氏名】クリストファー ヘイザー

(72)【発明者】

【氏名】オーウェン デイビス

(72)【発明者】

【氏名】カリード アザム

(72)【発明者】

【氏名】パース パテル

(57)【要約】

ここで述べられるシステム、方法及び他の実施形態は、車両内のサービス指向データアーキテクチャに関連する。一実施形態では、車両の電子システムを制御するコンピューティングシステムは、複数の仮想マシン（ＶＭ）を実行して車両の異なるサービスを分離するシステム処理部を備える。コンピューティングシステムは、複数のＶＭ間にまたがって複数のＶＭ並びに車両のメカトロニクス層及びセンサ層を横切る通信を提供する。複数のＶＭは、プログラムされた機能とは独立して自己完結して標準化され、且つ、通信プレーン及び複数のＶＭと相互動作するように形成されたマイクロサービスを実行することによって、異なるサービスを提供する。

【特許請求の範囲】

【請求項1】

車両の電子システムを制御するためのコンピューティングシステムであって、
複数の仮想マシン（ＶＭ）を実行して前記車両の異なるサービスを分離するシステム処理部と、
前記複数のＶＭ間にまたがって前記複数のＶＭ並びに前記車両のメカトロニクス層及びセンサ層を横切る通信を提供する通信プレーンと、
を備え、
前記複数のＶＭは、プログラムされた機能とは独立して自己完結して標準化され、且つ、前記通信プレーン及び前記複数のＶＭと相互動作するように形成されたマイクロサービスを実行することによって、前記異なるサービスを提供する、コンピューティングシステム。

【請求項2】

前記通信プレーンは、前記メカトロニクス層及び前記センサ層のパラメータを制御し且つ前記メカトロニクス層及び前記センサ層からデータを取得するために、前記メカトロニクス層と、前記センサ層と、前記複数のＶＭとの間の通信を提供し、
前記メカトロニクス層は、前記車両内のアクチュエータを制御する電子制御ユニット（ＥＣＵ）を含み、前記センサ層は、前記車両の電子センサを含む、請求項１に記載のコンピューティングシステム。

【請求項3】

前記通信プレーンは、前記メカトロニクス層から前記複数のＶＭへのＣＡＮフォーマットの通信と、前記センサ層から前記複数のＶＭへの通信とを、ＶＭマネージャの抽象化層を介して変換する、請求項２に記載のコンピューティングシステム。

【請求項4】

前記通信プレーンは、少なくとも前記マイクロサービスを含む、前記複数のＶＭのコンポーネント間における直接の通信を提供するための制御プレーン及びデータプレーンを更に含む、請求項１に記載のコンピューティングシステム。

【請求項5】

前記データプレーンは、前記複数のＶＭのコンポーネント間及び前記コンポーネントと前記センサ層との間に自由な専用のチャネルブローカを提供するピアツーピア（Ｐ２Ｐ）ネットワークであり、前記データプレーンは通信プロトコルのトランスポート層の上部で機能して前記コンポーネント間の前記通信を提供する、請求項４に記載のコンピューティングシステム。

【請求項6】

前記制御プレーンは、前記コンポーネント間のイベント駆動型の通信経路であり、
前記制御プレーンは、前記複数のＶＭ内で実行され且つ前記複数のＶＭ間のコネクタによってリンクされて通信を転送する個別のインスタンスを有するバスモジュールを含み、前記コネクタは前記通信をルーティングする、請求項４に記載のコンピューティングシステム。

【請求項7】

前記複数のＶＭのユーティリティＶＭ内で実行し、且つ、イベントに加入しているコンポーネントからトピックに関するイベントを動的に登録して、前記通信プレーン上で通信を提供するためのアーキテクチャを提供するイベントモジュールを更に備え、
前記イベントモジュールは、イベントを定義する構成可能なパラメータに従ってイベントを登録し、
前記マイクロサービスは、前記マイクロサービスの個別に定義された機能に従って、複数のイベントのうちのいずれのイベントを受信するかを個別に定義する、請求項６に記載のコンピューティングシステム。

【請求項8】

前記イベントは、前記車両から分離されたグローバルクラウドベースのコンポーネント、前記車両内のコンポーネント、及び、前記複数のＶＭのうちの１つのうちのローカルなコンポーネントを含むグループから定義される、請求項７に記載のコンピューティングシステム。

【請求項9】

前記システム処理部は、前記複数のＶＭを制御し且つ前記システム処理部へのアクセス及び前記車両の追加のリソースを調停するＶＭマネージャを実行し、前記マイクロサービスは、インフォテインメントＶＭ、ユーティリティＶＭ及び安全オペレーティングシステムＶＭを含む前記通信プレーンと統合する独立したアプリケーションであり、
前記複数のＶＭは、タイミング制約で機能するリアルタイムオペレーティングシステム、機能安全規格に従って認定された安全オペレーティングシステム、及び、高性能オペレーティングシステムを含む個別のオペレーティングシステムを実行する、請求項１に記載のコンピューティングシステム。

【請求項10】

グループに応じて信号を配置し且つ信号を宣言と関連付ける前記車両内の信号の階層的なマッピングである車両信号モデル（ＶＳＭ）を含む信号モジュールを更に有し、
前記信号モジュールは、信号をどのように処理するかを示す前記宣言を実行するロジックを実装する、請求項１に記載のコンピューティングシステム。

【請求項11】

前記信号モジュールは、前記ＶＳＭモデルに従って、前記グループの識別された信号に関連する１つ以上の前記宣言のパラメータを定義するＶＳＭフィルタを取得し、前記パラメータは、前記識別された信号を処理するための少なくとも１つの機能への変更を特定し、
前記少なくとも１つの機能は、前記信号モジュールが前記機能を実行する時を特定するポリシーを含む、請求項１０に記載のコンピューティングシステム。

【請求項12】

外部定義されたルールに従ってイベントを動的に定義するルールエンジンを更に備え、
前記外部定義されたルールは、少なくとも１つの前記マイクロサービスを実行するための少なくとも１つの条件を特定して、少なくとも１つの前記マイクロサービスがどのように機能するかの動作を変更する、請求項１に記載のコンピューティングシステム。

【請求項13】

前記外部定義されたルールは、前記動作を変更することによって少なくとも１つの前記マイクロサービスの構成を更新する、請求項１２に記載のコンピューティングシステム。

【請求項14】

前記複数のＶＭと、メトリックパイプライン、ブロブパイプライン及びロギングパイプラインを含むデータパイプラインとの間のアクセスを仲介するストレージモジュールを備え、
前記ストレージモジュールは、前記データパイプラインにアクセスするためのポートを提供する複数の個別の前記マイクロサービスを含み、前記ストレージモジュールは、前記データパイプラインをトピックレジストリに登録する、請求項１に記載のコンピューティングシステム。

【請求項15】

前記メトリックパイプラインは、時刻に従ってデータをインデックスするメトリックデータストアにデータを提供し、前記ブロブパイプラインは、バルクデータを記憶するブロブデータストアにデータを提供し、前記メトリックデータストアは、前記バルクデータに関連するメタデータ及びポインタを記憶し、前記ストレージモジュールは、前記ロギングパイプラインを介して、ログデータを前記メトリックデータストアに記憶する、請求項１４に記載のコンピューティングシステム。

【請求項16】

クラウドベースのリソースからトレース要求を受信するトレースコレクタを備え、
前記トレースコレクタは、前記トレース要求において定義されるパラメータに従って前記コンピューティングシステムのログデータストア内のデータを収集することによって、前記車両においてオフラインで前記トレース要求を実行する、請求項１に記載のコンピューティングシステム。

【請求項17】

前記トレースコレクタは、前記トレース要求において定義されたメッセージを追跡するために、前記車両内の前記マイクロサービスにおいて追跡を開始し、前記トレースコレクタは、ネットワークが利用可能である時、前記トレース要求のために収集されたデータを前記クラウドベースのリソースにオフロードする、請求項１６に記載のコンピューティングシステム。

【請求項18】

複数の仮想マシン（ＶＭ）を実行して車両の異なるサービスを分離するシステム処理部と、
前記車両のレガシーコンポーネントであるソフトウェアコンポーネントを実行する第２の処理部と、
前記複数のＶＭ及び前記ソフトウェアコンポーネント間にまたがって前記複数のＶＭ並びに前記車両のメカトロニクス層及びセンサ層を横切る通信を提供する通信プレーンと、
を備え、
前記複数のＶＭは、プログラムされた機能とは独立して自己完結して標準化され、且つ、前記通信プレーン及び前記複数のＶＭと相互動作するように形成されたマイクロサービスを実行することによって、前記異なるサービスを提供する、コンピューティングシステム。

【請求項19】

前記通信プレーンは、前記メカトロニクス層及び前記センサ層のパラメータを制御し且つ前記メカトロニクス層及び前記センサ層からデータを取得するために、前記メカトロニクス層と、前記センサ層と、前記複数のＶＭとの間の通信を提供し、
前記メカトロニクス層は、前記車両内のアクチュエータを制御する電子制御ユニット（ＥＣＵ）を含み、前記センサ層は、前記車両の電子センサを含む、請求項１８に記載のコンピューティングシステム。

【請求項20】

複数の仮想マシン（ＶＭ）を実行して車両の異なるサービスを分離するシステム処理部と、
前記システム処理部上で実行され、前記複数のＶＭを制御し且つ前記システム処理部へのアクセス及び前記車両の追加のリソースを調停するＶＭマネージャと、
前記車両のレガシーコンポーネントであるソフトウェアコンポーネントを実行する第２の処理部と、
前記複数のＶＭ及び前記ソフトウェアコンポーネント間にまたがって前記複数のＶＭ並びに前記車両のメカトロニクス層及びセンサ層を横切る通信を提供する通信プレーンと、
前記複数のＶＭのうちの一つで実行され、グループに応じて信号を配置し且つ信号を宣言と関連付ける前記車両内の信号の階層的なマッピングである車両信号モデル（ＶＳＭ）を含む信号モジュールであって、信号をどのように処理するかを示す前記宣言を実行するロジックを実装する信号モジュールと、
を備え、
前記複数のＶＭは、プログラムされた機能とは独立して自己完結して標準化され、且つ、前記通信プレーン及び前記複数のＶＭと相互動作するように形成されたマイクロサービスを実行することによって、前記異なるサービスを提供し、
前記マイクロサービスは、前記通信プレーンと統合する独立したアプリケーションである、コンピューティングシステム。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本願は、２０２１年３月１２日に出願された米国仮出願第６３／１６０，６４５号の利益を主張し、その全体が参照により本明細書に組み込まれる。

【0002】

本明細書で説明する主題は、一般に、車両内のサービス指向データアーキテクチャのためのシステム及び方法に関し、より詳細には、動的且つロバストな車両コンピューティング環境を提供するためのマイクロサービスＡＰＩを活用するロバストなアプローチ及び複数の組み込みサービスを有するロバストな通信プレーンを提供する固有のアーキテクチャに関する。

【背景技術】

【0003】

車両内の技術は、多くの独特の困難を呈する。例えば、車両システムは、移動プラットフォームにおいて高レベルの安全性を保持しながら、変化する条件に対してロバストでなければならない。したがって、各種自動車のアーキテクチャ設計は、概して、アーキテクチャ内で水平方向に個別の要素を実装し、したがって、概して、リソースの協調および垂直統合の単純さからの効率を実現しない。すなわち、いくつかの従来のアーキテクチャは、機能が追加の電子制御ユニット（ＥＣＵ）のプロビジョニングを通して水平に追加される単一層（すなわち、メカトロニクス）を含む。それぞれの個別のＥＣＵは、異なる専有システムを実行することができ、ＥＣＵ間の任意の通信は、静的プログラミングを伴う初歩的なものである。この柔軟性に欠ける構造は、任意の変更を行うために個々のＥＣＵを更新することに依存する。しかしながら、ＥＣＵの更新は、一般にディーラまたは他のサービス場所へのサービスへの訪問を伴う複雑なタスクである。このアプローチは、ある感覚では堅牢であるが、柔軟性に欠ける傾向がある。したがって、追加の複雑な機能性が車両（例えば、自動運転機能、高度なインフォテインメントなど）と統合されており、そのような機能性の利点または頻繁な更新さえも必要とする時代において、従来のフレームワークは、全体的な機能性を著しく複雑にすることが判明し得る。

【発明の概要】

【0004】

一実施形態では、車両の電子システムを制御するためのコンピューティングシステムが開示される。コンピューティングシステムは、複数の仮想マシン（ＶＭ）を実行して車両の異なるサービスを分離するシステム処理部を有する。コンピューティングシステムは、複数のＶＭ間にまたがって複数のＶＭ並びに車両のメカトロニクス層及びセンサ層を横切る通信を提供する。複数のＶＭは、プログラムされた機能とは独立して自己完結して標準化され、且つ、通信プレーン及び複数のＶＭと相互動作するように形成されたマイクロサービスを実行することによって、異なるサービスを提供する。

【0005】

一実施形態では、コンピューティングシステムは、複数の仮想マシン（ＶＭ）を実行して車両の異なるサービスを分離するシステム処理部を有する。コンピューティングシステムは、また、車両のレガシーコンポーネントであるソフトウェアコンポーネントを実行する第２の処理部を有する。コンピューティングシステムは、複数のＶＭ及びソフトウェアコンポーネント間にまたがって複数のＶＭ並びに車両のメカトロニクス層及びセンサ層を横切る通信を提供する通信プレーンを有する。複数のＶＭは、プログラムされた機能とは独立して自己完結して標準化され、且つ、通信プレーン及び複数のＶＭと相互動作するように形成されたマイクロサービスを実行することによって、異なるサービスを提供する。

【0006】

一実施形態では、コンピューティングシステムは、複数の仮想マシン（ＶＭ）を実行して車両の異なるサービスを分離するシステム処理部を有する。コンピューティングシステムは、システム処理部上で実行され、複数のＶＭを制御し且つシステム処理部へのアクセス及び車両の追加のリソースを調停するＶＭマネージャと、車両のレガシーコンポーネントであるソフトウェアコンポーネントを実行する第２の処理部とを有する。コンピューティングシステムは、複数のＶＭ及びソフトウェアコンポーネント間にまたがって複数のＶＭ並びに車両のメカトロニクス層及びセンサ層を横切る通信を提供する通信プレーンを有する。複数のＶＭは、プログラムされた機能とは独立して自己完結して標準化され、且つ、通信プレーン及び複数のＶＭと相互動作するように形成されたマイクロサービスを実行することによって、異なるサービスを提供する。マイクロサービスは、通信プレーンと統合する独立したアプリケーションである。コンピューティングシステムは、複数のＶＭのうちの一つで実行され、グループに応じて信号を配置し且つ信号を宣言と関連付ける車両内の信号の階層的なマッピングである車両信号モデル（ＶＳＭ）を含む信号モジュールを有する。信号モジュールは、信号をどのように処理するかを示す宣言を実行するロジックを実装する。

【0007】

添付の図面は、本明細書に組み込まれその一部を構成し、本開示の様々なシステム、方法、および他の実施形態を示す。図中の図示された要素境界（例えば、ボックス、ボックスのグループ、または他の形状）は、境界の一実施形態を表すことが理解されよう。いくつかの実施形態では、１つの要素が複数の要素として設計されてもよく、または複数の要素が１つの要素として設計されてもよい。いくつかの実施形態では、他の要素の内部構成として示される要素は、外部構成として実装されてもよい、逆もまた同様である。さらに、要素は、一定の縮尺通りに描かれていない場合がある。

【図面の簡単な説明】

【0008】

【図1】図１は、車両内のコンピューティングシステムおよび車両から離れていてもよい関連システムの一実施形態を示す。

【図2】図２は、図１のコンピューティングシステムの一実施形態を詳細図で示す。

【図3】図３は、メカトロニクス層と通信するためのアーキテクチャの一構成を示す。

【図4】図４は、メカトロニクス層と通信するためのアーキテクチャの他の配置を示す。

【図5】図５は、仮想マシン間のサービス間通信のためのアーキテクチャを示す。

【図6】図６は、アプリケーションおよびトピック登録および発見のための構成を示す。

【図7】図７は、通信プレーンのバスモジュールの一構成を示す図である。

【図8】図８は、車両信号モデル（ＶＳＭ）の一例の図を示している。

【図9】図９は、ＶＳＭの使用の一例を示す。

【図10】図１０は、マイクロサービス構成の一例を示す図である。

【図11】図１１は、車両とクラウドとの間のトレーシング処理を示す図である。

【発明を実施するための形態】

【0009】

車両内のサービス指向データアーキテクチャに関連するシステム、方法、および他の実施形態が開示される。前述のように、多くの車両アーキテクチャは、モノリシック用途に依存する水平アーキテクチャの柔軟性に欠ける形態、および各個別のＥＣＵに関連する特定のプログラムのために、適応する能力が限られている。一般に、このアプローチは、アーキテクチャ自体の形態の様々な制約に起因して、車両の態様を動的に構成し且つより強力なシステム全体の機能を構築する能力を制限する。

【0010】

したがって、一構成では、仮想マシンマネージャ（たとえば、ハイパーバイザ）によって管理される複数の仮想マシンを実行する中央計算ハードウェアノードを使用して、レガシーツールおよびアプリケーションとの統合を提供する一方で、様々な既存の車両システムの上にロバストで適応可能なアーキテクチャを提供する、車両のための統合サービス指向データアーキテクチャが開示される。例えば、１つのアプローチでは、開示されたコンピューティングシステムは、Ｑｕａｌｃｏｍｍ（登録商標）Ｓｎａｐｄｒａｇｏｎ（登録商標）ベースのプロセッサなどのシステムオンチップ（ＳｏＣ）の上で動作するが、各種メカトロニックＥＣＵ、センサ、車両のマイクロコントローラユニット（ＭＣＵ）などと共存する。いずれの場合も、コンピューティングシステムは、ロバストな通信プレーンを使用することによって、既存の態様全体にわたって統合される。一般に、コンピューティングシステム内での仮想マシンの使用は、モノリシック設計を回避し、代わりに、それらの構成要素に対する修正のみで個々の構成要素を適応させ、構成することを提供し、それによって、より柔軟な改善されたアプローチを提供する。

【0011】

さらに、個別の仮想マシンの使用は、機能的安全性に関連するサービス／アプリケーションの分離、および個別のＥＣＵと静的に統合されることとは対照的に、コンピューティングシステムのＶＭへの機能の将来の開発および移行に適応するためのロバストな能力など、さらなる利点を提供する。さらに、通信プレーンは、システムの上述の構成可能性および全体効率を容易にするために、メカトロニクス層およびセンサ層のような異なる層間の直接通信のためのロバストで効率的なメカニズムを、仮想マシンとともに個別のサービス間にも提供する。このようにして、開示されたコンピューティングシステムは、車両のデータアーキテクチャをより柔軟に改善する。

【0012】

図１を参照すると、車両１００を含むコンピューティング環境の一例が示されている。本明細書で使用される場合、「車両」は、任意の形態の動力輸送である。１つ以上の実装形態では、車両１００は自動車である。本明細書において、構成は自動車に関して説明されるが、実施形態は自動車に限定されないことが理解されるであろう。いくつかの実装形態では、車両１００は、たとえば、同様の要件を有する構成要素の同様の構成を含み、したがって、本明細書で説明する要素の機能／構成から利益を受ける任意のロボットデバイスであり得る。

【0013】

いずれの場合も、車両１００は、様々な要素も含む。様々な態様において、車両１００が本明細書に記載される要素のすべてを有する必要はないことが理解されるであろう。車両１００は、後続の図に示されるように、様々な要素の任意の組み合わせを有することができる。さらに、車両１００は、追加の要素を有することができる。いくつかの構成では、車両１００は、要素のうちの１つまたは複数が実装されないだろう。車両１００の可能な要素のいくつかを図１～図２に沿って説明するが、追加の態様を後続の図に沿って説明する。しかしながら、多くの要素の説明は、この説明を簡潔にするために、図２～図１１の議論の後に提供される。さらに、説明を簡単かつ明瞭にするために、適切な場合には、対応する要素または類似の要素を示すために、異なる図の間で参照番号が繰り返されていることが理解されよう。加えて、説明は、本明細書に記載される実施形態の深い理解を提供するために、多数の具体的な詳細を概説する。しかしながら、当業者は、本明細書に記載される実施形態がこれらの要素の様々な組み合わせを使用して実施され得ることを理解するであろう。

【0014】

いずれの場合も、車両１００は、本明細書で説明するように、サービス指向アーキテクチャを形成する態様を含むコンピューティングシステム１１０を含む。様々な実装において、コンピューティングシステム１１０は、異なるサービス／アプリケーションを個別に実装する様々な仮想マシンを実行するシステムプロセッサ（例えば、ＳｏＣ）を含む。さらに、コンピューティングシステムは、仮想マシンおよび他のコンポーネントとともに、本明細書で説明する機能を容易にする通信プレーンおよび様々なＡＰＩを実装する。車両１００内で実施される態様に加えて、コンピューティング環境全体は、エッジ１２０およびクラウド１３０も含む。本明細書で説明するように、エッジ１２０およびクラウド１３０は、コンピューティング環境全体の追加のリモート態様として選択的に含まれ得る。上述の通信プレーンは、追加の機能を容易にするために、クラウド１３０および／またはエッジ１２０などの分散／リモート態様に拡張することができる。

【0015】

一般に、エッジ１２０は、車両１００に対してローカルに配置された、路側ユニット（ＲＳＵ）、マイクロデータセンタ、および同様の構成要素のデバイスおよび関連するソフトウェアを包含する。すなわち、エッジ１２０は、ローカル環境内で車両１００と通信しているデバイスを表し、マシン認識、プランニングなどの様々なワークロードをオフロードするタスクを実行するように機能することができる。クラウド１３０は、少なくとも１つの配置において、共有通信プレーンを介して車両１００のコンピューティングシステム１１０と共に機能するアプリケーション／サービスを有するクラウドベースのコンピューティングリソースを含む。クラウド１３０自体は、無線通信チャネルを介してアクセスされるリモートリソースである。クラウド１３０は、機能を提供するために共に機能する単一のデバイスまたは複数の個別のリソースを備え得る。いずれにせよ、クラウド１３０は、共有通信プレーン及び相互動作性を容易にする関連するＡＰＩを介して、コンピューティングシステム１１０と統合される。記載された要素および機能は、図面のさらなる議論によってより明らかになるであろう。

【0016】

図２を参照すると、コンピューティングシステム１１０の一実施形態がさらに示されている。コンピューティングシステム１１０は、システムプロセッサ２００を含むものとして示される。したがって、システムプロセッサ２００は、コンピューティングシステム１１０の一部であってもよく、あるいは、コンピューティングシステム１１０は、データバスまたは別の通信経路を介して、システムプロセッサ２００にアクセスしてもよい。１つ以上の実施形態では、システムプロセッサ２００は、様々な機能を実装するように構成された特定用途向け集積回路（ＡＳＩＣ）である。一般に、システムプロセッサ２００は、本明細書に記載するように、種々の機能を実行することができるシステムオンチップ（ＳｏＣ）またはマイクロプロセッサなどの電子プロセッサである。一実施形態では、システムプロセッサ２００は、本明細書に記載する態様を支持して機能し得る種々のモジュールを記憶するメモリを含むか、またはそれにアクセスする。メモリは、ランダアクセスメモリ（RAM）、リードオンリーメモリ（ROM）、ハードディスクドライブ、フラッシュメモリ、上述したメモリの組み合わせ、または記載の機能をサポートする他の適切なメモリであってもよい。本明細書に記載するモジュールは、様々な構成において、システムプロセッサ２００によって実行されるとき、システムプロセッサ２００に本明細書に開示する様々な機能を実行させる、コンピュータ読み取り可能命令である。さらなる構成では、モジュールは、その中に組み込まれた命令を含む、言及された機能を実行するための論理、集積回路、または別のデバイスを含む。

【0017】

さらに、一実施形態では、コンピューティングシステム１１０は、車両のマイクロコントローラユニット（ＭＣＵ）または別の電子プロセッサであり得る第２のプロセッサ２０５を含む。一般に、プロセッサ２０５は、システムプロセッサ２００と並列に動作するレガシーデバイスである。さらに、直接の接続が示されていないが、システムプロセッサ２００と第２のプロセッサ２０５との間には、１つ以上のアプローチで、特定のソフトウェアプロトコルとの物理層接続（例えば、イーサネット）で構成される通信プレーンのような様々な通信経路が存在し得る。これについては、後でさらに詳細に説明する。いずれの場合も、第２のプロセッサ２０５は、様々なソフトウェアコンポーネント２１０を実行する。ソフトウェアコンポーネント２１０は、１つの構成では、車両１００における異なる機能を提供するために、第２のプロセッサ２０５が実行のためにコンパイルする個別のバイナリおよびコードの部分であり、これは、レガシー機能（たとえば、オンボード診断、エンジン管理など）であり得る、。さらに、ソフトウェアコンポーネントは、１つのアプローチでは、コンピュータシステム１１０内の通信を容易にするために、上述のように通信プレーンをさらに統合することができる。

【0018】

図２について続けると、システムプロセッサ２００は、個別の仮想マシンインスタンス２２０、２２５、２３０、および２３５を制御する仮想マシン（ＶＭ）マネージャ２１５を実行する。ＶＭマネージャは、１つ以上の構成において、ハイパーバイザ（仮想マシンモニタ（ＶＭＭ）とも呼ばれる）であり、これは、システムプロセッサ２００へのアクセスを仲介することによって仮想化された環境を提供することによって、ＶＭ２２０～２３５の実行を管理するように機能する。このように、ＶＭマネージャ２１５は、分離されたオペレーティングシステムインスタンスの実行のための分離された環境を提供する。図示のように、ＶＭ２２０～２３５は、個別のオペレーティングシステム２４０ａ、２４０ｂ、２４０ｃ、および２４０ｄを実行する。一般的な前提として、個別のＶＭおよび関連するオペレーティングシステムは、車両１００のより広いコンピューティング環境内の異なる目標および安全要件に焦点を当てる。オペレーティングシステム２４０ａ～２４０ｄは、リアルタイムオペレーティングシステムを含む様々な異なるオペレーティングシステムを含むことができる。

【0019】

一つの構成では、ＯＳ２４０ａは、例えばＬｉｎｕｘ（登録商標）ベースのオペレーティングシステムである。関連するユーティリティＶＭ２２５は、１つのアプローチで、各種安全性が重要でないアプリケーション／サービスを実行するための機能であり、これは、データオーケストレーション、管理機能、データストレージ、イベント／サービスディスカバリ（発見）など、サービス指向アーキテクチャ全体を支持して、異なる機能を含むことができる。一般的な前提として、ＶＭ２２５は、本明細書で説明する管理および一般的なサービスの多くが、ユーティリティモジュール２６０によって表されるように動作し得る、分離された実行環境を提供し、ユーティリティジュール２６０は、説明の目的のために個別のコンポーネントとして示されるが、概して、後で説明するように、複数の個別のマイクロサービスから形成される。

【0020】

インフォテインメントＶＭ２３０に関連付けられたＯＳ２４０ｂは、一実施形態では、車両内のインフォテインメント（例えば、ラジオ、ナビゲーション、ＨＶＡＣ制御部など）態様を制御するように機能するＡｎｄｒｏｉｄ（登録商標）ベースのオペレーティングシステムである。ＯＳ２４０ｂ及びＶＭ２３０は、さらに、インフォテインメントのタッチスクリーンディスプレイなど、車両１００内のヒューマンマシンインタフェース（ＨＭＩ）要素を制御するよう機能することができる。安全ＯＳＶＭ２２０内で実行するＯＳ２４０ｃは、一構成では、例えば、機能安全規格に従った安全認定されたオペレーティングシステム（例えば、Ｕｎｉｘ（登録商標）ベース）である。安全ＯＳＶＭ２２０は、自動制御システム（たとえば、ＡＤＡＳ、自律制御など）などの安全上重要なアプリケーションを実行することができる。図２は、追加のアプリケーション２４５を実行する追加のＶＭ２３５をさらに示す。追加のＶＭ２３５は、上述のコア仮想マシン２２０～２３０に加えて、例示的な仮想マシンとして示されている。すなわち、ＶＭマネージャ２１５は、様々な構成において、図示される仮想マシンと、本明細書で明示的に列挙されるものとは異なる／追加の機能に関連付けられ得る追加の仮想マシンとを含む、複数の仮想マシンを実行することができる。

【0021】

一例として、追加のＶＭ２３５は、自動化された制御部（例えば、自動運転スタック）、車両内の異なる構成コンポーネント（例えば、メカトロニクス層２６５）間のアクセスの調停等に専用であってもよい。もちろん、さらなるアプローチでは、自動運転（例えば、ＡＤＡＳ、自律的計画、認知、および制御）は、ＶＭ２２０および２２５などの仮想マシンのうちの１つ以上内にソフトウェアスタックを含み得る。いずれの場合も、さらなる例として、追加のＶＭ２３５は、ＶＭマネージャ２１５内の抽象化層を介してＶＭ２２０～２３０にセンサデータを通信することに関連する機能を提供することができる。すなわち、例えば、追加のＶＭ２３５は、センサデータをアプリケーションにより効率的に誘導するために、ＶＭ２２０～２３０内のセンサとアプリケーションとの間の中間翻訳層として機能するセンサパブリッシャを実行することができる。

【0022】

さらに、ＶＭマネージャ２１５は、システムプロセッサ２００と相互作用する管理エンティティとして示されているが、さらなる態様では、システムプロセッサ２００は、例えば、安全性が重要なアプリケーションなどの様々なアプリケーションを実装するＶＭマネージャ２１５とは独立した個別のオペレーティングシステムをネイティブに実行する。いずれにせよ、システムプロセッサ２００上での実行は、ＶＭマネージャ２１５及び関連する仮想マシンに限定されるものではなく、むしろ他のオペレーティングシステムの追加インスタンスをサポートすることができる。さらに、ＶＭマネージャ２１５の外部の個別のオペレーティングシステムは、コンピューティングシステム１１０の全体的なフレームワークとの統合をサポートするために、通信プレーン（たとえば、コーン２５０）のインスタンスをさらに実装し得る。

【0023】

通信プレーン（communication plane）

【0024】

図２に示すように、コーン２５０は、コンピューティングシステム１１０の通信プレーンを形成する複数の個別のインスタンス２５０ａ、２５０ｂ、２５０ｃ、および２５０ｄとして示されている。コーン（corn）２５０は、サービス指向アーキテクチャの様々なコンポーネント間のシームレスな通信を提供する。例えば、コーン２５０は、複数のＶＭ２２０～２３５とメカトロニクスＥＣＵ２６５（本明細書ではメカトロニクス層とも呼ばれる）とセンサ２７０（本明細書ではセンサ層とも呼ばれる）との間の通信を仲介する。さらなる態様では、コーン２５０はまた、コンピューティングシステム１１０内の異なるサービス／アプリケーション間、およびコンピューティングシステム１１０と、クラウド１３０およびエッジ１２０などのリモートコンポーネントとの間の通信を仲介する。

【0025】

一構成では、コンピューティングシステム１１０は、コーン２５０の機能をデータプレーン（data plane）および制御プレーン（control plane）にセグメント化し、これらのプレーンは、伝達されるデータのタイプを容易にするために、個別の特有の設計要素とともに構成される。したがって、言及された要素の特定の実装形態に応じて、特定の構成要素が変わり得ることを了解されたい。例えば、１つのアプローチでは、制御プレーンは、メカトロニクスＥＣＵ２６５とコンピューティングシステム１１０との間のコントローラエリアネットワーク（ＣＡＮ）－イーサネット（登録商標）ゲートウェイから構成される。ゲートウェイは、コンピューティングシステム１１０とメカトロニクスＥＣＵ２６５との間の分離を提供すると共に、ＣＡＮとイーサネット（登録商標）間を単一のコンピューティングデバイスに変換するハードウェア機能を統合する。さらに、１つの態様では、ゲートウェイは、マルチキャスト（送信）通信とユニキャスト（受信）通信を使用してイーサネット（登録商標）経由でデータを転送するために、自動車通信プロトコルである適応型ＡＵＴＯＳＡＲ（登録商標）プロトコルを使用する。したがって、ＶＭマネージャ２１５のＶＭは、通信を送信／受信し、変換するための個別の適応型ＡＵＴＯＳＡＲ（登録商標）ベースモジュール（図示せず）を含むことができる。図３に示すように、メカトロニクスＥＣＵ２６５は、ＶＭマネージャ２１５を介してＶＭと通信するゲートウェイ３００にＣＡＮデータを提供する。

【0026】

ＶＭは、ゲートウェイ３００からのデータを受け入れるための異なるアプローチを実装し得る。たとえば、１つのアプローチでは、ＶＭは、アプリケーション／サービスに直接、または特定のアプリケーションプログラミングインターフェイス（ＡＰＩ）を介して通信を提供する適応型ＡＵＴＯＳＡＲ（登録商標）ベースモジュールを実装する。あるいは、ＶＭは、適応型ＡＵＴＯＳＡＲ（登録商標）ベースモジュールとの間の通信を変換するマイクロサービス（例えば、パブリッシャ２７５）を実装することができる。パブリッシャ２７５は、データパイプ３１０に提供されるメトリックデータ、およびメカトロニクスＥＣＵ２６５に接続されたＣＡＮバスに公開されたデータのトレーサビリティ情報などの情報をさらに取得することができる。代替アプローチが、図４に示される。図４には、ソケット４００とＶＭマネージャ２１５との統合を示すアプローチを示す。この構成では、ゲートウェイ３００は取り外され、メカトロニクスＥＣＵ２６５は、ソケット４００を介してＶＭマネージャ２１５と直接通信し、ＣＡＮデータ経路を合理化する。一般に、ＶＭマネージャは、ソケットＣＡＮ４００を実装するので、ＣＡＮ接続は、イーサネット（登録商標）に切り替える代わりに、コンピューティングシステム１１０と直接接続される。このようにして、代替アプローチは、ゲートウェイの機能性をＶＭマネージャ２１５に移動し、ファームウェアから離れることによって待ち時間を改善する。したがって、パブリッシャ２７５によってＣＡＮバスをネイティブにサンプリングすることは、処理における層として適応型ＡＵＴＯＳＡＲ（登録商標）ベースモジュールを除去することによって、改善された待ち時間を提供する。

【0027】

コーン２５０のデータプレーンを介したセンサ２７０からのデータの取り込みに関して、センサ２７０は、一般に、かなりの量のデータを生成し、これは、データの個別の送信および記憶を低減することによって効率的に取り扱われるべきであることを理解されたい。したがって、物理層は、例えば、レーダ／ＬｉＤＡＲおよびカメラをそれぞれ含むセンサに使用され得るイーサネット（登録商標）および低電圧差動信号（ＬＶＤＳ）を含む、インタフェースの組み合わせを含み得る。コンピューティングシステム１１０は、一実施形態では、ＶＭマネージャ２１５内のセンシング抽象化層と一緒に、またはそれぞれの仮想マシン内で別々に埋め込まれたパブリッシャマイクロサービスとして、コーン２５０を実装する。すなわち、１つのアプローチでは、コーン２５０のデータプレーンは、抽象化層に沿って、または別々にＶＭにパブリッシングマイクロサービスを挿入して、適応型ＡＵＴＯＳＡＲ（登録商標）ベースモジュールなどの追加の処理層を介してホップを除去する。これは、データ処理を低減し、それによって待ち時間を改善する。

【0028】

サービス間通信に関しては、例示的な例として、コーン２５０（黒い実線として示されている）および適応型ＡＵＴＯＳＡＲ（登録商標）（鎖線によって示されている）を介して相互接続された３つの個別のＶＭを示す図５を考える。一般に、コーン２５０は、データプレーンと制御プレーンの両方にまたがるサービス間通信を提供する。後でより詳細に説明するように、データプレーンは、一実施形態では、ブローカフリー（broker free）であるピアツーピア（Ｐ２Ｐ）アプローチを実装し、一方、制御プレーンは、ブローカフレームワーク（brokered framework）を実装する。従って、コーン２５０は、アプリレジストリ５００およびトピックレジストリ５１０を介してサービスおよびアプリケーションのディスカバリを提供し、これらはユーティリティモジュール２６０内の個別のマイクロサービスであってもよい。いずれの場合も、制御プレーンはイベントバスサービスを実装し、データプレーンはトピックレジストリ５１０を利用する。アプリレジストリ５００およびトピックレジストリ５１０は、提供するコンテナ（container）およびＶＭ上にサービスポートをマップして、サービス間の通信を提供する。さらに、示されるように、適応ＡＵＴＯＳＡＲ（登録商標）モジュール５２０ａおよび５２０ｂは、レガシーサービスが通信プレーンと並んでどのように共存できるかを表す。

【0029】

コーン２５０の別々のセグメントに関するさらなる詳細として、データプレーンは、サービス、アプリケーション、およびワークロード間を流れるデータのための通信層を表す。データプレーンによって処理されるデータは、一般に、センサパブリッシュまたはサービスからのデータ（たとえば、ＣＡＮデータ、カメラフレーム、注釈情報）と、アクチュエータまたはサービスへのデータ（たとえば、ドライブバイワイヤ制御メッセージ）とを含む。１つの配置では、データプレーンは、サービスとアプリケーションが接続を確立することを許可するＰ２Ｐネットワークであり、管理されていないか、中央には仲介されない。データプレーンのためのこのフレームワークは、追加のホップ（hop）を排除することによって低い待ち時間を提供し、個々のサービスに対する障害を分離する回復力のあるフレームワークを提供する。したがって、データプレーンは、トピックの使用を通してサービス間に専用チャネルを作成することを提供し、それによって、トラフィックを特定の機能に隔離し、低い待ち時間およびトピック固有の通信パラメータ（たとえば、サービス品質）を容易にする。

【0030】

１つの例として、データプレーンは、特定のサービスのプライマリデータ、健全性、および障害ステータスに対して個別のチャネルを確立して、個別のトラフィックを分離し、適切な通信を確保できる。さらに、１つ以上の構成では、データプレーンの形成は、データプレーンプロトコルを不可知にするために、トランスポート層の上部に抽象化されたプロトコルを含み、その結果、下にあるトランスポート層は、データプレーン自体の実装に影響を及ぼすことなく、他の技術のためにスワップされ得る。各種トランスポート層技術は、たとえば、ＺＭＱ（登録商標）、データ配信サービス（ＤＤＳ）などを含むことができる。

【0031】

図６は、サービス（例えば、マイクロサービス）をデータプレーンメッセージングと統合する一例を示す。メッセージングライブラリ６００ａ～ｄは、サービスの個別のインスタンスに含まれる単一ライブラリの個別の実装インスタンスであり、トピックレジストリ５１０およびアプリレジストリ５００と一緒に含まれ、コーン２５０のデータプレーン上での通信を容易にする。特に、トピックレジストリ５１０及びアプリレジストリ５００が、登録されたアプリ及びトピックの個別のインデックスを維持して、データサービス６１０及びデータサービス６２０のような個別のマイクロサービスがアプリ／トピックを発見し、それらの間の通信を開始することができるようにする一方で、ライブラリは、通信の形成を定義する。例えば、図６に示されるように、データサービス６１０および６２０は、アプリレジストリ５００内の対応するアプリケーションのディスカバリに従ってパイプラインとして機能する直接のＰ２Ｐ接続を確立する。このようにして、コンピューティングシステム１１０は、柔軟／構成可能な方法で、コンポーネント間の直接チャネルを促進する。

【0032】

コーン２５０をさらに参照すると、そこに含まれる制御プレーンは、サービス（例えば、個別のＶＭのマイクロサービス）を横断して通信するためのイベント駆動アーキテクチャである。特に、制御プレーンのイベント駆動アーキテクチャは、サービスを分離する。なぜなら、サービスは、イベントコンシューマとして、静的バインディングまたはＡＰＩのような、事前に定義された符号化を介して、イベントプロデューサについて知る必要がなく、またはそれと結合される必要がないからである。さらに、イベントプロデューサは、コンシューマがレジストリを介してプロデューサから切り離されるので、イベントコンシューマの特定の知識（例えば、アイデンティティ、数など）なしにさらに動作する。このように関係を形成することによって、コンピューティングシステム１１０は、独立して維持され、試験され、無線（ＯＴＡ）機構（すなわち、遠隔無線制御）を介して更新されるべきサービスを提供し、それによって、他のサービスへの影響を回避し、手動で更新される必要があり得る特定のコンシューマ／プロデューサ関係を追跡する。

【0033】

イベントバス

【0034】

したがって、一つのアプローチでは、制御プレーンは、図７に示されるように、コーン２５０内にバスモジュール７００を実装する。特に、様々な構成において、バスモジュール７００（コーン２５０の一部として構成される複数のインスタンス７００ａおよび７００ｂを含むものとして図７に示される）は、サービス間通信を容易にするためのパブリッシュサブスクライブ機能を提供する。バスモジュール７００は、実装に応じて異なる形態で実装することができる。例えば、バスモジュール７００は、複数のＶＭのための単一のバスの状況において、図７の安全ＯＳＶＭ２２０のバスモジュール７００ａならびにサービス７２０ａおよび７２０ｂに関して示されるような、他のＶＭにサービスを提供するために、コーン２５０上の外部にポートを露出する。バスモジュール７００の複数のインスタンスが発生するさらなる態様では、バスモジュール７００ａおよびバスモジュール７００ｂの個別のインスタンスなど、コンピューティングシステム１１０は、コネクタ７１０ａ、７１０ｂ、７１０ｃ、および７１０ｄを実装する。

【0035】

コネクタ７１０は、コンピューティングシステム１１０の個別の態様をリンクするブリッジ、および個別のバス７００ａと７００ｂとの間のルートメッセージまたは存在し得る追加のバスとして働く。このようにして、バスモジュール７００は、複数の異なるＶＭに拡張可能である。さらなる態様では、コネクタ７１０は、メッセージをイベントバス７００のための適切な形態に変換するために、サブスクライブメッセージを前方に送り、受信メッセージ上でプロトコル変換を行うこともできる。したがって、様々な態様では、コネクタ７１０は、コーン２５０上での通信を容易にするために、イベント、宛先、およびプロトコルを特定の宛先と関連付けるルーティングテーブルを実装する。

【0036】

さらに、コネクタ７１０は、少なくとも１つの実施形態では、イベントバス７００をクラウド１３０などのリモートリソースに接続するための追加の機能を含むことができる。
したがって、クラウド１３０は、ＶＭ間の通信とは異なるプロトコルを使用することができるが、コネクタ７００ｄは、基礎となるプロトコルをフォーマット間で変換することによって、ＶＭとクラウド１３０との間のアクセスを仲介することができる。

【0037】

図７に示されるものと同様に、イベントバス７００は、別々の処理部および別々のＶＭにまたがることができる。このような構成では、別々のコンピューティングノード間のメッセージがコネクタ７１０を介してルーティングされてもよい。しかしながら、同じプロセッサのＶＭマネージャ２１５内のメッセージは、単に、イベントバス７００の公開されたポートを使用してもよい。さらに別の例では、各個別のＶＭが個別のイベントバス７００を有することができる。このアプローチでは、ＶＭ内のメッセージはそれぞれのイベントバス７００によって処理され、一方、ＶＭ間メッセージはコネクタ７１０を介して処理され、単一のコネクタ（例えば、７１０ｄ）はクラウド１３０への接続を提供する。このように、別々のサービスが別々のＶＭまたは他の実行環境内に分離されているとしても、通信は、イベントバス７００および各サービスに対する特定の個別の構成なしに関連するコネクタを介してシームレスに提供される。

【0038】

さらに、個別のサービス（たとえば、サービス７２０ａ、ｂ、ｃ、ｄ、ｅ、およびｆ）は、説明のためだけに示されている。個別のＶＭは、異なる数のサービス／アプリケーションをインスタンス化することができ、概して、示されるような構成に限定されないことが理解されるべきである。本開示全体にわたって説明される個別のサービスは、一般に、マイクロサービスを指し、マイクロサービスは、後でより詳細に説明される。さらに、バスモジュール７００は、個別のコンポーネント間のメッセージを提供するものとして記述されているが、個別のサービスは、一般に、最初に、コーン２５０のフレームワーク内に個別のメッセージを確立するための登録およびディスカバリのプロセスを行う。トピックレジストリ５１０およびアプリレジストリ５００に関連して先に述べたように、ＶＭ内で実行される個別のマイクロサービスは、コンピューティングシステム１１０内でコーン２５０を使用して動作するために登録（registry）および加入（subscribe）する。登録およびディスカバリは、データプレーンおよび制御プレーンの両方に適用されることに留意されたい。

【0039】

したがって、あるアプローチでは、ユーティリティＶＭ２２５のユーティリティモジュール２６０は、アプリレジストリ５００及びトピックレジストリ５１０のサービスを別々に含むことができるイベントモジュールを実装する。トピックレジストリには、異なるサービスによってサービスされるポートのマニフェスト（manifest）が含まれる。したがって、サービスが開始されると、サービスは、他のサービスによってサービスされるポートを発見すると共に、関連するポートをトピックレジストリ５１０に通知（advertise）する。同様に、アプリレジストリ５００は、グループ（すなわち、コンテナまたはＶＭ）の間で実行されるサービスのマニフェストである。アプリレジストリ５００は、アプリレジストリ５００にデータを送信するサービスの状態情報を収集する。状態情報は、他のサービスへの要求に応じて利用可能であり、アプリレジストリ５００は、状態情報をデータストア２５５またはコンピューティングシステム１１０の別のデータ記憶装置にも格納する。あるアプローチでは、アプリレジストリ５００は、サービスがアプリレジストリ５００を発見できるようにトピックレジストリ５１０に提供される専用サーバーポートを有する。このようにして、コンピューティングシステム１１０は、サービスが、同様に登録されている他の任意のサービスを登録し、相互作用することを可能にする。当然ながら、様々なアプローチにおいて、イベントモジュールは、コンピューティングシステム１１０内のセキュリティおよび／または他の定義されたポリシーに従って、アクセスを調停することができる。さらに、サービスは、登録する必要がなく、そのような場合には、ディスカバリプロセスの外部での直接プログラミングを通じて生じ得る、通信当事者のためのポートの識別子が知られている限り、通信プレーン上での通信に依然として参加することができる。

【0040】

イベントモジュールへの登録の一部として、登録サービスは、１つ以上のアプローチにおいて、例えば、コーン２５０内のイベントメッセージを容易にするために、他のサービスが加入できるサービスに関連するイベントを定義する、設定可能なパラメータを登録することができることを理解されたい。さらに、サービスは、一般にコンピューティングシステム１１０の状況内で論じられるが、クラウド１３０およびエッジ１２０の一部であるサービスは、イベントモジュールのサービス／トピックに登録および加入して、コンピューティングシステム１１０を越えて（たとえば、クラウドおよびエッジアセットに）拡張可能なイベント駆動アーキテクチャを提供することもできる。

【0041】

車両信号モデル（ＶＳＭ）

【0042】

図８を見ると、車両信号モデル（ＶＳＭ）８００の一例が示されている。図示のように、ＶＳＭ８００は、車両１００内の信号８２０の階層的マッピングから構成されており、少なくとも１つのアプローチでは、ユーティリティモジュール２６０のマイクロサービスである信号モジュールとして具体化されている。ＶＳＭ８００は、信号８２０を、車両１００内の個別の論理区分／ソースを規定する個別のグループ８１０に配置する。ＶＳＭはさらに、個々の信号８２０を個別の宣言８３０に関連付ける。コンピューティングシステム１１０は、ＶＳＭ８００を活用して、信号８２０をフィルタリングし、優先順位付けし、管理する。個別のグループ８１０のそれぞれは、車両１００の特定の態様に関連する信号のセットを含む。示されるように、グループ分けは、信号８２０のソースに従う。しかしながら、グループ分けは、特定の実装に応じて変更することができる。いずれの場合も、グループ８１０は、信号８２０の同じセットを生成する同様／同様の構成の他の車両にわたって概して一貫している。

【0043】

さらに、信号８２０は、観測可能または能動的であり、信号８２０のそれぞれの個別の宣言８３０は、例えば、サービス処理、信号の記憶または送信に関連して、コンピューティングシステム１１０が信号をどのように処理するかについての論理を提供する。さらなる態様では、ＶＳＭ８００は、構成変更の検証およびデータフロー挙動のモデリングを提供することができるマスターＶＳＭ（すなわち、すべての信号のマスターリスト）から導出することができる。信号モジュールは、例えば、ユーティリティモジュール２６０内に具現化され得るＶＭ２２５のマイクロサービスであり、ＶＳＭフィルタを作成および／または受信するように機能する。ＶＳＭフィルタは、１つ以上の宣言のパラメータを定義する。特に、ＶＳＭフィルタは、信号モジュールによって実装される場合、特定の信号８２０を識別し、識別された信号の処理に関連して機能の実行を引き起こすように機能する。

【0044】

例えば、信号モジュールは、特定の条件（例えば、温度が満たされる）が発生したときにバッテリパラメータを記憶するような、選択的な条件に従って特定の信号を記憶するためのＶＳＭフィルタを実装することができる。追加の例として、車両のグループの初期構成と、特定のＶＳＭフィルタを車両のグループに分配した後の更新された構成とを示す図９を考える。図示のように、ＶＳＭフィルタは、バッテリデータの収集をＡＣＣ離脱データの収集に再構成し、車線変更データの収集を信号機検出データの収集に再構成し、非保護の左折データの収集を車線合流データの収集に再構成し、そして、車線混雑道路での運転に関するデータの収集を曇り／見通しのよくない状態での運転に関するデータの収集に再構成する。このようにして、信号モジュールは、車両１００の様々な信号がどのように処理されるかの再構成を可能にする。さらに、例示は信号データの収集に焦点を当てているが、他の機能もまた、ＶＳＭフィルタを介して信号８２０に適用されてもよいことを理解されたい。

【0045】

例えば、信号モジュールは、１以上のアプローチにおいて、車両１００からの信号を変換するためにＶＳＭ８００を使用する。１つの配置では、信号モジュールは、信号を取得し、別の形態に変換することによって（例えば、名称変更または他の変調を介して）、信号を変換する。すなわち、信号モデルは、ＶＳＭ８００によって識別された信号を取得し、次いで、宛先フィールドに従って異なる名前で信号を再送することができる。さらなる実施例として、信号モジュールは、１つの配置において、信号のアグリゲーション（aggregation）を実施するためにＶＳＭ８００を使用する。この点に関し、信号モジュールは、信号のどの反復（例えば、最も最新のもの、１つおきの反復など）を他のコンポーネントに渡すかを選択し、信号を平均化し（例えば、時間ウィンドウにわたる移動平均）、および信号の値として平均を供することによって、ＶＳＭ８００によって規定された信号を選択的に通過させる。ＶＳＭ８００の宣言は、このサンプリングを、信号が車両１００内でいかに異なるコンポーネントに通信されるかについての充填ストラテジ（fill strategy）として定義する。したがって、ＶＳＭ８００は、１つ以上の手法で、特定の信号を異なるコンポーネントに報告するための異なる充填ストラテジを定義することができる。さらに、ＶＳＭ８００は、信号の優先順位を定義して、信号の通信における優先順位、信号の記憶、信号の処理など、信号に関連する特定のアクションの即時性を決定する。一例として、強い制動イベントに対する信号（すなわち、ブレーキペダルからの全振幅ブレーキ信号）は、ＧＰＳセンサからのＧＰＳ座標よりも高い通信優先順位が与えられる。

【0046】

ルールエンジン（rule engine）

【0047】

コンピューティングシステム１１０のさらなる態様は、動作を適応的に構成する際のさらなる柔軟性を提供する。例えば、ユーティリティモジュール２６０と、ルールエンジンを定義する追加のマイクロサービスを考えてみよう。１つの配置では、ルールエンジンは、イベントを動的に定義するように機能する。たとえば、ルールエンジンは、コーン２５０を介してクラウド１３０または別の遠隔エンティティから通信される、外部定義ルールを取得することができる。もちろん、さらなる例では、ルールエンジンを介して実装されるルールは、コンピューティングシステム１１０においてローカルに導出され得る。いずれの場合も、外部定義されたルールは、少なくとも１つのマイクロサービスを実行する条件を指定して、少なくとも１つのマイクロサービスがどのように機能するかの動作を変更します。条件は、イベント、メッセージ、またはオブジェクト（たとえば、車両の状態、センサデータ、外部イベントメッセージなど）に関連付けられる特定のトリガを定義し得る。さらなる例として、ルールエンジンは、たとえば、高帯域幅接続が利用可能である場合、より低い帯域幅のセルラー接続と比較してより多くのデータがオフロードされるように、信号が利用可能帯域幅に従って優先順位付けされるように、無線通信の状態に関連する条件を定義し得る。どちらの条件が定義されていても、ルールは、条件をトリガすることに応答して実行する何らかの特定の機能（例えば、マイクロサービス）をさらに指定する。したがって、ルールエンジンは、特定のマイクロサービスが実行される時を調整することによって、マイクロサービスの動作を適応させるために使用され得る。ルールエンジンは、１つ以上のアプローチにおいて、データプレーンおよび制御プレーン上で動作して、個別のサービス自体とのいかなる特定の統合もなしに、留意されたイベントの基礎を形成するイベントおよび追加の情報を取得することができることを了解されたい。

【0048】

追加の注意として、サービス間においてコーン２５０上で通信されるイベントは、１つ以上のアプローチにおいて、イベントヘッダとアプリケーション固有のペイロードとで構成される。イベントヘッダは、イベント管理用の情報を取得し、一方、アプリケーション固有のペイロードは、個別のイベントタイプごとに異なり、ＪＳＯＮフォーマットで提供される場合がある。前述のように、サービスは、他のサービスが加入できるトピックレジストリ５１０にイベントを公開する。イベントモジュールは、新しいイベントの追加と、既存のイベントの削除／変更を提供する。これらのイベントは、特定のルールをいつ実行するかを決定するためのルールエンジンのトリガとして機能する。さらに、イベント自体は、グローバル（たとえば、クラウドベース）、ローカル、またはＶＭ固有とすることができ、コーン２５０は、これらのエンティティにわたってシームレスにイベントを提供するので、ルールの統合も独立しており、サービスの特定の変更を伴わない。したがって、ルールエンジンは、多くの異なる条件に従ってルールを定義することができる。一般に、ルールエンジンは、システム１１０内の動作を変更する広範囲のルールを定義することができ、これには、管理機能、記憶装置、車両制御、イベント生成などが含まれるが、これらに限定されない。

【0049】

データストレージ

【0050】

図２を新たに参照すると、ユーティリティモジュール２６０は、コンピューティングシステム１１０内のデータストレージおよび管理に関連する追加のマイクロサービスをさらに含むことができる。例えば、ユーティリティモジュール２６０は、ストレージモジュールであるマイクロサービスをさらに含んでもよい。ストレージモジュールは、複数のＶＭとデータパイプライン間のアクセスを仲介する。データパイプラインは、コンピューティングシステム１１０内に異なるタイプのデータを記憶するための複数の異なるアクセスポイントを含む。例えば、１つのアプローチでは、データパイプラインは、メトリックパイプライン（metrics pipeline）、ブロブパイプライン（Blob pipeline）、およびロギングパイプライン（logging pipeline）を含む。一般に、パイプラインは、ストレージモジュールのマイクロサービスに関連する露出したポートである。従って、パイプラインは、データストア（data store）２５５からデータを格納したり取り出したりするためのデータアクセス要求を処理する。従って、ストレージモジュールは、パイプラインをトピックレジストリ５１０に登録する。

【0051】

メトリクパイプラインは、１つの構成では、時間に応じてデータのインデックスを作成するメトリクデータストアにデータを提供する。メトリックデータ自体は、一般に、サービス状態、サービスディスカバリ、システムリソース監視、アクチュエータ制御メッセージ、ブロブデータのメタデータ、およびログデータに関する構造化データである。ブロブパイプラインは、ＬｉＤＡＲデータ、カメラ画像などを含むセンサデータなどのバルクデータを記憶するブロブデータストアにデータを提供する。メトリックデータは関連するメタデータとバルクデータへのポインタを格納し、ストレージモジュールはロギングパイプラインを介してログデータをメトリックデータストアに格納する。

【0052】

前述されたデータストアは、１つ以上のアプローチでは、データストア２５５の上に抽象化される。データストア２５５は、一実施形態では、記憶データの分析、記憶データの提供、記憶データの編成などのために、システムプロセッサ２００によって実行可能なルーチンで構成されるメモリに記憶される電子データ構造である。したがって、一実施形態では、データストア２５５は、コンピューティングシステム１１０のマイクロサービスによって使用されるデータを記憶する。

【0053】

さらなる態様では、ストレージモジュールはさらに、データストア２５５への複数のマイクロサービス間のアクセスを仲介する。この仲介により、マイクロサービスは、他のマイクロサービスに影響を与えることなく、独立して振る舞い（behave）／動作する（operate）ことができる。例えば、データストア２５５からデータを読取るマイクロサービスは、データを記憶しているサービスに影響を与えずに再開することができ、これは、マイクロサービスを実装していないモノリシックシステムにおいては競合を引き起こす。さらに、データストア２５５は、個別の記憶場所を分離し、どのデータを個別の記憶場所から通信するかを可能にする。このフレームワークでデータストア２５５を実装することにより、コンピューティングシステム１１０は、記憶されたデータよりも少ないデータを通信して、コスト削減をもたらす。最後に、データストア２５５は、過去のある時点からデータをフェッチ（fetch）する機能を備えて実装される。すなわち、一般に、自動車システムは、データを記憶することなく、１つのサービスから別のサービスにデータをストリーミングする。このような場合、イベントが発生すると、そのイベントの前に生成されたデータを識別することができない。従って、ストレージモジュールは、データストアを使用してデータが生成された時点の時間インデックスを介してデータを記憶して、特定の時点からのデータの再生または再検査を可能にし、それにより過去の任意の時点からのデータの調査および使用を可能にする、。

【0054】

マイクロサービス

【0055】

図１０を参照すると、コンピューティングシステム１１０の複数のＶＭ内に実装され得る自己完結型マイクロサービス１０００の一例が示されている。一般に、マイクロサービスは、マイクロサービスがどのように実装されるかの形式に関連して標準化されたアプリケーション／サービスである。この標準化された形式は、ライフサイクル、展開プロセス、監視、ロギングなど、システム全体の多くの側面を容易にする。図１０に示されるように、マイクロサービス１０００は、標準であり、マイクロサービス１０００のヘルスチェックのためのヘルスポート、サービス関連メトリックを提供するためのメトリックポート、およびデフォルトログおよびトレースレベルを変更するためのログレベルを含む、様々な管理ポートを含む。イベントバスクライアントは、制御プレーン通信（すなわち、コーン２５０）を提供する。マイクロサービス１０００は、これらのプロセスを標準化するために、ロギングおよびトレース情報を共通のロギングコンポーネントに記憶する。

【0056】

さらに、サービスレジストリと認証は、再利用性を可能にする共通ライブラリを使用して、サービス間通信を可能にするためのものである。障害管理モジュールは、一貫した管理を提供することにより、マイクロサービス全体で一貫した方法で障害を処理する。ＡＰＩは、サービス間の機能を容易にするために、一貫した方法で個別のマイクロサービスによって公開されることができる。

【0057】

マイクロサービスのルールエンジンは、イベントバスからのイベントに適用される構成命令を提供するユーティリティモジュール２６０のルールエンジンの拡張である。ルールエンジンを介してマイクロサービス機能を公開することによって、ルールエンジンは、即時のマイクロサービスのみを更新することによって他のサービスへの影響を回避する個々のマイクロサービスへの無線更新を含む、ルールに基づいてマイクロサービス１０００のアクションを呼び出すことができる。ＶＳＭ構成は、車両１００内のすべての信号のマップを定義し、したがって、ＶＳＭを介してマイクロサービス１０００によってデータを解析および処理するための標準化された機構は、マイクロサービス１０００が有効なデータのみを処理することを保証する。最後に、ロジック１０１０は、マイクロサービス１０００の一次命令／ロジックを含み、これは、複雑な機械学習アルゴリズムから単純なデータ転送命令まで変化させることができる。

【0058】

トレース（trace：追跡）

【0059】

クラウド１３０に関する態様に目を向けると、コンピューティングシステム１１０は、一構成では、トレースコレクタ（trace collector）を含む。トレースコレクタは、クラウド１３０またはトレースされるコンピューティングシステム１１０に関連する態様を特定する別のエンティティから提供されるトレース要求を受信する。トレースコレクタは、車両１００においてオフラインでトレース要求を実行する。すなわち、トレースコレクタは、クラウド１３０との通信チャネルを維持する必要はなく、代わりに、トレース要求に定義されたパラメータに従って、コンピューティングシステム１１０のログデータストア内でデータをローカルに収集することができる。このようにして、トレースコレクタは、不安定なネットワーク接続を伴う困難を克服することができ、代わりに、車両１００内のマイクロサービスにおいてトレースを開始して、トレース要求において定義されたメッセージを追跡し、その後、ネットワークがクラウド１３０に利用可能であるときに、収集されたデータをオフロードする。

【0060】

トレースコレクタの一例が、図１１の車両１００とクラウド１３０に関連して示されている。車両１００のローカルトレースコレクタは、クラウド１３０から発信され、クラウドトレースコレクタに送られるトレースを含む、すべてのトレースを受信する。ローカルトレースコレクタは、トレースをログストアに追加し、車両１００がクラウド１３０との安定した通信チャネルを有するときに、トレースの移動を制御する定義された優先順位に従って、トレースをクラウド１３０に提供する。その後、ローカルに記憶されたトレースは、安定したエンドツーエンドの通信チャネルを必要とせずに包括的なトレースを提供するために、同じ要求からの他のトレースに追加することができる。このようにして、車両内のマイクロサービスにわたるトレースはローカルであり、ネットワーク問題に起因するカスケード障害またはスレッドロックアップに遭遇しない。

【0061】

次に、図１の車両１００を、コンピューティングシステム１１０が動作することができる例示的な環境として、網羅的に詳細に説明する。いくつかの例では、車両１００は、自律モード、１つ以上の半自律動作モード、および／または手動モード間で選択的に切り換えるように構成される。「手動モード」は、車両のナビゲーション及び／又は操作の全て又は大部分が、利用者（例えば、人間の運転者）から受信された入力に従って実行されることを意味する。１つ以上の構成では、車両１００は、手動モードで動作するように配置された従来の車両とすることができる。

【0062】

１つ以上の実施形態では、車両１００は自律車両（autonomous vehicle）である。本明細書で用いる「自律車両」とは、自律モードで動作する車両を指す。「自律モード」とは、人間のドライバーからの入力を最小限に又は全く用いずに、車両１００を制御するために、１つ又は複数のコンピューティングシステムを使用して、走行経路に沿って車両１００をナビゲーション及び／又は操作することをいう。１つ以上の実施形態では、車両１００は、高度に自動化されているか、または完全に自動化されている。一実施形態では、車両１００は、１つ以上のコンピューティングシステムが、走行経路に沿って車両のナビゲーションおよび／または操作の一部を実行し、車両オペレータ（すなわち、運転者）が、走行経路に沿って車両１００のナビゲーションおよび／または操作の一部を実行するために車両に入力を提供する、１つ以上の半自律動作モードで構成される。

【0063】

車両１００は、システムプロセッサ２００などの１つ以上のプロセッサを含むことができる。１つ以上の構成では、プロセッサは、車両１００のメインプロセッサとすることができる。たとえば、プロセッサは、電子制御ユニット（ＥＣＵ）、マイクロプロセッサ、ＳｏＣなどとすることができる。車両１００は、１つ以上の種類のデータを記憶するための１つ以上のデータストア２５５を含むことができる。データストアは、車両１００の揮発性メモリおよび／または不揮発性メモリ内に格納することができる。データストア２５５のための適切なメモリの例としては、ＲＡＭ（ランダムアクセスメモリ）、フラッシュメモリ、ＲＯＭ（読み出し専用メモリ）、ＰＲＯＭ（プログラマブル読み出し専用メモリ）、ＥＰＲＯＭ（消去可能プログラマブル読み出し専用メモリ）、ＥＥＰＲＯＭ（電気的消去可能プログラマブル読み出し専用メモリ）、レジスタ、磁気ディスク、光ディスク、ハードドライブ、または他の任意の適切な記憶媒体、あるいはそれらの任意の組み合わせが挙げられる。データストア２５５は、プロセッサの構成要素であってもよく、あるいは、データストア２５５は、プロセッサに動作可能に接続されて使用されてもよい。本明細書を通して使用される「動作可能に接続される」および「通信可能に接続される」という用語は、直接的な物理的接触を伴わない接続を含み、直接的または間接的な接続を含むことができる。

【0064】

１つ以上の構成では、１つ以上のデータストア２５５は、地図データを含むことができる。地図データは、一つ以上の地理的領域の地図を含むことができる。いくつかの例では、地図データは、１つ以上の地理的領域内の道路、交通制御装置、路面標識、構造物、特徴、および／またはランドマークに関する情報またはデータを含むことができる。場合によっては、地図データは、様々なソースから取得または導出された領域の空中ビューを含むことができる。いくつかの事例では、地図データは、３６０度の地上ビューを含む、領域の地上ビューを含むことができる。地図データは、地図データに含まれる１つ以上の項目および／または地図データに含まれる他の項目に対する測定値、寸法、距離、および／または情報を含むことができる。地図データは、道路形状に関する情報を有するデジタル地図を含むことができる。地図データは高精細（ＨＤ）地図データとすることができる。１つ以上の構成では、地図データは、１つ以上の静的障害物地図を含むことができる。静的障害物地図は、１つ以上の地理的領域内に位置する１つ以上の静的障害物に関する情報を含むことができる。「静的障害物」は、ある期間にわたって位置が変化しないかまたは実質的に変化しない、および／またはそのサイズがある期間にわたって変化しないかまたは実質的に変化しない物理的物体である。

【0065】

１つ以上のデータストア２５５は、センサデータを含むことができる。この文脈において、「センサデータ」は、車両１００が装備するセンサから導出される情報を意味し、そのようなセンサに関する能力および他の情報を含む。後で説明するように、車両１００は、センサシステムを形成し、外部環境および車両１００自体に関する側面を知覚するセンサ２７０を含むことができる。一例として、１つ以上の構成では、センサデータは、１つ以上のＬIＤＡＲセンサ、エンジン監視センサなどからの情報を含むことができる。

【0066】

いくつかの事例では、地図データおよび／またはセンサデータの少なくとも一部は、車両１００に搭載された１つ以上のデータストア２５５内に位置することができる。代替的に、または追加的に、地図データおよび／またはセンサデータの少なくとも一部は、車両１００から遠隔に位置する１つ以上のデータストア２５５内に位置することができる。

【0067】

上述のように、車両１００はセンサシステムを含むことができる。センサシステムは、１つ以上のセンサを含むことができる。「センサ」は、センサが配置される環境の態様を検出および／または感知することができる電子デバイス、コンポーネント、および／またはシステムを意味する。１つ以上のセンサは、リアルタイムで検出および／または感知するように構成され得る。本明細書で使用するとき、用語「リアルタイム」は、ユーザ又はシステムが、特定のプロセス又は決定が行われるのに十分に即座に感知する処理応答性のレベルを意味する。

【0068】

センサシステムが複数のセンサを含む配置では、センサは互いに独立して動作することができる。あるいは、２つ以上のセンサを組み合わせて動作させることができる。このような場合、２つ以上のセンサがセンサネットワークを形成することができる。センサシステムおよび／または１つ以上のセンサは、プロセッサ、データストア、および／または車両１００の別の要素に動作可能に接続することができる。センサシステムは、車両１００の外部環境の少なくとも一部のデータを取得することができる。

【0069】

センサシステムは、１つ以上の車両センサを含むことができる。車両センサは、車両１００自体に関する情報を検出、決定、及び／又は感知することができる。１つ以上の構成では、車両センサは、たとえば慣性加速度に基づいて、車両１００の位置および向きの変化を検出および／または感知するように配置され得る。１つ以上の構成では、車両センサは、１つ以上の加速度計、１つ以上のジャイロスコープ、慣性測定ユニット（ＩＭＵ）、推測航法（dead-reckoning）システム、全地球航法衛星システム（ＧＮＳＳ）、全地球測位システム（ＧＰＳ）、ナビゲーションシステム、および／または他の適切なセンサを含むことができる。車両センサは、車両１００の１つ以上の特性を検出および／または感知するように構成され得る。１つ以上の構成では、車両センサは、車両１００の現在の速度を決定するための速度計を含むことができる。

【0070】

代替として、または加えて、センサシステムは、運転環境データを取得および／または感知するように構成された１つ以上の環境センサを含むことができる。「運転環境データ」は、車両１００が位置する外部環境又はその１以上の部分に関するデータ又は情報を含む。たとえば、１つ以上の環境センサは、車両１００の外部環境の少なくとも一部分における障害物、および／またはそのような障害物に関する情報／データを検出、定量化、および／または感知するように構成され得る。１つ以上の環境センサは、たとえば、路面標識、標識、信号機、交通標識、車線境界線、横断歩道、車両１００に近接する縁石、道路外の物体など、車両１００の外部環境内の他のものを検出、測定、定量化、および／または感知するように構成され得る。

【0071】

本明細書では、センサシステムのセンサの様々な例について説明する。例示的なセンサは、１つ以上の環境センサおよび／または１つ以上の車両センサの一部であってもよい。しかしながら、実施形態は、記載された特定のセンサに限定されないことが理解されるであろう。一例として、１つ以上の構成では、センサシステムは、１つ以上のレーダセンサ、１つ以上のＬＩＤＡＲセンサ、１つ以上のソナーセンサ、及び／又は１つ以上のカメラを含むことができる。

【0072】

車両１００は入力システムを含むことができる。「入力システム」は、情報／データがマシンに入力されることを可能にする、装置、コンポーネント、システム、要素、またはそれらの配置もしくはグループを含む。入力システムは、車両の乗客（例えば、運転者または乗客）からの入力を受信することができる。車両１００は、出力システムを含むことができる。「出力システム」は、情報／データが車両の乗客（例えば、人、車両乗客など）に提示されることを可能にする装置、コンポーネント、またはそれらの配置もしくはグループを含む。

【0073】

車両１００は、１つ以上の車両システムを含むことができる。車両１００は、推進システム、ブレーキシステム、操舵システム、スロットルシステム、トランスミッションシステム、シグナリングシステム、ナビゲーションシステムなどを含むことができる。これらのシステムの各々は、現在知られているか、または後に開発される、１つ以上の装置、コンポーネント、および／またはそれらの組み合わせを含むことができる。さらに、一般に、コンピューティングシステム１１０は、メカトロニクス層（例えば、メカトロニクスＥＣＵ）を介して車両システムと通信するように機能する。

【0074】

コンピューティングシステム１１０は、様々な車両システムおよび／またはその個々の構成要素と通信するように動作可能に接続することができる。コンピューティングシステム１１０は、車両１００の動作、速度、操作、進行方向、方向などを制御するために、様々な車両システムから情報を送信および／または受信するように通信することができる。コンピューティングシステム１１０は、これらの車両システムの一部または全部を制御することができる。

【0075】

さらに、コンピューティングシステム１１０は、複数のＶＭのうちの１つ以上の自動運転モジュールを介して、車両システムおよび／またはそのコンポーネントのうちの１つ以上を制御することによって、車両１００のナビゲーションおよび／または操作を制御するように動作可能であり得る。例えば、自律モードで動作するとき、プロセッサ、コンピューティングシステム１１０、および／または自動運転モジュール１６０は、車両１００の方向および／または速度を制御することができる。プロセッサ、コンピューティングシステム１１０、および／または自動運転モジュール１６０は、（たとえば、エンジンに供給される燃料の供給を増加させることによって）車両１００を加速させ、（たとえば、エンジンへの燃料の供給を減少させることによって、および／またはブレーキをかけることによって）減速させ、および／または（たとえば、前側の２つの車輪を回転させることによって）方向性を変更させることができる。本明細書で使用するとき、「させる」又は「させている」とは、イベント又は作用を発生させる(make)、強制する（force）、強制する（compel）、直接的、命令する、指示する、及び／又は可能にすること、又は、少なくとも、そのようなイベント又は作用が直接的又は間接的に発生し得る状態にあることを意味する。

【0076】

車両１００は、１つ以上のアクチュエータを含むことができる。アクチュエータは、プロセッサおよび／または自動運転モジュールからの信号または他の入力の受信に応答して、車両システムまたはそのコンポーネントのうちの１つ以上を修正、調整、および／または変更するように動作可能な任意の要素または要素の組合せとすることができる。例えば、１つ以上のアクチュエータは、モータ、空圧アクチュエータ、油圧ピストン、中継器、ソレノイド、圧電アクチュエータなどを含むことができる。

【0077】

車両１００は、１つ以上のモジュールを含むことができ、そのうちの少なくともいくつかは、本明細書で説明される。モジュールは、システムプロセッサ２００または別のプロセッサによって実行されるときに、本明細書に記載する種々のプロセスのうちの１つまたは複数を実装する、コンピュータ読み取り可能なプログラムコードとして実装可能である。モジュールの１つ以上は、プロセッサ自体のコンポーネントであってもよく、あるいは、１つ以上のモジュールは、プロセッサが動作的に接続されている他の処理システム上で、および／または他の処理システム間で、実行されおよび／または分散してもよい。モジュールは、１つ以上のプロセッサによって実行可能な命令（例えば、プログラム論理）を含むことができる。

【0078】

車両１００は、１つ以上の自動運転モジュールを含むことができる。自動運転モジュールは、車両１００のセンサシステム及び／又は他のシステムからデータを受信するように構成することができる。１つ以上の構成では、自動運転モジュールは、そのようなデータを使用して、１つ以上の運転シーンモデルを生成することができる。自動運転モジュールは、車両１００の位置及び速度を決定することができる。自動運転モジュールは、交通標識、木、低木、近隣車両、歩行者などを含む、障害物または他の環境特徴物の位置を決定することができる。

【0079】

自動運転モジュールは、プロセッサによって使用するための車両１００の外部環境内の障害物の位置情報、および／または車両１００の位置および向きを推定するための本明細書に記載のモジュールのうちの１つもしくは複数、または車両１００の現在の状態を決定するために、またはマップを作成するか、またはマップ／知覚されたデータに対する車両１００の位置を決定するために使用するためのその環境に対する車両１００の位置を決定するために使用され得る他のデータおよび／もしくは信号を受信し、かつ／または決定するように構成され得る。

【0080】

自動運転モジュールは、センサシステムによって取得されたデータ、運転シーンモデル、および／または他の適切なソースからのデータに基づいて、走行経路、車両１００の現在の自動運転操作、将来の自動運転操作、および／または現在の自動運転操作に対する修正を決定するように構成することができる。「運転操作」は、車両の動作に影響を及ぼす１つ以上の作用を意味する。運転操作の例には、いくつかの可能性を挙げると、加速、減速、制動、旋回、走行車線の変更、走行車線への合流、および／または反転が含まれる。自動運転モジュールは、決定された運転操作を実施するように構成することができる。自動運転モジュールは、直接的または間接的に、そのような自立運転操作を実行させることができる。本明細書で使用するとき、「させる」又は「させている」とは、イベント又は作用を発生させる、命令する、指示する、及び／又は可能にすることを意味し、又は少なくとも、そのようなイベント又は作用が直接的又は間接的に発生し得る状態にあることを意味する。自動運転モジュールは、様々な車両機能を実行するように、および／または、車両１００またはその１つ以上のシステム（例えば、車両システムの１つ以上）からデータを送信し、データを受信し、データと相互作用し、および／またはデータを制御するように構成され得る。

【0081】

詳細な実施形態が本明細書に開示される。しかしながら、開示された実施形態は、例としてのみ意図されることを理解されたい。したがって、本明細書に開示される特定の構造的および機能的な詳細は、限定として解釈されるべきではなく、単に、特許請求の範囲の基礎として、および当業者が実質的に任意の適切に詳細な構造において本明細書の態様を様々に使用することを教示するための代表的な基礎として解釈されるべきである。さらに、本明細書で使用される用語および語句は、限定することを意図するものではなく、むしろ、可能な実装形態の理解可能な説明を提供することを意図する。様々な態様が図１～図１１に示されているが、実施形態は、図示された構造または用途に限定されない。

【0082】

図中のフローチャートおよびブロック図は、様々な態様による、システム、方法、およびコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能、および動作を示す。この点に関して、フローチャートまたはブロック図中の各ブロックは、特定の論理機能を実装するための１つまたは複数の実行可能命令を備える、モジュール、セグメント、またはコードの一部を表し得る。また、いくつかの代替的な実装において、ブロック中に記載された機能は、図中に記載された順序から外れて起こる可能性があることに留意されたい。例えば、連続して示される２つのブロックは、実際には、実質的に同時に実行されてもよく、または、ブロックは、関与する機能に応じて、逆の順序で実行されてもよい。

【0083】

上述のシステム、コンポーネント、および／またはプロセスは、ハードウェアまたはハードウェアとソフトウェアの組合せで実現することができ、１つの処理システムで集中化された方法で、または異なる要素がいくつかの相互接続された処理システムに分散された、分散された方法で実現することができる。本明細書に記載の方法を実行するように適合された任意の種類の処理システムまたは別の装置が適している。ハードウェアとソフトウェアの典型的な組合せは、コンピュータで使用可能なプログラムコードを有する処理システムであってよく、これは、ロードされて実行されるとき、本明細書に記載する方法を実行するように、処理システムを制御する。また、システム、コンポーネントおよび／またはプロセスは、本明細書に記載する方法およびプロセスを実行するためにマシンによって実行可能な命令のプログラムを実体的に具体化する、マシンによって読み取り可能な、コンピュータプログラム製品または他のデータプログラム記憶装置などの、コンピュータ読み取り可能な記憶装置に埋め込むことができる。これらの要素はまた、本明細書に記載の方法の実施を可能にし、処理システムにロードされたときにこれらの方法を実行することができるすべての特徴を含むアプリケーション製品に埋め込むことができる。

【0084】

さらに、本明細書で説明される構成は、その上に具体化される、たとえば記憶される、コンピュータ可読プログラムコードを有する１つまたは複数のコンピュータ可読媒体において具体化されるコンピュータプログラム製品の形をとり得る。１つまたは複数のコンピュータ可読媒体の任意の組合せが利用され得る。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体とすることができる。「コンピュータ読み取り可能な記憶媒体」という語句は、一時的でない記憶媒体を意味する。コンピュータ可読記憶媒体は、たとえば、電子、磁気、光学、電磁気、赤外線、もしくは半導体のシステム、装置、もしくはデバイス、または前述のものの任意の適切な組合せであり得るが、これらに限定されない。コンピュータ読取り可能記憶媒体のより具体的な例（包括的ではないリスト）には、ポータブルコンピュータディスケット、ハードディスクドライブ（HDD）、ソリッドステートドライブ（SSD）、読取り専用メモリ（ROM）、消去可能プログラマブル読取り専用メモリ（EPROM又はフラッシュメモリ）、ポータブルコンパクトディスク読取り専用メモリ（CD（登録商標）-ROM）、デジタル汎用ディスク（DVD（登録商標））、光学記憶装置、磁気記憶装置、またはこれらの適当な組み合わせが含まれる。本明細書の文脈において、コンピュータ可読記憶媒体は、命令実行システム、装置、または装置によって、またはそれに関連して使用するためのプログラムを収容したり、または記憶したりすることのできる任意の有形媒体であってもよい。

【0085】

一般に、本明細書で使用されるモジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み、これらは特定のタスクを実行するか、または特定のデータタイプを実装する。さらなる態様では、メモリは、一般に、言及されたモジュールを記憶する。モジュールに関連するメモリは、プロセッサ、ＲＡＭ、ＲＯＭ、フラッシュメモリ、または他の適切な電子記憶媒体内に埋め込まれたバッファまたはキャッシュであってもよい。なおさらなる態様では、本開示によって想定されるようなモジュールは、特定用途向け集積回路（ＡＳＩＣ）、システムオンチップ（ＳｏＣ）のハードウェア構成要素として、プログラマブルロジックアレイ（ＰＬＡ）、または開示された機能を実行するための定義された構成セット（例えば、命令）が埋め込まれた別の適切なハードウェア構成要素として、実装される。

【0086】

コンピュータ可読媒体上に埋め込まれたプログラムコードは、無線、有線、光ファイバ、ケーブル、ＲＦなど、または前述の任意の適切な組合せを含むが、これらに限定されない、任意の適切な媒体を使用して送信され得る。本構成の態様のための動作を実行するためのコンピュータプログラムコードは、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋等のようなオブジェクト指向プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語のような従来の手続き型プログラミング言語とを含む、１つ以上のプログラミング言語の任意の組み合わせで書くことができる。プログラムコードは、利用者のコンピュータ上で、部分的には利用者のコンピュータ上で、部分的にはスタンドアロンソフトウェアパッケージとして、部分的には利用者のコンピュータ上で、部分的にはリモートコンピュータ上で、あるいは完全にリモートコンピュータまたはサーバ上で実行することができる。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよく、または、接続は、外部コンピュータに対して（例えば、インターネットサービスプロバイダを使用するインターネットを介して）行われてもよい。

【0087】

本明細書で使用される「１つ」という用語は、１つ以上の１として定義される。用語「複数」は、本明細書で使用される場合、２つ以上の２として定義される。「別の」という用語は、本明細書で使用される場合、少なくとも第２またはそれ以上と定義される。本明細書で使用される「含む（including）」および／または「有する（having）」という用語は、含む（comprising）（すなわち、オープン言語）として定義される。本明細書で使用される「のうちの少なくとも１つ」という語句は、関連する列挙された項目のうちの１つまたは複数の任意のおよびすべての可能な組合せを指し、それらを包含する。一例として、「Ａ、Ｂ、およびＣのうちの少なくとも１つ」という語句は、Ａのみ、Ｂのみ、Ｃのみ、またはそれらの任意の組合せ（たとえば、ＡＢ、ＡＣ、ＢＣ、またはＡＢＣ）を含む。

【0088】

本明細書の態様は、その精神または本質的な属性から逸脱することなく、他の形態で実施することができる。従って、本明細書の技術的範囲を示すように、前述の明細書ではなく、以下の特許請求の技術的範囲を参照すべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【国際調査報告】