Simulation Model Provisioning

Detailed Technical Requirements Analysis
Document Type: Technical Specification Analysis
Framework: VPF (Virtuelle Probefahrt - Virtual Test Drive)
Application Domain: XiL (X-in-the-Loop) Simulation Environments
Table of Contents

1Overview and Purpose

1.1 Document Scope

This document provides a comprehensive technical requirements analysis for the Simulation Model Provisioning framework, based on extracted technical specifications. The analysis focuses on the requirements for creating and delivering XiL (X-in-the-Loop) simulation models that enable virtual testing of automotive E/E (Electrical/Electronic) architectures.

1.2 Purpose and Objectives

The primary purpose of this technical analysis is to define and document the requirements for:

1.3 Application Domains

The simulation model provisioning framework supports multiple XiL test bench configurations:

Test Bench Type Abbreviation Description DUT Configuration
Hardware-in-the-Loop HiL Real-time simulation with physical hardware components Real ECUs as Devices Under Test
Hybrid Hardware-in-the-Loop Hybrid HiL Combined simulation with both real and virtual components Mixed Real ECUs and vECUs
Software-in-the-Loop SiL Pure software simulation environment Virtual ECUs (vECUs) only

1.4 Key Framework: VPF Architecture

The VPF (Virtuelle Probefahrt - Virtual Test Drive) model architecture serves as the foundational framework for simulation model provisioning. VPF provides:

Core Principle

All simulation models must be designed for integration into HiL real-time systems as real-time applications, enabling reproducible system, bus, and timing behavior across all test bench configurations.

2Overall Simulation Model Provisioning Architecture

This section presents the high-level system architecture for simulation model provisioning, illustrating the complete flow from input sources through model generation, quality validation, and deployment to test benches.

2.1 System Architecture Overview

