Overview
Automotive SPICE (ASPICE) is the mandatory process assessment framework used by every major OEM to evaluate supplier software development capability. Achieving ASPICE Level 2 or 3 is a contractual requirement for most automotive projects.
This course covers all relevant process areas: SWE.1–SWE.6, SYS.1–SYS.5, MAN.3, and SUP processes. You'll understand what assessors look for, how to create compliant work products, and how to prepare for assessments.
With practical templates and real assessment scenarios, you'll be ready to implement ASPICE-compliant processes and support your team through successful assessments.
Course Modules
1
ASPICE Framework & Concepts
ASPICE Overview & HistoryFREE PREVIEW
35 min read
▸ ASPICE origins: derived from ISO/IEC 15504 (SPICE); intacs® Automotive SPICE® PAM (Process Assessment Model) v3.1 published 2017; VDA QMC working group; OEM requirement: BMW, Bosch, Continental, Daimler, VW require Level 2 for suppliers; Tier 1s require Level 3 internally; ASPICE v3.1 + ASPICE for Cybersecurity (2021) + ASPICE for ML (2024)
▸ ASPICE scope and terminology: Process Area (PA) = SWE, SYS, SUP, MAN; Process Dimension: 32 process areas in PRM; Capability Dimension: 6 levels (CL0=Incomplete to CL5=Optimizing); Rating: N (not achieved), P (partially ≥15%), L (largely ≥50%), F (fully ≥85%); PAM (Process Assessment Model) maps practices to work products; assessor: intacs®-certified CPA (Competent Process Assessor)
▸ ASPICE assessment types: formal assessment (external intacs® lead assessor, formal report, binding capability rating per process area); self-assessment (internal, non-binding, improvement-focused); supplier capability assessment (OEM team assesses Tier-1 project capability before SOP); gap analysis (internal pre-assessment); typical scope: SWE.1-SWE.6 + MAN.3 + SUP.1 + SUP.8 + SUP.10 = 10 process areas
▸ ASPICE vs ISO 26262 interaction: ASPICE covers process quality (how you develop); ISO 26262 covers functional safety (what you develop and its safety integrity); combined: ASPICE Level 2 processes ensure consistent SW development; ISO 26262 ASIL classification determines safety requirements; OEM gateway criteria: ASPICE CL2 = prerequisite before ISO 26262 compliance review; many assessors assess both simultaneously (joint ASPICE + FS assessment)
Process Reference Model (PRM)FREE PREVIEW
40 min read
▸ PRM structure: 32 process areas organized in 5 process groups: ACQ (Acquisition, 5 PAs), SPL (Supply, 2 PAs), SYS (System Engineering, 5 PAs), SWE (Software Engineering, 6 PAs), SUP (Supporting, 9 PAs), MAN (Management, 5 PAs); each PA has: Purpose, Outcomes (numbered NN.1, NN.2...), Base Practices (BPs), and Work Products (WPs); ASPICE PAM maps outcomes to Specific Practices (SPs) and Work Product Characteristics
▸ Engineering process hierarchy: SYS.1 (Requirements Elicitation) → SYS.2 (System Requirements Analysis) → SYS.3 (System Architectural Design) → SYS.4 (System Integration & IT) → SYS.5 (System Qualification Testing); SWE.1 → SWE.2 → SWE.3 → SWE.4 → SWE.5 → SWE.6; bidirectional traceability mandatory between all levels; SYS.2 ↔ SWE.1 (system req → SW req), SWE.1 ↔ SWE.3 (SW req → unit design), SWE.4 ↔ SWE.1 (unit test ↔ SW req)
▸ Key work products per process: SWE.1 WP 17-08 (Software Requirements Specification), WP 13-04 (Traceability Record); SWE.2 WP 04-04 (Software Architectural Design), WP 13-04 (Traceability); SWE.4 WP 08-50 (Test Specification), WP 08-52 (Test Results); SUP.8 WP 06-01 (Configuration Management Plan), WP 08-28 (CM record); MAN.3 WP 14-05 (Project Plan); work product types: documents, records, configuration items, plans
▸ PRM vs PAM relationship: PRM defines WHAT (outcomes and purposes at process level - ISO 15504-5); PAM defines HOW to assess (specific practices, work product characteristics, rating indicators); assessors use PAM to judge achievement; PAM rating indicators: direct (document exists, contains required info) vs indirect (interviews, tool outputs); PRM is normative (must comply); PAM is informative (guides assessment method); intacs® PAM v3.1 freely downloadable from VDA QMC website
Capability Levels 0–5
45 min read
▸ Capability Level definitions: CL0 Incomplete (PA outcomes not achieved); CL1 Performed (PA outcomes achieved, informal, undocumented); CL2 Managed (planned, tracked, verified, adjusted - 9 Generic Practices GP 2.1-2.9); CL3 Established (standard process defined, tailored, deployed - GP 3.1-3.2); CL4 Predictable (measured, quantitatively controlled - GP 4.1-4.2); CL5 Optimizing (continuous innovation - GP 5.1-5.2); automotive projects typically target CL2; Tier-1 internal processes target CL3
▸ CL2 Generic Practices in detail: GP 2.1.1 Identify objectives; GP 2.1.2 Plan performance; GP 2.1.3 Monitor performance; GP 2.1.4 Adjust performance; GP 2.2.1 Identify work product requirements; GP 2.2.2 Establish work products; GP 2.2.3 Control work products; GP 2.3.1 Identify interfaces; GP 2.3.2 Monitor interfaces; each GP requires evidence: project plan (GP 2.1.2), review records (GP 2.2.2), CM records (GP 2.2.3)
▸ Process Attribute (PA) ratings: PA 1.1 (Process Performance) → CL1; PA 2.1 (Performance Management) + PA 2.2 (Work Product Management) → CL2; PA 3.1 (Process Definition) + PA 3.2 (Process Deployment) → CL3; rating scale: N (<15%), P (15-50%), L (50-85%), F (>85%); to achieve CL2: PA 1.1=F AND PA 2.1=F AND PA 2.2=F; to achieve CL3: additionally PA 3.1=L AND PA 3.2=L; common OEM requirement: all SWE PAs at CL2=F
▸ Practical CL2 evidence checklist: project plan with milestones and resource allocation (GP 2.1.2); status reports with actual vs planned (GP 2.1.3); change records for plan adjustments (GP 2.1.4); requirements specification reviewed and approved (GP 2.2.2); configuration management records (GP 2.2.3); interface agreement document (GP 2.3.1); review records for all work products (quality criteria); tools: JIRA for tracking, DOORS for requirements, Git for CM; common finding: plan exists but not tracked → fails GP 2.1.3
Assessment Method & Ratings
40 min read
▸ Assessment method: intacs® CPA (Competent Process Assessor) leads; team: 2-4 assessors; duration: 3-5 days for 10 PAs; phases: planning (scope, process instances, schedule) → kick-off → data collection (document review + interviews) → validation → rating consensus → report; process instance: one project feature/component assessed for each PA; multiple instances required for robustness (at least 2)
▸ Rating aggregation: individual practice ratings (N/P/L/F) aggregated per PA; PA 1.1 rating = lowest rating across all Base Practices for that PA; CL2 achieved only if PA 1.1=F AND PA 2.1=F AND PA 2.2=F for ALL process instances; if one instance fails one GP → overall PA rating drops; common: SWE.4 PA 1.1=L (not F) because unit test coverage below threshold → CL1 not achieved → capability gap
▸ Finding categories: strengths (S): practices consistently well-implemented; weaknesses (W): practices partially or not implemented → root cause analysis required; observations (O): process improvements suggested, not mandatory; findings documented in Assessment Report with evidence references; IMP (Improvement) actions: each weakness → IMP item with owner, deadline, KPI; follow-up assessment (Reassessment) verifies IMPs closed; SMART criteria for IMP actions
▸ Assessment output & report: ASPICE Assessment Report sections: scope definition, process instances assessed, rating summary table (rows=PA, columns=CL), findings per PA (Strengths/Weaknesses/Observations), IMP list; rating summary example: SWE.1 CL2=F, SWE.2 CL1=L (gap: architectural design not formally reviewed), SWE.4 CL1=P (gap: no unit test automation); report issued within 10 business days; OEM receives copy; confidential per intacs® assessment guidelines
Base Practices & Generic Practices
35 min read
▸ Base Practices (BPs): process-specific practices for each PA; SWE.1 BPs: SWE.1.BP1 (Elicit SW requirements from system requirements, constraints, architecture); SWE.1.BP2 (Analyze SW requirements for correctness, completeness, consistency); SWE.1.BP3 (Evaluate feasibility); SWE.1.BP4 (Establish consistency between SW reqs and sys architecture); SWE.1.BP5 (Communicate agreed SW requirements); BP achievement evidence: SRS document, review protocol, DOORS traceability links
▸ Generic Practices (GPs) at CL2 - PA 2.1 Performance Management: GP 2.1.1 Identify scope (PA objectives); GP 2.1.2 Plan process performance (project plan with milestones, resources, schedule); GP 2.1.3 Monitor process performance (status reports with actual vs planned KPIs: requirements approved on schedule, review completion rate); GP 2.1.4 Adjust process performance (change request for plan deviation); evidence: project plan + status reports + change records; common weakness: status reports not updated regularly
▸ Generic Practices at CL2 - PA 2.2 Work Product Management: GP 2.2.1 Identify work product requirements (content, format, review criteria per work product type); GP 2.2.2 Establish work products (SRS, Architecture Doc, Test Spec formally created and under CM); GP 2.2.3 Control work products (Git/SVN version control, unique ID per document, status tracking: DRAFT/REVIEWED/APPROVED); evidence: document management system (SharePoint, Polarion) with version history and approval workflow
▸ BP vs GP interaction for assessors: BPs demonstrate PA purpose achievement (CL1 Process Performance); GPs demonstrate managed environment (CL2); assessor checklist: BP evidence → does the SRS exist and contain the required information? (BP quality); GP 2.2.3 evidence → is SRS under version control and formally approved? (GP quality); weakness example: SRS exists (BP1 = L) but not in CM system (GP 2.2.3 = N) → PA 2.2 = N → CL2 not achieved despite good BP scores; lesson: GPs are often the bottleneck, not BPs
Hands-On: Process Capability Scoring
50 min read
▸ Self-assessment workshop setup: select 2 project instances (e.g., engine control feature v1.5 + safety monitor feature v0.9); scope: SWE.1 + SWE.4 + SUP.8; assessor role-play (you=assessor, colleague=project engineer); prepare rating sheet: rows=BPs (SWE.1.BP1..BP5), columns=instances, cells=N/P/L/F; interview guide: open questions "Show me your SW requirements specification" "How do you verify completeness?"
▸ Practice BP rating: SWE.1.BP1 exercise: review provided SRS sample (Engine_SW_Req_v1.5.docx); check: each system requirement traced to ≥1 SW requirement? DOORS link count; SW requirements stated in SMART format? (Shall, measurable, verifiable); feasibility addressed? (implementation notes); if SRS has 80% traceability → BP1 rating = L (50-85% range); rating justification in rating notes: "80 of 100 sysRS linked, 20 missing for new features in scope"
▸ Practice GP rating: SWE.1 PA 2.1 exercise: check project plan (Jira Epic/MS Project); milestones defined? (SRS v1.0 approval date, SW architecture v1.0 date); actual vs planned tracked? (Jira Epic burndown chart, sprint velocity); change records for delays? (JIRA "delay" label with reason); scoring: plan exists + milestones → P; plan + tracking → L; plan + tracking + formal adjustment → F; PA 2.1 = L for this example → CL2 not achieved
▸ Consolidate rating & generate IMP: aggregate BP ratings → PA 1.1 rating; aggregate GP ratings → PA 2.1, PA 2.2; overall CL: SWE.1 CL2=L (gap: GP 2.1.4 not demonstrated → no adjustment records); IMP-SWE1-001: "Implement change request process for project plan deviations; owner: PM; deadline: 2025-03-31; evidence: 3 change requests with approval"; output: ASPICE Self-Assessment Report template filled with: scope, instances, rating table, findings, IMP list; tool: SPICE-ONE or Excel-based assessment template
2
Software Engineering Processes (SWE)
SWE.1 - Software Requirements Analysis
50 min read
▸ SWE.1 purpose & outcomes: elicit, analyze, and establish SW requirements from system requirements; outcomes: SWE.1.O1 (SW requirements defined); SWE.1.O2 (SW requirements analyzed for correctness); SWE.1.O3 (impact of constraints identified); SWE.1.O4 (SW req consistent with sys architecture); SWE.1.O5 (SW req communicated and agreed); work product WP 17-08 (Software Requirements Specification = SRS)
▸ SRS quality criteria (what assessors check): completeness: every system requirement traced to ≥1 SW requirement; unambiguous: "shall" language, no "should/may"; verifiable: every requirement has measurable acceptance criterion; consistent: no contradictions between requirements; traceable: DOORS trace link from SysRS → SwRS; example: SwReq_042 "The EMS shall limit engine speed to 6500 RPM ± 50 RPM"; bad example: "The system should respond quickly" (ambiguous, not verifiable)
▸ Traceability implementation: DOORS module hierarchy: SysRS_Module → SwRS_Module; DOORS link type: "satisfies" (SwRS satisfies SysRS); DOORS traceability report: shows uncovered requirements (no links); coverage target: 100% for ASIL-B+; IBM DOORS XT DXL script to auto-generate coverage report; Polarion: module → link rules; codeBeamer ALM: traceability tree view; common gap: new system requirements added after SRS approved without corresponding SwRS update → gap found in coverage report
▸ SWE.1 review process evidence: review types: peer review (author + 1 reviewer) or inspection (team); review record: document ID, version, reviewers, date, findings list (type: Major/Minor/Observation), disposition (Accept/Reject/Accepted-with-action); reviewer independence: cannot be document author; tool: Crucible, Polarion review workflow, or Excel review record template; typical SWE.1 review findings: missing acceptance criteria (Major), ambiguous "should" language (Minor), missing trace link (Major)
SWE.2 - Software Architectural Design
55 min read
▸ SWE.2 purpose & required work products: develop and document SW architecture; WP 04-04 (SW Architectural Design Document); WP 13-04 (Traceability: SwRS ↔ SW Components); WP 04-06 (SW Interface Specification); assessors check: architecture describes all SW components, their responsibilities, interfaces, interactions, and SW-HW interfaces; AUTOSAR Classic: BSW + MCAL + RTE + SWC architecture diagram
▸ Architecture description elements: component decomposition: ECM SW = App Layer (VehicleSpeed_Ctrl, Fuel_Ctrl, Diag_Mgr) + BSW Layer (Com, Dem, FiM, NvM) + MCAL; interface specification: component name, provided ports, required ports, data elements, data types, trigger conditions; UML component diagram + sequence diagram for key scenarios (engine start sequence); design rationale: why AUTOSAR OS partitioning chosen for freedom from interference (ISO 26262)
▸ Architecture review and traceability: SWE.2.BP4 - architectural design consistency with SW requirements: DOORS trace SwReq_042 → Component "EngineSpeed_Monitor"; complete coverage check: all SwRS requirements allocated to at least 1 component; review record: architecture review with architect + safety engineer + software lead; findings: "Component X has no interface definition" → Major finding → must fix before approval; Enterprise Architect (EA) or Rhapsody for UML architecture documentation
▸ Common SWE.2 assessment weaknesses: architecture exists only in engineer's head (not documented) → WP 04-04 missing → CL1 not achieved; components defined but no interface specification between them → BP3 not achieved; no traceability from SW components back to SW requirements → BP4 not demonstrated; architecture not reviewed formally (no review record with sign-off) → GP 2.2.2 not achieved; architecture version not under CM → GP 2.2.3 not achieved; solutions: Enterprise Architect model in Git LFS + automated traceability check script in DOORS
SWE.3 - Software Detailed Design & Unit Construction
50 min read
▸ SWE.3 purpose: develop SW units from SW architecture; work products: WP 04-05 (SW Detailed Design: function-level design, data flow, control flow, state machines), WP 06-01 (SW Unit = source code), WP 08-52 (Unit test specification - no wait, that's SWE.4); SWE.3.BP1: develop and document SW detailed design; BP2: describe dynamic behavior (sequence diagrams, state machines); BP3: evaluate SW detailed design; BP4: communicate and maintain agreed detailed design
▸ Detailed design documentation requirements: function-level specification: function name, inputs/outputs (data type, range, unit), algorithm description, pre/post conditions, error handling; state machine: states, transitions, guard conditions, actions (UML state diagram); pseudocode or flowchart for complex algorithms; code-to-design traceability: MISRA annotations or Doxygen \ref linking function to SWE.3 design document; AUTOSAR SWC: ARXML description maps to detailed design
▸ Unit construction (coding) standards: ASPICE BP6: apply coding standards during unit construction; evidence: MISRA C:2012 configuration (mandatory rules enforced, deviation register for advisory); Polyspace Code Prover or LDRA configuration file under CM; coding guideline document (naming conventions, complexity limits: McCabe ≤10, function length ≤60 lines); tool: Git pre-commit hook runs cppcheck or PC-lint; static analysis report included as WP evidence
▸ Common SWE.3 gaps: design document is copy of code comments (not design → code, but code → comments) → fails BP1 (design must precede code); no state machine documentation for complex ECU modes → BP2 not achieved; design not formally reviewed → GP 2.2.2 gap; coding standard document exists but compliance not verified → BP6 partial; solution: Model-Based Design (Simulink) → auto-generates both design documentation and code - assessors accept as SWE.3 WP if Simulink model includes requirements annotations
SWE.4 - Software Unit Verification
45 min read
▸ SWE.4 purpose & outcomes: verify SW units against SW detailed design; outcomes: SWE.4.O1 (unit test strategy developed); SWE.4.O2 (unit tests specified and reviewed); SWE.4.O3 (unit tests executed); SWE.4.O4 (unit verification consistency ensured); work products: WP 08-50 (Unit Test Specification), WP 08-52 (Unit Test Results), WP 19-00 (Verification Strategy/Plan including criteria: statement coverage, branch coverage, MC/DC for ASIL-D)
▸ Unit test specification requirements: test case structure: TC ID, linked design requirement, preconditions, inputs (specific values + boundary cases), expected output (specific value + tolerance), actual result, verdict; coverage criteria per ASIL: ASIL-B → 100% statement + branch; ASIL-C → additionally MC/DC for safety-relevant decisions; tool: VectorCAST (generates test specification from C code), LDRA, Polyspace Test; test spec under CM (version-controlled) and formally reviewed
▸ Unit test execution evidence: VectorCAST report elements: function, test case ID, coverage achieved (statement %, branch %, MC/DC %), verdict PASS/FAIL; acceptable result: 100% branch coverage with 0 FAIL; traceability: each test case linked to ≥1 detailed design requirement (SWE.3 design item → SWE.4 TC); VectorCAST Coverage Report PDF → stored as WP 08-52 in CM (Git tag with SW version); failed tests: defect report opened in Jira, linked to test case, tracked to closure
▸ Common SWE.4 assessment findings: unit tests exist but not systematically specified (only pass/fail screenshots) → WP 08-50 not sufficient; coverage <100% (e.g., 78% branch) → SWE.4.O4 not achieved → CL1=L; test cases not reviewed → GP 2.2.2 gap; VectorCAST reports not archived in CM → GP 2.2.3 gap; test results not linked to requirements → traceability gap; solution: VectorCAST + DOORS integration for automatic TC-to-requirement links; Jenkins CI: nightly unit test run + coverage report archived in Nexus
SWE.5 - Software Integration & Integration Testing
50 min read
▸ SWE.5 purpose & scope: integrate SW units/components and verify interfaces; outcomes: SWE.5.O1 (integration strategy defined); SWE.5.O2 (integration tests specified); SWE.5.O3 (integrated SW verified against architecture); SWE.5.O4 (consistency ensured); integration levels: unit integration (function ↔ function within component), component integration (SWC ↔ BSW), SW/HW integration (ECU on bench); each level has own integration test specification (WP 08-50) and results (WP 08-52)
▸ Integration test specification content: interface test focus: test that component A passes correct data to component B via their interface; example: test SWC "EngineSpeed_Ctrl" → sends correct CAN message 0x100 with EngineRPM value via Com module → measure with CANoe; test case elements: stimulus (input to system), execution (CAPL script or SIL test), verification (expected CAN signal value ±tolerance), traceability to SWE.2 interface specification; integration order: bottom-up (MCAL → BSW → App); stub/mock required for missing components
▸ Integration test tools: SIL (Software-in-the-Loop): run integrated ECU SW on PC; use GoogleTest or VectorCAST for SW-SW interface tests; CANoe Virtual: run CAN bus simulation + integrated ECU SW; SIL test framework: Python subprocess launches ECU binary + sends/receives signals via XCP-on-UDP; MIL testing: Simulink test harness for SW component integration; ECU-TEST: runs integration tests on SIL/PIL target; coverage: interface coverage (all defined interfaces tested) + integration scenario coverage
▸ Common SWE.5 weaknesses: integration tests not distinguished from unit tests (same VectorCAST tests claimed for both SWE.4 and SWE.5 → assessor rejects double-counting); integration test spec not traceable to SWE.2 architecture interfaces → BP2 gap; no integration order/strategy documented (just "we integrate everything at once") → O1 not achieved; integration test results not formally archived → GP 2.2.3 gap; interface errors found at HIL stage (SWE.6) that should have been caught at SWE.5 → process finding
SWE.6 - Software Qualification Testing
45 min read
▸ Test strategy & coverage requirements
▸ Test case specifications & procedures
▸ Automation framework & scripting guide
▸ Results analysis & reporting templates
Hands-On: Bidirectional Traceability Setup
60 min read
▸ Step-by-step implementation walkthrough
▸ Configuration templates & code samples
▸ Troubleshooting guide & common pitfalls
▸ Validation checklist & expected outputs
3
System & Support Processes
SYS.1–SYS.5 - System Engineering Processes
55 min read
▸ Process model & phase descriptions
▸ Role definitions & responsibilities
▸ Deliverables & work product templates
▸ Quality gates & review criteria
MAN.3 - Project Management
45 min read
▸ Step-by-step implementation walkthrough
▸ Configuration templates & code samples
▸ Troubleshooting guide & common pitfalls
▸ Validation checklist & expected outputs
SUP.1 - Quality Assurance
40 min read
▸ Comprehensive technical reference & specifications
▸ Detailed configuration guide with examples
▸ Implementation best practices & guidelines
▸ Troubleshooting reference & FAQ
SUP.8 - Configuration Management
40 min read
▸ Parameter reference table & valid ranges
▸ Step-by-step configuration procedure
▸ Validation & verification steps
▸ Configuration templates & examples
SUP.10 - Change Request Management
35 min read
▸ Planning framework & document structure
▸ Scope definition & stakeholder analysis
▸ Risk assessment & mitigation strategies
▸ Monitoring procedures & KPI definitions
Hands-On: Work Product Templates
55 min read
▸ Step-by-step implementation walkthrough
▸ Configuration templates & code samples
▸ Troubleshooting guide & common pitfalls
▸ Validation checklist & expected outputs
4
Assessment Preparation
Assessment Planning & Scope
40 min read
▸ Assessment criteria & rating scales
▸ Evidence requirements & documentation
▸ Finding categories & improvement actions
▸ Reporting templates & follow-up procedures
Evidence Collection Strategies
45 min read
▸ Comprehensive technical reference & specifications
▸ Detailed configuration guide with examples
▸ Implementation best practices & guidelines
▸ Troubleshooting reference & FAQ
Common Assessment Findings & Solutions
50 min read
▸ Assessment criteria & rating scales
▸ Evidence requirements & documentation
▸ Finding categories & improvement actions
▸ Reporting templates & follow-up procedures
Improvement Action Planning
35 min read
▸ Planning framework & document structure
▸ Scope definition & stakeholder analysis
▸ Risk assessment & mitigation strategies
▸ Monitoring procedures & KPI definitions
Hands-On: Mock Assessment Exercise
60 min read
▸ Step-by-step implementation walkthrough
▸ Configuration templates & code samples
▸ Troubleshooting guide & common pitfalls
▸ Validation checklist & expected outputs
Tools Used
What You'll Learn
Understand all ASPICE process areas and capability levels
Create ASPICE-compliant work products for SWE.1–SWE.6
Establish bidirectional traceability across the V-model
Prepare teams for successful ASPICE assessments
Implement process improvements based on assessment findings
Support Level 2 and Level 3 capability achievement
Prerequisites
Experience in automotive software development
Basic understanding of V-model development
Familiarity with requirements management
Full Access
Free with Pro
Enroll Now
Browse Modules
This course includes:
24 detailed documentation chapters
Downloadable resources
Searchable text documentation
Code snippets & technical diagrams
Hands-on exercises
Lifetime access
Certificate of completion