Containers and software deployment

Once several functions share one computer, an obvious question follows: how are they packaged, updated and isolated from each other?

The cloud world answered this with containers. Vehicles are borrowing the idea — carefully, and not everywhere.

The problem#

What a container gives you#

A container bundles an application with its dependencies into an image that runs in an isolated namespace on a shared kernel.

Property	Why a vehicle wants it
Dependency isolation	Two services can need different library versions
Independent update	Ship one service without rebuilding the image
Resource limits	Cap CPU and memory so one service cannot starve others
Reproducible builds	The same image runs on the bench and in the vehicle
Clear ownership	One team, one image, one release cadence

Where they fit, and where they do not#

Good fit:

Connectivity and cloud services
Data collection and telemetry
Non-safety vehicle services — comfort, convenience, charging management
Anything you want to update independently and often

Poor fit:

Safety-rated functions. Container isolation is not accepted as for a rated function; that needs a hypervisor or separate hardware.
Hard real-time control. Shared-kernel scheduling makes timing harder to bound.
Very constrained hardware. The runtime overhead is small but not zero.

What changes versus cloud practice#

Vehicle containers look superficially like cloud containers and differ in ways that matter.

No image registry pull at runtime. A vehicle may be offline for weeks. Images arrive as part of a signed update package, not fetched on demand.

Everything is signed and verified. The chain extends to container images. An unsigned image does not run.

Storage is precious. Layer bloat costs flash lifetime. Images are kept small deliberately, and old layers are pruned aggressively.

Startup time is a budget. Boot deadlines are real. Containers that must be up early are pre-warmed or started before the general orchestration.

Orchestration is minimal. Nothing resembling a cluster scheduler. Usually a simple supervisor that starts declared workloads, restarts failures with backoff, and enforces resource limits.

A vehicle workload declaration, conceptually

workloads:
  - name: charging-service
    image: oem/charging:2.4.1          # verified against a signature
    restart: on-failure
    backoff: exponential
    resources:
      cpu_shares: 512
      memory_max: 128Mi
      io_write_max: 5Mi/day            # flash wear matters
    start_after: vehicle-abstraction
    health:
      probe: grpc://localhost:50051/health
      timeout: 3s

Update granularity, and the honest limit#

What to check on a real programme#

Is anything safety-rated inside a container? It should not be.
Are images signed and verified as part of the boot chain?
Are there write limits, not just CPU and memory limits?
Can a single container genuinely ship alone? If not, why not — and is the reason interface versioning?
What happens offline? Nothing should require a registry.
What is the startup cost against the boot budget?

Next#

The communication module — how these services actually talk.