Концепции конфигурации метрик

Конфигурации метрик определяют кампании телеметрии, которые запускает служба телеметрии. Конфигурация метрик представляет собой экземпляр сообщения протокола буфера протоколов (protobuf) MetricsConfig . Конфигурации метрик определяют, как собирать, обрабатывать и сообщать данные. Производители оборудования могут активировать конфигурации метрик через API службы телеметрии. Несколько конфигураций могут выполняться одновременно.

Прежде чем начать, ознакомьтесь с архитектурой SDV , которая представляет собой сервисно-ориентированную архитектуру, в которой сервисы публикуют данные в виде сообщений protobuf. Эти сообщения обмениваются данными с использованием стека связи SDV через RPC или по схеме «публикация-подписка».

Ключевые термины

A metrics configuration orchestrates data collection by defining data sources, processing rules, and reporting mechanisms. One of the main benefits of this edge processing is reduced mobile data usage. By processing high-frequency data on the device and uploading only aggregates or insights, you significantly reduce the amount of data transmitted to the cloud.

Определение конфигурации метрик начинается со списка источников данных , которые будут использоваться в конфигурации. Это службы, которые предоставляют данные через коммуникационный стек SDV. При активации конфигурации служба телеметрии подключается к этим источникам для потоковой передачи или получения данных по мере необходимости.

Основой конфигурации является возможность обработки данных на периферии сети, управляемая агрегаторами данных с сохранением состояния. Каждый агрегатор использует построитель сообщений , который поддерживает экземпляр прототипа сообщения с сохранением состояния. Каждое поле в этом сообщении заполняется путем вычисления выражения, определяющего, какие данные следует считывать из других источников данных или агрегаторов, и какие математические, логические или агрегационные операции следует применять к данным. К результату выражения можно применять дополнительные агрегации.

Триггеры играют центральную роль в управлении этим процессом. Они могут срабатывать периодически, в ответ на новые данные или при выполнении условий, основанных на данных. Триггеры определяют, когда агрегаторы оценивают свой построитель сообщений, когда генерируются отчеты по метрикам, и могут влиять на жизненный цикл конфигурации, например, запуская или останавливая сбор данных.

Итоговым результатом являются отчеты по метрикам . Каждый отчет включает в себя данные, определенные конструктором сообщений, а также метаданные, такие как временные метки и идентификатор отчета. Вы можете создавать отчеты в определенные моменты жизненного цикла конфигурации, например, при активации или деактивации конфигурации. Сгенерированные отчеты хранятся в памяти, и клиент получает уведомление о необходимости их получения через канал уведомлений о состоянии отчета.

На следующем рисунке представлен концептуальный пример взаимодействия компонентов в рамках конфигурации метрик:

Рисунок 1. Источники данных, их обработка и формирование отчетов в рамках конфигурации метрик.

Компоненты конфигурации метрик

С помощью конфигураций метрик можно определять задачи сбора данных и сложные конвейеры обработки на устройстве. В этом разделе подробно описаны основные компоненты, используемые для определения кампании по сбору метрик. Компоненты представлены в порядке прохождения данных через систему, от входа к выходу. Вы можете определить эти компоненты в любом порядке. Обработка данных с помощью агрегаторов и управление жизненным циклом являются необязательными.

• Определите источники данных
• Обработка данных с помощью агрегаторов
• Управляйте потоком выполнения с помощью триггеров.
• Создание отчетов по метрикам
• Управление жизненным циклом сбора данных

Определите источники данных

The foundation of any metrics campaign is data. In a metrics configuration, the mechanism of receiving data is abstracted and you need to specify only the name by which a data source can be identified and the mode of connection (subscription or on demand). Data sources can be any service that makes data available through the SDV communications stack or registers itself in the Configurable Publisher Registry , which enables data collection from apps where SDV middleware is unavailable. Each data source must have a unique name within the configuration so that it can be referenced by other metrics configuration components like triggers or aggregators. You can configure how it connects, how often it receives data, and provide a service-specific configuration object.

Настройка источников данных

Служба телеметрии может подключаться к источнику данных двумя способами:

• Метод Getter: Этот метод получает данные по запросу всякий раз, когда выражение, определенное в конфигурации метрик, должно считывать данные из этого источника. Это полезно для источников данных, которые не предоставляют непрерывный поток, или когда вам нужны нечастые снимки данных.
• Подписка: Это метод по умолчанию. Он устанавливает непрерывный поток данных из источника. Этот тип подключения необходим, если вы планируете использовать триггер данных, который срабатывает при поступлении новых сообщений из этого источника.

При использовании подписки вы можете настроить следующее:

• Subsampling: To avoid ingesting data too frequently, you can define a minimum time interval between consecutive messages from the same source. If the source publishes data faster than this interval, the Telemetry service throttles the notifications, and data triggers activate only for messages received after throttling. This effectively subsamples the data.
• Первоначальное получение сообщения: Вы можете настроить службу таким образом, чтобы она получала самое последнее сообщение из источника при установлении подписки. В результате источник данных немедленно заполняется значением, если оно доступно, вместо того, чтобы ждать публикации первого нового сообщения. Это полезно в условных триггерах или агрегаторах, требующих начального состояния, или когда источник данных публикует данные нечасто.

Независимо от типа, сообщения кэшируются внутри системы. Если нескольким выражениям или агрегаторам требуются данные из одного и того же источника в течение одного цикла обработки, система извлекает данные только один раз: либо из кэша, если новое сообщение поступило по подписке, либо с помощью одного вызова по запросу.

Обработка данных с помощью агрегаторов

В то время как источники данных предоставляют необработанные данные, агрегаторы выполняют обработку данных на периферии сети с сохранением состояния. Они получают данные из источников данных или других агрегаторов, преобразуют их и делают результат доступным для чтения в отчетах по метрикам или для дальнейшей обработки другими агрегаторами. Это позволяет создавать многоступенчатые конвейеры обработки, например, вычислять статистику скорости в одном агрегаторе и использовать эту статистику в другом компоненте, который отслеживает модели поведения водителя.

Агрегаторы запускаются для выполнения вычислений одним или несколькими триггерами. Каждый раз, когда срабатывает один из триггеров, агрегатор оценивает свои правила и обновляет свое внутреннее состояние.

Вы можете настроить агрегатор таким образом, чтобы он сбрасывал свое состояние после того, как его значение будет считано другим компонентом, что полезно для расчета статистики за непересекающиеся временные интервалы.

Конструктор сообщений определяет структуру и логику агрегатора. Конструктор сообщений указывает, как создать экземпляр прототипа сообщения, описывая, как генерировать данные для каждого из его полей. Для каждого поля выражение определяет, как считывать данные из источников данных и агрегаторов и применять к этим данным операции. Кроме того, можно применить агрегацию , которая представляет собой операцию вычисления или сбора данных, применяемую к результатам выражения с течением времени.

Поддерживаются следующие типы агрегации:

• Математический уровень: вычисляет статистические значения (среднее, минимальное, максимальное, сумма, стандартное отклонение и дельта) по значениям, возвращаемым выражением при каждом срабатывании триггера. Дельта — это разница между текущим и предыдущим числовым значением, возвращаемым выражением.
• Список: Собирает значения, возвращаемые выражением, в список. Вы можете ограничить размер списка, чтобы создать скользящее окно (кольцевой буфер) последних значений.
• Count: Особый случай, когда выражение не указано. Подсчитывает, сколько раз поле оценивается (то есть, сколько раз запускается агрегатор или отчет).
• Сквозная передача: использует результат выражения напрямую, без применения агрегации. Это полезно в конфигурациях отчетов для доступа к конечным значениям из агрегаторов.

На следующем рисунке представлена ​​концептуальная схема, иллюстрирующая оценку агрегатора:

Рисунок 2. Оценка агрегатора.

Выполняйте вычисления или определяйте условия с помощью выражений.

Выражения используются в конструкторах сообщений и условных триггерах для выполнения вычислений или определения условий. При использовании генератора конфигурации метрик (MCG) для создания JSON-объектов конфигурации метрик выражения записываются в виде удобочитаемых строк, использующих точечную нотацию для доступа к полям источника данных (например, vehicle_speed.speed_value ) и применения широкого спектра операций. MCG преобразует эти строки в оптимизированную древовидную структуру, аналогичную абстрактному синтаксическому дереву (AST), для эффективной оценки на устройстве в итоговом сообщении protobuf MetricsConfig .

Операторы и функции

Выражения поддерживают следующий набор операторов и функций:

• Арифметические операции: поддерживают сложение, вычитание (двоичное и унарное), умножение, деление, остаток от деления и возведение в степень.
• Логические функции: поддерживают операторы И, ИЛИ, НЕ и Исключающее ИЛИ.
• Реляционный подход: Поддерживает проверку на равенство, а также сравнение «больше» и «меньше».
• List: Проверяет, содержит ли список определенное значение или нет.
• Timestamp: Возвращает метку времени на момент вычисления в микросекундах. Тип часов может быть часами реального времени, монотонным временем с момента загрузки (включая время приостановки) или монотонным временем с момента загрузки или последнего возобновления работы.
• Функция "Абсолютное значение": возвращает абсолютное значение числа.
• Округление: Округляет до ближайшего целого числа ( round ), возвращает наибольшее целое число, меньшее или равное заданному числу ( floor ), или возвращает наименьшее целое число, большее или равное заданному числу ( ceil ).

