AUTOSAR Classic General & Standard Types

Кластер модулей General & Standard Types через заголовочные файлы Platform_Types.h, Std_Types.h и ComStack_Types.h предоставляет аппаратно-независимый базис для всех типов данных, статусов обратной связи и коммуникационных буферов Classic Platform (AUTOSAR_SRS_BSWGeneral с. 62). Он стандартизирует базовые архитектурные характеристики, такие как модели порядка байтов (endianness), стандартизированные возвращаемые значения, такие как Std_ReturnType, и коммуникационные структуры, такие как PduInfoType ([SWS_Std_00005], [SWS_COMTYPE_00008]). Поскольку это исключительно определения в заголовочных файлах без исполняемого кода, кластер не требует конфигурации времени выполнения, а также не имеет собственных задач или активной обработки ошибок (SWS_StandardTypes с. 27).

больше ›

Кластер модулей General & Standard Types включает три базовых заголовочных файла: platform (Platform_Types.h), std (Std_Types.h) и comstack (ComStack_Types.h). Являясь исключительно определениями типов, они не содержат исполняемого кода и не требуют конфигурации (SWS_StandardTypes с. 27). Они образуют общеплатформенный фундамент для аппаратно-независимой типизации, унифицируют особенности компиляторов и аппаратного обеспечения и снабжают все модули BSW и RTE согласованными структурами данных (AUTOSAR_SRS_BSWGeneral с. 62).

Архитектурная диаграмма: статическая архитектура уровней и включений кластера модулей «General & Standard Types» с экспортируемыми интерфейсами типов. Источники: AUTOSAR_SRS_BSWGeneral с. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

Иерархия включений выстраивается поэтапно: Platform_Types.h инкапсулирует специфичные для платформы свойства, такие как тип C99 boolean ([SWS_Platform_00027]), универсальные указатели буфера, такие как ConstVoidPtr ([SWS_Platform_91002]), а также символы порядка битов в регистрах CPU_BIT_ORDER ([SWS_Platform_00038]) и порядка байтов в памяти CPU_BYTE_ORDER ([SWS_Platform_00039]). На этой основе Std_Types.h предоставляет универсальные стандартные константы, такие как STD_ON/STD_OFF ([SWS_Std_00010]), структуры версий модулей через Std_VersionInfoType ([SWS_Std_00015]), а также фундаментальную систему статусов Std_ReturnType с E_OK и E_NOT_OK ([SWS_Std_00005], [SWS_Std_00006]).

Для коммуникационного стека AUTOSAR заголовочный файл ComStack_Types.h определяет все межпротокольные интерфейсные типы, такие как PduIdType ([SWS_COMTYPE_00005]), NetworkHandleType ([SWS_COMTYPE_00038]) и центральную буферную структуру PduInfoType ([SWS_COMTYPE_00008]). В сегментированных транспортных протоколах (например, CanTp или DoIP) тип возвращаемого значения BufReq_ReturnType совместно с RetryInfoType управляет синхронным резервированием буфера и копированием данных между уровнями BSW (SWS_DiagnosticCommunicationManager с. 291, [SWS_COMTYPE_00012]).

Диаграмма последовательности: путь сегментированного приема и буферизации транспортного протокола с использованием ComStack_Types (PduInfoType, BufReq_ReturnType). Источники: SWS_PDURouter с. 112, SWS_DiagnosticCommunicationManager с. 273, SWS_DiagnosticCommunicationManager с. 274

Хотя кластер не имеет собственной обработки ошибок или сообщений DET (SWS_StandardTypes с. 27), Std_ReturnType структурирует обработку ошибок всей системы: биты с 0 по 5 (от 0x00 до 0x3F) зарезервированы для стандартных ошибок и ошибок приложений, тогда как биты 6 и 7 заняты исключительно RTE ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes с. 15). Все определения типов специфицированы для реентерабельного использования в контекстах многозадачности и прерываний (SWS_CANInterface с. 87).

больше ›

Системная архитектура & роль кластера модулей

Кластер модулей General & Standard Types образует фундаментальную типологическую и аппаратно-абстрагирующую основу AUTOSAR Classic Platform в релизе R20-11. Он состоит из трех чисто заголовочных модулей: platform ([SWS_Platform_00038]), std ([SWS_Std_00005]) и comstack ([SWS_COMTYPE_00005]). В соответствии с архитектурой BSW эти модули не предоставляют собственного исполняемого кода C и не запрашивают другие драйверы BSW (SWS_StandardTypes с. 27). Их главная задача состоит в том, чтобы инкапсулировать зависимости от компилятора и процессора, предоставить единые для всей платформы базовые типы и установить стандартизированные структуры данных для коммуникационных уровней.

