Every AAOS term, in plain English

A full Android operating system that runs on the car itself, not on your phone.

Android Automotive OS is Android installed on the vehicle's head unit at the factory. It boots when the car starts, owns the screens, the speakers and the climate controls, and works whether or not a phone is present. It is a complete operating system, not an app.

Think of the difference between a smart TV and a Chromecast. AAOS is the smart TV — the software is built into the device. Android Auto is the Chromecast — your phone does the work and the screen just displays it.

See also: Android Auto · head unit · GAS

A Linux Foundation project producing a shared open-source Linux platform for automotive.

AGL provides a Yocto-based reference distribution plus common services so OEMs share a base instead of each maintaining their own. It competes with Android Automotive for the infotainment slot, trading the Play ecosystem for full control of the stack.

See also: Yocto · AAOS

Your phone drawing a car-friendly screen and sending the picture to the car display.

Android Auto is a projection system. The app runs on the driver's phone; the head unit is only a screen and a touchpad. Unplug the phone and the experience leaves with it. It has no access to vehicle data.

See also: AAOS · head unit

The free, public source code that all Android versions are built from.

AOSP is the openly published Android source code. Anyone can download it, modify it and build their own Android. Car makers start from AOSP and add their own hardware support, apps and branding.

See also: GAS · Treble

The fixed, statically configured AUTOSAR platform for small real-time control ECUs.

Everything is decided at build time — tasks, memory, and which signal goes where. The result is a binary with predictable timing and no dynamic allocation, running on a microcontroller with no operating system in the desktop sense. It is what braking, steering and body ECUs are built on, and it is deliberately not updatable in the field.

A printed circuit board. Extremely reliable at exactly the job it was made for, and you cannot change what it does without making a new one.

See also: AUTOSAR · AUTOSAR Adaptive · ECU

How long from switching the car on to the software being usable.

Car makers commit to specific figures, and some are legal requirements — a reversing camera image within roughly two seconds. Boot time is measured on real hardware from the ignition signal, not from when Android starts.

See also: EVS · power state

A window after the car is switched off when it may still do background work.

The engine is off and the driver has gone, but the head unit stays awake briefly to apply updates, upload diagnostics and sync data — work nobody should have to wait for while driving. The window is limited, so tasks must be able to stop partway and resume next time.

See also: OTA · power state

A licensed bundle of Google apps — Maps, Assistant, Play Store — that a car maker can pay to include.

Google Automotive Services is separate from AAOS. AAOS itself is free and open. GAS adds Google Maps, Google Assistant and the Play Store, and requires a commercial agreement plus passing Google's compatibility tests. Some vehicles ship with it; many ship without and use the maker's own maps and voice assistant.

See also: AAOS · AOSP · CTS

Code that hides the details of specific hardware behind a standard interface.

A Hardware Abstraction Layer lets Android talk to hardware without knowing whose hardware it is. Android says "take a photo" or "read the cabin temperature"; the HAL translates that into whatever the actual chip or ECU needs. Swap the hardware, rewrite the HAL, and Android above it is unchanged.

See also: VHAL · AIDL · Treble

The computer and screen in the middle of the dashboard.

The head unit is the physical box behind the centre display. It runs the infotainment software, drives one or more screens, and connects to the vehicle network. On an AAOS vehicle, this is where Android runs.

Software that runs several separate operating systems on one chip, keeping them isolated.

A modern cockpit computer may run Android for infotainment and a safety-rated system for the instrument cluster on the same silicon. The hypervisor partitions the hardware so a fault in one cannot affect the other.

Like flats in one building. Shared foundations and wiring, but a fire door and separate meters between them.

See also: ASIL · cluster

The standard OS interface — files, processes, threads, sockets — that Linux, QNX and Android all implement.

Because AUTOSAR Adaptive, QNX and Linux all present a POSIX interface, application code written against it is broadly portable between them. This is why SDV stacks can plan for the operating system to change without rewriting the applications on top.

See also: AUTOSAR Adaptive · QNX

What the head unit is doing when the car is not being driven.

