Diagnostica

La piattaforma SDV fornisce un insieme di API da utilizzare tra i bundle di servizi Diagnostics Manager e SDV forniti dall'OEM, nonché utilità e funzionalità generali della piattaforma per supportare i casi d'uso di diagnostica dell'OEM. La diagnostica è essenziale per gli sforzi relativi ai veicoli definiti dal software, ai servizi automobilistici e alle tecnologie che forniamo agli OEM perché lo stack di diagnostica è un componente essenziale di qualsiasi sistema operativo per il settore auto e motori.

Gli OEM eseguono il deployment di istanze di Diagnostics Manager (in genere una per ECU o una per VM) per gestire le richieste dei client di diagnostica comunicando con i bundle di servizi SDV sul sistema. A questo scopo, SDV fornisce un insieme di API di diagnostica, utilità e supporto della piattaforma standard per i casi d'uso della diagnostica OEM. Il nostro obiettivo è:

  • Consente agli OEM di implementare Diagnostics Manager in conformità allo standard UDS.
  • Consente a Diagnostics Manager di delegare le richieste dei tester ai bundle di servizi SDV.
  • Consenti ai bundle di servizi SDV di esporre i dati di diagnostica in modo indipendente dal veicolo.

A questo scopo, SDV fornisce un insieme di API per standardizzare le interazioni tra i bundle di servizi SDV (potenzialmente forniti da terze parti) e l'implementazione dello stack di diagnostica dell'OEM.

Stack di diagnostica

Figura 1. Stack di diagnostica.

I bundle di servizi SDV possono esporre dati ed entità di diagnostica, implementare funzionalità di diagnostica e segnalare malfunzionamenti a Diagnostics Manager.

Fornendo un'API di diagnostica standard per l'intero SDV, semplifichiamo l'implementazione dei bundle di servizi SDV, evitando la necessità di reimplementare la diagnostica per l'esecuzione su diversi veicoli di diversi OEM.

API Diagnostics Services

L'API SDV Diagnostics definisce i seguenti servizi, che corrispondono a servizi UDS (ISO 14229-1) specifici:

  • service AuthenticationService: 0x29 (autenticazione). Fornisce un meccanismo per consentire al client di dimostrare la propria identità per accedere a dati o servizi con accesso limitato.
  • service DataItemService: 0x22 (ReadDataByIdentifier) e 0x2E (WriteDataByIdentifier). Consente di leggere e scrivere elementi di dati identificati dai DID.
  • service EcuResetService: 0x11 (ECUReset). Consente al tester di richiedere un ripristino della centralina elettronica.
  • service FileTransferService: 0x34 (RequestDownload), 0x35 (RequestUpload), 0x36 (TransferData), 0x37 (RequestTransferExit) e 0x38 (RequestFileTransfer). Gestisce l'avvio e l'elaborazione dei download e dei caricamenti di file.
  • service IoControlService: 0x2F (InputOutputControlByIdentifier). Consente ai tester esterni di controllare gli input e gli output del sistema a scopo di test.
  • service RoutineControlService: 0x31 (RoutineControl). Consente al tester di avviare, interrompere e richiedere i risultati di routine (funzioni) specifiche implementate dai servizi SDV.
  • service SecurityAccessService: 0x27 (SecurityAccess). Gestisce lo scambio di seed e chiavi necessario per sbloccare livelli di sicurezza specifici.

L'API SDV Diagnostics definisce inoltre service FaultListenerService e message Event in base a Diagnostic Event Manager (AUTOSAR_SWS_DiagnosticEventManager) di AUTOSAR, che consente alle applicazioni di segnalare eventi di diagnostica e malfunzionamenti.

Inoltre, service DiagnosticsManagerService definisce un servizio della piattaforma SDV che consente ad altri servizi di eseguire query sui parametri di connessione diagnostica correnti (indirizzo di origine, indirizzo di destinazione) e sul tipo di sessione.

Guida per gli sviluppatori sui bundle di servizi

In qualità di sviluppatore di bundle di servizi, diagnostics_declaration e i seguenti server possono essere definiti nel file .vsidl corrispondente:

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 {
            ...
        }
    }
    ...
}

Il messaggio DiagnosticsDeclaration è definito come:

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 il blocco precedente (service_bundle contenente diagnostics_declaration) è definito nei cataloghi, vsidl_rc_generator genera i target prebuilt_etc per ogni pacchetto di servizi che dichiara i server precedenti 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,
}

Questi target DEVONO essere aggiunti al prebuilts del blocco di definizione apex corrispondente, come indicato dal blocco di commenti generato automaticamente corrispondente sopra il blocco prebuilt_etc {}:

apex {
    name: "<APEX-NAME>",
    ...
    prebuilts: [
        ...
        "<APEX-NAME>.<BUNDLE-NAME>-diag-config.binpb",
        ...
    ],
    ...
}

Devi anche aggiungere questi target nel campo diagnostics_config_path della voce sdv_service_bundle_metadata del bundle del file sdv_service_bundles_manifest.textproto corrispondente. Inoltre, devi specificare le policy di autorizzazione per abilitare la comunicazione RPC tra il bundle di servizi e il servizio di gestione della diagnostica:

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"
  ...
}

Le autorizzazioni nel file permissions.textproto devono definire i ruoli client o server. Ad esempio, se il pacchetto di servizi implementa un elemento di dati di diagnostica:

server {
    service: "com.sdv.google.diagnostics.data_item.DataItemService"
    allow_all_channels: true
}

Guida per gli sviluppatori della piattaforma

In qualità di sviluppatori di piattaforme, gli OEM DEVONO implementare una destinazione rust_binary Diagnostics Manager Agent:

rust_binary {
    name: "<DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>",
    ...
    product_specific: true,
    ...
}

Inoltre, nei file di build, la seguente variabile deve essere impostata/sovrascritta: SDV_DIAGNOSTICS_AGENT_MODULE := <DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>

Per comodità, la libreria libsdv_uds_serde_v1 può essere utilizzata per la traduzione Proto ↔ UDS e la libreria del provider VSIDL per la reflection.

Il file .vsidl dell'agente di diagnostica deve contenere quanto segue:

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"
    }
}

Poiché l'agente Diagnostics Manager è un eseguibile binario, il sdv_service_bundle_metadata del bundle è definito come dichiarazione solo di configurazione:

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"
}

I criteri di autorizzazione dell'agente di diagnostica devono definire le autorizzazioni per i servizi con cui interagisce. Ad esempio, se chiama il servizio di trasferimento file:

client {
    service: "com.sdv.google.diagnostics.file_transfer.FileTransferService"
    allow_all_channels: true
}