SDV 平台提供了一组 API，用于 OEM 提供的诊断管理器与 SDV 服务软件包之间，以及用于支持 OEM 诊断用例的实用程序和通用平台功能。诊断对于我们为 OEM 提供的 SDV 工作、汽车服务和技术至关重要，因为诊断堆栈是任何汽车操作系统的重要组成部分。
OEM 会部署诊断管理器实例（通常每个 ECU 或每个虚拟机一个），通过与系统上的 SDV 服务软件包通信来处理诊断客户端的请求。为此，SDV 提供了一组标准诊断 API、实用程序和整体平台支持，以满足 OEM 诊断用例的需求。我们的目标是：
- 让 OEM 能够根据 UDS 标准实现诊断管理器。
- 允许诊断管理器将测试人员请求委托给 SDV 服务软件包。
- 允许 SDV 服务软件包以与车辆无关的方式公开诊断数据。
为此，SDV 提供了一组 API 来标准化 SDV 服务软件包（可能由第三方提供）与 OEM 的诊断堆栈实现之间的交互。
SDV 服务软件包可以公开诊断数据和实体、实现诊断功能，并向诊断管理器报告故障。
通过提供标准化的 SDV 范围诊断 API，我们简化了 SDV 服务包的实现，避免了重新实现诊断以在不同 OEM 的不同车辆上运行的需求。
Diagnostics Services API
SDV Diagnostics API 定义了以下服务，这些服务对应于特定的 UDS (ISO 14229-1) 服务：
service AuthenticationService：0x29（身份验证）。它提供了一种机制，让客户端能够证明自己的身份，从而访问受限数据或服务。service DataItemService：0x22（ReadDataByIdentifier）和 0x2E（WriteDataByIdentifier）。它允许读取和写入由 DID 标识的数据元素。service EcuResetService：0x11 (ECUReset)。它允许测试人员请求重置 ECU。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）。它管理解锁特定安全级别所需的种子和密钥交换。
SDV 诊断 API 还基于 AUTOSAR 的诊断事件管理器 (AUTOSAR_SWS_DiagnosticEventManager) 定义了 service FaultListenerService 和 message Event，从而使应用能够报告诊断事件和故障。
此外，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;
}
如果目录中定义了上述内容（包含 diagnostics_declaration 的 service_bundle 块），则 vsidl_rc_generator 会为每个声明了上述服务器和 diagnostics_declaration 的服务包生成 prebuilt_etc 目标：
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,
}
必须将这些目标添加到相应 apex 定义块的 prebuilts 中，如 prebuilt_etc {} 块上方的相应自动生成的注释块所示：
apex {
name: "<APEX-NAME>",
...
prebuilts: [
...
"<APEX-NAME>.<BUNDLE-NAME>-diag-config.binpb",
...
],
...
}
您还必须在相应 sdv_service_bundles_manifest.textproto 文件的 bundle 的 sdv_service_bundle_metadata 条目的 diagnostics_config_path 字段中添加这些目标。此外，您必须指定授权政策，以在服务软件包和诊断管理器服务之间启用 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
}
平台开发者指南
作为平台开发者，OEM 必须实现诊断管理器代理 rust_binary 目标：
rust_binary {
name: "<DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>",
...
product_specific: true,
...
}
此外，在 build 文件中，必须设置/覆盖以下变量：
SDV_DIAGNOSTICS_AGENT_MODULE := <DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>
为方便起见，libsdv_uds_serde_v1 库可用于 Proto ↔ UDS 转换，而 VSIDL 提供程序库可用于反射。
诊断代理 .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"
}
}
由于诊断管理器代理是一个二进制可执行文件，因此软件包的 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
}