Перевод документации по автоматизированным системам управления (АСУ ТП): что важно учесть на промышленных объектах Казахстана

Системы отопления и вентиляции на Атырауском НПЗ управляются микропроцессорными контроллерами Yokogawa Centum CS 3000. Это распределённая система управления, и за ней стоит документация, без которой завод не запустить и не обслуживать: описания алгоритмов регулирования, конфигурации контроллеров, перечни сигналов, инструкции оператору. Когда такой объект модернизируют, а интегратор вроде казахстанской iQS Engineering сводит воедино приборную часть, систему управления и связь, весь этот массив нужно перевести так, чтобы инженер КИПиА, программист ПЛК и оператор за пультом понимали текст одинаково.

Документация по автоматизированным системам управления технологическими процессами (АСУ ТП) стоит особняком среди технических текстов. Это не руководство к одному прибору и не контракт, а описание живой системы, которая управляет насосами, печами, задвижками и реакторами в реальном времени. Ошибка в переводе тега сигнала или порога срабатывания защиты здесь не косметическая: она может привести к неверной настройке системы и аварийному останову. Ниже разберём, из чего состоит документация АСУ ТП, почему уровни системы важны для переводчика, какие стандарты нельзя трогать наугад и как выстроить перевод на промышленном объекте в Казахстане.

Что входит в документацию АСУ ТП

АСУ ТП описывается комплектом, который складывается из нескольких слоёв. На верхнем уровне идёт проектная документация: техническое задание на систему, пояснительная записка, функциональные схемы автоматизации, структурная схема комплекса технических средств. Ниже располагается то, что нужно для наладки и работы: описание алгоритмов управления и блокировок, конфигурация контроллеров, перечни входов-выходов (I/O lists), таблицы сигналов и уставок.

Отдельный пласт связан с интерфейсом оператора. Это описания мнемосхем (экранов SCADA или HMI), перечни сообщений и аварийных сигналов (alarm lists), инструкции оператору и регламенты действий при отклонениях. Сюда же примыкает документация по связи и протоколам обмена, описания интеграции с MES и системами верхнего уровня.

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

Уровни АСУ ТП и почему это важно для перевода

АСУ ТП устроена по уровням, и понимание этой структуры напрямую влияет на качество перевода. На нижнем, полевом уровне находятся датчики и исполнительные механизмы: термопары, расходомеры, клапаны, приводы. Следующий уровень — контроллеры (ПЛК) и распределённые системы управления (DCS), которые собирают сигналы и исполняют алгоритмы. Выше располагается уровень оперативного управления: серверы SCADA и рабочие места операторов с мнемосхемами. На верхнем уровне работают системы планирования производства, MES и связанные с ними приложения.

Эта иерархия задаёт терминологию. Слово «контроллер» на полевом уровне и на уровне DCS значит разные вещи, а сигнал может называться по-разному в зависимости от того, на каком уровне он описан. Переводчик, не представляющий архитектуру системы, склеивает уровни в кашу, и текст перестаёт быть рабочим. Особенно это заметно при переводе описаний обмена данными: протоколы вроде OPC UA и MQTT соединяют оборудование разных производителей, и их названия и термины интерфейсов не переводятся вольно, а сохраняются в принятом виде.

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

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

Теги, уставки и интерфейс оператора

Самая аккуратная часть работы — перевод того, что видит и с чем работает оператор. Мнемосхема SCADA или HMI содержит названия аппаратов, единицы измерения, обозначения состояний (открыто, закрыто, авария, в работе). Подписи на экране должны быть короткими и однозначными: оператор реагирует на них в момент, когда нет времени разбираться в формулировке.

Здесь несколько типичных трудностей. Теги сигналов часто построены по заводской системе кодирования и не переводятся вообще, переводится только их расшифровка, и важно не перепутать одно с другим. Уставки (setpoints) и пороги срабатывания идут с конкретными числами, и при переводе перечня уставок проверка значений и единиц обязательна: подмена бар на килопаскали или градусов Цельсия на Фаренгейт меняет режим работы. Сообщения об авариях должны соответствовать тому, что заложено в логике контроллера, иначе оператор увидит на экране одно, а система отработает другое.

Терминология интерфейса требует единообразия в пределах всего проекта. Если на одном экране стоит «насос остановлен», а на другом «насос выключен» для того же состояния, оператор начинает гадать, есть ли разница. Чтобы этого не было, мы фиксируем словарь состояний и сообщений в начале работы и прогоняем через него все экраны. Эта же дисциплина нужна при переводе регламентов обслуживания, о чём мы писали в статье про перевод регламентов технического обслуживания и ремонта.

