RedundancyMasterКонфігурує кілька OPC-серверів у резервні пари

Технологія доступу до даних OPC (OPC DA) підтвердила свою надійність практично в кожному промисловому середовищі, де потрібен послідовний доступ до даних, до пристроїв і систем. Однак існують інші фактори, які можуть поставити під загрозу цілісність системи, зокрема програмне забезпечення, апаратне забезпечення та навіть помилки людини. Використовуючи технологію резервування OPC, ви можете зробити ці системи більш надійними та ефективними.

RedundancyMaster знаходиться на вашій клієнтській машині OPC і полегшує з’єднання з основним і вторинним OPC-сервером у мережах системи шляхом «підключення» до викликів OPC, що здійснюються між клієнтом і сервером. Якщо з будь-якої причини клієнт OPC втрачає зв’язок із основним сервером OPC або виконується визначена користувачем умова (наприклад, елемент не отримує оновлення, відповідає певному значенню елемента або якість елемента встановлено на погано), RedundancyMaster видалить основний OPC-сервер і розмістить вторинний OPC-сервер у вашій мережі, скоротивши час простою системи та заощадивши ваші гроші.

RedundancyMaster — це додаткова програма, яка не потребує внесення будь-яких змін у клієнтські або серверні програми OPC. Його інтуїтивно зрозуміла конфігурація займає всього кілька хвилин і дозволить вам легко встановити резервну систему OPC. Просто перегляньте та виберіть свій основний і вторинний сервери OPC, і ваша система буде запущена. RedundancyMaster включає такі функції, як сповіщення електронною поштою, моніторинг об’єктів і посилань, а також журнал діагностики. У ситуації, коли вам потрібні кілька надлишкових пар OPC-серверів, які використовують того самого постачальника OPC-сервера, ми додали можливість псевдоніма ProgID (ідентифікатора програми) OPC-сервера. (Аліас може вимагати незначних модифікацій клієнта OPC.)

Знайдіть основну машину, яка вказує бажане підключення до OPC-сервера, і допоміжну машину, яка вказує резервне підключення до OPC-сервера, коли зв’язок із основною машиною недоступний. Кожного разу, коли встановлюється нове підключення клієнта до базового сервера, програма спочатку намагатиметься встановити підключення до сервера, що працює на основній машині. У разі невдачі з’єднання з основним або втрати зв’язку з основним, буде зроблена спроба з’єднання з вторинним сервером, яке буде встановлено, якщо доступне. Залежно від режиму підключення ви можете налаштувати програму на автоматичне встановлення зв’язку з основною машиною, коли вона стає доступною.

Режим підключення визначає, як і коли програма резервування має підключатися до основного та додаткового серверів. Режим, у якому ви працюєте, впливає на кількість часу, необхідного для перемикання з одного сервера OPC на інший. Деякі режими дозволяють автоматично просувати комунікації до основного, коли це доступно. Нижче наведено підсумкові режими підключення:

Холодний (тільки активна машина): у цьому режимі програма підключатиметься лише до одного базового сервера одночасно. Під час запуску буде встановлено з’єднання з основним сервером, і всі пов’язані з клієнтом запити будуть перенаправлені на основний. У випадку, якщо з’єднання з основним не вдається або з’єднання з основним втрачено, буде встановлено з’єднання з вторинним. Якщо програмі резервування не вдається встановити з’єднання з вторинним сервером, він продовжуватиме пінг-понг між двома серверами, доки не встановить успішне з’єднання.

Режим «холодного» підключення мінімізує кількість виділених системних ресурсів, оскільки в будь-який момент часу буде лише одне підключення до одного сервера. Це також зменшує мережевий трафік, оскільки немає необхідності опитувати неактивну машину на додаток до активної машини, як в інших режимах. Недоліком цього параметра є кількість часу, який потрібен для переключення на неактивний сервер. Коли виявлено втрату зв’язку з активним сервером, програмі потрібно встановити з’єднання з неактивним сервером, підписатися на всі елементи від імені клієнта та запустити відповідні механізми зворотного виклику.

