Định cấu hình Orchestrator

Orchestrator là một tác nhân SDV cục bộ chạy trên mỗi máy ảo (VM) và cung cấp một cơ chế để kiểm soát thời điểm các gói dịch vụ cần được tạo, khởi động, dừng hoặc huỷ. Việc này được thực hiện thông qua cấu hình điều phối, trong đó bạn xác định một tập hợp các quy tắc xác định thời điểm và cách thức thực hiện các hành động trên các phiên bản gói dịch vụ. Các quy tắc này dựa trên chế độ xe, nguồn điện và chế độ tuỳ chỉnh.

Bạn có thể định cấu hình Orchestrator trong các APEX cấu hình hoặc thông qua cấu hình cho mỗi VM. Hệ thống cấu hình phân tán này cho phép các phần của mỗi gói dịch vụ được cập nhật độc lập thông qua Sổ đăng ký gói dịch vụ, như minh hoạ ở đây.

Sơ đồ cấu hình phân tán của Orchestrator

Hình 1. Sơ đồ cấu hình Orchestrator.

Cấu hình độc lập với xe không thay đổi tuỳ theo nhà sản xuất thiết bị gốc hoặc xe. Cấu hình vẫn giữ nguyên trên tất cả các xe của mỗi OEM. Cấu hình dành riêng cho xe có thể khác nhau trên các xe của nhiều OEM, mặc dù cấu hình có thể giống nhau cho tất cả các xe do một OEM cụ thể sản xuất.

APEX cấu hình

Vào thời gian chạy, Orchestrator sẽ chuyển đến sổ đăng ký gói dịch vụ để tìm nạp một bản phối hợp SDV cho từng gói dịch vụ, tải và phân tích cú pháp từng cấu hình. Để tìm hiểu thêm, hãy tham khảo phần Siêu dữ liệu điều phối.

Cấu hình cho mỗi máy ảo

Khi Orchestrator khởi động, nó sẽ tải và phân tích cú pháp cấu hình máy ảo (nếu có). Đường dẫn tuyệt đối đến tệp cấu hình này được chỉ định thông qua các thuộc tính hệ thống persist.sdv.orchestrator_config_path và ro.boot.sdv.orchestrator_config_path.

Hệ thống xác định đường dẫn tệp cấu hình máy ảo khi khởi động dựa trên hệ phân cấp sau:

  1. Hệ thống sẽ kiểm tra thuộc tính persist.sdv.orchestrator_config_path. Nếu có giá trị, đường dẫn đó sẽ được dùng. Giá trị này được duy trì trong quá trình khởi động lại hoặc được đặt tại thời gian chạy.

  2. Nếu persist.sdv.orchestrator_config_path trống, hệ thống sẽ kiểm tra thuộc tính ro.boot.sdv.orchestrator_config_path. Nếu thuộc tính ro.boot.sdv có giá trị, thì đường dẫn đó sẽ được sao chép vào thuộc tính persist và được dùng cho lần khởi động hiện tại và tất cả các lần khởi động sau này (trừ phi bị ghi đè).

persist.sdv.orchestrator_config_path

persist.sdv.orchestrator_config_path là thuộc tính chính mà tác nhân SDV Orchestrator dùng để lấy đường dẫn đến tệp cấu hình của tác nhân. Đây là một thuộc tính liên tục, nghĩa là giá trị của thuộc tính này sẽ được lưu trong các lần khởi động lại thiết bị. Bạn có thể thay đổi giá trị tại thời gian chạy, điều này rất hữu ích cho việc kiểm thử hoặc các trường hợp cụ thể (ví dụ: kiểm thử toàn diện).

Bạn có thể đặt giá trị tại thời gian chạy bằng lệnh setprop và tại thời gian xây dựng bằng cách sử dụng tệp makefile (có đuôi .mk) hoặc tệp tập lệnh tài nguyên, có đuôi .rc.

Đặt thuộc tính tại thời gian chạy

Việc thiết lập thuộc tính trong thời gian chạy rất hữu ích cho việc kiểm thử hoặc thực hiện các thay đổi tạm thời, vì giá trị này được lưu lại trong quá trình khởi động lại:

adb root
adb shell setprop persist.sdv.orchestrator_config_path {$path_to_file}.textproto

Đặt thuộc tính tại thời gian xây dựng

Để đặt thuộc tính này trong cấu hình bản dựng của thiết bị, hãy thêm một dòng vào tệp makefile của sản phẩm hoặc bảng. Đây là lựa chọn lý tưởng để đặt giá trị mặc định cho một hình ảnh thiết bị mới.

# Add this line to a product's or device's .mk file
PRODUCT_PROPERTY_OVERRIDES += persist.sdv.orchestrator_config_path={$path_to_file}.textproto

Bạn cũng có thể thiết lập thuộc tính này trong tệp tập lệnh tài nguyên:

# Add this line to an .rc file
on {$property}
    setprop persist.sdv.orchestrator_config_path {$path_to_file}.textproto

ro.boot.sdv.orchestrator_config_path

ro.boot.sdv.orchestrator_config_path là một thuộc tính chỉ đọc khi khởi động được dùng để cung cấp giá trị ban đầu cho thuộc tính persist.sdv.orchestrator_config_path. Nếu persist.sdv.orchestrator_config_path trống khi hệ thống khởi động, giá trị của ro.boot.sdv.orchestrator_config_path sẽ được sao chép vào đó. Sau khi được đặt, persist.sdv.orchestrator_config_path sẽ không bị thuộc tính này ghi đè trong các lần khởi động tiếp theo.

Bạn có thể đặt ro.boot.sdv.orchestrator_config_path bằng bootconfig hoặc cmdline của kernel.

Định dạng tệp

Xác định cấu hình điều phối ở định dạng .textproto (ví dụ: trong văn bản có cấu trúc) để có thể tải các cấu hình mới tại thời gian chạy.

Cú pháp cấu hình

Phần này mô tả cú pháp cấu hình.

Gói dịch vụ

Mỗi gói dịch vụ phải được xác định bằng cấu hình Gói dịch vụ. Cấu hình này xác định gói trong Orchestrator và được dùng để xử lý vòng đời của phiên bản gói. Cấu hình gói dịch vụ xác định:

  • InstanceToGroupMapping cho phép bạn đưa một phiên bản của gói dịch vụ vào một nhóm để thiết lập các phần phụ thuộc giữa các phiên bản của cùng một gói dịch vụ.

  • InstancesStates xác định các trạng thái khác nhau cho phiên bản gói dịch vụ.

  • InstancesStateConfiguration xác định trạng thái (từ InstancesStates) mà một thực thể gói dịch vụ phải được đặt nếu điều kiện đánh giá thành true.

  • ServiceBundleConfig chứa thông tin về gói dịch vụ cụ thể và các phiên bản của gói đó. Đối với gói, nó chứa InstanceToGroupMapping và InstancesStateConfiguration tương ứng.

  • CustomModes xác định danh sách các chế độ tuỳ chỉnh mà gói được phép xuất bản. CustomModes dùng để ngăn một gói không được uỷ quyền sửa đổi giá trị của một chế độ tuỳ chỉnh. Trường này không bắt buộc, vì gói dịch vụ có thể không xuất bản sang chế độ tuỳ chỉnh nào. Để tìm hiểu thêm, hãy xem phần Chế độ tuỳ chỉnh.

Cấu hình gói bắt buộc

Tối thiểu, cấu hình gói sẽ cung cấp các thuộc tính sau:

service_bundle_config {
    package_name: "package_name"
    service_bundle_name: "service_bundle_name"

    instance: "instance_1"
    instance: "instance_n"
}

Khai báo này xác định các thực thể gói dịch vụ n bằng FQIN tương ứng:

vm_name.package_name.service_bundle_name.instance_1
…
vm_name.package_name.service_bundle_name.instance_n

Tên máy ảo không được khai báo rõ ràng trong cấu hình. Vì cấu hình được xác định cho mỗi máy ảo, nên tên máy ảo luôn là tên của máy ảo mà tệp cấu hình được triển khai và đã được tác nhân điều phối biết.

Định cấu hình các phiên bản

Việc khai báo các thực thể gói dịch vụ không có tác dụng. Để được Orchestrator thực thi, bạn phải định cấu hình các phiên bản. Ví dụ: Orchestrator phải được thông báo về những điều kiện (hoặc trạng thái của VM hoặc xe) mà một phiên bản sẽ chạy. Để định cấu hình các phiên bản, bạn phải xác định trạng thái cấu hình thông qua:

  • condition là một biểu thức về trạng thái VM hoặc trạng thái xe cần được đánh giá.

  • instances_states là một tập hợp các trạng thái cho mỗi phiên bản cần được áp dụng nếu điều kiện đánh giá là true.

Để tìm hiểu thêm, hãy xem phần Điều kiện.

service_bundle_config {
    package_name: "oem.package"
    service_bundle_name: "OemApplication"

    instance: "adaptive_light"
    instance: "reserve_light"

    state {
        condition {
            power_state: "ON"
        }

        instances_states {
            started: "adaptive_light"
            created: "reserve_light"
        }
    }
}

Liên kết bản sao với nhóm

Bạn cũng có thể định cấu hình các phiên bản dịch vụ bằng cách đưa chúng vào các nhóm dịch vụ. Ở cấp cấu hình gói dịch vụ, bạn có thể thêm các phiên bản vào nhóm. Sau đó, bạn có thể định cấu hình các nhóm ở cấp cấu hình máy ảo. Để tìm hiểu thêm, hãy xem phần tiếp theo và Gói dịch vụ.

service_bundle_config {
    package_name: "oem.package"
    service_bundle_name: "OemApplication"

    instance: "fog_front_light"
    instance: "fog_rear_light"
    instance: "turn_signal_light"
    instance: "light_flasher_display"

    # Declare that fog_light contains fog_front_light and fog_rear_light.
    group_mapping {
        group: "fog_light"
        instance: "fog_front_light"
        instance: "fog_rear_light"
    }

    # Declare that flasher_light contains turn_signal_light and light_flasher_display.
    group_mapping {
        group: "flasher_light"
        instance: "turn_signal_light"
        instance: "light_flasher_display"
    }
}

Giản đồ Proto

Dưới đây là một mẫu lược đồ proto:

// Service bundle configuration.
//
// Defines service bundle data, its instances and configuration for instances
// states depending on the state of the system
message ServiceBundleConfig {
  // Required. Name of the service bundle.
  string service_bundle_name = 1;

  // Required. Package name of the service bundle.
  string package_name = 2;

  // Required. Service instances.
  repeated string instance = 3;

  // Configuration for instances states depending on the state of the system.
  repeated InstancesStateConfiguration state = 4;

  // Mapping of groups to their member service instances.
  repeated InstanceToGroupMapping group_mapping = 5;

  // Custom modes that this service bundle is allowed to set.
  repeated string custom_mode = 6;

  // Defines the retry policies for specific instances.
  // If multiple mappings target the same instance, the one with the highest `max_retries`
  // value takes precedence. This applies across all configuration files.
  repeated InstanceToRetryMapping retry_mapping = 7;
}

// Mapping of instances to their retry configuration.
message InstanceToRetryMapping {
  // Required.
  //
  // Name of the instances for which the given retry configuration is applied.
  repeated string instance = 1;

  // Required.
  //
  // The configuration that defines the restart and retry strategy for the instances.
  RetryConfiguration retry_config = 2;

  // Configuration for retry and restart.
  // This configuration is applied after a failure on a transition or after the bundle instance
  // has crashed. Upon a successful operation, the retry counter are reset to max_retries. This
  // configuration can be applied to any service bundle, not only the monitored ones. If the
  // configuration is not provided or none of the optional fields are filled, the default behavior
  // stated is applied (the value from `ro.boot.sdv.orchestrator.recovery.max_retries`
  // or zero if not set).
  message RetryConfiguration {
    // The number of times a retry/restart operation can be performed.
    // Defines the number of times the Orchestrator retries a transition
    // after a transient failure or after a bundle crash notification.
    // This applies to creating, starting and destroying operations.
    // The retry count resets to max_retries after a successful operation.
    // If not set, the default configured value in the
    // `ro.boot.sdv.orchestrator.recovery.max_retries` is used, or-if not set-
    // it fallbacks to zero.
    optional uint32 max_retries = 1;
  }
}

// Mapping of groups to their member service instances.
message InstanceToGroupMapping {
  // Required. Names of groups to which members are added.
  //
  // Group behavior is defined in VM configuration.
  repeated string group = 1;

  // Required. Names of instances to be included in the groups.
  //
  // Can reference only instance defined in the same config file.
  repeated string instance = 2;
}

// Describes the state the service instances should be in after the state is executed.
//
// If there is no valid configuration for the instance in the specific system state, such instance is transitioned to the "destroyed" state.
//
// For the GroupsStates definition to be useful, at least one item should be present in any of the fields.
message InstancesStates {
  // Names of the instances that must be in a "created" state.
  repeated string created = 1;

  // Names of the instances that must be in a "started" state, overrides "created" state.
  repeated string started = 2;

  // Names of the instances that must not run, overrides all other states.
  repeated string destroyed = 3;
}

// Configuration for instances states depending on the state of the system.
message InstancesStateConfiguration {
  // Condition for the system state under which the related instances states should be executed by Orchestrator.
  //
  // If omitted, the related instances states are always executed.
  Condition condition = 1;

  // Required. States of service bundle instances to be executed by Orchestrator if the condition is true.
  InstancesStates instances_states = 2;
}

Cấu hình cấp máy ảo

Cấu hình máy ảo cho phép xác định các mối liên kết nhóm và cấu hình cho các nhóm. Thành phần này được dùng để mô hình hoá các phần phụ thuộc giữa các gói dịch vụ ở cấp máy ảo, nhờ đó mang lại sự linh hoạt khi sửa đổi trạng thái của nhiều gói dịch vụ cùng một lúc. Tất cả các phiên bản của một nhóm đều được đưa về trạng thái đã chỉ định.

Orchestrator không đảm bảo thứ tự thực hiện thay đổi trạng thái. Orchestrator sẽ chuyển từng thực thể sang trạng thái đã cho.

Các nhóm được khai báo một cách gián tiếp bằng cách sử dụng tên group trong bất kỳ phần nào của cấu hình. Ví dụ: mối liên kết từ thực thể đến nhóm, mối liên kết từ nhóm đến nhóm và trạng thái cấu hình nhóm.

Liên kết nhóm với nhóm

Các nhóm có thể chứa các nhóm khác. Bằng cách khai báo rằng group_1 chứa subgroup_2, chúng ta sẽ thêm tất cả các phiên bản dịch vụ từ subgroup_2 vào group_1 một cách hiệu quả.

Ví dụ:

# Declare that body contains fog_light and flasher_light.
group_mapping {
    group: "body"
    subgroup: "fog_light"
    subgroup: "flasher_light"
}

Định cấu hình một nhóm

Việc khai báo một nhóm không có hiệu lực. Để được Orchestrator thực thi, bạn phải định cấu hình các nhóm. Ví dụ: Orchestrator phải được thông báo về những điều kiện hoặc trạng thái của máy ảo hoặc xe mà các nhóm sẽ chạy.

Bạn có thể định cấu hình các nhóm theo cách tương tự như các phiên bản dịch vụ, tức là bằng cách sử dụng các trạng thái cấu hình. Điểm khác biệt duy nhất là việc sử dụng groups_states thay vì instances_states trong cú pháp:

state {
    condition {
        power_state: "ON"
    }

    groups_states {
        started: "Body"
        started: "Adas"
    }
}

Giản đồ Proto

Sau đây là một mẫu giản đồ proto:

// VM configuration.
//
// Defines group-to-group mappings and configuration for groups
// states depending on the state of the system.
//
// Configurations of service bundles can also be defined in VM configuration (as well as in a separate configuration file).
message VmConfig {
  // Group to member groups mapping.
  repeated GroupToGroupMapping group_mapping = 1;

  // Configuration of group states.
  repeated GroupsStateConfiguration state = 2;

  // Required. We also allow to configure individual service bundles in the VM config, to simplify development and migration from the monolithic configuration.
  repeated ServiceBundleConfig service_bundle_config = 3;
}

// Mapping of groups to their member groups.
message GroupToGroupMapping {
  // Required. Names of groups to which members are added.
  repeated string group = 1;

  // Required. Names of member groups to be included in the groups.
  repeated string subgroup = 2;
}

// Describes the state the service instance groups should be in after the state is executed.
//
// If group configuration is valid in a specific system state, the configured state is applied to
// all group members. After that, the normal service instance configuration rules still apply:
// - "destroyed" > "started" > "created" precedence
// - not configured means the instance should be moved to the default state
//
// For the GroupsStates definition to be useful, at least one item should be present in any of the fields.
message GroupsStates {
  // Names of the groups that must be in a "created" state.
  repeated string created = 1;

  // Names of the groups that must be in a "started" state, overrides "created" state.
  repeated string started = 2;

  // Names of the groups that must not run, overrides all other states.
  repeated string destroyed = 3;
}

// Configuration for group states depending on the state of the system.
message GroupsStateConfiguration {
  // Condition for the system state under which the related group states should be executed by  Orchestrator.
  //
  // If omitted, the related groups states are always executed.
  Condition condition = 1;

  // Required. States of service bundle groups to be executed by Orchestrator if the condition  is true.
  GroupsStates groups_states = 2;
}

Trạng thái cấu hình

Các trạng thái cấu hình (trạng thái) xác định thời điểm một phiên bản dịch vụ hoặc nhóm được khởi động, dừng hoặc huỷ và bao gồm conditions và instances_states (cấu hình gói) và groups_states (cấu hình máy ảo).

Điều kiện

Các điều kiện cho phép mô hình có một điều kiện boolean. Khi điều kiện này được đánh giá thành true, trạng thái phiên bản đã xác định sẽ được áp dụng. Một điều kiện có những đặc điểm sau:

  • Biểu thức boolean phức tạp tuỳ ý (được tạo bằng biểu thức and hoặc not) dựa trên các tín hiệu được hỗ trợ, chẳng hạn như nguồn điện, xe và chế độ tuỳ chỉnh.

  • (Không bắt buộc) Trạng thái cấu hình không có điều kiện luôn ở trạng thái hoạt động, tức là trạng thái này đánh giá thành true

Trạng thái phiên bản và trạng thái nhóm

instances_states và groups_states có những đặc điểm sau.

  • Quy định những trạng thái mà tác nhân điều phối cần áp dụng cho các phiên bản hoặc nhóm đã cho, với điều kiện trạng thái là active

  • Khi áp dụng một trạng thái cho nhóm, trạng thái đó sẽ áp dụng cho từng phiên bản gói dịch vụ trong nhóm. Không có thứ tự áp dụng đối với thời điểm các phiên bản được đưa vào trạng thái này.

Các tiểu bang được hỗ trợ bao gồm:

  • started sau khi Service::on_start được gọi.

  • created

    • sau khi Service::new được gọi, nhưng trước khi Service::on_start được gọi.

      HOẶC

    • sau khi Service::on_stop được gọi, nhưng trước khi Service::drop được gọi.

  • destroyed sau khi Service::drop được gọi.

Bộ quy tắc

Trạng thái cấu hình có thể là đang hoạt động hoặc không hoạt động, tuỳ thuộc vào điều kiện. Bạn có thể kích hoạt nhiều trạng thái cùng lúc. Khi một tác nhân điều phối nhận được thông tin cập nhật về tín hiệu, tất cả các trạng thái cấu hình sẽ được đánh giá trước khi sửa đổi vòng đời của các gói dịch vụ. Các trạng thái của phiên bản dịch vụ được đánh giá theo những quy tắc sau:

  • Khi không có trạng thái nào đang hoạt động áp dụng cho phiên bản dịch vụ, phiên bản đó sẽ bị huỷ.

  • Khi áp dụng một hoặc nhiều trạng thái đang hoạt động, thứ tự ưu tiên này sẽ được áp dụng:

    1. destroyed có quyền ưu tiên tuyệt đối.
    2. started được ưu tiên trước created.

Giản đồ Proto

Sau đây là một mẫu giản đồ proto:

// A root boolean condition.
message Condition {
  // Required.
  oneof root {
    // VPM power state condition.
    string power_state = 1;
    // VPM vehicle state condition.
    string vehicle_state = 2;
    // Custom mode state condition.
    CustomState custom_state = 3;
    // Negation of a nested condition.
    Condition not = 4;
    // Logical 'and' between conditions grouped in expression.
    Expression and = 5;
    // Logical 'or' between conditions grouped in expression.
    Expression or = 6;
  }
}

// Representation of Custom state condition.
//
// Custom mode(s) are defined by the OEM and are not standardized by the platform, in contrast with
// VPM modes (i.e. power and vehicle mode).
message CustomState {
  // Custom mode being checked.
  string mode = 1;
  // State of the custom mode.
  string state = 2;
}

