AUTOSAR не нуждается в представлении для всех любителей автомобильной техники. Консорциум AUTOSAR был сформирован автопроизводителями для противодействия сложностям, возникшим из-за увеличения использования ECU (электронных блоков управления) в автомобилях.

Эта программная архитектура AUTOSAR обеспечивала отделение функциональных возможностей продукта от аппаратных и программных сервисов.

Эта стандартизация помогла разработчикам автомобильных встраиваемых систем сосредоточиться в первую очередь на инновациях в разработке функций продукта, а не на разных архитектурах.

Это изменение в подходе к разработке автомобильных ECU оказалось одинаково выгодным для автопроизводителей и их поставщиков первого уровня. Почему ты спрашиваешь? Поставщики после AUTOSAR, OEM-производители и Tier-I смогли сэкономить затраты, потраченные на различные инструменты разработки программного обеспечения, требуемые в эпоху нестандартной архитектуры.

Архитектура программного обеспечения AUTOSAR привела к стандартизации, которой следуют производители и поставщики при разработке программного обеспечения без каких-либо проблем совместимости.

Когда диагностика автомобиля встретила архитектуру программного обеспечения AUTOSAR
В автомобилестроении диагностика должна выполняться на всех ЭБУ, чтобы гарантировать отсутствие проблем с электронным управлением компонента автомобиля. Любая проблема, с которой сталкивается автомобильный ЭБУ, сохраняется в виде кода неисправности диагностики (DTC) в электрически стираемом программируемом постоянном запоминающем устройстве (EEPROM). Эти коды могут быть получены позже, используя автомобильный диагностический инструмент.

Теперь система диагностики транспортных средств должна быть реализована в архитектуре AUTOSAR, и это то, что этот блог стремится исследовать.

Чтобы понять, как диагностика реализована в архитектуре AUTOSAR, давайте кратко рассмотрим архитектуру.

На уровне базового программного обеспечения существуют сотни программных модулей, включая те, которые подразделяются на уровень абстракции микроконтроллера (MCAL) , уровни абстракции ECU и уровень обслуживания.

Блог будет посвящен уровню обслуживания базового программного модуля AUTOSAR, поскольку здесь хранятся сервисы диагностики автомобилей.

По сути, в этом слое есть три модуля, на которые возложена разная ответственность в отношении диагностики автомобиля. Мы обсудим их в следующих разделах.

На приведенной ниже схеме показаны различные компоненты диагностического стека (DCM, DEM, FIM и т. Д.).
Диагностический коммуникационный менеджер (DCM)
Диспетчер диагностической связи (DCM) несет ответственность за чтение и запись кодов неисправностей или диагностических кодов неисправностей в память неисправностей автомобильного ЭБУ. Он поддерживает реализацию диагностических протоколов, таких как UDS (ISO 14229) и OBD II.

Когда автомобильный ЭБУ получает запрос на диагностику от тестера, DCM выполняет его предварительную обработку. Хотя он обрабатывает большинство запросов, любой другой запрос направляется в функциональное программное обеспечение. Каждая новая версия DCM имеет расширенный функциональный диапазон, который увеличивает его способность обрабатывать различные типы диагностических запросов.

DCM состоит из подфункций идентификаторов услуг (SID), идентификаторов данных (DID) и стандартных идентификаторов для обработки запросов диагностики транспортного средства .

При обработке запросов диагностики от внешних инструментов тестирования во время разработки программного обеспечения ECU, производства программы транспортного средства или обслуживания гаража DCM также управляет состоянием сеанса и состояниями безопасности.

Например, DCM проверяет, может ли поддерживаться конкретный диагностический запрос, а также будет ли выполняться эта служба в текущем сеансе.

Мы немного углубимся в различные компоненты DCM и то, как они взаимодействуют друг с другом.

Уровень сеанса диагностики. Этот подмодуль отвечает за обеспечение потока данных, связанных с диагностическими запросами и ответами. Сеанс диагностики и состояния безопасности управляются этим уровнем вместе с контролем временных параметров диагностического протокола.

