O SDV do AAOS oferece uma arquitetura orientada a serviços e centrada em dados. Os usuários interagem com o sistema pela biblioteca de cliente de middleware, com a ajuda da Linguagem de definição de interface de serviços de veículos (VSIDL, na sigla em inglês). Isso oculta detalhes de infraestrutura de baixo nível, permitindo que os desenvolvedores se concentrem em entidades de comunicação e implantação de alto nível.
Modelos de comunicação
A comunicação lógica na SDV é definida por temas e canais.
Tópicos
Os tópicos são usados para comunicação centrada em dados (publicação/assinatura). Em vez de descobrir publishers específicos, os usuários interagem com mensagens publicadas em tópicos nomeados.
- Identificador:um tópico é identificado por uma string exclusiva.
- Tipo de dados:as mensagens publicadas em um tópico são definidas usando protobuf.
- Desacoplamento:os assinantes se preocupam com o tipo de mensagem e o nome do tópico, não com a identidade ou a localização do editor. Vários editores podem publicar no mesmo tópico, permitindo a comunicação de muitos para muitos.
Canais
Os canais são usados para comunicação com base em chamadas de procedimento remoto (RPCs, na sigla em inglês). Os usuários chamam métodos de serviço em um canal específico sem precisar saber qual servidor está processando a solicitação.
- Identificador:um canal é identificado por um nome exclusivo (por exemplo,
main-control). - Tipo de serviço:os serviços RPC são identificados pelo nome de serviço protobuf totalmente qualificado.
- Abstração:o middleware lida com a descoberta da instância de servidor adequada para um determinado serviço e canal.
Implantação e ciclo de vida
As entidades nesta seção definem como o software é empacotado, autorizado e instanciado no ambiente SDV.
Pacote de serviços
Um pacote de serviços é um grupo de lógica de negócios relacionada que tem duas funções principais:
- Unidade de implantação:os pacotes de serviços são implantados como parte de um
pacote SDV, que é um arquivo APEX e a menor
unidade de capacidade de atualização de software.
- Cada pacote de serviços é mapeado de forma exclusiva para um único processo do Linux em uma VM do SDV no tempo de execução e é chamado de instância de pacote de serviços.
- Os pacotes de serviços são referenciados no manifesto do pacote SDV, que contém metadados, incluindo nome e políticas de autorização.
- Unidade de autorização:as permissões são concedidas a todo o pacote de serviços. Um pacote de serviços está autorizado a:
- Publicar ou se inscrever em tópicos específicos (para um determinado tipo de mensagem).
- Atender ou chamar canais específicos (para um determinado tipo de serviço).
Instância do pacote de serviços
Uma instância de pacote de serviços é uma instância carregada no tempo de execução de um pacote de serviços.
- Cada instância de pacote de serviços é rastreada e identificada individualmente pelo SDV Lifecycle Manager (LCM).
- As inicializações de instâncias de pacote de serviços são acionadas pelo orquestrador do SDV e iniciadas e rastreadas pelo LCM do SDV.
Pacote SDV
Um pacote SDV é a menor unidade de capacidade de atualização de software e:
- Um arquivo Android Pony EXpress (APEX).
- Contém um ou mais pacotes de serviços.
- É atualizado de uma só vez, o que significa que todos os pacotes de serviços em um pacote SDV são atualizados de uma só vez.
Todo o código em um pacote SDV vem da mesma fonte de confiança (mesmo editor de software).
Diferentes versões do mesmo pacote SDV podem existir em VMs SDV diferentes.
Detalhes de implementação
As seções a seguir descrevem detalhes da implementação da camada de transporte do SDV.
Contexto: unidades de serviço
Embora os desenvolvedores interajam principalmente com tópicos e canais, as unidades de serviço continuam sendo o mecanismo subjacente para registro e descoberta na pilha de comunicações do SDV.
Uma unidade de serviço representa um único endpoint, como um servidor RPC ou um
publisher. A biblioteca de cliente de middleware (mw::clientlib) processa o
registro e a descoberta dessas unidades de serviço nos bastidores.