The automotive software development process, run as one program spine

Talk to us about a safety-critical program

Why the V-model dominates safety-critical automotive software#

Most guides to the automotive software development process open with a definition list. First they define the V-model. Then they define ASPICE, ISO 26262, MISRA, and AUTOSAR in turn. However, a definition never shows how the standards mesh on a real program. Therefore this guide refuses the glossary. Instead it threads one hazard through a single spine and clips every standard to it.

The V-model looks like a waterfall bent into a V. Yet the shape carries a claim the waterfall never made. Because each descending activity has an ascending partner, every definition step gains a matching proof step. So the automotive software development process is not a line from idea to code. Rather it is a set of pairs, and the pairing is the whole point.

The left leg defines, the right leg proves#

Read the diagram as pairs, not as two separate arms. First the safety goal at the top is validated by the on-vehicle test at the top of the other leg. Then the software architecture is proved by the software integration test. Next the unit design is proved by unit verification. Because every artifact earns a matching check, nothing ships unverified. In short, the pairing is what turns a drawing into an accountability structure.

This pairing also fixes the meaning of two words teams use loosely. Verification asks whether you built the thing right against a spec. Validation asks whether you built the right thing against the real world. Therefore the right leg is mostly verification, and only the top step is validation. Consequently a clean verification pass can still fail validation, and that gap is where field defects hide.

Why not Agile or pure waterfall for an ASIL D function#

Agile suits software where a wrong guess is cheap to correct. However, an ASIL D steering fault can kill, so a wrong guess is not cheap. Because the safety case needs traceable evidence at every step, the process cannot skip the paired proofs. Therefore the rigor is not bureaucracy. Instead it is the price of a hazard that severe.

Pure waterfall fails for the opposite reason. It defines everything, builds everything, then tests at the end. Yet a late defect in a safety function is the most expensive kind to fix. Because the V-model verifies at every rung, it catches defects while they are still cheap. So the automotive software development process keeps the discipline of waterfall and adds the paired proofs that waterfall lacks. Later sections show where even the V-model strains against continuous delivery.

The one function we follow: an ASIL D steering hazard#

A worked thread beats an abstract lifecycle. So pick one hazard and follow it the whole way. Our hazard comes from a hazard analysis and risk assessment. The function reads: no unintended steering torque at highway speed. Because unwanted self-steering can cause a fatal loss of control, it lands at ASIL D, the highest integrity level.

How a real automotive software development process runs four standards at once#

Here is the wiring diagram nobody draws. Each row is a V-model stage. The columns clip the four layers together: the V-model activity and deliverable, the ASPICE process ID with its CL2-versus-CL3 evidence, the ISO 26262 part.clause with its ASIL-scaled work product, and the V&V gate. Read one row and you see how all four standards land on the same stage at the same time. This is the single cross-walk the SERP leaders keep siloed.

Layer 1: the V-model activity and its deliverable#

The first column names what each stage produces. Because every stage owns a concrete deliverable, the process never trades in vague intent. First SYS.2 produces technical safety requirements. Then SWE.2 produces the software architecture. Next SWE.3 produces the unit design and its code. So the automotive software development process is a chain of deliverables, each one the input to the next.

Layer 2: the ASPICE process ID and the CL2 vs CL3 evidence#

ASPICE rates how capably you run each process, not whether the product is safe. The scale runs from CL1 performed, to CL2 managed, to CL3 established. Therefore the second column states what an assessor samples at each rung. At CL2 the assessor wants the work product planned, baselined, and traced. At CL3 the assessor wants the same process derived from an organisational standard with defined roles. The VDA Automotive SPICE reference is the binding source for the process reference model.

Layer 3: the ISO 26262 part.clause and its ASIL-scaled work product#

ISO 26262 attaches a functional-safety work product to each stage. Moreover the rigor of that work product scales with the ASIL. Because our function is ASIL D, the coverage and independence obligations sit at the top of every table. The third column names the exact part and clause, so the work product is never a guess. The standard itself is the ISO 26262 road-vehicle functional safety series.

Layer 4: the V&V gate, and where the testing page takes over#

The fourth column names the gate that lets the stage pass. Because this post is about the process, it stops at the gate name. However, the test methods behind those gates deserve their own treatment. Therefore the actual techniques, MIL, SIL, PIL, and HIL, live in the automotive software testing techniques guide. Read this post for how the standards mesh, and read that one for how each gate is actually run.

