Virtual ECU (vECU) Testing

1. Overview and Purpose

1.1 Document Scope

This document defines the comprehensive technical requirements for the delivery and use of Virtual ECU (vECU) test instances in Software-in-the-Loop (SiL) and Hardware-in-the-Loop (HiL) testing environments. The requirements outlined herein are based on the extension of specifications for secondary (2nd) ECUs used in Electrical/Electronic (EE) software testing with virtual test instances.

1.2 Reference Documents

1.3 Purpose and Objectives

The vECU testing framework serves the following key objectives:

• Enable virtual complete vehicle verification and validation before physical hardware availability
• Support network-level integration testing for secondary/2nd ECUs
• Provide frame-based and signal-based communication options depending on vECU level
• Ensure functional equivalence between virtual and real ECU test instances
• Standardize vECU delivery across different suppliers and testing platforms

1.4 Testing Environment Categories

2. vECU Level Classification

The vECU classification system is defined in the prostep ivip White Paper and provides a standardized framework for categorizing virtual ECU instances based on their level of abstraction and component fidelity.

2.1 Classification Overview

The following table presents the five vECU levels with their respective component compositions:

2.2 Level Descriptions

Level 0 - V-ECU Controller Model

Pure behavioral model representation of the ECU controller. This level contains only a mathematical model of the control logic without production code. Used for concept validation and algorithm development in early development phases.

Level 1 - V-ECU Application Level

Level 2 - V-ECU Simulation BSW

Production ASW code combined with simulation basic software. The BSW components are replaced with simulation-capable equivalents that mimic the interface behavior while enabling higher execution speed. This level represents a transitional approach.

Level 3 - V-ECU Production BSW

Level 4 - V-ECU Target Binary

Complete binary-level representation of the production ECU, including all drivers and hardware abstraction. This level provides the highest fidelity but may have limitations in execution speed and flexibility due to hardware-specific dependencies.

2.3 Level Selection Criteria

3. vECU Level Architecture

The following architecture diagram illustrates the progression from Level 0 (pure model) to Level 4 (full binary), showing which components are included at each level and their typical use cases.

