DEENESPTFRRUARHIKOZHNL

Standard Types (Std_Types)

ModulStd (Standard Types)
BSW-Modul-ID197
Standard-Header#include "Std_Types.h"
SWS-SpezifikationAUTOSAR_SWS_StandardTypes.pdf
ClusterGeneral & Standard Types

Руководство по модулюСОЗДАНО ИИ

Предоставляет унифицированные типы возвращаемых значений, версий, трансформеров и констант для всех модулей Classic.
СОЗДАНО ИИ не проверено Модель: claude-opus-5-5 · Усилие: high · Температура: не регулируется · Промпт: 4fcc802ced39 Происхождение Открытые вопросы (4)
Причинный якорь: R20-11 Действует с R20-11 Заново синтезировано для этой версии спецификации.
переведено с немецкого руководстваgemini-3.8-flash-low · 2026-10-13 · Немецкий оригинал

Предоставляет унифицированные типы возвращаемых значений, версий, трансформеров и констант для всех модулей Classic.

Модуль std предоставляет через Std_Types.h унифицированные в масштабах платформы типы и константы, но не содержит ни кода, ни конфигурации. Центральным является Std_ReturnType (uint8) с E_OK и E_NOT_OK. Модулям разрешено определять собственные значения только в диапазоне 0x02–0x3F с префиксом модуля, поскольку биты 7 и 8 зарезервированы за RTE [SWS_Std_00011]. Кроме того, модуль предоставляет константы STD_HIGH/STD_LOW, STD_ON/STD_OFF и STD_ACTIVE/STD_IDLE, тип Std_VersionInfoType для запроса версии, а также типы трансформеров и сообщений для взаимодействия «клиент — сервер». В R20-11 заголовочный файл также подключает Compiler.h SRS BSWGeneral с. 62.

Модуль std представляет собой заголовочный файл чисто с типами. Через Std_Types.h он предоставляет типы и символы, но не функции [SWS_Std_00005]. В R20-11 заголовочный файл подключает Platform_Types.h и Compiler.h и определяет Std_ReturnType, а также значения E_OK/E_NOT_OK и константы STD_*. Каждый модуль, использующий эти типы, подключает его SRS BSWGeneral с. 62. Конфигурация и собственная обработка ошибок, согласно более поздней редакции спецификации, отсутствуют; для R20-11 это, вероятно, справедливо в той же степени (интерпретация) SWS StandardTypes с. 27. Вопрос (открытый)

kontext std Std_Types.h (Modul std) plat Platform_Types.h std->plat #include comp Compiler.h (in R20-11 gefordert) std->comp #include bsw BSW-Module (z. B. Can, CanIf, Adc, NvM) bsw->std #include cdd Complex Device Driver cdd->std #include rte RTE (Rte_Call, Rte_Read, Rte_Send, …) rte->std nutzt Std_ReturnType, Std_TransformerError xf Transformer (SomeIpXf, E2EXf) xf->std nutzt Std_MessageTypeType, Std_MessageResultType swc SW-C swc->rte API RTE с Std_ReturnType / transformerError

Контекстная диаграмма: Std_Types.h как общий базис типов для BSW-модулей, CDD, RTE и трансформеров. Источники: SRS BSWGeneral с. 62, CDD Guideline с. 14

Ядром модуля является Std_ReturnType (uint8) со значениями E_OK (0) и E_NOT_OK (1). Диапазон 0x02–0x3F предусмотрен для специфичных для модулей ошибок с префиксом модуля; биты 7 и 8 определяет спецификация RTE [SWS_Std_00011]. Примерами таких расширений являются CAN_BUSY и Csm_ReturnType BSWUML Guide с. 29. E_OK защищен из-за OSEK через STATUSTYPEDEFINED [SWS_Std_00006].

returntype rt Std_ReturnType (abgeleitet von uint8) ok E_OK = 0x00 (kein Fehler) rt->ok Standardwert nok E_NOT_OK = 0x01 (generischer Fehler) rt->nok Standardwert user 0x02–0x3F модульно-специфичные значения (6 младших битов, префикс модуля) rt->user erweiterbar rtebits Бит 7 и бит 8 зарезервированы, определены спецификацией RTE rt->rtebits reserviert csm Csm_ReturnType «extra_literals» CSM_E_BUSY = 2 CSM_E_SMALL_BUFFER = 3 CSM_E_ENTROPY_EXHAUSTION = 4 csm->rt erbt von csm->user belegt can CAN_BUSY = 0x02 (Can_Write: kein Sendeobjekt frei) can->user belegt

Контекстная диаграмма (структура типов): стандартные значения, модульный диапазон и зарезервированные RTE биты Std_ReturnType. Источники: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes с. 15

К этому добавляются три пары констант со значениями 0x01u/0x00u каждая: STD_HIGH/STD_LOW для физических уровней, STD_ON/STD_OFF в качестве переключателей и STD_ACTIVE/STD_IDLE для логических состояний ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]). Std_VersionInfoType передает ID производителя, ID модуля и версию программного обеспечения для синхронной, рев enterable функции <Ma>_GetVersionInfo [SWS_Std_00015].

