módulo ara::rds — Raw Data Streams

O cluster adaptativo Raw Data Stream (RDS) destina-se à transferência otimizada em termos de latência e throughput de fluxos de dados não estruturados, bem como de dados críticos em termos de tempo de sensores e multimédia, contornando sobrecargas de serialização orientadas a serviços AUTOSAR_AP_EXP_SWArchitecture p. 74. Disponibiliza APIs C++ para fluxos de bytes ponto a ponto baseados em IP (TCP/UDP), bem como para streaming de camada 2 de acordo com o padrão AVTP IEEE 1722 [SWS_RDS_10482], [SWS_RDS_90312]. Ambas as formas de comunicação operam estritamente por meio de métodos estáticos de factory e reportam erros de forma eficiente em termos de recursos através do construto Result disponível em toda a plataforma [SWS_RDS_12367].

mais ›

O cluster funcional Raw Data Stream (RDS) disponibiliza interfaces de alto desempenho para a transmissão de fluxos de bytes não formatados e dados de sensores críticos em termos de tempo para a AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_SWArchitecture p. 73. Através da abstração direta de sockets de rede POSIX, bem como de interfaces Ethernet de camada 2, o RDS contorna a dispendiosa serialização da comunicação orientada a serviços padrão (ara::com) AUTOSAR_AP_EXP_SWArchitecture p. 74.

Para fluxos de bytes baseados em IP através de TCP ou UDP, as aplicações utilizam as classes RawDataStreamClient e RawDataStreamServer, que são associadas a portas modeladas através de métodos estáticos Create [SWS_RDS_10482], [SWS_RDS_11312]. Após o estabelecimento da ligação via Connect ou WaitForConnection, os volumes de dados são trocados sem cópias desnecessárias de memória por meio de std::unique_ptr<ara::core::Byte[]> através de ReadData e WriteData [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11301].

Diagrama de sequência: Estabelecimento de ligação, troca de dados e terminação em Raw Data Streams baseados em IP. Fontes: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10486], [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322]

Para fluxos de dados determinísticos em tempo real a partir de câmaras ou fontes de áudio, o RDS implementa classes em conformidade com o IEEE 1722 (AVTP), tais como IEEE1722RawDataStreamProducer e IEEE1722RawDataStreamConsumer [SWS_RDS_90312], [SWS_RDS_90323]. Classes de subtipo específicas, como RVF (vídeo), AAF (áudio) e CRF (referência de relógio), encapsulam aqui cabeçalhos de frame e dados úteis em conformidade com o padrão [SWS_RDS_90262], [SWS_RDS_90276], [SWS_RDS_90295].

Os erros são sinalizados em conformidade com a plataforma, sem exceções de C++, através de ara::core::Result e do domínio de erro RdsErrorDomain com códigos de erro específicos (RdsErrc) [SWS_RDS_11298], [SWS_RDS_12367]. No manifesto AUTOSAR, a definição da interface é vinculada de forma transparente a endpoints Ethernet através de RawDataStreamClientMapping e RawDataStreamServerMapping AUTOSAR_AP_TPS_ManifestSpecification p. 851.

mais ›

Enquadramento arquitetural e limites do sistema

O cluster funcional Raw Data Stream (RDS) da AUTOSAR Adaptive Platform disponibiliza interfaces de programação (APIs) padronizadas para a transferência de alto desempenho de fluxos de dados não estruturados ou críticos em tempo real AUTOSAR_AP_EXP_SWArchitecture p. 73. Em contraste com a comunicação fortemente tipada e orientada a serviços através de ServiceInterfaces (como SOME/IP ou DDS), o RDS contorna completamente o overhead de protocolo e de serialização de ara::com AUTOSAR_AP_EXP_SWArchitecture p. 74. Isto permite a ligação apta para tempo real e com throughput otimizado de sensores de banda larga, como câmaras de vídeo, sensores de radar e LiDAR ou sistemas de áudio, diretamente a Adaptive Applications AUTOSAR_AP_EXP_SWArchitecture p. 61.

