Перевод документации функциональной безопасности (SIL) по МЭК 61508 и МЭК 61511 для АСУ ТП

На газоперерабатывающем заводе идёт модернизация системы противоаварийной защиты. Поставщик АСУ ТП присылает пакет документации по функциональной безопасности: спецификацию требований безопасности, отчёт классификации SIL, расчёты вероятности отказа, руководство по безопасности на систему и процедуры периодических испытаний. Всё это на английском языке, с терминологией МЭК 61508 и МЭК 61511. Заказчику нужен русский перевод, который поймут не только инженеры АСУ ТП, но и служба промышленной безопасности, и орган по оценке соответствия.

Здесь перевод перестаёт быть переносом текста и становится частью контура безопасности объекта. Если переводчик спутает «вероятность отказа на запрос» с «частотой опасных отказов», расчёт SIL для внешнего читателя потеряет смысл. Если «proof test» переведён то как «контрольная проверка», то как «периодическое испытание» в разных разделах одного документа, аудитор функциональной безопасности задаст вопрос, на который у команды не будет хорошего ответа. Ниже разберём, из чего состоит документация функциональной безопасности по МЭК 61508 и 61511, какая терминология не прощает вольностей и как выстроить перевод так, чтобы пакет прошёл проверку.

Функциональная безопасность и SIL: что стоит за стандартами

МЭК 61508 (IEC 61508) — базовый международный стандарт функциональной безопасности электрических, электронных и программируемых электронных систем, связанных с безопасностью. МЭК 61511 (IEC 61511) применяет положения МЭК 61508 к промышленным процессам: нефтегазу, химии, неядерной энергетике, фармацевтике, целлюлозно-бумажному и пищевому производству. Для проектов АСУ ТП на промышленных объектах Казахстана это две опорные точки, вокруг которых строится вся документация систем противоаварийной защиты.

Ключевое понятие — уровень полноты безопасности, SIL (Safety Integrity Level). Это дискретная характеристика того, насколько надёжно функция безопасности должна срабатывать. Шкала идёт от SIL 1 до SIL 4, где SIL 4 отвечает наибольшей полноте безопасности, а SIL 1 — наименьшей. Каждому уровню соответствует свой диапазон вероятности отказа на запрос (PFD) и коэффициента снижения риска (RRF). Чем выше SIL, тем реже функция имеет право отказать, а значит, тем больше требований к резервированию оборудования и частоте испытаний.

Система противоаварийной защиты в терминах стандарта — это связка датчиков, логического решателя и исполнительных элементов, спроектированная для достижения заданного SIL. Каждый из этих элементов описан в отдельной документации, и перевод должен сохранять единство обозначений между ними.

Важно, что SIL характеризует не отдельный прибор, а функцию безопасности целиком, от датчика до исполнительного механизма. Поставщик может заявить SIL-пригодность датчика или клапана, но итоговый уровень функции определяется расчётом по всей цепочке с учётом архитектуры и периодичности испытаний. Эта тонкость важна для перевода: формулировку о SIL конкретного компонента нельзя переносить как утверждение о SIL всей функции, иначе документ начнёт вводить читателя в заблуждение относительно фактического уровня защиты. Общие принципы перевода сертификационной и нормативной документации мы разбирали в полном руководстве по переводу сертификационной документации для ЕАЭС и международных рынков. Функциональная безопасность добавляет к этому свой пласт расчётов и терминов.

Какие документы требуют перевода в проекте SIS

Пакет документации функциональной безопасности намного шире одного руководства. По жизненному циклу безопасности МЭК 61511 в проекте АСУ ТП обычно фигурируют несколько типов документов, и каждый ставит перед переводчиком свою задачу.

Спецификация требований безопасности (Safety Requirements Specification) задаёт, что именно должна делать каждая функция безопасности, при каких условиях и с каким SIL. Это документ, от точности перевода которого зависит проектирование всей системы. Отчёт классификации и назначения SIL, часто опирающийся на анализ методом LOPA (уровни защиты), обосновывает, почему конкретной функции присвоен именно этот уровень. Отчёты верификации SIL с расчётами PFD и архитектурных ограничений показывают, что выбранная конфигурация действительно достигает заявленного уровня.

К этому добавляются отчёты FMEDA по отказам компонентов, руководство по функциональной безопасности на систему (safety manual), процедуры периодических испытаний (proof test), а также документы управления функциональной безопасностью и планы аудита. При эксплуатации появляются журналы испытаний и отчёты о наработке, которые тоже нередко требуют перевода при смене оператора или подготовке к проверке.

Отдельно стоит выделить сертификаты SIL на оборудование от производителей датчиков, клапанов и логических контроллеров. Эти документы поставщик выпускает вместе с изделием, и в них указаны параметры, которые войдут в расчёт верификации на стороне заказчика: доля безопасных отказов, интенсивность отказов, интервал между испытаниями. Перевод сертификата должен точно воспроизводить эти значения, потому что на них строится доказательство достижения SIL для всей функции.

