Системы автоматического проектирования: системы автоматизированного проектирования: что такое САПР, разновидности, применение, функционал

Содержание

НОУ ИНТУИТ | Лекция | Системы автоматизированного проектирования (САПР) РЭС

Аннотация: В лекции приводятся основные определения, назначение и принципы систем автоматизированного проектирования (САПР). Даются сущность и схема функционирования САПР. Показано место САПР РЭС среди других автоматизированных систем. Рассматриваются структура и разновидности САПР. Основное назначение лекции — показать сущность процесса проектирования РЭС, основные принципы проектирования. Особенное внимание уделяется системному подходу к проектированию конструкции и технологии производства РЭС

Ключевые слова: ПО, САПР, проектная организация, объект проектирования, автоматизация, работ, очередь, опыт, проектная операция, объект автоматизации проектирования, технологический процесс, системы автоматизированного проектирования технологического процесса (САПР ТП), операции, средства автоматизации, эскизный проект, интерактивный режим, мощность, имитационное моделирование, критерий эффективности, информационное согласование, контроль, удобство эксплуатации, автоматизированная система, CAE, PDM, проектирующие подсистемы, обслуживающие подсистемы, проектная процедура, страта, MCAD, ACI, VHDL-T

4.

1. Определение, назначение, цель

По определению, САПР — это организационно-техническая система, состоящая из совокупности комплекса средств автоматизации проектирования и коллектива специалистов подразделений проектной организации, выполняющая автоматизированное проектирование объекта, которое является результатом деятельности проектной организации [54, 9].

Из этого определения следует, что САПР — это не средство автоматизации, а система деятельности людей по проектированию объектов. Поэтому автоматизация проектирования как научно-техническая дисциплина отличается от обычного использования ЭВМ в процессах проектирования тем, что в ней рассматриваются вопросы построения системы, а не совокупность отдельных задач. Эта дисциплина является методологической, поскольку она обобщает черты, являющиеся общими для разных конкретных приложений [59].

Идеальная схема функционирования САПР представлена на рис.

4.1.

Рис. 4.1. Схема функционирования САПР; КСА — комплекс технических средств

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

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

intuit.ru/2010/edi”>Из определения САПР следует, что целью ее функционирования является проектирование. Как уже было сказано, проектирование — это процесс переработки информации, приводящий в конечном счете к получению полного представления о проектируемом объекте и способах его изготовления [37].

В практике неавтоматизированного проектирования полное описание проектируемого объекта и способов его изготовления содержит проект изделия и техническую документацию. Для условия автоматизированного проектирования еще не узаконено названия конечного продукта проектирования, содержащего данные об объекте, и технологии его создания. На практике его называют по-прежнему “проектом”.

Проектирование — это один из наиболее сложных видов интеллектуальной работы, выполняемой человеком. Более того, процесс проектирования сложных объектов не под силу одному человеку и выполняется творческим коллективом. Это, в свою очередь, делает процесс проектирования еще более сложным и трудно поддающимся формализации. Для автоматизации такого процесса необходимо четко знать, что в действительности он собой представляет и как выполняется разработчиками. Опыт свидетельствует, что изучение процессов проектирования и их формализация давались специалистам с большим трудом, поэтому автоматизация проектирования всюду осуществлялась поэтапно, охватывая последовательно все новые проектные операции. Соответственно, поэтапно создавались новые и совершенствовались старые системы. Чем на большее число частей разбита система, тем труднее правильно сформулировать исходные данные для каждой части, но тем легче провести оптимизацию.

Объектом автоматизации проектирования являются работы, действия человека, которые он выполняет в процессе проектирования. А то, что проектируют, называют объектом проектирования.

Человек может проектировать дом, машину, технологический процесс, промышленное изделие. Такие же объекты призвана проектировать САПР. При этом разделяют САПР изделия (САПР И) и САПР технологических процессов ( САПР ТП ).

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

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

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

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

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

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

Автоматизация перечисленных операций обработки информации и процессов управления использованием информации на всех стадиях проектирования составляет

сущность функционирования современных САПР.

Каковы основные черты систем автоматизированного проектирования и их принципиальные отличия от “позадачных” методов автоматизации?

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

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

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

Третья особенность САПР РЭС заключается в возможности имитационного моделирования радиоэлектронных систем в условиях работы, близких к реальным. Имитационное моделирование дает возможность предвидеть реакцию проектируемого объекта на самые различные возмущения, позволяет конструктору “видеть” плоды своего труда в действии без макетирования. Ценность этой особенности САПР заключается в том, что в большинстве случаев крайне трудно сформулировать системный критерий эффективности РЭС. Эффективность связана с большим числом требований различного характера и зависит от большого числа параметров РЭС и внешних факторов. Поэтому в сложных задачах проектирования практически невозможно формализовать процедуру поиска оптимального по критерию комплексной эффективности решения. Имитационное моделирование позволяет провести испытания различных вариантов решения и выбрать лучший, причем сделать это быстро и учесть всевозможные факторы и возмущения.

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

4.2. Принципы создания систем автоматизированного проектирования конструкции и технологии

При создании САПР руководствуются следующими общесистемными принципами:

Принцип включения состоит в том, что требования к созданию, функционированию и развитию САПР определяются со стороны более сложной системы, включающей в себя САПР в качестве подсистемы. Такой сложной системой может быть, например, комплексная система АСНИ — САПР — АСУТП предприятия, САПР отрасли и т. п.
Принцип системного единства предусматривает обеспечение целостности САПР за счет связи между ее подсистемами и функционирования подсистемы управления САПР.
Принцип комплексности требует связности проектирования отдельных элементов и всего объекта в целом на всех стадиях проектирования.
intuit.ru/2010/edi”>Принцип информационного единства предопределяет информационную согласованность отдельных подсистем и компонентов САПР. Это означает, что в средствах обеспечения компонентов САПР должны использоваться единые термины, символы, условные обозначения, проблемно-ориентированные языки программирования и способы представления информации, которые обычно устанавливаются соответствующими нормативными документами. Принцип информационного единства предусматривает, в частности, размещение всех файлов, используемых многократно при проектировании различных объектов, в банках данных. За счет информационного единства результаты решения одной задачи в САПР без какой-либо перекомпоновки или переработки полученных массивов данных могут быть использованы в качестве исходной информации для других задач проектирования.
Принцип совместимости состоит в том, что языки, коды, информационные и технические характеристики структурных связей между подсистемами и компонентами САПР должны быть согласованы так, чтобы обеспечить совместное функционирование всех подсистем и сохранить открытую структуру САПР в целом. Так, введение каких-либо новых технических или программных средств в САПР не должно приводить к каким-либо изменениям уже эксплуатируемых средств.
Принцип инвариантности предусматривает, что подсистемы и компоненты САПР должны быть по возможности универсальными или типовыми, т. е. инвариантными к проектируемым объектам и отраслевой специфике. Применительно ко всем компонентам САПР это, конечно, невозможно. Однако многие компоненты, например программы оптимизации, обработки массивов данных и другие, могут быть сделаны одинаковыми для разных технических объектов.
Принцип развития требует, чтобы в САПР предусматривалось наращивание и совершенствование компонентов и связей между ними. При модернизации подсистемы САПР допускается частичная замена компонентов, входящих в подсистему, с изданием соответствующей документации.

Приведенные общесистемные принципы являются чрезвычайно важными на этапе разработки САПР. Контроль над их соблюдением обычно осуществляет специальная служба САПР предприятия.

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

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

Системы автоматического проектирования в судостроении

Библиографическое описание:

Минченко, Л. В. Системы автоматического проектирования в судостроении / Л. В. Минченко, Т. А. Кандратова. — Текст : непосредственный // Современные тенденции технических наук : материалы V Междунар. науч. конф. (г. Казань, май 2017 г. ). — Казань : Бук, 2017. — С. 73-76. — URL: https://moluch.ru/conf/tech/archive/230/12335/ (дата обращения: 14.07.2023).

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

Ключевые слова: судостроение, судоремонт, системы автоматического проектирования, САПР

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

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

На судостроительных предприятиях применяется множество различных информационных систем, многие из которых могут быть интегрированы с ИСУП. В частности, к ним можно отнести CAD/CAM-системы, системы документооборота, электронные архивы, PDM/PLM-системы и т. д.

Реализация проектов в области CAD/CAPP/PDM, как правило, занимает достаточно длительный период — от года и более. Естественно, что при внедрении таких решений заказчики заинтересованы в организации эффективных предпроектных исследований, в четком обозначении сроков выполнения всех этапов, в строгом следовании графикам. Здесь — причина того, что судостроительные предприятия все чаще обращаются к отечественным разработкам программного обеспечения и систем автоматического проектирования.

