Compendium

Automotive / On-Vehicle DSLs Family Index

12 min read

Automotive / On-Vehicle DSLs Family Index

type: language-family-index family: automotive-onvehicle languages_catalogued: 26 tags: [language-reference, family-index, automotive-onvehicle, autosar, arxml, can, dbc, lin, flexray, uds, doip, j1939, obd, someip, vss, viss, asam, misra]

Automotive / On-Vehicle DSLs — Family Index

Family overview

Automotive on-vehicle DSLs are the textual languages that describe the inside of a car: the bus topologies, the per-signal bit layouts, the ECU software architecture, the diagnostic services, the calibration variables, and increasingly the service-oriented communication graph. They sit one layer below source code (the C/C++ that actually runs on ECUs) and one layer above the wire (the CAN/LIN/FlexRay/Ethernet frames). The family is dominated by two megastandards — AUTOSAR (the architecture description, currently R24-11 released 2024-11-27) and the ASAM family (the data-exchange formats: ODX for diagnostics, A2L for calibration, FIBEX for networks, OTX for test sequences, OpenSCENARIO/OpenDRIVE upstream in robotics-control).

The signal-description layer has a long-running split between the DBC format (Vector Informatik, 1990s, ASCII, single-bus, de-facto industry standard) and ARXML / FIBEX (XML, multi-bus, OEM-handoff). DBC is what your tooling speaks — Vector CANalyzer/CANoe, BUSMASTER, python-can, dbcppp, cantools. ARXML is what OEMs hand to tier-1 suppliers. Most engineering workflows include a DBC ↔ ARXML conversion step. FIBEX (ASAM MCD-2 NET, latest 4.1.2 from 2017) is the open-standard XML competitor that supports CAN, FlexRay, LIN, MOST, and Ethernet, but it never displaced DBC in the tooling layer.

The diagnostic protocol stack has consolidated over two decades onto UDS (ISO 14229-1:2020, A1:2022) as the universal application-layer protocol, with DoIP (ISO 13400-2:2025 Edition 3) as the modern Ethernet transport replacing K-Line/CAN for new vehicles. OBD-II / J1979 remains the emissions-regulated PID subset for passenger cars and J1939 the heavy-truck CAN protocol with parameter group numbers (J1939DA Digital Annex updated 2024-09 with ~1,800 PGNs and 12,000+ SPNs). ODX (ASAM MCD-2 D, latest 2.2.0; ISO 22901-1) describes UDS services declaratively; OTX (ISO 13209) scripts diagnostic test sequences; CDD is Vector’s competing per-ECU diagnostic format.

The 2020s shift is toward service-oriented communication over Ethernet: SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the AUTOSAR Adaptive RPC layer for high-bandwidth domains (ADAS, infotainment, V2X); TSN profile IEEE 802.1DG-2025 provides bounded-latency in-vehicle Ethernet; CAN-XL (CiA 610/611/612 series, CiA 610-1 published 2024) scales legacy CAN to 10+ Mbit/s payloads. Above that, the COVESA Vehicle Signal Specification (VSS) has emerged since 2016 as the vendor-neutral semantic catalogue of every accessible vehicle signal (current VSS 6.x with overlay support), and VISS v2 / v3 is the W3C-originated, COVESA-stewarded REST/WebSocket/MQTT/gRPC API for accessing that data. AUTOSAR R24-11 explicitly added a VISS-protocol Automotive API Gateway functional cluster, marking the moment the two worlds officially merge.

In our deep library

No automotive DSL has a standalone deep-library note — the entire family sits at Tier 3. Cross-reference:

  • robotics-control — AV simulation sibling. OpenDRIVE (road-network description), OpenSCENARIO 1.x/2.x (driving-scenario description), OSI (Open Simulation Interface), and the ROS/ROS 2 stack live there. ASAM stewards both ODX/A2L/FIBEX (this family) and OpenDRIVE/OpenSCENARIO (that family) — the boundary is on-vehicle vs simulation/virtual-validation.
  • industrial-automation — fixed-plant OT sibling. IEC 61131-3 PLC languages, OPC UA, Modbus, Profinet. Shares the bus-protocol DNA but for stationary industrial equipment rather than moving vehicles.
  • assembly-and-encoding — Intel HEX and Motorola SREC firmware encodings are catalogued there but cross-list here as the universal ECU flash-image format.
  • embedded-firmware — where the C/C++ code described by AUTOSAR ARXML actually runs.
  • api-description — VISS is effectively an OpenAPI/AsyncAPI-style description for in-vehicle data; the modern automotive cloud-edge interface lives at the boundary.
  • cpp — Adaptive AUTOSAR is C++14 (MISRA C++:2023 rule set, 179 rules targeting C++17).
  • c — Classic AUTOSAR is C (MISRA C:2025, ~225 active guidelines covering C90/C99/C11/C18).
  • api-description — ARXML, FIBEX, ODX, OTX, CDD are all XML dialects; the schema-description infrastructure they ride on is catalogued there.

