Automotive SPICE® – Comprehensive Process Notes (Pages 28–99)

Lifecycle Models vs. PRM / PAM

  • Lifecycle model = HOW layer (specific sequences, tool-chains, work-instructions, artefacts)
    • Example: V-Model for development, Scrum board for task tracking.
  • PRM (Process Reference Model) / PAM (Process Assessment Model) = WHAT layer
    • Abstracts totally from any HOW implementation.
    • Automotive SPICE® adopts ISO/IEC 33004 principles.
    • Assessor maps evidence from an organisation’s HOW layer to assessment indicators in the PAM.
    • Process MAN.3 BP2 explicitly demands “Define project lifecycle.”
  • Assessment workflow (Fig. 5)
    • ① Read “defined HOW” (process descriptions, tool settings, templates, workflows).
    • ② Perform interviews & inspect repositories (actual doing).
    • ③ Map gathered facts to Automotive SPICE indicators.
    • ④ Determine capability profile (rating).
  • PRM / PAM purposely
    • do NOT prescribe order of processes or base practices.
    • do NOT prescribe work-product structure/blueprints (e.g., SYS.2 ≠ one big System-Requirement spec).
    • do NOT represent a product element hierarchy.

Automotive SPICE® Process Table Template (Table 21)

  • Left red bar = reference model section; green = Base Practices; blue = Output Information Items.
  • Each process table contains:
    • Process ID & Name (colour-coded by group)
    • Purpose statement + Outcomes
    • Base Practices list (activities to fulfil purpose/outcomes)
    • Output Information Items list (artefacts / evidence)
    • Header recap showing BP ↔ Outcome relationships.
  • Refer to Annex B for detailed Info-Item characteristics.

Acquisition (ACQ) – ACQ.4 Supplier Monitoring

  • Purpose: Track/assess supplier performance vs. commitments.
  • Outcomes
    1. Joint customer–supplier activities performed.
    2. Regular exchange of agreed information.
    3. Supplier performance monitored.
    4. Needed agreement changes negotiated & documented.
  • Base Practices
    • BP1 Agree/maintain joint activities, interfaces & info exchange.
    • BP2 Execute information exchange via defined interfaces.
    • BP3 Review dev work-products together; track measures (⇢ SUP.9).
    • BP4 Review supplier progress (schedule, quality, cost); mitigate risks (⇢ MAN.5).
    • BP5 Act to correct deviations & update agreements.
  • Key Output Items: 02-01 Commitment, 13-52 Communication evidence, 13-14 Progress status, 14-02 Corrective action, etc.

Supply (SPL) – SPL.2 Product Release

  • Purpose: Control product release to intended customer.
  • Outcomes: Contents identified, package built from configured items, docs produced, approval gained, delivery executed.
  • Base Practices
    • BP1 Define release functionality & criteria (incl. HW, SW, parameter files).
    • BP2 Define release package & supporting tools/docs.
    • BP3 Ensure unique release identification (classification & numbering).
    • BP4 Build release from items under CM control (⇢ SUP.8).
    • BP5 Ensure approval before delivery.
    • BP6 Provide release note (incl. legal aspects, linked to VAL.1).
    • BP7 Communicate support type/level/duration.
    • BP8 Deliver package to customer (internal or external).
  • Output Items: Release note, Release package, Delivery evidence, Release approval, Release criteria.

System Engineering (SYS)

SYS.1 Requirements Elicitation

  • Purpose: Gather, analyse, track evolving stakeholder needs.
  • Outcomes: Communication established; requirements defined & agreed; change impact analysed; status visible.
  • BPs: BP1 Obtain expectations; BP2 Agree; BP3 Analyse changes (⇢ SUP.10); BP4 Communicate status.
  • Outputs: Requirements, Analysis Results, Communication Evidence.

SYS.2 System Requirements Analysis

  • Purpose: Produce structured, analysed, traceable system-requirements.
  • Outcomes: Specified; structured/prioritised; analysed; context impact analysed; traceability to stakeholder reqs; communicated.
  • BPs: Specify, Structure, Analyse, Context Impact, Consistency & Traceability, Communicate.
  • Notes: Use ISO/IEEE 29148 characteristics; prioritisation links to SPL.2.

