< Назад к Набор инструментов для моделирования автомобильной отрасли

Автор: Джонни Лю, генеральный директор компании Dowway Vehicle
Опубликовано: 16 марта 2026 г.
Последнее обновление: 16 марта 2026 г.
Примечание рецензента: Подготовлено на основе технического отчета, предоставленного для данной статьи.
Тип контента: Технический анализ отрасли
Примечание о юрисдикции: В данной статье рассматриваются рабочие процессы в автомобильной инженерии в глобальном контексте, с особым вниманием к локализации на китайском рынке и местной инженерной практике.
Предупреждение: Данная статья предназначена для обсуждения в сфере инженерного образования и промышленности. Она не является юридической консультацией, советом по сертификации или нормативно-правовым рекомендациям.

Прямой ответ

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

• В разработке транспортных средств произошел переход от работы над отдельными подсистемами к комплексному системному проектированию, охватывающему различные области.
• SSA помогает объединить требования, архитектуру, имитационные модели и валидацию в единый рабочий процесс.
• Его главные преимущества — гетерогенное совместное моделирование, полная прослеживаемость, модульная конструкция и интеграция с набором инструментов.
• Он хорошо подходит для работы с силовыми агрегатами электромобилей, системами терморегулирования, ADAS и проверки контроллеров домена.
• Китайская версия снижает барьер для обучения местных инженерных команд и поддерживает местные стандарты и сотрудничество.

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

Именно здесь на помощь приходит системная инженерия на основе моделей (MBSE). Она позволяет командам объединить требования, функции системы, физическое проектирование, моделирование и верификацию в единую цепочку. В предоставленном вами отчете Simcenter System Architect находится в центре этой цепочки. Он представлен как центральный элемент, связывающий концептуальное проектирование, детальное проектирование, моделирование и верификацию, а также итерации проектирования в рамках всей цепочки разработки автомобильных компонентов.

---

Почему автомобильным командам необходима платформа системного уровня

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

• механические системы, такие как шасси и кузов,
• электрические системы, такие как батареи и двигатели,
• электронные системы, такие как электронные блоки управления и датчики, и
• программные системы, такие как логика управления и встроенные функции.

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

В отчете выявлены три распространенные проблемы в устаревших рабочих процессах:

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

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

---

Чем занимается системный архитектор Simcenter в автомобильной инфраструктуре.

SSA является частью инструментария Siemens Simcenter, но его роль отличается от роли отдельного решателя или симулятора для одной предметной области. Он не фокусируется только на одной дисциплине. Его задача — объединить:

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

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

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

---

Основные преимущества Simcenter System Architect для автомобильной инженерии

1. Многодисциплинарное гетерогенное совместное моделирование

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

SSA поддерживает интеграцию разнородных моделей через стандартные интерфейсы, такие как FMI/FMU и рабочие процессы в стиле Modelica SSP. Это означает, что модели из таких инструментов, как:

• Simcenter Amesim,
• MATLAB/Simulink и
• Среды на основе Modelica

их можно объединить в единую архитектуру моделирования на системном уровне без существенной переработки исходных моделей.

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

Это упрощает выявление проблем на системном уровне до начала интеграции оборудования.

2. Полная отслеживаемость требований на основе MBSE.

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

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

В качестве хорошего примера из отчета можно привести задачу автоматического экстренного торможения, например:

Время реакции AEB ≤ 100 мс

Это требование может быть применено ко всем:

• восприятие,
• решение и
• Подсистемы привода.

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

3. Модульная архитектура и быстрая итерация.

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

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

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

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

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

4. Бесшовная интеграция с автомобильной инструментальной цепочкой.

Ещё одним сильным моментом в отчёте является место SSA в более широкой цепочке инструментов разработки автомобильной промышленности. Она предназначена для взаимодействия со следующими структурами:

• NX для CAD-данных,
• Simcenter 3D для работы в области CAE.
• Simcenter Testlab — тестовая и валидационная лаборатория для сбора данных.
• Teamcenter для управления жизненным циклом PLM и PLM, и
• Использование Git или файловых рабочих процессов для управления моделями.

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

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

---

Основные функциональные модули Simcenter System Architect

Модуль проектирования системной архитектуры

Это и есть суть SSA. Она предоставляет командам графическую и модульную среду для построения моделей системной архитектуры.

Функциональное архитектурное моделирование

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

Например, систему управления транспортным средством можно разделить на следующие компоненты:

• функции датчиков,
• функции принятия решений и
• функции выполнения.

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

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

