Модель объекта контроля

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

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

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

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

Параметры модели устройства

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

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

Связь модели с базовым протоколом

При создании в модели новых команд, параметров и событий всегда производится «наследование» от базового протокола. Для создания новой команды необходимо «отнаследоваться» от базовой команды протокола, по которому работает устройство, и ввести аргументы, с которыми команда или несколько команд будут исполняться. Аналогичным образом это работает для событий и параметров. Например, если данные передаются от устройства на платформу и обратно по протоколу MQTT, то в этом случае для аргументов необходимо указывать источник данных — topic, по которому они отправляются.

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

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

Конфигурирование модели

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

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

ВНИМАНИЕ! В случае отсутствия у пользователя доступа к модели устройства, которая назначена на объект контроля, рендеринг интерфейсов, связанных с просмотром данных, производиться не будет.

Создание виртуальной модели физического устройства включает следующие шаги:

  1. Войти в меню «Модели».
  2. Вызвать диалоговое окно создания модели объектов контроля.
scheme

Далее необходимо заполнить следующие поля:

  • Имя — наименование модели;
  • Описание — подробная характеристика модели, которую можно добавить при желании;
  • Шаблон — заготовленная структура модели. В платформу добавлено несколько готовых моделей, созданных на основе реализованных в ней протоколов. Подобные шаблоны позволяют сделать процесс конфигурации моделей более удобным и быстрым, так как в шаблонах заранее заготовлены все необходимые параметры. В зависимости от того, по какому протоколу будут передаваться данные, выбирается соответствующий шаблон: MQTT, Wialon IPS или RIC HTTP, который используется для отправки HTTP-запросов и передачи данных по внутреннему HTTP API.

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

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

После нажатия кнопки «Создать» будет создана новая модель. Теперь можно приступать к ее конфигурированию.

По умолчанию созданная модель будет выглядеть следующим образом:

MQTT

RIC HTTP

scheme

Wialon IPS

scheme

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

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

Параметры узлов модели

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

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

scheme

Общие

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

Аргумент

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

Разделы «При разборе» и «Отображение» открывают дополнительные поля.

scheme
  • множитель: если выбран тип данных «Число», то значение аргумента будет перемножено на множитель;
  • единица измерения: она используется только для отображения во всех разделах платформы;
  • изображение: в формате svg задается иконка, которая будет представлять данный параметр в графическом виде в боковом меню объектов;
  • уровни: для индикации текущего значения параметра можно установить несколько цветов в формате числовых порогов, каждый из которых будет соответствовать своему собственному диапазону значений.

Действие

  • выполнить: выбирается тип действия, который необходимо будет выполнить;
  • в случае выбора автомата или действия (severless) в последнем поле указываются, соответственно, тот автомат или действие, которые необходимо выполнить;
  • в случае выбора команды к устройству в поле «Отправить» выбирается публикация сообщения, после чего указывается, с какими параметрами необходимо его опубликовать:
    • topic, по которому передается команда в виде сообщения на устройство;
    • payload, полезная нагрузка, содержащая текст передаваемого сообщения (например, в случае передачи сообщения в формате json указываются ключ и значение для каждого параметра, показания которого должны быть переданы на платформу и отображены в ее графическом интерфейсе);
    • ответ на полученное сообщение может быть отправлен устройством на указанный в последнем поле topic.

Мы используем cookies, чтобы сделать наш сайт полезным для вас.