OPC UA примитивный датчик.#1 Общее описание

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

Общее положение

Что датчик, что серверная часть, будут использовать open62541 как фреймворк для OPC UA. Аутентификация и авторизация клиента (датчика) на данном этапе будет отключена.

Функциональные требования к датчику

  1. Датчик должен представлять из себя небольшое устройство с возможностью работы по одному или нескольким каналам связи (Ethernet).
  2. Датчик должен иметь возможность передавать несколько значений, несколько типов значений. например если датчик включает в себя устройство изменения давления и устройство измерения влажности, оно должно иметь возможность передавать данные с обоих своих устройств.
  3. Датчик должен иметь синхронизированное время с сервером приема показаний (NTP).
  4. Датчик должен уметь работать в одноранговой (Ethernet) сети и самостоятельно искать в ней сервер для передачи (агрегации) показаний.
  5. Должен обеспечивать сохранение полученных показаний (в ограничениях связанных с объемом памяти) при не возможности их передать на сервер.
  6. Должен обеспечивать хранение своих настроек в энергонезависимой памяти (EEPROM), с возможностью их изменения без изменения программного кода. Также не должен иметь возможности менять настройки из программного кода.

Общая структура датчика

Датчик (устройство) будет состоять из следующих компонент: само устройство (Rspberry Pi Pico W), внешний EEPROM (AT24С256), внешней FLASH(W25Q128).

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

Функциональные требования к серверу

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

Общая структура сервера

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

Механизмом который будет обеспечивать сохранение передаваемых датчиком показаний будет служить OPC UA Historization

Среда функционирования датчиков. Модель среды.

Для моделирования среды будут использоваться следующие компоненты: датчики (датчик) на базе Raspberry Pi Pico W с прошивкой обеспечивающей описанную ранее функциональность, маршрутизатор (обеспечивающий также Wi-Fi, DHCP и NTP - Mikrotik), сервер OPC UA запущенный на платформе PC или на Raspberry Pi 3. Все они будут находится в одноранговой сети.

Структура передаваемых данных

Структуру передаваемых на сервер данных(показаний) можно представить в виде C составного типа данных:

struct Packet {
    UA_DateTime  time;
    UA_UInt16    kind;
    UA_Int64     value;
}

в котором time - это время когда датчик получил конкретное значение, kind - это тип передаваемого значения (обеспечение возможности передачи нескольких значений с одного датчика) тут будем иметь явное ограничение в 65535 возможных показаний, value - это непосредственно само значение показания.

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

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

Последовательность инициализации датчика в среде

После сброса/включения устройства будет выполняться следующа] последовательность дейтсвий:

  1. Чтение параметров (настроек) из внешней памяти EEPROM
  2. Инициализация Wi-Fi(Ethernet) модуля для подключения к сети
  3. Определение сервера NTP (в представленной выше топологии это тот же сервер что и DHCP). Синхронизация времени и установка RTC модуля.
  4. Запуск задачи сохранения показаний в случае невозможности их передать: инициализация внешней FLASH памяти и организация внутреннего получения показаний и сохранения их на FLASH (не является критически важным компонентом)
  5. Получение из настроек discovery адреса сервера и попытка определения его в сети. В случае если сервер не определен, этот пункт повторяется.
  6. После нахождения сервера устанавливается соединение с ним. При не возможности установить соединение повторяется пункт 5
  7. После установки соединения производится регистрация устройства на серврере и получение в ответ NodeID для передачи показаний.
  8. В случае обрыва соединения переходим в пункт 5 и все показания перенаправляются в задачу сохранения показаний.
  9. Если есть сохраненные показания они передаются на сервер в момнт простоя приема показаний и/или по запросу сервера

Последовательность инициализации и рестрации устройства на серверер

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

  1. Инициализация сети
  2. Синхронизация времени
  3. Запуск модуля обнаружения сервера
  4. Инициализация функций, типов данный, историчности - для обеспечения приема показаний датчиков и их регистрации
  5. Прием соединений

При приеме запроса на регистрацию датчика:

  1. Получение необходимых сведений от устройства (в простейшем случае это MAC адрес, в дальнейшем, при включении аутентификации по сертификату сервер будет получать все необходимую информацию о датчике)
  2. Поиск устройства, на возможность его регистрации ранее. Если устройство регистрировалось ранее то, проверяем включена ли историчность, если не включена включаем и переходим в пункт 4
  3. Если устройство еще не регистрировалось то добавляется новый NodeID и включается режим историчности (для сохранения всех переданных показаний).
  4. Завершение вызова и возвращение NodeID для передачи показаний.

Ссылки: