Реализация резервирования баз SCADA системы на 2-ух АРМ

[SokolovSS]

Добрый день.

Возникла необходимость в создании резервирования SCADA системы на двух АРМ.

Имеется два промышленных компьютера, которые будут использовать в качестве серверов. Через Коммутатор они подключены к ПЛК Siemens s7-300.
Идея в том чтобы создать надёжную, резервированную систему с продукцией InTouch на АРМ. Должна вестись база данных на АРМ и 1 и 2. Требуется их синхронизировать между собой, чтобы в случае отказа одного АРМ, работа переходила на второй достаточно быстро.

[Генератор зла]

Должна вестись база данных на АРМ и 1 и 2

А о какой базе идёт речь

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

Дык... Поставьте 2 АРМ-а, и они будут работать спокойно. От каком переключении речь то ???

[SokolovSS]

Уточнюсь, база имеется ввиду все архивные, исторические данные (тренды, алармы).
Прошу прощения за неточное описание.
При таком варианте построения каждый АРМ будет отправлять одни и те же запросы, т.е. со стороны контроллера: к нему будет приходить два запроса на одно и тоже, следовательно отправлять он будет два ответа(На одну скаду и на другую). Требуется избежать "двойного запроса". Это первое.
Второе: Если по какой-то причине один из АРМов вышел из строя, после замены его на новый, идентичный АРМ, нужно восстановить на нем все исторические данные.

Читая форумы я обнаружил, что базу алармов синхронизировать между АРМ можно, с помощью Alarm Hot Backup Manager. Можно ли восстановить тренды, с помощью какой-нибудь подобной штуки?

[skom]

При таком варианте построения каждый АРМ будет отправлять одни и те же запросы, т.е. со стороны контроллера: к нему будет приходить два запроса на одно и тоже, следовательно отправлять он будет два ответа(На одну скаду и на другую). Требуется избежать "двойного запроса". Это первое.

А чем вызвана такая необходимость? Очень медленная сеть?
Даже если так, то поставив два идентичных АРМ, можно выделить один из них как главный (сервер IO установлен на обоих), и 2-й АРМ будет использоваться сервер ввода/вывода 1-го АРМ, при необходимости InTouch произведёт переключение.

Второе: Если по какой-то причине один из АРМов вышел из строя, после замены его на новый, идентичный АРМ, нужно восстановить на нем все исторические данные.

Если вы поставите 2 идентичных АРМ, сделаете синхронизацию времени, то каждый будет писать одинаковую информацию в свою базу. И при выходе АРМ и строя, можно будет восстановить, используя данные работоспособного компьютера. Для синхронизации базы алармов решений нет (если я правильно помню), Alarm Hot Backup — это про переключение источника событий для журнала в интаче.

[Генератор зла]

Для синхронизации базы алармов решений нет (если я правильно помню), Alarm Hot Backup — это про переключение источника событий для журнала в интаче.

Ересь. И где Вы берёте такие дикие идеи?

базу алармов синхронизировать между АРМ можно, с помощью Alarm Hot Backup Manager

Угу, можно. Только для этого нужен 3-й компьютер, на котором и будет располагаться сама БД алармов (с утилитой Alarm DB Logger)
На этом же компьютере рекомендуется расположить сервер в/в (для Siemens), а сами InTouch взять по лицензиям без в/в - тогда и запросы к контроллеру не будут дублироваться (хотя Siemens к этому вполне устойчив).

Для резервирования истории (трендов) - каждый из АРМ-ов на 3-й комп пишет свои тренды (в свою дирректорию). А просматривать можно либо ту, либо другую, переключаясь с помощью набора встроенных ф-ций HTxxxxx в каждом из проектов (АРМ).

Если вы поставите 2 идентичных АРМ, сделаете синхронизацию времени, то каждый будет писать одинаковую информацию в свою базу.

Ещё раз ересь. Синхронизация времени не гарантирует синхронизации работы проекта каждого из АРМ. Т.е. алармы и тренды будут писаться в разные (хотя и близкие друг к другу) моменты времени. Соответственно, и значения параметров в эти моменты могут отличаться, хоть и не значительно.

[skom]

Ересь. И где Вы берёте такие дикие идеи?

Т.е. Alarm Hot Backup Manager позволяет синхронизировать именно базы данных на нескольких компьютерах? Т.е. реплицировать их?

Ещё раз ересь. Синхронизация времени не гарантирует синхронизации работы проекта каждого из АРМ. Т.е. алармы и тренды будут писаться в разные (хотя и близкие друг к другу) моменты времени. Соответственно, и значения параметров в эти моменты могут отличаться, хоть и не значительно.

Я это и имел в виду, тут зависит от самого реального времени производства. Если расхождение в десятки миллисекунд критично, то тогда это не подходит.

[Генератор зла]

Т.е. Alarm Hot Backup Manager позволяет синхронизировать именно базы данных на нескольких компьютерах? Т.е. реплицировать их?

Это позволяет вести единую БД алармов. Т.к. активным всегда является лишь один из пары. Пара, а не несколько компьютеров. Третий, как в сексе - лишний.

