What is automotive software? One address in three axes

Talk to us about an automotive software build

What is automotive software, and why one label is never enough#

Ask what is automotive software and most pages answer with a list. They name infotainment, then ADAS, then telematics, and stop. However, a list is not an anatomy. Because every feature lives in three places at once, one label can never locate it. Therefore this guide uses a coordinate, not a category.

Consider a single example. Adaptive cruise control is a chassis and ADAS function. Moreover it lives on a domain controller that speaks Automotive Ethernet. Furthermore it runs as an application on AUTOSAR Adaptive. So three answers place it, not one. In short, automotive software is best read as a point in three axes, and the rest of this guide walks each axis in turn.

Axis 1: the five functional domains (what job does the software do?)#

Start with the first axis. It asks a plain question. What job does the software do? Because a vehicle does many different jobs, the software splits into five functional domains. Each domain carries its own determinism and its own safety demand. Those two properties, in turn, decide the bus and the platform it needs.

Powertrain, chassis, body, cockpit, and connectivity as one system#

Read the five domains as one system, not five shopping aisles. First, powertrain and chassis are hard real-time and safety-critical. Therefore they demand deterministic control and high integrity levels. Second, body and comfort are softer. So they ride cheap, slow buses. Third, cockpit and connectivity are compute-heavy. Consequently they need rich operating systems and fast networks. Because each domain has a different demand, each lands on a different bus and a different stack. That is the whole reason the next two axes exist.

Axis 2: where the software physically lives in the E/E architecture#

The second axis asks where the software physically lives. This is the axis nearly every ranking page skips. Yet it is the one that explains the rest. Because a function must run on some box and talk over some wire, its home is a real location. That location is the E/E architecture, short for electrical and electronic architecture. Moreover the E/E architecture is changing fast, and that change is the story of the whole industry.

From distributed ECUs to domain controllers to zonal and central compute#

The shape of the E/E architecture has moved through clear generations. First it was distributed. Then it consolidated by domain. Next it consolidated by location into zones. Finally it centralized onto one computer. Read the four steps below in order, because each one sets up the software-defined vehicle at the end.

Notice the direction of travel. Because boxes keep merging, the count of ECUs falls while the compute per box rises. Therefore functions stop owning hardware and start sharing it. That single trend drives everything after it. The Bosch overview of vehicle E/E architecture is a good primary source for the centralization case.

The buses that connect them: CAN, CAN FD, LIN, FlexRay, Automotive Ethernet#

Boxes need wires. So the second half of this axis is the bus, the network that connects the ECUs. Automotive software does not run on one network. Instead it runs on a small family of them, each tuned for a different cost and speed. The table below turns the usual name-drop into a decision tool.

Read the table as a ladder of cost against speed. Because LIN is cheap and slow, it carries a window motor, not a camera. Because Automotive Ethernet is fast and switched, it carries video and radar. In practice a modern car runs several of these buses at once. Then each signal takes the cheapest bus that still meets its deadline. The bus numbers come from the primary references for the CAN bus, LIN, and FlexRay.

The bandwidth gulf that forces the bus choice#

One number makes the bus choice obvious. So compare the bandwidth each bus can carry against what a modern feature needs. The gap is not small. In fact it spans several orders of magnitude, which is why no single bus can serve the whole car.

Look at the smallest bars first. Because LIN and CAN FD sit near the floor, they vanish next to Ethernet. However, a control signal is tiny, so a slow bus still fits it. A camera stream is the opposite. Therefore high-bandwidth features force Automotive Ethernet, and the worked example further down puts real numbers on that force. The Ethernet speeds come from the reference on single-pair Ethernet over twisted pair.

Axis 3: which layer of the stack the software runs in#

The third axis asks how the software itself is layered. A feature is not one block of code. Instead it is a stack, from the silicon up to the application. Because each layer has a different job, a change at the top is cheap and a change at the bottom is not. The ladder below draws every layer that competitor pages leave out.

Read the ladder from the bottom up. First the silicon exposes registers. Then MCAL, the microcontroller abstraction layer, wraps those registers in drivers. Next an RTOS schedules the tasks. After that the platform runs, and here the stack forks into two. Finally the middleware and the application sit on top. Because the top layers are software on shared compute, they update over the air. Meanwhile the lower layers are frozen at manufacture.

AUTOSAR Classic vs Adaptive: two platforms for two workloads#

That fork in the middle is the important part. AUTOSAR is not one thing. Instead it ships as two platforms for two workloads. Classic is for deterministic control. Adaptive is for high-compute apps. The two snippets below show the same idea in each.

/* AUTOSAR Classic: a fixed 5 ms control task, statically scheduled.
   The period, the signals, and the wiring are all decided before the
   car ships. No dynamic allocation, no runtime discovery. */
