Проблема редундантности DCS

Можно сказать так: у всех резервных контроллеров есть индикатор состояния, предназначенный специально для указания на то, является ли текущий CPU основным или резервным. Вам следует сосредоточиться на том, как при переключении между основным и резервным узлами обеспечить синхронизацию данных без их потери, чтобы это не повлияло на всю систему.

Нормальное рабочее состояние — это когда один модуль работает, а другой находится в резервном режиме; это можно увидеть по индикаторным огням на модулях. Если процессор, работающий в данный момент, выходит из строя, работа переключается на резервный модуль. В повседневной работе также возможно переключение контроллера с одного сервера на другой. Если есть ещё вопросы, можете продолжать спрашивать

Я именно это и имею в виду! Передаётся ли основная карта данными на резервную в каждом цикле вычислений? Иначе как обеспечить согласованность данных при переключении?

Последнее изменение в этом посте было сделано пользователем humker 21.02.2016 в 15:15. У разных систем DCS механизмы в основном одинаковы, но есть и некоторые отличия. Оба контроллера одновременно получают данные с шины IO в реальном времени; только основной контроллер может отправлять команды. Во время переключения между основным и резервным контроллерами большинство команд не выполняется, либо выполняется в специальной кэш-памяти. У каждого контроллера есть общая кэш-область; обычно эта область не активна, но она используется во время переключения контроллеров для обеспечения продолжительной работы системы DCS. Она играет важную роль при жестком переключении (или ручном переключении). Возникает вопрос: что произойдет, если основной контроллер внезапно выйдет из строя? В таком случае резервная кэш-область будет продолжать выполнять команды до тех пор, пока резервный контроллер не займет место основного. Если же осуществляется ручная смена основного и резервного контроллеров, то заранее поступает команда в кэш-область, согласно которой она должна в процессе смены взять на себя функции основного контроллера, пока резервный контроллер не будет готов к работе. Однако поскольку время переключения между основным и резервным узлами DCS составляет несколько миллисекунд, в большинстве случаев в процессе переключения контроллер прекращает выполнение команд output и прекращает логические вычисления. В конце концов, DCS — это не ESD, поэтому к его эффективности не предъявляются такие высокие требования. Если в течение нескольких миллисекунд или десятков миллисекунд происходит какое-то критическое событие, которое длится всего лишь несколько миллисекунд, то можно только винить собственную невезучесть.

Видите ли вы специальный кабель или оптоволоконный кабель между основным контроллером и резервным контроллером? Этот кабель служит для переключения между основным и резервным контроллерами; без него переключение невозможно. По сути, речь идет о сигналах вижндог у главного и резервного контроллеров. В нормальных условиях оба контроллера собирают входные данные. Когда сигнал вижндог главного контроллера поступает, в работу входит резервный контроллер, а выходные сигналы переключаются от главного контроллера к резервному

В системах DCS резервирование процессоров обычно осуществляется по принципу «один рабочий, один резервный». При сбое основной карты происходит автоматический переход на работу резервной карты. Этот переход является импульсным, но для его осуществления необходимо определенное время. Если время переключения не выбрано правильно, это может привести к остановке работы системы.

Переключение занимает время! Кто же занимался решением этих вопросов в то время? Время переключения — это всё равно промежуток паузы

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

Два CPU: один основной, другой резервный. Различать с помощью индикаторных ламп. В реальной работе оба CPU выполняют вычисления в соответствии с конфигурацией, однако финальный результат выводится только CPU, находящемся на управляющей стороне. Это эквивалентно ситуации, когда оба процессора выполняют одну и ту же работу. Процессор, находящийся в режиме резерва, не просто перестает работать — существует множество причин, по которым контрольный процессор может перейти в режим резерва: например, прерывается сетевое соединение контрольного процессора, возникает сбой в его аппаратном обеспечении и так далее. Что касается разницы в данных и времени при переключении, то её не существует. У всех производителей есть технологии для синхронизации, и это является их технической тайной; они не могут рассказать, с помощью каких методов их процессоры устраняют разницу в данных и времени. Они лишь скажут вам, что при смене процессора у нас нет перебоев, и это не повлияет на систему. Сейчас технологии резервирования процессоров уже широко распространены, и отечественные производители также справляются с этой задачей неплохо. Если есть подозрения, что при переключении возникают сбои в собственной системе, их можно отследить по тенденциям. Посмотрите, есть ли в выходных данных PID скачки и т. п.