Резервирование для OPC

Роберт МакИлврайд и Эндрю Томас, Cogent Real‐Time Systems Inc.

Как-то рано утром Мел Фарнсворт сидел за пультом управления конвейерной линией Hardy Automotive Parts, допивая последнюю перед окончанием смены чашку кофе. Наблюдая за графиком индикатора линии, он заметил, что показатели результативности и эффективности Линии 3 упали до нуля. Он выглянул из окна аппаратной, казалось, что Линия 3 работает исправно. В чем же тогда проблема?

Линия нормально двигалась, но Мел не получал необходимых ему данных. Где-то между PLC и его дисплеем HMI была нарушена связь. Возможно, проблема была в полевой шине или плохом сетевом соединении. Может быть, это было вызвано сбоем OPC сервера или даже системы HMI. Какова бы ни была причина, поскольку подключение Мела к данным было единой цепью, единственное нарушение в цепи значило, что он свои данные не получает. Чтобы минимизировать такого рода риск и гарантировать максимально возможную доступность, системы непрерывного доступа к данным часто прибегают к резервированию.

Что такое резервирование?

Резервирование в системах управления процессами значит, что вся система или ее часть дублируется, иными словами, имеет резервную копию. Цель — исключить, насколько это возможно, любую единую точку отказа. Когда выходит из строя элемент оборудования или линия связи, похожий или идентичный компонент готов начать работу. Есть три типа систем резервирования, классифицированных по тому, насколько быстро осуществляется замещение (или включение резерва). Это системы «холодного», «теплого» и «горячего» резервирования.

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

«Теплое» резервирование имеет меньшее время ответа, поскольку дублирующая (резервная) система всегда работает и регулярно получает последнюю копию набора данных. Когда происходит отказ основной системы, система резервирования может произвести отключение от неисправной системы и взамен подключить к дублирующей. Это позволяет системе довольно быстро восстановиться (обычно в течение секунд) и продолжить работу. Некоторые данные будут потеряны в процессе отключенияпереподключения, но «теплое» резервирование вполне подходит в случаях, когда некоторая потеря данных допустима.

«Горячее» резервирование подразумевает, что основная и вспомогательная системы данных работают одновременно и обе предоставляют идентичные потоки данных нижестоящему клиенту. В основе лежит одна и та же физическая система, но каждая система данных использует отдельное аппаратное обеспечение, чтобы гарантировать отсутствие точек отказа (единой точки отказа). Когда основная система неисправна, предполагается, что переключение на вспомогательную систему произойдет плавно, «без происшествий», т. е. без потери данных. «Горячее» резервирование — лучший вариант для систем, в которых неприемлема потеря данных, свойственная «холодному» и «теплому» резервированию.

Типичная система резервирования OPC

Что из себя представляет резервирование в системе, основанной на OPC? Типичный сценарий включал бы два OPC сервера, подключенных к одному устройству или к одной PLC, либо, возможно, к дублирующим устройствам или нескольким PLC. Затем эти два OPC сервера подключались бы к какому-либо программному обеспечению, управляющему резервированием OPC, а этот менеджер резервирования в свою очередь обеспечивал бы одно подключение к клиенту OPC, такому как HMI. Менеджер резервирования отвечает за переключение на вторичный OPC сервер, когда возникает какая-либо проблема с данными, поступающими от основного OPC сервера. Этот сценарий создает резервный поток данных на всем пути от физической системы к HMI.

Рис. 1

Наиболее часто резервирование OPC применяется для OPC DA, но также возможно настроить резервные системы OPC A&E или OPC UA. Принципы те же. Иногда в больших системах необходимо настроить несколько резервных пар. Резервирование также можно настроить при работе по сети с помощью DCOM или туннелирования OPC. При сетевой настройке менеджер резервирования обычно располагается на машине OPC-клиента для минимизации числа возможных точек отказа.

