A plataforma SDV oferece um conjunto de APIs para serem usadas entre o Diagnostics Manager fornecido pelo OEM e os pacotes de serviços SDV, além de utilitários e recursos gerais da plataforma para oferecer suporte aos casos de uso de diagnóstico do OEM. Os diagnósticos são essenciais para os esforços de SDV, serviços automotivos e tecnologias que oferecemos aos OEMs porque a pilha de diagnóstico é um componente essencial de qualquer sistema operacional automotivo.
Os OEMs implantam instâncias do Diagnostics Manager (geralmente uma por ECU ou uma por VM) para processar solicitações de clientes de diagnóstico comunicando-se com os pacotes de serviços SDV no sistema. Para isso, o SDV oferece um conjunto de APIs de diagnóstico padrão, utilitários e suporte geral da plataforma para casos de uso de diagnóstico de OEM. Nosso objetivo é:
- Permitir que os OEMs implementem o Diagnostics Manager de acordo com o padrão UDS.
- Permite que o Diagnostics Manager delegue solicitações de teste a pacotes de serviços do SDV.
- Permite que pacotes de serviços SDV exponham dados de diagnóstico de maneira independente do veículo.
Para isso, o SDV fornece um conjunto de APIs para padronizar as interações entre pacotes de serviços do SDV (potencialmente fornecidos por terceiros) e a implementação da pilha de diagnóstico do OEM.
Os pacotes de serviços SDV podem expor dados e entidades de diagnóstico, implementar funcionalidades de diagnóstico e informar sobre falhas ao Gerenciador de diagnóstico.
Ao fornecer uma API de diagnóstico padrão em toda a SDV, simplificamos a implementação de pacotes de serviços da SDV, evitando a necessidade de reimplementar diagnósticos para execução em diferentes veículos de diferentes OEMs.
API Diagnostics Services
A API SDV Diagnostics define os seguintes serviços, que correspondem a serviços específicos de UDS (ISO 14229-1):
service AuthenticationService: 0x29 (autenticação). Ele oferece um mecanismo para o cliente provar sua identidade e acessar dados ou serviços restritos.service DataItemService: 0x22 (ReadDataByIdentifier) e 0x2E (WriteDataByIdentifier). Ela permite ler e gravar elementos de dados identificados por DIDs.service EcuResetService: 0x11 (ECUReset). Ele permite que o testador solicite uma redefinição da ECU.service FileTransferService: 0x34 (RequestDownload), 0x35 (RequestUpload), 0x36 (TransferData), 0x37 (RequestTransferExit) e 0x38 (RequestFileTransfer). Ele lida com o início e o processamento de downloads e uploads de arquivos.service IoControlService: 0x2F (InputOutputControlByIdentifier). Ele permite que testadores externos controlem entradas e saídas do sistema para fins de teste.service RoutineControlService: 0x31 (RoutineControl). Ele permite que o testador inicie, pare e solicite resultados de rotinas (funções) específicas implementadas pelos serviços do SDV.service SecurityAccessService: 0x27 (SecurityAccess). Ele gerencia a troca de sementes e chaves necessária para desbloquear níveis específicos de segurança.
A API SDV Diagnostics também define service FaultListenerService e message Event com base no Diagnostic Event Manager (Gerenciador de eventos de diagnóstico) da AUTOSAR (AUTOSAR_SWS_DiagnosticEventManager), que permite que os aplicativos informem eventos de diagnóstico e falhas.
Além disso, service DiagnosticsManagerService define um serviço de plataforma SDV
que permite que outros serviços consultem os parâmetros atuais de conexão de diagnóstico (endereço de origem, endereço de destino) e o tipo de sessão.
Guia para desenvolvedores sobre pacotes de serviços
Como desenvolvedor de pacotes de serviços, diagnostics_declaration e os
seguintes servidores podem ser definidos no arquivo .vsidl correspondente:
service_bundle {
name: "<BUNDLE-NAME>"
...
server {
service: "com.sdv.google.diagnostics.data_item.DataItemService"
}
server {
service: "com.sdv.google.diagnostics.routine_control.RoutineControlService"
}
server {
service: "com.sdv.google.diagnostics.io_control.IoControlService"
}
server {
service: "com.sdv.google.diagnostics.fault.FaultListenerService"
}
...
diagnostics_declaration {
data_item {
...
}
routine {
...
}
event {
...
}
io_control {
...
}
}
...
}
A mensagem DiagnosticsDeclaration é definida como:
package sdv.diagnostics.v1;
message DiagnosticsDeclaration {
// Diagnostics data item declaration.
//
// See com.sdv.google.diagnostics.data_item.DataItemService service.
message DataItem {
// Required. Id of the data item.
string id = 1;
// Required. Fully qualified name of the message that defines a structure of
// the data item.
string message_name = 2;
// Flag that indicates whether the data item is writable by the Diagnostics
// Manager.
//
// Effectively, this indicates whether the call to DataItemService::Write,
// is supported for this data item id.
bool is_writable = 3;
}
// Declaration of diagnostics data for input/output control.
//
// See com.sdv.google.diagnostics.io_control.IoControl service.
message InputOutputControlData {
// Id of the input/output control data.
string id = 1;
// Fully qualified name of the message that defines a structure of the data.
string message_name = 2;
}
// Declaration of diagnostics routine.
//
// See com.sdv.google.diagnostics.routine_control.RoutineControl.
message Routine {
// Information about routine control method.
message Method {
// Fully qualified name of the request message.
string request = 1;
// Fully qualified name of the response message.
string response = 2;
}
// Id of the routine.
string id = 1;
// Information about routine start method.
//
// See com.sdv.google.diagnostics.routine_control.RoutineControl::Start.
Method start = 2;
// Information about routine stop method.
//
// See com.sdv.google.diagnostics.routine_control.RoutineControl::Stop.
Method stop = 3;
// Information about routine result method.
//
// See
// com.sdv.google.diagnostics.routine_control.RoutineControl::RequestResult.
Method result = 4;
}
// Declaration of diagnostics event and corresponding fault listener.
//
// See com.sdv.google.diagnostics.event.Event.
// See com.sdv.google.diagnostics.fault.FaultListener.
message Event {
// Id of the event.
string id = 1;
// Fully qualified message name of the event's extended data message.
string extended_data_message_name = 2;
// Fault status changes which service wants to be notified of.
//
// See com.sdv.google.diagnostics.fault.FaultListener.StatusMask.
uint32 fault_listener_mask = 3;
// User-defined service unit name of a corresponding event publisher.
string service_unit_name = 4;
}
// Diagnostic data items exposed by the service bundle.
repeated DataItem data_item = 1;
// Diagnostic data exposed for input/output control by the service bundle.
repeated InputOutputControlData io_control = 2;
// Diagnostic routines exposed by the service bundle.
repeated Routine routine = 3;
// Diagnostic events sent by the service bundle.
repeated Event event = 4;
}
Se o bloco acima (service_bundle que contém diagnostics_declaration)
estiver definido nos catálogos,
vsidl_rc_generator vai gerar os
destinos prebuilt_etc para cada pacote de serviços que declarar os servidores acima
e diagnostics_declaration:
prebuilt_etc {
name: "<APEX-NAME>.<BUNDLE-NAME>-diag-config.binpb",
filename: "DiagService-diag-config.binpb",
sub_dir: "vsidl_provider",
src: ":generate_vsidl_files_single_bundle_<APEX-NAME>.<BUNDLE-NAME>{diagnostics-config.binpb}",
installable: false,
}
Essas metas PRECISAM ser adicionadas ao prebuilts do bloco de definição do apex correspondente, conforme indicado pelo bloco de comentários autogerado acima do bloco prebuilt_etc {}:
apex {
name: "<APEX-NAME>",
...
prebuilts: [
...
"<APEX-NAME>.<BUNDLE-NAME>-diag-config.binpb",
...
],
...
}
Também é necessário adicionar esses destinos no campo diagnostics_config_path da entrada sdv_service_bundle_metadata do pacote no arquivo sdv_service_bundles_manifest.textproto correspondente. Além disso, especifique
políticas de autorização para ativar a comunicação RPC entre o pacote de serviços
e o serviço do gerenciador de diagnóstico:
sdv_service_bundle_metadata {
name: "<BUNDLE-NAME>"
...
diagnostics_config_path: "etc/vsidl_provider/<BUNDLE-NAME>-diag-config.binpb"
authorization_policy_path: "etc/authz/permissions.textproto"
...
}
As permissões no arquivo permissions.textproto precisam definir as funções do cliente ou
do servidor. Por exemplo, se o pacote de serviços implementar um item de dados de diagnóstico:
server {
service: "com.sdv.google.diagnostics.data_item.DataItemService"
allow_all_channels: true
}
Guia para desenvolvedores da plataforma
Como desenvolvedores de plataforma, os OEMs PRECISAM implementar um destino
rust_binary do agente do Diagnostics Manager:
rust_binary {
name: "<DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>",
...
product_specific: true,
...
}
Além disso, nos arquivos de build, a seguinte variável precisa ser
definida/substituída:
SDV_DIAGNOSTICS_AGENT_MODULE := <DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>
Para facilitar, a biblioteca libsdv_uds_serde_v1 pode ser usada para tradução de Proto ↔ UDS, e a VSIDL Provider Library para reflexão.
O arquivo do agente de diagnóstico .vsidl precisa ter o seguinte conteúdo:
package: "com.sdv.oem.diagnostics"
service_bundle {
name: "DiagnosticsAgent"
server {
service: "com.sdv.google.diagnostics.DiagnosticsManagerService"
}
client {
service: "com.sdv.google.diagnostics.data_item.DataItemService"
}
client {
service: "com.sdv.google.diagnostics.routine_control.RoutineControlService"
}
client {
service: "com.sdv.google.diagnostics.io_control.IoControlService"
}
client {
service: "com.sdv.google.diagnostics.fault.FaultListenerService"
}
client {
service: "com.sdv.google.diagnostics.ecu_reset.EcuResetService"
}
client {
service: "com.sdv.google.diagnostics.security_access.SecurityAccessService"
}
client {
service: "com.sdv.google.diagnostics.authentication.AuthenticationService"
}
client {
service: "com.sdv.google.diagnostics.file_transfer.FileTransferService"
}
}
Como o agente do Diagnostics Manager é um executável binário, o sdv_service_bundle_metadata do pacote é definido como uma declaração somente de configuração:
sdv_service_bundle_metadata {
# This name must match the agent's Bundle Name
name: "DiagnosticsAgent"
version_number: 1
version_name: "1"
# Reference the manifest itself to mark this as a config-only declaration.
native_library_path: "etc/sdv_service_bundles_manifest.textproto"
authorization_policy_path: "etc/authz/permissions.textproto"
}
A política de autorização do agente de diagnóstico precisa definir as permissões dos serviços com que ele interage. Por exemplo, se ele chamar o serviço de transferência de arquivos:
client {
service: "com.sdv.google.diagnostics.file_transfer.FileTransferService"
allow_all_channels: true
}