Вот пример выражения, которое считывает данные из двух источников и принимает значение true , если скорость автомобиля превышает 100 км/ч и отсутствует предупреждение о низком давлении в шинах:

(vehicle_speed.speed_value * 3.6) > 100 && tire_pressure.warning == false

Управляйте потоком выполнения с помощью триггеров.

Триггеры — это инструменты управления конфигурацией метрик; они контролируют время обработки данных и создания отчетов. Каждый триггер должен иметь уникальное имя.

Существует три типа триггеров:

• Триггеры данных: срабатывают, когда источник данных с подпиской публикует новое сообщение (после выборки, если это настроено).
• Периодические триггеры: срабатывают через фиксированный промежуток времени.
• Условные триггеры: срабатывают при выполнении указанного логического условия.

Условные триггеры

Условные триггеры отслеживают другие триггеры (триггеры данных, периодические триггеры или другие условные триггеры) и, когда один из этих триггеров срабатывает, оценивают выражение. Условный триггер срабатывает только в том случае, если результат выражения соответствует определенному условию.

Вы можете настроить условный триггер таким образом, чтобы он срабатывал на основе нескольких типов условий:

• Значение: Когда выражение принимает значение true (или ненулевое) или false (или нулевое).
• Восходящий фронт: Когда логическое выражение изменяется с false на true или числовое значение увеличивается.
• Спад на фронте: событие, когда логическое выражение изменяется с true на false или числовое значение уменьшается.
• При изменении: всякий раз, когда результат выражения отличается от его предыдущего значения.

Фильтрация зашумленных изменений состояния

Для триггеров, срабатывающих по фронту события или при изменении состояния, можно отфильтровать кратковременные или шумные изменения состояния (сбои), установив требование, чтобы состояние оставалось в новом состоянии в течение минимального времени до срабатывания триггера.

For example, you can configure a trigger to fire only if vehicle_speed > 100 becomes true and stays true for at least 5 seconds. This prevents the trigger from firing due to a momentary spike in the speed reading. You can also require that all values seen during this hold duration are exactly equal.

Создание отчетов по метрикам

После обработки данных вы определяете, как и когда они будут сформированы в отчеты.

Отчеты определяются с помощью конфигураций отчетов по метрикам , которые используют конструкторы сообщений для определения структуры и содержимого их выходных данных. Когда срабатывает один из триггеров отчета, конструктор сообщений оценивает назначенные ему поля для формирования полезной нагрузки данных отчета.

Каждый сгенерированный отчет представляет собой экземпляр сообщения Protobuf MetricsReport , которое оборачивает выходные данные построителя сообщений в поле payload и добавляет метаданные. Служба телеметрии автоматически добавляет следующие метаданные к каждому MetricsReport :

• Универсальный уникальный идентификатор (UUID) для отчета.
• Порядковый номер отчета, который увеличивается для каждого отчета, созданного с помощью данной конфигурации отчетов.
• Отметка времени создания отчета.
• Причина генерации (например, срабатывает по правилу или генерируется при завершении работы).
• UUID и версия конфигурации метрик, на основе которой был сгенерирован отчет.
• Название конфигурации отчета по метрикам

контроль генерации отчетов

Хотя отчеты обычно генерируются в ответ на триггеры, вы также можете настроить их генерацию в определенные моменты жизненного цикла конфигурации метрик:

• Отчет об активации: Если эта функция включена, система немедленно генерирует первоначальный отчет при активации конфигурации метрик.
• Итоговый отчет: Если эта функция включена, система генерирует итоговый отчет при приостановке или остановке сбора данных, а также при завершении работы службы телеметрии. Этот отчет содержит данные, агрегированные к этому моменту, что помогает гарантировать отсутствие потери данных по завершении сессии.

Управление жизненным циклом сбора данных

По умолчанию конфигурация метрик начинает сбор и обработку данных сразу после активации клиентом и продолжается до тех пор, пока не будет деактивирована клиентом. Однако вы можете более детально управлять этим жизненным циклом, определяя триггеры, которые запускают или останавливают сбор данных или настройку метрик:

• Триггер запуска: Если задан, сбор данных начинается только при срабатывании этого триггера. Если сбор данных был приостановлен триггером остановки, триггер запуска возобновляет его.
• Триггер остановки: Если задан, этот триггер приостанавливает сбор данных. Агрегирование и генерация отчетов прекращаются до тех пор, пока снова не сработает триггер запуска.
• Deactivate trigger: This trigger deactivates the metrics configuration the same way a deactivate_metrics_config call from the client would.

Например, можно определить условный триггер, который срабатывает при изменении vehicle_state на DRIVING (начальный триггер), и другой, который срабатывает при изменении vehicle_state на PARKED (конечный триггер). Это помогает гарантировать сбор данных только во время движения транспортного средства.