AUTOSAR CAN Советы по реализации стека - PullRequest
Новая
       132

AUTOSAR CAN Советы по реализации стека

0 голосов
/ 13 апреля 2020

Моя задача - создать программный стек для модуля CAN с использованием последней версии AUTOSAR (R19-11). Я не буду использовать какие-либо инструменты настройки. Из того, что я прочитал на веб-сайте AUTOSAR , я должен реализовать следующие модули: драйвер CAN, интерфейс, диспетчер состояний, маршрутизатор PDU и AUTOSAR COM. Поскольку я не собираюсь использовать кадры, которые содержат более 8 байтов данных, мне не понадобится модуль CAN Transport Protocol.

При отправке PDU вниз по стеку некоторые модули добавляют метаданные к этим полученным PDU (которые называются SDU локально), а затем отправляют их на следующий уровень. Я читал, что мы должны назначить уникальные идентификаторы этим PDU. Кроме того, у нас должна быть таблица маршрутизации (внутри маршрутизатора PDU), которая будет использоваться для определения пункта назначения каждого PDU на основе их идентификаторов.

Мои вопросы:

  • Как назначены идентификаторы?
  • Как будет выглядеть идентификатор?
  • Для данного кадра CAN, нужно ли мне назначать другой идентификатор на основе текущего местоположения блока PDU в стеке? (COM, Диспетчер состояния, Интерфейс или Драйвер)
  • Зная, что пользователь (прикладной уровень) может определить произвольное количество CAN-кадров, как маршрутизатор PDU заранее знает, какой идентификатор определенного PDU и каков его пункт назначения будет?
  • Как будет выглядеть передача (или прием) сообщения, начиная с прикладного уровня и заканчивая на модуле драйвера CAN?
  • Какие метаданные (или PCI - информация управления протоколом, как это называется в AUTOSAR) будут добавлены модули, которые получают PDU? Например: приложение отправляет данные 0xAA. COM получает этот PDU и добавляет специфицированный c PCI, затем отправляет его на маршрутизатор PDU и так далее. Как бы выглядел SDU + PCI = PDU на каждом этапе?

1 Ответ

0 голосов
/ 17 апреля 2020

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

Ну, не реализовав CanTp, вы тоже нет диагностики клиента (UDS)? И, между прочим, CAN-FD имеет кадры до 64 байтов.

Определение PduIdType находится в AUTOSAR_SWS_CommunicationStackTypes Ch. 8.1.1. SWS_COMTYPE_00005, SWS_COMTYPE_00006, SWS_COMTYPE_00007, SWS_COMTYPE_00014.

Короче говоря, они представляют собой целые числа без знака, начинающиеся с нуля и последовательные для использования в качестве индекса конфигурации в конфигурации модулей. И они создаются для каждого модуля BSW, поэтому у вас есть набор CanIf-PduIds, PduR-PduIds, IpduM-PduIds, Com-PduIds, SecO C -PduIds, и их также можно разделить между Rx и Tx (так что набор RxPduIds, начинающийся с 0, и набор TxPduIds, начинающийся также с 0). Таким образом, PDU CanFrames может иметь разные идентификаторы PDU в CanIf, PduR, Com и др. c. и мультиплексированные кадры разделены на отдельные блоки PDU с разными PduI для каждого мультиплексора.

Еще одна глава, о которой следует прочитать, - это AUTOSAR_TPS_EcuConfiguration Ch. 3.4 Конфигурация COM-Stack.

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

...