módulo ara::rds — Raw Data Streams

El clúster adaptativo Raw Data Stream (RDS) sirve para la transferencia optimizada en latencia y rendimiento de flujos de datos no estructurados, así como de datos multimedia y de sensores de tiempo crítico, eludiendo la sobrecarga de serialización orientada a servicios AUTOSAR_AP_EXP_SWArchitecture p. 74. Proporciona APIs de C++ para flujos de bytes punto a punto basados en IP (TCP/UDP), así como para streaming de capa 2 según el estándar AVTP IEEE 1722 [SWS_RDS_10482], [SWS_RDS_90312]. Ambas formas de comunicación operan estrictamente mediante métodos factoría estáticos y notifican errores de manera eficiente en el uso de recursos mediante el constructo Result para toda la plataforma [SWS_RDS_12367].

más ›

El clúster funcional Raw Data Stream (RDS) proporciona interfaces de alto rendimiento para la transmisión de flujos de bytes no formateados y datos de sensores de tiempo crítico para la AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_SWArchitecture p. 73. Mediante la abstracción directa de sockets de red POSIX, así como de interfaces Ethernet de capa 2, RDS elude la costosa serialización de la comunicación estándar orientada a servicios (ara::com) AUTOSAR_AP_EXP_SWArchitecture p. 74.

Para flujos de bytes basados en IP a través de TCP o UDP, las aplicaciones utilizan las clases RawDataStreamClient y RawDataStreamServer, que se vinculan a puertos modelados mediante métodos estáticos Create [SWS_RDS_10482], [SWS_RDS_11312]. Tras el establecimiento de la conexión a través de Connect o WaitForConnection, los volúmenes de datos se intercambian sin copias de memoria innecesarias mediante std::unique_ptr<ara::core::Byte[]> a través de ReadData y WriteData [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11301].

Diagrama de secuencia: establecimiento de conexión, intercambio de datos y terminación en Raw Data Streams basados en IP. Fuentes: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10486], [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322]

Para flujos de datos deterministas en tiempo real procedentes de cámaras o fuentes de audio, RDS implementa clases según IEEE 1722 (AVTP) como IEEE1722RawDataStreamProducer y IEEE1722RawDataStreamConsumer [SWS_RDS_90312], [SWS_RDS_90323]. Clases de subtipos específicos como RVF (vídeo), AAF (audio) y CRF (referencia de reloj) encapsulan en este caso cabeceras de trama y datos útiles conformes con el estándar [SWS_RDS_90262], [SWS_RDS_90276], [SWS_RDS_90295].

Los errores se señalan de forma conforme con la plataforma sin excepciones de C++ mediante ara::core::Result y el dominio de error RdsErrorDomain con códigos de error específicos (RdsErrc) [SWS_RDS_11298], [SWS_RDS_12367]. En el manifiesto de AUTOSAR, la definición de la interfaz se vincula sin fisuras a puntos finales Ethernet mediante RawDataStreamClientMapping y RawDataStreamServerMapping AUTOSAR_AP_TPS_ManifestSpecification p. 851.

más ›

Clasificación arquitectónica y límites del sistema

El clúster funcional Raw Data Stream (RDS) de la AUTOSAR Adaptive Platform proporciona interfaces de programación de aplicaciones (APIs) estandarizadas para la transferencia de alto rendimiento de flujos de datos no estructurados o de tiempo real crítico AUTOSAR_AP_EXP_SWArchitecture p. 73. A diferencia de la comunicación fuertemente tipada y orientada a servicios a través de ServiceInterfaces (como SOME/IP o DDS), RDS elude por completo la sobrecarga de serialización y protocolo de ara::com AUTOSAR_AP_EXP_SWArchitecture p. 74. Esto permite la conexión con capacidad de tiempo real y optimizada para el rendimiento de sensores de banda ancha, tales como cámaras de vídeo, sensores de radar y LiDAR o sistemas de audio, directamente a Adaptive Applications AUTOSAR_AP_EXP_SWArchitecture p. 61.

Arquitectónicamente, el módulo se divide en dos pilares fundamentales de comunicación: por un lado, la transmisión de flujos de bytes basados en IP mediante protocolos de transporte como TCP o UDP, encapsulando sockets POSIX y con protección opcional mediante TLS/IPsec AUTOSAR_SWS_CommunicationManagement p. 58. Por otro lado, el módulo ofrece un subsistema especializado para el streaming de capa 2 según IEEE 1722 (Audio Video Transport Protocol, AVTP) a través de redes Ethernet y Time-Sensitive Networking (TSN) AUTOSAR_AP_EXP_SWArchitecture p. 74. Ambas formas de comunicación abstraen las estructuras de red y búfer específicas del sistema tras clases uniformes de C++ en el espacio de nombres ara::rds AUTOSAR_AP_SWS_RawDataStream p. 39.

Instanciación y gestión de conexiones

La creación de puntos finales de comunicación se realiza en RDS estrictamente mediante métodos factoría estáticos que están vinculados a instancias de puerto modeladas [SWS_RDS_10482]. Para flujos de bytes basados en IP, las clases ara::rds::RawDataStreamClient y ara::rds::RawDataStreamServer encapsulan los roles de iniciador y receptor AUTOSAR_AP_EXP_SWArchitecture p. 73. La factoría RawDataStreamClient::Create instancia un punto final de cliente para un puerto definido en el manifiesto de forma segura para hilos mediante un ara::core::InstanceSpecifier [SWS_RDS_10482]. De manera análoga, RawDataStreamServer::Create crea la instancia de punto final de servidor correspondiente [SWS_RDS_11312]. Ambas clases prohíben constructores de copia y asignaciones de copia, pero admiten explícitamente semánticas de movimiento para una propiedad de recursos unívoca [SWS_RDS_11303], [SWS_RDS_11305], [SWS_RDS_11316], [SWS_RDS_11314].

Tras una inicialización correcta, el servidor espera conexiones entrantes a través de WaitForConnection de forma bloqueante o con un tiempo de espera especificado [SWS_RDS_11318], [SWS_RDS_11319]. El cliente, por su parte, establece activamente la conexión mediante Connect, ya sea de forma indefinida o dentro de un lapso de tiempo en milisegundos [SWS_RDS_10484], [SWS_RDS_11307]. La finalización de una sesión activa se produce de forma determinista mediante la llamada a Shutdown [SWS_RDS_10485], [SWS_RDS_11320] o bien de forma implícita en el marco de la llamada al destructor, el cual cierra y libera automáticamente una conexión aún abierta [SWS_RDS_10483], [SWS_RDS_11313].

Diagrama de secuencia: establecimiento de conexión, intercambio bidireccional de datos y terminación entre RawDataStreamClient y RawDataStreamServer. Fuentes: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322], [SWS_RDS_11324], AUTOSAR_AP_SWS_RawDataStream p. 10, AUTOSAR_AP_EXP_SWArchitecture p. 204, AUTOSAR_AP_EXP_SWArchitecture p. 222

Diagrama de estados: ciclo de vida de una conexión Raw Data Stream. Fuentes: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10485], [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11318], [SWS_RDS_11320]

Intercambio de datos IP no estructurados a través de sockets

La transferencia de datos para conexiones IP está concebida de forma bidireccional y se lleva a cabo mediante operaciones que pueden ejecutarse de forma síncrona con supervisión opcional de tiempo de espera [SWS_RDS_10486], [SWS_RDS_11309]. En el lado del receptor, la operación ReadData devuelve una estructura de datos del tipo ara::rds::ReadDataResult [SWS_RDS_10486], [SWS_RDS_11322]. Esta estructura encapsula los datos binarios leídos en forma de un puntero inteligente data (std::unique_ptr<ara::core::Byte[]>) e indica, a través del campo numberOfBytes, la cantidad real de bytes recibidos [SWS_RDS_11301], [SWS_RDS_11302]. Mediante esta transferencia de la propiedad del búfer se evitan copias de memoria innecesarias.

Para el envío de datos binarios, las aplicaciones transfieren el búfer de bytes asimismo mediante semántica de movimiento a través de un std::unique_ptr<ara::core::Byte[]> y especifican la longitud máxima maxLength en WriteData [SWS_RDS_10487], [SWS_RDS_11324]. Para rutas de red críticas en latencia o con riesgo de bloqueo, se dispone de variantes sobrecargadas de ReadData y WriteData con especificación explícita de tiempo de espera en milisegundos [SWS_RDS_11310], [SWS_RDS_11323], [SWS_RDS_11325]. De este modo, se pueden gestionar de forma determinista extremos ausentes o búferes de red atascados AUTOSAR_AP_EXP_InterfacesGuidelines p. 41.

Streaming cuasi en tiempo real con IEEE 1722 (AVTP)

Para flujos isócronos y deterministas de multimedia y sensores, RDS proporciona clases plantilla especializadas para consumidores y productores según IEEE 1722 [SWS_RDS_90312], [SWS_RDS_90323]. La clase ara::rds::IEEE1722RawDataStreamConsumer<T> actúa como sumidero de datos y se instancia mediante Create [SWS_RDS_90312]. Mediante Connect se vincula al flujo asignado (bajo filtrado de MAC multidifusión, VLAN e ID de flujo) AUTOSAR_AP_EXP_SWArchitecture p. 203, para leer a continuación a través de ReadData hasta maxNumberOfDatagrams datagramas estructurados como std::vector<T> [SWS_RDS_90319], [SWS_RDS_90321]. De manera análoga, ara::rds::IEEE1722RawDataStreamProducer<T> asume la generación y el envío de tramas AVTP a través de WriteData(std::vector<T>) [SWS_RDS_90323], [SWS_RDS_90330], [SWS_RDS_90332].

Los tipos de datagrama forman una jerarquía de herencia orientada a objetos estandarizada AUTOSAR_AP_SWS_RawDataStream p. 39. La base de todas las tramas es IEEE1722Datagram con campo de datos útiles data e indicación de longitud stream_data_length [SWS_RDS_90226], [SWS_RDS_90227], [SWS_RDS_90228]. Derivada de esta, IEEE1722DatagramAVTPDUCommonHeaderFields encapsula información de cabecera general como avtpStreamDataSubtype, headerSpecific y version de protocolo [SWS_RDS_90230], [SWS_RDS_90231], [SWS_RDS_90232], seguida de IEEE1722DatagramAVTPDUCommonStreamHeaderFields con marcas de tiempo (avtp_timestamp), identificación de flujo (unique_id, mac_address) y números de secuencia de paquete (sequenceNum) [SWS_RDS_90235], [SWS_RDS_90237], [SWS_RDS_90240].

Sobre esta base común se asientan especializaciones concretas de subtipos: IEEE1722DatagramRVF para datos de vídeo sin procesar con parámetros de píxeles, frecuencia de actualización e información de línea (pixel_format, pixel_depth, frame_rate, colorspace, total_lines) [SWS_RDS_90276], [SWS_RDS_90278], [SWS_RDS_90285], [SWS_RDS_90286], [SWS_RDS_90287]; IEEE1722DatagramAAF para formatos de audio como PCM o AES3 (channels_per_frame, bit_depth, aes3_data_type_h) [SWS_RDS_90262], [SWS_RDS_90266], [SWS_RDS_90267], [SWS_RDS_90270]; IEEE1722DatagramCRF para sincronización y transmisión de reloj a través de TSN (base_frequency, timestamp_interval, pull) [SWS_RDS_90295], [SWS_RDS_90297], [SWS_RDS_90302], [SWS_RDS_90303]; así como IEEE1722Datagram61883_IIDC para transportes de cámaras industriales [SWS_RDS_90245], [SWS_RDS_90260] y IEEE1722DatagramNTSCF para formatos de control no críticos en tiempo [SWS_RDS_90306], [SWS_RDS_90310].

Diagrama de secuencia: ciclo de interacción para streaming de audio/vídeo IEEE 1722 (productor y consumidor). Fuentes: [SWS_RDS_90312], [SWS_RDS_90319], [SWS_RDS_90320], [SWS_RDS_90321], [SWS_RDS_90323], [SWS_RDS_90330], [SWS_RDS_90331], [SWS_RDS_90332], AUTOSAR_AP_EXP_SWArchitecture p. 203, AUTOSAR_AP_EXP_SWArchitecture p. 221

Diagrama de clases: jerarquía de herencia de los datagramas IEEE 1722 en el subsistema ara::rds. Fuentes: [SWS_RDS_90226], [SWS_RDS_90230], [SWS_RDS_90235], [SWS_RDS_90245], [SWS_RDS_90262], [SWS_RDS_90276], [SWS_RDS_90295], [SWS_RDS_90306], AUTOSAR_AP_SWS_RawDataStream p. 39

Metamodelado y despliegue del manifiesto

En el metamodelo de manifiesto de AUTOSAR se preserva la separación entre el diseño de la aplicación y el despliegue específico de la plataforma AUTOSAR_AP_TPS_ManifestSpecification p. 254. El elemento base abstracto AbstractRawDataStreamInterface especializa PortInterface y se ramifica en las interfaces concretas RawDataStreamClientInterface y RawDataStreamServerInterface AUTOSAR_AP_TPS_ManifestSpecification p. 254. En el nivel de despliegue, un EthernetRawDataStreamClientMapping o EthernetRawDataStreamServerMapping vincula los puertos de software con puntos finales físicos de comunicación como ApApplicationEndpoint, direcciones IP y números de puerto AUTOSAR_AP_TPS_ManifestSpecification p. 851, TPS_ManifestSpecification p. 850.

