指標の構成では、Telemetry サービスが実行するテレメトリー キャンペーンを定義します。指標の構成は、MetricsConfig プロトコル バッファ（protobuf）メッセージのインスタンスです。指標の構成では、データの収集、処理、レポートの方法を指定します。OEM は、Telemetry サービスの API を使用して指標の構成を有効にできます。複数の構成を同時に実行できます。
始める前に、SDV アーキテクチャについて理解しておいてください。これは サービスがデータを protobuf メッセージとして公開するサービス指向アーキテクチャです。 これらのメッセージは、RPC またはパブリッシュ / サブスクライブを介して SDV 通信スタックを使用して通信します。
主な用語
指標の構成 は、データソース、処理ルール、レポート メカニズムを定義してデータの収集を調整します。このエッジ処理の主なメリットの一つは、モバイルデータの使用量が削減されることです。デバイスで高頻度のデータを処理し、集計または分析情報のみをアップロードすることで、クラウドに送信されるデータ量を大幅に削減できます。
指標の構成の定義は、構成で使用するデータソース を一覧表示することから始まります。これらは、SDV 通信スタックを介してデータを利用可能にするサービスです。構成を有効にすると、Telemetry サービスはこれらのソースに接続して、必要に応じてデータをストリーミングまたは取得します。
構成の中核となるのは、ステートフルなデータ アグリゲータ を介して管理されるエッジデータ処理機能です。各アグリゲータは、ステートフルな proto メッセージ インスタンスを維持するメッセージ ビルダー を使用します。このメッセージの各フィールドには、式を評価して値が設定されます。この式では、他のデータソースまたはアグリゲータから読み取るデータと、データに適用する数学演算、論理演算、集計演算を定義します。式の結果に追加の集計を適用できます。
このプロセスを制御するうえでトリガー が重要になります。トリガーは、定期的に、新しいデータに応じて、またはデータに基づく条件が満たされたときに起動できます。トリガーは、アグリゲータがメッセージ ビルダーを評価するタイミング、指標レポートが生成されるタイミングを決定し、データの収集の開始や停止など、構成のライフサイクルに影響を与える可能性があります。
指標レポート は最終的な出力です。各レポートには、メッセージ ビルダーで定義されたデータ ペイロードと、タイムスタンプやレポート ID などのメタデータが含まれます。構成が有効または無効になったときなど、特定の構成ライフサイクルのタイミングでレポートを生成できます。生成されたレポートはメモリに保存され、レポート ステータス通知チャネルを介して取得するようにクライアントに通知されます。
次の図は、指標の構成内でコンポーネントがどのように連携できるかの概念的な例を示しています。
図 1.指標の構成内のデータソース、処理、レポート。
指標の構成要素
指標の構成を使用すると、データの収集タスクと複雑なオンデバイス処理パイプラインを定義できます。このセクションでは、指標キャンペーンの定義に使用されるコア コンポーネントについて詳しく説明します。コンポーネントは、入力から出力まで、データがシステムを流れる順に示されています。これらのコンポーネントは任意の順序で定義できます。アグリゲータによるデータの処理とライフサイクル管理は省略可能です。
- データソースを定義する
- アグリゲータでデータを処理する
- トリガーで実行フローを制御する
- 指標レポートを生成する
- データの収集のライフサイクルを管理する
データソースを定義する
指標キャンペーンの基盤はデータです。指標の構成では、データを受信するメカニズムが抽象化されているため、データソースを識別できる名前と接続モード（サブスクリプションまたはオンデマンド）のみを指定する必要があります。データソースは、SDV 通信スタックを介してデータを利用可能にするサービス、または 構成可能なパブリッシャー レジストリに登録するサービスにできます。 これにより、SDV ミドルウェアが使用できないアプリからデータの収集が可能です。各データソースには、トリガーやアグリゲータなどの他の指標構成要素から参照できるように、構成内で一意の名前を付ける必要があります。接続方法、データの受信頻度を構成し、サービス固有の構成オブジェクトを指定できます。
データソースの構成
Telemetry サービスは、次の 2 つの方法でデータソースに接続できます。
- Getter: 指標の構成で定義された式がこのソースからデータを読み取る必要があるたびに、このメソッドはオンデマンドでデータを取得します。 これは、継続的なストリームを提供しないデータソースや、データのスナップショットを頻繁に取得する必要がない場合に便利です。
- サブスクリプション: これはデフォルトの方法です。ソースから継続的なデータ ストリームを確立します。このソースから新しいメッセージが届いたときにトリガーされるデータトリガーを使用する場合は、この接続タイプが必要です。
サブスクリプションを使用する場合は、次の項目を構成できます。
- サブサンプリング: データの取り込み頻度が高すぎないように、同じソースからの連続するメッセージ間の最小時間間隔を定義できます。ソースがこの間隔よりも速くデータを公開すると、Telemetry サービスは通知をスロットリングし、スロットリング後に受信したメッセージに対してのみデータトリガーが有効になります。これにより、データが効果的にサブサンプリングされます。
- 最初のメッセージの取得: サブスクリプションを確立するときに、ソースから最新のメッセージを取得するようにサービスを構成できます。その結果、最初の新しいメッセージが公開されるのを待つのではなく、値が使用可能な場合はすぐにデータソースに値が入力されます。 これは、初期状態が必要な条件付きトリガーやアグリゲータ、またはデータソースの公開頻度が低い場合に便利です。
タイプに関係なく、メッセージは内部的にキャッシュに保存されます。単一の評価サイクル中に複数の式またはアグリゲータが同じソースからのデータを必要とする場合、システムはデータを 1 回だけ取得します。サブスクリプションを使用して新しいメッセージが届いた場合はキャッシュから、または単一のオンデマンド呼び出しを使用して取得します。
アグリゲータでデータを処理する
データソースは未加工データを提供しますが、アグリゲータはステートフルなエッジデータ処理を実行します。データソースや他のアグリゲータからデータを取り込み、変換して、指標レポートで読み取れるようにしたり、他のアグリゲータでさらに処理できるようにします。これにより、多段階の処理パイプラインを構築できます。たとえば、1 つのアグリゲータで速度統計を計算し、その統計を運転行動パターンを検出する別のコンポーネントで使用できます。
アグリゲータは、1 つ以上のトリガーによって計算を実行するようにトリガーされます。 トリガーが起動するたびに、アグリゲータはそのルールを評価し、内部状態を更新します。
アグリゲータは、別のコンポーネントによって値が読み取られた後に状態をリセットするように構成できます。これは、重複しない時間枠で統計を計算する場合に便利です。
メッセージ ビルダーは、アグリゲータの構造とロジックを定義します。メッセージ ビルダーは、各フィールドのデータを生成する方法を記述することで、proto メッセージのインスタンスを構築する方法を指定します。各フィールドについて、式はデータソースとアグリゲータからデータを読み取り、このデータにオペレーションを適用する方法を定義します。さらに、時間の経過に伴う式の結果に適用される 計算または収集オペレーション である集計を適用することもできます。
次の集計タイプがサポートされています。
- 数学: 各トリガーの式から返された値に対して統計（平均、最小値、最大値、合計、標準偏差、デルタ）を計算します。デルタは、式から返された現在値と前の数値の差です。
- リスト: 式から返された値をリストに収集します。リストサイズを制限して、最近の値のローリング ウィンドウ（リングバッファ）を作成できます。
- カウント: 式が指定されていない特殊なケース。フィールドが評価された回数（つまり、アグリゲータまたはレポートがトリガーされた回数）をカウントします。
- パススルー: 集計を適用せずに、式の結果を直接使用します。これは、アグリゲータから最終値にアクセスするためのレポート構成で役立ちます。
次の図は、アグリゲータの評価を示す概念図です。
図 2.アグリゲータの評価。
式を使用して計算を実行する、または条件を定義する
式は、メッセージ ビルダーと条件付きトリガー内で使用され、計算の実行や条件の定義を行います。Metrics Configuration Generator（MCG）を使用して指標構成 JSON オブジェクトを作成する場合、式は、ドット表記を使用してデータソースのフィールド（vehicle_speed.speed_value など）にアクセスし、幅広いオペレーションを適用する、人間が読める文字列として記述されます。MCG は、これらの文字列を抽象構文木（AST）に似た最適化されたツリー構造に変換し、最終的な MetricsConfig protobuf メッセージで効率的なオンデバイス評価を行います。
演算子と関数
式では、次の演算子と関数のセットがサポートされています。
- 算術: 加算、減算（二項と単項）、乗算、除算、剰余、累乗をサポートします。
- 論理: AND、OR、NOT、XOR をサポートします。
- リレーショナル: 等価性チェック、大なり比較、小なり比較をサポートします。
- リスト: リストに特定の値が含まれているかどうかを確認します。
- タイムスタンプ: 評価時のタイムスタンプをマイクロ秒単位で返します。クロックタイプは、リアルタイム クロック、起動からのモノトニック時間（一時停止時間を含む）、起動または最後の再開からのモノトニック時間にできます。
- 絶対値: 数値の絶対値を返します。
- 丸め: 最も近い整数に丸める（
round）、数値以下の最大の整数を返す（floor）、数値以上の最小の整数を返す（ceil）。
2 つのデータソースから読み取り、車両速度が 100 kmph を超えていて、タイヤ空気圧の警告がない場合に true に評価される式の例を次に示します。
(vehicle_speed.speed_value * 3.6) > 100 && tire_pressure.warning == false
トリガーで実行フローを制御する
トリガーは指標の構成のオーケストレータです。データの処理とレポートの生成のタイミングを制御します。各トリガーには一意の名前が必要です。
トリガーには次の 3 種類があります。
- データトリガー: サブスクリプション接続のデータソースが新しいメッセージを公開したときに起動します（構成されている場合はサブサンプリング後）。
- 定期的なトリガー: 固定時間間隔で起動します。
- 条件付きトリガー: 指定された論理条件が満たされたときに起動します。
条件付きトリガー
条件付きトリガーは、他のトリガー（データ、定期、その他の条件付きトリガー）をリッスンし、それらのトリガーのいずれかが起動したときに式を評価します。条件付きトリガーは、式の結果が特定の条件を満たす場合にのみ起動します。
条件付きトリガーは、次の条件タイプに基づいて起動するように構成できます。
- 値: 式が
true（またはゼロ以外）またはfalse（またはゼロ）に評価された場合。 - 立ち上がりエッジ: ブール式が
falseからtrueに変わった場合、または数値が増加した場合。 - 立ち下がりエッジ: ブール式が
trueからfalseに変わった場合、または数値が減少した場合。 - 変更時: 式の結果が前の値と異なる場合。
ノイズの多い状態変化をフィルタする
エッジベースまたは変更時のトリガーの場合、トリガーが起動する前に条件が新しい状態を維持する最小期間を要求することで、短いまたはノイズの多い状態変化（グリッチ）をフィルタできます。
たとえば、トリガーが vehicle_speed > 100
が true になり、少なくとも 5 秒間 true のままの場合にのみ起動するように構成できます。これにより、速度の読み取り値が一時的に急上昇した場合にトリガーが起動するのを防ぐことができます。この保持期間中に確認されたすべての値が完全に等しいことを要求することもできます。
指標レポートを生成する
データの処理後、レポートにパッケージ化する方法とタイミングを定義します。
レポートは、メッセージ ビルダーを使用して出力の構造と内容を定義する指標レポート構成を使用して定義されます。レポートのトリガーのいずれかが起動すると、メッセージ ビルダーはフィールド割り当てを評価してレポートのデータ ペイロードを構築します。
生成された各レポートは MetricsReport Protobuf メッセージのインスタンスであり、メッセージ ビルダーの出力を payload フィールドにラップしてメタデータを追加します。Telemetry サービスは、次のメタデータを各 MetricsReport に自動的に追加します。
- レポートの一意の識別子（UUID）
- このレポート構成で生成されたレポートごとに増分するレポート番号
- レポートが生成されたときのタイムスタンプ
- 生成理由（ルールによってトリガーされた、シャットダウン時に生成されたなど）
- レポートを生成した指標の構成の UUID とバージョン
- 指標レポート構成の名前
レポート生成の制御
レポートは通常、トリガーに応じて生成されますが、指標の構成の特定のライフサイクルのタイミングで生成するように構成することもできます。
- 有効化時のレポート: 有効にすると、指標の構成が有効になったときに、システムは最初のレポートをすぐに生成します。
- 最終レポート: 有効にすると、データ収集が一時停止または停止したとき、または Telemetry サービスがシャットダウンしたときに、システムは最終レポートを生成します。 このレポートには、その時点までに集計されたデータが含まれており、セッションの終了時にデータが失われないようにします。
データの収集のライフサイクルを管理する
デフォルトでは、指標の構成は、クライアントによって有効にされるとすぐにデータの収集と処理を開始し、クライアントによって無効にされるまで続行されます。ただし、データ収集または指標の構成を開始または停止するトリガーを定義することで、このライフサイクルをより細かく制御できます。
- 開始トリガー: 定義されている場合、このトリガーが起動したときにのみデータの収集が開始されます。停止トリガーによって収集が一時停止された場合、開始トリガーによって再開されます。
- 停止トリガー: 定義されている場合、このトリガーはデータ収集を一時停止します。 開始トリガーが再び起動するまで、集計とレポートの生成は停止します。
- 無効化トリガー: このトリガーは、クライアントからの
deactivate_metrics_config呼び出しと同じ方法で指標の構成を無効にします。
たとえば、vehicle_state が DRIVING に変わったときに起動する条件付きトリガーを開始トリガーとして定義し、vehicle_state が PARKED に変わったときに起動する別のトリガーを停止トリガーとして定義できます。これにより、車両が走行中にのみデータが収集されるようになります。