Для трансформации данных std определяет два типа ошибок трансформера: Std_TransformerError, структуру из кода ошибки и класса трансформера, и Std_TransformerClass [SWS_Std_00021]. RTE передает эту ошибку через опциональный параметр transformerError SWS RTE с. 731. Для взаимодействия «клиент — сервер» Std_MessageTypeType и Std_MessageResultType кодируют запрос/ответ и OK/ERROR. Указатель на функцию типа Std_ExtractProtocolHeaderFieldsType считывает оба значения из заголовка трансформера [SWS_Std_91003]. Типы прямой передачи (Forward) в R20-11 являются пока лишь проектом [SWS_Std_00029].

Роль и границы системы: чисто заголовочный файл типов без поведения времени выполнения

Модуль std (Standard Types) не содержит функций. Он предоставляет исключительно типы и символы, доступные через Std_Types.h. Каждое требование модуля называет этот заголовочный файл источником получения, например [SWS_Std_00005] и [SWS_Std_00015]. Спецификация прямо констатирует: заголовочный файл не предоставляет кода и не требует других модулей BSW, он не имеет конфигурации и собственной обработки ошибок SWS StandardTypes с. 27. Эти формулировки взяты из редакции начиная с R23-11. Для R20-11 должно быть справедливо то же самое, поскольку требования R20-11 содержат исключительно определения типов и символов (интерпретация). Вопрос Q-8e4c66ae80752d38 (открытый)

Целью является единообразный, общеплатформенный доступ к стандартным типам. Поэтому требование BSW к заголовочному файлу стандартных типов предписывает: каждый модуль, использующий целочисленные типы AUTOSAR или стандартный тип возвращаемого значения, подключает Std_Types.h SRS BSWGeneral с. 62. Тип возвращаемого значения Std_ReturnType явно разделяется между RTE и модулями BSW [SWS_Std_00005]. В методологии стандартные типы дополнительно описаны как ARXML-артефакт «AUTOSAR Standard Types» Methodology с. 400.

kontext std Std_Types.h (Modul std) plat Platform_Types.h std->plat #include comp Compiler.h (in R20-11 gefordert) std->comp #include bsw BSW-Module (z. B. Can, CanIf, Adc, NvM) bsw->std #include cdd Complex Device Driver cdd->std #include rte RTE (Rte_Call, Rte_Read, Rte_Send, …) rte->std nutzt Std_ReturnType, Std_TransformerError xf Transformer (SomeIpXf, E2EXf) xf->std nutzt Std_MessageTypeType, Std_MessageResultType swc SW-C swc->rte API RTE с Std_ReturnType / transformerError

Контекстная диаграмма: Std_Types.h подключает заголовочные файлы платформы и компилятора и используется BSW-модулями, CDD, RTE и трансформерами в качестве общего базиса типов. Источники: SRS BSWGeneral с. 62, CDD Guideline с. 14, [SWS_Std_00005], [SWS_Std_00021]

Структура Std_Types.h и включение в дерево заголовочных файлов

Для R20-11 требование BSW определяет, что должен обеспечивать Std_Types.h SRS BSWGeneral с. 62:

  • подключать специфичный для платформы заголовочный файл типов Platform_Types.h,
  • подключать специфичный для компилятора заголовочный файл Compiler.h,
  • определять Std_ReturnType,
  • задавать значения для E_OK, E_NOT_OK, STD_ON, STD_OFF, STD_HIGH, STD_LOW, STD_ACTIVE и STD_IDLE.

В более поздней редакции того же требования включение Compiler.h отсутствует RS BSWGeneral с. 60. Это согласуется с историей изменений: в R22-11 устаревшая абстракция компилятора была удалена из требования Std, а NULL_PTR был добавлен только в R21-11 SWS StandardTypes с. 1. Таким образом, для R20-11 Compiler.h входит в цепочку включения (include), тогда как NULL_PTR из Std_Types.h — еще нет.

Одна особенность касается E_OK. Этот символ уже определен в OSEK и поэтому должен использоваться совместно. [SWS_Std_00006] предписывает защиту через STATUSTYPEDEFINED: внутри защиты определяются E_OK (0x00u) и StatusType, а E_NOT_OK (0x01u) находится снаружи. Требование BSW содержит то же примечание к реализации со ссылкой на ISO 17356-3 SRS BSWGeneral с. 62. То, как сложный драйвер устройства (Complex Device Driver) упорядочивает заголовочный файл в своей структуре включения, показано на диаграмме структуры заголовков CDD CDD Guideline с. 14.

Std_ReturnType: диапазон значений, битовая структура и модульные расширения

