Справка
Alpha.AccessPoint – это компонент Альфа платформы, который обеспечивает единую точку доступа к оперативным данным и событиям из множества источников.
Основные возможности Alpha.AccessPoint:
- объединение сигналов различных источников в единое дерево сигналов;
- объединение событий и тревог от различных источников;
- поддержание связи с источниками данных при разрыве соединения;
- передача значений и событий в виде TCP/IP-трафика в условиях различных сетевых топологий и работа в режиме каскадирования;
- поддержка сбора данных по файловому интерфейсу;
Доступ к данным Alpha.AccessPoint выполняется по спецификациям OPC DA, OPC AE, OPC UA.
Документация: Alpha.AccessPoint 6.3 > Назначение и принцип работы
Проблематика
По умолчанию Alpha.AccessPoint не может быть развернут на центральном узле домена Альфа платформы, однако в некоторых ситуациях это может быть необходимо.
Например, если в системе есть резервированная пара серверов и инженерная станция, определенная как центральный узел Alpha.Domain, которая одновременно выполняет роль АРМ (автоматизированного рабочего места), которому нужен доступ через Alpha.AccessPoint.
Решение
Чтобы обойти ограничение, роль AccessPoint на центральном узле может выполнять Alpha.Server, на который будет применяться конфигурация службы Alpha.AccessPoint (alpha.accesspoint.service – для Linux систем).
Документация: Alpha.Domain 1.4 > Принципы настройки подсистемы > Конфигурирование серверного компьютера в домене> Конфигурирование Domain-агента
Чтобы это сконфигурировать:
- Добавьте экземпляр Alpha.Server в центральный узел Alpha.Domain.
- В свойстве «Имя службы» укажите Alpha.AccessPoint (alpha.accesspoint.service – для Linux систем).
- Отредактируйте конфигурационный файл alpha.domain.agent.xml, добавив описание экземпляра Alpha.Server, на который применяется конфигурация службы Alpha.AccessPoint.
Таким образом, система будет корректно работать даже при таком нетипичном развертывании.
Рассмотрим детальную настройку на следующем примере.
Имеется резервная пара серверов:
WINDOWSSERVER2 – основной сервер и центральный узел сети Alpha.Domain.
Orel2 – резервный сервер.
На центральном узле WINDOWSSERVER2 добавим из панели элементов еще один экземпляр Alpha.Server, назовем AP(AccessPoint).
Для того, чтобы Alpha.DevStudio могла корректно автоматически сгенерировать файл alpha.domain.agent.xml при построении решения, в свойстве «Имя службы» компонента Alpha.Server (AP) должно быть указано имя службы ОС Windows или ОС Linux. В нашем случае пропишем Alpha.AccessPoint (alpha.accesspoint.service. – на Linux системах).
Экземпляр Alpha.Server «AP» конфигурируем как обычный экземпляр AccessPoint:
- В приложении размещаем ссылки на объекты сервера, которые хотим транслировать.
- Не забываем добавленным ссылкам задать атрибут: Om.Server → Attributes → Раскрывать ссылку динамически.
Документация: Alpha.DevStudio 3.27 > Руководство пользователя > Разработка проекта > Alpha.AccessPoint: создание привязок
- В свойствах «OPC UA Сервер» указываем имя точки подключения.
- В свойстве «Порт OPC TCP протокола», чтобы не было конфликтов с OPC UA, расположенным в «WinServer», укажем другой порт - «62543».
- Добавляем «HUB Module» он необходим для соединения с удаленными исполняющими компонентами.
- При необходимости получения исторических данных, можно добавить и настроить «History Module».
Далее, в файл alpha.domain.agent.xml на узле WINDOWSSERVER2 добавляем строки с описанием экземпляра Alpha.Server, на который применяется конфигурация службы Alpha.AccessPoint.
Перезапускаем службы Alpha.Domain.Agent и Alpha.Net.Agent.
Строим решение, применяем конфигурацию ко всем исполняющим компонентам.
Чтобы убедиться в корректной работе Alpha.AccessPoint, подключаемся к нему при помощи Alpha.OPCExplorer.
Сигналы в AccessPoint должны транслироваться в независимости от того, какой сервер находится в режиме РАБОТА.
В результате, при использовании такой конфигурации, данные поступают корректно, и мы можем использовать центральный узел как полноценный АРМ.