An automotive supplier that wants to develop electronic systems for a major OEM quickly discovers that technical capability is not enough. Before the OEM will commit a program, it wants evidence that the supplier develops software and systems through a disciplined, repeatable process, not through the talent of a few engineers who might leave. That evidence is an Automotive SPICE assessment, and for many suppliers the ASPICE rating is as much a gate to winning business as any technical qualification. ASPICE, Automotive Software Process Improvement and Capability dEtermination, is a framework for assessing the maturity of the processes an organization uses to develop automotive systems and software. It sits beside ISO 26262 rather than under it, and confusing the two, or investing in one while neglecting the other, is a recurring and expensive mistake. The framework descends from the broader ISO/IEC 15504 and now ISO/IEC 33000 lineage of process assessment, tailored by the automotive industry into a shared yardstick that OEMs and their suppliers can both point at, which is precisely why an ASPICE rating carries commercial weight rather than merely internal significance: it is a common language for capability that a customer trusts because it is assessed the same way across the industry.
The distinction between what ASPICE and ISO 26262 each assess is the foundation everything else rests on. ISO 26262 is about functional safety: given a system whose failure could cause harm, it defines the safety objectives, the ASIL that quantifies how much rigor a hazard demands, and the safety activities that must be performed to control the risk. ASPICE is about process capability: independent of whether a system is safety-critical, it asks whether the organization develops it through a defined, managed, and improving process. A supplier can build a functionally safe system through a chaotic process, and can run a beautifully disciplined process that produces an unsafe design. The OEM wants neither failure mode, which is why serious programs demand evidence against both frameworks, and why the two are best understood as orthogonal axes rather than as a standard and its subset.
ASPICE describes development through a set of processes arranged in a way any systems engineer will recognize immediately, because it is the V-model rendered as a process reference model. On the left descending arm sit the engineering processes of definition and design: system requirements analysis, system architectural design, software requirements analysis, software architectural design, and software detailed design and unit construction. On the right ascending arm sit the corresponding integration and verification processes: software unit verification, software integration and integration test, software qualification test, system integration and integration test, and system qualification test. The symmetry is the point. Every definition process on the left has a verifying counterpart on the right, and the framework expects the traceability that connects them, from system requirement down to software unit and back up through the tests that prove each level, to be real and demonstrable.
What makes ASPICE demanding, and what surprises organizations approaching their first assessment, is that it evaluates capability on two dimensions at once. The first dimension is the processes themselves, whether the organization performs system requirements analysis, software architectural design, and the rest at all. The second is the capability level at which each process is performed, and this is where the framework has teeth. A process at Level 1 is merely performed, achieving its purpose in some fashion. A process at Level 2 is managed: it is planned, monitored, and its work products are controlled and reviewed. A process at Level 3 is established: it follows a defined organizational standard process, tailored appropriately, rather than being reinvented by each project. Most OEM programs demand Level 2 across the core processes and Level 3 for the most critical, and the leap from performed to managed to established is precisely the leap from talented individuals to a dependable organization. The higher levels above Level 3, predictable and innovating, extend the model into quantitative process control and continuous improvement, but the commercially decisive threshold for most suppliers is the climb from Level 1 to Level 2 and then to Level 3, because that is where an organization stops depending on who happens to be assigned and starts depending on a process that any competent team can execute repeatably. An OEM committing a multi-year platform is buying that repeatability as much as it is buying the technical result.
The capability levels are assessed through process attributes and their supporting practices, and the flavor of the assessment is worth understanding because it explains what actually gets scrutinized. To reach Level 2, a process must satisfy attributes for performance management and work product management: there must be evidence that the work was planned and tracked, that responsibilities were assigned, that the outputs were placed under configuration control and reviewed against defined criteria. To reach Level 3, there must be evidence that a standard process was defined at the organizational level and genuinely deployed on the project. Assessors do not accept assertions; they ask for the work products, the plans, the review records, the traceability, the change history, and they rate each attribute on how fully the evidence demonstrates it. An assessment is therefore only as good as the evidence a program can produce, which turns the entire exercise into a question of whether the connective tissue of the development effort actually exists in a form someone can inspect.
The engineering processes on the V are not the whole framework, and the supporting and management processes that surround them are where many assessments quietly lose points. Alongside the engineering group, ASPICE covers management processes such as project management, and supporting processes such as configuration management, change request management, problem resolution management, and quality assurance. These are not decoration; they are the processes that make the engineering repeatable, and an assessment that finds excellent requirements analysis sitting on top of undisciplined change management or absent problem resolution will not award the capability level the engineering alone might suggest. Configuration management and change request management in particular are assessed directly, because the framework understands that traceability and consistency cannot survive without them, and a supplier that cannot show a controlled way of raising, dispositioning, and closing changes has revealed that its impressive-looking work products are not actually under control. The management and supporting processes are the connective tissue that turns a set of good engineering activities into a dependable organization, which is precisely what the assessment is trying to measure.
That evidence problem is where most of the pain concentrates, and it is where the two most heavily weighted concerns of ASPICE, bidirectional traceability and consistency, become the deciding factors in a rating. ASPICE does not merely want a chain of requirements to design to test; it wants that chain to be bidirectional, so that every requirement traces down to what implements and verifies it and every design element and test traces back up to the requirement that justifies it. And it wants consistency, evidence that the linked artifacts actually agree with one another, that a test verifies what its requirement demands rather than merely citing it. An assessment routinely finds that an organization has requirements, has designs, has tests, and has a traceability matrix, but that the matrix was assembled by hand near the assessment date and is riddled with links that point at stale versions or verify nothing in particular. That is the difference between a Level 1 and a Level 2 process laid bare.
The reason this so reliably goes wrong is the same reason it goes wrong everywhere in systems engineering: when requirements, architecture, and tests live in separate tools maintained by separate teams, the traceability between them is a secondary artifact that someone maintains manually, and manual maintenance decays the moment the program gets busy. The links rot silently. A requirement changes and the design that implemented it is not flagged. A test is updated and its link to the requirement it once verified now points at wording that no longer exists. By assessment time the organization faces a choice between a frantic reconciliation effort and an honest admission that its traceability is not trustworthy, and neither produces the capability rating the business depends on. The process was probably sound; the evidence of the process was allowed to decay, and ASPICE assesses the evidence.
This is exactly the layer methodology-native tooling is built to hold, and it is why the ASPICE and the ISO 26262 evidence should live in the same connected environment rather than in parallel document stacks. Hitt Hosting SE keeps system and software requirements, architecture, and the verification activities at each level of the V as first-class, linked elements, so the bidirectional traceability ASPICE demands is live data generated by the work rather than a matrix reconstructed before an assessment. Because a change to any element flags the downstream and upstream artifacts that depended on it, the consistency between requirement, design, and test is maintained continuously instead of reconciled under deadline, and the ASIL attributes ISO 26262 assigns ride on the same requirements the process framework is assessing. The evidence an assessor asks to see, the traceability, the work-product control, the review and change history, becomes a view of the live program, so an organization that genuinely runs a disciplined process can prove it, which is the entire point of the assessment.