Настройка Alpha.AccessPoint для клиентского компьютера. Конфигурирование АРМ в домене. Настройка и создание привязок со стороны Alpha.DevStudio.
Когда мы говорим о клиентских компьютерах - автоматизированных рабочих местах (АРМ) для персонала - диспетчеров, операторов и т. д., в первую очередь подразумевается визуальная часть проекта - визуальный интерфейс для взаимодействия человека с системой (мониторинг, управление и т. д.). В нашем случае это проект Alpha.HMI на клиентских компьютерах.
Проект Alpha.HMI может быть подключен напрямую к серверу (Alpha.Server) и полноценно с ним взаимодействовать, принимать данные и отправлять команды. И в некоторых случаях - простых проектах, например, с одним сервером - этого может быть достаточно.
Но когда рассматривается более сложная система, например, с использованием резервирования, необходимо как-то обеспечить бесперебойную работу Alpha.HMI с резервной парой серверов. Для решения этой задачи (и не только этой) существует компонент Alpha.AccessPoint.
Alpha.AccessPoint – это компонент Альфа-платформы, который обеспечивает единую точку доступа к оперативным, историческим данным и событиям, может консолидировать данные с множества разных машин-источников.
При работе с резервными парами серверов AccessPoint автоматически определяет активный сервер и переключается на резервный при сбое основной машины. Компонент запрашивает актуальные данные и отправляет управляющие команды только на тот сервер, который находится в состоянии "работа"
Основные возможности Alpha.AccessPoint:
объединение сигналов различных источников в единое дерево сигналов;
объединение событий и тревог от различных источников;
поддержание связи с источниками данных при разрыве соединения:
в случае разрыва соединения Alpha.AccessPoint пытается восстановить связь через резервные каналы активного сервера, если такие имеются. Если не удалось восстановить связь по резервным каналам активного сервера, то Alpha.AccessPoint переключается на работу с резервным сервером.выполняет роль сервера-приложений, который ограничивает нагрузку, создаваемую множеством клиентов при прямых подключениях к серверам;
обеспечивает высокую скорость обмена данными и простую методику конфигурирования в условиях неоднородной сетевой топологии благодаря использованию протокола на базе TCP/IP.
поддержка сбора данных по файловому интерфейсу;
Доступ к данным Alpha.AccessPoint выполняется по спецификациям OPC DA, OPC AE, OPC UA и по внутреннему проприетарному TCP-протоколу Alpha.Link.
Более подробно о вариантах использования Alpha.AccessPoint в документации:
Alpha.AccessPoint 6.4 > Назначение и принцип работы.
Как правило, в Альфа-платформе Alpha.AccessPoint является неотъемлемой частью при конфигурировании клиентских компьютеров (АРМов).
Ниже перечислены основные принципы конфигурирования АРМов:
Alpha.AccessPoint устанавливается, разворачивается локально на каждом АРМе.
Для объединения в домен на каждом АРМе конфигурируются службы Alpha.Net.Agent и Alpha.Domain.Agent (конфигурационные файлы alpha.net.agent.xml и alpha.domain.agent.xml).
Документация: Alpha.Domain 1.5 > Принципы настройки подсистемы > Конфигурирование клиентского компьютера в домене.
Все АРМы должны быть указаны, перечислены на центральном узле домена в конфигурационных файлах alpha.net.agent.xml и alpha.domain.agent.xml.
Документация: Alpha.Domain 1.5 > Принципы настройки подсистемы > Конфигурирование центрального узла сети Alpha.Net в домене.
Проекты Alpha.HMI на каждом АРМе настраиваются на работу со своей локальной службой Alpha.AccessPoint. В свойствах источника AP указывается хост, порт.
Всё остальное - с какими источниками работает Alpha.AccessPoint, какие данные получает и консолидирует - конфигурируется на уровне проекта в Alpha.DevStudio.
Alpha.AccessPoint можно и не разворачивать локально на каждом АРМе.
Возможен вариант и с одной общей точкой доступа для группы АРМов.
То есть, когда проекты Alpha.HMI на АРМах подключаются к одному общему Alpha.AccessPoint, развернутом на отдельном узле.
Однако в таком случае при выходе из строя данного узла (общей точки доступа) работоспособность - связь с серверами потеряет сразу вся группа АРМов.
Поэтому рекомендуемый вариант с отдельной точкой доступа на каждом АРМе является более отказоустойчивым.
В качестве наглядного примера рассмотрим конфигурирование двух типов АРМов с разными данными и разрешениями:
Рабочее место для диспетчера (Workstation_Dispatchers).
В AccessPoint будет транслироваться всё дерево сигналов сервера и полный доступ - мониторинг и управление (возможность изменения сигналов, отправка команд).
Рабочее место для оператора (Workstation_Operators).
В AccessPoint будет транслироваться только отдельная ветка сигналов сервера. Также будет ограниченный доступ - отправка команд запрещена, только мониторинг.
Рассматриваемый далее пример настройки выполняется на версиях компонентов Альфа платформы по Bundle 24.9.3; Alpha.DevStudio 3.27.7.
Описание рабочего места - клиентского компьютера в DevStudio.
Настройка и создание привязок.
Рассмотрим на примере простого демо проекта. Один узел Alpha.Domain, он же центральный узел сети Alpha.Domain и PLC.
На узле развернут Alpha.Server. В приложении сервера дерево объектов и сигналов - root, в котором имеются ветки Valves и Sensors.
Для начала настроим тип рабочего места для диспетчера.
Из панели элементов добавим в домен элемент «Тип рабочего места».
Укажем имя «Workstation_Dispatchers».
В свойстве «Конфигурации» укажем путь для кэша конфигураций Alpha.AccessPoint. В случае с Windows можно оставить по умолчанию. Перейдем внутрь Workstation_Dispatchers.
Обратите внимание на элемент «Клиентский EthernetAdapter» - у него нет возможности указать IP-адрес. Здесь указывается только принадлежность к сети.
Конкретный IP-адрес в клиентском EthernetAdapter не указывается, так как на уровне проекта в Alpha.DevStudio мы конфигурируем сам тип (шаблон) рабочего места. Тип рабочего места в Alpha.DevStudio можно описать 1 раз, а конкретных рабочих мест, относящихся к данному типу, может быть сколько угодно.
Все конкретные машины - АРМы указываются в конфигурационных файлах alpha.net.agent.xml и alpha.domain.agent.xml подсистемы Alpha.Domain. Там будут перечислены имена АРМов, их IP-адреса и порты.
Далее из панели элементов добавим Alpha.AccessPoint.
В свойстве «Имя службы» по умолчанию указано наименование службы для ОС Windows –«Alpha.AccessPoint». Если АРМ работает на ОС Linux, укажите «alpha.accesspoint.service».
Само свойство «Имя службы» у компонента может быть абсолютно любым.
Оно задается для корректной автоматической генерации файла alpha.domain.agent.xml. (При построении решения Alpha.DevStudio генерирует файлы alpha.domain.agent.xml для каждого узла в папках проекта.)
Главное, чтобы служба в итоге была правильно указана в основном конфигурационном файле alpha.domain.agent.xml, расположенном в директории установки на АРМе.
C:\Program Files\Automiq\Alpha.Domain – в ОС Windows;
/opt/Automiq/Alpha.Domain – в ОС Linux.
В AccessPoint по умолчанию уже имеются модули:
«HUB Module» - он необходим для соединения с удаленными исполняющими компонентами, источниками данных по проприетарному TCP-протоколу Alpha.Link.
«OPC AE Сервер» - для передачи сгенерированных событий.
«TcpServer» - для предоставления данных клиентам по проприетарному TCP-протоколу Alpha.Link. В нашем случае для проекта Alpha.HMI.
Для доступа к истории из проекта Alpha.HMI не забудьте указать в свойствах порт доступа к истории, например 4950. (По умолчанию он не указан.)
Для того чтобы Alpha.AccessPoint мог получать исторические данные, добавим «History Module» (раздел «Служебные модули»). Но базы добавлять не нужно. О базах, с которыми нужно будет связываться, Alpha.AccessPoint узнает после подключения к источнику -Alpha.Server-у.
Также, чтобы иметь возможность подключаться к Alpha.AccessPoint по OPC UA (например, через OpcExplorer), добавим модуль «OPC UA Сервер»
В свойствах указываем имя точки подключения. Все порты можем оставить по умолчанию.
В случае если машина используется не только как клиентский АРМ (например, развернут еще и Alpha.Server), во избежание конфликта по портам укажите любые другие свободные порты.
Для описания дерева объектов и параметров в AccessPoint из панели элементов добавим элемент "Приложение".
Далее для того чтобы указать источник данных для AccessPoint и какие именно данные он будет получать, необходимо создать привязку.
Привязка – это ссылка в Alpha.AccessPoint, которая указывает на объект или приложение, размещённое в Alpha.Server. В процессе работы Alpha.AccessPoint привязка динамически раскрывается: в дереве сигналов Alpha.AccessPoint создаётся папка, в которой создаётся копия дерева сигналов объекта или приложения, на которое указывает привязка. При изменении значений сигналов в Alpha.Server, новые значения автоматически передаются и записываются в соответствующие сигналы в Alpha.AccessPoint.
Документация:
Alpha.DevStudio 4.2 > Руководство пользователя > Разработка проекта > Описание домена > Добавление компонентов домена > Добавление Alpha.AccessPoint
Alpha.DevStudio 4.2 > Руководство пользователя > Разработка проекта > Alpha.AccessPoint: создание привязок
В данном случае мы описываем рабочее место для диспетчера и хотим предоставить ему всё дерево объектов и сигналов сервера. Для этого создадим в приложении AccessPoint ссылку на корневую папку (root) с нашего Alpha.Server-а.
Создать ссылку сразу на конкретный элемент можно, вытянув соответствующий объект из обозревателя решений.
И для того, чтобы Alpha.AccessPoint по этой ссылке мог динамически раскрывать и просматривать всё дерево объектов и сигналов Alpha.Server-а, обязательно для данной ссылки добавляем атрибут «Раскрывать ссылку динамически».
Om.Server → Attributes → Раскрывать ссылку динамически.
В данном примере нет резервного Alpha.Server-а. Но даже при наличии узла с резервным Alpha.Server-ом принцип не меняется! В Alpha.AccessPoint динамическая ссылка создается только на объекты (или приложение) основного сервера. И если у него есть резервный исполняющий компонент (резервный Alpha.Server) - Alpha.AccessPoint уже будет знать о его наличии и сможет с ним работать.
На этом описание типа рабочего места для диспетчера со стороны проекта в Alpha.DevStudio закончено.
Описание типа рабочего места для оператора.
Тип рабочего места для оператора в нашем случае отличается, по сути, только набором транслируемых сигналов с сервера и запретом на изменение сигналов.
Поэтому необходимо повторить весь вышеописанный алгоритм создания типа рабочего места до момента создания динамической ссылки
Но чтобы этого не делать, мы можем просто скопировать уже сконфигурированный тип рабочего места и отредактировать некоторые моменты.
Скопируем тип рабочего места «Workstation_Dispatchers» и назовем «Workstation_Operators».
Отредактируем имя точки подключения для OPC UA сервера. Назовем «UA_AccessPoint_Operators».
В приложении удалим ссылку на ветку «root» и создадим новую ссылку на ветку сервера «Sensors». АРМ оператора будет видеть сигналы только данной ветки сервера.
И не забываем задать ссылке атрибут «Раскрывать ссылку динамически».
А для того, чтобы ограничить данный АРМ только мониторингом, то есть запретить изменение сигналов и отправку каких-либо команд, в HUB-модуле свойству «Разрешено изменять значение сигналов» укажем значение - «нет».
На этом описание типов рабочего места для диспетчера и оператора со стороны проекта в Alpha.DevStudio закончено. Перейдем к конфигурированию АРМов в домене.
Конфигурирование клиентских компьютеров в подсистеме Alpha.Domain.
Настройка со стороны центрального узла домена.
Здесь мы не будем рассматривать полноценное конфигурирование файлов центрального узла домена, а рассмотрим только ту часть, где в конфигурационных файлах описываются АРМы.
Подробное описание представлено в документации:
Alpha.Domain 1.5 > Принципы настройки подсистемы > Конфигурирование центрального узла сети Alpha.Net в домене.
Конфигурирование Net-агента на центральном узле.
Чтобы сконфигурировать службу, откроем файл alpha.net.agent.xml, расположенный в папке установки:
C:\Program Files\Automiq\Alpha.Domain – для ОС Windows;
/opt/Automiq/Alpha.Domain – для ОС Linux.
Здесь в xml-элементе <ChildAgents> необходимо описать все дочерние узлы домена.
В файле можно создать только один xml-элемент <ChildAgents>.
В самом xml-элементе <ChildAgents> может быть сколько угодно xml-элементов <ChildAgent>, в которых описываются конкретные машины.
В закомментированных примерах есть два образца записи:
С возможностью перечислить резервные каналы связи - с открытием и закрытием xml-элемента <ChildAgent>;
Запись в одну строку в одиночном xml-элементе <ChildAgent/>.
Прописываем необходимые параметры:
Атрибут Name — это имя дочернего агента, уникальное среди всех ChildAgent'ов (не должно содержать символы: '.' и '\').
На уровне проекта в Alpha.DevStudio мы конфигурировали сам тип рабочего места и не указывали конкретные машины и имена АРМов, поэтому на данном этапе мы придумываем и задаем имена всех АРМов в атрибутах Name.
В дальнейшем эти имена пропишем в конфигурационных файлах самих АРМов.
Атрибут Port — номер порта дочернего агента для связи с центральным узлом. Значение по умолчанию — «1010».
Атрибут Port должен соответствовать порту атрибута ParentAgentPort xml-элемента <Alpha.Net.Agent> в конфигурации Net-агента на АРМе.
Атрибут Address — IP-адрес дочернего узла (АРМа).
<ChildAgents>
<ChildAgent Name="ARM1_Dispatcher" Port="1020" Address="192.168.110.11"/>
<ChildAgent Name="ARM2_Operator" Port="1020" Address="192.168.110.21"/>
</ChildAgents>Зададим имена АРМам: "ARM1_Dispatcher" и "ARM2_Operator".
Укажем порты - 1020, и IP-адреса дочерних узлов.
Сохраним файл и перезапустим службу Alpha.Net.Agent, чтобы применить внесённые изменения. (На ОС Linux - сервис alpha.net.service.)
Не забывайте всегда после редактирования конфигурационных файлов сохранять его и перезапускать соответствующую службу, иначе изменения не применятся.
Конфигурирование Domain-агента на центральном узле.
Откроем файл alpha.domain.agent.xml, расположенный в папке установки:
C:\Program Files\Automiq\Alpha.Domain – для ОС Windows;
/opt/Automiq/Alpha.Domain – для ОС Linux.
Так как это конфигурация alpha.domain.agent центрального узла, помимо основных настроек, здесь необходимо также связать описанные в проекте типы рабочих мест с конкретными машинами (АРМ-ами), которые мы перечислили ранее в alpha.net.agent.xml.
Все описание выполняется внутри xml-элемента <Domain>.
Внутри созданного xml-элемента <WorkstationRoles> перечисляются все типы рабочих мест.
Каждый конкретный тип рабочего места указывается в отдельном xml-элементе <WorkstationRole> - имена, заданные в проекте DevStudio.
Далее в нем в xml-элементе <KnownWorkstations> перечисляются все АРМы, относящиеся к этому типу рабочего места, в отдельных xml-элементах <KnownWorkstation>.
(Имена АРМов, заданные в конфигурации alpha.net.agent.xml).
Атрибут Description (опциональный) — это описание, которое будет выводиться у АРМов в DevStudio в мастере развертывания.
Пример заполнения на скрине:
<Domain>
<WorkstationRoles>
<WorkstationRole Name="Workstation_Dispatchers">
<KnownWorkstations>
<KnownWorkstation AlphaNetPath="ARM1_Dispatcher" Description="Точка доступа для диспетчера на АРМ1 - полный доступ"/>
</KnownWorkstations>
</WorkstationRole>
<WorkstationRole Name="Workstation_Operators">
<KnownWorkstations>
<KnownWorkstation AlphaNetPath="ARM2_Operator" Description="Точка доступа для оператора на АРМ2 - ограниченный доступ, только мониторинг"/>
</KnownWorkstations>
</WorkstationRole>
</WorkstationRoles>
</Domain>Сохраним файл и перезапустим службу Alpha.Domain.Agent, чтобы применить внесённые изменения. (На ОС Linux – сервис alpha.domain.service)
Конфигурирование клиентских компьютеров в домене.
Конфигурирование Net-агентов клиентских машин.
Откроем файл alpha.net.agent.xml на АРМе диспетчера.
Здесь необходимо в атрибуте Name указать соответствующее имя АРМа – «ARM1_Dispatcher».
И в атрибуте ParentAgentPort (номер порта для соединения с родительским агентом) прописать тот же порт, который мы указывали в файле alpha.net.agent.xml на центральном узле -1020.
По аналогии отредактируем файл alpha.net.agent.xml на АРМе оператора:
Сохраним и перезапустим службы Alpha.Net.Agent, чтобы применить внесённые изменения. (На ОС Linux - сервис alpha.net.service.)
Конфигурирование Domain-агентов клиентских машин.
Для конфигурирования Domain-агентов клиентских машин мы можем воспользоваться файлами, которые генерирует Alpha.DevStudio для каждого узла при построении решения.
Выполним построение решения в Alpha.DevStudio и перейдем в директорию проекта:
Demo_DevStudio\DemoDev\bin\локальная\Domain
Здесь в папках для каждого узла генерируется файл alpha.domain.agent.xml, содержащий его конфигурацию из проекта Alpha.DevStudio.
Скопируем данный файл на соответствующий АРМ и отредактируем некоторые параметры.
Атрибут Name в xml-элементе <Alpha.Domain.Agent> можем удалить, в нем нет необходимости.
По сути, здесь нам нужно указать:
Имя конкретного АРМа в атрибуте Name в xml-элементе <EntryPointNetAgent>.
В атрибуте Address можем указать IP-адрес конкретного адаптера или оставить Localhost.
Так как это файл для АРМа диспетчера, атрибут Name в xml-элементе <WorkstationRole> указан верно - «Workstation_Dispatchers».
Остальные атрибуты сгенерированы верно.
Пример с пояснениями на скрине:
Далее скопируем на АРМ оператора сгенерированный (для АРМа оператора) файл alpha.domain.agent.xml и отредактируем по аналогии:
Не забываем перезапускать службы Alpha.Domain.Agent на АРМах, чтобы применить внесённые изменения. (На ОС Linux - сервис alpha.domain.service)
На этом конфигурирование клиентских компьютеров в подсистеме Alpha.Domain закончено.
Вернемся на инженерную станцию в Alpha.DevStudio, построим решение и применим конфигурацию ко всем узлам.
Если конфигурационные файлы настроены правильно, в мастере развертывания будут отображаться все настроенные АРМы (с заданными описаниями) и конфигурации успешно применятся.
Также в мастере развертывания будут отображаться динамические станции, по сути это описанные в проекте типы рабочих мест - на них проливать конфигурацию не обязательно.
Для проверки результата можем открыть приложение OpcExplorer и подключится к АРМам (к Alpha.AccessPoint) по протоколу OPC UA.
В итоге:
При подключении к АРМу диспетчера нам доступно все дерево сигналов сервера - корневая папка root и все ее содержимое. И мы можем изменять сигналы - отправлять команды.
При подключении к АРМу оператора нам доступна только ветка Sensors и ее содержимое. И работает ограничение - отправлять команды мы не можем, только мониторинг.
Если кратко, то процесс конфигурирования АРМа в домене может быть сведен к следующим ключевым аспектам:
Alpha.AccessPoint устанавливается на каждом АРМе.
Создается, настраивается тип рабочего места в проекте Alpha.DevStudio и строится решение.
Настраивается подсистема Alpha.Domain (файлы alpha.net.agent.xml и alpha.domain.agent.xml ) со стороны центрального узла домена.
Настраивается подсистема Alpha.Domain (файлы alpha.net.agent.xml и alpha.domain.agent.xml ) со стороны клиентского узла.
Разворачивание обновленной конфигурации на целевые АРМы
Сам проект HMI переносится (копируется) на АРМы и настраивается на работу с локальным Alpha.AccessPoint, т. е. указываются соответствующий хост и порты.
В дальнейшем проект HMI можно удаленно обновлять, в том числе без перезапуска. Для этого используется компонент «Менеджер проекта».
Документация:
Alpha.HMI 2.0 > Руководство пользователя > Основные этапы работы с проектом > Обновление проекта без перезапуска.