módulo ara::com — Communication Management

El Functional Cluster Communication Management (ara::com) permite la interacción orientada a servicios entre aplicaciones Adaptive a través de interfaces estandarizadas de proxy y skeleton (SWS_CommunicationManagement p. 55, ARAComAPI p. 1). Regula la búsqueda dinámica de servicios mediante OfferService() y FindService() ([SWS_CM_00101], [SWS_CM_00122]) y proporciona métodos síncronos y asíncronos, eventos y fields con protección E2E y SecOC integrada ([SWS_CM_00141], [SWS_CM_90420]). En caso de pérdida temporal de un servicio, el middleware absorbe las interrupciones de conexión y actualiza automáticamente los objetos proxy existentes una vez que vuelven a estar disponibles (ARAComAPI p. 32).

más ›

El Functional Cluster Communication Management (ara::com) constituye la columna vertebral de la arquitectura orientada a servicios (SOA) en la AUTOSAR Adaptive Platform y desacopla la lógica de aplicación de los protocolos de transmisión concretos mediante el patrón proxy-skeleton (SWS_CommunicationManagement p. 55, ARAComAPI p. 1). Las clases proxy generadas a partir de descripciones formales de interfaces en el lado consumidor y las clases skeleton en el lado proveedor proporcionan métodos, eventos y fields a través de APIs de C++ con seguridad de tipos ([SWS_CM_00130], [SWS_CM_00131]).

La provisión y la búsqueda dinámica de servicios se gestionan mediante Service Discovery (SWS_CommunicationManagement p. 67). Un proveedor ofrece su servicio a través de OfferService() ([SWS_CM_00101]), mientras que los consumidores determinan las instancias adecuadas de forma síncrona mediante FindService() o asíncrona mediante StartFindService() ([SWS_CM_00122], [SWS_CM_00123]). De este modo, las instancias pueden direccionarse a partir de modelos mediante ara::core::InstanceSpecifier y resolverse en tiempo de ejecución en ara::com::InstanceIdentifier concretos ([SWS_CM_00118], [SWS_CM_00622]).

Diagrama de secuencias: flujo de service offering, búsqueda asíncrona y creación de proxies. Fuentes: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces p. 16

Para la transmisión de datos, ara::com soporta métodos de petición-respuesta (request-response) mediante ara::core::Future ([SWS_CM_00191], [SWS_CM_00196]), así como patrones de publicación-suscripción (publish-subscribe) para eventos y fields (AUTOSAR_EXP_ARAComAPI p. 68). Los suscriptores se registran mediante Subscribe() ([SWS_CM_00141]) y leen los datos entrantes mediante GetNewSamples() ([SWS_CM_00701]). Para incrementar el rendimiento, el proveedor prepara los datos mediante Allocate() y transfiere la propiedad sin copias (zero-copy) mediante Send() ([SWS_CM_90437], [SWS_CM_90438]).

Para proteger la transmisión, la plataforma integra protección de extremo a extremo (E2E), autenticación criptográfica (SecOC) mediante Freshness Value Management (FVM), así como signal-to-service-translation para redes clásicas ([SWS_CM_90420], [SWS_CM_11288], [SWS_CM_10174], SWS_CommunicationManagement p. 222). Los estados de error se señalizan de manera estandarizada mediante dominios de error con seguridad de tipos como ComErrorDomain y ComE2EErrorDomain ([SWS_CM_10432], [SWS_CM_10474]). Si se interrumpe la conexión con un servicio, el estado del proxy cambia a kSubscriptionPending; tras volver a estar disponible, el middleware actualiza el direccionamiento interno de forma transparente, de modo que la comunicación continúa sin necesidad de reinstanciar el proxy (ARAComAPI p. 32).

más ›

Rol y arquitectura de sistema de la comunicación orientada a servicios

El Functional Cluster Communication Management (ara::com) constituye la columna vertebral informática de la AUTOSAR Adaptive Platform y realiza la comunicación orientada a servicios (Service-Oriented Architecture, SOA) entre procesos de aplicación aislados, así como más allá de los límites de las unidades de control (SWS_CommunicationManagement p. 55). El principio central es el estricto patrón de diseño proxy-skeleton (ARAComAPI p. 1): a partir de descripciones formales de interfaces de software (Service Interfaces), un generador de código basado en modelos genera clases proxy tipadas para consumidores de servicios y clases skeleton para proveedores de servicios ([SWS_CM_00130], [SWS_CM_00131]). La lógica de aplicación interactúa exclusivamente con estas abstracciones, mientras que los bindings específicos de protocolo como SOME/IP, IPC o DDS, así como su serialización, se vinculan recién en el momento de integración y despliegue (AUTOSAR_AP_EXP_ARAComAPI p. 124).

Para cumplir con los requisitos de la plataforma, ara::com coopera estrechamente con otros clusters funcionales (SWS_CommunicationManagement p. 34). En tiempo de ejecución, Execution Management supervisa el ciclo de vida de los procesos, mientras que el Identity and Access Management (IAM) bloquea interacciones no autorizadas a nivel de métodos, eventos y fields mediante comprobaciones de acceso basadas en políticas (Policy Decision Point) (SWS_CommunicationManagement p. 215). Asimismo, los incidentes de seguridad se notifican directamente al EventReporter del Intrusion Detection System Manager (IdSM) (SWS_CommunicationManagement p. 34).

Diagrama de contexto: integración de ara::com y desacoplamiento de los niveles de aplicación mediante bindings. Fuentes: SWS_CommunicationManagement p. 55, ARAComAPI p. 1

Búsqueda de servicios e instanciación mediante proxies y skeletons

La intermediación dinámica de servicios (Service Discovery) regula el establecimiento de relaciones de comunicación locales y distribuidas (SWS_CommunicationManagement p. 67). Un proveedor de servicios señaliza su disponibilidad llamando a OfferService() en el skeleton ([SWS_CM_00101]). Si el servicio finaliza o se retira la provisión, StopOfferService() revoca la oferta ([SWS_CM_00111]). Los consumidores determinan las instancias de servicio adecuadas de forma síncrona mediante FindService() o asíncrona mediante StartFindService() ([SWS_CM_00122], [SWS_CM_00123], ARAComAPI p. 103). Esta última registra un FindServiceHandler, que es notificado ante cada cambio en el entorno de instancias hasta que la búsqueda finaliza explícitamente mediante StopFindService() ([SWS_CM_00125], [SWS_CM_00383]).

Para desacoplar el código fuente de IDs fijos de red e instancia, la interfaz permite el direccionamiento mediante rutas abstractas de modelo a través de ara::core::InstanceSpecifier ([SWS_CM_00622], [SWS_CM_00623], AUTOSAR_AP_EXP_ARAComAPI p. 124). El middleware resuelve estos especificadores en ara::com::InstanceIdentifier concretos a través del Service Instance Manifest almacenado ([SWS_CM_00118], [SWS_CM_11520], ARAComAPI p. 1). Un servicio encontrado se proporciona como descriptor tipado (HandleType) en un ServiceHandleContainer ([SWS_CM_10383], AUTOSAR_EXP_SensorInterfaces p. 16). A través del método de fábrica estático Proxy::Create() o del constructor, el consumidor crea una instancia vinculada de proxy para el posterior uso de funciones ([SWS_CM_10438], [SWS_CM_00131]).

Diagrama de secuencias: flujo de service offering, búsqueda asíncrona y creación de proxies. Fuentes: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces p. 16

Patrones de interacción: llamadas a métodos y procesamiento asíncrono

Las llamadas a métodos reflejan el paradigma de petición-respuesta (request-response) síncrono y asíncrono. El cliente desencadena métodos a través del operador de llamada a función operator() en el proxy ([SWS_CM_00196]). Como tipo de retorno se utiliza por defecto un ara::core::Future, el cual encapsula el resultado o un estado de error ([SWS_CM_00191], ARAComAPI p. 1). El consumidor decide de forma flexible sobre la sincronización: mediante consulta bloqueante vía get(), espera con temporización vía wait_for() o wait_until(), o mediante el registro de rutinas de callback basadas en eventos con then() (ARAComAPI p. 1). Para notificaciones puramente unidireccionales sin respuesta existen métodos fire-and-forget con retorno void ([SWS_CM_90434], [SWS_CM_90435]).