Std_ReturnType является производным от uint8. Стандартными значениями являются E_OK (0) и E_NOT_OK (1); диапазон 0x02–0x3F доступен для ошибок, определяемых пользователем [SWS_Std_00005]. [SWS_Std_00011] уточняет это правило:

  • Обычно этот тип используется с E_OK или E_NOT_OK.
  • Если этих значений недостаточно, в шести младших битах разрешается определять собственные значения, именуемые с префиксом модуля.
  • Бит 7 и бит 8 зарезервированы. Они, как и вся разметка в целом, определяются спецификацией RTE.

Диаграмма разметки отображает именно такое разделение SWS StandardTypes с. 15.

Спецификация RTE описывает Std_ReturnType как тип для значений состояния и ошибок API-функций; значение 0 зарезервировано для варианта «ошибка не возникла» SWS RTE с. 675. Согласно руководству по моделированию BSW, это единственный возвращаемый тип, разрешённый в клиент-серверных операциях интерфейсов сервисов BSWUML Guide с. 28. Примером специфичного для модуля расширения является CAN_BUSY (0x02) CAN-драйвера. Can_Write() возвращает это значение, если нет свободного объекта передачи SWS CANDriver с. 54.

returntype rt Std_ReturnType (abgeleitet von uint8) ok E_OK = 0x00 (kein Fehler) rt->ok Standardwert nok E_NOT_OK = 0x01 (generischer Fehler) rt->nok Standardwert user 0x02–0x3F модульно-специфичные значения (6 младших битов, префикс модуля) rt->user erweiterbar rtebits Бит 7 и бит 8 зарезервированы, определены спецификацией RTE rt->rtebits reserviert csm Csm_ReturnType «extra_literals» CSM_E_BUSY = 2 CSM_E_SMALL_BUFFER = 3 CSM_E_ENTROPY_EXHAUSTION = 4 csm->rt erbt von csm->user belegt can CAN_BUSY = 0x02 (Can_Write: kein Sendeobjekt frei) can->user belegt

Контекстная диаграмма (структура типов): Std_ReturnType делится на стандартные значения, специфичный для модуля диапазон 0x02–0x3F и два зарезервированных RTE бита; расширения модулей, такие как Csm_ReturnType или CAN_BUSY, занимают только свободный диапазон. Источники: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes с. 15, BSWUML Guide с. 29, SWS CANDriver с. 54

В UML-модели BSW такое расширение моделируется как класс <Ma>_ReturnType со стереотипом «extra_literals». Его значения содержат префикс модуля и находятся в диапазоне 0x02–0x3f BSWUML Guide с. 28. Пример Csm_ReturnType с CSM_E_BUSY, CSM_E_SMALL_BUFFER и CSM_E_ENTROPY_EXHAUSTION демонстрирует шаблон BSWUML Guide с. 29. Если нескольким модулям одного стека требуется одно и то же расширение, его не нужно определять отдельно для каждого модуля BSWUML Guide с. 33. Редакция R23-11 предусматривает для этого общий класс с «generic_type», от которого наследуются специфичные для модуля расширения TR BSWUML Guide с. 37.

erweiterung start Старт: модуль определяет возвращаемые значения q1 Достаточно ли E_OK / E_NOT_OK? start->q1 std Использовать Std_ReturnType с E_OK / E_NOT_OK q1->std да q2 Требуется ли нескольким модулям одного стека одинаковое расширение? q1->q2 нет ende Конец: биты 7/8 остаются зарезервированными для RTE std->ende gen generische Erweiterung «extra_literals» «generic_type» (Fassung R23-11) q2->gen да own <Ma>_ReturnType als Klasse «extra_literals» modellieren q2->own нет derive Создать производный <Ma>_ReturnType, при необходимости добавить собственные литералы gen->derive lit Определить литералы с префиксом модуля в диапазоне 0x02–0x3F derive->lit own->lit lit->ende

Диаграмма деятельности: принятие решения о том, расширяет ли модуль Std_ReturnType собственными значениями и каким образом. Источники: [SWS_Std_00011], BSWUML Guide с. 28, BSWUML Guide с. 33, TR BSWUML Guide с. 37

Символические константы для уровней, переключателей и состояний

Помимо возвращаемых значений, Std_Types.h определяет три пары констант. Все три используют числовые значения 0x01u и 0x00u, но снабжены различными комментариями ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]):

ПараЦенностиЗначение согласно определению
STD_HIGH / STD_LOW0x01u / 0x00uфизическое состояние 5 В или 3,3 В / 0 В
STD_ON / STD_OFF0x01u / 0x00uВкл/Выкл, без дальнейших комментариев
STD_ACTIVE / STD_IDLE0x01u / 0x00uлогическое состояние активный / idle

Типичным пользователем STD_HIGH/STD_LOW является DIO-драйвер: его служба чтения возвращает ровно один из этих двух уровней SWS DIO с. 37. STD_ON/STD_OFF служат переключателями этапа предкомпиляции (pre-compile). Примером является EEP_21_LDEXT_VERSION_INFO_API STD_ON в общей спецификации BSW SWS BSWGeneral с. 76, другим примером служат опциональные API-переключатели GPT-драйвера SWS GPT с. 48.

