В преддверии очередного семестра готовлюсь к парам по предмету "Основы автоматизированного проектирования". Похожие курсы есть на многих специальностях на 3-5 курсах, и в рамках подобного предмета на этих специальностях начинают давать CAD системы. Некоторым дают не просто CAD, а трехмерные. У нас трехмерка идет с первого курса (по крайней мере теоретически), и к третьему курсу это должен быть привычный инструмент. Соответственно рассказывать о том что есть чудо-программы в которых можно нарисовать Три-Дэ и получить автоматом Два-Дэ уже как-то не комильфо. Обычно я рассказываю о истории становления отрасли автоматизированного проектирования, текущем состоянии и ближайшем будущем. С каждым годом появляются все новые возможности, и то что ранее было "еще чуть-чуть и увидим" переходит в режим "никого не удивляет". Впрочем не все. Так например то же самое Два-Дэ уже который год хоронят, а оно живее всех живых. Впрочем лично я его хоронить не собираюсь.
Даже то, что текущий третий курс, в рамках которого будет читаться данный курс у нас такой замечательный, что им на экзаменах первокурсники подсказывали, все равно не лишает необходимости провести хотя бы минимальную подготовку к парам (не смотря на общее расстройство из-за "этих дней"). И в рамках данной публикации (а может серии - как пойдет) я хочу описать свое видение "идеального сферического САПР в вакууме" (с упором на машиностроение). Я хотел назвать публикацию "Мы наш мы новый САПР построим", но потом понял, что кто-то может решить что я занимаюсь САПРописанием... Я бы с радостью, да не вытяну. квалификация не та. Так что в блог. Только в блог...
У меня были некоторые публикации на тему возможностей CAD и подходов (например: Что нам стоит дом построить). И как видно по названию данная публикация частично продолжает данную тематику. Также будет не бесполезно напомнить про цикл: Пан Атаман Идеал САПРический
Да и просто в блоге есть ряд полезных публикаций. Уже и сам не все вспомню. Ну а пока продолжим.
Итак каким должен быть идеальный САПР? Что должно быть в нем? Чего не должно быть в нем?
0. НЕ CAD!!! а Система автоматизированного проектирования = CAD/CAM/CAE/PDM ....
1. Современный! Что это значит на деле?
Ну во первых (1.1) интерфейс не должен вызывать желание застрелиться. А плиточный он или яблочный, плоские иконки или выпуклые это уже как-то все равно... ИМХО.
Во вторых (1.2) он должен быть адаптивным, как и веб сайты/мобильные игры. Т.е. с ним необходимо эффективно работать на любом устройстве на котором его можно запустить с любым типом и комплектом мониторов.
1.3 поддерживать многопроцессорность, кластерность и вычисление на графических картах на всех операциях на которых это вообще возможно. А то сидишь на компьютере с 24 ядрами.... а рядом школьник на ноутбуке тебя обгоняет, потому что у него на ноуте проц на пару мегагерц быстрее. (речь идет не о тормозах пользователя, а о тормозах системы). Я понимаю что это идет от необходимости сопровождать старый код, который успешно работает и обеспечивает совместимость со старыми версиями (и не всегда еще известно как он работает).
Почему я начал с интерфейса? Потому что встречают по одежке. Кроме того оставить пользователей на устаревшем но привычном интерфейсе - возможно. Но заставить их сменить САПР, или вообще обратить свой взор к САПРу при убогом многоокнном, с кучей выпадающих меню интерфейсе, в котором нужно для выполнения банальной операции нажать на кучу кнопок - увы нет.
Ну и конечно 1.2 (адаптивность) имеет смысл расширить на еще один пункт - мультиязычность, как интерфейса так и справки (особенно хочется чтобы была возможность переключаться между языками и интерфейсом внутри хелпа. Читаешь себе такой хелп на русском, а кнопки там все на английском (для веба это давно уже не новость). А еще возможность переводов не только в хелпе и "фейсе". Но, например, в дереве и комментах на чертежах.
2. Модульный. Причем модульность подразумевается как внешняя так и внутренняя. Да я знаю что сейчас любая программа является модульной, ибо так проще разрабатывать. Но дело не в этом. Дело в том что сейчас даже у одной фирмы, ее программы между собой не всегда хорошо совместимы, даже если должны. Хуже того, даже "внутренние" модули работают через такую пень-колоду и набор костылей, что просто ужас. А все потому, что пришивали их по живому белыми нитками. А до того это были принципиально разные решения от разных производителей, которые никто и больной фантазии не думал слепливать воедино. А уж про единую архитектуру на которой основана разработка речь вообще не шла.
Так вот исходная архитектура должна быть продумана заранее, как и способы и пути ее развития. Должны быть заложены возможности для дробления модулей логики и укрупнения (сборки их в мегамодули), должны быть продуманы стандартные протоколы обмена и оставлены места для развития (назовем его непредвиденным).
Естественно это в каком-то виде есть и в существующем ПО. Но зачастую это вглядит как-то так:
Что касается внешней модульности. Она должна быть двух типов. С одной стороны это должны быть модули ориентированные на выполнение конкретных типов работ (создание геометрии, CAM, CAE...) с другой это должны быть модули с ориентацией на разный уровень профессионализма. И если профессионалу мы показываем весь инструментарий и все настройки для операций, чтобы он мог сам создать то что нужно. То модуль для новичков должен быть неперегруженным интерфейсом и в ущерб возможностям быть максимально быстрым и дружелюбным.
Кстати, вот именно тут скажу что меня бесит лента/ribbon и кучи контекстных меню. Если Вы знакомы с ПО, то скорее всего это Вам ускорит работу. Но если не знакомы, то найти нужные инструменты бывает крайне проблематично даже используя хелп и форумы. Да даже видеоуроки и вебинары не всегда помогают, потому что у докладчиков интерфейс часто уже кастомизирован. Соответственно лента и умные менюхи - это замечательная вещь, но должна быть возможность вывести список всех команд, всех опций и всех настроек. В этом плане в ПО Solidworks (хотя они от этого пытаются почему-то уйти) самый правильный вариант. Наряду с "быстрой-удобной лентой" есть возможность вывести отдельно панели инструментов и есть меню содержащее все основные функции текущего окружения/модуля. К сожалению такое сейчас встречается все реже.
То же самое должно быть и с режимом установки. Т.е. нашу САПР необходимо, не смотря на все многообразие ее возможностей, устанавливать в два клика и при этом она должна быть работоспособной. А если уж хотите чего-то более подстроенногопод себя - пожалуйста - вот Ваши настройки. Сейчас уже почти любые системы ставятся в два клика из интернета. Причем многие позволяют пользователю на сайте указать что он хочет (в терминах понятных ему, а не названия модулей и пр), указать базовые настройки (названия серверов, типы баз данных и пр) и скачав exe'шник в несколько сот килобайт развернуть систему так, как он ее преднастроил.
3. Единая среда. Раз уж была упомянута база данных (и PDM в верху) то имеет смысл сказать что САПР должна быть клиентсерверной с хранением всей информации в БД. Речь идет не о том, что у системы не должно быть файлов на диске. Речь идет о том, что без нормальной системы документооборота, через пару лет работы даже если пользователь работает сам он обязательно запутается в половине своих проектов. Должны быть системы контроля версий, должны быть возможности быстрого поиска по параметрам, и не всегда четко формализованным и куча всего другого, что без Базы данных обеспечить невозможно.
Ну и раз мы говорим о клиентсерверности и БД, то имеет смысл сказать, что должны быть простые инструменты экспорта импорта информации, архивации, репликации, дублирования и синхронизации с серверами (например корпоративными) и облачным хранением (в т.ч. частное облако) при необходимости.
Среда для общения и коллаборации. Ни в коем случае не соц.сеть. Дело не в ней. Она может быть иногда вспомогательным решением, но не основным. Но любые переговоры, которые идут на тему проекта и идут в онлайн - должны быть приобщены к делу. Даже извините аудио-видео разговоры. Кому-то покажется это диким и странным. Но к тому что электронная почта является частью делопроизводства тоже не сразу привыкли.
4. Облака. Раз заговорили про облака то система должна быть в том числе облачной.Это и хранение данных в облаке компании разработчика (при необходимости), и при желании частное облако для хранения данных, и работа САПР в облаке и доступ к ней в режиме SaaS. Software as a Service. Причем тут тоже и саас и термин облако понимается в широких пределах.
Но главное я считаю не это. Пользуясь гуглосервисами (почтой, блогом, гуглодоками) я настолько привык к тому что у меня нет необходимости постоянно сохранять свои действия, и что даже в случае падения бразуера, ПО, коннекта, у меня все равно все останется в нормальном состоянии с минимальной потерей моих действий. Сейчас абсолютно тоже самое можно и НУЖНО сделать в САПР. ну забыл человек сохраниться, и у него упало пол дня работы (а ведь иногда падает и больше). Не забыл, сохранил, но из-за сбоев питания, программы и пр. единственная сохраненная версия стала испорченной и ее не открыть.
мы живем не в век дискет и многократное резервирование которое выполняется в автомате прочно вошло в нашу жизнь. Самое смешное, что при правильном подходе 20 копий нередко занимают места не многим меньше нежели в отсутствии этих копий при неправильном.
Сейчас технологии позволяют синхронизировать миллиарды действий миллионов игроков выполняемых одновременно в разных уголках планеты. И потому я просто не поверю, что в мире САПР это не возможно. Это не нужно. Но "не нужно" не пользователям, а сапропроизводиелям. Зачем напрягаться.
5. Мультидисциплинарность. Мы привыкаем к хорошему. Сейчас какую САПР не открой а там все есть. И CAD и CAM и CAE и ... Даже в системах у которых есть "старшие братья" и в которые просто не понятно зачем это все запихали. Ведь в том варианте в котором запихнули ничего серьезного все равно не сделаешь, и оно никому не нужно. А в том в котором нужно никто пихать не будет чтобы не создавать конкуренцию старшим... А зачем же тогда пихать? А "шоб було" ибо "все так делают". Причем к этому "все делают" привыкают и пользователи, и крутят носом если функционала нет. И плевать, что он им не нужен. Но его ж нетути!!!
И тем не менее, никакой мультидисциплинарности на деле нет.
Приведу пример. Я обрабатываю в CAM тонкостенную деталь. Настолько тонкостенную, что условия обработки влияют на точность в виду деформации модели. Я могу как-то связать CAM и CAE? нет. У меня деталь под действием нагрузки деформируется и искажается ее форма. Я могу как-то учесть эту деформацию в CAD? нет! Я могу сделать геометрию так, чтобы после деформации она была такой как мне нужно? не делайте мне смешно, тем более нет! А множественные зазоры натяги и пр. которые есть в геометрии, как и на что они влияют?
О какой мультидисциплинарности вообще идет речь, когда простое изменение модели приводит не только к тому что все расчеты или САМ-операции надо перезадавать по новой. Но и летит в тартарары половина геометрии. И да, параметризация спасает. (хотя и не всегда) , но какой ценой? Прямое моделирование, синхронные технологии и прочие поделки тоже облегчают жизнь. Но до заявляемых даже пять лет назад удобства и гарантированной работоспособности методик, как-то далековато.
Если же мы хотим добавить в модель математические расчеты, статистику, логику, результаы численных расчетов, технологические моменты.. то все это сделать абсолютно не представляется возможным. Все это с помощью костылей, граблей, лоскутной автоматизации и какой-то матери работает. У отдельных людей, в отдельных компаниях и почти всегда. Особенно при строгом соблюдении кучи нормативных документов. Но не более. Даже тако обожаемый мною подход BMX (Behavioral Modelin eXtension) не смотря на наличие рабочего прототипа, является скорее благим пожеланием.
Да елки-палки привязаться к длине дуги, я уж не говорю про кривую по уравнениям, сплайн или еще что-то и то в большинстве случаев нельзя. А если мне нужно чтобы сплайн был ровно 1 метр? Мне что повеситься? Или создавать цепочку прямых участков вместо сплайна?
Да елки палки, я хочу в на одной модели сделать "красявый рендер" с результатом расчета, обработкой и пр. и что? "Фотошоп в руках инженера" - единственный выход. (давно хочу такой учебник выпустить, впрочем я это уже писал).
Про то, что технологическая информация (допуски посадки, квалитеты, типы поверхностей и пр.) существует в САПР только в каком-то параллельном мире я вообще молчу.
Как итог примочки есть... а вот возможностей нет. А ведь разработчики САПР правильно говорят, что сейчас почти все разрабатывается на стыке между дисциплин. Но такое впечатление, что кто-то получает садистское удовольствие от вывертов народа на костылях при попытке этого добиться.
6. Технологичность. На самом деле данный пункт также относится к пункту 5. Потому что когда мы говорим о технологии в мире САПР во всем западном мире в 90% случаев говорят про CAM и только. А на постсоветском пространстве долгое время ни о чем кроме АСТПП (CAPP) 70% и не мечтало (а если и мечтало то снова таки о CAM). В лучшем случае большие компании вспоминают про средства виртуального производства. И это уже хорошо, но етсь же большое число расчетно-технологических (а потому междисциплинарных) вопросов - литье (пластика, металла), обработка материалов давлением, то же резание... сварка.. да много чего
И эти вопросы немаловажны особенно сейчас потому что кроме прочего влияют на sustainable. В общем "зеленость". Но зеленость не сама по себе, а в рамках технологии и расчетов (минимизация веса и пр). зеленая деталь обязательно технологичная, потому новый пункт я не выделяю.
7. Еще имеет смысл добавить стандартоориентированность
Более глубокая интеграция со стандартами. На текущий момент по сути обязательным является только поддержка чертежных стандартов. И то, и тут народ умудряется начудить. Но на деле, существенно больший список стандартов можно заложить в САПР с тем чтобы упростить процесс разработки изделий в соответствии с ними. Ну а для начала иметь базу стандартов.
8. всеядность
С точки зрения форматов данных. Сильнее всего тут продвинулись производители имеющие у себя инструменты прямого моделирования. Но на деле этого мало. Та же технология (допуски/посадки) - теряется. Любые данные из вертикальных приложений - теряются и пр. Зачастую нужно дерево, а его нет. И даже когда модели импортируются "успешно". Они нередко приходят с существенными отличиями. Да на текущий момент есть слишком много стандартов нейтральных форматов. И каждый его читает по своему. Есть еще больше проприетарных стандартов, которые никто не раскрывает и еще и "реверсить" пытаются запретить (даже не смотря на разрешения судов). Все это усугубляется различием в геометрических движках. Но шутка состоит в том, что в 90% случаев базовые кирпичики - они одинаковые, и надо просто постараться сделать совместимые конвертеры. Да это задача сложная (даже САПРопроизводители не всегда нормально организовывают работу новых программ со старыми версиями файлов) и все же она возможна.
9. наличие средств автоматизации
Это есть у всех. Но надо не только путем классического программирования, но и с помощью визуального программирования. Ну и конечно то что есть почти у всех: система подключения внешних решений и модулей.
9. Открытость
Три последних пункта, вкупе с 2 (а частично и с другими пунктами) приводит к тому, что система также должна быть открытой. Причем открытой по возможности максимально. Вплоть до кода, пусть и не всего. Но код это не главное. "Базы данных" материалов, стандартных и покупных изделий. Документов, стандартов, приложений....
Открытость не значит бесплатность. В данном случае. Я не буду экзалитированным юношей призывающим все сделать бесплатным (по крайней мере в рамках данного текста, хотя ранее неоднократно предлагал, да и сейчас не сильно отказался от своих идей).
Но не смотря на то, что данный термин применительно к тем или иным САПР я слышал неоднократно с высоких трибун. Хочется чего-то более открытого и существенного. Ибо в жизни все снова через шлагбаум (который посреди поля, но таки есть).
Наверное я что-то забыл. Но для начала процесса восстановления блога этого должно хватить. Потом постараюсь отдельные моменты расписать более подробно. Ну а жизнь покажет. получится или нет. А пока на этой благостной ноте закончим описание "САПРы нового поколения". (сразу после этой фразы мое лицо повторяет мимику героини из Формулы любви:
Комментариев нет:
Отправить комментарий