5.2: SUP.2 Verification

Process Definition

Purpose

SUP.2 Purpose: To confirm that work products properly reflect the requirements.

ASPICE 4.0 Note: In ASPICE PAM v4.0, the standalone SUP.2 Verification process has been removed as a separate process. Verification activities are now embedded directly within each engineering process (SYS.1-SYS.5, SWE.1-SWE.6). This chapter retains SUP.2 as a cross-cutting concern because: (a) many organizations still operate under ASPICE 3.1 where SUP.2 exists, (b) verification strategy and governance remain project-level activities regardless of the process model version, and (c) the principles of independent verification apply across all engineering processes.

Outcomes

Base Practices (ASPICE 3.1 Reference)

Verification in ASPICE 4.0

Where Verification Now Lives

ASPICE PAM v4.0 dissolved SUP.2 as a standalone process and distributed verification responsibilities into each engineering process. The table below maps the former SUP.2 outcomes to their new homes in v4.0.

Practical Impact: Organizations migrating from ASPICE 3.1 to 4.0 must redistribute their SUP.2 verification plan content into the individual SYS/SWE process plans. The verification strategy document remains valuable as a cross-cutting governance artifact, even if assessors will evaluate verification within each process.

System-Level Verification Mapping

Migration Guidance

Recommendation: When migrating from ASPICE 3.1 to 4.0, do not simply delete the SUP.2 verification plan. Instead, decompose it into per-process verification sections and retain a lightweight project-level verification governance document that ensures consistency across process levels.

Verification Strategy

Strategy Components

A verification strategy defines the overall approach to confirming that work products satisfy their requirements. AI assists at each stage of strategy development.

AI-Assisted Strategy Generation

Note: The strategy template below is illustrative. Actual strategy documents must be tailored to project-specific ASIL levels, domain standards, and organizational processes.

# Verification Strategy (AI-generated draft, requires human review)
verification_strategy:
  project: BCM-DoorLock
  aspice_version: "4.0"
  safety_level: ASIL-B

  scope:
    - artifact: "Software Requirements Specification"
      method: Technical Review + AI Pre-Analysis
      frequency: Per baseline
      ai_level: L2
    - artifact: "Software Architecture Document"
      method: Inspection + Static Analysis
      frequency: Per release
      ai_level: L2
    - artifact: "Detailed Design"
      method: Peer Review + AI Pre-Analysis
      frequency: Per change
      ai_level: L2
    - artifact: "Source Code"
      method: Peer Review + Static Analysis + AI Review
      frequency: Per merge request
      ai_level: L2-L3
    - artifact: "Test Specifications"
      method: Technical Review
      frequency: Per baseline
      ai_level: L1

  method_selection_criteria:
    asil_a: "Peer review with AI pre-analysis"
    asil_b: "Technical review with AI pre-analysis and static analysis"
    asil_c: "Inspection with AI pre-analysis, static analysis, formal methods"
    asil_d: "Inspection with AI pre-analysis, static analysis, formal methods, independent review"

  review_capacity:
    max_review_size: "200 LOC or 30 requirements per session"
    preparation_time: "1 hour minimum per reviewer"
    ai_preparation: "Automated, results available before human preparation"

Verification Methods

Method Selection Matrix

Method-Artifact Suitability

AI-Assisted Review Framework

The following diagram illustrates the AI-assisted pre-review preparation workflow, showing how AI pre-analyzes artifacts, flags potential issues, and prepares review packages before human reviewers begin their assessment.

Review Automation

AI-Powered Review by Artifact Type

AI-powered review automation applies differently across artifact types. The following subsections describe the approach for each major category.

Requirements Review

AI Role: L2 -- AI performs pre-analysis and flags issues; humans validate findings and make acceptance decisions.

# AI Requirements Review Output (illustrative)
requirements_review:
  document: SRS-BCM-v1.2
  total_requirements: 48
  ai_findings:
    ambiguity:
      - req: SWE-BCM-015
        term: "quickly"
        suggestion: "Replace with measurable criterion, e.g., 'within 10ms'"
      - req: SWE-BCM-033
        term: "appropriate level"
        suggestion: "Specify exact threshold value"
    completeness:
      - req: SWE-BCM-031
        gap: "No error handling specified for CAN timeout"
        suggestion: "Add timeout handling requirement with DTC specification"
    consistency:
      - req: SWE-BCM-008
        issue: "Uses 'actuator' but SWE-BCM-020 uses 'motor' for same component"
        suggestion: "Standardize to 'actuator' per glossary"
    testability:
      - req: SWE-BCM-041
        issue: "Requirement states 'system shall be reliable' without measurable criteria"
        suggestion: "Define MTBF target or failure rate threshold"
  summary:
    total_findings: 12
    by_severity: { critical: 0, major: 4, minor: 6, suggestion: 2 }
    human_review_required: true

Design Review

AI Role: L2 -- AI checks architectural patterns, interface consistency, and compliance with design standards.

Code Review

AI Role: L2-L3 -- AI automates static checks (L3) and performs semantic analysis (L2) requiring human validation.

Review Record Template

Note: Participant names are illustrative; actual records use real project team members.

# Technical Review Record (illustrative example)
review:
  id: TR-SWE1-001
  type: Technical Review
  date: (review date)
  duration: 2 hours

  artifact:
    name: "SW Requirements Specification"
    id: SRS-BCM-v1.2
    version: 1.2
    author: (Author Name)
    size: 48 requirements

  participants:
    moderator: (Moderator) (QA Lead)
    author: (Author) (SW Lead)
    reviewers:
      - (Reviewer 1) (System Architect)
      - (Reviewer 2) (Safety Engineer)
      - (Reviewer 3) (Test Lead)

  preparation:
    ai_analysis: completed
    ai_findings: 12 items
    prep_time_avg: 1.5 hours

  findings:
    major:
      - id: F-001
        requirement: SWE-BCM-015
        description: "Timing requirement 'quickly' is ambiguous"
        category: ambiguity
        source: AI + Human

      - id: F-002
        requirement: SWE-BCM-031
        description: "Error handling not specified for timeout"
        category: completeness
        source: Human

    minor:
      - id: F-003
        requirement: SWE-BCM-008
        description: "Inconsistent terminology: 'actuator' vs 'motor'"
        category: consistency
        source: AI

      - id: F-004
        requirement: SWE-BCM-022
        description: "Reference to deleted requirement SWE-BCM-050"
        category: consistency
        source: AI

    total_findings: 8
    major: 2
    minor: 6

  metrics:
    preparation_rate: 32 req/hour
    review_rate: 24 req/hour
    finding_density: 0.17 findings/requirement
    ai_contribution: 50% (4 of 8 findings)

  outcome: CONDITIONAL_ACCEPT
  rework_required: true
  rework_deadline: 2025-01-20
  verification_needed: true

Code Review Automation

AI-Powered Code Review

Note: Python code examples are illustrative; helper functions (run_static_analysis, check_misra_compliance, etc.) require project-specific implementation.

"""
AI-assisted code review for embedded software
"""

def analyze_code_change(diff: str, context: dict) -> dict:
    """
    Perform AI-assisted code review analysis.

    Args:
        diff: Git diff of changes
        context: Project context (standards, patterns)

    Returns:
        Review findings and recommendations
    """

    findings = []

    # 1. Static analysis checks (L3 - fully automated)
    static_findings = run_static_analysis(diff)
    findings.extend(static_findings)

    # 2. MISRA compliance (L3 - automated)
    misra_findings = check_misra_compliance(diff)
    findings.extend(misra_findings)

    # 3. AI semantic analysis (L2 - AI with human review)
    ai_findings = ai_semantic_review(diff, context)
    findings.extend(ai_findings)

    # 4. Security analysis (L2)
    security_findings = analyze_security(diff)
    findings.extend(security_findings)

    # Generate review summary
    summary = {
        'total_findings': len(findings),
        'by_severity': categorize_by_severity(findings),
        'by_category': categorize_by_type(findings),
        'recommendation': get_recommendation(findings),
        'human_review_items': get_human_review_items(findings)
    }

    return {
        'findings': findings,
        'summary': summary
    }


def ai_semantic_review(diff: str, context: dict) -> list:
    """AI semantic analysis of code changes."""

    prompt = f"""
    Review this embedded C code change for:
    1. Logic correctness
    2. Safety implications
    3. Performance concerns
    4. Maintainability issues
    5. Alignment with architecture patterns

    Standards: {context.get('standards', ['MISRA C:2012'])}
    Project: {context.get('project_type', 'Automotive BCM')}

    Code diff:
    ```
    {diff}
    ```

    Provide findings with:
    - Location (file:line)
    - Category
    - Severity (critical/major/minor)
    - Description
    - Recommendation
    """

    # Call AI service
    response = ai_service.analyze(prompt)

    return parse_ai_findings(response)

Static Analysis with AI

Beyond Traditional SAST

Traditional static analysis tools (SAST) apply fixed rule sets to detect coding standard violations, common defects, and security vulnerabilities. AI-enhanced static analysis goes further by learning project-specific patterns and detecting semantic issues that rule-based tools miss.

AI-Enhanced Analysis Workflow

Note: Tool names are illustrative. Actual tool selection depends on project constraints and vendor evaluation.

False Positive Reduction

Key Benefit: AI-assisted triage can reduce the human effort spent on false positives by learning from historical disposition decisions. Over successive releases, the AI model improves its precision in flagging genuine defects.

# AI False Positive Triage (illustrative)
triage_result:
  tool: Klocwork
  total_findings: 342
  ai_triage:
    true_positive_likely: 87
    false_positive_likely: 198
    uncertain: 57
  human_review_queue:
    priority_1: 87   # True positives - review and fix
    priority_2: 57   # Uncertain - human classification needed
    priority_3: 198  # Likely false positives - spot-check sample
  estimated_effort_saved: "~60% reduction in triage time"

Verification Criteria

AI-Generated Verification Criteria from Requirements

Verification criteria define the measurable conditions under which a work product is considered to satisfy its requirements. AI assists by extracting testable attributes from natural-language requirements and proposing criteria that humans refine.

Criteria Derivation Process

ASPICE Compliance: In ASPICE 4.0, verification criteria are part of the "Verification Measure" work product (08-60). Each verification measure must include explicit pass/fail criteria traceable to the requirement it verifies.

Traceability Verification

Automated Bidirectional Traceability Checking

Bidirectional traceability is a core ASPICE requirement across all engineering processes. AI automates the detection of traceability gaps, orphan items, and inconsistencies.

Gap Detection Report

# AI Traceability Verification Report (illustrative)
traceability_check:
  project: BCM-DoorLock
  date: (analysis date)
  tool: AI Traceability Agent

  coverage:
    system_to_sw: 47/48 (97.9%)
    sw_to_architecture: 45/48 (93.8%)
    sw_to_verification: 43/48 (89.6%)
    verification_to_results: 41/43 (95.3%)

  gaps:
    missing_forward:
      - from: SWE-BCM-046
        expected_link: Architecture component
        severity: HIGH
        suggestion: "Allocate to Door_Lock_Service component based on content analysis"
      - from: SWE-BCM-047
        expected_link: Architecture component
        severity: HIGH
        suggestion: "Allocate to Safety_Monitor component based on content analysis"
      - from: SWE-BCM-048
        expected_link: Architecture component
        severity: MEDIUM
        suggestion: "Allocate to Diagnostics component based on content analysis"

    missing_backward:
      - from: SWE-VM-BCM-022
        expected_link: SW Requirement
        severity: HIGH
        suggestion: "Orphan verification measure - link to SWE-BCM-105 or remove"

    orphan_requirements:
      - id: SWE-BCM-050
        status: "Deleted but still referenced by SWE-BCM-022"
        action: "Remove reference or restore requirement"

  recommendation: "5 traceability gaps require human resolution before baseline"

Consistency Checks

Independent Verification

Maintaining Independence When AI Assists

Independence is a fundamental principle of verification: the verifier must not be the author of the work product. When AI is introduced into the verification process, new independence considerations arise.

Independence Levels for AI-Assisted Verification

Reference: ISO 26262 Part 2, Table 3 defines independence levels for verification activities.

HITL Protocol for Verification Decisions

Human-in-the-Loop Requirements

Principle: AI assists verification execution; humans own verification decisions. No verification outcome may be approved without explicit human sign-off.

HITL Verification Workflow

# HITL Verification Workflow (illustrative)
hitl_workflow:
  phase_1_preparation:
    ai_actions:
      - Run static analysis on artifact
      - Perform NLP analysis for ambiguity/completeness
      - Check traceability links
      - Generate pre-review findings report
    human_actions:
      - Review AI findings report
      - Prepare own review notes independently
      - Confirm review readiness

  phase_2_review:
    ai_actions:
      - Present findings in structured format
      - Provide cross-references and evidence
      - Record findings in real-time (if using AI-assisted recording)
    human_actions:
      - Discuss each finding
      - Add findings not detected by AI
      - Classify and prioritize all findings
      - Decide outcome (accept, conditional accept, reject)

  phase_3_follow_up:
    ai_actions:
      - Track rework items to closure
      - Re-verify corrected items
      - Generate closure report
    human_actions:
      - Validate rework quality
      - Confirm all actions resolved
      - Sign off on verification closure

  accountability:
    finding_decisions: "Human only"
    pass_fail_verdict: "Human only"
    corrective_actions: "Human assigns, AI tracks"
    closure_approval: "Human only"

Audit Evidence: For ASPICE assessments, the review record must clearly document which findings originated from AI analysis and which from human reviewers. The disposition decision must always be attributed to a named human participant.

Tool Integration

Verification Tool Landscape

Integration Architecture

Note: The integration pattern below is illustrative. Actual integration depends on the organization's tool landscape and CI/CD infrastructure.

# Verification Tool Integration (illustrative CI/CD pipeline)
verification_pipeline:
  trigger: merge_request

  stage_1_automated:
    tools:
      - name: cppcheck
        type: static_analysis
        config: "--enable=all --std=c11 --addon=misra.json"
        ai_level: L3
      - name: Klocwork
        type: sast
        config: "project-specific analysis profile"
        ai_level: L3
      - name: Polyspace
        type: formal_analysis
        config: "Bug Finder + Code Prover"
        ai_level: L3
    output: static_analysis_report.json

  stage_2_ai_analysis:
    tools:
      - name: AI Review Agent
        type: semantic_analysis
        config: "embedded C review profile"
        ai_level: L2
      - name: AI Triage Agent
        type: finding_classification
        config: "trained on project history"
        ai_level: L2
    output: ai_review_report.md

  stage_3_human_review:
    tools:
      - name: Gerrit / GitLab MR
        type: review_platform
    input:
      - static_analysis_report.json
      - ai_review_report.md
    human_actions:
      - Review AI findings
      - Add human observations
      - Make pass/fail decision

  stage_4_traceability:
    tools:
      - name: AI Traceability Agent
        type: traceability_verification
        ai_level: L2
    output: traceability_report.json

AI Verification Agent Configuration

Note: Agent configuration is illustrative. Adapt to your AI infrastructure (cloud-hosted LLM, on-premises model, etc.).

# AI Verification Agent Configuration
ai_verification_agent:
  role: "Verification Assistant"
  capabilities:
    - pre_review_analysis
    - static_analysis_triage
    - traceability_verification
    - review_report_generation

  rules:
    - "Never make pass/fail decisions autonomously"
    - "Always flag safety-critical findings for human review"
    - "Clearly label all findings as AI-generated"
    - "Do not suppress findings without human approval"
    - "Maintain audit trail of all AI actions"

  integration:
    ci_cd: "GitLab CI / GitHub Actions"
    review_platform: "Gerrit / GitLab MR"
    alm: "Polarion / codebeamer"
    static_analysis: "Klocwork / Polyspace / SonarQube"

  reporting:
    format: "YAML + Markdown"
    traceability: "Link findings to requirements and design elements"
    metrics: "Finding density, AI contribution rate, false positive rate"

Verification Metrics

The diagram below presents a verification metrics report, summarizing finding density, review coverage, and AI contribution rates to help teams assess review effectiveness.

Key Performance Indicators

Work Products

Detailed Work Product Table

Work Product Quality Criteria

Implementation Checklist

Verification Process Setup

ASPICE 4.0 Migration Checklist

Summary

SUP.2 Verification:

• AI Level: L2 (AI pre-analysis, human decision)
• Primary AI Value: Pre-review analysis, finding detection, traceability verification, static analysis triage
• Human Essential: Technical judgment, design decisions, pass/fail verdicts, finding disposition
• Key Outputs: Review records, verification reports, traceability evidence
• Efficiency Gain: ~35% time reduction with AI assistance (estimated; calibrate based on project data)
• ASPICE 4.0: SUP.2 removed as standalone process; verification now embedded in SYS/SWE processes
• Independence: AI supplements but does not replace human reviewer independence requirements
• HITL: All verification decisions require explicit human sign-off with audit trail