En el lado del proveedor, el MethodCallProcessingMode define la estrategia de ejecución para las llamadas entrantes ([SWS_CM_00301], [SWS_CM_00130]). En el modo guiado por eventos (kEvent o kEventSingleThread), la llamada al método se realiza inmediatamente dentro de un worker thread gestionado por el middleware (AUTOSAR_SWS_CommunicationManagement p. 60). En el modo polling (kPoll), la propia aplicación controla determinísticamente los momentos de procesamiento llamando periódicamente a ProcessNextMethodCall() ([SWS_CM_00199], EXP_SWArchitecture p. 68). La implementación del método genera internamente el resultado a través de un ara::core::Promise y devuelve el future vinculado (ARAComAPI p. 1).

Diagrama de secuencias: llamada a método entre proxy y skeleton bajo despacho kPoll y kEvent. Fuentes: [SWS_CM_00196], [SWS_CM_00199], AUTOSAR_SWS_CommunicationManagement p. 60

Comunicación de eventos y fields en el patrón publish-subscribe

La distribución de flujos continuos de datos y cambios de estado se realiza a través de eventos y fields en el patrón publish-subscribe (SWS_CommunicationManagement p. 67). Un suscriptor activo registra su interés de recepción a través de Subscribe() indicando la cantidad máxima de samples que se deben mantener (maxSampleCount) ([SWS_CM_00141], [SWS_CM_12002]). El estado de suscripción se consulta a través de GetSubscriptionState() o se supervisa de forma asíncrona mediante callbacks vía SetSubscriptionStateChangeHandler() ([SWS_CM_00310], [SWS_CM_00316], [SWS_CM_01110]). La finalización de la suscripción se realiza a través de Unsubscribe() ([SWS_CM_00151]).

La recepción de datos puede efectuarse guiada por eventos mediante SetReceiveHandler() o a través de la lectura periódica del búfer de recepción ([SWS_CM_00181], [SWS_CM_11356]). Con GetNewSamples(), el consumidor transfiere un objeto función (lambda) que se invoca para cada sample recibido con un SamplePtr tipado ([SWS_CM_00701], [SWS_CM_11610]). Para evitar sobrecargas por copia (zero-copy), el skeleton proporciona memoria a través de Allocate() y envía el puntero tipado SampleAllocateePtr con transferencia completa de propiedad a través de Send() a la capa de transmisión ([SWS_CM_90438], [SWS_CM_90437], [SWS_CM_00308], AUTOSAR_EXP_ARAComAPI p. 63, ARAComAPI p. 1).

Un field amplía el concepto de evento con semántica de getter y setter (AUTOSAR_EXP_ARAComAPI p. 68). Los consumidores leen el field mediante Get() o lo escriben mediante Set() ([SWS_CM_00112], [SWS_CM_00113]). En el lado del servidor, estas solicitudes se atienden con RegisterGetHandler() o RegisterSetHandler() ([SWS_CM_00114], [SWS_CM_00116]). Si el servidor actualiza el estado mediante Update(), el field actúa automáticamente como notificador y distribuye el cambio a todos los suscriptores registrados ([SWS_CM_00119], ARAComAPI p. 1).

Diagrama de secuencias: asignación zero-copy, publicación de eventos, suscripción y consumo de GetNewSamples. Fuentes: [SWS_CM_00141], [SWS_CM_00701], [SWS_CM_90437], AUTOSAR_EXP_ARAComAPI p. 63

Protección, traducción de servicios e integración en la plataforma

Para flujos de datos relevantes para la seguridad y deterministas, ara::com integra protección de extremo a extremo (E2E) y autenticación según los estándares de AUTOSAR (AUTOSAR_AP_TR_SystemTests p. 132). A través de GetProfileCheckStatus() y GetE2EStateMachineState(), los consumidores pueden comprobar el estado de integridad y validación de los datos recibidos ([SWS_CM_90420], [SWS_CM_90421], [SWS_CM_11554]). En el lado del servidor, la aplicación registra rutinas de tratamiento de errores a través de SetTransportFaultConditionHandler() para reaccionar de manera estandarizada ante defectos de E2E y de transporte a nivel de método ([SWS_CM_00093], [SWS_CM_00094], [SWS_CM_00100], EXP_SWArchitecture p. 68).

La integridad criptográfica y la autenticidad de los mensajes externos se garantizan mediante Secure Onboard Communication (SecOC) (SWS_CommunicationManagement p. 222). Para ello, el middleware integra una biblioteca intercambiable de Freshness Value Management (FVM) que gestiona los valores de freshness a través de GetRxFreshness(), GetTxFreshness() y Initialize() ([SWS_CM_11288], [SWS_CM_11289], [SWS_CM_11290], SWS_CommunicationManagement p. 226). Las funciones de diagnóstico y seguridad supervisan o controlan la verificación a través de interfaces específicas como SetVerificationStatus() ([SWS_CM_19999], AUTOSAR_AP_EXP_SWArchitecture p. 70).