Система автоматизированного проектирования (САПР) — система, исполняющая информационную технологию выполнения функций проектирования и являет собой организационно-техническую систему, предназначенную для автоматизации процесса проектирования, состоящую из персонала и комплекса технических, программных и других средств автоматизации его деятельности.

САПР, активно применяемые в судостроении:

FORAN — специализированная судостроительная система проектирования (разработана фирмой SENER INGENERIA Y SISTEMAS S. A.).
TRIBON — специализированная судостроительная система проектирования (разработана фирмой TRIBON SOLUTIONS).
NUPAS-CADMATIC — специализированная судостроительная система проектирования (разработана и компаниями NUMERIEK CENTRUM GRONINGEN B. V., и CADMATIC Ltd.).
CATIA — система проектирования, разработанная фирмой DASSAULT SYSTEMES, Франция при поддержке корпорации IBM, США. В настоящее время анонсируется, как система, учитывающая специфику проектирования в судостроении.
AutoSHIP — специализированная судостроительная система проектирования, разработанная фирмой AUTOSHIP SYSTEMS CORPORATION.
ПЛАТЕР — интегрированная система автоматизации конструкторской и технологической подготовки корпусных производств верфи.
ShipModel — программный комплекс для судостроения.
DEFCAR — специализированная судостроительная система проектирования (разработана фирмой DEFCAR Eng.).
NAPA — специализированная судостроительная система проектирования (разработана фирмой Napa Oy).
K3-SHIP — комплекс программ трехмерного моделирования для судостроения, разработанный НВЦ «ГеоС», Россия.
Sea Solution — специализированный программный комплекс, разработанный компанией SeaTech Ltd., Россия.
Pro/Engineer Shipbuilding Solutions — специализированная система проектирования для судостроения, разработанная компанией PTC (Parametric Technology Corporation), США.
САПС — система автоматизированного проектирования судов. Разработана фирмой ООО «ЛЕДА» (г. Николаев, Украина) применительно к особенностям судостроения в странах СНГ и Балтии.

Ведущим российским разработчиком таких программных обеспечений является Группа компаний АСКОН, работающая на рынке САПР с 1989 года и разрабатывающая массовые CAD/CAM/CAPP/PDM-системы под следующими марками:

Система инженерного документооборота ЛОЦМАН:PLM — используется при управлении заказами, проектами, изделиями МСЧ и верфи;
САПР технологических процессов ВЕРТИКАЛЬ используется для написания техпроцессов как МСЧ, так и верфи;
САПР КОМПАС-3D и КОМПАС-График позволяют создавать 3D-модели и оформлять необходимую документацию, а также оформлять текстовую документацию.

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

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

В отечественном судостроении активно применяются информационные базы Группы компаний АСКОН под марками КОМПАС, ЛОЦМАН:PLM и ВЕРТИКАЛЬ.

На ОАО СПО «Арктика» (г. Северодвинск) широко используется система ЛОЦМАН:PLM. На ФГУП ЦМКБ «АЛМАЗ» (г. Санкт-Петербург) — система КОМПАС для решения задач проектирования элементов трубопроводных систем, систем гидравлики, компоновки гидропанелей и энергетических установок корабля.

ПО «Севмаш» также использует комплекс данного ПО и на сегодняшний день, для обеспечения автоматизации конструкторско-технологической подготовки изделий машиностроения решены следующие задачи:

организовано автоматизированное формирование заданий по раскрытию состава изделия машиностроения и внесению информации в систему ЛОЦМАН:PLM;
разработан и внедрен механизм загрузки транспортных массивов от проектантов;
организовано формирование конструкторского состава примененных изделий МСЧ с бумажных подлинников путем создания спецификаций в КОМПАС-График;
организовано взаимодействие информации, управляемой в системе ЛОЦМАН:PLM, с другими информационными системами, функционирующими на предприятии.

На предприятии ОАО «Адмиралтейские верфи» и ОАО «Северное ПКБ» широко используется информационно-нормативное обеспечение полного жизненного цикла корабля ПО NormaCS.

В процессе внедрения ПО на ОАО «Адмиралтейские верфи» была решена задача конвертации в формат NormaCS — ЛОТ базы данных ранее используемого на предприятии ПО Технорма/ИнтраДок. Для решения этой задачи была создана Программа автоматизированного (пакетного) внесения документов в систему по созданию собственных баз данных предприятия NormaCS Pro.