Диагностический сервисный диспетчер: необходимо проверить правильность входящих диагностических запросов, и именно здесь этот субмодуль входит в картину. Помимо обеспечения правильности запроса, он также отслеживает ход выполнения запроса.

После завершения проверки этот подмодуль обрабатывает поток диагностических данных, а также передает ответ после обработки данных.

Модуль обработки диагностической услуги (DSP): это место, где происходит реальная обработка. DSP анализирует формат запроса на обслуживание и взаимодействует с другими компонентами BSW AUTOSAR для извлечения данных, необходимых для обработки. Сервисный ответ также собирается им.

Эти три подмодуля взаимодействуют друг с другом с помощью определенных интерфейсов. Описание этих интерфейсов выходит за рамки блога, и мы подробно обсудим их в последующих блогах.

Чтобы сделать автомобильный ECU продуктом, совместимым с AUTOSAR , сначала необходимо настроить DCM с помощью таких инструментов, как Vector Tool Chain. В процессе разработки все необходимые API кодируются в DCM, включая общие определения DCM.

Модульное тестирование и интеграционное тестирование следуют процессу разработки. Модульное тестирование выполняется с использованием таких инструментов, как Tessy Test Systems, где анализируется исходный модуль и тестируются функции.

Интеграционный тест выполняется на плате оценки, где проверяются данные, которыми обмениваются модули. По сути, он проверяет, все ли интерфейсы работают без проблем.

Диагностика Event Manager (DEM)
DEM отвечает за хранение и обработку диагностических ошибок (событий) и всех данных, связанных с ним. В дополнение к этому, DEM предоставляет диагностические коды неисправностей (DTC) Диспетчеру диагностической связи (DCM) по мере необходимости.

Предоставление интерфейса для прикладного уровня ECU и других модулей базового программного модуля AUTOSAR также является одной из обязанностей DEM.

Может быть два типа событий, о которых можно сообщить DEM:

Событие базового программного обеспечения - событие, о котором сообщает базовое программное обеспечение
Событие программного компонента, сообщаемое прикладным уровнем AUTOSAR
События, сообщаемые ЦМР, должны быть сначала квалифицированы, чтобы гарантировать, является ли это неисправностью (отказ компонента) или просто происшествием (нерегулярное поведение системы).

После того, как событие квалифицировано, DEM записывает данные события и связывается с DCM для обработки события и FIM (модуль блокировки функций) для функционального управления (описано в следующем разделе).

Модуль блокировки функций (FIM):
FIM - это, по сути, механизм управления базовым программным обеспечением и его компонентами. FIM должен контролировать функциональность, доступную для этих компонентов, в зависимости от условий их запрета.

Идентификатор присваивается функциональности с условием запрета. Только в случае, если условие запрета не соответствует действительности, функциональность выполняется.

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

Услуги FIM в основном ориентированы на приложения, находящиеся в программных компонентах; однако базовое программное обеспечение AUTOSAR (BSW) также может использовать службы FIM при необходимости.

FIM имеет тесную связь с DEM, поскольку диагностические события и информация о их состоянии рассматриваются FIM как функция запрета. Когда обнаружен сбой, он сообщается в матрицу высот, и задача FIM - остановить определенные функции.

Заключение
Реализация UDS в базовом программном обеспечении архитектуры AUTOSAR требует двух состояний проектирования и очень сложного кодирования во время конфигурации.

Кроме того, конфигурация диспетчера диагностической связи (DCM) должна выполняться с учетом определенных параметров, определенных AUTOSAR. Именно здесь цепочки инструментов AUTOSAR становятся очень важными.

Эти платформы помогают разработчикам автоматически генерировать определенный код и писать остальные. Конфигурирование параметров также становится довольно простым с помощью программ цепочки инструментов, таких как Electrobit, Vector Tool Chain и некоторых других. Купить диагностическое оборудование в Орле