Спустя год после переключения карьеры с полного стека на встроенную систему, вместо того, чтобы начинать с Raspberry Pi, я работаю над полномасштабным проектом по разработке автомобильного блока управления с использованием Autosar. Я хотел заниматься машинным обучением на смене работы, но попал в эту область, и это просто жизнь! Я удивлен тем, как много документации нужно прочитать разработчику аппаратного обеспечения только для того, чтобы выполнять свою работу, и я хочу поделиться некоторым опытом того, почему эта документация важна и как она используется для резервного копирования реализации.

Документация ISO

Существует множество таких ISO, определяющих, как такие вещи, как flexray, должны работать, и все аппаратное и программное обеспечение должно следовать их рекомендациям. Существует ISO26262, связанный с безопасностью, и любой блок управления двигателем, которому необходимо достичь уровня целостности автомобильной безопасности (ASIL), должен следовать его рекомендациям. Мой опыт до сих пор был ISO14229 для реализации услуг UDS, и некоторые ISO в области испытаний на электромагнитную совместимость — эти напряжения, ток, радиоволны — все это для инженеров-электронщиков.

Стандарты и документация Autosar

Поскольку Autosar используется для настройки и создания API, взаимодействующего с оборудованием, таким как ram, rom, can, flexray и, самое главное, с чипом. Есть несколько основных, проходящих через общую архитектуру, и каждый базовый программный модуль имеет свой собственный. Я только читал архитектуру. Представьте, что comstack настроен неправильно и блок управления не может получить сигнал, тогда вам нужно прочитать документацию и проверить, почему.

Руководство по микроконтроллеру

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

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

Прямой доступ к памяти: мы внедрили драйвер Ethernet низкого уровня, который не включен в Autosar SIP. Так сказать реализация прерывания DCM, управляемая операционной системой. Если вы не читаете мануал, во-первых, вы не поймете, как работает железо и каким должен быть процесс инициализации. Мы делали циклические тесты и читали руководство около 2 недель, задаваясь вопросом, почему это не работает, и, наконец, выяснили, что процесс аппаратной инициализации был выполнен не в правильном порядке, и проблема была решена путем перемещения 3 строк кода вниз. метода.

Спецификация ОС

Когда мы занимаемся разработкой ecu, мы поставляем пользовательскую операционную систему, и даже ядро ​​компилируется с использованием некоторых наших собственных реализаций. Существуют различные операционные системы реального времени (microsaros, eta-os), соответствующие стандартам ОС Austosar. ОС и компилятор сделаны таким образом, чтобы быть совместимыми с микроконтроллером, поэтому чтение спецификации компилятора также помогает понять архитектуру микроконтроллера.

Забавно то, что настройка Autosar это просто выпадающий список и нажатие, но если вы плохо разбираетесь в ОС или не читаете спецификации ОС, вы никогда не поймете, что такое protectionhook, stackoverrunhook, приоритет, максимальное количество активаций и не сможете выполнить настройку правильно и не сможет выполнить реализацию в osal.c. Давайте рассмотрим два примера и посмотрим, почему важно читать спецификацию.

Максимальное количество активаций

Допустим, задача TaskA запланирована на запуск каждые 10 мс, а время ее выполнения составляет 5 мс. Но по какой-то причине задача B вытесняет задачу A и выполняется 15 мс, затем выполняется переключение контекста и возврат к выполнению задачи A. Таким образом, taskA никогда не завершает свое выполнение в течение 10 мс, а количество активаций все время увеличивается. Руководство скажет нам установить значение для максимальной активации, если задача A является важной задачей, которая должна быть завершена в течение 10 мс, тогда мы устанавливаем 1 в качестве порога, если задача A когда-либо пропускает свой крайний срок, возникает ошибка.

Защита памяти

Взяв, к примеру, etaos, это один стек, что означает, что по мере вытеснения все задачи располагаются друг над другом в одной и той же последовательной ячейке памяти. С точки зрения безопасности, если вашему автомобилю необходимо выполнить Asil, задача A не должна иметь доступа к содержимому из расположения стека, зарезервированного для задачи B. Чтобы понять, как это делается, вам нужно немного изучить модуль защиты памяти (MPU). Представляя, что задача B вытесняет задачу A, и ее стек начинается с 0x2000, а адрес ниже зарезервирован для задачи A, MPC будет отслеживать выполнение инструкции в регистре для задачи B, если он обнаружит какую-либо сборку, выполняющую такие действия, как «переместить что-то 0x1000», он знает, что задача B нарушает адрес, который он не должен касаться. Если вы читали руководство по etaos, в нем объясняется, как сгруппировать переменные вместе в виде разделов в отображении памяти и скрипте компоновки, и вам нужно определить, какие правила защиты следует вводить каждый раз, когда происходит переключение контекста.

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