Ab 2026 werden wir, um unser stabiles Entwicklungsmodell für den Trunk zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten, den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen. Verwenden Sie android-latest-release, um AOSP zu entwickeln und dazu beizutragen. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Bereitstellungsanleitung

Für die Cloud Telemetry Simulation-Plattform müssen Sie die Infrastruktur in Ihrem Google Cloud-Projekt bereitstellen.

Auf den Quellcode zugreifen

Der Quellcode für die Cloud Telemetry Simulation-Plattform wird auf GitHub unter aaos-sdv-telemetry-simulator gehostet.

Vorbereitung

Für die Bereitstellung der Plattform müssen die folgenden Voraussetzungen erfüllt sein:

Ein Google Cloud-Projekt mit aktivierter Abrechnung.
Sicherheit der Web-Demo: Wenn Sie die Web-Demo bereitstellen, müssen Sie in Google Cloud unter APIs und Dienste > Anmeldedaten eine OAuth 2.0-Client-ID konfigurieren, um die App Engine-Anwendung zu schützen und den Zugriff auf autorisierte Google-Konten zu beschränken.
Build-Artefakte für Software Defined Vehicle (SDV): Sie müssen eigene kompilierte SDV-Image-Artefakte haben. Diese werden in diesem Repository nicht bereitgestellt.
- cvd-host_package.tar.gz
- sdv_core_cf-img-<version>.zip
Berechtigungen: Der Nutzer oder das Dienstkonto, der bzw. das Terraform ausführt, muss über ausreichende Berechtigungen zum Erstellen der in der Konfiguration definierten Ressourcen verfügen (z. B. Project Editor oder eine benutzerdefinierte Rolle mit Berechtigungen für Compute Engine, Cloud Functions, Identity and Access Management, Cloud Storage und andere erforderliche Dienste).
Tools:
- Google Cloud CLI (gcloud CLI)
- Terraform (verwendete Version im Repository)
- Docker
- Go (verwendete Version für Orchestrator-Funktionen im Repository)

Google Cloud-Infrastruktur bereitstellen

Die Bereitstellung der Simulationsplattform umfasst zwei Hauptschritte: die Bereitstellung der Kerninfrastruktur in Google Cloud mit Terraform und das Erstellen und Übertragen des Docker-Images des Simulations-Agents in Artifact Registry. In diesem Abschnitt wird die Bereitstellung der Infrastruktur beschrieben.

Geben Sie Werte für die folgenden Variablen ein, um die Code-Snippets auf dieser Seite zu aktualisieren:

Terraform-Backend konfigurieren: Erstellen Sie eine Datei, um anzugeben, wo Terraform seine Statusdatei in Cloud Storage speichert. Benennen Sie die Datei mit dieser Syntax:
```
environments/ENVIRONMENT/backend.hcl
```
```
# environments/ENVIRONMENT/backend.hcl
bucket = "TF_BUCKET_NAME"
prefix = "sdv-telemetry-simulation"
```

Projektvariablen konfigurieren: Erstellen Sie eine Datei mit den Details Ihres Projekts. Benennen Sie die Datei mit dieser Syntax:

environments/ENVIRONMENT/variables.tfvars

# environments/ENVIRONMENT/variables.tfvars
project_id       = "PROJECT_ID"
default_region   = "REGION"
default_zone     = "ZONE"
agent_docker_image = "REGION-docker.pkg.dev/PROJECT_ID/sim-agents/simulation-agent"
    # Security: Map logical tags to SHA256 digests

# Security: Map logical tags to SHA256 digests (optional)
supported_agent_builds = {
"latest" = "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"stable" = "sha256:88d4266fd4e6338d13b845fcf289579d209c897823b9217da3e161936f031589"
}

# Parallel Execution Limit (Default: 5)
max_vm_count = 5

Terraform-Konfiguration anwenden: Rufen Sie das Verzeichnis infrastructure auf und initialisieren Sie die Konfiguration und wenden Sie sie an:

# Initialize Terraform with your backend configuration
terraform init -backend-config=environments/ENVIRONMENT/backend.hcl

# (Optional) Preview the changes
terraform plan --var-file=environments/ENVIRONMENT/variables.tfvars

# Apply the changes to deploy the infrastructure
terraform apply --var-file=environments/ENVIRONMENT/variables.tfvars

Simulations-Agent-Image erstellen und per Push übertragen

Der Simulations-Agent führt die Simulation auf der virtuellen Compute Engine-Maschine (VM) aus. Sie erstellen es mit Ihren SDV-Artefakten und übertragen es per Push an Artifact Registry.

So erstellen Sie das Image des Simulations-Agents und übertragen es per Push:

Artefakte platzieren: Kopieren Sie die Dateien cvd-host_package.tar.gz und sdv_core_cf-img-<version>.zip in das Verzeichnis simulation-agent/sdv-image-resources/.

Erstellen und per Push übertragen: Rufen Sie das Verzeichnis simulation-agent auf, erstellen Sie das Image und übertragen Sie es per Push. Ersetzen Sie den Image-Pfad durch den Pfad, den Sie in der Datei variables.tfvars konfiguriert haben.

# Example using the path from the .tfvars example above
export AGENT_IMAGE="REGION-docker.pkg.dev/PROJECT_ID/sim-agents/simulation-agent:latest"

# Build the image
docker build -t $AGENT_IMAGE .

# Push the image to Artifact Registry
docker push $AGENT_IMAGE

