Обычно резервированная система состоит из двух проектов на разных компьютерах с одинаковой оперативной системой. На этих двух системах, которые имеют резервированное сетевое соединение, работают одни и те же менеджеры. Резервирование чаще всего невидимо для менеджеров, и менеджеры действуют как в простой системе. В действительности поток данных и динамика проверяются и контролируются посредством системных сообщений менеджера данных.
В резервированной системе компоненты автономной системы могут контролироваться и могут быть оснащены взвешиванием, которое используется для расчета состояния ошибки в случае возникновения ошибок. К компонентам, которые контролируются и используются при расчете состояния ошибки, относятся: менеджеры, TCP-соединения, PLC-соединения, объем жесткого диска, оперативная память и т.д. Взвешивание — это номер от 0 до 999, который пользователь может специально назначить компонентам. Лицо, которое выполняет конфигурирование, принимает решение о том, насколько серьезной является ошибка, что означает, какой номер указывается для взвешивания. Отказу PLC-соединения задается более высокое взвешивание, чем отказу UI (пользовательского интерфейса). Обычно сумма взвешиваний, которая дает состояние ошибки, должна быть одинаковой на обоих компьютерах (оптимальным является состояние ошибки 0). В случае возникновения ошибок компьютер автоматически переключается. Это означает, что активный компьютер — это всегда компьютер с более низким уровнем состояния ошибки. Расчет ошибки выполняется в сценарии CTRL calculateState.ctl (этот сценарий находится в списке pvss_scripts ). Конфигурирование и взвешивание ошибки выполняются на панели обзора системы. Дополнительную информацию см. в разделе Панель обзора системы в резервированных системах.
Менеджер резервирования (WCCILredu) выполняет следующие важные функции в случае с резервированной системой (по умолчанию менеджер резервирования имеет номер 4776). Менеджер резервирования имеет следующие задачи:
- Состояние резервирования: Состояние резервирования (какой компьютер является активным, а какой компьютер является пассивным в данный момент времени) определяется и задается менеджером резервирования, поскольку он содержит всю информацию (состояния внутренней системы) о себе и своем партнере. Более того, менеджер резервирования управляет своими состояниями ошибок и состояниями ошибок своего партнера. Эти состояния сравниваются друг с другом, и компьютер с более низким уровнем состояния ошибки автоматически становится активным (менеджер событий переключает активное/пассивное состояние компьютеров).
- Обмен системной информацией и существующими сообщениями.
- Анализ отказов партнера.
На следующем рисунке принцип резервирования показан более понятно:
Рисунок: Резервирование в «КАСКАД Цифра»
На рисунке детально показаны оба компьютера «Сервер 1» и «Сервер 2»: мы уже знаем о них из рисунка на стр. Резервирование, основы. «Сервер 1» находится в режиме управления (активный), а «Сервер 2» — в режиме горячего резерва (пассивный).
В случае резервирования пользовательские интерфейсы (UI) рабочих терминалов соединяются с обоими менеджерами событий. Однако, на обоих UI отображаются только данные активной системы. Менеджер событий пассивной системы ограничен связью с менеджером событий активной системы для сопоставления данных процесса (он не передает никаких данных подсоединенным UI или отклоняет все сообщения драйверов). Это можно увидеть на рисунке с переключателем, находящемся на пользовательских интерфейсах или на пассивном менеджере событий.
Логика сообщений (сообщения и команды) показана на рисунках ниже:
Сообщение драйвера
Рисунок: Сообщения в направлении сообщений
Сообщения в направлении сообщений обрабатывается следующим образом:
- Оба драйвера получают сообщение от периферийного оборудования (это происходит не всегда, поскольку привод получает разные значения в различные моменты времени при конфигурировании опроса; это значит, что драйвер получает сообщение только на одном компьютере). В активной системе значение передается менеджеру событий, а пассивная система отклоняет сообщение.
- Менеджер событий в активной системе передает значение всем зарегистрированным менеджерам. Через резервированные сетевые соединения значение передается пассивному менеджеру событий. В пассивной системе значение снова передается всем менеджерам, зарегистрированным в менеджере событий.
- Значение передается пользовательским интерфейсам обоих рабочих терминалов только активным менеджером событий.
ПРИМЕЧАНИЕ
Такое же поведение также применяется для значений, которые передаются другими менеджерами (например, CTRL, API)!
Команда драйвера
Рисунок: Сообщения в направлении команд
Сообщения в направлении команд обрабатывается следующим образом:
- Значение изменяется на UI рабочего терминала 1. Изменение передается менеджеру событий активной системы. Пассивный менеджер событий не принимает никакие изменения от UI.
- Менеджер событий в активной системе передает значение всем зарегистрированным менеджерам. Через резервированное сетевое соединение значение передается пассивному менеджеру событий. В пассивной системе значение передается всем менеджерам, зарегистрированным в менеджере событий.
- Изменение значения передается периферийному оборудованию через драйвер в активной системе. Драйвер в пассивной системе отклоняет изменения значения и не передает никаких данных периферийному оборудованию.
ПРИМЕЧАНИЕ
Это поведение в направлении команд применяется только для драйвера!
Поскольку база данных является идентичной на обоих компьютерах, то на обоих компьютерах имеются одинаковые точки данных. Эти точки данных всегда имеют одинаковые значения и имена на обоих компьютерах. Это также относится к точкам данных, описанным выше (в направлении команд и сообщений). Поведение логики сообщений в направлении сообщений и команд уже было описано в предыдущих абзацах.
Кроме того, существуют элементы точек данных для внутренних состояний (например, пространство на диске, оперативная память, соединение с периферийным оборудованием и т.д.). . Информация об этих элементах точек данных может быть разной на двух компьютерах и должна быть известна на обоих компьютерах. При резервировании эта задача решается по-разному:
- Точки данных, содержащие информацию о внутренних состояниях, существуют в двух экземплярах с разными именами (один с постфиксом «_2», а второй без постфикса) на каждом компьютере.
- Левый компьютер несет ответственность за точку данных с постфиксом, а правый компьютер задает точку данных с постфиксом «_2». Если предположить, что драйвер Applicom теряет соединение с периферийным оборудованием, то элемент _apc_equipment.ConnState будет задан на левом компьютере в случае нормальной логики драйвера (левый компьютер является активным, а правый компьютер является пассивным). Если соединение будет потеряно на правом компьютере, он отклонит значение (поскольку он является пассивным), и точка данных «_2» не будет задана. Для того, чтобы данный тип поведения не возникал, существуют так называемые «передающие точки данных» («Forward DPs»). Передающие точки данных задаются и передаются другим компьютерам (такой передающей точкой данных является элемент точки данных _apc_equipment.ConnState). Таким образом, можно обеспечить постоянную доступность информации на обоих компьютерах.
- Однако, точка данных _apc_equipment состоит не только из элемента .ConnState, но и элементов, которые содержат конфигурации или команды инициирования (например, _apc_equipment.Board, _apc_equipment.Channel, _apc_equipment.Protocol и др.). Обычно значения этих элементов точек данных должны быть идентичными на левом и правом компьютерах. Для того, чтобы такие элементы точек данных были идентичными на обоих компьютерах, имеются так называемые «копирующие точки данных» («Copy DPs»). Копирующие точки данных копируют заданные значения в элементы точек данных обоих компьютеров. Так, если, например, элементу _apc_equipment.Channel задать значение «3», это значение также задается для элемента _apc_equipment_2.Channel.
Настройки относительно передающих и копирующих точек данных (особенно в случае специальных настроек проекта) выполняются в конфигурационном файле config.redu, находящемся в каталоге <<путь_проекта>>/config (см. также Конфигурационные файлы для резервирования).
ПРИМЕР: КОНФИГУРИРОВАНИЕ ДЛЯ ДРАЙВЕРА APPLICOM
- Откройте файл config.redu в каталоге <путь_КАСКАД>/config.
- Скопируйте в буфер раздел для настроек драйвера Applicom:
[event]
#copyDpType = «_Apc_Equ.Protocol»
#copyDpType = «_Apc_Equ.GeneralQuery»
#copyDpType = «_Apc_Equ.Active»
#copyDpType = «_Apc_Equ.InternalPollList»
#copyDpType = «_Apc_Equ.Board»
#copyDpType = «_Apc_Equ.Channel»
#copyDpType = «_Apc_Equ.ChannelEqNum»
#copyDpType = «_Apc_Equ.ReduConn.Board»
#copyDpType = «_Apc_Equ.ReduConn.Channel»
#copyDpType = «_Apc_Equ.ReduConn.ChannelEqNum»
#copyDpType = «_Apc_Equ.ReduConn.Active»
#copyDpType = «_Apc_Equ.ReduEqu.Board»
#copyDpType = «_Apc_Equ.ReduEqu.Channel»
#copyDpType = «_Apc_Equ.ReduEqu.ChannelEqNum»
#copyDpType = «_Apc_Equ.ReduEqu.Active»
#copyDpType = «_Apc_Equ.ReduEqu.ReduConn.Board»
#copyDpType = «_Apc_Equ.ReduEqu.ReduConn.Channel»
#copyDpType = «_Apc_Equ.ReduEqu.ReduConn.ChannelEqNum»
#copyDpType = «_Apc_Equ.ReduEqu.ReduConn.Active»
#copyDpType = «_Apc_Equ.ReduControl.Equ.SpsTag»
#copyDpType = «_Apc_Equ.ReduControl.Equ.MonMode»
#copyDpType = «_Apc_Equ.ReduControl.Equ.CmdMode»
#copyDpType = «_Apc_Equ.ReduControl.Equ.Switch»
#copyDpType = «_Apc_Equ.ReduControl.Conn.SpsTag»
#copyDpType = «_Apc_Equ.ReduControl.Conn.MonMode»
#copyDpType = «_Apc_Equ.ReduControl.Conn.CmdMode»
#copyDpType = «_Apc_Equ.ReduControl.Conn.Switch»
- Создайте новый файл с именем config.redu в каталоге <путь_проекта>/config.
- Добавьте из буфера раздел для настроек драйвера Applicom в только что созданный файл.
- Отрегулируйте настройки в этом файле в соответствии со своим проектом. Удалите символы комментария перед «copyDpType».
- Также имеется элемент, который может быть разным на двух компьютерах, над копирующими точками данных. Поэтому этот элемент также конфигурируется в качестве передающей точки данных:
fwdDpType = «_Apc_Equ.»
ПРИМЕЧАНИЕ
Этот элемент не должен изменяться в файле config.redu!
С помощью ключевого слова «fwdDpType» (подобно fwdDp) все изменения для данного элемента точки данных автоматически передаются от менеджера событий резервированному менеджеру событий. В отличие от «wdDp» указывается не элемент точки данных существующей точки данных, а элемент типа точки данных в форме «Type.Element» (например, «ExampleDP_Bit.» для корневого элемента типа точки данных «ExampleDp_Bit»). Таким образом, передаются соответствующие элементы всех точек данных этого типа.
Разделенный режим при резервировании
Разделенный режим в резервированных системах — это разделение обоих резервных серверов, при этом один сервер остается активным. Второй сервер может использоваться для тестирования новых конфигураций и конфигурирований. Преимущество состоит в том, что это может осуществляться во время выполнения программы на установке без какого-либо негативного влияния на активную систему.
Используя разделенный режим, можно свободно выбрать, какая система остается активной (переключая пользовательские интерфейсы на данную систему), а какая система используется для тестирования. После завершения тестирования система возвращается в режим резервирования на основе системы. Это значит, что, если тестирование было успешным, система синхронизируется с системой управления, когда система возвращается в режим резервирования, и новая конфигурация используется на обеих системах. Если старая система должна остаться резервированной, тестовая система синхронизируется в системой управления, и резервирование работает с настройками, которые существовали до переключения на разделенный режим.
Подробную информацию по разделенному режиму см. в разделах Обзор системы в резервированных системах и Резервирование в разделенном режиме.
Поведение резервирования пассивного события
Поведение резервирования, которое используется начиная с версии»КАСКАД Цифра» 3.5, служит для того, чтобы изменения значений на пассивном событии не отклонялись до тех пор, пока не будет уверенности в том, что активное событие обработало/передало их.
Поведение до версии 3.5
Благоприятный случай:
Отметка времени Менеджер событий (1|2) Описание
———————————————————————————————————————————————————
10:00:00 Событие 1 (активное) Получает изменение значения 1
10:00:01 Событие 2 (пассивное) Получает изменение значения 1
10:00:02 Событие 2 (пассивное) Отклоняет изменение значения 1
10:00:03 Событие 1 (активное) Обрабатывает изменение значения 1 и передает его событию 2
Критический случай— Отказ активного события — потеря данных:
Отметка времени Менеджер событий (1|2) Описание
———————————————————————————————————————————————————
10:30:00 Событие 1 (активное) Получает изменение значения 2
10:30:01 Событие 2 (пассивное) Получает изменение значения 2
10:30:02 Событие 2 (пассивное) Отклоняет изменение значения 2
10:30:03 Событие 1 (активное) Отказ -> нет передачи событию 2!
Поведение после версии 3.5
Благоприятный случай:
Отметка времени Менеджер событий (1|2) Описание
———————————————————————————————————————————————————
10:00:00 Событие 1 (активное) Получает изменение значения 1
10:00:01 Событие 2 (пассивное) Получает изменение значения 1
10:00:02 Событие 2 (пассивное) Игнорирует изменение значения 1 <- <-=»» NEW (НОВЫЙ)
10:00:03 Событие 1 (активное) Обрабатывает изменение значения 1 и передает его событию 2
10:00:22 Событие 2 (пассивное) Отклоняет изменение значения 1
Критический случай — Отказ активного события:
Отметка времени Менеджер событий (1|2) Описание
———————————————————————————————————————————————————
10:30:00 Событие 1 (активное) Получает изменение значения 2
10:30:01 Событие 2 (пассивное) Получает изменение значения 2
10:30:02 Событие 2 (пассивное) Игнорирует изменение значения 2 <- <-=»» NEW (НОВЫЙ)
10:30:03 Событие 1 (активное) Отказ -> нет передачи событию 2!
10:30:13 Событие 2 (пассивное) Обнаруживает отказ активного события и обрабатывает
все изменения значения, которые еще не были обработаны
10:30:14 Событие 2 (теперь активное) Обрабатывает изменение значения 2
Принятие отправителя во внимание
Поскольку данное поведение резервирования должно использоваться только в случае отказа (поломка, разъединение и т.д.), отправитель изменения значения также принимается во внимание.
Коррекция времени в случае одного и того же отправителя
Если в процессе работы сохраняется изображение, на котором последнее изменение значения было отправлено драйвером 1 с отметкой времени 10:00:01, а обрабатываемое событием в настоящий момент изменение значения также было получено от драйвера 1, но с отметкой времени 10:00:00, то вместо данного поведения резервирования используется коррекция времени. Коррекция времени означает, что отметка времени будет скорректирована на <<последнее_изменение_значения>> + 1 миллисекунда (в данном случае 10:00:00 + 1 миллисекунда).
Разные отправители
Если в процессе работы сохраняется изображение, на котором последнее изменение значения было отправлено драйвером 2 с отметкой времени 10:00:01, а обрабатываемое событием в настоящий момент изменение значения также было получено от драйвера 1, но с отметкой времени 10:00:00, то событие обнаруживает, что был задействован переключатель резервирования, и отклоняет это последнее изменение значения.
Одновременные изменения значения и общий запрос
Одновременные изменения значения от разных драйверов (отправителей) будут отклоняться.
В случае общего запроса все значения, которые не были изменены, будут передаваться с одинаковыми отметками времени, что может привести к тому, что они будут отклоняться данным поведением резервирования. Поэтому данное поведение резервирования не будет использоваться в случае общего запроса.