Communication Stack Types (ComStack_Types)

Модуль comstack предоставляет через ComStack_Types.h общие типы, с помощью которых все уровни коммуникационного стека Classic адресуют PDU и обмениваются ими: PduIdType в качестве дескриптора, PduLengthType в качестве длины и PduInfoType с указателем на полезные данные, указателем на метаданные и длиной ([SWS_COMTYPE_00011]). Транспортные протоколы копируют большие PDU посегментно через StartOfReception, CopyRxData и CopyTxData. О состоянии буфера они сообщают с помощью BufReq_ReturnType, в то время как RetryInfoType управляет подтверждением и повторением ([SWS_COMTYPE_00012]). Важнейшее граничное условие: разрядность PduIdType и PduLengthType зависит от конфигурации EcuC и генерируется.

больше ›

Модуль comstack определяет общий набор типов коммуникационного стека Classic. Сюда входят PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, RetryInfoType, а также идентификаторы для каналов и подсетей, доступные через ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00038]). Интерфейсы шин, транспортные протоколы, PduR, диагностические модули и RTE используют одни и те же типы; RTE явно импортирует их (SWS RTE с. 833).

Контекстная диаграмма: единый набор типов для всех уровней, масштабируемый через конфигурацию EcuC. Источники: [SWS_COMTYPE_00005], SWS RTE с. 833

Дескрипторы и длины зависят от конфигурации. PduIdType представляет собой uint8 или uint16, PduLengthType — uint8, uint16 или uint32; оба типа генерируются из конфигурации EcuC ([SWS_COMTYPE_00005], [SWS_COMTYPE_00008]). Каждый предоставляющий модуль сам выбирает идентификаторы своих дескрипторов. Уникальными они должны быть только в рамках каждого API; PduR транслирует их вдоль маршрута маршрутизации (ECU Configuration с. 156).

PduInfoType объединяет указатель на полезные данные, указатель на метаданные и длину. Таким образом, эта структура переносит запросы на передачу, индикации приема и Trigger Transmit. Большие PDU копируются по частям: транспортный протокол через PduR повторно вызывает CopyTxData верхнего уровня (SWS PduR с. 109). Прием начинается с StartOfReception и продолжается с CopyRxData.

Диаграмма последовательности: транспортный протокол извлекает передаваемые данные в цикле из DCM; подтверждение следует в конце. Источники: SWS PduR с. 109

Об ошибках и нехватке ресурсов сообщает BufReq_ReturnType ([SWS_COMTYPE_00012]):

• BUFREQ_E_BUSY: временно нет буфера или недостаточно данных; вызов разрешается повторить.
• BUFREQ_E_OVFL: нет буфера требуемой длины.
• BUFREQ_E_NOT_OK: прерывание.

Подтверждением и повторением при TP-передаче управляет RetryInfoType с помощью TP_DATACONF, TP_CONFPENDING и TP_DATARETRY вместе со смещением TxTpDataCnt ([SWS_COMTYPE_00027], [SWS_COMTYPE_00037]).

Дополнительные типы идентификаторов дополняют набор. NetworkHandleType (uint8) обозначает коммуникационный канал. TPParameterType выбирает STmin, Block Size или управление пропускной способностью для изменения ([SWS_COMTYPE_00031]). PNCHandleType в R20-11 является производным от uint8 ([SWS_COMTYPE_00036]); версия R23-11 в отличие от этого указывает uint16 (SWS ComStackTypes с. 17).

больше ›

Роль: общий набор типов коммуникационного стека

Модуль comstack не предоставляет собственных сервисов. Он определяет типы данных, посредством которых модули коммуникационного стека Classic взаимодействуют друг с другом. К ним относятся PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, TpDataStateType, RetryInfoType, TPParameterType, NetworkHandleType и PNCHandleType. Они доступны через ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00037], [SWS_COMTYPE_00038]). Интерпретация: таким образом, сам модуль не имеет поведения во время выполнения. Вопрос Q-766338989232e06a (открытый) Процессы, состояния и реакции на ошибки возникают только в тех модулях, которые используют эти типы в своих интерфейсах.

Поэтому системная граница проходит через весь стек. Одинаковые типы используют:

• интерфейсы шин, такие как CanIf, и транспортные протоколы, такие как CanTp (SWS CanIf с. 87),
• PDU Router и диагностические модули, такие как DCM (SWS PduR с. 109),
• SecOC (SWS SecOC с. 110),
• RTE, которая явно импортирует BufReq_ReturnType, PduIdType, PduInfoType, PduLengthType и RetryInfoType из ComStack_Types.h (SWS RTE с. 833).

Контекстная диаграмма: все уровни от интерфейса шины до RTE опираются на один и тот же набор типов из ComStack_Types.h; его размеры генерируются из конфигурации EcuC. Источники: [SWS_COMTYPE_00005], SWS RTE с. 833, SWS PduR с. 33, SWS ComM с. 171

Дескрипторы PDU и длины: идентичность и размер PDU

PduIdType представляет собой целое число с отсчетом от нуля в диапазоне 0…<PduIdmax>. Его разрядность (uint8 или uint16) зависит от максимального количества PDU, которыми управляет отдельный программный модуль. Инструмент генерации создает его на основе значения, сконфигурированного на виртуальном уровне EcuC в ComStack_Cfg.h ([SWS_COMTYPE_00005]). Соответствующий параметр PduIdTypeEnum определяет правило: UINT8 достаточно до тех пор, пока ни один модуль не обрабатывает более 256 PDU, иначе требуется UINT16 (ECU Configuration с. 153).

Аналогично PduLengthType в зависимости от конфигурации представлен как uint8, uint16 или uint32. Определяющей является максимальная длина PDU, передаваемых блоком управления ([SWS_COMTYPE_00008]). Транспортные протоколы также выводят длины из EcuC: CanTp определяет максимальную длину передачи N-PDU из параметра EcuC PduLength (SWS CanTp с. 60).

API стека объединяют две вещи: указатель на буфер данных PDU и идентификатор дескриптора (Handle-ID), определяющий, к какой PDU относится этот указатель. Значение Handle-ID предоставляющий модуль выбирает свободно. Так, одна и та же PDU может передаваться от Com в PduR с ID 5, а от PduR в CanIf с ID 19. Уникальным ID должен быть только в области действия соответствующего API (ECU Configuration с. 156). Чтобы два модуля могли ссылаться на одну и ту же PDU, в конфигурации виртуального модуля EcuC существует независимая от модуля EcucPduCollection (ECU Configuration с. 154). PduR идентифицирует путь маршрутизации по исходному ID и целевым ID, преобразует эти ID и передает значение PduInfoType дальше без изменений (SWS PduR с. 33).

Диаграмма кооперации: каждый интерфейс имеет собственные Handle-ID; PduR преобразует их, в то время как ссылка на общую PDU осуществляется через EcucPduCollection. Источники: ECU Configuration с. 156, ECU Configuration с. 154, SWS PduR с. 33

PduInfoType: полезные данные, метаданные и длина в единой структуре

PduInfoType объединяет три элемента ([SWS_COMTYPE_00011]):

• SduDataPtr указывает на полезные данные.
• MetaDataPtr указывает на метаданные, такие как CAN-ID, Socket-ID или диагностические адреса. Их длина и тип статически сконфигурированы для каждой PDU; элементы размером более 8 бит хранятся в порядке байтов платформы.
• SduLength типа PduLengthType задает длину SDU в байтах.

Одна и та же структура обеспечивает несколько форм взаимодействия:

• Запрос на передачу: <Mod>_Transmit(TxPduId, const PduInfoType*) передает длину, указатель на данные и указатель на метаданные и возвращает E_OK или E_NOT_OK (SWS CanIf с. 87).
• Индикация приема: <Mod>_RxIndication(RxPduId, const PduInfoType*). В CanNm указатель на данные действителен только до возврата из индикации (SWS CanNm с. 73).
• Trigger Transmit: PduInfoPtr является входом и выходом. При вызове SduLength содержит доступный размер буфера, а при возврате — длину скопированных данных (SWS CanIf с. 107). В предшествующем запросе на передачу верхний уровень передает только длину; SduDataPtr в этом случае указывает на NULL (SWS CanIf с. 158).
• Интерфейсы копирования TP: StartOfReception, CopyRxData и CopyTxData с возвратом BufReq_ReturnType (SWS PduR с. 93).

Буфер транспортного протокола: посегментное копирование вместо передачи целиком

Большие PDU не передаются целиком. Отправитель забирает данные по частям: DCM инициирует CanTp_Transmit через PduR. Затем CanTp циклически вызывает PduR_CanTpCopyTxData, который перенаправляется в Dcm_CopyTxData. В конце выполняются PduR_CanTpTxConfirmation и Dcm_TpTxConfirmation (SWS PduR с. 109). Для параметров CopyTxData действует следующее:

• info предоставляет целевой буфер и количество байтов для копирования.
• Значение SduLength, равное 0, лишь сообщает об изменении состояния в параметре retry или запрашивает доступный объем данных; SduDataPtr в таком случае может иметь значение NULL_PTR (SWS PduR с. 93).
• availableDataPtr сообщает об оставшихся данных для передачи. Модули TP с динамической длиной полезной нагрузки, такие как FrIsoTp, рассчитывают по нему последующие Consecutive Frames (SWS LdCom с. 34).

Диаграмма последовательности: при отправке через TP транспортный протокол извлекает данные из верхнего уровня в цикле через PduR; подтверждение следует только после последнего сегмента. Источники: SWS PduR с. 109, SWS PduR с. 93, [SWS_COMTYPE_00012]

Прием выполняется в три этапа:

1. StartOfReception открывает соединение. info содержит данные First Frame или Single Frame вместе с метаданными либо имеет значение NULL_PTR, если ни один из них не присутствует. TpSduLength указывает общую длину. Через bufferSizePtr приемник сообщает о своем свободном буфере; транспортный протокол вычисляет на этой основе Block Size (SWS PduR с. 92).
2. Каждый вызов CopyRxData доставляет следующий фрагмент I-PDU и записывает оставшийся размер буфера обратно (SWS PduR с. 91).
3. RxIndication завершает прием.

Если TP-PDU дополнительно маршрутизируется через шлюз, PduR сам буферизует ее, поскольку DCM ничего не знает о маршрутизации (SWS PduR с. 112).

Диаграмма последовательности: прием TP начинается с согласования буфера, продолжается посегментно и завершается индикацией. Источники: SWS PduR с. 112, SWS PduR с. 92, SWS PduR с. 91

Подтверждение и повтор: RetryInfoType и TpDataStateType

RetryInfoType содержит два поля ([SWS_COMTYPE_00037]):

• TpDataState описывает состояние буфера TP.
• TxTpDataCnt задает смещение относительно текущей позиции, которое определяет количество повторно отправляемых байтов.

TpDataStateType принимает три значения ([SWS_COMTYPE_00027]):

• TP_DATACONF: все скопированные к данному моменту данные подтверждены и могут быть удалены из буфера TP. Данные, скопированные при этом вызове, являются исключением.
• TP_DATARETRY: ранее скопированные данные копируются повторно для устранения ошибки. TxTpDataCnt указывает начальное смещение.
• TP_CONFPENDING: скопированные к данному моменту данные должны оставаться в буфере TP для устранения ошибки.

Если retry сам по себе равен NULL_PTR, данные могут быть освобождены сразу после копирования (SWS PduR с. 93).

Диаграмма деятельности: вызов CopyTxData сначала оценивает параметр retry и затем принимает решение о копировании или BUFREQ_E_BUSY. Источники: SWS PduR с. 93, [SWS_COMTYPE_00027], [SWS_COMTYPE_00012]

Схема транспортного протокола J1939 наглядно демонстрирует это взаимодействие:

• Для каждого блока первый пакет запрашивается с помощью TP_DATACONF, а последующие — с помощью TP_CONFPENDING.
• Если пакет TP.DT теряется, передача начинается снова с первого пакета блока. Для этого устанавливается TP_DATARETRY, а TxTpDataCnt содержит смещение относительно начала блока (SWS J1939Tp с. 55).

Не каждый пользователь обрабатывает этот параметр: в LdCom, согласно спецификации, retry не обрабатывается ни самим LdCom, ни его верхним уровнем (SWS LdCom с. 34).

Диаграмма последовательности: поблочная передача с состояниями подтверждения и возвратом к началу блока при потере пакета данных. Источники: SWS J1939Tp с. 55, [SWS_COMTYPE_00027], [SWS_COMTYPE_00037]

Каналы, подсети и параметры TP

NetworkHandleType представляет собой uint8 с диапазоном от 0 до 255 с отсчетом от нуля. Он хранит идентификатор коммуникационного канала ([SWS_COMTYPE_00038]). Примеры из более поздних релизов:

• Bus Mirroring сообщает о фрейме LIN с каналом ComM, сопоставленным с каналом LIN (SWS Mirror с. 80).
• J1939Dcm передает канал, по которому поступил запрос (SWS J1939Dcm с. 67).

