Обеспечение надежности в системе паз
Основная проблема обеспечения надежности заключается в выборе системы резервирования ПАЗ. Основываясь на принятых правилах (ПБ 09-170-97) и требованиях ГОСТ 24.104-85, часто предлагается реализовать систему ПАЗ с резервированием процессорного модуля. Недостатки резервирования процессорного модуля состоят в следующем:
не все современные промышленные контроллеры имеют возможность построения многопроцессорной архитектуры. Широко известный вариант это контроллеры с шиной VME. Но это достаточно дорогие контроллеры;
отказоустойчивая система предполагает своевременное выявление, предупреждение аварийной ситуации и обеспечение замены неисправного элемента системы без прерывания технологического процесса. Это не обеспечивается резервированием процессорного модуля;
при выходе из строя источника питания контроллера система ПАЗ неработоспособна;
при выходе из строя арбитра (он необходим в многопроцессорной системе) система ПАЗ не работоспособна;
в системах с высокоскоростными параллельными шинами данных, адреса и управления, где возможно построение двухпроцессорной архитектуры, часто происходят непредвиденные отказы с невозможностью продолжения процесса. Необходим общий сброс или переключение питания контроллера и перезагрузка программы контроллера, а это недопустимо для системы ПАЗ;
при выходе из строя основного процессора резервный может не подхватить процесс (безударное переключение), ввиду возникновения конфликтной ситуации на шине (зависание);
на процессорный модуль приходится значительная доля стоимости всего контроллера (более 50%).
Поэтому высокая надежность системы ПАЗ предполагает резервирование всех составных частей контроллерного оборудования, а именно:
резервирование процессора;
резервирование локальной шины обмена ПЦ-УСО;
резервирование крейта;
резервирование источника питания (ИП) контроллера;
резервирование коммуникационных интерфейсов.
А это выливается в дублирование контроллера. Такая система ПАЗ обеспечивает 100-процентное «горячее» резервирование.
Выбираю второй метод реактивности системы исходя из того , что в первом методе необходимо хранить предысторию аварийной ситуации в памяти контроллера, которая на это не рассчитана.
При использовании второго метода (рис.13.3) аварийное сообщение, сопровождаемое меткой времени (taimstamp), передается из выполняющейся в контроллере прикладной программы на верхний уровень в АРМ. Именно там обрабатывается предыстория события и хранится аварийный тренд (на жестком диске). Память контроллера используется для формирования таблиц и буфера аварийных сообщений, но при этом не требуется большого объема памяти буфера. Транзакции происходят с высокой скоростью, на порядок выше традиционного обмена между приложением и системой SCADA. Данный метод не требует применения высокоскоростных контроллеров и модулей УСО, а также специальной области памяти для хранения временного массива аварийного события.
