SOER - журнал последовательных событий контроллера ProSafe-RS

Пошаговый самоучитель ProSafe-RS

 


Содержание самоучителя


Урок 5
SOER, SOE Viewer, Message Cache Tool

SOER - Sequence of Events Recorder – журнал последовательных событий с метками времени и комментариями, который хранится в контроллере ProSafe-RS.

SOER регистрирует цепочку событий до и после трипа, т.е. помогает найти причину трипа и проанализировать последствия трипа.

События, которые может регистрировать SOER:

  • Изменение состояния дискретного сигнала (DI или DO)
  • Направление перехода аналогового сигнала через границы Low-Low, Low, Hi, Hi-Hi
  • Значения внутренних переменных (BOOL, INTEGER, REAL) прикладной программы

SOE Viewer – позволяет просматривать журнал SOER на инженерной станции SENG.

Отличие регистрации событий по дискретным входам и выходам

Событие по дискретному входу DI генерирует модуль дискретного ввода во время изменения сигнала на входе модуля.

Событие по дискретному выходу DO генерирует CPU в момент времени, предшествующий моменту передачи сигнала в модуль дискретного вывода.

Файлы, в которых SOER сохраняет данные в контроллере SCS

SOER хранит данные в двух файлах:

  1. Event log file
  2. Trip signal file

Event log file

В одном контроллере может храниться только один Event log файл.

В файле Event log может храниться до 15000 последних событий.

Если количество событий превышает 15000, то самые старые события стираются и на их место записываются новые события.

Когда количество событий превышает 12000, контроллер отправляет диагностическое сообщение пользователю.

Event log file хранится в рабочей памяти контроллера и при пропадании питания только 1000 последних событий успевают сохраниться в памяти, запитанной от батарейки.

Trip signal file

В одном контроллере может храниться до двух файлов Trip signal.

В файле Trip signal может храниться до 500 событий, предшествующих трипу, сам триповый сигнал и до 1000 событий после трипа. Файл закрывается после того как наберётся 1000 событий после трипа или через 30 минут после трипа, независимо от количества собранных послетриповых событий. После закрытия файла контроллер SCS отправляет пользователю диагностическое сообщение о готовности файла Trip signal. Новые файлы Trip signal создаются вручную с помощью специальной утилиты.

Открытый файл Event log хранится в рабочей памяти контроллера и при пропадании питания удаляется. Если Event log файл успевает закрыться до пропадания питания, то он переписывается в память с батарейкой.

Рестарт или офлайн прогрузка контроллера

Сохранённый до останова контроллера журнал событий восстанавливается после рестарта контроллера или офлайн прогрузки.



Задание

  1. Сконфигурировать DO для регистрации в SOER в качестве трипового сигнала
  2. Запрограммировать триповый сигнал
  3. Проимитировать события до трипа, трип и события после трипа
  4. Прочитать журнал событий с помощью SOE Viewer
  5. С помощью утилиты Message Cache Tool сохранить файлы Trip signal на жёстком диске SENG, а после этого стереть их в контроллере SCS и инициализировать новые

Решение