Запрос версии через Std_VersionInfoType

Std_VersionInfoType представляет собой структуру со следующими элементами: vendorID и moduleID (каждый uint16), а также sw_major_version, sw_minor_version и sw_patch_version (каждый uint8). С помощью <Module name>_GetVersionInfo() запрашивается версия BSW-модуля [SWS_Std_00015]. Общая спецификация BSW определяет для этой функции следующее SWS BSWGeneral с. 76:

  • Она работает синхронно и является реентерабельной.
  • Она имеет ровно один параметр этого типа.
  • Её доступность конфигурируется для каждого модуля во время предкомпиляции (pre-compile) через <Ma>VersionInfoApi.

Правило именования GetVersionInfo приведено в требовании BSW с примером Eep_21_LDExt_GetVersionInfo SRS BSWGeneral с. 60.

Конкретные реализации имеются во многих модулях. Can_GetVersionInfo при активном обнаружении ошибок разработки отклоняет нулевой указатель с CAN_E_PARAM_POINTER SWS CANDriver с. 57. Adc_GetVersionInfo выполняет соответствующую проверку на ADC_E_PARAM_POINTER SWS ADCDriver с. 80. Менеджер NVRAM демонстрирует вызов как простой синхронный обмен между пользователем и модулем SWS NvM с. 158.

Запрос версии с помощью Std_VersionInfoTypeNutzerBSW-Modul <Ma>DetAPI присутствует только если<Ma>VersionInfoApi = STD_ON (Pre-compile)<Ma>_GetVersionInfo(&versioninfo)altversioninfo == NULL и обнаружение ошибок разработки активноEntwicklungsfehler melden(z. B. CAN_E_PARAM_POINTER)действительный указательvendorID, moduleID,sw_major/minor/patch_version eintragenВозврат (void; синхронный, реентерабельный)

Диаграмма последовательности: пользователь синхронно запрашивает версию модуля; при нулевом указателе и активном обнаружении ошибок разработки модуль сообщает об ошибке, иначе он заполняет Std_VersionInfoType. Источники: [SWS_Std_00015], SWS BSWGeneral с. 76, SWS CANDriver с. 57, SWS NvM с. 158

Типы трансформеров и сообщений для преобразования данных

Для цепочек трансформеров std предоставляет несколько типов. Std_TransformerError в R20-11 представляет собой структуру из errorCode (uint8) и transformerClass типа Std_TransformerClass [SWS_Std_00021]. Std_TransformerClass является производным от uint8 и поддерживает пять значений [SWS_Std_00024]: STD_TRANSFORMER_UNSPECIFIED (0x00), STD_TRANSFORMER_SERIALIZER (0x01), STD_TRANSFORMER_SAFETY (0x02), STD_TRANSFORMER_SECURITY (0x03) и STD_TRANSFORMER_CUSTOM (0xFF).

Краткая сигнатура в каталоге API указывает Std_TransformerError как typedef uint8. Однако определяющим является определение структуры в требовании. Более поздние редакции типизируют errorCode как собственный тип Std_TransformerErrorCode, значение которого определяется для каждой цепочки трансформеров SWS StandardTypes с. 17.

RTE передаёт этот тип в качестве опционального OUT-параметра transformerError в свои API, например при Rte_Call SWS RTE с. 731, Rte_Read SWS RTE с. 720 и Rte_Result SWS RTE с. 750. Интерфейсы плагинов описывают его как ошибку, возникшую при выполнении цепочки трансформеров SWS RTE с. 969.

Std_TransformerForward и Std_TransformerForwardCode помечены в R20-11 как черновик (draft). Forward-код содержит E_OK, E_SAFETY_INVALID_REP, E_SAFETY_INVALID_SEQ и E_SAFETY_INVALID_CRC ([SWS_Std_00027], [SWS_Std_00029]). В более поздних редакциях Rte_Send принимает опциональный forwardedCode этого типа SWS RTE с. 704. Предположительно, он служит для повторного отображения полученных ошибок безопасности (Safety) при пересылке, как это описывают функции E2E-Forward SWS E2ELibrary с. 107 (интерпретация). Вопрос Q-f0d374b3b793c868 (открытый) Согласно истории изменений, структура Std_TransformerForward была удалена в R22-11 SWS StandardTypes с. 1.

Сообщить об ошибке трансформера через Std_TransformerErrorSW-CRTETransformer-KettetransformerError существует только приerrorHandling = transformerErrorHandlingRte_Call_<p>_<o>(…, OUT transformerError)Выполнить цепочку трансформеровaltTransformer meldet FehlerFehlercode (Interpretation)Заполнить Std_TransformerError:errorCode, transformerClass (z. B. STD_TRANSFORMER_SAFETY)Std_ReturnType + transformerErrorkein Transformer-FehlerРезультат без ошибокStd_ReturnType (z. B. E_OK)

