AUTOSAR CLASSIC · C O M M U N I C AT I O N S TA C K
Static Configuration & ARXML
Module 2 · A working ARXML → C generator · build it, read its output, link it
AUTOSAR SoAd Course · Module 2
MODULE 2
Static Configuration & ARXML — making
the tables real
MODULE 2 · METHODOLOGY
ARXML is a build-time input, not a runtime artifact
• ARXML files describe the desired configuration in a vendor-neutral XML schema.
• A code generator (DaVinci Configurator, EB tresos, ETAS ISOLAR, Vector COMASSO, …) reads
ARXML and emits C source.
• The emitted C is what gets compiled into the ECU. The ARXML is not parsed at runtime —
by then it's gone.
• Result: ARXML edits force a re-generate + re-compile. There is no "hot config" in Classic
AUTOSAR.
• This is the right trade-off for a safety stack: all decisions are visible to the compiler and the
static analyzer.
MODULE 2 · TOOLCHAIN
What "configured by ARXML" means at build time
Same pipeline in commercial toolchains; only the input/output volume differs.
MODULE 2 · ECUC MODEL
The ECUC container model — three primitives
• CONTAINER — a named node in the configuration tree (e.g. SoConGrp_HelloLink). Has a
SHORT-NAME.
• PARAMETER — a leaf value on a container (protocol = UDP, localPort = 30001). Schema-
typed.
• REFERENCE — an AR-path pointing to another container (PduRoute → SoCon). The string
IS the wire.
• Containers nest via SUB-CONTAINERS. AR-paths are slash-delimited and absolute:
/EcuA/SoAd/SoConGrp_HelloLink/SoCon_EcuB.
• Everything in the SoAd config maps to these three primitives. The generator's whole job is
walking them.
MODULE 2 · C O NTA I N E R T R E E
ECUC container tree for SoAd (from ecu_a.arxml)
Solid arrows = SUB-CONTAINERS. Dashed arrows = REFERENCE-VALUES (an AR-path string).
MODULE 2 · ARXML
An ARXML excerpt — the SoConGroup and its SoCon
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>SoConGrp_HelloLink</SHORT-NAME>
<PARAMETER-VALUES>
<PARAM name="SoAdProtocol">UDP</PARAM>
<PARAM name="SoAdSocketLocalPort">30001</PARAM>
<PARAM name="SoAdSocketLocalAddress">[Link]</PARAM>
</PARAMETER-VALUES>
<SUB-CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>SoCon_EcuB</SHORT-NAME>
<PARAMETER-VALUES>
<PARAM name="SoAdSocketRemoteAddress">[Link]</PARAM>
<PARAM name="SoAdSocketRemotePort">30002</PARAM>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
</SUB-CONTAINERS>
</ECUC-CONTAINER-VALUE>
Full file: tools/arxml_gen/ecu_a.arxml. Simplified shape; real ARXML adds DEFINITION-REF attributes.
MODULE 2 · G E N E R ATO R
Generator: parse phase (soad_gen.py, excerpt)
def parse(path: str) -> SoAdModel:
root = [Link](path).getroot()
pkg_name = _short_name([Link]('.//ar:AR-PACKAGE', NS))
soad_mod = next(e for e in [Link]()
if _strip_ns([Link]) == 'ECUC-MODULE-CONFIGURATION-VALUES'
and _short_name(e) == 'SoAd')
model = SoAdModel(ar_root_package=pkg_name)
for c in soad_mod.find('ar:CONTAINERS', NS):
params, refs = _params(c), _refs(c)
if 'SoAdProtocol' in params: [Link](_parse_grp(c, params,
pkg_name))
elif 'SoAdTxPduId' in params: model.pdu_routes.append(_parse_pdu_route(c,
params, refs))
elif 'SoAdRxPduId' in params: model.socket_routes.append(_parse_sock_route(c,
params, refs))
return model
The whole parser is ~80 lines. Real generators are larger because they cover all of AUTOSAR, not just SoAd.
MODULE 2 · G E N E R ATO R
Generator: emit phase (excerpt)
[Link]('static const MiniSoAd_SoConCfgType SOCONS[] = {')
for g in [Link]:
for s in [Link]:
[Link](f' /* [{socon_idx[s.ar_path]}] {g.short_name} / {s.short_name}
*/')
[Link](' { .localPort = ' + str(g.local_port) + ',')
[Link](' .localAddr = ' + _ip_to_octets(g.local_ip) + ',')
[Link](' .remotePort = ' + str(s.remote_port) + ',')
[Link](' .remoteAddr = ' + _ip_to_octets(s.remote_ip) + ',')
[Link](' .protocol = TCPIP_IPPROTO_UDP,')
[Link](f' .name = "{g.short_name}/{s.short_name}" }},')
[Link]('};')
AR-path → integer index resolution happens here too — keeps SoAd's runtime lookups O(1) per route.
MODULE 2 · G E N E R AT E D C O D E
Generated output: soad_gen_cfg.c (excerpt)
/* AUTO-GENERATED by soad_gen.py from ecu_a.arxml */
/* DO NOT EDIT — re-run the generator instead. */
#include "soad_gen_cfg.h"
#include "../examples/app_pdu_ids.h"
static const MiniSoAd_SoConCfgType SOCONS[] = {
/* [0] SoConGrp_HelloLink / SoCon_EcuB */
{ .localPort = 30001,
.localAddr = {0,0,0,0},
.remotePort = 30002,
.remoteAddr = {127,0,0,1},
.protocol = TCPIP_IPPROTO_UDP,
.name = "SoConGrp_HelloLink/SoCon_EcuB" },
};
const MiniSoAd_ConfigType SOAD_GEN_CFG = { .soCons = SOCONS, … };
Layout matches the hand-written ECU A config from Module 1 — by design.
MODULE 2 · BUILD FLOW
How the Makefile wires it together
# In mini_soad/Makefile:
$(GEN_A_SRC): $(ARXML_DIR)/ecu_a.arxml $(GEN_TOOL)
python3 $(GEN_TOOL) $(ARXML_DIR)/ecu_a.arxml $(GEN_A_DIR)
gen_ecu_a: $(CORE_OBJ) examples/gen_ecu_a.o $(GEN_A_DIR)/soad_gen_cfg.o
$(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
# Usage:
# make gen # re-generate C from ARXML
# make gen_all # generate + compile + link
# make run_gen # run the demo with generator-driven config
ARXML files are Make prerequisites; touch them and the C is regenerated and re-linked.
MODULE 2 · DEMO OUTPUT
Sample run — gen_ecu_a side
====== ECU A (gen) starting — config from ARXML ======
[SoAd] SoCon 'SoConGrp_HelloLink/SoCon_EcuB' (id=0) ONLINE
— local [Link]:30001, remote [Link]:30002
[SoAd] Init complete. 1 SoCon(s), 1 PduRoute(s), 1 SocketRoute(s).
[App-A] --> IfTransmit PDU_ID_HELLO_AB ("HELLO from A #0")
[SoAd] IfTransmit: PduId=1 via SoCon 'SoConGrp_HelloLink/SoCon_EcuB'
(15 bytes) -> [Link]:30002
[App-A] TxConfirmation PduId=1 result=OK
[SoAd] RxIndication: SoCon 'SoConGrp_HelloLink/SoCon_EcuB' got 13 bytes
from [Link]:30002 -> deliver as PduId 2
[App-A] <-- Reply received (13 bytes): "ACK from B #0"
The SoCon name is "SoConGrp_HelloLink/SoCon_EcuB" — proves the name came from ARXML, not C.
MODULE 2 · TA K EAWAYS
Takeaways
• ECUC container model = container, parameter, reference. That's the whole vocabulary.
• References are AR-path strings; the generator's job is to resolve them to integer indices.
• Generator output is just C: it must compile under the same flags as the rest of the BSW.
• Make wiring matters — treat ARXML as a build prerequisite, not as a side artifact.
• Commercial generators add validation (schema, semantic rules, cross-module consistency).
That's where most of their code lives.
REFERENCES
Resources for further study
• AUTOSAR_TPS_ECUConfiguration.pdf — the canonical document for the ECUC meta-model.
• AUTOSAR_TPS_ARXMLSerializationRules.pdf — defines AR-path resolution and SHORT-
NAME rules.
• Vector "DaVinci Developer User Manual" (free with eval) — most accessible commercial
toolchain reference.
• EB tresos Studio user docs — good treatment of the parameter validation model.
• Open-source ARXML libraries to inspect: autosar-tools (Python), arxml (Rust). Heavyweight;
learn the model first.
END OF MODULE 2
Next: Transmission Path Deep Dive
Module 3 will cover the Tx path in detail: header mode, fan-out routes, TP segmentation.
AUTOSAR SoAd Course · Module 2