Fleetrun
Hecterra
NimBus
Другие приложения
Wialon для Android/iOS
Logistics
Wialon Local
Wialon Hosting
WiaTag
Configurator
LeaseControl
ru
Содержание
Проблемы при изменении прав доступа на объекты
  • technical_consulting
  • access_rights

Пользователи могут иметь права доступа по отношению к разным элементам: объектам, группам объектов, ресурсам и учетным записям, маршрутам и другим пользователям. В зависимости от имеющихся прав пользователь может видеть и предпринимать какие-то действия в отношении определенного элемента.

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

Наблюдаемая проблема и метод ее решения

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

1. После сокращения прав пользователь все равно имеет более широкие права

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

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

Объект может входить сразу в несколько групп, и в таком случае рекомендуется проверить права пользователя на все эти группы. Список групп, в которые входит объект, отображается на вкладке Группы в свойствах этого объекта.

2. При снятии всех прав на объект отображается ошибка и изменения не применяются

Наиболее вероятно, данный пользователь является создателем объекта. На данный момент забрать у создателя все права на созданный им элемент невозможно. При попытке сделать это будет отображаться ошибка с текстом «Нельзя забрать права доступа у создателя элемента».

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

Мы создали видео о применении инструмента Сменить учетную запись из интерфейса управления (CMS):

3. При расширении прав изменения не сохраняются

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

Для исправления ситуации предоставьте более широкий список прав на объект пользователям, выше по иерархии. После — самому пользователю, которому было необходимо расширить права (то есть пройдите по всей ветке иерархии учетных записей сверху вниз).

Проверить структуру сервиса можно с помощью инструмента Иерархия сервиса в интерфейсе управления (CMS).

4. Права меняются, хотя вы не вносите изменений

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

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

5. Права меняются, хотя никто из пользователей не вносит изменений

Чаще всего такие изменения могут происходить с определенным равным периодом или при определенных условиях. В таком случае причиной является работа Заданий с типом Изменить доступ к объектам или Уведомлений со способом действия Изменить доступ к объектам или Изменить состав групп объектов.

Для исправления проверьте правильность настройки заданий и уведомлений (при необходимости их можно удалить или остановить).

6. Права меняются, хотя пользователи, задания и уведомления не делают этого

В Wialon реализована возможность изменять настройки элементов (в том числе менять права) посредством API-запросов. Такие запросы все равно выполняются от имени конкретного пользователя, при этом вход и выход из системы при помощи API-запроса в некоторое стороннее приложение логируется. Эту информацию можно отследить в свойствах пользователя на вкладке Журнал или в интерфейсе управления (CMS) на вкладке Пользователи в колонке Последний вход.

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

Изменения прав на объект логируются в Журнале (на вкладке Сообщения или в отчете с помощью одноименной таблицы). В колонке Хост будет написано имя пользователя, если изменения внесены вручную или через API-запрос, либо «задание» или «уведомление», если изменения внесены с помощью этого функционала.

Записи из Журнала можно удалять. В таком случае информация об изменении прав отображаться не будет. Если вы предполагаете, что столкнулись с такой ситуацией, пожалуйста, свяжитесь с технической поддержкой Wialon по почте support@wialon.com.

Екатерина Гриб,Инженер Customer Service

Перенос элементов в пределах одного сервиса
  • technical_consulting
  • hierarchy
  • service_structure
  • transferring_units

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

Важность иерархии проявляется к моменту зрелости сервиса, когда его структура уже сформирована. На начальном этапе работы с Wialon проблем может не возникать, но позже выясняется, что созданная структура не является оптимальной. Это приводит к проблемам с управлением правами доступа, общими ресурсами, к ограничениям в работе таких сервисов, как, например, Google-карты и SMS. В подобных случаях стоит исправить структуру и перенести элементы системы в новое место в иерархии.

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

Автоматический перенос

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

Учетные записи

При автоматическом переносе учетные записи переносятся целиком со всем содержимым и сохранением всех взаимосвязей, паролей пользователей, идентификаторов сессий и др. Данный перенос осуществляется с помощью внутренних инструментов Wialon и не доступен в интерфейсе пользователя. Для автоматического переноса учетных записей необходимо отправить запрос на support@wialon.com. Автоматический перенос учетных записей доступен только для Wialon Hosting.

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

Объекты и сообщения

Для переноса объектов воспользуйтесь инструментом Перенос объектов из одной учетной записи в другую в интерфейсе CMS Manager.

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

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

  • создатель учетной записи, в которую планируется перенос, обладает правом доступа Просмотр элемента и основных свойств в отношении переносимых объектов;
  • для учетной записи, в которую планируется перенос, активированы услуги Объекты и Создание объектов;
  • учетная запись, в которую планируется перенос, не должна быть заблокирована;
  • а также другие условия, указанные в руководстве пользователя.

Ручной перенос

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

Ниже мы рассмотрим инструкции по переносу отдельных элементов системы в пределах одного сервиса.

Учетные записи

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

  • перенос пользователя-создателя;
  • создание новой учетной записи;
  • назначение нужного тарифного плана;
  • перенос содержимого ресурса;
  • перенос остальных элементов, принадлежащих исходной учетной записи — пользователей, объектов, групп объектов, ретрансляторов.

Для переноса учетной записи войдите в интерфейс CMS Manager и следуйте инструкции:

  1. Экспортируйте настройки пользователя-создателя учетной записи в файл WLP (Экспорт в файл Полная копия).
  2. Измените имя учетной записи и ее пользователя-создателя. Например, можно добавить «‎_old»‎ в конце имени.
  3. Создайте копию пользователя-создателя учетной записи. Для этого удерживайте клавишу Ctrl и щелкните по нужному пользователю в списке. При копировании пользователя будут перенесены такие его свойства, как права доступа, адрес электронной почты  то есть те, которые не переносятся при экспорте. В процессе копирования:
    • Введите и подтвердите пароль пользователя. Важно отметить, что пароли пользователей не переносятся. Если у владельца сервиса сохранены текущие пароли, то после переноса пользователям можно установить аналогичные пароли, если же нет, то придется использовать новые.
    • В поле Создатель выберите пользователя-создателя учетной записи, которая должна стать родительской для новой учетной записи.

  4. Импортируйте настройки пользователя из файла WLP.
  5. Создайте новую учетную запись. При создании выберите опцию От имени существующего пользователя и выберите пользователя, созданного в пункте 3.
  6. При необходимости перенесите остальные элементы учетной записи по инструкциям, расположенным ниже в статье.
  7. Убедившись, что все настройки и содержимое учетной записи были перенесено корректно, удалите старую учетную запись с пометкой «‎_old»‎ в имени.

В случае возникновения трудностей необходимо проверить следующие моменты:

  • В учетной записи, из-под которой будут создаваться другие учетные записи, должны быть:
    • включены услуги Создание пользователей, Создание ресурсов, Система управления (CMS Manager);
    • активированы права дилера и назначены тарифные планы.

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

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

Содержимое ресурсов

Ресурс является местом хранения для следующих элементов:

  • геозоны и группы геозон;
  • задания и уведомления;
  • шаблоны отчетов;
  • водители, прицепы, пассажиры, а также группы водителей, прицепов и пассажиров;
  • заявки.

Для переноса доступны все элементы содержимого ресурса, кроме заявок. Перенести можно как полностью все содержимое, так и отдельные элементы. Для переноса:

  1. Экспортируйте содержимое переносимого ресурса в файл WLP, выбрав нужные для переноса элементы.
  2. Импортируйте содержимое ресурса в новый ресурс.

Заявки доступны для экспорта и импорта непосредственно в приложении Logistics.

Назначения водителей, прицепов и пассажиров не переносятся.

Если в настройках экспортированных шаблонов отчетов, уведомлений и заданий используются какие-либо геозоны, объекты, пользователи, шаблоны отчетов и пр., то необходимо будет заново установить данные настройки, так как при создании элементов им будет присвоен новый внутренний ID и старые настройки будут недействительны.

Пользователи

  1. Экспортируйте настройки исходного пользователя в файл WLP (Экспорт в файл → Полная копия).

  2. Переименуйте этого пользователя, например, добавив «_old»‎ к имени.
  3. Создайте копию пользователя. Для этого в CMS Manager удерживайте клавишу Ctrl и щелкните по нужному пользователю в списке. При копировании пользователя будут перенесены такие его свойства, как права доступа и адрес электронной почты, которые не переносятся при экспорте. В процессе копирования:
    • Введите и подтвердите пароль пользователя. Важно отметить, что пароли пользователей не переносятся. Если у владельца сервиса сохранены текущие пароли, то после переноса пользователям можно установить аналогичные пароли, если же нет, то придется использовать новые.
    • В поле Создатель выберите пользователя-создателя учетной записи, которая должна стать родительской для нового пользователя.

  4. Импортируйте настройки пользователя из файла WLP.
  5. Убедившись, что настройки и свойства пользователя перенеслись корректно, удалите старого пользователя с пометкой «_old»‎ в имени.

Группы объектов

  1. Создайте копию группы объектов. Для этого в CMS Manager удерживайте клавишу Ctrl и щелкните по нужной группе объектов в списке.
  2. При копировании группы в поле Создатель выберите пользователя-создателя учетной записи, в которую необходимо выполнить перенос.

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

Ретрансляторы

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

Ретрансляторы нельзя создавать от имени другого пользователя. Поэтому для создания ретранслятора в определенной учетной записи необходимо войти в систему как пользователь-создатель этой учетной записи.

Маршруты

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

Трудности с переносом элементов

При возникновении вопросов по переносу элементов обратитесь в техническую поддержку через почту support@wialon.com. В письме детально опишите возникшую проблему, а также укажите:

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

Кристина Малаховская,Инженер Customer Service

Перенос элементов между сервисами
  • technical_consulting
  • hierarchy
  • service_structure

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

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

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

После переноса рекомендуется выполнить проверку перенесенных элементов.

Автоматический перенос

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

  • переносятся только учетные записи целиком;
  • общее количество переносимых активных объектов от 50 и выше;
  • сервисы должны быть расположены в одном дата-центре;
  • все содержимое сервиса целиком для переноса не доступно;
  • количество объектов в финальном сервисе после переноса не должно превышать рекомендуемое.

Для автоматического переноса учетных записей необходимо отправить запрос на partners@wialon.com.

Ручной перенос

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

Ниже мы рассмотрим инструкции по переносу отдельных элементов системы между сервисами.

Учетные записи

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

  • создание новой учетной записи;
  • перенос пользователя-создателя учетной записи;
  • назначение нужного тарифного плана;
  • перенос содержимого ресурса;
  • перенос остальных элементов, принадлежащих исходной учетной записи — пользователей, объектов, групп объектов, ретрансляторов, маршрутов.

Для переноса учетных записей войдите в интерфейс CMS Manager и следуйте инструкции:

  1. Экспортируйте настройки пользователей-создателей учетных записей в файлы WLP (Экспорт в файлПолная копия). При экспорте настроек сразу нескольких пользователей создается архив с файлами WLP.
  2. Измените названия учетных записей и их пользователей-создателей в исходном сервисе. Например, можно добавить «_old» в конце названия.
  3. Создайте необходимые учетные записи в новом сервисе.
  4. Извлеките файлы из загруженного ранее архива и импортируйте настройки соответствующих пользователей из файлов WLP. Важно отметить, что такие свойства пользователей, как адрес электронной почты, права доступа и пароль, не переносятся при экспорте и их необходимо будет установить заново вручную. Если у владельца сервиса сохранены текущие пароли, то после переноса пользователям можно установить аналогичные пароли, если же нет, то придется использовать новые.
  5. При необходимости перенесите остальные элементы учетной записи по инструкциям, расположенным ниже в статье.

В случае возникновения трудностей необходимо проверить следующие моменты:

  • В учетной записи, из-под которой будут создаваться другие учетные записи, должны быть:
    • включены услуги Создание пользователейСоздание ресурсовСистема управления (CMS Manager);
    • активированы права дилера и назначены тарифные планы.

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

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

Объекты и сообщения

При помощи экспорта/импорта сообщений

  1. Экспортируйте настройки объектов в файл WLP. Если экспортируется сразу несколько элементов, будет загружен архив с файлами WLP.
  2. В исходном сервисе измените ID и номера телефонов, указанные в свойствах объектов. Например, можно добавить к ID «_old», а к номеру телефона лишнюю цифру.
  3. Извлеките файлы из загруженного ранее архива и создайте объекты из файлов WLP.
  4. Экспортируйте сообщения от объектов в исходном сервисе. Используйте формат WLN или WLB.
  5. Импортируйте сообщения в соответствующие  объекты в новом сервисе.

В случае возникновения трудностей необходимо проверить следующие моменты:

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

  • Существует ограничение на размер импортируемого файла/архива — 64 Мбайт. Если экспортированный файл больше 64 Мбайт, необходимо разделить временной интервал для сообщений еще на этапе экспорта и таким образом получить несколько файлов.
  • У пользователя в исходном сервисе должно быть право Экспорт сообщений на объекты, сообщения которых необходимо перенести. А в финальном сервисе — право Импорт сообщений на объекты, в которые необходимо осуществить перенос сообщений.
  • В исходном и финальном сервисах в учетной записи должна быть включена услуга Сообщения.
  • При переносе объектов может потребоваться изменение настроек самого оборудования. Нужные значения IP:port можно посмотреть в настройках объектов на вкладке Основное.
  • Сообщения, полученные в период между изменением изначального ID и созданием нового объекта из файла WLP, могут быть потеряны, если в устройстве нет черного ящика.

При помощи ретрансляции сообщений

  1. Экспортируйте настройки объектов в файлы WLP. Если экспортируется сразу несколько элементов, будет загружен архив с файлами WLP.
  2. Извлеките файлы из загруженного ранее архива и создайте объекты из файлов WLP.
  3. При создании объектов отобразится ошибка с текстом «Не удалось импортировать все или некоторые данные». Данная ошибка возникает из-за конфликта одинаковых ID и номера телефона в исходном и финальном сервисах. Когда откроется окно свойств объекта, необходимо указать тип устойства — Wialon Retranslator, ID — ID объекта в исходном сервисе.
  4. Создайте ретранслятор в исходном сервисе и добавьте в него объекты, сообщения которых должны быть перенесены.
  5. Запустите ретранслятор, так как ретранслятор создается остановленным.
  6. Откройте настройки ретранслятора, активируйте опцию Ретранслировать данные за прошедший период и укажите необходимый период.
  7. Когда ретрансляция данных за прошедший период завершится, измените ID и номер телефона объектов в исходном сервисе. Например, добавьте к ID «_old», а к номеру телефона лишнюю цифру.
  8. Импортируйте повторно файлы WLP, при импорте выберите пункт Конфигурация устройства. Повторный импорт необходим для указания корректного типа устройства и номера телефона объектов в новом сервисе.

В случае возникновения трудностей необходимо проверить следующие моменты:

  • Если ретрансляции недоступна, проверьте, включена ли услуга Ретрансляторы для текущей и вышестоящих учетных записей.
    В случае если ретрансляции недоступна и нет доступа к вышестоящей учетной записи, необходимо обратиться к поставщику услуг мониторинга.
  • Для добавления объектов в ретрансляторы пользователь должен обладать правом Использование объекта в уведомлениях, заданиях, маршрутах, ретрансляторах в отношении этих объектов.
  • При ретрансляции с Wialon Hosting на Wialon Hosting в качестве адреса сервера используется специальная запись, различная для каждого дата-центра: 
    • hosting.wialon.com — hw.sig;
    • hosting.wialon.eu — hw.tig;
    • hosting.wialon.us — hw.usa;
    • hosting.wialon.ru, hosting.wialon.org — hw.tms.
      Если необходимо уточнить, в каком дата-центре находится ваш сервис, обратитесь в техническую поддержку по адресу support@wialon.com.

  • При переносе объектов может потребоваться изменение настроек самого оборудования. Нужные значения IP:port можно посмотреть в настройках объектов на вкладке Основное.
  • Сообщения, полученные в период между изменением изначального ID и указанием корректного типа устройства в новом сервисе, могут быть потеряны, если в устройстве нет черного ящика.

Содержимое ресурсов

Ресурс представляется из себя место, в котором хранятся следующие элементы:

  • геозоны и группы геозон;
  • задания и уведомления;
  • шаблоны отчетов;
  • водители, прицепы, пассажиры, а также группы водителей, прицепов и пассажиров;
  • заявки.

Перенести можно как полностью все содержимое, так и отдельные элементы. Для выполнения переноса необходимо:

  1. Экспортировать содержимое ресурсов в исходном сервисе в файлы WLP, выбрав нужные для переноса элементы.
  2. Импортировать содержимое ресурсов из файлов WLP в новый сервис.

Заявки доступны для экспорта и импорта непосредственно в приложении Logistics.

Назначения водителей, прицепов и пассажиров не переносятся.

Если в настройках экспортированных шаблонов отчетов, уведомлений и заданий используются какие-либо геозоны, объекты, пользователи, шаблоны отчетов и пр., то необходимо будет заново установить данные настройки, так как при создании элементов им будет присвоен новый внутренний ID и старые настройки будут недействительны.

Пользователи

  1. Экспортируйте настройки пользователей в файлы WLP (Экспорт в файл → Полная копия). При экспорте настроек сразу нескольких пользователей загружается архив с файлами WLP.
  2. Переименуйте пользователей в исходном сервисе, например, добавив «_old»‎ к имени.
  3. Создайте пользователей в новом сервисе.
  4. Извлеките файлы из загруженного ранее архива и импортируйте настройки соответствующих пользователей. Важно отметить, что такие свойства пользователей, как адрес электронной почты, права доступа и пароль, не переносятся при экспорте и их необходимо будет установить заново вручную. Если у владельца сервиса сохранены текущие пароли, то после переноса пользователям можно установить аналогичные пароли, если же нет, то придется использовать новые.

Группы объектов

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

Ретрансляторы

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

Ретрансляторы нельзя создавать от имени другого пользователя. Поэтому для создания ретранслятора в определенной учетной записи необходимо войти в систему как пользователь-создатель этой учетной записи.

Маршруты

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

Проверка после переноса

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

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

Удалять элементы из исходного сервиса стоит только после проверки корректности переноса всех элементов, их настроек и связей.

Кристина Малаховская,Инженер Customer Service

Как выбрать параметр датчика
  • technical_consulting
  • sensor_parameters
  • sensor_types

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

Общие рекомендации

  1. Список параметров и их описание можно найти на странице конкретного устройства на сайте wialon.com в разделе Оборудование. Для этого введите в строку Поиск оборудования нужную модель устройства. Также можно выбрать одну из категорий типов оборудования и найти нужную модель в списке. После на странице оборудования перейдите на вкладку Параметры (пример такой страницы для WiaTag).

    Если на странице оборудования отсутствует описание параметров, обратитесь к специалистам по оборудованию через почту hw@wialon.com.
  2. В большинстве случаев понять содержание параметра можно по его английскому наименованию. Например, в параметре fuel_lvl наиболее вероятно будет отображаться значение уровня топлива, в параметре total_mileage — значения датчика пробега, и т.д. Наименования параметров, полученных из CAN-шины, обычно начинаются с префикса can

  3. Параметры, которые передает устройство, могут быть описаны в документации к оборудованию. Документация, как правило, представлена на сайте производителя.

  4. Существует список виртуальных параметров, которые определены в системе по умолчанию и подходят практически для любого типа оборудования:
    • speed — скорость движения;
    • altitude — высота над уровнем моря;
    • sats — количество спутников;
    • course — курс (направление движения);
    • lat — географическая широта;
    • lon — географическая долгота;
    • time — UNIX-время сообщения;
    • regtime — время регистрации сообщения на сервере.

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

Датчик зажигания

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

Датчик зажигания не отображает положение ключа зажигания «ACC», при котором двигатель не заведен, но дополнительное оборудование уже доступно для использования.

В качестве параметра для Датчик зажигания может подойти один из цифровых входов (в конце сообщений параметр формата I/O). I/O описывает состояние всех цифровых входов и выходов одновременно, и по нему можно определить состояние конкретного цифрового входа inN (логика выбора номера входа N описана в другой статье).

Также можно попробовать создать датчик зажигания на основе параметра, отображающего внешнее напряжение (обычно он называется pwr_ext). В таком случае в свойствах датчика необходимо создать Таблицу расчета. В руководстве пользователя приведен пример такой таблицы. При использовании данного примера нужно лишь изменить пороговое значение напряжения, при достижении которого зажигание будет считаться включенным.

Практический метод выбора и проверки параметра

  1. Выключите двигатель и дождитесь получения нескольких сообщений от трекера.
  2. Включите двигатель и дождитесь поступления еще нескольких сообщений.
  3. Сравните сообщения, полученные в пункте 1 и 2. Если скачкообразно изменился только один параметр, то наиболее вероятно, что он и будет показывать состояние зажигания. Если изменилось несколько параметров, то выбрать нужный можно с помощью дополнительной проверки, описанной в следующем пункте.
  4. Изучите сообщения с ненулевой скоростью. Предполагается, что зажигание включено при наличии скорости, а также в нескольких сообщениях до и после наличия скорости. При этом рекомендуется рассматривать интервалы длительностью хотя бы от пяти минут, так как некоторые трекеры могут менять режим отправки сообщений после начала и завершения движения.
 Пример

От объекта поступили сообщения со следующими параметрами:


Скоростьparam1param2param3
15526.00301000
25626.00401020
35726.00511015
4026.00611004
5026.0071476
6026.0080489
71026.00901001
81126.01011004

Предположим, что зажигание у объекта было выключено в 5-м и 6-м сообщении (выделены красным цветом). В остальных сообщениях зажигание включено (выделены зеленым цветом).

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

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

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

Датчики для учета пробега

На данный момент в Wialon существует два датчика для учета пробега:

  • Датчик пробега отображает весь пробег объекта с момента установки датчика.
  • Относительный одометр отображает пробег между рассматриваемым и предыдущим сообщениями.

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

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

Практический метод выбора и проверки параметра

Чтобы проверить, правильно ли выбран параметр для Датчика пробега или Относительного одометра, можно использовать инструмент Расстояние. Значения параметров и измеренное между двумя сообщениями расстояние чаще всего не совпадает полностью, но являются соизмеримыми. Это связано с тем, что инструмент Расстояние математически рассчитывает расстояние между двумя точками с выбранными координатами, а датчики, как правило, считают пройденные километры, исходя из количества вращений колеса и его диаметра.

Параметр можно использовать в Датчике пробега, если

  • его значение не изменяется, когда объект стоит;
  • его значение увеличивается при движении объекта;
  • разница его значений в двух соседних сообщениях соизмерима со значением, полученным при использовании инструмента Расстояние.

Параметр можно использовать в Относительном одометре, если

  • он равен нулю, когда объект стоит;
  • он имеет положительное значение, когда объект движется;
  • он имеет приблизительно равные значения, когда объект движется с одинаковой скоростью;
  • его значение соизмеримо со значением, полученным при использовании инструмента Расстояние.
 Пример

От объекта поступили сообщения со следующими параметрами:

Создайте Датчик пробега на основе параметра mileage, так как он постоянно растет в движении и не падает до нуля во время остановки.

Создайте Относительный одометр на основе параметра odo, так как он имеет разные значения в движении и падает до нуля во время остановки. Однако его значение кажется слишком большим, поэтому попробуйте применить формулу odo/const1000.

Измерьте пробег объекта между несколькими парами сообщений при помощи инструмента Расстояние, расположив измеряемые отрезки поверх трека.

Сравните полученные значения:

Датчик пробегаОтличие от предыдущего значения по датчику пробегаОтносительный одометрИнструмент Расстояние
16801.54 км1.00 км
26802.52 км6802.52 - 6801.54 = 0.98 км1.00 км1.000 км
36803.51 км6803.51 - 6802.52 = 0.99 км1.00 км1.020 км
46804.00 км6804.00 - 6803.51 = 0.49 км0.50 км0.500 км
56804.20 км6804.20 - 6804.00 = 0.20 км0.50 км0.160 км
66804.20 км6804.20 - 6804.20 = 0.00 км0.00 км-

Значения приблизительно равны, а потому можно предположить, что параметры для обоих датчиков выбраны верно.
Обратите внимание, что у разных датчиков может быть разная точность. В таком случае в Счетчике пробега и Детекторе поездок рекомендуется использовать тот датчик, который присылает показания, наиболее близкие к предполагаемым.

Топливные датчики

На данный момент в Wialon существует несколько типов топливных датчиков:

  • Датчик абсолютного расхода топлива (ДАРТ) показывает расход топлива за весь период эксплуатации объекта. Следовательно, для получения данных о расходе за конкретный период используется следующий алгоритм: вычисляется разница показаний датчика в конце и в начале рассматриваемого интервала.
  • Датчик мгновенного расхода топлива (ДМРТ) показывает количество израсходованного топлива с момента предыдущего измерения (сообщения). Следовательно, для получения данных о расходе за конкретный период используется следующий алгоритм: вычисляется сумма показаний датчика во всех сообщениях на рассматриваемом интервале.
  • Импульсный датчик расхода топлива (ДИРТ) — принцип работы этого датчика аналогичен ДМРТ.
  • Датчик уровня топлива (ДУТ) предназначен для расчета количества топлива в баке. По нему можно считать расход, а также контролировать сливы и заправки.
  • Импульсный датчик уровня топлива (ИДУТ), как и предыдущий датчик, предназначен для расчета количества топлива в баке. По нему можно считать расход, а также контролировать сливы и заправки. Отличие от ДУТ заключается в том, что при расчете используются данные из предыдущего сообщения, и разница значений импульсов двух соседних сообщений делится на разницу времени между ними. Данный тип датчика почти не применяется на практике — вместо него большинство пользователей предпочитают обычный ДУТ.

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

Информация о топливе может содержаться в параметрах со следующими именами: fuel_lvlfuel_usedcons_totalcan_fuelrs485_llsadc1adc2 и т.п.

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

ДАРТ

Параметр можно использовать в Датчике абсолютного расхода топлива, если

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

ДМРТ и ДИРТ

Параметр можно использовать в Датчике мгновенного расхода топлива или Датчике импульсного расхода топлива, если

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

ДУТ

Параметр можно использовать в Датчике уровня топлива, если

  • его значение не меняется, когда двигатель не работает;
  • его значение постепенно уменьшается, когда двигатель работает;
  • его значение падает быстрее при движении или работе под нагрузкой, чем при остановке или отсутствии нагрузки;
  • его значение колеблется вокруг фактического значения при работе двигателя и движении;
  • его значение резко растет во время заправки.

В отличие от датчиков расхода топлива параметр от ДУТ может вести себя не так, как описано выше, потому что во время остановки или движения может осуществляться слив топлива, объект может двигаться под наклоном, температура может значительно меняться в течение дня, в топливе могут содержаться примеси и т.д. Подробнее о проблемах при контроле топлива и методах их решения можно почитать в разделе Статьи экспертов → Топливо.

Ниже приведен пример графика изменения параметра ДУТ, который захватывает интервалы поездки и заправки.

В некоторых случаях параметр ДУТ ведет себя противоположным образом: при работе двигателя его значение растет, а при заправке — падает. Это отличие будет нивелировано после проведения тарировки бака и внесения ее результатов в Таблицу расчета.

Екатерина Гриб,Инженер Customer Service

Как выбрать номер цифрового входа/выхода (I/O)
  • technical_consulting
  • sensor_parameters

Цифровой вход и цифровой выход являются контактами (пинами разъема), на которые подается напряжение только двух уровней: один из них соответствует включенному состоянию (1, или Вкл), а второй — выключенному (0, или Выкл). Исходя из этого, цифровые входы и выходы используют для подключения к трекеру устройств или схем, которые передают только два возможных состояния. Например, к цифровому входу трекера можно подключить датчик состояния двери, чтобы трекер мог определить, открыта она или нет. А к цифровому выходу трекера можно подключить противоугонное устройство, который будет управляться трекером и блокировать зажигание.

Отмечу, что если клиенту требуется точное числовое значение, то нужен аналоговый разъем. Потому что если, например, для ДУТ использовать цифровой вход, то вы лишь сможете узнать, есть ли в баке топливо или нет.

Количество цифровых входов и выходов на трекере может быть довольно большим (например, у Galileosky 7-го поколения в зависимости от модификации и конфигурации может быть от 6 до 10 цифровых входов). Поэтому у пользователей часто возникает вопрос: к какому цифровому входу или выходу монтажник подключил интересующее клиента устройство? С помощью инструкции ниже вы сможете получить требуемый ответ.

Отображение цифровых входов/выходов

Вначале стоит отметить, что состояние цифровых входов и выходов в Wialon представлено в виде двух шестнадцатеричных чисел (HEX), получаемых из двоичных чисел (BIN), в которых каждому биту соответствует вход/выход с таким же номером. Параметр с этими значениями имеет имя I/O (сокращение от Inputs/Outputs) и содержит в себе два числа, разделенных косой чертой: слева от нее располагается значение, соответствующее состоянию всех входов, а справа — состоянию выходов.

Почему выбрана такая реализация? Давайте разберемся на примере.

Предположим, что к цифровым входам 1, 3, 4 и 7, а также выходам 1, 3, 6 и 8 подключено оборудование. Также предположим, что в рассматриваемом сообщении все упомянутые входы и выходы активированы. Если бы для каждого из них использовался отдельный параметр в сообщении, то вы бы увидели следующее:

in1=1, in2=0, in3=1, in4=1, in5=0, in6=0, in7=1, in8=0, out1=1, out2=0, out3=1, out4=0, out5=0, out6=1, out7=0, out8=1

А в нынешней реализации в Wialon вы увидите следующую запись:

I/O=4D/A5

И очевидная краткость записи в данном случае является ключевым преимуществом.

Определение номера активированного цифрового входа/выхода

Если номер N входа или выхода известен, то соответствующий ему параметр будет иметь вид inN, а параметр выхода — outN. Например, параметр для четвертого входа — это in4, а для выхода — out4.

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

Подбор

При подключении оборудования монтажники чаще всего используют первые входы/выходы. То есть если речь идет про устройство или схему, которые передают информацию трекеру, то проверять стоит in1-in4, а если про устройство или схему, которыми управляет трекер, — out1-out4.

Для поиска нужного входа вы можете создать 4 датчика с типом Произвольный цифровой датчик на основе этих параметров (например, в первом датчике в строке Параметр будет in1, во втором — in2 и так далее). Затем перейдите в панель Сообщения, выберите тип сообщений Сообщения с данными и в меню ниже укажите Значения датчиков. После этого запросите сообщения за интервал, когда оборудование было сперва выключено, а потом включено, чтобы найти момент перехода из состояния Выкл в состояние Вкл в одном из столбцов, каждый из которых соответствует созданному датчику.

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

Математический подход

Если вам неизвестен номер входа/выхода, к которому подключено оборудование, то вы можете воспользоваться следующей инструкцией:

1. Перейдите в панель Сообщения, выберите тип сообщений Сообщения с данными и в меню ниже укажите Исходные данные.
2. Запросите сообщения за интервал, когда оборудование было сперва выключено, а потом включено.
3. После отображения таблицы с сообщениями от трекера обратите внимание на колонку Параметры и найдите там параметр I/O (он расположен в самом конце строки).

