Зачем нужны стандарты при создании логики автомобиля. Краткое введение в Autosar

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Меня зовут Денис Кондратенко, я 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 представляет собой электронную плату с микроконтроллером, который работает под управлением простой операционной системы (ОС) или банального переключателя задач. Объем постоянной памяти — 1-5 Мб, оперативной — пару сотен килобайт. Каждая ECU живет похожим со всеми другими жизненным циклом (инициализация, работа, сон), каждая содержит память для сохранения параметров в ходе работы (EEPROM), тот же набор базовых коммуникационных интерфейсов — UART/LIN, CAN, I2C, SPI, те же таймеры (включая сторожевой), ШИМ, прерывания и прочее. Отличаются они друг от друга бизнес-логикой и аппаратной реализацией.

Если, вдруг, вам кажется, что от проекта к проекту

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

То могу Вас поздравить — Вам таки не кажется! 😊 В древних 2000-х годах, а то и ранее, примерно так же рассуждали автопроизводители (OEM), их компании-поставщики (Tier1, Tier2) и их инженеры.

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

Решение проблем — 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 файлов. Сам набор представляет собой древовидную структуру.

Каждый компонент системы состоит из двух частей:

  1. файл с конфигурацией для данного компонента (*.arxml);
  2. исходный код компонента (*.c; *.h файлы).

В процессе генерации кода, на базе arxml-файлов создаются *.c и *.h файлы, содержащие в себе конфигурацию компонента. После этапа генерации, код компонента может быть собран компилятором.

Генерация и сборка исходного кода

Когда проект настроен, можно попробовать его собрать.

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

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

Третий этап — компиляция и линковка. Тут все относительно просто — это обычный процесс сборки проекта.

Если все прошло удачно — на выходе будем иметь исполняемый файл (*.elf; *.axf), который мы прошьем в наш МК.

Прошивка МК и отладка приложений

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

С его помощью мы можем прошить наш код в память МК, который находится на плате. Также появляется возможность отладки приложения (пошаговое выполнение, просмотр переменных, точки остановки и прочие плюшки).

Заключение

В качестве заключения хотелось бы отметить — практически все клиенты из домена Automotive приходя в компанию GlobalLogic с новыми проектами в требованиях к разработчикам / менеджерам указывают эту страшную аббревиатуру. Стандарт активно используется и очень востребован на рынке.

В рамках данной колонки очень трудно объять необъятное и рассказать более детально о данной тематике. Но если Embedded — это ваше и вы хотите разрабатывать программы для автомобилей будущего, то приходите к нам!

Дело в том, что в отличие от других направлений, научиться AUTOSAR на серьезном проектном уровне самому очень сложно. Набор инструментов для отдельного рабочего места может стоить в среднем до 20 000 евро. Мало того, определенный ECU (электронный блок управления) является неотъемлемой частью всей экосистемы автомобиля, поэтому трудно с ним что-то сделать без общей архитектуры системы и средств моделирования. Есть много вещей, о которых невозможно прочитать или научиться по другому, кроме как на реальном автомобильном проекте. Подробнее о пути к GlobalLogic Academy можно узнать на специальной странице.

Использованные источники

👍НравитсяПонравилось10
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Довелось как-то поработать в autosar и могу сказать, это крайне противная штука ведущая в никуда. Я считаю сощусетвование данной органицзаци и будет причина почему Китай обойдет европейский автопром.

В то время как Китай и США делают автопилоты, европейцы ждут пока будет реализация адаптивного autosar. И это существенно тормозит развитие.

Autosar чистое зло. Никому не оветую идти и развиваться в этом направлении до 50 лет. А когда захочется сидеть и философствовать на встречах, и рисовать много диаграм, добро пожаловать.

Очень субъективное мнение. Спорить не буду. :)
Adaptive конечно еще очень сырой, но касательно Classic — реальных задач и проектов хватает.
Практически все проекты Automotive в GlobalLogic его требуют (в большей или меньшей степени).

Autosar это лишь стандарт. Сама реализация продается за очень большие деньги. Любой тренинг стоит очень больших денег. Сам формат autosar заточен на то, чтобы собирать деньги.

