Как СИБАЗС проектирует топливные системы ЦОД и ДГУ: ТХ и АТХ

В проекте ЦОД топливная система не существует сама по себе. Размещение оборудования, резервуары, трубопроводы, электроснабжение, автоматизация, строительные решения, системы безопасности и диспетчеризация связаны между собой. Решение, принятое в одной части проекта, может потребовать изменений сразу в нескольких других.

Поэтому в СИБАЗС мы рассматриваем проектирование топливной инфраструктуры не как выпуск отдельного комплекта чертежей, а как работу с единым инженерным контуром, который должен быть последовательно встроен в общий проект объекта.

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

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

Именно поэтому мы начинаем не с шаблонного набора работ, а с определения исходной точки конкретного проекта.

Сначала определяем, в какой точке находится проект

Первый вопрос — не «какое оборудование поставить», а что уже сделано и какую задачу необходимо решить сейчас.

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

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

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

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

Для PM или технического заказчика это важная точка: становится понятно, что именно должно происходить дальше и какой объём работ действительно требуется проекту.

Не начинаем детальную разработку, пока не понимаем исходные условия

Качество инженерного решения напрямую зависит от качества исходных данных.

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

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

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

Поэтому мы стремимся выявить критические ограничения до того, как они окажутся уже внутри разработанной документации.

Дорожная карта прямо фиксирует результат этого этапа: проверенная исходная база, достаточная для разработки обоснованных проектных решений.

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

Сначала формируем принципиальное решение, потом детализируем его

Мы разделяем принятие принципиальных решений и их последующую рабочую детализацию.

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

Здесь особенно важно, чтобы отдельные инженерные решения складывались в одну систему, а не существовали как независимые разделы документации.

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

Поэтому для нас корректность отдельного решения ещё не означает корректность проекта в целом. Этот принцип прямо заложен в дорожную карту проектирования СИБАЗС.

Именно на этом уровне особенно важна работа со смежными проектировщиками.

ТХ и АТХ проектируем как две связанные части одной системы

После фиксации принципиальных решений начинается детальная разработка рабочей документации.

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

АТХ — автоматизация технологических процессов — отвечает за то, как эта технология контролируется и управляется.

В зависимости от конкретного объекта в АТХ прорабатываются контроль технологических параметров и состояния оборудования, предупредительные и аварийные сигналы, управление исполнительными механизмами, блокировки, алгоритмы работы и аварийных событий, КИПиА, щиты управления, внешние соединения и взаимодействие с другими системами управления объектом.

Для нас принципиально важно не рассматривать ТХ и АТХ как два изолированных комплекта документации.

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

Именно поэтому на странице услуги мы говорим о проектировании ТХ и АТХ топливной системы, а не просто о выпуске двух формально отдельных разделов.

Отдельное внимание — стыкам со смежными разделами

Значительная часть сложностей реального проекта возникает не внутри ТХ или АТХ, а на границах между ними и другими инженерными системами.

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

Это не дополнительная формальность после завершения проектирования.

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

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

Дорожная карта отдельно отмечает, что значительная часть коллизий при реализации возникает именно на этих стыках.

Поэтому одна из задач нашей команды — не просто разработать собственный раздел, а своевременно обозначать необходимые интерфейсы и исходные данные для смежных участников проекта.

Руководитель проекта должен понимать не только документацию, но и состояние работы

Инженерная глубина проекта необходима профильным специалистам. Но PM или Product Owner управляет не отдельными трубопроводами и датчиками — он управляет сроками, участниками, зависимостями и результатом проекта.

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

Для каждого этапа должны быть понятны:

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

Именно эту задачу мы внутри СИБАЗС называем общим языком с проектной командой.

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

Такой подход вырос из отдельной работы СИБАЗС по адаптации собственной технической экспертизы под логику PM и Product Owner: входные данные, риски, ответственность, результат и формат взаимодействия рассматриваются нами как часть нормальной организации инженерного проекта, а не как дополнительная презентационная оболочка.

Согласование — не финальная проверка независимых разделов

Проектные решения проходят согласование с заказчиком и другими участниками, а в предусмотренных случаях — необходимые экспертные процедуры.

Но наша задача состоит не в том, чтобы впервые обнаружить взаимные противоречия уже на этой стадии.

Чем позднее выявлена проблема в принципиальном решении, тем больше связанных элементов она может затронуть.

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

Поэтому согласованность решений закладывается до их выдачи, а не создаётся постфактум в ответ на замечания. Такой принцип закреплён и в дорожной карте СИБАЗС.

Проектирование для нас не заканчивается выпуском документации

Рабочая документация должна быть пригодна не только для проверки или архива проекта. Она становится инструментом для закупки оборудования, комплектации, монтажа и дальнейших пусконаладочных работ.

И здесь особенно заметна ценность того, что СИБАЗС занимается не только проектированием.

На текущей странице направления мы предлагаем полный цикл по топливным системам ЦОД и ДГУ: проектирование, поставку оборудования, монтаж, модернизацию и сервис. При этом можем подключаться и только на необходимом заказчику этапе.

Это позволяет смотреть на решения не только с позиции «как их оформить в проекте», но и с позиции дальнейшей реализации.

В зависимости от состава конкретной задачи работа проектировщиков может продолжаться и после выпуска документации — при комплектации, строительстве и монтаже в формате предусмотренного сопровождения.

Так, в рамках авторского надзора изменения, возникающие на площадке, оцениваются не изолированно, а с точки зрения их влияния на общую инженерную систему. Дорожная карта приводит характерные связи: перенос оборудования влияет на трубопроводы, конструкции и кабельные трассы, а замена средств автоматизации может потребовать пересмотра подключения и алгоритмов работы.

Если проект уже разработан, не начинаем всё заново

Отдельный сценарий — когда заказчик приходит к нам не в начале проекта.

Например, топливная часть уже разработана полностью или частично, но требуется её корректировка, детализация, подбор и поставка оборудования либо дальнейшая реализация.

В этом случае логика остаётся той же, меняется стартовая точка.

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

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

Что в итоге означает наш подход

Для СИБАЗС проектирование ТХ и АТХ — это не задача «выпустить два раздела».

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

При этом для проектной команды мы стараемся сохранять прозрачную логику:

что является исходной точкой → какие данные нужны → какое решение принимается → с какими разделами оно связано → что необходимо согласовать → какой результат передаётся дальше.

Так техническая глубина остаётся внутри инженерной работы, но сама топливная часть становится понятным и управляемым контуром общего проекта.

Именно этот подход мы считаем одной из ключевых составляющих своей экспертизы в проектах топливной инфраструктуры для ЦОД и ДГУ.