- 1. Overview and Purpose
- 2. Overall Simulation Model Provisioning Architecture
- 3. Input Interface Definitions
- 4. Input Architecture Diagram
- 5. Output Interface Definitions
- 6. Output Architecture Diagram
- 7. Real-Time Execution Requirements
- 8. Communication Protocol Requirements
- 9. Protocol Architecture Diagram
- 10. CI/CD Pipeline Requirements
- 11. CI/CD Pipeline Architecture Diagram
- 12. Model Repository Management
- 13. Model Versioning and Dependencies
- 14. Quality Gate and Validation Requirements
- 15. Parameterization and Calibration Requirements
- 16. Dynamic Switching Architecture
- 17. Data Exchange Formats Summary
- 18. Coordination Requirements
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:
- Model Generation: Creating simulation models from various input sources including MATLAB/Simulink Gesamtmodell, bus description files (NIP-Release), and virtual ECUs (vECUs)
- Model Deployment: Delivering ready-to-use simulation models to X-in-the-Loop (XiL) test benches
- Quality Assurance: Implementing automated quality gates to ensure model correctness before deployment
- Continuous Integration: Establishing CI/CD pipelines for automated model building and deployment
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:
- Standardized model libraries for ECU simulation (SimECUs)
- Physics-based vehicle dynamics models (P1, P2, P3 levels)
- Integration adapters for vECU connectivity
- Bus communication simulation infrastructure
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
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
2.2 Data Flow Description
The provisioning architecture implements a staged data flow:
- Input Collection: All required artifacts (MATLAB/Simulink models, NIP bus descriptions, vECUs, test bench configs) are gathered from respective repositories
- Input Validation: Each input type is validated for format correctness, version compatibility, and completeness
- Model Generation: The simulation model is assembled, including bus simulation configuration and vECU integration
- Restbus Assembly: Static restbus from bus descriptions is combined with dynamic simulation components
- Real-Time Compilation: Model is compiled for real-time target hardware
- Quality Validation: Automated checks verify DUT state, drivability, and performance
- Deployment: Validated models are deployed to target test benches
2.3 Key Architectural Principles
Each component (bus simulation, vECU integration, physics models) must be independently configurable and replaceable without affecting other system components.
All model outputs must include metadata linking back to source artifacts (MATLAB release, NIP version, vECU versions) for full traceability.
Same input artifacts must always produce identical simulation models, ensuring test repeatability.
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
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:
Standard CAN and CAN-FD variants for vehicle networking
Local Interconnect Network including slave nodes
High-speed FlexRay with static and dynamic segments
Raw PDU communication over Ethernet
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 |
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
- Must be integrable into HiL real-time systems as real-time applications
- Must allow reproducible system behavior
- Must allow reproducible bus communication behavior
- Must allow reproducible timing behavior
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
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
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
- Signal acquisition and measurement in real-time execution
- Signal manipulation in real-time for fault injection and scenario modification
- Dynamic switching between simulated ECU, real ECU (HiL), and vECU (Hybrid HiL)
- Execution order respecting MATLAB/Simulink Gesamtmodell definitions
5.1.3 Dynamic Switching Requirements
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
- Datasets for simulation model parameterization
- Derived parameters extracted from MATLAB/Simulink Gesamtmodell
- Bus-specific configuration parameters
5.2.2 Project and Layout Files
- Measurement software project files
- Control software layout configurations
- Visualization configurations for test monitoring
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
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
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
- Signal acquisition in real-time with < 1ms latency
- Signal manipulation capability for fault injection
- Per brand and vehicle project requirements for 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 |
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:
- Base rate execution first (typically 10ms or 1ms base rate)
- Subrate models execute according to defined rates
- Asynchronous events handled with proper priority
- Data dependencies resolved through signal routing
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
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
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
- Automated Build: Compilation of simulation models from source artifacts
- Quality Gate Execution: Automated mechanism for acceptance of simulation model quality
- Automatic Deployment: Loading of simulation models onto test benches without manual steps
- Test Bench Initialization: Bringing test bench to operational state for automated test runs
- CI/CT Integration: Integration into client-defined Continuous Integration/Continuous Test chain
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
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
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
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
- Storage locations for XIL models must be coordinated with client
- Build results storage must support versioning and rollback
- Minimum retention period: 12 months for all model versions
12.3.2 Service Availability
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
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:
- E/E Architecture/Platform: e.g., E3.1.2, SDV 0.1
- MATLAB/Simulink Release Version: Release identifier from VPF
- NIP Release Version: Bus description release identifier
- Vehicle Derivative: Specific vehicle model and variant
- Simulation Model Version: Semantic version string
- Vendor Name and Software Version: Provider identification and tool versions
- Test Bench Name/Type: Target HIL identifier
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:
- Pre-deployment Validation: Verify DUT error-free state is established
- Functionality Check: Verify virtual vehicle is drivable (basic functionality)
- Requirement Verification: Confirm test bench-specific quality requirements are met
- 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
- Define measures for recurring model errors
- Ensure implementation of error corrections
- Maintain change management documentation
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
- Datasets for simulation model derived from MATLAB/Simulink Gesamtmodell
- Bus-specific parameters extracted from NIP descriptions
- ECU-specific calibration data from vECU packages
15.1.2 Parameterization Concept
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:
- Checksum Generation: Automatic CRC/checksum calculation
- Message Counter: Sequential counter incrementing per message
- Alive Signals: Periodic alive indication signals
15.3.2 Brand-Specific Implementation
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
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
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
All changes to coordinated items must follow the established change management process:
- Change request submission with technical justification
- Impact assessment by affected teams
- Client approval for technical changes
- Implementation and regression testing
- Documentation update and validation