Меня зовут Алексей Ильичев, я программный инженер по образованию. Во время обучения работал на фрилансе в зоне фронтенда. И получил предложение заняться бэкендом в части разработки плагинов для САПР (систем автоматического проектирования) AVEVA для нефтяных платформ. Мне в моменте стало интересно, и все, за уши не оттянешь. 

Сейчас я работаю в управлении инженерными данными в Цифровом СИБУРе. Когда строят крупный завод, все его системы сначала проектируют в 3D-модели: трубопроводы, оборудование, арматура (задвижки, клапаны, вентили, все, чем можно перекрыть поток), кабельные трассы, эстакады. Каждый объект в модели должен быть проименован, то есть назначен идентификатор в виде тега. 

Тег — это уникальное имя, сформированное по специальным правилам, по которому объект потом найдут на реальном заводе, включат в реестр обслуживания, загрузят в систему управления инженерными данными – наша внутренняя разработка. Без тегов 3D-модель просто геометрическая болванка, которую можно использовать только в качестве опорной модели, от которой на стройке нет толку.

Подрядчики у нас российские и международные: Китай, Корея, Индия и т.д. Каждый проектирует свой кусок завода в 3D, либо определенные уникальные комплектные поставки технологического оборудования, потом присылает модель на проверку. Моя задача — проанализировать и выдать экспертизу по входящим моделям на их соответствие проектным процедурам и требованиям компании. Как пример, наличие тегов, отсутствие коллизий, иерархия модели, LOD (level of detail) уровень детализации и т.д.. 

Коллизия — это когда труба проходит сквозь стену или насос стоит там, где уже проложен трубопровод. Если выявлены проблемы в 3D, выдаю замечания. Подрядчик исправляет, присылает следующую ревизию. Итерации продолжаются, пока модель не станет соответствовать требованиям всех инженерных дисциплин.

Я тщательно анализирую каждую входящую модель. При первичном анализе проверяю систему координат в 3D и позиционирование модели, соответствие 3D модели заявленному оборудованию, которое будет поставлено на площадку. Бывает, что на базовых вещах сразу видишь проблему. Потом подключаю автоматику. У нас разработаны плагины, которые собирают все теги из проекта, проверяют на соответствие маскам (это маска именования, где зашиты WBS/PBS код, номер установки, функциональный код среды, классы и т.п.). На выходе мы получаем результирующий Excel со списком проблем. Но полностью положиться на автоматику нельзя.

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

Система может найти миллионы коллизий, в зависимости от допущений, а половина из них допустимые.

Их разделить на 3 типа критичности коллизии. 

H - Hard, S - Soft. 

Эти обозначения знакомы тем, кто работал в программных продуктах AVEVA.

H x H недопустимая коллизия

H x S коллизия требующая анализа проектировщиков

S x S допустимая коллизия

Например, труба проходит через ограждение площадки, которое на стройке просто подрежут. Данная коллизия у нас относится к S x S, а значит допустима и не является ошибкой.

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

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

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

Модель лежит на боку

Зарубежный подрядчик присылает 3D-модель на рассмотрение. Мои коллеги идут проверять реестры тегов и документы, а я открываю 3D. И вижу, что модель не спозиционирована по координатам. Ориентация модели нарушена при выгрузке в обменные форматы и модель фактически "перевернута".

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

И тут иногда понимаешь, что при работе с международными компаниями менталитет сильно разнится. Что для российской компании - требование по договору - 100% исполнимо, то для зарубежных не так. Чаще всего получаем статистику 80:20. Подрядчик выполнил 3D по договору на 80%, а остальные 20% "как-нибудь сами". Ответ: «Так это же очень легко сделать». Ну а что тут ответишь? Если легко, так сделай. Мы за это платим.

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

Теги выгрузили, а проверить забыли

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

Поставщик выгружает модель в STEP. Не проводит проверку полученной модели обменного формата. Присылает нам, мы открываем — тегов нет.

– Ребята, а где теги? 

– Вот, у нас все есть (скриншот)

– У вас все хорошо, я понимаю, а нужно, чтобы теги перенеслись на сторону Заказчика

И начинаешь объяснять базовые вещи. Формат STEP — текстовый. Его можно открыть в блокноте и посмотреть, есть там теги или нет. Можно скрипт написать, можно хоть руками добавить. Из всех поставщиков, с кем я работал за все это время, из их 3D-специалистов об этом никто не знал. У нас в планах написать методичку для Подрядчиков с инструкциями, как в каждом различном ПО, используемом в российском секторе, вносить теги в 3D.

Русская «С» вместо латинской

Пару раз столкнулись с кейсом, когда тег визуально выглядит правильно, но не проходит проверку скриптом. Смотришь визуально, все корректно, а система не находит совпадения с данным тегом.

