অর্কেস্ট্রেটর কনফিগার করুন

অর্কেস্ট্রেটর হলো একটি স্থানীয় SDV এজেন্ট যা প্রতিটি ভার্চুয়াল মেশিনে (VM) চলে এবং সার্ভিস বান্ডেল কখন তৈরি, চালু, বন্ধ বা ধ্বংস করা হবে তা নিয়ন্ত্রণ করার একটি ব্যবস্থা প্রদান করে। এটি একটি অর্কেস্ট্রেশন কনফিগারেশনের মাধ্যমে করা হয়, যেখানে আপনি কিছু নিয়ম নির্ধারণ করেন যা ঠিক করে দেয় সার্ভিস বান্ডেল ইনস্ট্যান্সগুলোর উপর কখন এবং কীভাবে বিভিন্ন কাজ করা হবে। এই নিয়মগুলো ভেহিকেল, পাওয়ার এবং কাস্টম মোডের উপর ভিত্তি করে তৈরি।

আপনি কনফিগারেশন APEX-এ অথবা প্রতি VM কনফিগারেশনের মাধ্যমে অর্কেস্ট্রেটর কনফিগার করতে পারেন। এই ডিস্ট্রিবিউটেড কনফিগারেশন সিস্টেমটি প্রতিটি সার্ভিস বান্ডেলের অংশবিশেষকে সার্ভিস বান্ডেল রেজিস্ট্রি-র মাধ্যমে স্বাধীনভাবে আপডেট করার সুযোগ দেয়, যেমনটি এখানে দেখানো হয়েছে।

চিত্র ১. অর্কেস্ট্রেটর কনফিগারেশন ডায়াগ্রাম।

যানবাহন-নিরপেক্ষ কনফিগারেশন প্রস্তুতকারক বা গাড়ির উপর নির্ভর করে পরিবর্তিত হয় না। প্রতিটি প্রস্তুতকারকের সমস্ত গাড়িতে কনফিগারেশন একই থাকে। যদিও একটি নির্দিষ্ট প্রস্তুতকারকের তৈরি সমস্ত গাড়ির কনফিগারেশন একই হতে পারে, তবে বিভিন্ন প্রস্তুতকারকের বিভিন্ন গাড়িতে যানবাহন-নির্দিষ্ট কনফিগারেশন ভিন্ন হতে পারে।

কনফিগারেশন APEX

রান টাইমে, অর্কেস্ট্রেটর প্রতিটি সার্ভিস বান্ডেলের জন্য একটি SDV অর্কেস্ট্রেশন আনতে সার্ভিস বান্ডেল রেজিস্ট্রিতে যায় এবং প্রতিটি কনফিগারেশন লোড ও পার্স করে। আরও জানতে, অর্কেস্ট্রেশন মেটাডেটা দেখুন।

প্রতি ভিএম কনফিগারেশন

When the Orchestrator starts, it loads and parses the VM configuration (if present). The absolute path to this configuration file is specified through the system properties persist.sdv.orchestrator_config_path and ro.boot.sdv.orchestrator_config_path .

সিস্টেমটি বুট করার সময় নিম্নলিখিত ক্রমবিন্যাসের উপর ভিত্তি করে ভিএম কনফিগারেশন ফাইলের পাথ নির্ধারণ করে:

1. সিস্টেমটি persist.sdv.orchestrator_config_path প্রপার্টিটি পরীক্ষা করে। যদি এটির কোনো মান থাকে, তবে সেই পাথটি ব্যবহৃত হয়। এই মানটি রিবুটের পরেও সংরক্ষিত থাকে অথবা রান টাইমে সেট করা হয়।

2. যদি persist.sdv.orchestrator_config_path খালি থাকে, তাহলে সিস্টেম ro.boot.sdv.orchestrator_config_path প্রপার্টিটি পরীক্ষা করে। যদি ro.boot.sdv প্রপার্টিতে কোনো মান থাকে, তবে সেই পাথটি persist প্রপার্টিতে কপি করা হয় এবং বর্তমান বুট ও ভবিষ্যতের সমস্ত বুটের জন্য ব্যবহৃত হয় (যদি না এটি ওভাররাইড করা হয়)।

persist.sdv.orchestrator_config_path

persist.sdv.orchestrator_config_path হলো SDV Orchestrator এজেন্টের ব্যবহৃত প্রধান প্রপার্টি, যা তার কনফিগারেশন ফাইলের পাথ পেতে সাহায্য করে। এটি একটি পারসিস্টেন্ট প্রপার্টি, অর্থাৎ ডিভাইস রিবুট করার পরেও এর মান সংরক্ষিত থাকে। আপনি রান টাইমে এর মান পরিবর্তন করতে পারেন, যা টেস্টিং বা নির্দিষ্ট সিনারিওর (যেমন, এন্ড-টু-এন্ড টেস্ট) জন্য বেশ উপযোগী।

আপনি রান টাইমে setprop কমান্ড ব্যবহার করে, এবং বিল্ড টাইমে একটি মেকফাইল (যার এক্সটেনশন .mk ) বা একটি রিসোর্স স্ক্রিপ্ট ফাইল (যার এক্সটেনশন .rc ) ব্যবহার করে মানটি সেট করতে পারেন।

রান টাইমে প্রপার্টিটি সেট করুন

রান টাইমে প্রপার্টি সেট করা টেস্টিং বা অস্থায়ী পরিবর্তন করার জন্য উপযোগী, কারণ এর মান রিবুটের পরেও সংরক্ষিত থাকে:

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

বিল্ড টাইমে প্রপার্টিটি সেট করুন

আপনার ডিভাইসের বিল্ড কনফিগারেশনের অংশ হিসেবে এই প্রপার্টিটি সেট করতে, আপনার প্রোডাক্ট বা বোর্ডের মেকফাইলে একটি লাইন যোগ করুন। নতুন ডিভাইস ইমেজের জন্য ডিফল্ট ভ্যালু সেট করার ক্ষেত্রে এটি একটি আদর্শ উপায়।

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

আপনি একটি রিসোর্স স্ক্রিপ্ট ফাইলের মধ্যেও এই প্রপার্টিটি সেট করতে পারেন:

# 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 হলো একটি বুট-টাইম রিড-অনলি প্রপার্টি, যা persist.sdv.orchestrator_config_path প্রপার্টির জন্য একটি প্রাথমিক মান সরবরাহ করতে ব্যবহৃত হয়। সিস্টেম বুট করার সময় যদি persist.sdv.orchestrator_config_path খালি থাকে, তাহলে ro.boot.sdv.orchestrator_config_path এর মানটি এতে কপি করা হয়। একবার persist.sdv.orchestrator_config_path সেট করা হয়ে গেলে, পরবর্তী বুটগুলোতে এই প্রপার্টি দ্বারা এটি আর ওভাররাইট হবে না।

আপনি bootconfig অথবা কার্নেল cmdline ব্যবহার করে ro.boot.sdv.orchestrator_config_path সেট করতে পারেন।