Иерархия уровней следует строгому однонаправленному порядку включения: файл Platform_Types.h абстрагирует свойства базовой архитектуры микроконтроллера (такие как расположение регистров и памяти, а также элементарные типы C99), тогда как Std_Types.h надстраивается над ним и определяет универсальные возвращаемые значения и константы статусов (AUTOSAR_SRS_BSWGeneral с. 62). На этой основе ComStack_Types.h объявляет все независимые от шин и протоколов типы данных для таких сетей, как CAN, FlexRay, LIN и Ethernet, а также для транспортных протоколов по ISO 15765-2 и диагностических протоколов по ISO 14229 ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). Благодаря такому разделению обеспечивается полная переносимость вышележащих уровней, таких как среда выполнения (RTE) и программные компоненты приложений (SWC) (SWS_RTE с. 818).

Архитектурная диаграмма: статическая архитектура уровней и включений кластера модулей «General & Standard Types» с экспортируемыми интерфейсами типов. Источники: AUTOSAR_SRS_BSWGeneral с. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

Взаимодействие и пути взаимодействия между модулями

Взаимодействие внутри кластера основано на статической цепочке включений: ComStack_Types.h включает Std_Types.h, который, в свою очередь, подключает Platform_Types.h (RS_BSWGeneral с. 60). Модуль platform определяет фундаментальные величины, такие как boolean, который обязательно должен отображаться на базовый тип C99 _Bool ([SWS_Platform_00027]), и регулирует его строгое присвоение значений через литералы TRUE и FALSE ([SWS_Platform_00034]). Кроме того, специфицируются обобщенные указатели на буфер, такие как ConstVoidPtr, которые используются для неизменяемых передаваемых буферов в вызываемых интерфейсах функций ([SWS_Platform_91002]).

Дополнительно platform гармонизирует порядок байтов и битов аппаратуры с помощью стандартизированных символов препроцессора: для порядка битов в регистрах CPU_BIT_ORDER задается как MSB_FIRST или LSB_FIRST ([SWS_Platform_00038], [SWS_Platform_00048], [SWS_Platform_00049]). Порядок байтов в физической памяти управляется через CPU_BYTE_ORDER, при этом различаются HIGH_BYTE_FIRST (Big Endian, MSB по младшему адресу) и LOW_BYTE_FIRST (Little Endian, LSB по младшему адресу) ([SWS_Platform_00039], [SWS_Platform_00050], [SWS_Platform_00051]).

Структурная диаграмма: отображение в памяти скалярных многобайтовых значений при Big-Endian (HIGH_BYTE_FIRST) и Little-Endian (LOW_BYTE_FIRST). Источники: AUTOSAR_CP_SWS_PlatformTypes с. 16, AUTOSAR_CP_SWS_PlatformTypes с. 15, [SWS_Platform_00050], [SWS_Platform_00051]

На следующем уровне абстракции модуль std определяет универсальные символы для состояний переключения и логических уровней: STD_HIGH (0x01u) и STD_LOW (0x00u) для физических уровней напряжения ([SWS_Std_00007]), STD_ON (0x01u) и STD_OFF (0x00u) для режимов активации ([SWS_Std_00010]), а также STD_ACTIVE (0x01u) и STD_IDLE (0x00u) для логических состояний выполнения ([SWS_Std_00013]). Для протоколов сообщений и трансформеров std также предоставляет Std_MessageTypeType с литералами STD_MESSAGETYPE_REQUEST (0x00) и STD_MESSAGETYPE_RESPONSE (0x01) ([SWS_Std_91001], [SWS_Std_00017]), а также тип указателя на функцию Std_ExtractProtocolHeaderFieldsType для извлечения заголовков протоколов ([SWS_Std_91003]).

Модуль comstack, в свою очередь, использует базовые типы из platform и std для структурирования всего буферного обмена и обмена данными в коммуникационном стеке. Центральной интерфейсной структурой является PduInfoType, объединяющая указатель на данные SduDataPtr (uint8*), указатель на метаданные MetaDataPtr и длину буфера SduLength типа PduLengthType ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). Идентификация I-PDU осуществляется через PduIdType ([SWS_COMTYPE_00005]). Для управления целыми каналами связи и подсетями comstack определяет идентификатор канала NetworkHandleType ([SWS_COMTYPE_00038]) и идентификатор подсети PNCHandleType ([SWS_COMTYPE_00036]), которые применяются, например, в процедуре Synchronized PNC Shutdown модулей ComM и Nm (SWS_COMManager с. 171).

При сегментированных передачах по транспортному протоколу (TP) согласование буфера выполняется через возвращаемые типы BufReq_ReturnType и структуру RetryInfoType ([SWS_COMTYPE_00012]). При синхронных вызовах копирования, таких как CopyTxData или CopyRxData, между такими модулями, как CanTp, PduR, DCM, DoIP или SecOC, BUFREQ_OK сигнализирует об успешной операции копирования, тогда как BUFREQ_E_BUSY сообщает о том, что временно доступно недостаточно буфера и разрешено повторить попытку (SWS_DiagnosticCommunicationManager с. 291, SWS_SecureOnboardCommunication с. 76). С помощью RetryInfoType с такими параметрами, как TP_CONFPENDING или TP_DATACONF, гарантируется, что данные останутся в буфере для возможных повторов или будут освобождены после подтверждения (SWS_IntrusionDetectionSystemManager с. 49).