Каждый из этих документов насыщен числами и обозначениями, где ошибка переноса меняет смысл. Похожую плотность технических данных мы описывали в материале о переводе документации для оценки соответствия по ТР ТС 032 для оборудования под давлением: там, как и здесь, цена неточной цифры измеряется не редактурой, а риском на объекте. Аналогичная строгость к оформлению доказательной базы действует и при аккредитации испытательных лабораторий, о чём подробно в статье о переводе документации аккредитации по ISO/IEC 17025.

Терминология SIL: почему нельзя переводить по интуиции

Функциональная безопасность оперирует узким и жёстко определённым словарём. У большинства терминов есть закреплённые русские соответствия в серии ГОСТ Р МЭК 61508 и ГОСТ Р МЭК 61511, и отступать от них нельзя, даже если «своими словами» звучит понятнее. Проблема не в том, что вольный перевод непонятен, а в том, что он выводит документ из общего языка, на котором говорят проектировщик, оценщик и надзорный орган. Стоит одному термину сместиться, и стройная доказательная логика расчёта SIL превращается для проверяющего в набор приблизительных формулировок.

Несколько узлов, на которых чаще всего спотыкаются:

• SIF (Safety Instrumented Function) — приборная функция безопасности. Не «функция защиты» и не «предохранительная функция».
• SIS (Safety Instrumented System) — приборная система безопасности, в отечественной практике часто соотносится с системой ПАЗ.
• PFD (Probability of Failure on Demand) — вероятность отказа по запросу. Именно «по запросу», а не «при отказе».
• RRF (Risk Reduction Factor) — коэффициент снижения риска, величина, обратная PFD.
• Proof test — периодическое (контрольное) испытание, выявляющее скрытые отказы. Термин должен быть единым во всём пакете.
• SFF (Safe Failure Fraction) — доля безопасных отказов.
• HFT (Hardware Fault Tolerance) — отказоустойчивость аппаратуры.

Инструмент, который снимает разнобой, — двуязычный глоссарий проекта, согласованный до начала перевода. Он фиксирует английский термин, русское соответствие по ГОСТ и, при необходимости, пояснение. Без такого словаря один и тот же proof test в спецификации, в safety manual и в журнале испытаний легко получает три разных перевода, и связность пакета рушится. Бюро технических переводов iText ведёт подобные проекты именно от глоссария, а не от отдельных файлов, поэтому расчёт SIL и процедура его проверки читаются в одной системе понятий. Тесно связанная тема раскрыта в статье о переводе документации по функциональной безопасности SIL и систем ПАЗ, где показан разбор терминов на практике.

Согласование МЭК 61508/61511 с ГОСТ и требованиями РК

Международные стандарты МЭК 61508 и 61511 приняты в виде идентичных национальных переводов серии ГОСТ Р МЭК: части по общим требованиям, по требованиям к системам и к программному обеспечению, а для промышленных процессов — ГОСТ Р МЭК 61511. При переводе документации для казахстанского объекта важно, чтобы ссылки на международный стандарт сопровождались отсылкой к действующему в системе ГОСТ эквиваленту там, где это нужно органу по оценке соответствия или службе промышленной безопасности.

Функциональная безопасность вписана в более широкий контур промышленной безопасности Казахстана. Она регулируется законом «О гражданской защите», который устанавливает обязательные требования к опасным производственным объектам, декларированию безопасности и допуску технических устройств к применению. Практический пример стыковки: средства противоаварийной защиты подлежат внешнему осмотру не реже одного раза в сутки, и эксплуатационная документация, включая процедуры proof test, должна согласовываться с этим требованием по периодичности и порядку проверок.

Отдельный вопрос — как соотносятся расчётные показатели SIL с отраслевыми требованиями к оборудованию, которое сертифицируется по стандартам нефтегазовой отрасли. Логику такого сопоставления мы разбирали в материале о переводе документации для сертификации по стандартам API для нефтегазового рынка Казахстана. Переводчик, работающий с документацией SIS, должен видеть эту связку, а не переводить расчёт SIL в вакууме.

На практике это означает, что при переводе для объектов вроде газоперерабатывающих заводов, установок подготовки нефти или магистральных насосных станций нужно держать в поле зрения сразу несколько нормативных систем: международные МЭК, национальные ГОСТ, технические регламенты ЕАЭС и требования промышленной безопасности РК. Документ по функциональной безопасности редко ссылается только на один из этих источников. Задача перевода — сохранить каждую ссылку в узнаваемом для соответствующего читателя виде, чтобы инженер АСУ ТП, специалист по промбезопасности и эксперт органа по оценке соответствия видели знакомую им систему координат, а не набор чужих аббревиатур.

Типичные ошибки перевода документации функциональной безопасности

Ошибки в переводе документации SIS повторяются от проекта к проекту, и почти все они относятся к смыслу, а не к языку.

