Orchestrator'ı yapılandırma

Orkestratör, her sanal makinede (VM) çalışan yerel bir SDV aracısıdır ve hizmet paketlerinin ne zaman oluşturulması, başlatılması, durdurulması veya yok edilmesi gerektiğini kontrol etmek için bir mekanizma sağlar. Bu işlem, hizmet paketi örneklerinde işlemlerin ne zaman ve nasıl gerçekleştirileceğini belirleyen bir dizi kural tanımladığınız bir düzenleme yapılandırması aracılığıyla yapılır. Bu kurallar; araç, güç ve özel modlara göre belirlenir.

Orchestrator'ı yapılandırma APEX'lerinde veya VM başına yapılandırmalar aracılığıyla yapılandırabilirsiniz. Bu dağıtılmış yapılandırma sistemi, her hizmet paketinin bölümlerinin Hizmet Paketi Kayıt Defteri aracılığıyla bağımsız olarak güncellenmesine olanak tanır.

Şekil 1. Orkestratör yapılandırma şeması.

Araçtan bağımsız yapılandırmalar, OEM'ye veya araca bağlı olarak değişmez. Yapılandırma, her OEM'nin tüm araçlarında aynı kalır. Araca özel yapılandırmalar, farklı OEM'ler tarafından üretilen farklı araçlarda değişiklik gösterebilir. Ancak belirli bir OEM tarafından üretilen tüm araçlarda yapılandırma tümü için aynı olabilir.

Yapılandırma APEX'leri

Çalışma zamanında, Orchestrator her hizmet paketi için bir SDV düzenlemesi getirmek üzere hizmet paketi kayıt defterine gider, her yapılandırmayı yükler ve ayrıştırır. Daha fazla bilgi için Orkestrasyon meta verileri konusuna bakın.

Sanal makine başına yapılandırma

Düzenleyici başlatıldığında sanal makine yapılandırmasını (varsa) yükleyip ayrıştırır. Bu yapılandırma dosyasının mutlak yolu, persist.sdv.orchestrator_config_path ve ro.boot.sdv.orchestrator_config_path sistem özellikleri aracılığıyla belirtilir.

Sistem, önyükleme sırasında sanal makine yapılandırma dosyasının yolunu aşağıdaki hiyerarşiye göre belirler:

1. Sistem, persist.sdv.orchestrator_config_path özelliğini kontrol eder. Değeri varsa bu yol kullanılır. Bu değer, yeniden başlatma işlemleri arasında kalıcıdır veya çalışma zamanında ayarlanır.

2. persist.sdv.orchestrator_config_path boşsa sistem ro.boot.sdv.orchestrator_config_path özelliğini kontrol eder. ro.boot.sdv özelliğinin değeri varsa bu yol, persist özelliğine kopyalanır ve geçerli başlatma ile gelecekteki tüm başlatmalar için kullanılır (geçersiz kılınmadığı sürece).

persist.sdv.orchestrator_config_path

persist.sdv.orchestrator_config_path, SDV Orchestrator aracısının yapılandırma dosyasının yolunu almak için kullandığı birincil özelliktir. Bu, kalıcı bir özelliktir. Yani değeri cihaz yeniden başlatıldığında da korunur. Değeri çalışma zamanında değiştirebilirsiniz. Bu, test veya belirli senaryolar (ör. uçtan uca testler) için yararlıdır.

Değeri, çalışma zamanında setprop komutunu kullanarak, derleme süresinde ise .mk uzantılı bir makefile veya .rc uzantılı bir kaynak komut dosyası kullanarak ayarlayabilirsiniz.

Çalışma zamanında özelliği ayarlama

Değer yeniden başlatma işlemleri arasında kaydedildiğinden, özelliği çalışma zamanında ayarlamak test etme veya geçici değişiklikler yapma açısından faydalıdır:

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

Özelliği derleme süresinde ayarlama

Bu özelliği cihazınızın derleme yapılandırmasının bir parçası olarak ayarlamak için ürününüzün veya kartınızın makefile'ına bir satır ekleyin. Bu, yeni bir cihaz resmi için varsayılan değer ayarlamak üzere idealdir.

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

Bu özelliği bir kaynak komut dosyası içinde de ayarlayabilirsiniz:

# 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 özelliği için başlangıç değeri sağlamak üzere kullanılan, başlatma zamanında salt okunur bir özelliktir. Sistem başlatıldığında persist.sdv.orchestrator_config_path boşsa ro.boot.sdv.orchestrator_config_path değeri buraya kopyalanır. persist.sdv.orchestrator_config_path ayarlandıktan sonra sonraki başlatmalarda bu özellik tarafından üzerine yazılmaz.

ro.boot.sdv.orchestrator_config_path değerini bootconfig veya kernel cmdline kullanarak ayarlayabilirsiniz.

Dosya biçimi

Orkestrasyon yapılandırmasını .textproto biçiminde (örneğin, yapılandırılmış metin olarak) tanımlayın. Böylece, yeni yapılandırmalar çalışma zamanında yüklenebilir.

Yapılandırma söz dizimi

Bu bölümde, yapılandırma söz dizimi açıklanmaktadır.

Hizmet paketleri

Her hizmet paketi, Orchestrator'daki paketi tanımlayan ve paket örneğinin yaşam döngüsünü yönetmek için kullanılan hizmet paketi yapılandırmasıyla tanımlanmalıdır. Hizmet paketi yapılandırması şunları tanımlar:

• InstanceToGroupMapping, aynı hizmet paketinin örnekleri arasında bağımlılık oluşturmak için hizmet paketinin bir örneğini bir gruba dahil etmenize olanak tanır.

• InstancesStates, hizmet paketi örneğinin farklı durumlarını tanımlar.

• InstancesStateConfiguration, koşul true olarak değerlendirilirse bir hizmet paketi örneğinin ayarlanması gereken durumu (InstancesStates) tanımlar.

• ServiceBundleConfig, belirli hizmet paketi ve örnekleri hakkında bilgi içerir. Paket için ilgili InstanceToGroupMapping ve InstancesStateConfiguration değerlerini içerir.

• CustomModes, paketin yayınlamasına izin verilen özel modların listesini tanımlar. CustomModes, yetkisiz bir paketin özel modun değerini değiştirmesini engellemek için kullanılır. Hizmet paketi herhangi bir özel modda yayınlanmayabileceğinden bu alan isteğe bağlıdır. Daha fazla bilgi için Özel modlar başlıklı makaleyi inceleyin.

Gerekli paket yapılandırması

Paket yapılandırması en azından şu özellikleri sağlar:

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

    instance: "instance_1"
    instance: "instance_n"
}

Bu beyan, ilgili FQIN'lerle n hizmet paketi örneklerini tanımlar:

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

VM adı, yapılandırmada açıkça belirtilmemiş. Yapılandırma sanal makine başına tanımlandığından, sanal makine adı her zaman yapılandırma dosyasının dağıtıldığı sanal makinenin adıdır ve orkestrasyon aracısı tarafından zaten bilinir.

Örnekleri yapılandırma

Hizmet paketi örneklerinin bildirilmesinin etkisi yoktur. Örneklerin Orchestrator tarafından yürütülebilmesi için yapılandırılması gerekir. Örneğin, Orchestrator'a bir örneğin hangi koşullarda (veya sanal makinenin ya da aracın hangi durumda) çalışması gerektiği bildirilmelidir. Örnekleri yapılandırmak için yapılandırma durumları şu şekilde tanımlanmalıdır:

• condition, değerlendirilmesi gereken sanal makine veya araç durumuyla ilgili bir ifadedir.

• instances_states, koşul true olarak değerlendirilirse uygulanması gereken, örnek başına bir durum kümesidir.

Daha fazla bilgi için Koşullar başlıklı makaleyi inceleyin.

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

Örnekten gruba eşleme

Ayrıca, hizmet örneklerini hizmet gruplarına dahil ederek de yapılandırabilirsiniz. Hizmet paketi yapılandırma düzeyinde, gruplara örnekler ekleyebilirsiniz. Daha sonra grupları sanal makine yapılandırma düzeyinde yapılandırabilirsiniz. Daha fazla bilgi edinmek için sonraki bölüme ve Hizmet paketleri başlıklı makaleye bakın.

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

Proto şeması

İşte bir proto şema örneği:

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

Sanal makine düzeyinde yapılandırma

Sanal makine yapılandırması, grup eşlemelerinin tanımlanmasını ve grupların yapılandırılmasını sağlar. Hizmet paketleri arasındaki bağımlılıkları sanal makine düzeyinde modellemek için kullanılır. Böylece, birden fazla hizmet paketinin durumunu aynı anda değiştirme esnekliği sağlanır. Bir grubun tüm örnekleri belirtilen duruma getirilir.