PNCHandleType хранит идентификатор Partial Network Cluster и в R20-11 является производным от uint8 ([SWS_COMTYPE_00036]). В фрагменте документа из R23-11 вместо этого указывается uint16 (SWS ComStackTypes с. 17). Для R20-11 действует требование. Контекст применения идентификаторов PNC иллюстрирует, например, синхронизированное отключение PNC в ComM (SWS ComM с. 171).

TPParameterType указывает параметр транспортного протокола, значение которого необходимо изменить ([SWS_COMTYPE_00031]):

• TP_STMIN: Separation Time,
• TP_BS: Block Size,
• TP_BC: управление пропускной способностью транспортного протокола FlexRay.

Block Size и STmin появляются, например, во фрейме Flow Control транспортного протокола FlexRay-AR (SWS FrArTp с. 47).

Поведение при ошибке

Результат запроса буфера описывает BufReq_ReturnType ([SWS_COMTYPE_00012]):

• BUFREQ_OK (0): успешно.
• BUFREQ_E_NOT_OK (1): буфер недоступен.
• BUFREQ_E_BUSY (2): буфер временно недоступен; инициатору запроса следует повторить попытку в течение определенного времени.
• BUFREQ_E_OVFL (3): невозможно предоставить буфер требуемой длины.

Интерфейсы ставят эти значения в соответствие следующим образом:

• CopyTxData: если данных для передачи недостаточно, ничего не копируется и возвращается BUFREQ_E_BUSY; нижний уровень может повторить вызов (SWS PduR с. 93). В процессе постраничной буферизации (Paged Buffer) DCM BUFREQ_E_BUSY чередуется с подготовкой следующей страницы (SWS DCM с. 481).
• StartOfReception: BUFREQ_E_NOT_OK отклоняет соединение и прерывает прием; bufferSizePtr остается без изменений. BUFREQ_E_OVFL прерывает процесс, так как отсутствует буфер требуемой длины. В случае BUFREQ_OK без буфера запрошенного размера сообщается о размере буфера 0 (SWS DCM с. 273).
• CopyRxData: BUFREQ_E_NOT_OK означает, что из-за ошибки ничего не было скопировано (SWS PduR с. 91).
• Ошибка передачи в TP: устранение выполняется через TP_DATARETRY со смещением TxTpDataCnt ([SWS_COMTYPE_00027]).
• TriggerTransmit: E_NOT_OK означает, что ничего не было скопировано. PduInfoPtr в таком случае использовать нельзя, так как он может быть NULL или недействительным (SWS CanIf с. 107).

Дополнительные проверки определяются самими использующими модулями. Примеры:

• DoIP_SoAdTpCopyRxData при включенном обнаружении ошибок разработки проверяет, вызывался ли DoIP_Init ранее (SWS DoIP с. 77).
• FrIf_Transmit в состоянии FRIF_STATE_OFFLINE возвращает значение E_NOT_OK (SWS FrIf с. 68).
• Многие из этих функций реверсивны (reentrant) только для различных идентификаторов PDU, но не для одного и того же (SWS DoIP с. 75).

Дальнейшие подробные доказательства

В приведенном ниже обзоре классифицируются основные подтверждающие свидетельства (с [SWS_COMTYPE_00005] по [SWS_COMTYPE_00038]):

Обоснование	Классификация
[SWS_COMTYPE_00005], [SWS_COMTYPE_00008]	Зависящая от конфигурации разрядность PduIdType и PduLengthType, сгенерированная из EcuC
[SWS_COMTYPE_00011]	Структура PduInfoType, включая метаданные
[SWS_COMTYPE_00012]	Коды результатов всех запросов буфера TP
[SWS_COMTYPE_00027], [SWS_COMTYPE_00037]	Логика подтверждения и повтора при отправке через TP
[SWS_COMTYPE_00031], [SWS_COMTYPE_00036], [SWS_COMTYPE_00038]	Выбор параметров TP, идентификаторы PNC и каналов
ECU Configuration S. 156	Концепция Handle-ID: произвольно выбираемые значения для каждого модуля, уникальные для каждого API
SWS PduR S. 93, SWS PduR S. 92	Ссылочная семантика интерфейсов копирования TP
SWS J1939Tp S. 55	Схема обработки повторов (также указана для R20-11)