> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/rule-based-driver-events.md).

# События водителя на основе правил

Как таблица событий водителя на основе правил преобразует правила оповещений в записи о нарушениях вождения и как выполнять к ней запросы.

Преобразование событий Водитель на основе правил регистрирует нарушения Вождение как отдельные записи событий, оцениваемые по правилам оповещений, настроенным в вашей учетной записи. Каждая строка в `processed_common_data.rule_based_driver_events` Обозначает одно нарушение: какое правило его обнаружило, каким оно было типом, когда и где оно произошло и как быстро транспортное средство Движется в тот момент.

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

{% hint style="info" %}

* Пороги для превышения скорости и Стоит с включенным двигателем берутся из ваших собственных правил оповещений, а не из значений по умолчанию на уровне платформы. Два устройства могут выдавать разные события при идентичном Вождение, если к ним применяются разные правила.
* Повторяющиеся аппаратные события одного типа от одного и того же устройства в течение 10 секунд объединяются в одну строку, поскольку устройство может отправлять несколько сигналов для одного инцидента.
* События на основе Акселерометр игнорируются, пока транспортное средство Движется со скоростью ниже 3 км/ч. Это предотвращает ошибочное определение вибрации при погрузке или стоянке как нарушения.
* Все временные метки хранятся в UTC.
  {% endhint %}

## Таблица вывода: processed\_common\_data.rule\_based\_driver\_events

Каждая строка представляет одно обнаруженное нарушение. Таблица индексируется по `device_id`, `device_time`, `rule_id`, и `hw_event_id`.

Несколько столбцов представляют собой денормализованные копии значений, хранящихся в других местах, поэтому для самых распространенных запросов к панели мониторинга не нужны вообще никакие соединения: `Объект_лейбл` берется из записи объекта, а `speed_limit`, `event_comment1`, и `event_comment2` берутся из правила, которое сгенерировало событие.

<table><thead><tr><th width="180">Поле</th><th width="100">Тип</th><th>Описание</th></tr></thead><tbody><tr><td><code>device_id</code></td><td>integer</td><td>Идентификатор устройства.</td></tr><tr><td><code>object_id</code></td><td>integer</td><td>Идентификатор объекта (транспортного средства или актива), связанный с устройством на момент события.</td></tr><tr><td><code>Объект_лейбл</code></td><td>текст</td><td>Человекочитаемое имя объекта. Уже денормализовано в эту таблицу, поэтому соединение с <code>raw_business_data.objects</code> не требуется.</td></tr><tr><td><code>device_time</code></td><td>метка времени</td><td>Временная метка события, в UTC.</td></tr><tr><td><code>rule_id</code></td><td>integer</td><td>Правило контроля событий, которое сгенерировало событие. Ссылается на <code>raw_business_data.rules</code>. Установлено в <code>0</code> для <code>Обороты двигателя превышены</code> события, которые не определяются правилами. См. <a href="#how-rules-shape-the-output">Как правила формируют результат</a>.</td></tr><tr><td><code>event_type</code></td><td>текст</td><td>Категория нарушения. Одно из четырех значений. См. <a href="#violation-types">Типы нарушений</a> ниже.</td></tr><tr><td><code>hw_event_id</code></td><td>integer</td><td>Код аппаратного события для нарушений, выявленных Акселерометром и датчиком. <code>0</code> для <code>ускорение</code> и <code>Стоит с включенным двигателем_soft</code>, которые вычисляются, а не передаются устройством.</td></tr><tr><td><code>event_comment1</code></td><td>текст</td><td>Свободный текстовый ярлык, скопированный из правила. Устанавливается при настройке правила и полезен для группировки событий по вашим собственным категориям. Null для <code>Обороты двигателя превышены</code>.</td></tr><tr><td><code>event_comment2</code></td><td>текст</td><td>Второй свободный текстовый ярлык, скопированный из правила. Null для <code>Обороты двигателя превышены</code>.</td></tr><tr><td><code>speed_limit</code></td><td>integer</td><td>Порог, настроенный в правиле, денормализованный из <code>raw_business_data.rules</code>. Для <code>ускорение</code> правил это ограничение скорости в км/ч; для <code>Стоит с включенным двигателем_soft</code> правил это допустимое время работы на холостом ходу в минутах.</td></tr><tr><td><code>speed_kmh</code></td><td>numeric</td><td>Скорость транспортного средства в момент события, в км/ч.</td></tr><tr><td><code>duration_sec</code></td><td>integer</td><td>Длительность нарушения в секундах для типов событий, которые длятся некоторое время, а не происходят мгновенно.</td></tr><tr><td><code>zone_id</code></td><td>integer</td><td>Зона, в которой произошло событие, когда правило ограничено конкретными зонами. Null, когда к правилу не привязаны зоны, а также когда правило настроено срабатывать вне своих зон. См. <a href="#zone-scoping">Ограничение по зонам</a>.</td></tr><tr><td><code>zone_label</code></td><td>текст</td><td>Человекочитаемое название Зона, денормализованное вместе с <code>zone_id</code>.</td></tr><tr><td><code>latitude</code></td><td>double precision</td><td>Широта в градусах.</td></tr><tr><td><code>longitude</code></td><td>double precision</td><td>Долгота в градусах.</td></tr><tr><td><code>extra_value</code></td><td>numeric</td><td>Контекстно-зависимое измерение, задаваемое для типов событий, которые фиксируют значение, отличное от скорости. Для <code>Обороты двигателя превышены</code> событий, значение Обороты двигателя, которое вызвало событие.</td></tr><tr><td><code>created_at</code></td><td>метка времени</td><td>Когда строка была записана функцией обновления. Позже, чем <code>device_time</code> максимум на длину одного цикла обновления.</td></tr></tbody></table>