A head unit is rarely fully off. It suspends, so it can wake in about a second when the driver returns. The power state machine covers booting, running, preparing to shut down, and the different depths of sleep.

See also: Garage Mode · boot time

A phone drawing a car interface and sending the picture to the head unit.

Android Auto and Apple CarPlay both work this way. Confusingly, an AAOS vehicle can also host projection — the car runs Android as its own operating system AND can display a projected phone session as one more app.

See also: Android Auto · AAOS

A commercial real-time microkernel OS, widely certified for safety-critical automotive use.

QNX keeps drivers and services in user space rather than the kernel, so a failing driver does not take the system down. It ships with ISO 26262 certification evidence up to ASIL D, which is why it is the common choice for instrument clusters and hypervisors — the certification work is already done and paid for.

See also: ASIL · hypervisor · cluster

A small battery-backed clock that keeps time while the car is off.

The real-time clock runs on its own tiny power supply so the vehicle knows roughly what time it is at startup, before any network or satellite fix. It drifts, which is why the time is corrected once a better source is available.

See also: GNSS

The systems that help or intervene while driving — lane keeping, adaptive cruise, emergency braking.

ADAS covers everything from a lane departure warning to automatic emergency braking. It runs on its own dedicated, safety-rated hardware; Android generally only receives its state to display, and never controls it.

See also: ASIL · cluster

Which specific seat, door or window a value applies to.

Many properties exist several times over — one per seat, per door, per window. The area ID says which one. Crucially it is a set of flags, not a counter: the driver's seat is 0x0001 and the front passenger's is 0x0004, not 1 and 2.

Like room numbers in a hotel. "Temperature" is meaningless on its own; "temperature in room 204" is a fact.

See also: vehicle property · property ID

The shared wire that ECUs use to broadcast short messages to each other.

CAN is the most common vehicle network. ECUs broadcast small numbered messages; anything interested listens. It is fast, extremely reliable and decades old, and it carries no notion of "requests" — just a continuous stream of announcements.

Like a walkie-talkie channel that everyone on a building site can hear. Nobody addresses anyone directly; you announce, and whoever cares listens.

See also: ECU · vehicle network · SOME/IP

Whether a value is fixed, announced when it moves, or sampled continuously.

STATIC means it never changes after startup, like the VIN. ON_CHANGE means the VHAL announces it whenever it moves, like gear position. CONTINUOUS means it is sampled at a rate, like speed. Choosing wrong either wastes power or makes the UI stutter.

See also: vehicle property · subscription

Working out where you are from how fast and which way you have been going, when satellites are unavailable.

In a tunnel or a multi-storey car park there is no satellite signal. Dead reckoning keeps estimating position from wheel rotation, steering angle and gyroscope data until the signal returns. Error accumulates the longer it runs.

Like keeping track of where you are in a dark room by counting your steps and remembering which way you turned. It works for a while, and gets worse the longer you go.

See also: GNSS · wheel tick

A camera watching the driver to detect drowsiness or distraction.

A driver monitoring system uses an infrared camera pointed at the driver to estimate gaze direction and eye closure. In several markets it is becoming a regulatory requirement. The camera feed is highly sensitive personal data and normally never leaves its own processor.

See also: ADAS

A small dedicated computer that controls one part of the car.

A modern vehicle contains dozens to hundreds of ECUs. One controls the engine, another the doors, another the seats. Most are not running Android and know nothing about it — they exchange messages on the vehicle network.

Like the separate controller boards inside a washing machine or a printer: each does one job, and they talk over a shared wire.

See also: CAN · vehicle network

Processing data where it is produced rather than shipping it to a datacentre.

In a vehicle the edge is the car itself. Anything with a latency budget under a few hundred milliseconds, anything that must work without connectivity, and anything expensive to transmit — camera frames especially — is processed on the vehicle. The cloud gets summaries, not raw feeds.

See also: central compute · SDV

Positioning from satellites — GPS is one system among several.

Global Navigation Satellite System is the umbrella term for GPS (US), Galileo (EU), GLONASS (Russia) and BeiDou (China). A modern receiver uses several at once, which is why position is far better than GPS alone used to be.

See also: dead reckoning

A 32-bit number that encodes what a property is, not just which one it is.

A property ID packs four things into one number: which namespace it belongs to (Google's or a vendor's), what part of the car it applies to, what data type it holds, and a unique identifier. Reading the number tells you a lot before you look anything up.

See also: vehicle property · area ID · VENDOR group

How full the high-voltage battery is, as a percentage.

The equivalent of a fuel gauge for an electric vehicle. It is an estimate rather than a direct measurement, computed by the battery management system from voltage, current and temperature.

Asking to be told whenever a value changes, instead of repeatedly asking for it.

An app registers a callback for a property, and the platform delivers updates. This is always preferable to polling: it wakes fewer components and uses far less power.

See also: change mode · CarPropertyManager

The wiring and protocols the car's computers use to talk to each other.

Collectively the CAN, LIN, FlexRay and Automotive Ethernet links inside a vehicle. Android does not connect to these directly — a vendor component does, and translates for the VHAL.

See also: CAN · ECU · SOME/IP

One named piece of car information, like "speed" or "driver seat temperature".

A vehicle property is a single value the VHAL exposes. Each has an ID, a data type, an area it applies to, and rules about whether it can be read, written or both. Apps never talk to the car directly — they read and write properties.

See also: VHAL · property ID · area ID

The namespace car makers use for properties Google has not defined.

Property IDs carry a group. SYSTEM means Google defined it and every AAOS vehicle understands it the same way. VENDOR means a car maker invented it for their own feature. Using SYSTEM for your own invention causes collisions when Android is upgraded.

See also: property ID · vehicle property

The single doorway through which everything the car knows reaches Android.

The Vehicle HAL is a piece of software that sits between Android and the car's own electronics. It offers Android a list of named values — speed, gear, cabin temperature — that can be read, written or watched for changes. Everything vehicle-related that an Android app can see came through here.

Like a receptionist at a building. Visitors do not wander the corridors; they ask at the desk, and the desk knows how to reach each department. The VHAL is that desk.

See also: vehicle property · HAL · Car Service

A count of how far each wheel has rotated, used to measure distance precisely.

Wheel speed sensors produce pulses as the wheel turns. Counting them gives a far more accurate distance measurement than integrating speed, which is why they feed dead reckoning and odometry.

See also: dead reckoning

A small language for describing what one process is allowed to ask another.

You write an .aidl file listing methods and their arguments; the build generates the code that packs them into Binder messages. It is how HALs and system services publish their interfaces.

See also: Binder · HAL · HIDL

The library apps use to reach car features, the way android.media is used for audio.

android.car is the public API surface for automotive. It contains CarPropertyManager, CarAudioManager, CarUxRestrictionsManager and others. Apps link against it; it talks to Car Service behind the scenes.

See also: Car Service · CarPropertyManager

How one Android process asks another process to do something.

Binder is Android's mechanism for communication between processes. An app calling CarPropertyManager is really sending a Binder message to Car Service. It is fast, but not free — and each process has a limited pool of threads to handle incoming calls.

Like a phone call between two departments. Fast, but the other department only has so many people to answer.

See also: AIDL · Car Service

The part of Android that owns everything car-related.

Car Service is a single system process holding a dozen smaller services: vehicle properties, audio zones, power state, user switching, driver distraction, watchdog. Apps reach the vehicle through it, and it checks permissions on the way.

See also: CarPropertyManager · VHAL · system_server

The class an Android app uses to read and write vehicle values.

CarPropertyManager is the app-facing API for vehicle data. An app asks it for a property value or subscribes to changes; it forwards the request to Car Service, which checks permissions and asks the VHAL.

See also: Car Service · vehicle property · VHAL

A service that checks other processes are still responding, and kills the ones that are not.

CarWatchdog pings registered services and terminates any that stop answering. It also tracks how much each app writes to storage, because vehicle flash memory has to survive fifteen years.

An invisible account that runs the car's software before anyone logs in.

On a phone, user 0 is you. In a car, user 0 has no screen at all — it exists to run climate, audio and the vehicle connection so the car works with nobody signed in. Drivers are separate users layered on top, and switching between them never restarts user 0.