El manifiesto permite escenarios de integración flexibles para la topología del sistema: tanto modelos de AUTOSAR totalmente formalizados, en los que el cliente y el servidor están vinculados dentro del mismo diseño ARXML AUTOSAR_TPS_ManifestSpecification p. 656, como configuraciones asimétricas. En estos escenarios asimétricos, solo el cliente o solo el servidor está modelado en el modelo, mientras que el extremo opuesto correspondiente se conecta a través de credenciales estáticas como remoteServerConfig o remoteClientConfig AUTOSAR_TPS_ManifestSpecification p. 660, AUTOSAR_TPS_ManifestSpecification p. 661. Para flujos AVTP, el EthernetMacRawDataStreamMapping vincula puertos y procesos directamente a puntos finales MAC y priorizaciones VLAN AUTOSAR_AP_TPS_ManifestSpecification p. 854, en correspondencia con las definiciones de plantillas de sistema IEEE1722TpConnection, IEEE1722TpAvConnection, IEEE1722TpAafConnection y IEEE1722TpRvfConnection AUTOSAR_CP_TPS_SystemTemplate p. 705, AUTOSAR_CP_TPS_SystemTemplate p. 708, AUTOSAR_CP_TPS_SystemTemplate p. 716.

Diagrama de contexto: relaciones del metamodelo de AUTOSAR entre interfaz de puerto, asignación y despliegue de transporte. Fuentes: [SWS_RDS_10482], [SWS_RDS_11312], AUTOSAR_AP_TPS_ManifestSpecification p. 254, AUTOSAR_AP_TPS_ManifestSpecification p. 851, TPS_ManifestSpecification p. 850

Comportamiento en caso de error

El tratamiento de errores en RDS sigue el enfoque de evaluación de errores de la AUTOSAR Adaptive Platform mediante ara::core::Result y ara::core::ErrorCode [SWS_RDS_10484], [SWS_RDS_11299]. Todos los métodos de API potencialmente susceptibles de fallo —entre ellos Create, Connect, WaitForConnection, ReadData y WriteData— están declarados como noexcept y notifican códigos de error a través del tipo de retorno ara::core::Result [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_11318]. Los estados de error específicos del módulo se gestionan en la enumeración ara::rds::RdsErrc [SWS_RDS_12367], la cual puede referenciarse a través del alias de tipo ara::rds::RdsErrorDomain::Errc [SWS_RDS_11326].

El módulo define para ello el dominio de error RdsErrorDomain, cuya instancia se obtiene a través de GetRdsErrorDomain() [SWS_RDS_11298]. La construcción predeterminada de RdsErrorDomain está explícitamente eliminada [SWS_RDS_11294]. Las descripciones de error y el nombre del dominio pueden consultarse mediante los métodos virtuales Message(CodeType) y Name() [SWS_RDS_11295], [SWS_RDS_11296]. La función factoría MakeErrorCode permite crear objetos de error tipados a partir de un código RdsErrc y datos adicionales [SWS_RDS_11299]. Para entornos en los que están habilitadas las excepciones de C++, el módulo proporciona la excepción ara::rds::RdsException [SWS_RDS_11292], [SWS_RDS_11327], la cual puede lanzarse a través de RdsErrorDomain::ThrowAsException [SWS_RDS_11297].

Más evidencia detallada

La arquitectura y las interfaces de RDS están ancladas en los documentos centrales de especificación de AUTOSAR. La definición funcional de las interfaces de C++ para flujos basados en IP y mecanismos de error se basa en AUTOSAR_AP_SWS_RawDataStream [SWS_RDS_10482], [SWS_RDS_11312], [SWS_RDS_12367]. Los modelos de arquitectura, diseños de clases y escenarios de secuencia para el streaming IEEE 1722 están documentados en AUTOSAR_AP_EXP_SWArchitecture AUTOSAR_AP_EXP_SWArchitecture p. 74, AUTOSAR_AP_EXP_SWArchitecture p. 203, AUTOSAR_AP_EXP_SWArchitecture p. 221. El modelado formal de las interfaces y del despliegue se lleva a cabo mediante AUTOSAR_AP_TPS_ManifestSpecification AUTOSAR_AP_TPS_ManifestSpecification p. 254, AUTOSAR_AP_TPS_ManifestSpecification p. 851, así como las plantillas de sistema subyacentes para conexiones de transporte Ethernet en AUTOSAR_CP_TPS_SystemTemplate AUTOSAR_CP_TPS_SystemTemplate p. 705.