Standard Types (Std_Types)

El módulo std proporciona a través de Std_Types.h tipos y constantes homogéneos en toda la plataforma, pero no contiene código ni configuración. El elemento central es Std_ReturnType (uint8) con E_OK y E_NOT_OK. Los módulos solo pueden definir valores propios en el rango 0x02–0x3F con prefijo de módulo, ya que los bits 7 y 8 están reservados para la RTE [SWS_Std_00011]. Además, el módulo suministra las constantes STD_HIGH/STD_LOW, STD_ON/STD_OFF y STD_ACTIVE/STD_IDLE, el tipo Std_VersionInfoType para la consulta de versiones, así como tipos de transformador y de mensaje para la comunicación cliente-servidor. En R20-11, el encabezado incluye además Compiler.h SRS BSWGeneral p. 62.

más ›

El módulo std es un encabezado exclusivo de tipos. A través de Std_Types.h proporciona tipos y símbolos, pero ninguna función [SWS_Std_00005]. En R20-11, el encabezado incluye Platform_Types.h y Compiler.h, y define Std_ReturnType así como los valores E_OK/E_NOT_OK y las constantes STD_*. Cada módulo que utiliza estos tipos lo incluye SRS BSWGeneral p. 62. Según una versión posterior de la especificación, no existen configuración ni tratamiento de errores propio; para R20-11 se asume lo mismo (interpretación) SWS StandardTypes p. 27. Pregunta (abierta)

Diagrama de contexto: Std_Types.h como base común de tipos para módulos BSW, CDD, RTE y transformadores. Fuentes: SRS BSWGeneral p. 62, CDD Guideline p. 14

El núcleo del módulo es Std_ReturnType (uint8) con los valores E_OK (0) y E_NOT_OK (1). El rango 0x02–0x3F está previsto para errores específicos de módulo con prefijo de módulo; la especificación de la RTE determina los bits 7 y 8 [SWS_Std_00011]. Ejemplos de tales extensiones son CAN_BUSY y Csm_ReturnType BSWUML Guide p. 29. Debido a OSEK, E_OK se protege mediante STATUSTYPEDEFINED [SWS_Std_00006].

Diagrama de contexto (estructura de tipos): valores estándar, rango específico de módulo y bits reservados por la RTE de Std_ReturnType. Fuentes: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes p. 15

A esto se añaden tres pares de constantes con 0x01u/0x00u en cada caso: STD_HIGH/STD_LOW para niveles físicos, STD_ON/STD_OFF como conmutadores y STD_ACTIVE/STD_IDLE para estados lógicos ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]). Std_VersionInfoType transporta el ID de fabricante, el ID de módulo y la versión de software para la función síncrona y reentrante <Ma>_GetVersionInfo [SWS_Std_00015].

Para la transformación de datos, std define dos tipos para errores de transformador: Std_TransformerError, una estructura formada por código de error y clase de transformador, y Std_TransformerClass [SWS_Std_00021]. La RTE transmite este error a través del parámetro opcional transformerError SWS RTE p. 731. Para la comunicación cliente-servidor, Std_MessageTypeType y Std_MessageResultType codifican solicitud/respuesta y OK/ERROR. Un puntero a función del tipo Std_ExtractProtocolHeaderFieldsType lee ambos valores de un encabezado de transformador [SWS_Std_91003]. En R20-11, los tipos forward todavía son borradores (draft) [SWS_Std_00029].

más ›

Rol y límite del sistema: un encabezado exclusivo de tipos sin comportamiento en tiempo de ejecución

El módulo std (Standard Types) no contiene funciones. Proporciona exclusivamente tipos y símbolos disponibles a través de Std_Types.h. Cada requisito del módulo cita este encabezado como fuente de referencia, como por ejemplo [SWS_Std_00005] y [SWS_Std_00015]. La especificación establece expresamente: el encabezado no proporciona código ni requiere otros módulos BSW, no tiene configuración ni tratamiento de errores propio SWS StandardTypes p. 27. Estas formulaciones proceden de la versión a partir de R23-11. Para R20-11 se aplicaría lo mismo, ya que los requisitos de R20-11 solo contienen definiciones de tipos y símbolos (interpretación). Pregunta Q-8e4c66ae80752d38 (abierta)