ফাইল ফরম্যাট

অর্কেস্ট্রেশন কনফিগারেশনটি একটি .textproto ফরম্যাটে (উদাহরণস্বরূপ, স্ট্রাকচার্ড টেক্সটে) সংজ্ঞায়িত করুন, যাতে রান টাইমে নতুন কনফিগারেশন লোড করা যায়।

কনফিগারেশন সিনট্যাক্স

এই অংশে কনফিগারেশন সিনট্যাক্স বর্ণনা করা হয়েছে।

পরিষেবা বান্ডেল

প্রতিটি সার্ভিস বান্ডেলকে অবশ্যই সার্ভিস বান্ডেল কনফিগারেশন দ্বারা সংজ্ঞায়িত করতে হবে, যা অর্কেস্ট্রেটরের মধ্যে বান্ডেলটিকে শনাক্ত করে এবং বান্ডেল ইনস্ট্যান্সের জীবনচক্র পরিচালনা করতে ব্যবহৃত হয়। সার্ভিস বান্ডেল কনফিগারেশন যা যা সংজ্ঞায়িত করে:

• InstanceToGroupMapping আপনাকে একই সার্ভিস বান্ডেলের ইনস্ট্যান্সগুলোর মধ্যে নির্ভরতা স্থাপন করার জন্য একটি গ্রুপে সার্ভিস বান্ডেলের একটি ইনস্ট্যান্স অন্তর্ভুক্ত করার সুযোগ দেয়।

• InstancesStates সার্ভিস বান্ডেল ইনস্ট্যান্সের বিভিন্ন অবস্থা নির্ধারণ করে।

• InstancesStateConfiguration সেই অবস্থা ( InstancesStates থেকে) নির্ধারণ করে, যেটিতে একটি সার্ভিস বান্ডেল ইনস্ট্যান্সকে অবশ্যই সেট করতে হবে যদি শর্তটি true বলে প্রমাণিত হয়।

• ServiceBundleConfig নির্দিষ্ট সার্ভিস বান্ডেল এবং এর ইনস্ট্যান্সগুলো সম্পর্কে তথ্য থাকে। এতে বান্ডেলটির জন্য সংশ্লিষ্ট InstanceToGroupMapping এবং InstancesStateConfiguration অন্তর্ভুক্ত থাকে।

• CustomModes সেইসব কাস্টম মোডের একটি তালিকা নির্ধারণ করে, যা বান্ডেলটি প্রকাশ করার অনুমতি পায়। কোনো অননুমোদিত বান্ডেল যাতে কাস্টম মোডের মান পরিবর্তন করতে না পারে, তা প্রতিরোধ করার জন্য CustomModes ব্যবহৃত হয়। এই ফিল্ডটি ঐচ্ছিক, কারণ সার্ভিস বান্ডেলটি কোনো কাস্টম মোডেই প্রকাশ নাও করতে পারে। আরও জানতে, কাস্টম মোডসমূহ দেখুন।

প্রয়োজনীয় বান্ডেল কনফিগারেশন

ন্যূনতমভাবে, বান্ডেল কনফিগারেশন এই অ্যাট্রিবিউটগুলো প্রদান করে:

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

    instance: "instance_1"
    instance: "instance_n"
}

এই ঘোষণাটি n সংখ্যক সার্ভিস বান্ডেল ইনস্ট্যান্সকে তাদের নিজ নিজ FQIN সহ সংজ্ঞায়িত করে:

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

কনফিগারেশনে ভিএম-এর নামটি স্পষ্টভাবে উল্লেখ করা থাকে না। যেহেতু কনফিগারেশনটি প্রতিটি ভিএম-এর জন্য আলাদাভাবে সংজ্ঞায়িত করা হয়, তাই ভিএম-এর নামটি সর্বদা সেই ভিএম-এর নামই হয় যেখানে কনফিগারেশন ফাইলটি স্থাপন করা হয়েছে এবং এটি অর্কেস্ট্রেশন এজেন্টের কাছে আগে থেকেই পরিচিত থাকে।

ইনস্ট্যান্স কনফিগার করুন

সার্ভিস বান্ডেল ইনস্ট্যান্স ঘোষণা করার কোনো প্রভাব নেই। অর্কেস্ট্রেটর দ্বারা কার্যকর হওয়ার জন্য, ইনস্ট্যান্সগুলোকে অবশ্যই কনফিগার করতে হবে। উদাহরণস্বরূপ, কোন শর্তে (অথবা ভিএম বা গাড়ির কোন অবস্থায়) একটি ইনস্ট্যান্স চালানো উচিত, সে সম্পর্কে অর্কেস্ট্রেটরকে জানাতে হবে। ইনস্ট্যান্স কনফিগার করার জন্য, কনফিগারেশন স্টেটগুলো নিম্নলিখিত উপায়ে সংজ্ঞায়িত করতে হবে:

• condition হলো VM বা যানবাহনের অবস্থার উপর একটি অভিব্যক্তি যা মূল্যায়ন করা উচিত।

• instances_states হলো প্রতিটি ইনস্ট্যান্সের জন্য স্টেটগুলোর একটি সেট, যা শর্তটি true প্রমাণিত হলে প্রয়োগ করা উচিত।

আরও জানতে, শর্তাবলী দেখুন।

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

ইনস্ট্যান্স থেকে গ্রুপ ম্যাপিং

আপনি সার্ভিস ইনস্ট্যান্সগুলোকে সার্ভিস গ্রুপে অন্তর্ভুক্ত করেও কনফিগার করতে পারেন। সার্ভিস বান্ডেল কনফিগারেশন লেভেলে, আপনি ইনস্ট্যান্সগুলোকে গ্রুপে যুক্ত করতে পারেন। এরপর আপনি ভিএম কনফিগারেশন লেভেলে গ্রুপগুলোকে কনফিগার করতে পারেন। আরও জানতে, পরবর্তী সেকশন এবং সার্ভিস বান্ডেলস দেখুন।

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

প্রোটো স্কিমা

এখানে একটি প্রোটো স্কিম নমুনা দেওয়া হল:

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

ভিএম-স্তরের কনফিগারেশন

ভিএম কনফিগারেশন গ্রুপ ম্যাপিং এবং গ্রুপগুলোর কনফিগারেশন নির্ধারণ করতে সক্ষম করে। এটি ভিএম পর্যায়ে সার্ভিস বান্ডেলগুলোর মধ্যেকার নির্ভরতা মডেল করতে ব্যবহৃত হয়, যার ফলে একই সময়ে একাধিক সার্ভিস বান্ডেলের অবস্থা পরিবর্তন করার সুবিধা পাওয়া যায়। একটি গ্রুপের সমস্ত ইনস্ট্যান্সকে নির্দিষ্ট অবস্থায় নিয়ে আসা হয়।