Like the building's caretaker. They keep the heating and lights running whether or not any tenant is home, and they do not move out when tenants change.

See also: Car Service · occupant zone

The older version of AIDL, used for HALs before Android 13.

HIDL served the same purpose as AIDL for hardware interfaces. AOSP has moved HAL interfaces to AIDL; HIDL remains in older vehicles and is gradually being retired.

See also: AIDL · VHAL

A seat position, together with the screens and the user that belong to it.

A cockpit may have a driver display, a cluster, a passenger screen and rear screens, with different people using them at once. Occupant zones model who is sitting where, which screens they own, and which user account is theirs.

See also: headless system user · multi-display

The single Android process that hosts most of the operating system's services.

system_server runs the window manager, activity manager, package manager and dozens more. It is the most important process on the device — if it crashes, the whole user interface restarts.

See also: Car Service

A set of ready-made screen components sized and behaved for use in a moving car.

The Car UI Library provides lists, toolbars, dialogs and preferences that are already large enough to hit while driving and already respond to distraction rules. Because every component reads the same named resources, one overlay restyles all of them at once.

See also: RRO · UX restrictions

The permanent bars and panels around the edge of the screen.

CarSystemUI draws the status bar, the navigation bar, the climate panel and the notification surface. Your app only ever gets the region between them, and the bars stay on top at all times.

See also: RRO · car-ui-lib

The screen behind the steering wheel showing speed and warning lamps.

The instrument cluster displays legally required information. On many vehicles it is not driven by Android at all but by a separate certified system, with Android sending it content to display in one designated area.

See also: ASIL · telltale

A flag an app sets to claim a screen is safe to show while driving.

An activity marked distractionOptimized may be displayed while the vehicle is moving. Without it, the platform replaces the screen with a "not available while driving" message. Setting it is a safety claim that a car maker will test.

See also: UX restrictions

The fast path that puts the reversing camera on screen before Android has finished starting.

Regulations in many markets require a reversing image within about two seconds. Android takes far longer to boot, so the camera path deliberately bypasses the Android framework and runs as a small native service that can start almost immediately.

See also: head unit · boot time

A separate app that replaces another app's colours, sizes and layouts without changing its code.

A Runtime Resource Overlay is how car makers rebrand Android without copying and editing it. The overlay supplies new values for named resources; the target application never knows. This matters because a copied-and-edited version has to be re-merged at every Android upgrade, for the vehicle's whole life.

Like a phone case and a custom wallpaper. The phone is unchanged underneath, so it can still take system updates.

See also: CarSystemUI · car-ui-lib

A warning lamp — seatbelt, airbag, engine — on the instrument cluster.

Telltales have legal requirements for colour, symbol and availability. They are almost never drawn by Android, because a general-purpose operating system cannot guarantee they will appear.

See also: cluster · ASIL

Rules the platform enforces on what your screen may show while the car is moving.

Above a speed threshold, the platform limits how many list items you may display, how long your text may be, whether video may play and whether a keyboard may appear. These are enforced by Android itself, not left to each app to honour.

See also: distractionOptimized · car-ui-lib

What kind of sound this is — music, navigation, phone call, warning chime.

The audio context is derived from what an app says its sound is for. It decides which speakers the sound reaches and what happens to it when something more important starts playing.

See also: audio zone · bus · audio focus

The system deciding who is allowed to make noise right now.

When two things want to play, focus decides the outcome: one stops, one pauses, or both play with one quieter. In a car some sounds — collision warnings — cannot be interrupted at all, so requests that would interrupt them are simply refused.

See also: ducking · audio context

A place in the car with its own volume and its own idea of what is playing.

The cabin is usually zone 0. A rear-seat entertainment system can be zone 1, with its own volume control and its own audio focus, so a passenger's film does not pause when the driver gets a navigation prompt.

See also: audio context · bus

One physical audio output path from Android to the amplifier.

A car head unit exposes several separate outputs rather than one. Music goes out one, navigation another. Keeping them separate lets the amplifier lower the music behind a navigation prompt in hardware, without any software involvement.

See also: audio zone · audio context · ducking

