<aside> 🧐

The visual style of the data flow diagrams may vary slightly, as they were created by different team members at different times during the project. While the representations differ in appearance, they all aim to convey consistent architectural and data flow concepts aligned with the system’s overall design.

</aside>

This section presents Data Flow Diagrams (DFDs) illustrating the flow of information within selected critical business processes, highlighting key data interactions, processing steps, and system boundaries.

Build & Deploy Process for Autonomous Driving Stack

Diagram

Description

1. Code Commit & Version Control

   • Engineers commit code to the version control system (i.e., GitHub).
   • Branching strategy (e.g., GitFlow) ensures isolation for features, hotfixes, and releases.
   • Code is peer-reviewed and undergoes automated static analysis for quality, safety, and compliance (e.g., AUTOSAR guidelines).

2. Continuous Integration (CI)

   • A CI platform (e.g., GitHub Actions) runs:
     • Automated builds for the stack in containerized environments.
     • Unit and integration tests using simulation environments and mocked sensor data.
     • Static code analysis and vulnerability scans (e.g., using Semgrep).
     • Software bill of materials (SBOM) generation for compliance traceability.

3. Artifact Packaging

   • Built stack binaries, AI model weights, and dependencies are packaged as versioned artifacts.
   • Artifacts are stored in a secure artifact repository (e.g., AWS CodeArtifact).
   • Metadata is tagged (build time, commit hash, model version, safety assessment ID, etc.).

4. Deployment Pipeline (CD)

   • A deployment pipeline orchestrates rollout into multiple staging environments:

     • Simulation environment with synthetic road and traffic conditions.
     • Hardware-in-the-loop (HIL) test benches for low-level system interaction.
     • Digital twins to simulate edge cases and geographic conditions.

     Upon successful validation, the build is signed and sealed with cryptographic signatures for authenticity.

5. OTA Packaging

   • The verified stack is bundled into an OTA update package.
   • Stored in OTA Object Storage (e.g., S3 with versioning and encryption).
   • Metadata and rollout policies (vehicle model, hardware version, geography, fleet groups) are registered in the Update Metadata Service.

Vehicle’s Onboard Pulls and Applies Updates

Diagram

Description

1. ADS - Obtaining Pre-signed S3 URL
   • The Autonomous Driving Stack (ADS) initiates the process by calling the Update Manager Gateway with the VehicleID to check for updates.
   • The Update Manager Gateway forwards the request to the Update Micro-Service.
   • The Update Micro-Service queries the Entitlement Management system with the VehicleID and receives an ArtifactID in response.
   • Using the Artifact ID, the Update Micro-Service requests a Pre-signed S3 URL from the OTA Object Storage.
2. ADS - Retrieving the Updated File
   • ADS uses the Pre-signed S3 URL to request the updated file from the OTA Object Storage.
   • OTA Object Storage responds by providing the Artifact along with its Signature.
3. ADS - File Integrity Verification
   • Upon receiving the Artifact and Signature, ADS validates the file's integrity.
4. ADS - Applying the Update & Notifying the Backend
   • ADS applies the update to the vehicle's systems.
   • ADS then notifies the Update Manager Gateway, providing the VehicleID and Update status.
   • The Update Manager Gateway relays this information to the Update Micro-Service.
   • Finally, the Update Micro-Service logs the deployment status, vehicle-specific upgrade details, and other relevant information in the OTA Metadata store.