Моделирование физической архитектуры

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

• камеры,
• радиолокационные установки,
• контроллеры домена,
• тормозные суппорты,
• моторы и
• компоненты батареи.

В отчете также отмечается, что моделирование физической архитектуры определяет интерфейсы компонентов, в том числе:

• электрические интерфейсы,
• механические интерфейсы и
• коммуникационные интерфейсы.

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

Иерархическое проектирование архитектуры

SSA поддерживает многоуровневое проектирование архитектуры. Команды могут работать из следующих мест:

• уровень транспортного средства,
• на уровне подсистемы,
• на уровне компонентов.

В отчете приводится наглядный пример этой логики:

Архитектура транспортного средства → архитектура силовой подсистемы → архитектура компонентов батареи

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

Библиотеки многоразовых автомобильных компонентов

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

• силовой агрегат,
• шасси,
• подвеска и
• блоки управления.

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

---

Модуль управления требованиями и отслеживания

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

Импорт требований

Согласно отчету, SSA может импортировать необходимые ресурсы из таких источников, как:

• Excel и
• Документы с требованиями в стиле DOORS.

Это упрощает интеграцию целевых объектов верхнего уровня программы в архитектуру и среду моделирования.

Разбивка требований

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

Дальность хода по циклу NEDC ≥ 600 км

можно разбить на требования к подсистемам и компонентам, такие как:

• Емкость аккумулятора ≥ 80 кВт·ч,
• максимальная мощность двигателя ≥ 150 кВт, и
• Плотность энергии отдельной ячейки ≥ 280 Вт·ч/кг.

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

Распределение требований

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

Прямая и обратная прослеживаемость

В докладе здесь четко изложен важный тезис. SSA поддерживает:

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

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

Это экономит время и помогает сосредоточиться на итерациях.

---

Многодисциплинарный модуль совместного моделирования

Этот модуль преобразует архитектуру в работающую системную модель.

Импорт и совместимость моделей

В отчете перечислены основные среды разработки инструментов, имеющие отношение к данному вопросу:

• Simcenter Amesim для механических и тепловых моделей.
• MATLAB/Simulink для моделей стратегий управления, и
• Modelica для мультифизических моделей.

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

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

Настройка сценария моделирования

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

• Цикл NEDC,
• Цикл WLTP,
• условия подъема в гору и
• условия торможения.

В параметры сценария могут входить:

• скорость транспортного средства,
• температура окружающей среды и
• условия нагрузки.

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

Анализ результатов

В отчете говорится, что SSA поддерживает визуализацию результатов посредством:

• кривые,
• диаграммы и
• анимация.

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

• напряжение батареи,
• скорость двигателя,
• смещение подвески и
• тепловые характеристики.

Это упрощает выявление узких мест и позволяет структурированно сравнивать варианты архитектуры.

---

Модуль оптимизации и анализа

Этот модуль посвящен улучшению дизайна и компромиссам в архитектуре.

Параметрическая оптимизация

В отчете говорится, что SSA может оптимизировать такие параметры, как:

• емкость батареи,
• мощность двигателя,
• жесткость подвески и
• значения стратегии управления.

Цели оптимизации могут включать в себя:

• максимальная дальность
• минимальное энергопотребление, или
• улучшенные показатели NVH (шум, вибрация, жесткость).

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

В исходном тексте упоминается один из результатов: компания Hyundai, используя искусственный интеллект в более широком процессе, сократила время оценки отдельных требований с 2 ​​минут до 0,1 секунды. Это демонстрирует, как автоматизация на системном уровне может сократить время итераций проектирования.

Многоцелевая оптимизация

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

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

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

Анализ чувствительности

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

• емкость батареи,
• эффективность двигателя и
• коэффициент сопротивления

в отношении дальности хода транспортного средства.

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

---

Модуль управления отчетностью и взаимодействием

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

Автоматизированное создание отчетов

В отчете говорится, что SSA может генерировать:

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

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

Сотрудничество и разрешения

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

• дизайнеры,
• рецензенты и
• администраторы.

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

Взаимосвязь PLM и жизненного цикла

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

• контроль версий,
• ведение учета и
• отслеживаемость в дальнейшем.

В исходном тексте упоминается, что компания AZL использует подобный взаимосвязанный рабочий процесс в работе с NVH (шум, вибрация и жесткость) электромобилей, чтобы объединить данные испытаний и данные моделирования в стандартный набор отчетов.

---

Пример практического применения в инженерии 1: Проектирование архитектуры силовой установки электромобиля и оптимизация характеристик.

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

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

В качестве основного инструмента системного уровня использовалась система SSA.

Шаг 1: Импорт и детализация целевых показателей на уровне транспортных средств.

В исходном отчете в качестве основных целей указаны следующие:

• Запас хода по циклу NEDC ≥ 650 км.
• Разгон от 0 до 100 км/ч ≤ 6,5 секунд, и
• Потребление энергии ≤ 12 кВт·ч на 100 км.

Эти целевые объекты верхнего уровня были импортированы в SSA и разбиты на подсистемы и компоненты, такие как:

• Емкость аккумулятора ≥ 85 кВт·ч,
• максимальная мощность двигателя ≥ 160 кВт, и
• Эффективность электрического управления ≥ 95%.

Это позволило установить связь между целями создания транспортного средства и архитектурой конструкции.

Шаг 2: Создание функциональной и физической архитектуры

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

• аккумуляторный блок,
• мотор,
• электрическая система управления и
• редуктор.

Были сопоставлены три варианта архитектуры:

• одномоторный задний привод,
• двухмоторный полный привод и
• Передний привод с одним двигателем и расширителем запаса хода.

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

Шаг 3: Запуск междисциплинарного совместного моделирования.

В отчете говорится, что команда импортировала:

• модель управления температурным режимом батареи, созданная в Simcenter Amesim, и
• Модель стратегии управления двигателем, созданная в MATLAB/Simulink.

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

• тренировочное поле для гольфа,
• ускорение,
• потребление энергии и
• температура батареи.

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

Шаг 4: Оптимизация и выбор оптимальной архитектуры

В отчете говорится, что команда использовала многоцелевую оптимизацию с такими целями, как:

• максимальная дальность
• минимальное энергопотребление и
• наилучшие показатели разгона.

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

• Дальность хода 680 км.
• Разгон от 0 до 100 км/ч за 5,8 секунды, и
• 11,2 кВт·ч на 100 км.

Эти результаты соответствуют целевым показателям для данного транспортного средства.

Шаг 5: Отслеживание требований и создание отчетов.

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

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

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

В отчете говорится, что это помогло сократить цикл разработки архитектуры силового агрегата на 30% и повысить эффективность проверки моделирования на 40%.

---

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

Второй случай в отчете посвящен контроллеру домена автоматизированного вождения уровня L2+. Основные проблемы заключались в следующем:

• сложная функциональная логика,
• сложная многомодульная координация, и
• Проверка функциональной безопасности в соответствии с требованиями стандарта ISO 26262 ASIL-B.

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

Шаг 1: Определение и распределение функциональных требований

В отчете перечислены такие особенности, как:

• АЭБ,
• АКК и
• Удержание полосы движения.

Они были разбиты на требования:

• восприятие,
• решение,
• исполнение и
• коммуникационные модули.

Одновременно с этим команда определила цели в области безопасности и уровни риска в соответствии с принципами, изложенными в стандарте ISO 26262.

Шаг 2: Создание архитектуры контроллера и определение интерфейсов.

Архитектура объединила в себе:

• Интерфейсы камеры и радара на уровне датчиков,
• Распределение ресурсов ЦП/ГП на уровне принятия решений,
• интерфейсы тормозной системы и рулевого управления на уровне исполнения, и
• Интерфейсы CAN, LIN и Ethernet на уровне связи.

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

Шаг 3: Моделирование сценариев отказов для проверки функциональной безопасности.

В отчете говорится, что SSA использовалась совместно со следующими компонентами:

• Модели стратегий управления MATLAB/Simulink и
• Тестовые данные Simcenter Testlab.

Команда разработала сценарии возникновения ошибок, такие как:

• неисправность камеры,
• прерывание связи и
• Отказ исполнительного механизма.

Эти симуляции использовались для проверки диагностических функций и отказоустойчивости.

Шаг 4: Оптимизация архитектуры

На основе результатов моделирования команда выявила следующие проблемы безопасности:

• высокая задержка связи и
• медленное время отклика при диагностике неисправностей.

Затем они использовали оптимизацию параметров SSA для внесения корректировок:

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

Это помогло повысить безопасность и надежность на более поздних этапах интеграции.

Шаг 5: Создание результатов, ориентированных на соблюдение нормативных требований.

В итоговые результаты вошли:

• Отчеты о проектировании архитектуры контроллера,
• отчеты о проверке функциональной безопасности и
• записи об отслеживаемости.