SYS.3 System Architectural Design

  • Purpose: Design & analyse system architecture (static & dynamic).
  • Outcomes: Architecture defined; analysed & special characteristics derived; traceability to system reqs; communicated.
  • BPs: Specify static, Specify dynamic, Analyse (FMEA, simulation, prototypes), Traceability, Communicate.

SYS.4 System Integration & Integration Verification

  • Purpose: Integrate system elements & verify against architecture.
  • Outcomes: Verification measures specified; integration performed; measure selection logged; verification executed & recorded; traceability; summary communicated.
  • BPs: Specify measures, Select, Integrate & Verify, Trace, Summarise.

SYS.5 System Verification

  • Purpose: Verify integrated system vs. system requirements.
  • Outcomes & BPs mirror SYS.4 but at system vs. architecture level.

Software Engineering (SWE)

SWE.1 Software Requirements Analysis

  • Purpose: Structured, analysed SW reqs consistent with system reqs & architecture.
  • Outcomes: Specified, structured, analysed, operating-environment impact, traceability to SYS reqs & architecture, communicated.
  • BPs mirror SYS.2 with HW/SW-interface note.

SWE.2 Software Architectural Design

  • Purpose: Create analysed SW architecture (static & dynamic).
  • Outcomes: Architecture designed; analysed; traceability; communicated.
  • Highlights: Concurrency aspects, resource consumption analysis.

SWE.3 Software Detailed Design & Unit Construction

  • Purpose: Produce detailed design & construct units matching architecture.
  • Outcomes: Detailed design; units produced; multi-level traceability (architecture ↔ design ↔ code ↔ requirements); communicate.
  • BPs: Static aspects (value ranges, units), Dynamic aspects, Develop units (coding principles like single entry/exit), Trace, Communicate.

SWE.4 Software Unit Verification

  • Purpose: Verify software units vs. detailed design.
  • Outcomes: Measures specified & selected; units verified; traceability; results summarised.
  • Measures include static analysis, code review, unit tests.

SWE.5 Software Component Verification & Integration Verification

  • Purpose: Verify components vs. architecture and integrated SW vs. design.
  • Outcomes: Integration verification measures; component verification measures; integration executed; verify components + integrated software; traceability; communicate.

SWE.6 Software Verification

  • Purpose: Verify integrated software vs. software requirements.
  • Outcomes match SYS.5 pattern (specify ⇢ select ⇢ verify ⇢ trace ⇢ summarise).

Validation (VAL) – VAL.1

  • Purpose: Provide evidence product satisfies intended use in operational environment.
  • Outcomes: Validation measures selected; validation executed & recorded; traceability to stakeholder reqs; results communicated.
  • Notes: Stakeholder needs can be less formal; iterative increments common; may cover homologation/legal approval.

Machine Learning Engineering (MLE)

MLE.1 ML Requirements Analysis

  • Purpose: Refine ML-related SW reqs into ML reqs incl. data.
  • Outcomes: ML reqs specified/structured/analysed; operating-environment impact; traceability to SW reqs & architecture; communicated.
  • Data requirements (characteristics & distributions) produced.

MLE.2 ML Architecture

  • Purpose: Develop & evaluate ML architecture supporting training & deployment.
  • Outcomes: Architecture, hyperparameter ranges, evaluation done; interfaces & resource objectives defined; traceability; communicated.
  • Criteria can include trustworthiness, explainability.

MLE.3 ML Training

  • Purpose: Optimise ML model to meet ML reqs.
  • Outcomes: Training/validation approach; dataset created; model & hyperparams optimised; dataset traceability; results communicated.
  • Training approach covers dropout, tuning, env. parity.

MLE.4 ML Model Testing

  • Purpose: Ensure trained & deployed models comply with ML reqs.
  • Outcomes: Test approach & dataset; trained model tested; deployed model derived & tested; multi-level traceability; communicate.
  • Concepts: Test datum, data characteristics, scenarios with distributions.

Hardware Engineering (HWE)

HWE.1 Hardware Requirements Analysis

  • Purpose: Structured HW reqs consistent with system reqs & architecture.
  • Outcomes & BPs analogous to SWE.1 with notes on parts markets, HSI, etc.

HWE.2 Hardware Design

  • Purpose: Produce architecture + detailed design suitable for manufacturing & produce production data.
  • Outcomes: Architecture & detailed design, analysis & special characteristics, traceability, production data & test info derived, communicated.
  • BPs: Specify architecture (rationale), Detailed design (schematics, BOM, layout), Dynamic aspects, Analyse, Trace, Communicate.