Tier 3 family table — Network bus / signal description

FormatFirst appearedOriginTypeStatus (2026)URL
DBC (Vector CANdb)~1992Vector InformatikASCII signal/message layout for a single CAN bus; multiplexed signals, value tables, attributesDominant de-facto standard; CANdb++ Admin 2.1 (2024-07); ~all CAN tooling reads DBChttps://www.csselectronics.com/pages/can-dbc-file-database-intro
ARXML for CAN cluster2003 (AUTOSAR 1.0)AUTOSAR consortiumXML cluster description (FibexCluster element) for CAN/CAN-FD; multi-ECU, multi-busActive; OEM-preferred for tier-1 handoff; AUTOSAR R24-11 (2024-11)https://www.autosar.org/standards/classic-platform
FIBEX (ASAM MCD-2 NET)2004ASAMXML, multi-protocol (CAN, FlexRay, LIN, MOST, Ethernet) network descriptionMaintained at 4.1.2 (2017-06); superseded in practice by ARXML for AUTOSAR workflowshttps://www.asam.net/standards/detail/mcd-2-net/
LDF (LIN Description File)2003 (LIN 2.0)LIN Consortium → ISO 17987 (2016)ASCII description of a LIN cluster: frames, signals, schedule tables, baud rateActive; LIN 2.2A LDF format current; ISO 17987-3 the standard formhttps://www.csselectronics.com/pages/ldf-lin-description-file
FIBEX-FlexRay2005ASAM / FlexRay ConsortiumFIBEX profile for FlexRay schedule + signal descriptionsMaintained; FlexRay declining as new programs move to Ethernethttps://www.asam.net/standards/detail/mcd-2-net/
CAN-FD frame format2012 (Bosch), ISO 11898-1:2015Bosch / ISOWire-level frame, not a DSL but described by DBC/ARXML extensionsUniversal in 2020s+ powertrain and chassis ECUshttps://www.bosch-semiconductors.com/products/ip-modules/can-protocols/can-fd/
CAN-XL (CiA 610/611/612 series)2022 spec draft; CiA 610-1 published 2024CiA / BoschUp to 2048-byte payload, 10+ Mbit/s; new SDU type byte; described via extended DBC/ARXMLEmerging; ISO 11898-1:2024 includes CAN-XL; CiA 612 guidelines in preparationhttps://www.can-cia.org/can-knowledge/can-xl

Tier 3 family table — AUTOSAR architecture

