Когда на входе не готовое ТЗ, а неструктурированная задача: как я вёл механику съёмочной системы для «Детского Евровидения - 2018»

Есть проекты, после которых хорошо понимаешь разницу между инженером, который выпускает чертёж, и инженером, который отвечает за превращение сырой задачи в работающую конструкцию. Для меня одним из таких проектов стала разработка механической части операторской техники для проекта «Детское Евровидение - 2018» на площадке «Минск-Арены».

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

И именно этот проект для меня показателен не количеством выпущенных листов КД.

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

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

Вот эту часть работы на красивом рендере обычно не видно.

В рамках проекта разрабатывалась, в частности, роботизированная панорамная головка для киносъёмки и пульт управления. По исходным данным системы панорамная головка имела три оси вращения, отдельный контур стабилизации, восемь цифровых и один аналоговый канал управления, скорость вращения до 120 градусов в секунду. Рабочая нагрузка указывалась до 12 кг.

Но набор технических характеристик ещё не является конструкцией.

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

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

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

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

Именно поэтому я осторожно отношусь к формулировке «надо просто разработать КД».

Иногда разработать КД действительно означает оформить уже принятое техническое решение. Но в других проектах сначала ещё нужно это решение создать.

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

Ответ не очевиден. Руководитель проекта отвечает за интеграцию. Заказчик знает нужный результат. Производство знает свои ограничения. Но кто-то всё равно должен принять десятки связанных технических решений между этими точками.

Особенно хорошо это видно на пульте управления.

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

А дальше механика встречается с электроникой.

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

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

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

Вот почему в подобных проектах слово «компоновка» недооценено.

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

Компоненты помещаются. Механизм движется. Кабели проходят. Крепёж доступен. Деталь можно изготовить. Конструкцию можно собрать. Оператор может ею пользоваться. А сервисный специалист потом способен до нужного элемента добраться.

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

Отсюда один из выводов, который я вынес из этого и последующих проектов:

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

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

В инженерной работе легко перепутать носитель результата с самим результатом.

Файл CAD - носитель.

Сборочный чертёж - носитель.

Спецификация - носитель.

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

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

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

Мне кажется важным разделять эти два уровня, потому что предприятие в конечном счёте не покупает чертёж.

Оно покупает возможность изготовить изделие, собрать его, проверить и повторить результат.

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

То есть направление работы фактически обратное тому, как её часто воспринимают со стороны:

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

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

Так постепенно из неструктурированной задачи возникала инженерная система.

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

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

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

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

И второй вопрос уже к тем, кто сейчас заказывает подобные разработки: что для вас ценнее - исполнитель, которому можно выдать полностью готовое ТЗ, или инженер, которому можно принести ещё плохо структурированную техническую проблему и вместе получить из неё работающую систему?

Павел Самута. Белорусский инженер-механик, предприниматель и независимый технический партнёр с профессиональной практикой с 2007 года. Работаю на стыке инженерии, производства и экономики технических решений. Публикации в СМИ, статьи, видео интервью и экспертные комментарии об инженерии, промышленности, реверс-инжиниринге, импортозамещении, технологических рисках и производстве.