অর্কেস্ট্রেটর স্টেট পরিবর্তনের ক্রম নিশ্চিত করে না। অর্কেস্ট্রেটর প্রতিটি ইনস্ট্যান্সকে প্রদত্ত স্টেটে উন্নীত করে।

কনফিগারেশনের যেকোনো অংশে group নাম ব্যবহার করার মাধ্যমে গ্রুপগুলো পরোক্ষভাবে ঘোষিত হয়। উদাহরণস্বরূপ, ইনস্ট্যান্স থেকে গ্রুপে ম্যাপিং, গ্রুপ থেকে গ্রুপে ম্যাপিং, এবং গ্রুপ কনফিগারেশন স্টেট।

গ্রুপ থেকে গ্রুপে ম্যাপিং

একটি গ্রুপের মধ্যে অন্য গ্রুপ থাকতে পারে। group_1 মধ্যে subgroup_2 আছে বলে ঘোষণা করার মাধ্যমে, আমরা কার্যকরভাবে subgroup_2 এর সমস্ত সার্ভিস ইনস্ট্যান্সকে group_1 এ যুক্ত করে দিই।

উদাহরণস্বরূপ:

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

একটি গ্রুপ কনফিগার করুন

একটি গ্রুপ ঘোষণা করার কোনো প্রভাব নেই। অর্কেস্ট্রেটর দ্বারা কার্যকর হওয়ার জন্য, গ্রুপগুলিকে অবশ্যই কনফিগার করতে হবে। উদাহরণস্বরূপ, ভিএম বা যানবাহনের কোন শর্ত বা অবস্থায় গ্রুপগুলি চালানো উচিত, তা অর্কেস্ট্রেটরকে জানাতে হবে।

আপনি সার্ভিস ইনস্ট্যান্সের মতোই গ্রুপ কনফিগার করতে পারেন, অর্থাৎ, কনফিগারেশন স্টেট ব্যবহার করে। একমাত্র পার্থক্য হলো সিনট্যাক্সে instances_states এর পরিবর্তে groups_states এর ব্যবহার:

state {
    condition {
        power_state: "ON"
    }

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

প্রোটো স্কিমা

এখানে একটি নমুনা প্রোটো স্কিমা দেওয়া হলো:

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

কনফিগারেশন অবস্থা

Configuration states (states) define when a service instance or group is started, stopped, or destroyed and consists of conditions and instances_states (bundle config) and groups_states (VM config).

শর্তাবলী

কন্ডিশন মডেলকে একটি বুলিয়ান শর্ত ব্যবহারের সুযোগ দেয়, যার মান ' true হলে সংজ্ঞায়িত ইনস্ট্যান্স স্টেটটি প্রয়োগ করা হয়। একটি কন্ডিশনের নিম্নলিখিত বৈশিষ্ট্যগুলো থাকে:

• পাওয়ার, ভেহিকেল এবং কাস্টম মোডের মতো সমর্থিত সিগন্যালগুলোর উপর ভিত্তি করে যথেচ্ছ জটিল বুলিয়ান এক্সপ্রেশন (যা and বা not ' এক্সপ্রেশন দিয়ে গঠিত)।

• (ঐচ্ছিক) শর্ত ছাড়া কনফিগ স্টেট সর্বদা সক্রিয় থাকে, অর্থাৎ এর মান true হয়।

ইনস্ট্যান্স স্টেট এবং গ্রুপ স্টেট

instances_states এবং groups_states এই বৈশিষ্ট্যগুলো রয়েছে।

• প্রদত্ত ইনস্ট্যান্স বা গ্রুপগুলিতে প্রয়োগ করার জন্য অর্কেস্ট্রেশন এজেন্টের কোন কোন স্টেট প্রয়োজন, তা নির্দেশ করুন, এই শর্তে যে স্টেটটি active থাকবে।

• গ্রুপে কোনো স্টেট প্রয়োগ করার সময়, সেই স্টেটটি গ্রুপের প্রতিটি সার্ভিস বান্ডেল ইনস্ট্যান্সের উপর প্রযোজ্য হয়। ইনস্ট্যান্সগুলোকে কখন সেই স্টেটে আনা হবে, তার কোনো নির্দিষ্ট ক্রম অনুসরণ করা হয় না।

সমর্থিত রাজ্যগুলোর মধ্যে রয়েছে:

• Service::on_start কল করার পরে started ।

• created

  • Service::new কল করার পরে, কিন্তু Service::on_start কল করার আগে।

    অথবা

  • Service::on_stop কল করার পরে, কিন্তু Service::drop কল করার আগে।

• Service::drop কল করার পর destroyed ।

নিয়মাবলী

শর্তের উপর নির্ভর করে একটি কনফিগারেশন স্টেট সক্রিয় বা নিষ্ক্রিয় হতে পারে। যেকোনো সময়ে একাধিক স্টেট সক্রিয় থাকতে পারে। যখন একটি অর্কেস্ট্রেশন এজেন্ট একটি সিগন্যাল আপডেট গ্রহণ করে, তখন সার্ভিস বান্ডেলের লাইফসাইকেল পরিবর্তন করার আগে সমস্ত কনফিগারেশন স্টেট মূল্যায়ন করা হয়। সার্ভিস ইনস্ট্যান্স স্টেটগুলো নিম্নলিখিত নিয়ম অনুসারে মূল্যায়ন করা হয়:

• যখন সার্ভিস ইনস্ট্যান্সটির ক্ষেত্রে কোনো সক্রিয় অবস্থা প্রযোজ্য থাকে না , তখন এটিকে ধ্বংস করে দেওয়া হয়।

• যখন এক বা একাধিক সক্রিয় অবস্থা প্রযোজ্য হয়, তখন এই অগ্রাধিকার প্রযোজ্য হয়:

  1. destroyed চূড়ান্ত অগ্রাধিকার রয়েছে।
  2. started এর অগ্রাধিকার created আগে।

প্রোটো স্কিমা

এখানে একটি নমুনা প্রোটো স্কিমা দেওয়া হলো:

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

ক্র্যাশ পুনরুদ্ধার এবং পুনরায় চালু করার কৌশল

অর্কেস্ট্রেটর সার্ভিস বান্ডেল ক্র্যাশ এবং লাইফসাইকেল ট্রানজিশন ব্যর্থতা সামলানোর জন্য একটি শক্তিশালী ব্যবস্থা প্রদান করে। যেহেতু অর্কেস্ট্রেটরের কাছে সার্ভিসের অবস্থাগুলোর একটি সামগ্রিক চিত্র থাকে এবং এটি মোড ট্রানজিশন পরিচালনা করে, তাই রিস্টার্ট এবং রিট্রাই কৌশলটি কার্যকর করার জন্য এটিই সবচেয়ে উপযুক্ত কম্পোনেন্ট। লাইফসাইকেল ম্যানেজার (এলএম) বাইন্ডার ডেথ নোটিফিকেশনের মাধ্যমে অর্কেস্ট্রেটরকে সার্ভিস বান্ডেল ক্র্যাশের খবর দেয়। এলএম-এ অপ্রয়োজনীয় বাইন্ডার কল এড়ানোর জন্য, অর্কেস্ট্রেটর প্রতিটি বান্ডেলের সর্বশেষ অবস্থা (সফল হোক বা না হোক) ক্যাশ করে রাখে এবং যদি সর্বশেষ জ্ঞাত অবস্থাটি নতুন অনুরোধ করা অবস্থার সমান হয়, তবে ট্রানজিশনগুলো পুনরায় প্রয়োগ করে না।

কনফিগারেশন পুনরায় চেষ্টা করুন

আপনি আপনার Orchestrator কনফিগারেশনে retry_mapping ব্যবহার করে প্রতিটি ইনস্ট্যান্সের জন্য রিস্টার্ট এবং রিট্রাই কৌশল নির্ধারণ করতে পারেন। যদি কনফিগারেশনে max_retries সেট করা না থাকে, তাহলে ডিফল্ট মানটি ro.boot.sdv.orchestrator.recovery.max_retries সিস্টেম প্রপার্টি থেকে নেওয়া হয়। যদি এই প্রপার্টিটিও সেট করা না থাকে, তাহলে মানটি 0-তে ফিরে যায়।

• max_retries : Defines the number of times the Orchestrator retries a transition after a transient failure or a bundle crash notification. The retry counter resets to the value of max_retries after a successful operation or when a new mode is processed. If multiple mappings target the same instance, the one with the highest max_retries takes precedence.

কনফিগারেশন নমুনা

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

পুনরুদ্ধার আচরণ

অর্কেস্ট্রেটরের রিস্টার্ট এবং রিট্রাই লজিক বিভিন্ন ব্যর্থতার পরিস্থিতি দক্ষতার সাথে সামাল দেয়:

• স্বাভাবিক কার্যক্রমে ক্র্যাশ : যদি কোনো সার্ভিস বান্ডেল চলার সময় ক্র্যাশ করে, তাহলে অর্কেস্ট্রেটর রিস্টার্ট স্ট্র্যাটেজি প্রয়োগ করে এবং অবশিষ্ট রিট্রাইয়ের সংখ্যার উপর ভিত্তি করে বান্ডেলটিকে তার সর্বশেষ অনুরোধ করা অবস্থায় ফিরিয়ে আনার চেষ্টা করে।
• Crash during mode transition : If a bundle crashed while enforcing a new mode, the restart request is queued and processed later. Once the request is processed, the Orchestrator checks which was the last state for the instance and only applies the restart if the instance isn't at the last requested state (from the last mode transition).
• রিকভারি চলাকালীন নতুন মোড : যদি কোনো বান্ডেল রিস্টার্ট করার সময় (অথবা রিস্টার্ট করার জন্য ইনস্ট্যান্সের সারিতে থাকা অবস্থায়) অর্কেস্ট্রেটর একটি নতুন মোডে যাওয়ার অনুরোধ পায়, তবে এটি চলমান রিকভারি প্রক্রিয়াটি বাতিল করে দেয়। নতুন মোডে যাওয়ার প্রক্রিয়াটি কার্যকর হয় এবং নতুন টার্গেট স্টেটের জন্য নতুন করে চেষ্টার সুযোগ দিতে রিট্রাই কাউন্টারটি রিসেট করা হয়।

পুনরায় চেষ্টার কৌশল নির্ধারণ করার জন্য অর্কেস্ট্রেটর লাইফসাইকেল ম্যানেজার দ্বারা ফেরত আসা বিভিন্ন ধরণের ত্রুটির মধ্যে পার্থক্য করে:

• ক্ষণস্থায়ী ত্রুটি ( SERVICE_NOT_FOUND , OPERATION_FAILED , INTERNAL_ERROR ): অর্কেস্ট্রেটর কোনো বিশেষ পরিষ্করণমূলক ব্যবস্থা না নিয়েই অপারেশনটি পুনরায় চেষ্টা করে।
• ক্রমাগত ত্রুটি ( VALUE_CORRUPTED , INVALID_ARGUMENT ): অর্কেস্ট্রেটর ধরে নেয় যে সার্ভিস বান্ডেলটি ত্রুটিপূর্ণ অবস্থায় থাকতে পারে এবং একটি সুষ্ঠু পুনঃসূচনা নিশ্চিত করার জন্য অপারেশনটি পুনরায় চেষ্টা করার আগে সার্ভিস ইনস্ট্যান্সটিকে বন্ধ করে দেওয়ার চেষ্টা করে।
• স্থায়ী ত্রুটি ( PERMISSION_DENIED ): অপারেশনটি পুনরায় চেষ্টা করা হয় না এবং বান্ডেলটিকে একটি অপুনরুদ্ধারযোগ্য অবস্থায় আছে বলে মনে করা হয়।

যদি লাইফসাইকেল ম্যানেজার ক্র্যাশ করে, তাহলে সমস্ত সার্ভিস বান্ডেল প্রসেস হারিয়ে যায়। যেহেতু প্রকৃত অবস্থা অজানা থাকে, তাই অর্কেস্ট্রেটর প্রতিটি ইনস্ট্যান্সকে বাতিল করে দেয় এবং অবশিষ্ট পুনঃপ্রচেষ্টাগুলো ব্যবহার করে একটি রিস্টার্ট কৌশল প্রয়োগ করে প্রতিটি ইনস্ট্যান্সকে সর্বশেষ অনুরোধ করা অবস্থায় ফিরিয়ে আনে।

যেসব বান্ডেল বারবার ক্র্যাশ বা ফেইল করে, সেগুলোর ক্ষেত্রে অসীম রিকভারি লুপ প্রতিরোধ করার জন্য, রিট্রাই কাউন্টারটি শুধুমাত্র একটি লাইফসাইকেল অপারেশন সফল হওয়ার পর অথবা যখন একটি নতুন মোড ট্রানজিশনের অনুরোধ করা হয়, তখনই max_retries এ রিসেট করা হয়। যদি কোনো বান্ডেল পরপর ব্যর্থতার কারণে তার রিট্রাই সংখ্যা নিঃশেষ করে ফেলে (উদাহরণস্বরূপ, একটি ট্রানজিশন ব্যর্থতার পর ক্র্যাশ), তবে রিট্রাই কাউন্টারটি রিসেট না করা পর্যন্ত সেটিকে পুনরায় চালু করা হয় না।

স্বাস্থ্য মনিটরের কাছে রাজ্য প্রতিবেদন

অর্কেস্ট্রেটর একটি অভ্যন্তরীণ বাইন্ডার ইন্টারফেস উন্মুক্ত করে, যেখানে হেলথ মনিটর (HM) নিবন্ধিত হয়, যা এটিকে সমস্ত সার্ভিস বান্ডেলের অবস্থা সম্পর্কে অবিচ্ছিন্ন আপডেট পেতে সক্ষম করে। এই ইন্টারফেসের মাধ্যমে, অর্কেস্ট্রেটর সক্রিয়ভাবে নিম্নলিখিত উভয় বিষয়ই রিপোর্ট করে:

• লাইফসাইকেল স্টেট: বর্তমান কনফিগারেশন এবং সক্রিয় মোডগুলির উপর ভিত্তি করে ইনস্ট্যান্সটির উদ্দিষ্ট অবস্থা (যেমন স্টার্টেড, ক্রিয়েটেড বা ডেস্ট্রয়েড)।
• পুনরুদ্ধার অবস্থা: উদ্দিষ্ট লাইফসাইকেল অবস্থায় পৌঁছানোর স্থিতি, যা নির্দেশ করে যে ইনস্ট্যান্সটি সচল আছে, ব্যর্থতার পর বর্তমানে পুনরায় চেষ্টা করছে, অথবা সমস্ত পুনঃচেষ্টা শেষ হওয়ার পরেও পুনরুদ্ধার করতে ব্যর্থ হয়েছে।

এই তথ্যটি সমস্ত ইনস্ট্যান্সের জন্য রিপোর্ট করা হয়, এমনকি যারা হার্টবিট-মনিটরিংয়ের জন্য রেজিস্টার করেনি তাদের জন্যও। HM এই তথ্য ব্যবহার করে VM-এর অবস্থা রিপোর্ট করার জন্য তার API-গুলো বাস্তবায়ন করে। আপনি হেলথ মনিটরিং- এ এ বিষয়ে আরও জানতে পারবেন।

উদাহরণ

এই অংশে শর্তসাপেক্ষে স্টেট কনফিগার করার উদাহরণ উপস্থাপন করা হয়েছে।

বেস পরিষেবা নমুনা

• এর কোনো অবস্থা নেই এবং তাই এটি সর্বদা সক্রিয়।
• একটি একক পরিষেবা ইনস্ট্যান্স চালু করে।

state {
  # Note: This state has no condition, hence its actions are valid throughout the lifetime of the program
  instances_states { started: "ServiceBundleName" }
}

HVAC অ্যাপের নমুনা

• শর্ত: সক্রিয় হবে যখন custom_state != occupancy.OCCUPANCY_EMPTY || custom_state == preheat.PREHEAT_ON ।

• একাধিক HVAC-সম্পর্কিত পরিষেবা ইনস্ট্যান্সকে 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"
  }
}