Теплий (обидва комп’ютери, підписка на елементи на активному комп’ютері): у цьому режимі програма намагатиметься постійно підтримувати з’єднання з основним і вторинним серверами. Лише елементи на основному сервері будуть активними та опитуваними. У випадку, якщо з’єднання з основним не вдається або з’єднання з основним втрачено, ідентичні елементи на основному сервері будуть активовані на додатковому сервері. Періодично обидва сервери перевірятимуться, щоб визначити, чи з’єднання все ще є дійсним.

«Тепле» підключення збільшує кількість виділених системних ресурсів, оскільки від імені клієнта буде створено два підключення до сервера. Також спостерігається мінімальне збільшення мережевого трафіку за рахунок періодичного пінгування двох серверів замість одного, як в «холодному» режимі роботи. Переваги полягають у тому, що час перемикання збоїв мінімізований у порівнянні з «холодним» режимом роботи, оскільки програма резервування має лише ініціалізувати зворотні виклики даних до неактивного сервера, щоб почати отримувати дані. Якщо вам потрібно мінімізувати втрату даних у вашій програмі, і в той же час ви хочете мінімізувати мережевий трафік, вам слід використовувати цей режим підключення.

Гаряче (обидві машини, підписка на елементи на обох машинах): у цьому режимі програма намагатиметься постійно підтримувати з’єднання з основним і вторинним серверами. Під час запуску програма ініціалізує зворотні виклики даних для основного та додаткового серверів, щоб обидва сервери надсилали сповіщення про зміну даних. Дані, отримані з основного сервера, будуть передані клієнту. У разі невдачі з’єднання з основним або втрати зв’язку з основним, дані, отримані для вторинного, будуть негайно перенаправлені клієнту. У будь-якому випадку записи будуть перенаправлені лише на активний сервер. Періодично обидва сервери перевірятимуться, щоб визначити, чи з’єднання все ще дійсні. Якщо в будь-який час програма резервування втрачає зв’язок із будь-яким сервером, вона періодично намагатиметься повторно підключитися до сервера, у якому виникла помилка. Цей параметр збільшує кількість виділених системних ресурсів, оскільки від імені клієнта буде створено два підключення до сервера. Також спостерігається збільшення мережевого трафіку через отримання сповіщень про зміну даних від обох базових серверів, а також через періодичні пінги перевірте обидва сервери, щоб визначити, чи вони все ще доступні. Перевага цього параметра полягає в тому, що час відновлення після відмови відбувається одразу після виявлення втрати активного сервера. Якщо втрата даних дуже важлива для вашої програми, вам слід використовувати цей режим підключення.

Ця функція дозволяє налаштувати кілька пар серверів OPC з однаковим ProgID. Ця функція дозволяє вам використовувати одного постачальника OPC-сервера, якщо у вашій мережі є кілька вузлів OPC-сервера. Це дозволить клієнтам OPC підключатися до певної надлишкової пари, посилаючись на псевдонім ProgID цієї надлишкової пари.

Цей параметр дозволяє RedundancyMaster автоматично повертати зв’язок до основної машини, коли сервер OPC стає доступним.

Цей інтервал (зазначений у мілісекундах) визначає, як часто RedundancyMaster буде перевіряти базові сервери, щоб визначити, чи була втрата зв’язку. Надаючи запити з більшою швидкістю, ви можете мінімізувати час відновлення після відмови, оскільки виявлення помилок відбувається частіше.

Цей інтервал (вказаний у мілісекундах) визначає, як довго програма резервування чекатиме відповіді ping від базових серверів, перш ніж вважати, що зв’язок утрачений.

Ця функція дозволяє налаштувати певні умови, які ініціюватимуть перехід до неактивного сервера. Ці умови дозволяють відстежувати елементи сервера для певних станів, щоб визначити працездатність основних серверів/пристроїв, окрім автоматичного перемикання, яке відбудеться через втрату зв’язку.

Події можна зберегти на диску, коли програма вимикається. Під час наступного запуску програми події відображатимуться, а всі нові події об’єднуватимуться в кінець перегляду.
Оскільки діагностика використовує пам’ять і ресурси зберігання, ви можете обмежити кількість діагностичних даних, які зберігаються в будь-який момент часу. RedundancyMaster дозволяє встановити максимальну кількість подій для захоплення. Коли буде досягнуто максимальної кількості подій, найстаріші події будуть відхилені за потреби.