El propósito es un acceso homogéneo a los tipos estándar en toda la plataforma. Por ello, el requisito de BSW para el encabezado de tipos estándar exige: cada módulo que utilice tipos enteros de AUTOSAR o el tipo de retorno estándar incluye Std_Types.h SRS BSWGeneral p. 62. El tipo de retorno Std_ReturnType se comparte expresamente entre la RTE y los módulos BSW [SWS_Std_00005]. En la metodología, los tipos estándar se describen adicionalmente como el artefacto ARXML «AUTOSAR Standard Types» Methodology p. 400.

Diagrama de contexto: Std_Types.h incluye los encabezados de plataforma y de compilador, y es utilizado por módulos BSW, CDD, RTE y transformadores como base de tipos común. Fuentes: SRS BSWGeneral p. 62, CDD Guideline p. 14, [SWS_Std_00005], [SWS_Std_00021]

Estructura de Std_Types.h e integración en el árbol de encabezados

Para R20-11, el requisito de BSW determina lo que debe ofrecer Std_Types.h SRS BSWGeneral p. 62:

• incluir el encabezado de tipos específico de la plataforma Platform_Types.h,
• incluir el encabezado específico del compilador Compiler.h,
• definir Std_ReturnType,
• establecer valores para E_OK, E_NOT_OK, STD_ON, STD_OFF, STD_HIGH, STD_LOW, STD_ACTIVE y STD_IDLE.

En la versión posterior del mismo requisito falta la inclusión de Compiler.h RS BSWGeneral p. 60. Esto coincide con el historial de cambios: en R22-11 se eliminó la abstracción de compilador obsoleta de un requisito Std, y NULL_PTR no se añadió hasta R21-11 SWS StandardTypes p. 1. Por lo tanto, para R20-11, Compiler.h forma parte de la cadena de inclusión, mientras que un NULL_PTR de Std_Types.h todavía no.

Una particularidad afecta a E_OK. El símbolo ya está definido en OSEK y, por tanto, debe utilizarse de forma compartida. [SWS_Std_00006] prescribe una protección mediante STATUSTYPEDEFINED: dentro de la protección se definen E_OK (0x00u) y StatusType; E_NOT_OK (0x01u) queda fuera. El requisito de BSW contiene la misma nota de implementación con referencia a ISO 17356-3 SRS BSWGeneral p. 62. El diagrama sobre la estructura de encabezados de CDD muestra cómo un Complex Device Driver organiza el encabezado en su estructura de inclusión CDD Guideline p. 14.

Std_ReturnType: rango de valores, disposición de bits y extensiones específicas de módulo

Std_ReturnType se deriva de uint8. Los valores estándar son E_OK (0) y E_NOT_OK (1); el rango 0x02–0x3F está disponible para errores específicos del usuario [SWS_Std_00005]. [SWS_Std_00011] precisa esta regla:

• Normalmente, el tipo se utiliza con E_OK o E_NOT_OK.
• Si estos valores no son suficientes, se pueden definir valores propios en los seis bits de menor peso, nombrados con el prefijo de módulo.
• Los bits 7 y 8 están reservados. Se definen, al igual que el diseño (layout) global, en la especificación de la RTE.

El diagrama de la disposición representa exactamente esta división SWS StandardTypes p. 15.

La especificación de la RTE describe Std_ReturnType como tipo para valores de estado y error de funciones de API; el valor 0 está reservado para «no se ha producido ningún error» SWS RTE p. 675. Según la guía de modelado de BSW, es el único tipo de retorno permitido en operaciones cliente-servidor de Service Interfaces BSWUML Guide p. 28. Un ejemplo de extensión específica de módulo es CAN_BUSY (0x02) del controlador CAN. Can_Write() devuelve este valor cuando no hay ningún objeto de transmisión libre SWS CANDriver p. 54.