Предположим, что в сообщении, где оборудование было выключено, параметр I/O=102/0, то есть цифровые выходы деактивированы (или даже не подключены), а некоторые цифровые входы активированы.

4. Откройте приложение Калькулятор (оно предустановлено на каждом компьютере, либо его аналоги можно найти в интернете) и переключите его в режим Программист (или аналогичный, который позволяет переводить значения из одной системы счисления в другую).
5. Переключите калькулятор на шестнадцатеричную систему счисления (HEX).
6. Введите найденное ранее значение 102.
7. Приложение автоматически (либо по нажатию клавиши ввода) представит вам данное число в разных системах счисления. Нас интересует запись в двоичном виде (BIN), которая состоит только из нулей и единиц.

8. Изучите полученное двоичное число. Учтите, что отсчет номера бита идет справа налево (как и в десятичной системе, где единицы находятся справа, слева от них находятся десятки, потом сотни, тысячи и так далее): 0001 0000 0010
9. Определите номера битов для данного числа (нумерация битов в Wialon начинается с 1):

Номер121110987654321
Значение000100000010

10. Из этой записи можно сделать вывод, что в данном сообщении активированы входы 2 и 9 (то есть in2=1, in9=1), а все остальные входы деактивированы (то есть их значение равно нулю).
11. Теперь найдите сообщение, в котором оборудование было включено. Предположим, что оно содержит параметр I/O=10A/0.
12. Повторите шаги 4-8 для значения 10A.

13. Определите номера битов для данного числа:

Номер121110987654321
Значение000100001010

14. В данном сообщении активированы входы 2, 4 и 9 (то есть in2=1, in4=1 и in9=1).
15. Сравните результаты шагов 10 и 14. Как несложно заметить, они отличаются лишь состоянием параметра in4, то есть в приведенном примере оборудование было подключено ко входу 4.

Использование цифровых входов/выходов

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

При создании датчиков для цифровых входов/выходов больше всего подходят типы из группы Цифровые, так как они подразумевают только два состояния (Вкл и Выкл).

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

Олег Жарковский,Инженер Customer Service

Датчики: объяснение таблицы расчета
  • technical_consulting
  • calculation_table

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

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

Общий принцип работы датчиков

Wialon поддерживает множество типов трекеров (актуальное количество можно найти на сайте wialon.com в разделе Оборудование), и каждый из них «говорит» на своем «языке». Поэтому параметры, которые приходят от разных трекеров и отображаются на вкладке Сообщения, могут содержать одну и ту же информацию (например о температуре или пробеге), но при этом иметь разные имена. Чтобы пользователь не замечал различий при использовании объектов с разными типами трекеров, для каждого объекта в Wialon необходимо создать датчики. Датчики имеют определенный тип, что позволяет системе понимать, какой алгоритм необходимо использовать для обработки приходящих параметров.

Однако зачастую просто выбрать тип датчика и указать в нем параметр оказывается недостаточно, потому что значение параметра приходит в неочевидном для пользователя виде. Например, temp=125 может означать 125°F, 125°C, 12.5°C или вообще −3°C. Для преобразования приходящего параметра в нужный вид существует 3 метода:

  1. Выражение в строке Параметр;
  2. Таблица расчета;
  3. Валидация.

Их можно использовать по отдельности или комбинировать. Если использовать несколько методов одновременно, то они будут применяться именно в том порядке, в котором они перечислены выше.

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

  • Подключенный к трекеру датчик измеряет некоторую физическую величину, которую мы обозначим S.
  • Датчик преобразует эту величину и передает трекеру. От трекера в Wialon приходит параметр X.
  • На основе параметра в Wialon создается датчик. Чтобы получить понятное для пользователя значение Y, в датчике к параметру применяются преобразования f(X).
  • В идеале после преобразований в датчике значение Y=f(X) должно равняться величине S, которая измерялась на первом этапе. Далее Y будет использоваться во всплывающих подсказках, отчетах, уведомлениях и другом функционале Wialon.

Так как в этой статье рассматривается только настройка таблицы расчета в Wialon, то из приведенной выше схемы мы будем обращать внимание лишь на следующие элементы:

Когда используется таблица расчета

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

С точки зрения практического применения можно сказать, что таблица расчета используется

  • для тарировочной таблицы (например для датчиков веса или уровня топлива);

  • для цифровых датчиков на основе аналоговых входных данных (например для датчиков зажигания на основе напряжения);

  • для датчиков на основе кодов, которые описывают разные состояния, но приходят в одном параметре (например device_status=4 означает включение зажигания, а device_status=13 — нажатие тревожной кнопки и т.д.);

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

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

Другими словами, таблицу расчета стоит использовать, если

  • формула Y=f(X) неизвестна, но на практике были установлены соответствия между некоторыми X и Y;
  • формула Y=f(X) является слишком сложной (например содержит функции sin, cos, log и т.д., которые не поддерживаются в Wialon);
  • формула Y=f(X) имеет разный вид на разных интервалах и не может быть описана одной функцией;
  • необходимо разделить диапазон корректных и ошибочных значений.

Настройка таблицы расчета

Таблица расчета подразумевает работу с самыми простыми линейными функциями. То есть таблица расчета преобразовывает данные в соответствии со следующей формулой: Y=a⋅X+b — это один из вариантов уравнения прямой.

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

Чтобы увидеть график, который соответствует заполненной таблице расчета, нужно нажать на иконку  в верхней части вкладки.

Пары XY

В правой части расположен блок Пары XY. Его заполнения недостаточно для работы таблицы расчета, однако он может упростить ее настройку.

Мы рекомендуем использовать пары XY только для датчиков уровня топлива, чтобы вносить тарировочную таблицу. В иных случаях стоит самостоятельно рассчитывать и вносить значения X, a и b.

Добавлять пары можно как вручную, так и с помощью импорта CSV или TXT файлов (экспорт доступен только в CSV). После заполнения всех строк этого блока необходимо нажать на клавишу Генерировать (подразумевается «Генерировать таблицу расчета на основе пар XY»), что приведет к расчету значений X, a и b в левой части окна.

Каждая из добавленных пар XY соответствует точке на графике. Как вы можете знать, прямую можно провести через 2 точки. Следовательно, если внести 5 пар XY, то на графике получится 4 прямые.

Пары с одинаковым значением X вводить запрещено. Это технически невозможно, так как одному значению X не может соответствовать два или более значения Y. При этом вводить одинаковые значения Y можно.

X — входное значение

Центральный блок вкладки Таблица расчета содержит в себе строки со значениями X, a и b. Каждая из строк соответствует прямой на графике. Значение X в каждой строке означает начало новой прямой, то есть задает интервал, где будут использоваться новые значения a и b.

Последняя строка влияет на все дальнейшие значения до +∞, а первая строка влияет на значения даже до первого указанного X, то есть начиная с ∞. Поэтому писать несколько строк подряд с одинаковыми значениями a и b не имеет смысла.

В качестве примера рассмотрим таблицу со следующими значениями:

Иначе это условие можно записать так:

  • От ∞ до 3 (не включая) применяется уравнение Y=1⋅X-2.
  • От 3 (включая) до 5.5 (не включая) применяется уравнение Y=0⋅X+3.
  • От 5.5 (включая) до +∞ применяется уравнение Y=-0.5⋅X+2.

Пример графика, получаемого при заполнении таблицы расчета

a — коэффициент наклона прямой

При a=0 наклон будет 0°, то есть прямая будет параллельна оси X.
При a=1 наклон будет 45°, то есть чем больше будет коэффициент, тем ближе будет прямая к оси Y.
При a=-1 наклон будет 45°, то есть отрицательные значения этого коэффициента наклоняют прямую вниз, а положительные — вверх.

Пример графика прямой Y=a⋅X с разным коэффициентом наклона

Определить коэффициент наклона прямой бывает довольно просто: его значение равно отношению изменения Y к изменению X.

В качестве примера можно рассмотреть зеленую прямую на графике выше. По ней видно, что Y увеличивается с 0 до 1, когда X растет с 0 до 3, а значит для этой прямой коэффициент a=(1-0)/(3-0)=1/3=0.33.

b — смещение прямой по оси Y

При b=0 смещение отсутствует.
При b>0 смещение прямой происходит вверх относительно оси X.
При b<0 смещение происходит вниз.

Пример линий с разным смещением

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

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

Единственным исключением является случай, когда с помощью таблицы расчета настраивается цифровой датчик. В таком случае a=0, и формула принимает вид Y=b. Следовательно, значение b будет равно тому, что вы ожидаете увидеть в качестве Y.

Нижняя и верхняя границы

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

Рассмотрим пример с датчиком уровня топлива. Предположим, что значения параметра от 3 до 250 соответствуют объему топлива от 0 литров до 100 литров. А значения параметра 0 или 255 означают ошибки, которые мы хотим исключить, чтобы они не интерпретировалось как реальный объем (так как в рассматриваемом баке не может быть меньше 0 или больше 100 литров топлива). Для этого примера можно предложить решение с выключенной опцией Применять после расчета:

Также существует решение с включенной опцией Применять после расчета:

Так как нижняя граница входит в разрешенный диапазон, то мы можем указать значения из условия (3 или 0). Но верхняя граница в разрешенный диапазон не входит, поэтому в этом поле нужно указывать значение чуть больше, чем в условии (250.1 или 100.1).

Из примера можно понять, что опция Применять после расчета влияет на то, к каким значениям применяются границы: если она выключена, то отсеиваются значения по оси X (входные значения до применения таблицы расчета), а если она включена, то отсеиваются значения по оси Y (значения датчика после применения таблицы расчета).

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

Нижняя граница равна 2, верхняя граница равна 3, опция «Применять после расчета» отключена

Нижняя граница равна 2, верхняя граница равна 3, опция «Применять после расчета» включена


Принцип работы таблицы расчета

Иногда, чтобы понять суть явления, следует пойти от обратного. Если нам известна точная формула Y=f(X), которая связывает входное и выходное значения на всем диапазоне, то прибегать к таблице расчета нет необходимости достаточно просто использовать выражение в строке Параметр. Давайте рассмотрим такой случай.

Для примера предположим, что входное значение связано с выходным следующей формулой: Y=0.5⋅X2.
В качестве параметра возьмем adc3. Чтобы описать такую формулу в Wialon, в строку Параметр нужно вставить следующее выражение: const0.5*adc3^const2

График функции Y=0.5⋅X2

Но что делать, если мы не знаем точную формулу Y=f(X)? Именно в таком случае нам поможет таблица расчета.

Предположим, что в определенных условиях мы знаем значения измеряемой величины (это будет Y) и можем проверить, какое значение будет принимать параметр в Wialon в этих точках (это будет X). Таким образом можно получить значения, например, в 4 точках: (0; 0), (1; 0.5), (2; 2), (3; 4.5). Далее нанесем эти точки (X, Y) на график и соединим их отрезками красного цвета.

Воспроизведение части функции Y=0.5⋅X2 отрезками, построенными по 4 точкам

Несложно заметить, что результат близок к тому, который получается по формуле, но все же отличия имеются. В некоторых случаях такой точности будет достаточно, а если ее не хватает, то можно измерить значения в большем количестве точек. На графике ниже приведен пример уже для 6 точек: (0; 0), (0.5; 0.125), (1; 0.5), (1.5; 1.125), (2; 2), (3; 4.5).

Воспроизведение части функции Y=0.5⋅X2 отрезками, построенными по 6 точкам

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

 Математическая минутка

Таблица расчета использует точечную аппроксимацию и линейную интерполяцию.

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

Линейная интерполяция — это расчет значений на участках между изначально известными точками по прямым, которые проходят через эти точки. В Wialon она используется, для вычисления значений в точках, которые находятся между введенными ранее парами XY, по приблизительно воспроизведенной функции.

Обоснование и примеры использования

В данном разделе рассмотрим несколько случаев, в которых таблица расчета будет полезна.

Форма кривой, которая описывает связь между X и Y, может быть довольно сложной.

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

График, построенный по тарировочной таблице с малым шагом между замерами

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

Воспроизведение формы сложной кривой отрезками, проходящими через 11 точек

Также иногда зависимость между X и Y может быть различной на нескольких интервалах. Для ее описания требуется использовать систему из нескольких выражений, что нельзя сделать в строке Параметр в свойствах датчика.

Например, некоторые датчики температуры работают следующим образом: значения X в диапазоне от 0 до 127 соответствуют положительной температуре, а в дипазоне от 128 до 255 — отрицательной. Для обработки подобного случая потребуется две строки в таблице расчета:

X=0; a=1; b=0
X=128; a=1; b=-256

График температуры, на котором более высокие значения параметра
соответствуют отрицательной температуре

Цифровые датчики являются еще одним ярким примером ситуации, когда зависимость между X и Y является различной на нескольких интервалах. Например, датчик зажигания можно создать на основе параметра напряжения, и для этого нужно учесть два условия: Y=0 при X<14, Y=1 при X≥14. Но, как мы уже знаем, сделать это с помощью выражения в свойствах датчика не получится. А на вкладке Таблица расчета для этого потребуется всего две строки:

X=0; a=0; b=0
X=14; a=0; b=1

В цифровых датчиках коэффициент наклона всегда равен 0.

График состояния зажигания в зависимости от напряжения

 Математическая минутка

В статье уже несколько раз упоминалось, что для датчика в идеале нужна формула связи X и Y, а таблицу расчета мы используем из-за отсутствия других вариантов. На самом деле, такую формулу можно попробовать рассчитать, однако для этого нужно иметь представление о численных методах анализа и соответствующее ПО. При этом результат скорее всего будет сложен для понимания и будет плохо поддаваться корректировке в будущем. Чтобы это продемонстрировать, мы рассчитали интерполяционный полином для следующих 7 точек: (0; 5), (400; 8), (1000; 22), (1850; 78), (2800; 160), (3600; 195), (4096; 200).

Результат полиномиальной интерполяции в данном случае имеет следующий вид:

Y=1.78962834270398⋅10-19⋅X6-7.99064624017665⋅10-16⋅X5-4.83816855045549⋅10-12⋅X4+
+2.62803612257704⋅10
-8⋅X3-1.24091655860425⋅10-5⋅X2+8.58707470047479⋅10-3⋅X+5

Эту формулу можно ввести в строку Параметр в свойствах датчика (с учетом синтаксиса Wialon), и она действительно будет рабочей. График такой функции в диапазоне от 0 до 4096 имеет следующий вид:

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

Олег Жарковский,Инженер Customer Service

Датчики: логика и альтернативы валидации
  • technical_consulting
  • sensors
  • validation

Одним из первых и главных этапов работы с Wialon является настройка датчиков в объекте. В данной статье будет детально рассмотрена валидация датчиков, так как она имеет неочевидные варианты использования и позволяет выполнять уникальные действия с датчиками.

Общий принцип работы датчиков

Wialon поддерживает множество типов трекеров (актуальное количество можно найти на сайте wialon.com в разделе Оборудование), и каждый из них «говорит» на своем «языке». Поэтому параметры, которые приходят от разных трекеров и отображаются на вкладке Сообщения, могут содержать одну и ту же информацию (например, о температуре или пробеге), но при этом иметь разные имена. Чтобы пользователь не замечал различий при использовании объектов с разными типами трекеров, для каждого объекта в Wialon необходимо создать датчики. Датчики имеют определенный тип, что позволяет системе понимать, какой алгоритм необходимо использовать для обработки приходящих параметров.

Однако зачастую просто выбрать тип датчика и указать в нем параметр оказывается недостаточно. Для преобразования значения параметра в нужный вид существуют 3 метода:

  1. Выражение в строке Параметр;
  2. Таблица расчета;
  3. Валидация.

Их можно использовать по отдельности или комбинировать. Если использовать несколько методов одновременно, то они будут применяться именно в том порядке, в котором они перечислены выше.

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

Когда используется валидация

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

  • один датчик влияет на другой на физическом уровне (например, датчик уровня топлива показывает неправильное значение при скачке показаний датчика напряжения);

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

  • необходимо отобразить отчет за интервал времени, в начале которого использовался старый датчик с одним параметром, а в конце — новый датчик с другим параметром (например, ранее на грузовике использовался менее точный ДУТ с одной тарировочной таблицей, а потом его заменили на более точный ДУТ с другой тарировочной таблицей);

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

  • параметр содержит информацию о разных системах объекта, и из него необходимо извлечь только определенную часть (например, первые 5 битов параметра сообщают о напряжении, а последующие имеют другое назначение, и из параметра нужно извлечь только те биты, которые связаны с напряжением);

  • необходимо провести какие-то арифметические вычисления, которые включают значения нескольких датчиков (например, требуется в реальном времени видеть расход топлива км/л, который вычисляется делением показания относительного одометра на показания датчика мгновенного расхода топлива).

Типы валидации

В Wialon существует 12 типов валидации. Вы не увидите такого разделения в интерфейсе мониторинга, но для упрощения все типы можно условно разделить на 3 группы.

ГруппаТипы валидацииКомментарийАльтернативы
Арифметическая
  • Суммировать
  • Вычесть валидатор из датчика
  • Вычесть датчик из валидатора
  • Перемножить
  • Делить датчик на валидатор
  • Делить валидатор на датчик
Без этих типов можно легко обойтись.Имеются, и они простые.
Алгоритмическая
  • Проверка на неравенство нулю
  • Заменять датчик валидатором в случае ошибки
Оба типа используются часто.Для второго типа имеется простая альтернатива.
Логическая
  • Логическое И
  • Логическое ИЛИ
  • Математическое И
  • Математическое ИЛИ
Наименее понятные типы, из которых в основном используются только первые два.Имеются, но они непростые.
Рассмотрим каждую из групп более подробно.

Арифметическая валидация

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

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

В следующем примере рассмотрена небольшая разница между этими подходами.

 Пример

Предположим, что от объекта приходят сообщения, в которых присутствуют следующие параметры:

  • odometer — отображает расстояние в километрах, пройденное между двумя последними сообщениями;
  • fuel_consumption — отображает топливо в литрах, потраченное между двумя последними сообщениями.

Клиенту нужен датчик, который будет в реальном времени показывать расход в км/л.

Вариант решения через валидацию:

  1. Создать Датчик мгновенного расхода топлива с именем ДМРТ, основанный на параметре fuel_consumption.
  2. Создать Произвольный датчик с именем Расход и единицами измерения км/л. В качестве параметра указать odometer. В свойствах датчика Расход указать датчик ДМРТ в качестве валидатора и выбрать тип валидации Делить датчик на валидатор.

Вариант решения через выражение:

  1. Создать датчик с типом Относительный одометр с именем Относительный пробег, основанный на параметре odometer.
  2. Создать Датчик мгновенного расхода топлива с именем ДМРТ, основанный на параметре fuel_consumption.
  3. Создать Произвольный датчик с именем Расход и единицами измерения км/л. Использовать формулу с именами созданных ранее датчиков в квадратных скобках: [Относительный пробег]/[ДМРТ].

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

Алгоритмическая валидация

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

Проверка на неравенство нулю

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

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

 Пример

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

  • Датчик уровня топлива с именем ДУТ, основанный на параметре fuel_lvl;
  • Датчик напряжения с именем Напряжение, основанный на параметре pwr_ext.

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

В таком случае необходимо:

  1. Создать Произвольный цифровой датчик с именем Достаточное напряжение на основе выражения [Напряжение].
  2. Добавить к нему таблицу расчета со следующими строками:
    X=0; a=0; b=0
    X=9; a=0; b=1
  3. В свойствах ДУТ указать датчик Достаточное напряжение в качестве валидатора и выбрать тип валидации Проверка на неравенство нулю.

Теперь при напряжении ниже 9 вольт датчик Достаточное напряжение будет иметь значение 0 (Выкл), следовательно, проверка на неравенство нулю не будет пройдена, из-за чего показания ДУТ будут заменены на прочерк (N/A). Это позволит исключить ошибочные данные из анализа.

Использование валидации Проверка на неравенство нулю возможно не только в тех ситуациях, когда датчики связаны друг с другом на физическом уровне (в примере выше на работу датчика влияет недостаточное напряжение), но и в случаях, когда между значениями датчиков наблюдается корреляция. Например, если вы замечаете, что по какой-то причине ДУТ показывает ложные значения, когда датчик температуры показывает значение 255, то этого достаточно, чтобы использовать такой тип валидации.

Заменять датчик валидатором в случае ошибки

Этот тип валидации также является достаточно популярным. Логика его работы проста: если валидируемый датчик имеет ошибочное значение, то оно заменяется на значение датчика-валидатора.

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

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

 Пример 1

Предположим, что в рамках интервала отчета от объекта приходили сообщения, в которых присутствовали следующие параметры:

  • adc1 — отображает уровень топлива в вольтах по ранее установленному датчику уровня топлива (в новых сообщениях параметр отсутствует);
  • param4 — отображает уровень топлива в вольтах по новому датчику уровня топлива (в старых сообщениях параметр отсутствует).

Необходимо настроить датчики так, чтобы в отчете можно было отобразить данные о топливе и по старому, и по новому датчику.

В таком случае необходимо:

  1. Создать Датчик уровня топлива с именем ДУТ (старый), основанный на параметре adc1. В его таблицу расчета необходимо внести старую тарировочную таблицу для конвертации вольт в литры.

  2. Создать Датчик уровня топлива с именем ДУТ, основанный на параметре param4. В его таблицу расчета необходимо внести новую тарировочную таблицу для конвертации вольт в литры. В свойствах ДУТ в качестве валидатора указать датчик ДУТ (старый) и выбрать тип валидации Заменять датчик валидатором в случае ошибки.

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

  1. Создать Датчик уровня топлива с именем ДУТ (старый), основанный на параметре adc1. В его таблицу расчета необходимо внести старую тарировочную таблицу для конвертации вольт в литры.
  2. Создать Датчик уровня топлива с именем ДУТ, основанный на параметре param4|[ДУТ (старый)]. В его таблицу расчета необходимо внести новую тарировочную таблицу для конвертации вольт в литры.
 Пример 2

Предположим, что от объекта приходят сообщения, в которых присутствуют следующие параметры:

  • fls_rs485 — отображает уровень топлива в вольтах по установленному датчику уровня топлива;
  • fuel_lvl — отображает уровень топлива в литрах по встроенному датчику уровню топлива.

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

В таком случае необходимо:

  1. Создать Произвольный датчик с именем ДУТ встроенный, основанный на параметре fuel_lvl.
  2. Создать Датчик уровня топлива с именем ДУТ, основанный на параметре fls_rs485. В его таблицу расчета необходимо внести тарировочную таблицу для конвертации вольт в литры. В свойствах ДУТ в качестве валидатора указать датчик ДУТ встроенный и выбрать тип валидации Заменять датчик валидатором в случае ошибки.

Логическая валидация

Данная группа включает 4 типа валидации:

  • Логическое И и Логическое ИЛИ — работают с логическими значениями (в Wialon они называются цифровыми — это Вкл/Выкл или 1/0);
  • Математическое И и Математическое ИЛИ — работают отдельно с каждым битом чисел.

Рассмотрим эти варианты с примерами.

Логическое И/ИЛИ

Можно сказать, что операция Логическое И выдает значение 1 в качестве результата только в том случае, когда оба значения на входе равны 1, а Логическое ИЛИ — если хотя бы одно из значений на входе равно 1.

Если предположить, что два датчика связаны валидацией, и один из них основан на параметре a, а другой — на параметре b, то все возможные результаты можно описать одной таблицей:

Таблица истинности
aba И ba ИЛИ b

0

000
0101

1

001

1

111

Значение валидируемого датчика после выполнения логических операций И/ИЛИ всегда будет равно 0 или 1 (в данном случае не рассматривается ошибка, то есть прочерк или N/A).

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

  • Только 0 воспринимается как 0 (Выкл).
  • Любое другое числовое значение (например, 0.01, -0.01, 100500, -777 и т. д.) будет восприниматься как 1 (Вкл).

В идеале стоит избегать подобных ситуаций и использовать таблицу расчета, чтобы превратить все входящие значения только в 0 или 1.

 Пример 1

Предположим, что от объекта приходят сообщения, в которых присутствуют следующие параметры:

  • in3 — равен 0, когда навесное оборудование выключено, или 1, когда оно включено;
  • in4 — равен 0, когда задняя дверь закрыта, или 1, когда она открыта.

Необходимо создать датчик, который будет включен, когда навесное оборудование включено и задняя дверь открыта.

В таком случае необходимо:

  1. Создать Произвольный цифровой датчик с именем Навесное оборудование, основанный на параметре in3.

  2. Создать Произвольный цифровой датчик с именем Задняя дверь открыта при рабочем оборудовании, основанный на параметре in4. Далее выбрать датчик Навесное оборудование в качестве валидатора и выбрать тип валидации Логическое И.

Решить эту задачу можно и с помощью выражения в строке Параметр. Для этого достаточно создать Произвольный цифровой датчик с именем Задняя дверь открыта при рабочем оборудовании, основанный на выражении in3*in4.

Данный подход будет работать, если параметры могут принимать только значения 0 или 1.

 Пример 2

Предположим, что от объекта приходят сообщения, в которых присутствуют следующие параметры:

  • door11 — равен 0, когда левая передняя дверь закрыта, или 1, когда эта дверь открыта;
  • door12 — равен 0, когда правая передняя дверь закрыта, или 1, когда эта дверь открыта.

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

В таком случае необходимо:

  1. Создать Произвольный цифровой датчик с именем Левая передняя дверь открыта, основанный на параметре door11.

  2. Создать Произвольный цифровой датчик с именем Открытие передних дверей, основанный на параметре door12. Далее указать датчик Левая передняя дверь открыта в качестве валидатора и выбрать тип валидации Логическое ИЛИ.

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

  1. Создать Произвольный цифровой датчик с именем Открытие передних дверей, основанный на выражении door11+door12.
  2. Добавить к нему таблицу расчета со следующими строками:
    X=0; a=0; b=0
    X=1; a=0; b=1

Данный подход будет работать, если параметры могут принимать только значения 0 или 1.

Математическое И

Данная валидация бывает полезна для выделения определенной части битов из параметра. Она подразумевает побитовое выполнение операции Логическое И, что продемонстрировано ниже.

Сперва с помощью приложения Калькулятор в режиме программиста или аналогичных онлайн-инструментов необходимо перевести рассматриваемое число из десятичной (DEC) системы счисления в двоичную (BIN).

Например, результат математического И между числами 122 и 15 будет иметь следующий вид:


DECBIN
число 112201111010
число 21500001111
результат математического И1000001010

Если во втором числе бит равен 0 (выделено красным), то в результате этот бит также будет равен 0. А если во втором числе бит равен 1 (выделено зеленым), то в результате этот бит будет иметь то же значение, что и в первом числе. Можно сказать, что с помощью двоичного представления числа 15 была осуществлена фильтрация числа 122 таким образом, чтобы оставить в нем только младшие 4 бита.

 Пример 1

Предположим, что от объекта приходят сообщения, в которых присутствует 16-битный параметр can_a1, который содержит в себе информацию о разных системах объекта. Исходя из документации трекера в младших 8 битах параметра содержится информация об уровне топлива. Необходимо проверить это и извлечь часть параметра из 8 младших битов, чтобы создать на их основе датчик уровня топлива.

Например, когда 100-литровый бак заполнен на 40%, значение параметра can_a1 может иметь следующие значения:

DECBIN
169980100001001100110
267260110100001100110
408061001111101100110
390141001100001100110

Как несложно заметить, значение параметра can_a1 может меняться в десятичном представлении, но при этом младшие 8 битов параметра остаются неизменными (они выделены синим), так как количество топлива в баке не меняется. Если перевести значения младших 8 битов в десятичную систему, то получаем:

(BIN) 0110 0110 = (DEC) 102

А максимально значение, которое можно хранить в 8 битах равно:

(BIN) 1111 1111 = (DEC) 255

С помощью простых арифметических действий проверяем, что 102/255 = 40/100 = 0.4 — из этого можно сделать вывод, что младшие 8 битов параметра действительно соответствуют баку, заполненному на 40%.

Для извлечения первой части параметра необходимо:

  1. Создать Произвольный датчик с именем Младшие 8 битов на основе параметра const255.
  2. Создать Датчик уровня топлива с именем ДУТ на основе параметра can_a1. Далее выбрать датчик Младшие 8 битов в качестве валидатора и выбрать тип валидации Математическое И. Также в таблицу расчета датчика необходимо внести тарировочную таблицу для конвертации результата в литры.

Так как в разных сообщениях каждый бит может иметь разные значения, то обозначим младшие биты как b, а старшие — B:


DECBIN
can_a1
BBBBBBBBbbbbbbbb
число 22550000000011111111
результат математического И
00000000bbbbbbbb

В итоге с помощью двоичного представления числа 255 была осуществлена фильтрация параметра can_a1 таким образом, чтобы оставить в нем только младшие 8 битов.

Решить эту задачу можно с помощью выражения в строке Параметр.

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

const128*can_a1:8+const64*can_a1:7+const32*can_a1:6+const16*can_a1:5+const8*can_a1:4+
const4*can_a1:3+const2*can_a1:2+const1*can_a1:1

Подробнее о таком решении можно узнать в статье о работе с битами.

 Пример 2

Предположим, что от объекта приходят сообщения, в которых присутствует 16-битный параметр can_b2, который содержит в себе информацию о разных системах объекта. Исходя из документации трекера в старших 8 битах параметра содержится информация об уровне топлива. Необходимо проверить это и извлечь часть параметра из 8 старших битов, чтобы создать на их основе датчик уровня топлива.

Например, когда 200-литровый бак заполнен на 60%, значение параметра can_b2 может иметь следующие значения:

DECBIN
392821001100101110010
392621001100101011110
393621001100111000010
392861001100101110110

Как несложно заметить, значение параметра can_b2 может меняться в десятичном представлении, но при этом старшие 8 битов параметра остаются неизменными (они выделены синим), так как количество топлива в баке не меняется. Если перевести значения старших 8 битов в десятичную систему, то получаем:

(BIN) 1001 1001 = (DEC) 153

А максимально значение, которое можно хранить в 8 битах равно:

(BIN) 1111 1111 = (DEC) 255

С помощью простых арифметических действий проверяем, что 153/255 = 120/200 = 0.6 — из этого можно сделать вывод, что старшие 8 битов параметра действительно соответствуют баку, заполненному на 60%.

Для извлечения второй части параметра необходимо:

  1. Создать Произвольный датчик с именем Старшие 8 битов на основе параметра const65280.
  2. Создать Произвольный датчик с именем Отфильтрованные биты на основе параметра can_b2. Далее выбрать датчик Старшие 8 битов в качестве валидатора и выбрать тип валидации Математическое И.

  3. Создать Датчик уровня топлива с именем ДУТ на основе выражения [Отфильтрованные биты]/const256. В его таблицу расчета необходимо внести тарировочную таблицу для конвертации результата в литры.

