s1_63381_66

Что предлагают PLM вендоры для решения интеграционных проблем при проектировании мехатроники? Часть 1.

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

 

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

Три независимых среды разработки — вызов актуален

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

 

Очевидно, что это несет в себе новые вызовы для промышленности: нужны конструктора новых специализаций, программисты, менеджеры со специфическим опытом и способностью находить общий язык как с конструкторами, так и с программистами. Новым инженерам нужны специализированные инструменты проектирования и разработки — системы проектирования электроники EDA (Electronic Design Automation), среды разработки ПО. Появляются новые поставщики компонентов, которые имеют другой уровень сложности и интеграции. Нужна новая конструкторская и производственная инженерная экспертиза. Единовременно перейти в новое качество невозможно, и в условиях недостатка опыта проектирование устройств новых поколений становится серьезным вызовом для предприятий, их менеджеров и инженеров.

s1_65843_75

При проектировании мехатронных изделий предприятия сталкиваются с тем, что фактически существуют три независимых среды разработки: MCAD (Mechanical Computer-Aided Design), EDA и отдельная от них среда разработки ПО. Все эти среды имеют собственную длительную историю развития и устоявшуюся идеологию. Эти идеологии не совпадают. В MCAD системах по большому счету все вращается вокруг дерева построения модели и состава изделия. В свою очередь, в EDA 3D модель объективно малополезна, зато важны обширные каталоги элементов, качественные алгоритмы компоновки и трассировки печатных плат, а результатом является по сути многомерная плоская модель печатной платы, имеющая большое количество ссылок и описывающая распределение и связи элементов из баз компонентов. В средах разработки ПО мы вообще сталкиваемся с продуктом не имеющем воплощения в физическом мире — с точки зрения инженера-конструктора программный код — это вообще чистая бесплотная абстракция, почти не привязанная к физическому миру.

 

Ситуация усугубляется тем, что у каждой системы существуют свои цели и задачи, свои форматы данных, а результаты работы не всегда могут быть сопряжены в одну модель изделия. Каждый развитый инструмент безусловно имеет также и соответствующую систему управления создаваемыми данными, например PDM (Product Data Management) и ALM (Application Lyfecycle Management) системы для механической и программной части изделия соответственно. При этом, для систем проектирования электроники EDA вообще почти не сформировалось определенного класса отдельных решений по управлению их информацией, а в силу идеологии EDA такой функционал начал развиваться внутри самих инструментов проектирования. Все перечисленные системы управления информацией этих инструментов тоже имеют колоссальные отличия, порожденные особенностями объекта управления (механическая конструкция, электроника, программный код) и сложившимися различиями в процессах управления данными — в софтверной компании и КБ бизнес-процессы обычно отличаются очень значительно.

Что предпринимает «большая тройка» PLM вендоров?

Ближе всего к объединяющей платформе на текущий момент находятся PDM системы основных отраслевых вендоров: Windchill компании PTC, Teamcenter компании Siemens PLM Software и Enovia разработки Dassault Systemes. Но все равно, говорить об этом можно только потому, что представить себе хранение, например, исходных кодов в PDM можно, а вот ведение состава изделия и его конфигураций в классической ALM системе — только в кошмарном сне. То есть мы просто имеем дело с меньшим из зол, которое пытаются использовать не по назначению, но творчески.

 

Вендоры PDM решений безусловно тоже сделали аналогичные выводы и постарались создать решения, которые бы сделали из PDM системы центр управления комплексной информацией при проектировании мехатроники. Что вендоры понимают под этим? В целом, стратегия всех вендоров более-менее одинакова. Во-первых, идеологическое ядро — это физический состав изделия. И это, наверное, правильный на текущий момент подход. По-крайней мере, другие концепции управления информацией об изделии пока не достигли нужного уровня зрелости. Во-вторых — максимальное использование уже имеющихся инструментов (процессы, модели данных, отчеты) для новых объектов (программный код, топология печатной платы). Разработчики PDM предлагают считать, что это примерно то же самое, что и деталь, но только без 3D модели. И в третьих — ведение справочных данных новых сред проектирования (ПО, электронных подсистем) предлагается вести по большому счету в обычных справочниках этих систем, возможно, немного кастомизированных.

 