Чтобы задать ориентир, приведём базовый набор соответствий, который мы закрепляем в глоссарии АСУ ТП на старте: PLC — программируемый логический контроллер; DCS — распределённая система управления; SCADA — система диспетчерского управления и сбора данных; HMI — человеко-машинный интерфейс; I/O list — перечень входов-выходов; tag — тег (сигнал); setpoint — уставка; interlock — блокировка; trip — аварийный останов; alarm — аварийный сигнал; field level — полевой уровень. За каждым из этих понятий стоит конкретная функция системы, и подмена даже одного слова в перечне сигналов сбивает наладку. Когда соответствия согласованы с инженерами завода и зафиксированы, переводчики и редакторы перестают трактовать их по-своему.

Стандарты, которые нельзя переводить наугад

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

Структуру и состав документации на автоматизированные системы в постсоветской инженерной практике задаёт серия ГОСТ 34, по ней оформляют техническое задание и проектные документы. Языки программирования контроллеров описывает международный стандарт IEC 61131-3, и его обозначения языков (LD, FBD, ST, IL, SFC) в тексте остаются как есть. Кибербезопасность промышленных систем регулирует семейство IEC 62443, разработанное комитетом ISA99 и принятое МЭК. Стандарт делится на четыре группы документов: общие концепции, политики и процедуры, требования к системе и требования к компонентам, а уровни защищённости обозначаются как SL 1–4. К этому добавляются требования функциональной безопасности по линии IEC 61508 и её отраслевого применения для процессных производств.

При переводе важно различать, какой стандарт за что отвечает. IEC 62443 — это про защиту от кибератак, а функциональная безопасность — про предотвращение опасных отказов, и смешивать их нельзя. В Казахстане кибербезопасность промышленных объектов стала самостоятельной темой, и документация по защите АСУ ТП проходит отдельное согласование. Переводчик, который не отличает уровень защищённости SL от уровня полноты безопасности, наделает ошибок в тексте, который потом ляжет в основу аттестации системы. Поэтому стандарты мы отдаём специалистам с инженерным бэкграундом, а не переводчикам общего профиля.

Импортное оборудование и состав поставщиков

На казахстанских объектах работают системы разных производителей, и это определяет источник документации. В нефтепереработке и металлургии распространены DCS от Yokogawa, Honeywell, Siemens и других вендоров, а Атырауский НПЗ, как уже упоминалось, использует решения Yokogawa Centum. Документация от этих поставщиков приходит на английском, и в ней свой устоявшийся набор терминов, который нужно знать, а не изобретать заново.

У каждого вендора своя система обозначений и своя структура руководств. Yokogawa, Honeywell и Siemens называют одни и те же по сути функции разными фирменными терминами, и при переводе их нельзя усреднять до «общепонятных» слов: инженер по наладке ищет в тексте именно вендорское обозначение, чтобы найти его в самой системе. Поэтому при переводе документации DCS мы держим отдельный словарь под конкретного производителя и не смешиваем терминологию разных вендоров в одном проекте, даже если на объекте стоит оборудование нескольких марок.

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

Масштаб документации на крупных промышленных предприятиях измеряется не сотнями, а тысячами и десятками тысяч страниц. Опыт работы с большими индустриальными заказчиками показывает, насколько критична здесь единая терминология: на проекте перевода для Eurasian Resources Group объём составил миллионы страниц, и без централизованного глоссария такие объёмы рассыпаются на несогласованные куски. Подробности этого проекта собраны в кейсе о партнёрстве с ERG. АСУ ТП на таких объектах — лишь часть общего массива, но часть, к которой требования по точности одни из самых высоких.

Как организовать перевод документации АСУ ТП

Перевод АСУ ТП окупается тогда, когда система выстроена до начала работы, а не правится по ходу. Порядок, который мы применяем на промышленных объектах, выглядит так.

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

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

Чего стоит избегать: перевода перечней сигналов без понимания архитектуры, вольного перевода тегов и обозначений стандартов, разрозненной работы над экранами оператора без общего словаря состояний. Каждая из этих ошибок проявляется при пусконаладке, когда система уже на объекте и цена правки максимальна. Этот тип документации нередко пересекается с цифровизацией энергосетей и диспетчерских систем, смежные подходы мы рассматривали в обзоре про перевод проектов smart grid.

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

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

Что делать дальше

Автоматизация промышленных объектов Казахстана идёт волной: модернизируются НПЗ, обновляются металлургические производства, на новых линиях ставят современные DCS и SCADA. Тему модернизации заводов мы разбирали отдельно в материале про перевод документации для модернизации НПЗ в Атырау, Павлодаре и Шымкенте. За каждым таким проектом стоит документация АСУ ТП, от точности которой зависит и безопасность пусконаладки, и устойчивость работы системы.

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