Так как в разных сообщениях каждый бит может иметь разные значения, то обозначим младшие биты как b, а старшие — B:


DECBIN
can_b2
BBBBBBBBbbbbbbbb
число 2652801111111100000000
результат математического И
BBBBBBBB00000000
результат после деления на 256
00000000BBBBBBBB

Смещение битов на несколько разрядов вниз происходит через деление на 2 в степени, которая равная количеству разрядов для смещения. В данном случае это смещение на 8 разрядов, поэтому деление осуществляется на 28 = 256.

В итоге с помощью двоичного представления числа 65280 была осуществлена фильтрация параметра can_b2 таким образом, чтобы оставить в нем только старшие 8 битов, а потом они были превращены в младшие биты с помощью смещения.

Решить эту задачу можно с помощью выражения в строке Параметр.

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

const128*can_b2:16+const64*can_b2:15+const32*can_b2:14+const16*can_b2:13+const8*can_b2:12+
const4*can_b2:11+const2*can_b2:10+const1*can_b2:9

Подробнее о таком решении можно узнать в статье о работе с битами.

Математическое ИЛИ

Данная валидация подразумевает побитовое выполнение операции Логическое ИЛИ, что продемонстрировано ниже.

Сперва с помощью приложения Калькулятор в режиме программиста или аналогичных онлайн-инструментов необходимо перевести рассматриваемое число из десятичной (DEC) системы счисления в двоичную (BIN).

Например, результат математического ИЛИ между числами 122 и 210 будет иметь следующий вид:


DECBIN
число 112201111010
число 221011010010
результат математического ИЛИ25011111010

Если хотя бы один из битов в первых двух числах равен 1, то в результате этот бит будет равен 1 (выделено зеленым). А если оба бита в первых двух числах равны 0, то в результате этот бит будет равен 0 (выделено красным).

Олег Жарковский,Инженер Customer Service

Датчики: работа с битами
  • technical_consulting
  • sensor_parameters

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

Проблематика

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

Например, в Wialon может отображаться параметр user_value = 2646793773, хотя со стороны трекера подразумевалась передача одного из следующих значений:

  • 2646793773 — целое число без знака;
  • 56877 и 40386 — несколько целых чисел;
  • −499310125 — целое число со знаковым разрядом;
  • −5.15811×1021 или 0.00000000000000000000515811 — число с плавающей запятой и т. д.

Теоретически данную проблему можно решить со стороны Wialon через изменение скрипта, который разбирает приходящие от трекера данные. Однако это повлияет на всех пользователей, а у них могут быть разные конфигурации трекеров, то есть они могут ожидать разного результата разбора данных со стороны скрипта. К счастью, существует метод решения проблемы, который подойдет для всех, — создание датчика с нужной формулой. При этом основана она будет на представлении параметра в двоичной системе счисления, так как мы уже знаем, что представление в десятичной системе счисления может быть разным. В двоичном виде значение параметра из примера выше записывается следующим образом: 1001 1101 1100 0010 1101 1110 0010 1101. Теперь давайте разберемся, как работать с двоичной системой счисления.

Теоретическая основа

В данном разделе будет рассмотрена информация, необходимая для применения дальнейших формул.

Системы счисления

В математике используются разные системы счисления. Наиболее привычными для понимания являются позиционные системы счисления, в которых значение каждого знака зависит от его позиции (разряда). Например, в рамках десятичной системы цифра 1, в зависимости от позиции в числе, может означать одну единицу (1), один десяток (10), одну сотню (100) и так далее.

Количество знаков, используемых в позиционных системах счисления, называется основанием.

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

Название

ОбозначениеОснованиеОбласть примененияИспользуемые знаки

Двоичная (binary)

BIN2Дискретная математика, информатика, программирование0, 1

Десятичная (decimal)

DEC10Повсеместно

0, 1, 2, 3, 4, 5, 6, 7, 8, 9

Шестнадцатеричная (hexadecimal)

HEX16Информатика, программирование0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F

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

Числа в Wialon отображаются в десятичной системе счисления. Исключением являются текстовые параметры, в которых может быть записано число (например, шестнадцатеричный код водителя), а также отображение цифровых входов и выходов в формате I/O.

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

Использование разных систем счисления имеет не только исторические или культурные причины, но и практические основания. Непривычная людям двоичная система значительно упрощает математические расчеты для электронных устройств. Также двоичная система удобна с точки зрения простоты распознавания значений при наличии шумов, так как отличить отсутствие напряжения от его наличия проще, чем определить конкретный уровень напряжения от 0 до 9.

Биты и байты

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

Бит — это один разряд двоичного кода.

Байт — это совокупность 8 бит.

Полубайт — это группа из 4 бит, которая соответствуют одному символу в шестнадцатеричной системе счисления.

Для удобства восприятия двоичные числа часто разделяют пробелами на полубайты. То есть вместо записи 10011101110000101101111000101101 будет использоваться запись 1001 1101 1100 0010 1101 1110 0010 1101.

Нумерация битов в Wialon начинается с 1. Обычно нумерация битов начинается с 0, поэтому формулы, которые вы увидите ниже, могут немного отличаться от найденных в интернете или других источниках.

Числа с плавающей запятой

Число с плавающей запятой (или точкой) — это экспоненциальная форма представления действительных чисел, в которой число хранится в виде мантиссы и порядка.

Ниже приведено несколько примеров таких чисел:

125 000 = 1.25 × 105 — здесь мантисса равна 1.25, а порядок равен 5.

0.000000125 = 1.25 × 10−7 — мантисса равна 1.25, а порядок равен −7.

125 000 000 000 000 = 1.25 × 1014 — мантисса равна 1.25, а порядок равен 14.

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

Для представления чисел с плавающей запятой в цифровых устройствах наиболее часто используется стандарт IEEE 754.

Практическое применение

В данном разделе будут рассмотрены разные варианты пользовательских параметров и формулы для их интерпретации в Wialon.

Примеры их использования можно найти в инструкции.

Преобразование двоичного числа в целое десятичное

Для понимания формулы преобразования стоит сперва взглянуть на десятичные числа под немного непривычным углом. Рассматривать будем десятичное число 125. Оно состоит из 1 сотни, 2 десятков и 5 единиц: 125 = 1 × 100 + 2 × 10 + 5 × 1.

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

125 = 1 × 103−1 + 2 × 102−1 + 5 × 101−1 = 1 × 1022 × 101 + 5 × 100

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

,

где d — число в десятичной системе счисления, i — номер бита двоичного числа, N — количество битов, bi — значение i-го бита.

Также эту формулу можно представить в следующем виде:

d = bN × 2N−1 + ... + bi × 2i−1 + ... + b2 × 22−1 + b1 × 21−1

Рассмотрим пример с тем же числом:

(BIN) 0111 1101 = (DEC) 0 × 28−1 + 1 × 27−1 + 1 × 26−1 + 1 × 25−1 + 1 × 24−1 + 1 × 23−1 + 0 × 22−1 + 1 × 21−1 =

= (DEC) 0 × 27 + 1 × 26 + 1 × 25 + 1 × 24 + 1 × 23 + 1 × 22 + 0 × 21 + 1 × 20 = (DEC) 26 + 25 + 24 + 23 + 22 + 20 =

= (DEC) 64 + 32 + 16 + 8 + 4 + 1 = (DEC) 125.

Эта формула является ключевой для работы с битами в Wialon. На ее основе выполняются все остальные преобразования.

Если значение приходит в параметре с именем user_value, то с учетом синтаксиса Wialon формула примет следующий вид:

user_value:8*const2^const7+user_value:7*const2^const6+user_value:6*const2^const5+user_value:5*const2^const4+user_value:4*const2^const3+user_value:3*const2^const2+user_value:2*const2^const1+user_value:1*const2^const0

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

user_value:8*const128+user_value:7*const64+user_value:6*const32+user_value:5*const16+user_value:4*const8+user_value:3*const4+user_value:2*const2+user_value:1*const1

Длина формулы преобразования будет зависеть от количества учитываемых битов, поэтому копировать ее напрямую из статьи не получится. Если по протоколу трекера на значение параметра выделен 1 байт (8 битов), то формула будет аналогична приведенной выше (необходимо будет лишь заменить в ней имя параметра). А если на параметр выделено 3 байта, то формула будет в 3 раза длиннее, и в ней будут использоваться константы вплоть до 223 = 8388608.

Выделение части параметра

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

В качестве примера рассмотрим параметр user_value со значением (DEC) 32200 = (BIN) 0111 1101 1100 1000. Его первый байт описывает значение первого счетчика, а второй байт — значение другого счетчика. Необходимо создать два отдельных датчика с формулами, которые будут использовать только нужные байты.

Параметрuser_value
Номер бита исходного значения16151413121110987654321
Значение бита0111110111001000
Номер бита искомого значения8765432187654321
ДатчикСчетчик №2Счетчик №1

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

user_value:8*const2^const7+user_value:7*const2^const6+user_value:6*const2^const5+user_value:5*const2^const4+user_value:4*const2^const3+user_value:3*const2^const2+user_value:2*const2^const1+user_value:1*const2^const0

Формула для второго датчика будет отличаться, так как мы будем обращаться к битам 9-16, но воспринимать их как биты 1-8:

user_value:16*const2^const7+user_value:15*const2^const6+user_value:14*const2^const5+user_value:13*const2^const4+user_value:12*const2^const3+user_value:11*const2^const2+user_value:10*const2^const1+user_value:9*const2^const0

В итоге из одного числа 32200 мы сможем получить:

(BIN) 1100 1000 = (DEC) 200 — значение первого счетчика.

(BIN) 0111 1101 = (DEC) 125 — значение второго счетчика.

Учет знака числа

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

Например, если в пользовательском параметре трекер отправляет значение 13 или −5, то Wialon об этом не знает, и в обоих случаях мы увидим одинаковый параметр user_value = 13, так как:

(DEC) 13 = (BIN) 1101

(DEC) −5 = (BIN) 1101 — старший бит отвечает за минус, а (BIN) 101 = (DEC) 5.

Чтобы интерпретировать знаковый бит правильно, необходимо изменить формулу преобразование двоичного числа в целое десятичное, добавив к ней в начале −1 в степени старшего бита:

,

где d — число в десятичной системе счисления, i — номер бита двоичного числа, N — количество битов, bi — значение i-го бита.

Также эту формулу можно представить в следующем виде:

d = (−1)bN × (bN-1 × 2(N−1)−1 + ... + bi × 2i−1 + ... + b2 × 22−1 + b1 × 21−1)

Данная формула работает, так как (−1)0 = 1, а (−1)1 = −1, что и позволяет отобразить знак числа с помощью одного бита.

Если предположить, что знаковым битом является бит номер 32, то для его учета в Wialon нужно дописать в датчике в начало выражения следующую формулу:

(const-1)^user_value:32*...

Преобразование двоичного числа в десятичное число с плавающей запятой

Речь идет про преобразование двоичного нормализованного числа в 32-битный формат по стандарту IEEE 754. Данный стандарт подразумевает не передачу самого числа с плавающей запятой, а передачу некоторых значений, по которым искомое число можно рассчитать по следующей формуле:

d = (−1)S × 2(E−127) × (1 + M/223),

где d — число в десятичной системе счисления, S — знак числа, E — смещенная экспонента, M — остаток нормализованной мантиссы.

Для применения этой формулы не требуется ее полное понимание, так как в стандарте описано, в каких битах хранятся S, E и M, которые нужно просто подставить в выражение.

 Дополнительная информация

В приведенной формуле используется не порядок числа с плавающей запятой, который может быть отрицательным (например, 1.25×10−7), а смещенная экспонента E, которая всегда имеет положительное значение. Обратное смещение достигается с помощью вычитания 127 из смещенной экспоненты уже в формуле, что и позволяет получить отрицательные значения.

Нормализованная двоичная мантисса лежит в диапазоне [1; 2), то есть ее первый бит всегда равен 1. Поэтому в стандарте IEEE 754 эту единицу не отправляют (ведь она известна заранее), а добавляют в формуле на этапе вычисления результата. Это позволяет сэкономить один бит и получить большую точность передаваемого значения. В приведенной формуле М является не мантиссой, а ее остатком.

В качестве примера рассмотрим число −5.15811×10−21, которое будет отображаться в параметре как user_value = 2646793773:

(DEC) 2646793773 = (BIN) 1001 1101 1100 0010 1101 1110 0010 1101

Знаковый бит (S)Смещенная экспонента (E)Остаток нормализованной мантиссы (M)
3231302928272625242322212019181716151413121110987654321
10011101110000101101111000101101

По формуле преобразования двоичного числа в целое десятичное получаем значения M и E.

Остаток нормализованной мантиссы M будет равен:

user_value:23*const2^const22+user_value:22*const2^const21+user_value:21*const2^const20+user_value:20*const2^const19+user_value:19*const2^const18+user_value:18*const2^const17+user_value:17*const2^const16+user_value:16*const2^const15+user_value:15*const2^const14+user_value:14*const2^const13+user_value:13*const2^const12+user_value:12*const2^const11+user_value:11*const2^const10+user_value:10*const2^const9+user_value:9*const2^const8+user_value:8*const2^const7+user_value:7*const2^const6+user_value:6*const2^const5+user_value:5*const2^const4+user_value:4*const2^const3+user_value:3*const2^const2+user_value:2*const2^const1+user_value:1*const2^const0

Смещенная экспонента E будет равна:

user_value:31*const2^const7+user_value:30*const2^const6+user_value:29*const2^const5+user_value:28*const2^const4+user_value:27*const2^const3+user_value:26*const2^const2+user_value:25*const2^const1+user_value:24*const2^const0

Теперь запишем конечную формулу с учетом синтаксиса Wialon:

(const-1^user_value:32)*const2^(user_value:31*const2^const7+user_value:30*const2^const6+
user_value:29*const2^const5+user_value:28*const2^const4+user_value:27*const2^const3+
user_value:26*const2^const2+user_value:25*const2^const1+user_value:24*const2^const0-const127)*(const1+
(user_value:23*const2^const22+user_value:22*const2^const21+user_value:21*const2^const20+
user_value:20*const2^const19+user_value:19*const2^const18+user_value:18*const2^const17+
user_value:17*const2^const16+user_value:16*const2^const15+user_value:15*const2^const14+
user_value:14*const2^const13+user_value:13*const2^const12+user_value:12*const2^const11+
user_value:11*const2^const10+user_value:10*const2^const9+user_value:9*const2^const8+
user_value:8*const2^const7+user_value:7*const2^const6+user_value:6*const2^const5+
user_value:5*const2^const4+user_value:4*const2^const3+user_value:3*const2^const2+
user_value:2*const2^const1+user_value:1*const2^const0)/const2^const23)

Или упрощенно:

(const-1^user_value:32)*const2^(user_value:31*const128+user_value:30*const64+user_value:29*const32+
user_value:28*const16+user_value:27*const8+user_value:26*const4+user_value:25*const2+
user_value:24*const1-const127)*(const1+(user_value:23*const4194304+user_value:22*const2097152+
user_value:21*const1048576+user_value:20*const524288+user_value:19*const262144+
user_value:18*const131072+user_value:17*const65536+user_value:16*const32768+user_value:15*const16384+
user_value:14*const8192+user_value:13*const4096+user_value:12*const2048+user_value:11*const1024+
user_value:10*const512+user_value:9*const256+user_value:8*const128+user_value:7*const64+
user_value:6*const32+user_value:5*const16+user_value:4*const8+user_value:3*const4+user_value:2*const2+
user_value:1*const1)/const8388608)

При подстановке числовых значений получаем:

(−1)1 × 2(59−127) × (1 + 4382253/223) = −0.00000000000000000000515811 = −5.15811×10−21

Как видим, полученный результат значительно отличается от исходного значения параметра 2646793773.

Формула преобразования двоичного нормализованного числа в 32-битный формат IEEE 754 является единой для всех трекеров, так как речь идет про конкретный стандарт. Если в документации к трекеру вы видите, что пользовательский параметр может отправляться по стандарту IEEE 754, и вы выбираете этот формат отправки, то для интерпретации в Wialon вы можете копировать выражение для датчика напрямую из этой статьи, заменив в нем лишь имя параметра user_value, но не изменяя номера битов.

Из следующего блока вы можете удобно скопировать формулу для преобразование двоичного числа в десятичное число с плавающей запятой (32-битный формат по стандарту IEEE 754):

(const-1^user_value:32)*const2^(user_value:31*const128+user_value:30*const64+user_value:29*const32+user_value:28*const16+user_value:27*const8+user_value:26*const4+user_value:25*const2+user_value:24*const1-const127)*(const1+(user_value:23*const4194304+user_value:22*const2097152+user_value:21*const1048576+user_value:20*const524288+user_value:19*const262144+user_value:18*const131072+user_value:17*const65536+user_value:16*const32768+user_value:15*const16384+user_value:14*const8192+user_value:13*const4096+user_value:12*const2048+user_value:11*const1024+user_value:10*const512+user_value:9*const256+user_value:8*const128+user_value:7*const64+user_value:6*const32+user_value:5*const16+user_value:4*const8+user_value:3*const4+user_value:2*const2+user_value:1*const1)/const8388608)

Олег Жарковский,Инженер Customer Service

Некорректный пробег
  • technical_consulting
  • trips

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

Если вы столкнулись с проблемой некорректного определения пробега в отчете, на треке или в сообщениях, то в первую очередь проверьте, какой тип счетчика пробега выбран у вас на вкладке Основное в свойствах объекта:

  • GPS
  • GPS + датчик зажигания
  • Датчик пробега
  • Относительный одометр

Узнав, какой счетчик используется в вашем объекте, выберите соответствующий раздел статьи.

1. GPS

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

a. Выбросы координат и неправильная хронология сообщений

Выбросы координат могут появляться из-за плохой связи со спутниками Глобальной Навигационной Спутниковой Системы (ГНСС). Чтобы определить, что выбросы имели место, перейдите на вкладку Сообщения и выгрузите данные для нужного объекта за проблемный период. На карте вы увидите трек, по которому можно будет определить наличие выбросов: координаты сообщений значительно отстоят от фактического местоположения объекта.


В данном примере явным признаком проблем с определение местоположения объекта является параметр HDOP — он имеет значения >1

Wialon имеет ограничение: не более 1 сообщения должно приходить от объекта за 1 секунду. Если терминал передает более 1 сообщения в 1 секунду, хронология сообщений может нарушиться и трек будет выглядеть аналогичным образом. Причина — некорректная расстановка сообщений с позиционными данными (координатами) в базе данных Wialon. В таких случаях, в настройках терминала следует снизить частоту отправки сообщений с данными.

Возможные варианты решения:

  • Использовать Фильтрацию валидности сообщений;
  • Изменить настройки Детектора поездок.

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



b. Использование датчика пробега

В некоторых случаях счетчик (вкладка Основное в свойствах объекта) работает на основе GPS-координат, но при этом также создан отдельный датчик пробега (вкладка Датчики в свойствах объекта). В отчетах, например, с таблицей Поездки колонка Пробег будет выводить значение по GPS (суммарное расстояние между координатами), но значение колонок Начальный/Конечный пробег будет рассчитано следующими методами:

  • Если значение датчика пробега имеется в первом/последнем сообщении интервала, то система использует эти значения.
 Пояснения

Условимся, что фактически объект проехал 2 км, а сообщения приходили в следующем порядке:

  1. 10 км
  2. -- км
  3. -- км
  4. 15 км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км (как в сообщении), в колонке Конечный пробег получим 15 км (как в сообщении).

Аналогичный пример, но значение датчика пробега доступно только в последнем сообщении:

  1. -- км
  2. -- км
  3. -- км
  4. 15 км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Конечный пробег получим 15 км (как в сообщении).

И еще один пример, где значение датчика пробега доступно только в первом сообщении:

  1. 10 км
  2. -- км
  3. -- км
  4. -- км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км (как в сообщении).

  • Если в первом сообщении интервала нет значения датчика пробега, то система ищет первое доступное сообщение со значением датчика пробега на этом интервале, а потом из него вычитается пробег до начала поездки, рассчитанный по GPS-координатам.
 Пояснения

Условимся, что фактически объект проехал 2 км, а сообщения приходили в следующем порядке:

  1. -- км
  2. -- км
  3. -- км
  4. 15 км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 15 км - рассчитанное по GPS-координатам значение или 15 км - 2 км = 13 км, в колонке Конечный пробег получим 15 км (как в сообщении).

  • Если в последнем сообщении интервала нет значения датчика пробега, то система ищет последнее доступное сообщение со значением пробега на этом интервале, а потом к нему прибавляется пробег до конца поездки, рассчитанный по GPS-координатам.
 Пояснения

Условимся, что фактически объект проехал 2 км, а сообщения приходили в следующем порядке:

  1. 10 км
  2. -- км
  3. -- км
  4. -- км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км (как в сообщении), в колонке Конечный пробег получим 10 км + рассчитанное по GPS-координатам значение или 10 км + 2 км = 12 км.

  • Если в первом и последнем сообщении нет значения датчика пробега, то система ищет первое доступное значение датчика, а потом из него вычитает пробег рассчитанный по GPS-координатам, чтобы получить начальное значение, а, чтобы получить конечное значение, наоборот, прибавляет к значению датчика пробег, рассчитанный по GPS-координатам.
 Пояснения

Условимся, что фактически объект проехал 2 км, а сообщения приходили в следующем порядке:

  1. -- км
  2. 10 км
  3. 15 км
  4. -- км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км - рассчитанное по GPS-координатам значение до первого сообщения интервала, в колонке Конечный пробег получим 10 км + рассчитанное по GPS-координатам значение до последнего сообщения интервала.

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


В данном примере для объекта создан датчик пробега на основе параметра can_mileage, который отсутствует в сообщениях вплоть до 18.12.2019 16:38:54:


После 16:38 и далее параметр всегда имеет значение 0, а датчик, соответственно, — значение 0 км.

Возможные варианты решения:

  • Удалить датчик пробега и полностью перейти на пробег по GPS-координатам;
  • Устранить проблему на стороне оборудования или переключиться на параметр с корректными значениями.

В примере выше решением стало удаление датчика и переход только на GPS пробег, т. к. значения параметра не считывались с CAN-шины.

2. GPS + датчик зажигания

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

Некорректное значение датчика зажигания

В качестве счетчика пробега выбрана опция GPS + датчик зажигания. При построении трека (через вкладку Сообщения, Треки или Отчеты) пробег равен 0 км, при этом сам трек на карте виден:



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

В данном примере для объекта не создан датчик с типом Зажигание, поэтому система игнорирует все сообщения и выводит 0 км пробега:


Возможные варианты решения:

  • Переключить счетчик пробега на GPS;
  • Добавить корректно работающий датчик зажигания.


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

3. Датчик пробега

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

a. Сброс значений параметра пробега

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





В примере суммарный пробег по счетчику пробега составляет 26943 км, а по датчику пробега — всего 7069 км.

Причина  сброс параметра датчика пробега.


В такой ситуации происходит сброс до 0 км и далее снова рост до 6452 км (в примере такие сбросы повторялись неоднократно).

Возможные варианты решения:

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

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





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

b. Сообщения с одинаковой временной меткой (опция С переполнением включена)

Терминалы могут присылать сообщения слишком часто. Wialon имеет ограничение: не более 1 сообщения должно приходить от объекта за 1 секунду. При получении данных с большей частотой их хронология может быть нарушена и меньшее значение пробега может попасть в базу после сообщения с бо́льшим значением, пример на картинке ниже:


В таких ситуациях происходит переполнение счетчика до максимально возможного значения  2147483648.

Возможные варианты решения:

  • Отключить опцию С переполнением в настройках датчика (если была активирована).

В примере выше опция С переполнением была включена. Отключив ее, мы получили более корректное значение пробега:


с. Сообщения с одинаковой временной меткой (опция С переполнением выключена)

Сообщения могут приходить с одинаковой временной меткой, нарушая хронологию, например:

В целом, на картинке выше, пробег выглядит корректным  25.01 км, в отличие от предыдущего примера, где ошибка была очевидна. Однако, если взять из сообщений начальное значение датчика пробега на интервале  9917.81 км и конечное  9942.44 км, вычесть разницу, то получим пробег  24.63 км.

Разница составляет 0.38 км на относительно небольшом отрезке трека. Погрешность будет расти с увеличением объема данных (количеством поездок). Причина ошибки — это конечно же нарушение хронологии сообщений. Система ожидает, что значение датчика будут расти. В примере видим падение с 9931.03 км до 9930.85 км и последующий рост до 9931.29 км. Происходит повторный расчет пробега между сообщениями зо значением датчика 9930.85 км и 9931.29 км, т.е. добавляются лишние 0.44 км.

Возможные варианты решения:

  • Переключить счетчик пробега на GPS;
  • Устранить проблему на стороне оборудования;
  • Переключить датчик пробега на тип Относительный одометр и применить валидацию.

В примере выше удалось получить более корректные значения пробега с помощью перевода датчика пробега на тип Относительный одометр с добавлением валидации. Датчика относительного одометра основан на параметре в виде выражения: mileage-#mileage. Валидатор основан на параметре в виде выражения: time-#time. Нижняя граница для валидатора  0, a тип валидации  Проверка на неравенство нулю. Счетчик пробега во вкладке Основное переключен на  Относительный одометр.

После применения валидации, пробег составил  24.65 км. Сообщения, в которых временная метка совпадает, исключаются из расчета.

При возникновении вопросов по конкретным практическим случаям вы можете обратиться в техподдержку через почту support@wialon.com. Обязательно указывайте в вашем письме краткое описание ситуации со скриншотами, точное имя объекта, имя шаблона отчета для проверки, минимальный интервал времени для проверки (например, не месяц, а одни сутки), а также прочие важные детали.

Павел Чеботарёв,Инженер Customer Service

Контроль качества вождения
  • technical_consulting
  • eco_driving

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

Теоретическая основа

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

Скорость и ускорение

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

v = S / Δt,

где v — скорость, S — пройденный путь за рассматриваемый интервал времени (можно сказать, что это разница пробега ТС в конце и в начале), Δt — длительность интервала.

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

Ускорение характеризует изменение скорости за определенный интервал времени:

a = Δv / Δt,

где a — ускорение, Δv — разница скорости в конце и в начале рассматриваемого интервала времени, Δt — длительность интервала.

Среднее значение ускорения за поездку почти не используется при анализе движения автомобиля, поэтому имеет смысл вычислять только ускорение за минимальный интервал времени.

Единицы измерения

Единицей скорости в СИ служит метр в секунду (м/с), однако в повседневной жизни чаще используется внесистемная единица измерения километр в час (км/ч).

Единицей ускорения в СИ служит метр в секунду за секунду (м/с2), однако часто используется внесистемная единица измерения g (именно она применяется в Wialon).

g (произносится «же») — это ускорение свободного падения на поверхности Земли, равное 9.80665 м/с2 (часто используется приближение g ≈ 10 м/с2). В нашем случае это стандартная величина, на которую делят значение ускорения, чтобы сравнить с чем-то более привычным (как давление зачастую отображают не в паскалях, а в атмосферах).

Ускорение в 1 g соответствует разгону от 0 до 100 км/ч за 2.83 секунды.

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

Вид движения

Среднее ускорение
м/с2g
Пассажирский лифт0.9—1.60.09—0.16
Поезд метро10.1
Бегун на коротких дистанциях1.50.15
Велосипедист1.70.17
Легковой автомобиль2.5—30.25—0.3
Мотоцикл3—60.3—0.6
Гоночный автомобиль8—90.8—0.9
Аварийное торможение автомобилядо 20до 2
Запуск и торможение космического корабля40—604—6
Маневр реактивного самолетадо 100до 10
 Пример расчета скорости и ускорения

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

В рамках примера будем отсчитывать время с 0 секунд. Для упрощения будем предполагать, что объект всегда двигался по прямой, а между сообщениями скорость транспортного средства менялась равномерно.

Номер сообщения12345678
Время, с0510204070100103
Путь, м002515040090014001430
Скорость, км/ч0018454560600
Ускорение, g0.0000.0000.1020.0770.0000.0140.000-0.567

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

  • Скорость равна 0, когда объект не меняет положение.
  • Ускорение равно 0, когда объект не меняет скорость (стоит на месте или движется с одинаковой скоростью).
  • Положительное значение ускорения соответствует увеличению скорости, а отрицательное — торможению.
  • По величине ускорения можно судить о том, насколько быстро и значительно изменилась скорость между сообщениями.

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

Акселерометры

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

Так как ускорение является векторной величиной, то есть оно имеет направление, то для его полноценного измерения требуется три акселерометра, установленных перпендикулярно друг другу. Вместе они формируют один трехосевой акселерометр, в котором, например, ось X показывает ускорение или торможение, ось Y — повороты, ось Z — подъемы и спуски.

Трекер с акселерометром или отдельный датчик-акселерометр могут иметь на корпусе нарисованные оси, по которым его нужно расположить на объекте.

Единого правила для направления или наименования осей не существует. То есть ось Z может быть направлена не вверх, а вниз, либо вместо оси X вперед может быть направлена ось Y. Узнать об этом вы можете из документации устройства.

При установке устройства на объект важно, чтобы оно было жестко зафиксировано.

Идеально ровно установить устройство на объект не получится, поэтому после установки необходимо осуществить калибровку. В общем случае процедура калибровки подразумевает несколько этапов: движение по прямой, повороты, плавное и резкое торможение, поездка без нарушений, поездка с нарушениями. Однако для разных устройств калибровка может значительно отличаться. Узнать о ней вы можете из документации устройства.

Так как в акселерометрах и трекерах используется одинаковая элементная база (микросхемы), то их показания не будут отличаться более чем на 15% (а при правильном выполнении калибровки это значение будет еще меньше).

Реализация в Wialon

Общую логику контроля качества вождения в Wialon можно представить в следующем виде:

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

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

Общий подход к настройке

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

Типы трекеровТочностьСложность настройкиРасчет ускорения поЧастота сообщенийСоздание датчиковКритерии для контроля ускорения

1. Трекер присылает рассчитанные параметры качества вождения

ВысокаяЛегкаяПараметрам качества вожденияЛюбаяНе требуетсяУскорение,
Торможение,
Поворот,
Резкое вождение

2. Трекер присылает рассчитанные параметры ускорения в произвольном формате

ВысокаяСредняяНеважноЛюбаяТребуетсяПроизвольный
3. Трекер присылает сырые значения ускорения по осямСредняяВысокаяНеважно1 раз в 2 секундыТребуетсяПроизвольный
4. Трекер ни в каком виде не присылает данные об ускоренииНизкаяЛегкаяGPS1 раз в 2 секундыНе требуетсяУскорение,
Торможение,
Поворот,
Резкое вождение

Далее приведем некоторые подробности по каждому из подходов:

1. Трекер присылает рассчитанные параметры качества вождения

Данный подход применим только для определенных типов устройств, которые используют особые алгоритмы обработки данных от акселерометра. Их список можно найти на сайте wialon.com в разделе Оборудование с помощью фильтра ECO driving.