Ця функція дозволяє налаштувати одного або кількох одержувачів на отримання сповіщень електронною поштою про одну чи кілька діагностичних подій. Події, доступні для надсилання сповіщень електронною поштою, є тими самими подіями, видимими в локальному перегляді подій параметрів діагностики.

Існує багато змінних, які можуть вплинути на якість і надійність ваших даних або спричинити втрату з’єднання системи OPC із сервером OPC. До найпоширеніших відносяться:

• Комп’ютер, на якому працює сервер OPC, вимкнено
• Помилки користувача викликають обвал OPC-сервера
• Мережне підключення до OPC-сервера втрачено або ненадійне
• Налаштування мережі змінено, що спричинило збій з’єднання
• Сам сервер OPC виходить з ладу з будь-якої відомої чи іншої причини
• Обліковий запис для входу змінено на ПК OPC-сервера

У більшості випадків, наведених вище, сервер OPC DA не може надати дані через фактичний збій, що лежить в основі сервера OPC або підключення до цього сервера. Ці типи збоїв відомі як "об'єктні" збої. Об’єктні збої виникають, коли фактичний зв’язок між клієнтською програмою OPC і цільовим OPC-сервером порушується. У цих прикладах винне програмне забезпечення. Однак фізичні поломки апаратного забезпечення в програмі також можуть значно вплинути на надійність. Деякі з цих фізичних факторів включають:

>
• Фізичний збій підключення (кабель витягнуто)
• Збій обладнання (збій маршрутизатора)
• Електричні перешкоди (сильний розряд)
• Затримки через поширення сигналу (радіозв'язок)
• Фактори зовнішнього середовища (блискавка)
• Випадкові аварії

У таких ситуаціях віртуальне з’єднання між OPC-сервером і клієнтом може бути абсолютно неушкодженим, але фізичне з’єднання з основним пристроєм або системою може бути порушено. Ці типи збоїв відомі як збої на основі зв’язку. Збої на основі зв’язку виникають, коли з’єднання з цільовим пристроєм або системою втрачено. У більшості випадків OPC-сервер все ще повністю працює, але просто не може надавати дані решті системи.

RedundancyMaster можна налаштувати для моніторингу цих умов і запобігання непотрібним простоям вашої системи, заощаджуючи ваш час і гроші.

Якщо кілька клієнтських додатків OPC DA звертаються до одного сервера OPC, існує ймовірність як об’єктного збою, так і збою на основі зв’язку. Якщо з будь-якої причини єдиний OPC-сервер не працює, може виникнути об’єктний збій. Крім того, оскільки цей єдиний ПК відповідає за збір даних із базових пристроїв, єдина точка збою існує також для з’єднань пристроїв.

Щоб підвищити надійність вашої системи OPC, вам потрібно усунути ці окремі точки відмови, перепроектувавши вашу систему OPC, щоб використовувати більше одного сервера OPC. Щоб полегшити резервну роботу OPC-серверів, кожен OPC-клієнт поєднується з RedundancyMaster.

За допомогою настроюваних параметрів у RedundancyMaster можна напряму керувати використанням первинного або вторинного OPC-сервера. Залежно від вибраних режимів RedundancyMaster підтримуватиме активність обох серверів або (якщо налаштовано на це) запускатиме вторинний сервер лише у разі збою основного сервера.

У цьому сценарії клієнт OPC, RedundancyMaster і вторинний сервер OPC знаходяться на локальній машині, а основний сервер OPC знаходиться на віддаленій машині. Для цієї системи обов’язково зробіть найнадійніший сервер вторинним сервером OPC. Цей сценарій зменшує потребу в іншій машині для запуску вторинного сервера OPC.

RedundancyMaster можна налаштувати на наявність кількох пар серверів OPC. У цьому сценарії є дві пари серверів OPC, які збирають дані з двох окремих мереж пристроїв. Якщо кілька пар серверів OPC мають однаковий ідентифікатор ProgID, вам потрібно буде використовувати функцію псевдонімів. Якщо дві пари мають різні OPC-сервери з різними ProgID, вам не потрібно буде використовувати функцію псевдонімів..