Orchestrator, durum değişikliğinin yürütülme sırasını garanti etmez. Orchestrator, her örneği belirtilen duruma yükseltir.

Gruplar, yapılandırma bölümlerinden herhangi birinde group adı kullanılarak örtülü olarak tanımlanır. Örneğin, örnekten gruba eşleme, gruptan gruba eşleme ve grup yapılandırma durumları.

Gruplar arası eşleme

Gruplar, başka gruplar içerebilir. group_1 öğesinin subgroup_2 içerdiğini belirterek subgroup_2 içindeki tüm hizmet örneklerini group_1 öğesine etkili bir şekilde ekleriz.

Örneğin:

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

Grup yapılandırma

Bir grubu bildirmek herhangi bir etki yaratmaz. Grupların Orchestrator tarafından yürütülebilmesi için yapılandırılması gerekir. Örneğin, Orchestrator'a grupların hangi koşullarda veya sanal makinenin ya da aracın hangi durumunda çalışması gerektiği bildirilmelidir.

Grupları hizmet örneklerine benzer şekilde, yani yapılandırma durumlarını kullanarak yapılandırabilirsiniz. Tek fark, söz diziminde instances_states yerine groups_states kullanılmasıdır:

state {
    condition {
        power_state: "ON"
    }

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

Proto şeması

Aşağıda örnek bir proto şeması verilmiştir:

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

Yapılandırma durumları

Yapılandırma durumları (durumlar), bir hizmet örneğinin veya grubunun ne zaman başlatılacağını, durdurulacağını ya da yok edileceğini tanımlar ve conditions ile instances_states (paket yapılandırması) ve groups_states (VM yapılandırması) öğelerinden oluşur.

Koşullar

Koşullar, modelin true olarak değerlendirildiğinde tanımlanan örnek durumun uygulandığı bir Boole koşuluna sahip olmasını sağlar. Bir koşul şu özelliklere sahiptir:

• Güç, araç ve özel mod gibi desteklenen sinyallere dayalı olarak rastgele karmaşık Boole ifadesi (and veya not ifadeleriyle oluşturulur).

• (İsteğe bağlı) Koşul içermeyen yapılandırma durumu her zaman aktiftir. Yani true olarak değerlendirilir.

Örnek durumları ve grup durumları

instances_states ve groups_states bu özelliklere sahiptir.

• Durum active olduğundan, orkestrasyon aracısının belirli örnekler veya gruplar için hangi durumların gerekli olduğunu belirleyin.

• Gruba bir durum uygulandığında bu durum, gruptaki her hizmet paketi örneğine uygulanır. Örneklerin duruma ne zaman getirileceğiyle ilgili bir sıra uygulanmaz.

Desteklenen eyaletler şunlardır:

• Service::on_start arandıktan sonra started aranır.

• created

  • Service::new çağrıldıktan sonra ancak Service::on_start çağrılmadan önce.

    VEYA

  • Service::on_stop çağrıldıktan sonra ancak Service::drop çağrılmadan önce.

• Service::drop arandıktan sonra destroyed aranır.

Kural grubu

Yapılandırma durumu, koşula bağlı olarak etkin veya etkin olmayan olabilir. İstediğiniz zaman birden fazla durum etkin olabilir. Bir düzenleme aracısı sinyal güncellemesi aldığında, hizmet paketlerinin yaşam döngüsü değiştirilmeden önce tüm yapılandırma durumları değerlendirilir. Hizmet örneği durumları şu kurallara göre değerlendirilir:

• Etkin durumlardan hiçbiri hizmet örneği için geçerli olmadığında hizmet örneği yok edilir.

• Bir veya daha fazla etkin durum geçerli olduğunda şu öncelik uygulanır:

  1. destroyed mutlak önceliğe sahiptir.
  2. started, created tarihinden önce gelir.

Proto şeması

Aşağıda örnek bir proto şeması verilmiştir:

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

Kilitlenme kurtarma ve yeniden başlatma stratejisi

Orkestratör, hizmet paketi çökmelerini ve yaşam döngüsü geçişi hatalarını işlemek için güçlü bir mekanizma sağlar. Orchestrator, hizmet durumlarına ilişkin bütünsel bir görünüme sahip olduğundan ve mod geçişlerini yönettiğinden yeniden başlatma ve yeniden deneme stratejisini yürütmek için en uygun bileşendir. Yaşam Döngüsü Yöneticisi (LM), hizmet paketi kilitlenmelerini bağlayıcı ölüm bildirimleri aracılığıyla Orchestrator'a bildirir. LM'ye gereksiz bağlayıcı çağrılarını önlemek için Orchestrator, her paketin son durumunu (başarılı olup olmadığı) önbelleğe alır ve bilinen son durum, istenen yeni durumla aynıysa geçişleri yeniden uygulamaz.

Yapılandırmayı yeniden dene

retry_mapping kullanarak Orchestrator yapılandırmanızda yeniden başlatma ve yeniden deneme stratejisini örnek başına tanımlayabilirsiniz. Yapılandırmada max_retries ayarlanmamışsa varsayılan değer ro.boot.sdv.orchestrator.recovery.max_retries sistem özelliğinden alınır. Bu özellik ayarlanmazsa değer 0 olarak geri döner.

• max_retries: Düzenleyicinin, geçici bir hatadan veya paket kilitlenme bildiriminden sonra geçişi yeniden deneme sayısını tanımlar. Yeniden deneme sayacı, başarılı bir işlemden sonra veya yeni bir mod işlendiğinde max_retries değerine sıfırlanır. Birden fazla eşleme aynı örneği hedefliyorsa en yüksek max_retries değerine sahip olan öncelikli olur.

Yapılandırma örneği

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

Toparlanma davranışı

Orchestrator'ın yeniden başlatma ve yeniden deneme mantığı, çeşitli hata senaryolarını sorunsuz bir şekilde yönetir:

• Normal çalışma sırasında kilitlenme: Bir hizmet paketi çalışırken kilitlenirse Orchestrator, yeniden başlatma stratejisini uygular ve kalan yeniden deneme sayısına göre paketi son istenen durumuna geri getirmeye çalışır.
• Mod geçişi sırasında kilitlenme: Yeni bir mod uygulanırken paket kilitlenirse yeniden başlatma isteği sıraya alınır ve daha sonra işlenir. İstek işlendikten sonra Orchestrator, örneğin son durumunu kontrol eder ve yalnızca örnek son istenen durumda değilse (son mod geçişinden itibaren) yeniden başlatmayı uygular.
• Kurtarma sırasında yeni mod: Bir paket yeniden başlatılırken (veya yeniden başlatılacak örnekler sırasındayken) Düzenleyici'ye yeni bir moda geçiş isteği gelirse devam eden kurtarma işlemi iptal edilir. Yeni mod geçişi devreye girer ve yeni hedef durum için yeni bir deneme grubu sağlamak üzere yeniden deneme sayacı sıfırlanır.

Orkestratör, yeniden deneme stratejisini belirlemek için Yaşam Döngüsü Yöneticisi tarafından döndürülen farklı hata türlerini ayırt eder:

• Geçici hatalar (SERVICE_NOT_FOUND, OPERATION_FAILED, INTERNAL_ERROR): Düzenleyici, herhangi bir özel temizleme işlemi yapmadan işlemi yeniden dener.
• Kalıcı hatalar (VALUE_CORRUPTED, INVALID_ARGUMENT): Düzenleyici, hizmet paketinin bozuk durumda olabileceğini varsayar ve temiz bir yeniden başlatma sağlamak için işlemi yeniden denemeden önce hizmet örneğini sonlandırmaya çalışır.
• Kalıcı hatalar (PERMISSION_DENIED): İşlem yeniden denenmez ve paket kurtarılamaz durumda kabul edilir.

Yaşam Döngüsü Yöneticisi kilitlenirse tüm hizmet paketi işlemleri kaybolur. Gerçek durum bilinmediğinden Orchestrator her örneği geçersiz kılar ve her örneği son istenen duruma getirmek için kalan yeniden denemelerle bir yeniden başlatma stratejisi uygular.

Tekrarlı olarak çöken veya başarısız olan paketlerde sonsuz kurtarma döngülerini önlemek için yeniden deneme sayacı yalnızca bir yaşam döngüsü işlemi başarılı olduğunda ya da yeni bir mod geçişi istendiğinde max_retries olarak sıfırlanır. Bir paket, art arda hatalar nedeniyle yeniden deneme sınırını aşarsa (örneğin, geçiş hatasının ardından kilitlenme olursa) yeniden deneme sayacı sıfırlanana kadar yeniden başlatılmaz.

Durumun Durum Monitörü'ne Bildirilmesi

Orchestrator, Health Monitor'ün (HM) kaydolduğu dahili bir bağlayıcı arayüzü sunar. Bu arayüz, tüm hizmet paketlerinin durumu hakkında sürekli güncellemeler almasını sağlar. Orkestratör, bu arayüz üzerinden aşağıdakilerin her ikisini de etkin bir şekilde bildirir:

• Yaşam döngüsü durumu: Mevcut yapılandırmaya ve etkin modlara (ör. başlatıldı, oluşturuldu veya yok edildi) göre örneğin amaçlanan durumu.
• Kurtarma durumu: Amaçlanan yaşam döngüsü durumuna ulaşma durumu. Bu durum, örneğin çalışır durumda olup olmadığını, şu anda bir hatadan sonra yeniden deneme yapıp yapmadığını veya tüm yeniden denemeler tükendikten sonra kurtarılamadığını gösterir.

Bu bilgiler, kalp atışı izleme için kaydedilmemiş olanlar da dahil olmak üzere tüm örnekler için raporlanır. HM, sanal makinenin durumunu bildirmek için API'lerini uygulamak üzere bu bilgileri kullanır. Daha fazla bilgiyi Sağlık izleme başlıklı makalede bulabilirsiniz.

Örnekler

Bu bölümde, koşullarla durumları yapılandırma örnekleri verilmektedir.

Temel hizmet örneği

• Koşulu olmadığından her zaman aktiftir.
• Tek bir hizmet örneğini başlatır.

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

HVAC uygulaması örneği

• Koşul: custom_state != occupancy.OCCUPANCY_EMPTY || custom_state == preheat.PREHEAT_ON olduğunda etkin.

• HVAC ile ilgili birden fazla hizmet örneğini started olarak bildirir.

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

Güç tasarrufu örneği

• Koşul: custom_state == system_power.SYSTEM_POWER_LOW && custom_state == range_ext.RANGE_EXT_ON olduğunda etkin.

  Bu durum, güç tasarrufu durumu olarak değerlendirilebilir.

• HVAC ile ilgili bir hizmet örneğini destroyed olarak bildirir.

• Bu örnekte, SYSTEM_POWER_LOW ve RANGE_EXT_ON modları etkin olduğunda HVAC uygulaması RefrigerantLoop hizmet örneği olmadan çalışır:

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

Gemideki yaşamla ilgili örnek

• Durum: power_state == ON && vehicle_state == LIFE_ON_BOARD ise etkin.

  Bu durum, Arabanın içinde biri var ve araba açık olarak değerlendirilebilir.

• Sıcaklık sensörlerinin çalıştığını bildirir.

• Aracın içinde birisi varken güvenlik nedeniyle sıcaklık gibi öğeler izlenir.

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

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

Örnekler

Bu bölümde aşağıdakileri içeren tam örnekler sunulmaktadır:

• İki örneği olan bir hizmet paketi sunan hizmet paketi düzeyinde bir proto yapılandırma. Bu örneklerin her biri bir grubun parçasıdır.

• Gruplarla modlara göre etkileşim kurmak için mantık sunan, sanal makine düzeyinde bir proto yapılandırma

Hizmet paketi düzeyinde yapılandırma

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

Sanal makine düzeyinde yapılandırma

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

Paket yönetimi paralelliğini yapılandırma

ro.boot.sdv.max_bundles_management_threads sistem özelliği, hizmet paketi yaşam döngüsü işlemleri sırasında performansı ve kaynak tüketimini kontrol etmek için kullanılan önemli bir ayarlama parametresidir. Hizmet paketleri işlemlerinde maksimum paralellik düzeyini tanımlar ve doğrudan iki temel hizmeti etkiler:

1. Orchestration Engine: Bu hizmet, Orchestrator'ın Lifecycle Manager'a kaç eşzamanlı çağrı (ör. startService, stopService) yapabileceğini belirlemek için mülkü okur. Bu, birçok paketin aynı anda durum değiştirebileceği başlatma ve mod geçişleri sırasında performans açısından çok önemlidir.

2. Yaşam Döngüsü Yöneticisi: Bu hizmet, tüm gelen istekleri işlemekten sorumlu olan Binder iş parçacığı havuzunun boyutunu hesaplamak için mülkün değerini kullanır. Bu, LM'nin Orchestrator'dan gelen eşzamanlı istekleri işlemek için yeterli iş parçacığına sahip olmasını sağlar.

Bu özellik ayarlanmazsa her iki hizmet de varsayılan olarak 12 değerini kullanır.

Yapılandırma yöntemi

Mülkü, BOARD_BOOTCONFIG değişkenine ekleyerek cihazınızın BoardConfig.mk dosyasında ayarlayabilirsiniz. Bu sayede, cihaz her başlatıldığında değerin uygulanması sağlanır.

BOARD_BOOTCONFIG += \
    androidboot.sdv.max_bundles_management_threads=8

Cihazınızın değerini değiştirmek için bu satırı uygun BoardConfig.mk dosyasında değiştirin ve yeniden oluşturun.

Başlatma süresi optimizasyonu

ro.sdv.orchestrator.state.ready, başlatma zamanı performans optimizasyon stratejisinin bir parçası olan write-once boole özelliğidir. Bu, Orchestration aracısının başlatma işlemini tamamladığını ve hizmet paketlerinin yaşam döngüsünü yönetmeye hazır olduğunu gösterir. Birincil amacı, diğer SDV aracıların başlatma sırasını kontrol ederek Orchestrator'ın ve yönetilen hizmet paketlerinin başlatılmasına öncelik vermektir.

• Ayarlandı: Düzenleme aracısı.
• Ne zaman: Açılış sırası sırasında bir kez.
• Kullanım: Bu özellik, çoğu SDV aracısının (Güncelleme Yöneticisi, VSIDL sağlayıcı, Sağlık Monitörü, Hizmet Bulma, Veri Tüneli, RPC, VPM ve Telemetri) başlatma sırasını kontrol etmek için init sistemi tarafından kullanılır. Düzenleyiciyi erken başlatıp diğer ajanların bu özellik için beklemesini sağlayarak sistem, düzenleyicinin sistem kaynakları için rekabet etmeden hizmet paketlerini başlatma gibi kritik görevine başlayabilmesini sağlar.

Performans

Sistemin başlatılması sırasında tüm aracıların aynı anda başlatılması kaynak çekişmesine yol açabilir ve genel başlatma sürecini yavaşlatabilir. Bunu azaltmak için sistem özellikleri kullanılarak sıralı bir başlatma sırası uygulanır:

1. Hizmet paketleri kayıt defteri: Tüm hizmet paketi meta verilerini yüklemek için önce bu kayıt defteri başlatılır.
2. Yaşam Döngüsü Yöneticisi ve Düzenleyici: Bu temel aracılar, kayıt defteri hazır olur olmaz çalışmaya başlar. Bu erken başlangıç, Orchestrator'ın yapılandırmasını değerlendirmeye başlamasına ve hizmet paketlerini hemen başlatmaya hazırlanmasına olanak tanıdığı için çok önemlidir.
3. Diğer SDV temsilcileri: Yalnızca düzenleyici hazır olduktan sonra başlatılır.

Bu kontrollü sıra, Orchestrator'ın hizmet paketlerini mümkün olan en kısa sürede başlatmak için sistem kaynaklarını kullanma önceliğine sahip olmasını sağlar. Bu da sistemin daha hızlı, daha deterministik ve daha verimli bir şekilde başlatılmasını sağlar.

Orchestrator tarafından kullanılan modlar

Düzenleme aracısı, VPM tarafından iletilen araç ve güç modlarına etkin bir abonelikle bağlı kalır. Orchestrator ile Araç ve Güç Yönetimi (VPM) sistemi arasında ilk bağlantı kurulduktan sonra Orchestrator, aşağıdaki boolean sistem özelliklerini true olarak ayarlar:

• sdv.orchestrator.bootup.power_mode.ready

• sdv.orchestrator.bootup.vehicle_mode.ready

Düzenleme aracısı, yapılandırma dosyasını referans olarak kullanarak alınan modların geçerli değerlerine göre çalışan durumda olması gereken hizmet paketleri grubunu dinamik olarak hesaplar. Orkestrasyon aracı daha sonra yaşam döngüsü yöneticisiyle iletişim kurarak hizmet paketlerinin gerçek durumunu hesaplanan hedef durumla eşleştirmek için farklı komutlar verir.

Araç ve güç durumları

Araç modu ve güç yönetimi (VPM) aracısı, SDV bileşenlerinin aracın mevcut durumu (ör. Park veya Sürüş gibi çalışma modu ve Açık ve Askıya Alındı gibi güç durumu) hakkında bilgi sahibi olmasını sağlar. Orkestratör, hangi hizmet paketlerinin Orkestratör yapılandırmasına göre çalışması gerektiğini tanımlamak için bu değerleri değerlendirir. Daha fazla bilgi için Araç ve güç yönetimi başlıklı makaleyi inceleyin.

Özel modlar

Çok sayıda araç modu olduğundan hepsini modelleyemiyoruz. Her OEM'nin farklı ihtiyaçları vardır ve araç modlarının standartlaştırılması tüm OEM kullanım alanlarını karşılayamaz. Bu nedenle, özel modlar olarak bilinen OEM'e özel modları destekliyoruz. Bu modlar, mevcut araç ve güç modlarını genişletmez. Bunun yerine, yeni modlar tanımlamanın bir yolunu sunarlar.

İşlevsellik:

• Genel kapsam: Özel modlar geneldir ve Orchestrator tarafından yönetilen tüm VM'lere eşit şekilde uygulanır.

• Bileşim: Her özel mod değişikliği iki öğeden oluşur:

  • Ad: OEM tarafından özel modu temsil etmek için seçilen benzersiz tanımlayıcı.

  • Değer: Özel modun mevcut durumu. Değer ayarlanmadığında UNDEFINED olabilir.

• Orkestratör rolü: Orkestratör, özel mod değerlerinin pasif alıcısı olarak işlev görür.

• Hizmet paketi rolü: Her hizmet paketi birden fazla özel moda sahip olabilir ve bunlardan herhangi birinde yeni değerler yayınlayabilir. Birden fazla hizmet paketi aynı özel moda sahip olabilir. Bu da özel bir modun farklı kaynaklardan yeni değerler alabileceği anlamına gelir.

• Doğrulama sorumluluğu: OEM'ler, geçerli durum geçişlerinin sağlanmasından sorumludur. Orkestratör, yeni değerleri kabul eder.

Tahmini özellikler:

• Tahmini sayı: Güç ve araç modları, çoğu hizmet paketinin yaşam döngüsünü yönetir. Özel modlar ise ek bir rol oynar. Özel modların büyüklük sırasının yüzlerle değil, onlarca olmasını bekliyoruz.

• Tahmini zamanlama: Modlar belirli aralıklarla gönderilmez. Bunun yerine modlar, kapı açma, park etme sırası başlatma, şarj döngüsü başlatma ve OEM tarafından tanımlanan benzer önemdeki diğer etkinlikler gibi belirli işlemler tarafından tetiklenen, etkinliğe dayalıdır.

Özel mod tasarımı, belirli modları tanımlama ve yönetme esnekliği sağlarken Orchestrator'ın temel durum makinesi mantığına karşı tarafsız kalmasına olanak tanır.

Desteklenen modlar

Hizmet paketlerinin yalnızca sahip oldukları özel modlarda yayınlanmasını sağlamak için her birinin, hizmet paketi kayıt defteriyle yerel sanal makinede bulunan Orchestrator yapılandırmasında sahip olunan özel modların listesini açıkça belirtmesi gerekir. Bildirilmemiş bir özel moda yayınlama girişimleri silinir.

Bir hizmet paketinin yayınlamasına (dolayısıyla sahip olmasına) izin verilen özel modları tanımlamak için service_bundle_config proto şeması aşağıdakilerle genişletilir:

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

Modlara göre paketleri yapılandırma

Mevcut Orchestrator proto yapılandırması (Condition bileşeni), özel modlara dayalı hizmet paketlerinin değiştirilmesini destekler:

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

Proto örneği

Aşağıdaki örnekte, bir hizmet paketinin örneklerinin TURN ve FOG durumuna göre nasıl başlatılacağı gösterilmektedir:

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

}

