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