Lesson 8 of 16 · Automotive SPICE, the vital 20 %
How assessors rate
The PAM says what to rate. The VDA Guidelines say how: what gets sampled, which evidence is trusted, how instances combine, and why a rating without a weakness statement is worthless.
A project's tailoring decisions with rationale, signed off by quality. PA 3.1 or PA 3.2?
CI shows the build broke after a compiler update. Which process records and resolves it?
"Test specifications live in the repo under /verification, with status Draft or Released in the file header." Which GP?
1. Everything starts from the scope
Before anything is rated, the assessment input fixes the purpose and the scope: the boundaries of the organisational unit, the processes, the target capability level for each process, and the process context, such as which releases, which components and whether open source is included. "Each process attribute rating shall strictly remain within the boundaries of the process context"[Guidelines §1.2–1.3.4, pp. 27–32].
2. Evidence: sampled, plausible, and read
- Sampling. The assessor picks stakeholder requirements covering the most important functions; new, adapted, reused and platform content; safety- and security-relevant content; and every coding and modelling approach used, and follows them so the samples "mark a clear path through the engineering lifecycle". The same goes for changes and problems. The organisation may propose samples, but the assessor decides[§1.4.3.1, pp. 37–38].
- Plausibility. Every work product is checked for its change history. One "initially generated shortly before the assessment … should not be considered", unless there is a plausible reason. A weekly schedule should show roughly weekly versions[§1.4.3.2, p. 38].
- Content. "Automotive SPICE must not be mistaken for a checklist." Samples are read for the right content, and what counts as appropriate depends on team size, product complexity and timeline[§1.4.3.3, p. 39].
It follows that the strongest evidence is the kind that piles up as a side effect of the work: Git history, tool timestamps and review records show the process was lived, not written up for the visit. (This is an inference from the plausibility rules, not a quote.)
3. Each process is rated on its own
Only a process's own weaknesses may pull it down. The single exception is BPs that explicitly refer to another process, which in practice means the consistency and traceability BPs, "the only 'connection points' between processes". The rule is [GEN.RL.1]: "A rating of PA 1.1 of P or N for a process X shall not be used to downrate PA 1.1 of the process Y"[§1.4.2, pp. 36–37].
4. Instances, then aggregation
If a process runs differently in different places (model-based vs hand-coded, platform vs project code, two sites), each process instance is rated separately[§1.3.5, pp. 32–34], and the results are then aggregated. The recommended method[§1.4.4, pp. 39–41]:
- Convert: N = 0, P = 1, L = 2, F = 3.
- Take the arithmetic mean, or a weighted mean if the report explains the weights (headcount, revenue, criticality…).
- Round to the nearest integer, where exactly halfway rounds up, and convert back.
| Instances | Mean | Aggregate |
|---|---|---|
| L, L, F | 7 / 3 = 2.33 | L |
| P, L, F | 6 / 3 = 2.00 | L |
| N, P, F | 4 / 3 = 1.33 | P |
The Guidelines' own worked examples, p. 40.
5. Rating rules and weakness statements
The Guidelines contain hundreds of rating rules, such as [TAC.RL.1] or [AGE.RL.2], which reduce variation between assessors. They come in three patterns: "shall not be downrated", "shall be downrated" (at least one step), and "shall not be rated higher than". There is no "rating rule algebra": three rules that each call for a downrate don't automatically mean three steps. An assessor who departs from a rule must document a compelling justification[§1.5, pp. 42–44].
The rule that governs all the others: any downrating, and any weakness found within an F rating, needs "a comprehensive explanation of the associated process risk, substantiated by traceable objective evidence". Citing only rules "renders the entire assessment report invalid"[§1.5.4.2, p. 44]. A good weakness statement names what is missing, where the evidence shows it, and what can go wrong because of it.
Practice
A. Aggregate these instances
SWE.3 PA 1.1: model-based instance L, hand-coded instance F.
SUP.8 PA 1.1 at three sites: N, N, F.
Weighted by headcount 70 % / 20 % / 10 %: P, L, F.
B. What would the assessor do?
Seat-Heat's risk register, for a project running for two years, was created in Confluence nine days before the assessment and has one version.
A new sub-project started twelve days before the assessment. Its risk register was created on day three and has two versions since.
SUP.9 is rated P. Should SUP.10's PA 1.1 be lowered because of it?
Which is an acceptable weakness statement for MAN.3.BP5?
(a) "Estimation is immature." · (b) "Remaining effort for the features planned for releases 3.0 and 3.1 is not estimated (Jira epics SH-40…SH-52 have no estimates; confirmed in the PM interview), so the team cannot tell whether the release dates are achievable." · (c) "Downrated per AGE.RL.2."
C. From memory
Describe the aggregation method, including the rounding rule.
Rate each instance. Convert N/P/L/F to 0/1/2/3, take the mean (or an explained weighted mean), round to the nearest integer with exact halves rounding up, then convert back.
What three things does a sound weakness statement contain?
What is missing or weak, the traceable objective evidence showing it (which work products, which interview), and the process risk it creates.
Your win: you know the assessor's procedure well enough to predict their moves: what they will sample, which work products they will distrust, how instances combine, and what a defensible finding looks like. Last: put it all together on Seat-Heat.
To keep it: import this lesson's Anki deck (how).
Read next
VDA Guidelines Part 1, pp. 26–44. It is the highest-yield twenty pages in either document. Part 2 (from p. 275) covers running an assessment end to end, if you ever sit on one.
Unsure how a rule or the aggregation would apply to your own project? Ask your teacher in the chat. If you get the chance to talk to a working assessor, ask how they handle plausibility checks on tool-based evidence; Gate4SPICE events are one place to do that.