В Wialon параметрами качества вождения называют параметры wln_accel_max, wln_brk_max и wln_crn_max. Упрощенно можно сказать, что эти параметры содержат в себе значения, соответствующие максимальному ускорению, зафиксированному между двумя последовательными сообщениями. Это позволяет настроить трекер на любую частоту сохранения сообщений без влияния на точность результата.

Такие параметры распознаются системой автоматически, поэтому никаких дополнительных датчиков создавать не нужно. Достаточно настроить расчет ускорения по параметрам качества вождения и создать критерии с типом Ускорение, Торможение, Поворот, Резкое вождение.

2. Трекер присылает рассчитанные параметры ускорения в произвольном формате

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

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

3. Трекер присылает сырые значения ускорения по осям

Если трекеры не имеют особых алгоритмов обработки данных от акселерометра, то они присылают параметры с показаниями по трем осям в момент генерации сообщения. В таком случае чем выше будет частота сохранения сообщений, тем выше будет точность результата, однако это будет приводить к увеличению GPRS-трафика, затрачиваемого трекером. Рекомендуемая частота — 1 сообщение каждые 2 секунды.

Подобные параметры не распознаются системой автоматически, поэтому для их учета необходимо создать два датчика (логичнее всего выбрать тип Акселерометр): один будет основан на параметре от оси X (положительное значение будет соответствовать ускорению, а отрицательное — торможению), а второй будет основан на параметре от оси Y (положительное значение будет показывать поворот в одну сторону, а отрицательное — в другую). Ось Z, связанная с ускорением по вертикали, не будет использоваться для расчетов. Далее на основе этих двух датчиков создать критерии с типом Произвольный.

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

Стоит повторить, что единого правила для направления или наименования осей не существует. Узнать направления осей вашего устройства можно из его документации.

4. Трекер ни в каком виде не присылает данные об ускорении

Если трекеры не имеют акселерометра, то есть не могут измерять ускорение, то его можно рассчитать математически по данным от GPS. В таком случае чем выше будет частота сохранения сообщений, тем выше будет точность результата, однако это будет приводить к увеличению GPRS-трафика, затрачиваемого трекером. Рекомендуемая частота — 1 сообщение каждые 2 секунды.

Далее необходимо настроить расчет ускорения по GPS и создать критерии с типом  Ускорение, Торможение, Поворот, Резкое вождение.

Если трекер не присылает информацию о направлении движения (параметр course), то система не сможет определить нарушения по критериям с типом Поворот.

Рекомендуемые значения критериев

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

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

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

Шаблоны критериев

Для упрощения настройки критериев в Wialon имеется 3 стандартных шаблона: для легкового автомобиля, для грузового автомобиля и для автобуса. С их помощью можно получить сразу несколько критериев, которые можно оставить в исходном виде, либо немного поменять, либо просто использовать в качестве примера для самостоятельной настройки.

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

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

Олег Жарковский,Инженер Customer Service

Расход топлива по расчету (математический расчет)
  • technical_consulting
  • fuel
  • fuel_consumption
  • math_consumption

Некоторые трекеры не присылают информацию о топливе, либо топливные датчики в принципе не установлены на объект, однако пользователи все равно хотят видеть в отчете информацию о расходе.

В качестве альтернативы топливным датчикам можно использовать Расход по нормам, который настраивается на вкладке Дополнительно. Алгоритм его вычисления прост: пробег за интервал умножается на заданную норму расхода (л/100 км), которая может меняться в зависимости от сезона.

Но в данной статье мы рассмотрим другой вариант вычисления расхода без датчика, который требует большего количества пояснений, — Расход по расчету, также называемый Математическим расчетом. Тем более сфера его применения не ограничивается одним вариантом.

Где используется расход по расчету

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

Также расход по расчету используется в топливных алгоритмах. Во-первых, для поиска сливов, если включена опция Расчет сливов по времени. Во-вторых, для вычисления расхода на интервалах с ошибочными значениями, если включена опция Заменять ошибочные значения рассчитанными математически. Обе упомянутые опции находятся в дополнительных настройках ДУТ.

Как работает математический расчет

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

  • датчиков работы двигателя (зажигания или абсолютных/относительных моточасов), в которых указана норма расхода на холостом ходу;
  • датчиков полезной работы двигателя (ДПРД), каждый из которых говорит о влиянии какого-либо фактора на расход топлива (оборотов двигателя, температуры, нагрузки на ось, работы кондиционера, навесного оборудования и так далее).

Расход по расчету за интервал является суммой расходов между всеми сообщениями интервала. Для вычисления расхода по расчету между рассматриваемым и предыдущим сообщениями используется следующая формула:

Δt ( CХХ 1 + CХХ 2 + ... + CХХ N )  (KДПРД 1 + (KДПРД 2 - 1) + (KДПРД 3 - 1) + ... + (KДПРД M - 1)),

где Δt — время между сообщениями; CХХ i — норма расхода на холостом ходу из i-го датчика работы двигателя, который был включен в рассматриваемом сообщении; N — количество созданных в объекте датчиков работы двигателя; KДПРД j — значение j-го датчика полезной работы двигателя в рассматриваемом сообщении; M — количество созданных в объекте датчиков полезной работы двигателя.

Приведенная выше формула применяется только для связанных между собой датчиков. Если в объекте нет ДПРД или они не связаны с датчиками работы двигателя, то используется сокращенная формула:

Δt ⋅ ( CХХ 1 + CХХ 2 + ... + CХХ N )

Зачем связывать датчики работы двигателя, ДПРД и ДУТ

Некоторые объекты имеют сразу несколько двигателей. Чаще всего это касается спецтехники, и хорошим примером здесь является автобетоносмеситель: его основной двигатель заставляет машину перемещаться, а дополнительный автономный двигатель вращает смесительный барабан. Ускорение машины или включение кондиционера может повлиять на расход основного двигателя, но не повлияют на расход дополнительного. Следовательно, некоторые влияющие на расход факторы (их мы учитываем с помощью ДПРД) влияют только на один из двигателей (их мы учитываем с помощью датчиков работы двигателя). При этом у объекта может быть и несколько топливных баков (их мы учитываем с помощью ДУТ), которые тоже нужно связать с определенным двигателем.

Чтобы осуществить связь, необходимой войти в свойства датчика зажигания или датчиков абсолютных/относительных моточасов и выбрать соответствующие ДПРД. Аналогично в свойствах ДУТ настраивается его связь с датчиками работы двигателя.

Как быстро создать математическую модель

Для создания базовой математической модели воспользуйтесь Мастером расхода по расчету, расположенным на вкладке Датчики в свойствах объекта. В окне Мастера расхода по расчету необходимо ввести информацию о расходе топлива в разных режимах работы, а также сезонный коэффициент и даты начала и окончания сезона. Рассмотрим эти поля подробнее:

  • Расход топлива (л/ч) подразумевает расход на холостом ходу, то есть при включенном двигателе и отсутствии движения. Минимальная скорость движения при этом берется из Детектора поездок.
  • Городской цикл и Загородный цикл (л/100км) являются стандартными характеристиками транспортного средства, которые можно найти в документах, в интернете или вычислить на практике. При этом в разных странах используют различные подходы к тому, как определять эти циклы. В Wialon норма городского цикла соответствует скорости 36 км/ч, а загородного — 80 км/ч.
  • Сезонный коэффициент (%) подразумевает то, на сколько процентов увеличивается расход топлива в течение указанного сезона относительного остального года. Учет сезонного коэффициента можно отключить, если на территории использования транспортного средства не наблюдается значительного изменения температуры в течение года.

Чем больше данных вы внесете, тем точнее будет работать математическая модель, однако минимально необходимо ввести хотя бы расход в городском цикле.

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

Создать более точную модель автоматически не получится, но можно сделать это вручную, добавив ДПРД самостоятельно.

Как работают датчики полезной работы двигателя

Значение ДПРД в каждом сообщении должно показывать, во сколько раз какой-либо влияющий фактор увеличивает расход на холостом ходу относительно расхода без влияния этого фактора. Для лучшего понимания рассмотрим пример.

Предположим, что расход на холостом ходу равен 2 л/ч, а при включении системы отопления расход возрастает до 2.2 л/ч. Следовательно, отношение этих величин равно: 2.2/2 = 1.1
Также предположим, что параметр in4 однозначно говорит о состоянии системы отопления: если данный параметр равен 0, то отопление выключено, а если равен 1 — включено.
В таком случае для учета влияния системы отопления на расход необходимо создать датчик с типом Датчик полезной работы двигателя, в строке Параметр указать in4, а в Таблицу расчета добавить следующие строки:

x = 0; a = 0; b = 1
x = 1; a = 0; b = 1.1

Получается, что при выключенной системе отопления ДПРД увеличивает расход в 1 раз (то есть никак не меняет его), а при включенной — увеличивает в 1.1 раза. Дополнительно стоит отметить, что нулевое значение ДПРД также не изменило бы расход.

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

Как сделать расход по расчету более точным

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

Но все же вы можете попробовать увеличить точность модели нижеприведенными способами.

Учитывайте больше факторов

Вы можете создать больше ДПРД на основе параметров от трекера, которые описывают влияющие на расход факторы.

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

Увеличьте точность измерения параметров

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

Увеличьте частоту генерации сообщений

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

Почему расход по расчету показывает неправильные значения

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

  1. Используемые в Мастере расхода по расчету нормы могут отличаться от реальных (например, из-за износа транспортного средства). В таком случае вы можете на практике проверить их соответствие реальности.
  2. Это может быть связано с некорректной настройкой расхода по расчету. Проверьте, чтобы в свойствах датчика работы двигателя было указано ненулевое значение в строке Расход, литров в час. Также убедитесь, что датчик работы двигателя и ДПРД связаны.
  3. Частота генерации сообщений трекером может быть слишком низкой.
  4. Это может объясняться поломкой датчика, показания которого используются в математической модели.
  5. В некоторых случаях система может считать, что зажигание было включено все время, пока трекер не присылал сообщений. В таком случае математическая модель покажет, что все это время двигатель должен был тратить топливо. Для исправления ситуации попробуйте установить корректное значение опции Максимальный интервал между сообщениями на вкладке Дополнительно в свойствах объекта. Достичь такого же результата можно и с помощью опции Таймаут в свойствах датчика зажигания.


При возникновении вопросов по конкретным практическим случаям вам стоит обратиться в техподдержку через почту support@wialon.com. Обязательно указывайте в вашем письме краткое описание ситуации со скриншотами, точное имя объекта, имя шаблона отчета для проверки, минимальный интервал времени для проверки (например, не месяц, а одни сутки), а также прочие важные детали.



Олег Жарковский,Инженер Customer Service

Различия топливных алгоритмов
  • technical_consulting
  • fuel

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

Какой алгоритм выбрать

Ниже приведен список особенностей алгоритмов, который должен помочь вам определиться с выбором.

Алгоритм по пробегу

  1. Подходит для большинства подвижных объектов.
  2. Относительно прост в настройке.
  3. Используется по умолчанию.

Алгоритм по времени

  1. Подходит
    • для стационарных объектов,
    • для объектов с большими интервалами холостого хода,
    • для объектов с дополнительным оборудованием, увеличивающим расход,
    • при подозрениях на сливы во время движения,
    • если алгоритм по пробегу не дает ожидаемых результатов.
  2. Более сложен в настройке.
  3. Для активации рекомендуется одновременно включить следующие опции в свойствах датчика уровня топлива:
    • Рассчитывать расход топлива по времени,
    • Расчет заправок по времени,
    • Расчет сливов по времени – для обработки сливов также требуется математическая модель расхода, которую можно создать, например, с помощью Мастера расхода по расчету.

В чем разница между алгоритмами

Сперва стоит отметить, что алгоритм по пробегу в некотором смысле было бы корректнее назвать алгоритмом по скорости, так как он игнорирует сообщения, скорость в которых меньше Минимальной скорости движения, заданной в Детекторе поездок. Но так как при наличии скорости пробег растет, то нынешнее название тоже является вполне уместным.

Из описанного выше следует, что ключевая разница алгоритмов заключается в том, что алгоритм по времени анализирует все сообщения, а алгоритм по пробегу исключает из анализа часть сообщений, используя упрощение. Оно основано на том, что судить об изменении уровня топлива во время остановки или стоянки (то есть на интервале с низкой скоростью) можно по двум сообщениям до и после рассматриваемой остановки или стоянки. Например, если автомобиль был на парковке с 14:00 до 16:00, а слив был осуществлен в промежутке 15:00-15:10, то узнать о факте слива можно, просто сравнив уровни топлива в 14:00 и 16:00.

Расход

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

Дополнительно отмечу, что объем сливов по умолчанию включен в расход, пока не активирована опция Исключить сливы из расхода топлива в настройках шаблона отчета.

Заправки

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

Сливы

Детектирование сливов происходит разным методом:

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

При возникновении вопросов по конкретным практическим случаям вам стоит обратиться в техподдержку через почту support@wialon.com. Обязательно указывайте в вашем письме краткое описание ситуации со скриншотами, точное имя объекта, имя шаблона отчета для проверки, минимальный интервал времени для проверки (например, не месяц, а одни сутки), а также прочие важные детали.

Олег Жарковский,Инженер Customer Service




Не детектируется заправка
  • technical_consulting
  • fuel
  • fuel_fillings

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

Возможные причины и их устранение

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

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

1. Заправка игнорируется из-за сглаживания

Попробуйте уменьшить степень фильтрации в свойствах датчика уровня топлива.

 Пояснения

Уровень топлива в баке колеблется из-за работы двигателя, ускорений, торможений, поворотов, неровностей дороги, наклона транспортного средства и так далее.

Чем больше степень фильтрации, тем сильнее сглаживание, применяемое для компенсации колебаний показаний ДУТ. Чем сильнее сглаживание, тем проще анализировать обработанные данные, однако тем сильнее искажена входная информация. Поэтому для получения требуемой точности степень фильтрации стоит установить на минимально необходимую. Если же степень фильтрации слишком велика, то обработанные данные могут уже не содержать перепада уровня топлива, соответствующего заправке. В большинстве случаев не рекомендуется использовать степень фильтрации выше 10.

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

Также вы можете попробовать включить адаптивную медианную фильтрацию.

2. Заправка отфильтрована по объему

Попробуйте уменьшить значение опции Минимальный объем заправки в свойствах датчика уровня топлива.

 Пояснения

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

Если же установить Минимальный объем заправки слишком большим, то из результатов отчета может исчезнуть фактическая заправка.

3. Заправка происходит при наличии скорости

Скорректируйте настройки Детектора поездок, увеличив Минимальную скорость движения, если скорость не связана с фактической поездкой объекта, а связана с погрешностью исходных данных. Однако если скорость в таких сообщениях соизмерима со скоростью при фактических поездках (например, более 10 км/ч), то подобные сообщения, вероятно, можно удалить, а для избежания подобных ситуаций в будущем можно попробовать их отфильтровать. Пожалуйста, учитывайте, что вы не сможете восстановить сообщения, удаленные вручную или вследствие применения фильтрации валидности сообщений, поэтому к данным шагам стоит подходить с особым вниманием.

 Пояснения

Не всегда скорость, определяемая трекером и отображаемая в системе мониторинга, однозначно говорит о том, что объект движется. Это следует из наличия погрешности у спутниковых систем навигации (GPS, ГЛОНАСС и так далее). Для определения факта движения используется Минимальная скорость движения, которая определяет минимальный порог значения скорости, распознаваемый системой как движение.

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

Другим методом решения является включение опции Поиск заправок только при остановке и увеличение Таймаута для определения полного объема заправки в свойствах датчика уровня топлива.

 Пояснения

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

4. Заправка помечена ложной и затем скрыта

Включите опцию Показывать ложные события в настройках шаблона отчета. Затем выполните отчет еще раз и снимите отметку о том, что заправка является ложной.

  Пояснения

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

Заправки, помеченные как ложные, отображаются в отчете только при включении соответствующей опции.

Ни один из вариантов не подходит

Вероятно, вы столкнулись с более сложной ситуацией, чем рассмотренные выше, и вам стоит обратиться в техподдержку через почту support@wialon.com. Обязательно указывайте в вашем письме точное имя объекта, имя шаблона отчета для проверки, минимальный интервал времени для проверки (например, не месяц, а несколько суток), а также прочие важные детали.

Олег Жарковский,Инженер Customer Service

Не детектируется слив
  • technical_consulting
  • fuel
  • fuel_thefts

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

Возможные причины и их устранение

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

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

1. Слив игнорируется из-за сглаживания

Попробуйте уменьшить степень фильтрации в свойствах датчика уровня топлива.

 Пояснения

Уровень топлива в баке колеблется из-за работы двигателя, ускорений, торможений, поворотов, неровностей дороги, наклона транспортного средства и так далее.

Чем больше степень фильтрации, тем сильнее сглаживание, применяемое для компенсации колебаний показаний ДУТ. Чем сильнее сглаживание, тем проще анализировать обработанные данные, однако тем сильнее искажена входная информация. Поэтому для получения требуемой точности степень фильтрации стоит установить на минимально необходимую. Если же степень фильтрации слишком велика, то обработанные данные могут уже не содержать перепада уровня топлива, соответствующего сливу. В большинстве случаев не рекомендуется использовать степень фильтрации выше 10.

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

Также вы можете попробовать включить адаптивную медианную фильтрацию.

2. Слив отфильтрован по объему

Попробуйте уменьшить значение опции Минимальный объем слива в свойствах датчика уровня топлива.

 Пояснения

Зачастую заявляемая производителями точность ДУТ в 1% не позволяет в реальных условиях детектировать небольшие сливы из-за наличия уже упомянутых выше колебаний топлива в баке. Поэтому сразу устанавливать Минимальный объем слива, например, в 1 литр будет довольно оптимистично. Данная опция является своего рода грубым фильтром, который разделяет слив и обычные колебания уровня топлива, которые будут оставаться даже несмотря на применение фильтрации. Следовательно, Минимальный объем слива стоит выбирать соразмерно значению этих колебаний, которые в некоторых случаях могут достигать даже 20 и более литров.

Если же установить Минимальный объем слива слишком большим, то из результатов отчета может исчезнуть фактический слив.

3. Слив происходит на коротких остановках

Попробуйте уменьшить значение опции Минимальное время остановки для определения слива в свойствах датчика уровня топлива.

 Пояснения

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

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

4. Слив происходит при наличии скорости

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

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

 Пояснения

Не всегда скорость, определяемая трекером и отображаемая в системе мониторинга, однозначно говорит о том, что объект движется. Это следует из наличия погрешности у спутниковых систем навигации (GPS, ГЛОНАСС и так далее). Для определения факта движения используется Минимальная скорость движения, которая определяет минимальный порог значения скорости, распознаваемый системой как движение.

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

5. Слив помечен ложным и затем скрыт

Включите опцию Показывать ложные события в настройках шаблона отчета. Затем выполните отчет еще раз и снимите отметку о том, что слив является ложным.

 Пояснения

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

Сливы, помеченные как ложные, отображаются в отчете только при включении соответствующей опции.

Ни один из вариантов не подходит

Вероятно, вы столкнулись с более сложной ситуацией, чем рассмотренные выше, и вам стоит обратиться в техподдержку через почту support@wialon.com. Обязательно указывайте в вашем письме точное имя объекта, имя шаблона отчета для проверки, минимальный интервал времени для проверки (например, не месяц, а несколько суток), а также прочие важные детали.

Олег Жарковский,Инженер Customer Service

Как избавиться от ложных сливов топлива
  • technical_consulting
  • fuel
  • fuel_thefts

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

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

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

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

Обязательные шаги перед применением инструкций

  • В Wialon создан объект, сообщения от трекера отображаются в системе.
  • Датчик уровня топлива подключен к трекеру, тарировка бака произведена.
  • В объекте создан датчик с типом Датчик уровня топлива (ДУТ).
  • В свойствах ДУТ активирована опция Рассчитывать данные по датчику.
  • Тарировочная таблица (Пары XY) внесена в Таблицу расчета датчика уровня топлива, после чего нажата кнопка Генерировать.
  • Создан шаблон отчета с графиком типа Обычный, который отображает Обработанный уровень топлива.
  • Также график отображает маркеры сливов и фон поездок (по умолчанию он розовый), остановок (голубой) и моточасов (желтый).

Поведение графика в области ложного слива

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

1. Скачки в процессе движения или работы двигателя

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

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

Либо там же вы можете выбрать тип фильтрации Медианная фильтрация для ручной настройки сглаживания. Для этого установите степень фильтрации (например, 3). Обязательно учитывайте, что высокие степени фильтрации стоит применять только при высокой частоте отправки сообщений (1-5 секунд между сообщениями). После применения фильтрации топливные алгоритмы будут работать не с исходными данными, а со сглаженными.

Для проверки эффективности сглаживания добавьте на график линию Уровень топлива (до сглаживания) и сравните ее с линией Обработанный уровень топлива (после сглаживания). Если колебания линии Обработанный уровень топлива все еще кажутся вам значительными, то можно попробовать увеличить степень фильтрации (рекомендуется делать это с шагом в 1). Однако помните, что сглаживание может начать искажать входные данные, а потому нужно найти золотую середину: колебания линии Обработанный уровень топлива уже не кажутся большими (или их совсем нет), но при этом линии до и после сглаживания все еще не слишком отличаются в характерных местах (например, во время фактических заправок/сливов).

 Как работает фильтрация (сглаживание значений датчика)

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

Степень фильтрацииШирина окнаКоличество сообщений до/после центра окна
031


N

N — нечетное5×N(5×N-1)/2
N — четное5×N-1(5×N-2)/2

Пример

Степень фильтрации установлена равной 3. Тогда ширина окна будет составлять 5×3=15. Следовательно, для сглаживания значений уровня топлива берутся 7 сообщений до и 7 сообщений после рассматриваемого сообщения.

Например, для вычисления значения в сообщении номер 61 будут использованы сообщения с 54 по 68.

2. Резкий скачок сразу после начала или прекращения движения

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

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

3. Плавное падение при работе двигателя и отсутствии движения

В системе Wialon существует 2 алгоритма для анализа топлива: алгоритм по пробегу (он используется по умолчанию) и алгоритм по времени. Для стационарных объектов и для объектов с длительными интервалами холостого хода рекомендуется использовать алгоритм по времени. Для этого активируйте 3 опции в свойствах датчика уровня топлива: Расчет заправок по времени, Расчет сливов по времени и Рассчитывать расход топлива по времени. Стоит пояснить, что в рассматриваемом случае можно было бы обойтись только опцией Расчет сливов по времени, но одновременное включение всех опций позволит достичь лучшей сходимости всех топливных показателей в отчетах.

При использовании алгоритма по времени происходит сравнение расхода по ДУТ с расходом по расчету, то есть со значением, рассчитанным по математической модели. На интервалах холостого хода расход по расчету в общем случае определятся по датчику зажигания или датчикам моточасов. Потому откройте свойства датчика зажигания или моточасов и проверьте, верная ли норма расхода в час установлена в поле Расход.

4. Слив во время движения, хотя график выглядит нормально

Наиболее вероятно, вы используете алгоритм анализа топлива по времени, а также активировали опцию Поиск сливов в движении в свойствах датчика уровня топлива. В таком случае происходит сравнение расхода по ДУТ с математически рассчитанным расходом. Если расход по расчету настроен неправильно, то ложный слив может быть детектирован там, где объект просто совершал поездку, а потому рекомедуется проверить математическую модель расхода по расчету. Она задается через:

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

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

5. Значительные скачки до минимума/максимума

Если на графике видны скачки линии Обработанный уровень топлива до 0 или до максимального значения (зачастую это 2¹⁶-1=65535) и обратно к актуальному значению, то даже после применения сглаживания эти скачки могут приводить к детектированию ложных сливов. Такие скачки показаний могут быть связаны с некорректной конфигурацией или подключением датчика уровня топлива к трекеру.

Рекомендуется исправлять данную проблему со стороны оборудования, однако и со стороны Wialon вы можете попробовать отсечь эти показания с помощью Таблицы расчета. Для этого войдите в свойства ДУТ, перейдите во вкладку Таблица расчета и установите значения Нижней границы и/или Верхней границы, соответствующие пустому и полному баку. Однако в нижней границе лучше прописать не 0, а значение близкое к нулю (например, 0.1), чтобы отсечь ложные скачки показаний до 0.

6. Значительные скачки не до минимума/максимума

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

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

  1. Откройте вкладку Сообщения и запросите сообщения с исходными данными за интервал, который включает исследуемый скачок уровня топлива.
  2. Вручную или с помощью фильтра найдите другой параметр, который меняется одновременно с показаниями ДУТ.
    Предположим, это параметр pwr_ext, который для большинства трекеров соответствует внешнему напряжению.
  3. Определите, при преодолении какого значения найденного параметра показания ДУТ изменяются.
    Предположим, что если pwr_ext меньше 12, то ДУТ начинает присылать неправильные показания.
  4. Войдите в свойства объекта и создайте датчик с типом Произвольный цифровой датчик, используя параметр из пункта 3, а затем задайте для него Таблицу расчета со следующими строками:
    X = 0; a = 0; b = 0
    X = 12; a = 0; b = 1
  5. Сохраните созданный датчик и изменения свойств объекта, два раза нажав кнопку ОК.
  6. Снова войдите в свойства объекта, а затем в свойства ДУТ. Укажите датчик из пункта 4 в качестве валидатора с типом Проверка на неравенство нулю.

В примере выше рассматривается реальный случай, так как низкое напряжение действительно зачастую приводит к искажению показаний разных датчиков. То есть между передаваемыми параметрами напряжения и уровня топлива существует прямая связь. Однако вы можете использовать и непрямую связь, если заметите одновременное изменение показаний ДУТ и любого другого параметра. Возможно, трекер не присылает значение напряжения, однако присылает значение температуры, а датчик температуры тоже сбоит и присылает, например, 451 °F в момент скачка напряжения. В таком случае с помощью валидации попробуйте связать ДУТ и значение температуры, что тоже должно исправить ситуацию.

7. Плавное падение после заправки при наличии нескольких соединенных баков с ДУТ в каждом

Подобное изменение показаний ДУТ может быть связано с тем, что у объекта имеется несколько соединенных баков, между которыми происходит перетекание топлива. После заправки в один из баков выравнивание уровней между несколькими баками может занять некоторое время, и если вы создали датчики уровня топлива в Wialon отдельно, то сразу после заправки система может детектировать ложный слив по одному из баков.

При работе с несколькими соединенными баками мы рекомендуем для каждого из ДУТ создавать Произвольный датчик (например, с именами «ДУТ 1» и «ДУТ 2») и вносить в них свою тарировочную таблицу. После этого создайте отдельный датчик с типом Датчик уровня топлива, не вносите в него тарировочную таблицу, а вместо этого просто используйте следующую формулу: [ДУТ 1]+[ДУТ 2]

8. Резкое падение при достижении определенного уровня

Данная ситуация может наблюдаться для баков специфичной формы в момент перехода от широкой части к узкой (например, для баков в форме буквы «Г»). Это особенно вероятно, если тарировка была произведена по слишком малому количеству точек, а зачастую ее делают всего по 2 точкам (при пустом и полном баке). Потому имеет смысл перетарировать бак, используя небольшие порции.

9. Плавное изменение в одно и то же время

Иногда уровень топлива падает/растет в определенные моменты времени, а в некоторых случаях позже даже возвращается к актуальному значению. Происходить это может ночью, или во время поездки (особенно под нагрузкой), или спустя примерно одно и то же время после завершения поездки — то есть выделить общее правило затруднительно.

Предположительные причины:

  • изменение температуры, влияющее на объем топлива, а также на деформацию бака (особенно это касается гибких пластиковых баков);
  • образование «вакуума» из-за разницы давлений (активного забора топлива в двигатель);
  • оседание примесей в топливе или грязи в баке, которая происходит после завершения поездки (тряски).

Решение в большинстве случаев связано с оборудованием: установка крышки с клапаном для выравнивания давления, удаление грязи/осадка в баке или на ДУТ. Однако если ситуация связана только с изменением температуры, то вам помочь может использование датчика с типом Коэффициент температуры (пример его настройки можно найти в документации).

Ни один из вариантов не подходит

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

  1. Точность ДУТ недостаточна для бака данной формы, данного типа ТС, данного характера движения ТС, для данной местности и т.д. Тогда помочь сможет только увеличение настройки Минимальный объем слива в свойствах датчика уровня топлива. По сути это не исправление ситуации, а просто признание низкой точности ДУТ и настройка объекта в соответствии с этой точностью.
  2. Вы столкнулись с более сложной ситуацией, чем описано в выше, и вам стоит обратиться в техподдержку через почту support@wialon.com. Обязательно указывайте в вашем письме краткое описание ситуации со скриншотами, точное имя объекта, имя шаблона отчета для проверки, минимальный интервал времени для проверки (например, не месяц, а одни сутки), а также прочие важные детали.
  3. Вероятно, слив действительно имел место.

Олег Жарковский,Инженер Customer Service

Движение топлива
  • technical_consulting
  • fuel
  • fuel_traffic
  • tables

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

Особенности таблицы

Таблица Движение топлива является необычной по нескольким причинам. Фактически она совмещает в себе три таблицы: Заправки и зарядки батареи, Сливы и Датчики счетчиков. И несмотря на то, что она не доступна для группы объектов, при выполнении отчета по топливозаправщику она может отобразить данные и по другим объектам, принимающим топливо (потребителям).

Данную таблицу можно использовать разными способами:

  1. Для топливозаправщика, чтобы отображать выдачи топлива объектам-потребителям.
  2. Для любого объекта, чтобы выводить одним списком все его заправки и сливы.

  3. Совместить первый и второй способы, чтобы видеть и заправки, и выдачи топливозаправщика.

Далее в статье будет рассмотрен только первый способ, так как по сравнению со вторым он требует более нестандартных настроек.

Необходимые датчики

Тип объектаТип датчикаВозможности
Топливозаправщик

Датчик уровня топлива (ДУТ)

Позволяет отображать выдачи топлива (в виде сливов) и заправки (наполнение цистерны с топливом).
Топливозаправщик

Счетчик

Позволяет отображать объем топлива, выданного через заправочный пистолет-расходомер.

Использование счетчика дает более точный результат по сравнению с ДУТ.

ПотребительДУТПозволяет отображать объем заправки при получении топлива от топливозаправщика.
ТопливозаправщикНазначение водителяДля отображения имени водителя на топливозаправщике должен быть установлен картридер. Предполагается, что водитель заправляемого объекта прикладывает свою карту к картридеру топливозаправщика, чтобы выдача началась, и на это время он назначается на топливозаправщик, а после завершения выдачи водитель должен быть снят с объекта.

Логика работы таблицы

Рассмотрим пошагово логику работы таблицы Движение топлива для случая, когда она выполняется по топливозаправщику.

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

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

Следующим шагом система запускает поиск заправок по найденным вблизи объектам. Поиск происходит точно так же, как в одноименной таблице Заправки и зарядки батареи.

Заправки для потенциальных потребителей рассчитываются за весь интервал построения отчета, а не только за то время, когда они находились рядом с топливозаправщиком во время выдачи. Это объясняется следующим:

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