Это послужило поддержкой для последующей сертификации и подготовки к производству.

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

---

Адаптация китайской версии и ценность локальных инженерных решений.

В отчете есть отдельный раздел, посвященный китайской версии Simcenter System Architect, и эту часть следует оставить в статье, поскольку она действительно полезна для целевой аудитории.

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

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

В докладе также отмечается поддержка местных стандартов и норм, включая такие ссылки, как: GB/T 28950-2012 Требования безопасности электромобилей.

Это полезно по нескольким причинам.

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

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

---

Технические заметки для практического применения

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

Стандартизация моделей

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

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

Требования к качеству

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

• измеримый,
• проверяемый и
• привязано к методу проверки.

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

Разумные сценарии моделирования

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

• температура окружающей среды,
• состояние дорог и
• нагрузка

должно отражать реальные сценарии использования транспортного средства.

В качестве конкретного примера в отчете приводится программа развития электромобилей в Северном Китае, которая должна включать в себя следующее: условия низкой температуры при -20°C для проверки надежности батареи и системы терморегулирования.

Управление командным взаимодействием

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

• проектные группы в области архитектуры,
• группы моделирования и
• команды по управлению требованиями.

Без этого, даже если сам инструмент достаточно мощный, могут возникнуть конфликты версий и дублирование работы.

Глубокая интеграция инструментария

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

---

Почему системный архитектор Simcenter важен в будущем

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

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

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

В докладе также указывается на возможное объединение стран Африки к югу от Сахары с:

• ИИ и
• методы цифрового двойника.

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

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

---

Часто задаваемые вопросы

Что такое Simcenter System Architect и как он вписывается в цепочку инструментов MBSE для автомобильной промышленности?

Краткий ответ:
В рамках подхода MBSE (Model-Based System Architecture) к проектированию автомобильной системы это слой системной архитектуры, который связывает требования, проектирование системы, средства моделирования и валидацию.

Simcenter System Architect — это платформа для моделирования и совместного моделирования архитектуры на системном уровне, входящая в портфолио Siemens Simcenter. В автомобильной разработке она обычно находится между определением требований и детальным инженерным моделированием. Она связывает требования, функциональную архитектуру, физическую архитектуру, многодоменные модели и проверку системы, позволяя командам изучать варианты архитектуры до появления аппаратных прототипов.

Как Simcenter System Architect поддерживает междисциплинарное совместное моделирование?

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

SSA поддерживает интеграцию разнородных моделей из разных областей и с использованием различных инструментов. В отчете это включает модели на основе Simcenter Amesim, MATLAB/Simulink и Modelica, с возможностью взаимодействия через такие интерфейсы, как FMI/FMU. Это позволяет автомобильным командам моделировать взаимодействие между механикой, электроникой, системами управления, тепловым поведением и другими областями в одной среде, вместо того чтобы проверять их по отдельности.

Почему MBSE важен для современной разработки автомобильных систем?

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

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

Как Simcenter System Architect интегрируется с другими инженерными инструментами?

Краткий ответ:
Она связывает работу над системной архитектурой с инструментами проектирования, моделирования, тестирования и управления жизненным циклом системы.

В отчете указана интеграция с Simcenter Amesim, NX, Simcenter 3D, Simcenter Testlab, Teamcenter, а также с системами управления моделями на основе Git или файлов. Это помогает поддерживать связь между требованиями, моделями, отчетами и данными валидации на протяжении всего жизненного цикла разработки. Вместо хранения записей об архитектуре, моделировании и жизненном цикле в отдельных системах, команды могут поддерживать более согласованный процесс разработки.

Каковы основные сценарии использования Simcenter System Architect в автомобильной отрасли?

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

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

---

Итоговый вывод

Simcenter System Architect полезен в автомобильной инженерии, поскольку предоставляет командам единое место для объединения требований, архитектуры, моделирования, оптимизации и верификации.

Из исходного отчета становится ясно, что его ценность проявляется в четырех областях:

• гетерогенное совместное моделирование,
• полная прослеживаемость,
• итерация модульной архитектуры и
• Интеграция инструментария.

Его пять основных функциональных групп также очевидны:

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

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

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

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

---

Биография автора

Джонни Лю является ли Генеральный директор компании Dowway Vehicle. Он занимается разработкой стратегии автомобильной инженерии, планированием системной архитектуры и методами цифровой разработки для электромобилей, интеллектуальных транспортных средств и междисциплинарных инженерных программ.

---