Хотя «холодное» или «теплое» резервирование может иметь смысл при определенных обстоятельствах, обычно инженер или системный интегратор, внедряющий систему резервирования OPC, ищет «горячее» резервирование. Это самый подходящий тип резервирования для систем управления процессами и в то же время самый трудно достижимый. Давайте рассмотрим поближе первостепенную задачу менеджера резервирования OPC в системах «горячего» резервирования – переключение.

Переключение

Попросту говоря, менеджер «горячего» резервирования получает два идентичных входящих потока данных и отправляет один исходящий поток OPC клиенту. Задача менеджера резервирования при любых обстоятельствах определить наилучший из двух потоков и переключиться с одного на другой как можно скорее, когда бы не изменилось состояние. Переключение может быть инициировано несколькими различными видами событий:

• Изменение значения одной точки — на и от определенное значение, при достижении предельной величины и т. п.
• Изменение атрибута, одной точки — например, с “Good” на любой другой атрибут OPC.
• Мониторинг нескольких позиций — если атрибут или значение любой точки в группе ухудшается.
• Мониторинг быстроты изменений — если значения точек меняются медленнее, чем ожидалось.
• Обрывы сети и таймауты — проверяется посредством какого-либо механизма контроля импульса (heartbeat mechanism).

Как только произошло переключение, система или сам менеджер резервирования может включать возможность отправить аварийное сообщение или email, или даже запустить какую-либо программу диагностики или исследования. Он также может быть в состоянии регистрировать диагностическую информацию о состоянии основного OPC сервера или сетевого подключения. А в системе распознавания основного и вспомогательного входящих потоков часто предусмотрен инструмент, обеспечивающий предпочтение основного потока и переключение на него при первой возможности. Он иногда именуется fallback (возврат в исходный режим).

Практические рекомендации

Идея резервирования нетрудна для понимания, но её внедрение требует некоторых размышлений. Изначальное решение о «холодном», «теплом» или «горячем» резервировании отразится на всех аспектах внедрения. Выбор подходящего аппаратного и программного обеспечения критически важен для нормального функционирования системы. Надежная архитектура системы также важна, особенно при сетевом подключении. В дополнение к выбору OPC серверов и планированию сетевой инфраструктуры (в случае необходимости), важно будет решить, какое ПО использовать для управления резервированием. Хорошее ПО для управления резервированием должно быть простым в использовании и не требовать программирования. Технология должна быть современной и совместимой с последней версией Windows. Шанс потери данных при переключении должен быть снижен до абсолютного минимума, даже при работе по сети.

Ловушки таймеров

На практике достичь абсолютно плавного переключения во всех случаях невозможно, даже с системой «горячего» резервирования. Например, если ошибка сети произошла в рамках основного подключения, пройдет некоторое время, прежде чем менеджер резервирования обнаружит эту ошибку. Данные, переданные в этот период, не будут доставлены, но менеджер резервирования не сможет отличить стандартную паузу в потоке данных от паузы, связанной со сбоем в работе.

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

Применение таймеров для периодической проверки значений или атрибутов данных или опроса OPC серверов также сомнительно, поскольку таймеры привносят лишнее время ожидания в систему. В то время как ошибки сети должны обнаруживаться на основании временных показателей, изменение значения или атрибута данных может регистрироваться сразу, как только событие произошло. Обычно лучше избегать систем, базирующихся на регистрации изменения значения на основании временных показателей, а вместо этого использовать мониторинг объектов на основании событий.

Мониторинг объектов и соединения

Хороший менеджер резервирования должен включать и мониторинг объектов, и мониторинг соединения. Мониторинг объектов подразумевает возможность отслеживать отдельные значения и осуществлять переключение на основании событий. Например, если заданный контрольный тэг меняется существенным образом, т.е. принимает отрицательное значение или превышает установленный предел, это может инициировать переключение на вспомогательный OPC сервер. Или, возможно, вы бы хотели отслеживать группу точек, и если атрибут любой из них меняется на “Bad” или “Unconnected”, вы можете переключиться.