Если в настройках таблицы включена опция Учитывать только объекты с заправками, то объекты без заправок будут исключены из дальнейшего анализа и отображения. А если данная опция выключена, то в отчет попадут даже те объекты, которые просто находились рядом с топливозаправщиком в момент топливных активностей, но при этом не имели заправок. Предположим, что в рассматриваемом примере опция Учитывать только объекты с заправками включена.

На данный момент система уже вычислила интервалы активности топливозаправщика и интервалы заправок объектов-потребителей. Теперь необходимо их связать.

При работе с заправками в Wialon используются несколько временных меток:

  • Начало заправки — время из первого сообщения интервала заправки.
  • Конец заправки — время из последнего сообщения интервала заправки.
  • Время заправки — время из сообщения, после которого произошел максимальный рост топлива на интервале заправки. Именно это значение выводится в столбец Время в таблице Заправки и зарядки батареи.

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

В рассматриваемом на картинках примере получаем:

  • В строку с топливной активностью 1 будет выводиться заправка потребителя 1.
    В данном случае время (максимальный перепад уровня топлива) заправки потребителя попадает в интервал выдачи.
  • В строку с топливной активностью 2 будет выводиться заправка потребителя 2.
    Время этой заправки не попадает в интервалы выдачи, однако заправка имеет пересечения с несколькими выдачами и будет относится к первой по времени.
  • В одну строку с топливной активностью 3 не будет выводиться ни одна заправка.
    Интервал заправки потребителя 3 не имеет пересечений ни с одной выдачей.
  • Потенциальный потребитель 4 не будет выводиться в отчет.
    У него не было детектировано заправок, а по условию примера в настройках таблицы включена опция Учитывать только объекты с заправками.

Имена потребителей будут отображаться в столбце Геозоны/Объекты, в столбце Заправлено будет содержаться объем заправки потребителя, а в столбце Отклонение — разница между заправкой и выдачей.

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

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

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

  • Чтобы скрыть заправки топливозаправщика, в фильтрации интервалов раскрываем блок Заправки, в нем включаем фильтр Заправки и в выпадающем меню выбираем вариант Без заправок.


  • Если на топливозаправщике не установлен пистолет-расходомер, но при этом на объекте имеются другие счетчики, то они могут повлиять на выводимый результат.
    Чтобы скрыть показания этих счетчиков, в фильтрации интервалов раскрываем блок Датчики, в нем включаем фильтр Маски датчиков и указываем имя, которое не соответствует именам счетчиков.


  • Если на топливозаправщике установлен пистолет-расходомер, то рекомендуется работать с данными, полученными от пистолета-расходомера, а не со сливами, детектированными по ДУТ.
    Чтобы скрыть сливы топливозаправщика, в фильтрации интервалов раскрываем блок Сливы, в нем включаем фильтр Сливы и в выпадающем меню выбираем вариант Без сливов.


  • На данном этапе в зависимости от предыдущих шагов в отчет будут выводиться только выдачи топлива, зафиксированные по ДУТ или по счетчику.
    В обоих случаях для отображения объектов-потребителей и их заправок необходимо отметить нужные объекты или группы объектов в фильтре Геозоны/Объекты и указать радиус приближения. Это фильтр повторяется в каждом из блоков (Заправки, Сливы, Датчики), поэтому настраивать его нужно в том блоке, который вы планируете использовать.
    Также рекомендуется включить опцию Учитывать только объекты с заправками, чтобы скрыть из результата отчета объекты, которые просто находились рядом, но не имели заправок.

    Если рядом было найдено несколько объектов, то в отчет выводится имя объекта с наименьшим радиусом приближения. Если радиусы совпадают, то в отчет выводятся все объекты.

Решение возможных проблем

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

Объемы выдачи или заправки не сходятся

Если в таблице Движение топлива не сходятся объемы, то вам необходимо выполнить те же действия, как если бы некорректные результаты были в таблицах Заправки и зарядки батареи, Сливы и Датчики счетчиков. Вы можете проверить:

  • Наличие параметров датчиков в сообщениях от топливозаправщика и потребителя.
  • Тарировку баков топливозаправщика и потребителя.
  • Коэффициент счетчика топливозаправщика (при его наличии).
  • Дополнительные настройки топливных датчиков топливозаправщика и потребителя.

Возможно, вам будут полезны другие статьи на тему топлива из раздела Другие материалы.

Потребитель не отображается или отображается неправильно

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

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

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

Выдача разделяется на несколько частей

Если выдача определяется по счетчику, то в блоке Датчики в настройках таблицы Движение топлива вы можете задать условие объединения интервалов. Например, если установить Таймаут на 30 секунд, то интервалы работы счетчика, между которыми прошло менее 30 секунд, будут объединены.

Если выдача определяется по ДУТ, то вы можете увеличить Таймаут для разделения сливов в свойствах ДУТ.

Выдачи не разделяются

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

Также вы можете применить рекомендации из предыдущего пункта, но наоборот: уменьшить Таймаут в условии объединения интервалов или уменьшить Таймаут для разделения сливов в свойствах ДУТ.

Много небольших лишних выдач

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

Правильнее всего будет отремонтировать оборудование, однако со стороны Wialon вы можете установить минимальную Границу значений датчика счетчика в настройках таблицы Движение топлива, что позволит игнорировать небольшие выдачи.

Водители не отображаются корректно

Водители могут не отображаться в отчете, либо во всех строках может отображаться один водитель.

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

Попробуйте изучить логику автоматического назначения и снятия водителей. Вам может понадобиться проверить:

  • Наличие параметров датчика назначения водителя в сообщениях от топливозаправщика.
  • Настройки датчика назначения водителя, включая код снятия.
  • Свойства водителей, а именно их коды.
  • Настройку списка автоматического назначения.

Ни один из вариантов не подходит

Вероятно, вы столкнулись с более сложной ситуацией, чем рассмотренные выше, и вам стоит обратиться в техподдержку через почту support@wialon.com. Обязательно указывайте в вашем письме точное имя объекта, имя шаблона отчета для проверки, минимальный интервал времени для проверки (например, не месяц, а несколько суток), а также прочие важные детали.

Олег Жарковский,Инженер Customer Service

Не срабатывает команда
  • technical_consulting
  • commands
  • sms

Wialon не только принимает данные от трекеров, но также может отправлять на них команды. В данной статье вы найдете условия для выполнения команд, описание особенностей разных каналов отправки команд, а также возможные проблемы и варианты их решения.

Условия для выполнения команд

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

  1. В учетной записи включена услуга Команды.



  2. Пользователь обладает специальным правом Отправка команд в отношении объекта.



  3. Команда создана на одноименной вкладке Команды в свойствах объекта.


    Для создания команд пользователь должен обладать специальным правом Создание, редактирование и удаление команд в отношении объекта.

  4. Для выполнения команд по каналу SMS существует еще несколько дополнительных условий:
    • В учетной записи включена услуга SMS-сообщения.

    • В сервисе должны быть доступны SMS, то есть счетчик на верхней панели должен быть больше нуля.

      Данный счетчик не отображается, если в сервисе для отправки SMS используется персональный модем.

    • На вкладке Основное в свойствах объекта должен быть указан Телефонный номер в международном формате, на который трекер будет получать SMS.

Особенности каналов отправки команд

Канал (тип связи) для отправки команды выбирается в ее свойствах. В зависимости от выбранного канала при выполнении команды необходимо учитывать состояние соединения объекта с сервером.

Объект поддерживает интернет соединение с сервером, если от него приходят сообщения с данными или keep alive/heart beat пакеты. Для проверки нынешнего статуса соединения можно использовать столбец Состояние соединения на панели Мониторинг.

КаналОсобенности

GPRS (TCP/UDP)

Объект обязательно должен поддерживать интернет соединение с сервером.

Virtual

Данный канал аналогичен по принципу отправки с TCP/UDP, однако виртуальная команда может быть выполнена, даже когда объект не подключен к серверу. В момент выполнения команда становится в очередь, а ее фактическая отправка будет произведена в момент выхода объекта на связь.

Для каждого типа устройства в Wialon предусмотрено ограничение количества виртуальных команд в очереди, а при переполнении очереди новая виртуальная команда вытеснит из очереди самую старую команду (она не будет отправлена).
SMSОбъект может не поддерживать интернет соединение с сервером.
АвтоПри отправке программа сама выберет тот канал, который доступен в данный момент. Если доступно несколько типов, то использован будет тот канал, который находится выше в данной таблице.
Если выбранный для команд канал связи в данный момент доступен, то кнопка выполнения команды напротив объекта в панели Мониторинг станет активной.

Проверка отправки команды со стороны Wialon

Факт выполнения команды фиксируется в Журнале объекта. Также эта информация доступна для просмотра:

  • на вкладке Сообщения при запросе Отправленных команд;
  • на вкладке Сообщения при запросе SMS-сообщений;
  • в отчете с таблицей Отправленные команды.

Запись о выполнении команды в журнале означает, что команда была выполнена со стороны Wialon. Далее она отправляется по TCP/UDP каналу или передается модему/SMPP шлюзу на отправку.

Если команда не была выполнена при нажатии соответствующей кнопки, то следует проверить соблюдение вышеуказанных требований. Ели все требования были соблюдены и объект не терял связь в момент выполнения команды, то вы можете отправить на support@wialon.com подробное описание проблемы (имя пользователя, объект, имя команды и время выполнения) для анализа специалистами технической поддержки Wialon.

Возможные проблемы и методы их решения

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

ПроблемаВозможные причиныВарианты действий
SMS-команда не доставлена на объект

Проблемы с доставкой SMS-сообщений и TCP/UDP команд обычно связаны с проблемами на уровне сетей операторов связи/интернет провайдеров. Следует совместно с провайдером проверять маршрут доставки сообщения, устранять неполадки сети или искать другие маршруты доставки.

Если вы используете пакет 500 SMS, напишите техподдержке Wialon на support@wialon.com.
Если вы используете собственный SMPP шлюз или модем, обратитесь к вашему SMPP провайдеру или GSM оператору для анализа ситуации.

Команда доставлена, но с некорректным текстом

Обычно такая проблема связана с кодировкой оператора связи и актуальна в основном для SMS-сообщений. В Wialon используется стандартная кодировка A5 (CCITT T.50)/ASCII (ANSI X3.4). Оператор связи получателя может использовать другой протокол и в результате не верно декодировать сообщение.

Пользователь должен связаться с оператором связи получателя для исправления ситуации.

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

В SMS задан неверный формат команды. Необходимо перепроверить синтаксис согласно руководству по прибору или обратиться к производителю оборудования.

Если используются стандартные команды Wialon (кроме Произвольное сообщение), убедитесь, что в команде переданы корректные параметры (например, номер входа трекера для активации). Также вы можете обратиться в техподдержку Wialon по адресу support@wialon.com, предоставив подробное описание проблемы.

SMS команда получена от номера отправителя, который не внесен в список разрешенных.

Внесите разрешенный номер в настройках трекера.

Команда получена с неразрешенного трекеру IP.

Внесите разрешенный IP в настройках трекера. IP в Wialon Hosting зависит от дата-центра сервиса, и его можно видеть во вкладке Основное в свойствах любого объекта.

В настройках объекта не введен Пароль для выполнения команд (или он не совпадает с паролем в трекере).

Перепроверьте пароль для выполнения команд. Для пароля рекомендуется использовать латиницу, т.к. другие языки могут декодироваться трекером некорректно.

Трекер не исправен.

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

Команда доставлена, выполнена трекером, но не получен ответ в системе Wialon

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

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

Команда поступила c виртуального номера, который не может выступать в качестве получателя SMS.

В Wialon Hosting используется виртуальный номер 79037676122. Вы можете обратиться в техподдержку Wialon по адресу support@wialon.com и уточнить возможность переключения вашего сервиса на другой доступный телефонный номер отправителя, чтобы получать SMS ответы трекеров на этот номе.
Если из-за особенностей маршрутов доставки SMS в определенную страну вы не можете задать другой номер отправителя для отправки SMS, то наиболее удобным решением будет подключить для своего сервиса Hosting собственный SMPP шлюз с возможностью приема SMS от трекеров. По вопросу подключения своего SMPP шлюза к сервису Hosting обратитесь к вашему менеджеру (или к техподдержке Wialon за техническими консультациями).


Сергей Новиков,Инженер Customer Service

Уведомления в Telegram
  • technical_consulting
  • notifications_to_telegram

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

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

Часть информации (токены и ID) в инструкциях будет скрыта, так как это приватная информация. На понимание инструкций это не влияет.

Предварительные требования

Необходимо создать бота, следуя инструкции. Здесь и далее будем предполагать, что Telegram установлен на вашем компьютере или телефоне. Работу по настройке можно вести в обеих версиях, однако делать это на компьютере проще, так как вам придется копировать информацию в настройки уведомления в Wialon.

Категории уведомлений

Условно, уведомления можно разделить на две категории:

  • индивидуальные — для одного выделенного пользователя (например клиент с одним личным автомобилем);
  • массовые — для нескольких пользователей сразу (например одной группы, команды, отдела, компании).

Настройка для Telegram уведомлений в Wialon одна — нужно задать Токен бота и ID канала:

Обычно вопросы возникают с ID канала. Именно от того, как вы заполните это поле, зависит, будет ли уведомление индивидуальным или массовым.

Индивидуальные уведомления

Открываем следующую ссылку на компьютере или на телефоне с установленным Telegram: https://telegram.me/userinfobot

Отправляем команду для начала работы и в ответ получаем собственный ID:

Этот собственный ID и задаем в настройках уведомления:

При срабатывании такого уведомления, сообщение придет в чат бота, и увидите его только вы:

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

Чтобы узнать ID другого пользователя, просто перенаправьте ему сообщение этого пользователя (например, из вашей переписки с данным пользователем):

Массовые уведомления

Публичный канал

С массовой отправкой сразу нескольким пользователям все проще. Достаточно создать публичный канал Telegram, добавить туда бота и разрешить ему управлять уведомлениями.

В качестве ID канала для настройки уведомления в Wialon нужно использовать ID канала:

Берем только «pach_test» (без символов «t.me/»), ставим префикс «@» и добавляем в уведомление в Wialon:

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

Закрытый канал

Создаем открытый канал, добавляем туда бота администратором. Отправляем запрос от имени бота в этот канал, вставив в адресную строку браузера следующую ссылку и нажав Enter:

https://api.telegram.org/bot/sendMessage?chat_id=@yourchannelname&text=ping

Заменяем токен на токен своего бота:

Указываем ID своего канала:

Вставляем в адресную строку браузера и нажимаем Enter, например:

https://api.telegram.org/bot775ххххххх:AAH5Kp_cххххххххххххххххх/sendMessage?chat_id=@gurtamstudy&text=ping

В ответ получаем:

{"ok":true,"result":{"message_id":17,"chat":{"id":-1001xxxxxxxxx,"title":"Study","username":"gurtamstudy","type":"channel"},"date":1593066856,"text":"ping"}}

Удаляем сообщение, делаем канал закрытым. Вместо @yourchannelname в настройках уведомления используем значение «id»: -1001xxxxxxxxx

Закрытая группа

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

Создаем открытую группу, добавляем туда бота (можно без прав администратора). Отправляем запрос от имени бота в эту группу, вставив в адресную строку браузера следующую ссылку и нажав Enter:

https://api.telegram.org/bot/sendMessage?chat_id=@yourgroupname&text=ping

Заменяем токен на токен своего бота:


Указываем ID своей группы:

Вставляем в адресную строку браузера и нажимаем Enter, например:

https://api.telegram.org/bot775ххххххх:AAH5Kp_cххххххххххххххххх/sendMessage?chat_id=@gurtam_study&text=ping

В ответ получаем:

{"ok":true,"result":{"message_id":2,"from":{"id":775ххххххх,"is_bot":true,"first_name":"pach_test","username":"pach_bot"},"chat":{"id":-1001xxxxxxxxx,"title":"Study group","username":"gurtam_study","type":"supergroup"},"date":1593070025,"text":"ping"}}


Удаляем сообщение, делаем группу закрытой. Вместо @yourgroupname в настройках уведомления используем значение «id»: -1001xxxxxxxxx

Павел Чеботарёв,Инженер Customer Service

Тахографы и Wialon
  • technical_consulting

Тахограф — это устройство, которое контролирует режим труда и отдыха (РТО) водителей, а также скорость движения транспортного средства, пройденный им путь и страну нахождения. Использование подобного устройства позволяет минимизировать риск возникновения аварийных ситуаций из-за усталости водителя и оптимизировать работу автопарка. Необходимость установки тахографа определяется законом.

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

Юридический аспект

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

В Wialon поддержано только «Европейское соглашение, касающееся работы экипажей транспортных средств, производящих международные автомобильные перевозки», или сокращенно ЕСТР (в оригинале это соглашение называется AETR, от французского Accord Européen sur les Transports Routiers). Это единое соглашение о работе экипажей транспортных средств на территории европейских стран.

 Правила других стран

Перечисляемые далее правила не поддержаны в Wialon, однако о них может быть полезно знать:

  • В Российской Федерации правила использования тахографов определяются приказами Министерства транспорта РФ (в частности, приказом от 13 февраля 2013 г. №36 г. Москва).
  • В США функцию тахографов выполняют электронные устройства регистрации (electronic logging devices, ELD), а правила, которые определяют режим работы и отдыха водителей, называются Hours of Service (HOS). Для учета HOS на основе Wialon была создано решение Apollo ELD, познакомиться с которым можно на следующем сайте: eld.wialon.com
  • В Австралии закон о тахографии называется Heavy Vehicle National Law and Regulations (NHVL).

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

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

Режимы работы

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

ПиктограммаНазваниеАльтернативные
названия
Описание

ВождениеУправление,
«колесо»‎‎‎,
«руль»‎‎‎

Используется для регистрации длительности непосредственного управления ТС.

Включается автоматически, когда карточка водителя вставлена в первый слот, двигатель включен, а скорость ТС не равна нулю.

Работа

Другая работа,
иные работы,
«молотки»

Используется для регистрации работы, которая не является вождением (оформление документов, погрузочно-разгрузочные работы и прочее).

Включается вручную или автоматически, когда карточка водителя вставлена в первый слот, двигатель включен, а скорость ТС равна нулю.

ОтдыхПерерыв,
«кровать»,
«стул»‎

Используется для регистрации отдыха.

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

РезервДоступность,
готовность,
ожидание,
«конверт»

Используется при наличии в экипаже ТС второго водителя.

Включается автоматически, когда карточка водителя вставлена во второй слот, а для первого водителя отображается режим «Вождение» или «Работа».

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

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

Примеры правил РТО

Чтобы иметь представление о том, какие критерии использует тахограф при контроле РТО, можно рассмотреть некоторые из правил ЕСТР:

  • Без остановки на перерыв можно ехать максимум 4,5 часа. После этого должен быть сделан перерыв на 45 минут.

     Примеры

    Пример 1. Водитель проехал 4,5 часа, а потом сделал перерыв на 45 минут. В данном случае нарушений нет.

    Пример 2. Водитель проехал 4,5 часа, а потом сделал перерыв на 30 минут. Это нарушение, так как продолжительность перерыва недостаточная.

  • Если в пределах 4,5 часов вождения сделать перерыв продолжительностью более чем 15 минут, но менее чем 45 минут, то в конце периода 4,5-часового вождения можно сделать перерыв такой длительности, которая в сумме с предыдущим перерывом составит 45 минут. Если же перерыв длится менее 15 минут, то он не будет засчитан.

     Примеры

    Пример 1. Водитель проехал 2 часа, сделал перерыв на 20 минут, потом проехал еще 2,5 часа и сделал перерыв на 25 минут. В данном случае нарушений нет, так как на период 4,5-часового вождения суммарно получилось 45 минут отдыха.

    Пример 2. Водитель проехал 2 часа, сделал перерыв на 10 минут, потом проехал еще 2,5 часа и сделал перерыв на 35 минут. Это нарушение, так как первый перерыв длился менее 15 минут, а потому не был засчитан. В результате на период 4,5-часового вождения суммарно не получилось 45 минут отдыха.

  • Максимальное время вождения в течение одной рабочей недели составляет 56 часов, а за две следующие друг за другом недели — 90 часов.

     Примеры

    Пример 1. Время вождения в первую неделю составило 50 часов, во вторую — 40 часов, а в третью — опять 50 часов. В данном случае нарушений нет, так как в каждую отдельную неделю лимит в 56 часов не был превышен, и суммарно для каждых двух последовательных недель был соблюден лимит в 90 часов.

    Пример 2. Время вождения в первую неделю составило 50 часов, во вторую — 50 часов, а в третью — 40 часов. В данном случае нарушение имеется: несмотря на то, что в каждой отдельной неделе лимит в 56 часов не был превышен, суммарно за первую и вторую недели был превышен лимит в 90 часов.

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

Устройство тахографов

Обычно тахографы делят на аналоговые и цифровые.

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

Цифровые имеют прямоугольную форму и устанавливаются в гнездо автомагнитолы (головного устройства). Техническая реализация цифрового тахографа представляет из себя зашифрованную систему постоянного энергонезависимого хранения данных с ограничением доступа к данным и термопринтером для вывода отчетов. Далее в статье будет идти речь только об этом типе тахографов.

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

Доступ к памяти тахографа осуществляется при помощи 4 видов пластиковых ключей-карт:

  1. Карта водителя — позволяет водителю сохранять данные о режимах работы за 28 дней.
  2. Карта компании/предприятия — позволяет транспортной компании считывать данные о рейсах ее транспортных средств.
  3. Карта мастерской — позволяет техническим специалистам настраивать тахограф.
  4. Карта контролера/инспектора — позволяет правоохранительным органам считывать допущенные водителем нарушения и произошедшие сбои в работе оборудования.

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

В Wialon можно отобразить только данные с карты водителя. Работа возможна с форматом DDD и прочими схожими по структуре форматами (например, TGD, V1B, C1B).

Контроль РТО в Wialon

Предыдущие разделы являются своеобразным введением в тему тахографии и контроля РТО. Далее перейдем к непосредственной работе в рамках Wialon.

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

Так как в получении информации участвует связка «тахограф-трекер-Wialon», то возможные проблемы не всегда получается решить со стороны Wialon.

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

Источники информации о РТО

Отображаемая в Wialon информация о РТО может быть получена из нескольких источников.

Файл с карты водителя

Тахограф хранит в памяти файлы с разными данными. Информация о РТО конкретного водителя сохраняется на его карту. Загрузить файл с карты водителя в Wialon можно по-разному в зависимости от модели трекера:

  • С помощью команд — в разделе FAQ можно найти инструкцию об этом. Подобный метод доступен для трекеров, которые отображаются в списке поддержанных устройств по фильтру Загрузка файлов с тахографа.
  • Через стороннее ПО, например, подключив трекер к компьютеру. Далее файл нужно загрузить в Wialon через веб-приложение Tacho Manager и при загрузке выбрать, к какому водителю он относится.

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

Файл с карты водителя является единственным достоверным источником для вывода тахографической информации в Wialon. Контролер видит данные из этого же источника при проверке показаний тахографа на дороге.

Назначения и поездки

Тахограф определяет режим работы по наличию скорости у ТС, статусу зажигания и наличию карты в слоте. Эти данные имеются в Wialon и без тахографа: поездки, которые могут рассчитываться по датчику зажигания и скорости, и назначения/снятия водителей. Поэтому активность водителя можно определить по сообщениям от трекера, даже если на объект не установлен тахограф.

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

Онлайн-данные

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

  • Параметры от тахографа, которые трекер определяет по текущему режиму тахографа. На момент написания статьи такая возможность реализована только у трекеров производства Sensata INSIGHTS (ex-BCE)Teltonika и Navtelecom.
  • Назначения водителей и поездки из Wialon.

Рассчитанные по любому из источников онлайн-данные связываются с элементом Водитель.

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

Отображение информации о РТО

Отобразить информацию о РТО в Wialon можно несколькими способами.

Tacho View

Веб-приложение Tacho View визуализирует информацию о РТО в виде цветных диаграмм и отчета об активности водителя или нарушениях режима.

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

Отчет по водителям

Таблица Активность водителя показывает информацию о РТО.

Таблица Нарушения режима работы показывает информацию о нарушении РТО.

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

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

Дополнительная информация об объекте и водителе

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

При наведении курсора на водителя информация о РТО и его нарушениях будет выводиться во всплывающую подсказку.

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

Источником информации для этого способа отображения всегда являются онлайн-данные.

Олег Жарковский,Инженер Customer Service

Работа с модулем Маршруты
  • technical_consulting
  • routes

Исходя из названия, модуль Маршруты должен подходить при любом запросе о контроле пути транспортного средства. Однако данный модуль имеет особенности, из-за которых он идеально подходит для решения некоторых задач и совершенно не подходит для других. Разные варианты контроля маршрутов упоминались в митапе 4 варианта контроля маршрута в Wialon. Как выбрать подходящий. В данной статье будут рассмотрены ключевые настройки модуля Маршруты и примеры его применения.

Общая концепция

Слово «маршрут» часто используется в повседневной речи, но в Wialon оно является термином. Во избежание путаницы договоримся, что в рамках этой статьи слово «маршрут» будет использоваться только в качестве термина.

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

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

Главные вопросы, на которые необходимо ответить при использовании модуля Маршруты, звучат следующим образом:

  • Как будут добавляться контрольные точки?
  • Какой тип расписания будет использоваться?
  • Какой порядок прохождения контрольных точек будет выбран?
  • Как будет создаваться рейс?
  • Как будет отслеживаться результат?

Каждый из этих вопросов имеет 3 варианта ответов. Давайте разберемся с каждым из них.

Добавление контрольных точек

Первый слой маршрутов — это контрольные точки, которые в него входят. Контрольные точки являются областями на карте, которые должен посетить объект. Добавить их можно тремя методами:

  1. Добавление точек с карты похоже на работу с инструментом Адрес: вы можете сделать двойной щелчок по необходимому месту на карте либо ввести адрес в соответствующую строку. Найденная точка будет являться центром контрольной точки. По умолчанию радиус равен 100 метрам, при необходимости его можно изменить вручную.

    Аналогичным образом контрольные точки маршрута можно добавить через инструмент Маршрутизатор, а затем сохранить результат в виде маршрута.

  2. Добавление точек из числа геозон подразумевает выбор нужной геозоны из списка доступных. В данном случае радиус не нужно указывать, так как геозона уже имеет определенную площадь.
  3. Добавление точек из числа объектов аналогично предыдущему методу: необходимо просто выбрать объект из списка. Так как объект соответствует точке, то для него нужно задать радиус (по умолчанию он равен 100 метрам).

    Использование объекта в качестве контрольной точки кажется странным методом, однако у этого метода могут быть варианты практического применения. Например, объектом, который проходит маршрут, может быть грузовик, а подвижными контрольными точками будут комбайны, которые собирают урожай. С другой стороны, объект-точка может быть и стационарным, если речь идет, например, про топливную станцию, на которую установлен трекер, и она заведена в Wialon в качестве объекта.

Важным этапом при создании контрольных точек является оптимизация порядка посещения точек. В процессе оптимизации на карте отображается предполагаемая наиболее короткая дорога между контрольными точками, однако после сохранения маршрута контрольные точки будут просто соединены пунктирными линиями, так как модуль Маршруты не следит за местоположением объекта между контрольными точками.

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

Также маршруты нельзя переносить из одной учетной записи в другую.


Типы расписаний

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

Существуют расписания трех типов:

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

    Данный тип расписания учитывает не только время, но и конкретную дату.


  2. Относительно суток — использовать такое расписание можно один раз в день.

  3. Относительно активации — использовать такое расписание можно несколько раз в день.

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

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

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

На схемах выше приведены примеры заполнения поля Прибытие для разных типов расписаний. Кроме него для каждой из контрольных точек можно заполнить поле Отправление, что позволяет зафиксировать время, которое объект должен провести в точке. Также для каждого времени можно указать допустимое Отклонение, то есть временной коридор разрешенного опережения/опоздания.

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

Порядок прохождения точек

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

  1. Строгий — все контрольные точки должны быть пройдены в установленном порядке без пропусков.
  2. Возможны пропуски — посещение точек ожидается в указанном порядке, но их можно пропускать, при этом посещение последней точки является обязательным.
  3. Произвольный — контрольные точки можно проходить в любом порядке.

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

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

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

Создание рейсов

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

Создать рейс можно тремя методами:

  1. Вручную — данный метод может использоваться при наличии диспетчера, который может создавать рейс в нужный момент времени. Маловероятно, что такой подход подойдет при наличии большого количества рейсов.
  2. Автоматически для расписаний с типом Относительно суток — данный тип расписания однозначно определяет время создания рейса в любой день, поэтому достаточно выбрать в расписании объекты и включить опцию Создавать рейсы по этому расписанию автоматически.
  3. Автоматически при помощи уведомлений с типом действия Создать рейс — данный метод логично сочетается с расписаниями с типом Относительно активации.

    Например, можно создать уведомление, которое будет запускать рейс при выезде объекта из геозоны.


    При подобной настройке любой выезд объекта из геозоны-базы будет приводить к созданию рейса. Поэтому если объект покидает базу не только для выезда на рейс, то необходимо использовать дополнительные критерии, чтобы отличать эти выезды друг от друга. Например, объект может выезжать на рейс только в определенное время, или только с назначенным водителем, или только при нажатой кнопке «Готов к работе» в кабине и т. д.

Методы отслеживания

Для отслеживания маршрутов можно применять разные подходы:

  1. Отчеты позволяют собрать информацию о маршруте за прошедший период. Для объекта и группы объектов можно использовать таблицы Рейсы и Контрольные точки, а для отчета по маршрутам — таблицы Рейсы и Журнал.
  2. Уведомления позволяют отслеживать рейсы в реальном времени. Единственный тип уведомления Прохождение маршрута включает в себя:
    • статус рейса — начат, завершен, прерван;
    • активность в контрольных точках — прибытие, отправление, пропуск;
    • контроль расписания — опоздание, опережение, возвращение в расписание.

  3. Временная шкала также позволяет отслеживать рейсы в реальном времени. Это особая панель, которая доступна в нижней части вкладки Маршруты. Главная ее особенность заключается в том, что на ней не видны объекты, но зато на шкале отображается расписание в виде диапазонов от Прибытия до Отправления (при нажатии на иконку  диапазон будет расширен с учетом разрешенного Отклонения), а вертикальная черта соответствует текущему времени.

    Так как на шкале не отображается объект, то по шкале нельзя понять, насколько далеко он находится от контрольной точки. Сделать это можно только с помощью карты.

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

Примеры настройки

При использовании модуля Маршруты необходимо выполнить целый ряд настроек, о которых речь велась выше. Для удобства они собраны в таблицу-шпаргалку, где в каждом из столбцов нужно выбрать один из вариантов.

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

Контрольные точкиРасписание*Порядок прохождения точекСоздание рейсаОтслеживание
АдресаАбсолютноеСтрогийВручнуюОтчеты
ГеозоныОтносительно сутокВозможны пропускиАвтоматически (относительно суток)Уведомления
ОбъектыОтносительно активацииПроизвольныйАвтоматически (уведомления)Временная шкала

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

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

