Glossary

The model

PRM (process reference model): the set of processes, each with a purpose and outcomes. Avoid: "the standard", "the model".

PAM (process assessment model): the PRM plus the indicators an assessor uses to rate it. Avoid: "the checklist", "the model".

VDA Guidelines: the VDA's companion to the PAM: how to interpret it, and the rating rules assessors apply. Always plural. Avoid: "the Guideline".

Process: in the PAM, a distinct set of related goals with a purpose and outcomes; not a workflow and not a lifecycle phase. Avoid: "phase", "workflow".

WHAT / HOW / DOING: the goals the PAM states / the methods and tools an organisation chooses / the actual performance on real work. Assessors rate the WHAT, evidenced by the DOING.

Purpose: the one-sentence reason a process exists.

Outcome: an observable result of achieving a process's purpose. PA 1.1 rates outcomes.

Process dimension / capability dimension: the two axes of a rating: which processes are assessed, and how capable each one is.

Recommended VDA Scope: the VDA's recommended process selection. It is the base (MAN.3, SUP.1, SUP.8, SUP.9, SUP.10) plus at least one plug-in, with flex processes added as the purpose needs. Avoid: "the eleven processes", "ASPICE scope".

Plug-in: one domain's engineering processes, added to the base: SYS.2–SYS.5, SWE.1–SWE.6, HWE.1–HWE.4, or MLE.1–MLE.4 with SUP.11. The Guidelines count system as one domain among four; PAM Annex C.1 keeps the system V above the domains.

Flex process: a process outside the base and the plug-ins of the recommended VDA Scope, added when the assessment purpose needs it. Examples are SYS.1, VAL.1, SPL.2 and MAN.5. Avoid: "optional process", "outside the VDA Scope".

Indicators

Indicator: something an assessor looks for when rating: a practice or an information item.

Base practice (BP): a process-specific activity indicator for level 1.

Generic practice (GP): an activity indicator for a process attribute, applied identically to every process.

Information item (II): what an assessor looks for, described by its characteristics in PAM Annex B and numbered (13-13, 17-57 and so on). It is not a document anyone must write. Avoid: "required document", "record".

Work product: what the organisation actually produced, including tool content such as Jira tickets, commits and CI results. Avoid: "document", "deliverable".

Record: a work product held in a tool, such as a ticket, a review approval or a Markdown file with front-matter. It is never a synonym for information item.

Objective evidence: work products and testimony, the only two sources a rating may rest on.

Testimony: what the people doing the work say in interviews: the second source of objective evidence. Avoid: "interview notes".

The capability dimension

Capability level: 0 Incomplete, 1 Performed, 2 Managed, 3 Established, 4 Predictable or 5 Innovating. Derived from PA ratings, for one process. Avoid: "maturity level", which rates organisations in other models.

Capability profile: the result of an assessment: one capability level per assessed process. Avoid: "score", "overall level".

Process attribute (PA): a measurable property of capability. There are nine: PA 1.1, then two per level from 2 to 5.

N / P / L / F: not (≤ 15 %), partially (≤ 50 %), largely (≤ 85 %) and fully (> 85 %) achieved. P and L may be refined to P−/P+ and L−/L+.

Level rule: level n needs its own PAs rated L or F and every lower PA rated F.

Downrate: rate an indicator or attribute lower because of a weakness.

Process performance objective: a target for how one process is performed (GP 2.1.1). It is not a project goal and not a restated outcome.

Process performance strategy: how a process will be performed to meet its objectives (GP 2.1.2). Tool-enforced workflows and CI can be one.

Review evidence (13-19): the information item a review leaves: the object and its version, the reviewers and their roles, the date, the status, the criteria and the non-conformances found.

Status model: the defined states a work product moves through, part of its storage and control (GP 2.2.2).