Diagrama de contexto (estructura de tipos): Std_ReturnType se divide en valores estándar, un rango específico de módulo de 0x02–0x3F y dos bits reservados por la RTE; las extensiones de módulo como Csm_ReturnType o CAN_BUSY ocupan únicamente el rango libre. Fuentes: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes p. 15, BSWUML Guide p. 29, SWS CANDriver p. 54

En el modelo UML de la BSW, dicha extensión se modela como una clase <Ma>_ReturnType con el estereotipo «extra_literals». Sus valores llevan el prefijo de módulo y se sitúan en el rango 0x02–0x3f BSWUML Guide p. 28. El ejemplo Csm_ReturnType con CSM_E_BUSY, CSM_E_SMALL_BUFFER y CSM_E_ENTROPY_EXHAUSTION ilustra este patrón BSWUML Guide p. 29. Si varios módulos de una pila requieren la misma extensión, no es necesario definirla por separado para cada módulo BSWUML Guide p. 33. La versión R23-11 prevé para ello una clase genérica con «generic_type», de la cual se derivan las extensiones específicas de módulo TR BSWUML Guide p. 37.

Diagrama de actividades: decisión sobre si un módulo amplía Std_ReturnType con valores propios y cómo lo hace. Fuentes: [SWS_Std_00011], BSWUML Guide p. 28, BSWUML Guide p. 33, TR BSWUML Guide p. 37

Constantes simbólicas para niveles, conmutadores y estados

Junto a los valores de retorno, Std_Types.h define tres pares de constantes. Los tres utilizan los valores numéricos 0x01u y 0x00u, pero están comentados de forma diferente ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]):

Par	Valores	Significado según la definición
STD_HIGH / STD_LOW	0x01u / 0x00u	estado físico 5 V o 3,3 V / 0 V
STD_ON / STD_OFF	0x01u / 0x00u	Encendido/Apagado, sin más comentarios
STD_ACTIVE / STD_IDLE	0x01u / 0x00u	estado lógico activo / inactivo

Un usuario típico de STD_HIGH/STD_LOW es el controlador DIO: su servicio de lectura devuelve exactamente uno de estos dos niveles SWS DIO p. 37. STD_ON/STD_OFF sirven como conmutadores de tiempo de precompilación. Un ejemplo es EEP_21_LDEXT_VERSION_INFO_API STD_ON en la especificación general de BSW SWS BSWGeneral p. 76, otro son los conmutadores opcionales de API del controlador GPT SWS GPT p. 48.

Consulta de versión mediante Std_VersionInfoType

Std_VersionInfoType es una estructura con los siguientes elementos: vendorID y moduleID (cada uno uint16), así como sw_major_version, sw_minor_version y sw_patch_version (cada uno uint8). Mediante <Module name>_GetVersionInfo() se consulta con ella la versión de un módulo BSW [SWS_Std_00015]. La especificación general de BSW establece para esta función SWS BSWGeneral p. 76:

• opera de forma síncrona y es reentrante;
• tiene exactamente un parámetro de este tipo;
• su disponibilidad se configura por módulo en tiempo de precompilación mediante <Ma>VersionInfoApi.

La regla de nomenclatura GetVersionInfo se cita en el requisito de BSW con el ejemplo Eep_21_LDExt_GetVersionInfo SRS BSWGeneral p. 60.

Existen implementaciones concretas en muchos módulos. Can_GetVersionInfo rechaza un puntero nulo con CAN_E_PARAM_POINTER si la detección de errores de desarrollo está activada SWS CANDriver p. 57. Adc_GetVersionInfo comprueba correspondientemente ADC_E_PARAM_POINTER SWS ADCDriver p. 80. El administrador de NVRAM muestra la llamada como un intercambio síncrono simple entre el usuario y el módulo SWS NvM p. 158.

