AUTOSAR

AUTOSAR

Theia is an ARA-inspired runtime. We model it on the AUTOSAR Adaptive Platform — its Functional Cluster decomposition, its service/communication patterns, its manifest-driven configuration — and we read the ARA specifications as our reference. But:

We do not claim AUTOSAR compatibility, and we have no intent to certify the system. We use the specs as a design guide, not a conformance target. Where the spec and practicality disagree, we choose practicality — and we may deviate further over time. Treat "ara::*" names here as homages that signal intent, not as conformance claims.

What we keep from ARA: the vocabulary and shape — a POSIX base, services as supervised processes, a clear split between platform Functional Clusters and the applications that ride on top, and the four deployment manifests. What we replace: the transport (TIPC + nanopb, not SOME/IP + ARXML serialization), the IDL (our .art DSL, not ARXML), and most internal APIs (a C++ actor runtime — GenServer / GenStateM / GenRunnable — not ara::* libraries). ARA itself says "internal interfaces between the building blocks shall not be standardized" — so a different realization is squarely within the spirit.

Why the Adaptive shape fits

The Adaptive Platform exists for high-performance compute ECUs: multi-core SoCs, automotive Ethernet, complex/upgradeable functions — the world of an ADAS or gateway box, not a brake actuator. It is service-oriented over POSIX, with the integrator constraining dynamic behaviour through manifests (pre-determined discovery, startup-time allocation, fixed process→core pinning). That is exactly the niche Theia targets, which is why the FC decomposition transfers cleanly even though our internals don't.

The Functional Clusters

ARA groups the platform into building blocks. Theia implements them as .art nodes/compositions; some are real services, some are AUTOSAR-named placeholders, and seven carry deliberate Theia adaptations (linked below).

Building block	FC	Theia status
Runtime	core, exec, log, sm, [OS interface]	exec = the supervisor (fork/exec, lifecycle, Function-Group state, heartbeat); log = ring-buffer trace/log hub; sm = Function-Group state machine
Communication	com, tsync, rds, nm	com = the gRPC/TIPC bridge + DMZ edge
Storage	per	etcd-backed config gatekeeper
Safety	phm	health → mode escalation (FgGate)
Security	crypto, idsm, fw	OpenSSL provider, eBPF IDS, nftables firewall
Diagnostic	diag (dm)	placeholder
Configuration	ucm, vucm, registry	OTA update agent + fleet campaign
Hardware	shwa	telemetry + power-mode plane

Pages for the seven adapted FCs: tsync · shwa · per · nm · ucm · vucm · rds

Communication matrix

Theia maps the two AUTOSAR communication patterns directly onto two .art port idioms:

Pattern	.art idiom	Semantics
cast	senderReceiver + sender/receiver ports	fire-and-forget notification; no reply; N subscribers (events, streams, status, health/mode escalations)
call	clientServer + server/client ports	request→reply service call; caller blocks for a value (queries, confirming commands, sign/verify, snapshots)

Rule of thumb: a producer that informs many consumers casts; a consumer that needs an answer from one provider calls. A status stream is a cast; a GetStatus is a call — and they often coexist on one FC (e.g. fw provides both FwStatusStream (cast) and FwCtlIf.GetFirewallStatus (call)). The full producer→consumer table — wired vs. documented-gap vs. intentional-non-port (the hand-encoded firehose / gRPC edge / iceoryx bulk plane) — is on the Communication Matrix page, derived from the prose and cross-checked against the actual .art port declarations.

How a Functional Cluster is realized

Every FC is .art-declared and rests on three primitives:

Primitive	Is a	Owns
node	thread	one TIPC type/instance, ports, a GenServer/GenStateM/GenRunnable
composition	process (one executable)	node instances + in-process wiring
cluster	distribution bundle	compositions + the deploy/packaging unit

The .art model generates both the C++ daemons and the four AUTOSAR deployment manifests (machine / application / service / execution) — see Manifests + ARA.