FormatFirst appearedOriginTypeStatus (2026)URL
AUTOSAR Classic ARXML2003 (AUTOSAR 1.0); modern XSD R4.x lineAUTOSAR consortium (BMW, Bosch, Continental, Daimler, Ford, GM, PSA, Siemens VDO, Toyota, VW)XML DSL describing SW-Cs, RTE, BSW stack, ECU mapping for hard-RT MCUsR24-11 released 2024-11-27 (latest as of 2026-05); ISO 26262 ASIL-D safety-critical workhorsehttps://www.autosar.org/standards/classic-platform
AUTOSAR Adaptive ARXML2017 (AP 17-03)AUTOSAR consortiumXML DSL describing C++14+ POSIX-based service-oriented architecture (ara::com, ara::exec, ara::diag)R24-11 (2024-11); the SDV / ADAS / V2X pathhttps://www.autosar.org/standards/adaptive-platform
AUTOSAR Foundation2017 (FO 1.0.0)AUTOSAR consortiumCross-platform shared spec: SOME/IP protocol, methodology, metamodelR24-11; the seam between Classic and Adaptivehttps://www.autosar.org/standards/foundation
AUTOSAR Methodology / metamodel (M2)2003AUTOSAR consortiumThe Ecore-based metamodel from which ARXML XSDs are generated; templates for the methodology workflowActive; revised every R-releasehttps://www.autosar.org/about/methodology
A2L / ASAP2 (ASAM MCD-2 MC)1996 (ASAP2 1.x)ASAM (orig. ASAM-AE)ASCII description of ECU-internal measurement and calibration variables; characteristic curves, maps, axis-typesV1.7.1 latest; pairs with XCP/CCP for live calibration over CAN/Ethernethttps://www.asam.net/standards/detail/mcd-2-mc/
MISRA C:20251998 (MISRA C:1998); 2025 editionMISRA Consortium (UK automotive)Coding-standard rule set (not strictly a DSL, but the rules are formal config for static-analysis tools)MISRA C:2025 published 2025-03; ~225 active guidelines for C90/C99/C11/C18; AI-generated code held to the same standardhttps://misra.org.uk/
MISRA C++:2023 (merged with AUTOSAR C++14)2008 (MISRA C++:2008); 2023 mergerMISRA + AUTOSARJoint C++ rule set; 179 rules targeting C++17; supersedes AUTOSAR C++14 GuidelinesReleased 2023-10; the canonical Adaptive AUTOSAR coding standardhttps://misra.org.uk/product/misra-cpp2023/

Tier 3 family table — Diagnostics (OBD/UDS/J1939/DoIP)

FormatFirst appearedOriginTypeStatus (2026)URL
OBD-II PIDs (SAE J1979)1996 (US federal mandate)SAEStandardized 8-bit Parameter IDs over CAN/ISO 15765-4 for emissions diagnostics; ~200 standard PIDs plus per-OEM proprietary modesUniversal; J1979-DA 2023 the latest digital annex; J1979-2 covers HEV/EVhttps://www.sae.org/standards/content/j1979_202308/
UDS (ISO 14229-1)2006 (Ed.1); 2013 (Ed.2); 2020 (Ed.3)ISO TC22/SC31Application-layer diagnostic protocol — 26 SID services; SecurityAccess, ReadDataByIdentifier, RoutineControl, etc.ISO 14229-1:2020 + A1:2022; new Authentication service added in 2020 ed.; next revision expectedhttps://www.iso.org/standard/72439.html
DoIP (ISO 13400-2)2011 (Ed.1); 2019 (Ed.2); 2025 (Ed.3)ISO TC22/SC31UDS transport over TCP/UDP/IPv4/IPv6 in-vehicle Ethernet; routing activation, vehicle-announcement broadcastISO 13400-2:2025 Edition 3 (2025-06) adds optional TLS, entity firewall, status monitoringhttps://www.iso.org/standard/87961.html
SAE J1939 (PGNs/SPNs)1994SAEHeavy-truck/off-highway CAN profile; 29-bit identifiers, Parameter Group Numbers (PGNs), Suspect Parameter Numbers (SPNs)J1939DA-202409 (Sept 2024): ~1,800+ PGNs, 12,000+ SPNs; widely used outside cars (agriculture, marine, military)https://www.sae.org/standards/content/j1939da_202404/
ODX (ASAM MCD-2 D / ISO 22901-1)2008 (V2.0); 2010 (V2.2 ratified)ASAMXML diagnostic-service description; UDS service catalog + ECU variants + flash data containers; PDX = packaged ODXV2.2.0 current; ASAM MCD-3 D V3.0.0 adds DoIP integration; ISO 22901-1 mirrors ithttps://www.asam.net/standards/detail/mcd-2-d/
OTX (ISO 13209)2011 (Part 1); 2012 (Part 2/3); 2021 (Part 4)ASAM → ISO TC22/SC31XML-based diagnostic test-sequence language; programmable workflow over ODX dataActive; ISO 13209-4:2021 latest; ASAM OTX Extensions add JSON/SOVDhttps://www.asam.net/standards/detail/otx-extensions/
CDD (CANdela Diagnostic Description)~2000Vector Informatik (proprietary)XML per-ECU diagnostic spec; states, sessions, DIDs, DTCs, security levelsActive proprietary; CANdelaStudio 18 (2024) supports AUTOSAR DEXT + ODX/PDX exporthttps://www.vector.com/int/en/products/products-a-z/software/candelastudio/
KWP2000 (ISO 14230)1999ISO TC22Legacy K-Line application-layer diagnostic protocol; superseded by UDSLegacy; still in service-tool use for vehicles up to ~2010 model yearhttps://www.iso.org/standard/27522.html
Intel HEX / Motorola SREC1973 (HEX) / 1970s (SREC)Intel / MotorolaASCII firmware image formats; universal ECU flash-tool inputUniversal; cross-listed in assembly-and-encodinghttps://en.wikipedia.org/wiki/Intel_HEX