বিদ্যুৎ সাশ্রয়ের নমুনা

• শর্ত: সক্রিয় হবে যখন custom_state == system_power.SYSTEM_POWER_LOW && custom_state == range_ext.RANGE_EXT_ON ।

  এই অবস্থাকে বিদ্যুৎ সাশ্রয়ী অবস্থা হিসেবে বিবেচনা করা যেতে পারে।

• একটি HVAC-সম্পর্কিত পরিষেবা ইনস্ট্যান্সকে destroyed হিসেবে ঘোষণা করে।

• এই উদাহরণে, যখন SYSTEM_POWER_LOW এবং RANGE_EXT_ON মোডগুলি সক্রিয় থাকে, তখন HVAC অ্যাপটি 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" }
  }
  

জাহাজে জীবনযাত্রার নমুনা

• শর্ত: সক্রিয় হবে যদি power_state == ON && vehicle_state == LIFE_ON_BOARD ।

  এই অবস্থাকে এভাবে দেখা যেতে পারে যে , গাড়িতে কেউ একজন আছে এবং গাড়িটি চালু আছে ।

• তাপমাত্রা সেন্সরগুলোকে চলমান হিসেবে ঘোষণা করা হলো।

• গাড়িতে কেউ থাকলে নিরাপত্তার কারণে তাপমাত্রার মতো বিষয়গুলো পর্যবেক্ষণ করা হয়।

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

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

উদাহরণ

এই বিভাগে সম্পূর্ণ উদাহরণ উপস্থাপন করা হয়েছে, যেগুলিতে রয়েছে:

• একটি সার্ভিস বান্ডেল-স্তরের প্রোটো কনফিগারেশন, যা দুটি ইনস্ট্যান্স সহ একটি সার্ভিস বান্ডেল চালু করে, যেখানে প্রতিটি ইনস্ট্যান্স একটি গ্রুপের অংশ।

• একটি ভিএম-স্তরের প্রোটো কনফিগারেশন যা মোডের উপর ভিত্তি করে গ্রুপগুলির সাথে ইন্টারঅ্যাক্ট করার জন্য লজিক প্রবর্তন করে।

পরিষেবা বান্ডেল-স্তরের কনফিগারেশন

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

ভিএম-স্তরের কনফিগারেশন

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

বান্ডেল ম্যানেজমেন্ট প্যারালালিজম কনফিগার করুন

ro.boot.sdv.max_bundles_management_threads সিস্টেম প্রপার্টিটি হলো সার্ভিস বান্ডেল লাইফসাইকেল অপারেশন চলাকালীন পারফরম্যান্স এবং রিসোর্স ব্যবহার নিয়ন্ত্রণের জন্য একটি গুরুত্বপূর্ণ টিউনিং প্যারামিটার। এটি সার্ভিস বান্ডেল ট্রানজ্যাকশনের জন্য প্যারালালিজমের সর্বোচ্চ স্তর নির্ধারণ করে এবং সরাসরি দুটি কোর সার্ভিসকে প্রভাবিত করে:

1. অর্কেস্ট্রেশন ইঞ্জিন: এই সার্ভিসটি প্রপার্টিটি পড়ে নির্ধারণ করে যে, অর্কেস্ট্রেটর লাইফসাইকেল ম্যানেজারকে একই সাথে কতগুলো কল (যেমন, startService , stopService ) করতে পারবে। বুট-আপ এবং মোড পরিবর্তনের সময় পারফরম্যান্সের জন্য এটি অত্যন্ত গুরুত্বপূর্ণ, কারণ এই সময়ে অনেকগুলো বান্ডেল একই সাথে তাদের অবস্থা পরিবর্তন করতে পারে।

2. লাইফসাইকেল ম্যানেজার: এই সার্ভিসটি তার বাইন্ডার থ্রেড পুলের আকার গণনা করার জন্য প্রপার্টির মান ব্যবহার করে, যা সমস্ত আগত অনুরোধ পরিচালনার জন্য দায়ী। এটি নিশ্চিত করে যে অর্কেস্ট্রেটর থেকে আসা যুগপৎ অনুরোধগুলি পরিচালনা করার জন্য এলএম-এর কাছে পর্যাপ্ত থ্রেড রয়েছে।

এই প্রপার্টিটি সেট করা না থাকলে, উভয় সার্ভিসের ডিফল্ট মান 12 হয়ে যায়।

কনফিগারেশন পদ্ধতি

