Реализация практик моделеориентированной системной инженерии в комплексном PLM-решении от Siemens Digital Industries Software

Станислав Щейников,
заместитель генерального директора по комплексным проектам ГК «ПЛМ Урал»

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

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

Моделеориентированная системная инженерия

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

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

Если акцентировать внимание на технических аспектах системной инженерии, то они направлены на:

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

Чтобы обеспечивать создание успешных изделий, системная инженерия как дисциплина непрерывно развивается, делая упор в своих процессах на применении на всех стадиях жизненного цикла компьютерных моделей различной степени абстракции и детализации. Такой подход называется моделеориентированная системная инженерия (Model Based Systems Engineering, MBSE).

Компания Siemens Digital Industries Software уверенно отвечает на актуальные потребности рынка, и сегодня ее комплексное PLM­решение позволяет организовать процессы управления жизненным циклом изделия на основе практик моделеориентированной системной инженерии.

Центральным компонентом PLM­решения Siemens Digital Industries Software является PDM­система Teamcenter, которая обеспечивает централизованное хранение, управление и доступ к данным. Teamcenter позволяет управлять инженерными процессами, планировать и контролировать работы, объединять разрозненную информацию в единую управляемую конфигурацию изделия.

Работа с требованиями

Основой процессов проектирования являются требования: от того, насколько правильно и эффективно организована работа с требованиями, зависит успешность последующих стадий жизненного цикла изделия. Функционал Teamcenter позволяет сделать работу с требованиями максимально эффективной. Пользователи имеют возможность формализовать требования в виде отдельных управляемых объектов, объединяемых в спецификации требований. Каждое требование насыщается атрибутивной информацией, проходит процедуру согласования и утверждения. Требования связываются с другой инженерной информацией (дочерними требованиями, функциями, элементами архитектуры, элементами конструкторского состава, технологией, результатами инженерных расчетов, доказательной документацией), что позволят добиться прозрачности, реализовать прослеживаемость требований и упростить анализ влияния вносимых изменений.

Определение архитектуры

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

Мультидоменная архитектурная модель

Результатом процесса определения архитектуры является мультидоменная архитектурная модель (рис. 1). Ее ключевая задача — формирование единого и в то же время многоаспектного представления проектируемого изделия для всех заинтересованных сторон. Такая модель объединяет описание всех систем и подсистем изделия, а также их взаимосвязи — независимо от их физического домена, аппаратной или программной реализации.

Рис. 1. Мультидоменная архитектурная модель

Основным инструментом для формирования мультидоменной архитектурной модели в рамках PLM­решения Siemens Digital Industries Software является программный продукт System Modeling Workbench (SMW). Разработка мультидоменной архитектурной модели в SMW базируется на методике ARCADIA, что отличает SWM от других продуктов для архитектурного проектирования, не предлагающих стандартизованных процессов построения архитектуры.

Разработка архитектуры по методике ARCADIA состоит из пяти шагов:

1. Операционный анализ. Разработчик концентрируется на анализе потребностей и целей заказчиков. Результатом этого этапа проектирования является эксплуатационная архитектура, описывающая потребности с точки зрения пользователей (включая сценарии эксплуатационного использования с параметрами измерения и эксплуатационными ограничениями, такими как безопасность, жизненный цикл и т.д.).
2.  Системный анализ. Результаты этого этапа состоят из описаний функциональных потребностей системы (функции, функциональные цепочки, сценарии), взаимодействия с пользователями и внешними системами (функции, функциональные связи и обмены, нефункциональные ограничения), а также требований к системе в целом.
3.  Определение логической архитектуры. На этом этапе работа направлена на построение укрупненной компонентной структуры системы, несущей наиболее важные инженерные решения (с использованием функций, интерфейсов, потоков данных, поведения и т.д.).
4.  Определение физической архитектуры. Разрабатывается «конечная» архитектура системы в виде физических компонентов и их интерфейсов (рис. 2).
5.  Формирование контрактов на разработку. Результатом этого этапа являются структуры разбивки конечного продукта и модели, описывающие спецификацию каждой подсистемы, аппаратного или программного компонента.

Рис. 2. Фрагмент физической архитектуры масляной системы ГТД

Мультидоменная архитектурная модель хранится в среде Teamcenter для обеспечения доступа к информации всех заинтересованных сторон. На функции, логические, физические компоненты и их интерфейсы выполняется аллокация (распределение) требований. Структура требований создается и управляется средствами Teamcenter; трассировка обеспечивается за счет интеграции Teamcenter и SMW.

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

Детальное проектирование

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

