AIAG CQI-34 (Software Assurance Approval Process / SwAAP): AIAG CQI-34 – Tutorial (about 60 minutes)

AIAG CQI-34, the Software Assurance Approval Process (SwAAP), is an automotive industry manual that gives customers and suppliers one shared, structured way to approve software and to manage changes to it, in the same spirit as the Production Part Approval Process (PPAP) that the industry already uses for physical parts. It is read by software and systems engineers, supplier-quality and software-quality staff, release and configuration managers, and programme managers at carmakers (OEMs) and their suppliers. After this tutorial you will be able to explain why SwAAP exists, describe the building blocks of a PPAP-style software approval, plan an approval package and a change re-approval for a real software release, and position CQI-34 next to Automotive SPICE, ISO 26262, ISO/SAE 21434, UN Regulation No. 156 and IATF 16949.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: CQI-34 Software Assurance Approval Process (SwAAP), 1st edition, published by the Automotive Industry Action Group (AIAG, USA) and developed with experts from OEMs and tier suppliers. AIAG's manuals catalogue dates the listing January 2025 and sells it as an e-document in English and Portuguese (item XD-CQI-34). It is current; no revision or second edition had been announced when this course was checked. AIAG files it under its "Digital, Software and Data" continuous quality improvement (CQI) publications. Verified 2026-10-29 against the AIAG CQI-34 product page and the AIAG Digital, Software and Data page.

An honest note on sources: the manual itself is a paid, copyrighted document and AIAG does not publish its table of contents. AIAG's public description says three things clearly: the process is modelled on PPAP, it covers software that is stand-alone or part of a larger system, and it offers industry-recommended ways to evaluate software development quality and to handle software change. This tutorial teaches those ideas, explains the PPAP model that SwAAP borrows from, and shows how a PPAP-style approval naturally applies to software. Where the exact names of elements, forms or levels matter, check your licensed copy of CQI-34 and your customer's customer-specific requirements; this course does not invent them.

Who it is for: engineers, quality and supplier-quality staff, software release managers, project managers and auditors who are new to software approval in the automotive supply chain, including people who know PPAP for hardware but have never approved a software release, and software people who have never met PPAP.

Prerequisites: none. A rough idea of how software is developed (requirements, code, tests, releases) helps, and so does knowing that cars contain many electronic control units, but every term is explained when it first appears.

By the end of this tutorial:

You will be able to explain the problem CQI-34 was written to solve and why the industry chose PPAP as its model.
You will be able to define the core vocabulary of software approval: baseline, software identification, approval package, warrant, interim approval, change notification and re-approval.
You will be able to describe the building blocks that a PPAP-style software approval has to cover, from scope and identification to evidence of development quality.
You will be able to walk through the approval lifecycle of a software release, including what happens when the software changes after approval.
You will be able to explain who decides on approval, what forms of approval exist in the PPAP model, and why there is no CQI-34 certificate for an organisation.
You will be able to plan a software approval for a realistic supplier release and its first change.
You will be able to explain how CQI-34 relates to PPAP, Automotive SPICE, ISO 26262, ISO/SAE 21434, UN Regulation No. 156 and IATF 16949.

Lesson 1 – Origins, purpose and scope

Why software needed its own approval process

For decades the automotive supply chain has had a well-understood answer to a simple question: "How does a carmaker know that a supplier's part, made in series production, really meets every requirement?" The answer is PPAP. Before a supplier ships production parts, it submits evidence (dimensional results, material tests, process studies, a control plan and more) and the customer formally approves the part. If the part or its production process changes later, the supplier must tell the customer and, where required, get the part approved again.

Modern vehicles, however, are defined as much by software as by metal and plastic. Brakes, steering, battery management, driver assistance, infotainment and body electronics are all controlled by electronic control units (ECUs) running software, and many vehicles now receive software updates over the air long after they leave the factory. The physical part may be approved through PPAP, but the software inside it can change many times during development and after launch. Each carmaker tended to solve this in its own way: one might ask for a release note and a test report, another for a custom approval form, a third for a portal with its own checklist. AIAG's description of CQI-34 names the problem directly: there was growing variation in software approval processes across the industry.

That variation is expensive. A tier-1 supplier that delivers similar software to five carmakers has to produce five different approval packages, each with its own vocabulary and evidence expectations. Sub-tier software suppliers face the same problem one level down. Inconsistent approval also creates risk: when nobody agrees on what "approved software" means, a version can reach production without the evidence that would have exposed a defect, or a small change can slip through without anyone asking whether it needs re-approval.

Why PPAP was the model

The working group behind CQI-34 did not start from a blank page. PPAP is familiar to every automotive quality professional, IATF 16949 requires a customer-defined product approval process, which carmakers' requirements usually fulfil with PPAP, and its logic is sound: define the item precisely, collect objective evidence that it meets requirements, have the customer approve it formally, and control every later change. Those same four ideas are exactly what software approval needs. Building SwAAP on PPAP means a supplier-quality engineer recognises the structure immediately, and a software engineer learns one consistent set of expectations rather than one per customer.

Figure 1 – SwAAP borrows the PPAP pattern of identify, prove, declare, approve and control change, and applies it to software.

Scope

According to AIAG, CQI-34 applies to software whether it is delivered on its own or as part of a larger system. In practice that covers a wide range of deliveries:

Embedded software flashed into an ECU that the supplier also manufactures, where the hardware goes through PPAP and the software needs its own approval.
Software delivered separately from hardware, for example a software component that the carmaker integrates into its own ECU or a central computer.
Software updates to parts already in production or already in the field, including updates that will be distributed over the air.
Configuration and parameter data that changes the behaviour of the software, where the customer treats it as part of the approved release.

CQI-34 is a process for approving software and controlling its change. It is not a coding standard, not a functional safety standard and not a cybersecurity standard. It does not tell a team how to write code; it tells a supplier and a customer how to agree that a particular, precisely identified software release is fit to be used in production and how to keep that agreement valid when things change.

Who uses it

Three groups use the manual. Carmakers use it as a common reference when they write their supplier requirements, so suppliers see familiar terms. Tier-1 suppliers use it both when they submit software to carmakers and when they approve software from their own sub-tier software suppliers. Software-only companies entering the automotive market use it to understand what "production approval" means in an industry where they may never have shipped a physical part. In each case the shared goal is the one AIAG states: a consistent approach across the whole supply chain.

Lesson 2 – Key concepts and vocabulary

Software approval mixes vocabulary from two worlds, automotive quality and software engineering. The terms below are the ones you need; where CQI-34 may use a slightly different label, the concept is what matters.

Software assurance – the level of confidence, backed by evidence, that software does what it should, does not do what it should not, and was produced by a controlled process. Assurance is about justified confidence, not a guarantee of zero defects.
Software approval – the customer's formal decision that a specific, identified software release may be used for its intended purpose, usually series production. Approval is given to a release, not to a company.
PPAP (Production Part Approval Process) – the AIAG process, current 4th edition from 2006, by which a supplier proves that a production part and its manufacturing process meet customer requirements and the customer approves the part. CQI-34 is modelled on it.
Part Submission Warrant (PSW) – in PPAP, the summary document in which the supplier declares that the submitted part meets all requirements and that the evidence is on file. SwAAP uses the same idea of a signed supplier declaration that summarises the submission.
Submission level – in PPAP, one of five levels that tell the supplier how much evidence to send to the customer and how much to keep on file. Level 3 is the default unless the customer says otherwise. The idea that the customer chooses how much evidence it wants to see carries over to software.
Software baseline – a frozen, reviewed set of configuration items (source code, build scripts, configuration data, documents) that defines one release. A baseline cannot change; any change creates a new baseline.
Software identification – the unique name and version (and often a customer software part number and a checksum or hash) that lets anyone tell exactly which software is in a unit. Without reliable identification, approval has nothing to attach to.
Configuration management – the discipline of identifying configuration items, controlling changes to them, recording their status and auditing that what was built matches what was documented.
Release note – the document that accompanies a software release and explains what it contains: version, new functions, fixed defects, known open issues, restrictions and compatibility with hardware and other software.
Verification and validation – verification checks that the software meets its specified requirements ("did we build it right?"); validation checks that it serves its intended use in the vehicle ("did we build the right thing?").
Traceability – documented links from customer requirements to software requirements, design, code and tests, so that every requirement can be shown to be tested and every test can be tied to a requirement.
Interim approval – in PPAP, a time-limited or quantity-limited permission to ship while some requirement is still open, under an agreed action plan. A software release can be approved in the same conditional way, for example for a pilot build.
Change notification – the supplier's obligation to tell the customer before making a change that could affect the approved item, so that the customer can decide whether re-approval is required.
Re-approval – a new approval for a changed release. Its depth depends on the size and risk of the change, but it always produces a new approved identification.
Customer-specific requirements (CSRs) – each carmaker's additional rules on top of common industry manuals. CSRs can set approval levels, forms, portals and timing, and they always take precedence for that customer.
Software bill of materials (SBOM) – a list of the software components, including open-source and third-party libraries and their versions, that make up a release. Many customers now ask for it as part of the evidence because it supports licence, vulnerability and change analysis.

Assurance versus approval

Two words in the title deserve a closer look. Assurance is something the supplier builds up over the whole development: every review, test, analysis and audit adds evidence. Approval is a single, formal decision taken by the customer at a defined point, based on a summary of that evidence. A good SwAAP submission is therefore not a pile of documents created at the end; it is a curated view of evidence that already exists because the development process produced it. If the evidence has to be invented at the last minute, the assurance was never there.

Why identification is the foundation

In PPAP, a part is identified by its part number and drawing revision level. Software needs an equally strict identity, and it is easy to get wrong. Two builds from the same source code can differ if compiler versions, build options or included libraries differ. A version string printed on a screen can be correct while the flashed binary is not. That is why mature suppliers tie each approved release to a version, a customer part number where one exists, and a cryptographic hash of the delivered files, and why they can reproduce the exact binary from the archived baseline.

Lesson 3 – Structure: the building blocks of a software approval

Because the manual's contents are not public, this lesson does not list CQI-34's chapters. Instead it explains the building blocks that any PPAP-style software approval must cover, which is what the manual sets out to standardise. When you open your copy of CQI-34, you will be able to place each of its sections against these blocks.

Block 1 – Scope and approval trigger

Every approval starts with a clear statement of what is being approved and why now. Typical triggers are the first production release of new software, a release for a new vehicle programme, a change to approved software, a change of development site or sub-supplier, or a correction after a field problem. The trigger influences how much evidence is needed: a first release needs the full set, a small change may need a focused set.

Block 2 – Identification and configuration

The submission must identify the release exactly: software name, version, customer part number, hashes of the delivered files, the hardware it is intended for, and compatible versions of other software it depends on. It must also show that the release comes from a controlled baseline, so that the supplier can rebuild it and can say precisely what changed relative to the last approved version.

Block 3 – Requirements and traceability

The customer needs to see that its requirements were understood and covered. Evidence here includes the agreed requirements baseline, the supplier's software requirements derived from it, and a traceability analysis showing which tests cover which requirements and which requirements, if any, are not yet covered.

Block 4 – Verification and validation results

This is the software equivalent of PPAP's dimensional and performance results. It typically includes unit, integration and qualification test results, regression results against the previous release, results on target hardware, and results from the customer's integration or vehicle tests where they exist. Test results are only meaningful if they are tied to the exact version being approved, which is why Block 2 comes first.

Block 5 – Evidence of development quality

AIAG's description of CQI-34 highlights industry-recommended methods for evaluating software development quality. This block answers the question "Was this software produced by a process we can trust?" Evidence may include process assessment results (for example against Automotive SPICE), review records, static analysis and coding-guideline results, defect statistics and the status of open problem reports. Where the software has safety or cybersecurity relevance, the corresponding work products, such as a safety case or cybersecurity case, are referenced here rather than repeated.

Block 6 – Open issues and risk

No release of real software is defect-free. A trustworthy submission lists known open issues, their severity, their effect on the vehicle, any workaround, and the plan and date to close them. Hiding open issues is the fastest way to lose a customer's trust; disclosing them openly is what makes interim approval possible.

Block 7 – Supplier declaration and customer decision

Finally, as in PPAP, a responsible person at the supplier signs a summary declaration that the release meets requirements (or lists where it does not) and that the supporting evidence is on file. The customer reviews the submission at the agreed depth and records its decision.

Block 8 – Change management

Approval is only the beginning. The process must define how changes are classified, when the customer must be notified, which changes need re-approval, and how the approved version history is maintained. AIAG calls out change management explicitly as one of the complexities CQI-34 helps organisations handle.

Figure 2 – The eight building blocks of a PPAP-style software approval package: what is approved, the evidence for it, and the decision and later change control.

How the blocks scale

PPAP uses submission levels so that the customer can ask for little evidence on a low-risk part and a lot on a critical one. A software approval scales in the same way. A carry-over release with a one-line calibration change and a strong regression suite needs far less submitted evidence than the first release of brake-control software. Whatever the depth, the blocks stay the same; only the amount of evidence sent, and the amount kept on file for audit, changes. Your customer's requirements, interpreted alongside CQI-34, decide the depth.

What stays on file

Another PPAP habit worth keeping is the difference between "submitted" and "retained". Even when the customer only asks for the declaration, the supplier must have the complete evidence available for review. In software terms that means archived baselines, build environments, test logs and reports, kept for the retention period the customer requires, often the life of the vehicle programme plus service years.

Lesson 4 – How it works in practice

Roles

A software approval involves several roles, whatever titles your organisation uses:

Software project lead – owns the release content and plan, and ensures the evidence is produced during development rather than at the end.
Configuration and release manager – controls baselines, builds the release reproducibly, assigns identification and maintains the version history.
Test lead – plans and runs verification, keeps results tied to versions, and reports coverage and regressions.
Software quality assurance – independently checks that the process was followed and that the evidence is complete and consistent, and usually prepares or reviews the approval package.
Supplier signatory – the authorised person who signs the supplier declaration, accepting accountability for its accuracy.
Customer software quality or supplier quality engineer – reviews the submission, asks questions, and records the approval decision.

The approval lifecycle

The most useful way to think about SwAAP in practice is as a lifecycle for each software release. A release is developed and baselined, its evidence is assembled, it is submitted, and the customer decides. An approved release is then used in production until it is superseded. Any change sends the process back to the start, but with a scope that matches the change.

Implementation steps for an organisation

An organisation adopting CQI-34 typically works through the following steps.

Read the manual and your customers' requirements together. CQI-34 gives the common framework; each carmaker's CSRs tell you which forms, portals, levels and timing apply. Build a simple matrix showing, per customer, what is expected.
Map your existing evidence. Most suppliers with an established software process already produce release notes, test reports and configuration records. Map them to the approval blocks and find the gaps rather than creating a parallel set of documents.
Fix identification first. Agree on how every release is named, versioned and hashed, how the customer part number is linked, and how the version can be read from a unit in the field. Everything else depends on this.
Define change classes. Decide, together with customers, which kinds of change need only notification, which need a focused re-approval and which need a full one. Typical criteria are effect on safety- or security-relevant functions, effect on interfaces, and size of the change.
Automate evidence collection. Continuous integration pipelines can produce build records, hashes, test results and static-analysis reports for every baseline automatically. This keeps evidence current and tied to versions.
Template the package and the declaration. Create a standard package structure aligned with CQI-34 so that every project submits in the same shape.
Extend it to sub-tier suppliers. Apply the same approach to software you buy, including commercial and open-source components, so that your own submission rests on approved inputs.
Train and review. Train project leads, testers and quality staff, then review the first few submissions closely and improve the templates.

Working with the development process, not against it

A common misconception is that software approval is a gate bolted onto the end of agile development. In a healthy setup the approval is the natural output of a disciplined pipeline: each sprint or increment produces traceable, tested, identified baselines, and the approval package for a production release is mostly a selection and summary of what already exists. Teams that release frequently, including over the air, gain the most from this, because they cannot afford a manual, weeks-long evidence hunt for every update.

Change management in detail

Software changes far more often than hardware, so change control is where SwAAP earns its value. A sound change process records every proposed change, assesses its impact (which functions, interfaces and requirements are affected, and whether safety or cybersecurity analyses must be updated), decides whether the customer must be notified, and determines the depth of re-approval. Regression testing is central: the supplier must show not only that the change works but that nothing else broke. The approved version history must show, for every version in production, what changed, why, and who approved it.

Some changes are not code changes at all but still change what the customer receives: a new compiler version, a different build server, a new third-party library version, a move of development to another site, or a new sub-supplier. In PPAP, a change of manufacturing location or sub-supplier requires notification even if the drawing is unchanged. The same thinking applies to software: changes to how the software is produced can change its behaviour, and the customer should be told.

Lesson 5 – Assessment, approval and compliance

There is no CQI-34 certificate

CQI-34 is not a certification scheme. No accredited body audits a company and issues a "CQI-34 certificate", and no company can be "SwAAP certified" as an organisation. What exists is approval of individual software releases by the customer that receives them. This mirrors PPAP exactly: nobody holds a PPAP certificate; parts are PPAP-approved by customers. Be cautious of any offer that claims to certify an organisation against CQI-34; at most, training providers issue course attendance certificates, which say nothing about any release.

Who decides and how

The customer that receives the software decides. That may be a carmaker approving a tier-1 release, or a tier-1 approving a sub-tier component. The customer reviews the submission at the depth it has requested, may ask questions, may witness tests or audit the supplier's records, and then records a decision. Following the PPAP model, three outcomes are useful to know:

Approved – the release meets requirements and may be used as agreed, typically in series production.
Interim approval – the release may be used for a limited time, quantity or purpose (for example a pilot build or a specific vehicle derivative) while defined open items are closed under an agreed action plan.
Rejected – the evidence does not show that the release meets requirements; the supplier must correct the software or the evidence and resubmit.

Exact status names and the forms used to record them are set by CQI-34 and by each customer's requirements; check both.

Figure 4 – A typical approval exchange: the customer sets the evidence depth, reviews the package with its engineers, and records the decision.

How evaluators judge a submission

Whether you are preparing a submission or reviewing one, the same questions decide the outcome:

Is the release identified so precisely that the approved binary can be recognised in any unit and rebuilt from the archive?
Is every customer requirement traced to passing tests on this exact version, and are gaps explained?
Do regression results show that unchanged functions still work?
Is there credible evidence that the development process was controlled, for example a recent process assessment and review records?
Are open issues listed honestly, with severity, effect and closure plans?
Are safety and cybersecurity work products, where relevant, referenced and consistent with the release?
Does the declaration match the evidence, and is it signed by someone with authority?

Where compliance obligations come from

CQI-34 becomes binding through contracts and requirements, not by law. A carmaker may reference it in its supplier quality manual or CSRs, and a tier-1 may pass it to its sub-suppliers. It also helps suppliers meet obligations they already have. IATF 16949, the automotive quality management system standard, contains a requirement (clause 8.3.2.3) for organisations that develop products with internally developed embedded software to have a quality assurance process for that software, to use a software development assessment method, and to keep a record of a software development capability self-assessment. A structured, evidence-based approval process supports that requirement, although following CQI-34 does not by itself make an organisation IATF 16949 compliant.

Regulation also raises the stakes. Under UN Regulation No. 156, vehicle manufacturers that want type approval in the countries applying it must operate a certified software update management system and keep track of the software versions that are relevant to type approval. A carmaker in that position needs its suppliers to deliver precisely identified, controlled and documented software and to report changes reliably. SwAAP-style approvals are one practical way suppliers support that, but the regulatory certification belongs to the vehicle manufacturer, not to CQI-34.

Internal audits of the approval process

Even without certification, organisations should audit their own approval process. Useful audit checks include picking a random unit from production and confirming its software identification matches an approved release, picking a recent change and tracing it through notification, impact analysis, regression testing and approval, and confirming that archived baselines can actually be rebuilt. These checks find weaknesses before a customer audit or a field problem does.

Lesson 6 – Worked example

To tie the ideas together, follow a fictional but realistic supplier, Northvale Controls, a tier-1 that makes electric power steering ECUs. Its customer, a carmaker, has adopted CQI-34 as the basis of its software approval requirements and added its own CSRs. Northvale must approve software version 4.0 for the start of production of a new vehicle, then handle a change six months later.

Step 1 – Clarify the expectations

Northvale's software quality lead reads CQI-34 alongside the carmaker's CSRs. The CSRs specify the approval forms, the portal for submissions, that full evidence must be submitted for a first production release, and that safety-relevant changes always need re-approval. The lead builds a one-page checklist that maps each requirement to Northvale's existing work products and an owner.

Step 2 – Lock down identification

The release manager confirms the naming scheme: application software 4.0.0, bootloader 2.1.3 and a calibration data set C-17, each with a SHA-256 hash, all three together identified by one customer software part number assigned by the carmaker. The ECU reports all three versions through its diagnostic interface, so a service technician or end-of-line tester can read them. The release manager also proves that the pipeline can rebuild 4.0.0 bit-for-bit from the archived baseline, including the frozen compiler version.

Step 3 – Assemble the evidence

Because Northvale's pipeline runs on every merge, most evidence already exists:

The requirements baseline agreed with the carmaker and a traceability report showing 1,412 of 1,420 requirements covered by passing tests on 4.0.0; the 8 uncovered ones relate to a trailer-mode feature the carmaker deferred, documented in writing.
Unit, integration and hardware-in-the-loop qualification results tied to 4.0.0, plus regression results against the previous pre-series release 3.6.
Static analysis results against the agreed coding guideline, with all deviations justified.
A recent Automotive SPICE assessment of the steering software project and the closure status of its findings.
A reference to the functional safety case for the steering function, updated for 4.0.0, and to the cybersecurity work products for the diagnostic and update interfaces.
The SBOM listing the real-time operating system, communication stack and two open-source libraries with their versions and licences.
Release notes with new functions, fixed defects, and three known open issues of low severity, each with effect, workaround and target fix date.

Step 4 – Review internally and declare

Software quality assurance reviews the package against the checklist and finds one inconsistency: the release notes list calibration C-16, while the test reports used C-17. The release manager confirms C-17 is correct and the notes are fixed. Only then does Northvale's head of software quality, the authorised signatory, sign the supplier declaration and submit the package through the carmaker's portal.

Step 5 – Customer review and decision

The carmaker's software quality engineer passes the test results to the steering engineers, who ask for evidence on one corner case: behaviour at low battery voltage during parking manoeuvres. Northvale supplies the relevant hardware-in-the-loop logs, which show correct degradation. Because the trailer-mode feature is deferred by agreement, and the three open issues are low severity with fix dates before the second production wave, the carmaker grants approval for start of production and records the open issues for follow-up in the next release.

Step 6 – A change arrives

Six months later, field data shows a rare false warning when the steering column is adjusted at very low temperature. Northvale's engineers propose a change to a filter parameter in the calibration data and a two-line code fix. The change process kicks in:

The change is logged and an impact analysis is performed. The affected function is the warning logic, which is linked to a safety requirement, so the functional safety analysis is reviewed and confirmed still valid with an updated argument.
Under the carmaker's CSRs, a safety-relevant change requires re-approval, so Northvale sends a change notification before implementing it in production software.
The carmaker asks for a focused package: change description, impact analysis, updated traceability for the affected requirements, targeted tests including cold-chamber tests, and full regression results.
The new release, application software 4.0.1 with calibration C-18, gets new hashes and a new customer software part number. Release notes explain exactly what changed relative to 4.0.0.
The carmaker approves 4.0.1. Version 4.0.0 is marked superseded for new production, and the carmaker plans a service update for vehicles already in the field through its own software update management system.

What the example shows

Identification made approval precise; existing pipeline evidence made the package cheap to assemble; honesty about open issues made the decision easier; and a defined change process meant the low-temperature fix was approved in days instead of becoming a debate about what "approved software" means. That is the value CQI-34 aims to deliver across the industry.

Lesson 7 – Relationship to other standards and frameworks

CQI-34 sits in a crowded neighbourhood. Each neighbour answers a different question, and understanding the differences prevents both duplication and gaps.

Standard or framework	Main question it answers	Relationship to CQI-34
PPAP (AIAG, 4th edition)	Is this production part, made by this process, approved by the customer?	The model for SwAAP. PPAP approves the physical part; SwAAP applies the same logic to software in or beside it.
Automotive SPICE (VDA QMC)	How capable is the supplier's system and software development process?	Assesses process capability per project. Its results are typical evidence of development quality in a software approval, but an assessment is not a release approval.
ISO 26262 (functional safety)	Is the risk from malfunctioning electrical and electronic systems acceptably low?	Produces safety work products and a safety case. A software approval references them for safety-relevant releases; it does not replace them.
ISO/SAE 21434 (cybersecurity engineering)	Are cybersecurity risks managed across the vehicle lifecycle?	Produces cybersecurity work products; relevant evidence for releases with security-relevant functions or interfaces.
UN Regulation No. 156 and ISO 24089	Does the vehicle manufacturer manage software updates in a controlled way for type approval?	R156 places obligations on the vehicle manufacturer; ISO 24089 describes software update engineering. Supplier approvals and change notices feed the manufacturer's update management.
IATF 16949	Does the organisation run an automotive quality management system?	Requires software quality assurance and a development capability self-assessment for internally developed embedded software; SwAAP is one way to put that into practice at release level.

Figure 5 – Process assessment, safety and security evidence feed the CQI-34 approval, whose identified releases feed the vehicle manufacturer's update management.

Approval versus capability

The most common confusion is between Automotive SPICE and software approval. An Automotive SPICE assessment rates how well defined processes are performed on a project, on capability levels. It says nothing directly about whether version 4.0.1 is ready for production. A software approval says that a specific release is fit for its intended use, and process capability evidence is one input to that judgement. A team with high capability ratings can still deliver a release with a serious defect; a team with modest ratings may still deliver a well-tested release, though with less confidence that the next one will be.

Approval versus safety and security cases

ISO 26262 and ISO/SAE 21434 require specific engineering activities and arguments. Their outputs are large bodies of work with their own reviews and assessments. A software approval should reference these outputs and confirm they are valid for the exact release, not copy them. If a change invalidates part of the safety or security argument, the approval process is where that should be caught.

Hardware PPAP and software approval together

For an ECU, both processes apply: the hardware and its manufacturing process go through PPAP, and the software goes through SwAAP. They must be coordinated, because the delivered product is the combination. A change to the flashing process at the end of the production line, for example, may affect both. Many organisations run one combined approval calendar so that hardware and software milestones line up.

Common pitfalls and best practices

Pitfalls

Treating approval as paperwork at the end. Teams that build the package in the last week before start of production find gaps they cannot close in time and are tempted to submit unsupported claims.
Weak software identification. Version strings that are not tied to hashes, or calibrations that are not part of the identified release, make it impossible to know what was approved.
Testing a different build from the one submitted. If test results come from a build that differs from the delivered binary in compiler, options or data, the evidence does not support the approval.
Silent changes. Updating a library, compiler or calibration "because it is only a small fix" without notification undermines the whole approval and can create field problems that are hard to trace.
Hiding open issues. Customers usually find them, and then question the reliability of every other statement in the package.
Ignoring sub-tier software. Approving your own code while accepting third-party and open-source components without identification or evidence leaves a large gap.
Assuming CQI-34 overrides customer rules. Each carmaker's requirements still apply and may set different forms, depths or timings.

Best practices

Design the pipeline to produce evidence. Let every baseline automatically generate build records, hashes, test results and analysis reports linked to its version.
Make builds reproducible. Freeze toolchains and dependencies per baseline so that any approved release can be rebuilt exactly.
Agree change classes early. Settle with each customer, before start of production, which changes need notification only and which need re-approval.
Keep one package template. Structure all submissions the same way, aligned with CQI-34, and adapt only the depth per customer.
Disclose open issues with plans. List them with severity, effect, workaround and closure date; this enables interim approval when time is short.
Reference, do not duplicate. Point to safety, security and assessment work products and confirm their validity for the release instead of copying them.
Flow requirements down. Apply the same approval logic to your own software suppliers, including identification and SBOMs.
Audit with real units. Periodically compare the software in production units with the approved release list.

Summary and key takeaways

CQI-34, the Software Assurance Approval Process (SwAAP), is AIAG's 1st-edition manual for a common, structured way to approve automotive software and manage its changes across the supply chain.
It was written because software approval practices varied widely between carmakers, creating cost for suppliers and risk for everyone.
It is modelled on PPAP: identify the item precisely, collect objective evidence, declare and approve formally, and control every later change.
It applies to software delivered on its own or as part of a larger system, including updates to software already in production.
Exact software identification and reproducible baselines are the foundation; without them, approval has nothing to attach to.
Approval is a customer decision on a specific release, with approved, interim and rejected outcomes in the PPAP model; there is no organisational CQI-34 certificate.
Change management, with impact analysis, notification and regression testing, is where most of the long-term value lies.
CQI-34 complements, and draws evidence from, Automotive SPICE, ISO 26262, ISO/SAE 21434, UN Regulation No. 156 and IATF 16949 rather than replacing them.

Reflection questions

Pick a piece of software your organisation delivers or receives. How is it identified today, and could you prove which exact binary is in a given unit and rebuild it from your archive?
List the evidence your current pipeline already produces for each release. Which of the approval building blocks would be easy to fill, and where are the biggest gaps?
Draft three change classes for a software product you know, with one example change in each class and the re-approval depth you would propose to the customer.
Think of a time when a "small" software or toolchain change caused an unexpected problem. How would a SwAAP-style change process have caught it earlier?
Your customer asks whether your Automotive SPICE assessment result means your next release can skip approval. How would you explain the difference between process capability and release approval?