আপনি আপনার ডিভাইসের BoardConfig.mk ফাইলে BOARD_BOOTCONFIG ভেরিয়েবলে এটি যোগ করে প্রপার্টিটি সেট করতে পারেন। এটি নিশ্চিত করে যে প্রতিবার ডিভাইসটি বুট করার সময় মানটি প্রয়োগ করা হয়।

BOARD_BOOTCONFIG += \
    androidboot.sdv.max_bundles_management_threads=8

আপনার ডিভাইসের জন্য মান পরিবর্তন করতে, উপযুক্ত BoardConfig.mk ফাইলে এই লাইনটি পরিবর্তন করুন এবং রিবিল্ড করুন।

বুট-টাইম অপ্টিমাইজেশন

ro.sdv.orchestrator.state.ready হলো একটি write-once বুলিয়ান প্রপার্টি যা একটি বুট-টাইম পারফরম্যান্স অপটিমাইজেশন স্ট্র্যাটেজির অংশ। এটি নির্দেশ করে যে অর্কেস্ট্রেশন এজেন্ট তার ইনিশিয়ালাইজেশন সম্পন্ন করেছে এবং সার্ভিস বান্ডেলগুলোর লাইফসাইকেল পরিচালনা শুরু করার জন্য প্রস্তুত। এর প্রধান উদ্দেশ্য হলো অন্যান্য SDV এজেন্টগুলোর স্টার্টআপ সিকোয়েন্স নিয়ন্ত্রণের মাধ্যমে অর্কেস্ট্রেটর এবং এর পরিচালিত সার্ভিস বান্ডেলগুলোর স্টার্টআপকে অগ্রাধিকার দেওয়া।

• নির্ধারণকারী: অর্কেস্ট্রেশন এজেন্ট।
• কখন: বুট-আপ প্রক্রিয়ার সময় একবার।
• ব্যবহার: এই প্রপার্টিটি ইনিট সিস্টেম দ্বারা বেশিরভাগ এসডিভি এজেন্টের (আপডেটস ম্যানেজার, ভিএসআইডিএল প্রোভাইডার, হেলথ মনিটর, সার্ভিস ডিসকভারি, ডেটা টানেল, আরপিসি, ভিপিএম এবং টেলিমেট্রি) স্টার্টআপ সিকোয়েন্স নিয়ন্ত্রণ করতে ব্যবহৃত হয়। অর্কেস্ট্রেটরকে আগেভাগে চালু করে এবং অন্যান্য এজেন্টদের এই প্রপার্টির জন্য অপেক্ষা করিয়ে, সিস্টেম নিশ্চিত করে যে অর্কেস্ট্রেটর সিস্টেম রিসোর্সের জন্য প্রতিযোগিতা না করেই সার্ভিস বান্ডেল চালু করার মতো তার গুরুত্বপূর্ণ কাজটি শুরু করতে পারে।

কর্মক্ষমতা

সিস্টেম বুট করার সময়, সমস্ত এজেন্টকে একযোগে চালু করলে রিসোর্স নিয়ে দ্বন্দ্ব সৃষ্টি হতে পারে, যা সামগ্রিক বুট প্রক্রিয়াকে ধীর করে দেয়। এটি প্রশমিত করার জন্য, সিস্টেম প্রোপার্টি ব্যবহার করে একটি ক্রমিক স্টার্টআপ অর্ডার প্রয়োগ করা হয়:

1. সার্ভিস বান্ডেল রেজিস্ট্রি: সমস্ত সার্ভিস বান্ডেল মেটাডেটা লোড করার জন্য এটি প্রথমে চালু হয়।
2. লাইফসাইকেল ম্যানেজার এবং অর্কেস্ট্রেটর: রেজিস্ট্রি প্রস্তুত হওয়ার সাথে সাথেই এই কোর এজেন্টগুলো চালু হয়। এই দ্রুত সূচনা অত্যন্ত গুরুত্বপূর্ণ, কারণ এটি অর্কেস্ট্রেটরকে তার কনফিগারেশন মূল্যায়ন শুরু করতে এবং অবিলম্বে সার্ভিস বান্ডেলগুলো চালু করার জন্য প্রস্তুত হতে সাহায্য করে।
3. অন্যান্য SDV এজেন্ট: Orchestrator প্রস্তুত হওয়ার পরেই কেবল চালু করুন।

এই নিয়ন্ত্রিত ক্রমটি নিশ্চিত করে যে, অর্কেস্ট্রেটর যত দ্রুত সম্ভব সার্ভিস বান্ডেলগুলো চালু করার জন্য সিস্টেম রিসোর্স ব্যবহারে অগ্রাধিকার পায়, যার ফলে সিস্টেম আরও দ্রুত, সুনির্দিষ্ট এবং কার্যকরভাবে চালু হয়।

অর্কেস্ট্রেটর দ্বারা ব্যবহৃত মোডগুলি

অর্কেস্ট্রেশন এজেন্ট VPM দ্বারা প্রেরিত যানবাহন এবং পাওয়ার মোডগুলিতে একটি সক্রিয় সাবস্ক্রিপশন বজায় রাখে। অর্কেস্ট্রেটর এবং ভেহিকেল অ্যান্ড পাওয়ার ম্যানেজমেন্ট (VPM) সিস্টেমের মধ্যে প্রাথমিক সংযোগ স্থাপনের সময়, অর্কেস্ট্রেটর নিম্নলিখিত বুলিয়ান সিস্টেম প্রোপার্টিগুলিকে ' true তে সেট করে:

• sdv.orchestrator.bootup.power_mode.ready

• sdv.orchestrator.bootup.vehicle_mode.ready

একটি কনফিগারেশন ফাইলকে রেফারেন্স হিসেবে ব্যবহার করে, অর্কেস্ট্রেশন এজেন্ট প্রাপ্ত মোডগুলোর বর্তমান মানের উপর ভিত্তি করে সার্ভিস বান্ডেলগুলোর একটি সেট গতিশীলভাবে গণনা করে, যেগুলো চলমান অবস্থায় থাকা উচিত। এরপর অর্কেস্ট্রেটর লাইফসাইকেল ম্যানেজারের সাথে যোগাযোগ করে এবং সার্ভিস বান্ডেলগুলোর প্রকৃত অবস্থাকে গণনাকৃত লক্ষ্য অবস্থার সাথে সামঞ্জস্যপূর্ণ করার জন্য বিভিন্ন কমান্ড জারি করে।

যানবাহন এবং শক্তির অবস্থা

ভেহিকেল মোড অ্যান্ড পাওয়ার ম্যানেজমেন্ট (VPM) এজেন্ট, SDV কম্পোনেন্টগুলোকে গাড়ির বর্তমান অবস্থা, যেমন অপারেশনাল মোড (উদাহরণস্বরূপ, পার্ক বা ড্রাইভে থাকা) এবং পাওয়ার স্ট্যাটাস (উদাহরণস্বরূপ, অন ​​এবং সাসপেন্ড) সম্পর্কে অবহিত করে। অর্কেস্ট্রেটর এই মানগুলো মূল্যায়ন করে অর্কেস্ট্রেটর কনফিগারেশনের উপর ভিত্তি করে কোন সার্ভিস বান্ডেলগুলো চালানো উচিত তা নির্ধারণ করে। আরও জানতে, ভেহিকেল অ্যান্ড পাওয়ার ম্যানেজমেন্ট দেখুন।

