In short
Network configuration as code keeps one versioned description of the vehicle network, usually AUTOSAR ARXML or ASAM FIBEX, in version control alongside the software, and generates the switch configuration, the simulation stimuli, the analyser decode inputs and the test cases from it instead of maintaining each by hand. The point is not automation for its own sake. It is that the description becomes the only artefact anyone edits, generated outputs are build products rather than documents, and a change that would have broken integration fails a validation gate on a commit instead of surfacing on a bench three weeks later.
There is a switch on your bench whose running configuration nobody can derive from a document. It works. It has worked since the person who set the bench up changed a VLAN identifier to make a link come up, told nobody, and moved on. Six months later that bench is the only accurate description of the network, and every artefact that claims to describe it disagrees with it and with the others in different ways.
That is the failure this article is about. Not a tooling gap and not carelessness, but the predictable outcome of holding one design in five places with nothing enforcing agreement. Most available material answers a different question, how to open an ARXML file, which is a fair question and not this one.
What follows covers the formats as the standards bodies describe them, what a pipeline generates downstream, the gates worth putting in front of a commit, a migration path, and what none of it fixes. It assumes the network itself, covered in our complete guide to automotive Ethernet, and the architecture context in our domain versus zonal article.
One network, many descriptions
Where configuration lives today
On a typical Ethernet programme the same network is written down in at least five places: an AUTOSAR ARXML description from the OEM’s architecture toolchain, often a FIBEX export derived from it because some tools read that and not ARXML, a switch configuration typed in at a bench, a simulation project holding the peers the bench lacks, and test scripts with addresses, VLAN identifiers and service identifiers written in as literals. All five describe the same network. None is derived from the others, and nothing checks that they agree.
Who owns each artefact, and why that is the real problem
Ownership is where this becomes structural rather than untidy. The ARXML belongs to the architecture team, often at the OEM. The switch configuration belongs to whoever built the bench, frequently a supplier or a contractor. The simulation project belongs to validation, the test scripts to test automation, and the address spreadsheet to nobody, which is why everyone trusts it. That is four or five groups across as many as three organisations, and a change that is correct in one artefact has no route into the other four. No malice, no incompetence, just no mechanism.
How drift starts: one bench edit that never goes back upstream
Drift always starts the same way. A link will not come up, or a service will not appear, and an engineer with a deadline changes something at the bench until it works. The change is correct: the bench now matches reality better than the description does.
What is missing is the path back. The engineer would have to know which artefact is authoritative, have write access to it, and have a review process that would accept the change. Usually at least one of those is false, so the change stays local. Repeat that a dozen times and the bench is the source of truth by accident, with nobody able to say which of its settings are design and which are workarounds. The cost is paid at integration, when two teams arrive with benches that were each correct locally and the mismatch surfaces as a defect in a product that does not have one.
The formats, plainly
Lookup table: what each artefact is and who consumes it
| Artefact | Governed by | What it describes | Typical producer | Typical consumer |
|---|---|---|---|---|
| AUTOSAR ARXML | AUTOSAR | Software components, ECUs, systems and the communication between them | OEM architecture toolchain | Basic software and RTE generators, supplier toolchains, simulation and test tools |
| ASAM FIBEX (MCD-2 NET) | ASAM e.V. | Network topology, ECUs with ports and gateways, signals per ECU, service providers and consumers | OEM interface description, or an AUTOSAR toolchain export | Bus tools, network test tools, residual bus simulation, code generation |
| Switch configuration | The switch supplier | VLAN membership, priority to queue mapping, shaper parameters, port state | A bench engineer, by hand | The switch, and nothing else |
| Capture encapsulation configuration | ASAM CMP, or a vendor-originated format | Interface to stream mapping, timestamping, control and configuration | Capture module supplier tooling | Logger, analyser, offline scripts |
| Analyser decode configuration | The analyser project | Service, method and parameter layout | Generated, or typed by hand | The analyser only |
| Spreadsheet or slide | No standards body | Address plan, VLAN plan, service list, in whatever shape the last meeting left them | Whoever was in the meeting | Every other artefact above |
AUTOSAR ARXML: system description and ECU extracts
AUTOSAR is explicit about what these files are. Its Classic Platform page states that the descriptions, carrying the .arxml extension, are based on the AUTOSAR Templates, which define the formal exchange format known as the AUTOSAR Schema and the semantic constraints that go with it, and that the descriptions hold the information produced or consumed in the AUTOSAR methodology, with various generators using that information to support configuration and generation of the runtime environment and the basic software.
Two things follow. ARXML is an exchange format defined by a schema, which is what makes it tractable as a versioned artefact. And an ARXML file means something only in relation to the template it was written against, so “we have the ARXML” is not a statement about what you have.
The distinction that catches bench teams is between a system level description and an extract generated for one ECU. Our rest bus simulation article works through what happens when a team is handed the device under test’s own extract and asked to simulate its peers from it. Ask which you were given, before the bench is built. AUTOSAR serves its specification PDFs publicly for information, so ARXML semantics are readable without a licence negotiation, which is not true of every standard a vehicle network touches.
ASAM FIBEX (MCD-2 NET): bus and network description
ASAM covers the same territory from a different direction. Its standard MCD-2 NET, titled Data Model for ECU Network Systems and known throughout the industry as FIBEX, is described by ASAM as a uniform, XML-based interface description for configuring the software of automotive networks. It allows the definition of network topologies consisting of ECUs with network ports and gateways, and consists of a generic interface description plus technology-specific extensions for FlexRay, MOST, CAN, TTCAN, LIN and Ethernet, with per-port properties including addresses, transport protocols and reserved ports for Ethernet and IP. It carries the signals sent and received per ECU, and, where communication is service oriented, the service provider instances and consumers.
The current version is 4.1.2, released on 2 June 2017. ASAM lists the application areas as network specification, communication stack development, network testing, bus tools configuration and residual network simulation, says it supports auto-generation of ECU software code and the configuration of test tools, and states that it is widely used in the automotive industry and harmonized with the AUTOSAR system template.
Three of those five are downstream artefacts this article covers: residual network simulation, network testing and bus tools configuration. Switch configuration is not on ASAM’s list, which is a fair signal of where the standardised path stops.
Capture and measurement descriptions alongside them
A third description family gets forgotten because it belongs to the measurement side. ASAM CMP, currently version 1.1.0 released on 26 January 2026, defines the communication between capture modules and data sinks and includes the specification of status messages, control messages, time synchronisation and configuration mechanisms. Its published list of supported buses and signals covers CAN and CAN FD, LIN, FlexRay, analog and digital signals, Ethernet and 10BASE-T1S symbols among others, so a programme adopting the multidrop link covered in our 10BASE-T1S article acquires description content on the measurement side too.
The point is not the format choice, which our capture encapsulation article covers. It is that the measurement chain has a configuration deciding whether a result is trustworthy, it drifts like the others do, and it belongs in the same versioned tree rather than in a logger’s flash.
Projects that carry both, and how they keep them consistent
Plenty of programmes hold both an ARXML tree and a FIBEX export, and that is not a mistake: ASAM’s harmonisation statement is what makes the export possible, and some tools read one and not the other.
The mistake is treating the export as a document. An export is a build step, derived, versioned, and lossy in ways specific to the exporting tool unless someone has checked otherwise, so the moment someone patches the exported file you have a second source of truth wearing the clothes of a generated one. The rule that keeps both formats honest is short: one is authored, the other generated, and nobody edits the generated one. Our payload decode article follows one instance of this end to end, including what it costs when the export path is discovered late.
What “as code” means here
Stripped of enthusiasm, the borrowed phrase means four commitments.
One versioned source of truth, in the same repository as the software
The description lives in version control, in the same tree as the software it describes, tagged with the same releases. Not on a share, not attached to an email, not in a tool database only one licensed workstation can open. The test is simple: can a new engineer reconstruct the network a release ran against from a commit identifier alone? If the answer requires asking someone, the description is not the source of truth yet.
Review by diff instead of review by meeting
A change to the network becomes a reviewable change with an author, a timestamp and a rationale, rather than an agenda item. XML diffs badly by default, so this works only if formatting is stable and files are generated rather than hand-shaped. The reward is that a VLAN identifier change reaches the person whose test it will break, before it does.
Generated artefacts are never hand-edited, and the pipeline is the only writer
This is the commitment that fails first. Someone patches a generated switch configuration at two in the morning because it is faster, the pipeline overwrites it on the next run, and the fix is lost in a way that looks like a product regression.
The defence has to be structural. Generated outputs live in a directory the pipeline owns, carry a header saying they are generated and from what, and are rebuilt on every run rather than updated in place. A hand edit then requires changing the description or the generator, which is the correct amount of friction.
Validation in CI, so a bad description fails before it reaches a bench
The description is now a text file in a repository, so any check you can write runs on every commit. That is the practical argument for the whole approach: a bad VLAN plan should fail a build rather than a bench. Our test automation article covers the surrounding pipeline, including bench configuration held as version-controlled code.
What you generate downstream
Each of these is hand-maintained on most programmes, and each is derivable from a description that already holds the information.
Switch VLAN, priority and shaper configuration. VLAN membership per port, the priority to traffic class mapping and the shaper parameters per queue all exist in the design before anyone types them into a switch. Our VLAN and QoS article sets out the plan they come from, and makes the same point from the other end: a plan living only in a bench switch’s running configuration gets reverse engineered under pressure.
Service and eventgroup configuration for service oriented communication. Service and instance identifiers, endpoint addresses, ports, transport selection and eventgroup membership are deployment facts, and our SOME/IP explainer covers what each controls on the wire. Every one appears in several artefacts at once.
Capture decode inputs. An analyser needs parameter definitions before payload bytes become named fields, and generating them from the same description keeps a capture readable across a release boundary. Our payload decode article covers that path, and our decode fix list the case where nothing decodes at all.
Rest bus simulation stimuli. ASAM lists residual network simulation as an application area of the network description, which is a standards body saying this artefact is meant to be generated. Our rest bus simulation article covers the fidelity decision that sits on top, because generation gets you a correct peer, not a realistic one.
Test cases and expected results. Not the logic, which is judgement, but the parameters: which service on which endpoint, which VLAN, which priority, which timeout the requirement quotes. Generated fixtures, not literals in scripts, consumed by the test automation pipeline that runs them.
Validation gates worth having
These are gates we would put in front of a commit. Each is reasoning about the failure modes above rather than a measurement, and each is cheap because the alternative is finding out at a bench.
- Schema validation on every commit. Both formats are schema-defined, and a description that does not validate is a description no downstream consumer can be trusted to read the same way. Seconds of build time, a class of failure removed.
- VLAN identifier uniqueness and conformance to the plan. Every identifier used is in the plan, no identifier means two things, reserved values are respected. Our VLAN and QoS article covers which values are not yours to assign.
- Service and instance identifier collision check. Two service instances sharing an identifier, or an endpoint reused across two services, produces behaviour that looks like a network fault and is not one.
- Priority to queue mapping sanity per port. Confirm the mapping is expressible on the hardware, because queue count per egress port is a device limit rather than a design choice, and assuming more queues than a port has fails silently as merged classes.
- Time synchronisation domain consistency. Check that domain membership, roles and referenced domains agree across the description. A domain described inconsistently in two places is not detectable at a bench without deliberate measurement. Our time sync validation article covers what proving it at a bench actually takes.
- Diff review required on any change to the description. The gate with no automation in it and the highest value, because every other gate here can be satisfied by a description that is valid and wrong.
A migration path from spreadsheets
Most teams never start because this gets presented as a transformation. One engineer can walk the path below in the gaps of a sprint.
- Freeze one export as the baseline and commit it. Take the description you have, in whatever state, and commit it unchanged. It is wrong in places. Fine: it is now wrong in a way that has a history.
- Generate exactly one artefact from it, the one that hurts most today. Pick by pain, not ambition. On most Ethernet benches that is the analyser decode configuration, where the failure is visible in minutes and the fix loop is short.
- Add one validation gate. Schema validation, nothing else yet. The point is to establish that a commit can fail, which is a cultural change more than a technical one.
- Make the generated artefact authoritative and delete the hand-maintained copy. This step is the whole exercise: two copies of anything means the discipline is not established, and deleting the old copy is what proves it is.
- Expand one artefact at a time, and stop when the value stops. Add the next output only once the previous one has been stable through a release. An artefact edited once a year by one person who is never wrong about it may not be worth a generator built for it.
Limits and honest caveats
Not every switch or test device exposes a machine-readable configuration
The generated output has to be applied to something. Some switches accept a configuration file over a defined interface, some expose only an interactive one, and some expose an interface undocumented outside a supplier relationship. Where a device cannot be configured from a file, generate a readable configuration anyway and diff it against what the device reports back, which catches drift without preventing it. Ask before purchase; it is not a property you can add later.
Tooling lock-in around ARXML, and what portability actually buys you
Both formats are XML defined by a schema, though not on equal terms: AUTOSAR serves its template specifications publicly, while the FIBEX schemata come with the ASAM package. Either way it sounds like portability and only partly is. Toolchains differ in which parts of a schema they populate, how they express what the schema leaves open, and what they do with elements they do not understand, so a file that validates is not therefore a file another tool interprets identically.
What portability buys is not tool independence but survival: your description outlives any tool decision, readable and diffable and parseable by something you could write yourself. That is a smaller claim than the marketing around either format, and it is the one that holds.
The configuration as code category for vehicle networks is young
Compared with server infrastructure practice, the vehicle network equivalent is early. Most of what exists is either built in-house against one OEM’s description profile or embedded in a commercial toolchain. We are describing a category and a discipline, not recommending a tool, and a team adopting it should expect to write some of the connective code themselves.
Ownership across OEM and supplier boundaries, which no tool fixes
The hardest problem here is organisational. If the OEM owns the description and the supplier owns the bench, a change found at the bench has to cross a contractual boundary to reach the description, and no pipeline crosses that on its own. Configuration as code does not solve it. It makes it undeniable, because the change has to be committed somewhere and there is visibly nowhere to commit it, and a drift problem everybody can see is a different problem from one everybody works around.
Where GSAS fits
The teams we work with rarely have a tooling problem here. They have an artefact they cannot point at and call right, and a bench that has quietly become the answer instead. The first useful conversation is not about pipelines. It is about which artefact you would trust if two of them disagreed tomorrow, and what would have to be true for that to still hold in six months.
GSAS Micro Systems is an engineering partner to automotive teams in India, and the work here sits between the architecture document and the bench: reading the description you have, comparing it against the switch, the simulation and the test scripts meant to implement it, and identifying which single generated artefact would remove the most drift for the least effort. That is usually smaller than teams expect, and scoped to leave you with something you own rather than rent.
Our applications engineers work alongside teams in Bengaluru, Pune, Chennai and Hyderabad, in IST, so a working session lands inside your day. The automotive Ethernet capability page sets out the wider scope, and if a description and a bench are disagreeing in front of you, request a consultation describing the artefacts you hold and who owns each one.
References
- ASAM MCD-2 NET (FIBEX) standard page, ASAM e.V. (title and scope, network topologies, technology-specific extensions, signals and service provider instances per ECU, version 4.1.2 of 2 June 2017, application areas, harmonisation with the AUTOSAR system template): https://www.asam.net/standards/detail/mcd-2-net/
- ASAM CMP standard page, ASAM e.V. (Capture Module Protocol, version 1.1.0 of 26 January 2026, capture modules and data sinks, supported buses and signals, status and control and configuration mechanisms): https://www.asam.net/standards/detail/cmp/
- AUTOSAR Classic Platform standards page (methodology and templates,
.arxmldescriptions and the AUTOSAR Schema, generators consuming descriptions to configure the RTE and basic software, release listing): https://www.autosar.org/standards/classic-platform - AUTOSAR Classic Platform System Template, R24-11 (System Description, System Extract, ECU Extract; served publicly from autosar.org without a licence): https://www.autosar.org/fileadmin/standards/R24-11/CP/AUTOSAR_CP_TPS_SystemTemplate.pdf
Also appears in:
Building for Automotive & Mobility?
Talk to our application engineers for personalized tool recommendations.
