Платформа SDV предоставляет набор API для взаимодействия между предоставляемым OEM-производителем менеджером диагностики и пакетами услуг SDV, а также утилиты и общие возможности платформы для поддержки сценариев использования диагностики OEM-производителями. Диагностика имеет важное значение для усилий SDV, автомобильных услуг и технологий, которые мы предоставляем OEM-производителям, поскольку диагностический стек является неотъемлемой частью любой автомобильной операционной системы.
Производители оригинального оборудования (OEM) развертывают экземпляры Diagnostics Manager (обычно по одному на каждый ЭБУ или на каждую виртуальную машину) для обработки запросов от диагностических клиентов путем взаимодействия с пакетами служб SDV в системе. Для этого SDV предоставляет набор стандартных API-интерфейсов диагностики, утилит и общую поддержку платформы для сценариев использования диагностики OEM-производителями. Наша цель:
- Предоставить производителям оборудования возможность внедрять Diagnostics Manager в соответствии со стандартом UDS.
- Разрешите Diagnostics Manager делегировать запросы тестировщиков пакетам служб SDV.
- Разрешить пакетам услуг SDV предоставлять диагностические данные независимо от типа транспортного средства.
Для достижения этой цели SDV предоставляет набор API для стандартизации взаимодействия между пакетами услуг SDV (потенциально предоставляемыми сторонними разработчиками) и реализацией диагностического стека производителем оборудования.

Пакеты сервисов SDV могут предоставлять доступ к диагностическим данным и объектам, реализовывать диагностические функции и сообщать о неисправностях менеджеру диагностики.
Предоставляя стандартный API для диагностики в рамках всей системы SDV, мы упрощаем внедрение пакетов услуг SDV, избегая необходимости повторной разработки диагностических средств для работы на различных автомобилях от разных производителей.
API диагностических служб
API SDV Diagnostics определяет следующие сервисы, которые соответствуют определенным сервисам UDS (ISO 14229-1):
-
service AuthenticationService: 0x29 (Аутентификация). Он предоставляет клиенту механизм для подтверждения своей личности с целью доступа к ограниченным данным или услугам. -
service DataItemService: 0x22 (ReadDataByIdentifier) и 0x2E (WriteDataByIdentifier). Он позволяет читать и записывать элементы данных, идентифицированные по DID. -
service EcuResetService: 0x11 (ECUReset). Позволяет тестировщику запросить сброс ЭБУ. -
service FileTransferService: 0x34 (RequestDownload), 0x35 (RequestUpload), 0x36 (TransferData), 0x37 (RequestTransferExit) и 0x38 (RequestFileTransfer). Он отвечает за инициирование и обработку загрузки и выгрузки файлов. -
service IoControlService: 0x2F (InputOutputControlByIdentifier). Он позволяет внешним тестировщикам управлять входами и выходами системы в целях тестирования. -
service RoutineControlService: 0x31 (RoutineControl). Он позволяет тестировщику запускать, останавливать и запрашивать результаты для конкретных подпрограмм (функций), реализованных сервисами SDV. -
service SecurityAccessService: 0x27 (SecurityAccess). Он управляет обменом начальным значением и ключом, необходимым для разблокировки определенных уровней безопасности.
API диагностики SDV дополнительно определяет service FaultListenerService и message Event на основе менеджера диагностических событий AUTOSAR ( AUTOSAR_SWS_DiagnosticEventManager ), что позволяет приложениям сообщать о диагностических событиях и неисправностях.
Кроме того, service DiagnosticsManagerService определяет службу платформы SDV, которая позволяет другим службам запрашивать текущие параметры диагностического соединения (адрес источника, адрес цели) и тип сессии.
Руководство разработчика пакета услуг
Разработчику пакетов сервисов можно указать в соответствующем файле .vsidl следующие серверы: diagnostics_declaration и другие.
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 {
...
}
}
...
}
Сообщение DiagnosticsDeclaration определяется следующим образом:
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;
}
Если указанный выше блок service_bundle содержащий diagnostics_declaration , определен в каталогах, vsidl_rc_generator генерирует цели prebuilt_etc для каждого пакета служб, который объявляет указанные выше серверы и 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,
}
Эти цели ДОЛЖНЫ быть добавлены в prebuilts блоки соответствующего определения Apex, как указано в соответствующем автоматически сгенерированном блоке комментариев над блоком prebuilt_etc {} :
apex {
name: "<APEX-NAME>",
...
prebuilts: [
...
"<APEX-NAME>.<BUNDLE-NAME>-diag-config.binpb",
...
],
...
}
Также необходимо добавить эти цели в поле diagnostics_config_path записи sdv_service_bundle_metadata пакета в соответствующем файле sdv_service_bundles_manifest.textproto . Кроме того, необходимо указать политики авторизации для обеспечения RPC-связи между пакетом служб и службой управления диагностикой:
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"
...
}
Права доступа в файле permissions.textproto должны определять роли клиента или сервера. Например, если пакет сервиса реализует элемент диагностических данных:
server {
service: "com.sdv.google.diagnostics.data_item.DataItemService"
allow_all_channels: true
}
Руководство для разработчиков платформы
Разработчики платформ ОБЯЗАНЫ внедрить целевой объект rust_binary для агента Diagnostics Manager:
rust_binary {
name: "<DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>",
...
product_specific: true,
...
}
Кроме того, в файлах сборки необходимо установить/переопределить следующую переменную: SDV_DIAGNOSTICS_AGENT_MODULE := <DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>
Для удобства можно использовать библиотеку libsdv_uds_serde_v1 для преобразования Proto ↔ UDS, а библиотеку VSIDL Provider Library — для рефлексии.
Файл диагностического агента .vsidl должен содержать следующее:
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"
}
}
Поскольку агент Diagnostics Manager представляет собой исполняемый двоичный файл, параметр sdv_service_bundle_metadata пакета определяется как объявление, содержащее только конфигурацию:
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"
}
Политика авторизации диагностического агента должна определять разрешения для служб, с которыми он взаимодействует. Например, если он вызывает службу передачи файлов:
client {
service: "com.sdv.google.diagnostics.file_transfer.FileTransferService"
allow_all_channels: true
}