AUTOSAR per

per — Persistency

← back to AUTOSAR

What ARA defines

ara::per is the standardized C++ interface for storing/retrieving data across power cycles in a high-reliability automotive environment. Two paradigms: Key-Value Storage (small structured params, accessed by string key) and File Storage (large unstructured data, std::fstream-like). The "schema" is declared in the manifest, the platform pre-allocates, and per coordinates an app's data lifecycle across UCM updates (migrate / preserve / clear).

Our adaptation

Theia's per is the sole etcd client and the config gatekeeper — the one process that owns durable structured state.

• etcd backend behind an abstract Store (etcd-cpp-apiv3, isolated TU). per is the only FC that talks to etcd; everyone else reaches config through per.
• We split state by lifecycle, not format: params = static deploy knobs (per-FC JSON + a runtime config singleton); config = structured protobuf in etcd as binary bytes, digest-versioned, pushed to FCs as a ConfigUpdated{cfg, FieldMask} cast with per-field STATIC / HOT_RELOAD / RESTART_REQUIRED reload classes.
• Config framing is <digest>\0<proto>; defaults auto-seed on theia start.
• com proxies per's ListSchemas / Snapshot over gRPC (PerView) for the GUI Persistency panel — the only outside view into the store.

We keep ARA's "manifest-declared, platform-pre-allocated, update-aware" idea but realize it as etcd + a digest-versioned protobuf config bus, which is far more practical than ARXML-serialized KVS for our fleet.