Glossary
Automotive security terms, explained by the people who test ECUs.
Each entry says in a few sentences what a term means, where it is defined and how it shows up on a real ECU. Written by the AutoST team, checked against ISO 14229, ISO 13400 and ISO/SAE 21434.
In short
The AutoST glossary defines terms from vehicle diagnostics and automotive cybersecurity: UDS services and negative response codes, data and routine identifiers, SecurityAccess, ISO-TP, CAN and CAN FD, DoIP, SOME/IP, ODX and CDD, TARA, CAL, CSMS, ISO/SAE 21434 and UN R155. Every entry names its source.
All terms
From ADB to UN R156
A
- ADB (Android Debug Bridge)ADB is the Android debug interface over USB or TCP port 5555. Why it is the first thing to check on an Android head unit, and what an open ADB gives an attacker.
- Android Automotive OS (AAOS)Android Automotive OS runs natively on the head unit and talks to the vehicle through the Vehicle HAL. How it differs from Android Auto and what we find on the bench.
C
- CAL (Cybersecurity Assurance Level)The Cybersecurity Assurance Level (CAL 1 to 4) of ISO/SAE 21434 Annex E sets how rigorous verification and validation must be. How it is derived and used in testing.
- CAN Bus (Controller Area Network)CAN (ISO 11898) is the broadcast bus most ECUs share: identifiers, arbitration, error handling. Why any node can send any frame and what that means for security testing.
- CAN FD (CAN with Flexible Data Rate)CAN FD extends classic CAN to 64 data bytes and a faster data phase. How the DLC, BRS bit and bit timing work and what changes for diagnostics and fuzzing.
- CDD (CANdela Diagnostic Description)A CDD file is the Vector CANdela description of an ECU diagnostic interface: sessions, services, DIDs, routines and security levels. What it holds and how testers use it.
- CommunicationControl (0x28)UDS CommunicationControl (0x28) enables or disables normal and network messages on an ECU. The sub-functions, request and response bytes and what to validate.
- ControlDTCSetting (0x85)UDS ControlDTCSetting (0x85) turns fault-code storage on an ECU on or off during a test. The sub-functions, request and response bytes and what to validate.
- CSMS (Cybersecurity Management System)A CSMS is the system of processes UN R155 requires from a vehicle manufacturer: risk management, testing, monitoring and response over the vehicle lifecycle.
D
- Diagnostic session (DiagnosticSessionControl 0x10)UDS DiagnosticSessionControl (0x10) switches an ECU between default, extended and programming session. Bytes, timing parameters and what to validate.
- DID (Data Identifier)A DID is the 16-bit identifier UDS uses to address a data record, read with 0x22 and written with 0x2E. Standard ranges from ISO 14229-1 Annex C and writable DIDs.
- DoIP (Diagnostics over Internet Protocol)DoIP (ISO 13400) carries UDS over Ethernet: vehicle discovery, routing activation and diagnostic messages on port 13400. How it works and where gateways go wrong.
- DTC (Diagnostic Trouble Code)A DTC is a fault code an ECU stores when it detects a problem. The 3-byte UDS format, the status byte, how 0x19 and 0x14 read and clear them, and their role in fuzzing.
E
- ECU (Electronic Control Unit)An ECU is an embedded computer that controls one function of a vehicle. What sits inside, which interfaces it exposes and why every ECU is a security test object.
- ECUReset (0x11)UDS ECUReset (0x11) restarts an ECU. The reset types, the request and response bytes, which session it needs and what to validate on the bench.
F
- Functional vs. Physical AddressingPhysical addressing sends a UDS request to one ECU, functional addressing to all of them. CAN IDs 0x7E0 and 0x7DF, the single-frame rule and the response rules.
- Fuzzing (Fuzz Testing)Fuzzing sends malformed and unexpected input to an ECU and watches for crashes, resets and hangs. How UDS and CAN fuzzing work and what a reproducible run needs.
G
H
I
- ISO-TP (ISO 15765-2)ISO-TP (ISO 15765-2) splits UDS messages into CAN frames: single, first, consecutive and flow-control frames. How it works and why malformed frames crash ECUs.
- ISO/SAE 21434ISO/SAE 21434:2021 is the standard for cybersecurity engineering of road vehicles: processes, TARA, concept, development, validation. Structure and testing clauses.
- IVI (In-Vehicle Infotainment)IVI is the vehicle head unit that runs apps, media and connectivity, often on Android or Linux. Why it is a large attack surface and what hardening checks look for.
N
O
- ODX (Open Diagnostic Data Exchange)ODX (ISO 22901-1, ASAM MCD-2 D) is the XML format that describes how an ECU speaks UDS: services, DIDs and routines. How it is structured and what testers do with it.
- OTA Update (Over-the-Air Software Update)An OTA update delivers new software to a vehicle over a wireless link instead of a workshop tester. How the chain works, what UN R156 requires and where ECUs fit in.
P
- PDX (Packaged ODX)A PDX file is a ZIP container that packages ODX diagnostic data (ODX-D, ODX-C, ODX-F and more) with a catalog, per ISO 22901-1. What is inside and how testers use it.
- Programming Session (0x10 0x02)The UDS programming session (10 02) is the diagnostic mode for reflashing an ECU. How it is entered, which services it unlocks and why it is the most sensitive one.
R
- ReadDataByIdentifier (0x22)UDS ReadDataByIdentifier (0x22) reads a data identifier (DID) from an ECU. The request and response bytes, which session it needs and what to validate.
- ReadDTCInformation (0x19)UDS ReadDTCInformation (0x19) reads diagnostic trouble codes and their status from an ECU. The sub-functions, request and response bytes and what to validate.
- RequestDownload (0x34)UDS RequestDownload (0x34) opens a download into ECU memory. Request bytes, maxNumberOfBlockLength, typical NRCs and why 0x34 outside a locked session is a top finding.
- RID (Routine Identifier)A RID is the two-byte identifier that RoutineControl (0x31) uses to start, stop and query a routine in an ECU, from erase memory (FF00) to manufacturer tests.
- RoutineControl (0x31)UDS RoutineControl (0x31) starts, stops and reads routines on an ECU by routine identifier (RID). The request and response bytes and what to validate.
S
- SARIF (Static Analysis Results Interchange Format)SARIF is the OASIS JSON standard for exchanging tool findings. What a SARIF file contains, why it fits ECU test results too, and what to watch for when you import one.
- SecOC (Secure Onboard Communication)SecOC is the AUTOSAR mechanism that authenticates in-vehicle messages with a MAC and a freshness value. How it works on CAN and what a bus test can check.
- Secure BootSecure boot verifies an ECU firmware image before it runs, so unsigned or modified software does not start. How it works, the HSM role and what a bench test can observe.
- SID (Service Identifier)The SID is the first byte of every UDS message and names the service, from 0x10 DiagnosticSessionControl to 0x3E TesterPresent. Ranges, response rule, SID sweeps.
- SOME/IP (Scalable service-Oriented MiddlewarE over IP)SOME/IP is the AUTOSAR middleware for services on automotive Ethernet: header, methods, events and service discovery. What it is and why exposed services are a finding.
T
- TARA (Threat Analysis and Risk Assessment)TARA is the threat analysis and risk assessment of ISO/SAE 21434 clause 15: assets, threat scenarios, impact, attack paths, feasibility, risk value and treatment.
- TesterPresent (0x3E)UDS TesterPresent (0x3E) keeps a non-default session alive. Request and response bytes, the suppress bit, the S3 server timer, and the session bugs it exposes.
U
- UDS (Unified Diagnostic Services)UDS (ISO 14229) is the diagnostic protocol of most automotive ECUs: sessions, services, DIDs and SecurityAccess. What it defines and why it is the first attack surface.
- UN R155 (UN Regulation No. 155, Cyber Security)UN R155 is the UNECE regulation that makes a certified CSMS and cyber security measures a condition for vehicle type approval. What it requires and what testers deliver.
- UN R156 (UN Regulation No. 156, Software Update)UN R156 is the UNECE regulation on software updates and the Software Update Management System. What it requires of OTA updates and how it connects to ECU testing.
V
W
How to use it
Definitions from the standard, plus what the bench shows
Diagnostics vocabulary is precise in the standards and loose in daily use. We define each term the way ISO 14229, ISO 13400 or ISO/SAE 21434 does, cite the clause and then add what we see on real ECUs: how the term appears in a trace, what typically goes wrong and how AutoST tests it.
Entries link to the related guides, comparisons and tools. If a term is missing, tell us and we add it.
FAQ
About the glossary
Who writes the entries?
The AutoST team at Zyberum, the same engineers who do ECU and vehicle penetration tests. Every entry is checked against the standard it cites and carries the date of its last update.
Can I link to or quote an entry?
Yes. Each entry has a stable URL and a Markdown copy. Quote with a link to the page. For reuse beyond a quotation, ask us.
Why mix diagnostics terms with regulation?
Because that is how ECU security work happens: a SecurityAccess weakness found on the bench becomes a threat scenario in the TARA and evidence in the UN R155 audit. The entries connect both sides.
See it on your ECU
A term that matters for your ECU?
In 15 minutes we tell you how AutoST tests it, what a finding looks like and what it means for your ISO/SAE 21434 evidence.
- Direct answer from an ECU security engineer
- Which test covers the term
- Free and without obligation
Your demo is withTom ZaubermannFounder of Zyberum, ex-lead of the VW InCar Security Testing Lab
Already trusted by Tier 1, Tier 2 suppliers and OEMs. References on request.
Or send us a message
We reply within one business day.