Turning one sound down rather than stopping it, so another can be heard over it.

When a navigation prompt plays, the music does not stop — it gets quieter for a moment. That is ducking. It can be done by the app, by Android, or by the amplifier in hardware.

See also: audio focus · bus

Two complete copies of the system, so an update can be written while the car runs on the other.

The vehicle runs from slot A while the update is written to slot B. A reboot switches to B. If B fails to start, the bootloader falls back to A automatically. There is never a moment where the car has neither a working system nor a spare.

Like painting the spare room while you sleep in the main one, then swapping. If the paint job is wrong, you move back.

See also: OTA · verified boot

Android deciding an app has stopped responding to input and offering to close it.

If an app does not handle input within a few seconds, or a service does not start in time, Android declares an ANR. On a vehicle these are more serious than on a phone: the driver cannot pull over to deal with a frozen screen.

See also: tombstone · Binder

A description of what hardware exists, handed to the kernel at boot.

Rather than compiling hardware details into the kernel, a device tree describes the board: which chips are on which bus, which pins do what, which display is attached. The same kernel can then boot different boards.

See also: boot time

The choice of which device and which build flavour you are compiling.

Before building AOSP you run `lunch` and pick a target, such as a car emulator in debug configuration. It determines which code is compiled, which apps are included and what the resulting image runs on.

See also: product config · userdebug

A software update delivered to a vehicle wirelessly.

Over-the-air updates let a car maker fix software after a vehicle is sold. Because there is no way to recover a vehicle that fails mid-update, the design writes the new version to a spare copy of the storage and switches over only once it is complete.

See also: A/B partitions · verified boot

The file listing what software goes into a particular device's image.

A product makefile names the apps, HALs, configuration files and settings that make up one device. Board configuration, separately, describes the hardware it runs on.

See also: lunch target · Soong

The build system AOSP uses, configured with Android.bp files.

Soong reads declarative Android.bp files describing each module — its sources, its dependencies, which partition it belongs on — and works out how to build everything. It replaced the older Make-based system.

See also: product config

A file Android writes when a native program crashes, recording exactly where.

When C or C++ code crashes, the system captures the registers, the stack and the memory map into a tombstone file under /data/tombstones. With the matching symbols it can be turned back into readable function names.

Like a flight recorder. The program is gone, but it left behind enough detail to reconstruct the last moments.

See also: ANR

A build flavour that behaves like production but lets you debug it.

user builds are locked down like a customer's vehicle. eng builds are permissive and fast to build but unlike production. userdebug sits between: security stays enforcing, but you get root over adb and useful diagnostics. It is what platform development uses.

See also: lunch target

A build system that produces a custom Linux distribution from recipes.

Rather than shipping a distribution, Yocto builds one to your specification — you choose every package that goes in. In automotive this matters because you must account for every binary on the device for security and licence compliance, and because you are targeting a fixed board rather than a general-purpose computer.

See also: AGL

A rating for how dangerous it is if a particular function fails.

ASIL levels run from A to D, D being the most critical. The rating decides how rigorously something must be developed and tested. Android is generally not rated at all, which is why anything safety-critical — telltales, airbag control — runs on separate hardware.

See also: cluster · telltale

A log line saying SELinux blocked something.

When SELinux refuses an operation it logs a denial naming who tried, what they touched and what they wanted to do. Denials do not usually crash anything — the operation simply fails — which is why a value that is wrong but consistent is so often a denial.

See also: SELinux

Google's automated tests that check a device behaves like Android is supposed to.

CTS runs thousands of tests against the framework. Passing is required to ship with Google services, and failures usually mean a car maker changed platform behaviour that apps rely on.

See also: VTS · GAS

Using a phone or watch to unlock and start the car instead of a physical key.

Standardised by the Car Connectivity Consortium. It uses secure hardware on both the phone and the vehicle, with ultra-wideband or Bluetooth for proximity. Android is usually not in the trust path at all — a dedicated secure module handles it.

See also: verified boot

A guarantee that one part of a system cannot disturb a more safety-critical part.

When a safety-rated function shares hardware with an unrated one, functional safety standards require proof that the unrated one cannot affect it — through memory, timing or shared resources. It is the requirement that hypervisor partitioning exists to satisfy.

