AUTOSAR Classic General & Standard Types

El clúster de módulos General & Standard Types proporciona, a través de las cabeceras Platform_Types.h, Std_Types.h y ComStack_Types.h, la base independiente del hardware para todos los tipos de datos, respuestas de estado y búferes de comunicación de la Classic Platform (AUTOSAR_SRS_BSWGeneral p. 62). Normaliza características fundamentales de arquitectura como modelos de endianness, valores de retorno estandarizados como Std_ReturnType y estructuras de comunicación como PduInfoType ([SWS_Std_00005], [SWS_COMTYPE_00008]). Dado que se trata de puras definiciones de cabecera sin código ejecutable, el clúster no requiere configuración en tiempo de ejecución ni posee tareas propias o un tratamiento activo de errores (SWS_StandardTypes p. 27).

más ›

El clúster de módulos General & Standard Types abarca las tres cabeceras básicas platform (Platform_Types.h), std (Std_Types.h) y comstack (ComStack_Types.h). Como puras definiciones de tipos, no contienen ningún código ejecutable y no precisan configuración (SWS_StandardTypes p. 27). Constituyen el fundamento a nivel de plataforma para una tipificación independiente del hardware, unifican particularidades de compilador y hardware y abastecen a todos los módulos BSW y a la RTE con estructuras de datos consistentes (AUTOSAR_SRS_BSWGeneral p. 62).

Diagrama de arquitectura: arquitectura estática de capas e inclusión del clúster de módulos 'General & Standard Types' con interfaces de tipos exportadas. Fuentes: AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

La jerarquía de inclusión se construye progresivamente: Platform_Types.h encapsula propiedades específicas de la plataforma como el tipo C99 boolean ([SWS_Platform_00027]), punteros a búfer universales como ConstVoidPtr ([SWS_Platform_91002]), así como símbolos para el orden de bits de registros CPU_BIT_ORDER ([SWS_Platform_00038]) y el orden de bytes en memoria CPU_BYTE_ORDER ([SWS_Platform_00039]). Sobre esta base, Std_Types.h proporciona constantes estándar universales como STD_ON/STD_OFF ([SWS_Std_00010]), estructuras de versión de módulo mediante Std_VersionInfoType ([SWS_Std_00015]), así como el sistema de estado fundamental Std_ReturnType con E_OK y E_NOT_OK ([SWS_Std_00005], [SWS_Std_00006]).

Para la pila de comunicación de AUTOSAR, ComStack_Types.h define todos los tipos de interfaz independientes del protocolo como PduIdType ([SWS_COMTYPE_00005]), NetworkHandleType ([SWS_COMTYPE_00038]) y la estructura central de búfer PduInfoType ([SWS_COMTYPE_00008]). En protocolos de transporte segmentados (p. ej., CanTp o DoIP), el tipo de retorno BufReq_ReturnType controla junto con RetryInfoType la reserva síncrona de búfer y la copia de datos entre capas BSW (SWS_DiagnosticCommunicationManager p. 291, [SWS_COMTYPE_00012]).

Diagrama de secuencias: ruta segmentada de recepción y búfer de un protocolo de transporte utilizando ComStack_Types (PduInfoType, BufReq_ReturnType). Fuentes: SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274

Aunque el clúster no posee un tratamiento de errores propio ni notificaciones DET (SWS_StandardTypes p. 27), Std_ReturnType estructura el tratamiento de errores del sistema global: los bits 0 a 5 (0x00 a 0x3F) están reservados para errores estándar y de aplicación, mientras que los bits 6 y 7 están ocupados exclusivamente por la RTE ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). Todas las definiciones de tipos están especificadas para su uso reentrante en contextos multitarea y de interrupción (SWS_CANInterface p. 87).

más ›

Arquitectura del sistema & rol del clúster de módulos

El clúster de módulos General & Standard Types constituye el fundamento tipológico y de abstracción de hardware fundamental de la AUTOSAR Classic Platform en el Release R20-11. Se compone de los tres módulos de cabecera pura platform ([SWS_Platform_00038]), std ([SWS_Std_00005]) y comstack ([SWS_COMTYPE_00005]). Conforme a la arquitectura BSW, estos módulos no proporcionan código C ejecutable propio ni solicitan otros controladores BSW (SWS_StandardTypes p. 27). Su tarea central consiste en encapsular las dependencias de compilador y procesador, proporcionar tipos básicos uniformes en toda la plataforma y establecer estructuras de datos estandarizadas para las capas de comunicación.

