Урок 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 хранит данные в двух файлах:
- Event log file
- 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 файл успевает закрыться до пропадания питания, то он переписывается в память с батарейкой.
Рестарт или офлайн прогрузка контроллера
Сохранённый до останова контроллера журнал событий восстанавливается после рестарта контроллера или офлайн прогрузки.
Задание
- Сконфигурировать DO для регистрации в SOER в качестве трипового сигнала
- Запрограммировать триповый сигнал
- Проимитировать события до трипа, трип и события после трипа
- Прочитать журнал событий с помощью SOE Viewer
- С помощью утилиты Message Cache Tool сохранить файлы Trip signal на жёстком диске SENG, а после этого стереть их в контроллере SCS и инициализировать новые
Решение
SCS симулятор не поддерживает SOER для DI, поэтому ограничимся упражнением с DO.
-
Открываем редактор параметров входов-выходов:
Engineering > I/O Parameter Builder.
Изменяем два параметра выхода в слоте 4 канал 1:
SOER = Yes, Trip Singnal = ON TRIP
Это означает, что изменение состояния дискретного выхода DO1 с FALSE на TRUE регистрируется в SOER как трип. -
Добавляем ещё один программный блок с именем TripProgram:
-
Открываем словарь переменных:
Project > Variables
и добавляем три глобальных внутренних переменных типа BOOL: var_1, var_2, trip
-
Открываем редактор схем функциональных блоков FBD и добавляем следующий код:
Функциональные блоки SOE_B используются для регистрации внутренних переменных булевского типа в журнале SOER.
На вход TRP подаётся константа:
TRIP_NONE – переменная регистрируется как событие
TRIP_ON – переменная регистрируется как трип при изменении с FALSE на TRUE
TRIP_OFF – переменная регистрируется как трип при изменении с на TRUE на FALSE
На вход ID подаётся текст комментария, который тоже записывается в SOER. -
Компилируем проект:
Project > Build Project/Library - Прогоняем анализаторы
-
Запускаем SCS симулятор:
Maintenance > SCS Test Function
-
Ждём пока полностью не запуститься симулятор контроллера безопасности:
-
В редакторе схем функциональных блоков FBD запускаем отладчик логики для POU PripProgram:
Debug > Debug
И форсируем переменные var_1 и var_2 из FALSE в TRUE и обратно. -
Из меню ПУСК запускаем SOE Viewer:
-
В открывшемся окне нажимаем кнопку [Setup]:
-
В открывшемся окне переходим на вкладку Data Source (источник данных) и задаём имя
нашего контроллера – SCS0102
Обратите внимание, что можно задать до 8 источников данных.
Оставляем галочки для событий из SOER (Events) и диагностических сообщений (Alarms). -
В основном меню SOE Viewer нажимаем кнопку запроса данных [Query]:
Видим, что в журнале появились записи 4-х событий и 4 диагностических сообщения, триповое событие выделено жёлтым цветом. События выше трипового могут быть причинами, которые привели к трипу, а события ниже трипа могут быть последствиями трипа. -
Открываем утилиту управления кэшем сообщений:
Пуск > YOKOGAWA ProSafe > Message Cache Tool
Видим, что в первом триповом файле записано 4 из 1500 событий. -
В редакторе схем функциональных блоков FBD в режиме отладчика логики для POU FirstProgram
форсируем логические значения входных переменных DI1 и DI2 из FALSE в TRUE и обратно.
Ещё раз нажимаем кнопку [Query] в SOER Viewer – никаких новых трипов не появилось, появилось только 6 новых диагностических сообщений:
Что не так? -
Открываем окно форсирования входов-выходов
Maintenance > I/O Lock Window:
-
Ещё раз форсируем логические значения входных переменных DI1 и DI2 из FALSE в TRUE.
Ещё раз открываем окно I/O Lock Window:
Видим, что выходной канал заблокирован, и логическое значение выходной переменной не передаётся на физический выход. То есть система даёт вам ещё один шанс на проверку правильности форсирования.
Если вы на 100% уверены в том, что этот выход не трипанёт завод, то деблокируйте выходы. -
Для этого открываем окно управления состоянием контроллера безопасности:
Maintenance > SCS State Management
А в открывшемся окне выбираем сначала пункт меню:
Window > Diagnostic Information
Открывается окно с диагностикой:
Чтобы сообщения перестали мигать их необходимо квитировать кнопкой с красной галочкой - [Acknowledgment]. -
Возвращаемся в основное окно SCS State Management и там нажимаем кнопку [I/O Channel Status].
В открывшемся окне нажимаем кнопку [Output enabled]:
(подробное описание этой операции см. в уроке 3). -
В окне I/O Lock Window видим, что физический выход сработал:
-
Повторяем запрос в SOE Viewer и видим, что прилетел трип:
(конечно, это не тот трип, который останавливает завод) -
Обновляем окно утилиты управления кэшем сообщений и видим уже 5 событий:
-
Чтобы удалить старые триповые файлы в контроллере нажимаем кнопку [Initialize Trip Information]:
Видим, что информация из файлов в контроллере удалена. Но она ещё осталась в кэше на диске. В этом можно убедиться, если очистить окно SOE Viewer с помощью кнопки [Clear] и заново нажать кнопку [Query]. Вы получите тот же список событий и сообщений. -
Перед тем как очистить кэш на диске, сохраним файлы на жёстком диске инженерной станции:
Открываем окно утилиты Message Cache Tool нажимаем кнопку [Save Disk Cache].
В открывшемся окне нажимаем кнопку [Select all], выбираем папку для хранения файлов и нажимаем кнопку [Save]:
-
Теперь можно почистить кэш на диске – нажимаем [Delete DISK cache].
В открывшемся окне нажимаем кнопку [Select all] и нажимаем кнопку [Delete].
Кэш очищен:
-
В этом можно убедиться, если очистить окно SOER Viewer с помощью кнопки [Clear] и
заново нажать кнопку [Query]. В ответ вы получите только окно с предупреждением:
