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

Содержание

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

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

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

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

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

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

< Лекция 6 || Лекция 7: 12 || Лекция 8 >

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

Ключевые слова: ПО, САПР, проектная организация, автоматизация, работ, очередь, опыт, проектная операция, объект автоматизации проектирования, объект проектирования, технологический процесс, операции, средства автоматизации, эскизный проект, процесс управления, компоновка, интерактивный режим, мощность, имитационное моделирование, Макетирование, критерий эффективности, АСУТП, связность, информационное согласование, технические характеристики, контроль, ветвь, интегральная схема, страта, MCAD, CAE, CAD, CAM, software, hardware, конструирование, ACI, логическое проектирование, VHDL-T, MathCAD, функциональная схема, топология, проектная процедура, проектирующие подсистемы, обслуживающие подсистемы, аппаратные средства, периферийное устройство, линия связи, математическое обеспечение, этап жизненного цикла, технологическая подготовка производства, минимизация, удобство эксплуатации, автоматизированная система, АС, координация, component, supplier, SCM, ERP, MRP, MES, покупатель, e-crm, t-commerce, управление данными, PDM

intuit.ru/2010/edi”>Основное назначение лекции – показать сущность процесса проектирования РЭС, основные принципы проектирования. Особенное внимание уделяется системному подходу к проектированию конструкции и технологии производства РЭС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. 2. Принципы создания САПР конструкции и технологии

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

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

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

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

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

Дальше >>

< Лекция 6 || Лекция 7: 12 || Лекция 8 >

Автоматизация системы проектирования. Есть много вещей, которые нужно учитывать, когда… | Джефф Чу | _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 дней.0017 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.

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

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

Автоматизация системы проектирования и адаптация рабочего процесса — пример из практики | by Roberto Herrera

Целью этого тематического исследования является хроника того, как я создал первую систему дизайна Burberry, внедрил и автоматизировал рабочий процесс кампании по электронной почте и перенес систему дизайна из Sketch в Figma. Я покажу, как я разработал экосистему плагинов для создания адаптивных шаблонов в Sketch и Figma. Это исследование расскажет о моем процессе, а также об инструментах и ресурсах, которые я использовал для создания и внедрения системы.

Проблема

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

Кампании по электронной почте Burberry 2018

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

Я присоединился к команде цифрового дизайна Burberry в январе 2019 года. Мы решили начать наше исследование с определения возможных решений проблемы, и вот что мы делали в течение первых четырех месяцев, пока год спустя не перенесли нашу систему в Figma.

В наши дни у компаний нет времени и/или ресурсов для ежедневного повторения процессов. Вот почему так важно автоматизировать как можно больше. Дизайн-система позволяет вам централизовать источник информации и создавать многократно используемые компоненты и возможность их настройки. Это также:

Экономит время на ваших процессах;
Обеспечивает согласованность UX и UI;
Снижает затраты для разных команд;
Увеличивает и продвигает инновации;
Обеспечивает совместную работу;
Ускоряет итерации и обновления.

Что такое дизайн-система?

Дизайн-система — это совокупность элементов, помогающих более надежно строить сложные конструкции; классическое руководство бренда по стероидам. Это мое определение дизайн-системы, ниже вы можете найти еще несколько:

«Система дизайна — это набор стандартов для дизайна и кода, а также компоненты, объединяющие обе практики. Думайте об этом как об одинаковых инструкциях и наборах Lego для всех».

Uxpin

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

UX Collective

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

Какую систему проектирования следует использовать?

Существует множество различных методологий создания дизайн-системы, вот некоторые из них:

Atomic Design Брэда Фроста
Full-stack дизайн-система Emmet Connolly
Material Design от Google
Fluent Design System от Microsoft

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

Так выглядит наша дизайн-система.

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

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

Инвентаризация

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

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

Необработанная коллекция компонентов

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

Аудит

Сначала я проверил кадры изображения, что позволило бы мне определить соотношение сторон кадра изображения, которое я затем использовал бы для определения моей базовой сетки. В этом случае я использовал соотношение сторон 4:5 для изображений кампании и соотношение сторон 3:4 для плоских продуктов. Это были пропорции, предоставленные отделом фотографии, и, таким образом, эти активы уже были утверждены. Использование стандартного соотношения сторон внутри компании для уже утвержденных ресурсов, естественно, сэкономит время в процессе и обеспечит согласованность на разных платформах и каналах.

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

Проверенная инвентаризация

Почему структура?

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

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

Руководитель проекта;
Конструктор;
Создатель контента;
Помощник по маркетингу;
Проявитель.

Окружающая среда

Изменения всегда касаются более чем одного человека, и в данном случае идея системы проектирования на основе шаблонов коснулась и двух других команд:

Дизайн : большую часть времени команды копировали и вставляли копии и искали активы, а затем переходили туда и обратно, чтобы утвердить эти активы. Во-первых, я понял, что нам нужно найти инструмент, который позволил бы нам вытащить содержимое из текстового документа в дизайн, найти решение было непросто — странно, не так ли? Затем я нашел Content Sync, плагин для Sketch App. Дэвид Броди проделал потрясающую работу тогда — год назад — верьте или нет, в то время, кроме их плагина, надежного решения не существовало — пожалуйста, загляните на их веб-сайт, если вы используете приложение Sketch или AdobeXD. пользователь. Кроме того, команда по маркетингу изменила привычный способ работы и начала назначать активы для кампании еще до того, как она была разработана, что помогло нам сэкономить больше времени.
Маркетинг : ухватившись за идею шаблонов, мы получили возможность заранее планировать способ общения с нашей аудиторией. Нам нужна была эта команда, чтобы помочь нам, выбрав шаблоны в зависимости от количества сообщений, которые они хотели отправить, и предварительно назначив ресурсы. Они проделали отличную работу, и вскоре мы увидели, что KPI растут месяц за месяцем. Это дало два основных преимущества: во-первых, мы сэкономили огромное количество времени, получив предварительное одобрение ресурсов, а во-вторых, команды смогли заранее планировать кампании и избегать повторения используемых ресурсов.
Контент : извлек выгоду из этих решений, поскольку они могли создавать копии в зависимости от назначенных активов. Поскольку мы стандартизировали наши электронные письма, они заранее знали количество символов, которое они должны были предоставить для каждого текстового поля. Переход на электронные таблицы Google принес некоторые функции, такие как: простой поиск и ссылка на документы по URL-адресу, подсчет символов в ячейке, индекс используемых терминов, простое комментирование, извлечение информации из переводных документов или создание внутренних сценариев в Документах Google.

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

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

Требования:

Быстрая доставка;
Фокус стратегии;
Особые сообщения;
Консистенция.

Система шаблонов

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

Требования:

Синхронизация контента;
Автомакет;
Шаблоны;
Быстрая доставка.

Синхронизация контента в приложении Sketch

Создание контента: Группа контента получает электронную таблицу Google с конкретными полями, которые им нужны, и готовый макет с активами кампании. В документе они могут найти полезные ссылки о продвигаемых продуктах или URL-адреса CTA. Они могут отмечать, комментировать и оставлять отзывы в документе, а также получать уведомления в свой почтовый ящик, чтобы с меньшей вероятностью пропустить информацию. Кроме того, в этом формате у них есть возможность отслеживать кампании, подсчитывать и индексировать весь словарь, используемый в кампаниях, и создавать внутренние сценарии для любых новых функций, которые мы хотели бы добавить, таких как система статусов, индекс кампании, извлечение информации из разных ячеек. или вкладки кампании.

Требования:

Отслеживание;
Вытягивание или отправка содержимого;
Совместное использование;
Комментарий и тег;
Автоматизация задач;
Словарный указатель;
Индекс кампании.

Пример Google Spreadsheet

Экосистема

Чтобы все предыдущие решения работали, нам нужно было создать экосистему, которая обслуживает систему и задействованные команды.

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

Через год мы решили перенести дизайн-систему на Figma. В то время они уже разработали свою экосистему подключаемых модулей и отлично поработали над своим подходом.

Редактировать

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

Структура папок сервера;
Файлы эскизов;
Плагины Sketch;
Структура Google Диска;
Таблица Google;
Поток асан.

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

Мы определили следующее:

Структура и правила системы дизайна;
Соглашение об именах;
Связь с Content Sync и Google Spreadsheet;
Слоистая структура;
Сетка;
Структура типографики.

Сборка

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

Вы обнаружите, например, что при автоматической компоновке (Anima Tool Kit) некоторые правила противоречат друг другу, и вам необходимо понять порядок, в котором правила применяются к вложенному компоненту.

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

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

Evolve

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

У меня произошла серьезная эволюция, когда мне пришлось перенести систему с приложения Sketch на Figma. К счастью, этот бизнес-запрос появился после того, как Figma вложила некоторые ресурсы в собственную экосистему плагинов — отличная работа, команда Figma. Это означало, что у меня были все необходимые плагины и функции.

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

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

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

Создание email-кампании в Figma

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

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

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

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

Если у вас есть какие-либо вопросы об автоматизации систем проектирования и о том, как вы можете внедрить ее в свою работу, пожалуйста, свяжитесь со мной.

Я создал этот раздел, чтобы предоставить некоторые полезные ресурсы, которые я использовал в своем процессе.

Что, черт возьми, такое дизайн-система?: https://uxdesign.cc/what-the-heck-is-a-design-system-c89a8ea73b0d

Atomic Design Брэда Фроста: https://atomicdesign.bradfrost. com/

Система полного стека дизайна от Эммета Коннолли: https://www.

Саргорстрой

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. 2. Принципы создания САПР конструкции и технологии

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

Автоматизация системы проектирования и адаптация рабочего процесса — пример из практики | by Roberto Herrera

Проблема

Что такое дизайн-система?

Какую систему проектирования следует использовать?

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

Инвентаризация

Аудит

Почему структура?

Окружающая среда

Экосистема

Редактировать

Сборка

Evolve

Добавить комментарий Отменить ответ