1.4: SYS.4 System Integration and Integration Verification

Learning Objectives

After reading this section, you will be able to:

• Integrate system elements according to integration strategy
• Develop and execute system integration tests
• Apply AI for test generation and result analysis
• Verify interface compliance
• Design AI-assisted HIL test campaigns
• Implement intelligent regression test selection for integration cycles

Process Definition

Purpose

SYS.4 Purpose: To integrate system elements and verify that the integrated system elements are consistent with the system architecture.

Key Distinction: SYS.4 verifies that integrated elements work together correctly according to the system architecture. This is fundamentally different from SYS.5, which verifies that the complete integrated system satisfies the system requirements. SYS.4 answers "Did we build the interfaces right?" while SYS.5 answers "Did we build the right system?"

Outcomes

Relationship to Other Processes

Base Practices with AI Integration

AI Automation Levels:

• L1 (Assist): AI suggests, human decides and executes
• L2 (Collaborate): AI drafts/executes, human reviews and approves
• L3 (Automate): AI executes autonomously, human monitors results

System Integration Test Strategy

AI-Assisted Strategy Design

Note: The integration test strategy must be aligned with the system architecture (SYS.3) and account for hardware availability, build sequences, and interface maturity.

AI Strategy Generation Input:
─────────────────────────────
Architecture: SYS.3 system architecture description
Elements:     HW elements, SW components, external interfaces
Constraints:  Hardware availability timeline, lab access schedule
Risk data:    Historical defect density per interface type

AI Strategy Output:
───────────────────
1. Integration Sequence Recommendation
   - Phase 1: CAN communication stack (highest risk, earliest availability)
   - Phase 2: Sensor signal chain (ADC + filtering + calibration)
   - Phase 3: Actuator control path (PWM + driver + feedback)
   - Phase 4: Cross-functional interfaces (diagnostics, NVM, watchdog)
   - Phase 5: Full system integration (all elements combined)

2. Test Environment Mapping
   - Phases 1-2: SIL sufficient for protocol and logic verification
   - Phase 3: PIL required for timing-critical actuator paths
   - Phases 4-5: HIL mandatory for full electrical interface verification

3. Risk-Based Prioritization
   - CAN ↔ Application interface: HIGH (timing-critical, safety-relevant)
   - Sensor ↔ Application interface: MEDIUM (calibration-dependent)
   - NVM ↔ Application interface: LOW (well-established pattern)

Human Review: Approve sequence, validate hardware availability assumptions

Integration Approaches

Automotive Example: BCM Integration

The diagram below shows the BCM integration phases, illustrating how system elements are progressively combined and verified from individual components to the fully integrated system.

Test Environment Progression

SIL → PIL → HIL → VIL

The following diagram illustrates the test environment progression from Software-in-the-Loop through Vehicle-in-the-Loop, showing increasing hardware fidelity at each stage.

Test Case Generation

AI-Powered Test Case Derivation from System Requirements

Principle: Integration test cases are derived from the system architecture interface specifications, not from system requirements directly. Each architectural interface should have at least one integration test verifying data exchange, timing, and error behavior.

test_case_generation:
  input:
    architecture: "sys3_bcm_architecture.xml"
    interface_spec: "bcm_interface_definitions.xlsx"
    signal_database: "bcm_signals.dbc"
    timing_constraints: "sys_timing_budget.yaml"

  ai_analysis:
    - Parse interface definitions for all system element pairs
    - Extract signal ranges, scaling factors, and validity conditions
    - Identify timing constraints per interface path
    - Cross-reference with known failure patterns from defect database
    - Generate boundary value combinations for multi-signal interfaces

  generated_tests:
    normal_operation:
      - "SYS-INT-001: CAN lock command → actuator activation (nominal)"
      - "SYS-INT-002: Sensor input → application state update (all channels)"
      - "SYS-INT-003: Diagnostic request → response frame (all services)"

    timing_verification:
      - "SYS-INT-020: End-to-end latency CAN Rx to actuator command"
      - "SYS-INT-021: Sensor sampling to application data availability"
      - "SYS-INT-022: Watchdog trigger to safe state transition"

    error_injection:
      - "SYS-INT-040: CAN bus-off recovery and re-integration"
      - "SYS-INT-041: Sensor open-circuit detection and substitution"
      - "SYS-INT-042: Power supply brownout during actuator operation"

    boundary_conditions:
      - "SYS-INT-060: Maximum CAN bus load with all messages active"
      - "SYS-INT-061: Simultaneous actuator activation current limit"
      - "SYS-INT-062: Temperature extremes with timing verification"

  human_review:
    - Verify completeness of interface coverage
    - Confirm error injection scenarios are physically realizable
    - Approve timing tolerances and pass/fail criteria

Integration Test Specification

Test Case Example

---
ID: SYS-INT-010
Title: Door Lock CAN Command Integration
Type: Integration Test
Priority: High
Phase: Phase 4 (System Interfaces)
---

## Objective

Verify that lock command received via CAN bus correctly activates
door lock actuators within timing requirements.

## Preconditions

- BCM powered and initialized
- CAN bus connected at 500 kbps
- All four door locks in unlocked position
- HIL environment operational

## Test Steps

| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | Send CAN message 0x301 [0x01, ...] | Message received |
| 2 | Monitor lock timing | Command within 50ms |
| 3 | Verify actuator signals | All 4 doors commanded |
| 4 | Verify feedback signals | Locked state within 200ms |

## Pass Criteria

- All four doors locked within 200ms of CAN message
- No error DTCs set
- Power consumption within limits

## Traceability

- Verifies: SYS-BCM-010, SYS-BCM-025
- Architecture: CAN Interface → Application → Driver

Hardware-in-the-Loop (HIL) Testing

AI in HIL Test Environments

Note: HIL testing is the primary verification environment for SYS.4 because it allows exercising real hardware interfaces (CAN, LIN, analog/digital I/O) while simulating the vehicle environment. AI enhances HIL testing by automating signal monitoring, anomaly detection, and adaptive test sequencing.

HIL Test Configuration Example

HIL Environment: BCM Integration Verification
──────────────────────────────────────────────
Hardware Under Test:  BCM ECU (production sample, Rev C)
HIL Platform:         dSPACE SCALEXIO with DS2211 I/O boards
CAN Interface:        Vector VN1610 (2x CAN channels at 500 kbps)
LIN Interface:        Vector VN1611 (1x LIN channel at 19.2 kbps)
Load Simulation:      4x electronic load modules (actuator emulation)
Sensor Simulation:    8x configurable analog outputs (0-5V)
Power Supply:         Programmable 8-16V with transient injection

AI Monitoring Layer:
  - Real-time signal recording at 1 ms resolution
  - Automated signal quality assessment per test step
  - Anomaly detection on all monitored channels
  - Timing measurement with microsecond precision
  - Automatic screenshot and waveform capture on failure

Test Automation Framework

Architecture for Automated System Integration Testing

Note: The test automation framework bridges the gap between test specifications (BP1) and automated execution (BP3). It should support multiple test environments (SIL, PIL, HIL) with a common test description language.

Automation Pipeline Configuration

# System integration test automation pipeline
sys_integration_pipeline:
  trigger:
    - integration_build_complete
    - nightly_schedule: "02:00 UTC"

  environment:
    platform: "dSPACE SCALEXIO"
    ecu_image: "${BUILD_ARTIFACT}/bcm_integration.hex"
    signal_db: "config/bcm_signals.dbc"
    plant_model: "models/vehicle_body_v3.2.mdl"

  phases:
    - name: "Flash and Initialize"
      timeout: 120s
      steps:
        - flash_ecu: "${ecu_image}"
        - wait_boot: 5s
        - verify_dtc_clear: true

    - name: "CAN Interface Integration"
      test_suite: "tests/can_integration/*.yaml"
      timeout: 600s
      abort_on_critical: true

    - name: "Sensor Chain Integration"
      test_suite: "tests/sensor_integration/*.yaml"
      timeout: 900s
      abort_on_critical: true

    - name: "Actuator Path Integration"
      test_suite: "tests/actuator_integration/*.yaml"
      timeout: 900s
      abort_on_critical: true

    - name: "Full System Integration"
      test_suite: "tests/full_integration/*.yaml"
      timeout: 1800s

  reporting:
    format: [junit_xml, html, pdf]
    ai_summary: true
    coverage_matrix: true
    trend_comparison: "last_5_builds"

AI Integration for Testing

L2: Test Case Generation

Input: System requirements + interface specifications

AI Output:
─────────
Generated Integration Test Cases for SYS-BCM-010:

1. SYS-INT-010-01: Normal lock via button
   - Precondition: All doors unlocked
   - Action: Press lock button
   - Expected: All doors locked < 200ms

2. SYS-INT-010-02: Normal lock via CAN
   - Precondition: All doors unlocked
   - Action: Send CAN lock command
   - Expected: All doors locked < 200ms

3. SYS-INT-010-03: Partial lock (1 door stuck)
   - Precondition: RL door mechanically blocked
   - Action: Press lock button
   - Expected: 3 doors locked, DTC set for RL

4. SYS-INT-010-04: Rapid lock/unlock
   - Precondition: All doors unlocked
   - Action: Lock, wait 100ms, unlock, wait 100ms, lock
   - Expected: Final state locked, no errors

Human Review: Verify completeness, add domain-specific cases

L3: Automated Test Execution

The diagram below shows how AI-generated test cases flow through automated execution environments, with results fed back for coverage analysis and regression tracking.

Defect Analysis

AI-Powered Root Cause Analysis of Integration Failures

Note: Integration defects frequently involve timing, protocol, or interface mismatch issues that are difficult to diagnose from test results alone. AI accelerates root cause analysis by correlating failure patterns across test runs and signal traces.

AI Defect Analysis Report:
──────────────────────────

Failed Test: SYS-INT-010-02 (CAN lock command integration)

Symptom: Actuator feedback delayed by 85ms (expected < 200ms, measured 285ms)

AI Correlation Analysis:
  - Signal trace shows CAN Rx timestamp normal (2ms)
  - Application processing delay normal (8ms)
  - Actuator command output delayed by 75ms
  - Delay correlates with high CPU load period (NVM write in progress)

Pattern Match:
  - Similar failure in Build #142 (NVM write blocking, resolved by priority inversion fix)
  - 3 other tests show marginal timing in same execution window

Root Cause Hypothesis:
  1. [HIGH confidence] NVM write operation blocking actuator task
  2. [MEDIUM confidence] Task priority configuration mismatch after RTOS update
  3. [LOW confidence] Hardware timer drift under thermal stress

Suggested Investigation:
  - Check RTOS task priority table against architecture specification
  - Review NVM write scheduling vs. actuator control cycle
  - Capture CPU load trace during next test execution

Human Action: Validate hypothesis, authorize investigation path

Defect Classification Matrix

Regression Testing

Intelligent Test Selection and Prioritization

Note: Full integration test suites can take hours to execute on HIL platforms. AI-assisted regression test selection reduces execution time while maintaining confidence in integration quality.

Regression Optimization Example

AI Regression Analysis:
───────────────────────

Build Delta: CAN driver updated (v2.3.1 → v2.4.0), NVM module unchanged

Full Suite:     248 integration tests, estimated 4.2 hours
AI Recommended:  67 integration tests, estimated 1.1 hours

Selection Breakdown:
  - CAN interface tests (all):       34 tests  [change-based]
  - CAN-dependent path tests:        18 tests  [dependency-based]
  - Previously flaky tests:           8 tests  [failure-history]
  - Safety-critical path smoke tests: 7 tests  [risk-based]

Excluded (with justification):
  - NVM integration tests (42):  No changes to NVM module or interfaces
  - LIN interface tests (38):    No shared code path with CAN update
  - Sensor chain tests (56):     Independent signal path, no coupling

Coverage Impact:
  - Interface coverage: 94% of affected interfaces (vs. 100% full suite)
  - Risk coverage: 100% of HIGH-risk interfaces maintained
  - Estimated defect escape probability: < 2%

Human Decision: Approve reduced suite or request full execution

HITL Protocol for System Integration Testing

Human-in-the-Loop Protocol: System integration testing involves safety-relevant decisions about interface behavior and system-level interactions. The following protocol defines mandatory human checkpoints.

Escalation Criteria

Mandatory human escalation is triggered when any of the following conditions are detected during automated test execution:

Work Products

Note: Work Product IDs follow ASPICE 4.0 standard numbering.

Tool Integration

Vector CANoe, dSPACE, and NI with AI

Note: AI integration with established automotive test tools enhances automation without replacing proven measurement and simulation capabilities. The AI layer sits above the tool-specific interfaces.

Tool Chain Integration Architecture

Tool Chain Data Flow:
─────────────────────
Requirements DB (DOORS)
    ↓ [AI: trace extraction]
Architecture Model (Enterprise Architect / Rhapsody)
    ↓ [AI: interface enumeration]
Test Specification (vTESTstudio / TestStand)
    ↓ [AI: test script generation]
HIL Execution (CANoe + SCALEXIO / VeriStand)
    ↓ [AI: signal monitoring, pass/fail evaluation]
Result Database (custom / ALM tool)
    ↓ [AI: trend analysis, defect correlation]
Traceability Report (auto-generated)
    ↓ [Human: review and approve]
Integration Milestone Gate

Implementation Checklist

Usage: This checklist supports project teams in establishing SYS.4 process compliance with AI integration. Each item maps to the relevant base practice and outcome.

Summary

SYS.4 System Integration and Integration Verification:

• AI Level: L2-L3 (significant automation possible)
• AI Value: Test generation, execution automation, result analysis
• Human Essential: Strategy decisions, failure analysis, milestone sign-off
• Key Outputs: Integration verification specification, verification results, coverage matrix
• Test Environments: SIL → PIL → HIL → VIL progression
• Critical Success Factor: Architecture-driven test derivation with AI assistance and human oversight