See also: hypervisor · ASIL

A machine-readable list of every software component in a build, with versions.

When a vulnerability is announced, the first question is "are we affected?" Without an SBOM that takes weeks of archaeology across suppliers. With one it is a query. Regulation and customer contracts increasingly require them, and build systems are expected to emit one automatically.

See also: UNECE R155 · OTA

A permission system in the Linux kernel that says which programs may touch which files.

SELinux labels every process and every file, and a policy lists what is allowed. Anything not explicitly permitted is denied. On Android it is always on, and it is the usual reason a correctly written program silently does nothing.

Like a building where every door needs a specific badge. Your badge working everywhere is not the default — every door must be granted individually.

See also: AVC denial · Treble

A permission only apps built into the car's software can hold.

Reading the speed is an ordinary permission any app can request. Moving a window is not — that requires the app to be part of the vehicle image and signed with the car maker's key. This is a schedule decision as much as a technical one: such an app ships when the car maker ships.

See also: verified boot

The rule that hardware code and Android code are kept separate and talk only through fixed interfaces.

Treble splits the system into partitions: Android framework on one, hardware-specific code on another. They communicate only through versioned, stable interfaces. This is what allows Android to be upgraded on a vehicle years later without every supplier rewriting their code.

Like a plug and a socket. You can replace the lamp or rewire the house independently, because the plug shape is agreed and does not change.

See also: HAL · AIDL · VINTF

UN regulations requiring a certified cybersecurity and software-update management system to sell a vehicle.

R155 covers cybersecurity management, R156 covers software update management. They are type-approval requirements in the EU, UK, Japan, Korea and elsewhere — without them a vehicle cannot legally be sold. They turned security and update process from good practice into a condition of doing business, which is why these topics now have budget and audits attached.

See also: OTA · SBOM · zero trust

Each stage of startup checking the next is genuine before running it.

A key burned into the chip verifies the bootloader, which verifies the system, and so on. If any stage has been tampered with, the vehicle refuses to start it. This is why the software cannot simply be edited on a production car.

See also: OTA · signature permission

A manifest listing which hardware interfaces a device provides, and at which version.

The Vendor Interface Object declares each HAL a device implements. Android checks it at startup, and apps can ask whether an interface exists — which is how a feature can be absent on a cheaper trim without anything crashing.

See also: Treble · HAL

Tests that check the hardware-facing code honours its interfaces.

Where CTS tests the framework, VTS tests HALs. For the VHAL it checks the property list is well formed, areas are consistent, and declared limits are actually enforced.

See also: CTS · VHAL

Assuming no component is trustworthy just because it is inside the vehicle.

Traditionally anything on the vehicle network was trusted implicitly. Zero trust replaces that with authentication and authorisation between components, so a compromised part cannot simply command the others.

See also: SDV

The software standard most car ECUs are built to.

AUTOSAR defines how automotive control software is structured. Its signal definitions are published in an XML format called ARXML, which is usually the original source of truth for what data a vehicle produces.

See also: VSS · ECU · SOME/IP

The version of AUTOSAR built for powerful processors and service-based communication.

Classic AUTOSAR targets small microcontrollers with fixed scheduling. Adaptive targets microprocessors running POSIX operating systems, with dynamic scheduling and SOME/IP services. Both exist in the same vehicle, doing different jobs.

See also: AUTOSAR · SOME/IP

One powerful computer running many vehicle functions that used to have their own boxes.

Rather than a hundred small controllers, a few capable processors run the software for many functions at once. This is what makes a function updatable, replaceable and addable after the vehicle ships.

See also: zonal architecture · hypervisor

A publish-subscribe messaging standard used where large amounts of data must move with predictable timing.

Where SOME/IP suits request-response service calls, DDS suits continuous high-volume streams with quality-of-service guarantees — which is why it appears in ADAS and robotics rather than body electronics.

See also: SOME/IP · service-oriented architecture

Designing a car so its features come from software that can be changed later.

