Diagnostyka

Platforma SDV udostępnia zestaw interfejsów API do użytku między dostarczonym przez producenta OEM menedżerem diagnostyki a pakietami usług SDV, a także narzędzia i ogólne możliwości platformy, które obsługują przypadki użycia diagnostyki przez producenta OEM. Diagnostyka jest niezbędna w przypadku działań SDV, usług motoryzacyjnych i technologii, które udostępniamy producentom OEM, ponieważ stos diagnostyczny jest podstawowym komponentem każdego motoryzacyjnego systemu operacyjnego.

Producenci OEM wdrażają instancje menedżera diagnostyki (zwykle jedną na ECU lub jedną na maszynę wirtualną), aby obsługiwać żądania klientów diagnostyki przez komunikację z pakietami usług SDV w systemie. W tym celu SDV udostępnia zestaw standardowych interfejsów API diagnostyki, narzędzi i ogólnej obsługi platformy w zakresie przypadków użycia diagnostyki przez producenta OEM. Naszym celem jest:

  • umożliwienie producentom OEM wdrożenia menedżera diagnostyki zgodnie ze standardem UDS;
  • umożliwienie menedżerowi diagnostyki delegowania żądań testera do pakietów usług SDV;
  • umożliwienie pakietom usług SDV udostępniania danych diagnostycznych w sposób niezależny od pojazdu.

Aby to osiągnąć, SDV udostępnia zestaw interfejsów API, które standaryzują interakcje między pakietami usług SDV (potencjalnie dostarczanymi przez firmy zewnętrzne) a implementacją stosu diagnostycznego producenta OEM.

Stos diagnostyczny

Rysunek 1. Stos diagnostyczny.

Pakiety usług SDV mogą udostępniać dane i encje diagnostyczne, implementować funkcje diagnostyczne i zgłaszać awarie do menedżera diagnostyki.

Dzięki udostępnieniu standardowego interfejsu API diagnostyki SDV upraszczamy implementację pakietów usług SDV, co eliminuje konieczność ponownego wdrażania diagnostyki w celu uruchamiania jej w różnych pojazdach różnych producentów OEM.

Interfejs API usług diagnostycznych

Interfejs SDV Diagnostics API definiuje te usługi, które odpowiadają konkretnym usługom UDS (ISO 14229-1):

  • service AuthenticationService: 0x29 (Authentication). Umożliwia klientowi udowodnienie swojej tożsamości w celu uzyskania dostępu do danych lub usług o ograniczonym dostępie.
  • service DataItemService: 0x22 (ReadDataByIdentifier) i 0x2E (WriteDataByIdentifier). Umożliwia odczytywanie i zapisywanie elementów danych identyfikowanych przez identyfikatory DID.
  • service EcuResetService: 0x11 (ECUReset). Umożliwia testerowi wysłanie prośby o zresetowanie ECU.
  • service FileTransferService: 0x34 (RequestDownload), 0x35 (RequestUpload), 0x36 (TransferData), 0x37 (RequestTransferExit) i 0x38 (RequestFileTransfer). Obsługuje inicjowanie i przetwarzanie pobierania i przesyłania plików.
  • service IoControlService: 0x2F (InputOutputControlByIdentifier). Umożliwia zewnętrznym testerom kontrolowanie wejść i wyjść systemu na potrzeby testowania.
  • service RoutineControlService: 0x31 (RoutineControl). Umożliwia testerowi uruchamianie, zatrzymywanie i wysyłanie próśb o wyniki określonych procedur (funkcji) zaimplementowanych przez usługi SDV.
  • service SecurityAccessService: 0x27 (SecurityAccess). Zarządza wymianą klucza i ziarna wymaganą do odblokowania określonych poziomów bezpieczeństwa.

Interfejs SDV Diagnostics API definiuje też service FaultListenerService i message Event na podstawie menedżera zdarzeń diagnostycznych AUTOSAR (AUTOSAR_SWS_DiagnosticEventManager), co umożliwia aplikacjom zgłaszanie zdarzeń diagnostycznych i awarii.

Dodatkowo service DiagnosticsManagerService definiuje usługę platformy SDV, która umożliwia innym usługom wysyłanie zapytań o bieżące parametry połączenia diagnostycznego (adres źródłowy, adres docelowy) i typ sesji.

Przewodnik dla programistów dotyczący pakietu usług

Jako programista pakietu usług możesz zdefiniować w odpowiednim pliku .vsidl element diagnostics_declaration i te serwery:

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

Komunikat DiagnosticsDeclaration jest zdefiniowany w ten sposób:

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

Jeśli powyższy blok (service_bundle zawierający diagnostics_declaration) jest zdefiniowany w katalogach, vsidl_rc_generator generuje cele prebuilt_etc dla każdego pakietu usług, który deklaruje powyższe serwery i 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,
}

Te cele MUSZĄ zostać dodane do prebuilts odpowiedniego bloku definicji apex zgodnie ze wskazaniami w odpowiednim automatycznie wygenerowanym bloku komentarzy nad blokiem prebuilt_etc {}:

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

Musisz też dodać te cele w polu diagnostics_config_path wpisu sdv_service_bundle_metadata pakietu w odpowiednim pliku sdv_service_bundles_manifest.textproto. Dodatkowo musisz określić zasady autoryzacji, aby włączyć komunikację RPC między pakietem usług a usługą menedżera diagnostyki:

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

Uprawnienia w pliku permissions.textproto powinny definiować role klienta lub serwera. Jeśli na przykład pakiet usług implementuje element danych diagnostycznych:

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

Przewodnik dla programistów dotyczący platformy

Jako programista platformy producenci OEM MUSZĄ zaimplementować cel rust_binary agenta menedżera diagnostyki:

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

Dodatkowo w plikach kompilacji należy ustawić lub zastąpić tę zmienną: SDV_DIAGNOSTICS_AGENT_MODULE := <DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>

Dla wygody do tłumaczenia Proto ↔ UDS można używać biblioteki libsdv_uds_serde_v1, a do odbicia – biblioteki VSIDL Provider Library.

Plik .vsidl agenta diagnostyki powinien zawierać te treści:

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

Ponieważ agent menedżera diagnostyki jest plikiem wykonywalnym, pakietu sdv_service_bundle_metadata jest zdefiniowany jako deklaracja tylko do konfiguracji:

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

Zasady autoryzacji agenta diagnostyki powinny definiować uprawnienia do usług, z którymi agent wchodzi w interakcje. Jeśli na przykład wywołuje usługę przesyłania plików:

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