Диаграмма последовательности: ошибка трансформера поступает в SW-C наряду с Std_ReturnType как Std_TransformerError с кодом ошибки и классом трансформера. Источники: [SWS_Std_00021], [SWS_Std_00024], SWS RTE с. 731, SwCluster Guideline с. 245, SWS RTE с. 774

Для клиент-серверной коммуникации существуют два типа кодирования, в которых диапазон 0x02–0x3F в каждом случае зарезервирован для будущих значений:

  • Std_MessageTypeType различает запрос (STD_MESSAGETYPE_REQUEST, 0x00) и ответ (STD_MESSAGETYPE_RESPONSE, 0x01) ([SWS_Std_91001], [SWS_Std_00017]).
  • Std_MessageResultType кодирует результат ответа: STD_MESSAGERESULT_OK (0x00) или STD_MESSAGERESULT_ERROR (0x01) ([SWS_Std_91002], [SWS_Std_00019]).

Тип указателя на функцию Std_ExtractProtocolHeaderFieldsType описывает синхронную реентерабельную функцию. Она извлекает оба значения из заголовка протокола трансформера в буфере и возвращает Std_ReturnType [SWS_Std_91003]. Трансформеры опционально получают такой указатель в качестве аргумента своей обратной функции ASWS TransformerGeneral с. 40. SOME/IP-трансформер предоставляет подходящую реализацию с помощью SomeIpXf_ExtractProtocolHeaderFields SWS SOMEIPTransformer с. 61. Профили E2E 4m, 7m, 8m и 44m анализируют эти два значения в своих функциях проверки SWS E2ELibrary с. 108.

Protokoll-Header-Felder extrahieren (E2E, Profil PXXm)RTEE2EXf (inverse Funktion)SomeIpXfE2E-BibliothekE2EXf_Inv_<transformerId>(extractProtocolHeaderFields,buffer, bufferLength, …)optProfile == PXXmextractProtocolHeaderFields(buffer, bufferLength,&messageType, &messageResult)= SomeIpXf_ExtractProtocolHeaderFields (Beispiel)Std_ReturnType ok,Std_MessageTypeType, Std_MessageResultTypealtok == E_OKsourceID = config->sourceIDE2E_P04mSourceCheck(…, SourceID,MessageType, MessageResult, …) (Beispiel)Std_ReturnTypeok == E_NOT_OK (z. B. falsche Protokollversion, Puffer zu kurz)Прервать обработку с завершением по ошибкеuint8 (результат обратного преобразования)

Диаграмма последовательности: E2E-трансформер извлекает тип и результат сообщения для профилей PXXm через переданный указатель на функцию и продолжает проверку только при E_OK. Источники: [SWS_Std_91003], ASWS TransformerGeneral с. 40, SWS E2ETransformer с. 45, SWS SOMEIPTransformer с. 61, SWS E2ELibrary с. 108

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

Сам модуль не обнаруживает ошибок и не сообщает о них. Редакция, начиная с R23-11, констатирует, что стандартные типы не предусматривают обработки ошибок и не поддерживают событий безопасности (Security) SWS StandardTypes с. 27; для R20-11, вероятно, справедливо то же самое (интерпретация). Вопрос (открытый) Поэтому поведение при ошибках формируется только в тех модулях, которые используют эти типы. Базовым сигналом является E_NOT_OK [SWS_Std_00006]; его конкретное значение определяется соответствующим API. Для Adc_ReadGroup это означает «нет доступных результатов или ошибка разработки» SWS ADCDriver с. 61, для CanIf_Transmit — «запрос на отправку не принят» SWS CANInterface с. 87.

Более детальные картины ошибок передаются через специфичные для модуля значения в диапазоне 0x02–0x3F [SWS_Std_00011], например CAN_BUSY SWS CANDriver с. 54. Таким образом, вызывающие компоненты должны учитывать, что Std_ReturnType может принимать более двух значений. Особым случаем являются обратные вызовы (callbacks), маршрутизируемые через RTE как сервисы AUTOSAR: хотя вызывающая сторона может предполагать E_OK, такие обратные вызовы могут завершаться сбоем, например, в секционированных системах SWS BSWGeneral с. 69.

В цепочках трансформеров ошибка, помимо возвращаемого значения, сообщается через Std_TransformerError с кодом ошибки и классом трансформера [SWS_Std_00021]. RTE генерирует опциональный параметр transformerError только тогда, когда для порта настроена обработка ошибок transformerErrorHandling SWS RTE с. 774. Если извлечение полей заголовка завершается неудачей, SomeIpXf_ExtractProtocolHeaderFields возвращает E_NOT_OK, например при неверной версии протокола или слишком коротком буфере SWS SOMEIPTransformer с. 61. Логика E2E-трансформера продолжает проверку только при E_OK SWS E2ETransformer с. 45.

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