A software-defined vehicle treats functions as software running on general-purpose computers, rather than fixed behaviour wired into dedicated ECUs. In practice it means fewer, more powerful computers, service-based communication, and features that can be added after the car is sold.

See also: VSS · SOME/IP · OTA

Components offer named capabilities that others discover and call, instead of broadcasting values.

A seat controller offers a SeatService with a setPosition method; anything that needs it discovers the service at runtime and calls it. Adding a new consumer requires no network redesign, which is the property that lets features be added after production.

See also: SOME/IP · SDV

A way for car components to offer services to each other over a network, rather than just broadcasting.

Where CAN broadcasts numbered messages, SOME/IP lets a component publish named services that others discover and call. It is part of the shift from wiring signals together to treating vehicle functions as software services.

See also: CAN · AUTOSAR · SDV

Extensions that make ordinary Ethernet deliver messages on a guaranteed schedule.

Standard Ethernet is fast but makes no promise about when a packet arrives. Time-Sensitive Networking adds scheduling and reservation so a control message cannot be delayed by a video stream — which is what a vehicle needs before it can replace CAN with Ethernet.

See also: CAN · SOME/IP

An industry-standard naming scheme for car data, like Vehicle.Speed.

The Vehicle Signal Specification is a shared tree of signal names, types and units maintained by an industry body. Its value is that a supplier, a platform team and a UI team can agree on one definition instead of each keeping a private list.

See also: AUTOSAR · SDV

Grouping the wiring by where things are in the car, rather than by what they do.

Instead of a lighting ECU wired to every lamp in the vehicle, a zonal design puts a small controller in each corner of the car. It connects to whatever is physically near it and links back to a central computer over one high-speed cable. Wiring gets dramatically shorter and lighter; the intelligence moves to the centre.

Like a building with a fuse box on each floor instead of one wire from the basement to every socket.

See also: central compute · SDV

A simulated model of a specific vehicle, kept in step with the real one.

A digital twin mirrors a real vehicle's configuration and state closely enough to reproduce its behaviour. It is used to test an update against what a customer actually has, rather than against a generic reference build.

See also: virtual ECU

A capability already present in the vehicle, unlocked after purchase.

The hardware and software shipped with the car; buying the feature issues a signed entitlement the vehicle verifies locally. Commercially attractive and reputationally sensitive — customers object to paying for hardware they already own.

See also: OTA · SDV

A test bench where real ECU hardware runs against a simulated vehicle.

The ECU under test believes it is in a car: its bus inputs come from a real-time simulation of the vehicle rather than from actual sensors. HIL catches timing and electrical problems that pure software simulation cannot, but rigs are expensive and scarce, which is why teams push as much testing as possible down to SIL first.

See also: virtual ECU · shift left

A coding-standard subset of C that bans constructs prone to undefined behaviour.

Safety-critical automotive C is written against MISRA and checked by a static analyser. The rules remove things like dynamic allocation after startup and implicit type conversions — not because they are always wrong, but because their failure modes are hard to argue about in a safety case.

See also: ASIL · AUTOSAR Classic

The company whose badge is on the car — Volvo, GM, Ford.

In automotive, OEM means the vehicle manufacturer. They own the product, set the requirements, and decide what ships. Suppliers (also called Tier 1s) build components and software for them.

See also: Tier 1

Finding defects earlier, where they are cheaper to fix.

Moving testing from late stages that need physical vehicles to early stages that run in a build pipeline. In vehicle software the cost difference between the two is enormous — minutes versus a scheduled test slot.

See also: virtual ECU

A company that builds parts or software directly for a car maker.

A Tier 1 supplier delivers components to the OEM — a head unit, a cluster, a software stack. Much automotive software is written by Tier 1s to an OEM's specification, which is why so much of the platform is designed around clean handover boundaries.

See also: OEM · Treble

A software copy of a vehicle computer, running on a normal machine with no hardware involved.

A virtual ECU lets the real production software be tested on a laptop or a build server. It is the foundation of shift-left testing: defects that would otherwise need a physical vehicle can be found in a pipeline run.

Like a flight simulator. Not the aircraft, but close enough that most training happens there and only the final checks need the real thing.

See also: digital twin · SDV