суббота, 19 марта 2011 г.

Куда дует ветер?


              Окинул взглядом написанные посты и понял, что в списке тегов не достает тега «Teamcenter». Серьезное упущение, поскольку в последнее время главным образом ковыряюсь именно в нем. Настал момент открыть новую тему, глубокую и бесконечную, как и жизненный цикл продукта. Логично начинать с начала, с него и начну. Короткая история о том, как я «вляпался» в Teamcenter.
                Был обычный московский день, и ничто не предвещало ничего необычного. На улице свирепствовал декабрь, заметая город. Город уже проявлял тяжелые симптомы предновогодней лихорадки. Разговоры о подарках, о том, где встречать 11-й, в Финляндии или в ближайшем подъезде, какой салат приготовить, кто что будет пить и т.д. Собственная определенность в этом отношении позволяла мне работать, не отвлекаясь на такие мелочи. Я измывался над синхронной технологией подкидывай ей одну задачку за другой, все более усложняя пресловутый «замысел конструктора». В общем, обычный день, каких 200 с лишним бывает в год. Тогда я и не подозревал, что где-то через пару комнат от меня в глубинах сознания моей начальницы (знакомьтесь, Наталья, менеджер по работе с партнерами, также с гордостью носит имя «куратор направления Velocity») зародился план, суливший мне большие перемены.
                План назывался кросс-экспертиза, что по-русски значит расширение специализации, или проще - изучение дополнительного продукта. Основная цель всей затеи заключается в том, что если заказчику нужен не только Solid Edge, но и еще что-нить из Velocity, то не очень эффективно таскать двух специалистов по командировкам. На выбор было три продукта: CAM Express, Femap и Teamcenter. Я сразу же расставил для себя приоритеты:
1.       CAM Express – отпадал сразу по личным причинам. «Любовь» к технологии мне привили еще в универе. Преподаватели были умудренные всяческим опытом (кроме, пожалуй, уважения к студентам и их мнению) старцы, которые своими методами напрочь отбили у меня интерес к данной дисциплине как таковой. Они всегда были правы, находя этому любые возможные (а порой и невозможные) объяснения. Спорить с ними было все равно, что доводить отливку из Ст 3 до шероховатости Ra 0,8 языком. Справедливости ради надо также отметить, что технологию я изначально не очень любил, поскольку у меня к ней были претензии философского характера. Конструктор может придумать конструкцию, совершенную, идеальную, функциональную и красивую, но произвести ее невозможно, технологи обламывают весь кайф! Я осознаю, что первопричина все-таки технология (если не копать глубже), а не технологи, но не все в подсознании поддается логическому обоснованию.
2.       Teamcenter PDM/PLM система. На тот момент я практически не имел опыта работы с PDM системами. На Туполеве в ней не нуждались, на Икаре была Катия под VPM’ом (кажется так называлась система). Работая на Икаре я знал несколько команд: check-in, check-out, поиск, log-on, log-off и все в таком роде. Зачем все это – меня не особенно интересовало, моделирование захватывало куда больше. Что случалось с данными после того как я делал check-out меня не волновало совершенно. Поэтому ни пользы, ни практической выгоды от использования систем такого класса я не понимал, и, само собой, мысль, что придется убеждать кого–то в преимуществах этих программ, значительно обескураживала.
3.       Femap – казался мне наиболее понятным. Создал модель, приложил нагрузки и закрепления, сгенерил сетку, произвел расчет на основе КЭ, проанализировал результаты – сидишь и радуешься! Я догадывался, что и здесь есть нюансы (куда ж без них), но они пугали меня гораздо меньше, чем в предыдущем случае. Таким образом, мой выбор первоначально пал именно на Femap.
К вопросу подключился и наш специалист всея CAE, т.е. менеджер CAE направления SPLMS, Павел. Он тут же заявил, что он «будет только за, если весь офис будет продвигать Femap». Вопрос казался уже практически решенным: низы хотели, верхи были не против. Однако, то ли изменчивая питерская погода (именно в городе на Неве располагается наш генштаб CAE-фронта) накладывает отпечаток на характер жителей города, то ли при более глубоком анализе ситуации проявились весьма веские причины, и через пару недель верхи немного изменили свою позицию… на противоположную.
Страх неизвестности, самый сильный из человеческих страхов, с новой силой принялся терзать мой беспокойный ум. Я стал много и плохо спать, производительность труда падала, мороженное и шоколад уже не казались такими вкусными, все простые радости жизни становились проще и блекли одна за другой. Сжалившись надо мной, Наталья, созвала совет, который в мою личную историю вошел как «Совет в переговорке».
В совет вошли все люди, наиболее обеспокоенные моим будущим, как специалиста. Каждый высказался. В целом все свелось к следующему: компаниям чаще требуется сочетание SE+Tc (нежели SE+Femap); мне полезнее будет изучать Tc, т.к. это позволит расширить мои знания о бизнесе SPLMS (а именно, PLM-софт и услуги); учить меня из Питера не очень удобно; либо ты отдаешься CAE полностью, либо вообще не трогай его. Может еще что-то было, но эти тезисы главные. В общем, все склонялись к Тс. В конце и мне предоставили последнее слово (как во всех цивилизованных обществах J). Выбор был прост: первый вариант – согласиться с Тс; вариант второй - упершись рогом, рвать на себе рубашку, настаивать на Femap, спорить, возражать и согласиться с Тс. Надо ли говорить, что я выбрал первый вариант. Определившись, я вздохнул свободно, и жизнь обрела прежнюю яркость и смысл.
Все написанное ранее – лирика, и если у Вас хватило упорства дочитать до этого момента, то сейчас Вы узнаете, что значит вопрос в заголовке блога. Немного поясню его: речь прежде всего идет о первоочередных потребностях российской компании, решившей стать на путь автоматизации проектирования (хотя сейчас речь скорее идет о легализации, поскольку практически везде на чем-то уже чертят), что более востребовано сейчас PDM или CAE системы, насколько PDM сейчас вообще интересен компаниям, с чего начинают с CAD или с PDM. На эти вопросы нет ответа в посте, я их не знаю. Есть лишь тезис: «компаниям чаще требуется сочетание SE+Tc», даже приводились примерные цифры – на 8 из 10 «выездов» необходим эксперт как по CAD, так и по PDM. Мне даже сейчас, пообщавшись с заказчиками как PDM специалист по Тс, трудно оценить насколько эти оценки близки в истине. Поэтому данный вопрос я бы хотел задать читателям. Пишите свои мысли, соображения, оценки, мнения, личный опыт.
И еще напоследок немного лирики: я рад, что выбор пал на Tc. За это большое спасибо, в первую очередь начальнику моего отдела. Действительно, за прошедшие месяцы знакомства с Тс я узнал много о самой компании, в которой работаю, о компаниях – наших пользователях. Изучение Тс позволяет мне смотреть на все проблемы пользователей более комплексно, изучать механизмы и принципы функционирования предприятий. Порой эти знания дают гораздо больше, нежели знания в узкой предметной или прикладной области. Пару дней назад в Самаре даже представлял презентацию о бизнесе SPLMS, но это уже следующая история :-)