Yeni özel modlar ayarlama

Yeni bir özel mod değeri ayarlama süreci, istenen değeri aynı sanal makinede çalışan yerel düzenleyiciye ileten hizmet paketiyle başlar. Ardından Orchestrator, hizmet paketinin belirtilen özel moda yayınlamak için gereken izinlere sahip olduğunu doğrular. Değeri diğer VM'lere yayması gerekip gerekmediğini belirlemek için .textproto içinde tanımlanan yapılandırmaya başvurur. Her düzenleyici, yaygınlaştırma işleminden sonra durumunun değiştirilmesi gereken hizmet paketlerinin listesini bulmak için kendi yapılandırmasını inceler.

RPC

Her sanal makinede çalışan her Orchestrator, yeni özel mod değerlerini dinlemek için bir RPC sunucusu oluşturur. Özel bir modu güncellemek isteyen her hizmet paketi, sunucuya bir RPC istemcisi oluşturmalıdır. Yetkisiz paketlerin sunucuya bağlanmasını önlemek için ACL'ler uygulanır.

RPC üzerinden yeni bir değer ayarlamaya yönelik proto tanımı şu şekilde görünür: örnek:

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

Güç geçişlerinin iptali

Orchestrator, SHUTDOWN_CANCELLED güç modu (VPM tarafından Orchestrator'a gönderilir) aracılığıyla devam eden güç geçişlerinin iptal edilmesine olanak tanır.

Örnek olarak aşağıdaki Orchestrator yapılandırmasını ele alalım:

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

SHUTDOWN_CANCELLED modu alındığında, Orchestrator'ın davranışını iki temel senaryo belirler. Her iki durumda da SHUTDOWN_CANCELLED güç modu, sıranın sonuna eklenir. Ardından, sıraya alınmış öğeler tüketildikten sonra SHUTDOWN_CANCELLED yürütülür.

Senaryo 1: Devam eden mod bir güç modu

Orchestrator bir güç modu güncellemesi yürütüyorsa devam eden modun iptal edilmesi istenir. Yaşam Döngüsü Yöneticisi, devam eden bir geçişin iptal edilmesini doğal olarak desteklemese de Orchestrator, yeni hizmet paketi isteklerinin başlatılmadığını doğrular.

Örnek: Önceki örnekteki yapılandırmadan alınan instance-1, SHUTDOWN_CANCELLED modu alındığında başlatılma sürecindeyse instance-1 başlatma işlemini tamamlar. Ancak instance-2 ve instance-3, başlatılan duruma geçiş yapmaz.

2. senaryo: İşleme kuyruğunda bir güç modu var

Orchestrator, güç modu dışındaki bir güncellemeyi işlerken ve yürütülecek modlar sırasına bir güç isteği eklendiğinde güç geçişi sıradan kaldırılır. Bu durum, yürütülmesini engeller.

Örnek: Önceki örnekteki yapılandırma kullanıldığında, Orchestrator güçle ilgili olmayan bir güncelleme (ör. araç güncellemesi) üzerinde çalışıyorsa ve SUSPEND_TO_RAM_ENTER kuyrukta bulunuyorsa SHUTDOWN_CANCELLED sonuçlarının alınması, örneklerin (instance-1, instance-2, instance-3) hiçbirinin başlatılmamasına neden olur.

Uygulama örneği

RPC sunucusuna istemci oluşturmak için ara katman yazılımı tarafından oluşturulan kodu kullanmak isteyen bir istemcinin kataloğu aşağıdaki örnek gibi görünebilir:

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

Kod oluştururken bağımlılığı Orchestrator kataloğuna eklemeniz gerekir:

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

Yeni bir değer göndermek için kullanılan istemci kodu şu şekilde görünür:

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

Hata ayıklama araçları

Orchestrator aracısı, dumpsys aracını destekler. Çalışan bir SDV örneğinde aşağıdaki komutu çalıştırarak bu işlevi çağırabilirsiniz:

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

Orchestrator aracısının iç durumunu hata ayıklamak ve bu konuda bilgi edinmek için bu aracı kullanın. Bu işlemi yaptığınızda şunlar gösterilir:

• Mevcut Mod Durumu: Etkin araç, güç ve özel modları görün.
• Özel Mod Yayıncıları: Hangi hizmetlerin özel mod yayınlayabileceğini (ve hangi modlarda) belirleyin.
• Hizmet başına gerekli durum: Önceden tanımlanmış koşullara ve mevcut modlara göre her hizmet paketinin durumunu öğrenin. Bu, bir hizmetin neden beklenen durumda olmadığını teşhis etmeye yardımcı olur.
• Mod Yaptırım Durumu: Devam eden bir yaptırım uygulanan mod veya devam eden bir mod yoksa son yaptırım uygulanan mod hakkında net bir resim elde edin.
• Mod Yaptırım Sırası: Yaptırım uygulanmayı bekleyen modları görüntüleyin.

Örneğin:

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

Orchestrator tarafından yönetilen bağımsız hizmet paketleri hakkında daha fazla bilgi edinmek için Lifecycle Manager'daki mevcut dumpsys'i aşağıdaki gibi kullanın:

dumpsys google.sdv.lifecycle.ILifecycleManager/default

Bu işlem, her hizmetin yaşam döngüsü durumu hakkında ayrıntılı bilgi sağlar. Orchestrator dumpsys çıkışını LifecycleManager'dan alınan çıkışla birleştirmek, sanal makinedeki hizmet paketlerinin yaşam döngüsü hakkında eksiksiz bir resim sunar.