Если расхождение в десятки миллисекунд критично, то тогда это не подходит.

А в несколько секунд?

[skom]

Это позволяет вести единую БД алармов. Т.к. активным всегда является лишь один из пары. Пара, а не несколько компьютеров. Третий, как в сексе - лишний.

Так это же противоречит условия задачи. Нужно резервирование. Alarm Hot Baсkup этому никак не способствует.

А в несколько секунд?

Современные решения для синхронизации времени позволяют держать расхождения во времени в пределах десятков миллисекунд. Насколько это критично, решать не мне.

[Генератор зла]

Так это же противоречит условия задачи. Нужно резервирование. Alarm Hot Baсkup этому никак не способствует.

Не так уж и противоречит. Поскольку является штатным решением для пары АРМ-ов c InTouch. И никто не мешает в качестве 3-го компьютера выбрать сервер, у которого наработка на отказ и надёжность повыше, чем у АРМ-ов.

Современные решения для синхронизации времени позволяют держать расхождения во времени в пределах десятков миллисекунд. Насколько это критично, решать не мне.

Моя фраза о нескольких секундах касалась расхождения в работе проектов InTouch. Один сгенерирует аларм в 18:34:12.123, другой - в 18:37:41.456 при одинаковом системном времени.

Насколько это критично, решать не мне.

[skom]

Один сгенерирует аларм в 18:34:12.123, другой - в 18:37:41.456 при одинаковом системном времени.

Это почему? Если на каждом АРМ будет стоять сервер ввода/вывода, опрашивающий контроллер напрямую?

[Генератор зла]

Это почему? Если на каждом АРМ будет стоять сервер ввода/вывода, опрашивающий контроллер напрямую?

Рука-лицо!!!
Кто засинхронизирует работу самих серверов в/в и InTouch, расположенных на разных компьютерах? Если первый InTouch опрашивает теги с M по Z, то другой генерирует алармы для тегов с A по L. А когда первый обновляет данные на экране, второй пишет данные в файлы трендов.
Это я не беру в расчёт что за каждом из компьютеров сидит воинствующий "чайник" и жмякает мышой куда попало, а за всем этим с ухмылкой наблюдает Каспер и усиленно тормозит.
Вы не можете заставить работать 2 InTouch синхронно до миллисекунд! До секунд (десятков секунд) - да.

[Генератор зла]

В качестве наглядного примера могу привести работу АВР для электроустановок.
2 фидера. Работает только один.
На одном фидере напряжения по фазам = 225, 224, 226 В, частота 51 Гц, косинус фи = 0.78
На втором - напряжения по фазам = 222, 219, 220 В, частота 49 Гц, косинус фи = 0.83
Но при исчезновении одной из фаз активного фидера произойдёт переключение и электропотребители продолжат работать.
Никому же не приходит в голову синхронизировать эти два фидера.

И вообще, ни одна из скад, работающих под управлением ОС Microsoft Windows, не будет работать синхронно с аналогичной до миллисекунд. По одной простой причине - ОС Microsoft не являются операционками реального времени и скады в них - вторичные процессы, а не часть ядра.
Чтобы синхронизация была на уровне миллисекунд придётся использовать продукты на основе QNX

[skom]

Это почему? Если на каждом АРМ будет стоять сервер ввода/вывода, опрашивающий контроллер напрямую?

Рука-лицо!!!
Кто засинхронизирует работу самих серверов в/в и InTouch, расположенных на разных компьютерах? Если первый InTouch опрашивает теги с M по Z, то другой генерирует алармы для тегов с A по L. А когда первый обновляет данные на экране, второй пишет данные в файлы трендов.
Это я не беру в расчёт что за каждом из компьютеров сидит воинствующий "чайник" и жмякает мышой куда попало, а за всем этим с ухмылкой наблюдает Каспер и усиленно тормозит.
Вы не можете заставить работать 2 InTouch синхронно до миллисекунд! До секунд (десятков секунд) - да.

Вы наверное меня не так поняли, я предлагал 2 идентичных АРМ. Т.е. каждый опрашивает контроллер (все теги), проекты идентичны, каждый генерирует все алармы, пишет в их БД (каждый в свою), в локальную папку тренды (если используется итнтач, а не хисториан), плюс они синхронизируются в пределах секунды отставания (чтобы избежать разницы во времени в журналах и отчётах). Для небольших проектов эта схема подойдёт, сам такое решение использовал не раз.

[Генератор зла]

Ваше решение ничем не отличается от просто 2 АРМ-ов. А синхронизация времени происходит аутоматически в любом домене по времени DC.
Но обычно проблема не только и не столько в резервировании/синхронизации. А в единых/надёжных/устойчивых/достоверных данных. Какую из БД алармов Вы примете за истинную при разборе полётов аварии, которая принесла большие убытки? Повторю, метки времени алармов в этих БД будут разными. Более того, последовательность записей в каждой БД будет разная
Поэтому и есть Hot Backup Manager.