Зачем нужны стандарты при создании логики автомобиля. Краткое введение в Autosar
Меня зовут Денис Кондратенко, я Team Lead в GlobalLogic. В этой статье я расскажу о том, что представляет собой стандарт AUTOSAR Classic и почему стандарты важны при создании логики автомобиля. Статья будет полезна как опытным инженерам, так и новичкам, которые смогут познакомиться с процессом создания AUTOSAR-проектов и разобраться в технологии их разработки.
Автомобили становятся сложнее и «умнее». При этом все системы должны работать как слаженный механизм и быстро реагировать на сигналы. Производители автомобилей нашли способ контролировать работу каждого электронного юнита и автоматизировать сложные связи в архитектуре управления. Так, в 2003 году появился стандарт AUTOSAR (AUTomotive Open System ARchitecture) и используется в автомотив проектах до сих пор.
Предыстория
Первый автомобиль с двигателем внутреннего сгорания был сконструирован в 1886 году немецким инженером Карлом Бенцем. А спустя несколько месяцев Готтлиб Даймлер, тоже немец, презентовал свою версию автомобиля. Какой из автомобилей был действительно первым «автомобилем» — споры идут до сих пор.
С момента изобретения автомобиль постоянно эволюционирует. Автопроизводители (OEM) стремятся улучшить характеристики, добавить новые функции, уменьшить себестоимость (не путать с уменьшением цены для покупателя!) с целью увеличить продажи и прибыль компании. Для реализации поставленных задач OEM изменяет аппаратную и программную составляющие автомобиля.
Современный транспорт нафарширован рядом электронных модулей управления — ECU (Electronic Control Unit). Все они соединены в единую систему (хотя и связываются друг с другом по разным аппаратным шинам). Каждый ECU отвечает за определенный функционал. Также в системе присутствует отдельный модуль, отвечающий за взаимодействие с пользователем (так называемый Head Unit).
Число ECU в автомобиле с каждым годом увеличивается. Выходят новые версии аппаратного обеспечения (c новыми микроконтроллерами), функциональность переносится с одной ECU на другую. Всё это приводит к тому, что каждый раз ту же систему приходится программировать заново. Добавляется множество новых ECU «электронных помощников» — от элементарных как электронный ручной тормоз до сложнейших систем автономного вождения с камерами, лидарами, разнообразными датчиками, возможностью машин общаться друг с другом и дорожной инфраструктурой (в ближайшей перспективе). Все системы должны работать в комплексе, т.е. добавляя новую ECU придётся обновить еще и ряд смежных.
ECU представляет собой электронную плату с микроконтроллером, который работает под управлением простой операционной системы (ОС) или банального переключателя задач. Объем постоянной памяти —
Если, вдруг, вам кажется, что от проекта к проекту
- разрабатывается один и тот же функционал продукт за продуктом;
- проекты очень похожи друг на друга;
- большинство компонентов проекта — это набор «велосипедов», которые написаны с нуля или перекочевали из предыдущих проектов с определенными модификациями
То могу Вас поздравить — Вам таки не кажется! 😊 В древних
Как совладать с этой растущей сложностью, как облегчить себе жизнь и, попутно, ускорить выход нового продукта на рынок и уменьшить его стоимость?
Решение проблем — AUTOSAR
В 2006 году автопроизводители пришли к решению данной задачи — был презентован стандарт AUTOSAR (AUTomotive Open System ARchitecture). Этим стандартом был внедрен новый подход в разработке ПО для автомобилей.
В чем идея? Заменить «обычный подход» (аппаратное обеспечение и код были заточены друг под друга и представляли собой монолитную структуру) на «AUTOSAR-подход».
Что было предложено взамен? Вся бизнес-логика сконцентрирована в слое Application Software. Все стандартные библиотеки, ОС и прочие системные аппаратно-независимые модули размещены в слое AUTOSAR. Микроконтроллер (Hardware) абстрагируется от слоя AUTOSAR при помощи HAL слоя (называется MCAL — MC Abstraction Layer). Все интерфейсы в верхних двух слоях стандартизированы.
Таким образом, мы можем легко переносить бизнес логику с одной ECU на другую. Или взять AUTOSAR слой у другого поставщика (можем даже написать его сами — стандарты-то открытые!). Или сменить один микроконтроллер на другой. Все это можно сделать относительно просто и безболезненно для проекта.
Звучит заманчиво, не правда ли?
Разработка по методологии AUTOSAR
Проектирование функциональности автомобиля начинается с высокоуровневой диаграммы, которая описывает функции (компоненты) и их взаимосвязи (Abstract System Design phase).
На данном этапе совершенно не важно по каким физическим интерфейсам будут связаны компоненты системы, на каких устройствах они будут расположены и прочие детали реализации. Для абстрагирования был введен специальный термин — виртуальная системная шина (VFB).
Каждый компонент SWC (Software Component) можно представить как приложение, которое отвечает за определенный функционал.
Уже на данном этапе архитектурного проектирования с помощью соответствующего ПО можно проводить программное моделирование работы всей системы.
Описание системы хранится в «AbstractSystemDescription.arxml» файле.
Далее происходит детальная разработка системы.
Компоненты распределяются по реальным физическим сущностям (ECU). Часть компонентов располагается на одной ECU. Их взаимодействие будет сравнительно простой задачей. А часть будет располагаться на других ECU и взаимодействовать они будут при помощи коммуникационных интерфейсов, таких как CAN, LIN, Ethernet и прочие.
Детальный дизайн (System Design phase) системы будет храниться в «SystemDescription.arxml» файле. Он станет базовым и из него будут сгенерированы так называемые файлы выжимки — EcuExtract.arxml. Данные файлы передаются субподрядчикам для разработки подсистем. Так, общую картину субподрядчики не видят, но получают четкий API для разработки своих частей.
Два предыдущих этапа выполняет OEM при участии субконтракторов.
Отдельные ECU разрабатываются подрядчиками на заказ и под руководством OEM. А часть ECU OEM может разрабатывать самостоятельно.
Архитектура AUTOSAR
Что происходит далее? По согласованию с OEM выбирается поставщик МК и поставщик AUTOSAR. Tier1-компания, имея на руках EcuExtract.arxml, приступает к разработке ECU.
ECU (Electronic Control Unit) — устройство на базе микроконтроллера выполняющее ряд задач. Кроме самого МК на плате присутствуют датчики, драйверы (микросхемы), энергонезависимая память, разъемы и прочая необходимая периферия.
Говорят, что все это работает под управлением AUTOSAR. А что же такое AUTOSAR в данном случае?
AUTOSAR состоит из трех основных частей:
- Application Layer (SWC)
- Run-Time Environment (RTE)
- Basic Software (BSW)
Давайте это рассмотрим...
Application Layer
Application Layer — тут сконцентрирована вся бизнес-логика.
Слой состоит из набора SWC (Software Components). Компоненты связываются между собой при помощи портов. Каждый SWC включает в себя ряд исполняемых функций (Runnable) — это и есть, тот небольшой участок кода, который вы должны написать руками. Всё остальное вам придется «накликать». Функции будут вызываться по определенным событиям — при старте, периодически, по прерыванию и прочее.
.
Разработка Application Layer производится при помощи Vector DaVinci Developer (или аналогов от другого производителя программ разработки).
Run-Time Environment
RTE — Run-Time Environment. Данный слой является связным (абстрагирующим) между Application Layer и Basic Software Layer. Особенность данного слоя — он полностью автогенерируемый. Каждый раз при генерации проекта он будет создан с нуля.
Basic Software
Ну и наиболее интересный из слоев, BSW — Basic Software. Он, по сути, и является тем, что называют AUTOSAR.
Данный слой включает в себя 4 слоя.
Service Layer — операционная система и все что связано с системными сервисами (режимы работы, диагностика, память, коммуникации, шифрование и прочее).
ECU Abstraction Layer — слой абстракции железа ECU от бизнес-логики.
Рассмотрим, например, энергонезависимую память. У нас есть эта память на борту нашего МК, а также чип памяти на плате самого ECU. Чип подключен к МК по шине I2C. Для Application Layer обе памяти будут иметь тот же интерфейс для доступа. Разницу спрячет в себе ECU Abstraction Layer.
Microcontroller Abstraction Layer (MCAL) — набор драйверов, заточенных под данный конкретный МК. Мы этот слой хорошо знаем под аббревиатурой HAL (Hardware Abstraction Layer). Он защищает все вышестоящие слои от разновидности МК, который используется в данном случае и позволяет произвести смену МК относительно легко и безболезненно (ведь все API стандартизированы!).
Многие производители МК имеют в своем арсенале линейки продуктов с приставкой «Automotive/AUTOSAR compliant». Это значит, что данные МК заточены под архитектуру AUTOSAR. И кроме самих МК производитель может поставить MCAL драйвера для данного МК, а также — средства для их конфигурирования.
Complex Device Drivers (CDD) — драйвер для устройств, которые не подпадают под стандарты AUTOSAR.
Стандарт не идеален. Часть устройств и их функций им не покрыты. Иногда к ряду устройств можно обратиться существенно проще и быстрее, чем с помощью стека AUTOSAR. Для этих целей очень часто используются такие драйверы. Они позволяют приложению (SWC) обращаться напрямую к микроконтроллеру минуя стандартный стек слоев Autosar.
BSW слой конфигурируется. Если вы используете ПО от Vector — то это будет DaVinci Configurator.
Данное ПО настраивает весь BSW слой (исключая MCAL), а также подвязывает SWC компоненты к системным событиям и потокам.
Все настройки по всем слоям хранятся в наборе ARXML файлов. Сам набор представляет собой древовидную структуру.
Каждый компонент системы состоит из двух частей:
- файл с конфигурацией для данного компонента (*.arxml);
- исходный код компонента (*.c; *.h файлы).
В процессе генерации кода, на базе arxml-файлов создаются *.c и *.h файлы, содержащие в себе конфигурацию компонента. После этапа генерации, код компонента может быть собран компилятором.
Генерация и сборка исходного кода
Когда проект настроен, можно попробовать его собрать.
Первым этапом нужно сгенерировать конфигурацию MCAL-уровня. Мы получим набор с-шных файлов, содержащих настройки для HAL.
Второй этап — генерация кода для BSW слоя. Будут созданы с-шные файлы с конфигурацией ОС, модулей и так далее. После второго этапа мы получим полный набор файлов, которые можно скомпилировать и собрать в исполняемый файл.
Третий этап — компиляция и линковка. Тут все относительно просто — это обычный процесс сборки проекта.
Если все прошло удачно — на выходе будем иметь исполняемый файл (*.elf; *.axf), который мы прошьем в наш МК.
Прошивка МК и отладка приложений
Для программирования и отладки внешнего устройства нам понадобиться программатор.
С его помощью мы можем прошить наш код в память МК, который находится на плате. Также появляется возможность отладки приложения (пошаговое выполнение, просмотр переменных, точки остановки и прочие плюшки).
Заключение
В качестве заключения хотелось бы отметить — практически все клиенты из домена Automotive приходя в компанию GlobalLogic с новыми проектами в требованиях к разработчикам / менеджерам указывают эту страшную аббревиатуру. Стандарт активно используется и очень востребован на рынке.
В рамках данной колонки очень трудно объять необъятное и рассказать более детально о данной тематике. Но если Embedded — это ваше и вы хотите разрабатывать программы для автомобилей будущего, то приходите к нам!
Дело в том, что в отличие от других направлений, научиться AUTOSAR на серьезном проектном уровне самому очень сложно. Набор инструментов для отдельного рабочего места может стоить в среднем до 20 000 евро. Мало того, определенный ECU (электронный блок управления) является неотъемлемой частью всей экосистемы автомобиля, поэтому трудно с ним что-то сделать без общей архитектуры системы и средств моделирования. Есть много вещей, о которых невозможно прочитать или научиться по другому, кроме как на реальном автомобильном проекте. Подробнее о пути к GlobalLogic Academy можно узнать на специальной странице.
Михаил Кузьмин
flyman
Dmytro Kurbakov
Dmytro Kurbakov
flyman
Мавпа программиста
anonymous
11 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів