La plate-forme SDV fournit un ensemble d'API à utiliser entre le gestionnaire de diagnostics fourni par l'OEM et les packs de services SDV, ainsi que des utilitaires et des fonctionnalités générales de la plate-forme pour prendre en charge les cas d'utilisation des diagnostics de l'OEM. Les diagnostics sont essentiels pour les efforts SDV, les services automobiles et les technologies que nous fournissons aux OEM, car la pile de diagnostics est un composant essentiel de tout système d'exploitation automobile.
Les OEM déploient des instances de gestionnaire de diagnostics (généralement une par ECU ou une par VM) pour gérer les requêtes des clients de diagnostic en communiquant avec les packs de services SDV sur le système. Pour ce faire, SDV fournit un ensemble d'API de diagnostic standard, d'utilitaires et une assistance globale de la plate-forme pour les cas d'utilisation des diagnostics OEM. Notre objectif est le suivant :
- Permettre aux OEM d'implémenter le gestionnaire de diagnostics conformément à la norme UDS.
- Permettre au gestionnaire de diagnostics de déléguer les requêtes de testeur aux packs de services SDV.
- Permettre aux packs de services SDV d'exposer les données de diagnostic de manière indépendante du véhicule.
Pour ce faire, SDV fournit un ensemble d'API permettant de standardiser les interactions entre les packs de services SDV (potentiellement fournis par des tiers) et l'implémentation de la pile de diagnostics par l'OEM.
Les packs de services SDV peuvent exposer des données et des entités de diagnostic, implémenter des fonctionnalités de diagnostic et signaler des dysfonctionnements au gestionnaire de diagnostics.
En fournissant une API de diagnostic standard à l'échelle de SDV, nous simplifions l'implémentation des packs de services SDV, ce qui évite d'avoir à réimplémenter les diagnostics pour qu'ils s'exécutent sur différents véhicules de différents OEM.
API Diagnostics Services
L'API SDV Diagnostics définit les services suivants, qui correspondent à des services UDS (ISO 14229-1) spécifiques :
service AuthenticationService: 0x29 (Authentication). Il fournit un mécanisme permettant au client de prouver son identité pour accéder à des données ou des services restreints.service DataItemService: 0x22 (ReadDataByIdentifier) et 0x2E (WriteDataByIdentifier). Il permet de lire et d'écrire des éléments de données identifiés par des DID.service EcuResetService: 0x11 (ECUReset). Il permet au testeur de demander une réinitialisation de l'ECU.service FileTransferService: 0x34 (RequestDownload), 0x35 (RequestUpload), 0x36 (TransferData), 0x37 (RequestTransferExit) et 0x38 (RequestFileTransfer). Il gère l'initiation et le traitement des téléchargements et des importations de fichiers.service IoControlService: 0x2F (InputOutputControlByIdentifier). Il permet aux testeurs externes de contrôler les entrées et les sorties du système à des fins de test.service RoutineControlService: 0x31 (RoutineControl). Il permet au testeur de démarrer, d'arrêter et de demander les résultats de routines (fonctions) spécifiques implémentées par les services SDV.service SecurityAccessService: 0x27 (SecurityAccess). Il gère l'échange de seed-and-key requis pour déverrouiller des niveaux de sécurité spécifiques.
L'API SDV Diagnostics définit également
service FaultListenerService et message Event en fonction du
gestionnaire d'événements de diagnostic d'AUTOSAR (AUTOSAR_SWS_DiagnosticEventManager), ce qui permet aux
applications de signaler des événements de diagnostic et des dysfonctionnements.
De plus, service DiagnosticsManagerService définit un service de plate-forme SDV qui permet à d'autres services d'interroger les paramètres de connexion de diagnostic actuels (adresse source, adresse cible) et le type de session.
Guide du développeur de packs de services
En tant que développeur de packs de services, diagnostics_declaration et les serveurs suivants peuvent être définis dans le fichier .vsidl correspondant :
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 {
...
}
}
...
}
Le message DiagnosticsDeclaration est défini comme suit :
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 le bloc ci-dessus (service_bundle contenant diagnostics_declaration) est défini dans les catalogues, vsidl_rc_generator génère les cibles prebuilt_etc pour chaque pack de services qui déclare les serveurs et diagnostics_declaration ci-dessus :
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,
}
Ces cibles DOIVENT être ajoutées aux prebuilts du bloc de définition apex correspondant, comme indiqué par le bloc de commentaires généré automatiquement correspondant au-dessus du bloc prebuilt_etc {} :
apex {
name: "<APEX-NAME>",
...
prebuilts: [
...
"<APEX-NAME>.<BUNDLE-NAME>-diag-config.binpb",
...
],
...
}
Vous devez également ajouter ces cibles dans le champ diagnostics_config_path de l'entrée sdv_service_bundle_metadata du pack du fichier sdv_service_bundles_manifest.textproto correspondant. De plus, vous devez spécifier des règles d'autorisation pour activer la communication RPC entre le pack de services et le service de gestionnaire de diagnostics :
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"
...
}
Les autorisations du fichier permissions.textproto doivent définir les rôles client ou serveur. Par exemple, si le pack de services implémente un élément de données de diagnostic :
server {
service: "com.sdv.google.diagnostics.data_item.DataItemService"
allow_all_channels: true
}
Guide du développeur de plate-forme
En tant que développeur de plate-forme, les OEM DOIVENT implémenter une cible rust_binary de l'agent de gestionnaire de diagnostics :
rust_binary {
name: "<DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>",
...
product_specific: true,
...
}
De plus, dans les fichiers de compilation, la variable suivante doit être
définie/remplacée :
SDV_DIAGNOSTICS_AGENT_MODULE := <DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>
Pour plus de commodité, la bibliothèque libsdv_uds_serde_v1 peut être utilisée pour
la traduction Proto ↔ UDS, et la bibliothèque de fournisseur VSIDL pour la réflexion.
Le fichier .vsidl de l'agent de diagnostic doit contenir les éléments suivants :
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"
}
}
Étant donné que l'agent de gestionnaire de diagnostics est un exécutable binaire, le pack's
sdv_service_bundle_metadata est défini comme une déclaration de configuration uniquement :
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 règle d'autorisation de l'agent de diagnostic doit définir les autorisations pour les services avec lesquels il interagit. Par exemple, s'il appelle le service de transfert de fichiers :
client {
service: "com.sdv.google.diagnostics.file_transfer.FileTransferService"
allow_all_channels: true
}