Автор: Джонни Лю, генеральный директор компании Dowway Vehicle.
Опубликовано: 9 июля 2026 г.
Время чтения: 15 мин.
Категория: Электромобили, инженерия на основе искусственного интеллекта, проектирование на основе моделей (MBD)
Table of Contents
За кулисами ажиотажа вокруг чат-ботов
Если ваша команда разработчиков автомобильного программного обеспечения рассматривает такие фреймворки, как… Агент Гермеса или OpenClaw И если они видят просто «более умного чат-бота», то используют их неправильно. В высоконадежных автомобильных НИОКР, особенно в рамках «трехэлектрических» систем (системы управления батареей),[BMS]Блок управления транспортным средством[VCU]и блок управления двигателем.[MCU]Реальная ценность ИИ заключается не в принятии окончательных решений за инженеров.
Вместо этого его ценность заключается в способности организовывать доступ к файлам, вызов инструментов, выполнение команд командной строки, изоляцию браузера и поиск корпоративных знаний в единое целое. проверяемый, детерминированный инженерный конвейер.
В этой статье объясняется, как агенты искусственного интеллекта могут объединить разрозненные инструменты проектирования на основе моделей (MBD) без ущерба для безопасности, прокладывая четкий путь от простого вызова инструментов к полному замкнутому циклу проектирования.
1. Основная проблема в разработке программного обеспечения: фрагментированные файлы, разрозненные инструменты и нарушенные цепочки доказательств.
Любой опытный инженер-программист, специализирующийся на разработке программного обеспечения для силовых агрегатов, знает, что типичная неисправность системы управления редко возникает в одном-единственном, изолированном файле. Рассмотрим стандартный сценарий поиска и устранения неисправностей:
- Симптом: В условиях низких температур предел мощности зарядки аккумулятора неожиданно снижается. Это происходит наряду с периодическими ограничениями крутящего момента и несоответствием диагностического кода неисправности (DTC) между фактическим выходным сигналом контроллера и техническими характеристиками системы.
Для диагностики этой проблемы инженеру необходимо одновременно открыть, проанализировать и сопоставить огромный, фрагментированный набор данных:
[System Requirements] ── (DOORS / Word)
│
[Software Model] ── (MATLAB Simulink / Stateflow)
│
[Network Interfaces] ── (DBC / ARXML)
│
[Memory Mapping] ── (ASAP2 / A2L / Calibration Parameters)
│
[Real-world Behavior] ── (Vector CANoe Trace / CANape Logs / MDF4)
Четыре уровня фрагментации
Данный алгоритм выявляет сильную фрагментацию по четырем различным направлениям:
- Фрагментация на уровне файлов: Требования хранятся в Word или IBM Doors; управляющая логика — в моделях MATLAB Simulink.
.slx) и диаграммы Stateflow; интерфейсы шины определены в.dbcили.arxmlАдреса памяти определены в.a2lТестовые скрипты написаны на CAPL или Python; журналы тестирования находятся в.mdf,.dat, или.csvфайлы. - Изоляция цепочки инструментов: Инженерам приходится постоянно переключаться между задачами. Они переходят от MATLAB/Simulink (проектирование моделей) к Vector CANoe (моделирование автобусов), Vector CANape или TsMaster (калибровка/измерение), Excel (сопоставление данных) и внутренним веб-системам отслеживания проблем (Jira).
- Семантическая несогласованность: Точно такая же физическая переменная (например, ток зарядки целевой батареи) может быть названа.
Target_Chg_Currв спецификации функциональных требований,bms_I_targetв рабочей области модели Simulink,BMS_TargetCurrentв базе данных сигналов CAN DBC, иP_BMS_Chg_Curr_Limitв калибровочном файле A2L. Они часто имеют разные частоты дискретизации, коэффициенты масштабирования, единицы измерения и допустимые диапазоны значений. - Цепочки отсутствующих доказательств: Генеративный ИИ может легко предложить гипотетическую первопричину. Однако, если это предположение не может указать на конкретную миллисекунду в логе, конкретный переход сигнала в трассировке, конкретный путь в модели Simulink или конкретный идентификатор тестового случая, он не может быть воспринято как инженерное заключение.
Вопрос не в том, насколько умён магистр права. Вопрос в другом: Какое место занимает ИИ-агент в цепочке инструментов MBD, как он получает доступ к файлам, когда ему разрешено вызывать скрипты и когда он должен остановиться, чтобы передать управление обратно инженеру-человеку?
2. Ограничения традиционной автоматизации по сравнению с агентным подходом.
В автомобильных отделах разработки программного обеспечения автоматизированные скрипты используются уже несколько десятилетий (API MATLAB, парсеры DBC на Python, наборы тестов CAPL, конвейеры CI/CD Jenkins и макросы Excel). Эти инструменты отличаются высокой степенью детерминированности, воспроизводимостью и полной возможностью аудита.
Однако они страдают от высоких затрат на переключение контекста. Скрипт на Python может анализировать DBC, а скрипт на MATLAB может выполнять проверку модели, но они не используют общий семантический контекст.
Следующая матрица определяет, где традиционные скрипты автоматизации сталкиваются с трудностями и где следует вмешаться агентам искусственного интеллекта:
| Инженерный артефакт | Традиционные ограничения автоматизации | Границы возможностей ИИ-агента |
|---|---|---|
| Simulink / Stateflow | Скрипты выполняют проверку статических правил проектирования (подобно Model Advisor) и генерируют XML-отчеты. Однако интерпретация этих отчетов и установление связи между ошибками и системными требованиями по-прежнему требуют ручной работы. | Агент анализирует отчет Model Advisor и исходную спецификацию, выявляет неисправности и формирует список приоритетных технических проблем. никогда напрямую редактирует файлы модели. |
| DBC / A2L / МДФ | Скрипты на Python или CANape могут извлекать списки сигналов, но сопоставление переменных между DBC и A2L требует от инженеров ручного ведения ненадежных таблиц преобразования в Excel. | Агент динамически устраняет несоответствия в семантическом сопоставлении, анализируя коэффициенты масштабирования, типы данных, физические единицы измерения и версии параметров калибровки в рамках DBC, A2L и моделей. |
| CANoe / CAPL | Автоматизированные тестовые стенды выполняют тестовые сценарии и экспортируют отчеты о тестировании в формате HTML. Однако для выявления первопричины ошибки требуется ручное отслеживание журналов. | Агент сканирует файлы трассировки теста CANoe и журналы CAPL, определяет точное время сбоя, сопоставляет его с диагностическими кодами и составляет исправления для скриптов CAPL. |
| Технические требования | Стандартные скрипты могут проверить наличие поля ID в документе с требованиями, но они не могут оценить ясность текста или сопоставить покрытие тестами. | Агент извлекает функциональные критерии приемки, сопоставляет их с фактическими точками тестирования и генерирует черновик матрицы сквозной прослеживаемости. |
| Внутренние веб-инструменты | Инженерам приходится вручную копировать и вставлять журналы трассировки или коды диагностических ошибок в Jira, Confluence или внутренние базы знаний. | Агент использует инструменты поиска и извлечения информации для сканирования внутренних баз данных, сопоставляет исторические журналы проблем и записывает ссылки вместе с URL-адресами источников. |
3. Эталонная архитектура: LLM на уровне оркестровки
Для безопасного развертывания агентов ИИ в разработке критически важных систем (таких как программные конвейеры ISO 26262 ASIL-D) LLM должен строго соответствовать определенным требованиям. Уровень оркестровкиполностью изолирован от Цикл безопасного выполнения.
┌────────────────────────────────────────────────────────┐
│ HUMAN ENGINEER (Review) │
└───────────────────────────▲────────────────────────────┘
│
[State / Logs] │ [Approve / Correct]
│
┌───────────────────────────▼────────────────────────────┐
│ LLM ORCHESTRATION LAYER (Agent) │
│ - Plan Formulation - Context Assembly │
│ - Semantic Mapping - Reasoning & Tool-calling │
└───────────────────────────┬────────────────────────────┘
│
[Authorized Tool Calls] / [Structured Outputs]
│
┌───────────────────────────▼────────────────────────────┐
│ AUDITABLE EXECUTION LAYER │
│ ┌───────────────────────┐ ┌───────────────────────┐ │
│ │ Sandboxed Environment│ │ Whitelisted Tools │ │
│ │ - Read-Only Snapshots│ │ - MATLAB / CANoe APIs│ │
│ │ - Isolated Browsers │ │ - Python/CAPL Parsers│ │
│ └───────────────────────┘ └───────────────────────┘ │
└────────────────────────────────────────────────────────┘
Фреймворки, такие как OpenClaw Инструменты определяются как структурированные функции, которые может вызывать Агент (выполнение, поиск в интернете, локальный поиск, обмен сообщениями). Аналогично, Агент Гермеса Использует локальную песочницу для безопасного запуска системных утилит.
Для автомобильного программного обеспечения необходимо установить пять абсолютных мер безопасности:
- Изолирование хранилища только для чтения: Агент должен работать с моментальным снимком, доступным только для чтения, или с выделенной веткой Git в рабочей области.
./project_snapshot). Оно ни в коем случае не должно иметь доступа на запись к производственным веткам, криптографическим ключам или проприетарным базовым репозиториям. - Вызов инструментов, внесенных в белый список: Агент не может выполнять прямые команды оболочки. Вместо этого он должен взаимодействовать с инженерной экосистемой, вызывая список предварительно написанных, детерминированных скриптов запуска на Python или MATLAB.
- Ведение журнала ограничений выполнения: Каждый скрипт должен выполняться в строго определенной директории, соблюдаться ограничения по времени выполнения и автоматически фиксироваться.
стандартный вывод,stderrкоды завершения и хеши входных файлов. Эти записи сохраняются в неизменяемом журнале аудита. - Изолированные профили браузера: Для получения информации из веб-интерфейса (например, для поиска определений стандарта ASAM или проверки внутренних досок Jira) агент должен использовать выделенный профиль браузера, полностью изолированный от личных или корпоративных учетных данных SSO.
- Сегрегация арендаторов в базе знаний: При подключении к базам данных с расширенным поиском (RAG), содержащим конфиденциальные руководства по калибровке или данные отладки предыдущих проектов, система должна обеспечивать строгий контроль доступа на основе ролей (RBAC) для предотвращения утечек IP-адресов между клиентами.
4. Пошаговая интеграция: сопоставление агента с цепочкой инструментов MBD.
Давайте рассмотрим, как агент искусственного интеллекта выполняет полный четырехэтапный рабочий процесс MBD.
Step 1: Parse Specs ──► Step 2: Scan Model ──► Step 3: Align Signals ──► Step 4: Parse Logs
(Requirements to (MATLAB Report (DBC to A2L (CANoe Trace
Test Matrix) Analyzer) Mapping) to Evidence)
Шаг 4.1: Составление матрицы требований к тестированию
Агент обрабатывает документы с требованиями (например, файлы Markdown или JSON, экспортированные из DOORS). Он анализирует каждое функциональное условие для извлечения следующих данных:
- Предварительные условия (например,
Температура батареи < -10°C) - Активные входные данные (например,
Charge_Plug_Detected == TRUE) - Ожидаемые выходные данные системы (например,
Max_Chg_Current_Limit == 15A) - Сопутствующие диагностические состояния.
Вместо того чтобы пытаться написать окончательный код, агент выводит структурированный результат. Проект тестовой матрицы в формате JSON, определяющем явные точки проверки для последующего тестирования по стандартам MIL/SIL/HIL.
Шаг 4.2: Проверка модели для выпуска контрольных списков
Агенту запрещено изменять модели Simulink..slx) или напрямую диаграммы Stateflow. Вместо этого он запускает локальный скрипт MATLAB через интерфейс командной строки. Этот скрипт запуска:
- Открывает MATLAB в безмониторном режиме.
- Запускает пользовательские статические средства проверки правил проектирования (например, проверку соглашений об именовании или поиск несвязанных сигнальных портов).
- Экспортирует структурированный диагностический отчет.
Агент читает этот отчет, сопоставляет его с рекомендациями по проектированию программного обеспечения и генерирует структурированный контрольный список, выделяющий ошибки (например, “диаграмма потока состояний”). Charge_Manager отсутствует путь перехода по умолчанию).
Шаг 4.3: Семантическое сопоставление полей DBC, A2L и калибровки.
На этом этапе происходит сопоставление физических сигналов связи с внутренней памятью контроллера. Агент вызывает специальный парсер на языке Python для чтения файла CAN DBC и файла A2L контроллера.
Затем создается единая таблица сопоставления переменных и проверяется наличие критических несоответствий:
[Signal: BMS_Target_I] ── (DBC Unit: Ampere | Scale: 0.1 | Offset: 0)
VS
[Parameter: Target_I_Cal] ── (A2L Unit: Ampere | Scale: 0.01 | Offset: -40)
▲
[Agent Flags Mismatch]