Современный автомобиль — это распределенная вычислительная система на колесах. И если раньше основное внимание уделялось механике, то сегодня значительная часть функциональности автомобиля определяется электроникой и ПО.
Для электромобиля эта зависимость еще сильнее: десятки электронных блоков должны непрерывно обмениваться данными, координировать свою работу и при этом оставаться энергоэффективными.
Разберемся, как наладить между ними коннект и заставить работать в унисон.
Итак, начнем
Меня зовут Николай, в Атоме я занимаюсь валидацией электрики и электроники и вместе со своим коллегой Александром, отвечающим за разработку электронной архитектуры, хочу рассказать, как она создавалась для нашего электромобиля.
От пользовательских сценариев к системным требованиям
Разработка низковольтной архитектуры начинается задолго до появления первых электронных блоков или схем подключения.
На первом этапе продуктовые команды проводят исследования пользовательских потребностей, анализируют рыночные решения и формируют требования к будущему продукту, чтобы определить набор функций, которые должны будут реализованы в автомобиле.
В результате появляется операционная концепция: набор сценариев взаимодействия пользователя с автомобилем.
Например:
· дистанционное управление функциями через мобильное приложение;
· бесключевой доступ;
· зарядка электромобиля;
· работа систем помощи водителю;
· мультимедийные сервисы.
Каждый такой сценарий нужно преобразовать в конкретные техтребования к аппаратному и программному обеспечению.
Задача инженеров: обеспечить надежное взаимодействие всех компонентов электромобиля независимо от сложности реализуемых функций.
Почему мы выбрали децентрализованный подход
Стратегический выбор архитектуры – важнейший этап в разработке автомобиля, потому что на этом этапе она определяется экономически и функционально. В частности, формируется топология верхнего уровня и создается список необходимых ECU — электронных блоков управления.
Топология определяет:
· какие электронные блоки присутствуют в системе;
· как они связаны между собой;
· по каким протоколам осуществляется обмен данными: CAN, CAN-FD, LIN, Ethernet;
· какие функции выполняет каждый узел сети.
В Атоме мы решили делать децентрализованную низковольтную архитектуру.
В отличие от архитектур, построенных вокруг одного центрального контроллера, в ней каждый домен способен выполнять свои задачи независимо от остальных. Такой подход обеспечивает несколько важных преимуществ.
А именно:
Повышение надежности
Отказ одного электронного блока не приводит к полной потере функциональности электромобиля. Остальные подсистемы продолжают работать независимо, что повышает общую отказоустойчивость системы.
Масштабируемость
Архитектура изначально проектировалась с учетом будущего развития платформы. Добавление новых функций или модернизация существующих систем требует минимального влияния на уже работающие компоненты.
Энергоэффективность
Одно из преимуществ децентрализованного подхода — возможность выборочного пробуждения отдельных электронных блоков.
Например, для выполнения удаленной команды пользователя нет необходимости активировать всю низковольтную систему электромобиля. Достаточно вывести из спящего режима только необходимые модули.
Это позволяет снизить паразитное энергопотребление и увеличить запас энергии при длительной стоянке.
Три этапа разработки низковольтной системы
Если упростить процесс создания низковольтной архитектуры, его можно разделить на три этапа:
1. Формирование требований.
2. Разработка аппаратной и программной части.
3. Верификация и подтверждение соответствия требованиям.
На практике каждый из них включает множество итераций, поскольку требования, архитектурные решения и результаты испытаний постоянно влияют друг на друга.
Формирование требований и системная архитектура
Когда пользовательские сценарии сформированы, они разбиваются на уровень атомарных функций без привязки к железу и создают функциональные домены:
· домен кузовной электроники;
· домен шасси;
· домен силовой установки;
· домен системы помощи водителю;
· домен информационно-развлекательных систем и мультимедиа;
· домен сервисных функций и других подсистем.
Потом все системы связываются между собой функциональными диаграммами и интерфейсами и исходя из этого рождается фактическая топология сети, где определяются требования к обмену данными между системами и требования к безопасности и надежности, такие как ISO-26262 и ISO21434. Так же создаются сигнальные матрицы для этих систем.
Фактически на этом этапе формируется цифровой «скелет» автомобиля.
Разработка аппаратной и программной части
На основе выбранной топологии идет распределение функций на уровень отдельных электронных блоков управления (ECU). Здесь предъявляются требования к конкретным устройствам:
· требования к контроллеру
· требования по питанию
· требования по коммуникации
· распиновка и тд.
По результатам этой работы формируются требования к аппаратному обеспечению и к ПО.
Часть компонентов закупается у поставщиков, а для некоторых устройств формируются индивидуальные ТЗ на разработку специально под проект.
При выборе поставщиков важны зрелость производственных процессов, качество продукции и способность обеспечивать долгосрочную поддержку компонентов на протяжении жизненного цикла автомобиля.
Верификация: от цифровых моделей до реального электромобиля
После разработки архитектуры начинается самый продолжительный этап — валидация.
Для оценки готовности низковольтной системы необходимо подтвердить корректную работу всех функций, электронных блоков и коммуникационных сценариев.
Такая проверка идет на нескольких уровнях.
Виртуальное моделирование
На ранних стадиях используются цифровые модели, позволяющие анализировать взаимодействие систем еще до появления физических прототипов.
Это помогает выявлять архитектурные ошибки и снижать стоимость последующих доработок.
Лабораторные испытания
У нас одним из ключевых инструментов тестирования стал стенд Лабкар.
Это аппаратно-программный комплекс, который полностью имитирует низковольтную систему электромобиля.
На стенде установлены реальные электронные блоки, которые используются в предсерийных образцах и будут применяться в серийном производстве.
Лабкар позволяет:
· тестировать отдельные функции;
· проверять взаимодействие между блоками;
· воспроизводить редкие или аварийные сценарии;
· проводить автоматизированные регрессионные испытания;
· выявлять ошибки до выхода электромобиля на дороги общего пользования.
Испытания на прототипах
Финальный этап: проверка архитектурных решений на реальных электромобилях.
На этом уровне оценивается работа системы в условиях, максимально приближенных к эксплуатации, включая различные климатические режимы, дорожные условия и пользовательские сценарии.
Архитектура с перспективой
При разработке низковольтной системы Атома важно было не только обеспечить работу текущих функций, но и заложить возможности для дальнейшего развития платформы.
Современный электромобиль продолжает эволюционировать даже после выхода в серию: появляются новые программные функции, обновляются алгоритмы управления и расширяется набор цифровых сервисов.
Поэтому архитектура проектировалась с учетом:
· дальнейшего масштабирования;
· интеграции новых электронных компонентов;
· развития программной функциональности;
· модернизации отдельных подсистем без необходимости полной переработки платформы.
Такой подход позволяет создать основу для длительного жизненного цикла продукта и обеспечивает гибкость развития электромобиля в будущем.
ссылка на оригинал статьи https://habr.com/ru/articles/1055304/