La jerarquía de capas sigue un orden de inclusión estrictamente unidireccional: el archivo Platform_Types.h abstrae las propiedades de la arquitectura del microcontrolador subyacente (como la disposición de registros y memoria, así como los tipos elementales de C99), mientras que Std_Types.h se basa en él y define valores de retorno universales y constantes de estado (AUTOSAR_SRS_BSWGeneral p. 62). A partir de ello, ComStack_Types.h declara todos los tipos de datos interbuses y multiprotocolo para redes como CAN, FlexRay, LIN y Ethernet, así como para protocolos de transporte según ISO 15765-2 y protocolos de diagnóstico según ISO 14229 ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). Mediante este desacoplamiento se garantiza que las capas superiores, como el entorno de ejecución (RTE) y los componentes de software de aplicación (SWCs), permanezcan completamente portables (SWS_RTE p. 818).

Diagrama de arquitectura: arquitectura estática de capas e inclusión del clúster de módulos 'General & Standard Types' con interfaces de tipos exportadas. Fuentes: AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

Interacción y rutas de interacción entre los módulos

La interacción dentro del clúster se basa en una cadena de inclusión estática: ComStack_Types.h incluye Std_Types.h, el cual a su vez incluye Platform_Types.h (RS_BSWGeneral p. 60). El módulo platform define magnitudes fundamentales como boolean, que debe mapearse obligatoriamente al tipo básico de C99 _Bool ([SWS_Platform_00027]), y regula su rigurosa asignación de valores mediante los literales TRUE y FALSE ([SWS_Platform_00034]). Además, se especifican punteros a búfer genéricos como ConstVoidPtr, que se utilizan para búferes de paso inmutables hacia interfaces de función invocadas ([SWS_Platform_91002]).

Adicionalmente, platform armoniza los endianness del hardware mediante símbolos de preprocesador estandarizados: para el orden de bits en registros, CPU_BIT_ORDER se fija en MSB_FIRST o LSB_FIRST ([SWS_Platform_00038], [SWS_Platform_00048], [SWS_Platform_00049]). El orden de bytes en la memoria física se controla mediante CPU_BYTE_ORDER, distinguiéndose HIGH_BYTE_FIRST (Big Endian, MSB en la dirección inferior) de LOW_BYTE_FIRST (Little Endian, LSB en la dirección inferior) ([SWS_Platform_00039], [SWS_Platform_00050], [SWS_Platform_00051]).

Diagrama estructural: mapeo en memoria de valores multietapa escalares en Big-Endian (HIGH_BYTE_FIRST) vs. Little-Endian (LOW_BYTE_FIRST). Fuentes: AUTOSAR_CP_SWS_PlatformTypes p. 16, AUTOSAR_CP_SWS_PlatformTypes p. 15, [SWS_Platform_00050], [SWS_Platform_00051]

En el siguiente nivel de abstracción, el módulo std define símbolos universales para estados de conmutación y niveles lógicos: STD_HIGH (0x01u) y STD_LOW (0x00u) para niveles de tensión física ([SWS_Std_00007]), STD_ON (0x01u) y STD_OFF (0x00u) para modos de activación ([SWS_Std_00010]), así como STD_ACTIVE (0x01u) y STD_IDLE (0x00u) para estados lógicos de ejecución ([SWS_Std_00013]). Para protocolos de mensajes y transformadores, std proporciona además Std_MessageTypeType con los literales STD_MESSAGETYPE_REQUEST (0x00) y STD_MESSAGETYPE_RESPONSE (0x01) ([SWS_Std_91001], [SWS_Std_00017]), así como el tipo de puntero a función Std_ExtractProtocolHeaderFieldsType para la extracción de cabeceras de protocolo ([SWS_Std_91003]).

El módulo comstack, a su vez, utiliza los tipos básicos de platform y std para estructurar todo el intercambio de búferes y datos en la pila de comunicación. La estructura de interfaz central es PduInfoType, que agrupa el puntero de datos SduDataPtr (uint8*), el puntero de metadatos MetaDataPtr y la longitud de búfer SduLength del tipo PduLengthType ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). La identificación de I-PDU se realiza a través de PduIdType ([SWS_COMTYPE_00005]). Para la gestión de canales de comunicación completos y subredes, comstack define el identificador de canal NetworkHandleType ([SWS_COMTYPE_00038]) y el identificador de subred PNCHandleType ([SWS_COMTYPE_00036]), que se utilizan, por ejemplo, en el Synchronized PNC Shutdown de ComM y Nm (SWS_COMManager p. 171).

En transmisiones de protocolos de transporte segmentados (TP), la negociación de búfer se gestiona mediante los tipos de retorno BufReq_ReturnType y la estructura RetryInfoType ([SWS_COMTYPE_00012]). En llamadas de copia síncronas como CopyTxData o CopyRxData entre módulos como CanTp, PduR, DCM, DoIP o SecOC, BUFREQ_OK señala una operación de copia exitosa, mientras que BUFREQ_E_BUSY comunica que se dispone temporalmente de búfer insuficiente y que se permite un nuevo intento (SWS_DiagnosticCommunicationManager p. 291, SWS_SecureOnboardCommunication p. 76). Mediante RetryInfoType con parámetros como TP_CONFPENDING o TP_DATACONF se asegura que los datos permanezcan en el búfer para posibles reintentos o se liberen tras la confirmación (SWS_IntrusionDetectionSystemManager p. 49).

