Архитектура TagNet

Источники разработки платформы

Разработка платформы стартовала в начале 2000-х годов, как развитие отдельных решений по сбору данных с низовых систем (контроллеры ТМ, приборы учета).

Основные принципы и архитектурные решения, которые закладывались в платформу:

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

Концептуальная архитектура платформы

Платформа состоит из трех основных элементов:

• Конфигуратор
• Сервер координатор
• Модули ввода/вывода (IO серверы)

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

Сервер координатор реализует JNDI API (внутреннее наименование Сервера координатора - JNDI сервер) и основная его задача - регистрация в реестре IO серверов и предоставление серверам списка уже зарегистрированных IO серверов.

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

Общий сценарий работы IO серверов следующий:

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

Для взаимодействия между модулями в сети TagNet используется протокол RMI (англ. Remote Method Invocation) - программный интерфейс вызова удаленных методов в языке Java.

На рисунке ниже показана общая схема взаимодействия модулей в сети TagNet.

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

Такой подход имеет следующие преимущества:

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

Ограничения:

• Описанный выше подход возможен потому, что в рамках обмена данными используется только один тип стандартизованных сообщений, состоящий из 4 элементов:
  • Имя тега
  • Метка времени
  • Значение тега
  • Метка качества

Ядро платформы и базовый комплект поставки

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

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

• Конфигуратор
• Сервер координатор
• Сервер OPC UA - используется как стандартный механизм для обмена данными со SCADA системами
• Клиент МЭК 104
• Клиент Modbus

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