HWE.3 Verification against Hardware Design

  • Purpose: Verify production-data-compliant HW vs. design.
  • Outcomes: Measures specified & selected; compliant samples ensured; verification executed; traceability; results summarised.

HWE.4 Verification against Hardware Requirements

  • Purpose: Verify complete hardware vs. hardware requirements.
  • Pattern similar to HWE.3 but traceability links to requirements.

Supporting Processes (SUP)

SUP.1 Quality Assurance

  • Purpose: Provide independent, objective assurance of product & process quality.
  • Outcomes: Independence; quality criteria; conformance verification; non-conformances tracked & escalated; mgmt resolves.
  • BPs: Ensure independence, Define criteria, Assure work products & processes, Report, Resolve, Escalate.

SUP.8 Configuration Management

  • Purpose: Establish & maintain integrity of config items and baselines.
  • Outcomes: CI selection criteria, CI properties, CM system, Modification control, Baselining, Status reporting, Completeness, Backup/Recovery.
  • BPs: Identify CIs, Define properties, Establish CM, Control changes, Baseline, Communicate status, Ensure consistency, Verify backups.

SUP.9 Problem Resolution Management

  • Purpose: Ensure problems identified, analysed, and resolved.
  • Outcomes: Problems recorded/classified; analysis; resolution initiated; tracked; status reported.
  • BPs: Record, Analyse cause/impact, Authorise urgent action, Alerts, Initiate resolution, Track to close, Report trends.

SUP.10 Change Request Management

  • Purpose: Record, analyse, track, approve, implement change requests.
  • Outcomes: Requests recorded; analysed; approved; traceability; implementation confirmed; tracked to closure.
  • BPs: Identify, Analyse, Approve, Traceability, Confirm implementation, Track status.

SUP.11 Machine Learning Data Management

  • Purpose: Align ML data with requirements, assure integrity/quality, and provide data.
  • Outcomes: ML data mgmt system; quality approach; data processed; data quality verified; data communicated.
  • BPs: Establish system, Develop quality approach, Collect data, Process, Assure quality, Communicate.

Management Processes (MAN)

MAN.3 Project Management

  • Purpose: Identify & control activities/resources for project.
  • Outcomes: Scope, Feasibility, Estimates, Interfaces, Plans, Progress monitoring, Adjustments.
  • Key BPs: Define scope & lifecycle, Feasibility analysis, Work packages & estimates, Skills, Interfaces/commitments, Schedule, Consistency, Progress reviews.

MAN.5 Risk Management

  • Purpose: Identify, analyse, treat & monitor process/product risks.
  • Outcomes: Risk sources identified; undesirable events; risks analysed/prioritised; measures applied & assessed; treatment executed.
  • BPs: Identify sources, Identify events, Determine risks (probability & severity), Define options, Perform treatments, Monitor, Corrective action.

MAN.6 Measurement

  • Purpose: Collect & analyse data to support process management.
  • Outcomes: Info needs; metrics set; activities executed; data analysed; results used.
  • BPs: Identify info needs, Specify metrics, Collect/store, Analyse, Communicate, Use for decisions.

Process Improvement (PIM) – PIM.3

  • Purpose: Continually improve effectiveness/efficiency of organisation’s processes.
  • Outcomes: Commitment; issues/opportunities identified; current status analysed; goals set & changes implemented; effects monitored; knowledge shared.
  • BPs: Establish commitment, Identify measures, Set goals, Prioritise, Define measures, Implement, Confirm improvement, Communicate.

Reuse (REU) – REU.2 Management of Products for Reuse

  • Purpose: Ensure reused work products analysed, verified, approved for target context.
  • Outcomes: Selection criteria; portability analysis; limitations defined; products verified; provided; communication with provider.
  • BPs: Select, Analyse reuse capability, Define limitations, Ensure qualification, Provide, Communicate effectiveness.

Process Capability Levels & Attributes (Intro to Chapter 5)

  • Level 0 Incomplete: Process not implemented or fails to achieve purpose (no generic practices).
  • For each higher level, template identical to Table 22:
    • Attribute ID & Name, Scope statement, Achievements.
    • Generic Practices (activities) & Output Information Items mapped to achievements.
    • Indicators used in measurement framework to judge capability.