Standard process: the organisation-wide reference process, with tailoring guidelines (PA 3.1). Avoid: "the standard"; "the handbook" (the company's own word in L07's story, never the course's).

Defined process: a project's tailored instance of the standard process (PA 3.2).

Tailoring guideline: predefined, unambiguous criteria for deriving a defined process from the standard process, naming who tailors and who approves.

Waiver: an approved one-off deviation from the standard process. A recurring waiver for the same deviation is a sign the standard process needs changing.

Competency: what a role requires people to know and be able to do (GP 3.1.2), and the basis for assigning people to roles (GP 3.2.2).

The V and engineering

V-model: a picture of which work products must be consistent and traceable with which. It is not a sequence of phases. Avoid: "V-model phases".

Left leg / right leg: the processes that specify (requirements, architecture, design) and the processes that check what was specified (verification, validation).

Bidirectional traceability: links that can be followed both ways between related items. Avoid: using it to mean "consistent".

Unidirectional traceability: links followed one way only. This is sufficient when a validation measure derives from a legal or homologation requirement (VAL.1.BP4).

Consistency: linked items actually agree in content. Links alone don't prove it.

Connection point: a consistency or traceability BP: the only way a weakness in one process can count against another.

Cluster: a group of requirements traced as one. Cluster-level tracing is not downrated (TAC.RL.1).

System: whatever the team delivers as its product, whether a mechatronic system, an ECU or a chip. SYS processes are not tied to a fixed product level.

System element: a building block of the system architecture, whether logical (a design object) or physical (a sensor, a mechanical part, a software executable).

Stakeholder requirement (SYS.1): an agreed requirement from a stakeholder: the customer's, but also the supplier's own and legal or regulatory ones. System requirements are derived from them. Avoid: "customer requirement", when other stakeholders count too.

System requirement (SYS.2): a functional or non-functional requirement on the system, derived from the stakeholder requirements.

Software requirement (SWE.1): a requirement on the software, derived from the system requirements and architecture, or from stakeholder requirements in software-only development.

Static aspects / dynamic aspects: an architecture's elements, interfaces and relationships / its behaviour and interactions in each mode. An architecture needs at least one view of each. Avoid: "diagrams".

Hardware-software interface (HSI): which pins, signals and timing the software sees. It is defined at system level in SYS.3 and is an input to the software requirements.

Special characteristic: a property of a non-software system element derived in the system architecture (SYS.3.BP3) and communicated to all affected parties.

Software component: what the software architecture (SWE.2) decomposes the software into, down to the lowest-level components.

Software unit: what the detailed design (SWE.3) decomposes a component into, not subdivided further. First a design idea, not a file or a function; under verification it is represented by source code or object files. Avoid: "module" (Seat-Heat's own word in L04's story, never the course's).

Software element: a component or a unit, seen as something that is integrated (SWE.5). Avoid: "element", on its own, for anything else.

Detailed design: what each software unit shall do and how it interacts with other units. It is not a picture of the code.

Coding principles: rules units are developed to (SWE.3.BP3), such as no implicit type conversions, one entry and one exit, and range checks. A level 1 matter.

Verification and validation

Verification measure: any check against a specification: a test, measurement, calculation, simulation, review or analysis. ASPICE 4 says "verification" rather than "testing". Avoid: "test", when any other kind of measure would do.

Verification pattern: the five steps every right-leg process follows: specify measures, select them, perform and record, trace, and summarise and communicate.

Automated verification measure: a measure run by scripts or programs. Its definition must address their correctness, completeness and consistency. Avoid: "test code", as if it were exempt.

Exploratory test: a verification measure, or under VAL.1 a validation measure (Guidelines p. 164), with no specification to trace to. Not downrated for that, but it must trace to its results.

Component verification / integration verification: SWE.5's two halves: each component's behaviour and interfaces, then how the integrated elements work together.

Code coverage: accompanying information on how complete the chosen tests are. Never a verification objective in itself.

Validation (VAL.1): evidence that the end product meets its users' intended-use expectations in its operational target environment. The test is not whether a requirement exists but whether objective measurement settles it (verification) or it takes a judgement of what users need, made by end users or their representatives or approximated, for instance by accident simulations (validation). A simulation checked against a specification is still verification. It does not apply to pure embedded software, an ECU or a drive.

Validation measure: a check against intended use, such as use-case testing under real-life conditions, end-user trials, panel or blind tests, or expert panels.

End product: a product people use directly, with a direct end-user interface. It is the only thing VAL.1 validates.

Support, change and release

Quality assurance (SUP.1): independent, objective assurance that work products and processes meet their criteria, with non-conformances resolved.

Independence: SUP.1's demand that quality assurance is unbiased and free of conflicts of interest: no self-monitoring, and not done by the project's own manager or developers. ASPICE demands it of no other process. Avoid: using it for GEN.RL.1, or for verification.

Non-conformance: a deviation found against defined criteria, by a review or by quality assurance.

Configuration item: a work product, or a group of them, managed as one entity under SUP.8. For AI assistance, the Guidelines' examples include prompts as new configuration items and version control of AI tools, models and their settings.

Baseline: a defined, consistent, read-only set of configuration items at a point in time, serving as input for the affected parties. Avoid: "snapshot", "tag".

Problem (SUP.9): something wrong, to be analysed and tracked to closure.

Change request (SUP.10): a wanted change, analysed, approved before implementation and traced to what it affects. Avoid: "CR" in prose; "bug" or "defect", for a change request.

CCB (change control board): a decision authority that approves change requests (SUP.10.BP3). The PAM gives a CCB as one example mechanism, and the Guidelines call any such authority a CCB for simplicity. It represents all affected disciplines and required stakeholders, with authority to decide, and there may be more than one. Avoid: "approving body"; "approval authority", except when quoting the Guidelines' rules.

Lifecycle: the project's own phases, gates and order (MAN.3.BP2): a HOW. ASPICE defines none. Avoid: "ASPICE phases".

Gate: a decision point in a project's lifecycle, such as "Requirements agreed". A stage-gate model is a lifecycle, and going back through a gate is iteration, not a deviation.

Gate approval: the decision to pass a gate: a lifecycle HOW. A complete, consistent baseline can support one (SUP.8.BP7). Avoid: "release approval".

Release approval (SPL.2.BP5): approval against release criteria before delivery. An assessor looks for it as information item 13-13: the date and the approver's name and role. Avoid: "gate approval", "sign-off".

Release note: what SPL.2 delivers alongside a release to say what it contains (information item 11-03).

Automation and AI

Docs-as-code: keeping requirements, architecture and verification as files in Git, with trace IDs in their front-matter. A HOW.

Structural check / semantic check: an automated check that the trace graph is well-formed / a recorded review that linked items agree in content. Only a semantic check shows consistency. Avoid: "compliance check".

Orphan: a record nothing traces to. A checker flags it, and must accept a recorded justification.

Compliance: an assessor's judgement about a process. No check or tool can establish it.

Coding agent: an AI tool that drafts work products, such as requirements, code and tests, usually as pull requests. Using one is a HOW. Avoid: "agent", for the course's teacher.

Self-monitoring: the producer of a work product checking it. It can support a review, but never counts as quality assurance.

Assessment

Assessment purpose: why the assessment is done, such as supplier evaluation or an improvement baseline. The scope is defined to cover it.

Assessment scope: four things: organisational-unit boundaries, the processes, the target capability level per process, and the process context. The purpose is not part of it.

Sponsor: whoever commissions the assessment and agrees its scope. A process leaves the scope only with the sponsor's approval.

Process context: the factors bounding what is rated, such as releases, components and inclusions.

Process instance: one distinct way a process is performed within the scope. Each is rated separately, then aggregated.

Aggregation: combining instance ratings as N0 P1 L2 F3 by arithmetic mean, or by a weighted mean whose weights are explained in the report. Exactly halfway rounds up.

Plausibility check: an assessor's check that evidence fits the rhythm of the work. A work product created shortly before the assessment, with no plausible reason, is not considered.

Rating rule (RL): a Guidelines directive such as "shall (not) be downrated" or "not higher than", named like SYS.2.RL.5. Avoid: "Guideline rule".

Weakness statement: what is missing, the traceable evidence and the process risk. Required for every downrating, and for any weakness found within an F rating.

Abbreviations and names

ECU (electronic control unit): the embedded controller Seat-Heat's software runs on.

OEM / Tier-1: the vehicle maker / a supplier delivering directly to it.

HIL (hardware-in-the-loop): testing software on the real ECU against a simulated environment.

SIL (software-in-the-loop): running software against a simulated environment with no target hardware. It can support integration verification.

CI (continuous integration): building and checking every change automatically. Never used for configuration items.

RASIC: a matrix saying who is Responsible, Approves, Supports, is Informed or Consulted for each activity (GP 3.1.1).

intacs / Gate4SPICE: the assessor certification body / its regular community events where practising assessors talk.

Sources

PAM 4.1 terminology, pp. 8–11 and chapters 3–5; Guidelines terms and glossary, pp. 16–20.

Course index