Один год работы инженером в Германии
В январе будет год как я начал работать инженером в небольшой фирме ESI ITI в Дрездене. Когда меня спрашивают чем занимается фирма, я обычно отвечаю, что она разрабатывает софт для инженеров под названием SimulationX. Конечно, мало кому это что-то говорит, да и невозможно описать это в двух словах. Сейчас, когда я стал более-менее понимать что происходит вокруг, я решил попробовать описать подробнее чем занимается наша фирма и в чём заключается моя работа здесь.
Начну издалека. Рассмотрим процесс создания технического устройства на примере автомобиля. Условно автомобиль можно разделить на три части: двигатель, шасси и кузов. В старые добрые времена за создание каждой части целиком и полностью отвечал один человек и всё замечательно работало, но прогресс не стоял на месте и постепенно к процессу создания одного автомобиля примазались тысячи (а то и сотни тысяч) человек! Зная народную мудрость „Что один человек сделает за час, то два человека сделают за два часа“, можно представить себе масштаб возникших проблем!
Давайте представим, что двигатель, шасси и кузов для какого-то абстрактного автомобиля изготовили разные люди, которые сидят в разных городах (или даже странах). Они заранее договорились о всех размерах, параметрах и характеристиках, каждый добросовестно изготовил свою часть и испытал её на специальных стендах. Это может показаться странным, но если просто так взять и собрать всё вместе, то с первого раза ничего работать не будет… Либо двигатель вывалится из кронштейнов, либо коробка передач внезапно начнёт трещать на неведомой частоте, либо подвеска выкинет какой-нибудь кульбит в самый неподходящий момент… И большая удача, когда выясняется это на испытаниях, а не в процессе эксплуатации.
Как правило, проблемы возникают в местах стыка компетенций инженеров различных областей техники. Разработчики двигателя и подвески приняли в своих расчётах, что кузов абсолютно жёсткий, разработчики трансмиссии забыли о неравномерности вращения вала двигателя, а разработчики кузова в погоне за красивыми формами убрали металл там, где не следовало. Очень редко находится человек, который обладает достаточными знаниями, чтобы видеть картину в целом и предвидеть все трудности. Проблема решается созданием единых стандартов и совершенствованием методик предварительных испытаний (поэтому сейчас редко можно увидеть двигатель, выпрыгивающий из кронштейнов), но стоит немного отойти в процессе разработки от протоптанной тропинки, как наступаешь на новые грабли.
Таким образом, работа инженера в области создания новой техники состоит из решения постоянно возникающих проблем, из которых львиную долю времени отнимают именно те, которые находятся на границах его компетенции. Гарантией того, что проблемы будут регулярно попадать на эти границы служит тот факт, что у фирм, как правило, нет возможности нанимать узкоспециализированных инженеров, которые месяцами будут просиживать штаны в ожидании своего звёздного часа. Поэтому инженер, обучавшийся конструированию, за неделю нарисует дифференциал, потом месяц будет думать как лучше приклеить датчики температуры, а потом на пару месяцев засядет за тепловым расчётом, пытаясь разобраться почему же ничего не работает (либо работает через раз).
В этот момент возникает идея ещё на этапе проектирования постараться предсказать возможные проблемы посредством математического моделирования. Конечно, идея эта не нова, ведь ещё наши прадеды писали математические модели на клочке бумаги, потом строили графики на миллиметровке и запускали по этим расчётам ракеты в космос. Да и сейчас нормальную мат. модель можно написать хоть в экселе, ну а владение тем же с++ просто сносит все границы.
Другое дело, с тем же с++ можно очень быстро утратить чувство реальности и уйти от решения конкретной технической проблемы в недры программирования. У тебя не работает агрегат, а ты в это время увлечённо изучаешь полиморфизм классов и get-функции… Аналогичная ситуация и с матлабом. Это очень мощный инструмент для научных исследований, но и требует довольно много времени на освоение и борьбу с непонятными глюками. Я и после пяти лет работы в матлабе не только регулярно открывал для себя что-то новое, но и натыкался на новые неведомые ранее ошибки… Для обычного инженера зачастую такое распределение времени будет считаться непозволительной роскошью.
Здесь появляемся мы и предлагаем программу SimulationX, в которой можно быстро и с минимумом головной боли собрать нужную математическую модель при помощи библиотек готовых элементов.
Представьте себе работу в матлабе с библиотеками Simscape, только так, что помещаешь нужные тебе элементы на форму, нажимаешь на кнопку и… всё с первого раза работает! А потом одним движением мышки взял… и вывел нужный тебе график! А потом взял и одним кликом сделал быстрое преобразование Фурье! А следом нажал ещё на одну кнопку и увидел все резонансные частоты, которые есть в системе и каким элементам они принадлежат! И всё это за один расчёт модели, без рекламы, скриптов и смс!
Звучит настораживающе, но в SimulationX на самом деле практически любое повседневное для пользователя действие совершается гораздо проще и быстрее, чем в матлабе. Кроме того, в SimulationX гораздо больше библиотек, а сами библиотеки гораздо богаче всевозможными элементами в сравнении с Simscape.
Возвращаясь к примеру с автомобилестроением: проектируете двигатель внутреннего сгорания? Вот вам библиотека с ДВС:
Ой, ДВС же сейчас у хипстеров не в моде… Вот вам электродвигатели:
Трансмиссия? На любой вкус!
Автомат с двойным сцеплением, например:
А здесь всё для гибридных трансмиссий:
Тормозная система:
Пневматическая подвеска:
И это всё только лишь на автомобильную тематику… Ещё есть дорожная и строительная техника, горное дело, железнодорожный транспорт, кораблестроение, авиация, машиностроение… и для каждой из этих отраслей у нас есть своя библиотека элементов, а то и не одна (не говоря уже о том, что программа позволяет быстро писать свои библиотеки на очень удобном языке Modelica).
Как же так получается? Вариантов „содрать библиотеку элементов с матлаба и впарить её оборонным предприятиям“ и „принудительно перевести на свой софт университеты под лозунгом импортозамещения“ в Германии нет, поэтому приходится просто работать…
Как ни странно, для того, чтобы в софте было удобно решать инженерные задачи, самим разработчикам нужно просто регулярно решать в нём инженерные задачи. Основной штат нашей фирмы - инженеры самых различных областей, которые на регулярной основе заняты в работе над сторонними проектами. Очень часто после проекта остаётся полноценная библиотека элементов, которая в большинстве случаев подтверждена многочисленными экспериментами и с большой долей вероятности может пригодиться кому-то ещё.
Другое очень важное наше преимущество - поддержка пользователя. Те, кто имел дело с математическим моделированием, наверняка ехидно ухмыльнулись на том моменте, где я рассказывал, что ты просто набрасываешь нужные тебе элементы и получаешь желаемую модель. Конечно, чтобы создать мат. модель даже из готовых элементов, нужно как минимум представлять какие элементы тебе нужны. Это не такая уж и тривиальная задача, как может сначала показаться. В зависимости, например, от интересующего тебя диапазона частот, вид модели может очень сильно отличаться. Одно дело, когда ты хочешь посмотреть в модели на расход топлива за двухчасовую поездку, а другое дело, когда ты хочешь изучить возможные колебания внутри трансмиссии, которые запросто могут уйти в килогерцовый диапазон.
Для того, чтобы сделать правильный выбор, нужно обладать опытом решения подобных задач, который в достатке имеется у наших инженеров. Пользователь может написать свой вопрос на специальном сайте и в течение нескольких рабочих часов получить исчерпывающий ответ с формулами, иллюстрациями и работающей моделью. Быстрая и качественная поддержка - главное наше конкурентное преимущество в Германии по сравнению с другими хорошими CAE-программами, чьи разработчики сидят в других странах или вообще на других континентах.
Конечно же у нас есть отдел гидравлической и пневматической техники, в котором я и работаю. Первое время я вникал в саму программу (потому что до этого работал в ней только студентом), в систему исправления багов (узнал, про тонкую грань между „багом“ и „фичей“) и в то, какими проектами занимаются остальные инженеры и практиканты.
Т.к. последнее, чем я занимался в МГТУ им. Баумана, были волновые процессы в трубопроводах, меня определили разбираться с моделями труб, которые, честно говоря, оставляли желать лучшего… Сами модели были написаны очень подробно и обладали большим набором параметров (моделируй хоть трубу, хоть рукав высокого давления, с учётом теплообмена или без), но проблема была в том, что применяемая схема дискретизации очень плохо годилась, например, для расчёта гидроудара.
Я сразу предложил написать модель, где задача решалась бы другим численным методом, но как выяснилось, софт так не разрабатывается… На это нужно время, время стоит денег, а деньги должен кто-то дать. Поэтому около месяца я потратил на то, чтобы выжать максимум из той модели, что уже есть и на передачу своего опыта клиентам, обращавшимся за помощью.
Тем не менее, меня гложила эта ситуация, и в свободное от срочной работы время я принялся втихаря писать новую модель трубы. Мне нужно было всего лишь повторить ту модель, которую я уже писал в МГТУ в матлабе, поэтому через пару недель у меня уже был работающий прототип. Он уже мог решать конкретные задачи, которые не могла решать старая модель, но не годилась для трубопроводов с низким давлением и не учитывала теплообмен. По этой причине, модель едва ли продвинулась бы дальше моего рабочего компьютера. Я уже стал копать в направлении более продвинутых численных методов для этой задачи, вышел на метод Годунова, выяснил, что наш штатный математик уже использовал его для решения задачи с электрической дугой, стал разбираться в его коде на c++… и так и погряз бы в этом, если бы в один прекрасный момент к нам не обратился наш клиент с типовой проблемой со старой моделью трубы…
Это был производитель плунжерных насосов, который хотел в нашей программе считать пульсации в трубопроводах. Я решил подбросить ему свою модель, т.к. работал он как раз в области больших давлений. К моему удивлению, ему удалось получить какое-то фантастическое совпадение с экспериментом при том, что модель считалась гораздо быстрее, чем прежняя. Кроме того попутно удалось исправить несколько багов и понять где нужно поставить пользователю „забор“, чтобы он не выходил за рамки выбранных допущений.
В последствии я отсылал эту модель ещё нескольким клиентам, и все были очень довольны результатом. В итоге начальник дал добро на добавление моей модели в стандартную библиотеку элементов в новую версию программы, чему я конечно же был очень рад.
В качестве заключения могу сказать, что когда я работал студентом на кафедре Дрезденского технического университета, у меня складывалось впечатление, что в Германии уже ничего нельзя существенно улучшить и остаётся только вылизывать и без того совершенные машины. Это на несколько лет сильно вдохновило меня на работу в России, которая представлялась непаханным полем. Теперь, имея какой-никакой опыт работы, у меня составлен длинный список из необходимых усовершенствований (среди которых и совершенно непаханные в нашей фирме области), которые нужно внести в нашу (казалось бы и без того совершенную) программу или в документацию.
Из приятных мелочей радует спокойный ритм работы (без сроков „вчера“), практически полное отсутствие бюрократии и формальной работы лишь ради производства бумажек (работаешь ты всегда с конкретными инженерами, которых интересует прежде всего решение конкретной технической проблемы). Ну и конечно же я постоянно убеждаюсь в том, что Германию населяют такие же люди как и в России со всеми достоинствами и недостатками, отличаются только правила, по которым они живут.
Поэтому я уверен, что когда-нибудь (когда зарабатывать честным трудом станет выгоднее, чем воровать) и в России сложится похожий климат для продуктивной и эффективной работы инженером.