Сгенерированное ИИ руководство по модулю для std (classic, R20-11), созданное исключительно на основе полезной нагрузки (payload) autodocs. Многие места в документе взяты из других релизов; нормативными являются требования R20-11. Сверить со спецификацией перед обязательным применением.

Standard Types (Std_Types)

Standard types, return codes (Std_ReturnType, E_OK, E_NOT_OK), version info structures, and error codes shared across the entire AUTOSAR architecture.

Typen — Übersicht

Typen — Detailansicht

тип Std_ReturnType [SWS_Std_00005] 📄 PDF

typedef uint8 Std_ReturnType;

This type can be used as standard API return type which is shared between the RTE and the BSW modules. It shall be defined as follows: typedef uint8 Std_ Return Type;

СОЗДАНО ИИ не проверено Модель: gemini-3.8-flash-medium · Усилие: medium · Температура: не регулируется · Промпт: 6f8f9add55f9 Происхождение Открытые вопросы (1)
переведено с немецкого руководстваgemini-3.8-flash-low · 2026-10-13 · Немецкий оригинал

Тип Std_ReturnType служит стандартизированным типом возвращаемого значения для API-функций и совместно используется RTE и BSW-модулями ([SWS_Std_00005]). Он доступен через заголовочный файл Std_Types.h и определен как uint8 ([SWS_Std_00005]).

По умолчанию Std_ReturnType принимает значения E_OK (значение 0) или E_NOT_OK (значение 1) ([SWS_Std_00005], [SWS_Std_00011]). Если этих двух стандартных возвращаемых значений недостаточно, стандарт допускает определение специфических для модуля значений ошибок:

  • Диапазон значений для пользовательских ошибок: для пользовательских кодов ошибок доступен диапазон от 0x02 до 0x3F ([SWS_Std_00005]). При этом используются шесть младших значащих битов ([SWS_Std_00011]).
  • Соглашение об именовании: при именовании специфических пользовательских значений ошибок в соответствии с предписаниями BSW в обязательном порядке должен предшествовать префикс соответствующего модуля ([SWS_Std_00011]).
  • Резервирование RTE: бит 7 и бит 8 зарезервированы и задаются спецификацией RTE, которой также следует общая компоновка типа возвращаемого значения ([SWS_Std_00011]). Интерпретация: вероятно, речь идет о двух старших значащих битах 8-битного представления, которые дополняют шесть младших битов до одного байта. Вопрос Q-d97256956c510f58 (открытый)

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

Это указание по использованию было создано ИИ и основано на спецификациях AUTOSAR Classic релиза R20-11.

Руководство разработчика реализации в подготовке (сложность I1)

тип Std_TransformerError [SWS_Std_00021] 📄 PDF

typedef uint8 Std_TransformerError;

-

СОЗДАНО ИИ не проверено Модель: gemini-3.8-flash-medium · Усилие: medium · Температура: не регулируется · Промпт: 534a10ed1c56 Происхождение Открытые вопросы (2)
переведено с немецкого руководстваgemini-3.8-flash-low · 2026-10-13 · Немецкий оригинал

Тип данных Std_TransformerError согласно требованию [SWS_Std_00021] предоставляется в качестве стандартизированного типа через заголовочный файл Std_Types.h для платформы AUTOSAR Classic. Структурно данный элемент определен в спецификации как структура (Structure) и состоит из двух компонентов: элемента errorCode с базовым типом uint8, а также элемента transformerClass с типом Std_TransformerClass [SWS_Std_00021].

Относительно практического применения спецификация не содержит конкретных сигнатур функций, описаний параметров или возвращаемых значений. Структурный тип, вероятно, служит единым контейнером данных для структурированной передачи ошибок, возникающих при трансформации данных (интерпретация). Вопрос Q-6e0938f276d60fd3 (открытый) При этом поле errorCode, вероятно, передает собственно числовой код ошибки, тогда как transformerClass идентифицирует вызвавший или назначенный класс трансформера (интерпретация). Вопрос Q-d8806698683ec00e (открытый)

Специфические механизмы обработки ошибок, такие как сообщения DET или DEM, в [SWS_Std_00021] не определены. Требования к параллелизму, реентерабельности или синхронной либо асинхронной семантике также отсутствуют в исходных материалах. Поскольку речь идет о чистом определении типа в Std_Types.h, сам тип не подлежит ограничениям времени выполнения; они вытекают исключительно из соответствующего контекста использующих его модулей.

Этот текст был сгенерирован ИИ на основе спецификации AUTOSAR R20-11.

тип Std_MessageType [SWS_Std_91001] 📄 PDF

This type is used to encode the different type of messages. - Currently this encoding is limited to the distinction between requests and responses in C/ S c ommunication.

СОЗДАНО ИИ не проверено Модель: gemini-3.8-flash-medium · Усилие: medium · Температура: не регулируется · Промпт: 3a61d74dd0cf Происхождение
переведено с немецкого руководстваgemini-3.8-flash-low · 2026-10-13 · Немецкий оригинал

