Diagnose

Die SDV-Plattform bietet eine Reihe von APIs, die zwischen dem vom OEM bereitgestellten Diagnostics Manager und SDV-Dienstpaketen verwendet werden können. Außerdem stellt sie Dienstprogramme und allgemeine Plattformfunktionen zur Unterstützung der Diagnoseanwendungsfälle von OEMs bereit. Diagnosen sind für die SDV-Initiative, die von uns bereitgestellten Automobildienste und -technologien für OEMs von entscheidender Bedeutung, da der Diagnosestack eine wesentliche Komponente jedes Automobilbetriebssystems ist.

OEMs stellen Diagnostics Manager-Instanzen bereit (in der Regel eine pro Steuergerät oder eine pro VM), um Anfragen von Diagnoseclients zu verarbeiten, indem sie mit den SDV-Dienstpaketen auf dem System kommunizieren. Dazu bietet SDV eine Reihe von Standard-Diagnose-APIs, Dienstprogrammen und allgemeine Plattformunterstützung für Diagnoseanwendungsfälle von OEMs. Unser Ziel ist es:

  • OEMs zu ermöglichen, Diagnostics Manager gemäß dem UDS-Standard zu implementieren.
  • Diagnostics Manager zu ermöglichen, Testeranfragen an SDV-Dienstpakete zu delegieren.
  • SDV-Dienstpaketen zu ermöglichen, Diagnosedaten fahrzeugunabhängig bereitzustellen.

Dazu bietet SDV eine Reihe von APIs, um die Interaktionen zwischen SDV-Dienstpaketen (die möglicherweise von Drittanbietern bereitgestellt werden) und der Implementierung des Diagnosestacks durch den OEM zu standardisieren.

Diagnosestapel

Abbildung 1. Diagnosestack.

SDV-Dienstpakete können Diagnosedaten und -entitäten bereitstellen, Diagnosefunktionen implementieren und Fehlfunktionen an den Diagnostics Manager melden.

Durch die Bereitstellung einer standardmäßigen SDV-weiten Diagnose-API vereinfachen wir die Implementierung von SDV-Dienstpaketen. So müssen Diagnosen nicht neu implementiert werden, um auf verschiedenen Fahrzeugen von verschiedenen OEMs ausgeführt zu werden.

Diagnostics Services API

Die SDV Diagnostics API definiert die folgenden Dienste, die bestimmten UDS-Diensten (ISO 14229-1) entsprechen:

  • service AuthenticationService: 0x29 (Authentifizierung). Dieser Dienst bietet einen Mechanismus, mit dem der Client seine Identität nachweisen kann, um auf eingeschränkte Daten oder Dienste zuzugreifen.
  • service DataItemService: 0x22 (ReadDataByIdentifier) und 0x2E (WriteDataByIdentifier). Dieser Dienst ermöglicht das Lesen und Schreiben von Datenelementen, die durch DIDs identifiziert werden.
  • service EcuResetService: 0x11 (ECUReset). Dieser Dienst ermöglicht es dem Tester, einen Reset des Steuergeräts anzufordern.
  • service FileTransferService: 0x34 (RequestDownload), 0x35 (RequestUpload), 0x36 (TransferData), 0x37 (RequestTransferExit) und 0x38 (RequestFileTransfer). Dieser Dienst verarbeitet die Initiierung und Verarbeitung von Datei-Downloads und ‑Uploads.
  • service IoControlService: 0x2F (InputOutputControlByIdentifier). Dieser Dienst ermöglicht es externen Testern, Ein- und Ausgaben des Systems zu Testzwecken zu steuern.
  • service RoutineControlService: 0x31 (RoutineControl). Dieser Dienst ermöglicht es dem Tester, bestimmte Routinen (Funktionen), die von SDV-Diensten implementiert werden, zu starten und zu beenden sowie Ergebnisse anzufordern.
  • service SecurityAccessService: 0x27 (SecurityAccess). Dieser Dienst verwaltet den Seed-and-Key-Austausch, der zum Entsperren bestimmter Sicherheitsstufen erforderlich ist.

Die SDV Diagnostics API definiert außerdem service FaultListenerService und message Event basierend auf dem Diagnostic Event Manager von AUTOSAR (AUTOSAR_SWS_DiagnosticEventManager), mit dem Anwendungen Diagnoseereignisse und Fehlfunktionen melden können.

Außerdem definiert service DiagnosticsManagerService einen SDV-Plattformdienst, mit dem andere Dienste die aktuellen Diagnoseverbindungsparameter (Quelladresse, Zieladresse) und den Sitzungstyp abfragen können.

Entwicklerleitfaden für Dienstpakete

Als Entwickler von Dienstpaketen können diagnostics_declaration und die folgenden Server in der entsprechenden .vsidl-Datei definiert werden:

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

Die Nachricht DiagnosticsDeclaration ist so definiert:

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

Wenn der oben genannte Block (service_bundle-Block mit diagnostics_declaration) in den Katalogen definiert ist, generiert vsidl_rc_generator die prebuilt_etc-Ziele für jedes Dienstpaket, das die oben genannten Server und diagnostics_declaration deklariert:

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

Diese Ziele MÜSSEN den prebuilts des entsprechenden Apex-Definitionsblocks hinzugefügt werden, wie im entsprechenden automatisch generierten Kommentarblock über dem Block prebuilt_etc {} angegeben:

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

Sie müssen diese Ziele auch im Feld diagnostics_config_path des Eintrags sdv_service_bundle_metadata des Pakets in der entsprechenden Datei sdv_service_bundles_manifest.textproto hinzufügen. Außerdem müssen Sie Autorisierungsrichtlinien angeben, um die RPC-Kommunikation zwischen dem Dienstpaket und dem Diagnostics Manager-Dienst zu ermöglichen:

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

In der Datei permissions.textproto sollten die Client- oder Serverrollen definiert werden. Beispiel: Wenn das Dienstpaket ein Diagnose-Datenelement implementiert:

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

Entwicklerleitfaden für Plattformen

Als Plattformentwickler MÜSSEN OEMs ein rust_binary-Ziel für den Diagnostics Manager-Agenten implementieren:

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

Außerdem muss in den Build-Dateien die folgende Variable festgelegt/überschrieben werden: set/overwritten: SDV_DIAGNOSTICS_AGENT_MODULE := <DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>

Die Bibliothek libsdv_uds_serde_v1 kann für Proto-↔-UDS-Übersetzung und die VSIDL Provider Library für die Reflektion verwendet werden.

Die .vsidl-Datei des Diagnose-Agents sollte folgenden Inhalt haben:

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

Da der Diagnostics Manager-Agent eine binäre ausführbare Datei ist, wird das Paket sdv_service_bundle_metadata als reine Konfigurationsdeklaration definiert:

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

In der Autorisierungsrichtlinie des Diagnose-Agents sollten die Berechtigungen für die Dienste definiert werden, mit denen er interagiert. Beispiel: Wenn er den File Transfer-Dienst aufruft:

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