Fingerabdrücke aktualisieren: Nachdem Sie ein neues Image übertragen haben, müssen Sie möglicherweise den SHA256-Digest abrufen und die supported_agent_builds-Zuordnung in Ihrer variables.tfvars-Datei aktualisieren. Führen Sie dann terraform apply noch einmal aus.
```
# Get the digest using gcloud
gcloud artifacts docker images describe $AGENT_IMAGE --format="value(image_summary.digest)"
```
Ihre Cloud Telemetry Simulation-Plattform ist bereitgestellt und bereit, Simulationsanfragen anzunehmen.

Betrieb und Fehlerbehebung

Mit dieser Lösung können Sie die integrierten Google Cloud-Tools für die Beobachtbarkeit verwenden. Es verbraucht Rechenressourcen nur pro Anfrage und während der Simulationsausführung.

Kostenverwaltung

Die Architektur ist so konzipiert, dass sie durch die Verwendung von serverlosen und sitzungsspezifischen Ressourcen kostengünstig ist. Die Kosten werden hauptsächlich durch Folgendes verursacht:

Compute Engine: Die Zeit, in der die Simulations-VMs ausgeführt werden, wird in Rechnung gestellt. Durch die Verwendung von Spot-VMs können diese Kosten erheblich gesenkt werden.
Cloud Functions: Abrechnung pro Aufruf.
Cloud Storage: Die Speicherung von Eingabe- und Ausgabedateien sowie Logs wird in Rechnung gestellt.
Firestore: Abrechnung für Lese- und Schreibvorgänge sowie Datenspeicherung.

Beobachtbarkeit

Alle Komponenten sind in die Operations-Suite von Google Cloud eingebunden.

Log-Explorer: Dies ist Ihr primäres Tool zur Fehlerbehebung. Sie können Logs nach Ressource filtern:
- Cloud Functions: Prüfen Sie die Logs für die Funktionen receive-request oder schedule-simulation, um Orchestrierungsprobleme zu beheben.
- Compute Engine: Prüfen Sie die VM-Instanzlogs auf Start- oder Herunterfahrprobleme.
- Simulations-Agent: Der im Docker-Container ausgeführte Agent leitet seine Logs an den Log-Explorer weiter. Filtern Sie nach dem Namen der VM-Instanz, um den detaillierten Simulationsfortschritt zu sehen.
Cloud Storage: Bei abgeschlossenen Simulationen werden die Dateien logcat und bugreport vom Cuttlefish-Gerät in das Ausgabeverzeichnis der Simulation im Cloud Storage-Bucket hochgeladen. So erhalten Sie detaillierte Einblicke in das Verhalten der Android-Umgebung.

Dienstkonten

Terraform erstellt mehrere Dienstkonten, um eine sichere Umgebung mit geringsten Berechtigungen zu ermöglichen. Zu den wichtigsten Dienstkonten gehören:

Ausführungsidentität (VM):
- simulation-agent:
  - Angehängt an: Die Compute Engine-VMs, auf denen die Simulation ausgeführt wird.
  - Rolle: Ermöglicht der VM, Ergebnisse hochzuladen und den Abschluss zu signalisieren.
  - Berechtigungen:
    - roles/storage.objectUser: Liest Eingaben und lädt Artefakte (Logs, Berichte) in Cloud Storage hoch.
    - roles/run.invoker: Authentifiziert und ruft die Funktion finish-simulation auf.
Orchestrierungsidentitäten (Funktionen):
- read-simulations-function:
  - Angehängt an: Die Cloud Functions-Funktion read-simulation.
  - Berechtigungen:
    - roles/datastore.user: Liest Simulations- und laufende VM-Einträge in Firestore.
- receive-request-function:
  - Angehängt an: Die Cloud Functions-Funktion receive-request.
  - Berechtigungen:
    - roles/datastore.user: Erstellt neue PENDING-Simulationsdatensätze in Firestore.
    - roles/storage.objectUser: Prüft, ob die Eingabedateien in Cloud Storage vorhanden sind.
- scheduler-function:
  - Angehängt an: Die Cloud Functions-Funktion schedule-simulation.
  - Berechtigungen:
    - roles/pubsub.subscriber: Ruft Nachrichten aus der Simulationswarteschlange ab.
    - roles/datastore.user: Führt atomare Lese- und Schreibvorgänge für den Zähler running-vms aus.
    - roles/compute.instanceAdmin.v1: Erstellt und startet Compute Engine-VMs.
    - roles/iam.serviceAccountUser: Ermöglicht dieser Funktion, das Dienstkonto simulation-agent den von ihr erstellten VMs zuzuweisen.
- simulation-finisher-function:
  - Angehängt an: Die Cloud Functions-Funktion finish-simulation.
  - Berechtigungen:
    - roles/compute.instanceAdmin.v1: Löscht die VM nach Abschluss der Ausführung.
    - roles/datastore.user: Aktualisiert den Simulationsstatus auf COMPLETED oder FAILED.
- delete-simulation-function:
  - Angehängt an: Die Cloud Functions-Funktion delete-simulation.
  - Berechtigungen:
    - roles/compute.instanceAdmin.v1: Erzwingt das Löschen von virtuellen Maschinen während des Abbruchs.
    - roles/datastore.user: Aktualisiert den Status für abgebrochene Jobs.
Triggeridentitäten:
- scheduler-trigger:
  - Verwendet von: Eventarc- (Ereignisse) und Cloud Scheduler-Triggern.
  - Berechtigungen: roles/eventarc.eventReceiver und roles/run.invoker, um die Orchestrator-Funktionen auszulösen.
- cleanup-scheduler:
  - Verwendet von: Dem Cloud Scheduler-Cronjob für die Bereinigung.
  - Berechtigungen: roles/run.invoker, um die Bereinigungslogik auszulösen.

Die Verwaltung von IAM-Richtlinien (Identity and Access Management) für diese Dienstkonten ist die wichtigste Methode, um den Zugriff und die Berechtigungen im System zu steuern.