В процессе внедрения была решена задача нормативного обеспечения разработки конструкторской и технологической документации в MS Word, MS Excel, AutoCAD, Pro/Engineer. Для решения этой задачи были использованы встроенные интеграционные механизмы. Результатом явилась отработка автоматической простановки и проверки гиперссылок на нормативные документы:

В документах MSOffice;
В документах (чертежах) AutoCAD;
В 3D-моделях и чертежах, разработанных с использованием Pro/Engineer.

При выборе системы в ОАО «Северное ПКБ» особое значение имела полнота баз данных и функционал. Несомненно, то, что в NormaCS хранится практически весь фонд отечественных нормативных документов по всем отраслям промышленности, включая судостроение, сыграло решительную роль в выборе по критерию полноты базы данных.

В пользу выбора NormaCS по критерию функционала сыграли следующие факторы:

Система позволяет создавать и собственные базы данных, в том числе — базы внутренних документов (нормативов, стандартов предприятия (СТП), распоряжений и т. д.).
Система оптимизирует процесс обмена информацией, ускоряет процесс разработки и проектирования. Это возможно благодаря наличию следующих функций:
NormaCS имеет встроенный модуль автоматизированного нормоконтроля, позволяющий производить проверку актуальности ссылочных документов, названия которых указаны в чертежах и рабочей документации. При этом сам нормативный документ не открывается;
Система интегрирована с основными используемыми приложениями: Microsoft Word, Microsoft Excel, AutoCAD.

Таким образом, NormaCS оказалась лидером среди нормативно-справочных систем и была выбрана Северным ПКБ для интеграции в производственный цикл в качестве мощного инструмента информационно-нормативного обеспечения.

Фонд действующих (межгосударственных, национальных и отраслевых) стандартов на бумажных носителях, имеющийся в Северном Бюро, составляет 6 738 единиц. Актуализация стандартов на бумажных носителях выполняется постоянно на договорной основе с ФГУП «Стандартинформ» и НИИ «ЛОТ».

На базе ПО NormaCS в ОАО Северное ПКБ» проведено внедрение электронной библиотеки национальных, межгосударственных стандартов, а также нормативных документов судостроения (903 единицы). Используется сетевая версия (плавающая лицензия на 50 клиентских мест) NormaCS для обработки и просмотра документов. В процессе внедрения использована одна из важных функций ПО NormaCS — возможность самостоятельно силами предприятия создавать БД нормативных документов, например, внутренних стандартов. Такая БД была создана на Северном ПКБ.

В настоящее время каждая проектная организация, каждое промышленное предприятие, получая более менее серьезный заказ, осознают, что без средств автоматизации не достичь высокого качества и скорости выполнения работ. То же происходит и в судостроительной отрасли. Заказчик, размещая заказ на проектирование или строительство судна, смотрит не только на высокое качество выполненной работы и соответствие мировым стандартам, но и на методы выполнения данной работы. Одной из определяющих является качество и сроки выполнения проектно-конструкторской, рабочей и технологической документации с применением систем автоматизированного проектирования. Внедрение на предприятии САПР является трудным, но необходимым шагом.

Литература:

Михайлов С., Резник Б., Казанцева И., Гимейн Л. Опыт внедрения NormaCS на ОАО «Адмиралтейские верфи», // Корабел. — 2013. — № 3 (21).
Румянцев Ю., Фофанова В., Фертман И., Попов К. Информационная система нормативных документов для предприятий судостроения, // CAD Master — 2008. — № 31.
Решения АСКОН и опыт внедрения на предприятиях судостроения // Автоматизация проектирования URL: https://machinery.ascon.ru/source/articles/vnedrenie_na_predprijatijah_sudoctroenija.pdf (дата обращения: 15.04.2017).

Основные термины (генерируются автоматически): система, CAD, специализированная судостроительная система, CAPP, DEFCAR, PDM, TRIBON, автоматическое проектирование, проектирование, процесс внедрения.

Ключевые слова

САПР, судостроение, судоремонт, системы автоматического проектирования

Представляем: Автоматизация системы проектирования — Блог Anima

Время чтения: 5 минут

Я рад объявить о запуске Автоматизация системы проектирования от Anima !

Цель Anima с автоматизацией системы дизайна — помочь командам разработчиков, дизайнерам и разработчикам создавать и поддерживать системы дизайна более эффективно с помощью автоматизации. Это увеличивает скорость проектирования и разработки и сокращает жизненные циклы разработки продукта. Получите доступ здесь