Стандартный тип Std_MessageType согласно [SWS_Std_91001] используется для кодирования различных типов сообщений. В настоящей спецификации это кодирование ограничивается различением запросов (Requests) и ответов (Responses) в рамках коммуникации клиент/сервер ([SWS_Std_91001]).

Тип данных порожден от базового типа uint8 и предоставляется программным компонентам, а также модулям Basic Software через заголовочный файл Std_Types.h ([SWS_Std_91001]). Для присвоения и вычисления специфицированы следующие значения и константы:

  • STD_MESSAGETYPE_REQUEST (значение 0x00): обозначает сообщение-запрос ([SWS_Std_91001]).
  • STD_MESSAGETYPE_RESPONSE (значение 0x01): обозначает сообщение-ответ ([SWS_Std_91001]).
  • Диапазон значений от 0x02 до 0x3F: этот диапазон зарезервирован для будущих типов сообщений ([SWS_Std_91001]).

В отношении применения и граничных условий действует правило, согласно которому реализующие модули должны использовать исключительно определенные идентификаторы. Поскольку значения от 0x02 до 0x3F зарезервированы для будущих расширений AUTOSAR, их запрещено самовольно занимать для других целей ([SWS_Std_91001]). Специфические коды ошибок, возвращаемые значения, асинхронные процессы или сообщения в DET или DEM для этого типа данных в спецификации не определены ([SWS_Std_91001]).

Этот текст был сгенерирован ассистентом курации ИИ и основан на спецификации AUTOSAR R20-11.

тип Std_MessageResultType [SWS_Std_91002] 📄 PDF

typedef uint8 Std_MessageResultType;

This type is used to encode different types of results for response messages. - Currently this encoding is limited to the distinction between OK and ERROR responses.

СОЗДАНО ИИ не проверено Модель: gemini-3.8-flash-medium · Усилие: medium · Температура: не регулируется · Промпт: 48b18d78d865 Происхождение Открытые вопросы (1)
переведено с немецкого руководстваgemini-3.8-flash-low · 2026-10-13 · Немецкий оригинал

Фундаментальный тип данных Std_MessageResultType служит в AUTOSAR Classic Platform для кодирования различных типов результатов для ответных сообщений (Response Messages) [SWS_Std_00019]. Тип предоставляется через стандартный заголовочный файл Std_Types.h и определен как скалярный тип на основе uint8 [SWS_Std_91002].

Использование и диапазон значений

Спецификация требует использования Std_MessageResultType для единообразного обозначения ответных сообщений [SWS_Std_00019]. В настоящее время предусмотренный функциональный объем этого кодирования ограничен базовым разграничением успешных и ошибочных ответов [SWS_Std_91002]. Для этого определены следующие фиксированные значения результатов:

  • STD_MESSAGERESULT_OK (значение 0x00): обозначает штатный, безошибочный результат ответного сообщения [SWS_Std_91002].
  • STD_MESSAGERESULT_ERROR (значение 0x01): сигнализирует о результате ошибочного ответного сообщения (Error Response) [SWS_Std_91002].

Ограничения и будущие расширения

Диапазон значений от 0x02 до 0x3F явно зарезервирован для будущих результатов сообщений [SWS_Std_91002]. Интерпретация: поскольку спецификация в настоящее время не предусматривает иных допустимых возвращаемых значений, анализирующие модули, по-видимому, должны быть запрограммированы защитно, чтобы надежно перехватывать неожиданные или еще не занятые значения в этом диапазоне [SWS_Std_00019]. Вопрос Q-5f652f73800b7d94 (открытый)

Данный текст создан с помощью ИИ и обобщает положения спецификации AUTOSAR для разработчиков.

тип Std_ExtractProtocolHeaderFieldsType [SWS_Std_91003] 📄 PDF

typedef Std_ReturnType (* Std_ExtractProtocolHeaderFieldsType)(const uint8* buffer, uint32 bufferLength, Std_MessageTypeType* messageType, Std_MessageResultType* messageResult);

Type for the function pointer to extract the relevant protocol header fields of the message and the type of the message result of a transformer. - At the time being, this is limited to the types used for C/ S communication (i.e., REQUE ST and RESPONSE and OK and ERROR).

тип E_OK / E_NOT_OK [SWS_Std_00006] 📄 PDF

#define E_OK 0x00u #define E_NOT_OK 0x01u

Because E_ OK is already defined within OSEK, the symbol E_ OK has to be shared. To avoid name clashes and redefinition problems, the symbols have to be defined in the following way (approved within implementation): #ifndef STATUSTYPEDEFINED #define STATUSTYPEDEFINED #define E_ OK 0x00u typedef unsigned char Status Type; /* OSEK compliance */ #endif #define E_ NOT_ OK 0x01u

