Подготовка за одит на функционалната безопасност 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 с 2oo3 логика на гласуване постига ниски стойности на PFDavg благодарение на високото диагностично покритие (DC ≥ 99%) и вградената излишност. Въпреки това, публикуваните стойности на PFDavg от докладите Triconex FMEDA предполагат конкретни интервали за тестове и работни условия.

Пресметнете отново PFDavg за всяка SIF, използвайки опростената формула за подсистема 1oo1: PFDavg = λDU × Ti / 2, където λDU е честотата на опасни неоткрити откази, а Ti е интервалът за тест за доказване в часове. За Triconex T3000 с λDU = 2.3×10⁻⁷ на час (от Triconex FMEDA 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 са непълни записи от тестове за доказване. IEC 61511, точка 16.2.5 изисква записите от тестове за доказване да включват: дата на теста, идентичност на техника, метод на теста, състояние „както е намерено“, резултат от теста и състояние „както е оставено“. Записи, съдържащи само подпис и обозначение „PASS“, не отговарят на изискванията.

• Стъпка 1: Одитирайте всеки запис от тест за доказване на SIF от последния интервал за тест. Създайте матрица на пропуските: номер на SIF, дата на теста, липсващи полета, отговорен техник.
• Стъпка 2: За записи, в които липсва време за реакция „както е намерено“, свържете се с оригиналния техник и поискайте декларация под клетва за измерената стойност по спомен — ако е документирана другаде (в полеви бележник, система за калибриране). Прикачете декларацията към оригиналния запис.
• Стъпка 3: За записи без никакви данни „както е намерено“ документирайте пропуска формално като несъответствие в системата за управление на безопасността. Назначете коригиращо действие за извършване на непланиран тест за доказване при следващия наличен прозорец за поддръжка, за да се установи нова базова линия „както е намерено“.
• Стъпка 4: Внедрете структуриран шаблон за тест за доказване в CMMS (SAP PM или подобна система). Шаблонът трябва да изисква задължителни полета — време за реакция в милисекунди, потвърждение на движение на крайния елемент и Triconex TriStation диагностичен моментен образ преди и след теста. Заключете записа така, че да не може да се избере PASS без въвеждане на числова стойност за време за реакция.

Изисквания за документация при управление на заобикаляне

Управлението на заобикаляне е критично изискване по IEC 61511, точка 11.9.4. Всеки път, когато SIF на Triconex T3000 се поставя в режим на заобикаляне, остатъчният риск се увеличава — функцията за безопасност е недостъпна. Регистърът за заобикаляне трябва да записва: причина за заобикаляне, орган за одобрение, начален час, планиран краен час и компенсаторни мерки, приложени по време на периода на заобикаляне.

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

SRS трябва да дефинира максималната допустима продължителност на заобикаляне за всяка SIF въз основа на честотата на процесното изискване. За SIF, която защитава срещу опасност с честота на процесно изискване 0.1 на година, максималната продължителност на заобикаляне без компенсаторни мерки обикновено е 72 часа. Одиторите ще сравнят регистъра за заобикаляне в CMMS с SOE регистъра — несъответствията между тях показват, че процесът за контрол на заобикалянето не функционира както трябва и представляват системна неспособност съгласно IEC 61511, точка 5.

Контролен списък за проверка на конфигурацията преди одит

• Експортирайте отчета за конфигурацията на проекта TriStation 1131 и сравнете всички зададени стойности за спиране на SIF със SRS. Всяко отклонение изисква запис за Управление на промяната (MOC), датиран преди въвеждането на промяната.
• Потвърдете, че версията на фърмуера на Triconex T3000 съвпада с версията, квалифицирана в случая за безопасност. Актуализациите на фърмуера Triconex изискват повторна валидация съгласно IEC 61511, точка 11.8.5, ако актуализацията засяга функционалност, свързана с безопасността.
• Проверете дали всички интервали за диагностични тестове са в рамките на стойностите, посочени в SRS. Цикълът на самотест на модула T3000 по подразбиране е 1 час — уверете се, че това не е променено на по-дълъг интервал с цел намаляване на честотата на алармите SCADA DIAG_FAIL.
• Проверете дали датата и часът на Triconex T3000 се синхронизират с NTP сървъра на завода. Несинхронизираните времеви печати в SOE са често срещано несъответствие при одит, което поставя под въпрос последователността на всички исторически събития за безопасност.
• Прегледайте дневника на промените в TriStation за всякакви модификации на конфигурацията, направени без съответен запис за MOC. Неоторизираните промени са сериозно несъответствие съгласно IEC 61511, точка 5.2.4 (управление на функционалната безопасност).

Заключение и препоръки за действие

Подготовката на инсталация Invensys Triconex за функционален одит по IEC 61511 изисква систематично събиране на доказателства, а не генериране на документи в последния момент. Пресметнете отново PFDavg за всяка SIF, използвайки реалните интервали за тестове и данни от FMEDA за инсталацията — не разчитайте на публикувани таблици за SIL без проверка. Одитирайте записите от тестове за доказване за липсващи времена за реакция „както е намерено“ и отстранете пропуските формално. Проверете записите за управление на заобикалянето както в CMMS, така и в SOE регистъра на Triconex — несъответствията показват системни процесни грешки.

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

Автор: Фанг Хаоран е инженер по индустриална автоматизация с над 10 години опит в PLC, DCS и системи за управление.