Доставка выпечки в магазины

Каждое утро грузовик должен доставлять свежую выпечку из пекарни в одни и те же точки продаж. Разгрузка и заполнение накладных в каждой точке суммарно занимают 10 минут, разрешенное время опоздания — 5 минут.

Предлагаемая настройка:

  • Контрольные точки можно добавить через адреса или геозоны.
  • Рейс выполняется один раз утром, поэтому подойдет расписание относительно суток.
    Для каждой точки поле Отправление будет содержать время на 10 минут больше, чем поле Прибытие. В поля Отклонение нужно ввести 5 минут.
    Ограничение по времени не требуется.
  • Так как оптимальный порядок посещения можно рассчитать заранее и пропускать точки не нужно (партии выпечки не такие большие, их всегда разбирают за день), то порядок прохождения точек будет строгий.
  • Время отправления каждый день одинаковое, поэтому создавать рейс можно автоматически (относительно суток).
  • Предположим, что в процессе доставки не ожидается проблем, которые нужно решать в реальном времени, поэтому для отслеживания подойдет отчет по объекту с таблицей Рейсы.

Настройка расписания

Доставка воды для кулеров

Фургон развозит 5-галлонные бутыли с водой для офисных кулеров. Клиенты являются постоянными, их база имеется в системе. Однако не все клиенты успевают выпить всю воду к среде (это стандартный день доставки), поэтому существует дополнительный день доставки – четверг. Точное время посещения точек несущественно, имеется лишь приблизительный диапазон: с 10:00 до 14:00. Из-за гибкости графика время разгрузки и заполнения накладных можно не учитывать.

Предлагаемая настройка:

  • Контрольные точки можно добавить через адреса или геозоны. В качестве последней точки можно указать склад, с которого начинается и в котором заканчивается доставка.
  • Рейс выполняется один раз в середине дня, поэтому подойдет расписание относительно суток.
    В поле Прибытие для всех точек можно указать время 12:00. Поле Отправление можно не заполнять. В поля Отклонение можно указать 2 часа.
    Ограничение по времени: только среда и четверг.
  • Так как не все точки нужно посещать в один день, то в качестве порядка прохождения точек нужно выбрать вариант Возможны пропуски.
  • Время отправления каждый день примерно одинаковое, поэтому создавать рейсы можно автоматически (относительно суток).
    Дополнительный рейс в четверг можно запускать вручную, если в нем имеется необходимость, но в таком случае в ограничении по времени в расписании нужно указать только среду, чтобы автоматическое создание рейса происходило только в этот день.
  • Клиенты периодически связываются с администратором, чтобы уточнить статус доставки в реальном времени, поэтому для отслеживания можно использовать уведомления и временную шкалу.

Настройка расписания

Настройка ограничения по времени

Маршрутное такси

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

Предлагаемая настройка:

  • Контрольные точки можно добавить через адреса или геозоны. Точка ожидания пассажиров в начале маршрута обведена геозоной. Первая точка маршрута находится сразу за этой геозоной.
  • Рейс может выполняться несколько раз в день, поэтому подойдет расписание относительно активации.
    Поле Прибытие для первой точки равно 00:00, а для остальных точек заполняется относительно первой точки. Так как микроавтобус проводит мало времени на каждой остановке, то поле Отправление можно не заполнять. В поле Отклонение можно ввести любое значение, исходя из обычной ситуации на данном маршруте (например, 10 минут).
    Ограничение по времени: суббота и воскресенье.
  • Речь идет про конкретный маршрут общественного транспорта, поэтому порядок прохождения точек будет строгий.
  • Так как объект начинает движение только после того, как в салоне наберется достаточное количество людей, то точное время начала рейса неизвестно. Создавать рейс придется с помощью уведомления, а критерием для запуска будет выезд из геозоны в начале маршрута, где ожидались пассажиры.
  • Предположим, что в процессе доставки не ожидается проблем, которые нужно решать в реальном времени, поэтому для отслеживания подойдет отчет по объекту с таблицей Рейсы.

Создание геозон для контрольных точек

Настройка расписания

Настройка ограничения по времени

Выбор типа уведомления для запуска рейса

Выбор способа действия в уведомлении

Олег Жарковский,Инженер Customer Service

Как выбрать вариант контроля маршрутов
  • technical_consulting
  • routes
  • geofences

Wialon позволяет закрывать потребности клиентов разными способами. Например, в системе существует минимум четыре варианта контроля маршрутов, каждый из которых имеет свои преимущества и недостатки. Эта статья поможет их сравнить, чтобы выбрать именно тот вариант, который нужен клиенту.

Рассматриваемые варианты

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

  • Модуль Маршруты — несмотря на свое название, данный модуль подходит не для всех случаев, а только при наличии конкретного времени посещения точек и при отсутствии необходимости отслеживать путь между ними.

  • Сочетание геозон, отчетов и уведомлений (упрощенно будем называть этот вариант Геозоны) — наиболее гибкий вариант, который подойдет для большинства ситуаций, однако потребует настройки нескольких отдельных элементов.

  • Веб-приложение Logistics — нишевое решение для организации работы курьерских служб, которое, однако, можно использовать и для решения других бизнес-задач.

  • Веб-приложение NimBus — нишевое решение для общественного транспорта, которое также можно использовать для решения других бизнес-задач.

Терминология, используемая в рассматриваемых вариантах, отличается друг от друга:


МаршрутыГеозоныLogisticsNimBus
Точка для посещенияконтрольная точкагеозоназаявкаостановка
Совокупность точек в рамках одного выездамаршрут

планируемый маршрут
или шаблон
маршрут
Время посещения точекрасписаниеограничение по временивремя планируемого прибытиярасписание
Движение объекта по совокупности точекрейсактивный маршрутрейс

Стоит учитывать эту разницу при сравнении рассматриваемых вариантов.

Сравнение по критериям

Теперь рассматриваемые варианты будут сведены в таблицу, в которой будет отмечено, насколько они удовлетворяют разным критериям, то есть требованиям клиента. Мы постарались сделать эти критерии максимально практико-ориентированными, опираясь на опыт общения с нашими партнерами.

Критерии

МаршрутыГеозоныLogisticsNimBus

Базовые
1Одни и те же контрольные точки каждый деньдададада
2

Новые контрольные точки каждый день

нетчастичноданет
3Отслеживание пути между контрольными точкаминетдадада
4Оптимизация последовательности точекдачастичноданет
5Оптимизация пути между точкаминетчастичнодада
6

Автоматический запуск слежения за рейсом

даданетда

Специфические
7Дополнительные условия посещения точекнетчастичноданет
8Расписание относительно выезда
данетчастичнода
9Замена транспорта в процессе выполнения рейсанетчастичнодада
10Длительный маршрут (более 2 суток)дададанет
11Подвижные контрольные точкидаданетнет
12Отправка маршрутов водителючастичночастичноданет

Вывод информации
13Онлайн-контрольдададада
14Отчеты за предыдущий периоддададада
15Отображение в интерфейсе мониторингададачастичнонет
16Мобильное приложениенетдадачастично

Теперь рассмотрим каждый из критериев отдельно.

1. Одни и те же контрольные точки каждый день

Маршрутыда

Маршруты позволяют запускать рейсы с одними и теми же контрольными точками каждый день, если используются расписания Относительно суток или Относительно активации.

ГеозоныдаГеозоны не удаляются после их посещения, поэтому их легко можно использовать в разные дни.
Logisticsда

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

NimBusда

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

2. Новые контрольные точки каждый день

Маршрутынет

Новые точки нельзя добавлять в уже сохраненный маршрут. Чтобы добавить новые точки, необходимо создавать новый маршрут с нуля, заново настраивая для него расписания и создание рейсов, что трудозатратно.

ГеозонычастичноСоздание новой геозоны, а также добавление ее в отчеты и уведомления не является проблемой. Относительно много времени может потребовать настройка только в том случае, когда имеется необходимость контроля времени посещения точек (через Ограничение по времени в отчетах и уведомлениях).
Logisticsда

Новый маршрут с учетом новых заявок можно создать очень быстро. Добавление точек в уже созданный маршрут также доступен.

NimBusнет

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

3. Отслеживание пути между контрольными точками

Маршрутынет

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

ГеозоныдаДля отслеживания пути между точками можно создать геозону-линию на дорогах, по которым должен следовать объект. Для контроля выезда из геозоны-линии или возвращения в нее можно использовать уведомления с типом Геозона.
Logisticsда

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

NimBusда

В приложении существует уведомление с типом Съезд с линии маршрута. Оно срабатывает после получения от объекта сообщения, которое удалено от линии маршрута более чем на 50 метров.

4. Оптимизация последовательности точек

Маршрутыда

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

ГеозонычастичноВ интерфейсе мониторинга существует инструмент Маршрутизатор, который, среди прочего, позволяет оптимизировать последовательность точек и сохранить результат в качестве геозон.
Logisticsда

При планировании маршрута приложение автоматически оптимизирует порядок точек с учетом множества критериев, а также позволяет менять порядок точек вручную.

NimBusнет

Порядок точек в приложении фиксируется вручную при создании маршрута.

5. Оптимизация пути между точками

Маршрутынет

Модуль не отслеживает путь между точками. Путь отображается только на этапе оптимизации порядка точек.

ГеозонычастичноВ интерфейсе мониторинга существует инструмент Маршрутизатор, который, среди прочего, позволяет оптимизировать путь между точками и сохранить результат в качестве геозон.
Logisticsда

При планировании маршрута приложение автоматически оптимизирует путь между точками с учетом множества критериев.

NimBusда

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

6. Автоматический запуск слежения за рейсом

Маршрутыда

Автоматическое создание рейсов доступно при использовании расписания с типом Относительно суток либо при использовании уведомлений с типом действия Создать рейс.

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

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

NimBusда

Если для маршрута созданы расписания и он включен, то рейс по нему создается автоматически. В приложении доступно два типа активации рейсов:

  • По расписаниюрейс создается за определенное количество минут до планируемого посещения первой остановки; количество минут указывается в настройках.
  • При посещении остановки — этот тип активации доступен только для маршрутов, у которых включена функция автоматического назначения объектов.

7. Дополнительные условия посещения точек

Маршрутынет

Дополнительные условия посещения отсутствуют. Посещением точки является любое сообщение с координатами в области контрольной точки.

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

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

NimBusнет

Дополнительные условия посещения отсутствуют. Посещением остановки является любое сообщение с координатами в области остановки.

8. Расписание относительно выезда

Маршрутыда

Расписание может иметь тип Относительно активации, таким образом одно расписание можно использовать несколько раз в день.

ГеозонынетВ данном варианте отсутствует понятие «расписание». Его заменяет Ограничение по времени в отчетах и уведомлениях, где указывается время только относительно начала суток.
Logisticsчастично

При создании маршрута время планируемого прибытия может варьироваться в зависимости от текущего времени. Например, если заявки можно посетить с 10:00 до 20:00, а сейчас 12:00, то время планируемого прибытия будет отсчитываться от 12:00. Это лишь отчасти можно назвать расписанием относительно выезда.

NimBusда

Для этого в приложении существует тип расписания Относительное.

9. Замена транспорта в процессе выполнения рейса

Маршрутынет

Заменить объект в процессе выполнения рейса невозможно. Например, при поломке первого объекта придется создавать новый рейс (или даже маршрут) для второго объекта, который выходит на замену.

ГеозонычастичноВ данном варианте отсутствует понятие «рейс». Однако формально диспетчер может связаться с водителем и направить его в непосещенные геозоны.
Logisticsда

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

NimBusда

На рейсе можно сменить объект, который его выполняет.

10. Длительный маршрут (более 2 суток)

Маршрутыда

Для Абсолютного расписания нет ограничений по длительности маршрута, однако каждое такое расписание можно использовать только 1 раз, после чего оно становится бесполезным. Для расписаний Относительно суток и Относительно активации можно достичь длительности в 99 часов (чуть более 4 суток).

ГеозоныдаВ данном варианте отсутствуют понятия «рейс» и «расписание». Поэтому ничто не мешает объекту двигаться между геозонами в течение нескольких дней, недель и так далее.
Logisticsда

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

NimBusнет

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

11. Подвижные контрольные точки

Маршрутыда

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

ГеозоныдаВ таблицах Геозоны и Поездки между геозонами можно использовать объекты в качестве «подвижных геозон».
Logisticsнет

Заявки в приложении имеют фиксированное местоположение.

NimBusнет

Остановки в приложении имеют фиксированное местоположение.

12. Отправка маршрутов водителю

Маршрутычастично

Существует возможность отправки маршрутов на объект с помощью команд. Необходимо, чтобы такую команду поддерживал трекер, а также к нему должен быть подключен навигатор. То есть данная возможность доступна не для всех объектов.

ГеозонычастичноСуществует возможность отправки геозон на объект с помощью команд, однако они не будут объединены в единый маршрут. При этом необходимо, чтобы данную возможность поддерживал трекер.
Logisticsда

Для курьеров создано мобильное приложение, в котором они видят их планируемые маршруты.

NimBusнет

Подобный функционал отсутствует.

13. Онлайн-контроль

Маршрутыда

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

ГеозоныдаСледить за выполнением маршрута можно на карте в интерфейсе мониторинга или с помощью уведомлений с типом Геозона.
Logisticsда

Активные в данный момент маршруты и статусы заявок можно увидеть в виде таблицы. Также диспетчеру будут полезны уведомления. Статистика в реальном времени отображается на вкладке Обзор.

NimBusда

Для наблюдения за выполнением рейсов онлайн подходит вкладка Слежение. Также диспетчеру будут полезны уведомления. Статистика в реальном времени отображается на вкладке Обзор.

14. Отчеты за предыдущий период

Маршрутыда

Для объекта и группы объектов можно использовать таблицы Рейсы и Контрольные точки, а для отчета по маршрутам — таблицы Рейсы и Журнал.

ГеозоныдаНаиболее удобными являются таблицы Геозоны и Поездки между геозонами, доступные для объекта и группы объектов.
Logisticsда

В приложении существует специальная вкладка Отчеты.

NimBusда

В приложении существует специальная вкладка Отчеты.

15. Отображение в интерфейсе мониторинга

Маршрутыда

Модуль является частью интерфейса мониторинга. 

ГеозоныдаГеозоны, отчеты и уведомления являются частью интерфейса мониторинга.
Logisticsчастично

По данным из Logistics можно построить таблицу Заявки, но она отображает только часть информации, которая доступна в приложении.

NimBusнет

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

16. Мобильное приложение

Маршрутынет

Маршруты не отображаются в мобильном приложении Wialon.

Геозоныда

Геозоны, уведомления и отчеты отображаются в мобильном приложении.
Клиенты могут отслеживать местоположение с помощью ссылки Локатора, которую можно добавить в текст уведомления через тег %LOCATOR_LINK%. Эту ссылку удобно открывать через браузер на телефоне.

Logisticsда

Для курьеров создано мобильное приложение. В нем курьер видит маршруты, которые он должен выполнить.
Клиент может отследить выполнение его заявки при получении уведомления с тегом %LOCATOR_LINK%. После отправки уведомления тег превращается в ссылку Локатора, которую удобно открывать через браузер на телефоне.

NimBusчастично

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


Олег Жарковский,Инженер Customer Service

Контроль нестандартных условий с помощью динамических групп
  • technical_consulting
  • notifications
  • unit_groups

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

Логика работы динамических групп

Логика работы данного метода основывается на следующих возможностях системы:

  • уведомления могут отслеживать не только конкретные объекты, а группы объектов;



  • уведомления позволяют изменять состав групп объектов.


Совместив эти возможности, можно добиться неочевидного поведения:

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

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

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

Сортировка по группам

Самым простым подходом при использовании динамических групп является сортировка объектов по группам. Таким образом можно, например, разделить все машины автопарка на движущиеся и простаивающие, свободные и занятые, находящиеся на территории предприятия и за его пределами и так далее. После сортировки полученные группы можно использовать в Отчетах или Заданиях, а также отображать на вкладке Мониторинг.

Для сортировки по одному условию A потребуются следующие элементы и настройки:

  1. Группа Альфа, содержащая объекты, для которых еще не выполнено условие A.
  2. Группа Бета, содержащая объекты, для которых уже выполнено условие A.
  3. Уведомление 1, которое настроено на отслеживание группы Альфа и контролирует условие A. Если это условие будет выполнено, то объекты будут исключены из группы Альфа и добавлены в группу Бета.
  4. Уведомление 2, которое настроено на отслеживание группы Бета и контролирует условие, противоположное условию A. Если это условие будет выполнено, то объекты будут исключены из группы Бета и снова добавлены в группу Альфа.

Схематично данный подход можно изобразить следующим образом:

Рассмотрим несколько примеров.

Пример 1. Отчет по объектам вне страны

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

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

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

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

There are no pictures in the gallery


❮ ❯

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

There are no pictures in the gallery


❮ ❯

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

Подобное разделение на группы является актуальным только на текущий момент времени. То есть если выполнить отчет по группе объектов за прошлую неделю, то отобразятся результаты по тем объектам, которые входят в группу сейчас, а не по тем, которые входили в нее в течение прошлой недели.

Пример 2. Распределение доступов через группы

Предположим, что запрос клиента аналогичен примеру 1, однако дополнительно необходимо сделать так, чтобы определенный диспетчер имел доступ только к тем объектам, которые в данный момент находятся вне страны. За основу будет взято решение из предыдущего примера, а ниже будут рассмотрены только недостающие настройки.

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

Сперва необходимо удостовериться, что диспетчер не имеет прав в отношении рассматриваемых объектов. Далее необходимо предоставить диспетчеру права только на определенную группу объектов (в данном примере — это группа Вне страны).

There are no pictures in the gallery


❮ ❯

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

Контроль нескольких условий в уведомлении

В Wialon существует 20 типов уведомлений, которые позволяют автоматически выполнять разные действия при выполнении выбранного условия. При этом действий может быть несколько (например, можно одновременно показать онлайн-уведомление во всплывающем окне и изменить иконку объекта), а контролируемое условие формально может быть только одно.

Однако, в 8 типах уведомлений кроме основного условия можно включить дополнительные.

Тип уведомленияДополнительные условия
Значение датчикаГеозонаСкоростьОтсутствие водителя
Скорость

Геозона

Взаиморасположение объектов

Адрес

Простой

Потеря связи


Заправка


Слив


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

Для контроля двух условий A и B потребуются следующие элементы и настройки:

  1. Группа Альфа, содержащая объекты, для которых еще не выполнено условие A.
  2. Группа Бета, содержащая объекты, для которых уже выполнено условие A.
  3. Уведомление 1, которое настроено на отслеживание группы Альфа и контролирует условие A. Если это условие будет выполнено, то объекты будут исключены из группы Альфа и добавлены в группу Бета.
  4. Уведомление 2, которое настроено на отслеживание группы Бета и контролирует условие, противоположное условию A. Если это условие будет выполнено, то объекты будут исключены из группы Бета и снова добавлены в группу Альфа.
  5. Ключевое уведомление 3, которое настроено на отслеживание группы Бета и контролирует условие B. Если это условие будет выполнено, то уведомление выполнит финальное действие (например, уведомит клиента по email).

Схематично данный подход можно изобразить следующим образом:

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

При необходимости контролировать больше условий количество групп и уведомлений можно увеличивать, например:

Отличительной особенностью данного подхода является последовательный контроль условий. Например, уведомление с типом Скорость с дополнительным фильтром Значение датчика контролирует выполнение обоих условий одновременно (для срабатывания уведомления потребуется одно сообщение). А система уведомлений с динамическими группами, настроенная на эти же условия, сперва контролирует скорость и только потом значение датчика (то есть для срабатывания потребуется два сообщения). При этом увеличение количества элементов в схеме будет также увеличивать количество сообщений, необходимых для срабатывания.

Пример 3. Контроль объектов вне особых зон

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

Для решения этой задачи сначала необходимо создать геозону, которая соответствует базе, а также две группы объектов, которые можно назвать На базе и На выезде. Далее необходимо создать два уведомления для сортировки объектов по созданным группам. Делается это по аналогии с решением из примера 1. Ниже будет показана настройка только последнего уведомления.

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

There are no pictures in the gallery


❮ ❯

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

Контроль условий с учетом времени

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

Пример 4. Срабатывание уведомления один раз в день

Предположим, что клиент хочет получать SMS о первом нажатии тревожной кнопки для всех машин из автопарка в течение рабочего дня.

Чтобы решить эту задачу для одного объекта, необходимо установить значение 1 в поле Максимальное количество срабатываний, а затем указать для этого параметра ограничение по времени с 00:00 по 23:59. Если объектов немного, то можно обойтись одним уведомлением для каждого из них. Однако если объектов много, то придется прибегнуть к динамическим группам, что и будет рассмотрено далее.

Схематично решение этой задачи можно изобразить следующим образом:

Соответственно, для решения потребуются:

  1. Группа под названием Тревоги не было (группа Альфа на схеме выше), которая содержит все объекты, водители которых еще не нажимали сегодня тревожную кнопку. В полночь в ней должны находиться все объекты автопарка, поэтому нужно их туда поместить изначально.
  2. Группа Тревога случилась (группа Бета), которая содержит объекты, водители которых нажимали сегодня тревожную кнопку. В полночь эта группа должна быть пустой.
  3. Уведомление Тревога! (уведомление 1), которое настроено на отслеживание группы Тревоги не было и контролирует нажатие тревожной кнопки. Если это условие будет выполнено, то объекты будут исключены из группы Тревоги не было и добавлены в группу Тревога случилась, а также уведомление отправит SMS клиенту.

    There are no pictures in the gallery


    ❮ ❯

  4. Уведомление К исходной настройке (уведомление 2) в данном случае будет возвращать все объекта из группы Тревога случилась в группу Тревоги не было ближе к полуночи. Для этого оно должно быть настроено на отслеживание группы Тревога случилась, иметь ограничение по времени (например, с 20:00 по 23:59) и контролировать какое-то условие, которое точно выполнится для всех объектов в конце рабочего дня. Одним из таких условий может быть наличие скорости менее 300 км/ч (при этом уведомление должно срабатывать Для всех сообщений).

    There are no pictures in the gallery


    ❮ ❯

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

Пример 5. Отчет по объектам, которые не начали движение к определенному времени

Предположим, что владелец автопарка хочет каждый день получать список машин, которые не начали движение до 8 утра.

Схематично решение этой задачи можно изобразить следующим образом:

Соответственно, для решения потребуются:

  1. Группа под названием Не начали работу до 8 (группа Альфа на схеме выше), в ней будут содержаться все объекты, которые еще не начали движение. Будем считать, что в полночь в ней должны находиться все объекты автопарка, поэтому нужно их туда поместить изначально.
  2. Группа Начали до 8 (группа Бета), которая содержит объекты, которые уже начали движение. В полночь эта группа должна быть пустой.
  3. Уведомление Успели начать до 8 (уведомление 1), которое настроено на отслеживание группы Не начали работу до 8 и контролирует появление скорости (то есть начало работы). Если это условие будет выполнено, то объекты будут исключены из группы Не начали работу до 8 и добавлены в группу Начали до 8. Также работу данного уведомления нужно ограничить по времени с 00:00 до 07:59.

    There are no pictures in the gallery


    ❮ ❯

  4. Задание Список опоздавших, которое в 08:00 будет отправлять отчет владельцу автопарка об объектах из группы Не начали работу до 8. Групповой отчет может содержать, например, таблицу Последние данные.

    There are no pictures in the gallery


    ❮ ❯

  5. Уведомление К исходной настройке (уведомление 2) в данном случае будет возвращать все объекта из группы Начали до 8 в группу Не начали работу до 8 ближе к полуночи. Делается это по аналогии с одноименным уведомлением из примера 4 выше.

Теперь объекты, которые не начали движение до 08:00, останутся в группе Не начали работу до 8, а затем задание отправит о них отчет владельцу автопарка. Если же какой-то объект начнет движение до 8 утра, то он будет перемещен в группу Начали до 8, поэтому не попадет в отчет о нарушителях. Вечером все объекты будут возвращены в исходную группу.

Пример 6. Контроль длительных состояний (более суток)

Предположим, что менеджеру нужно получить электронное письмо, если объект находится на территории завода более 3 суток (72 часов).

Обычно длительность контролируемого тревожного состояния (в данном случае — это нахождение в геозоне) настраивается через поле Мин. продолжительность тревожного состояния на последней странице настройки уведомления. Максимальное значение для этого поля составляет 24 часа (1440 минут, 86400 секунд). То есть отследить тревожное состояние длительностью 72 часа нельзя без использования динамических групп.

Исключением являются два уведомления: Простой имеет максимальную длительность 30 дней, а Потеря связи — 999 999 минут (это приблизительно 694 дня).

Схематично решение этой задачи можно изобразить следующим образом:

Соответственно, для решения потребуются:

  1. Геозона, которая соответствует территории завода.
  2. Группа под названием Вне или внутри <24 часов (группа Альфа на схеме выше), которая изначально содержит все объекты.
  3. Группа Внутри >24 часов (группа Бета), в которой будут содержаться объекты, которые находятся внутри геозоны 24 часа или более.
  4. Группа Внутри >48 часов (группа Гамма), в которой будут содержаться объекты, которые находятся внутри геозоны 48 часов или более.
  5. Уведомление Въезд на 1 день (уведомление 1), которое настроено на отслеживание группы Вне или внутри <24 часов и контролирует нахождение в геозоне более 24 часов. Если это условие будет выполнено, то объекты будут исключены из группы Вне или внутри <24 часов и добавлены в группу Внутри >24 часов. Уведомление должно срабатывать При изменении состояния, а Мин. продолжительность тревожного состояния должна быть равна 24 часам (1440 минутам, 86400 секундам).

    There are no pictures in the gallery


    ❮ ❯


  6. Уведомление Въезд на 2 дня (уведомление 2), которое настроено на отслеживание группы Внутри >24 часов и контролирует нахождение в геозоне более 48 часов. Если это условие будет выполнено, то объекты будут исключены из группы Внутри >24 часов и добавлены в группу Внутри >48 часов. Уведомление должно срабатывать Для всех сообщений, а Мин. продолжительность тревожного состояния должна быть равна 24 часам (1440 минутам, 86400 секундам).

    There are no pictures in the gallery


    ❮ ❯

  7. Уведомление К исходной настройке (уведомление 3) будет возвращать все объекта из групп Внутри >24 часов и Внутри >48 часов в группу Вне или внутри <24 часов, если объект покинул геозону. Уведомление должно срабатывать При изменении состояния.

    There are no pictures in the gallery


    ❮ ❯

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

  8. Уведомление Въезд на 3 дня (уведомление 4), которое настроено на отслеживание группы Внутри >48 часов и контролирует нахождение в геозоне более 72 часов. Если это условие будет выполнено, то объекты будут исключены из группы Внутри >48 часов и добавлены в группу Вне или внутри <24 часов, а также менеджеру отправится электронное письмо. Уведомление должно срабатывать Для всех сообщений, а Мин. продолжительность тревожного состояния должна быть равна 24 часам (1440 минутам, 86400 секундам).

    There are no pictures in the gallery


    ❮ ❯


Теперь объекты, которые находились в геозоне в течение одних суток, переместятся из группы Вне или внутри <24 часов в группу Внутри >24 часов, спустя одни сутки они переместятся в группу Внутри >48 часов, а спустя еще одни сутки уведомление отправит электронное письмо менеджеру и переместит объект в исходную группу. Если же в любой момент объекты покинут геозону, то они вернутся в исходную группу Вне или внутри <24 часов.

Олег Жарковский,Инженер Customer Service

Введение в SDK: базовые запросы
  • technical_consulting

SDK (Software Development Kit) — это набор инструментов для разработки собственных приложений. Wialon SDK включает в себя несколько API. Самым базовым из них является Remote API, на изучение которого нацелены данные статьи. Remote API предполагает доступ к данным через HTTP-запросы и актуален для 1С, PHP, C++/C# и других языков программирования. JS API и остальные построены на базе Remote API.

В данной статье будут рассмотрены базовые знания, необходимые новичкам для использования Remote API.

Также вам могут быть полезны:

  • Портал для разработчиков с документаций и подробным описанием каждого запроса.
  • Примеры готовых решений с использованием SDK из раздела Маркетплейс.
  • Серия вебинаров Wialon API и SDK: обучающие видео.
  • Коллекция примеров в приложении Postman для тестирования API-запросов.
  • Раздел форума Собственные разработки под Wialon.

Просмотр запросов в браузере

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

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

При просмотре сетевых запросов можно увидеть отправляемый запрос, его параметры и ответ от API-сервера в формате JSON.

 Пример

В качестве примера создадим круговую геозону. Откроем вкладку Сеть, а потом заполним поля Имя, Описание, Тип, Радиус и Координаты.

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

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

  • Заголовки — позволяет увидеть полный URL запроса, используемый метод отправки (POST или GET), статус выполнения запроса и другую полезную информацию.
    Среди прочего здесь можно найти 
    название API-запроса. В данном случае это resource/update_zone.



  • Полезная нагрузка — отображает параметры запроса, про каждый из которых можно прочитать в документации.
    Например, параметры, которые предлагалось указать при создании геозоны: n — имя, d — описание, t — тип (круг), w — радиус круга, x и y — координаты центра.



  • Ответ — отображает ответ от API-сервера в формате JSON (в случае ошибки — ее код).


Некоторые запросы выполняются пакетно. Тогда при просмотре сетевых запросов нужно найти запрос core/batch и изучить его параметры.

Не весь функционал интерфейса мониторинга основан на Wialon API (примером исключения является инструмент Расстояние).

Формат запроса

Запросы HTTP отправляются на сервер в следующем формате:

https://host/wialon/ajax.html?svc=НАИМЕНОВАНИЕ_ЗАПРОСА¶ms={ПАРАМЕТРЫ}&sid=ИДЕНТИФИКАТОР_СЕССИИ
ПараметрОписание
host

Для Wialon Hosting это обычно hst-api.wialon.com, а для Wialon Local — сайт системы мониторинга или CMS.

svc

Наименование запроса (например, resource/update_zone).

params

Параметры для выполнения запроса в формате JSON. Они перечислены в документации, при этом некоторые из них могут быть опциональными. В некоторых случаях отправляется пустое значение params={}.

sidУникальный идентификатор сессии, который используется практически во всех запросах. Сервер возвращает его при запросе на авторизацию.

Отправлять запросы для тестирования функционала API можно через адресную строку браузера. При этом необходимо, чтобы символы были закодированы для передачи в URL. Например, код символа % имеет вид %25, что можно проверить с помощью общедоступных онлайн-инструментов. Если специальные символы не будут закодированы, то в качестве ответа сервер вернет ошибку с кодом 4.

Получение токена и авторизация

Для авторизации в Wialon используется токен, то есть ключ, применяемый для зашифрованной идентификации пользователя.

Для создания токена можно использовать форму oAuth. После успешного логина токен отобразится в адресной строке браузера в качестве значения параметра access_token. При этом важно учитывать дополнительные параметры, которые регулируют такие свойства, как срок жизни (параметр duration), имя пользователя (параметр user), права доступа (параметр access_type) и другие.

Пример расширенной формы для получения токена:

https://hosting.wialon.com/login.html?client_id=ИМЯ_ПРИЛОЖЕНИЯ&access_type=256&activation_time=0&duration=0&lang=ru&flags=0&user=ИМЯ_ПОЛЬЗОВАТЕЛЯ

Пример ответа:

https://hosting.wialon.com/login.html?lang=ru&user=ИМЯ_ПОЛЬЗОВАТЕЛЯ&wialon_sdk_url=https%3A%2F%2Fhst%2Dapi%2Ewialon%2Ecom&access_token=ЗНАЧЕНИЕ_ТОКЕНА&svc_error=0

После получения токена его нужно использовать для авторизации. Пример логина под токеном:

https://hst-api.wialon.com/wialon/ajax.html?&svc=token/login¶ms={"token":"ЗНАЧЕНИЕ_ТОКЕНА"}

В ответе на логин под токеном содержится параметре eid, значение которого является уникальным идентификатором сессии. Далее он будет использоваться практически во всех API-запросах.

Настройка часового пояса

По умолчанию при работе c Remote API данные отображаются согласно часовому поясу GMT+0. Чтобы изменить его на необходимый, используется запрос render/set_locale. Достаточно выполнить данный запрос в рамках одной активной сессии.

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

При отправке запроса render/set_locale необходимо использовать параметр tzOffset. Стандартный метод вычисления его значения описан в документации.

 Пример

В качестве примера рассчитаем значение параметра tzOffset для клиента из Австралии (Сидней).

Посмотреть нужные значения временных настроек (летнее время и часовой пояс) можно в документации. В данном случае значение часового пояса равно 36000 (в формате DEC), а летнего времени — 0x0A270000 (в формате HEX).

Далее необходимо выполнить два действия:

  1. К часовому поясу применим операцию побитового И по маске f000ffff (HEX).
    Так как используемая операция выполняется для каждой пары битов, то сперва необходимо перевести значения в двоичную систему счисления:

    Часовой пояс

    00000000000000001000110010100000 (BIN)

    36000 (DEC)
    Маска

    11110000000000001111111111111111 (BIN)

    f000ffff (HEX)
    Результат операции

    00000000000000001000110010100000 (BIN)

    36000 (DEC)

    В данном случае операция не изменила значение часового пояса.

  2. К результату из предыдущего пункта применим операцию побитового ИЛИ по маске летнего времени.

    Предыдущей результат

    00000000000000001000110010100000 (BIN)

    36000 (DEC)
    Маска

    00001010001001110000000000000000 (BIN)

    0x0A270000 (HEX)
    Результат операции

    00001010001001111000110010100000 (BIN)

    170364064 (DEC)

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

Системный ID

В API работа почти со всеми элементами ведется через внутренние идентификаторы, называемые системными ID, которые представлены уникальными цифровыми значениями.

Не нужно путать системный ID объекта с его Уникальным ID, который указывается в свойствах на вкладке Основное.

В веб-интерфейсах системные ID по умолчанию не отображаются, но их можно увидеть тремя методами:

  1. В ответе на запрос поиска элементов по критериям (core/search_items). Он будет рассмотрен подробнее в следующем разделе данной статьи.
  2. В параметрах запросов при просмотре сетевых запросов в браузере.
  3. В столбце avl_id в системе управления.

    Чтобы столбец avl_id отображался, необходимо авторизоваться в CMS, добавив в конец ссылки ?features=avl_id. Пример такой ссылки приведен на изображении ниже.

Поиск элементов по критериям

Данный запрос позволяет найти элементы по указанным в параметрах критериям.

Поиск осуществляется по следующим типам элементов, которые указываются в поле itemsType:

  • avl_hw — тип устройства;
  • avl_resource — ресурс;
  • avl_retranslator — ретранслятор;
  • avl_unit — объект;
  • avl_unit_group — группа объектов;
  • user — пользователь;
  • avl_route — маршрут.

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

  • объекты:
    • unit_sensors — датчики;
    • unit_commands — команды;
    • service_intervals — интервалы техобслуживания;

  • ресурсы:
    • drivers — водители;
    • driver_groups — группы водителей;
    • jobs — задания;
    • notifications — уведомления;
    • trailers — прицепы;
    • trailer_groups — группы прицепов;
    • zones_library — геозоны;
    • reporttemplates — шаблоны отчетов;
    • orders — заявки;

  • маршруты:
    • rounds — рейсы;
    • route_schedules — расписания;

  • ретрансляторы:
    • retranslator_units — ретранслируемые объекты;

  • объекты, пользователи или ресурсы:
    • custom_fields — произвольные поля;
    • admin_fields — административные поля.

Системные ID элементов имеют уникальные числовые значения и присваиваются сервером.

Нумерация системных ID подэлементов ведется в порядке создания и начинается с 1.

Если ранее было создано несколько подэлементов (например, с системными ID 1, 2 и 3), а потом какой-то из них был удален (предположим, нетронутыми остались подэлементы с ID 1 и 3), то следующий созданный подэлемент займет наименьший свободный ID (в данном примере это ID 2).

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

Например, можно вести поиск по имени датчика Engine, но в ответе на запрос вернется не только информация о датчиках, а именно об объектах, в которых создан датчик с искомым именем.

Информация в ответе зависит от того, какие флаги указаны в запросе поиска в параметре flags. Флаги задаются в формате DEC.

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

Например, если необходимо вывести основные свойства объекта ("flag":1), созданные в нем команды ("flag":524288) и последнее местоположение ("flag":4194304), то достаточно выполнить поиск по объектам с флагом "flag":4718593, так как 1 + 524288 + 4194304 = 4718593.

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

Поиск элементов с определенным именем

Необходимо получить список всех доступных пользователю объектов, в имени которых есть слово Tractor, а также информацию о датчиках, созданных в объектах.

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

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_unit","propName":"sys_name","propValueMask":"*Tractor*","sortType":"sys_name"},"force":1,"flags":4097,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemsType":"avl_unit"

Поиск будет выполнен по объектам.

Если оставить значение пустым ("itemsType":""), то поиск будет осуществляться по всем типам элементов.

"propName":"sys_name"

Поиск будет выполнен по имени элемента.

"propValueMask":"*Tractor*"

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

Если задать для данного параметра значение *, то в ответе на запрос будут присутствовать элементы с любым значением именем, то есть все доступные пользователю элементы.

"sortType":"sys_name"Сортировка будет выполнена по имени элемента.
"force":1Результаты предыдущих поисков не будут учитываться.
"flags":4097

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

1 + 4096 = 4097

"from":0;"to":0Ограничения по количеству найденных элементов не будут применяться.
 Ответ
{
	"searchSpec":{
		"itemsType":"avl_unit",
		"propName":"sys_name",
		"propValueMask":"*Tractor*",
		"sortType":"sys_name",
		"propType":"",
		"or_logic":"0"
	},
	"dataFlags":4097,
	"totalItemsCount":1,
	"indexFrom":0,
	"indexTo":0,
	"items":[
		{
			"nm":"Tractor 1",
			"cls":2,
			"id":22353120,
			"mu":0,
			"sens":{
				"1":{
					"id":1,
					"n":"Ignition",
					"t":"engine operation",
					"d":"",
					"m":"On\/Off",
					"p":"in1",
					"f":0,
					"c":"{\"act\":1,\"appear_in_popup\":true,\"ci\":{},\"cm\":1,\"mu\":0,\"pos\":2,\"show_time\":false,\"timeout\":0}",
					"vt":0,
					"vs":0,
					"tbl":[]
				},
				"2":{
					"id":2,
					"n":"Fuel level",
					"t":"fuel level",
					"d":"",
					"m":"l",
					"p":"adc1",
					"f":0,
					"c":"{\"act\":1,\"appear_in_popup\":true,\"calc_fuel\":0,\"ci\":{},\"cm\":1,\"fuel_params\":{\"fillingsJoinInterval\":300,\"filterQuality\":0,\"flags\":0,\"ignoreStayTimeout\":10,\"minFillingVolume\":20,\"minTheftTimeout\":0,\"minTheftVolume\":10,\"theftsJoinInterval\":300},\"mu\":0,\"pos\":1,\"show_time\":false,\"timeout\":0}",
					"vt":0,
					"vs":0,
					"tbl":[]
				}
			},
			"sens_max":-1,
			"uacl":-1
		}
	]
}

Поиск пользователей, созданных после определенной даты

Необходимо получить список пользователей, которые были созданы после 23 февраля 2021 05:41:46 (GMT+0). В ответе должны содержаться системные ID данных пользователей и их адреса электронной почты.

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

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"user","propName":"rel_creation_time","propValueMask":">=1614058906","sortType":"sys_name"},"force":1,"flags":3,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemsType":"user"

Поиск будет выполнен по пользователям.

"propName":"rel_creation_time"

Поиск будет выполнен по дате создания.

"propValueMask":">=1614058906"

В ответе будет отображен список элементов, время создания которых больше или равно 23 февраля 2021 05:41:46 (GMT+0).

В запросах используется Unix-время. Для перевода даты и времени в Unix-время можно использовать общедоступные онлайн-инструменты.

"sortType":"sys_name"Сортировка будет выполнена по имени элемента.
"force":1Результаты предыдущих поисков не будут учитываться.
"flags":3

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

1 + 2 = 3

"from":0;"to":0Ограничения по количеству найденных элементов не будут применяться.

Поиск объектов определенного типа

Необходимо вывести список объектов с типом оборудования Wialon Retranslator, которые отправляли сообщения после 12 февраля 2023 12:00:00 (GMT+0). В ответе необходимо отобразить датчики объектов, время последнего сообщения и местоположения.

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

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_unit","propName":"rel_hw_type_name,rel_last_msg_date","propValueMask":"Wialon%20Retranslator,>1676203200","sortType":"rel_creation_time"},"force":1,"flags":1,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemsType":"avl_unit"

Поиск будет выполнен по объектам.

"propName":"rel_hw_type_name,rel_last_msg_date"

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

"propValueMask":"Wialon%20Retranslator,>1676203200"

В ответе будет отображен список элементов с типом оборудования Wialon Retranslator, время отправки последнего сообщения от которых позже, чем 12 февраля 2023 12:00:00 (GMT+0).

"sortType":"rel_creation_time"Сортировка будет выполнена по дате создания элементов.
"force":1Результаты предыдущих поисков не будут учитываться.
"flags":1

В ответе вернется информация об основных свойствах объекта.

"from":0;"to":0Ограничения по количеству найденных элементов не будут применяться.

Поиск объектов по имени датчика

Необходимо вывести список объектов, в которых создан датчик с именем Engine.

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

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_unit","propType":"propitemname","propName":"unit_sensors","propValueMask":"Engine","sortType":"sys_name"},"force":1,"flags":1,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemsType":"avl_unit"

Поиск будет выполнен по объектам.

"propType":"propitemname"

Поиск будет выполнен по имени подэлемента.

"propName":"unit_sensors"

Поиск будет выполнен по имени датчика.

"propValueMask":"engine"

В ответе будет отображен список объектов, в свойствах которых создан датчик с названием Engine.

"sortType":"sys_name"Сортировка будет выполнена по имени элемента.
"force":1Результаты предыдущих поисков не будут учитываться.
"flags":1

В ответе вернется информация об основных свойствах объектов.

"from":0;"to":0Ограничения по количеству найденных элементов не будут применяться.

Поиск групп объектов по нескольким критериям

Необходимо получить список групп объектов, которые были созданы пользователем User, и в которые добавлено более 5 объектов.

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

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_unit_group","propName":"rel_user_creator_name,rel_group_unit_count","propValueMask":"User,>5","sortType":"sys_name"},"force":1,"flags":133,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemsType":"avl_unit_group"

Поиск будет выполнен по группам объектов.

"propName":"rel_user_creator_name,rel_group_unit_count"

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

"propValueMask":"User,>5"

В ответе будет отображен список групп объектов, создателем которых является пользователь User, и в которые добавлено более 5 объектов.

"sortType":"sys_name"Сортировка будет выполнена по имени элемента.
"force":1Результаты предыдущих поисков не будут учитываться.
"flags":133

В ответе вернется информация об основных свойствах, свойствах биллинга и административных записях.

1 + 4 + 128 = 133

"from":0;"to":0Ограничения по количеству найденных элементов не будут применяться.

Список частых ошибок

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

Наиболее частыми ошибками являются:

  • {error: 1} — недействительная сессия.
    Данная ошибка отображается, когда истек срок действия уникального идентификатора сессии. Чтобы исправить ошибку, достаточно выполнить логин под токеном еще раз и использовать новый идентификатор сессии (sid) для выполнения запросов.

    Если в течение 5 минут в рамках сессии не выполняется ни одного запроса, то она становится неактивной. Чтобы поддерживать сессию, вы можете каждые 5 минут отправлять запрос avl_evts.

  • {error: 4} — неверный ввод.
    Данная ошибка отображается, если в тексте запроса присутствует ошибка: указаны не все требуемые параметры, текстовые параметры не заключены в кавычки, нет открывающей или закрывающей скобки и т. д. Чтобы исправить ошибку, необходимо исправить текст выполняемого запроса согласно его описанию в документации.

  • {error: 7} — доступ запрещен.
    Данная ошибка отображается, если у пользователя недостаточно прав на выполнение запроса. Чтобы исправить ошибку, необходимо проверить, достаточно ли прав у токена, который используется для получения уникального идентификатора сессии, а также достаточно ли у пользователя, для которого был сгенерирован токен, прав в отношении используемых элементов.


Екатерина Гриб,Инженер Customer Service

Введение в SDK: создание учетных записей и объектов
  • technical_consulting

В данной статье будет рассмотрено создание учетных записей и объектов при помощи Remote API. Эти элементы являются ключевыми при работе с Wialon, а их создание требует выполнения цепочки обязательных действий.

Также вам могут быть полезны:

  • Статья Введение в SDK: базовые запросы.
  • Портал для разработчиков с документаций и подробным описанием каждого запроса.
  • Примеры готовых решений с использованием SDK из раздела Маркетплейс.
  • Серия вебинаров Wialon API и SDK: обучающие видео.
  • Коллекция примеров в приложении Postman для тестирования API-запросов.
  • Раздел форума Собственные разработки под Wialon.

Создание учетной записи

Перед выполнением данного действия необходимо вспомнить два важных термина:

  • Создатель — это пользователь, от имени которого создан определенный элемент системы.
  • Учетная запись — это макроэлемент системы, который представляет собой единство ресурса, пользователя и тарифного плана.

Исходя из этого, чтобы создать учетную запись, необходимо:

  1. Найти подходящий тарифный план.
  2. Найти системный ID пользователя-создателя, под которым будет находиться будущий создатель учетной записи.
  3. От имени найденного пользователя создать нового пользователя.
  4. От имени нового пользователя создать ресурс.
  5. Объединить нового пользователя, ресурс и тарифный план в учетную запись.

Рассмотрим запросы, которые понадобятся на каждом из этих шагов, на следующем примере: необходимо создать учетную запись с именем sdk_account, которая по иерархии сервиса будет находиться под учетной записью пользователя manager.

1. Поиск тарифного плана

Используем запрос core/get_account_data.

https://hst-api.wialon.com/wialon/ajax.html?svc=core/get_account_data¶ms={"type":1}&sid=ИДЕНТИФИКАТОР_СЕССИИ

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

Имена назначенных тарифных планов будут отображаться в ответе на запрос в параметре subPlans. Предположим, что мы будем использовать тарифный план с именем standard_client.

Если в ответе не отображаются тарифные планы, то необходимо проверить, обладает ли учетная запись правами дилера и назначены ли на нее тарифные планы.

2. Поиск системного ID пользователя-создателя

Используем запрос core/search_items.

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"user","propName":"sys_name","propValueMask":"manager","sortType":"sys_name"},"force":1,"flags":1,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemsType":"user"

Поиск будет выполнен по пользователям.

"propName":"sys_name"

Поиск будет выполнен по имени элемента.

"propValueMask":"manager"

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

"sortType":"sys_name"Сортировка будет выполнена по имени элемента.
"force":1Результаты предыдущих поисков не будут учитываться.
"flags":1

В ответе будет содержаться только информация об основных свойствах.

"from":0;"to":0Ограничения по количеству найденных элементов не будут применяться.

Системный ID пользователя будет отображаться в ответе на запрос в параметре id. Предположим, он будет иметь значение 11111.

3. Создание нового пользователя

Используем запрос core/create_user.

https://hst-api.wialon.com/wialon/ajax.html?svc=core/create_user¶ms={"creatorId":11111,"name":"sdk_account","password":"Pa%24%24w0rd","dataFlags":1}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"creatorId":11111

Создателем нового пользователя будет пользователь с системным ID 11111.

"name":"sdk_account"

Новый пользователь будет иметь имя sdk_account.

"password":"Pa%24%24w0rd"

Новый пользователь будет иметь пароль Pa$$w0rd.

Так как по требованиям безопасности пароль должен содержать спецсимволы, то они должны быть закодированы для передачи в URL.

"dataFlags":1В качестве ответа будут отображены только основные свойства нового пользователя.

Системный ID пользователя будет отображаться в ответе на запрос в параметре id. Предположим, он будет иметь значение 22222.

4. Создание ресурса

Используем запрос core/create_resource.

https://hst-api.wialon.com/wialon/ajax.html?svc=core/create_resource¶ms={"creatorId":22222,"name":"sdk_account","dataFlags":1,"skipCreatorCheck":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"creatorId":22222

Создателем нового ресурса будет пользователь с системным ID 22222.

"name":"sdk_account"

Новый ресурс будет иметь имя sdk_account.

"dataFlags":1В качестве ответа будут отображены только основные свойства нового ресурса.
"skipCreatorCheck":0Проверить, является ли пользовать создателем каких-либо элементов системы на данный момент.

Системный ID ресурса будет отображаться в ответе на запрос в параметре id. Предположим, он будет иметь значение 33333.

5. Объединение в учетную запись

Используем запрос account/create_account.

https://hst-api.wialon.com/wialon/ajax.html?svc=account/create_account¶ms={"itemId":33333,"plan":"standard_client"}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemId":33333

Новая учетная запись будет содержать в себе ресурс с системным ID 33333.

"plan":"standard_client"

Новая учетная запись будет использовать тарифный план standard_client.

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


Создание объекта

Чтобы создать объект с помощью Remote API, необходимо:

  1. Найти системный ID типа оборудования.
  2. Найти системный ID пользователя-создателя, в учетной записи которого будет находиться будущий объект.
  3. Создать объект.
  4. Присвоить объекту уникальный ID.

Рассмотрим необходимые запросы на следующем примере: необходимо создать объект Delivery truck с типом оборудования Wialon IPS и уникальным ID 12345 в учетной записи пользователя sdk_account.

1. Поиск системного ID типа оборудования

Используем запрос core/get_hw_types.

https://hst-api.wialon.com/wialon/ajax.html?svc=core/get_hw_types¶ms={"filterType":"name","filterValue":["Wialon%20IPS"],"includeType":0,"ignoreRename":1}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"filterType":"name"

Фильтрация будет осуществляться по имени типа оборудования.

"filterValue":["Wialon%20IPS"]

Поиск будет выполнен по выражению Wialon IPS.

"includeType":0

В ответе не будет показана дополнительная информация о типе оборудования.

"ignoreRename":1В ответе будут проигнорированы переименования типов оборудования.

Системный ID типа оборудования будет отображаться в ответе на запрос в параметре id. Предположим, он будет иметь значение 44444.


Системный ID одного типа оборудования может отличаться для разных сервисов Wialon Hosting и Wialon Local.


2. Поиск системного ID пользователя-создателя

Используем запрос core/search_items.

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"user","propName":"sys_name","propValueMask":"sdk_account","sortType":"sys_name"},"force":1,"flags":1,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemsType":"user"

Поиск будет выполнен по пользователям.

"propName":"sys_name"

Поиск будет выполнен по имени элемента.

"propValueMask":"sdk_account"

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

"sortType":"sys_name"Сортировка будет выполнена по имени элемента.
"force":1Результаты предыдущих поисков не будут учитываться.
"flags":1

В ответе будет содержаться только информация об основных свойствах.

"from":0;"to":0Ограничения по количеству найденных элементов не будут применяться.

Системный ID пользователя будет отображаться в ответе на запрос в параметре id. Предположим, он будет иметь значение 22222.

3. Создание объекта

Используем запрос core/create_unit.

https://hst-api.wialon.com/wialon/ajax.html?svc=core/create_unit¶ms={"creatorId":22222,"name":"Delivery%20truck","hwTypeId":"44444","dataFlags":1}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"creatorId":22222

Создателем нового объекта будет пользователь с системным ID 22222.

"name":"Delivery%20truck"

Имя нового объекта будет Delivery truck.

"hwTypeId":"44444"

Системный ID типа оборудования для нового объекта будет иметь значение 44444.

"dataFlags":1В качестве ответа будут отображены только основные свойства нового объекта.

Системный ID объекта будет отображаться в ответе на запрос в параметре id. Предположим, он будет иметь значение 55555.

4. Указание уникального ID

Используем запрос unit/update_device_type.

https://hst-api.wialon.com/wialon/ajax.html?svc=unit/update_device_type¶ms={"itemId":55555,"deviceTypeId":"44444","uniqueId":"12345"}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemId":55555

Изменение настроек будет осуществляться для объекта с системным ID 55555.

"deviceTypeId":"44444"

Системный ID типа оборудования будет иметь значение 44444.

С помощью данного параметра можно изменить тип оборудования объекта.

"uniqueId":"12345"

Уникальный ID объекта будет иметь значение 12345.

Выше рассмотрены только минимальные необходимые шаги для появления объекта в системе. Для выполнения прочих настроек нужно использовать отдельные запросы из списка в документации.


Екатерина Гриб,Инженер Customer Service

Введение в SDK: выполнение отчетов
  • technical_consulting

В данной статье будет рассмотрена работа с шаблонами отчетов при помощи Remote API. Выполнение отчетов через SDK подразумевает последовательность обязательных действий, которые не заметны при работе в веб-интерфейсе. Для полноты картины будут приведены примеры работы с отчетами с группировкой и без группировки.

Также вам могут быть полезны:

  • Статья Введение в SDK: базовые запросы.
  • Портал для разработчиков с документаций и подробным описанием каждого запроса.
  • Примеры работы с отчетами из документации.
  • Примеры готовых решений с использованием SDK из раздела Маркетплейс.
  • Серия вебинаров Wialon API и SDK: обучающие видео.
  • Коллекция примеров в приложении Postman для тестирования API-запросов.
  • Раздел форума Собственные разработки под Wialon.

Создание отчетов

В большинстве случаев пользователи создают шаблоны отчетов в веб-интерфейсе и потом выполняют их с помощью API-запросов. Далее мы будем рассматривать именно такие случаи.

Однако создание шаблонов отчетов доступно и через SDK, для чего нужно использовать запрос report/update_report.

Последовательность действий

Для получения результатов отчетов с помощью Remote API необходимо отправить несколько запросов подряд. Использование некоторых из них зависит от наличия группировки в отчете и количества анализируемых данных. Приведем самый общий список действий:

  1. Авторизация через запрос token/login и настройка локализации через запрос render/set_locale.

  2. Получение необходимых системных ID для:
    • элемента, для которого необходимо выполнить отчет;

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

    • ресурса, в котором содержится шаблон отчета;
    • самого шаблона отчета.

  3. Выполнение отчета через запрос report/exec_report.

    В общем случае мы рекомендуем выполнять отчет в фоновом режиме на сервере. Несмотря на увеличение количества шагов, это бывает полезно, если отчет может выполняться долго из-за большого количества объектов, интервала выполнения отчета, количества таблиц и графиков и т. д. Далее в статье будет рассмотрено именно выполнение отчета в фоновом режиме.

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

  4. Проверка статуса выполнения отчета через запрос report/get_report_status.
    После подтверждения готовности отчета можно будет продолжать движение по инструкции.

  5. Получение результата отчета через запрос report/apply_report_result.
    Результат данного запроса предоставит количество строк, столбцов и уровней вложенности при наличии группировки.

  6. Получение строк таблицы через запрос report/get_result_rows для отчета без группировки или через запрос report/select_result_rows для отчета с группировкой.
    Выбор таблицы, уровней вложенности и отображаемых строк осуществляется на основе данных из ответа на предыдущий запрос.

  7. Экспорт в файл через запрос report/export_result.
    Данный шаг является необязательным, но достаточно несложным и полезным, поэтому мы рассмотрим и его.

  8. Удаление результата предыдущего отчета через запрос report/cleanup_result.
    Данный шаг является обязательным, если в одной сессии необходимо выполнить несколько отчетов.

Следующие запросы не могут выполняться одновременно:

  • report/exec_report
  • report/export_result
  • report/get_result_chart
  • report/get_result_map
  • report/get_result_chart
  • resource/get_driver_bindings
  • resource/get_trailer_bindings
  • resource/get_tag_bindings
  • exchange/import_zones_save
  • exchange/import_json
  • exchange/import_messages
  • exchange/import_pois_read
  • exchange/import_zones_read
  • unit/get_trips
  • render/create_messages_layer
  • messages/load_interval
  • exchange/export_zones
  • exchange/export_json
  • exchange/export_messages
  • exchange/export_pois
  • account/get_account_history


Далее рассмотрим два примера работы с отчетами (без группировки и с группировкой).

Работа с отчетом без группировки

Необходимо получить результаты выполнения отчета Список поездок, доступного авторизованному по токену пользователю, для объекта Грузовик 0769 (системный ID 55555) за интервал времени с 2023 Июнь 30 20:00 до 2023 Июль 01 03:59 (GMT+0) в виде ответа на API-запрос и PDF-файла.

В веб-интерфейсе результат выглядит следующим образом:

1. Авторизация и настройка локализации

Используем запрос token/login.

https://hst-api.wialon.com/wialon/ajax.html?svc=token/login¶ms={"token":"ЗНАЧЕНИЕ_ТОКЕНА"}

Более подробно авторизация описана в одной из предыдущих статей.

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

Если настройка часового пояса выполнена в рамках сессии, то далее при выполнении отчета время задается в GMT+0.

Используем запрос render/set_locale.

https://hst-api.wialon.com/wialon/ajax.html?svc=render/set_locale¶ms={"tzOffset":134217728,"language":"ru","formatDate":"%25E.%25m.%25Y%20%25H:%25M:%25S"}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"tzOffset":134217728

Будет применен часовой пояс GMT+0 (без перехода на летнее время).

"language":"ru"

Будет использоваться русский язык.

"formatDate":"%25Y.%25m.%25E%20%25H:%25M:%25S"Будет использоваться формат даты yyyy-MM-dd и формат времени HH:mm:ss.

Невыполнение настройки локализации может приводить к различию результатов при выполнении отчета через Remote API и веб-интерфейс.

2. Получение системных ID

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

Получим список всех ресурсов, в которых создан шаблон отчета с именем Список поездок, доступных пользователю, для которого выполнена авторизация по токену. Используем запрос core/search_items:

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_resource","propType":"propitemname","propName":"reporttemplates","propValueMask":"Список%20поездок","sortType":"sys_name"},"force":1,"flags":8193,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemsType":"avl_resource"

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

"propType":"propitemname"Поиск будет выполнен по имени подэлемента.
"propName":"reporttemplates"

Поиск будет выполнен по имени шаблона отчета.

"propValueMask":"Список%20поездок"

В ответе будет отображен список ресурсов, в котором создан шаблон отчета с названием Список поездок.

"sortType":"sys_name"Сортировка будет выполнена по имени элемента.
"force":1Результаты предыдущих поисков не будут учитываться.
"flags":8193

В ответе будет содержаться информация об основных свойствах и о созданных шаблонах отчетов.

1 + 8192 = 8193

"from":0;"to":0Ограничения по количеству найденных элементов не будут применяться.
 Ответ
{
	"searchSpec":{
		"itemsType":"avl_resource",
		"propName":"reporttemplates",
		"propValueMask":"Список поездок",
		"sortType":"sys_name",
		propType:"propitemname",
		or_logic:"0"
		},
	"dataFlags":8193,
	"totalItemsCount":1,
	"indexFrom":0,
	"indexTo":0,
	"items":[
		{
			"nm":"sdk_account",
			"cls":3,
			"id":12345678,
			"mu":0,
			"rep":{
				1:{
					"id":1,
					"n":"Список поездок",
					"ct":"avl_unit",
					"c":59352
				},
				2:{
					"id":2,
					"n":"Поездки с группировкой",
					"ct":"avl_unit",
					"c":6883
				}
			},
			"repmax":-1,
			"uacl":-1
		}
	]
}

Обратим внимание на следующие параметры из ответа:

  • nm — имя ресурса;
  • rep — массив шаблонов отчетов, созданных в ресурсе;

    Если данный параметр отображается пустым, то это означает, что в ресурсе не создано шаблонов отчетов.

  • n — имя подэлемента;
  • id — системный ID.

В данном случае пользователю доступен ресурс sdk_account с системным ID 12345678, в котором находится шаблон отчета Список поездок с системным ID 1.

3. Выполнение отчета

Используем запрос report/exec_report.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/exec_report¶ms={"reportResourceId":12345678,"reportTemplateId":1,"reportObjectId":55555,"reportObjectSecId":0,"interval":{"flags":0,"from":1688144400,"to":1688173199},"remoteExec":1}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"reportResourceId":12345678

Шаблон отчета будет выбран из ресурса с системным ID 12345678.

"reportTemplateId":1

Будет выполнен шаблон отчета с системным ID 1.

"reportObjectId":55555

Отчет будет выполнен для объекта с системным ID 55555.

"reportObjectSecId":0Отчет будет выполняться не для подэлемента.
"flags":0Отчет будет выполнен за указанный интервал.
"from":1688144400

Началом интервала будет 2023 Июнь 30 20:00 (GMT+0).

В запросах используется Unix-время. Для перевода даты и времени в Unix-время можно использовать общедоступные онлайн-инструменты.

"to":1688173199Концом интервала будет 2023 Июль 01 03:59 (GMT+0).
"remoteExec":1Отчет будет выполнен в фоновом режиме на сервере.
 Ответ
{
	"remoteExec":1
}

4. Проверка статуса выполнения

Так как отчет выполняется в фоновом режиме на сервере, то проверим статус его выполнения, используя запрос report/get_report_status.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/get_report_status¶ms={}&sid=ИДЕНТИФИКАТОР_СЕССИИ
 Ответ
{
	"status":4
}

Код статуса 4 означает, что отчет выполнен. Интерпретацию остальных значений можно найти на странице с описанием запроса.

5. Получение результата отчета