কাস্টম মোড

যেহেতু গাড়ির মোড অনেক, তাই আমরা সবগুলোর মডেল তৈরি করতে পারি না। প্রতিটি OEM-এর চাহিদা ভিন্ন এবং গাড়ির মোডগুলোকে প্রমিতকরণ করে সব OEM-এর ব্যবহারের ক্ষেত্র পূরণ করা সম্ভব নয়। ফলস্বরূপ, আমরা OEM-নির্দিষ্ট মোড সমর্থন করি, যা কাস্টম মোড নামে পরিচিত। এই মোডগুলো বিদ্যমান গাড়ি এবং পাওয়ার মোডকে প্রসারিত করে না। বরং, এগুলো নতুন মোড সংজ্ঞায়িত করার একটি উপায় প্রদান করে।

কার্যকারিতা:

• বৈশ্বিক পরিধি: কাস্টম মোডগুলি বৈশ্বিক, যা অর্কেস্ট্রেটর দ্বারা পরিচালিত সমস্ত ভিএম জুড়ে অভিন্নভাবে প্রযোজ্য।

• গঠন: প্রতিটি কাস্টম মোড পরিবর্তন দুটি উপাদান নিয়ে গঠিত:

  • নাম: কাস্টম মোডকে উপস্থাপন করার জন্য OEM দ্বারা নির্বাচিত অনন্য শনাক্তকারী।

  • মান: কাস্টম মোডের বর্তমান অবস্থা, যা কোনো মান সেট না করা হলে UNDEFINED হতে পারে।

• অর্কেস্ট্রেটরের ভূমিকা: অর্কেস্ট্রেটর কাস্টম মোড ভ্যালুগুলোর একজন নিষ্ক্রিয় গ্রাহক হিসেবে কাজ করে।

• সার্ভিস বান্ডেলের ভূমিকা: প্রতিটি সার্ভিস বান্ডেল একাধিক কাস্টম মোডের মালিক হতে পারে এবং যেকোনোটিতে নতুন মান প্রকাশ করতে পারে। একাধিক সার্ভিস বান্ডেল একই কাস্টম মোডের মালিক হতে পারে, যার অর্থ হলো একটি কাস্টম মোড বিভিন্ন উৎস থেকে নতুন মান গ্রহণ করতে পারে।

• যাচাইকরণের দায়িত্ব: OEM-রা বৈধ অবস্থা পরিবর্তন নিশ্চিত করার জন্য দায়ী। অর্কেস্ট্রেটর যেকোনো নতুন মান গ্রহণ করে।

আনুমানিক বৈশিষ্ট্য:

• Estimated count: Power and vehicle modes manage the lifecycle of most service bundles, with custom modes playing a supplemental role. We expect that the order of magnitude of custom modes to be in the dozens and not the hundreds.

• আনুমানিক সময়: মোডগুলো পর্যায়ক্রমে পাঠানো হয় না। এর পরিবর্তে, মোডগুলো ইভেন্ট-চালিত, যা নির্দিষ্ট কিছু কাজের মাধ্যমে সক্রিয় হয়, যেমন—দরজা খোলা, পার্কিং প্রক্রিয়া শুরু করা, চার্জিং চক্র চালু করা এবং OEM-নির্ধারিত তাৎপর্যপূর্ণ অন্যান্য অনুরূপ ঘটনা।

কাস্টম মোড ডিজাইন নির্দিষ্ট মোডগুলি সংজ্ঞায়িত ও পরিচালনা করার নমনীয়তা প্রদান করে এবং একই সাথে অর্কেস্ট্রেটরকে অন্তর্নিহিত স্টেট মেশিন লজিক থেকে স্বাধীন থাকতে দেয়।

সমর্থিত মোড

সার্ভিস বান্ডেলগুলো যেন শুধুমাত্র তাদের নিজস্ব কাস্টম মোডেই পাবলিশ করে, তা নিশ্চিত করার জন্য, প্রত্যেকটিকে তার অর্কেস্ট্রেটর কনফিগারেশনের মধ্যে নিজস্ব কাস্টম মোডগুলোর তালিকা স্পষ্টভাবে ঘোষণা করতে হবে। এই কনফিগারেশনটি সার্ভিস বান্ডেল রেজিস্ট্রি সহ স্থানীয় ভিএম-এ উপলব্ধ থাকে। কোনো অঘোষিত কাস্টম মোডে পাবলিশ করার প্রচেষ্টা বাতিল করা হয়।

একটি সার্ভিস বান্ডেল যে কাস্টম মোডগুলি প্রকাশ করার অনুমতি পায় (এবং সেই সূত্রে সেটির মালিকানা থাকে), তা ঘোষণা করার জন্য service_bundle_config প্রোটো স্কিমাটিকে নিম্নলিখিত বিষয়গুলির দ্বারা সম্প্রসারিত করা হয়:

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

মোডের উপর ভিত্তি করে বান্ডেল কনফিগার করুন

বিদ্যমান অর্কেস্ট্রেটর প্রোটো কনফিগারেশন ( Condition কম্পোনেন্ট) কাস্টম মোডের উপর ভিত্তি করে সার্ভিস বান্ডেল ম্যানিপুলেশন সমর্থন করে:

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

প্রোটো নমুনা

নিম্নলিখিত উদাহরণটি দেখায় কিভাবে TURN এবং 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"
    }
}

}

নতুন কাস্টম মোড সেট করুন

The process of setting a new custom mode value starts with the service bundle, which communicates the desired value to the local Orchestrator running on the same VM. The Orchestrator then verifies that the service bundle has the permissions needed to publish to the specified custom mode, referencing the configuration defined in the .textproto , to determine if it should propagate the value to other VMs. Once propagated, each Orchestrator reviews its configuration to find the list of service bundles for which state should be changed.

আরপিসি

প্রতিটি ভিএম-এ চলমান প্রতিটি অর্কেস্ট্রেটর নতুন কাস্টম মোড ভ্যালু শোনার জন্য একটি আরপিসি সার্ভার তৈরি করে। কাস্টম মোড আপডেট করতে ইচ্ছুক প্রতিটি সার্ভিস বান্ডেলকে অবশ্যই সার্ভারের জন্য একটি আরপিসি ক্লায়েন্ট তৈরি করতে হবে। অননুমোদিত বান্ডেলগুলোকে সার্ভারের সাথে সংযোগ স্থাপন থেকে বিরত রাখতে এসিএল (ACL) প্রয়োগ করা হয়।

RPC-এর মাধ্যমে একটি নতুন মান সেট করার জন্য প্রোটো ডেফিনিশনটি এই উদাহরণের মতো দেখতে হয়:

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