### Типы нарушений

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

<table><thead><tr><th width="150">значение event_type</th><th width="230">Что это означает</th><th width="150">hw_event_id</th><th>Порог</th></tr></thead><tbody><tr><td><code>ускорение</code></td><td>Транспортное средство превысило ограничение скорости, установленное в правиле</td><td><code>0</code></td><td>По правилу, в км/ч</td></tr><tr><td><code>агрессивное_Вождение</code></td><td>Акселерометр или аппаратное событие, сообщаемое устройством: Ускорение, торможение, повороты, смена полосы движения и нарушения ремня безопасности</td><td><code>900</code>, <code>931</code>, <code>987</code>–<code>991</code>, <code>996</code></td><td>Обнаруживается устройством. Игнорируется ниже 3 км/ч</td></tr><tr><td><code>Стоит с включенным двигателем_soft</code></td><td>Транспортное средство стоит, при этом Зажигание включено дольше, чем разрешает правило</td><td><code>0</code></td><td>На правило, в минутах</td></tr><tr><td><code>Обороты двигателя превышены</code></td><td>Обороты двигателя выше порога платформы</td><td><code>9002</code></td><td>Зафиксировано на уровне 5,000 Обороты двигателя</td></tr></tbody></table>

{% hint style="warning" %}
Этот `event_type` значения, а также `hw_event_id` нумерация, отличается от таблицы событий эффективности Водитель, которую заменяет эта трансформация. Запросы, написанные для старой таблицы, нужно обновить значения фильтров, а не только имя таблицы. В частности, нарушения ремня безопасности больше не имеют собственного типа события: они приходят как `агрессивное_Вождение` с `hw_event_id = 931`.
{% endhint %}

Приведенные ниже примеры показывают типовые шаблоны запросов. Базовый запрос возвращает недавние нарушения, отсортированные по устройству и времени. Второй добавляет определение правила для каждого события. Третий фильтрует только аппаратно обнаруженное Опасное вождение.