graph TB
    subgraph L0["Level 0: V-ECU Controller Model"]
        L0_ASW["Application Software
Behavioral Model"]
        L0_USE["Use Case: Concept Validation"]
    end

    subgraph L1["Level 1: V-ECU Application Level"]
        L1_ASW["Application Software
Production Code"]
        L1_MID["Middleware
(Optional)"]
        L1_SIGNAL["Signal-Based
Communication"]
        L1_USE["Use Case: ASW Testing"]
    end

    subgraph L2["Level 2: V-ECU Simulation BSW"]
        L2_ASW["Application Software
Production Code"]
        L2_BSW_SIM["Basic Software
Simulation"]
        L2_SIGNAL["Signal-Based
Communication"]
        L2_USE["Use Case: Integration Testing"]
    end

    subgraph L3["Level 3: V-ECU Production BSW"]
        L3_ASW["Application Software
Production Code"]
        L3_BSW_PROD["Basic Software
Production Code"]
        L3_FRAME["Frame-Based
Full PDU"]
        L3_DIAG["Complete Diagnostic
Stack"]
        L3_USE["Use Case: Full Stack Verification"]
    end

    subgraph L4["Level 4: V-ECU Target Binary"]
        L4_ALL["Complete Binary Stack
All Components"]
        L4_HW["Hardware Abstraction"]
        L4_DRIVERS["Binary Drivers"]
        L4_USE["Use Case: Binary Replication"]
    end

    L0 --> L1
    L1 --> L2
    L2 --> L3
    L3 --> L4

    style L3 fill:#FF9800,stroke:#E65100,stroke-width:3px
    style L1 fill:#2196F3,stroke:#0D47A1,stroke-width:2px
      

3.1 Component Breakdown per Level

3.2 Use Case Mapping

4. Required vECU Delivery Levels

This section defines the mandatory and optional vECU delivery levels based on testing requirements and integration scenarios.

4.1 Level 3 vECU - PRIMARY REQUIREMENT

• Full Production Code: Complete application software AND basic software in production quality
• Frame-based Communication: Full PDU communication over CAN, FlexRay, and Ethernet bus systems
• Complete Diagnostic Stack: All diagnostic functions activated or activatable by default
• Parameterization Capability: Must be parameterizable with identical tools as real ECU

Required Use Cases for Level 3:

4.2 Level 1 vECU - OPTIONAL

• Production Code: Application software only (no BSW)
• Signal-based Communication: Signal-level interface with bus networks
• Middleware: May include middleware components (boundary to Level 2 not exact)
• Coordination Required: Must be individually coordinated with virtual test house

Benefits of Level 1 vECU:

4.3 Level Selection Decision Matrix

5. Level 3 vECU Format Requirements

Level 3 vECU must be delivered in formats that ensure maximum compatibility with target simulation environments while maintaining functional equivalence to production ECUs.

5.1 Primary Delivery Formats

5.2 Functional Requirements

Communication Requirements

Parameterization Requirements

• Must enable parameterization with identical tools as real ECU
• Must load pre-simulation calibration (e.g., DCM files)
• XCP interface for "Live changes" during simulation
• All internal measurement signals accessible
• Signal naming: Identical to real ECU measurement signal names
• Interface: Same as real ECU (e.g., XCP)

5.3 Diagnostic Requirements

• Complete software stack of all diagnostic functions
• All diagnostics activated or activatable by default
• Identical tool landscape as real vehicle diagnostics (SiL environment)
• Diagnostic access via standard diagnostic protocols

5.4 XCP Interface Requirements

5.5 Signal Access Requirements

• All internal measurement signals accessible
• Signal names must match real ECU exactly
• Real-time signal monitoring capability
• Signal logging and tracing support

6. Level 1 vECU Format Requirements

Level 1 vECU provides application-only software delivery with signal-based communication, suitable for scenarios where higher simulation speed is required and full BSW functionality is not critical.

6.1 Primary Delivery Formats

6.2 FMI 3.0 Requirements

• FMU for Co-Simulation (minimum FMI 3.0)
• Must be license-free executable
• XCP interface via FMI 3.0 LS-XCP (mandatory if real ECU has XCP)
• Windows 11 binaries required
• Linux 64-bit binaries optional

6.3 Level 1 Communication Requirements

6.4 FMI Interface Specifications

6.5 Level 1 vs Level 3 Format Differences

7. Real-Time HIL Integration Requirements

Real-Time Hardware-in-the-Loop (RT-HiL) systems require specific technical configurations to ensure deterministic execution and compatibility with timing constraints.

7.1 Target System Parameters

7.2 Real-Time Timing Requirements

7.3 Compiler and Runtime Requirements

7.4 FMI 3.0 LS-XCP Requirements

• Mandatory for real-time calibration during HiL simulation
• LS-XCP (Layered Services XCP) must be supported via FMI 3.0 interface
• Enables measurement and calibration without stopping simulation
• Provides access to internal variables and parameters

7.5 Shared Object Delivery

8. vHIL Architecture

The Virtual Hardware-in-the-Loop (vHIL) architecture provides a framework for distributed real-time testing with virtual ECU instances.

graph TB
    subgraph RT_HIL["Real-Time HiL System"]
        subgraph EXECUTIVE["Real-Time Executive"]
            TIME_MGMT["Time Management
1ms Raster"]
            TASK_SCHED["Task Scheduler"]
        end
        subgraph FMU_CONTAINER["FMU Container"]
            VECU_L3["vECU Level 3
Execution Unit"]
            TURNAROUND["Turnaround Budget
50% = 500us"]
        end
        subgraph BUS_SIM["Bus Simulation"]
            CAN_SIM["CAN Simulator"]
            FR_SIM["FlexRay Simulator"]
            ETH_SIM["Ethernet Simulator"]
        end
    end

    subgraph VIRTUAL_BUS["Virtual Bus Integration"]
        SIL_KIT["Vector SIL Kit
Open-Source"]
        GLOBAL_TIME["Global Virtual Time
Synchronization"]
    end

    subgraph VECU_INSTANCES["vECU Instances"]
        VECU_1["vECU Instance 1"]
        VECU_2["vECU Instance 2"]
        VECU_N["vECU Instance N"]
    end

    subgraph RESTBUS["Restbus Simulation"]
        RESTBUS_SIM["Restbus Simulation
Frame-Based"]
    end

    EXECUTIVE --> FMU_CONTAINER
    EXECUTIVE --> BUS_SIM
    TIME_MGMT --> GLOBAL_TIME
    VECU_L3 --> SIL_KIT
    SIL_KIT --> VECU_INSTANCES
    SIL_KIT --> RESTBUS
    BUS_SIM --> SIL_KIT

    style RT_HIL fill:#FFF3E0,stroke:#E65100,stroke-width:2px
    style VECU_L3 fill:#FF9800,stroke:#E65100,stroke-width:3px
    style TURNAROUND fill:#FFEBEE,stroke:#f44336,stroke-width:2px
      

8.1 Architecture Components

8.2 Timing Flow

gantt
    title Real-Time Calculation Step (1ms)
    dateFormat X
    axisFormat %s us

    section Calculation Step
    Total Step Time           :0, 1000
    section vECU Execution
    vECU Turnaround Budget    :0, 500
    section Remaining Tasks
    Bus Simulation            :200, 700
    Other Tasks Budget        :500, 1000
      

8.3 vHIL Integration Points

9. Bus Communication Requirements

Bus communication requirements differ based on vECU level, with Level 3 requiring frame-based (full PDU) communication and Level 1 using signal-based communication.

9.1 Level 3 vECU Bus Communication

9.2 Level 1 vECU Bus Communication

9.3 Communication Mode Comparison

9.4 Virtual Network Integration

• Vector SIL Kit for virtual bus integration (open-source)
• SIL Kit supports both frame-based (L3) and signal-based (L1) communication
• vECU must synchronize with global virtual time
• All software components must participate in time synchronization

9.5 Signal Naming Requirements

• Signal names must be identical to real ECU measurement signal names
• PDU structure must match production ECU network configuration
• Bus databases (DBC, FIBEX, ARXML) must be consistent with real ECU

10. Bus Communication Architecture

The bus communication architecture supports both Level 3 (frame-based) and Level 1 (signal-based) communication topologies.

graph TB
    subgraph VECU_L3["vECU Level 3"]
        ASW_L3["Application Software"]
        BSW_L3["Basic Software"]
        PDU_LAYER["PDU Layer
Frame Processing"]
        COM_STACK["Communication Stack"]
    end

    subgraph VIRTUAL_BUS_L3["Virtual Bus - Frame Based"]
        SIL_KIT_FRAME["SIL Kit
Frame Mode"]
        PDU_ROUTING["PDU Routing"]
        BUS_SIM_FRAME["Bus Simulation
CAN | FlexRay | ETH"]
    end

    subgraph RESTBUS_L3["Restbus Simulation"]
        ECU_1_L3["ECU 1 (Real)"]
        ECU_2_L3["ECU 2 (Real)"]
        ECU_3_L3["ECU 3 (Virtual)"]
    end

    ASW_L3 --> BSW_L3
    BSW_L3 --> PDU_LAYER
    PDU_LAYER --> COM_STACK
    COM_STACK --> PDU_ROUTING
    PDU_ROUTING --> SIL_KIT_FRAME
    SIL_KIT_FRAME --> BUS_SIM_FRAME
    BUS_SIM_FRAME --> ECU_1_L3
    BUS_SIM_FRAME --> ECU_2_L3
    BUS_SIM_FRAME --> ECU_3_L3

    style VECU_L3 fill:#FF9800,stroke:#E65100,stroke-width:3px
    style SIL_KIT_FRAME fill:#4CAF50,stroke:#2E7D32
      

graph TB
    subgraph VECU_L1["vECU Level 1"]
        ASW_L1["Application Software"]
        MIDDLEWARE["Middleware"]
        SIGNAL_LAYER["Signal Layer"]
    end

    subgraph VIRTUAL_BUS_L1["Virtual Bus - Signal Based"]
        SIL_KIT_SIGNAL["SIL Kit
Signal Mode"]
        SIGNAL_ROUTING["Signal Routing"]
        BUS_SIM_SIGNAL["Bus Simulation
CAN | FlexRay | ETH"]
    end

    subgraph RESTBUS_L1["Restbus Simulation"]
        ECU_1_L1["ECU 1 (Real)"]
        ECU_2_L1["ECU 2 (Real)"]
    end

    ASW_L1 --> MIDDLEWARE
    MIDDLEWARE --> SIGNAL_LAYER
    SIGNAL_LAYER --> SIGNAL_ROUTING
    SIGNAL_ROUTING --> SIL_KIT_SIGNAL
    SIL_KIT_SIGNAL --> BUS_SIM_SIGNAL
    BUS_SIM_SIGNAL --> ECU_1_L1
    BUS_SIM_SIGNAL --> ECU_2_L1

    style VECU_L1 fill:#2196F3,stroke:#0D47A1,stroke-width:2px
    style SIL_KIT_SIGNAL fill:#4CAF50,stroke:#2E7D32
      

10.1 Communication Stack Comparison

10.2 SIL Kit Configuration Options

11. SiL Simulation Requirements

Software-in-the-Loop (SiL) simulation requirements define the execution environment, configuration parameters, and functional expectations for vECU instances.

11.1 SiL Environment Requirements

Execution Options:

• Option 1: Native execution in Silver
• Option 2: Connection via Vector SIL Kit (open-source)

11.2 Level 3 vECU SiL Requirements

11.3 Level 1 vECU SiL Requirements

11.4 Simulation Model Technical Requirements (Level 1)

11.5 Model Delivery Standards (LAH.000.900.BQ)

12. SiL Architecture

The SiL architecture defines the component structure and data flow for Software-in-the-Loop testing with virtual ECU instances.

graph TB
    subgraph TEST_FRAMEWORK["Test Framework"]
        TEST_ORCH["Test Orchestration"]
        TEST_DATA["Test Data
Management"]
        RESULT_COLL["Result
Collection"]
    end

    subgraph SIL_ENV["SiL Environment - Silver 2025.03+"]
        subgraph VECU_CONTAINER["vECU Container"]
            VECU_L3_A["vECU Level 3A"]
            VECU_L3_B["vECU Level 3B"]
            VECU_L1["vECU Level 1"]
        end
        subgraph SIL_KIT["Vector SIL Kit"]
            FRAME_MODE["Frame Mode
L3"]
            SIGNAL_MODE["Signal Mode
L1"]
        end
    end

    subgraph VIRTUAL_BUS["Virtual Bus"]
        RESTBUS["Restbus
Simulation"]
        BUS_MON["Bus
Monitoring"]
    end

    subgraph PERIPHERALS["Peripheral Models"]
        SENSOR_MOD["Sensor
Models"]
        ACTUATOR_MOD["Actuator
Models"]
        ENV_MOD["Environment
Models"]
    end

    TEST_ORCH --> SIL_ENV
    SIL_ENV --> VIRTUAL_BUS
    VIRTUAL_BUS --> RESTBUS
    SIL_ENV --> PERIPHERALS
    TEST_DATA --> TEST_ORCH
    RESULT_COLL --> TEST_ORCH

    style SIL_ENV fill:#FFF3E0,stroke:#E65100,stroke-width:2px
    style VECU_CONTAINER fill:#FF9800,stroke:#E65100,stroke-width:3px
    style SIL_KIT fill:#4CAF50,stroke:#2E7D32
      

12.1 Component Responsibilities

flowchart LR
    A[Test Cases] --> B[Test Orchestration]
    B --> C[vECU Instance]
    C --> D{SIL Kit}
    D --> E[CAN Bus Sim]
    D --> F[FlexRay Bus Sim]
    D --> G[Ethernet Bus Sim]
    E --> H[Restbus]
    F --> H
    G --> H
    H --> I[Bus Monitor]
    C --> J[Peripheral Models]
    J --> C
    I --> K[Results]
    C --> K
      

12.2 Integration Patterns

13. Calibration and Parameterization Requirements

Calibration and parameterization capabilities enable fine-tuning of vECU behavior and adaptation to different vehicle configurations without code changes.

13.1 Level 3 vECU Calibration

13.2 Level 1 vECU Calibration

13.3 XCP Measurement and Calibration Requirements

13.4 Calibration File Formats

13.5 Calibration Workflow

flowchart TD
    A[Load DCM File] --> B[Parse Calibration Data]
    B --> C[Apply to vECU]
    C --> D{Level Type}
    D -->|Level 3| E[XCP Direct Access]
    D -->|Level 1| F[FMI LS-XCP]
    E --> G[Live Parameter Adjustment]
    F --> G
    G --> H[Verify Parameter Change]
    H --> I[Save Updated Calibration]
    I --> J[A2L Update]
      

14. Debug and Trace Capabilities

Debug and trace capabilities enable verification, troubleshooting, and performance analysis of vECU execution in simulation environments.

14.1 Level 3 vECU Debug Capabilities

• All internal measurement signals accessible
• Signal names IDENTICAL to real ECU measurement signal names
• Interface IDENTICAL to real ECU (e.g., XCP)
• Diagnostic extracts via SiL with same tool landscape as real vehicle

14.2 Level 1 vECU Debug Capabilities

• XCP interface mandatory if real ECU has XCP
• Integration via FMI 3.0 LS-XCP
• Limited signal access compared to Level 3

14.3 Trace Capabilities

14.4 Signal Naming Consistency

• Consistent test specification across SiL and HiL
• Reuse of existing calibration and measurement tools
• Traceability between virtual and physical testing

15. Functional Equivalence Verification

Functional equivalence verification ensures that vECU instances exhibit behavior equivalent to real ECUs within defined tolerances and test scenarios.

15.1 Acceptance Testing Requirements

Test Methods:

15.2 Test Specification Requirements

• Must provide test specification with:
  • Pre-condition: Initial state and configuration
  • Action: Input stimulus or trigger
  • Expected result: Definitive pass/fail criteria
• Tests shall use interface signals only
• Test cases must be documented and handed over

15.3 Test Execution Requirements

15.4 Model Delivery Requirements

• Model documentation standards
• Version control procedures
• Quality assurance checkpoints
• Handover documentation

15.5 Test Coverage Requirements

16. Functional Equivalence Architecture

The functional equivalence architecture provides a framework for comparing vECU behavior against real ECU specifications.

flowchart TD
    A[Real ECU Behavior
Specification] --> B[Test Specification
Definition]
    B --> C[OpenLoop Test Catalog]
    C --> D{Test Execution}
    D -->|Virtual| E[vECU Instance]
    D -->|Reference| F[Reference ECU
or Model]
    E --> G[Virtual Test
Results]
    F --> H[Reference Test
Results]
    G --> I{Comparison}
    H --> I
    I -->|Pass| J[Equivalence
Certified]
    I -->|Fail| K[Delta Analysis]
    K --> L[Issue Documentation]
    L --> M[Remediation
Required]
    M --> B

    style C fill:#FFF3E0,stroke:#E65100
    style J fill:#4CAF50,stroke:#2E7D32
    style K fill:#FF9800,stroke:#E65100
      

16.1 Verification Components

graph TB
    subgraph TEST_ENV["Test Environment"]
        subgraph INPUT["Input Generation"]
            STIMULI["Test Stimuli
Signals/Frames"]
            TIMING["Timing Control"]
        end
        subgraph DUT["Device Under Test"]
            VECU["vECU Instance"]
            MONITOR["Behavior Monitor"]
        end
        subgraph COMPARE["Comparison"]
            ACTUAL["Actual Output"]
            EXPECTED["Expected Output"]
            DIFF["Difference
Analyzer"]
        end
    end

    INPUT --> DUT
    DUT --> COMPARE
    STIMULI --> EXPECTED
    MONITOR --> ACTUAL
    ACTUAL --> DIFF
    EXPECTED --> DIFF

    style DUT fill:#FF9800,stroke:#E65100,stroke-width:3px
    style DIFF fill:#f44336,stroke:#B71C1C
      

16.2 Acceptance Criteria

17. Delivery Requirements

Delivery requirements ensure timely and comprehensive provision of vECU artifacts to support testing activities.

17.1 Timing Requirements

• All release software stocks and special versions must be delivered
• Same delivery process as real ECU software per Q-LAH
• Version nomenclature must match real ECU software

17.2 Documentation Requirements

17.3 Change Management Requirements

• Changes to function logics must be documented
• Model parameter changes must be documented
• Changelog required from contractor

Required Change Documentation:

17.4 Delivery Package Contents

18. Tool Compatibility Matrix

The tool compatibility matrix defines required tool versions, platforms, and purposes for vECU integration and testing.

18.1 Primary Simulation Environment

18.2 Integration Middleware

18.3 Standards and Interfaces

18.4 Calibration and Diagnostic Files

18.5 Model Development Framework

18.6 Version Compatibility Summary

19. Migration Path

The migration path defines the journey from physical ECU development to virtual ECU delivery and integration.

flowchart LR
    A[Physical ECU
Development] --> B[Real ECU
Software Release]
    B --> C{vECU Level
Selection}
    C -->|Level 3| D[vECU Level 3
Development]
    C -->|Level 1| E[vECU Level 1
Development]
    D --> F[Functional
Equivalence Testing]
    E --> F
    F --> G{Test Results}
    G -->|Pass| H[Acceptance
Certification]
    G -->|Fail| I[Remediation
Loop]
    I --> D
    I --> E
    H --> J[Delivery
Package Prep]
    J --> K[vECU
Delivery]
    K --> L[Client
Integration]
    L --> M[SiL/HiL
Testing]
    M --> N[Virtual Validation
Complete]

    style A fill:#9E9E9E,stroke:#616161
    style B fill:#9E9E9E,stroke:#616161
    style H fill:#4CAF50,stroke:#2E7D32
    style K fill:#FF9800,stroke:#E65100
      

19.1 Migration Phase Description

19.2 Timing Constraints

gantt
    title vECU vs Real ECU Delivery Timeline
    dateFormat YYYY-MM-DD
    axisFormat %d

    section Development
    Real ECU Development :2026-01-01, 2026-04-01
    vECU Development :2026-01-15, 2026-04-01

    section Delivery
    Real ECU Delivery :2026-04-01, 2026-04-02
    vECU Delivery :2026-03-30, 2026-04-01

    section Testing
    vECU Testing :2026-04-02, 2026-06-01
    Integration Testing :2026-04-15, 2026-06-15
      

20. Real-Time Performance Budget

Real-time performance budgeting ensures deterministic execution of vECU instances within hard real-time constraints of HiL systems.

20.1 Time Budget Overview

20.2 Time Budget Breakdown

pie title Calculation Step Time Budget (1ms = 1000us)
    "vECU Execution" : 50
    "System Tasks" : 50
      

gantt
    title Real-Time Calculation Step Timeline
    dateFormat X
    axisFormat %s us

    section Step Start
    Step Boundary :0, 0

    section vECU Budget
    vECU Init :0, 50
    vECU Execute :50, 400
    vECU Finalize :400, 500

    section System Budget
    Bus Simulation :100, 600
    Task Switch :600, 700
    Other Tasks :700, 1000

    section Step End
    Step Boundary :1000, 1000
      

20.3 Performance Requirements by Level

20.4 Execution Time Measurement

20.5 Worst-Case Budget Scenarios

21. Summary and Conclusions

21.1 Key Requirements Summary

21.2 Level 3 vs Level 1 Comparison

21.3 Critical Success Factors

21.4 Recommendations

• Prioritize Level 3 delivery for comprehensive testing coverage
• Consider Level 1 for early-stage development and speed-critical tests
• Ensure early engagement with vECU development team for timeline alignment
• Establish clear acceptance criteria based on this specification
• Plan for iterative refinement based on test results and feedback