Tier 3 family table — Service-oriented / VSS / cloud / Ethernet

FormatFirst appearedOriginTypeStatus (2026)URL
SOME/IP (Scalable service-Oriented MiddlewarE over IP)2013BMW → AUTOSAR FOBinary RPC + pub/sub middleware for in-vehicle Ethernet; methods, events, fieldsSpec’d in AUTOSAR FO R24-11 (PRS SOMEIPProtocol); SDV roadmap targets ~150 serviceshttps://www.autosar.org/fileadmin/standards/R24-11/FO/AUTOSAR_FO_PRS_SOMEIPProtocol.pdf
SOME/IP-SD (Service Discovery)2013BMW → AUTOSAR FOCompanion service-discovery protocol; offer / find / subscribe / event-groupSpec’d in AUTOSAR FO R24-11 (PRS SOMEIPServiceDiscoveryProtocol)https://www.autosar.org/fileadmin/standards/R24-11/FO/
TSN Automotive Profile (IEEE 802.1DG-2025)2018 (PAR); 2025 (published)IEEE 802.1 TSN Task GroupProfile bundling 802.1AS-rev, 802.1Qbv (TAS), 802.1Qci, 802.1CB for bounded-latency in-vehicle EthernetPublished 2025; the deterministic-Ethernet baseline for SDVhttps://standards.ieee.org/ieee/802.1DG/7480/
Audio Video Bridging (IEEE 802.1BA)2011 (802.1BA-2011)IEEE 802.1 AVB Task GroupPredecessor of TSN; AVB profile for in-vehicle infotainment audio/video streamsLegacy → migrating to TSN/802.1DGhttps://1.ieee802.org/tsn/
Vehicle Signal Specification (VSS)2016COVESA (orig. GENIVI)YAML/JSON catalogue of vendor-neutral vehicle signals organized as a tree (Vehicle.Body.Lights.Beam…)VSS 6.x (2025+) adds overlay feature for OEM customizations; widely adopted across OEMs/SDV stackshttps://covesa.github.io/vehicle_signal_specification/
VISS v2 / v3 (W3C → COVESA)2018 (v1); 2023-04 WD (v2 Core); v3 in COVESAW3C Automotive WG (closed 2024-02) → COVESA stewardshipREST + WebSocket + MQTT + (v3) HTTP/gRPC access protocol for VSS datav3 current; AUTOSAR R24-11 added Automotive API Gateway with native VISS supporthttps://www.w3.org/TR/viss2-core/
AUTOSAR DEXT (Diagnostic Extract)2017 (AUTOSAR 4.3)AUTOSARARXML profile dedicated to diagnostic descriptions; bridges ARXML ↔ ODXActive; CANdelaStudio + DiagRA can import/exporthttps://www.autosar.org/