«Не парься. Это всего лишь твоя жизньJ»

6 комментариев:

0'Brain комментирует...

Как человек считающий себя не самым плохим пользователем CAE, и давно и успешно выполняющий проекты заказчиков, могу сказать, что начальство оказалось совершенно ... правым.
Что касается вопроса, что больше нужно предприятиям CAE или PDM. Во многом предприятия сами не понимают что им вообще-то нужно и то и другое. Вопросы расчетов у предприятий возникают постоянно. Но как 10-15 лет назад, народ закрывал глаза на необходимость 3D, и говорил обойдемся чертежеми.. то сейчас так же говорят, что можно обойтись чистым 3D, без расчетов. Если все же припекает то в конечном итоге CAE расчеты, предприятия готовы отдать сторонним исполнителям. Они (предприятия) очень этого не любят, но, в принципе, готовы. Потому что специалист расчетчик, который может решить те задачи, на которых нельзя забить на отсутствие расчетов, это в первую очередь высококласный инженер с глубоким зананием теории, и потом уже интерфейса. Такие люди стоят много и должны иметь много постоянной работы, иначе резко падает уровень. А, как я уже говорил, в большинстве случаев от расчетов просто отказываются. По этому такие задачи, хоть и с большим нежеланием, но отдают на сторону. В то же время PDM на сторону не отдашь. Кроме того, даже в простейшем варианте с чек-ин чек-аутом они приносят пользу, которая горазд больше заметна РУКОВОДСТВУ, чем все расчетные программы вместе взятые. А уж в нормальном варианте работы...
Препдприятия, чтобы не платить деньги, часто пытаются решить проблемы через искусственные решения - "файлопомойки", обычную почту, Active Directory. И именно по причине что они уже пытались организовать как-то процесс работы, наткнулись на кучу граблей, и как-то реализовали (или забили на это), они считают что PDM не нужен. И уж тем более они часто не готовы платить за поддержку и внедрение, а только за лицензии. Потом они пытаются поставить. Ничего не выходит, и они забивают на все это дело.