Выясняется, что внутри тега сидит невидимый символ каретки, а еще были и символы из разных кодировок, которые ломали Excel. Или одна из латинских букв на самом деле кириллическая, русская «С» вместо английской «C». Глазами не отличишь.

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

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

— Зачем вы вообще так делаете?

— Потому что у нас зашиты каталоги и плагины на наши именования в 3D, а с "Вашими" кавычками ничего не работает.

— Тогда сделайте копию проекта. Себе оставляйте хоть с тройными кавычками. Нам отдайте как правильно.

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

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

Насос есть, а геометрии нет

Подрядчик прислал модель, где не были протегированы шкафы. Мы выдали замечание. Он присылает следующую ревизию, все протегировано, замечание снято. Но я знал, что подрядчик не самый добросовестный, и чуял, что что-то не так. Решил перепроверить глазами, а не только автоматикой.

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

Зачем они так делают? Чтобы закрыть платежную веху (этап сдачи, после которого подрядчик получает деньги за выполненный объем). Через неделю сдавать, специалист, который должен рисовать эти насосы, будет делать это месяц. Создают пустышку, проходят проверку, получают деньги. А насос якобы добавят потом. На практике никто не добавляет, если не ловить за руку.

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

«По техническим причинам не можем сделать скриншот»

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

У коллег был зарубежный подрядчик, не наш прямой. Ему прислали проект, выполненный другим подрядчиком в другой системе. Зарубежные подрядчики заявили, что проект нерабочий, модель «explose» (взорвана, элементы разлетелись). Требовали, чтобы заказчик сам выгрузил чертежи за них.

Менеджеры высшего звена не погружены в тонкости разного ПО и им необходимо знать, подрядчик намеренно лжет, чтобы не выполнять объем работ им или действительно на проекте есть проблемы. Мне присылают проект, я смотрю — все нормально. По логам вижу, что проект делал мой бывший коллега из другой организации, ответственный специалист. Я с ним работал в данном САПР и уже на стадии открытия проекта понимал, что навряд ли он допустил бы такие проблемы в проекте.

Назначаем встречу с подрядчиком. Спрашиваем: коллеги, расскажите, в чем проблема. Подрядчик сходу продавливает менеджеров, что проект нерабочий, зона ответственности не их и т.д.. Я включаю микрофон: подключите к нам вашего 3D специалиста, чтобы убедиться в проблематике. После непродолжительного диалога с их специалистом понимаем, что это просто политика поведения подрядчика - уклониться от работ. После нашей проверки с двух инстанций мы видим, что проект в порядке.. Подрядчик: «Ну, у нас не работает, в общем».

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

Долгая заминка. «По техническим причинам не можем включить демонстрацию экрана».

Ладно, давайте скриншоты. Посидим, разберемся по скриншотам.

По техническим причинам не можем сделать скриншоты.

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

За все время, сколько я работаю, обычно все решается после фразы «включите демонстрацию экрана и продемонстрируйте проблему».

Подрядчик ни при чём

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

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

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

«Алексей Алексеевич, все сделаем»

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

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

– О, Алексей Алексеевич, добрый день! 

– Что у вас тут? 

– Такое-то оборудование .

– Требования помните? 

– А такие же, как на прошлом проекте?

– Такие же.

– Все, Алексей Алексеевич, все сделаем.

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

Сроки горят, а 3D стоит

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

Поэтому в проектных процедурах изначально зафиксированы требования, чтобы максимально покрыть большинство потребностей площадок. И мы прекрасно понимаем, что не везде требуется высокая детализация. Например, дисциплины ОВКВ. Очень часто мы не требуем моделировать и тегировать внутри приточных установок вентиляторы и компрессоры. Подрядчик прислал 3D-модель противопожарной системы, мы начали гонять по ней, а сроки горят. Подрядчик говорит, что не успевает.

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

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

Истина где-то рядом или как я пальцем тыкал в их экран

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

Объяснил, как выглядит структура файла, как вносить теги вручную, если не получается через систему. Они же сами подписали договор, подписались под работой. Google, YouTube, пожалуйста, вперед. Надо брать деньги за полезные уроки.

Один раз подрядчик дошел до того, что утверждал: у него нет технической возможности проименовать объекты в 3D-модели. Закидывали друг друга официальными письмами, подключали юристов. Но именование объектов — базовая функция в любой системе проектирования, это все равно что сказать «мы не можем создать папку на компьютере». После долгих переписок подрядчик обязался выполнить контрактные обязательства и сейчас их выполняет.

Пять проектов за спиной, а тендер надо брать

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

Подписывайтесь на наш тг-канал. Он полезен айтишникам, которые хотят понять, что реально происходит в промышленном ИТ.

Там мы рассказываем о цифровых технологиях для производства — от IIoT и аналитики до инженерных инструментов и ИИ. Делимся кейсами, экспериментами, новостями и выкладываем вакансии.