Diagrama de secuencias: ruta segmentada de recepción y búfer de un protocolo de transporte utilizando ComStack_Types (PduInfoType, BufReq_ReturnType). Fuentes: SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274

Sincronización, reentrancia y contextos de tareas

Dado que los módulos platform, std y comstack son archivos de cabecera puros sin archivos objeto ejecutables, por su naturaleza no implementan MainFunctions cíclicos y no poseen contextos de tarea propios (SWS_StandardTypes p. 27). No obstante, definen las firmas y convenciones de tipos para funciones que se invocan a través de los límites entre capas. Todas las definiciones de tipos están diseñadas de modo que puedan pasarse sin restricciones de forma reentrante y sin estado (SWS_CANInterface p. 87).

El uso práctico de los tipos tiene lugar en entornos altamente asíncronos y concurrentes. Las devoluciones de llamada de recepción de datos como CanIf_RxIndication o Dcm_CopyRxData, que utilizan PduInfoType y PduIdType, pueden ejecutarse explícitamente en el contexto de interrupción (SWS_CANInterface p. 164, SWS_DiagnosticCommunicationManager p. 274). Por el contrario, las decisiones de enrutamiento, las asignaciones de búfer o las transmisiones cíclicas se procesan en tareas periódicas de las capas superiores (p. ej., SoAd_MainFunction) (SWS_SocketAdaptor p. 104). Dado que las estructuras de punteros como PduInfoType pueden compartirse entre el nivel de interrupción y el nivel de tarea, la sincronización segura para subprocesos mediante áreas exclusivas (protección contra concurrencia) corresponde a los módulos BSW invocadores e implementadores.

Ciclos de vida típicos y modos de funcionamiento

Las definiciones de tipos puras no están sujetas a un ciclo de vida en tiempo de ejecución y no poseen funciones de inicialización ni de apagado (SWS_StandardTypes p. 27). Deben incluirse estáticamente en tiempo de compilación antes de todos los módulos procesadores. Sin embargo, forman la estructura normativa para representar y supervisar el ciclo de vida de otros módulos BSW: para la consulta de versiones estandarizada, std especifica la estructura Std_VersionInfoType, que contiene vendorID, moduleID así como los estados de versión del software (sw_major_version, sw_minor_version, sw_patch_version) ([SWS_Std_00015]).

Además, tipos como NetworkHandleType y PNCHandleType admiten la gestión de red y de modos de nivel superior durante los cambios de modo de funcionamiento tales como Startup, funcionamiento normal, Sleep y Wakeup ([SWS_COMTYPE_00036], [SWS_COMTYPE_00038]). De este modo, el ComM controla, basándose en estos identificadores, desconexiones coordinadas y cambios de estado en el conjunto de subredes (SWS_COMManager p. 171, SWS_NetworkManagementInterface p. 106).

Tratamiento de errores, rastreo mediante DET y codificación de estados

El clúster de módulos no proporciona un tratamiento de errores activo propio y no notifica ni errores de desarrollo al DET ni errores de producción al DEM (SWS_StandardTypes p. 27). En su lugar, normaliza el formato de respuesta en toda la plataforma: el tipo fundamental Std_ReturnType se basa en uint8 y sirve a través de todas las capas como resultado estándar de llamadas síncronas ([SWS_Std_00005], BSWUMLModelModelingGuide p. 28). Por defecto, E_OK (0x00u) representa la ejecución correcta y E_NOT_OK (0x01u) un error genérico ([SWS_Std_00006]). Por motivos de compatibilidad con ISO 17356-3 (OSEK OS), E_OK se protege contra definiciones múltiples mediante una comprobación de protección (STATUSTYPEDEFINED) (AUTOSAR_SRS_BSWGeneral p. 62).

La disposición de bits de Std_ReturnType sigue una partición firmemente definida: los bits 0 a 5 (rango de 0x00 a 0x3F) están reservados para valores de retorno estandarizados y específicos del módulo o bien códigos de ApplicationError específicos de la aplicación en operaciones cliente/servidor ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). Las extensiones específicas de módulo se gestionan en modelos UML como una clase con el estereotipo «extra_literals» (BSWUMLModelModelingGuide p. 33). Los bits 6 y 7 (rango de valores 0x40, 0x80, 0xC0) están estrictamente reservados para estados de error de infraestructura de la RTE (AUTOSAR_CP_SWS_StandardTypes p. 15). Para transformaciones de datos en la RTE, std declara adicionalmente la estructura Std_TransformerError, compuesta por errorCode ([SWS_Std_00022]) y transformerClass ([SWS_Std_00021]), con lo que las cadenas de errores pueden rastrearse por completo en la serialización o en la protección E2E.