Know-how · Architecture
AUTOSAR
A standardised architecture for ECU software, and the reason a measurement engineer keeps being handed XML files that describe a system rather than data from it.
In short
AUTOSAR (AUTomotive Open System ARchitecture) is a standardised software architecture for automotive ECUs, developed by a partnership of manufacturers and suppliers. It separates application software from the hardware beneath it through a runtime environment and a layered basic software stack, so a software component can in principle be reused across different ECUs and suppliers. There are two platforms: Classic, for deeply embedded real-time control on microcontrollers, and Adaptive, for high-performance compute running a POSIX operating system with service-oriented communication. The system is described in ARXML, an XML format that defines software components, interfaces, data types, signals, and the mapping onto ECUs and buses. ARXML is a description, not a measurement — it tells you what a signal is and where it is routed, not what value it took.
01
Classic and Adaptive
Classic AUTOSAR targets the deeply embedded controllers that run powertrain, chassis and body functions. Behaviour is statically configured before build: the communication matrix, the task schedule and the memory layout are fixed, which is what makes the timing analysable and the system certifiable for safety.
Adaptive AUTOSAR targets the high-performance compute that arrived with driver assistance and software-defined vehicle architectures. It runs on a POSIX operating system, communicates through services that can appear and disappear at runtime, and supports software deployed and updated over the vehicle's lifetime. The two coexist in modern vehicles rather than one replacing the other.
- ClassicStatically configured, real-time, microcontroller, signal-based communication.
- AdaptivePOSIX, service-oriented, dynamic, updatable over the vehicle lifetime.
- RTEThe runtime environment that isolates application components from the stack beneath.
- BSWLayered basic software: drivers, communication, diagnostics, memory services.
02
What ARXML actually contains
ARXML describes the system: software components and their ports, the interfaces between them, data types and their constraints, signals and signal groups, and how all of that maps onto physical ECUs and network frames. For a measurement or diagnostics engineer, the useful part is usually the communication description — which signal travels in which frame, with what layout and conversion.
That overlaps with what a DBC provides for CAN, which is why both turn up in the same workflow and why they are easy to confuse. ARXML describes the system broadly, including the routing; a DBC describes CAN frames specifically. Neither contains measured values.
- Components and portsThe software structure and its interfaces.
- Data typesBase types, ranges, conversions and constraints.
- CommunicationSignals, frames, PDUs and their mapping to buses.
- Not a measurementARXML describes; MDF4 records.
03
Where calibration and measurement sit
AUTOSAR standardises the software architecture, not the calibration tooling. Calibration parameters still live in ECU memory and are still described by an A2L; measurement still happens over XCP and still lands in MDF4. What AUTOSAR changes is how the software around those parameters is structured, and that the system description an engineer receives may arrive as ARXML rather than as a bus database.
In practice that means a calibration or measurement workflow in an AUTOSAR programme looks much as it did — A2L for calibration objects, XCP to measure, MDF4 to record — with ARXML added as another description file to reconcile against.
04
Reading the data that comes out of it
MDX loads ARXML alongside DBC as a description file, so signals carry their proper names and conversions when a recording is opened, rather than being reconciled by hand afterwards. The recording itself is MDF4, BLF, ASC or CSV as the logger produced it.
Where the question is diagnostic rather than analytical, DiagAI reads fault memory over UDS, OBD-II and J1939 against the same recording, which matters in an architecture where a function may be distributed across several control units.
Standards & references
Check the source.
These primary sources define the formats and regulatory context discussed above. They do not certify or endorse VehicleLab products.
Questions
Frequently asked.
What does AUTOSAR stand for?
AUTomotive Open System ARchitecture. It is a standardised layered software architecture for automotive ECUs, developed by a partnership of manufacturers and suppliers.
What is the difference between Classic and Adaptive AUTOSAR?
Classic is statically configured for deeply embedded real-time control on microcontrollers. Adaptive runs on a POSIX operating system with service-oriented communication for high-performance compute, and supports software updated over the vehicle lifetime. Modern vehicles use both.
What is an ARXML file?
The XML format AUTOSAR uses to describe a system: software components, interfaces, data types, signals, and the mapping onto ECUs and network frames. It is a description, not recorded data.
Is ARXML the same as a DBC file?
No, though they overlap. A DBC describes CAN frames and the signals inside them. ARXML describes the broader system including components, interfaces and routing, and can cover several bus types. Both are descriptions; neither holds measurements.
Does AUTOSAR replace A2L and XCP?
No. Calibration parameters are still described by an A2L and still measured over XCP, with recordings in MDF4. AUTOSAR standardises the software architecture around them.
Next step
Open one of your own files with us.
Send a measurement, an A2L or an EHANDBOOK container. We will open it in the instruments on a call, with your engineers in the room.