Одним из первых и главных этапов работы с Wialon является настройка датчиков в объекте. В данной статье будет детально рассмотрена валидация датчиков, так как она имеет неочевидные варианты использования и позволяет выполнять уникальные действия с датчиками.
Общий принцип работы датчиков
Wialon поддерживает множество типов трекеров (актуальное количество можно найти на сайте wialon.com в разделе Оборудование), и каждый из них «говорит» на своем «языке». Поэтому параметры, которые приходят от разных трекеров и отображаются на вкладке Сообщения, могут содержать одну и ту же информацию (например, о температуре или пробеге), но при этом иметь разные имена. Чтобы пользователь не замечал различий при использовании объектов с разными типами трекеров, для каждого объекта в Wialon необходимо создать датчики. Датчики имеют определенный тип, что позволяет системе понимать, какой алгоритм необходимо использовать для обработки приходящих параметров.
Однако зачастую просто выбрать тип датчика и указать в нем параметр оказывается недостаточно. Для преобразования значения параметра в нужный вид существуют 3 метода:
- Выражение в строке Параметр;
- Таблица расчета;
- Валидация.
Их можно использовать по отдельности или комбинировать. Если использовать несколько методов одновременно, то они будут применяться именно в том порядке, в котором они перечислены выше.
Когда используется валидация
Валидация используется в тех случаях, когда необходимо связать значение одного датчика с другим. С точки зрения практического применения можно выделить следующие случаи для использования валидации:
- один датчик влияет на другой на физическом уровне (например, датчик уровня топлива показывает неправильное значение при скачке показаний датчика напряжения);
- необходимо связать несколько датчиков в логическую схему (например, необходимо создать датчик открытия передних дверей автомобиля, который будет включен, когда включен либо датчик открытия левой двери, либо датчик открытия правой двери);
- необходимо отобразить отчет за интервал времени, в начале которого использовался старый датчик с одним параметром, а в конце — новый датчик с другим параметром (например, ранее на грузовике использовался менее точный ДУТ с одной тарировочной таблицей, а потом его заменили на более точный ДУТ с другой тарировочной таблицей);
- имеется несколько датчиков, измеряющих один и тот же показатель, и необходимо показывать значение одного или другого датчика (например, на машине имелся менее точный встроенный ДУТ, в дополнение к нему установили более точный ДУТ, и обычно используются показания второго, но если в них возникает ошибка, то лучше показать значение первого датчика, пусть они и менее точные);
- параметр содержит информацию о разных системах объекта, и из него необходимо извлечь только определенную часть (например, первые 5 битов параметра сообщают о напряжении, а последующие имеют другое назначение, и из параметра нужно извлечь только те биты, которые связаны с напряжением);
- необходимо провести какие-то арифметические вычисления, которые включают значения нескольких датчиков (например, требуется в реальном времени видеть расход топлива км/л, который вычисляется делением показания относительного одометра на показания датчика мгновенного расхода топлива).
Типы валидации
В Wialon существует 12 типов валидации. Вы не увидите такого разделения в интерфейсе мониторинга, но для упрощения все типы можно условно разделить на 3 группы.
| Группа | Типы валидации | Комментарий | Альтернативы |
|---|---|---|---|
| Арифметическая |
| Без этих типов можно легко обойтись. | Имеются, и они простые. |
| Алгоритмическая |
| Оба типа используются часто. | Для второго типа имеется простая альтернатива. |
| Логическая |
| Наименее понятные типы, из которых в основном используются только первые два. | Имеются, но они непростые. |
Арифметическая валидация
Данная группа включает в себя простые арифметические операции: сложение, вычитание, умножение и деление.
Без этих типов валидации можно легко обойтись, так как достичь аналогичного результата можно с помощью выражения в строке Параметр. Чтобы обратиться к значению другого датчика в выражении, нужно указать имя этого датчика в квадратных скобках (например, [Уровень топлива]).
В следующем примере рассмотрена небольшая разница между этими подходами.
Предположим, что от объекта приходят сообщения, в которых присутствуют следующие параметры:
- odometer — отображает расстояние в километрах, пройденное между двумя последними сообщениями;
- fuel_consumption — отображает топливо в литрах, потраченное между двумя последними сообщениями.
Клиенту нужен датчик, который будет в реальном времени показывать расход в км/л.
Вариант решения через валидацию:
- Создать Датчик мгновенного расхода топлива с именем ДМРТ, основанный на параметре fuel_consumption.
- Создать Произвольный датчик с именем Расход и единицами измерения км/л. В качестве параметра указать odometer. В свойствах датчика Расход указать датчик ДМРТ в качестве валидатора и выбрать тип валидации Делить датчик на валидатор.
Вариант решения через выражение:
- Создать датчик с типом Относительный одометр с именем Относительный пробег, основанный на параметре odometer.
- Создать Датчик мгновенного расхода топлива с именем ДМРТ, основанный на параметре fuel_consumption.
- Создать Произвольный датчик с именем Расход и единицами измерения км/л. Использовать формулу с именами созданных ранее датчиков в квадратных скобках: [Относительный пробег]/[ДМРТ].
Как несложно заметить, при использовании валидации достаточно создать не 3, а только 2 датчика, но в таком случае ни один датчик не будет показывать значение пробега между сообщениями. Однако если для решения каких-то других задач вам потребуется создать датчик с типом Относительный одометр, то в таком случае решение с использованием выражения будет более удобным.
Алгоритмическая валидация
Данная группа включает в себя всего 2 типа валидации, каждый из которых заслуживает рассмотрения.
Проверка на неравенство нулю
Этот тип валидации является одним из самых используемых. Он позволяет игнорировать ошибочные показания валидируемого датчика, факт наличия которых определяется по нулевому значению датчика-валидатора.
Наиболее частой ситуацией применения является следующая: подключенный к трекеру датчик может показывать неправильные данные при недостаточном напряжении.
Предположим, что в объекте созданы следующие датчики:
- Датчик уровня топлива с именем ДУТ, основанный на параметре fuel_lvl;
- Датчик напряжения с именем Напряжение, основанный на параметре pwr_ext.
Когда значение датчика напряжения падает ниже 9 вольт, аналоговый датчик уровня топлива показывает ошибочные значения. Для корректного контроля топлива необходимо избавиться от ложных показаний.
В таком случае необходимо:
- Создать Произвольный цифровой датчик с именем Достаточное напряжение на основе выражения [Напряжение].
- Добавить к нему таблицу расчета со следующими строками:
X=0; a=0; b=0
X=9; a=0; b=1
- В свойствах ДУТ указать датчик Достаточное напряжение в качестве валидатора и выбрать тип валидации Проверка на неравенство нулю.
Теперь при напряжении ниже 9 вольт датчик Достаточное напряжение будет иметь значение 0 (Выкл), следовательно, проверка на неравенство нулю не будет пройдена, из-за чего показания ДУТ будут заменены на прочерк (N/A). Это позволит исключить ошибочные данные из анализа.
Заменять датчик валидатором в случае ошибки
Этот тип валидации также является достаточно популярным. Логика его работы проста: если валидируемый датчик имеет ошибочное значение, то оно заменяется на значение датчика-валидатора.
Данный тип подходит для ситуаций, в которых нужно отобразить значение двух датчиков таким образом, будто это один датчик. Обычно причин для этого может быть две: либо старый датчик заменили на новый, а отчеты должны содержать информацию и за интервал работы старого, и за интервал работы нового датчика, либо на объекте одновременно имеется два датчика, но один из них периодически отображает ошибку, и в этот момент нужно показывать значение другого датчика. Рассмотрим оба случая на примерах.
Предположим, что в рамках интервала отчета от объекта приходили сообщения, в которых присутствовали следующие параметры:
- adc1 — отображает уровень топлива в вольтах по ранее установленному датчику уровня топлива (в новых сообщениях параметр отсутствует);
- param4 — отображает уровень топлива в вольтах по новому датчику уровня топлива (в старых сообщениях параметр отсутствует).
Необходимо настроить датчики так, чтобы в отчете можно было отобразить данные о топливе и по старому, и по новому датчику.
В таком случае необходимо:
- Создать Датчик уровня топлива с именем ДУТ (старый), основанный на параметре adc1. В его таблицу расчета необходимо внести старую тарировочную таблицу для конвертации вольт в литры.
- Создать Датчик уровня топлива с именем ДУТ, основанный на параметре param4. В его таблицу расчета необходимо внести новую тарировочную таблицу для конвертации вольт в литры. В свойствах ДУТ в качестве валидатора указать датчик ДУТ (старый) и выбрать тип валидации Заменять датчик валидатором в случае ошибки.
Предположим, что от объекта приходят сообщения, в которых присутствуют следующие параметры:
- fls_rs485 — отображает уровень топлива в вольтах по установленному датчику уровня топлива;
- fuel_lvl — отображает уровень топлива в литрах по встроенному датчику уровню топлива.
Установленный ДУТ является более точным, но иногда он отображает ошибку, и в этот момент клиент хочет видеть показания встроенного ДУТа.
В таком случае необходимо:
- Создать Произвольный датчик с именем ДУТ встроенный, основанный на параметре fuel_lvl.
- Создать Датчик уровня топлива с именем ДУТ, основанный на параметре fls_rs485. В его таблицу расчета необходимо внести тарировочную таблицу для конвертации вольт в литры. В свойствах ДУТ в качестве валидатора указать датчик ДУТ встроенный и выбрать тип валидации Заменять датчик валидатором в случае ошибки.
Логическая валидация
Данная группа включает 4 типа валидации:
- Логическое И и Логическое ИЛИ — работают с логическими значениями (в Wialon они называются цифровыми — это Вкл/Выкл или 1/0);
- Математическое И и Математическое ИЛИ — работают отдельно с каждым битом чисел.
Рассмотрим эти варианты с примерами.
Логическое И/ИЛИ
Можно сказать, что операция Логическое И выдает значение 1 в качестве результата только в том случае, когда оба значения на входе равны 1, а Логическое ИЛИ — если хотя бы одно из значений на входе равно 1.
Если предположить, что два датчика связаны валидацией, и один из них основан на параметре a, а другой — на параметре b, то все возможные результаты можно описать одной таблицей:
| Таблица истинности | |||
|---|---|---|---|
| a | b | a И b | a ИЛИ b |
0 | 0 | 0 | 0 |
| 0 | 1 | 0 | 1 |
1 | 0 | 0 | 1 |
1 | 1 | 1 | 1 |
Предположим, что от объекта приходят сообщения, в которых присутствуют следующие параметры:
- in3 — равен 0, когда навесное оборудование выключено, или 1, когда оно включено;
- in4 — равен 0, когда задняя дверь закрыта, или 1, когда она открыта.
Необходимо создать датчик, который будет включен, когда навесное оборудование включено и задняя дверь открыта.
В таком случае необходимо:
- Создать Произвольный цифровой датчик с именем Навесное оборудование, основанный на параметре in3.
- Создать Произвольный цифровой датчик с именем Задняя дверь открыта при рабочем оборудовании, основанный на параметре in4. Далее выбрать датчик Навесное оборудование в качестве валидатора и выбрать тип валидации Логическое И.
Предположим, что от объекта приходят сообщения, в которых присутствуют следующие параметры:
- door11 — равен 0, когда левая передняя дверь закрыта, или 1, когда эта дверь открыта;
- door12 — равен 0, когда правая передняя дверь закрыта, или 1, когда эта дверь открыта.
Необходимо создать датчик, который будет включен, когда открыта хотя бы одна из передних дверей автомобиля.
В таком случае необходимо:
- Создать Произвольный цифровой датчик с именем Левая передняя дверь открыта, основанный на параметре door11.
- Создать Произвольный цифровой датчик с именем Открытие передних дверей, основанный на параметре door12. Далее указать датчик Левая передняя дверь открыта в качестве валидатора и выбрать тип валидации Логическое ИЛИ.
Математическое И
Данная валидация бывает полезна для выделения определенной части битов из параметра. Она подразумевает побитовое выполнение операции Логическое И, что продемонстрировано ниже.
Сперва с помощью приложения Калькулятор в режиме программиста или аналогичных онлайн-инструментов необходимо перевести рассматриваемое число из десятичной (DEC) системы счисления в двоичную (BIN).
Например, результат математического И между числами 122 и 15 будет иметь следующий вид:
| DEC | BIN | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| число 1 | 122 | 0 | 1 | 1 | 1 | 1 | 0 | 1 | 0 |
| число 2 | 15 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| результат математического И | 10 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
Если во втором числе бит равен 0 (выделено красным), то в результате этот бит также будет равен 0. А если во втором числе бит равен 1 (выделено зеленым), то в результате этот бит будет иметь то же значение, что и в первом числе. Можно сказать, что с помощью двоичного представления числа 15 была осуществлена фильтрация числа 122 таким образом, чтобы оставить в нем только младшие 4 бита.
Предположим, что от объекта приходят сообщения, в которых присутствует 16-битный параметр can_a1, который содержит в себе информацию о разных системах объекта. Исходя из документации трекера в младших 8 битах параметра содержится информация об уровне топлива. Необходимо проверить это и извлечь часть параметра из 8 младших битов, чтобы создать на их основе датчик уровня топлива.
Например, когда 100-литровый бак заполнен на 40%, значение параметра can_a1 может иметь следующие значения:
| DEC | BIN | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 16998 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 |
| 26726 | 0 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 |
| 40806 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 |
| 39014 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 |
Как несложно заметить, значение параметра can_a1 может меняться в десятичном представлении, но при этом младшие 8 битов параметра остаются неизменными (они выделены синим), так как количество топлива в баке не меняется. Если перевести значения младших 8 битов в десятичную систему, то получаем:
(BIN) 0110 0110 = (DEC) 102
А максимально значение, которое можно хранить в 8 битах равно:
(BIN) 1111 1111 = (DEC) 255
С помощью простых арифметических действий проверяем, что 102/255 = 40/100 = 0.4 — из этого можно сделать вывод, что младшие 8 битов параметра действительно соответствуют баку, заполненному на 40%.
Для извлечения первой части параметра необходимо:
- Создать Произвольный датчик с именем Младшие 8 битов на основе параметра const255.
- Создать Датчик уровня топлива с именем ДУТ на основе параметра can_a1. Далее выбрать датчик Младшие 8 битов в качестве валидатора и выбрать тип валидации Математическое И. Также в таблицу расчета датчика необходимо внести тарировочную таблицу для конвертации результата в литры.
Так как в разных сообщениях каждый бит может иметь разные значения, то обозначим младшие биты как b, а старшие — B:
| DEC | BIN | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| can_a1 | B | B | B | B | B | B | B | B | b | b | b | b | b | b | b | b | |
| число 2 | 255 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| результат математического И | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | b | b | b | b | b | b | b | b | |
В итоге с помощью двоичного представления числа 255 была осуществлена фильтрация параметра can_a1 таким образом, чтобы оставить в нем только младшие 8 битов.
Предположим, что от объекта приходят сообщения, в которых присутствует 16-битный параметр can_b2, который содержит в себе информацию о разных системах объекта. Исходя из документации трекера в старших 8 битах параметра содержится информация об уровне топлива. Необходимо проверить это и извлечь часть параметра из 8 старших битов, чтобы создать на их основе датчик уровня топлива.
Например, когда 200-литровый бак заполнен на 60%, значение параметра can_b2 может иметь следующие значения:
| DEC | BIN | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 39282 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 |
| 39262 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 0 |
| 39362 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 |
| 39286 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 0 |
Как несложно заметить, значение параметра can_b2 может меняться в десятичном представлении, но при этом старшие 8 битов параметра остаются неизменными (они выделены синим), так как количество топлива в баке не меняется. Если перевести значения старших 8 битов в десятичную систему, то получаем:
(BIN) 1001 1001 = (DEC) 153
А максимально значение, которое можно хранить в 8 битах равно:
(BIN) 1111 1111 = (DEC) 255
С помощью простых арифметических действий проверяем, что 153/255 = 120/200 = 0.6 — из этого можно сделать вывод, что старшие 8 битов параметра действительно соответствуют баку, заполненному на 60%.
Для извлечения второй части параметра необходимо:
- Создать Произвольный датчик с именем Старшие 8 битов на основе параметра const65280.
- Создать Произвольный датчик с именем Отфильтрованные биты на основе параметра can_b2. Далее выбрать датчик Старшие 8 битов в качестве валидатора и выбрать тип валидации Математическое И.
- Создать Датчик уровня топлива с именем ДУТ на основе выражения [Отфильтрованные биты]/const256. В его таблицу расчета необходимо внести тарировочную таблицу для конвертации результата в литры.
Так как в разных сообщениях каждый бит может иметь разные значения, то обозначим младшие биты как b, а старшие — B:
| DEC | BIN | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| can_b2 | B | B | B | B | B | B | B | B | b | b | b | b | b | b | b | b | |
| число 2 | 65280 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| результат математического И | B | B | B | B | B | B | B | B | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
| результат после деления на 256 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | B | B | B | B | B | B | B | B | |
Смещение битов на несколько разрядов вниз происходит через деление на 2 в степени, которая равная количеству разрядов для смещения. В данном случае это смещение на 8 разрядов, поэтому деление осуществляется на 28 = 256.
В итоге с помощью двоичного представления числа 65280 была осуществлена фильтрация параметра can_b2 таким образом, чтобы оставить в нем только старшие 8 битов, а потом они были превращены в младшие биты с помощью смещения.
Математическое ИЛИ
Данная валидация подразумевает побитовое выполнение операции Логическое ИЛИ, что продемонстрировано ниже.
Сперва с помощью приложения Калькулятор в режиме программиста или аналогичных онлайн-инструментов необходимо перевести рассматриваемое число из десятичной (DEC) системы счисления в двоичную (BIN).
Например, результат математического ИЛИ между числами 122 и 210 будет иметь следующий вид:
| DEC | BIN | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| число 1 | 122 | 0 | 1 | 1 | 1 | 1 | 0 | 1 | 0 |
| число 2 | 210 | 1 | 1 | 0 | 1 | 0 | 0 | 1 | 0 |
| результат математического ИЛИ | 250 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 0 |
Если хотя бы один из битов в первых двух числах равен 1, то в результате этот бит будет равен 1 (выделено зеленым). А если оба бита в первых двух числах равны 0, то в результате этот бит будет равен 0 (выделено красным).
Скачать файл PDF
Скачать документ Word