// A set of conditions united under an 'and' or 'or' expression.
//
// Evaluation type ('and' or 'or') depends on the field in [Condition]/[Expression], where the
// expression is being used.
//
// At least one value in at least one of the fields is required.
message Expression {
  // VPM power state condition.
  repeated string power_state = 1;
  // VPM vehicle state condition.
  repeated string vehicle_state = 2;
  // Custom mode state condition.
  repeated CustomState custom_state = 3;
  // Negation of a nested condition.
  repeated Condition not = 4;
  // Logical 'and' between conditions grouped in expression.
  repeated Expression and = 5;
  // Logical 'or' between conditions grouped in expression.
  repeated Expression or = 6;
}

Chiến lược khởi động lại và khôi phục sau sự cố

Orchestrator cung cấp một cơ chế mạnh mẽ để xử lý các sự cố về gói dịch vụ và lỗi chuyển đổi vòng đời. Vì Orchestrator có cái nhìn tổng thể về trạng thái dịch vụ và quản lý các quá trình chuyển đổi chế độ, nên đây là thành phần phù hợp nhất để thực thi chiến lược khởi động lại và thử lại. Lifecycle Manager (LM) báo cáo các sự cố của gói dịch vụ cho Orchestrator thông qua thông báo về sự cố liên kết. Để tránh các lệnh gọi liên kết không cần thiết đến LM, Orchestrator sẽ lưu vào bộ nhớ đệm trạng thái gần đây nhất của từng gói (dù thành công hay không) và không áp dụng lại các quá trình chuyển đổi nếu trạng thái gần đây nhất đã biết giống với trạng thái mới được yêu cầu.

Thử định cấu hình lại

Bạn có thể xác định chiến lược khởi động lại và thử lại cho mỗi phiên bản trong cấu hình Orchestrator bằng cách sử dụng retry_mapping. Nếu bạn không đặt max_retries trong cấu hình, giá trị mặc định sẽ được lấy từ thuộc tính hệ thống ro.boot.sdv.orchestrator.recovery.max_retries. Nếu bạn không đặt thuộc tính này, giá trị sẽ dự phòng thành 0.

  • max_retries: Xác định số lần Orchestrator thử lại một quá trình chuyển đổi sau khi có thông báo về lỗi tạm thời hoặc sự cố gói. Bộ đếm thử lại sẽ đặt lại thành giá trị max_retries sau khi một thao tác thành công hoặc khi một chế độ mới được xử lý. Nếu nhiều ánh xạ nhắm đến cùng một phiên bản, thì ánh xạ có max_retries cao nhất sẽ được ưu tiên.

Cấu hình mẫu

service_bundle_config {
  package_name: "oem.package"
  service_bundle_name: "OemApplication"
  instance: "fog_front_light"
  instance: "fog_rear_light"

  # Defines the restart configuration mapping for specific instances.
  retry_mapping {
    instance: "fog_front_light"
    instance: "fog_rear_light"
    retry_config {
      max_retries: 3
    }
  }
}

Hành vi khôi phục

Logic khởi động lại và thử lại của Orchestrator giúp quản lý một cách hiệu quả một số trường hợp lỗi:

  • Sự cố khi hoạt động bình thường: Nếu một gói dịch vụ gặp sự cố trong khi chạy, Orchestrator sẽ áp dụng chiến lược khởi động lại và cố gắng đưa gói về trạng thái được yêu cầu gần đây nhất dựa trên số lần thử lại còn lại.
  • Sự cố trong quá trình chuyển đổi chế độ: Nếu một gói gặp sự cố trong khi thực thi một chế độ mới, thì yêu cầu khởi động lại sẽ được đưa vào hàng đợi và xử lý sau. Sau khi yêu cầu được xử lý, Orchestrator sẽ kiểm tra trạng thái gần đây nhất của phiên bản và chỉ áp dụng thao tác khởi động lại nếu phiên bản không ở trạng thái được yêu cầu gần đây nhất (từ quá trình chuyển đổi chế độ gần đây nhất).
  • Chế độ mới trong quá trình khôi phục: Nếu Orchestrator nhận được yêu cầu chuyển sang một chế độ mới trong khi một gói đang được khởi động lại (hoặc đang ở trong hàng đợi các phiên bản cần khởi động lại), thì Orchestrator sẽ huỷ quá trình khôi phục đang diễn ra. Quá trình chuyển đổi chế độ mới sẽ diễn ra và bộ đếm số lần thử lại được đặt lại để cho phép một loạt các lần thử mới cho trạng thái mục tiêu mới.

Orchestrator phân biệt các loại lỗi khác nhau do Lifecycle Manager trả về để xác định chiến lược thử lại:

  • Lỗi tạm thời (SERVICE_NOT_FOUND, OPERATION_FAILED, INTERNAL_ERROR): Orchestrator sẽ thử lại thao tác mà không thực hiện bất kỳ thao tác dọn dẹp đặc biệt nào.
  • Lỗi liên tục (VALUE_CORRUPTED, INVALID_ARGUMENT): Orchestrator giả định rằng gói dịch vụ có thể ở trạng thái bị hỏng và cố gắng huỷ phiên bản dịch vụ trước khi thử lại thao tác để đảm bảo khởi động lại hoàn toàn.
  • Lỗi vĩnh viễn (PERMISSION_DENIED): Thao tác không được thử lại và gói được coi là ở trạng thái không thể khôi phục.

Nếu Trình quản lý vòng đời gặp sự cố, tất cả các quy trình gói dịch vụ sẽ bị mất. Vì không xác định được trạng thái thực tế, nên Orchestrator sẽ vô hiệu hoá từng phiên bản và áp dụng chiến lược khởi động lại với số lần thử lại còn lại để đưa từng phiên bản về trạng thái được yêu cầu gần đây nhất.

Để ngăn các vòng lặp khôi phục vô hạn cho những gói liên tục gặp sự cố hoặc không hoạt động, bộ đếm số lần thử lại chỉ được đặt lại thành max_retries sau khi một thao tác vòng đời thành công hoặc khi có yêu cầu chuyển đổi chế độ mới. Nếu một gói hết số lần thử lại do các lỗi liên tiếp (ví dụ: lỗi chuyển đổi, sau đó là sự cố), thì gói đó sẽ không khởi động lại cho đến khi bộ đếm số lần thử lại được đặt lại.

Báo cáo trạng thái cho Trình giám sát sức khoẻ

Orchestrator hiển thị một giao diện liên kết nội bộ mà Health Monitor (HM) đăng ký, cho phép giao diện này nhận thông tin cập nhật liên tục về trạng thái của tất cả các gói dịch vụ. Thông qua giao diện này, Orchestrator chủ động báo cáo cả hai:

  • Trạng thái vòng đời: Trạng thái dự kiến của thực thể dựa trên cấu hình hiện tại và các chế độ đang hoạt động (chẳng hạn như đã bắt đầu, đã tạo hoặc đã huỷ).
  • Trạng thái khôi phục: Trạng thái đạt được trạng thái vòng đời dự kiến, cho biết liệu phiên bản có đang hoạt động hay không, hiện đang thử lại sau khi gặp lỗi hoặc không khôi phục được sau khi hết số lần thử lại.

Thông tin này được báo cáo cho tất cả các phiên bản, kể cả những phiên bản chưa đăng ký được theo dõi nhịp tim. HM sử dụng thông tin này để triển khai các API của mình nhằm báo cáo trạng thái của VM. Bạn có thể tìm hiểu thêm trong phần Theo dõi sức khoẻ.

Ví dụ

Phần này trình bày các ví dụ về cách định cấu hình trạng thái có điều kiện.

Mẫu dịch vụ cơ bản
  • Không có điều kiện và do đó luôn hoạt động.
  • Khởi động một phiên bản dịch vụ duy nhất.
state {
  # Note: This state has no condition, hence its actions are valid throughout the lifetime of the program
  instances_states { started: "ServiceBundleName" }
}
Mẫu ứng dụng HVAC

  • Điều kiện: Hoạt động khi custom_state != occupancy.OCCUPANCY_EMPTY || custom_state == preheat.PREHEAT_ON.

  • Khai báo nhiều phiên bản dịch vụ liên quan đến hệ thống sưởi ấm, thông gió và điều hoà không khí (HVAC) dưới dạng started.

state {
  condition {
    or {
      # I.e. when the vehicle is occupied (for example, by _DRIVER / _NON_DRIVER / _PET)
      not {
        custom_state {
          mode: "occupancy"
          state: "OCCUPANCY_EMPTY"
        }
      }
      custom_state {
        mode: "preheat"
        state: "PREHEAT_ON"
      }
    }
  }

  # HVAC-related services
  instances_states {
    started: "HvacTemperatureCommand"
    started: "TempSensorDriverZone"
    started: "TempSensorPassengerZone"
    started: "RefrigerantLoop"
  }
}
Mẫu tiết kiệm năng lượng

  • Điều kiện: Hoạt động khi custom_state == system_power.SYSTEM_POWER_LOW && custom_state == range_ext.RANGE_EXT_ON.

    Bạn có thể xem trạng thái này là trạng thái tiết kiệm điện.

  • Khai báo một thực thể dịch vụ liên quan đến HVAC dưới dạng destroyed.

  • Trong ví dụ này, khi các chế độ SYSTEM_POWER_LOW và RANGE_EXT_ON đang hoạt động, ứng dụng HVAC sẽ chạy mà không có phiên bản dịch vụ RefrigerantLoop:

    state {
  condition {
    and {
      custom_state {
        mode: "system_power"
        state: "SYSTEM_POWER_LOW"
      }
      custom_state {
        mode: "range_ext"
        state: "RANGE_EXT_ON"
      }
    }
  }

  # Disable services with high power consumption
  instances_states { destroyed: "RefrigerantLoop" }
}
Mẫu Life onboard

  • Điều kiện: Hoạt động nếu power_state == ON && vehicle_state == LIFE_ON_BOARD.

    Bạn có thể xem trạng thái này là Có người trong xe và xe đang bật.

  • Khai báo cảm biến nhiệt độ đang chạy.

  • Khi có người ở trong xe, các thông tin như nhiệt độ sẽ được theo dõi vì lý do an toàn.

state {
  condition {
    and {
      power_state: "ON"
      vehicle_state: "LIFE_ON_BOARD"
    }
  }

  # Temperature monitoring services
  instances_states {
    started: "TempSensorDriverZone"
    started: "TempSensorPassengerZone"
  }
}

Ví dụ

Phần này trình bày các ví dụ đầy đủ bao gồm:

  • Cấu hình proto ở cấp gói dịch vụ giới thiệu một gói dịch vụ có 2 phiên bản, mỗi phiên bản là một phần của một nhóm

  • Cấu hình giao thức ở cấp máy ảo giới thiệu logic để tương tác với các nhóm dựa trên chế độ

Cấu hình ở cấp gói dịch vụ

# proto-file: //system/software_defined_vehicle/orchestration/distributed_config/src/protos/service_bundle_config.proto
# proto-message: ServiceBundleConfig

package_name: "oem.package"
service_bundle_name: "OemApplication"
instance: "fog_front_light"
instance: "fog_rear_light"
instance: "turn_signal_light"
custom_mode: "FOG"
custom_mode: "TURN"

group_mapping {
    group: "fog_light"
    instance: "fog_front_light"
    instance: "fog_rear_light"
}

group_mapping {
    group: "flasher_light"
    instance: "turn_signal_light"
}

state {
    condition {
        power_state: "ON"
    }

    instances_states {
        created: "turn_signal_light"
        destroyed: "fog_front_light"
        destroyed: "fog_rear_light"
    }
}

Cấu hình cấp máy ảo

# proto-file: //system/software_defined_vehicle/orchestration/distributed_config/src/protos/vm_config.proto
# proto-message: VmConfig

group_mapping {
    group: "lights"
    subgroup: "fog_light"
    subgroup: "flasher_light"
}

state {
    condition {
        custom_state {
            mode: "FOG"
            state: "ON"
        }
    }
    groups_states {
        started: "fog_light"
    }
}

state {
    condition {
        custom_state {
            mode: "TURN"
            state: "RIGHT"
        }
    }
    groups_states {
        started: "flasher_light"
    }
}

state {
    condition {
        vehicle_state: "SUSPEND_TO_RAM_ENTER"
    }
    groups_states {
        created: "lights"
    }
}

Định cấu hình tính song song của việc quản lý gói

Thuộc tính hệ thống ro.boot.sdv.max_bundles_management_threads là một tham số điều chỉnh chính để kiểm soát hiệu suất và mức tiêu thụ tài nguyên trong các thao tác vòng đời của gói dịch vụ. Tham số này xác định mức độ song song tối đa cho các giao dịch gói dịch vụ và ảnh hưởng trực tiếp đến 2 dịch vụ cốt lõi:

  1. Orchestration Engine (Công cụ điều phối): Dịch vụ này đọc thuộc tính để xác định số lượng lệnh gọi đồng thời (ví dụ: startService, stopService) mà Orchestrator có thể thực hiện đối với Lifecycle Manager. Điều này rất quan trọng đối với hiệu suất trong quá trình khởi động và chuyển đổi chế độ, khi nhiều gói có thể thay đổi trạng thái cùng một lúc.

  2. Lifecycle Manager:Dịch vụ này sử dụng giá trị của thuộc tính để tính toán kích thước của nhóm luồng Binder. Nhóm này chịu trách nhiệm xử lý tất cả các yêu cầu đến. Điều này đảm bảo rằng LM có đủ luồng để xử lý các yêu cầu đồng thời từ Orchestrator.

Nếu bạn không đặt thuộc tính này, cả hai dịch vụ đều có giá trị mặc định là 12.

Phương thức định cấu hình

Bạn có thể đặt thuộc tính này trong tệp BoardConfig.mk của thiết bị bằng cách thêm thuộc tính đó vào biến BOARD_BOOTCONFIG. Điều này đảm bảo giá trị được áp dụng mỗi khi thiết bị khởi động.

BOARD_BOOTCONFIG += \
    androidboot.sdv.max_bundles_management_threads=8

Để thay đổi giá trị cho thiết bị, hãy sửa đổi dòng này trong tệp BoardConfig.mk thích hợp rồi tạo lại.

Tối ưu hoá thời gian khởi động

ro.sdv.orchestrator.state.ready là một thuộc tính boolean write-once nằm trong chiến lược tối ưu hoá hiệu suất khi khởi động. Điều này cho biết Orchestration agent đã hoàn tất quá trình khởi tạo và sẵn sàng bắt đầu quản lý vòng đời của các gói dịch vụ. Mục đích chính của SDV là ưu tiên việc khởi động Orchestrator và các gói dịch vụ được quản lý bằng cách kiểm soát trình tự khởi động của các tác nhân SDV khác.

  • Đặt theo: Tác nhân điều phối.
  • Thời điểm: Một lần trong trình tự khởi động.
  • Cách sử dụng: Thuộc tính này được hệ thống khởi động dùng để kiểm soát trình tự khởi động của hầu hết các tác nhân SDV (Trình quản lý bản cập nhật, nhà cung cấp VSIDL, Trình giám sát tình trạng, Dịch vụ khám phá, Đường hầm dữ liệu, RPC, VPM và Telemetry). Bằng cách khởi động Orchestrator sớm và yêu cầu các tác nhân khác đợi thuộc tính này, hệ thống đảm bảo rằng Orchestrator có thể bắt đầu nhiệm vụ quan trọng là khởi động các gói dịch vụ mà không cần cạnh tranh tài nguyên hệ thống.

Hiệu suất

Trong quá trình khởi động hệ thống, việc khởi động tất cả các tác nhân cùng lúc có thể dẫn đến tình trạng tranh chấp tài nguyên, làm chậm quá trình khởi động tổng thể. Để giảm thiểu vấn đề này, một thứ tự khởi động tuần tự sẽ được thực thi bằng cách sử dụng các thuộc tính hệ thống:

  1. Sổ đăng ký gói dịch vụ: Bắt đầu tải tất cả siêu dữ liệu gói dịch vụ trước.
  2. Lifecycle Manager và Orchestrator: Các tác nhân cốt lõi này sẽ bắt đầu ngay khi sổ đăng ký sẵn sàng. Việc khởi động sớm này là rất quan trọng vì nó cho phép Orchestrator bắt đầu đánh giá cấu hình và chuẩn bị khởi động ngay các gói dịch vụ.
  3. Các tác nhân SDV khác: Chỉ bắt đầu sau khi Orchestrator sẵn sàng.

Trình tự có kiểm soát này đảm bảo Trình điều phối có quyền ưu tiên sử dụng tài nguyên hệ thống để khởi động các gói dịch vụ vào thời điểm sớm nhất có thể, dẫn đến quá trình khởi động hệ thống nhanh hơn, có tính xác định cao hơn và hiệu quả hơn.

Các chế độ do Orchestrator sử dụng

Tác nhân điều phối duy trì một gói thuê bao đang hoạt động cho các chế độ xe và nguồn điện do VPM truyền. Khi thiết lập kết nối ban đầu giữa Orchestrator và hệ thống Quản lý nguồn và xe (VPM), Orchestrator sẽ đặt các thuộc tính hệ thống boolean sau thành true:

  • sdv.orchestrator.bootup.power_mode.ready

  • sdv.orchestrator.bootup.vehicle_mode.ready

Dựa vào tệp cấu hình, tác nhân điều phối sẽ tính toán linh động tập hợp các gói dịch vụ phải ở trạng thái đang chạy dựa trên các giá trị hiện tại của các chế độ đã nhận. Sau đó, Orchestrator sẽ giao tiếp với trình quản lý vòng đời, đưa ra các lệnh khác nhau để điều chỉnh trạng thái thực tế của các gói dịch vụ cho phù hợp với trạng thái mục tiêu đã tính toán.

Trạng thái xe và nguồn điện

Tác nhân Chế độ xe và quản lý nguồn điện (VPM) cho phép các thành phần SDV được thông báo về trạng thái hiện tại của xe, chẳng hạn như chế độ vận hành (ví dụ: ở chế độ Đỗ xe hoặc Lái xe) và trạng thái nguồn điện (ví dụ: Bật và Tạm dừng). Trình điều phối đánh giá các giá trị này để xác định những gói dịch vụ nào sẽ chạy dựa trên cấu hình Trình điều phối. Để tìm hiểu thêm, hãy xem phần Quản lý xe và nguồn.

Chế độ tuỳ chỉnh

Do có quá nhiều chế độ lái xe, chúng tôi không thể mô hình hoá tất cả các chế độ lái xe. Mỗi nhà sản xuất thiết bị gốc có những nhu cầu riêng và việc chuẩn hoá các chế độ lái xe không thể đáp ứng mọi trường hợp sử dụng của nhà sản xuất thiết bị gốc. Do đó, chúng tôi hỗ trợ các chế độ dành riêng cho nhà sản xuất thiết bị gốc (OEM), còn được gọi là chế độ tuỳ chỉnh. Các chế độ này không mở rộng các chế độ hiện có của xe và nguồn điện. Thay vào đó, chúng cung cấp một cách để xác định các chế độ mới.

Chức năng:

  • Phạm vi toàn cầu: Các chế độ tuỳ chỉnh có phạm vi toàn cầu, áp dụng đồng nhất trên tất cả các máy ảo do Trình điều phối quản lý.

  • Thành phần: Mỗi thay đổi về chế độ tuỳ chỉnh bao gồm hai phần tử:

    • Tên: Giá trị nhận dạng riêng biệt do OEM chọn để biểu thị chế độ tuỳ chỉnh.

    • Giá trị: Trạng thái hiện tại của chế độ tuỳ chỉnh, có thể là UNDEFINED khi không có giá trị nào được đặt.

  • Vai trò của Orchestrator: Orchestrator đóng vai trò là một bên nhận thụ động các giá trị chế độ tuỳ chỉnh.

  • Vai trò của gói dịch vụ: Mỗi gói dịch vụ có thể sở hữu nhiều chế độ tuỳ chỉnh và có thể xuất bản các giá trị mới cho bất kỳ chế độ nào. Nhiều gói dịch vụ có thể có cùng chế độ tuỳ chỉnh. Điều này có nghĩa là một chế độ tuỳ chỉnh có thể nhận các giá trị mới từ nhiều nguồn.

  • Trách nhiệm xác thực: Các OEM chịu trách nhiệm đảm bảo các trạng thái chuyển đổi hợp lệ. Orchestrator chấp nhận mọi giá trị mới.

Đặc điểm ước tính:

  • Số lượng ước tính: Chế độ nguồn và chế độ xe quản lý vòng đời của hầu hết các gói dịch vụ, trong đó các chế độ tuỳ chỉnh đóng vai trò bổ sung. Chúng tôi dự kiến số lượng chế độ tuỳ chỉnh sẽ là hàng chục chứ không phải hàng trăm.

  • Thời gian ước tính: Các chế độ không được gửi định kỳ. Thay vào đó, các chế độ này dựa trên sự kiện, được kích hoạt bởi các hành động cụ thể, chẳng hạn như mở cửa, bắt đầu trình tự đỗ xe, bắt đầu chu kỳ sạc và các sự kiện tương tự khác có ý nghĩa do OEM xác định.

Thiết kế chế độ tuỳ chỉnh mang đến sự linh hoạt trong việc xác định và quản lý các chế độ cụ thể, đồng thời cho phép Trình điều phối không phụ thuộc vào logic máy trạng thái cơ bản.

Các chế độ được hỗ trợ

Để đảm bảo rằng các gói dịch vụ chỉ xuất bản cho các chế độ tuỳ chỉnh mà chúng sở hữu, mỗi gói phải khai báo rõ ràng danh sách các chế độ tuỳ chỉnh thuộc sở hữu trong cấu hình Orchestrator. Cấu hình này có sẵn trong VM cục bộ với sổ đăng ký gói dịch vụ. Các nỗ lực xuất bản vào một chế độ tuỳ chỉnh chưa khai báo sẽ bị loại bỏ.

Để khai báo các chế độ tuỳ chỉnh mà một gói dịch vụ được phép xuất bản (do đó sở hữu), lược đồ giao thức service_bundle_config được mở rộng bằng những nội dung sau:

// Service bundle configuration.
//
// Defines service bundle metadata, its instances, and configuration for instances
// lifecycle states depending on the state of the vehicle.
message ServiceBundleConfig {
      [...]

    // The list of custom modes that this service bundle publishes.
    repeated string custom_mode = 5;
}

Định cấu hình các gói dựa trên chế độ

Cấu hình proto Orchestrator hiện có (thành phần Condition) hỗ trợ việc điều khiển các gói dịch vụ dựa trên các chế độ tuỳ chỉnh:

message Condition {
  oneof root {
    string power_state = 1;
    string vehicle_state = 2;
    CustomState custom_state = 3;
    Condition not = 4;
    Expression and = 5;
    Expression or = 6;
  }
}

message CustomState {
  // Custom mode being checked.
  string mode = 1;
  // State of the custom mode.
  string state = 2;
}

Mẫu Proto

Ví dụ sau đây cho thấy cách định cấu hình các phiên bản của một gói dịch vụ để bắt đầu dựa trên trạng thái TURN và FOG:

service_bundle_config {
package_name: "oem.package"
service_bundle_name: "OemApplication"
instance: "flasher_light"
// Service bundle is allowed to set values for the TURN mode
custom_mode: "TURN"
// Service bundle is allowed to set values for the FOG mode
custom_mode: "FOG"

state {
    condition {
        custom_state {
            mode: "TURN"
            state: "LEFT"
        }
    }
    instances_states {
        started: "flasher_light"
    }
}

state {
    condition {
        custom_state {
            mode: "FOG"
            state: "ON"
        }
    }
    // Group assumed to be defined containing all FOG lights instances.
    groups_states {
        started: "fog_lights"
    }
}

}

Thiết lập chế độ tuỳ chỉnh mới

Quy trình đặt giá trị chế độ tuỳ chỉnh mới bắt đầu bằng gói dịch vụ. Gói này truyền đạt giá trị mong muốn đến Orchestrator cục bộ đang chạy trên cùng một VM. Sau đó, Orchestrator sẽ xác minh rằng gói dịch vụ có các quyền cần thiết để xuất bản vào chế độ tuỳ chỉnh đã chỉ định, tham chiếu cấu hình được xác định trong .textproto để xác định xem có nên truyền giá trị đến các VM khác hay không. Sau khi được truyền tải, mỗi Orchestrator sẽ xem xét cấu hình của mình để tìm danh sách các gói dịch vụ mà trạng thái cần được thay đổi.

RPC

Mỗi Orchestrator chạy trên mỗi VM sẽ tạo một máy chủ RPC để theo dõi các giá trị chế độ tuỳ chỉnh mới. Mỗi gói dịch vụ muốn cập nhật một chế độ tuỳ chỉnh phải tạo một ứng dụng RPC cho máy chủ. ACL được thực thi để ngăn các gói không được uỷ quyền kết nối với máy chủ.

Định nghĩa proto để thiết lập một giá trị mới thông qua RPC có dạng như sau ví dụ:

syntax = "proto3";

import "google/protobuf/timestamp.proto";

package com.sdv.google.Orchestrator;

// Representation of the request used by service bundles to update a custom mode.
// Service bundles are permitted to update only the custom modes specifically designated
// for them within the Orchestrator configuration.
message SetCustomStateRequest {
  // Required.
  // The name of the custom mode.
  // The mode string can not be longer than 56 characters and can only contain
  // letters, numbers, dashes, dots and underscores: [a-zA-Z0-9_-.].
  // No other special character nor spaces should be present in the mode.
  string mode = 1;

  // Required.
  // The new value for the custom mode.
  // The value string can not be longer than 56 characters and can only contain
  // letters, numbers, dashes, dots and underscores: [a-zA-Z0-9_-.].
  // No other special character nor spaces should be present in the value.
  string value = 2;

  // Required.
  // The timestamp in which the new custom mode value was set. This is used to
  // prevent race conditions whenever different service bundles in different
  // VMs want to set a new value for the same custom mode.
  // We use this timestamp to order the requests and we promise eventual
  // consistency: while temporary inconsistencies may occur, the system will
  // eventually converges to the correct state.
  .google.protobuf.Timestamp timestamp = 3;
}

// Representation of the set custom state response.
message SetCustomStateResponse {}

// Orchestrator interface for service bundles that update the value of a
// custom mode.
// When a new value is received, it is propagated to Orchestrators running on
// other VMs.
service CustomStateService {
  // Updates the value for the custom mode.
  // Returns the error:
  // - PermissionDenied: the service is not authorized to update the custom mode.
  // - InvalidArgument: the provided mode and/or value are not valid.
  rpc SetCustomState(SetCustomStateRequest) returns (SetCustomStateResponse) {};
}

Huỷ các quá trình chuyển đổi nguồn

Orchestrator cho phép huỷ các quá trình chuyển đổi nguồn đang diễn ra thông qua chế độ nguồn SHUTDOWN_CANCELLED (do VPM gửi đến Orchestrator).

Hãy xem xét cấu hình Orchestrator sau đây làm ví dụ:

state {
    condition {
        power_state: "SUSPEND_TO_RAM_ENTER"
    }
    instances_states {
        started: "instance-1"
        started: "instance-2"
        started: "instance-3"
    }
}

Khi nhận được chế độ SHUTDOWN_CANCELLED, hai trường hợp chính sẽ quyết định hành vi của Orchestrator. Trong cả hai trường hợp, chế độ nguồn SHUTDOWN_CANCELLED sẽ được thêm vào cuối hàng đợi. Sau đó, SHUTDOWN_CANCELLED sẽ được thực thi sau khi các phần tử trong hàng đợi đã được sử dụng.

Tình huống 1: Chế độ đang diễn ra hiện tại là một chế độ nguồn

Nếu Orchestrator đang thực thi bản cập nhật chế độ nguồn, thì yêu cầu huỷ chế độ đang diễn ra sẽ được gửi. Mặc dù Lifecycle Manager vốn không hỗ trợ việc huỷ một quá trình chuyển đổi đang diễn ra, nhưng Orchestrator sẽ xác minh rằng không có yêu cầu gói dịch vụ mới nào được bắt đầu.

Ví dụ: Nếu instance-1 trong cấu hình ở ví dụ trước đang trong quá trình khởi động khi nhận được chế độ SHUTDOWN_CANCELLED, thì instance-1 sẽ hoàn tất quá trình khởi động. Tuy nhiên, instance-2 và instance-3 không tiếp tục chuyển đổi sang trạng thái đã bắt đầu.

Tình huống 2: Có một chế độ nguồn trong hàng đợi xử lý

Trong trường hợp Orchestrator đang xử lý một bản cập nhật không ở chế độ nguồn và có một yêu cầu về nguồn trong hàng đợi các chế độ sẽ được thực thi, thì quá trình chuyển đổi nguồn sẽ bị xoá khỏi hàng đợi. Điều này ngăn chặn việc thực thi.

Ví dụ: Khi sử dụng cấu hình trong ví dụ trước, nếu Orchestrator đang xử lý một bản cập nhật không liên quan đến nguồn điện (chẳng hạn như bản cập nhật xe) và SUSPEND_TO_RAM_ENTER nằm trong hàng đợi, thì việc nhận được SHUTDOWN_CANCELLED sẽ không khởi động bất kỳ phiên bản nào (instance-1, instance-2, instance-3).

Mẫu triển khai

Danh mục cho một ứng dụng muốn sử dụng mã do phần mềm trung gian tạo để tạo một ứng dụng cho máy chủ RPC có thể trông giống như ví dụ này:

# proto-file: //system/software_defined_vehicle/vsidl/language/src/protos/sdv/vsidl/v1/syntax.proto
# proto-message: VsidlEntry

package: "package_name"

service_bundle {
    name: "service_bundle_name"

    client {
        service: "com.android.sdv.orchestrator.CustomStateService"
    }
}

Khi tạo mã, bạn phải thêm phần phụ thuộc vào danh mục Orchestrator:

--dependency-catalog-path orchestration/engine/stable/vsidl/*

Mã ứng dụng khách để gửi một giá trị mới có dạng như sau:

let fqin = ServiceFqin::builder()
        .sdv_vm_name("vm_name")
        .sdv_package_name("package_name")
        .service_bundle_name("service_bundle_name")
        .service_instance_name("instance_name")
        .build()
        .unwrap();
let context_ref = ContextRef::create(fqin);
let comms = Arc::new(SdvComms { context: context_ref });
// service_bundle_name is the bundle generated with middleware code that defines
// the RPC client to "com.android.sdv.orchestrator.CustomStateService".
let client = service_bundle_name::new(comms).await.unwrap();
let rpc_client = client
        .create_rpc_client::<Client>(
            UnitName::builder()
                .vm_name(comms.context.get_self_fqin().get_sdv_vm_name())
                .package_name("com.android.sdv.orchestrator")
                .bundle_name("OrchestratorServiceBundle")
                .service_unit_name(Client::DEFAULT_UNIT_NAME)
                .build()
                .unwrap(),
            ClientOptions::default(),
        )
        .await;
let client = Arc::new(rpc_client.unwrap());
let request = SetCustomStateRequest {
mode: custom_mode_name,
value: custom_mode_value,
timestamp: MessageField::some(Timestamp::now()),
..Default::default()
};
let result = client.SetCustomState(&request).await;
// Process result

Công cụ gỡ lỗi

Tác nhân Orchestrator có hỗ trợ công cụ dumpsys. Bạn có thể gọi nó bằng cách chạy lệnh sau trên một phiên bản SDV đang chạy:

adb shell dumpsys com.google.sdv.ISdvAgent/orch

Sử dụng công cụ này để gỡ lỗi và nắm được thông tin chi tiết về trạng thái nội bộ của tác nhân Orchestrator. Thao tác này sẽ hiển thị:

  • Trạng thái hiện tại của các chế độ: Xem các chế độ tuỳ chỉnh, chế độ nguồn và chế độ lái đang hoạt động.
  • Nhà xuất bản ở Chế độ tuỳ chỉnh: Xác định những dịch vụ có thể xuất bản chế độ tuỳ chỉnh (và chế độ nào).
  • Trạng thái bắt buộc cho mỗi dịch vụ: Tìm hiểu trạng thái của từng gói dịch vụ dựa trên các điều kiện được xác định trước và các chế độ hiện tại. Điều này giúp chẩn đoán lý do khiến một dịch vụ có thể không ở trạng thái dự kiến.
  • Trạng thái thực thi chế độ: Xem rõ hình ảnh về chế độ đang được thực thi hoặc chế độ được thực thi gần đây nhất nếu không có chế độ nào đang được thực thi.
  • Hàng đợi thực thi chế độ: Xem các chế độ đang chờ được thực thi.

Ví dụ:

AGENT NAME: SDV Agent dump - Orchestrator
AGENT FQIN: instance1:com.android.sdv.orchestrator.OrchestratorServiceBundle/default
AGENT STATE: See orchestrator state below.
----------------
----------------
INTERNAL STATE REPORTERS:

*NAME: Configuration state
*REPORT:
Active modes:
MODE                          VALUE                         TIMESTAMP (scs, ns)
Power                         POWER_OFF_EXIT                -
Vehicle                       VEHICLE_ON                    -
Custom("CHARGING")            ON                            1750757590 (scs) 466507459 (ns)
Custom("TIRE_PRESSURE")       front-left                    1750757570 (scs) 554522995 (ns)

Modes allowed to publish by bundle (FQIN: modes):
com.android.sdv.sample.orchestration/CustomModeControlBundle: CHARGING, TIRE_PRESSURE

Requested state for instances:
STATE          FQIN
Started        com.android.sdv.sample.orchestration/CustomModeControlBundle/always-started-instance
Started        com.android.sdv.sample.orchestration/OrchestratedServiceBundle/my-instance
Started        com.sdv.oem.sample.diagnostics/DiagnosticsSampleWithDataItem/instance
Started        com.sdv.oem.sample.diagnostics/DiagnosticsSampleWithEvent/instance
Started        com.sdv.oem.user_preferences/UserPreferencesServiceBundle/default
----------------
*NAME: Engine state
*REPORT:
Last mode enforced was Custom("CHARGING") with value "ON"

Next modes to process: []
----------------

Để tìm hiểu thêm về các gói dịch vụ riêng lẻ do Orchestrator quản lý, hãy sử dụng dumpsys hiện có từ Trình quản lý vòng đời như sau:

dumpsys google.sdv.lifecycle.ILifecycleManager/default

Thao tác này sẽ cung cấp thông tin chi tiết về trạng thái vòng đời của từng dịch vụ. Bằng cách kết hợp đầu ra dumpsys của Orchestrator với đầu ra từ LifecycleManager, bạn sẽ có được thông tin đầy đủ về vòng đời của các gói dịch vụ trong máy ảo.