Управление расчетными данными

Александр Никулин,
архитектор цифровых двойников ГК «ПЛМ Урал»

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

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

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

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

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

В такой ситуации возникает несколько вопросов:

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

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

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

И на рубеже 2010 годов  менеджменту предприятий абсолютно внезапно пришло осознание нескольких фактов:

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

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

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

Во-вторых, существует несколько сотен крупных, коммерчески успешных САЕ-пакетов, а каждое предприятие использует от нескольких десятков до сотен программных кодов собственной разработки. Чтобы выстроить интеграцию со всеми нужными предприятию расчетными модулями, понадобятся годы работы. Именно по этим двум причинам историй об успешном внедрении SPDM во всем мире не наберется и пары десятков.

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

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

Рис. 1. Схема прямой информационной связи от PLM-системы к системе автоматизации расчетов и управления расчетными процессами

Вторым этапом система автоматизации расчетных процессов направляет данные контейнера в соответствующие порты расчетных моделей, конфигурирует очередь задач, отдает команды на проведение обычного или комплексного расчета, проводит предварительную и постобработку данных, при необходимости формирует доказательную документацию: отчет, служебную или пояснительную записку. Доказательная документация и результаты расчета возвращаются в PLM-систему, непосредственно в контейнер, названный для практической реализации в PLM-системе «Запрос на проверку». В зависимости от объема данных осуществляется возврат либо непосредственно файлов результатов и полей параметров, либо ссылки на них. Такой подход позволяет не передавать по корпоративной сети расчетные модели, весящие периодически до десятков терабайт. После возврата данных PLM-система трассирует данные доказательной документации в соответствующие объекты: значения возвращаются в систему управления требованиями и служат для формирования матрицы соответствия, документация возвращается в PDM. Разумеется, каждое движение информации в системах контролируется и проводится в рамках настроенных рабочих процессов (рис. 2).

Рис. 2. Схема обратной информационной связи. Возврат данных в PLM-систему и их трассировка
по целевым объектам

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

Рис. 3. Схема взаимодействия систем при изменении исходных данных, требований и иных артефактов конструкторско-расчетных работ

Именно такой подход совместно реализовали российские компании — разработчики программного обеспечения АО «АСКОН» и ООО «ДАТАДВАНС», выстроив интеграцию между своими продуктами и обеспечив управление рабочими процессами на стороне ЛОЦМАН:PLM,  интеграционные связи с большинством расчетных пакетов и автоматизацию расчетных процессов на стороне DT Enterprise (ранее — pSeven Enterprise). Созданное интеграционное решение отработано специалистами ГК «ПЛМ Урал» на практических задачах совместно со специалистами АО «Объединенная двигателестроительная корпорация» и продемонстрировало богатый потенциал к тиражированию и применению. В настоящее время интеграция постоянно дорабатывается и совершенствуется для обеспечения максимально эффективной работы и по рекомендациям пользователей. Дополнительно ведутся работы по интеграции систем с российской экосистемой цифровых двойников CML-Bench® для обеспечения возможности использования расчетчиками конфигураций изделий, отличных от конструкторской.

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

ГК «ПЛМ Урал» организует вебинар для всех заинтересованных лиц, на котором будет обсуждаться интеграция систем ЛОЦМАН:PLM и DT Seven. Участники смогут узнать, как эти системы могут быть использованы для решения практических задач. Мероприятие пройдет в марте, точная дата будет анонсирована на сайте www.plm-ural.ru.