Диаграмма последовательности: путь сегментированного приема и буферизации транспортного протокола с использованием ComStack_Types (PduInfoType, BufReq_ReturnType). Источники: SWS_PDURouter с. 112, SWS_DiagnosticCommunicationManager с. 273, SWS_DiagnosticCommunicationManager с. 274

Синхронизация, реентерабельность и контексты задач

Поскольку модули platform, std и comstack являются чисто заголовочными файлами без исполняемых объектных файлов, они естественным образом не реализуют циклические MainFunctions и не имеют собственных контекстов задач (SWS_StandardTypes с. 27). Однако они определяют сигнатуры и конвенции типов для функций, вызываемых через границы уровней. Все определения типов спроектированы так, что могут передаваться полностью реентерабельно и без сохранения состояния (SWS_CANInterface с. 87).

Практическое использование типов происходит в высокоасинхронных и конкурентных средах. Callback-функции приема данных, такие как CanIf_RxIndication или Dcm_CopyRxData, использующие PduInfoType и PduIdType, могут явно выполняться в контексте прерывания (SWS_CANInterface с. 164, SWS_DiagnosticCommunicationManager с. 274). В отличие от этого, решения по маршрутизации, выделение буферов или циклические передачи обрабатываются в периодических задачах верхних уровней (например, SoAd_MainFunction) (SWS_SocketAdaptor с. 104). Поскольку структуры указателей, такие как PduInfoType, могут разделяться между уровнем прерываний и уровнем задач, потокобезопасная синхронизация с помощью исключительных областей (защита от состояний гонки) возлагается на вызывающие и реализующие модули BSW.

Типичные жизненные циклы и режимы работы

Чистые определения типов не имеют жизненного цикла во время выполнения и не содержат функций инициализации или завершения работы (SWS_StandardTypes с. 27). Они должны быть статически включены во время компиляции до всех обрабатывающих модулей. Однако они формируют нормативную основу для отображения и мониторинга жизненного цикла других модулей BSW: для стандартизированного запроса версии std специфицирует структуру Std_VersionInfoType, содержащую vendorID, moduleID, а также версии программного обеспечения (sw_major_version, sw_minor_version, sw_patch_version) ([SWS_Std_00015]).

Кроме того, такие типы, как NetworkHandleType и PNCHandleType, поддерживают вышестоящее управление сетью и режимами при смене рабочих режимов, таких как запуск, нормальный режим, переход в спящий режим и пробуждение ([SWS_COMTYPE_00036], [SWS_COMTYPE_00038]). Так, на основе этих идентификаторов ComM управляет скоординированными отключениями и переходами состояний в объединении подсетей (SWS_COMManager с. 171, SWS_NetworkManagementInterface с. 106).

Обработка ошибок, DET-трассировка и кодирование статуса

Кластер модулей не предоставляет собственной активной обработки ошибок и не сообщает ни об ошибках разработки в DET, ни о производственных ошибках в DEM (SWS_StandardTypes с. 27). Вместо этого он нормирует общеплатформенный формат отклика: базовый тип Std_ReturnType основан на uint8 и служит на всех уровнях стандартным результатом синхронных вызовов ([SWS_Std_00005], BSWUMLModelModelingGuide с. 28). По умолчанию E_OK (0x00u) представляет успешное выполнение, а E_NOT_OK (0x01u) — общую ошибку ([SWS_Std_00006]). Из соображений совместимости с ISO 17356-3 (OSEK OS) E_OK защищен от повторных определений с помощью защитной проверки (STATUSTYPEDEFINED) (AUTOSAR_SRS_BSWGeneral с. 62).

Битовая структура Std_ReturnType следует строго определенному разделению: биты от 0 до 5 (диапазон от 0x00 до 0x3F) зарезервированы для стандартизированных и модулеспецифичных возвращаемых значений или специфичных для приложения кодов ApplicationError в клиент-серверных операциях ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes с. 15). Модулеспецифичные расширения ведутся в UML-моделях как класс со стереотипом «extra_literals» (BSWUMLModelModelingGuide с. 33). Биты 6 и 7 (диапазон значений 0x40, 0x80, 0xC0) строго зарезервированы для инфраструктурных состояний ошибок RTE (AUTOSAR_CP_SWS_StandardTypes с. 15). Для преобразований данных в RTE std дополнительно объявляет структуру Std_TransformerError, состоящую из errorCode ([SWS_Std_00022]) и transformerClass ([SWS_Std_00021]), что позволяет непрерывно отслеживать цепочки ошибок при сериализации или E2E-защите.