Do ponto de vista arquitetural, o módulo divide-se em dois pilares fundamentais de comunicação: por um lado, a transmissão de fluxos de bytes baseada em IP através de protocolos de transporte como TCP ou UDP, sob encapsulamento de sockets POSIX e proteção opcional por TLS/IPsec AUTOSAR_SWS_CommunicationManagement p. 58. Por outro lado, o módulo oferece um subsistema especializado para streaming de camada 2 de acordo com o IEEE 1722 (Audio Video Transport Protocol, AVTP) através de redes Ethernet e Time-Sensitive Networking (TSN) AUTOSAR_AP_EXP_SWArchitecture p. 74. Ambas as formas de comunicação abstraem estruturas de rede e de buffer específicas do sistema por trás de classes C++ uniformes no namespace ara::rds AUTOSAR_AP_SWS_RawDataStream p. 39.

Instanciação e gestão de ligações

A criação de endpoints de comunicação no RDS ocorre estritamente por meio de métodos estáticos de factory vinculados a instâncias de porta modeladas [SWS_RDS_10482]. Para fluxos de bytes baseados em IP, as classes ara::rds::RawDataStreamClient e ara::rds::RawDataStreamServer encapsulam as funções de iniciador e listener AUTOSAR_AP_EXP_SWArchitecture p. 73. A factory RawDataStreamClient::Create instancia um endpoint de cliente para uma porta definida no manifesto de forma thread-safe através de um ara::core::InstanceSpecifier [SWS_RDS_10482]. De forma análoga, RawDataStreamServer::Create cria a respetiva instância de endpoint de servidor [SWS_RDS_11312]. Ambas as classes proíbem construtores de cópia e atribuições por cópia, mas suportam explicitamente semânticas de movimentação para uma posse inequívoca de recursos [SWS_RDS_11303], [SWS_RDS_11305], [SWS_RDS_11316], [SWS_RDS_11314].

Após uma inicialização bem-sucedida, o servidor aguarda ligações de entrada de forma bloqueante ou com um timeout especificado através de WaitForConnection [SWS_RDS_11318], [SWS_RDS_11319]. O cliente, por sua vez, estabelece a ligação ativamente por meio de Connect, opcionalmente sem limite de tempo ou dentro de um intervalo de tempo em milissegundos [SWS_RDS_10484], [SWS_RDS_11307]. O encerramento de uma sessão ativa ocorre ou deterministicamente através da chamada de Shutdown [SWS_RDS_10485], [SWS_RDS_11320] ou implicitamente no âmbito da chamada do destrutor, o qual fecha e liberta automaticamente uma ligação ainda aberta [SWS_RDS_10483], [SWS_RDS_11313].

Diagrama de sequência: Estabelecimento de ligação, troca bidirecional de dados e terminação entre RawDataStreamClient e RawDataStreamServer. Fontes: [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 uma ligação Raw Data Stream. Fontes: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10485], [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11318], [SWS_RDS_11320]

Troca não estruturada de dados IP através de sockets

A transferência de dados para ligações IP é concebida de forma bidirecional e ocorre através de operações síncronas com monitorização opcional de timeout [SWS_RDS_10486], [SWS_RDS_11309]. No lado do recetor, a operação ReadData devolve uma estrutura de dados do tipo ara::rds::ReadDataResult [SWS_RDS_10486], [SWS_RDS_11322]. Esta estrutura encapsula os dados binários lidos sob a forma de um smart pointer data (std::unique_ptr<ara::core::Byte[]>) e indica através do campo numberOfBytes o número efetivo de bytes recebidos [SWS_RDS_11301], [SWS_RDS_11302]. Por meio desta transferência da posse do buffer, evitam-se cópias desnecessárias de memória.

Para o envio de dados binários, as aplicações passam igualmente o buffer de bytes por meio de semântica de movimentação através de um std::unique_ptr<ara::core::Byte[]> e especificam o comprimento máximo maxLength em WriteData [SWS_RDS_10487], [SWS_RDS_11324]. No caso de caminhos de rede críticos em termos de latência ou sujeitos a bloqueios, estão disponíveis variantes sobrecarregadas de ReadData e WriteData com indicação explícita de timeout em milissegundos [SWS_RDS_11310], [SWS_RDS_11323], [SWS_RDS_11325]. Desta forma, é possível intercetar deterministicamente a ausência de nós remotos ou congestionamentos de buffers de rede AUTOSAR_AP_EXP_InterfacesGuidelines p. 41.