The safety thread, followed node by node#

The cross-walk shows the stages side by side. Now walk the trace itself. Traceability is bidirectional, so you can start at any artifact and move both ways. The interactive thread below makes that concrete. Select any node and the whole chain re-tints to show what it derives from and what verifies it. Because the relation is labelled in text as well as colour, it reads the same with or without sight of the tint.

Down the left leg: safety goal to FSR to TSR to software safety requirement to unit#

The left leg derives one artifact from the one above it. First the safety goal states the outcome to protect. Then the functional safety requirement says what the system must do to hold it. Next the technical safety requirement makes that testable at the system level. After that the software safety requirement pins it to a 5 ms plausibility check. Finally the architecture and unit design place that check in an independent partition. Because each step traces to its parent, an assessor can walk the chain in either direction.

At the bottom of the V: MISRA and AUTOSAR discipline in the implementation#

At the vertex of the V, the design becomes code. Because the code runs a safety function, it must obey a coding standard. MISRA C is that standard for automotive C, and AUTOSAR Classic is the runtime it sits on. The tabs below show the same plausibility unit three ways. First a version that violates three MISRA rules. Then the compliant rewrite of the same logic. Finally a deviation record, which is how a genuinely needed exception is documented rather than silenced.

/* MISRA C:2023 NON-COMPLIANT. torque_plausibility_check():
   the static analyser flags three rules on this unit. */
int16_t torque_plausibility_check(int16_t demanded, uint16_t estimated)
{
    int16_t delta;
    /* Rule 10.4: operands mix signed and unsigned essential types. */
    delta = demanded - estimated;
    /* Rule 14.4: the controlling expression is not a boolean.
       Rule 15.6: the if body has no braces. */
    if (delta)
        return fault_flag = 1;   /* Rule 13.4: the assignment result is used. */
    return 0;
}
/* Three deviations, one 20-line unit. On an ASIL B(D) element this fails review. */

/* MISRA C:2023 COMPLIANT. The same plausibility law, deviations removed. */
int16_t torque_plausibility_check(int16_t demanded, int16_t estimated)
{
    /* Same essential type on both operands, explicit cast on the result. */
    int16_t delta = (int16_t)(demanded - estimated);

    if (delta > TORQUE_TOLERANCE)   /* explicit boolean, Rule 14.4 satisfied */
    {                               /* braces mandatory, Rule 15.6 satisfied */
        fault_flag = 1;             /* assignment stands alone, Rule 13.4 ok */
        return 1;
    }
    return 0;
}
/* The law is unchanged. The analyser is now silent, and the unit is traceable. */

Deviation record DEV-STEER-014
--------------------------------------------------------------
Rule        MISRA C:2023 Rule 11.4 (cast between pointer and integer)
Location    hal_steer.c, memory-mapped register write
Category    Advisory
Rationale   Register addresses are fixed in the SoC memory map. The cast is
            confined to one HAL translation unit and checked against the
            device datasheet. No arithmetic runs on the cast value.
Containment Encapsulated in the REG_WRITE macro; reviewed by two people.
Approved    Functional safety manager, ASIL B(D) monitoring element
Trace       TSR-STEER-07 -> SW-SR-STEER-19 -> unit hal_steer_write()
--------------------------------------------------------------
A deviation is a documented, approved exception. It is not a silenced warning.

Notice that the law never changed between the first two tabs. Instead the second tab removes the ambiguity the analyser flagged. Because a signed-unsigned mix or a missing brace can hide a real defect, the rules are not style preferences. The MISRA C:2023 guidelines are the source for each rule, and the runtime contract comes from the AUTOSAR Classic Platform standard. The third tab matters too. A deviation is an approved, contained exception with a rationale, not a warning you turned off.

Back up the right leg: unit test to integration to safety validation#

From the vertex the thread climbs. First unit verification proves the code against the unit design, with MC/DC coverage because the function is ASIL D. Then software integration proves the partitions hold together and stay independent. Next software qualification tests against the software safety requirements. Finally safety validation proves the safety goal on the vehicle. Because each step verifies a specific left-leg artifact, the climb closes every pair the descent opened. The methods behind these steps are covered in the sibling testing guide.

Worked ASIL decomposition: one ASIL D channel into two ASIL B(D) channels#