Diagrama de secuencia: un usuario consulta la versión de un módulo de forma síncrona; en caso de puntero nulo y detección de errores de desarrollo activa, el módulo notifica un error; en caso contrario, completa Std_VersionInfoType. Fuentes: [SWS_Std_00015], SWS BSWGeneral p. 76, SWS CANDriver p. 57, SWS NvM p. 158

Tipos de transformador y de mensaje para la transformación de datos

Para cadenas de transformadores, std proporciona varios tipos. En R20-11, Std_TransformerError es una estructura compuesta por errorCode (uint8) y transformerClass de tipo Std_TransformerClass [SWS_Std_00021]. Std_TransformerClass deriva de uint8 y cuenta con cinco valores [SWS_Std_00024]: STD_TRANSFORMER_UNSPECIFIED (0x00), STD_TRANSFORMER_SERIALIZER (0x01), STD_TRANSFORMER_SAFETY (0x02), STD_TRANSFORMER_SECURITY (0x03) y STD_TRANSFORMER_CUSTOM (0xFF).

La signatura abreviada en el directorio de API incluye Std_TransformerError como typedef uint8. No obstante, la definición determinante es la estructura del requisito. Versiones posteriores tipifican errorCode como un tipo propio Std_TransformerErrorCode, cuyo significado se determina para cada cadena de transformadores SWS StandardTypes p. 17.

La RTE pasa este tipo como parámetro de salida opcional (OUT) transformerError a sus API, como por ejemplo en Rte_Call SWS RTE p. 731, Rte_Read SWS RTE p. 720 y Rte_Result SWS RTE p. 750. Las interfaces de complementos (plug-in) lo describen como el error ocurrido durante la ejecución de la cadena de transformadores SWS RTE p. 969.

Std_TransformerForward y Std_TransformerForwardCode están marcados como borrador (draft) en R20-11. El código de reenvío (forward) reconoce E_OK, E_SAFETY_INVALID_REP, E_SAFETY_INVALID_SEQ y E_SAFETY_INVALID_CRC ([SWS_Std_00027], [SWS_Std_00029]). En versiones posteriores, Rte_Send recibe un forwardedCode opcional de este tipo SWS RTE p. 704. Probablemente sirva para volver a mapear errores de seguridad funcional (Safety) recibidos al reenviarlos, tal como describen las funciones forward de E2E SWS E2ELibrary p. 107 (interpretación). Según el historial de cambios, la estructura Std_TransformerForward se eliminó en R22-11 SWS StandardTypes p. 1. Pregunta Q-f0d374b3b793c868 (abierta)

Diagrama de secuencia: un error de transformador llega a la SW-C junto con Std_ReturnType como Std_TransformerError con código de error y clase de transformador. Fuentes: [SWS_Std_00021], [SWS_Std_00024], SWS RTE p. 731, SwCluster Guideline p. 245, SWS RTE p. 774

Para la comunicación cliente-servidor existen dos tipos de codificación en los que 0x02–0x3F están reservados respectivamente para valores futuros:

• Std_MessageTypeType distingue solicitud (STD_MESSAGETYPE_REQUEST, 0x00) y respuesta (STD_MESSAGETYPE_RESPONSE, 0x01) ([SWS_Std_91001], [SWS_Std_00017]).
• Std_MessageResultType codifica el resultado de una respuesta: STD_MESSAGERESULT_OK (0x00) o STD_MESSAGERESULT_ERROR (0x01) ([SWS_Std_91002], [SWS_Std_00019]).