Streaming em tempo quase real com IEEE 1722 (AVTP)

Para fluxos isócronos e determinísticos de dados multimédia e de sensores, o RDS disponibiliza classes de template especializadas para consumidores e produtores em conformidade com o IEEE 1722 [SWS_RDS_90312], [SWS_RDS_90323]. A classe ara::rds::IEEE1722RawDataStreamConsumer<T> atua como sumidouro de dados e é instanciada através de Create [SWS_RDS_90312]. Por meio de Connect, vincula-se ao fluxo atribuído (com filtragem de MAC multicast, VLAN e ID de fluxo) AUTOSAR_AP_EXP_SWArchitecture p. 203, para ler subsequentemente até maxNumberOfDatagrams datagramas estruturados como std::vector<T> através de ReadData [SWS_RDS_90319], [SWS_RDS_90321]. De forma análoga, ara::rds::IEEE1722RawDataStreamProducer<T> assume a geração e o envio de frames AVTP através de WriteData(std::vector<T>) [SWS_RDS_90323], [SWS_RDS_90330], [SWS_RDS_90332].

Os tipos de datagrama formam uma hierarquia de herança orientada a objetos padronizada AUTOSAR_AP_SWS_RawDataStream p. 39. A base de todos os frames é IEEE1722Datagram com campo de payload data e indicação de comprimento stream_data_length [SWS_RDS_90226], [SWS_RDS_90227], [SWS_RDS_90228]. Derivado deste, IEEE1722DatagramAVTPDUCommonHeaderFields encapsula informações gerais de cabeçalho, tais como avtpStreamDataSubtype, headerSpecific e version de protocolo [SWS_RDS_90230], [SWS_RDS_90231], [SWS_RDS_90232], seguido por IEEE1722DatagramAVTPDUCommonStreamHeaderFields com timestamps (avtp_timestamp), identificação de fluxo (unique_id, mac_address) e números de sequência de pacote (sequenceNum) [SWS_RDS_90235], [SWS_RDS_90237], [SWS_RDS_90240].

Sobre esta base comum assentam especializações de subtipo concretas: IEEE1722DatagramRVF para dados de vídeo em bruto com parâmetros de píxeis, taxa de atualização de fotogramas e informações de linha (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 áudio como PCM ou AES3 (channels_per_frame, bit_depth, aes3_data_type_h) [SWS_RDS_90262], [SWS_RDS_90266], [SWS_RDS_90267], [SWS_RDS_90270]; IEEE1722DatagramCRF para sincronização de relógio e transmissão de relógio através de TSN (base_frequency, timestamp_interval, pull) [SWS_RDS_90295], [SWS_RDS_90297], [SWS_RDS_90302], [SWS_RDS_90303]; bem como IEEE1722Datagram61883_IIDC para transportes de câmaras industriais [SWS_RDS_90245], [SWS_RDS_90260] e IEEE1722DatagramNTSCF para formatos de controlo não críticos em termos de tempo [SWS_RDS_90306], [SWS_RDS_90310].

Diagrama de sequência: Ciclo de interação para streaming de áudio/vídeo IEEE 1722 (produtor e consumidor). Fontes: [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 classes: Hierarquia de herança dos datagramas IEEE 1722 no subsistema ara::rds. Fontes: [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

Metamodelação e deployment de manifesto

No metamodelo de manifesto da AUTOSAR, mantém-se a separação entre a conceção da aplicação e o deployment específico da plataforma AUTOSAR_AP_TPS_ManifestSpecification p. 254. O elemento base abstrato AbstractRawDataStreamInterface especializa PortInterface e ramifica-se nas interfaces concretas RawDataStreamClientInterface e RawDataStreamServerInterface AUTOSAR_AP_TPS_ManifestSpecification p. 254. No nível de deployment, um EthernetRawDataStreamClientMapping ou EthernetRawDataStreamServerMapping associa as portas de software a endpoints de comunicação físicos, como ApApplicationEndpoint, endereços IP e números de porta AUTOSAR_AP_TPS_ManifestSpecification p. 851, TPS_ManifestSpecification p. 850.

O manifesto permite cenários de integração flexíveis para a topologia do sistema: tanto modelos AUTOSAR totalmente formalizados, nos quais o cliente e o servidor estão ligados dentro do mesmo design ARXML AUTOSAR_TPS_ManifestSpecification p. 656, como configurações assimétricas. Nestes cenários assimétricos, apenas o cliente ou apenas o servidor é modelado no modelo, enquanto o respetivo nó remoto é conectado através de credenciais estáticas, como remoteServerConfig ou remoteClientConfig AUTOSAR_TPS_ManifestSpecification p. 660, AUTOSAR_TPS_ManifestSpecification p. 661. Para fluxos AVTP, o EthernetMacRawDataStreamMapping associa portas e processos diretamente a endpoints MAC e priorizações de VLAN AUTOSAR_AP_TPS_ManifestSpecification p. 854, correspondendo às definições do System Template IEEE1722TpConnection, IEEE1722TpAvConnection, IEEE1722TpAafConnection e IEEE1722TpRvfConnection AUTOSAR_CP_TPS_SystemTemplate p. 705, AUTOSAR_CP_TPS_SystemTemplate p. 708, AUTOSAR_CP_TPS_SystemTemplate p. 716.

Diagrama de contexto: Relações do metamodelo AUTOSAR entre Port-Interface, mapeamento e deployment de transporte. Fontes: [SWS_RDS_10482], [SWS_RDS_11312], AUTOSAR_AP_TPS_ManifestSpecification p. 254, AUTOSAR_AP_TPS_ManifestSpecification p. 851, TPS_ManifestSpecification p. 850

Comportamento em caso de erro

O tratamento de erros no RDS segue a abordagem baseada em avaliação de erros da AUTOSAR Adaptive Platform através de ara::core::Result e ara::core::ErrorCode [SWS_RDS_10484], [SWS_RDS_11299]. Todos os métodos da API potencialmente passíveis de falha – entre eles Create, Connect, WaitForConnection, ReadData e WriteData – são declarados como noexcept e reportam códigos de erro através do tipo de retorno ara::core::Result [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_11318]. Os estados de erro específicos do módulo são geridos na enumeração ara::rds::RdsErrc [SWS_RDS_12367], a qual pode ser referenciada através do alias de tipo ara::rds::RdsErrorDomain::Errc [SWS_RDS_11326].

Para esse efeito, o módulo define o domínio de erro RdsErrorDomain, cuja instância é obtida através de GetRdsErrorDomain() [SWS_RDS_11298]. O construtor padrão de RdsErrorDomain foi explicitamente eliminado [SWS_RDS_11294]. As descrições de erro e o nome do domínio podem ser lidos através dos métodos virtuais Message(CodeType) e Name() [SWS_RDS_11295], [SWS_RDS_11296]. A função de fábrica MakeErrorCode permite a criação de objetos de erro tipados a partir de um código RdsErrc e dados adicionais [SWS_RDS_11299]. Para ambientes nos quais as exceções C++ estão ativadas, o módulo disponibiliza a exceção ara::rds::RdsException [SWS_RDS_11292], [SWS_RDS_11327], a qual pode ser lançada através de RdsErrorDomain::ThrowAsException [SWS_RDS_11297].

Evidências mais detalhadas

A arquitetura e as interfaces do RDS estão ancoradas nos documentos centrais de especificação da AUTOSAR. A definição funcional das interfaces C++ para fluxos baseados em IP e mecanismos de erro apoia-se em AUTOSAR_AP_SWS_RawDataStream [SWS_RDS_10482], [SWS_RDS_11312], [SWS_RDS_12367]. Os modelos arquiteturais, designs de classes e cenários de sequência para streaming IEEE 1722 estão documentados em AUTOSAR_AP_EXP_SWArchitecture AUTOSAR_AP_EXP_SWArchitecture p. 74, AUTOSAR_AP_EXP_SWArchitecture p. 203, AUTOSAR_AP_EXP_SWArchitecture p. 221. A modelação formal das interfaces e do deployment é realizada através de AUTOSAR_AP_TPS_ManifestSpecification AUTOSAR_AP_TPS_ManifestSpecification p. 254, AUTOSAR_AP_TPS_ManifestSpecification p. 851 bem como dos templates de sistema subjacentes para ligações de transporte Ethernet em AUTOSAR_CP_TPS_SystemTemplate AUTOSAR_CP_TPS_SystemTemplate p. 705.