Будущее продуктового дизайна и внешнего интерфейса

Компания Gartner недавно представила компанию Anima как важного поставщика в области проектирования для кодирования и яркий пример современного подхода «от проектирования до разработки». С более чем 400 тысячами установок в сообществе Figma, Anima является интеграцией №1 в категории «разработка» на Figma. Мы находимся на пороге перехода от дизайна к коду и определяем будущее технологии, которая его поддерживает.

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

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

ИИ уже творит чудеса с кодом и дизайном. ChatGPT уже может кодировать определенный метод и обычно делает это хорошо. Midjourney может рисовать красивые простые интерфейсы в виде одного изображения. Искусственный интеллект Anima может преобразовывать дизайны Figma/XD/Sketch в статические React и HTML. Но это только начало.

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

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

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

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

Системы дизайна

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

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

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

Математика проста: имея 100 компонентов в дизайн-системе, и каждый компонент требует 3 дня для обслуживания в Figma в год (таблицы, диаграммы, древовидные представления и многовариантные карты — одни из самых сложных), вы понимаете что по крайней мере 1 дизайнер работает полный рабочий день на обслуживании .

Единый источник достоверной информации: Код

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

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

Как работает автоматизация системы проектирования

Anima согласовывает команды UX и разработчиков интерфейса с современной системой проектирования в Figma. Благодаря единому источнику достоверной информации, основанному на вашем коде, команды могут быстрее создавать надежные продукты, пропуская работу по обслуживанию проекта и улучшая взаимодействие между дизайнером и разработчиком.

1. Превратите свой сборник рассказов в библиотеку Figma с помощью Anima:

Непрерывные обновления — Anima будет отправлять обновления из кода в Figma.
Варианты Figma — Anima будет преобразовывать состояния кода в родные варианты Figma .
Auto Layout — Anima автоматически создает автомакет на основе CSS.

2. Создавайте быстрее с фрагментами кода Anima:

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

Присоединяйтесь к нам в построении будущего масштабной разработки продуктов

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

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

Автоматизация системы проектирования. Есть много вещей, которые нужно учитывать, когда… | Джефф Чу | _carbondesign

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

Наша команда предоставляет набор компонентов IBM.com (с использованием системы Carbon Design под капотом), необходимых для создания опыта IBM.com в React и веб-компонентах. В дополнение к самим компонентам существует множество общих утилит, сервисов и стилей (среди других общих ресурсов) между двумя предложениями. Все это размещено в монорепозитории, чтобы наилучшим образом управлять этими пакетами в унисон.

Наша команда активно работает над улучшением Carbon для IBM.com и выпускает выпуск каждые три недели. Между релизами мы выпускаем канареечную версию дизайн-системы при каждом слиянии кода. Мы также публикуем ночные выпуски и выпускаем кандидатов в периоды заморозки кода.

Чтобы обеспечить контроль качества всего, что мы предоставляем, мы создаем предварительные версии развертывания в каждом запросе на включение. Базовый уровень, который создается автоматически, — это наши экземпляры сборника рассказов React и веб-компонентов (и версия React-оболочки веб-компонентов в сборнике рассказов), а также последующие тестовые приложения для каждого из них, такие как приложение NextJS и приложение руля веб-компонентов. Дополнительные метки также могут быть добавлены к запросам на вытягивание, чтобы инициировать развертывание предварительных просмотров версий сборников с письмом справа налево (RTL) и специальных экспериментальных версий сборников рассказов, которые будут отображать компоненты за флагом функции.

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

Мы очень рано перенесли весь процесс сборки на внутренний сервер IBM Jenkins, на котором работают агенты в кластере Kubernetes, и разместили собственный агент образа докера во внутренней Artifactory IBM. Все предварительные версии развертывания размещаются в IBM Cloud. Этот шаг дал нам большую гибкость для масштабирования нашего уровня тестирования на несколько репозиториев и оценки последующего воздействия, а также более целенаправленного интеграционного тестирования. Интеграционное тестирование включает в себя создание изолированных развертываний наших примеров codeandbox, а затем запуск тестов cypress e2e.

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

Визуальное регрессионное тестирование с помощью Browserstack Percy