SCS симулятор не поддерживает SOER для DI, поэтому ограничимся упражнением с DO.

  1. Открываем редактор параметров входов-выходов:
    Engineering > I/O Parameter Builder.
    Изменяем два параметра выхода в слоте 4 канал 1:
    SOER = Yes, Trip Singnal = ON TRIP

    Рис. I/O Parameter Builder
    Это означает, что изменение состояния дискретного выхода DO1 с FALSE на TRUE регистрируется в SOER как трип.

  2. Добавляем ещё один программный блок с именем TripProgram:

    Рис. TripProgram

  3. Открываем словарь переменных:
    Project > Variables
    и добавляем три глобальных внутренних переменных типа BOOL: var_1, var_2, trip

    Рис. Variables

  4. Открываем редактор схем функциональных блоков FBD и добавляем следующий код:

    Рис. Код программы TripProgram
    Функциональные блоки SOE_B используются для регистрации внутренних переменных булевского типа в журнале SOER.

    На вход TRP подаётся константа:
    TRIP_NONE – переменная регистрируется как событие
    TRIP_ON – переменная регистрируется как трип при изменении с FALSE на TRUE
    TRIP_OFF – переменная регистрируется как трип при изменении с на TRUE на FALSE

    На вход ID подаётся текст комментария, который тоже записывается в SOER.

  5. Компилируем проект:
    Project > Build Project/Library

  6. Прогоняем анализаторы

  7. Запускаем SCS симулятор:
    Maintenance > SCS Test Function

    Рис. SCS Test Function

  8. Ждём пока полностью не запуститься симулятор контроллера безопасности:

    Рис. Test Function

  9. В редакторе схем функциональных блоков FBD запускаем отладчик логики для POU PripProgram:
    Debug > Debug
    И форсируем переменные var_1 и var_2 из FALSE в TRUE и обратно.

  10. Из меню ПУСК запускаем SOE Viewer:

    Рис. Пуск SOE Viewer

  11. В открывшемся окне нажимаем кнопку [Setup]:

    Рис. SOE Viewer Setup

  12. В открывшемся окне переходим на вкладку Data Source (источник данных) и задаём имя нашего контроллера – SCS0102

    Рис. SOE Viewer Properties
    Обратите внимание, что можно задать до 8 источников данных.
    Оставляем галочки для событий из SOER (Events) и диагностических сообщений (Alarms).

  13. В основном меню SOE Viewer нажимаем кнопку запроса данных [Query]:

    Рис. SOE Viewer Query
    Видим, что в журнале появились записи 4-х событий и 4 диагностических сообщения, триповое событие выделено жёлтым цветом. События выше трипового могут быть причинами, которые привели к трипу, а события ниже трипа могут быть последствиями трипа.


  14. Открываем утилиту управления кэшем сообщений:
    Пуск > YOKOGAWA ProSafe > Message Cache Tool

    Рис. Пуск Message Cache Tool

    Рис. Message Cache Tool
    Видим, что в первом триповом файле записано 4 из 1500 событий.

  15. В редакторе схем функциональных блоков FBD в режиме отладчика логики для POU FirstProgram форсируем логические значения входных переменных DI1 и DI2 из FALSE в TRUE и обратно.

    Ещё раз нажимаем кнопку [Query] в SOER Viewer – никаких новых трипов не появилось, появилось только 6 новых диагностических сообщений:

    Рис. Message Cache Tool

    Что не так?

  16. Открываем окно форсирования входов-выходов
    Maintenance > I/O Lock Window:

    Рис. I/O Lock Window


  17. Ещё раз форсируем логические значения входных переменных DI1 и DI2 из FALSE в TRUE.

    Ещё раз открываем окно I/O Lock Window:

    Рис. Channel disabled
    Видим, что выходной канал заблокирован, и логическое значение выходной переменной не передаётся на физический выход. То есть система даёт вам ещё один шанс на проверку правильности форсирования.
    Если вы на 100% уверены в том, что этот выход не трипанёт завод, то деблокируйте выходы.

  18. Для этого открываем окно управления состоянием контроллера безопасности:
    Maintenance > SCS State Management

    А в открывшемся окне выбираем сначала пункт меню:
    Window > Diagnostic Information
    Открывается окно с диагностикой:

    Рис. Diagnostic Information
    Чтобы сообщения перестали мигать их необходимо квитировать кнопкой с красной галочкой - [Acknowledgment].

  19. Возвращаемся в основное окно SCS State Management и там нажимаем кнопку [I/O Channel Status].

    В открывшемся окне нажимаем кнопку [Output enabled]:

    Рис. Output enabled
    (подробное описание этой операции см. в уроке 3).


  20. В окне I/O Lock Window видим, что физический выход сработал:

    Рис. Channel enabled

  21. Повторяем запрос в SOE Viewer и видим, что прилетел трип:

    Рис. SOE Viewer
    (конечно, это не тот трип, который останавливает завод)

  22. Обновляем окно утилиты управления кэшем сообщений и видим уже 5 событий:

    Рис. Message Cache Tool

  23. Чтобы удалить старые триповые файлы в контроллере нажимаем кнопку [Initialize Trip Information]:

    Рис. Message Cache Tool
    Видим, что информация из файлов в контроллере удалена. Но она ещё осталась в кэше на диске. В этом можно убедиться, если очистить окно SOE Viewer с помощью кнопки [Clear] и заново нажать кнопку [Query]. Вы получите тот же список событий и сообщений.

  24. Перед тем как очистить кэш на диске, сохраним файлы на жёстком диске инженерной станции:
    Открываем окно утилиты Message Cache Tool нажимаем кнопку [Save Disk Cache].
    В открывшемся окне нажимаем кнопку [Select all], выбираем папку для хранения файлов и нажимаем кнопку [Save]:

    Рис. Message Cache Tool

  25. Теперь можно почистить кэш на диске – нажимаем [Delete DISK cache]. В открывшемся окне нажимаем кнопку [Select all] и нажимаем кнопку [Delete]. Кэш очищен:

    Рис. Message Cache Tool

  26. В этом можно убедиться, если очистить окно SOER Viewer с помощью кнопки [Clear] и заново нажать кнопку [Query]. В ответ вы получите только окно с предупреждением:

    Рис. SOE Viewer Warning