Мониторинг соединения особенно полезен при сетевом подключении. Вашей системе потребуется способ очень быстрого обнаружения обрыва сети для предотвращения потери данных. Для «горячего» резервирования или высокоскоростных систем с высокой частотой обновления данных обнаружение таймаута со скоростью отклика менее секунды является неотъемлемой частью. В любом случае система должна быть в состоянии обнаружить таймаут при сбое сетевого подключения, а также перебой в получении данных. Это важное различие. Обнаружение потери связи может занять секунды или даже минуты, но менеджер резервирования должен быть в состоянии определить приостановку потока данных за период времени, очень близкий к реальной частоте передачи данных от физический системы. Менеджер резервирования должен быть в состоянии переключить с одного источника на другой, основываясь только на наблюдении, что данные поступили не по основному каналу связи, а от резервной системы.

Некоторые системы используют таймауты COM для мониторинга соединения. Это может быть приемлемо в условиях, когда относительно длительное отсутствие данных допустимо, но мы не рекомендуем полагаться на таймауты COM при «теплом» или «горячем» резервировании.

«Умное» переключение

Большое значение имеет, как ведет себя система резервирования во время переключения. Предположим, например, что по какой-то причине произошел сбой и основного и вспомогательного подключения. Типичный менеджер резервирования запустит цикл попыток подключения поочередно то к одному, то к другому OPC серверу, пока один из них не ответит. Менеджер резервирования будет переключаться (flip-flop) между ними неопределенно долгое время, включая ждущий режим между каждым переключением для снижения нагрузки на систему. Этот ждущий режим сам по себе источник периода ожидания. Более рациональная модель переключения поддерживает опцию определения состояния источника, что позволяет менеджеру резервирования переключаться, только когда изменилось состояние источника. Это позволяет менеджеру резервирования эффективно бездействовать либо пытаться переподключиться одновременно, пока не изменится состояние источника, затем мгновенно откликнуться без дополнительного периода ожидания. Результатом применения более рациональной логики переключения может стать существенное снижение нагрузки на систему и уменьшение количества переключений.

Принудительное переключение или Приоритетный источник?

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

Доступ к исходным данным

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

Другие возможности и средства

Помимо возможностей, описанных выше, хороший менеджер резервирования может предлагать дополнительные опции для вашего удобства. Он может обеспечивать возможность обновления всего набора данных при переключении. Возможно, он будет отправлять email или даже запускать дополнительные программы при каждом переключении. Это может быть полезно для уведомления ключевых сотрудников о состоянии системы. Он может регистрировать диагностические данные для обеспечения ценной информацией о причинах переключения. Некоторые менеджеры резервирования могут подключаться к нескольким серверам и создавать несколько резервных подключений. Другие позволяют работать с выборкой данных. Еще одна актуальная функция — возможность задать, какой источник данных будет основным, а какой вспомогательным, и запустить возврат в исходный режим, как только проблема, вызвавшая переключение, будет решена.

Поскольку сложность систем управления продолжает возрастать и поскольку мы все больше и больше на них полагаемся, ситуация Мела Фарнсворта стала более распространенной и более затратной. Если подключение к источникам данных имеет ключевое значение для успеха компании, будет мудро предусмотреть возможность установки системы резервирования и тщательно взвесить варианты при выборе ключевых компонентов.

▫ ▫ ▫

Основанная в 1995 году, Cogent Real-Time Systems предлагает многофункциональные и надежные кросс-платформенные продукты для интеграции и доступа к данным реального времени в промышленных, встроенных и финансовых системах. В список их клиентов входят Siemens, ABB, Honeywell, IBM, GE, Statoil, Goodyear, BASF, Cadbury Chocolate и Банк Канады. Для получения большей информации вы можете связаться с Cogent по электронной почте info@cogent.ca или посетить сайт www.opcdatahub.com. Вы также можете нам позвонить: +1 (905) 702 7851

Источник: http://cogentdatahub.com/Download/PDF_Release/Redundancy_for_OPC.pdf