После объединения запросов на вытягивание оживает еще больше роботов нашей команды. Canary-версия дизайн-системы автоматически публикуется в общедоступном NPM. Для каждой имеющейся у нас перестановки сборника рассказов существует канареечная версия, которая также размещена в IBM Cloud. Они обновляются, как только становится доступной новая канареечная версия. Специально для веб-компонентов наша команда также предоставляет CDN-версии каждого компонента, которые автоматически публикуются каждые 9 дней. 0115 canary , next (кандидаты на выпуск) и последний выпуск .

Когда приходит время вырезать релиз, мы замораживаем код в ветке релиза. Оттуда релиз-кандидаты публикуются в NPM, а наши промежуточные среды для сборника рассказов и последующих тестовых приложений обновляются последней версией релиз-кандидата для регрессионного тестирования. Все необходимые анонсы делаются в нашем внутреннем IBM Slack, а релизы создаются в Github. Если необходимы какие-либо исправления, они создаются в ветке выпуска, а затем объединяются обратно в основную ветку, чтобы поддерживать ее в актуальном состоянии.

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

После выхода полной версии (NPM и CDN) наши производственные сборники историй автоматически обновляются и публикуются, а также обновляются зависимости в наших последующих тестовых приложениях. У нас также есть версии шаблонов наших тестовых приложений для групп разработчиков приложений IBM.com, которые хотят их использовать (шаблоны NextJS и веб-компонентов), которые также автоматически обновляются с помощью последней версии .

Еще один важный аспект, который следует учитывать применительно к нашей системе проектирования, — это постоянная синхронизация с системой Carbon Design. Как и другие упомянутые задачи, это управлялось вручную всякий раз, когда нас уведомляли об обновлениях в слабом канале Carbon Design System. Сегодня у нас есть задание cron в Jenkins, чтобы всегда проверять, есть ли новая версия, которая автоматически создает запрос на включение для обновления наших репозиториев, если новая доступна. Мы в полной мере используем предварительное тестирование изолированного развертывания (особенно визуальное регрессионное тестирование Перси), чтобы увидеть, есть ли какое-либо негативное влияние на последующие этапы при внесении изменений вышестоящего уровня.

Наш бот для обновления следит за тем, чтобы у нас всегда была последняя версия Carbon Design System

На нашем веб-сайте с документацией также есть собственный «бот для обновления» для темы Carbon Gatsby. Это гарантирует, что он всегда будет соответствовать предполагаемому цифровому опыту для сайтов документации IBM Design.

Дженкинс упоминался несколько раз, так как он используется в значительной части нашего общего рабочего процесса доставки. Наша команда также использует Github Actions, где это применимо. Общая стратегия, которой мы следовали, заключается в том, что если есть какие-либо задачи, которые должны выполняться с разветвленными репозиториями без раскрытия конфиденциальных токенов, они управляются за нашим брандмауэром в Jenkins. Любые задачи, которые также требуют выполнения за брандмауэром (например, развертывание в нашей CDN или производственной среде), также находятся в Jenkins. Как вы понимаете, Дженкинс постоянно чем-то занят. Вот почему мы будем определять любые задачи, которые имеет смысл запускать в Github Actions везде, где это возможно. Это включает в себя выполнение непрерывных интеграционных тестов для запросов на вытягивание, канареечную публикацию NPM и развертывание в более низких средах из источника или отправку диспетчерских сообщений в другие наши репозитории с открытым исходным кодом для запуска последующих развертываний.

В конце концов, команда Carbon for IBM.com состоит из звездной группы дизайнеров, разработчиков, менеджеров по продуктам и проектам, а также аналитиков по обеспечению качества. Наши блестящие сотрудники работают над опытом, создают инструменты, обеспечивают непосредственную поддержку наших команд разработчиков приложений и предоставляют Carbon наилучшим образом для IBM.

Саргорстрой

Системы автоматического проектирования: системы автоматизированного проектирования: что такое САПР, разновидности, применение, функционал

НОУ ИНТУИТ | Лекция | Системы автоматизированного проектирования (САПР) РЭС

4.

4.2. Принципы создания систем автоматизированного проектирования конструкции и технологии

Системы автоматического проектирования в судостроении

Ключевые слова

Похожие статьи

Преимущества CALS-технологий и культуры

Анализ и перспективы развития

Подготовка специалистов в области PLM/

Применение макросов при

Исследование

Компьютерное моделирование в России | Статья в журнале…

Использование современных информационных технологий

Оптимизация времени