ASIL D on one monolithic channel is expensive to build and verify. So ISO 26262 offers a lever. Because a requirement can be met by two sufficiently independent elements, an ASIL D goal can split across them. The calculator below works the arithmetic. Set the hazard parameters, read the determined ASIL, then pick a decomposition scheme and watch the per-element metric burden drop.

Step 1: classify the hazard, S3 x E4 x C3 = ASIL D#

ISO 26262-3 rates three parameters. Severity S3 means life-threatening or fatal injuries. Exposure E4 means a high-probability situation, such as normal highway driving. Controllability C3 means the average driver cannot control the outcome. Because the risk-graph cell for S3, E4, and C3 sits at the top, the hazard classifies as ASIL D. So the strictest obligations apply to every downstream stage.

Step 2: decompose with the ASIL algebra, 4 = 2 + 2#

ISO 26262-9 Clause 5 defines a small algebra. Map the levels to numbers: QM is 0, A is 1, B is 2, C is 3, and D is 4. Because an ASIL D requirement scores 4, it can split across two independent elements whose values sum to 4. The chosen scheme is ASIL B(D) plus ASIL B(D), that is 2 plus 2. The tag B(D) records that each element still traces to an original ASIL D goal. However, the split is valid only when freedom from interference is proved through Dependent Failure Analysis, per ISO 26262-9, Clause 7.

Step 3: the metric relief this buys, SPFM, LFM, PMHF#

The split changes the hardware-metric burden per element. An undecomposed ASIL D element must reach a Single-Point Fault Metric of 99 percent, a Latent-Fault Metric of 90 percent, and a random-failure budget below 10 FIT. After the split, each ASIL B(D) element only needs 90 percent, 60 percent, and a budget below 100 FIT. So the random-failure budget per element loosens by a factor of ten. The comparison below makes that relief felt.

Read the relief as a trade, not a discount. Because the burden moves from one gold-plated channel to two cheaper channels plus an independence claim, the team now builds a primary controller and an independent monitor. However, the independence itself must be proved, or the whole relief collapses. So decomposition saves cost only when the freedom-from-interference argument is real. For the budget picture around choices like this, see what custom software development costs at this level of rigor.

Locating your program's real maturity: ASPICE CL1 to CL2 to CL3#

Teams often claim a capability level they cannot evidence. So use this self-locator to find your true rung. Each row states what an assessor asks, the evidence you must show, and the gap that caps you below the next level. Because the levels build on each other, a hole at CL2 pulls the whole process back to CL1, whatever the intent.

Because most automotive programs target CL2 or CL3, the honest question is where your evidence actually sits today. First check whether every requirement traces both ways. Then check whether your process is written down as an org standard, not carried in one lead's head. If either check fails, you know your real rung, and you know the next thing to fix.

The time dimension: concept to start of production#

The V-model shows structure, not calendar. So overlay it on the real automotive milestones. The timeline below runs from concept freeze to start of production, or SOP. Because the samples harden the design in stages, the V is not run once. Instead slices of it repeat as the hardware matures from A-sample to C-sample. This concept-to-start-of-production spine is what tool-vendor diagrams usually omit.

The change-management loop that re-triggers a slice of the V#

A late change is the real test of the process. Suppose a torque sensor is swapped after design freeze. Because the change may touch a safety goal, you cannot just edit the code. Instead an impact analysis decides which artifacts and units are affected. Then the affected slice of the V re-opens, re-verifies, and if the safety goal is touched, re-validates. Finally the traceability and the interface agreement are re-baselined. The loop below draws that cycle.

What tool-vendor pages won't tell you#

When NOT to run the full V#

Where to go next#

This post covered the process. The companion methods and the wider context live next door. For the test techniques behind every V&V gate, read the automotive software testing techniques guide, which traces one ASIL D requirement down the MIL, SIL, PIL, and HIL chain. For the generalised lifecycle beyond safety-critical work, read the enterprise software development lifecycle guide. To see where embedded and safety-critical systems sit among other build types, read the guide to custom software categories.

So treat this cross-walk as a planning tool. First determine the ASIL from your hazard analysis. Then decide how far each requirement must travel down the V. Finally decide whether a decomposition earns its independence cost. If you want a partner who works this way, explore Atyantik's software development services. Measure the hazard first, then run only as much process as the safety goal demands.