Андрей Карпушин, главный функциональный архитектор САРУС+ PLM, НКК
Алексей Сулинов, главный технический архитектор САРУС+ PLM, НКК
Андрей Слюняев, директор по разработке САРУС+ PLM, НКК
Когда в 2022 году мы начинали проект САРУС+, перед нами стояла амбициозная задача: создать PLM-систему, которая сочетает современные ИТ-подходы и архитектуру, гибкость, адаптивность к процессам заказчика и соответствие жёстким требованиям российских регуляторов. САРУС+ — это инструмент управления жизненным циклом изделия, построенный на принципах открытости и возможности глубокой кастомизации. Управление жизненным циклом реализовано, как сквозной связанный процесс в единой среде, где каждое решение в модели данных, архитектуре и интерфейсе подчинено одной цели — сделать управление изделием прозрачным, быстрым и удобным для всех участников.
Нюансы работы с такой системой не лежат на поверхности. Модель данных, подход к сборкам и конфигурированию, работа со связями — все это требует глубокого понимания проблематики, с которой сталкиваются современные предприятия машиностроения и приборостроения. В этом материале мы разложим по полочкам архитектуру САРУС+, покажем ключевые отличия от привычных PLM-решений и дадим практическое описание механизмов работы системы, включая сквозные сценарии от проектирования до технологической подготовки производства. Мы постарались простым языком рассказать о сложных вещах. Насколько это удалось – судить читателям.
Рабочий стол САРУС+ PLM
Архитектура: от микросервисов до рабочего места
Архитектура САРУС+ строится вокруг принципа разделения ответственности. Вместо «монолита», характерного для многих отечественных систем, мы спроектировали решение как многоуровневую конструкцию, где каждый слой решает свой класс задач, а взаимодействие между слоями и внутри слоев строго регламентировано открытыми интерфейсами.
Первый уровень — клиентский. Здесь система намеренно разделена на два независимых интерфейса, каждый из которых оптимизирован под свой класс задач.
Первая часть клиентского уровня – веб-интерфейс. Работает через браузер и отвечает за всю «информационную» работу: действия с объектами, управление структурой изделия, разработку технологии, маршрутов изготовления и нормирования материалов, работу со справочниками и документами, запуск рабочих процессов для согласования данных. Это дает пользователям независимость от рабочего устройства там, где она действительно необходима: конструктор может работать за мощной рабочей станцией, а мастер, контролер или рабочий в цехе — открыть ту же электронную модель, чертеж или техпроцесс на защищенном планшете с сенсорным экраном прямо у станка или на самом станке. Вся бизнес-логика, связанная с обработкой данных, выполняется на сервере, а браузер выступает исключительно как средство отображения информации – посредник между человеком и актуальными инженерными данными.
Вторая часть клиентского уровня — единое десктопное приложение САРУС+ CAx. Это среда для работы с геометрией (CAD), где выполняется трехмерное моделирование и оформление документации, инженерные расчеты (CAE) и подготовка управляющих программ для станков с ЧПУ (CAM). Уникальность системе добавляет приложение САРУС+ Композиты, предназначенное для проектирования изделий из полимерных композиционных материалов. Все четыре приложения внутри одного продукта связаны сквозной ассоциативностью. Такой подход привычен для инженеров, производителен и не требует переучивания.
При этом оба клиента (веб-клиент и десктопное приложение) работают с одними и теми же данными через единое хранилище, что исключает рассинхронизацию, а САРУС+ CAx предоставляет функционал бесшовной интеграции с PLM-системой, механизм работы которой описан далее в этой статье.
Второй уровень – серверный – является двухуровневой конструкцией.
Нижний уровень серверной части — это сертифицированные ФСТЭК компоненты (до второго уровня доверия), которые вместе выполняют роль «умной базы данных». Совместно они отвечают за низкоуровневые операции и часть задач администратора системы:
- базовый слой логики работы с объектами без специфики МД и автоматизации,
- безопасный доступ к таблицам СУБД,
- менеджер модели данных,
- управление пользователями и правами (включая мандатный доступ, реализованный на уровне ядра),
- шаблонизатор рабочих процессов (workflow),
- генератор отчетов.
Верхний уровень серверной части — слой микросервисов, реализованный на современном технологическом стеке и последних достижениях ИТ-отрасли, в котором сосредоточен пользовательский функционал системы. Именно здесь работает новая бизнес-логика САРУС+, отличающаяся от традиционного подхода: алгоритмы создания и ревизионирования объектов, управления конфигурациями изделия и интеграции с САПР, работы со связями и их атрибутами как с полноценными объектами, а также расширенного управления изменениями с автоматическим расчетом пересечений применяемости.
Архитектура САРУС+ PLM
Микросервисная архитектура дает принципиальное преимущество: заказчик или системный интегратор может проводить индивидуальную настройку системы, добавляя собственные микросервисы или заменяя ими существующие, не нарушая логику (контракты) взаимодействия сервисов и не попадая в зависимость от разработчика. Для этого в САРУС+ предусмотрены открытый API-слой и документированные интерфейсы взаимодействия, через которые можно модифицировать систему теми же средствами, что используются разработчиками. Впервые разработчик предлагает свободно заменять отдельные части системы, сохраняя все возможности по обновлению ПО. В комплект поставки системы входит документация разработчика. Она подготовлена в Swagger и позволяет наиболее заинтересованным специалистам попробовать пообщаться с системой на программном уровне. Процесс взаимодействия и примеры запросов являются неотъемлемой частью документации.
Как известно, микросервисы позволяют выполнять горизонтальное масштабирование, что дает предприятию возможность не только гибко реагировать на растущую нагрузку, но и менять составные микроприложения под потребности конкретного заказчика. Система приспособлена к этому из «коробки». Наша команда разработчиков готовит к публикации отдельную статью о микросервисной архитектуре САРУС+, где будет описан наш подход к реализации приложения класса PLM на ее основе.
Документация разработчика
Весь код серверных и десктопных компонентов разрабатывается единообразно, компилируется и собирается под две операционные системы — Windows и Astra Linux. Astra Linux поддерживается нативно, без эмуляции, прослоек или виртуализации, что критически важно для стабильности и производительности при работе с тяжелыми инженерными задачами в CAx. Кроссплатформенность заложена на уровне исходного кода, а не через внешние технические средства. При этом все серверные и десктопные компоненты штатно функционируют под управлением Linux, что соответствует актуальным требованиям импортозамещения и эксплуатации системы в значимых объектах КИИ, приобретающих все большее значение в текущих условиях.
Живым подтверждением архитектурной зрелости служат публичные демонстрации и апробации, которые мы проводим регулярно. Во время таких работ сервер с базой данных и микросервисами размещен в удаленном ЦОДе (что обычно не принято для систем класса PLM, так иногда делают зарубежные разработчики) под управлением Astra Linux, а рабочие места пользователей, например, — в Нижнем Новгороде и Екатеринбурге. В процессе открытых демонстраций пользователи работают с системой через браузер и видят в реальном времени, как она откликается на действия удаленного пользователя. Это не просто демонстрация скорости, а подтверждение готовности платформы к работе на территориально распределенных предприятиях. Но и это не все: команда разработчиков также практически полностью децентрализована. Сотрудники находятся в разных регионах на огромных расстояниях друг от друга — от Крыма до Кузбасса, но вместе работают с одним экземпляром системы из облачного ЦОД. Это дает возможность анализировать скорость работы системы и постоянно работать над повышением производительности и стабильности обмена данными.
Модель данных: вхождение, связи и конфигурирование
Если архитектура — это «скелет» системы, то модель данных — ее «нервная система». В САРУС+ мы реализовали подход, который принципиально отличается от российских систем аналогичного класса, и он описывается тремя ключевыми понятиями.
Первое понятие — «вхождение» вместо классического «подключения». В традиционных PLM-системах для включения детали в сборку создается объект-подключение, связывающий родительский объект с конкретной версией (иногда их называют ревизиями) дочернего объекта. Если у дочернего объекта появляется новая версия, для ее включения в состав родительского объекта требуется создавать новое подключение вручную либо через дополнительные инструменты, увеличивающие трудоемкость работы. В САРУС+ вы один раз указываете, что деталь входит в состав сборки, и система запоминает это как факт вхождения. При появлении новой ревизии детали вам не нужно ничего дополнительно подключать – система автоматически подберет нужную ревизию в соответствии с правилами конфигурирования (например, «брать последнюю утвержденную версию на дату сборки»). В интерфейсе вы видите одно вхождение, но за ним может скрываться целая цепочка версий, и никаких дополнительных действий не требуется.
Второе понятие — «связь-отношение» между объектами как полноценный объект. Вместо того чтобы множить таблицы с дополнительными полями, мы сделали отношение самостоятельной сущностью, у которой могут быть собственные атрибуты.
Визуализация прямых и обратных связей данных в Навигаторе связей
Рассмотрим на примере назначения материала.
В классическом подходе у детали есть поле «Материал», где необходимо выбрать значение из справочника. При этом не существует возможности указать, что одна деталь сделана из листа 2 мм, а другая — из прутка 10 мм, если это одна и та же позиция материала в справочнике. Потребуется завести отдельные позиции или использовать текстовые примечания, что ведет к дублированию и ошибкам.
В САРУС+ между объектом «Деталь» и объектом «Материал» создается объект-отношение «Изготовлено из», у которого есть собственные атрибуты: «Количество», «Тип заготовки» (лист, пруток, поковка), «Примечание». Вы гибко управляете отношениями, и один и тот же материал из справочника может применяться в разных деталях без захламления системы дублями. Такая же логика применима к любым отношениям: на связи документа со сборкой можно указать, будет ли документ входить в спецификацию изделия или нет (эскизный вариант); на связи извещения об изменении с компонентом — характер изменения и указания о внедрении; на связи детали с техническим требованием — конкретный параметр, который это требование определяет. Дополнительным преимуществом использования объектов-отношений является быстрая перенастройка системы под конкретного заказчика. Если в базовой поставке для отношения не определены свойства, а в процессе внедрения потребовалось их добавить, достаточно просто создать параметр внутри объекта-отношения без модификации модели данных и разработки диалоговых окон.
Следствием такого подхода — выделения связей-отношений в виде отдельных сущностей в модели данных — стала возможность работы со связями так же, как и с объектами системы: их можно копировать по одиночке или группой, переносить эти данные на другой объект как без изменений, так и с корректировкой атрибутов. Для этого мы создали в системе продвинутый буфер обмена, который умеет копировать не только объекты, но и связи вместе с их параметрами, а также функцию специальной вставки, которая знает какие атрибуты были у отношений (кстати, тот же механизм применяется и для вхождения объекта в сборку) и позволяет намного быстрее переносить однотипные данные между объектами с корректировкой атрибутов или без.
Третье понятие — динамическое конфигурирование состава. Благодаря описанным механизмам мы можем реализовать конфигурирование не «в лоб по фильтрам» (что, на наш взгляд, является самым простым и наименее гибким способом), а на основе гибких правил, которые применяются в момент доступа к данным. В интерфейсе управления структурой вы задаете правило по дате, и система автоматически подбирает те версии компонентов, которые были актуальны на эту дату. Можно сконфигурировать состав по статусу (например, показать изделие на этапе макета или на этапе серийного производства), по номеру ревизии, дате или по финальному изделию. Самый важный момент: вы можете взять эту сконфигурированную сборку и открыть ее в CAD-системе для дальнейшей работы именно в том состоянии, которое выбрали. Это не фильтрация уже сформированной структуры (при которой можно случайно потерять компоненты и не заметить этого), а гарантированное построение состава на уровне PLM с последующей передачей полученной конфигурации изделия в CAx и ERP. Система явно подсказывает, какие объекты не вошли в собранную конфигурацию, исключая риск потери и неполной передачи данных в производство.
Управление структурой САРУС+ PLM с ошибкой конфигурирования и визуализацией структуры изделия
Визуализация структуры изделия с кросс-подсветкой
Интеграция с CAD и управление изменениями
Наша команда имеет многолетний опыт работы с зарубежным ПО, и API-функционал системы NX нам знаком досконально. Мы использовали NX как полигон для отработки собственных алгоритмов двунаправленной синхронизации с PLM-системой, чтобы затем масштабировать эти наработки на отечественные CAD-системы. На NX мы отточили ключевые механизмы. Двунаправленная синхронизация структуры позволяет конструктору менять состав в CAD, нажать «Сохранить» — и информация автоматически отправляется в PLM-систему без ручных выгрузок, синхронизаций, операций пересчета, обновлений и прочих сценариев, о которых иногда можно и забыть. В такой архитектуре отсутствует понятие самостоятельно живущей локальной копии состава. PLM становится единственным источником актуальных данных, а CAD — инструментом их редактирования. Это работает и в обратную сторону: если изменить состав в PLM, то при следующем открытии сборки в CAD ее состав будет актуальным. Эти механизмы обеспечивают равную значимость и дают равные возможности для проектирования изделия независимо от выбранного подхода: можно начинать с хорошо изученной структуры изделия и двигаться «снизу-вверх», добавляя или заменяя повторно используемые детали и узлы в сборках, либо начинать с идеи об изделии и двигаться «сверху-вниз», начиная с базовой геометрии, от которой происходят построения и детализация до уровня узлов и деталей. Система обеспечивает работу с предварительными электронными структурами изделия в PLM, а также с дальнейшей детализацией их в xCAx и EDA-системах (механика, электрические системы и печатные платы).
Автоматическая передача атрибутов — от простых (масса, геометрические параметры, объем) до более сложных — избавляет конструктора от ручного заполнения сведений об объекте. При сохранении сборки система генерирует JT-файлы (используя возможности самой CAD-системы) — международный формат легковесной визуализации — и прикрепляет их к объектам в PLM-системе. Благодаря этому любой сотрудник может просмотреть 3D-модель прямо в браузере, сделать необходимые измерения, сечения или 3D-пометки.
Главный вызов — не столько интеграция с CAD-системой на уровне NX, сколько обеспечение плавного перехода с зарубежного ПО на отечественное, чтобы выбранная пользователем CAD-система не была проблемой при работе в единой PLM-системе.
С этой целью мы разработали несколько сценариев.
Смешанный режим (MultiCAD) позволяет предприятию одновременно использовать NX и САРУС+ CAD (а скоро и другие общепринятые CAD-системы), работая с одними и теми же структурами изделий. При изменении геометрии или состава в одной системе изменения корректно отображаются в другой, что позволяет вести новые проекты в САРУС+ CAD, а старые дорабатывать в NX без разрыва сквозных процессов. Понятно, что «под капотом» такого механизма работают конверторы форматов и очевидно теряется история построений. Однако такие механизмы и возможности интеграции для «исторических» данных позволяют легче преодолевать критические ситуации, когда 3D-модель нужно изменить здесь и сейчас, а сделать это проще в той CAD-системе, в которой такая модель была разработана.
Один и тот же состав открыт в NX и САРУС+ CAD
Работа в режиме (MultiCAD) невозможна без продвинутого инструмента визуализации, работающего независимо от конкретной CAx-системы и позволяющего просматривать изделие, собранное и сохраненное в разных CAx-системах как единый цифровой макет. Такую возможность в нашей системе обеспечивает Визуализатор.
Функциональные возможности Визуализатора при работе с 3D-геометрией
Для миграции данных PLM-to-PLM мы разработали инструмент, который через PLMXML переносит из Teamcenter не только объекты и структуры, но и все файлы (включая JT для легковесного просмотра) с сопоставлением и, при необходимости, преобразованием атрибутов, типов и связей между объектами. После загрузки сборка может быть открыта как в NX (через интеграцию), так и в САРУС+ CAD — после автоматической конвертации геометрии. Мы полагаем, что настолько полно и привычно реализовать перенос данных из Teamсenter в другие PLM-системы невозможно, поскольку ключевым фактором здесь являются сходные с зарубежной системой подходы к организации модели данных и способу ведения структур изделия. В этом есть и практический смысл: миграция данных из Teamcenter позволяет сохранить их максимально привычный вид и способ работы с ними, а методики работы, которые были разработаны на предприятиях, не потребуют больших изменений. Аналогичный механизм переноса реальных данных мы опробовали и для передачи данных из российских PLM-систем, включая структуры изделия и его геометрические данные. Эта работа была проделана в интересах одного из крупных российских промышленных холдингов и была признана полностью успешной.
Отдельно стоит упомянуть еще одну сущность модели данных – «наборы данных», без которых управление файловыми данными современных приложений было бы очень неудобным. Мы разделяем подход одной из иностранных систем, в которой файлы не существовали сами по себе, а были собраны в логические контейнеры. Практика работы с прикладным ПО говорит нам о том, что такие системы редко хранят данные в одном файле.
Например, как хранить в системе наборы файлов для встроенного программного обеспечения изделия? Как сделать так, чтобы не перемешать их между собой и точно знать какой набор файлов совместим с конкретной ревизией изделия? Ответ прост и давно опробован на практике: объедините их в логические контейнеры и дайте возможность PLM-системе хранить такой набор файлов вместе. В САРУС+ сделано именно так — в наборе данных. Но система должна понимать такой логический объект и уметь оперировать с его содержимым. Для решения этой задачи и для работы с файлами очень большого размера (до 50 ГБ в одном файле, характерные для CAE-систем или отчетов об испытаниях) был разработан специализированный файловый сервер, опирающийся на технологии S3.
Управление изменениями в САРУС+ также опирается на модель данных. При создании извещения об изменении система автоматически анализирует, в какие сборки входят изменяемые объекты, и на основе текущей конфигурации предлагает диапазоны применяемости — с какого и по какой номер или дату действует изменение. Вычисление происходит автоматически на основе пересечения множеств вхождений. Если параллельно готовятся несколько изменений, диапазоны применяемости корректируются динамически: то, что выйдет раньше, повлияет на то, что еще в работе, и система это учитывает.
Сквозные сценарии: от модели до производства
Особенность САРУС+ состоит в том, что он объединяет в едином комплексе CAD-, CAM- и CAE-функционал для выполнения проектно-конструкторских работ и технологической подготовки производства изделий, включая изделия из полимерных композиционных материалов. Это не интеграция разнородных систем, а среда, где инженер любого профиля работает в одном окне. У специалиста появляется возможность использовать мастер-модели и ассоциативные связи: изменение геометрии в мастер-модели автоматически приводит к пересчету всех зависимых компонентов, включая управляющие программы. При изменении размера конструктивно-технологического элемента в детали достаточно выполнить команду «Полный пересчет» в CAM-модуле, и траектории обработки обновятся автоматически без переназначения обрабатываемых граней.
Для технолога-программиста ЧПУ САРУС+ CAM предоставляет полный набор операций: фрезерование (от 2,5D до 5D), точение, обработка отверстий, электроэрозия. Инструмент формируется в виде наладок с режущими элементами, удлинителями, держателями и угловыми головками. Контроль операций возможен тремя способами: прогон инструмента по траектории, имитация с учетом кинематики оборудования и верификация по G-коду. Постпроцессоры настраиваются через генератор постов, позволяя адаптировать выходные данные под конкретное оборудование. Для расчетчика в CAE-модуле доступны создание сетки, наложение кинематических и начальных условий, нагрузок, а также инженерные расчеты зубчатых зацеплений, пружин, подшипников, соединений с интеграцией Logos.
Сквозная 3D-технология: модель, расчет управляющей программы и инженерный расчет
Не секрет, что неотъемлемая часть любого современного изделия – это электронные и электрические компоненты. Как правило, на бытовом уровне это называют «электрика» или «электроника», нередко смешивая между собой два сложных понятия, каждое из которых требует отдельного внимания.
Мы приняли, что «электроника» – это уровень печатной платы. Для работы с такими компонентами существует специальный класс программного обеспечения – системы EDA.
Специально для решения задач разработки печатных плат мы разработали интеграцию с отечественной EDA-системой, которая так же, как и САРУС+, имеет свой API. При разработке печатных плат как и при решении любых других инженерных задач, важно работать с актуальными данными и по единым правилам.
Предложенный нами сценарий выглядит так: в САРУС+ создается проект, который автоматически передается в EDA, библиотечные компоненты синхронизируются с атрибутами и 3D-моделями, а после разработки (равно, как и в любой момент времени при необходимости) проект загружается обратно в САРУС+ вместе со схемой, 3D-моделью платы и отчетными документами. Корректную передачу информации гарантируют программные интерфейсы систем, пользователь исключен из технического процесса обмена информацией.
«Электрика» — это «коробки с печатными платами» или другие компоненты, имеющие электрические интерфейсы, расставленные по всему устройству или изделию и связанные между собой проводами. Из этих проводов формируются жгуты. При кажущейся простоте это очень сложная задача, имеющая очень много тонкостей.
Для решения таких задач применяются eCAD-системы. Совместно с разработчиком одной из отечественных eCAD-систем мы разрабатываем совместные сценарии взаимодействия двух систем и механизмы интеграции с САРУС+. В общем случае разработка электрических схем ведется в eCAD, откуда информация об электрических компонентах и их соединениях загружается в САРУС+ PLM через XML. Затем в САРУС+ CAD выполняется 3D-размещение: компоненты размещаются по изделию, по сплайнам формируются трассы прокладки жгутов, определяются точки крепления жгутов (хомуты), формируется развертка жгута, которая передается обратно в eCAD для выпуска сборочной КД. На стороне САРУС+ CAD остается формирование монтажной КД, спецификации можно сформировать в любой из систем, а согласование удобнее проводить в PLM-системе. В результате в PLM-системе оказывается полная структура изделия: от электрической схемы до 3D-сборки с установленным оборудованием и монтажом жгутов, а с помощью возможностей управления версиями объектов и конфигурирования структур изделия в САРУС+ PLM обеспечивается гибкое и удобное управление полной информацией об изделии (конфигурацией), включая данные электрических, электронных и даже программных составных частей изделия.
Для изделий из композиционных материалов мы разработали модуль САРУС+ Композиты, который является неотъемлемой частью общего CAD/CAE/CAM-модуля и обеспечивает решение задач сквозного процесса послойного проектирования и технологической подготовки производства изделий из полимерных композиционных материалов. Впрочем, совсем недавно на isicad.ru вышла очередная статья о развитии, верификации и валидации функционала этого продукта.
Внимание к удобству пользователей, или почему у нас такой UX/UI
Не секрет, что большинство инженерных систем сложны для освоения, потому что их интерфейс перегружен: пользователю показывают все команды сразу, независимо от контекста задачи, а при выборе цветовой схемы не учитывают психологию восприятия. Но мало кто задумывался, что инженеры, а сейчас и сотрудники производства, взаимодействуют с таким ПО весь рабочий день. Так исторически сложилось, что в момент выбора дизайна есть технологические ограничения стека, есть текущий взгляд на эргономику организации интерфейса, и есть, в конце концов, ограничения по времени и возможностям конкретной команды разработки. Мы наблюдали на примере зарубежного инженерного ПО, как по мере роста его возможностей с завидным постоянством изменялся интерфейс (а точнее совокупность UX/UI): объединялись группы команд, появлялось ленточное меню, добавлялась механика управления отображением команд, контекстные команды-помощники при взаимодействии с геометрией и данными, а теперь уже и ИИ-агенты.
Мы, как команда, обладая, с нашей точки зрения, преимуществом в виде отсутствия накопленного legacy-кода и исторически сформировавшегося дизайна, решили следовать концепции интерфейса, дружелюбного пользователю. Для этого пришлось проделать большую работу, анализируя существующие программы и их функционал не только с точки зрения выполнения задач, но и с учетом того когда, как часто, как долго и с каким настроением все это используется.
В итоге сложились несколько основных подходов, которых мы стараемся придерживаться:
- Программа должна упрощать работу, предлагая только необходимые в конкретный момент инструменты и данные.
- Удобное и естественное управление информацией: нажал, перетащил, бросил — без погружения в многоуровневые меню.
- Настройка рабочей области в соответствии с ролью и предпочтениями пользователя.
- Легкое получение справочной информации в контексте работы.
- Низкий порог входа: не требуются специальные курсы, чтобы начать работу.
- Пользователь должен понимать, что именно он управляет системой, а не система навязывает ему последовательность действий.
- Пользователю должно нравиться то, что он видит на экране. Хорошее настроение – залог успеха.
Мы уверены, что сейчас именно пользователю необходимо уделять основное внимание при разработке программного обеспечения, и вдвойне – при разработке таких проектов, как наш.
Смарт-панель приложения Рабочий стол. При формировании порядка расположения и группировки команд проанализированы данные по более чем 64 вариантам взаимодействия пользователя с системой
Чтобы действительно не упустить этот момент в погоне за функционалом, макеты типовых элементов интерфейса САРУС+ PLM проходят обязательный анализ на интуитивность, читаемость, наглядность и эргономику. Выполняются функциональное прототипирование для выявления особенностей работы функции, UX/UI-макетирование различных этапов сценария работы пользователя и работа с текстовыми сообщениями. Результатом становится выявление точек напряженности пользователя и формирование наглядного сценария работы системы, который упрощает разработчикам задачу создания именно того, что задумано, не забывая об удобстве пользователя.
Макеты модальных окон и секций САРУС+ PLM проектируются с учетом интуитивности, единообразия, значимости и обратной связи интерфейса при работе пользователя с системой.
Продолжением концепции открытости по отношению к пользователям стал простой подход к компоновке интерфейса: визуальное проектирование на базе стандартных компонентов, состав которых опытный пользователь выбирает сам. Открыто практически все: создание нового приложения, управление компоновкой экрана, встраивание приложений в другие приложения, создание групп секций (закладок), создание собственных секций под требования пользователей. Сам по себе подход не нов и вполне привычен в системах класса BI, однако в PLM-системах встречается редко, и мы постарались реализовать его.
Формирование и итоговая индивидуальная компоновка управления структурой в САРУС+ PLM
Панель администратора для создания индивидуальной компоновки системы
Этим подходом мы развиваем идею открытости САРУС+ и стремимся предоставить пользователям максимальную индивидуальность системы. Ведь вряд ли мы сможем предсказать, что именно может понадобиться специалистам при решении своих задач завтра.
Несколько слов о вышедшем релизе
Летним релизом 2026 года (версия 26.2.6) мы представляем рынку новую PLM-систему САРУС+, которая построена на базе открытости, адаптивности и приспособленности «из коробки» к актуальным на сегодня инфраструктурным решениям. Система открыта к модернизации и разработке функционала без вмешательства в исходный код, а также к новым возможностям индивидуальной настройки вплоть до каждого пользователя. Вместе с тем хотим отметить, что архитектура системы позволяет нам вести выпуск скользящих релизов с использованием практик CI/CD без привязки к базовой версии и регулярно выпускать дополнения по мере накопления ценных функциональных улучшений для пользователей.
Узнать о функциональных возможностях системы можно в обзоре нового релиза на нашем сайте https://sarusplus.ru/. Там же заинтересованный читатель может ознакомиться с дополнительными материалами о продукте, а самые любопытные — попробовать систему в работе. Для этого достаточно заполнить форму обратной связи. Система доступна для знакомства в облачном варианте.
PLM-платформа САРУС+ — российская PLM-платформа нового поколения для машиностроения и приборостроения. Объединяет CAD/CAE/CAM/Композиты в едином окне с поддержкой сквозной ассоциативности. Включает веб‑PDM с 3D‑визуализатором, доступным из браузера и не требующим установки CAD. Обеспечивает бесшовную миграцию данных из зарубежных систем тяжелого класса с сохранением связей, атрибутов и привычных сценариев работы. Использует современную микросервисную архитектуру для построения приложений. Весь функционал без исключения доступен нативно как в Windows, так и в Astra Linux. Средства защиты информации сертифицированы ФСТЭК. Платформа внесена в единый реестр российского ПО. Программное обеспечение «САРУС+» создано с использованием и на базе комплекса программ в защищенном исполнении «Система полного жизненного цикла изделий «Цифровое предприятие» © ФГУП «РФЯЦ-ВНИИЭФ».