Para la interoperabilidad con la AUTOSAR Classic Platform, ara::com soporta la comunicación basada en señales (Signal-to-Service Translation) (SWS_CommunicationManagement p. 146, TPS_ManifestSpecification p. 476). Conforme a [SWS_CM_10174] y [SWS_CM_80001], las IPDUs de señal clásicas y los mensajes SOME/IP pueden transportarse a través del mismo socket. Si existe una configuración de SecOC basada en señales, el middleware lee los parámetros de protección directamente desde el PDU-Triggering del manifiesto ([SWS_CM_11346], SWS_CommunicationManagement p. 228).

Diagrama de actividades: pipeline de protección E2E y SecOC de mensajes entrantes. Fuentes: [SWS_CM_90420], [SWS_CM_11288], SWS_CommunicationManagement p. 222

Comportamiento en caso de error

La gestión de errores de ara::com se basa en dominios de error con seguridad de tipos y códigos de retorno del framework de AUTOSAR Core ([SWS_CM_11334], [SWS_CM_11335]). Los errores de la capa de comunicación general se agrupan en ComErrorDomain y se codifican mediante el enumerador ComErrc ([SWS_CM_10432]). Ante errores de comprobación de E2E, ComE2EErrorDomain señaliza fallos de comprobación específicos, como desviaciones de suma de comprobación o contadores no válidos, mediante el valor de enumeración ComE2EErrc ([SWS_CM_10474], [SWS_CM_12510], [SWS_CM_12511]). Para errores de freshness de SecOC existe análogamente ComSecOcFvmErrorDomain con ComSecOcFvmErrc ([SWS_CM_12521], [SWS_CM_12522]).

Si se produce una caída de la conexión durante el tiempo de ejecución, el estado de suscripción del proxy cambia de kSubscribed a kSubscriptionPending ([SWS_CM_00310], [SWS_CM_00316], ARAComAPI p. 32). Las llamadas a métodos fallan en esta fase con un error. Si el proveedor de servicios regresa a continuación a través de Service Discovery, el middleware actualiza el direccionamiento interno del proxy de forma transparente, sin que el consumidor deba reinstanciar el objeto proxy; tras una resincronización exitosa, el estado vuelve automáticamente a kSubscribed (ARAComAPI p. 32). De los plazos temporales y de la supervisión de plazos (Deadline Monitoring) se encarga, según la especificación del sistema, el propio software de aplicación (TPS_ManifestSpecification p. 504).

Diagrama de estados: ciclo de vida y estados de conexión de una instancia de proxy ante cambios de disponibilidad del proveedor. Fuentes: [SWS_CM_00310], [SWS_CM_00316], ARAComAPI p. 32

Más evidencia detallada

Los requisitos esenciales y las interfaces del sistema se estructuran de la siguiente manera dentro de las especificaciones de AUTOSAR:

• Ciclo de vida y discovery de servicios: la provisión de servicios y los mecanismos de búsqueda se basan en [SWS_CM_00101], [SWS_CM_00111], [SWS_CM_00122] y [SWS_CM_00123], detallados en la guía de arquitectura de software (ARAComAPI p. 103).
• Paradigmas de interacción: los métodos y los valores futuros asíncronos están estandarizados en [SWS_CM_00191] y [SWS_CM_00196]; las suscripciones a eventos y las transmisiones de muestras siguen [SWS_CM_00141], [SWS_CM_00701] y [SWS_CM_90437] (SWS_CommunicationManagement p. 67).
• Seguridad y serialización: los conceptos de protección para E2E ([SWS_CM_90420]), SecOC ([SWS_CM_90108], [SWS_CM_11288]) y traducción de señal a servicio ([SWS_CM_10174]) regulan el intercambio de datos a nivel de todo el sistema (SWS_CommunicationManagement p. 146, SWS_CommunicationManagement p. 222).
• Definiciones de manifiesto y de tipos: el mapeo de tipos de datos estructurados, campos opcionales y especificadores de instancia está establecido en la especificación del manifiesto (TPS_ManifestSpecification p. 161, TPS_ManifestSpecification p. 458).