El tipo de puntero a función Std_ExtractProtocolHeaderFieldsType describe una función síncrona y reentrante. Esta extrae ambos valores del encabezado de protocolo de un transformador en un búfer y devuelve un Std_ReturnType [SWS_Std_91003]. Los transformadores reciben opcionalmente dicho puntero como argumento de su función inversa ASWS TransformerGeneral p. 40. El transformador SOME/IP proporciona una implementación adecuada con SomeIpXf_ExtractProtocolHeaderFields SWS SOMEIPTransformer p. 61. Los perfiles E2E 4m, 7m, 8m y 44m evalúan ambos valores en sus funciones de comprobación SWS E2ELibrary p. 108.

Diagrama de secuencia: para los perfiles PXXm, el transformador E2E extrae el tipo y el resultado del mensaje mediante el puntero a función transmitido y solo continúa la comprobación si se cumple E_OK. Fuentes: [SWS_Std_91003], ASWS TransformerGeneral p. 40, SWS E2ETransformer p. 45, SWS SOMEIPTransformer p. 61, SWS E2ELibrary p. 108

Comportamiento en caso de error

El módulo en sí no detecta ni notifica errores. La versión a partir de R23-11 constata que los tipos estándar no prevén ningún tratamiento de errores ni admiten eventos de seguridad (Security) SWS StandardTypes p. 27; para R20-11 se asume lo mismo (interpretación). Pregunta (abierta) Por tanto, el comportamiento de error solo se origina en los módulos que utilizan los tipos. La señal básica es E_NOT_OK [SWS_Std_00006]; su significado concreto lo define la API correspondiente. En Adc_ReadGroup significa «no hay resultados disponibles o error de desarrollo» SWS ADCDriver p. 61, en CanIf_Transmit «solicitud de transmisión no aceptada» SWS CANInterface p. 87.

Los patrones de error más específicos se notifican mediante valores específicos de módulo en el rango 0x02–0x3F [SWS_Std_00011], por ejemplo CAN_BUSY SWS CANDriver p. 54. Por tanto, los llamantes deben contar con que un Std_ReturnType adopte más de dos valores. Un caso especial son las retrollamadas (callbacks) enrutadas como servicios AUTOSAR a través de la RTE: aunque el llamante puede asumir E_OK, dichas retrollamadas pueden fallar, por ejemplo, en sistemas particionados SWS BSWGeneral p. 69.

En las cadenas de transformadores, además del valor de retorno, se notifica un error mediante Std_TransformerError con el código de error y la clase de transformador [SWS_Std_00021]. La RTE solo genera el parámetro opcional transformerError si se ha configurado el tratamiento de errores transformerErrorHandling para el puerto SWS RTE p. 774. Si la extracción de los campos del encabezado falla, SomeIpXf_ExtractProtocolHeaderFields devuelve E_NOT_OK, por ejemplo en caso de una versión de protocolo incorrecta o un búfer demasiado corto SWS SOMEIPTransformer p. 61. La lógica del transformador E2E solo continúa la comprobación con E_OK SWS E2ETransformer p. 45.

Más evidencia detallada

• [SWS_Std_00005], [SWS_Std_00006], [SWS_Std_00011]: tipo de retorno, valores estándar con protección OSEK, diseño de bits y regla de ampliación.
• [SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]: los tres pares de constantes para niveles físicos, conmutadores y estados lógicos.
• [SWS_Std_00015] junto con SWS BSWGeneral p. 76: estructura de versión y reglas para GetVersionInfo.
• [SWS_Std_00021], [SWS_Std_00024], [SWS_Std_00027], [SWS_Std_00029]: tipos de error de transformador y de reenvío (forward); los dos últimos son borradores (draft).
• [SWS_Std_91001], [SWS_Std_91002], [SWS_Std_91003], [SWS_Std_00017], [SWS_Std_00019]: tipos de mensajes y extracción de cabecera para comunicación C/S.
• SRS BSWGeneral p. 62: contenido y cadena de inclusión de Std_Types.h en R20-11.
• SWS StandardTypes p. 27 y SWS StandardTypes p. 1: configuración ausente y tratamiento de errores, así como historial de cambios (releases posteriores).