• механическая часть разрабатывается в CAD­системе NX. Входом в этот процесс служит декомпозиция с уровня физической архитектуры, а также выходные данные средств проектирования электрики и электроники (EDA). Выходом является детально проработанная геометрия в виде электронной модели всего изделия;
• проектирование электрики и электроники реализуется средствами линейки продуктов Mentor (Capital и Xpedition). Входом в этот процесс служит архитектура электрических и электронных систем, выделенных из общей мультидоменной архитектурной модели, с уровня физической архитектуры SMW. Выходом являются новые системные требования, модель электрической системы, схема соединений, топология печатной платы. Часть этих данных используется в CAD­системе NX для 3D­моделирования электрических и электронных компонентов (кабелей, жгутов, соединителей, печатных плат и др.) в рамках общей электронной модели всего изделия;
• разработка встроенного ПО выполняется с помощью связки Capital Software Designer и ALM­системы Polarion. Входом для разработки ПО служат требования и мультидоменная архитектура. Это решение закрывает полный цикл задач по разработке и управлению жизненным циклом встраиваемого ПО, поэтому последующая декомпозиция и управление системными требованиями, разработка архитектуры ПО, планирование и реализация тестов, управление версиями разработки ПО выполняется средствами Polarion и Capital Software Designer. Выходом является конкретный релиз программного кода.

Вся информация, выходящая из обозначенных систем, аккумулируется и управляется функционалом Teamcenter.

Верификация и валидация

Особой задачей MBSE является планирование, реализация и контроль процессов оценки соответствия (верификации и валидации).

Требования, имеющие численные значения, могут быть представлены в Teamcenter в виде отдельных объектов типа «Атрибут» с указанием его номинального значения, а также возможных отклонений. Процедуры оценки соответствия в Teamcenter могут быть запланированы (для каждого требования в отдельности или для группы требований) через формирование запросов на анализ. К запросу на анализ прикрепляются контролируемые требования и их параметры, указываются методы оценки соответствия, виды доказательной документации.

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

Рис. 3. Схема процесса планирования и контроля оценки соответствия в среде Teamcenter

Компания Siemens Digital Industries Software предлагает полный набор решений для реализации процесса оценки соответствия в цифровом виде:

для оценки соответствия мультидоменной архитектуры или ее отдельных системных компонентов применяется метод 1D­анализа. Системы 1D­моделирования и анализа позволяют определить соответствие выбранной архитектуры системным требованиям или подобрать обоснованные системные требования к системным компонентам. На базе имитационной 1D­модели выполняется валидация системы управления применительно к объекту управления (SiL). В линейке Siemens Digital Industries Software эту задачу решает набор продуктов Simcenter System Simulation (в первую очередь System Architect и Simcenter Amesim). Входом являются требования, мультидоменная архитектурная модель из SMW, результаты других процессов (например, 3D CAE­анализа, учитывающего геометрические характеристики системы, код управляющей программы);

• для оценки надежности и отказобезопасности на базе таких методик, как RAMS и FMEA, используется решение MADe (PHM Technology). В качестве входной информации применяются требования, функциональная модель из SMW и электронный состав изделия. Выходом является оценка соответствия. Отдельно для FMEA­анализа может применяться модуль FMEA QMS­системы Opcenter Quality;
• часть требований может быть верифицирована средствами системы NX — например соответствие требованиям по массе, по геометрии (присоединительные, габаритные размеры), по технологичности;
• для оценки соответствия результатов проектирования в виде геометрических данных (3D­модели) применяется группа продуктов Simcenter CAE Simulation, включающая такие инструменты, как Simcenter STAR­CCM+, Simcenter 3D, NX Nastran, Simcenter Flotherm и др. Результаты подобной верификации и валидации служат исходными данными для уточнения мультидоменной системной архитектуры, на основе которой уточняется имитационная 1D­модель;
• часть инструментов верификации и валидации встраивается в системы проектирования — такие инструменты есть в арсенале Capital, Xpedition, Polarion, NX.

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

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

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

Преимущества программных решений от Siemens

Выбрав для себя ПО от компании Siemens Digital Industries Software, вы обеспечиваете решение как существующих, так и перспективных задач с применением передовых подходов и методик (рис. 4).

Рис. 4. Укрупненная схема реализации MBSE с помощью инструментов Siemens Digital Industries Software

Использование практик MBSE и инструментов Siemens Digital Industries Software дает возможность:

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

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

ГК «ПЛМ Урал» уже имеет практический опыт внедрения практик и инструментов моделеориентированной системной инженерии (www.plm­ural.ru/sdpd) на базе решений Siemens Digital Industries Software. Мы готовы предоставлять необходимые методики, поставлять программные инструменты, помогать перестраивать существующие процессы, обучать сотрудников и обеспечивать постпродажное обслу