SOAFEE

SOAFEE (Scalable Open Architecture for Embedded Edge) is an industry alliance initiated by Arm in 2021 that defines a cloud-native architecture for vehicle software. Its goal is that automotive workloads can be developed and tested in the cloud using standard cloud tooling — containers, orchestration, CI/CD — and then deployed unchanged to embedded hardware in the vehicle.

The core deliverable is an open architecture and reference implementation built on container technology with automotive extensions for real-time, safety and mixed-criticality requirements — the aspects standard cloud stacks do not address. Members span chipmakers, OEMs, Tier 1s, cloud providers and software vendors.

What SOAFEE produces

SOAFEE’s output sits between a specification and a software project. The architecture documents describe how a cloud-native automotive stack should be layered: container runtimes and orchestration on the vehicle’s high-performance computers, standardized interfaces to hardware and to safety-critical functions, and hooks for the properties cloud software normally ignores — deterministic timing, freedom from interference between workloads of different criticality, and functional-safety processes. A reference software stack lets members and developers stand up that environment on supported hardware and in cloud instances, and a blueprint program packages worked examples of the architecture applied to concrete automotive use cases.

The consistent theme is reuse of the cloud-native mainstream rather than reinvention: existing container and orchestration technology is adopted where it works, and the alliance concentrates its effort on the automotive deltas.

Who is behind it

Arm initiated SOAFEE and remains its most visible backer, which is not incidental: the more automotive compute behaves like cloud compute, the better for a company whose processor architecture spans both. The alliance launched in 2021 with 13 founding members and had grown past 150 participating organizations by 2026, governed by its own Governing Body and Technical Steering Committee with special-interest and working groups underneath. In July 2026 Arm announced that SOAFEE would continue as a working group within CoreCollective, a broader open-collaboration initiative for the Arm software ecosystem, retaining its existing governance and blueprint program.

The cloud-native premise

The bet behind SOAFEE is environmental parity. If the vehicle’s central compute runs the same processor architecture, container runtime and orchestration patterns as a cloud instance, then most development, integration and testing can happen in the cloud at scale — thousands of parallel test runs instead of a bench of scarce prototype hardware — with the physical vehicle needed only for final validation. Arm-based cloud instances make this concrete: code can be built and run in the cloud for the same instruction set that ships in the car.

The honest caveats are the automotive deltas themselves. Containers do not, by themselves, provide deterministic real-time behavior; orchestrators are not designed around ISO 26262 safety cases; and mixed-criticality isolation — an airbag-relevant function sharing silicon with an infotainment app — remains an active engineering problem rather than a solved pattern. SOAFEE is best read as the industry’s shared workbench for closing those gaps, not as a claim that they are closed.

How it fits in the landscape

Placed against the other bodies in this crowded space:

• SOAFEE defines how compute is organized: a cloud-native architecture for the vehicle’s high-performance computers.
• Eclipse SDV produces open-source components — many of which can run as workloads inside a SOAFEE-style environment, and the two communities overlap in membership and blueprints.
• COVESA standardizes vehicle data; its Vehicle Signal Specification can serve as the data model for services running on a SOAFEE stack.
• AUTOSAR (Classic for deeply embedded ECUs, Adaptive for high-performance ones) standardizes the software platform itself. SOAFEE and AUTOSAR Adaptive address overlapping hardware from different directions — one importing cloud practice downward, one extending automotive practice upward — and production architectures as of 2026 typically mix both rather than choosing one.

A further distinction: SOAFEE is silicon-ecosystem-anchored in a way the others are not. Its neutrality is genuine at the specification level, but its gravitational pull toward Arm-based platforms is part of its logic.

Adoption reality

As of 2026, SOAFEE’s clearest wins are in the development loop rather than in shipped vehicles: cloud-based build and test environments, virtual platforms, and blueprint demonstrations with named partners. Membership past 150 organizations shows the direction of industry sentiment, but — as across this whole landscape — membership is not deployment. Running a full container-orchestrated, mixed-criticality SOAFEE stack in a series-production vehicle is a taller order than adopting its patterns for development infrastructure, and the second is where most real usage sits today. That is still consequential: development speed has become a competitive metric, and if most vehicle software can be validated in virtual environments before it ever touches a test car, OEMs shorten release cycles and cut hardware dependency — the same shift that Eclipse SDV and OEM vehicle OS programs pursue from different angles.

What to watch

Three signals matter. First, whether the CoreCollective transition broadens SOAFEE’s base or dilutes its automotive focus. Second, whether the mixed-criticality and real-time extensions mature to the point where safety-rated workloads demonstrably run under the architecture — the technical threshold between a development story and a production one. Third, how the boundary with AUTOSAR Adaptive settles: convergence, coexistence, or a slow migration of workloads toward the cloud-native side as zonal and central-compute architectures concentrate software on fewer, larger processors.