{% tabs %}
{% tab title="Базовый запрос" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    Объект_label,
    device_time,
    event_type,
    speed_kmh,
    ограничение скорости,
    широта,
    longitude
ИЗ processed_common_data.rule_based_driver_events
WHERE device_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY device_id, device_time;
```

{% endcode %}
{% endtab %}

{% tab title="С подробностями правила" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    e.device_id,
    e.object_label,
    e.device_time,
    e.event_type,
    e.speed_kmh,
    e.speed_limit,
    e.event_comment1,
    r.maximum AS rule_threshold
FROM processed_common_data.rule_based_driver_events e
LEFT JOIN raw_business_data.rules r
    ON r.rule_id = e.rule_id
WHERE e.device_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY e.device_id, e.device_time;
```

{% endcode %}

Используйте `LEFT JOIN` а не inner join. `Обороты двигателя превышены` события содержат `rule_id = 0` и не иметь соответствующей строки в `raw_business_data.rules`, так что внутреннее соединение молча отбрасывает их.
{% endtab %}

{% tab title="Только опасное вождение" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    Объект_label,
    device_time,
    hw_event_id,
    speed_kmh
ИЗ processed_common_data.rule_based_driver_events
WHERE event_type = 'harsh_driving'
  AND device_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY device_id, device_time;
```

{% endcode %}

Фильтрация по одному `event_type` значение заменяет длинное `в` укажите предыдущую таблицу, поскольку теперь все нарушения Акселерометра и оборудования относятся к одной категории. Разделите их с помощью `hw_event_id` когда вам нужен отдельный маневр.
{% endtab %}
{% endtabs %}

## Как правила формируют результат

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

{% stepper %}
{% step %}

#### Правило задает порог

Каждое правило хранит свой порог в `raw_business_data.rules.maximum`: скорость в km/h для `ускорение` правил, длительность в минутах для `Стоит с включенным двигателем_soft` правил. Преобразование копирует это значение в `speed_limit` в каждой строке, которую она записывает, так что вы можете видеть, по чему было измерено транспортное средство, без повторного соединения с правилом.
{% endstep %}

{% step %}

#### Правило задает область действия

Правило применяется к объектам, связанным с ним через `rules2objects`, а при необходимости и к геозонам, связанным через `rules2zones`. Устройство вне списка объектов правила не создает событий для этого правила, независимо от того, как оно управляется.
{% endstep %}

{% step %}

#### Правило предоставляет собственные метки

`event_comment1` и `event_comment2` являются текстовыми полями свободного ввода, заполняемыми при настройке правила. Они копируются в каждое событие, чтобы панели мониторинга могли отображать вашу собственную терминологию без соединения.
{% endstep %}

{% step %}

#### Функция обновления оценивает окно

Каждые 15 минут, `refresh_rule_based_Водитель_events` повторно просматривает 40-минутное окно недавних данных и записывает любые подходящие события. Окно намеренно длиннее интервала, поэтому записи, которые поступают на платформу с опозданием, все еще будут захвачены при следующем проходе.
{% endstep %}

{% step %}

#### Обороты двигателя — это исключение

`Обороты двигателя превышены` События не основаны на правилах. Они используют фиксированный порог платформы 5,000 Обороты двигателя, содержат `rule_id = 0`, и не имеют `event_comment1` или `event_comment2` значения.
{% endstep %}
{% endstepper %}

### Ограничение по зонам

Когда к правилу привязаны геозоны через `rules2zones`, эти зоны определяют и то, будет ли зафиксировано событие, и `zone_id` заполняется. Геометрия зоны считывается из `processed_common_data.zones_geom`, материализовано из `raw_business_data.zones`.

<table><thead><tr><th width="260">Настройка правила</th><th width="200">Записанные события</th><th>Значение zone_id</th></tr></thead><tbody><tr><td>Геозоны не привязаны</td><td>Везде</td><td>NULL</td></tr><tr><td>Геозоны привязаны, <code>zone_inverted = false</code></td><td>Только внутри геозон</td><td>Геозона, в которой произошло событие</td></tr><tr><td>Геозоны привязаны, <code>zone_inverted = true</code></td><td>Только вне геозон</td><td>NULL</td></tr></tbody></table>

{% hint style="warning" %}
NULL `zone_id` само по себе неоднозначно: это означает либо то, что у правила не было геозон, либо то, что правило срабатывает вне своих геозон. При фильтрации по `WHERE zone_id IS NULL` смешает оба этих случая. Присоедините к `rules2zones` когда вам нужно их различать.
{% endhint %}

<details>

<summary>Фиксированные константы платформы</summary>

Эти значения одинаковы для каждого аккаунта и не настраиваются через правило. Пороги, задаваемые правилом, описаны в [Как правила формируют результат](#how-rules-shape-the-output).

<table><thead><tr><th width="220">Константа</th><th width="160">Значение</th><th>Описание</th></tr></thead><tbody><tr><td>Минимальная скорость для событий, связанных с Акселерометр</td><td>3 km/h</td><td>Нарушения, основанные на Акселерометре, ниже этой скорости игнорируются, чтобы не помечать вибрацию, когда транспорт Стоит или загружается.</td></tr><tr><td>Порог Обороты двигателя</td><td>5,000 Обороты двигателя</td><td>Обороты двигателя должны превышать это значение, чтобы для <code>Обороты двигателя превышены</code> событие было записано.</td></tr><tr><td>Окно дедупликации аппаратных событий</td><td>10 seconds</td><td>Повторяющиеся аппаратные события одного типа от одного и того же устройства в пределах этого окна объединяются в одно.</td></tr><tr><td>Интервал обновления</td><td>15 minutes</td><td>Как часто выполняется функция обновления.</td></tr><tr><td>Окно ретроспективного просмотра</td><td>40 minutes</td><td>На какую глубину каждый запуск повторно анализирует данные, чтобы не пропустить записи, пришедшие с задержкой.</td></tr></tbody></table>

</details>

## Настройка преобразования

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

{% hint style="warning" %}
Функцию обновления, которая заполняет `processed_common_data.rule_based_driver_events` нельзя редактировать напрямую. Пороги, которые не определяются правилом, например нижний порог Акселерометр 3 km/h или лимит 5,000 Обороты двигателя, можно изменить только путем создания параллельного рабочего процесса в Transformation Builder и запланировать его как отдельное преобразование в `processed_custom_data`. Это не изменит таблицу, описанную на этой странице.
{% endhint %}

Если вашему операционному сценарию нужны другие фиксированные пороги, свяжитесь с **<iotquery@navixy.com>** чтобы запросить соответствующий шаблон рабочего процесса. Как только вы получите его, загрузите его в [Конструктор трансформаций](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder.md), скорректируйте соответствующие значения и запланируйте измененный рабочий процесс как пользовательское преобразование.

## Следующие шаги

* [**Общие преобразования**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations.md): Назад к индексу преобразований.
* [**Поездки**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/trips.md): Соседнее преобразование, которое создает записи поездок транспортных средств из необработанных телематических данных.
* [**Агрегация Данные датчиков**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/sensor-data-aggregation.md): Соседнее преобразование, которое агрегирует показания датчиков по временным интервалам.
* [**Слой сырых данных**](/docs/analytics/ru/iot-query/schema-overview/bronze-layer.md): Изучить `Мониторинг_data_core`, `состояния`, и `входы`, исходные таблицы, которые формируют события Водитель на основе правил.
* [**Конструктор трансформаций**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder.md): Узнайте, как создать настроенную версию этого преобразования.
* [**Панель мониторинга рейтинга водителей**](https://github.com/Navixy/navixy-iot-query-dashboard/blob/main/schemas/12-driver-performance-dashboard.md): Использует основанные на правилах события водителя для оценки безопасности вождения для всего автопарка.
* [**Панель мониторинга влияния поведения**](https://github.com/Navixy/navixy-iot-query-dashboard/blob/main/schemas/13-behavior-impact-dashboard.md): Использует события Водитель на основе правил для отслеживания тенденций поведения с течением времени.
* [**Панель мониторинга безопасности и охраны**](https://github.com/Navixy/navixy-iot-query-dashboard/blob/main/schemas/10-premium-safety-security-dashboard.md): Использует события Водитель на основе правил вместе с данными Зона и Поездка.
* [**Панель мониторинга лизинга**](https://github.com/Navixy/navixy-iot-query-dashboard/blob/main/schemas/06-leasing-dashboard.md): Использует запросы по Опасное вождение и обнаружению холостого хода из событий Водитель на основе правил.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://navixy.com/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/rule-based-driver-events.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.