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.

Orkestratör dağıtılmış yapılandırma şeması

Ş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

Orkestratör 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ı 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 kaydedilir. Değeri çalışma zamanında değiştirebilirsiniz. Bu, testler 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 veya geçici değişiklikler yapmak için kullanışlı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 amacıyla 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

Yeni yapılandırmaların çalışma zamanında yüklenebilmesi için orkestrasyon yapılandırmasını .textproto biçiminde (örneğin, yapılandırılmış metin olarak) tanımlayın.

Yapılandırma söz dizimi

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

Hizmet paketleri

Her hizmet paketi, paketi Orchestrator içinde 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 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 moda 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 bildirim, 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

Sanal makine adı, yapılandırmada açıkça belirtilmemiş. Yapılandırma sanal makine başına tanımlandığından sanal makine adı, 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. Orchestrator tarafından yürütülebilmesi için örneklerin 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

Hizmet örneklerini hizmet gruplarına dahil ederek de yapılandırabilirsiniz. Hizmet paketi yapılandırma düzeyinde, gruplara örnekler ekleyebilirsiniz. Ardından, grupları sanal makine yapılandırması 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ı

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

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

VM 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. Orkestratör, her örneğin belirtilen durumda olmasını sağlar.

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

Gruptan gruba eşleme

Gruplar başka grupları içerebilir. group_1'nın subgroup_2 içerdiğini beyan ederek subgroup_2'daki tüm hizmet örneklerini group_1'ya 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ülmesi 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 bir Boole koşulu altında tanımlanan örnek durumun uygulanmasına olanak tanır. Bu koşul, true olarak değerlendirilir. 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, düzenleme 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ği için geçerli olur. Örneklerin duruma getirildiği zamanla ilgili herhangi bir sıra uygulanmaz.

Desteklenen eyaletler şunlardır:

  • Service::on_start arandıktan sonra started.

  • 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.

Kural grubu

Yapılandırma durumu, koşula bağlı olarak etkin veya etkin değil 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ı aşağıdaki 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 sırası 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

Orchestrator, hizmet paketi çökmelerini ve yaşam döngüsü geçişi hatalarını işlemek için sağlam bir mekanizma sağlar. Orchestrator, hizmet durumları hakkında bütünsel bir görünüme sahip olduğu ve mod geçişlerini yönettiği için 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 Düzenleyici'ye bildirir. LM'ye gereksiz bağlayıcı çağrılarını önlemek için düzenleyici, 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. max_retries yapılandırmada 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ışı

Orkestratör'ü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 (son mod geçişinden itibaren) değilse 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) Orchestrator'a 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 Lifecycle Manager 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 bozulmuş 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 başarısızlıklar nedeniyle (örneğin, kilitlenme ile sonuçlanan bir geçiş hatası) yeniden deneme sınırını aşarsa yeniden deneme sayacı sıfırlanana kadar yeniden başlatılmaz.

Durumun Durum Monitörü'ne Bildirilmesi

Orchestrator, Health Monitor'un (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. Orchestrator, bu arayüz üzerinden aşağıdakilerin her ikisini de aktif olarak 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" }
}
Gemide yaşam örneği

  • 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örlerini çalışır durumda olarak 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 verilmektedir:

  • İ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 kurma mantığını tanıtan VM düzeyinde bir proto yapılandırması

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 özelliği 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. Lifecycle Manager: Bu hizmet, gelen tüm istekleri işlemekten sorumlu olan Binder iş parçacığı havuzunun boyutunu hesaplamak için mülkün değerini kullanır. Bu, LM'nin düzenleyiciden 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ü, BoardConfig.mk değişkenine ekleyerek cihazınızın BoardConfig.mk dosyasında ayarlayabilirsiniz.BOARD_BOOTCONFIG 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 uygun BoardConfig.mk dosyasında bu satırı değiştirin ve yeniden oluşturun.

Başlatma süresi optimizasyonu

ro.sdv.orchestrator.state.ready, write-once boole özelliği olup başlatma zamanı performans optimizasyonu stratejisinin bir parçasıdır. Bu, Orchestration aracısının ilk kullanıma hazırlama işlemini tamamladığını ve hizmet paketlerinin yaşam döngüsünü yönetmeye hazır olduğunu gösterir. Bu aracının temel 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.

  • Ayarlayan: 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 başlatma 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 düzeni 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 aracıları: 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 daha hızlı, daha deterministik ve daha verimli bir sistem başlangıcı sağlar.

Orchestrator tarafından kullanılan modlar

Düzenleme aracısı, VPM tarafından iletilen araç ve güç modlarına etkin bir şekilde abone olur. 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. Orkestratör 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. çalışma modu [Park veya Sürüş modunda] ve güç durumu [Açık ve Askıya Alındı]) hakkında bilgi sahibi olmasını sağlar. Orkestratör, hangi hizmet paketlerinin Orkestratör yapılandırmasına göre çalıştırılması 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 özgü modları destekliyoruz. Bu modlar, mevcut araç ve güç modlarını genişletmez. Bunun yerine, yeni modlar tanımlamanıza olanak tanır.

İşlevsellik:

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

  • Bileşen: 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 hareket eder.

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

  • Doğrulama sorumluluğu: Geçerli durum geçişlerinin sağlanmasından OEM'ler 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 sayısı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 gibi belirli işlemler ve OEM tarafından tanımlanan öneme sahip diğer benzer etkinlikler 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ı beyan etmek 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 başlatılacak şekilde nasıl yapılandırı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 Orchestrator, yayılma işlemi tamamlandıktan sonra durumunun değiştirilmesi gereken hizmet paketlerinin listesini bulmak için 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, sunucu için 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ıldı durumuna geçiş yapmaz.

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

Orchestrator'ın güç modu dışındaki bir güncellemeyi işlediği ve yürütülecek modlar sırasına bir güç isteğinin eklendiği durumlarda, 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 kuyruktaysa 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 müşterinin 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şlem sonucunda:

  • 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 zorunlu mod veya devam eden bir mod yoksa son zorunlu 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: []
----------------

Orkestratör tarafından yönetilen bireysel 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'ın çıkışıyla birleştirerek sanal makinedeki hizmet paketlerinin yaşam döngüsü hakkında eksiksiz bir görünüm elde edebilirsiniz.