тип STD_HIGH / STD_LOW [SWS_Std_00007] 📄 PDF

#define STD_HIGH 0x01u #define STD_LOW 0x00u

The symbols STD_ HIGH and STD_ LOW shall be defined as follows: #define STD_ HIGH 0x01u /* Physical state 5V or 3.3V */ #define STD_ LOW 0x00u /* Physical state 0V */

тип STD_ACTIVE / STD_IDLE [SWS_Std_00013] 📄 PDF

#define STD_ACTIVE 0x01u #define STD_IDLE 0x00u

The symbols STD_ ACTIVE and STD_ IDLE shall be defined as follows: #define STD_ ACTIVE 0x01u /* Logical state active */ #define STD_ IDLE 0x00u /* Logical state idle */

тип STD_ON / STD_OFF [SWS_Std_00010] 📄 PDF

#define STD_ON 0x01u #define STD_OFF 0x00u

The symbols STD_ ON and STD_ OFF shall be defined as follows: #define STD_ ON 0x01u #define STD_ OFF 0x00u

Request a governed re-review of this record. The record is not changed immediately.

Record
AUTOSAR/AP/record/CP_MOD_Std
Status
unspecified
Version
AUTOSAR/AP/record/CP_MOD_Std@rel:R20-11#cd48a40b
Content hash
cd48a40b
Source
https://www.autosar.org/fileadmin/standards/R20-11/CP/AUTOSAR_SWS_StandardTypes.pdf#nameddest=SWS_Std_00005

Карта тем

Типы

13
E_OK / E_NOT_OKSTD_ACTIVE / STD_IDLEStd_ExtractProtocolHeaderFieldsTypeSTD_HIGH / STD_LOWStd_MessageResultTypeStd_MessageTypeSTD_ON / STD_OFFStd_ReturnTypeStd_TransformerClassStd_TransformerErrorStd_TransformerForwardStd_TransformerForwardCodeStd_VersionInfoType

Подробный вид

Выберите элемент в оглавлении.

Типы

E_OK / E_NOT_OK тип

Because E_ OK is already defined within OSEK, the symbol E_ OK has to be shared. To avoid name clashes and redefinition problems, the symbols have to be defined in the following way (approved within implementation): #ifndef STATUSTYPEDEFINED #define STATUSTYPEDEFINED #define E_ OK 0x00u typedef unsigned char Status Type; /* OSEK compliance */ #endif #define E_ NOT_ OK 0x01u

#define E_OK 0x00u #define E_NOT_OK 0x01u
STD_ACTIVE / STD_IDLE тип

The symbols STD_ ACTIVE and STD_ IDLE shall be defined as follows: #define STD_ ACTIVE 0x01u /* Logical state active */ #define STD_ IDLE 0x00u /* Logical state idle */

#define STD_ACTIVE 0x01u #define STD_IDLE 0x00u
Std_ExtractProtocolHeaderFieldsType тип

Type for the function pointer to extract the relevant protocol header fields of the message and the type of the message result of a transformer. - At the time being, this is limited to the types used for C/ S communication (i.e., REQUE ST and RESPONSE and OK and ERROR).

typedef Std_ReturnType (* Std_ExtractProtocolHeaderFieldsType)(const uint8* buffer, uint32 bufferLength, Std_MessageTypeType* messageType, Std_MessageResultType* messageResult);
STD_HIGH / STD_LOW тип

The symbols STD_ HIGH and STD_ LOW shall be defined as follows: #define STD_ HIGH 0x01u /* Physical state 5V or 3.3V */ #define STD_ LOW 0x00u /* Physical state 0V */

#define STD_HIGH 0x01u #define STD_LOW 0x00u
Std_MessageResultType тип

This type is used to encode different types of results for response messages. - Currently this encoding is limited to the distinction between OK and ERROR responses.

typedef uint8 Std_MessageResultType;
Std_MessageType тип

This type is used to encode the different type of messages. - Currently this encoding is limited to the distinction between requests and responses in C/ S c ommunication.

STD_ON / STD_OFF тип

The symbols STD_ ON and STD_ OFF shall be defined as follows: #define STD_ ON 0x01u #define STD_ OFF 0x00u

#define STD_ON 0x01u #define STD_OFF 0x00u
Std_ReturnType тип

This type can be used as standard API return type which is shared between the RTE and the BSW modules. It shall be defined as follows: typedef uint8 Std_ Return Type;

typedef uint8 Std_ReturnType;
Std_TransformerForward тип

- Tags: atp.Status=draft

typedef uint8 Std_TransformerForward;
Std_TransformerForwardCode тип

- Tags: atp.Status=draft

typedef uint8 Std_TransformerForwardCode;
Std_VersionInfoType тип

This type shall be used to request the version of a BSW module using the _ Get Version Info() function.

typedef struct { uint16 vendorID; uint16 moduleID; uint8 sw_major_version; uint8 sw_minor_version; uint8 sw_patch_version; } Std_VersionInfoType;