ОPC UA

Введение

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

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

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

OPC UA модуль можно развернуть с использованием Baetyl и Baetyl-Cloud и использовать вместе с Baetyl-Broker. Baetyl автоматически настроит соединение OPC UA и Baetyl-Broker с использованием двустороннего TLS.

Для получения дополнительной информации см. документацию Baetyl (https://docs.baetyl.io/zh_CN/latest/) и лучшие практики (https://docs.baetyl.io/zh_CN/latest/practice/application-deployment-practice.html).

Конфигурацию модуля можно разделить на три части: 1. Конфигурация подключения устройства; 2. Конфигурация задачи; 3. Конфигурация отправки данных:

Конфигурация подключения устройства

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

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

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

id: 1 # Идентификатор устройства
endpoint: opc.tcp://<ip>:53530/OPCUA/Server # Конечная точка устройства
timeout: 20s # По умолчанию 10 секунд
security:
  policy: None # Можно выбрать None, Basic128Rsa15, Basic256, Basic256Sha256, Aes128Sha256RsaOaep, Aes256Sha256RsaPss
  mode: None # Можно выбрать Invalid, None, Sign, SignAndEncrypt
auth:
  username: test # Имя пользователя
  password: test # Пароль

Задача

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

Подробности конфигурации следующие:

deviceid: 1 # Идентификатор соответствующего устройства задачи
interval: 20s # Интервал считывания
time: # Информация о времени задачи
  name: time # Поле времени, по умолчанию «время»
  type: integer # Можно настроить как integer и string, по умолчанию integer
  format: '2006-01-02 15:04:05' # Формат времени, необходимо настроить в соответствии с форматом времени 2006-01-02 15:04:05, по умолчанию 2006-01-02 15:04:05
  precision: s # Можно настроить s или ns, то есть точность до секунд или наносекунд, по умолчанию s
properties:
- name: var # Имя переменной считываемых данных
  type: float64 # Тип данных считываемых данных
  nodeid: ns=1;i=1001 # Точка данных считывания
publish:
  topic: # Тема отправки
  qos: # QoS отправки

Эта конфигурация означает, что данные считываются с устройства с идентификатором 1 через равные промежутки времени в 20 секунд. Nodeid считываемых данных — ns=1;i=1001, а данные, собранные после считывания, проверяются на соответствие типу данных, указанному именем переменной. Здесь имя переменной — var. Таким образом, данные для отправки (не фактические данные) имеют формат:

{
  "deviceid": 1,
  "time": "2020-05-20 15:04:05",
  "attr": {
    "var": 35.32
  }
}

Эти данные будут отправлены в jobs определённую тему. При запуске в Baetyl можно не настраивать тему, по умолчанию она будет /.

• NodeId Часть идентификатора узла однозначно идентифицирует узел в пространстве имён. Для формирования полного уникального идентификатора требуется пространство имён плюс идентификатор.

• Типы данных Типы данных, поддерживаемые модулем для анализа данных, включают bool, int16, uint16, int32, uint32, int64, uint64, float32, float64 и string. При указании типа анализа следует использовать один из этих типов.

Отправка

В настоящее время модуль OPC UA может отправлять собранные или проанализированные данные через протокол MQTT на MQTT брокер. Соединение с брокером поддерживает tcp/ws/ssl/wss и т. д. Указывая тему MQTT для отправки, собранные или проанализированные данные будут отправляться в эту тему.

Конфигурация соединения MQTT:

broker:
  clientid: Client Идентификатор клиента, подключающегося к Hub. Если cleansession имеет значение false, он не должен быть пустым
  address: [Обязательно] Адрес подключения клиента к Hub
  username: Имя пользователя клиента, подключающегося к Hub
  password: Если используется учётная запись и пароль, необходимо заполнить пароль клиента, подключающегося к Hub, в противном случае не заполнять
  ca: Если используется двухсторонняя аутентификация сертификата, необходимо указать путь к сертификату CA клиента, подключающемуся к Hub
  key: Если используется двухсторонняя аутентификация сертификата, необходимо указать путь к закрытому ключу клиента, подключающемуся к Hub
  cert: Если используется двухсторонняя аутентификация сертификата, необходимо указать путь к открытому ключу клиента, подключающемуся к Hub
  timeout: Значение по умолчанию: 30 с, время ожидания подключения клиента к Hub
  maxReconnectInterval: Значение по умолчанию: 3 м, максимальный интервал повторного подключения клиента к Hub, начиная с 500 микросекунд и удваиваясь до максимального значения
  keepalive: Значение по умолчанию: 30 с, клиент поддерживает соединение с Hub
  cleansession: Значение по умолчанию: false, сохраняет ли клиент сеанс при подключении к Hub
  disableAutoAck: Значение по умолчанию: false, отключить автоматическое подтверждение
  subscriptions: Список тем подписки Hub
  maxCacheMessages: Значение по умолчанию: 10, размер очереди сообщений памяти клиента при отправке сообщений на Hub, аварийное завершение работы приведёт к потере сообщений, после восстановления QoS 1 сообщения зависят от повторной отправки Hub

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

broker:
  address: tcp://127.0.0.1:1883 # Адрес подключения к mqtt hub
  clientid: opcua-1 # Идентификатор клиента при подключении к mqtt hub, можно не настраивать при работе на основе фреймворка baetyl
devices:
  - id: 1 # Идентификатор устройства
    endpoint: opc.tcp://<ip>:53530/OPCUA/Server # Конечная точка устройства
jobs:
  - deviceid: 1 # Идентификатор задачи соответствующего устройства
    properties:
      - name: var1 # Имя переменной
        type: int16 # Тип данных
        nodeid: ns=3;i=1001 # Точка считывания данных
      - name: var2 # Имя переменной
        type: float64 # Тип данных
        nodeid: ns=2;i=1002 # Точка считывания данных
    publish:
      topic: test # Тема отправки данных
logger:
  filename: var/log/baetyl/service.log # Путь к журналу
  level: info # Уровень журнала

На примере этой конфигурации данные, считанные с устройства OPC UA, отправляются в тему test MQTT брокера и имеют следующую структуру:

{
  "deviceid": 1,
  "attr": {
    "var1": 43,
    "var2": 23.24
  },
  "time": 234435345,
}

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

Данные записываются в OPC UA-устройство главным образом через отправку данных по MQTT. Конфигурационный модуль подписывается на темы MQTT брокера и получает сообщения с данными для записи. Затем эти данные записываются в устройство.

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

В качестве примера можно взять типичную конфигурацию сбора и анализа. В jobs определены две переменные var1 и var2 с типами int16 и float64 соответственно.

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

broker:
  address: tcp://127.0.0.1:1883 # 连接mqtt hub的地址 
  clientid: opcua-1 # 连接mqtt hub时使用的client id，基于baetyl框架运行时可不配置
  subscriptions:
      - topic: control # 反控向从设备写入数据时订阅的主题
devices:
  - id: 1 # 设备id
    endpoint: opc.tcp://<ip>:53530/OPCUA/Server # 设备端点 
jobs:
  - deviceid: 1 # 读取任务的对应设备
    properties:
      - name: var1 # 变量名
        type: int16 # 数据类型
        nodeid: ns=3;i=1001 # 读取数据的nodeid
      - name: var2 # 变量名
        type: float64 # 数据类型
        nodeid: ns=2;i=1002 # 读取数据的nodeid
    publish:
      topic: test # 读取数据发送的mqtt主题
logger:
  filename: var/log/baetyl/service.log # 日志路径 
  level: info # 日志级别

Через отправку сообщений на тему control MQTT брокера можно записывать данные в устройство.

{
  "deviceid": 1,
  "attr": {
    "var1": 12,
    "var2": 89.87 
  }
}

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