Первая — вольная передача терминов вероятности. «Вероятность отказа по запросу» (PFD) и «частота опасных отказов в час» (PFH) относятся к разным режимам работы функции, низкой и высокой частоты запросов. Спутать их значит поставить под сомнение весь расчёт. Вторая — потеря точности в числах и порядках величины. Значения PFD выражаются в виде малых чисел с показателем степени, и небрежность с порядком превращает SIL 2 в SIL 3 на бумаге.

Третья ошибка — рассинхрон терминологии между документами пакета. Когда спецификацию, safety manual и журнал испытаний переводят разные исполнители без общего глоссария, один термин расходится на несколько вариантов, и аудитор функциональной безопасности теряет нить. Четвёртая — перевод обозначений методов анализа (LOPA, HAZOP, FMEDA) описательно, вместо принятых сокращений, из-за чего документ выпадает из привычной для специалиста системы координат.

Пятая — игнорирование программной части. МЭК 61508 отдельно нормирует требования к программному обеспечению систем безопасности, и терминология жизненного цикла ПО (верификация, валидация, модульное тестирование) имеет строгие соответствия, которые нельзя подменять бытовыми синонимами.

Есть и шестой, менее очевидный промах: перевод, оторванный от контекста режима работы объекта. Одна и та же функция безопасности на установке непрерывного действия и на объекте с редкими запросами описывается разными показателями, и переводчик, не понимающий этой разницы, может «выправить» текст так, что он станет внутренне противоречивым. Поэтому документацию функциональной безопасности переводит не универсальный лингвист, а специалист, знакомый с логикой ПАЗ и АСУ ТП.

Практический ориентир для команды заказчика: при приёмке перевода стоит проверить сквозную связность одной выбранной функции безопасности по всем документам пакета. Если её обозначение, присвоенный SIL, значение PFD и интервал proof test совпадают в спецификации, в отчёте верификации и в safety manual, перевод сделан в едином контуре. Если хотя бы один параметр «поехал», это сигнал вернуть пакет на сверку до подачи в надзорные органы.

Как организовать перевод пакета SIS

Документацию функциональной безопасности бессмысленно переводить пофайлово в случайном порядке. Рабочая схема выстраивается по жизненному циклу безопасности.

Первый шаг — инвентаризация пакета и определение приоритетов: спецификация требований безопасности и отчёты классификации SIL идут первыми, поскольку от них зависят проектные решения. Второй шаг — сбор и утверждение глоссария вместе со специалистами по АСУ ТП и функциональной безопасности заказчика, с опорой на терминологию ГОСТ Р МЭК 61508 и 61511. Третий — перевод силами инженера-переводчика, который понимает разницу между режимами работы функции и умеет читать расчёт PFD, а не только текст вокруг него.

Четвёртый шаг — многоступенчатая проверка с обязательной сверкой всех числовых значений, показателей степени, единиц и обозначений SIL. Для документов, идущих в орган по оценке соответствия или в службу промышленной безопасности, добавляется финальный контроль соответствия оригиналу. Пятый — ведение памяти переводов и обновление глоссария, чтобы поздние документы наследовали утверждённые решения.

Формат тоже требует внимания. Расчётные таблицы, схемы контуров безопасности и диаграммы блокировок сохраняются с точностью до структуры, иначе привязка перевода к оригиналу теряется. Тот же принцип аккуратной работы с числовыми массивами и обозначениями действует при переводе документации автоматизированных систем управления в электроэнергетике, что показано в материале о переводе технической документации по системам SCADA.

Полезно заранее договориться с заказчиком о том, кто отвечает за проверку расчётных значений. Переводчик отвечает за корректный перенос цифр и обозначений один в один, но подтвердить, что сам расчёт SIL верен по существу, может только специалист по функциональной безопасности на стороне заказчика или независимого оценщика. Разделение этих зон ответственности, зафиксированное на старте, экономит недели на этапе аудита: перевод не пытаются превратить в экспертизу, а экспертиза не спотыкается о разночтения в терминах.

С чего начать по вашему проекту

Документация функциональной безопасности по МЭК 61508 и 61511 — это связанный пакет, где спецификация требований, расчёт SIL и процедуры испытаний должны говорить одними терминами и одними числами. Если ваша команда готовит проект АСУ ТП или модернизацию ПАЗ с импортной системой безопасности, начните с двух шагов: инвентаризации документов по жизненному циклу безопасности и согласования проектного глоссария на базе ГОСТ Р МЭК 61508 и 61511.

Бюро технических переводов iText специализируется на технической документации для промышленных объектов Казахстана и работает с пакетами функциональной безопасности как с единым терминологическим контуром, а не набором разрозненных файлов. Направление перевода для нефтегазовой отрасли закрывает документацию систем ПАЗ и АСУ ТП для перерабатывающих и добывающих объектов. Пришлите перечень документов вашего проекта SIS, и специалисты iText предложат план перевода с приоритизацией под сроки проектирования и оценки соответствия.