Что я имею в виду. Если мы рассмотрим решения компании PTC, то увидим, что ее решение Creo позволяет создавать 3D модели печатных плат на основе импортированных из EDA даных, а PDM система Windchill позволяет управлять не только «механическим» составом, но и микрокодом, а также импортировать в состав изделия данные из BOM (Bill os material) печатных плат различных EDA систем (продукты Creo View ECAD, Windchill ECAD Workgroup manager и др.). Да, это безусловно уже намного лучше, чем ничего.

 

У компании Dassault systemes похожая концепция и поддерживающие ее решения ENOVIA Collaborative Design for ECAD. Интеграция атрибутов, импорт BOM, данных библиотек и далее по списку, все уже было перечислено, не будем повторяться. Весь этот функционал, как и функционал решений решений, предлагаемых PTC и Siemens PLM Software безусловно полезен, но не является концептуальным прорывом в области сквозного проектирования мехатроники.

 

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

 

5 системных проблем

Создание и внедрение специальных комплексных решений для мехатроники отягощают следующие системные проблемы:

 

1. Сложность интеграции справочников. Механические и электронные компоненты имеют существенные отличия в модели описания, и не всегда встроенные справочники PDM систем, ориентированные на крепеж, трубопроводную арматуру и прочие стандартные и покупные изделия, имеют функционал для корректного описания элемента, нужного EDA (например, координаты контактных площадок). Вторым тяжелым на практике вопросом является корректное получение информации EDA системами из этих справочников — необходимо сложное интеграционное решение на стороне EDA систем. Мало того, даже если PDM система может импортировать данные, как, например, Teamcenter gateway for ECAD part library позволяет импортировать в Teamcenter Classification библиотеки Orcad CIS, Altium, Mentor Expedition DXDatabook, то все равно остаются открытыми вопросы по распознаванию элементов на импортированной в MCAD топологии печатной плате и сопоставлению их со справочником, а также корректная передача изменений в EDA, если таковые будут иметь место. Наблюдая существующие решения создается впечатление, что все это полумеры, и есть существенный дефицит концептуального видения нового процесса проектирования и требований к новому (а не немного кастомизированному) инструменту. 
 
2. Сложность интеграции процессов. Многие бизнес-процессы, например, управление требованиями, или тот же процесс внесения изменений на стадии проектирования может затронуть все три слоя изделия — и механику, и электронику, и программное обеспечение. Но работы по оценке и реализации этого изменения будут вестись в разных средах, из-за чего могут возникать процессные, организационные коллизии и коллизии конструкционные.

 

3. Разный уровень зрелости процессов. Если многие R&D подразделения софтверных компаний в СНГ активно экспериментируют с Agile и Kanban подходами к управлению разработкой, внедряется большое количество новых подходов, таких как TDD (Test Driven Development), Continious Integration, и практик (рефакторинг, парная разработка), то отечественные КБ поглощены толкованием догматики ГОСТ, ЕСКД, ЕСТД, которые, конечно, не вредны сами по себе, но могут натворить бед, если превращаются в карго культ.

 

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

 

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

 

В целом это на 80%-90% совпадает с проблематикой, которую получила в своем исследовании Aberdeen еще в 2006 году.

 

Image1
Рис. 1. Mechatronic Product Development Challenges
 
Как можно преодолеть указанные проблемы? Очевидно, что простого решения на данный момент не существует. Я не могу на этом моменте щелкнуть пальцами и сказать «Используйте систему ХХХХХХ и она решит все ваши проблемы, потому что она основана на лучших практиках и так далее, и так далее». Объективно, такой системы пока нет. Windchill ECAD Workgroup manager и ENOVIA Collaborative Design for ECAD могут помочь вам качественно упаковать все данные в PDM системе, сохранить их от потери и предотвратить ряд системных рисков, но не предложит решения для интеграции процессов и интеграции справочных данных. Teamcеnter предложит очень большое количество различных концепций и отдельных продуктов в данной области, но недостаточная интеграция этих решений друг с другом и их тяжелый для восприятия интерфейс (встречайте конфигурационные файлы!) затруднят их практическое использование.

Напишите свое мнение на форуме!

Анатолий Суздальцев

Я приглашаю всех заинтересованных специалистов к созданию нового отраслевого процессного фреймворка. 
Пишите нам.

Анатолий Суздальцев.

 

При написании статьи использованы данные следующих источников: