La plataforma de SDV proporciona un conjunto de APIs que se pueden usar entre el Administrador de diagnóstico proporcionado por el OEM y los paquetes de servicios de SDV, así como utilidades y capacidades generales de la plataforma para admitir los casos de uso de diagnóstico del OEM. Los diagnósticos son fundamentales para los esfuerzos de SDV, los servicios automotrices y las tecnologías que proporcionamos a los OEM, ya que la pila de diagnósticos es un componente esencial de cualquier sistema operativo automotriz.
Los OEM implementan instancias de Diagnostics Manager (por lo general, una por ECU o una por VM) para controlar las solicitudes de los clientes de diagnóstico comunicándose con los paquetes de servicios del SDV en el sistema. Para ello, SDV proporciona un conjunto de APIs de diagnóstico estándar, utilidades y asistencia general de la plataforma para los casos de uso de diagnóstico de OEM. Nuestro objetivo es:
- Permite que los OEM implementen Diagnostics Manager según el estándar de UDS.
- Permite que Diagnostics Manager delegue solicitudes de verificadores en paquetes de servicios de SDV.
- Permite que los paquetes de servicios de SDV expongan datos de diagnóstico de forma independiente del vehículo.
Para lograrlo, SDV proporciona un conjunto de APIs para estandarizar las interacciones entre los paquetes de servicios de SDV (que potencialmente proporcionan terceros) y la implementación de la pila de diagnóstico del OEM.
Los paquetes de servicios de SDV pueden exponer datos y entidades de diagnóstico, implementar funciones de diagnóstico y registrar fallas en el Administrador de diagnóstico.
Al proporcionar una API de diagnóstico estándar para todo el SDV, simplificamos la implementación de paquetes de servicios de SDV, lo que evita la necesidad de volver a implementar el diagnóstico para que se ejecute en diferentes vehículos de diferentes OEM.
API de Diagnostics Services
La API de SDV Diagnostics define los siguientes servicios, que corresponden a servicios específicos de UDS (ISO 14229-1):
service AuthenticationService: 0x29 (Autenticación). Proporciona un mecanismo para que el cliente demuestre su identidad y acceda a datos o servicios restringidos.service DataItemService: 0x22 (ReadDataByIdentifier) y 0x2E (WriteDataByIdentifier). Permite leer y escribir elementos de datos identificados por DIDs.service EcuResetService: 0x11 (ECUReset). Permite que el verificador solicite un restablecimiento de la ECU.service FileTransferService: 0x34 (RequestDownload), 0x35 (RequestUpload), 0x36 (TransferData), 0x37 (RequestTransferExit) y 0x38 (RequestFileTransfer). Controla el inicio y el procesamiento de las cargas y descargas de archivos.service IoControlService: 0x2F (InputOutputControlByIdentifier). Permite que los verificadores externos controlen las entradas y salidas del sistema con fines de prueba.service RoutineControlService: 0x31 (RoutineControl). Permite que el verificador inicie, detenga y solicite resultados para rutinas (funciones) específicas implementadas por los servicios de SDV.service SecurityAccessService: 0x27 (SecurityAccess). Administra el intercambio de claves y datos de inicialización necesario para desbloquear niveles de seguridad específicos.
La API de SDV Diagnostics también define service FaultListenerService y message Event según el Diagnostic Event Manager de AUTOSAR (AUTOSAR_SWS_DiagnosticEventManager), lo que permite que las aplicaciones informen eventos de diagnóstico y fallas.
Además, service DiagnosticsManagerService define un servicio de plataforma de SDV que permite que otros servicios consulten los parámetros de conexión de diagnóstico actuales (dirección de origen, dirección de destino) y el tipo de sesión.
Guía para desarrolladores de paquetes de servicios
Como desarrollador de paquetes de servicios, diagnostics_declaration y los siguientes servidores se pueden definir en el archivo .vsidl correspondiente:
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 {
...
}
}
...
}
El mensaje DiagnosticsDeclaration se define de la siguiente manera:
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;
}
Si lo anterior (bloque service_bundle que contiene diagnostics_declaration) se define en los catálogos, vsidl_rc_generator genera los destinos prebuilt_etc para cada paquete de servicio que declara los servidores anteriores y 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,
}
Estos destinos SE DEBEN agregar al prebuilts del bloque de definición de apex correspondiente, como se indica en el bloque de comentarios generado automáticamente correspondiente sobre el bloque prebuilt_etc {}:
apex {
name: "<APEX-NAME>",
...
prebuilts: [
...
"<APEX-NAME>.<BUNDLE-NAME>-diag-config.binpb",
...
],
...
}
También debes agregar estos destinos en el campo diagnostics_config_path de la entrada sdv_service_bundle_metadata del paquete del archivo sdv_service_bundles_manifest.textproto correspondiente. Además, debes especificar políticas de autorización para habilitar la comunicación de RPC entre el paquete de servicios y el servicio del administrador 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"
...
}
Los permisos en el archivo permissions.textproto deben definir los roles del cliente o del servidor. Por ejemplo, si el paquete de servicio implementa un elemento de datos de diagnóstico, se debe hacer lo siguiente:
server {
service: "com.sdv.google.diagnostics.data_item.DataItemService"
allow_all_channels: true
}
Guía para desarrolladores de la plataforma
Como desarrollador de la plataforma, los OEM DEBEN implementar un destino rust_binary de Diagnostics Manager Agent:
rust_binary {
name: "<DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>",
...
product_specific: true,
...
}
Además, en los archivos de compilación, se debe establecer o reemplazar la siguiente variable:
SDV_DIAGNOSTICS_AGENT_MODULE := <DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>
Para mayor comodidad, se puede usar la biblioteca libsdv_uds_serde_v1 para la traducción de Proto ↔ UDS y la biblioteca del proveedor de VSIDL para la reflexión.
El archivo .vsidl del agente de diagnóstico debe tener el siguiente contenido:
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"
}
}
Dado que el agente de Diagnostics Manager es un ejecutable binario, el sdv_service_bundle_metadata del paquete se define como una declaración solo de configuración:
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"
}
La política de autorización del agente de diagnóstico debe definir los permisos para los servicios con los que interactúa. Por ejemplo, si llama al servicio de transferencia de archivos:
client {
service: "com.sdv.google.diagnostics.file_transfer.FileTransferService"
allow_all_channels: true
}