Подготовка к аудиту функциональной безопасности IEC 61511: создание обоснованного пакета доказательств для систем безопасности Invensys Triconex

Что на самом деле проверяют аудиторы

Аудит функциональной безопасности по IEC 61511 — это не просто проверка документов, а анализ разрывов между вашей Спецификацией Требований Безопасности (SRS) и фактической системой, построенной и обслуживаемой на объекте. Аудиторы сначала проверяют три аспекта: полноту обоснования безопасности, целостность записей о проверочных испытаниях и обоснованность заявленного уровня SIL. Для установки Invensys Triconex T3000 или Tricon CX пакет доказательств должен показать, что Система Инструментальной Безопасности (SIS) была спроектирована, установлена и обслуживается в соответствии с SRS. Пробелы в любой из этих областей могут снизить эффективный уровень SIL с SIL 2 до SIL 1 или, в тяжелых случаях, полностью аннулировать обоснование безопасности.

Во-первых, соберите полный документ SRS, включая все описания Функций Инструментальной Безопасности (SIF), целевые уровни SIL и частоты требований процесса. Во-вторых, подтвердите, что все конфигурации проекта TriStation 1131 соответствуют SRS — архитектура, логика голосования, логика обхода и покрытие диагностики. В-третьих, проверьте, что записи о проверочных испытаниях подписаны, датированы и содержат зафиксированное время реакции «как найдено», а не только отметки «пройдено/не пройдено».

Пересчет PFDavg и проверка SIL

Средняя вероятность отказа по требованию (PFDavg) количественно оценивает надежность SIS в течение интервала проверочного испытания. Для SIL 2 требуется PFDavg в диапазоне от 1×10⁻³ до 1×10⁻². Архитектура Triconex T3000 TMR с логикой голосования 2 из 3 достигает низких значений PFDavg благодаря высокому покрытию диагностики (DC ≥ 99%) и встроенной избыточности. Однако опубликованные значения PFDavg из отчетов FMEDA Triconex предполагают определённые интервалы проверочных испытаний и условия эксплуатации.

Пересчитайте PFDavg для каждой SIF, используя упрощённую формулу для подсистемы 1 из 1: PFDavg = λDU × Ti / 2, где λDU — частота опасных невыявленных отказов, а Ti — интервал проверочного испытания в часах. Для Triconex T3000 с λDU = 2.3×10⁻⁷ в час (по данным FMEDA Triconex Rev 4) и Ti = 8760 часов (годовое испытание): PFDavg = 2.3×10⁻⁷ × 8760 / 2 = 1.0×10⁻³. Это ровно нижняя граница SIL 2 — без запаса. Сокращение Ti до 4380 часов (полугодовое испытание) уменьшает PFDavg до 5.0×10⁻⁴, что уверенно помещает SIF в диапазон SIL 2.

Последний элемент (клапан ESD или устройство отключения) часто доминирует в PFDavg SIF, а не логический контроллер Triconex. Типичный соленоидный клапан с λDU = 5×10⁻⁷ в час и Ti = 8760 часов вносит вклад PFDavg = 2.2×10⁻³ — этого достаточно, чтобы исчерпать бюджет SIL 2. Частичное тестирование хода (PST) с интервалом 3 месяца снижает этот вклад до 5.5×10⁻⁴ и восстанавливает значительный запас PFDavg.

Устранение пробелов в записях проверочных испытаний

Самой распространённой находкой аудита на установках Triconex являются неполные записи проверочных испытаний. Пункт 16.2.5 IEC 61511 требует, чтобы записи включали: дату испытания, личность техника, метод испытания, состояние «как найдено», результат испытания и состояние «как оставлено». Записи, содержащие только подпись и отметку «ПРОЙДЕНО», не соответствуют требованиям.

• Шаг 1: Проверьте каждую запись проверочного испытания SIF за последний интервал испытаний. Создайте матрицу пробелов: номер SIF, дата испытания, отсутствующие поля, ответственный техник.
• Шаг 2: Для записей без времени реакции «как найдено» свяжитесь с оригинальным техником и запросите официальное заявление о значении, измеренном по памяти — если оно задокументировано в другом месте (полевой журнал, система калибровки). Приложите заявление к оригинальной записи.
• Шаг 3: Для записей без каких-либо данных «как найдено» формально задокументируйте пробел как несоответствие в системе управления безопасностью. Назначьте корректирующее действие — проведение внепланового проверочного испытания при следующем доступном окне обслуживания для установления новой базы «как найдено».
• Шаг 4: Внедрите структурированный шаблон проверочного испытания в CMMS (SAP PM или аналог). Шаблон должен требовать обязательного заполнения полей — время реакции в миллисекундах, подтверждение хода конечного элемента и диагностический снимок Triconex TriStation до и после испытания. Заблокируйте запись так, чтобы отметка «ПРОЙДЕНО» не могла быть выбрана без числового значения времени реакции.

Требования к документации управления обходом

Управление обходом — критическое требование пункта 11.9.4 IEC 61511. Каждый раз, когда SIF Triconex T3000 переводится в обход, остаточный риск увеличивается — функция безопасности становится недоступной. В журнале обходов должны фиксироваться: причина обхода, лицо, одобряющее обход, время начала, планируемое время окончания и компенсирующие меры, реализованные в период обхода.

В TriStation 1131 условия обхода реализуются через переменные INHIBIT или BYPASS в управляющей программе. Каждая переменная INHIBIT должна быть связана с физическим ключом или тегом авторизации на уровне SCADA. Настройте программу TriStation так, чтобы при изменении состояния переменной INHIBIT в журнал SOE (Последовательность Событий) записывалось событие обхода. Метка времени SOE обеспечивает аудиторский след, требуемый IEC 61511.

SRS должен определять максимально допустимую продолжительность обхода для каждого SIF на основе частоты требований процесса. Для SIF, защищающего от опасности с частотой требований 0.1 в год, максимальная продолжительность обхода без компенсирующих мер обычно составляет 72 часа. Аудиторы сверят журнал обходов CMMS с журналом SOE — расхождения между ними указывают на то, что процесс управления обходом не работает должным образом и представляют собой системный сбой по пункту 5 IEC 61511.

Контрольный список проверки конфигурации перед аудитом

• Экспортируйте отчет конфигурации проекта TriStation 1131 и сравните все уставки срабатывания SIF с SRS. Любое отклонение требует записи Управления Изменениями (MOC), датированной до внедрения изменений.
• Проверьте, что версия прошивки Triconex T3000 совпадает с версией, квалифицированной в обосновании безопасности. Обновления прошивки Triconex требуют повторной валидации по пункту 11.8.5 IEC 61511, если обновление влияет на функции, связанные с безопасностью.
• Подтвердите, что все интервалы диагностических тестов соответствуют значениям, указанным в SRS. Цикл самотестирования модуля T3000 по умолчанию — 1 час; проверьте, что он не был изменён на более длинный интервал для снижения частоты сигналов тревоги SCADA DIAG_FAIL.
• Проверьте, что дата и время Triconex T3000 синхронизируются с NTP-сервером предприятия. Несинхронизированные метки времени SOE — распространённое несоответствие аудита, ставящее под сомнение последовательность всех исторических событий безопасности.
• Просмотрите журнал изменений в TriStation на предмет модификаций конфигурации без соответствующей записи MOC. Несанкционированные изменения — серьёзное несоответствие по пункту 5.2.4 IEC 61511 (управление функциональной безопасностью).

Заключение и рекомендации к действиям

Подготовка установки Invensys Triconex к аудиту функциональной безопасности IEC 61511 требует системного сбора доказательств, а не создания документов в последний момент. Пересчитайте PFDavg для каждой SIF, используя фактические интервалы проверочных испытаний и данные FMEDA, соответствующие установленной системе — не полагайтесь на опубликованные таблицы SIL без проверки. Проверьте записи проверочных испытаний на наличие времени реакции «как найдено» и формально устраните пробелы. Проверьте записи управления обходом как в CMMS, так и в журнале SOE Triconex — расхождения указывают на системные сбои процесса.

Завершите контрольный список проверки конфигурации за 30 дней до аудита, чтобы было время оформить документацию MOC по обнаруженным отклонениям. Привлеките компетентного инженера по функциональной безопасности для проверки пакета доказательств до прихода аудитора. Обнаружение пробела SIL 2 во время аудита обходится гораздо дороже — по времени, деньгам и рискам процесса — чем выявление его на внутреннем контроле.

Автор: Фанг Хаоран — инженер по промышленной автоматизации с более чем 10-летним опытом работы с ПЛК, ДСК и системами управления.