ক্ষমতা হস্তান্তর বাতিলকরণ

অর্কেস্ট্রেটর, VPM থেকে অর্কেস্ট্রেটরে পাঠানো SHUTDOWN_CANCELLED পাওয়ার মোডের মাধ্যমে চলমান পাওয়ার ট্রানজিশন বাতিল করার সুযোগ দেয়।

উদাহরণস্বরূপ নিম্নলিখিত অর্কেস্ট্রেটর কনফিগারেশনটি বিবেচনা করুন:

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

যখন একটি SHUTDOWN_CANCELLED মোড পাওয়া যায়, তখন দুটি প্রধান পরিস্থিতি অর্কেস্ট্রেটরের আচরণ নির্ধারণ করে। উভয় ক্ষেত্রেই, SHUTDOWN_CANCELLED পাওয়ার মোডটি কিউ-এর শেষে যুক্ত করা হয়। এরপর, কিউ-তে থাকা উপাদানগুলো ব্যবহৃত হয়ে গেলে SHUTDOWN_CANCELLED কার্যকর করা হয়।

দৃশ্যকল্প ১: বর্তমানে চলমান মোডটি একটি পাওয়ার মোড

যদি অর্কেস্ট্রেটর একটি পাওয়ার মোড আপডেট সম্পাদন করে, তাহলে চলমান মোডটি বাতিল করার জন্য অনুরোধ করা হয়। যদিও লাইফসাইকেল ম্যানেজার স্বাভাবিকভাবে কোনো চলমান ট্রানজিশন বাতিল করা সমর্থন করে না, অর্কেস্ট্রেটর যাচাই করে দেখে যে কোনো নতুন সার্ভিস বান্ডেল অনুরোধ শুরু করা হয়নি।

উদাহরণ: যদি পূর্ববর্তী উদাহরণের কনফিগারেশন থেকে instance-1 চালু হওয়ার প্রক্রিয়ার মধ্যে থাকে যখন SHUTDOWN_CANCELLED মোডটি পাওয়া যায়, তবে instance-1 তার স্টার্টআপ সম্পন্ন করে। কিন্তু, instance-2 এবং instance-3 তাদের স্টার্টেড স্টেটে রূপান্তর প্রক্রিয়া এগিয়ে নিয়ে যায় না।

দৃশ্যকল্প ২: প্রসেসিং কিউতে একটি পাওয়ার মোড বিদ্যমান আছে

যে ক্ষেত্রে অর্কেস্ট্রেটর একটি নন-পাওয়ার মোড আপডেট প্রসেস করছে, এবং কার্যকর করার জন্য মোডগুলোর কিউতে একটি পাওয়ার রিকোয়েস্ট থাকে, তখন পাওয়ার ট্রানজিশনটি কিউ থেকে সরিয়ে দেওয়া হয়। এর ফলে এটির এক্সিকিউশন প্রতিরোধ করা হয়।

উদাহরণ: পূর্ববর্তী উদাহরণের কনফিগারেশন ব্যবহার করে, যদি অর্কেস্ট্রেটর বিদ্যুৎ-সম্পর্কিত নয় এমন কোনো আপডেটে (যেমন গাড়ির আপডেট) কাজ করে এবং কিউতে SUSPEND_TO_RAM_ENTER থাকে, তাহলে SHUTDOWN_CANCELLED পেলে কোনো ইনস্ট্যান্সই ( instance-1 , instance-2 , instance-3 ) চালু হবে না।

বাস্তবায়ন নমুনা

যে ক্লায়েন্ট RPC সার্ভারের জন্য একটি ক্লায়েন্ট তৈরি করতে মিডলওয়্যার দ্বারা তৈরি কোড ব্যবহার করতে চায়, তার জন্য ক্যাটালগটি এই উদাহরণের মতো দেখতে হতে পারে:

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

কোড জেনারেট করার সময়, আপনাকে অবশ্যই অর্কেস্ট্রেটর ক্যাটালগে ডিপেন্ডেন্সিটি যোগ করতে হবে:

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

নতুন মান পাঠানোর জন্য ক্লায়েন্ট কোডটি দেখতে এইরকম:

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

ডিবাগিং টুলস

অর্কেস্ট্রেটর এজেন্টে dumpsys টুলের সাপোর্ট রয়েছে। একটি চলমান SDV ইনস্ট্যান্সে নিম্নলিখিত কমান্ডটি চালিয়ে আপনি এটি চালু করতে পারেন:

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

অর্কেস্ট্রেটর এজেন্টের অভ্যন্তরীণ অবস্থা ডিবাগ করতে এবং সে সম্পর্কে ধারণা পেতে এই টুলটি ব্যবহার করুন। এটি করলে যা দেখা যায়:

• বর্তমান মোডের অবস্থা: সক্রিয় যানবাহন, পাওয়ার এবং কাস্টম মোডগুলো দেখুন।
• কাস্টম মোড প্রকাশক: শনাক্ত করুন কোন পরিষেবাগুলি কাস্টম মোড (এবং কোন মোডগুলিতে) প্রকাশ করতে পারে।
• প্রতিটি সার্ভিসের জন্য প্রয়োজনীয় অবস্থা: পূর্ব-নির্ধারিত শর্তাবলী এবং বর্তমান মোডের উপর ভিত্তি করে প্রতিটি সার্ভিস বান্ডেলের অবস্থা জানুন। এটি নির্ণয় করতে সাহায্য করে যে কেন একটি সার্ভিস প্রত্যাশিত অবস্থায় নাও থাকতে পারে।
• মোড প্রয়োগের অবস্থা: চলমান কোনো প্রয়োগকৃত মোড সম্পর্কে স্পষ্ট ধারণা পান, অথবা কোনো মোড চালু না থাকলে সর্বশেষ প্রয়োগকৃত মোড সম্পর্কে জানুন।
• মোড প্রয়োগ সারি: প্রয়োগের অপেক্ষায় থাকা মোডগুলো দেখুন।

উদাহরণস্বরূপ:

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: []
----------------

অর্কেস্ট্রেটর দ্বারা পরিচালিত স্বতন্ত্র পরিষেবা বান্ডেলগুলি সম্পর্কে আরও জানতে, লাইফসাইকেল ম্যানেজার থেকে বিদ্যমান dumpsys ফাইলটি নিম্নরূপে ব্যবহার করুন:

dumpsys google.sdv.lifecycle.ILifecycleManager/default

এর মাধ্যমে প্রতিটি সার্ভিসের লাইফসাইকেল অবস্থা সম্পর্কে বিস্তারিত তথ্য পাওয়া যায়। Orchestrator dumpsys আউটপুটের সাথে Lifecycle Manager-এর আউটপুট একত্রিত করলে VM-এর মধ্যে থাকা সার্ভিস বান্ডেলগুলোর লাইফসাইকেলের একটি সম্পূর্ণ চিত্র ফুটে ওঠে।