---
title: "LDF and ARXML"
---

# LDF and ARXML

LIN description files as a language with checks per revision, and AUTOSAR system descriptions read into the module's CAN, J1939, LIN and FlexRay models, with 68 checks, navigation across files, container PDUs and validation against your AUTOSAR schema.

## LDF

`.ldf` files of LIN 1.3, 2.0, 2.1 and 2.2 open as their own language (SAE J2602 and ISO 17987 additions are kept as written):

- nodes and attributes, signals, frames of every kind, diagnostic frames, schedule tables with all twelve command forms, encoding types and representations;
- consistency checks per declared revision, each resting on a clause of the LIN specification: frame identifiers and lengths, signals outside or overlapping their frame, publishers and subscribers, initial values, NAD ranges, schedule slots too short for their frame at the bus speed with the declared jitter;
- outline, hovers, go to definition, find references and rename, as for DBC;
- **Check LIN Description Files in Workspace** checks every file.

The LIN channels, simulation and trace run from the same model: see [LIN bus](https://neuralinverse.com/docs/modules/automotive/lin/).

**State:** modelled. Checked on the LIN 2.2A specification's example and community files against ldfparser; no LDF written by a vendor tool has been read. The severity (error or warning) of each rule has not been reviewed against a vendor tool.

## ARXML

`.arxml` files keep the XML language, with an AUTOSAR outline, hovers, go to definition across files and find references. AUTOSAR 3 and 4 files, schemas up to R23-11, are read with the files their references need, as system descriptions and ECU extracts are often split.

What the description becomes:

| AUTOSAR element | Becomes | Used by |
|---|---|---|
| A CAN physical channel | A CAN database, like a DBC | The CAN Database view (read only), codec, traces, bus monitor, rest-bus simulation, compare, export and Save CAN Database as DBC |
| A J1939 cluster | A J1939 database with node addresses, NAMEs and transport protocol groups | [J1939 networks](https://neuralinverse.com/docs/modules/automotive/j1939/) |
| A LIN cluster | A LIN cluster of the LIN model, like an LDF | [LIN bus](https://neuralinverse.com/docs/modules/automotive/lin/) |
| A FlexRay cluster | The FlexRay model with its communication cycle | [FlexRay](https://neuralinverse.com/docs/modules/automotive/flexray/) |
| A CAN NM cluster | Network management of the simulated nodes | [Rest-bus simulation](https://neuralinverse.com/docs/modules/automotive/rest-bus-simulation/) |
| SOME/IP deployments, service instances, Ethernet clusters | SOME/IP decoding, the SOME/IP node and the Ethernet topology | [Automotive Ethernet](https://neuralinverse.com/docs/modules/automotive/ethernet/) |
| E2E transformers and secured PDUs | Protection settings | [E2E and SecOC](https://neuralinverse.com/docs/modules/automotive/e2e-and-secoc/) |

Read from the description: clusters and channels, frame triggerings, frames and PDU mappings, I-signal, multiplexed, secured and container PDUs, signals with compu methods and units, ECUs with ports, PDU groups and network management nodes.

- **68 checks** (18 of them on FlexRay clusters) report broken references and inconsistent layouts at the element that causes them.
- When several files define an element a file needs, the nearest is taken and Problems names both files, as information.
- **Deep projects and split elements.** Referenced files are looked for in the workspace folders 16 folders deep, up to 3000 ARXML files, nearest first. An element split over several files, as AUTOSAR allows, is read as one when its parts define different children and agree on the values both state; a copy is not joined.
- **Check AUTOSAR Files in Workspace** checks every file.

## Container PDUs with headers

A container I-PDU with short or long headers decodes frame by frame in the trace editor, the CAN Bus panel, the signal plot, the State Tracker and the agent tools:

- each header gives a contained PDU's id and length, so the PDUs come in whatever order and number the sender put them;
- a short header is a 24-bit id and an 8-bit length, a long header a 32-bit id and a 32-bit length, in the byte order the description's `CONTAINER-I-PDU-HEADER-BYTE-ORDER` gives (most significant byte first where none is given, said in Problems);
- an unknown header id is skipped by its length, the unused byte pattern ends the reading, and a PDU that appears twice is read from the later one;
- the CAN Database view's layout picker lists the contained PDUs.

The rest-bus simulation and Interactive Transmit send a container frame with every contained PDU behind its header, in the order the description lists them. Three checks are added: two contained PDUs with the same header id, a container with headers that does not fill its frame alone, and no usable header byte order. What has no fixed position is left out of the DBC export and generated C, with the reason.

## Validate against your AUTOSAR schema

Each open ARXML file is validated against the XML Schema it names in `xsi:schemaLocation` (`AUTOSAR_00049.xsd`, `AUTOSAR_4-2-2.xsd` and so on). Faults appear in Problems at their line and column: an element the schema does not allow there (with the elements it expects), a missing required element, an element repeated too often, text where only elements belong, an unknown or missing required attribute, a value outside an enumeration, against a pattern or too long.

1. Put your AUTOSAR schemas (with `xml.xsd`) in a folder. The Editor does not ship them: use the copy from your AUTOSAR release or tool.
2. Add the folder to `neuralInverse.automotive.arxmlSchemaFolders`. Without it, the schema is looked for beside the file and in the folders above it, where tools such as DaVinci keep it.
3. Open or change the file. Validation runs then; at most 500 problems per file are listed, with the count of the rest.

When the named schema is in none of these folders, Problems says so at the root element and names the setting. A file without a schema location is said to be unvalidated. A schema that uses an XML Schema construct the validator does not cover is reported as not fully checked rather than taken as passed.

![ARXML schema faults reported in Problems at their line and column, and a file whose schema was not found.](https://neuralinverse.com/docs-images/modules/automotive/arxml-schema-problems.webp)

**State:** verified on vendor samples against cantools and canmatrix: one CAN channel of 3 frames from Vector's published DaVinci output. Schema validation compared with xmllint on three schema releases only (AUTOSAR_00048, AUTOSAR_00049 and AUTOSAR_4-1-2). No production description has been read. The field order of a little-endian container header is a reading of the schema's documentation, not checked against an AUTOSAR stack.