Notable threads

  • AUTOSAR’s Classic vs Adaptive split is irreversible and accelerating. Classic (since 2003) targets ISO 26262 ASIL-D safety-critical hard-real-time applications on AURIX/RH850/S32K-class microcontrollers in C with statically-configured BSW stacks. Adaptive (since 2017-03) targets POSIX-class compute platforms (Linux PREEMPT_RT, QNX, VxWorks) in C++14+ for ADAS, infotainment, V2X, and the broader SDV workload. R24-11 (2024-11) is the current synchronized release for both; the merged-into-MISRA AUTOSAR C++14 guidelines are now formally MISRA C++:2023.

  • DBC vs ARXML in practice is a tooling question, not a standards question. DBC is what every CAN-tooling vendor (Vector CANalyzer/CANoe, BUSMASTER, Kvaser, PEAK-System, python-can, cantools, dbcppp) speaks natively. ARXML is what OEMs hand to tier-1 suppliers under contract. FIBEX (open ASAM standard, v4.1.2 from 2017) was the open alternative to both but never gained tooling traction. The dominant 2026 workflow is “OEM ships ARXML → supplier converts to internal DBC for bench testing → re-emits an ARXML cluster for integration.” Canmatrix (Python) and Vector tools both bridge the formats.

  • ASAM is the standards body most outsiders underestimate. ODX (diagnostics), OTX (test sequences), A2L/ASAP2 (calibration), FIBEX (networks), OpenSCENARIO (driving scenarios), OpenDRIVE (road networks), OpenLABEL (sensor annotation), and OSI (simulator interface) are all under one roof. Roughly half of the cross-OEM data-exchange formats in modern vehicle development are ASAM. ASAM standards are typically dual-published as ISO standards (ODX as ISO 22901-1, OTX as ISO 13209) once mature.

  • The OBD-II PID catalogue is the only universal-by-regulation slice. Emissions regulations (US EPA Tier 3, EU Euro 7) require ~200 standard PIDs accessible via J1979 over ISO 15765-4 (UDS on CAN). Everything else — proprietary modes 22 (Read Data By Identifier), 21, 23 — is OEM-private. This is why generic OBD-II dongles only show coolant temp, RPM, MAF, and a handful of fuel-trim values; the actually-interesting signals live in proprietary DIDs that require manufacturer-specific decoder packs.

  • UDS displaced KWP2000 / ISO 9141 / ISO 14230 over the 2010s and is now universal. ISO 14229-1:2020 (Edition 3, Amendment A1:2022) is the application-layer protocol shared across all transports — UDSonCAN (ISO 15765-3), UDSonLIN (ISO 17987-2), UDSonFlexRay (ISO 10681-2), UDSonIP / DoIP (ISO 13400-2:2025). The 2020 edition added a new Authentication service (SID 0x29) and an enhanced SecurityAccess (SID 0x27), reflecting the cybersecurity-of-vehicles mandate (UNECE R155/R156).

  • DoIP (ISO 13400) is the modern transport that makes Ethernet diagnostics practical. ISO 13400-2:2025 (Edition 3, June 2025) added optional TLS for tester-to-vehicle encryption, in-vehicle DoIP entity firewall capabilities, and entity-status monitoring — closing the cybersecurity gaps in earlier editions. DoIP is now mandated by many OEMs for new-vehicle EOL (end-of-line) flashing because gigabit Ethernet trivially outperforms CAN-FD for multi-hundred-megabyte flash images.

  • SOME/IP is the AUTOSAR Adaptive RPC layer for in-vehicle Ethernet. Designed at BMW (~2011-2013), adopted by AUTOSAR in 2015, now the canonical service-oriented middleware for high-bandwidth in-vehicle communication. SOME/IP-SD handles service discovery via multicast; SOME/IP-TP (transport protocol) handles segmented payloads. The SDV roadmap (per 2024-2025 papers) targets ~150 SOME/IP services covering every in-vehicle domain — at which point the legacy DBC-described CAN signal bus becomes a backup for the SOME/IP service bus.

  • COVESA/VSS is the open-vehicle-data movement and is winning. Started by GENIVI (now COVESA) in 2016, VSS gives a vendor-neutral tree-structured catalogue of every accessible vehicle signal (Vehicle.Speed, Vehicle.Powertrain.CombustionEngine.Engine.Speed, Vehicle.Body.Lights.Beam.Low.IsOn, etc.). VSS 6.x adds an overlay mechanism so OEMs can extend the standard tree without forking. VISS (Vehicle Information Service Specification) is the API: v2 published as W3C Working Draft in April 2023, v3 now stewarded by COVESA after the W3C Automotive WG closed in February 2024 — supporting WebSocket, HTTP, MQTT, and gRPC. AUTOSAR R24-11’s new “Automotive API Gateway” functional cluster speaks VISS natively — the moment the two worlds officially merged.

  • MISRA C / MISRA C++ are coding-standard rule sets, but functionally serve as static-analysis configuration DSLs. MISRA C:2025 (March 2025, ~225 guidelines covering C90/C99/C11/C18) and MISRA C++:2023 (October 2023, 179 rules for C++17, merged with the former AUTOSAR C++14 Guidelines) are the canonical safety/security coding standards across the automotive industry. Notably, MISRA C:2025 explicitly states AI-generated code is held to the same compliance standard as handwritten code — the first major coding standard to take a position on this. Every certified ASIL-D codebase in 2026 ships a MISRA compliance report.

Citations

Graph View