Используем запрос report/apply_report_result.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/apply_report_result¶ms={}&sid=ИДЕНТИФИКАТОР_СЕССИИ
 Ответ
{
	"reportResult":{
		"msgsRendered":0,
		"stats":[],
		"tables":[
			{
				"name":"unit_trips",
				"label":"Поездки",
				"grouping":{},
				"flags":4224,
				"rows":4,
				"level":1,
				"columns":5,
				"header":[
					"№",
					"Начало",
					"Конец",
					"Длительность",
					"Пробег"
				],
				"header_type":[
					"",
					"time_begin",
					"time_end",
					"duration",
					"mileage"
				]
			}
		],
		"attachments":[]
	}
}

Три ключевых параметра из ответа, интересующих нас, выглядят следующим образом:

  • tables — показывает количество таблиц в отчете в виде массива. В данном случае упоминается только одна таблица — Поездки, следовательно, ее индекс будет равен 0.
  • rows — количество строк в таблице, в данном случае их 4. Следовательно, их индексы лежат в диапазоне от 0 до 3.
  • level — количество уровней вложенности, в данном случае оно равно 1, так как в отчете отсутствует группировка.

Индексы таблиц, строк, столбцов и уровней вложенности отсчитываются с 0. Это стоит учитывать при последующем обращении к ним.

Также можно коротко перечислить другие параметры из ответа. Параметр columns говорит о количестве столбцов, далее их имена описаны в параметре header. Нулевое значение параметра msgsRendered говорит о том, что в шаблоне отчета не включено отображение сообщений на карте. Пустые параметры stats и attachments говорят о том, что в шаблоне отчета отсутствует Статистика и приложения (например, графики).

6. Получение строк таблицы

Зная индекс содержимого таблицы, отобразим ее, используя запрос report/get_result_rows.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/get_result_rows¶ms={"tableIndex":0,"indexFrom":0,"indexTo":3}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"tableIndex":0

Будет отображено содержимое таблицы с индексом 0.

"indexFrom":0

Первая отображаемая строка будет иметь индекс 0.

"indexTo":3

Последняя отображаемая строка будет иметь индекс 3.

 Ответ
[
	{
		"n":0,
		"i1":0,
		"i2":790,
		"t1":1688144420,
		"t2":1688154878,
		"d":0,
		"c":[
			"1",
			{
				"t":"2023-06-30 20:00:20",
				"v":1688144420,
				"y":47.2941741943,
				"x":26.4906959534,
				"u":55555
			},
			{
				"t":"2023-06-30 22:54:38",
				"v":1688154878,
				"y":43.8697662354,
				"x":26.0177116394,
				"u":55555
			},
			"2:54:18",
			"469.54 км"
		]
	},
	{
		"n":1,
		"i1":936,
		"i2":2171,
		"t1":1688155181,
		"t2":1688169690,
		"d":0,
		"c":[
			"2",
			{
				"t":"2023-06-30 22:59:41",
				"v":1688155181,
				"y":43.8698196411,
				"x":26.0177154541,
				"u":55555
			},
			{
				"t":"2023-07-01 03:01:30",
				"v":1688169690,
				"y":41.7139854431,
				"x":26.3660545349,
				"u":55555
			},
			"4:01:49",
			"343.84 км"
		]
	},
	{
		"n":2,
		"i1":2340,
		"i2":2486,
		"t1":1688170034,
		"t2":1688170841,
		"d":0,
		"c":[
			"3",
			{
				"t":"2023-07-01 03:07:14",
				"v":1688170034,
				"y":41.7140579224,
				"x":26.365901947,
				"u":55555
			},
			{
				"t":"2023-05-01 09:23:10",
				"v":1688170841,
				"y":41.7122383118,
				"x":26.3712425232,
				"u":55555
			},
			"0:13:27",
			"1.39 км"
		]
	},
	{
		"n":3,
		"i1":2833,
		"i2":2910,
		"t1":1688171565,
		"t2":1688173175,
		"d":0,
		"c":[
			"4",
			{
				"t":"2023-07-01 03:32:45",
				"v":1688171565,
				"y":41.7120819092,
				"x":26.3711204529,
				"u":55555
			},
			{
				"t":"2023-07-01 03:59:35",
				"v":1688173175,
				"y":41.5760040283,
				"x":26.9871864319,
				"u":55555
			},
			"0:26:50",
			"57.84 км"
		]
	}
]

7. Экспорт в файл

Экспортируем результат в PDF-файл, используя запрос report/export_result.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/export_result¶ms={"format":2,"compress":0,"outputFileName":"Список%20поездок"}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"format":2

Результат отчета будет экспортирован в формат PDF.

"compress":0Экспортируемый файл не будет сжат (добавлен в архив).
"outputFileName":"Список%20поездок"Экспортируемый файл будет иметь имя Список поездок.

Ответ на данный API-запрос не отображается, вместо этого автоматически начинается загрузка файла.

8. Удаление результата предыдущего отчета

Используем запрос report/cleanup_result.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/cleanup_result¶ms={}&sid=ИДЕНТИФИКАТОР_СЕССИИ
 Ответ
{
	"error":0
}

Нулевое значение означает успешное удаление.

Работа с отчетом с группировкой

Необходимо получить результаты выполнения отчета Поездки с группировкой, доступного авторизованному по токену пользователю, для объекта Грузовик 0769 (системный ID 55555) за интервал времени с 2023 Июнь 30 20:00 до 2023 Июль 01 03:59 (GMT+0) в виде ответа на API-запрос и PDF-файла.

В веб-интерфейсе результат выглядит следующим образом:

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

  • на 1-м уровне расположены строки с месяцами;
  • на 2-м — строки с датой в рамках месяца;
  • на 3-м — строки непосредственно с поездками в рамках даты.

1. Авторизация и настройка локализации

Используем запрос token/login.

https://hst-api.wialon.com/wialon/ajax.html?svc=token/login¶ms={"token":"ЗНАЧЕНИЕ_ТОКЕНА"}

Более подробно авторизация описана в одной из предыдущих статей.

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

Если настройка часового пояса выполнена в рамках сессии, то далее при выполнении отчета время задается в GMT+0.

Используем запрос render/set_locale.

https://hst-api.wialon.com/wialon/ajax.html?svc=render/set_locale¶ms={"tzOffset":134217728,"language":"ru","formatDate":"%25E.%25m.%25Y%20%25H:%25M:%25S"}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"tzOffset":134217728

Будет применен часовой пояс GMT+0 (без перехода на летнее время).

"language":"ru"

Будет использоваться русский язык.

"formatDate":"%25Y.%25m.%25E%20%25H:%25M:%25S"Будет использоваться формат даты yyyy-MM-dd и формат времени HH:mm:ss.

Невыполнение настройки локализации может приводить к различию результатов при выполнении отчета через Remote API и веб-интерфейс.

2. Получение системных ID

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

Получим список всех ресурсов, в которых создан шаблон отчета с именем Поездки с группировкой, доступных пользователю, для которого выполнена авторизация по токену. Используем запрос core/search_items:

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_resource","propType":"propitemname","propName":"reporttemplates","propValueMask":"Поездки%20с%20группировкой","sortType":"sys_name"},"force":1,"flags":8193,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"itemsType":"avl_resource"

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

"propType":"propitemname"Поиск будет выполнен по имени подэлемента.
"propName":"reporttemplates"

Поиск будет выполнен по имени шаблона отчета.

"propValueMask":"Поездки%20с%20группировкой"

В ответе будет отображен список ресурсов, в котором создан шаблон отчета с названием Поездки с группировкой.

"sortType":"sys_name"Сортировка будет выполнена по имени элемента.
"force":1Результаты предыдущих поисков не будут учитываться.
"flags":8193

В ответе будет содержаться информация об основных свойствах и о созданных шаблонах отчетов.

1 + 8192 = 8193

"from":0;"to":0Ограничения по количеству найденных элементов не будут применяться.
 Ответ
{
	"searchSpec":{
		"itemsType":"avl_resource",
		"propName":"reporttemplates",
		"propValueMask":"Поездки с группировкой",
		"sortType":"sys_name",
		propType:"propitemname",
		or_logic:"0"
		},
	"dataFlags":8193,
	"totalItemsCount":1,
	"indexFrom":0,
	"indexTo":0,
	"items":[
		{
			"nm":"sdk_account",
			"cls":3,
			"id":12345678,
			"mu":0,
			"rep":{
				1:{
					"id":1,
					"n":"Список поездок",
					"ct":"avl_unit",
					"c":59352
				},
				2:{
					"id":2,
					"n":"Поездки с группировкой",
					"ct":"avl_unit",
					"c":6883
				}
			},
			"repmax":-1,
			"uacl":-1
		}
	]
}

Обратим внимание на следующие параметры из ответа:

  • nm — имя ресурса;
  • rep — массив шаблонов отчетов, созданных в ресурсе;

    Если данный параметр отображается пустым, то это означает, что в ресурсе не создано шаблонов отчетов.

  • n — имя подэлемента;
  • id — системный ID.

В данном случае пользователю доступен ресурс sdk_account с системным ID 12345678, в котором находится шаблон отчета Поездки с группировкой с системным ID 2.

3. Выполнение отчета

Используем запрос report/exec_report.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/exec_report¶ms={"reportResourceId":12345678,"reportTemplateId":2,"reportObjectId":55555,"reportObjectSecId":0,"interval":{"flags":0,"from":1688144400,"to":1688173199},"remoteExec":1}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"reportResourceId":12345678

Шаблон отчета будет выбран из ресурса с системным ID 12345678.

"reportTemplateId":2

Будет выполнен шаблон отчета с системным ID 2.

"reportObjectId":55555

Отчет будет выполнен для объекта с системным ID 55555.

"reportObjectSecId":0Отчет будет выполняться не для подэлемента.
"flags":0Отчет будет выполнен за указанный интервал.
"from":1688144400

Началом интервала будет 2023 Июнь 30 20:00 (GMT+0).

В запросах используется Unix-время. Для перевода даты и времени в Unix-время можно использовать общедоступные онлайн-инструменты.

"to":1688173199Концом интервала будет 2023 Июль 01 03:59 (GMT+0).
"remoteExec":1Отчет будет выполнен в фоновом режиме на сервере.
 Ответ
{
	"remoteExec":1
}

4. Проверка статуса выполнения

Так как отчет выполняется в фоновом режиме на сервере, то проверим статус его выполнения, используя запрос report/get_report_status.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/get_report_status¶ms={}&sid=ИДЕНТИФИКАТОР_СЕССИИ
 Ответ
{
	"status":4
}

Код статуса 4 означает, что отчет выполнен. Интерпретацию остальных значений можно найти на странице с описанием запроса.

5. Получение результата отчета

Используем запрос report/apply_report_result.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/apply_report_result¶ms={}&sid=ИДЕНТИФИКАТОР_СЕССИИ
 Ответ
{
	"reportResult":{
		"msgsRendered":0,
		"stats":[],
		"tables":[
			{
				"name":"unit_trips",
				"label":"Поездки",
				"grouping":{
					"nested":{
						"type":"day"
					},
					"type":"month"
				},
				"flags":4491,
				"rows":2,
				"level":3,
				"columns":6,
				"header":[
					"№",
					"Группировка",
					"Начало",
					"Конец",
					"Длительность",
					"Пробег"
				],
				"header_type":[
					"",
					"",
					"time_begin",
					"time_end",
					"duration",
					"mileage"
				]
			}
		],
		"attachments":[]
	}
}

Три ключевых параметра из ответа, интересующих нас, выглядят следующим образом:

  • tables — показывает количество таблиц в отчете в виде массива. В данном случае упоминается только одна таблица — Поездки, следовательно, ее индекс будет равен 0.
  • rows — количество строк в таблице, в данном случае их 2. Следовательно, их индексы лежат в диапазоне от 0 до 1. Речь идет только про строки на верхнем уровне вложенности, внутри их может быть больше.
  • level — количество уровней вложенности, в данном случае оно равно 3, так как в отчете присутствует группировка. Следовательно, в таблице существуют уровни с индексами от 0 до 2.

Индексы таблиц, строк, столбцов и уровней вложенности отсчитываются с 0. Это стоит учитывать при последующем обращении к ним.

Также можно коротко перечислить другие параметры из ответа. Параметр columns говорит о количестве столбцов, далее их имена описаны в параметре header. Нулевое значение параметра msgsRendered говорит о том, что в шаблоне отчета не включено отображение сообщений на карте. Пустые параметры stats и attachments говорят о том, что в шаблоне отчета отсутствует Статистика и приложения (например, графики).

6. Выбор строк в многоуровневой таблице

Зная индекс содержимого таблицы отобразим ее, используя запрос report/select_result_rows.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/select_result_rows¶ms={"tableIndex":0,"config":{"type":"range","data":{"from":0,"to":1,"level":2}}}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"tableIndex":0

Будет отображено содержимое таблицы с индексом 0.

"type":"range"Запрашиваться будет последовательность строк.
"from":0

Первая отображаемая строка будет иметь индекс 0.

"to":1

Последняя отображаемая строка будет иметь индекс 1.

"level":2Результат будет отображать уровни вложенности вплоть до индекса 2.
 Ответ
[
	{
		"n":0,
		"i1":0,
		"i2":1188,
		"t1":1688144420,
		"t2":1688158739,
		"d":1,
		"c":[
			"1",
			"Июнь",
			{
				"t":"20:00:20",
				"v":1688144420,
				"y":47.2941741943,
				"x":26.4906959534,
				"u":55555
			},
			{
				"t":"23:58:59",
				"v":1688158739,
				"y":43.1049079895,
				"x":25.6173667908,
				"u":55555
			},
			"3:53:36",
			"576.60 км"
		],
		"r":[
			{
				"n":0,
				"i1":0,
				"i2":1188,
				"t1":1688144420,
				"t2":1688158739,
				"d":2,
				"c":[
					"1.1",
					"2023-06-30",
					{
						"t":"20:00:20",
						"v":1688144420,
						"y":47.2941741943,
						"x":26.4906959534,
						"u":55555
					},
					{
						"t":"23:58:59",
						"v":1688158739,
						"y":43.1049079895,
						"x":25.6173667908,
						"u":55555
					},
					"3:53:36",
					"576.60 км"
				],
				"r":[
					{
						"n":0,
						"i1":0,
						"i2":790,
						"t1":1688144420,
						"t2":1688154878,
						"d":0,
						"c":[
							"1.1.1",
							"2023-06-30 20:00:20",
							{
								"t":"20:00:20",
								"v":1688144420,
								"y":47.2941741943,
								"x":26.4906959534,
								"u":55555
							},
							{
								"t":"22:54:38",
								"v":1688154878,
								"y":43.8697662354,
								"x":26.0177116394,
								"u":55555
							},
							"2:54:18",
							"469.54 км"
						]
					},
					{
						"n":1,
						"i1":936,
						"i2":1188,
						"t1":1688155181,
						"t2":1688158739,
						"d":0,
						"c":[
							"1.1.2",
							"2023-06-30 22:59:41",
							{
								"t":"22:59:41",
								"v":1688155181,
								"y":43.8698196411,
								"x":26.0177154541,
								"u":55555
							},
							{
								"t":"23:58:59",
								"v":1688158739,
								"y":43.1049079895,
								"x":25.6173667908,
								"u":55555
							},
							"0:59:18",
							"107.06 км"
						]
					}
				]
			}
		]
	},
	{
		"n":1,
		"i1":1193,
		"i2":2910,
		"t1":1688158805,
		"t2":1688173175,
		"d":1,
		"c":[
			"2",
			"Июль",
				{
					"t":"00:00:05",
					"v":1688158805,
					"y":43.0983314514,
					"x":25.6316585541,
					"u":55555
				},
				{
					"t":"03:59:35",
					"v":1688173175,
					"y":41.5760040283,
					"x":26.9871864319,
					"u":55555
				},
				"3:41:42",
				"294.55 км"
		],
		"r":[
			{
				"n":0,
				"i1":1193,
				"i2":2910,
				"t1":1688158805,
				"t2":1688173175,
				"d":3,
				"c":[
					"2.1",
					"2023-07-01",
					{
						"t":"00:00:05",
						"v":1688158805,
						"y":43.0983314514,
						"x":25.6316585541,
						"u":55555
					},
					{
						"t":"03:59:35",
						"v":1688173175,
						"y":41.5760040283,
						"x":26.9871864319,
						"u":55555
					},
					"3:41:42",
					"294.55 км"
				],
				"r":[
					{
						"n":0,
						"i1":1193,
						"i2":2171,
						"t1":1688158805,
						"t2":1688169690,
						"d":0,
						"c":[
							"2.1.1",
							"2023-07-01 00:00:05",
							{
								"t":"00:00:05",
								"v":1688158805,
								"y":43.0983314514,
								"x":25.6316585541,
								"u":55555
							},
							{
								"t":"03:01:30",
								"v":1688169690,
								"y":41.7139854431,
								"x":26.3660545349,
								"u":55555
							},
							"3:01:25",
							"235.31 км"
						]
					},
					{
						"n":1,
						"i1":2340,
						"i2":2486,
						"t1":1688170034,
						"t2":1688170841,
						"d":0,
						"c":[
							"2.1.2",
							"2023-07-01 03:07:14",
							{
								"t":"03:07:14",
								"v":1688170034,
								"y":41.7140579224,
								"x":26.365901947,
								"u":55555
							},
							{
								"t":"03:20:41",
								"v":1688170841,
								"y":41.7122383118,
								"x":26.3712425232,
								"u":55555
							},
							"0:13:27",
							"1.39 км"
						]
					},
					{
						"n":2,
						"i1":2833,
						"i2":2910,
						"t1":1688171565,
						"t2":1688173175,
						"d":0,
						"c":[
							"2.1.3",
							"2023-07-01 03:32:45",
							{
								"t":"03:32:45",
								"v":1688171565,
								"y":41.7120819092,
								"x":26.3711204529,
								"u":55555
							},
							{
								"t":"03:59:35",
								"v":1688173175,
								"y":41.5760040283,
								"x":26.9871864319,
								"u":55555
							},
							"0:26:50",
							"57.84 км"
						]
					}
				]
			}
		]
	}
]

7. Экспорт в файл

Экспортируем результат в PDF-файл, используя запрос report/export_result.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/export_result¶ms={"format":2,"compress":0,"outputFileName":"Поездки%20с%20группировкой"}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"format":2

Результат отчета будет экспортирован в формат PDF.

"compress":0Экспортируемый файл не будет сжат (добавлен в архив).
"outputFileName":"Поездки%20с%20группировкой"Экспортируемый файл будет иметь имя Поездки с группировкой.

Ответ на данный API-запрос не отображается, вместо этого автоматически начинается загрузка файла.

8. Удаление результата предыдущего отчета

Используем запрос report/cleanup_result.

https://hst-api.wialon.com/wialon/ajax.html?svc=report/cleanup_result¶ms={}&sid=ИДЕНТИФИКАТОР_СЕССИИ
 Ответ
{
	"error":0
}

Нулевое значение означает успешное удаление.

Особенности получения результатов

Получение данных из таблиц может осуществляться с помощью запросов report/get_result_rows или report/select_result_rows, в которых используется параметр tableIndex, чтобы обратиться к таблице с определенным индексом. При этом необходимо учитывать, что при выполнении отчета за разные интервалы индекс одной и той же таблицы может меняться из-за наличия или отсутствия других таблиц.

Для лучшего понимания ситуации рассмотрим пример. Предположим, что в шаблон отчета добавлены таблицы Поездки, Сливы и Геозоны. При выполнении отчета за интервал с 1 по 3 июля результат будет содержать все таблицы, а потому их индексы примут следующие значения:

0 — Поездки
1 — Сливы
2 — Геозоны

А при выполнении отчета за интервал с 4 по 6 июля индексы некоторых таблиц поменяются из-за отсутствия зарегистрированных сливов и примут другие значения:

0 — Поездки
1 — Геозоны

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

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


Екатерина Гриб,Инженер Customer Service

Введение в SDK: FAQ
  • technical_consulting

В данной статье собраны ответы на наиболее часто задаваемые вопросы касательно Remote API.

Также вам могут быть полезны:

  • Статья Введение в SDK: базовые запросы.
  • Статья Введение в SDK: создание учетных записей и объектов.
  • Статья Введение в SDK: выполнение отчетов.
  • Портал для разработчиков с документаций и подробным описанием каждого запроса.
  • Примеры готовых решений с использованием SDK из раздела Маркетплейс.
  • Серия вебинаров Wialon API и SDK: обучающие видео.
  • Коллекция примеров в приложении Postman для тестирования API-запросов.
  • Раздел форума Собственные разработки под Wialon.

Существуют ли ограничения на использование API?

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

Ограничения существуют и у некоторых запросов, они упоминаются в описании запроса в документации. Например, одновременно в сессии может быть выполнен только один отчет. Если в сессии содержатся результаты выполнения предыдущего отчета, то их следует удалить с помощью запроса report/cleanup_result перед выполнением следующего отчета. Также запрос на выполнение отчетов не может выполняться одновременно с некоторыми другими запросами.

Можно ли с помощью API организовать передачу данных из Wialon в реальном времени?

Нет. API-запросы работают по принципу «запрос-ответ». То есть данные на принимающей стороне не будут обновляться без отправления запроса.

Если необходимо получать данные от оборудования по мере поступления новых сообщений, то можно использовать ретрансляторы.

Как создать локатор через API?

Рассмотрим пример: необходимо создать локатор с неограниченным сроком действия, на котором будут отображаться объекты с системным ID 11111111 и 22222222, а также геозоны из ресурса с системным ID 12345678, но не будут отображаться треки объектов.

Для этого нужно использовать запрос token/update:

https://hst-api.wialon.com/wialon/ajax.html?svc=token/update¶ms=
{"callMode":"create","app":"locator","at":0,"dur":0,"fl":256,"p":"{\"note\":\"Bus\",\"zones\":1,\"tracks\":0}","items":[11111111,22222222,12345678]}&sid=ИДЕНТИФИКАТОР_СЕССИИ
Параметр и его значениеОписание
"callMode":"create"

В качестве действия выбрано создание (также доступны редактирование и удаление).

"app":"locator"Значение locator необходимо для отображения в списке ссылок в веб-интерфейсе.
"at":0

Время активации токена в UNIX-time равно 0, то есть локатор начнет работу сразу после создания.

"dur":0

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

"fl":256Данное значение флагов доступа предоставит возможность только отслеживать объекты в режиме онлайн.
"p":"{\"note\":\"Bus\",\"zones\":1,\"tracks\":0}"В качестве примечания будет использоваться слово Bus, которое позволит отличить локатор от других в общем списке. Локатор будет отображать геозоны, но не будет отображать треки объектов.
"items":[11111111,22222222,12345678]

В локаторе будут отображаться объекты с системными ID 11111111 и 22222222, а также геозоны из ресурса с системным ID 12345678.

В ответе на запрос будет присутствовать параметр h, содержащий значение токена. Для получения искомой ссылки необходимо подставить значение токена в ссылку: https://hosting.wialon.com/locator/index.html?t=ЗНАЧЕНИЕ_ТОКЕНА

Как получить токен с максимальным доступом и без ограничения срока жизни?

Если создание токена осуществляется через расширенную форму, то необходимо использовать параметры access_type=-1 и duration=0. Например:

https://hosting.wialon.com/login.html?client_id=ИМЯ_ПРИЛОЖЕНИЯ&access_type=-1&activation_time=0&duration=0&lang=ru&flags=0&user=ИМЯ_ПОЛЬЗОВАТЕЛЯ

Если создание токена осуществляется через запрос token/update, то необходимо использовать параметры fl=-1 и dur=0. Например:

https://hst-api.wialon.com/wialon/ajax.html?svc=token/update¶ms=
{"callMode":"create","app":"Wialon Hosting","at":0,"dur":0,"fl":-1,"p":"{}"}&sid=ИДЕНТИФИКАТОР_СЕССИИ

Токен автоматически удаляется, если он не используется в течение 100 дней, даже если срок его жизни не ограничен (параметр duration или dur равны 0).

Почему при использовании бессрочного токена может возвращаться ошибка с кодом 1?

Ошибка с кодом 1 говорит о том, что текущая сессия недействительна. Срок жизни токена не связан с сессией напрямую.

Для исправления ситуации необходимо повторно выполнить авторизацию. В ответе на логин под токеном будет содержаться параметр eid, значение которого является уникальным идентификатором сессии. Далее он будет использоваться практически во всех API-запросах.

Если в течение 5 минут в рамках сессии не выполняется ни одного запроса, то она становится неактивной. Чтобы поддерживать сессию, вы можете каждые 5 минут отправлять запрос avl_evts.

Как исправить ошибку с кодом 4?

Ошибка с кодом 4 соответствует неверному вводу, что может означать:

  • неправильный тип данных (числовой, текстовый и т. д.);

  • неправильные имена параметров;
  • неправильные разделители (запятые, кавычки, пробелы, скобки и т. п.);
  • отсутствие кодировки для передачи в URL.

Рассмотрим пример запроса со всеми обозначенными ошибками:

https://hst-api.wialon.com/wialon/ajax.html?svc=report/export_result¶ms={"format":"2";"compres":0;"outputFileName":"Список поездок"}&sid=ИДЕНТИФИКАТОР_СЕССИИ

В данном примере были допущены следующие ошибки:

  1. параметр format должен содержать число, но так как его значение указано в кавычках, то оно воспринимается, как текст;
  2. вместо параметра с именем compress использовался параметр с именем compres;
  3. для разделения параметров вместо запятой использовалась точка с запятой;
  4. символ пробела не был закодирован для передачи в URL.

Для проверки кодировки в URL можно использовать общедоступные онлайн-инструменты.

Правильный запрос будет выглядеть следующим образом:

https://hst-api.wialon.com/wialon/ajax.html?svc=report/export_result¶ms={"format":2,"compress":0,"outputFileName":"Список%20поездок"}&sid=ИДЕНТИФИКАТОР_СЕССИИ

Почему при использовании уникальных ID объектов возникает ошибка с кодом 7?

В API-запросах используются не уникальные ID объектов с вкладки Основное, а внутренние системные ID элементов. По умолчанию они не отображаются в веб-интерфейсах.

Чтобы получить системные ID элементов, можно использовать запрос поиска элементов по критериям (core/search_items). В ответе на данный запрос в параметре id будет находиться искомое значение.

Другие методы отображения системных ID описаны в статье Введение в SDK: базовые запросы.

Почему доступ к элементу ограничен, хотя пользователь имеет полные права?

Вероятно, проблема возникает из-за нехватки прав у используемого токена.

Для проверки прав токена выполните логин под ним:

https://hst-api.wialon.com/wialon/ajax.html?svc=token/login¶ms={"token":"ЗНАЧЕНИЕ_ТОКЕНА"}

В ответе будет содержаться параметр fl, который отображает текущие права токена. Чтобы их изменить, отредактируйте текущий токен или создайте новый.

Для предоставления различных прав флаги необходимо суммировать между собой.

Н
апример, если необходимо предоставить право на слежение онлайн ("fl":256) и доступ к большей части информации ("fl":512), то стоит использовать значение "fl":768, так как 256 + 512 = 768.

Как получить последние координаты объектов?

Для получения последних координат от нескольких объектов можно использовать запрос поиска элементов по критериям (core/search_items). При этом необходимо указать флаги доступа, согласно которым в ответе отобразятся имена объектов ("flag":1") и информация о последнем местоположении объектов ("flag":1024). Флаги можно суммировать между собой, поэтому в запросе будет использоваться значение 1 + 1024 = 1025.

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_unit","propName":"sys_name","propValueMask":"*","sortType":"sys_name"},"force":1,"flags":1025,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ

Как получить список всех доступных пользователю объектов?

Для вывода всех доступных пользователю объектов можно использовать запрос поиска элементов по критериям (core/search_items) со значением "propValueMask":"*".

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_unit","propName":"sys_name","propValueMask":"*","sortType":"sys_name"},"force":1,"flags":1,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ

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

Как получить имена групп, в которые включен определенный объект?

Чтобы получить имена групп, в которые входит объект с системным ID 11112222, необходимо использовать запрос поиска элементов по критериям (core/search_items) со значениями "itemsType":"avl_unit_group", "propName":"sys_units" и "propType":"list".

https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_unit_group","propName":"sys_units","propValueMask":11112222,"sortType":"sys_name","propType":"list"},"force":1,"flags":1,"from":0,"to":0}}&sid=ИДЕНТИФИКАТОР_СЕССИИ

Как получить имена объектов из определенной группы?

Чтобы получить имена объектов, которые входят в группу с именем Group, необходимо использовать два запроса поиска элементов по критериям (core/search_items): первый будет искать по группе объектов (avl_unit_group), а второй — по объекту (avl_unit).

  1. Сначала нужно получить список системных ID объектов, которые входят в группу (ее имя нужно указать в параметре propValueMask):

    https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_unit_group","propName":"sys_name","propValueMask":"Group","sortType":"sys_name"},"force":1,"flags":1,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
     Ответ
    {
    	"searchSpec":{
    		"itemsType":"avl_unit_group",
    		"propName":"sys_name",
    		"propValueMask":"Group",
    		"sortType":"sys_name",
    		"propType":"",
    		"or_logic":"0"
    	},
    	"dataFlags":1,
    	"totalItemsCount":1,
    	"indexFrom":0,
    	"indexTo":0,
    	"items":[
    		{
    			"nm":"Group",
    			"cls":5,
    			"id":10000000,
    			"mu":0,
    			"u":[
    				20000001,
    				20000002,
    				20000003
    			],
    			"uacl":-1
    		}
    	]
    }
    
  2. В ответе на предыдущий запрос необходимо найти параметр u с системными ID объектов. Их нужно подставить в параметр propValueMask для следующего запроса поиска:

    https://hst-api.wialon.com/wialon/ajax.html?svc=core/search_items¶ms={"spec":{"itemsType":"avl_unit","propName":"sys_id","propValueMask":"20000001,20000002,20000003","sortType":"sys_name"},"force":1,"flags":1,"from":0,"to":0}&sid=ИДЕНТИФИКАТОР_СЕССИИ
     Ответ
    {
    	searchSpec:{
    		itemsType:"avl_unit",
    		propName:"sys_id",
    		propValueMask:"20000001,20000002,20000003",
    		sortType:"sys_name",
    		propType:"",
    		or_logic:"0"
    	},
    	dataFlags:1,
    	totalItemsCount:3,
    	indexFrom:0,
    	indexTo:0,
    	items:[
    		{
    			nm:"Unit_1",
    			cls:2,
    			id:20000001,
    			mu:0,
    			uacl:-1
    		},
    		{
    			nm:"Unit_2",
    			cls:2,
    			id:20000002,
    			mu:0,
    			uacl:-1
    		},
    		{
    			nm:"Unit_3",
    			cls:2,
    			id:20000003,
    			mu:0,
    			uacl:-1
    		}
    	]
    }
    

    Имена объектов будут отображаться в параметрах nm.

Почему отличаются результаты отчета в интерфейсе и в ответе на API-запрос?

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

При работе с отчетами через API необходимо учитывать особенности получения результатов по индексу таблицы.

Екатерина Гриб,Инженер Customer Service

10
  • 10
  • 25
  • 30
Спасибо за ваш отзыв!
Сообщить об ошибке
Текст с ошибкой Комментарий
Максимум 500 символов