Правы ли они? Как человек самостоятельно изучивший САЕ пакеты Cosmos/M, ANSYS, и работавший и в Abaqus, и в Patran, и в Femap. И как человек, который уже долгое время пытается разобраться как работает Tc... Причем скорее безуспешно, чем успешно. Я считаю что они не правы. Именно по этому пытаюсь вернуться к этому вопросу.
Что же мне (и многим другим) мешает? Большой проблемой наверняка является такое же отсутствие нормального менеджерского образования (как и инженерного для САЕ), в котором дается описание бизнес-процессам, таймменеджменту и пр. Во многом отсутсвие нормальных знаний об администрировании WinServ, SQL и пр. Во многом - отсутствие достаточного времени, чтобы по нормальному сесть и разобраться. Но когда пытаюсь понять многие моменты чуствую, что моего интеллектуального уровня не хватает, и что в данном случае платная поддержка - это не блажь. Только вот ни денег, ни времени начальство предоставить не готово. Потому и пытаемся, а не работаем. Отсюда - респект всем кто осилил.

Чайковский Илья комментирует...

Спасибо за комментарий.
У меня пара вопросов, как к опытному расчетчику. Часто я читаю и слышу, что CAE позволяет просчитать большее число конструкций, снизить расходы на испытания, и таким образом и ускоряет, оптимизирует процесс разработки. Отсюда вопрос: насколько это соответствует реальности? Действительно между конструкторами и расчетчиками происходит итерационный процесс оптимизации конструкции?
И еще, из личного опыта насколько максимально удавалось улучшить изделие в результате расчета (снижение массы, замена материалов на более дешевые и т.д.)?
И еще вопрос: насколько остро стоит вопрос оформления расчетной документации в соответствие с общепринятыми стандартами (подобно ЕСКД в конструировании)?
Часто сталкиваюсь с подобными вопросами, а опыта и знаний о реальной работе расчетчиков нет совсем.

0'Brain комментирует...

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

0'Brain комментирует...

Что касается оптимизации. Лично я крайне не люблю это слово. Оно слишком спекулятивно. Для нормальной оптимизации, от которой будет толк не в пределах машиностроительной погрешности, зачастую требуется огромное количество итераций. Дикое. Оно измеряется в тысячах шагов. Если каждый шаг длится не секунды, то процесс оптимизации может занять ГОДЫ машинного времени. Годы.
Когда быстрее там не нужна оптимизация. Там достаточно многовариантного расчета. Три четыре параметра, по 5 точек максимум, на базе результатов проводим анализ мозгами и принимаем решения. Проверяем его, еще три пять расчетов - и все довольны. И по времени и по результатам. Но это не оптимизация.
Кроме того, ни одно предприятие не готово долго ждать оптимальную конструкцию. Им достаточно работоспособной.
Особенно если изначально конструкция неработоспособна. Что часто выходит когда сталкиваются общепринятые 20-40 лет назад расчеты и современные требования. Собственно, вот тут без САЕ не обойтись.
Тут улучшение только одно - конструкция заработала. Немного вроде бы. но с другой стороны...
В плане САЕ вообще много вопросов. У меня была заметка "когда машина врет" http://saprobasni.blogspot.com/2011/01/blog-post_15.html В случае САЕ это только усугубляется. Потому еще раз повторюсь - САЕ - не панацея.

0'Brain комментирует...

Есть одна задача, с которой САЕ справляется лучше всего. Хотя это и не совсем заслуга САЕ. итак: Была конструкция. Нерабочая. Что-то приварили по месту, что-то обрезали, что-то заменили. Так в N итераций на РЕАЛЬНОМ объекте довели до рабочего состояния (и инженеры тут не при чем). Это на предприятиях чаще бывает чем использование успешное САЕ. Дальше вопрос формализации и аргументации изменений, чтобы были в порядке все нормативные документы.
Это может прозвучать смешно, может прозвучать вразрез вышенаписаным фразам, но: НАШИМ предприятиям чаще проще и дешевле решать все вопросы непосредственно по месту в реальном железе. Эта фраза не противоречит первым. Просто так построены наши бизнес процессы, что зачастую вся документация делается не на базе того, что создали конструктора, и написали технологи, а на базе того, что и как это произвели.

Вопрос снижения массы. К сожалению тут: http://www.zartum.ru/2010/12/c_20.html "Про цены и веc" правильно написано о том, как в реальности выглядит вопрос снижения массы. Когда то, один заказчик чуть не убил за фразу, о том, что можно снизить вес почти в двое. Другой "пример". Снизили вес конструкции из алюминия процентов на 20, как того и хотел заказчик, а в серию пошли отливки из чугуна, так как результат оказался дешевле на порядки.
Кроме того, мало кто понимает, что для корректного принятия решений часто нужен комплекс из экспериментов и расчетов. Не все и всегда надо полностью повторять в метале. Но как минимум, нужно откуда-то брать данные о поведении материалов. И не справочных а реальных. И уж тем более мало кто понимает, что если у конструкции некоторые механические свойства имеют разброс в порядки (например предел прочности), то неточность результатов в 20% это идеальные результаты.

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

Чайковский Илья комментирует...

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