Figure 2.1: Overall Simulation Model Provisioning Architecture
flowchart TB
    subgraph Input_Sources["INPUT SOURCES"]
        direction TB
        A1["MATLAB/Simulink Gesamtmodell
(.mdl, .m, .mat, .yaml/.json)"] A2["NIP-Release Bus Descriptions
(ARXML, LDF, AUTOSAR 4.3.0)"] A3["Virtual ECUs
(Level 1-3 vECUs)"] A4["Test Bench Configuration
(YAML: HiL/Hybrid/SiL)"] end subgraph Model_Generation["MODEL GENERATION PIPELINE"] direction TB B1["Input Validation & Parsing"] B2["Bus Simulation Configuration"] B3["vECU Integration"] B4["Restbus Model Assembly"] B5["Real-Time Target Compilation"] end subgraph Quality_Gate["QUALITY GATE"] direction TB C1["DUT Error State Check"] C2["Virtual Vehicle Drivability Test"] C3["Timing & Performance Validation"] C4["Protocol Conformance Check"] end subgraph Deployment["DEPLOYMENT"] direction TB D1["Test Bench 1
(HiL)"] D2["Test Bench 2
(Hybrid HiL)"] D3["Test Bench 3
(SiL)"] D4["Model Repository
(Git/Artifactory)"] end A1 --> B1 A2 --> B1 A3 --> B1 A4 --> B1 B1 --> B2 B2 --> B3 B3 --> B4 B4 --> B5 B5 --> C1 C1 --> C2 C2 --> C3 C3 --> C4 C4 --> D1 C4 --> D2 C4 --> D3 C4 --> D4 style Input_Sources fill:#e3f2fd,stroke:#1565c0,stroke-width:2px style Model_Generation fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style Quality_Gate fill:#fff3e0,stroke:#ef6c00,stroke-width:2px style Deployment fill:#fce4ec,stroke:#c2185b,stroke-width:2px
Input Sources
Model Generation
Quality Gate
Deployment

2.2 Data Flow Description

The provisioning architecture implements a staged data flow:

  1. Input Collection: All required artifacts (MATLAB/Simulink models, NIP bus descriptions, vECUs, test bench configs) are gathered from respective repositories
  2. Input Validation: Each input type is validated for format correctness, version compatibility, and completeness
  3. Model Generation: The simulation model is assembled, including bus simulation configuration and vECU integration
  4. Restbus Assembly: Static restbus from bus descriptions is combined with dynamic simulation components
  5. Real-Time Compilation: Model is compiled for real-time target hardware
  6. Quality Validation: Automated checks verify DUT state, drivability, and performance
  7. Deployment: Validated models are deployed to target test benches

2.3 Key Architectural Principles

Modularity

Each component (bus simulation, vECU integration, physics models) must be independently configurable and replaceable without affecting other system components.

Traceability

All model outputs must include metadata linking back to source artifacts (MATLAB release, NIP version, vECU versions) for full traceability.

Reproducibility

Same input artifacts must always produce identical simulation models, ensuring test repeatability.

Automation

Full pipeline from input change to test bench ready state must be automated with no manual interventions.

3Input Interface Definitions

This section defines the required input interfaces for simulation model provisioning, including format specifications, content requirements, and source locations.

3.1 MATLAB/Simulink Gesamtmodell (VPF)

3.1.1 Supported File Formats

Format Content Type Description
.mdl Simulink Model Libraries Simulink model files containing the complete vehicle system representation
.m MATLAB Scripts MATLAB automation scripts for model configuration and initialization
.mat Workspace Variables MATLAB workspace variables including parameter sets and configuration data
.yaml/.json Meta-info Files Metadata files containing model version, release info, and configuration parameters

3.1.2 Simulink Model Library Components

The MATLAB/Simulink Gesamtmodell comprises the following standardized model libraries:

Component Type Notation Description
ECU Simulation Models SimECU (S1, S2, S3...) Virtual ECU models at various integration levels (IO levels)
Physics Models P1, P2, P3... Vehicle physics simulation at different fidelity levels
vECU Adapter - Integration adapter for connecting external vECUs to the simulation

3.1.3 Repository Location

Source Repository

Primary: Git repository (VPFKonzern organization on hub.vwgroup.com)
Example Path: VPFKonzern/PPE41
Release Branches: e.g., VPFKonzern/PPE41 Release Test

3.2 Bus Description Files (NIP-Release)

3.2.1 AUTOSAR Format Support

Format Content Notes
ARXML System-Extracts, Bus-Extracts, ECU-Extracts Required for AUTOSAR-based architectures
LDF LIN bus descriptions including LIN slaves Required for LIN bus simulation
AUTOSAR Standard Version 4.3.0 Mandatory support required

3.2.2 Supported Bus Protocols

The NIP-Release must support the following automotive bus protocols:

CAN CAN(-FD)

Standard CAN and CAN-FD variants for vehicle networking

LIN LIN

Local Interconnect Network including slave nodes

FR FlexRay

High-speed FlexRay with static and dynamic segments

ETH Automotive Ethernet

Raw PDU communication over Ethernet

SOME/IP SOME/IP Services

Service-oriented communication middleware

3.2.3 Additional Protocol Catalogues

Catalogue Type Format Description
BAP Catalogues Proprietary Bedien- und Anzeige Protokoll (Operation and Display Protocol)
HID Command Catalogue Proprietary Human Interface Device command definitions
SOK Key Files Proprietary Mapping VKMS Key-ID to actual Key for secure communication
SOME/IP Services ARXML Service specifications for service-oriented communication
VWG-Specific Requirements

The system must accept VWG AUTOSAR dialect. Manual post-patching may be necessary to accommodate Volkswagen Group-specific AUTOSAR extensions.

3.3 Virtual ECUs (vECUs)

3.3.1 vECU Level Definitions

Level Description Integration
Level 1 Basic virtual ECU with minimal functionality Simple I/O mapping
Level 2 Intermediate vECU with extended features Bus communication capable
Level 3 Full-featured virtual ECU Complete integration with real-time behavior

3.3.2 vECU Integration Requirements

3.4 Test Bench Description

3.4.1 Test Bench Configuration Parameters

Parameter Format Description
Test bench type Enum HiL, Hybrid HiL, or SiL configuration
Device Under Test (DUT) Reference Real ECUs (HiL) or vECUs (SiL)
Restbus simulation Boolean Optional, for specific buses
HW configuration YAML Peripheral/attachment control, special protocols
File format .yaml Coordinated with client

4Input Architecture Diagram

This section provides a detailed architectural view of how all input sources flow into the model generation process.

4.1 Complete Input Data Flow

Figure 4.1: Input Sources to Model Generation Data Flow
flowchart LR
    subgraph VPF_Repository["VPF Repository
(Git/Artifactory)"] direction TB M1["MATLAB/Simulink Gesamtmodell"] M2["SimECU Libraries
(S1, S2, S3...)"] M3["Physics Models
(P1, P2, P3)"] M4["vECU Adapter"] end subgraph NIP_Repository["NIP Repository
(Bus Descriptions)"] direction TB N1["ARXML System-Extract"] N2["ARXML Bus-Extract"] N3["ARXML ECU-Extract"] N4["LDF Files"] N5["SOME/IP Service Specs"] end subgraph vECU_Registry["vECU Registry"] direction TB V1["Level 1 vECU"] V2["Level 2 vECU"] V3["Level 3 vECU"] end subgraph TestBench_Config["Test Bench Configuration"] direction TB T1["Bench Type Definition"] T2["HW Configuration"] T3["DUT Mapping"] T4["Restbus Settings"] end subgraph Model_Generator["Model Generation Engine"] direction TB G1["Input Aggregator"] G2["Dependency Resolver"] G3["Configuration Manager"] G4["Build Orchestrator"] end M1 --> G1 M2 --> G1 M3 --> G1 M4 --> G1 N1 --> G2 N2 --> G2 N3 --> G2 N4 --> G2 N5 --> G2 V1 --> G3 V2 --> G3 V3 --> G3 T1 --> G4 T2 --> G4 T3 --> G4 T4 --> G4 G1 --> Build["Simulation Model Build"] G2 --> Build G3 --> Build G4 --> Build style VPF_Repository fill:#e3f2fd,stroke:#1565c0,stroke-width:2px style NIP_Repository fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style vECU_Registry fill:#fff3e0,stroke:#ef6c00,stroke-width:2px style TestBench_Config fill:#fce4ec,stroke:#c2185b,stroke-width:2px style Model_Generator fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px

4.2 Input Validation Pipeline

Figure 4.2: Input Validation and Preprocessing Pipeline
flowchart TB
    subgraph Validation["Input Validation Pipeline"]
        directionTB
        V1["Schema Validation
(Format Check)"] V2["Version Compatibility
(Tool Versions)"] V3["Dependency Check
(Required Artifacts)"] V4["Content Integrity
(Checksum/Hash)"] V5["Semantic Validation
(Business Rules)"] end subgraph Preprocessing["Preprocessing Stage"] directionTB P1["Format Normalization"] P2["Path Resolution"] P3["Variable Substitution"] P4["Configuration Merge"] end V1 --> V2 V2 --> V3 V3 --> V4 V4 --> V5 V5 --> P1 P1 --> P2 P2 --> P3 P3 --> P4 style Validation fill:#ffebee,stroke:#c62828,stroke-width:2px style Preprocessing fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

4.3 Input Interface Summary

Input Category Source System Update Frequency Criticality
MATLAB/Simulink Gesamtmodell VPF Git Repository Per release cycle Critical
NIP Bus Descriptions NIP Repository Per NIP release Critical
Virtual ECUs vECU Registry As needed High
Test Bench Config Client System Per project High

5Output Interface Definitions

This section defines the complete set of outputs produced by the simulation model provisioning system, including simulation models, parameters, and metadata.

5.1 Simulation Models (XIL Real-Time Application)

5.1.1 Model Composition

The dynamic restbus simulation model consists of the following integrated components:

Component Description Source
Static Restbus Bus configuration from NIP descriptions with init/default parameterization NIP-Release
Protocol Simulation CAN-FD, LIN, FlexRay, Ethernet communication stacks NIP-Release
Dynamic Models MATLAB/Simulink Gesamtmodell dynamics in closed-loop VPF Gesamtmodell
DUT Interface I/O component configuration for real ECU/vECU connection Test Bench Config
Measurement System Signal acquisition and manipulation in real-time Integrated

5.1.2 Real-Time Capabilities

5.1.3 Dynamic Switching Requirements

Switching Capability

The simulation model must support dynamic switching between:

  • Simulated ECU: Full software simulation within the model
  • Real ECU (HiL): Physical hardware connected to the test bench
  • vECU (Hybrid HiL): Virtual ECU running on separate compute node

5.2 Parameter and Data Outputs

5.2.1 Parameterization Datasets

5.2.2 Project and Layout Files

5.3 Metadata Outputs (Machine-Readable YAML)

5.3.1 Required Metadata Fields

Field Content Example Description
E/E architecture/platform E3.1.2, SDV 0.1 Platform identifier
MATLAB/Simulink release version R2023a Release ID from VPF
NIP release version NIP_2023.2 Bus description release
Vehicle derivative Model/Variant Specific vehicle configuration
Simulation model version 1.2.3 Version string for output model
Vendor name Model provider Model generation provider
Vendor software version Tool version Model generator version
Test bench name/type HIL_Bench_01 HIL identifier
Variable mapping table model.var.path -> name Model variable to name mapping

5.3.2 Metadata Format Example

simulation_model_metadata:
  platform: "E3.1.2"
  matlab_release: "R2023a"
  nip_release: "NIP_2023.2"
  vehicle_derivative: "PPE41_SUV"
  model_version: "1.2.3"
  vendor_name: "VPF_Konzern"
  vendor_version: "3.2.1"
  test_bench: "HIL_Cluster_01"
  timestamp: "2024-01-15T10:30:00Z"
  variable_mappings:
    - model_path: "VPF.Vehicle.Speed"
      display_name: "vVehicle"
    - model_path: "VPF.ECU1.IO.Input"
      display_name: "ECU1_Input"

6Output Architecture Diagram

This section illustrates the complete output generation and delivery architecture.

6.1 Output Generation Flow

Figure 6.1: Simulation Model Output Generation and Delivery
flowchart TB
    subgraph Generation["Model Generation Process"]
        directionTB
        G1["Bus Simulation Assembly"]
        G2["vECU Integration"]
        G3["Physics Model Connection"]
        G4["I/O Configuration"]
        G5["Real-Time Compilation"]
    end

    subgraph Outputs["Output Artifacts"]
        directionTB
        O1["XIL Real-Time Application
(Simulation Model)"] O2["Parameter Datasets
(.mat, .yaml)"] O3["Metadata YAML
(Machine-readable)"] O4["Measurement Layouts
(Project Files)"] O5["Variable Mapping Tables"] end subgraph Delivery["Delivery Channels"] directionTB D1["Direct Deploy to
Test Benches"] D2["Model Repository
(Git/Artifactory)"] D3["Build Artifact
Storage"] end G1 --> O1 G2 --> O1 G3 --> O1 G4 --> O1 G5 --> O1 O1 --> D1 O2 --> D2 O3 --> D2 O4 --> D1 O5 --> D2 G1 -.-> O2 G2 -.-> O3 G3 -.-> O4 G4 -.-> O5 style Generation fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style Outputs fill:#e3f2fd,stroke:#1565c0,stroke-width:2px style Delivery fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

6.2 Output Delivery to Test Benches

Figure 6.2: Test Bench Deployment Architecture
flowchart TB
    subgraph Central["Build Server / CI/CD"]
        CI["Pipeline Controller"]
        BUILD["Build Artifacts"]
    end

    subgraph Repository["Model Repository"]
        REPO1["Git Tags"]
        REPO2["Build Artifacts"]
        REPO3["Metadata Store"]
    end

    subgraph Benches["Test Bench Infrastructure"]
        B1["HiL Bench 1"]
        B2["HiL Bench 2"]
        B3["Hybrid HiL"]
        B4["SiL Station"]
    end

    CI --> BUILD
    BUILD --> REPO2
    BUILD --> REPO1
    CI --> REPO3

    REPO2 --> B1
    REPO2 --> B2
    REPO2 --> B3
    REPO2 --> B4

    B1 -.-> "Auto-Load" -.-> CI
    B2 -.-> "Auto-Load" -.-> CI
    B3 -.-> "Auto-Load" -.-> CI
    B4 -.-> "Auto-Load" -.-> CI

    style Central fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style Repository fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style Benches fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    

7Real-Time Execution Requirements

This section specifies the mandatory real-time execution requirements for all simulation models.

7.1 Timing and Performance Requirements

Parameter Requirement Validation Method
Computation step size 1ms without overruns Real-time performance profiling
Real-time capability Mandatory for all models Determinism validation
Execution order Must follow MATLAB/Simulink Gesamtmodell definition Order verification test
Jitter tolerance < 100 microseconds Timing analysis
CPU utilization < 80% at peak load Resource monitoring

7.2 Signal Manipulation Requirements

7.2.1 Real-Time Signal Processing

7.2.2 E2E Message Handling

E2E Protection Type Signal Name Pattern Description
Checksum *_CRC, *_Checksum Message integrity verification signals
Message Counter *_Counter, *_SeqCounter Sequential message counting signals
Alive Counter *_AliveCtr Node alive indication signals
Brand-Specific Implementation

E2E message manipulation (checksum generation, message counter increment) must be implemented per brand-specific requirements. For example, E3.1.2 Audi platform has specific E2E signal handling requirements.

7.3 Execution Order Management

The simulation model must respect the execution order as defined in the MATLAB/Simulink Gesamtmodell:

8Communication Protocol Requirements

This section details the mandatory and optional communication protocol support for simulation models.

8.1 Supported Bus Protocols

Protocol Level Variants Notes
CAN CAN(-FD) Full simulation Standard CAN, CAN-FD Primary vehicle bus
LIN LIN Full simulation LIN 1.x, LIN 2.x Including LIN slave simulation
FR FlexRay Full simulation Static segment, Dynamic segment High-speed fault-tolerant
ETH Automotive Ethernet Full simulation 100BASE-TX, 1000BASE-T Raw PDU communication
SOME/IP SOME/IP Full simulation Service-based Service discovery and RPC

8.2 VWG-Specific Protocol Extensions

For Volkswagen Group applications, the following proprietary protocols must be supported:

Protocol Full Name Function
VWG-SOK Sichere Onboard Kommunikation Secure on-board communication with key management
TLS/dTLS Transport Layer Security Encrypted communication channels
BAP Bedien- und Anzeige Protokoll Operation and Display Protocol for HMI
PS15 VW Proprietary VW Group proprietary diagnostic protocol
ViWi VW infotainment web interface Infotainment system interface
Diagnose-Routing Diagnostic Routing Diagnostic message routing between ECUs
VIN-Routing WFS Routing Wegfahrsperre (Immobilizer) simulation via WFS

8.3 Signal Routing Requirements

8.3.1 Cross-Bus Routing

Route Type Description
ETH to ETH Ethernet to Ethernet gateway routing
ETH to FR Ethernet to FlexRay routing
ETH to CAN Ethernet to CAN gateway routing
CAN to FR CAN to FlexRay routing

8.3.2 Integration Interfaces

Interface Description
ASM Interface ASM (Automation Software Module) system integration
FEP Coupling Front-end Processor coupling for I/O
FPGA Interfaces FPGA-based hardware interfaces for high-speed I/O

9Protocol Architecture Diagram

This section illustrates the communication protocol stack and VWG-specific extensions.

9.1 Protocol Stack Architecture

Figure 9.1: Communication Protocol Stack
flowchart TB
    subgraph Application["Application Layer"]
        directionTB
        APP1["Diagnostic Services"]
        APP2["Measurement & Calibration"]
        APP3["Application Software"]
    end

    subgraph Service["Service Layer"]
        directionTB
        SVC1["SOME/IP Services"]
        SVC2["BAP Protocol"]
        SVC3["VWG-SOK"]
    end

    subgraph Transport["Transport Layer"]
        directionTB
        T1["TCP/UDP"]
        T2["TLS/dTLS"]
        T3["PS15"]
    end

    subgraph Network["Network Layer"]
        directionTB
        N1["IPv4/IPv6"]
        N2["AutoSAR PDU"]
    end

    subgraph Bus["Bus Abstraction Layer"]
        directionTB
        B1["CAN(-FD)"]
        B2["LIN"]
        B3["FlexRay"]
        B4["Ethernet"]
    end

    subgraph Physical["Physical Layer"]
        directionTB
        P1["CAN Transceiver"]
        P2["LIN Transceiver"]
        P3["FlexRay Transceiver"]
        P4["ETH PHY"]
    end

    APP1 --> SVC1
    APP2 --> SVC2
    APP3 --> SVC3
    SVC1 --> T1
    SVC2 --> T2
    SVC3 --> T3
    T1 --> N1
    T2 --> N1
    T3 --> N2
    N1 --> B4
    N2 --> B1
    B1 --> P1
    B2 --> P2
    B3 --> P3
    B4 --> P4

    style Application fill:#e8f5e9,stroke:#2e7d32
    style Service fill:#fff3e0,stroke:#ef6c00
    style Transport fill:#e3f2fd,stroke:#1565c0
    style Network fill:#fce4ec,stroke:#c2185b
    style Bus fill:#f3e5f5,stroke:#7b1fa2
    style Physical fill:#efebe9,stroke:#5d4037
    

9.2 VWG-Specific Protocol Extensions

Figure 9.2: VWG Protocol Extensions Architecture
flowchart LR
    subgraph Core["Core Simulation"]
        C1["Restbus Simulation"]
        C2["Bus Protocols
(CAN/LIN/FR/ETH)"] C3["vECU Integration"] end subgraph Extensions["VWG Extensions"] directionTB E1["VWG-SOK
(Secure Communication)"] E2["TLS/dTLS
(Encrypted Channels)"] E3["BAP Protocol
(HMI Communication)"] E4["PS15 Protocol
(VW Diagnostics)"] E5["ViWi Interface
(Infotainment)"] end subgraph Routing["Signal Routing"] directionTB R1["ETH ↔ ETH"] R2["ETH ↔ FR"] R3["ETH ↔ CAN"] R4["CAN ↔ FR"] end subgraph Integration["Integration Points"] directionTB I1["ASM Interface"] I2["FEP Coupling"] I3["FPGA Interfaces"] end Core --> Extensions Core --> Routing Routing --> Integration style Core fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style Extensions fill:#fff3e0,stroke:#ef6c00,stroke-width:2px style Routing fill:#e3f2fd,stroke:#1565c0,stroke-width:2px style Integration fill:#fce4ec,stroke:#c2185b,stroke-width:2px

10CI/CD Pipeline Requirements

This section defines the mandatory CI/CD pipeline capabilities and performance requirements for automated simulation model provisioning.

10.1 Build and Integration Performance

Metric Requirement Target
Input artifact change to output < 5 minutes End-to-end build time
Deployment to test bench ready < 5 minutes Deployment execution time
CI/CD availability 24/7 operation Continuous availability
Automated quality gate Yes, mandatory No manual approval required
Recovery time (failure) < 10 minutes From detection to retry

10.2 Mandatory Pipeline Capabilities

10.2.1 Automated Triggering

Changes to input artifacts must automatically trigger the deployment pipeline without manual intervention.

10.2.2 Required Pipeline Functions

10.3 Pipeline Monitoring and Reporting

Monitoring Aspect Requirement
Build status visibility Real-time dashboard showing pipeline status
Failure notifications Immediate alerts on pipeline failures
Build artifact retention Minimum 30 days retention for all build artifacts
Audit logging Complete audit trail of all pipeline executions

11CI/CD Pipeline Architecture Diagram

This section provides detailed architectural views of the CI/CD pipeline implementation.

11.1 Complete Pipeline Flow

Figure 11.1: Automated CI/CD Pipeline Architecture
flowchart TB
    subgraph Trigger["Pipeline Trigger"]
        directionTB
        T1["Input Change Event
(Webhook)"] T2["Scheduled Trigger
(Cron)"] T3["Manual Trigger
(API)"] end subgraph Artifacts["Input Artifacts"] A1["MATLAB/Simulink
Gesamtmodell"] A2["NIP Release
(Bus Descriptions)"] A3["vECU
Packages"] A4["HW Config
(YAML)"] end subgraph Build["Build Stage"] directionTB B1["Source Checkout"] B2["Dependency Resolution"] B3["Model Compilation"] B4["Artifact Packaging"] end subgraph Quality["Quality Gate"] directionTB Q1["DUT State Check"] Q2["Drivability Test"] Q3["Timing Validation"] Q4["Protocol Check"] end subgraph Deploy["Deploy Stage"] directionTB D1["Repository Upload"] D2["Test Bench Select"] D3["Model Loading"] D4["Bench Ready State"] end T1 --> Build A1 --> B1 A2 --> B1 A3 --> B1 A4 --> B1 B1 --> B2 B2 --> B3 B3 --> B4 B4 --> Q1 Q1 --> Q2 Q2 --> Q3 Q3 --> Q4 Q4 --> D1 D1 --> D2 D2 --> D3 D3 --> D4 style Trigger fill:#fff3e0,stroke:#ef6c00,stroke-width:2px style Artifacts fill:#e3f2fd,stroke:#1565c0,stroke-width:2px style Build fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style Quality fill:#ffebee,stroke:#c62828,stroke-width:2px style Deploy fill:#fce4ec,stroke:#c2185b,stroke-width:2px

11.2 Quality Gate Integration

Figure 11.2: Quality Gate Decision Flow
flowchart TB
    START(["Build Complete"]) --> Q1

    subgraph Q1["Quality Gate 1: DUT State"]
        D1["Check DUT error-free state"]
        D1 --> D1R{Result}
    end

    D1R -->|PASS| Q2
    D1R -->|FAIL| FAIL1["Log Failure
Notify Team
Block Deployment"] subgraph Q2["Quality Gate 2: Drivability"] D2["Verify virtual vehicle
is drivable"] D2 --> D2R{Result} end D2R -->|PASS| Q3 D2R -->|FAIL| FAIL2["Log Failure
Notify Team
Block Deployment"] subgraph Q3["Quality Gate 3: Timing"] D3["Validate real-time
performance"] D3 --> D3R{Result} end D3R -->|PASS| Q4 D3R -->|FAIL| FAIL3["Log Failure
Notify Team
Block Deployment"] subgraph Q4["Quality Gate 4: Protocol"] D4["Check protocol
conformance"] D4 --> D4R{Result} end D4R -->|PASS| SUCCESS(["Deploy to
Test Bench"]) D4R -->|FAIL| FAIL4["Log Failure
Notify Team
Block Deployment"] style FAIL1 fill:#ffcdd2,stroke:#c62828 style FAIL2 fill:#ffcdd2,stroke:#c62828 style FAIL3 fill:#ffcdd2,stroke:#c62828 style FAIL4 fill:#ffcdd2,stroke:#c62828 style SUCCESS fill:#c8e6c9,stroke:#2e7d32

12Model Repository Management

This section defines the repository infrastructure and management requirements for simulation models and artifacts.

12.1 Repository Types

Repository Type Primary Use Content
Git Primary version control Source models, scripts, configuration as code
Artifactory Binary artifact storage Compiled models, build artifacts, dependencies

12.2 VPF Repository Structure

12.2.1 Organization and Access

VPFKonzern Repository

Organization: VPFKonzern on hub.vwgroup.com
Example Project: VPFKonzern/PPE41 Release Test
Access: Based on user permissions within organization

12.2.2 Repository Tooling

Tool Source Purpose
VPFBasis SVN Initialization tool for Gesamtmodell baseline
Model-Generator GitHub Releases Model generation from repository sources

12.3 Infrastructure Requirements

12.3.1 Storage Requirements

12.3.2 Service Availability

24/7 Operation Required

All repository and build infrastructure must support 24/7 stable service operation to enable continuous integration and uninterrupted testing workflows.

13Model Versioning and Dependencies

This section defines the versioning strategy and dependency management for simulation models.

13.1 Dependency Chain

Figure 13.1: Model Dependency Chain
flowchart TB
    subgraph Tools["Required Tools"]
        T1["VPFBasis Tool
(from SVN)"] T2["Model-Generator
(from GitHub)"] end subgraph Standards["Standards"] S1["AUTOSAR 4.3.0
(Mandatory)"] S2["VWG AUTOSAR Dialect
(Accepted)"] end subgraph Models["Model Components"] M1["MATLAB/Simulink
Gesamtmodell"] M2["NIP Bus
Descriptions"] M3["vECU
Packages"] end subgraph Outputs["Outputs"] O1["Simulation Model
with Version ID"] O2["Metadata YAML
(Dependency记录)"] end T1 --> M1 T2 --> M1 S1 --> M2 S2 -.-> M2 M1 --> O1 M2 --> O1 M3 --> O1 O1 --> O2 style Tools fill:#fff3e0,stroke:#ef6c00,stroke-width:2px style Standards fill:#e3f2fd,stroke:#1565c0,stroke-width:2px style Models fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style Outputs fill:#fce4ec,stroke:#c2185b,stroke-width:2px

13.2 Dependency Details

Dependency Version/Spec Support Level Notes
VPFBasis Tool Latest from SVN Required For Gesamtmodell initialization
Model-Generator From GitHub Releases Required For model generation automation
AUTOSAR Version 4.3.0 Mandatory Standard support required
VWG AUTOSAR Dialect VWG-specific Accepted Manual post-patching may be necessary

13.3 Metadata for Unique Identification

Each simulation model output must include the following metadata for unique identification and traceability:

14Quality Gate and Validation Requirements

This section defines the quality assurance framework for simulation model validation before deployment.

14.1 Acceptance Process

Systematic commissioning (Inbetriebnahme) must be completed before rollout to XIL test systems. The acceptance process follows these mandatory steps:

  1. Pre-deployment Validation: Verify DUT error-free state is established
  2. Functionality Check: Verify virtual vehicle is drivable (basic functionality)
  3. Requirement Verification: Confirm test bench-specific quality requirements are met
  4. Deployment Authorization: Release for deployment upon successful validation

14.2 Quality Gate Checks

Check Criteria Pass Condition
DUT Error State No error flags active All DUT status signals indicate operational
Virtual Vehicle Drivability Vehicle responds to basic commands Acceleration, braking, steering functional
Test Bench Requirements Bench-specific criteria All defined quality metrics met

14.3 Defect Management

14.3.1 Contractor Responsibilities

14.3.2 Defect Categories

Category Description Response Time
Critical Model fails to build or deploy Immediate
Major Functionality impaired, workaround available Within 24 hours
Minor Non-critical issues, cosmetic Next release cycle

15Parameterization and Calibration Requirements

This section defines the parameterization framework and calibration data management for simulation models.

15.1 Parameterization Data

15.1.1 Data Sources

15.1.2 Parameterization Concept

Coordination Requirement

The parameterization concept must be technically coordinated with client to ensure compatibility with existing tools and workflows.

15.2 Mapping Tables

15.2.1 Variable Mapping Requirements

Requirement Specification
Format Machine-readable (YAML or coordinated format)
Content Maps model variable paths to human-readable names
Usage Required for test automation integration

15.2.2 Mapping Table Format

variable_mappings:
  - model_path: "VPF.Vehicle.Dynamics.Speed"
    display_name: "vVehicle"
    unit: "m/s"
    data_type: "float"
  - model_path: "VPF.ECU1.IO.Digital_Input_01"
    display_name: "ECU1_DI_01"
    unit: "boolean"
    data_type: "bool"
  - model_path: "VPF.Bus.CAN_FD.Message_01"
    display_name: "CAN_FD_Msg_01"
    unit: "-"
    data_type: "structure"

15.3 Signal Manipulation

15.3.1 E2E Message Handling

Signal manipulation for E2E protected messages must support:

15.3.2 Brand-Specific Implementation

Per-Brand Requirements

Signal manipulation implementation must be done per brand and vehicle project requirements. Example: E3.1.2 Audi platform requires specific E2E signal handling patterns.

16Dynamic Switching Architecture

This section illustrates the dynamic switching capability between different ECU modes in the simulation environment.

16.1 ECU Mode Switching

Figure 16.1: Dynamic ECU Mode Switching Architecture
flowchart TB
    subgraph Simulation_Model["Simulation Model Environment"]
        directionTB
        SM["MATLAB/Simulink
Gesamtmodell"] BUS["Bus Simulation
(CAN/LIN/FR/ETH)"] SWITCH["Dynamic
Switch"] end subgraph Modes["ECU Operating Modes"] directionTB SIM["Simulated ECU
(In-Model)"] REAL["Real ECU
(HiL)"] VECU["vECU
(Hybrid HiL)"] end subgraph Connections["Signal Connections"] C1["I/O Signals"] C2["Bus Traffic"] C3["Control Signals"] end SM --> BUS BUS --> SWITCH SWITCH --> SIM SWITCH --> REAL SWITCH --> VECU SIM --> C1 REAL --> C2 VECU --> C3 SIM -.->|"Closed Loop"| SM REAL -.->|"Closed Loop"| SM VECU -.->|"Closed Loop"| SM style Simulation_Model fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style Modes fill:#e3f2fd,stroke:#1565c0,stroke-width:2px style Connections fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

16.2 Switching Use Cases

Use Case From To Trigger
Development Simulated ECU Real ECU (HiL) Ready for hardware test
Debugging Real ECU (HiL) Simulated ECU Hardware issue detected
Scaling Real ECU (HiL) vECU (Hybrid HiL) Resource optimization
Hybrid Testing vECU (Hybrid HiL) Simulated ECU Specific scenario testing

16.3 Switching Timing Requirements

Parameter Requirement
Switch activation time < 100ms
Signal continuity No signal loss during switch
State preservation ECU state preserved across switch
Logging All switches logged with timestamp

17Data Exchange Formats Summary

This section provides a consolidated reference of all data exchange formats used in the simulation model provisioning system.

17.1 Model and Script Formats

Category Format Extension Description
Simulink Models Simulink Model .mdl Simulink model libraries and components
MATLAB Scripts MATLAB Script .m MATLAB automation and configuration scripts
Workspace Variables MATLAB Data .mat MATLAB workspace variables and parameter sets
Metadata YAML/JSON .yaml/.json Meta-info files for model configuration

17.2 Bus Description Formats

Category Format Extension Description
AUTOSAR Descriptions AUTOSAR XML .arxml System, Bus, and ECU extracts
LIN Bus LDF .ldf LIN bus descriptions including slaves
Service Specs SOME/IP ARXML .arxml SOME/IP service definitions

17.3 Configuration and Test Bench Formats

Category Format Extension Description
Test Bench Config YAML .yaml Test bench descriptions and HW config
Simulation Metadata YAML .yaml Model identification and version info
Variable Mapping YAML .yaml Path-to-name mapping tables

17.4 Output Artifact Summary

Artifact Type Format Destination
Simulation Model (XIL) Real-time Application Test Benches
Parameter Datasets .mat, .yaml Model Repository
Metadata .yaml Model Repository
Measurement Layouts Proprietary Test Benches

18Coordination Requirements

This section documents all aspects that must be coordinated with the client for successful simulation model provisioning implementation.

18.1 Technical Coordination Items

Item Description Coordination Required
Test Bench Description Format YAML structure and schema for test bench configurations Mandatory
Parameterization Concept Technical approach for model parameterization Mandatory
XIL Model Architecture Overall simulation model structure and organization Mandatory
Project Structure Directory and file organization for projects Mandatory
Storage Locations Repository paths and storage allocation Mandatory
MATLAB/Simulink Release Specific MATLAB/Simulink version for compatibility Mandatory

18.2 Coordination Process

Figure 18.1: Client Coordination Workflow
flowchart TB
    START(["Project Initiation"]) --> R1

    subgraph Requirements["Requirements Gathering"]
        R1["Collect Technical
Requirements"] R2["Review Current
Infrastructure"] R3["Define Integration
Points"] end R1 --> R2 R2 --> R3 R3 --> REVIEW subgraph Review["Coordination Review"] REVIEW["Technical Review
with Client"] APPROVE{Approved?} end REVIEW --> APPROVE APPROVE -->|Yes| SPEC["Create Specification
Document"] APPROVE -->|No| REVISE["Revise Requirements"] REVISE --> R1 SPEC --> IMPL["Implementation
Phase"] IMPL --> VALIDATE["Validation
Phase"] VALIDATE --> HANDOVER["Production
Handover"] style Requirements fill:#e3f2fd,stroke:#1565c0,stroke-width:2px style Review fill:#fff3e0,stroke:#ef6c00,stroke-width:2px style IMPL fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style HANDOVER fill:#fce4ec,stroke:#c2185b,stroke-width:2px

18.3 Key Contact Points

Area Responsible Deliverable
Infrastructure Setup Client IT Repository access, storage allocation
Model Configuration VPF Team Gesamtmodell releases
Bus Descriptions NIP Team NIP releases and updates
Test Bench Setup Test Systems Bench configuration, HW setup
Integration Joint Pipe integration, validation

18.4 Change Management

Change Coordination Process

All changes to coordinated items must follow the established change management process:

  1. Change request submission with technical justification
  2. Impact assessment by affected teams
  3. Client approval for technical changes
  4. Implementation and regression testing
  5. Documentation update and validation
Created by MiniMax Agent
×