Касательно всех проектов, это обусловлено то с кем вы работаете. Я не думаю что GlobalLogic сам решил выбрать autosar для разработки.

Изначально autosar Classic был придуман чтобы решить проблему зоопарка возможных комбинаций машины. Но я не могу сказать что autosar добавляет удобство в разработке. Да все инструменты autosar Classic поддерживают лишь Винду. И там подавляющем большинстве все идёт через графический интерфейс. Мне это больше похоже не как инструмент для разработчика, а инструмент чтобы менеджер мог мышкой конфигурировать arxml.

Безусловно это лишь мои личные предпочтения и мое личное мнение которое не претендует на истинную правду.

тока класік це АС, а АА нова відоформа С++14

П.С.
АА це POSIX бейзд, АС моар RT

ее.
шас ужє єсть АА — Автозар Адаптів, оце справжнє зло: відкінута лампова Сшка, так как не нужна, введено новий діалєкт ЦеПеПЕ — АутозарЦеПеПе, вопщєм аутомотів живе своїм жизньом

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

кстаті, в ЛС і ГЛ іпуть на собісаї хрестами, а насправді в аутомотіві 85% якраз то що пан написав вище, дохріна кодєгєна, а «тру кодінг» хіба ще на одинадцятих хрестах, і то який бахфікс та тестврітінг

Таким образом, мы можем легко переносить бизнес логику с одной ECU на другую. Или взять AUTOSAR слой у другого поставщика (можем даже написать его сами — стандарты-то открытые!). Или сменить один микроконтроллер на другой. Все это можно сделать относительно просто и безболезненно для проекта.

Ну-ну. У того же вектора вместе с SIPом идёт Technical References для каждого модуля из BSW, и обычно в начале документа есть раздел Supported/Not supported AUTOSAR requirements. У другого поставщика этот набор отличий от спецификации может быть совершенно другим.

Он станет базовым и из него будут сгенерированы так называемые файлы выжимки — EcuExtract.arxml. Данные файлы передаются субподрядчикам для разработки подсистем. Так, общую картину субподрядчики не видят, но получают четкий API для разработки своих частей.

Это скорее не апи, а описание входящих/исходящих/мимо проходящих pdu, сигналов, адресов, протоколов — т.е. коммуникационный интерфейс ecu с окружением.

Набор инструментов для отдельного рабочего места может стоить в среднем до 20 000 евро

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

Стандарт активно используется и очень востребован на рынке

А вот тут спорный момент. Порог входа очень высокий, как материальный, так и нематериальный — в гугле кроме самих спек найти что-то крайне тяжело, т.е. скопипастить со стековерфлоу не получится. В Украине вообще эмбеддеда мало, а с автосаром ещё и инженеров почти нет. Внимание вопрос — есть ли готовность со стороны работодателей на повышенную компенсацию (х2 минимум) за работу с маловостребованной технологией с сомнительными перспективами на местном рынке? Потому что qt/linux учить намного проще, и работы намного больше.

AUTOSAR специфицирует интерфейсы (стандарты). Т.е. как наборы лего — совместимы между собой, так и компоненты по стандартам AUTOSAR.
Если в МК есть только один CAN интерфейс, а Вам надо 3 — тут AUTOSAR не причем (выбор МК нужен правильный). Так же по BSW — если за этот модуль не заплачено, то его и не будет в поставке.
Девайсы есть — проект обеспечивает. Работаем с реальным железом, программаторами, тулами от Вектора.
У Global’а есть отдельные лицензии для обучения (Autosar Academy).
Проблемы конечно есть — куда ж без них. :)
Но в целом жить можно.
По ЗП (x2)???? Может дешевле будет немца нанять? ;)

По ЗП (x2)???? Может дешевле будет немца нанять? ;)

наймате, базар великий
але чомусь польська галєра більше платить чим лідери аутсорца вна неньці
і попасти простіше без цепепе інтерву гуру кодінг тазскс

. Внимание вопрос — есть ли готовность со стороны работодателей на повышенную компенсацию (х2 минимум) за работу с маловостребованной технологией с сомнительными перспективами на местном рынке?

да єсть, рейт X/2

Подписаться на комментарии