تشخیص

پلتفرم SDV مجموعه‌ای از APIها را برای استفاده بین مدیر تشخیص عیب ارائه شده توسط OEM و بسته‌های سرویس SDV، و همچنین ابزارها و قابلیت‌های عمومی پلتفرم را برای پشتیبانی از موارد استفاده تشخیص عیب OEM فراهم می‌کند. تشخیص عیب برای تلاش‌های SDV، خدمات خودرویی و فناوری‌هایی که ما به OEMها ارائه می‌دهیم ضروری است زیرا مجموعه تشخیص عیب، جزء ضروری هر سیستم عامل خودرویی است.

تولیدکنندگان اصلی تجهیزات (OEM) نمونه‌هایی از مدیر تشخیص عیب (Diagnostic Manager) (معمولاً یکی برای هر ECU یا یکی برای هر VM) را برای رسیدگی به درخواست‌های مشتریان تشخیص عیب از طریق ارتباط با بسته‌های سرویس SDV در سیستم، مستقر می‌کنند. برای انجام این کار، SDV مجموعه‌ای از APIهای استاندارد تشخیص عیب، ابزارها و پشتیبانی کلی پلتفرم را برای موارد استفاده از تشخیص عیب OEM ارائه می‌دهد. هدف ما این است که:

  • به تولیدکنندگان اصلی تجهیزات (OEM) این امکان را می‌دهد که Diagnostics Manager را مطابق با استاندارد UDS پیاده‌سازی کنند.
  • به مدیر تشخیص اجازه دهید درخواست‌های آزمایش‌کننده را به بسته‌های سرویس SDV واگذار کند.
  • به بسته‌های خدمات SDV اجازه دهید داده‌های تشخیصی را به روشی مستقل از وسیله نقلیه ارائه دهند.

برای دستیابی به این هدف، SDV مجموعه‌ای از APIها را برای استانداردسازی تعاملات بین بسته‌های خدمات SDV (که به‌طور بالقوه توسط اشخاص ثالث ارائه می‌شوند) و پیاده‌سازی پشته تشخیصی توسط تولیدکننده اصلی تجهیزات (OEM) ارائه می‌دهد.

پشته تشخیصی

شکل ۱. مجموعه ابزارهای تشخیصی.

بسته‌های سرویس SDV می‌توانند داده‌ها و موجودیت‌های تشخیصی را در معرض نمایش قرار دهند، قابلیت‌های تشخیصی را پیاده‌سازی کنند و نقص‌ها را به مدیر تشخیصی گزارش دهند.

با ارائه یک API استاندارد عیب‌یابی در سطح SDV، پیاده‌سازی بسته‌های خدمات SDV را ساده می‌کنیم و از نیاز به پیاده‌سازی مجدد عیب‌یابی برای اجرا روی خودروهای مختلف از تولیدکنندگان اصلی تجهیزات (OEM) مختلف جلوگیری می‌کنیم.

API خدمات تشخیصی

API مربوط به SDV Diagnostics سرویس‌های زیر را تعریف می‌کند که با سرویس‌های خاص UDS (ISO 14229-1) مطابقت دارند:

  • service AuthenticationService : سرویس 0x29 (احراز هویت). این سرویس مکانیزمی را برای کلاینت فراهم می‌کند تا هویت خود را برای دسترسی به داده‌ها یا سرویس‌های محدود شده اثبات کند.
  • service DataItemService : 0x22 (شناسه خواندن داده با شناسه) و 0x2E (شناسه نوشتن داده با شناسه). این سرویس امکان خواندن و نوشتن عناصر داده‌ای شناسایی‌شده توسط 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). این سرویس، تبادل کلید اولیه (seed-and-key) مورد نیاز برای باز کردن سطوح امنیتی خاص را مدیریت می‌کند.

رابط برنامه‌نویسی کاربردی SDV Diagnostics علاوه بر این، service FaultListenerService و message Event بر اساس مدیر رویداد تشخیصی AUTOSAR ( AUTOSAR_SWS_DiagnosticEventManager ) تعریف می‌کند که به برنامه‌ها امکان می‌دهد رویدادها و نقص‌های تشخیصی را گزارش دهند.

علاوه بر این، service DiagnosticsManagerService یک سرویس پلتفرم SDV تعریف می‌کند که به سایر سرویس‌ها اجازه می‌دهد پارامترهای اتصال عیب‌یابی فعلی (آدرس منبع، آدرس هدف) و نوع جلسه را جستجو کنند.

راهنمای توسعه‌دهندگان بسته خدماتی

به عنوان یک توسعه‌دهنده بسته سرویس، diagnostics_declaration و سرورهای زیر را می‌توان در فایل .vsidl مربوطه تعریف کرد:

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 بلوک تعریف رأس مربوطه، همانطور که توسط بلوک نظر تولید شده خودکار مربوطه در بالای بلوک 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
}

راهنمای توسعه‌دهندگان پلتفرم

به عنوان یک توسعه‌دهنده پلتفرم، تولیدکنندگان تجهیزات اصلی (OEM) باید یک هدف rust_binary برای مدیر تشخیص (Diagnostic Manager Agent) پیاده‌سازی کنند:

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 برای بازتاب استفاده کرد.

فایل .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 Agent یک فایل اجرایی باینری است، 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
}