FUNC(void, RTE_CODE) Runnable_TorqueControl_5ms(void)
{
    uint16 request  = Rte_Read_TorqueRequest();
    uint16 measured = Rte_Read_TorqueMeasured();

    /* A deterministic plausibility law: same worst-case time every cycle. */
    if (torque_plausible(request, measured) == TRUE)
    {
        Rte_Write_TorqueSetpoint(request);
    }
    else
    {
        Rte_Write_SafeState(TORQUE_LIMP);
    }
}
/* Timing is frozen at build time. That is the point of Classic. */

// AUTOSAR Adaptive: a POSIX service built for high compute, not
// sub-millisecond determinism. Peers are found at runtime over SOME/IP.
#include "ara/com/service.h"

void PerceptionService::OnStart() {
  // The radar proxy is discovered dynamically, never wired at build time.
  auto handle = ara::com::FindService<RadarProxy>();

  handle.SetReceiveHandler([this](const RadarFrame& frame) {
    // Runs on a POSIX thread pool; latency varies with load.
    const auto objects = fusion_.Update(frame);
    cruise_.Plan(objects);
  });
}
// The binary is a container. It can be replaced over the air after sale.

Compare the two shapes. First the Classic task runs on a fixed 5 ms period, decided before the car ships. Therefore its timing is the same every cycle. Second the Adaptive service discovers its peers at runtime over SOME/IP. Consequently it trades strict determinism for compute and flexibility. Because braking cannot miss a deadline, it runs Classic. Because perception needs a lot of compute, it runs Adaptive. The two platforms are defined in the AUTOSAR Classic Platform and the AUTOSAR Adaptive Platform standards.

Locate any feature on all three axes at once#

Now put the three axes together. Because a feature has a coordinate, you can locate any one of them. The tool below does exactly that. First pick a real feature. Then read its three axes resolve at once. Finally step the E/E generation and watch its home migrate.

Step one feature from distributed to central compute. Because the early generations bolt it to its own ECU, it cannot change after sale. However, once the architecture centralizes, the same function becomes a task on shared compute. Therefore it decouples from fixed hardware. That decoupling is the whole point. In short, it is what turns a fixed car into a software-defined vehicle.

A worked example: a rear-right zone under domain vs zonal architecture#

A worked example makes the force concrete. So take the rear-right corner of a modern electric platform. Three real signal classes terminate there. First, four body actuators, a window, a lock, a mirror, and a seat, historically on a 19.2 kbit/s LIN sub-bus. Second, a door-mounted surround-view camera streaming about 3.5 Gbit/s of raw video. Third, a wheel-speed sensor feeding the brake loop on CAN FD, which tops out at 8 Mbit/s.

The camera is the problem. CAN FD, the fastest classic control bus, tops out at 8 Mbit/s, or 0.008 Gbit/s. Yet the surround-view camera needs about 3.5 Gbit/s. That is roughly 438 times more bandwidth than CAN FD can carry, the same gulf the earlier bandwidth chart already plotted across every bus. Therefore the gap, not preference, decides the wiring, and it forces Automotive Ethernet at this corner.

Under a domain architecture each signal runs its own harness back to a domain controller. Therefore the rear-right corner needs three separate cable runs. That is copper, weight, and cost, repeated at every corner of the car.

Under a zonal architecture all three terminate at one rear-right zone ECU. Because the zone aggregates locally, the LIN body signals share it. Meanwhile the camera rides 1000BASE-T1 at 1 Gbit/s, or multi-gig single-pair Ethernet up to 10 Gbit/s, and the wheel-speed signal rides CAN FD. Then one Ethernet backbone link carries the consolidated traffic to the central computer. Bosch reports this zone-oriented approach removes up to 20 percent of the control units and shortens the harness. Moreover, consolidating the software onto the vehicle computer is what makes fleet-wide over-the-air updates practical.

Why automotive software is different from general application software#

Step back and ask why automotive software feels so different. Because the constraints are different, the whole discipline is different. General application software assumes cheap memory and forgiving latency. Automotive software assumes neither. The table below sets the two side by side.

Read the failure row twice. Because a web retry costs a refund, general software can fail and recover. Because a brake fault can injure, automotive software cannot. Therefore the rigor is not bureaucracy. Instead it is the price of the risk. That risk is also why the structure is safety-partitioned, which the callout below explains.

Why centralizing makes the software-defined vehicle possible#

Here is the causal link the whole page builds toward. First, in a distributed architecture, a function owns its ECU. Because it is fused to that hardware, it ships once and then stays fixed. Second, as the architecture centralizes, the function moves onto shared compute. Therefore it stops being a box and becomes software. Once it is software on a central computer, you can rewrite it after the car is sold.

When this three-axis framing does not apply#

How this software is built, and how it is verified: read next#

This guide covered what automotive software is and how it is organized. Two neighbouring questions deserve their own posts. First, how is this software built and certified? Second, how is it verified? Because both threads are large, this post hands them off rather than repeating them.

Beyond the vehicle, the same structural thinking applies to any complex build. For the fundamentals, read our guide to custom software development fundamentals. For the wider map, read the guide to the types of custom software. If you want a partner who works this way, explore Atyantik's custom software development services.